Концепции Kubernetes: основные концепции и терминология

Эта статья участвовала в приказе о созыве Haowen, нажмите, чтобы просмотреть:Двойные заявки на внутреннюю и внешнюю стороны, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!

Прежде чем начать использовать, вы должны сначала понять оKubernetesсвязанные понятия и термины, которые будут очень полезны для последующего изучения и использования. (KubernetesЕсть много понятий, рекомендуется укреплять понимание и четко понимать расположение и взаимосвязь различных! )

KubernetesБольшинство понятий в , таких как:Node,Pod,Replication Controller,Serviceможно рассматривать какресурсный объект, почти все объекты ресурсов могут быть доступны черезKubernetesкоторый предоставилkubectlИнструмент (или интерфейс API) выполняет такие операции, как добавление, удаление, изменение и поиск, и сохраняет их вetcdсреднее постоянное хранилище.

с этого ракурса,KubernetesПо сути, это высокоавтоматизированная система управления ресурсами, которая отслеживает и сравниваетetcdРазница между «ожидаемым состоянием ресурса», сохраненным в библиотеке, и «фактическим состоянием ресурса» в текущей среде используется для реализации расширенных функций автоматического управления и автоматического исправления ошибок.

Эта статья познакомитKubernetesВажные объекты ресурсов в , а именно:Kubernetesосновные понятия и терминология.

1. Мастер

MasterОтносится кKubernetesУправляющий узел (Master Node) в кластере, в каждомKubernetesВ кластере должен быть одинMasterОн отвечает за управление и контроль всего кластера, в основном на него отправляются все управляющие команды, он отвечает за конкретный процесс выполнения, а все последующие команды в основном выполняются вMasterзапускать на.

MasterПредоставляет уникальное представление о кластере и имеет набор компонентов, таких какKubernetes API Server.API ServerПредоставляет конечные точки REST, которые можно использовать для взаимодействия с кластером. Поды, реплики и сервисы можно поддерживать через командную строку или через графический интерфейс.

Включите в Мастер следующие компоненты:

и т. д.:Распределенное хранилище ключей и значений сохраняет данные состояния и данные объекта ресурсов кластера.
API Server(kube-api-server):Интерфейс HTTP Rest, предоставляемый Kubernetes, является единственным входом для таких операций, как добавление, удаление, изменение и проверка всех ресурсов, а также процессом входа для управления кластером.
Controllers(kube-controller-manager):Автоматизированный центр управления всеми объектами ресурсов в Kubernetes.
Scheduler(kube-scheduler):Процесс, отвечающий за планирование ресурсов (планирование Pod), эквивалентен «кабинету планирования» автобусной компании.

2. Узел

Помимо Мастера, другие кластеры в кластере Kubernetes называютсяNode, а именно: Worker Node (рабочий узел). Как и Master, Node может быть физическим хостом или виртуальной машиной.

NodeЭто узел рабочей нагрузки в кластере Kubernetes. Каждому узлу будет назначена некоторая рабочая нагрузка Мастером. Когда узел выйдет из строя, рабочая нагрузка на нем будет автоматически передана Мастером другим узлам.

Следующие ключевые компоненты работают на каждом узле:

kubelet:Он отвечает за такие задачи, как создание контейнера, запуск и остановка соответствующего пода, и тесно сотрудничает с Мастером для реализации основных функций управления кластером.
kube-proxy:Важный компонент, реализующий механизм связи и балансировки нагрузки службы Kubernetes.
Время выполнения контейнера:Скачайте образ и запустите контейнер. Например, механизм Docker отвечает за создание собственных контейнеров и управление ими.

NodeЕго можно динамически добавлять и настраивать в кластере Kubernetes во время работы.По умолчанию кубелет регистрируется на Мастере. Как только узел включен в область управления кластером, процесс kubelet будет периодически сообщать Мастеру свою собственную информацию, такую как операционная система, версия Docker, ЦП и память компьютера, а также какие поды в настоящее время работают, чтобы Мастер мог узнать статус использования ресурсов каждого узла и внедрить эффективную и сбалансированную стратегию планирования ресурсов. Когда узел не может сообщить информацию по истечении указанного времени, он будет оценен Мастером как «отключенный» и помечен как недоступный (Не готов), а затем Мастер инициирует автоматический процесс «переноса большой рабочей нагрузки».

Выполнение заказаkubectl get nodesВы можете увидеть, сколько узлов в кластере:

[xcbeyond@localhost ~]$ kubectl get nodes
NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   17d   v1.19.0

затем пройтиkubectl describe node <node_name>Просмотр сведений об узле:

[xcbeyond@localhost ~]$ kubectl describe node minikube
Name:               minikube
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    ……

3. Стручок

PodЯвляется атомарным объектом в Kubernetes, базовой структурной единицей.

PodПредставляет набор запущенных контейнеров в кластере. Поды обычно создаются для запуска одного главного контейнера. Поды также могут запускать дополнительные контейнеры sidecar для реализации дополнительных функций, таких как ведение журнала. (Например: в Service Mesh он существует вместе с приложениемistio-proxy,istio-initконтейнер)

Развертывания обычно используются для управления подами.

ОдинPodОн может содержать несколько контейнеров (другие контейнеры служат функциональными дополнениями), отвечающих за обработку томов данных, ключей и настройку контейнеров.

Как показано на рисунке ниже,PodНа диаграмме состава мы видим, что каждыйPodОба имеют специальный контейнер Pause, называемый «корневым контейнером». Образ, соответствующий контейнеру Pause, является частью платформы Kubernetes.В дополнение к контейнеру Pause каждый Pod также содержит один или несколько тесно связанных пользовательских бизнес-контейнеров.

Почему Kubernetes разрабатывает новую концепцию Pod и почему у Pod такая особенная структура?

В случае группы контейнеров как единого целого нам сложно просто судить и эффективно контролировать «целое». Например, если умирает контейнер, считается ли это полной смертью? Контейнер Pause, который не имеет отношения к бизнесу и не так просто умереть, вводится как корневой контейнер Pod, а его состояние представляет собой состояние всей группы контейнеров, что просто и гениально решает эту проблему.
Несколько бизнес-контейнеров в поде совместно используют IP-адрес контейнера Pause и тома, прикрепленного к контейнеру Pause, что не только упрощает связь между тесно связанными бизнес-контейнерами, но и решает проблему обмена файлами между ними.

Kubernetes присваивает каждому поду уникальный IP-адрес, который называется Pod IP. Несколько контейнеров в поде используют общий IP-адрес пода.

Kubernetes требует, чтобы базовая сеть поддерживала прямую связь TCP/IP между любыми двумя модулями в кластере, которая обычно реализуется с использованием виртуальных сетевых технологий уровня 2, таких как Flannel, Open vSwitch и т. д., поэтому нам нужно помнить:В Kubernetes контейнеры в поде могут напрямую взаимодействовать с контейнерами пода на другом хосте.

Существует два типа подов:

нормальный стручок
Статическая капсула

Последний особенный, он не хранится в хранилище etcd Kubernetes, а хранится в файле на определенном узле, и только запускается и работает на этом узле. Как только обычный под будет создан, он будет сохранен в etcd, а затем назначен мастером Kubernetes на конкретный узел и привязан (привязка), а затем под будет сохранен процессом kubelet на соответствующем узле. связанных контейнеров Docker и запустите их.

По умолчанию, когда контейнер в поде останавливается, Kubernetes автоматически обнаруживает проблему и перезапускает под (перезапускает все контейнеры в поде). перенаправляются на другие узлы. Отношения между подом, контейнером и узлом показаны на следующем рисунке.

Жизненный цикл модуля не определен и может быть очень коротким, но модуль обладает сильной способностью к регенерации и может быть автоматически перезапущен после смерти (механизм перезапуска). В течение всего процесса жизненного цикла Pod обычно может находиться на одной из следующих пяти стадий:

Pending:Pod определен правильно и отправлен мастеру, но образ контейнера, который он содержит, не был полностью создан. Обычно мастеру требуется некоторое время, чтобы запланировать под, некоторое время узлу, чтобы загрузить образ контейнера, и некоторое время, чтобы запустить контейнер.
Running:Pod был назначен узлу, все контейнеры созданы, хотя бы один контейнер запущен или контейнер запускается или перезапускается.
Succeeded:Все контейнеры в поде работают успешно и не будут перезапущены. Это конечное состояние Pod.
Failed:Все контейнеры в поде завершились, и по крайней мере один из них завершился аварийно (код выхода не равен 0). Это также конечное состояние Pod.
Unknown:Статус пода не может быть получен, как правило, из-за невозможности связи с узлом, на котором находится под.

4. Этикетка

Label(Ярлык) — еще одна ключевая концепция в Kubernetes. Метка — это пара ключ=значение, где ключ и значение задаются пользователем. Метки могут быть прикреплены к различным объектам ресурсов, таким как Node, Pod, Service, RC и т. д. Объект ресурса может определять любое количество меток, и одна и та же метка также может быть добавлена к любому количеству объектов ресурсов. Метки обычно определяются при определении объекта ресурса, а также могут динамически добавляться или удаляться после создания объекта.

Вообще говоря, мы определяем несколько меток для указанных объектов ресурсов, чтобы реализовать многомерное управление группировкой ресурсов, чтобы гибко и удобно управлять распределением ресурсов, планированием, конфигурацией, развертыванием и другими задачами управления. Например: развертывание разных версий приложений в разных средах или мониторинг и анализ приложений (регистрация, мониторинг, оповещение и т. д.). Вот некоторые часто используемые примеры меток:

Метка версии:release：stable,release: canary
Экологические этикетки:environment: dev,environemnt: qa,environment: production
Теги архитектуры:tier: frontend,tier: backend,tier: middleware
...

После того, как объект ресурса определяет метку, селектор меток можно использовать для запроса и фильтрации объектов ресурсов метки.Таким образом, Kubernetes реализует механизм запросов объектов, подобный SQL.

Обычно мы передаем файл описанияspec.selectorполе для указания метки, чтобы Kubernetes находил все объекты, содержащие указанную вами метку, и управлял ими.

В настоящее время Kubernetes поддерживает два типа селекторов меток:

Селектор на основе равенства: выражения на основе равенства соответствуют тегам.
Селектор на основе набора (на основе набора): набор выражений класса операции соответствует тегам.

использоватьLabelВы можете создать один или несколько наборов тегов для объекта,LabelиLabel SelectorВместе они составляют основную модель приложения в системе Kubernetes, позволяя точно группировать объекты и управлять ими, обеспечивая при этом высокую доступность кластера.

5. Контроллер репликации

Replication Controller, называемый RC, является одним из основных понятий в Kubernetes, который определяет ожидаемый сценарий, то есть: объявляет, что количество реплик определенного Pod соответствует определенному ожидаемому значению в любое время.

Определение RC включает следующие части:

Ожидаемое количество реплик для Pod.
Селектор ярлыков для фильтрации целевых модулей.
Шаблон пода, используемый для создания нового пода, когда количество реплик пода меньше ожидаемого числа.

Ниже в качестве примера используется кластер с 3 узлами, чтобы проиллюстрировать, как Kubernetes реализует механизм автоматического управления количеством реплик Pod через RC.

Если поду redis-slave, определенному в нашем RC, необходимо поддерживать 2 копии, система может создать поды в двух узлах, как показано на следующем рисунке:

Если Pod на узле 2 неожиданно завершится, в соответствии с количеством реплик 2, определенным RC, Kubernetes автоматически создаст и запустит новый Pod, чтобы гарантировать, что во всем кластере всегда будут работать два redis-slave. Как показано на рисунке ниже, Kubernetes может выбрать узел 3 или узел 1 для создания нового пода.

Кроме того, во время выполнения мы можем добиться динамического масштабирования (Scaling) Pod путем изменения количества копий RC, чего можно добиться, выполнивkubectl scale rc redis-slave --replicas=3Завершение команд одним щелчком мыши. Результат выполнения показан на следующем рисунке:

Примечание. Удаление RC не повлияет на модули, созданные с помощью этого RC.Чтобы удалить все поды, вы можете установить значение реплик на 0, а затем обновить RC. Кроме того, kubectl также предоставляет команды остановки и удаления для одновременного удаления всех подов, контролируемых RC и RC.

Наконец, резюмируем характеристики и функции RC:

В большинстве случаев процесс создания пода и автоматический контроль количества копий реализуется путем настройки RC.
Полный шаблон определения модуля включен в RC.
RC реализует автоматическое управление репликами pod через механизм селектора меток.
Изменяя количество реплик Pod в RC,Расширяйте и уменьшайте возможности.
Изменив версию образа в шаблоне пода в RC,Функция непрерывного обновления.

6. Развертывание

DeploymentЭто новая концепция, представленная Kubernetes в версии 1.2 для лучшего решения проблемы оркестровки модулей. с этой целью,DeploymentВнутренне набор реплик используется для реализации, независимо от роли развертывания, определения YAML или конкретной операции командной строки, мы можем рассматривать его как обновление RC.

DeploymentОдним из самых больших улучшений по сравнению с RC является то, что мы всегда можем знать о ходе текущего развертывания Pod.

Типичные сценарии использования:

Создайте объект Deployment, чтобы сгенерировать соответствующий набор реплик и завершить создание реплики Pod.
Проверьте состояние развертывания, чтобы убедиться, что действие развертывания завершено (достигло ли количество реплик Pod ожидаемого значения).
Обновите развертывание, чтобы создать новый модуль.
Если текущее развертывание нестабильно, выполните откат к предыдущей версии развертывания.
Приостановите развертывание, чтобы одновременно изменить элементы конфигурации нескольких PodTemplateSpec, а затем возобновите развертывание для нового выпуска.
Масштабируйте развертывание для обработки высоких нагрузок.
Проверьте статус развертывания как индикатор успеха выпуска.

7. StatefulSet

В Kubernetes объекты управления Pod RC, Deployment, DaemonSet и Job являются службами без сохранения состояния. Но на самом деле многие сервисы имеют состояние, особенно некоторые сложные кластеры промежуточного программного обеспечения, такие как кластер MySQL, кластер MongoDB, кластер Kafka, кластер Zookeeper и т. д. Эти кластеры приложений имеют следующие общие черты.

Каждый узел имеет фиксированный идентификатор удостоверения, с помощью которого члены кластера могут обнаруживать друг друга и взаимодействовать друг с другом.
Размер кластера относительно фиксирован, и размер кластера не может быть изменен по желанию.
Каждый узел в кластере имеет состояние и обычно сохраняет данные в постоянном хранилище.
Если диск поврежден, узел в кластере не может функционировать должным образом, и функция кластера нарушается.

Если мы используем RC или Deployment для управления количеством реплик Pod для реализации вышеуказанного кластера с отслеживанием состояния, мы обнаружим, что первый пункт не может быть выполнен, потому что имя Pod генерируется случайным образом, а также IP-адрес Pod. определяется во время выполнения.И могут быть изменения.Мы не можем определить уникальный и постоянный ID для каждого Pod заранее.Чтобы восстановить отказавший узел на других узлах,Pod в этом кластере нужно привязать к какому-то общему Чтобы решить эту проблему, Kubernetes представил новый ресурсный объект под названием PetSet, начиная с версии 1.4, и был переименован в версии 1.5.StatefulSet,StatefulSetПо сути, его можно рассматривать как особый вариант Deployment/RC, который имеет следующие характеристики.

Каждый под в StatefulSet имеет стабильный и уникальный сетевой идентификатор, который можно использовать для обнаружения других членов в кластере. Предположим, что имя StatefulSet — kafka, тогда первый Pod называется kafak-0, второй Pod — kafak-1 и так далее.
Последовательность запуска и остановки реплики пода, управляемая StatefulSet, контролируется.Когда работает n-й под, первые n-1 подов уже работают и готовы.
Поды в StatefulSet используют стабильные постоянные тома хранения, которые реализованы через PV/PVC.По умолчанию тома хранения, связанные с StatefulSet, не удаляются при удалении пода (для обеспечения безопасности данных).

StatefulSetПомимо того, что он связан с томами PV для хранения данных о состоянии подов, его также следует использовать вместе с Headless Service, то есть в каждомStatefulSetОпределение для объявления того, к какому безголовому сервису он принадлежит. Ключевое отличие между безголовой службой и обычной службой заключается в том, что у нее нет IP-адреса кластера.Если DNS-имя домена безголовой службы разрешается, возвращается список конечных точек всех подов, соответствующих службе. StatefulSet создает DNS-доменное имя для каждого экземпляра Pod, контролируемого StatefulSet, на основе Headless Service.Формат этого доменного имени:

$(podname).$(headless service name)

Например, в 3-узловом кластере Kafka StatefulSet имя соответствующей безголовой службы — kafka, а имя StatefulSet — kafka, тогда DNS-имена трех подов в StatefulSet — kafka-0.kafka, kafka -1.kafka, kafka -3.kafka, эти имена DNS можно зафиксировать прямо в конфигурационном файле кластера.

8. Сервис

ServiceЭто также один из основных объектов ресурсов в Kubernetes. Каждая служба в Kubernetes на самом деле является «микрослужбой» в архитектуре микрослужб, которую мы часто упоминаем. способ. На следующем рисунке показана логическая связь между Pod, RC и Service.

Pod、RC与Service的逻辑关系

Из рисунка видно, что сервис Kubernetes определяет адрес входа для доступа к сервису.Фронтенд-приложение (Pod) получает доступ к группе экземпляров кластера позади него, состоящей из реплик Pod, через этот адрес входа, а сервис и его back- end Кластер реплик Pod «Бесшовная стыковка» достигается с помощью селектора меток. Роль RC на самом деле заключается в обеспечении того, чтобы возможности обслуживания и качество обслуживания Службы всегда соответствовали ожидаемому стандарту.

9. Работа

Job(Пакетная задача) Чтобы обработать пакетную работу, запустив несколько процессов параллельно или последовательно, после завершения обработки вся пакетная задача завершается. Начиная с версии Kubernetes 1.2, приложения, поддерживающие пакетную обработку, могут определять и запускать задание пакетной задачи с помощью нового объекта ресурса, называемого заданием Kubernetes. Подобно RC, Deployment и ReplicaSet, Job также используется для управления набором контейнеров Pod.

JobОтвечает за пакетирование кратковременных разовых задач, то есть задач, которые выполняются только один раз, и гарантирует успешное завершение одного или нескольких подов пакетной задачи.

10. Объем

VolumeA (том хранения) — это общий каталог в поде, к которому могут обращаться несколько контейнеров. Концепция Volume Kubernetes, использование и цель аналогичны Volume Docker, но они не эквивалентны. Во-первых, том в Kubernetes определяется в поде, а затем монтируется в определенный файловый каталог несколькими контейнерами в поде; во-вторых, данные в томе в Kubernetes не будут потеряны. Наконец, Kubernetes поддерживает несколько типов томов, таких как Gluster, Ceph и другие передовые распределенные файловые системы.

11. Пространство имен

Namespace(Пространство имен) — еще одна очень важная концепция в системе Kubernetes. Во многих случаях пространство имен используется для достижения мультитенантной изоляции ресурсов. Пространство имен «распределяет» объекты ресурсов в кластере по разным пространствам имен для формирования логически сгруппированных различных проектов, групп или групп пользователей, чтобы можно было управлять разными группами по отдельности при совместном использовании ресурсов всего кластера.

Кластер Kubernetes по умолчанию создаст пространство имен с именем default.kubectlМожет просматривать:

[xcbeyond@bogon ~]$ kubectl get namespaces
NAME                   STATUS   AGE
default                Active   23d
istio-system           Active   22d
kube-node-lease        Active   23d
kube-public            Active   23d
kube-system            Active   23d
kubernetes-dashboard   Active   23d

Если пространство имен не указано, Pod, RC, Service и т. д., созданные пользователем, будут созданы в пространстве имен по умолчанию.

12. Аннотация

Annotation(Примечание) Подобно метке, он также определяется в виде пар ключ/значение. Разница в том, что Label имеет строгие правила именования, он определяет метаданные объектов Kubernetes (Metadata) и используется для Label Selector. иAnnotationЭто «дополнительная» информация, произвольно определяемая пользователем для облегчения поиска внешними инструментами.Во многих случаях модуль Kubernetes сам помечает специальную информацию объекта ресурса с помощью аннотации.

Обычно сAnnotationИнформация, которая должна быть записана, следующая:

Информация о сборке, информация о выпуске, информация об образе Docker и т. д., например метка времени, идентификационный номер выпуска, номер PR, хэш-значение образа, адрес реестра Docker и т. д.
Информация об адресах библиотек ресурсов, таких как библиотека журналов, библиотека мониторинга и библиотека анализа.
Информация об инструменте отладки программы, такая как инструмент, номер версии и т. д.
Контактная информация, такая как команда, такая как номер телефона, имя ответственного лица, URL-адрес и т. д.

13. Карта конфигурации

Для того, чтобы иметь возможность точно и глубоко понятьKubernetes ConfigMapФункция и ценность Docker могут начинаться с Docker. Все мы знаем, что Docker решает проблему различий в развертывании приложений путем «упаковки и лечения» программ, зависимых библиотек, данных и файлов конфигурации в неизменяемый файл образа, но это также порождает еще одну сложную проблему, а именно: как параметры в файл конфигурации изменяется во время работы. Для решения этой проблемы Docker предоставляет следующие два способа:

Параметры передаются через переменные среды.
Файлы конфигурации вне контейнера сопоставляются с контейнером через Docker Volume.

В большинстве случаев мы предпочитаем последний метод.Большинство приложений обычно имеют несколько параметров, а метод отображения файла конфигурации является кратким. Но у этого метода есть и явные недостатки: на хосте нужно заранее создать конфигурационный файл, а затем контейнер может быть сопоставлен с контейнером при его запуске.

В распределенной системе становится еще хуже, создавая одни и те же файлы конфигурации на нескольких хостах, и трудно добиться согласованности этих файлов конфигурации. С этой целью Kubernetes представилConfigMap, который аккуратно решает эту проблему.

Рассматривайте все элементы конфигурации как строки ключ-значение, такие как: элементы конфигурации host=192.168.1.1, user=root, password=123456 используются для указания параметров конфигурации для подключения к FTP-серверу. Эти элементы конфигурации являются одним элементом в таблице карты. Данные всей карты постоянно хранятся в etcd Kubernetes, а API предоставляется для облегчения связанных с Kubernetes компонентов или операций CRUD приложений. Карта, используемая для сохранения параметров конфигурации, — это Объект ресурса Kubernetes ConfigMap.

Механизм ConfigMap:ConfigMap, хранящийся в etcd, изменяется в файле конфигурации в целевом модуле с помощью сопоставления тома.Независимо от того, на какой сервер запланирован целевой модуль, сопоставление будет выполнено из Odong. Если данные «ключ-значение» в ConfigMap изменены, «файл конфигурации», сопоставленный с модулем, также будет автоматически обновлен. В результате ConfigMap образует самый простой и ненавязчивый центр настройки в распределенных системах.

14. Резюме

Приведенные выше концептуальные термины также являются основными компонентами Kubernetes, которые вместе составляют структуру и вычислительную модель Kubernetes. Гибко комбинируя их, пользователи могут быстро и легко настраивать, создавать кластеры контейнеров и управлять ими. В дополнение к концепциям, представленным в этой статье, в Kubernetes есть много других концепций, которые используются для помощи в настройке объектов ресурсов, таких как: LimitRange, ResourceQuota и т. д. Дополнительные концептуальные термины см. в официальном глоссарии:Это особенное. IO/this/docs/hot air…

В следующий раз, за гранью возможностей /блог/ дети в трудном положении...