Настройка

Docker Compose Versions

Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on versions 2.1 and 3.2 due to their experimental nature.

A full list on compatibility between all three versions is listed in our conversion document including a list of all incompatible Docker Compose keys.

Feedback

Was this page helpful?

Yes
No

Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on
Stack Overflow.
Open an issue in the GitHub repo if you want to
report a problem
or
suggest an improvement.

Create an Issue
Edit This Page

Page last modified on
May 30, 2020 at 3:10 PM PST
by
add en pages
(Page History)

Проброс порта в pod

А сейчас пробросим 80-й порт мастера в конкретный под и проверим, что nginx действительно работает в соответствии с установленным конфигом. Делается это следующим обарзом.

# kubectl port-forward deployment-nginx-848cc4c754-w7q9s 80:80
Forwarding from 127.0.0.1:80 -> 80
Forwarding from :80 -> 80

Перемещаемся в сосeднюю консоль мастера и там проверяем через curl.

# curl localhost:80
deployment-nginx-848cc4c754-w7q9s

Если сделать проброс в другой под и проверить подключение, вы получите в ответ на запрос curl на 80-й порт мастера имя второго пода. На практике, я не знаю, как можно использовать данную возможность. А вот для тестов в самый раз.

Чем полезны контейнеры

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

Техническим же специалистам контейнеры прежде всего полюбились за возможность упаковать приложение вместе с его средой запуска, решая тем самым проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика и в последующих окружениях рано или поздно приведёт к сбоям, и нужно будет как минимум потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало! ¯\_(ツ)_/¯».

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

Deployment — деплой в кластер

Переходим к следующей абстракции Kubernetes — Deployment. Они управляют наборами replicaset для непрерывного обновления подов. Покажу на примере, о чем идет речь. Допустим, у вас вышло обновление приложения в новом контейнере. Вам нужно не останавливая сервис выкатить обновление в прод. Если вы измените версию контейнера в шаблоне replicaset, автоматически он у вас не обновится. Да, если pod со старой версией контейнера упадет, новый будет создан уже с новой версией. Но все работающие поды останутся на старой версии.

Deployment как раз и нужен для управления репликасетами, задавая им стратегию обновления. У вас вышла новая версия контейнера, вы заменяете в текущем deployment версию контейнера и он по заранее настроенным правилам начинает перезапуск репликасетов и соответственно подов в них. Покажу на примере nginx, который мы откатим на предыдущую версию. Создаем yaml файл с deployment.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - image: nginx:1.16
        name: nginx
        ports:
        - containerPort: 80

Запускаем его.

# kubectl apply -f deployment-nginx.yaml 
deployment.apps/deployment-nginx created

Смотрим список подов и репликасетов.

# kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
deployment-nginx-785b6d8d9f-dr4cv   1/1     Running   0          55s
deployment-nginx-785b6d8d9f-m47tr   1/1     Running   0          55s
# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
deployment-nginx-785b6d8d9f   2         2         2       58s

Проверяем версию nginx в одном из подов.

# kubectl describe pod deployment-nginx-785b6d8d9f-dr4cv

Теперь откатимся на предыдущую версию nginx 1.15. Для этого вносим изменения в Deployment.

# kubectl set image deployment deployment-nginx nginx=nginx:1.15

Проверяем список подов и репликасетов.

# kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
deployment-nginx-68d778658b-fz5lt   1/1     Running   0          11s
deployment-nginx-68d778658b-mpkg5   1/1     Running   0          10s
# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
deployment-nginx-68d778658b   2         2         2       15s
deployment-nginx-785b6d8d9f   0         0         0       5m57s

Название подов и репликасета изменились. Появился новый replicaset, а старый остался с погашенными подами, у него параметр replicas стал 0. Проверяем версию nginx в поде.

# kubectl describe pod deployment-nginx-68d778658b-fz5lt

Версия nginx изменилась во всех подах. Стратегия обновления описана в шаблоне деплоймента в разделе strategy. В данном случае используется тип RollingUpdate, когда deployment постепенно уменьшает количество реплик старой версии и увеличивает реплики новой версии, пока они все не заменят старые. При этом replicaset с предыдущей версией контейнера осталась. Она не удаляется для того, чтобы можно было потом оперативно вернуться на предыдущую версию, если с новой будет что-то не так. Для этого достаточно будет по очереди погасить поды новой replicaset и запустить старые. Делается это следующим образом.

# kubectl rollout undo deployment deployment-nginx
deployment.extensions/deployment-nginx rolled back

Проверяем наши replicaset.

# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
deployment-nginx-68d778658b   0         0         0       12m
deployment-nginx-785b6d8d9f   2         2         2       18m

Видим, что был снова запущен предыдущий replicaset с прошлой версией контейнера. По-умолчанию хранятся 10 версий прошлых replicaset.

Отказоустойчивость подов с помощью ReplicaSet

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

---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - image: nginx:1.16
        name: nginx
        ports:
        - containerPort: 80

Запускаем replicaset.

# kubectl apply -f replicaset-nginx.yaml

Проверяем, что получилось.

# kubectl get replicaset
NAME               DESIRED   CURRENT   READY   AGE
replicaset-nginx   2         2         2       18m

Нам нужно было 2 реплики и мы их получили. С помощью edit мы можем на ходу редактировать replicaset, к примеру, добавляя количество реплик.

# kubectl edit replicaset replicaset-nginx

Репликасет сама следит за количеством запущенных подов. Если один из них по какой-то причине упадет или будет удален, она поднимет его заново. Можете проверить это сами, вручную удалив один из подов. Спустя некоторое время он появится снова.

# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
pod-nginx                1/1     Running   0          15m
replicaset-nginx-f87qf   1/1     Running   0          22m
replicaset-nginx-mr4kw   1/1     Running   0          22m

# kubectl delete pod replicaset-nginx-f87qf
pod "replicaset-nginx-f87qf" deleted

# kubectl get replicaset
NAME               DESIRED   CURRENT   READY   AGE
replicaset-nginx   2         2         2       23m

# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
pod-nginx                1/1     Running   0          16m
replicaset-nginx-g4l58   1/1     Running   0          14s
replicaset-nginx-mr4kw   1/1     Running   0          23m

Я удалил replicaset-nginx-f87qf, вместо него тут же был запущен новый replicaset-nginx-g4l58. Наглядный пример одного из механизмов отказоустойчивости в кластере kubernetes на уровне подов. Кубернетис будет следить за количеством реплик на основе их label. Если вы через replicaset указали запустить 2 реплики приложения с меткой my-nginx, ни меньше, ни больше подов с этой меткой вы запустить не сможете. Если вы вручную запустите pod с меткой my-nginx, он будет тут же завершен, если у вас уже есть 2 пода с такими метками от replicaset.

Replicaset запускает поды на разных нодах. Проверить это можно, посмотрев расширенную информацию о подах.

# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
replicaset-nginx-cmfnh   1/1     Running   0          2m26s    10.233.67.6   kub-node-1   <none>           <none>
replicaset-nginx-vgxfl   1/1     Running   0          2m26s    10.233.68.4   kub-node-2   <none>           <none>

Таким образом, если у вас одна нода выйдет из строя, кластер автоматически запустит умершие поды на новых нодах. При этом, если нода вернется обратно с запущенными подами на ней, kubernetes автоматически прибьет лишние поды, чтобы их максимальное количество соответствовало информации из шаблона replicaset.

Удаляются replicaset так же как и поды.

# kubectl delete rs replicaset-nginx
replicaset.extensions "replicaset-nginx" deleted

Вместо длинного replicaset я использовал сокращение rs. Это бывает удобно для абстракций с длинными названиями. Для всех них кубернетис поддерживает сокращения.

Управление кластером

Запуск кластера

Команда используется для запуска кластера.
Эта команда создаёт и конфигурирует виртуальную машину, которая запускает одноузловой кластер Kubernetes.
Эта команда также настраивает вашу установку kubectl для взаимодействия с этим кластером.

Указание версии Kubernetes

Вы можете указать используемую версию Kubernetes в Minikube, добавив параметр в команду . Например, чтобы запустить Minikube из-под версии v1.19.0, вам нужно выполнить следующую команду:

Указание драйвера виртуальной машины

Вы можете изменить драйвер виртуальной машины, добавив флаг в команду .

Тогда команда будет выглядеть так:

Minikube поддерживает следующие драйверы:

virtualbox
vmwarefusion
docker (ЭКСПЕРИМЕНТАЛЬНЫЙ)
kvm2 (установка драйвера)
hyperkit (установка драйвера)
hyperv (установка драйвера)
Обратите внимание, что указанный IP-адрес на этой странице является динамическим и может изменяться. Его можно получить с помощью .
vmware (установка драйвера) (VMware unified driver)
parallels (установка драйвера)
none (Запускает компоненты Kubernetes на хосте, а не на виртуальной машине

Использование этого драйвера требует использование Linux и установленного DockerDocker — это программное обеспечение для виртуализации на уровне операционной системы, которая известна как контейнеризация.
.)

Запуск кластера в других средах выполнения контейнеров

Вы можете запустить Minikube в следующих средах выполнения контейнеров.

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

Также можете использовать расширенную вариант команды:

Чтобы использовать CRI-O в качестве среды выполнения контейнера, выполните команду ниже:

Также можете использовать расширенную вариант команды:

Использование локальных образов путём повторного использования демона Docker

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

Для работы с Docker-демоном на вашем хосте под управлением Mac/Linux, запустите последнюю строку из вывода команды .

Теперь вы можете использовать Docker в командной строке вашего хост-компьютера на Mac/Linux для взаимодействия с демоном Docker внутри виртуальной машины Minikube:

Конфигурация Kubernetes

Minikube имеет такую возможность как «конфигуратор» («configurator»), позволяющая пользователям настраивать компоненты Kubernetes произвольными значениями.
Чтобы использовать эту возможность, используйте флаг в команде .

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

Этот флаг принимает строку вида , где — это одно из значение в приведённом ниже списка, — ключ из структуры конфигурации, а — значение, которое нужно установить.

Допустимые ключи можно найти в документации по в Kubernetes каждого компонента.
Ниже вы найдете документации по каждой поддерживаемой конфигурации:

Примеры

Чтобы изменить настройку на значение 5 в Kubelet, передайте этот флаг .

Эта возможность также поддерживает вложенные структуры. Для изменения настройки на значение в планировщике, передайте флаг .

Чтобы изменить настройку в на значение , используйте флаг .

Остановка кластера

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

Удаление кластера

Команда используется для удаления кластера.
Эта команда выключает и удаляет виртуальную машину Minikube.
Данные или состояние не сохраняются.

Смотрите инструкцию по обновлению minikube.

What You Can Do

Docker for Mac and Windows are the most popular way to configure a Docker dev environment and are used everyday by hundreds of thousands of developers to build, test and debug containerized apps. Developers building both docker-compose and Swarm-based apps, and apps destined for deployment on Kubernetes can now get a simple-to-use development system that takes optimal advantage of their laptop or workstation. All container tasks – build, run and push – will run on the same Docker instance with a shared set of images, volumes and containers. Docker for Mac is simple to install, so you can have Docker containers running on your Mac in just a few minutes. And Docker for Mac auto-updates so you continue getting the latest Docker product revisions.

With experimental Kubernetes support in Docker CE for Mac, Docker can provide users an end-to-end suite of container-management software and services that span from developer workstations running Docker for Mac or Windows, through test and CI/CD, through to production systems on-premises or in the cloud running Docker Enterprise Edition (EE).

The beauty of building with Docker for Mac or Windows is that you can deploy the exact same set of Docker container images on your desktop as you do with Docker Enterprise Edition (EE) on your production systems. Docker for Mac or Windows is a single node system for building, testing and preparing to ship applications; Docker EE provides the security, control, and scale needed to manage your production applications. You eliminate the “it worked on my machine” problem because you have the same Docker containers running on the same Docker engines, and the same Docker Swarm and Kubernetes orchestrators (coming soon to EE).

Архитектура кубернетис

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

Также на узлах развернуты поды (pods) — базовые модули управления и запуска приложений, состоящие из одного или нескольких контейнеров. При этом на одном узле для каждого пода обеспечивается разделение ресурсов, межпроцессное взаимодействие и уникальный IP-адрес в пределах кластера. Это позволяет приложениям, развёрнутым на поде, без риска конфликта использовать фиксированные и предопределённые номера портов. Для совместного использования нескольких контейнеров, развернутые на одном поде, их объединяют в том (volume) – общий ресурс хранения .

Помимо подов, на ведомых узлах также работают следующие компоненты Kubernetes []:

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

Управление подами реализуется через API Kubernetes, интерфейс командной строки (Kubectl) или специализированные контроллеры (controllers) – процессы, которые переводят кластер из фактического состояния в желаемое, оперируя набором подов, определяемого с помощью селекторов меток. Селекторы меток (label selector) – это запросы, которые позволяют получить ссылку на нужный объект управления (узел, под, контейнер) .

На ведущем компоненте (master) работают следующие элементы :

• Etcd – легковесная распределённая NoSQL-СУБД класса «ключ — значение», которая отвечает за согласованное хранение конфигурационных данных кластера.
• сервер API— ключевой компонент подсистемы управления, предоставляющий интерфейс программирования приложений в стиле REST (в формате JSON поверх HTTP-протокола) и используемый для внешнего и внутреннего доступа к функциям Kubernetes. Сервер API обновляет состояние объектов, хранящихся в etcd, позволяя своим клиентам управлять распределением контейнеров и нагрузкой между узлами системы.
• планировщик (scheduler), который регулирует распределение нагрузки по узлам, выбирая узел выполнения для конкретного пода в зависимости от доступности ресурсов узла и требований пода.
• менеджер контроллеров (controller manager) – процесс, выполняющий основные контроллеры Kubernetes (DaemonSet Controller и Replication Controller), которые взаимодействуют с сервером API, создавая, обновляя и удаляя управляемые ими ресурсы (поды, точки входа в сервисы и т.д.).

Архитектура Kubernetes

Как работает Kubernetes

Согласно концепции контейнеризации, контейнеры содержат выполняемые сервисы, библиотеки и прочие ресурсы, необходимые для работы этих приложений. Доступ к контейнеру извне реализуется через индивидуально назначаемый ему IP-адрес. Таким образом, в Kubernetes контейнер – это программный компонент самого низкого уровня абстракции. Для межпроцессного взаимодействия нескольких контейнеров они инкапсулируются в поды.

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

Что особенно важно для Big Data проектов, Kubelet – компонент Kubernetes, работающий на узлах, автоматически обеспечивает запуск, остановку и управление контейнерами приложений, организованными в поды. При обнаружении проблем с каким-то подом Kubelet пытается повторно развернуть и перезапустить его на узле

Аналогично HDFS, наиболее популярной распределенной файловой системе для Big Data-решений, реализованной в Apache Hadoop, в кластере Kubernetes каждый узел постоянно отправляет на master диагностические сообщения (heartbeat message). Если по содержанию этих сообщений или в случае их отсутствия мастер обнаруживает сбой какого-либо узла, процесс подсистемы управления Replication Controller пытается перезапустить необходимые поды на другом узле, работающем корректно .

Принципы работы Kubernetes

Примеры использования кубернетис

Поскольку K8s предназначен для управления множеством контейнеризированных микросервисов, неудивительно, что эта технология приносит максимальную выгоду именно в Big Data проектах. Например, кубернетис используют популярный сервис знакомств Tinder , телекоммуникационная компания Huawei , крупнейший в мире онлайн-сервисом поиска автомобильных попутчиков BlaBlaCar , Европейский Центр ядерных исследований (CERN) и множество других компаний, работающих с большими данными и нуждающимися в инструментах быстрого и отказоустойчивого развертывания приложений .

В связи с цифровизацией предприятий и распространением DevOps-подхода, спрос на владение Kubernetes растет и в отечественных компаниях. Как показал обзор вакансий с рекрутинговой площадки HeadHunter, в 2019 году для современного DevOps-инженера и Big Data разработчика данная технология является практически обязательной.

Kubernetes — настоящий must have для современного DevOps-инженера

Источники

1. https://ru.wikipedia.org/wiki/Kubernetes
2. https://ru.wikipedia.org/wiki/Docker
3. https://habr.com/ru/company/flant/blog/327338/
4. https://habr.com/ru/company/flant/blog/440278/
5. https://habr.com/ru/company/flant/blog/349940/
6. https://habr.com/ru/company/flant/blog/345780/
7. https://habr.com/ru/company/flant/blog/412571/

Заключение

Я рассмотрел основные абстракции kubernetes, которые нужны для того, чтобы на нем хоть что-то запустить и начать работать. Кластер в таком виде уже способен принимать запросы из вне. Для полноты картины не хватает одного объемного раздела — фаловые хранилища. Эта отдельная большая тема, поэтому я решил ее не затрагивать здесь, а вынести в отдельную статью, которая будет следующей в этом цикле. В таком виде, как описано здесь, используются локальные диски нод кластера, где запущены контейнеры docker.

Если вам подходит такой формат работы — пользуйтесь. По большому счету, он вполне жизнеспособен, если у вас все полезные данные, к примеру, хранятся в самих контейнерах в реджистри и в базе данных, которая работает не в кластере, а медиаконтент на внешних CDN. В таком случае kubernetes будет работать как масштабируемый вычислительный кластер.

Для автоматического деплоя приложений в кластер k8s можно использовать helm. Я рассмотрел этот вопрос в отдельной статье — Работа с Helm 3 в Kubernetes.

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

Онлайн курс «Сетевой инженер»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные сети, рекомендую познакомиться с онлайн-курсом «Сетевой инженер» в OTUS. Это авторская программа в сочетании с удалённой практикой на реальном оборудовании и академическим сертификатом Cisco! Студенты получают практические навыки работы на оборудовании при помощи удалённой онлайн-лаборатории, работающей на базе партнёра по обучению — РТУ МИРЭА: маршрутизаторы Cisco 1921, Cisco 2801, Cisco 2811; коммутаторы Cisco 2950, Cisco 2960.

Особенности курса:

• Курс содержит две проектные работы.;
• Студенты зачисляются в официальную академию Cisco (OTUS, Cisco Academy, ID 400051208) и получают доступ ко всем частям курса «CCNA Routing and Switching»;
• Студенты могут сдать экзамен и получить вместе с сертификатом OTUS ещё сертификат курса «CCNA Routing and Switching: Scaling Networks»;

Проверьте себя на вступительном тесте и смотрите программу детальнее по .