‫Kubernetes veya Swarm.
‫Birisi orkestrasyon hakkında yeterince bilgi edindikten sonra hangisini
‫kullanacağına karar vermek istediğinde bana gelen en popüler sorulardan
‫biri bu.
‫Öncelikle Swarm'daki videoları, özellikle
‫de ilk videoyu izlemenizi tavsiye
‫ederim. Bu Swarm Mode
‫Built-in Orchestration'dır, çünkü yine bu size belirli
‫sorunları çözmek için orkestrasyonun neden gerekli olduğuna
‫dair arka planı verecektir. Ardından, devam etmeden önce
‫her iki aracın arka planını anlamak için bu bölümde
‫daha önce Kubernetes ile ilgili videoları da
‫izleyin. Burada temel olarak, bunların her ikisi
‫de benzer sorunları çözen araçlardır. Her ikisi de bir konteyner çalışma
‫zamanının üzerinde çalışan konteyner
‫orkestratörleridir.
‫Bu video serisinde Docker konteyner çalışma zamanı hakkında
‫bilgi edindiniz.
‫Artık başka konteynerler de var, konteynerd ve CRI-O.
‫Gerçekten, Docker 1 numara.
‫Neredeyse her vakada kullanılır.
‫Her ikisi de satıcılar ve ürünler üzerinde çalışan ekipler
‫tarafından desteklenmektedir.
‫Genel olarak, ikisini karşılaştırmak
‫için bir tweet atmam gerekseydi, Swarm'ın kurulumu kolay, düğüm eklemesi
‫kolay, başlatması kolay ve yönetmesi kolay
‫olurdu. Yani Swarm için söyleyebileceğim
‫tek şey kesinlikle kolay.
‫Ancak, Kubernetes'in çok daha fazla işlevselliğe,
‫esnekliğe ve özelleştirmeye sahip olduğu tüm kullanım
‫durumlarını çözmez. Daha fazla sorunu, daha fazla şekilde
‫çözebilir ve ayrıca genellikle daha geniş bir benimseme ve
‫desteğe sahiptir.
‫Sizin için, hangisini kullanmak istediğinize karar vermenize
‫yardımcı olmak amacıyla, her birinin avantajlarından bazı
‫mermileri inceleyeceğiz. DevOps topluluğunda yer alacaksanız
‫ve bu araçları iş sorunlarını çözmek için kullanacaksanız, her ikisini
‫de bilmenizin gerçekten hepimiz için önemli olduğunu
‫düşünüyorum.
‫Her ikisini de yükleyebilmeli ve ardından her ikisinde
‫de uygulamaları dağıtabilmeli ve uygulamaları
‫dağıtma, gelen trafik için Ingress seçenekleri oluşturma ve ardından
‫bu uygulamaları güncelleme ile ilgili bazı temel işlevleri
‫bilmelisiniz. Bence bu tek başına, hangi
‫problemleri çözmek için hangisini kullanacağınızı bilmeniz için
‫araçlara yeterince aşina olmanızı sağlayacaktır.
‫Her birinin birçok avantajı vardır.
‫Bunu hızlıca açıklayalım. Swarm tarafında, bu
‫kurs boyunca öğrendiğiniz gibi, Docker ile
‫birlikte gelir. Yani, satıcı destekli tek bir çözüm.
‫Bu da konteyner çalışma zamanının ve orkestratörün aynı şirket
‫tarafından oluşturulduğu anlamına geliyor.
‫Bu, daha az karmaşıklık, sadece bu şeyi çalıştırmak için daha az kaynak kullanımı
‫dahil olmak üzere birçok ödül kazandırır.
‫Swarm'ı
‫çalıştırmak Docker'ın üzerinde çok az kaynak kullanımına sahiptir.
‫Geliştirici iş akışı göz önünde bulundurularak
‫tasarlanmıştır. Bu nedenle, Operasyon ve geliştiricilerin
‫kullanması için çok iyi. Dediğim gibi, bu tür bir orkestratörü
‫dağıtmak ve yönetmek kolaydır.
‫Binlerce olmasa da yüzlerce düğüme kadar kolayca büyüyebilir
‫ve bunu yönetmek için mutlaka büyük bir ekibe ihtiyacınız
‫olmayacaktır. Kubernetes'in
‫özelliklerinin %20'sine sahip olduğu ve konteyner
‫çalıştırma ve düzenleme kullanım durumlarının %80'ini
‫çözdüğü 80/20 kuralını izlediğini söyleyebilirsiniz.
‫Şimdi, bu bilimsel bir karşılaştırma değil.
‫Tam özellik numarasını gerçekten bilmiyorum. Bunu nasıl yapacağını
‫bile bilmiyorum.
‫Ancak, her ikisini de çalıştırdığınızda, Swarm'ın ister Bulutta ister
‫veri merkezinde, hatta küçük cihazlarda olsun, sunucularda
‫uzun süre çalışan web uygulamalarını çalıştırmak için kullanım
‫durumlarının çoğunu çözdüğünü fark ediyorsunuz.
‫Kutudan
‫çıktığı haliyle iyi çalışıyor gibi görünüyor. İhtiyacınız olan her şey var. Ağ bağlantısı
‫var. Ingress var. Şifreleme var.
‫Bütün o şeyler. Veri tabanı var.
‫Yani, kullanıma hazır olarak, gerçekten pek çok sorunu çözüyor.
‫Ancak, bir uygulamayı bir makinede çalıştırmak için tüm senaryolar için tüm kullanım
‫durumlarını çözmez.
‫Kubernetes bu boşluğu doldurabilir.
‫Bunun bir diğer büyük avantajı da Docker'ın çalıştığı
‫her yerde çalışmasıdır. Docker Engine, şu anda altı yaşında
‫ve tüm bu konteyner devriminin başlangıcı olan Engine,
‫diğer tüm araçlardan daha fazla yerde çalışıyor.
‫Sadece Linux üzerinde değil, Windows üzerinde de çalışır.
‫Mainframe üzerinde çalışır.
‫ARM cihazlarında çalışır, bu da Gömülü,
‫IoT, Raspberry Pis anlamına gelir.
‫Eski ARM, yeni ARM, 32 bit, 64 bit üzerinde
‫çalışır. Dediğim gibi, her yerde var.
‫Server 2016'dan bu yana yıllardır Windows Server üzerinde
‫yerel olarak çalışmaktadır.
‫Bu nedenle, ihtiyaçlarınız buysa, çeşitli çok mimarili
‫bir ortam için kesinlikle en uzun süre desteklenen orkestratördür.
‫Kutudan çıkar çıkmaz güvenlidir ve bu kursta
‫bundan bahsettiğimi duydunuz, bir Swarm oluşturduğunuzda
‫ve düğümler eklediğinizde, karşılıklı Telus kimlik doğrulaması
‫sağlar. Kontrol düzlemini şifreler ve bunları saklamak
‫istemeniz durumunda sırlarınızı korumak için
‫veritabanını şifreler.
‫Bu harika bir şey çünkü birçok ekibin son teslim tarihlerine yetişmek için acele
‫ettiklerinde ya da karmaşıklıktan biraz
‫bunaldıklarında Kubernetes gibi diğer araçların gerektirdiği
‫bazı güvenlik gereksinimlerini unuttuklarını ya da atladıklarını görüyorum.
‫Son
‫olarak, daha az hareketli parça olduğu için sorun gidermenin daha kolay olduğuna
‫inanıyorum. Yönetecek daha az şey var.
‫Varsayılan olarak Docker'da yerleşik olduğundan, Docker sorunlarını nasıl
‫gidereceğinizi biliyorsanız, muhtemelen Swarm sorunlarını nasıl gidereceğinizi
‫de biliyorsunuzdur.
‫Aynı daemon günlüklerini kullanır. Uygulamalar için aynı Docker
‫logs komutunu kullanır. Düğümlerdeki ve Swarm'ın kendisindeki olaylara
‫bakmak için aynı Docker events komutunu kullanır.
‫Şimdi
‫bu bir Sürü için çok fazla avantaj gibi görünüyor, ancak bunun sizin için her
‫zaman doğru şey olacağını düşünmenizi istemiyorum.
‫Genel olarak Swarm, küçük çaplı bir başlangıç yapanlara
‫tavsiye ettiğim bir araç.
‫Belki tek bir kişidirler ya da ekiplerinde sadece bir,
‫iki veya üç kişi vardır ve küçük, basit bir orkestratörün
‫kendileri için işe yarayıp yaramayacağını görmeleri
‫gerekir. Kubernetes kullanmak zorunda
‫olduğunuzu kesinlikle bilmiyorsanız, her zaman önce
‫Swarm'ı öneririm. Swarm'da bazı sınırlara ulaştığınızı
‫ve ihtiyacınız olanı tam olarak elde edemediğinizi düşündüğünüzde,
‫Kubernetes'e bakmanın zamanı gelmiş
‫demektir.
‫Şimdi bu avantajlardan bazılarından bahsedelim.
‫İlk olarak, bulutlar ve satıcılar Kubernetes'i desteklemeyi
‫gerçekten çok seviyor. Bu kadar popüler hale geldiğinden
‫ve özellikle haberlerde ve medyada zeitgeist türü bir popülerlik
‫olduğundan, artık her tedarikçinin Kubernetes'i
‫destekliyoruz listesinde işaretlemek istediği bir
‫şey.
‫Bu nedenle, kesinlikle en geniş bulut ve satıcı desteğine sahip olduğunu
‫söyleyebilirim.
‫Her bulut sağlayıcısı Kubernetes için bir teklif sunar, bu nedenle kendiniz
‫çalıştırmak istemiyorsanız, tüm sistemleri başlatmalarına izin
‫verebilir ve ardından Kubernetes dağıtım dosyalarını
‫kullanarak uygulamalarınızı orada çalıştırabilirsiniz.
‫VMware,
‫Red Hat gibi altyapı sağlayıcılarının bile artık kendi Kubernetes dağıtımları
‫var. Geleneksel olarak sadece
‫bir depolama tedarikçisi olan Netflix gibi şirketler bile Kubernetes'in
‫kendi onaylı sürümüne veya dağıtımına sahiptir.
‫Dolayısıyla burada bariz olan şey, en geniş benimseme ve desteğe
‫sahip olması gibi görünüyor ve bu kesinlikle doğru.
‫Ancak bunun ötesinde, desteklenen en geniş kullanım alanı setine
‫de sahiptir. Değiştirilecek
‫ve kurcalanacak çok daha fazla şey ve çok sayıda farklı özellik
‫ve üçüncü taraf seçeneği olduğundan, Swarm'a
‫göre kesinlikle daha fazla uç durumu kapsıyor.
‫Aslında,
‫bunu muhtemelen bugün zaten birlikte çalıştığınız satıcılarda
‫görmeye başlayacaksınız; önce Kubernetes'i destekleyecekler,
‫bu da benim satıcıların Docker'ın Swarm ürününe bakmaya zahmet etmeden önce
‫Kubernetes'i kendi ürünleriyle nasıl destekleyebileceklerine bakacaklarını söyleme şeklim.
‫Özellikle de endüstri, her şeyin Kubernetes'i desteklemesi gerektiği
‫gibi bir tutum içinde olduğundan, halihazırda
‫sahip olduğunuz satıcıların, araçlarını Kubernetes üzerinde çalıştırmak
‫için zaten bir dağıtıma veya çözüme sahip olabileceğini göreceksiniz.
‫Örneğin,
‫CloudBees şirketinden Jenkins ile.
‫Kurumsal çözümlerini satın aldıysanız, size Kubernetes araçlarını
‫ve nasıl çalıştırılacağına dair örnekleri veriyorlar.
‫Bu, Jenkins'i Swarm üzerinde çalıştıramayacağınız anlamına gelmez.
‫Orada harika çalışıyor.
‫Bu sadece satıcıdan bu konuda daha iyi destek alacağınız
‫anlamına gelir.
‫Burada bahsedeceğim son avantaj biraz
‫garip bir avantaj. IBM'i satın aldığı için kimsenin kovulmadığına
‫dair bu terimi ortaya atacağım.
‫Bu söz onlarca yıl önce IBM'in en büyük bilgi işlem
‫tedarikçisi olduğu ve donanımınızı, ana bilgisayarlarınızı
‫ve PC'lerinizi dışarıdan temin ettiği ve pazarda gerçekten
‫de ortalığı kasıp kavurduğu zamanlarda popülerdi.
‫Esasen, hangi tedarikçi ile çalışmak istediğinize
‫karar veremediyseniz. Eğer sadece güvenli yoldan
‫gitseydiniz, IBM ile çalışıyor olurdunuz.
‫Bunun için asla kovulmazdınız çünkü o zamanın
‫güvenilir tedarikçisiydi.
‫Genel olarak Kubernetes platformu için artık
‫durumun böyle olduğunu söyleyebilirim.
‫Hatta CIO'lar ve CTO'lar için bir kontrol maddesi olma
‫noktasına geldiğini iddia edebilirim.
‫Bu hem iyi hem de kötü olabilir, çünkü henüz teknik
‫gereksinimleriniz olmasa bile Kubernetes'i çalıştırmanız
‫söylenebilir.
‫Yönetiminiz tarafından Kubernetes'i çalıştırmamız
‫gerektiği söyleniyor. Bu, onlar için teknik gereksinimlerin
‫veya faydaların ne olduğuna bakmaksızın veya farklı platformlarla karşılaştırmaksızın
‫çalıştırmak istedikleri bir şey olabilir.
‫Bu, BT kararlarının her zaman yalnızca teknik değerlere
‫veya gereksinimlere göre alınmadığı bu politik dünyanın
‫açık bir parçasıdır.
‫Genellikle satın almanın kullanım kolaylığı
‫ile olabilir. Başka bir deyişle, zaten bir
‫tedarikçiniz varsa, daha kolay olduğu için başka bir tedarikçi yerine
‫onun ürününü kullanabilirsiniz.
‫Ya da ekibinizin arka plandaki deneyimi, geçmiş işlerinden
‫veya projelerinden daha iyi bir deneyime sahip olabilir.
‫Yani, bunu dağıtacaksınız çünkü birisi
‫bunu zaten biliyor. Ya da belki de satın alacaksınız çünkü
‫ne yazık ki yönetiminiz bir dergi okudu ya da internete baktı ve
‫internet onlara Kubernetes gibi belirli bir ürünü seçmeleri
‫gerektiğini söyledi.
‫Yani, size kullanmanızı söyledikleri şey bu.
‫Aslında, canlı atölye çalışmaları yaptığımda ve insanlara
‫çalıştırdıkları orkestratörü neden seçtiklerini sorduğumda,
‫onlardan aldığım en yaygın cevap, ne yazık ki, hala patronum bunu yapmamı
‫söyledi.
‫Bu nedenle, insanlar her zaman ne çalıştıracakları konusunda söz sahibi
‫olamıyorlar, bu yüzden ekibinizdeki en eğitimli kişi olmanız ve onlara
‫gerçek teknik gereksinimler konusunda yardımcı olabilmeniz ve en iyi kararı
‫vermenize yardımcı olabilmeniz için size her ikisinin de
‫araç ve özellikleri arasında iyi bir denge sağlamaya çalışıyorum.