Sanal makineler Kubernetes'in geleceği mi?
Kubernetes'in geleceği nerede? Bu makalenin yazarı sizin için tek tek analiz ediyor.
Yazar | Paul Czarkowski
Tercüman | Hilal Ay
Editör | Tu Min
Üretildi | CSDN (ID: CSDNNews)
Kristal küreye bakıyorum
Bu yılki kariyerim için Kubernetes çok önemli bir teknoloji ve gelecek yıl da aynı olacak. 2018'in sonunda burada cesur bir tahmin yapacağım. Sanal makineler Kubernetes'in geleceğidir, konteynerlerin değil.
Sanal makineler Kubernetes'in geleceğidir, konteynerlerin değil.
2018, Çin ay takviminde köpeğin yılıdır, ancak teknik alanda bu yıl Kubernetes yılıdır. Artık birçok kişi Kubernetes öğreniyor. Tüm CIO'lar bir "Kubernetes stratejisi" geliştirmek için çok çalışıyor (hala bir Kubernetes stratejisi geliştirmeye çalışıyorsanız, başlangıç çizgisini zaten kaybetmişsinizdir, ancak bu başka bir hikaye). Bazı kuruluşlar zaten Kubernetes üzerinde çok sayıda üretim iş yükü çalıştırmaktadır.
Başka bir deyişle, Kubernetes'in Gartner Hype Döngüsü'ne bakıldığında, her aşamada birçok insan var. Birçok insan hayal kırıklığının çukurunda ya da çaresizlik tuzağına düşüyor.
Wikipedia'dan resim, Yazar: Jeremykemp
Ben büyük bir kap hayranıyım ve kapların öldüğünü ima etmedim. Docker 2013'te bize Linux kapsayıcıları için bir sarmalayıcı getirerek uygulamaları oluşturmanın, paketlemenin, paylaşmanın ve dağıtmanın harika bir yolunu gösterdi. O zamanlar sürekli teslimatı zaten ciddiye alıyorduk, bu nedenle zamanlama daha uygun olamazdı. Bu konteyner modelleri, modern teslimat süreçlerinin yanı sıra PaaS ve sonraki CaaS platformları için çok uygundur.
Google'da çalışan mühendisler, teknik topluluğun nihayet kapsayıcılar için hazır olduğunu gördüler. Google uzunca bir süredir kapsayıcılar kullandı (az çok icat etti). Oluşturmaya başladıkları Kubernetes, Google'ın artık iyi bilinen kendi Borg platformunun yeniden tasarlanmasıdır ve Borg platformu topluluk tarafından oluşturulmuştur.
Büyük genel bulutların Kubernetes tabanlı platformlar (GKE, AKS, EKS) sağlaması uzun sürmedi. İçeriden öğrenenler ayrıca hızla Kubernetes tabanlı bir platform (Pivotal Container Service, Openshift, vb.) Kurdu.
Kırılgan "yumuşak" çok kiracılı
Hala çetrefilli bir sorunu çözmemiz gerekiyor ve bence bu, konteyner-çok kiracılığını ezmek için son damla olacak.
Linux kapsayıcıları, yalıtılmış sanal alanların (Solaris Bölgeleri veya FreeBSD Jails gibi) güvenliğini sağlamak için oluşturulmamıştır. Bunun yerine, temel işlem izolasyonu sağlamak için çekirdek yeteneklerini kullanan paylaşılan bir çekirdek modeline dayanırlar. Jessie Frazelle'in dediği gibi: "Bunlar gerçek kaplar değil."
İşleri daha karmaşık hale getirmek için, Kubernetes bileşenlerinin çoğu kiracıların varlığından habersizdir. Elbette ad alanları ve Pod güvenlik politikaları kiracı kavramına sahiptir, ancak API'nin kendisinin kiracılarla hiçbir ilgisi yoktur. Kubelet veya kube-proxy gibi dahili bileşenler de kiracıların varlığını bilmiyor. Bu, Kubernetes'in "yumuşak kiralama" modeline yol açtı.
Bu, soyut sızıntı anlamına gelir. Konteyner üzerine inşa edilen platform, konteyner yazılım kiralama özelliklerini her yönden devralır. "Sert" çok kiracılı sanal makineler üzerine inşa edilen platformların tümü "sabit kiralamaları" (VMware, Amazon Web Services, OpenStack, vb.) Devralır.
Kubesprawl çevremdeki her şeyi yönetiyor
Kubernetes'in yumuşak kiralama modeli, servis sağlayıcıları ve yayıncıları tuhaf bir duruma sokar. Kubernetes kümesinin kendisi bir "zorunlu kiralama" dır. Çeşitli nedenlerle (aynı kuruluş içinde bile), kullanıcıların (veya uygulamaların) "kesin kiralamaları" sürdürmesi gerekir. Genel bulut, tam olarak yönetilen bir hizmet olarak Kubernetes ürünü sağladığından, her kiracı kendi kümesini kolayca edinebilir ve küme sınırını bir izolasyon noktası olarak kullanabilir.
Bazı Kubernetes yayıncıları (Pivotal Container Service, PKS gibi) bu kiralama sorununun farkındadır ve genel bulutla aynı hizmet olarak Kubernetes deneyimini sağlamak için benzer bir modeli benimsemiştir, ancak kendi veri merkezlerinde uygulanmıştır.
Bu, "büyük bir paylaşılan küme" yerine "birçok küme" modelinin ortaya çıkmasına yol açtı. Google GKE hizmetlerinin müşterilerinin birden çok ekip için düzinelerce Kubernetes kümesi dağıtması alışılmadık bir durum değildir. Genellikle her geliştirici kendi kümesini alır. Bu davranış, şaşırtıcı miktarda Kubesprawl oluşturabilir.
Kendi veri merkezlerinde Kubernetes kümeleri (yukarı akış tabanlı veya dağıtım tabanlı) çalıştıran Kubernetes operatörleri, çok sayıda kümeyi kendi başlarına yönetme ek işini üstlenmeyi seçebilir veya bir veya iki büyük küme üzerinde doğrudan yumuşak kiralamaları kabul edebilir.
"Bu tür davranışlar, şaşırtıcı miktarda Kubesprawl oluşturur."
Genellikle, alabileceğiniz en küçük küme 4 bilgisayardır (veya sanal makinedir). Bir (yüksek kullanılabilirlik için 3) Kubernetes Master için ve üçü Kubernetes Worker içindir. Dolayısıyla, sistemin çoğu boşta olsa bile, çok büyük miktarda paraya mal olacak.
Bu yüzden Kubernetes'i bir şekilde zor kiralama modeline dönüştürmemiz gerekiyor. Kubernetes topluluğu bu ihtiyacın farkındadır ve çok kiracılı bir çalışma grubuna sahiptirler. Bu grup, bu sorunu çözmek için çok çalışıyor ve her modelin nasıl çözüleceğine dair birkaç önerisi ve önerisi var.
Jessie Frazelle bu konu hakkında bir makale yazdı (https://blog.jessfraz.com/post/hard-multi-tenancy-in-kubernetes/), bu makale harika çünkü o benden daha akıllı, " Sözlerini dinlemek on yıl okumaktan daha iyidir, bu yüzden ona da dikkat edebilirsiniz. Yukarıdaki makalesini okumadıysanız, durmanızı ve okumanızı öneririm.
Küçük sanal makinelerin hız optimizasyonu
Kata Containers, hafif sanal makinelerin standart bir uygulamasını oluşturmaya adanmış açık kaynaklı bir proje ve topluluktur.Bu sanal makine, konteynerler gibi hisseder ve çalışır, ancak iş yükü yalıtımı ve sanal makine güvenliği avantajları da sağlayabilir.
Jessie, Kata Kapsayıcıları gibi sanal makine kapsayıcı teknolojilerinin kullanılmasını önerir. Kata Kapsayıcıları, sanal makine düzeyinde yalıtımı birleştirir ve eylemleri ve yürütülmesi, kapsayıcılarla aynıdır. Bu şekilde Kubernetes, iç içe geçmiş bir sanal makine konteynerinde (temel IaaS tarafından sağlanan bir sanal makinede çalışan sanal makine konteyneri) çalışan kendi kiracı kümesini sağlayabilir (her ad alanının yalnızca bir kiracı olduğunu varsayıyoruz) Kubernetes sistem hizmeti.
Jessie Frazelle'nin "Kubernetes Hard Multi-tenant" adlı kitabından bir resim (https: // blo
Bu, Kubernetes çok kiracılı sorununa zarif bir çözümdür. Jessie ayrıca, Kubernetes'in iş yüklerini (Kapsüller) Kubernetes üzerinde çalıştırmak için iç içe geçmiş konteyner sanal makineleri kullandığını ve bu da kaynak kullanımını büyük ölçüde artırabileceğini öne sürdü.
Burada, yapılması gereken başka bir optimizasyon var, bu da temeldeki IaaS veya bulut sağlayıcısı için uygun bir yönetim programı oluşturmak. Sanal makine konteyneri IaaS tarafından sağlanan ilk soyutlama seviyesiyse, kaynak kullanımını daha da iyileştirebiliriz. Bir Kubernetes kümesini çalıştırmak için gereken minimum sanal makine sayısı bire düşürülür (yüksek kullanılabilirlik gerekiyorsa 3), yani "süper kullanıcılar" için Kubernetes kontrol düzlemini çalıştırmak için bir sanal makine kullanılır.
Çok kiracılı kaynak (maliyet) optimizasyonu
İki ad alanı ve her birinde çalışan birçok uygulama içeren bir Kubernetes dağıtımı kabaca aşağıdaki gibidir:
Not: Diğer bulut kiracılarının iş yükleri de aynı IaaS altyapısı üzerinde çalışıyor. Bunlar sanal makine konteynerleri olduğu için izolasyon seviyeleri geleneksel bulut sanal makinelerle aynıdır. Bu nedenle, minimum riskle aynı hiper yönetici üzerinde çalışabilirler.
Başlangıçta buluta konuşlandırılan altyapı sıfırdır, bu nedenle süper kullanıcının maliyeti sıfırdır.
Süper kullanıcı, bulut aracılığıyla Kubernetes kümesine bir istek gönderir. Bulut sağlayıcısı, ana Kubernetes API ve sistem hizmetlerini çalıştırmak için bir kapsayıcı sanal makine (yüksek kullanılabilirlik gerekiyorsa 3) oluşturur. Süper kullanıcılar, sistem ad alanında bölmeleri dağıtmayı seçebilir veya diğer kullanıcılara erişim hakları vermek için yeni bir ad alanı oluşturabilir.
Süper kullanıcı foo ve bar olmak üzere iki ad alanı oluşturur. Kubernetes, her ad alanının kontrol düzlemini (Kubernetes API ve sistem hizmetleri) çalıştırmak için buluttan iki sanal makine kapsayıcısı ister. Süper kullanıcılar, bazı iş yüklerini (Bölmeler) dağıtan her kullanıcıya bu ad alanlarına erişim yetkisi verir ve ilgili kontrol düzlemleri daha sonra her iş yükünü çalıştırmak için sanal makinelere istekler gönderir.
Bu sürecin tüm aşamalarında, süper kullanıcı yalnızca gerçekten tüketilen kaynaklar için ödeme yapar. Tüm bulut kullanıcılarına sunulan kaynaklar, bulut sağlayıcısına aittir.
Yeniden ziyaret
Bulut sağlayıcıları zaten bu yönde çalışıyor. Açık kaynak topluluğunda meydana gelen çeşitli durumlardan bazı ipuçları görebiliriz. (Amazon'un Fargate'i zaten gizlice hareket ediyor.)
En temsili olanı, kubelet gibi davranmak için tasarlanmış açık kaynaklı bir araç olan Virtual Kubelet'tir. Kubernetes'i diğer API'lere bağlar. Bu, Kubernetes'in bulutun kapsayıcı sanal makine planlayıcısı aracılığıyla kapsayıcı sanal makineleri istemesine olanak tanır.
Yukarıda bahsedilen Kata Container'lar, Amazon'dan Firecracker ve Google'dan gvisor gibi ortaya çıkan başka birçok sanal makine kapsayıcı teknolojisi vardır.
sonuç olarak
Kubernetes sabit kiralama modelini doğru bir şekilde geliştirerek Kubernetes başarısına ulaşabilirsiniz. Kubernetes iş yükünü her bir Pod'un tüketim maliyeti modelinden tamamen izole ederek iş yükünü Kubernetes üzerinde çalıştırmalıyız.
Genel bulutları kullanmayanlar için, altyapı sağlayıcısının kapasite yükü ile aynı tüketim modelini elde edemezsiniz (bu durumda kendiniz). Ancak yine de, kapasite talebini azaltabilecek yüksek kaynak kullanımının avantajlarından yararlanabilirsiniz.
Umarım VMware ve OpenStack bu sorunlara dikkat eder ve bize hipervizöre ve uygun Sanal Kubelet uygulamasına dayalı hafif sanal makine konteyner teknolojisi getirir.
Orijinal: https://tech.paulcz.net/blog/future-of-kubernetes-is-virtual-machines/
Yazar: Paul Czarkowski, IBM bulut geliştirme laboratuvarlarının teknik direktörü.
Bu makale bir CSDN çevirisidir. Yeniden yazdırmanız gerekirse, lütfen kaynağı belirtin.
