Кластер k8s что это
Кластеры K8s в облаке на базе VMware
Контейнеризация приложений на сегодняшний день — один из самых удобных и часто используемых способов их доставки конечным пользователям. Но что делать, если существующая инфраструктура построена на VMware и хочется использовать Kubernetes? Ответ на этот вопрос в нашей новой статье.
CSE и его место в экосистеме VMware
Container Service Extension (CSE) — это расширение для VMware vCloud Director (VCD), позволяющее создавать кластеры Kubernetes (K8s) и управлять ими внутри существующей облачной инфраструктуры VMware. Важность этого сложно переоценить, ведь обеспечение доступа к кластерам K8s и управление «жизненным циклом» приложений — задача, требующая серьезного внимания.
Зачем нужен CSE
Появление системы оркестрации контейнеров, k8s, стало «философским камнем» для разработчиков и «Святым Граалем» для облачных провайдеров, предоставляющих возможность запуска контейнеризованных приложений. Несмотря на сложную архитектуру и более высокий порог вхождения (по сравнению с тем же Docker Swarm), K8s дает более широкие возможности по управлению контейнеризованной инфраструктурой.
Отлично, давайте использовать k8s! Но как быть, если бережно выстраиваемая в компании IT-инфраструктура изначально создавалась в экосистеме VMware?
Именно эту проблему и решает CSE, позволяя реализовать потребность в контейнеризованных приложениях внутри действующей инфраструктуры VMware. Это расширение позволяет создать кластер k8s в виде отдельного vApp, привычной инфраструктурной единицы, а также обеспечить локальную сетевую связность с имеющимися приложениями и сервисами.
Приведем пример. Есть компания X, которая активно использует CRM в связке с базой данных. Инфраструктура реализована в виде виртуального дата-центра в экосистеме VMware. При необходимости запуска какого-либо контейнеризованного приложения, требующего взаимодействия с этой же базой данных, не потребуется выход за пределы периметра существующей инфраструктуры.
Наша реализация
Мы уже рассказывали о нашем «Облаке на базе VMware». Кластер K8s, размещенный внутри нашей инфраструктуры, будет иметь такие же преимущества и возможность применения тех же механизмов отказоустойчивости. Legacy-приложения смогут легко взаимодействовать с контейнеризованными через общую локальную сеть.
Распределение ролей на администратора и пользователей весьма удобно, когда требуется не только использовать K8s для доставки приложений, но и обеспечить разработчиков удобной средой для тестирования кода. Пользователи не могут выполнять административные действия и взаимодействуют с кластером только при помощи kubectl. Администраторы же выполняют любые действия как внутри кластера, так и над ним.
Для развертывания и масштабирования кластера не потребуется вникать в тонкости работы K8s, поскольку все действия происходят из vcd-cli за несколько минут.
Установка расширения CSE в vcd-cli
По умолчанию vcd-cli не умеет работать с CSE, поэтому сперва необходимо установить расширение container-service-extension.
После установки расширения необходимо зафиксировать его в конфигурационном файле vcd-cli. Открываем
/.vcd-cli/profiles.yaml и добавляем после параметра active следующие строки:
Далее выполняем вход:
Теперь можно убедиться, что расширение успешно установлено и взаимодействует с сервером:
Создание кластера k8s
Интеграция с vCloud Director обеспечивает удобство управления из единой точки при помощи привычных действий и интерфейса. Внутри виртуального дата-центра используется общий пул ресурсов, а развертывание происходит из шаблонов виртуальных машин с уже установленным и настроенным k8s. Создание кластера kubernetes выполняется в одну команду:
Обратите внимание, что обязательными параметрами является название кластера и используемая сеть, остальные параметры можно опустить. По умолчанию создается 3 узла из шаблона ubuntu-16.04_k8-1.18_weave-2.6.5. Посмотреть все доступные шаблоны можно командой vcd cse template list.
В веб-интерфейсе vCloud Director созданный кластер можно видеть в разделе vApps.
Остался завершающий штрих: получить файл конфигурации для kubectl. Его можно сгенерировать следующим образом:
Для дальнейшей работы с кластером k8s размещаем файл конфигурации на нужное место:
Теперь кластер k8s готов к работе.
Особенности и ограничения реализации
На текущий момент не поддерживается тип сервиса LoadBalancer из коробки, а это означает, что манифесты K8s, использующие сервисы LoadBalancer и Ingress, не будут работать корректно. Тем не менее, есть решения данной проблемы. Допустимо использовать любую реализацию LoadBalancer и Ingress, но мы расскажем про MetalLB и ProjectContour.
MetalLB
В качестве балансировщика можно использовать MetalLB (имплементация LB, использующая стандартные протоколы маршрутизации, вместо облачных LB). Создаем пространство имен и добавляем MetalLB через манифесты:
Настраиваем безопасное общение между узлами. Если не выполнить данную команду, то все поды перейдут в статус CreateContainerConfigError, а в логах будет причина Error: secret «memberlist» not found.
Проверяем статус балансировщика. Если все настроено правильно, то контроллер и спикеры будет в статусе running.
Файл конфигурации не включен в манифест, поэтому его необходимо создать самостоятельно. Создаем metallb-config.yaml и заполняем его следующим образом:
Обратите внимание, что параметр addresses необходимо заполнять свободными адресами, которые будут использованы балансировщиком нагрузки. Применяем файл конфигурации:
LoadBalancer настроен, остался Ingress.
Project Contour
Создание Ingress реализуется в применении манифеста Project Contour.
Эта команда автоматически развернет прокси-сервер Envoy внутри нового, созданного namespace projectcontour, который будет слушать стандартные порты 80/443.
Заключение
Использование VMware Container Service Extension позволяет применить гибридный подход и объединить использование Legacy-приложений с контейнеризованными в рамках одной виртуальной инфраструктуры VMware и одного сетевого периметра. Тем самым сохраняется однородность и системный подход к управлению инфраструктурой.
VMware Container Service Extension доступен всем пользователям нашего Облака на базе VMware и предоставляется бесплатно (оплачиваются только потребляемые ресурсы).
Кластер k8s что это
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]:
Управление подами реализуется через API Kubernetes, интерфейс командной строки (Kubectl) или специализированные контроллеры (controllers) – процессы, которые переводят кластер из фактического состояния в желаемое, оперируя набором подов, определяемого с помощью селекторов меток. Селекторы меток (label selector) – это запросы, которые позволяют получить ссылку на нужный объект управления (узел, под, контейнер) [1].
На ведущем компоненте (master) работают следующие элементы [1]:
Как работает Kubernetes
Согласно концепции контейнеризации, контейнеры содержат выполняемые сервисы, библиотеки и прочие ресурсы, необходимые для работы этих приложений. Доступ к контейнеру извне реализуется через индивидуально назначаемый ему IP-адрес. Таким образом, в Kubernetes контейнер – это программный компонент самого низкого уровня абстракции. Для межпроцессного взаимодействия нескольких контейнеров они инкапсулируются в поды.
Задачей Kubernetes является динамическое распределение ресурсов узла между подами, которые на нем выполняются. Для этого на каждом узле с помощью встроенного агента внутреннего мониторинга Kubernetes cAdvisor ведется непрерывный сбор данных о производительности и использовании ресурсов (время работы центрального процессора, оперативной памяти, нагрузок на файловую и сетевую системы).
Что особенно важно для Big Data проектов, Kubelet – компонент Kubernetes, работающий на узлах, автоматически обеспечивает запуск, остановку и управление контейнерами приложений, организованными в поды. При обнаружении проблем с каким-то подом Kubelet пытается повторно развернуть и перезапустить его на узле.
Аналогично HDFS, наиболее популярной распределенной файловой системе для Big Data-решений, реализованной в Apache Hadoop, в кластере Kubernetes каждый узел постоянно отправляет на master диагностические сообщения (heartbeat message). Если по содержанию этих сообщений или в случае их отсутствия мастер обнаруживает сбой какого-либо узла, процесс подсистемы управления Replication Controller пытается перезапустить необходимые поды на другом узле, работающем корректно [1].
Принципы работы Kubernetes
Примеры использования кубернетис
Поскольку K8s предназначен для управления множеством контейнеризированных микросервисов, неудивительно, что эта технология приносит максимальную выгоду именно в Big Data проектах. Например, кубернетис используют популярный сервис знакомств Tinder [4], телекоммуникационная компания Huawei [5], крупнейший в мире онлайн-сервисом поиска автомобильных попутчиков BlaBlaCar [6], Европейский Центр ядерных исследований (CERN) [7] и множество других компаний, работающих с большими данными и нуждающимися в инструментах быстрого и отказоустойчивого развертывания приложений [3].
В связи с цифровизацией предприятий и распространением DevOps-подхода, спрос на владение Kubernetes растет и в отечественных компаниях. Как показал обзор вакансий с рекрутинговой площадки HeadHunter, в 2019 году для современного DevOps-инженера и Big Data разработчика данная технология является практически обязательной.
Kubernetes – настоящий must have для современного DevOps-инженера
Kubernetes (k8s) Tutorial — pod, кластер, node, yaml, helm
Docker и Docker-Compose Tutorial (Контейнеры, install, run, image, daemon, etc.)
Краткое введение в терминологию и архитектуру — Kubernetes (k8s) Tutorial
Kubernetes (или K8S) — это платформа с открытым исходным кодом, которая запускает контейнерные приложения. Kubernetes стал стандартом в сфере devops для масштабного развертывания контейнерных приложений в частных, общедоступных и гибридных облачных средах.
Kubernetes предоставляет базовый ресурс под названием Pod. Pod — это самая маленькая развертываемая единица в Kubernetes, которая на самом деле является оболочкой для контейнеров. Pod может иметь один или несколько контейнеров, и вы можете передать различную конфигурацию контейнеру(-ам), используя конфигурацию модуля, например, передачу переменных среды, монтируемых томов, проверки работоспособности и т.д.
Архитектура Kubernetes
На очень высоком уровне Kubernetes предоставляет набор динамически масштабируемых хостов для выполнения рабочих нагрузок с использованием контейнеров и использует набор управляющих хостов, называемых мастерами, для предоставления API для управления всей контейнерной инфраструктурой. Рабочие нагрузки могут включать в себя долго работающие службы, пакетные задания и демонов, специфичных для контейнеров. Все хосты контейнеров соединены вместе с помощью оверлейной сети для обеспечения маршрутизации от контейнера к контейнеру. Приложения, развернутые в Kubernetes, динамически обнаруживаются в сети кластера и могут быть доступны во внешних сетях с помощью традиционных балансировщиков нагрузки.
Чтобы начать работать с Kubernetes, можно использовать Minikube. Minikube — это упрощённая реализация Kubernetes, которая создает виртуальную машину на вашем локальном компьютере и разворачивает простой кластер с одним узлом. Minikube доступен для Linux, macOS и Windows. В CLI-инструменте Minikube есть основные операции для инициализации кластера, включая запуск, завершение, просмотра состояния и удаления кластера.
Модель развертывания приложений
На приведенном выше рисунке показана модель развертывания приложений высокого уровня в Kubernetes. Он использует ресурс ReplicaSet для оркестровки контейнеров.
ReplicaSet можно рассматривать как файл метаданных на основе YAML или JSON, который определяет образы контейнеров, порты, количество реплик, проверки работоспособности активации, проверки работоспособности, переменные среды, монтирование томов, правила безопасности и т.д.
Контейнеры всегда создаются в Kubernetes как группы, называемые подами (pod), которые являются Kubernetes metadata definition или resource. Каждый pod позволяет совместно использовать файловую систему, сетевые интерфейсы, пользователей операционной системы и т.д.
Основные термины, которые нужны для понимания Kubernetes
master — объект, ответственный за управление состоянием кластера. Он состоит из 3-х основных компонентов:
Kubernetes Helm
Helm — это менеджер пакетов для Kubernetes, аналог NPM или YARN. Однако это не только диспетчер пакетов, это еще и средство управления развертыванием Kubernetes. Для простоты Helm Chart можно сравнить с Docker Image.
Helm chart— это просто набор файлов шаблонов YAML, организованных в определенную структуру каталогов.
Vanilla All the Way. Ванильное облачное решение на K8s
Публикуем перевод статьи о Vanilla Stack — новой облачной open-source технологии на основе Kubernetes.
Недавно я наткнулся на стек технологий Vanilla Stack, включающий в себя множество компонентов с открытым кодом. В этой статье мы кратко рассмотрим процесс их установки и расскажем о различных вариантах использования.
Кратко о Vanilla Stack
Vanilla Stack можно определить как кластер Kubernetes с большим количеством open-source компонентов.
Как мы видим из схемы выше, юзеры могут:
Следующая схема более детальная, она содержит список всех компонентов, организованных по категориям, которые могут поставляться с Vanilla Stack:
Мне кажется, это довольно занятно! Некоторые компоненты установлены по умолчанию, другие можно выбрать во время установки.
В этой статье мы разберем основные этапы процесса установки. Для упрощения задачи мы установим Vanilla Stack на шести виртуальных машинах, подготовленных у хостера: три будут выступать в качестве главных узлов (master) Kubernetes, а остальные — в качестве рабочих (workers).
Примечание: Облачные провайдеры следует выбирать в зависимости от компонентов, которые мы хотим установить, так как некоторые из них могут не соответствовать требованиям установки. Например, чтобы установить Rook, нам нужен поставщик инфраструктуры, который предоставляет block storage.
Запускаем установку
Есть два способа установить Vanilla Stack, они описаны в разделе загрузки. Мы будем использовать установку Docker, которую можно запустить с помощью следующей команды:
Веб-интерфейс установщика доступен через порт 8080. Установку можно будет выполнить в десять несложных этапов, о которых мы расскажем далее.
Требования
Первый шаг, Start, определяет требования к оборудованию и программному обеспечению для машин, на которых будет установлен стек. В нашем случае мы будем использовать шесть виртуальных машин. Каждая из них работает на Ubuntu 20.04 и имеет 4 ГБ оперативной памяти / 2 процессора.
Как мы писали ранее, три виртуальные машины будут выступать в качестве главных узлов Kubernetes, а остальные будут рабочими.
Кроме того, нам необходимо настроить домен (и пару поддоменов) для доступа к кластеру. Мы вернемся к этому шагу позже при настройке балансировщика нагрузки.
Условия и положения
Принятие условий использования (Terms) — наш второй шаг. Обязательно ознакомьтесь с указанной информацией о лицензии.
Общие настройки
Далее идет шаг General Settings. Необходимо указать тип установки, который нам подходит: количество главных и рабочих узлов и начальную нагрузку.
В нашем случае мы выберем HA installation с тремя главными узлами, три оставшихся узла действуют как рабочие. Rook выбран по умолчанию для установки хранилища. Мы не используем OpenStack или Cloud Foundry здесь. Это может быть темой для другой статьи.
Доступ к виртуальной машине по SSH-ключу
Раздел Public Key предоставляет открытый ключ RSA, его необходимо скопировать на каждой из виртуальных машин. Этот шаг необходим, чтобы разрешить установочной машине (на которой запущен установщик) запускать Ansible playbooks для настройки каждой VM.
Примечание: Ansible — это система управления конфигурациями. Она запускает команды на машинах только через SSH-соединение. Ansible не требует установки агента в отличие от таких аналогов, как Chef и Puppet.
Инструкция по копированию ключа указана в установщике:
Определите информацию об узлах
На этапе Nodes нам нужно определить IP-адреса и пользователя каждого из узлов.
Также нам нужно определить узлы, которые запустят поды для Rook. Согласно требованиям, мы используем все три рабочих узла.
Проверка конфигурации узла
На шаге Node-Check мы проверяем, все ли узлы соответствуют требованиям.
Перед кликом на кнопку Validates Nodes важно прокрутить страницу до конца и убедиться, что мы выполняем требования Rook: к каждому узлу должно быть подключено блочное устройство (raw block device).
Нажав кнопку Validate Nodes в установщике, мы можем убедиться, что все узлы настроены корректно.
Настройки кластера
Первое, что нужно настроить на этапе Cluster-Settings, — это Pod CIDR и Service CIDR (то есть диапазоны IP, которые используются для предоставления IP-адресов подов и виртуальных IP-адресов сервисов). В нашем случае мы используем значения по умолчанию.
Кроме того, нам нужно создать балансировщик нагрузки для перенаправления трафика на главный или рабочий узел.
Из-за особенностей используемого облачного провайдера использовать один и тот же балансировщик нагрузки для перенаправления трафика на другой набор узлов не получится.
Поэтому мы создадим два балансировщика нагрузки: перед главными узлами
и перед рабочими.
Балансировщик нагрузки перед главными узлами
Первый балансировщик нагрузки необходим для доступа к серверу API кластера. Он должен быть настроен следующим образом:
В данном случае балансировщик нагрузки получает IP-адрес 159.65.211.35.
Балансировщик нагрузки перед рабочими узлами
Второй балансировщик нагрузки необходим для предоставления доступа к ingress-контроллеру кластера (компонент, дающий доступ к приложениям в кластере). Его настройки:
В данном случае балансировщик нагрузки получает IP 46.101.64.165.
Настройка DNS entries
На этом этапе мы можем предоставить IP-адрес только одного балансировщика нагрузки, но в следующих релизах установщика будет уже больше возможностей.
Настройка Let’s Encrypt
Let’s Encrypt — широко используемый бесплатный центр сертификатов. Он позволяет нам получать и автоматически обновлять сертификаты HTTPS. В Kubernetes Let’s Encrypt часто используется через Cert Manager, компонент, установленный по умолчанию в Vanilla Stack. Cert Manager может получить сертификат от Let’s Encrypt (а также из нескольких других источников) и сделать его доступным для приложения через Kubernetes Secret.
Rook Configuration
Следующие шаги позволяют выбрать компоненты Rook, которые будут установлены (в данном случае — панель управления Rook и мониторинг), а также сколько раз будут дублироваться фрагменты данных (replica level).
Установка дополнительных инструментов
В разделе Additional Tools можно указать, какие компоненты будут установлены в кластере.
Перечисленные здесь инструменты довольно распространенные. Они делятся на разные категории:
Это удобный способ установить все компоненты из одного места. Также их можно будет установить позже, если на данном этапе они не выбраны.
Подписка
Если мы хотим подписаться на коммерческую поддержку, то на этом шаге можем получить всю необходимую информацию.
Поддержка предоставляется сервисом Cloudical. Он поддерживает Vanilla Stack и предоставляет Vanilla Cloud, новый управляемый вариант стека.
Проверка всех шагов
Здесь мы можем просмотреть и изменить (при необходимости) параметры конфигурации.
Прежде чем перейти к следующему шагу и установить весь стек, нам нужно убедиться, что
/etc/apt/sources.list правильно настроен на каждом узле и содержит официальные репозитории.
Примечание: Этот шаг необходим, например, если Ansible недоступен из репозиториев, предоставленных по умолчанию.
Самый простой способ исправить это — заменить содержимое /etc/apt/sources.list следующими инструкциями:
Установка
Теперь все готово и мы можем запустить установку под чашечку чая.
В журналах установки мы видим, что на каждой виртуальной машине применились Ansible playbooks, которые:
Установка всего стека не займет много времени.
Примечание: При установке стека я столкнулся с небольшой проблемой, обусловленной особенностями используемого облачного провайдера: балансировщик нагрузки перенаправляет трафик на внутренний IP-адрес узла вместо общедоступных. Ingress контроллер доступен на внешнем IP-адресе узлов, поэтому рабочие узлы помечаются как неисправные, что неправильно.
Доступ к кластеру
Как обычно, мы начинаем с перечисления узлов нашего кластера:
Кроме того, мы можем проверить все поды, работающие в кластере, а также сервисы, предоставляющие их.
Похоже, всё работает! Следующим шагом может быть тестовый запуск, например, stateful-приложения, которое:
Итоги
Настройка Vanilla Stack прошла быстро, установщик Docker прост и понятен. Вскоре должны быть добавлены дополнительные параметры для большего удобства.
Если вы не хотите устанавливать Vanilla Stack, то можете использовать тот же самый стек прямо из Vanilla Cloud. Это новое облачное предложение запущено в декабре 2020 года, а первая бета-версия уже доступна.
Я рекомендую поближе познакомиться с этим стеком, так как это отличный способ узнать больше популярных open-source проектов.