Kubernetes что это

29.08.202228.08.2022 admin 0 Комментариев

Kubernetes что это

Оркестрация контейнеров промышленного уровня

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

Масштабируемость любого уровня

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

Бесконечная гибкость

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

Может быть запущен где угодно

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

О сложности миграции 150+ микросервисов в Kubernetes

Сара Уелльс, технический директор по эксплуатации и надёжности в Financial Times

Источник

Основы 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. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

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 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.

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

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

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

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

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

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

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

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

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

Установка Kubernetes

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

Настройка

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

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

Установка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Что такое Kubernetes

Эта страница посвящена краткому обзору Kubernetes.

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

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

История

Давайте вернемся назад и посмотрим, почему Kubernetes так полезен.

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

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

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

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

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

Контейнеры стали популярными из-за таких дополнительных преимуществ как:

Зачем вам Kubernetes и что он может сделать?

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

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

Kubernetes предоставляет вам:

Чем Kubernetes не является

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

Что дальше

Обратная связь

Была ли эта страница полезной?

Спасибо за отзыв! Если у вас есть конкретный вопрос об использовании Kubernetes, спрашивайте Stack Overflow. Сообщите о проблеме в репозитории GitHub, если вы хотите сообщить о проблеме или предложить улучшение.

Источник

Kubernetes или с чего начать, чтобы понять что это и зачем он нужен

Данная статья рассчитана на новичков. Если вы опытный ниндзя, просто вспомните о том, как когда-то подобная информация могла быть полезной и для вас.

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

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

Давайте вспомним что такое контейнеры.

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

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

Вот для такого и нужен Kubernetes.

Kubernetes по сути является не просто системой оркестрации. Технически оркестрация это про выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C.

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

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

Сделать это только с помощью контейнеров не получится. А вот в Kubernetes это можно достичь с помощью Pods (подов).

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

Kubernetes, согласно официальной документации, так же сможет предоставить вам:

Используя имя DNS или собственный IP-адрес мониторинг сервисов и распределение нагрузки Kubernetes может обнаружить контейнер. При высоком трафике в нем Kubernetes сбалансирует нагрузку и распределить сетевой трафик так, что развертывание будет стабильным.

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

Автоматическое развертывание и откаты.

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

Автоматическое распределение нагрузки.

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

Самоконтроль.

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

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

Как видим на рисунке, это наглядная демонстрация того что есть внутри Kubernetes на примере одной мастер ноды (Master node) и одной воркер ноды (Worker node).

На Master node находится Kubernetes Control Plane (kube-scheduler, kube-controller-manager, kube-apiserver, etcd), с помощью которой происходит управление всем кластером Kubernetes.

На Worker node находятся container runtime (среда запуска контейнера), kubelet и kube-proxy.

Сontainer runtime это то на чем будет запущен ваш Под (например Docker, Container D, Rocket и т.д.).

Kubelet это основной «агент узла», который работает на каждой ноде. Гарантирует, что контейнеры в Pod(поде)работают и исправны. Не управляет контейнерами, которые не были созданы Kubernetes.

Kube-proxy это демон на каждой ноде, управляет правилами iptable на хосте для достижения балансировки нагрузки службы (одна из реализаций) и следит за изменениями Service и Endpoint.

Более детальное рассмотрение архитектуры, основных концепций Kubernetes в теории и главное на практике, наравне с такими интересными темами как кластеризация, highload web, администрирование СУБД, виртуализация и контейнеризация, оркестрация вы сможете изучить на курсе Administrator Linux. Advanced.

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

Ну и как же без такого важного вопроса как хранение данных, мониторинг и Kubernetes secrets Hashicorp Vault.

А тех, кто давно знаком с тем, что рассказано в этой статье и хочет чего-то похардкорнее, приглашаем на бесплатный демо-урок по теме ««Кластерная файловая система Lustre»». В рамках урока рассмотрим архитектуру и компоненты файловой системы Lustre. Разберем области применения файловой системы и ее особенности. Ответим на вопросы как используется file striping и что такое сетевой транспортный уровень LNET. На практической части установим и сконфигурируем файловую систему вручную. Посмотрим пример работы графической пользовательского интерфейса Integrated Manager for Lustre (IML)

Источник

Just-in-Time Kubernetes: Руководство начинающим для понимания основных концепций Kubernetes

Простые истины

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

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

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

Вы опытный инженер-программист, который уже некоторое время работает с Kubernetes в режиме обучения «just-in-time». То есть, вы изучаете только то, что вам нужно для выполнения работы. Теперь же вам становится все труднее, и вы решили, что настало время углубиться в некоторые основы.

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

Что бы ни привело вас сюда, добро пожаловать! Я рад, что вы здесь!

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

Моя цель — показать вам, что Kubernetes не так уж и страшен, и вдохновить вас на дальнейшее совершенствование своих знаний. (ознакомьтесь с одним из моих расширенных постов) Если вы уже давно занимаетесь Kubernetes, пусть это освежит ваши знания! Возможно, вы делали все определенным образом, принимая как должное, что «так оно и работает». А сейчас, возможно, вы лучше поймете, почему это работает именно так.

Обзор

В этом посте я расскажу о следующих темах:

Что такое Kubernetes?

Высокоуровневый взгляд: Архитектура Kubernetes;

Копаем глубже: Ресурсы, контроллеры и операторы;

Инструмент командной строки kubectl для взаимодействия с Kubernetes.

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

1. Что такое Kubernetes?

Забавный факт: Kubernetes уходит своими корнями в проект Borg, который изначально разрабатывался компанией Google.

Теперь вам, возможно, интересно, что такое оркестровка контейнеров. Давайте рассмотрим пример.

Допустим, у вас на компьютере запущена куча контейнеров Docker. Возможно, некоторым из них нужно общаться друг с другом. А может быть, ваша подруга Нэнси пытается получить доступ к конечной точке API, запущенной на одном из этих контейнеров. Как обеспечить, чтобы контейнеры могли общаться друг с другом? Как вы можете гарантировать, что Нэнси сможет безопасно получить доступ к конечной точке API? Что произойдет, если один из ваших контейнеров умирает? Что будет, если вам понадобится масштабировать контейнеры, потому что внезапно доступ к конечной точке API понадобится не только Нэнси. это будет Нэнси и все ее друзья-разработчики, участвующие в хакатоне. Что тогда?

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

Заклятые друзья Kubernetes

Несмотря на то, что Kubernetes очень крут и популярен, вы можете быть шокированы, узнав, что это не единственный контейнерный оркестратор! Поэтому будет справедливо упомянуть несколько конкурентов Kubernetes:

Дистрибутивы Kubernetes

Стоит упомянуть, что существует несколько различных способов запуска Kubernetes.

Локальный

Во-первых, вы можете запустить Kubernetes локально на своей машине. Вот несколько инструментов, которые делают это возможным:

KIND (означает Kubernetes in (в) Docker)

Docker Desktop (он поставляется вместе с Kubernetes, и вы можете запустить его локально)

Решения облачных вендоров

Они также предоставляют вам некоторые базовые графические интерфейсы k8s, хотя ничего сверхъестественного.

Решения для предприятий

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

Сделай сам

И, наконец, вы всегда можете создать свои собственные кластеры k8s с нуля. Если вы действительно хотите понять, как работает Kubernetes, то этот способ вам точно подойдет!

2. Компоненты Kubernetes

Теперь, когда мы немного ознакомились с Kubernetes, давайте заглянем под капот.

Главный и рабочий (minion) узлы Kubernetes

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

Кластер обычно состоит из главного узла (мастер) и множества рабочих (воркер) узлов (minion).

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

На приведенной ниже схеме показано, что происходит внутри мастера и воркера:

Компоненты Kubernetes. Изображение с сайта kubernetes.io

Главный узел

Как управляющий всей этой операцией, мастер имеет довольно много компонентов:

Давайте разберемся в них.

etcd — это распределенная база данных ключ-значение. Она является источником достоверных данных для Kubernetes. Каждый раз, когда вы вносите изменения в Kubernetes — например, отправляя YAML или JSON через REST API k8s или с помощью инструмента kubectl CLI (подробнее об этом позже) — эти изменения сохраняются в etcd в виде JSON. Он также версионируется, таким образом, обеспечивается серьезный контроль версий.

Одной из ключевых особенностей etcd является ее способность следить за изменениями. То есть, она сверяет текущие настройки системы с любыми входящими изменениями, отправленными в Kubernetes через REST API вызов или kubectl.

Предупреждение для зануд: я лично считаю, что etcd — один из самых крутых компонентов Kubernetes. Вы можете установить etcd на свою локальную машину (например, OSX или Ubuntu) и поиграть с ним, используя инструмент etcdctl CLI. В Python даже есть несколько библиотек для программного взаимодействия с etcd. Я лично играл с библиотекой Python etcd3, и рекомендую изучить etcd самостоятельно!

Сервер API

Менеджер контроллеров

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

Принятие мер при выходе из строя пода;

Подключение служб к подам;

Создание учетных записей и доступ к API-токенам.

И многие другие.

Примечание: Если вам интересно, что такое под, то это, по сути, обертка вокруг одного или нескольких контейнеров.

Планировщик

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

Рабочие узлы

Очевидно, что мастер делает многое, но, как и менеджер, он ничто без рабочих узлов (воркеров). Воркеры содержат 2 основных компонента:

Kubelet

Kubelet — это агент (небольшое приложение), который запускается на каждом рабочем узле в кластере. Его основная задача — следить за тем, чтобы контейнеры запускались в поде (обертке из одного или нескольких контейнеров). Но кто указывает ему запустить эти контейнеры? Это происходит из control plane (управляющего уровня) (где находится наш хороший друг — менеджер контроллеров). Когда уровень управления требует, чтобы что-то произошло в узле, kubelet делает это.

Kubelet запускает рантайм контейнера и, как следует из названия, отвечает за фактический его запуск. Точнее, он управляет полным жизненным циклом контейнера: получение образа контейнера (из реестра контейнеров, такого как Docker Hub) и его хранение, выполнение контейнера, подключение к сети и т. д. — популярная среда выполнения контейнеров; однако существуют и другие, такие как containerd, CRI-O.

Примечание: В настоящее время Kubernetes использует контейнерный рантайм Docker; однако в ближайшем будущем он откажется от Docker в пользу Container Runtime Interface (CRI), созданный для Kubernetes. Образы, созданные Docker, будут продолжать работать в вашем кластере со всеми режимами выполнения, как и раньше, поэтому не стоит паниковать!

Kube-proxy

Kube-proxy обрабатывает сетевые соединения внутри и за пределами вашего кластера. Это означает, что если подам нужно общаться между собой или если какому-то внешнему сервису нужно обратиться к подам, kube-proxy поможет это сделать.

3. Ресурсы, контроллеры и операторы

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

Ресурсы

Ресурс Kubernetes — это объект или операция в Kubernetes, доступ к которым осуществляется через Kubernetes API. Тип ресурса известен как kind (вид) и представлен в виде объекта JSON. Этот JSON-объект хранится (и версионируется) в хранилище etcd.

Существует две категории ресурсов: примитивные и пользовательские. Примитивные ресурсы поставляются «из коробки» с Kubernetes. К ним относятся Pod, Service, Deployment, ServiceAccount, PersistentVolumeClaim, RoleBinding. Я могу продолжить.

Образец примитивного ресурса в Kubernetes

Пользовательские ресурсы являются расширением API Kubernetes и поэтому не всегда доступны в стандартной установке Kubernetes. После инсталляции вы можете использовать инструмент kubectl CLI для создания и доступа к этим ресурсам (подробнее о kubectl позже). Пользовательские ресурсы создаются, когда вы хотите/необходимо, чтобы Kubernetes делал некоторые вещи, которые вы не можете получить из коробки с k8s.

Вот пример того, как выглядит пользовательский ресурс:

Образец пользовательского ресурса в Kubernetes

Заметьте, что в большинстве случаев примитивный и пользовательский ресурс имеют одинаковые основные поля:

apiVersion : Версия API Kubernetes, который вы используете для создания ресурса;

kind : Тип создаваемого ресурса;

metadata : Данные, которые однозначно идентифицируют ресурс;

spec : Сообщает Kubernetes желаемое состояние ресурса.

Контроллеры

Как говорилось ранее, контроллер следит за состоянием вашего кластера, затем вносит или запрашивает изменения, где это необходимо, для достижения желаемого состояния. Что именно это значит?

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

Операторы

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

Создавать операторы может кто угодно: вы, ваша организация или сторонний вендор. Например, RedHat OpenShift имеет свой собственный набор операторов (вместе с сопутствующими пользовательскими ресурсами), которые являются частью его основного продукта, который он запускает поверх обычного Kubernetes. И благодаря замечательному сообществу разработчиков открытого кода многие из операторов доступны для совместного использования. Вы можете ознакомиться с некоторыми из них на сайте OperatorHub.io.

4. kubectl

Скриншот примера файла kubeconfig

Записи в файле kubeconfig автоматически создаются при подключении к существующему кластеру Kubernetes.

Например, если бы я хотел подключиться к кластеру Azure Kubernetes, я бы использовал Azure’s az CLI для выполнения следующей команды:

Который заполнит мой файл kubeconfig для меня.

Аналогично, я могу использовать gcloud CLI Google Cloud для подключения к кластеру Google Kubernetes следующим образом:

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

Заключение

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

Вы сможете обмолвится о нескольких забавных фактах про Kubernetes своим друзьям и близким во время следующего звонка в Zoom, а также рассказать им такие вещи, как:

Что такое Kubernetes и зачем он вам нужен;

Разница между главным и рабочим узлами, а также все преимущества каждого из них;

Что такое ресурсы;

Разница между контроллерами и операторами;

Перевод материала подготовлен для будущих студентов курса «DevOps практики и инструменты».

Инфраструктура как код (IaC), Immutable Infrastructure и другие страшные слова из книжек про DevOps у всех на слуху, а в родной компании всё еще по заявкам создаем виртуалки накликивая их в гипервизоре. Всех желающих приглашаем на открытый урок «Принципы организации инфраструктурного кода и работа над инфраструктурой в команде на примере Terraform», на котором поговорим о том, зачем и как начать использовать практику Infrastructure as a Code.

Источник

K8S для начинающих. Первая часть

Предисловие

Что такое Kubernetes?

Kubernetes делает следующее:

Управляет и запускает контейнеры

Балансирует сетевой трафик между узлами кластера Kubernetes и количеством реплик контейнеров

Осуществляет контроль состояния, автоматические развертывания и откаты реплик контейнеров внутри узлов кластера Kubernetes

Осуществляет распределение нагрузки между узлами кластера Kubernetes

Предоставляет автоматическое монтирование систем хранения для контейнеров

Предоставляет декларативный API и CLI для управления

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

Kubernetes не делает следующее:

Не собирает контейнеры с исходным кодом вашего приложения или сервиса

Не предоставляет процессы и решения непрерывной интеграции (CI)

Не включает в себя решения и системы сбора журналов и метрик

Не включает в себя решения и системы хранения данных

Не включает в себя решения и системы хранения контейнеров (registry)

Не включает в себя решения и системы от всех бед и болячек инфраструктуры

Kubernetes или K8S — это не просто система оркестрации. Техническое определение оркестрации — это выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C. Напротив, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно переводят текущее состояние к предполагаемому состоянию. Неважно, как добраться от А до С. Не требуется также и централизованный контроль. Это делает систему более простой в использовании, более мощной, надежной, устойчивой и расширяемой.

Но что если у нас таких сервисов тысячи, каждый за что-то отвечает и работает сам по себе? А если еще развернуты несколько реплик для отказоустойчивости? Как управлять всем и уделить внимание каждому из них? Как понять, что сервис правильно работает и взаимодействует с другими? Для этого есть специальные системы, оркестраторы в своем роде, такие как HashiCorp Nomad, Docker Swarm и Kubernetes. Последний используется активнее всего, так как предоставляет более гибкий функционал в контексте управления всей конструкцией приложения.

На самом деле бизнесу нужен не Kubernetes, а система, которая позволит более быстрее подходить к изменению рынка и подстраиваться под его запросы предоставления набора новых услуг или вывода старых. В НАТ.Тех мы давно используем этот инструмент и чувствуем большую разницу, как для нас, так и для наших клиентов. Исходя из нашего опыта, бизнес чаще всего ценит такие возможности К8S как собирать и тестировать только часть приложения, с которой мы работаем, что в разы уменьшает объем необходимых ресурсов; добавлять и убирать сервисы «на лету», тестировать новый функционал в разных регионах и смотреть, как он себя показывает.

Именно для этого нам и нужен Kubernetes, который дает унификацию и гибкость в способе обслуживания и содержания сервисов приложения. Kubernetes предоставляет:

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

Гибкий подход в управлении. Kubernetes не потребует перестройки инфраструктуры и прочего, если вы захотели провести тестирование, внедрить новый сервис или сделать деплой по методологии blue-green

Универсальность. С помощью манифестов легко переехать, если вы захотели поменять провайдера или переезжали в свой собственный кластер

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

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

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

Внедрение Kubernetes

Kubernetes, так как он был реализован как облачное решение, предпочтительнее разворачивать именно в облаке.

Если вы решились ставить Kubernetes внутри, на своих собственных ресурсах, то вам придется позаботиться о развёртывании и обслуживании такой инфраструктуры вокруг кластера как: репозиторий для контейнеров, внешние или внутренние балансировщики, сетевые хранилища, хранилище секретов, решения для сбора логов и метрик. Также важна и внутренняя инфраструктура “кубера”: CertManager, Ingress, Istio и другие.

При этом существует много компаний, которые предоставляют Kubernetes как IaaS-решение, где не требуется поднимать и обслуживать окружение для кластера и процессов, которые будут на нем. Или, например, в NUT.Tech, где я сейчас работаю, разрабатываются решения “под ключ” индивидуально под запрос заказчика.

Компоненты и архитектура

Давайте поверхностно коснемся архитектуры самого K8S и его важных компонентов.

Сам кластер K8S состоит из, барабанная дробь, рабочих узлов. В узлах или нодах (Nodes, Worker nodes), помимо контейнеров компонентов самого кластера, размещаются контейнеры наших проектов и сервисов.

Worker nodes состоит из компонентов:

Плоскость управления (Master nodes) управляет рабочими узлами и подами в кластере. Там располагаются компоненты, которые управляют узлами кластера и предоставляют доступ к API.

Control plane состоит из компонентов:

Виды контроллеров

Тестовые кластеры, где потренироваться

Kubectl: как пользоваться, основные команды

При работе с кластером нам потребуется инструмент командной строки kubectl. https://Kubernetes.io/ru/docs/tasks/tools/install-kubectl/

Его можно установить на локальную машину и управлять несколькими кластерами с одной точки.

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

Тестовый кластер

Давайте развернем свой k8s кластер на примере kind https://kind.sigs.k8s.io/

После выполнения команды посмотрим и убедимся, что все хорошо и наш кластер появился в списке.

Убедимся, что в kubectl добавился context нашего кластера

Что такое Pods

Pods или поды — это абстрактный объект в кластере K8S, который состоит из одного или нескольких контейнеров с общим хранилищем и сетевыми ресурсами, а также спецификации для запуска контейнеров.

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

kube-scheduler планирует размещение пода на узлах кластера

kubelet на рабочем узле кластера запускает под

Любители забегать вперед и просто углубиться в тему могут почитать прекрасную статью на github.

Что такое Namespace

Namespace или пространство имен — это абстрактный объект, который логически разграничивает и изолирует ресурсы между подами. Вы можете рассматривать пространство имен как внутренний виртуальный кластер, который поможет вам изолировать проекты или пользователей между собой, применить разные политики квот на свои проекты или выдать права доступа только на определенную область.

default — пространство имён по умолчанию для объектов без какого-либо другого пространства имён

kube-system — пространство имён для объектов, созданных Kubernetes. Там размещаются системные поды кластера

kube-public — создаваемое автоматически пространство имён, которое доступно для чтения всем пользователям (включая также неаутентифицированных пользователей)

Размещение объектов

Давайте разместим свой первый объект в нашем тестовом кластере, для этого создадим свой namespace и положим туда простенький pod с nginx.

Чтобы создать свой namespace, нам нужно передать его спецификацию или манифест в формате yaml.

apiVersion — используемая для создания объекта версия API Kubernetes. Стоит отметить, что из версии к версии версии api могут меняться

kind — тип создаваемого объекта

metadata — данные, позволяющие идентифицировать объект (name, UID и необязательное поле namespace)

spec — требуемое состояние объекта

Давайте создадим test-namespace.yaml со следующим содержанием:

И применим его с помощью команды:

Посмотрим на результат:

Как видим, наш namespace успешно создался. Приступим к созданию своего первого пода (pod). Давайте положим контейнер с NGINX в наш namespace.

Как и с namespace, опишем его. Создадим hello.yaml

Если манифест применился то увидим:

Узнаем развернулся ли наш контейнер

Зайдем через наш браузер на http://localhost:30080/

Если вы видите в браузере:

То контейнер работает, неожиданно. 🙂

Источник

Основы Kubernetes

Что такое Kubernetes?

Концепции Kubernetes

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

Нода Kubernetes

Kubelet

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

Kube-Proxy

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

Kubernetes API Server

Scheduler

Kubernetes Controller Manager Server

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

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

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

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

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

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

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

Установка Kubernetes

Настройка

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

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

Установка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Обзор

Эта страница посвящена краткому обзору Kubernetes.

История

Давайте вернемся назад и посмотрим, почему Kubernetes так полезен.

Контейнеры стали популярными из-за таких дополнительных преимуществ как:

Зачем вам Kubernetes и что он может сделать?

Kubernetes предоставляет вам:

Чем Kubernetes не является

Что дальше

При развёртывании Kubernetes вы имеете дело с кластером.

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

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

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

Ниже показана диаграмма кластера Kubernetes со всеми связанными компонентами.

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

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

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

kube-apiserver

Сервер API — компонент Kubernetes панели управления, который представляет API Kubernetes. API-сервер — это клиентская часть панели управления Kubernetes

Основной реализацией API-сервера Kubernetes является kube-apiserver. kube-apiserver предназначен для горизонтального масштабирования, то есть развёртывание на несколько экземпляров. Вы можете запустить несколько экземпляров kube-apiserver и сбалансировать трафик между этими экземплярами.

Распределённое и высоконадёжное хранилище данных в формате «ключ-значение», которое используется как основное хранилище всех данных кластера в Kubernetes.

Если ваш кластер Kubernetes использует etcd в качестве основного хранилища, убедитесь, что у вас настроено резервное копирование данных.

Вы можете найти подробную информацию о etcd в официальной документации.

kube-scheduler

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

При планировании развёртывания подов на узлах учитываются множество факторов, включая требования к ресурсам, ограничения, связанные с аппаратными/программными политиками, принадлежности (affinity) и непринадлежности (anti-affinity) узлов/подов, местонахождения данных, предельных сроков.

kube-controller-manager

Компонент Control Plane запускает процессы контроллера.

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

Эти контроллеры включают:

cloud-controller-manager

cloud-controller-manager запускает контроллеры, которые взаимодействуют с основными облачными провайдерами. Двоичный файл cloud-controller-manager — это альфа-функциональность, появившиеся в Kubernetes 1.6.

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

Следующие контроллеры зависят от облачных провайдеров:

Компоненты узла

Компоненты узла работают на каждом узле, поддерживая работу подов и среды выполнения Kubernetes.

kubelet

Агент, работающий на каждом узле в кластере. Он следит за тем, чтобы контейнеры были запущены в поде.

Утилита kubelet принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров. Агент kubelet не отвечает за контейнеры, не созданные Kubernetes.

kube-proxy

kube-proxy — сетевой прокси, работающий на каждом узле в кластере, и реализующий часть концепции сервис.

kube-proxy конфигурирует правила сети на узлах. При помощи них разрешаются сетевые подключения к вашими подам изнутри и снаружи кластера.

kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика.

Среда выполнения контейнера

Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров.

Kubernetes поддерживает несколько сред для запуска контейнеров: Docker, containerd, CRI-O, и любая реализация Kubernetes CRI (Container Runtime Interface).

Дополнения

Некоторые из дополнений описаны ниже; более подробный список доступных расширений вы можете найти на странице Дополнения.

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

Кластерный DNS — это DNS-сервер наряду с другими DNS-серверами в вашем окружении, который обновляет DNS-записи для сервисов Kubernetes.

Контейнеры, запущенные посредством Kubernetes, автоматически включают этот DNS-сервер в свои DNS.

Веб-интерфейс (Dashboard)

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

Мониторинг ресурсов контейнера

Мониторинг ресурсов контейнера записывает общие метрики о контейнерах в виде временных рядов в центральной базе данных и предлагает пользовательский интерфейс для просмотра этих данных.

Логирование кластера

Механизм логирования кластера отвечает за сохранение логов контейнера в централизованном хранилище логов с возможностью их поиска/просмотра.

Что дальше

Общие соглашения API описаны на странице соглашений API.

Конечные точки API, типы ресурсов и примеры описаны в справочнике API.

Удаленный доступ к API обсуждается в Controlling API Access doc.

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

Kubernetes также сохраняет сериализованное состояние (в настоящее время в хранилище etcd) каждого API-ресурса.

Kubernetes как таковой состоит из множества компонентов, которые взаимодействуют друг с другом через собственные API.

Изменения в API

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

Определение совместимого изменения и методы изменения API подробно описаны в документе об изменениях API.

Определения OpenAPI и Swagger

Все детали API документируется с использованием OpenAPI.

Примеры получения спецификации OpenAPI:

До 1.10	С версии Kubernetes 1.10
GET /swagger.json	GET /openapi/v2 Accept: application/json
GET /swagger-2.0.0.pb-v1	GET /openapi/v2 Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf
GET /swagger-2.0.0.pb-v1.gz	GET /openapi/v2 Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf Accept-Encoding: gzip

В Kubernetes реализован альтернативный формат сериализации API, основанный на Protobuf, который в первую очередь предназначен для взаимодействия внутри кластера. Описание этого формата можно найти в проектом решении, а IDL-файлы по каждой схемы — в пакетах Go, определяющих API-объекты.

Версионирование API

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

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

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

API-группы

Чтобы упростить расширение API Kubernetes, реализованы группы API. Группа API указывается в пути REST и в поле apiVersion сериализованного объекта.

В настоящее время используется несколько API-групп:

Есть два поддерживаемых пути к расширению API с помощью пользовательских ресурсов:

Включение или отключение групп API

Включение определённых ресурсов в группу extensions/v1beta1

Изучение объектов Kubernetes

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

После создания объекта Kubernetes будет следить за существованием объекта. Создавая объект, вы таким образом указываете системе Kubernetes, какой должна быть рабочая нагрузка кластера; это требуемое состояние кластера.

Спецификация и статус объекта

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

Для получения дополнительной информации о спецификации объекта, статусе и метаданных смотрите документ с соглашениями API Kubernetes.

Описание объекта Kubernetes

Вывод будет примерно таким:

Обязательные поля

Конкретный формат поля-объекта spec зависит от типа объекта Kubernetes и содержит вложенные поля, предназначенные только для используемого объекта. В справочнике API Kubernetes можно найти формат спецификации любого объекта Kubernetes. Например, формат spec для объекта Pod находится в ядре PodSpec v1, а формат spec для Deployment — в DeploymentSpec v1 apps.

Что дальше

В инструменте командной строки kubectl есть несколько разных способов создания и управления объектами Kubernetes. На этой странице рассматриваются различные подходы. Изучите документацию по Kubectl для получения подробной информации по управлению объектами с помощью Kubectl.

Способы управления

Способ управления	Область применения	Рекомендуемое окружение	Количество поддерживаемых авторов	Трудность изучения
Императивные команды	Активные объекты	Проекты в стадии разработки	1+	Низкая
Императивная конфигурация объекта	Отдельные файлы	Продакшен-проекты	1	Средняя
Декларативная конфигурация объекта	Директории или файлы	Продакшен-проекты	1+	Сложная

Императивные команды

При использовании императивных команд пользователь работает непосредственно с активными (текущими) объектами в кластере. Пользователь указывает выполняемые операции команде kubectl в качестве аргументов или флагов.

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

Примеры

Запустите экземпляр контейнера nginx, посредством создания объекта Deployment:

То же самое, но с другим синтаксисом:

Плюсы и минусы

Преимущества по сравнению с конфигурацией объекта:

Недостатки по сравнению с конфигурацией объекта:

Императивная конфигурация объекта

В случае использования императивной конфигурации объекта команде kubectl устанавливают действие (создание, замена и т.д.), необязательные флаги и как минимум одно имя файла. Файл должен содержать полное определение объекта в формате YAML или JSON.

Посмотрите Справочник API для получения более подробной информации про определения объекта.

Примеры

Создать объекты, определенные в конфигурационном файле:

Удалить объекты, определенные в двух конфигурационных файлах:

Обновить объекты, определенные в конфигурационном файле, перезаписав текущую конфигурацию:

Плюсы и минусы

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

Недостатки по сравнению с императивными командами:

Преимущества по сравнению с декларативной конфигурацией объекта:

Недостатки по сравнению с декларативной конфигурацией объекта:

Декларативная конфигурация объекта

Примеры

Рекурсивная обработка директорий:

Плюсы и минусы

Преимущества по сравнению с императивной конфигурацией объекта:

Недостатки по сравнению с императивной конфигурацией объекта:

Что дальше

Каждый объект в кластере имеет уникальное имя для конкретного типа ресурса. Кроме этого, у каждого объекта Kubernetes есть собственный уникальный идентификатор (UID) в пределах кластера.

Для создания пользовательских неуникальных атрибутов у Kubernetes есть метки и аннотации.

Имена

Указанное имя может иметь только один объект определённого типа. Но если вы удалите этот объект, вы можете создать новый с таким же именем

Ниже перечислены три типа распространённых требований к именам ресурсов.

Имена поддоменов DNS

Большинству типов ресурсов нужно указать имя, используемое в качестве имени поддомена DNS в соответствии с RFC 1123. Соответственно, имя должно:

Имена меток DNS

Некоторые типы ресурсов должны соответствовать стандарту меток DNS, который описан в RFC 1123. Таким образом, имя должно:

Имена сегментов пути

Определённые имена типов ресурсов должны быть закодированы для использования в качестве сегмента пути. Проще говоря, имя не может быть «.» или «..», а также не может содержать «/» или «%».

Уникальные идентификаторы

Уникальная строка, сгенерированная самим Kubernetes, для идентификации объектов.

У каждого объекта, созданного в течение всего периода работы кластера Kubernetes, есть собственный уникальный идентификатор (UID). Он предназначен для выяснения различий между событиями похожих сущностей.

Уникальные идентификатор (UID) в Kubernetes — это универсальные уникальные идентификаторы (известные также как Universally Unique IDentifier, сокращенно UUID). Эти идентификаторы стандартизированы под названием ISO/IEC 9834-8, а также как ITU-T X.667.

Что дальше

Kubernetes поддерживает несколько виртуальных кластеров в одном физическом кластере. Такие виртуальные кластеры называются пространствами имён.

Причины использования нескольких пространств имён

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

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

Пространства имён — это способ разделения ресурсов кластера между несколькими пользователями (с помощью квоты ресурсов).

По умолчанию в будущих версиях Kubernetes объекты в одном и том же пространстве имён будут иметь одинаковую политику контроля доступа.

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

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

Создание и удаление пространств имён описаны в руководстве администратора по пространствам имён.

Просмотр пространств имён

Используйте следующую команду, чтобы вывести список существующих пространств имён в кластере:

По умолчанию в Kubernetes определены три пространства имён:

Определение пространства имён для отдельных команд

Определение пространства имён для всех команд

Можно определить пространство имён, которое должно использоваться для всех выполняемых команд kubectl в текущем контексте.

Пространства имён и DNS

Объекты без пространства имён

Большинство ресурсов Kubernetes (например, поды, сервисы, контроллеры репликации и другие) расположены в определённых пространствах имён. При этом сами ресурсы пространства имён не находятся ни в других пространствах имён. А такие низкоуровневые ресурсы, как узлы и persistentVolumes, не принадлежат ни одному пространству имён.

Чтобы посмотреть, какие ресурсы Kubernetes находятся в пространстве имён, а какие — нет, используйте следующие команды:

Что дальше

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

Метки используются при получении и отслеживании объектов и в веб-панелях и CLI-инструментах. Любая неидентифицирующая информация должна быть записана в аннотации.

Причины использования

Метки позволяют пользователям гибко сопоставить их организационные структуры с системными объектами, не требуя от клиентов хранить эти соответствия.

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

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

Синтаксис и набор символов

Префиксы kubernetes.io/ и k8s.io/ зарезервированы для использования основными компонентами Kubernetes.

Например, ниже представлен конфигурационный файл объекта Pod с двумя метками environment: production и app: nginx :

Селекторы меток

В отличие от имен и идентификаторов, метки не гарантируют уникальность. Поэтому мы предполагаем, что многие объекты будут иметь одинаковые метки.

С помощью селектора меток клиент/пользователь может идентифицировать набор объектов. Селектор меток — основное средство группировки в Kubernetes.

В настоящее время API поддерживает два типа селекторов: на равенстве и на наборе. Селектор меток может состоять из нескольких условий, разделенных запятыми. В таком случае все условия должны быть выполнены, поэтому запятая-разделитель работает как логический оператор И ( && ).

Работа пустых или неопределённых селекторов зависит от контекста. Типы API, которые использует селекторы, должны задокументировать это поведение.

Условие равенства

С помощью условия равенства в объектах Pod можно указать, какие нужно выбрать ресурсы. Например, в примере ниже объект Pod выбирает узлы с меткой » accelerator=nvidia-tesla-p100 «.

Условие набора

Фильтрация LIST и WATCH

Операции LIST и WATCH могут использовать параметр запроса, чтобы указать селекторы меток фильтрации наборов объектов. Есть поддержка обоих условий (строка запроса URL ниже показывается в исходном виде):

Либо используя условия на основе набора:

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

Либо можно воспользоваться исключающим сопоставлением с помощью оператора exists:

Установка ссылок в API-объекты

Service и ReplicationController

Ресурсы, поддерживающие условия набора

Выбор наборов узлов

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

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

Добавление метаданных к объектам

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

Аннотации, как и метки, являются коллекциями с наборами пар ключ-значение:

Некоторые примеры информации, которая может быть в аннотациях:

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

Информация о сборке, выпуске или образе, например, метка времени, идентификаторы выпуска, ветка git, номера PR, хеши образов и адрес реестра.

Ссылки на репозитории логирования, мониторинга, аналитики или аудита.

Информация о клиентской библиотеке или инструменте, которая может использоваться при отладке (например, имя, версия и информация о сборке).

Информация об источнике пользователя или инструмента/системы, например, URL-адреса связанных объектов из других компонентов экосистемы.

Небольшие метаданные развертывания (например, конфигурация или контрольные точки).

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

Инструкции от конечных пользователей по исправлению работы или использования нестандартной функциональности.

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

Синтаксис и набор символов

Префиксы kubernetes.io/ и k8s.io/ зарезервированы для использования основными компонентами Kubernetes.

Например, ниже представлен конфигурационный файл объекта Pod с аннотацией imageregistry: https://hub.docker.com/ :

Что дальше

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

Следующая команда kubectl выбирает все Pod-объекты, в которых значение поля status.phase равно Running :

По сути, селекторы полей являются фильтрами ресурсов. По умолчанию нет установленных селекторов/фильтров, поэтому выбираются ресурсы всех типов. Это означает, что два запроса kubectl ниже одинаковы:

Поддерживаемые поля

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

Составные селекторы

Множественные типы ресурсов

Можно использовать селекторы полей с несколькими типами ресурсов одновременно. Команда kubectl выбирает все объекты StatefulSet и Services, не включенные в пространство имен default :

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

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

Метаданные сосредоточены на понятии приложение. Kubernetes — это не платформа как услуга (PaaS), поэтому не закрепляет формальное понятие приложения. Вместо этого приложения являются неформальными и описываются через метаданные. Определение приложения довольно расплывчатое.

Метки

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

Ключ	Описание	Пример	Тип
app.kubernetes.io/name	Имя приложения	mysql	string
app.kubernetes.io/instance	Уникальное имя экземпляра приложения	wordpress-abcxzy	string
app.kubernetes.io/version	Текущая версия приложения (например, семантическая версия, хеш коммита и т.д.)	5.7.21	string
app.kubernetes.io/component	Имя компонента в архитектуре	database	string
app.kubernetes.io/part-of	Имя основного приложения, частью которого является текущий объект	wordpress	string
app.kubernetes.io/managed-by	Инструмент управления приложением	helm	string

Для демонстрации этих меток, рассмотрим следующий объект StatefulSet :

Приложения и экземпляры приложений

Одно и то же приложение может быть установлено несколько раз в кластер Kubernetes, в ряде случаев — в одинаковое пространство имен. Например, WordPress может быть установлен более одного раза, тогда каждый из сайтов будет иметь собственный установленный экземпляр WordPress.

Примеры

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

Простой сервис без состояния

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

Объект Service используется для открытия доступа к приложению.

Веб-приложение с базой данных

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

Следующий объект Deployment используется для WordPress:

Объект Service используется для открытия доступа к WordPress:

MySQL открывается в виде StatefulSet с метаданными как для самого приложения, так и основного (родительского) приложения, к которому принадлежит СУБД:

Объект Service предоставляет MySQL в составе WordPress:

Вы заметите, что StatefulSet и Service MySQL содержат больше информации о MySQL и WordPress.

Источник

Что такое Kubernetes?

Kubernetes стал первым выпускным проектом CNCF, и одним из самых быстро растущих проектов с открытым исходным кодом в истории. Над Kubernetes теперь работают более 2300 участников, и широко используется крупными и малыми компаниями, в том числе половиной Fortune 100.

Основы Kubernetes — ключевые понятия

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

Кластер

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

Это виртуальная или физическая машина. Кластер состоит из главного узла и ряда рабочих узлов.

Контейнер Cloud

Образ, содержащий программное обеспечение и его зависимости.

Отсек

Является одним контейнером или набором контейнеров, запущенным в Вашем кластере Kubernetes.

Развертывание

Объект, управляющий реплицированными приложениями, представленными отсеками. Отсеки развертываются на узлах кластера.

Набор реплик

Обеспечивает одновременное выполнение указанного числа реплик отсеков.

Сервис

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

Что такое KubeCon?

KubeCon — это ежегодная конференция для разработчиков и пользователей Kubernetes. С момента первого KubeCon в 2015 году, где было 500 участников, KubeCon стал важным мероприятием для сообщества cloud native технологий. В 2019 году в Сан-Диего в калифорнийской версии KubeCon приняли участие 12 000 разработчиков и инженеров по надежности сайтов, которые отмечали расширение экосистемы с открытым исходным кодом на базе облачной платформы оркестровки Kubernetes.

Что такое контейнеры Kubernetes?

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

Сравнение Kubernetes и Docker

Хотя контейнеры Linux существовали с 2008 года, известность им принесло появление контейнеров Docker в 2013 году. Similarly, the explosion of interest in deploying containerized applications—applications that contained everything they needed to run—ultimately created a new problem: managing thousands of containers. Kubernetes автоматически управляет жизненным циклом контейнера, распределяя контейнеры по хостинговой инфраструктуре. Kubernetes масштабирует ресурсы вверх или вниз в зависимости от потребностей. Содержит положения, графики, удаления и мониторинг состояния контейнеров.

Какие компоненты входят в состав Kubernetes?

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

Область управления содержит следующие элементы:

Компоненты узла включают в себя:

Каковы преимущества использования Kubernetes?

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

Kubernetes позволяет компаним:

выполнять автоматическое масштабирование;	расширять или сокращать развертывания в зависимости от потребностей.
Знакомство с сервисами	Поиск сервисов в контейнерах с помощью DNS или IP-адреса.
Балансировка нагрузки	Стабилизируйте развертывание, распределяя сетевой трафик.
Управление хранилищем	Выберите локальное или облачное хранилище.
Управление версиями	Выберите типы контейнеров, которые планируется запускать и которые следует заменить, используя новые ресурсы образа или контейнера.
Обеспечение безопасности	Безопасное обновление паролей, маркеров OAuth и ключей SSH, связанных с конкретными образами контейнеров.

Какие проблемы возникают при использовании Kubernetes?

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

Kubernetes развертывает контейнеры, а не исходный код и не создает приложения. Для журналирования, промежуточного ПО, мониторинга, настройки, непрерывной интеграции и развертывания ПО и многих других производственных операций необходимы дополнительные инструменты. Таким образом, Kubernetes является расширяемой и отлично подходит для самых разных сценариев использования: от авиации до машинного обучения. По сути, поставщики облачных решений, включая Oracle, Google, Amazon Web Services и другие, использовали собственные возможности расширения Kubernetes для создания управляемой среды Kubernetes, которая обеспечивает сокращение сложности и повышение производительности разработчиков.

What is managed Kubernetes?

Наша облачная инфраструктура Container Engine for Kubernetes — это удобный для разработчиков управляемый сервис с возможностью использования для развертывания контейнерных приложений в облаке. Используйте Container Engine for Kubernetes для надежного создания и развертывания cloud native приложений и управления ими. Вы указываете вычислительные ресурсы, необходимые для приложений, и Container Engine for Kubernetes их инициализирует в существующей области аренды облачной инфраструктуры.

Хотя Вам не требуется использовать управляемый сервис Kubernetes, наш Container Engine for Kubernetes предлагает простой способ запуска высокодоступных кластеров с возможностями управления, безопасности и предсказуемой производительностью Oracle Cloud Infrastructure. Container Engine for Kubernetes поддерживает как выделенные серверы Bare Metal, так и виртуальные машины в качестве узлов и сертифицируется в соответствии с требованиями CNCF. Вы также получаете все обновления Kubernetes, и сохраняется совместимость с экосистемой CNCF без дополнительных трудозатрат с Вашей стороны.

Cloud native и Kubernetes меняют подход к поддержке авторов AgroScout.

Источник