Налаштування Podʼів та контейнерів

• 1: Виділення ресурсів памʼяті для контейнерів та Podʼів
• 2: Виділення ресурсів CPU контейнерам та Podʼам
• 3: Налаштування GMSA для Windows Podʼів та контейнерів
• 4: Зміна обсягів CPU та памʼяті, призначених для контейнерів
• 5: Налаштування RunAsUserName для Podʼів та контейнерів Windows
• 6: Створення Podʼа Windows HostProcess
• 7: Налаштування якості обслуговування для Podʼів
• 8: Призначення розширених ресурсів контейнеру
• 9: Налаштування Podʼа для використання тому для зберігання
• 10: Налаштування Podʼа для використання PersistentVolume для зберігання
• 11: Налаштування Pod для використання projected тому для зберігання
• 12: Налаштування контексту безпеки для Podʼа або контейнера
• 13: Налаштування службових облікових записів для Podʼів
• 14: Отримання образів з приватного реєстру
• 15: Налаштування проб життєздатності, готовності та запуску
• 16: Призначення Podʼів на вузли
• 17: Призначення Podʼів на вузли за допомогою спорідненості вузла
• 18: Налаштування ініціалізації Podʼа
• 19: Обробники подій життєвого циклу контейнера
• 20: Налаштування Podʼів для використання ConfigMap
• 21: Поділ простору імен процесів між контейнерами у Podʼі
• 22: Використання простору імен користувача з Podʼом
• 23: Використання тому Image в Pod
• 24: Створення статичних Podʼів
• 25: Конвертація файлу Docker Compose в ресурси Kubernetes
• 26: Забезпечення стандартів безпеки Podʼів шляхом конфігурування вбудованого контролера допуску
• 27: Забезпечення стандартів безпеки Podʼів за допомогою міток простору імен
• 28: Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity

1 - Виділення ресурсів памʼяті для контейнерів та Podʼів

Ця сторінка показує, як вказати запити та ліміти памʼяті для контейнерів. Контейнери гарантовано матимуть стільки памʼяті, скільки вказано у запиті, і не отримають більше, ніж вказано у ліміті.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Кожен вузол у вашому кластері повинен мати принаймні 300 МіБ памʼяті.

Деякі кроки на цій сторінці вимагають запуску служби metrics-server у вашому кластері. Якщо у вас запущено metrics-server, ви можете пропустити ці кроки.

Якщо ви використовуєте Minikube, виконайте таку команду, щоб увімкнути metrics-server:

minikube addons enable metrics-server

Щоб перевірити, чи запущений metrics-server, або інший постачальник API ресурсів метрик (metrics.k8s.io), виконайте таку команду:

kubectl get apiservices

Якщо API ресурсів метрик доступне, у виводі буде міститися посилання на metrics.k8s.io.

NAME
v1beta1.metrics.k8s.io

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були відокремлені від інших ресурсів у вашому кластері.

kubectl create namespace mem-example

Визначення запитів та лімітів памʼяті

Щоб вказати запит памʼяті для Контейнера, включіть поле resources:requests у маніфесті ресурсів Контейнера. Для вказівки ліміти памʼяті включіть resources:limits.

У цьому завданні ви створюєте Pod, який має один Контейнер. У Контейнера вказано запит памʼяті 100 МіБ і ліміти памʼяті 200 МіБ. Ось файл конфігурації для Podʼа:

pods/resource/memory-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Розділ args у файлі конфігурації надає аргументи для Контейнера при його запуску. Аргументи "--vm-bytes", "150M" вказують Контейнеру спробувати виділити 150 МіБ памʼяті.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example

Перевірте, що Контейнер Podʼа працює:

kubectl get pod memory-demo --namespace=mem-example

Перегляньте детальну інформацію про Pod:

kubectl get pod memory-demo --output=yaml --namespace=mem-example

Вивід показує, що один Контейнер у Podʼі має запит памʼяті 100 МіБ та ліміти памʼяті 200 МіБ.

...
resources:
  requests:
    memory: 100Mi
  limits:
    memory: 200Mi
...

Виконайте команду kubectl top, щоб отримати метрики для Podʼа:

kubectl top pod memory-demo --namespace=mem-example

Вивід показує, що Pod використовує приблизно 162,900,000 байт памʼяті, що становить близько 150 МіБ. Це більше, ніж запит Podʼа на 100 МіБ, але в межах ліміти Podʼа на 200 МіБ.

NAME                        CPU(cores)   MEMORY(bytes)
memory-demo                 <something>  162856960

Видаліть свій Pod:

kubectl delete pod memory-demo --namespace=mem-example

Перевищення лімітів памʼяті Контейнера

Контейнер може перевищити свій запит на памʼять, якщо на вузлі є вільна памʼять. Але Контейнер не може використовувати памʼяті більше, ніж його ліміт памʼяті. Якщо Контейнер використовує більше памʼяті, ніж його ліміт, Контейнер стає кандидатом на зупинку роботи. Якщо Контейнер продовжує використовувати памʼять поза своїм лімітом, він зупиняється. Якщо Контейнер може бути перезапущений, kubelet перезапускає його, як із будь-яким іншим типом відмови під час роботи.

У цьому завданні ви створюєте Pod, який намагається виділити більше памʼяті, ніж його ліміт. Ось файл конфігурації для Podʼа, який має один Контейнер з запитом памʼяті 50 МіБ та лімітом памʼяті 100 МіБ:

pods/resource/memory-request-limit-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-2
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-2-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

У розділі args файлу конфігурації видно, що Контейнер спробує використати 250 МіБ памʼяті, що значно перевищує ліміт в 100 МіБ.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-2.yaml --namespace=mem-example

Перегляньте детальну інформацію про Pod:

kubectl get pod memory-demo-2 --namespace=mem-example

На цей момент Контейнер може працювати або бути знищеним. Повторіть попередню команду, доки Контейнер не буде знищено:

NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          24s

Отримайте більш детальний огляд стану Контейнера:

kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example

Вивід показує, що Контейнер був знищений через вичерпання памʼяті (OOM):

lastState:
   terminated:
     containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
     exitCode: 137
     finishedAt: 2017-06-20T20:52:19Z
     reason: OOMKilled
     startedAt: null

Контейнер у цьому завданні може бути перезапущений, тому kubelet перезапускає його. Повторіть цю команду кілька разів, щоб переконатися, що Контейнер постійно знищується та перезапускається:

kubectl get pod memory-demo-2 --namespace=mem-example

Вивід показує, що Контейнер знищується, перезапускається, знищується знову, знову перезапускається і так далі:

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS      RESTARTS   AGE
memory-demo-2   0/1       OOMKilled   1          37s

kubectl get pod memory-demo-2 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-2   1/1       Running   2          40s

Перегляньте детальну інформацію про історію Podʼа:

kubectʼ describe pod лімітомo-2 ʼ-namespace=mem-example

Вивід показує, що Контейнер починається і знову не вдається:

... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff   Back-off restarting failed container

Перегляньте детальну інформацію про вузли вашого кластера:

kubectl describe nodes

Вивід містить запис про знищення Контейнера через умову вичерпання памʼяті:

Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child

Видаліть свій Pod:

kubectl delete pod memory-demo-2 --namespace=mem-example

Визначення запиту памʼяті, що є завеликим для вашого вузла

Запити та ліміт памʼяті повʼязані з Контейнерами, але корисно думати про Pod як про елемент, що має запит та ліміт памʼяті. Запит памʼяті для Podʼа — це сума запитів памʼяті для всіх Контейнерів у Podʼі. Аналогічно, ліміт памʼяті для Podʼа — це сума лімітів всіх Контейнерів у Podʼі.

Планування Podʼа ґрунтується на запитах. Pod планується кзапуску на вузлі лише у разі, якщо вузол має достатньо вільної памʼяті, щоб задовольнити запит памʼяті Podʼа.

У цьому завданні ви створюєте Pod, у якого запит памʼяті настільки великий, що перевищує можливості будь-якого вузла у вашому кластері. Ось файл конфігурації для Podʼа, у якого один Контейнер з запитом на 1000 ГіБ памʼяті, що, ймовірно, перевищує можливості будь-якого вузла у вашому кластері.

pods/resource/memory-request-limit-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-3-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "1000Gi"
      limits:
        memory: "1000Gi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example

Перегляньте статус Podʼа:

kubectl get pod memory-demo-3 --namespace=mem-example

Вивід показує, що статус Podʼа — PENDING. Це означає, що Pod не заплановано для запуску на жодному вузлі, і він залишатиметься у стані PENDING безстроково:

kubectl get pod memory-demo-3 --namespace=mem-example
NAME            READY     STATUS    RESTARTS   AGE
memory-demo-3   0/1       Pending   0          25s

Перегляньте детальну інформацію про Pod, включаючи події:

kubectl describe pod memory-demo-3 --namespace=mem-example

Вивід показує, що Контейнер не може бути запланований через нестачу памʼяті на вузлах:

Events:
  ...  Reason            Message
       ------            -------
  ...  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient memory (3).

Одиниці памʼяті

Ресурс памʼяті вимірюється у байтах. Ви можете виразити памʼять як ціле число або ціле число з одним із наступних суфіксів: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. Наприклад, наступні значення приблизно однакові:

128974848, 129e6, 129M, 123Mi

Видаліть свій Pod:

kubectl delete pod memory-demo-3 --namespace=mem-example

Якщо ви не вказуєте ліміт памʼяті

Якщо ви не вказуєте ліміт памʼяті для Контейнера, відбувається одне з наступного:

• Контейнер не має верхньої межі на кількість використаної памʼяті. Контейнер може використовувати всю доступну памʼять на вузлі, де він працює, що, своєю чергою, може спричинити активацію "OOM Killer". Крім того, в разі активації "OOM Kill" Контейнер без обмежень ресурсів матиме більше шансів на знищення.

• Контейнер працює в просторі імен, який має стандартний ліміт памʼяті, і Контейнер автоматично отримує визначений стандартний ліміт. Адміністратори кластера можуть використовувати LimitRange для зазначення стандартного ліміту памʼяті.

Для чого вказувати запит та ліміт памʼяті

Налаштовуючи запити та ліміти памʼяті для Контейнерів, які працюють у вашому кластері, ви можете ефективно використовувати ресурси памʼяті, доступні на вузлах вашого кластера. Знижуючи запит памʼяті для Podʼа, ви даєте Podʼу хороший шанс на планування. Маючи ліміти памʼяті, який перевищує запит памʼяті, ви досягаєте двох цілей:

• Pod може мати періоди сплеску активності, коли він використовує доступну памʼять.
• Обсяг памʼяті, який Pod може використовувати під час сплесків, обмежений до якогось розумного значення.

Очищення

Видаліть простір імен. Це видалить всі Podʼи, які ви створили для цього завдання:

kubectl delete namespace mem-example

Що далі

Для розробників застосунків

• Призначення ресурсів ЦП для Контейнерів та Podʼів

• Налаштування якості обслуговування для Podʼів

Для адміністраторів кластера

• Налаштування стандартних запитів та обмежень памʼяті для простору імен

• Налаштування стандартних запитів та обмежень ЦП для простору імен

• Налаштування мінімальних та максимальних обмежень памʼяті для простору імен

• Налаштування мінімальних та максимальних обмежень ЦП для простору імен

• Налаштування квот памʼяті та ЦП для простору імен

• Налаштування квоти для Podʼів у просторі імен

• Налаштування квот для обʼєктів API

• Зміна розміру ресурсів ЦП та памʼяті, які призначені для Контейнерів

2 - Виділення ресурсів CPU контейнерам та Podʼам

Ця сторінка показує, як вказати запит та ліміт CPU для контейнера. Контейнери не можуть використовувати більше CPU, ніж налаштований ліміт. При наявності вільного часу процесора контейнера гарантується виділення стільки CPU, скільки він запитує.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Кожен вузол у вашому кластері повинен мати принаймні 1 CPU.

Деякі кроки на цій сторінці вимагають запуску служби metrics-server у вашому кластері. Якщо у вас запущено metrics-server, ви можете пропустити ці кроки.

Якщо ви використовуєте Minikube, виконайте таку команду, щоб увімкнути metrics-server:

minikube addons enable metrics-server

Щоб перевірити, чи запущений metrics-server, або інший постачальник API ресурсів метрик (metrics.k8s.io), виконайте таку команду:

kubectl get apiservices

Якщо API ресурсів метрик доступне, у виводі буде міститися посилання на metrics.k8s.io.

NAME
v1beta1.metrics.k8s.io

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були відокремлені від інших ресурсів у вашому кластері.

kubectl create namespace cpu-example

Визначте запит ЦП та ліміт ЦП

Для вказання запиту ЦП для контейнера включіть поле resources:requests в маніфест ресурсів Контейнера. Щоб вказати ліміт ЦП, включіть resources:limits.

У цьому завданні ви створюєте Pod, у якого є один контейнер. Контейнер має запит на 0,5 CPU та ліміт 1 CPU. Ось файл конфігурації для Podʼа:

pods/resource/cpu-request-limit.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

Секція args у файлі конфігурації надає аргументи для контейнера при його запуску. Аргумент -cpus "2" каже Контейнеру спробувати використовувати 2 CPU.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example

Перевірте, що Pod працює:

kubectl get pod cpu-demo --namespace=cpu-example

Перегляньте детальну інформацію про Pod:

kubectl get pod cpu-demo --output=yaml --namespace=cpu-example

Вивід показує, що один контейнер у Podʼі має запит ЦП 500 міліCPU та ліміт ЦП 1 CPU.

resources:
  limits:
    cpu: "1"
  requests:
    cpu: 500m

Використовуйте kubectl top, щоб отримати метрики для Podʼа:

kubectl top pod cpu-demo --namespace=cpu-example

У цьому прикладі виводу показано, що Pod використовує 974 міліCPU, що незначно менше, ніж ліміт 1 CPU, вказане в конфігурації Podʼа.

NAME                        CPU(cores)   MEMORY(bytes)
cpu-demo                    974m         <something>

Нагадуємо, що, встановивши -cpu "2", ви налаштували контейнер на спробу використати 2 CPU, але контейнер може використовувати лише близько 1 CPU. Використання ЦП контейнером обмежується, оскільки контейнер намагається використовувати більше ресурсів ЦП, ніж його ліміт.

Одиниці ЦП

Ресурс ЦП вимірюється в одиницях ЦП. Одна одиниця ЦП в Kubernetes еквівалентна:

• 1 AWS vCPU
• 1 GCP Core
• 1 Azure vCore
• 1 Hyperthread на процесорі Intel з гіперпотоками

Дозволені дробові значення. Контейнер, який запитує 0,5 ЦП, гарантовано отримує половину ЦП порівняно з контейнером, який запитує 1 ЦП. Ви можете використовувати суфікс m для позначення мілі. Наприклад, 100m ЦП, 100 міліЦП і 0,1 ЦП — це все одне й те саме. Точність, більша за 1m, не допускається.

ЦП завжди запитується як абсолютна кількість, ніколи як відносна кількість; 0.1 — це та сама кількість ЦП на одноядерному, двоядерному або 48-ядерному компʼютері.

Видаліть свій Pod:

kubectl delete pod cpu-demo --namespace=cpu-example

Визначте запит ЦП, який перевищує можливості ваших вузлів

Запити та ліміти ЦП повʼязані з контейнерами, але корисно вважати Pod таким, що має запит ЦП та ліміти. Запит ЦП для Podʼа — це сума запитів ЦП для всіх контейнерів у Podʼі. Так само, ліміти ЦП для Podʼа — це сума обмежень ЦП для всіх контейнерів у Podʼі.

Планування Podʼа базується на запитах. Pod буде запланований для запуску на вузлі тільки у випадку, якщо на вузлі є достатньо ресурсів ЦП для задоволення запиту ЦП Podʼа.

У цьому завданні ви створюєте Pod, який має запит ЦП такий великий, що він перевищує можливості будь-якого вузла у вашому кластері. Ось файл конфігурації для Podʼа, який має один контейнер. Контейнер запитує 100 ЦП, що ймовірно перевищить можливості будь-якого вузла у вашому кластері.

pods/resource/cpu-request-limit-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-2
  namespace: cpu-example
spec:
  containers:
  - name: cpu-demo-ctr-2
    image: vish/stress
    resources:
      limits:
        cpu: "100"
      requests:
        cpu: "100"
    args:
    - -cpus
    - "2"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example

Перегляньте статус Podʼа:

kubectl get pod cpu-demo-2 --namespace=cpu-example

Вивід показує, що статус Podʼа — Pending. Тобто Pod не був запланований для запуску на будь-якому вузлі, і він буде залишатися в стані Pending нескінченно:

NAME         READY     STATUS    RESTARTS   AGE
cpu-demo-2   0/1       Pending   0          7m

Перегляньте детальну інформацію про Pod, включаючи події:

kubectl describe pod cpu-demo-2 --namespace=cpu-example

Вивід показує, що контейнер не може бути запланований через недостатні ресурси ЦП на вузлах:

Events:
  Reason                        Message
  ------                        -------
  FailedScheduling      No nodes are available that match all of the following predicates:: Insufficient cpu (3).

Видаліть свій Pod:

kubectl delete pod cpu-demo-2 --namespace=cpu-example

Якщо ви не вказуєте ліміт ЦП

Якщо ви не вказуєте ліміт ЦП для контейнера, то застосовується одне з наступного:

• Контейнер не має верхньої межі ресурсів ЦП, які він може використовувати. Контейнер може використовувати всі доступні ресурси ЦП на вузлі, на якому він працює.

• Контейнер працює в просторі імен, який має стандартний ліміт ЦП, і контейнеру автоматично призначається цей стандартний ліміт. Адміністратори кластера можуть використовувати LimitRange для зазначення стандартних значень лімітів ЦП.

Якщо ви вказуєте ліміт ЦП, але не вказуєте запит ЦП

Якщо ви вказуєте ліміт ЦП для контейнера, але не вказуєте запит ЦП, Kubernetes автоматично призначає запит ЦП, який збігається з лімітом. Аналогічно, якщо контейнер вказує свій власний ліміт памʼяті, але не вказує запит памʼяті, Kubernetes автоматично призначає запит памʼяті, який збігається з лімітом.

Для чого вказувати запит та ліміт ЦП

Налаштувавши запити та ліміти ЦП контейнерів, що працюють у вашому кластері, ви можете ефективно використовувати доступні ресурси ЦП на вузлах вашого кластера. Зберігаючи низький запит ЦП для Podʼа, ви забезпечуєте хороші шанси на його планування. Маючи ліміти ЦП, який перевищує запит ЦП, ви досягаєте двох речей:

• Pod може мати періоди підвищеної активності, коли він використовує доступні ресурси ЦП.
• Кількість ресурсів ЦП, які Pod може використовувати під час такої активності, обмежена розумною кількістю.

Очищення

Видаліть ваш простір імен:

kubectl delete namespace cpu-example

Що далі

Для розробників застосунків

• Призначення ресурсів памʼяті контейнерам та Podʼам
• Налаштування якості обслуговування для Podʼів

Для адміністраторів кластерів

• Налаштування стандартних запитів та лімітів памʼяті для простору імен
• Налаштування стандартних запитів та лімітів ЦП для простору імен
• Налаштування мінімальних та максимальних лімітів памʼяті для простору імен
• Налаштування мінімальних та максимальних лімітів ЦП для простору імен
• Налаштування квот на памʼять та ЦП для простору імен
• Налаштування квоти для Podʼів у просторі імен
• Налаштування квот для API-обʼєктів
• Зміна розміру ресурсів ЦП та памʼяті, призначених контейнерам

3 - Налаштування GMSA для Windows Podʼів та контейнерів

Ця сторінка показує, як налаштувати Group Managed Service Accounts (GMSA) для Podʼів та контейнерів, які будуть запущені на вузлах Windows. Group Managed Service Accounts це специфічний тип облікового запису Active Directory, який забезпечує автоматичне управління паролями, спрощене управління іменами служб (SPN) та можливість делегування управління іншим адміністраторам на кількох серверах.

У Kubernetes специфікації облікових даних GMSA налаштовуються на рівні кластера Kubernetes як Custom Resources. Windows Podʼи, також як і окремі контейнери в Podʼі, можуть бути налаштовані для використання GMSA для доменних функцій (наприклад, автентифікація Kerberos) при взаємодії з іншими службами Windows.

Перш ніж ви розпочнете

Вам необхідно мати кластер Kubernetes і інструмент командного рядка kubectl, налаштований для керування з вашим кластером. Очікується, що в кластері будуть вузли Windows. Цей розділ охоплює набір початкових кроків, необхідних один раз для кожного кластера:

Встановлення CRD для GMSACredentialSpec

CustomResourceDefinition(CRD) для ресурсів специфікації облікових даних GMSA потрібно налаштувати на кластері, щоб визначити тип настроюваного ресурсу GMSACredentialSpec. Завантажте GMSA CRD YAML і збережіть як gmsa-crd.yaml. Далі встановіть CRD за допомогою kubectl apply -f gmsa-crd.yaml.

Встановлення вебхуків для перевірки користувачів GMSA

Два вебхуки потрібно налаштувати на кластері Kubernetes для заповнення та перевірки посилань на специфікації облікових даних GMSA на рівні Podʼа або контейнера:

1. Модифікаційний вебхук, який розширює посилання на GMSAs (за іменем зі специфікації Podʼа) до повної специфікації облікових даних у форматі JSON у специфікації Podʼа.

2. Валідаційний вебхук забезпечує, що всі посилання на GMSAs уповноважені для використання обліковим записом служби Podʼа.

Встановлення зазначених вище вебхуків та повʼязаних обʼєктів вимагає наступних кроків:

1. Створіть пару ключів сертифікатів (яка буде використовуватися для забезпечення звʼязку контейнера вебхука з кластером)

2. Встановіть Secret із вищезазначеним сертифікатом.

3. Створіть Deployment для основної логіки вебхука.

4. Створіть конфігурації валідаційного та модифікаційного вебхуків, посилаючись на Deployment.

Скрипт можна використовувати для розгортання та налаштування вебхуків GMSA та повʼязаних з ними обʼєктів, зазначених вище. Скрипт можна запускати з опцією --dry-run=server, щоб ви могли переглянути зміни, які будуть внесені в ваш кластер.

YAML шаблон, що використовується скриптом, також може бути використаний для ручного розгортання вебхуків та повʼязаних обʼєктів (з відповідними замінами параметрів)

Налаштування GMSA та вузлів Windows в Active Directory

Перш ніж Podʼи в Kubernetes можуть бути налаштовані на використання GMSA, необхідно провести налаштування бажаних GMSA в Active Directory, як описано в документації Windows GMSA. Вузли робочих станцій Windows (які є частиною кластера Kubernetes) повинні бути налаштовані в Active Directory для доступу до секретних облікових даних, що повʼязані з бажаним GMSA, як описано в документації Windows GMSA.

Створення ресурсів GMSA Credential Spec

Після встановлення CRD GMSACredentialSpec (як описано раніше), можна налаштувати власні ресурси, що містять специфікації облікових даних GMSA. Специфікація облікових даних GMSA не містить конфіденційні або секретні дані. Це інформація, яку контейнерне середовище може використовувати для опису бажаної GMSA контейнера для Windows. Специфікації облікових даних GMSA можуть бути створені у форматі YAML за допомогою утиліти сценарію PowerShell.

Ось кроки для створення YAML-файлу специфікації облікових даних GMSA вручну у форматі JSON і подальше його конвертування:

1. Імпортуйте модуль CredentialSpec module: ipmo CredentialSpec.psm1.

2. Створіть специфікацію облікових даних у форматі JSON за допомогою команди New-CredentialSpec. Щоб створити специфікацію облікових даних GMSA з іменем WebApp1, викличте New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer).

3. Використайте команду Get-CredentialSpec, щоб показати шлях до файлу JSON.

4. Конвертуйте файл credspec з формату JSON у YAML та застосуйте необхідні заголовкові поля apiVersion, kind, metadata та credspec, щоб зробити його специфікацією GMSACredentialSpec, яку можна налаштувати в Kubernetes.

Наступна конфігурація YAML описує специфікацію облікових даних GMSA з іменем gmsa-WebApp1:

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-WebApp1  # Це довільне імʼя, але воно буде використовуватися як посилання
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: WebApp1   # Імʼя користувача облікового запису GMSA
      Scope: CONTOSO  # Імʼя домену NETBIOS
    - Name: WebApp1   # Імʼя користувача облікового запису GMSA
      Scope: contoso.com # Імʼя домену DNS
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: contoso.com  # Імʼя домену DNS
    DnsTreeName: contoso.com # Корінь імені домену DNS
    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # GUID для Domain
    MachineAccountName: WebApp1 # Імʼя користувача облікового запису GMSA
    NetBiosName: CONTOSO  # Імʼя домену NETBIOS
    Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID для Domain

Вищезазначений ресурс специфікації облікових даних може бути збережений як gmsa-Webapp1-credspec.yaml і застосований до кластера за допомогою: kubectl apply -f gmsa-Webapp1-credspec.yaml.

Налаштування ролі кластера для включення RBAC у конкретні специфікації облікових даних GMSA

Для кожного ресурсу специфікації облікових даних GMSA потрібно визначити роль в кластері. Це авторизує дію use ("використовувати") на конкретному ресурсі GMSA певним субʼєктом, який, як правило, є службовим обліковим записом. Наведений нижче приклад показує роль в кластері, яка авторизує використання специфікації облікових даних gmsa-WebApp1 зверху. Збережіть файл як gmsa-webapp1-role.yaml і застосуйте його за допомогою kubectl apply -f gmsa-webapp1-role.yaml.

# Створення ролі для читання credspec
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["gmsa-WebApp1"]

Призначення ролі службовому обліковому запису для використання конкретних специфікацій облікових даних GMSA

Службовий обліковий запис (з якими будуть налаштовані Podʼи) повинен бути привʼязаний до ролі в кластері, створеної вище. Це авторизує службовий обліковий запис використовувати бажаний ресурс специфікації облікових даних GMSA. Нижче показано, як стандартний службовий обліковий запис привʼязується до ролі в кластера webapp1-role для використання ресурсу специфікації облікових даних gmsa-WebApp1, створеного вище.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-gmsa-WebApp1
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: webapp1-role
  apiGroup: rbac.authorization.k8s.io

Налаштування посилання на специфікацію облікових даних GMSA в специфікації Pod

Поле securityContext.windowsOptions.gmsaCredentialSpecName у специфікації Pod використовується для вказівки посилань на бажані ресурси специфікації облікових даних GMSA в специфікаціях Pod. Це налаштовує всі контейнери в специфікації Pod на використання вказаного GMSA. Нижче наведено приклад специфікації Pod з анотацією, заповненою для посилання на gmsa-WebApp1:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: gmsa-webapp1
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
      nodeSelector:
        kubernetes.io/os: windows

Індивідуальні контейнери в специфікації Pod також можуть вказати бажану специфікацію облікових даних GMSA, використовуючи поле securityContext.windowsOptions.gmsaCredentialSpecName на рівні окремого контейнера. Наприклад:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
        securityContext:
          windowsOptions:
            gmsaCredentialSpecName: gmsa-Webapp1
      nodeSelector:
        kubernetes.io/os: windows

Під час застосування специфікацій Pod з заповненими полями GMSA (як описано вище) в кластері відбувається наступна послідовність подій:

1. Модифікаційний вебхук розвʼязує та розширює всі посилання на ресурси специфікації облікових даних GMSA до вмісту специфікації облікових даних GMSA.

2. Валідаційний вебхук переконується, що обліковий запис служби, повʼязаний з Pod, авторизований для дії use на вказаній специфікації облікових даних GMSA.

3. Контейнерне середовище налаштовує кожен контейнер Windows із вказаною специфікацією облікових даних GMSA, щоб контейнер міг прийняти елемент GMSA в Active Directory та отримати доступ до служб в домені, використовуючи цей елемент.

Автентифікація на мережевих ресурсах за допомогою імені хосту або повного доменного імені

Якщо ви маєте проблеми з підключенням до SMB-ресурсів з Podʼів за допомогою імені хосту або повного доменного імені, але можете отримати доступ до ресурсів за їх адресою IPv4, переконайтеся, що встановлений наступний ключ реєстру на вузлах Windows.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1

Після цього потрібно перестворити Podʼи, щоб вони врахували зміни в поведінці. Додаткову інформацію про те, як використовується цей ключ реєстру, можна знайти тут.

Усунення несправностей

Якщо у вас виникають труднощі з налаштуванням роботи GMSA в вашому середовищі, існують кілька кроків усунення несправностей, які ви можете виконати.

Спочатку переконайтеся, що credspec був переданий до Podʼа. Для цього вам потрібно виконати команду exec в одному з ваших Podʼів і перевірити вивід команди nltest.exe /parentdomain.

У наступному прикладі Pod не отримав credspec правильно:

kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe

Результат команди nltest.exe /parentdomain показує наступну помилку:

Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

Якщо ваш Pod отримав credspec правильно, наступним кроком буде перевірка звʼязку з доменом. Спочатку, зсередини вашого Podʼа, виконайте nslookup, щоб знайти корінь вашого домену.

Це дозволить нам визначити 3 речі:

1. Pod може досягти контролера домену (DC).
2. Контролер домену (DC) може досягти Podʼа.
3. DNS працює правильно.

Якщо тест DNS та комунікації успішний, наступним буде перевірка, чи Pod встановив захищений канал звʼязку з доменом. Для цього, знову ж таки, виконайте команду exec в вашому Podʼі та запустіть команду nltest.exe /query.

nltest.exe /query

Результат буде наступним:

I_NetLogonControl failed: Статус = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

Це говорить нам те, що з якоїсь причини Pod не зміг увійти в домен, використовуючи обліковий запис, вказаний у credspec. Ви можете спробувати полагодити захищений канал за допомогою наступного:

nltest /sc_reset:domain.example

Якщо команда успішна, ви побачите подібний вивід:

Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

Якщо дії вище виправили помилку, ви можете автоматизувати цей крок, додавши наступний виклик у час життєвого циклу до специфікації вашого Podʼа. Якщо це не виправило помилку, вам потрібно перевірити ваш credspec ще раз та підтвердити, що він правильний та повний.

        image: registry.domain.example/iis-auth:1809v1
        lifecycle:
          postStart:
            exec:
              command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
        imagePullPolicy: IfNotPresent

Якщо ви додасте розділ lifecycle до специфікації вашого Podʼа, Pod виконає вказані команди для перезапуску служби netlogon до того, як команда nltest.exe /query вийде без помилок.

4 - Зміна обсягів CPU та памʼяті, призначених для контейнерів

Ця сторінка передбачає, що ви обізнані з Якістю обслуговування для Podʼів Kubernetes.

Ця сторінка показує, як змінити обсяги CPU та памʼяті, призначені для контейнерів працюючого Podʼа без перезапуску самого Podʼа або його контейнерів. Вузол Kubernetes виділяє ресурси для Podʼа на основі його запитів, і обмежує використання ресурсів Podʼа на основі лімітів, вказаних у контейнерах Podʼа.

Зміна розподілу ресурсів для запущеного Podʼа вимагає, що функціональна можливість InPlacePodVerticalScaling має бути увімкнено. Альтернативою може бути видалення Podʼа і ввімкнення параметра, щоб workload controller створив новий Pod з іншими вимогами до ресурсів.

Для зміни ресурсів Podʼа на місці:

• Ресурси запитів та лімітів контейнера є змінними для ресурсів CPU та памʼяті.
• Поле allocatedResources у containerStatuses статусу Podʼа відображає ресурси, виділені контейнерам Podʼа.
• Поле resources у containerStatuses статусу Podʼа відображає фактичні ресурси запитів та лімітів, які налаштовані на запущених контейнерах відповідно до звіту контейнерного середовища.
• Поле resize у статусі Podʼа показує статус останнього запиту очікуваної зміни розміру. Воно може мати наступні значення:
  • Proposed: Це значення показує, що було отримано підтвердження запиту на зміну розміру та що запит був перевірений та зареєстрований.
  • InProgress: Це значення вказує, що вузол прийняв запит на зміну розміру та знаходиться у процесі застосування його до контейнерів Podʼа.
  • Deferred: Це значення означає, що запитаної зміни розміру наразі не можна виконати, і вузол буде спробувати її виконати пізніше. Зміна розміру може бути виконана, коли інші Podʼи покинуть і звільнять ресурси вузла.
  • Infeasible: це сигнал того, що вузол не може задовольнити запит на зміну розміру. Це може статися, якщо запит на зміну розміру перевищує максимальні ресурси, які вузол може виділити для Podʼа.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Має бути увімкнено функціональну можливість InPlacePodVerticalScaling для вашої панелі управління і для всіх вузлів вашого кластера.

Політики зміни розміру контейнера

Політики зміни розміру дозволяють більш детально керувати тим, як контейнери Podʼа змінюють свої ресурси CPU та памʼяті. Наприклад, застосунок з контейнера може використовувати ресурси CPU, змінені без перезапуску, але зміна памʼяті може вимагати перезапуску застосунку та відповідно контейнерів.

Для активації цього користувачам дозволяється вказати resizePolicy у специфікації контейнера. Наступні політики перезапуску можна вказати для зміни розміру CPU та памʼяті:

• NotRequired: Змінити ресурси контейнера під час його роботи.
• RestartContainer: Перезапустити контейнер та застосувати нові ресурси після перезапуску.

Якщо resizePolicy[*].restartPolicy не вказано, воно стандартно встановлюється в NotRequired.

У наведеному нижче прикладі Podʼа CPU контейнера може бути змінено без перезапуску, але змінювання памʼяті вимагає перезапуску контейнера.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Створення Podʼа із запитами та лімітами ресурсів

Ви можете створити Guaranteed або Burstable клас якості обслуговування Podʼу, вказавши запити та/або ліміти для контейнерів Podʼа.

Розгляньте наступний маніфест для Podʼа, який має один контейнер.

pods/qos/qos-pod-5.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-5
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr-5
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Створіть Pod у просторі імен qos-example:

kubectl create namespace qos-example
kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-5.yaml

Цей Pod класифікується як Pod класу якості обслуговування Guaranteed, і має запит 700 мілі CPU та 200 мегабайтів памʼяті.

Перегляньте детальну інформацію про Pod:

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

Також погляньте, що значення resizePolicy[*].restartPolicy типово встановлено в NotRequired, що вказує, що CPU та памʼять можна змінити, поки контейнер працює.

spec:
  containers:
    ...
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
...
  containerStatuses:
...
    name: qos-demo-ctr-5
    ready: true
...
    allocatedResources:
      cpu: 700m
      memory: 200Mi
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    restartCount: 0
    started: true
...
  qosClass: Guaranteed

Оновлення ресурсів Podʼа

Скажімо, вимоги до CPU зросли, і тепер потрібно 0.8 CPU. Це можна вказати вручну, або визначити і застосувати програмно, наприклад, за допомогою таких засобів, як VerticalPodAutoscaler (VPA).

Тепер відредагуйте контейнер Podʼа, встановивши як запити, так і ліміти CPU на 800m:

kubectl -n qos-example patch pod qos-demo-5 --patch '{"spec":{"containers":[{"name":"qos-demo-ctr-5", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

Отримайте докладну інформацію про Pod після внесення змін.

kubectl get pod qos-demo-5 --output=yaml --namespace=qos-example

Специфікація Podʼа нижче показує оновлені запити та ліміти CPU.

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
...
  containerStatuses:
...
    allocatedResources:
      cpu: 800m
      memory: 200Mi
    resources:
      limits:
        cpu: 800m
        memory: 200Mi
      requests:
        cpu: 800m
        memory: 200Mi
    restartCount: 0
    started: true

Зверніть увагу, що значення allocatedResources були оновлені, щоб відображати нові бажані запити CPU. Це вказує на те, що вузол зміг забезпечити потреби у збільшених ресурсах CPU.

У статусі контейнера оновлені значення ресурсів CPU показують, що нові CPU ресурси були застосовані. Значення restartCount контейнера залишається без змін, що вказує на те, що ресурси CPU контейнера були змінені без перезапуску контейнера.

Очищення

Видаліть ваш простір імен:

kubectl delete namespace qos-example

Для розробників застосунків

• Призначення ресурсів памʼяті для контейнерів та Podʼів

• Призначення ресурсів CPU для контейнерів та Podʼів

Для адміністраторів кластерів

• Налаштування стандартних запитів та лімітів памʼяті для простору імен

• Налаштування стандартних запитів та лімітів CPU для простору імен

• Налаштування мінімальних та максимальних лімітів памʼяті для простору імен

• Налаштування мінімальних та максимальних лімітів CPU для простору імен

• Налаштування квот памʼяті та CPU для простору імен

5 - Налаштування RunAsUserName для Podʼів та контейнерів Windows

Ця сторінка показує, як використовувати параметр runAsUserName для Podʼів та контейнерів, які будуть запущені на вузлах Windows. Це приблизно еквівалент параметра runAsUser, який використовується для Linux, і дозволяє виконувати програми в контейнері від імені іншого імені користувача, ніж типово.

Перш ніж ви розпочнете

Вам потрібно мати кластер Kubernetes, а також інструмент командного рядка kubectl повинен бути налаштований для взаємодії з вашим кластером. Очікується, що в кластері будуть використовуватися вузли Windows, де будуть запускатися Podʼи з контейнерами, що виконують робочі навантаження у Windows.

Встановлення імені користувача для Podʼа

Щоб вказати імʼя користувача, з яким потрібно виконати процеси контейнера Podʼа, включіть поле securityContext (PodSecurityContext) в специфікацію Podʼа, а всередині нього — поле windowsOptions (WindowsSecurityContextOptions), що містить поле runAsUserName.

Опції безпеки Windows, які ви вказуєте для Podʼа, застосовуються до всіх контейнерів та контейнерів ініціалізації у Podʼі.

Ось конфігураційний файл для Podʼа Windows зі встановленим полем runAsUserName:

windows/run-as-username-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
    kubernetes.io/os: windows

Створіть Pod:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml

Перевірте, що Контейнер Podʼа працює:

kubectl get pod run-as-username-pod-demo

Отримайте доступ до оболонки контейнера:

kubectl exec -it run-as-username-pod-demo -- powershell

Перевірте, що оболонка працює від імені відповідного користувача:

echo $env:USERNAME

Вивід повинен бути:

ContainerUser

Встановлення імені користувача для контейнера

Щоб вказати імʼя користувача, з яким потрібно виконати процеси контейнера, включіть поле securityContext (SecurityContext) у маніфесті контейнера, а всередині нього — поле windowsOptions (WindowsSecurityContextOptions), що містить поле runAsUserName.

Опції безпеки Windows, які ви вказуєте для контейнера, застосовуються тільки до цього окремого контейнера, і вони перевизначають налаштування, зроблені на рівні Podʼа.

Ось конфігураційний файл для Podʼа, який має один Контейнер, а поле runAsUserName встановлене на рівні Podʼа та на рівні Контейнера:

windows/run-as-username-container.yaml

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-container-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
    securityContext:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
    kubernetes.io/os: windows

Створіть Pod:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml

Перевірте, що Контейнер Podʼа працює:

kubectl get pod run-as-username-container-demo

Отримайте доступ до оболонки контейнера:

kubectl exec -it run-as-username-container-demo -- powershell

Перевірте, що оболонка працює від імені відповідного користувача (того, який встановлений на рівні контейнера):

echo $env:USERNAME

Вивід повинен бути:

ContainerAdministrator

Обмеження імен користувачів Windows

Для використання цієї функції значення, встановлене у полі runAsUserName, повинно бути дійсним імʼям користувача. Воно повинно мати наступний формат: DOMAIN\USER, де DOMAIN\ є необовʼязковим. Імена користувачів Windows регістронезалежні. Крім того, існують деякі обмеження стосовно DOMAIN та USER:

• Поле runAsUserName не може бути порожнім і не може містити керуючі символи (ASCII значення: 0x00-0x1F, 0x7F)
• DOMAIN може бути або NetBios-імʼям, або DNS-імʼям, кожне з власними обмеженнями:
  • NetBios імена: максимум 15 символів, не можуть починатися з . (крапка), і не можуть містити наступні символи: \ / : * ? " < > |
  • DNS-імена: максимум 255 символів, містять тільки буквено-цифрові символи, крапки та дефіси, і не можуть починатися або закінчуватися . (крапка) або - (дефіс).
• USER може мати не більше 20 символів, не може містити тільки крапки або пробіли, і не може містити наступні символи: " / \ [ ] : ; | = , + * ? < > @.

Приклади припустимих значень для поля runAsUserName: ContainerAdministrator, ContainerUser, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\LOCAL SERVICE.

Для отримання додаткової інформації про ці обмеження, перевірте тут та тут.

Що далі

• Посібник з планування контейнерів Windows в Kubernetes
• Управління ідентифікацією робочого навантаження за допомогою групових керованих облікових записів служб (GMSA)
• Налаштування GMSA для Podʼів та контейнерів Windows

6 - Створення Podʼа Windows HostProcess

Windows HostProcess контейнери дозволяють вам запускати контейнеризовані робочі навантаження на хості Windows. Ці контейнери працюють як звичайні процеси, але мають доступ до мережевого простору імен хосту, сховища та пристроїв, коли надані відповідні права користувача. Контейнери HostProcess можуть бути використані для розгортання мережевих втулків, сховищ конфігурацій, пристроїв, kube-proxy та інших компонентів на вузлах Windows без потреби у власних проксі або безпосереднього встановлення служб хосту.

Адміністративні завдання, такі як встановлення патчів безпеки, збір подій логів тощо, можна виконувати без потреби входу операторів кластера на кожен вузол Windows. Контейнери HostProcess можуть працювати як будь-який користувач, що доступний на хості або в домені машини хосту, що дозволяє адміністраторам обмежити доступ до ресурсів через дозволи користувача. Хоча і не підтримуються ізоляція файлової системи або процесу, при запуску контейнера на хості створюється новий том, щоб надати йому чисте та обʼєднане робоче середовище. Контейнери HostProcess також можуть бути побудовані на базі наявних образів базової системи Windows і не успадковують ті ж вимоги сумісності як контейнери Windows server, що означає, що версія базового образу не повинна відповідати версії хосту. Однак рекомендується використовувати ту ж версію базового образу, що й ваші робочі навантаження контейнерів Windows Server, щоб уникнути зайвого використання місця на вузлі. Контейнери HostProcess також підтримують монтування томів всередині тома контейнера.

Коли варто використовувати контейнери Windows HostProcess?

• Коли потрібно виконати завдання, які потребують мережевого простору імен хосту. Контейнери HostProcess мають доступ до мережевих інтерфейсів хосту та IP-адрес.
• Вам потрібен доступ до ресурсів на хості, таких як файлова система, події логів тощо.
• Встановлення конкретних драйверів пристроїв або служб Windows.
• Обʼєднання адміністративних завдань та політик безпеки. Це зменшує ступінь привілеїв, які потрібні вузлам Windows.

Перш ніж ви розпочнете

Цей посібник стосується конкретно Kubernetes v1.31. Якщо ви використовуєте іншу версію Kubernetes, перевірте документацію для цієї версії Kubernetes.

У Kubernetes 1.31 контейнери HostProcess є типово увімкненими. kubelet буде спілкуватися з containerd безпосередньо, передаючи прапорець hostprocess через CRI. Ви можете використовувати останню версію containerd (v1.6+) для запуску контейнерів HostProcess. Як встановити containerd.

Обмеження

Ці обмеження стосуються Kubernetes v1.31:

• Контейнери HostProcess вимагають середовища виконання контейнерів containerd 1.6 або вище, рекомендується використовувати containerd 1.7.
• Podʼи HostProcess можуть містити лише контейнери HostProcess. Це поточне обмеження ОС Windows; непривілейовані контейнери Windows не можуть спільно використовувати vNIC з простором імен IP хосту.
• Контейнери HostProcess запускаються як процес на хості та не мають жодного рівня ізоляції, окрім обмежень ресурсів, накладених на обліковий запис користувача HostProcess. Ізоляція ні файлової системи, ні ізоляції Hyper-V не підтримуються для контейнерів HostProcess.
• Монтування томів підтримуються і монтуватимуться як томом контейнера. Див. Монтування томів
• Стандартно для контейнерів HostProcess доступний обмежений набір облікових записів користувачів хосту. Див. Вибір облікового запису користувача.
• Обмеження ресурсів (диск, памʼять, кількість процесорів) підтримуються так само як і процеси на хості.
• Як іменовані канали, так і сокети Unix-домену не підтримуються і замість цього слід отримувати доступ до них через їх шлях на хості (наприклад, \\.\pipe\*)

Вимоги до конфігурації HostProcess Pod

Для активації Windows HostProcess Pod необхідно встановити відповідні конфігурації у конфігурації безпеки Podʼа. З усіх політик, визначених у Стандартах безпеки Pod, HostProcess Podʼи заборонені за базовою та обмеженою політиками. Тому рекомендується, щоб HostProcess Podʼи працювали відповідно до привілейованого профілю.

Під час роботи з привілейованою політикою, ось конфігурації, які потрібно встановити для активації створення HostProcess Pod:

Приклад маніфесту (частково)

spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\Local service"
  hostNetwork: true
  containers:
  - name: test
    image: image1:latest
    command:
      - ping
      - -t
      - 127.0.0.1
  nodeSelector:
    "kubernetes.io/os": windows

Монтування томів

Контейнери HostProcess підтримують можливість монтування томів у просторі томів контейнера. Поведінка монтування томів відрізняється залежно від версії контейнерного середовища containerd, яке використовується на вузлі.

Containerd v1.6

Застосунки, що працюють усередині контейнера, можуть отримувати доступ до підключених томів безпосередньо за допомогою відносних або абсолютних шляхів. Під час створення контейнера встановлюється змінна середовища $CONTAINER_SANDBOX_MOUNT_POINT, яка містить абсолютний шлях хосту до тому контейнера. Відносні шляхи базуються на конфігурації .spec.containers.volumeMounts.mountPath.

Для доступу до токенів облікового запису служби (наприклад) у контейнері підтримуються такі структури шляхів:

• .\var\run\secrets\kubernetes.io\serviceaccount\
• $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

Containerd v1.7 (та новіші версії)

Застосунки, які працюють усередині контейнера, можуть отримувати доступ до підключених томів безпосередньо через вказаний mountPath тому (аналогічно Linux і не-HostProcess контейнерам Windows).

Для забезпечення зворотної сумісності зі старими версіями, доступ до томів також може бути здійснений через використання тих самих відносних шляхів, які були налаштовані у containerd v1.6.

Наприклад, для доступу до токенів службового облікового запису усередині контейнера ви можете використовувати один із таких шляхів:

• c:\var\run\secrets\kubernetes.io\serviceaccount
• /var/run/secrets/kubernetes.io/serviceaccount/
• $CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\

Обмеження ресурсів

Обмеження ресурсів (диск, памʼять, кількість CPU) застосовуються до задачі і є загальними для всієї задачі. Наприклад, при обмеженні в 10 МБ памʼяті, памʼять, виділена для будь-якого обʼєкта задачі HostProcess, буде обмежена 10 МБ. Це така ж поведінка, як і в інших типах контейнерів Windows. Ці обмеження вказуються так само як і зараз для будь-якого середовища виконання контейнерів або оркестрування, яке використовується. Єдина відмінність полягає у розрахунку використання дискових ресурсів для відстеження ресурсів через відмінності у способі ініціалізації контейнерів HostProcess.

Вибір облікового запису користувача

Системні облікові записи

Типово контейнери HostProcess підтримують можливість запуску з одного з трьох підтримуваних облікових записів служб Windows:

• LocalSystem
• LocalService
• NetworkService

Вам слід вибрати відповідний обліковий запис служби Windows для кожного контейнера HostProcess, спираючись на обмеження ступеня привілеїв, щоб уникнути випадкових (або навіть зловмисних) пошкоджень хосту. Обліковий запис служби LocalSystem має найвищий рівень привілеїв серед трьох і повинен використовуватися лише у разі абсолютної необхідності. Де це можливо, використовуйте обліковий запис служби LocalService, оскільки він має найнижчий рівень привілеїв серед цих трьох варіантів.

Локальні облікові записи

Якщо налаштовано, контейнери HostProcess також можуть запускатися як локальні облікові записи користувачів, що дозволяє операторам вузлів надавати деталізований доступ до робочих навантажень.

Для запуску контейнерів HostProcess як локального користувача, спершу на вузлі має бути створена локальна група користувачів, і імʼя цієї локальної групи користувачів повинно бути вказане у полі runAsUserName у Deployment. Перед ініціалізацією контейнера HostProcess має бути створено новий ефемерний локальний обліковий запис користувача та приєднано його до вказаної групи користувачів, з якої запускається контейнер. Це надає кілька переваг, включаючи уникнення необхідності управління паролями для локальних облікових записів користувачів. Початковий контейнер HostProcess, що працює як службовий обліковий запис, може бути використаний для підготовки груп користувачів для подальших контейнерів HostProcess.

Приклад:

1. Створіть локальну групу користувачів на вузлі (це може бути зроблено в іншому контейнері HostProcess).

   net localgroup hpc-localgroup /add
   

2. Надайте доступ до потрібних ресурсів на вузлі локальній групі користувачів. Це можна зробити за допомогою інструментів, таких як icacls.

3. Встановіть runAsUserName на імʼя локальної групи користувачів для Podʼа або окремих контейнерів.

   securityContext:
     windowsOptions:
       hostProcess: true
       runAsUserName: hpc-localgroup
   

4. Заплануйте Pod!

Базовий образ для контейнерів HostProcess

Контейнери HostProcess можуть бути побудовані з будь-яких наявних базових образів контейнерів Windows.

Крім того, був створений новий базовий образ спеціально для контейнерів HostProcess! Для отримання додаткової інформації перегляньте проєкт windows-host-process-containers-base-image на github.

Розвʼязання проблем з контейнерами HostProcess

• Контейнери HostProcess не запускаються, помилка failed to create user process token: failed to logon user: Access is denied.: unknown.

  Переконайтеся, що containerd працює як службовий обліковий запис LocalSystem або LocalService. Облікові записи користувачів (навіть адміністраторські облікові записи) не мають дозволів на створення токенів входу для будь-яких підтримуваних облікових записів користувачів.

7 - Налаштування якості обслуговування для Podʼів

Ця сторінка показує, як налаштувати Podʼи так, щоб їм були призначені певні класи якості обслуговування (QoS). Kubernetes використовує класи QoS для прийняття рішень про видалення Podʼів, коли використання ресурсів вузла збільшується.

Коли Kubernetes створює Pod, він призначає один з таких класів QoS для Podʼа:

• Guaranteed
• Burstable
• BestEffort

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Також вам потрібно мати можливість створювати та видаляти простори імен.

Створення простору імен

Створіть простір імен, щоб ресурси, які ви створюєте у цьому завданні, були ізольовані від решти вашого кластера.

kubectl create namespace qos-example

Створення Podʼа, якому призначено клас QoS Guaranteed

Щоб Podʼа був наданий клас QoS Guaranteed:

• Кожний контейнер у Pod повинен мати ліміт памʼяті та запит памʼяті.
• Для кожного контейнера у Pod ліміт памʼяті повинен дорівнювати запиту памʼяті.
• Кожний контейнер у Pod повинен мати ліміт CPU та запит CPU.
• Для кожного контейнера у Pod ліміт CPU повинен дорівнювати запиту CPU.

Ці обмеження так само застосовуються до контейнерів ініціалізації і до контейнерів застосунків. Ефемерні контейнери не можуть визначати ресурси, тому ці обмеження не застосовуються до них.

Нижче подано маніфест для Podʼа з одним контейнером. Контейнер має ліміт памʼяті та запит памʼяті, обидва дорівнюють 200 MiB. Контейнер має ліміт CPU та запит CPU, обидва дорівнюють 700 міліCPU:

pods/qos/qos-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼу клас QoS Guaranteed. Також вивід підтверджує, що у контейнера Podʼа є запит памʼяті, який відповідає його ліміту памʼяті, і є запит CPU, який відповідає його ліміту CPU.

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    ...
status:
  qosClass: Guaranteed

Очищення

Видаліть свій Pod:

kubectl delete pod qos-demo --namespace=qos-example

Створення Podʼа, якому призначено клас QoS Burstable

Podʼу надається клас QoS Burstable, якщо:

• Pod не відповідає критеріям для класу QoS Guaranteed.
• Принаймні один контейнер у Podʼі має запит або ліміт памʼяті або CPU.

Нижче подано маніфест для Podʼа з одним контейнером. Контейнер має ліміт памʼяті 200 MiB та запит памʼяті 100 MiB.

pods/qos/qos-pod-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼу клас QoS Burstable:

spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: qos-demo-2-ctr
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi
  ...
status:
  qosClass: Burstable

Очищення

Видаліть свій Pod:

kubectl delete pod qos-demo-2 --namespace=qos-example

Створення Podʼа, якому призначено клас QoS BestEffort

Для того, щоб Podʼу був призначений клас QoS BestEffort, контейнери у Podʼі не повинні мати жодних лімітів або запитів памʼяті чи CPU.

Нижче подано маніфест для Podʼа з одним контейнером. контейнер не має лімітів або запитів памʼяті чи CPU:

pods/qos/qos-pod-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼа клас QoS BestEffort:

spec:
  containers:
    ...
    resources: {}
  ...
status:
  qosClass: BestEffort

Очищення

Видаліть свій Pod:

kubectl delete pod qos-demo-3 --namespace=qos-example

Створення Podʼа з двома контейнерами

Нижче подано маніфест для Podʼа з двома контейнерами. Один контейнер вказує запит памʼяті 200 MiB. Інший контейнер не вказує жодних запитів або лімітів.

pods/qos/qos-pod-4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-4
  namespace: qos-example
spec:
  containers:

  - name: qos-demo-4-ctr-1
    image: nginx
    resources:
      requests:
        memory: "200Mi"

  - name: qos-demo-4-ctr-2
    image: redis

Зверніть увагу, що цей Pod відповідає критеріям класу QoS Burstable. Тобто, він не відповідає критеріям для класу QoS Guaranteed, і один з його контейнерів має запит памʼяті.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example

Перегляньте докладну інформацію про Pod:

kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml

Вивід показує, що Kubernetes призначив Podʼу клас QoS Burstable:

spec:
  containers:
    ...
    name: qos-demo-4-ctr-1
    resources:
      requests:
        memory: 200Mi
    ...
    name: qos-demo-4-ctr-2
    resources: {}
    ...
status:
  qosClass: Burstable

Отримання класу QoS Podʼа

Замість того, щоб бачити всі поля, ви можете переглянути лише поле, яке вам потрібно:

kubectl --namespace=qos-example get pod qos-demo-4 -o jsonpath='{ .status.qosClass}{"\n"}'

Burstable

Очищення

Видаліть ваш простір імен:

kubectl delete namespace qos-example

Що далі

Для розробників застосунків

• Призначення ресурсів памʼяті для контейнерів та Podʼів

• Призначення ресурсів CPU для контейнерів та Podʼів

Для адміністраторів кластера

• Налаштування стандартних запитів та лімітів памʼяті для простору імен

• Налаштування стандартних запитів та лімітів CPU для простору імен

• Налаштування мінімальних та максимальних лімітів памʼяті для простору імен

• Налаштування мінімальних та максимальних лімітів CPU для простору імен

• Налаштування квот памʼяті та CPU для простору імен

• Налаштування квоти Podʼа для простору імен

• Налаштування квот для обʼєктів API

• Керування політиками управління топологією на вузлі

8 - Призначення розширених ресурсів контейнеру

Ця сторінка показує, як призначити розширені ресурси контейнеру.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Перш ніж виконувати це завдання, виконайте завдання Оголошення розширених ресурсів для вузла. Це налаштує один з ваших вузлів для оголошення ресурсу "dongle".

Призначте розширений ресурс Podʼу

Щоб запитати розширений ресурс, включіть поле resources:requests у ваш маніфест контейнера. Розширені ресурси повністю кваліфікуються будь-яким доменом поза *.kubernetes.io/. Дійсні імена розширених ресурсів мають форму example.com/foo, де example.com замінено на домен вашої організації, а foo — це описове імʼя ресурсу.

Нижче подано конфігураційний файл для Podʼа з одним контейнером:

pods/resource/extended-resource-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo
spec:
  containers:
  - name: extended-resource-demo-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 3
      limits:
        example.com/dongle: 3

У конфігураційному файлі можна побачити, що контейнер запитує 3 розширених ресурси "dongle".

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml

Перевірте, що Pod працює:

kubectl get pod extended-resource-demo

Опишіть Pod:

kubectl describe pod extended-resource-demo

Виведений текст показує запити донглів:

Limits:
  example.com/dongle: 3
Requests:
  example.com/dongle: 3

Спроба створення другого Podʼа

Нижче наведено конфігураційний файл для Podʼа з одним контейнером. Контейнер запитує два розширені ресурси "dongle".

pods/resource/extended-resource-pod-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo-2
spec:
  containers:
  - name: extended-resource-demo-2-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 2
      limits:
        example.com/dongle: 2

Kubernetes не зможе задовольнити запит на два донгли, оскільки перший Pod використав три з чотирьох доступних донглів.

Спроба створити Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml

Опишіть Pod:

kubectl describe pod extended-resource-demo-2

Текст виводу показує, що Pod не може бути запланованим, оскільки немає вузла, на якому було б доступно 2 донгли:

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  ...
  ... Warning   FailedScheduling  pod (extended-resource-demo-2) failed to fit in any node
fit failure summary on nodes : Insufficient example.com/dongle (1)

Перегляньте статус Podʼа:

kubectl get pod extended-resource-demo-2

Текст виводу показує, що Pod було створено, але не заплановано для виконання на вузлі. Він має статус Pending:

NAME                       READY     STATUS    RESTARTS   AGE
extended-resource-demo-2   0/1       Pending   0          6m

Очищення

Видаліть Podʼи, які ви створили для цього завдання:

kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2

Для розробників застосунків

• Призначення ресурсів памʼяті для контейнерів та Podʼів
• Призначення ресурсів CPU для контейнерів та Podʼів

Для адміністраторів кластера

• Оголошення розширених ресурсів для вузла

9 - Налаштування Podʼа для використання тому для зберігання

Ця сторінка показує, як налаштувати Pod для використання тому для зберігання.

Файлова система контейнера існує лише поки існує сам контейнер. Отже, коли контейнер завершує роботу та перезавантажується, зміни в файловій системі втрачаються. Для більш стійкого зберігання, яке не залежить від контейнера, ви можете використовувати том. Це особливо важливо для застосунків, що зберігають стан, таких як бази даних і сховища ключ-значення (наприклад, Redis).

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Налаштування тому для Podʼа

У цьому завданні ви створюєте Pod, який запускає один контейнер. У цьому Podʼі є том типу emptyDir, який існує протягом усього життєвого циклу Podʼа, навіть якщо контейнер завершиться та перезапуститься. Ось конфігураційний файл для Podʼа:

pods/storage/redis.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}

1. Створіть Pod:

   kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
   

2. Перевірте, що контейнер Podʼа працює, а потім спостерігайте за змінами в Podʼі:

   kubectl get pod redis --watch
   

   Вивід буде подібний до цього:

   NAME      READY     STATUS    RESTARTS   AGE
   redis     1/1       Running   0          13s
   

3. В іншому терміналі отримайте доступ до оболонки запущеного контейнера:

   kubectl exec -it redis -- /bin/bash
   

4. У вашій оболонці перейдіть до /data/redis, а потім створіть файл:

   root@redis:/data# cd /data/redis/
   root@redis:/data/redis# echo Hello > test-file
   

5. У вашій оболонці виведіть список запущених процесів:

   root@redis:/data/redis# apt-get update
   root@redis:/data/redis# apt-get install procps
   root@redis:/data/redis# ps aux
   

   Вивід буде схожий на це:

   USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
   root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
   root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
   

6. У вашій оболонці завершіть процес Redis:

   root@redis:/data/redis# kill <pid>
   

   де <pid> — це ідентифікатор процесу Redis (PID).

7. У вашому початковому терміналі спостерігайте за змінами в Podʼі Redis. В кінцевому результаті ви побачите щось подібне:

   NAME      READY     STATUS     RESTARTS   AGE
   redis     1/1       Running    0          13s
   redis     0/1       Completed  0         6m
   redis     1/1       Running    1         6m
   

На цьому етапі контейнер завершився та перезапустився. Це тому, що Pod Redis має restartPolicy Always.

1. Отримайте доступ до оболонки в перезапущеному контейнері:

   kubectl exec -it redis -- /bin/bash
   

2. У вашій оболонці перейдіть до /data/redis та перевірте, що test-file все ще там.

   root@redis:/data/redis# cd /data/redis/
   root@redis:/data/redis# ls
   test-file
   

3. Видаліть Pod, який ви створили для цього завдання:

   kubectl delete pod redis
   

Що далі

• Дивіться Volume.

• Дивіться Pod.

• Крім локального сховища на диску, яке надає emptyDir, Kubernetes підтримує багато різних рішень для мережевого сховища, включаючи PD на GCE та EBS на EC2, які бажані для критичних даних та будуть обробляти деталі, такі як монтування та розмонтування пристроїв на вузлах. Дивіться Volumes для отримання додаткової інформації.

10 - Налаштування Podʼа для використання PersistentVolume для зберігання

Ця сторінка показує, як налаштувати Pod для використання PersistentVolumeClaim для зберігання. Ось короткий опис процесу:

1. Ви, як адміністратор кластера, створюєте PersistentVolume на основі фізичного сховища. Ви не повʼязуєте том з жодним Podʼом.

2. Ви, як розробник / користувач кластера, створюєте PersistentVolumeClaim, який автоматично привʼязується до відповідного PersistentVolume.

3. Ви створюєте Pod, який використовує вищезгаданий PersistentVolumeClaim для зберігання.

Перш ніж ви розпочнете

• Вам потрібно мати кластер Kubernetes, який має лише один вузол, і kubectl повинен бути налаштований на спілкування з вашим кластером. Якщо у вас ще немає кластера з одним вузлом, ви можете створити його, використовуючи Minikube.

• Ознайомтеся з матеріалом в Постійні томи.

Створіть файл index.html на вашому вузлі

Відкрийте оболонку на єдиному вузлі вашого кластера. Спосіб відкриття оболонки залежить від того, як ви налаштували ваш кластер. Наприклад, якщо ви використовуєте Minikube, ви можете відкрити оболонку до вашого вузла, введенням minikube ssh.

У вашій оболонці на цьому вузлі створіть теку /mnt/data:

# Це передбачає, що ваш вузол використовує "sudo" для запуску команд
# як суперкористувач
sudo mkdir /mnt/data

У теці /mnt/data створіть файл index.html:

# Це також передбачає, що ваш вузол використовує "sudo" для запуску команд
# як суперкористувач
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"

Перевірте, що файл index.html існує:

cat /mnt/data/index.html

Виведення повинно бути:

Hello from Kubernetes storage

Тепер ви можете закрити оболонку вашого вузла.

Створення PersistentVolume

У цьому завданні ви створюєте hostPath PersistentVolume. Kubernetes підтримує hostPath для розробки та тестування на одновузловому кластері. PersistentVolume типу hostPath використовує файл або теку на вузлі для емуляції мережевого сховища.

В операційному кластері ви не використовували б hostPath. Замість цього адміністратор кластера створив би мережевий ресурс, такий як постійний диск Google Compute Engine, розділ NFS або том Amazon Elastic Block Store. Адміністратори кластера також можуть використовувати StorageClasses для динамічного налаштування.

Ось файл конфігурації для PersistentVolume типу hostPath:

pods/storage/pv-volume.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Файл конфігурації вказує, що том знаходиться в /mnt/data на вузлі кластера. Конфігурація також вказує розмір 10 гібібайт та режим доступу ReadWriteOnce, що означає, що том може бути підключений як для читання-запису лише одним вузлом. Визначається імʼя StorageClass manual для PersistentVolume, яке буде використовуватися для привʼязки запитів PersistentVolumeClaim до цього PersistentVolume.

Створіть PersistentVolume:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

Перегляньте інформацію про PersistentVolume:

kubectl get pv task-pv-volume

Вивід показує, що PersistentVolume має STATUS Available. Це означає, що він ще не був привʼязаний до PersistentVolumeClaim.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s

Створення PersistentVolumeClaim

Наступним кроком є створення PersistentVolumeClaim. Podʼи використовують PersistentVolumeClaim для запиту фізичного сховища. У цій вправі ви створюєте PersistentVolumeClaim, який запитує том не менше трьох гібібайт, який може забезпечити доступ до читання-запису не більше одного вузла за раз.

Ось файл конфігурації для PersistentVolumeClaim:

pods/storage/pv-claim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Створіть PersistentVolumeClaim:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

Після створення PersistentVolumeClaim панель управління Kubernetes шукає PersistentVolume, який відповідає вимогам заявки. Якщо панель управління знаходить відповідний PersistentVolume з тим самим StorageClass, вона привʼязує заявку до тому.

Знову подивіться на PersistentVolume:

kubectl get pv task-pv-volume

Тепер вивід показує STATUS як Bound.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m

Подивіться на PersistentVolumeClaim:

kubectl get pvc task-pv-claim

Вивід показує, що PersistentVolumeClaim привʼязаний до вашого PersistentVolume, task-pv-volume.

NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s

Створення Podʼа

Наступним кроком є створення Podʼа, який використовує ваш PersistentVolumeClaim як том.

Ось файл конфігурації для Podʼа:

pods/storage/pv-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Зверніть увагу, що файл конфігурації Podʼа вказує PersistentVolumeClaim, але не вказує PersistentVolume. З погляду Podʼа, заявка є томом.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml

Перевірте, що контейнер у Podʼі працює:

kubectl get pod task-pv-pod

Відкрийте оболонку для контейнера, що працює у вашому Podʼі:

kubectl exec -it task-pv-pod -- /bin/bash

У вашій оболонці перевірте, що nginx обслуговує файл index.html з тому hostPath:

# Обовʼязково запустіть ці 3 команди всередині кореневої оболонки, яка є результатом
# виконання "kubectl exec" на попередньому кроці
apt update
apt install curl
curl http://localhost/

Вивід показує текст, який ви записали у файл index.html у томі hostPath:

Hello from Kubernetes storage

Якщо ви бачите це повідомлення, ви успішно налаштували Pod для використання зберігання з PersistentVolumeClaim.

Очищення

Видаліть Pod, PersistentVolumeClaim та PersistentVolume:

kubectl delete pod task-pv-pod
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume

Якщо у вас ще не відкрито оболонку до вузла у вашому кластері, відкрийте нову оболонку так само як ви робили це раніше.

У оболонці на вашому вузлі видаліть файл і теку, які ви створили:

# Це передбачає, що ваш вузол використовує "sudo" для виконання команд
# з правами суперкористувача
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data

Тепер ви можете закрити оболонку доступу до вашого вузла.

Монтування одного PersistentVolume у два місця

pods/storage/pv-duplicate.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: nginx
      volumeMounts:
        # a mount for site-data
        - name: config
          mountPath: /usr/share/nginx/html
          subPath: html
        # another mount for nginx config
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: config
      persistentVolumeClaim:
        claimName: test-nfs-claim

Ви можете виконати монтування томуу двох місцях у вашому контейнері nginx:

• /usr/share/nginx/html для статичного вебсайту
• /etc/nginx/nginx.conf для стандартної конфігурації

Контроль доступу

Зберігання даних із використанням ідентифікатора групи (GID) дозволяє запис лише для Podʼів, які використовують той самий GID. Невідповідність або відсутність GID призводить до помилок доступу. Щоб зменшити необхідність координації з користувачами, адміністратор може анотувати PersistentVolume з GID. Після цього GID автоматично додається до будь-якого Podʼа, який використовує цей PersistentVolume.

Використовуйте анотацію pv.beta.kubernetes.io/gid наступним чином:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
  annotations:
    pv.beta.kubernetes.io/gid: "1234"

Коли Pod використовує PersistentVolume з анотацією GID, анотований GID застосовується до всіх контейнерів у Podʼі так само як GID, зазначені у контексті безпеки Podʼа. Кожен GID, незалежно від того, чи походить він з анотації PersistentVolume або специфікації Podʼа, застосовується до першого процесу, запущеного в кожному контейнері.

Що далі

• Дізнайтеся більше про PersistentVolumes.
• Прочитайте документ проєктування постійного сховища.

Довідка

• PersistentVolume
• PersistentVolumeSpec
• PersistentVolumeClaim
• PersistentVolumeClaimSpec

11 - Налаштування Pod для використання projected тому для зберігання

Ця сторінка показує, як використовувати projected том, щоб змонтувати декілька наявних джерел томів у одну теку. Наразі можна проєктувати томи типів secret, configMap, downwardAPI, та serviceAccountToken.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Налаштування projected тому для Pod

У цьому завданні ви створите Secrets із локальних файлів для імені користувача та пароля. Потім ви створите Pod, який запускає один контейнер, використовуючи projected том для монтування секретів у спільну теку.

Ось файл конфігурації для Pod:

pods/storage/projected.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox:1.28
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

1. Створіть Secrets:

   # Створіть файли, що містять імʼя користувача та пароль:
   echo -n "admin" > ./username.txt
   echo -n "1f2d1e2e67df" > ./password.txt
   
   # Запакуйте ці файли у секрети:
   kubectl create secret generic user --from-file=./username.txt
   kubectl create secret generic pass --from-file=./password.txt
   

2. Створіть Pod:

   kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml
   

3. Перевірте, що контейнер Pod запущено, а потім слідкуйте за змінами в Podʼі:

   kubectl get --watch pod test-projected-volume
   

   Вивід буде виглядати так:

   NAME                    READY     STATUS    RESTARTS   AGE
   test-projected-volume   1/1       Running   0          14s
   

4. В іншому терміналі отримайте оболонку до запущеного контейнера:

   kubectl exec -it test-projected-volume -- /bin/sh
   

5. У вашій оболонці перевірте, що тека projected-volume містить ваші projected джерела:

   ls /projected-volume/
   

Очищення

Видаліть Pod та Secrets:

kubectl delete pod test-projected-volume
kubectl delete secret user pass

Що далі

• Дізнайтеся більше про projected томи.
• Прочитайте документ про проєктування all-in-one volume.

12 - Налаштування контексту безпеки для Podʼа або контейнера

Контекст безпеки визначає параметри привілеїв та контролю доступу для Podʼа або контейнера. Налаштування контексту безпеки включають, але не обмежуються:

• Дискреційний контроль доступу: Дозвіл на доступ до обʼєкта, такого як файл, базується на ідентифікаторі користувача (UID) та ідентифікаторі групи (GID).

• Security Enhanced Linux (SELinux): Обʼєкти призначаються мітки безпеки.

• Виконання з привілеями або без них.

• Linux Capabilities: Надає процесу деякі привілеї, але не всі привілеї користувача root.

• AppArmor: Використовуйте профілі програм для обмеження можливостей окремих програм.

• Seccomp: Фільтрує системні виклики процесу.

• allowPrivilegeEscalation: Контролює, чи може процес отримувати більше привілеїв, ніж його батьківський процес. Ця логічна величина безпосередньо контролює, чи встановлюється прапорець no_new_privs для процесу контейнера. allowPrivilegeEscalation завжди true, коли контейнер:

  • запущений з привілеями, або
  • має CAP_SYS_ADMIN

• readOnlyRootFilesystem: Підключає кореневу файлову систему контейнера тільки для читання.

Вищевказані пункти не є повним набором налаштувань контексту безпеки,докладну інформацію див. у SecurityContext для повного переліку.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Встановлення контексту безпеки для Pod

Щоб вказати параметри безпеки для Podʼа, включіть поле securityContext в специфікацію Pod. Поле securityContext є обʼєктом PodSecurityContext. Параметри безпеки, які ви вказуєте для Pod, застосовуються до всіх контейнерів в Podʼі. Ось файл конфігурації для Podʼа з securityContext та томом emptyDir:

pods/security/security-context.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    supplementalGroups: [4000]
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

У файлі конфігурації поле runAsUser вказує, що для будь-яких контейнерів в Podʼі, всі процеси виконуються з ідентифікатором користувача 1000. Поле runAsGroup вказує основний ідентифікатор групи 3000 для усіх процесів у контейнерах Pod. Якщо це поле відсутнє, основний ідентифікатор групи контейнерів буде root(0). Будь-які створені файли також належатимуть користувачу 1000 та групі 3000 при вказанні runAsGroup. Оскільки вказано поле fsGroup, всі процеси контейнера також належать до додаткової групи ідентифікатора 2000. Власником тому /data/demo та всіх створених файлів у цьому томі буде груповий ідентифікатор 2000. Додатково, коли вказане поле supplementalGroups, всі процеси контейнера також є частиною вказаних груп. Якщо це поле пропущене, це означає, що воно порожнє.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context.yaml

Перевірте, що контейнер Pod запущений:

kubectl get pod security-context-demo

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo -- sh

У вашій оболонці перелічіть запущені процеси:

ps

Виведений результат показує, що процеси виконуються від імені користувача 1000, що є значенням runAsUser:

PID   USER     TIME  COMMAND
    1 1000      0:00 sleep 1h
    6 1000      0:00 sh
...

У вашій оболонці перейдіть до /data, та виведіть список тек:

cd /data
ls -l

Виведений результат показує, що тека /data/demo має ідентифікатор групи 2000, що є значенням fsGroup.

drwxrwsrwx 2 root 2000 4096 Jun  6 20:08 demo

У вашій оболонці перейдіть до /data/demo, та створіть файл:

cd demo
echo hello > testfile

Виведіть список файлів у теці /data/demo:

ls -l

Виведений результат показує, що testfile має ідентифікатор групи 2000, що є значенням fsGroup.

-rw-r--r-- 1 1000 2000 6 Jun  6 20:08 testfile

Виконайте наступну команду:

id

Результат буде схожий на цей:

uid=1000 gid=3000 groups=2000,3000,4000

З результату видно, що gid дорівнює 3000, що є таким самим, як поле runAsGroup. Якби поле runAsGroup було пропущено, gid залишився б 0 (root), і процес зміг би взаємодіяти з файлами, які належать групі root(0) та групам, які мають необхідні права групи для групи root (0). Ви також можете побачити, що groups містить ідентифікатори груп, які вказані в fsGroup і supplementalGroups, поряд з gid.

Вийдіть з оболонки:

exit

Неявні членства груп, визначені в /etc/group в контейнерному образі

Стандартно Kubernetes обʼєднує інформацію про групи з Podʼа з інформацією, визначеною в /etc/group в контейнерному образі.

pods/security/security-context-5.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Цей контекст безпеки Podʼа містить runAsUser, runAsGroup та supplementalGroups. Проте ви можете побачити, що фактичні додаткові групи, що прикріплені до процесу контейнера, включатимуть ідентифікатори груп, які походять з /etc/group всередині контейнерного образу.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-5.yaml

Перевірте, чи контейнер Pod запущений:

kubectl get pod security-context-demo

Отримайте оболонку для запущеного контейнера:

kubectl exec -it security-context-demo -- sh

Перевірте ідентичність процесу:

$ id

Вивід буде схожий на:

uid=1000 gid=3000 groups=3000,4000,50000

Ви можете побачити, що groups включає ідентифікатор групи 50000. Це тому, що користувач (uid=1000), який визначений в образі, належить до групи (gid=50000), яка визначена в /etc/group всередині контейнерного образу.

Перевірте /etc/group в контейнерному образі:

$ cat /etc/group

Ви побачите, що uid 1000 належить до групи 50000.

...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

Вийдіть з оболонки:

exit

Налаштування SupplementalGroups для Podʼа

Цю функцію можна увімкнути, встановивши функціональну можливість SupplementalGroupsPolicy для kubelet та kube-apiserver, а також налаштувавши поле .spec.securityContext.supplementalGroupsPolicy для Podʼа.

Поле supplementalGroupsPolicy визначає політику для розрахунку додаткових груп для процесів контейнера в Podʼі. Для цього поля є два дійсних значення:

• Merge: Членство в групах, визначене в /etc/group для основного користувача контейнера, буде обʼєднано. Це є стандартною політикою, якщо не зазначено інше.

• Strict: Тільки ідентифікатори груп у полях fsGroup, supplementalGroups або runAsGroup прикріплюються як додаткові групи для процесів контейнера. Це означає, що жодне членство в групах з /etc/group для основного користувача контейнера не буде обʼєднано.

Коли функція увімкнена, вона також надає ідентичність процесу, прикріплену до першого процесу контейнера в полі .status.containerStatuses[].user.linux. Це буде корисно для виявлення, чи прикріплені неявні ідентифікатори груп.

pods/security/security-context-6.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: sec-ctx-demo
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Цей маніфест Podʼа визначає supplementalGroupsPolicy=Strict. Ви можете побачити, що жодне членство в групах, визначене в /etc/group, не обʼєднується в додаткові групи для процесів контейнера.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-6.yaml

Перевірте, що контейнер Podʼа працює:

kubectl get pod security-context-demo

Перевірте ідентичність процесу:

kubectl exec -it security-context-demo -- id

Вивід буде подібним до цього:

uid=1000 gid=3000 groups=3000,4000

Перегляньте статус Podʼа:

kubectl get pod security-context-demo -o yaml

Ви можете побачити, що поле status.containerStatuses[].user.linux надає ідентичність процесу, прикріплену до першого процесу контейнера.

...
status:
  containerStatuses:
  - name: sec-ctx-demo
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

Реалізації

Відомо, що наступні середовища виконання контейнерів підтримують контроль додаткових груп з тонкою настройкою.

На рівні CRI:

• containerd, починаючи з v2.0
• CRI-O, починаючи з v1.31

Ви можете перевірити, чи підтримується функція в статусі вузла.

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

Налаштування політики зміни дозволів та прав власності тому для Pod

Типово Kubernetes рекурсивно змінює права власності та дозволи для вмісту кожного тому так, щоб вони відповідали значенню fsGroup, вказаному в securityContext Podʼа при підключенні цього тому. Для великих томів перевірка та зміна власності та дозволів може займати багато часу, сповільнюючи запуск Podʼів. Ви можете використовувати поле fsGroupChangePolicy в securityContext для контролю способу, яким Kubernetes перевіряє та керує власністю та дозволами для тому.

fsGroupChangePolicy — fsGroupChangePolicy визначає поведінку зміни власності та дозволів тому перед тим, як він буде використаний в Pod. Це поле застосовується лише до типів томів, які підтримують контроль власності та дозволів за допомогою fsGroup. Це поле має два можливі значення:

• OnRootMismatch: Змінювати дозволи та права власності тільки у випадку, якщо дозволи та права кореневої теки не відповідають очікуваним дозволам тому. Це може допомогти скоротити час зміни власності та дозволів тому.
• Always: Завжди змінювати дозволи та права власності тому під час підключення.

Наприклад:

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

Делегування зміни прав власності та дозволів тому до драйвера CSI

Якщо ви розгортаєте драйвер Container Storage Interface (CSI), який підтримує VOLUME_MOUNT_GROUP NodeServiceCapability, процес встановлення права власності та дозволів файлу на основі fsGroup, вказаного в securityContext, буде виконуватися драйвером CSI, а не Kubernetes. У цьому випадку, оскільки Kubernetes не виконує жодної зміни права власності та дозволів, fsGroupChangePolicy не набуває чинності, і згідно з вказаним CSI, очікується, що драйвер монтує том з наданим fsGroup, що призводить до отримання тому, який є доступними для читаання/запису для fsGroup.

Встановлення контексту безпеки для контейнера

Для вказання параметрів безпеки для контейнера, включіть поле securityContext в маніфест контейнера. Поле securityContext є обʼєктом SecurityContext. Параметри безпеки, які ви вказуєте для контейнера, застосовуються тільки до окремого контейнера, і вони перевизначають налаштування, зроблені на рівні Podʼа, коли є перетин. Налаштування контейнера не впливають на томи Podʼів.

Ось файл конфігурації для Podʼа з одним контейнером. Як Pod, так і контейнер мають поле securityContext:

pods/security/security-context-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-2.yaml

Перевірте, що контейнер Pod запущений:

kubectl get pod security-context-demo-2

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo-2 -- sh

У вашій оболонці перегляньте запущені процеси:

ps aux

Виведений результат показує, що процеси виконуються від імені користувача 2000. Це значення runAsUser, вказане для контейнера. Воно перевизначає значення 1000, вказане для Pod.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js
...

Вийдіть з оболонки:

exit

Встановлення можливостей для контейнера

За допомогою можливостей Linux, ви можете надати певні привілеї процесу, не надаючи всі привілеї користувачеві з правами root. Щоб додати або видалити можливості Linux для контейнера, включіть поле capabilities в розділ securityContext маніфесту контейнера.

Спочатку подивімося, що відбувається, коли ви не включаєте поле capabilities. Ось файл конфігурації, який не додає або не видаляє жодних можливостей контейнера:

pods/security/security-context-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-3
spec:
  containers:
  - name: sec-ctx-3
    image: gcr.io/google-samples/hello-app:2.0

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-3.yaml

Перевірте, що контейнер Pod запущений:

kubectl get pod security-context-demo-3

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo-3 -- sh

У вашій оболонці перегляньте запущені процеси:

ps aux

Виведений результат показує ідентифікатори процесів (PID) для контейнера:

USER  PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root    1  0.0  0.0   4336   796 ?     Ss   18:17   0:00 /bin/sh -c node server.js
root    5  0.1  0.5 772124 22700 ?     Sl   18:17   0:00 node server.js

У вашій оболонці перегляньте статус для процесу 1:

cd /proc/1
cat status

Виведений результат показує bitmap можливостей для процесу:

...
CapPrm:	00000000a80425fb
CapEff:	00000000a80425fb
...

Запамʼятайте bitmap можливостей, а потім вийдіть з оболонки:

exit

Далі, запустіть контейнер, який є такий самий, як попередній контейнер, за винятком того, що він має додаткові можливості.

Ось файл конфігурації для Pod, який запускає один контейнер. Конфігурація додає можливості CAP_NET_ADMIN та CAP_SYS_TIME:

pods/security/security-context-4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/hello-app:2.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/security/security-context-4.yaml

Отримайте оболонку до запущеного контейнера:

kubectl exec -it security-context-demo-4 -- sh

У вашій оболонці перегляньте можливості для процесу 1:

cd /proc/1
cat status

Виведений результат показує бітову карту можливостей для процесу:

...
CapPrm:	00000000aa0435fb
CapEff:	00000000aa0435fb
...

Порівняйте можливості двох контейнерів:

00000000a80425fb
00000000aa0435fb

У bitmap можливостей першого контейнера біти 12 і 25 не встановлені. У другому контейнері, біти 12 і 25 встановлені. Біт 12 — це CAP_NET_ADMIN, а біт 25 — це CAP_SYS_TIME. Дивіться capability.h для визначень констант можливостей.

Встановлення профілю Seccomp для контейнера

Щоб встановити профіль Seccomp для контейнера, включіть поле seccompProfile в розділ securityContext вашого маніфесту Pod або контейнера. Поле seccompProfile є обʼєктом SeccompProfile, який складається з type та localhostProfile. Допустимі варіанти для type включають RuntimeDefault, Unconfined та Localhost. localhostProfile повинен бути встановлений лише якщо type: Localhost. Він вказує шлях до попередньо налаштованого профілю на вузлі, повʼязаного з розташуванням налаштованого профілю Seccomp kubelet (налаштованого за допомогою прапорця --root-dir).

Ось приклад, який встановлює профіль Seccomp до стандартного профілю контейнера вузла:

...
securityContext:
  seccompProfile:
    type: RuntimeDefault

Ось приклад, який встановлює профіль Seccomp до попередньо налаштованого файлу за шляхом <kubelet-root-dir>/seccomp/my-profiles/profile-allow.json:

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-profiles/profile-allow.json

Налаштування профілю AppArmor для контейнера

Щоб налаштувати профіль AppArmor для контейнера, включіть поле appArmorProfile в секцію securityContext вашого контейнера. Поле appArmorProfile є обʼєктом AppArmorProfile, що складається з type та localhostProfile. Дійсні опції для type включають RuntimeDefault (стандартно), Unconfined і Localhost. localhostProfile слід встановлювати тільки якщо type є Localhost. Це вказує на назву попередньо налаштованого профілю на вузлі. Профіль повинен бути завантажений на всіх вузлах, які підходять для Podʼа, оскільки ви не знаєте, де буде розгорнуто Pod. Підходи до налаштування власних профілів обговорюються в Налаштування вузлів з профілями.

Примітка: Якщо containers[*].securityContext.appArmorProfile.type явно встановлено на RuntimeDefault, то Pod не буде допущено, якщо AppArmor не включено на вузлі. Однак, якщо containers[*].securityContext.appArmorProfile.type не зазначено, то стандартне значення (що також є RuntimeDefault) буде застосовано тільки якщо вузол має увімкнений AppArmor. Якщо вузол має вимкнений AppArmor, Pod буде допущено, але контейнер не буде обмежено профілем RuntimeDefault.

Ось приклад, який встановлює профіль AppArmor на стандартний профіль контейнерного середовища вузла:

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: RuntimeDefault

Ось приклад, який встановлює профіль AppArmor на попередньо налаштований профіль з назвою k8s-apparmor-example-deny-write:

...
containers:
- name: container-1
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write

Для отримання додаткової інформації дивіться Обмеження доступу контейнера до ресурсів з AppArmor.

Призначення міток SELinux контейнеру

Щоб призначити мітки SELinux контейнеру, включіть поле seLinuxOptions в розділ securityContext вашого маніфесту Podʼа або контейнера. Поле seLinuxOptions є обʼєктом SELinuxOptions. Ось приклад, який застосовує рівень SELinux:

...
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

Ефективне переозначення обʼєктів SELinux в томах

Стандартно, контейнерне середовище рекурсивно призначає мітку SELinux для всіх файлів на всіх томах Pod. Щоб прискорити цей процес, Kubernetes може миттєво змінити мітку SELinux тому за допомогою параметра монтування -o context=<мітка>.

Щоб скористатися цим прискоренням, мають бути виконані всі ці умови:

• Функціональні можливості ReadWriteOncePod та SELinuxMountReadWriteOncePod повинні бути увімкнені.
• Pod повинен використовувати PersistentVolumeClaim з відповідними accessModes та функціональною можливстю:
  • Або том має accessModes: ["ReadWriteOncePod"], і властивість включення SELinuxMountReadWriteOncePod увімкнена.
  • Або том може використовувати будь-які інші режими доступу та обидва SELinuxMountReadWriteOncePod та SELinuxMount повинні бути увімкнені.
• Pod (або всі його контейнери, які використовують PersistentVolumeClaim) повинні мати встановлені параметри seLinuxOptions.
• Відповідний PersistentVolume повинен бути або:
  • Том, який використовує старі типи томів iscsi, rbd або fc.
  • Або том, який використовує драйвер CSI CSI. Драйвер CSI повинен оголосити, що він підтримує монтування з -o context, встановивши spec.seLinuxMount: true у його екземплярі CSIDriver.

Для будь-яких інших типів томів переозначення SELinux відбувається іншим шляхом: контейнерне середовище рекурсивно змінює мітку SELinux для всіх inodes (файлів і тек) у томі. Чим більше файлів і тек у томі, тим довше відбувається це переозначення.

Управління доступом до файлової системи /proc

Для середовищ виконання, які слідують специфікації виконання OCI, контейнери типово запускаються у режимі, де є кілька шляхів, які промасковані та доступні тільки для читання. Результатом цього є те, що в межах простору імен монтування контейнера присутні ці шляхи, і вони можуть працювати подібно до того, якби контейнер був ізольованим хостом, але процес контейнера не може записувати до них. Список промаскованих і доступних тільки для читання шляхів такий:

• Промасковані шляхи:

  • /proc/asound
  • /proc/acpi
  • /proc/kcore
  • /proc/keys
  • /proc/latency_stats
  • /proc/timer_list
  • /proc/timer_stats
  • /proc/sched_debug
  • /proc/scsi
  • /sys/firmware
  • /sys/devices/virtual/powercap

• Шляхи доступні тільки для читання:

  • /proc/bus
  • /proc/fs
  • /proc/irq
  • /proc/sys
  • /proc/sysrq-trigger

Для деяких Podʼів вам може знадобитися обійти стандартний шлях маскування. Найбільш поширений контекст, коли це потрібно, — це спроба запуску контейнерів у межах контейнера Kubernetes (у межах Podʼа).

Поле procMount в securityContext дозволяє користувачеві запитати, щоб /proc контейнера був Unmasked, або міг бути підмонтований для читання-запису контейнерним процесом. Це також стосується /sys/firmware, який не знаходиться в /proc.

...
securityContext:
  procMount: Unmasked

Обговорення

Контекст безпеки для Pod застосовується до Контейнерів Pod і також до Томів Pod при необхідності. Зокрема, fsGroup та seLinuxOptions застосовуються до Томів наступним чином:

• fsGroup: Томи, які підтримують управління власністю, модифікуються так, щоб бути власністю та доступними для запису за GID, вказаним у fsGroup. Докладніше див. Документ із проєктування управління власністю томів.

• seLinuxOptions: Томи, які підтримують мітку SELinux, переозначаються так, щоб бути доступними за міткою, вказаною у seLinuxOptions. Зазвичай вам потрібно лише встановити розділ level. Це встановлює мітку Multi-Category Security (MCS), яку отримують всі Контейнери у Pod, а також Томи.

Очищення

Видаліть Pod:

kubectl delete pod security-context-demo
kubectl delete pod security-context-demo-2
kubectl delete pod security-context-demo-3
kubectl delete pod security-context-demo-4

Що далі

• PodSecurityContext
• SecurityContext
• Посібник з налаштування втулків CRI
• Документ проєктування контекстів безпеки
• Документ проєктування управління власністю
• Допуск PodSecurity
• Документ проєктування AllowPrivilegeEscalation
• Для отримання додаткової інформації про механізми безпеки в Linux дивіться Огляд функцій безпеки ядра Linux (Примітка: деяка інформація може бути застарілою)
• Дізнайтеся більше про Простори імен користувачів для Linux контейнерів.
• Промасковані шляхи в специфікації OCI Runtime

13 - Налаштування службових облікових записів для Podʼів

Kubernetes пропонує два відмінні способи автентифікації для клієнтів, які працюють у межах вашого кластера або мають взаємозвʼязок з панеллю управління вашого кластера для автентифікації в API-сервері.

Службовий обліковий запис надає ідентичність процесам, які працюють у Podʼі, і відповідає обʼєкту ServiceAccount. Коли ви автентифікуєтеся в API-сервері, ви ідентифікуєте себе як певного користувача. Kubernetes визнає поняття користувача, але сам Kubernetes не має API User.

Це завдання стосується Службових облікових записів, які існують в API Kubernetes. Керівництво показує вам деякі способи налаштування Службових облікових записів для Podʼів.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• Killercoda
• Play with Kubernetes

Використання стандартного службового облікового запису для доступу до API-сервера

Коли Podʼи звертаються до API-сервера, вони автентифікуються як певний Службовий обліковий запис (наприклад, default). В кожному просторі імен завжди є принаймні один Службовий обліковий запис.

У кожному просторі імен Kubernetes завжди міститься принаймні один Службовий обліковий запис: стандартний службовий обліковий запис для цього простору імен, з назвою default. Якщо ви не вказуєте Службовий обліковий запис при створенні Podʼа, Kubernetes автоматично призначає Службовий обліковий запис з назвою default у цьому просторі імен.

Ви можете отримати деталі для Podʼа, який ви створили. Наприклад:

kubectl get pods/<імʼя_пода> -o yaml

У виводі ви побачите поле spec.serviceAccountName. Kubernetes автоматично встановлює це значення, якщо ви не вказали його при створенні Podʼа.

Застосунок, який працює усередині Podʼа, може отримати доступ до API Kubernetes, використовуючи автоматично змонтовані облікові дані службового облікового запису. Для отримання додаткової інформації див. доступ до кластера.

Коли Pod автентифікується як Службовий обліковий запис, його рівень доступу залежить від втулка авторизації та політики, які використовуються.

Облікові дані API автоматично відкликаються, коли Pod видаляється, навіть якщо є завершувачі. Зокрема, облікові дані API відкликаються через 60 секунд після встановленого на Pod значення .metadata.deletionTimestamp (час видалення зазвичай дорівнює часу, коли запит на видалення був прийнятий плюс період належного завершення роботи Pod).

Відмова від автоматичного монтування облікових даних API

Якщо ви не бажаєте, щоб kubelet автоматично монтував облікові дані API ServiceAccount, ви можете відмовитися від такої стандартної поведінки. Ви можете відмовитися від автоматичного монтування облікових даних API у /var/run/secrets/kubernetes.io/serviceaccount/token для службового облікового запису, встановивши значення automountServiceAccountToken: false у ServiceAccount:

Наприклад:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
automountServiceAccountToken: false
...

Ви також можете відмовитися від автоматичного монтування облікових даних API для певного Podʼа:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...

Якщо як ServiceAccount, так і .spec Podʼа вказують значення для automountServiceAccountToken, специфікація Podʼа має перевагу.

Використання більше ніж одного ServiceAccount

У кожному просторі імен є принаймні один ServiceAccount: типовий ServiceAccount, який називається default. Ви можете переглянути всі ресурси ServiceAccount у вашому поточному просторі імен за допомогою:

kubectl get serviceaccounts

Вихідні дані схожі на наступні:

NAME      SECRETS    AGE
default   1          1d

Ви можете створити додаткові обʼєкти ServiceAccount таким чином:

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF

Імʼя обʼєкта ServiceAccount повинно бути дійсним DNS-піддоменним імʼям.

Якщо ви отримуєте повний дамп обʼєкта ServiceAccount, подібний до цього:

kubectl get serviceaccounts/build-robot -o yaml

Вихідні дані схожі на наступні:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2019-06-16T00:12:34Z
  name: build-robot
  namespace: default
  resourceVersion: "272500"
  uid: 721ab723-13bc-11e5-aec2-42010af0021e

Ви можете використовувати розширення дозволів для встановлення дозволів на облікові записи служб.

Щоб використовувати не-стандартний обліковий запис, встановіть поле spec.serviceAccountName Podʼа на імʼя ServiceAccount, який ви хочете використовувати.

Ви можете встановити лише поле serviceAccountName при створенні Podʼа або в шаблоні для нового Podʼа. Ви не можете оновлювати поле .spec.serviceAccountName Podʼа, який вже існує.

Очищення

Якщо ви спробували створити ServiceAccount build-robot з прикладу вище, ви можете видалити його виконавши:

kubectl delete serviceaccount/build-robot

Вручну створіть API-токен для ServiceAccount

Припустимо, у вас вже є службовий обліковий запис з назвою "build-robot", як зазначено вище.

Ви можете отримати тимчасовий API-токен для цього ServiceAccount за допомогою kubectl:

kubectl create token build-robot

Вихідні дані з цієї команди — це токен, який ви можете використовувати для автентифікації цього ServiceAccount. Ви можете запросити певний час дії токена, використовуючи аргумент командного рядка --duration для kubectl create token (фактичний час дії виданого токену може бути коротшим або навіть довшим).

Коли увімкнено функції ServiceAccountTokenNodeBinding і ServiceAccountTokenNodeBindingValidation, а також використовується kubectl версії 1.31 або пізнішої, можна створити токен службового облікового запису, який безпосередньо привʼязаний до Node.

kubectl create token build-robot --bound-object-kind Node --bound-object-name node-001 --bound-object-uid 123...456

Токен буде чинний до закінчення його терміну дії або до видалення відповідного вузла чи службового облікового запису.

Вручну створіть довговічний API-токен для ServiceAccount

Якщо ви бажаєте отримати API-токен для службового облікового запису, ви створюєте новий Secret з особливою анотацією kubernetes.io/service-account.name.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF

Якщо ви переглянете Secret використовуючи:

kubectl get secret/build-robot-secret -o yaml

ви побачите, що тепер Secret містить API-токен для ServiceAccount "build-robot".

Через анотацію, яку ви встановили, панель управління автоматично генерує токен для цього службового облікового запису і зберігає їх у відповідному Secret. Крім того, панель управління також очищає токени для видалених облікових записів служб.

kubectl describe secrets/build-robot-secret

Вивід схожий на такий:

Name:           build-robot-secret
Namespace:      default
Labels:         <none>
Annotations:    kubernetes.io/service-account.name: build-robot
                kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1338 байтів
namespace:      7 байтів
token:          ...

При видаленні ServiceAccount, який має відповідний Secret, панель управління Kubernetes автоматично очищає довговічний токен з цього Secret.

Додайте ImagePullSecrets до ServiceAccount

Спочатку створіть imagePullSecret. Потім перевірте, чи він був створений. Наприклад:

• Створіть imagePullSecret, як описано в Вказування ImagePullSecrets в контейнері.

  kubectl create secret docker-registry myregistrykey --docker-server=<імʼя реєстру> \
          --docker-username=ІМ'Я_КОРИСТУВАЧА --docker-password=ПАРОЛЬ_ДЛЯ_DOCKER \
          --docker-email=ЕЛЕКТРОННА_ПОШТА_ДЛЯ_DOCKER
  

• Перевірте, чи він був створений.

  kubectl get secrets myregistrykey
  

  Вивід схожий на такий:

  NAME             TYPE                              DATA    AGE
  myregistrykey    kubernetes.io/.dockerconfigjson   1       1д
  

Додайте imagePullSecret до ServiceAccount

Далі, змініть типовий обліковий запис служби для цього простору імен так, щоб він використовував цей Secret як imagePullSecret.

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

Ви можете досягти того ж самого результату, відредагувавши обʼєкт вручну:

kubectl edit serviceaccount/default

Вивід файлу sa.yaml буде схожий на такий:

Вибраний вами текстовий редактор відкриється з конфігурацією, що схожа на цю:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  resourceVersion: "243024"
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6

За допомогою вашого редактора видаліть рядок з ключем resourceVersion, додайте рядки для imagePullSecrets: та збережіть це. Залиште значення uid таким же, як ви його знайшли.

Після внесення змін, відредагований ServiceAccount виглядатиме схоже на це:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
  - name: myregistrykey

Перевірте, що imagePullSecrets встановлені для нових Podʼів

Тепер, коли створюється новий Pod у поточному просторі імен і використовується типовий ServiceAccount, у новому Podʼі автоматично встановлюється поле spec.imagePullSecrets:

kubectl run nginx --image=<імʼя реєстру>/nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'

Вивід:

myregistrykey

Проєцювання токенів ServiceAccount

Kubelet також може проєцювати токен ServiceAccount в Pod. Ви можете вказати бажані властивості токена, такі як аудиторія та тривалість дії. Ці властивості не конфігуруються для типового токена ServiceAccount. Токен також стане недійсним щодо API, коли будь-який з Podʼів або ServiceAccount буде видалено.

Ви можете налаштувати цю поведінку для spec Podʼа за допомогою типу projected тому, що називається ServiceAccountToken.

Токен з цього projected тому — JSON Web Token (JWT). JSON-вміст цього токена слідує чітко визначеній схемі — приклад вмісту для токена, повʼязаного з Pod:

{
  "aud": [  # відповідає запитаним аудиторіям або стандартним аудиторіям API-сервера, якщо явно не запитано
    "https://kubernetes.default.svc"
  ],
  "exp": 1731613413,
  "iat": 1700077413,
  "iss": "https://kubernetes.default.svc",  # відповідає першому значенню, переданому прапорцю --service-account-issuer
  "jti": "ea28ed49-2e11-4280-9ec5-bc3d1d84661a",  # Функція ServiceAccountTokenJTI повинна бути активована для того, щоб вимагати присутності цього запиту
  "kubernetes.io": {
    "namespace": "kube-system",
    "node": {  # Функція ServiceAccountTokenPodNodeInfo повинна бути активована для того, щоб API-сервер додавав цей запит посилання на вузол
      "name": "127.0.0.1",
      "uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
    },
    "pod": {
      "name": "coredns-69cbfb9798-jv9gn",
      "uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
    },
    "serviceaccount": {
      "name": "coredns",
      "uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
    },
    "warnafter": 1700081020
  },
  "nbf": 1700077413,
  "sub": "system:serviceaccount:kube-system:coredns"
}

Запуск Podʼа з використанням проєцювання токену службового облікового запису

Щоб надати Podʼу токен з аудиторією vault та терміном дії дві години, ви можете визначити маніфест Podʼа, схожий на цей:

pods/pod-projected-svc-token.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

Створіть Pod:

kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml

Kubelet буде: запитувати та зберігати токен від імені Podʼа; робити токен доступним для Podʼа за налаштованим шляхом до файлу; і оновлювати токен поблизу його закінчення. Kubelet активно запитує ротацію для токена, якщо він старший, ніж 80% від загального часу життя (TTL), або якщо токен старший, ніж 24 години.

Застосунок відповідає за перезавантаження токена при його ротації. Зазвичай для застосунку достатньо завантажувати токен за розкладом (наприклад: один раз кожні 5 хвилин), без відстеження фактичного часу закінчення.

Виявлення емітента службового облікового запису

Якщо ви увімкнули проєцювання токенів для ServiceAccounts у вашому кластері, то ви також можете скористатися функцією виявлення. Kubernetes надає спосіб клієнтам обʼєднуватись як постачальник ідентифікаційних даних, щоб одна або кілька зовнішніх систем могли діяти як сторона, що їм довіряє.

Якщо увімкнено, Kubernetes API-сервер публікує документ конфігурації постачальника OpenID через HTTP. Документ конфігурації публікується за адресою /.well-known/openid-configuration. Документ конфігурації OpenID постачальника іноді називається документом виявлення. Kubernetes API-сервер також публікує повʼязаний набір ключів JSON Web (JWKS), також через HTTP, за адресою /openid/v1/jwks.

Кластери, які використовують RBAC, включають типову роль кластера з назвою system:service-account-issuer-discovery. Типовий ClusterRoleBinding надає цю роль групі system:serviceaccounts, до якої неявно належать всі ServiceAccounts. Це дозволяє Podʼам, які працюють у кластері, отримувати доступ до документа виявлення службового облікового запису через їх змонтований токен службового облікового запису. Адміністратори також можуть вибрати привʼязку ролі до system:authenticated або system:unauthenticated залежно від їх вимог до безпеки та зовнішніх систем, з якими вони мають намір обʼєднуватись.

Відповідь JWKS містить публічні ключі, які може використовувати залежна сторона для перевірки токенів службових облікових записів Kubernetes. Залежні сторони спочатку запитують конфігурацію постачальника OpenID, а потім використовують поле jwks_uri у відповіді, щоб знайти JWKS.

У багатьох випадках API-сервери Kubernetes не доступні через глобальну мережу, але публічні точки доступу, які обслуговують кешовані відповіді від API-сервера, можуть бути доступні для користувачів або постачальників послуг. У таких випадках можливо перевизначити jwks_uri в конфігурації постачальника OpenID, щоб вона вказувала на глобальну точку доступу, а не на адресу API-сервера, передаючи прапорець --service-account-jwks-uri до API-сервера. Як і URL емітента, URI JWKS повинен використовувати схему https.

Що далі

Дивіться також:

• Прочитайте Посібник адміністратора кластера щодо службових облікових записів
• Дізнайтеся про Авторизацію в Kubernetes
• Дізнайтеся про Secret
  • або, як розподіляти облікові дані безпечно за допомогою Secret
  • але також майте на увазі, що використання Secret для автентифікації як службового облікового запису є застарілим. Рекомендований альтернативний метод — проєціювання токенів службового облікового запису.
• Дізнайтеся про projected томи.
• Для ознайомлення з OIDC discovery, прочитайте Попередній перегляд пропозиції щодо підпису токена службового облікового запису щодо покращення Kubernetes
• Прочитайте Специфікацію виявлення OIDC