‫Kubernetes'e neden ihtiyaç duyabileceğinizden bahsedelim.
‫Şimdi bir gözden geçirme olarak, önceki
‫bölümlere geri dönün. Swarm için ilk bölüm ve Swarm Mode
‫Built-in Orchestration başlıklı bir ders var.
‫Bu size orkestrasyonun çözdüğü sorunlar ve neden
‫buna ihtiyaç duyabileceğiniz hakkında bazı temel
‫bilgiler verir. İlk olarak, uygulamalarınızı
‫dağıtmak için hangi orkestrasyon avantajlarına
‫ihtiyaç duyacağınızı ve başlangıçta orkestrasyona ihtiyacınız
‫olup olmadığını anlamanızın kesinlikle önemli
‫olduğunu vurgulayacağım.
‫Orkestrasyonun popülaritesi kesinlikle artıyor, ancak konteynerleri
‫çalıştırmanın tek yolu bu değil.
‫Burada Docker çalıştırmalarını kullanmaktan bahsetmiştik.
‫Docker Compose hakkında konuştuk.
‫Diğer platform teklifleri ve hizmetleri hakkında konuştuk.
‫Hala AWS'deki tek düğümlerde orkestrasyon
‫olmadan konteyner çalıştıran müşterilerim
‫var. Bu platformun özelliklerini,
‫otomatik ölçeklendirme grupları, Elastik Yük Dengeleme ve uygulama
‫dağıtımlarımızı yönetmek için on yıldan uzun bir süredir
‫kullandığımız diğer birçok şeyi kullandıkları
‫orkestrasyon gibi benzer bir soyutlama oluşturmak için kullanırlar.
‫O kadar rafine bir sistemleri var ki, tüm bunları tamamen
‫orkestrasyona dönüştürmenin çok fazla faydasını görmüyorlar.
‫Şimdi, çoğumuz eninde sonunda bir çeşit
‫konteyner düzenlemesi kullanacağız çünkü bence sektörün
‫gidişatı bu yönde ve bunların hepsi Docker'ın ya
‫da bu kurs boyunca öğrendiğiniz başka bir çalışma
‫zamanının üzerinde çalışan ekstra katmanlar
‫olacak.
‫Orkestrasyonu kullanıp kullanmamak için kullandığım
‫basit formüllerden biri, belirli
‫bir ortam için ihtiyaç duyacağım sunucu
‫sayısını ve ardından uygulamalarımın veya ortamın
‫kendisinin değişim oranını almak ve bu ikisinin
‫çarpımı gerçekten orkestrasyonun faydasına eşittir.
‫Bununla kastettiğim şey, orkestrasyonun değişimi otomatikleştirmek
‫ve şeylerin durumunu izlemek ve
‫her şeyin olmasını beklediğiniz durumda olmasını sağlamak için
‫tasarlandığıdır.
‫Örneğin, sağlıklı bir durumda çalışan uygulamalar.
‫Başlangıç aşamasında yalnızca tek bir
‫sunucuya ya da yalnızca birkaç sunucuya ihtiyacınız
‫olabilir ve uygulamalarınızı çok sık değiştirmiyorsanız,
‫diyelim ki ayda bir ya da daha az değiştiriyorsanız, orkestrasyon
‫ve onu dağıtmak, yönetmek, güvenliğini sağlamak için harcanan
‫çaba sizin durumunuzda gereksiz olabilir.
‫Özellikle
‫de tek başına çalışan bir geliştiriciyseniz veya çok küçük bir ekibiniz varsa.
‫İşte bu noktada Elastic Beanstalk ya da uygulama
‫dağıtım platformu Heroku gibi şeyler, kendi
‫düzenlemenizi yapmanın alternatifi olarak
‫parlamaya başlıyor.
‫Tabii ki, orkestrasyona ihtiyaç duyduklarını
‫anladıktan sonra insanlardan aldığım en yaygın
‫soru, hangisini istediklerine karar vermektir.
‫Gerçekten de 2019'un bu noktasında
‫en az iki ya da üç büyük platform var.
‫Bulut çözümlerini de dahil ederseniz, dört ya da beş büyük platform
‫söz konusu olabilir.
‫Bu kursta bahsettiklerim her yerde işe yarayan
‫en iyi iki tanesidir. Bu Swarm ve Kubernetes.
‫Ardından, yalnızca AWS'de bulunan
‫ECS gibi Bulut platformlarına
‫özgü olanlar ve Cloud Foundry veya Mesos ve Marathon
‫gibi biraz daha uzun süredir var olan
‫daha geleneksel teklifler var.
‫Ancak bence konteynerleri şirket içinde ve
‫Bulutta ya da potansiyel olarak çoklu bulutta çalıştırmakla
‫ilgilenen biriyseniz ECS gibi Buluta özel teklifleri
‫tercih etmek istemeyebilirsiniz çünkü bunlar
‫Kubernetes'ten önce vardı.
‫Bu, Amazon'un hala desteklediği eski bir çözümdü
‫ve hala güzel bir seçenek, ancak yalnızca AWS'ye özgü
‫iseniz ve konteynerleri dağıtmayı planladığınız
‫tek yer orasıysa.
‫Müşterilerimin ve öğrencilerimin çoğu için seçimler genellikle
‫şu şekilde oluyor: Hibrit bir şeye ihtiyacım var.
‫Yani veri merkezimde veya çoklu bulutta
‫çalıştırabilirim. Sadece tek bir yerde
‫çalışamaz. Bu da genellikle Swarm veya Kubernetes'in
‫en büyük tercihleri olmasına neden oluyor çünkü bunlar
‫en popüler konteyner düzenleyicileri olan
‫iki çözüm.
‫Her bulutta, veri merkezlerinde ve hatta muhtemelen IoT
‫gibi küçük ortamlarda çalışırlar.
‫Orkestratörünüz olarak Kubernetes'e karar verirseniz,
‫bir sonraki büyük karar hangi dağıtımı kullanacağınızdır.
‫Bunun ilk kısmı, Bulut tarafından yönetilen bir çözüm
‫mü istediğinizi yoksa sunuculara kendiniz
‫kuracağınız bir satıcının ürünüyle kendi çözümünüzü mü
‫oluşturmak istediğinizi belirlemektir.
‫Docker Enterprise ve Red Hat'ten Rancher OpenShift gibi diğer dağıtımlar
‫da dahil olmak üzere satıcı tarafından desteklenen yaygın dağıtımlar
‫hakkında konuştuğumu duymuşsunuzdur.
‫Ubuntu
‫şirketi Canonical'ın kendi sürümü var.
‫VMware'in kendi sürümü vardır.
‫PKS de.
‫Aslında, Kubernetes için o kadar çok altyapı
‫ve yazılım şirketi satıcı çözümü var ki, bu
‫biraz bunaltıcı.
‫Kaynaklarda size Kubernetes sertifikalı dağıtımların bir listesinin
‫bağlantısını vereceğim.
‫Bunlardan birini kullanmak istersiniz çünkü Kubernetes'in
‫API'sinin doğrudan kullanıldığını ve tamamen desteklendiğini
‫garanti ederler.
‫Böylece ideal durum, iş yüklerinizi ve altyapınızı
‫tasarlayan YAML dosyalarınızı alabilmeniz ve bunları bir
‫Kubernetes satıcısından diğerine taşıyabilmeniz
‫ve çoğu şey için kutudan çıkar çıkmaz çalışmasıdır.
‫Şimdi burada bahsedeceğim başka bir seçenek daha
‫var, o da Kubernetes'in ham GitHub upstream sürümünü
‫kullanmak.
‫Tüm dağıtımlar buna dayanmaktadır.
‫Örneğin, yukarı akışa bakarsanız ve Kubernetes 1'i
‫görürseniz. 14 sürüm.
‫Ardından, bir satıcı ürününe baktığınızda, hangi
‫Kubernetes sürümlerini destekledikleriyle ilgilenirsiniz.
‫Genellikle, satıcı ürünleri birkaç sürüm geriden gelir, ancak
‫günümüzde yarış, hepsinin mümkün olduğunca
‫güncel kalmasıdır.
‫Bu nedenle, çoğu zaman sadece bir sürüm güncel olmadıklarını
‫görüyorum.
‫Şimdi, satıcı çözümlerinden elde ettiğiniz
‫şey, sadece o satıcının destek seçeneklerinin yanı sıra,
‫diğer araçları da onunla birlikte paketlemektir.
‫Kubernetes ile ilgili Swarm'dan biraz farklı
‫olan şeylerden biri, kullanıma hazır olarak kullanımını
‫gerçekten kolaylaştırmak için kendisine eklenen birçok şeye ihtiyaç
‫duymasıdır. Dolayısıyla, bir satıcı
‫çözümü aldığınızda muhtemelen özel kimlik doğrulama
‫çözümleri, özel Web yönetimi ve özel ağ oluşturma gibi şeyler
‫göreceksiniz.
‫Gereksinimlerinizi bilmeden size genellikle
‫GitHub'ın Kubernetes'inin saf yukarı
‫akış sürümüne ihtiyacınız olmadığını önereceğim.
‫Kubernetes deposunu klonlamanıza ve sadece bunu çalıştırmanıza
‫gerek yoktur.
‫Şimdi, öğrenmek için harika.
‫Aslında, Kubernetes'i öğrenmenin yolu olarak bununla
‫başlamanızı öneririm. Ancak, satıcı çözümlerine girdiğinizde,
‫bunların hepsi güvenlik, ağ ve diğer şeylerle
‫biraz farklı olacaktır.
‫Dolayısıyla, birini öğrenip diğerinin de aynı şekilde davrandığını
‫varsaymak sizin için zor olacaktır.
‫Ancak üretimden bahsetmeye başladığınızda, yönetilmesi daha
‫kolay olacağı için öncelikle bu satıcı çözümlerinden
‫birini kullanmayı denemenizi beklerdim.
‫Daha iyi destek seçeneklerine sahip olacaksınız.
‫Genel olarak, işler kutudan çıktığı haliyle daha iyi ve daha hızlı çalışacaktır.