Temu duga Backend: apa yang boleh dilindungi oleh PodDisruptionBudget, dan apa yang tidak boleh dilindunginya?

Prompt dan konteks

Anda mengendalikan perkhidmatan yang diuruskan oleh Deployment dengan bilangan replika yang diingini sebanyak lima. Semasa peningkatan kluster, satu nod mesti di-drain dan pasukan bimbang kehilangan beberapa replika sekaligus. Penemu duga meminta anda mereka bentuk atau menyemak PodDisruptionBudget dan menerangkan kesannya terhadap rolling release, kegagalan nod, dan pemadaman Pod secara terus.

Ini menguji sempadan ketersediaan Kubernetes dan penaakulan operasi. PDB mengehadkan bilangan replika terpilih yang boleh tidak tersedia secara serentak disebabkan oleh gangguan sukarela (voluntary disruptions). Ia bukan pengawal replika dan bukan jaminan terhadap setiap kegagalan. Jawapan yang baik menghubungkan replika yang diingini, pemilih (selectors), titik masuk eviction, dan baki kapasiti.

Perkara yang dinilai oleh penemu duga

• Sama ada anda membezakan gangguan sukarela daripada gangguan tidak sukarela.
• Sama ada anda menerangkan semantik saling eksklusif bagi minAvailable dan maxUnavailable.
• Sama ada anda tahu bahawa PDB bergantung pada bilangan replika yang diingini oleh pengawal dan pemilih Pod yang tepat.
• Sama ada anda boleh menerangkan cubaan semula drain, laluan pemadaman yang tidak dilindungi, dan sempadan rolling-update.
• Sama ada anda menambah replika, topologi, probe, dan kapasiti ke dalam pelan ketersediaan.

Soalan untuk dijelaskan terlebih dahulu

• Adakah perkhidmatan diuruskan oleh Deployment, StatefulSet, atau pengawal lain yang disokong?
• Adakah pemilih padan hanya dengan beban kerja ini? Pemilih yang luas boleh mencampurkan Pod yang tidak berkaitan ke dalam satu belanjawan.
• Adakah anda melindungi daripada node drain dan penurunan skala (scale-down), atau gangguan bekalan elektrik? PDB tidak dapat menghalang perkara yang kedua.
• Adakah replika disebarkan merentasi zon dengan kapasiti yang mencukupi dan readiness yang betul? PDB mengehadkan eviction; ia tidak mencipta kapasiti.
• Berapa lama penyelenggaraan boleh menunggu? Belanjawan yang terlalu ketat boleh memanjangkan tetingkap masa, manakala belanjawan yang longgar mengurangkan kapasiti.

Kerangka jawapan 30 saat

"PDB mengehadkan permintaan gangguan sukarela yang dibuat melalui Eviction API. Dengan lima replika, minAvailable: 4 atau maxUnavailable: 1 boleh menyatakan bahawa paling banyak satu replika harus hilang pada satu masa, tetapi medan tersebut adalah saling eksklusif. Belanjawan bergantung pada replika yang diingini oleh beban kerja dan pemilih yang tepat; kegagalan nod, pemadaman terus Deployment, dan rolling update aplikasi tidak dihentikan sepenuhnya olehnya. Jika drain ditolak, saya akan memeriksa belanjawan, replika sihat, kapasiti, dan laluan eviction, sambil menggunakan replika, topologi, dan probe untuk reka bentuk ketersediaan yang selebihnya."

Jawapan mendalam

Mengelaskan gangguan

Node drain, penyelenggaraan nod, dan beberapa tindakan penurunan skala kluster biasanya meminta pemindahan Pod melalui Eviction API. Ini adalah gangguan sukarela, jadi PDB boleh menolak eviction buat sementara waktu. Gangguan bekalan elektrik, kegagalan kernel, atau pengasingan rangkaian adalah gangguan tidak sukarela; PDB tidak dapat menghalangnya, dan Pod tidak tersedia yang terhasil masih mempengaruhi status belanjawan.

Menerangkan medan yang saling eksklusif

minAvailable menyatakan bilangan Pod sepadan yang mesti kekal tersedia selepas eviction. maxUnavailable menyatakan bilangan Pod sepadan yang boleh tidak tersedia selepas eviction. Kedua-duanya tidak boleh ditetapkan serentak. Bagi lima replika yang diingini, minAvailable: 4 dan maxUnavailable: 1 menyatakan niat yang serupa pada saiz tersebut, tetapi peratusan berubah mengikut skala dan pembundaran, jadi nyatakan bilangan yang diingini dan semantik versi.

Menunjukkan kebergantungan pada replika yang diingini dan pemilih

Control plane mencari beban kerja pengurusan melalui Pod owner references dan memperoleh bilangan yang diingini daripada .spec.replicas. Pemilih harus sepadan dengan label Deployment atau StatefulSet dan kekal khusus. Pemilih yang sepadan dengan berbilang aplikasi mencipta belanjawan kongsi; tanpa sumber pemilik yang disokong, Kubernetes tidak dapat memperoleh jumlah keseluruhan dengan pasti.

Menggunakan konfigurasi untuk menunjukkan sempadan

Contoh ini membenarkan paling banyak satu Pod terpilih tidak tersedia akibat eviction sukarela apabila beban kerja menginginkan lima replika:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-api
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: checkout-api

Ia tidak menjamin empat Pod sihat pada setiap masa. Replika mungkin sudah tidak sihat, atau nod mungkin gagal secara tiba-tiba. Sebelum pelancaran (rollout), sahkan pemilih, readiness, replika yang diingini, dan kapasiti pelbagai zon.

Menerangkan penolakan dan cubaan semula drain

Apabila tiada eviction dibenarkan pada masa ini, replika sihat sudah berada di bawah minAvailable, atau pengawal belanjawan tidak dapat mengira status, Eviction API mungkin menolak permintaan tersebut. kubectl drain mencuba semula permintaan yang gagal secara berkala sehingga Pod ditamatkan atau had masa (timeout) dicapai. Penyelesaian masalah bermula dengan status PDB, Pod yang dipilih, bilangan sihat, kegagalan readiness, dan pengesahan bahawa tindakan penyelenggaraan benar-benar menggunakan Eviction API.

Mengasingkan rolling update dan pemadaman terus

Rolling update bagi Deployment dan StatefulSet ditadbir oleh strategi kemas kini mereka sendiri; PDB bukan pengganti sepenuhnya untuk peraturan tersebut. PDB juga tidak boleh mengehadkan setiap pemadaman terus bagi Pod atau Deployment. Sistem pelepasan harus menggabungkan maxUnavailable, maxSurge, readiness, dan tingkah laku rollback dan bukannya menyerahkan semua keselamatan pelepasan kepada PDB semata-mata.

Menambah kebolehpercayaan di luar PDB

PDB meliputi satu kelas gangguan. Menahan kegagalan nod atau zon juga memerlukan replika yang mencukupi, penyebaran topologi (topology spread), ruang kapasiti tambahan (headroom), readiness dan liveness yang betul, penamatan anggun (graceful termination), dan pengosongan sambungan (connection draining). Untuk perkhidmatan stateful berasaskan kuorum, peroleh belanjawan daripada keperluan kuorum; untuk perkhidmatan stateless, sahkan ketersediaan dengan trafik sebenar, masa pemulihan, dan ujian kapasiti.

Model jawapan berkualiti tinggi

"Deployment memerlukan lima replika, jadi saya akan mengesahkan terlebih dahulu bahawa pemilih PDB sepadan hanya dengan checkout-api dan bahawa readiness serta kapasiti rentas zon adalah kukuh. Jika eviction sukarela mesti meninggalkan empat replika yang tersedia, saya boleh menggunakan minAvailable: 4 atau maxUnavailable: 1; kedua-duanya saling eksklusif, dan saya akan memilih nilai mutlak atau peratusan berdasarkan tingkah laku penskalaan.

PDB melindungi node drain, penyelenggaraan, dan beberapa tindakan scale-down yang menggunakan Eviction API. Ia tidak dapat menghentikan gangguan elektrik, kegagalan kernel, atau pemadaman Pod secara terus, dan rolling update dikawal terutamanya oleh strategi Deployment. Jika drain ditolak, saya akan memeriksa replika sihat, status belanjawan, pemilih, kegagalan readiness, kapasiti, dan laluan eviction; kubectl drain mungkin mencuba semula sehingga timeout.

Saya akan mengesahkan PDB bersama dengan replika, penyebaran topologi, readiness, graceful termination, dan rollback pelepasan. Belanjawan yang terlalu ketat boleh menyekat penyelenggaraan, manakala belanjawan yang terlalu longgar boleh melanggar kapasiti minimum, jadi ambang had harus diperoleh daripada trafik dan latihan kegagalan dan bukannya peratusan sejagat."

Kesilapan lazim

• Mendakwa PDB menghalang kegagalan nod: gangguan sukarela dan tidak sukarela terkeliru → hadkan dakwaan kepada laluan Eviction API.
• Menetapkan kedua-dua minAvailable dan maxUnavailable: medan tersebut saling eksklusif → pilih satu bentuk ungkapan belanjawan.
• Mengira Pod semasa sahaja: belanjawan menggunakan replika yang diingini → periksa owner references dan .spec.replicas.
• Memilih keseluruhan namespace: aplikasi yang tidak berkaitan berkongsi satu belanjawan → gunakan pemilih beban kerja yang khusus.
• Menyatakan PDB melindungi rolling update dan pemadaman terus: pengawal dan laluan pemadaman mempunyai semantik berasingan → periksa setiap dasar dan laluan kebenaran.
• Memadamkan PDB apabila drain tersekat: risiko kapasiti boleh meningkat → periksa replika sihat, probe, status belanjawan, dan kapasiti terlebih dahulu.
• Mengkonfigurasi PDB tanpa topologi atau kapasiti: Pod yang masih hidup boleh berkongsi satu domain kegagalan → gabungkan zon, headroom, dan latihan simulasi.
• Menganggap peratusan sebagai bilangan replika tetap: penskalaan mengubah maknanya → nyatakan skala yang diingini, pembundaran, dan tingkah laku autoscaling.

Soalan susulan dan jawapan

Soalan susulan 1: Apakah maksud minAvailable: 80% bagi lima replika?

Ia memerlukan bilangan tersedia yang dihasilkan oleh peraturan peratusan dan pembundaran Kubernetes. Jangan anggap ia sentiasa tepat empat; sahkan semantik API semasa dan perhatikan tingkah laku selepas penskalaan.

Soalan susulan 2: Mengapa drain masih boleh menyebabkan perkhidmatan tidak tersedia?

PDB mengehadkan eviction sukarela yang diterima; ia tidak boleh membaiki Pod yang sudah tidak sihat, mencipta kapasiti, membatalkan penumpuan zon tunggal, atau menjadikan aplikasi toleran terhadap pergerakan sambungan. Readiness, topologi, kapasiti, dan graceful termination mesti disahkan bersama-sama.

Soalan susulan 3: Adakah kubectl delete pod disekat oleh PDB?

Jangan anggap ia disekat. Dokumentasi Kubernetes menyatakan bahawa memadam Pod atau Deployment secara terus boleh memintas perlindungan PDB, jadi kebenaran, audit, dan proses pelepasan mesti mengehadkan laluan tersebut.

Soalan susulan 4: PDB menunjukkan sifar gangguan yang dibenarkan (allowed disruptions). Patutkah anda melonggarkannya terlebih dahulu?

Mula-mula periksa pemilih, replika yang diingini, replika sihat, kegagalan readiness, dan status pengawal. Melonggarkan belanjawan secara membuta tuli boleh menyembunyikan masalah kesihatan Pod. Jika penyelenggaraan benar-benar memerlukan perubahan sementara, nilaikan kapasiti dan rollback, rekodkan tetingkap masa, dan pulihkan dasar tersebut.

Soalan susulan 5: Bagaimanakah perkhidmatan stateful dan stateless berbeza?

Perkhidmatan stateful mesti mengekalkan kuorum atau replika minimum protokol ketekalan serta mengesahkan pengimbangan semula (rebalancing) dan pemulihan. Perkhidmatan stateless biasanya memberi tumpuan kepada baki kapasiti, latensi, dan pengosongan sambungan. Tiada tuntutan ketersediaan yang terjamin hanya daripada bilangan replika semata-mata.

Soalan susulan 6: Bagaimanakah anda mengesahkan bahawa PDB adalah berkesan?

Dalam tetingkap masa yang terkawal, laksanakan Eviction API dan node drain, kemudian perhatikan penolakan, cubaan semula, masa tangguh penamatan (termination grace), trafik, ralat, dan masa pemulihan. Uji juga kegagalan nod dan laluan pemadaman terus supaya pasukan tidak tersilap menganggap sempadan PDB sebagai jaminan terhadap semua jenis kegagalan.