Кубернетис для чего нужен
Основы 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 все уши прожужжали. А нужен ли он вашему проекту?
Недавно мы писали статью на VC про аудит Kubernetes. И получили несколько личных сообщений примерно такого характера: «А вы можете по-человечески объяснить, зачем и в каких случаях этот кубернетис нужен? А то все ставят, все хвалят, а понять, нужен ли он моему проекту, — не получается. «
Технически корректный ответ на вопрос «что такое Kubernetes?» — «система для оркестрации контейнезированных приложений» — не особо помогает понять, почему он так популярен в технологических компаниях. Поэтому давайте начнём с того, что попробуем разобраться, почему и для чего компании используют Kubernetes — при этом не прибегая к очевидной формулировке «чтобы управлять контейнерами, зачем же ещё. »
Основная причина использования Kubernetes в компаниях, зарабатывающих на производстве и применении ПО, заключается в том, что изменился подход к разработке. Подход в построении технологических архитектур сместился с больших единых приложений в сторону множества маленьких программ, которые взаимодействуют между собой. Грубо говоря, вместо Microsoft Word разработчики предпочитают делать набор сервисов, наделённых каждый своей функцией, от проверки орфографии до вставки маркированного списка, и объединённых в единую систему. Идея в том, чтобы помогать бизнесу легче внедрять изменения.
Давайте представим, что большое приложение — это дом. В нём нельзя просто убрать одну из стен, другую переместить, а третью переделать на лету из какого-то совершенно иного материала: дом станет неустойчивым или вообще рассыплется. А теперь представим, что приложение похоже на улей. В нём гораздо проще передвигать и изменять соты… Но когда в улье десятки тысяч компонентов, этих микросервисов, и все они работают сами по себе, появляется вопрос: как этим всем управлять? Как узнать, что все они правильно общаются между собой и что ничего не отвалилось? Как не сойти с ума, дирижируя этим оркестром?
Около шести лет назад для этих целей появились специальные системы. Так получилось, что Google и еще несколько компаний выпустили продукт под названием Kubernetes, который оказался гибче и мощнее остальных. Так как его функциональность для управления инфраструктурой различных приложений была шире, Kubernetes набрал большую популярность. Есть и другие решения, например, HashiCorp Nomad и Docker Swarm, но Kubernetes сейчас используется активнее прочих.
Однако бизнесу нужен не Kubernetes как таковой. На идеологическом уровне бизнесу нужна система, которая позволит микросервисной архитектуре не рассыпаться, чтобы бизнес мог постоянно меняться.
С точки зрения бизнеса будет правильнее сказать: «Мы решили быть гибкими, способными легко подстраиваться под запросы рынка и внедрять фичи быстрее конкурентов. И для этого используем подходящую из доступных технологий». А доступная технология, в свою очередь, сейчас это Kubernetes.
Чтобы найти ответ на вопрос «почему?» из заголовка, полезно понять, почему же другие компании стали использовать Kubernetes, какой в этом был бизнес-интерес. Примерить на себя, подходит ли компании переход к микросервисной архитектуре и DevOps. И если да, то имеет смысл внедрить Kubernetes. Но не «внедрить Kubernetes и всё», а изменить процесс разработки.
Исследование DORA’s State of DevOps подсказывает, какие понадобятся изменения, и одно из самых существенных — это сокращение цикла разработки от идеи до доставки пользователю. Чем он короче, чем чаще разработчик выкладывает свой код в продакшен-окружение, тем ниже риск аварий и тем выше гибкость. Частые изменения позволяют быстро проверять гипотезы, но при этом, так как они малы, меньше вероятность серьезных аварий. А если всё же что-то пошло не так, изменения легче откатить и устранить последствия аварии.
Успешный бизнес отличают не конкретные технологические решения, а идеологические и процессные. Так, многие технологичные компании добиваются лидерства, внедряя методологию DevOps. DevOps и другие гибкие подходы к разработке позволяют эффективнее использовать ресурсы и не тратить годы на проект, который, неизвестно, выстрелит или прогорит. С помощью изменений, позволяющих проверить жизнеспособность гипотезы, компании, выбравшие такой путь, минимизируют риски. Но для того, чтобы разрабатывать приложения небольшими шагами, нужно подготовить команду разработки. А для этого, в свою очередь, организовать инфраструктуру: развернуть Kubernetes-кластеры или другую систему, которая будет управлять ульем приложений, и адаптироваться к частым изменениям кодовой базы.
Главное бизнес-преимущество DevOps — снижается количество инвестиций на проверку теорий и запуск новой функциональности.
Раньше, когда эксперимент оказывался неудачным и пользователи требовали «вернуть стену», нужно было откатывать всё приложение на предыдущую версию, разворачивать бэкапы, чтобы вернуть структуру данных, и грустить. Теперь же с современными технологиями можно сделать небольшой редизайн и проверить его на части аудитории (часто экспериментируют на отдельных странах, например, Турции), посмотреть на реакцию пользователей и дальше уже по ситуации, распространить на всех, либо немедленно откатить. К тому же в DevOps-идеологии и с использованием возможностей, которые дают Kubernetes и микросервисная архитектура, меньше ресурсов требуется на тестирование. Так как изменения маленькие, то в процессе разработки новой фичи тестирование и анализ занимают небольшое место. Потому что, если окажется, что есть проблема и она простая, — мы исправим её за несколько минут и выкатим новую версию. Если проблема серьезная — быстро откатимся к предыдущей версии и пользователи не пострадают. Если будет ошибка в тестировании — проверим на стране с маленьким трафиком, поймём, что нужно оптимизировать, и пустим больше трафика. Это всё также сокращает цену эксперимента.
Kubernetes дает унификацию в способе обслуживания всего «улья приложений». Можно сказать, что это задача любой системы оркестрации, но Kubernetes здесь де-факто стандарт. С практической точки зрения распространённость Kubernetes означает уверенность в том, что это решение, которое:
Большое сообщество вокруг ПО — важный (если не решающий) момент. Например, вспомним ситуацию с операционными системами лет пятнадцать лет назад: кроме Linux, были ещё FreeBSD, SunOS и др. У них были свои преимущества, но так получилось, что Linux стал популярней. Во многом это произошло, потому что у Linux была большая группа поддержки, многие люди его использовали, работали над улучшениями и продолжают это делать. С технической точки зрения Kubernetes на своём сайте акцентирует внимание на трёх преимуществах. Попробуем объяснить, что все они значат на практике.
А кроме того, Kubernetes — унифицированная технология, поэтому снижается порог входа новых сотрудников и нет рисков велосипедостроения. Kubernetes применяется в огромном количестве компаний, а значит, не окажется, что всё изначально было сделано неправильно, как может получиться с самописными решениями.
Если вы не знаете, зачем вам Kubernetes, то, вполне возможно, он вам и незачем. Если вы слышите, что все Kubernetes применяют, и думаете, что наверное вам тоже нужно, но не понимаете точно, какую задачу с его помощью собираетесь решать, то Kubernetes вам не нужен. Вопрос, стоит ли применить Kubernetes как техническое решение, примерно такой же, как вопрос, стоит ли перейти с Linux CentOS (упокой господь его душу) на Linux Ubuntu. Фичи там, скорее всего, похожие, и важнее, есть ли в компании люди, которые к этому готовы и которым будет удобнее после перехода, есть ли процессы, которые станут эффективнее, и т.п. Техническое решение в данном случае очень тесно связано с организационными решениями.
Kubernetes не нужен:
Но! Даже в этом случае есть два аргумента в пользу того, чтобы попробовать Kubernetes (точнее, попробовать изменить все свои технологические подходы и к администрированию, и к разработке) отчасти под влиянием популярности. Во-первых, технарям всегда хочется технически развиваться и пробовать что-то новое. Это большой вопрос для бизнеса, стоит ли идти на поводу у любопытства сотрудников, но если его игнорировать, то рано или поздно им станет скучно, и они уйдут. Во-вторых, если вы решитесь на внедрение Kubernetes, то расширить штат будет относительно просто. Всё-таки это самая популярная система оркестрации, и через найти в команду Kubernetes-инженера ощутимо проще, чем знатока того же HashiCorp.
Если вы всё-таки берётесь за внедрение Kubernetes, то нужно решить ещё один вопрос: поднимать его на выделенных серверах или в облаке.
Вариант облака предпочтительнее, потому что Kubernetes изначально ориентирован на облачные хостинг-решения. В облаке легко добавлять узлы, изменять конфигурацию и создавать сущности буквально за минуту.
К тому же облачные провайдеры уже справились с болезнями стабильного дискового хранилища, с которыми придётся столкнуться при разворачивании кластера на собственных серверах. Нет смысла набивать собственные шишки, когда есть AWS, Google Cloud, Azure Cloud, DigitalOcean и российские Яндекс.Облако, Selectel, Mail.Ru Cloud Solutions и другие. С точки зрения гибкости, для которой, собственно, и применяется Kubernetes, правильно использовать их.
Для компаний разного размера на рентабельность решения будут влиять разные факторы.
В небольшом стартапе даже разработчики должны понимать, хотя бы базово, как управлять Kubernetes-кластером и деплоить туда приложения. Это усложняет подбор участников команды, но иначе в стартапе никак. И совершенно точно нужно воспользоваться услугами облачного хостинг-провайдера. Возможно, в этом случае будет сложнее оценить будущие затраты на инфраструктуру, зато полностью снимается вопрос внедрения, потому что в большинстве облаков Kubernetes уже есть по умолчанию.
Средние и крупные компании ждёт тяжелая работа и по подготовке инфраструктуры, и по организационным изменениям. Здесь трудно точно рассчитать все риски и потенциальную пользу и строго определить, при каких условиях начинать внедрение Kubernetes. Но похожая ситуация и с любыми элементами технологического стека, рано или поздно требующими изменений, например, старыми языками программирования. Pearl не то чтобы фундаментально плохой язык программирования, с ним возможно жить. Но ему на смену пришли другие языки, лучше подходящие под современные запросы.
Конечно, стоимость внедрения будет отличаться в зависимости от ситуации и сложности инфраструктуры. Но почти всегда её можно снизить, воспользовавшись облачным хостинг-провайдером, хотя бы за счет того, что не потребуется создавать саму базу инфраструктуры Kubernetes на железных серверах.
Также снизить расходы могут готовые решения. Компании, предоставляющие такие решения, и мы в ITSumma в частности, уже набили шишки, которые не понадобится набивать заново в поисках верного пути. Мы можем проанализировать процессы разработки и найти наиболее удачный канал доставки программного обеспечения в каждом конкретном случае.
Если ваша компания до сих пор не перешла к гибким процессам, у вас длинный цикл разработки и вам кажется, что новые фичи слишком медленно доходят до пользователей, то скорее всего пора что-то менять. И прежде всего менять нужно мышление. Наш совет не в том, чтобы использовать Kubernetes, а в том, чтобы изменится так, чтобы вам потребовался Kubernetes или то, что придёт ему на смену.
Если вы по-прежнему не понимаете, почему все вокруг говорят Kubernetes и зачем он конкретно вам — то и нафиг он вам нужен. Серьёзно.
А если не хотите отставать от лидеров, но вам нужна помощь с адаптацией инфраструктуры под работу с контейнеризированными приложениями или с тем, как, собственно, измениться, — вы знаете, как её найти 🙂
Kubernetes для чайников: установка, настройка и основы
Содержание:
Контейнеризация приложений — один из главных трендов современных IT-разработок. Однако, у контейнеров есть один существенный недостаток для массового потребителя — сложная настройка масштабирования.
Решением стали автоматические системы управления контейнеризацией, наиболее популярной из которых является Kubernetes. Это программное обеспечение с открытым исходным кодом от компании Google завоевало признание благодаря сочетанию гибкости, безопасности и мощности.
Cтатья «Kubernetes для чайников» поможет разобраться как устроена платформа управления контейнеризацией, как установить ПО и для чего его можно использовать в дальнейшем. Она будет полезна как для начинающих пользователей Kubernetes, так и для профильных IT-специалистов.
История создания
Проект Kubernetes (сокращенно K8s) вырос из системы управления кластерами Borg. Внутренний продукт поискового гиганта Google получил название в честь кибер-рассы боргов из легендарного сериала «Звездный путь».
Команде разработчиков Google Borg была поставлена масштабная задача — создать открытое программное обеспечение для оркестрирования* контейнеров, которое станет вкладом Google в развитие мировых IT-технологий. Приложение было написано на основе языка Go.
* Под «оркестрированием» подразумевается автоматизированное управление связанными сущностями — контейнерами или виртуальными машинами.
На этапе разработки K8s назвался Project Seven («Проект «Седьмая»). Это было прямой отсылкой к персонажу «Звездного пути» Seven of Nine («Седьмая-из-девяти») — андроиду-боргу, сумевшему вернуть себе человечность. Позже проект получил имя «Кубернетес», от греческого слова κυβερνήτης, которое означает «управляющий», «рулевой» или «кормчий».
В 2014 году общественности представили исходные коды, а годом позже появилась первая версия программы Kubernetes 1.0. В дальнейшем все права на продукт были переданы некоммерческому фонду Cloud Native Computing Foundation (CNCF), куда входят Google, The Linux Foundation и ряд крупнейших технологических корпораций.
Как работает технология
Принципы устройства
Основы работы K8s – применение декларативного подхода. От разработчика требуется указать, чего необходимо достичь, а не способы достижения.
Помимо этого, в Kubernetes могут быть задействованы императивные команды (create, edit, delete), которые позволяют непосредственно создавать, модифицировать и удалять ресурсы. Однако, их не рекомендуется использовать для критически важных задач.
Для развертывания программного обеспечения в Kubernetes применяется база Linux-контейнеров (например, Containerd или CRI-O) и описание — сколько потребуется контейнеров и в каком количестве им потребуются ресурсы. Само развертывание контейнеров происходит на основе рабочих нод — виртуальных или физических машин.
Основные задачи Kubernetes
Преимущества K8s
Kubernetes – удобный инструмент оркестрации контейнеров. Однако, это решение, не работает само по себе, без подготовки и дополнительных настроек. Например, пользователям придется решать вопросы по миграции схем баз данных или разбираться с обратной совместимостью API.
Основные компоненты
Схема взаимодействия основных компонентов K8s
Node (Нода)
Ноды или узлы — виртуальные или физические машины, на которых разворачивают и запускают контейнеры. Совокупность нод образует кластер Kubernetes.
Первая запущенная нода или мастер-нода непосредственно управляет кластером, используя для этого менеджер контроллеров (controller manager) и планировщик (scheduler). Она ответственна за интерфейс взаимодействия с пользователями через сервер API и содержит в себе хранилище «etcd» с конфигурацией кластера, метаданными и статусами объектов.
Namespace (Пространство имен)
Объект, предназначенный для разграничения ресурсов кластера между командами и проектами. Пространства имен — несколько виртуальных кластеров, запущенные на одном физическом.
Pod (Под)
Первичный объект развертывания и основной логический юнит в K8s. Поды — набор из одного и более контейнеров для совместного развертывания на ноде.
Группировка контейнеров разных типов требуется в том случае, когда они взаимозависимы и должны запускаться в одной ноде. Это позволяет увеличить скорость отклика во время взаимодействия. Например, это могут быть контейнеры, хранящие веб-приложение и сервис для его кэширования.
ReplicaSet (Набор реплик)
Объект, отвечающий за описание и контроль за несколькими экземплярами (репликами) подов, созданных на кластере. Наличие более одной реплики позволяет повысить устойчивость от отказов и масштабирование приложение. На практике ReplicaSet создается с использованием Deployment.
ReplicaSet является более продвинутой версией предыдущего способа организации создания реплик (репликации) в K8s – Replication Controller.
Deployment (Развертывание)
Объект, в котором хранится описание подов, количество реплик и алгоритм их замены в случае изменения параметров. Контроллер развертывания позволяет выполнять декларативные обновления (с помощью описания нужного состояния) на таких объектах, как ноды и наборы реплик.
StatefulSet (Набор состояния)
Как и другие объекты, например — ReplicaSet или Deployment, Statefulset позволяет развертывать и управлять одним или несколькими подами. Но в отличие от них, идентификаторы подов имеют предсказуемые и сохраняемые при перезапуске значения.
DaemonSet (Набор даемона)
Объект, который отвечает за то, чтобы на каждой отдельной ноде (или ряде выбранных) запускался один экземпляр выбранного пода.
Job/CronJob (Задания/Задания по расписанию)
Объекты для регулировки однократного или регулярного запуска выбранных подов и контроля завершения их работы. Контроллер Job отвечает за однократный запуск, CronJob — за запуск нескольких заданий по расписанию.
Label/Selector (Метки/Селекторы)
Метки предназначены для маркировки ресурсов. Позволяют упростить групповые манипуляции с ними. Селекторы позволяют выбирать/фильтровать объекты на основе значения меток.
По факту, метки и селекторы не являются самостоятельными объектами Kubernetes, но без них система не сможет полноценно функционировать.
Service (Сервис)
Средство для публикации приложения как сетевого сервиса. Используется, в том числе, для балансировки трафика/нагрузки между подами.
Процесс установки
Установка Kubernetes, рассмотренная ниже, предполагает наличие одного (или более) серверов с операционной системой Centos 7 или Ubuntu 16.04.
Затем открыть «/etc/fstab» с правами root и удалить соответствующую команде строчку «#/swapfile».
Проект Kubernetes действует на основе контейнеров Docker, существенно расширяя их функциональность. Логично, что начинать работу Kubernetes следует именно с установки Docker.
Проще всего остановить выбор на версии, добавленной на текущий момент в репозитории. Ее протестировали разработчики Kubernetes и она работает наиболее стабильно.
Установка контейнеров на Ubuntu 16.04
Чтобы установить Docker на Ubuntu 16.04, необходимо выполнить следующие команды с правами суперпользователя:
Если требуется работать с более новыми версиями контейнеров, запустите команды:
Установка контейнеров в CentOS 7
Для установки Docker на Centos, в консоли нужно выполнить команды:
Установка kubeadm, kubelet и kubectl в Ubuntu
Для работы с Kubernetes понадобится установить компоненты kubeadm, kubelet и kubectl. Эти утилиты понадобятся для создания управления кластером Kubernetes.
В Ubuntu эти компоненты можно установить следующим способом:
Установка kubeadm, kubelet и kubectl в CentOS
В CentOS 7 компоненты устанавливаются следующим образом:
Обращаем внимание! Команда setenforce 0 позволит получить корректный доступ контейнеров к файловой системе хоста. Последняя необходима для функционирования сети у подов.
Нужно убедиться, что «kubelet» и «docker» пользуются одним и тем же драйвером «cgroup». В этом может помочь команда:
Настройка Kubernetes
Инициализация кластера
Нужно указать сервер, на котором установлен K8s (он будет первичным — там будут запускаться остальные операции) и выполнить инициализацию кластера:
Обращаем внимание! Опция «—pod-network-cidr» задает адрес виртуальной сети подов и может отличаться, в зависимости от используемого сетевого плагина.
В данном примере будем использован наиболее распространенный сетевой плагин — Flannel. По умолчанию он использует сеть «10.244.0.0/16», которая была указана в параметре, приведенном выше.
При выполнении команды в консоли, есть вероятность появления ошибок или предупреждений. Ошибки нужно исправлять в обязательном порядке, а на предупреждения можно не обращать внимание, если это не окружение «production».
Если все сделано правильно, на экране отобразится команда, позволяющая присоединить остальные ноды кластера к первичному хосту. Команда может отличаться, в зависимости от структуры кластера. Ее нужно сохранить на будущее.
После выполнения этой команды система выведет примерный результат:
Остается выполнить следующие команды от имени пользователя, который будет управлять кластером:
Настройка CNI
Перед тем, как начать запускать в кластере приложения, нужно выполнить настройку Container Network Interface («сетевой интерфейс контейнера» или CNI). CNI нужен для настройки взаимодействия и управления контейнерами внутри кластера.
Существует много плагинов для создания CNI. В данном примере применяется Flannel, так как это наиболее простое и проверенное решение. Однако, не меньшей популярностью пользуются плагины Weave Net от компании Weaveworks и Calico (Project Calico), обладающие более широким функционалом и возможностями сетевых настроек.
Чтобы установить Flannel, выполните в терминале команду:
В выводе будут отображены имена всех созданных ресурсов.
Добавление узлов (нод) в кластер
Чтобы добавить новые ноды в существующий кластер, требуется выполнить следующий алгоритм:
Данная команда была выведена при выполнении команды «kubeadm init» на мастер-ноде.
Если команда не была сохранена, то можно ее составить повторно.
Получение токена авторизации кластера ( )
Если токена нет, его можно получить, выполнив следующую команду на мастер-ноде:
Вывод должен быть примерно таков:
По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен следующей командой:
Вывод будет примерно таков:
Если значение параметра «—discovery-token-ca-cert-hash» неизвестно, его можно получить следующей командой:
Будет получен примерно такой вывод:
Для ввода IPv6-адреса в параметр « : », адрес должен быть заключен в квадратные скобки. Например:
Дополнительные настройки
В дефолтной конфигурации мастер-нода не запускает контейнеры, так как занимается отслеживанием состояния кластера и перераспределением ресурсов. Ввод данной команды даст возможность запускать контейнеры на мастере, собенно, если кластер содержит лишь одну ноду:
Проверка работоспособности кластера
Проверить, что кластер запустился и правильно работает, можно так:
Вывод будет аналогичен. В нем будут отображены системные POD’ы k8s.
Теперь установку можно считать завершенной. Далее можно продолжить настройку K8s для работы с веб-приложениями. Например, подключить диспетчер пакетов «helm» для автоматического развертывания приложений или контроллер «nginx ingress», отвечающий за маршрутизацию внешнего трафика.
Заключение
Несмотря на кажущуюся сложность настройки, K8s стоит времени, потраченного на его изучение. Kubernetes — наиболее совершенный на сегодня инструмент оркестрирования контейнеров. Он позволяет не только автоматизировать процесс развертывания, но и максимально упрощает дальнейший процесс работы с массивами контейнеров.
С помощью этого краткого руководства начать работу с K8s сможет даже начинающий пользователь. В дальнейшей работе с платформой поможет подробная официальная документация, доступная, в том числе, на русском языке.