🥇Memperluas dan menambah Kubernetes (laporan ulasan dan video)

8 April di persidangan itu Saint HighLoad++ 2019, sebagai sebahagian daripada bahagian "DevOps and Operations", laporan "Memperluas dan melengkapkan Kubernetes" telah diberikan, dalam penciptaan yang mana tiga pekerja syarikat Flant mengambil bahagian. Di dalamnya, kami bercakap tentang banyak situasi di mana kami ingin mengembangkan dan melengkapkan keupayaan Kubernetes, tetapi kami tidak menemui penyelesaian siap sedia dan mudah. Kami mempunyai penyelesaian yang diperlukan dalam bentuk projek Sumber Terbuka, dan ucapan ini juga didedikasikan untuk mereka.

Mengikut tradisi, kami berbesar hati untuk mempersembahkan video laporan tersebut (50 minit, lebih bermaklumat daripada artikel) dan ringkasan utama dalam bentuk teks. Pergi!

Teras dan tambahan dalam K8s

Kubernetes sedang mengubah industri dan pendekatan pentadbiran yang telah lama ditubuhkan:

Terima kasih kepadanya abstraksi, kami tidak lagi beroperasi dengan konsep seperti menyediakan konfigurasi atau menjalankan perintah (Chef, Ansible...), tetapi menggunakan pengumpulan bekas, perkhidmatan, dsb.
Kami boleh menyediakan aplikasi tanpa memikirkan nuansa tapak tertentu, di mana ia akan dilancarkan: logam kosong, awan salah satu penyedia, dsb.
Dengan K8 anda tidak pernah lebih mudah diakses amalan terbaik mengenai penganjuran infrastruktur: teknik penskalaan, penyembuhan diri, toleransi kesalahan, dsb.

Walau bagaimanapun, sudah tentu, semuanya tidak begitu lancar: Kubernetes juga membawa cabaran baharunya sendiri.

Kubernetes tiada adalah gabungan yang menyelesaikan semua masalah semua pengguna. Inti Kubernetes hanya bertanggungjawab untuk satu set fungsi minimum yang diperlukan yang terdapat dalam setiap kelompok:

Teras Kubernetes mentakrifkan set asas primitif untuk mengumpulkan bekas, mengurus trafik dan sebagainya. Kami bercakap tentang mereka dengan lebih terperinci dalam laporan 2 tahun lalu.

Sebaliknya, K8 menawarkan peluang hebat untuk mengembangkan fungsi yang tersedia, yang membantu menutup yang lain - khusus — keperluan pengguna. Penambahan kepada Kubernetes adalah tanggungjawab pentadbir kluster, yang mesti memasang dan mengkonfigurasi semua yang diperlukan untuk mendapatkan kluster mereka "dalam bentuk yang betul" [untuk menyelesaikan masalah khusus mereka]. Apakah jenis tambahan ini? Mari lihat beberapa contoh.

Contoh alat tambah

Setelah memasang Kubernetes, kami mungkin terkejut bahawa rangkaian yang sangat diperlukan untuk interaksi pod dalam nod dan antara nod tidak berfungsi dengan sendirinya. Kernel Kubernetes tidak menjamin sambungan yang diperlukan; sebaliknya, ia menentukan rangkaian antara muka (CNI) untuk alat tambah pihak ketiga. Kita mesti memasang salah satu alat tambah ini, yang akan bertanggungjawab untuk konfigurasi rangkaian.

Contoh rapat ialah penyelesaian penyimpanan data (cakera tempatan, peranti blok rangkaian, Ceph...). Pada mulanya mereka berada di teras, tetapi dengan kedatangan CSI situasi berubah kepada sesuatu yang serupa dengan yang telah diterangkan: antara muka berada dalam Kubernetes, dan pelaksanaannya adalah dalam modul pihak ketiga.

Contoh lain termasuk:

Ingress-pengawal (lihat ulasan mereka dalam artikel terbaru kami).
pengurus sijil:
Operator ialah keseluruhan kelas alat tambah (yang termasuk pengurus sijil yang disebutkan), mereka mentakrifkan primitif dan pengawal. Logik kerja mereka dihadkan hanya oleh imaginasi kita dan membolehkan kita menukar komponen infrastruktur siap pakai (contohnya, DBMS) menjadi primitif, yang lebih mudah untuk digunakan (berbanding dengan set bekas dan tetapannya). Sebilangan besar pengendali telah ditulis - walaupun banyak daripada mereka belum bersedia untuk pengeluaran, ia hanya menunggu masa:
Metrik - ilustrasi lain tentang cara Kubernetes memisahkan antara muka (API Metrik) daripada pelaksanaan (alat tambah pihak ketiga seperti penyesuai Prometheus, ejen kluster Datadog...).
Untuk pemantauan dan statistik, di mana dalam amalan bukan sahaja diperlukan Prometheus dan Grafana, tetapi juga kube-state-metrics, nod-exporter, dsb.

Dan ini bukan senarai lengkap tambahan... Contohnya, di syarikat Flant yang kami pasang sekarang 29 tambahan (semuanya mencipta sejumlah 249 objek Kubernetes). Ringkasnya, kita tidak dapat melihat kehidupan kluster tanpa penambahan.

Automasi

Operator direka bentuk untuk mengautomasikan operasi rutin yang kami hadapi setiap hari. Berikut ialah contoh kehidupan sebenar yang menulis operator akan menjadi penyelesaian yang sangat baik:

Terdapat pendaftaran peribadi (iaitu memerlukan log masuk) dengan imej untuk aplikasi. Diandaikan bahawa setiap pod diberikan rahsia khas yang membenarkan pengesahan dalam pendaftaran. Tugas kami adalah untuk memastikan rahsia ini ditemui dalam ruang nama supaya pod boleh memuat turun imej. Terdapat banyak aplikasi (masing-masing memerlukan rahsia), dan ia berguna untuk mengemas kini rahsia itu sendiri dengan kerap, jadi pilihan untuk meletakkan rahsia dengan tangan dihapuskan. Di sinilah pengendali datang untuk menyelamatkan: kami mencipta pengawal yang akan menunggu ruang nama muncul dan, berdasarkan acara ini, akan menambah rahsia pada ruang nama.
Benarkan akses lalai dari pod ke Internet adalah dilarang. Tetapi kadangkala ia mungkin diperlukan: adalah logik untuk mekanisme kebenaran akses berfungsi dengan mudah, tanpa memerlukan kemahiran khusus, contohnya, dengan kehadiran label tertentu dalam ruang nama. Bagaimanakah pengendali boleh membantu kami di sini? Pengawal dicipta yang menunggu untuk label muncul dalam ruang nama dan menambah dasar yang sesuai untuk akses Internet.
Situasi yang sama: katakan kita perlu menambah tertentu mencemarkan, jika ia mempunyai label yang serupa (dengan beberapa jenis awalan). Tindakan dengan pengendali adalah jelas...

Dalam mana-mana kelompok, tugas rutin mesti diselesaikan, dan betul ini boleh dilakukan menggunakan operator.

Merumuskan semua cerita yang diterangkan, kami sampai pada kesimpulan bahawa untuk kerja yang selesa di Kubernetes anda perlukan: A) pasang alat tambah, b) membangunkan pengendali (untuk menyelesaikan tugas pentadbir setiap hari).

Bagaimana untuk menulis kenyataan untuk Kubernetes?

Secara umum, skema ini mudah:

... tetapi ternyata:

API Kubernetes adalah perkara yang agak tidak remeh yang memerlukan banyak masa untuk dikuasai;
pengaturcaraan juga bukan untuk semua orang (bahasa Go dipilih sebagai bahasa pilihan kerana terdapat rangka kerja khas untuknya - SDK Operator);
Keadaannya serupa dengan rangka kerja itu sendiri.

Dasarnya: untuk menulis pengawal (pengendali) terpaksa membelanjakan sumber yang besar untuk mempelajari bahan. Ini wajar untuk pengendali "besar" - katakan, untuk DBMS MySQL. Tetapi jika kita mengingati contoh yang diterangkan di atas (membuka rahsia, mengakses pod ke Internet...), yang juga ingin kita lakukan dengan betul, maka kita akan faham bahawa usaha yang dibelanjakan akan melebihi hasil yang kita perlukan sekarang:

Secara umum, dilema timbul: menghabiskan banyak sumber dan cari alat yang sesuai untuk menulis kenyataan, atau lakukan dengan cara lama (tetapi dengan cepat). Untuk menyelesaikannya - untuk mencari kompromi antara keterlaluan ini - kami mencipta projek kami sendiri: pengendali shell (lihat juga dia pengumuman baru-baru ini di hab).

Shell-operator

Bagaimana dia bekerja? Kelompok ini mempunyai pod yang mengandungi binari Go dengan pengendali shell. Di sebelahnya adalah satu set cangkuk (butiran lanjut tentang mereka - lihat di bawah). Shell-operator itu sendiri melanggan tertentu perkembangan dalam API Kubernetes, apabila ia melancarkan cangkuk yang sepadan.

Bagaimanakah pengendali shell tahu cangkuk mana yang hendak dipanggil pada acara mana? Maklumat ini dihantar kepada pengendali shell oleh cangkuk itu sendiri, dan mereka melakukannya dengan sangat mudah.

Cangkuk ialah skrip Bash atau mana-mana fail boleh laku lain yang menerima satu hujah --config dan bertindak balas dengan JSON. Yang terakhir menentukan objek mana yang menarik minatnya dan peristiwa (untuk objek ini) harus dijawab:

Saya akan menggambarkan pelaksanaan pada shell-operator salah satu contoh kami - menguraikan rahsia untuk mengakses pendaftaran peribadi dengan imej aplikasi. Ia terdiri daripada dua peringkat.

Latihan: 1. Tulis cangkuk

Pertama sekali, dalam cangkuk kami akan memproses --config, menunjukkan bahawa kami berminat dengan ruang nama, dan khususnya, detik penciptaannya:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Apakah rupa logiknya? Juga agak mudah:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Langkah pertama ialah untuk mengetahui ruang nama yang dicipta, dan yang kedua ialah menciptanya menggunakan kubectl rahsia untuk ruang nama ini.

Latihan: 2. Memasang imej

Apa yang tinggal ialah menghantar cangkuk yang dibuat kepada pengendali shell - bagaimana untuk melakukan ini? Pengendali shell itu sendiri datang sebagai imej Docker, jadi tugas kami adalah untuk menambah cangkuk ke direktori khas dalam imej ini:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

Yang tinggal hanyalah memasangnya dan menolaknya:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

Sentuhan terakhir adalah untuk menggunakan imej ke kluster. Untuk melakukan ini, mari kita menulis Deployment:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

Terdapat dua perkara yang perlu diberi perhatian:

petunjuk imej yang baru dibuat;
Ini ialah komponen sistem yang (sekurang-kurangnya) memerlukan hak untuk melanggan acara dalam Kubernetes dan memperuntukkan rahsia kepada ruang nama, jadi kami mencipta Akaun Perkhidmatan (dan satu set peraturan) untuk cangkuk.

Keputusan - kami menyelesaikan masalah kami saudara mara untuk Kubernetes dengan cara yang mencipta operator untuk menguraikan rahsia.

Ciri pengendali shell lain

Untuk mengehadkan objek jenis pilihan anda yang akan berfungsi dengan cangkuk, mereka boleh ditapis, memilih mengikut label tertentu (atau menggunakan matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Dengan syarat mekanisme deduplikasi, yang - menggunakan penapis jq - membolehkan anda menukar objek JSON yang besar kepada yang kecil, di mana hanya parameter tersebut kekal yang kami mahu pantau untuk perubahan.

Apabila cangkuk dipanggil, pengendali cangkerang melepasinya data objek, yang boleh digunakan untuk sebarang keperluan.

Peristiwa yang mencetuskan cangkuk tidak terhad kepada acara Kubernetes: pengendali shell menyediakan sokongan untuk memanggil cangkuk mengikut masa (serupa dengan crontab dalam penjadual tradisional), serta acara istimewa onStartup. Semua acara ini boleh digabungkan dan diberikan kepada cangkuk yang sama.

Dan dua lagi ciri pengendali shell:

Ianya berfungsi tak segerak. Memandangkan peristiwa Kubernetes (seperti objek yang dicipta) telah diterima, peristiwa lain (seperti objek yang sama dipadamkan) mungkin berlaku dalam kelompok dan cangkuk perlu mengambil kira perkara ini. Jika cangkuk telah dilaksanakan dengan ralat, maka secara lalai ia akan berlaku panggilan semula sehingga berjaya disiapkan (tingkah laku ini boleh diubah).
Ia mengeksport metrik untuk Prometheus, yang mana anda boleh memahami sama ada pengendali shell berfungsi, ketahui bilangan ralat untuk setiap cangkuk dan saiz baris gilir semasa.

Untuk meringkaskan bahagian laporan ini:

Pasang Tambahan

Untuk kerja yang selesa dengan Kubernetes, keperluan untuk memasang alat tambah juga disebut. Saya akan memberitahu anda tentangnya menggunakan contoh laluan syarikat kami untuk cara kami melakukannya sekarang.

Kami mula bekerja dengan Kubernetes dengan beberapa kluster, satu-satunya tambahan ialah Ingress. Ia perlu dipasang secara berbeza dalam setiap kelompok, dan kami membuat beberapa konfigurasi YAML untuk persekitaran yang berbeza: logam kosong, AWS...

Oleh kerana terdapat lebih banyak kluster, terdapat lebih banyak konfigurasi. Di samping itu, kami memperbaik konfigurasi ini sendiri, akibatnya ia menjadi agak heterogen:

Untuk menyusun segala-galanya, kami mulakan dengan skrip (install-ingress.sh), yang mengambil sebagai hujah jenis kluster yang akan kami gunakan, menghasilkan konfigurasi YAML yang diperlukan dan melancarkannya ke Kubernetes.

Ringkasnya, laluan kami selanjutnya dan alasan yang berkaitan dengannya adalah seperti berikut:

untuk bekerja dengan konfigurasi YAML, enjin templat diperlukan (pada peringkat pertama ini adalah sed mudah);
dengan peningkatan bilangan kluster, keperluan untuk pengemaskinian automatik datang (penyelesaian terawal ialah meletakkan skrip dalam Git, mengemas kini menggunakan cron dan menjalankannya);
skrip yang serupa diperlukan untuk Prometheus (install-prometheus.sh), walau bagaimanapun, adalah ketara kerana ia memerlukan lebih banyak data input, serta storan mereka (dengan cara yang baik - berpusat dan dalam kelompok), dan beberapa data (kata laluan) boleh dijana secara automatik:
risiko melancarkan sesuatu yang salah kepada bilangan kluster yang semakin meningkat sentiasa meningkat, jadi kami menyedari bahawa pemasang (iaitu dua skrip: untuk Ingress dan Prometheus) pementasan diperlukan (beberapa cawangan dalam Git, beberapa cron untuk mengemas kininya dalam kumpulan yang sepadan: stabil atau ujian);
с kubectl apply ia telah menjadi sukar untuk digunakan kerana ia tidak deklaratif dan hanya boleh mencipta objek, tetapi tidak membuat keputusan tentang statusnya/memadamnya;
Kami kehilangan beberapa fungsi yang kami tidak melaksanakan sama sekali pada masa itu:
- kawalan penuh ke atas hasil kemas kini kelompok,
- penentuan automatik beberapa parameter (input untuk skrip pemasangan) berdasarkan data yang boleh diperolehi daripada kluster (penemuan),
- perkembangan logiknya dalam bentuk penemuan berterusan.

Kami melaksanakan semua pengalaman terkumpul ini dalam rangka kerja projek kami yang lain - pengendali tambahan.

Addon-operator

Ia adalah berdasarkan kepada shell-operator yang telah disebutkan. Keseluruhan sistem kelihatan seperti ini:

Perkara berikut ditambah pada cangkuk pengendali shell:

simpanan nilai,
Carta helm,
komponen itu memantau kedai nilai dan - sekiranya berlaku sebarang perubahan - meminta Helm untuk melancarkan semula carta.

Oleh itu, kita boleh bertindak balas terhadap peristiwa dalam Kubernetes, melancarkan cangkuk, dan daripada cangkuk ini kita boleh membuat perubahan pada storan, selepas itu carta akan dimuat turun semula. Dalam rajah yang terhasil, kami memisahkan set cangkuk dan carta menjadi satu komponen, yang kami panggil modul:

Terdapat banyak modul, dan kepada mereka kami menambah cangkuk global, kedai nilai global, dan komponen yang memantau kedai global ini.

Kini, apabila sesuatu berlaku dalam Kubernetes, kita boleh bertindak balas terhadapnya menggunakan cangkuk global dan menukar sesuatu dalam kedai global. Perubahan ini akan diperhatikan dan akan menyebabkan semua modul dalam kluster dilancarkan:

Skim ini memenuhi semua keperluan untuk memasang alat tambah yang dinyatakan di atas:

Helm bertanggungjawab untuk templat dan perisytiharan.
Isu kemas kini automatik telah diselesaikan menggunakan cangkuk global, yang pergi ke pendaftaran mengikut jadual dan, jika ia melihat imej sistem baharu di sana, melancarkannya (iaitu "sendiri").
Menyimpan tetapan dalam kelompok dilaksanakan menggunakan Peta Konfigurasi, yang mengandungi data utama untuk storan (pada permulaan ia dimuatkan ke dalam storan).
Masalah dengan penjanaan kata laluan, penemuan dan penemuan berterusan telah diselesaikan menggunakan cangkuk.
Pementasan dicapai berkat teg, yang disokong oleh Docker di luar kotak.
Hasilnya dipantau menggunakan metrik yang membolehkan kami memahami status.

Keseluruhan sistem ini dilaksanakan dalam bentuk binari tunggal dalam Go, yang dipanggil addon-operator. Ini menjadikan rajah kelihatan lebih mudah:

Komponen utama dalam rajah ini ialah satu set modul (diserlahkan dalam warna kelabu di bawah). Kini kita boleh menulis modul untuk alat tambah yang diperlukan dengan sedikit usaha dan pastikan ia akan dipasang dalam setiap kelompok, akan dikemas kini dan bertindak balas kepada peristiwa yang diperlukan dalam kelompok.

Kegunaan "Flant". pengendali tambahan pada 70+ kluster Kubernetes. Status semasa - versi alfa. Sekarang kami sedang menyediakan dokumentasi untuk mengeluarkan beta, tetapi buat masa ini dalam repositori contoh yang ada, atas dasar itu anda boleh membuat addon anda sendiri.

Di manakah saya boleh mendapatkan modul untuk pengendali tambahan? Menerbitkan perpustakaan kami adalah peringkat seterusnya untuk kami; kami merancang untuk melakukan ini pada musim panas.

Video dan slaid

Video daripada persembahan (~50 minit):

Pembentangan laporan:

PS

Laporan lain di blog kami:

«Pangkalan Data dan Kubernetes»; (Dmitry Stolyarov; 8 November 2018 di HighLoad++);
«Pemantauan dan Kubernetes»; (Dmitry Stolyarov; 28 Mei 2018 di RootConf);
«Amalan Terbaik CI/CD dengan Kubernetes dan GitLab»; (Dmitry Stolyarov; 7 November 2017 di HighLoad++);
«Pengalaman kami dengan Kubernetes dalam projek kecil»; (Dmitry Stolyarov; 6 Jun 2017 di RootConf).

Anda juga mungkin berminat dengan penerbitan berikut:

«Memperkenalkan shell-operator: membuat operator untuk Kubernetes semakin mudah'.

Sumber: www.habr.com

Memperluas dan melengkapkan Kubernetes (laporan ulasan dan video)