Проект управления Docker контейнерами. Решение довольно новое, но работает стабильно, есть уже много субпроектов, дополняющих K8S, и легко можно найти сообщения об успешном использовании в продакшен, (наши DevOps инженеры уже опробавали решение) так как в нем реализованы все функции, необходимые для запуска приложений на основе Docker в конфигурации с высокой доступностью, – деплой, обнаружение сервисов, планирование, мониторинг и многое другое.nnТак, за координацию и хранение настроек отвечает etcd, за создание сетей между контейнерами или нодами – Flannel, Weave Net, Calico, за мониторинг – cAdvisor. И многие другие. При этом, даже учитывая, что эти компоненты устанавливаются дополнительно, особых проблем (в последних релизах) с их интеграцией нет, все ставятся буквально одной командой, и можно собрать среду под конкретные задачи. Все обычно работает и без особого вмешательства и фактически скрыто от сисадмина (приходится специально разбираться, как оно все работает). После установки он размещает контейнеры, все остальное полностью на плечах K8S. Забегая наперед, скажу, что отсутствие внятной документации, явно не успевающей за проектом и часто вводящей в заблуждение, требует большего времени, чтобы во всем действительно разобраться. К тому же проект быстро развивается, и функции, недоступные в текущем релизе, уже реализованы и работают в master ветке Git.nnНо важно понимать, что Kubernetes хотя и использует Docker, но именно из-за своей нацеленности на работу в кластерах, когда контейнер будет запущен неизвестно на каком сервере, многие моменты здесь чуть отличаются. И если единичный контейнер запускается без дополнительных изменений и практически такой же командой, то группа контейнеров, обменивающихся данными между собой, работает чуть по-другому. Например, Docker запускается так, что контейнеры на одном хосте могут общаться между собой как по сети, так и брать файлы из volume на локальном диске. Если нужен доступ к контейнерам на другом хосте, придется уже как-то проксировать информацию. В K8S изначально исходят из того, что контейнеры могут находиться не только на разных хостах, но и в разных дата-центрах. А поэтому сетевая модель несколько изменена, чтобы упростить настройку сети, а возможность обмена данными через локальный volume присутствует, но лишь для тестовых целей для запуска на однокластерной системе.nnKubernetes представляет собой систему с несколькими специфическими концепциями, с которыми нужно познакомиться, прежде чем идти вперед. Единицей планирования (и масштабирования) ресурсов здесь является Pods. По сути, это один контейнер или группа контейнеров, работающих вместе. Контейнеры внутри Pods могут обмениваться данными через localhost, IPC, использовать общие разделы и т.п. Также все контейнеры из одного Pod всегда будут запускаться на одном сервере.nnОсновная идея сети в K8S состоит в том, чтобы контейнеры общались между собой напрямую без NAT, гарантировано получая сетевые ресурсы. Это реализовано в концепции IP-per-Pod, упрощающей обмен информацией и распределение сетевых ресурсов, не привязываясь к порту (как это было в Borg, сервисы использовали одно IP), в K8S каждому Pod назначается отдельный IP-адрес из серого диапазона. К этому адресу можно подключаться и работать, как в Docker, но при перезапуске Pod он мало того, что может стартовать на другом сервере, так и скорее всего получит совсем другой PodsIP, и закрепить его никак нельзя. Каждый объект получает свое уникальное имя (задается пользователем) и UID (генерируется автоматически). Для обмена информацией между объектами используется внутрикластерная служба DNS, поэтому вместо IP достаточно указать его имя и порт. Также по имени можно обращаться к некоторым ресурсам, в настоящее время доступно 19 типов ресурсов, все они описаны в документации.nnPod можно стартовать командой, как это делается в Docker, но обычно создается YAML-файл (ранее поддерживался и JSON), в котором прописываются все настройки. Чтобы обеспечить работу приложения, используется следующая абстракция – сервис (Services), определяющий набор Pods и политику их применения. Метки (Labels) – пары ключ/значение, которые прикрепляются к Pod и любому объекту, позволяя легко группировать, отбирать, назначать задания и привязывать к сервисам при помощи селектора (selector). Также к сервисам можно назначить и внешнюю службу. Для проксирования информации внутри кластера сервисы получают clusterIP, доступный только внутри кластера.nnКластер логически делится на несколько виртуальных при помощи Namespaces. Каждая Namespaces существует в изолированном пространстве, ограниченном квотами, не влияя на других. По умолчанию в кластере создается Namespaces – default, в которую будут помещаться поды и служебная kube-system.nnКластер содержит мастер сервер и minion. Уже реализованы работа нескольких мастеров в кластере и мультикластерная установка (Cluster Federation или Ubernetes), позволяющая несколькими кластерами из одной точки. Правда, в отличие от Docker swarm mode настройка не так проста и ужасно плохо описана в документации. На мастере по умолчанию запускаются следующие службы:n
- kubelet (основная программа),
- kube-apiserver,
- kube-controller-manager (менеджер сервисов),
- kube-discovery,
- kube-dns,
- kube-proxy (прокси балансировщик),
- kube-scheduler (планировщик),
- etcd,
- сетевая служба weave-net/flannel.
На minion устанавливаются агенты kubelet, kube-proxy и сетевая служба. Прокси обеспечивает перенаправление потоков между Pod. Также на всех узлах запускается служба мониторинга cAdvisor (при стандартной установке, порт 4194).nnДоступ к API управления, кроме программного способа, можно получить при помощи консольной утилиты kubectl и веб-интерфейса. Они помогут просматривать текущую конфигурацию, управлять ресурсами, создавать и разворачивать контейнеры.n
Нужна помощь в поддержке и управлении конейнерами, обращайтесь [email protected]