Продолжение. Предыдущая глава Kubernetes (3)

Варианты развёртывания Kubernetes

Kubernetes может работать как в собственной ИТ-системе предприятия, так и в облаке. Можно также использовать мини-версию, которая называется minikube, на отдельном компьютере.

При первоначальном развёртывании в ИТ-системе потребуется создать кластер из нескольких серверов, чтобы использовать функцию kubeadm, при помощи которой можно создать кластеры с минимумом жизнеспособных сервисов, которые могут пройти тест соответствия (Kubernetes confor­mance tests).

Облачные провайдеры предоставляют сервисы, которые ещё больше облегчают развёртывание Kubernetes. Например, Google Cloud предоставляет Google Kubernetes Engine (GKE), Amazon Web Services (AWS) предоставляет Amazon EKS с профессиональным обслуживанием, Microsoft Azure предлагает Azure Kubernetes Service (AKS).

Работа Kubernetes в разнородных средах становится обычной практикой. Часть нагрузки деплоймента может работать в небольших средах ИТ-системы предприятия, затем их можно оттестировать в небольшом облачном кластере Kubernetes, в среде местного облачного провайдера, а затем деплоймент может быть развёрнут в мульти-региональном кластере в большом облаке.   

Более подробно с такой концепцией можно ознакомиться здесь: https://kubernetes.io/docs/concepts/workloads/).

Использование Minikube для создания кластера

Кластеры Kubernetes

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

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

Kubernetes автоматизируют распространение и планирование в кластере контейнеров с приложениями наиболее эффективным образом.

Kubernetes – это платформа с открытым кодом (open-source platform) и она готова к непосредственному развёртывание в продуктивной ИТ-среде.  

• Плоскость управления (Control Plane) координирует работу кластера;
• Узлы (Nodes) – это рабочие места для приложений.

Рис. 1. Схема кластера Kubernetes

Плоскость управления (Control Plane) управляет кластером.  Control Plane координирует всю активность в кластере, например, планирование приложений, поддержание их в желаемом состоянии, масштабирование приложений и «накат» новых апдейтов.

Нода (node) – это виртуальная машина (VM) на физическом компьютере, которая служить как рабочая машина в кластере Kubernetes. Каждая нода имеет Kubelet, который является агентом для управления нодой и связи с плоскостью управления Kubernetes. В ноде должны быть средства для обработки операций с контейнерами, такие как containerd или Docker. Кластер Kubernetes, который обрабатывает трафик рабочей нагрузки, должен иметь минимум три ноды, т.к. если одна нода отказывает, то теряются член etcd (etcd member) и экземпляр агента control plane (control plane instance), и резервирование данных оказывается под угрозой. Это риск можно уменьшить, увеличив количество нод control plane.

Control Plane управляет кластером и нодами, в которых работают приложения.  

При развёртывании приложений в Kubernetes, control plane по команде пользователя запускает контейнеризованные приложения и распределяет контейнеры по нодам кластера. Ноды общаются с control plane через Kubernetes API. Конечные пользователи также могут использовать Kubernetes API для работы с кластером.

Кластер Kubernetes может развёртываться как на физических, так и на виртуальных машинах. Для начала можно попробовать развернуть Kubernetes при помощи Minikube.

Minikube – это небольшая реализация Kubernetes, которая создаёт виртуальные машины на локальной машине, и развёртывает простые кластеры из одной ноды. Minikube имеет версии для ОС Linux, macOS и Windows. Интерфейс командной строки Minikube CLI даёт возможность выполнять простые команды в кластере включая start, stop, status, and delete.

По ссылке https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/ можно запустить интерактивный учебник по Minikube.

Управление объектами Kubernetes

Средство командной строки kubectl может создавать объекты Kubernetes несколькими способами. По ссылке можно посмотреть небольшой учебник Kubectl book.   

Способы управления

Предупреждение: Объект Kubernetes должен управляться каким-то одним способом.  Смешивание способов может привести к непредсказуемому поведению объекта.

Императивные команды

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

Это рекомендуемый способ для начального обучения или запуска поочерёдных задач с однократным исполнением (one-off task) в кластере. Поскольку этот способ работает непосредственно с живыми объектами, он не предоставляет историю предыдущих конфигураций.

Примеры

Запуск экземпляра (instance) контейнера nginx созданием объекта Deployment:

kubectl create deployment nginx --image nginx

 Сравнение

Преимущества по сравнению с конфигурацией объекта:  

• Команды состоят из слов с одним действием (single action word).
• Для изменения в кластере требуется только одно действие команды.

Недостатки по сравнению с конфигурацией объекта:

• Команды не интегрируются с изменением процесса ревю (review processes).
• Команды не обеспечивают последующего просмотра изменений.
• Команды не обеспечивают источника записей, кроем того, обхъекта, который работает (live).
• Команды не обеспечивают шаблона создания новых объектов.

Императивная конфигурация объекта

При императивной конфигурации объекта, команда kubectl определяет операцию (создание, замена и пр.), флаги опций и по крайней мере одно имя файла. Указанный в команде файл должен содержать полное определение объекта в формате YAML или JSON.

В документе API reference указаны подробности конфигурации объекта.

Предупреждение: императивная команда replace заменяет существующую спецификацию на новую, сбрасывая все изменения в объекте, которые отличают его от файла конфигурации. Такой подход не должен использоваться с ресурсами, спецификации которых модифицируются независимо от файла конфигурации. Сервисы типа LoadBalancer, например, имеют своё собственное поле externalIP, модифицируемое независимо от конфигурации кластера.

Примеры

Создание объекта, определённого в файле конфигурации:

kubectl create -f nginx.yaml

Удаление объекта, определённого в файле конфигурации:

kubectl delete -f nginx.yaml -f redis.yaml

Модификация объекта, определённого в файле конфигурации путём перезаписи живой текущей конфигурации:

kubectl replace -f nginx.yaml

 Сравнение

Преимущества по сравнению с императивными командами:

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

Недостатки по сравнению с императивными командами:

• Конфигурация объекта требует базового понимания схемы объекта.
• Требуется написание файла YAML.

Преимущества по сравнению с декларативной конфигурацией объекта:

• Действия при императивной конфигурации объекта проще и легче для понимания.
• В версии Kubernetes version 1.5, императивная конфигурация объекта – более зрелая.

Недостатки по сравнению с декларативной конфигурацией объекта:

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

Декларативная конфигурация объекта

При декларативной конфигурации объекта, пользователь работает с файлами конфигурации объекта, которые хранятся локально, однако, пользователь не определяет операции, которые нужно выполнить с файлами. Операции создания, модификации и удаления автоматически распознаются kubectl. Это даёт возможность работы с каталогами, где различные операции могут потребоваться для различных объектов.

Примечание: декларативная конфигурация объекта сохраняют изменения, сделанные другими писателями (writers), даже если изменения не отражаются в фацле конфигурации объекта. Это можно делать при помощи API-команды patch для записи только наблюдаемых изменений, вместо API-команды replace для замены всей конфигурации объекта.

Примеры

Обработка файла конфигурация объекта в каталоге configs, создание или патчинг существующего объекта.

kubectl diff -f configs/

kubectl apply -f configs/

Рекурсивная обработка каталога:

kubectl diff -R -f configs/

kubectl apply -R -f configs/

Сравнение

Преимущества по сравнению с императивной конфигурацией объекта:

• Изменения, сделанные на живых объектах, сохраняются, даже если они не отображаются в файлах конфигурации.
• Декларативная конфигурация объекта имеет лучшую поддержку операций в каталогах и автоматически распознаёт типы операций (create, patch, delete) для каждого объекта.

Недостатки по сравнению с императивной конфигурацией объекта:

• Декларативная конфигурация объекта сложнее в отладке и понимании результатов, если получается не то, что ожидалось.
• Частичные модификации усложняют операции.