Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.
Цей розділ документації Kubernetes містить сторінки, які показують, як виконувати окремі завдання. Сторінка завдання показує, як виконати одну дію, зазвичай за допомогою короткої послідовності кроків.
Якщо ви хочете написати сторінку завдання, дивіться Створення запиту на злиття для документації.
Інструмент командного рядка Kubernetes, kubectl, дозволяє виконувати команди в кластерах Kubernetes. За допомогою kubectl можна розгортати застосунки, оглядати ресурси кластера й керувати ними, а також переглядати логи. Докладніше, зокрема повний перелік операцій kubectl, дивіться в довідковій документації kubectl.
kubectl можна встановити на різних платформах Linux, macOS і Windows. Виберіть свою операційну систему нижче.
kind дозволяє запускати Kubernetes на вашому локальному компʼютері. Для цього інструмента потрібно встановити Docker або Podman.
На сторінці kind Quick Start показано, що потрібно зробити, щоб почати працювати з kind.
Переглянути посібник kind Quick Start
Подібно до kind, minikube — це інструмент, який дозволяє запускати Kubernetes локально. minikube запускає локальний кластер Kubernetes «все в одному» або багатовузловий кластер на вашому персональному компʼютері (зокрема на ПК з Windows, macOS і Linux), щоб ви могли випробувати Kubernetes або використовувати його для щоденної розробки.
Якщо ваша мета — встановити інструмент, скористайтеся офіційним посібником Get Started!.
Переглянути посібник minikube Get Started!
Коли minikube запрацює, ви зможете використовувати його для запуску застосунку-прикладу.
Ви можете використовувати інструмент kubeadm для створення кластерів Kubernetes і керування ними. Він виконує дії, потрібні для зручного запуску мінімально життєздатного захищеного кластера.
На сторінці Встановлення kubeadm показано, як встановити kubeadm. Після встановлення ви можете використовувати його для створення кластера.
Вам потрібно використовувати версію kubectl, яка має мінорну версію, що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.37 може співпрацювати з панелями управління v1.36, v1.37 та v1.38. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.
Існують наступні методи встановлення kubectl у Linux:
Завантажте останній випуск за допомогою команди:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl"
Щоб завантажити певну версію, замініть частину команди $(curl -L -s https://dl.k8s.io/release/stable.txt) конкретною версією.
Наприклад, щоб завантажити версію 1.37.0 у Linux x86-64, введіть:
curl -LO https://dl.k8s.io/release/v1.37.0/bin/linux/amd64/kubectl
А для Linux ARM64:
curl -LO https://dl.k8s.io/release/v1.37.0/bin/linux/arm64/kubectl
Перевірте бінарний файл (необовʼязково)
Завантажте файл контрольної суми kubectl:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256"
Перевірте бінарний файл kubectl за допомогою файлу контрольної суми:
echo "$(cat kubectl.sha256) kubectl" | sha256sum --check
Якщо перевірка успішна, вивід буде таким:
kubectl: OK
Якщо перевірка не пройшла, sha256 поверне ненульовий статус і виведе повідомлення подібне до:
kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
Встановіть kubectl
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
Якщо у вас немає прав root на цільовій системі, все одно можна встановити
kubectl у теку ~/.local/bin:
chmod +x kubectl
mkdir -p ~/.local/bin
mv ./kubectl ~/.local/bin/kubectl
# а потім додайте (в початок чи кінець) ~/.local/bin до $PATH
Перевірте, щоб переконатися, що встановлена вами версія є актуальною:
kubectl version --client
Або скористайтеся цим для детального перегляду версії:
kubectl version --client --output=yaml
Оновіть індекс пакунків apt та встановіть пакунки, необхідні для використання репозиторію apt Kubernetes:
sudo apt-get update
# apt-transport-https може бути макетним пакетом; якщо так, ви можете пропустити цей пакет
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
Завантажте публічний ключ підпису для репозиторіїв пакунків Kubernetes. Той самий ключ підпису використовується для всіх репозиторіїв, тому ви можете проігнорувати версію в URL:
# Якщо тека `/etc/apt/keyrings` не існує, її слід створити перед запуском curl, прочитайте примітку нижче.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.37/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # дозволяє непривілейованим програмам APT читати цей ключ
/etc/apt/keyrings типово не існує, її слід створити перед запуском команди curl.Додайте відповідний репозиторій Kubernetes apt. Якщо ви хочете використовувати версію Kubernetes, відмінну від v1.37, замініть v1.37 на потрібну мінорну версію в команді нижче:
# Це перезапише будь-яку існуючу конфігурацію в /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # допомагає правильно працювати з такими інструментами, як command-not-found
/etc/apt/sources.list.d/kubernetes.list перед виконанням apt-get update та apt-get upgrade. Цю процедуру більш докладно описано в Зміні репозиторію пакунків Kubernetes.Оновіть індекс пакунків apt, а потім встановіть kubectl:
sudo apt-get update
sudo apt-get install -y kubectl
Додайте репозиторій Kubernetes yum. Якщо ви хочете використовувати версію Kubernetes, відмінну від v1.37, замініть v1.37 на потрібну мінорну версію в команді нижче.
# Це перезапише будь-яку існуючу конфігурацію у /etc/yum.repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/repodata/repomd.xml.key
EOF
/etc/yum.repos.d/kubernetes.repo перед виконанням dnf update. Цю процедуру більш докладно описано в Зміні репозиторію пакунків Kubernetes.Встановіть kubectl за допомогою dnf:
sudo dnf install -y kubectl
Додайте репозиторій Kubernetes zypper. Якщо ви хочете використовувати версію Kubernetes, відмінну від v1.37, замініть v1.37 на потрібну мінорну версію в команді нижче.
# Це перезапише будь-яку існуючу конфігурацію у /etc/zypp/repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/repodata/repomd.xml.key
EOF
/etc/zypp/repos.d/kubernetes.repo перед виконанням zypper update. Цю процедуру більш докладно описано в
Зміні репозиторію пакунків Kubernetes.Оновіть zypper і підтвердіть додавання нового репозиторію:
sudo zypper update
Коли зʼявиться таке повідомлення, натисніть 't' або 'a':
New repository or package signing key received:
Repository: Kubernetes
Key Fingerprint: 1111 2222 3333 4444 5555 6666 7777 8888 9999 AAAA
Key Name: isv:kubernetes OBS Project <isv:kubernetes@build.opensuse.org>
Key Algorithm: RSA 2048
Key Created: Thu 25 Aug 2022 01:21:11 PM -03
Key Expires: Sat 02 Nov 2024 01:21:11 PM -03 (expires in 85 days)
Rpm Name: gpg-pubkey-9a296436-6307a177
Note: Signing data enables the recipient to verify that no modifications occurred after the data
were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
and in extreme cases even to a system compromise.
Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
you are not sure whether the presented key is authentic, ask the repository provider or check
their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
are using.
Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a
Встановіть kubectl, використовуючи zypper:
sudo zypper install -y kubectl
Якщо ви користуєтеся Ubuntu або іншим дистрибутивом Linux, який підтримує менеджер пакунків snap, kubectl доступний як застосунок snap.
snap install kubectl --classic
kubectl version --client
Якщо ви користуєтеся Linux і використовуєте пакетний менеджер Homebrew, kubectl доступний для встановлення.
brew 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
У Kubernetes 1.26 з kubectl вилучено вбудовану автентифікацію для керованих сервісів Kubernetes таких хмарних провайдерів. Ці провайдери випустили втулки kubectl, що забезпечують автентифікацію для їхніх хмар. Інструкції дивіться в документації провайдера:
Те саме повідомлення про помилку може мати й інші причини, не повʼязані з цією зміною.
kubectl надає підтримку автодоповнення для оболонок Bash, Zsh, Fish та PowerShell, що може зекономити вам багато часу на набір тексту.
Нижче наведені процедури для налаштування автодоповнення для оболонок Bash, Fish та Zsh.
Скрипт автодоповнення kubectl для Bash можна згенерувати командою kubectl completion bash. Підключення цього скрипта у вашій оболонці вмикає автодоповнення kubectl.
Однак скрипт автодоповнення залежить від bash-completion, тому спочатку потрібно встановити це програмне забезпечення (ви можете перевірити, чи вже встановлено bash-completion, виконавши type _init_completion).
bash-completion є в багатьох менеджерах пакунків (див. тут). Ви можете встановити його за допомогою apt-get install bash-completion, dnf 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 в усіх сеансах оболонки. Це можна зробити двома способами:
echo 'source <(kubectl completion bash)' >>~/.bashrc
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
sudo chmod a+r /etc/bash_completion.d/kubectl
Якщо у вас є псевдонім для kubectl, ви можете розширити автодоповнення оболонки, щоб воно працювало з цим псевдонімом:
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
/etc/bash_completion.d.Обидва підходи рівноцінні. Після перезавантаження оболонки автодоповнення kubectl має працювати. Щоб увімкнути автодоповнення bash у поточному сеансі оболонки, підключіть файл ~/.bashrc:
source ~/.bashrc
Скрипт автодоповнення kubectl для Fish можна згенерувати командою kubectl completion fish. Підключення цього скрипта у вашій оболонці вмикає автодоповнення kubectl.
Щоб зробити це в усіх сеансах оболонки, додайте такий рядок до файлу ~/.config/fish/config.fish:
kubectl completion fish | source
Після перезавантаження оболонки автодоповнення kubectl має працювати.
Скрипт автодоповнення kubectl для Zsh можна згенерувати командою kubectl completion zsh. Підключення цього скрипта у вашій оболонці вмикає автодоповнення kubectl.
Щоб зробити це в усіх сеансах оболонки, додайте наведене нижче до файлу ~/.zshrc:
source <(kubectl completion zsh)
Якщо у вас є псевдонім для kubectl, автодоповнення kubectl автоматично працюватиме з ним.
Після перезавантаження оболонки автодоповнення kubectl має працювати.
Якщо ви отримуєте помилку на кшталт 2: command not found: compdef, додайте наведене нижче на початок файлу ~/.zshrc:
autoload -Uz compinit
compinit
Дивіться kuberc для отримання докладної інформації.
kubectl convertВтулок для інструмента командного рядка Kubernetes kubectl, який дозволяє конвертувати маніфести між різними версіями API. Це може бути особливо корисно для міграції маніфестів на незастарілу версію API в новіших випусках Kubernetes. Докладніше дивіться в розділі перехід на незастарілі API.
Завантажте останній випуск за допомогою наступної команди:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert"
Перевірте бінарний файл (необовʼязково)
Завантажте файл контрольної суми для kubectl-convert:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl-convert.sha256"
Перевірте бінарний файл kubectl-convert за допомогою файлу контрольної суми:
echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
Якщо перевірка пройшла успішно, вивід буде таким:
kubectl-convert: OK
Якщо перевірка не вдалася, sha256 виходить з ненульовим статусом і виводить подібне повідомлення:
kubectl-convert: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
Встановіть kubectl-convert
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
Перевірте, чи втулок успішно встановлено
kubectl convert --help
Якщо ви не бачите помилку, це означає, що втулок успішно встановлено.
Після встановлення втулка вилучіть файли встановлення:
rm kubectl-convert kubectl-convert.sha256
Вам потрібно використовувати версію kubectl, яка має мінорну версію, що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.37 може співпрацювати з панелями управління v1.36, v1.37 та v1.38. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.
Існують наступні методи встановлення kubectl у macOS:
Завантажте останній випуск:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
Щоб завантажити певну версію, замініть частину $(curl -L -s https://dl.k8s.io/release/stable.txt) команди на конкретну версію.
Наприклад, щоб завантажити версію 1.37.0 на Intel macOS, введіть:
curl -LO "https://dl.k8s.io/release/v1.37.0/bin/darwin/amd64/kubectl"
А для macOS на Apple Silicon, введіть:
curl -LO "https://dl.k8s.io/release/v1.37.0/bin/darwin/arm64/kubectl"
Перевірте бінарний файл (необовʼязково)
Завантажте файл контрольної суми для kubectl:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
Перевірте бінарний файл kubectl за допомогою файлу контрольної суми:
echo "$(cat kubectl.sha256) kubectl" | shasum -a 256 --check
Якщо перевірка пройшла успішно, вивід буде таким:
kubectl: OK
Якщо перевірка не вдалася, shasum виходить з ненульовим статусом і виводить подібне повідомлення:
kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match
Зробіть бінарний файл kubectl виконуваним.
chmod +x ./kubectl
Перемістіть бінарний файл kubectl до теки, що входить до PATH вашої системи.
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
/usr/local/bin є у вашій змінній середовища PATH.Перевірте, що встановлена версія kubectl актуальна:
kubectl version --client
Або використовуйте це для детального перегляду версії:
kubectl version --client --output=yaml
Після встановлення та перевірки kubectl видаліть файл контрольної суми:
rm kubectl.sha256
Якщо ви користуєтеся 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
Щоб 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
У Kubernetes 1.26 з kubectl вилучено вбудовану автентифікацію для керованих сервісів Kubernetes таких хмарних провайдерів. Ці провайдери випустили втулки kubectl, що забезпечують автентифікацію для їхніх хмар. Інструкції дивіться в документації провайдера:
Те саме повідомлення про помилку може мати й інші причини, не повʼязані з цією зміною.
kubectl надає підтримку автодоповнення для оболонок Bash, Zsh, Fish та PowerShell, що може значно зекономити ваш час при введенні команд.
Нижче подані процедури для налаштування автодоповнення для оболонок Bash, Fish та Zsh.
Скрипт автодоповнення kubectl для Bash можна згенерувати командою kubectl completion bash. Підключення цього скрипта у вашій оболонці вмикає автодоповнення kubectl.
Однак скрипт автодоповнення kubectl залежить від bash-completion, який потрібно встановити заздалегідь.
Ці інструкції передбачають, що ви використовуєте Bash 4.1+. Перевірити версію Bash можна, виконавши:
echo $BASH_VERSION
Якщо вона надто стара, ви можете встановити або оновити її за допомогою Homebrew:
brew install bash
Перезавантажте оболонку й перевірте, що використовується потрібна версія:
echo $BASH_VERSION $SHELL
Зазвичай Homebrew встановлює його в /usr/local/bin/bash.
Ви можете перевірити, чи вже встановлено bash-completion v2, за допомогою type _init_completion. Якщо ні, встановіть його за допомогою Homebrew:
brew install bash-completion@2
Як зазначено у виводі цієї команди, додайте наведене нижче до файлу ~/.bash_profile:
brew_etc="$(brew --prefix)/etc" && [[ -r "${brew_etc}/profile.d/bash_completion.sh" ]] && . "${brew_etc}/profile.d/bash_completion.sh"
Перезавантажте оболонку й перевірте, що bash-completion v2 правильно встановлено, за допомогою type _init_completion.
Тепер потрібно забезпечити підключення скрипта автодоповнення kubectl в усіх сеансах оболонки. Це можна зробити кількома способами:
Підключіть скрипт автодоповнення у файлі ~/.bash_profile:
echo 'source <(kubectl completion bash)' >>~/.bash_profile
Додайте скрипт автодоповнення до теки /usr/local/etc/bash_completion.d:
kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
Якщо у вас є псевдонім для kubectl, ви можете розширити автодоповнення оболонки, щоб воно працювало з цим псевдонімом:
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile
Якщо ви встановили kubectl за допомогою Homebrew (як пояснено тут), скрипт автодоповнення kubectl вже має бути в /usr/local/etc/bash_completion.d/kubectl. У цьому випадку нічого робити не потрібно.
BASH_COMPLETION_COMPAT_DIR, тому два останні способи працюють.У будь-якому разі після перезавантаження оболонки автодоповнення kubectl має працювати.
Скрипт автодоповнення kubectl для Fish можна згенерувати командою kubectl completion fish. Підключення цього скрипта у вашій оболонці вмикає автодоповнення kubectl.
Щоб зробити це в усіх сеансах оболонки, додайте такий рядок до файлу ~/.config/fish/config.fish:
kubectl completion fish | source
Після перезавантаження оболонки автодоповнення kubectl має працювати.
Скрипт автодоповнення kubectl для Zsh можна згенерувати командою kubectl completion zsh. Підключення цього скрипта у вашій оболонці вмикає автодоповнення kubectl.
Щоб зробити це в усіх сеансах оболонки, додайте наведене нижче до файлу ~/.zshrc:
source <(kubectl completion zsh)
Якщо у вас є псевдонім для kubectl, автодоповнення kubectl автоматично працюватиме з ним.
Після перезавантаження оболонки автодоповнення kubectl має працювати.
Якщо ви отримуєте помилку на кшталт 2: command not found: compdef, додайте наведене нижче на початок файлу ~/.zshrc:
autoload -Uz compinit
compinit
Дивіться kuberc для отримання докладної інформації.
kubectl convertВтулок для інструмента командного рядка Kubernetes kubectl, який дозволяє конвертувати маніфести між різними версіями API. Це може бути особливо корисно для міграції маніфестів на незастарілу версію API в новіших випусках Kubernetes. Докладніше дивіться в розділі перехід на незастарілі API.
Завантажте останній випуск за допомогою команди:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
Перевірте бінарний файл (необовʼязково)
Завантажте файл контрольної суми для kubectl-convert:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
Перевірте бінарний файл kubectl-convert за допомогою файлу контрольної суми:
echo "$(cat kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
Якщо перевірка пройшла успішно, вивід буде таким:
kubectl-convert: OK
Якщо перевірка не вдалася, shasum виходить з ненульовим статусом і виводить подібне повідомлення:
kubectl-convert: FAILED
shasum: WARNING: 1 computed checksum did NOT match
Зробіть бінарний файл kubectl-convert виконуваним.
chmod +x ./kubectl-convert
Перемістіть бінарний файл kubectl-convert до теки, що входить до PATH вашої системи.
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
/usr/local/bin є у вашій змінній середовища PATH.Перевірте, що втулок успішно встановлено
kubectl convert --help
Якщо ви не бачите жодних помилок, втулок було встановлено успішно.
Після встановлення втулка вилучіть файли встановлення:
rm kubectl-convert kubectl-convert.sha256
Залежно від того, як ви встановили kubectl, використовуйте один з наступних методів.
Знайдіть бінарний файл kubectl у вашій системі:
which kubectl
Видаліть бінарний файл kubectl:
sudo rm <path>
Замініть <path> на шлях до бінарного файлу kubectl з попереднього кроку. Наприклад, sudo rm /usr/local/bin/kubectl.
Якщо ви встановили kubectl за допомогою Homebrew, виконайте наступну команду:
brew remove kubectl
Вам потрібно використовувати версію kubectl, яка має мінорну версію, що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.37 може співпрацювати з панелями управління v1.36, v1.37 та v1.38. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.
Існують наступні методи встановлення kubectl у Windows:
У вас є два варіанти встановлення kubectl на вашому пристрої з Windows
Безпосереднє завантаження:
Завантажте останню версію 1.37 патчу безпосередньо для вашої архітектури, відвідавши сторінку випуску Kubernetes. Переконайтеся, що вибрано правильний двійковий файл для вашої архітектури (наприклад, amd64, arm64 тощо).
Використовуючи curl:
Якщо у вас встановлено curl, використайте цю команду:
curl.exe -LO "https://dl.k8s.io/release/v1.37.0/bin/windows/amd64/kubectl.exe"
Перевірте бінарний файл (необовʼязково)
Завантажте файл контрольної суми для kubectl:
curl.exe -LO "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubectl.exe.sha256"
Перевірте бінарний файл kubectl за допомогою файлу контрольної суми:
Використовуючи командний рядок для ручного порівняння виводу CertUtil з завантаженим файлом контрольної суми:
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
Використовуючи PowerShell для автоматизації перевірки за допомогою оператора -eq для отримання результату True або False:
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
Додайте на початок чи в кінець змінної середовища PATH шлях до теки з kubectl.
Перевірте, що версія kubectl збігається з завантаженою:
kubectl version --client
Або використайте це для детального перегляду версії:
kubectl version --client --output=yaml
kubectl до PATH. Якщо ви вже встановили Docker Desktop раніше, можливо, вам потрібно розмістити свій шлях в PATH перед тим, який додається інсталятором Docker Desktop, або видалити kubectl Docker Desktop.Для встановлення kubectl у Windows ви можете використовувати пакетний менеджер Chocolatey, командний інсталятор Scoop, або менеджер пакунків winget.
choco install kubernetes-cli
scoop install kubectl
winget install -e --id Kubernetes.kubectl
Перевірте, що встановлена версія актуальна:
kubectl version --client
Перейдіть до вашої домашньої теки:
# Якщо ви використовуєте cmd.exe, виконайте: cd %USERPROFILE%
cd ~
Створіть теку .kube:
mkdir .kube
Перейдіть до теки .kube, що ви щойно створили:
cd .kube
Налаштуйте kubectl для використання віддаленого кластера Kubernetes:
New-Item config -type file
Щоб 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
У Kubernetes 1.26 з kubectl вилучено вбудовану автентифікацію для керованих сервісів Kubernetes таких хмарних провайдерів. Ці провайдери випустили втулки kubectl, що забезпечують автентифікацію для їхніх хмар. Інструкції дивіться в документації провайдера:
Те саме повідомлення про помилку може мати й інші причини, не повʼязані з цією зміною.
kubectl надає підтримку автодоповнення для оболонок Bash, Zsh, Fish та PowerShell, що може значно зекономити ваш час при введенні команд.
Нижче подані процедури для налаштування автодоповнення для PowerShell.
Скрипт автодоповнення kubectl для PowerShell можна згенерувати командою kubectl completion powershell.
Щоб зробити це в усіх сеансах оболонки, додайте такий рядок до файлу $PROFILE:
kubectl completion powershell | Out-String | Invoke-Expression
Ця команда генеруватиме скрипт автодоповнення під час кожного запуску PowerShell. Ви також можете додати згенерований скрипт безпосередньо до файлу $PROFILE.
Щоб додати згенерований скрипт до файлу $PROFILE, виконайте такий рядок у командному рядку PowerShell:
kubectl completion powershell >> $PROFILE
Після перезавантаження оболонки автодоповнення kubectl має працювати.
Дивіться kuberc для отримання докладної інформації.
kubectl convertВтулок для інструмента командного рядка Kubernetes kubectl, який дозволяє конвертувати маніфести між різними версіями API. Це може бути особливо корисно для міграції маніфестів на незастарілу версію API в новіших випусках Kubernetes. Докладніше дивіться в розділі перехід на незастарілі API.
Завантажте останній випуск за допомогою команди:
curl.exe -LO "https://dl.k8s.io/release/v1.37.0/bin/windows/amd64/kubectl-convert.exe"
Перевірте бінарний файл (необовʼязково).
Завантажте файл контрольної суми для kubectl-convert:
curl.exe -LO "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubectl-convert.exe.sha256"
Перевірте бінарний файл kubectl-convert за допомогою файлу контрольної суми:
Використовуючи командний рядок для ручного порівняння виводу CertUtil з завантаженим файлом контрольної суми:
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
Використовуючи PowerShell для автоматизації перевірки за допомогою оператора -eq для отримання результату True або False:
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
Додайте на початок чи в кінець змінної середовища PATH шлях до теки з kubectl-convert.
Перевірте, що втулок успішно встановлено.
kubectl convert --help
Якщо ви не бачите помилки, це означає, що втулок успішно встановлено.
Після встановлення втулка вилучіть файли встановлення:
del kubectl-convert.exe
del kubectl-convert.exe.sha256
Цей посібник допоможе користувачам налагодити застосунки, які розгорнуті в Kubernetes і поводяться некоректно. Це не посібник для тих, хто хоче налагодити свій кластер. Для цього ознайомтеся з цим посібником.
Перший крок в усуненні несправностей — первинна оцінка. У чому проблема? У ваших Podʼах, ReplicationController чи Service?
Перший крок у налагодженні Podʼа — переглянути його. Перевірте поточний стан Podʼа й останні події такою командою:
kubectl describe pods ${POD_NAME}
Перегляньте стан контейнерів у Podʼі. Чи всі вони в стані Running? Чи були нещодавні перезапуски?
Продовжуйте налагодження залежно від стану Podʼів.
Якщо Pod застряг у стані Pending, це означає, що його не можна призначити на вузол. Зазвичай це стається через нестачу ресурсів того чи іншого типу, яка заважає плануванню. Перегляньте вивід команди kubectl describe ... вище. Там мають бути повідомлення від планувальника про те, чому він не може запланувати ваш Pod. Можливі причини:
У вас недостатньо ресурсів: можливо, ви вичерпали запас CPU або памʼяті в кластері; у такому разі потрібно видалити Podʼи, скоригувати запити ресурсів або додати нові вузли до кластера. Докладніше дивіться документ про обчислювальні ресурси.
Ви використовуєте hostPort: коли ви привʼязуєте Pod до hostPort, кількість місць, де можна запланувати цей Pod, обмежена. У більшості випадків hostPort не потрібен, спробуйте використати обʼєкт Service, щоб відкрити доступ до вашого Podʼа. Якщо hostPort вам усе ж потрібен, ви зможете запланувати лише стільки Podʼів, скільки вузлів у вашому кластері Kubernetes.
Якщо Pod застряг у стані Waiting, його вже призначено на робочий вузол, але він не може працювати на цій машині. Знову ж таки, корисну інформацію має дати вивід kubectl describe .... Найпоширеніша причина Podʼів у стані Waiting — помилка завантаження образу. Перевірте три речі:
docker pull <image>.Якщо Pod застряг у стані Terminating, це означає, що для Podʼа надіслано запит на видалення, але панель управління не може видалити обʼєкт Pod.
Зазвичай таке стається, якщо Pod має завершувач, а в кластері встановлено вебхук допуску, який не дає панелі управління вилучити завершувач.
Щоб виявити такий сценарій, перевірте, чи є у вашому кластері ValidatingWebhookConfiguration або MutatingWebhookConfiguration, спрямовані на операції UPDATE для ресурсів pods.
Якщо вебхук надає третя сторона:
UPDATE.Якщо ви автор вебхука:
UPDATE. Наприклад, зміни контейнерів зазвичай не дозволені.Щойно ваш Pod заплановано, для налагодження можна використовувати методи, описані в Налагодження запущених Podʼів.
Якщо ваш Pod поводиться не так, як ви очікували, можливо, в описі Podʼа (наприклад, у файлі mypod.yaml на вашому локальному компʼютері) була помилка, яку мовчки проігнорували під час створення Podʼа. Часто якийсь розділ опису Podʼа вкладено неправильно або імʼя ключа написано з помилкою, тож ключ ігнорується. Наприклад, якщо ви написали command як commnd, Pod буде створено, але він не використовуватиме командний рядок, який ви задумали.
Насамперед видаліть свій Pod і спробуйте створити його знову з параметром --validate. Наприклад, виконайте kubectl apply --validate -f mypod.yaml. Якщо ви написали command як commnd, ви отримаєте помилку на кшталт такої:
I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
pods/mypod
Далі перевірте, чи збігається Pod на API-сервері з Podʼом, який ви хотіли створити (наприклад, з YAML-файлом на вашому локальному компʼютері). Наприклад, виконайте kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml, а потім вручну порівняйте початковий опис Podʼа, mypod.yaml, з тим, що ви отримали від API-сервера, mypod-on-apiserver.yaml. Зазвичай у версії з API-сервера будуть рядки, яких немає в початковій версії. Це очікувано. Однак якщо в початковому описі є рядки, яких немає у версії з API-сервера, це може свідчити про проблему зі специфікацією вашого Podʼа.
ReplicationController досить прості. Вони або можуть створювати Podʼи, або не можуть. Якщо вони не можуть створювати Podʼи, скористайтеся інструкціями вище, щоб налагодити свої Podʼи.
Також можна використати kubectl describe rc ${CONTROLLER_NAME}, щоб переглянути події, повʼязані з ReplicationController.
Service забезпечують балансування навантаження між набором Podʼів. Є кілька поширених проблем, через які Service можуть працювати неправильно. Наведені нижче інструкції допоможуть налагодити проблеми з Service.
Спершу переконайтеся, що для Service є точки доступу. Для кожного обʼєкта Service API-сервер робить доступними один або кілька ресурсів EndpointSlice.
Переглянути ці ресурси можна так:
kubectl get endpointslices -l kubernetes.io/service-name=${SERVICE_NAME}
Переконайтеся, що точки доступу в EndpointSlice відповідають кількості Podʼів, які мають входити до вашого Service. Наприклад, якщо ваш Service призначено для контейнера nginx з 3 репліками, ви маєте побачити три різні IP-адреси в EndpointSlice цього Service.
Якщо точок доступу бракує, спробуйте вивести перелік Podʼів за мітками із селектора Service. Наприклад, у вас є Service з таким селектором:
...
spec:
selector:
name: nginx
type: frontend
Можна використати:
kubectl get pods --selector=name=nginx,type=frontend
щоб вивести перелік Podʼів, які відповідають цьому селектору. Перевірте, чи список збігається з Podʼами, які мають обслуговувати ваш Service. Перевірте, чи containerPort Podʼа збігається з targetPort Service.
Докладніше дивіться налагодження Service.
Якщо жоден із наведених вище кроків не розвʼязав вашої проблеми, виконайте інструкції з документа про налагодження Service, щоб переконатися, що ваш Service працює, має Endpoints, а ваші Podʼи справді обслуговують запити; що DNS працює, правила iptables встановлено, а kube-proxy поводиться правильно.
Докладніше також дивіться документ про усунення несправностей.
Для Kubernetes Metrics API пропонує базовий набір метрик для підтримки автоматичного масштабування та подібних випадків використання. Це API робить доступною інформацію про використання ресурсів вузлами й Podʼами, зокрема метрики CPU та памʼяті. Якщо ви розгорнете Metrics API у своєму кластері, клієнти API Kubernetes зможуть запитувати цю інформацію, а ви зможете використовувати механізми контролю доступу Kubernetes для керування дозволами на це.
HorizontalPodAutoscaler (HPA) і VerticalPodAutoscaler (VPA) використовують дані з Metrics API, щоб коригувати кількість реплік і ресурси робочих навантажень відповідно до попиту користувачів.
Ви також можете переглядати метрики ресурсів, використовуючи команду kubectl top.
Схема 1 ілюструє архітектуру конвеєра метрик ресурсів.
flowchart RL
subgraph cluster[Кластер]
direction RL
S[
]
A[Сервер-
метрик]
subgraph B[Вузли]
direction TB
D[cAdvisor] --> C[kubelet]
E[Середовище
виконання
контейнерів] --> D
E1[Середовище
виконання
контейнерів] --> D
P[Дані Podʼа] -.- C
end
L[API-сервер]
W[HPA]
C ---->|метрики ресурсів
на рівні вузла| A -->|Metrics
API| L --> W
end
L ---> K[kubectl
top]
classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000;
class W,B,P,K,cluster,D,E,E1 box
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class S spacewhite
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
class A,L,C k8s
Схема 1. Конвеєр метрик ресурсів
Компоненти архітектури, справа наліво на схемі, такі:
cAdvisor: демон, вбудований у kubelet, для збирання, агрегування та надання метрик контейнерів.
kubelet: агент вузла для керування ресурсами контейнерів. Метрики ресурсів доступні через точки доступу API kubelet /metrics/resource і /stats.
метрики ресурсів на рівні вузла: API, який надає kubelet для виявлення й отримання підсумкової статистики по вузлу, доступної через точку доступу /metrics/resource.
metrics-server: компонент-надбудова кластера, який збирає й агрегує метрики ресурсів, отримані від кожного kubelet. API-сервер обслуговує Metrics API для HPA, VPA і команди kubectl top. Metrics Server — це еталонна реалізація Metrics API.
Metrics API: API Kubernetes, що надає доступ до даних про CPU та памʼять, які використовуються для автомасштабування робочих навантажень. Щоб це працювало у вашому кластері, потрібен API-сервер розширення, який надає Metrics API.
Metrics-server реалізує Metrics API. Це API дає змогу отримати дані про використання CPU та памʼяті вузлами й Podʼами вашого кластера. Його основна роль — передавати метрики використання ресурсів компонентам автомасштабування K8s.
Ось приклад запиту до Metrics API для вузла minikube, обробленого через jq для зручного перегляду:
kubectl get --raw "/apis/metrics.k8s.io/v1/nodes/minikube" | jq '.'
Той самий виклик API за допомогою curl:
curl http://localhost:8080/apis/metrics.k8s.io/v1/nodes/minikube
Приклад відповіді:
{
"kind": "NodeMetrics",
"apiVersion": "metrics.k8s.io/v1",
"metadata": {
"name": "minikube",
"selfLink": "/apis/metrics.k8s.io/v1/nodes/minikube",
"creationTimestamp": "2022-01-27T18:48:43Z"
},
"timestamp": "2022-01-27T18:48:33Z",
"window": "30s",
"usage": {
"cpu": "487558164n",
"memory": "732212Ki"
}
}
Ось приклад запиту до Metrics API для Podʼа kube-scheduler-minikube у просторі імен kube-system, обробленого через jq для зручного перегляду:
kubectl get --raw "/apis/metrics.k8s.io/v1/namespaces/kube-system/pods/kube-scheduler-minikube" | jq '.'
Той самий виклик API за допомогою curl:
curl http://localhost:8080/apis/metrics.k8s.io/v1/namespaces/kube-system/pods/kube-scheduler-minikube
Приклад відповіді:
{
"kind": "PodMetrics",
"apiVersion": "metrics.k8s.io/v1",
"metadata": {
"name": "kube-scheduler-minikube",
"namespace": "kube-system",
"selfLink": "/apis/metrics.k8s.io/v1/namespaces/kube-system/pods/kube-scheduler-minikube",
"creationTimestamp": "2022-01-27T19:25:00Z"
},
"timestamp": "2022-01-27T19:24:31Z",
"window": "30s",
"containers": [
{
"name": "kube-scheduler",
"usage": {
"cpu": "9559630n",
"memory": "22244Ki"
}
}
]
}
Metrics API визначено в репозиторії k8s.io/metrics. Вам потрібно увімкнути шар агрегації API та зареєструвати APIService для API metrics.k8s.io.
Щоб дізнатися більше про Metrics API, дивіться дизайн API метрик ресурсів, репозиторій metrics-server і API метрик ресурсів.
CPU відображається як середнє використання ядер, виміряне в одиницях CPU. Один CPU у Kubernetes еквівалентний 1 vCPU/ядру в хмарних провайдерів і 1 гіперпотоку на процесорах Intel на bare-metal.
Це значення отримують, обчислюючи швидкість зміни накопичувального лічильника CPU, який надає ядро (і в Linux, і в Windows). Часове вікно, використане для обчислення CPU, показано в полі window у Metrics API.
Щоб дізнатися більше про те, як Kubernetes розподіляє та вимірює ресурси CPU, дивіться значення CPU.
Памʼять відображається як робочий набір, виміряний у байтах, у момент збору метрики.
В ідеальному світі "робочий набір" — це обсяг памʼяті, що використовується й не може бути звільнений за умов тиску на памʼять. Однак обчислення робочого набору залежить від ОС хоста й, як правило, значною мірою покладається на евристики для отримання оцінки.
Модель Kubernetes для робочого набору контейнера очікує, що середовище виконання контейнерів враховує анонімну памʼять, повʼязану з відповідним контейнером. Метрика робочого набору зазвичай також включає деяку кешовану памʼять (file-backed), оскільки ОС хоста не завжди може звільнити сторінки.
Щоб дізнатися більше про те, як Kubernetes розподіляє та вимірює ресурси памʼяті, дивіться значення памʼяті.
Metrics-server отримує метрики ресурсів від kubelet і надає їх через Metrics API на API-сервері Kubernetes для використання HPA та VPA. Ці метрики також можна переглядати командою kubectl top.
Metrics-server використовує API Kubernetes для відстеження вузлів і Podʼів у вашому кластері. Metrics-server запитує кожен вузол через HTTP, щоб отримати метрики. Metrics-server також будує внутрішнє подання метаданих Podʼів і зберігає кеш стану справності Podʼів. Ця кешована інформація про стан справності Podʼів доступна через API розширення, яке надає metrics-server.
Наприклад, для запиту HPA metrics-server має визначити, які Podʼи відповідають селекторам міток у Deployment.
Metrics-server викликає API kubelet для збору метрик з кожного вузла. Залежно від версії metrics-server використовується:
/metrics/resource у версії v0.6.0+ або/stats/summary у старіших версіяхЩоб дізнатися більше про metrics-server, перегляньте репозиторій metrics-server.
Також можна переглянути таке:
Щоб дізнатися про те, як kubelet надає метрики вузла, і як ви можете отримати до них доступ через API Kubernetes, прочитайте Дані метрик вузлів.
Ця сторінка пояснює, як оновити робочі вузли Linux, створені за допомогою kubeadm.
Вам потрібен доступ до оболонки на всіх вузлах, а інструмент командного рядка kubectl має бути налаштований для звʼязку з вашим кластером. Рекомендується виконувати цей підручник у кластері, що має принаймні два вузли, які не є вузлами панелі управління.
Для перевірки версії введіть kubectl version.
Якщо ви використовуєте репозиторії пакунків, що належать спільноті (pkgs.k8s.io), вам потрібно увімкнути репозиторій пакунків для потрібного мінорного релізу Kubernetes. Це пояснено в документі Зміна репозиторію пакунків Kubernetes.
apt.kubernetes.io та yum.kubernetes.io) визнані
застарілими та заморожені станом на 13 вересня 2023.
Наполегливо рекомендується використання нових репозиторіїв пакунків, розміщених за адресою pkgs.k8s.io,
які є обовʼязковими для встановлення версій Kubernetes, випущених після 13 вересня 2023 року.
Застарілі репозиторії та їх вміст можуть бути видалені у будь-який момент у майбутньому без попереднього повідомлення.
Нові репозиторії пакунків надають можливість завантаження версій Kubernetes, починаючи з v1.24.0.
Оновіть kubeadm та kubectl:
# замініть x у 1.37.x-* на останню версію патча
sudo apt-mark unhold kubeadm kubectl && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.37.x-*' kubectl='1.37.x-*' && \
sudo apt-mark hold kubeadm kubectl
Для систем з DNF4 (Fedora < 41, RHEL/CentOS < 10):
# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubeadm-'1.37.x-*' kubectl-'1.37.x-*' --disableexcludes=kubernetes
Для систем з DNF5:
# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubeadm-'1.37.x-*' kubectl-'1.37.x-*' --setopt=disable_excludes=kubernetes
Для робочих вузлів це оновлює локальну конфігурацію kubelet:
sudo kubeadm upgrade node
Підготуйте вузол до обслуговування, позначивши його як недоступний для планування та виселивши робочі навантаження:
# виконайте цю команду на вузлі панелі управління
# замініть <node-to-drain> імʼям вузла, для якого ви виконуєте drain
kubectl drain <node-to-drain> --ignore-daemonsets
Оновіть kubelet:
# замініть x у 1.37.x-* на останню версію патча
sudo apt-mark unhold kubelet && \
sudo apt-get update && sudo apt-get install -y kubelet='1.37.x-*' && \
sudo apt-mark hold kubelet
Для систем з DNF4 (Fedora < 41, RHEL/CentOS < 10):
# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubelet-'1.37.x-*' --disableexcludes=kubernetes
Для систем з DNF5:
# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubelet-'1.37.x-*' --setopt=disable_excludes=kubernetes
Перезапустіть kubelet:
sudo systemctl daemon-reload
sudo systemctl restart kubelet
Поверніть вузол в роботу, позначивши його як придатний для планування:
# виконайте цю команду на вузлі панелі управління
# замініть <node-to-uncordon> імʼям вашого вузла
kubectl uncordon <node-to-uncordon>
Ця сторінка пояснює, як оновити вузол Windows, створений за допомогою kubeadm.
Вам потрібен доступ до оболонки на всіх вузлах, а інструмент командного рядка kubectl має бути налаштований для звʼязку з вашим кластером. Рекомендується виконувати цей підручник у кластері, що має принаймні два вузли, які не є вузлами панелі управління.
Версія вашого Kubernetes сервера має бути не старішою ніж 1.17.Для перевірки версії введіть kubectl version.
З вузла Windows оновіть kubeadm:
# замініть 1.37.0 на вашу бажану версію
curl.exe -Lo <path-to-kubeadm.exe> "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubeadm.exe"
З машини з доступом до API Kubernetes підготуйте вузол до обслуговування, позначивши його як недоступний для планування та виселивши робочі навантаження:
# замініть <node-to-drain> імʼям вашого вузла, для якого ви виконуєте drain
kubectl drain <node-to-drain> --ignore-daemonsets
Ви повинні побачити подібний вивід:
node/ip-172-31-85-18 cordoned
node/ip-172-31-85-18 drained
З вузла Windows виконайте таку команду, щоб синхронізувати нову конфігурацію kubelet:
kubeadm upgrade node
З вузла Windows оновіть та перезапустіть kubelet:
stop-service kubelet
curl.exe -Lo <path-to-kubelet.exe> "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubelet.exe"
restart-service kubelet
З вузла Windows оновіть та перезапустіть kube-proxy.
stop-service kube-proxy
curl.exe -Lo <path-to-kube-proxy.exe> "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kube-proxy.exe"
restart-service kube-proxy
З машини з доступом до API Kubernetes поверніть вузол в роботу, позначивши його як придатний для планування:
# замініть <node-to-drain> імʼям вашого вузла
kubectl uncordon <node-to-drain>
Ця сторінка показує адміністраторам кластера, як посилити авторизацію для динамічного виділення ресурсів (DRA) з акцентом на доступ з мінімальними привілеями для оновлень статусу ResourceClaim.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для перевірки версії введіть kubectl version.
Задокументуйте, які ідентичності (зазвичай ServiceAccount) оновлюють статус ResourceClaim у вашому кластері. Типові компоненти, що записують статус:
Починаючи з Kubernetes v1.36, оновлення статусу DRA вимагають дозволів на синтетичні субресурси на додаток до resourceclaims/status.
Застосуйте роль, яка дозволяє оновлення, повʼязані з привʼязкою:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: dra-binding-updater
rules:
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims/status"]
verbs: ["get", "patch", "update"]
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims/binding"]
verbs: ["patch", "update"]
Використовуйте вузлово-орієнтовані дієслова для драйверів, локальних для вузла:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: dra-node-driver-status-updater
rules:
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims/status"]
verbs: ["get", "patch", "update"]
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims/driver"]
verbs: ["associated-node:patch", "associated-node:update"]
resourceNames: ["dra.example.com"]
Використовуйте arbitrary-node:* лише для компонентів, які повинні оновлювати статус з будь-якого вузла:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: dra-multinode-status-updater
rules:
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims/status"]
verbs: ["get", "patch", "update"]
- apiGroups: ["resource.k8s.io"]
resources: ["resourceclaims/driver"]
verbs: ["arbitrary-node:patch", "arbitrary-node:update"]
resourceNames: ["dra.example.com"]
Створіть обʼєкти ClusterRoleBinding для кожної ідентичності компонента та уникайте спільного використання широкої ролі між не повʼязаними між собою компонентами DRA.
Обмежте правила resourceclaims/driver за допомогою resourceNames, де це можливо, щоб ідентичність могла оновлювати статус лише для конкретного драйвера DRA, яким вона керує.
resourceclaims/binding та resourceclaims/driver.На цій сторінці показано, як запустити одноекземплярний застосунок зі збереженням стану в Kubernetes, використовуючи PersistentVolume та Deployment. Застосунок — MySQL.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для перевірки версії введіть kubectl version.
Вам потрібно мати або динамічний provisioner PersistentVolume з типовим StorageClass, або самостійно статично надати PersistentVolumes, щоб задовольнити PersistentVolumeClaims, які використовуються тут.
Ви можете запустити застосунок зі збереженням стану, створивши Deployment Kubernetes і підʼєднавши його до наявного PersistentVolume за допомогою PersistentVolumeClaim. Наприклад, цей файл YAML описує Deployment, який запускає MySQL і посилається на PersistentVolumeClaim. Файл визначає монтування тому для /var/lib/mysql, а потім створює PersistentVolumeClaim, що шукає том на 20G. Цю заявку задовольняє будь-який наявний том, що відповідає вимогам, або динамічний provisioner.
Примітка: пароль визначено у файлі конфігурації yaml, і це небезпечно. Безпечне рішення дивіться в розділі Kubernetes Secrets.
apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- port: 3306
selector:
app: mysql
clusterIP: None
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:9
name: mysql
env:
# Use secret in real usage
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Розгорніть PV та PVC з файлу YAML:
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
Розгорніть вміст файлу YAML:
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
Виведіть інформацію про Deployment:
kubectl describe deployment mysql
Вивід подібний до такого:
Name: mysql
Namespace: default
CreationTimestamp: Tue, 01 Nov 2016 11:18:45 -0700
Labels: app=mysql
Annotations: deployment.kubernetes.io/revision=1
Selector: app=mysql
Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType: Recreate
MinReadySeconds: 0
Pod Template:
Labels: app=mysql
Containers:
mysql:
Image: mysql:9
Port: 3306/TCP
Environment:
MYSQL_ROOT_PASSWORD: password
Mounts:
/var/lib/mysql from mysql-persistent-storage (rw)
Volumes:
mysql-persistent-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: mysql-pv-claim
ReadOnly: false
Conditions:
Type Status Reason
---- ------ ------
Available False MinimumReplicasUnavailable
Progressing True ReplicaSetUpdated
OldReplicaSets: <none>
NewReplicaSet: mysql-63082529 (1/1 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
Перегляньте Podʼи, створені Deployment:
kubectl get pods -l app=mysql
Вивід подібний до такого:
NAME READY STATUS RESTARTS AGE
mysql-63082529-2z3ki 1/1 Running 0 3m
Перевірте PersistentVolumeClaim:
kubectl describe pvc mysql-pv-claim
Вивід подібний до такого:
Name: mysql-pv-claim
Namespace: default
StorageClass:
Status: Bound
Volume: mysql-pv-volume
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed=yes
pv.kubernetes.io/bound-by-controller=yes
Capacity: 20Gi
Access Modes: RWO
Events: <none>
Наведений вище файл YAML створює сервіс, який дає іншим Podʼам у кластері змогу отримувати доступ до бази даних. Параметр Service clusterIP: None дозволяє DNS-імені Service розвʼязуватися безпосередньо в IP-адресу Podʼа. Це оптимально, коли за Service стоїть лише один Pod і ви не маєте наміру збільшувати кількість Podʼів.
Запустіть клієнта MySQL, щоб підʼєднатися до сервера:
kubectl run -it --rm --image=mysql:9 --restart=Never mysql-client -- mysql -h mysql -ppassword
Ця команда створює в кластері новий Pod, у якому працює клієнт MySQL, і підʼєднує його до сервера через Service. Якщо зʼєднання встановлено, значить, ваша база даних MySQL зі збереженням стану запущена й працює.
Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
mysql>
Образ або будь-яку іншу частину Deployment можна оновити як зазвичай за допомогою команди kubectl apply. Ось деякі запобіжні заходи, специфічні для застосунків зі збереженням стану:
strategy: type: Recreate у файлі конфігурації YAML для Deployment. Це вказує Kubernetes не використовувати поетапні оновлення. Поетапні оновлення не працюватимуть, оскільки одночасно не може працювати більше одного Podʼа. Стратегія Recreate зупинить перший Pod перед створенням нового з оновленою конфігурацією.Видаліть розгорнуті обʼєкти за назвою:
kubectl delete deployment,svc mysql
kubectl delete pvc mysql-pv-claim
kubectl delete pv mysql-pv-volume
Якщо ви надали PersistentVolume вручну, вам також потрібно вручну видалити його й звільнити базовий ресурс. Якщо ви використовували динамічний provisioner, він автоматично видаляє PersistentVolume, коли бачить, що ви видалили PersistentVolumeClaim. Деякі динамічні provisioners (наприклад, для EBS і PD) також звільняють базовий ресурс під час видалення PersistentVolume.
Дізнайтеся більше про обʼєкти Deployment.
Дізнайтеся більше про розгортання застосунків
Ця сторінка показує, як запустити реплікований застосунок зі збереженням стану (StatefulSet). Цей застосунок — реплікована база даних MySQL. У топології цього прикладу є один головний сервер і кілька реплік, що використовують асинхронну реплікацію на основі рядків.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Вам потрібно мати або динамічний provisioner PersistentVolume з типовим StorageClass, або самостійно статично надати PersistentVolumes, щоб задовольнити PersistentVolumeClaims, які використовуються тут.
Приклад розгортання складається з ConfigMap, двох Service та StatefulSet.
Створіть ConfigMap із наступного файлу конфігурації YAML:
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql
labels:
app: mysql
app.kubernetes.io/name: mysql
data:
primary.cnf: |
# Apply this config only on the primary.
[mysqld]
log-bin
replica.cnf: |
# Apply this config only on replicas.
[mysqld]
super-read-only
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
Цей ConfigMap надає перевизначення для my.cnf, що дозволяє вам незалежно керувати конфігурацією на головному сервері MySQL та його репліках. У цьому випадку ви хочете, щоб головний сервер міг надавати логи реплікації реплікам, а репліки відхиляли будь-які записи, які надходять не через реплікацію.
Немає нічого особливого у самому ConfigMap, що зумовлює застосування різних частин до різних Podʼів. Кожен Pod вирішує, яку частину дивитися при ініціалізації, на основі інформації, що надає контролер StatefulSet.
Створіть Service із наступного файлу конфігурації YAML:
# Headless service for stable DNS entries of StatefulSet members.
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
app: mysql
app.kubernetes.io/name: mysql
spec:
ports:
- name: mysql
port: 3306
clusterIP: None
selector:
app: mysql
---
# Client service for connecting to any MySQL instance for reads.
# For writes, you must instead connect to the primary: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:
name: mysql-read
labels:
app: mysql
app.kubernetes.io/name: mysql
readonly: "true"
spec:
ports:
- name: mysql
port: 3306
selector:
app: mysql
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml
Headless Service надає місце для DNS-записів, які контролери StatefulSet створюють для кожного Podʼа, що є частиною набору. Оскільки headless Service називається mysql, Podʼи доступні через розвʼязання імені <pod-name>.mysql з будь-якого іншого Podʼа в тому самому кластері Kubernetes і просторі імен.
Клієнтський Service, з назвою mysql-read, є звичайним Service з власним кластерним IP, який розподіляє підключення між всіма Podʼами MySQL, які повідомляють про готовність. Набір потенційних точок доступу включає головний сервер MySQL та всі репліки.
Зверніть увагу, що лише запити на читання можуть використовувати клієнтський Service з балансуванням навантаження. Оскільки існує лише один головний сервер MySQL, клієнти повинні підключатися безпосередньо до головного Podʼа MySQL (через його DNS-запис у headless Service) для виконання записів.
Наостанок, створіть StatefulSet із наступного файлу конфігурації YAML:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
app.kubernetes.io/name: mysql
serviceName: mysql
replicas: 3
template:
metadata:
labels:
app: mysql
app.kubernetes.io/name: mysql
spec:
initContainers:
- name: init-mysql
image: mysql:5.7
command:
- bash
- "-c"
- |
set -ex
# Generate mysql server-id from pod ordinal index.
[[ $HOSTNAME =~ -([0-9]+)$ ]] || exit 1
ordinal=${BASH_REMATCH[1]}
echo [mysqld] > /mnt/conf.d/server-id.cnf
# Add an offset to avoid reserved server-id=0 value.
echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
# Copy appropriate conf.d files from config-map to emptyDir.
if [[ $ordinal -eq 0 ]]; then
cp /mnt/config-map/primary.cnf /mnt/conf.d/
else
cp /mnt/config-map/replica.cnf /mnt/conf.d/
fi
volumeMounts:
- name: conf
mountPath: /mnt/conf.d
- name: config-map
mountPath: /mnt/config-map
- name: clone-mysql
image: gcr.io/google-samples/xtrabackup:1.0
command:
- bash
- "-c"
- |
set -ex
# Skip the clone if data already exists.
[[ -d /var/lib/mysql/mysql ]] && exit 0
# Skip the clone on primary (ordinal index 0).
[[ `hostname` =~ -([0-9]+)$ ]] || exit 1
ordinal=${BASH_REMATCH[1]}
[[ $ordinal -eq 0 ]] && exit 0
# Clone data from previous peer.
ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
# Prepare the backup.
xtrabackup --prepare --target-dir=/var/lib/mysql
volumeMounts:
- name: data
mountPath: /var/lib/mysql
subPath: mysql
- name: conf
mountPath: /etc/mysql/conf.d
containers:
- name: mysql
image: mysql:5.7
env:
- name: MYSQL_ALLOW_EMPTY_PASSWORD
value: "1"
ports:
- name: mysql
containerPort: 3306
volumeMounts:
- name: data
mountPath: /var/lib/mysql
subPath: mysql
- name: conf
mountPath: /etc/mysql/conf.d
resources:
requests:
cpu: 500m
memory: 1Gi
livenessProbe:
exec:
command: ["mysqladmin", "ping"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
readinessProbe:
exec:
# Перевірити, що ми можемо виконувати запити через TCP (skip-networking вимкнено).
command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
initialDelaySeconds: 5
periodSeconds: 2
timeoutSeconds: 1
- name: xtrabackup
image: gcr.io/google-samples/xtrabackup:1.0
ports:
- name: xtrabackup
containerPort: 3307
command:
- bash
- "-c"
- |
set -ex
cd /var/lib/mysql
# Determine binlog position of cloned data, if any.
if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
# XtraBackup already generated a partial "CHANGE MASTER TO" query
# because we're cloning from an existing replica. (Need to remove the tailing semicolon!)
cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
# Ignore xtrabackup_binlog_info in this case (it's useless).
rm -f xtrabackup_slave_info xtrabackup_binlog_info
elif [[ -f xtrabackup_binlog_info ]]; then
# We're cloning directly from primary. Parse binlog position.
[[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
rm -f xtrabackup_binlog_info xtrabackup_slave_info
echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
fi
# Check if we need to complete a clone by starting replication.
if [[ -f change_master_to.sql.in ]]; then
echo "Waiting for mysqld to be ready (accepting connections)"
until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
echo "Initializing replication from clone position"
mysql -h 127.0.0.1 \
-e "$(<change_master_to.sql.in), \
MASTER_HOST='mysql-0.mysql', \
MASTER_USER='root', \
MASTER_PASSWORD='', \
MASTER_CONNECT_RETRY=10; \
START SLAVE;" || exit 1
# In case of container restart, attempt this at-most-once.
mv change_master_to.sql.in change_master_to.sql.orig
fi
# Start a server to send backups when requested by peers.
exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
"xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
volumeMounts:
- name: data
mountPath: /var/lib/mysql
subPath: mysql
- name: conf
mountPath: /etc/mysql/conf.d
resources:
requests:
cpu: 100m
memory: 100Mi
volumes:
- name: conf
emptyDir: {}
- name: config-map
configMap:
name: mysql
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10Gi
kubectl apply -f https://k8s.io/examples/application/mysql/mysql-statefulset.yaml
Ви можете спостерігати за процесом запуску, виконавши:
kubectl get pods -l app=mysql --watch
Через деякий час ви повинні побачити, що всі 3 Podʼи стануть Running:
NAME READY STATUS RESTARTS AGE
mysql-0 2/2 Running 0 2m
mysql-1 2/2 Running 0 1m
mysql-2 2/2 Running 0 1m
Натисніть Ctrl+C, щоб скасувати перегляд.
Цей маніфест використовує різноманітні техніки для керування Podʼами зі збереженням стану в межах StatefulSet. У наступному розділі підкреслено деякі з цих технік, щоб пояснити, що відбувається під час створення Podʼів StatefulSet.
Контролер StatefulSet запускає Podʼи по одному, в порядку їх індексів. Він чекає, доки кожен Pod не повідомить про готовність, перш ніж запустити наступний.
Крім того, контролер призначає кожному Podʼу унікальне, стабільне імʼя у формі <statefulset-name>-<ordinal-index>, в результаті отримуємо Podʼи з іменами mysql-0, mysql-1 та mysql-2.
Шаблон Podʼа у вищенаведеному маніфесті StatefulSet використовує ці властивості, щоб здійснити впорядкований запуск реплікації MySQL.
Перед запуском будь-яких контейнерів у специфікації Podʼа, спочатку Pod запускає будь-які контейнери ініціалізації у визначеному порядку.
Перший контейнер ініціалізації, init-mysql, генерує спеціальні конфігураційні файли MySQL на основі порядкового індексу.
Скрипт визначає свій власний порядковий індекс, витягуючи його з кінця імені Podʼа, яке повертається командою hostname. Потім він зберігає порядковий індекс (з числовим зміщенням для уникнення зарезервованих значень) у файлі з назвою server-id.cnf в теці conf.d MySQL. Це перетворює унікальний, стабільний ідентифікатор, наданий StatefulSet, у домен ідентифікаторів серверів MySQL, які вимагають таких же властивостей.
Скрипт у контейнері init-mysql також застосовує або primary.cnf, або replica.cnf з ConfigMap, копіюючи вміст у conf.d. Оскільки у топології цього прикладу є лише один головний сервер MySQL та будь-яка кількість реплік, скрипт призначає порядковий індекс 0 головному серверу, а всі інші — репліками. Разом з гарантією контролера StatefulSet щодо порядку розгортання, це забезпечує готовність головного сервера MySQL перед створенням реплік, щоб вони могли почати реплікацію.
Загалом, коли новий Pod приєднується до набору як репліка, він повинен припускати, що головний сервер MySQL може вже містити дані. Також він повинен припускати, що логи реплікації можуть не сягати самого початку. Ці консервативні припущення є ключем до того, щоб запущений StatefulSet міг масштабуватися вгору та вниз з часом, а не залишатися фіксованим на своєму початковому розмірі.
Другий контейнер ініціалізації, з назвою clone-mysql, виконує операцію клонування на реплікаційному Podʼі першого разу, коли він запускається на порожньому PersistentVolume. Це означає, що він копіює всі наявні дані з іншого працюючого Podʼа, таким чином, його локальний стан є достатньо консистентним для початку реплікації з головного сервера.
MySQL сам по собі не надає механізму для цього, тому приклад використовує популярний відкритий інструмент — Percona XtraBackup. Під час клонування сервер-джерело MySQL може мати знижену продуктивність. Щоб мінімізувати вплив на головний сервер MySQL, скрипт вказує кожному Podʼу отримувати дані з Podʼа, чий порядковий індекс на одиницю менший. Це працює через те, що контролер StatefulSet завжди гарантує, що Pod N є готовим перед запуском Podʼа N+1.
Після успішного завершення контейнерів ініціалізації запускаються звичайні контейнери. Podʼи MySQL складаються з контейнера mysql, в якому працює фактичний сервер mysqld, та контейнера xtrabackup, який діє як sidecar.
Sidecar xtrabackup переглядає клоновані файли даних і визначає, чи необхідно ініціалізувати реплікацію MySQL на репліці. У цьому випадку він чекає, доки mysqld буде готовий, а потім виконує команди CHANGE MASTER TO та START SLAVE з параметрами реплікації, отриманими з клонованих файлів XtraBackup.
Після того як репліка починає реплікацію, вона запамʼятовує свій головний сервер MySQL і автоматично підʼєднується, якщо сервер перезапускається або зʼєднання втрачається. Також, оскільки репліки шукають головний сервер за його стабільним DNS-імʼям (mysql-0.mysql), вони автоматично знаходять головний сервер навіть якщо він отримує новий IP Podʼа через перепланування.
Нарешті, після початку реплікації, контейнер xtrabackup слухає зʼєднання з інших Podʼів, які запитують клон даних. Цей сервер залишається активним нескінченно довго в разі, якщо StatefulSet масштабується вгору, або якщо наступний Pod втрачає свій PersistentVolumeClaim і потрібно повторно виконати клонування.
Ви можете надіслати тестові запити до головного сервера MySQL (хост mysql-0.mysql) запустивши тимчасовий контейнер з образом mysql:5.7 і використовуючи бінарний файл клієнта mysql.
kubectl run mysql-client --image=mysql:5.7 -i --rm --restart=Never --\
mysql -h mysql-0.mysql <<EOF
CREATE DATABASE test;
CREATE TABLE test.messages (message VARCHAR(250));
INSERT INTO test.messages VALUES ('hello');
EOF
Використовуйте хост mysql-read, щоб надіслати тестові запити до будь-якого сервера, який повідомляє про готовність:
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
mysql -h mysql-read -e "SELECT * FROM test.messages"
Ви повинні отримати вивід схожий на цей:
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello |
+---------+
pod "mysql-client" deleted
Щоб продемонструвати, що Service mysql-read розподіляє підключення між
серверами, ви можете запустити SELECT @@server_id у циклі:
kubectl run mysql-client-loop --image=mysql:5.7 -i -t --rm --restart=Never --\
bash -ic "while sleep 1; do mysql -h mysql-read -e 'SELECT @@server_id,NOW()'; done"
Ви повинні бачити, що @@server_id змінюється випадковим чином, оскільки може бути вибрана інша точка доступу при кожній спробі підключення:
+-------------+---------------------+
| @@server_id | NOW() |
+-------------+---------------------+
| 100 | 2006-01-02 15:04:05 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW() |
+-------------+---------------------+
| 102 | 2006-01-02 15:04:06 |
+-------------+---------------------+
+-------------+---------------------+
| @@server_id | NOW() |
+-------------+---------------------+
| 101 | 2006-01-02 15:04:07 |
+-------------+---------------------+
Ви можете натиснути Ctrl+C, коли захочете зупинити цикл, але цікаво тримати його запущеним в іншому вікні, щоб бачити ефект від наступних кроків.
Щоб продемонструвати підвищену доступність читання з пулу реплік замість одного сервера, залиште цикл SELECT @@server_id, запущений вище, активним, тоді як ви змушуєте Pod вийти зі стану Ready.
Проба готовності для контейнера mysql виконує команду mysql -h 127.0.0.1 -e 'SELECT 1', щоб переконатися, що сервер запущений і може виконувати запити.
Один зі способів змусити цю пробу готовності не спрацювати — зламати цю команду:
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql /usr/bin/mysql.off
Ця дія втручається у файлову систему контейнера Podʼа mysql-2 і перейменовує команду mysql, щоб проба готовності не могла її знайти. Через кілька секунд Pod повинен повідомити про один зі своїх контейнерів як неготовий, що можна перевірити за допомогою:
kubectl get pod mysql-2
Перевірте значення 1/2 у стовпці READY:
NAME READY STATUS RESTARTS AGE
mysql-2 1/2 Running 0 3m
На цьому етапі ви повинні бачити продовження роботи вашого циклу SELECT @@server_id, хоча він більше не повідомляє про 102. Нагадаємо, що скрипт init-mysql визначив server-id як 100 + $ordinal, тож ідентифікатор сервера 102 відповідає Podʼу mysql-2.
Тепер відновіть Pod і він повинен знову зʼявитися у виводі циклу через кілька секунд:
kubectl exec mysql-2 -c mysql -- mv /usr/bin/mysql.off /usr/bin/mysql
Контролер StatefulSet також створює Podʼи знову, якщо вони видалені, подібно до того, як це робить ReplicaSet для Podʼів без збереження стану.
kubectl delete pod mysql-2
Контролер StatefulSet помічає, що Podʼа mysql-2 більше не існує, і створює новий з тією ж назвою та повʼязаний з тим самим PersistentVolumeClaim. Ви повинні побачити, що ідентифікатор сервера 102 зникне з виводу циклу протягом певного часу і потім повернеться самостійно.
Якщо у вашому кластері Kubernetes є кілька вузлів, ви можете симулювати відмову вузла (наприклад, під час оновлення вузлів) за допомогою команди drain.
Спочатку визначте, на якому вузлі знаходиться один із Podʼів MySQL:
kubectl get pod mysql-2 -o wide
Назва вузла повинна зʼявитися у останньому стовпчику:
NAME READY STATUS RESTARTS AGE IP NODE
mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-node-9l2t
Потім виконайте drain вузла такою командою: вона виконує cordon вузла, щоб нові Podʼи не могли туди плануватися, а потім виселяє всі наявні Podʼи. Замість <node-name> підставте назву вузла, яку ви знайшли на попередньому кроці.
# Дивіться вище поради щодо впливу на інші робочі навантаження
kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets
Тепер ви можете спостерігати, як Pod переплановується на іншому вузлі:
kubectl get pod mysql-2 -o wide --watch
Це має виглядати приблизно так:
NAME READY STATUS RESTARTS AGE IP NODE
mysql-2 2/2 Terminating 0 15m 10.244.1.56 kubernetes-node-9l2t
[...]
mysql-2 0/2 Pending 0 0s <none> kubernetes-node-fjlm
mysql-2 0/2 Init:0/2 0 0s <none> kubernetes-node-fjlm
mysql-2 0/2 Init:1/2 0 20s 10.244.5.32 kubernetes-node-fjlm
mysql-2 0/2 PodInitializing 0 21s 10.244.5.32 kubernetes-node-fjlm
mysql-2 1/2 Running 0 22s 10.244.5.32 kubernetes-node-fjlm
mysql-2 2/2 Running 0 30s 10.244.5.32 kubernetes-node-fjlm
І знову, ви повинні побачити, що ідентифікатор сервера 102 зник з виводу циклу SELECT @@server_id протягом певного часу, а потім повернувся.
Тепер виконайте uncordon вузла, щоб повернути його до звичайного стану:
kubectl uncordon <node-name>
Коли ви використовуєте реплікацію MySQL, ви можете збільшувати пропускну здатність для запитів на читання, додаючи репліки. Для StatefulSet це можна зробити однією командою:
kubectl scale statefulset mysql --replicas=5
Спостерігайте, як нові Podʼи запускаються, виконавши:
kubectl get pods -l app=mysql --watch
Коли вони будуть готові, ви побачите, що ідентифікатори серверів 103 та 104 починають зʼявлятися у виводі циклу SELECT @@server_id.
Ви також можете перевірити, що ці нові сервери мають дані, які ви додали ще до того, як вони зʼявилися:
kubectl run mysql-client --image=mysql:5.7 -i -t --rm --restart=Never --\
mysql -h mysql-3.mysql -e "SELECT * FROM test.messages"
Waiting for pod default/mysql-client to be running, status is Pending, pod ready: false
+---------+
| message |
+---------+
| hello |
+---------+
pod "mysql-client" deleted
Зменшення кількості реплік так само безпроблемне:
kubectl scale statefulset mysql --replicas=3
Хоча збільшення створює нові PersistentVolumeClaims автоматично, зменшення автоматично не видаляє ці PVC.
Це дає вам можливість залишити ці ініціалізовані PVC для швидшого збільшення, або вилучити дані перед їх видаленням.
Ви можете перевірити це, виконавши:
kubectl get pvc -l app=mysql
Це покаже, що всі 5 PVC все ще існують, попри те, що StatefulSet був зменшений до 3:
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
data-mysql-0 Bound pvc-8acbf5dc-b103-11e6-93fa-42010a800002 10Gi RWO 20m
data-mysql-1 Bound pvc-8ad39820-b103-11e6-93fa-42010a800002 10Gi RWO 20m
data-mysql-2 Bound pvc-8ad69a6d-b103-11e6-93fa-42010a800002 10Gi RWO 20m
data-mysql-3 Bound pvc-50043c45-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m
data-mysql-4 Bound pvc-500a9957-b1c5-11e6-93fa-42010a800002 10Gi RWO 2m
Якщо ви не збираєтеся повторно використовувати додаткові PVC, ви можете їх видалити:
kubectl delete pvc data-mysql-3
kubectl delete pvc data-mysql-4
Припиніть цикл SELECT @@server_id, натиснувши Ctrl+C в його терміналі або виконавши наступне з іншого терміналу:
kubectl delete pod mysql-client-loop --now
Видаліть StatefulSet. Це також розпочне завершення Podʼів.
kubectl delete statefulset mysql
Перевірте, що Podʼи зникають. Завершення їхньої роботи може зайняти деякий час.
kubectl get pods -l app=mysql
Ви будете знати, що Podʼи завершилися, коли вищезазначена команда поверне:
No resources found.
Видаліть ConfigMap, Services та PersistentVolumeClaims.
kubectl delete configmap,service,pvc -l app=mysql
Якщо ви вручну надавали PersistentVolumes, вам також потрібно вручну видалити їх, а також звільнити відповідні ресурси. Якщо ви використовували динамічний provisioner, він автоматично видаляє PersistentVolumes, коли бачить, що ви видалили PersistentVolumeClaims. Деякі динамічні provisioners (такі як ті, що стосуються EBS та PD) також звільняють відповідні ресурси при видаленні PersistentVolumes.
crictl — це інтерфейс командного рядка для середовищ виконання контейнерів, сумісних з CRI. За його допомогою можна оглядати й налагоджувати середовища виконання контейнерів і застосунки на вузлі Kubernetes. crictl і його вихідний код розміщено в репозиторії cri-tools.
Для роботи crictl потрібна операційна система Linux із середовищем виконання CRI.
Стиснений архів crictl для кількох різних архітектур можна завантажити зі сторінки релізів cri-tools. Завантажте версію, яка відповідає вашій версії Kubernetes. Розпакуйте архів і перемістіть crictl у теку з вашого системного шляху, наприклад /usr/local/bin/.
Команда crictl має кілька підкоманд і прапорців середовища виконання. Докладніше дивіться crictl help або crictl <subcommand> help.
Точку доступу для crictl можна встановити одним із таких способів:
--runtime-endpoint та --image-endpoint.CONTAINER_RUNTIME_ENDPOINT та IMAGE_SERVICE_ENDPOINT./etc/crictl.yaml. Щоб вказати інший файл, використовуйте прапорець --config=PATH_TO_FILE під час запуску crictl.crictl намагатиметься підʼєднатися до відомих точок доступу зі списку, що може вплинути на продуктивність.Також можна вказати тайм-аут підʼєднання до сервера й увімкнути або вимкнути налагодження, задавши значення timeout або debug у файлі конфігурації або використавши прапорці командного рядка --timeout і --debug.
Щоб переглянути або змінити поточну конфігурацію, перегляньте або відредагуйте вміст /etc/crictl.yaml. Наприклад, з середовищем виконання контейнерів containerd конфігурація буде схожа на таку:
runtime-endpoint: unix:///var/run/containerd/containerd.sock
image-endpoint: unix:///var/run/containerd/containerd.sock
timeout: 10
debug: true
Щоб дізнатися більше про crictl, зверніться до документації crictl.
Наведені нижче приклади показують деякі команди crictl і приклади їхнього виводу.
Вивести всі Podʼи:
crictl pods
Вивід подібний до такого:
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
926f1b5a1d33a About a minute ago Ready sh-84d7dcf559-4r2gq default 0
4dccb216c4adb About a minute ago Ready nginx-65899c769f-wv2gp default 0
a86316e96fa89 17 hours ago Ready kube-proxy-gblk4 kube-system 0
919630b8f81f1 17 hours ago Ready nvidia-device-plugin-zgbbv kube-system 0
Вивести Podʼи за назвою:
crictl pods --name nginx-65899c769f-wv2gp
Вивід подібний до такого:
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0
Вивести Podʼи за міткою:
crictl pods --label run=nginx
Вивід подібний до такого:
POD ID CREATED STATE NAME NAMESPACE ATTEMPT
4dccb216c4adb 2 minutes ago Ready nginx-65899c769f-wv2gp default 0
Вивести всі образи:
crictl images
Вивід подібний до такого:
IMAGE TAG IMAGE ID SIZE
busybox latest 8c811b4aec35f 1.15MB
k8s-gcrio.azureedge.net/hyperkube-amd64 v1.10.3 e179bbfe5d238 665MB
k8s-gcrio.azureedge.net/pause-amd64 3.1 da86e6ba6ca19 742kB
nginx latest cd5239a0906a6 109MB
Вивести образи за репозиторієм:
crictl images nginx
Вивід подібний до такого:
IMAGE TAG IMAGE ID SIZE
nginx latest cd5239a0906a6 109MB
Вивести лише ідентифікатори образів:
crictl images -q
Вивід подібний до такого:
sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a
sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5
sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e
sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569
Вивести всі контейнери:
crictl ps -a
Вивід подібний до такого:
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 7 minutes ago Running sh 1
9c5951df22c78 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 8 minutes ago Exited sh 0
87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 8 minutes ago Running nginx 0
1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 18 hours ago Running kube-proxy 0
Вивести запущені контейнери:
crictl ps
Вивід подібний до такого:
CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT
1f73f2d81bf98 busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47 6 minutes ago Running sh 1
87d3992f84f74 nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f 7 minutes ago Running nginx 0
1941fb4da154f k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a 17 hours ago Running kube-proxy 0
crictl exec -i -t 1f73f2d81bf98 ls
Вивід подібний до такого:
bin dev etc home proc root sys tmp usr var
Отримати всі логи контейнера:
crictl logs 87d3992f84f74
Вивід подібний до такого:
10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
Отримати лише останні N рядків логів:
crictl logs --tail=1 87d3992f84f74
Вивід подібний до такого:
10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
This is a stable feature in Kubernetes, and has been since version v1.35. It was first available in the v1.30 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate DynamicResourceAllocation, Kubernetes ignores it but does not report any error.
На цій сторінці показано, як налаштувати динамічне виділення ресурсів (DRA) у кластері Kubernetes шляхом активації груп API та налаштування класів пристроїв. Ці інструкції призначені для адміністраторів кластерів.
Можливість Kubernetes, яка дозволяє запитувати ресурси та спільно використовувати їх між Podʼами. Часто такими ресурсами є приєднані пристрої, як-от апаратні прискорювачі.
З DRA драйвери пристроїв і адміністратори кластера визначають класи пристроїв, які робочі навантаження можуть запитувати (claim). Kubernetes виділяє відповідні пристрої конкретним запитам (claims) і розміщує відповідні Podʼи на вузлах, які мають доступ до виділених пристроїв.
Переконайтеся, що ви ознайомлені з принципом роботи DRA та термінологією DRA, такою як DeviceClasses, ResourceClaims і ResourceClaimTemplates. Детальніше дивіться Динамічне виділення ресурсів (DRA).
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.34.Для перевірки версії введіть kubectl version.
Загалом DRA є стабільною функцією в Kubernetes, проте деякі її аспекти можуть бути ще в стадії альфа- або бета-тестування. Якщо ви хочете використовувати будь-який аспект DRA, який ще не є стабільним, а повʼязана з ним функція залежить від спеціального типу API, тоді ви повинні увімкнути відповідні групи альфа- або бета-API.
Деякі старі драйвери або робочі навантаження DRA можуть все ще потребувати API v1beta1 з Kubernetes 1.30 або v1beta2 з Kubernetes 1.32. Тільки якщо потрібна підтримка цих версій, увімкніть наступні групи API:
* `resource.k8s.io/v1beta1`
* `resource.k8s.io/v1beta2`
Альфа-функції з окремими типами API потребують:
resource.k8s.io/v1alpha3Для отримання додаткової інформації дивіться Увімкнення або вимкнення груп API.
Щоб перевірити правильність налаштування кластера, спробуйте вивести список DeviceClasses:
kubectl get deviceclasses
Якщо конфігурація компонентів була правильною, ви побачите подібний результат:
No resources found
Якщо DRA налаштовано неправильно, результат виконання попередньої команди буде схожий на:
error: the server doesn't have a resource type "deviceclasses"
Наприклад, це може статися, коли група API resource.k8s.io була вимкнена. Аналогічна перевірка застосовується до типів верхнього рівня якості альфа або бета.
Спробуйте наступні кроки для усунення несправностей:
Переконфігуруйте та перезапустіть компонент kube-apiserver.
Якщо повне поле .spec.resourceClaims видаляється з Podʼів, або якщо Podʼи плануються без урахування ResourceClaims, перевірте, чи не вимкнено функціональну можливість DynamicResourceAllocation для kube-apiserver, kube-controller-manager, kube-scheduler або kubelet.
Після активації DRA для вашого кластера ви можете встановити драйвери для підключених пристроїв. Інструкції шукайте у документації власника пристрою або проєкту, що підтримує драйвери пристроїв. Встановлені драйвери мають бути сумісні з DRA.
Щоб перевірити роботу встановлених драйверів, виведіть список ResourceSlices у кластері:
kubectl get resourceslices
Вивід буде схожий на:
NAME NODE DRIVER POOL AGE
00000-driver.example.com-cluster-1-node-1-abcde cluster-1-node-1 driver.example.com cluster-1-device-pool-1-r1gc 7s
00000-driver.example.com-cluster-1-node-2-fghij cluster-1-node-2 driver.example.com cluster-1-device-pool-2-446z 8s
Спробуйте наступні кроки для усунення несправностей:
Ви можете визначити категорії пристроїв, які оператори ваших застосунків можуть запитувати у робочих навантаженнях, створюючи DeviceClasses. Деякі постачальники драйверів пристроїв також можуть вказати вам створити DeviceClasses під час встановлення драйверів.
ResourceSlices, які публікує ваш драйвер, містять інформацію про пристрої, якими керує драйвер, такі як ємність, метадані та атрибути. Ви можете використовувати Common Expression Language для фільтрації властивостей у DeviceClasses, що спрощує пошук пристроїв для операторів навантажень.
Щоб знайти властивості пристрою, які можна вибирати у DeviceClasses за допомогою виразів CEL, отримайте специфікацію ResourceSlice:
kubectl get resourceslice <resourceslice-name> -o yaml
Вивід буде схожий на:
apiVersion: resource.k8s.io/v1
kind: ResourceSlice
# рядки пропущено для ясності
spec:
devices:
- attributes:
type:
string: gpu
capacity:
memory:
value: 64Gi
name: gpu-0
- attributes:
type:
string: gpu
capacity:
memory:
value: 64Gi
name: gpu-1
driver: driver.example.com
nodeName: cluster-1-node-1
# рядки пропущено для ясності
Ви також можете переглянути документацію постачальника драйверів для доступних властивостей і значень.
Ознайомтеся з прикладом маніфесту DeviceClass, який вибирає будь-який пристрій, керований драйвером пристроїв driver.example.com:
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
name: example-device-class
spec:
selectors:
- cel:
expression: |-
device.driver == "driver.example.com"
Створіть DeviceClass у вашому кластері:
kubectl apply -f https://k8s.io/examples/dra/deviceclass.yaml
Щоб видалити DeviceClass, створений у цьому завданні, виконайте команду:
kubectl delete -f https://k8s.io/examples/dra/deviceclass.yaml
This is a stable feature in Kubernetes, and has been since version v1.35. It was first available in the v1.30 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate DynamicResourceAllocation, Kubernetes ignores it but does not report any error.
На цій сторінці показано, як виділяти пристрої вашим Podʼам за допомогою динамічного виділення ресурсів (DRA). Ці інструкції призначені для операторів робочих навантажень. Перед прочитанням цієї сторінки ознайомтеся з принципами роботи DRA та термінами DRA, такими як ResourceClaims і ResourceClaimTemplates. Докладніше дивіться у розділі Динамічне виділення ресурсів (DRA).
Як оператор робочих навантажень, ви можете запитувати пристрої для своїх навантажень, створюючи ResourceClaims або ResourceClaimTemplates. Під час розгортання навантаження Kubernetes і драйвери пристроїв знаходять доступні пристрої, виділяють їх вашим Podʼам і розміщують Podʼи на вузлах, які мають доступ до цих пристроїв.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.34.Для перевірки версії введіть kubectl version.
Адміністратор вашого кластера або драйвери пристроїв створюють DeviceClasses, які визначають категорії пристроїв. Ви можете запитувати пристрої, використовуючи Common Expression Language для фільтрації за конкретними властивостями пристроїв.
Отримайте список DeviceClasses у кластері:
kubectl get deviceclasses
Вивід буде схожим на наступний:
NAME AGE
driver.example.com 16m
Якщо ви отримали помилку доступу, можливо, у вас немає прав для перегляду DeviceClasses. Зверніться до адміністратора кластера або постачальника драйверів щодо доступних властивостей пристроїв.
Ви можете запитувати ресурси з DeviceClass за допомогою ResourceClaims. Щоб створити ResourceClaim, виконайте одну з наступних дій:
Якщо ви безпосередньо посилаєтеся на конкретний ResourceClaim у Podʼі, цей ResourceClaim вже має існувати у кластері. Якщо зазначений ResourceClaim не існує, Pod залишатиметься у стані очікування, доки ResourceClaim не буде створено. Ви можете посилатися на автоматично згенерований ResourceClaim у Podʼі, але це не рекомендується, оскільки автоматично згенеровані ResourceClaims привʼязані до часу життя Podʼа, який спричинив їх створення.
Щоб створити робоче навантаження, яке запитує ресурси, виберіть одну з наступних опцій:
Ознайомтеся з наступним прикладом маніфесту:
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: example-resource-claim-template
spec:
spec:
devices:
requests:
- name: gpu-claim
exactly:
deviceClassName: example-device-class
selectors:
- cel:
expression: |-
device.attributes["driver.example.com"].type == "gpu" &&
device.capacity["driver.example.com"].memory == quantity("64Gi")
Цей маніфест створює ResourceClaimTemplate, який запитує пристрої у DeviceClass example-device-class, що відповідають обом наступним параметрам:
driver.example.com/type зі значенням gpu.64Gi.Щоб створити ResourceClaimTemplate, виконайте наступну команду:
kubectl apply -f https://k8s.io/examples/dra/resourceclaimtemplate.yaml
Ознайомтеся з наступним прикладом маніфесту:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: example-resource-claim
spec:
devices:
requests:
- name: single-gpu-claim
exactly:
deviceClassName: example-device-class
allocationMode: All
selectors:
- cel:
expression: |-
device.attributes["driver.example.com"].type == "gpu" &&
device.capacity["driver.example.com"].memory == quantity("64Gi")
Цей маніфест створює ResourceClaim, який запитує пристрої у DeviceClass example-device-class, що відповідають обом наступним параметрам:
driver.example.com/type зі значенням gpu.64Gi.Щоб створити ResourceClaim, виконайте наступну команду:
kubectl apply -f https://k8s.io/examples/dra/resourceclaim.yaml
Щоб запросити виділення пристроїв, вкажіть ResourceClaim або ResourceClaimTemplate у полі resourceClaims специфікації Podʼа. Потім запросіть конкретну заявку за назвою у полі resources.claims контейнера цього Podʼа. Ви можете вказати декілька записів у полі resourceClaims та використовувати конкретні заявки у різних контейнерах.
Ознайомтеся з наступним прикладом Job:
apiVersion: batch/v1
kind: Job
metadata:
name: example-dra-job
spec:
completions: 10
parallelism: 2
template:
spec:
restartPolicy: Never
containers:
- name: container0
image: ubuntu:24.04
command: ["sleep", "9999"]
resources:
claims:
- name: separate-gpu-claim
- name: container1
image: ubuntu:24.04
command: ["sleep", "9999"]
resources:
claims:
- name: shared-gpu-claim
- name: container2
image: ubuntu:24.04
command: ["sleep", "9999"]
resources:
claims:
- name: shared-gpu-claim
resourceClaims:
- name: separate-gpu-claim
resourceClaimTemplateName: example-resource-claim-template
- name: shared-gpu-claim
resourceClaimName: example-resource-claim
Кожен Pod у цьому Job має наступні властивості:
separate-gpu-claim та ResourceClaim з назвою shared-gpu-claim.container0 запитує пристрої з ResourceClaimTemplate separate-gpu-claim.container1 та container2 мають спільний доступ до пристроїв з ResourceClaim shared-gpu-claim.Створіть Job:
kubectl apply -f https://k8s.io/examples/dra/dra-example-job.yaml
Спробуйте наступні кроки для усунення неполадок:
kubectl describe, щоб дізнатися, чи є якісь поля статусу або події, які можуть пояснити, чому робоче навантаження не запускається.must specify one of: resourceClaimName, resourceClaimTemplateName, перевірте, що всі записи в pod.spec.resourceClaims мають точно одне з цих полів. Якщо так, то можливо, що в кластері встановлено модифікуючий вебхук Podʼа, який був створений для API Kubernetes < 1.32. Попросіть адміністратора кластера перевірити це.Щоб видалити обʼєкти Kubernetes, створені у цьому завданні, виконайте наступні кроки:
Видаліть приклад Job:
kubectl delete -f https://k8s.io/examples/dra/dra-example-job.yaml
Щоб видалити свої заявки на ресурси, виконайте одну з наступних команд:
Видаліть ResourceClaimTemplate:
kubectl delete -f https://k8s.io/examples/dra/resourceclaimtemplate.yaml
Видаліть ResourceClaim:
kubectl delete -f https://k8s.io/examples/dra/resourceclaim.yaml
Ця сторінка показує, як отримати доступ до метаданих пристроїв з контейнерів, які використовують динамічне виділення ресурсів (DRA). Метадані пристроїв дозволяють робочим навантаженням дізнаватися інформацію про виділені пристрої, таку як атрибути пристроїв або деталі мережевого інтерфейсу, шляхом читання JSON-файлів за відомими шляхами всередині контейнера.
Перш ніж читати цю сторінку, ознайомтеся з динамічним виділенням ресурсів (DRA) та з тим, як виділяти пристрої для робочих навантажень.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути v1.37.Для перевірки версії введіть kubectl version.
EnableDeviceMetadata та повинні включити metadata.resource.k8s.io/v1beta1 у вибрані версії. Драйвер також може видавати v1alpha1 для сумісності зі старішими споживачами.Коли ви використовуєте безпосередньо вказаний ResourceClaim для виділення пристроїв, файли метаданих пристроїв зʼявляються всередині контейнера за шляхом:
/var/run/kubernetes.io/dra-device-attributes/resourceclaims/<claimName>/<requestName>/<driverName>-metadata.json
Перегляньте наступний приклад маніфесту:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: gpu-claim
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
---
apiVersion: v1
kind: Pod
metadata:
name: gpu-metadata-reader
spec:
resourceClaims:
- name: my-gpu
resourceClaimName: gpu-claim
containers:
- name: workload
image: ubuntu:24.04
resources:
claims:
- name: my-gpu
request: gpu
command:
- sh
- -c
- |
echo "=== DRA device metadata ==="
find /var/run/kubernetes.io/dra-device-attributes -name '*-metadata.json' -print -exec cat {} \;
sleep 3600
restartPolicy: Never
Цей маніфест створює ResourceClaim з назвою gpu-claim, який запитує пристрій з DeviceClass gpu.example.com, та Pod, який читає метадані пристрою.
Створіть ResourceClaim та Pod:
kubectl apply -f https://k8s.io/examples/dra/dra-device-metadata-pod.yaml
Коли Pod запрацює, перегляньте логи контейнера, щоб побачити метадані:
kubectl logs gpu-metadata-reader
Вивід буде схожий на:
=== DRA device metadata ===
/var/run/kubernetes.io/dra-device-attributes/resourceclaims/gpu-claim/gpu/gpu.example.com-metadata.json
{
"kind": "DeviceMetadata",
"apiVersion": "metadata.resource.k8s.io/v1beta1",
...
}
Щоб переглянути повний файл метаданих, виконайте команду всередині контейнера:
kubectl exec gpu-metadata-reader -- \
cat /var/run/kubernetes.io/dra-device-attributes/resourceclaims/gpu-claim/gpu/gpu.example.com-metadata.json
Файл метаданих — це JSON-потік. Він містить один обʼєкт для кожної версії API, вибраної драйвером, у порядку, налаштованому драйвером. Драйвери повинні розміщувати найновішу версію першою. Обʼєкти містять еквівалентні метадані пристрою, тому команда може вивести більше ніж один JSON-обʼєкт.
Вивід містить атрибути пристрою, такі як модель, версія драйвера та UUID пристрою. Ємності пристроїв не є частиною схеми метаданих. Дивіться схему метаданих для деталей структури JSON.
Коли ви використовуєте ResourceClaimTemplate, Kubernetes генерує ResourceClaim для кожного Podʼа. Оскільки згенерована назва заявки непередбачувана, файли метаданих натомість зʼявляються за шляхом, який використовує імʼя посилання на заявку в Podʼі:
/var/run/kubernetes.io/dra-device-attributes/resourceclaimtemplates/<podClaimName>/<requestName>/<driverName>-metadata.json
<podClaimName> відповідає полю name у записі spec.resourceClaims[] Podʼа. JSON-метадані також включають поле podClaimName, яке фіксує це зіставлення.
Перегляньте наступний приклад маніфесту:
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
name: gpu-claim-template
spec:
spec:
devices:
requests:
- name: gpu
exactly:
deviceClassName: gpu.example.com
---
apiVersion: v1
kind: Pod
metadata:
name: gpu-metadata-template-reader
spec:
resourceClaims:
- name: my-gpu
resourceClaimTemplateName: gpu-claim-template
containers:
- name: workload
image: ubuntu:24.04
resources:
claims:
- name: my-gpu
request: gpu
command:
- sh
- -c
- |
echo "=== DRA device metadata (from template) ==="
find /var/run/kubernetes.io/dra-device-attributes -name '*-metadata.json' -print -exec cat {} \;
sleep 3600
restartPolicy: Never
Цей маніфест створює ResourceClaimTemplate та Pod. Кожен Pod отримує власний згенерований ResourceClaim. Шлях до метаданих використовує імʼя посилання на заявку в Podʼі — my-gpu.
Створіть ResourceClaimTemplate та Pod:
kubectl apply -f https://k8s.io/examples/dra/dra-device-metadata-template-pod.yaml
Коли Pod запрацює, перегляньте метадані:
kubectl exec gpu-metadata-template-reader -- \
cat /var/run/kubernetes.io/dra-device-attributes/resourceclaimtemplates/my-gpu/gpu/gpu.example.com-metadata.json
Пакунок k8s.io/dynamic-resource-allocation/devicemetadata надає готові функції для читання файлів метаданих. Ці функції автоматично обробляють узгодження версій, декодують потік метаданих і перетворюють його на внутрішні типи, щоб ваш код працював з різними версіями схеми без ручної перевірки версій. Вони пропускають обʼєкти з невідомими версіями API та повертають перший сумісний обʼєкт.
Для безпосередньо вказаного ResourceClaim:
import "k8s.io/dynamic-resource-allocation/devicemetadata"
dm, err := devicemetadata.ReadResourceClaimMetadata("gpu-claim", "gpu")
Для заявки, створеної з шаблону (з використанням імені посилання на заявку в Podʼі):
dm, err := devicemetadata.ReadResourceClaimTemplateMetadata("my-gpu", "gpu")
Якщо ви знаєте конкретне імʼя драйвера, ви можете прочитати файл метаданих одного драйвера:
dm, err := devicemetadata.ReadResourceClaimMetadataWithDriverName("gpu.example.com", "gpu-claim", "gpu")
Функції, які читають усі драйвери, повертають *metadata.DeviceMetadata з обʼєднаними запитами та атрибутами кожного пристрою. Функції, які приймають імʼя драйвера, повертають повний обʼєкт метаданих із файлу цього драйвера.
Допоміжні функції читання декодують метадані без перевірки. Щоб увімкнути перевірку, відкрийте файл і використайте DecodeMetadataFromStream:
import (
"encoding/json"
"os"
"k8s.io/dynamic-resource-allocation/api/metadata"
"k8s.io/dynamic-resource-allocation/devicemetadata"
)
func readMetadata(path string) (*metadata.DeviceMetadata, error) {
file, err := os.Open(path)
if err != nil {
return nil, err
}
defer file.Close()
var deviceMetadata metadata.DeviceMetadata
var validationErr error
err = devicemetadata.DecodeMetadataFromStream(
json.NewDecoder(file),
&deviceMetadata,
devicemetadata.DecodeMetadataWithValidationResult(&validationErr),
)
if err != nil {
return nil, err
}
if validationErr != nil {
return nil, validationErr
}
return &deviceMetadata, nil
}
Декодування та перевірка мають окремі результати. Помилка перевірки не заважає декодеру заповнювати deviceMetadata. Перевірка корисна, коли метадані надходять від власного драйвера, оскільки втулок kubelet DRA не перевіряє обʼєкти перед їх записом.
Застосунки іншими мовами можуть декодувати JSON-потік по одному обʼєкту за раз, перевіряти кожен apiVersion, пропускати невідомі версії та використовувати першу версію, яку вони підтримують.
Видаліть створені ресурси:
kubectl delete -f https://k8s.io/examples/dra/dra-device-metadata-pod.yaml
kubectl delete -f https://k8s.io/examples/dra/dra-device-metadata-template-pod.yaml
Аудит Kubernetes надає важливий для безпеки хронологічний набір записів, що документують послідовність дій у кластері. Кластер проводить аудит дій, ініційованих користувачами, застосунками, які використовують API Kubernetes, і самою панеллю управління.
Аудит дає змогу адміністраторам кластера відповісти на такі запитання:
Записи аудиту починають свій життєвий цикл у компоненті kube-apiserver. Кожен запит на кожному етапі виконання генерує подію аудиту, яку потім попередньо обробляють відповідно до певної політики й записують у бекенд. Політика визначає, що записується, а бекенди зберігають записи. Поточні реалізації бекендів — файли логів і вебхуки.
Кожен запит можна записати з відповідним етапом (stage). Визначено такі етапи:
RequestReceived — етап для подій, що генеруються, щойно обробник аудиту отримує запит, і до того, як запит передано далі ланцюжком обробників.ResponseStarted — після надсилання заголовків відповіді, але до надсилання тіла відповіді. Цей етап генерується лише для тривалих запитів (наприклад, watch).ResponseComplete — тіло відповіді завершено, і більше жодних байтів не буде надіслано.Panic — події, що генеруються, коли сталася паніка.Можливість логування аудиту збільшує споживання памʼяті API-сервером, оскільки для кожного запиту зберігається певний контекст, потрібний для аудиту. Споживання памʼяті залежить від конфігурації логування аудиту.
Політика аудиту визначає правила щодо того, які події слід записувати і які дані вони мають містити. Структуру обʼєкта політики аудиту визначено в групі API audit.k8s.io. Під час обробки подію по черзі порівнюють зі списком правил. Перше правило, що збіглося, встановлює рівень аудиту події. Визначено такі рівні аудиту:
None — не записувати події, які відповідають цьому правилу.Metadata — записувати події з метаданими (користувач, що надіслав запит, часова мітка, ресурс, дієслово тощо), але без тіла запиту чи відповіді.Request — записувати події з метаданими й тілом запиту, але без тіла відповіді. Це не стосується запитів, не повʼязаних з ресурсами.RequestResponse — записувати події з метаданими запиту, тілом запиту й тілом відповіді. Це не стосується запитів, не повʼязаних з ресурсами.Файл з політикою можна передати kube-apiserver за допомогою прапорця --audit-policy-file. Якщо прапорець пропущено, жодні події не записуються. Зверніть увагу, що поле rules обовʼязково має бути у файлі політики аудиту. Політика без правил (0) вважається неприпустимою.
Нижче наведено приклад файлу політики аудиту:
apiVersion: audit.k8s.io/v1 # Це обовʼязково.
kind: Policy
# Не генерувати події аудиту для всіх запитів на етапі RequestReceived.
omitStages:
- "RequestReceived"
rules:
# Логувати зміни Podʼів на рівні RequestResponse
- level: RequestResponse
resources:
- group: ""
# Ресурс "pods" не охоплює запити до будь-якого субресурсу Podʼів,
# що узгоджується з політикою RBAC.
resources: ["pods"]
# Логувати "pods/log", "pods/status" на рівні Metadata
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
# Не логувати запити до ConfigMap з назвою "controller-leader"
- level: None
resources:
- group: ""
resources: ["configmaps"]
resourceNames: ["controller-leader"]
# Не логувати watch-запити від "system:kube-proxy" до endpoints або services
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # основна група API
resources: ["endpoints", "services"]
# Не логувати автентифіковані запити до певних URL-шляхів, що не є ресурсами.
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*" # Зіставлення за шаблоном.
- "/version"
# Логувати тіло запитів на зміну ConfigMap у kube-system.
- level: Request
resources:
- group: "" # основна група API
resources: ["configmaps"]
# Це правило застосовується тільки до ресурсів в просторі імен "kube-system".
# Порожній рядок "" можна використовувати для вибору ресурсів без простору імен.
namespaces: ["kube-system"]
# Логувати зміни ConfigMap і Secret у всіх інших просторах імен на рівні Metadata.
- level: Metadata
resources:
- group: "" # основна група API
resources: ["secrets", "configmaps"]
# Логувати всі інші ресурси в групах core та extensions на рівні Request.
- level: Request
resources:
- group: "" # основна група API
- group: "extensions" # Версію групи НЕ слід вказувати.
# Загальне правило для логування всіх інших запитів на рівні Metadata.
- level: Metadata
# Тривалі запити, як-от watch, що підпадають під це правило,
# не генерують подію аудиту на етапі RequestReceived.
omitStages:
- "RequestReceived"
Можна використати мінімальний файл політики аудиту, щоб записувати всі запити на рівні Metadata:
# Записувати всі запити на рівні Metadata.
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
Якщо ви створюєте власний профіль аудиту, за відправну точку можна взяти профіль аудиту для Google Container-Optimized OS. Перегляньте скрипт configure-helper.sh, який генерує файл політики аудиту. Більшу частину файлу політики аудиту можна побачити безпосередньо в скрипті.
Докладніше про визначені поля дивіться в довіднику конфігурації Policy.
Бекенди аудиту зберігають події аудиту в зовнішньому сховищі. Без додаткових налаштувань kube-apiserver надає два бекенди:
У всіх випадках події аудиту мають структуру, визначену API Kubernetes у групі API audit.k8s.io.
У разі патчів тіло запиту — це масив JSON з операціями патча, а не обʼєкт JSON з відповідним обʼєктом API Kubernetes. Наприклад, наведене нижче тіло запиту є коректним запитом на патч до /apis/batch/v1/namespaces/some-namespace/jobs/some-job-name:
[
{
"op": "replace",
"path": "/spec/parallelism",
"value": 0
},
{
"op": "remove",
"path": "/spec/template/spec/containers/0/terminationMessagePolicy"
}
]
Бекенд логів записує події аудиту у файл у форматі JSONlines. Бекенд аудиту логів можна налаштувати за допомогою таких прапорців kube-apiserver:
--audit-log-path вказує шлях до файлу логу, який бекенд логів використовує для запису подій аудиту. Якщо цей прапорець не вказано, бекенд логів вимкнено. - означає стандартний вивід--audit-log-maxage визначає максимальну кількість днів для зберігання старих файлів логів аудиту--audit-log-maxbackup визначає максимальну кількість файлів логів аудиту для зберігання--audit-log-maxsize визначає максимальний розмір файлу логу аудиту в мегабайтах, після якого виконується його ротаціяЯкщо панель управління вашого кластера запускає kube-apiserver як Pod, не забудьте змонтувати hostPath у розташування файлу політики й файлу логів, щоб записи аудиту зберігалися. Наприклад:
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml
- --audit-log-path=/var/log/kubernetes/audit/audit.log
потім змонтуйте томи:
...
volumeMounts:
- mountPath: /etc/kubernetes/audit-policy.yaml
name: audit
readOnly: true
- mountPath: /var/log/kubernetes/audit/
name: audit-log
readOnly: false
і нарешті налаштуйте hostPath:
...
volumes:
- name: audit
hostPath:
path: /etc/kubernetes/audit-policy.yaml
type: File
- name: audit-log
hostPath:
path: /var/log/kubernetes/audit/
type: DirectoryOrCreate
Бекенд аудиту webhook надсилає події аудиту до віддаленого веб-API, яке вважається різновидом API Kubernetes, зокрема щодо засобів автентифікації. Бекенд аудиту webhook можна налаштувати за допомогою таких прапорців kube-apiserver:
--audit-webhook-config-file вказує шлях до файлу з конфігурацією webhook. Конфігурація webhook фактично є спеціалізованим kubeconfig.--audit-webhook-initial-backoff вказує час очікування після першого невдалого запиту перед повторною спробою. Подальші запити повторюються з експоненційною затримкою.Файл конфігурації webhook використовує формат kubeconfig, щоб вказати віддалену адресу сервісу й облікові дані для підʼєднання до нього.
Обидва бекенди, log і webhook, підтримують пакетну обробку. Нижче наведено перелік доступних прапорців для кожного бекенду. Стандартно пакетну обробку й тротлінг увімкнено для бекенду webhook і вимкнено для бекенду log.
--audit-webhook-mode визначає стратегію буферизації. Можливі значення:
batch — буферизувати події й асинхронно обробляти їх пакетами. Це стандартний режим для бекенду webhook.blocking — блокувати відповіді API-сервера під час обробки кожної окремої події.blocking-strict — те саме, що й blocking, але якщо під час логування аудиту на етапі RequestReceived стається збій, увесь запит до kube-apiserver завершується невдачею.Такі прапорці використовуються лише в режимі batch:
--audit-webhook-batch-buffer-size визначає кількість подій для буферизації перед пакетною обробкою. Якщо швидкість надходження подій переповнює буфер, події відкидаються. Стандартне значення — 10000.--audit-webhook-batch-max-size визначає максимальну кількість подій в одному пакеті. Стандартне значення — 400.--audit-webhook-batch-max-wait визначає максимальний час очікування перед безумовною пакетною обробкою подій у черзі. Стандартне значення — 30 секунд.--audit-webhook-batch-throttle-enable визначає, чи увімкнено тротлінг пакетів. Стандартно тротлінг увімкнено.--audit-webhook-batch-throttle-qps визначає максимальну середню кількість пакетів, що генеруються за секунду. Стандартне значення — 10.--audit-webhook-batch-throttle-burst визначає максимальну кількість пакетів, згенерованих у той самий момент, якщо дозволений QPS раніше використовувався не повністю. Стандартне значення — 15.--audit-log-mode визначає стратегію буферизації. Можливі значення:
batch — буферизувати події й асинхронно обробляти їх пакетами. Пакетна обробка не рекомендується для бекенду log.blocking — блокувати відповіді API-сервера під час обробки кожної окремої події. Це стандартний режим для бекенду log.blocking-strict — те саме, що й blocking, але якщо під час логування аудиту на етапі RequestReceived стається збій, увесь запит до kube-apiserver завершується невдачею.Такі прапорці використовуються лише в режимі batch (стандартно для бекенду log пакетну обробку вимкнено, і коли її вимкнено, усі прапорці, повʼязані з пакетною обробкою, ігноруються):
--audit-log-batch-buffer-size визначає кількість подій для буферизації перед пакетною обробкою. Якщо швидкість надходження подій переповнює буфер, події відкидаються.--audit-log-batch-max-size визначає максимальну кількість подій в одному пакеті.--audit-log-batch-max-wait визначає максимальний час очікування перед безумовною пакетною обробкою подій у черзі.--audit-log-batch-throttle-enable визначає, чи увімкнено тротлінг пакетної обробки.--audit-log-batch-throttle-qps визначає максимальну середню кількість пакетів, що генеруються за секунду.--audit-log-batch-throttle-burst визначає максимальну кількість пакетів, згенерованих у той самий момент, якщо дозволений QPS раніше використовувався не повністю.Параметри слід задавати з урахуванням навантаження на API-сервер.
Наприклад, якщо kube-apiserver отримує 100 запитів щосекунди і кожен запит проходить аудит лише на етапах ResponseStarted і ResponseComplete, слід розраховувати на ≅200 подій аудиту щосекунди. Якщо в пакеті до 100 подій, рівень тротлінгу слід встановити щонайменше 2 запити на секунду. Якщо бекенду може знадобитися до 5 секунд для запису подій, розмір буфера слід встановити так, щоб він вміщував події за 5 секунд, тобто 10 пакетів або 1000 подій.
Однак у більшості випадків стандартних параметрів має бути достатньо, і вам не потрібно задавати їх вручну. Щоб відстежувати стан підсистеми аудиту, можна переглядати такі метрики Prometheus, які надає kube-apiserver, а також логи.
apiserver_audit_event_total містить загальну кількість експортованих подій аудиту.apiserver_audit_error_total містить загальну кількість подій, відкинутих через помилку під час експорту.Обидва бекенди, логів і webhook, підтримують обмеження розміру подій, що записуються. Наприклад, ось перелік прапорців, доступних для бекенду логів:
audit-log-truncate-enabled — чи ввімкнено обрізання подій і пакетів.audit-log-truncate-max-batch-size — максимальний розмір у байтах пакета, що надсилається до базового бекенду.audit-log-truncate-max-event-size — максимальний розмір у байтах події аудиту, що надсилається до базового бекенду.Стандартно обрізання вимкнено і для webhook, і для log; щоб увімкнути цю можливість, адміністратор кластера має встановити audit-log-truncate-enabled або audit-webhook-truncate-enabled.
Event і Policy з довідника конфігурації аудиту.На цій сторінці показано, як створювати й редагувати Secrets Kubernetes, керувати ними та видаляти їх за допомогою інструмента командного рядка kubectl.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Обʼєкт 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 гарантує, що згенеровані файли не матимуть зайвого символу нового рядка в кінці тексту. Це важливо, бо коли kubectl читає файл і кодує вміст у рядок base64, зайвий символ нового рядка теж кодується. Спеціальні символи в рядках, які ви додаєте у файл, екранувати не потрібно.
Передайте шляхи до файлів у команду 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 від випадкового розкриття або збереження в логах термінала.
Перегляньте вміст створеного вами 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 або використовувати одну з цих пісочниць:
Ви можете спочатку визначити обʼєкт 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 створено, і розкодувати дані 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 із такою самою назвою. kubectl отримує наявний обʼєкт, планує зміни в ньому й надсилає змінений обʼєкт Secret до панелі управління кластера.
Якщо натомість ви вказали kubectl apply --server-side, kubectl використовує застосування на боці сервера.
Щоб видалити створений вами Secret:
kubectl delete secret mysecret
kubectl підтримує використання інструмента керування обʼєктами Kustomize для керування Secrets і ConfigMaps. За допомогою Kustomize ви створюєте генератор ресурсів, який генерує Secret, що його можна застосувати до API-сервера за допомогою kubectl.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Ви можете згенерувати 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 створено, і розкодувати дані 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. Можливо, вам доведеться оновити посилання на Secret у ваших Podʼах.
Щоб видалити Secret, використайте kubectl:
kubectl delete secret db-user-pass
Kubernetes приховує від користувача багато аспектів того, як Podʼи виконуються на вузлах. Це зроблено навмисно. Однак деяким робочим навантаженням для прийнятної роботи потрібні сильніші гарантії щодо затримки та/або продуктивності. kubelet надає методи для складніших політик розміщення робочих навантажень і водночас зберігає абстракцію вільною від явних директив розміщення.
Ви можете керувати топологією всередині вузлів. Це означає, що ви допомагаєте kubelet налаштувати операційну систему хоста так, щоб Podʼи й контейнери розміщувалися з правильного боку внутрішніх меж, таких як домени NUMA. (NUMA — абревіатура від non-uniform memory access (нерівномірний доступ до памʼяті); вона відображає ідею, що CPU можуть бути топологічно ближчими до певних ділянок памʼяті через фізичне розташування апаратних компонентів і спосіб їх зʼєднання.)
Щоб зʼясувати, чому Pod не вдалося розгорнути або чому його відхилено на вузлі в контексті керування топологією, можна скористатися такими засобами:
TopologyAffinityErrorЦя помилка зазвичай виникає в таких ситуаціях:
Помилка зʼявляється в статусі Podʼа:
kubectl get pods
NAME READY STATUS RESTARTS AGE
guaranteed 0/1 TopologyAffinityError 0 113s
Використовуйте kubectl describe pod <id> або kubectl events, щоб отримати детальне повідомлення про помилку:
Warning TopologyAffinityError 10m kubelet, dell8 Resources cannot be allocated with Topology locality
Шукайте в системних логах записи щодо конкретного Podʼа.
Набір підказок, згенерованих менеджером CPU, має бути в логах. Також у логах можна знайти набір підказок, які менеджер памʼяті згенерував для Podʼа.
Менеджер топології обʼєднує ці підказки, щоб обчислити одну найкращу підказку. Найкраща підказка також має бути в логах.
Найкраща підказка вказує, де виділити всі ресурси. Менеджер топології перевіряє цю підказку на відповідність своїй поточній політиці й, залежно від результату, або допускає Pod на вузол, або відхиляє його.
Також шукайте в логах записи, повʼязані з менеджером памʼяті, наприклад, щоб знайти інформацію про оновлення cgroups і cpuset.mems.
Спочатку розгорнімо зразковий Pod Guaranteed з такою специфікацією:
apiVersion: v1
kind: Pod
metadata:
name: guaranteed
spec:
containers:
- name: guaranteed
image: consumer
imagePullPolicy: Never
resources:
limits:
cpu: "2"
memory: 150Gi
requests:
cpu: "2"
memory: 150Gi
command: ["sleep","infinity"]
Далі увійдіть на вузол, де його розгорнуто, і перегляньте файл стану в /var/lib/kubelet/memory_manager_state:
{
"policyName":"Static",
"machineState":{
"0":{
"numberOfAssignments":1,
"memoryMap":{
"hugepages-1Gi":{
"total":0,
"systemReserved":0,
"allocatable":0,
"reserved":0,
"free":0
},
"memory":{
"total":134987354112,
"systemReserved":3221225472,
"allocatable":131766128640,
"reserved":131766128640,
"free":0
}
},
"nodes":[
0,
1
]
},
"1":{
"numberOfAssignments":1,
"memoryMap":{
"hugepages-1Gi":{
"total":0,
"systemReserved":0,
"allocatable":0,
"reserved":0,
"free":0
},
"memory":{
"total":135286722560,
"systemReserved":2252341248,
"allocatable":133034381312,
"reserved":29295144960,
"free":103739236352
}
},
"nodes":[
0,
1
]
}
},
"entries":{
"fa9bdd38-6df9-4cf9-aa67-8c4814da37a8":{
"guaranteed":[
{
"numaAffinity":[
0,
1
],
"type":"memory",
"size":161061273600
}
]
}
},
"checksum":4142013182
}
З файлу стану можна зробити висновок, що Pod закріплено за обома вузлами NUMA, тобто:
"numaAffinity":[
0,
1
],
Термін «закріплений» означає, що споживання памʼяті Podʼом обмежено (через конфігурацію cgroups) цими вузлами NUMA.
Це автоматично означає, що менеджер памʼяті створив нову групу з цих двох вузлів NUMA, тобто вузлів NUMA з індексами 0 і 1.
Щоб проаналізувати ресурси памʼяті, доступні в групі, потрібно підсумувати відповідні записи з вузлів NUMA, що належать до групи.
Наприклад, загальний обсяг вільної «звичайної» памʼяті в групі можна обчислити, додавши вільну памʼять, доступну на кожному вузлі NUMA групи, тобто в розділі "memory" вузла NUMA 0 ("free":0) і вузла NUMA 1 ("free":103739236352). Отже, загальний обсяг вільної «звичайної» памʼяті в цій групі дорівнює 0 + 103739236352 байтів.
Рядок "systemReserved":3221225472 показує, що адміністратор цього вузла зарезервував 3221225472 байти (тобто 3Gi) для kubelet і системних процесів на вузлі NUMA 0 за допомогою прапорця --reserved-memory.
kubelet надає gRPC-сервіс PodResourceLister, щоб уможливити виявлення ресурсів і повʼязаних з ними метаданих. Через його точку доступу gRPC List можна отримати інформацію про зарезервовану памʼять для кожного контейнера, яка міститься в повідомленні protobuf ContainerMemory.
Цю інформацію можна отримати лише для Podʼів класу QoS Guaranteed.
На цій сторінці показано, як увімкнути й налаштувати ротацію сертифікатів для kubelet.
kubelet використовує сертифікати для автентифікації в API Kubernetes. Стандартно ці сертифікати видаються на один рік, щоб їх не потрібно було оновлювати надто часто.
Kubernetes містить ротацію сертифікатів kubelet, яка автоматично генерує новий ключ і запитує новий сертифікат в API Kubernetes, коли строк дії поточного сертифіката наближається до завершення. Щойно новий сертифікат стане доступним, він використовуватиметься для автентифікації зʼєднань з API Kubernetes.
Процес kubelet приймає аргумент --rotate-certificates, який визначає, чи автоматично kubelet запитуватиме новий сертифікат, коли наближається завершення строку дії поточного сертифіката.
Процес kube-controller-manager приймає аргумент --cluster-signing-duration (--experimental-cluster-signing-duration до версії 1.19), який визначає, на який строк видаватимуться сертифікати.
Якщо під час запуску kubelet налаштований на початкове завантаження (за допомогою прапорця --bootstrap-kubeconfig), він використає свій початковий сертифікат, щоб підʼєднатися до API Kubernetes і надіслати запит на підписання сертифіката. Переглянути стан запитів на підписання сертифікатів можна за допомогою:
kubectl get csr
Спочатку запит на підписання сертифіката від kubelet на вузлі матиме статус Pending. Якщо запит відповідає певним критеріям, менеджер контролерів автоматично схвалить його, і він матиме статус Approved. Далі менеджер контролерів підпише сертифікат, виданий на строк, вказаний параметром --cluster-signing-duration, і підписаний сертифікат буде прикріплено до запиту на підписання сертифіката.
kubelet отримає підписаний сертифікат з API Kubernetes і запише його на диск у місце, вказане в --cert-dir. Потім kubelet використовуватиме новий сертифікат для підʼєднання до API Kubernetes.
Коли наближається завершення строку дії підписаного сертифіката, kubelet автоматично надсилає новий запит на підписання сертифіката через API Kubernetes. Це може статися в будь-який момент, коли лишається від 30% до 10% строку дії сертифіката. Менеджер контролерів знову автоматично схвалює запит на сертифікат і прикріплює підписаний сертифікат до запиту на підписання сертифіката. kubelet отримує новий підписаний сертифікат з API Kubernetes і записує його на диск. Потім він оновлює свої зʼєднання з API Kubernetes, щоб перепідʼєднатися з новим сертифікатом.
На цій сторінці показано, як вручну виконати ротацію сертифікатів центру сертифікації (CA).
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Обовʼязково створіть резервну копію теки сертифікатів разом із файлами конфігурації та іншими потрібними файлами.
Цей підхід передбачає роботу панелі управління Kubernetes у конфігурації HA з кількома API-серверами. Також передбачається коректне завершення роботи API-сервера, щоб клієнти могли чисто відʼєднатися від одного API-сервера й підʼєднатися до іншого.
Конфігурації з одним API-сервером будуть недоступні під час перезапуску API-сервера.
Розподіліть нові сертифікати CA й приватні ключі (наприклад, ca.crt, ca.key, front-proxy-ca.crt і front-proxy-ca.key) на всі вузли панелі управління в теку сертифікатів Kubernetes.
Оновіть прапорець --root-ca-file для kube-controller-manager, щоб він містив і старий, і новий CA, а потім перезапустіть kube-controller-manager.
Будь-який ServiceAccount, створений після цього, отримає Secrets, що містять і старий, і новий CA.
Файли, вказані у прапорцях kube-controller-manager --client-ca-file і --cluster-signing-cert-file, не можуть бути наборами CA. Якщо ці прапорці та --root-ca-file вказують на той самий файл ca.crt, який тепер є набором (містить і старий, і новий CA), ви отримаєте помилку. Щоб обійти цю проблему, скопіюйте новий CA в окремий файл і вкажіть цю копію в прапорцях --client-ca-file і --cluster-signing-cert-file. Коли ca.crt більше не буде набором, ви зможете знову вказати ca.crt у цих прапорцях і видалити копію.
Issue 1350 для kubeadm відстежує помилку, через яку kube-controller-manager не може прийняти набір CA.
Зачекайте, поки менеджер контролерів оновить ca.crt у Secrets для ServiceAccount, щоб вони містили і старі, і нові сертифікати CA.
Якщо якісь Podʼи запускаються до того, як API-сервери почнуть використовувати новий CA, нові Podʼи отримають це оновлення й довірятимуть і старим, і новим CA.
Перезапустіть усі Podʼи, що використовують конфігурації всередині кластера (наприклад, kube-proxy, CoreDNS тощо), щоб вони могли використовувати оновлені дані центру сертифікації із Secrets, повʼязаних із ServiceAccounts.
Додайте і старий, і новий CA до файлу, вказаного у прапорцях --client-ca-file і --kubelet-certificate-authority, у конфігурації kube-apiserver.
Додайте і старий, і новий CA до файлу, вказаного у прапорці --client-ca-file, у конфігурації kube-scheduler.
Оновіть сертифікати облікових записів користувачів, замінивши вміст client-certificate-data і client-key-data відповідно.
Докладніше про створення сертифікатів для окремих облікових записів користувачів дивіться в розділі Налаштування сертифікатів для облікових записів користувачів.
Крім того, оновіть розділ certificate-authority-data у файлах kubeconfig, вказавши відповідно закодовані в Base64 дані старого й нового центру сертифікації.
Оновіть прапорець --root-ca-file для Cloud Controller Manager, щоб він містив і старий, і новий CA, а потім перезапустіть cloud-controller-manager.
Виконайте наведені нижче кроки поетапно.
Перезапустіть усі інші агреговані API-сервери або обробники вебхуків, щоб вони довіряли новим сертифікатам CA.
Перезапустіть kubelet, оновивши файл, вказаний у clientCAFile у конфігурації kubelet, і certificate-authority-data у kubelet.conf, щоб використовувати і старий, і новий CA на всіх вузлах.
Якщо ваш kubelet не використовує ротацію клієнтських сертифікатів, оновіть client-certificate-data і client-key-data у kubelet.conf на всіх вузлах, а також файл клієнтського сертифіката kubelet, який зазвичай міститься в /var/lib/kubelet/pki.
Перезапустіть API-сервери із сертифікатами (apiserver.crt, apiserver-kubelet-client.crt і front-proxy-client.crt), підписаними новим CA. Ви можете використовувати наявні або нові приватні ключі. Якщо ви змінили приватні ключі, оновіть їх і в теці сертифікатів Kubernetes.
Оскільки Podʼи у вашому кластері довіряють і старим, і новим CA, буде короткочасне відʼєднання, після якого клієнти Kubernetes у Podʼах перепідʼєднаються до нового API-сервера. Новий API-сервер використовує сертифікат, підписаний новим CA.
Щоб згенерувати сертифікати й приватні ключі для вашого кластера за допомогою інструмента командного рядка `openssl`, дивіться [Сертифікати (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl). Також можна використовувати [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl).
Додайте анотації до DaemonSets і Deployments, щоб запустити заміну Podʼів безпечнішим поетапним способом.
for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do
for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
done
for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do
kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}';
done
done
Щоб обмежити кількість одночасних порушень, яких зазнає ваш застосунок, дивіться [налаштування бюджету порушень Podʼів](/docs/tasks/run-application/configure-pdb/).
Залежно від того, як ви використовуєте StatefulSets, вам також може знадобитися виконати подібну поетапну заміну.
Якщо ваш кластер використовує токени початкового завантаження для приєднання вузлів, оновіть ConfigMap cluster-info у просторі імен kube-public, додавши новий CA.
base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)"
kubectl get cm/cluster-info --namespace kube-public -o yaml | \
/bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
Перевірте роботу кластера.
Перевірте логи компонентів панелі управління, а також kubelet і kube-proxy. Переконайтеся, що ці компоненти не повідомляють про помилки TLS; докладніше дивіться в розділі перегляд логів.
Перевірте логи агрегованих API-серверів і Podʼів, що використовують конфігурацію всередині кластера.
Після успішної перевірки роботи кластера:
Оновіть усі токени ServiceAccount, щоб вони містили лише новий сертифікат CA.
Перезапустіть компоненти панелі управління, вилучивши старий CA з файлів kubeconfig і файлів, вказаних у прапорцях --client-ca-file і --root-ca-file відповідно.
На кожному вузлі перезапустіть kubelet, вилучивши старий CA з файлу, вказаного в прапорці clientCAFile, і з файлу kubeconfig kubelet. Виконуйте це як поетапне оновлення.
Якщо ваш кластер дозволяє внести цю зміну, ви також можете розгорнути її заміною вузлів, а не їх переналаштуванням.
На цій сторінці показано, як створити базовий DaemonSet, який запускає Pod на кожному вузлі кластера Kubernetes. Вона охоплює простий сценарій монтування файлу з хоста, логування його вмісту за допомогою init-контейнера і використання контейнера pause.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Кластер Kubernetes щонайменше з двома вузлами (один вузол панелі управління та один робочий вузол), щоб продемонструвати поведінку DaemonSets.
У цьому завданні створюється базовий DaemonSet, який гарантує, що копія Podʼа планується на кожен вузол. Pod використовуватиме init-контейнер для читання й логування вмісту /etc/machine-id з хоста, а основним контейнером буде контейнер pause, який підтримує роботу Podʼа.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: example-daemonset
spec:
selector:
matchLabels:
app.kubernetes.io/name: example
template:
metadata:
labels:
app.kubernetes.io/name: example
spec:
containers:
- name: pause
image: registry.k8s.io/pause
initContainers:
- name: log-machine-id
image: busybox:1.37
command: ['sh', '-c', 'cat /etc/machine-id > /var/log/machine-id.log']
volumeMounts:
- name: machine-id
mountPath: /etc/machine-id
readOnly: true
- name: log-dir
mountPath: /var/log
volumes:
- name: machine-id
hostPath:
path: /etc/machine-id
type: File
- name: log-dir
hostPath:
path: /var/logСтворіть DaemonSet на основі маніфесту (YAML):
kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml
Після застосування ви можете перевірити, що DaemonSet запускає Pod на кожному вузлі кластера:
kubectl get pods -o wide
Вивід міститиме по одному Podʼу на вузол, наприклад:
NAME READY STATUS RESTARTS AGE IP NODE
example-daemonset-xxxxx 1/1 Running 0 5m x.x.x.x node-1
example-daemonset-yyyyy 1/1 Running 0 5m x.x.x.x node-2
Ви можете переглянути вміст залогованого файлу /etc/machine-id, перевіривши теку логів, змонтовану з хоста:
kubectl exec <pod-name> -- cat /var/log/machine-id.log
Де <pod-name> — назва одного з ваших Podʼів.
Щоб видалити DaemonSet, виконайте цю команду:
kubectl delete --cascade=foreground --ignore-not-found --now daemonsets/example-daemonset
Цей простий приклад DaemonSet знайомить із ключовими компонентами, такими як init-контейнери й томи hostPath, які можна розширювати для складніших сценаріїв. Докладніше дивіться DaemonSet.
На цій сторінці показано, як виконати поетапне оновлення DaemonSet.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
DaemonSet має два типи стратегій оновлення:
OnDelete: Зі стратегією оновлення OnDelete після оновлення шаблону DaemonSet нові Podʼи DaemonSet створюватимуться лише тоді, коли ви вручну видалите старі Podʼи DaemonSet. Така сама поведінка була в DaemonSet у Kubernetes версії 1.5 або раніше.RollingUpdate: Це стандартна стратегія оновлення. Зі стратегією оновлення RollingUpdate після оновлення шаблону DaemonSet старі Podʼи DaemonSet буде завершено, а нові Podʼи DaemonSet буде автоматично створено контрольованим чином. Протягом усього процесу оновлення на кожному вузлі працюватиме щонайбільше один Pod DaemonSet.Щоб увімкнути поетапне оновлення DaemonSet, потрібно встановити .spec.updateStrategy.type у RollingUpdate.
Ви також можете встановити .spec.updateStrategy.rollingUpdate.maxUnavailable (стандартно 1), .spec.minReadySeconds (стандартно 0) та .spec.updateStrategy.rollingUpdate.maxSurge (стандартно 0).
RollingUpdateЦей файл YAML визначає DaemonSet зі стратегією оновлення RollingUpdate:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
# видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
Перевіривши стратегію оновлення в маніфесті DaemonSet, створіть DaemonSet:
kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
Або скористайтесь командою kubectl apply, щоб створити той самий DaemonSet, якщо ви плануєте оновлювати DaemonSet за допомогою kubectl apply.
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
RollingUpdate у DaemonSetПеревірте стратегію оновлення вашого DaemonSet і переконайтеся, що вона встановлена в RollingUpdate:
kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system
Якщо ви ще не створили DaemonSet у системі, натомість перевірте маніфест DaemonSet такою командою:
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
Вивід обох команд має бути таким:
RollingUpdate
Якщо вивід не RollingUpdate, поверніться й відповідно змініть обʼєкт DaemonSet або маніфест.
Будь-які оновлення .spec.template у DaemonSet зі стратегією RollingUpdate запускають поетапне оновлення. Оновімо DaemonSet, застосувавши новий файл YAML. Це можна зробити кількома різними командами kubectl.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# ці tolerations дозволяють запускати DaemonSet на вузлах панелі управління
# видаліть їх, якщо ваші вузли панелі управління не повинні запускати Podʼи
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
Якщо ви оновлюєте DaemonSets за допомогою файлів конфігурації, використовуйте kubectl apply:
kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml
Якщо ви оновлюєте DaemonSets за допомогою імперативних команд, використовуйте kubectl edit :
kubectl edit ds/fluentd-elasticsearch -n kube-system
Якщо вам потрібно оновити лише образ контейнера у шаблоні DaemonSet, тобто
.spec.template.spec.containers[*].image, використовуйте kubectl set image:
kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
Нарешті, спостерігайте за станом розгортання останнього поетапного оновлення DaemonSet:
kubectl rollout status ds/fluentd-elasticsearch -n kube-system
Коли розгортання завершиться, вивід буде подібний до такого:
daemonset "fluentd-elasticsearch" successfully rolled out
Іноді поетапне оновлення DaemonSet може застрягнути. Ось деякі можливі причини:
Розгортання застрягло, оскільки нові Podʼи DaemonSet не можна запланувати щонайменше на один вузол. Таке можливо, коли на вузлі вичерпуються ресурси.
Коли це трапляється, знайдіть вузли, на яких не заплановано Podʼи DaemonSet, порівнявши вивід kubectl get nodes з виводом:
kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
Знайшовши ці вузли, видаліть із них деякі Podʼи, що не належать до DaemonSet, щоб звільнити місце для нових Podʼів DaemonSet.
Якщо останнє оновлення шаблону DaemonSet невдале, наприклад контейнер постійно аварійно завершується (crash looping) або образу контейнера не існує (часто через одруківку), розгортання DaemonSet не просуватиметься.
Щоб виправити це, ще раз оновіть шаблон DaemonSet. Нове розгортання не блокуватиметься попередніми несправними розгортаннями.
Якщо в DaemonSet задано .spec.minReadySeconds, невідповідність годинників між панеллю управління та вузлами не дасть DaemonSet правильно визначати перебіг розгортання.
Видаліть DaemonSet із простору імен:
kubectl delete ds fluentd-elasticsearch -n kube-system
На цій сторінці показано, як виконати відкочування DaemonSet.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж 1.7.Для перевірки версії введіть kubectl version.
Ви вже маєте знати, як виконати поетапне оновлення DaemonSet.
Цей крок можна пропустити, якщо ви хочете лише відкотитися до останньої ревізії.
Виведіть усі ревізії DaemonSet:
kubectl rollout history daemonset <daemonset-name>
Це поверне список ревізій DaemonSet:
daemonsets "<daemonset-name>"
REVISION CHANGE-CAUSE
1 ...
2 ...
...
kubernetes.io/change-cause до його ревізій під час їх створення. Ви можете вказати --record=true у kubectl, щоб записати виконану команду в анотацію причини зміни.Щоб переглянути подробиці конкретної ревізії:
kubectl rollout history daemonset <daemonset-name> --revision=1
Це поверне подробиці цієї ревізії:
daemonsets "<daemonset-name>" with revision #1
Pod Template:
Labels: foo=bar
Containers:
app:
Image: ...
Port: ...
Environment: ...
Mounts: ...
Volumes: ...
# Вкажіть номер ревізії, отриманий на кроці 1, у --to-revision
kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>
Якщо команда виконається успішно, вона поверне:
daemonset "<daemonset-name>" rolled back
--to-revision не вказано, kubectl обирає найновішу ревізію.kubectl rollout undo daemonset наказує серверу почати відкочування DaemonSet. Фактичне відкочування виконується асинхронно всередині панелі управління кластера.
Щоб спостерігати за перебігом відкочування:
kubectl rollout status ds/<daemonset-name>
Коли відкочування завершиться, вивід буде подібний до такого:
daemonset "<daemonset-name>" successfully rolled out
На попередньому кроці kubectl rollout history ви отримали список ревізій DaemonSet. Кожна ревізія зберігається в ресурсі під назвою ControllerRevision.
Щоб побачити, що зберігається в кожній ревізії, знайдіть необроблені ресурси ревізій DaemonSet:
kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>
Це поверне список ControllerRevisions:
NAME CONTROLLER REVISION AGE
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 1 1h
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 2 1h
Кожен ControllerRevision зберігає анотації та шаблон ревізії DaemonSet.
kubectl rollout undo бере конкретний ControllerRevision і замінює шаблон DaemonSet шаблоном, збереженим у ControllerRevision. kubectl rollout undo рівнозначний оновленню шаблону DaemonSet до попередньої ревізії іншими командами, такими як kubectl edit або kubectl apply.
.revision) ControllerRevision, до якого відбулося відкочування, збільшується. Наприклад, якщо в системі є ревізії 1 і 2 і ви відкочуєтеся з ревізії 2 до ревізії 1, ControllerRevision із .revision: 1 стане .revision: 3.На цій сторінці показано, як запускати Podʼи лише на деяких вузлах у складі DaemonSet
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Уявімо, що ви хочете запустити DaemonSet, але ці Podʼи демонів потрібно запускати лише на вузлах із локальним твердотільним сховищем (SSD). Наприклад, Pod може надавати вузлу сервіс кешування, а кеш корисний лише тоді, коли доступне локальне сховище з низькою затримкою.
Додайте мітку ssd=true до вузлів, які мають SSD.
kubectl label nodes example-node-1 example-node-2 ssd=true
Створімо DaemonSet, який розгортатиме Podʼи демонів лише на вузлах з міткою SSD.
Далі використайте nodeSelector, щоб DaemonSet запускав Podʼи лише на вузлах, де мітка ssd має значення "true".
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ssd-driver
labels:
app: nginx
spec:
selector:
matchLabels:
app: ssd-driver-pod
template:
metadata:
labels:
app: ssd-driver-pod
spec:
nodeSelector:
ssd: "true"
containers:
- name: example-container
image: example-imageСтворіть DaemonSet з маніфесту, використовуючи kubectl create або kubectl apply.
Додамо мітку ssd=true ще одному вузлу.
kubectl label nodes example-node-3 ssd=true
Додавання мітки вузлу автоматично спонукає панель управління (а саме контролер DaemonSet) запустити новий Pod демона на цьому вузлі.
kubectl get pods -o wide
Вивід подібний до такого:
NAME READY STATUS RESTARTS AGE IP NODE
<daemonset-name><some-hash-01> 1/1 Running 0 13s ..... example-node-1
<daemonset-name><some-hash-02> 1/1 Running 0 13s ..... example-node-2
<daemonset-name><some-hash-03> 1/1 Running 0 5s ..... example-node-3
This is a stable feature in Kubernetes, and has been since version v1.33. It was first available in the v1.27 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate MultiCIDRServiceAllocator, Kubernetes ignores it but does not report any error.
У цьому документі описано, як розширити наявний діапазон IP-адрес Service, призначений кластеру.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.29.Для перевірки версії введіть kubectl version.
Панель управління забезпечує наявність спеціального обʼєкта ServiceCIDR із загальновідомою назвою kubernetes, який визначає діапазон IP-адрес на основі значення аргументу командного рядка --service-cluster-ip-range для kube-apiserver.
kubectl get servicecidr
NAME CIDRS AGE
kubernetes 10.96.0.0/28 17d
Загальновідомий Service kubernetes, який відкриває Podʼам доступ до точки доступу kube-apiserver, обчислює першу IP-адресу зі стандартного діапазону ServiceCIDR і використовує її як свою кластерну IP-адресу.
kubectl get service kubernetes
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 17d
Стандартний Service у цьому випадку використовує ClusterIP 10.96.0.1, що має відповідний обʼєкт IPAddress.
kubectl get ipaddress 10.96.0.1
NAME PARENTREF
10.96.0.1 services/default/kubernetes
ServiceCIDRs захищені завершувачами, щоб ClusterIP у Service не лишалися без батьківського обʼєкта; завершувач вилучається лише тоді, коли існує інша підмережа з наявними IPAddresses або немає IPAddresses, що належать до цієї підмережі.
Іноді користувачам потрібно збільшити кількість адрес, доступних для Services. Раніше збільшення діапазону Service було операцією з порушенням роботи, яка також могла спричинити втрату даних. Завдяки цій новій можливості користувачам достатньо додати новий ServiceCIDR, щоб збільшити кількість доступних адрес.
У кластері з діапазоном 10.96.0.0/28 для Services доступно лише 2^(32-28) - 2 = 14 IP-адрес. Service kubernetes.default створюється завжди; у цьому прикладі лишається лише 13 можливих Services.
for i in $(seq 1 13); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done
10.96.0.11
10.96.0.5
10.96.0.12
10.96.0.13
10.96.0.14
10.96.0.2
10.96.0.3
10.96.0.4
10.96.0.6
10.96.0.7
10.96.0.8
10.96.0.9
error: failed to create ClusterIP service: Internal error occurred: failed to allocate a serviceIP: range is full
Ви можете збільшити кількість IP-адрес, доступних для Services, створивши новий ServiceCIDR, який розширює наявні або додає нові діапазони IP-адрес.
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: ServiceCIDR
metadata:
name: newcidr1
spec:
cidrs:
- 10.96.0.0/24
EOF
servicecidr.networking.k8s.io/newcidr1 created
і це дозволить створювати нові Services з ClusterIP, вибраними з цього нового діапазону.
for i in $(seq 13 16); do kubectl create service clusterip "test-$i" --tcp 80 -o json | jq -r .spec.clusterIP; done
10.96.0.48
10.96.0.200
10.96.0.121
10.96.0.144
Ви не можете видалити ServiceCIDR, якщо є IPAddresses, які залежать від цього ServiceCIDR.
kubectl delete servicecidr newcidr1
servicecidr.networking.k8s.io "newcidr1" deleted
Kubernetes використовує завершувач на ServiceCIDR, щоб відстежувати цю залежність.
kubectl get servicecidr newcidr1 -o yaml
apiVersion: networking.k8s.io/v1
kind: ServiceCIDR
metadata:
creationTimestamp: "2023-10-12T15:11:07Z"
deletionGracePeriodSeconds: 0
deletionTimestamp: "2023-10-12T15:12:45Z"
finalizers:
- networking.k8s.io/service-cidr-finalizer
name: newcidr1
resourceVersion: "1133"
uid: 5ffd8afe-c78f-4e60-ae76-cec448a8af40
spec:
cidrs:
- 10.96.0.0/24
status:
conditions:
- lastTransitionTime: "2023-10-12T15:12:45Z"
message: There are still IPAddresses referencing the ServiceCIDR, please remove
them or create a new ServiceCIDR
reason: OrphanIPAddress
status: "False"
type: Ready
Видаляючи Services з IP-адресами, які блокують видалення ServiceCIDR,
for i in $(seq 13 16); do kubectl delete service "test-$i" ; done
service "test-13" deleted
service "test-14" deleted
service "test-15" deleted
service "test-16" deleted
панель управління помічає це видалення. Потім панель управління вилучає свій завершувач, і ServiceCIDR, що очікував на видалення, справді буде видалено.
kubectl get servicecidr newcidr1
Error from server (NotFound): servicecidrs.networking.k8s.io "newcidr1" not found
Адміністратори кластера можуть застосовувати політики для контролю створення й зміни ресурсів ServiceCIDR у кластері. Це дає змогу централізовано керувати діапазонами IP-адрес, які використовуються для Services, і запобігає ненавмисним або конфліктним конфігураціям. Kubernetes надає для застосування цих правил такі механізми, як валідаційні політики допуску (Validating Admission Policies).
Іноді адміністратори кластера хочуть обмежити дозволені діапазони або повністю заборонити будь-які зміни діапазонів IP-адрес Service кластера.
Стандартний ServiceCIDR "kubernetes" створюється kube-apiserver для забезпечення узгодженості в кластері й потрібен для роботи кластера, тому його завжди потрібно дозволяти. Щоб ValidatingAdmissionPolicy не обмежувала стандартний ServiceCIDR, додайте таку умову:
matchConditions:
- name: 'exclude-default-servicecidr'
expression: "object.metadata.name != 'kubernetes'"
як у наведених нижче прикладах.
Нижче наведено приклад ValidatingAdmissionPolicy, яка дозволяє створювати ServiceCIDR, лише якщо вони є піддіапазонами заданих діапазонів allowed. (Отже, ця політика дозволить ServiceCIDR з cidrs: ['10.96.1.0/24'] або cidrs: ['2001:db8:0:0:ffff::/80', '10.96.0.0/20'], але не дозволить ServiceCIDR з cidrs: ['172.20.0.0/16'].) Ви можете скопіювати цю політику й змінити значення allowed на відповідне для вашого кластера.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: "servicecidrs.default"
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: ["networking.k8s.io"]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["servicecidrs"]
matchConditions:
- name: 'exclude-default-servicecidr'
expression: "object.metadata.name != 'kubernetes'"
variables:
- name: allowed
expression: "['10.96.0.0/16','2001:db8::/64']"
validations:
- expression: "object.spec.cidrs.all(newCIDR, variables.allowed.exists(allowedCIDR, cidr(allowedCIDR).containsCIDR(newCIDR)))"
# For all CIDRs (newCIDR) listed in the spec.cidrs of the submitted ServiceCIDR
# object, check if there exists at least one CIDR (allowedCIDR) in the `allowed`
# list of the VAP such that the allowedCIDR fully contains the newCIDR.
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
name: "servicecidrs-default-binding"
spec:
policyName: "servicecidrs.default"
validationActions: [Deny,Audit]
Щоб дізнатися більше про CEL і написати власний expression для валідації, дивіться документацію CEL.
Наведений нижче приклад показує, як використовувати ValidatingAdmissionPolicy та її привʼязку, щоб обмежити створення будь-яких нових діапазонів Service CIDR, окрім стандартного ServiceCIDR "kubernetes":
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: "servicecidrs.deny"
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: ["networking.k8s.io"]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["servicecidrs"]
validations:
# Deny changes to all ServiceCIDRs except the default one
- expression: "object.metadata.name == 'kubernetes'"
message: "you can only create or update the default ServiceCIDR"
# Deny changes from all users except kube-apiserver
- expression: "request.userInfo.username == 'system:apiserver' && 'system:masters' in request.userInfo.groups"
message: "you can not create or update ServiceCIDR objects"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
name: "servicecidrs-deny-binding"
spec:
policyName: "servicecidrs.deny"
validationActions: [Deny,Audit]
У цьому документі описано, як перевірити кластери Kubernetes з увімкненим подвійним стеком IPv4/IPv6.
Для перевірки версії введіть kubectl version.
Кожен вузол із подвійним стеком повинен мати виділений один блок IPv4 і один блок IPv6. Перевірте, що діапазони адрес Podʼів IPv4/IPv6 налаштовано, виконавши наведену нижче команду. Замініть назву вузла з прикладу на назву дійсного вузла з подвійним стеком у вашому кластері. У цьому прикладі назва вузла — k8s-linuxpool1-34450317-0:
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}'
10.244.1.0/24
2001:db8::/64
Має бути виділено один блок IPv4 та один блок IPv6.
Перевірте, що на вузлі виявлено інтерфейси IPv4 та IPv6. Замініть назву вузла на назву дійсного вузла з кластера. У цьому прикладі назва вузла — k8s-linuxpool1-34450317-0:
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}'
Hostname: k8s-linuxpool1-34450317-0
InternalIP: 10.0.0.5
InternalIP: 2001:db8:10::5
Перевірте, що Podʼу призначено адреси IPv4 та IPv6. Замініть назву Podʼа на назву дійсного Podʼа у вашому кластері. У цьому прикладі назва Podʼа — pod01:
kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}'
10.244.1.4
2001:db8::4
Ви також можете перевірити IP-адреси Podʼа за допомогою Downward API через fieldPath status.podIPs. Наведений нижче фрагмент показує, як надати IP-адреси Podʼа контейнеру через змінну середовища MY_POD_IPS.
env:
- name: MY_POD_IPS
valueFrom:
fieldRef:
fieldPath: status.podIPs
Наведена нижче команда виводить значення змінної середовища MY_POD_IPS усередині контейнера. Значення — це список, розділений комами, який відповідає адресам IPv4 та IPv6 Podʼа.
kubectl exec -it pod01 -- set | grep MY_POD_IPS
MY_POD_IPS=10.244.1.4,2001:db8::4
IP-адреси Podʼа також записуються в /etc/hosts усередині контейнера. Наведена нижче команда виконує cat для /etc/hosts у Podʼі з подвійним стеком. З виводу можна перевірити адреси IPv4 та IPv6 Podʼа.
kubectl exec -it pod01 -- cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.1.4 pod01
2001:db8::4 pod01
Створіть наведений нижче Service, який явно не визначає .spec.ipFamilyPolicy. Kubernetes призначить Service кластерний IP з першого налаштованого service-cluster-ip-range і встановить .spec.ipFamilyPolicy у SingleStack.
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
app.kubernetes.io/name: MyApp
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
Використайте kubectl, щоб переглянути YAML цього Service.
kubectl get svc my-service -o yaml
Service має .spec.ipFamilyPolicy зі значенням SingleStack і .spec.clusterIP з адресою IPv4 із першого налаштованого діапазону, заданого прапорцем --service-cluster-ip-range у kube-controller-manager.
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: default
spec:
clusterIP: 10.0.217.164
clusterIPs:
- 10.0.217.164
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- port: 80
protocol: TCP
targetPort: 9376
selector:
app.kubernetes.io/name: MyApp
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
Створіть наведений нижче Service, який явно визначає IPv6 як перший елемент масиву .spec.ipFamilies. Kubernetes призначить Service кластерний IP із діапазону IPv6, налаштованого в service-cluster-ip-range, і встановить .spec.ipFamilyPolicy у SingleStack.
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
app.kubernetes.io/name: MyApp
spec:
ipFamilies:
- IPv6
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
Використайте kubectl, щоб переглянути YAML цього Service.
kubectl get svc my-service -o yaml
Service має .spec.ipFamilyPolicy зі значенням SingleStack і .spec.clusterIP з адресою IPv6 із діапазону IPv6, заданого прапорцем --service-cluster-ip-range у kube-controller-manager.
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: MyApp
name: my-service
spec:
clusterIP: 2001:db8:fd00::5118
clusterIPs:
- 2001:db8:fd00::5118
ipFamilies:
- IPv6
ipFamilyPolicy: SingleStack
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app.kubernetes.io/name: MyApp
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
Створіть наведений нижче Service, який явно визначає PreferDualStack у .spec.ipFamilyPolicy. Kubernetes призначить адреси IPv4 та IPv6 (оскільки в цьому кластері ввімкнено подвійний стек) і вибере .spec.ClusterIP зі списку .spec.ClusterIPs на основі сімейства адрес першого елемента масиву .spec.ipFamilies.
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
app.kubernetes.io/name: MyApp
spec:
ipFamilyPolicy: PreferDualStack
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
Команда kubectl get svc показує лише основну IP-адресу в полі CLUSTER-IP.
kubectl get svc -l app.kubernetes.io/name=MyApp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service ClusterIP 10.0.216.242 <none> 80/TCP 5s
Перевірте за допомогою kubectl describe, що Service отримує кластерні IP з блоків адрес IPv4 та IPv6. Потім можна перевірити доступ до сервісу через IP-адреси й порти.
kubectl describe svc -l app.kubernetes.io/name=MyApp
Name: my-service
Namespace: default
Labels: app.kubernetes.io/name=MyApp
Annotations: <none>
Selector: app.kubernetes.io/name=MyApp
Type: ClusterIP
IP Family Policy: PreferDualStack
IP Families: IPv4,IPv6
IP: 10.0.216.242
IPs: 10.0.216.242,2001:db8:fd00::af55
Port: <unset> 80/TCP
TargetPort: 9376/TCP
Endpoints: <none>
Session Affinity: None
Events: <none>
Якщо хмарний провайдер підтримує надання зовнішніх балансувальників навантаження з підтримкою IPv6, створіть наведений нижче Service із PreferDualStack у .spec.ipFamilyPolicy, IPv6 як першим елементом масиву .spec.ipFamilies і полем type зі значенням LoadBalancer.
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
app.kubernetes.io/name: MyApp
spec:
ipFamilyPolicy: PreferDualStack
ipFamilies:
- IPv6
type: LoadBalancer
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
Перевірте Service:
kubectl get svc -l app.kubernetes.io/name=MyApp
Перевірте, що Service отримує адресу CLUSTER-IP із блоку адрес IPv6 разом з EXTERNAL-IP. Потім можна перевірити доступ до сервісу через IP-адресу й порт.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer 2001:db8:fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s
Додавання записів до файлу /etc/hosts у Podʼі дає змогу перевизначити розвʼязання імен хостів на рівні Podʼа, коли DNS та інші варіанти не підходять. Ви можете додавати ці власні записи за допомогою поля HostAliases у PodSpec.
Проєкт Kubernetes рекомендує змінювати конфігурацію DNS за допомогою поля hostAliases (частина .spec Podʼа), а не за допомогою init-контейнера чи інших засобів безпосереднього редагування /etc/hosts. Зміни, внесені іншим способом, kubelet може перезаписати під час створення або перезапуску Podʼа.
Запустіть Pod із Nginx, якому призначено IP-адресу Podʼа:
kubectl run nginx --image nginx
pod/nginx created
Перевірте IP-адресу Podʼа:
kubectl get pods --output=wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
Вміст файлу hosts виглядатиме так:
kubectl exec nginx -- cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.200.0.4 nginx
Стандартно файл hosts містить лише шаблонні записи IPv4 та IPv6, такі як localhost і власне імʼя хоста.
Крім стандартних шаблонних записів, ви можете додати до файлу hosts інші записи. Наприклад, щоб розвʼязувати foo.local, bar.local у 127.0.0.1, а foo.remote, bar.remote у 10.1.2.3, налаштуйте HostAliases для Podʼа в полі .spec.hostAliases:
apiVersion: v1
kind: Pod
metadata:
name: hostaliases-pod
spec:
restartPolicy: Never
hostAliases:
- ip: "127.0.0.1"
hostnames:
- "foo.local"
- "bar.local"
- ip: "10.1.2.3"
hostnames:
- "foo.remote"
- "bar.remote"
containers:
- name: cat-hosts
image: busybox:1.28
command:
- cat
args:
- "/etc/hosts"
Ви можете запустити Pod із такою конфігурацією, виконавши:
kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
pod/hostaliases-pod created
Перегляньте подробиці Podʼа, щоб побачити його адресу IPv4 і статус:
kubectl get pod --output=wide
NAME READY STATUS RESTARTS AGE IP NODE
hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
Вміст файлу hosts виглядає так:
kubectl logs hostaliases-pod
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.200.0.5 hostaliases-pod
# Entries added by HostAliases.
127.0.0.1 foo.local bar.local
10.1.2.3 foo.remote bar.remote
з додатковими записами, вказаними внизу.
kubelet керує файлом hosts для кожного контейнера Podʼа, щоб середовище виконання контейнерів не змінювало цей файл після запуску контейнерів. Історично Kubernetes завжди використовував Docker Engine як середовище виконання контейнерів, а Docker Engine змінював файл /etc/hosts після запуску кожного контейнера.
Поточний Kubernetes може використовувати різні середовища виконання контейнерів; попри це, kubelet керує файлом hosts у кожному контейнері, щоб результат був очікуваним незалежно від середовища виконання контейнерів, яке ви використовуєте.
Уникайте ручних змін файлу hosts усередині контейнера.
Якщо ви вносите ручні зміни до файлу hosts, ці зміни втрачаються, коли контейнер завершує роботу.
This is a stable feature in Kubernetes, and has been since version v1.33. It was first available in the v1.27 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate MultiCIDRServiceAllocator, Kubernetes ignores it but does not report any error.
У цьому документі описано, як переналаштувати стандартні діапазони IP-адрес Service, призначені кластеру.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.33.Для перевірки версії введіть kubectl version.
У цьому документі пояснено, як керувати діапазоном IP-адрес Service у кластері Kubernetes, що також впливає на сімейства IP, які кластер підтримує для Services.
Сімейства IP, доступні для ClusterIP у Service, визначаються прапорцем --service-cluster-ip-range у kube-apiserver. Щоб краще зрозуміти виділення IP-адрес Service, дивіться документацію Відстеження виділення IP-адрес Services.
Починаючи з Kubernetes 1.33, сімейства IP Service, налаштовані для кластера, відображаються в обʼєкті ServiceCIDR з назвою kubernetes. Обʼєкт ServiceCIDR kubernetes створює перший запущений екземпляр kube-apiserver на основі свого налаштованого прапорця --service-cluster-ip-range. Щоб забезпечити узгоджену поведінку кластера, усі екземпляри kube-apiserver мають бути налаштовані з однаковими значеннями --service-cluster-ip-range, які мають відповідати стандартному обʼєкту ServiceCIDR kubernetes.
Переналаштування ServiceCIDR зазвичай належить до однієї з таких категорій:
Розширення наявних ServiceCIDR: Це можна зробити динамічно, додавши нові обʼєкти ServiceCIDR без переналаштування kube-apiserver. Дивіться окрему документацію про Розширення діапазонів IP-адрес Service.
Перетворення з одного стека на подвійний стек зі збереженням первинного ServiceCIDR: Це передбачає додавання вторинного сімейства IP (IPv6 до кластера лише з IPv4 або IPv4 до кластера лише з IPv6) зі збереженням початкового сімейства IP як первинного. Для цього потрібно оновити конфігурацію kube-apiserver і відповідно змінити різні компоненти кластера, які мають працювати з цим додатковим сімейством IP. Серед цих компонентів, зокрема, kube-proxy, CNI або мережевий втулок, реалізації service mesh і сервіси DNS.
Перетворення з подвійного стека на один зі збереженням первинного ServiceCIDR: Це передбачає вилучення вторинного сімейства IP з кластера з подвійним стеком і повернення до одного сімейства IP зі збереженням початкового первинного сімейства IP. Окрім переналаштування компонентів відповідно до нового сімейства IP, може знадобитися розібратися з Services, які явно налаштовані на використання вилученого сімейства IP.
Усе, що призводить до зміни первинного ServiceCIDR: Повна заміна стандартного ServiceCIDR — складна операція. Якщо новий ServiceCIDR не перетинається з наявним, потрібно буде перенумерувати всі наявні Services і змінити Service kubernetes.default. Випадок, коли змінюється ще й первинне сімейство IP, ще складніший і може потребувати зміни кількох компонентів кластера (kubelet, мережевих втулків тощо) відповідно до нового первинного сімейства IP.
Переналаштування стандартного ServiceCIDR потребує ручних дій з боку оператора кластера, адміністратора або програмного забезпечення, що керує життєвим циклом кластера. Зазвичай це такі дії:
--service-cluster-ip-range, указавши нові діапазони IP.kubernetes.default потрібно видалити й створити заново, щоб отримати IP-адресу з нового ServiceCIDR, якщо первинне сімейство IP змінено або замінено іншою мережею.Наведені нижче кроки описують контрольоване переналаштування з повною заміною стандартного ServiceCIDR і повторним створенням Service kubernetes.default:
--service-cluster-ip-range.kubernetes для видалення (він лишатиметься в очікуванні через наявні IP-адреси й завершувачі). Це запобігає новим виділенням зі старого діапазону.kubernetes.default. Новий kube-apiserver створить його заново в новому ServiceCIDR.Цей посібник показує, як встановлювати й створювати розширення для kubectl. Розглядаючи основні команди kubectl як базові будівельні блоки для взаємодії з кластером Kubernetes, адміністратор кластера може вважати втулки засобом використання цих блоків для створення складнішої поведінки. Втулки розширюють kubectl новими підкомандами, додаючи нові й власні можливості, яких немає в основному дистрибутиві kubectl.
Вам потрібен встановлений робочий бінарний файл kubectl.
Втулок — це окремий виконуваний файл, назва якого починається з kubectl-. Щоб установити втулок, перемістіть його виконуваний файл у будь-яке місце у вашому PATH.
Ви також можете шукати й встановлювати втулки kubectl із відкритим кодом за допомогою Krew. Krew — це менеджер втулків, який підтримує спільнота Kubernetes SIG CLI.
kubectl надає команду kubectl plugin list, яка шукає у вашому PATH дійсні виконувані файли втулків. Виконання цієї команди спричиняє обхід усіх файлів у вашому PATH. Усі файли, які є виконуваними й починаються з kubectl-, зʼявляться у виводі цієї команди у тому порядку, в якому вони розташовані у вашому PATH. Для всіх файлів, що починаються з kubectl- і не є виконуваними, буде показано попередження. Також буде показано попередження для всіх дійсних файлів втулків, назви яких перекривають одна одну.
Ви можете використовувати Krew, щоб шукати й встановлювати втулки kubectl з індексу втулків, який підтримує спільнота.
kubectl дозволяє втулкам додавати власні команди створення вигляду kubectl create something: для цього в PATH має бути виконуваний файл kubectl-create-something.
Наразі неможливо створити втулки, які перезаписують наявні команди kubectl або розширюють інші команди, крім create. Наприклад, якщо створити втулок kubectl-version, він ніколи не виконуватиметься, оскільки наявна команда kubectl version завжди матиме пріоритет. Через це обмеження також не можна використовувати втулки для додавання нових підкоманд до наявних команд kubectl. Наприклад, якщо додати підкоманду kubectl attach vm, назвавши втулок kubectl-attach-vm, цей втулок буде проігноровано.
kubectl plugin list показує попередження для всіх дійсних втулків, які намагаються це зробити.
Ви можете написати втулок будь-якою мовою програмування або скриптом, що дозволяє створювати команди командного рядка.
Втулки не потребують встановлення чи попереднього завантаження. Виконувані файли втулків успадковують середовище від бінарного файлу kubectl. Втулок визначає шлях команди, який він реалізує, за своєю назвою. Наприклад, втулок із назвою kubectl-foo надає команду kubectl foo. Виконуваний файл втулка потрібно встановити десь у вашому PATH.
#!/bin/bash
# необовʼязкова обробка аргументів
if [[ "$1" == "version" ]]
then
echo "1.0.0"
exit 0
fi
# необовʼязкова обробка аргументів
if [[ "$1" == "config" ]]
then
echo "$KUBECONFIG"
exit 0
fi
echo "I am a plugin named kubectl-foo"
Щоб використовувати втулок, зробіть його виконуваним:
sudo chmod +x ./kubectl-foo
і помістіть його в будь-яке місце у вашому PATH:
sudo mv ./kubectl-foo /usr/local/bin
Тепер ви можете викликати втулок як команду kubectl:
kubectl foo
I am a plugin named kubectl-foo
Усі аргументи та прапорці передаються виконуваному файлу без змін:
kubectl foo version
1.0.0
Усі змінні середовища також передаються виконуваному файлу без змін:
export KUBECONFIG=~/.kube/config
kubectl foo config
/home/<user>/.kube/config
KUBECONFIG=/etc/kube/config kubectl foo config
/etc/kube/config
Крім того, першим аргументом, який передається втулку, завжди буде повний шлях до місця, де його викликано ($0 дорівнюватиме /usr/local/bin/kubectl-foo у наведеному вище прикладі).
Як видно з наведеного вище прикладу, втулок визначає шлях команди, яку він реалізує, за назвою свого файлу. Усі підкоманди в шляху команди, на яку націлений втулок, розділені дефісом (-). Наприклад, втулок, який має викликатися щоразу, коли користувач виконує команду kubectl foo bar baz, матиме назву файлу kubectl-foo-bar-baz.
Механізм втулків не створює жодних власних, специфічних для втулка значень або змінних середовища для процесу втулка.
Старіший механізм втулків kubectl надавав змінні середовища, такі як KUBECTL_PLUGINS_CURRENT_NAMESPACE; тепер такого немає.
Втулки kubectl мають самостійно розбирати та перевіряти всі передані їм аргументи. Докладніше про бібліотеку Go для авторів втулків дивіться в розділі використання пакунка command line runtime.
Нижче наведено кілька додаткових випадків, коли користувачі викликають ваш втулок із додатковими прапорцями та аргументами. Вони ґрунтуються на втулку kubectl-foo-bar-baz із наведеного вище сценарію.
Якщо ви виконаєте kubectl foo bar baz arg1 --flag=value arg2, механізм втулків kubectl спочатку спробує знайти втулок із найдовшою можливою назвою, у цьому випадку kubectl-foo-bar-baz-arg1. Не знайшовши такого втулка, kubectl вважатиме останнє значення, відокремлене дефісом, аргументом (тут arg1) і спробує знайти наступну найдовшу можливу назву, kubectl-foo-bar-baz. Знайшовши втулок із такою назвою, kubectl викличе його, передаючи всі аргументи й прапорці після назви втулка як аргументи процесу втулка.
Приклад:
# створимо втулок
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz
# встановимо ваш втулок, перемістивши його у теку з $PATH
sudo mv ./kubectl-foo-bar-baz /usr/local/bin
# перевіримо, що kubectl розпізнав ваш втулок
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo-bar-baz
# перевірте, що виклик вашого втулка через команду "kubectl" працює
# навіть тоді, коли користувач передає додаткові аргументи та прапорці
# до виконуваного файлу вашого втулка.
kubectl foo bar baz arg1 --meaningless-flag=true
My first command-line argument was arg1
Як бачите, ваш втулок було знайдено за командою kubectl, вказаною користувачем, а всі додаткові аргументи та прапорці після цього передано виконуваному файлу втулка без змін.
Хоча механізм втулків kubectl використовує дефіс (-) у назвах файлів втулків для розділення послідовності підкоманд, які обробляє втулок, усе ж можна створити команду втулка з дефісами у виклику з командного рядка, використовуючи підкреслення (_) у назві файлу.
Приклад:
# створимо втулок, що містить підкреслення в назві файлу
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar
# перемістимо втулок у теку з $PATH
sudo mv ./kubectl-foo_bar /usr/local/bin
# тепер ви можете викликати свій втулок через kubectl:
kubectl foo-bar
I am a plugin with a dash in my name
Зверніть увагу, що підкреслення в назві файлу втулка не заважає використовувати команди на кшталт kubectl foo_bar. Команду з наведеного вище прикладу можна викликати і з дефісом (-), і з підкресленням (_):
# Ви можете викликати вашу власну команду з дефісом
kubectl foo-bar
I am a plugin with a dash in my name
# Ви також можете викликати свою власну команду з підкресленнями
kubectl foo_bar
I am a plugin with a dash in my name
У вашому PATH може бути кілька втулків з однаковою назвою файлу в різних розташуваннях. Наприклад, якщо PATH має значення PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins, копія втулка kubectl-foo може існувати в /usr/local/bin/plugins і /usr/local/bin/moreplugins, і тоді вивід команди kubectl plugin list буде таким:
PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/plugins/kubectl-foo
/usr/local/bin/moreplugins/kubectl-foo
- warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo
error: one plugin warning was found
У цьому сценарії попередження під /usr/local/bin/moreplugins/kubectl-foo повідомляє, що цей втулок ніколи не буде виконано. Натомість механізм втулків kubectl завжди спершу знайде й виконає файл, який першим трапляється у вашому PATH, тобто /usr/local/bin/plugins/kubectl-foo.
Щоб розвʼязати цю проблему, переконайтеся, що розташування втулка, який ви хочете використовувати з kubectl, завжди стоїть першим у вашому PATH. Наприклад, якщо ви хочете завжди використовувати /usr/local/bin/moreplugins/kubectl-foo під час виклику команди kubectl foo, змініть значення PATH на /usr/local/bin/moreplugins:/usr/local/bin/plugins.
Існує ще один вид перекриття, який може виникнути з назвами файлів втулків. Якщо в PATH користувача є два втулки, kubectl-foo-bar і kubectl-foo-bar-baz, механізм втулків kubectl завжди вибиратиме найдовшу можливу назву втулка для заданої команди користувача. Наведені нижче приклади це пояснюють:
# для заданої команди kubectl завжди вибиратиметься втулок із найдовшою можливою назвою файлу
kubectl foo bar baz
Plugin kubectl-foo-bar-baz is executed
kubectl foo bar
Plugin kubectl-foo-bar is executed
kubectl foo bar baz buz
Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument
kubectl foo bar buz
Plugin kubectl-foo-bar is executed, with "buz" as its first argument
Таке проєктне рішення гарантує, що підкоманди втулка можна за потреби реалізувати в кількох файлах і вкладати їх під «батьківську» команду втулка:
ls ./plugin_command_tree
kubectl-parent
kubectl-parent-subcommand
kubectl-parent-subcommand-subsubcommand
Ви можете скористатися згаданою вище командою kubectl plugin list, щоб переконатися, що kubectl бачить ваш втулок, і перевірити, що немає попереджень, які заважають викликати його як команду kubectl.
kubectl plugin list
The following kubectl-compatible plugins are available:
test/fixtures/pkg/kubectl/plugins/kubectl-foo
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
- warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable
error: 2 plugin warnings were found
Якщо ви пишете втулок для kubectl мовою Go, ви можете скористатися допоміжними бібліотеками cli-runtime.
Ці бібліотеки надають допоміжні засоби для розбору чи оновлення файлу kubeconfig користувача, для виконання запитів у стилі REST до API-сервера або для привʼязування прапорців, повʼязаних із конфігурацією та виводом.
Приклад використання інструментів із репозиторію CLI Runtime дивіться в Sample CLI Plugin.
Якщо ви розробили втулок для інших користувачів, варто подумати, як ви його пакуватимете, розповсюджуватимете й доставлятимете оновлення своїм користувачам.
Krew пропонує кросплатформний спосіб пакування й розповсюдження ваших втулків. Так ви використовуєте єдиний формат пакування для всіх цільових платформ (Linux, Windows, macOS тощо) і доставляєте оновлення своїм користувачам. Krew також підтримує індекс втулків, щоб інші люди могли знайти ваш втулок і встановити його.
Також ви можете використовувати традиційні менеджери пакунків, такі як apt або dnf у Linux, Chocolatey у Windows і Homebrew у macOS. Підійде будь-який менеджер пакунків, який може розмістити нові виконувані файли десь у PATH користувача. Якщо ви як автор втулка обираєте цей варіант, вам також доведеться оновлювати пакунок розповсюдження вашого втулка kubectl на кількох платформах для кожного випуску.
Ви можете опублікувати вихідний код, наприклад як репозиторій Git. Якщо ви обираєте цей варіант, той, хто хоче використовувати цей втулок, має отримати код, налаштувати середовище збірки (якщо потрібна компіляція) і розгорнути втулок. Якщо ви також надаєте скомпільовані пакунки або використовуєте Krew, встановлення стане простішим.
This is a stable feature in Kubernetes, and has been since the 1.14 release. You can no longer toggle this feature (the associated feature gate has been removed).
Kubernetes підтримує виділення та використання застосунками в Podʼі заздалегідь виділених великих сторінок (huge pages). На цій сторінці описано, як користувачі можуть використовувати великі сторінки.
Вузли Kubernetes мають заздалегідь виділити великі сторінки, щоб вузол міг повідомляти про свою місткість великих сторінок.
Вузол може заздалегідь виділяти великі сторінки кількох розмірів; наприклад, такий рядок у /etc/default/grub виділяє 2*1GiB сторінок розміром 1 GiB і 512*2 MiB сторінок розміром 2 MiB:
GRUB_CMDLINE_LINUX="hugepagesz=1G hugepages=2 hugepagesz=2M hugepages=512"
Вузли автоматично виявлять усі ресурси великих сторінок і повідомлять про них як про ресурси, придатні для планування.
Коли ви переглянете опис вузла, ви маєте побачити щось подібне до наведеного нижче в розділах Capacity та Allocatable:
Capacity:
cpu: ...
ephemeral-storage: ...
hugepages-1Gi: 2Gi
hugepages-2Mi: 1Gi
memory: ...
pods: ...
Allocatable:
cpu: ...
ephemeral-storage: ...
hugepages-1Gi: 2Gi
hugepages-2Mi: 1Gi
memory: ...
pods: ...
Великі сторінки можна використовувати через вимоги до ресурсів на рівні контейнера з назвою ресурсу hugepages-<size>, де <size> — найкомпактніше двійкове позначення з цілочисельними значеннями, підтримуваними на конкретному вузлі. Наприклад, якщо вузол підтримує розміри сторінок 2048KiB і 1048576KiB, він надаватиме ресурси, придатні для планування, hugepages-2Mi та hugepages-1Gi. На відміну від CPU або памʼяті, великі сторінки не підтримують надмірне виділення (overcommit). Зверніть увагу, що під час запиту ресурсів великих сторінок також потрібно запитувати ресурси памʼяті або CPU.
Pod може використовувати кілька розмірів великих сторінок в одній специфікації Podʼа. У цьому випадку для всіх монтувань томів потрібно використовувати нотацію medium: HugePages-<hugepagesize>.
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
image: fedora:latest
command:
- sleep
- inf
volumeMounts:
- mountPath: /hugepages-2Mi
name: hugepage-2mi
- mountPath: /hugepages-1Gi
name: hugepage-1gi
resources:
limits:
hugepages-2Mi: 100Mi
hugepages-1Gi: 2Gi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage-2mi
emptyDir:
medium: HugePages-2Mi
- name: hugepage-1gi
emptyDir:
medium: HugePages-1Gi
Pod може використовувати medium: HugePages, лише якщо він запитує великі сторінки одного розміру.
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
image: fedora:latest
command:
- sleep
- inf
volumeMounts:
- mountPath: /hugepages
name: hugepage
resources:
limits:
hugepages-2Mi: 100Mi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage
emptyDir:
medium: HugePages
shmget() із SHM_HUGETLB, мають працювати з допоміжною групою, яка відповідає proc/sys/vm/hugetlb_shm_group.cpu або memory, за допомогою токена hugepages-<size>.Kubernetes містить стабільну підтримку керування GPU (графічними процесорами) AMD і NVIDIA на різних вузлах вашого кластера за допомогою втулків пристроїв.
На цій сторінці описано, як користувачі можуть використовувати GPU, і наведено деякі обмеження реалізації.
Kubernetes реалізує втулки пристроїв, щоб надати Podʼам доступ до спеціалізованих апаратних можливостей, таких як GPU.
Як адміністратору вам потрібно встановити на вузлах драйвери GPU від відповідного постачальника обладнання й запустити відповідний втулок пристроїв від постачальника GPU. Ось кілька посилань на інструкції постачальників:
Після встановлення втулка ваш кластер надає власний ресурс, придатний для планування, наприклад amd.com/gpu або nvidia.com/gpu.
Ви можете використовувати ці GPU у своїх контейнерах, запитуючи власний ресурс GPU так само, як ви запитуєте cpu чи memory. Однак є деякі обмеження щодо того, як вказувати вимоги до ресурсів для власних пристроїв.
GPU слід вказувати лише в розділі limits, що означає:
limits для GPU без requests, оскільки Kubernetes стандартно використовує обмеження як значення запиту.limits, і в requests, але ці два значення мають бути однаковими.requests для GPU без limits.Ось приклад маніфесту для Podʼа, який запитує GPU:
apiVersion: v1
kind: Pod
metadata:
name: example-vector-add
spec:
restartPolicy: OnFailure
containers:
- name: example-vector-add
image: "registry.example/example-vector-add:v42"
resources:
limits:
gpu-vendor.example/example-gpu: 1 # запит на 1 GPU
Якщо різні вузли вашого кластера мають різні типи GPU, ви можете використовувати мітки вузлів і селектори вузлів для планування Podʼів на відповідні вузли.
Наприклад:
# Додайте вузлам мітки з типом прискорювача, який вони мають.
kubectl label nodes node1 accelerator=example-gpu-x100
kubectl label nodes node2 accelerator=other-gpu-k915
Ключ мітки accelerator — лише приклад; за бажання ви можете використовувати інший ключ мітки.
Як адміністратор ви можете автоматично виявляти всі вузли з підтримкою GPU й додавати їм мітки, розгорнувши Kubernetes Node Feature Discovery (NFD). NFD виявляє апаратні можливості, доступні на кожному вузлі кластера Kubernetes. Зазвичай NFD налаштовують оголошувати ці можливості як мітки вузлів, але NFD також може додавати розширені ресурси, анотації та taints вузлів. NFD сумісний з усіма підтримуваними версіями Kubernetes. Стандартно NFD створює мітки можливостей для виявлених можливостей. Адміністратори також можуть використовувати NFD, щоб додавати taints вузлам із певними можливостями, і тоді на цих вузлах можна буде планувати лише Podʼи, що запитують ці можливості.
Вам також потрібен втулок для NFD, який додає відповідні мітки вашим вузлам; це можуть бути загальні мітки або мітки конкретного постачальника. Ваш постачальник GPU може надавати сторонній втулок для NFD; докладніше дивіться в його документації.
apiVersion: v1
kind: Pod
metadata:
name: example-vector-add
spec:
restartPolicy: OnFailure
# Ви можете використовувати спорідненість вузлів Kubernetes, щоб запланувати цей Pod на вузол,
# який надає тип GPU, потрібний його контейнеру для роботи
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "gpu.gpu-vendor.example/installed-memory"
operator: Gt # (більше ніж)
values: ["40535"]
- key: "feature.node.kubernetes.io/pci-10.present" # мітка можливості NFD
values: ["true"] # (необовʼязково) планувати лише на вузли з пристроєм PCI 10
containers:
- name: example-vector-add
image: "registry.example/example-vector-add:v42"
resources:
limits:
gpu-vendor.example/example-gpu: 1 # запит на 1 GPU