Mengikuti
shell-operator, kami memperkenalkan kakaknya -
addon-operator . Ini adalah proyek Open Source yang digunakan untuk menginstal komponen sistem di kluster Kubernetes, yang dapat disebut kata umum - add-on.
Mengapa ada penambahan sama sekali?
Bukan rahasia lagi bahwa Kubernetes bukanlah produk jadi lengkap, dan berbagai tambahan akan diperlukan untuk membangun kluster "dewasa". Addon-operator akan membantu untuk menginstal, mengkonfigurasi dan menjaga pengaya ini tetap terbaru.
Kebutuhan komponen tambahan dalam klaster diungkapkan dalam
laporan oleh rekan
driusha . Singkatnya, situasi dengan Kubernet saat ini adalah bahwa untuk instalasi sederhana Anda dapat "bermain-main" dengan komponen di luar kotak, untuk pengembang dan pengujian Anda dapat menambahkan Ingress, tetapi untuk instalasi penuh, yang dapat Anda katakan "produksi Anda sudah siap," Anda perlu menambahkan selusin pengaya yang berbeda: sesuatu untuk pemantauan, sesuatu untuk log, jangan lupa masuk dan pengelola sertifikat, pilih grup host, tambahkan kebijakan jaringan, musim dengan pengaturan sysctl dan pod autoscaler ...
Apa spesifiknya bekerja dengan mereka?
Seperti yang ditunjukkan oleh praktik, kasing tidak terbatas pada satu pemasangan. Untuk pekerjaan yang nyaman dengan cluster, add-on perlu diperbarui, dinonaktifkan (dihapus dari cluster), dan Anda ingin menguji sesuatu sebelum menginstalnya di cluster produksi.
Jadi mungkin Ansible sudah cukup di sini? Mungkin Tetapi
penambahan penuh dalam kasus umum tidak hidup tanpa pengaturan . Pengaturan ini dapat bervariasi tergantung pada opsi cluster (aws, gce, azure, bare-metal, do, ...). Beberapa pengaturan tidak dapat diatur sebelumnya - mereka harus diperoleh dari cluster. Dan cluster tidak statis: untuk beberapa pengaturan Anda harus mengikuti perubahan. Dan di sini Ansible sudah hilang: kita membutuhkan program yang hidup dalam sebuah cluster, mis. Operator Kubernetes.
Mereka yang telah mencoba
operator shell yang beroperasi akan mengatakan bahwa tugas menginstal dan memperbarui add-on dan pengaturan pelacakan dapat sepenuhnya diselesaikan dengan bantuan
kait untuk operator shell. Anda dapat menulis skrip yang akan melakukan kondisional
kubectl apply dan memantau, misalnya, ConfigMap, di mana pengaturan akan disimpan. Ini kira-kira apa yang diterapkan dalam addon-operator.
Bagaimana ini diatur dalam addon-operator?
Menciptakan solusi baru, kami melanjutkan dari prinsip-prinsip berikut:
- Pemasang add-on harus mendukung konfigurasi templating dan deklaratif . Kami tidak melakukan skrip ajaib yang memasang pengaya. Addon-operator menggunakan Helm untuk menginstal add-ons. Untuk menginstal, Anda perlu membuat bagan dan menyoroti nilai-nilai yang akan digunakan untuk mengonfigurasi.
- Pengaturan dapat dihasilkan selama instalasi , mereka dapat diperoleh dari cluster , atau menerima pembaruan dengan memonitor sumber daya cluster. Operasi ini dapat diimplementasikan menggunakan kait.
- Pengaturan dapat disimpan dalam sebuah cluster . Untuk menyimpan pengaturan di cluster, operator ConfigMap / addon dibuat dan operator Addon memantau perubahan ConfigMap ini. Addon-operator memberikan kait akses ke pengaturan menggunakan konvensi sederhana.
- Penambahan tergantung pada pengaturan . Jika pengaturan telah berubah, maka Addon-operator meluncurkan Helm-chart dengan nilai-nilai baru. Gabungan dari grafik Helm, nilai untuknya, dan kaitan yang kami sebut modul (lihat di bawah untuk detail lebih lanjut).
- Pementasan . Tidak ada skrip rilis ajaib. Mekanisme pembaruan serupa dengan aplikasi biasa - kumpulkan add-ons dan addon-operator ke dalam gambar, uji dan jalankan.
- Kontrol hasilnya . Addon-operator dapat memberikan metrik untuk Prometheus.
Apa addon di operator addon?
Tambahan bisa dianggap segala sesuatu yang menambahkan fungsi baru ke cluster. Misalnya, menginstal Ingress adalah contoh add-on yang bagus. Ini bisa berupa operator atau pengontrol dengan CRD-nya sendiri: prometheus-operator, cert-manager, kube-controller-manager, dll. Atau sesuatu yang kecil, tetapi menyederhanakan operasi - misalnya, mesin fotokopi rahasia, menyalin rahasia registri ke ruang nama baru, atau sysctl tuner, mengkonfigurasi parameter sysctl pada node baru.
Addon-operator menyediakan beberapa konsep untuk mengimplementasikan add-ons:
- Grafik Helm digunakan untuk menginstal berbagai perangkat lunak ke dalam kluster - misalnya, Prometheus, Grafana, nginx-ingress. Jika komponen yang diperlukan memiliki grafik Helm, kemudian memasangnya menggunakan Addon-operator akan sangat sederhana.
- Menyimpan nilai . Helm biasanya memiliki banyak pengaturan yang berbeda yang dapat berubah seiring waktu. Addon-operator mendukung penyimpanan pengaturan ini dan dapat memonitor perubahannya untuk mengatur ulang Helm-chart dengan nilai-nilai baru.
- Hooks adalah file yang dapat dieksekusi yang dijalankan oleh Addon-operator pada acara dan yang mengakses penyimpanan nilai. Hook bisa memantau perubahan dalam cluster dan memperbarui nilai di penyimpanan nilai. Yaitu dengan bantuan kait, Anda dapat membuat penemuan untuk mengumpulkan nilai-nilai dari cluster saat startup atau sesuai dengan jadwal, atau penemuan terus-menerus, dengan mengumpulkan nilai-nilai dari cluster dengan perubahan dalam cluster.
- Modul adalah gabungan dari grafik Helm, penyimpanan nilai dan kait. Modul dapat dihidupkan dan dimatikan. Menonaktifkan modul adalah penghapusan semua rilis grafik Helm. Modul dapat menyalakan dirinya sendiri secara dinamis, misalnya, jika semua modul yang ia butuhkan dimasukkan atau jika penemuan menemukan parameter yang diperlukan dalam kait - ini dilakukan dengan menggunakan skrip bantu yang diaktifkan.
- Kait global Ini adalah “sendiri” kait, mereka tidak termasuk dalam modul dan memiliki akses ke penyimpanan nilai global, nilai yang tersedia untuk semua kait dalam modul.
Bagaimana bagian-bagian ini bekerja bersama? Perhatikan gambar dari dokumentasi:
Dua skenario kerja:
- Hook global dipicu oleh suatu peristiwa - misalnya, ketika sumber daya dalam sebuah cluster berubah. Hook ini memproses perubahan dan menulis nilai baru ke penyimpanan nilai global. Pemberitahuan operator tambahan bahwa penyimpanan global telah berubah dan meluncurkan semua modul. Setiap modul, menggunakan kaitnya, menentukan apakah perlu dinyalakan dan memperbarui nilainya. Jika modul diaktifkan, maka Addon-operator memulai pemasangan Helm-chart. Dalam hal ini, nilai-nilai dari penyimpanan modul dan dari penyimpanan global dapat diakses oleh Helm-chart.
- Skenario kedua lebih sederhana: kait modul dipicu oleh suatu peristiwa, mengubah nilai dalam penyimpanan nilai modul. Addon-operator memperhatikan ini dan meluncurkan grafik Helm dengan nilai yang diperbarui.
Add-on dapat diimplementasikan sebagai pengait tunggal atau sebagai satu Helm-chart, atau
bahkan sebagai beberapa modul dependen - ini tergantung pada kompleksitas komponen yang dipasang di cluster dan pada tingkat fleksibilitas konfigurasi yang diinginkan. Sebagai contoh, di repositori (
/ contoh ) ada tambahan sysctl-tuner, yang diimplementasikan baik sebagai modul sederhana dengan kait dan grafik Helm, dan menggunakan penyimpanan nilai, yang memungkinkan untuk menambahkan pengaturan melalui pengeditan ConfigMap.
Perbarui pengiriman
Beberapa kata tentang organisasi pembaruan komponen yang diinstal Addon-operator.
Untuk menjalankan Addon-operator dalam sebuah cluster, Anda perlu
mengumpulkan gambar dengan penambahan dalam bentuk file hook dan helm, menambahkan file biner
addon-operator dan segala sesuatu yang diperlukan untuk kait:
bash ,
kubectl ,
jq ,
python , dll. Selanjutnya, gambar ini dapat diluncurkan ke cluster sebagai aplikasi reguler, dan kemungkinan besar Anda ingin mengatur skema penandaan ini atau itu. Jika tidak ada banyak cluster, pendekatan yang sama dengan aplikasi mungkin cocok: rilis baru, versi baru, pergi ke semua cluster dan perbaiki gambar untuk Pods. Namun, dalam hal peluncuran ke sejumlah kluster, konsep pembaruan diri dari saluran lebih cocok untuk kita.
Kami mengaturnya seperti ini:
- Saluran pada dasarnya adalah pengidentifikasi yang dapat diatur oleh siapa saja (misalnya, dev / stage / ea / stable).
- Nama saluran adalah tag gambar. Saat Anda perlu meluncurkan pembaruan ke saluran, gambar baru dikumpulkan dan ditandai dengan nama saluran.
- Ketika gambar baru muncul di registri, Addon-operator restart dan mulai dengan gambar baru.
Ini bukan praktik terbaik, seperti yang dijelaskan dalam
dokumentasi Kubernetes . Ini tidak disarankan, tetapi kita berbicara tentang
aplikasi reguler yang hidup dalam satu cluster . Dalam kasus Addon-operator, aplikasi banyak Penyebaran tersebar di seluruh cluster, dan memperbarui diri sangat membantu dan menyederhanakan kehidupan.
Saluran membantu
dalam pengujian : jika ada kluster bantu, Anda dapat mengonfigurasinya di saluran
stage dan menggulung pembaruan sebelum meluncurkan ke saluran
ea dan
stable . Jika kesalahan terjadi dengan kluster pada saluran
ea , Anda bisa mengubahnya ke
stable saat investigasi masalah dengan kluster ini sedang berlangsung. Jika cluster ditarik dari dukungan aktif, itu beralih ke saluran "beku" - misalnya,
freeze-2019-03-20 .
Selain memperbarui kait dan bagan Helm, Anda mungkin perlu
memperbarui komponen pihak ketiga . Misalnya, Anda melihat ada kesalahan pada pengekspor simpul bersyarat dan bahkan menemukan cara untuk menambalnya. Kemudian kami membuka PR dan menunggu rilis baru untuk pergi melalui semua cluster dan meningkatkan versi gambar. Agar tidak menunggu tanpa batas waktu, Anda dapat mengumpulkan simpul-eksportir dan beralih ke sana sebelum menerima PR.
Secara umum, ini dapat dilakukan tanpa Addon-operator, tetapi dengan Addon-operator modul untuk menginstal node-eksportir akan terlihat dalam satu repositori, Anda dapat menjaga Dockerfile untuk membangun gambar Anda di sana, menjadi lebih mudah bagi semua peserta dalam proses untuk memahami bahwa terjadi ... Dan jika ada beberapa kelompok, menjadi lebih mudah untuk menguji PR Anda dan menggulung versi baru!
Organisasi pembaruan komponen ini berhasil bekerja dengan kami, tetapi Anda dapat menerapkan skema lain yang sesuai, karena
dalam hal ini Addon-operator adalah file biner sederhana .
Kesimpulan
Prinsip-prinsip yang diterapkan dalam Addon-operator memungkinkan Anda untuk membangun proses transparan untuk membuat, menguji, menginstal dan memperbarui add-on dalam sebuah cluster, mirip dengan proses pengembangan aplikasi biasa.
Add-on untuk Addon-operator dalam format modul (Helm-chart + hooks) dapat diunggah ke publik. Kami, perusahaan Flant, berencana untuk meletakkan prestasi kami selama musim panas dalam bentuk penambahan tersebut. Bergabunglah dengan pengembangan di GitHub (
operator shell ,
addon-operator ), cobalah membuat tambahan Anda berdasarkan
contoh dan
dokumentasi , tunggu berita di Habré dan di
saluran YouTube kami!
DIPERBARUI (14 Juni) : Jika Anda memiliki kolega berbahasa Inggris yang mungkin tertarik dengan operator tambahan, maka pengumuman yang sesuai untuk mereka tersedia di blog kami di Medium .PS
Baca juga di blog kami: