Downward API
Іноді корисно, щоб контейнер мав інформацію про себе, не будучи занадто повʼязаним із Kubernetes. downward API дозволяє контейнерам використовувати інформацію про себе чи кластер, не використовуючи клієнт Kubernetes або API-сервер.
Наприклад, поточний застосунок, який передбачає, що відома змінна середовища містить унікальний ідентифікатор. Однією з можливостей є обгортання застосунку, але це нудно та помилкове, і воно суперечить меті вільного звʼязку. Кращий варіант — використовувати імʼя Podʼу як ідентифікатор та впровадити імʼя Podʼу у відому змінну середовища.
В Kubernetes існують два способи використання полів обʼєкта Pod та контейнера:
Разом ці два способи використання полів обʼєкта Pod та контейнера називають downward API.
Доступні поля
Через downward API доступні не всі поля обʼєкта Kubernetes API. У цьому розділі перераховано доступні поля.
Ви можете передавати інформацію з доступних полів рівня Pod, використовуючи fieldRef. На рівні API spec для Pod завжди визначає принаймні один Контейнер. Ви можете передавати інформацію з доступних полів рівня Container, використовуючи
resourceFieldRef.
Інформація, доступна за допомогою fieldRef
Для деяких полів рівня Pod ви можете передати їх контейнеру як змінні середовища або використовуючи том downwardAPI. Поля, доступні через обидва механізми, наступні:
metadata.name- імʼя Pod
metadata.namespace- namespace Pod
metadata.uid- унікальний ідентифікатор Pod
metadata.annotations['<KEY>']- значення аннотації Pod з іменем
<KEY>(наприклад,metadata.annotations['myannotation']) metadata.labels['<KEY>']- текстове значення мітки Pod з іменем
<KEY>(наприклад,metadata.labels['mylabel'])
Наступна інформація доступна через змінні середовища, але не як поле fieldRef тома downwardAPI:
spec.serviceAccountName- імʼя service account Pod
spec.nodeName- імʼя вузла, на якому виконується Pod
status.hostIP- основна IP-адреса вузла, до якого призначено Pod
status.hostIPs- IP-адреси — це версія подвійного стека
status.hostIP, перша завжди така сама, як іstatus.hostIP. status.podIP- основна IP-адреса Pod (зазвичай, його IPv4-адреса)
status.podIPs- IP-адреси — це версія подвійного стека
status.podIP, перша завжди така сама, як іstatus.podIP
Наступна інформація доступна через том downwardAPI fieldRef, але не як змінні середовища:
metadata.labels- всі мітки Pod, в форматі
label-key="escaped-label-value"з однією міткою на рядок metadata.annotations- всі аннотації поду, у форматі
annotation-key="escaped-annotation-value"з однією аннотацією на рядок
Інформація, доступна за допомогою resourceFieldRef
Ці поля рівня контейнера дозволяють надавати інформацію про вимоги та обмеження для ресурсів, таких як CPU та памʼять.
resource: limits.cpu- Обмеження CPU контейнера
resource: requests.cpu- Вимога CPU контейнера
resource: limits.memory- Обмеження памʼяті контейнера
resource: requests.memory- Вимога памʼяті контейнера
resource: limits.hugepages-*- Обмеження hugepages контейнера
resource: requests.hugepages-*- Вимога hugepages контейнера
resource: limits.ephemeral-storage- Обмеження ефемерних сховищ контейнера
resource: requests.ephemeral-storage- Вимога ефемерних сховищ контейнера
Резервні інформаційні обмеження для ресурсів
Якщо ліміти CPU та памʼяті не вказані для контейнера, і ви використовуєте downward API для спроби викриття цієї інформації, тоді kubelet типово використовує значення для CPU та памʼяті на основі розрахунку розподілених вузлів.
Що далі
Ви можете прочитати про томи downwardAPI.
Ви можете спробувати використовувати downward API для поширення інформації на рівні контейнера чи Pod: