Pengantar Singkat tentang Kustomize

Catatan. terjemahan: Artikel ini ditulis oleh Scott Lowe, seorang insinyur dengan pengalaman luas di bidang TI, yang merupakan penulis/rekan penulis tujuh buku cetak (terutama tentang VMware vSphere). Dia sekarang bekerja untuk anak perusahaan VMware, Heptio (diakuisisi pada tahun 2016), yang berspesialisasi dalam komputasi awan dan Kubernetes. Teks itu sendiri berfungsi sebagai pengenalan singkat dan mudah dipahami tentang manajemen konfigurasi untuk Kubernetes menggunakan teknologi Sesuaikan, yang baru-baru ini menjadi bagian dari K8s.

Kustomize adalah alat yang memungkinkan pengguna untuk “menyesuaikan file YAML sederhana dan bebas template untuk berbagai tujuan, sehingga YAML asli tetap utuh dan dapat digunakan” (deskripsi dipinjam langsung dari sesuaikan repositori di GitHub). Kustomize dapat dijalankan secara langsung atau, mulai Kubernetes 1.14, digunakan kubectl -k untuk mengakses fungsionalitasnya (walaupun pada Kubernetes 1.15, biner terpisah lebih baru dibandingkan kemampuan yang dibangun di kubectl). (Catatan. terjemahan: Dan dengan rilis terbaru Kubernet 1.16 sesuaikan didukung oleh juga di utilitas kubeadm.) Dalam postingan ini, saya ingin memperkenalkan kepada pembaca dasar-dasar kustomisasi.

Dalam bentuk/aplikasi paling sederhana, kustomize hanyalah kumpulan sumber daya (file YAML yang mendefinisikan objek Kubernetes: Deployment, Layanan, dll.) ditambah daftar instruksi untuk perubahan yang perlu dilakukan pada sumber daya tersebut. Sama seperti make yang menggunakan set instruksi yang ada di dalamnya Makefile, dan Docker membangun container berdasarkan instruksi dari Dockerfile, sesuaikan penggunaan kustomization.yaml untuk menyimpan instruksi tentang perubahan apa yang ingin dilakukan pengguna pada sekumpulan sumber daya.

Berikut ini contoh filenya kustomization.yaml:

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

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

• Lapangan resources menunjukkan apa (sumber daya mana) yang dikustomisasi akan berubah. Dalam hal ini, ia akan mencari sumber daya dalam file deployment.yaml и service.yaml di direktori Anda (Anda dapat menentukan jalur lengkap atau relatif jika perlu).
• Lapangan namePrefix menginstruksikan kustomize untuk menambahkan awalan tertentu (dalam hal ini - dev-) untuk diatribusikan name semua sumber daya yang ditentukan di lapangan resources. Jadi, jika Deployment punya name dengan makna nginx-deployment, penyesuaian akan berhasil dev-nginx-deployment.
• Lapangan namespace menginstruksikan kustomize untuk menambahkan namespace yang diberikan ke semua sumber daya. Dalam hal ini, Deployment dan Service akan masuk ke dalam namespace development.
• Terakhir, lapangan commonLabels berisi sekumpulan label yang akan ditambahkan ke semua sumber daya. Dalam contoh kita, kustomize akan memberikan label pada sumber daya dengan nama environment dan artinya development.

Jika pengguna melakukannya kustomize build . di direktori dengan file tersebut kustomization.yaml dan sumber daya yang diperlukan (yaitu file deployment.yaml и service.yaml), kemudian pada outputnya akan menerima teks dengan perubahan yang ditentukan kustomization.yaml.

Catatan. terjemahan: Ilustrasi dari dokumentasi proyek tentang penggunaan kustomize yang “sederhana”.

Outputnya dapat dialihkan jika perubahan perlu dilakukan:

kustomize build . > custom-config.yaml

Data keluarannya bersifat deterministik (data masukan yang sama akan menghasilkan hasil keluaran yang sama), sehingga tidak perlu menyimpan hasilnya ke file. Sebaliknya, ini dapat diteruskan langsung ke perintah lain:

kustomize build . | kubectl apply -f -

Fitur kustomize juga dapat diakses melalui kubectl -k (sejak Kubernetes versi 1.14). Namun, perlu diingat bahwa paket kustomize mandiri diperbarui lebih cepat daripada paket kubectl terintegrasi (setidaknya hal ini terjadi pada rilis Kubernetes 1.15).

Pembaca mungkin bertanya: “Mengapa semua kerumitan ini jika Anda dapat mengedit file secara langsung?” Pertanyaan bagus. Memang benar dalam contoh kita satu bisa memodifikasi file deployment.yaml и service.yaml secara langsung, tetapi bagaimana jika itu adalah hasil dari proyek orang lain? Mengubah file secara langsung menyulitkan (jika bukan tidak mungkin) untuk melakukan rebase fork ketika ada perubahan pada asal/sumber. Menggunakan kustomize memungkinkan Anda memusatkan perubahan ini dalam sebuah file kustomization.yaml, membiarkan file asli tetap utuh sehingga memudahkan untuk melakukan rebase file asli jika perlu.

Manfaat kustomize menjadi jelas dalam kasus penggunaan yang lebih kompleks. Dalam contoh di atas kustomization.yaml dan sumber daya berada di direktori yang sama. Namun, kustomize mendukung kasus penggunaan di mana terdapat konfigurasi dasar dan banyak variannya, yang juga dikenal sebagai hamparan. Misalnya, pengguna ingin menggunakan Deployment dan Service untuk nginx, yang saya gunakan sebagai contoh, dan membuat versi (atau varian) pengembangan, staging, dan produksi dari file tersebut. Untuk melakukan ini, ia memerlukan lapisan yang disebutkan di atas dan, pada kenyataannya, sumber daya dasar itu sendiri.

Untuk mengilustrasikan gagasan overlay dan sumber daya yang mendasarinya (sumber daya dasar), asumsikan direktori memiliki struktur berikut:

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

Dalam file base/kustomization.yaml pengguna menggunakan bidang tersebut resources cukup nyatakan sumber daya yang harus disertakan oleh kustomize.

Di setiap file overlays/{dev,staging,prod}/kustomization.yaml pengguna merujuk pada konfigurasi dasar di lapangan resources, lalu tunjukkan perubahan spesifik untuk lingkungan tertentu. Misalnya, berkas overlays/dev/kustomization.yaml mungkin terlihat seperti contoh yang diberikan sebelumnya:

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

Dalam hal ini file overlays/prod/kustomization.yaml bisa sangat berbeda:

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

Saat pengguna berjalan kustomize build . di katalog overlays/dev, kustomize akan menghasilkan opsi pengembangan. Jika kamu lari kustomize build . di katalog overlays/prod - Anda mendapatkan opsi produksi. Dan semua ini - tanpa membuat perubahan apa pun pada aslinya (basis) file, semuanya dengan cara deklaratif dan deterministik. Anda dapat mengkomit konfigurasi dasar dan direktori overlay langsung ke kontrol versi, mengetahui bahwa berdasarkan file-file ini Anda dapat mereproduksi konfigurasi yang diinginkan kapan saja.

Catatan. terjemahan: Ilustrasi dari dokumentasi proyek tentang penggunaan overlay dalam kustomisasi

Sesuaikan bisa banyak lebih dari apa yang dibahas dalam artikel ini. Namun, saya harap ini bisa menjadi perkenalan yang baik.

Sumber daya tambahan

Ada banyak artikel dan publikasi bagus tentang kustomize. Berikut beberapa yang menurut saya sangat berguna:

• Ubah konfigurasi YAML dasar untuk produksi/pengujian lingkungan yang berbeda menggunakan Kustomize;
• Kustomize — Cara yang tepat untuk melakukan templating di Kubernetes;
• Pengelolaan Deklaratif Objek Kubernetes Menggunakan Customize;
• Menyesuaikan Grafik Helm Hulu dengan Kustomisasi.

Catatan. terjemahan: Anda juga dapat merekomendasikan blok tautan yang diterbitkan sebagai Sumber di situs web utilitas, diikuti dengan kumpulan video dengan laporan terbaru tentang kustomisasi.

Jika Anda memiliki pertanyaan atau saran untuk menyempurnakan materi ini, saya selalu terbuka untuk menerima masukan. Anda dapat menghubungi saya di Twitter atau Saluran Kubernetes Slack. Bersenang-senang memodifikasi manifes Anda dengan kustomize!

PS dari penerjemah

Baca juga di blog kami:

• «Alat untuk pengembang aplikasi yang berjalan di Kubernetes»;
• «Kubernetes 1.14: ikhtisar inovasi utama»;
• «Lima hasil utama Helm Summit 2019 di Amsterdam»;
• «Pengenalan praktis tentang manajer paket untuk Kubernetes - Helm'.

Sumber: www.habr.com