Setelah kami memperkenalkan kakak laki-lakinya - . Ini adalah proyek Open Source yang digunakan untuk menginstal komponen sistem ke dalam cluster Kubernetes, yang bisa disebut add-on.
Mengapa ada tambahan sama sekali?
Bukan rahasia lagi bahwa Kubernetes bukanlah produk lengkap yang siap pakai, dan untuk membangun cluster “dewasa” Anda memerlukan berbagai tambahan. Operator add-on akan membantu Anda menginstal, mengkonfigurasi, dan selalu memperbarui add-on ini.
Kebutuhan komponen tambahan dalam cluster diungkapkan dalam rekan kerja . Singkatnya, situasi dengan Kubernetes saat ini sedemikian rupa sehingga untuk instalasi "bermain-main" yang sederhana Anda dapat menggunakan komponen-komponen yang sudah ada, untuk pengembang dan pengujian Anda dapat menambahkan Ingress, tetapi untuk instalasi penuh, tentang hal itu Anda dapat mengatakan "produksi Anda sudah siap", Anda perlu menambahkan selusin add-on yang berbeda: sesuatu untuk pemantauan, sesuatu untuk logging, jangan lupa ingress dan cert-manager, pilih grup node, tambahkan kebijakan jaringan, musim dengan pengaturan sysctl dan pod autoscaler...
Apa spesifiknya bekerja dengan mereka?
Seperti yang ditunjukkan oleh praktik, masalahnya tidak terbatas pada satu instalasi. Agar dapat bekerja dengan nyaman dengan klaster, add-on perlu diperbarui, dinonaktifkan (dihapus dari klaster), dan Anda perlu menguji beberapa add-on sebelum menginstalnya di klaster produksi.
Jadi, mungkin Ansible cukup di sini? Mungkin. Tetapi Secara umum, add-on lengkap tidak akan berfungsi tanpa pengaturan. Pengaturan ini mungkin berbeda tergantung pada varian cluster (aws, gce, azure, bare-metal, do, ...). Beberapa pengaturan tidak dapat ditentukan sebelumnya; pengaturan tersebut harus diperoleh dari cluster. Dan cluster ini tidak statis: untuk beberapa pengaturan Anda harus memantau perubahan. Dan di sini Ansible sudah hilang: Anda memerlukan program yang berada dalam sebuah cluster, mis. Operator Kubernetes.
Mereka yang mencobanya di tempat kerja , mereka akan mengatakan bahwa tugas menginstal dan memperbarui add-on dan pengaturan pemantauan dapat diselesaikan sepenuhnya dengan menggunakan untuk operator shell. Anda dapat menulis skrip yang akan melakukan kondisi kubectl apply dan memantau, misalnya, ConfigMap, tempat pengaturan akan disimpan. Ini kira-kira apa yang diterapkan di addon-operator.
Bagaimana ini diatur dalam operator tambahan?
Saat membuat solusi baru, kami berangkat dari prinsip-prinsip berikut:
- Penginstal add-on harus mendukung konfigurasi templating dan deklaratif. Kami tidak membuat skrip ajaib yang memasang add-on. Operator addon menggunakan Helm untuk menginstal addons. Untuk menginstal, Anda perlu membuat bagan dan memilih nilai yang akan digunakan untuk konfigurasi.
- Pengaturannya bisa menghasilkan pada instalasi, mereka bisa menjadi dapatkan dari clusterAtau menerima pembaruan, memantau sumber daya cluster. Operasi ini dapat diimplementasikan dengan menggunakan kait.
- Pengaturannya bisa simpan dalam sebuah cluster. Untuk menyimpan pengaturan di cluster, ConfigMap/addon-operator dibuat dan Addon-operator memantau perubahan pada ConfigMap ini. Operator tambahan memberikan akses kait ke pengaturan menggunakan konvensi sederhana.
- Penambahan tergantung pada pengaturan. Jika pengaturan telah berubah, maka operator Addon akan meluncurkan diagram Helm dengan nilai baru. Kami menyebut kombinasi bagan Helm, nilainya, dan kaitan modul (lihat di bawah untuk lebih jelasnya).
- Memanggungkan. Tidak ada skrip rilis ajaib. Mekanisme pembaruan mirip dengan aplikasi biasa - kumpulkan add-on dan operator add-on ke dalam gambar, beri tag, dan luncurkan.
- Kontrol hasil. Operator tambahan dapat menyediakan metrik untuk Prometheus.
Apa itu padding di addon-operator?
Penambahan dapat dianggap sebagai segala sesuatu yang menambahkan fungsi baru ke cluster. Misalnya, menginstal Ingress adalah contoh add-on yang bagus. Ini bisa berupa operator atau pengontrol apa pun yang memiliki CRDnya sendiri: prometheus-operator, cert-manager, kube-controller-manager, dll. Atau sesuatu yang kecil, tetapi lebih mudah digunakan - misalnya, mesin fotokopi rahasia, yang menyalin rahasia registri ke ruang nama baru, atau sysctl tuner, yang mengonfigurasi parameter sysctl pada node baru.
Untuk mengimplementasikan add-on, Addon-operator menyediakan beberapa konsep:
- Bagan helm digunakan untuk menginstal berbagai perangkat lunak ke dalam cluster - misalnya, Prometheus, Grafana, nginx-ingress. Jika komponen yang dibutuhkan memiliki diagram Helm, maka instalasinya menggunakan operator Addon akan sangat sederhana.
- Penyimpanan nilai. Bagan helm biasanya memiliki banyak pengaturan berbeda yang dapat berubah seiring waktu. Operator tambahan mendukung penyimpanan pengaturan ini dan dapat memantau perubahannya untuk menginstal ulang bagan Helm dengan nilai baru.
- Kait adalah file yang dapat dieksekusi yang dijalankan oleh operator Addon pada acara dan mengakses penyimpanan nilai. Hook dapat memantau perubahan dalam cluster dan memperbarui nilai di penyimpanan nilai. Itu. Dengan menggunakan hooks, Anda dapat melakukan penemuan untuk mengumpulkan nilai dari cluster saat startup atau sesuai jadwal, atau Anda dapat melakukan penemuan berkelanjutan, mengumpulkan nilai dari cluster berdasarkan perubahan dalam cluster.
- Modul adalah kombinasi grafik Helm, penyimpanan nilai, dan kait. Modul dapat diaktifkan atau dinonaktifkan. Menonaktifkan modul berarti menghapus semua rilis grafik Helm. Modul dapat mengaktifkan dirinya sendiri secara dinamis, misalnya, jika semua modul yang diperlukan diaktifkan atau jika penemuan telah menemukan parameter yang diperlukan di hook - ini dilakukan dengan menggunakan skrip tambahan yang diaktifkan.
- Kait global. Ini adalah kait "sendiri", mereka tidak termasuk dalam modul dan memiliki akses ke penyimpanan nilai global, yang nilainya tersedia untuk semua kait dalam modul.
Bagaimana bagian-bagian ini bekerja sama? Mari kita lihat gambar dari dokumentasi:
Ada dua skenario kerja:
- Kait global dipicu oleh suatu peristiwa - misalnya, ketika sumber daya di cluster berubah. Kait ini memproses perubahan dan menulis nilai baru ke penyimpanan nilai global. Operator tambahan memperhatikan bahwa penyimpanan global telah berubah dan memulai semua modul. Setiap modul, menggunakan pengaitnya, menentukan apakah modul perlu diaktifkan dan memperbarui penyimpanan nilainya. Jika modul diaktifkan, operator Addon memulai instalasi diagram Helm. Dalam hal ini, bagan Helm memiliki akses ke nilai dari penyimpanan modul dan dari penyimpanan global.
- Skenario kedua lebih sederhana: kait modul dipicu oleh suatu peristiwa dan mengubah nilai di penyimpanan nilai modul. Operator tambahan memperhatikan hal ini dan meluncurkan bagan Helm dengan nilai yang diperbarui.
Penambahan dapat diimplementasikan sebagai satu hook tunggal, atau sebagai satu diagram Helm, atau bahkan sebagai beberapa modul dependen - ini tergantung pada kompleksitas komponen yang dipasang di cluster dan pada tingkat fleksibilitas konfigurasi yang diinginkan. Misalnya, di repositori () terdapat add-on sysctl-tuner, yang diimplementasikan baik sebagai modul sederhana dengan hook dan diagram Helm, dan menggunakan penyimpanan nilai, yang memungkinkan untuk menambahkan pengaturan dengan mengedit ConfigMap.
Pengiriman pembaruan
Beberapa kata tentang mengatur pembaruan komponen yang dipasang oleh operator Addon.
Untuk menjalankan Addon-operator di sebuah cluster, Anda memerlukan membangun gambar dengan tambahan berupa file grafik hook dan helm, ditambah file biner addon-operator dan semua yang Anda butuhkan untuk pengait: bash, kubectl, jq, python dll. Kemudian gambar ini dapat diluncurkan ke cluster sebagai aplikasi biasa, dan kemungkinan besar Anda ingin mengatur satu atau beberapa skema penandaan. Jika terdapat sedikit cluster, pendekatan yang sama seperti pada aplikasi mungkin cocok: rilis baru, versi baru, buka semua cluster dan perbaiki image Pod. Namun, dalam kasus peluncuran ke sejumlah besar klaster, konsep pembaruan mandiri dari saluran lebih cocok bagi kami.
Inilah cara kami melakukannya:
- Saluran pada dasarnya adalah pengenal yang dapat disetel ke apa pun (misalnya, dev/stage/ea/stable).
- Nama saluran adalah tag gambar. Saat Anda perlu meluncurkan pembaruan pada suatu saluran, gambar baru dikumpulkan dan diberi tag dengan nama saluran.
- Ketika gambar baru muncul di registri, operator Addon dimulai ulang dan diluncurkan dengan gambar baru.
Ini bukan praktik terbaik, seperti yang tertulis . Tidak disarankan untuk melakukan ini, tetapi yang sedang kita bicarakan aplikasi reguler yang berada di cluster yang sama. Dalam kasus Addon-operator, sebuah aplikasi memiliki banyak Deployment yang tersebar di seluruh cluster, dan pembaruan mandiri sangat membantu dan membuat hidup lebih mudah.
Saluran bantuan dan dalam pengujian: jika ada cluster tambahan, Anda dapat mengkonfigurasinya ke saluran stage dan meluncurkan pembaruan ke dalamnya sebelum meluncurkannya ke saluran ea и stable. Jika dengan cluster di saluran ea terjadi kesalahan, Anda dapat mengalihkannya ke stable, sementara masalah dengan cluster ini sedang diselidiki. Jika cluster dikeluarkan dari dukungan aktif, cluster akan beralih ke saluran "beku" - misalnya, freeze-2019-03-20.
Selain memperbarui grafik hook dan Helm, Anda mungkin perlu pembaruan dan komponen pihak ketiga. Misalnya, Anda melihat bug pada node-eksportir bersyarat dan bahkan menemukan cara untuk menambalnya. Selanjutnya, Anda membuka PR dan menunggu rilis baru melewati semua cluster dan meningkatkan versi gambar. Agar tidak menunggu tanpa batas waktu, Anda dapat membangun node-eksportir dan beralih ke sana sebelum menerima PR.
Secara umum hal ini dapat dilakukan tanpa Addon-operator, tetapi dengan Addon-operator modul untuk menginstal node-exporter akan terlihat dalam satu repositori, Dockerfile untuk membangun image Anda dapat disimpan di sana, sehingga lebih mudah bagi semua peserta dalam proses untuk memahami apa yang terjadi... Dan jika ada beberapa cluster, maka akan lebih mudah untuk menguji PR Anda dan meluncurkan versi baru!
Organisasi pembaruan komponen ini berhasil bagi kami, tetapi skema lain yang sesuai dapat diterapkan - bagaimanapun juga dalam hal ini Addon-operator adalah file biner sederhana.
Kesimpulan
Prinsip-prinsip yang diterapkan di Add-on-operator memungkinkan Anda 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 tersedia untuk umum. Kami, perusahaan Flant, berencana untuk mempublikasikan perkembangan kami dalam bentuk tambahan selama musim panas. Bergabunglah dengan pengembangan di GitHub (, ), coba buat tambahan sendiri berdasarkan и , tunggu berita di Habré dan di kami !
PS
Baca juga di blog kami:
- «»;
- «'.
Sumber: www.habr.com