Temu Bual Reka Bentuk Sistem: Bagaimana Anda Berhijrah ke Sidecar Asli Kubernetes Secara Selamat?

Gesaan dan konteks yang berkenaan

Anda memiliki beban kerja Kubernetes yang menjalankan ejen log, proksi service-mesh, atau daemon cache setempat di sebelah aplikasi. Pasukan ingin menghijrahkan pembantu tersebut daripada bekas biasa kepada sidecar asli Kubernetes. Aplikasi mesti menunggu pembantu bersedia, kegagalan pembantu memerlukan sempadan ketersediaan yang jelas, dan reka bentuk mesti merangkumi Jobs, pelepasan bergolek (rolling releases), kuota sumber, dan pemulihan. Cadangkan pelan penghijrahan dan terangkan ketakselarasan versi (version skew), prob (probes), susunan penamatan, dan pengendalian kegagalan.

Ini ialah soalan reka bentuk sistem. Isyarat yang dinilai ialah penaakulan anda tentang sempadan dan pertukaran kompromi (trade-offs), bukannya fragmen YAML yang dihafal. Liputi kitaran hayat, keserasian, sumber, kebolehcerapan, dan pemulihan.

Perkara yang dinilai oleh penemu bual

• Menukar objektif tahap perkhidmatan (SLO) kepada dasar permulaan, kesediaan, penamatan, dan kegagalan.
• Menerangkan sempadan antara sidecar asli, bekas biasa, Deployment berasingan, dan DaemonSet.
• Mencari risiko versi merentasi pelayan API, nod, webhook, dan klien.
• Mengurangkan risiko penghijrahan dengan belanjawan sumber, peluncuran berperingkat, metrik, dan pemulihan.
• Mengendalikan contoh bertentangan seperti penyelesaian Job, proksi yang tersekat, prob yang gagal, dan naik taraf nod.

Bahan persediaan SDE II Amazon menerangkan penilaian reka bentuk sistem dari segi kepraktisan, ketepatan, kecekapan, kebolehpercayaan, pengoptimuman, dan kebolehskalaan. Soalan ini meminta anda menggunakan matlamat tersebut pada kitaran hayat Pod dan kawalan pelepasan.

Soalan penjelasan

1. Adakah pembantu ini satu salinan bagi setiap Pod atau satu salinan bagi setiap nod? Adakah ia mesti berkongsi ruang nama rangkaian atau volum aplikasi?
2. Bolehkah aplikasi menerima trafik sebelum pembantu bersedia? Adakah kegagalan permulaan menyekat pelepasan, merosotkan tingkah laku, atau membenarkan pintasan (bypass)?
3. Adakah ini perkhidmatan jangka panjang, Job sekali jalan, atau kedua-duanya? Adakah ia mesti mengosongkan log (flush) atau memuat naik data semasa penamatan?
4. Adakah versi Kubernetes selaras merentasi kluster, pelayan API, dan nod? Mungkinkah webhook kemasukan (admission webhook), pemapar templat, atau klien menggugurkan medan yang tidak diketahui?
5. Apakah belanjawan CPU, memori, storan efemeral, dan rangkaian pembantu? Adakah kegagalannya menggunakan belanjawan ralat aplikasi?
6. Bolehkah anda melakukan kenari mengikut ruang nama atau beban kerja sambil mengekalkan templat bekas biasa sebagai suis pemulihan?

Rangka kerja jawapan 30 saat

Mulakan dengan matlamat: kekalkan pembantu dan aplikasi dalam satu Pod, mulakannya mengikut susunan, jadikan tingkah laku boleh dicerap, dan pastikan pemulihan pantas tanpa membenarkan pembantu menyekat selama-lamanya. Laksanakan sidecar asli dalam initContainers dengan restartPolicy: Always peringkat bekas, prob kesediaan yang bermakna, dan belanjawan sumber yang jelas. Lindungi keserasian dengan semakan kluster dan kemasukan. Lancarkan dua templat secara berperingkat, bandingkan kependaman permulaan dan kadar ralat, kembali kepada bentuk lama jika ambang dilanggar, dan uji penyelesaian Job serta pembersihan penamatan secara berasingan.

Jawapan mendalam langkah demi langkah

1. Lukis sempadan kitaran hayat terlebih dahulu

Sidecar asli Kubernetes ialah bekas init khas: restartPolicy: Always peringkat bekas membolehkannya bermula semasa pemulaan dan terus berjalan. Ia masih mengikut susunan bekas init, jadi bekas init seterusnya dan bekas aplikasi menunggu ia boleh digunakan. "Proksi bersedia terlebih dahulu" menjadi jaminan struktur peringkat Pod dan bukannya gelung pengundian (polling loop) aplikasi.

Aplikasi dan sidecar berkongsi ruang nama rangkaian dan storan Pod. Ini berguna untuk soket Unix, volum log, atau port proksi setempat. Jika pembantu hanya menyediakan keupayaan peringkat nod, nilaikan DaemonSet daripada membayar kos tersebut sekali bagi setiap Pod.

2. Tentukan dasar kesediaan dan kegagalan

Berikan pembantu readinessProbe yang mewakili keupayaan sebenar: konfigurasi satah kawalan dimuatkan, port pendengaran tersedia, dan sijil kritikal sah. Kesediaan sidecar boleh mempengaruhi kesediaan Pod, jadi prob yang gagal boleh mengeluarkan keseluruhan Pod daripada perkhidmatan. Prob melaporkan keadaan; ia tidak menggantikan percubaan semula, had kadar, atau penurunan prestasi secara anggun (graceful degradation).

Asingkan kegagalan permulaan, ranap dalam proses, dan kebergantungan yang tidak tersedia buat sementara waktu. Kegagalan permulaan biasanya memastikan Pod berada di luar perkhidmatan. Ranap yang sedang berjalan dimulakan semula oleh Always, tetapi kiraan permulaan semula, masa pemulihan, dan kadar ralat mesti menunjukkan sama ada SLO telah terjejas. Pembantu pilihan boleh mempunyai pintasan; proksi keselamatan atau kebenaran harus gagal-tutup (fail closed) dan menghentikan peluncuran dengan cepat apabila belanjawan ralatnya dilebihi.

3. Kendalikan penamatan, Jobs, dan pembersihan (flushing)

Sidecar asli ditamatkan selepas bekas aplikasi, dan pelbagai sidecar dimatikan dalam susunan terbalik. Oleh itu, ejen log boleh mengosongkan penimbal selepas aplikasi keluar, tetapi tempoh ihsan penamatan memerlukan had atas yang tegas. Rekod jumlah yang hilang apabila masa pembersihan tamat; jangan sekali-kali menunggu selama-lamanya.

Bagi Job, sahkan bahawa pengawal menganggap penyelesaian bekas utama sebagai penyelesaian tugas dan bukannya menunggu sidecar selama-lamanya. Sidecar mungkin terus dimulakan semula sebelum Job selesai, jadi dedahkan hasil tugas, hasil pembersihan sidecar, dan integriti data akhir sebagai isyarat dan amaran yang berasingan.

4. Periksa versi dan laluan mutasi

Sidecar asli adalah stabil dan didayakan secara lalai dalam Kubernetes v1.33; keupayaan ini adalah beta dan didayakan secara lalai dari v1.29. Sebelum penghijrahan, periksa kubelet sebenar, pelayan API, komponen kemasukan, dan get ciri (feature gates) pada setiap kolam nod.

Webhook bermutasi, alat templat, atau klien yang lebih lama mungkin tidak memahami restartPolicy peringkat bekas dan mungkin menggugurkannya semasa menulis semula objek. Sahkan objek akhir dalam CI, rekod bentuk sidecar dalam log kemasukan, dan jalankan Pod prob yang mengesahkan susunan masa jalanan. Jika rantaian tersebut tidak boleh dipercayai, kekalkan sandaran bekas biasa atau jedakan penghijrahan.

5. Kira kesan sumber dan penjadualan

Sidecar tidak percuma. Permintaan CPU, memori, dan storan efemeralnya mengambil bahagian dalam pengiraan sumber berkesan Pod, yang mempengaruhi QoS, kuota, dan penjadualan. Gunakan puncak aplikasi, puncak permulaan pembantu, dan had penimbal untuk mengira permintaan dan had; pantau pemecahan nod, penyingkiran (evictions), OOM, dan masa giliran permulaan.

Jika pembantu memerlukan penskalaan bebas, irama pelepasan berasingan, atau domain kegagalan yang lebih luas, Deployment yang berasingan mungkin lebih sesuai. Sidecar asli memberikan perkongsian setempat dan susunan kitaran hayat, sambil menggabungkan penjadualan, sumber, dan pelepasan ke dalam satu unit.

6. Reka bentuk kenari, kebolehcerapan, dan pemulihan

Sediakan dua templat Pod: sidecar asli dan bentuk bekas biasa lama. Lancarkan mengikut ruang nama, label, atau beban kerja, dengan syarat henti automatik untuk setiap kelompok. Jejak sekurang-kurangnya kependaman cipta-Pod-ke-Ready, kegagalan kesediaan sidecar, kiraan permulaan semula, ralat permintaan aplikasi, kedalaman penimbal, kehilangan pembersihan, puncak CPU dan memori, serta kependaman penyelesaian Job.

Semasa penghijrahan, rekod bentuk yang dijangkakan dan bentuk yang diperhatikan; objek Deployment yang berjaya tidak mencukupi. Jika webhook menggugurkan medan, kependaman Ready merosot, atau permulaan semula pembantu melepasi ambang, hentikan pengembangan dan beralih kepada templat lama. Pemulihan juga mesti memeriksa bahawa templat lama tidak mewarisi konfigurasi baharu, format volum, atau andaian port.

7. Letakkan keselamatan dan kebolehcerapan di dalam sempadan

Kerana sidecar berkongsi rangkaian dan volum Pod, ia mempunyai permukaan capaian Pod. Berikan keistimewaan paling sedikit, sistem fail akar baca sahaja, akaun perkhidmatan yang jelas, dan dasar rangkaian. Jangan langkau kawalan audit hanya kerana ia "hanya pembantu." Tambahkan label Pod, bekas, dan versi pelepasan pada log, metrik, dan surihan supaya kegagalan aplikasi boleh diasingkan daripada kegagalan pembantu.

Contoh jawapan berkualiti tinggi

Saya akan terlebih dahulu mengklasifikasikan pembantu sebagai kebergantungan bagi setiap Pod dan mengesahkan bahawa ia benar-benar memerlukan rangkaian atau storan yang dikongsi. Jika ia merupakan keupayaan peringkat nod, saya akan memilih DaemonSet. Templat penghijrahan menggunakan sidecar asli: letakkan pembantu dalam initContainers dan tetapkan restartPolicy: Always peringkat bekas. Ia bermula mengikut susunan init, readinessProbe mengesahkan konfigurasi dan port boleh digunakan, dan hanya selepas itu aplikasi memasuki perkhidmatan.

Saya akan membahagikan kegagalan kepada kegagalan permulaan, ranap yang sedang berjalan, dan kebergantungan yang tidak tersedia buat sementara waktu. Proksi keselamatan gagal-tutup; peningkatan pilihan mengekalkan pintasan. Semasa penamatan, susunan penutupan sidecar selepas aplikasi membenarkan pembersihan yang terhad. Untuk Jobs, saya akan mengesahkan penyelesaian bekas utama dan pembersihan sidecar secara berasingan supaya pembantu yang berjalan lama tidak dapat menyekat keadaan Job.

Sebelum peluncuran, saya akan memeriksa pelayan API, setiap kolam nod, get ciri, webhook, dan klien templat kerana alat yang lebih lama boleh menggugurkan restartPolicy. CI mengesahkan objek akhir, dan kenari mengesahkan susunan dan kesediaan Pod sebenar. Belanjawan sumber merangkumi puncak pembantu dalam QoS, kuota, dan penjadualan; papan pemuka menunjukkan kependaman Ready, permulaan semula, ralat, penimbal, dan kehilangan. Dua templat dilancarkan secara berkelompok, dengan sebarang pelanggaran ambang menghentikan pengembangan dan kembali kepada bentuk lama. Ini menggunakan jaminan kitaran hayat asli sambil menukar sempadan versi, sumber, dan kegagalan kepada pintu kawalan pelepasan yang boleh dicerap.

Kesilapan biasa

• Menampal YAML tanpa menerangkan mengapa sidecar asli diperlukan atau bila bekas biasa atau beban kerja berasingan lebih baik.
• Menulis restartPolicy: Always pada peringkat Pod dan bukannya di dalam definisi bekas sidecar.
• Mengkonfigurasi livenessProbe sahaja dan mengabaikan cara kegagalan kesediaan mengubah tingkah laku trafik dan peluncuran.
• Menganggap versi Kubernetes sudah mencukupi tanpa memeriksa ketakselarasan nod, webhook, dan klien.
• Menganggap sidecar adalah percuma dan terlepas pandang kuota sumber, puncak permulaan, penimbalan, dan kesan QoS.
• Menguji perkhidmatan jangka panjang sahaja dan melupakan penyelesaian Job, masa tamat pembersihan, dan susunan penamatan terbalik.
• Memulihkan imej sahaja tanpa memeriksa templat lama, port, volum, dan output kemasukan.

Soalan susulan dan jawapan

Bagaimana jika nod lama tidak menyokong sidecar asli?

Hentikan peluncuran dan asingkan mengikut kolam nod. Jika objek tidak boleh dipercayai untuk mengekalkan dasar peringkat bekas, gunakan templat bekas biasa atau naik taraf nod; menggugurkan medan yang tidak diketahui secara senyap bukanlah keserasian.

Apakah yang berlaku apabila kesediaan sidecar terus gagal?

Pod harus kekal di luar Ready dan pengawal peluncuran harus menghentikan pengembangan. Bezakan ralat konfigurasi, kebergantungan yang tidak tersedia, dan pepijat prob, kemudian betulkan atau pulihkan. Jangan sembunyikan ketidaktersediaan sebenar dengan menjadikan prob membenarkan segalanya tanpa had.

Adakah sidecar terus berjalan selepas bekas utama Job keluar?

Sidecar asli mungkin terus berjalan dan dimulakan semula, manakala pengawal Job boleh mengenali penyelesaian bekas utama. Hadkan pembersihan dan rekod hasil tugas secara berasingan daripada integriti data supaya aktiviti pembantu yang berjalan lama tidak disalah anggap sebagai kegagalan tugas.

Mengapa tidak menggunakan Deployment yang berasingan untuk proksi?

Pilih pemisahan apabila proksi memerlukan penskalaan bebas, pelepasan, atau domain kegagalan yang lebih luas. Pilih sidecar asli apabila soket setempat, rangkaian yang dikongsi, dan susunan permulaan yang ketat adalah penting. Keputusan mengikut pergantungan dan SLO.

Bagaimanakah anda mendiagnosis tekanan sumber yang lebih tinggi selepas penghijrahan?

Bandingkan permintaan Pod berkesan, puncak permulaan, pemecahan nod, penyingkiran, dan OOM sebelum dan selepas penghijrahan; periksa penimbal dan konkurensi pembantu. Jika pembantu hanya menyediakan keupayaan peringkat nod, nilaikan DaemonSet. Jika ia mesti kekal di dalam Pod, semak semula belanjawan atau kurangkan saiz kenari.

Bagaimanakah anda membuktikan pemulihan adalah selamat?

Kekalkan cincangan (hash) templat lama. Semasa pemulihan, sahkan bentuk bekas, port, volum, akaun perkhidmatan, dan output webhook, kemudian perhatikan kelompok kenari untuk kependaman Ready, kadar ralat, dan kehilangan pembersihan. Teruskan pengembangan hanya selepas isyarat pulih.