Kubernetes'in en popüler paket yöneticisi hakkındaki hikayenin özü bir emoji kullanılarak anlatılabilir:
- kutu Helm'dir (en son Emoji sürümüne en yakın olanıdır);
- kilit - güvenlik;
- küçük adam sorunun çözümüdür.
Aslında her şey biraz daha karmaşık olacak ve hikaye, teknik detaylarla dolu. Helm nasıl güvenli hale getirilir?.
- Bilmiyorsanız veya unuttuysanız kısaca Helm nedir? Hangi sorunları çözer ve ekosistemin neresinde yer alır?
- Helm mimarisine bakalım. Güvenlik ve bir aracın veya çözümün nasıl daha güvenli hale getirileceği hakkındaki hiçbir konuşma, bileşenin mimarisini anlamadan tamamlanmış sayılmaz.
- Helm bileşenlerini tartışalım.
- En yakıcı soru ise gelecek: Helm 3'ün yeni versiyonu.
Bu yazıdaki her şey Helm 2 için geçerlidir. Bu sürüm şu anda üretimdedir ve büyük ihtimalle şu anda kullanmakta olduğunuz sürümdür ve güvenlik risklerini içeren sürümdür.
Konuşmacı hakkında: Aleksandr Hayorov () 10 yıldır geliştiriliyor ve içeriğin iyileştirilmesine yardımcı oluyor ve komiteye katıldım . Şu anda Chainstack'ta geliştirme lideri olarak çalışıyor; bu, geliştirme yöneticisi ile son sürümlerin tesliminden sorumlu olan kişi arasındaki bir melezdir. Yani bir ürünün yaratılmasından işletilmesine kadar her şeyin gerçekleştiği savaş alanında bulunur.
Chainstack, misyonu müşterilerin merkezi olmayan uygulamaları çalıştırmanın altyapısını ve karmaşıklığını unutmasını sağlamak olan küçük, aktif olarak büyüyen bir girişimdir; geliştirme ekibi Singapur'da bulunmaktadır. Chainstack'tan kripto para satmasını veya satın almasını istemeyin, ancak kurumsal blockchain çerçeveleri hakkında konuşmayı teklif edin, size memnuniyetle cevap vereceklerdir.
Dümen
Bu, Kubernetes için bir paket (grafik) yöneticisidir. Uygulamaları Kubernetes kümesine taşımanın en sezgisel ve evrensel yolu.
Elbette kendi YAML manifestlerinizi oluşturmak ve küçük yardımcı programlar yazmaktan daha yapısal ve endüstriyel bir yaklaşımdan bahsediyoruz.
Helm şu anda mevcut ve popüler olanların en iyisidir.
Neden Helm? Öncelikle CNCF tarafından desteklendiği için. Cloud Native büyük bir kuruluştur ve Kubernetes, vb., Fluentd ve diğer projelerin ana şirketidir.
Bir diğer önemli gerçek ise Helm'in çok popüler bir proje olmasıdır. Ocak 2019'da Helm'i nasıl güvenli hale getireceğimi anlatmaya başladığımda projenin GitHub'da bin yıldızı vardı. Mayıs ayına gelindiğinde bunların sayısı 12 bindi.
Pek çok kişi Helm'e ilgi duyuyor, bu nedenle henüz kullanmasanız bile güvenliği hakkında bilgi sahibi olmanızın faydasını göreceksiniz. Güvenlik önemlidir.
Çekirdek Helm ekibi Microsoft Azure tarafından desteklenmektedir ve bu nedenle diğerlerinden farklı olarak oldukça istikrarlı bir projedir. Helm 3 Alpha 2'nin Temmuz ortasında piyasaya sürülmesi, proje üzerinde oldukça fazla insanın çalıştığını ve Helm'i geliştirme ve iyileştirme arzusuna ve enerjisine sahip olduklarını gösteriyor.
Helm, Kubernetes'teki uygulama yönetiminin çeşitli temel sorunlarını çözüyor.
- Uygulama paketleme. WordPress'teki "Merhaba Dünya" gibi bir uygulama bile zaten birkaç hizmetten oluşuyor ve siz bunları bir arada paketlemek istiyorsunuz.
- Bu uygulamaları yönetmenin getirdiği karmaşıklığı yönetmek.
- Uygulama yüklendikten veya dağıtıldıktan sonra bitmeyen bir yaşam döngüsü. Yaşamaya devam ediyor, güncellenmesi gerekiyor ve Helm de bu konuda yardımcı oluyor, bunun için doğru önlem ve politikaları getirmeye çalışıyor.
Torbalama net bir şekilde düzenlenmiştir: Linux, Windows veya MacOS için normal bir paket yöneticisinin çalışmasına tam uygun meta veriler vardır. Yani bir depo, çeşitli paketlere bağımlılıklar, uygulamalar için meta bilgiler, ayarlar, yapılandırma özellikleri, bilgi indeksleme vb. Helm, tüm bunları uygulamalar için almanıza ve kullanmanıza olanak tanır.
Karmaşıklık Yönetimi. Aynı türden çok sayıda uygulamanız varsa parametrelendirmeye ihtiyaç vardır. Şablonlar buradan gelir, ancak kendi şablon oluşturma yönteminizi bulmak zorunda kalmamak için Helm'in kutudan çıkan tekliflerini kullanabilirsiniz.
Uygulama Yaşam Döngüsü Yönetimi - bence bu en ilginç ve çözülmemiş soru. Bir zamanlar Helm'e bu yüzden geldim. Uygulama yaşam döngüsüne dikkat etmemiz gerekiyordu ve CI/CD ile uygulama döngülerimizi bu paradigmaya taşımak istedik.
Helm şunları yapmanızı sağlar:
- dağıtımları yönetmek, yapılandırma ve revizyon kavramını tanıtır;
- geri almayı başarıyla gerçekleştirin;
- farklı etkinlikler için kancalar kullanın;
- ek uygulama kontrolleri ekleyin ve sonuçlarına yanıt verin.
Dahası Dümenin “pilleri” var - Hayatınızı kolaylaştıran eklentiler biçiminde eklenebilecek çok sayıda lezzetli şey. Eklentiler bağımsız olarak yazılabilir, oldukça izoledirler ve uyumlu bir mimari gerektirmezler. Bir şeyi uygulamak istiyorsanız, bunu bir eklenti olarak yapmanızı ve ardından muhtemelen yukarı akışa dahil etmenizi öneririm.
Helm üç ana konsepte dayanmaktadır:
- Grafik Repo — bildiriminiz için mümkün olan parametrelendirmelerin açıklaması ve dizisi.
- Yapılandırma —yani uygulanacak değerler (metin, sayısal değerler vb.).
- Bırakın üstteki iki bileşeni toplar ve birlikte Release'e dönüşürler. Sürümler versiyonlandırılabilir, böylece düzenli bir yaşam döngüsü elde edilebilir: kurulum sırasında küçük, yükseltme, sürüm düşürme veya geri alma sırasında büyük.
Dümen mimarisi
Diyagram kavramsal olarak Helm'in üst düzey mimarisini göstermektedir.
Helm'in Kubernetes ile alakalı bir şey olduğunu hatırlatayım. Bu nedenle Kubernetes kümesi (dikdörtgen) olmadan yapamayız. Kube-apserver bileşeni ana sunucuda bulunur. Helm olmadan Kubeconfig'imiz var. Helm küçük bir ikili dosya getiriyor, eğer buna böyle diyebilirseniz, bir bilgisayara, dizüstü bilgisayara, ana bilgisayara - herhangi bir şeye yüklenen Helm CLI yardımcı programı.
Ancak bu yeterli değil. Helm'in Tiller adında bir sunucu bileşeni var. Helm'in küme içindeki çıkarlarını temsil eder; tıpkı diğerleri gibi Kubernetes kümesi içindeki bir uygulamadır.
Chart Repo'nun bir sonraki bileşeni grafiklerin bulunduğu bir depodur. Resmi bir depo vardır ve bir şirketin veya projenin özel bir deposu olabilir.
Etkileşim
Helm kullanarak bir uygulama yüklemek istediğimizde mimari bileşenlerin nasıl etkileşime girdiğine bakalım.
- Biz konuşuyoruz
Helm install, depoya (Grafik Repo) erişin ve bir Helm grafiği edinin.
- Helm yardımcı programı (Helm CLI), hangi kümeyle iletişim kurulacağını belirlemek için Kubeconfig ile etkileşime girer.
- Bu bilgiyi alan yardımcı program, uygulama olarak kümemizde bulunan Tiller'a başvurur.
- Tiller, Kubernetes'te eylemler gerçekleştirmek, bazı nesneler (hizmetler, bölmeler, kopyalar, sırlar vb.) oluşturmak için Kube-apiserver'ı çağırır.
Daha sonra, tüm Helm mimarisinin bir bütün olarak maruz kalabileceği saldırı vektörünü görmek için diyagramı karmaşıklaştıracağız. Sonra onu korumaya çalışacağız.
Saldırı vektör
İlk potansiyel zayıf nokta ayrıcalıklı API-kullanıcı. Planın bir parçası olarak bu kişi, Helm CLI'ye yönetici erişimi elde eden bir bilgisayar korsanıdır.
Ayrıcalıksız API kullanıcısı yakın bir yerde olması da tehlike oluşturabilir. Böyle bir kullanıcı farklı bir bağlama sahip olacaktır; örneğin, Kubeconfig ayarlarında bir küme ad alanına sabitlenebilir.
En ilginç saldırı vektörü, Tiller'ın yakınındaki bir kümede bulunan ve ona erişebilen bir süreç olabilir. Bu, kümenin ağ ortamını gören bir web sunucusu veya mikro hizmet olabilir.
Egzotik ama giderek daha popüler hale gelen bir saldırı çeşidi, Chart Repo'yu içerir. Vicdansız bir yazar tarafından oluşturulan bir çizelge, güvensiz kaynaklar içerebilir ve siz de onu inanarak tamamlayacaksınız. Veya resmi depodan indirdiğiniz grafiğin yerini alabilir ve örneğin politikalar şeklinde bir kaynak oluşturup erişimini artırabilir.
Bu dört taraftan gelen saldırıları savuşturmaya çalışalım ve Helm mimarisinde nerede sorun olduğunu, nerede sorun olmadığını bulalım.
Diyagramı genişletelim, daha fazla öğe ekleyelim, ancak tüm temel bileşenleri koruyalım.
Helm CLI, Chart Repo ile iletişim kurar, Kubeconfig ile etkileşime girer ve iş, kümedeki Tiller bileşenine aktarılır.
Tiller iki nesneyle temsil edilir:
- Belirli bir hizmeti ortaya çıkaran Tiller-dağıtım svc;
- Kümeye erişen tüm yükün üzerinde çalıştığı Tiller dağıtım bölmesi (diyagramda tek bir kopyada tek bir kopya halinde).
Etkileşim için farklı protokoller ve şemalar kullanılır. Güvenlik açısından en çok ilgilendiğimiz konular:
- Helm CLI'nin grafik deposuna erişme mekanizması: hangi protokol, kimlik doğrulama var mı ve bununla neler yapılabilir.
- Helm CLI'nin kubectl kullanarak Tiller ile iletişim kurmasını sağlayan protokol. Bu, kümenin içine kurulu bir RPC sunucusudur.
- Tiller'ın kendisine, kümede bulunan ve Kube-apserver'ıyla etkileşime giren mikro hizmetler erişebilir.
Tüm bu alanları sırasıyla tartışalım.
RBAC
RBAC etkinleştirilmediği sürece Helm veya küme içindeki herhangi bir hizmet için herhangi bir güvenlikten bahsetmenin bir anlamı yoktur.
Görünüşe göre bu en son öneri değil, ancak birçok kişinin üretimde bile RBAC'ı hala etkinleştirmediğinden eminim, çünkü bu çok fazla telaş ve birçok şeyin yapılandırılması gerekiyor. Ancak bunu yapmanızı tavsiye ederim.
— RBAC için web sitesi avukatı. RBAC'ı kurmanıza, neden iyi olduğunu ve üretimde onunla nasıl yaşayacağınızı göstermenize yardımcı olacak çok sayıda ilginç malzeme içerir.
Tiller ve RBAC'ın nasıl çalıştığını açıklamaya çalışacağım. Tiller, kümenin içinde belirli bir hizmet hesabı altında çalışır. Tipik olarak, eğer RBAC yapılandırılmamışsa bu, süper kullanıcı olacaktır. Temel konfigürasyonda Tiller yönetici olacaktır. Bu nedenle Tiller'ın kümenize giden bir SSH tüneli olduğu sıklıkla söylenir. Aslında bu doğrudur, dolayısıyla yukarıdaki şemada Varsayılan Hizmet Hesabı yerine ayrı bir özel hizmet hesabı kullanabilirsiniz.
Helm'i başlattığınızda ve sunucuya ilk kez yüklediğinizde, hizmet hesabını kullanarak ayarlayabilirsiniz. --service-account. Bu, gerekli minimum haklara sahip bir kullanıcıyı kullanmanıza olanak tanır. Doğru, böyle bir "çelenk" yaratmanız gerekecek: Rol ve RolBinding.
Maalesef Helm bunu senin için yapmayacak. Helm'i geçmek için sizin veya Kubernetes küme yöneticinizin hizmet hesabı için önceden bir dizi Rol ve RoleBinding hazırlamanız gerekir.
Şu soru ortaya çıkıyor: Rol ve ClusterRole arasındaki fark nedir? Aradaki fark, yalnızca özel bir ad alanı için çalışan normal Roles ve RoleBindings'in aksine, ClusterRole'un tüm ad alanları için çalışmasıdır. Kümenin tamamı ve tüm ad alanları için ilkeleri yapılandırabilir veya her ad alanı için ayrı ayrı kişiselleştirebilirsiniz.
RBAC'ın başka bir büyük sorunu çözdüğünü belirtmekte fayda var. Pek çok kişi Helm'in ne yazık ki çok kiracılı olmadığından (çoklu kiracılığı desteklemediğinden) şikayetçi. Birkaç ekip bir kümeyi tüketiyor ve Helm kullanıyorsa, bu küme içinde politikalar oluşturmak ve erişimlerini sınırlamak temelde imkansızdır çünkü Helm'in altında çalıştığı belirli bir hizmet hesabı vardır ve kümedeki tüm kaynakları onun altından oluşturur. ki bu bazen çok sakıncalıdır. Bu doğrudur; ikili dosyanın kendisi gibi, süreç gibi, Helm Tiller'ın çoklu kiracılık kavramı yok.
Ancak Tiller'ı bir kümede birden çok kez çalıştırmanıza olanak tanıyan harika bir yol var. Bunda bir sorun yok, Tiller her namespace'te başlatılabilir. Böylece RBAC, Kubeconfig'i bağlam olarak kullanabilir ve özel bir Helm'e erişimi sınırlayabilirsiniz.
Bunun gibi görünecek.
Örneğin, farklı ekipler için bağlama sahip iki Kubeconfig vardır (iki ad alanı): Geliştirme ekibi ve yönetici kümesi için X Team. Yönetici kümesinin, buna uygun olarak gelişmiş bir hizmet hesabı olan Kube sistemi ad alanında yer alan kendi geniş Tiller'ı vardır. Geliştirme ekibi için ayrı bir ad alanı sayesinde hizmetlerini özel bir ad alanına dağıtabilecekler.
Bu uygulanabilir bir yaklaşımdır, Tiller bütçenizi büyük ölçüde etkileyecek kadar güce aç değildir. Bu hızlı çözümlerden biridir.
Tiller'ı ayrı ayrı yapılandırmaktan ve Kubeconfig'e ekip, belirli bir geliştirici veya ortam için bağlam sağlamaktan çekinmeyin: Geliştirme, Hazırlama, Üretim (her şeyin aynı kümede olacağı şüphelidir, ancak bu yapılabilir).
Hikayemize devam ederek RBAC'tan geçip ConfigMaps'ten bahsedelim.
Yapılandırma Haritaları
Helm, ConfigMaps'i veri deposu olarak kullanıyor. Mimariden bahsettiğimizde sürümler, konfigürasyonlar, geri almalar vb. bilgileri saklayacak bir veritabanı hiçbir yerde yoktu. Bunun için ConfigMaps kullanılıyor.
ConfigMaps'le ilgili temel sorun biliniyor; prensip olarak güvenli değiller; hassas verileri saklamak imkansızdır. Şifreler gibi hizmetin ötesine geçmemesi gereken her şeyden bahsediyoruz. Şu anda Helm için en doğal yol, ConfigMaps'i kullanmaktan gizli dizilere geçiş yapmaktır.
Bu çok basit bir şekilde yapılır. Tiller ayarını geçersiz kılın ve depolamanın gizli kalacağını belirtin. Daha sonra her dağıtım için bir ConfigMap değil, bir sır alacaksınız.
Sırların tuhaf bir kavram olduğunu ve pek de güvenli olmadığını iddia edebilirsiniz. Ancak bunu Kubernetes geliştiricilerinin kendilerinin yaptığını anlamakta fayda var. 1.10 sürümünden başlayarak, yani. Uzun bir süredir, en azından genel bulutlarda, sırları saklamak için doğru depolamayı bağlamak mümkün. Ekip şu anda sırlara, bireysel bölmelere veya diğer varlıklara erişimi daha iyi dağıtmanın yolları üzerinde çalışıyor.
Depolama Helm'i sırlara aktarmak daha iyidir ve bunlar da merkezi olarak güvence altına alınır.
Elbette kalacak 1 MB veri depolama sınırı. Helm burada ConfigMaps için dağıtılmış depolama alanı olaraketcd'yi kullanıyor. Ve orada bunun çoğaltma vb. için uygun bir veri yığını olduğunu düşündüler. Reddit'te bununla ilgili ilginç bir tartışma var, hafta sonu için bu eğlenceli yazıyı bulmanızı veya alıntıyı okumanızı öneririm .
Grafik Repoları
Grafikler sosyal açıdan en savunmasız olanlardır ve özellikle hisse senedi çözümü kullanıyorsanız "Ortadaki Adam" kaynağı haline gelebilirler. Öncelikle HTTP üzerinden açığa çıkan depolardan bahsediyoruz.
Kesinlikle Helm Repo'yu HTTPS üzerinden açığa çıkarmanız gerekiyor - bu en iyi seçenektir ve ucuzdur.
Not grafik imza mekanizması. Teknoloji son derece basittir. Bu, genel ve özel anahtarlara sahip normal bir PGP makinesi olan GitHub'da kullandığınız şeyin aynısıdır. Kurulumu yapın ve gerekli anahtarlara sahip olduğunuzdan ve her şeyi imzaladığınızdan emin olun, bunun gerçekten sizin çizelgeniz olduğundan emin olun.
Buna ek olarak, Helm istemcisi TLS'yi destekliyor (sunucu tarafı HTTP anlamında değil, karşılıklı TLS anlamında). İletişim kurmak için sunucu ve istemci anahtarlarını kullanabilirsiniz. Doğrusunu söylemek gerekirse karşılıklı sertifikaları sevmediğim için böyle bir mekanizmayı kullanmıyorum. Temel olarak, - Helm 2 için Helm Repo'yu kurmaya yönelik ana araç - aynı zamanda temel kimlik doğrulamayı da destekler. Daha rahat ve sessiz olması durumunda temel kimlik doğrulamayı kullanabilirsiniz.
Ayrıca bir eklenti var , Google Bulut Depolama'da Grafik Depolarını barındırmanıza olanak tanır. Bu oldukça kullanışlıdır, harika çalışır ve oldukça güvenlidir çünkü açıklanan tüm mekanizmalar geri dönüştürülmüştür.
Riskleri daha da azaltmak için HTTPS veya TLS'yi etkinleştirir, mTLS kullanır ve temel kimlik doğrulamayı etkinleştirirseniz Helm CLI ve Chart Repo ile güvenli bir iletişim kanalına sahip olursunuz.
gRPC API'si
Bir sonraki adım çok önemlidir - kümede bulunan ve bir yandan sunucu olan Tiller'ın güvenliğini sağlamak, diğer yandan kendisi diğer bileşenlere erişir ve biri gibi davranmaya çalışır.
Daha önce de söylediğim gibi Tiller, gRPC'yi açığa çıkaran bir hizmettir, Helm istemcisi ona gRPC aracılığıyla gelir. Elbette varsayılan olarak TLS devre dışıdır. Bunun neden yapıldığı tartışmalı bir soru, bana başlangıçta kurulumu basitleştirmek gibi geliyor.
Üretim ve hatta hazırlama için gRPC'de TLS'yi etkinleştirmenizi öneririm.
Bana göre, grafikler için mTLS'den farklı olarak, bu burada uygundur ve çok basit bir şekilde yapılır - bir PQI altyapısı oluşturun, bir sertifika oluşturun, Tiller'ı başlatın, başlatma sırasında sertifikayı aktarın. Bundan sonra, oluşturulan sertifikayı ve özel anahtarı kendinize sunarak tüm Helm komutlarını çalıştırabilirsiniz.
Bu şekilde kendinizi Tiller'a küme dışından gelen tüm isteklerden koruyacaksınız.
Böylece, Tiller'a olan bağlantı kanalını güvence altına aldık, RBAC'yi zaten tartıştık ve Kubernetes apserverının haklarını ayarlayarak etkileşime girebileceği alanı azalttık.
Korumalı Miğfer
Son diyagrama bakalım. Aynı oklara sahip aynı mimari.
Artık tüm bağlantılar güvenli bir şekilde yeşil renkle çizilebilir:
- Chart Repo için TLS veya mTLS ve temel kimlik doğrulamayı kullanıyoruz;
- Tiller için mTLS ve TLS ile gRPC hizmeti olarak sunuluyor, sertifikaları kullanıyoruz;
- küme, Rol ve RoleBinding içeren özel bir hizmet hesabı kullanır.
Kümeyi önemli ölçüde güvence altına aldık, ancak akıllı biri şunları söyledi:
"Sadece tek bir tamamen güvenli çözüm olabilir; beton bir kutuya yerleştirilen ve askerler tarafından korunan, kapatılmış bir bilgisayar."
Verileri manipüle etmenin ve yeni saldırı vektörleri bulmanın farklı yolları vardır. Ancak bu önerilerin güvenlik açısından temel bir endüstri standardına ulaşacağına inanıyorum.
Bonus
Bu kısım doğrudan güvenlikle ilgili olmasa da işinize yarayacaktır. Size çok az insanın bildiği bazı ilginç şeyler göstereceğim. Örneğin, resmi ve resmi olmayan grafiklerin nasıl aranacağı.
Depoda Şimdi yaklaşık 300 grafik ve iki akış var: kararlı ve kuluçka makinesi. Katkıda bulunan herkes, kuluçka makinesinden ahıra ulaşmanın ne kadar zor olduğunu ve ahırdan uçmanın ne kadar kolay olduğunu çok iyi biliyor. Ancak bu, Prometheus ve istediğiniz başka her şey için grafik aramak için en iyi araç değildir; basit bir nedenden dolayı, paketleri rahatça arayabileceğiniz bir portal değildir.
Ama bir hizmet var , bu da grafikleri bulmayı çok daha kolay hale getirir. En önemlisi, çok daha fazla harici depo ve neredeyse 800 tılsım mevcut. Ayrıca, herhangi bir nedenle grafiklerinizi kararlı ortama göndermek istemiyorsanız deponuzu bağlayabilirsiniz.
hub.helm.sh'yi deneyin ve birlikte geliştirelim. Bu hizmet Helm projesi kapsamındadır ve bir ön uç geliştiriciyseniz ve yalnızca görünümü iyileştirmek istiyorsanız kullanıcı arayüzüne bile katkıda bulunabilirsiniz.
Şuna da dikkatinizi çekmek isterim Açık Hizmet Aracısı API entegrasyonu. Kulağa hantal ve belirsiz gelebilir ama herkesin karşılaştığı sorunları çözer. Basit bir örnekle açıklayayım.
Klasik bir uygulamayı (WordPress) çalıştırmak istediğimiz bir Kubernetes kümesi var. Genel olarak tam işlevsellik için bir veritabanına ihtiyaç vardır. Pek çok farklı çözüm var; örneğin kendi durum bilgisi olan hizmetinizi başlatabilirsiniz. Bu pek kullanışlı değil ama birçok kişi bunu yapıyor.
Diğerleri, bizim gibi Chainstack'ta, sunucuları için MySQL veya PostgreSQL gibi yönetilen veritabanlarını kullanıyor. Bu nedenle veritabanlarımız bulutta bir yerde bulunur.
Ancak bir sorun ortaya çıkıyor: Hizmetimizi bir veritabanına bağlamamız, bir veritabanı tadı oluşturmamız, kimlik bilgilerini aktarmamız ve bir şekilde yönetmemiz gerekiyor. Bütün bunlar genellikle sistem yöneticisi veya geliştirici tarafından manuel olarak yapılır. Başvuru sayısı az olduğunda da sorun olmuyor. Birçoğu olduğunda, bir birleştirmeye ihtiyacınız var. Böyle bir biçerdöver var - bu Servis Brokerı. Genel bir bulut kümesi için özel bir eklenti kullanmanıza ve sanki bir APIymiş gibi sağlayıcıdan Broker aracılığıyla kaynak sipariş etmenize olanak tanır. Bunu yapmak için yerel Kubernetes araçlarını kullanabilirsiniz.
Çok basit. Örneğin Azure'da Yönetilen MySQL'i bir temel katmanla sorgulayabilirsiniz (bu yapılandırılabilir). Azure API kullanılarak veritabanı oluşturulacak ve kullanıma hazırlanacaktır. Buna müdahale etmenize gerek yok, bunun sorumlusu eklentidir. Örneğin, OSBA (Azure eklentisi) kimlik bilgilerini hizmete döndürecek ve bunu Helm'e iletecektir. WordPress'i bulut MySQL ile kullanabilecek, yönetilen veritabanlarıyla hiç ilgilenmeyecek ve içerideki durum bilgisi olan hizmetler konusunda endişelenmeyeceksiniz.
Helm'in bir yandan hizmetleri dağıtmanıza olanak tanıyan, diğer yandan da bulut sağlayıcıların kaynaklarını tüketen bir yapıştırıcı görevi gördüğünü söyleyebiliriz.
Kendi eklentinizi yazabilir ve bu hikayenin tamamını şirket içinde kullanabilirsiniz. O zaman kurumsal Bulut sağlayıcınız için kendi eklentinize sahip olacaksınız. Özellikle büyük bir ölçeğe sahipseniz ve bir özellik için geliştirmeyi, aşamalandırmayı veya tüm altyapıyı hızlı bir şekilde dağıtmak istiyorsanız bu yaklaşımı denemenizi öneririm. Bu, operasyonlarınız veya DevOps'unuz için hayatı kolaylaştıracaktır.
Daha önce bahsettiğim bir diğer bulgu ise helm-gcs eklentisiHelm grafiklerini depolamak için Google paketlerini (nesne depolama) kullanmanıza olanak tanır.
Kullanmaya başlamak için yalnızca dört komuta ihtiyacınız var:
- eklentiyi yükleyin;
- başlatın;
- gcp'de bulunan kovanın yolunu ayarlayın;
- Grafikleri standart şekilde yayınlayın.
İşin güzelliği, yetkilendirme için yerel gcp yönteminin kullanılacak olmasıdır. Hizmet hesabı, geliştirici hesabı, ne isterseniz kullanabilirsiniz. Çok kullanışlıdır ve çalıştırılması hiçbir maliyet gerektirmez. Eğer siz de benim gibi operasyonsuz felsefeyi destekliyorsanız, bu özellikle küçük ekipler için çok uygun olacaktır.
alternatifleri
Helm tek hizmet yönetimi çözümü değil. Bununla ilgili pek çok soru var, muhtemelen üçüncü versiyonun bu kadar hızlı ortaya çıkmasının nedeni de budur. Elbette alternatifler var.
Bunlar, örneğin Ksonnet veya Metaparticle gibi özel çözümler olabilir. Klasik altyapı yönetimi araçlarınızı (Ansible, Terraform, Chef vb.) bahsettiğim amaçlarla kullanabilirsiniz.
Sonunda bir çözüm var popülaritesi giderek artıyor.
Operatör Çerçevesi dikkate alınması gereken en iyi Helm alternatifidir.
Daha çok CNCF ve Kubernetes'e özgüdür, ancak giriş engeli çok daha yüksek, daha fazla programlamanız ve bildirimleri daha az tanımlamanız gerekir.
Draft, Scaffold gibi çeşitli eklentiler bulunmaktadır. Hayatı çok daha kolay hale getiriyorlar; örneğin, geliştiricilerin bir test ortamı dağıtmaları için Helm'i gönderme ve başlatma döngüsünü basitleştiriyorlar. Onlara güçlendiriciler derdim.
İşte her şeyin nerede olduğuna dair görsel bir tablo.
X ekseninde olup bitenler üzerindeki kişisel kontrol seviyeniz, y ekseni ise Kubernetes'in yerellik düzeyidir. Dümen versiyonu 2 ortada bir yere düşüyor. Versiyon 3'te çok fazla olmasa da hem kontrol hem de yerellik düzeyi iyileştirildi. Ksonnet seviyesindeki çözümler hala Helm 2'den bile daha düşük. Ancak, bu dünyada başka neler olduğunu bilmek için bunlara bakmaya değer. Elbette konfigürasyon yöneticiniz sizin kontrolünüz altında olacaktır ancak kesinlikle Kubernetes'e özgü değildir.
Operatör Çerçevesi kesinlikle Kubernetes'e özgüdür ve onu çok daha zarif ve titiz bir şekilde yönetmenize olanak tanır (ancak giriş seviyesini unutmayın). Daha ziyade, Helm kullanarak çok sayıda uygulamayı paketlemek için toplu bir hasat makinesi yerine, özel bir uygulama ve bunun için yönetimin oluşturulması için uygundur.
Genişleticiler kontrolü biraz iyileştirir, iş akışını tamamlar veya CI/CD işlem hatlarında işleri kolaylaştırır.
Helm'in geleceği
İyi haber şu ki Helm 3 geliyor, Helm 3.0.0-alpha.2'nin alfa sürümü zaten yayınlandı, deneyebilirsiniz. Oldukça kararlıdır, ancak işlevsellik hala sınırlıdır.
Neden Helm 3'e ihtiyacınız var? Öncelikle bu bir hikaye Tiller'ın ortadan kaybolması, bir bileşen olarak. Bu, zaten anladığınız gibi, ileriye doğru atılmış büyük bir adımdır, çünkü mimarinin güvenliği açısından her şey basitleştirilmiştir.
Helm 2 oluşturulduğunda, yani Kubernetes 1.8 zamanında veya daha öncesinde, kavramların çoğu henüz olgunlaşmamıştı. Örneğin, CRD konsepti şu anda aktif olarak uygulanıyor ve Helm, CRD'yi kullanyapıları depolamak için. Yalnızca istemciyi kullanmak ve sunucu kısmını korumamak mümkün olacaktır. Buna göre yapılar ve kaynaklarla çalışmak için yerel Kubernetes komutlarını kullanın. Bu ileriye doğru atılmış büyük bir adımdır.
Görünecek yerel OCI depoları için destek (Açık Konteyner Girişimi). Bu çok büyük bir girişim ve Helm öncelikli olarak grafiklerini yayınlamakla ilgileniyor. Öyle bir noktaya geliyor ki örneğin Docker Hub birçok OCI standardını destekliyor. Tahmin etmiyorum ama belki de klasik Docker veri havuzu sağlayıcıları size Helm grafiklerinizi barındırma fırsatı vermeye başlayacaktır.
Benim için tartışmalı hikaye Lua desteği, komut dosyaları yazmak için bir şablon oluşturma motoru olarak. Lua'nın büyük bir hayranı değilim ama bu tamamen isteğe bağlı bir özellik olacaktır. Bunu 3 kez kontrol ettim; Lua'yı kullanmaya gerek kalmayacak. Bu nedenle Lua'yı kullanabilmek isteyenler, Go'yu sevenler devasa kampımıza katılıp bunun için go-tmpl kullanıyorlar.
Sonunda kesinlikle özlediğim şey şuydu: şema ortaya çıkışı ve veri türü doğrulaması. Artık int veya string ile ilgili sorun olmayacak, sıfırı çift tırnak içine almanıza gerek kalmayacak. Bunu değerler için açıkça tanımlamanıza izin verecek bir JSONS şeması görünecektir.
Yoğun bir şekilde yeniden çalışılacak olay odaklı model. Zaten kavramsal olarak açıklanmıştır. Helm 3 şubesine bakın ve kaç tane olayın, kancanın ve başka şeylerin eklendiğini göreceksiniz, bu da büyük ölçüde basitleştirecek ve diğer yandan dağıtım süreçleri ve bunlara verilen tepkiler üzerinde kontrol ekleyecektir.
Helm 3 daha basit, daha güvenli ve daha eğlenceli olacak; Helm 2'yi sevmediğimiz için değil, Kubernetes daha gelişmiş hale geldiği için. Buna göre Helm, Kubernetes'in geliştirmelerini kullanabilir ve bunun üzerinde Kubernetes için mükemmel yöneticiler oluşturabilir.
Bir başka güzel haber de şu Alexander Khayorov size şunu söyleyecektir: Geliştirme, test ve operasyon süreçlerinin entegrasyonu konulu konferansın Moskova'da düzenleneceğini hatırlatalım. 30 Eylül ve 1 Ekim. Bunu 20 Ağustos'a kadar hala yapabilirsiniz. ve bize çözümle ilgili deneyiminizi anlatın DevOps yaklaşımının görevleri.
Konferans kontrol noktalarını ve haberleri şu adresten takip edin: и .
Kaynak: habr.com