Kubernetes для тех, кому его запускать

Туториалы по Kubernetes учат разворачивать pod. Никто не учит, что делать, когда узел незаметно выпадает из состояния Ready в 3 ночи, а телефон дежурного не перестаёт звонить. Это про вторую часть.

Resource requests и limits — не опция

Если пропустить resources.requests и resources.limits в контейнерах, планировщик гадает, а kubelet не знает, что вытеснить в первую очередь, когда на узле кончается память. Установите requests на то, что контейнер реально потребляет при нормальной нагрузке, а не на то, что вы надеетесь. Установите лимит памяти близко к requests, так как OOM-killed поды перезагружаются чисто, но лимиты CPU обычно должны быть мягче или отсутствовать вовсе, если вы не боретесь с шумными соседями, потому что CPU throttling под жёстким лимитом вызывает всплески латентности, которые мучительно отлаживать. Регулярно запускайте kubectl top pods -n your-namespace и сравнивайте с объявленным. Расхождения накапливаются быстро в кластерах больше, чем с handful сервисов.

etcd — это весь кластер, относитесь к нему соответственно

Всё, что знает Kubernetes, живёт в etcd. Потеряете его — потеряете состояние кластера, не просто какие-то метаданные. Запускайте etcdctl snapshot save /backup/etcd-snapshot.db по расписанию и реально тестируйте восстановление на временном кластере хотя бы раз. Я видел команды, у которых были ежедневные резервные копии, но они оказались повреждены три месяца, потому что никто их не проверял. Если вы на managed control plane (EKS, GKE, AKS), etcd вы не управляете напрямую, но всё равно должны знать историю резервной копии и восстановления вашего провайдера до инцидента, а не во время.

Liveness и readiness проbes должны иногда отличаться

Частая ошибка — использовать один и тот же endpoint для обоих probes: liveness и readiness. Liveness должен отвечать