Kubernetes как профстандарт работы с контейнерами


Оглавление (нажмите, чтобы открыть):

Записки программиста

Быстрое введение в Kubernetes

Kubernetes (часто сокращают до k8s) — открытая система оркестрации контейнеров, представленная компанией Google в 2014 году. Kubernetes реализует идею, ранее использованную во внутренней системе Google под названием Borg [PDF] . Если вкратце, идея состоят в том, что ваш деплоймент строится на базе контейнеров (например, Docker), а также описании того, сколько этих контейнеров нужно и какие ресурсы они используют. Kubernetes на базе этого описания и доступных физических машин разворачивает контейнеры и делает все возможное для поддержания требуемой конфигурации. В том числе, он перезапускает упавшие контейнеры, перемещает их для выделения ресурсов, необходимых новым контейнерам, и так далее.

Зачем это нужно?

Другими словами, используется декларативный подход — мы описываем, что требуется достичь, а не как. Из преимуществ данного подхода можно отметить следующие. Система сама себя восстанавливает в случае сбоев. У вас не болит голова о том, на какой физической машине запущен тот или иной контейнер, и куда его перенести, чтобы запустить новый тяжелый сервис. Система становится повторяемой. Если у вас все развернулось и работает в тестовом окружении, вы можете с хорошей долей уверенности сказать, что оно развернется в точно такую же систему и на продакшене. Наконец, система становится версионируемой. Если что-то пошло не так, вы можете достать из Git‘а старую конфигурацию и развернуть все в точности, как было раньше.

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

Цель этой заметки как раз заключается в том, чтобы помочь вам составить собственное мнение о кубере, и понять, нужен ли он вам.

Подготовка к эксперименту

Самый простой способ познакомиться с Kubernetes — это установить Docker Desktop. На момент написания этих строк Docker Desktop был доступен в виде пакетов только для Windows и MacOS. Как альтернативный вариант, вы можете зарегистрироваться в Digital Ocean по моей реферальной ссылке, чтобы воспользоваться Kubernetes as a Service. Ссылка дает некоторую сумму денег на счету, которой за глаза хватит, чтобы наиграться с кубером.

Также понадобится установить утилиту kubectl. Ее установка в разных системах описана здесь. Например, в MacOS достаточно сказать:

Если вы решили воспользоваться Docker Desktop, включите Kubnernetes в меню Preferences… → Kubernetes. Также рекомендую сразу увеличить количество ресурсов, выделенных под Docker и Kubernetes, так как по умолчанию ресурсов этих немного. Сделать это можно во вкладке Advanced.

Если же вы выбрали вариант с Digital Ocean, или используете любого другого провайдера Kubernetes в виде сервиса, то вам будет предложено скачать файл конфигурации. После этого нужно сказать:

Независимо от того, какой кубер вы решили использовать, теперь команда:

… должна выводить список доступных физических машин. Например:

Поздравляю, можно переходить к следующим шагам. Для Docker Desktop и Digital Ocean они будут одинаковыми.

Эксперимент

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

В качестве примера рассмотрим описание простейшего deployment, состоящего из одного контейнера:

Здесь для примера я использовал образ Nginx, но вы с тем же успехом можете запускать любые другие образы. В том числе, собранные самостоятельно из Dockerfile.

Скажем куберу применить новую конфигурацию:

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

Также в списке подов появится наш первый под:

Pod в кубере является минимальной единицей развертывания. Часто в одном поде содержится один контейнер, но в общем случае в поде может содержаться и несколько контейнеров. В последнем случае эти контейнеры будут всегда разворачиваться вместе, на одной физической машине. То есть, невозможна ситуация, при которой одна половина пода развернулась на одной физической машине (ноде), а вторая — на второй физической машине.

У get pods доступны следующие полезные кючи:

# фильтрация подов по меткам
kubectl get pods -l app =nginx

# показывает внутренние IP подов
kubectl get pods -o wide

# вывод в JSON — удобно в скриптах
kubectl get pods -o json

# чтобы не зависеть от jq:
kubectl get pods -o jsonpath = ‘<.items[:].metadata.name>‘

Бывает так, что в кубере что-то почему-то не стартует. Разобраться в причине обычно помогает describe:

При желании можно зайти внутрь контейнера, сказав:

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

Под запущен, но сейчас с ним есть маленькая проблемка. К нему никак нельзя достучаться откуда-то снаружи. Чтобы исправить эту ситуацию, создадим следующий файл:

Здесь объявлен сервис с типом LoadBalancer, который находит все поды с меткой app=nginx и прокидывает порт 80 данных подов наружу.

Сертификация по Docker и Kubernetes

В настоящее время в сети появляется все большее количество запросов на сертификацию по контейнерным технологиям (поисковый запрос “docker certification”).

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

Компания Mirantis на базе своего учебного центра организовала сертификацию Mirantis Certification for Kubernetes (MCK100), которой можно подтвердить свои знания контейнерных технологий. Для тех же, кто хочет пройти эту сертификацию максимально просто, предлагается дополнительно принять участие в подготовительном online курсеKubernetes and Docker Bootcamp (KD100).

Сертификация требует у вас наличия знаний следующих тем:


  • Docker
  • Docker. Образы
  • Docker. Сети
  • Docker. Диски
  • Kubernetes. Основы
  • Kubernetes. Ресурсы
  • Kubernetes. Управление ресурсами
  • Kubernetes. Сеть
  • Kubernetes. Диск для хранения данных
  • Многоконтейнерные приложения в Kubernetes

Компания RedHat тоже предлагает подтвердить свои знания контейнерных технологий (Docker и Kubernetes) экзаменом Red Hat Certificate of Expertise in Containerized Application Development (EX276). Также как и у Mirantis, RedHat предлагает предварительное обучение Containerizing Software Applications (DO276), которое должно упростить подготовку к экзамену, знакомя вас со следующими темами:

  • Создание контейнеров при помощи Docker
  • Работа с реестрами образов Docker
  • Предоставление контейнерам СХД для хранения данных
  • Создание образов при помощи Dockerfile
  • Применение лучших практик в процессе создания образов
  • Связывание контейнеров
  • Управление контейнерами при помощи Kubernetes
  • Создание девелоперских и тестовых окружений при помощи Vagrant

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

PHPUnit тестирование – проще простого

SOAP — протокол имени мыльной оперы

Установка OpenVPN в CentOS

Виртуализация сетевых функций (NVF)

Управляем лодкой: Kubernetes

Обзор и установка

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

Компания Docker Inc. привлекла народное внимание к контейнерам с помощью маркетинговых компаний о своем прекрасном продукте (у нас есть статья о первоначальной настройке Docker). Но что интересно, Docker – не первопроходец в мире контейнеров, но они положили начало их победоносному походу по миру. Что же было в начале? А в начале были Linux контейнеры, внимание к которым также возросло после такого ажиотажа вокруг Docker контейнеров, при этом и повысив потребность к контейнерным оркестраторам.

Давайте поближе познакомимся с Кормчим – он же Kubernetes. Первоначально это являлось разработкой Google, для управления их гигантской инфраструктурой, состоящей из миллионов контейнеров. В какой-то момент Google отдал Кормчего в люди, а именно — Cloud Native Computing Foundation. На данный момент, Docker добавил Kubernetes в свои сборки как один из вариантов оркестраторов наравне с Docker Swarm.

Теперь Kubernetes также будет частью сборок Docker Community и Docker Enterprise Edition.

Общий обзор Кормчего

Пожалуй, тут нужно разъяснить: Kubernetes является греческим именем кормчего или управляющего кораблём

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

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

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

Сам Google запускает более чем 2 миллиарда контейнеров в неделю. Это почти 300 миллионов контейнеров в день с помощью своей внутренней платформы Borg. Эта платформа – предшественник Kubernetes. Все ошибки Borg были учтены и исправлены в Кормчем./

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


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

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

Посмотрите на схему с официального сайта (ссылка ниже):

Как вы видите, Kubernetes это очень сложная система (особенно если сравнивать с нативным оркестратором Docker Swarm). Чтобы понять, как он работает, необходимо сначала понять его базовые принципы.

Желаемое состояние

Желаемое состоятие (Desired state) – это один из базовых концептов Kubernetes. Вы можете указать необходимое состояние для запуска контейнеров в т.н Подах. То есть, к примеру, если контейнер почему-то перестал работать, Kubernetes заново создаст Под основываясь на указанном желаемом состоянии.

Kubernetes всегда проверяет состояние контейнеров в кластере, и этим занимается т.н Kubernetes Мастер, который является частью плоскости управления. Можно использовать объект kubectl – он напрямую взаимодействует с кластером для установки или изменения Desired State через Kubernetes API.

Объекты Kubernetes

Обратимся к официальной документации Kubernetes: объект в Kubernetes это «запись о намерениях» (record of intent) – после создания объекта, Kubernetes будет постоянно проверять наличие этого объекта. При создании объекта, вы сообщаете Кормчему как должна выглядеть загрузка вашего кластера, иначе говоря – каково его желаемое состояние.

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

  • Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе. Довольно часто (но не всегда) в поде находится только один контейнер;
  • Сервис(Service) – данный объект используется для обозначения логической суммы подов и политик, используемых для доступа к подам;
  • Раздел (Volume) – директория, которая доступна всем контейнерам внутри пода;
  • Именные пространства (Namespaces) – виртуальные кластеры, поддерживаемые физическим кластером;

Также в Kubernetes есть несколько контроллеров, которые построены на базовых объектах и они предоставляют дополнительные фичи. Ниже список данных контроллеров:

  • ReplicaSet — проверяет что какое-то количество копий подов также все время запущено;
  • Deployment — используется для смены текущего состояния на желаемое состояние;
  • StatefulSet — используется для контроля над развертыванием и доступов к разделам;
  • DaemonSet — используется для копирования пода на все ноды кластера или только на указанные ноды;
  • Job — используется для реализации какой-то задачи и прекращения существования после завершения задачи или после указанного времени
Плоскость управления в Kubernetes

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

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

Kubernetes Мастер являются частью плоскости управления, и выполняет такую же задачу по сохранению желаемого состояния во всем вашем кластере. Команда kubectl является интерфейсом для взаимодействия с мастером в кластере через API.

В документации написано: «мастер» — это группа процессов, управляющих состоянием кластера. Как правило, все эти процессы запущены одной ноде в кластере и эта нода также называется мастер-нодой. Мастер-нода также может быть реплицирована для избыточности и отказоустойчивости.

Мастер Йода рекомендует:  Как вывести текст как есть в HTML

Каждый мастер в кластере являет собой совокупность следующих процессов:

  • kube-apiserver — единственная точка управления для целого кластера. Команда cubectl взаимодействует напрямую через API;
  • kube-controller-manager — управляет состоянием кластера, управляя различными контроллерами;
  • kube-scheduler — планирует задачи на всех доступных нодах в кластере;
Ноды в Kubernetes

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

  • kubelet– интерфейс между нодой и мастером;
  • kube-proxy – сетевая прокси, через которую проходят сервисы, указанные в API на каждой ноде. Также эта прокси может совершать простой TCP и UDP проброс портов;
Установка Kubernetes

Теперь давайте посмотрим как это работает. Для этого необходимо установить Kubernetes у вас на сервере. Нужно скачать и установить Docker Community Edition версий 17.12.+ и затем для локального запуска нужно установить Minikube.

Ссылка для скачивания Docker Community Edition — здесь;
Ссылка для скачивания Minikube — тут (MiniKube)

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

Для запуска однонодного кластера достаточно лишь выполнить команду minikube start . Бадумс, вы одновременно запустили виртуальную машину, кластер и сам Kubernetes.

Для проверки установки надо ввести команду kubectl version

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

Kubernetes: разбираемся с системой управления контейнерами


Содержание статьи

С появлением Docker интерес к контейнерам вырос взрывообразно: разворачивать приложения оказалось настолько удобно, что технологию начали использовать буквально везде. Облачные сервисы уже дают быстрый доступ к большому количеству виртуальных машин, которыми нужно управлять. Поэтому без инструмента, позволяющего запускать контейнеры на множестве хостов, масштабировать и выполнять балансировку, уже не обойтись. Разберемся с решением, предложенным Google.

Проект Kubernetes

Проект Kubernetes, или K8S, стартовал в Google в 2014 году, первая публичная версия 0.1 была представлена сообществу практически через год — в июле 2015-го. Нужно, наверное, особо отметить, что разработка не начиналась с нуля. В основе K8S лежит суперсекретный (в буквальном смысле этого слова) проект Гугла Borg — фактически основа основ управления кластерами в этой корпорации, проект, наработками которого до этого гигант не особо хотел делиться. Многие из разработчиков Borg перешли в Kubernetes, а вместе с ними туда перекочевали все идеи и решения проблем — перенос контейнеров без потерь данных, балансировка нагрузки, обнаружение сервисов. То есть можно сказать, что K8S — точная копия того, что в Google создавали долгое время, но адаптированная и ориентированная к применению Docker. Сразу после анонса проекта совместно с Linux Foundation была сформирована Cloud Computing Native Foundation (CNCF), в которую вошли сама Google, Cisco, IBM, Docker и VMware. Задача CNCF — выработать единый стандарт и обеспечить взаимодействие между разработчиками.

В Kubernetes реализованы все функции, необходимые для запуска приложений на основе Docker в конфигурации с высокой доступностью (кластеры более 1000 узлов, с multi-availability и multi-region зонами): управление кластером, планирование, обнаружение сервисов, мониторинг, управление учетными данными и многое другое. Выглядит это пугающе, но вся внутренняя кухня скрыта от админа. Он просто размещает контейнеры, все остальное — забота K8S. Для реализации этого используется больше десятка сторонних взаимодействующих услуг, которые вместе обеспечивают требуемую функциональность. Например, за координацию и хранение настроек отвечает etcd, создание сетей между контейнерами — flannel. Это несколько усложняет первоначальную настройку (хотя в последних релизах это уже не так заметно), но позволяет при необходимости просто заменить любой компонент. Для состыковки служб используются разные CLI, API, которые уже совместно реализуют API более высокого уровня для сервисных функций, таких как планирование ресурсов. Нужная функциональность должна быть специально адаптирована для K8S. Например, обратиться напрямую к API Docker нельзя (точнее, можно, но очень и очень нежелательно), следует использовать Docker Compose.

Kubernetes представляет собой систему с несколькими концепциями. Многие из этих понятий проявляются как «объекты» или «ресурсы» RESTful API. Кроме общепринятых, таких как Node, Cluster и Replication controller, есть и весьма специфические.

  • Pods — единица планирования в Kubernetes. Группа или ресурс, в котором могут работать несколько контейнеров. Контейнеры из одного Pod будут запускаться на одном сервере и могут совместно использовать общие разделы. Объекты Pod описаны в так называемых PodSpec — YAML/JSON-файлах.
  • Services — набор контейнеров, которые работают вместе, обеспечивая, например, функционирование многоуровневого приложения. K8S поддерживает динамическое наименование и балансировку нагрузки Pods с помощью абстракций, гарантируя прозрачное подключение к Services по имени и отслеживая их текущее состояние.
  • Labels — пары ключ/значение, которые прикрепляются к Pod и фактически к любому объекту (сервису), позволяя их легко группировать, отбирать и назначать задания.
  • IP-per-Pod — в Borg сервисы использовали один IP и для распределения сетевых ресурсов применялись порты. Это накладывало ряд ограничений. В K8S возможно назначить каждому Pod отдельный адрес.
  • Namespaces — способ, позволяющий логически разделить единый кластер K8S на несколько виртуальных, каждый из них будет существовать в изолированном пространстве, ограниченном квотами, не влияя на других.

На всех узлах кластера minion устанавливаются агенты kubelet и kube-proxy (прокси-балансировщик). Агенты принимают из специального API сервера данные PodSpec (файл или HTTP) и гарантируют работоспособность указанных в нем объектов. Прокси обеспечивает перенаправление потоков между Pod. Мастер кластера содержит специальные компоненты — kube-controller-manager (менеджер сервисов) и kube-scheduler (планировщик), kube-apiserver, etcd и flannel. Доступ к API управления, кроме программного способа, можно получить через консольную утилиту kubectl и веб-интерфейс. С их помощью можно просматривать текущую конфигурацию, управлять ресурсами, создавать и разворачивать контейнеры.

Установка Kubernetes

Установка Kubernetes выполняется скриптом, и в процессе следует ориентироваться на официальную инструкцию, адаптировав ее к своему дистрибутиву. Она несложная, просто нужно быть очень внимательным. Мануалы из Сети работают не всегда, так как в разных версиях дистрибутива часто требуются различные действия и встречаются специфические проблемы, также разработчики по мере развития K8S меняют процесс развертывания и параметры в конфигурационных файлах. Установим в простейшем варианте K8S на одну систему master/minion в Ubuntu 14.04/16.04, так что нам не потребуются некоторые компоненты вроде сервера ключей. Перед установкой нужно составить список всех узлов и их сетевые параметры и роль. Проект предлагает исходные тексты и bash-скрипт.

Скрипт установки Kubernetes

Первый вариант дает чуть больше контроля, если что-то пойдет не так. Ставим приложения:

Для беспарольного входа генерируем ключ. Так как впоследствии понадобятся права root, то ключи генерируем для него. Все параметры оставляем по умолчанию, на запрос пароля жмем Enter.

Подтверждаем операцию и вводим свой пароль.

После этого пробуем войти. Должно пустить без запроса пароля:

Если серверов несколько, поступаем аналогично и копируем на них ключи. Несмотря на простоту, это очень важный момент. Малейшая ошибка — и дальнейшие действия ни к чему не приведут. Забираем актуальный релиз (файл большой, почти 1,5 Гбайт):

Или ветку master:

Архив содержит примеры и готовые настройки в kubernetes/cluster для самых разных конфигураций. Следует выбрать свою и запустить установочный скрипт. Так как ставим на Ubuntu, то выбираем этот вариант. Для начала нам нужно указать конфигурацию сети. Смотрим вывод ifconfig — настройку физического интерфейса и docker0 — и приступаем к настройке.

Конфигурационный файл config-default.sh

Это основные настройки, позволяющие запустить K8S. В файле также настраиваются параметры Docker и остальных компонентов, журналирование, мониторинг. Если к интернету подключение происходит через прокси, то его параметры следует прописать в PROXY_SETTING .

Теперь можно развернуть кластер.

Скрипт закачает и установит все необходимые компоненты (etcd), на все прописанные в конфиге ноды. В процессе потребуется указать пароль для управления узлом. По окончании получим сообщение Cluster validation succeeded. Причем скрипт повторно будет скачивать последний релиз K8S — чтобы не повторять это дважды, просто скопируй файл kubernetes.tar.gz в каталог kubernetes/cluster/ubuntu и подправь скрипт закачки download-release.sh .

Еще одна проблема, которую не могут устранить уже пару месяцев, — это ошибка при создании кластера:

Нужный файл расположен в каталоге kubernetes/server , его просто забыли положить на место. Это можно сделать вручную или добавить в cluster/ubuntu/download-release.sh две строки распаковки kubernetes-salt .

После чего master будет слушать на порту http://127.0.0.1:8080. Остановить кластер можно также одной командой:

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

Для управления K8S используется утилита kubectl. Настройки можно указывать прямо в командной строке или использовать заранее подготовленный YAML/JSON-файл. Чтобы было проще вводить команды, укажем в переменной PATH, где ее искать.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Хранилище: etcd

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

Краткая сводка по etcd: etcd — это кластерная база данных, в которой согласованность (consistency) считается важнее устойчивости к разделению (partition tolerance). Продукты этого класса (ZooKeeper, части Consul) созданы по образцу разработанной в Google системы под названием chubby. Они часто называются «серверами блокировок» (lock servers), поскольку могут использоваться для координирования процесса блокирования в распределенной системе, хотя я лично считаю, что это название немного сбивает с толку. Модель данных etcd (и chubby) — это иерархия ключей, в которой хранятся простые неструктурированные значения. Это похоже на файловую систему. Что интересно, в Google доступ к chubby осуществляется с помощью абстрактного интерфейса File , который может работать с файлами, хранилищами объектов и т. д. Поскольку во главе угла здесь стоит согласованность, операции записи происходят в строгом порядке, что позволяет клиентам делать атомарные модификации (atomic updates) наборов значений.

Надежное управление состоянием — это весьма непростая задача для любой системы. А в распределенной системе ситуация дополнительно усугубляется использованием таких сложных алгоритмов, как raft или paxos. Полагаясь в этом вопросе на etcd, разработчики Kubernetes могут сконцентрировать внимание на других частях системы.

Идея наблюдения (watch) в etcd (и аналогичных продуктах) очень важна для Kubernetes, где клиенты могут подписываться на изменения частей пространства имен. Как только объект наблюдения изменяется, клиент получает соответствующее уведомление. Эта функциональность может использоваться в качестве механизма координации между компонентами распределенной системы. Например, один компонент что-то записывает в etcd, а другие могут мгновенно на это изменение отреагировать.

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


Обычно клиенты держат в памяти копию части базы данных, реагируя на происходящие в ней изменения. Механизм наблюдения (watch) эффективно поддерживает этот кэш в актуальном состоянии. Если watch по каким-либо причинам не работает, клиент возвращается к механизму опроса сервера (polling), правда, ценой увеличения нагрузки, сетевого трафика и сетевой задержки.

Уровень политик: API Server

В сердце Kubernetes находится механизм с креативным названием API Server. Это единственная часть системы, которая напрямую общается с etcd. Фактически etcd — лишь деталь реализации API Server, поэтому теоретически он может быть заменен на что-то другое.

API Server — это компонент, который отвечает за политики, предоставляя ограниченный доступ к etcd. Его обязанности в определенной степени являются обобщенными и в настоящий момент находятся в процессе расщепления. Это делается для того, чтобы приспособить API Server для управления другими системами.

Основная валюта API Server — это ресурс. Доступ к ресурсам можно получить с помощью простого REST API. Большинство ресурсов имеют стандартную структуру, что позволяет получить дополнительную функциональность. Сама структура API будет описана в одной из следующих статей. Независимо от структуры API Server позволяет различным компонентам создавать, читать, записывать, обновлять ресурсы, а также наблюдать за их изменениями.

Давайте подробнее остановимся на функциях API Server:

  1. Проверка подлинности и авторизация. Система авторизации Kubernetes имеет модульную структуру. В ней есть встроенные механизмы по проверке подлинности пользователей и авторизации этих пользователей для использования ресурсов. В этой системе также предусмотрены методы для обращения к внешним сервисам (потенциально развернутым в рамках Kubernetes). Такая расширяемость характерна для Kubernetes в целом.
  2. На API Server выполняются контроллеры приема (admission controllers), которые могут отклонять и модифицировать запросы. Они позволяют применять политики и устанавливать значения по умолчанию. Именно здесь, пока клиент API Server ждет подтверждения запроса, происходит процесс валидации идущих в систему данных. Сейчас контроллеры приема являются неотъемлемой частью API Server, однако уже идет работа по их превращению в еще один механизм расширений.
  3. API Server также помогает при версионировании API, где очень важно дать представлению ресурса возможность эволюционировать. Поля будут добавляться, объявляться устаревшими, подвергаться реорганизации и трансформироваться иными способами. API Server хранит «правильное» представление ресурса в etcd и трансформирует/воспроизводит этот ресурс в зависимости от версии API. Планирование версионирования и эволюции API было основной задачей Kubernetes с самого начала проекта. Именно этот механизм позволил Kubernetes предложить неплохую политику устаревания (deprecation policy) на довольно раннем этапе своего жизненного цикла.

Важной частью API Server также является идея поддержки концепции наблюдений (watch). Это значит, что клиенты API Server могут использовать такие же способы взаимодействия, как и с etcd. Координация в Kubernetes в основном заключается в том, что один компонент пишет в API Server ресурс, за которым другой компонент ведет наблюдение. Второй компонент имеет возможность отреагировать на изменение практически мгновенно.

Бизнес-логика: Controller Manager и Scheduler

Последняя часть пазла — это код, благодаря которому все и работает. Он реализован в виде компонентов, которые взаимодействуют через API Server и сгруппированы в виде двух серверов: Controller Manager и Scheduler. Их решили разделить, чтобы они не «жульничали». Это позволяет с самого начали обеспечивать расширяемость системы, поскольку базовые ее компоненты должны так же, как и все остальные, общаться через API Server. То, что компонентов всего два, — историческая случайность. Их вполне можно было бы объединить в один большой бинарник или разбить на десяток отдельных серверов.

Мастер Йода рекомендует:  Интервью про стажировку в Facebook процесс изнутри, советы по подготовке

Эти компоненты выполняют различные функции, необходимые для работы системы. Планировщик (scheduler), например:

  • отыскивает поды, не привязанные к нодам (unbound Pods),
  • проверяет состояние кластера (кэшированного в памяти),
  • подбирает ноду, на которой есть свободное место и которая удовлетворяет другим требованиям,
  • привязывает Pod к ноде.

В Controller Manager есть код, реализующий поведение ReplicaSet. (Напомню, что ReplicaSet поддерживает заданное количество одновременно выполняющихся реплик Pod Template.) Этот контроллер мониторит ресурс ReplicaSet и набор подов, основанных на селекторе в этом ресурсе. Он создает/удаляет поды, поддерживая таким образом стабильный набор подов согласно описанию в ReplicaSet. Большинство контроллеров действуют по такому же принципу.

Node Agent: Kubelet

Наконец, есть еще и агент, который устанавливается на ноду. Он, как и любой другой компонент, аутентифицируется на API Server. Агент осуществляет наблюдение за набором подов, привязанных к его ноде, и обеспечивает выполнение этих подов. Если в отношении подов что-то меняется, агент сообщает об этом.

Типовой процесс

Для лучшего понимания работы Kubernetes давайте рассмотрим пример.

На этой диаграмме показан типичный процесс планирования пода. Здесь, правда, приведено достаточно редкое событие создания пода напрямую пользователем. Обычно же пользователь создает что-то типа ReplicaSet, и уже ReplicaSet создает поды.

  1. Пользователь с помощью API Server создает под, и API Server записывает изменения в etcd.
  2. Планировщик замечает непривязанный (unbound) под и определяет, на какой ноде его запустить. Эта связь записывается в API Server.
  3. Kubelet замечает произошедшее в наборе привязанных к его ноде подов изменение и запускает контейнер с помощью соответствующей среды выполнения (например, Docker).
  4. Kubelet отслеживает статус пода с помощью среды выполнения. Если что-то меняется, он уведомляет об этом API Server.

Итого

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

Оставляйте обратную связь по этой работе и предлагайте интересующие вас темы для будущих статей из разряда «под капотом». До меня можно достучаться здесь @jbeda и здесь @heptio.

Введение в DevOps: инфраструктура как код, использование Docker и Kubernetes

Подготовка инженеров DevOps и системных администраторов, желающих освоить принципы и технологии Infrastructure as a Code для автоматизации развертывания и управления IT инфраструктурой предприятия.

Слушатели получат знания и навыки разработки стратегии DevOps, ознакомятся с концепцией Infrastructure as a Code, практиками из разработки для создания, тестирования и управления версиями шаблонов, изучат инструменты для непрерывной интеграции (Continuous Integration, CI) и непрерывной поставки (Continuous Delivery, CD), познакомятся с микросервисной архитектурой и научатся использовать технологии docker и kubernetes для развертывания контейнеризованных приложений.

Аудитория курса: технические специалисты, инженеры DevOps и системные администраторы.

По окончании курса Вы будете уметь:

  • разрабатывать стратегии DevOps;
  • разворачивать и управлять инфраструктурой предприятия с помощью шаблонов;
  • использовать инструменты для непрерывной интеграции (Continuous Integration, CI) и непрерывной поставки (Continuous Delivery, CD);
  • использовать технологии docker и kubernetes для развертывания контейнеризованных приложений.

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

Продолжительность курса — 24 ак. ч.

Отзывы о Центре

Cлушатель: Загер Давид Константинович

Удобство организации учебного процесса от момента заказа курсов до непосредственного обучения. Информационный обмен на высшем уровне. Обратная связь с кураторами и «бумажный» документооборот организованы прекрасно.

Cлушатель: Милованов Антон Михайлович

Предварительная подготовка

Требуемая подготовка: Успешное окончание курса Linux. Уровень 1. Основы администрирования систем Debian, CentOS, Gentoo или эквивалентная подготовка.


Требуемая подготовка: Успешное окончание курса Linux. Уровень 2. Администрирование сервисов и сетей или эквивалентная подготовка.

Получить консультацию о необходимой предварительной подготовке по курсу Вы можете у наших менеджеров: +7 (495) 232-32-16.

Наличие предварительной подготовки является залогом Вашего успешного обучения. Предварительная подготовка указывается в виде названия других курсов Центра (Обязательная предварительная подготовка). Вам следует прочитать программу указанного курса и самостоятельно оценить, есть ли у Вас знания и опыт, эквивалентные данной программе. Если Вы обладаете знаниями менее 85-90% рекомендуемого курса, то Вы обязательно должны получить предварительную подготовку. Только после этого Вы сможете качественно обучиться на выбранном курсе.

Рекомендуемые курсы по специальности

Чтобы стать профессионалом, мы рекомендуем Вам вместе с этим курсом изучить:

Программа курса

Тема Ак. часов
Модуль 1. Введение
  • Основные понятия devops
  • Система контроля версий Git
  • Лабораторная работа. Инициализация репозитория Git
1 Модуль 2. Operations

  • Общие принципы и модели управления
  • Шаблоны конфигурации
  • Описание инфраструктуры с помощью Ansible
  • Развертывание инфраструктуры через terraform
  • Использование Vagrant
  • Лабораторная работа. Установка и начало работы с Ansible
4 Модуль 3. Development

  • Практики из разработки
  • API и Development kit
  • Линтеры языка и проверка кода
  • Лабораторная работа. Установка и использование Ansible-lint
4 Модуль 4. Обзор задач QA

  • Использование Unit тестов
  • Функциональное тестирование
  • Интеграционное тестирование
3 Модуль 5. Development Operations

  • Что такое Continuous Integration и Continuous Delivery

  • Обзор инструментов Continuous Integration:
    • jenkins
    • gitlab
  • Обзор инструментов Continuous Delivery:
    • ansible
    • puppet
  • Пайплайны
    • Обзор инструментов (Vagrant, Test Kitchen, Molecule, Beaker)
  • Лабораторная работа. Установка GitLab. Интеграции Jenkins и GitLab
4 Модуль 6. Docker

  • Основные понятия
  • Микросервисная архитектура
  • Собираем docker контейнер
  • Связываем контейнеры с помощью docker-compose
  • Деплоим контейнеры вручную
  • Лабораторная работа. Установка docker и работа с контейнерами
4 Модуль 7. Kubernetes

  • Обзор систем оркестрации
  • Концепции и архитектура
  • Компоненты управления Kubernetes
  • Развертывание кластера kubernetes
  • Создаем pod
  • Интеграция Kubernetes с Gitlab CI
  • Настраиваем CD в kubernetes
  • Использование пакетного менеджера Helm
  • Лабораторная работа. Использование Kubernetes для развертывания микросервисных приложений
4 Аудиторная нагрузка в классе с преподавателем 24 +12
бесплатно
По окончании обучения на курсе проводится итоговая аттестация. Аттестация проводится в виде теста на последнем занятии или на основании оценок практических работ, выполняемых во время обучения на курсе.

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

  • утренним группам с 8:30 до 10:00
  • дневным группам — по 1 ак.ч. до и после занятий (13.15-14.00, 17.10-17.55)

Расписание

Звоните по тел. +7 (495) 232-32-16

Стоимость обучения (рублей)*

Курс может быть заказан согласно ФЗ-44, ФЗ-223 (закупка/аукцион/запрос котировок/конкурсные процедуры)
с 10:00 до 17:00 Вечер или Выходные
Стандартная цена
Онлайн Индивидуальное обучение Записаться
Частные лица 17 990 17 990 17 990 127 200 **
Организации 19 990 19 990 19 990

Ваша выгода может быть 2 740 рублей


Введение в DevOps: инфраструктура как код, использование Docker и Kubernetes + DASA: Практик DevOps по организации работы команды Подготовка к экзамену DASA DevOps Professional. Уровень 2 = 33 240 руб.*
35 980 руб.

*Данное предложение действует только для частных лиц.

Документы об окончании

В зависимости от программы обучения выдаются следующие документы:

Cертификат международного образца

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

Сертификаты международного образца выводятся после окончания курса в личном кабинете слушателя.

Kubernetes

Kubernetes (K8s) – это программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Поддерживает основные технологии контейнеризации (Docker, Rocket) и аппаратную виртуализацию [1].

Зачем нужен Kubernetes

Kubernetes необходим для непрерывной интеграции и поставки программного обеспечения (CI/CD, Continuos Integration/ Continuos Delivery), что соответствует DevOps-подходу. Благодаря «упаковке» программного окружения в контейнер, микросервис можно очень быстро развернуть на рабочем сервере (production), безопасно взаимодействуя с другими приложениями. Наиболее популярной технологией такой виртуализации на уровне операционной системы считается Docker, пакетный менеджер которого (Docker Compose) позволяет описывать и запускать многоконтейнерные приложения [2].

Однако, если необходим сложный порядок запуска большого количества таких контейнеров (от нескольких тысяч), как это бывает в Big Data системах, потребуется средство управления ими – инструмент оркестрации. Именно это считается основным назначением Kubernetes.

При этом кубернетис – это не просто фреймворк для оркестрации контейнеров, а целая платформа управления контейнерами, которая позволяет параллельно запускать множество задач, распределённых по тысячам приложений (микросервисов), расположенных на различных кластерах (публичном облаке, собственном датацентре, клиентских серверах и т.д.).

Тем не менее, Kubernetes нельзя назвать классическим PaaS-решением: K8s состоит из нескольких модулей, которые можно различным образом комбинировать между собой, сохраняя ключевые функциональные возможности (развёртывание приложений, масштабирование, балансировка нагрузок, журналирование и пр.) [3].

История развития K8s

Изначально проект кубернетис был разработан корпорацией Google, одной из крупнейших Big Data компаний, для своих внутренних нужд на языке программирования Go. В середине 2014 года были опубликованы исходные коды проекта. Первый готовый релиз системы был выпущен 21 июля 2015 года (версия 1.0). Во второй половине 2015 года корпорация Google совместно с Linux Foundation организовали специальный фонд Cloud Native Computing Foundation (CNCF), которому и был передан Kubernetes в качестве начального технологического вклада [1].

Кубернетис, как и Docker, относится к технологиям виртуальной контейнеризации

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

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

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

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

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

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

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

  • 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 пытается перезапустить необходимые поды на другом узле, работающем корректно [1].

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

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

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

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

Kubernetes, Docker Swarm и Mesos: лучшее для оркестрации контейнеров


Динамика мировых продаж контейнеров, 2015-2020 гг. Источник: 451 Research

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

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

По оценкам Forrester Research, сегодня контейнеры уже получили признание у 31% корпоративного рынка. Согласно прогнозу компании 451 Research, выпущенному в начале 2020 г., мировой объем продаж контейнеров в ближайшее время будет продолжен. Если в 2020 г. он оценивался в размере 762 млн. долл., то к 2020 г. должен достигнуть уровня 2,7 млрд. долл., что соответствует среднегодовому темпу роста на уровне 40%.

Впрочем, несмотря на такую активную динамику роста, этот сегмент пока еще остается сравнительно малым по сравнению с общим рынком облачных услуг, который учитывает и другие направления, такие как системы виртуализации, частные PaaS, средства автоматизации и управления облачными услугами и пр. Его объем в 2020 г. оценивается в размере 23,1 млрд. долл.; к концу 2020 г. он достигнет 39,6 млрд. долл., что соответствует среднегодовому темпу роста на уровне 15%.

Развитие платформ для оркестрации контейнеров — одно из направлений рыночного сегмента систем виртуализации. Они служат для реализации удобных и эффективных средств развертывания контейнерных систем, выстраивания единой централизованной консоли для применения политик управления. В настоящее время наибольшей известностью пользуются такие системы, как Kubernetes, Docker Swarm и Apache Mesos. Помимо них есть и другие системы, например, Amazon EC2 Container Service или Microsoft Azure Container Service, однако с точки зрения популярности они пока уступают трем фаворитам.

Согласно опросу, проведенному среди посетителей портала SDxCentral, свой выбор системы оркестрации в пользу Kubernetes сделали 64% респондентов; 36% отдали голос за Docker Swarm и 18% — за Apache Mesos (анкета позволяла выбрать несколько вариантов ответа).

Более подробно о каждой из этих платформ рассказал Дан Мейер (Dan Meyer) старший редактор SDxCentral.

Kubernetes на вершине славы

Open Source-система Kubernetes для управления контейнерными кластерами появилась в результате наработок, которые были накоплены Google в течение 10 лет эксплуатации Borg — механизма для изоляции процессов в виртуальной среде. В 2014 г. Google открыла код Kubernetes, который был написан на языке Go, и начала распространять систему под лицензией Apache 2.0. Благодаря компании Mirantis система Kubernetes совсем скоро появилась в каталоге OpenStack в составе платформы Cloud Native Computing Foundation, развиваемой Linux Foundation, получив тем самым отличные шансы на то, чтобы быстро стать популярной среди пользователей.

Расчет Google оправдался — сегодня многие рассматривают Kubernetes как лучшее универсальное решение для работы с приложениями в облачном окружении. Платформу активно поддерживают около десятка вендоров, среди которых Mirantis, CoreOS, IBM и Red Hat.

Благодаря полученной со стороны рынка поддержке Kubernetes сегодня часто называют «идеальной платформой» для оркестрации контейнеров. Она позволяет управлять кластерами виртуальных машин и Linux-контейнеров как единым целым, находится в первых рядах списка систем, рекомендуемых для внедрения для средних и крупных предприятий.

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

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

Docker Swarm интересен СМБ

Второй крупный игрок на рынке систем оркестрации контейнеров — система Docker Swarm, и это не случайно: компания Docker была фактически первой, кто предложил действительно эффективную и удобную для корпоративного использования одноименную платформу. Ее решение, выпущенное в 2013 г., значительно упростило развертывание полноценных виртуальных систем. По сути с этого момента стало возможным легко объединять вместе тысячи ВМ, запускать тысячи изолированных друг от друга приложений, быстро выстраивая нужную конфигурацию из виртуализованных прикладных систем

Инструмент контейнерной кластеризации Docker Swarm появился немного позже и стал частью платформы Docker. С его помощью решается задача объединения Docker-хостов в общий виртуальный хост.

Вендору удалось предложить действительно элегантное решение. Docker Swarm предоставляет REST API-интерфейс, который совместим с Docker API. Поэтому все пользователи, которые ранее активно использовали Docker-инструменты, сразу получили возможность работать с контейнерными кластерами под управлением Docker Swarm, даже не волнуясь, что теперь вместо одной машины им приходится управлять сразу роем (swarm) Docker-контейнеров.

Режим Swarm интересен в первую очередь представителям малых и средних предприятий, «аппетиты» которых не выходят за рамки запуска более 50 тыс. контейнеров и до 1000 нод. Благодаря автоматической совместимости с Docker применение Swarm интересно разработчику как развитие его бизнес-модели наращивания своего облачного присутствия. Большую помощь в развитии этого направления оказывает Microsoft Azure, которая предлагает поддержку Swarm.

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

Mesos достигла поры зрелости

Третий основной игрок на рынке оркестрации контейнеров — система Apache Mesos. Появившись как исследовательский студенческий проект в Университете Беркли, она затем была собрана в полноценный продукт и впервые представлена публично в 2009 г. Apache Mesos — это централизованная отказоустойчивая система для управления кластером, позволяющая объединять в группы отдельные узлы (Mesos Slaves) согласно выставленным требованиям и в последующем обеспечивать им изоляцию от остальных ИТ-ресурсов и управление.

Сущность работы системы Mesos в определенной степени противоположна модели виртуализации. Если традиционный подход предусматривает дробление вычислительной среды, состоящей из множества физических машин, на их виртуальные аналоги с предоставлением каждой своей доли общих ресурсов ЦОДа, то Mesos наоборот объединяет существующие объекты в единый виртуальный ресурс, формируя крупные кластеры и эффективную систему управления серверной инфраструктурой с выделением каждому кластеру индивидуального пула ресурсов.

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

Главным инструментом, осуществляющим контроль за работой кластеров, являются Mesos Masters. Они занимаются предоставлением ресурсов, распределением задач между узлами Mesos Slaves, объединяющими запущенные контейнеры. Чтобы гарантировать высокий уровень доступности в системе запускается сразу несколько Mesos Masters, однако в каждый момент времени активным лидером выступает только один сервер. Логика запуска задач, мониторинг, масштабирование — эти операции находятся в распоряжении Mesos Frameworks.

Модель Apache Mesos также получила широкую поддержку среди вендоров. В качестве ОС для ЦОДов ее взяли на вооружение свыше 60 партнеров, в том числе Microsoft, HPE, Accenture, Autodesk, Cisco, Dell EMC, Equinix, Puppet и Verizon.

С точки зрения потребителей заинтересованность в Mesos проявили прежде всего компании, которым приходится работать с очень большим количеством контейнеров. Наиболее известные среди них — Twitter, eBay, Netflix, Verizon; они применяют Mesos для управления вычислительной нагрузкой в облаке и дата-центрах.

Mesosphere, разработчик этой системы, предлагает также использовать Mesos для реализации моделей типа «как сервис». В этом отношении наибольший интерес представляют сейчас совместные проекты компании с HPE.

Kubernetes как профстандарт работы с контейнерами

24 просмотра

2 ответа

512 Репутация автора

Мы используем kubernetes в GCP. У нас есть модули, которые записывают журналы на общий том, с контейнером коляски, который всасывает наши журналы для нашей системы журналирования. Мы не можем просто использовать вместо этого стандартный вывод для этого процесса.

Некоторые из этих модулей являются долгоживущими и занимают место на диске из-за отсутствия ротации журналов.

Вопрос: Какой самый простой способ предотвратить заполнение дискового пространства здесь (без планирования перезапуска модуля)?

Я пытался установить logrotate, используя: RUN apt-get install -y logrotate в нашем Dockerfile и помещая в него файл конфигурации logrotate, /etc/logrotate.d/dynamicproxy но, похоже, он не запускается. /var/lib/logrotate/status никогда не генерируется.

Я чувствую, что я лаю не на том дереве или пропускаю что-то неотъемлемое, чтобы заставить это работать. Любая помощь будет оценена.

Ответы (2)

плюса

3940 Репутация автора

Если вы пишете в файловую систему, приложение, создающее журналы, должно отвечать за ротацию. Если вы используете приложение Java с logback или log4j, это просто изменение конфигурации. Для других языков / фреймворков это обычно аналогично.

Если это не вариант, вы можете использовать специализированный инструмент для управления вращением и передачи вывода на него. Одним из примеров будет http://cr.yp.to/daemontools/multilog.html

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

Автор: Thomas Размещён: 18.04.2020 08:40

плюса

66 Репутация автора

В общем, вы должны записывать журналы в стандартный вывод и настраивать инструмент сбора журналов, такой как стек ELK. Это лучшая практика.

Однако, если вы хотите запустить logrotate как отдельный процесс в вашем контейнере — вы можете использовать Supervisor, который служит очень простой системой инициализации и позволяет запускать столько параллельных процессов в контейнере, сколько вы хотите.

Kubernetes

Kubernetes (K8s) – это программное обеспечение для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Поддерживает основные технологии контейнеризации (Docker, Rocket) и аппаратную виртуализацию [1].

Зачем нужен Kubernetes

Kubernetes необходим для непрерывной интеграции и поставки программного обеспечения (CI/CD, Continuos Integration/ Continuos Delivery), что соответствует DevOps-подходу. Благодаря «упаковке» программного окружения в контейнер, микросервис можно очень быстро развернуть на рабочем сервере (production), безопасно взаимодействуя с другими приложениями. Наиболее популярной технологией такой виртуализации на уровне операционной системы считается Docker, пакетный менеджер которого (Docker Compose) позволяет описывать и запускать многоконтейнерные приложения [2].

Однако, если необходим сложный порядок запуска большого количества таких контейнеров (от нескольких тысяч), как это бывает в Big Data системах, потребуется средство управления ими – инструмент оркестрации. Именно это считается основным назначением Kubernetes.

При этом кубернетис – это не просто фреймворк для оркестрации контейнеров, а целая платформа управления контейнерами, которая позволяет параллельно запускать множество задач, распределённых по тысячам приложений (микросервисов), расположенных на различных кластерах (публичном облаке, собственном датацентре, клиентских серверах и т.д.).

Тем не менее, Kubernetes нельзя назвать классическим PaaS-решением: K8s состоит из нескольких модулей, которые можно различным образом комбинировать между собой, сохраняя ключевые функциональные возможности (развёртывание приложений, масштабирование, балансировка нагрузок, журналирование и пр.) [3].

История развития K8s

Изначально проект кубернетис был разработан корпорацией Google, одной из крупнейших Big Data компаний, для своих внутренних нужд на языке программирования Go. В середине 2014 года были опубликованы исходные коды проекта. Первый готовый релиз системы был выпущен 21 июля 2015 года (версия 1.0). Во второй половине 2015 года корпорация Google совместно с Linux Foundation организовали специальный фонд Cloud Native Computing Foundation (CNCF), которому и был передан Kubernetes в качестве начального технологического вклада [1].

Кубернетис, как и Docker, относится к технологиям виртуальной контейнеризации

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

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

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

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

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

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

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

  • 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 пытается перезапустить необходимые поды на другом узле, работающем корректно [1].

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

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

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

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

Мастер Йода рекомендует:  Stack Overflow запустил зарплатный калькулятор, предсказывающий оклад на основе вашего опыта,
Добавить комментарий