Pengurus Pengawal Awan Kubernetes

Sila ambil perhatian bahawa siaran ini pada asalnya disiarkan oleh saya di medium.com, saya telah memutuskan untuk beralih ke dev.to sebaliknya!

Siaran ini mengandaikan bahawa anda mempunyai pengalaman dengan kedua-dua mengendalikan/menjalankan Kubernetes dan beberapa konsep bahasa pengaturcaraan Go.

Selama setengah tahun lepas kami telah banyak dengan OpenStack dan Kubernetes di Etraveli Group. Kami adalah penyedia awan kami sendiri dan pengguna akhir ialah pembangun dan pasukan sekitar dalam organisasi pembangunan.

Salah satu komponen utama menjalankan Kubernetes di atas OpenStack ialah Pengurus Pengawal Awan. Ia adalah salah satu kepingan yang melekatkan kedua-dua platform bersama-sama. Bagi anda yang bekerja dengan perkhidmatan Kubernetes terurus, dalam awan awam (atau peribadi untuk perkara itu) di suatu tempat, akan mempunyai ini disusun untuk anda. Pesawat kawalan Kubernetes akan berada di luar jangkauan anda.

Jadi mengapa perlu menulis sesuatu tentang Pengurus Pengawal Awan? Pemacu utama adalah soalan paling mudah yang ditanya oleh salah seorang rakan sekerja saya:

"Apa yang Pengurus Pengawal Awan (OpenStack) lakukan pula?"

Saya cuba menjawab soalan itu tetapi pada dasarnya saya tidak tahu apa yang saya perkatakan, saya tahu bahawa ia bertanggungjawab untuk mencipta pengimbang beban dalam awan asas apabila objek Perkhidmatan jenisLoadBalancer dicipta.

Saya dengan serta-merta memutuskan untuk menggali perkara ini sedikit dan akhirnya saya menggali dengan cukup dalam, cuba memahami setiap teka-teki dan dalam siaran ini saya akan meringkaskan penemuan saya.

Sepanjang siaran ini saya akan merujuk:

• Pengurus Pengawal Awan sebagai "CCM"

• Repositori kod sumber utama Kubernetes sebagai "k/k"

• Kubernetes sebagai "k8s"

Semasa saya mula menulis siaran ini, saya mencipta projek kecil dan repositori di mana saya telah membina Pengurus Pengawal Awan saya sendiri mengikut buku dan membandingkan dua kelompok kecil Kubernetes (v1.18.2) antara satu sama lain, satu menjalankan CCM dan satu yang tidak. Ia adalah bukti konsep dan bertujuan untuk menunjukkan kepada anda perkara yang anda perlukan untuk menjalankan CCM anda sendiri. Segala-galanya daripada kod yang membentuk CCM kepada manifes k8, anda perlu menggunakannya.

Sebelum kita bermula, adalah baik untuk mengetahui bahawa siaran ini memaut ke pelbagai bahagian repositori kod sumber k8s, saya telah menggunakan teg v1.18.0.

Semua ilustrasi adalah milik saya.

Nikmati!

Sila tinggalkan satu atau dua komen (!), sebarang maklum balas amat dihargai!

Pengurus Pengawal Awan

Pengurus Pengawal Awan boleh digambarkan sebagai tiga perkara berbeza melihatnya dari pandangan tahap tinggi:

• Perduaan

• Beberapa gelung kawalan

• Sebahagian daripada gam antara k8 dan awan anda

Kod dari segi CCM adalah sebahagian daripada k/k repo, lihat di sini. Seperti yang dinyatakan dalam dokumentasi rasmi k8s, kod untuk CCM dalam k/k boleh digunakan sebagai rangka untuk pelaksanaan anda sendiri. Perbezaannya ialah kod (pakej) yang anda sediakan dan import untuk berinteraksi dengan awan anda.

SSM akan paling kerap digunakan melalui manifes k8s dan binari terbina dalam bekas (Docker) ditarik daripada pendaftaran kontena yang terkenal.

Perlu diambil perhatian bahawa CCM akan diberikan port 10258 dan anda perlu mendedahkannya, jika perlu. Di luar kotak, CCM akan mendedahkan titik akhir /healthz untuk memeriksa kesihatan perkhidmatan.

Apabila melihat melalui organisasi k8s dalam GitHub, anda akan menemui beberapa pelaksanaan CCM yang berbeza, ia juga dipanggil CCM luaran kerana ia tinggal di luar repositori k/k dan terdiri daripada satu set antara muka Golang yang direka dengan baik sebagai serta minimum untuk sesiapa sahaja mencipta CCM mereka sendiri.

Kami akan melihat dengan terperinci semua ini kemudian.

Inti CCM terdiri daripada empat pengawal (awan) yang menjalankan gelung kawalan, secara pilihan anda boleh menjalankan pengawal anda sendiri bersama yang lain.

Kami akan melihat dengan lebih mendalam pada setiap pengawal awan yang dijalankan dalam SKM dalam bahagian seterusnya.

Pengawal Nod

Pengawal Nod memastikan bahawa nod awan anda (cth. VM) dilabel, dicemari dan dikemas kini dengan maklumat lain yang berkaitan daripada pembekal awan anda. Pengawal akan melakukan perkara berikut secara berkala, dalam senarai tidak tertib:

• Mulakan nod baharu yang ditambahkan pada penyedia awan dengan taint berikut: node.cloudprovider.kubernetes.io/uninitialized ditetapkan kepada benar dan kesan taint pada NoSchedule. Apabila nod dimulakan, oleh pengawal Nod, kotoran ini akan dialih keluar membenarkan beban kerja dijadualkan pada nod. Pod yang kritikal untuk cth. menjalankan kluster sudah tentu mempunyai toleransi yang diperlukan untuk dijadualkan pada nod yang sudah tercemar.

• Kemas kini alamat IP nod dengan membandingkan alamat IP dalam pembekal awan dengan yang disimpan dalam objek Nod dalam API k8s.

• Tambah atau kemas kini label nod dengan maklumat yang diberikan daripada awan, ini termasuk: jenis tika, domain kegagalan zon dan rantau zon. Maklumat khusus zon tidak wajib seperti yang akan kita lihat nanti.

Mengenai label nod dan cara maklumat tentang kejadian, yang dinyatakan di atas, diambil dan ditambah pada objek Nod. Untuk memberi anda contoh, CCM luaran OpenStack melakukan ini dengan sama ada membaca metadata daripada cakera (cakera konfigurasi) atau menggunakan titik akhir perkhidmatan metadata yang boleh dicapai dalam setiap nod.

Pengawal perkhidmatan

Pengawal Perkhidmatan akan mengendalikan semua yang berkaitan dengan kitaran hayat pengimbang beban berasaskan objek Perkhidmatan yang dibuat dalam awan anda. Perkhidmatan menyediakan cara untuk mendedahkan aplikasi anda secara dalaman dan/atau luaran dalam perspektif kelompok k8s.

Pengawal khusus ini hanya akan mengendalikan objek Perkhidmatan jenis LoadBalancer. Ini bermakna, dari perspektif penyedia awan, ia akan memastikan bahawa pengimbang beban semacam dibuat, dipadamkan dan dikemas kini dalam awan anda.

Bergantung pada cara CCM anda telah melaksanakan logik pengawal Perkhidmatan, anda boleh mencipta pengimbang beban awan yang hanya memuatkan trafik rangkaian baki secara dalaman dalam awan. Ini biasanya dilakukan dengan mentakrifkan satu set anotasi dalam bahagian metadata objek Perkhidmatan.

Sila ambil perhatian bahawa tingkah laku lalai, seperti yang saya nyatakan dalam cth. OpenStack, ialah objek berikut akan dibuat apabila menggunakan manifes objek Perkhidmatan mudah (jenis LoadBalancer):

• Pengimbang beban awan dengan senarai nod yang dihuni tempat trafik akan diimbangi beban. Pengimbang beban akan menghala pada setiap nod dengan menggunakan NodePort rawak yang dihasilkan

• Objek Perkhidmatan jenis NodePort

Seperti yang dilihat di atas sebenarnya terdapat beberapa perkara yang membentuk objek Perkhidmatan dalam kedua-dua k8 dan pembekal awan. Bagi pengguna ini bermakna lajur EXTERNAL-IP akan diisi dengan IP pembekal awan bagi pengimbang beban awan. Dilihat apabila menyenaraikan objek Perkhidmatan menggunakan kubectl :

$> kubectl get service my-app-svc
NAME       TYPE         CLUSTER-IP    EXTERNAL-IP     PORT(S)
my-app-svc LoadBalancer 172.20.10.100 123.123.123.123 80:31147/TCP

Pengawal laluan

Daripada empat pengawal itu terdapat satu yang agak istimewa dan itu ialah pengawal Laluan (Awan), ia tidak akan dimulakan melainkan anda memberikan bendera --allocate-node-cidrs atau --configure-cloud-routes kepada CCM. Juga jika anda belum melaksanakan sebarang logik pengendalian laluan maka pengawal ini tidak akan bermula, lebih lanjut mengenai perkara ini kemudian.

Pengawal ini secara berkala akan cuba melakukan perkara berikut:

• Senaraikan semua laluan yang dikaitkan dengan gugusan k8s, ini dilakukan dengan menanyakan API pembekal awan.

• Senaraikan semua Nod dengan menanyakan API k8s.

• Gelung melalui setiap medan Nod dan thepodCIDRs bagi spesifikasi Nod. CIDR Pod dan nama nod akan digunakan untuk membuat laluan melalui API penyedia awan.

Selain itu, semasa gelung kawalan, pengawal akan memadamkan laluan yang tidak digunakan. Apabila semua laluan telah dibuat, Nod akan dianggap sedia, maksudnya ialah medan keadaan nod NetworkUnavailable akan ditetapkan kepada false . Jika nod tidak mempunyai sebarang laluan yang dikaitkan dengannya, medan NetworkUnavailable akan ditetapkan kepada benar . Syarat ini diterjemahkan ke dalam kotoran oleh pengawal NodeLifeCycle, tidak boleh dikelirukan dengan syarat yang bertanggungjawab oleh CCM.

Pengawal kitaran hayat

Pengawal kitaran hayat (Cloud Nod) akan memastikan bahawa nod anda, yang diwakili sebagai objek Nod API Kubernetes dialih keluar jika nod dialih keluar daripada awan anda.

Juga jika nod berada dalam keadaan penutupan yang ditentukan oleh penyedia awan, nod akan tercemar dengan sewajarnya dengan node.cloudprovider.kubernetes.io/shutdown dan kesan taint NoSchedule .

Itulah kira-kira semua fungsi yang anda akan dapat daripada CCM, selalunya awan anda mungkin mempunyai pengawalnya sendiri (disediakan dalam binari berasingan daripada repositori berasingan) untuk mengendalikan objek k8s jenis Ingress , atau membantu anda berintegrasi secara asli dengan infrastruktur rangkaian asas.

SSM tidak akan menjadi penyelesaian kedai sehenti, ia hanya pada kepingan teka-teki yang lebih besar.

Jika anda telah mengikutinya, dan mungkin telah melihat kod sumber pengawal berbeza yang dikendalikan oleh CCM, anda mungkin perasan bahawa tiada kod khusus pembekal awan di mana-mana sahaja untuk dilihat. Terdapat hanya sekumpulan panggilan kepada kaedah yang agak misteri pada pelbagai objek.

Kod khusus pembekal awan dan pendawaiannya akan menjadi bahagian teka-teki CCM yang hilang ini.

Pandangan di cermin pandang belakang

Sebelum beralih pada pakej penyedia awan (k8s.io/cloud-provider), bahagian teka-teki CCM yang hilang, kami akan meneliti beberapa sejarah di sebalik CCM dan penyedia awan. Bagaimana mereka telah berkembang selama bertahun-tahun dan bagaimana semuanya berlaku.

Sejak awal lagi, penyepaduan awan telah menjadi asas kepada sebahagian daripada k8, atas sebab yang jelas. Mari kita lihat penyedia awan yang mempunyai kod pembekal khusus mereka dalam repositori k8s (k/k) v1.0 , yang dikeluarkan pada Julai 2015:

• AWS
• GCE
• Mesos
• OpenStack
• Ovirt
• Rackspace
• Kurang ajar

Anda mungkin mengenali semua "penyedia awan" di atas, sesetengah daripadanya adalah teknologi maya dan tidak sesuai dengan apa yang kami umum lihat sebagai pembekal awan. Nak kata sikit.

Pada bulan Julai 2015, semua kod khusus penyedia awan telah diimport dan digunakan oleh kubelet , salah satu komponen nod kritikal yang membentuk nod kelompok k8s.

Terdapat beberapa masalah dengan pelaksanaan asal kod khusus penyedia awan yang dikenali oleh komuniti k8 dan sehingga kini sedang diusahakan.

Berikut ialah beberapa masalah yang timbul selama ini:

• Kubelet tidak boleh menjalankan gelung kawalan khusus penyedia awan. Ini kini telah dipindahkan ke CCM.

• Pembekal awan tidak boleh menjadi sebahagian daripada k/k (dalam-pokok), sebabnya ialah kod pembekal awan akan terikat kepada kitaran keluaran k8s dan komit kod kepada k/k boleh tugas yang membosankan.

• Sokong penyedia awan luaran (luar pokok) dengan menyediakan pakej berasingan dengan cara boleh pasang untuk menyepadukan awan anda dengan k8s. Ini menjadi pakej k8s.io/cloud-provider.

• Semua kod pengawal awan yang digunakan oleh CCM akan dialihkan ke pakej k8s.io/cloud-provider, masih terdapat baki kod dalam pokok yang akan dialihkan.

Atas sebab keserasian ke belakang, kod yang berada dalam pokok akan wujud untuk sementara waktu, tetapi kini ia adalah pakej sendiri (k8s.io/legacy-cloud-providers).

Saya telah cuba mengikuti bagaimana CCM dan k8s.io/cloud-provider muncul dengan mencari-cari dalam pelbagai repositori dalam organisasi k8s, hampir seperti arkeologi digital. Berikut ialah beberapa sorotan:

• Pada bulan September 2016 isu peningkatan #88 (KEP) dicipta untuk menyokong penyedia awan luar pokok (boleh pasang).

• Mula memecahkan pengurus pengawal (kube) kepada dua bahagian, Okt 2016. Sila ambil perhatian bahawa PR ini menyebut volumeController , ini adalah masa sebelum CSI. Pengawal itu telah dialih keluar daripada SSM sejak itu.

• Perbincangan Pengurus Pengawal Awan Julai 2017. Berjaya ke versi beta dalam v1.11 .

• Berikut ialah penjelasan yang baik tentang betapa rapatnya kubelet dan penyedia awan suatu ketika dahulu. Terdapat tiga pendekatan tentang cara memisahkan kubelet dan penyedia awan.

Pakej pembekal awan

Pakej penyedia awan diimport sebagai k8s.io/cloud-provider dalam CCM anda dan mentakrifkan beberapa antara muka (Golang). Yang utama ialah antara muka Antara Muka yang menjadikan pakej ini boleh dipasang untuk pembekal awan.

Antara Muka mentakrifkan satu set kaedah, sebahagian daripada ini mengembalikan antara muka lain. Antara muka yang dikembalikan ini juga ditakrifkan dalam fail cloud.go bagi pakej pembekal awan.

$> kubectl get service my-app-svc
NAME       TYPE         CLUSTER-IP    EXTERNAL-IP     PORT(S)
my-app-svc LoadBalancer 172.20.10.100 123.123.123.123 80:31147/TCP

Seperti yang anda lihat di atas, tandatangan kaedah menentukan nilai pulangan bool bersama antara muka yang dikembalikan, ini bermakna anda boleh mendayakan/melumpuhkan fungsi jika ia tidak boleh atau tidak patut dilaksanakan oleh CCM. Ini ialah sesuatu yang akan disemak semasa pemulaan pengawal yang melaksanakan fungsi yang ditakrifkan oleh antara muka.

Berikut ialah gambaran keseluruhan ringkas kaedah antara muka k8s.io/cloud-provider yang digunakan oleh pengawal mana:

• Kaedah antara muka Kejadian akan dipanggil daripada pengawal Nod dan Kitaran Hayat.

• Kaedah antara muka Zon akan dipanggil daripada pengawal Nodedan theLifecycle.

• Kaedah antara muka Laluan akan dipanggil daripada pengawalRoute.

• Kaedah antara muka LoadBalancer akan dipanggil daripada pengawal Perkhidmatan.

• Antara muka Kluster hanya digunakan oleh pembekal awan luaran GCP.

Perhatikan bahawa terdapat beberapa tempat dalam repositori k/k yang terdapat panggilan keluar kepada pelbagai kaedah dalam antara muka di atas, mis. kedua-duanya dalam kubelet dan pelayan API.

Selain antara muka di atas pakej k8s.io/cloud-provider juga termasuk semua yang diperlukan untuk mendaftar dan memulakan pembekal awan anda dengan CCM.

Mari kita lihat antara muka LoadBalancer, anda akan melihat sekumpulan kaedah yang akan anda laksanakan:

LoadBalancer() (LoadBalancer, bool)
Instances() (Instances, bool)
Zones() (Zones, bool)
Clusters() (Clusters, bool)
Routes() (Routes, bool)

Kaedah ini akan dipanggil oleh pengawal Perkhidmatan yang dijalankan dalam SKM, saya menunjukkan kaedah ini sebagai contoh kerana anda akan melihat kaedah ini dipanggil dalam kod sumber pengawal Perkhidmatan.

Apa yang sebenarnya diedarkan di seluruh SKM ialah objek anda yang diintai yang akan bertindak sebagai penyedia awan (memuaskan semua antara muka penyedia awan).

Beginilah cara pengawal awan yang dikekalkan oleh CCM dapat mencipta, mengemas kini dan memadam sumber dalam awan anda.

Pakej k8s.io/cloud-provider tidak akan menentukan sebarang cara untuk menyambung dan mis. sahkan ke awan anda. Logik semacam itu adalah sesuatu yang anda perlu bina ke dalam CCM.

Apabila anda telah berpuas hati dengan semua antara muka yang ditakrifkan dalam pakej k8s.io/cloud-provider, menghubungkan semuanya bersama-sama, anda telah berjaya menjadi penyedia awan. Satu-satunya perkara yang tinggal ialah membina dan membungkus binari CCM anda ke dalam bekas dan menggunakan ia ke k8!

Melihat ke hadapan sebenarnya terdapat banyak perkara yang berlaku apabila melihat bahagian penyedia awan repositori k/k, sehingga berita ini ditulis, terdapat inisiatif berterusan untuk menstruktur semula dan menjadikan k8s.io/cloud-provider lebih kurang berdikari. Maksudnya cth. pengawal awan akan menjadi sebahagian daripada pakej k8s.io/cloud-provider, ini bermakna pada akhirnya anda sebagai penyedia awan akan mengimport satu pakej untuk dapat membina dan melaksanakan CCM dan pembekal awan luaran anda sendiri.

Dari perspektif Kubernetes

Untuk dapat menjalankan CCM anda yang baru dipasang dan dibungkus Docker, terdapat beberapa perkara yang perlu dikonfigurasikan semasa menaikkan satah kawalan k8s:

• kubelet hendaklah dimulakan dengan bendera --cloud-provider=external, ini memberi isyarat kepada kubelet bahawa terdapat pengawal lain yang memulakan nod.

Seperti yang dinyatakan pada permulaan siaran ini, terdapat repositori ini tempat saya menunjukkan dan menerangkan bahagian teknikal perkara yang menjalankan CCM pembekal awan luaran anda sendiri.

Jika anda, katakan, berada di AWS sekarang memutarkan kluster k8 anda sendiri pada kejadian EC2 dan mahukan penyepaduan yang lebih asli kepada AWS, anda akan menggunakan penyedia awan AWS CCM. Anda juga boleh, walaupun tidak disyorkan, hanya nyatakan --cloud-provider=aws pada kubelet. Beginilah cara anda memberi isyarat kepada k8 bahawa anda ingin menggunakan pembekal awan dalam pokok, hanya terdapat segelintir daripadanya yang dilaksanakan. Mana-mana awan peribadi/awam yang "lebih baharu" di luar sana akan mempunyai penyedia awan luaran CCM.

Kod untuk penyedia awan dalam pokok diimport melalui k8s.io/legacy-cloud-providers , sila ambil perhatian bahawa apabila anda menggunakan kod rangka CCM dari k/k anda akan mengimport pakej ini dari awal .

Sumber

Untuk mengikuti apa yang berlaku berhubung dengan semua yang berkaitan dengan penyedia awan dalam konteks k8, sila lihat sumber ini:

• Pembekal Awan SIG

• Pembekal sig-cloud-saluran dalam ruang Slack k8s

• Semua isu peningkatan k8 yang dilabelkan dengan sig/pembekal awan

Berikut ialah senarai penyedia awan luaran, bagus untuk digunakan sebagai rujukan atau jika anda hanya ingin tahu bagaimana orang lain telah melakukannya:

• OpenStack

• DigitalOcean

• AWS

• GCP

• Awan Alibaba

• Awan Huawei

• Awan Baidu

• vSphere

• Azure

Atas ialah kandungan terperinci Pengurus Pengawal Awan Kubernetes. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!