Привет! Меня зовут Леонид, я DevOps-инженер в компании KTS.
В этой статье я рассмотрю различные оркестраторы и объясню, почему Kubernetes — лучший выбор.
Нашей компании уже 6 лет, и 4 из них мы живем с Kubernetes. До этого мы испытали все варианты деплоя приложений на серверах: начиная от простого git pull до ci/cd на нескольких серверах.
За небольшой срок в 4 года мы набрали много опыта. Начинали с вопроса, который, возможно, стоит сейчас перед вами: «Какой оркестратор выбрать?» Мы рассмотрели разные варианты, и в итоге остановились на Kubernetes. В статье расскажу, почему.
Большинство микросервисов — это контейнеры, которые должны связно работать между собой. Кроме контейнеров, это могут быть обычные приложения: например, на Java или виртуальной машине.
Оркестратор позволяет управлять всем этим централизованно:
Что должно быть в хорошем удобном оркестраторе:
Вертикальное масштабирование: кластер управляет ресурсами, которые выделяются приложению. Выделять и ограничивать ресурсы необходимо, чтобы не столкнуться с такими ситуациями, когда одно из приложений съело всю память и CPU на наших серверах, а другим ничего не осталось. Оркестратор понимает, какие лимиты ресурсов есть у приложения на старте, и до каких оно может подниматься.
kind: Deployment
metadata:
name: {{ .Values.name }}
namespace: {{ .Values.namespace }}
labels:
app: {{ .Values.name }}
spec:
replicas: {{ .Values.replicas }}
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: {{ .Values.name }}
template:
metadata:
labels:
app: {{ .Values.name }}
spec:
containers:
- name: {{ .Values.name }}
image: {{ .Values.image }}
ports:
- containerPort: {{ .Values.HTTP_PORT }}
Docker Swarm состоит из менеджеров и воркеров. Менеджеры определяют, на каких воркерах и как будут работать контейнеры, и хранят стек нашего кластера. Контейнер крутится на воркерах.
Минимальная рабочая сущность Docker — Service, который разбивается на task, в каждом из которых — Docker-контейнер:
Чтобы запустить какой-то Service, нам нужно:
services:
proxy:
image: nginx:latest
ports:
- 80:80
- 443:443
networks:
- proxy
deploy:
replicas: 1
frontend:
image: kts/my-super-web:latest
networks:
- proxy
volumes:
- /opt/images:/usr/share/nginx/images
deploy:
placement:
constraints: [node.role == worker]
replicas: 3
networks:
proxy:
external: true
$ docker stack deploy --compose-file docker-compose.yml stackdemo
Имеет Roling Back — возможность в случае проблем откатить приложение к предыдущей версии
$ docker swarm init --advertise-addr 192.168.99.100
2 — Для присоединения виртуальных машин к кластерам:
$ docker swarm join --token %sometoken% 192.168.99.100:2377
--replicas 3 \
--publish published=8080,target=80 \
nginx
Состоит из серверов, которые определяют, где и как живут объекты оркестрации, и клиентов, на которых эти объекты крутятся.
В отличие от сервисов в Docker Swarm, в Nomad мы создаем рабочие сущности job. Они, в свою очередь, состоят из task.
Чтобы создать job, мы пишем манифест и передаем его серверу, а он уже распределяет их по клиентам.
$ nomad job run example.nomad
job "example-job" {
type = "service"
update {
stagger = "30s"
max_parallel = 1
}
group "example-group" {
count = 3
task "example-task" {
driver = "docker"
config {
image = "nginx:latest"
port_map {
http = 8080
}
}
service {
port = "http"
check {
type = "http"
path = "/"
interval = "10s"
timeout = "2s"
}
}
resources {
cpu = 500
memory = 128
network {
mbit = 100
port "http" {}
}
}
}
}
}
Шаблоны поддерживаются через consul-template.
Nomad полностью поддерживает всю экосистему HashiCorp:
Он может успешно существовать в симбиозе с Kubernetes. Вы даже можете запускать некоторые из его job прямо в Kubernetes.
У него есть Enterprise-версия: некоторые возможности платны. Например, масштабирование появилось совсем недавно и реализовано через плагины. Поддерживается оба вида горизонтального масштабирования, но вертикальное есть только в Enterprise:
datacenters = [{{list_of_datacenters}}]
type = "service"
group "{{service_name}}" {
count = {{count}}
}
task "{{service_name}}" {
driver = "docker"
config {
image = "{{docker_image}}:latest"
port_map = {
http = {{http_port}}
}
}
service {
name = "{{service_name}}"
port = "http"
}
}
}
Kubernetes ближе к понятиям фреймворка и технологии.
Openshift — скорее, готовая к использованию платформа.
Kubernetes родился в стенах Google и был передан в open source. Среди сегодняшних контрибьюторов разработки Kubernetes используют множество крупных компаний. Он работает на Linux и Windows.
Openshift работает исключительно на Red Hat Enterprise Linux. Имеет только Enterprise-версию с небольшим тестовым периодом. Помимо Kubernetes, там есть много других технологий: для доставки кода, мониторинга, сбора логов и т. д.
Способов установки Kubernetes очень много:
У обоих есть утилиты для того, чтобы их можно было «потрогать». С помощью любой из них вы можете развернуть на своей машине полноценный кластер и посмотреть, что такое Kubernetes или Openshift:
$ kind create cluster
$ k3s server &
Архитектура обоих оркестраторов непростая.
В Kubernetes кластер состоит из узлов node и Control Plane, мастер-узла.
Control Plane включает в себя:
При вертикальном масштабировании мы можем определить request, количество ресурсов, которые будут даны приложению при старте, и лимиты, до которых оно может расширяться, затрачивая больше ресурсов.
По средней нагрузке Kubernetes может следить за репликами и узлами, добавляя или уменьшая их количество. Так же он работает в облаке, покупая или продавая узлы:
Минимальная рабочая сущность обоих оркестраторов — pod: контейнер, который может быть основан и на Docker, и на cri-o, и на containerd. Но это обязательно будет контейнер, в отличие от Nomad, который может оркестрировать виртуальные машины и много чего еще.
В поде необязательно будет только один контейнер. Их может быть несколько, и они будут делить между собой сетевое дисковое пространство.
Чтобы создать под, мы пишем простой yaml-файл и либо применяем его, либо запускаем из командной строки напрямую. Для управления Kubernetes используется довольно популярная утилита Kubetail.
С помощью операторов мы можем создавать свои сущности:
PostgreSQL
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: postgres
namespace: db
spec:
teamId: postgres
volume:
size: 5Gi
numberOfInstances: 3
users:
- pg_admin
databases:
- test
- prod
postgresql:
version: "13"
resources:
requests:
cpu: 500m
memory: 1Gi
limit:
cpu: 800m
memory: 2Gi
pg_hba:
- local all all trust
- hostssl all all 0.0.0.0/0 md5
- host all all 0.0.0.0/0 md5
enableLogicalBackup: true
logicalBackupSchedule: "00 01 * * *"
RabbitMQ
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
name: rabbitmq
namespace: query
spec:
replicas: 5
resources:
requests:
cpu: 500m
memory: 1Gi
limit:
cpu: 800m
memory: 2Gi
persistence:
storage: 5Gi
image: rabbitmq:3.8.14-management
Для Postges мы описываем все необходимые параметры. Например, описываем размеры кластера, хранилища и указываем БД, которые создадутся у пользователей.
Из таблички видно, почему именно Kubernetes — стандарт в отрасли:
Недостатки Docker Swarm были очевидны, и было ясно, что в долгосрочной перспективе нам он точно не подойдет. Мы деплоим большое количество приложений, не связанных друг с другом в каких-то местах. Нам нужно dev-, stage- и prod-окружение, а оперировать этим с помощью Docker Swarm сложно.
Но у нас была уже существующая архитектура, в которой не использовался какой-то из оркестраторов. Мы пользовались SaltStack для деплоя приложений на наши сервера, т.е. устанавливали их в виде пакетов.
Мы думали, как перейти на другую технологию проще всего. В этом плане был очень привлекателен Nomad, потому что он может запускать на машине те или иные задачи. Мы думали: «Сейчас переведем деплой на Nomad, а потом, может быть, начнем использовать Docker-контейнеры и будем жить еще как-то».
Но подумав еще немного, мы пришли к выводу, что у Nomad много подвижных частей и не такое большое сообщество. Главные причины, по которым мы выбрали Куб, были:
Переход был непростой. Многое нам пришлось написать с нуля, перевести все манифесты в Docker. Где-то за полгода мы перевезли все проекты на новую технологию. С тех пор мы живем в Kubernetes. Конечно, у нас есть отдельные серверы, связанные с какими-то БД, которые деплоятся отдельно, но сами приложения почти полностью живут в Kubernetes.
habr.com
В этой статье я рассмотрю различные оркестраторы и объясню, почему Kubernetes — лучший выбор.
Нашей компании уже 6 лет, и 4 из них мы живем с Kubernetes. До этого мы испытали все варианты деплоя приложений на серверах: начиная от простого git pull до ci/cd на нескольких серверах.
За небольшой срок в 4 года мы набрали много опыта. Начинали с вопроса, который, возможно, стоит сейчас перед вами: «Какой оркестратор выбрать?» Мы рассмотрели разные варианты, и в итоге остановились на Kubernetes. В статье расскажу, почему.
Что такое оркестратор и какие задачи он решает
Наверняка многие слышали про микросервисную архитектуру.Большинство микросервисов — это контейнеры, которые должны связно работать между собой. Кроме контейнеров, это могут быть обычные приложения: например, на Java или виртуальной машине.
Оркестратор позволяет управлять всем этим централизованно:
Что должно быть в хорошем удобном оркестраторе:
- Возможность быстро начать работать, чтобы не тратить полгода на изучение и тестирование
- Набор определенных возможностей из коробки:
- управление секретами — передавать приложению пароли, токены, доступы к БД, а не хранить все в коде
- service discovery — подключать новые реплики приложения к инфраструктуре
- возможности кастомизации кластера — для добавления своих сущностей и организации API для наших целей
- Наименьший vendor lock-in: когда разработчики завязывают покупателя на конкретную технологию, и переход от одного поставщика к другому сопровождается большими сложностями
- Горизонтальное масштабирование: автоматическое масштабирование узлов кластера и приложения. Нагрузка может быть нелинейной, поэтому оркестратор должен уметь увеличить количество реплик приложения в процессе работы. Если в кластере не хватает ресурсов, нужно соответственное увеличение количества узлов кластера:
Вертикальное масштабирование: кластер управляет ресурсами, которые выделяются приложению. Выделять и ограничивать ресурсы необходимо, чтобы не столкнуться с такими ситуациями, когда одно из приложений съело всю память и CPU на наших серверах, а другим ничего не осталось. Оркестратор понимает, какие лимиты ресурсов есть у приложения на старте, и до каких оно может подниматься.
- Разные стратегии обновления приложения. Приложения постоянно обновляются. Чтобы это проходило незаметно для пользователя и бизнеса, а сами обновления не ломались в процессе, оркестраторы имеют для этого разные стратегии:
- Rolling — новая версия приложения выкатывается постепенно. Например, у нас есть 5 реплик приложения, которые постепенно заменяют исходное, пока, наконец, версия полностью не заменится на новую.
- Recreate — достаточно простая стратегия, когда мы просто убиваем старую версию и раскатываем новую.
- Blue/Green — мы выкатываем на стенды сразу 2 версии приложения: пока одна работает, вторая тестируется и со временем заменяет первую.
- Canary (Dark) — достаточно похожа на Blue/Green, но с одной особенностью. Новая версия сначала выкатывается для ограниченного числа пользователей. В случае отсутствия проблем мы постепенно заменяем на новую версию все приложение.
- Инфраструктура как код (IaC) с механизмами шаблонизации — удобная вещь, позволяющая хранить состояния приложения, описанные кодом, в каких-то манифестах. Удобно для инженеров и новичков. Когда в компанию приходит новичок, ему очень просто познакомиться с инфраструктурой и понять, где, что и как настроено. Все это удобно версионируется. Шаблонизация нужна, чтобы переиспользовать манифесты и не писать каждый раз одинаковые вещи. Например, мы подставляем разные значения в заготовленные шаблоны и меняем версии приложения:
kind: Deployment
metadata:
name: {{ .Values.name }}
namespace: {{ .Values.namespace }}
labels:
app: {{ .Values.name }}
spec:
replicas: {{ .Values.replicas }}
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: {{ .Values.name }}
template:
metadata:
labels:
app: {{ .Values.name }}
spec:
containers:
- name: {{ .Values.name }}
image: {{ .Values.image }}
ports:
- containerPort: {{ .Values.HTTP_PORT }}
- Крупное сообщество — залог жизни технологии и разнообразия инструментов. Пока есть сообщество, мы понимаем, что технология будет жить.
Docker Swarm
Оркестратор, встроенный в Docker.
Архитектура и описание
Docker Swarm состоит из менеджеров и воркеров. Менеджеры определяют, на каких воркерах и как будут работать контейнеры, и хранят стек нашего кластера. Контейнер крутится на воркерах.
Минимальная рабочая сущность Docker — Service, который разбивается на task, в каждом из которых — Docker-контейнер:
Чтобы запустить какой-то Service, нам нужно:
- запустить yaml-файл, который очень похож на Docker Compose. Отличие только в нескольких параметрах, характерных для Swarm. Например, replicas
- выполнить команду, которая очень похожа на команду для Docker Compose
services:
proxy:
image: nginx:latest
ports:
- 80:80
- 443:443
networks:
- proxy
deploy:
replicas: 1
frontend:
image: kts/my-super-web:latest
networks:
- proxy
volumes:
- /opt/images:/usr/share/nginx/images
deploy:
placement:
constraints: [node.role == worker]
replicas: 3
networks:
proxy:
external: true
$ docker stack deploy --compose-file docker-compose.yml stackdemo
Плюсы
- Полностью бесплатен
- Нетребователен к ресурсам
Имеет Roling Back — возможность в случае проблем откатить приложение к предыдущей версии
- Низкий уровень входа: прост в первоначальной настройке. Нужно запустить всего две команды:
$ docker swarm init --advertise-addr 192.168.99.100
2 — Для присоединения виртуальных машин к кластерам:
$ docker swarm join --token %sometoken% 192.168.99.100:2377
Минусы
- Работает только с Docker-контейнерами.
- Совершенно не поддерживает автоматическое масштабирование. Количество реплик приложения необходимо создавать руками в параметре replicas:
--replicas 3 \
--publish published=8080,target=80 \
nginx
- Поддерживает только одну стратегию обновления — Rolling Update.
- Малая поддержка сообщества. Многие слышали фразу «Docker Swarm мертв». Технология непопулярна у специалистов, у нее малое количество готовых решений.
- Язык манифестов мы пишем на yaml, но у Docker Swarm нет встроенной поддержки шаблонов.
Nomad
Оркестратор от компании HashiCorp.
Архитектура и описание
Достаточно похож на Docker Swarm:
Состоит из серверов, которые определяют, где и как живут объекты оркестрации, и клиентов, на которых эти объекты крутятся.
В отличие от сервисов в Docker Swarm, в Nomad мы создаем рабочие сущности job. Они, в свою очередь, состоят из task.
Чтобы создать job, мы пишем манифест и передаем его серверу, а он уже распределяет их по клиентам.
job "example-job" {
type = "service"
update {
stagger = "30s"
max_parallel = 1
}
group "example-group" {
count = 3
task "example-task" {
driver = "docker"
config {
image = "nginx:latest"
port_map {
http = 8080
}
}
service {
port = "http"
check {
type = "http"
path = "/"
interval = "10s"
timeout = "2s"
}
}
resources {
cpu = 500
memory = 128
network {
mbit = 100
port "http" {}
}
}
}
}
}
Шаблоны поддерживаются через consul-template.
Nomad полностью поддерживает всю экосистему HashiCorp:
- Vault для хранения секретных паролей, токенов и прочего.
- Consult для авто-discovery и dns.
- Terraform для управления конфигурацией.
Он может успешно существовать в симбиозе с Kubernetes. Вы даже можете запускать некоторые из его job прямо в Kubernetes.
У него есть Enterprise-версия: некоторые возможности платны. Например, масштабирование появилось совсем недавно и реализовано через плагины. Поддерживается оба вида горизонтального масштабирования, но вертикальное есть только в Enterprise:
Плюсы
- Одно из главных отличий Nomad от других оркестраторов — он может оркестрировать не только Docker-контейнеры. И вообще не только контейнеры. Это могут быть и виртуальные машины, и бинарники Java, и даже Amazon Elastic Container Service.
- Работает на всех популярных ОС.
- Нетребователен к ресурсам — примерно как Docker Swarm.
- Низкий уровень входа — прост в первоначальной настройке. Чтобы запустить, нужно:
- Установить пакет Nomad.
- Структурировать серверы: в основном нужно только указать адреса машин, на которых он будет работать.
- Запустить Nomad.
- Описывая job, в строке driver = “docker” мы запускаем Docker-контейнер и описываем какой-то config, связанный с Docker. Прелесть Nomad в том, что, поскольку он умеет запускать не только Docker-контейнеры, описание job практически не будет меняться. Например, вы запускаете какую-то job как systemd.service, или у вас Java-приложение. Вы описываете job и запускаете ее у себя на сервере. Если в какой-то момент вы решаете перейти на Docker, вам не нужно будет переписывать job глобально — только заменить driver и немного изменить структуру деплоя, но процесс описания манифеста останется.
- Поддерживаются все популярные и нужные стратегии обновления, описанные в начале статьи.
Минусы
- Малое количество возможностей из коробки:
- Нет ни load balancing, ни автомасштабирования, ни возможности добавления кастомных контроллеров.
- Малая поддержка сообщества. Чуть больше, чем у Docker Swarm, но все равно невелика. Хотя за рубежом Nomad довольно популярен.
- Манифесты пишутся на малораспространенном среди инженеров языке HCL. Если вы хотите использовать Nomad, придется с ним познакомиться:
datacenters = [{{list_of_datacenters}}]
type = "service"
group "{{service_name}}" {
count = {{count}}
}
task "{{service_name}}" {
driver = "docker"
config {
image = "{{docker_image}}:latest"
port_map = {
http = {{http_port}}
}
}
service {
name = "{{service_name}}"
port = "http"
}
}
}
Kubernetes и Openshift
Kubernetes — открытый проект для оркестрирования контейнеризированных приложений.
OpenShift — семейство программных продуктов для контейнеризации, разработанное Red Hat.
Архитектура и описание
Эти оркестраторы мы сравниваем вместе, потому что «под капотом» Openshift находится Kubernetes.Kubernetes ближе к понятиям фреймворка и технологии.
Openshift — скорее, готовая к использованию платформа.
Kubernetes родился в стенах Google и был передан в open source. Среди сегодняшних контрибьюторов разработки Kubernetes используют множество крупных компаний. Он работает на Linux и Windows.
Openshift работает исключительно на Red Hat Enterprise Linux. Имеет только Enterprise-версию с небольшим тестовым периодом. Помимо Kubernetes, там есть много других технологий: для доставки кода, мониторинга, сбора логов и т. д.
Способов установки Kubernetes очень много:
- поставить руками, устанавливая бинарники Kubernetes на серверы, и самому решая вопросы с выпуском сертификатов и их обновлениями
- передать это относительно автоматизированным инструментам, таким как kubespray и kubeadm
- использовать managed-решения
У обоих есть утилиты для того, чтобы их можно было «потрогать». С помощью любой из них вы можете развернуть на своей машине полноценный кластер и посмотреть, что такое Kubernetes или Openshift:
- Kubernetes: minikube, kind, k3s
$ kind create cluster
$ k3s server &
- Openshift: minishift
Архитектура обоих оркестраторов непростая.
В Kubernetes кластер состоит из узлов node и Control Plane, мастер-узла.
Control Plane включает в себя:
- kube-api-server, это центральная точка входа для всех компонентов Kubernetes и людей, которые работают с кластером. Он предоставляет api для управления кластером
- kube-controller-manager управляет контроллерами, например, node controller, который следит за node, или replica controller, который следит за количеством подов, развернутых в нашем кластере
- kube-sheduler определяет, когда и на каком узле будет работать под
- хранилище etcd, в котором хранятся состояния кластера в формате ключ-значение
- cloud-contoller — его наличие опционально. Он следит за контроллерами определенного публичного или приватного облака
- kubelet, который разворачивает и следит за контейнерами
- kube-proxy, который занимается сетью: настраивает сеть и сетевые правила так, чтобы поды на разных узлах могли друг с другом общаться
При вертикальном масштабировании мы можем определить request, количество ресурсов, которые будут даны приложению при старте, и лимиты, до которых оно может расширяться, затрачивая больше ресурсов.
По средней нагрузке Kubernetes может следить за репликами и узлами, добавляя или уменьшая их количество. Так же он работает в облаке, покупая или продавая узлы:
Минимальная рабочая сущность обоих оркестраторов — pod: контейнер, который может быть основан и на Docker, и на cri-o, и на containerd. Но это обязательно будет контейнер, в отличие от Nomad, который может оркестрировать виртуальные машины и много чего еще.
В поде необязательно будет только один контейнер. Их может быть несколько, и они будут делить между собой сетевое дисковое пространство.
Чтобы создать под, мы пишем простой yaml-файл и либо применяем его, либо запускаем из командной строки напрямую. Для управления Kubernetes используется довольно популярная утилита Kubetail.
С помощью операторов мы можем создавать свои сущности:
PostgreSQL
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: postgres
namespace: db
spec:
teamId: postgres
volume:
size: 5Gi
numberOfInstances: 3
users:
- pg_admin
databases:
- test
- prod
postgresql:
version: "13"
resources:
requests:
cpu: 500m
memory: 1Gi
limit:
cpu: 800m
memory: 2Gi
pg_hba:
- local all all trust
- hostssl all all 0.0.0.0/0 md5
- host all all 0.0.0.0/0 md5
enableLogicalBackup: true
logicalBackupSchedule: "00 01 * * *"
RabbitMQ
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
name: rabbitmq
namespace: query
spec:
replicas: 5
resources:
requests:
cpu: 500m
memory: 1Gi
limit:
cpu: 800m
memory: 2Gi
persistence:
storage: 5Gi
image: rabbitmq:3.8.14-management
Для Postges мы описываем все необходимые параметры. Например, описываем размеры кластера, хранилища и указываем БД, которые создадутся у пользователей.
Из таблички видно, почему именно Kubernetes — стандарт в отрасли:
Плюсы
- Просто запустить в публичных облаках.
- Из коробки Kubernetes поддерживает только две стратегии обновлений: Rolling и Recreate. Но с помощью расширений в него легко можно добавить и Blue/Green, и Canary.
- Поддерживает Rollback: следит за статусом пода и health-check — это команды, которые можно настроить, чтобы помочь Kubernetes лучше понимать, что происходит с приложением. В случае проблем он тоже откатится до предыдущей версии.
- Kubernetes позволяет описывать свои манифесты на yaml и JSON. yaml предпочтительнее, им пользуется большинство.
- С помощью пакетного менеджера Helm доступна достаточно продвинутая модернизация манифестов. Мы можем использовать циклы, редактирование строк и т. д.
- У Kubernetes большое количество встроенных возможностей. Здесь есть все необходимое, что требуется от оркестратора, к тому же есть возможность постоянно расширять его возможности с помощью кастомного API, сетевых плагинов, инструментов для установки и управления кластеров и т. д.:
- Kubernetes имеет развитое сообщество, очень заинтересованное в технологии. Можно решить практически любую проблему, или найти инженера, который будет работать с Kubernetes.
- Одновременный плюс и минус Openshift — то, что платформа выбрана за вас. С одной стороны, можно сразу взять ее и пользоваться, а с другой — не факт, что она лучше всего подойдет именно вам. Возможно, придется ставить что-то рядом и пользоваться всем по частям. Поэтому тут присутствует vendor lock-in: переехать с Openshift на какой-то другой оркестратор будет достаточно проблематично.
- Т.к. это Enterprise, у Openshift есть коммерческая поддержка. У Kubernetes ее нет, зато есть большое сообщество open source, хорошая подробная документация и множество статей и книг. К тому же огромный выбор технологий для пользователя.
- Openshift предлагает встроенную поддержку шаблонов.
Минус
Оба достаточно сложны для самостоятельной установки.Как начать использовать Kubernetes
Для начала есть несколько вариантов:- Очевидно, нужно просто начать его использовать.
- Попробовать Managed-версии у разных облачных провайдеров.
- Обратиться к компаниям, специализирующимся на эксплуатации k8s.
- Пройти специализированные курсы по эксплуатации.
Заключение: как это было у нас
Очевидно, что уровень входа в Kubernetes или Openshift — выше, чем в какие-то другие решения. Но в конечном счете это выигрышный вариант. Когда мы выбирали оркестратор, в конце концов остановились на двух вариантах: Kubernetes или Nomad.Недостатки Docker Swarm были очевидны, и было ясно, что в долгосрочной перспективе нам он точно не подойдет. Мы деплоим большое количество приложений, не связанных друг с другом в каких-то местах. Нам нужно dev-, stage- и prod-окружение, а оперировать этим с помощью Docker Swarm сложно.
Но у нас была уже существующая архитектура, в которой не использовался какой-то из оркестраторов. Мы пользовались SaltStack для деплоя приложений на наши сервера, т.е. устанавливали их в виде пакетов.
Мы думали, как перейти на другую технологию проще всего. В этом плане был очень привлекателен Nomad, потому что он может запускать на машине те или иные задачи. Мы думали: «Сейчас переведем деплой на Nomad, а потом, может быть, начнем использовать Docker-контейнеры и будем жить еще как-то».
Но подумав еще немного, мы пришли к выводу, что у Nomad много подвижных частей и не такое большое сообщество. Главные причины, по которым мы выбрали Куб, были:
- Большое сообщество.
- better is included: в Kubernetes уже все есть и по большей части ничего не нужно додумывать. Естественно, есть большое количество вещей, которое нужно доделать в каждом кластере: для работы с tls-сертификатами, для более прозрачного удобного деплоя, может быть, service machine — все это не встроено, но существует большое количество уже разработанных решений.
Переход был непростой. Многое нам пришлось написать с нуля, перевести все манифесты в Docker. Где-то за полгода мы перевезли все проекты на новую технологию. С тех пор мы живем в Kubernetes. Конечно, у нас есть отдельные серверы, связанные с какими-то БД, которые деплоятся отдельно, но сами приложения почти полностью живут в Kubernetes.
Kubernetes и другие оркестраторы
Привет! Меня зовут Леонид, я DevOps-инженер в компании KTS. В этой статье я рассмотрю различные оркестраторы и объясню, почему Kubernetes — лучший выбор. Нашей компании уже 6 лет, и 4 из них мы живем...
habr.com