(Читать с толикой сарказма…) Все, кто работал с Ansible, знают, что он не хранит состояние результата своей работы. Это нелепое поведение Ansible, нельзя взять и просто удалить из git объекты конфигурации, чтобы они исчезли с управляемых систем, фу. При этом сразу вспоминается его величество Terraform с tfstate. Всех, кого раздражает подобное положение дел, прошу под кат.

В конце прошлого года нам поступила задача по реализации отказоустойчивого хранилища для разрабатываемого сервиса.

Ранее для этих целей предложили бы готовое решение в виде СХД с поддержкой сетевых протоколов вроде Hitachi NAS Platform (HNAS). Но текущая ситуация и особенности контракта обязывали проработать решение на мощностях заказчика.

В итоге выбрали и реализовали решение с использованием ОС на ядре Linux и кластере PaceMaker — с общим диском, поддержкой кворума, демона SDB и протокола NFS. Кому интересны особенности реализации, прошу под кат.

Несколько месяцев назад коллеги, работающие с одним из кластеров Kubernetes в dev-окружении, обратились с проблемой недоступности API-сервера Kubernetes. Dev-среды обычно не подключены к дежурной смене, и решением проблем занимаются владельцы или, если проблемы нестандартные, обращаются к профильным специалистам. В ходе диагностики оказалось, что kube-api стал потреблять значительно больше памяти. Это приводило к возникновению ошибки с OOM.

Давайте будем честными — если бы это произошло в production-окружении, мы, скорее всего, закинули бы больше памяти и успешно бы забыли про проблему. Но dev-стенд не имеет жёстких SLA с финансовой ответственностью, и это дало нам возможность и время разобраться с прожорливым kube-api.

Всех, кому интересно, что из этого вышло, прошу под капот.