Table of Contents

*Автор выбрал фонд Free and Open Source Fund для получения пожертвования в рамках программы Write for DOnations.*

Введение

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

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

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

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

Цели

kubernetes illustration for: Цели

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

  • Один главный узел

Главный узел (под _узлом_ в Kubernetes подразумевается сервер), отвечающий за управление состоянием кластера. На нем работает система Etcd, которая хранит данные кластера среди компонентов, распределяющих рабочие задачи по рабочим узлам.

  • Два рабочих узла

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

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

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

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

  • Три сервера с Ubuntu 16.04, имеющие не менее 2 ГБ оперативной памяти и 2 виртуальных процессоров каждый. Вы должны иметь возможность подключаться к каждому серверу через SSH как пользователь root, используя вашу пару ключей SSH.
  • Умение запускать контейнеры из образа Docker. Ознакомьтесь с разделом «Шаг 5 — Запуск контейнера Docker» обучающего руководства Установка и использование Docker в Ubuntu 16.04, если вам требуется освежить знания.

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

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

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

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

				
					
[environment local]

mkdir ~/kube-cluster

cd ~/kube-cluster

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

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

				
					
[environment local]

nano ~/kube-cluster/hosts

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

				
					
[environment local]

[label ~/kube-cluster/hosts]

[masters]

master ansible_host=&lt;^&gt;master_ip&lt;^&gt; ansible_user=root



[workers]

worker1 ansible_host=&lt;^&gt;worker_1_ip&lt;^&gt; ansible_user=root

worker2 ansible_host=&lt;^&gt;worker_2_ip&lt;^&gt; ansible_user=root



[all:vars]

ansible_python_interpreter=/usr/bin/python3

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

В группе masters имеется запись сервера master, в которой указан IP-адрес главного узла (<^>master_ip<^>) и указывается, что система Ansible должна запускать удаленные команды от имени пользователя root.

В группе workers также есть две записи для серверов рабочих узлов (<^>worker_1_ip<^> и <^>worker_2_ip<^>), где пользователь ansible_user также задается как пользователь root.

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

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

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

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

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

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

				
					
[environment local]

nano ~/kube-cluster/initial.yml

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

				
					
[environment local]

[label ~/kube-cluster/initial.yml]

- hosts: all

 become: yes

 tasks:

 - name: create the 'ubuntu' user

 user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash



 - name: allow 'ubuntu' to have passwordless sudo

 lineinfile:

 dest: /etc/sudoers

 line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'

 validate: 'visudo -cf %s'



 - name: set up authorized keys for the ubuntu user

 authorized_key: user=ubuntu key="{{item}}"

 with_file:

 - ~/.ssh/id_rsa.pub

Далее приведено детальное описание операций, выполняемых этим плейбуком:

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

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

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

				
					
[environment local]

ansible-playbook -i hosts ~/kube-cluster/initial.yml

Выполнение команды займет от двух до пяти минут. После завершения вы увидите примерно следующий результат:

				
					
[environment local]

[secondary_label Output]

PLAY [all] ****



TASK [Gathering Facts] ****

ok: [master]

ok: [worker1]

ok: [worker2]



TASK [create the 'ubuntu' user] ****

changed: [master]

changed: [worker1]

changed: [worker2]



TASK [allow 'ubuntu' user to have passwordless sudo] ****

changed: [master]

changed: [worker1]

changed: [worker2]



TASK [set up authorized keys for the ubuntu user] ****

changed: [worker1] =&gt; (item=ssh-rsa AAAAB3...

changed: [worker2] =&gt; (item=ssh-rsa AAAAB3...

changed: [master] =&gt; (item=ssh-rsa AAAAB3...



PLAY RECAP ****

master : ok=5 changed=4 unreachable=0 failed=0 

worker1 : ok=5 changed=4 unreachable=0 failed=0 

worker2 : ok=5 changed=4 unreachable=0 failed=0

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

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

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

  • Docker — среда исполнения контейнеров. Это компонент, который запускает ваши контейнеры. В настоящее время для Kubernetes активно разрабатывается поддержка других сред исполнения, в том числе rkt.
  • kubeadm — инструмент командной строки, который устанавливает и настраивает различные компоненты кластера стандартным образом.
  • kubelet — системная служба/программа, которая работает на всех узлах и обрабатывает операции на уровне узлов.
  • kubectl — инструмент командной строки, используемый для отправки команд на кластер через сервер API.

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

				
					
[environment local]

nano ~/kube-cluster/kube-dependencies.yml

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

				
					
[environment local]

[label ~/kube-cluster/kube-dependencies.yml]

- hosts: all

 become: yes

 tasks:

 - name: install Docker

 apt:

 name: docker.io

 state: present

 update_cache: true



 - name: install APT Transport HTTPS

 apt:

 name: apt-transport-https

 state: present



 - name: add Kubernetes apt-key

 apt_key:

 url: https://packages.cloud.google.com/apt/doc/apt-key.gpg

 state: present



 - name: add Kubernetes' APT repository

 apt_repository:

 repo: deb http://apt.kubernetes.io/ kubernetes-xenial main

 state: present

 filename: 'kubernetes'



 - name: install kubelet

 apt:

 name: kubelet=1.14.0-00

 state: present

 update_cache: true



 - name: install kubeadm

 apt:

 name: kubeadm=1.14.0-00

 state: present



- hosts: master

 become: yes

 tasks:

 - name: install kubectl

 apt:

 name: kubectl=1.14.0-00

 state: present

 force: yes

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

  • Устанавливает среду исполнения контейнеров Docker.
  • Устанавливает apt-transport-https, позволяя добавлять внешние источники HTTPS в список источников APT.
  • Добавляет ключ apt-key репозитория Kubernetes APT для проверки ключей.
  • Добавляет репозиторий Kubernetes APT в список источников APT ваших удаленных серверов.
  • Устанавливает kubelet и kubeadm.

Второй сценарий состоит из одной задачи, которая устанавливает kubectl на главном узле.

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

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

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

				
					
[environment local]

ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

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

				
					
[environment local]

[secondary_label Output]

PLAY [all] ****



TASK [Gathering Facts] ****

ok: [worker1]

ok: [worker2]

ok: [master]



TASK [install Docker] ****

changed: [master]

changed: [worker1]

changed: [worker2]



TASK [install APT Transport HTTPS] *****

ok: [master]

ok: [worker1]

changed: [worker2]



TASK [add Kubernetes apt-key] *****

changed: [master]

changed: [worker1]

changed: [worker2]



TASK [add Kubernetes' APT repository] *****

changed: [master]

changed: [worker1]

changed: [worker2]



TASK [install kubelet] *****

changed: [master]

changed: [worker1]

changed: [worker2]



TASK [install kubeadm] *****

changed: [master]

changed: [worker1]

changed: [worker2]



PLAY [master] *****



TASK [Gathering Facts] *****

ok: [master]



TASK [install kubectl] ******

ok: [master]



PLAY RECAP ****

master : ok=9 changed=5 unreachable=0 failed=0 

worker1 : ok=7 changed=5 unreachable=0 failed=0 

worker2 : ok=7 changed=5 unreachable=0 failed=0

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

Теперь все системные зависимости установлены. Далее мы настроим главный узел и проведем инициализацию кластера.

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

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

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

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

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

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

				
					
[environment local]

nano ~/kube-cluster/master.yml

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

				
					
[environment local]

[label ~/kube-cluster/master.yml]

- hosts: master

 become: yes

 tasks:

 - name: initialize the cluster

 shell: kubeadm init --pod-network-cidr=10.244.0.0/16 &gt;&gt; cluster_initialized.txt

 args:

 chdir: $HOME

 creates: cluster_initialized.txt



 - name: create .kube directory

 become: yes

 become_user: ubuntu

 file:

 path: $HOME/.kube

 state: directory

 mode: 0755



 - name: copy admin.conf to user's kube config

 copy:

 src: /etc/kubernetes/admin.conf

 dest: /home/ubuntu/.kube/config

 remote_src: yes

 owner: ubuntu



 - name: install Pod network

 become: yes

 become_user: ubuntu

 shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml &gt;&gt; pod_network_setup.txt

 args:

 chdir: $HOME

 creates: pod_network_setup.txt

Далее приведена детализация этого сценария:

  • Первая задача инициализирует кластер посредством запуска 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 в кластере.

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

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

				
					
[environment local]

ansible-playbook -i hosts ~/kube-cluster/master.yml

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

				
					
[environment local]

[secondary_label Output]



PLAY [master] ****



TASK [Gathering Facts] ****

ok: [master]



TASK [initialize the cluster] ****

changed: [master]



TASK [create .kube directory] ****

changed: [master]



TASK [copy admin.conf to user's kube config] *****

changed: [master]



TASK [install Pod network] *****

changed: [master]



PLAY RECAP ****

master : ok=5 changed=4 unreachable=0 failed=0

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

				
					
[environment local]

ssh ubuntu@&lt;^&gt;master_ip&lt;^&gt;

Запустите на главном узле следующую команду:

				
					
kubectl get nodes

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

NAME STATUS ROLES AGE VERSION

master Ready master 1d v1.14.0

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

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

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

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

				
					
[environment local]

nano ~/kube-cluster/workers.yml

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

				
					
[environment local]

[label ~/kube-cluster/workers.yml]

- hosts: master

 become: yes

 gather_facts: false

 tasks:

 - name: get join command

 shell: kubeadm token create --print-join-command

 register: join_command_raw



 - name: set join command

 set_fact:

 join_command: "{{ join_command_raw.stdout_lines[0] }}"





- hosts: workers

 become: yes

 tasks:

 - name: join cluster

 shell: "{{ hostvars['master'].join_command }} &gt;&gt; node_joined.txt"

 args:

 chdir: $HOME

 creates: node_joined.txt

Вот что делает этот плейбук:

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

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

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

				
					
[environment local]

ansible-playbook -i hosts ~/kube-cluster/workers.yml

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

				
					
[environment local]

[secondary_label Output]

PLAY [master] ****



TASK [get join command] ****

changed: [master]



TASK [set join command] *****

ok: [master]



PLAY [workers] *****



TASK [Gathering Facts] *****

ok: [worker1]

ok: [worker2]



TASK [join cluster] *****

changed: [worker1]

changed: [worker2]



PLAY RECAP *****

master : ok=2 changed=1 unreachable=0 failed=0 

worker1 : ok=2 changed=1 unreachable=0 failed=0 

worker2 : ok=2 changed=1 unreachable=0 failed=0

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

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

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

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

				
					
[environment local]

ssh ubuntu@&lt;^&gt;master_ip&lt;^&gt;

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

				
					
kubectl get nodes

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

				
					
[secondary_label Output]

NAME STATUS ROLES AGE VERSION

master Ready master 1d v1.14.0

worker1 Ready &lt;none&gt; 1d v1.14.0

worker2 Ready &lt;none&gt; 1d v1.14.0

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

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

Теперь кластер успешно проверен, и мы запланируем запуск на кластере образца приложения Nginx.

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

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

Запустите на главном узле следующую команду для создания развертывания с именем nginx:

				
					
kubectl create deployment &lt;^&gt;nginx&lt;^&gt; --image=&lt;^&gt;nginx&lt;^&gt;

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

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

				
					
kubectl expose deploy &lt;^&gt;nginx&lt;^&gt; --port &lt;^&gt;80&lt;^&gt; --target-port &lt;^&gt;80&lt;^&gt; --type NodePort

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

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

				
					
kubectl get services

Будет выведен текст следующего вида:

				
					
[secondary_label Output]

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 &lt;none&gt; 443/TCP 1d

&lt;^&gt;nginx&lt;^&gt; NodePort 10.109.228.209 &lt;none&gt; 80:&lt;^&gt;nginx_port&lt;^&gt;/TCP 40m

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

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

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

				
					
kubectl delete service &lt;^&gt;nginx&lt;^&gt;

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

				
					
kubectl get services

Результат будет выглядеть следующим образом:

				
					
[secondary_label Output]

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 &lt;none&gt; 443/TCP 1d

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

				
					
kubectl delete deployment &lt;^&gt;nginx&lt;^&gt;

Запустите следующую команду для проверки успешности выполнения:

				
					
kubectl get deployments

				
			
				
					
[secondary_label Output]

No resources found.

Заключение

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

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

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

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

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