Temu duga reka bentuk sistem: Bagaimanakah topology spread constraints Kubernetes meningkatkan ketersediaan?

Prompt dan konteks

Satu perkhidmatan tanpa keadaan (stateless) berjalan merentasi pelbagai zon dan diskalakan daripada 2 kepada 30 replika. Semasa kegagalan nod, penskalaan, dan pelepasan bergolek (rolling releases), pasukan ingin mengelakkan penumpuan replika dalam satu domain kegagalan tanpa menjadikan pelepasan baharu mustahil untuk dijadualkan. Reka bentuk topologySpreadConstraints dan terangkan bila perlu menggunakan DoNotSchedule, ScheduleAnyway, atau anti-affinity.

Perkara yang dinilai oleh penemu duga

• Sama ada anda menukar ketersediaan kepada matlamat domain kegagalan nod, zon, dan rantau yang eksplisit.
• Sama ada anda menerangkan maxSkew, minDomains, topologyKey, dan whenUnsatisfiable dengan betul.
• Sama ada anda menangani kes pinggir bagi pemilih (selector), ketiadaan label topologi, dan replika berskala kecil.
• Sama ada penempatan, PDB, kemas kini bergolek, penskalaan automatik, dan kebolehcerapan berfungsi sebagai satu reka bentuk yang bersepadu.

Soalan penjelasan

1. Adakah zon bebas dari segi kuasa, rangkaian, dan kapasiti, dan adakah kegagalan serantau termasuk dalam skop?
2. Berapa banyakkah replika yang mesti kekal selepas kehilangan satu domain kegagalan?
3. Patutkah Pod yang tidak boleh dijadualkan menunggu, mengurangkan ketersediaan, atau bertoleransi dengan ketidakseimbangan (skew) sementara?
4. Adakah label beban kerja, label topologi nod, dan kekangan lalai diuruskan oleh platform?
5. Adakah versi lama dan baharu menggunakan labelSelector yang sama semasa kemas kini bergolek?

Jawapan 30 saat

Saya akan mentakrifkan domain kegagalan dan kapasiti minimum terlebih dahulu, kemudian menetapkan matlamat penempatan berasingan untuk nod dan zon. Perkhidmatan kritikal menggunakan DoNotSchedule yang terikat; beban kerja biasa atau elastik menggunakan ScheduleAnyway sebagai matlamat lembut (soft). maxSkew mengehadkan perbezaan bagi satu pemilih merentasi domain yang layak, manakala minDomains menghalang pengiraan yang mengelirukan apabila domain tiada. Sebelum pelancaran, saya akan menguji label, penskalaan, kemas kini bergolek, dan kegagalan domain tunggal; dalam pengeluaran, saya akan memantau replika bagi setiap domain, masa Pending, kapasiti yang tersedia, dan belanjawan gangguan PDB.

Jawapan mendalam

Langkah 1: Tentukan domain dan kapasiti

Petakan nod, zon, dan rantau kepada nilai topologyKey yang berbeza. Jika perkhidmatan mesti bertahan daripada kehilangan satu zon, kekalkan replika yang mencukupi dalam sekurang-kurangnya dua zon; dengan hanya dua replika, anda tidak boleh menjanjikan penempatan yang sama rata merentasi tiga zon dan dua replika yang sihat selepas kehilangan satu daripadanya. Nyatakan invarian kapasiti sebelum memilih tahap ketat.

Langkah 2: Pilih maxSkew dan minDomains

maxSkew ialah perbezaan yang dibenarkan antara domain sasaran dan minimum global; dengan DoNotSchedule, melebihi nilai tersebut menyebabkan Pod kekal dalam keadaan Pending. minDomains menyatakan bilangan domain yang layak yang diperlukan dan menghalang set domain yang tidak mencukupi daripada dianggap sebagai pengagihan yang sah. Uji perkhidmatan replika kecil supaya kekangan tidak menghalang pelepasan.

Langkah 3: Asingkan kekangan keras dan lembut

Perkhidmatan satah kawalan (control-plane) atau pembayaran boleh menggunakan DoNotSchedule peringkat zon dan menukar kegagalan penempatan kepada amaran kapasiti. Kerja kelompok atau yang boleh ditangguhkan boleh menggunakan ScheduleAnyway, meminta penjadual mengurangkan ketidakseimbangan sambil membenarkan ketidakseimbangan sementara. Anti-afiniti keras sesuai untuk peraturan mudah "jangan letak bersama"; topologi pelbagai peringkat dan ketidakseimbangan yang boleh diukur biasanya lebih jelas dengan kekangan sebaran (spread constraints).

Langkah 4: Jadikan pemilih dan label boleh dipercayai

Kekangan labelSelector mesti sepadan dengan templat Pod sebenar, jika tidak Pod baharu mungkin dikira terhadap set yang salah. Nod memerlukan label zon, rantau, dan nama hos yang stabil; nod tanpa kunci topologi tidak mengambil bahagian dengan betul dalam pengiraan domain tersebut. Pemeriksaan kemasukan (admission checks) harus mengesahkan pemilih, label, dan nilai lalai sebelum pasukan menyalin manifes yang rosak.

Langkah 5: Selaraskan pelepasan, PDB, dan penskalaan

Kemas kini bergolek mesti mengambil kira replika lama, replika baharu, dan maxUnavailable bersama-sama. PDB mengehadkan gangguan sukarela; ia tidak menggantikan penempatan merentasi domain. Penskala automatik harus memahami Pod yang berstatus Pending dan kapasiti bagi setiap domain, jika tidak, kekangan yang ketat boleh menunggu selama-lamanya tanpa menambah nod yang boleh digunakan.

Langkah 6: Tentukan tindakan kegagalan dan degradasi

Lakukan latihan kehilangan nod, kehilangan zon, dan label nod yang hilang, kemudian perhatikan sama ada Pod baharu ditolak, tidak seimbang, atau Pending. Perkhidmatan kritikal boleh menjeda pelepasan berkeutamaan rendah, menambah kapasiti pada domain yang sihat, atau memasuki mod baca sahaja. Jangan alih keluar kekangan keras dalam persekitaran pengeluaran tanpa merekodkan risiko ketersediaan. Versikan dan buat rollback bagi tindakan degradasi.

Langkah 7: Sahkan dengan metrik pengagihan

Rekodkan replika, ketidakseimbangan (skew), tempoh Pending, sebab penjadualan, kapasiti yang tersedia, gangguan PDB, dan ralat permintaan mengikut beban kerja, versi, dan domain topologi. Ujian beban perlu merangkumi 2 hingga 30 replika, kapasiti domain yang tidak sekata, kemas kini bergolek, dan penskalaan automatik. Matlamatnya adalah untuk membuktikan bahawa kapasiti yang tinggal memenuhi SLO selepas kehilangan domain, bukan sekadar replika ditempatkan pada nod yang berbeza.

Jawapan model

Saya akan memodelkan nod, zon, dan rantau sebagai tiga lapisan domain kegagalan dan terlebih dahulu menetapkan replika minimum yang diperlukan selepas kehilangan satu zon. Pod perkhidmatan menggunakan pemilih yang sepadan dengan templat; kekangan digunakan secara berasingan pada nama hos dan zon. Perkhidmatan kritikal menggunakan zon maxSkew yang kecil dengan DoNotSchedule, manakala kerja kelompok menggunakan ScheduleAnyway. Jika domain yang layak jatuh di bawah minDomains, cetuskan amaran kapasiti dan bukannya menerima pengagihan yang mengelirukan secara senyap. Sahkan PDB, maxUnavailable, dan pemilih lama/baharu semasa kemas kini bergolek, serta pastikan penskala automatik memerhatikan sebab Pending dan kapasiti domain. Lancarkan dalam mod pemerhatian, kemudian dayakan kekangan keras secara beransur-ansur dengan replika setiap domain, masa Pending, latihan domain kegagalan, dan SLO perniagaan sebagai pintu kawalan (gates) rollback.

Kesilapan lazim

• Mengatakan "gunakan merentasi zon" tanpa menamakan topologyKey atau sasaran kapasiti.
• Menganggap maxSkew sebagai had replika mutlak bagi setiap domain.
• Mengabaikan ketidakpadanan pemilih dan seterusnya mengira set Pod yang salah.
• Menganggap PDB sebagai kekangan penjadual atau sebagai perlindungan daripada setiap kegagalan nod.
• Menjanjikan penempatan sama rata merentasi tiga zon dan tiada degradasi selepas kehilangan zon dengan hanya dua replika.
• Mengalih keluar DoNotSchedule untuk mengosongkan status Pending tanpa merekodkan kompromi ketersediaan.

Soalan susulan

Soalan susulan 1: Adakah ScheduleAnyway masih membantu ketersediaan?

Ya. Ia menjadikan ketidakseimbangan yang lebih rendah sebagai keutamaan penjadualan sambil membenarkan beban kerja berjalan apabila kapasiti terhad. Ia sesuai untuk kerja yang boleh ditangguhkan atau beban kerja dengan redundansi lain; perkhidmatan kritikal boleh meningkatkan skala terlebih dahulu dan menggunakan kekangan keras.

Soalan susulan 2: Mengapa tidak menggunakan pod anti-affinity sahaja?

Anti-afiniti menetapkan untuk tidak meletakkan Pod bersama Pod yang dipilih. Ia menyatakan pelbagai peringkat topologi, ketidakseimbangan berangka, dan keperluan domain minimum secara kurang langsung. Spread constraints menerangkan ketidakseimbangan merentasi domain, manakala anti-afiniti kekal berguna untuk satu peraturan pengecualian.

Soalan susulan 3: Apakah yang berlaku apabila minDomains salah?

Dengan domain yang layak terlalu sedikit, minimum global yang digunakan untuk skew boleh menyebabkan kekangan kelihatan dipenuhi atau mengekalkan Pod dalam status Pending. Sertakan ketersediaan domain dalam semakan kemasukan dan amaran kapasiti, serta sahkan tingkah laku medan untuk versi kluster tersebut.

Soalan susulan 4: Mengapakah pelepasan bergolek boleh merosakkan pengagihan?

Versi lama dan baharu mungkin menggunakan pemilih yang berbeza, atau maxUnavailable dan maxSurge mungkin menambah replika secara sementara dalam satu domain. Simulasikan keadaan perantaraan dan periksa ketidakseimbangan mengikut versi dan domain sebelum pelepasan.

Soalan susulan 5: Bagaimana jika nod tidak mempunyai label zon?

Ia tidak akan mengambil bahagian dengan betul dalam pengiraan topologi yang diminta. Baiki atau asingkan nod tersebut; jangan kira nod yang tidak berlabel sebagai domain kegagalan yang bebas.

Soalan susulan 6: Bagaimanakah anda membuktikan SLO bertahan daripada kegagalan zon?

Jalankan latihan pengasingan dan sahkan kapasiti yang boleh dijadualkan, replika yang sihat, ralat permintaan, dan masa pemulihan dalam domain yang tinggal. Rekodkan status PDB, sebab Pending, dan masa peningkatan skala untuk mengesahkan keseluruhan laluan daripada penjadualan kepada metrik perniagaan.