Kubernetes untuk Orang-Orang yang Harus Menjalankannya

Tutorial Kubernetes mengajarkan Anda deploy pod. Tidak ada yang mengajarkan apa yang harus dilakukan ketika node secara diam-diam keluar dari Ready state jam 3 pagi dan telepon on-call Anda tidak berhenti berdering. Ini tentang bagian kedua.

Resource requests dan limits bukan opsional

Jika Anda melewatkan resources.requests dan resources.limits pada container Anda, scheduler menebak-nebak, dan kubelet tidak tahu apa yang harus di-evict terlebih dahulu ketika node kekurangan memori. Atur requests ke apa yang benar-benar digunakan container di bawah beban normal, bukan apa yang Anda harapkan digunakannya. Atur memory limits dekat dengan requests karena pod yang OOM-killed restart dengan bersih, tetapi CPU limits umumnya harus lebih longgar atau tidak ada kecuali Anda melawan noisy neighbors, karena CPU throttling di bawah hard limit menyebabkan latency spikes yang sangat sulit di-debug. Jalankan kubectl top pods -n your-namespace secara teratur dan bandingkan dengan apa yang Anda deklarasikan. Ketidakcocokan menumpuk cepat di cluster dengan lebih dari beberapa service.

etcd adalah seluruh cluster, perlakukan itu seperti itu

Semua yang diketahui Kubernetes hidup di etcd. Kehilangannya dan Anda kehilangan cluster state Anda, bukan hanya metadata. Jalankan etcdctl snapshot save /backup/etcd-snapshot.db sesuai jadwal, dan benar-benar uji restore-nya di cluster scratch setidaknya sekali. Saya telah melihat tim dengan backup malam hari yang ternyata corrupt selama tiga bulan karena tidak ada yang memverifikasi mereka. Jika Anda di control plane terkelola (EKS, GKE, AKS), Anda tidak mengelola etcd secara langsung, tetapi Anda tetap harus tahu backup dan restore story provider Anda sebelum Anda membutuhkannya, bukan selama incident.

Liveness dan readiness probes perlu tidak setuju kadang-kadang

Kesalahan umum adalah menggunakan endpoint yang sama untuk kedua liveness dan readiness probes. Liveness harus menjawab