Статичні Podʼи керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження за ними з боку API сервера. На відміну від Podʼів, які керуються панеллю управління (наприклад, Deployment), kubelet спостерігає за кожним статичним Podʼом (і перезапускає його у разі невдачі).
Статичні Podʼи завжди привʼязані до одного Kubelet на конкретному вузлі.
Kubelet автоматично намагається створити дзеркальний Pod на сервері Kubernetes API для кожного статичного Podʼа. Це означає, що Podʼи, які запущені на вузлі, є видимими на сервері API, але не можуть бути керовані звідти. Назви Podʼів будуть мати суфікс з іменем хосту вузла відділеним дефісом.
spec статичного Podʼа не може посилатися на інші обʼєкти API (наприклад, ServiceAccount, ConfigMap, Secret, тощо).Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для перевірки версії введіть kubectl version.
На цій сторінці передбачається, що ви використовуєте CRI-O для запуску Podʼів, а також що ваші вузли працюють під управлінням операційної системи Fedora. Інструкції для інших дистрибутивів або встановлень Kubernetes можуть відрізнятися.
Ви можете налаштувати статичний Pod з використанням файлу конфігурації, що зберігається в файловій системі або файлу конфігурації, що зберігається на вебсервері.
Маніфести — це стандартні визначення Podʼів у форматі JSON або YAML в певній теці. Використовуйте поле staticPodPath: <тека> у конфігураційному файлі kubelet, який періодично сканує теку і створює/видаляє статичні Podʼи, коли у цій теці зʼявляються/зникають файли YAML/JSON. Зверніть увагу, що kubelet ігнорує файли, що починаються з крапки при скануванні вказаної теки.
cp kube-apiserver.yaml kube-apiserver.yaml.backup, kubelet прочитає обидва файли і спробує створити статичний Pod з кожного з них. Коли два файли визначають Pod з однаковою назвою, результат є невизначеним і може призвести до того, що застаріла специфікація резервної копії буде тихо застосована замість поточного маніфесту. Якщо ви створюєте резервну копію, зберігайте її поза текою статичних Podʼів (наприклад, у /etc/kubernetes/backup/).Наприклад, так можна запустити простий вебсервер як статичний Pod:
Виберіть вузол, на якому ви хочете запустити статичний Pod. У цьому прикладі це my-node1.
ssh my-node1
Виберіть теку, наприклад /etc/kubernetes/manifests, і помістіть туди визначення Podʼа вебсервера, наприклад, /etc/kubernetes/manifests/static-web.yaml:
# Виконайте цю команду на вузлі, де працює kubelet
mkdir -p /etc/kubernetes/manifests/
cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
EOF
Налаштуйте kubelet на тому вузлі, щоб встановити значення staticPodPath в конфігураційному файлі kubelet. Див. Встановлення параметрів kubelet через конфігураційний файл для отримання додаткової інформації.
Альтернативний і застарілий метод полягає в налаштуванні kubelet на тому вузлі, щоб він шукав маніфести статичного Podʼа локально, використовуючи аргумент командного рядка. Щоб використовувати застарілий підхід, запустіть kubelet з аргументом --pod-manifest-path=/etc/kubernetes/manifests/.
Перезапустіть kubelet. У Fedora ви виконаєте:
# Виконайте цю команду на вузлі, де працює kubelet
systemctl restart kubelet
Kubelet періодично завантажує файл, вказаний аргументом --manifest-url=<URL>,
і розглядає його як файл JSON/YAML, який містить визначення Podʼів.
Подібно до того, як працюють маніфести, розміщені в файловій системі, kubelet
перевіряє маніфест за розкладом. Якщо відбулися зміни в списку статичних
Podʼів, kubelet застосовує їх.
Щоб скористатися цим підходом:
Створіть YAML-файл і збережіть його на веб-сервері, щоб ви могли передати URL цього файлу kubelet.
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
Налаштуйте kubelet на обраному вузлі для використання цього веб-маніфесту,
запустивши його з аргументом --manifest-url=<URL-маніфесту>.
У Fedora відредагуйте /etc/kubernetes/kubelet, щоб додати цей рядок:
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<URL-маніфесту>"
Перезапустіть kubelet. У Fedora ви виконаєте:
# Виконайте цю команду на вузлі, де працює kubelet
systemctl restart kubelet
Після запуску kubelet автоматично запускає всі визначені статичні Podʼи. Оскільки ви визначили статичний Pod і перезапустили kubelet, новий статичний Pod вже має бути запущений.
Ви можете переглянути запущені контейнери (включно зі статичними Podʼами), виконавши (на вузлі):
# Виконайте цю команду на вузлі, де працює kubelet
crictl ps
Вивід може бути наступним:
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
129fd7d382018 docker.io/library/nginx@sha256:... 11 minutes ago Running web 0 34533c6729106
crictl виводить URI образу та контрольну суму SHA-256. NAME буде виглядати більш подібним до: docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31.Ви можете побачити дзеркальний Pod на сервері API:
kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
Мітки зі статичного Podʼа передаються в дзеркальний Pod. Ви можете використовувати ці мітки як зазвичай через селектори, і т.д.
Якщо ви спробуєте використовувати kubectl для видалення дзеркального Podʼа з сервера API, kubelet не видаляє статичний Pod:
kubectl delete pod static-web-my-node1
pod "static-web-my-node1" deleted
Ви побачите, що Pod все ще працює:
kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 4s
Поверніться на вузол, де працює kubelet, і спробуйте вручну зупинити контейнер. Ви побачите, що після певного часу kubelet помітить це та автоматично перезапустить Pod:
# Виконайте ці команди на вузлі, де працює kubelet
crictl stop 129fd7d382018 # замініть на ID вашого контейнера
sleep 20
crictl ps
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
Після того як ви визначите потрібний контейнер, ви можете отримати журнал для цього контейнера за допомогою crictl:
# Виконайте ці команди на вузлі, де працює контейнер
crictl logs <container_id>
10.240.0.48 - - [16/Nov/2022:12:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.48 - - [16/Nov/2022:12:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.48 - - [16/Nove/2022:12:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
Щоб дізнатися більше про те, як налагоджувати за допомогою crictl, відвідайте Налагодження вузлів Kubernetes за допомогою crictl.
Запущений kubelet періодично сканує налаштовану теку (/etc/kubernetes/manifests у нашому прикладі) на предмет змін та додає/видаляє Podʼи при появі/зникненні файлів в цій теці.
# Це передбачає, що ви використовуєте файлову конфігурацію статичних Podʼів
# Виконайте ці команди на вузлі, де працює контейнер
#
mv /etc/kubernetes/manifests/static-web.yaml /tmp
sleep 20
crictl ps
# Ви бачите, що ніякий контейнер nginx не працює
mv /tmp/static-web.yaml /etc/kubernetes/manifests/
sleep 20
crictl ps
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID
f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106
crictlcrictl