Это многостраничный печатный вид этого раздела. Нажмите что бы печатать.
Этот раздел документации по Kubernetes содержит страницы, на которых показано, как выполнять отдельные задачи. На странице задачи показано, как выполнить что-то одно, обычно с краткой последовательностью шагов.
Если вы хотите написать страницу задачи, обратитесь к разделу Создание запроса на получение документации.
Инструмент командной строки Kubernetes kubectl позволяет запускать команды для кластеров Kubernetes. Вы можете использовать kubectl для развертывания приложений, проверки и управления ресурсов кластера, а также для просмотра логов. Полный список возможных операций для kubectl смотрите в Обзоре kubectl.
Используемая вами мажорная версия kubectl не должна отличаться от той, которая используется в кластере. Например, версия v1.2 может работать с версиями v1.1, v1.2 и v1.3. Использование последней версии kubectl поможет избежать непредвиденных проблем.
Загрузите последнюю версию с помощью команды:
curl -LO https://dl.k8s.io/release/`curl -LS https://dl.k8s.io/release/stable.txt`/bin/linux/amd64/kubectl
Чтобы загрузить определенную версию, вставьте в фрагмент команды $(curl -LS https://dl.k8s.io/release/stable.txt) нужную версию.
Например, команда загрузки версии 1.35.0 для Linux будет выглядеть следующим образом:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl
Сделайте бинарный файл kubectl исполняемым:
chmod +x ./kubectl
Переместите бинарный файл в директорию из переменной окружения PATH:
sudo mv ./kubectl /usr/local/bin/kubectl
Убедитесь, что установлена последняя версия:
kubectl version --client
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.33/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.33/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.33/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.33/rpm/repodata/repomd.xml.key
EOF
sudo yum install -y kubectl
Если вы используете Ubuntu или другой Linux-дистрибутив, в котором есть пакетный менеджер snap, kubectl доступен в виде приложения snap.
snap install kubectl --classic
kubectl version
Если вы работаете в Linux и используете пакетный менеджер Homebrew, то kubectl можно установить через него.
brew install kubectl
kubectl version
Загрузите последнюю версию:
curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
Чтобы загрузить определенную версию, вставьте в фрагмент команды $(curl -LS https://dl.k8s.io/release/stable.txt) нужную версию.
Например, команда загрузки версии 1.35.0 для macOS будет выглядеть следующим образом:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/darwin/amd64/kubectl
Сделайте бинарный файл kubectl исполняемым:
chmod +x ./kubectl
Переместите бинарный файл в директорию из переменной окружения PATH:
sudo mv ./kubectl /usr/local/bin/kubectl
Убедитесь, что установлена последняя версия:
kubectl version --client
Если вы используете macOS и Homebrew, то kubectl можно установить с помощью пакетного менеджера Homebrew.
Выполните команду установки:
brew install kubectl
Или:
brew install kubernetes-cli
Убедитесь, что установлена последняя версия:
kubectl version --client
Если вы используйте macOS и Macports, то kubectl можно установить с помощью пакетного менеджера Macports.
Выполните команду установки:
sudo port selfupdate
sudo port install kubectl
Убедитесь, что установлена последняя версия:
kubectl version --client
Загрузите последнюю версию 1.35.0 по этой ссылке.
Либо, если у вас установлен curl, выполните команду ниже:
curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe
Последнюю стабильную версию (например, при написании скриптов) вы можете узнать из файла по ссылке https://dl.k8s.io/release/stable.txt.
Переместите бинарный файл в директорию из переменной окружения PATH:
Убедитесь, что версия kubectl соответствует загружённой:
kubectl version --client
kubectl в переменную окружения PATH.
Если у вас установлен Docker Desktop, вам придётся поместить путь к установленному бинарному файлу перед записью, добавленной установщиком Docker Desktop, либо же удалить вовсе kubectl, поставляемый вместе с Docker Desktop.Если вы работаете в Windows и используете менеджер пакетов Powershell Gallery, вы можете установить и обновить kubectl с помощью Powershell.
Выполните команды по установке (обязательно укажите DownloadLocation):
Install-Script -Name install-kubectl -Scope CurrentUser -Force
install-kubectl.ps1 [-DownloadLocation <path>]
DownloadLocation, то kubectl будет установлен во временную директорию пользователя.Установщик создаст $HOME/.kube вместе с конфигурационным файлом.
Убедитесь, что установлена последняя версия:
kubectl version --client
Для установки kubectl в Windows вы можете использовать либо менеджер пакетов Chocolatey, либо установщик в командной строке Scoop.
choco install kubernetes-cli
scoop install kubectl
Убедитесь, что установлена последняя версия:
kubectl version --client
Перейдите в домашнюю директорию:
cd %USERPROFILE%
Создайте директорию .kube:
mkdir .kube
Перейдите в созданную только что директорию .kube:
cd .kube
Настройте kubectl, чтобы было возможно использовать удаленный кластер Kubernetes:
New-Item config -type file
Вы можете использовать kubectl из SDK Google Cloud, который использует этот CLI-инструмент.
Установите Google Cloud SDK.
Выполните команду для установки kubectl:
gcloud components install kubectl
Убедитесь, что установлена последняя версия:
kubectl version --client
Чтобы kubectl мог найти и получить доступ к кластеру Kubernetes, нужен файл kubeconfig, который создаётся автоматически при создании кластера с помощью скрипта kube-up.sh или при успешном развертывании кластера Minikube. По умолчанию конфигурация kubectl находится в ~/.kube/config.
Посмотрите на состояние кластера, чтобы убедиться, что kubectl правильно сконфигурирован:
kubectl cluster-info
Если вы видите URL в ответ, значит kubectl корректно настроен для работы с вашим кластером.
Если вы видите сообщение следующего содержания, то значит kubectl настроен некорректно или не может подключиться к кластеру Kubernetes:
The connection to the server <server-name:port> was refused - did you specify the right host or port?
Например, если вы собираетесь запустить кластер Kubernetes на своем ноутбуке (локально), вам потребуется сначала установить специальный для этого инструмент, например Minikube, а затем снова выполнить указанные выше команды.
Если команда kubectl cluster-info возвращает URL в ответ, но вы не можете подключиться к своему кластеру, чтобы убедиться, что он правильно настроен, воспользуйтесь этой командой:
kubectl cluster-info dump
kubectl поддерживает автодополнение (автозаполнение) ввода в Bash и Zsh, которое сэкономит вам много времени на набор команд.
Ниже приведены инструкции по настройке автодополнения для Bash (для Linux и macOS) и Zsh.
Скрипт дополнения ввода kubectl для Bash может быть сгенерирован с помощью команды kubectl completion bash. Подключение скрипта дополнения ввода в вашу оболочку включает поддержку автозаполнения ввода для kubectl.
Однако скрипт дополнения ввода зависит от bash-completion, поэтому вам нужно сначала установить этот пакет (вы можете выполнить команду type _init_completion, чтобы проверить, установлен ли у вас уже bash-completion).
bash-completion можно установить через многие менеджеры пакеты (см. здесь). Вы можете установить его с помощью apt-get install bash-completion или yum install bash-completion и т.д.
Приведенные выше команды создадут файл /usr/share/bash-completion/bash_completion, который является основным скриптом bash-completion. Возможно, вам потребуется вручную подключить этот файл в ~/.bashrc (необходимость выполнять эту операцию зависит от используемого менеджера пакетов).
Чтобы убедиться, что всё работает, перезагрузите оболочку и выполните команду type _init_completion. Если команда отработала успешно, установка сделана правильно, в противном случае добавьте следующее содержимое в файл ~/.bashrc:
source /usr/share/bash-completion/bash_completion
Перезагрузите вашу оболочку и убедитесь, что bash-completion правильно установлен, выполнив команду type _init_completion.
Теперь нужно убедиться, что скрипт дополнения ввода kubectl выполняется во всех сессиях командной оболочки. Есть два способа сделать это:
Добавьте запуск скрипта дополнения ввода в файл ~/.bashrc:
echo 'source <(kubectl completion bash)' >>~/.bashrc
Добавьте скрипт дополнения ввода в директорию /etc/bash_completion.d:
kubectl completion bash >/etc/bash_completion.d/kubectl
Если у вас определён псевдоним для kubectl, вы можете интегрировать его с автодополнением оболочки:
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
/etc/bash_completion.d.Оба подхода эквивалентны. После перезагрузки вашей оболочки автодополнение ввода для kubectl должно работать.
Скрипт дополнения ввода kubectl для Bash может быть сгенерирован с помощью команды kubectl completion bash. Подключение скрипта дополнения ввода в вашей оболочке включает поддержку автозаполнения ввода для kubectl.
Однако скрипт дополнения ввода kubectl зависит от пакета bash-completion, который первым делом нужно установить.
Вы можете проверить, установлен ли у вас bash-completion v2, набрав команду type _init_completion. Если он не установлен, вы можете сделать это с помощью Homebrew:
brew install bash-completion@2
Как указано в выводе этой команды, добавьте следующий код в файл ~/.bashrc:
export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
Перезагрузите вашу командную оболочку и убедитесь, что bash-completion v2 корректно установлен, выполнив команду type _init_completion.
Теперь нужно убедиться, что скрипт дополнения ввода kubectl выполняется во всех сессиях командной оболочки. Есть два способа сделать это:
Добавьте запуск скрипта дополнения ввода в файл ~/.bashrc:
echo 'source <(kubectl completion bash)' >>~/.bashrc
Добавьте скрипт дополнения ввода в директорию /etc/bash_completion.d:
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
Если у вас определён псевдоним для kubectl, вы можете интегрировать его с автодополнением оболочки:
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc
Если вы установили kubectl с помощью Homebrew (как описано выше), то скрипт дополнения ввода kubectl уже должен быть находится в /usr/local/etc/bash_completion.d/kubectl. В этом случае вам не нужно ничего делать.
BASH_COMPLETION_COMPAT_DIR, что делает рабочими два метода.Какой бы вариант вы ни выбрали, после перезагрузки командной оболочки автодополнение ввода для kubectl должно заработать.
Скрипт дополнения ввода kubectl для Zsh может быть сгенерирован с помощью команды kubectl completion zsh. Подключение скрипта дополнения ввода в вашу оболочку включает поддержку автодополнения ввода для kubectl.
Чтобы подключить его во все сессии командной оболочки, добавьте следующую строчку в файл ~/.zshrc:
source <(kubectl completion zsh)
Если у вас определён псевдоним для kubectl, вы можете интегрировать его с автодополнением оболочки:
echo 'alias k=kubectl' >>~/.zshrc
echo 'compdef __start_kubectl k' >>~/.zshrc
После перезагрузки командной оболочки должны появляться дополнения ввода kubectl.
Если появляется ошибка complete:13: command not found: compdef, то добавьте следующее содержимое в начало вашего файла ~/.zshrc:
autoload -Uz compinit
compinit
На этой странице рассказано, как установить Minikube, инструмент для запуска одноузлового кластера Kubernetes на виртуальной машине в персональном компьютере.
Чтобы проверить, поддерживается ли виртуализация в Linux, выполните следующую команду и проверьте, что вывод не пустой:
grep -E --color 'vmx|svm' /proc/cpuinfo
Чтобы проверить, поддерживается ли виртуализация в macOS, выполните следующую команду в терминале:
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
Если вы видите VMX в выводе (должен быть окрашенным), значит в вашем компьютере поддерживается виртуализация VT-x.
Чтобы проверить, поддерживается ли виртуализация в Windows 8 и выше, выполните следующую команду в Windows Terminal или в командной строке.
systeminfo
Если вы видите следующий вывод, значит виртуализация поддерживается в Windows.
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
Virtualization Enabled In Firmware: Yes
Second Level Address Translation: Yes
Data Execution Prevention Available: Yes
Если вы видите следующий вывод, значит системе уже установлен гипервизор, значит вы можете пропустить следующий шаг установке гипервизора.
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
Убедитесь, что у вас установлен kubectl. Вы можете установить kubectl согласно инструкциям в разделе Установка и настройка kubectl.
Если у вас ещё не установлен гипервизор, установите один из них:
• KVM, который также использует QEMU
Minikube также поддерживает опцию --vm-driver=none, которая запускает компоненты Kubernetes на хосте, а не на виртуальной машине.
Для использования этого драйвера требуется только Docker и Linux, но не гипервизор.
Если вы используете драйвер none в Debian и его производных, используйте пакеты .deb для Docker, а не snap-пакет, который не работает с Minikube.
Вы можете скачать .deb-пакеты с сайта Docker.
none может привести к проблемам безопасности и потери данных. Перед использованием --vm-driver=none обратитесь к этой документации для получения дополнительной информации.Minikube также поддерживает vm-driver=podman, похожий на драйвер Docker. Podman, работающий с правами суперпользователя (пользователь root) — это лучший способ гарантировать вашим контейнерам полный доступ ко всем возможностям в системе.
podman должен запускать контейнеры от имени суперпользователя, поскольку у обычных аккаунтов нет полного доступа ко всем возможностям операционной системы, которые могут понадобиться контейнерам для работы.Доступны экспериментальные пакеты для Minikube; Вы можете загрузить пакеты для Linux (AMD64) со страницы релизов Minikube на GitHub.
Используйте пакетный менеджер в вашем дистрибутиве Linux для установки нужного пакета.
Вы также можете загрузить двоичный файл и использовать его вместо установки пакета:
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
&& chmod +x minikube
Чтобы исполняемый файл Minikube был доступен из любой директории выполните следующие команды:
sudo mkdir -p /usr/local/bin/
sudo install minikube /usr/local/bin/
В качестве ещё одной альтернативы вы можете установить Minikube с помощью Linux Homebrew:
brew install minikube
Убедитесь, что у вас установлен kubectl. Вы можете установить kubectl согласно инструкциям в разделе Установка и настройка kubectl.
Если у вас ещё не установлен гипервизор, установите один из них:
• HyperKit
Простейший способ установить Minikube в macOS — использовать Homebrew:
brew install minikube
Вы также можете установить его в macOS, загрузив двоичный файл:
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
&& chmod +x minikube
Чтобы исполняемый файл Minikube был доступен из любой директории выполните следующие команды:
sudo mv minikube /usr/local/bin
Убедитесь, что у вас установлен kubectl. Вы можете установить kubectl согласно инструкциям в разделе Установка и настройка kubectl.
Если у вас ещё не установлен гипервизор, установите один из них:
• Hyper-V
Простейший способ установить Minikube в Windows — использовать Chocolatey (запущенный с правами администратора):
choco install minikube
После установки Minikube нужно перезапустить терминал. Minikube должен быть автоматически добавлен в директорию с исполняемыми файлами.
Для ручной установки Minikube в Windows с помощью установщика Windows, загрузите и запустите установщик minikube-installer.exe.
Для ручной установки Minikube в Windows, загрузите minikube-windows-amd64, переименуйте его в minikube.exe и добавьте его в директорию исполняемых файлов.
Чтобы убедиться в том, что гипервизор и Minikube были установлены корректно, выполните следующую команду, которая запускает локальный кластер Kubernetes:
--vm-driver с командой minikube start укажите имя установленного вами гипервизора в нижнем регистре в заполнителе <driver_name> команды ниже. Полный список значений для опции --vm-driver перечислен в разделе по указанию драйвера виртуальной машины.minikube start --vm-driver=<driver_name>
После того, как команда minikube start отработала успешно, выполните команду для проверки состояния кластера:
minikube status
Если ваш кластер запущен, то в выводе команды minikube status должно быть что-то вроде этого:
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
Теперь, когда вы убедились, что Minikube работает с выбранным вами гипервизором, вы можете продолжить использовать Minikube или остановить кластер. Чтобы остановить кластер выполните команду ниже:
minikube stop
Если вы уже установили Minikube, то выполните следующую команду:
minikube start
В таком случае команда minikube start вернёт ошибку:
machine does not exist
Чтобы исправить это, нужно очистить локальное состояние:
minikube delete
При аутентификации с помощью клиентского сертификата сертификаты можно генерировать вручную с помощью easyrsa, openssl или cfssl.
easyrsa поддерживает ручную генерацию сертификатов для кластера.
Скачайте, распакуйте и инициализируйте пропатченную версию easyrsa3.
curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki
Создайте новый центр сертификации (certificate authority, CA). --batch задает автоматический режим;
--req-cn указывает общее имя (Common Name, CN) для нового корневого сертификата CA.
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
Сгенерируйте сертификат и ключ сервера.
Аргумент --subject-alt-name задает допустимые IP-адреса и DNS-имена, с которых будет осуществляться доступ к серверу API. MASTER_CLUSTER_IP обычно является первым IP из CIDR сервиса, который указан в качестве аргумента --service-cluster-ip-range как для сервера API, так и для менеджера контроллеров. Аргумент --days задает количество дней, через которое истекает срок действия сертификата. В приведенном ниже примере предполагается, что cluster.local используется в качестве доменного имени по умолчанию.
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
"IP:${MASTER_CLUSTER_IP},"\
"DNS:kubernetes,"\
"DNS:kubernetes.default,"\
"DNS:kubernetes.default.svc,"\
"DNS:kubernetes.default.svc.cluster,"\
"DNS:kubernetes.default.svc.cluster.local" \
--days=10000 \
build-server-full server nopass
Скопируйте pki/ca.crt, pki/issued/server.crt и pki/private/server.key в свою директорию.
Заполните и добавьте следующие параметры в параметры запуска сервера API:
--client-ca-file=/yourdirectory/ca.crt
--tls-cert-file=/yourdirectory/server.crt
--tls-private-key-file=/yourdirectory/server.key
openssl поддерживает ручную генерацию сертификатов для кластера.
Сгенерируйте 2048-разрядный ключ ca.key:
openssl genrsa -out ca.key 2048
На основе ca.key сгенерируйте ca.crt (используйте -days для установки времени действия сертификата):
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
Сгенерируйте 2048-битный ключ server.key:
openssl genrsa -out server.key 2048
Создайте файл конфигурации для генерации запроса на подписание сертификата (Certificate Signing Request, CSR).
Замените значения, помеченные угловыми скобками (например, <MASTER_IP>), нужными значениями перед сохранением в файл (например, csr.conf). Обратите внимание, что значение для MASTER_CLUSTER_IP – это cluster IP сервиса для сервера API, как описано в предыдущем подразделе. В приведенном ниже примере предполагается, что cluster.local используется в качестве доменного имени по умолчанию.
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
IP.1 = <MASTER_IP>
IP.2 = <MASTER_CLUSTER_IP>
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
Сгенерируйте запрос на подписание сертификата, используя файл конфигурации:
openssl req -new -key server.key -out server.csr -config csr.conf
С помощью ca.key, ca.crt и server.csr сгенерируйте сертификат сервера:
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf -sha256
Используйте следующую команду, чтобы просмотреть запрос на подписание сертификата:
openssl req -noout -text -in ./server.csr
Используйте следующую команду, чтобы просмотреть сертификат:
openssl x509 -noout -text -in ./server.crt
Наконец, добавьте эти параметры в конфигурацию запуска сервера API.
cfssl – еще один инструмент для генерации сертификатов.
Скачайте, распакуйте и подготовьте пакеты, как показано ниже.
Обратите внимание, что команды необходимо адаптировать под архитектуру и используемую версию cfssl.
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
chmod +x cfssl
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
chmod +x cfssljson
curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
chmod +x cfssl-certinfo
Создайте директорию для хранения артефактов и инициализируйте cfssl:
mkdir cert
cd cert
../cfssl print-defaults config > config.json
../cfssl print-defaults csr > csr.json
Создайте JSON-конфиг для генерации файла CA (например, ca-config.json):
{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "8760h"
}
}
}
}
Создайте JSON-конфиг для запроса на подписание сертификата (CSR) (например,
ca-csr.json). Замените значения, помеченные угловыми скобками, на нужные.
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names":[{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
Сгенерируйте ключ CA (ca-key.pem) и сертификат (ca.pem):
../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
Создайте конфигурационный JSON-файл для генерации ключей и сертификатов для сервера API (например, server-csr.json). Замените значения, помеченные угловыми скобками, на нужные. MASTER_CLUSTER_IP – это cluster IP сервиса для сервера API, как описано в предыдущем подразделе. В приведенном ниже примере предполагается, что cluster.local используется в качестве доменного имени по умолчанию.
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"<MASTER_IP>",
"<MASTER_CLUSTER_IP>",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [{
"C": "<country>",
"ST": "<state>",
"L": "<city>",
"O": "<organization>",
"OU": "<organization unit>"
}]
}
Сгенерируйте ключ и сертификат для сервера API (по умолчанию они сохраняются в файлах server-key.pem и server.pem соответственно):
../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
--config=ca-config.json -profile=kubernetes \
server-csr.json | ../cfssljson -bare server
Клиентский узел может отказаться признавать самоподписанный сертификат CA действительным. В случае его использования не в production или в инсталляциях, защищенных межсетевым экраном, самоподписанный сертификат CA можно распространить среди всех клиентов и обновить локальный список действительных сертификатов.
Для этого на каждом клиенте выполните следующие операции:
sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
done.
Для создания сертификатов x509, которые будут использоваться для аутентификации, можно воспользоваться API certificates.k8s.io. Для дополнительной информации см. Управление TLS-сертификатами в кластере.
На этой странице рассказывается, как настраивать запрос памяти и её лимит для контейнеров. Контейнеру гарантируется столько памяти, сколько он запросит, но не больше установленных ограничений.
Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен на связь с вашим кластером. Если у вас ещё нет кластера, вы можете создать, его используя Minikube, или вы можете использовать одну из песочниц Kubernetes:
Чтобы проверить версию, введите kubectl version.
Каждая нода вашего кластера должна располагать хотя бы 300 Мб памяти.
Некоторые операции на этой странице предполагают работу сервера метрик на вашем кластере. Если сервер метрик у вас уже запущен, следующие действия можно пропустить.
Если вы используете Minikube, выполните следующую команду, чтобы запустить сервер метрик:
minikube addons enable metrics-server
Чтобы проверить работу сервера меток или другого провайдера API ресурсов метрик
(metrics.k8s.io), запустите команду:
kubectl get apiservices
Если API ресурсов метрики доступно, в выводе команды будет содержаться
ссылка на metrics.k8s.io.
NAME
v1beta1.metrics.k8s.io
Создадим пространство имён, чтобы ресурсы, которыми будем пользоваться в данном упражнении, были изолированы от остального кластера:
kubectl create namespace mem-example
Для установки запроса памяти контейнеру подключите поле resources:requests в манифест ресурсов контейнера.
Для ограничений по памяти - добавьте resources:limits.
В этом упражнении создаётся Pod, содержащий один контейнер. Зададим контейнеру запрос памяти в 100 Мб и её ограничение в 200 Мб. Конфигурационный файл для Pod'а:
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
namespace: mem-example
spec:
containers:
- name: memory-demo-ctr
image: polinux/stress
resources:
requests:
memory: "100Mi"
limits:
memory: "200Mi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
Раздел args конфигурационного файла содержит аргументы для контейнера в момент старта.
Аргументы "--vm-bytes", "150M" указывают контейнеру попытаться занять 150 Мб памяти.
Создадим Pod:
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
Убедимся, что контейнер Pod'a запущен:
kubectl get pod memory-demo --namespace=mem-example
Посмотрим подробную информацию о Pod'е:
kubectl get pod memory-demo --output=yaml --namespace=mem-example
В выводе мы видим, что для контейнера в Pod'е зарезервировано 100 Мб памяти и выставлено 200 Мб ограничения.
...
resources:
requests:
memory: 100Mi
limits:
memory: 200Mi
...
Запустим kubectl top, чтобы получить метрики Pod'a:
kubectl top pod memory-demo --namespace=mem-example
Вывод команды показывает, что Pod использовал примерно 162900000 байт памяти - и это около 150 Мб. Данная величина больше установленного запроса в 100 Мб, но укладывается в имеющееся ограничение на 200 Мб.
NAME CPU(cores) MEMORY(bytes)
memory-demo <something> 162856960
Удалим Pod:
kubectl delete pod memory-demo --namespace=mem-example
Контейнер может превысить величину запроса памяти, если нода имеет достаточно ресурсов памяти. Но превышение заданного ограничения памяти не допускается. Если контейнер запрашивает больше памяти, чем ему разрешено использовать, то он становится кандидатом на удаление. Если превышение лимита памяти продолжится, контейнер удаляется. Если удалённый контейнер может быть перезапущен, то kubelet перезапускает его, как и в случае любой другой неполадки в работе.
В этом упражнении создадим Pod, который попытается занять больше памяти, чем для него ограничено. Ниже представлен конфигурационный файл для Pod'a с одним контейнером, имеющим 50 Мб на запрос памяти и 100 Мб лимита памяти:
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-2
namespace: mem-example
spec:
containers:
- name: memory-demo-2-ctr
image: polinux/stress
resources:
requests:
memory: "50Mi"
limits:
memory: "100Mi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]
В разделе args можно увидеть, что контейнер будет пытаться занять
250 Мб - и это значительно превышает лимит в 100 Мб.
Создадим Pod:
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example
Посмотрим подробную информацию о Pod'е:
kubectl get pod memory-demo-2 --namespace=mem-example
В этот момент контейнер уже либо запущен, либо убит. Будем повторять предыдущую команду, пока контейнер не окажется убитым:
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 24s
Посмотрим ещё более подробный вид статуса контейнера:
kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
В выводе показано, что контейнер был убит по причине недостатка памяти (OOM):
lastState:
terminated:
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
exitCode: 137
finishedAt: 2017-06-20T20:52:19Z
reason: OOMKilled
startedAt: null
В данном упражнении контейнер может быть перезапущен, поэтому kubelet стартует его. Выполните следующую команду несколько раз, чтобы увидеть, как контейнер раз за разом убивается и запускается снова:
kubectl get pod memory-demo-2 --namespace=mem-example
Вывод показывает, что контейнер убит, перезапущен, снова убит, перезапущен, и т.д.:
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 37s
kubectl get pod memory-demo-2 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 1/1 Running 2 40s
Посмотрим подробную информацию об истории Pod'a:
kubectl describe pod memory-demo-2 --namespace=mem-example
Вывод показывает, что контейнер постоянно запускается и падает:
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff Back-off restarting failed container
Посмотрим детальную информацию о нодах на кластере:
kubectl describe nodes
В выводе содержится запись о том, что контейнер убивается по причине нехватки памяти:
Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
Удалим Pod:
kubectl delete pod memory-demo-2 --namespace=mem-example
Запросы и ограничения памяти связаны с контейнерами, но полезно также рассматривать эти параметры и для Pod'а. Запросом памяти для Pod'a будет сумма всех запросов памяти контейнеров, имеющихся в Pod'е. Также и лимитом памяти будет сумма всех ограничений, установленных для контейнеров.
Планирование Pod'a основано на запросах. Pod запускается на ноде лишь в случае, если нода может удовлетворить запрос памяти Pod'a.
В данном упражнении мы создадим Pod, чей запрос памяти будет превышать ёмкость любой ноды в кластере. Ниже представлен конфигурационный файл для Pod'a с одним контейнером, имеющим запрос памяти в 1000 Гб (что наверняка превышает ёмкость любой имеющейся ноды):
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-3
namespace: mem-example
spec:
containers:
- name: memory-demo-3-ctr
image: polinux/stress
resources:
requests:
memory: "1000Gi"
limits:
memory: "1000Gi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
Создадим Pod:
kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
Проверим статус Pod'a:
kubectl get pod memory-demo-3 --namespace=mem-example
Вывод показывает, что Pod имеет статус PENDING. Это значит, что он не запланирован ни на одной ноде, и такой статус будет сохраняться всё время:
kubectl get pod memory-demo-3 --namespace=mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-3 0/1 Pending 0 25s
Посмотрим подробную информацию о Pod'е, включающую события:
kubectl describe pod memory-demo-3 --namespace=mem-example
Вывод показывает невозможность запуска контейнера из-за нехватки памяти на нодах:
Events:
... Reason Message
------ -------
... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3).
Удалим Pod:
kubectl delete pod memory-demo-3 --namespace=mem-example
Ресурсы памяти измеряются в байтах. Их можно задавать просто целым числом либо целым числом с одним из следующих окончаний: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. Например, представленные здесь варианты задают приблизительно одну и ту же величину:
128974848, 129e6, 129M , 123Mi
Если вы не задали ограничение памяти для контейнера, возможны следующие варианты:
У контейнера отсутствует верхняя граница для памяти, которую он может использовать. Такой контейнер может занять всю память, доступную на ноде, где он запущен, что, в свою очередь, может вызвать OOM Killer. Также контейнеры без ограничений по ресурсам имеют более высокие шансы быть убитыми в случае вызова OOM Kill.
Контейнер запущен в пространстве имён, в котором настроена величина ограничений по умолчанию. Тогда контейнеру автоматически присваивается это стандартное значение лимита. Администраторы кластера могут использовать LimitRange для задания стандартной величины ограничений по памяти.
При помощи задания величины запросов и лимитов памяти для контейнеров, запущенных на вашем кластере, можно эффективно распоряжаться имеющимися на нодах ресурсами. Задание Pod'у небольшого запроса памяти даёт хорошие шансы для него быть запланированным. Ограничение памяти, превышающее величину запроса памяти, позволяет достичь 2 вещей:
Pod может иметь всплески активности, в течение которых ему может потребоваться дополнительная память.
Величина памяти, доступная Pod'у при повышении активности, ограничена некоторой разумной величиной.
Удалим пространство имён. Эта операция удалит все Pod'ы, созданные в рамках данного упражнения:
kubectl delete namespace mem-example
На этой странице показывается, как настроить запрос CPU и лимит CPU для контейнера. Контейнер не сможет использовать больше ресурсов CPU, чем для него ограничено. Если в системе есть свободное время CPU, контейнеру гарантируется выдача запрошенных им ресурсов CPU.
Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен на связь с вашим кластером. Если у вас ещё нет кластера, вы можете создать, его используя Minikube, или вы можете использовать одну из песочниц Kubernetes:
Чтобы проверить версию, введите kubectl version.
На кластере должен быть хотя бы 1 доступный для работы CPU, чтобы запускать учебные примеры.
Для некоторых шагов с этой страницы понадобится запущенный сервер метрик на вашем кластере. Если сервер метрик уже запущен, следующие шаги можно пропустить.
Если вы используете Minikube, выполните следующую команду, чтобы запустить сервер метрик:
minikube addons enable metrics-server
Проверим, работает ли сервер метрик (или другой провайдер API ресурсов метрик,
metrics.k8s.io), выполните команду:
kubectl get apiservices
Если API ресурсов метрик доступно, в выводе будет присутствовать
ссылка на metrics.k8s.io.
NAME
v1beta1.metrics.k8s.io
Создадим Пространство имен, чтобы создаваемые в этом упражнении ресурсы были изолированы от остального кластера.
kubectl create namespace cpu-example
Чтобы установить запрос CPU для контейнера, подключите поле resources:requests
в манифест ресурсов контейнера. Для установки ограничения по CPU подключите resources:limits.
В этом упражнении мы создадим Pod, имеющий один контейнер. Зададим для контейнера запрос в 0.5 CPU и лимит в 1 CPU. Конфигурационный файл для такого Pod'а:
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
namespace: cpu-example
spec:
containers:
- name: cpu-demo-ctr
image: vish/stress
resources:
limits:
cpu: "1"
requests:
cpu: "0.5"
args:
- -cpus
- "2"
Раздел args конфигурационного файла содержит аргументы для контейнера в момент старта.
Аргумент -cpus "2" говорит контейнеру попытаться использовать 2 CPU.
Создадим Pod:
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
Удостоверимся, что Pod запущен:
kubectl get pod cpu-demo --namespace=cpu-example
Посмотрим детальную информацию о Pod'е:
kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
В выводе видно, что Pod имеет один контейнер с запросом в 500 милли-CPU и с ограничением в 1 CPU.
resources:
limits:
cpu: "1"
requests:
cpu: 500m
Запустим kubectl top, чтобы получить метрики Pod'a:
kubectl top pod cpu-demo --namespace=cpu-example
В этом варианте вывода Pod'ом использовано 974 милли-CPU, что лишь чуть меньше заданного в конфигурации Pod'a ограничения в 1 CPU.
NAME CPU(cores) MEMORY(bytes)
cpu-demo 974m <something>
Напомним, что установкой параметра -cpu "2" для контейнера было задано попытаться использовать 2 CPU,
однако в конфигурации присутствует ограничение всего в 1 CPU. Использование контейнером CPU было отрегулировано,
поскольку он попытался занять больше ресурсов, чем ему позволено.
Удалим Pod:
kubectl delete pod cpu-demo --namespace=cpu-example
Ресурсы CPU измеряются в CPU единицах. Один CPU, в Kubernetes, соответствует:
Дробные значения возможны. Контейнер, запрашивающий 0.5 CPU, получит вполовину меньше ресурсов, чем контейнер, запрашивающий 1 CPU. Можно использовать окончание m для обозначения милли. Например, 100m CPU, 100 milliCPU и 0.1 CPU обозначают одно и то же. Точность выше 1m не поддерживается.
CPU всегда запрашивается в абсолютных величинах, не в относительных; 0.1 будет одинаковой частью от CPU для одноядерного, двухъядерного или 48-ядерного процессора.
Запросы и лимиты CPU устанавливаются для контейнеров, но также полезно рассматривать и Pod имеющим эти характеристики. Запросом CPU для Pod'а является сумма запросов CPU всех его контейнеров. Аналогично и лимит CPU для Pod'а - сумма всех ограничений CPU у его контейнеров.
Планирование Pod'а основано на запросах. Pod попадает в расписание запуска на ноде лишь в случае достаточного количества доступных ресурсов CPU на ноде, чтобы удовлетворить запрос CPU Pod'а.
В этом упражнении мы создадим Pod с запросом CPU, превышающим мощности любой ноды в вашем кластере. Ниже представлен конфигурационный файл для Pod'а с одним контейнером. Контейнер запрашивает 100 CPU, что почти наверняка превышает имеющиеся мощности любой ноды в кластере.
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo-2
namespace: cpu-example
spec:
containers:
- name: cpu-demo-ctr-2
image: vish/stress
resources:
limits:
cpu: "100"
requests:
cpu: "100"
args:
- -cpus
- "2"
Создадим Pod:
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
Проверим статус Pod'а:
kubectl get pod cpu-demo-2 --namespace=cpu-example
Вывод показывает Pending статус у Pod'а. То есть Pod не запланирован к запуску ни на одной ноде и будет оставаться в статусе Pending постоянно:
NAME READY STATUS RESTARTS AGE
cpu-demo-2 0/1 Pending 0 7m
Посмотрим подробную информацию о Pod'е, включающую в себя события:
kubectl describe pod cpu-demo-2 --namespace=cpu-example
В выводе отражено, что контейнер не может быть запланирован из-за нехватки ресурсов CPU на нодах:
Events:
Reason Message
------ -------
FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3).
Удалим Pod:
kubectl delete pod cpu-demo-2 --namespace=cpu-example
Если ограничения на использование контейнером CPU не установлены, возможны следующие варианты:
У контейнера отсутствует верхняя граница количества CPU доступных ему ресурсов. В таком случае он может занять все ресурсы CPU, доступные на ноде, на которой он запущен.
Контейнер запущен в пространстве имён, в котором задана стандартная величина ограничения ресурсов CPU. Тогда контейнеру автоматически присваивается это ограничение. Администраторы кластера могут использовать LimitRange, чтобы задать стандартную величину ограничения ресурсов CPU.
Вы можете распоряжаться ресурсами CPU на нодах вашего кластера эффективнее, если для запущенных контейнеров установлены запросы и ограничения на использование ресурсов CPU. Задание небольшого запроса CPU даёт Pod'у хорошие шансы быть запланированным. Установка лимита на ресурсы CPU, большего, чем запрос, позволяет достичь 2 вещей:
Удалим созданное для этого упражнения пространство имён:
kubectl delete namespace cpu-example
На этой странице рассказывается, как настроить liveness, readiness и startup пробы для контейнеров.
Kubelet использует liveness пробу для проверки, когда перезапустить контейнер. Например, liveness проба должна поймать блокировку, когда приложение запущено, но не может ничего сделать. В этом случае перезапуск приложения может помочь сделать приложение более доступным, несмотря на баги.
Kubelet использует readiness пробы, чтобы узнать, готов ли контейнер принимать траффик. Pod считается готовым, когда все его контейнеры готовы.
Одно из применений такого сигнала - контроль, какие Pod будут использованы в качестве бек-енда для сервиса. Пока Pod не в статусе ready, он будет исключен из балансировщиков нагрузки сервиса.
Kubelet использует startup пробы, чтобы понять, когда приложение в контейнере было запущено. Если проба настроена, он блокирует liveness и readiness проверки, до того как проба становится успешной, и проверяет, что эта проба не мешает запуску приложения. Это может быть использовано для проверки работоспособности медленно стартующих контейнеров, чтобы избежать убийства kubelet'ом прежде, чем они будут запущены.
Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен на связь с вашим кластером. Если у вас ещё нет кластера, вы можете создать, его используя Minikube, или вы можете использовать одну из песочниц Kubernetes:
Чтобы проверить версию, введите kubectl version.
Многие приложения, работающие в течение длительного времени, ломаются и могут быть восстановлены только перезапуском. Kubernetes предоставляет liveness пробы, чтобы обнаруживать и исправлять такие ситуации.
В этом упражнении вы создадите Pod, который запускает контейнер, основанный на образе registry.k8s.io/busybox. Конфигурационный файл для Pod'а:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: registry.k8s.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
В конфигурационном файле вы можете видеть, что Pod состоит из одного Container.
Поле periodSeconds определяет, что kubelet должен производить liveness
пробы каждые 5 секунд. Поле initialDelaySeconds говорит kubelet'у, что он должен ждать 5 секунд перед первой пробой. Для проведения пробы
kubelet исполняет команду cat /tmp/healthy в целевом контейнере.
Если команда успешна, она возвращает 0, и kubelet считает контейнер живым и здоровым.
Если команда возвращает ненулевое значение, kubelet убивает и перезапускает контейнер.
Когда контейнер запускается, он исполняет команду
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"
Для первых 30 секунд жизни контейнера существует файл /tmp/healthy.
Поэтому в течение первых 30 секунд команда cat /tmp/healthy возвращает код успеха. После 30 секунд cat /tmp/healthy возвращает код ошибки.
Создание Pod:
kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
В течение 30 секунд посмотрим события Pod:
kubectl describe pod liveness-exec
Вывод команды показывает, что ещё ни одна liveness проба не завалена:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "registry.k8s.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "registry.k8s.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
После 35 секунд посмотрим события Pod снова:
kubectl describe pod liveness-exec
Внизу вывода появились сообщения, показывающие, что liveness проба завалена и containers был убит и пересоздан.
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "registry.k8s.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "registry.k8s.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Подождите ещё 30 секунд и убедитесь, что контейнер был перезапущен:
kubectl get pod liveness-exec
Вывод команды показывает, что RESTARTS увеличено на 1:
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
Другой вид liveness пробы использует запрос HTTP GET. Ниже представлен файл конфигурации для Pod, который запускает контейнер, основанный на образе registry.k8s.io/e2e-test-images/agnhost.
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: registry.k8s.io/e2e-test-images/agnhost:2.40
args:
- liveness
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
В конфигурационном файле вы можете видеть Pod с одним контейнером.
Поле periodSeconds определяет, что kubelet должен производить liveness
пробы каждые 3 секунды. Поле initialDelaySeconds сообщает kubelet'у, что он должен ждать 3 секунды перед проведением первой пробы. Для проведения пробы
kubelet отправляет запрос HTTP GET на сервер, который запущен в контейнере и слушает порт 8080. Если обработчик пути /healthz на сервере
возвращает код успеха, kubelet рассматривает контейнер как живой и здоровый. Если обработчик возвращает код ошибки, kubelet убивает и перезапускает контейнер.
Любой код, больший или равный 200 и меньший 400, означает успех. Любой другой код интерпретируется как ошибка.
Вы можете посмотреть исходные коды сервера в server.go.
В течение первых 10 секунд жизни контейнера обработчик /healthz
возвращает статус 200. После обработчик возвращает статус 500.
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
duration := time.Now().Sub(started)
if duration.Seconds() > 10 {
w.WriteHeader(500)
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
} else {
w.WriteHeader(200)
w.Write([]byte("ok"))
}
})
Kubelet начинает выполнять health checks через 3 секунды после старта контейнера. Итак, первая пара проверок будет успешна. Но после 10 секунд health checks будут завалены и kubelet убьёт и перезапустит контейнер.
Чтобы попробовать HTTP liveness проверку, создайте Pod:
kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
Через 10 секунд посмотрите события Pod, чтобы проверить, что liveness probes завалилась и container перезапустился:
kubectl describe pod liveness-http
В релизах до v1.13 (включая v1.13), если переменная окружения
http_proxy (или HTTP_PROXY) определена на node, где запущен Pod,
HTTP liveness проба использует этот прокси.
В версиях после v1.13, определение локальной HTTP прокси в переменной окружения не влияет на HTTP liveness пробу.
Третий тип liveness проб использует TCP сокет. С этой конфигурацией kubelet будет пытаться открыть сокет к вашему контейнеру на определённый порт. Если он сможет установить соединение, контейнер будет считаться здоровым, если нет, будет считаться заваленным.
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: registry.k8s.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
Как вы можете видеть, конфигурация TCP проверок довольно похожа на HTTP проверки.
Этот пример использует обе - readiness и liveness пробы. Kubelet будет отправлять первую readiness пробу через 5 секунд после старта контейнера. Он будет пытаться соединиться с goproxy контейнером на порт 8080. Если проба успешна, Pod
будет помечен как ready. Kubelet будет продолжать запускать эту проверку каждые 10 секунд.
В дополнение к readiness пробе, конфигурация включает liveness пробу.
Kubelet запустит первую liveness пробу через 15 секунд после старта контейнера. Аналогично readiness пробе, он будет пытаться соединиться с контейнером goproxy на порт 8080. Если liveness проба завалится, контейнер будет перезапущен.
Для испытаний TCP liveness проверки, создадим Pod:
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
Через 15 секунд посмотрим события Pod'а для проверки liveness пробы:
kubectl describe pod goproxy
Вы можете использовать именованный порт ContainerPort для HTTP или TCP liveness проверок:
ports:
- name: liveness-port
containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
Иногда приходится иметь дело со старыми приложениями, которым может требоваться дополнительное время для запуска
на их первую инициализацию.
В таких случаях бывает сложно настроить параметры liveness пробы без ущерба для скорости реакции на deadlock'и, для выявления которых как раз и нужна liveness проба.
Хитрость заключается в том, чтобы настроить startup пробу с такой же командой, что и HTTP или TCP проверка, но failureThreshold * periodSeconds должно быть достаточным, чтобы покрыть наихудшее время старта.
Итак, предыдущий пример будет выглядеть так:
ports:
- name: liveness-port
containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
Благодаря startup пробе, приложению дано максимум 5 минут
(30 * 10 = 300 сек.) для завершения его старта.
Как только startup проба успешна 1 раз, liveness проба начинает контролировать дедлоки контейнеров.
Если startup probe так и не заканчивается успехом, контейнер будет убит через 300 секунд и подвергнется restartPolicy pod'а.
Иногда приложения временно не могут обслужить траффик. Например, приложение может требовать загрузки огромных данных или конфигурационных файлов во время старта, или зависит от внешних сервисов после старта. В таких случаях вы не хотите убивать приложение, но и отправлять ему клиентские запросы тоже не хотите. Kubernetes предоставляет readiness пробы для определения и нивелирования таких ситуаций. Pod с контейнерами сообщает, что они не готовы принимать траффик через Kubernetes Services.
Readiness пробы настраиваются аналогично liveness пробам. Единственная разница в использовании поля readinessProbe вместо livenessProbe.
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Конфигурация HTTP и TCP readiness проб также идентичны liveness пробам.
Readiness и liveness пробы могут быть использованы одновременно на одном контейнере. Использование обеих проб может обеспечить отсутствие траффика в контейнер, пока он не готов для этого, и контейнер будет перезапущен, если сломается.
Probes имеют несколько полей, которые вы можете использовать для более точного контроля поведения liveness и readiness проверок:
initialDelaySeconds: Количество секунд от старта контейнера до инициации startup-, liveness- или readiness-проб. Если определена startup-проба, задержки от liveness- и readiness-проб не вступают в силу, пока startup-проба не завершилась с успехом. Если значение periodSeconds выше initialDelaySeconds, то initialDelaySeconds игнорируется. По умолчанию 0 секунд. Минимальное значение 0.periodSeconds: Длительность времени (в секундах) между двумя последовательными проведениями проб. По умолчанию 10
секунд. Минимальное значение 1.timeoutSeconds: Количество секунд ожидания пробы. По умолчанию
1 секунда. Минимальное значение 1.successThreshold: Минимальное количество последовательных проверок, чтобы проба считалась успешной после неудачной. По умолчанию 1.
Должна быть 1 для liveness. Минимальное значение 1.failureThreshold: Когда Pod стартует и проба даёт ошибку, Kubernetes будет пытаться failureThreshold раз перед тем, как сдаться. Сдаться в этом случае для liveness пробы означает перезапуск контейнера. В случае readiness пробы Pod будет помечен Unready.
По умолчанию 3. Минимальное значение 1.HTTP пробы
имеют дополнительные поля, которые могут быть установлены для httpGet:
host: Имя хоста для соединения, по умолчанию pod IP. Вы, возможно, захотите установить заголовок "Host" в httpHeaders вместо этого.scheme: Схема для соединения к хосту (HTTP or HTTPS). По умолчанию HTTP.path: Путь для доступа к HTTP серверу.httpHeaders: Кастомные заголовки запроса. HTTP позволяет повторяющиеся заголовки.port: Имя или номер порта для доступа к контейнеру. Номер должен быть в диапазоне от 1 до 65535.Для HTTP проб kubelet отправляет HTTP запрос на настроенный путь и
порт для проведения проверок. Kubelet отправляет пробу на IP адрес pod’а,
если адрес не переопределён необязательным полем host в httpGet. Если поле scheme установлено в HTTPS, kubelet отправляет HTTPS запрос, пропуская проверку сертификата. В большинстве сценариев вам не нужно устанавливать поле host.
Рассмотрим один сценарий, где бы он мог понадобиться. Допустим, контейнер слушает 127.0.0.1 и поле Pod'а hostNetwork задано в true. Поле host опции httpGet должно быть задано в 127.0.0.1. Если pod полагается на виртуальные хосты, что, скорее всего, более распространённая ситуация, лучше вместо поля host устанавливать заголовок Host в httpHeaders.
Для TCP проб kubelet устанавливает соединение с ноды, не внутри pod, что означает, что вы не можете использовать service name в параметре host, пока kubelet не может выполнить его резолв.
Вы также можете прочитать API references для:
На этой странице показано, как создавать, редактировать, управлять и удалять Kubernetes
Secrets с помощью инструмента командной строки kubectl.
Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен на связь с вашим кластером. Если у вас ещё нет кластера, вы можете создать, его используя Minikube, или вы можете использовать одну из песочниц Kubernetes:
Объект Secret хранит конфиденциальные данные, например учётные данные,
используемые Pod'ами для доступа к сервисам. К примеру, может потребоваться Secret
для хранения имени пользователя и пароля, необходимых для доступа к базе данных.
Secret можно создать, передав данные непосредственно в команде или сохранив
учётные данные в файлах и указав их в команде. Следующие команды создают Secret,
в котором хранятся имя пользователя admin и пароль S!B\*d$zDsb=.
Выполните следующую команду:
kubectl create secret generic db-user-pass \
--from-literal=username=admin \
--from-literal=password='S!B\*d$zDsb='
Для экранирования специальных символов ($, \, *, =, !) в строках
необходимо использовать одинарные кавычки ''. В противном случае оболочка
интерпретирует эти символы самостоятельно.
stringData у Secret плохо работает совместно с серверным применением (server-side apply).Сохраните учётные данные в файлы:
echo -n 'admin' > ./username.txt
echo -n 'S!B\*d$zDsb=' > ./password.txt
Флаг -n гарантирует, что в конце текста в сгенерированных файлах не будет
лишнего символа новой строки. Это важно, поскольку при чтении файла и кодировании
содержимого в строку base64 утилита kubectl закодирует лишний символ новой строки
тоже. Экранировать специальные символы в строках, содержащихся в файле, не нужно.
Передайте пути к файлам в команде kubectl:
kubectl create secret generic db-user-pass \
--from-file=./username.txt \
--from-file=./password.txt
По умолчанию именем ключа становится имя файла. При желании можно указать имя ключа
явно с помощью --from-file=[key=]source. Например:
kubectl create secret generic db-user-pass \
--from-file=username=./username.txt \
--from-file=password=./password.txt
При использовании любого из этих методов вывод будет аналогичен следующему:
secret/db-user-pass created
Убедитесь, что Secret был создан:
kubectl get secrets
Вывод будет аналогичен следующему:
NAME TYPE DATA AGE
db-user-pass Opaque 2 51s
Просмотрите подробную информацию о Secret:
kubectl describe secret db-user-pass
Вывод будет аналогичен следующему:
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 12 bytes
username: 5 bytes
Команды kubectl get и kubectl describe по умолчанию не отображают содержимое Secret.
Это сделано для защиты от случайного раскрытия данных или их сохранения в логах терминала.
Просмотрите содержимое созданного Secret:
kubectl get secret db-user-pass -o jsonpath='{.data}'
Вывод будет аналогичен следующему:
{ "password": "UyFCXCpkJHpEc2I9", "username": "YWRtaW4=" }
Декодируйте данные поля password:
echo 'UyFCXCpkJHpEc2I9' | base64 --decode
Вывод будет аналогичен следующему:
S!B\*d$zDsb=
kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode
Вы можете редактировать существующий объект Secret, если он не является
неизменяемым.
Для редактирования Secret выполните следующую команду:
kubectl edit secrets <secret-name>
Откроется редактор по умолчанию, позволяющий обновить закодированные в base64
значения Secret в поле data, как показано в следующем примере:
# Пожалуйста, отредактируйте объект ниже. Строки, начинающиеся с '#', будут проигнорированы,
# а пустой файл отменит редактирование. При возникновении ошибки во время сохранения файл
# будет открыт повторно с указанием неполадок.
#
apiVersion: v1
data:
password: UyFCXCpkJHpEc2I9
username: YWRtaW4=
kind: Secret
metadata:
creationTimestamp: "2022-06-28T17:44:13Z"
name: db-user-pass
namespace: default
resourceVersion: "12708504"
uid: 91becd59-78fa-4c85-823f-6d44436242ac
type: Opaque
Чтобы удалить Secret, выполните следующую команду:
kubectl delete secret db-user-pass
Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен на связь с вашим кластером. Если у вас ещё нет кластера, вы можете создать, его используя Minikube, или вы можете использовать одну из песочниц Kubernetes:
Сначала можно описать Secret в манифесте в формате JSON или YAML,
а затем создать этот объект. Ресурс
Secret
содержит два отображения: data и stringData.
Поле data используется для хранения произвольных данных, закодированных в base64.
Поле stringData предоставлено для удобства и позволяет указывать те же данные
в виде незакодированных строк.
Ключи полей data и stringData должны состоять из буквенно-цифровых символов,
-, _ или ..
В следующем примере в Secret с помощью поля data сохраняются две строки.
Закодируйте строки в base64:
echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64
base64 в Darwin/macOS следует избегать опции -b для разбиения длинных строк. Пользователям Linux, напротив, следует добавлять опцию -w 0 к командам base64 или использовать конвейер base64 | tr -d '\n', если опция -w недоступна.Вывод будет аналогичен следующему:
YWRtaW4=
MWYyZDFlMmU2N2Rm
Создайте манифест:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Обратите внимание, что имя Secret должно быть допустимым именем DNS-поддомена.
Создайте Secret с помощью kubectl apply:
kubectl apply -f ./secret.yaml
Вывод будет аналогичен следующему:
secret/mysecret created
Чтобы проверить, что Secret был создан, и декодировать его данные, обратитесь к разделу Управление Secrets с помощью kubectl.
В ряде сценариев может потребоваться использовать поле stringData. Оно позволяет
помещать строки без кодирования base64 непосредственно в Secret; при создании или
обновлении Secret строка будет закодирована автоматически.
Практический пример такого подхода — развёртывание приложения, которое использует Secret для хранения конфигурационного файла, когда часть значений этого файла нужно задать в процессе развёртывания.
Например, если приложение использует следующий конфигурационный файл:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
Его можно сохранить в Secret с помощью следующего определения:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
stringData у Secret плохо работает совместно с серверным применением (server-side apply).При получении данных Secret команда вернёт закодированные значения,
а не исходный открытый текст, переданный в поле stringData.
Например, при выполнении следующей команды:
kubectl get secret mysecret -o yaml
Вывод будет аналогичен следующему:
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data и stringDataЕсли одно и то же поле указано одновременно в data и stringData, используется
значение из stringData.
Например, если определить следующий Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
stringData у Secret плохо работает совместно с серверным применением (server-side apply).Объект Secret будет создан следующим образом:
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
YWRtaW5pc3RyYXRvcg== декодируется в administrator.
Чтобы изменить данные в Secret, созданном с помощью манифеста, отредактируйте
поле data или stringData в манифесте и примените файл к кластеру.
Вы можете редактировать существующий объект Secret, если он не является
неизменяемым.
Например, чтобы изменить пароль из предыдущего примера на birdsarentreal,
выполните следующие действия:
Закодируйте новую строку пароля:
echo -n 'birdsarentreal' | base64
Вывод будет аналогичен следующему:
YmlyZHNhcmVudHJlYWw=
Обновите поле data, указав новую строку пароля:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: YmlyZHNhcmVudHJlYWw=
Примените манифест к кластеру:
kubectl apply -f ./secret.yaml
Вывод будет аналогичен следующему:
secret/mysecret configured
Kubernetes обновит существующий Secret. Подробнее: инструмент kubectl
обнаруживает существующий Secret с тем же именем, получает его, планирует
изменения и отправляет обновлённый Secret на управляющий слой кластера.
Если вместо этого указать kubectl apply --server-side, утилита kubectl будет
использовать Server Side Apply.
Чтобы удалить созданный Secret:
kubectl delete secret mysecret
kubectl поддерживает использование инструмента управления объектами Kustomize для управления Secrets
и ConfigMaps. С помощью Kustomize создаётся генератор ресурсов, который
формирует Secret, применяемый к API-серверу командой kubectl.
Вам нужен Kubernetes кластер и инструмент командной строки kubectl должен быть настроен на связь с вашим кластером. Если у вас ещё нет кластера, вы можете создать, его используя Minikube, или вы можете использовать одну из песочниц Kubernetes:
Secret можно сгенерировать, определив secretGenerator в файле
kustomization.yaml, который ссылается на существующие файлы, файлы .env
или литеральные значения. Например, следующие инструкции создают файл
kustomization для имени пользователя admin и пароля 1f2d1e2e67df.
stringData у Secret плохо работает совместно с серверным применением (server-side apply).
secretGenerator:
- name: database-creds
literals:
- username=admin
- password=1f2d1e2e67df
Сохраните учётные данные в файлы. Имена файлов станут ключами Secret:
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt
Флаг -n гарантирует отсутствие символа новой строки в конце файлов.
Создайте файл kustomization.yaml:
secretGenerator:
- name: database-creds
files:
- username.txt
- password.txt
secretGenerator в файле kustomization.yaml можно также определить с помощью
файлов .env. Например, следующий файл kustomization.yaml считывает данные
из файла .env.secret:
secretGenerator:
- name: db-user-pass
envs:
- .env.secret
Во всех случаях кодировать значения в base64 не нужно. Имя YAML-файла должно
быть kustomization.yaml или kustomization.yml.
Чтобы создать Secret, примените директорию, содержащую файл kustomization:
kubectl apply -k <directory-path>
Вывод будет аналогичен следующему:
secret/database-creds-5hdh7hhgfk created
При генерации Secret его имя формируется путём хэширования данных Secret и добавления значения хэша к имени. Это гарантирует, что при каждом изменении данных будет сгенерирован новый Secret.
Чтобы убедиться, что Secret был создан, и декодировать его данные:
kubectl get -k <directory-path> -o jsonpath='{.data}'
Вывод будет аналогичен следующему:
{ "password": "MWYyZDFlMmU2N2Rm", "username": "YWRtaW4=" }
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
Вывод будет аналогичен следующему:
1f2d1e2e67df
Дополнительную информацию см. в разделах Управление Secrets с помощью kubectl и Декларативное управление объектами Kubernetes с помощью Kustomize.
Измените данные в файле kustomization.yaml, например значение password.
Примените директорию, содержащую файл kustomization:
kubectl apply -k <directory-path>
Вывод будет аналогичен следующему:
secret/db-user-pass-6f24b56cc8 created
Отредактированный Secret создаётся как новый Secret, а не обновляет существующий. Возможно, потребуется обновить ссылки на Secret в ваших Pod'ах.
Чтобы удалить Secret, используйте kubectl:
kubectl delete secret db-user-pass