🎀 📑 🛰️ 7 faktor yang hilang dalam pendekatan 12 Factor App 🐂 🍓 ♈️

Catatan perev. : Kegembiraan yang dialami para pemimpin tim kami ketika mereka melihat materi ini di blog IBM Cloud - semacam "perpanjangan" dari Aplikasi Dua Belas-Faktor yang legendaris, - berbicara untuk dirinya sendiri. Pertanyaan-pertanyaan yang diajukan oleh penulis tidak hanya dari telinga, tetapi benar-benar vital, yaitu relevan dalam kehidupan sehari-hari. Pemahaman mereka berguna tidak hanya untuk insinyur DevOps, tetapi juga untuk pengembang yang membuat aplikasi modern yang berjalan di Kubernetes.

Metodologi aplikasi 12 faktor yang terkenal adalah seperangkat aturan yang didefinisikan dengan jelas untuk mengembangkan layanan-layanan mikro. Mereka banyak digunakan untuk menjalankan, skala, dan menyebarkan aplikasi. Di platform IBM Cloud Private, kami mengikuti 12 prinsip yang sama ketika mengembangkan aplikasi yang dipaketkan. Artikel “ Kubernetes & aplikasi 12 faktor ” membahas secara spesifik penggunaan 12 faktor ini (semuanya didukung oleh model orkestrasi wadah Kubernetes).

Berpikir tentang prinsip-prinsip pengembangan layanan wadah kemas yang bekerja di bawah kendali Kubernetes, kami sampai pada kesimpulan berikut: 12 faktor di atas sepenuhnya benar, tetapi yang lain juga sangat penting untuk mengatur lingkungan produksi:

diamati
prediktabilitas ( dapat dijadwalkan) ;
dapat diperbarui (dapat diperbarui ) ;
hak minimum
pengendalian (dapat diaudit) ;
keamanan (diamankan) ;
terukur

Mari kita memikirkan prinsip-prinsip ini dan mencoba mengevaluasi signifikansinya. Untuk menjaga keseragaman, kami menambahkannya ke yang sudah ada - karenanya, kami akan mulai dengan XIII ...

Prinsip XIII: Observabilitas

Aplikasi harus memberikan informasi tentang status dan indikator mereka saat ini.

Sistem terdistribusi dapat menjadi sulit untuk dikelola karena banyak layanan mikro terintegrasi ke dalam suatu aplikasi. Bahkan, berbagai roda gigi harus bergerak bersamaan agar mekanisme (aplikasi) bekerja. Jika kegagalan terjadi di salah satu layanan microser, sistem akan secara otomatis mendeteksi dan memperbaikinya. Kubernetes menyediakan mekanisme penyelamatan yang sangat baik, seperti tes kesiapan dan keaktifan .

Dengan bantuan mereka, Kubernetes memastikan bahwa aplikasi tersebut siap menerima lalu lintas. Jika kesiapan gagal, Kubernetes berhenti mengirimkan lalu lintas ke pod sampai pengujian berikutnya menunjukkan bahwa pod siap.

Misalkan kita memiliki aplikasi yang terdiri dari 3 layanan mikro: frontend, logika bisnis, dan database. Agar aplikasi berfungsi, sebelum menerima lalu lintas, frontend harus memastikan bahwa logika bisnis dan basis data siap. Ini dapat dilakukan dengan menggunakan tes kesiapan - ini memungkinkan Anda untuk memastikan bahwa semua dependensi berfungsi.

Animasi menunjukkan bahwa permintaan ke pod tidak dikirim sampai tes kesiapan menunjukkan kesiapannya:

Uji Kesiapan Beraksi: Kubernetes menggunakan probe kesiapan untuk memeriksa apakah pod siap menerima lalu lintas

Ada tiga jenis tes: menggunakan HTTP, permintaan TCP, dan perintah. Anda dapat mengontrol konfigurasi tes, misalnya, menunjukkan frekuensi mulai, ambang batas keberhasilan / kegagalan dan berapa lama menunggu jawaban. Dalam hal tes liveness, Anda perlu menetapkan satu parameter yang sangat penting - initialDelaySeconds . Pastikan tes dimulai hanya setelah aplikasi siap. Jika parameter ini diatur secara tidak benar, aplikasi akan terus-menerus restart. Inilah cara penerapannya:

 livenessProbe: # an http probe httpGet: path: /readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5

Melalui tes keaktifan, Kubernetes memeriksa untuk melihat apakah aplikasi Anda berjalan. Jika aplikasi berfungsi normal, maka Kubernetes tidak melakukan apa pun. Jika "mati", Kubernetes menghapus pod dan memulai yang baru sebagai balasannya. Ini sesuai dengan kebutuhan layanan mikro tanpa kewarganegaraan dan daur ulangnya ( faktor IX, Disposabilitas ). Animasi di bawah ini mengilustrasikan situasi di mana Kubernetes me-restart pod setelah gagal tes keaktifan:

Uji keaktifan dalam aksi: Kubernet memeriksa apakah polong "hidup" dengannya

Keuntungan besar dari tes ini adalah bahwa Anda dapat menggunakan aplikasi dalam urutan apa pun tanpa khawatir tentang ketergantungan.

Namun, kami menemukan bahwa tes ini tidak cukup untuk lingkungan produksi. Biasanya, aplikasi memiliki metrik sendiri yang perlu dilacak, misalnya, jumlah transaksi per detik. Klien menetapkan ambang batas untuknya dan mengonfigurasi pemberitahuan. IBM Cloud Private mengisi celah ini dengan tumpukan pemantauan Prometheus dan Grafana yang sangat aman dengan sistem kontrol akses berbasis peran. Lihat bagian pemantauan IBM Cloud Private cluster untuk informasi lebih lanjut.

Prometheus mengumpulkan data target dari metrik titik akhir. Aplikasi Anda harus menentukan metrik titik akhir menggunakan anotasi berikut:

 prometheus.io/scrape: 'true'

Setelah itu, Prometheus secara otomatis mendeteksi titik akhir dan mengumpulkan metrik darinya (seperti yang ditunjukkan dalam animasi berikut):

Koleksi metrik khusus

Catatan perev. : Akan lebih benar untuk mengarahkan panah ke arah yang berlawanan, karena Prometheus berjalan dan menentukan titik akhir, dan Grafana sendiri mengambil data dari Prometheus, tetapi dalam arti ilustrasi umum ini tidak terlalu kritis.

Prinsip XIV: Dapat diprediksi

Aplikasi harus menyediakan prediksi kebutuhan sumber daya.

Bayangkan bahwa seorang pemandu telah memilih tim Anda untuk bereksperimen dengan proyek Kubernetes. Anda bekerja keras untuk menciptakan lingkungan yang sesuai. Hasilnya adalah aplikasi yang menunjukkan waktu respons dan kinerja yang patut dicontoh. Kemudian tim lain bergabung dengan pekerjaan itu. Dia menciptakan aplikasi dan meluncurkannya di lingkungan yang sama. Setelah meluncurkan aplikasi kedua, kinerja yang pertama tiba-tiba menurun. Dalam hal ini, alasan perilaku ini harus dicari dalam sumber daya komputasi (CPU dan memori) yang tersedia untuk wadah Anda. Probabilitas tinggi dari kekurangan mereka. Timbul pertanyaan: bagaimana menjamin alokasi sumber daya komputasi yang dibutuhkan oleh aplikasi?

Kubernetes memiliki opsi luar biasa yang memungkinkan Anda untuk mengatur sumber daya minimum dan menetapkan batasan untuk wadah. Minimum dijamin. Jika sebuah wadah membutuhkan sumber daya, Kubernetes menjalankannya hanya pada host yang dapat disediakan oleh sumber daya ini. Di sisi lain, batas atas memastikan bahwa selera wadah tidak pernah melebihi nilai tertentu.

Minimum dan batasan untuk wadah

Cuplikan kode YAML berikut menunjukkan penyetelan sumber daya komputasi:

 resources: requests: memory: "64Mi" cpu: "150m" limits: memory: "64Mi" cpu: "200m"

Catatan perev. : Untuk informasi lebih lanjut tentang penyediaan sumber daya di Kubernetes, permintaan dan batasan, lihat laporan terbaru kami dan ulasannya, “ Autoscaling dan Manajemen Sumberdaya di Kubernetes, ” serta dokumentasi K8 .

Peluang menarik lainnya untuk administrator di lingkungan produksi adalah menetapkan kuota untuk namespace . Jika kuota disetel, Kubernetes tidak akan membuat kontainer yang permintaan / batasannya tidak ditentukan di namespace ini. Contoh pengaturan kuota untuk namespace dapat dilihat pada gambar di bawah ini:

Kuota untuk ruang nama

Prinsip XV. Pembaruan

Aplikasi harus memperbarui format data dari generasi sebelumnya.

Seringkali ada kebutuhan untuk menambal aplikasi produksi yang berfungsi untuk menghilangkan kerentanan atau memperluas fungsionalitas. Penting bahwa pembaruan berlangsung tanpa gangguan dalam pekerjaan. Kubernetes menyediakan mekanisme pembaruan bergulir yang memungkinkan Anda untuk memperbarui aplikasi Anda tanpa downtime. Dengan menggunakan mekanisme ini, Anda dapat memperbarui melalui pod pada satu waktu tanpa menghentikan seluruh layanan. Berikut ini adalah representasi skematis dari proses ini (di atasnya aplikasi diperbarui ke versi kedua):

Contoh deskripsi YAML yang sesuai:

 minReadySeconds: 5 strategy: # ,      type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1

Perhatikan maxSurge dan maxSurge :

maxUnavailable - parameter opsional yang menetapkan jumlah maksimum pod yang mungkin tidak tersedia selama proses pembaruan. Meskipun bersifat opsional, tetap bernilai menetapkan nilai tertentu untuk menjamin ketersediaan layanan;
maxSurge adalah parameter opsional tetapi penting lainnya. Ini menetapkan jumlah maksimum pod yang dapat dibuat melebihi jumlah yang diinginkan.

Prinsip XVI: Hak Istimewa Minimum

Kontainer harus bekerja dengan minimum hak istimewa.

Kedengarannya pesimistis, tetapi Anda harus menganggap setiap resolusi dalam wadah sebagai kerentanan potensial (lihat ilustrasi). Misalnya, jika wadah berjalan sebagai root, maka siapa pun yang memiliki akses ke sana dapat menyuntikkan proses berbahaya di sana. Kubernetes menyediakan Kebijakan Keamanan Pod (PSP) untuk membatasi akses ke sistem file, port host, kemampuan Linux, dan banyak lagi. IBM Cloud Private menawarkan satu set PSP yang siap pakai yang terikat pada wadah ketika mereka disediakan di namespace. Untuk informasi lebih lanjut, lihat Menggunakan ruang nama dengan Kebijakan Keamanan Pod .

Semua resolusi adalah vektor serangan potensial

Prinsip XVII: Pengendalian

Anda perlu tahu siapa, apa, di mana, dan kapan untuk semua operasi kritis misi.

Kontrol sangat penting untuk operasi apa pun dengan kluster atau aplikasi Kubernetes. Misalnya, jika aplikasi memproses transaksi kartu kredit, Anda harus mengaktifkan audit agar memiliki kontrol jejak setiap transaksi. IBM Cloud Private menggunakan Cloud Auditing Data Federation (CADF) standar industri, yang tidak sesuai dengan implementasi cloud tertentu. Untuk informasi lebih lanjut, lihat Pencatatan audit di IBM Cloud Private .

Acara CADF berisi data berikut:

initiator_id - ID pengguna yang melakukan operasi;
target_uri - target CADF URI (misalnya: data / keamanan / proyek);
action - action akan dilakukan, biasanya operation: resource_type .

Prinsip XVIII: Keamanan (identifikasi, jaringan, ruang lingkup, sertifikat)

Diperlukan untuk melindungi aplikasi dan sumber daya dari orang asing.

Item ini layak mendapat artikel terpisah. Cukuplah untuk mengatakan bahwa aplikasi produksi memerlukan perlindungan ujung ke ujung. IBM Cloud Private mengambil langkah-langkah berikut untuk memastikan keamanan lingkungan produksi:

otentikasi: verifikasi identitas;
otorisasi: pemeriksaan akses pengguna terotentikasi;
manajemen sertifikat: bekerja dengan sertifikat digital, termasuk pembuatan, penyimpanan, dan pembaruan;
perlindungan data: memastikan keamanan data yang dikirimkan dan disimpan;
keamanan dan isolasi jaringan: mencegah akses ke jaringan oleh pengguna dan proses yang tidak sah;
penasihat kerentanan: mengidentifikasi kerentanan dalam gambar;
Penasihat Mutasi: Deteksi mutasi dalam wadah.

Untuk informasi lebih lanjut, lihat IBM Cloud Private Security Guide .

Catatan khusus adalah manajer sertifikat. Layanan ini di IBM Cloud Private didasarkan pada proyek open source Jetstack . Manajer Sertifikat memungkinkan Anda mengeluarkan dan mengelola sertifikat untuk layanan yang berjalan di IBM Cloud Private. Ini mendukung sertifikat publik dan ditandatangani sendiri, terintegrasi penuh dengan kubectl dan kontrol akses berbasis peran.

Prinsip XIX: Dapat diukur

Penggunaan aplikasi harus dapat diukur untuk keperluan kuota dan penyelesaian antar departemen.

Pada akhirnya, perusahaan harus membayar biaya TI (lihat gambar di bawah). Sumber daya komputasi yang didedikasikan untuk menjalankan wadah harus dapat diukur, dan organisasi yang menggunakan cluster harus bertanggung jawab. Pastikan untuk mengikuti Prinsip XIV - Prediktabilitas. IBM Cloud Private menawarkan layanan akuntansi yang mengumpulkan data tentang sumber daya komputasi untuk setiap wadah dan menggabungkannya di tingkat namespace untuk perhitungan lebih lanjut (sebagai bagian dari showbacks atau tolak bayar).

Penggunaan aplikasi harus dapat diukur

Kesimpulan

Saya harap Anda menyukai topik yang diangkat dalam artikel ini, dan Anda mencatat faktor-faktor yang sudah Anda gunakan dan pikirkan tentang faktor-faktor yang masih ada di sela-sela.

Untuk informasi lebih lanjut, saya sarankan Anda membiasakan diri dengan rekaman kinerja kami di KubeCon 2019 di Shanghai. Di dalamnya, Michael Elder dan saya membahas 12 + 7 prinsip untuk orkestrasi wadah berbasis Kubernetes.

7 faktor yang hilang dalam pendekatan 12 Factor App