Özelleştirmeye Kısa Bir Giriş

Not. tercüme: Makale, yedi basılı kitabın (çoğunlukla VMware vSphere üzerine) yazarı/ortak yazarı olan, BT alanında geniş deneyime sahip bir mühendis olan Scott Lowe tarafından yazılmıştır. Şu anda VMware yan kuruluşu Heptio'da (2016'da satın alındı) çalışıyor ve bulut bilişim ve Kubernetes konusunda uzmanlaşıyor. Metnin kendisi, teknolojiyi kullanan Kubernetes için konfigürasyon yönetimine kısa ve anlaşılması kolay bir giriş niteliğindedir. özelleştirmekyakın zamanda K8'lerin bir parçası haline geldi.

Özelleştirme, kullanıcıların "basit, şablonsuz YAML dosyalarını farklı amaçlar için özelleştirmelerine ve orijinal YAML'yi olduğu gibi ve kullanılabilir durumda bırakmalarına" olanak tanıyan bir araçtır (açıklama doğrudan şuradan alınmıştır: GitHub'daki depoyu özelleştirin). Özelleştirme doğrudan çalıştırılabilir veya Kubernetes 1.14'ten itibaren kullanılabilir. kubectl -k işlevselliğine erişmek için (Kubernetes 1.15'ten itibaren ayrı ikili dosya kubectl'de yerleşik yeteneklerden daha yeni olmasına rağmen). (Not. tercüme: Ve son sürümle birlikte Kubernet'ler 1.16 kişiselleştirmek Tarafından desteklenen ayrıca kubeadm yardımcı programında.) Bu yazıda okuyuculara kişiselleştirmenin temellerini tanıtmak istiyorum.

En basit biçiminde/uygulamasında özelleştirme, yalnızca bir kaynak koleksiyonudur (Kubernetes nesnelerini tanımlayan YAML dosyaları: Dağıtımlar, Hizmetler vb.) artı bu kaynaklarda yapılması gereken değişikliklere yönelik talimatların bir listesidir. Make'in içerdiği talimat setini kullanması gibi Makefileve Docker, kapsayıcıyı şuradaki talimatlara göre oluşturur: Dockerfile,kullanımları özelleştir kustomization.yaml kullanıcının bir dizi kaynakta ne gibi değişiklikler yapmak istediğine ilişkin talimatları depolamak için.

İşte bir örnek dosya kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Dosyadaki tüm olası alanlar hakkında konuşmaya çalışmayacağım. kustomization.yaml (bunun hakkında iyi yazılmış burada), ancak belirli bir örneğin kısa bir açıklamasını vereceğim:

• Tarla resources neyin (hangi kaynakların) özelleştirileceğini belirtir. Bu durumda dosyalardaki kaynakları arayacaktır. deployment.yaml и service.yaml dizininizde (gerekiyorsa tam veya göreli yolları belirtebilirsiniz).
• Tarla namePrefix özelleştirmeye belirli bir önek eklemesi talimatını verir (bu durumda - dev-) nitelik kazandırmak name alanda tanımlanan tüm kaynaklar resources. Bu nedenle, eğer Dağıtım varsa name anlamı olan nginx-deployment, özelleştir bunu yapacak dev-nginx-deployment.
• Tarla namespace özelleştirmeye verilen ad alanını tüm kaynaklara ekleme talimatını verir. Bu durumda Dağıtım ve Hizmet ad alanına girecektir development.
• Son olarak saha commonLabels tüm kaynaklara eklenecek bir dizi etiket içerir. Örneğimizde özelleştirme, kaynaklara şu adla bir etiket atayacaktır: environment ve anlam development.

Kullanıcı bunu yaparsa kustomize build . dosyanın bulunduğu dizinde kustomization.yaml ve gerekli kaynaklar (ör. dosyalar) deployment.yaml и service.yaml), daha sonra çıktıda belirtilen değişiklikleri içeren bir metin alacaktır. kustomization.yaml.

Not. tercüme: Özelleştirmenin "basit" kullanımına ilişkin proje belgelerinden örnek

Değişikliklerin yapılması gerekiyorsa çıktı yeniden yönlendirilebilir:

kustomize build . > custom-config.yaml

Çıkış verileri deterministiktir (aynı giriş verileri aynı çıkış sonuçlarını üretecektir), dolayısıyla sonucu bir dosyaya kaydetmeniz gerekmez. Bunun yerine doğrudan başka bir komuta aktarılabilir:

kustomize build . | kubectl apply -f -

Kişiselleştirme özelliklerine şu adresten de erişilebilir: kubectl -k (Kubernetes sürüm 1.14'ten beri). Ancak bağımsız kustomize paketinin entegre kubectl paketinden daha hızlı güncellendiğini unutmayın (en azından Kubernetes 1.15 sürümünde durum böyledir).

Okuyucular şunu sorabilir: "Dosyaları doğrudan düzenleyebiliyorsanız neden tüm bu karmaşıklık?" Harika bir soru. Bizim örneğimizde aslında kimse yapamaz dosyaları değiştir deployment.yaml и service.yaml doğrudan, ama ya bunlar başka birinin projesinin bir çatalıysa? Dosyaları doğrudan değiştirmek, kaynak/kaynakta değişiklik yapıldığında çatalın yeniden temellendirilmesini zorlaştırır (imkansız olmasa da). Özelleştirmeyi kullanmak, bu değişiklikleri bir dosyada merkezileştirmenize olanak tanır kustomization.yamlorijinal dosyaları olduğu gibi bırakarak gerekirse orijinal dosyaların yeniden temellendirilmesini kolaylaştırır.

Özelleştirmenin faydaları daha karmaşık kullanım durumlarında belirgin hale gelir. Yukarıdaki örnekte kustomization.yaml ve kaynaklar aynı dizindedir. Ancak özelleştirme, bir temel yapılandırmanın ve bunun pek çok çeşidinin bulunduğu kullanım durumlarını destekler. bindirmeleri. Örneğin, bir kullanıcı benim örnek olarak kullandığım nginx için Dağıtım ve Hizmet'i alıp bu dosyaların geliştirme, hazırlama ve üretim sürümlerini (veya varyantlarını) oluşturmak istedi. Bunu yapmak için yukarıda belirtilen katmanlara ve aslında temel kaynaklara ihtiyacı olacak.

Kaplamalar ve temel kaynaklar fikrini göstermek için (temel kaynaklar), dizinlerin aşağıdaki yapıya sahip olduğunu varsayalım:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Dosyada base/kustomization.yaml alanı kullanan kullanıcılar resources özelleştirmenin içermesi gereken kaynakları bildirmeniz yeterlidir.

Dosyaların her birinde overlays/{dev,staging,prod}/kustomization.yaml kullanıcılar alandaki temel konfigürasyona başvurur resourcesve ardından belirli değişiklikleri belirtin verilen ortam. Örneğin, dosya overlays/dev/kustomization.yaml daha önce verilen örneğe benzeyebilir:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Bu durumda dosya overlays/prod/kustomization.yaml tamamen farklı olabilir:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Kullanıcı çalıştırıldığında kustomize build . katalogda overlays/dev, özelleştirme geliştirme seçeneğini oluşturacaktır. Eğer koşarsan kustomize build . katalogda overlays/prod - üretim seçeneğine sahip olursunuz. Ve tüm bunlar - orijinalde herhangi bir değişiklik yapmadan (Baz) dosyaların tümü bildirimsel ve deterministik bir şekilde. Temel konfigürasyonu ve katman dizinlerini doğrudan sürüm kontrolüne aktarabilirsiniz; bu dosyalara dayanarak istediğiniz konfigürasyonu istediğiniz zaman yeniden üretebileceğinizi bilirsiniz.

Not. tercüme: Özelleştirmede katmanların kullanımına ilişkin proje belgelerinden örnek

Kutuyu özelleştir daha bu makalede anlatılanlardan daha fazlası. Ancak umarım iyi bir giriş niteliğindedir.

Ek kaynaklar

Kişiselleştirmeyle ilgili pek çok güzel makale ve yayın var. İşte özellikle yararlı bulduğum birkaç tanesi:

• Kustomize'ı kullanarak farklı ortamlar için temel YAML yapılandırmasını değiştirme/test etme;
• Kişiselleştirme — Kubernetes'te şablon oluşturmanın doğru yolu;
• Özelleştirme Kullanarak Kubernetes Nesnelerinin Bildirime Dayalı Yönetimi;
• Özelleştir ile Yukarı Akış Dümen Grafiklerini Özelleştirme.

Not. tercüme: Ayrıca şu şekilde yayınlanan bir bağlantı bloğu da önerebilirsiniz: Kaynaklar yardımcı programın web sitesinde ve ardından kişiselleştirmeyle ilgili en son raporların yer aldığı bir video koleksiyonu yer alıyor.

Bu materyali geliştirmeye yönelik sorularınız veya önerileriniz varsa geri bildirime her zaman açığım. Benimle şu adresten iletişime geçebilirsiniz: Twitter veya Kubernetes Slack kanalı. Kişiselleştirme ile bildirimlerinizi değiştirirken eğlenin!

çevirmenden PS

Blogumuzda da okuyun:

• «Kubernetes'te çalışan uygulama geliştiricilerine yönelik araçlar";
• «Kubernetes 1.14: ana yeniliklere genel bakış";
• «Amsterdam'daki Helm Zirvesi 2019'un beş ana sonucu";
• «Kubernetes için paket yöneticisine pratik giriş - Helm'.

Kaynak: habr.com