Kubernetes: внутреннее устройство и архитектура
Я думаю, все или почти все, кто сталкивался с миром DevOps, хотя бы в общих чертах знают, что такое Kubernetes. Но для менее искушенных и подкованных читателей будет полезно почитать пару абзацев о том, что же такое система контейнерной оркестрации, и чем так хорош наш Kubernetes.
Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а также обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат в 2014 году в недрах самой великой и ужасной Google и теперь поддерживается многими компаниями, среди которых и Microsoft, и RedHat, и IBM. Код Kubernetes написан на языке Go и распространяется под лицензией Apache 2.0. Продукт позиционируется как развиваемое сообществом универсальное решение, не привязанное к отдельным решениям и способное работать с любыми приложениями в любых облачных окружениях.
И сегодня K8s де-факто стал неким стандартом для современных DevOps-сред – что in-house недр больших компаний, что в популярных среди стартапов облачных сервисах типо AWS, Microsoft Azure или Google Cloud.
Базовая концепции внутреннего устройства Kubernetes
Nodes (node.md) – нода – это машина в кластере Kubernetes.
Pods (pods.md) – это группа контейнеров с общими разделами, запускаемые как единое целое.
Replication Controllers (replication-controller.md) – сервис, гарантирующий, что определённое количество «реплик» pod'ы будут запущены в любой момент времени.
Services (services.md) – ещё один сервис в Kubernetes – это абстракция, которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md) – директория или раздел, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md) – пары ключ/значение, которые прикрепляются к объектам, например, pod'ам. Label'ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md) – интерфейс командной строки для управления Kubernetes.
Несколько слов об архитектуре Kubernetes
Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet), и компоненты мастера (APIs, scheduler, etc) поверх решения с распределённым хранилищем.
Архитектура: 1. Нода Kubernetes – при взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде, и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. И, конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров. 2. Kubelet – Kubelet управляет pod'ами их контейнерами, образами, разделами. 3. Kube-Proxy – на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов. 4. Компоненты управления Kubernetes – система управления Kubernetes разделена на несколько компонентов. 4.1 Сервер хранения ключевой информации etcd – состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния. 4.2 Kubernetes API Server – обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD-сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST-операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах). 4.3 Scheduler – привязывает незапущенные pod'ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler'ов и пользовательских scheduler'ов. 5. Kubernetes Controller Manager Server – все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.
