Just-in-Time Kubernetes: Руководство начинающим для понимания основных концепций Kubernetes

Простые истины

Итак, вы хотите освоить Kubernetes. Это такой технологический хайп, о котором, кажется, говорят все. Я затрудняюсь сказать, сколько рекрутеров обращались ко мне с предложением поработать с Kubernetes. Kubernetes — это определенно круто!

Вполне возможно, к вам относится одно из следующих утверждений:

• Вы слышали о Kubernetes и, наконец, решили, что настало время посмотреть, к чему вся эта шумиха.

• Вы опытный инженер-программист, который уже некоторое время работает с Kubernetes в режиме обучения "just-in-time". То есть, вы изучаете только то, что вам нужно для выполнения работы. Теперь же вам становится все труднее, и вы решили, что настало время углубиться в некоторые основы. 

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

Что бы ни привело вас сюда, добро пожаловать! Я рад, что вы здесь!

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

Моя цель — показать вам, что Kubernetes не так уж и страшен, и вдохновить вас на дальнейшее совершенствование своих знаний. (ознакомьтесь с одним из моих расширенных постов) Если вы уже давно занимаетесь Kubernetes, пусть это освежит ваши знания! Возможно, вы делали все определенным образом, принимая как должное, что "так оно и работает". А сейчас, возможно, вы лучше поймете, почему это работает именно так.

Давайте начнем!

Обзор

В этом посте я расскажу о следующих темах:

1. Что такое Kubernetes?

2. Высокоуровневый взгляд: Архитектура Kubernetes

3. Копаем глубже: Ресурсы, контроллеры и операторы

4. Инструмент командной строки kubectl для взаимодействия с Kubernetes

Примечание: Я предполагаю, что у вас уже есть базовые знания о контейнерах.

Что такое Kubernetes?

Прежде всего... что такое Kubernetes? Kubernetes - это система оркестрации контейнеров, которая позволяет развертывать, масштабировать и управлять контейнерными приложениями. В сокращенном виде она также именуется k8s. 

Забавный факт: Kubernetes уходит своими корнями в проект Borg, который изначально разрабатывался компанией Google.

Теперь вам, возможно, интересно, что такое оркестровка контейнеров. Давайте рассмотрим пример.

Допустим, у вас на компьютере запущена куча контейнеров Docker. Возможно, некоторым из них нужно общаться друг с другом. А может быть, ваша подруга Нэнси пытается получить доступ к конечной точке API, запущенной на одном из этих контейнеров. Как обеспечить, чтобы контейнеры могли общаться друг с другом? Как вы можете гарантировать, что Нэнси сможет безопасно получить доступ к конечной точке API? Что произойдет, если один из ваших контейнеров умирает? Что будет, если вам понадобится масштабировать контейнеры, потому что внезапно доступ к конечной точке API понадобится не только Нэнси... это будет Нэнси и все ее друзья-разработчики, участвующие в хакатоне. Что тогда?

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

Заклятые друзья Kubernetes

Несмотря на то, что Kubernetes очень крут и популярен, вы можете быть шокированы, узнав, что это не единственный контейнерный оркестратор! Поэтому будет справедливо упомянуть несколько конкурентов Kubernetes:

• Docker Swarm

• Marathon

• Amazon ECS

• Azure Service Fabric

• Hashicorp Nomad

Дистрибутивы Kubernetes

Стоит упомянуть, что существует несколько различных способов запуска Kubernetes.

Локальный

Во-первых, вы можете запустить Kubernetes локально на своей машине. Вот несколько инструментов, которые делают это возможным:

• KIND (означает Kubernetes in (в) Docker).

• Docker Desktop (он поставляется вместе с Kubernetes, и вы можете запустить его локально)

• Minikube

Решения облачных вендоров

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

• Google Kubernetes Engine (GKE)

• Amazon Elastic Kubernetes Service (EKS)

• Azure Kubernetes Service (AKS).

У каждого из вендоров облака обычно есть небольшой набор команд CLI для автоматического создания кластера k8s. Это совершенно волшебное ощущение - дать команду CLI, которая создает целый кластер за 5-10 минут. Мы говорим не только о запуске виртуальных машин по требованию, но и о запуске всех служб, которые обеспечивают работу k8s. Если задуматься, это впечатляет!

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

Решения для предприятий

Для людей с корпоративным мышлением, которые любят красивые графические интерфейсы администратора и любят, чтобы их водили за руку (без осуждения - на самом деле существует огромный рынок для такого рода вещей), вы можете обратить внимание на некоторых из этих поставщиков:

• RedHat OpenShift

• VMWare Tanzu

• Rancher

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

СДЕЛАЙ САМ

И, наконец, вы всегда можете создать свои собственные кластеры k8s с нуля. Если вы действительно хотите понять, как работает Kubernetes, то этот способ вам точно подойдет!

Компоненты Kubernetes

Теперь, когда мы немного ознакомились с Kubernetes, давайте заглянем под капот.

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

Кластер обычно состоит из главного узла (мастер) и множества рабочих (воркер) узлов (minion).

Примечание: Вот почему вам нужно как минимум два узла - потому что неправильно иметь кластер, в котором один узел одновременно выполняет функции мастера и воркера.

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

На приведенной ниже схеме показано, что происходит внутри мастера и воркера:

Главный узел

Как управляющий всей этой операцией, мастер имеет довольно много компонентов:

• etcd

• Сервер API

• Менеджер контроллеров

• Планировщик

Давайте разберемся в них.

etcd

etcd — это распределенная база данных ключ-значение. Она является источником достоверных данных для Kubernetes. Каждый раз, когда вы вносите изменения в Kubernetes — например, отправляя YAML или JSON через REST API k8s или с помощью инструмента kubectl CLI (подробнее об этом позже) — эти изменения сохраняются в etcd в виде JSON. Он также версионируется, таким образом, обеспечивается серьезный контроль версий.

Одной из ключевых особенностей etcd является ее способность следить за изменениями. То есть, она сверяет текущие настройки системы с любыми входящими изменениями, отправленными в Kubernetes через REST API вызов или kubectl.

Предупреждение для зануд: я лично считаю, что etcd — один из самых крутых компонентов Kubernetes. Вы можете установить etcd на свою локальную машину (например, OSX или Ubuntu) и поиграть с ним, используя инструмент etcdctl CLI. В Python даже есть несколько библиотек для программного взаимодействия с etcd. Я лично играл с библиотекой Python etcd3, и рекомендую изучить etcd самостоятельно!

Сервер API

Сервер API отвечает за обслуживание API Kubernetes. Хотите поговорить с Kubernetes и попросить его сделать что-то для вас? Это ваша прямая линия - будь вы пользователь, программа или kubectl. Сервер API также отвечает за отправку и получение данных в/из etcd.

Менеджер контроллеров

Менеджер контроллеров — это мозг, который стоит за оркестровкой. Kubernetes имеет несколько контроллеров, каждый из которых отвечает за разные вещи. Они следят за состоянием вашего кластера, затем вносят или запрашивают изменения, когда это необходимо. Менеджер контроллеров следит за тем, чтобы он указывал нужным контроллерам на выполнение необходимых действий. Например, существуют контроллеры для:

• Принятие мер при выходе из строя пода

• Подключение служб к подам

• Создание учетных записей и доступ к API-токенам

И многие другие...

Примечание: Если вам интересно, что такое под, то это, по сути, обертка вокруг одного или нескольких контейнеров.

Планировщик

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

Рабочие узлы

Очевидно, что мастер делает многое, но, как и менеджер, он ничто без рабочих узлов (воркеров). Воркеры содержат 2 основных компонента:

• Kubelet

• Kube-proxy

Kubelet

Kubelet — это агент (небольшое приложение), который запускается на каждом рабочем узле в кластере. Его основная задача — следить за тем, чтобы контейнеры запускались в поде (обертке из одного или нескольких контейнеров). Но кто указывает ему запустить эти контейнеры? Это происходит из control plane (управляющего уровня) (где находится наш хороший друг — менеджер контроллеров). Когда уровень управления требует, чтобы что-то произошло в узле, kubelet делает это.

Kubelet запускает рантайм контейнера и, как следует из названия, отвечает за фактический его запуск. Точнее, он управляет полным жизненным циклом контейнера: получение образа контейнера (из реестра контейнеров, такого как Docker Hub) и его хранение, выполнение контейнера, подключение к сети и т. д. — популярная среда выполнения контейнеров; однако существуют и другие, такие как containerd, CRI-O.

Примечание: В настоящее время Kubernetes использует контейнерный рантайм Docker; однако в ближайшем будущем он откажется от Docker в пользу Container Runtime Interface (CRI), созданный для Kubernetes. Образы, созданные Docker, будут продолжать работать в вашем кластере со всеми режимами выполнения, как и раньше, поэтому не стоит паниковать!

Kube-proxy

Kube-proxy обрабатывает сетевые соединения внутри и за пределами вашего кластера. Это означает, что если подам нужно общаться между собой или если какому-то внешнему сервису нужно обратиться к подам, kube-proxy поможет это сделать.

Ресурсы, контроллеры и операторы

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

Ресурсы

Ресурс Kubernetes — это объект или операция в Kubernetes, доступ к которым осуществляется через Kubernetes API. Тип ресурса известен как kind (вид) и представлен в виде объекта JSON. Этот JSON-объект хранится (и версионируется) в хранилище etcd.

Существует две категории ресурсов: примитивные и пользовательские. Примитивные ресурсы поставляются "из коробки" с Kubernetes. К ним относятся Pod, Service, Deployment, ServiceAccount, PersistentVolumeClaim, RoleBinding... Я могу продолжить.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipeline-sa
secrets:
  - name: basic-docker-user-pass
  - name: basic-git-app-repo-user-pass

Образец примитивного ресурса в Kubernetes

Пользовательские ресурсы являются расширением API Kubernetes и поэтому не всегда доступны в стандартной установке Kubernetes. После инсталляции вы можете использовать инструмент kubectl CLI для создания и доступа к этим ресурсам (подробнее о kubectl позже). Пользовательские ресурсы создаются, когда вы хотите/необходимо, чтобы Kubernetes делал некоторые вещи, которые вы не можете получить из коробки с k8s.

Вот пример того, как выглядит пользовательский ресурс:

apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
  generateName: my-pipeline-run-
spec:
  serviceAccountName: pipeline-sa
  pipelineRef:
    name: my-pipeline
  resources:
  - name: git-app-repo
    resourceRef:
      name: git-app-repo
  - name: image-registry
    resourceRef:
      name: image-registry

Образец пользовательского ресурса в Kubernetes

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

• apiVersion: Версия API Kubernetes, который вы используете для создания ресурса.

• kind: Тип создаваемого ресурса

• metadata: Данные, которые однозначно идентифицируют ресурс

• spec: Сообщает Kubernetes желаемое состояние ресурса.

Примечание: Не все ресурсы имеют поле spec (например, ServiceAccount, Role, RoleBinding).

Контроллеры

Как говорилось ранее, контроллер следит за состоянием вашего кластера, затем вносит или запрашивает изменения, где это необходимо, для достижения желаемого состояния. Что именно это значит?

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

Операторы

Оператор - это разновидность контроллера. Помните те пользовательские ресурсы, о которых я говорил ранее? Определить пользовательский ресурс - это хорошо, но в конце концов, как заставить Kubernetes сделать с ним что-то полезное? Вот тут-то и приходят на помощь операторы - это закулисный код, который заставляет эти пользовательские ресурсы делать полезные вещи.

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

Интересный факт: операторы могут быть написаны на любом языке, и существуют несколько фреймворков, которые предоставляют шаблонный (boilerplate) код, чтобы помочь вам написать свой собственный оператор.

Создавать операторы может кто угодно: вы, ваша организация или сторонний вендор. Например, RedHat OpenShift имеет свой собственный набор операторов (вместе с сопутствующими пользовательскими ресурсами), которые являются частью его основного продукта, который он запускает поверх обычного Kubernetes. И благодаря замечательному сообществу разработчиков открытого кода многие из операторов доступны для совместного использования. Вы можете ознакомиться с некоторыми из них на сайте OperatorHub.io.

kubectl

Вы слышали, как я много говорил о kubectl в этом посте, и теперь мы, наконец, увидим, из-за чего вся эта шумиха! kubectl - это интерфейс командной строки (CLI) для управления операциями на кластерах Kubernetes. Он взаимодействует с API-сервером, чтобы получить информацию о нашем кластере и указать Kubernetes сделать что-нибудь для нас, например, создать новый ресурс или изменить существующий. Как я уже говорил, если вы расширяете Kubernetes API с помощью чудесной комбинации операторов и пользовательских определений ресурсов (CRD), вы можете использовать kubectl для доступа/обновления этих ресурсов!

Поскольку это инструмент командной строки, kubectl запускается на вашей локальной машине. Он работает совместно с файлом kubeconfig, который представляет собой YAML-файл, по умолчанию установленный в $HOME/.kube/config. Вот как может выглядеть пример файла kubeconfig:

Записи в файле kubeconfig автоматически создаются при подключении к существующему кластеру Kubernetes.

Например, если бы я хотел подключиться к кластеру Azure Kubernetes, я бы использовал Azure's az CLI для выполнения следующей команды:

az aks get-credentials --resource-group my-resource-group --name my-aks-cluster

Который заполнит мой файл kubeconfig для меня. 

Аналогично, я могу использовать gcloud CLI Google Cloud для подключения к кластеру Google Kubernetes следующим образом:

gcloud container clusters get-credentials my-gke-cluster --region=us-central1-a

Дело в том, что у каждого облачного провайдера есть свой собственный облачный CLI и набор команд для подключения к кластеру Kubernetes в этом облаке и соответствующего обновления файла kubeconfig.

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

Примечание: Вы можете зарегистрировать несколько кластеров Kubernetes из разных облаков в одном файле kubeconfig. Также вы можете иметь несколько файлов kubeconfig, если вам так больше нравится.

Заключение

Уф-ф! Было очень много интересного! Это ни в коем случае не было техническим углублением в Kubernetes. Скорее, моя цель была познакомить вас с основными концепциями, дать вам представление о том, как работает Kubernetes, и, надеюсь, вдохновить вас на более глубокое изучение этой популярной технологии, о которой, кажется, говорят все.

Вы сможете обмолвится о нескольких забавных фактах про Kubernetes своим друзьям и близким во время следующего звонка в Zoom, а также рассказать им такие вещи, как: 

• Что такое Kubernetes и зачем он вам нужен

• Разница между главным и рабочим узлами, а также все преимущества каждого из них

• Что такое ресурсы

• Разница между контроллерами и операторами

• Что делает kubectl

Перевод материала подготовлен для будущих студентов курса «DevOps практики и инструменты».

Инфраструктура как код (IaC), Immutable Infrastructure и другие страшные слова из книжек про DevOps у всех на слуху, а в родной компании всё еще по заявкам создаем виртуалки накликивая их в гипервизоре. Всех желающих приглашаем на открытый урок «Принципы организации инфраструктурного кода и работа над инфраструктурой в команде на примере Terraform», на котором поговорим о том, зачем и как начать использовать практику Infrastructure as a Code.