Kubernetes (4)

Продолжение. Предыдущая глава 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 должен управляться каким-то одним способом.  Смешивание способов может привести к непредсказуемому поведению объекта.

Способы управленияС чем работает способРекомендуемые средыЧисло источников вносимых данных (writers)Длительность обучения
Императивные командыЖивые объектыПроекты разработки (Development)1+Наименьшая
Императивная конфигурация объектаОтдельные файлыПроекты в реальной среде (Production)1Средняя
Декларативная конфигурация объектаФайлы и каталогиПроекты в реальной среде (Production)1+Наибольшая

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

При использовании императивных команд, пользователь работает непосредственно с живыми объектами в кластере. Пользователь вводит команды в строку 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) для каждого объекта.

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

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

Об авторе Алексей Шалагинов

Независимый эксперт
Запись опубликована в рубрике NFV, цифровая трансформация с метками , , , . Добавьте в закладки постоянную ссылку.

3 отзыва на “Kubernetes (4)

  1. Уведомление: Kubernetes (3) | Telecom & IT

  2. Уведомление: Kubernetes (5) | Telecom & IT

  3. Уведомление: Kubernetes (6) | Telecom & IT

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.