Kubernetes ile birden çok ortam (Hazırlık, Kalite Güvencesi, üretim vb.)

Birden çok ortamı (QA, Hazırlama, Üretim, Geliştirme vb.) Yönetmek için K8S ile iyi bir uygulama olarak kabul edilen nedir?

Örnek olarak, bir takımın bir ön uç uygulamayla birlikte birkaç API dağıtılmasını gerektiren bir ürün üzerinde çalıştığını varsayalım. Genellikle bu, en az 2 ortam gerektirir:

• Evreleme: İstemciye yayınlamadan önce yinelemeler / testler ve doğrulama için
• Üretim: Bu, müşterinin erişebildiği ortamdır. Kararlı ve iyi test edilmiş özellikler içermelidir.

Öyleyse, ekibin Kubernetes kullandığını varsayarsak, bu ortamları barındırmak için ne iyi bir uygulama olur? Şimdiye kadar iki seçeneği değerlendirdik:

1. Her ortam için bir K8s kümesi kullanın
2. Yalnızca bir K8 kümesi kullanın ve bunları farklı ad alanlarında tutun.

(1) Üretim ortamını tehlikeye atabilecek potansiyel insan hatası ve makine arızası risklerini en aza indirdiği için en güvenli seçenekler gibi görünüyor. Ancak bu, daha fazla ana makinenin maliyeti ve ayrıca daha fazla altyapı yönetimi maliyeti ile birlikte gelir.

(2) Altyapı ve dağıtım yönetimini basitleştiriyor gibi görünüyor çünkü tek bir küme var, ancak aşağıdaki gibi birkaç soruyu gündeme getiriyor:

• Bir insan hatasının üretim ortamını etkileyebileceğinden nasıl emin olunur?
• Hazırlama ortamındaki yüksek yükün üretim ortamında performans kaybına neden olmayacağından nasıl emin olunur?

Başka endişeler olabilir, bu yüzden insanların bu tür zorluklarla nasıl başa çıktıklarını daha iyi anlamak için StackOverflow'daki K8s topluluğuna ulaşıyorum.

Çoklu Kümelerde Dikkat Edilmesi Gerekenler

Vadim Eisenberg ( IBM / Istio ) tarafından yayınlanan şu blog gönderisine bir göz atın : Kontrol listesi: birden çok Kubernetes kümesi kullanmanın artıları ve eksileri ve bunlar arasında iş yüklerinin nasıl dağıtılacağı .

Bazı artıları / eksileri vurgulamak isterim:

Birden çok kümeye sahip olmanın nedenleri

• Üretim / geliştirme / test ayrımı: özellikle Kubernetes'in yeni bir sürümünü, bir hizmet ağının ve diğer küme yazılımlarının test edilmesi için
• Uyumluluk: Bazı düzenlemelere göre bazı uygulamaların ayrı kümelerde / ayrı VPN'lerde çalışması gerekir
• Güvenlik için daha iyi izolasyon
• Bulut / şirket içi: yükü şirket içi hizmetler arasında bölmek için

Tek bir kümeye sahip olmanın nedenleri

• Kurulum, bakım ve yönetim giderlerini azaltın
• Kullanımı iyileştirin
• Maliyet azaltma

Çok pahalı olmayan, ortalama bakım gerektiren ve yine de üretim uygulamaları için güvenlik izolasyonu sağlayan bir ortam düşünüldüğünde, şunları tavsiye ederim:

• DEV ve STAGING için 1 küme (ad alanlarıyla ayrılmış, hatta Calico'da olduğu gibi Ağ Politikaları kullanılarak izole edilmiş olabilir )
• PROD için 1 küme

Çevre Paritesi

Bu bir var iyi pratice mümkün olduğunca benzer geliştirme, evreleme ve üretim tutmak için:

Destek hizmetleri arasındaki farklılıklar, küçük uyumsuzlukların ortaya çıkması anlamına gelir, bu da kodun çalışmasına ve geliştirme veya aşamalandırmada testlerden geçmesine neden olarak üretimde başarısız olur. Bu tür hatalar, sürekli dağıtımı caydıran sürtüşme yaratır.

Güçlü bir CI / CD aletini dümenle birleştirin . Dümen değerlerinin esnekliğini kullanabilirsinizBir ortamdan diğerine farklılık gösteren yapılandırmaları geçersiz kılarak, varsayılan yapılandırmaları ayarlamak için .

AutoDevops ile GitLab CI / CD, halihazırda dümen desteğine sahip birden fazla Kubernetes kümesini yönetmenize olanak tanıyan Kubernetes ile güçlü bir entegrasyona sahiptir.

Birden çok kümeyi ( etkileşimleri) yönetmekubectl

Birden çok Kubernetes kümesiyle çalışırken, bağlamlarla uğraşmak kubectlve yanlış kümede çalıştırmak kolaydır . Bunun ötesinde, Kubernetes, istemci ( ) ve sunucu (kubernetes ana) arasında sürüm uyuşmazlığı için kısıtlamalara sahiptir kubectl, bu nedenle komutları doğru bağlamda çalıştırmak, doğru istemci sürümünü çalıştırmak anlamına gelmez.

Bunun üstesinden gelmek için:

• asdfBirden çok kubectlsürümü yönetmek için kullanın
• KUBECONFIGEnv değişkenini birden çok kubeconfigdosya arasında değişecek şekilde ayarlayın
• kube-ps1Mevcut bağlamınızı / ad alanınızı takip etmek için kullanın
• Kümeler / ad alanları arasında hızlı geçiş yapmak için kubectxvekubens kullanın
• Hepsini bir araya getirmek için takma adlar kullanın

Bunu nasıl başaracağımı örnekleyen bir makalem var: makalem var Birden çok Kubernetes kümesiyle farklı kubectl sürümleri kullanma

Ayrıca aşağıdaki okumaları da tavsiye ederim:

• Ahmet Alp Balkan'dan ( Google Mühendisi ) KUBECONFIG dosyasına hakim olmak
• Henning Jacobs'tan ( Zalando Tech ) Zalando 140+ Kubernetes Kümesini Nasıl Yönetiyor?

Aşama / üretim kümelerinizin güvenlik açısından kilitlenebilmesi için docker görüntüleri geliştirmek ve oluşturmak için kesinlikle ayrı bir küme kullanın. Ayrı kümeler kullanıp kullanmayacağınız staging + production, riske / maliyete göre karar vermek size bağlıdır - kesinlikle onları ayrı tutmak, stagingetkilemekten kaçınmanıza yardımcı olacaktır production.

Ayrıca, uygulamalarınızın sürümlerini ortamlarınız arasında tanıtmak için GitOps kullanmanızı şiddetle tavsiye ederim.

İnsan hatasını en aza indirmek için CI / CD'niz ve tanıtımınız için mümkün olduğunca otomatikleştirmeye de bakmanızı tavsiye ederim.

Burada , ortamlar arasında promosyon için GitOps ve GKE üzerinde canlı olarak yapılan Çekme İsteklerinde Önizleme Ortamları kullanılarak Kubernetes üzerinde birden çok ortamla CI / CD'nin nasıl otomatikleştirileceğinin bir demosu, ancak Jenkins X çoğu kubernetes kümesini destekler.

Senaryoların her birinde neyi test etmek istediğinize bağlıdır. Genel olarak, gereksiz yan etkilerden (performans etkisi, vb.) Kaçınmak için üretim kümesinde test senaryoları çalıştırmaktan kaçınmaya çalışırdım.

Niyetiniz, üretim sistemini tam olarak taklit eden bir aşamalandırma sistemi ile test yapmaksa , tam kümenin tam bir kopyasını çalıştırmanızı ve testi bitirdikten ve dağıtımları üretime taşıdıktan sonra kapatmanızı öneririm.

Amacınız, uygulamanın konuşlandırılmasını test etmeye izin veren bir aşamalandırma sistemini test etmekse, kalıcı olarak daha küçük bir hazırlama kümesi çalıştırır ve sürekli test için gerektiği şekilde dağıtımları (dağıtımların küçültülmüş bir sürümüyle) güncellerim.

Farklı kümeleri kontrol etmek için, kümenin bir parçası olmayan, ancak kümeleri ateşlemek ve kapatmak, ayrıca dağıtım çalışmaları yapmak, testleri başlatmak vb. İçin kullanılan ayrı bir ci / cd makinesine sahip olmayı tercih ediyorum. otomatik test senaryolarının parçası olarak kümeler.

Üretim kümesini aşamalandırmadan ayrı tutarak, üretim hizmetlerini etkileyen potansiyel hata riskinin azaldığı açıktır. Ancak bu, en azından aşağıdakileri gerektirdiği için daha fazla altyapı / konfigürasyon yönetimi maliyetiyle gelir:

• üretim kümesi için en az 3 ana bilgisayar ve aşamalandırma için en az bir ana makine
• CI / CD sistemine eklenecek 2 Kubectl yapılandırma dosyası

Birden fazla ortam olabileceğini de unutmayalım. Örneğin en az 3 ortamın olduğu şirketlerde çalıştım:

• QA: Bu, günlük dağıtımları yaptığımız ve müşteriye sunmadan önce dahili QA'mızı yaptığımız yer)
• İstemci QA: Bu, müşterinin üretime yayınlamadan önce ortamı doğrulayabilmesi için üretime dağıtmadan önce konuşlandırdığımız yer)
• Üretim: Bu, üretim hizmetlerinin uygulandığı yerdir.

Geçici / isteğe bağlı kümelerin mantıklı olduğunu düşünüyorum, ancak yalnızca belirli kullanım durumları için (yük / performans testi veya çok "büyük" entegrasyon / uçtan uca test), ancak daha kalıcı / yapışkan ortamlar için azaltılabilecek bir ek yük görüyorum bunları tek bir küme içinde çalıştırarak.

Sanırım anlattıklarıma benzer senaryolar için hangi kalıpların kullanıldığını görmek için k8s topluluğuna ulaşmak istedim.

Uyumluluk veya diğer gereksinimler aksini gerektirmedikçe, tüm ortamlar için tek bir kümeyi tercih ederim. Bu yaklaşımla dikkat edilecek noktalar şunlardır:

• Etiketleri kullanarak ortam başına düğümleri grupladığınızdan da emin olun. Daha sonra nodeSelector, belirli düğümlerde çalıştıklarından emin olmak için on kaynaklarını kullanabilirsiniz . Bu, ortamlar arasında (fazla) kaynak tüketiminin yayılma olasılığını azaltacaktır.

• Ad alanlarınızı alt ağlar olarak değerlendirin ve varsayılan olarak tüm çıkış / giriş trafiğini yasaklayın. Bkz. Https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

• Hizmet hesaplarını yönetmek için bir stratejiniz olsun. ClusterRoleBindingsbir küme birden fazla ortamı barındırıyorsa farklı bir anlama gelir.

• Helm gibi araçları kullanırken dikkatli olun. Bazı grafikler açık bir şekilde küme çapında izinlere sahip hizmet hesaplarını yükler, ancak hizmet hesaplarına yönelik izinlerin içinde bulundukları ortamla sınırlı olması gerekir.

Listede üretim ve "üretim dışı" arasında güçlü bir ayrım yapmak için birden fazla kümenin kullanılması bir normdur.

Bu ruhla GitLab 13.2'nin (Temmuz 2020) artık şunları içerdiğini unutmayın:

Core'da birden çok Kubernetes kümesi dağıtımı

GitLab ile birden çok Kubernetes kümesini dağıtmak için GitLab'i kullanmak, önceden bir Premium lisans gerektiriyordu.
Topluluğumuz konuştu ve dinledik: Birden çok kümeye dağıtmak, bireysel katkıda bulunanlar için bile yararlıdır.
Geri bildirimlerinize dayanarak, GitLab 13.2'den başlayarak, Core'da birden çok gruba ve proje kümesine dağıtabilirsiniz.

Belgelere ve soruna bakın /

Tek bir kümeyi çalıştırmanın mantıklı olduğunu düşünüyorum çünkü ek yükü, izlemeyi azaltır. Ancak, ağ politikalarını, erişim kontrolünü yerleştirdiğinizden emin olmalısınız.

Ağ ilkesi - geliştirme / qa ortamı iş yükünün üretim / hazırlama depolarıyla etkileşime girmesini engellemek için.

Erişim denetimi - ClusterRoles, Roles vb. Kullanarak farklı ortam kaynaklarına erişebilenler.