‫Şimdiye kadar, YAML'nin şu şekilde olabileceğini
‫tartıştık. dört kök nesne vardır ve bunlardan
‫üçünden kısaca bahsettik.
‫Bu tamamen teknik özelliklerle ilgili.
‫Ne yapmasını istediğinize dair ayrıntılar, doğru.
‫İlk olarak API'ye sahiptik, bu yüzden API'nin hangi sürümüyle
‫konuştuğumuzu biliyoruz. Hangi kaynakla konuşmak istediğimizi ve
‫hangi kaynakla uğraşacağımızı biliyoruz.
‫O zaman meta verilerdeki adı biliyoruz.
‫Bizde o var. Bundan sonra, teknik özellikler
‫keşfedilecek koca bir dünyadır.
‫Öğrenmenizi istediğim ilk komut, belirli bir
‫kaynak türü için koyabileceğiniz tüm farklı
‫anahtarları nasıl listeleyeceğinizdir.
‫Öğrenmeniz gereken ilk komut kubectl açıklaması
‫ve ardından kaynak türü.
‫YAML'deki tür budur.
‫Sonra --recursive.
‫Bu size YAML dosyasında desteklediği tüm farklı
‫anahtarları gösterecektir.
‫Sadece hizmetler için, bunun çok fazla geri dönüşü olduğunu
‫görebilirsiniz. Biraz bunaltıcı.
‫Orada çok şey var.
‫Tabii ki, bize bu şeylerin ne işe yaradığını söylemiyor.
‫Ancak, bu en azından hepsinin hızlı
‫bir listesidir. Bunun benim için iyi
‫olan yanı, YAML oluştururken o şeyin adını tam olarak hatırlayamıyorsam,
‫oluşturma zaman damgası.
‫Zaman damgası oluşturma mı?
‫Çoğul mu? Tekil mi?
‫Bunu sadece hızlı bir arama olarak kullanabilirsiniz.
‫Ancak, bu size bu şeylerin ne işe yaradığını veya hangilerinin gerekli
‫olduğunu ya da buna benzer bir şeyi söylemeyecek.
‫Biraz farklı bir komut kullanarak detaya inebilir ve daha fazla ayrıntı
‫elde edebiliriz.
‫kubectl explain services'i tekrar
‫yapalım, ancak bu sefer YAML'de detaya inmek için nokta gösterimini
‫kullanacağız.
‫Sadece teknik özelliklerle ilgilendiğimi söyleyeceğim.
‫Sana katılıyorum. spec.
‫Bu sefer, sadece spesifikasyonun alt anahtarlarını ve ardından
‫bunlar hakkında küçük bir açıklama alıyorum.
‫O halde, ne tür bir değeri destekledikleri, doğru.
‫Boolean olup olmadığı? Nesnelerin bir haritası mı?
‫Bunun gibi şeyler, doğru. Bu sadece güzel bir referans.
‫Bu, dokümantasyona atlamanıza yardımcı
‫olacaktır. Buraya bakarak bundan biraz
‫kaçınabilirsiniz. Bu, özellikle sadece tek bir özellik
‫aramak istediğinizde yine de çok fazla olabilir.
‫Nokta notasyonunu delmeye devam edebilirsiniz.
‫Eğer spesifikasyon yaparsak. type, yani hizmetler
‫YAML'si içinde yük dengeleyicinin türünü
‫söyleyen belirli bir anahtardır.
‫Bu kursun başlarında hizmetler hakkında konuşurken
‫bunu hatırladıysanız, bu varsayılan olarak küme IP'si olabilir.
‫Bunu dışarıda bırakırsanız, sadece küme IP'sini veya bir düğüm bağlantı
‫noktasını veya yük dengeleyiciyi yapacaktır.
‫Bunu belirtmeniz gereken yer burasıdır.
‫YAML dosyanızda spec ve ardından type anahtarının
‫altına girmesi gerektiğini biliyorsunuz.
‫Bu durumda, YAML'ımızı yazmaya başlayabiliriz, değil mi?
‫Bu türün hizmet olacağını biliyoruz.
‫Burada API sürümünün bu tür için v1 olduğu
‫yazıyor. Bunu daha önce yaptığımız gibi api-versions
‫komutu ile de doğrulayabilirsiniz.
‫Sonra değerinizi girebilirsiniz.
‫Bu, çalışma değerini listeler, böylece küme IP'sinin
‫büyük C ve büyük IP ile olduğunu bilirsiniz, bunun gibi şeyler,
‫doğru. Sizi internetin her yerinde
‫arama yapmaktan alıkoyar.
‫Birinin modasının geçip geçmeyeceğini ya da doğru olup olmayacağını
‫asla bilemezsiniz.
‫Ben böyle yapmayı seviyorum.
‫Sadece bu nokta gösteriminin ne kadar ileri gidebileceğini göstermek için.
‫Bir dağıtım spesifikasyonuna bakarsak, çünkü
‫alt spesifikasyonları var, bu da hakkında
‫konuşmadığımız bir şey. Bir kaynağı başka bir kaynağın alt nesnesi
‫olarak kullanabilirsiniz.
‫Bu durumda, verileri depolamak için hacimler, doğru.
‫Bir dağıtımın içinde istediğimiz kadar birime sahip
‫olabiliriz ve bu birimler daha sonra
‫konteynerlere bağlanır. Bunlar kesinlikle kendi
‫kaynak türleri, doğru, hacim.
‫Bu durumda, spesifikasyonu iki kez göreceğiz.
‫Dağıtım için bu komutta enter
‫tuşuna basarsam. spek, oradaki şeylerden biri
‫şablon olacaktır.
‫O zaman sadece şablon yazabilirim.
‫Sonra oraya koyabileceğim tüm farklı anahtarları
‫listeler ve bunlardan biri şablonun özelliğidir.
‫Teknik olarak, bir spesifikasyonun spesifikasyonundayız.
‫Daha sonra bir pod şablonu için bu spesifikasyonun altında,
‫çünkü bir dağıtımın kendi spesifikasyonu
‫vardır ve daha sonra podlar için şablon bu spesifikasyonun
‫altındadır. O zaman konteynerler için
‫bir spesifikasyon var ve burada hacimler olabilir.
‫Yani birimler ve sonra nfs çünkü bu kullanabileceğim
‫bir birim türü.
‫Sonra NFS içinde kullanacağım sunucu.
‫İşte başlıyoruz. Açıklama ve sürümler hakkında
‫bilgi alabildim. Bu arada, Kubernetes ile ilgili
‫bir başka tuhaflık da, komut satırlarındaki belgelerin
‫sürümler söz konusu olduğunda biraz eski olması, bu yüzden
‫her zaman API kaynakları ile birlikte API sürümleri komutunu
‫kullanıyorum. Çünkü daha önce bu şekilde
‫yapılıyordu. Artık dağıtımlar için yeni uygulamalara/v1'e
‫sahipler. Bunu biliyorum çünkü bunun neden
‫böyle olduğunu araştırıyordum ve tamamen kullanımdan
‫kaldırılana kadar belgelerde bu şekilde tuttukları
‫ortaya çıktı.
‫Her neyse, sonunda nokta notasyonu
‫ile nasıl ilerleyeceğimi görebilirsiniz.
‫Sadece görevlendirme yapardım. O zaman buna bakardım.
‫Ve sonra ben . spesifikasyonlar, vb.
‫Sonunda YAML'ime koyacağım doğru anahtarları
‫ve değerleri bu şekilde bulabilirim.
‫Her zaman başkalarının örneklerini kullanabilirsiniz.
‫Muhtemelen sonunda elde edeceğiniz şey, ya benden
‫ya da belgelerden bazı örneklerle başlayacağınızdır.
‫Ardından, buradaki yöntemimi kullanarak saf
‫vanilya dosyasından geçip geçemeyeceğinizi görmek
‫isteyeceksiniz. O zaman kendi küçük kaynağınıza
‫sahip olursunuz, değil mi? Tüm bu kaynak YAML'lerinin
‫kendi küçük kopyanız. Bu senin özel bilgi
‫depon. Şirketinizde kullanacağınız şey bu olacak.
‫Hatta dağıtımları nasıl oluşturacağınıza dair standartlarınız ve hizmetleri
‫nasıl oluşturacağınıza dair standartlarınız bile olabilir.
‫Belki üzerlerinde henüz konuşmadığımız özel etiketler veya
‫ek açıklamalar olacak.
‫Belki de özel bir şablon özellikleri olacaktır.
‫Her neyse. Burada yapabileceğiniz çok
‫şey var, ancak çoğu ekip tamamen sıfırdan yazmak
‫yerine bir tür depoda kendi varsayılanlarını oluşturuyor.
‫Doğru. Bunu compose ile yapmıyoruz
‫ve kesinlikle bunu Kubernetes'teki YAML ile
‫yapmak istemeyeceğiz. Burada size vereceğim son küçük
‫ipucu, eğer daha çok geliştirici tarafındaysanız,
‫tüm bu aynı verileri alabileceğiniz API belgelerini her
‫zaman takdir edeceksiniz.
‫Sadece daha operasyonel odaklı bir kişinin anlayacağı
‫şekilde olması gerekmiyor.
‫Her iki geçmişten de geliyorum, ancak API dokümantasyonunun
‫swagger ve API'ler için diğer tüm dokümantasyon türlerini
‫okumaya alışkın olmayan biri için nasıl biraz
‫göz korkutucu olabileceğini kesinlikle görebiliyorum.
‫Burada, örneğin 115 altındaki API
‫için Kubernetes referansını seçeceğim, yani
‫bu sürümlendirilmiş.
‫Burada, sol tarafta, tüm iş yükü API'lerinin bir
‫menüsünü görebiliyorum.
‫Uğraşacağınız şeylerin
‫çoğu bunlar olacak. Bir de hizmet API'si var.
‫Bu şeyler, hizmetler veya giriş, uç
‫nokta gibi iş yüklerinizin üstüne
‫gider. Sonra burada yapılandırmalar ve depolama var.
‫İlerledikçe, aslında daha fazla kullanımdan kaldırılmış veya eski
‫API sürümlerine ulaşacaksınız.
‫Şunları araştırabilirsiniz... Bu alfa ve betaların çoğunu
‫burada göreceksiniz.
‫Hangilerinin orada olduğunu anlayabilirsiniz.
‫Çok hızlı bir şekilde dağıtıma çıkıp buraya
‫gelirsem, neye benzeyebileceğine dair bazı kubectl örnekleri
‫alabilirim.
‫Burayı aşağı kaydırıp teknik özelliklere
‫de bakabilirim.
‫Bir şeyin özellikleri, daha önce baktığımız tüm
‫ayrıntıları elde edeceğiniz yerdir.
‫Spesifikasyonun altında, söz konusu nesne için tüm
‫bu farklı seçenekleri göreceksiniz.
‫Dağıtım spesifikasyonunun şablonuna dalarsam, bir süre
‫önce nokta gösterimini takip ettiğim zamanı
‫hatırlarsanız, bu pod şablonuna gidecektir.
‫Sonra buraya atlayacağız ve tüm bu şeylerin
‫bu şablona atladığını göreceksiniz ve bu
‫böyle devam edecek. Aradığınız nesneleri ve
‫anahtarları bulmak için biraz etrafı araştırmanızı
‫gerektiriyor. Komut satırından çalışmanın biraz
‫daha kolay olduğunu düşünüyorum, ancak komut satırı da sürümlerle
‫ilgilenmiyor.
‫Sunucu sürümünüzden farklı bir istemci sürümüne sahipseniz,
‫API dokümanlarına kesinlikle bakmak isteyeceksiniz çünkü
‫istemciniz sunucunuzun destekleyebileceğinden daha eski veya
‫daha yeni bir sürümde olabilir.
‫Bildiğim kadarıyla komut satırında bilgilerin
‫farklı versiyonlarını almanın gerçek bir yolu yok.
‫Her zaman sadece müşterinizin versiyonudur.