Kubernetes для людей, які мають його запускати

Туторіали Kubernetes вчать вас розгортати pod. Ніхто не вчить вас, що робити, коли вузол беззвучно виходить зі стану Ready о 3 ранку, а телефон дежурного не перестає дзвеніти. Це про другу частину.

Resource requests та limits не є необов'язковими

Якщо ви пропустите resources.requests та resources.limits на ваших контейнерах, scheduler робить припущення, а kubelet не має ідеї, що спочатку витіснити, коли вузлу не вистачає пам'яті. Встановіть requests на те, що контейнер насправді використовує під нормальним навантаженням, а не на те, що ви сподіваєтесь. Встановіть ліміти пам'яті близько до requests, оскільки pod, вбитий OOM, перезавантажуються чисто, але CPU limits має бути загалом більш м'яким або відсутнім, якщо ви не боретеся з шумними сусідами, бо CPU throttling під жорстким лімітом викликає викиди latency, які жахливо налагоджувати. Запускайте kubectl top pods -n your-namespace регулярно та порівнюйте з тим, що ви оголосили. Невідповідності швидко накопичуються в кластерах з більш ніж кількома сервісами.

etcd — це весь кластер, ставтеся до цього відповідно

Усе, що знає Kubernetes, живе в etcd. Втратите його — втратите стан вашого кластера, а не просто якісь метадані. Запускайте etcdctl snapshot save /backup/etcd-snapshot.db за розкладом та насправді тестуйте його відновлення на тестовому кластері щонайменше один раз. Я бачив команди з нічними резервними копіями, які виявилися пошкодженими три місяці, бо ніхто їх не перевірив. Якщо ви на керованій площині управління (EKS, GKE, AKS), ви не керуєте etcd безпосередньо, але вам все одно слід знати історію резервної копії та відновлення вашого провайдера перед тим, як вона вам знадобиться, а не під час інциденту.

Liveness та readiness probe іноді мають не погоджуватися

Поширена помилка — використання однієї endpoint для обох liveness та readiness probe. Liveness має відповідати