# Projected томи
LLMS index: [llms.txt](/llms.txt)
---
У цьому документі описано _проєкційні томи_ в Kubernetes. Рекомендується ознайомитися з [томами](/docs/concepts/storage/volumes/) для кращого розуміння.
## Вступ {#introduction}
Том `projected` відображає кілька наявних джерел томів в одну теку.
Зараз наступні типи джерел томів можуть бути проєкційні:
* [`secret`](/docs/concepts/storage/volumes/#secret)
* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi)
* [`configMap`](/docs/concepts/storage/volumes/#configmap)
* [`serviceAccountToken`](#serviceaccounttoken)
* [`clusterTrustBundle`](#clustertrustbundle)
* [`podCertificate`](#podcertificate)
Всі джерела повинні бути в тому ж просторі імен, що й Pod. Для отримання додаткових відомостей дивіться документ з дизайну [все-в-одному томі](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md).
### Приклад конфігурації з secret, downwardAPI та configMap {#example-configuration-secret-downwardapi-configmap}
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox:1.28
command: ["sleep", "3600"]
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "cpu_limit"
resourceFieldRef:
containerName: container-test
resource: limits.cpu
- configMap:
name: myconfigmap
items:
- key: config
path: my-group/my-config
### Приклад конфігурації: secret з встановленим нестандартним режимом дозволу {#example-configuration-secrets-nondefault-permission-mode}
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox:1.28
command: ["sleep", "3600"]
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- secret:
name: mysecret2
items:
- key: password
path: my-group/my-password
mode: 0777
Кожне джерело проєкційного тому перераховане в специфікації в розділі `sources`. Параметри майже такі ж, за винятком двох пунктів:
* Для секретів поле `secretName` було змінено на `name`, щоб бути послідовним з назвою ConfigMap.
* `defaultMode` можна вказати тільки на рівні проєкційного тому, а не для кожного джерела тому. Однак, як показано вище, ви можете явно встановити `mode` для кожної окремої проєкції.
## Проєкційні томи serviceAccountToken {#serviceaccounttoken}
Ви можете зробити інʼєкцію токена для поточного [service accountʼу](/docs/reference/access-authn-authz/authentication/#service-account-tokens) в Pod за вказаним шляхом. Наприклад:
apiVersion: v1
kind: Pod
metadata:
name: sa-token-test
spec:
containers:
- name: container-test
image: busybox:1.28
command: ["sleep", "3600"]
volumeMounts:
- name: token-vol
mountPath: "/service-account"
readOnly: true
serviceAccountName: default
volumes:
- name: token-vol
projected:
sources:
- serviceAccountToken:
audience: api
expirationSeconds: 3600
path: token
Pod в прикладі має project том, що містить інʼєктований токен service account. Контейнери в цьому Pod можуть використовувати цей токен для доступу до сервера API Kubernetes, автентифікуючись за відомостями [service accountʼу Pod](/docs/tasks/configure-pod-container/configure-service-account/). Поле `audience` містить призначену аудиторію токена. Отримувач токена повинен ідентифікувати себе за ідентифікатором, вказаним в аудиторії токена, інакше він повинен відхилити токен. Це поле є необовʼязковим, але стандартним для ідентифікації в API сервері.
Поле `expirationSeconds` містить час, через який токен стане недійсним. Типовим є час в одну годину, але він має бути принаймні 10 хвилин (600 секунд). Адміністратор може обмежити максимальне значення вказавши параметр `--service-account-max-token-expiration` в API сервері. Поле `path` містить відносний шлях до точки монтування тому.
Примітка:
Контейнер, що використовує джерела project томів як
subPath для монтування тому не отримуватиме оновлення для цих джерел.
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.33 [beta](стандартно вимкнено)
Примітка:
Для використання цієї функції в Kubernetes {{ skew currentVersion }} вам потрібно увімкнути підтримку обʼєктів ClusterTrustBundle з
функціональною можливістю ClusterTrustBundle та прапорцем
--runtime-config=certificates.k8s.io/v1beta1/clustertrustbundles=true в kube-apiserver, а потім увімкнути функцію
ClusterTrustBundleProjection.
apiVersion: v1
kind: Pod
metadata:
name: sa-ctb-name-test
spec:
containers:
- name: container-test
image: busybox
command: ["sleep", "3600"]
volumeMounts:
- name: token-vol
mountPath: "/root-certificates"
readOnly: true
serviceAccountName: default
volumes:
- name: token-vol
projected:
sources:
- clusterTrustBundle:
name: example
path: example-roots.pem
- clusterTrustBundle:
signerName: "example.com/mysigner"
labelSelector:
matchLabels:
version: live
path: mysigner-roots.pem
optional: true
## Спроєцьовані томи podCertificate {#podcertificate}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.35 [beta](стандартно вимкнено)
Примітка:
В Kubernetes 1.36, ви повинні увімкнути підтримку Pod Certificates, використовуючи
функціональну можливість PodCertificateRequest та прапорець
--runtime-config=certificates.k8s.io/v1beta1/podcertificaterequests=true kube-apiserver.
Примітка:
Більшість застосунків повинні віддавати перевагу використанню credentialBundlePath, якщо їм не потрібні ключ і сертифікати в окремих файлах з причин сумісності. Kubelet використовує атомарну стратегію запису на основі символічних посилань, щоб переконатися, що коли ви відкриваєте файли, для яких він виконує проєкцію, ви читаєте або старий вміст, або новий вміст. Однак, якщо ви читаєте ключ і ланцюг сертифікатів з окремих файлів, Kubelet може обернути облікові дані після вашого першого читання і до вашого другого читання, в результаті чого ваш застосунок завантажить невідповідний ключ і сертифікат.
# Приклад специфікації Pod, яка використовує проекцію podCertificate для запиту приватного ключа ED25519,
# сертифіката від підписувача `coolcert.example.com/foo` та
# запису результатів у `/var/run/my-x509-credentials/credentialbundle.pem`.
apiVersion: v1
kind: Pod
metadata:
namespace: default
name: podcertificate-pod
spec:
serviceAccountName: default
containers:
- image: debian
name: main
command: ["sleep", "infinity"]
volumeMounts:
- name: my-x509-credentials
mountPath: /var/run/my-x509-credentials
volumes:
- name: my-x509-credentials
projected:
defaultMode: 0644
sources:
- podCertificate:
keyType: ED25519
signerName: coolcert.example.com/foo
credentialBundlePath: credentialbundle.pem
userAnnotations:
example.com/annotation1: "value1"
example.com/annotation2: "value2"
## Взаємодія SecurityContext {#securitycontext-interactions}
[Пропозиція](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) щодо обробки дозволів файлів у розширенні projected service account volume представляє, що projected файли мають відповідні набори дозволів власника.
### Linux
У Podʼах Linux, які мають projected том та `RunAsUser` вказано у [`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context), projected файли мають правильно встановлені права власності, включаючи власника контейнера.
Коли у всіх контейнерах в Podʼі встановлено одне й те ж `runAsUser` у їх
[`PodSecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) або [`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1), то kubelet гарантує, що вміст тому `serviceAccountToken` належить цьому користувачеві, а файл токена має режим дозволів, встановлений в `0600`.
Примітка:
ефемерні контейнери додані до Podʼа після його створення не змінюють прав доступу до тому, які були встановлені при створенні Podʼа.
Якщо права доступу до тому serviceAccountToken Podʼа були встановлені на 0600, тому що всі інші контейнери в Podʼі мають одне і те ж runAsUser, ефемерні контейнери повинні використовувати той самий runAsUser, щоб мати змогу читати токен.
Примітка:
Загалом не рекомендується надавати контейнеру доступ до хосту, оскільки це може відкрити можливості для потенційних використань дірок безпеки.
Створення Windows Podʼа з RunAsUser в його SecurityContext призведе до того, що Pod буде застрягати на стадії ContainerCreating назавжди. Таким чином, рекомендується не використовувати опцію RunAsUser, яка призначена лише для Linux, з Windows Podʼами.
