Назовите главные компоненты архитектуры Kubernetes

Master-ноды (master node, control plane) координируют все активности кластера: распределяют и резервируют ресурсы, управляют состоянием контейнеров, масштабируют, раскатывают обновления. Мастер-ноды состоят из следующих компонентов:

🔵kube-apiserver — это точка входа в панель управления master-ноды. Он отвечает за взаимодействие между master- и worker-нодами, отслеживает состояние worker-узлов и оповещает master о важных изменениях;
🔵kube-scheduler отвечает за распределение нагрузки на рабочие узлы, постоянно отслеживает, сколько ресурсов сейчас доступно и сколько из них задействовано под нагрузку на каждом узле. Он решает, на каком узле запускать новый Pod;
🔵Controller Manager отвечает за работу контроллеров: Deployment, ReplicaSet, StatefulSets, DaemonSet, Jobs, CronJob;
🔵ETCD хранит информацию о настройках и состоянии кластера, его метаданные. Представляет собой распределенную базу данных в формате ключ-значение.


Nodes (workers) — рабочие узлы в кластере. На них запускаются поды с контейнерами.

На каждой worker-ноде Kubernetes работают:

🔵kubelet — процесс, который запускает, удаляет, обновляет поды с контейнерами;
🔵kube-proxy — конфигурирует правила сети на рабочих узлах.

Схема архитектуры и основных компонентов Kubernetes на картинке ниже

#kb #собес

Kubernetes. Приложение перестало работать — как понять, что случилось?

Причин, по которым приложение не работает в кластере Kubernetes, много.

Вот самые распространенные:

🔵под отсутствует;
🔵под не запускается (статус Pending);
🔵под запускается, но падает с ошибкой (статус CrashLoopBackOff);
🔵под работает (статус Runnung), но недоступен по сети.

Ниже кратко рассмотрим алгоритмы, позволяющие понять, что же все-таки случилось.

🔵 Для начала нужно убедиться, что манифест выполнился и под действительно зарегистрирован в кластере. Если подов и деплоймента не находится, проверьте манифесты.

🔵Если поды находятся в статусе Pending, значит Scheduler не может найти подходящую ноду для запуска пода. На это тоже может быть много причин: недостаточно ресурсов в кластере, несовпадение taints/tolerances, невозможность скачать образ и многое другое. Найти причину помогут события, связанные с подом, однако некоторые проблемы (например, отказ Scheduler) не попадут в этот список. Также проверьте статус нод в кластере и селекторы, указанные в манифесте.

🔵Если под был назначен ноде, но при запуске произошла ошибка, под будет иметь статус CrashLoopBackOff и кластер будет предпринимать попытки запустить его повторно. Обычно это происходит в случае ошибки в самом приложении внутри контейнера, а найти причину обычно помогают логи (если приложение их пишет, конечно).

🔵Следующая ситуация — поды работают (статус Running), однако не доступны по сети из других подов. Для начала нужно проверить, создан ли Service с соответствующим селектором. Также необходимо проверить, что они находятся в одном namespace.