Автор выбрал фонд 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 подразумевается сервер), отвечающиой за управление состоянием кластера. На нем работает система 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 в Ubuntu 18.04» для установки Ansible. Инструкции по установке на других платформах, включая macOS и CentOS, можно найти в официальной документации по установке Ansible.
Знакомство с плейбуками Ansible. Прочитайте руководство «Все об управлении конфигурацией: создание плейбуков Ansible».
Умение запускать контейнеры из образа Docker. Ознакомьтесь с разделом «Шаг 5 — запуск контейнера Docker» обучающего модуля «Установка и использование Docker в Ubuntu 18.04», если вам требуется освежить знания.
В этом разделе вы создадите на локальном компьютере каталог, который будет выступать в качестве рабочего пространства. Вы выполните локальную настройку Ansible, чтобы обеспечить возможность связи с вашими удаленными серверами и выполнения команд на этих серверах. После этого вы создадите файл hosts
с данными инвентаризации, в том числе с IP-адресами ваших серверов и данными групп, к которым принадлежит каждый сервер.
Из трех ваших серверов один сервер будет главным сервером, и его IP-адрес будет отображаться как master_ip
. Другие два сервера будут рабочими узлами и будут иметь IP-адреса worker_1_ip
и worker_2_ip
.
Создайте каталог ~/kube-cluster
в домашнем каталоге локального компьютера и перейдите в него с помощью команды cd
:
- mkdir ~/kube-cluster
- cd ~/kube-cluster
В рамках этого обучающего модуля данный каталог будет выступать в качестве рабочего пространства, и в нем будут храниться все ваши плейбуки Ansible. Также в этом каталоге вы будете запускать все локальные команды.
Создайте файл с именем ~/kube-cluster/hosts
с помощью nano
или своего любимого текстового редактора:
- 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 (masters и workers) для определения логической структуры вашего кластера.
В группе masters имеется запись сервера master, в которой указан IP-адрес главного узла (master_ip
) и указывается, что система Ansible должна запускать удаленные команды от имени пользователя root.
В группе workers также есть две записи для серверов рабочих узлов (worker_1_ip
и worker_2_ip
), где пользователь ansible_user
также задается как пользователь root.
В последней строке файла Ansible предписывается использовать для операций управления интерпретаторы Python 3 удаленных серверов.
Сохраните и закройте файл после добавления текста.
После настойки инвентаризации сервера с помощью групп мы переходим к установке зависимостей уровня операционной системы и создания параметров конфигурации.
В этом разделе вы создадите пользователя без привилегий root с привилегиями sudo на всех серверах, чтобы вы могли вручную подключаться к ним через SSH как пользователь без привилегий. Это полезно на случай, если вы захотите посмотреть информацию о системе с помощью таких команд как top/htop
, просмотреть список работающих контейнеров или изменить файлы конфигурации, принадлежащие пользователю root. Данные операции обычно выполняются во время технического обслуживания кластера, и использование пользователя без привилегий root для выполнения таких задач минимизирует риск изменения или удаления важных файлов или случайного выполнения других опасных операций.
Создайте в рабочем пространстве файл с именем ~/kube-cluster/initial.yml
:
- nano ~/kube-cluster/initial.yml
Добавьте в файл следующую строку сценария play для создания пользователя без привилегий root с привилегиями sudo на всех серверах. Сценарий в Ansible — это набор выполняемых шагов, нацеленных на определенные серверы и группы. Следующий сценарий создаст пользователя без привилегий root с привилегиями sudo:
- 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
.
Сохраните и закройте файл после добавления текста.
Затем запустите плейбук на локальном компьютере:
- ansible-playbook -i hosts ~/kube-cluster/initial.yml
Выполнение команды займет от двух до пяти минут. После завершения вы увидите примерно следующий результат:
OutputPLAY [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.
В этом разделе вы научитесь устанавливать требующиеся Kubernetes пакеты уровня операционной системы с помощью диспетчера пакетов Ubuntu. Вот эти пакеты:
Docker — среда исполнения контейнеров. Это компонент, который запускает ваши контейнеры. В настоящее время для Kubernetes активно разрабатывается поддержка других сред исполнения, в том числе rkt.
kubeadm
— инструмент командной строки, который устанавливает и настраивает различные компоненты кластера стандартным образом.
kubelet
— системная служба / программа, которая работает на всех узлах и обрабатывает операции на уровне узлов.
kubectl
— инструмент командной строки, используемый для отправки команд на кластер через сервер API.
Создайте в рабочем пространстве файл с именем ~/kube-cluster/kube-dependencies.yml
:
- 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
Первый сценарий в плейбуке выполняет следующие операции:
Устанавливает среду исполнения контейнеров Docker.
Устанавливает apt-transport-https
, позволяя добавлять внешние источники HTTPS в список источников APT.
Добавляет ключ apt-key репозитория Kubernetes APT для проверки ключей.
Добавляет репозиторий Kubernetes APT в список источников APT ваших удаленных серверов.
Устанавливает kubelet
и kubeadm
.
Второй сценарий состоит из одной задачи, которая устанавливает kubectl
на главном узле.
Примечание. Хотя документация по Kubernetes рекомендует использовать для вашей среды последнюю стабильную версию Kubernetes, в данном обучающем модуле используется конкретная версия. Это обеспечит успешное следование процедуре, поскольку Kubernetes быстро изменяется и последняя версия может не соответствовать этому обучающему модулю.
Сохраните файл и закройте его после завершения.
Затем запустите плейбук на локальном компьютере:
- ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml
После завершения вы увидите примерно следующий результат:
OutputPLAY [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
можно запускать с любых рабочих узлов и на любом компьютере, где их можно установить и настроить для указания на кластер.
Теперь все системные зависимости установлены. Далее мы настроим главный узел и проведем инициализацию кластера.
На этом шаге вы настроите главный узел. Прежде чем создавать любые плейбуки, следует нружно познакомиться с концепциями _подов и плагинов___ сети подов, которые будут использоваться в вашем кластере.
Под — это атомарная единица, запускающая один или несколько контейнеров. Эти контейнеры используют общие ресурсы, такие как файловые тома и сетевые интерфейсы. Под — это базовая единица планирования в Kubernetes: все контейнеры в поде гарантированно запускаются на том же узле, который назначен для этого пода.
Каждый под имеет собственный IP-адрес, и под на одном узле должен иметь доступ к поду на другом узле через IP-адрес пода. Контейнеры в одном узле могут легко взаимодействовать друг с другом через локальный интерфейс. Однако связь между подами более сложная, и для нее требуется отдельный сетевой компонент, обеспечивающий прозрачную маршрутизацию трафика между подами на разных узлах.
Эту функцию обеспечивают плагины сети подов. Для этого кластера мы используем стабильный и производительный плагин Flannel.
Создайте на локальном компьютере плейбук Ansible с именем master.yml
:
- 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
создать объекты, описанные в файле descriptor.[yml|json]
. Файл kube-flannel.yml
содержит описания объектов, требуемых для настроки Flannel
в кластере.
Сохраните файл и закройте его после завершения.
Запустите плейбук на локальной системе с помощью команды:
- 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 с помощью следующей команды:
- ssh ubuntu@master_ip
Запустите на главном узле следующую команду:
- kubectl get nodes
Результат будет выглядеть следующим образом:
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
В результатах показано, что главный узел master
завершил выполнение всех задач инициализации и находится в состоянии готовности Ready
, из которого он может принимать подключения от рабочих узлов и выполнять задачи, отправленные на сервер API. Теперь вы можете добавить рабочие узлы с локального компьютера.
Для добавления рабочих узлов в кластер нужно запустить на каждом из них отдельную команду. Эта команда предоставляет всю необходимую информацию о кластере, включая IP-адрес, порт сервера API главного узла и защищенный токен. К кластеру могут подключаться только те узлы, которые проходят проверку с защищенным токеном.
Вернитесь в рабочее пространство и создайте плейбук с именем workers.yml
:
- 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
Вот что делает этот плейбук:
Первый сценарий получает команду join, которую нужно запустить на рабочих узлах. Эта команда имеет следующий форматt: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
. После получения фактической команды с правильными значениями token и hash задача задает их как фактические, чтобы следующий сценарий имел доступ к этой информации.
Второй сценарий содержит одну задачу, которая запускает команду join на всех рабочих узлах. После завершения этой задачи два рабочих узла становятся частью кластера.
Сохраните файл и закройте его после завершения.
Запустите плейбук на локальном компьютере:
- ansible-playbook -i hosts ~/kube-cluster/workers.yml
После завершения вы увидите примерно следующий результат:
OutputPLAY [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
Теперь рабочие узлы добавлены, ваш кластер полностью настроен и готов к работе, а рабочие узлы готовы к выполнению рабочих задач. Перед назначением приложений следует убедиться, что кластер работает надлежащим образом.
Иногда при установке и настройке кластера может произойти ошибка, если один из узлов отключен или имеются проблемы сетевого соединения между главным узлом и рабочими узлами. Сейчас мы проверим кластер и убедимся, что все узлы работают правильно.
Вам нужно будет проверить текущее состояние кластера с главного узла, чтобы убедиться в готовности всех узлов. Если вы отключились от главного узла, вы можете снова подключиться к нему через SSH с помощью следующей команды:
- ssh ubuntu@master_ip
Затем выполните следующую команду, чтобы получить данные о статусе кластера:
- kubectl get nodes
Вы увидите примерно следующий результат:
OutputNAME 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.
Теперь вы можете развернуть на кластере любое приложение в контейнере. Для удобства мы развернем Nginx с помощью Deployments и Services и посмотрим, как можно развернуть это приложение на кластере. Вы можете использовать приведенные ниже команды для других приложений в контейнерах, если вы измените имя образа Docker и дополнительные параметры (такие как ports
и volumes
).
Запустите на главном узле следующую команду для создания развертывания с именем nginx
:
- kubectl create deployment nginx --image=nginx
Развертывание — это тип объекта Kubernetes, обеспечивающий постоянную работу определенного количества подов на основе заданного шаблона, даже в случае неисправности пода в течение срока службы кластера. Вышеуказанное развертывание создаст под с одним контейнером из образа Nginx Docker в реестре Docker.
Запустите следующую команду, чтобы создать службу nginx
, которая сделает приложение общедоступным. Для этого используется схема NodePort, которая делает под доступным на произвольном порту, который открывается на каждом узле кластера:
- kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort
Службы — это еще один тип объектов Kubernetes, который открывает внутренние службы кластера для внутренних и внешних клиентов. Они поддерживают запросы балансировки нагрузки на разные поды и являются неотъемлемым компонентом Kubernetes, который часто взаимодействует с другими компонентами.
Запустите следующую команду:
- kubectl get services
Будет выведен текст следующего вида:
OutputNAME 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
с главного узла:
- kubectl delete service nginx
Запустите следующую команду, чтобы проверить удаление службы:
- kubectl get services
Результат будет выглядеть следующим образом:
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d
Затем удалите развертывание:
- kubectl delete deployment nginx
Запустите следующую команду для проверки успешности выполнения:
- kubectl get deployments
OutputNo resources found.
В этом обучающем модуле вы научились успешно настраивать кластер Kubernetes в Ubuntu 18.04, используя для автоматизации Kubeadm и Ansible.
Если вы не знаете, что дальше делать с настроенным кластером, попробуйте развернуть на нем собственные приложения и службы. Далее приведен список ссылок с дополнительной информацией, которая будет вам полезна:
Докеризация приложений — детальные примеры контейнеризации приложений с помощью Docker.
Обзор подов — детальное описание принципов работы подов и их отношений с другими объектами Kubernetes. Поды используются в Kubernetes повсеместно, так что понимание этой концепции упростит вашу работу.
Обзор развертывания — обзор концепции развертывания. С его помощью проще понять принципы работы таких контроллеров как развертывания, поскольку они часто используются для масштабирования в приложениях без сохранения состояния и для автоматического восстановления поврежденных приложений.
Обзор служб — рассказывает о службах, еще одном часто используемом объекте кластеров Kubernetes. Понимание типов служб и доступных для них опций важно для использования приложений с сохранением состояния и без сохранения состояния.
Другие важные концепции, полезные при развертывании рабочих приложений: тома, входы и секреты.
В Kubernetes имеется множество функций и возможностей. Официальная документация Kubernetes — лучший источник информации о концепциях, руководств по конкретным задачам и ссылок API для различных объектов.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Are crazy to connect with root user on remote servers ? Anyway it doesn work with connect with ansible_user or ansible_ssh_user Thanks for wasted time