Pengantar singkat untuk Kustomize

Catatan perev. : Artikel ini ditulis oleh Scott Lowe, seorang insinyur senior TI yang menulis / ikut menulis tujuh buku cetak (terutama untuk VMware vSphere). Dia saat ini bekerja di anak perusahaan VMware, Heptio (diakuisisi pada 2016), yang berspesialisasi dalam komputasi awan dan Kubernetes. Teks itu sendiri berfungsi sebagai pengantar yang luas dan mudah dipahami untuk manajemen konfigurasi untuk Kubernetes menggunakan teknologi Kustomize , baru-baru ini disertakan dengan K8s.



Kustomize adalah alat yang memungkinkan pengguna untuk "menyesuaikan file YAML yang sederhana dan bebas-templat untuk berbagai keperluan, membuat YAML asli tetap dapat digunakan" (deskripsi dipinjam langsung dari repositori kustomize di GitHub ). Kustomize dapat dijalankan secara langsung atau, dimulai dengan Kubernetes 1.14, gunakan kubectl -k untuk mengakses fungsinya (meskipun pada Kubernetes 1.15, biner terpisah lebih baru daripada fitur yang dibangun dalam kubectl). ( Catatan : Dengan rilis Kubernetes 1.16 baru-baru ini, kustomize juga didukung di utilitas kubeadm.) Dalam posting ini, saya ingin memperkenalkan pembaca pada dasar-dasar kustomisasi.

Dalam bentuk / aplikasinya yang paling sederhana, kustomize hanyalah kumpulan sumber daya (file YAML yang mendefinisikan objek Kubernetes: Penyebaran, Layanan, dll.) Ditambah daftar instruksi tentang perubahan yang perlu dilakukan pada sumber daya ini. Sama seperti make menggunakan set instruksi yang terdapat dalam Makefile , dan Docker Dockerfile wadah berdasarkan instruksi dari Dockerfile , kustomisasi menggunakan kustomization.yaml untuk menyimpan instruksi tentang perubahan apa yang ingin dilakukan pengguna ke set sumber daya.

Berikut ini contoh file kustomization.yaml :

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

Saya tidak akan mencoba membicarakan semua bidang yang mungkin ada dalam file kustomization.yaml (ini ditulis dengan baik di sini ), tetapi saya akan memberikan penjelasan singkat tentang contoh spesifik:

• Bidang resources menunjukkan perubahan (sumber daya) mana yang akan diubah. Dalam hal ini, ia akan mencari sumber daya di file deployment.yaml dan service.yaml dalam direktori-nya (jika perlu, Anda dapat menentukan path lengkap atau relatif).
• Bidang namePrefix menginstruksikan kustomisasi untuk menambahkan awalan spesifik (dalam hal ini, dev- ) ke atribut name semua sumber daya yang ditentukan dalam bidang resources . Jadi, jika ada name di Deployment dengan nilai nginx-deployment , kustomize akan membuat dev-nginx-deployment .
• Bidang namespace menginstruksikan kustomisasi untuk menambahkan namespace yang ditentukan untuk semua sumber daya. Dalam hal ini, Penyebaran dan Layanan akan jatuh ke dalam namespace development .
• Terakhir, bidang commonLabels berisi serangkaian label yang akan ditambahkan ke semua sumber daya. Dalam contoh kami, kustomisasi akan memberikan label ke sumber daya dengan environment nama dan development nilai.

Jika pengguna menjalankan kustomize build . dalam direktori dengan file kustomization.yaml dan sumber daya yang diperlukan (mis. deployment.yaml dan file service.yaml ), maka pada output akan menerima teks dengan perubahan yang terdaftar di kustomization.yaml .


Catatan perev. : Ilustrasi dari dokumentasi proyek untuk penggunaan "sederhana" kustomisasi

Output dapat diarahkan jika Anda perlu melakukan perubahan:

 kustomize build . > custom-config.yaml 

Outputnya deterministik (dengan input yang sama, output yang sama akan diperoleh), sehingga Anda tidak dapat menyimpan hasilnya ke file. Sebagai gantinya, Anda dapat langsung meneruskannya ke perintah lain:

 kustomize build . | kubectl apply -f - 

Fungsi Kustomize juga dapat diakses melalui kubectl -k (sejak versi 1.14 dari Kubernetes). Namun, perlu diingat bahwa paket kustomisasi terpisah diperbarui lebih cepat daripada yang terintegrasi di kubectl (setidaknya demikian halnya dengan rilis Kubernetes 1.15).

Pembaca mungkin bertanya: "Mengapa semua kesulitan ini, apakah Anda dapat mengedit file secara langsung?". Pertanyaan yang bagus Dalam contoh kita, sangat mungkin untuk memodifikasi file deployment.yaml dan service.yaml secara langsung, tetapi bagaimana jika mereka adalah fork proyek orang lain? Mengubah file secara langsung membuat sulit (jika bukan tidak mungkin sama sekali) melakukan rebase pada garpu ketika perubahan dilakukan pada sumber / sumber. Menggunakan kustomize memungkinkan Anda untuk memusatkan perubahan ini dalam file kustomization.yaml , membiarkan file asli tetap utuh dan dengan demikian membuatnya lebih mudah untuk melakukan rebase pada file sumber jika perlu.

Manfaat kustomisasi menjadi jelas dalam kasus penggunaan yang lebih kompleks. Dalam contoh di atas, kustomization.yaml dan sumber daya berada di direktori yang sama. Namun, kustomisasi mendukung skenario penggunaan ketika ada konfigurasi dasar dan banyak variasinya, juga dikenal sebagai overlay . Sebagai contoh, seorang pengguna ingin mengambil Deployment dan Layanan untuk nginx, yang saya gunakan sebagai contoh, dan membuat versi pengembangan, staging, dan produksi (atau varian) dari file-file itu. Untuk melakukan ini, ia akan memerlukan overlay yang disebutkan di atas dan, pada kenyataannya, sumber daya dasar sendiri.

Untuk menggambarkan ide overlay dan sumber daya dasar , misalkan direktori memiliki struktur berikut:

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

Di file base/kustomization.yaml pengguna cukup menggunakan bidang resources untuk mendeklarasikan sumber daya yang harus diaktifkan.

Di masing-masing file overlays/{dev,staging,prod}/kustomization.yaml pengguna merujuk ke konfigurasi dasar di bidang resources , dan kemudian menunjukkan perubahan spesifik untuk lingkungan ini . Misalnya, file overlays/dev/kustomization.yaml mungkin terlihat seperti contoh yang diberikan sebelumnya:

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

Pada saat yang sama, file overlays/prod/kustomization.yaml mungkin sangat berbeda:

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

Ketika pengguna mulai kustomize build . di overlays/dev , kustomize akan menghasilkan opsi pengembangan. Jika Anda menjalankan kustomize build . di direktori overlays/prod - Anda mendapatkan opsi produksi. Dan semua ini - tanpa membuat perubahan pada file asli (basis) , dan semua ini - dengan cara deklaratif dan deterministik. Anda dapat melakukan konfigurasi dasar dan overlay direktori langsung ke sistem kontrol versi, mengetahui bahwa berdasarkan file-file ini Anda dapat mereproduksi konfigurasi yang diinginkan setiap saat.


Catatan perev. : Ilustrasi dari dokumentasi proyek untuk menggunakan overlay di kustomisasi

Kustomize dapat melakukan lebih dari yang dijelaskan dalam artikel ini. Namun, saya berharap ini akan menjadi pengantar yang bagus.

Sumber Daya Tambahan

Ada banyak artikel dan publikasi bagus tentang menyesuaikan. Berikut adalah beberapa yang saya temukan sangat berguna:

• Ubah konfigurasi YAML dasar untuk berbagai lingkungan / uji menggunakan Kustomize ;
• Kustomize - Cara yang tepat untuk melakukan templating di Kubernetes ;
• Manajemen Deklaratif Obyek Kubernetes Menggunakan Kustomize ;
• Menyesuaikan Grafik Helm Hulu dengan Kustomize .

Catatan perev. : Anda juga dapat menyarankan blok tautan yang diterbitkan sebagai Sumberdaya di situs web utilitas, dan koleksi video berikutnya dengan laporan terbaru tentang menyesuaikan.

Jika Anda memiliki pertanyaan atau saran untuk meningkatkan materi ini, saya selalu terbuka untuk umpan balik. Anda dapat menghubungi saya di Twitter atau di saluran Kubernetes Slack . Bersenang-senang memodifikasi manifes Anda dengan menyesuaikan!

PS dari penerjemah

Baca juga di blog kami:

• " Alat untuk pengembang aplikasi yang berjalan di Kubernetes ";
• “ Kubernetes 1.14: Tinjauan Umum tentang Inovasi Kunci ”;
• “ Lima Hasil Utama dari Helm Summit 2019 di Amsterdam ”;
• " Pengantar praktis untuk manajer paket untuk Kubernetes - Helm ."