Убунту 20.04

Введение

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

Note: В этом руководстве используется версия Kubernetes 1.22, официальная поддерживаемая версия на момент публикации этой статьи. Актуальную информацию о последней версии можно найти в текущих примечаниях к выпуску в официальной документации Kubernetes.

Kubeadm автоматизирует установку и настройку компонентов Kubernetes, таких как сервер API, диспетчер контроллеров и Kube DNS. Однако он не создает пользователей и не управляет установкой зависимостей уровня операционной системы и их конфигурацией. Для этих предварительных задач можно использовать инструмент управления конфигурацией, такой как Ansible или SaltStack. Использование этих инструментов значительно упрощает создание дополнительных кластеров или воссоздание существующих кластеров и снижает вероятность ошибок.

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

Цели

Ваш кластер будет включать в себя следующие физические ресурсы:

  • One Control Plane node

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

  • Two worker nodes

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

После выполнения этого руководства у вас будет кластер, готовый к запуску контейнерных приложений, при условии, что серверы в кластере имеют достаточные ресурсы ЦП и ОЗУ для использования вашими приложениями. Практически любое традиционное приложение Unix, включая веб-приложения, базы данных, демоны и инструменты командной строки, можно поместить в контейнер и запустить в кластере. Сам кластер будет потреблять около 300-500 МБ памяти и 10% ЦП на каждом узле.

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

Предварительные условия

  • Пара ключей SSH на вашем локальном компьютере с Linux/macOS/BSD. Если вы раньше не использовали ключи SSH, вы можете узнать, как их настроить, следуя этому объяснению того, как настроить ключи SSH на вашем локальном компьютере.

  • Три сервера под управлением Ubuntu 20.04, минимум 2 ГБ ОЗУ и 2 виртуальных ЦП каждый. У вас должна быть возможность подключаться по SSH к каждому серверу в качестве пользователя root с вашей парой ключей SSH.

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

  • Ansible установлен на вашем локальном компьютере. Если вы используете Ubuntu 20.04 в качестве ОС, следуйте разделу «Шаг 1 — Установка Ansible» в разделе «Как установить и настроить Ansible в Ubuntu 20.04», чтобы установить Ansible. Инструкции по установке на других платформах, таких как macOS или Rocky Linux, можно найти в официальной документации по установке Ansible.

  • Знакомство с плейбуками Ansible. Для обзора ознакомьтесь с Управлением конфигурациями 101: Написание сборников сценариев Ansible.

  • Знание того, как запустить контейнер из образа Docker. Если вам нужно освежить знания, посмотрите «Шаг 5 — Запуск Docker-контейнера» в разделе «Как установить и использовать Docker в Ubuntu 20.04».

Шаг 1 — Настройка каталога рабочей области и файла инвентаризации Ansible

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

Из трех ваших серверов один будет плоскостью управления с IP-адресом, отображаемым как control_plane_ip . Два других сервера будут рабочими и будут иметь IP-адреса worker_1_ip и worker_2_ip .

Создайте каталог с именем ~/kube-cluster в домашнем каталоге вашего локального компьютера и cd в него:

Этот каталог будет вашим рабочим пространством до конца урока и будет содержать все ваши сборники сценариев Ansible. Это также будет каталог, внутри которого вы будете запускать все локальные команды.

Создайте файл с именем ~/kube-cluster/hosts с помощью nano или вашего любимого текстового редактора:

Добавьте в файл следующий текст, который будет содержать информацию о логической структуре вашего кластера:

~/kube-кластер/хосты

Возможно, вы помните, что файлы инвентаризации в Ansible используются для указания информации о сервере, такой как IP-адреса, удаленные пользователи и группы серверов, которые будут использоваться как единое целое для выполнения команд. ~/kube-cluster/hosts будет вашим файлом инвентаризации, и вы добавили в него две группы Ansible ( control plane и workers ), определяющие логическую структуру вашего кластера.

В группе control plane есть запись сервера с именем «control1», в которой указан IP-адрес плоскости управления ( control_plane_ip ) и указано, что Ansible должен запускать удаленные команды от имени пользователя root.

Аналогично, в workers группе есть две записи для рабочих серверов ( worker_1_ip и worker_2_ip ), которые также указывают ansible_user как root.

Последняя строка файла сообщает Ansible использовать интерпретаторы Python 3 удаленных серверов для операций управления.

Сохраните и закройте файл после добавления текста. Если вы используете nano , нажмите Ctrl+X , затем при появлении запроса Y и Enter .

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

Шаг 2. Создание пользователя без полномочий root на всех удаленных серверах

В этом разделе вы создадите пользователя без полномочий root с привилегиями sudo на всех серверах, чтобы вы могли подключаться к ним по SSH вручную как непривилегированный пользователь. Это может быть полезно, если, например, вы хотите просмотреть информацию о системе с помощью таких команд, как top/htop , просмотреть список запущенных контейнеров или изменить файлы конфигурации, принадлежащие пользователю root. Эти операции регулярно выполняются во время обслуживания кластера, и использование пользователя без полномочий root для таких задач сводит к минимуму риск изменения или удаления важных файлов или непреднамеренного выполнения других опасных операций.

Создайте файл с именем ~/kube-cluster/initial.yml в рабочей области:

Затем добавьте в файл следующую команду, чтобы создать пользователя без полномочий root с привилегиями sudo на всех серверах. Игра в Ansible — это набор шагов, которые необходимо выполнить для конкретных серверов и групп. Следующая игра создаст пользователя sudo без полномочий root:

~/kube-cluster/initial.yml

Вот разбивка того, что делает эта книга:

  • Создает пользователя ubuntu без полномочий root.

  • Настраивает файл sudoers , чтобы позволить пользователю ubuntu запускать команды sudo без запроса пароля.

  • Добавляет открытый ключ на вашем локальном компьютере (обычно ~/.ssh/id_rsa.pub ) в список авторизованных ключей удаленного пользователя ubuntu . Это позволит вам подключаться по SSH к каждому серверу в качестве пользователя ubuntu .

Сохраните и закройте файл после добавления текста.

Затем запустите плейбук локально:

Команда выполнится в течение двух-пяти минут. По завершении вы увидите вывод, аналогичный следующему:

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

Шаг 3 — Установка зависимостей Kubernetetes

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

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

  • kubeadm — инструмент CLI, который стандартным образом установит и настроит различные компоненты кластера.

  • kubelet — системная служба/программа, которая работает на всех узлах и обрабатывает операции на уровне узлов.

  • kubectl — инструмент CLI, используемый для выдачи команд кластеру через его API-сервер.

Создайте файл с именем ~/kube-cluster/kube-dependencies.yml в рабочей области:

Добавьте в файл следующие фрагменты, чтобы установить эти пакеты на ваши серверы:

~/kube-cluster/kube-dependents.yml

Первая пьеса в сборнике пьес делает следующее:

  • Устанавливает Docker, среду выполнения контейнера, и настраивает параметры совместимости.

  • Устанавливает apt-transport-https , позволяющий добавлять внешние источники HTTPS в список источников APT.

  • Добавляет apt-ключ репозитория Kubernetes APT для проверки ключа.

  • Добавляет репозиторий APT Kubernetes в список источников APT ваших удаленных серверов.

  • Устанавливает kubelet и kubeadm .

Второй этап состоит из одной задачи, которая устанавливает kubectl на ваш узел плоскости управления.

Note: Хотя в документации Kubernetes рекомендуется использовать последнюю стабильную версию Kubernetes для вашей среды, в этом руководстве используется конкретная версия. Это гарантирует, что вы сможете успешно следовать инструкциям, поскольку Kubernetes быстро меняется, и последняя версия может не работать с этим руководством. Хотя «xenial» — это название Ubuntu 16.04, а это руководство предназначено для Ubuntu 20.04, Kubernetes по-прежнему ссылается на исходные коды пакетов Ubuntu 16.04 по умолчанию, и в данном случае они поддерживаются 20.04.

Сохраните и закройте файл, когда закончите.

Затем запустите плейбук локально с помощью следующей команды:

По завершении вы получите вывод, аналогичный следующему:

После запуска этой книги Docker, kubeadm и kubelet будут установлены на всех удаленных серверах. kubectl не является обязательным компонентом и нужен только для выполнения команд кластера. В этом контексте имеет смысл установить его только на узле плоскости управления, поскольку вы будете запускать команды kubectl только из плоскости управления. Однако обратите внимание, что команды kubectl можно запускать с любого рабочего узла или с любого компьютера, где он может быть установлен и настроен для указания на кластер.

Все системные зависимости теперь установлены. Давайте настроим узел плоскости управления и инициализируем кластер.

Шаг 4 — Настройка узла плоскости управления

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

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

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

Эта функциональность обеспечивается плагинами сети модулей. Для этого кластера вы будете использовать Flannel — стабильный и производительный вариант.

Создайте плейбук Ansible с именем control-plane.yml на своем локальном компьютере:

Добавьте в файл следующую команду для инициализации кластера и установки Flannel:

~/kube-cluster/control-plane.yml

Вот разбивка этой пьесы:

  • Первая задача инициализирует кластер, запустив kubeadm init . Передача аргумента --pod-network-cidr=10.244.0.0/16 указывает частную подсеть, из которой будут назначены IP-адреса модулей. Flannel по умолчанию использует указанную выше подсеть; мы говорим kubeadm использовать ту же подсеть.

  • Вторая задача создает каталог .kube в /home/ubuntu . В этом каталоге будет храниться информация о конфигурации, такая как файлы ключей администратора, необходимые для подключения к кластеру, и адрес API кластера.

  • Третья задача копирует файл /etc/kubernetes/admin.conf , созданный при kubeadm init в домашний каталог пользователя без полномочий root. Это позволит вам использовать kubectl для доступа к вновь созданному кластеру.

  • Последняя задача запускает kubectl apply для установки Flannel . kubectl apply -f descriptor.[yml|json] — это синтаксис, указывающий kubectl на создание объектов, описанных в файле descriptor.[yml|json] . Файл kube-flannel.yml содержит описания объектов, необходимых для настройки Flannel в кластере.

Сохраните и закройте файл, когда закончите.

Запустите playbook локально с помощью следующей команды:

По завершении вы увидите вывод, аналогичный следующему:

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

Оказавшись внутри узла плоскости управления, выполните:

Теперь вы увидите следующий вывод:

Note: Начиная с Ubuntu 20.04, kubernetes находится в процессе обновления своей старой терминологии. Узел, который мы в этом руководстве называли control-plane раньше назывался master узлом, и иногда вы можете увидеть, как Kubernetes назначает обе роли одновременно из соображений совместимости.

В выходных данных указывается, что узел control-plane выполнил все задачи инициализации и находится в состоянии Ready , из которого он может начать принимать рабочие узлы и выполнять задачи, отправленные на сервер API. Теперь вы можете добавить работников со своей локальной машины.

Шаг 5 — Настройка рабочих узлов

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

Вернитесь в свою рабочую область и создайте книгу с именем workers.yml :

Добавьте в файл следующий текст, чтобы добавить рабочие процессы в кластер:

~/kube-cluster/workers.yml

Вот что делает playbook:

  • Первая игра получает команду соединения, которую необходимо запустить на рабочих узлах. Эта команда будет иметь следующий формат: kubeadm join --token : --discovery-token-ca-cert-hash sha256: . Как только она получает фактическую команду с правильными значениями token и hash функции, задача устанавливает ее как факт, чтобы следующая игра могла получить доступ к этой информации.

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

Сохраните и закройте файл, когда закончите.

Запустите playbook локально с помощью следующей команды:

По завершении вы увидите вывод, аналогичный следующему:

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

Шаг 6 — Проверка кластера

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

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

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

Вы увидите вывод, аналогичный следующему:

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

Однако если некоторые узлы имеют NotReady в качестве STATUS , это может означать, что рабочие узлы еще не завершили настройку. Подождите примерно пять-десять минут, прежде чем повторно запустить kubectl get nodes и проверить новый вывод. Если несколько узлов по-прежнему имеют статус NotReady , возможно, вам придется проверить и повторно выполнить команды, выполненные на предыдущих шагах.

Теперь, когда ваш кластер успешно проверен, давайте запланируем в кластере пример приложения Nginx.

Шаг 7 — Запуск приложения в кластере

Теперь вы можете развернуть любое контейнерное приложение в своем кластере. Чтобы все было знакомо, давайте развернем Nginx с помощью Deployments and Services, чтобы изучить, как это приложение можно развернуть в кластере. Вы также можете использовать приведенные ниже команды для других контейнерных приложений при условии, что вы измените имя образа Docker и все соответствующие флаги (например ports и volumes ).

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

Развертывание — это тип объекта Kubernetes, который гарантирует, что всегда будет работать определенное количество модулей на основе определенного шаблона, даже если модуль выйдет из строя во время существования кластера. В приведенном выше развертывании будет создан модуль с одним контейнером из образа Nginx Docker из реестра Docker.

Затем выполните следующую команду, чтобы создать службу с именем nginx , которая будет предоставлять доступ к приложению публично. Это будет сделано через NodePort — схему, которая сделает модуль доступным через произвольный порт, открытый на каждом узле кластера:

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

Выполните следующую команду:

Эта команда выведет текст, подобный следующему:

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

Чтобы проверить, что все работает, посетите http:// worker_1_ip : nginx_port или http:// worker_2_ip : nginx_port через браузер на локальном компьютере. Вы увидите знакомую страницу приветствия Nginx.

Если вы хотите удалить приложение Nginx, сначала удалите службу nginx из узла плоскости управления:

Выполните следующее, чтобы убедиться, что служба удалена:

Вы увидите следующий результат:

Затем удалите развертывание:

Запустите следующее, чтобы убедиться, что это сработало:

Заключение

В этом руководстве вы успешно настроили кластер Kubernetes в Ubuntu 20.04, используя Kubeadm и Ansible для автоматизации.

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

  • Докеризация приложений — список примеров, в которых подробно описывается, как контейнеризировать приложения с помощью Docker.

  • Обзор Pod — подробно описывает, как работают Pod и их связь с другими объектами Kubernetes. Поды широко распространены в Kubernetes, поэтому их понимание облегчит вашу работу.

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

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

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

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