‫Tamam. Bu son birkaç derste Kubernetes'in
‫genişleyen tüm farklı alanlarını görmeye başladınız,
‫değil mi? Bunu Kubernetes'in
‫ikili dosyalarının ve temel altyapısının ortasındaki küçük
‫küre gibi düşünürseniz, halkalar
‫gittikçe büyüyor, değil mi?
‫Ingress
‫ve Operatör modeli ve özel kaynak tanımları ile.
‫Gittikçe büyüyor.
‫Şimdi sizinle bunun nasıl daha da büyüdüğü hakkında
‫konuşmak istiyorum. Aslında, bu muhtemelen biraz çılgınca
‫olduğu tek alan.
‫Bu, bu kaynaklar için YAML'nin nasıl dağıtılacağına
‫ilişkin görüşler alanındadır, değil mi?
‫Şimdiye kadar kubectl uygulamasını gördünüz.
‫Bu sizi başlatacak ve muhtemelen bir konteyner orkestratörünün
‫ilk dağıtımını yapmanızı sağlayacaktır, değil
‫mi? Sen... Swarm ya da Kubernetes
‫kullanıyor olsanız da, bu YAML'yi alacaksınız ve bir
‫reponuz olacak ve onu orada depolayacaksınız ve bu mantıklı olacaktır.
‫Bunu genişletmeye başladığınızda ve ekipleriniz, izinleriniz,
‫farklı izin türleriniz ve bir şeyleri
‫yönetmesi veya onaylaması gereken kişiler olduğunda,
‫her şey daha karmaşık hale gelir.
‫Uygulamalarınızı Kubernetes'te nasıl dağıtacağınıza
‫dair bu dünyada neler oldu ve bu temelde
‫bununla ilgili. Şu anda 60'ın üzerinde, aslında
‫80'e yakın proje olduğu gerçeğinden bahsedeceğiz, ancak
‫bunların çoğu artık gerçek proje değil ya da öldü veya
‫arşivlendi.
‫Ancak sadece uygulamalarınızı Kubernetes'e
‫dağıtmak için Kubernetes'in üzerine araç
‫eklemenin en az 60 yolu vardır.
‫Bir sürü görüş var, değil mi?
‫Bu noktada, bunu nasıl yapmanız gerektiğine dair görüşler
‫ortaya çıkmaya başlar. Jenkins X'ten Helm'e ve ötesine
‫kadar her şey. Tüm bu farklı şeyler
‫ve görüşler var, Kubernetes fikirlere dayalı
‫bir altyapı değil, bu yüzden insanlara uygulamalarını dağıtma ve
‫güncelleme sürecinde rehberlik edecek
‫fikirlere ihtiyacımız var.
‫Yani, herkeste bir tane var. Kubernetes'te bunun nasıl
‫yapılacağı hakkında bir şeyler okuduysanız, muhtemelen
‫Helm'i duymuşsunuzdur. Helm'den Kubernetes'e, Kubernetes'ten
‫konteynerlere. Helm, herkesin şablon oluşturmak
‫ve üçüncü taraf uygulamaları
‫dağıtmak ya da kendi özel Helm grafiklerini oluşturmak
‫için şablonlama standartlarını kullanmak istediği
‫fiili bir yoldur.
‫Bunlara çizelge deniyor.
‫Esasen şablonlaştırılmış bir YAML'dir, ancak Helm'in
‫sizin için Kubernetes kümenize girecek
‫olan YAML'yi oluşturmasına veya tükürmesine izin
‫verir. Ama bu tek görüş değil, doğru.
‫En azından son baktığımda 60'ın üzerinde olduğunu söyledim.
‫Aslında referans bağlantılarına koyduğum bir
‫Google Sheet var. Biraz eski, ancak bu farklı dağıtım
‫yöntemlerini bulabileceğiniz tüm yerlerin
‫bilinen son listesi. Docker'ın kendi görüşleri çok ilginç,
‫özellikle de Docker ekosistemine sıkı sıkıya bağlı olmak
‫istiyorsanız. Bu Kubernetes
‫üzerinde Compose.
‫Docker Desktop'a sahipseniz, bugün Kubernetes'i
‫etkinleştirebilirsiniz, ki bunu muhtemelen kursun bu bölümü için
‫zaten yapmışsınızdır. Docker stack deploy kullanabilir
‫ve Swarm'a gitmek yerine Kubernetes'e gönderebilirsiniz.
‫Docker stack deploy komutuna bakarsanız ve bunun yardımına
‫bakarsanız, kullanmak istediğiniz orkestratörü
‫belirtmek için bir seçenek olduğunu göreceksiniz.
‫Aslında,
‫Docker Desktop'ın ayarlarında, yığın dağıtım komutları için Kubernetes'i tercih etmesini veya
‫varsayılan olarak kullanmasını söyleyebilirsiniz.
‫Bu oldukça ilginç çünkü Compose YAML'nin Kubernetes YAML'den farklı
‫olduğunu düşünüyordum.
‫Kubernetes üzerinde Compose artık bunu yapıyor.
‫Esasen üçüncü taraf bir araçtır.
‫Docker'dan, Compose'un YAML'sinin, Compose formatının, Kubernetes formatının
‫YAML'sine nasıl dağıtılacağı veya yorumlanacağı veya teknik
‫olarak nasıl çevrileceği konusunda fikir sahibi olmanın
‫bir yoludur.
‫Bu nedenle, Kubernetes, Swarm ve genel olarak Docker
‫için kurumsal araç olarak Docker Enterprise'ı düşünen
‫biriyseniz, gidip kontrol etmeniz için buraya bir bağlantı
‫koydum.
‫O zaman, bunu kesinlikle kontrol etmelisiniz çünkü kutudan çıktığı
‫gibi geliyor. Bu özelliğin güzel yanlarından
‫biri de iş akışının son derece basit kalması.
‫Temel
‫olarak, Compose YAML'nizi tüm boru hattı boyunca kullanıyorsunuz ve bunu Ops ve Dev'de
‫kullanabilirsiniz. Sizi şöyle demeye zorlamaz:
‫Tamam, geliştiriciler için Compose için YAML'ye sahip olmalısınız
‫ve üretim ve sunucular için bu Kubernetes YAML'ye sahip olmalısınız
‫ve bunlar uyumlu değil, doğru.
‫Docker ile ilgili fikir, bunun çok karmaşık olduğunu düşünmeleriydi.
‫Basitleştirelim.
‫Tüm kontrol hattı için tek bir YAML standardı
‫kullanalım.
‫Ve bunu sevdim. Bununla ilgili sorun,
‫Kubernetes'in yapabileceği her şeyi desteklememesidir,
‫doğru. Açıkçası, Docker Docs'ta
‫bir Compose dosyasının tüm özelliklerini listeleyen
‫tek bir sayfamız var. Ancak Kubernetes YAML o kadar
‫karmaşık ki birden fazla komuta, API referanslarına ve diğer
‫her şeye girmemiz gerekiyor, değil mi?
‫Açıkça görülüyor ki, her şeyi yapması mümkün değil.
‫Compose for Kubernetes web sitesinde güzel olan şey,
‫GitHub'da desteklediği farklı özellikler hakkında
‫konuşmaları.
‫Bu 80/20 kuralı.
‫Başka bir deyişle, yüzde 80'imizin muhtemelen ihtiyaç duyduğu
‫Kubernetes özelliklerinin yüzde 20'sini destekliyor.
‫Böylece, bununla başlayabilir ve bu iş akışının sizin için uygun olup
‫olmadığını görebilirsiniz. Bir başka güzel şey de 2018'in
‫sonlarında Compose on Kubernetes'in açık kaynağını oluşturdular,
‫böylece artık sahip olduğunuz herhangi bir Kubernetes altyapısına dağıtabilirsiniz
‫ve sadece bir tür yorumlayıcı olarak çalışır.
‫Docker'dan
‫Compose dosyasını kullandığınızda ve Docker komutlarını kullandığınızda,
‫Kubernetes kümenizi sizin için bağlayacak, bunu otomatik olarak Kubernetes
‫YAML'ye çevirecek ve gideceksiniz.
‫Aslında
‫bu noktada, uygulamalarınız için Kubernetes YAML'nin çoğunu görmezden
‫gelebilirsiniz. Belki de her gün dağıtmadığınız
‫altyapı işleri için Kubernetes YAML kullanıyorsunuzdur.
‫Ancak,
‫belki de geliştiricilerinizin Compose YAML yazmalarını kolaylaştırmak
‫ve işleri daha hızlı üretime almak için, iş akışı olarak Kubernetes üzerinde
‫Compose kullanmayı seçersiniz.
‫Sonra, belki de ana altyapınız için rakip bir standart
‫olan Helm grafiklerini kullanıyorsunuz.
‫Çünkü
‫Helm, kutudan çıktığı gibi bu grafik şablonlarının birçoğuyla birlikte
‫gelir, böylece belki Prometheus'u veya ELK ile Elasticsearch
‫günlüğünü ya da bunun gibi bir şeyi dağıtabilirsiniz.
‫Kutudan çıkar çıkmaz bu şablonlarla birlikte gelir
‫ve daha hızlı başlamanızı sağlar.
‫Ayrıca, bunların hepsinin isteğe bağlı olduğunu unutmayın, değil mi?
‫Kubernetes'i şimdiye kadar oynadığınız standart YAML
‫ile yapabilirsiniz ve bu iyi bir şeydir.
‫Bu diğer şeyleri gerektirmez.
‫Bunlar sadece isteğe bağlı üçüncü taraf araçlarıdır.
‫Geleneksel olarak, ekip büyüdükçe, birden fazla üretim
‫Kubernetes kümesine sahip olduğunuzda ve birden fazla
‫ekip dahil olduğunda, her şey zorlaşır ve muhtemelen birden
‫fazla çözümle sonuçlanırsınız.
‫Belirli kümelerde Helm ile karşılaşabilirsiniz.
‫Geliştiricileriniz için Kubernetes üzerinde Compose ya da buna benzer
‫bir şey elde edebilirsiniz.
‫Ya da ekosistemdeki diğer 60'tan fazla araçtan
‫biri.
‫Son olarak, Helm şu anda bu alanda gerçekten lider olduğu için,
‫neredeyse her dağıtım onu kullanıyor
‫veya destekliyor, hatta kutudan çıktığı gibi onunla birlikte
‫geliyor. Bu araçlara bakarken
‫büyük bir ortamda Helm'den kaçınamayacağınızı
‫göz önünde bulundurun.
‫Sadece kullanman gerekecek.
‫Bugünlerde güzel olan şey 3'te olması. 0 ve 3'te bunun için
‫çok daha basit dağıtım seçenekleri
‫var. 0'a karşı 1. 0 ve
‫2. 0. Bu yüzden işler her geçen gün
‫daha iyi ve daha kolay hale geliyor. Bu dağıtım araçlarının birçoğu
‫aslında YAML'nizi çeşitli şekillerde şablonlamanıza yardımcı
‫oluyor. Kubernetes'in kendisi
‫uzun süre boyunca gerçekten hiçbir şeye sahip değildi.
‫Son sürümlerde, şimdi K ile Kustomize
‫adında bir şey çıktı.
‫Bu kelimeyi K ile görmeye başladığınızda, bunun özel bir özellik
‫olduğunu bilirsiniz.
‫Helm ve diğer dağıtım çözümlerine benzer şeyler
‫yapmanıza olanak tanır, ancak Helm
‫kadar güçlü değildir,
‫doğru.
‫Yani, Helm hala lider.
‫Kustomize, bloğun yeni çocuğu sayılır, ancak Kubernetes'te yaptığınız
‫her şeyle birlikte kutudan çıkar çıkmaz gelir.
‫kubectl komutu bunu destekler.
‫Aslında bu sadece, şablonlu bir YAML
‫yerine, standart Kubernetes YAML olan YAML'yi alıyor
‫ve daha sonra bu dosyayı alıp üzerinde başka bir
‫şey çalıştırabilir ve bir tür geçersiz kılma
‫ile değiştirebilirsiniz.
‫Swarm'da yaptığımıza benzer bir şey.
‫Aslında Swarm ve Compose'da geçersiz kılma dosyalarımız
‫ve bunun gibi şeylerimiz var.
‫Artık bunu kutudan çıktığı gibi yapıyorlar.
‫Çok fazla özelliği var.
‫Bence Helm'in sahip olduğu özellik seti açısından aşağı yukarı
‫aynı seviyede değil ama en azından kutudan çıktığı
‫gibi geliyor.
‫Unutmayın, Docker'ınız varsa, en son
‫sürüm olan 19. 03 veya daha yeni Docker, artık
‫kendi Compose YAML şablonlamasını yapan ve Kubernetes için
‫bu özelleştirilmiş seçenekle gerçekten
‫çok karşılaştırılabilir olan docker app alt komutuna
‫sahiptir. Yine, Docker izini takip
‫edecekseniz ve Docker Enterprise'ı düşünecekseniz
‫veya Docker'ın geliştirici iş akışına odaklanmasını gerçekten
‫seviyorsanız, docker app alt komutuna ve
‫ayrıca burada kaynaklara koyacağım docker app repo'ya bakın.
‫Çünkü Compose YAML'yi nasıl alabileceğiniz, ortam
‫değişkenleri ve diğer şeyler gibi şeyleri nasıl çıkarabileceğiniz
‫hakkında belgeleri var. Hepsini tek bir görüntü halinde paketleyin
‫ve ardından YAML'nizi görüntü olarak gönderin.
‫Bu da artık YAML'nizi sürümlendirebileceğiniz ve YAML'yi
‫aşağı çekmek ve ardından uzun komutlar yazmak zorunda
‫kalmadan tek bir satırla dağıtabileceğiniz anlamına gelir.
‫Bunu yapmak için oldukça ilginç bir yol.
‫CNAB standardı adı verilen yeni bir şey kullanıyor,
‫bu konuya burada girmeyeceğiz, ancak
‫bu CNAB'dir.
‫Docker ve Microsoft'un 2018 yılında yaptığı
‫bir duyuruydu.
‫Tüm bunları Docker uygulamasının web sitesindeki kaynaklardan
‫kontrol edebilirsiniz. Yine, tüm bu şeyler, siz büyüdükçe
‫ekibinizin işini kolaylaştırmak için varsayılan YAML'yi özelleştirmenin
‫ve genişletmenin isteğe bağlı üçüncü taraf yollarıyla ilgilidir.