Поиск по сайту:

Как создать кластер Kubernetes с помощью Kubeadm в Ubuntu 18.04

Автор выбрал программу Write for DOnations.

Введение

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

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

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

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

Примечание. С 15 декабря 2022 г. DigitalOcean больше не поддерживает создание новых капель RancherOS через панель управления или API. Однако любые существующие капли RancherOS, созданные до 15 декабря 2022 года, будут работать, несмотря на изменение предложений. Кроме того, вы по-прежнему можете запускать дроплеты RancherOS, используя собственный образ. Узнайте, как импортировать собственное изображение в DigitalOcean, следуя нашей документации по продукту.

Цели

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

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

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

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

Предпосылки

  • Пара ключей SSH на вашем локальном компьютере Linux/macOS/BSD. Если вы раньше не использовали ключи SSH, вы можете узнать, как их настроить, следуя этому объяснению, как настроить ключи SSH на локальном компьютере.
  • Три сервера под управлением Ubuntu 18.04 с не менее 2 ГБ ОЗУ и 2 виртуальными ЦП каждый. Вы должны иметь возможность подключаться по SSH к каждому серверу в качестве пользователя root с вашей парой ключей SSH.
  • Ansible установлен на вашем локальном компьютере. Если вы используете Ubuntu 18.04 в качестве ОС, следуйте инструкциям раздела «Шаг 1 — Установка Ansible» в официальной документации по установке Ansible.
  • Знакомство с плейбуками Ansible. Для ознакомления ознакомьтесь с Управлением конфигурацией 101: Написание Ansible Playbooks.
  • Знание того, как запустить контейнер из образа Docker. Посмотрите «Шаг 5 — Запуск контейнера Docker» в разделе «Установка и использование Docker в Ubuntu 18.04», если вам нужно освежить знания.

Шаг 1 — Настройка каталога рабочей области и файла Ansible Inventory

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

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

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

  1. mkdir ~/kube-cluster

  2. cd ~/kube-cluster

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

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

  1. nano ~/kube-cluster/hosts

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

[masters]
master ansible_host=master_ip ansible_user=root

[workers]
worker1 ansible_host=worker_1_ip ansible_user=root
worker2 ansible_host=worker_2_ip ansible_user=root

[all:vars]
ansible_python_interpreter=/usr/bin/python3

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

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

Точно так же в группе рабочих есть две записи для рабочих серверов (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 в рабочей области:

  1. nano ~/kube-cluster/initial.yml

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

- 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

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

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

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

Затем запустите playbook, запустив локально:

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

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

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] => (item=ssh-rsa AAAAB3...)
changed: [worker2] => (item=ssh-rsa AAAAB3...)
changed: [master] => (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 — среда выполнения контейнера. Это компонент, который запускает ваши контейнеры. Поддержка других сред выполнения, таких как rkt, активно разрабатывается в Kubernetes.
  • kubeadm — инструмент командной строки, который установит и настроит различные компоненты кластера стандартным способом.
  • kubelet — системная служба/программа, которая работает на всех узлах и обрабатывает операции на уровне узла.
  • kubectl — инструмент командной строки, используемый для выдачи команд кластеру через его сервер API.

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

  1. nano ~/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

Первая игра в playbook делает следующее:

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

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

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

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

Затем запустите playbook, запустив локально:

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

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

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 — Настройка мастер-узла

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

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

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

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

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

  1. nano ~/kube-cluster/master.yml

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

- hosts: master
  become: yes
  tasks:
    - name: initialize the cluster
      shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> 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 >> 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 создавать объекты, описанные в дескрипторе.[yml|json] файл. Файл kube-flannel.yml содержит описания объектов, необходимых для настройки Flannel в кластере.

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

Запустите playbook локально, запустив:

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

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

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 с помощью следующей команды:

  1. ssh ubuntu@master_ip

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

  1. kubectl get nodes

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

Output
NAME      STATUS    ROLES     AGE       VERSION
master    Ready     master    1d        v1.14.0

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

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

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

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

  1. nano ~/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 }} >> node_joined.txt"
      args:
        chdir: $HOME
        creates: node_joined.txt

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

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

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

Запустите playbook, запустив локально:

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

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

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 с помощью следующей команды:

  1. ssh ubuntu@master_ip

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

  1. kubectl get nodes

Вы увидите вывод, подобный следующему:

Output
NAME      STATUS    ROLES     AGE       VERSION
master    Ready     master    1d        v1.14.0
worker1   Ready     <none>    1d        v1.14.0
worker2   Ready     <none>    1d        v1.14.0

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

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

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

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

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

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

  1. kubectl create deployment nginx --image=nginx

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

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

  1. kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort

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

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

  1. kubectl get services

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

Output
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP           PORT(S)             AGE
kubernetes   ClusterIP   10.96.0.1        <none>                443/TCP             1d
nginx        NodePort    10.109.228.209   <none>                80:nginx_port/TCP   40m

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

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

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

  1. kubectl delete service nginx

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

  1. kubectl get services

Вы увидите следующий вывод:

Output
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP           PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>                443/TCP        1d

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

  1. kubectl delete deployment nginx

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

  1. kubectl get deployments



Output
No resources found.

Заключение

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

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

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

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

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