# Podʼи LLMS index: [llms.txt](/llms.txt) --- _Podʼи_ — найменші обчислювальні одиниці, які ви можете створити та керувати ними в Kubernetes. _Pod_ (_ім. чол. рід_; як у випадку з групою китів або гороховим стручком) — це група з одного або кількох , які мають спільні ресурси зберігання та мережі, а також специфікацію щодо того, як запускати контейнери. Вміст Podʼа завжди розташований та запускається разом, та працює в спільному контексті. Pod моделює "логічний хост" для вашого застосунку: він містить один або кілька контейнерів застосунку, які мають відносно тісний звʼязок один з одним. У контексті хмарних обчислень, застосунки, що виконуються на одному фізичному або віртуальному компʼютері, аналогічні застосункам, що виконуються на одному логічному хості. Так само як і контейнери застосунків, Podʼи можуть містити , які запускаються під час старту Podʼа. Ви також можете впровадити для налагодження, якщо ваш кластер це підтримує. ## Що таке Pod? {#what-is-a-pod}

Примітка:

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

Спільний контекст Podʼа — це набір Linux-просторів імен, cgroups та, можливо, інших аспектів ізоляції — тих самих речей, що забезпечують ізоляцію . В межах контексту Podʼа окремі застосунки можуть мати додаткові рівні ізоляції. Pod схожий на набір контейнерів із спільними просторами імен та спільними ресурсами файлових систем. Podʼи в кластері Kubernetes використовуються двома основними способами: * **Podʼи, що керують одним контейнером**. Модель «один контейнер на Pod» є найпоширенішим використанням в Kubernetes. У цьому випадку Pod можна розглядати як обгортку навколо одного контейнера; Kubernetes керує Podʼами, а не контейнерами безпосередньо. * **Podʼи, що керують кількома контейнерами, які мають працювати разом**. Pod може інкапсулювати застосунок, який складається з кількох [розміщених разом контейнерів](#how-pods-manage-multiple-containers), які тісно повʼязані та мають спільні ресурси. Такі контейнери утворюють єдиний обʼєкт. Група кількох контейнерів, розміщених разом в одному Podʼі є відносно складним прикладом. Ви повинні використовувати цей шаблон тільки в конкретних випадках, коли ваші контейнери тісно повʼязані. Для забезпечення реплікації (з метою підвищення відмовостійкості або розширення потужності) не потрібно запускати кілька контейнерів; якщо вам потрібно створити кілька реплік, див. [Керування навантаженням](/docs/concepts/workloads/controllers/). ## Використання Podʼів {#using-pods} Нижче наведено приклад Podʼа, який складається з контейнера, який запускає образ `nginx:1.14.2`.

    pods/simple-pod.yaml
    
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Для створення Podʼа, показаного вище, виконайте наступну команду: ```shell kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml ``` Як правило Podʼи не створюються напряму, навіть одиничні Podʼи. Замість цього, створюйте їх за допомогою ресурсів робочих навантажень. Дивіться [Робота з Podʼами](#working-with-pods) для отримання додаткової інформації про те, як Podʼи використовуються разом з ресурсами робочих навантажень. ### Ресурси робочих навантажень для керування Podʼами {#workload-resources-for-managing-pods} Зазвичай у вас немає потреби у створенні окремих Podʼів напряму в Kubernetes, навіть одиничних Podʼів. Натомість створюйте їх за допомогою ресурсів робочих навантажень, таких як або . Якщо ваші Podʼи потребують відстеження стану, розгляньте використання ресурсу . Кожен Pod призначений для запуску одного екземпляра застосунку. Якщо ви хочете масштабувати свій застосунок горизонтально (щоб надати більше ресурсів, запустивши більше екземплярів), вам слід використовувати кілька Podʼів, по одному для кожного екземпляра. У Kubernetes це зазвичай називається _реплікацією_. Репліковані Podʼи створюються та керуються як група ресурсів робочих навантажень разом з їх . Ознайомтесь з розділом [Podʼи та контролери](#pods-and-controllers) для отримання додаткової інформації про те, як Kubernetes використовує ресурси робочих навантажень та їх контролери для реалізації масштабування та автоматичного відновлення роботи застосунку. Podʼи можуть надавати два види спільних ресурсів для своїх підпорядкованих контейнерів: [мережу](#pod-networking) та [зберігання](#pod-storage). ## Робота з Podʼами {#working-with-pods} Ви навряд чи створюватимете окремі Podʼи напряму в Kubernetes, навіть одиничні Podʼи. Це тому, що Podʼи спроєктовано бути відносно ефемерними, одноразовими обʼєктами, які можуть бути втрачені в будь-який момент. Коли Pod створено (чи це зроблено вами, чи це зроблено автоматично за допомогою ), новий Pod планується на виконання на вашого кластера. Pod залишається на цьому вузлі до тих пір, поки він не завершить роботу, або обʼєкт Pod буде видалено, Pod буде _виселено_ за відсутності ресурсів, або вузол зазнав збою.

Примітка:

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

Назва Podʼа має бути дійсним [DNS-піддоменом](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призвести до неочікуваних результатів для імені хосту Podʼа. Для найкращої сумісності, імʼя має відповідати більш обмеженим правилам для [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). ### Операційна система Podʼа {#pod-os}

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Ви маєте встановити значення поля `.spec.os.name` як `windows` або `linux`, щоб визначити операційну систему, яку потребують контейнери в цьому Podʼі. Ці дві ОС підтримуються Kubernetes. У майбутньому цей список може бути розширений. Kubelet відмовляється запускати Pod, якщо значення `.spec.os.name` не відповідає операційній системі вузла. Однак у Kubernetes v1.36 значення `.spec.os.name` не впливає на те, як вибирає вузол для запуску Podʼа. У будь-якому кластері, де для робочих вузлів використовується більше однієї операційної системи, слід правильно встановити мітку [kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os) на кожному вузлі та визначити Podʼи параметром `nodeSelector`, що базується на мітці операційної системи. Kube-scheduler призначає ваш Pod на вузол на основі інших критеріїв і може успішно або невдало вибрати відповідне розміщення вузла, де ОС вузла підходить для контейнерів у цьому Podʼі. [Стандарти безпеки Podʼів](/docs/concepts/security/pod-security-standards/) також використовують це поле, щоб уникнути застосування політик, які не є відповідними для цієї операційної системи. ### Podʼи та контролери {#pods-and-controllers} Ви можете використовувати ресурси робочих навантажень для створення та керування Podʼами. Контролери ресурсів опікуються реплікацією та розгортанням Podʼів, а також автоматичним відновленням роботи застосунку в разі відмови. Наприклад, якщо Вузол впав, контролер помітить, що Pod на цьому вузлі перестав працювати, він створить заміну Podʼа. Планувальник поміщає Pod-заміну до нового працездатного вузла. Ось кілька прикладів ресурсів робочих навантажень, які керують одним чи більше Podʼами: * * * ### Визначення групи планування {#specifying-a-scheduling-group}

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.35 [alpha](стандартно вимкнено)

Стандартно Kubernetes планує кожний Pod окремо. Однак деякі тісно повʼязані застосунки потребують одночасного планування групи Podʼів для коректної роботи. Ви можете повʼязати Pod з [PodGroup](/docs/concepts/workloads/podgroup-api/) за допомогою поля [групи планування](/docs/concepts/workloads/pods/scheduling-group/) (`spec.schedulingGroup`). Це повідомляє `kube-scheduler`, що Pod належить до певної групи, що дозволяє застосовувати скоординовані рішення щодо розміщення на рівні групи для всієї групи одночасно. ### Pod templates {#pod-templates} Контролери ресурсів створюють Pod з _pod template_ та керують цим Podʼом від вашого імені. PodTemplate — це специфікація для створення Podʼа, і вона включена в ресурси робочих навантажень, таких як [Deployment](/docs/concepts/workloads/controllers/deployment/), [Job](/docs/concepts/workloads/controllers/job/) та [DaemonSet](/docs/concepts/workloads/controllers/daemonset/). Кожен контролер ресурсів робочих навантажень використовує `PodTemplate` всередині обʼєкта робочого навантаження для створення фактичних Podʼів. `PodTemplate` є частиною бажаного стану будь-якого ресурсу робочого навантаження, який ви використовуєте для запуску вашого застосунку. Коли ви створюєте Pod, ви можете додати [змінні оточення](/docs/tasks/inject-data-application/define-environment-variable-container/) в шаблон Podʼа для контейнерів, які запускаються в Podʼі. Приклад нижче — це маніфест простого Завдання (Job) з `template`, яке запускає один контейнер. Контейнер в цьому Podʼі виводить повідомлення, а потім призупиняється. ```yaml apiVersion: batch/v1 kind: Job metadata: name: hello spec: template: # Це шаблон Podʼа spec: containers: - name: hello image: busybox:1.28 command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure # Кінець шаблону Podʼа ``` Зміна template або перемикання на новий template не має прямого впливу на Podʼи, які вже існують. Якщо ви змінюєте template Podʼа для ресурсу робочого навантаження, цей ресурс має створити Pod-заміну, який використовує оновлений template. Наприклад, контролер StatefulSet переконується, що запущені Podʼи відповідають поточному template для кожного обʼєкта StatefulSet. Якщо ви редагуєте StatefulSet, щоб змінити його template, StatefulSet починає створювати нові Podʼи на основі оновленого template. З часом всі старі Podʼи замінюються новими і оновлення завершується. Кожен ресурс робочого навантаження реалізує власні правила для обробки змін у template Podʼа. Якщо ви хочете дізнатися більше про StatefulSet, прочитайте розділ [Стратегія оновлення](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) в посібнику Основи StatefulSet. На вузлах безпосередньо не спостерігає та не керує жодними деталями щодо template Podʼа та оновлень; ці деталі абстраговані. Ця абстракція та розділення відповідальностей спрощує семантику системи та робить можливим розширення поведінки кластера без зміни наявного коду. ## Оновлення та заміна Podʼів {#pod-update-and-replacement} Як зазначено в попередньому розділі, коли template Podʼа для ресурсу робочого навантаження змінюється, контролер створює нові Podʼи на основі оновленого template замість оновлення або латання наявних Podʼів. Kubernetes не забороняє вам керувати Podʼами напряму. Ви можете оновлювати деякі поля запущеного Podʼа, на місці. Однак операції оновлення Podʼа, такі як [`patch`](/docs/reference/generated/kubernetes-api/v1.36/#patch-pod-v1-core) та [`replace`](/docs/reference/generated/kubernetes-api/v1.36/#replace-pod-v1-core), мають деякі обмеження: * Більшість метаданих Podʼа є незмінними. Наприклад, ви не можете змінити поля `namespace`, `name`, `uid` або `creationTimestamp`. * Якщо `metadata.deletionTimestamp` встановлено, новий запис не може бути доданий до списку `metadata.finalizers`. * Оновлення Podʼа може не змінювати поля, крім `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds`, `spec.terminationGracePeriodSeconds`, `spec.tolerations` або `spec.schedulingGates`. Для `spec.tolerations` ви можете додавати лише нові записи. * Коли ви оновлюєте `spec.activeDeadlineSeconds`, дозволені два типи оновлень: 1. встановлення непризначеному полю позитивного числа; 2. оновлення поля з позитивного числа на менше, невідʼємне число. ### Субресурси Podʼів {#pod-subresources} Наведені вище правила оновлення застосовуються до регулярних оновлень подів, але інші поля пода можуть бути оновлені за допомогою _субресурсів_. * **Resize:** Субресурс `resize` дозволяє оновлювати ресурси контейнерів (`spec.containers[*].resources`). Дивіться [Зміна розміру ресурсів контейнера](/docs/tasks/configure-pod-container/resize-container-resources/) для більш детальної інформації. * **Ефемерні контейнери:** Субресурс `ephemeralContainers` дозволяє додавати до Podʼа. Дивіться [Ефемерні контейнери](/docs/concepts/workloads/pods/ephemeral-containers/) для більш детальної інформації. * **Status:** Субресурс `status` дозволяє оновити статус контейнера. Зазвичай він використовується лише Kubelet та іншими системними контролерами. * **Binding:** Субресурс `binding` дозволяє встановити `spec.nodeName` Podʼів за допомогою запиту `Binding`. Зазвичай це використовується лише . ### Генерація (покоління) Podʼів {#pod-generation} * Поле `metadata.generation` є унікальним. Воно автоматично встановлюється системою таким чином, що нові Podʼи мають значення `metadata.generation`, рівне 1, і кожне оновлення змінних полів у специфікації Podʼа збільшуватиме значення `metadata.generation` на 1.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.35 [stable](стандартно увімкнено)

* `observedGeneration` — це поле, яке фіксується в розділі `status` обʼєкта Pod. Kubelet встановить `status.observedGeneration` для відстеження поточного статусу Podʼа. Поле `status.observedGeneration` Podʼа відображатиме `metadata.generation` Podʼа у момент коли повідомляється про статус Podʼа.

Примітка:

Поле status.observedGeneration керується kubelet, і зовнішні контролери не повинні змінювати це поле.

Різні поля статусу можуть бути повʼязані або з `metadata.generation` поточного циклу синхронізації, або з `metadata.generation` попереднього циклу синхронізації. Ключова відмінність полягає в тому, чи зміна в `spec` відображається безпосередньо в `status`, чи є непрямим результатом поточного процесу. #### Безпосередні оновлення статусу {#direct-status-updates} Для полів статусу, де виділена специфікація безпосередньо відображається, `observedGeneration` буде повʼязане з поточним `metadata.generation` (Generation N). Ця поведінка застосовується до: * **Статусу Resize**: Статус операції зміни розміру ресурсу. * **Виділених ресурсів**: Ресурси, виділені Podʼу після зміни розміру. * **Ефемерних контейнерів**: Коли додається новий ефемерний контейнер, і він знаходиться в стані `Waiting`. #### Опосередковані оновлення статусу {#indirect-status-updates} Для полів статусу, які є непрямим результатом виконання специфікації зі `spec`, `observedGeneration` буде повʼязано з `metadata.generation` попереднього циклу синхронізації (покоління N-1). Ця поведінка застосовується до: * **Образу контейнера**: `ContainerStatus.ImageID` показує образ з попереднього покоління, поки новий образ не буде завантажено, а контейнер не буде оновлено. * **Фактичних ресурсів**: Під час зміни розміру, фактичні ресурси, що використовуються, все ще належать запиту попереднього покоління. * **Стану контейнера**: Під час зміни розміру, з політикою перезапуску, що вимагає перезапуску, відображає запит попереднього покоління. * **activeDeadlineSeconds** та **terminationGracePeriodSeconds** та **deletionTimestamp**: Вплив цих полів на статус Podʼа є результатом раніше отриманої специфікації. ## Спільні ресурси та комунікація {#resource-sharing-and-communication} Podʼи дозволяють контейнерам спільно використовувати ресурси та спілкуватися один з одним. ### Зберігання в Podʼах {#pod-storage} Pod може мати набір спільних . Всі контейнери в Podʼі можуть отримати доступ до спільних томів, що дозволяє цим контейнерам спільно використовувати дані. Також томи дозволяють постійним даним в Podʼі вижити в разі перезапуску одного з контейнерів. Дивіться розділ [Зберігання](/docs/concepts/storage/) для отримання додаткової інформації про те, як Kubernetes реалізує спільне зберігання та робить його доступним для Podʼів. ### Мережеві можливості Podʼа {#pod-networking} Кожному Podʼу присвоюється унікальна IP-адреса для кожного сімейства адрес. Кожен контейнер у Podʼі використовує спільний мережевий простір імен, що включає IP-адресу та мережеві порти. Всередині Podʼа (і **тільки** там) контейнери, що належать до Podʼа, можуть спілкуватися один з одним за допомогою `localhost`. Коли контейнери в Podʼа спілкуються з обʼєктами *поза межами Podʼа*, вони повинні координувати використання спільних мережевих ресурсів (таких як порти). Всередині Podʼа контейнери використовують спільну IP-адресу та простір портів і можуть знаходити один одного через `localhost`. Контейнери в Podʼі також можуть спілкуватися між собою, використовуючи стандартні засоби міжпроцесної комунікації, такі як семафори SystemV або спільну памʼять POSIX. Контейнери в різних Podʼах мають різні IP-адреси і не можуть спілкуватися за допомогою IPC на рівні ОС без спеціальної конфігурації. Контейнери, які хочуть взаємодіяти з контейнером, що працює в іншому Podʼі, можуть використовувати IP-мережу для спілкування. Контейнери в межах Podʼа сприймають імʼя хоста системи як імʼя, що збігається з налаштованим `name` для Podʼа. Більше інформації про це можна знайти в розділі [Мережі](/docs/concepts/cluster-administration/networking/). ## Налаштування безпеки Podʼів {#pod-security} Щоб встановити обмеження безпеки для Podʼів і контейнерів, використовуйте поле `securityContext` у специфікації Podʼа. Це поле дає вам можливість детально контролювати, що може робити Pod або окремі контейнери. Докладнішу інформацію див. у розділі [Розширена конфігурація Podʼа](/docs/concepts/workloads/pods/advanced-pod-config/). Для базової конфігурації безпеки слід дотримуватися Базового стандарту безпеки Podʼів та запускати контейнери з правами, відмінними від root. Ви можете налаштувати прості контексти безпеки: ```yaml apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 containers: - name: sec-ctx-demo image: busybox command: ["sh", "-c", "sleep 1h"] ``` Щоб дізнатися про розширені налаштування контексту безпеки, зокрема про можливості (capabilities), профілі seccomp та детальні параметри безпеки, перейдіть до розділу [Концепції безпеки](/docs/concepts/security/). * Щоб дізнатися про обмеження безпеки на рівні ядра, які ви можете використовувати, див. [Обмеження безпеки ядра Linux для Podʼів та контейнерів](/docs/concepts/security/linux-kernel-security-constraints). * Для отримання додаткової інформації про контекст безпеки Podʼа див. [Налаштування контексту безпеки для Podʼа або контейнера](/docs/tasks/configure-pod-container/security-context/). ## Запити та обмеження ресурсів {#resource-requests-and-limits} Коли ви визначаєте Pod, ви можете необовʼязково вказати, скільки кожного ресурсу потребує контейнер. Найпоширеніші ресурси для вказання — це CPU та памʼять (RAM). Коли ви вказуєте запит ресурсу (_request_) для контейнерів у Podʼі, kube-scheduler використовує цю інформацію для визначення, на який вузол розмістити Pod. Коли ви вказуєте обмеження ресурсу (_limit_) для контейнера, kubelet забезпечує дотримання цих обмежень, щоб використання ресурсів запущеним контейнером не перевищувало встановлені ліміти. Ліміти CPU забезпечуються шляхом обмеження доступу до CPU. Коли контейнер наближається до свого ліміту CPU, ядро обмежує його доступ до CPU. Ліміти памʼяті забезпечуються ядром за допомогою примусового завершення процесів через нестачу памʼяті (OOM), коли контейнер перевищує свій ліміт.

Примітка:

Встановлення лімітів CPU повʼязане з компромісами. Ліміти CPU допомагають запобігти проблемам «шумного сусіда», коли одне робоче навантаження позбавляє ресурсів інших на тому ж вузлі. Це особливо важливо в багатокористувацьких середовищах. Однак ліміти CPU можуть призводити до обмеження продуктивності навіть тоді, коли на вузлі є вільні ресурси CPU, що потенційно погіршує продуктивність робочих навантажень, чутливих до затримок. Вирішення питання про встановлення лімітів CPU залежить від вашого середовища, характеристик робочого навантаження та вимог до ізоляції.

Детальнішу інформацію про одиниці ресурсів, механізми забезпечення дотримання обмежень та приклади конфігурації дивіться у розділі [Управління ресурсами для Podʼів та контейнерів](/docs/concepts/configuration/manage-resources-containers/). ## Статичні Podʼи {#static-pods} _Статичні Podʼи_ керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження з боку . У той час як більшість Podʼів керуються панеллю управління (наприклад, ), для статичних Podʼів kubelet безпосередньо наглядає за кожним статичним Podʼом (та перезапускає його, якщо він падає). Статичні Podʼи завжди привʼязані до одного на конкретному вузлі. Основне використання статичних Podʼів — це запуск самостійної панелі управління: іншими словами, використання kubelet для нагляду за окремими [компонентами панелі управління](/docs/concepts/architecture/#control-plane-components). За докладнішою інформацією звертайтесь до розділу [Статичні Podʼи](/docs/concepts/workloads/pods/static-pods/). ### Podʼи з кількома контейнерами {#how-pods-manage-multiple-containers} Podʼи спроєктовано для підтримки кількох взаємодіючих процесів (таких як контейнери), які утворюють єдиний обʼєкт сервісу. Контейнери в Podʼі автоматично спільно розміщуються та плануються на тому ж фізичному або віртуальному компʼютері в кластері. Контейнери можуть спільно використовувати ресурси та залежності, взаємодіяти між собою та координувати, коли та як вони завершують роботу. Podʼи в Kubernetes можуть керувати одним або кількома контейнерами двома способами: * **Podʼи, що керують одним контейнером**. Модель "один контейнер на Pod" є найпоширенішим використанням в Kubernetes. У цьому випадку Pod можна розглядати як обгортку навколо одного контейнера; Kubernetes керує Podʼами, а не контейнерами безпосередньо. * **Podʼи, що керують кількома контейнерами, які мають працювати разом**. Pod може інкапсулювати застосунок, який складається з кількох розміщених разом контейнерів, які тісно повʼязані та мають спільні ресурси. Ці спільно розташовані контейнери утворюють єдиний цілісний сервіс — наприклад, один контейнер обслуговує дані, збережені в спільному томі, для загального доступу, тоді як окремий оновлює ці файли. Pod обгортає ці контейнери, ресурси сховища та тимчасову мережеву ідентичність разом як єдину одиницю. Наприклад, у вас може бути контейнер, який виконує функції вебсервера для файлів у спільному томі, та окремий [sidecar контейнер](/docs/concepts/workloads/pods/sidecar-containers/), який оновлює ці файли з віддаленого джерела, як показано на малюнку:

Деякі Podʼи мають та . Типово, контейнери ініціалізації запускаються та завершують роботу перед тим, як почнуть працювати контейнери застосунку. У вас також може бути [sidecar контейнер](/docs/concepts/workloads/pods/sidecar-containers/), який виконує додаткові функції для контейнера застосунку, наприклад, реалізує сервісну мережу (service mesh).

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.33 [stable](стандартно увімкнено)

Типово увімкнена функціональна можливість [`SidecarContainers`](/docs/reference/command-line-tools-reference/feature-gates/#SidecarContainers) дозволяє вам вказати `restartPolicy: Always` для контейнерів ініціалізації. Встановлення політики перезапуску `Always` гарантує, що контейнери, там де ви встановили, будуть вважатися як _sidecar_ та працювати протягом усього життєвого циклу Podʼа. Контейнери, які явно визначені як sidecar контейнери, стартують до запуску основного застосунку Podʼа та працюють допоки Pod не завершить роботу. ## Проби контейнерів {#container-probes} _Проба_ — це діагностика, яку періодично виконує kubelet для контейнерів. Для виконання діагностики kubelet може використовувати різні дії: * `ExecAction` (виконується за допомогою рушія виконання контейнера) * `TCPSocketAction` (перевіряється безпосередньо kubelet) * `HTTPGetAction` (перевіряється безпосередньо kubelet) Ви можете дізнатися більше про [перевірки](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) в документації про життєвий цикл Podʼів ## Що далі * Дізнайтесь про [життєвий цикл Podʼів](/docs/concepts/workloads/pods/pod-lifecycle/). * Дізнайтесь про [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) та як ви можете використовувати його для керування доступністю застосунку під час збоїв. * Pod є ресурсом найвищого рівня в Kubernetes REST API. Обʼєкт Pod детально описує його. * Допис в блозі [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) пояснює типові конфігурації Podʼів з більш ніж одним контейнером. * Дізнайтесь про [Обмеження топології розміщення Podʼів](/docs/concepts/scheduling-eviction/topology-spread-constraints/) * Прочитайте про [Розширену конфігурацію Podʼів](/docs/concepts/workloads/pods/advanced-pod-config/), щоб дізнатися про цю тему докладніше. На цій сторінці висвітлюються аспекти конфігурації Podʼів, що виходять за межі основних положень, зокрема: * PriorityClasses * RuntimeClasses * розширені способи конфігурації _планування_: спосіб, яким Kubernetes вирішує, на якому вузлі повинен працювати Pod. Для розуміння контексту того, чому Kubernetes обгортає загальний API Pod іншими ресурсами (такими як або ), ви можете прочитати про попередні роботи, включаючи: * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) * [Borg](https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/) * [Marathon](https://github.com/d2iq-archive/marathon) * [Omega](https://research.google/pubs/pub41684/) * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). --- Section pages: - [Життєвий цикл Podʼа](/uk/docs/concepts/workloads/pods/pod-lifecycle/) - [Стани Podʼів](/uk/docs/concepts/workloads/pods/pod-condition/) - [Контейнери ініціалізації](/uk/docs/concepts/workloads/pods/init-containers/) - [Контейнери sidecar](/uk/docs/concepts/workloads/pods/sidecar-containers/) - [Ефемерні контейнери](/uk/docs/concepts/workloads/pods/ephemeral-containers/) - [Проби життєздатності, готовності та запуску](/uk/docs/concepts/workloads/pods/probes/) - [Розлади](/uk/docs/concepts/workloads/pods/disruptions/) - [Імʼя хосту Podʼа](/uk/docs/concepts/workloads/pods/pod-hostname/) - [Класи якості обслуговування (Quality of Service) Podʼів](/uk/docs/concepts/workloads/pods/pod-qos/) - [Група планування](/uk/docs/concepts/workloads/pods/scheduling-group/) - [Статичні Podʼи](/uk/docs/concepts/workloads/pods/static-pods/) - [Простори імен користувачів](/uk/docs/concepts/workloads/pods/user-namespaces/) - [Downward API](/uk/docs/concepts/workloads/pods/downward-api/): Є два способи використання полів обʼєкта Pod та контейнера у працюючому контейнері: як змінні середовища та як файли, які заповнюються спеціальним типом тома. Разом ці два способи використання полів обʼєкта Pod та контейнера називають Downward API. - [Розширена конфігурація Podʼів](/uk/docs/concepts/workloads/pods/advanced-pod-config/)