` (наприклад, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
При використанні теґів образів, якщо реєстр образів змінив код, який представляє теґ вашого образу, ви могли б отримати суміш Podʼів, що запускають старий і новий код. Дайджест образу унікально ідентифікує конкретну версію образу, тому Kubernetes запускає один і той же код кожного разу, коли він запускає контейнер із вказаним імʼям образу та дайджестом. Зазначення образу за допомогою дайджесту фіксує код, який ви запускаєте, так що зміна в реєстрі не може призвести до такого змішаного використання версій.
Є сторонні [контролери допуску](/docs/reference/access-authn-authz/admission-controllers/) що змінюють Pod (і PodTemplates), коли вони створюються, так що робоче навантаження визначається на основі хешу образу, а не теґу. Це може бути корисно, якщо ви хочете переконатися, що ваші робочі навантаження запускають один і той самий код, незалежно від того, які зміни теґів відбуваються в реєстрі.
#### Стандартні політики завантаження образів {#imagepullpolicy-defaulting}
Коли ви (чи контролер) подаєте новий Pod серверу API, ваш кластер встановлює поле `imagePullPolicy` при виконанні певних умов:
- якщо ви опускаєте поле `imagePullPolicy` та вказуєте хеш для образів контейнерів, `imagePullPolicy` автоматично встановлюється в `IfNotPresent`.
- якщо ви опускаєте поле `imagePullPolicy` та теґ для образів контейнерів є `:latest`, `imagePullPolicy` автоматично встановлюється в `Always`;
- якщо ви опускаєте поле `imagePullPolicy` та не вказуєте теґ для образів контейнерів, `imagePullPolicy` автоматично встановлюється в `Always`;
- якщо ви опускаєте поле `imagePullPolicy` та вказуєте теґ для образів контейнерів, який не є `:latest`, `imagePullPolicy` автоматично встановлюється в `IfNotPresent`.
Примітка:
Значення imagePullPolicy контейнера завжди встановлюється при першому створенні обʼєкта і не оновлюється, якщо теґ чи хеш образів пізніше зміниться.
Наприклад, якщо ви створите Deployment з образом, теґ якого не є :latest, і пізніше оновите образ цього Deployment до теґу :latest, поле imagePullPolicy не зміниться на Always. Вам слід вручну змінити політику завантаження для будь-якого обʼєкта після його початкового створення.
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.29 [alpha](стандартно вимкнено)
У Kubernetes є альфа-підтримка для виконання завантаження образів на основі класу середовища виконання контейнерів Pod.
Якщо ви увімкнете [функціональну можливість](/docs/reference/command-line-tools-reference/feature-gates/) `RuntimeClassInImageCriApi`, kubelet вказує образи контейнерів кортежем (назва образу, обробник), а не лише назва чи хеш образу. Ваше середовище виконання контейнерів може адаптувати свою поведінку залежно від обраного обробника. Завантаження образів на основі класу середовища виконання буде корисним для контейнерів, що використовують віртуальні машини, таких як контейнери Windows Hyper-V.
## Послідовне та паралельне завантаження образів {#serial-and-parallel-image-pulls}
Типово kubelet завантажує образи послідовно. Іншими словами, kubelet надсилає лише один запит на завантаження образу до служби образів одночасно. Інші запити на завантаження образів мають чекати, поки завершиться обробка того, який знаходиться в процесі.
Вузли приймають рішення про завантаження образу незалежно один від одного. Навіть коли ви використовуєте послідовні запити на завантаження образів, два різні вузли можуть завантажувати один і той самий образ паралельно.
Якщо ви хочете увімкнути паралельне завантаження образів, ви можете встановити поле `serializeImagePulls` у значення false в [конфігурації kubelet](/docs/reference/config-api/kubelet-config.v1beta1/). Зі значенням `serializeImagePulls` встановленим у false, запити на завантаження образів будуть надсилатись до служби образів негайно, і кілька образів буде завантажено одночасно.
При увімкненні паралельного завантаження образів, будь ласка, переконайтеся, що служба образів вашого середовища виконання контейнерів може обробляти паралельне завантаження образів.
Kubelet ніколи не завантажує кілька образів паралельно від імені одного Pod. Наприклад, якщо у вас є Pod із контейнером ініціалізації та контейнером застосунку, завантаження образів для цих двох контейнерів не буде виконуватись паралельно. Однак якщо у вас є два Podʼи, які використовують різні образи, kubelet завантажує образи паралельно для цих двох різних Podʼів, коли увімкнено паралельне завантаження образів.
### Максимальна кількість паралельних завантажень образів {#maximum-parallel-image-pulls}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.35 [stable]
Коли `serializeImagePulls` встановлено в значення false, kubelet стандартно не обмежує максимальну кількість образів, які завантажуються одночасно. Якщо ви хочете обмежити кількість паралельних завантажень образів, ви можете встановити поле `maxParallelImagePulls` у конфігурації kubelet. Зі значенням `maxParallelImagePulls` в _n_, тільки _n_ образів можуть завантажуватися одночасно, і будь-яке завантаження образу за межами _n_ буде чекати, поки завершиться принаймні одне завантаження образу, яке вже триває.
Обмеження кількості паралельних завантажень образів допоможе уникнути зайвого використання пропускної здатності мережі або дискових операцій вводу/виводу, коли увімкнено паралельне завантаження образів.
Ви можете встановити `maxParallelImagePulls` на позитивне число, яке більше або рівне 1. Якщо ви встановите `maxParallelImagePulls` більше або рівне 2, ви повинні встановити `serializeImagePulls` в значення false. Kubelet не буде запущено з недійсними налаштуваннями `maxParallelImagePulls`.
## Мультиархітектурні образи з індексами образів {#multi-architecture-images-with-image-indexes}
Окрім надання бінарних образів, реєстр контейнерів також може обслуговувати [індекс образу контейнера](https://github.com/opencontainers/image-spec/blob/master/image-index.md). Індекс образу може посилатися на кілька [маніфестів образу](https://github.com/opencontainers/image-spec/blob/master/manifest.md) для версій контейнера, специфічних для архітектури. Ідея полягає в тому, що ви можете мати імʼя для образу (наприклад: `pause`, `example/mycontainer`, `kube-apiserver`) та дозволити різним системам отримувати правильний бінарний образ для використання на їхній архітектурі машини.
Сам Kubernetes зазвичай називає образи контейнерів зі своїми релізами з використанням суфіксу `-$(ARCH)`. З метою забезпечення сумісності з попередніми версіями, будь ласка, генеруйте старіші образи із суфіксами. Ідея полягає в тому, щоб створити, наприклад, образ `pause`, який має маніфест для всіх архітектур, та скажімо `pause-amd64`, який є сумісним з попередніми конфігураціями або файлами YAML, які можуть містити жорстко закодовані образи із суфіксами.
## Використання приватних реєстрів {#using-a-private-registry}
Приватні реєстри можуть вимагати автентифікації для читання та отримання образів з них. Облікові дані можна надати кількома способами:
- Через [зазначення `imagePullSecrets` у визначенні Podʼа](#specifying-imagepullsecrets-on-a-pod)
Доступ до приватного реєстру мають лише ті Podʼи, які надали власні ключі.
- Шляхом [Налаштування Візлів для автентифікації в приватному](#configuring-nodes-to-authenticate-to-a-private-registry) - Всі Podʼи можуть читати будь-які налаштовані приватні реєстри
- Вимагає конфігурації вузла адміністратором кластера
- Використання втулка _kubelet credential provider_ для [динамічного отримання облікових даних для приватних реєстрів](#kubelet-credential-provider)
kubelet може бути налаштований для використання втулка від постачальника облікових даних для відповідного приватного реєстру.
- [Попередньо завантажені образи](#pre-pulled-images)
- Всі Podʼи можуть використовувати будь-які образи, кешовані на вузлі
- Вимагає root-доступу на всіх вузлах для налаштування
Якщо ви використовуєте власну конфігурацію вузла, ви (або ваш постачальник хмари) можете реалізувати власний механізм автентифікації вузла в реєстрі контейнерів.
Ці варіанти пояснюються докладніше нижче.
### Зазначення `imagePullSecrets` в Podʼі {#specifying-imagepullsecrets-on-a-pod}
Примітка:
Це рекомендований підхід для запуску контейнерів на основі образів з приватних реєстрів.
У Kubernetes підтримується вказівка ключів реєстру образів контейнерів у Pod. Усі `imagePullSecrets` мають бути Секретами, які існують у тому ж Namespace, що і Pod. Ці секрети мають бути типу `kubernetes.io/dockercfg` або `kubernetes.io/dockerconfigjson`.
### Налаштування вузлів для автентифікації в приватному реєстрі {#configuring-nodes-to-authenticate-to-a-private-registry}
Конкретні інструкції щодо встановлення облікових даних залежать від середовища виконання контейнерів та реєстру, який ви вибрали для використання. Вам слід звертатися до документації щодо вашого рішення для отримання найточнішої інформації.
Для прикладу конфігурування приватного реєстру образів контейнерів дивіться завдання [Завантаження образу з приватного реєстру](/docs/tasks/configure-pod-container/pull-image-private-registry). У цьому прикладі використовується приватний реєстр в Docker Hub.
### Постачальник облікових даних Kubelet для отримання автентифікованих образів {#kubelet-credential-provider}
Ви можете налаштувати kubelet для виклику бінарного втулка, щоб динамічно отримувати облікові дані реєстру для образу контейнера. Це найнадійніший та універсальний спосіб отримання облікових даних для приватних реєстрів, але також вимагає конфігурації kubelet для його увімкнення.
Ця техніка може бути особливо корисною для запуску static Pods, які потребують образів контейнерів, розміщених у приватному реєстрі. Використання ServiceAccount або Secret для надання облікових даних приватного реєстру є неможливим у специфікації статичного Pod, оскільки він _не може_ мати посилань на інші ресурси API у своїй специфікації.
Докладніше дивіться [Налаштування постачальника облікових даних образу kubelet](/docs/tasks/administer-cluster/kubelet-credential-provider/).
### Тлумачення файлу config.json {#config-json}
Тлумачення `config.json` відрізняється між оригінальною реалізацією Docker та тлумаченням Kubernetes. У Docker ключі `auths` можуть вказувати тільки кореневі URL-адреси, тоді як Kubernetes дозволяє використовувати глобальні URL-адреси, а також шляхи, які відповідають префіксу. Єдиним обмеженням є те, що глобальні шаблони (`*`) повинні включати крапку (`.`) для кожного піддомену. Кількість піддоменів, що мають збіг, повинна дорівнювати кількості глобальних шаблонів (`*.`), наприклад:
- `*.kubernetes.io` _не_ збігатиметься з `kubernetes.io`, але збігатиметься з `abc.kubernetes.io`
- `*.*.kubernetes.io` _не_ збігатиметься з `abc.kubernetes.io`, але збігатиметься з `abc.def.kubernetes.io`
- `prefix.*.io` збігатиметься з `prefix.kubernetes.io`
- `*-good.kubernetes.io` збігатиметься з `prefix-good.kubernetes.io`
Це означає, що файл `config.json`, подібний до цього, є дійсним:
```json
{
"auths": {
"my-registry.example/images": { "auth": "…" },
"*.my-registry.example/images": { "auth": "…" }
}
}
```
Операції отримання образів тепер будуть передавати облікові дані CRI контейнеру для кожного дійсного шаблону. Наприклад, образи контейнера, вказані нижче, матимуть збіг:
- `my-registry.example/images`
- `my-registry.example/images/my-image`
- `my-registry.example/images/another-image`
- `sub.my-registry.example/images/my-image`
Але не:
- `a.sub.my-registry.example/images/my-image`
- `a.b.sub.my-registry.example/images/my-image`
Kubelet виконує операції отримання образів послідовно для кожного знайденого облікового запису. Це означає, що можливі кілька записів у `config.json` для різних шляхів:
```json
{
"auths": {
"my-registry.example/images": {
"auth": "…"
},
"my-registry.example/images/subpath": {
"auth": "…"
}
}
}
```
Тепер, якщо контейнер вказує образ `my-registry.example/images/subpath/my-image`, то kubelet спробує завантажити його з обох джерел автентифікації, якщо завантаження з одного з них виявиться невдалим.
### Попередньо завантажені образи {#pre-pulled-images}
Примітка:
Цей підхід підходить, якщо ви можете контролювати конфігурацію вузла. Він не буде надійно працювати, якщо ваш постачальник хмари управляє вузлами та автоматично їх замінює.
Типово kubelet намагається отримати кожен образ з вказаного реєстру. Однак якщо властивість `imagePullPolicy` контейнера встановлена на `IfNotPresent` або `Never`, то використовується локальний образ (переважно або виключно, відповідно).
Якщо ви хочете покладатися на попередньо завантажені образи як заміну автентифікації в реєстрі, вам слід переконатися, що всі вузли кластера мають однакові попередньо завантажені образи.
Це може бути використано для попереднього завантаження певних образів для швидкості або як альтернатива автентифікації в приватному реєстрі.
Подібно до використання [постачальника облікових даних kubelet](#kubelet-credential-provider), попередньо завантажені образи також підходять для запуску static Pods, які залежать від образів, розміщених у приватному реєстрі.
### Перевірка облікових даних при отриманні образів {#ensureimagepullcredentialverification}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.35 [beta](стандартно увімкнено)
Якщо увімкнено функціональну можливість `KubeletEnsureSecretPulledImages`, Kubernetes перевірятиме облікові дані образів кожного образу, коли це вимагається навіть якщо цей образ вже присутній на вузлі. Ця перевірка гарантує, що образи у запиті на отримання, які не були успішно отримані за допомогою наданих облікових даних, повинні бути повторно отримані з реєстру. Крім того, при повторному отриманні образів з тими самими обліковими даними, які раніше призвели до успішного отримання образів, не потрібно повторно отримувати їх з реєстру, а вони перевіряються локально без доступу до реєстру (за умови, що образ доступний локально). Це контролюється полем `imagePullCredentialsVerificationPolicy` у [конфігурації Kubelet](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-ImagePullCredentialsVerificationPolicy).
Ця конфігурація контролює, коли потрібно перевіряти облікові дані для отримання образів, якщо образ вже присутній на вузлі:
- `NeverVerify`: Імітує поведінку, коли цю функціональну можливість вимкнено. Якщо образ присутній локально, облікові дані для отримання образу не перевірятимуться.
- `NeverVerifyPreloadedImages`: Образи, отримані за межами kubelet, не перевірятимуться, але всі інші образи будуть перевірятися. Це стандартна поведінка.
- `NeverVerifyAllowListedImages`: Образи, отримані поза kubelet і згадані у списку `preloadedImagesVerificationAllowlist`, вказаному у конфігурації kubelet, не перевірятимуться.
- `AlwaysVerify`: Всі образи будуть перевірятися перед тим, як їх буде використано.
Ця перевірка застосовується до [попередньо отриманих образів](#pre-pulled-images), образів, отриманих за допомогою загальновузлових секретів, та образів, отриманих за допомогою секретів на рівні Podʼів.
Примітка:
У випадку ротації облікових даних, облікові дані, які було використано для отримання образу, продовжуватимуть свою перевірку без необхідності звернення до реєстру. Нові або змінені облікові дані вимагатимуть повторного отримання образу з реєстру.
#### Перше увімкнення `KubeletEnsureSecretPulledImages` {#enabling-kubeletensuresecretpulledimages-for-the-first-time}
Коли функція `KubeletEnsureSecretPulledImages` вмикається вперше, або шляхом оновлення kubelet, або шляхом явного ввімкнення цієї функції, і якщо kubelet має доступ до будь-яких образів у цей момент, усі вони вважатимуться попередньо отриманими. Це відбувається тому, що в цьому випадку kubelet не має записів про образи, що отримуються. Kubelet зможе почати створювати записи про отримання образів лише тоді, коли будь-який образ витягується вперше.
Якщо це стосується, рекомендується очистити вузли від усіх образів, які не повинні вважатися попередньо отриманими, перед увімкненням функції.
Зверніть увагу, що видалення теки, що містить записи про отримання образів, матиме той самий ефект при перезапуску kubelet, особливо образи, які зараз кешуються на вузлах через рушій виконання контейнерів, будуть всі вважатися попередньо отриманими.
### Створення Secret з Docker-конфігом {#creating-a-secret-with-a-docker-config}
Вам потрібно знати імʼя користувача, пароль реєстру та адресу електронної пошти клієнта для автентифікації в реєстрі, а також його імʼя хосту. Виконайте наступну команду, підставивши відповідні значення замість заповнювачів:
```shell
kubectl create secret docker-registry \
--docker-server= \
--docker-username= \
--docker-password= \
--docker-email=
```
Якщо у вас вже є файл облікових даних Docker, ніж використовувати вищезазначену команду, ви можете імпортувати файл облікових даних як Secret Kubernetes. [Створення Secret на основі наявних облікових даних Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) пояснює, як це зробити.
Це особливо корисно, якщо ви використовуєте кілька приватних реєстрів контейнерів, оскільки `kubectl create secret docker-registry` створює Secret, який працює лише з одним приватним реєстром.
Примітка:
Podʼи можуть посилатися лише на ключі реєстру образів у своєму власному просторі імен, так що цей процес слід виконати один раз для кожного простору імен.
#### Посилання на imagePullSecrets для Pod {#referring-to-imagepullsecrets-on-a-pod}
Тепер ви можете створювати Podʼи, які посилаються на цей secret, додавши розділ `imagePullSecrets` до визначення Pod. Кожен елемент у масиві `imagePullSecrets` може посилатися тільки на Secret у тому ж просторі імен.
Наприклад:
```shell
cat < pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <> ./kustomization.yaml
resources:
- pod.yaml
EOF
```
Це слід робити для кожного Podʼа, який використовує приватний реєстр.
Однак налаштування цього поля можна автоматизувати, встановивши imagePullSecrets в [ресурс ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/). Дивіться [Додавання ImagePullSecrets до службового облікового запису](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) для докладних інструкцій.
Ви можете використовувати це разом із `.docker/config.json` на рівні вузла. Облікові дані об'єднані.
### Сценарії використання {#use-cases}
Існує кілька рішень для конфігурації приватних реєстрів. Ось деякі типові сценарії використання та рекомендовані рішення.
1. Кластер, в якому використовуються лише непропрієтарні (наприклад, відкриті) образи. Немає потреби приховувати образи.
- Використовуйте відкриті образи з відкритого реєстру.
- Конфігурація не потрібна.
- Деякі постачальники хмари автоматично кешують або дзеркалюють відкриті образи, що підвищує доступність та скорочує час їх отримання.
2. Кластер, в якому використовуються деякі пропрієтарні образи, які повинні бути невидимими для інших компаній, але доступними для всіх користувачів кластера.
- Використовуйте приватний реєстр.
- Можлива ручна конфігурація на вузлах, які повинні мати доступ до приватного реєстру.
- Або запустіть внутрішній приватний реєстр за вашим фаєрволом з відкритим доступом на читання.
- Не потрібна конфігурація Kubernetes.
- Використовуйте сервіс реєстрації образів контейнерів, який контролює доступ до образів.
- Він працюватиме краще з автомасштабуванням Вузлів, ніж ручна конфігурація вузла.
- Або на кластері, де зміна конфігурації вузла незручна, використовуйте `imagePullSecrets`.
3. Кластер із проприєтарними образами, кілька з яких вимагають строгого контролю доступу.
- Переконайтеся, що [контролер доступу AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) активний. У протилежному випадку всі Podʼи потенційно мають доступ до всіх образів.
- Перемістіть конфіденційні дані в ресурс Secret, а не додавайте їх в образ.
4. Багатокористувацький кластер, де кожен орендар потребує власного приватного реєстру.
- Переконайтеся, що [контролер доступу AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) активний. У протилежному випадку всі Podʼи всіх орендарів потенційно мають доступ до всіх образів.
- Запустіть приватний реєстр з обовʼязковою авторизацією.
- Створіть обліковий запис реєстру для кожного орендаря, розмістіть його в Secret та внесіть Secret в кожний простір імен орендаря.
- Орендар додає цей Secret до imagePullSecrets кожного простору імен.
Якщо вам потрібен доступ до декількох реєстрів, ви можете створити Secret для кожного реєстру окремо.
## Застарілий вбудований постачальник облікових даних kubelet
У старших версіях Kubernetes kubelet мав пряму інтеграцію з обліковими даними хмарного постачальника. Це давало йому можливість динамічно отримувати облікові дані для реєстрів образів.
Існувало три вбудовані реалізації інтеграції облікових записів kubelet: ACR (Azure Container Registry), ECR (Elastic Container Registry) та GCR (Google Container Registry).
Починаючи з версії Kubernetes v1.26 застарілий механізм було вилучено, тому вам потрібно або:
- налаштувати постачальника облікових записів kubelet на кожному вузлі, або
- вказати облікові дані для отримання образів, використовуючи `imagePullSecrets` та принаймні один Secret.
## Що далі
- Прочитайте [Специфікацію маніфеста образу OCI](https://github.com/opencontainers/image-spec/blob/main/manifest.md).
- Дізнайтеся про [збирання сміття образів контейнерів](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection).
- Дізнайтеся більше про [отримання образу з приватного реєстру](/docs/tasks/configure-pod-container/pull-image-private-registry).