🥇Memperkenalkan Kubernetes CCM (Pengurus Pengawal Awan) untuk Yandex.Cloud

Dalam kesinambungan kepada yang baru-baru ini Keluaran pemacu CSI untuk Yandex.Cloud kami menerbitkan satu lagi projek Sumber Terbuka untuk awan ini - Pengurus Pengawal Awan. CCM diperlukan bukan sahaja untuk kluster secara keseluruhan, tetapi juga untuk pemacu CSI itu sendiri. Butiran tentang tujuannya dan beberapa ciri pelaksanaan sedang dikurangkan.

Pengenalan

kenapa ni?

Motif yang mendorong kami untuk membangunkan CCM untuk Yandex.Cloud sepenuhnya bertepatan dengan yang telah diterangkan dalam pengumuman pemandu CSI. Kami mengekalkan banyak kluster Kubernetes daripada pembekal awan yang berbeza, yang mana kami menggunakan satu alat. Ia melaksanakan pelbagai kemudahan "memintas" penyelesaian terurus penyedia ini. Ya, kami mempunyai kes dan keperluan yang agak khusus, tetapi perkembangan yang dibuat kerana itu mungkin berguna kepada pengguna lain.

Apakah sebenarnya CCM?

Biasanya, kami menyediakan persekitaran di sekeliling kami untuk kluster dari luar - contohnya, menggunakan Terraform. Tetapi kadangkala terdapat keperluan untuk menguruskan persekitaran awan di sekeliling kita daripada kelompok. Kemungkinan ini disediakan, dan ia adalah yang dilaksanakan CCM.

Khususnya, Pengurus Pengawal Awan menyediakan lima jenis interaksi utama:

Contohnya – melaksanakan hubungan 1:1 antara objek nod dalam Kubernetes (Node) dan mesin maya dalam pembekal awan. Untuk ini kami:
- mengisi medan spec.providerID dalam objek Node. Sebagai contoh, untuk OpenStack CCM medan ini mempunyai format berikut: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Anda boleh melihat nama pembekal awan dan UUID unik pelayan (mesin maya dalam OpenStack) objek;
- pelengkap nodeInfo dalam objek Node maklumat tentang mesin maya. Sebagai contoh, kami menentukan jenis contoh dalam AWS;
- Kami menyemak kehadiran mesin maya dalam awan. Sebagai contoh, jika objek Node pergi ke sebuah negeri NotReady, anda boleh menyemak sama ada mesin maya wujud sama sekali dalam pembekal awan dengan providerID. Jika ia tiada, padamkan objek tersebut Node, yang sebaliknya akan kekal dalam kelompok selama-lamanya;
zon – menetapkan domain kegagalan untuk objek Node, supaya penjadual boleh memilih nod untuk Pod mengikut kawasan dan zon dalam pembekal awan;
LoadBalancer – semasa mencipta objek Service dengan jenis LoadBalancer mencipta sejenis pengimbang yang akan mengarahkan trafik dari luar ke nod kelompok. Sebagai contoh, dalam Yandex.Cloud anda boleh gunakan NetworkLoadBalancer и TargetGroup untuk tujuan ini;
Jalan – membina rangkaian antara nod, kerana Mengikut keperluan Kubernetes, setiap pod mesti mempunyai alamat IP sendiri dan boleh mencapai mana-mana pod lain. Untuk tujuan ini, anda boleh menggunakan rangkaian tindanan (VXLAN, GENEVE) atau menetapkan jadual penghalaan terus dalam rangkaian maya pembekal awan:
jumlah – Membenarkan pesanan dinamik PV menggunakan PVC dan SC. Pada mulanya, fungsi ini adalah sebahagian daripada CCM, tetapi disebabkan kerumitannya yang hebat, ia telah dipindahkan ke projek berasingan, Antara Muka Penyimpanan Kontena (CSI). Kami telah bercakap tentang CSI lebih daripada sekali писали dan, seperti yang telah disebutkan, malah dilepaskan pemandu CSI.

Sebelum ini, semua kod yang berinteraksi dengan awan terletak dalam repositori Git utama projek Kubernetes di k8s.io/kubernetes/pkg/cloudprovider/providers, tetapi mereka memutuskan untuk meninggalkan ini kerana kesulitan bekerja dengan pangkalan kod yang besar. Semua pelaksanaan lama telah dipindahkan ke repositori berasingan. Untuk kemudahan sokongan dan pembangunan selanjutnya, semua komponen biasa juga telah dipindahkan ke repositori berasingan.

Seperti CSI, banyak penyedia awan besar telah mereka bentuk CCM mereka untuk memanfaatkan awan pada Kubernetes. Jika pembekal tidak mempunyai CCM, tetapi semua fungsi yang diperlukan tersedia melalui API, maka anda boleh melaksanakan CCM sendiri.

Untuk menulis pelaksanaan CCM anda sendiri, ia sudah cukup untuk dilaksanakan antara muka Go yang diperlukan.

И ini yang kami dapat.

Реализация

Bagaimana anda sampai kepada ini

Kami memulakan pembangunan (atau lebih tepatnya, bahkan menggunakan) dengan sedia(!) CCM untuk Yandex.Cloud setahun yang lalu.

Walau bagaimanapun, dalam pelaksanaan ini kami telah kehilangan:

pengesahan melalui token JWT IAM;
Sokongan pengawal perkhidmatan.

Bersetuju dengan penulis (dlisin) dalam Telegram, kami memotong yandex-cloud-controller-manager dan menambah fungsi yang hilang.

Ciri-ciri utama

Pada masa ini, CCM menyokong antara muka berikut:

Contohnya;
zon;
LoadBalancer.

Pada masa hadapan, apabila Yandex.Cloud mula berfungsi dengan keupayaan VPC lanjutan, kami akan menambah antara muka laluan.

LoadBalanacer sebagai cabaran utama

Pada mulanya, kami cuba, seperti pelaksanaan CCM lain, untuk mencipta sepasang LoadBalancer и TargetGroup untuk setiap Service dengan jenis LoadBalancer. Walau bagaimanapun, Yandex.Cloud menemui satu had yang menarik: anda tidak boleh menggunakan TargetGroups dengan bersilang Targets (pasangan SubnetID - IpAddress).

Oleh itu, di dalam CCM yang dicipta, pengawal dilancarkan, yang, apabila objek berubah Node mengumpul maklumat tentang semua antara muka pada setiap mesin maya, mengumpulkannya mengikut kepunyaan mereka kepada tertentu NetworkID, dicipta oleh TargetGroup pada NetworkID, dan juga memantau perkaitan. Selepas itu, apabila mencipta objek Service dengan jenis LoadBalanacer kami hanya melampirkan pra-dicipta TargetGroup ke baru NetworkLoadBalanacer'am.

Bagaimana untuk mula menggunakan?

CCM menyokong Kubernetes versi 1.15 dan lebih tinggi. Dalam kelompok, untuk ia berfungsi, ia memerlukan bendera --cloud-provider=external telah ditetapkan kepada true untuk kube-apiserver, kube-controller-manager, kube-scheduler dan semua kubelet.

Semua langkah yang diperlukan untuk pemasangan itu sendiri diterangkan dalam README. Pemasangan bermula dengan mencipta objek dalam Kubernetes daripada manifes.

Untuk menggunakan CCM anda juga perlu:

menunjukkan dalam manifes pengecam direktori (folder-id) Yandex.Cloud;
akaun perkhidmatan untuk berinteraksi dengan API Yandex.Cloud. Dalam manifesto Secret perlu pindahkan kunci yang dibenarkan daripada akaun perkhidmatan. Dalam dokumentasi diterangkan, cara membuat akaun perkhidmatan dan mendapatkan kunci.

Kami akan gembira menerima maklum balas anda dan isu barujika anda menghadapi sebarang masalah!

Keputusan

Kami telah menggunakan CCM yang dilaksanakan dalam lima kluster Kubernetes sejak dua minggu lalu dan merancang untuk mengembangkan bilangan mereka kepada 20 pada bulan akan datang. Pada masa ini kami tidak mengesyorkan menggunakan CCM untuk pemasangan K8 yang besar dan kritikal.

Seperti dalam kes CSI, kami akan gembira jika pemaju Yandex mengambil pembangunan dan sokongan projek ini - kami bersedia untuk memindahkan repositori atas permintaan mereka untuk menangani tugas yang lebih berkaitan dengan kami.

Memperkenalkan Kubernetes CCM (Pengurus Pengawal Awan) untuk Yandex.Cloud