🥇 Dümen 3'e Giriş

Not. tercüme: Bu yılın 16 Mayıs'ı Kubernetes paket yöneticisi Helm'in geliştirilmesinde önemli bir dönüm noktasına işaret ediyor. Bu gün, projenin gelecekteki büyük versiyonu olan 3.0'ın ilk alfa sürümü sunuldu. Yayınlanması, Helm'e, Kubernetes topluluğundaki pek çok kişinin büyük umutlar beslediği önemli ve uzun zamandır beklenen değişiklikleri getirecek. Helm'i uygulama dağıtımı için aktif olarak kullandığımız için biz de bunlardan biriyiz: onu CI/CD'yi uygulamaya yönelik aracımıza entegre ettik. Werf zaman zaman da upstream'in gelişimine katkıda bulunuyoruz. Bu çeviri, Helm 7'ün ilk alfa sürümüne adanan ve projenin geçmişi ve Helm 3'ün ana özellikleri hakkında konuşan resmi Helm blogundan 3 notu bir araya getiriyor. Yazarları, bir Microsoft çalışanı olan Matt "bacongobbler" Fisher'dır. ve Helm'in kilit koruyucularından biri.

15 Ekim 2015'te artık Helm olarak bilinen proje doğdu. Helm topluluğu, kuruluşundan sadece bir yıl sonra Helm 2 üzerinde aktif olarak çalışırken Kubernetes'e katıldı. Haziran 2018'de Helm CNCF'ye katıldı gelişen (kuluçkalayan) bir proje olarak. Günümüze hızla ilerleyelim ve yeni Helm 3'ün ilk alfa sürümü yolda. (bu sürüm zaten gerçekleşti mayıs ortasında - yakl. çeviri.).

Bu makalede, her şeyin başladığı yerden, bugün bulunduğumuz yere nasıl geldiğimizden bahsedeceğim, Helm 3'ün ilk alfa sürümündeki benzersiz özelliklerden bazılarını tanıtacağım ve nasıl daha da geliştirmeyi planladığımızı açıklayacağım.

Özet:

Helm'in yaratılış tarihi;
Tiller'a şefkatli bir veda;
grafik depoları;
sürüm yönetimi;
grafik bağımlılıklarındaki değişiklikler;
kütüphane çizelgeleri;
sırada ne var?

Helm'in tarihi

doğum

Helm 1, Deis tarafından oluşturulan bir Açık Kaynak projesi olarak başladı. Biz küçük bir startuptık absorbe Microsoft, 2017 baharında. Deis adlı diğer Açık Kaynak projemizde bir araç vardı deisctl(diğer şeylerin yanı sıra) Deis platformunu kurmak ve çalıştırmak için kullanıldı Filo kümesi. O zamanlar Fleet, ilk konteyner düzenleme platformlarından biriydi.

2015'in ortasında rotayı değiştirmeye karar verdik ve Deis'i (o zamanlar Deis Workflow olarak yeniden adlandırıldı) Fleet'ten Kubernetes'e taşıdık. Yeniden tasarlananlardan biri kurulum aracıydı. deisctl. Filo kümesinde Deis Workflow'u kurmak ve yönetmek için kullandık.

Helm 1, Homebrew, apt ve yum gibi ünlü paket yöneticilerinin imajına göre oluşturuldu. Ana hedefi Kubernetes'te uygulamaları paketleme ve yükleme gibi görevleri basitleştirmekti. Helm resmi olarak 2015 yılında San Francisco'daki KubeCon konferansında tanıtıldı.

Helm'le ilk denememiz işe yaradı ama bazı ciddi sınırlamalar da vardı. Giriş niteliğindeki YAML blokları olarak jeneratörlerle tatlandırılmış bir dizi Kubernetes bildirimini aldı. (ön madde)* ve sonuçları Kubernetes'e yükledim.

* Not. tercüme: Helm'in ilk sürümünden itibaren Kubernetes kaynaklarını tanımlamak için YAML sözdizimi seçildi ve konfigürasyonlar yazılırken Jinja şablonları ve Python komut dosyaları desteklendi. Bu konu ve genel olarak Helm'in ilk versiyonunun yapısı hakkında daha fazla bilgiyi "Miğferin Kısa Tarihi" bölümünde yazmıştık. bu materyal.

Örneğin, YAML dosyasındaki bir alanı değiştirmek için manifest dosyasına aşağıdaki yapıyı eklemeniz gerekiyordu:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Günümüzde şablon motorlarının mevcut olması harika, değil mi?

Birçok nedenden ötürü, bu ilk Kubernetes yükleyicisi, sabit kodlanmış bir manifest dosyası listesine ihtiyaç duyuyordu ve yalnızca küçük, sabit bir olay dizisini yürütüyordu. Kullanımı o kadar zordu ki Deis Workflow Ar-Ge ekibi, ürünlerini bu platforma aktarmaya çalışırken zor anlar yaşadı - ancak fikrin tohumları çoktan ekilmişti. İlk girişimimiz harika bir öğrenme fırsatıydı: Kullanıcılarımızın gündelik sorunlarını çözen pragmatik araçlar yaratma konusunda gerçekten tutkulu olduğumuzu fark ettik.

Geçmişteki hatalardan edindiğimiz deneyimlere dayanarak Helm 2'yi geliştirmeye başladık.

Miğfer Yapımı 2

2015'in sonunda Google ekibi bizimle iletişime geçti. Kubernetes için de benzer bir araç üzerinde çalışıyorlardı. Deployment Manager for Kubernetes, Google Cloud Platform için kullanılan mevcut bir aracın bağlantı noktasıydı. "Benzerlikleri ve farklılıkları tartışarak birkaç gün geçirmek ister miyiz?" diye sordular.

Ocak 2016'da Dümen ve Dağıtım Yöneticisi ekipleri fikir alışverişinde bulunmak için Seattle'da bir araya geldi. Müzakereler iddialı bir planla sona erdi: Helm 2'yi oluşturmak için her iki projeyi birleştirmek. Deis ve Google'ın yanı sıra, Atlama Kutusu (şimdi Bitnami'nin bir parçası - yaklaşık çeviri.)ve Helm 2 üzerinde çalışmaya başladık.

Helm'in kullanım kolaylığını korumak istedik ancak şunları eklemek istedik:

özelleştirme için grafik şablonları;
ekipler için küme içi yönetim;
birinci sınıf grafik deposu;
imza seçeneğiyle kararlı paket formatı;
Anlamsal sürüm oluşturmaya ve sürümler arasında geriye dönük uyumluluğu sürdürmeye güçlü bir bağlılık.

Bu hedeflere ulaşmak için Helm ekosistemine ikinci bir unsur eklendi. Bu küme içi bileşene Tiller adı verildi ve Helm grafiklerinin kurulmasından ve yönetilmesinden sorumluydu.

Helm 2'nin 2016'da piyasaya sürülmesinden bu yana Kubernetes birçok önemli yenilik ekledi. Rol tabanlı erişim kontrolü eklendi (RBAC), sonunda Öznitelik Tabanlı Erişim Denetiminin (ABAC) yerini aldı. Yeni kaynak türleri tanıtıldı (O sırada Dağıtımlar hâlâ beta aşamasındaydı). Özel Kaynak Tanımları (başlangıçta Üçüncü Taraf Kaynakları veya TPR'ler olarak adlandırılıyordu) icat edildi. Ve en önemlisi, bir dizi en iyi uygulama ortaya çıktı.

Tüm bu değişikliklerin ortasında Helm, Kubernetes kullanıcılarına sadakatle hizmet vermeye devam etti. Üç yıl ve birçok yeni eklemenin ardından, Helm'in gelişen bir ekosistemin artan ihtiyaçlarını karşılamaya devam edebilmesini sağlamak için kod tabanında önemli değişiklikler yapmanın zamanının geldiği açıktı.

Tiller'a duygusal veda

Helm 2'nin geliştirilmesi sırasında Google'ın Dağıtım Yöneticisi ile entegrasyonumuzun bir parçası olarak Tiller'ı tanıttık. Tiller, ortak bir küme içinde çalışan ekipler için önemli bir rol oynadı: altyapıyı işleten farklı uzmanların aynı sürümlerle etkileşime girmesine olanak sağladı.

Kubernetes 1.6'da rol tabanlı erişim kontrolü (RBAC) varsayılan olarak etkinleştirildiğinden, üretimde Tiller ile çalışmak daha zor hale geldi. Olası güvenlik politikalarının çok fazla olması nedeniyle bizim pozisyonumuz, varsayılan olarak izin veren bir yapılandırma sunmak olmuştur. Bu, yeni başlayanların önce güvenlik ayarlarına dalmak zorunda kalmadan Helm ve Kubernetes ile deneyler yapmasına olanak tanıdı. Ne yazık ki, bu izin yapılandırması kullanıcıya ihtiyaç duymadığı çok çeşitli izinler verebilir. DevOps ve SRE mühendisleri, Tiller'ı çok kiracılı bir kümeye kurarken ek operasyonel adımları öğrenmek zorunda kaldı.

Topluluğun Helm'i belirli durumlarda nasıl kullandığını öğrendikten sonra, Tiller'in sürüm yönetimi sisteminin, sürüm bilgileri için merkezi bir merkez olarak durumu veya işlevi sürdürmek için küme içi bir bileşene güvenmesi gerekmediğini fark ettik. Bunun yerine, Kubernetes API sunucusundan basitçe bilgi alabilir, istemci tarafında bir grafik oluşturabilir ve kurulumun kaydını Kubernetes'te saklayabiliriz.

Tiller'ın ana hedefine Tiller olmadan da ulaşılabilirdi, dolayısıyla Helm 3 ile ilgili ilk kararlarımızdan biri Tiller'ı tamamen terk etmek oldu.

Tiller'ın gitmesiyle Helm'in güvenlik modeli kökten basitleştirildi. Helm 3 artık mevcut Kubernetes'in tüm modern güvenlik, kimlik ve yetkilendirme yöntemlerini destekliyor. Dümen izinleri kullanılarak belirlenir kubeconfig dosyası. Küme yöneticileri, kullanıcı haklarını herhangi bir ayrıntı düzeyiyle sınırlayabilir. Sürümler hâlâ küme içinde kaydediliyor ve Helm'in geri kalan işlevleri bozulmadan kalıyor.

Grafik depoları

Yüksek düzeyde bir grafik deposu, grafiklerin saklanabileceği ve paylaşılabileceği bir yerdir. Helm istemcisi grafikleri paketler ve depoya gönderir. Basitçe söylemek gerekirse, grafik deposu, index.yaml dosyası ve bazı paketlenmiş grafikler içeren ilkel bir HTTP sunucusudur.

Charts Repository API'nin temel depolama gereksinimlerinin çoğunu karşılamasının bazı avantajları olsa da birkaç dezavantajı da vardır:

Grafik depoları, üretim ortamında gereken çoğu güvenlik uygulamasıyla uyumlu değildir. Kimlik doğrulama ve yetkilendirme için standart bir API'ye sahip olmak, üretim senaryolarında son derece önemlidir.
Helm'in bir grafiği imzalamak, bütünlüğünü ve kaynağını doğrulamak için kullanılan harita kaynak araçları, Grafik yayınlama sürecinin isteğe bağlı bir parçasıdır.
Çok kullanıcılı senaryolarda, aynı grafik başka bir kullanıcı tarafından yüklenebilir, bu da aynı içeriği depolamak için gereken alan miktarını iki katına çıkarır. Bu sorunu çözmek için daha akıllı depolar geliştirildi, ancak bunlar resmi spesifikasyonun bir parçası değil.
Meta verileri aramak, depolamak ve grafikleri almak için tek bir dizin dosyası kullanmak, güvenli çok kullanıcılı uygulamalar geliştirmeyi zorlaştırdı.

Proje Docker Dağıtımı (Docker Registry v2 olarak da bilinir) Docker Registry'nin halefidir ve esas olarak Docker görüntülerini paketlemek, göndermek, depolamak ve dağıtmak için bir dizi araç görevi görür. Birçok büyük bulut hizmeti Dağıtım tabanlı ürünler sunar. Bu artan ilgi sayesinde Dağıtım projesi, yıllarca süren iyileştirmelerden, en iyi güvenlik uygulamalarından ve saha testlerinden yararlanarak Açık Kaynak dünyasının en başarılı isimsiz kahramanlarından biri haline geldi.

Ancak Dağıtım Projesinin yalnızca kapsayıcı görüntüleri değil, her türlü içeriği dağıtmak üzere tasarlandığını biliyor muydunuz?

Çabalar sayesinde Kapsayıcı Girişimini Aç (veya OCI), Helm grafikleri herhangi bir Dağıtım örneğine yerleştirilebilir. Şimdilik bu süreç deneyseldir. Tam bir Helm 3 için gereken oturum açma desteği ve diğer özellikler, devam eden bir çalışmadır, ancak OCI ve Dağıtım ekiplerinin yıllar içinde yaptığı keşiflerden yeni şeyler öğrenmek bizi heyecanlandırıyor. Onların mentorluğu ve rehberliği sayesinde, yüksek düzeyde kullanılabilir bir hizmeti geniş ölçekte çalıştırmanın nasıl bir şey olduğunu öğreniyoruz.

Helm grafiği veri havuzlarında yapılacak bazı değişikliklerin daha ayrıntılı bir açıklaması mevcuttur по ссылке.

Sürüm yönetimi

Helm 3'te uygulama durumu küme içinde bir çift nesne tarafından izlenir:

yayın nesnesi - bir uygulama örneğini temsil eder;
sürüm sırrı - uygulamanın belirli bir andaki istenen durumunu temsil eder (örneğin, yeni bir sürümün yayınlanması).

Вызов helm install bir yayın nesnesi ve yayın sürümü sırrı oluşturur. Arama helm upgrade bir yayın nesnesi gerektirir (değiştirebilir) ve yeni değerleri ve hazırlanmış bir bildirimi içeren yeni bir yayın sürümü sırrı oluşturur.

Sürüm nesnesi, sürümle ilgili bilgileri içerir; burada sürüm, adlandırılmış bir grafiğin ve değerlerin belirli bir kurulumudur. Bu nesne, sürümle ilgili üst düzey meta verileri açıklar. Yayın nesnesi, uygulamanın yaşam döngüsü boyunca varlığını sürdürür ve tüm yayın sürümü sırlarının yanı sıra doğrudan Helm grafiği tarafından oluşturulan tüm nesnelerin de sahibidir.

Sürüm gizli anahtarı, bir sürümü bir dizi revizyonla (kurulum, güncellemeler, geri almalar, silme) ilişkilendirir.

Helm 2'deki revizyonlar son derece tutarlıydı. Arama helm install v1 oluşturuldu, sonraki güncelleme (yükseltme) - v2 vb. Yayın ve yayın sürümü sırrı, revizyon olarak bilinen tek bir nesneye daraltılmıştır. Düzeltmeler, Tiller ile aynı ad alanında saklanıyordu; bu, her sürümün ad alanı açısından "küresel" olduğu anlamına geliyordu; sonuç olarak adın yalnızca bir örneği kullanılabildi.

Helm 3'te her sürüm, bir veya daha fazla sürüm sürümü sırrıyla ilişkilendirilir. Sürüm nesnesi her zaman Kubernetes'e dağıtılan geçerli sürümü açıklar. Her sürüm sürümü sırrı, o sürümün yalnızca bir sürümünü açıklar. Örneğin bir yükseltme, yeni bir yayın sürümü sırrı oluşturacak ve ardından yayın nesnesini bu yeni sürümü işaret edecek şekilde değiştirecektir. Geri alma durumunda, sürümü önceki bir duruma geri almak için önceki sürüm sürümü sırlarını kullanabilirsiniz.

Tiller terk edildikten sonra Helm 3, sürüm verilerini sürümle aynı ad alanında saklar. Bu değişiklik, aynı sürüm adına sahip bir grafiği farklı bir ad alanına yüklemenize olanak tanır ve veriler, küme güncellemeleri/yeniden başlatmalar arasında etcd'ye kaydedilir. Örneğin, WordPress'i "foo" ad alanına ve ardından "bar" ad alanına yükleyebilirsiniz; her iki sürüm de "wordpress" olarak adlandırılabilir.

Grafik bağımlılıklarındaki değişiklikler

Paketlenmiş grafikler (kullanılarak helm packageHelm 2 ile kullanım için ) Helm 3 ile kurulabilir, ancak grafik geliştirme iş akışı tamamen elden geçirilmiştir, bu nedenle Helm 3 ile grafik geliştirmeye devam etmek için bazı değişiklikler yapılması gerekmektedir. Özellikle grafik bağımlılığı yönetim sistemi değişti.

Grafiğin bağımlılık yönetimi sistemi şu tarihten itibaren taşındı: requirements.yaml и requirements.lock üzerinde Chart.yaml и Chart.lock. Bu, komutu kullanan grafiklerin helm dependencyHelm 3'te çalışmak için bazı kurulumlar gerekir.

Bir örneğe bakalım. Helm 2'deki grafiğe bir bağımlılık ekleyelim ve Helm 3'e geçerken nelerin değişeceğini görelim.

Dümen 2'de requirements.yaml şuna benziyordu:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Helm 3'te aynı bağımlılık oyununuza da yansıyacaktır. Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Grafikler hâlâ indiriliyor ve dizine yerleştiriliyor charts/, yani alt grafikler (alt grafikler), katalogda yer alıyor charts/, değişiklik yapılmadan çalışmaya devam edecektir.

Kütüphane Tablolarına Giriş

Helm 3, kitaplık grafikleri adı verilen bir grafik sınıfını destekler (kütüphane şeması). Bu grafik diğer grafikler tarafından kullanılır ancak kendi başına herhangi bir yayın yapısı oluşturmaz. Kitaplık grafiği şablonları yalnızca öğeleri bildirebilir define. Diğer içerik basitçe göz ardı edilir. Bu, kullanıcıların birden fazla grafikte kullanılabilecek kod parçacıklarını yeniden kullanmasına ve paylaşmasına olanak tanır, böylece tekrarlardan kaçınılır ve prensibe bağlı kalınır. KURU.

Kütüphane çizelgeleri bölümde bildirilir. dependencies dosyada Chart.yaml. Bunları kurmak ve yönetmek diğer grafiklerden farklı değildir.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Bu bileşenin grafik geliştiricilere açacağı kullanım örneklerinin yanı sıra kitaplık grafiklerinden ortaya çıkabilecek en iyi uygulamalar konusunda heyecan duyuyoruz.

Sırada ne var?

Helm 3.0.0-alpha.1, Helm'in yeni bir versiyonunu oluşturmaya başlayacağımız temeldir. Makalede Helm 3'ün bazı ilginç özelliklerini anlattım. Birçoğu henüz geliştirme aşamasındadır ve bu normaldir; Alfa sürümünün amacı fikri test etmek, ilk kullanıcılardan geri bildirim toplamak ve varsayımlarımızı doğrulamaktır.

Alfa sürümü yayınlanır yayınlanmaz (bunun olduğunu unutmayın çoktan oldu - yaklaşık. çeviri.)Topluluktan Helm 3 için yamaları kabul etmeye başlayacağız. Yeni işlevlerin geliştirilmesine ve benimsenmesine ve kullanıcıların destek bildirimleri açarak ve düzeltmeler yaparak sürece dahil olduklarını hissetmelerine olanak tanıyan güçlü bir temel oluşturmanız gerekir.

Helm 3'e gelen bazı önemli iyileştirmeleri vurgulamaya çalıştım, ancak bu liste kesinlikle kapsamlı değil. Helm 3'ün tam yol haritası, geliştirilmiş güncelleme stratejileri, OCI kayıtları ile daha derin entegrasyon ve grafik değerlerini doğrulamak için JSON şemalarının kullanılması gibi özellikleri içerir. Ayrıca kod tabanını temizlemeyi ve son üç yıldır ihmal edilen kısımlarını güncellemeyi planlıyoruz.

Bir şeyi kaçırdığımızı düşünüyorsanız düşüncelerinizi duymak isteriz!

Bizimle ilgili tartışmaya katılın Gevşek kanallar:

#helm-users toplulukla sorular ve basit iletişim için;
#helm-dev çekme isteklerini, kodu ve hataları tartışmak için.

Ayrıca Perşembe günleri saat 19:30 MSK'daki haftalık Herkese Açık Geliştirici Çağrılarımızda da sohbet edebilirsiniz. Toplantılar, kilit geliştiricilerin ve topluluğun üzerinde çalıştığı konuların yanı sıra haftanın tartışma konularını tartışmaya adanmıştır. Toplantıya herkes katılabilir ve katılabilir. Bağlantı Slack kanalında mevcut #helm-dev.

çevirmenden PS

Blogumuzda da okuyun:

Kaynak: habr.com

Helm 3'le tanışın