Kapitan di pucuk pimpinan Kubernetes

Temui Kapitan . Ini membantu Anda menghadirkan keindahan dan ketertiban untuk konfigurasi Kubernetes Anda.

Kapitan mendapatkan reputasi dari ulasan pengguna yang puas dan karenanya memberikan dokumentasi yang luas dan pemasaran yang mahal. Kami memiliki cukup banyak bintang dan beberapa sebutan dari blogger dan pengkhotbah Kubernet. Kapitan bahkan menjadi protagonis dari seluruh bab dalam buku ini . Yang paling penting, ia menarik perhatian beberapa perusahaan yang menjanjikan, karena Kapitan, seperti tidak ada orang lain, mampu mengurai konfigurasi yang terkait dengan simpul laut .

Di kubernetes.slack.com #kapitan berhasil mengumpulkan komunitas kecil namun berdedikasi (bergabung!), Jadi kami bangga dengan pekerjaan kami :)

Banyak yang masih percaya bahwa Kapitan adalah campuran jsonnet dan jinja, tetapi mereka melewatkan intinya.
Dalam posting ini saya akan memberi tahu Anda bagaimana Kapitan mengelola penyebaran Kubernet, tetapi secara umum mampu melakukan lebih dari itu. Ini penting: Kapitan bersifat universal dan tidak terpaku pada satu Kubernet. Kubernetes hanyalah salah satu dari banyak kegunaan.

Ini bukan panduan (meskipun saya menjanjikan panduan juga). Saya hanya ingin memberi tahu Anda mengapa kami melakukannya dan masalah apa dengan penerapan konfigurasi Kubernet yang harus dipecahkan.

Apa yang tidak saya sukai

Saya mulai bereksperimen dengan Kubernetes pada 2015 dan langsung jatuh cinta.
Benar, ada beberapa kelemahan yang tidak ingin saya lakukan:

• Konteks . Bagi saya, ini adalah salah satu konsep yang paling sulit untuk dipahami Kubernetes - dan salah satu yang paling berbahaya. Konteksnya merujuk pada klien, sulit untuk dimengerti, itu disebut dengan bingung dan menciptakan kebingungan ketika menjalankan perintah kubectl . Saya benci konteks di kubectl!
• Konfigurasi bersarang verbose (yaml!) . Saya harus berkeringat untuk mencari tahu setiap tingkat konfigurasi yaml dalam manifes. Apa gunanya mengulangi label dua hingga tiga kali di beberapa tempat?
• Berantakan dengan tim imperatif dan deklaratif . Para pendatang baru di Kubernet didorong untuk belajar oleh tim-tim penting, meskipun jelas bahwa orang normal tidak menggunakannya. Menurut pendapat saya, lebih sulit untuk menyesuaikan Kubernetes ke dalam strategi penyebaran yang tepat untuk perusahaan Anda. Spoiler: Tidak ada "strategi kanan" tunggal.
• Konfigurasi runtime . Jesse Suen benar ketika ia menyarankan agar tidak melewati parameter konfigurasi ke baris perintah helm (atau kubectl dan yang lainnya seperti itu). Dengan parameter, perintah yang sama dapat dieksekusi secara berbeda setiap kali.
• Konfigurasi Aplikasi Kami belajar bagaimana mengelola manifest ubi di Kubernetes, kami hebat. Itu hanya di bawah dan Menyebarkan - ini adalah mangkuk kosong. Masih harus mengapung aplikasi dengan semua konfigurasinya.
• Pengembang menginginkan liburan , dan alur kerja di Kubernetes masih sedikit cadel. Penggemar Kubernetes memaksa semua orang untuk melakukannya di sana. Apakah itu perlu? Patuhi Kelsey Hightower!
• Operator Saya memiliki perasaan campur aduk untuk mereka, jadi untuk sekarang tinggalkan topik ini :) Saya hanya bisa mengatakan bahwa mereka sering disalahgunakan.
• Idempotensi . Sebaliknya, ketidakhadirannya. Jika kita menjumlahkan semua kekurangan di atas, kita tidak mendapatkan alur kerja idempoten, yang menyedihkan bagi Kubernet.

Apa yang harus dilakukan

Saya mencoba untuk memecahkan masalah ini dan mengumpulkan sistem templating kecil yang menggunakan j2cli dan beberapa skrip bash untuk mengelola konfigurasi Kubernetes.

Sistem meletakkan semuanya ke dalam file environmentA.yaml dan menggunakannya dalam template Jinja2. Menyebarkan aplikasi gaya-microservice dari beberapa komponen dimungkinkan dengan perintah sederhana:

bin/apply.sh environments/environmentA.yaml 

Keren! Yaml adalah tentang penyebaran. Ini sangat nyaman, karena saya dapat menggunakan file yang sama sebagai sumber informasi untuk hal lain. Katakan untuk ... bash scripts !

Saya menemukan cara mengimpor nilai dari yaml ke skrip untuk menjalankan perintah serupa:

 bin/create_kafka_topics.sh environments/environmentA.yaml 

Dan semuanya menjadi tak terkendali sekaligus :

• Saya tidak bisa melakukan apa pun dengan struktur dalam file yaml. Itu kecelakaan di bidang yang sama, nilai, konfigurasi bingung.
• Anda tidak akan pernah tahu bagaimana berperilaku menyebarkan di lingkungan sampai Anda mencobanya. Seringkali ini disebabkan oleh perubahan pada template jinja2 karena nilai inventaris baru (katakanlah fitur_X), yang tidak berfungsi di lingkungan di mana fungsi ini tidak didefinisikan.
• Masalah yang sama dengan skrip: jika Anda tidak mencoba, Anda tidak tahu.
• Terkadang Kubernetes berubah begitu cepat sehingga mengganggu saya untuk terus mengubah manifes untuk versi yang berbeda, terutama mengacaukan anotasi nilai.
• Faktor eksternal : tim pengembangan beralih dari file konfigurasi ke parameter baris perintah. Perubahan kecil seperti itu membingungkan kami semua, dan kami harus memikirkan solusi baru.
• Yang terpenting : templating yaml dengan Jinja (atau Go templates) BUKAN MENYENANGKAN! Kami kemudian memiliki teka-teki: “ Apa yang tampak seperti teks, dibaca seperti teks, berbau seperti teks, tetapi bukan teks? ". Atau, seperti yang dikatakan Lee Briggs dengan tepat: " Mengapa kita membuat tempaan yaml? "

Kapitan: Menjadi

Kami mengumpulkan semua pengalaman pahit kami dan, bersama dengan Ricardo Amaro, mulai berfantasi tentang sistem manajemen konfigurasi yang ideal. Kemudian kami masih belum memiliki gambaran yang jelas, tetapi kami tahu bahwa kami mencintai dan bahwa kami tidak mencintai.

Cinta :

• Git.
• Pola secara umum: data / nilai terpisah dari pola.
• Pisahkan nilai untuk berbagai aspek (aplikasi, Kubernetes, runtime ...).
• Pendekatan berorientasi objek.
• Yaml yang disederhanakan sebagai antarmuka tempat menyembunyikan kompleksitas Kubernetes.
• Pemahaman yang jelas tentang apa yang terjadi dan mengapa.
• Penggunaan kembali nilai dalam komponen yang berbeda.
• Dan skrip harus memiliki akses ke nilai.

Kami tidak suka :

• Konteks Kubectl
• Mesin templat teks untuk membuat yaml.
• Penghitungan Indentasi: {{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} .
• Magic: semuanya harus jelas dan jelas. Tidak ada trik.
• Manajemen manual kata sandi dan rahasia aplikasi.
• Pendekatan Penggarap: Kami ingin mengontrol penggunaan manifes.
• Pendekatan Git-crypt: rahasia pada disk tidak dienkripsi.
• Templat pipeline langsung ke kubectl.
• Melewati opsi baris perintah.

Dan kemudian dua hal terjadi :

1. Kami menemukan jsonnet Dave Cunningham untuk mengatur yaml / json dalam bahasa berorientasi objek.
2. Gustavo Buriola menunjukkan kepada kami reklasifikasi , dan tanpa dia kami tidak akan pergi jauh.

Ricardo Amaro mulai bekerja, dan segera seluruh tim duduk di Kapitan - beberapa bekerja pada fungsi utama, yang lain pada penggunaannya dalam proyek internal kami. Manajemen rahasia, dukungan gpg \ kms, fungsi yang ditentukan pengguna: sekarang Kapitan adalah produk lengkap yang menghasilkan lebih dari yang dijanjikan.

Siapakah Kapitan?

Kapitan berusaha menyelesaikan semua (atau hampir semua) masalah yang saya bicarakan.

Dari sudut pandang teknis, Kapitan sangat sederhana:

• Inventaris : kumpulan nilai hierarkis yang menggambarkan penyebaran berdasarkan yaml. Berdasarkan reklasifikasi. Seperti hiera.
• Mesin templat : sekarang adalah Jinja2, Jsonnet, Kadet. Mereka mengambil inventaris dan membuat file (yaml, json, dokumentasi atau skrip bash).
• Rahasia : templat rahasia, dan Kapitan akan menghadapinya.

Kami menggunakan jsonnet untuk template manifesto dan Jinja untuk melakukan sisanya.

Kadang-kadang orang mengeluh bahwa file jsonnet sama sekali berbeda dari yaml yang sama, sehingga sulit bagi mereka untuk beralih ke jsonnet.

Kami mencoba menyelesaikan masalah ini dengan Kadet dengan membungkus yaml dengan Python. Ambil yaml favorit Anda sebagai basis dan tambahkan Python ke dalamnya.

Anggap ini exoskeleton Python untuk yaml! Entah bagaimana, saya akan membicarakan ini.

Dalam alur kerja, Kapitan segera menunjukkan karakter:

• Kebebasan memilih : kami tidak memaksakan proses kerja dan teknologi apa pun, tetapi biasanya bekerja berdasarkan prinsip-prinsip yang diuraikan di bawah ini. Bahkan, Kapitan bisa digunakan sesuka Anda. Anda tidak diharuskan menggunakan git, Anda tidak boleh mengkompilasi file di dalamnya, dan Anda bahkan dapat melakukannya tanpa jsonnet! Lakukan apa yang kamu inginkan.
• GitOps ke sumsum tulang: semua yang ada di git, semua yang ada di master- light yang mencerminkan niat kita.
• Deklarabilitas : Kapitan menyambut baik kompilasi templat nyata dalam representasi khusus. Dan Anda mengkompilasi skrip Anda.
• Konteks terkontrol : kami menggunakan skrip yang dikompilasi untuk menyederhanakan pekerjaan kami, misalnya, ketika menetapkan konteks dan mengkonfigurasi cluster.
  Konfigurasi kubernet: compiled/target_A/setup/setup.sh
  Terapkan Perubahan: compiled/target_A/setup/apply.sh
• Idempotensi : Kapitan memungkinkan Anda untuk mengubah template dan kode alat refactoring. Manifes dan kode yang dikompilasi tidak akan berubah tanpa perintah Anda, jadi Anda tidak perlu takut ketika melakukan refactoring.
• Sebab dan akibat : kami diperuntukkan bagi alur kerja tempat perubahan inventaris atau templat dan file yang dikompilasi dimasukkan dalam satu permintaan penggabungan. Jadi pengkaji akan dapat mengevaluasi perubahan Anda dan konsekuensinya yang sebenarnya. Adalah baik untuk mengetahui apakah perubahan dalam templat akan memengaruhi satu, dua atau lebih target.
• Dan akhirnya : Kapitan tidak terikat pada Kubernetes. Itu hanya membuat file. Penempatan perubahan melibatkan kubectl . Kami hanya memberikan shell untuk perintah yang akan dieksekusi secara konsisten.

Apakah saya membutuhkannya?

Mari kita perjelas : Anda mungkin tidak membutuhkan Kapitan (belum).

Tapi itu semua tergantung pada apa yang Anda coba lakukan dan seberapa rumit sistem Anda.

Kapitan adalah alat investasi yang kuat . Gunakan dalam skenario kompleks di mana Anda harus menggunakan banyak aplikasi di tumpukan cluster.

Jika Anda memiliki aplikasi standar, Anda baru belajar Kubernetes atau sudah senang dengan alur kerja Anda, maka Helm atau alternatifnya saat ini akan bekerja.

Saya membayangkan Helm sebagai tepat untuk Kubernetes , dan Kapitan adalah sesuatu seperti Wayang .

Pada posting berikutnya saya akan memberikan contoh spesifik dan menjelaskan secara rinci inventaris. Tulis tentang apa yang ingin Anda ketahui atau setujui / tidak setujui dalam pos ini.

Terima kasih kepada Jacek Gruzewski .