🥇Peranti Helm dan perangkapnya

Konsep pengangkut barang Typhon, Anton Swanepoel

Nama saya Dmitry Sugrobov, saya seorang pembangun di Leroy Merlin. Dalam artikel ini saya akan memberitahu anda mengapa Helm diperlukan, cara ia memudahkan kerja dengan Kubernetes, perkara yang telah berubah dalam versi ketiga dan cara menggunakannya untuk mengemas kini aplikasi dalam pengeluaran tanpa masa henti.

Ini adalah ringkasan berdasarkan ucapan di persidangan @Persidangan Kubernetes by Penyelesaian Awan Mail.ru — jika anda tidak mahu membaca, tonton video itu.

Sebab kami menggunakan Kubernetes dalam pengeluaran

Leroy Merlin ialah peneraju dalam pasaran runcit DIY di Rusia dan Eropah. Syarikat kami mempunyai lebih daripada seratus pembangun, 33 pekerja dalaman dan sebilangan besar orang yang melawat pasar raya besar dan laman web. Untuk menggembirakan mereka semua, kami memutuskan untuk mengikuti pendekatan standard industri. Membangunkan aplikasi baharu menggunakan seni bina perkhidmatan mikro; gunakan bekas untuk mengasingkan persekitaran dan memastikan penghantaran yang betul; dan gunakan Kubernetes untuk orkestrasi. Harga penggunaan orkestra menjadi lebih murah dengan pantas: bilangan jurutera yang mahir dalam teknologi semakin meningkat di pasaran, dan pembekal muncul menawarkan Kubernetes sebagai perkhidmatan.

Semua yang Kubernetes lakukan, sudah tentu, boleh dilakukan dengan cara lain, contohnya, dengan merangkumi beberapa Jenkins dan docker-compose dengan skrip, tetapi mengapa merumitkan kehidupan jika terdapat penyelesaian yang sedia dan boleh dipercayai? Itulah sebabnya kami datang ke Kubernetes dan telah menggunakannya dalam pengeluaran selama setahun sekarang. Pada masa ini kami mempunyai dua puluh empat gugusan Kubernetes, yang tertua adalah lebih daripada setahun, dengan kira-kira dua ratus buah.

Kutukan fail YAML yang besar dalam Kubernetes

Untuk melancarkan perkhidmatan mikro dalam Kubernetes, kami akan membuat sekurang-kurangnya lima fail YAML: untuk Deployment, Service, Ingress, ConfigMap, Secrets - dan menghantarnya ke kluster. Untuk aplikasi seterusnya kami akan menulis pakej jambs yang sama, dengan yang ketiga kami akan menulis satu lagi, dan seterusnya. Jika kita mendarabkan bilangan dokumen dengan bilangan persekitaran, kita sudah akan mendapat ratusan fail, dan ini belum lagi mengambil kira persekitaran dinamik.

Adam Reese, penyelenggara teras Helm, memperkenalkan konsep "Kitaran Pembangunan di Kubernetes", yang kelihatan seperti ini:

Salin YAML - salin fail YAML.
Tampal YAML - tampalkannya.
Betulkan Inden - betulkan inden.
Ulang - ulang lagi.

Pilihan ini berfungsi, tetapi anda perlu menyalin fail YAML berkali-kali. Untuk mengubah kitaran ini, Helm telah dicipta.

Apa itu Helm

Pertama, Helm - pengurus pakej, yang membantu anda mencari dan memasang program yang anda perlukan. Untuk memasang, sebagai contoh, MongoDB, anda tidak perlu pergi ke laman web rasmi dan memuat turun binari, hanya jalankan arahan helm install stable/mongodb.

Kedua, Helm - enjin templat, membantu meparameterkan fail. Mari kembali kepada situasi dengan fail YAML dalam Kubernetes. Lebih mudah untuk menulis fail YAML yang sama, tambahkan beberapa ruang letak padanya, di mana Helm akan menggantikan nilai. Iaitu, bukannya satu set perancah yang besar, akan ada satu set templat di mana nilai yang diperlukan akan digantikan pada masa yang tepat.

Ketiga, Helm - tuan penempatan. Dengan itu anda boleh memasang, melancarkan semula dan mengemas kini aplikasi. Mari kita fikirkan bagaimana untuk melakukan ini.

Cara menggunakan Helm untuk menggunakan aplikasi anda sendiri

Mari pasang klien Helm pada komputer anda, mengikut arahan rasmi Directions. Seterusnya, kami akan mencipta satu set fail YAML. Daripada menyatakan nilai tertentu, kami akan meninggalkan ruang letak, yang akan diisi oleh Helm dengan maklumat pada masa hadapan. Satu set fail sedemikian dipanggil carta Helm. Ia boleh dihantar kepada klien konsol Helm dalam tiga cara:

nyatakan folder dengan templat;
bungkus arkib ke dalam .tar dan tunjuk kepadanya;
letakkan templat dalam repositori jauh dan tambahkan pautan ke repositori dalam klien Helm.

Anda juga memerlukan fail dengan nilai - values.yaml. Data dari sana akan dimasukkan ke dalam templat. Mari menciptanya juga.

Versi kedua Helm mempunyai aplikasi pelayan tambahan - Tiller. Ia tergantung di luar Kubernetes dan menunggu permintaan daripada klien Helm, dan apabila dipanggil, menggantikan nilai yang diperlukan ke dalam templat dan menghantarnya ke Kubernetes.

Helm 3 adalah lebih mudah: daripada memproses templat pada pelayan, maklumat kini diproses sepenuhnya pada bahagian klien Helm dan dihantar terus ke API Kubernetes. Penyederhanaan ini meningkatkan keselamatan kelompok dan memudahkan skim pelancaran.

Bagaimana semuanya berfungsi

Jalankan arahan helm install. Mari nyatakan nama keluaran aplikasi dan berikan laluan ke values.yaml. Pada akhirnya kami akan menunjukkan repositori di mana carta terletak dan nama carta. Dalam contoh, ini ialah "lmru" dan "carta terbaik", masing-masing.

helm install --name bestapp --values values.yaml lmru/bestchart

Perintah itu boleh dilaksanakan sekali sahaja, sebaliknya apabila dilaksanakan semula install perlu guna upgrade. Untuk kesederhanaan, bukannya dua arahan, anda boleh menjalankan arahan itu upgrade dengan kunci tambahan --install. Apabila dilaksanakan buat kali pertama, Helm akan menghantar arahan untuk memasang keluaran dan akan mengemas kininya pada masa hadapan.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Kesalahan menggunakan versi baharu aplikasi dengan Helm

Pada ketika ini dalam cerita, saya memainkan Who Wants to Be a Millionaire dengan penonton, dan kami sedang memikirkan cara untuk mendapatkan Helm mengemas kini versi apl. Tonton videonya.

Semasa saya mempelajari cara Helm berfungsi, saya terkejut dengan tingkah laku pelik apabila cuba mengemas kini versi aplikasi yang sedang berjalan. Saya mengemas kini kod aplikasi, memuat naik imej baharu ke pendaftaran Docker, menghantar arahan penempatan - dan tiada apa yang berlaku. Di bawah ialah beberapa cara yang tidak berjaya sepenuhnya untuk mengemas kini aplikasi. Dengan mengkaji setiap daripada mereka dengan lebih terperinci, anda mula memahami struktur dalaman instrumen dan sebab untuk tingkah laku yang tidak jelas ini.

Kaedah 1. Jangan ubah maklumat sejak pelancaran terakhir

Seperti yang dikatakan laman rasmi Helm, "Carta Kubernetes boleh menjadi besar dan kompleks, jadi Helm cuba untuk tidak menyentuh apa-apa terlalu banyak." Oleh itu, jika anda mengemas kini versi terkini imej aplikasi dalam pendaftaran docker dan jalankan arahan helm upgrade, maka tiada apa yang akan berlaku. Helm akan berfikir bahawa tiada apa yang berubah dan tidak perlu menghantar arahan kepada Kubernetes untuk mengemas kini aplikasi.

Di sini dan di bawah, teg terkini ditunjukkan semata-mata sebagai contoh. Apabila anda menentukan teg ini, Kubernetes akan memuat turun imej daripada pendaftaran docker setiap kali, tanpa mengira parameter imagePullPolicy. Penggunaan terkini dalam pengeluaran adalah tidak diingini dan menyebabkan kesan sampingan.

Kaedah 2. Kemas kini LABEL dalam imej

Seperti yang ditulis dalam yang sama dokumentasi, "Helm hanya akan mengemas kini aplikasi jika ia telah berubah sejak keluaran terakhir." Pilihan logik untuk ini nampaknya mengemas kini LABEL dalam imej docker itu sendiri. Walau bagaimanapun, Helm tidak melihat ke dalam imej aplikasi dan tidak tahu tentang sebarang perubahan pada mereka. Sehubungan itu, apabila mengemas kini label dalam imej, Helm tidak akan mengetahui tentangnya dan arahan kemas kini aplikasi tidak akan dihantar ke Kubernetes.

Kaedah 3: Gunakan kunci --force

Mari beralih kepada manual dan cari kunci yang diperlukan. Kuncinya paling masuk akal --force. Walaupun nama yang jelas, tingkah laku berbeza daripada yang dijangkakan. Daripada memaksa kemas kini aplikasi, tujuan sebenarnya adalah untuk memulihkan keluaran yang berstatus GAGAL. Jika anda tidak menggunakan kunci ini, anda perlu melaksanakan arahan secara berurutan helm delete && helm install --replace. Adalah dicadangkan untuk menggunakan kunci sebaliknya --force, yang mengautomasikan pelaksanaan berurutan bagi arahan ini. Maklumat lanjut dalam ini permintaan tarik. Untuk memberitahu Helm mengemas kini versi aplikasi, malangnya, kunci ini tidak akan berfungsi.

Kaedah 4. Tukar label terus dalam Kubernetes

Mengemas kini label terus dalam kluster menggunakan arahan kubectl edit - idea yang tidak baik. Tindakan ini akan membawa kepada ketidakkonsistenan maklumat antara aplikasi yang sedang berjalan dan aplikasi yang pada asalnya dihantar untuk digunakan. Gelagat Helm semasa penggunaan dalam kes ini berbeza daripada versinya: Helm 2 tidak akan melakukan apa-apa dan Helm 3 akan menggunakan versi baharu aplikasi. Untuk memahami sebabnya, anda perlu memahami cara Helm berfungsi.

Bagaimanakah Helm berfungsi?

Untuk menentukan sama ada aplikasi telah berubah sejak keluaran terakhir, Helm boleh menggunakan:

menjalankan aplikasi dalam Kubernetes;
nilai baharu.yaml dan carta semasa;
Maklumat keluaran dalaman Helm.

Untuk yang lebih ingin tahu: di manakah Helm menyimpan maklumat dalaman tentang keluaran?Dengan melaksanakan arahan helm history, kami akan mendapat semua maklumat tentang versi yang dipasang menggunakan Helm.

Terdapat juga maklumat terperinci tentang templat dan nilai yang dihantar. Kami boleh memintanya:

Dalam versi kedua Helm, maklumat ini terletak dalam ruang nama yang sama di mana Tiller sedang berjalan (kube-sistem secara lalai), dalam ConfigMap, ditandakan dengan label "OWNER=TILLER":

Apabila versi ketiga Helm muncul, maklumat dipindahkan ke rahsia, dan ke ruang nama yang sama di mana aplikasi berjalan. Terima kasih kepada ini, ia menjadi mungkin untuk menjalankan beberapa aplikasi secara serentak dalam ruang nama yang berbeza dengan nama keluaran yang sama. Dalam versi kedua, ia adalah sakit kepala yang serius apabila ruang nama diasingkan tetapi boleh mempengaruhi satu sama lain.

Helm kedua, apabila cuba memahami sama ada kemas kini diperlukan, hanya menggunakan dua sumber maklumat: apa yang diberikan kepadanya sekarang dan maklumat dalaman tentang keluaran, yang terdapat dalam ConfigMap.

Helm ketiga menggunakan strategi gabungan tiga hala: sebagai tambahan kepada maklumat itu, ia juga mengambil kira aplikasi yang sedang berjalan sekarang dalam Kubernetes.

Atas sebab ini, versi lama Helm tidak akan melakukan apa-apa, kerana ia tidak mengambil kira maklumat aplikasi dalam kelompok, tetapi Helm 3 akan menerima perubahan dan menghantar aplikasi baharu untuk penggunaan.

Kaedah 5. Gunakan suis --recreate-pods

Dengan kunci --recreate-pods anda boleh mencapai apa yang anda rancang pada asalnya dengan kunci --force. Bekas akan dimulakan semula dan, menurut imagePullPolicy: Sentiasa dasar untuk teg terkini (lebih lanjut mengenai ini dalam nota kaki di atas), Kubernetes akan memuat turun dan melancarkan versi baharu imej. Ini tidak akan dilakukan dengan cara terbaik: tanpa mengambil kira StrategyType of deployment, ia akan mematikan semua contoh aplikasi lama secara tiba-tiba dan mula melancarkan yang baharu. Semasa restart, sistem tidak akan berfungsi, pengguna akan menderita.

Dalam Kubernetes sendiri, masalah serupa juga wujud sejak sekian lama. Dan sekarang, 4 tahun selepas pembukaan Isu, masalah telah dibetulkan dan bermula dengan versi 1.15 Kubernetes, keupayaan untuk melancarkan semula pod muncul.

Helm hanya mematikan semua aplikasi dan melancarkan bekas baharu berdekatan. Anda tidak boleh melakukan ini dalam pengeluaran, supaya tidak menyebabkan masa henti aplikasi. Ini hanya diperlukan untuk keperluan pembangunan dan hanya boleh dilakukan dalam persekitaran pentas.

Bagaimana untuk mengemas kini versi aplikasi menggunakan Helm?

Kami akan menukar nilai yang dihantar kepada Helm. Biasanya, ini adalah nilai yang digantikan sebagai ganti tag imej. Dalam kes terkini, yang sering digunakan untuk persekitaran yang tidak produktif, maklumat yang boleh diubah ialah anotasi, yang tidak berguna untuk Kubernetes sendiri, dan untuk Helm ia akan bertindak sebagai isyarat keperluan untuk mengemas kini aplikasi. Pilihan untuk mengisi nilai anotasi:

Nilai rawak menggunakan fungsi standard - {{ randAlphaNum 6 }}.
Terdapat kaveat: selepas setiap penggunaan menggunakan carta dengan pembolehubah sedemikian, nilai anotasi akan menjadi unik dan Helm akan menganggap bahawa terdapat perubahan. Ternyata kami akan sentiasa memulakan semula aplikasi, walaupun kami tidak menukar versinya. Ini tidak kritikal, kerana tidak akan ada masa henti, tetapi ia masih tidak menyenangkan.
Tampal arus tarikh dan masa - {{ .Release.Date }}.
Varian adalah serupa dengan nilai rawak dengan pembolehubah unik yang kekal.
Cara yang lebih betul ialah menggunakan jumlah semak. Ini ialah SHA imej atau SHA komit terakhir dalam git - {{ .Values.sha }}.
Mereka perlu dikira dan dihantar kepada pelanggan Helm di bahagian panggilan, contohnya di Jenkins. Jika aplikasi telah berubah, maka checksum akan berubah. Oleh itu, Helm hanya akan mengemas kini aplikasi apabila diperlukan.

Mari kita ringkaskan percubaan kita

Helm membuat perubahan dengan cara yang paling tidak invasif, jadi sebarang perubahan pada tahap imej aplikasi dalam Pendaftaran Docker tidak akan menghasilkan kemas kini: tiada apa yang akan berlaku selepas arahan itu dilaksanakan.
Kunci --force digunakan untuk memulihkan keluaran bermasalah dan tidak dikaitkan dengan kemas kini paksa.
Kunci --recreate-pods akan mengemas kini aplikasi secara paksa, tetapi akan melakukannya dengan cara yang merosakkan: ia akan mematikan semua bekas secara tiba-tiba. Pengguna akan mengalami ini; anda tidak sepatutnya melakukan ini dalam pengeluaran.
Buat perubahan terus pada gugusan Kubernetes menggunakan arahan kubectl edit jangan: kami akan memecahkan konsistensi, dan tingkah laku akan berbeza bergantung pada versi Helm.
Dengan keluaran versi baharu Helm, banyak nuansa telah muncul. Isu dalam repositori Helm diterangkan dalam bahasa yang jelas, ia akan membantu anda memahami butirannya.
Menambah anotasi boleh diedit pada carta akan menjadikannya lebih fleksibel. Ini akan membolehkan anda melancarkan aplikasi dengan betul, tanpa masa henti.

Pemikiran "keamanan dunia" yang berfungsi dalam semua bidang kehidupan: baca arahan sebelum digunakan, bukan selepas. Hanya dengan maklumat yang lengkap akan dapat membina sistem yang boleh dipercayai dan menggembirakan pengguna.

Pautan lain yang berkaitan:

Laporan ini pertama kali dibentangkan di @Persidangan Kubernetes oleh Mail.ru Cloud Solutions. Tengok video persembahan lain dan melanggan pengumuman acara di Telegram Sekitar Kubernetes di Mail.ru Group.

Sumber: www.habr.com

Peranti Helm dan perangkapnya