🥇Adakah mudah dan senang untuk menyediakan kluster Kubernetes? Mengumumkan pengendali addon

Selepas pengendali shell kami menghadiahkan abangnya - pengendali tambahan. Ini ialah projek Sumber Terbuka yang digunakan untuk memasang komponen sistem ke dalam kelompok Kubernetes, yang boleh dipanggil alat tambah.

Mengapa ada penambahan sama sekali?

Bukan rahsia lagi bahawa Kubernetes bukanlah produk semua-dalam-satu siap pakai, dan untuk membina kelompok "dewasa" anda memerlukan pelbagai tambahan. Pengendali Addon akan membantu anda memasang, mengkonfigurasi dan memastikan alat tambah ini dikemas kini.

Keperluan untuk komponen tambahan dalam kelompok didedahkan dalam lapor Rakan sekerja driusha. Ringkasnya, situasi dengan Kubernetes pada masa ini adalah sedemikian rupa sehingga untuk pemasangan "bermain-main" yang mudah anda boleh bertahan dengan komponen di luar kotak, untuk pembangun dan ujian anda boleh menambah Ingress, tetapi untuk pemasangan penuh, yang mana anda boleh mengatakan "pengeluaran anda sudah sedia", anda perlu menambah dengan sedozen alat tambah yang berbeza: sesuatu untuk pemantauan, sesuatu untuk pembalakan, jangan lupa kemasukan dan pengurus sijil, pilih kumpulan nod, tambah dasar rangkaian, musim dengan tetapan sysctl dan pod autoscaler...

Apakah spesifikasi bekerja dengan mereka?

Seperti yang ditunjukkan oleh amalan, perkara itu tidak terhad kepada satu pemasangan. Untuk berfungsi dengan selesa dengan kluster, alat tambah perlu dikemas kini, dilumpuhkan (dialih keluar daripada kluster) dan anda perlu menguji beberapa sebelum memasangnya dalam kluster pengeluaran.

Jadi, mungkin Ansible akan cukup di sini? Mungkin. Tetapi Secara umum, alat tambah penuh tidak akan hidup tanpa tetapan. Tetapan ini mungkin berbeza bergantung pada varian kluster (aws, gce, azure, bare-metal, do, ...). Sesetengah tetapan tidak boleh ditentukan terlebih dahulu; ia mesti diperoleh daripada kluster. Dan kluster tidak statik: untuk beberapa tetapan anda perlu memantau perubahan. Dan di sini Ansible sudah hilang: anda memerlukan program yang tinggal dalam kelompok, i.e. Operator Kubernetes.

Mereka yang mencubanya di tempat kerja pengendali shell, mereka akan mengatakan bahawa tugas memasang dan mengemas kini alat tambah dan tetapan pemantauan boleh diselesaikan sepenuhnya menggunakan cangkuk untuk shell-operator. Anda boleh menulis skrip yang akan melakukan bersyarat kubectl apply dan pantau, contohnya, ConfigMap, tempat tetapan akan disimpan. Ini adalah lebih kurang apa yang dilaksanakan dalam addon-operator.

Bagaimanakah ini dianjurkan dalam pengendali addon?

Apabila mencipta penyelesaian baharu, kami meneruskan daripada prinsip berikut:

Pemasang tambahan mesti menyokong templat dan konfigurasi deklaratif. Kami tidak membuat skrip ajaib yang memasang alat tambah. Addon-operator menggunakan Helm untuk memasang addon. Untuk memasang, anda perlu membuat carta dan pilih nilai yang akan digunakan untuk konfigurasi.
Tetapan boleh menjana pada pemasangan, mereka boleh dapatkan dari klusterAtau menerima kemas kini, memantau sumber kluster. Operasi ini boleh dilaksanakan menggunakan cangkuk.
Tetapan boleh simpan dalam kelompok. Untuk menyimpan tetapan dalam kelompok, ConfigMap/addon-operator dibuat dan Addon-operator memantau perubahan pada ConfigMap ini. Addon-operator memberikan cangkuk akses kepada tetapan menggunakan konvensyen mudah.
Penambahan bergantung pada tetapan. Jika tetapan telah berubah, maka pengendali Addon melancarkan carta Helm dengan nilai baharu. Kami memanggil gabungan carta Helm, nilai untuknya dan mengaitkan modul (lihat di bawah untuk butiran lanjut).
Pementasan. Tiada skrip keluaran ajaib. Mekanisme kemas kini adalah serupa dengan aplikasi biasa - kumpulkan alat tambah dan pengendali tambahan ke dalam imej, tandainya dan luncurkannya.
Kawalan keputusan. Addon-operator boleh menyediakan metrik untuk Prometheus.

Apakah padding dalam addon-operator?

Penambahan boleh dianggap apa sahaja yang menambah fungsi baharu pada kluster. Sebagai contoh, memasang Ingress ialah contoh alat tambah yang bagus. Ini boleh menjadi mana-mana pengendali atau pengawal dengan CRDnya sendiri: prometheus-operator, cert-manager, kube-controller-manager, dsb. Atau sesuatu yang kecil, tetapi lebih mudah untuk digunakan - contohnya, penyalin rahsia, yang menyalin rahsia pendaftaran ke ruang nama baharu, atau penala sysctl, yang mengkonfigurasi parameter sysctl pada nod baharu.

Untuk melaksanakan add-on, Addon-operator menyediakan beberapa konsep:

Carta helm digunakan untuk memasang pelbagai perisian ke dalam kelompok - contohnya, Prometheus, Grafana, nginx-ingress. Jika komponen yang diperlukan mempunyai carta Helm, maka memasangnya menggunakan Addon-operator akan menjadi sangat mudah.
Penyimpanan nilai. Carta helm biasanya mempunyai banyak tetapan berbeza yang boleh berubah dari semasa ke semasa. Addon-operator menyokong penyimpanan tetapan ini dan boleh memantau perubahannya untuk memasang semula carta Helm dengan nilai baharu.
cangkuk ialah fail boleh laku yang dikendalikan oleh pengendali Addon pada acara dan yang mengakses stor nilai. Cangkuk boleh memantau perubahan dalam kelompok dan mengemas kini nilai dalam stor nilai. Itu. Menggunakan cangkuk, anda boleh membuat penemuan untuk mengumpul nilai daripada kluster pada permulaan atau mengikut jadual, atau anda boleh melakukan penemuan berterusan, mengumpul nilai daripada kluster berdasarkan perubahan dalam kluster.
Modul ialah gabungan carta Helm, stor nilai dan cangkuk. Modul boleh didayakan atau dilumpuhkan. Melumpuhkan modul bermakna memadam semua keluaran carta Helm. Modul boleh mendayakan diri mereka sendiri secara dinamik, contohnya, jika semua modul yang diperlukannya didayakan atau jika penemuan telah menemui parameter yang diperlukan dalam cangkuk - ini dilakukan menggunakan skrip yang didayakan tambahan.
Cangkuk global. Ini adalah cangkuk "sendiri", mereka tidak termasuk dalam modul dan mempunyai akses kepada kedai nilai global, yang nilainya tersedia untuk semua cangkuk dalam modul.

Bagaimanakah bahagian ini berfungsi bersama? Mari lihat gambar dari dokumentasi:

Terdapat dua senario kerja:

Cangkuk global dicetuskan oleh peristiwa - contohnya, apabila sumber dalam kelompok berubah. Cangkuk ini memproses perubahan dan menulis nilai baharu ke kedai nilai global. Addon-operator menyedari bahawa storan global telah berubah dan memulakan semua modul. Setiap modul, menggunakan cangkuknya, menentukan sama ada ia perlu didayakan dan mengemas kini stor nilainya. Jika modul didayakan, pengendali Addon memulakan pemasangan carta Helm. Dalam kes ini, carta Helm mempunyai akses kepada nilai daripada storan modul dan daripada storan global.
Senario kedua adalah lebih mudah: cangkuk modul dicetuskan oleh peristiwa dan menukar nilai dalam stor nilai modul. Addon-operator menyedari perkara ini dan melancarkan carta Helm dengan nilai yang dikemas kini.

Penambahan boleh dilaksanakan sebagai satu cangkuk tunggal, atau sebagai satu carta Helm, atau walaupun sebagai beberapa modul bergantung - ini bergantung pada kerumitan komponen yang dipasang dalam kelompok dan pada tahap fleksibiliti konfigurasi yang dikehendaki. Sebagai contoh, dalam repositori (/contoh) terdapat add-on sysctl-tuner, yang dilaksanakan sebagai modul mudah dengan cangkuk dan carta Helm, dan menggunakan kedai nilai, yang memungkinkan untuk menambah tetapan dengan mengedit ConfigMap.

Penghantaran kemas kini

Beberapa perkataan tentang mengatur kemas kini komponen yang dipasang oleh pengendali Addon.

Untuk menjalankan Addon-operator dalam kelompok, anda perlukan membina imej dengan tambahan dalam bentuk fail carta cangkuk dan Helm, tambahkan fail binari addon-operator dan semua yang anda perlukan untuk cangkuk: bash, kubectl, jq, python dan lain-lain. Kemudian imej ini boleh dilancarkan ke kluster sebagai aplikasi biasa, dan kemungkinan besar anda akan mahu mengatur satu atau satu lagi skim penandaan. Jika terdapat beberapa kluster, pendekatan yang sama seperti dengan aplikasi mungkin sesuai: keluaran baharu, versi baharu, pergi ke semua kluster dan betulkan imej Pod. Walau bagaimanapun, dalam kes pelancaran kepada sejumlah besar kelompok, konsep mengemas kini sendiri daripada saluran adalah lebih sesuai untuk kami.

Begini cara kami melakukannya:

Saluran pada asasnya ialah pengecam yang boleh ditetapkan kepada apa-apa sahaja (contohnya, dev/stage/ea/stable).
Nama saluran ialah tag imej. Apabila anda perlu melancarkan kemas kini pada saluran, imej baharu akan dipasang dan ditanda nama saluran.
Apabila imej baharu muncul dalam registri, Addon-operator dimulakan semula dan dilancarkan dengan imej baharu.

Ini bukan amalan terbaik, seperti yang tertulis dalam dokumentasi Kubernetes. Ia tidak disyorkan untuk melakukan ini, tetapi kita bercakap tentang aplikasi biasa yang tinggal dalam kelompok yang sama. Dalam kes pengendali Addon, aplikasi ialah banyak Deployment yang tersebar di seluruh kelompok, dan pengemaskinian sendiri banyak membantu dan menjadikan hidup lebih mudah.

Saluran membantu dan dalam ujian: jika terdapat kluster tambahan, anda boleh mengkonfigurasinya ke saluran stage dan masukkan kemas kini ke dalamnya sebelum melancarkannya ke saluran ea и stable. Jika dengan gugusan pada saluran ea ralat telah berlaku, anda boleh menukarnya kepada stable, sementara masalah dengan kluster ini sedang disiasat. Jika kluster dikeluarkan daripada sokongan aktif, ia bertukar kepada saluran "beku" - contohnya, freeze-2019-03-20.

Selain mengemas kini cangkuk dan carta Helm, anda mungkin perlu kemas kini dan komponen pihak ketiga. Sebagai contoh, anda melihat pepijat dalam pengeksport nod bersyarat dan juga mengetahui cara untuk menampalnya. Seterusnya, anda membuka PR dan sedang menunggu keluaran baharu untuk melalui semua kluster dan meningkatkan versi imej. Untuk tidak menunggu selama-lamanya, anda boleh membina pengeksport nod anda dan beralih kepadanya sebelum menerima PR.

Secara umum, ini boleh dilakukan tanpa Addon-operator, tetapi dengan Addon-operator modul untuk memasang nod-exporter akan kelihatan dalam satu repositori, Dockerfile untuk membina imej anda boleh disimpan di sana, ia menjadi lebih mudah untuk semua peserta dalam proses untuk memahami perkara yang berlaku... Dan jika terdapat beberapa kluster, maka menjadi lebih mudah untuk menguji PR anda dan melancarkan versi baharu!

Organisasi pengemaskinian komponen ini berjaya untuk kami, tetapi sebarang skim lain yang sesuai boleh dilaksanakan - selepas semua dalam kes ini Addon-operator ialah fail binari yang mudah.

Kesimpulan

Prinsip yang dilaksanakan dalam Addon-operator membolehkan anda membina proses yang telus untuk mencipta, menguji, memasang dan mengemas kini alat tambah dalam kelompok, serupa dengan proses pembangunan aplikasi biasa.

Alat tambah untuk Addon-operator dalam format modul (Carta Helm + cangkuk) boleh disediakan secara terbuka. Kami, syarikat Flant, merancang untuk menerbitkan perkembangan kami dalam bentuk tambahan tersebut semasa musim panas. Sertai pembangunan di GitHub (pengendali shell, pengendali tambahan), cuba buat penambahan anda sendiri berdasarkan contoh и dokumentasi, tunggu berita tentang Habré dan kami saluran YouTube!

Adakah mudah dan senang untuk menyediakan kluster Kubernetes? Mengumumkan pengendali addon