‫Şimdiye kadar kullandığınız bazı komutların
‫arkasında jeneratör olarak bilinen küçük bir
‫otomasyon vardır. Jeneratörleri şablonlar gibi düşünebilirsiniz.
‫Esasen komut satırı seçeneklerinize göre Kubernetes
‫kümesine uygulanacak spesifikasyonu veya belirtimi
‫oluştururlar.
‫Run, expose ve create gibi komutları
‫düşünürsünüz. Genellikle arkalarında, komut satırında
‫belirtmeniz gerekmeyen tüm alanlar ve
‫varsayılanlarla birlikte gerekli şablonu veren jeneratörler
‫olacaktır.
‫Esasen, bu jeneratörlerin amacı Docker,
‫Docker Compose ve Swarm ile alıştığınız gibi tek satırlık komutları
‫kullanmanızı kolaylaştırmaktır.
‫Kubernetes'te bu tek satırlık komutları kullanırken daha
‫gelişmiş ayarlardan bazılarını varsayılanlara bırakmak.
‫Gerçekten, Swarm bunu da yapıyor.
‫Swarm, arka planda gerçekleşen hizmetler ve yığınlar oluşturduğunuzda
‫birçok varsayılana sahiptir.
‫Sadece bunu bilmiyorsun. Bu jeneratörler böyledir.
‫Burada create komutuyla bir Deployment oluşturduğumuz
‫ve minimum gereksinimleri karşılamak için ona
‫birkaç seçenek verdiğimiz bir örnek var.
‫Spesifikasyonun geri kalanını bir jeneratör
‫ile dolduracaktır.
‫Bu jeneratörler, oluşturduğunuz her
‫tür şey için farklıdır. İster bir hizmet, ister dağıtım,
‫ister bir iş ya da cron işi olsun.
‫Diğer şeyler hakkında daha sonra konuşacağız.
‫Kubernetes'in her sürümü çıktıkça bu
‫jeneratörler de zaman içinde değişebilir.
‫Bu spesifikasyonun bir ya da iki özelliğini değiştirebilirler.
‫Yani, bunların versiyonları var.
‫Bazen belgelerde Kubernetes için bazı YAML'ler
‫görebilirsiniz ve beta hakkında bir şeyler söyler.
‫Bu genellikle bir jeneratör ilk oluşturulduğunda beta sürümüne
‫sahip olabilir ve daha sonra olgun bir jeneratöre
‫dönüştüğünde V1 sürümüne sahip olur.
‫Komut satırında jeneratörlerin bir listesini alamayız
‫çünkü hangi jeneratörlerin kullanılabileceği farklı
‫komutları ve farklı seçenekleri kapsar.
‫Tüm bu farklı komutlar boyunca, bir kümeye
‫karşı bu komutu yazdığınızda ne üretileceğini
‫görmenin en kolay yolu iki seçenek kullanmaktır.
‫Yazdıklarınızın çıktısını göstermenin gerçekten
‫güzel bir yolu olan kuru çalıştırmayı birazdan
‫göreceğiz. Sonra -o, yani
‫çıktı. YAML'de bir çıktı istediğimizi söylüyoruz.
‫Aslında bu komutu çalıştırın ama teknik olarak bunu
‫küme üzerinde yapmayın diyoruz.
‫Sadece yaparsam ne olacağını görmek için denedim.
‫Sonra aynı zamanda, bu komutu bitirirsem ne üretileceğine
‫dair YAML çıktısını gösterin.
‫Esasen güzel küçük şablonlar elde edeceksiniz.
‫Hatta bunu daha sonraki derslerde kullanacağımız kendi YAML'ınızı oluşturmaya
‫başlamak için bile kullanabilirsiniz.
‫Son olarak, jeneratörler burada.
‫Bunları fikir sahibi varsayılanlar olarak da düşünebilirsiniz.
‫Gerçekten fikir sahibi değiller.
‫Çok küçükler.
‫Bunlar genellikle 10 ila 15 satırlık YAML'dir.
‫Bir şeyi başlatmak için gereken en az şey.
‫Yine de fikirleri var, bu yüzden versiyonları
‫var. Bir beta sürüm mezunu
‫falan görebilirsiniz. Fikir sahibi olduklarını düşünüyorum
‫ama iyiler, değil mi? Sadece geliştirme ve test için bir
‫şeyler denerken çoğu kullanım durumu için işe yarayacaklardır.
‫Bu jeneratörleri komut satırında görmek için birkaç
‫örnek üzerinden gidelim.
‫Bunlardan ilki daha önce kullandığımız gibi bir Dağıtımdır.
‫Dağıtım oluşturun.
‫Sonuna --dry-run eklediğimi fark edeceksiniz.
‫Sadece kuru bir çalışma yaparsanız, yalnızca oluşturacağı
‫kaynak türünü tükürecektir.
‫Bu, kubectl get komutuyla listelediğimizde
‫gördüğümüz kaynağın adına benzer.
‫Eğer yukarı oka basar ve sonuna -o yaml yazarsam,
‫bana bu komutla oluşturduğu
‫YAML çıktısını gösterecektir.
‫YAML özelliklerini daha sonra
‫inceleyeceğiz. Şimdilik, create deployment
‫komutunu verdiğimizde arka planda yapılanların önemli kısımlarını görebilirsiniz.
‫İlk olarak, API sürümünü, bu kaynak türünün sürümünü
‫gösterir.
‫Yani, burada bir apps/v1 sürümü kullanıyoruz.
‫Tür,
‫dağıtımdır ve bunun nedeni bir Dağıtım oluşturuyor olmamızdır.
‫Eğer bu bir işse, iş demekti.
‫Eğer bir Hizmet olsaydı, hizmet yazardı.
‫Bu tür şeyler. Meta veriler, oluşturduğunuz
‫herhangi bir kaynak için her zaman orada olacaktır.
‫İsteğe bağlı olan zaman damgasına sahip olacaktır, çünkü bu şeyi
‫gerçekten oluşturduğunuzda bunu otomatik
‫olarak oluşturacaktır. Ardından etiketleriniz ve burada
‫belirtebileceğiniz bir ad özelliğiniz olacak.
‫Bu durumda, bunların çoğunu komut satırında verdiğim
‫bilgilerle doldurduğunu görüyorsunuz.
‫Ona test demek istediğimi söyledim.
‫Yani, ona bir test adı veriyor.
‫Burada bir Dağıtım kullandığımız için ona bir uygulama atıyor,
‫onu bir hizmet veya başka bir şey değil, bir uygulama olarak
‫görüyor. Buna etiket testi deniyor.
‫Bunlar sadece kutudan çıkan varsayılan değerlerdir.
‫O halde Dağıtım için teknik özellikler bir
‫tanesinin kopyasıdır.
‫Seçiciye daha sonra değineceğiz, ancak bu şey
‫esasen bu Dağıtım içindeki podları nasıl seçeceğini
‫belirler. Temel olarak bu Dağıtım'ı
‫kapsülleriyle eşleştiren şeydir.
‫O zaman strateji. Boş bıraktığımız.
‫Buradaki şablon ReplicaSet içindir.
‫Daha sonra bu spesifikasyonun altında oluşturacağı konteynerleri
‫göreceksiniz. Yani, burada biraz iç içe geçmiş
‫bir spesifikasyon katmanı var. Bunun nedeni bu katmanların karmaşıklığı,
‫değil mi? Pod'larımız, ardından ReplicaSet'lerimiz ve bunun
‫üzerinde de Deployment'larımız var.
‫Tüm bunları anında oluşturduğunu görebilirsiniz
‫ve bu komutu verdiğimizde bunu API'ye uygulayacağız.
‫Burada birkaç tane daha yaratalım. İkincisi, Dağıtımlar yerine
‫İşler kullanmaktır. Genellikle bir kez çalışacak
‫bir dizi pod oluşturmak istediğinizde tasarlanır.
‫Bunları varsayılan olarak yeniden başlatılmayacak şekilde ayarlama eğilimindedir.
‫Bu durumda aynı görüntüyü, aynı isimle
‫kullanacağız. -output yaml ile kuru
‫çalıştırma yapacağız. Ne kadar farklı olduğunu göreceksiniz.
‫Bu durumda, ReplicaSet'in iç içe geçtiği bir Deployment'ın
‫çoklu seviyelerine sahip olmadığımız için, çoklu spec
‫seviyelerine ihtiyacımız yoktur.
‫Öncelikle bunun çok daha kısa olduğunu göreceksiniz.
‫Bunun nedeni büyük ölçüde, Dağıtımlar ile iç içe geçmiş
‫bir ReplicaSet oluşturması ve ardından pod
‫oluşturmasıdır. Yani burada birden fazla seviye var.
‫Burada, doğrudan bizim için podlar oluşturan
‫bu toplu işimiz var.
‫En üstte API sürümünün ve türünün değiştiğini görebilirsiniz.
‫Meta veriler çok benzerdir, ancak bu durumda bir
‫uygulama etiketi oluşturmamıştır.
‫Spesifikasyon sadece İşler içindir ve daha sonra onun altındaki
‫spesifikasyon, bu şablonun içinde, her
‫bir konteyner podunun spesifikasyonudur,
‫doğru.
‫Bu tek spesifikasyon, oluşturmasını istediğim sayı kadar
‫oluşturulacaktı.
‫Varsayılan olarak yalnızca bir tane oluşturduk.
‫Yani, test adıyla Nginx çalıştıran bir konteynere
‫sahip olacak. Yeniden başlatma politikasının asla
‫olmadığını fark edeceksiniz. Kubernetes'te kapsayıcı
‫oluşturmanın diğer yollarının çoğunda değişiklik
‫budur. Otomatik olarak yeniden oluşturmayı veya yeniden başlatmayı
‫deneyeceklerdir. Bir işle veya daha
‫sonra bir cron işiyle, yeniden başlatma politikasının asla olarak
‫ayarlandığını göreceksiniz. Çünkü genellikle bir iş bittiğinde,
‫sadece bitmiştir ve konteynerin onu yeniden oluşturmasını
‫istemezsiniz. Son olarak, bir açığa çıkarma komutu yapalım.
‫Burada bir kuru çalışma olsa da, dağıtımı açığa çıkardığınızda,
‫bu dağıtımı kontrol edecek ve mevcut olmadığını
‫fark edecektir, bu nedenle size örnek çıktıyı
‫veremez çünkü gerçekten geçerli girdiye sahip değildir.
‫Bu durumda, teknik olarak bir Deployment oluşturmamız gerekir.
‫Bunda, kuru çalışma ve çıktı olmasına ihtiyacımız
‫yok. Biz sadece yaratmasını istiyoruz.
‫Hadi yapalım şunu.
‫Ardından, bu açığa çıkarma komutuna geri dönelim ve
‫tekrar deneyelim. O zaman o kuru çalışma
‫bu sefer işe yarayacaktır. V1'in bir API sürümüne sahip olacağız.
‫Artık Dağıtım veya İş yerine Hizmetin tür olduğunu
‫fark edeceksiniz.
‫Sonra, benzer başka etiketlerimiz de var.
‫Spesifikasyonun tamamen portlar ve protokollerle ilgili olduğunu göreceksiniz,
‫çünkü bir Hizmet gerçekten budur.
‫Ağ rotalarının ve IP alt ağlarının, TCP veya UDP portlarının
‫ve bunun gibi şeylerin birleşimidir.
‫Jeneratörler
‫çok büyük bir mesele değildir. Bunları ezberlemenize veya hepsi arasındaki
‫farkları öğrenmenize gerek yok. Çünkü birazdan göreceğiniz
‫gibi kubectl run komutu ile bunların birçoğu ortadan
‫kalkıyor. Daha sonraki bir derste,
‫konteyner oluşturma yöntemlerinden ve belki de üretim
‫iş yüklerinizde neden çok fazla çalıştırma ve oluşturma yöntemi
‫kullanmayacağınızdan bahsedeceğiz.
‫Açığa çıkarmayı test ettiğimiz son komutumuz için oluşturduysanız
‫test dağıtımını silmeyi unutmayın.