Кубер что это

Kubernetes

Kubernetes (K8s) — это программная платформа для автоматического управления контейнеризованными приложениями. Она предлагает базовые механизмы для их развертывания, масштабирования и поддержки. Система имеет открытый исходный код и быстро растущую экосистему.

«IT-специалист с нуля» наш лучший курс для старта в IT

Kubernetes разработала компания Google на основе более ранней системы управления кластерами Borg. Первое название — Project Seven, в честь героини сериала Star Trek. Аллюзией на нее также являются семь ручек на штурвале логотипа проекта. Современное название отсылает к греческому слову «рулевой». Исходный код системы был представлен в 2014 году. После выхода версии 1.0 в 2015 году Google в сотрудничестве с Linux Foundation основала фонд Cloud Native Computing Foundation (CNCF) и передала ему Kubernetes в рамках начального технологического вклада.

Что представляет собой контейнеризация

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

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

Виртуальная машина. Это программная или аппаратная эмуляция работы одной или нескольких гостевых платформ (quest) на платформе-хозяине (host). Виртуальная машина имитирует компоненты аппаратного обеспечения или целый ПК с отдельной ОС. Это позволило эффективнее разграничить ресурсы физического сервера между ВМ и масштабировать их работу.

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

Преимущества контейнеризации:

• простота и гибкость развертывания приложений по сравнению с ВМ;
• непрерывность создания, интеграции и развертывания контейнера с возможностью быстро откатить изменения;
• создание контейнеров приложений в процессе сборки/релиза и отделение приложения от аппаратной инфраструктуры;
• идентичность среды разработки и тестирования на сервере и терминалах разработчика (ноутбуках, ПК);
• возможность переносить приложения между облаками и ОС — Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine и т.д.;
• разделение приложений на изолированные, распределенные, гибкие микросервисы с динамическим развертыванием и управлением.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

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

Сами по себе контейнеры — это способ развертывания и запуска приложений на сервере. Если контейнеров несколько, важно настроить их совместную работу так, чтобы они не отбирали друг у друга ресурсы аппаратной платформы и эффективно их расходовали. Кроме развертывания и запуска контейнеров, разработчику нужно периодически исправлять ошибки. Делать это вручную очень сложно. Kubernetes позволяет автоматизировать большинство процессов. Это называется «оркестрация контейнеров». Платформа может масштабировать приложения и обрабатывать возникающие ошибки, распределять ресурсы, поддерживать баланс между контейнерами и т.д. Но K8s работает не один. Чтобы он мог запустить приложения и службы в контейнерах, каждый должен быть оснащен средой выполнения. Это может быть Docker, rkt или runc.

Kubernetes действует на уровне логики, а не аппаратного обеспечения, по принципу «ведущий — ведомый». Управление системой основано на двух подходах:

• декларативном — разработчик задает цели, а не пути их достижения, которые система автоматически выбирает сама;
• императивном — разработчик может распоряжаться ресурсами с помощью команд «Создать», «Изменить», «Удалить».

Возможности Kubernetes

Наблюдение за работой сервисов. Платформа позволяет следить как за отдельными приложениями, так и за всем кластером сразу. K8s имеет веб-интерфейс. Все данные о работе сервисов система предоставляет разработчику в интуитивно понятном виде.

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

Оркестрация хранилища. С помощью Kubernetes разработчик может выбрать систему хранения: локальное хранилище, облако и т.д. Платформа автоматически создаст ее и настроит под потребности проекта.

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

Развертывание и откаты. Платформа позволяет развертывать приложения в автоматическом и ручном режимах. Есть вариант канареечного развертывания, когда изменения, внесенные разработчиком, применяются только на некоторой части контейнеров. Такое решение позволяет осторожно тестировать обновления. Изменения можно автоматически откатить.

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

Безопасность и конфиденциальность. Kubernetes может сохранять и контролировать конфиденциальные данные (пароли, ключи SSH, OAuth-токены), распределять права доступа к системе. Обновление и развертывание приложений не затрагивает образы контейнеров и не раскрывает секретные сведения в конфигурации стека.

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

Основные объекты кластера Kubernetes

Объекты — сущности, которые в архитектуре Kubernetes используются для представления состояния кластера.

Nodes (ноды, узлы)

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

Nodes бывают двух типов:

1. Master (мастер-нода) — узел, управляющий всем кластером. Он следит за остальными нодами и распределяет между ними нагрузку с помощью менеджера контроллеров (controller manager) и планировщика (scheduler). Как правило, мастер-нода занимается только управлением и не берет на себя рабочие нагрузки. Для повышения отказоустойчивости существует несколько мастер-нод.
2. Worker (рабочие ноды) — узлы, на которых работают контейнеры. В зависимости от параметров ноды (объема памяти и центрального процессора) на одном узле может работать много контейнеров. Чем больше рабочих узлов, тем больше приложений можно запустить. Также количество влияет на отказоустойчивость кластера, потому что при выходе из строя одной ноды нагрузка переносится на другие.

Pods (Поды)

Это абстрактный объект Kubernetes, представляющий собой «обертку» для одного или группы контейнеров. Контейнеры в поде запускаются и работают вместе, имеют общие сетевые ресурсы и хранилище. Kubernetes не управляет контейнерами напрямую, он собирает их в поды и работает с ими.

DevOps-инженер

Помогайте компаниям быстрее выпускать качественный продукт

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

Чаще всего в поде только один контейнер (приложение), потому что у каждого могут быть свои требования к масштабированию, производительности, SLA и пр.

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

Обычно Kubernetes сам создает поды. Для этого он должен знать образы, требования к узлам и пр. В этом помогают контроллеры, например Deployments.

Controllers (контроллеры)

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

• Deployment (развертывание). Набор алгоритмов и директив, описывающих поды, число их экземпляров, порядок их замены при изменении характеристик. С его помощью разработчик декларирует изменения нодов и наборов реплик. Это самый популярный способ разместить приложение в Kubernetes.
• ReplicaSet(набор реплик). Описывает и управляет работой нескольких подов на кластере. Чем больше таких реплик, тем выше устойчивость системы к отказам и лучше масштабируются приложения.
• StatefulSet(набор состояния). Контроллер применяется для управления приложениями с отслеживанием состояния (stateful-приложениями) с использованием постоянного хранилища.
• DaemonSet(набор «демонов»). Представляет собой совокупность «демонов» (фоновых программ, работающих без взаимодействия с пользователем) и отвечает за запуск одной реплики выбранного пода на каждом отдельном узле. То есть по мере добавления узлов в кластер добавляются и поды.
• Job(задание). Контроллер, отвечающий за однократный запуск выбранного пода и завершающий его работу. CronJob — его разновидность, запускающая группу заданий по заданному расписанию.

Читайте также 5 сложных задач на логику для айтишников

Services (сервисы)

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

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

Persistent Volumes (постоянные тома)

Это способ хранения данных между перезапусками контейнеров.

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

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

Namespaces (пространства имен)

Это возможность разделить физический кластер Kubernetes на виртуальные, каждый из которых изолирован от других. Обычно пространства имен создаются для того, чтобы разделить команды, разные проекты или среды развертывания (dev, test, prod).

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

В каждом Namespaces есть свои ресурсы: сервисы, поды, развертывания. В одном пространстве имен они должны иметь уникальные названия, но эти же названия допустимо использовать в других пространствах. В Namespaces входят не все ресурсы: например, Persistent Volumes и ноды доступны всему кластеру.

Основные компоненты кластера

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

Кластер Kubernetes включает следующие компоненты:

• kube-apiserver. С помощью сервера API обеспечивается работа API кластера, обрабатываются REST-операции и предоставляется интерфейс, через который остальные компоненты взаимодействуют друг с другом. Также через него проходят запросы на изменение состояния или чтение кластера. Работает на master-нодах;
• kube-scheduler. Компонент, планирующий, на каких узлах разворачивать поды. Он учитывает такие факторы, как ограничения, требования к ресурсам, местонахождение данных и пр. Работает на master-нодах;
• etcd. Распределенное хранилище в формате «ключ-значение». В нем хранится состояние всего кластера. Главная задача etcd — обеспечить отказоустойчивость кластера и консистентность данных. Etcd — самостоятельный проект. Он развивается отдельно от Kubernetes и применяется в разных продуктах. Работает на master-нодах;
• kube-proxy. Служба, которая управляет правилами балансировки нагрузки. Она конфигурирует правила IPVS или iptables, через которые выполняются проксирование и роутинг. Работает на worker-нодах;
• kube-controller-manager. Компонент запускает работу контроллеров. Работает на master-нодах;
• kubelet. Cлужба, которая управляет состоянием ноды: запуском, остановкой и поддержанием работы контейнеров и подов. Работает на worker-нодах.

Преимущества и недостатки Kubernetes

Высокая популярность этой платформы среди разработчиков имеет следующие причины.

Портативность и гибкость

Kubernetes не зависит от аппаратного обеспечения. Работающую платформу можно переносить на другой сервер, в частное или общедоступное облако. Главное требование — операционная система хоста должна иметь подходящую версию ОС Linux и Windows.

Экономичность

Крупным компаниям Kubernetes помогает уменьшить расходы на ИТ-инфраструктуру благодаря группировке приложений в пакеты. Это оптимизирует использование средств, инвестированных в инфраструктуру и оборудование. K8s дает много возможностей для масштабирования приложения и делает процесс более доступным. Одновременно он сокращает нагрузку на персонал, позволяет сотрудникам направить силы на решение других задач, повышает эффективность использования ресурсов инфраструктуры.

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

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

Эффективное распределение задач

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

Наличие развитой экосистемы

Kubernetes поддерживает много крупных корпораций, но это свободное ПО. Фонд CNCF только контролирует его развитие, но не владеет им. Поэтому сторонние разработчики могут создавать дополнения, расширяющие функционал системы, обмениваться опытом друг с другом. Большое количество справочных материалов и широкое комьюнити энтузиастов делают решаемой любую проблему, возникающую при работе с Kubernetes. Также можно пройти интерактивные уроки на официальном сайте.

Надежность

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

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

DevOps-инженер

Станьте DevOps-инженером и помогайте командам фокусироваться на создании качественного продукта. Профессия отлично подойдет разработчикам, тестировщикам и сисадминам

Статьи по теме:

Подборка на любой вкус для питонистов, программистов на JavaScript, тестировщиков и игровых разработчиков

Почему для больших проектов обычно выбирают Java, средних — PHP, а быстро развивающихся стартапов — Ruby или Go

Основы Kubernetes

В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

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

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

Концепции Kubernetes

Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.

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

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.

Нода Kubernetes

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

Kubelet

Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.

Kube-Proxy

Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.

Компоненты управления Kubernetes

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

etcd

Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

Kubernetes API Server

Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).

Scheduler

Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.

Kubernetes Controller Manager Server

Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.

ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.

Пример настройки кластера

В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.

Для создания тестового кластера будут использованы три машины для создания нод и отдельная машина для проведения удалённой установки. Можно не выделять отдельную машину и производить установку с одной из нод.

• Conf
• Node1: 192.168.0.10 — master, minion
• Node2: 192.168.0.11 — minion
• Node3: 192.168.0.12 — minion

Подготовка нод

Требования для запуска:

1. На всех нодах установлен docker версии 1.2+ и bridge-utils
2. Все машины связаны друг с другом, необходимости в доступе к интернету нет (в этом случае необходимо использовать локальный docker registry)
3. На все ноды можно войти без ввода логина/пароля, с использованием ssh-ключей

Установка ПО на ноды

Установку Docker можно произвести по статье в официальных источниках:

node% sudo apt-get update $ sudo apt-get install wget node% wget -qO- https://get.docker.com/ | sh 

Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:

node% sudo apt-get install bridge-utils 

Добавление ssh-ключей

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

conf% ssh-keygen 

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

conf% ssh-copy-id core@192.168.0.10 conf% ssh-copy-id core@192.168.0.11 conf% ssh-copy-id core@192.168.0.12 

Установка Kubernetes

Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:

conf% wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.17.0/kubernetes.tar.gz conf% tar xzf ./kubernetes.tar.gz conf% cd ./kubernetes 

Настройка

Настройка Kubernetes через стандартные скрипты примеров полностью производится перед установкой производится через конфигурационные файлы. При установке мы будем использовать скрипты папке ./cluster/ubuntu/.

В первую очередь изменим скрипт ./cluster/ubuntu/build.sh который скачивает и подготавливает необходимые для установки бинарники Kubernetes, etcd и flannel:

conf% vim ./cluster/ubuntu/build.sh 

Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:

# k8s echo "Download kubernetes release . " K8S_VERSION="v0.15.0" 

# k8s echo "Download kubernetes release . " K8S_VERSION="v0.17.0" 

conf% cd ./cluster/ubuntu/ conf% ./build.sh #Данный скрипт важно запускать именно из той папки, где он лежит. 

Далее указываем параметры будущего кластера, для чего редактируем файл ./config-default.sh:

## Contains configuration values for the Ubuntu cluster # В данном пункте необходимо указать все ноды будущего кластера, MASTER-нода указывается первой # Ноды указываются в формате   разделитель - пробел # В качестве пользователя указывается тот пользователь для которого по нодам разложены ssh-ключи export nodes="core@192.168.0.10 core@192.168.0.10 core@192.168.0.10" # Определяем роли нод : a(master) или i(minion) или ai(master и minion), указывается в том же порядке, что и ноды в списке выше. export roles=("ai" "i" "i") # Определяем количество миньонов export NUM_MINIONS=$ # Определяем IP-подсеть из которой, в последствии будут выделяться адреса для сервисов. # Выделять необходимо серую подсеть, которая не будет пересекаться с имеющимися, т.к. эти адреса будут существовать только в пределах каждой ноды. #Перенаправление на IP-адреса сервисов производится локальным iptables каждой ноды. export PORTAL_NET=192.168.3.0/24 #Определяем подсеть из которой будут выделяться подсети для создания внутренней сети flannel. #flannel по умолчанию выделяет подсеть с маской 24 на каждую ноду, из этих подсетей будут выделяться адреса для Docker-контейнеров. #Подсеть не должна пересекаться с PORTAL_NET export FLANNEL_NET=172.16.0.0/16 # Admission Controllers определяет политику доступа к объектам кластера. ADMISSION_CONTROL=NamespaceLifecycle,NamespaceAutoProvision,LimitRanger,ResourceQuota # Дополнительные параметры запуска Docker. Могут быть полезны для дополнительных настроек # например установка --insecure-registry для локальных репозиториев. DOCKER_OPTS="" 

На этом настройка заканчивается и можно переходить к установке.

Установка

Первым делом необходимо сообщить системе про наш ssh-agent и используемый ssh-ключ для этого выполняем:

eval `ssh-agent -s` ssh-add /путь/до/ключа 

Далее переходим непосредственно к установке. Для этого используется скрипт ./kubernetes/cluster/kube-up.sh которому необходимо указать, что мы используем ubuntu.

conf% cd ../ conf% KUBERNETES_PROVIDER=ubuntu ./kube-up.sh 

В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.

Пример вывода скрипта

Starting cluster using provider: ubuntu . calling verify-prereqs . calling kube-up Deploying master and minion on machine 192.168.0.10 [sudo] password to copy files and start node: etcd start/running, process 16384 Connection to 192.168.0.10 closed. Deploying minion on machine 192.168.0.11 [sudo] password to copy files and start minion: etcd start/running, process 12325 Connection to 192.168.0.11 closed. Deploying minion on machine 192.168.0.12 [sudo] password to copy files and start minion: etcd start/running, process 10217 Connection to 192.168.0.12 closed. Validating master Validating core@192.168.0.10 Validating core@192.168.0.11 Validating core@192.168.0.12 Kubernetes cluster is running. The master is running at: http://192.168.0.10 . calling validate-cluster Found 3 nodes. 1 NAME LABELS STATUS 2 192.168.0.10 Ready 3 192.168.0.11 Ready 4 192.168.0.12 Ready Validate output: NAME STATUS MESSAGE ERROR etcd-0 Healthy <"action":"get","node":<"dir":true,"nodes":[<"key":"/coreos.com","dir":true,"modifiedIndex":11,"createdIndex":11>,],"modifiedIndex":5,"createdIndex":5>> nil controller-manager Healthy ok nil scheduler Healthy ok nil Cluster validation succeeded Done, listing cluster services: Kubernetes master is running at http://192.168.0.10:8080 

Посмотрим, какие ноды и сервисы присутствуют в новом кластере:

conf% cp ../kubernetes/platforms/linux/amd64/kubectl /opt/bin/ conf% /opt/bin/kubectl get services,minions -s "http://192.168.0.10:8080" NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes 192.168.3.1 80/TCP NAME LABELS STATUS 192.168.0.10 Ready 192.168.0.11 Ready 192.168.0.12 Ready 

Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.

Запуск тестового сервиса

Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.

Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.

Запуск сервиса вручную

Начнём с создания Replication Controller’а:

conf% /opt/bin/kubectl run-container nginx --port=80 --port=443 --image=nginx --replicas=6 -s "http://192.168.0.10:8080" 

• nginx — имя будущего rc
• —port — порты на которых будут слушать контейнеры rc
• —image — образ из которого будут запущены контейнеры
• —replicas=6 — количество реплик

/opt/bin/kubectl get pods,rc -s "http://192.168.0.10:8080" 

POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE nginx-3gii4 172.16.58.4 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 9 seconds nginx-3xudc 172.16.62.6 192.168.0.10/192.168.0.10 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-igpon 172.16.58.6 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-km78j 172.16.58.5 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-sjb39 172.16.83.4 192.168.0.12/192.168.0.12 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-zk1wv 172.16.62.7 192.168.0.10/192.168.0.10 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx nginx nginx run-container=nginx 6 

• Часть pod находится в состоянии pending: это значит, что они ещё не запустились, необходимо немного подождать
• У pod не определён HOST: это значит, что scheduler ещё не назначил ноду на которой будет запущен pod

Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:

conf% /opt/bin/kubectl expose rc nginx --port=80 --target-port=80 --service-name=nginx-http -s "http://192.168.0.10:8080" 

conf% /opt/bin/kubectl expose rc nginx --port=443 --target-port=443 --service-name=nginx-https -s "http://192.168.0.10:8080" 

• rc nginx — тип и имя используемого ресурса (rc = Replication Controller)
• —port — порт на котором будет «слушать» сервис
• —target-port — порт контейнера на который будет производиться трансляция запросов
• —service-name — будущее имя сервиса

/opt/bin/kubectl get rc,services -s "http://192.168.0.10:8080" 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx nginx nginx run-container=nginx 6 NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes 192.168.3.1 80/TCP nginx-http run-container=nginx 192.168.3.66 80/TCP nginx-https run-container=nginx 192.168.3.172 443/TCP 

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

node% curl http://192.168.3.66 

В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.

Запуск сервиса с помощью конфигов

Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.

Предварительно очистим наш кластер от предыдущего эксперимента:

conf% /opt/bin/kubectl delete services nginx-http nginx-https -s "http://192.168.0.10:8080" conf% /opt/bin/kubectl stop rc nginx -s "http://192.168.0.10:8080" Теперь приступим к написанию конфигов. 

nginx_rc.yaml
содержимое

apiVersion: v1beta3 kind: ReplicationController # Указываем имя ReplicationController metadata: name: nginx-controller spec: # Устанавливаем количество реплик replicas: 6 selector: name: nginx template: metadata: labels: name: nginx spec: containers: #Описываем контейнер - name: nginx image: nginx #Пробрасываем порты ports: - containerPort: 80 - containerPort: 443 livenessProbe: # включаем проверку работоспособности enabled: true type: http # Время ожидания после запуска pod'ы до момента начала проверок initialDelaySeconds: 30 TimeoutSeconds: 5 # http проверка httpGet: path: / port: 80 portals: - destination: nginx 

conf% /opt/bin/kubectl create -f ./nginx_rc.yaml -s "http://192.168.0.10:8080" 

conf% /opt/bin/kubectl get pods,rc -s "http://192.168.0.10:8080" 

POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE nginx-controller-0wklg 172.16.58.7 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-2jynt 172.16.58.8 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-8ra6j 172.16.62.8 192.168.0.10/192.168.0.10 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-avmu8 172.16.58.9 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-ddr4y 172.16.83.7 192.168.0.12/192.168.0.12 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-qb2wb 172.16.83.5 192.168.0.12/192.168.0.12 name=nginx Running About a minute nginx nginx Running About a minute CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx-controller nginx nginx name=nginx 6 

Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.

nginx_service.yaml

Содержимое

apiVersion: v1beta3 kind: Service metadata: name: nginx spec: publicIPs: - 12.0.0.5 # IP который будет присвоен сервису помимо автоматически назначенного. ports: - name: http port: 80 #порт на котором будет слушать сервис targetPort: 80 порт контейнера на который будет производиться трансляция запросов protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: name: nginx # поле должно совпадать с аналогичным в конфиге ReplicationController 

Можно заметить, что при использовании конфига за одним сервисом могут быть закреплены несколько портов.
Применяем конфиг:

conf% /opt/bin/kubectl create -f ./nginx_service.yaml -s "http://192.168.0.10:8080" 

/opt/bin/kubectl get rc,services -s "http://192.168.0.10:8080" 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx-controller nginx nginx name=nginx 6 NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes 192.168.3.1 80/TCP nginx name=nginx 192.168.3.214 80/TCP 12.0.0.5 443/TCP 

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

node% curl http://192.168.3.214 node% curl http://12.0.0.5 

В выводе curl увидим стандартную приветственную страницу nginx.

Заметки на полях

В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:

-A PREROUTING -j KUBE-PORTALS-CONTAINER -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A OUTPUT -j KUBE-PORTALS-HOST -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 10.0.42.0/24 ! -o docker0 -j MASQUERADE -A KUBE-PORTALS-CONTAINER -d 10.0.0.2/32 -p tcp -m comment --comment "default/kubernetes:" -m tcp --dport 443 -j REDIRECT --to-ports 46041 -A KUBE-PORTALS-CONTAINER -d 10.0.0.1/32 -p tcp -m comment --comment "default/kubernetes-ro:" -m tcp --dport 80 -j REDIRECT --to-ports 58340 -A KUBE-PORTALS-HOST -d 10.0.0.2/32 -p tcp -m comment --comment "default/kubernetes:" -m tcp --dport 443 -j DNAT --to-destination 172.16.67.69:46041 -A KUBE-PORTALS-HOST -d 10.0.0.1/32 -p tcp -m comment --comment "default/kubernetes-ro:" -m tcp --dport 80 -j DNAT --to-destination 172.16.67.69:58340 

• gcloud — платная разработка от Google
• bgp — с помощью анонсирования подсетей
• IPVS
• и прочие варианты, которых множество

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

Использование материалы:

• Архитектура Kubernetes
• Kubernetes user guide
• Kubernetes ubuntu cluster
• Scaling Docker with Kubernetes
• Kubernetes services

Чем отличаются Kubernetes и Docker?

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

Где используются Kubernetes и Docker

Kubernetes и Docker – это контейнерные технологии. Современные приложения состоят из микросервисов – независимых компонентов, которые выполняют каждый процесс приложения как сервис. Каждый сервис выполняет одну функцию и взаимодействует с другими сервисами через четко определенный интерфейс, называемый API. Контейнеризация предоставляет программный инструмент для упаковки микросервисов в виде развертываемых программ на разных платформах.

Создание контейнеров

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

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

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

• Как следует координировать работу нескольких контейнеров?
• Как следует планировать контейнеры?
• Как следует группировать и каталогизировать контейнеры?

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

Какие ключевые различия между Kubernetes и Docker

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

Операции

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

• Docker Build для создания образов контейнеров;
• Docker Compose для определения и запуска многоконтейнерных приложений;
• Docker Hub для поиска и обмена образами контейнеров, аналогично GitHub для обмена кодом.

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

Базовая технология

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

Большая выгода

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

Когда использовать Kubernetes, а когда – Docker

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

Что такое Pods, Nodes, Containers и Clusters в Kubernetes

Kubernetes (k8s) очень стремительно становится новым стандартом для деплоймента и менеджмента вашего кода в клауде. Вместе с тем, сколько фич предоставляет k8s, для новичка наступает высокий порог входа в новую технологии.

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

Hardware

Nodes

Node — это самая маленькая единица ‘computing hardware в k8s. Это представление одной машины в вашем кластере. В большинстве производственных систем нодой, корее всего, будет либо физическая машина в датацентре, либо виртуальная машина, размещенная на облачном провайдере, таком как Google Cloud Platform, Azure, AWS. Однако, вы можете сделать ноду практически из чего угодно (например Rasbery PI).

Если обсуждать про машину как «ноду», можем разбавить это слоем абстракции, мы можем представлять ее как некий набор CPU, RAM ресурсов которые можно использовать. Таким образом любая такая машина может заменить любую другую машину как k8s кластер.

Cluster

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

В Kubernetes ноды объединяют свои ресурсы для формирования более мощной машины. Когда вы развертываете программы в кластере, он балансирует нагрузку по индивидуальным нодам для вас. Если какие-либо nodes добавляются или удаляются, кластер будет перемещаться по мере необходимости. Для программы или девелопера не должно быть важно, на каких машинах выполняется код в k8s. Можно сравнить такую систему с улием.

Persistent Volumes

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

Для постоянного хранения данных Kubernetes использует Persistent Volumes. Хотя ресурсы ЦП и ОЗУ всех нодов эффективно объединяются и управляются кластером, постоянного хранение файлов — нет. Вместо этого локальные или облачные диски могут быть подключены к кластеру как постоянный том (Persistent Volumes). Это можно рассматривать как подключение внешнего жесткого диска к кластеру. Persistent Volumes предоставляют файловую систему, которая может быть подключена к кластеру без привязки к какому-либо конкретному ноду.

Software

Контейнеры

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

Контейнеризация позволяет вам создавать self-contained environments. Любая программа и все ее зависимости могут быть объединены в один файл и затем опубликованы в Интернете. Любой может загрузить контейнер и развернуть его в своей инфраструктуре с минимальными настройками. Создание контейнера может быть сделано и скриптом, позволяя строить CI/CD пайплайны.

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

Pods

В отличие от других систем, которые вы, возможно, использовали в прошлом, Kubernetes не запускает контейнеры напрямую; вместо этого он упаковывает один или несколько контейнеров в структуру более высокого уровня, называемую pod. Любые контейнеры в одном pod’e будут использовать одни и те же ресурсы и локальную сеть. Контейнеры могут легко связываться с другими контейнерами в том же pod’e, как если бы они находились на одной машине, сохраняя степень изоляции от других pod’ов.

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

Pod’ы могут содержать несколько контейнеров, но вы должны ограничивать их количество, когда это возможно. Поскольку контейнеры масштабируются как единое целое, все контейнеры в паке должны масштабироваться вместе, независимо от их индивидуальных потребностей. Это приводит к потраченным впустую ресурсам и дорогому счету. Чтобы решить эту проблему, Pod’ы должны оставаться меньше на сколько это возможно, обычно вмещая только основной процесс и его тесно связанные вспомогательные контейнеры (эти вспомогательные контейнеры обычно называют Side-cars).

Deployments

Хотя в Kubernetes pod являются базовой единицей вычислений, они, как правило, не запускаются напрямую в кластере. Вместо этого pod обычно менеджится еще одним уровнем абстракции — deployment.

Основная цель юзать подход с deployment состоит в том, чтобы настроить, сколько реплик pod’а должно работать одновременно. Когда развертывание добавляется в кластер, оно автоматически деплоит требуемое количество pod’ов и отслеживает их. Если pod умирает, deployment автоматически пересоздает его.

Используя deployment, вам не нужно иметь дело с подами вручную. Вы можете просто объявить желаемое состояние системы, и оно будет управляться автоматически.

Ingress

Используя описанные выше концепции, вы можете создать кластер нодов и запустить деплоймент подов в кластере. Однако есть еще одна проблема, которую необходимо решить: разрешить внешний трафик вашему приложению. По умолчанию Kubernetes обеспечивает изоляцию между модулями и внешним миром. Если вы хотите общаться с сервисом, работающим в pod, вам нужно открыть канал для связи. Это называется Ingress.

Есть несколько способов добавить ingress в ваш кластер. Наиболее распространенными способами являются добавление либо ingress controller, либо LoadBalancer. Описание различий и что лучше выбрать выходит за рамки этой статьи, но вы должны держать в голове что вам нужно разобратся с доступом к сервису, если вы хотите работать с k8s.