🥇О растущей популярности Kubernetes

Привет, Хабр!

В конце лета мы хотим напомнить, что продолжаем проработку темы Kubernetes и решили опубликовать статью со Stackoverflow, демонстрирующую состояние дел в этом проекте на начало июня.

Приятного чтения!

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

Контейнеры зародились как специальная конструкция для изоляции процессов в Linux; в состав контейнеров с 2007 входят cgroups, а с 2002 – пространства имен. Контейнеры оформились еще лучше к 2008 году, когда стала доступна LXC, а в Google разработали свой внутрикорпоративный механизм под названием Borg, где «вся работа ведется в контейнерах». Отсюда перенесемся в 2013, когда состоялся первый релиз Docker, и контейнеры окончательно перешли в разряд популярных массовых решений. На тот момент основным инструментом для оркестрации контейнеров был Mesos, хотя, бешеной популярностью он не пользовался. Первый релиз Kubernetes состоялся 2015 году, после чего этот инструмент де-факто стал стандартом в области оркестрации контейнеров.

Чтобы попытаться понять, почему так популярен Kubernetes, давайте попробуем ответить на несколько вопросов. Когда в последний раз разработчикам удавалось прийти к согласию о том, как развертывать приложения в продакшене? Сколько вы знаете разработчиков, использующих инструменты в том виде, как они предоставляются «из коробки»? Сколько сегодня таких облачных администраторов, которые не понимают, как работают приложения? Ответы на эти вопросы мы рассмотрим в данной статье.

Инфраструктура как YAML

В мире, который от Puppet и Chef пришел к Kubernetes, одна из самых больших перемен заключалась в переходе от «инфраструктуры как код» к «инфраструктуре как данные» — конкретно, как YAML. Все ресурсы в Kubernetes, к которым относятся поды, конфигурации, развернутые экземпляры, тома и др. можно легко описать в файле YAML. Например:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

С таким представлением специалистам по DevOps или SRE удобнее полностью выражать свои рабочие нагрузки, без необходимости писать программный код на таких языках как Python или Javascript.

Другие достоинства организации инфраструктуры как данных, в частности, таковы:

GitOps или контроль версий Git Operations Version. Такой подход позволяет держать все YAML-файлы Kubernetes в репозиториях git, благодаря чему вы в точности можете отследить, когда было внесено изменение, кто его внес, и что именно изменилось. Благодаря этому повышается прозрачность операций в пределах всей организации, повышается эффективность работы в силу устранения неоднозначности, в частности, в том, где сотрудники должны искать нужные им ресурсы. В то же время, становится проще автоматически вносить изменения в ресурсы Kubernetes – путем обычного слияния pull-запроса.
Масштабируемость. Когда ресурсы определены в виде YAML, операторам кластера становится чрезвычайно просто изменить одно или два числа в ресурсе Kubernetes, изменив тем самым принципы его масштабирования. В Kubernetes предусмотрен механизм для горизонтального автомасштабирования подов, при помощи которого удобно определять, каково минимальное и максимальное количество подов, которое требуется в конкретной развернутой конфигурацией, чтобы справляться с низким и высоким уровнем трафика. Например, если вы развернули конфигурацию, для которой требуются дополнительные мощности из-за резкого всплеска трафика, то показатель maxReplicas можно изменить с 10 на 20:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Безопасность и управление. YAML отлично подходит для оценки того, как те или иные вещи развертываются в Kubernetes. Например, серьезная проблема, связанная с обеспечением безопасности, касается того, запускаются ли ваши рабочие нагрузки из-под пользователя, не обладающего правами администратора. В данном случае нам могут пригодиться такие инструменты как conftest, валидатор YAML/JSON, плюс Open Policy Agent, валидатор политик, позволяющий убедиться, что контекст SecurityContext ваших рабочих нагрузок не позволяет контейнеру работать с привилегиями администратора. Если требуется это обеспечить, пользователи могут применить простую политику rego, вот так:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

Варианты интеграции с облачным провайдером. Одна из наиболее заметных тенденций в современных высоких технологиях – запускать рабочие нагрузки на мощностях общедоступных облачных провайдеров. При помощи компонента cloud-provider Kubernetes позволяет любому кластеру интегрироваться с тем облачным провайдером, на котором он работает. Например, если пользователь запустил приложение в Kubernetes на AWS и хочет открыть доступ к этому приложению через сервис, облачный провайдер помогает автоматически создать сервис LoadBalancer, который автоматически предоставит балансировщик нагрузки Amazon Elastic Load Balancer, чтобы перенаправить трафик в поды приложений.

Расширяемость

Kubernetes очень хорошо расширяется, и это нравится разработчикам. Существует набор имеющихся ресурсов, таких, как поды, развертки, StatefulSets, секреты, ConfigMaps, т.д. Правда, пользователи и разработчики могут добавлять и другие ресурсы в форме пользовательских определений ресурсов.

Например, если мы хотим определить ресурс CronTab, то могли бы сделать нечто подобное:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

Позже мы можем создать ресурс CronTab приблизительно таким образом:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Еще один вариант расширяемости в Kubernetes заключается в том, что разработчик может писать собственные операторы. Оператор – это особый процесс в кластере Kubernetes, работающий по паттерну «контур управления». При помощи оператора пользователь может автоматизировать управление CRD (собственными определениями ресурсов), обмениваясь информацией с Kubernetes API.

В сообществе есть несколько инструментов, при помощи которых разработчикам удобно создавать собственные операторы. Среди них — Operator Framework и его Operator SDK. Этот SDK предоставляет основу, отталкиваясь от которой, разработчик может очень быстро приступить к созданию оператора. Скажем, можно начать с командной строки примерно таким образом:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

Так создается весь стереотипный код для вашего оператора, в том числе, файлы YAML и код на Golang:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

Затем можно добавлять нужные API и контроллер, вот так:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

После чего, наконец, собрать оператор и отправить его в реестр вашего контейнера:

$ operator-sdk build your.container.registry/youruser/myapp-operator

Если разработчику требуется еще более полный контроль, то можно изменить стереотипный код в файлах на Go. Например, чтобы видоизменить специфику контроллера, можно внести изменения в файл controller.go.

Другой проект, KUDO, позволяет создавать операторы, пользуясь одними лишь декларативными YAML-файлами. Например, оператор для Apache Kafka будет определяться примерно так. С его помощью можно всего лишь парой команд установить кластер Kafka поверх Kubernetes:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

А затем настроить его при помощи еще одной команды:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

Инновации

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

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

Сообщество

Еще один серьезный аспект популярности Kubernetes заключается в силе его сообщества. В 2015 году, по достижении версии 1.0, Kubernetes спонсировался Cloud Native Computing Foundation.

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

Фонд Cloud Native Foundation также проводит CloudNativeCon/KubeCon, которая, на момент написания этого текста, является крупнейшей опенсорсной конференцией в мире. Как правило, она проводится три раза в год и собирает тысячи профессионалов, желающих улучшить Kubernetes и его экосистему, а также освоить новые возможности, появляющиеся каждые три месяца.

Более того, в Cloud Native Foundation есть Комитет по техническому надзору, который, совместно с SIGs рассматривает новые и имеющиеся проекты фонда, ориентированные на облачную экосистему. Большинство из этих проектов помогают улучшить сильные стороны Kubernetes.

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

Будущее

Один из основных вызовов, с которыми разработчикам придется иметь дело в будущем, является умение сосредотачиваться на деталях самого кода, а не на той инфраструктуре, в которой он работает. Именно этим тенденциям отвечает бессерверная архитектурная парадигма, являющаяся сегодня одной из ведущих. Уже существуют продвинутые фреймворки, например, Knative и OpenFaas, которые используют Kubernetes для абстрагирования инфраструктуры от разработчика.

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

Источник: habr.com