Pengenalan Ringkas kepada Kustomize

Catatan. terjemah: Artikel itu ditulis oleh Scott Lowe, seorang jurutera yang berpengalaman luas dalam IT, yang merupakan pengarang/pengarang bersama tujuh buku bercetak (terutamanya pada VMware vSphere). Dia kini bekerja untuk anak syarikat VMwarenya Heptio (diperolehi pada 2016), pakar dalam pengkomputeran awan dan Kubernetes. Teks itu sendiri berfungsi sebagai pengenalan ringkas dan mudah difahami kepada pengurusan konfigurasi untuk Kubernetes menggunakan teknologi Sesuaikan, yang baru-baru ini menjadi sebahagian daripada K8s.

Kustomize ialah alat yang membolehkan pengguna "menyesuaikan fail YAML yang ringkas dan bebas templat untuk tujuan berbeza, menjadikan YAML asal utuh dan boleh digunakan" (perihalan yang dipinjam terus daripada kustomize repositori pada GitHub). Kustomize boleh dijalankan secara langsung atau, seperti Kubernetes 1.14, digunakan kubectl -k untuk mengakses kefungsiannya (walaupun pada Kubernetes 1.15, binari yang berasingan adalah lebih baharu daripada keupayaan yang dibina ke dalam kubectl). (Catatan. terjemah: Dan dengan keluaran baru-baru ini Kubernetes 1.16 menyesuaikan disokong oleh juga dalam utiliti kubeadm.) Dalam siaran ini, saya ingin memperkenalkan pembaca kepada asas kustomize.

Dalam bentuk/aplikasi yang paling mudah, kustomize hanyalah koleksi sumber (fail YAML yang mentakrifkan objek Kubernetes: Deployments, Services, dll.) serta senarai arahan untuk perubahan yang perlu dibuat pada sumber tersebut. Sama seperti make menggunakan set arahan yang terkandung dalam Makefile, dan Docker membina bekas berdasarkan arahan daripada Dockerfile,suaikan kegunaan kustomization.yaml untuk menyimpan arahan tentang perubahan yang ingin dilakukan oleh pengguna pada set sumber.

Berikut adalah contoh fail kustomization.yaml:

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

Saya tidak akan cuba bercakap tentang semua medan yang mungkin dalam fail. kustomization.yaml (ini ditulis dengan baik tentang di sini), tetapi saya akan memberikan penjelasan ringkas tentang contoh khusus:

• Bidang resources menunjukkan apa (sumber mana) kustomize akan berubah. Dalam kes ini, ia akan mencari sumber dalam fail deployment.yaml и service.yaml dalam direktori anda (anda boleh menentukan laluan penuh atau relatif jika perlu).
• Bidang namePrefix mengarahkan kustomize untuk menambah awalan tertentu (dalam kes ini - dev-) untuk atribut name semua sumber yang ditakrifkan dalam bidang resources. Oleh itu, jika Deployment mempunyai name dengan makna nginx-deployment, sesuaikan akan berjaya dev-nginx-deployment.
• Bidang namespace mengarahkan kustomize untuk menambah ruang nama yang diberikan kepada semua sumber. Dalam kes ini, Deployment dan Service akan jatuh ke dalam ruang nama development.
• Akhirnya, padang commonLabels mengandungi set label yang akan ditambahkan pada semua sumber. Dalam contoh kami, kustomize akan memberikan label kepada sumber dengan nama itu environment dan makna development.

Jika pengguna lakukan kustomize build . dalam direktori dengan fail kustomization.yaml dan sumber yang diperlukan (iaitu fail deployment.yaml и service.yaml), maka pada output ia akan menerima teks dengan perubahan yang dinyatakan dalam kustomization.yaml.

Catatan. terjemah: Ilustrasi daripada dokumentasi projek mengenai penggunaan "mudah" kustomize

Output boleh diubah hala jika perubahan perlu dilakukan:

kustomize build . > custom-config.yaml

Data output adalah deterministik (data input yang sama akan menghasilkan hasil output yang sama), jadi anda tidak perlu menyimpan hasilnya ke fail. Sebaliknya, ia boleh dihantar terus ke arahan lain:

kustomize build . | kubectl apply -f -

Ciri kustomize juga boleh diakses melalui kubectl -k (sejak Kubernetes versi 1.14). Walau bagaimanapun, perlu diingat bahawa pakej kustomize kendiri dikemas kini lebih cepat daripada pakej kubectl bersepadu (sekurang-kurangnya ini berlaku dengan keluaran Kubernetes 1.15).

Pembaca mungkin bertanya: "Mengapa semua kerumitan ini jika anda boleh mengedit fail secara terus?" Soalan yang hebat. Dalam contoh kita, sesungguhnya seseorang boleh mengubah suai fail deployment.yaml и service.yaml secara langsung, tetapi bagaimana jika mereka adalah garpu projek orang lain? Menukar fail secara langsung menyukarkan (jika tidak mustahil) untuk meletakkan semula garpu apabila perubahan dibuat pada asal/sumber. Menggunakan kustomize membolehkan anda memusatkan perubahan ini dalam fail kustomization.yaml, meninggalkan fail asal utuh dan dengan itu memudahkan untuk mengasaskan semula fail asal jika perlu.

Faedah kustomize menjadi jelas dalam kes penggunaan yang lebih kompleks. Dalam contoh di atas kustomization.yaml dan sumber berada dalam direktori yang sama. Walau bagaimanapun, kustomize menyokong kes penggunaan di mana terdapat konfigurasi asas dan banyak variasinya, juga dikenali sebagai overlays. Sebagai contoh, pengguna ingin mengambil Deployment and Service untuk nginx, yang saya gunakan sebagai contoh, dan mencipta pembangunan, pementasan dan versi pengeluaran (atau varian) fail tersebut. Untuk melakukan ini, dia memerlukan tindanan yang disebutkan di atas dan, sebenarnya, sumber asas itu sendiri.

Untuk menggambarkan idea tindanan dan sumber asas (sumber asas), mari kita anggap bahawa direktori mempunyai struktur berikut:

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

Dalam fail base/kustomization.yaml pengguna menggunakan medan resources hanya mengisytiharkan sumber yang perlu disertakan oleh kustomize.

Dalam setiap fail overlays/{dev,staging,prod}/kustomization.yaml pengguna merujuk kepada konfigurasi asas dalam medan resources, dan kemudian nyatakan perubahan khusus untuk persekitaran yang diberikan. Sebagai contoh, fail overlays/dev/kustomization.yaml mungkin kelihatan seperti contoh yang diberikan sebelum ini:

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

Dalam kes ini fail overlays/prod/kustomization.yaml mungkin berbeza sama sekali:

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

Apabila pengguna berjalan kustomize build . dalam katalog overlays/dev, kustomize akan menjana pilihan pembangunan. Jika anda berlari kustomize build . dalam katalog overlays/prod - anda mendapat pilihan pengeluaran. Dan semua ini - tanpa membuat sebarang perubahan kepada yang asal (asas) fail, semuanya dalam cara deklaratif dan deterministik. Anda boleh menetapkan konfigurasi asas dan direktori tindanan terus ke kawalan versi, dengan mengetahui bahawa berdasarkan fail ini anda boleh menghasilkan semula konfigurasi yang diingini pada bila-bila masa.

Catatan. terjemah: Ilustrasi daripada dokumentasi projek tentang penggunaan tindanan dalam kustomize

Sesuaikan boleh banyak lebih daripada yang dibincangkan dalam artikel ini. Walau bagaimanapun, saya harap ia berfungsi sebagai pengenalan yang baik.

Sumber tambahan

Terdapat banyak artikel dan penerbitan yang bagus tentang kustomize. Berikut adalah beberapa yang saya dapati amat berguna:

• Tukar konfigurasi YAML asas untuk prod/ujian persekitaran yang berbeza menggunakan Kustomize;
• Kustomize — Cara yang betul untuk melakukan templat dalam Kubernetes;
• Pengurusan Perisytiharan Objek Kubernetes Menggunakan Sesuaikan;
• Menyesuaikan Carta Helm Hulu dengan Sesuaikan.

Catatan. terjemah: Anda juga boleh mengesyorkan blok pautan yang diterbitkan sebagai Sumber di tapak web utiliti, diikuti dengan koleksi video dengan laporan terkini tentang kustomize.

Jika anda mempunyai soalan atau cadangan untuk menambah baik bahan ini, saya sentiasa terbuka untuk menerima maklum balas. Anda boleh menghubungi saya di Twitter atau Saluran Kubernetes Slack. Berseronoklah mengubah suai manifes anda dengan kustomize!

PS daripada penterjemah

Baca juga di blog kami:

• «Alat untuk pembangun aplikasi yang berjalan pada Kubernetes»;
• «Kubernetes 1.14: gambaran keseluruhan inovasi utama»;
• «Lima keputusan utama Helm Summit 2019 di Amsterdam»;
• «Pengenalan praktikal kepada pengurus pakej untuk Kubernetes - Helm'.

Sumber: www.habr.com