Система оркестрування контейнерів промислового класу on Kubernetes

APIService

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apiregistration.k8s.io/v1

import "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"

APIService

APIService представляє сервер для певної GroupVersion. Імʼя повинно бути "version.group".

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (APIServiceSpec)

Spec містить інформацію для пошуку та звʼязку з сервером
status (APIServiceStatus)

Status містить похідну інформацію про сервер API

APIServiceSpec

APIServiceSpec містить інформацію для пошуку та звʼязку з сервером. Підтримується лише https, хоча ви можете вимкнути перевірку сертифіката.

groupPriorityMinimum (int32), обовʼязково

GroupPriorityMinimum — це мінімальний пріоритет, який має мати ця група. Вищий пріоритет означає, що група має перевагу для клієнтів над групами з нижчим пріоритетом. Зверніть увагу, що інші версії цієї групи можуть мати ще вищі значення GroupPriorityMinimum, що надає групі вищий пріоритет. Першочергове сортування базується на GroupPriorityMinimum, впорядкованому від найвищого до найнижчого (20 перед 10). Вторинне сортування базується на алфавітному порівнянні імені обʼєкта. (v1.bar перед v1.foo) Ми рекомендуємо щось на зразок: *.k8s.io (за винятком extensions) на 18000, а PaaS (OpenShift, Deis) рекомендується бути у 2000-х.

Babylon Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Задача

Багато продуктів Babylon використовують машинне навчання та штучний інтелект, і в 2019 році не вистачало обчислювальних ресурсів для проведення певного експерименту. Компанія також активно розвивалася (від 100 до 1600 працівників за три роки) і планувала розширення в інші країни.

Рішення

Babylon перенесла свої застосунки для користувачів на платформу Kubernetes у 2018 році, тому команда інфраструктури звернулася до Kubeflow, інструментарію для машинного навчання на Kubernetes. "Ми спробували створити ядро сервера Kubernetes, розгорнули Kubeflow та організували весь експеримент, який виявився дуже успішним", каже керівник AI Infrastructure Жеремі Валле. Команда почала створювати платформу для самостійного навчання AI на основі Kubernetes.

ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ConfigMap

ConfigMap містить конфігураційні дані, які використовуються Podʼами.

apiVersion: v1
kind: ConfigMap
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
binaryData (map[string][]byte)

BinaryData містить бінарні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. BinaryData може містити байтові послідовності, які не належать до діапазону UTF-8. Ключі, що зберігаються у BinaryData, не повинні збігатися з ключами у полі Data, це перевіряється під час валідації. Використання цього поля вимагатиме apiserver та kubelet версії 1.10+.

CustomResourceDefinition

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apiextensions.k8s.io/v1

import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

CustomResourceDefinition

CustomResourceDefinition представляє ресурс, який повинен бути експонований на сервері API. Його імʼя повинно бути у форматі <.spec.name>.<.spec.group>.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (CustomResourceDefinitionSpec), обовʼязково

spec описує, як користувач хоче, щоб ресурси виглядали.
status (CustomResourceDefinitionStatus)

status показує фактичний стан CustomResourceDefinition.

CustomResourceDefinitionSpec

CustomResourceDefinitionSpec визначає, як користувач хоче, щоб їхні ресурси виглядали

group (string), обовʼязково

group — це API-група визначеного власного ресурсу. Власні ресурси обслуговуються як /apis/<group>/.... Повинно відповідати імені CustomResourceDefinition у форматі <names.plural>.<group>.

DeleteOptions

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

DeleteOptions можуть бути надані при видаленні обʼєкта API.

apiVersion (string)

APIVersion визначає версійовану схему цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення, і можуть відхилити невизнані значення. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
dryRun ([]string)

Atomic: буде замінено під час злиття

Коли параметр присутній, вказує, що зміни не повинні бути збережені. Недійсні або невизнані директиви dryRun призведуть до відповіді з помилкою і подальшої відмови в обробці запиту. Допустимі значення: - All: всі етапи випробувального запуску будуть оброблені

FlowSchema

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

FlowSchema

FlowSchema визначає схему групи потоків. Зверніть увагу, що потік складається з набору вхідних API-запитів з подібними атрибутами та ідентифікується парою рядків: імʼям FlowSchema та "розрізнювачем потоку".

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata (ObjectMeta)

metadata — стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (FlowSchemaSpec)

spec — специфікація бажаної поведінки FlowSchema. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (FlowSchemaStatus)

status — поточний статус FlowSchema. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

FlowSchemaSpec

FlowSchemaSpec описує вигляд специфікації FlowSchema.

distinguisherMethod (FlowDistinguisherMethod)

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

LocalSubjectAccessReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

LocalSubjectAccessReview

LocalSubjectAccessReview перевіряє, чи може користувач або група виконати дію в заданому просторі імен. Наявність ресурсу, обмеженого простором імен, значно полегшує надання політики, обмеженої простором імен, що включає перевірку дозволів.

apiVersion: authorization.k8s.io/v1
kind: LocalSubjectAccessReview
metadata (ObjectMeta)

Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (SubjectAccessReviewSpec), обовʼязково

Специфікація містить інформацію про запит, який оцінюється. spec.namespace повинен дорівнювати простору імен, щодо якого зроблено запит. Якщо поле порожнє, встановлюється стандартне значення.
status (SubjectAccessReviewStatus)

MutatingAdmissionPolicyBindingList v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1beta1

import "k8s.io/api/admissionregistration/v1beta1"

Pod

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Pod

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

apiVersion: v1
kind: Pod
metadata (ObjectMeta)

Метадані стандартного обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (PodSpec)

Специфікація бажаної поведінки Podʼа. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (PodStatus)

Останній спостережуваний статус Podʼа. Ці дані можуть бути застарілими. Заповнюється системою. Тільки для читання. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

PodSpec

PodSpec — це опис Pod.

Контейнери

containers ([]Container), обовʼязково

Patch strategy: обʼєднання за ключем name

Service

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Service

Service — це іменована абстракція служб програмного забезпечення (наприклад, mysql), що складається з локального порту (наприклад, 3306), який прослуховує проксі, і селектора, який визначає, які Podʼи будуть відповідати на запити, надіслані через проксі.

apiVersion: v1
kind: Service
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (ServiceSpec)

Специфікація бажаної поведінки Service. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (ServiceStatus)

Останній зафіксований статус Service. Заповнюється системою. Тільки для читання. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

ServiceSpec

ServiceSpec описує атрибути, які користувач створює для служби.

ServiceAccount

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ServiceAccount

ServiceAccount повʼязує разом

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

apiVersion: v1
kind: ServiceAccount
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
automountServiceAccountToken (boolean)

automountServiceAccountToken вказує, чи повинні Podʼи, які працюють від імені цього службового облікового запису, автоматично мати змонтований API токен. Може бути перевизначено на рівні Podʼа.
imagePullSecrets ([]LocalObjectReference)

Atomic: буде замінено під час злиття

Вступ до kubectl

Mon, 01 Jan 0001 00:00:00 +0000

kubectl — це версія CLI для Kubernetes, яка може виконувати багато різних речей.

Хоча це керівництво зосереджене на використанні kubectl для декларативного управління застосунками в Kubernetes, воно також охоплює інші функції kubectl.

Набори команд

Більшість команд kubectl зазвичай відносяться до однієї з кількох категорій:

Тип	Використання	Опис
Декларативне управління ресурсами	Розгортання та операційна діяльність (наприклад, GitOps)	Декларативне управління ресурсами Kubernetes за допомогою конфігурації ресурсів
Імперативне управління ресурсами	Тільки розробка	Виконання команд для управління ресурсами Kubernetes за допомогою аргументів командного рядка та прапорців
Виведення стану робочого навантаження	Налагодження	Виведення інформації про робочі навантаження
Взаємодія з контейнерами	Налагодження	Exec, attach, cp, logs
Управління кластером	Операції з кластером	Виведення та блокування вузлів

Декларативне управління застосунками

Найкращим підходом для управління ресурсами є використання декларативних файлів, які називаються конфігурацією ресурсів, разом з командою kubectl Apply. Ця команда читає локальну (або віддалену) структуру файлів та змінює стан кластера, щоб відображати заявлені наміри.

Binding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Binding

Binding звʼязує один обʼєкт з іншим; наприклад, Pod звʼязується з вузлом за допомогою планувальника.

apiVersion: v1
kind: Binding
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
target (ObjectReference), обовʼязково

Цільовий обʼєкт, з яким ви хочете звʼязати стандартний обʼєкт.

Операції

`create` створення Binding

HTTP запит

POST /api/v1/namespaces/{namespace}/bindings

Параметри

namespace (в шляху): string, обовʼязково

namespace
body: Binding, обовʼязково
dryRun (в запиті): string

dryRun
fieldManager (в запиті): string

fieldManager
fieldValidation (в запиті): string

Booz Allen Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Задача

У 2017 році група стратегічних інновацій компанії Booz Allen Hamilton співпрацювала з федеральним урядом, щоб перезапустити десятирічний вебсайт recreation.gov, який надає інформацію та реальне бронювання для понад 100,000 кемпінгів та обʼєктів на федеральних землях по всій країні. Інфраструктура мала бути гнучкою, надійною та масштабованою, а також повторюваною для інших федеральних агентств, що є клієнтами Booz Allen Hamilton.

Рішення

"Єдиним способом, з яким ми могли б бути успішними у вирішенні цієї проблеми серед різних агентств, було створення мікросервісної архітектури та контейнерів, щоб ми могли бути дуже динамічними та гнучкими для будь-якого агентства, яке має свої особливі вимоги", говорить старший технолог Booz Allen Hamilton Мартін Фолкофф. Щоб відповідати цим вимогам, команда Фолкоффа звернулася до Kubernetes для оркестрування.

ComponentStatus

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ComponentStatus

ComponentStatus (і ComponentStatusList) містить інформацію про валідацію кластера. Застаріло: Цей API застарів у версії v1.19+

apiVersion: v1
kind: ComponentStatus
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
conditions ([]ComponentCondition)

Patch strategy: обʼєднання за ключем type

Map: унікальні значення ключа type будуть збережені під час злиття

Список спостережуваних станів компонента

Інформація про стан компонента.
- conditions.status (string), обовʼязково
  
  Статус стану компонента. Допустимі значення для "Healthy": "True", "False" або "Unknown".

DeviceClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1

import "k8s.io/api/resource/v1"

DeviceClass

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

Це альфа-тип і вимагає увімкнення функціональної можливості DynamicResourceAllocation.

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata (ObjectMeta)

Стандартний обʼєкт метаданих
spec (DeviceClassSpec), обовʼязково

Spec визначає, що можна призначити і як це налаштувати.

Поле є змінюваним. Споживачі повинні бути готові до того, що класи можуть змінюватися в будь-який час, як через оновлення, так і через заміну. Розподілення заявок виконується один раз на основі того, що було встановлено в класах на момент виділення.

Endpoints

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Endpoints

Endpoints — є колекцією точок доступу, що фактично утворюють Service.

Name: "mysvc",
Subsets: [
 {
 Addresses: [{"ip": "10.10.1.1"}, {"ip": "10.10.2.2"}],
 Ports: [{"name": "a", "port": 8675}, {"name": "b", "port": 309}]
 },
 {
 Addresses: [{"ip": "10.10.3.3"}],
 Ports: [{"name": "a", "port": 93}, {"name": "b", "port": 76}]
 },
]

Endpoints — це застарілий API, який не містить інформації про всі функції Сервісу. Використовуйте discoveryv1.EndpointSlice для отримання повної інформації про точки доступу Сервісу.

Застаріло: Цей API застарів у версії 1.33+. Використовуйте discoveryv1.EndpointSlice.

apiVersion: v1
kind: Endpoints

LabelSelector

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

Селектор міток — це запит на наявність міток до набору ресурсів. Результати matchLabels та matchExpressions поєднуються логічним І (AND). Порожній селектор міток має збіг зі всіма обʼєктам. Нульовий селектор міток не збігається з жодним обʼєктом.

matchExpressions ([]LabelSelectorRequirement)

Atomic: буде замінено під час злиття

matchExpressions — це список вимог селектора міток. Вимоги зʼєднуються логічною операцією І (AND).

Вимоги селектора міток — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

LimitRange

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

LimitRange

LimitRange встановлює обмеження на використання ресурсів для кожного типу ресурсу в просторі імен.

apiVersion: v1
kind: LimitRange
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (LimitRangeSpec)

Spec визначає застосовувані обмеження. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

LimitRangeSpec

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

limits ([]LimitRangeItem), обовʼязково

Atomic: буде замінено під час злиття

Limits — це список обʼєктів LimitRangeItem, що застосовуються.

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

Secret

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Secret

Secret зберігає секретні дані певного типу. Загальна кількість байт значень у полі Data має бути меншою за MaxSecretSize.

apiVersion: v1
kind: Secret
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
data (map[string][]byte)

Data містить секретні дані. Кожен ключ повинен складатися з алфавітно-цифрових символів, '-', '_' або '.'. Сериалізована форма секретних даних є рядком, закодованим у base64, що представляє довільне (можливо, не рядкове) значення даних. Описано в https://tools.ietf.org/html/rfc4648#section-4.
immutable (boolean)

SelfSubjectAccessReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectAccessReview

SelfSubjectAccessReview перевіряє, чи може поточний користувач виконати дію. Незаповнення spec.namespace означає "в усіх просторах імен". Self є особливим випадком, оскільки користувачі завжди повинні мати змогу перевірити, чи можуть вони виконати дію.

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata (ObjectMeta)

Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (SelfSubjectAccessReviewSpec), обовʼязково

Специфікація містить інформацію про запит, який оцінюється. user та groups повинні бути порожніми.
status (SubjectAccessReviewStatus)

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

TokenRequest

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenRequest

TokenRequest запитує токен для вказаного службового облікового запису.

apiVersion: authentication.k8s.io/v1
kind: TokenRequest
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (TokenRequestSpec), обовʼязково

Spec містить інформацію про запит, що оцінюється.
status (TokenRequestStatus)

Status заповнюється сервером і вказує, чи може токен бути автентифікований.

TokenRequestSpec

TokenRequestSpec містить параметри запиту токена, надані клієнтом.

audiences ([]string), обовʼязково

Atomic: буде замінено під час злиття

Audiences — це цільові аудиторії токена. Отримувач токена повинен ідентифікувати себе за допомогою ідентифікатора зі списку аудиторій токена, інакше він повинен відхилити токен. Токен, виданий для кількох аудиторій, може бути використаний для автентифікації з будь-якою з вказаних аудиторій, що передбачає високий ступінь довіри між цільовими аудиторіями.

Booking.com Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Задача

У 2016 році Booking.com перейшла на платформу OpenShift, що надало розробникам продуктів швидший доступ до інфраструктури. Але через те, що Kubernetes був абстрагований від розробників, команда інфраструктури стала "вузьким місцем знань", коли виникали проблеми. Масштабувати цю підтримку стало неможливо.

Рішення

Після року роботи з OpenShift, команда платформи вирішила створити власну платформу на базі стандартного Kubernetes і попросити розробників вивчити Kubernetes для її використання. "Це не магічна платформа", каже Бен Тайлер, провідний розробник треку B Platform. "Ми не стверджуємо, що ви можете використовувати її з закритими очима. Розробники повинні навчитися, і ми зробимо все можливе, щоб вони мали доступ до цих знань."

CSIDriver

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSIDriver

CSIDriver збирає інформацію про драйвер тому Container Storage Interface (CSI), розгорнутий в кластері. Контролер приєднання та відʼєднання Kubernetes використовує цей обʼєкт для визначення необхідності приєднання. Kubelet використовує цей обʼєкт, щоб визначити, чи потрібно передавати інформацію про контейнер при монтуванні. Обʼєкти CSIDriver не має простору імен.

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata (ObjectMeta)

Стандартні метадані обʼєкта. metadata.Name вказує назву драйвера CSI, до якого відноситься цей обʼєкт; вона МАЄ бути такою ж, як імʼя, яке повертає виклик CSI GetPluginName() для цього драйвера. Назва драйвера повинна бути не більше 63 символів, починатися і закінчуватися алфавітно-цифровим символом ([a-z0-9A-Z]), з тире (-), крапками (.) та алфавітно-цифровими символами між ними. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

EndpointSlice

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: discovery.k8s.io/v1

import "k8s.io/api/discovery/v1"

EndpointSlice

EndpointSlice представляє набір точок доступу сервісу. Більшість EndpointSlice створюються контролером EndpointSlice для представлення Pod-ів, вибраних обʼєктами Service. Для даного сервісу може існувати декілька обʼєктів EndpointSlice, які необхідно обʼєднати для отримання повного набору точок доступу; ви можете знайти всі зрізи для певного сервісу, перерахувавши EndpointSlices у просторі імен сервісу, мітка kubernetes.io/service-name якого містить назву сервісу..

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata (ObjectMeta)

Стандартні метадані обʼєкта.
addressType (string), обовʼязково

Event

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: events.k8s.io/v1

import "k8s.io/api/events/v1"

Event

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

apiVersion: events.k8s.io/v1

ListMeta

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

ListMeta описує метадані, які синтетичні ресурси повинні мати, включаючи списки та різноманітні обʼєкти статусу. Ресурс може мати лише один з {ObjectMeta, ListMeta}.

continue (string)

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

MutatingWebhookConfiguration

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

MutatingWebhookConfiguration

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

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata (ObjectMeta)

Стандартний обʼєкт метаданих; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.
webhooks ([]MutatingWebhook)

Patch strategy: обʼєднання за ключем name

Map: унікальні значення ключа name будуть збережені під час злиття

Webhooks — це список вебхуків та відповідних ресурсів і операцій.

MutatingWebhook описує вебхук допуску та ресурси й операції, до яких він застосовується.
- webhooks.admissionReviewVersions ([]string), обовʼязково

PodTemplate

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

PodTemplate

PodTemplate описує шаблон для створення копій наперед визначеного Podʼа.

apiVersion: v1
kind: PodTemplate
metadata (ObjectMeta)

Метадані стандартного обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
template (PodTemplateSpec)

Template — визначає Podʼи, які будуть створені з цього шаблону. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

PodTemplateList

PodTemplateList — список PodTemplate.

apiVersion: v1
kind: PodTemplateList
metadata (ListMeta)

Метадані стандартного списку. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
items ([]PodTemplate), обовʼязково

Список шаблонів Pod.

Операції

`get` прочитати вказаний PodTemplate

HTTP-запит

GET /api/v1/namespaces/{namespace}/podtemplates/{name}

Параметри

name (в шляху): string, обовʼязково

ResourceQuota

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ResourceQuota

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

apiVersion: v1
kind: ResourceQuota
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (ResourceQuotaSpec)

Spec визначає бажані квоти. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (ResourceQuotaStatus)

Status визначає фактично застосовані квоти та їх поточне використання. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

ResourceQuotaSpec

ResourceQuotaSpec визначає бажані жорсткі обмеження для застосування квоти.

hard (map[string]Quantity)

hard — це набір бажаних жорстких обмежень для кожного названого ресурсу. Докладніше: https://kubernetes.io/docs/concepts/policy/resource-quotas/
scopeSelector (ScopeSelector)

scopeSelector — це також набір фільтрів, таких як scopes, які повинні відповідати кожному обʼєкту, відстежуваному квотою, але виражені за допомогою ScopeSelectorOperator у поєднанні з можливими значеннями. Для відповідності ресурсу повинні відповідати як scopes, так і scopeSelector (якщо зазначено у spec).

SelfSubjectRulesReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SelfSubjectRulesReview

SelfSubjectRulesReview перелічує набір дій, які поточний користувач може виконувати в межах простору імен. Отриманий список дій може бути неповним залежно від режиму авторизації сервера та будь-яких помилок, які виникли під час оцінки. SelfSubjectRulesReview слід використовувати інтерфейсами користувача для показу/приховування дій або швидкого надання кінцевому користувачеві можливості оцінити свої дозволи. Він НЕ ПОВИНЕН використовуватися зовнішніми системами для прийняття рішень щодо авторизації, оскільки це викликає проблеми з підміною, тривалістю життя кешу/відкликанням та правильністю. SubjectAccessReview і LocalAccessReview є правильним способом делегування рішень щодо авторизації до API сервера.

TokenReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

TokenReview

TokenReview намагається автентифікувати токен вже відомому користувачу. Примітка: запити TokenReview можуть кешуватися dnekrjv автентифікації вебхука в kube-apiserver.

apiVersion: authentication.k8s.io/v1
kind: TokenReview
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (TokenReviewSpec), обовʼязково

Spec містить інформацію про запит, що оцінюється
status (TokenReviewStatus)

Status заповнюється сервером і вказує, чи можна автентифікувати запит.

TokenReviewSpec

TokenReviewSpec є описом запиту автентифікації токена.

audiences ([]string)

Atomic: буде замінено під час злиття

Audiences — це список ідентифікаторів, які сервер ресурсів, представлений токеном, розпізнає як. Автентифікатори токенів, що володіють інформацією про аудиторію, перевірять, що токен був призначений принаймні для однієї з аудиторій у цьому списку. Якщо аудиторії не надані, типово використовується аудиторія Kubernetes apiserver.

AppDirect Case Study

Mon, 01 Jan 0001 00:00:00 +0000

Задача

AppDirect забезпечує платформу для торгівлі продуктами та послугами на базі хмари. Коли директор з розробки програмного забезпечення Пʼєр-Олександр Ласерт почав працювати в компанії у 2014 році, компанія мала монолітний застосунок, розгорнутий на "інфраструктурі tomcat, і весь процес випуску був складним для того, чим він мав бути", говорить він. "Була велика кількість ручних кроків, один інженер розробляв функцію, потім інша команда приймала зміни. Отже, у вас були вузькі місця в конвеєрі для доставки функції в операційну експлуатацію." Одночасно команда інженерів зростала, і компанія усвідомила, що їй потрібна краща інфраструктура для підтримки цього зростання та збільшення швидкості.

CertificateSigningRequest

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: certificates.k8s.io/v1

import "k8s.io/api/certificates/v1"

CertificateSigningRequest

Обʼєкти CertificateSigningRequest надають механізм для отримання сертифікатів x509 шляхом подання запиту на підписання сертифіката та його асинхронного схвалення і видачі.

Kubelets використовують цей API для отримання:

клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client-kubelet").
серверних сертифікатів для TLS-точок доступу, до яких kube-apiserver може підключатися безпечно (з використанням signerName "kubernetes.io/kubelet-serving").

Цей API може бути використаний для запиту клієнтських сертифікатів для автентифікації до kube-apiserver (з використанням signerName "kubernetes.io/kube-apiserver-client") або для отримання сертифікатів від нестандартних підписувачів, що не належать до Kubernetes.

CSINode

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSINode

CSINode містить інформацію про всі драйвери CSI, встановлені на вузлі. Драйверам CSI не потрібно створювати обʼєкт CSINode безпосередньо. Якщо вони використовують sidecar контейнер node-driver-registrar, kubelet автоматично заповнить обʼєкт CSINode для драйвера CSI під час реєстрації втулка kubelet. CSINode має ту ж назву, що і вузол. Якщо обʼєкт відсутній, це означає, що або на вузлі немає доступних драйверів CSI, або версія Kubelet є достатньо низькою, щоб не створювати цей обʼєкт. CSINode має OwnerReference, яке вказує на відповідний обʼєкт вузла.

Ingress

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

Ingress

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (IngressSpec)

spec — це бажаний стан Ingress. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (IngressStatus)

status — це поточний стан Ingress. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

IPAddress

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

IPAddress

IPAddress представляє одну IP-адресу одного сімейства IP. Цей обʼєкт призначений для використання API, які оперують IP-адресами. Обʼєкт використовується ядром API Service для виділення IP-адрес. IP-адресу можна представити у різних форматах. Щоб гарантувати унікальність IP-адреси, імʼя обʼєкта є IP-адреса в канонічному форматі: чотири десяткові цифри, розділені крапками без ведучих нулів для IPv4 і представлення, визначене RFC 5952 для IPv6. Дійсні: 192.168.1.5 або 2001:db8::1 або 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 Недійсні: 10.01.2.3 або 2001:db8:0:0:0::1

LocalObjectReference.

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

LocalObjectReference містить достатньо інформації, щоб дозволити вам знайти вказаний обʼєкт всередині того самого простору імен." title: "LocalObjectReference

name (string)

Назва обʼєкта, на який ви посилаєтеся. Це поле є фактично обов'язковим, але через зворотну сумісність дозволено залишати його порожнім. Екземпляри цього типу з порожнім значенням тут, як правило, є помилковими. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

NetworkPolicy

NetworkPolicy описує, який мережевий трафік дозволений для набору Podʼів

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (NetworkPolicySpec)

spec представляє специфікацію бажаної поведінки для цього NetworkPolicy.

NetworkPolicySpec

NetworkPolicySpec надає специфікацію NetworkPolicy

podSelector (LabelSelector)

podSelector вибирає Podʼи, до яких застосовується цей обʼєкт NetworkPolicy. Масив правил застосовується до будь-яких Podʼів, вибраних цим полем. Порожній селектор відповідає всім подам у просторі імен політики. Кілька мережевих політик можуть вибирати той самий набір Podʼів. У цьому випадку правила ingress для кожного з них поєднуються. Це поле НЕ є необовʼязковим і слідує стандартним семантикам вибору міток. Це поле є необовʼязковим. Якщо воно не вказане, стандартно використовується порожній селектор.

ReplicationController

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

ReplicationController

ReplicationController представляє конфігурацію контролера реплікації.

apiVersion: v1
kind: ReplicationController
metadata (ObjectMeta)

Якщо мітки (Labels) ReplicationController пусті, вони стандартно встановлюються такими ж, як у Pod(ів), які контролює replication controller. Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (ReplicationControllerSpec)

Spec визначає специфікацію бажаної поведінки replication controller. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (ReplicationControllerStatus)

Status — це останній спостережуваний статус replication controller. Ці дані можуть бути застарілими на деякий час. Заповнюється системою. Тільки для читання. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

SubjectAccessReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authorization.k8s.io/v1

import "k8s.io/api/authorization/v1"

SubjectAccessReview

SubjectAccessReview перевіряє, чи може користувач або група виконати дію.

apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
metadata (ObjectMeta)

Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (SubjectAccessReviewSpec), обовʼязково

Специфікація містить інформацію про запит, який оцінюється
status (SubjectAccessReviewStatus)

Статус заповнюється сервером і вказує, чи дозволено запит, чи ні

SubjectAccessReviewSpec

SubjectAccessReviewSpec — це опис запиту на доступ. Має бути встановлено одне з ResourceAuthorizationAttributes або NonResourceAuthorizationAttributes

extra (map[string][]string)

Extra відповідає методу user.Info.GetExtra() з автентифікатора. Оскільки це вхідні дані для авторизатора, це потребує відображення тут.

ValidatingWebhookConfiguration

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingWebhookConfiguration

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

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata (ObjectMeta)

Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.
webhooks ([]ValidatingWebhook)

Patch strategy: обʼєднання за ключем name

Map: унікальні значення ключа name будуть збережені під час злиття

Webhooks — це список вебхуків і ресурсів та операцій, які вони зачіпають.

ValidatingWebhook описує вебхук допуску та ресурси й операції, до яких він застосовується.

ClusterRole

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRole

ClusterRole — це логічне групування PolicyRules на рівні кластера, на яке можна посилатися як на єдине ціле за допомогою привʼязки RoleBinding або ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata (ObjectMeta)

Стандартні метадані обʼєкта.
aggregationRule (AggregationRule)

AggregationRule — це необовʼязкове поле, яке описує, як створити правила для цього ClusterRole. Якщо AggregationRule встановлено, то правила управляються контролером і прямі зміни до правил будуть перезаписані контролером.

AggregationRule описує, як знайти ClusterRoles для обʼєднання у ClusterRole

ClusterTrustBundle v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: certificates.k8s.io/v1beta1

import "k8s.io/api/certificates/v1beta1"

ClusterTrustBundle

ClusterTrustBundle — це кластерний контейнер для довірчих якорів X.509 (кореневих сертифікатів).

Обʼєкти ClusterTrustBundle вважаються доступними для читання будь-яким автентифікованим користувачем у кластері, оскільки їх можна монтувати в Pod за допомогою проєкції clusterTrustBundle. Усі службові облікові записи типово мають доступ на читання ClusterTrustBundles. Користувачі, які мають доступ лише на рівні простору імен у кластері, можуть читати ClusterTrustBundles, використовуючи serviceaccount, до якого вони мають доступ.

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

CSIStorageCapacity

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

CSIStorageCapacity

CSIStorageCapacity зберігає результат одного виклику CSI GetCapacity. Для заданого StorageClass це описує доступну місткість у певному сегменті топології. Це можна використовувати під час розгляду місця для створення нових PersistentVolumes.

Наприклад, це може виражати такі речі:

StorageClass "standard" має "1234 GiB" доступних у "topology.kubernetes.io/zone=us-east1"
StorageClass "localssd" має "10 GiB" доступних у "kubernetes.io/hostname=knode-abc123"

Наступні три випадки означають, що місткість недоступна для певної комбінації:

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

Виробник цих обʼєктів може вирішити, який підхід є більш відповідним.

IngressClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

IngressClass

IngressClass представляє клас Ingress, на який посилається Ingress Spec. Анотацію ingressclass.kubernetes.io/is-default-class можна використовувати, щоб вказати, що IngressClass слід вважати стандартним класом. Коли для одного ресурсу IngressClass ця анотація має значення true, новим ресурсам Ingress без вказаного класу буде присвоєно цей клас.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata (ObjectMeta)

Стандартний обʼєкт метаданих. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (IngressClassSpec)

spec — є бажаним станом IngressClass. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

IngressClassSpec

IngressClassSpec надає інформацію про клас Ingress.

Lease

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: coordination.k8s.io/v1

import "k8s.io/api/coordination/v1"

Lease

Lease визначає концепцію оренди.

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata (ObjectMeta)

Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (LeaseSpec)

Spec містить специфікацію оренди. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

LeaseSpec

LeaseSpec — це специфікація оренди.

acquireTime (MicroTime)

acquireTime — це час, коли поточну оренду було отримано.

MicroTime — це версія Time з точністю до мікросекунд.
holderIdentity (string)

holderIdentity містить ідентифікатор власника поточної оренди. Якщо використовується координований вибір лідера, ідентифікатор власника повинен відповідати значенню поля LeaseCandidate.metadata.name, яке було обране.

NodeSelectorRequirement

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

Вимоги селектора вузлів — це селектор, що містить значення, ключ та оператор, який повʼязує ключ і значення.

key (string), обовʼязково

key — це ключ мітки, до якого застосовується селектор.
operator (string), обовʼязково

operator представляє стосунок ключа до набору значень. Допустимі оператори: In, NotIn, Exists, DoesNotExist, Gt та Lt.

Можливі значення переліку (enum):
- "DoesNotExist"
- "Exists"
- "Gt"
- "In"
- "Lt"
- "NotIn"
values ([]string)

Atomic: буде замінено під час злиття

values — це масив рядкових значень. Якщо оператор — In або NotIn, масив значень повинен бути не пустим. Якщо оператор — Exists або DoesNotExist, масив значень повинен бути пустим. Якщо оператор — Gt або Lt, масив значень повинен містити один елемент, який буде інтерпретовано як ціле число. Цей масив замінюється під час стратегічного злиття патча.

PodDisruptionBudget

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: policy/v1

import "k8s.io/api/policy/v1"

PodDisruptionBudget

PodDisruptionBudget — обʼєкт, який визначає максимальний розлад, який може бути завданий колекції Podʼів.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (PodDisruptionBudgetSpec)

Специфікація бажаної поведінки PodDisruptionBudget.
status (PodDisruptionBudgetStatus)

Останній спостережуваний стан PodDisruptionBudget.

PodDisruptionBudgetSpec

PodDisruptionBudgetSpec — це опис PodDisruptionBudget.

maxUnavailable (IntOrString)

Виселення дозволяється, якщо щонайбільше "maxUnavailable" Podʼів, вибраних за допомогою "selector", є недоступними після виселення, тобто навіть за відсутності виселеного Podʼа. Наприклад, можна запобігти всім добровільним виселенням, вказавши 0. Це взаємозаперечне налаштування з "minAvailable".

ReplicaSet

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ReplicaSet

ReplicaSet забезпечує, що в будь-який момент часу задана кількість реплік Podʼів працює.

apiVersion: apps/v1
kind: ReplicaSet
metadata (ObjectMeta)

Якщо мітки ReplicaSet порожні, вони стандартно встановлюються такими самими, як у Pod(ах), яким керує ReplicaSet. Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (ReplicaSetSpec)

Spec визначає специфікацію бажаної поведінки ReplicaSet. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (ReplicaSetStatus)

Статус — це останній зареєстрований статус ReplicaSet. Ці дані можуть бути застарілими на деякий час. Заповнюється системою. Тільки для читання. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

Глосарій

Mon, 01 Jan 0001 00:00:00 +0000

Привіт Minikube

Mon, 01 Jan 0001 00:00:00 +0000

Цей посібник показує, як запустити зразковий застосунок у середовищі Kubernetes за допомогою minikube. Посібник надає образ контейнера, який використовує NGINX для відповіді на всі запити.

Цілі

Розгортання тестового застосунку в minikube.
Запуск застосунку.
Перегляд логів застосунку.

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

Цей застосунок передбачає, що у вас вже є встановлений minikube. Дивіться Крок 1 в minikube start для інструкцій щодо встановлення.

Примітка:

Виконайте лише інструкції з Кроку 1, Встановлення. Решту розглянуто на цій сторінці.

Вам також потрібно встановити kubectl. Дивіться Встановлення інструментів для інструкцій щодо встановлення.

Створення базового DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

ClusterRoleBinding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

ClusterRoleBinding

ClusterRoleBinding посилається на ClusterRole, але не містить її. ClusterRoleBinding може посилатися на ClusterRole в глобальному просторі імен та додає інформацію про субʼєкти через Subject.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata (ObjectMeta)

Стандартні метадані обʼєкта.
roleRef (RoleRef), обовʼязкове

RoleRef може посилатися лише на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.

RoleRef містить інформацію, яка посилається на використану роль

Deployment

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

Deployment

Deployment робить можливими декларативні оновлення для Podʼів та ReplicaSet.

apiVersion: apps/v1
kind: Deployment
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (DeploymentSpec)

Специфікація бажаної поведінки Deployment.
status (DeploymentStatus)

Найбільш останній спостережуваний статус Deployment.

DeploymentSpec

DeploymentSpec є специфікацією бажаної поведінки Deployment.

selector (LabelSelector), обовʼязково

Селектор міток для Podʼів. Наявні ReplicaSets, чиї Podʼи вибрані за допомогою цього селектора, будуть ті, які будуть змінені цим Deployment. Він повинен відповідати міткам шаблону Podʼа.

LeaseCandidate v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: coordination.k8s.io/v1beta1

import "k8s.io/api/coordination/v1beta1"

LeaseCandidate

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

apiVersion: coordination.k8s.io/v1beta1
kind: LeaseCandidate
metadata (ObjectMeta)

Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (LeaseCandidateSpec)

spec містить специфікацію Lease. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

LeaseCandidateSpec

LeaseCandidateSpec — це специфікація Lease.

binaryVersion (string), обовʼязково

BinaryVersion - це бінарна версія. Вона має бути у форматі semver без символу v. Це поле є обовʼязковим.
leaseName (string), обовʼязково

LeaseName — імʼя Lease, на який претендує цей кандидат. Обмеження для цього поля такі ж, як і для Lease.name. Кілька кандидатів на оренду можуть посилатися на один і той самий Lease.name. Це поле є незмінним.

ObjectFieldSelector

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

ObjectFieldSelector вибирає поле з версією API обʼєкта.

fieldPath (string), обовʼязково

Шлях поля для вибору в зазначеній версії API.
apiVersion (string)

Версія схеми, в якій виражений fieldPath, стандартне значення — "v1".

PersistentVolumeClaim

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolumeClaim

PersistentVolumeClaim представляє запит користувача на отримання та право на постійний том.

apiVersion: v1
kind: PersistentVolumeClaim
metadata (ObjectMeta)

Метадані стандартного обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (PersistentVolumeClaimSpec)

Специфікація визначає бажані характеристики тому, запитаного автором Podʼа. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims
status (PersistentVolumeClaimStatus)

Статус представляє поточну інформацію/стан запиту на постійний том. Тільки для читання. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

PersistentVolumeClaimSpec

PersistentVolumeClaimSpec описує загальні атрибути пристроїв зберігання та дозволяє вказувати джерело для атрибутів, специфічних для постачальника.

PriorityLevelConfiguration

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: flowcontrol.apiserver.k8s.io/v1

import "k8s.io/api/flowcontrol/v1"

PriorityLevelConfiguration

PriorityLevelConfiguration представляє конфігурацію рівня пріоритету.

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: PriorityLevelConfiguration
metadata (ObjectMeta)

metadata — стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (PriorityLevelConfigurationSpec)

spec — специфікація бажаної поведінки "request-priority". Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (PriorityLevelConfigurationStatus)

status — поточний статус "request-priority". Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

PriorityLevelConfigurationSpec

PriorityLevelConfigurationSpec визначає конфігурацію рівня пріоритету.

exempt (ExemptPriorityLevelConfiguration)

exempt вказує, як обробляються запити для виняткового рівня пріоритету. Це поле ПОВИННО бути порожнім, якщо type встановлено на "Limited". Це поле МОЖЕ бути не порожнім, якщо type встановлено на "Exempt". Якщо воно порожнє і type встановлено на "Exempt", застосовуються стандартне значення для ExemptPriorityLevelConfiguration.

SelfSubjectReview

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: authentication.k8s.io/v1

import "k8s.io/api/authentication/v1"

SelfSubjectReview

SelfSubjectReview містить інформацію про користувача, яку має kube-apiserver про користувача, що робить цей запит. При використанні імперсоніфікації, користувачі отримають інформацію про користувача, якого вони імітують. Якщо використовується імперсоніфікація або автентифікація заголовка запиту, будь-які додаткові ключі будуть ігноруватися і повертатися у нижньому регістрі.

apiVersion: authentication.k8s.io/v1
kind: SelfSubjectReview
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
status (SelfSubjectReviewStatus)

Статус заповнюється сервером атрибутами користувача.

SelfSubjectReviewStatus

SelfSubjectReviewStatus заповнюється kube-apiserver і відсилається користувачу.

Namespace

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Namespace

Namespace надає область видимості для імен. Використання кількох просторів імен є необовʼязковим.

apiVersion: v1
kind: Namespace
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (NamespaceSpec)

Spec визначає поведінку простору імен. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (NamespaceStatus)

Status описує поточний статус простору імен. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

NamespaceSpec

NamespaceSpec описує атрибути простору імен.

finalizers ([]string)

Atomic: буде замінено під час злиття

Finalizers є непрозорим списком значень, які повинні бути порожніми щоб назавжди видалити обʼєкт з сховища. Докладніше: https://kubernetes.io/docs/tasks/administer-cluster/namespaces/

ObjectMeta

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

ObjectMeta — це метадані, які повинні бути у всіх збережених ресурсів, включаючи всі обʼєкти, які користувачі повинні створювати.

name (string)

Ім’я (назва) має бути унікальним у просторі імен. Потрібне під час створення ресурсів, хоча деякі ресурси можуть дозволяти клієнту запитувати створення відповідного імені автоматично. Назва в першу чергу призначена для створення ідемпотентності та визначення конфігурації. Не може бути змінене. Більше інформації: https://kubernetes.io/docs/concepts/overview/working-with-objects/names#names
generateName (string)

GenerateName — це необов’язковий префікс, який використовується сервером для генерації унікального імені, ТІЛЬКИ ЯКЩО поле Name не було надано. Якщо використовується це поле, ім’я, що повертається клієнту, відрізнятиметься від переданого. Це значення також поєднується з унікальним суфіксом. Надане значення має ті самі правила перевірки, що й поле Name, і може бути скорочено на довжину суфікса, необхідного для того, щоб зробити значення унікальним на сервері.

PersistentVolume

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

PersistentVolume

PersistentVolume (PV) — це ресурс зберігання, який впроваджується адміністратором. Він є аналогом ресурсу Node. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes.

apiVersion: v1
kind: PersistentVolume
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (PersistentVolumeSpec)

spec визначає специфікацію постійного тому, що належить кластеру. Впроваджується адміністратором. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistent-volumes
status (PersistentVolumeStatus)

status представляє поточну інформацію/статус для постійного тому. Заповнюється системою. Лише для читання. Докладніше: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistent-volumes

PersistentVolumeSpec

PersistentVolumeSpec — це специфікація постійного тому.

accessModes ([]string)

Atomic: буде замінено під час злиття

PodCertificateRequest v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: certificates.k8s.io/v1beta1

import "k8s.io/api/certificates/v1beta1"

PodCertificateRequest

PodCertificateRequest кодує pod, що запитує сертифікат від певного підписувача.

Kubelets використовують цей API для реалізації cпроєцьованих томів podCertificate.

apiVersion: certificates.k8s.io/v1beta1
kind: PodCertificateRequest
metadata (ObjectMeta)

metadata містить метадані обʼєкта.
spec (PodCertificateRequestSpec), обовʼязково

spec містить детальну інформацію про сертифікат, який запитується.
status (PodCertificateRequestStatus)

статус містить виданий сертифікат та стандартний набір станів.

PodCertificateRequestSpec

PodCertificateRequestSpec описує запит на сертифікат. Всі поля є незмінними після створення.

nodeName (string), обовʼязково

nodeName — це імʼя вузла, до якого приписано под.

Role

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

Role

Роль — це логічне групування PolicyRules у просторі імен, на яке можна посилатися як на одиницю за допомогою RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata (ObjectMeta)

Стандартні метадані обʼєкта.
rules ([]PolicyRule)

Atomic: буде замінено під час злиття

Rules містить всі PolicyRules для цієї Ролі

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

StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

StatefulSet

StatefulSet представляє набір Podʼів з постійною ідентичністю. Ідентичність визначається як:

Мережа: єдине стабільне DNS та імʼя хосту.
Сховище: Стільки VolumeClaims, скільки потрібно.

StatefulSet гарантує, що вказана мережева ідентичність завжди буде зіставлятись з вказаним сховищем.

apiVersion: apps/v1
kind: StatefulSet
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (StatefulSetSpec)

Spec визначає бажані ідентичності Podʼів у цьому наборі.
status (StatefulSetStatus)

Status — це поточний стан Podʼів у цьому StatefulSet. Ці дані можуть бути застарілими на певний проміжок часу.

ValidatingAdmissionPolicy

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicy

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

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata (ObjectMeta)

Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.
spec (ValidatingAdmissionPolicySpec)

Специфікація бажаної поведінки ValidatingAdmissionPolicy.

ValidatingAdmissionPolicySpec — це специфікація бажаної поведінки AdmissionPolicy.
- spec.auditAnnotations ([]AuditAnnotation)
  
  Atomic: буде замінено під час обʼєднання
  
  auditAnnotations містить вирази CEL, які використовуються для створення анотацій аудити для події аудити запиту API. validations і auditAnnotations не можуть бути одночасно порожніми; потрібна щонайменше одна з validations або auditAnnotations.

ControllerRevision

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

ControllerRevision

ControllerRevision впроваджує незмінюваний знімок даних стану. Клієнти відповідають за серіалізацію та десеріалізацію обʼєктів, які містять їх внутрішній стан. Після успішного створення ControllerRevision, його не можна оновити. API Server не пройде валідацію всіх запитів, які намагаються змінити поле Data. Однак ControllerRevision може бути видалено. Зверніть увагу, що через використання цього обʼєкта обома контролерами DaemonSet і StatefulSet для оновлення та відкату, він знаходиться на стадії бета-тестування. З усім тим, його назва та представлення можуть змінюватися в майбутніх версіях, і клієнти не повинні покладатися на його стабільність. Він призначений головним чином для внутрішнього використання контролерами.

Node

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: v1

import "k8s.io/api/core/v1"

Node

Node є робочим вузлом в Kubernetes. Кожен вузол буде мати унікальний ідентифікатор у кеші (тобто в etcd).

apiVersion: v1
kind: Node
metadata (ObjectMeta)

Стандартні метадані об’єкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (NodeSpec)

Spec визначає поведінку вузла. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (NodeStatus)

Останній за часом спостереження статус вузла. Заповнюється системою. Тільки для читання. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

NodeSpec

NodeSpec описує атрибути, з якими створюється вузол.

configSource (NodeConfigSource)

Застаріло: Раніше використовувалося для вказівки джерела конфігурації вузла для функції DynamicKubeletConfig. Цю функцію вилучено.

ObjectReference

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

ObjectReference містить достатньо інформації для того, щоб дозволити вам переглядати або змінювати зазначений обʼєкт.

apiVersion (string)

apiVersion — це версія API ресурсу, до якого вказує цей обʼєкт.
fieldPath (string)

Якщо потрібно посилатися на частину обʼєкта замість цілого обʼєкта, цей рядок повинен містити дійсне висловлення доступу до поля JSON/Go, наприклад, desiredState.manifest.containers[2]. Наприклад, якщо посилання на обʼєкт стосується контейнера у межах Podʼа, це прийме значення подібне: "spec.containers{name}" (де "name" вказує на імʼя контейнера, що спричинило подію), або якщо не вказано жодного імені контейнера "spec.containers[2]" (контейнер з індексом 2 у цьому Pod). Ця синтаксична конструкція вибрана лише для того, щоб мати деякий чітко визначений спосіб посилання на частину обʼєкта.

RoleBinding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: rbac.authorization.k8s.io/v1

import "k8s.io/api/rbac/v1"

RoleBinding

RoleBinding посилається на роль, але не містить її. RoleBinding може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. RoleBinding додає інформацію про субʼєкти через Subjects і інформацію про простір імен, в якому існує. RoleBindings у визначеному просторі імен мають вплив лише в цьому просторі імен.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata (ObjectMeta)

Стандартні метадані обʼєкта.
roleRef (RoleRef), обовʼязкове

RoleRef може посилатися на Role в поточному просторі імен або на ClusterRole в глобальному просторі імен. Якщо RoleRef не може бути розвʼязано, Авторизатор повинен повернути помилку. Це поле є незмінним.

StorageClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

StorageClass

StorageClass описує параметри класу сховища, для якого PersistentVolumes можна динамічно виділяти.

Класи сховищ не мають простору імен; імʼя класу сховища згідно з etcd знаходиться в ObjectMeta.Name.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
provisioner (string), обовʼязково

provisioner вказує на тип провізора.
allowVolumeExpansion (boolean)

allowVolumeExpansion показує, чи дозволяє клас зберігання розширення тому.
allowedTopologies ([]TopologySelectorTerm)

Atomic: буде замінено під час обʼєднання

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

ValidatingAdmissionPolicyBinding

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1

import "k8s.io/api/admissionregistration/v1"

ValidatingAdmissionPolicyBinding

ValidatingAdmissionPolicyBinding повʼязує ValidatingAdmissionPolicy з параметризованими ресурсами. ValidatingAdmissionPolicyBinding і параметризовані CRD разом визначають, як адміністраторам кластерів налаштовувати політики для кластерів.

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

CEL вирази політики повинні мати обчислену вартість CEL нижчу за максимальний бюджет CEL. Кожна оцінка політики отримує незалежний бюджет витрат CEL. Додавання/видалення політик, звʼязувань або параметрів не повинно впливати на те, чи є дана комбінація (політика, звʼязування, параметр) у межах свого бюджету CEL.

DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: apps/v1

import "k8s.io/api/apps/v1"

DaemonSet

DaemonSet представляє налаштування набору фонових служб (демонів).

apiVersion: apps/v1
kind: DaemonSet
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (DaemonSetSpec)

Бажана поведінка цього DaemonSet. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (DaemonSetStatus)

Поточний стан цього DaemonSet. Ці дані можуть бути неактуальними протягом певного часу. Заповнюється системою. Тільки для читання. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

DaemonSetSpec

DaemonSetSpec є специфікацією DaemonSet.

selector (LabelSelector), обовʼязково

Запит міток для Podʼів, якими керує набір демонів. Має мати збіг з міткам шаблону Pod. Докладніше: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

MutatingAdmissionPolicy v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1beta1

import "k8s.io/api/admissionregistration/v1beta1"

MutatingAdmissionPolicy

MutatingAdmissionPolicy описує визначення політики модифікації допуску, яка змінює обʼєкт, що потрапляє в ланцюжок допуску.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingAdmissionPolicy
metadata (ObjectMeta)

Стандартні метадані обʼєкта; Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.
spec (MutatingAdmissionPolicySpec)

Специфікація бажаної поведінки MutatingAdmissionPolicy.

MutatingAdmissionPolicySpec — це специфікація бажаної поведінки політики допуску.
- spec.failurePolicy (string)
  
  failurePolicy визначає, як обробляти відмови для політики допуску. Помилки можуть виникати через помилки розбору виразів CEL, помилки перевірки типів, помилки під час виконання, а також через недійсні або неправильно сконфігуровані визначення чи привʼязки політики.

Patch

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

Patch надає конкретну назву та тип тілу запиту PATCH Kubernetes.

RuntimeClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: node.k8s.io/v1

import "k8s.io/api/node/v1"

RuntimeClass

RuntimeClass визначає клас середовища виконання контейнерів, підтримуваних у кластері. RuntimeClass використовується для визначення, яке середовище виконання контейнерів використовується для запуску всіх контейнерів у Podʼі. RuntimeClass визначаються вручну користувачем або провайдером кластера і посилаються в PodSpec. Kubelet відповідає за розвʼязання посилання RuntimeClassName перед запуском Podʼа. Для отримання додаткової інформації дивіться: https://kubernetes.io/docs/concepts/containers/runtime-class/

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata (ObjectMeta)

Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
handler (string), обовʼязково

handler визначає базове середовище виконання та конфігурацію, яку реалізація CRI буде використовувати для обробки Podʼів цього класу. Можливі значення специфічні для конфігурації вузла та CRI. Припускається, що всі обробники доступні на кожному вузлі, і обробники з однаковими назвами еквівалентні на кожному вузлі. Наприклад, обробник з назвою "runc" може вказувати, що для запуску контейнерів у Podʼі буде використовуватися середовище виконання runc OCI (з використанням нативних Linux контейнерів). Handler повинен бути у нижньому регістрі, відповідати вимогам мітки DNS (RFC 1123) і бути незмінним.

StorageVersionMigration v1beta1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storagemigration.k8s.io/v1beta1

import "k8s.io/api/storagemigration/v1beta1"

StorageVersionMigration

StorageVersionMigration представляє міграцію збережених даних до останньої версії сховища.

apiVersion: storagemigration.k8s.io/v1beta1
kind: StorageVersionMigration
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (StorageVersionMigrationSpec)

Специфікація міграції.
status (StorageVersionMigrationStatus)

Статус міграції.

StorageVersionMigrationSpec

Специфіка міграції версії сховища.

resource (GroupResource), обовʼязково

Ресурс, який мігрує. Мігратор надсилає запити до точки доступу, що обслуговує ресурс. Незмінний.

GroupResource визначає групу та ресурс, але не вимагає версії. Це корисно для ідентифікації понять на етапах пошуку без використання частково дійсних типів.

Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Розгортання (Deployment) забезпечує декларативні оновлення для Podʼів та ReplicaSets.

Ви описуєте бажаний стан у Deployment, і Контролер Deployment змінює фактичний стан на бажаний стан з контрольованою швидкістю. Ви можете визначити Deployment для створення нових ReplicaSets або видалення існуючих Deployment та прийняття всіх їхніх ресурсів новими Deployment.

Job

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

Job

Job представляє конфігурацію окремого завдання.

apiVersion: batch/v1
kind: Job
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (JobSpec)

Специфікація бажаної поведінки завдання. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (JobStatus)

Поточний статус завдання. Детальніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

JobSpec

JobSpec описує, як виглядатиме виконання завдання.

Репліки

template (PodTemplateSpec), обовʼязково

Описує pod, який буде створено під час виконання завдання. Єдині дозволені значення template.spec.restartPolicy — "Never" або "OnFailure". Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
parallelism (int32)

Визначає максимальну бажану кількість Podʼів, які завдання повинно виконувати в будь-який момент часу. Фактична кількість Podʼів, що працюють в стабільному стані, буде меншою за цю кількість, коли ((.spec.completions - .status.successful) < .spec.parallelism), тобто коли залишилося менше роботи, ніж максимально дозволена паралельність. Детальніше: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

Kubelet Checkpoint API

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

MutatingAdmissionPolicyBinding v1alpha1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: admissionregistration.k8s.io/v1alpha1

import "k8s.io/api/admissionregistration/v1alpha1"

MutatingAdmissionPolicyBinding

MutatingAdmissionPolicyBinding звʼязує MutatingAdmissionPolicy з параметризованими ресурсами. MutatingAdmissionPolicyBinding і необовʼязковий параметр resource разом визначають, як адміністратори кластерів налаштовують політики для кластерів.

Для заданого запиту на допуск кожна привʼязка призведе до того, що її політика буде оцінена N разів, де N дорівнює 1 для політик/привʼязок, які не використовують параметри, інакше N — це кількість параметрів, обраних привʼязкою. Кожна оцінка обмежена бюджетом витрат на виконання.

Додавання/видалення політик, привʼязок або параметрів не може вплинути на те, чи знаходиться дана комбінація (політика, привʼязка, параметр) в межах власного бюджету CEL.

Quantity

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/api/resource"

Quantity — це представлення числа з фіксованою комою. Воно надає зручний спосіб перетворення в/з JSON та YAML, на додачу до інструментів String() та AsInt64().

Формат серіалізації виглядає наступним чином:

\<quantity> ::= \<signedNumber>\<suffix>

 (Зауважте, що \<suffix> може бути порожнімy, з "" у \<decimalSI>.)

\<digit> ::= 0 | 1 | ... | 9 
\<digits> ::= \<digit> | \<digit>\<digits> 
\<number> ::= \<digits> | \<digits>.\<digits> | \<digits>. | .\<digits> 
\<sign> ::= "+" | "-" 
\<signedNumber> ::= \<number> | \<sign>\<number> 
\<suffix> ::= \<binarySI> | \<decimalExponent> | \<decimalSI> 
\<binarySI> ::= Ki | Mi | Gi | Ti | Pi | Ei

 (Міжнародна система мір; Див: http://physics.nist.gov/cuu/Units/binary.html)

\<decimalSI> ::= m | "" | k | M | G | T | P | E

 (Зауважте, що 1024 = 1Ki але 1000 = 1k; капіталізація не використовується.)

\<decimalExponent> ::= "e" \<signedNumber> | "E" \<signedNumber>

Незалежно від того, яка з трьох форм експоненти використовується, жодна кількість не може представляти число більше, ніж 2^63-1, а також не може мати більше трьох десяткових знаків. Числа, більші або точніші, будуть обмежені або округлені вгору. (Наприклад: 0.1m буде округлено до 1m.) Це може бути розширено в майбутньому, якщо ми потребуватимемо більших або менших кількостей.

Service

Mon, 01 Jan 0001 00:00:00 +0000

В Kubernetes, Service — це метод надання доступу ззовні до мережевого застосунку, який працює як один чи кілька Podʼів у вашому кластері.

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

ServiceCIDR

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: networking.k8s.io/v1

import "k8s.io/api/networking/v1"

ServiceCIDR

ServiceCIDR визначає діапазон IP-адрес у форматі CIDR (наприклад, 192.168.0.0/24 або 2001:db2::/64). Цей діапазон використовується для виділення ClusterIP для обʼєктів Service.

apiVersion: networking.k8s.io/v1
kind: ServiceCIDR
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (ServiceCIDRSpec)

spec — це бажаний стан ServiceCIDR. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.
status (ServiceCIDRStatus)

status представляє поточний стан ServiceCIDR. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.

ServiceCIDRSpec

ServiceCIDRSpec визначає CIDR, які користувач хоче використовувати для виділення ClusterIP для Services.

cidrs ([]string)

Atomic: буде замінено під час злиття

Volume

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

Volume

Volume становить собою іменований том у Pod, до якого може мати доступ будь-який контейнер у Podʼі.

name (string), обовʼязково

Назва тома. Повинна бути DNS_LABEL і унікальна в межах Pod. Додаткова інформація: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

Відкриті постійні томи

persistentVolumeClaim (PersistentVolumeClaimVolumeSource)

persistentVolumeClaimVolumeSource — це посилання на PersistentVolumeClaim у тому ж просторі імен. Додаткова інформація: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims

PersistentVolumeClaimVolumeSource посилається на PVC користувача в тому ж просторі імен. Цей том знаходить привʼязаний PV та монтує цей том для Podʼа. PersistentVolumeClaimVolumeSource, фактично, є обгорткою навколо іншого типу тому, який належить комусь іншому (системі).

Автентифікація

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці наведено огляд автентифікації в Kubernetes, з акцентом на автентифікацію в Kubernetes API.

Користувачі в Kubernetes

У всіх кластерах Kubernetes є дві категорії користувачів: службові облікові записи, які керуються Kubernetes, і звичайні користувачі.

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

адміністратор розповсюджує приватні ключі
сховище користувачів, таке як Keystone або Google Accounts
файл зі списком імен користувачів та паролів

У цьому відношенні Kubernetes не має обʼєктів, які представляють звичайні облікові записи користувачів. Звичайні користувачі не можуть бути додані до кластера через API виклик.

Анотації аудиту

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка служить довідником по анотаціях аудиту простору імен kubernetes.io. Ці анотації застосовуються до обʼєктів Event з API-групи audit.k8s.io.

Примітка:

Наступні анотації не використовуються в межах Kubernetes API. Коли ви вмикаєте аудит у своєму кластері, дані аудиту подій записуються за допомогою Event з API-групи audit.k8s.io. Ці анотації застосовуються до подій аудиту. Події аудиту відрізняються від обʼєктів у API подій (API-група events.k8s.io).

k8s.io/deprecated

Приклад: k8s.io/deprecated: "true"

Значення повинно бути "true" або "false". Значення "true" вказує на те, що в запит використовував застарілу версію API.

Безпека хмарних середовищ та Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes базується на хмарній архітектурі та використовує рекомендації CNCF щодо найкращих практик з безпеки інформації в хмарних середовищах.

Прочитайте огляд того, як Kubernetes допоможе вам розгорнути безпечну хмарну платформу.

Інформаційна безпека хмарних середовищ

У документів CNCF white paper про безпеку хмарних середовищ визначаються компоненти та практики безпеки, які відповідають різним фазам життєвого циклу.

Фаза життєвого циклу Розробка

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

Для досягнення цього:

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Виконання автоматизованих завдань за допомогою CronJob

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як виконувати автоматизовані завдання за допомогою обʼєкта Kubernetes CronJob.

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

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

Виконання поетапного оновлення DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як виконати поетапне оновлення (rolling update) DaemonSet.

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

Виконання поступового оновлення

Mon, 01 Jan 0001 00:00:00 +0000

Цілі

Виконання постійного оновлення застосунку (rolling update) за допомогою kubectl.

Оновлення застосунку

Поступові оновлення дозволяють виконувати оновлення Deployment без зупинки роботи застосунку за допомогою поетапного оновлення екземплярів Podʼів.

Користувачі очікують, що застосунки будуть доступні постійно, а розробники — випускатимуть нові версії по кілька разів на день. У Kubernetes це робиться за допомогою розгортань з поступовим оновленням. Поступове оновлення (rolling update) дозволяє виконати оновлення Deployment без перерви в роботі застосунку. Це досягається поетапною заміною поточних Podʼів новими. Нові Podʼи призначаються Вузлам з вільними ресурсами, а Kubernetes чекає, доки ці нові Podʼи не почнуть працювати, перш ніж вилучити старі Podʼи.

Використання Antrea для NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як встановити та використовувати втулок Antrea CNI в Kubernetes. Щоб дізнатися більше про проєкт Antrea, прочитайте Вступ до Antrea.

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

Вам потрібно мати кластер Kubernetes. Слідуйте початковому керівництву kubeadm для його створення.

Розгортання Antrea за допомогою kubeadm

Слідуйте керівництву Початок роботи для розгортання Antrea за допомогою kubeadm.

Що далі

Після того, як ваш кластер буде запущений, ви можете перейти до Оголошення мережевої політики, щоб спробувати в дії Kubernetes NetworkPolicy.

Використання kubectl для створення Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Цілі

Дізнайтесь, що таке Deployment застосунків.
Розгорніть свій перший застосунок у Kubernetes за допомогою kubectl.

Процеси Kubernetes Deployment

Deployment відповідає за створення та оновлення екземплярів для вашого застосунку.

Примітка:

Цей навчальний посібник використовує контейнер, який вимагає архітектури AMD64. Якщо ви використовуєте minikube на компʼютері з іншою архітектурою процесора, ви можете спробувати використовувати minikube з драйвером, який може емулювати AMD64. Наприклад, драйвер Docker Desktop може це зробити.

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

Використання Minikube для створення кластера

Mon, 01 Jan 0001 00:00:00 +0000

Цілі

Дізнайтесь, що таке Kubernetes кластер.
Дізнайтесь, що таке Minikube.
Запустіть кластер Kubernetes на вашому компʼютері.

Kubernetes кластери

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

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

Використання Service для доступу до застосунку

Mon, 01 Jan 0001 00:00:00 +0000

Цілі

Дізнайтесь про Service у Kubernetes.
найомтесь з тим, як мітки та селектори повʼязані з Service.
Відкрийте доступ до застосунку по за межами Kubernetes кластера.

Огляд Сервісів в Kubernetes

Існування Podʼів в Kubernetes є обмеженими за часом, також вони мають свій життєвий цикл. Коли робочий вузол припиняє існування, також втрачаються Podʼи, які виконуються на цьому Вузлі. Replicaset може динамічно приводити кластер до бажаного стану шляхом створення нових Podʼів, щоб ваш застосунок продовжував працювати. As another example, consider an image-processing backend with 3 replicas. Наприклад, розгляньмо обробник зображень, що має 3 копії. Ці копії (репліки) можуть бути взаємозамінні; система форонтенду не повинна перейматися репліками бекенду або навіть тим, чи Pod втрачено та створено наново. Проте кожен Pod в кластері Kubernetes має унікальну IP-адресу, навіть Podʼи на одному Вузлі, тому потрібно мати спосіб автоматичного узгодження змін серед Podʼів, щоб ваші застосунки продовжували працювати.

Вимикання вузлів

Mon, 01 Jan 0001 00:00:00 +0000

У кластері Kubernetes вузол може бути вимкнутий плановим відповідним способом або несподівано через такі причини, як відключення електропостачання або інші зовнішні обставини. Вимкнення вузла може призвести до відмови робочого навантаження, якщо вузол не буде виводитись з обслуговування перед вимкненням. Вимкнення вузла може бути відповідним або невідповідним (graceful or non-graceful).

Належне вимикання вузла

Kubelet намагається виявити вимикання системи вузла та завершує виконання Podʼів на вузлі.

Вимоги до версії ядра Linux

Mon, 01 Jan 0001 00:00:00 +0000

Примітка: Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з посібником з контенту перед надсиланням змін. Докладніше.

Багато функцій залежать від певних можливостей ядра і мають мінімальні вимоги до версії ядра. Однак покладатися лише на номери версій ядра може бути недостатньо для деяких операційних систем, оскільки підтримувачі дистрибутивів таких як RHEL, Ubuntu та SUSE часто зворотно переносять вибрані функції до старіших версій ядра (залишаючи старішу версію ядра).

Відкриття зовнішньої IP-адреси для доступу до застосунку в кластері

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як створити обʼєкт Kubernetes Service, який відкриває зовнішню IP-адресу.

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

Встановіть kubectl.
Використовуйте хмарного провайдера, такого як Google Kubernetes Engine або Amazon Web Services, щоб створити кластер Kubernetes. У цьому підручнику створюється зовнішній балансувальник навантаження, який вимагає хмарного провайдера.
Налаштуйте kubectl для спілкування з вашим API-сервером Kubernetes. Для інструкцій дивіться документацію вашого хмарного провайдера.

Цілі

Запустіть пʼять екземплярів застосунку Hello World.
Створіть обʼєкт Service, який відкриває зовнішню IP-адресу.
Використовуйте обʼєкт Service для доступу до запущеного застосунку.

Створення Service для застосунку, що працює в пʼяти Podʼах

Запустіть застосунок Hello World у вашому кластері:

Власні Ресурси

Mon, 01 Jan 0001 00:00:00 +0000

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

Власні ресурси

Ресурс — це точка доступу в API Kubernetes, яка зберігає колекцію обʼєктів API певного виду; наприклад, вбудований ресурс pods містить колекцію обʼєктів Pod.

Встановлення kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як встановити інструменти kubeadm. Для отримання інформації щодо того, як створити кластер за допомогою kubeadm після виконання цього процесу встановлення, див. сторінку Створення кластера за допомогою kubeadm.

Інструкція з встановлення стосується Kubernetes v1.35. Якщо ви хочете використовувати іншу версію Kubernetes, перегляньте натомість такі сторінки:

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

У вас має бути сумісний хост на основі Linux. Проєкт Kubernetes надає загальні інструкції для дистрибутивів Linux, зокрема на базі Debian та Red Hat, а також для дистрибутивів без менеджера пакетів.
2 ГБ або більше оперативної памʼяті на кожній машині (менше може залишити мало місця для ваших застосунків).
2 CPU або більше для машин панелі управління.
Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи приватна мережа підходить).
Унікальні імена хостів, MAC-адреси та product_uuid для кожного вузла. Див. тут для отримання докладнішої інформації.
Відкриті певні порти на ваших машинах. Див. тут для отримання докладнішої інформації.

Примітка:

Встановлення за допомогою kubeadm виконується за допомогою бінарних файлів, які використовують динамічне звʼязування та передбачають, що ваша цільова система надає бібліотеку glibc. Це припущення стосується багатьох дистрибутивів Linux (включаючи Debian, Ubuntu, Fedora, CentOS і т. д.), але не завжди відповідає дійсності у випадку власних та легких дистрибутивів, які типово не включають glibc, наприклад, Alpine Linux. Очікується, що дистрибутив включає або шар сумісності, який забезпечує необхідні символи, або glibc.

Перевірте версію вашої операційної системи

Linux
Windows

Проєкт kubeadm підтримує ядра LTS. Дивіться Список ядер LTS.
Ви можете отримати версію ядра за допомогою команди uname -r.

Докладнішу інформацію наведено у Вимоги до ядра Linux.

Встановлення та налаштування kubectl у Linux

Mon, 01 Jan 0001 00:00:00 +0000

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

Вам потрібно використовувати версію kubectl, яка має мінорну версію що відрізняється не більше ніж на одиницю від мінорної версії вашого кластера. Наприклад, клієнт v1.35 може співпрацювати з панелями управління v1.34, v1.35 та v1.36. Використання останньої сумісної версії kubectl допомагає уникнути непередбачуваних проблем.

Встановлення kubectl у Linux

Існують наступні методи встановлення kubectl у Linux:

Встановлення бінарного файлу kubectl за допомогою curl у Linux
Встановлення за допомогою стандартного пакетного менеджера
Встановлення за допомогою іншого пакетного менеджера

Встановлення бінарного файлу kubectl за допомогою curl у Linux

Завантажте останній випуск за допомогою команди:

Встановлення та налаштування kubectl у macOS

Mon, 01 Jan 0001 00:00:00 +0000

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

Встановлення kubectl у macOS

Існують наступні методи встановлення kubectl у macOS:

Встановлення kubectl у macOS
Перевірка конфігурації kubectl
Опціональне налаштування kubectl та втулка
- Увімкнення автопідстановки оболонки
- Встановлення втулка kubectl convert

Встановлення бінарника kubectl з curl у macOS

Завантажте останнє видання:

Встановлення та налаштування kubectl у Windows

Mon, 01 Jan 0001 00:00:00 +0000

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

Встановлення kubectl у Windows

Існують наступні методи встановлення kubectl у Windows:

Встановлення бінарника kubectl у Windows (за допомогою прямого завантаження або за допомогою curl)
Встановлення за допомогою Chocolatey, Scoop або winget у Windows

Встановлення бінарника kubectl у Windows (за допомогою прямого завантаження або за допомогою curl)

У вас є два варіанти встановлення kubectl на вашому пристрої з Windows

Вузли

Mon, 01 Jan 0001 00:00:00 +0000

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

Декларативне керування обʼєктами Kubernetes з використанням конфігураційних файлів

Mon, 01 Jan 0001 00:00:00 +0000

Обʼєкти Kubernetes можна створювати, оновлювати та видаляти, зберігаючи декілька файлів конфігурації обʼєктів у теці та використовувати kubectl apply для рекурсивного створення та оновлення цих обʼєктів за потреби. Цей метод зберігає записи, зроблені у поточних обʼєктах, без злиття змін до файлів конфігурації обʼєкта. За допомогою kubectl diff також можна переглянути зміни, які буде внесено командою apply.

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

Встановіть kubectl.

Додавання записів до файлу /etc/hosts у Pod за допомогою HostAliases

Mon, 01 Jan 0001 00:00:00 +0000

Додавання записів до файлу /etc/hosts у Pod надає можливість перевизначення розподілу імен на рівні Pod, коли DNS та інші параметри не застосовуються. Ви можете додавати ці власні записи за допомогою поля HostAliases у PodSpec.

Проєкт Kubernetes рекомендує змінювати конфігурацію DNS за допомогою поля hostAliases (частина файлу .spec для Podʼа), а не за допомогою контейнера init або інших засобів для редагування безпосередньо /etc/hosts. Зміни, внесені в інший спосіб, можуть бути перезаписані kubelet під час створення або перезапуску Pod.

Додавання робочих вузлів Linux

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Кожен робочий вузол, що додається, має встановлені необхідні компоненти з Встановлення kubeadm, такі як kubeadm, kubelet і середовище виконання контейнерів.
Запущений кластер kubeadm, створений за допомогою kubeadm init та дотриманням кроків з документа Створення кластера з kubeadm.
Необхідно мати права суперкористувача на вузлі.

Додавання робочих вузлів Linux

Щоб додати нові робочі вузли Linux до кластера, виконайте наступне для кожної машини:

Доступні версії документації

Mon, 01 Jan 0001 00:00:00 +0000

Цей вебсайт містить документацію для поточної версії Kubernetes та чотирьох попередніх версій Kubernetes.

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

Завантаження Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

kubectl

Інструмент командного рядка Kubernetes, kubectl, дозволяє виконувати команди в кластерах Kubernetes.

Заміна середовища виконання контейнерів на вузлі з Docker Engine на containerd

Mon, 01 Jan 0001 00:00:00 +0000

Це завдання визначає кроки, необхідні для оновлення вашого середовища виконання контейнерів на containerd з Docker. Воно буде корисним для операторів кластерів, які працюють з Kubernetes 1.23 або старішими версіями. Воно також охоплює приклад сценарію міграції з dockershim на containerd. З цієї сторінки можна вибрати альтернативні середовища виконання контейнерів.

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

Встановіть containerd. Для отримання додаткової інформації дивіться документацію з встановлення containerd і для конкретних передумов виконуйте кроки описані в посібнику containerd.

Запуск автономного Kublet

Mon, 01 Jan 0001 00:00:00 +0000

Цей посібник показує, як запустити автономний екземпляр kubelet.

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

Після того, як ви пройдете цей посібник, ви можете спробувати використовувати кластер, який має панель управління для керування podʼами та вузлами, а також іншими типами обʼєктів. Ознайомтесь з прикладом в розділі Привіт, minikube.

Запуск застосунку без збереження стану за допомогою Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як запустити застосунок за допомогою обʼєкта Deployment в Kubernetes.

Цілі

Створити розгортання nginx.
Використання kubectl для виведення інформації про розгортання.
Оновити розгортання.

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

Запуск кількох екземплярів вашого застосунку

Mon, 01 Jan 0001 00:00:00 +0000

Цілі

Масштабування застосунку вручну за допомогою kubectl.

Масштабування застосунку

Ви можете створити Deployment з декількома екземплярами з самого початку за допомогою параметра --replicas команди kubectl create deployment.

Раніше ми створили Deployment, а потім робили його загальнодоступним за допомогою Service. Deployment створив лише один Pod для запуску нашого застосунку. Зі збільшенням трафіку, нам потрібно масштабувати застосунок, щоб відповідати зростаючим вимогам користувачів.

Якщо ви ще не працювали над попередніми розділами, почніть з Використання minikube для створення кластера.

Застосування стандартів безпеки Podʼів на рівні кластера

Mon, 01 Jan 0001 00:00:00 +0000

Примітка

Цей навчальний посібник застосовується лише для нових кластерів.

Безпека Pod покладається на контролер допуску, що виконує перевірки відповідно до Стандартів безпеки Podʼів в Kubernetes при створенні нових Podʼів. Це функція, має загальну доступність з випуску v1.25. Цей навчальний посібник показує, як застосувати стандарт безпеки baseline на рівні кластера, що застосовує стандартну конфігурацію для всіх просторів імен у кластері.

Для застосування стандартів безпеки Podʼів до певних просторів імен дивіться Застосування стандартів безпеки Podʼів на рівні простору імен.

Керування cвоп-памʼяттю

Mon, 01 Jan 0001 00:00:00 +0000

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

Керування Secret за допомогою kubectl

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці ви дізнаєтесь, як створювати, редагувати, керувати та видаляти Secret Kubernetes за допомогою інструменту командного рядка kubectl.

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

Компоненти Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить огляд основних компонентів, з яких складається кластер Kubernetes.

Компоненти кластера Kubernetes

Основні компоненти

Кластер Kubernetes складається з панелі управління та одного або декількох робочих вузлів. Ось короткий огляд основних компонентів:

Компоненти панелі управління

Керують загальним станом кластера:

kube-apiserver: Сервер основних компонентів, який надає Kubernetes HTTP API
etcd: Узгоджене та високодоступне сховище значень ключів для всіх даних сервера API
kube-scheduler: Шукає ще не прикріплені до вузла Podʼи та призначає кожен Pod до відповідного вузла.
kube-controller-manager: Запускає контролери для впровадження поведінки API Kubernetes.
cloud-controller-manager (необовʼязково): Інтегрується з інфраструктурою хмарного постачальника.

Компоненти вузлів

Запускаються на кожному вузлі, підтримуючи запущені Podʼи та надаючи середовище виконання Kubernetes:

Мережеві втулки

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes (з версії 1.3 і до останньої версії 1.35 та можливо й потім) дозволяє використовувати мережевий інтерфейс контейнерів (CNI, Container Network Interface) для втулків мережі кластера. Вам потрібно використовувати втулок CNI, який сумісний з вашим кластером та відповідає вашим потребам. В екосистемі Kubernetes доступні різні втулки (як з відкритим, так і закритим кодом).

Для імплементації мережевої моделі Kubernetes необхідно використовувати втулок CNI.

Вам потрібно використовувати втулок CNI, який сумісний з v0.4.0 або більш пізніми версіями специфікації CNI. Проєкт Kubernetes рекомендує використовувати втулок, який сумісний з v1.0.0 специфікації CNI (втулки можуть бути сумісними з кількома версіями специфікації).

Міркування щодо великих кластерів

Mon, 01 Jan 0001 00:00:00 +0000

Кластер — це набір вузлів (фізичних або віртуальних машин), на яких працюють агенти Kubernetes, керовані через панель управління. Kubernetes v1.35 підтримує кластери розміром до 5,000 вузлів. Зокрема, Kubernetes розроблений для роботи з конфігураціями, які відповідають всім наступним критеріям:

Не більше 110 Podʼів на вузол
Не більше 5,000 вузлів
Не більше 150,000 Podʼів загалом
Не більше 300,000 контейнерів загалом

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

Налагодження Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

Діагностика проблеми

Перший крок у розвʼязанні проблем — перевірка. Що сталося? Проблема у ваших Podʼах, Контролері Реплікацій чи Service?

Налагодження Podʼів
Налагодження Контролерів Реплікацій
Налагодження Services

Налагодження Podʼів

Перший крок у налагоджені Podʼа — це його перевірка. Перевірте поточний стан Podʼа та останні події за допомогою наступної команди:

Налаштування DRA у кластері

Mon, 01 Jan 0001 00:00:00 +0000

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

На цій сторінці показано, як налаштувати динамічне виділення ресурсів (DRA) у кластері Kubernetes шляхом активації груп API та налаштування класів пристроїв. Ці інструкції призначені для адміністраторів кластерів.

Про DRA

Функція Kubernetes, яка дозволяє вам запитувати ресурси та ділитися ними з іншими Podʼами. Ці ресурси часто приєднуються до пристроїів, наприклад, до апаратних прискорювачів.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Налаштування шару агрегації

Mon, 01 Jan 0001 00:00:00 +0000

Налаштування шару агрегації дозволяє розширити apiserver Kubernetes додатковими API, які не є частиною основних API Kubernetes.

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

Обмеження діапазонів

Mon, 01 Jan 0001 00:00:00 +0000

Типово контейнери запускаються з необмеженими обчислювальними ресурсами у кластері Kubernetes. Використовуючи квоти ресурсів Kubernetes, адміністратори (оператори кластера) можуть обмежити споживання та створення ресурсів кластера (таких як час ЦП, памʼять та постійне сховище) у визначеному namespace. У межах простору імен Pod може використовувати стільки ЦП та памʼяті, скільки дозволяють ResourceQuotas, що застосовуються до цього простору імен. Як оператору кластера або адміністратору на рівні простору імен вам також може бути важливо переконатися, що один обʼєкт не може монополізувати всі доступні ресурси у просторі імен.

Образ контейнера

Mon, 01 Jan 0001 00:00:00 +0000

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

Зазвичай ви створюєте образ контейнера свого застосунку та розміщуєте його в реєстрі перш ніж посилатися на нього у Pod.

Ця сторінка надає огляд концепції образів контейнерів.

Основи StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Перш ніж розпочати цей підручник, вам слід ознайомитися з наступними концепціями Kubernetes:

Podʼи
Cluster DNS
Headless Services
PersistentVolumes
PersistentVolumes Provisioning
Інструмент командного рядка kubectl

Перевищення ємності вузла для кластера

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Перегляд Podʼів та Вузлів (Node)

Mon, 01 Jan 0001 00:00:00 +0000

Цілі

Дізнайтесь, що таке Pod в Kubernetes.
Дізнайтесь, що таке Node в Kubernetes.
Діагностика розгорнутих застосунків.

Podʼи Kubernetes

Pod — це група з одного або декількох контейнерів (таких як Docker), що має спільне сховище даних (volumes), IP-адресу та містить інформацію про те, як їх запустити.

Коли ви створили Deployment у Модулі 2, Kubernetes створив Pod, щоб розмістити екземпляр вашого застосунку. Pod — це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (таких як Docker) та ресурсів, спільних для цих контейнерів. До цих ресурсів належать:

Планувальник Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes планування означає забезпечення того, що Podʼи відповідно призначаються вузлам, щоб їх можна було запустити за допомогою Kubelet.

Огляд планування

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

Політики груп Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

Кожна група Podʼів, визначена у Workload, повинна мати політику планування. Ця політика визначає, як планувальник обробляє колекцію Podʼів.

Типи політик

Наразі API підтримує два типи політик: basic та gang. Ви повинні вказати тільки одну політику для кожної групи.

Політика `basic`

Політика basic наказує планувальнику вважати всі Podʼи у групі незалежними сутностями, плануючи їх за допомогою стандартного поведіння Kubernetes.

Посібник з вмісту документації

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить вказівки щодо документації Kubernetes.

Якщо у вас є запитання про те, що дозволено, приєднуйтесь до каналу #sig-docs у Kubernetes Slack і запитуйте!

Ви можете зареєструватися на Kubernetes Slack за адресою https://slack.k8s.io/.

Для отримання інформації про створення нового вмісту для документації Kubernetes, дотримуйтесь посібника зі стилю.

Огляд

Сирці вебсайту Kubernetes, включаючи документацію, знаходиться в репозиторії kubernetes/website.

Більшість документації Kubernetes знаходиться в теці kubernetes/website/content/<language_code>/docs і специфічна для проєкту Kubernetes.

Протоколи Service

Mon, 01 Jan 0001 00:00:00 +0000

Якщо ви налаштовуєте Service, ви можете обрати будь-який мережевий протокол, що підтримується Kubernetes.

Kubernetes підтримує наступні протоколи для Service:

SCTP
TCP (типово)
UDP

Коли ви визначаєте Service, ви також можете вказати протокол застосунку, який він використовує.

Цей документ описує деякі особливі випадки, всі з яких зазвичай використовують TCP як транспортний протокол:

HTTP та HTTPS
PROXY protocol
TLS термінація на балансувальнику навантаження

Підтримувані протоколи

Існує 3 допустимі значення для protocol порту Service:

Рецензування pull request

Mon, 01 Jan 0001 00:00:00 +0000

Будь-хто може рецензувати pull request документації. Відвідайте розділ pull requests у репозиторії вебсайту Kubernetes, щоб побачити відкриті pull request.

Рецензування pull request документації — це чудовий спосіб познайомитися зі спільнотою Kubernetes. Це допомагає вам вивчити кодову базу та завоювати довіру інших учасників.

Перед рецензуванням доцільно:

Ознайомитись з настановами з контенту та керівництвом зі стилю, щоб залишати обґрунтовані коментарі.
Розуміти різні ролі та обовʼязки у спільноті документації Kubernetes.

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

Перш ніж почати рецензування:

Розгортання та доступ до Інфопанелі Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes Dashboard є застарілим та не підтримується.

Проєк Kubernetes Dashboard перебуває в архівованому стані і більше не активно підтримується. Для нових встановлень розгляньте можливість використання Headlamp.

Примітка:

Для розгортання в кластері, схожого на Kubernetes Dashboard, дивіться інструкцію з встановлення Headlamp у кластері.

Інфопанель Kubernetes — це вебінтерфейс для кластерів Kubernetes. Ви можете використовувати Інфопанель для розгортання контейнерізованих застосунків в кластері Kubernetes, керувати ресурсами кластера, відстежувати та виправляти проблеми в роботі застосунків. Ви можете використовувати Інфопанель для перегляду роботи застосунків у вашому кластері, створення або зміни ресурсів Kubernetes (таких як Deployment, Job, DaemonSet та інші). Наприклад, ви можете масштабувати Deployment, ініціювати поступове оновлення, перезапустити Pod чи розгорнути новий застосунок за допомоги помічника з розгортання.

Ролі та обовʼязки

Mon, 01 Jan 0001 00:00:00 +0000

Будь-хто може зробити внесок у Kubernetes. Зі зростанням ваших внесків до SIG Docs, ви можете подати заявку на різні рівні членства в спільноті. Ці ролі дозволяють брати на себе більше відповідальності в спільноті. Кожна роль вимагає більше часу та відданості. Ролі є такими:

Будь-хто: регулярні учасники документації Kubernetes
Члени: можуть призначати та розподіляти тікети, а також надавати відгук на pull requestʼи, який не є обовʼязковим до виконання
Рецензенти: можуть керувати рецензією документаційних pull request'ів і гарантувати якість змін
Затверджувачі: можуть керувати рецензією документації та зливати зміни

Будь-хто

Будь-хто з обліковим записом GitHub може зробити свій внесок у Kubernetes. SIG Docs вітає всіх нових учасників!

Створення pull request

Mon, 01 Jan 0001 00:00:00 +0000

Примітка:

Розробники коду: Якщо ви документуєте нову функцію для майбутнього релізу Kubernetes, дивіться Документування нової функції.

Щоб створити нові сторінки або покращити наявні, відкрийте pull request (PR). Переконайтеся, що ви виконали всі вимоги у розділі Перш ніж почати.

Якщо ваша зміна невелика або ви незнайомі з git, прочитайте Зміни за допомогою GitHub, щоб дізнатися, як редагувати сторінку.

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

Томи

Mon, 01 Jan 0001 00:00:00 +0000

Томи Kubernetes надають можливість контейнерам у podʼах отримувати доступ до даних у файловій системі та обмінюватися даними з ними. Існують різні типи томів, які можна використовувати для різних цілей, наприклад

заповнення файлу конфігурації на основі ConfigMap або Secret
надання деякого тимчасового простору для зберігання podʼам
надання спільного доступу до файлової системи двом різним контейнерам у тому самому podʼі
надання спільного доступу до файлової системи між двома різними podʼами (навіть якщо ці podʼи запущено на різних вузлах)
довготривале зберігання даних, щоб вони залишалися доступними навіть після перезапуску або заміни Podʼа
передача інформації про конфігурацію застосунку, що працює у контейнері, на основі даних про Pod, у якому знаходиться контейнер (наприклад, повідомлення контейнера sidecar про те, у якому просторі імен працює Pod)
надання доступу лише на читання до даних в іншому образі контейнера

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

Трекер проблем Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Робота з кодом Kubernetes та публічними проблемами відстежуватися за допомогою GitHub Issues.

Офіційний список відомих CVE (вразливості безпеки), які були оголошені Комітетом з питань реагування на загрози безпеці
Тікети на GitHub, повʼязані з CVE

Повідомлення про безпеку надсилаються у список розсилки kubernetes-security-announce@googlegroups.com.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Вам потрібно мати кластер Kubernetes.
Вам також потрібно встановити kubectl — дивіться встановлення інструментів

Перевірка налаштувань kubectl

Переконайтеся, що ви правильно встановили та налаштували kubectl на вашому локальному компʼютері. Перевірте версію kubectl, щоб впевнитися, що вона актуальна та сумісна з вашим кластером.

Функціональні можливості

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить огляд різних функціональних можливостей, які адміністратор може вказати для різних компонентів Kubernetes.

Дивіться функціональні стадії для пояснення стадій функції.

Огляд

Функціональні можливості — це набір пар ключ=значення, які описують функції Kubernetes. Ви можете увімкнути або вимкнути ці функції, використовуючи прапорець командного рядка --feature-gates на кожному компоненті Kubernetes.

Як увімкнути функціональні можливості

Щоб увімкнути або вимкнути функціональну можливість для певного компонента Kubernetes, використовуйте прапорець --feature-gates.

Швидкий довідник kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить перелік загальновживаних команд та прапорців kubectl.

Примітка:

Ці інструкції призначені для Kubernetes v1.35. Для перевірки версії скористайтесь командою kubectl version.

Автозавершення команд kubeclt

BASH

source <(kubectl completion bash) # встановлення автозавершення для bash в поточному терміналі, пакунок bash-completion повинен бути встановлений.
echo "source <(kubectl completion bash)" >> ~/.bashrc # додавання автозавершення для bash в профіль bash для постіного використання

Ви також можете використовувати зручне скорочення для kubectl, яке також працює з автозавершенням:

Швидкий старт з довідковою документацією

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати скрипт update-imported-docs.py для генерації довідкової документації Kubernetes. Скрипт автоматизує налаштування збірки та генерує довідкову документацію для релізу.

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

Вимоги:

Вам потрібна машина, що працює під управлінням Linux або macOS.
Вам потрібно встановити ці інструменти:
- Python версії v3.7.x+
- Git
- Golang версії 1.13+
- Pip для встановлення PyYAML
- PyYAML версії v5.1.2
- make
- gcc компілятор/лінкер
- Docker (Потрібен тільки для довідки по команді kubectl)
Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

CronJob

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: batch/v1

import "k8s.io/api/batch/v1"

CronJob

CronJob являє собою конфігурацію одного завдання cron.

apiVersion: batch/v1
kind: CronJob
metadata (ObjectMeta):

Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (CronJobSpec):

Специфікація бажаної поведінки cron job, включаючи розклад. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status (CronJobStatus):

Поточний статус cron job. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

CronJobSpec

CronJobSpec описує, як виглядатиме виконання завдання та коли воно буде запущено.

jobTemplate (JobTemplateSpec), обовʼязково

Вказує на шаблон задачі, яка буде створена під час виконання CronJob.

JobTemplateSpec описує дані, які повинні бути у задачі при створенні з шаблону

ResourceFieldSelector

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

ResourceFieldSelector представляє ресурси контейнера (cpu, memory) та їх формат виводу.

resource (string), обовʼязково

Обовʼязково: ресурс, який потрібно вибрати.
containerName (string)

Назва контейнера: обовʼязково для томів, необовʼязково для змінних середовища.
divisor (Quantity)

Вказує формат виводу відображених ресурсів, стандартне значення — "1".

VolumeAttachment

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

VolumeAttachment

VolumeAttachment фіксує намір приєднати або відʼєднати вказаний том до/від вказаного вузла.

Обʼєкти VolumeAttachment не належать до просторів імен.

apiVersion: storage.k8s.io/v1
kind: VolumeAttachment
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (VolumeAttachmentSpec), обовʼязково

spec представляє специфікацію бажаної поведінки при приєднанні/відʼєднанні тому. Заповнюється системою Kubernetes.
status (VolumeAttachmentStatus)

status представляє статус запиту VolumeAttachment. Заповнюється сутністю, що завершує операцію приєднання або відʼєднання, тобто external-attacher.

VolumeAttachmentSpec

VolumeAttachmentSpec — це специфікація запиту на приєднання тому.

Додавання робочих вузлів Windows

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка пояснює, як додати робочі вузли Windows до кластера kubeadm.

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

Запущений екземпляр Windows Server 2022 (або новіший) з адміністративним доступом.
Запущений кластер kubeadm, створений за допомогою kubeadm init та з дотриманням кроків з документа Створення кластера з kubeadm.

Додавання робочих вузлів Windows

Примітка:

Для полегшення додавання робочих вузлів Windows до кластера використовуються скрипти PowerShell з репозиторію https://sigs.k8s.io/sig-windows-tools.

Виконайте наступні кроки для кожної машини:

Загальні параметри

Mon, 01 Jan 0001 00:00:00 +0000

allowWatchBookmarks

allowWatchBookmarks запитує події спостереження з типом "BOOKMARK". Сервери, які не реалізують закладки, можуть ігнорувати цей прапорець, і закладки надсилаються на розсуд сервера. Клієнти не повинні припускати, що закладки повертаються через певні інтервали, і не можуть припускати, що сервер надішле будь-яку подію BOOKMARK під час сеансу. Якщо це не спостереження, це поле ігнорується.

continue

Опція continue повинна бути встановлена при отриманні додаткових результатів з сервера. Оскільки це значення визначається сервером, клієнти можуть використовувати значення continue лише з попереднього результату запиту з ідентичними параметрами запиту (за винятком значення continue), і сервер може відхилити значення continue, яке він не розпізнає. Якщо вказане значення continue більше не є дійсним через закінчення терміну дії (зазвичай від п’яти до п’ятнадцяти хвилин) або зміну конфігурації на сервері, сервер відповість помилкою 410 ResourceExpired разом з токеном продовження. Якщо клієнту потрібен узгоджений список, він повинен перезапустити свій список без поля continue. В іншому випадку клієнт може надіслати інший запит списку з токеном, отриманим разом із помилкою 410, сервер відповість списком, починаючи з наступного ключа, але з останнім знімком, який не узгоджується з попередніми результатами списку — об’єкти, які створені, змінені або видалені після першого запиту списку будуть включені у відповідь, якщо їх ключі знаходяться після «наступного ключа».

Попередній локальний перегляд змін

Mon, 01 Jan 0001 00:00:00 +0000

Before you're going to open a new PR, previewing your changes is recommended. A preview lets you catch build errors or markdown formatting problems.

Попередній перегляд змін локально

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

Hugo в контейнері
Hugo в командному рядку

Примітка:

Наведені нижче команди використовують Docker як стандартний контейнерний рушій. Щоб змінити це налаштування, встановіть змінну середовища CONTAINER_ENGINE.

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

HorizontalPodAutoscaler

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: autoscaling/v1

import "k8s.io/api/autoscaling/v1"

HorizontalPodAutoscaler

Конфігурація горизонтального автомасштабування Podʼів.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata.
spec (HorizontalPodAutoscalerSpec)

spec визначає поведінку автомасштабування. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.
status (HorizontalPodAutoscalerStatus)

status містить поточну інформацію про автомасштабування.

HorizontalPodAutoscalerSpec

Специфікація горизонтального автомасштабування Podʼів.

maxReplicas (int32), обовʼязково

maxReplicas — верхня межа для кількості Podʼів, яку може встановити автомасштабувальник; не може бути менше, ніж MinReplicas.
scaleTargetRef (CrossVersionObjectReference), обовʼязково

посилання на масштабований ресурс; горизонтальний автомасштабувальник Podʼів буде вивчати поточне використання ресурсу і встановлювати бажану кількість Podʼів за допомогою його субресурсу Scale (масштаб).

Status

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/apimachinery/pkg/apis/meta/v1"

Status — це значення, що повертається для викликів, які не повертають інших обʼєктів.

apiVersion (string)

APIVersion визначає версійну схему цього представлення обʼєкта. Сервери повинні конвертувати визнані схеми до останнього внутрішнього значення, і можуть відхиляти невизнані значення. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
code (int32)

Рекомендований HTTP-код відповіді для цього статусу, 0, якщо не встановлено.
details (StatusDetails)

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

VolumeAttributesClass v1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: storage.k8s.io/v1

import "k8s.io/api/storage/v1"

VolumeAttributesClass

VolumeAttributesClass представляє специфікацію змінних атрибутів тома, визначених драйвером CSI. Клас можна вказати під час динамічного резервування PersistentVolumeClaims і змінити у специфікації PersistentVolumeClaim після резервування.

apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
driverName (string), обовʼязково

Імʼя драйвера CSI Це поле є незмінним.

VolumeAttributesClassList

VolumeAttributesClassList — це колекція обʼєктів VolumeAttributesClass.

apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClassList
metadata (ListMeta)

Стандартні метадані списку. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
items ([]VolumeAttributesClass), обовʼязково

items — це список обʼєктів VolumeAttributesClass.

HorizontalPodAutoscaler

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: autoscaling/v2

import "k8s.io/api/autoscaling/v2"

HorizontalPodAutoscaler

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

Зрозуміло, ось переклад без формату YAML:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata (ObjectMeta):

metadata — стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec (HorizontalPodAutoscalerSpec):

spec — специфікація поведінки автомасштабування. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.
status (HorizontalPodAutoscalerStatus):

status містить поточну інформацію про автомасштабування.

HorizontalPodAutoscalerSpec

HorizontalPodAutoscalerSpec описує бажану функціональність HorizontalPodAutoscaler.

maxReplicas (int32), обовʼязково

TypedLocalObjectReference

Mon, 01 Jan 0001 00:00:00 +0000

import "k8s.io/api/core/v1"

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

kind (string), обовʼязково

Kind — це тип ресурсу, на який посилаються.
name (string), обовʼязково

Name — це назва ресурсу, на який посилаються.
apiGroup (string)

APIGroup — це група для ресурсу, на який посилаються. Якщо APIGroup не вказано, вказаний Kind повинен бути в основній групі API. Для будь-яких інших сторонніх типів APIGroup є обовʼязковим.

PriorityClass

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: scheduling.k8s.io/v1

import "k8s.io/api/scheduling/v1"

PriorityClass

PriorityClass визначає зіставлення імені класу пріоритету з цілим значенням пріоритету.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Додаткова інформація: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
value (int32), обовʼязково

Представляє ціле значення цього класу пріоритету. Це фактичний пріоритет, який отримують Podʼи, коли вони мають імʼя цього класу у їхній специфікації.
description (string)

Опис є довільним рядком, який зазвичай надає вказівки про те, коли слід використовувати цей клас пріоритету.
globalDefault (boolean)

DeviceTaintRule v1alpha3

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1alpha3

import "k8s.io/api/resource/v1alpha3"

DeviceTaintRule

DeviceTaintRule додає одну позначку taint до всіх пристроїв, які відповідають селектору. Це має той самий ефект, як якби позначку taint було вказано безпосередньо в ResourceSlice драйвером DRA.

apiVersion: resource.k8s.io/v1alpha3
kind: DeviceTaintRule
metadata (ObjectMeta)

Стандартні метадані обʼєкта
spec (DeviceTaintRuleSpec), обовʼязково

Spec визначає селектор та одну позначку taint.

Зміна spec автоматично збільшує номер metadata.generation.
status (DeviceTaintRuleStatus)

Status надає інформацію про те, що було запрошено в специфікації.

DeviceTaintRuleSpec

DeviceTaintRuleSpec визначає селектор та одну позначку taint.

Автомасштабування Node

Mon, 01 Jan 0001 00:00:00 +0000

Для того, щоб запускати робочі навантаження у вашому кластері, вам потрібні Вузли. Вузли у вашому кластері можуть бути автомасштабовані — динамічно виділені, або консолідовані, щоб забезпечити необхідну потужність при оптимізації витрат. Автомасштабування виконується автомасштабувальниками Вузлів.

Виділення Вузлів

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

Конвеєер метрик ресурсів

Mon, 01 Jan 0001 00:00:00 +0000

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

HorizontalPodAutoscaler (HPA) та VerticalPodAutoscaler (VPA) використовують дані з API метрик для налаштування реплік робочого навантаження та ресурсів для задоволення вимог користувачів.

Налаштування API сервера розширення

Mon, 01 Jan 0001 00:00:00 +0000

Налаштування API сервера розширення для роботи з шаром агрегації дозволяє розширювати apiserver Kubernetes додатковими API, які не є частиною основних API Kubernetes.

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

Стандарти безпеки для Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

Профіль	Опис
Privileged	Необмежена політика, яка забезпечує найширший можливий рівень дозволів. Ця політика дозволяє відомі підвищення привілеїв.
Baseline	Мінімально обмежена політика, яка запобігає відомим підвищенням привілеїв. Дозволяє стандартну (мінімально визначену) конфігурацію Pod.
Restricted	Дуже обмежена політика, яка відповідає поточним найкращим практикам забезпечення безпеки Pod.

Деталі профілю

Privileged

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

Функціональні можливості (вилучені)

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить список функціональних можливостей воріт, які були видалені. Інформація на цій сторінці є довідковою. Вилучені функціональні можливості відрізняються від GA або застарілих тим, що вилучені функціональні можливості більше не розпізнається як дійсний функціональний елемент. Однак, GA'ed або застарілі функціональні ворота все ще розпізнаються відповідними компонентами Kubernetes, хоча вони не можуть спричинити жодних відмінностей у поведінці кластера.

Для отримання інформації про функціональні можливості, які все ще розпізнаються компонентами Kubernetes, зверніться до Таблиці функціональних можливостей Alpha/Beta або Таблиці функціональних можливостей Graduated/Deprecated.

ResourceClaim v1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1

import "k8s.io/api/resource/v1"

ResourceClaim

ResourceClaim описує запит на доступ до ресурсів у кластері, для використання робочими навантаженнями. Наприклад, якщо робоче навантаження потребує пристрою-акселератора з конкретними властивостями, ось як виражається цей запит. Розділ статусу відстежує, чи було задоволено цей запит і які саме ресурси були виділені.

Це альфа-тип і потребує увімкнення функціональної можливості DynamicResourceAllocation.

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata (ObjectMeta)

Стандартні метадані обʼєкта
spec (ResourceClaimSpec), обовʼязково

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

ResourceClaimTemplate v1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1

import "k8s.io/api/resource/v1"

ResourceClaimTemplate

ResourceClaimTemplate використовується для створення обʼєктів ResourceClaim.

Це альфа-тип і вимагає увімкнення функціональної можливості DynamicResourceAllocation.

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata (ObjectMeta)

Стандартні метадані обʼєкта.
spec (ResourceClaimTemplateSpec), обовʼязково

Описує ResourceClaim, який буде створений.

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

ResourceClaimTemplateSpec

ResourceClaimTemplateSpec містить метадані та поля для ResourceClaim.

spec (ResourceClaimSpec), обовʼязково

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

Інструменти для моніторингу ресурсів

Mon, 01 Jan 0001 00:00:00 +0000

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

У Kubernetes моніторинг застосунків не залежить від єдиного рішення для моніторингу. На нових кластерах ви можете використовувати конвеєри метрик ресурсів або повні метрики, щоб збирати статистику для моніторингу.

ResourceSlice v1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: resource.k8s.io/v1

import "k8s.io/api/resource/v1"

ResourceSlice

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

Наразі підтримуються лише пристрої з атрибутами та ємностями (capacities). Кожен пристрій у певному пулі, незалежно від кількості ResourceSlices, повинен мати унікальне імʼя. ResourceSlice, в якому пристрій публікується, може змінюватися з часом. Унікальний ідентифікатор для пристрою — це кортеж <імʼя драйвера>, <імʼя пулу>, <імʼя пристрою>.

Workload v1alpha1

Mon, 01 Jan 0001 00:00:00 +0000

apiVersion: scheduling.k8s.io/v1alpha1

import "k8s.io/api/scheduling/v1alpha1"

Workload

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

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata (ObjectMeta)

Стандартні метадані обʼєкта. Назва повинна бути піддоменом DNS.
spec (WorkloadSpec), обовʼязково

Spec визначає бажану поведінку Workload.

WorkloadSpec

WorkloadSpec визначає бажаний стан Workload.

podGroups ([]PodGroup), обовʼязково

Map: унікальні значення імені ключа будуть збережені під час злиття

ConfigMaps

Mon, 01 Jan 0001 00:00:00 +0000

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

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

kubeadm init

Mon, 01 Jan 0001 00:00:00 +0000

Ця команда ініціалізує вузол панелі управління Kubernetes.

Опис

Запустіть цю команду, щоб налаштувати панель управління Kubernetes

Команда "init" виконує наступні етапи:

preflight Виконання перевірок перед запуском
certs Генерація сертифікатів
 /ca Генерація самопідписаного CA Kubernetes для забезпечення ідентифікації інших компонентів Kubernetes
 /apiserver Генерація сертифіката для обслуговування Kubernetes API
 /apiserver-kubelet-client Генерація сертифіката для зʼєднання API server з kubelet
 /front-proxy-ca Генерація самопідписаного CA для забезпечення ідентифікації front proxy
 /front-proxy-client Генерація сертифіката для клієнта front proxy
 /etcd-ca Генерація самопідписаного CA для забезпечення ідентифікації etcd
 /etcd-server Генерація сертифіката для обслуговування etcd
 /etcd-peer Генерація сертифіката для звʼязку між вузлами etcd
 /etcd-healthcheck-client Генерація сертифіката для перевірки живучості etcd
 /apiserver-etcd-client Генерація сертифіката, який використовується apiserver для доступу до etcd
 /sa Генерація приватного ключа для підписання токенів службових облікових записів разом з його відкритим ключем
kubeconfig Генерація всіх kubeconfig файлів, необхідних для створення панелі управління, та kubeconfig файлу адміністратора
 /admin Генерація kubeconfig файлу для використання адміністратором та самим kubeadm
 /super-admin Генерація kubeconfig файлу для супер-адміністратора
 /kubelet Генерація kubeconfig файлу для використання kubelet *лише* для завантаження кластера
 /controller-manager Генерація kubeconfig файлу для використання контролер-менеджером
 /scheduler Генерація kubeconfig файлу для використання планувальником
etcd Генерація маніфесту статичного Pod для локального etcd
 /local Генерація маніфесту статичного Pod для локального, одновузлового локального etcd
control-plane Генерація всіх маніфестів статичних Podʼів, необхідних для створення панелі управління
 /apiserver Генерація маніфесту статичного Pod для kube-apiserver
 /controller-manager Генерація маніфесту статичного Pod для kube-controller-manager
 /scheduler Генерація маніфесту статичного Pod для kube-scheduler
kubelet-start Запис налаштувань kubelet та (перезавантаження) kubelet
upload-config Завантаження конфігурації kubeadm та kubelet до ConfigMap
upload-config Завантаження конфігурації kubeadm та kubelet у ConfigMap
 /kubeadm Завантаження конфігурації кластера kubeadm у ConfigMap
 /kubelet Завантаження конфігурації компоненту kubelet у ConfigMap
upload-certs Завантаження сертифікатів у kubeadm-certs
mark-control-plane Маркування вузла як вузла панелі управління
bootstrap-token Генерація bootstrap токенів, які використовуються для приєднання вузла до кластера
kubelet-finalize Оновлення налаштувань, що стосуються kubelet, після TLS завантаження
 /enable-client-cert-rotation Ввімкнути ротацію сертифікатів клієнтів kubelet
addon Встановлення необхідних надбудов для проходження тестів відповідності
 /coredns Встановлення надбудови CoreDNS у Kubernetes кластер
 /kube-proxy Встановлення надбудови kube-proxy у Kubernetes кластер
show-join-command Показати команду приєднання для вузлів керування та робочих вузлів

kubeadm init [прапорці]

Параметри

--apiserver-advertise-address string

IP адреса, за якою API Server буде оголошувати, що він слухає. Якщо не встановлено, буде використаний стандартний мережевий інтерфейс.

Pod Security Admission

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

ReplicaSet

Mon, 01 Jan 0001 00:00:00 +0000

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

Як працює ReplicaSet

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

Автентифікація за допомогою Bootstrap-токенів

Mon, 01 Jan 0001 00:00:00 +0000

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

Bootstrap-токени — це простий токен на предʼявника, який призначений для використання під час створення нових кластерів або приєднання нових вузлів до наявного кластера. Він був створений для підтримки kubeadm, але може використовуватися в інших контекстах для користувачів, які бажають створювати кластери без kubeadm. Також він призначений для роботи, через політику RBAC, з kubelet TLS Bootstrapping.

Огляд Bootstrap-токенів

Bootstrap-токени визначені як певний тип secretʼів (bootstrap.kubernetes.io/token), що знаходяться в просторі імен kube-system. Ці secret читаються Bootstrap Authenticator з API Server. Протерміновані токени видаляються контролером TokenCleaner у Controller Manager. Токени також використовуються для створення підпису для конкретного ConfigMap, який використовується у процесі "виявлення" через контролер BootstrapSigner.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Визначення залежних змінних середовища

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як визначити змінні середовища для контейнера у Kubernetes Pod.

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

Виконання відкату DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як виконати відкат на DaemonSet.

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

Використання Calico для NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує кілька швидких способів створення кластера Calico в Kubernetes.

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

Вирішіть, чи ви хочете розгорнути хмарний або локальний кластер.

Створення кластера Calico з Google Kubernetes Engine (GKE)

Передумова: gcloud.

Щоб запустити кластер GKE з Calico, включіть прапорець --enable-network-policy.

Синтаксис

gcloud container clusters create [ІМ'Я_КЛАСТЕРА] --enable-network-policy

Приклад

gcloud container clusters create my-calico-cluster --enable-network-policy

Для перевірки розгортання використовуйте наступну команду.
```
kubectl get pods --namespace=kube-system
```
Podʼи Calico починаються з calico. Перевірте, щоб кожен з них мав статус Running.

Відповідальні за PR

Mon, 01 Jan 0001 00:00:00 +0000

SIG Docs затверджувачі беруть участь у тижневих чергуваннях стосовно управління pull request'ами для репозиторію.

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

Обовʼязки

Кожного дня під час тижневого чергування відповідальний за PR:

Робить огляд відкритих pull request'ів на відповідність стилю та змісту.
- Почніть з найменших PRʼів (size/XS), і закінчіть найбільшими (size/XXL). Огляньте стільки PRʼів, скільки зможете.
Переконайтеся, що учасники PR підписали CLA.
- Використовуйте цей скрипт, щоб нагадати учасникам, які не підписали CLA, зробити це.
Надання відгуків про зміни та запит технічних оглядів від членів інших SIG.
- Надання своїх пропозицій щодо запропонованих змін у PR.
- Якщо вам потрібно перевірити зміст, залиште коментар у PR і запросіть більше деталей.
- Призначте відповідну мітку(и) sig/.
- Якщо необхідно, призначте рецензентів з блоку reviewers: у метаданих файлу.
- Ви також можете позначити SIG для огляду, коментуючи @kubernetes/<sig>-pr-reviews у PR.
Використовуйте коментар /approve для затвердження PR для злиття. Зливайте PR, коли він готовий.
- PRʼи повинні мати коментар /lgtm від іншого члена перед злиттям.
- Розгляньте можливість прийняття технічно правильного змісту, який не відповідає настановам зі стилю. Під час затвердження змін відкрийте новий тікет для розвʼязання питання стилю. Зазвичай такі питання стилю можна описати як гарні перші завдання.
- Використання виправлень стилю як гарних перших завдань — це хороший спосіб забезпечити наявність легших завдань для допомоги в адаптації нових учасників.
Також перевіряйте pull requestʼи до коду генератора довідкової документації та оглядайте їх (або залучайте допомогу).
Підтримуйте відповідального за тікети у розгляді та теґуванні нових тікетів щодня. Дивіться Розгляд та категоризація тікетів для керівництва з використання метаданих SIG Docs.

Примітка:

Обовʼязки відповідального за PR не застосовуються до PRʼів локалізації (неангломовних PRʼів). Команди локалізації мають свої власні процеси та команди для огляду своїх PRʼів. Однак часто корисно переконатися, що PRʼи локалізації правильно позначені, переглянути невеликі PRʼи, що не залежать від мови (наприклад, оновлення посилань), або позначити рецензентів чи учасників у довготривалих PRʼах (тих, що відкриті понад 6 місяців і не оновлювалися більше як місяць).

Корисні запити GitHub для відповідальних

Наступні запити корисні під час роботи з PRʼами. Після обробки цих запитів зазвичай залишається невеликий список PRʼів для огляду. Ці запити виключають PRʼи локалізації. Усі запити стосуються основної гілки, крім останнього.

Відповідальні за тікети

Mon, 01 Jan 0001 00:00:00 +0000

На додаток до PR чергування, офіційні затверджувачі, рецензенти та члени SIG Docs беруть участь у тижневих чергуваннях у розгляді та категоризації тікетів в репозиторії.

Обовʼязки

Кожного дня під час тижневого чергування Відповідальний за тікети буде відповідати за:

Щоденний розгляд та тегування нових тікетів. Дивіться Розглядв та категоризація тікетів для керівництва з використання метаданих SIG Docs.
Слідкування за застарілими та "протухлими" тікетами в репозиторії kubernetes/website.
Підтримку дошки тікетів.

Вимоги

Повинен бути активним членом організації Kubernetes.
Мінімум 15 значущих внесків у Kubernetes (з яких певна кількість має бути спрямована на kubernetes/website).
Виконання ролі неофіційно вже деякий час.

Корисні команди Prow для відповідальних за тікети

Нижче наведені деякі команди, що часто використовуються Відповідальними за тікетами:

Відстеження стану вузлів

Mon, 01 Jan 0001 00:00:00 +0000

Node Problem Detector — це служба для моніторингу та звітування про стан вузла. Ви можете запустити Node Problem Detector як DaemonSet або окремий демон. Node Problem Detector збирає інформацію про проблеми вузла з різних демонів і повідомляє їх на сервер API як стан вузла або як події.

Для отримання інформації щодо встановлення та використання Node Problem Detector, див. Документацію проєкту Node Problem Detector.

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

Внесок у код Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як зробити внесок у проєкт kubernetes/kubernetes. Ви можете виправити помилки, знайдені в документації API Kubernetes або вмісті компонентів Kubernetes, таких як kubeadm, kube-apiserver та kube-controller-manager.

Якщо ви хочете відновити довідкову документацію для API Kubernetes або компонентів kube-* з коду upstream, перегляньте наступні інструкції:

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

Вам потрібно встановити наступні інструменти:

Втулки пристроїв

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes надає фреймворк втулків пристроїв, який ви можете використовувати для оголошення системних апаратних ресурсів Kubelet.

Замість того, щоб вносити зміни в код самого Kubernetes, вендори можуть реалізувати втулки пристроїв, які ви розгортаєте або вручну, або як DaemonSet. Цільові пристрої включають GPU, мережеві інтерфейси високої продуктивності, FPGA, адаптери InfiniBand, та інші подібні обчислювальні ресурси, які можуть вимагати ініціалізації та налаштування від вендора.

Груба паралельна обробка за допомогою черги роботи

Mon, 01 Jan 0001 00:00:00 +0000

У цьому прикладі ви запустите Job Kubernetes з кількома паралельними робочими процесами.

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

Ось огляд кроків у цьому прикладі:

Запустіть службу черги повідомлень. У цьому прикладі ви використовуєте RabbitMQ, але ви можете використовувати іншу. На практиці ви налаштовували б службу черги повідомлень один раз і використовували б її для багатьох робочих завдань.
Створіть чергу та заповніть її повідомленнями. Кожне повідомлення являє собою одне завдання для виконання. У цьому прикладі повідомлення — це ціле число, на якому ми будемо виконувати тривалі обчислення.
Запустіть Job, що працює над завданнями з черги. Job створює декілька Podʼів. Кожен Pod бере одне завдання з черги повідомлень, обробляє його та завершує роботу.

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

Ви вже маєте бути знайомі з основним, не-паралельним використанням Job.

Декларативна перевірка API

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes 1.35 включає необовʼязкову декларативну перевірку для API. Якщо її увімкнено, сервер API Kubernetes може використовувати цей механізм, а не застарілий підхід, який покладається на рукописний код Go (файли validation.go), щоб гарантувати, що запити до API є дійсними. Розробники Kubernetes та люди, які розширюють Kubernetes API, можуть визначати правила валідації безпосередньо поряд з визначеннями типів API (файли types.go). Автори коду визначають спеціальні теґи коментарів (наприклад, +k8s:minimum=0). Генератор коду (validation-gen) потім використовує ці теґи для створення оптимізованого коду Go для перевірки API.

Декларативне керування обʼєктами Kubernetes за допомогою Kustomize

Mon, 01 Jan 0001 00:00:00 +0000

Kustomize — це окремий інструмент для налаштування обʼєктів Kubernetes за допомогою файлу кастомізації.

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

kubectl kustomize <kustomization_directory>

Щоб застосувати ці ресурси, запустіть kubectl apply з прапорцем --kustomize або -k:

kubectl apply -k <kustomization_directory>

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

Встановіть kubectl.

Рецензування для затверджувачів та рецензентів

Mon, 01 Jan 0001 00:00:00 +0000

Рецензенти та затверджувачі SIG Docs виконують кілька додаткових дій під час огляду змін.

Щотижня конкретний затверджувач документації добровільно погоджується переглядати та рецензувати pull request'и (PR). Ця особа є "PR Wrangler" на тиждень. Детальнішу інформацію можна знайти в розкладі PR Wrangler. Щоб стати PR Wrangler, відвідайте щотижневу зустріч SIG Docs і станьте волонтером. Навіть якщо ви не внесені до розкладу на поточний тиждень, ви все одно можете переглядати pull request'и, які не знаходяться в активному перегляді.

Документування функцій для випуску

Mon, 01 Jan 0001 00:00:00 +0000

Кожен великий випуск Kubernetes вводить нові функції, які потребують документації. Нові випуски також приносять оновлення наявних функцій і документації (наприклад, оновлення функції з alpha до beta).

Зазвичай робоча група SIG, відповідальна за функцію, подає чернетку документації функції як pull request до відповідної гілки розробки репозиторію kubernetes/website, а хтось з команди SIG Docs надає редакторський відгук або безпосередньо редагує чернетку. Цей розділ охоплює конвенції з гілками та процес, що використовуються під час релізу обома групами.

Доступ до кластерів

Mon, 01 Jan 0001 00:00:00 +0000

В цій темі обговорюється кілька способів взаємодії з кластерами.

Перший доступ з kubectl

При першому доступі до Kubernetes API ми пропонуємо використовувати Kubernetes CLI, kubectl.

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

Запуск одноекземплярного застосунку зі збереженням стану

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці показано, як запустити одноекземплярний застосунок зі збереженням стану (Stateful) в Kubernetes, використовуючи PersistentVolume та Deployment. Застосунок — MySQL.

Цілі

Створити PersistentVolume, посилаючись на диск у вашому середовищі.
Створити Deployment MySQL.
Використання MySQL для інших Podʼів в кластері за відомим DNS-імʼям.

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

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

Запуск у кількох зонах

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує запуск Kubernetes у кількох зонах відмов.

Контекст

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

Застосування Стандартів безпеки Pod на рівні простору імен

Mon, 01 Jan 0001 00:00:00 +0000

Примітка

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

Pod Security Admission — це контролер допуску, який застосовує Стандарти безпеки Pod при створенні Podʼів. Це функція, яка є загально доступною з v1.25. У цьому посібнику ви будете застосовувати Стандарт безпеки Pod baseline, по одному простору імен за раз.

Ви також можете застосовувати Стандарти безпеки Pod до кількох просторів імен одночасно на рівні кластера. Щоб дізнатися більше, перейдіть за посиланням Застосування Стандартів безпеки Pod на рівні кластера.

Звʼязок між Вузлами та Панеллю управління

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ описує шляхи звʼязку між API-сервером та кластером Kubernetes. Мета — надати користувачам можливість налаштувати їхнє встановлення для зміцнення конфігурації мережі так, щоб кластер можна було запускати в ненадійній мережі (або на повністю публічних IP-адресах у хмарному середовищі).

Звʼязок Вузла з Панеллю управління

У Kubernetes існує шаблон API "hub-and-spoke". Всі використання API вузлів (або Podʼів, які вони виконують) завершуються на API-сервері. Інші компоненти панелі управління не призначені для експонування віддалених служб. API-сервер налаштований для прослуховування віддалених підключень на захищеному порту HTTPS (зазвичай 443) з однією або декількома формами автентифікації клієнта. Рекомендується включити одну чи кілька форм авторизації, особливо якщо анонімні запити або токени службового облікового запису дозволені.

Квоти ресурсів

Mon, 01 Jan 0001 00:00:00 +0000

Коли декілька користувачів або команд спільно використовують кластер з фіксованою кількістю вузлів, є можливість, що одна команда може використовувати більше, ніж свою справедливу частку ресурсів.

Квоти ресурсів є інструментом для адміністраторів для розвʼязання цієї проблеми.

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

Керування Secret за допомогою конфігураційного файлу

Mon, 01 Jan 0001 00:00:00 +0000

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

Створення Secret

Ви можете спочатку визначити обʼєкт Secret у форматі JSON або YAML у маніфесті, а потім створити цей обʼєкт. Ресурс Secret містить два словники: data та stringData. Поле data використовується для зберігання довільних даних, закодованих за допомогою base64. Поле stringData надається для зручності, і воно дозволяє вам надавати ті самі дані у вигляді незакодованих рядків. Ключі data та stringData повинні складатися з буквено-цифрових символів, -, _ або ..

Команди kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Довідник команд kubectl

Концепції API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

API Kubernetes — це програмний інтерфейс на основі ресурсів (RESTful), який надається через HTTP. Він підтримує отримання, створення, оновлення та видалення основних ресурсів за допомогою стандартних HTTP-дієслів (POST, PUT, PATCH, DELETE, GET).

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

Метрики SLI компонентів Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Типово Kubernetes 1.35 публікує метрики Індикаторів Рівня Обслуговування (SLI) для кожного компонентного бінарного файлу Kubernetes. Ця точка доступу метрики відкривається на порту HTTPS кожного компонента за шляхом /metrics/slis. Функціональна можливість ComponentSLIs типово увімкнена для кожного компонента Kubernetes починаючи з версії v1.27.

Метрики SLI

З увімкненими метриками SLI кожен компонент Kubernetes відкриває дві метрики, позначені для кожної перевірки стану:

Налагодження Service

Mon, 01 Jan 0001 00:00:00 +0000

Досить часто виникає проблема в нових інсталяціях Kubernetes, коли Service не працює належним чином. Ви запустили свої Podʼи за допомогою Deployment (або іншого контролера робочих навантажень) і створили Service, але не отримуєте відповіді при спробі отримати до нього доступ. Цей документ, сподіваємось, допоможе вам зрозуміти, що йде не так.

Виконання команд у Podʼі

Для багатьох кроків ви захочете побачити, що бачить Pod, який працює в кластері. Найпростіший спосіб зробити це — запустити інтерактивний Pod busybox:

Налаштування кількох планувальників

Mon, 01 Jan 0001 00:00:00 +0000

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

Детальний опис того, як реалізувати планувальник, виходить за рамки цього документа. Будь ласка, зверніться до реалізації kube-scheduler в pkg/scheduler в теці вихідних кодів Kubernetes для канонічного прикладу.

Налаштування Планувальника

Mon, 01 Jan 0001 00:00:00 +0000

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

Ви можете налаштувати поведінку kube-scheduler, написавши конфігураційний файл і передавши його шлях як аргумент командного рядка.

Профіль планування дозволяє налаштувати різні етапи планування в kube-scheduler. Кожен етап відображається в точці розширення. Втулки забезпечують поведінку планування, реалізуючи одну або кілька таких точок розширення.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

Кластер Kubernetes може бути розділений на простори імен. Якщо ви створюєте Pod у просторі імен, який має типове обмеження CPU limit, і будь-який контейнер у цьому Podʼі не вказує своє власне обмеження CPU, то панель управління назначає типове обмеження CPU цьому контейнеру.

Оновлення конфігурації за допомогою ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить покроковий приклад оновлення конфігурації всередині Podʼа за допомогою ConfigMap і базується на завданні Налаштування Podʼа для використання ConfigMap. Наприкінці цього посібника ви зрозумієте, як змінити конфігурацію для запущеного застосунку. Цей посібник використовує образи alpine та nginx як приклади.

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

Підключення застосунків за допомогою Service

Mon, 01 Jan 0001 00:00:00 +0000

Модель Kubernetes для підключення контейнерів

Тепер, коли у вас є постійно працюючий, реплікований застосунок, ви можете дати до нього доступ з мережі.

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

Постійні томи

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ описує постійні томи (persistent volumes) в Kubernetes. Рекомендується вже мати уявлення про томи, StorageClasses та VolumeAttributesClasses.

Вступ

Управління системою зберігання даних — це завдання, що відрізняється від управління обчислювальними ресурсами. Підсистема PersistentVolume надає API для користувачів та адміністраторів, який відділяє деталі того, як відбувається надання сховища від того, як воно використовується. Для цього ми вводимо два нових ресурси API: PersistentVolume і PersistentVolumeClaim.

PersistentVolume (PV) — це частина системи зберігання в кластері, яка була надана адміністратором або динамічно надана за допомогою Storage Classes. Це ресурс в кластері, так само як вузол — це ресурс кластера. PV — це втулки томів, так само як Volumes, але вони мають життєвий цикл, незалежний від будь-якого окремого Podʼа, який використовує PV. Цей обʼєкт API охоплює деталі реалізації зберігання, такі як NFS, iSCSI або система зберігання, специфічна для постачальника хмарних послуг.

Призначення Podʼів до Вузлів

Mon, 01 Jan 0001 00:00:00 +0000

Ви можете обмежити Pod так, щоб він був обмежений для запуску на конкретних вузлах, або віддавав перевагу запуску на певних вузлах. Існують кілька способів як це зробити, а рекомендовані підходи використовують усі селектори міток для полегшення вибору. Зазвичай вам не потрібно встановлювати жодні обмеження такого роду; планувальник автоматично робить розумне розміщення (наприклад, розподіл Podʼів по вузлах так, щоб не розміщувати Podʼи на вузлі з недостатньою кількістю вільних ресурсів). Однак є деякі обставини, коли ви можете контролювати, на якому вузлі розгортається Pod, наприклад, щоб переконатися, що Pod потрапляє на вузол з прикріпленим до нього SSD, або спільно розміщувати Podʼи з двох різних служб, які багато спілкуються в одній зоні доступності.

Призначення пристроїв робочим навантаженням за допомогою DRA

Mon, 01 Jan 0001 00:00:00 +0000

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

На цій сторінці показано, як призначати пристрої для ваших Podʼів за допомогою динамічного розподілу ресурсів (DRA). Ці інструкції призначені для операторів робочих навантажень. Перед прочитанням цієї сторінки ознайомтеся з принципами роботи DRA та термінами, такими як ResourceClaims і ResourceClaimTemplates. Докладніше дивіться у розділі Динамічний розподіл ресурсів (DRA).

Приклад: Розгортання PHP застосунку гостьової книги з Redis

Mon, 01 Jan 0001 00:00:00 +0000

Цей посібник показує, як створити та розгорнути простий (але не готовий до промислового використання) багатошаровий вебзастосунок, використовуючи Kubernetes та Docker. Цей приклад складається з наступних компонентів:

Одно-екземплярний Redis для зберігання записів у гостьовій книзі
Кілька веб-фронтендів

Цілі

Запустити Redis-лідер.
Запустити двох Redis-фолловерів.
Запустити фронтенд гостьової книги.
Опублікувати та переглянути Frontend Service.
Виконати очищення.

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

Приклад: Розгортання WordPress та MySQL з постійними томами

Mon, 01 Jan 0001 00:00:00 +0000

У цьому посібнику ви дізнаєтеся, як розгорнути сайт WordPress та базу даних MySQL за допомогою Minikube. Обидва застосунки використовують PersistentVolumes та PersistentVolumeClaims для зберігання даних.

Постійні томи (PersistentVolume (PV)) — це частина системи зберігання в кластері, яку адміністратор вручну надав або яку Kubernetes автоматично надав за допомогою StorageClass. Запити на постійні томи (PersistentVolumeClaim (PVC)) — це запит на зберігання, який користувач може отримати через PV. PersistentVolumes та PersistentVolumeClaims незалежні від життєвого циклу Podʼів і зберігають дані під час перезапуску, перепланування та навіть видалення Podʼів.

Пропозиції щодо покращення вмісту

Mon, 01 Jan 0001 00:00:00 +0000

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

У більшості випадків нова робота над документацією Kubernetes починається з тікета на GitHub. Потім учасники Kubernetes переглядають, класифікують та теґують проблеми за потреби. Після цього, ви або інший учасник спільноти Kubernetes відкриваєте pull request зі змінами, щоб розвʼязати проблему.

Створення issue

Якщо ви хочете запропонувати покращення наявного контенту або помітили помилку, створіть тікет.

Процес розкриття інформації про безпеку в Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує процес розкриття інформації про безпеку в Kubernetes.

Оголошення з питань безпеки

Приєднуйтесь до групи kubernetes-security-announce, щоб отримувати електронні листи щодо безпеки та основних оголошень API.

Повідомлення про вразливості

Ми дуже вдячні фахівцям з безпеки та користувачам, які повідомляють про вразливості Kubernetes Open Source Community. Всі звіти ретельно розглядаються командою волонтерів спільноти.

Для повідомлення про вразливість подайте свій звіт у Програму винагородження за виправлення помилок у Kubernetes. Це дозволяє класифікувати та обробляти вразливість за стандартизованими часовими рамками відповіді.

Розвʼязання проблем kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

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

Якщо вашої проблеми немає в переліку нижче, будь ласка, скористайтесь настпуним:

Ви вважаєте, що це помилка в kubeadm:
- Відвідайте github.com/kubernetes/kubeadm, пошукайте в списку наявних повідомлень.
- Якщо ви не знайшли свою проблему, створіть нове повідомлення про проблему використовуючи готовий шаблон.
Ви не впевнені, що це проблема в роботі kubeadm, ви можете запитати в Slack в каналі #kubeadm, або поставити питання на Stack Overflow. Будь ласка, додайте теґи #kubeadm та #kubernetes.

Розширення API Kubernetes за допомогою CustomResourceDefinitions

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як встановити власний ресурс у API Kubernetes, створивши CustomResourceDefinition.

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

Розширення діапазонів IP Service

Mon, 01 Jan 0001 00:00:00 +0000

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

У цьому документі описано, як розширити наявний діапазон IP-адрес, призначених Serviceʼу в кластері.

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

Середовище виконання контейнерів

Mon, 01 Jan 0001 00:00:00 +0000

Примітка: Dockershim було вилучено з проєкту Kubernetes починаючи з випуску 1.24. Ознайомтесь з Питання та відповіді щодо вилучення Dockershim для отримання додаткових відомостей.

Для того, щоб запускати Podʼи на кожному вузлі кластера, потрібно встановити container runtime. Ця сторінка надає огляд того, які компоненти беруть в цьому участь, та описує повʼязані завдання для налаштування вузлів.

Середовище контейнера

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує ресурси, доступні контейнерам в середовищі контейнера.

Середовище контейнера

Середовище контейнера Kubernetes надає кілька важливих ресурсів контейнерам:

Файлову систему, яка є комбінацією образу та одного чи декількох томів.
Інформацію про сам контейнер.
Інформацію про інші обʼєкти в кластері.

Інформація про контейнер

hostname контейнера є імʼям Podʼа, в якому він працює. Воно доступне через команду hostname або виклик функції gethostname у бібліотеці libc.

Імʼя та простір імен Pod доступні як змінні середовища через downward API.

Сертифікати

Mon, 01 Jan 0001 00:00:00 +0000

Щоб дізнатись, як генерувати сертифікати для вашого кластера, дивіться розділ Завдань — Сертифікати.

Статті про видалення dockershim та використання сумісних з CRI середовищ виконання

Mon, 01 Jan 0001 00:00:00 +0000

Це список статей й інших сторінок, що стосуються видалення dockershim у Kubernetes та використання сумісних з CRI контейнерних середовищ виконання у звʼязку з цим видаленням.

Проєкт Kubernetes

Блог Kubernetes: Часті запитання щодо видалення Dockershim (оригінал опубліковано 2020/12/02)
Блог Kubernetes: Оновлено: Часті запитання щодо видалення Dockershim (оновлення опубліковано 2022/02/17)
Блог Kubernetes: Kubernetes переходить від Dockershim: Зобовʼязання та наступні кроки (опубліковано 2022/01/07)
Блог Kubernetes: Видалення dockershim наближається. Чи готові ви? (опубліковано 2021/11/12)

Управління обʼєктами Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Інструмент командного рядка kubectl підтримує кілька різних способів створення та управління обʼєктами Kubernetes. Цей документ надає огляд різних підходів. Для отримання деталей щодо управління обʼєктами за допомогою Kubectl читайте Книгу Kubectl.

Техніки управління

Попередження:

Обʼєкт Kubernetes повинен управлятися лише з використанням однієї техніки. Змішування різних технік для того самого обʼєкта призводить до невизначеної поведінки.

Техніка управління	Діє на	Рекомендоване середовище	Підтримувані інструменти	Крива навчання
Імперативні команди	Живі обʼєкти	Проєкти розробки	1+	Налегша
Імперативна конфігурація обʼєктів	Окремі файли	Продуктові проєкти	1	Середня
Декларативна конфігурація обʼєктів	Теки файлів	Продуктові проєкти	1+	Найскладніша

Імперативні команди

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

Шар агрегації API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Шар агрегації відрізняється від Custom Resource Definitions, які є способом зробити так, щоб kube-apiserver визнавав нові види обʼєктів.

Шар агрегації

Шар агрегації працює в процесі разом з kube-apiserver. До того, як розширений ресурс буде зареєстровано, шар агрегації не виконуватиме жодних дій. Для реєстрації API ви додаєте обʼєкт APIService, який "запитує" URL-шлях у Kubernetes API. На цьому етапі шар агрегації буде передавати будь-що, що надійде на цей API-шлях (наприклад, /apis/myextension.mycompany.io/v1/…), зареєстрованому APIService.

Projected томи

Mon, 01 Jan 0001 00:00:00 +0000

У цьому документі описано спроєцьовані томи в Kubernetes. Рекомендується ознайомитися з томами для кращого розуміння.

Вступ

Том projected відображає кілька наявних джерел томів в одну теку.

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

secret
downwardAPI
configMap
serviceAccountToken
clusterTrustBundle
podCertificate

Всі джерела повинні бути в тому ж просторі імен, що й Pod. Для отримання додаткових відомостей дивіться документ з дизайну все-в-одному томі.

Приклад конфігурації з secret, downwardAPI та configMap

pods/storage/projected-secret-downwardapi-configmap.yaml

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 з встановленим нестандартним режимом дозволу

pods/storage/projected-secrets-nondefault-permission-mode.yaml

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: 511

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

Офіційний список CVE

Mon, 01 Jan 0001 00:00:00 +0000

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

Це список офіційних CVE, оголошених Комітетом з питань реагування на загрози безпеці Kubernetes. Детальніше дивіться в Процес розкриття інформації про безпеку в Kubernetes.

Проєкт Kubernetes публікує програмно доступний потік опублікованих проблем безпеки у форматах JSON feed та RSS feed. Ви можете отримати до них доступ, виконавши наступні команди:

JSON feed
RSS feed

Посилання на формат JSON

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Посилання на формат RSS

Server-Side Apply

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes підтримує співпрацю кількох аплікаторів для керування полями одного обʼєкта.

Server-Side Apply (Серверне застосування) надає необовʼязковий механізм для контролера вашого кластера, щоб відстежувати зміни в полях обʼєкта. На рівні конкретного ресурсу, Server-Side Apply записує та відстежує інформацію про контроль над полями цього обʼєкта.

Server-Side Apply допомагає користувачам та контролерам керувати своїми ресурсами за допомогою декларативної конфігурації. Клієнти можуть створювати та змінювати обʼєкти декларативно, подаючи їх повністю визначений намір.

Службові облікові записи

Mon, 01 Jan 0001 00:00:00 +0000

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

Що таке службові облікові записи?

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

Ingress

Mon, 01 Jan 0001 00:00:00 +0000

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

Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP.

Ingress може надавати балансування навантаження, розшифровування SSL-трафіку та віртуальний хостинг на основі імен.

Примітка:

Проєкт Kubernetes рекомендує використовувати Gateway замість Ingress. API Ingress наразі перебуває в стані замороження.

Це означає, що:

API Ingress є загальнодоступним і на нього поширюються гарантії стабільності для загальнодоступних API. Проєкт Kubernetes не планує видаляти Ingress із Kubernetes.
API Ingress більше не розробляється і не буде зазнавати подальших змін або оновлень.

Термінологія

Для ясності цей посібник визначає наступні терміни:

kube-apiserver

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Сервер API Kubernetes перевіряє та налаштовує дані для обʼєктів api, які включають поди, сервіси, replicationcontrollers та інші. API Server обслуговує REST-операції та забезпечує інтерфейс до спільного стану кластера, через який взаємодіють всі інші компоненти.

kube-apiserver [flags]

Параметри

--admission-control strings

Допуск поділяється на два етапи. На першому етапі виконуються тільки втулки допуску, що змінюють дані. На другому етапі виконуються тільки втулки допуску, що перевіряють дані. Імена в наведеному нижче списку можуть позначати втулки, що перевіряють дані, втулки, що змінюють дані, або обидва типи. Порядок втулків, в якому вони передаються до цього прапорця, не має значення. Список, розділений комами: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionPolicy, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeDeclaredFeatureValidator, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PodNodeSelector, PodSecurity, PodTolerationRestriction, PodTopologyLabels, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. (ЗАСТАРІЛО: Замість цього використовуйте --enable-admission-plugins або --disable-admission-plugins. Буде видалено в майбутній версії.)

kube-controller-manager

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Менеджер контролерів Kubernetes — це демон, який вбудовує основні цикли керування, що постачаються з Kubernetes. У робототехніці та автоматизації автоматизації, цикл керування — це нескінченний цикл, який регулює стан системи. У Kubernetes контролер — це цикл керування, який відстежує спільний стан кластера через apiserver і вносить зміни, намагаючись перевести поточний стан у бажаний. Приклади контролерів, які постачаються з Kubernetes сьогодні це контролер реплікації, контролер точок доступу, контролер просторів імен та контролер службових облікових записів.

kube-proxy

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Мережевий проксі-сервер Kubernetes працює на кожному вузлі. Це відображає сервіси, визначені у Kubernetes API, на кожному вузлі і може виконувати просте перенаправлення потоків TCP, UDP і SCTP або циклічне перенаправлення TCP, UDP і SCTP через набір бекендів. Наразі IP-адреси та порти кластерів обслуговування можна знайти за допомогою сумісних з Docker-посиланнями змінні оточення, що визначають порти, відкриті проксі-сервісом. Існує надбудова яка надає кластерний DNS для цих кластерних IP-адрес. Користувач повинен створити сервіс за допомогою API apiserver, щоб налаштувати проксі.

kube-scheduler

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

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

kube-scheduler [flags]

Параметри

--allow-metric-labels stringToString Типово: []

Зіставляє метрику-мітку зі списком дозволених значень цієї мітки. Формат ключа — <MetricName>,<LabelName>. Формат значення — < allowed_value>, <allowed_value>...наприклад, metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'.

kubeadm join

Mon, 01 Jan 0001 00:00:00 +0000

Ця команда ініціалізує новий вузол Kubernetes і приєднує його до наявного кластера.

Запустіть цю команду на будь-якому компʼютері, який ви хочете приєднати до існуючого кластера

Опис

Під час приєднання до ініціалізованого кластера за допомогою kubeadm, необхідно встановити двосторонню довіру. Цей процес розділяється на два етапи: виявлення (щоб Node довіряв Панелі Управління Kubernetes) та TLS завантаження (щоб Панель управління Kubernetes довіряла Node).

Існує дві основні схеми для виявлення. Перша — використовувати спільний токен разом з IP-адресою сервера API. Друга — надати файл, який є підмножиною стандартного файлу kubeconfig. Файл discovery/kubeconfig підтримує токен, втулки автентифікації client-go ("exec"), "tokenFile" та "authProvider". Цей файл може бути локальним або завантаженим через URL HTTPS. Форми приєднання є:

kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

kubectl керує менеджером кластерів Kubernetes.

Докладніше: https://kubernetes.io/docs/reference/kubectl/

kubectl [flags]

Параметри

--as string

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

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

--as-uid string

UID, який використовується для операції.

--as-user-extra strings

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

kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

kubectl керує менеджером кластерів Kubernetes.

Додаткову інформацію можна знайти в розділі Інструмент командного рядка (kubectl).

kubectl [flags]

Параметри

--add-dir-header

Якщо true, додає теку файлу до заголовка повідомлень логу

--alsologtostderr

писати лог до standard error, а також в файл

--as string

Імʼя користувача, яке використовується для виконання операції.

--as-group stringArray

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

--azure-container-registry-config string

Шлях до файлу, що містить інформацію про конфігурацію реєстру контейнера Azure.

--cache-dir string Типово: "$HOME/.kube/cache"

Типове розташування теки кешу

kubectl alpha kuberc

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Керує файлом налаштувань користувача (kuberc).

Файл kuberc дозволяє налаштувати вашу роботу з kubectl.

kubectl alpha kuberc SUBCOMMAND

Приклади

# Переглянути поточну конфігурацію kuberc
kubectl alpha kuberc view

# Встановити стандартне значення для прапорця команди
kubectl alpha kuberc set --section defaults --command get --option output=wide

# Створити аліас для команди
kubectl alpha kuberc set --section aliases --name getn --command get --prependarg nodes --option output=wide

Параметри

-h, --help

довідка для kuberc

kubectl alpha kuberc set

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановлює значення у файлі конфігурації kuberc.

Використовуйте --section, щоб вказати, чи встановлювати стандартні значення чи аліаси.

Для стандартних значень: Встановлює стандартні значення прапорців для команд kubectl. Прапорець --command повинен вказувати лише команду (наприклад, "get", "create", "set env"), не ресурси.

Для аліасів: Створює аліас команд з опціональними значеннями прапорців та аргументами. Використовуйте --prependarg та --appendarg, щоб включити ресурси або інші аргументи.

kubectl alpha kuberc set --section (defaults|aliases) --command COMMAND

Приклади

 # Встановити стандартний формат виводу команди 'get'
 kubectl alpha kuberc set --section defaults --command get --option output=wide

 # Встановити стандартний формат виводу для підкоманди
 kubectl alpha kuberc set --section defaults --command "set env" --option output=yaml

 # Створити аліас 'getn' для команди 'get' з попередньо доданим ресурсом 'nodes'
 kubectl alpha kuberc set --section aliases --name getn --command get --prependarg nodes --option output=wide

 # Створити аліас 'runx' для команди 'run' з доданими аргументами
 kubectl alpha kuberc set --section aliases --name runx --command run --option image=nginx --appendarg "--" --appendarg custom-arg1

 # Перезаписати наявне стандартне значення
 kubectl alpha kuberc set --section defaults --command get --option output=json --overwrite

Параметри

--appendarg strings

Аргумент для додавання до команди (можна вказувати кілька разів, лише для аліасів)

kubectl alpha kuberc view

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показати вміст файлу kuberc у вказаному форматі виводу.

kubectl alpha kuberc view

Приклади

# Переглянути конфігурацію kuberc у форматі YAML (стандартно)
kubectl alpha kuberc view

# Переглянути конфігурацію kuberc у форматі JSON
kubectl alpha kuberc view --output json

# Переглянути конкретний файл kuberc
kubectl alpha kuberc view --kuberc /path/to/kuberc

Параметри

--allow-missing-template-keys Default: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang та jsonpath.

kubectl apply edit-last-applied

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Редагуйте останні анотації last-applied-configuration ресурсів зі стандартного редактора.

Команда edit-last-applied дозволяє безпосередньо редагувати будь-який API-ресурс, який ви можете отримати за допомогою інструментів командного рядка. Вона відкриє редактор, визначений вашими змінними середовища KUBE_EDITOR або EDITOR, або використає стандартний редактор — 'vi' для Linux або 'notepad' для Windows. Ви можете редагувати кілька обʼєктів, але зміни застосовуються поодинці. Команда приймає імена файлів або аргументи командного рядка, але файли, на які ви посилаєтесь, повинні бути збереженими версіями ресурсів.

kubectl apply set-last-applied

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановлює останню last-applied-configuration анотацію, встановивши її, щоб відповідати вмісту файлу. Це призводить до того, що last-applied-configuration оновлюється так, ніби 'kubectl apply -f<file> ' було запущено без оновлення будь-яких інших частин обʼєкта.

kubectl apply set-last-applied -f FILENAME

Приклади

# Встановити last-applied-configuration ресурсу, щоб відповідати вмісту файлу
kubectl apply set-last-applied -f deploy.yaml

# Виконати set-last-applied для кожного файлу конфігурації у директорії
kubectl apply set-last-applied -f path/

# Встановити last-applied-configuration ресурсу, щоб відповідати вмісту файлу; створить анотацію, якщо вона ще не існує
kubectl apply set-last-applied -f deploy.yaml --create-annotation=true

Параметри

--allow-missing-template-keys Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath.

kubectl apply view-last-applied

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Переглянути останні застосовані конфігурації за типом/іменем або файлом.

Стандартно вивід буде зроблено у stdout у форматі YAML. Ви можете змінити формат виводу за допомогою опції -o.

kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)

Приклади

# Переглянути анотації last-applied-configuration за типом/імʼям у форматі YAML
kubectl apply view-last-applied deployment/nginx

# Переглянути анотації last-applied-configuration за файлом у форматі JSON
kubectl apply view-last-applied -f deploy.yaml -o json

Параметри

--all

Вибрати всі ресурси у просторі імен вказаних типів ресурсів.

kubectl auth can-i

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Перевіряє, чи дозволена дія.

VERB — дієслово API Kubernetes, таке як 'get', 'list', 'watch', 'delete' тощо. TYPE — це ресурс Kubernetes. Скорочення та групи будуть розпізнані. NONRESOURCEURL — часткова URL-адреса, яка починається з "/". NAME — назва певного ресурсу Kubernetes. Ця команда чудово поєднується з імпровізацією. Дивіться глобальний прапорець --as.

kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]

Приклади

# Перевірити, чи можу я створювати Podʼи в будь-якому просторі імен
kubectl auth can-i create pods --all-namespaces

# Перевірити, чи можу я переглядати списки deployment у моєму поточному просторі імен
kubectl auth can-i list deployments.apps

# Перевірити, чи може служюовий обліковий запис "foo" у просторі імен "dev" переглядати перелік Podʼів
# у просторі імен "prod"
# Ви повинні мати дозвіл на використання імперсонації для глобальної опції "--as"
kubectl auth can-i list pods --as=system:serviceaccount:dev:foo -n prod

# Перевірити, чи можу я виконувати всі дії в моєму поточному просторі імен ("*" означає все)
kubectl auth can-i '*' '*'

# Перевірити, чи можу я отримати завдання з назвою "bar" у просторі імен "foo"
kubectl auth can-i list jobs.batch/bar -n foo

# Перевірити, чи можу я читати логи Podʼів
kubectl auth can-i get pods --subresource=log

# Перевірити, чи можу я отримати доступ до URL /logs/
kubectl auth can-i get /logs/

# Перевірити, чи можу я затвердити certificates.k8s.io
kubectl auth can-i approve certificates.k8s.io

# Переглянути всі дозволені дії в просторі імен "foo"
kubectl auth can-i --list --namespace=foo

Параметри

-A, --all-namespaces

Якщо true, перевірити вказану дію в усіх просторах імен.

kubectl auth reconcile

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Узгодження правил для ролі RBAC, привʼязки ролі, ролі кластера та обʼєктів привʼязки ролі кластера.

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

Наявні ролі буде оновлено з урахуванням дозволів вхідних обʼєктів і вилучено зайві дозволи, якщо вказано --remove-extra-permissions.

Існуючі привʼязки буде оновлено до обʼєктів вхідних даних і вилучено зайві обʼєкти, якщо вказано --remove-extra-subjects.

Це бажано застосовувати для ресурсів RBAC, щоб забезпечити семантично усвідомлене обʼєднання правил і обʼєктів.

kubectl auth whoami

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Експериментально: Перевірте, хто ви і які у вас атрибути (групи, додаткові).

Ця команда корисна для ознайомлення з поточними атрибутами користувача, особливо якщо у кластері Kubernacle увімкнено динамічну автентифікацію, наприклад, вебхук, проксі-авторизацію або OIDC-провайдер, увімкнено в кластері Kubernetes.

kubectl auth whoami

Приклади

# Отримати атрибути вашого субʼєкта
kubectl auth whoami

# Отримати атрибути вашого субʼєкта у форматі JSON
kubectl auth whoami -o json

Параметри

--allow-missing-template-keys Типово: true

kubectl certificate approve

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Схвалення запиту на підписання сертифіката.

kubectl certificate approve дозволяє адміністратору кластера затвердити запит на підписання сертифіката (CSR). Ця дія вказує контролеру підпису сертифікатів видати сертифікат запитувачу з атрибутами, вказаними у CSR.

ЗАСТЕРЕЖЕННЯ: Залежно від запитуваних атрибутів, виданий сертифікат потенційно може надати заявнику доступ до ресурсів кластера або автентифікацію в якості запитуваного облікового запису. Перш ніж затверджувати CSR, переконайтеся, що ви розумієте, що може робити підписаний сертифікат.

kubectl certificate approve (-f FILENAME | NAME)

Приклади

# Схвалити CSR 'csr-sqgzp'
kubectl certificate approve csr-sqgzp

Параметри

--allow-missing-template-keys Типово: true

kubectl certificate deny

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Відхилення запиту на підписання сертифіката.

kubectl certificate deny дозволяє адміністратору кластера відхилити запит на підписання сертифіката (CSR). Ця дія вказує контролеру підписання сертифікатів не видавати сертифікат запитувачу.

kubectl certificate deny (-f FILENAME | NAME)

Приклади

# Відхилити CSR 'csr-sqgzp'
kubectl certificate deny csr-sqgzp

Параметри

--allow-missing-template-keys Типово: true

kubectl cluster-info dump

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Виведення інформації про кластер, придатної для налагодження та діагностики проблем кластера. Стандартно все виводиться до stdout. За бажанням ви можете вказати теку за допомогою --output-directory. Якщо ви вкажете теку, Kubernetes створить набір файлів у цій теці. Типово команда виводить дані лише у поточному просторі імен та просторі імен "kube-system", але ви можете перемикнутися на інший простір імен за допомогою прапорця --namespaces або вказати --all-namespaces для виводу даних з усіх просторів імен.

kubectl config current-context

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показ поточного контексту.

kubectl config current-context [flags]

Приклади

# Показ поточного контексту
kubectl config current-context

Параметри

-h, --help
	Довідка current-context

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config delete-cluster

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Видалити вказаний кластер з kubeconfig.

kubectl config delete-cluster NAME

Приклади

# Видалити кластер minikube з kubeconfig
kubectl config delete-cluster minikube

-h, --help
	Довідка delete-cluster

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config delete-context

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Видалити вказаний контекст з kubeconfig.

kubectl config delete-context NAME

Приклади

# Видалити контекст для кластера minikube
kubectl config delete-context minikube

Параметри

-h, --help
	Довідка delete-context

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config delete-user

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Видалити вказаного користувача з kubeconfig.

kubectl config delete-user NAME

Приклади

# Видалити користувача minikube
kubectl config delete-user minikube

Параметри

-h, --help
	Довідка delete-user

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config get-clusters

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показати кластери, визначені в kubeconfig.

kubectl config get-clusters [flags]

Приклади

# Вивести перелік кластерів, які відомі kubectl
kubectl config get-clusters

Параметри

-h, --help
	Довідка get-clusters

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config get-contexts

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показати один або декілька контекстів з файлу kubeconfig.

kubectl config get-contexts [(-o|--output=)name)]

Приклади

# Показати перелік всіх контекстів з файлу kubeconfig
kubectl config get-contexts

# Показати опис одного контексту з файлу kubeconfig
kubectl config get-contexts my-context

Параметри

-h, --help

Довідка get-contexts

--no-headers

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

-o, --output string

Формат виводу. Один з: (name).

kubectl config get-users

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показує користувачів, визначених у kubeconfig.

kubectl config get-users [flags]

Приклади

# Перелік користувачів, відомих kubectl
kubectl config get-users

Параметри

-h, --help
	Довідка get-users

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config rename-context

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Перейменовує контекст з файлу kubeconfig.

CONTEXT_NAME — назва контексту, яку ви хочете змінити.

NEW_NAME — нова назва, яку ви хочете встановити.

Примітка: Якщо контекст, який перейменовується, є "поточним контекстом", це поле також буде оновлено.

kubectl config rename-context CONTEXT_NAME NEW_NAME

Приклади

# Перейменуйте контекст 'old-name' на 'new-name' у вашому файлі kubeconfig
kubectl config rename-context old-name new-name

Параметри

-h, --help
	Довідка rename-context

Успадковані батьківські параметри

--as string

kubectl config set

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановлює індивідуальне значення у файлі kubeconfig.

PROPERTY_NAME — це імʼя, розділене крапками, де кожен токен представляє або імʼя атрибута, або ключ map. Ключі map можуть не містити крапок.

PROPERTY_VALUE — нове значення, яке ви хочете встановити. Двійкові поля, такі як 'certificate-authority-data', очікують рядок у кодуванні base64, якщо не використовується прапорець --set-raw-bytes.

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

kubectl config set PROPERTY_NAME PROPERTY_VALUE

Приклади

# Встановити поле server для кластера my-cluster на https://1.2.3.4
kubectl config set clusters.my-cluster.server https://1.2.3.4

# Встановити поле certificate-authority-data для кластера my-cluster
kubectl config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

# Встановити поле cluster в контексті my-context на my-cluster
kubectl config set contexts.my-context.cluster my-cluster

# Встановити поле client-key-data для користувача cluster-admin з використанням опції --set-raw-bytes
kubectl config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

Параметри

-h, --help

Довідка set

kubectl config set-cluster

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановлює запис кластера у kubeconfig.

Якщо вказати назву, яка вже існує, нові поля буде обʼєднано з наявними значеннями для цих полів.

kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true] [--tls-server-name=example.com]

Приклади

# Встановити тільки поле server для запису кластера e2e без змін інших значень
kubectl config set-cluster e2e --server=https://1.2.3.4

# Вбудувати дані CA для запису кластера e2e
kubectl config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

# Вимкнути перевірку сертифікатів для запису кластера e2e
kubectl config set-cluster e2e --insecure-skip-tls-verify=true

# Встановити власне імʼя сервера TLS для перевірки для запису кластера e2e
kubectl config set-cluster e2e --tls-server-name=my-cluster-name

# Встановити URL проксі для запису кластера e2e
kubectl config set-cluster e2e --proxy-url=https://1.2.3.4

Параметри

--certificate-authority string

Шлях до файлу сертифіката для центра сертифікації

kubectl config set-context

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановлює запис контексту у kubeconfig.

Якщо вказати назву, яка вже існує, нові поля буде обʼєднано з наявними значеннями для цих полів.

kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

Приклади

# Встановіть поле користувача у записі контексту gce, не змінюючи інших значень
kubectl config set-context gce --user=cluster-admin

Параметри

--cluster string

cluster для запису контексту в kubeconfig

--current

Змінити поточний контекст

-h, --help

Довідка set-context

kubectl config set-credentials

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Задайте запис user у kubeconfig.

Якщо вказати імʼя, яке вже існує, нові поля буде обʼєднано з наявними значеннями.

Прапорці клієнтського сертифіката:: --client-certificate=certfile --client-key=keyfile
Прапорці токенів на предʼявника:: --token=bearer_token
Базові прапорці авторизації:: --username=базовий_користувач --password=базовий_пароль

Токен на предʼявника та базова авторизація є взаємозаперечними.

kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value]

Приклади

# Встановити тільки поле "client-key" для запису "cluster-admin"
# без змін інших значень
kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key

# Встановити базову автентифікацію для запису "cluster-admin"
kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

# Вбудувати дані сертифіката клієнта для запису "cluster-admin"
kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

# Увімкнути провайдера автентифікації Google Compute Platform для запису "cluster-admin"
kubectl config set-credentials cluster-admin --auth-provider=gcp

# Увімкнути провайдера автентифікації OpenID Connect для запису "cluster-admin" з додатковими аргументами
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

# Видалити значення конфігурації "client-secret" для провайдера автентифікації OpenID Connect для запису "cluster-admin"
kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

# Увімкнути новий втулок автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

# Увімкнути новий втулок автентифікації exec для запису "cluster-admin" з інтерактивним режимом
kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1 --exec-interactive-mode=Never

# Визначити нові аргументи для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

# Створити або оновити змінні середовища для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

# Видалити змінні середовища для втулка автентифікації exec для запису "cluster-admin"
kubectl config set-credentials cluster-admin --exec-env=var-to-remove-

Параметри

--auth-provider string

Провайдер авторизації/автентифікації для запису користувача у kubeconfig

kubectl config unset

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Скинути окреме значення у файлі kubeconfig.

kubectl config unset PROPERTY_NAME

Приклади

# Видалити поточний контекст
kubectl config unset current-context

# Видалити простір імен у контексті foo
kubectl config unset contexts.foo.namespace

Параметри

-h, --help
	Довідка unset

Успадковані батьківські параметри

--as string

kubectl config use-context

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановлює current-context у файлі kubeconfig.

kubectl config use-context CONTEXT_NAME

Приклади

# Використання контексту для кластера minikube
kubectl config use-context minikube

Параметри

-h, --help
	Довідка use-context

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl config view

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показує обʼєднану конфігурацію kubeconfig або вказаний файл kubeconfig.

Ви можете використовувати --output jsonpath={...} для вибору конкретних полів конфігурації.

kubectl config view [options]

Приклади

# Показати обʼєднані налаштування kubeconfig
kubectl config view

# Показати обʼєднані налаштування kubeconfig, необроблені дані сертифіката та показати секрети
kubectl config view --raw

# Отримати пароль для користувача e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

Параметри

--allow-missing-template-keys Типово: true

kubectl create clusterrole

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення кластерної ролі.

kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run=server|client|none]

Приклади

# Створити кластерну роль з назвою "pod-reader", яка дозволяє користувачу виконувати "get", "watch" та "list" для Podʼів
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

# Створити кластерну роль з назвою "pod-reader" із вказаними іменами ресурсів
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# Створити кластерну роль з назвою "foo" із вказаною API Group
kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps

# Створити кластерну роль з назвою "foo" із вказаним субресурсом
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

# Створити кластерну роль з назвою "foo" із вказаним NonResourceURL
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

# Створити кластерну роль з назвою "monitoring" із вказаним правилом агрегації
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

Параметри

--aggregation-rule <пари 'ключ=значення', розділені комами>

Селектор міток агрегації для обʼєднання ClusterRoles.

kubectl create clusterrolebinding

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення привʼязки кластерної ролі для певної кластерної ролі.

kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Створити привʼязування кластерної ролі для user1, user2 та group1, використовуючи кластерну роль cluster-admin
kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

Параметри

--allow-missing-template-keys Типово: true

kubectl create configmap

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створює ConfigMap на основі файлу, теки або вказаного літерального значення.

Один ConfigMap може містити одну або декілька пар ключ/значення.

При створенні ConfigMap на основі файлу, стандартним значенням ключа буде імʼя файлу, а значенням — його вміст. Якщо назва файлу є невірним ключем, ви можете вказати альтернативний ключ.

При створенні ConfigMap на основі теки кожен файл, назва якого є допустимим ключем у теці, буде запаковано до ConfigMap. Будь-які записи у теці, окрім звичайних файлів, ігноруються (наприклад, субтеки, символічні посилання, пристрої, канали й т.д.).

kubectl create cronjob

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створіть завдання cron із зазначеним імʼям.

kubectl create cronjob NAME --image=image --schedule='0/5 * * * ?' -- [COMMAND] [args...] [flags]

Приклади

# Створити крон-завдання
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *"

# Створити крон-завдання з командою
kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

Параметри

--allow-missing-template-keys Типово: true

kubectl create deployment

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створює deployment із зазначеним іменем.

kubectl create deployment NAME --image=image -- [COMMAND] [args...]

Приклади

# Створити deployment з назвою my-dep, що використовує образ busybox
kubectl create deployment my-dep --image=busybox

# Створити deployment з командою
kubectl create deployment my-dep --image=busybox -- date

# Створити deployment з назвою my-dep, що використовує образ nginx з 3 репліками
kubectl create deployment my-dep --image=nginx --replicas=3

# Створити deployment з назвою my-dep, що використовує образ busybox і відкриває порт 5701
kubectl create deployment my-dep --image=busybox --port=5701

# Створити deployment з назвою my-dep, що містить декілька контейнерів
kubectl create deployment my-dep --image=busybox:latest --image=ubuntu:latest --image=nginx

Параметри

--allow-missing-template-keys Типово: true

kubectl create ingress

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створює ingress із зазначеною назвою.

kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]

Приклади

# Створити один ingress з назвою 'simple', який направляє запити з foo.com/bar на svc1:8080 з TLS-сертифікатом "my-cert"
kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

# Створити ingress, який захоплює усі шляхи "/path" і направляє їх на сервіс svc:port з класом ingress "otheringress"
kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port"

# Створити ingress з двома анотаціями: ingress.annotation1 і ingress.annotations2
kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" \
--annotation ingress.annotation1=foo \
--annotation ingress.annotation2=bla

# Створити ingress з тим же хостом і декількома шляхами
kubectl create ingress multipath --class=default \
--rule="foo.com/=svc:port" \
--rule="foo.com/admin/=svcadmin:portadmin"

# Створити ingress з декількома хостами і типом шляху як Prefix
kubectl create ingress ingress1 --class=default \
--rule="foo.com/path*=svc:8080" \
--rule="bar.com/admin*=svc2:http"

# Створити ingress з увімкненим TLS, використовуючи стандартний сертифікат ingress і різними типами шляхів
kubectl create ingress ingtls --class=default \
--rule="foo.com/=svc:https,tls" \
--rule="foo.com/path/subpath*=othersvc:8080"

# Створити ingress з увімкненим TLS, використовуючи конкретний секрет і типом шляху як Prefix
kubectl create ingress ingsecret --class=default \
--rule="foo.com/*=svc:8080,tls=secret1"

# Створити ingress зі стандартним бекендом
kubectl create ingress ingdefault --class=default \
--default-backend=defaultsvc:http \
--rule="foo.com/*=svc:8080,tls=secret1"

Параметри

--allow-missing-template-keys Типово: true

kubectl create job

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створює job з вказаним іменем.

kubectl create job NAME --image=image [--from=cronjob/name] -- [COMMAND] [args...]

Приклади

# Створити задачу (job)
kubectl create job my-job --image=busybox

# Створити задачу з командою
kubectl create job my-job --image=busybox -- date

# Створити задачу на основі крон-завдання з назвою "a-cronjob"
kubectl create job test-job --from=cronjob/a-cronjob

Параметри

--allow-missing-template-keys Типово: true

kubectl create namespace

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створює простір імен з вказаним іменем.

kubectl create namespace NAME [--dry-run=server|client|none]

Приклади

# Створити простір імен з іменем my-namespace
kubectl create namespace my-namespace

Параметри

--allow-missing-template-keys Типово: true

--dry-run string[="unchanged"] Типово: "none"

Має бути "none", "server" або "client". Якщо це стратегія client, вивести лише обʼєкт, який міг би бути надісланим, не надсилаючи його. Якщо це стратегія server, надіслати запит на стороні сервера без збереження ресурсу.

kubectl create poddisruptionbudget

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створіть бюджет розладу роботи Podʼів із зазначеною назвою, селектором і бажаним мінімумом доступних Podʼів.

kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none]

Приклади

# Створити бюджет розладу роботи Podʼів з назвою "my-pdb",
# який вибере всі Podʼи з міткою app=rails і вимагатиме, щоб принаймні один з них був доступний в будь-який момент
kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

# Створити бюджет розладу роботи Podʼів з назвою "my-pdb",
# який вибере всі Podʼи з міткою app=nginx і вимагатиме, щоб принаймні половина вибраних Podʼів була доступна в будь-який момент
kubectl create pdb my-pdb --selector=app=nginx --min-available=50%

Параметри

--allow-missing-template-keys Типово: true

kubectl create priorityclass

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створює клас пріоритету з вказаним імʼям, значенням, globalDefault та описом.

kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none]

Приклади

# Створити клас пріоритету з назвою high-priority
kubectl create priorityclass high-priority --value=1000 --description="high priority"

# Створити клас пріоритету з назвою default-priority, який вважається глобальним стандартним класом пріоритету
kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority"

# Створити клас пріоритету з назвою high-priority, який не може випереджувати Podʼи з нижчим пріоритетом
kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

Параметри

--allow-missing-template-keys Типово: true

kubectl create quota

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення квоти ресурсів із зазначеною назвою, жорсткими обмеженнями та необовʼязковими діапазонами.

kubectl create quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=server|client|none]

Приклади

# Створити нову квоту ресурсів з назвою my-quota
kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10

# Створити нову квоту ресурсів з назвою best-effort
kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort

Параметри

--allow-missing-template-keys Типово: true

kubectl create role

Mon, 01 Jan 0001 00:00:00 +0000

Створює роль з одним правилом.

kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none]

Приклади

# Створити роль з назвою "pod-reader", яка дозволяє користувачу виконувати "get", "watch" і "list" для Podʼів
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

# Створити роль з назвою "pod-reader" з вказаними ResourceName
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

# Створити роль з назвою "foo" з вказаною API Group
kubectl create role foo --verb=get,list,watch --resource=rs.apps

# Створити роль з назвою "foo" з вказаним SubResource
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

Параметри

--allow-missing-template-keys Типово: true

kubectl create rolebinding

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення привʼязки для певної ролі або кластерної ролі.

kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Створити привʼязки ролей для user1, user2 та group1, використовуючи роль admin
kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1

# Створити привʼязки ролей для serviceaccount monitoring:sa-dev, використовуючи роль admin
kubectl create rolebinding admin-binding --role=admin --serviceaccount=monitoring:sa-dev

Параметри

--allow-missing-template-keys Типово: true

kubectl create secret

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення секрету з вказаним типом.

Секрет типу docker-registry призначений для доступу до реєстру контейнера.

Тип секрету generic вказує на Opaque тип секрету.

Секрет типу tls містить TLS-сертифікат і повʼязаний з ним ключ.

kubectl create secret (docker-registry | generic | tls)

Параметри

-h, --help
	Довідка secret

Успадковані батьківські параметри

--as string

kubectl create secret docker-registry

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення нового секрету для використання з реєстрами Docker.

Секрети Dockercfg використовуються для автентифікації у реєстрах Docker.

При використанні командного рядка Docker для надсилання образів, ви можете автентифікуватися в заданому реєстрі за допомогою запуску команди:

$ docker login DOCKER_REGISTRY_SERVER --username=DOCKER_USER --password=DOCKER_PASSWORD --email=DOCKER_EMAIL.

В результаті буде створено файл ~/.dockercfg, який використовується наступними командами docker push і docker pull для автентифікації в реєстрі. Адреса електронної пошти не є обовʼязковою.

При створенні програм може виникнути ситуація, коли реєстр Docker вимагає автентифікації. Для того, щоб вузли вузли могли отримувати образи від вашого імені, вони повинні мати облікові дані. Ви можете надати цю інформацію створивши секрет dockercfg і прикріпивши його до свого службового облікового запису.

kubectl create secret generic

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення секрету на основі файлу, теки або вказаного літерального значення.

Один секрет може містити одну або декілька пар ключ/значення.

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

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

kubectl create secret tls

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення TLS-секрету із заданої пари публічного/приватного ключа.

Пара відкритий/закритий ключ повинна існувати заздалегідь. Сертифікат відкритого ключа повинен бути зашифрований у форматі .PEM і відповідати заданому закритому ключу.

kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]

Приклади

# Створіть новий TLS-секрет з імʼям tls-secret із заданою парою ключів
kubectl create secret tls tls-secret --cert=path/to/tls.crt --key=path/to/tls.key

Параметри

--allow-missing-template-keys Типово: true

kubectl create service

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення сервісу з використанням субкоманд.

kubectl create service [flags]

Параметри

-h, --help
	Довідка service

Успадковані батьківські параметри

--as string

--as-group strings

Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп.

kubectl create service clusterip

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення сервісу ClusterIP із зазначеним імʼям.

kubectl create service clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run=server|client|none]

Приклади

# Створити новий сервіс ClusterIP з назвою my-cs
kubectl create service clusterip my-cs --tcp=5678:8080

# Створити новий сервіс ClusterIP з назвою my-cs (у режимі headless)
kubectl create service clusterip my-cs --clusterip="None"

Параметри

--allow-missing-template-keys Типово: true

kubectl create service externalname

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення сервісу ExternalName із зазначеним імʼям.

Сервіс ExternalName посилається на зовнішню DNS-адресу, а не лише на Podʼи, що дозволить авторам застосунків посилатися на сервіси, які існують за межами платформи, в інших кластерах або локально.

kubectl create service externalname NAME --external-name external.name [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс ExternalName з іменем my-ns
kubectl create service externalname my-ns --external-name bar.com

Параметри

--allow-missing-template-keys Типово: true

kubectl create service loadbalancer

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення сервісу LoadBalancer з вказаним імʼям.

kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс LoadBalancer з назвою my-lbs
kubectl create service loadbalancer my-lbs --tcp=5678:8080

Параметри

--allow-missing-template-keys Типово: true

--dry-run string[="unchanged"] Типово: "none"

kubectl create service nodeport

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення сервісу NodePort з вказаним імʼям.

kubectl create service nodeport NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Приклади

# Створіть новий сервіс NodePort з назвою my-ns
kubectl create service nodeport my-ns --tcp=5678:8080

Параметри

--allow-missing-template-keys Типово: true

--dry-run string[="unchanged"] Типово: "none"

kubectl create serviceaccount

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Створення службового облікового запису з вказаним імʼям.

kubectl create serviceaccount NAME [--dry-run=server|client|none]

Приклади

# Створіть новий служюовий обліковий записк з назвою my-service-account
kubectl create serviceaccount my-service-account

Параметри

--allow-missing-template-keys Типово: true

--dry-run string[="unchanged"] Типово: "none"

kubectl create token

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

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

kubectl create token SERVICE_ACCOUNT_NAME

Приклади

# Запит токена для автентифікації на kube-apiserver як службовий обліковий запис "myapp" у поточному просторі імен
kubectl create token myapp

# Запит токена для службового облікового запису у власному просторі імен
kubectl create token myapp --namespace myns

# Запит токена із власним часом дії
kubectl create token myapp --duration 10m

# Запит токена із власною аудиторією
kubectl create token myapp --audience https://example.com

# Запит токена, привʼязаного до обʼєкта типу Secret
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret

# Запит токена, привʼязаного до обʼєкта типу Secret з конкретним UID
kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid 0d4691ed-659b-4935-a832-355f77ee47cc

Параметри

--allow-missing-template-keys Типово: true

kubectl plugin list

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показати всі доступні файли втулків у PATH користувача. Для виводу тільки назв двійкових файлів використовуйте прапорець --name-only.

Доступними вважаються файли втулків, які є:

виконуваними
будь-де в PATH користувача
починаються з "kubectl-"

kubectl plugin list [flags]

Приклади

# Вивести перелік всіх доступних втулків
kubectl plugin list

# Вивести перелік назв двійкових файлів доступних втулків без шляхів
kubectl plugin list --name-only

Параметри

-h, --help

Довідка list

kubectl rollout history

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Переглянути попередні версії та конфігурації розгортання.

kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]

Приклади

# Переглянути історію розгортання deployment
kubectl rollout history deployment/abc

# Переглянути деталі daemonset ревізії 3
kubectl rollout history daemonset/abc --revision=3

Параметри

--allow-missing-template-keys Типово: true

-f, --filename strings

Імʼя файлу, теки або URL до файлів, що ідентифікують ресурс, який потрібно отримати з сервера.

kubectl rollout pause

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Позначає вказані ресурси як призупинені.

Призупинені ресурси не будуть узгоджуватися контролером. Щоб відновити роботу призупиненого ресурсу, скористайтеся "kubectl rollout resume". Наразі призупинення підтримується лише у deployment.

kubectl rollout pause RESOURCE

Приклади

# Позначити deployment nginx як призупинений
# Будь-який поточний стан deployment продовжить свою роботу; нові оновлення
# deployment не матимуть ефекту, доки deployment призупинено
kubectl rollout pause deployment/nginx

Параметри

--allow-missing-template-keys Типово: true

kubectl rollout restart

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Перезапускає ресурс.

Розгортання ресурсів буде перезапущено.

kubectl rollout restart RESOURCE

Приклади

# Перезапустити всі deployment у просторі імен test-namespace
kubectl rollout restart deployment -n test-namespace

# Перезапустіть deployment
kubectl rollout restart deployment/nginx

# Перезапустити набір демонів
kubectl rollout restart daemonset/abc

# Перезапустити deployment з міткою app=nginx
kubectl rollout restart deployment --selector=app=nginx

Параметри

--allow-missing-template-keys Типово: true

kubectl rollout resume

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Відновити роботу призупиненого ресурсу.

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

kubectl rollout resume RESOURCE

Приклади

# Відновити роботу призупиненого deployment
kubectl rollout resume deployment/nginx

Параметри

--allow-missing-template-keys Типово: true

kubectl rollout status

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показувати статус розгортання.

Стандартно "rollout status" буде стежити за статусом останнього розгортання, доки воно не завершиться. Якщо ви не бажаєте чекати на завершення розгортання, ви можете використати --watch=false. Зауважте, що якщо у проміжку між ними розпочнеться нове розгортання, то "rollout status" продовжуватиме стежити за останньою ревізією. Якщо ви хочете привʼязатися до певної ревізії і перервати процес, якщо його буде перенесено на іншу ревізію, скористайтеся --revision=N, де N — ревізія, за якою ви хочете стежити.

kubectl rollout undo

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Повернення до попереднього розгортання.

kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags]

# Відкотитися до попередньої версії deployment
kubectl rollout undo deployment/abc

# Відкотитися до ревізії 3 daemonset
kubectl rollout undo daemonset/abc --to-revision=3

# Перевірити відкат до попередньої версії за допомогою dry-run
kubectl rollout undo --dry-run=server deployment/abc

Параметри

--allow-missing-template-keys Типово: true

kubectl set env

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Оновити змінні середовища у шаблоні Pod.

Вивести перелік визначення змінних середовища в одному або декількох Pod, шаблонах Pod. Додати, оновити або видалити визначення змінних середовища контейнера в одному або декількох шаблонах Pod (в рамках контролерів реплікації або конфігурацій deployment). Переглянути або змінити визначення змінних середовища у всіх контейнерах у вказаних Pod або шаблонах Pod, або тільки тих, що відповідають шаблону.

Якщо передано "--env -", змінні середовища можуть бути прочитані зі STDIN за допомогою стандартного синтаксису env.

kubectl set image

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Оновити наявні образи контейнерів ресурсів.

Можливі ресурси включають (не чутливі до регістру):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N

Приклади

# Встановити образ контейнера nginx в deployment як 'nginx:1.9.1', а образ контейнера busybox на 'busybox'
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1

# Оновити образ контейнера nginx у всіх deployment та контролерах реплікації на 'nginx:1.9.1'
kubectl set image deployments,rc nginx=nginx:1.9.1 --all

# Оновити образи всіх контейнерів у daemonset abc на 'nginx:1.9.1'
kubectl set image daemonset abc *=nginx:1.9.1

# Вивести результат (у форматі yaml) оновлення образу контейнера nginx з локального файлу, без звернення до сервера
kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

kubectl set resources

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Вказує вимоги до обчислювальних ресурсів (ЦП, памʼять) для будь-якого ресурсу, який визначає шаблон pod. Якщо pod успішно заплановано, йому гарантовано надається запитана кількість ресурсів, які він може використовувати до зазначених меж.

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

Можливі ресурси включають (незалежно від регістру): Використовуйте "kubectl api-resources" для повного списку підтримуваних ресурсів.

kubectl set resources (-f FILENAME | TYPE NAME) ([--limits=LIMITS & --requests=REQUESTS]

Приклади

# Встановити межі використання ЦП для контейнера nginx у deployment на "200m" та памʼяті на "512Mi"
kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi

# Встановити запити та межі ресурсів для всіх контейнерів у deployment nginx
kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

# Видалити запити ресурсів для контейнерів у deployment nginx
kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

# Вивести результат (у форматі yaml) оновлення меж використання ресурсів для контейнера nginx з локального файлу, без звернення до сервера
kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

kubectl set selector

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Встановити селектор на ресурс. Зауважте, що новий селектор замінить старий, якщо ресурс вже мав селектор перед викликом команди 'set selector'.

Селектор повинен починатися з літери або цифри та може містити літери, цифри, дефіси, крапки та підкреслення, до 63 символів. Якщо вказано --resource-version, оновлення використовуватимуть цю версію ресурсу, інакше використовуватиметься наявна версія ресурсу. Примітка: зараз селектори можна встановлювати лише на обʼєкти типу Service.

kubectl set selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]

Приклади

# Встановіть мітки і селектор перед створенням пари deployment/service
kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -

kubectl create deployment my-dep --image=nginx -o yaml --dry-run=client | kubectl label --local -f - environment=qa -o yaml | kubectl create -f -

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

kubectl set serviceaccount

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Оновлення службового облікового запису ресурсів шаблону pod.

Можливі ресурси (нечутливі до регістру) можуть бути такими:

replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset

kubectl set serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT

Приклади

# Встановити службовий обліковий запис nginx-deployment у serviceaccount1
kubectl set serviceaccount deployment nginx-deployment serviceaccount1

# Вивести результат (у форматі YAML) оновленого deployment nginx з службовим обліковим записом з локального файлу, не звертаючись до сервера API
kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run=client -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

kubectl set subject

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Оновлює user, group або service account в обʼєкті RoleBinding або ClusterRoleBinding.

kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Приклади

# Оновлення привʼязки кластерних ролей для serviceaccount1
kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1

# Оновлення привʼязки ролей для user1, user2 і group1
kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1

# Вивести результат (у форматі YAML) оновлення субʼєктів привʼязки ролей локально, без звернення до сервера
kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml

Параметри

--all

Якщо true, вибрати всі ресурси в просторі імен вказаних типів ресурсів

kubectl top node

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показати використання ресурсів (процесор/памʼять) вузлами.

Команда top-node дозволяє переглядати використання ресурсів вузлами кластера.

kubectl top node [NAME | -l label]

Приклади

# Показати метріки для всіх вузлівShow metrics for all nodes
kubectl top node

# Показати метріки для вузла NODE_NAME
kubectl top node NODE_NAME

Параметри

-h, --help

Довідка node

--no-headers

Якщо присутній, то виводити без заголовків.

-l, --selector string

Селектор (запит на мітки) для фільтрації, що підтримує '=', '==', '!=', 'in', 'notin' (наприклад, -l key1=value1,key2=value2,key3 in (value3)). Обʼєкти, щоб мати збіг, повинні задовольняти усім зазначеним обмеженням міток.

kubectl top pod

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Показувати використання ресурсів (процесора/памʼять) pod'ами

Команда 'top pod' дозволяє вам переглядати використання ресурсів (процесора/памʼяті) podʼами.

Через затримку конвеєра метрик, вони можуть бути недоступні протягом декількох хвилин з моменту створення podʼів.

kubectl top pod [NAME | -l label]

Приклади

# Показати метрики для всіх podʼів у стандартному просторі імен
kubectl top pod

# Показати метрики для всіх podʼів у вказаному просторі імен
kubectl top pod --namespace=NAMESPACE

# Показати метрики для вказаного podʼа та його контейнерів
kubectl top pod POD_NAME --containers

# Показати метрики для podʼів, визначених міткою name=myLabel
kubectl top pod -l name=myLabel

Параметри

-A, --all-namespaces

Якщо вказано, вивести перелік запитуваних обʼєктів у всіх просторах назв. Простір назв у поточному контексті ігнорується, навіть якщо вказано --namespace.

kubelet

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

Kubelet є основним "агентом вузла", який працює на кожному вузлі. Він може зареєструвати вузол на apiserver, використовуючи одне з наступного: імʼя хосту; прапорець для перевизначення імені хоста; або спеціальну логіку для провайдера хмарних послуг.

Kubelet працює в термінах PodSpec. PodSpe — це обʼєкт YAML або JSON, який описує Pod. Kubelet приймає набір PodSpec, які надаються різними механізмами (переважно через apiserver) і забезпечує, що контейнери, описані в цих PodSpec, працюють і є справними. Kubelet не управляє контейнерами, які не були створені Kubernetes.

Secrets

Mon, 01 Jan 0001 00:00:00 +0000

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

StatefulSets

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Авторизація

Mon, 01 Jan 0001 00:00:00 +0000

Авторизація в Kubernetes відбувається після автентифікації. Зазвичай клієнт, що робить запит, має бути автентифікований (увійти в систему), перш ніж його запит може бути дозволений; однак, Kubernetes також дозволяє анонімні запити за деяких обставин.

Для огляду того, як авторизація вписується в ширший контекст контролю доступу до API, читайте Контроль доступу до Kubernetes API.

Вердикти авторизації

Авторизація запитів до API в Kubernetes відбувається всередині API-сервера. API-сервер оцінює всі атрибути запиту щодо всіх політик, потенційно також звертаючись до зовнішніх сервісів, і потім дозволяє або відхиляє запит.

Бібліотеки клієнтів

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить огляд бібліотек клієнтів для використання Kubernetes API різними мовами програмування.

Для написання застосунків, що використовують Kubernetes REST API, вам не потрібно самостійно реалізовувати виклики API та типи запитів/відповідей. Ви можете використовувати бібліотеку клієнтів для мови програмування, яку ви використовуєте.

Бібліотеки клієнтів часто виконують загальні завдання, такі як автентифікація. Більшість бібліотек клієнтів можуть знаходити та використовувати Kubernetes Service Account для автентифікації, якщо API клієнт працює всередині кластера Kubernetes, або можуть розуміти формат kubeconfig файлу для читання облікових даних та адреси API сервера.

Версії у CustomResourceDefinitions

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Використання Cilium для NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати Cilium для NetworkPolicy.

Щоб ознайомитися з основною інформацією про Cilium, прочитайте Вступ до Cilium.

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

Використання змінних середовища для передачі контейнерам інформації про Pod

Mon, 01 Jan 0001 00:00:00 +0000

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

У Kubernetes є два способи експозиції полів Pod та контейнера для запущеного контейнера:

Змінні середовища, як пояснено в цьому завданні
Файли томів

Разом ці два способи експозиції полів Pod та контейнера називаються downward API.

Генерація сертифікатів вручну

Mon, 01 Jan 0001 00:00:00 +0000

При використанні автентифікації сертифіката клієнта ви можете генерувати сертифікати вручну за допомогою easyrsa, openssl або cfssl.

easyrsa

З easyrsa ви можете вручну генерувати сертифікати для вашого кластера.

Завантажте, розпакуйте та ініціалізуйте патчену версію easyrsa3.

curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz
tar xzf easy-rsa.tar.gz
cd easy-rsa-master/easyrsa3
./easyrsa init-pki

Згенеруйте новий центр сертифікації (CA). --batch встановлює автоматичний режим; --req-cn вказує загальну назву (CN, Common Name) для нового кореневого сертифіката CA.
```
./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
```
Згенеруйте сертифікат та ключ сервера.

Ефемерні томи

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ описує ефемерні томи в Kubernetes. Рекомендується мати знайомство з томами, зокрема з PersistentVolumeClaim та PersistentVolume.

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

Інші застосунки очікують, що деякі дані тільки-для-читання будуть присутні в файлах, таких як конфігураційні дані або секретні ключі.

Життєвий цикл Podʼа

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Запуск Podʼів лише на деяких вузлах

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка демонструє, як можна запускати Podʼи лише на деяких вузлах як частину DaemonSet

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

Запуск реплікованого застосунку зі збереженням стану

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як запустити реплікований застосунок зі збереженням стану (StatefulSet). Цей застосунок — реплікована база даних MySQL. У топології цього прикладу є один головний сервер і кілька реплік, що використовують асинхронну реплікацію на основі рядків.

Примітка:

Ця конфігурація не для операційної експлуатації. Налаштування MySQL залишаються на небезпечних стандартних значеннях, щоб зосередитися на загальних патернах запуску застосунків зі збереженням стану в Kubernetes.

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

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

Зміна розміру CPU та memory, призначених контейнерам

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка пояснює як змінити запити та обмеження ресурсів CPU та памʼяті повʼязані з контейнером без перестворення Podʼу.

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

Зміна розміру ресурсів CPU та памʼяті, призначених для Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Функція In-place Pod Resize дозволяє змінювати розподіл ресурсів для запущеного Pod, уникаючи переривання роботи застосунків. Процес зміни розміру окремих ресурсів контейнера описано в розділі Зміна розміру ресурсів CPU та памʼяті, призначених контейнерам.

На цій сторінці описано зміну розміру ресурсів на рівні Pod. Ресурси на рівні Pod визначаються в spec.resources і виступають верхньою межею сукупних ресурсів, що споживаються всіма контейнерами в Podʼі. Функція зміни розміру ресурсів на рівні Podʼа дозволяє безпосередньо змінювати сукупні розподіли ресурсів CPU та памʼяті для запущеного Podʼа.

Керування Secret за допомогою Kustomize

Mon, 01 Jan 0001 00:00:00 +0000

kubectl підтримує використання інструменту керування обʼєктами Kustomize для керування Secret та ConfigMap. Ви можете створити генератор ресурсів за допомогою Kustomize, який створює Secret, який ви можете застосувати до сервера API за допомогою kubectl.

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

Керування обʼєктами Kubernetes за допомогою імперативних команд

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Встановіть kubectl.

Клас виконання

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка описує ресурс RuntimeClass та механізм вибору середовища виконання.

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

Обґрунтування

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

Контролери

Mon, 01 Jan 0001 00:00:00 +0000

У робототехніці та автоматизації control loop (цикл керування) — це необмежений цикл, який регулює стан системи.

Ось один приклад control loop — термостат у кімнаті.

Коли ви встановлюєте температуру, це означає, що ви повідомляєте термостату про бажаний стан. Фактична температура в кімнаті — це поточний стан. Термостат діє так, щоб наблизити поточний стан до бажаного стану, вмикаючи чи вимикаючи відповідне обладнання.

У Kubernetes контролери — це цикли управління, які спостерігають за станом вашого , а потім вносять або запитують зміни там, де це необхідно. Кожен контролер намагається наблизити поточний стан кластера до бажаного.

Шаблон контролер

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

Конфігурування Redis за допомогою ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає реальний приклад конфігурування Redis за допомогою ConfigMap і базується на завданні Конфігурування Pod для використання ConfigMap.

Цілі

Створити ConfigMap з конфігураційними значеннями Redis
Створити Pod з Redis, який монтує та використовує створений ConfigMap
Перевірити, що конфігурація була правильно застосована.

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

Лізинг

Mon, 01 Jan 0001 00:00:00 +0000

Часто в розподілених системах є потреба в лізингу, яка забезпечує механізм блокування спільних ресурсів та координації дій між членами групи. В Kubernetes концепцію лізингу представлено обʼєктами Lease в API Group coordination.k8s.io, які використовуються для критичних для системи можливостей, таких як час роботи вузлів та вибір лідера на рівні компонентів.

Час роботи вузлів

Kubernetes використовує API Lease для звʼязку з пульсом kubelet вузла з API сервером Kubernetes. Для кожного Node існує обʼєкт Lease з відповідним імʼям в просторі імен kube-node-lease. Під капотом кожен сигнал пульсу kubelet — це запит на оновлення цього обʼєкта Lease, який оновлює поле spec.renewTime для оренди. Панель управління Kubernetes використовує відмітку часу цього поля для визначення доступності цього вузла.

Надання ресурсів CPU та памʼяті на рівні Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Назви та Ідентифікатори Обʼєктів

Mon, 01 Jan 0001 00:00:00 +0000

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

Наприклад, ви можете мати лише один обʼєкт Pod із назвою myapp-1234 в просторі імен з такою ж назвою, а також ви можете мати один обʼєкт Pod та один Deployment із назвами myapp-1234 кожен.

Накладні витрати, повʼязані з роботою Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

Коли ви запускаєте Pod на вузлі, сам Pod потребує певної кількості системних ресурсів. Ці ресурси додаються до ресурсів, необхідних для запуску контейнерів всередині Pod. У Kubernetes Pod Overhead — це спосіб обліку ресурсів, які використовуються інфраструктурою Pod, понад запити та обмеження контейнерів.

У Kubernetes накладні витрати Pod встановлюються під час допуску з урахуванням перевищення, повʼязаного з RuntimeClass Pod.

Накладні витрати Pod вважаються додатковими до суми запитів ресурсів контейнера при плануванні Pod. Так само, kubelet включатиме накладні витрати Pod при визначенні розміру cgroup Podʼа і при виконанні ранжування виселення Podʼа.

Налагодження StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

Ця задача показує, як усувати несправності у StatefulSet.

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

Вам потрібен кластер Kubernetes, та інструмент командного рядка kubectl повинен бути налаштований на звʼязок з вашим кластером.
Ви повинні мати запущений StatefulSet, який ви хочете дослідити.

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

Для того, щоб переглянути всі Podʼи, які належать до StatefulSet і мають мітку app.kubernetes.io/name=MyApp на них, ви можете використовувати наступне:

kubectl get pods -l app.kubernetes.io/name=MyApp

Якщо ви помітили, що будь-які Podʼи вказані у стані Unknown або Terminating протягом тривалого періоду часу, зверніться до завдання Видалення Podʼів StatefulSet за інструкціями щодо дії з ними. Ви можете усувати несправності окремих Podʼів у StatefulSet, використовуючи Посібник з усунення несправностей Podʼів.

Налагодження вузлів Kubernetes за допомогою crictl

Mon, 01 Jan 0001 00:00:00 +0000

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

crictl — це інтерфейс командного рядка для сумісних з CRI контейнерних середовищ. Ви можете використовувати його для огляду та налагодження контейнерних середовищ та застосунків на вузлі Kubernetes. crictl та його вихідний код розміщені у репозиторії cri-tools.

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

Для роботи crictl потрібна операційна система Linux з CRI середовищем.

Встановлення crictl

Ви можете завантажити архів crictl зі сторінки релізів у репозиторії cri-tools release page, для різних архітектур. Завантажте версію, яка відповідає вашій версії Kubernetes. Розпакуйте її та перемістіть у розташування у вашому системному шляху, наприклад, /usr/local/bin/.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка показує, як налаштувати 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.

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

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як налаштувати доступ до декількох кластерів за допомогою конфігураційних файлів. Після того, як ваші кластери, користувачі та контексти визначені в одному або декількох конфігураційних файлах, ви можете швидко перемикатися між кластерами, використовуючи команду kubectl config use-context.

Примітка:

Файл, що використовується для налаштування доступу до кластера, іноді називається kubeconfig файлом. Це загальний спосіб посилання на файли конфігурації. Це не означає, що існує файл з назвою kubeconfig.

Попередження:

Використовуйте kubeconfig файли тільки з надійних джерел. Використання спеціально створеного kubeconfig файлу може призвести до виконання шкідливого коду або витоку файлів. Якщо вам необхідно використовувати ненадійний kubeconfig файл, уважно перевірте його перед використанням, так само як ви б перевіряли shell скрипт.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Обмежте доступ контейнера до ресурсів за допомогою AppArmor

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка показує, як завантажити профілі AppArmor на ваших вузлах та забезпечити їх виконання в Podʼах. Щоб дізнатися більше про те, як Kubernetes може обмежувати Podʼи за допомогою AppArmor, див. Обмеження безпеки ядра Linux для Podʼів та контейнерів.

Цілі

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

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

AppArmor — це необовʼязковий модуль ядра та функція Kubernetes, тому переконайтеся, що він підтримується на ваших вузлах перед продовженням:

Оновлення кластерів з kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює, як оновити кластер Kubernetes, створений за допомогою kubeadm, з версії 1.34.x до версії 1.35.x і з версії 1.35.x до 1.35.y (де y > x). Пропуск МІНОРНИХ версій при оновленні не підтримується. Для отримання додаткових відомостей відвідайте Політику версій зміни.

Щоб переглянути інформацію про оновлення кластерів, створених за допомогою старіших версій kubeadm, зверніться до наступних сторінок:

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

Патч-випуски

Mon, 01 Jan 0001 00:00:00 +0000

Розклад та контактна інформація команди патч-випусків Kubernetes.

Для загальної інформації про цикл випусків Kubernetes, дивіться опис процесу випуску.

Періодичність

Типова періодичність патч-випусків — щомісяця. Зазвичай вона трохи швидша (1-2 тижні) для перших патч-випусків після 1.X мінорного випуску. Критичні виправлення можуть призвести до негайного випуску поза звичайною періодичністю. Ми також намагаємося не робити випуски під час основних святкових періодів.

Контакт

Дивіться сторінку Менеджери Випусків для отримання повних контактних даних команди патч-випусків.

Дайте нам хоча б один робочий день на відповідь — ми можемо бути в іншому часовому поясі!

Перевірка налаштувань вузла

Mon, 01 Jan 0001 00:00:00 +0000

Тест відповідності вузла

Тест відповідності вузла — це контейнеризований тестовий фреймворк, який надає системну перевірку та тестування функціональності для вузла. Тест перевіряє, чи вузол відповідає мінімальним вимогам Kubernetes; вузол, який успішно проходить тест, має відповідати вимогам для приєднання до кластера Kubernetes.

Передумови вузла

Для запуску тесту відповідності вузла вузол повинен відповідати тим же передумовам, що й стандартний вузол Kubernetes. Принаймні, на вузлі повинні бути встановлені наступні служби:

Сумісні з CRI середовища виконання контейнерів, такі як Docker, containerd та CRI-O
kubelet

Запуск тесту відповідності вузла

Для запуску тесту відповідності вузла виконайте наступні кроки:

Перевірка наявності підтримки подвійного стеку IPv4/IPv6

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ розповідає, як перевірити підтримку dual-stack IPv4/IPv6 в увімкнених кластерах Kubernetes.

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

Підтримка постачальника для мереж з підтримкою подвійного стека (постачальник хмарних послуг або інший постачальник повинен забезпечити вузлам Kubernetes мережеві інтерфейси з маршрутними IPv4/IPv6)
Втулок мережі, який підтримує dual-stack мережу.
Увімкнений подвійний стек кластер

Версія вашого Kubernetes сервера має бути не старішою ніж v1.23.

Для перевірки версії введіть kubectl version.

Примітка:

Хоча ви можете перевірити це за допомогою попередньої версії, функція доступна та офіційно підтримується лише починаючи з v1.23.

Перевірка адресації

Перевірка адресування вузлів

Кожен вузол з подвійним стеком має мати виділені один блок IPv4 та один блок IPv6. Перевірте, що діапазони адрес IPv4/IPv6 для Pod налаштовані за допомогою наступної команди. Замініть імʼя вузла з прикладу на наявний вузол з подвійним стеком у вашому кластері. У цьому прикладі імʼя вузла — k8s-linuxpool1-34450317-0:

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

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці наведено кроки для визначення того, яке середовище виконання контейнерів використовують вузли у вашому кластері.

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

Політики безпеки для Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

Видалена функція

PodSecurityPolicy було визнано застарілим у Kubernetes v1.21, і видалено з Kubernetes у v1.25.

Замість використання PodSecurityPolicy, ви можете застосовувати схожі обмеження до Podʼів, використовуючи один чи обидва варіанти:

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

Для практичного керівництва з міграції дивіться Міграція з PodSecurityPolicy до вбудованого контролера Pod Security Admission. Для отримання додаткової інформації про вилучення цього API, дивіться Застарівання PodSecurityPolicy: минуле, сьогодення та майбутнє.

Політики планування

Mon, 01 Jan 0001 00:00:00 +0000

У версіях Kubernetes до v1.23 політика планування могла використовуватися для вказівки процесу predicates та priorities. Наприклад, ви могли встановити політику планування, запустивши kube-scheduler --policy-config-file <filename> або kube-scheduler --policy-configmap <ConfigMap>.

Ця політика планування не підтримується з Kubernetes v1.23. Споріднені прапорці policy-config-file, policy-configmap, policy-configmap-namespace та use-legacy-policy-config також не підтримуються. Натомість використовуйте Конфігурацію планувальника, щоб досягти схожої поведінки.

Що далі

Дізнайтеся більше про планування
Ознайомтеся з Конфігурацією kube-scheduler
Прочитайте довідку з конфігурації kube-scheduler (v1)

Приклад: Розгортання Cassandra з використанням StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

Цей підручник покаже вам, як запустити Apache Cassandra у Kubernetes. Cassandra, база даних, потребує постійного сховища для забезпечення стійкості даних (стан застосунку). У цьому прикладі використовується власний постачальник насіння Cassandra, що дозволяє базі даних виявляти нові екземпляри Cassandra, коли вони приєднуються до кластера Cassandra.

StatefulSet полегшує розгортання стійких застосунків у вашому кластері Kubernetes. Для отримання додаткової інформації про використані у цьому підручнику функції дивіться StatefulSet.

Примітка:

Cassandra та Kubernetes використовують термін вузол для позначення члена кластера. У цьому підручнику Podʼи, що належать StatefulSet, є вузлами Cassandra та є членами кластера Cassandra (званого кільцем (ring)). Коли ці Podʼи працюють у вашому кластері Kubernetes, панель управління Kubernetes розміщує ці Podʼи на Вузлах Kubernetes.

Подання прикладів використання

Mon, 01 Jan 0001 00:00:00 +0000

Приклади використання показують, як організації використовують Kubernetes для розвʼязання реальних проблем. Команда маркетингу Kubernetes та члени CNCF разом з вами працюватимуть над усіма прикладами використання.

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

Подання прикладу використання

Ознайомтеся з джерелом наявних прикладів використання.

Ознайомтеся з рекомендаціями щодо написання прикладів використання і надішліть свій запит, як зазначено в інструкції.

Публікація статей у блогах Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Існує два офіційні блоги Kubernetes, і CNCF має свій власний блог, де ви також можете розповідати про Kubernetes. У головному блозі Kubernetes ми (проєкт Kubernetes) хочемо публікувати статті з різними поглядами та напрямками, які повʼязані з Kubernetes.

За рідкісними винятками, ми публікуємо лише той контент, який не був поданий або опублікований в інших місцях.

Написання статей для блогу(ів) Kubernetes

Як автор, ви маєте три різні шляхи до публікації.

Створення кластера за допомогою kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

За допомогою kubeadm ви можете створити мінімальний кластер Kubernetes, який відповідає найкращим практикам. Фактично, ви можете використовувати kubeadm для налаштування кластера, який успішно пройде тести відповідності Kubernetes. kubeadm також підтримує інші функції життєвого циклу кластера, такі як bootstrap-токени та оновлення кластера.

Інструмент kubeadm корисний у випадках, коли вам потрібен:

Простий спосіб спробувати Kubernetes, можливо, вперше.
Спосіб для поточних користувачів автоматизувати налаштування кластера та протестувати свій застосунок.
Компонент в інших екосистемах та/або інсталяторах із більшим функціоналом.

Ви можете встановлювати та використовувати kubeadm на різних машинах: на вашому ноутбуці, хмарних серверах, Raspberry Pi та інших. Незалежно від того, чи ви розгортаєте у хмарі, чи на власних серверах, ви можете інтегрувати kubeadm у системи постачання, такі як Ansible або Terraform.

Тонка паралельна обробка за допомогою черги роботи

Mon, 01 Jan 0001 00:00:00 +0000

In цьому прикладі ви запустите Job Kubernetes, яке виконує декілька паралельних завдань як робочі процеси, кожен з яких працює як окремий Pod.

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

Ось загальний огляд кроків у цьому прикладі:

Запустіть службу зберігання, щоб зберігати чергу завдань. У цьому прикладі ви використаєте Redis для зберігання робочих елементів. У попередньому прикладі, ви використали RabbitMQ. У цьому прикладі ви будете використовувати Redis та власну бібліотеку клієнтів черг завдань; це тому, що AMQP не надає зручний спосіб клієнтам виявити, коли скінчиться черга робочих елементів з обмеженою довжиною. На практиці ви налаштуєте сховище, таке як Redis, один раз і повторно використовуватимете його для черг робочих завдань багатьох завдань та іншого.
Створіть чергу та заповніть її повідомленнями. Кожне повідомлення представляє одне завдання, яке потрібно виконати. У цьому прикладі повідомленням є ціле число, над яким ми виконаємо тривалі обчислення.
Запустіть завдання, яке працює над завданнями з черги. Завдання запускає декілька Podʼів. Кожний Pod бере одне завдання з черги повідомлень, обробляє його та повторює цей процес до досягнення кінця черги.

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

Шаблон Operator

Mon, 01 Jan 0001 00:00:00 +0000

Оператори — це розширення програмного забезпечення для Kubernetes, які використовують власні ресурси для управління застосунками та їх компонентами. Оператори дотримуються принципів Kubernetes, зокрема control loop.

Мотивація

Шаблон operator спрямований на досягнення ключової мети людини-оператора, яка керує сервісом або набором сервісів. Люди-оператори, які відповідають за конкретні застосунки та сервіси, мають глибокі знання про те, як система повинна себе вести, як її розгорнути та як реагувати у разі проблем.

Визначення причини збою Podʼа

Mon, 01 Jan 0001 00:00:00 +0000

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

Повідомлення про припинення роботи надають можливість контейнерам записувати інформацію про фатальні події у місце, звідки її можна легко витягти та показувати за допомогою інструментів, таких як інформаційні панелі та програмне забезпечення моніторингу. У більшості випадків інформацію, яку ви вводите у повідомлення про припинення роботи, також слід записати в логи Kubernetes.

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

Індексоване завдання (Job) для паралельної обробки з фіксованим призначенням роботи

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Індекс Podʼа доступний в анотації batch.kubernetes.io/job-completion-index у вигляді рядка, який представляє його десяткове значення. Щоб контейнеризований процес завдання отримав цей індекс, можна опублікувати значення анотації за допомогою механізму downward API. Для зручності панель управління автоматично встановлює downward API для експонування індексу в змінну середовища JOB_COMPLETION_INDEX.

Завдання (Job) з комунікацією Pod-Pod

Mon, 01 Jan 0001 00:00:00 +0000

У цьому прикладі ви запустите Job в Indexed completion mode, налаштований таким чином, щоб Podʼи, створені Job, могли комунікувати один з одним, використовуючи назви хостів Podʼів, а не IP-адреси Podʼів.

Podʼи в межах Job можуть потребувати комунікації між собою. Робоче навантаження користувача, що виконується в кожному Podʼі, може звертатися до сервера API Kubernetes для отримання IP-адрес інших Podʼів, але набагато простіше покладатися на вбудований DNS-резолвер Kubernetes.

Job в Indexed completion mode автоматично встановлюють назви хостів Podʼів у форматі ${jobName}-${completionIndex}. Ви можете використовувати цей формат для детермінованого створення назв хостів Podʼів та забезпечення комунікації між Podʼами без необхідності створювати клієнтське з’єднання з панеллю управління Kubernetes для отримання назв хостів/IP-адрес Podʼів через API-запити.

Використання RBAC авторизації

Mon, 01 Jan 0001 00:00:00 +0000

Контроль доступу на основі ролей (RBAC) — це метод регулювання доступу до компʼютерних або мережевих ресурсів на основі ролей окремих користувачів у вашій організації.

RBAC авторизація використовує групу API rbac.authorization.k8s.io група API для прийняття рішень щодо авторизації, дозволяючи вам динамічно налаштовувати політики через Kubernetes API.

Щоб увімкнути RBAC, запустіть API сервер з прапорцем --authorization-config, встановленим на список, розділений комами, що включає RBAC; наприклад:

Використання авторизації вузлів

Mon, 01 Jan 0001 00:00:00 +0000

Авторизація вузлів — це режим авторизації спеціального призначення, який спеціально авторизує запити API, зроблені kubelet-ами.

Огляд

Авторизатор вузлів дозволяє kubelet-ам виконувати операції з API. Це включає:

Операції читання:

services
endpoints
nodes
pods
secrets, configmaps, persistent volume claims та persistent volumes, що стосуються Podʼів, привʼязаних до вузла kubelet-а

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

Kubelets обмежені читанням власних обʼєктів Node і читанням тільки подів, привʼязаних до їхнього вузла.

Аудит

Mon, 01 Jan 0001 00:00:00 +0000

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

Аудит дозволяє адміністраторам кластера відповісти на такі питання:

що сталося?
коли це сталося?
хто це ініціював?
на чому це сталося?
де це було помічено?
звідки це було ініційовано?
куди це направлялося?

Записи аудиту починають свій життєвий цикл всередині компонента kube-apiserver. Кожен запит на кожному етапі його виконання генерує подію аудиту, яка потім передається до попередньої обробки відповідно до певної політики та записується в бекенд. Політика визначає, що буде записано, а бекенд зберігає записи. Поточні реалізації бекендів включають файли логів та вебхуки.

Загальна мова виразів у Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Загальна мова виразів (Common Expression Language, CEL) використовується в API Kubernetes для оголошення правил валідації, політик та інших обмежень чи умов.

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

Налаштування свопу на вузлах Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить приклад того, як створити та налаштувати своп на вузлі Kubernetes за допомогою kubeadm.

Створити своп на вузлі Kubernetes за допомогою kubeadm.
Навчитися налаштовувати як зашифрований, так і незашифрований своп.
Навчитися вмикати своп при завантаженні системи.

Режим Webhook

Mon, 01 Jan 0001 00:00:00 +0000

Webhook — це зворотний виклик HTTP: HTTP POST, який відбувається, коли щось стається; просте сповіщення про подію через HTTP POST. Вебзастосунок, що реалізує Webhook, буде надсилати POST повідомлення на URL, коли відбуваються певні події.

Коли вказано режим Webhook, Kubernetes звертається до зовнішнього REST сервісу для визначення привілеїв користувача.

Формат файлу конфігурації

Режим Webhook потребує файл для HTTP конфігурації, що вказується за допомогою прапорця --authorization-webhook-config-file=SOME_FILENAME.

Використання ABAC авторизації

Mon, 01 Jan 0001 00:00:00 +0000

Авторизація на основі атрибутів (ABAC) визначає парадигму контролю доступу, за якою права доступу надаються користувачам за допомогою політик, які комбінують атрибути.

Формат файлу політики

Для увімкнення режиму ABAC вказуйте --authorization-policy-file=SOME_FILENAME та --authorization-mode=ABAC при запуску.

Формат файлу — один обʼєкт JSON на рядок. Не повинно бути жодного вкладеного списку або map, тільки один map на рядок.

Кожний рядок — "обʼєкт політики", де такий обʼєкт є map із такими властивостями:

API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Основа Kubernetes — це панель управління з API server. Сервер API використовує API HTTP, яке дозволяє кінцевим користувачам, різним частинам вашого кластера та зовнішнім компонентам спілкуватися один з одним.

API Kubernetes дозволяє вам отримувати та маніпулювати станом обʼєктів API в Kubernetes (наприклад: Pod, Namespace, ConfigMap та Event).

Cloud Controller Manager

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Сloud-controller-manager це компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

DaemonSet

Mon, 01 Jan 0001 00:00:00 +0000

DaemonSet переконується, що всі (або деякі) вузли запускають копію Podʼа. При додаванні вузлів до кластера, на них додаються Podʼи. При видаленні вузлів з кластера ці Podʼи видаляються. Видалення DaemonSet призведе до очищення створених ним Podʼів.

Деякі типові використання DaemonSet включають:

запуск демона кластерного сховища на кожному вузлі
запуск демона збору логів на кожному вузлі
запуск демона моніторингу вузла на кожному вузлі

У простому випадку один DaemonSet, який охоплює всі вузли, може використовуватися для кожного типу демона. Складніше налаштування може використовувати кілька DaemonSet для одного типу демона, але з різними прапорцями, або різними запитами памʼяті та CPU для різних типів обладнання.

kubeadm upgrade

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm upgrade — це зручна команда, яка обгортає складну логіку оновлення однією командою, з підтримкою як планування оновлення, так і його фактичного виконання.

Інструкція kubeadm upgrade

Кроки для виконання оновлення за допомогою kubeadm викладені в цьому документі. Для старіших версій kubeadm, будь ласка, зверніться до старих наборів документації на сайті Kubernetes.

Ви можете використовувати kubeadm upgrade diff для перегляду змін, які будуть застосовані до маніфестів статичних Pod.

kubeadm upgrade phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm upgrade apply phase

За допомогою фаз kubeadm upgrade apply ви можете вибрати виконання окремих кроків початкового оновлення вузла панелі управління.

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу "apply"

kubeadm upgrade apply phase [flags]

-h, --help

Довідка phase

Безпека для вузлів Linux

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці описано міркування щодо безпеки та найкращі практики, характерні для операційної системи Linux.

Захист даних Secret на вузлах

На вузлах Linux томи з підтримкою пам'яті (наприклад, монтування томів secret або emptyDir з medium: Memory) реалізовано за допомогою файлової системи tmpfs.

Якщо у вас налаштовано swap і ви використовуєте стару версію ядра Linux (або поточну версію ядра та непідтримувану конфігурацію Kubernetes), томи з підтримкою памʼяті можуть мати дані, записані в постійне сховище.

Використання HTTP-проксі для доступу до Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати HTTP-проксі для доступу до Kubernetes API.

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

Використання Kube-router для NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати Kube-router для NetworkPolicy.

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

Вам потрібно мати запущений кластер Kubernetes. Якщо у вас ще немає кластера, ви можете створити його, використовуючи будь-які інсталятори кластерів, такі як Kops, Bootkube, Kubeadm тощо.

Встановлення надбудови Kube-router

Надбудова Kube-router містить контролер мережевих політик, який відстежує сервер API Kubernetes на предмет будь-яких оновлень NetworkPolicy та Podʼів і налаштовує правила iptables та ipsets для дозволу або блокування трафіку відповідно до політик. Будь ласка, слідуйте керівництву спробуйте Kube-router з інсталяторами кластерів для встановлення надбудови Kube-router.

Використання Source IP

Mon, 01 Jan 0001 00:00:00 +0000

Застосунки, що працюють у кластері Kubernetes, знаходять і взаємодіють один з одним та з зовнішнім світом через абстракцію Service. У цьому документі пояснюється, що відбувається з Source IP пакетів, надісланих на різні типи Service, і як ви можете змінити цю поведінку відповідно до ваших потреб.

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

Терміни

У цьому документі використовуються наступні терміни:

NAT: Трансляція мережевих адрес
Source NAT: Заміна Source IP в пакеті; у цьому документі це зазвичай означає заміну на IP-адресу вузла.
Destination NAT: Заміна Destination IP в пакеті; у цьому документі це зазвичай означає заміну на IP-адресу Pod
VIP: Віртуальна IP-адреса, така як та, що призначається кожному Service у Kubernetes
kube-proxy: Мережевий демон, який оркеструє управління віртуальними IP Service на кожному вузлі

Необхідні умови

Використання контейнерів sidecar

Mon, 01 Jan 0001 00:00:00 +0000

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

Sidecar-контейнери — це не нова концепція, про що було згадано в блог-пості ще у 2015 році. Kubernetes дозволяв запускати декілька контейнерів у Pod, щоб реалізувати цю концепцію. Однак запуск sidecar-контейнера як звичайного контейнера має багато обмежень, які вирішуються за допомогою нової підтримки вбудованих sidecar-контейнерів.

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

Цілі

Зрозуміти необхідність використання sidecar-контейнерів.
Вміти розвʼязувати проблеми з sidecar-контейнерами.
Зрозуміти варіанти універсального "впровадження" sidecar-контейнерів у будь-яке навантаження.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати kubectl port-forward для підключення до сервера MongoDB, який працює у кластері Kubernetes. Такий тип підключення може бути корисним для налагодження бази даних.

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

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

Виправлення помилок, повʼязаних з втулками CNI

Mon, 01 Jan 0001 00:00:00 +0000

Щоб уникнути помилок, повʼязаних з втулками CNI, переконайтеся, що ви використовуєте або оновлюєте середовище виконання контейнерів, яке було протестовано й працює коректно з вашою версією Kubernetes.

Про помилки "Incompatible CNI versions" та "Failed to destroy network for sandbox"

Проблеми з Service існують для налаштування та демонтажу мережі CNI для Pod в containerd v1.6.0-v1.6.3, коли втулки CNI не були оновлені та/або версія конфігурації CNI не вказана в файлах конфігурації CNI. Команда containerd повідомляє, що "ці проблеми вирішені в containerd v1.6.4."

Готовність планування Pod

Mon, 01 Jan 0001 00:00:00 +0000

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

Podʼи вважалися готовими до планування відразу після створення. Планувальник Kubernetes виконує всі необхідні дії для знаходження вузлів для розміщення всіх Podʼів, що очікують. Однак на практиці деякі Podʼи можуть перебувати в стані "відсутні ресурси" ("miss-essential-resources") протягом тривалого періоду. Ці Podʼи фактично спричиняють зайве навантаження на планувальник (та інтегратори, по ходу далі, такі як Cluster AutoScaler), що є непотрібним.

Шляхом вказання/видалення поля .spec.schedulingGates для Podʼа ви можете контролювати, коли Pod готовий до розгляду для планування.

Довідник KYAML

Mon, 01 Jan 0001 00:00:00 +0000

KYAML — це безпечніший і менш неоднозначний піднабір YAML, який спочатку був представлений у Kubernetes v1.34 (альфа) і є стандартно увімкненим у v1.35 (бета). KYAML, розроблений спеціально для Kubernetes, вирішує типові проблеми YAML, такі як чутливість до пробілів і неявне примусове перетворення типів, зберігаючи при цьому повну сумісність з наявними парсерами та інструментами YAML.

Цей довідник описує синтаксис KYAML.

Початок роботи з KYAML

Залежність YAML від відступів та неявного примусового перетворення типів часто призводить до помилок конфігурації, особливо в конвеєрах CI/CD та системах шаблонів, таких як Helm. KYAML усуває ці проблеми, застосовуючи явну синтаксичну структуру, що робить конфігурації більш надійними та простішими для налагодження.

Запровадження стандартів безпеки для Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Контролер допуску безпеки Podʼів має на меті замінити застарілі політики безпеки Podʼів (PodSecurityPolicies).

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

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

Запуск ZooKeeper, розподіленого системного координатора

Mon, 01 Jan 0001 00:00:00 +0000

Цей посібник демонструє як запускати Apache Zookeeper в Kubernetes, використовуючи StatefulSets, PodDisruptionBudgets, та PodAntiAffinity.

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

Перед тим як розпочати, переконайтеся, що ви маєте уявлення про:

Вам необхідно мати кластер із щонайменше чотирма вузлами, і кожен вузол повинен мати щонайменше 2 ЦП та 4 ГБ памʼяті. У цьому посібнику ви будете закривати (cordon) та очищувати для обслуговування (drain) вузли кластера. Це означає, що кластер припинить роботу та виселить всі Podʼи зі своїх вузлів, і вузли тимчасово стануть не придатними до розміщення Podʼів. Вам слід використовувати окремий кластер для цього посібника, або ви повинні забезпечити, що порушення, яке ви викличете, не нашкодить іншим мешканцям кластера.

Захист для вузлів з операційною системою Windows

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці описано питання безпеки та найкращі практики, специфічні для операційної системи Windows.

Захист конфіденційних даних на вузлах

У Windows дані з Secret записуються у відкритому вигляді у локальне сховище вузла (на відміну від використання tmpfs / файлових систем у памʼяті в Linux). Як оператору кластера, вам слід вжити обидва наступні додаткові заходи:

Використовуйте контроль доступу до файлів (file ACLs), щоб захистити місце розташування файлів Secrets.
Застосовуйте шифрування на рівні тому за допомогою BitLocker.

Користувачі контейнерів

RunAsUsername може бути вказано для Podʼів Windows або контейнерів, щоб виконувати процеси контейнера як конкретний користувач. Це приблизно еквівалентно RunAsUser.

Імперативне керування обʼєктами Kubernetes за допомогою файлів конфігурації

Mon, 01 Jan 0001 00:00:00 +0000

Обʼєкти Kubernetes можна створювати, оновлювати та видаляти за допомогою інструменту командного рядка kubectl разом із файлом конфігурації обʼєкта, написаним у форматі YAML або JSON. У цьому документі пояснюється, як визначати та керувати обʼєктами за допомогою файлів конфігурації.

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

Встановіть kubectl.

Керування ресурсами Podʼів та Контейнерів

Mon, 01 Jan 0001 00:00:00 +0000

Коли ви визначаєте Pod, ви можете додатково вказати, скільки кожного ресурсу потребує контейнер. Найпоширеніші ресурси для вказання — це процесор та памʼять (RAM); є й інші.

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

Класи сховищ

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ описує концепцію StorageClass в Kubernetes. Рекомендується мати знайомство з томами та постійними томами.

StorageClass надає можливість адміністраторам описати класи сховищ, які вони надають. Різні класи можуть відповідати рівням обслуговування, політикам резервного копіювання або будь-яким політикам, визначеним адміністраторами кластера. Kubernetes сам не визначає, що являють собою класи.

Концепція Kubernetes StorageClass схожа на "профілі" в деяких інших дизайнах систем збереження.

Обʼєкти StorageClass

Кожен StorageClass містить поля provisioner, parameters та reclaimPolicy, які використовуються, коли PersistentVolume, який належить до класу, має бути динамічно резервований для задоволення PersistentVolumeClaim (PVC).

Контейнери ініціалізації

Mon, 01 Jan 0001 00:00:00 +0000

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

Ви можете вказати контейнери ініціалізації в специфікації Podʼа разом із масивом containers (який описує контейнери застосунку).

У Kubernetes контейнер sidecar — це контейнер, який запускається перед основним контейнером застосунку і продовжує працювати. Цей документ стосується контейнерів ініціалізації — контейнерів, які завершують свою роботу після ініціалізації Podʼа.

Контролери допуску в Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає огляд контролерів допуску.

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

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

Менеджери випусків

Mon, 01 Jan 0001 00:00:00 +0000

"Менеджери Випусків" — це загальний термін, що охоплює групу учасників Kubernetes, відповідальних за підтримку гілок випусків та створення випусків, використовуючи інструменти, надані SIG Release.

Обовʼязки кожної ролі описані нижче.

Контакти
- Політика закритості за для безпеки
Довідники
Менеджери випусків
- Як стати менеджером випусків
Асистенти менеджерів випусків
- Як стати асистентом менеджера випусків
Лідери SIG Release
- Голови
- Технічні лідери

Контакти

Список Розсилки	Slack	Видимість	Використання	Членство
release-managers@kubernetes.io	#release-management (канал) / @release-managers (група користувачів)	Публічний	Публічні обговорення для Менеджерів Випусків	Усі Менеджери Випусків (включаючи Асистентів та Голов SIG)
release-managers-private@kubernetes.io	N/A	Приватний	Приватні обговорення для привілейованих Менеджерів Випусків	Менеджери Випусків, лідерство SIG Release
security-release-team@kubernetes.io	#security-release-team (канал) / @security-rel-team (група користувачів)	Приватний	Координація безпеки випусків з Комітетом з Відповіді на Безпеку	security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io

Політика закритості за для безпеки

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

Мітки вузлів, які заповнює kubelet

Mon, 01 Jan 0001 00:00:00 +0000

Вузли Kubernetes мають попередньо встановлений набір міток.

Ви також можете встановлювати власні мітки на вузлах, як через конфігурацію kubelet, так і використовуючи API Kubernetes.

Попередньо встановлені мітки

Попередньо встановлені мітки, які Kubernetes встановлює на вузли:

kubernetes.io/arch
kubernetes.io/hostname
kubernetes.io/os
node.kubernetes.io/instance-type (якщо відомо kubelet, Kubernetes може не мати цієї інформації для встановлення мітки)
topology.kubernetes.io/region (якщо відомо kubelet, Kubernetes може не мати цієї інформації для встановлення мітки)
topology.kubernetes.io/zone (якщо відомо kubelet, Kubernetes може не мати цієї інформації для встановлення мітки)

Примітка:

Значення цих міток специфічні для постачальника хмарних послуг і їх надійність не гарантуються. Наприклад, значення kubernetes.io/hostname може бути таким самим, як імʼя вузла в деяких середовищах та різним в інших середовищах.

Що далі

Дивіться Відомі мітки, анотації та позначення для списку загальних міток.
Дізнайтеся, як додати мітку на вузол.

Мітки та Селектори

Mon, 01 Jan 0001 00:00:00 +0000

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

Налагодження вузлів Kubernetes за допомогою kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як налагоджувати вузол на кластері Kubernetes за допомогою команди kubectl debug.

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

Налагодження контейнерів ініціалізації

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як розвʼязувати проблеми, повʼязані з запуском контейнерів ініціалізації. Приклади команд нижче вказують на Pod як <pod-name> та на контейнери ініціалізації як <init-container-1> та <init-container-2>.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

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

Налаштування компонентів за допомогою kubeadm API

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка охоплює способи налаштування компонентів, які розгортаються за допомогою kubeadm. Для компонентів панелі управління можна використовувати прапорці у структурі ClusterConfiguration або патчі на рівні вузла. Для kubelet і kube-proxy ви можете використовувати KubeletConfiguration та KubeProxyConfiguration, відповідно.

Всі ці опції можливі за допомогою конфігураційного API kubeadm. Докладніше про кожне поле в конфігурації ви можете дізнатися на наших довідкових сторінках API.

Примітка:

Щоб переконфігурувати кластер, який вже був створений, дивіться Переконфігурація кластера з kubeadm.

Налаштовування панелі управління за допомогою прапорців у `ClusterConfiguration`

Обʼєкт конфігурації панелі управління kubeadm надає можливість користувачам перевизначати типові прапорці, що передаються компонентам панелі управління, таким як APIServer, ControllerManager, Scheduler та Etcd. Компоненти визначаються за допомогою наступних структур:

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Обмеження системних викликів контейнера за допомогою seccomp

Mon, 01 Jan 0001 00:00:00 +0000

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

Seccomp походить від secure computing mode (безпечний режим обчислення) і є функцією ядра Linux з версії 2.6.12. Його можна використовувати для ізоляції привілеїв процесу, обмежуючи виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів та контейнерів.

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

Обмеження та резервування ID процесів

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes дозволяє обмежувати кількість ідентифікаторів процесів (PID), які може використовувати Pod. Також можна зарезервувати певну кількість доступних PID для кожного вузла для використання операційною системою та службами (на відміну від Podʼів).

Ідентифікатори процесів (PID) є фундаментальним ресурсом на вузлах. Досить легко досягти обмеження на кількість завдань без досягнення будь-яких інших обмежень ресурсів, що може призвести до нестабільності роботи хосту.

Оновлення вузлів Linux

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Для перевірки версії введіть kubectl version.

Ознайомтеся з процесом оновлення решти вузлів панелі управління за допомогою kubeadm. Вам потрібно буде спочатку оновити вузли панелі управління перед оновленням вузлів робочих навантажень Linux.

Зміна репозиторію пакунків

Якщо ви використовуєте репозиторії пакунків (pkgs.k8s.io), вам потрібно увімкнути репозиторій пакунків для потрібного мінорного релізу Kubernetes. Це пояснено в документі Зміна репозиторію пакунків Kubernetes.

Передача інформації про Pod контейнерам через файли

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як Pod може використовувати volumeDownwardAPI, щоб передати інформацію про себе контейнерам, які працюють в Pod. volumeDownwardAPI може викривати поля Pod та контейнера.

У Kubernetes є два способи експозиції полів Pod та контейнера для запущеного контейнера:

Змінні середовища
Файли томів, як пояснено в цьому завданні

Разом ці два способи експозиції полів Pod та контейнера називаються downward API.

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

Підтримка JSONPath

Mon, 01 Jan 0001 00:00:00 +0000

Kubectl підтримує шаблони JSONPath як вихідний формат.

Шаблон JSONPath складається з виразів JSONPath, які заключені в фігурні дужки { та }. Kubectl використовує вирази JSONPath для фільтрації конкретних полів у JSON-обʼєкті та форматування виводу. Окрім оригінального синтаксису шаблону JSONPath, дійсні наступні функції та синтаксис:

Використовуйте подвійні лапки для цитування тексту всередині виразів JSONPath.
Використовуйте оператори range, end для ітерації списків.
Використовуйте відʼємні індекси зрізу для кроку назад через список. Відʼємні індекси не "обгортають" список і є дійсними, поки $ ( - index + listLength ) \ge 0 $.

Примітка:

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

Політика застарівання Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ описує політику застарівання для різних аспектів системи.

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

Порти та Протоколи

Mon, 01 Jan 0001 00:00:00 +0000

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

Панель управління

Протокол	Напрямок	Діапазон портів	Призначення	Використовується
TCP	Вхідний	6443	Kubernetes API сервер	Усі
TCP	Вхідний	2379-2380	etcd server client API	kube-apiserver, etcd
TCP	Вхідний	10250	Kubelet API	Власний, Панель управління
TCP	Вхідний	10259	kube-scheduler	Власний
TCP	Вхідний	10257	kube-controller-manager	Власний

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

Посібник зі стилю документації

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає вказівки щодо стилю написання документації Kubernetes. Це вказівки, а не правила. Використовуйте здоровий глузд та не соромтеся пропонувати зміни до цього документа за допомогою pull request.

Для отримання додаткової інформації про створення нового вмісту для документації Kubernetes, прочитайте Посібник з вмісту документації.

Зміни до посібника зі стилю вносяться групою SIG Docs. Щоб запропонувати зміну або доповнення, додайте її до порядку денного на наступну зустріч SIG Docs та відвідайте зустріч, щоб взяти участь в обговоренні.

Правила створення постів у блозі

Mon, 01 Jan 0001 00:00:00 +0000

Ці настанови стосуються основного блогу Kubernetes та блогу учасників Kubernetes.

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

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

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

Оригінальний вміст

Проєкт Kubernetes приймає лише оригінальний вміст, англійською мовою.

Проби життєздатності, готовності та запуску

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes має різні типи проб:

Проба життєздатності
Проба готовності
Проба запуску

Проба життєздатності

Проби життєздатності (Liveness) визначають, коли перезапустити контейнер. Наприклад, проби життєздатності можуть виявити тупик, коли додаток працює, але не може виконувати роботу.

Якщо контейнеру не вдається пройти пробу життєздатності, kubelet перезапускає контейнер.

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

Управління робочими навантаженнями

Mon, 01 Jan 0001 00:00:00 +0000

Ви розгорнули ваш застосунок та експонували його через Service. Що далі? Kubernetes надає ряд інструментів для допомоги в управлінні розгортанням вашого застосунку, включаючи масштабування та оновлення.

Організація конфігурацій ресурсів

Багато застосунків потребують створення кількох ресурсів, таких як Deployment разом із Service. Управління кількома ресурсами можна спростити, обʼєднавши їх в одному файлі (розділеному --- у YAML). Наприклад:

application/nginx-app.yaml

apiVersion: v1
kind: Service
metadata:
 name: my-nginx-svc
 labels:
 app: nginx
spec:
 type: LoadBalancer
 ports:
 - port: 80
 selector:
 app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-nginx
 labels:
 app: nginx
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.14.2
 ports:
 - containerPort: 80

Кілька ресурсів можна створити так само як і один ресурс:

Хмарні рішення під ключ

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає список постачальників сертифікованих рішень Kubernetes. З кожної сторінки постачальника ви можете дізнатися, як встановити та налаштувати готові до експлуатації кластери.

Хуки життєвого циклу контейнера

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці описано, як контейнери, керовані kubelet, можуть використовувати фреймворк хука життєвого циклу контейнера для запуску коду, викликаного подіями під час управління їх життєвим циклом.

Огляд

Аналогічно багатьом фреймворкам програмування, які мають хуки життєвого циклу компонентів, таким як Angular, Kubernetes надає контейнерам хуки життєвого циклу. Ці хуки дозволяють контейнерам бути в курсі подій у своєму циклі управління та виконувати код, реалізований в обробнику, коли відповідний хук життєвого циклу виконується.

Оновлення вузлів Windows

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка пояснює, як оновити вузол Windows, створений за допомогою kubeadm.

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

Версія вашого Kubernetes сервера має бути не старішою ніж 1.17.

Для перевірки версії введіть kubectl version.

Використання SOCKS5-проксі для доступу до Kubernetes API

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка показує, як використовувати SOCKS5-проксі для доступу до API віддаленого кластера Kubernetes. Це корисно, коли кластер, до якого ви хочете отримати доступ, не відкриває свій API безпосередньо в інтернет.

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

Локальні файли та шляхи, які використовує Kubelet

Mon, 01 Jan 0001 00:00:00 +0000

kubelet — це переважно процес без збереження стану, який працює на вузлі Kubernetes. У цьому документі описані файли, які kubelet читає та записує.

Примітка:

Цей документ має інформаційний характер і не описує жодної гарантованої поведінки або API. У ньому перелічено ресурси, що використовуються kubelet, що є деталлю реалізації та може бути змінено у будь-якій версії.

Зазвичай, kubelet використовує панель управління як джерело істини про те, що повинно запускатися на вузлі, і середовище виконання контейнерів для отримання поточного стану контейнерів. За наявності kubeconfig (конфігурації клієнта API), kubelet підключається до панелі управління; інакше вузол працює в автономному режимі.

Обмеження поширення топології Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

Ви можете встановлювати типові обмеження на рівні кластера або налаштовувати обмеження поширення топології для окремих навантажень.

Мотивація

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

Динамічне керування допуском

Mon, 01 Jan 0001 00:00:00 +0000

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

Що таке вебхуки допуску?

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

Класи атрибутів тома

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка передбачає, що ви знайомі з StorageClasses, томами та постійними томами в Kubernetes.

Клас VolumeAttributesClass надає адміністраторам можливість описати змінні "класи" сховищ, які вони пропонують. Різні класи можуть відповідати різним рівням якості обслуговування. Kubernetes сам по собі не виражає думки про те, що представляють ці класи.

Ця функція загалом доступна (GA) з версії 1.34, і користувачі мають можливість вимкнути її.

Посібник з міграції від застарілих API

Mon, 01 Jan 0001 00:00:00 +0000

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

Вилучені API в розрізі версій

v1.32

У випуску v1.32 перестали обслуговуватися наступні застарілі версії API:

Ресурси контролю потоку

Версія API flowcontrol.apiserver.k8s.io/v1beta3 FlowSchema та PriorityLevelConfiguration більше не обслуговуються починаючи з v1.32.

Простори імен

Mon, 01 Jan 0001 00:00:00 +0000

В Kubernetes простори імен (namespaces) забезпечують механізм для ізоляції груп ресурсів в межах одного кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Засноване на просторах імен обмеження застосовується лише до обʼєктів, які входять до простору імен (наприклад, Deployments, Services тощо), а не до обʼєктів, що поширюються на весь кластер (наприклад, StorageClass, Вузли, PersistentVolumes тощо).

Job

Mon, 01 Jan 0001 00:00:00 +0000

Завдання (Job) створює один або кілька Podʼів і буде продовжувати повторювати виконання Podʼів, поки їх певна кількість успішно не завершиться. При успішному завершенні Podʼів Завдання відстежує ці успішні завершення. Коли досягнута вказана кількість успішних завершень, завдання (тобто Job) завершується. Видалення завдання буде видаляти Podʼи, які воно створило. При призупиненні завдання буде видаляти активні Podʼи, доки завдання знову не буде відновлене.

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

kubeadm config

Mon, 01 Jan 0001 00:00:00 +0000

Під час виконання kubeadm init, kubeadm надсилає обʼєкт ClusterConfiguration у ваш кластер у ConfigMap з назвою kubeadm-config у просторі імен kube-system. Ця конфігурація зчитується під час виконання kubeadm join, kubeadm reset та kubeadm upgrade.

Ви можете використовувати kubeadm config print для виведення стандартної статичної конфігурації, яку використовує kubeadm для kubeadm init і kubeadm join.

Примітка:

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

Для отримання додаткової інформації про init та join перейдіть до Використання kubeadm init з конфігураційним файлом або Використання kubeadm join з конфігураційним файлом.

kubectl для користувачів Docker

Mon, 01 Jan 0001 00:00:00 +0000

Ви можете використовувати інструмент командного рядка Kubernetes kubectl для взаємодії з сервером API. Використання kubectl є простим, якщо ви знайомі з інструментом командного рядка Docker. Однак, існує декілька відмінностей між командами Docker і командами kubectl. У наступних розділах показано субкоманду Docker та опис еквівалентної команди kubectl.

docker run

Щоб запустити Deployment nginx і експонувати Deployment, див. kubectl create deployment.

docker:

docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx

55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db

docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app

kubectl:

Автомасштабування робочих навантажень

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes ви можете масштабувати робоче навантаження залежно від поточного попиту на ресурси. Це дозволяє вашому кластеру більш еластично та ефективно реагувати на зміни витрат ресурсів.

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

Перший підхід називається горизонтальним масштабуванням, тоді як другий — вертикальним масштабуванням.

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

Варіанти топології високої доступності (HA)

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює два варіанти налаштування топології кластерів Kubernetes з високою доступністю (HA).

Ви можете налаштувати стійкий кластер:

З вузлами панелі управління, де вузли etcd розташовані разом із вузлами панелі управління.
З зовнішніми вузлами etcd, де etcd працює на окремих вузлах від вузлів панелі управління.

Перед налаштуванням стійкого кластера слід ретельно розглянути переваги та недоліки кожної топології.

Примітка:

kubeadm статично розгортає кластер etcd. Ознайомтесь з Керівництвом з кластеризації.

Топологія etcd зі спільним розміщенням

Високодоступний кластер зі спільним розміщенням — це топологія, де розподілений кластер зберігання даних, який забезпечує etcd, розміщується поверх кластера, сформованого вузлами, керованими kubeadm, які запускають компоненти панелі управління.

Версії API Kubelet Device Manager

Mon, 01 Jan 0001 00:00:00 +0000

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

Матриця сумісності

	`v1alpha1`	`v1beta1`
Kubernetes 1.21	-	✓
Kubernetes 1.22	-	✓
Kubernetes 1.23	-	✓
Kubernetes 1.24	-	✓
Kubernetes 1.25	-	✓
Kubernetes 1.26	-	✓

Позначення:

✓ Точно такі ж функції / обʼєкти API в обох, API втулка пристроїв та версії Kubernetes.
+ API втулка пристроїв має функції або обʼєкти API, яких може не бути в кластері Kubernetes, або через те, що API втулка пристроїв додало додаткові нові виклики API, або через те, що сервер видалив старий виклик API. Однак, все, що у них є спільного (більшість інших API), працюватиме. Зверніть увагу, що альфа-версії API можуть зникнути або значно змінитися між незначними релізами.
- Кластер Kubernetes має функції, які не може використовувати API втулка пристроїв, або через те, що сервер додав додаткові виклики API, або через те, що API втулка пристроїв видалило старий виклик API. Однак, все, що у них є спільного (більшість API), працюватиме.

Використання Romana для NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати Romana для NetworkPolicy.

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

Виконайте кроки 1, 2 та 3 з початкового керівництва kubeadm.

Встановлення Romana за допомогою kubeadm

Слідуйте керівництву з контейнеризованого встановлення для kubeadm.

Застосування мережевих політик

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

Мережеві політики Romana.
- Приклад мережевої політики Romana.
API NetworkPolicy.

Що далі

Після встановлення Romana ви можете перейти до Оголошення мережевої політики для випробування Kubernetes NetworkPolicy.

Віддзеркалення статті в блозі

Mon, 01 Jan 0001 00:00:00 +0000

Існує два офіційні блоги Kubernetes, і CNCF має власний блог, де ви також можете висвітлювати тему Kubernetes. У головному блозі Kubernetes ми (проєкт Kubernetes) хочемо публікувати статті з різними поглядами та напрямками, які повʼязані з Kubernetes.

Деякі статті зʼявляються в обох блогах: є первинна версія статті, а є дзеркальна стаття в іншому блозі.

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

Віртуальні IP та Проксі для Service

Mon, 01 Jan 0001 00:00:00 +0000

Кожен вузол у кластері Kubernetes запускає компонент kube-proxy (якщо ви не розгорнули власний альтернативний компонент замість kube-proxy).

Компонент kube-proxy відповідає за реалізацію механізму віртуальних IP для Service типу відмінного від ExternalName. Кожен екземпляр kube-proxy відстежує додавання та видалення обʼєктів Service та EndpointSlice у панелі управління. Для кожного сервісу kube-proxy викликає відповідні API (залежно від режиму kube-proxy) для налаштування вузла для перехоплення трафіку на clusterIP та port сервісу, і перенаправляє цей трафік на одну з точок доступу Service (зазвичай це Pod, але можливо також будь-яка інша IP-адреса, надана користувачем). Цикл керування забезпечує, що правила на кожному вузлі надійно синхронізуються зі станом Service та EndpointSlice, вказаним API сервером.

Генерація документації для API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка демонструє, як оновити документацію API Kubernetes.

Документація API Kubernetes формується на основі специфікації OpenAPI Kubernetes з використанням коду генерації з kubernetes-sigs/reference-docs.

Якщо ви знайшли помилки у згенерованій документації, вам потрібно виправити їх на upstream.

Якщо вам потрібно тільки згенерувати документацію з OpenAPI, продовжте читати цю сторінку.

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

Вимоги:

Вам потрібна машина, що працює під управлінням Linux або macOS.
Вам потрібно встановити ці інструменти:
- Python версії v3.7.x+
- Git
- Golang версії 1.13+
- Pip для встановлення PyYAML
- PyYAML версії v5.1.2
- make
- gcc компілятор/лінкер
- Docker (Потрібен тільки для довідки по команді kubectl)
Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

Дані метрик вузла

Mon, 01 Jan 0001 00:00:00 +0000

kubelet збирає статистичні дані метрик на рівні вузла, томів, pod та контейнерів, і надає цю інформацію через Summary API.

Ви можете надіслати запит з проксі до Summary API через сервер API Kubernetes.

Ось приклад запиту до Summary API для вузла з іменем minikube:

kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary"

Ось той самий виклик API за допомогою curl:

# Спочатку потрібно запустити "kubectl proxy"
# Змініть 8080 на порт, який призначає "kubectl proxy"
curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary

Примітка:

Починаючи з metrics-server версії 0.6.x, metrics-server запитує кінцеву точку kubelet /metrics/resource, а не /stats/summary.

Джерело метрик Summary API

Стандартно, Kubernetes отримує дані метрик вузлів, використовуючи вбудований cAdvisor, який працює в kubelet. Якщо ви увімкнете функціональну можливість PodAndContainerStatsFromCRI у вашому кластері та використовуєте середовище виконання контейнерів, яке підтримує доступ до статистики через Інтерфейс Виконання Контейнерів (CRI), тоді kubelet отримує дані метрик на рівні Pod та контейнерів за допомогою CRI, а не через cAdvisor.

Динамічне впровадження томів

Mon, 01 Jan 0001 00:00:00 +0000

Динамічне впровадження томів дозволяє створювати томи сховища при потребі. Без динамічного впровадження адміністратори кластера повинні вручну звертатися до свого хмарного або постачальника сховища, щоб створити нові томи сховища, а потім створювати обʼєкти PersistentVolume, щоб мати їх в Kubernetes. Функція динамічного впровадження томів усуває необхідність для адміністраторів кластера попередньо впровадження сховища. Замість цього воно автоматично впроваджує сховище, коли користувачі створюють обʼєкти PersistentVolumeClaim.

Причини

Реалізація динамічного впровадження томів базується на API-обʼєкті StorageClass з групи API storage.k8s.io. Адміністратор кластера може визначити стільки обʼєктів StorageClass, скільки потрібно, кожен з них вказуючи провайдера тому (також відомий як provisioner) для впровадження тому та набір параметрів, які слід передати цьому провайдеру. Адміністратор кластера може визначити та надавати кілька варіантів сховища (з того ж або різних систем сховищ) в межах кластера, кожен зі своїм набором параметрів. Цей дизайн також забезпечує те, що кінцеві користувачі не повинні турбуватися про складнощі та нюанси впровадження сховища, але все ще мають можливість вибрати з різних варіантів сховища.

Заплямованість та Толерантність

Mon, 01 Jan 0001 00:00:00 +0000

Спорідненість вузла (node affinity) це властивість Podʼа, яка привертає Pod до набору вузлів (або як перевага, або як жорстка вимога). Заплямованість (taint) є протилежною властивістю — вона дозволяє вузлу відштовхувати набір Podʼів.

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

Імперсонізація користувача

Mon, 01 Jan 0001 00:00:00 +0000

Імперсонізація користувача — це метод, що дозволяє автентифікованим користувачам діяти від імені іншого користувача, групи або облікового запису служби через HTTP-заголовки.

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

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

Керування доступом до API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає загальний огляд керування доступом до API Kubernetes.

Користувачі отримують доступ до API Kubernetes за допомогою kubectl, клієнтських бібліотек або за допомогою запитів REST. Як користувачі-люди, так і службові облікові записи Kubernetes можуть бути авторизовані для доступу до API. Коли запит досягає API, він проходить кілька етапів, які ілюструються на наступній діаграмі:

Транспортна безпека

Стандартно сервер API Kubernetes прослуховує порт 6443 на першому нелокальному мережевому інтерфейсі, захищеному за допомогою TLS. У типовому промисловому кластері Kubernetes, API працює на порту 443. Порт можна змінити за допомогою прапорця --secure-port, а IP-адресу прослуховування — за допомогою --bind-address.

Контейнери sidecar

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Зазвичай в одному Podʼі є лише один контейнер застосунку. Наприклад, якщо у вас є вебзастосунок, який потребує локального вебсервера, локальний вебсервер буде контейнером sidecar, а сам вебзастосунок — це контейнер застосунку.

Контролери Ingress

Mon, 01 Jan 0001 00:00:00 +0000

Примітка:

Проєкт Kubernetes рекомендує використовувати Gateway замість Ingress. API Ingress наразі перебуває в стані замороження.

Це означає, що:

API Ingress є загальнодоступним і на нього поширюються гарантії стабільності для загальнодоступних API. Проєкт Kubernetes не планує видаляти Ingress із Kubernetes.
API Ingress більше не розробляється і не буде зазнавати подальших змін або оновлень.

Контролери Ingress

Як проєкт, Kubernetes підтримує та обслуговує контролери Ingress AWS та GCE.

Контролери ingress сторонніх розробників

AKS Application Gateway Ingress Controller — це контролер Ingress, який налаштовує Azure Application Gateway.
Alibaba Cloud API Gateway Ingress — це контролер Ingress, який налаштовує Alibaba Cloud Native API Gateway, який також є комерційною версією Higress.
Apache APISIX Ingress Controller — це контролер Ingress, заснований на Apache APISIX.
Avi Kubernetes Operator забезпечує балансування навантаження рівня 4-7, використовуючи VMware NSX Advanced Load Balancer.
BFE Ingress Controller — це контролер Ingress, заснований на BFE.
BunkerWeb Ingress Controller — це контролер Ingress для BunkerWeb, WAF (Web Application Firewall) на базі nginx.
Cilium Ingress Controller — це контролер Ingress, який працює на основі Cilium.
Контролер Ingress Citrix співпрацює з контролером доставки програм Citrix.
Contour — це контролер Ingress на основі Envoy.
Emissary-Ingress API Gateway — це контролер Ingress на основі Envoy.
EnRoute — це шлюз API на основі Envoy, який може працювати як контролер Ingress.
F5 BIG-IP Container Ingress Services for Kubernetes дозволяє використовувати Ingress для конфігурації віртуальних серверів F5 BIG-IP.
FortiADC Ingress Controller підтримує ресурси Kubernetes Ingress та дозволяє керувати обʼєктами FortiADC з Kubernetes
Gloo — це відкритий контролер Ingress на основі Envoy, який пропонує функціональність воріт API.
HAProxy Ingress — це контролер Ingress для HAProxy.
Higress — це шлюз API на основі Envoy, який може працювати як контролер Ingress.
Контролер Ingress HAProxy для Kubernetes також є контролером Ingress для HAProxy.
Istio Ingress — це контролер Ingress на основі Istio.
Контролер Ingress Kong для Kubernetes — це контролер Ingress, який керує Kong Gateway.
Kusk Gateway — це контролер Ingress, орієнтований на OpenAPI, на основі Envoy.
Контролер Ingress NGINX для Kubernetes працює з вебсервером NGINX (як проксі).
ngrok-operator — це контролер для ngrok, який підтримує як Ingress, так і Gateway API для додавання безпечного публічного доступу до ваших Services K8s.
Контролер Ingress OCI Native — це контролер Ingress для Oracle Cloud Infrastructure, який дозволяє керувати OCI Load Balancer.
OpenNJet Ingress Controller є ingress-контролером на основі OpenNJet.
Контролер Ingress Pomerium — це контролер Ingress на основі Pomerium, який пропонує політику доступу з урахуванням контексту.
Skipper — це HTTP-маршрутизатор та зворотний проксі для композиції служб, включаючи випадки використання, такі як Kubernetes Ingress, розроблений як бібліотека для побудови вашого власного проксі.
Контролер Ingress Traefik Kubernetes provider — це контролер Ingress для проксі Traefik.
Tyk Operator розширює Ingress за допомогою власних ресурсів для надання можливостей управління API Ingress. Tyk Operator працює з відкритими шлюзами Tyk та хмарною системою управління Tyk.
Voyager — це контролер Ingress для HAProxy.
Контролер Ingress Wallarm — це контролер Ingress, який надає можливості WAAP (WAF) та захисту API.

Використання кількох контролерів Ingress

Ви можете розгортати будь-яку кількість контролерів Ingress за допомогою класу Ingress у межах кластера. Зверніть увагу на значення .metadata.name вашого ресурсу класу Ingress. При створенні Ingress вам слід вказати це імʼя для визначення поля ingressClassName в обʼєкті Ingress (див. специфікацію IngressSpec v1). ingressClassName є заміною застарілого методу анотації.

Локалізація документації Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить приклади локалізації документації Kubernetes різними мовами.

Покращення наявної локалізації

Ви можете допомогти додати або покращити вміст наявної локалізації. У Slack Kubernetes, ви можете знайти канал для кожної локалізації. Також є загальний канал SIG Docs Localizations, де ви можете привітатись.

Примітка:

За додатковою інформацією про те, як допомогти з певною локалізацією, шукайте локалізовану версію цієї сторінки.

Визначте дволітерний код вашої мови

Звіртесь зі стандартом ISO 639-1, щоб знайти дволітерний код вашої мови. Наприклад, дволітерний код для української мови — uk.

Масштабування StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

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

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

StatefulSets доступні тільки в версії Kubernetes 1.5 або пізніше. Щоб перевірити вашу версію Kubernetes, виконайте kubectl version.
Не всі застосунки зі збереженням стану гарно масштабуються. Якщо ви не впевнені, чи масштабувати ваші StatefulSets, див. Концепції StatefulSet або Посібник StatefulSet для отримання додаткової інформації.
Ви повинні виконувати масштабування лише тоді, коли ви впевнені, що ваш кластер застосунку зі збереженням стану є повністю справним.

Менеджери ресурсів вузлів

Mon, 01 Jan 0001 00:00:00 +0000

Для підтримки критичних до затримки та високопродуктивних робочих навантажень Kubernetes пропонує набір менеджерів ресурсів. Менеджери прагнуть координувати та оптимізувати вирівнювання ресурсів вузла для Podʼів, налаштованих з конкретною вимогою до ресурсів процесорів, пристроїв та памʼяті (величезних сторінок).

Політики вирівнювання топології апаратного забезпечення

Topology Manager — це компонент kubelet, який прагне координувати набір компонентів, відповідальних за ці оптимізації. Загальний процес управління ресурсами регулюється за допомогою політики, яку ви вказуєте. Щоб дізнатися більше, прочитайте Контроль політик управління топологією на вузлі.

Мережа в кластері

Mon, 01 Jan 0001 00:00:00 +0000

Мережі є центральною частиною Kubernetes, але часто важко зрозуміти, як саме вони мають працювати. Існують 4 відмінних мережевих проблеми, які потрібно вирішити:

Взаємодія контейнерів між собою: цю проблему вирішує використання Podʼів та взаємодія з localhost.
Взаємодія між Podʼами: це основна ціль даного документа.
Взаємодія між Podʼом та Service: ця проблема описана у Service.
Взаємодія Service із зовнішнім світом: це також описано в контексті Service.

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

Метрики Pod та Контейнерів CRI

Mon, 01 Jan 0001 00:00:00 +0000

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

kubelet збирає метрики Pod та контейнерів через cAdvisor. Як альфа-функція, Kubernetes дозволяє налаштувати збір метрик Pod та контейнерів через Інтерфейс Виконання Контейнерів (CRI). Ви повинні увімкнути функціональну можливість PodAndContainerStatsFromCRI та використовувати сумісну реалізацію CRI (containerd >= 1.6.0, CRI-O >= 1.23.0), щоб використовувати механізм збору через CRI.

Метрики Pod та Контейнерів CRI

З увімкненим PodAndContainerStatsFromCRI, kubelet опитує підлегле середовище виконання контейнерів для отримання статистики Pod та контейнерів замість того, щоб безпосередньо перевіряти хост-систему за допомогою cAdvisor. Переваги використання середовища виконання контейнерів для цієї інформації, на відміну від прямого збору за допомогою cAdvisor, включають:

Налаштування драйвера cgroup

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює, як налаштувати драйвер cgroup kubelet, щоб він відповідав драйверу cgroup контейнера для кластерів kubeadm.

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

Вам слід ознайомитися з вимогами до контейнерних середовищ Kubernetes.

Налаштування драйвера cgroup середовища виконання контейнерів

Сторінка Середовища виконання контейнерів пояснює, що для налаштувань на основі kubeadm рекомендується використовувати драйвер systemd замість типового драйвера cgroupfs kubelet, оскільки kubeadm керує kubelet як сервісом systemd.

На сторінці також наведено деталі щодо того, як налаштувати різні контейнерні середовища зі стандартним використанням драйвера systemd.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Нотатки

Mon, 01 Jan 0001 00:00:00 +0000

Нотатки про випуски можна знайти, переглянувши Changelog, який відповідає вашій версії Kubernetes. Перегляньте changelog для 1.35 на GitHub.

Або, нотатки про випуски можна шукати та фільтрувати онлайн на: relnotes.k8s.io. Перегляньте відфільтровані нотатки про випуск для 1.35 на relnotes.k8s.io.

Обʼєднання конфігураційних тек Kubelet

Mon, 01 Jan 0001 00:00:00 +0000

Коли використовується прапорець kubelet --config-dir для вказівки теки для конфігурації, існує певна специфічна поведінка для обʼєднання різних типів.

Ось кілька прикладів того, як різні типи даних поводяться під час обʼєднання конфігурації:

Поля структур

У YAML структурі є два типи полів структури: одиничні (або скалярні типи) та вбудовані (структури, що містять скалярні типи). Процес обʼєднання конфігурацій обробляє заміну одиничних та вбудованих полів структур для створення кінцевої конфігурації kubelet.

Наприклад, ви можете хотіти мати базову конфігурацію kubelet для всіх вузлів, але налаштувати поля address і authorization. Це можна зробити наступним чином:

Оновлення обʼєктів API на місці за допомогою kubectl patch

Mon, 01 Jan 0001 00:00:00 +0000

Це завдання показує, як використовувати kubectl patch для оновлення обʼєкта API на місці. Вправи в цьому завданні демонструють стратегічний патч злиття та патч злиття JSON.

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

Паралельна обробка з розширенням

Mon, 01 Jan 0001 00:00:00 +0000

Це завдання демонструє запуск кількох Jobs на основі загального шаблону. Ви можете використовувати цей підхід для обробки пакетних завдань паралельно.

У цьому прикладі є лише три елементи: apple, banana та cherry. Приклади Job обробляють кожен елемент, виводячи рядок, а потім очікуючи дії користувача.

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

Перевірка впливу видалення dockershim на ваш кластер

Mon, 01 Jan 0001 00:00:00 +0000

Компонент dockershim Kubernetes дозволяє використовувати Docker як середовище виконання контейнерів Kubernetes. Вбудований компонент dockershim Kubernetes був видалений у випуску v1.24.

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

Про cgroup v2

Mon, 01 Jan 0001 00:00:00 +0000

У Linux control groups обмежують ресурси, які виділяються процесам.

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

Є дві версії cgroups у Linux: cgroup v1 і cgroup v2. cgroup v2 — це нове покоління API cgroup в Linux.

Розповсюдження облікових даних з використанням Secret

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Розробка та налагодження сервісів локально за допомогою telepresence

Mon, 01 Jan 0001 00:00:00 +0000

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

Розуміння метрик Pressure Stall Information (PSI)

Mon, 01 Jan 0001 00:00:00 +0000

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

У вигляді бета-функції Kubernetes дозволяє налаштувати kubelet для збору інформації про тиск на ресурси в Linux Pressure Stall Information (PSI) про використання CPU, памʼяті та вводу-виводу. Інформація збирається на рівні вузлів, podʼів та контейнерів. Ця функція є стандартно увімкненою через функціональну можливість KubeletPSI.

Метрики PSI надаються через два різні джерела:

Summary API kubelet, який надає дані PSI на рівні вузлів, podʼів та контейнерів.
Точка доступу /metrics/cadvisor на kubelet, яка надає метрики PSI у форматі Prometheus.

Вимоги

Pressure Stall Information вимагає наступного на ваших вузлах Linux:

Самовідновлення Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Можливості самовідновлення

Перезапуски на рівні контейнера: Якщо контейнер всередині Podʼа виходить з ладу, Kubernetes перезапускає його на основі restartPolicy.
Заміна реплік: Якщо Pod у Deployment або StatefulSet виходить з ладу, Kubernetes створює Pod на заміну, щоб підтримувати вказану кількість реплік. Якщо Pod, який є частиною DaemonSet, виходить з ладу, панель управління створює Pod на заміну для запуску на тому ж вузлі.

Сертифікати PKI та вимоги

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes вимагає наявності сертифікатів PKI для автентифікації за допомогою TLS. Якщо ви встановлюєте Kubernetes за допомогою kubeadm, сертифікати, необхідні для вашого кластера, генеруються автоматично. Ви також можете створити свої власні сертифікати, наприклад, щоб зберігати ваші приватні ключі більш безпечно, не зберігаючи їх на сервері API. Ця сторінка пояснює, які сертифікати необхідні для вашого кластера.

Як кластер використовує сертифікати

Kubernetes вимагає PKI для виконання таких операцій:

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Точки доступу для моніторингу стану API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

API сервер Kubernetes надає точки доступу API для індикації поточного стану API сервера. Ця сторінка описує ці точки доступу API та пояснює, як ви можете їх використовувати.

Точки доступу API для моніторингу стану

API сервер Kubernetes надає 3 точки доступу API (healthz, livez і readyz) для індикації поточного стану API сервера. Точка доступу healthz є застарілою (з Kubernetes v1.16), і ви повинні використовувати більш конкретні точки доступу livez та readyz. Точку доступу livez можна використовувати з прапорцем --livez-grace-period, щоб вказати тривалість запуску. Для належного завершення роботи ви можете вказати прапорець --shutdown-delay-duration з точкою доступу /readyz. Машини, що перевіряють healthz/livez/readyz API сервера, повинні покладатися на HTTP-код статусу. Код статусу 200 вказує, що API сервер є healthy/live/ready, залежно від викликаної точки доступу.

Управління службовими обліковими записами

Mon, 01 Jan 0001 00:00:00 +0000

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

Процес всередині Pod може використовувати ідентифікацію свого повʼязаного службового облікового запису для автентифікації у API сервері кластера.

Для ознайомлення зі службовими обліковими записами, прочитайте про конфігурування службових облікових записів.

Цей посібник пояснює деякі концепції, повʼязані зі ServiceAccount. Також у посібнику розглядається, як отримати або відкликати токени, що представляють ServiceAccounts. ServiceAccounts, і як (за бажанням) привʼязати термін дії ServiceAccounts до часу життя обʼєкта API.

Gateway API

Mon, 01 Jan 0001 00:00:00 +0000

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

Принципи дизайну

Наведені нижче принципи визначили дизайн та архітектуру Gateway API:

Орієнтований на ролі: Види Gateway API моделюються за організаційними ролями, які відповідають за управління мережевою службою Kubernetes:

Спостережуваність

Mon, 01 Jan 0001 00:00:00 +0000

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

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

На малюнку 1 показано, як компоненти кластера формують три основні типи сигналів.

EndpointSlices

Mon, 01 Jan 0001 00:00:00 +0000

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

EndpointSlices відстежують IP-адреси точок доступу бекенду. EndpointSlices зазвичай повʼязані з і точки доступу бекенду зазвичай представляють .

EndpointSlice API

У Kubernetes, EndpointSlice містить посилання на набір мережевих точок доступу. Панель управління автоматично створює EndpointSlices для будь-якої служби Kubernetes, яка має вказаний селектор. Ці EndpointSlices містять посилання на всі Podʼи, які відповідають селектору Service. EndpointSlices групують мережеві точки доступу за унікальними комбінаціями сімейств IP, протоколу, номеру порту та імені Service. Імʼя обʼєкта EndpointSlice повинно бути дійсним імʼям піддомену DNS.

kubeadm reset

Mon, 01 Jan 0001 00:00:00 +0000

Виконує максимально можливий відкат змін, зроблених командами kubeadm init або kubeadm join.

Опис

Виконує максимально можливий відкат змін для хоста, зроблених командами kubeadm init або kubeadm join.

Команда "reset" виконує наступні фази:

preflight Запуск попередніх перевірок
remove-etcd-member Вилучення локального учасника etcd.
cleanup-node Запуск очищення вузла.

kubeadm reset [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях до теки, де зберігаються сертифікати. Якщо вказано, очистити цю теку.

Kubernetes z-pages

Mon, 01 Jan 0001 00:00:00 +0000

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

Компоненти ядра Kubernetes можуть надавати набір z-endpoints, щоб полегшити користувачам налагодження кластера та його компонентів. Ці точки доступу мають використовуватися виключно для перевірки людиною для отримання інформації про налагодження двійкового коду компонента у реальному часі. Уникайте автоматичного отримання даних, що повертаються цими точками доступу; у Kubernetes 1.35 це альфа функція, і формат відповіді може змінитися у майбутніх випусках.

z-pages

Kubernetes v1.35 дозволяє увімкнути z-pages, які допоможуть вам усунути проблеми з компонентами основної панелі управління. Ці спеціальні налагоджувальні точки доступу надають внутрішню інформацію про запущені компоненти. У Kubernetes 1.35 компоненти обслуговують такі точки доступу (якщо їх увімкнено):

Анотації

Mon, 01 Jan 0001 00:00:00 +0000

Ви можете використовувати анотації Kubernetes, щоб додати довільні невизначені метадані до обʼєктів. Клієнти, такі як інструменти та бібліотеки, можуть отримувати ці метадані.

Додавання метаданих до обʼєктів

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

Архітектура логування

Mon, 01 Jan 0001 00:00:00 +0000

Логи застосунків можуть допомогти вам зрозуміти, що відбувається у нього всередині. Логи особливо корисні для виправлення проблем та моніторингу активності кластера. Більшість сучасних застосунків мають деякий механізм логування. Так само, рушії виконання контейнерів розроблені з підтримкою логування. Найпростіший і найбільш прийнятий метод логування для контейнеризованих застосунків — це запис у стандартні потоки виводу та помилок.

Однак, природня функціональність, яку надає рушій виконання контейнерів або середовище виконання, зазвичай недостатня для повного вирішення завдань логування.

Видалення StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

Це завдання показує, як видалити StatefulSet.

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

Це завдання передбачає, що у вас є застосунок, який працює на вашому кластері та представлений StatefulSet.

Видалення StatefulSet

Ви можете видалити StatefulSet так само як і інші ресурси в Kubernetes: використовуйте команду kubectl delete та вкажіть StatefulSet або файлом, або імʼям.

Використання Service для доступу до застосунку у кластері

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Використання Weave Net для NetworkPolicy

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як використовувати Weave Net для NetworkPolicy.

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

Вам потрібен Kubernetes кластер. Слідуйте початковому керівництву kubeadm, щоб його налаштувати.

Встановлення надбудови Weave Net

Слідуйте керівництву Інтеграція Kubernetes через надбудову.

Надбудова Weave Net для Kubernetes містить Контролер мережевих політик, який автоматично відстежує всі анотації мережевих політик у Kubernetes у всіх просторах імен і налаштовує правила iptables для дозволу або блокування трафіку відповідно до цих політик.

Встановлення драйверів та виділення пристроїв з DRA

Mon, 01 Jan 0001 00:00:00 +0000

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

Цей посібник показує, як встановити драйвери Динамічного виділення ресурсів (DRA) у вашому кластері та як використовувати їх разом з API DRA для виділення пристроїв для Pod. Ця сторінка призначена для адміністраторів кластерів.

Горизонтальне автомасштабування Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes HorizontalPodAutoscaler автоматично оновлює ресурс навантаження (наприклад, Deployment або StatefulSet), з метою автоматичного масштабування потужності у відповідь на попит.

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

Дослідження поведінки завершення роботи для Podʼів та їх точок доступу

Mon, 01 Jan 0001 00:00:00 +0000

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

Процес завершення роботи для Podʼів та їх точок доступу

Часто виникають випадки, коли потрібно завершити роботу Podʼа — чи то для оновлення, чи то для зменшення масштабу. Для поліпшення доступності застосунку може бути важливо реалізувати правильне завершення активних зʼєднань.

Доступ до кластера через API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує, як отримати доступ до кластера через API Kubernetes.

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

Ефемерні контейнери

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Розуміння ефемерних контейнерів

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

Знімки томів

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes VolumeSnapshot представляє знімок тому в системі зберігання. Цей документ передбачає, що ви вже знайомі з постійними томами Kubernetes — persistent volumes.

Вступ

Так само як ресурси API PersistentVolume та PersistentVolumeClaim використовуються для створення томів для користувачів та адміністраторів, API-ресурси VolumeSnapshotContent та VolumeSnapshot надаються для створення знімків томів для користувачів та адміністраторів.

VolumeSnapshotContent — це знімок, зроблений з тому в кластері, який був створений адміністратором. Це ресурс в кластері, так само як PersistentVolume — це ресурс кластера.

Інтерфейс середовища виконання контейнерів (CRI)

Mon, 01 Jan 0001 00:00:00 +0000

CRI — це інтерфейс втулка, який дозволяє kubelet використовувати різноманітні середовища виконання контейнерів, не маючи потреби перекомпілювати компоненти кластера.

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

Комунікація після випуску

Mon, 01 Jan 0001 00:00:00 +0000

Команда Release Comms Kubernetes (частина SIG Release) займається анонсами випусків, які публікуються у головному блозі проєкту.

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

Підписка на розсилку після випуску

Під час циклу випуску, як учасник, ви можете підписатися на розсилку повідомлень про майбутні зміни у Kubernetes.

Міграція агентів телеметрії та безпеки з dockershim

Mon, 01 Jan 0001 00:00:00 +0000

Підтримка Kubernetes прямої інтеграції з Docker Engine є застарілою та була видалена. Більшість застосунків не мають прямої залежності від середовища виконання контейнерів. Однак, є ще багато агентів телеметрії та моніторингу, які мають залежність від Docker для збору метаданих, логів та метрик контейнерів. Цей документ збирає інформацію про те, як виявити ці залежності, а також посилання на те, як перенести ці агенти для використання загальних інструментів або альтернативних середовищ виконання.

Міграція обʼєктів Kubernetes за допомогою міграції версій сховища

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes покладається на активне переписування даних API, щоб підтримувати деякі дії обслуговування, повʼязані зі збереженням у спокої. Два видатні приклади цього — це версійна схема збережених ресурсів (тобто зміна перевіреної схеми збереження від v1 до v2 для певного ресурсу) та шифрування у спокої (тобто перезапис старих даних на основі зміни у способі шифрування даних).

Виконання міграції версій сховища дозволяє гарантувати, що всі обʼєкти для ресурсу були переміщені з застарілої версії сховища. Вимоги до виконання міграції сховища полягають у тому, щоб ресурс мав цілочисельну версію ресурсу. Всі ресурси Kubernetes і CRD гарантовано мають цю властивість, але міграція не відбудеться, якщо це не так, наприклад, у випадку агрегованих API.

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

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці показано, як встановити квоту на загальну кількість Podʼів, які можуть працювати в просторі імен. Ви вказуєте квоти в обʼєкті ResourceQuota.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Обробка повторюваних і неповторюваних помилок Pod за допомогою політики збоїв Pod

Mon, 01 Jan 0001 00:00:00 +0000

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

Цей документ показує, як використовувати політику збоїв Pod, у поєднанні з типовою політикою відмови Podʼа, для покращення контролю над обробкою збоїв на рівні контейнера або Pod у Job.

Визначення політики збоїв Pod може допомогти вам:

краще використовувати обчислювальні ресурси, уникаючи непотрібних повторних запусків Podʼів.
уникати збоїв Job через збої Pod (такі як випередження, виселення ініційоване API або виселення на основі taint).

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

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

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

Mon, 01 Jan 0001 00:00:00 +0000

Використовуйте файли kubeconfig для організації інформації про кластери, користувачів, простори імен та механізми автентифікації. kubectl використовує файли kubeconfig, щоб знайти інформацію, необхідну для вибору кластера та звʼязку з сервером API кластера.

Примітка:

Файл, який використовується для налаштування доступу до кластерів, називається файлом kubeconfig. Це загальний спосіб посилання на файли конфігурації. Це не означає, що існує файл з іменем kubeconfig.

Попередження:

Використовуйте файли kubeconfig лише з надійних джерел. Використання спеціально створеного файлу kubeconfig може призвести до виконання зловмисного коду або розголошення файлів. Якщо вам все ж потрібно використовувати ненадійний файл kubeconfig, уважно перевірте його, так само як ви це зробили б з файлом скрипту оболонки.

Типово kubectl шукає файл з імʼям config у теці $HOME/.kube. Ви можете вказати інші файли kubeconfig, встановивши змінну середовища KUBECONFIG або встановивши прапорець --kubeconfig.

Політика версійної розбіжності

Mon, 01 Jan 0001 00:00:00 +0000

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

Підтримувані версії

Версії Kubernetes позначаються як x.y.z, де x — основна версія, y — мінорна версія, а z — патч-версія, згідно з термінологією Семантичного Версіонування. Для отримання додаткової інформації дивіться Kubernetes Release Versioning.

Проєкт Kubernetes підтримує гілки випусків для останніх трьох мінорних випусків (1.35, 1.34, 1.33). Kubernetes 1.19 та новіші версії отримують приблизно 1 рік патч-підтримки. Kubernetes 1.18 та старіші отримували приблизно 9 місяців патч-підтримки.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

Поради щодо динамічного розподілу ресурсів адміністратором кластера

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці описано найкращі практики налаштування кластера Kubernetes із використанням динамічного розподілу ресурсів (DRA). Ці інструкції призначені для адміністраторів кластерів.

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

Загалом, доступ до DeviceClasses і ResourceSlices має бути обмеженим, тільки для адміністраторів і драйверів DRA. Операторам кластерів, які будуть розгортати Podʼи з запитами, знадобиться доступ до API ResourceClaim і ResourceClaimTemplate; обидва ці API обмежуються просторами імен.

Правила використання kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Рекомендовані правила використання kubectl.

Використання `kubectl` у багаторазових скриптах

Для стабільного виводу у скрипті:

Використовуйте одну з машинно-орієнтованих форм виводу, таких як -o name, -o json, -o yaml, -o go-template, або -o jsonpath.
Повністю вказуйте версію. Наприклад, jobs.v1.batch/myjob. Це гарантує, що kubectl не використовуватиме свою стандартну версію, яка може змінюватися з часом.
Не покладайтеся на контекст, налаштування або інші неявні стани.

Субресурси

Ви можете використовувати аргумент --subresource для команд kubectl, таких як get, patch, edit, apply та replace для отримання та оновлення субресурсів для всіх ресурсів, які їх підтримують. В Kubernetes версії 1.35 підтримуються лише субресурси status, scale та resize.
- Для kubectl edit, субресурс scale не підтримується. Якщо ви використовуєте --subresource з kubectl edit і вказуєте scale як субресурс, команда викличе помилку.
Контракт API для субресурсу ідентичний до повного ресурсу. Оновлюючи субресурс status до нового значення, майте на увазі, що субресурс може бути потенційно узгоджений контролером до іншого значення.

Сертифікати та запити на їх підписування

Mon, 01 Jan 0001 00:00:00 +0000

API для сертифікатів та наборів довіри Kubernetes дозволяють автоматизувати створення облікових даних X.509, надаючи програмний інтерфейс для клієнтів API Kubernetes для запиту та отримання X.509 сертифікатів від Центру сертифікації (CA).

Також є експериментальна (альфа) підтримка розподілу наборів довіри.

Запити на підписання сертифікатів

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

Ресурс CertificateSigningRequest (CSR) використовується для запиту підписання сертифіката від вказаного підписувача, після чого запит може бути схвалений або відхилений перед остаточним підписанням.

Створення високодоступних кластерів за допомогою kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці пояснюється два різних підходи до налаштування високодоступного кластера Kubernetes з використанням інструменту kubeadm:

Зі стековими вузлами панелі управління. Цей підхід вимагає менше інфраструктури. Члени etcd та вузли панелі управління розташовані разом.
Зовнішній кластер etcd. Цей підхід вимагає більше інфраструктури. Вузли панелі управління та члени etcd розділені.

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

Створення діаграм

Mon, 01 Jan 0001 00:00:00 +0000

Цей посібник показує, як створювати, редагувати та поширювати діаграмами за допомогою JavaScript бібліотеки Mermaid. Mermaid.js дозволяє створювати діаграми за допомогою простого синтаксису, подібного до Markdown, всередині Markdown-файлів. Ви також можете використовувати Mermaid для створення файлів зображень у форматі .svg або .png, які ви можете додати до документації.

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

Увімкнення або вимкнення функціональних можливостей

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці показано, як увімкнути або вимкнути функціональні можливості для керування певними функціями Kubernetes у вашому кластері. Увімкнення функціональних можливостей дозволяє тестувати та використовувати функції Alpha або Beta до того, як вони стануть загальнодоступними.

Примітка:

Деякі стабільні (GA) можливості також можна вимкнути, зазвичай через один мінорний реліз після GA; однак у цьому випадку ваш кластер може не відповідати вимогам Kubernetes.

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

Усунення несправностей управління топологією

Mon, 01 Jan 0001 00:00:00 +0000

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

Ви можете керувати топологією всередині вузлів. Це означає, що ви допомагаєте kubelet налаштувати операційну систему хоста так, щоб под і контейнери розміщувалися на правильній стороні внутрішніх меж, таких як домени NUMA. (NUMA — це абревіатура від «non-uniform memory access» (нерівномірний доступ до памʼяті) і означає, що процесори можуть бути топологічно ближчими до певних областей памʼяті через фізичне розташування апаратних компонентів і спосіб їх зʼєднання).

Фреймворк планування

Mon, 01 Jan 0001 00:00:00 +0000

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

Фреймворк планування — це розширювана архітектура для планувальника Kubernetes. Вона складається з набору "втулків" API, які компілюються безпосередньо в планувальник. Ці API дозволяють реалізувати більшість функцій планування у вигляді втулків, зберігаючи при цьому основне ядро планування легким та зручним у використанні. Для отримання більш технічної інформації про дизайн цієї архітектури зверніться до пропозиції проєкту дизайну системи планування.

Робота фреймворку

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

Класи знімків томів

Mon, 01 Jan 0001 00:00:00 +0000

У цьому документі описано концепцію VolumeSnapshotClass в Kubernetes. Рекомендується мати відомості про знімки томів та класи сховищ.

Вступ

Так само як StorageClass надає можливість адміністраторам описувати "класи" сховищ, які вони пропонують при виділенні тому, VolumeSnapshotClass надає можливість описувати "класи" сховищ при виділенні знімка тому.

Ресурс VolumeSnapshotClass

Кожен VolumeSnapshotClass містить поля driver, deletionPolicy та parameters, які використовуються, коли потрібно динамічно виділити том для VolumeSnapshot, який належить до цього класу.

Динамічне виділення ресурсів

Mon, 01 Jan 0001 00:00:00 +0000

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

На цій сторінці описано динамічне виділення ресурсів (DRA) у Kubernetes.

Про DRA

DRA is функція Kubernetes, яка дозволяє вам запитувати ресурси та ділитися ними з іншими Podʼами. Ці ресурси часто приєднуються до пристроїів, наприклад, до апаратних прискорювачів.

З DRA драйвери пристроїв і адміністратори кластерів визначають класи пристроїв, які доступні для заявки в робочих навантаженнях. Kubernetes виділяє відповідні пристрої для конкретних заявок і розміщує відповідні Podʼи на вузлах, які можуть отримати доступ до виділених пристроїв.

Контейнери Windows у Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Організації, що вклались у застосунки на базі Windows та Linux, не мають шукати окремі оркестратори для управління своїми навантаженнями, що призводить до збільшення оперативної ефективності у їх розгортаннях, незалежно від операційної системи.

Windows-вузли у Kubernetes

Для увімкнення оркестрування контейнерів Windows у Kubernetes, додайте Windows-вузли до вашого поточного Linux-кластера. Планування розміщення контейнерів Windows у Podʼах на Kubernetes подібне до планування розміщення контейнерів на базі Linux.

kubeadm token

Mon, 01 Jan 0001 00:00:00 +0000

Токени запуску (Bootstrap token) використовуються для встановлення двосторонньої довіри між вузлом, який приєднується до кластера, та вузлом панелі управління, як описано в розділі автентифікація за допомогою токенів запуску.

kubeadm init створює початковий токен з часом життя 24 години. Наступні команди дозволяють вам керувати таким токеном, а також створювати та керувати новими.

kubeadm token create

Створює токени запуску на сервері.

Опис

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

Автоматичне очищення завершених задач

Mon, 01 Jan 0001 00:00:00 +0000

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

Коли ваша задача завершилася, корисно залишити цю задачу в API (і не видаляти її відразу), щоб ви могли визначити, чи вдалося, чи не вдалося завдання.

Контролер Kubernetes часу життя після завершення забезпечує механізм TTL (time to live), щоб обмежити термін життя обʼєктів задачі, які завершили виконання.

Версія сумісності для компонентів панелі управління Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Починаючи з версії 1.32, ми додали до компонентів панелі управління Kubernetes параметри сумісності версій та емуляції, що налаштовуються, щоб зробити оновлення безпечнішими, надаючи більше контролю та збільшуючи деталізацію кроків, доступних адміністраторам кластерів.

Емульована версія

Параметр емуляції задається прапорцем --emulated-version компонентів панелі управління. Він дозволяє компоненту емулювати поведінку (API, функції ...) більш ранньої версії Kubernetes.

При його використанні доступні можливості будуть відповідати емульованій версії:

Будь-які можливості, присутні в двійковій версії, які були додані після версії емуляції, будуть недоступні.
Будь-які можливості, вилучені після версії емуляції, будуть доступними.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes VerticalPodAutoscaler автоматично оновлює управління ресурсом робочого навантаження (таким як Deployment або StatefulSet), з метою автоматичного коригування ресурсів інфраструктури [запитів і обмежень](/docs/concepts/configuration/manage-resources-containers/# запити-та-обмеження) відповідно до фактичного використання.

Групове планування

Mon, 01 Jan 0001 00:00:00 +0000

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

Групове планування забезпечує, щоб група Podʼів була запланована з дотриманням принципу "все або нічого". Якщо кластер не може вмістити всю групу (або визначену мінімальну кількість Podʼів), жоден з Podʼів не привʼязується до вузла.

Ця функція залежить від Workload API . Переконайтесь, що увімкнено функціональну можливість GenericWorkload та групу API scheduling.k8s.io/v1alpha1 у кластері.

Як це працює

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

Допомога у написанні блогу

Mon, 01 Jan 0001 00:00:00 +0000

Існує два офіційні блоги Kubernetes, і CNCF має власний блог, де ви також можете писати про Kubernetes. Прочитайте як робити внесок у створення дописів у блоги Kubernetes, щоб дізнатися про ці два блоги.

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

Вам слід переконатися, що ви принаймні ознайомилися з правилами подання статті перед тим, як читати далі на цій сторінці.

Зʼєднання фронтенду з бекендом за допомогою Service

Mon, 01 Jan 0001 00:00:00 +0000

Це завдання показує, як створити мікросервіси frontend та backend. Мікросервіс бекенд є сервісом для привітання. Фронтенд експонує backend за допомогою nginx та обʼєкта Kubernetes Service.

Цілі

Створити та запустити зразок мікросервісу бекенд hello за допомогою обʼєкта Deployment.
Використовувати обʼєкт Service для надсилання трафіку до кількох реплік мікросервісу бекенд.
Створити та запустити мікросервіс фронтенд nginx, також використовуючи обʼєкт Deployment.
Налаштувати мікросервіс фронтенд для надсилання трафіку до мікросервісу бекенд.
Використовувати обʼєкт Service типу LoadBalancer для експонування мікросервісу фронтенд назовні кластера.

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

Збір сміття

Mon, 01 Jan 0001 00:00:00 +0000

Збирання сміття — це загальний термін для різних механізмів, які Kubernetes використовує для очищення ресурсів кластера. Це дозволяє очищати ресурси, такі як:

Припиненні Podʼи
Завершені завдання (Jobs)
Обʼєкти без власників
Невикористані контейнери та образи контейнерів
Динамічно створені томи PersistentVolumes із політикою вилучення StorageClass Delete
Застарілі або прострочені запити на підпис сертифікатів (CSRs)
Видалені вузли в наступних сценаріях:
- У хмарі, коли кластер використовує керування контролером хмари
- На місці, коли кластер використовує надбудову, схожу на контролер хмари
Обʼєкти Node Lease

Власники та залежності

Багато обʼєктів в Kubernetes повʼязані один з одним через посилання на власника. Посилання на власника повідомляють панелі управління, які обʼєкти залежать від інших. Kubernetes використовує посилання на власника для того, щоб дати панелі управління та іншим клієнтам API можливість очищати повʼязані ресурси перед видаленням обʼєкта. У більшості випадків Kubernetes автоматично керує посиланнями на власника.

Клонування CSI-томів

Mon, 01 Jan 0001 00:00:00 +0000

У цьому документі описано концепцію клонування наявних томів CSI в Kubernetes. Рекомендується мати уявлення про томи.

Вступ

Функція клонування томів CSI додає підтримку вказання наявних PVC у полі dataSource для позначення бажання користувача клонувати Том.

Мережеві політики

Mon, 01 Jan 0001 00:00:00 +0000

Якщо ви хочете контролювати потік трафіку на рівні IP-адреси чи порту для протоколів TCP, UDP та SCTP, то вам, можливо, варто розглянути використання NetworkPolicies Kubernetes для конкретних застосунків у вашому кластері. NetworkPolicies — це конструкт, орієнтований на застосунок, який дозволяє вам визначати, як Pod може взаємодіяти з різними мережевими "сутностями" (ми використовуємо тут слово "сутність", щоб уникнути перевантаження більш загальноприйнятими термінами, такими як "Endpoints" та "Services", які мають конкретні конотації Kubernetes) мережею. NetworkPolicies – застосовується до зʼєднання з Pod на одному або обох кінцях і не має відношення до інших зʼєднань.

Метрики для компонентів системи Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Метрики системних компонентів можуть краще показати, що відбувається всередині. Метрики особливо корисні для побудови інформаційних панелей та сповіщень.

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

Метрики в Kubernetes

У більшості випадків метрики доступні на точці доступу /metrics HTTP сервера. Для компонентів, які типово не показують цю точку, її можна активувати за допомогою прапорця --bind-address.

Налаштування високодоступного кластера etcd за допомогою kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

Типово kubeadm запускає локальний екземпляр etcd на кожному вузлі панелі управління. Також можливо розглядати кластер etcd як зовнішній та розгортати екземпляри etcd на окремих хостах. Відмінності між цими підходами описано на сторінці Варіанти топології високої доступності.

Це завдання описує процес створення зовнішнього кластера etcd з високою доступністю, що складається з трьох членів, який може використовуватися kubeadm під час створення кластера.

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

У вас повинні бути такі ресурси:

Налаштування користувача для kubectl (kuberc)

Mon, 01 Jan 0001 00:00:00 +0000

СТАН ФУНКЦІОНАЛУ: Kubernetes 1.34 [beta]

Файл конфігурації Kubernetes kuberc дозволяє вам визначити параметри для kubectl, такі як стандартні параметри та аліаси команд. На відміну від файлу kubeconfig, файл конфігурації kuberc не містить відомостей про кластер, імен користувачів або паролів.

В Linux/POSIX системах стандартне розташування цього файлу конфігурації — $HOME/.kube/kuberc. У Windows стадартний шлях подібний до %USERPROFILE%\.kube\kuberc. Ви можете вказати kubectl, щоб він шукав конфігурацію в іншому шляху, використовуючи аргумент командного рядка --kuberc. Ви також можете встановити змінну середовища KUBERC.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

kube-scheduler — стандартний планувальник для Kubernetes. Він відповідає за розміщення Podʼів на вузлах кластера.

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

Налаштування служби Konnectivity

Mon, 01 Jan 0001 00:00:00 +0000

Служба Konnectivity надає проксі на рівні TCP для комунікації між панеллю управління та кластером.

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

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

Налаштування служби Konnectivity

Для виконання наступних кроків потрібна конфігурація egress, наприклад:

Написання нової теми

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як створити нову тему для документації Kubernetes.

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

Створіть форк репозиторію документації Kubernetes, як описано в розділі Створення PR.

Вибір типу сторінки

Перед тим, як почати писати нову тему, подумайте про тип сторінки, який найкраще підходить для вашого контенту:

Керівництво з вибору типу сторінки
Тип	Опис
Concept	Сторінка концепту пояснює певний аспект Kubernetes. Наприклад, сторінка концепту може описувати обʼєкт Kubernetes Deployment і пояснювати його роль як застосунку під час його розгортання, масштабування та оновлення. Зазвичай сторінки концептів не містять послідовностей кроків, але натомість надають посилання на завдання або підручники. Для прикладу теми концепту, див. Вузли.
Task	Сторінка завдання показує, як виконати одне конкретне завдання. Ідея полягає в тому, щоб надати читачам послідовність кроків, які вони можуть виконати під час читання сторінки. Сторінка завдання може бути короткою або довгою, за умови, що вона зосереджена на одній темі. На сторінці завдання можна поєднувати короткі пояснення з кроками, які потрібно виконати, але якщо вам потрібно надати докладне пояснення, ви повинні зробити це в темі концепту. Повʼязані теми завдань і концептів повинні посилатися одна на одну. Для прикладу короткої сторінки завдання див. Налаштування контейнера Pod для використання тому для зберігання. Для прикладу довшої сторінки завдання див. Налаштування проб для перевірки працездатності та готовності.
Tutorial	Сторінка підручника показує, як досягти мети, яка обʼєднує кілька функцій Kubernetes. Підручник може містити кілька послідовностей кроків, які читачі можуть виконувати під час читання сторінки. Або він може надавати пояснення повʼязаних фрагментів коду. Наприклад, підручник може надати покроковий огляд зразка коду. Підручник може включати короткі пояснення функцій Kubernetes, які обʼєднуються, але повинен посилатися на відповідні теми концептів для детального пояснення окремих функцій.

Створення нової сторінки

Використовуйте тип контенту для кожної нової сторінки, яку ви пишете. Сайт документації надає шаблони або Hugo archetypes для створення нових сторінок контенту. Щоб створити нову сторінку, запустіть команду hugo new з шляхом до файлу, який ви хочете створити. Наприклад:

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Поради використання Secretʼів в Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes, Secret — це обʼєкт, який зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.

Секрети дають вам більше контролю над тим, як використовується конфіденційна інформація і зменшують ризик випадкового її розголошення. Значення Secret кодуються як рядки base64 і зазвичай зберігаються в незашифрованому вигляді, але можуть бути налаштовані для шифрування в стані покою.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Примусове видалення Podʼів StatefulSet

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Міркування про StatefulSet

При нормальному функціонуванні StatefulSet ніколи немає потреби у примусовому видаленні Podʼів StatefulSet. Контролер StatefulSet відповідає за створення, масштабування та видалення членів StatefulSet. Він намагається забезпечити, щоб зазначена кількість Podʼів від ordinal 0 до N-1 були справними та готовими. StatefulSet забезпечує те, що в будь-який момент часу в кластері працює не більше одного Podʼа з заданою ідентичністю. Це називається семантикою як максимум один, яку забезпечує StatefulSet.

Розлади

Mon, 01 Jan 0001 00:00:00 +0000

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

Також це стосується адміністраторів кластера, які хочуть виконувати автоматизовані дії з кластером, такі як оновлення та автомасштабування кластерів.

Добровільні та невідворотні розлади

Podʼи не зникають, поки хтось (людина або контролер) не знищить їх, або не трапиться невідворотна помилка обладнання чи системного програмного забезпечення.

Селектори полів

Mon, 01 Jan 0001 00:00:00 +0000

Селектори полів дозволяють вам вибирати обʼєкти Kubernetes на основі значень одного або кількох полів ресурсу. Ось кілька прикладів запитань для селекторів полів:

metadata.name=my-service
metadata.namespace!=default
status.phase=Pending

Ця команда kubectl вибирає всі Podʼи, для яких значення поля status.phase дорівнює Running:

kubectl get pods --field-selector status.phase=Running

Примітка:

Селектори полів, по суті, є фільтрами ресурсів. Типово селектори/фільтри не застосовуються, а це означає, що вибрані всі ресурси вказаного типу. Це робить запити kubectl kubectl get pods та kubectl get pods --field-selector "" еквівалентними.

Підтримувані поля

Підтримувані селектори полів варіюються залежно від типу ресурсу Kubernetes. Усі типи ресурсів підтримують поля metadata.name та metadata.namespace. Використання селекторів до полів, що їх не підтримують, призводить до помилки. Наприклад:

Метрики для станів обʼєктів Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Стан обʼєктів Kubernetes у Kubernetes API може бути поданий у вигляді метрик. Агент-надбудова kube-state-metrics може підключатися до сервера Kubernetes API та надавати доступ до точки доступу з метриками, що генеруються зі стану окремих обʼєктів у кластері. Він надає різні дані про стан обʼєктів, такі як мітки та анотації, час запуску та завершення, статус або фазу, в яких обʼєкт знаходиться зараз. Наприклад, контейнери, що працюють у Podʼах, створюють метрику kube_pod_container_info. Вона включає імʼя контейнера, імʼя Podʼа, до якого він належить, простір імен, в якому працює Pod, імʼя образу контейнера, ідентифікатор образу, імʼя образу з опису контейнера, ідентифікатор працюючого контейнера та ідентифікатор Podʼа як мітки.

Посібник з запуску контейнерів Windows у Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає покроковий опис, які ви можете виконати, щоб запустити контейнери Windows за допомогою Kubernetes. На сторінці також висвітлені деякі специфічні для Windows функції в Kubernetes.

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

Цілі

Налаштувати приклад розгортання для запуску контейнерів Windows на вузлі з операційною системою Windows.

Управління ресурсами для вузлів Windows

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає огляд різниці у способах управління ресурсами між Linux та Windows.

На Linux-вузлах використовуються cgroups як межа Pod для керування ресурсами. Контейнери створюються в межах цих груп для ізоляції мережі, процесів та файлової системи. API cgroup для Linux може використовуватися для збору статистики використання процесора, введення/виведення та памʼяті.

CronJob

Mon, 01 Jan 0001 00:00:00 +0000

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

CronJob створює Jobs за повторюваним графіком.

CronJob призначений для виконання регулярних запланованих дій, таких як резервне копіювання, генерація звітів та інше. Один обʼєкт CronJob подібний до одного рядка файлу crontab (таблиця cron) на системі Unix. Він запускає Job періодично за заданим графіком, записаним у форматі Cron.

У CronJob є обмеження та особливості. Наприклад, в певних обставинах один CronJob може створювати кілька одночасних Jobs. Див. обмеження нижче.

DNS для Service та Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes створює DNS-записи для Service та Podʼів. Ви можете звертатися до Service за допомогою стійких імен DNS замість IP-адрес.

Kubernetes публікує інформацію про Podʼи та Serviceʼи, яка використовується для налаштування DNS. Kubelet конфігурує DNS Podʼів так, щоб запущені контейнери могли знаходити Service за іменем, а не за IP.

Service, визначеним у кластері, призначаються імена DNS. Типово список пошуку DNS клієнта Pod включає власний простір імен Pod та стандартний домен кластера.

kubeadm version

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Ця команда виводить версію kubeadm.

kubeadm version [flags]

Параметри

-h, --help
	довідка version
-o, --output string
	Формат виводу; доступні варіанти: 'yaml', 'json' та 'short'

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Kubelet Systemd Watchdog

Mon, 01 Jan 0001 00:00:00 +0000

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

На вузлах Linux, Kubernetes 1.35 підтримує інтеграцію з systemd, щоб дозволити супервізору операційної системи відновити несправний kubelet. Стандартно цю інтеграцію не увімкнено. Її можна використовувати як альтернативу періодичним запитам до точки доступу kubelet /healthz для перевірки працездатності. Якщо протягом тайм-ауту kubelet не відповість на запит сторожового таймера, сторожовий таймер вбʼє kubelet.

Сторожовий таймер systemd працює, вимагаючи від сервісу періодично надсилати сигнал keep-alive процесу systemd. Якщо сигнал не отримано протягом визначеного тайм-ауту, служба вважається такою, що не реагує, і припиняє свою роботу. Після цього службу можна перезапустити відповідно до конфігурації.

Seccomp та Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Seccomp (secure computing mode) — це функція ядра Linux, яка існує з версії 2.6.12. Її можна використовувати для обмеження привілеїв процесу шляхом ізоляції, обмежуючи системні виклики, які він може здійснювати з простору користувача в ядро. Kubernetes дозволяє автоматично застосовувати профілі seccomp, завантажені на вузол, до ваших Podʼів і контейнерів.

Поля Seccomp

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

Існує чотири способи вказати профіль seccomp для Podʼа:

Автоматичне масштабування служби DNS в кластері

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як увімкнути та налаштувати автоматичне масштабування служби DNS у вашому кластері Kubernetes.

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

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

Випуск сертифіката для клієнта Kubernetes API за допомогою CertificateSigningRequest

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes дозволяє використовувати інфраструктуру відкритих ключів (PKI) для автентифікації у кластері в якості клієнта.

Для того, щоб звичайний користувач міг автентифікуватися і викликати API, потрібно виконати кілька кроків. По-перше, цей користувач повинен мати сертифікат X.509, виданий органом, якому довіряє ваш кластер Kubernetes. Потім клієнт повинен предʼявити цей сертифікат API Kubernetes.

Ви використовуєте запит CertificateSigningRequest як частину цього процесу, і ви або інша довірена особа маєте схвалити запит.

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

Завершувачі

Mon, 01 Jan 0001 00:00:00 +0000

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

Мультиорендність

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає огляд наявних параметрів конфігурації та найкращих практик для мультиорендності (multi-tenancy) кластера.

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

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Налаштування кожного kubelet у кластері за допомогою kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

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

Життєвий цикл інструменту командного рядка kubeadm не повʼязаний з kubelet, який є службою, що працює на кожному вузлі в кластері Kubernetes. Інструмент командного рядка kubeadm запускається користувачем під час ініціалізації або оновлення Kubernetes, тоді як kubelet завжди працює в фоновому режимі.

Обсяг сховища

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Пакування ресурсів

Mon, 01 Jan 0001 00:00:00 +0000

У scheduling-plugin NodeResourcesFit kube-scheduler є дві стратегії оцінювання, які підтримують пакування ресурсів: MostAllocated та RequestedToCapacityRatio.

Включення пакування ресурсів за допомогою стратегії MostAllocated

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

Щоб встановити стратегію MostAllocated для втулка NodeResourcesFit, використовуйте конфігурацію планувальника подібну до наступної:

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
 - args:
 scoringStrategy:
 resources:
 - name: cpu
 weight: 1
 - name: memory
 weight: 1
 - name: intel.com/foo
 weight: 3
 - name: intel.com/bar
 weight: 3
 type: MostAllocated
 name: NodeResourcesFit

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

Системні логи

Mon, 01 Jan 0001 00:00:00 +0000

Логи компонентів системи фіксують події, які відбуваються в кластері, що може бути дуже корисним для налагодження. Ви можете налаштувати рівень деталізації логів, щоб бачити більше або менше деталей. Логи можуть бути настільки грубими, що вони показують лише помилки у компоненті, або настільки дрібними, що вони показують крок за кроком слідування за подіями (наприклад, логи доступу HTTP, зміни стану події, дії контролера або рішення планувальника).

Попередження:

На відміну від описаних тут прапорців командного рядка, вивід логу сам по собі не підпадає під гарантії стійкості API Kubernetes: окремі записи логу та їх форматування можуть змінюватися від одного релізу до наступного!

Klog

klog — це бібліотека реєстрації подій для системних компонентів Kubernetes. klog генерує повідомлення логу для системних компонентів Kubernetes.

Стан вузла

Mon, 01 Jan 0001 00:00:00 +0000

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

Поля стану вузла

Стан вузла містить наступну інформацію:

Адреси
Стани
Місткість та Доступність
Інформація
Оголошені Функції

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

kubectl describe node <insert-node-name-here>

Кожен розділ вихідних даних описано нижче.

Адреси

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

Створення зовнішнього балансувальника навантаження

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Типи контенту сторінок

Mon, 01 Jan 0001 00:00:00 +0000

Документація Kubernetes містить кілька типів контенту сторінок:

Concept (Концепт)
Task (Завдання)
Tutorial (Посібник)
Reference (Довідка)

Розділи контенту

Кожен тип контенту сторінок містить кілька розділів, визначених коментарями Markdown і HTML-заголовками. Ви можете додати заголовки контенту до вашої сторінки за допомогою shortcode heading. Коментарі та заголовки допомагають підтримувати структуру типів контенту сторінок.

Приклади коментарів Markdown, що визначають розділи контенту сторінки:

<!-- overview -->

<!-- body -->

Щоб створити загальні заголовки на ваших контентних сторінках, використовуйте body heading із рядком заголовка.

Управління сертифікатами з kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Ви повинні бути знайомі з сертифікатами PKI та вимогами Kubernetes.

Імʼя хосту Podʼа

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює, як встановити ім'я хосту Podʼа, можливі побічні ефекти після налаштування та механізми, що лежать в основі.

Стандартне імʼя хосту Podʼа

Коли створюється Pod, імʼя його хосту (яке спостерігається зсередини Podʼа) походить від значення metadata.name Podʼа. І імʼя хосту, і відповідне повністю кваліфіковане доменне імʼя (FQDN) встановлюються зі значення metadata.name (з точки зору Podʼа)

apiVersion: v1
kind: Pod
metadata:
 name: busybox-1
spec:
 containers:
 - image: busybox:1.28
 command:
 - sleep
 - "3600"
 name: busybox

Pod, створений цим маніфестом, матиме імʼя хосту та повністю кваліфіковане доменне імʼя (FQDN) встановлені як busybox-1.

Класи якості обслуговування (Quality of Service) Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка вводить класи обслуговування (Quality of Service, QoS) в Kubernetes та пояснює, як Kubernetes присвоює кожному Podʼа клас QoS як наслідок обмежень ресурсів, які ви вказуєте для контейнерів у цьому Podʼі. Kubernetes покладається на цю класифікацію для прийняття рішень про те, які Podʼи виводити при відсутності достатньої кількості ресурсів на вузлі.

Класи обслуговування (QoS)

Kubernetes класифікує Podʼи, які ви запускаєте, і розподіляє кожен Pod в певний клас обслуговування (Quality of Service, QoS). Kubernetes використовує цю класифікацію для впливу на те, як різні Podʼи обробляються. Kubernetes робить цю класифікацію на основі резервів ресурсів контейнерів у цьому Podʼі, а також того, як ці резерви стосуються обмежень ресурсів. Це відомо як клас обслуговування (Quality of Service, QoS). Kubernetes присвоює кожному Podʼу клас QoS на основі запитів та лімітів ресурсів його складових контейнерів. Класи QoS використовуються Kubernetes для вирішення того, які Podʼи виводити з вузла, який переживає високий тиск на вузол. Можливі класи QoS: Guaranteed, Burstable та BestEffort.

kubeadm alpha

Mon, 01 Jan 0001 00:00:00 +0000

Увага:

kubeadm alpha надає попередній перегляд набору функцій, які стануть доступними для збору відгуків від спільноти. Будь ласка, спробуйте його та надайте нам відгук!

Наразі в kubeadm alpha немає експериментальних команд.

Що далі

kubeadm init для створення вузла панелі управління Kubernetes
kubeadm join для підключення вузла до кластера
kubeadm reset для скасування будь-яких змін, внесених на хості за допомогою kubeadm init або kubeadm join

kubeadm certs

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm certs надає утиліти для керування сертифікатами. Для отримання детальної інформації про використання цих команд, дивіться Керування сертифікатами за допомогою kubeadm.

kubeadm certs

Збірка операцій для роботи з сертифікатами Kubernetes.

огляд

Опис

Команди, повʼязані з обробкою сертифікатів Kubernetes

kubeadm certs [command]

Параметри

-h, --help
	довідка certs

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm init phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm init phase дозволяє вам викликати атомарні кроки процесу початкового завантаження. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви можете заповнити прогалини якщо ви бажаєте застосувати кастомізацію.

kubeadm init phase узгоджується з kubeadm init workflow, і за лаштунками обидва використовують той самий код.

kubeadm init phase preflight

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

preflight

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm join phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm join phase дозволяє викликати атомарні кроки процесу приєднання. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви заповните прогалини, якщо захочете застосувати налаштування.

kubeadm join phase узгоджується з workflow приєднання kubeadm, і за лаштунками обидва використовують той самий код.

kubeadm join phase

phase

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу "join"

kubeadm join phase [flags]

Параметри

-h, --help

Довідка phase

kubeadm kubeconfig

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm kubeconfig надає інструменти для управління файлами kubeconfig.

Приклади використання kubeadm kubeconfig user дивіться в розділі Генерація файлів kubeconfig для додаткових користувачів.

kubeadm kubeconfig

overview

Опис

Файлові утиліти Kubeconfig.

Параметри

-h, --help
	Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

kubeadm reset phase

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm reset phase дозволяє вам викликати атомарні кроки процесу reset. Таким чином, ви можете дозволити kubeadm виконати частину роботи, а ви можете заповнити прогалини якщо ви бажаєте застосувати кастомізацію.

kubeadm reset phase узгоджується з kubeadm reset workflow, і за лаштунками обидва використовують той самий код.

kubeadm reset phase

phase

Опис

Використовуйте цю команду для виклику однієї фази процесу "reset"

kubeadm reset phase [flags]

Параметри

-h, --help

Довідка phase

ReplicationController

Mon, 01 Jan 0001 00:00:00 +0000

Примітка:

Deployment, який налаштовує ReplicaSet, тепер є рекомендованим способом налаштування реплікації.

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

Як працює ReplicationController

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

Власники та Залежності

Mon, 01 Jan 0001 00:00:00 +0000

В Kubernetes деякі обʼєкти є власниками інших обʼєктів. Наприклад, ReplicaSet є власником групи Podʼів. Ці обʼєкти, якими володіють, є залежними від свого власника.

Власність відрізняється від механізму міток та селекторів, який також використовують деякі ресурси. Наприклад, розгляньте Service, який створює обʼєкти EndpointSlice. Service використовує мітки щоби панель управління могла визначити, які обʼєкти EndpointSlice використовуються для цього Service. Крім того, до міток, кожен EndpointSlice, який керується від імені Service, має посилання на власника. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують.

Генерація документації для команд kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як згенерувати довідкову документацію для команд kubectl.

Примітка:

Ця тема показує, як згенерувати довідкову документацію для команд kubectl таких як kubectl apply та kubectl taint. Ця тема не показує, як згенерувати сторінку довідки для опцій kubectl. Для інструкцій про те, як згенерувати довідкову сторінку опцій kubectl, дивіться Генерація довідкових сторінок для компонентів та інструментів Kubernetes.

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

Вимоги:

Вам потрібна машина, що працює під управлінням Linux або macOS.

Зміна режиму доступу до PersistentVolume на ReadWriteOncePod

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як змінити режим доступу наявного PersistentVolume на ReadWriteOncePod.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Обмеження томів на вузлі

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує максимальну кількість томів, які можна прикріпити до вузла для різних хмарних постачальників.

Хмарні постачальники, такі як Google, Amazon і Microsoft, зазвичай мають обмеження на те, скільки томів можна прикріпити до вузла. Важливо, щоб Kubernetes дотримувався цих обмежень. В іншому випадку Podʼи, заплановані на вузлі, можуть застрягти в очікуванні прикріплення томів.

Типові обмеження Kubernetes

У планувальнику Kubernetes є типові обмеження на кількість томів, які можна прикріпити до вузла:

Організація контенту

Mon, 01 Jan 0001 00:00:00 +0000

Цей сайт використовує Hugo. В Hugo організація контенту є основним концептом.

Примітка:

Порада Hugo: Запускайте Hugo за допомогою hugo server --navigateToChanged для редагування контенту.

Списки сторінок

Порядок сторінок

Бічне меню документації, оглядач сторінок документації тощо формуються за допомогою стандартного порядку сортування Hugo, який сортує за вагою (починаючи з 1), датою (новіші перші), і нарешті за заголовком посилання.

Щоб перемістити сторінку або розділ вверх, задайте вагу у front matter сторінки:

Переконфігурація кластера за допомогою kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm не підтримує автоматизованих способів переконфігурації компонентів, що були розгорнуті на керованих вузлах. Один зі способів автоматизації цього — використання власного оператора.

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

Цей посібник показує правильну послідовність кроків, які потрібно виконати для досягнення переконфігурації кластера kubeadm.

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

Вам потрібен кластер, що був розгорнутий за допомогою kubeadm.
У вас мають бути адміністративні облікові дані (/etc/kubernetes/admin.conf) та мережеве зʼєднання з робочим kube-apiserver у кластері з хосту, на якому встановлено kubectl.
Мати текстовий редактор встановлений на всіх хостах.

Переконфігурація кластера

kubeadm записує набір параметрів конфігурації компонентів на рівні кластера у ConfigMaps та в інших обʼєктах. Ці обʼєкти потрібно редагувати вручну. Команда kubectl edit може бути використана для цього.

Подвійний стек IPv4/IPv6

Mon, 01 Jan 0001 00:00:00 +0000

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

Двостекова мережа IPv4/IPv6 дозволяє виділяти як адреси IPv4, так і IPv6 для Podʼів та Serviceʼів.

Двостекова мережа IPv4/IPv6 є стандартно увімкненою у вашому кластері Kubernetes починаючи з версії 1.21, що дозволяє одночасно призначати адреси як IPv4, так і IPv6.

Поради з посилення безпеки — Механізми автентифікації

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Посилання на Workload

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Визначення посилання на робоче навантаження

Коли функція GenericWorkload увімкнена, ви можете використовувати поле spec.workloadRef у маніфесті Podʼа. Це поле встановлює посилання на конкретну групу Podʼів, визначену в ресурсі Workload в тому ж просторі імен.

Посібник із зміцнення безпеки — Налаштування планувальника

Mon, 01 Jan 0001 00:00:00 +0000

Планувальник у Kubernetes є одним з найважливіших компонентів панелі управління.

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

Неправильно налаштований планувальник може мати наслідки для безпеки. Такий планувальник може вражати певні вузли і виселяти робочі навантаження або програми, які спільно використовують вузол та його ресурси. Це може допомогти зловмиснику провести Yo-Yo атаку: атаку на вразливий автопланувальник.

Пріоритет та Випередження Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Попередження:

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

Ризики обходу сервера API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Сервер API Kubernetes є головним входом до кластера для зовнішніх сторін (користувачів та сервісів), що з ним взаємодіють.

У рамках цієї ролі сервер API має кілька ключових вбудованих елементів безпеки, таких як аудит логів та контролери допуску. Однак існують способи модифікації конфігурації або вмісту кластера, які обминають ці елементи.

Ця сторінка описує способи обходу вбудованих в сервер API Kubernetes засобів контролю безпеки, щоб оператори кластера та архітектори безпеки могли переконатися, що ці обхідні механізми адекватно обмежені.

Трейси для системних компонентів Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Трейси системних компонентів реєструють затримку та звʼязки між операціями у кластері.

Компоненти Kubernetes відправляють трейси за допомогою Протоколу OpenTelemetry з експортером gRPC і можуть бути зібрані та направлені до різних систем відслідковування за допомогою OpenTelemetry Collector.

Збір трейсів

Компоненти Kubernetes мають вбудовані експортери gRPC для OTLP для експорту трейсів, або через OpenTelemetry Collector, або без нього.

Для повного посібника зі збору трейсів та використання колектора див. Початок роботи з OpenTelemetry Collector. Однак є кілька речей, на які варто звернути увагу, що є специфічними для компонентів Kubernetes.

Зміна типового StorageClass

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як змінити типовий StorageClass, який використовується для створення томів для PersistentVolumeClaims, які не мають особливих вимог.

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

Перехід від опитування до оновлення стану контейнера на основі подій CRI

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка показує, як мігрувати вузли для використання оновлення стану контейнера на основі подій. Реалізація на основі подій зменшує використання ресурсів вузла kubeletʼом порівняно зі старим підходом, який ґрунтується на опитуванні. Ви можете знати цю функцію як evented Pod lifecycle event generator (PLEG). Це назва, яка використовується внутрішньо в проєкті Kubernetes для основних деталей реалізації.

Підхід на основі опитування відомий як generic PLEG.

Зіставлення PodSecurityPolicies зі стандартами безпеки Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

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

Для кожного параметра, до якого це застосовується, перераховані допустимі значення для Baseline та Restricted профілів. Все, що перебуває за межами допустимих значень для цих профілів, підпадає під Privileged профіль. "Немає думки" означає, що всі значення допустимі для всіх стандартів безпеки Podʼів.

Для покрокового керівництва міграції див. Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity.

Локальне тимчасове сховище

Mon, 01 Jan 0001 00:00:00 +0000

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

Podʼи використовують тимчасове локальне сховище для тимчасового простору, кешування та журналів. Kubelet може надавати тимчасовий простір для Podʼів, використовуючи локальне тимчасове сховище для монтування томів emptyDir у контейнери.

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

Виселення внаслідок тиску на вузол

Mon, 01 Jan 0001 00:00:00 +0000

Виселення через тиск на вузол — це процес, при якому kubelet активно завершує роботу Podʼів для звільнення ресурсів на вузлах.

The kubelet моніторить ресурси, такі як памʼять, простір на диску та i-nodeʼи файлової системи на вузлах вашого кластера. Коли один або декілька з цих ресурсів досягають певних рівнів використання, kubelet може проактивно припинити роботу одного або кількох Podʼів на вузлі, щоб відновити ресурси та запобігти голодуванню.

Генерація довідкової документації для метрик

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка демонструє, як згенерувати довідкову документацію для метрик.

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

Вимоги:

Вам потрібна машина, що працює під управлінням Linux або macOS.
Вам потрібно встановити ці інструменти:
- Python версії v3.7.x+
- Git
- Golang версії 1.13+
- Pip для встановлення PyYAML
- PyYAML версії v5.1.2
- make
- gcc компілятор/лінкер
- Docker (Потрібен тільки для довідки по команді kubectl)
Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.

Деталі реалізації

Mon, 01 Jan 0001 00:00:00 +0000

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

kubeadm init та kubeadm join разом забезпечують гарну послідовність дій користувача для створення базового кластера Kubernetes з нуля, відповідно до найкращих практик. Однак може бути не очевидно, як kubeadm це робить.

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

Основні принципи дизайну

Кластер, який налаштовується за допомогою kubeadm init та kubeadm join, має бути:

Зміна політики відновлення PersistentVolume

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як змінити політику відновлення PersistentVolume в Kubernetes.

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

Маршрутизація з урахуванням топології

Mon, 01 Jan 0001 00:00:00 +0000

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

Примітка:

До Kubernetes 1.27 ця функція відома як Topology Aware Hints.

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

Мотивація

Кластери Kubernetes все частіше розгортаються в багатозональних середовищах. Маршрутизацію з урахуванням топології забезпечує механізм для збереження трафіку в межах зони, з якої він походить. При розрахунку точок доступу для Service, контролер EndpointSlice враховує топологію (регіон і зону) кожної точки доступу та заповнює поле підказок для виділення її в зону. Компоненти кластера, такі як kube-proxy, можуть використовувати ці підказки для впливу на маршрутизацію трафіку (надання переваги точкам доступу, які знаходяться в топологічно ближчих зонах).

Моніторинг справності томів

Mon, 01 Jan 0001 00:00:00 +0000

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

Моніторинг справності томів CSI дозволяє драйверам CSI виявляти ненормальні умови тому у підлеглих систем збереження та повідомляти про них як події у PVCs або Podʼи.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

Примітка:

serviceAccountToken не є типом тому.

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

Обмеження безпеки ядра Linux для Podʼів та контейнерів

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує деякі з функцій безпеки, які вбудовані в ядро Linux і які ви можете використовувати у вашій роботі з Kubernetes. Щоб дізнатися, як застосувати ці функції до ваших Podʼів та контейнерів, див. Налаштування контексту безпеки для Podʼа або контейнера. Ви вже маєте бути знайомі з Linux та основами роботи з робочими навантаженням Kubernetes.

Запуск робочих навантажень без привілеїв адміністратора

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

Отримання переліку всіх образів контейнерів, що працюють у кластері

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Підтримка подвійного стека за допомогою kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

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

Ваш кластер Kubernetes має мережу з підтримкою подвійного стека, що означає, що у кластері мережева взаємодія може використовувати обидві адресні родини. У кластері панель управління може призначити як IPv4-адреси, так і IPv6-адреси Podʼу чи Service.

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

Вам потрібно встановити інструмент kubeadm, дотримуючись кроків з Встановлення kubeadm.

Покрокове керівництво HorizontalPodAutoscaler

Mon, 01 Jan 0001 00:00:00 +0000

HorizontalPodAutoscaler (HPA) автоматично оновлює ресурс робочого навантаження (наприклад, Deployment або StatefulSet), з метою автоматичного масштабування робочого навантаження, щоб відповідати попиту.

Горизонтальне масштабування означає, що відповідь на збільшене навантаження полягає в розгортанні додаткових Podʼів. Це відрізняється від вертикального масштабування, що для Kubernetes означає призначення додаткових ресурсів (наприклад: памʼять або CPU) для Podʼів, які вже працюють для робочого навантаження.

Проксі у Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці пояснюються проксі, що використовуються з Kubernetes.

Проксі

У вас можуть зустрітися декілька різних проксі, коли ви використовуєте Kubernetes:

Проксі kubectl:
- працює на робочому столі користувача або в контейнері
- забезпечує проксі з локальної адреси до apiserver Kubernetes
- клієнт до проксі використовує HTTP
- проксі до apiserver використовує HTTPS
- знаходить apiserver
- додає заголовки автентифікації
Проксі apiserver:
- є бастіоном, вбудованим в apiserver
- зʼєднує користувача поза кластером з IP-адресами кластера, які інакше можуть бути недоступними
- працює в процесах apiserver
- клієнт до проксі використовує HTTPS (або http, якщо apiserver налаштовано так)
- проксі до цілі може використовувати HTTP або HTTPS, як вибрав проксі за наявною інформацією
- може бути використаний для доступу до Node, Pod або Service
- виконує балансування навантаження при використанні для доступу до Service
kube proxy:

Розширена участь

Mon, 01 Jan 0001 00:00:00 +0000

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

Пропонування покращень

Члени SIG Docs можуть пропонувати покращення.

Після того, як ви вже деякий час вносите зміни в документацію Kubernetes, у вас можуть зʼявитися ідеї щодо покращення настанов зі стилю, настанов з контенту, інструментів, які використовуються для створення документації, стилю вебсайту, процесів перевірки та злиття pull request-ів, або інших аспектів документації. Для забезпечення максимальної прозорості ці пропозиції повинні обговорюватися на зустрічі SIG Docs або у списку розсилки kubernetes-sig-docs. Крім того, корисно мати певний контекст щодо того, як все зараз працює і чому в минулому були прийняті певні рішення, перш ніж пропонувати кардинальні зміни. Найшвидший спосіб отримати відповіді на запитання про те, як працює документація, — запитати в каналі #sig-docs на kubernetes.slack.com.

Список перевірок безпеки

Mon, 01 Jan 0001 00:00:00 +0000

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

Як користуватись цим документом:

Порядок тем не відображає порядок пріоритетів.
Деякі пункти списку розкриваються в абзац нижче переліку кожної секції.

Увага:

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

Автентифікація та авторизація

Група system:masters не використовується для автентифікації користувачів чи компонентів після першого налаштування.
Компонент kube-controller-manager працює з увімкненим параметром --use-service-account-credentials.
Кореневий сертифікат захищений (або офлайн CA, або керований онлайн CA з ефективними елементами керування доступом).
Проміжний та листовий сертифікати мають строк дії не більше ніж 3 роки вперед.
Існує процес періодичного перегляду доступу, і перегляди проводяться не рідше ніж через кожні 24 місяці.
Дотримуються рекомендації щодо контролю доступу на основі ролей щодо автентифікації та авторизації.

Після початкового налаштування ні користувачі, ні компоненти не повинні автентифікуватися в API Kubernetes як system:masters. Так само, варто уникати використання всіх компонентів kube-controller-manager як system:masters. Фактично, system:masters повинен використовуватися лише як механізм для виходу з аварійної ситуації, а не як адміністративний користувач.

API Priority та Fairness

Mon, 01 Jan 0001 00:00:00 +0000

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

Контроль поведінки сервера API Kubernetes у ситуації перевантаження є основним завданням для адміністраторів кластера. У kube-apiserver є деякі елементи керування (тобто прапорці командного рядка --max-requests-inflight та --max-mutating-requests-inflight), щоб обмежити обсяг невиконаної роботи, яка буде прийнята, запобігаючи перевантаженню потоку вхідних запитів та потенційному збою сервера API, але цих прапорців недостатньо для забезпечення проходження найважливіших запитів у період високого навантаження.

Автентифікація/авторизація kubelet

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

HTTP-запити до HTTPS-точки доступу kubelet надають доступ до даних різного рівня чутливості та дозволяють виконувати операції з різними рівнями повноважень на вузлі та в контейнерах.

У цьому документі описано, як автентифікувати та авторизувати доступ до HTTPS-точки доступу kubelet.

Автентифікація kubelet

Стандартно запити до HTTPS-точки доступу kubelet, які не відхилені іншими налаштованими методами автентифікації, розглядаються як анонімні запити та отримують імʼя користувача system:anonymous та групу system:unauthenticated.

Щоб вимкнути анонімний доступ та надсилати відповіді 401 Unauthorized на невідомі запити:

Адміністрування менеджера хмарного контролера

Mon, 01 Jan 0001 00:00:00 +0000

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

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

cloud-controller-manager може бути повʼязаний з будь-яким хмарним провайдером, який відповідає вимогам cloudprovider.Interface. Для забезпечення зворотної сумісності, cloud-controller-manager, що постачається у складі основного проєкту Kubernetes, використовує ті ж хмарні бібліотеки, що і kube-controller-manager. Очікується, що хмарні постачальники, які вже підтримуються у ядрі Kubernetes, використовуватимуть вбудований cloud-controller-manager для передачі даних з ядра Kubernetes.

Версії зберігання

Mon, 01 Jan 0001 00:00:00 +0000

Сервер API Kubernetes зберігає обʼєкти, використовуючи бекенд etcd-сумісного сховища (часто, сховище є самим etcd). Кожен обʼєкт серіалізується за допомогою певної версії типу API; наприклад, представлення v1 ConfigMap. Kubernetes використовує термін версія зберігання для опису того, як зберігається обʼєкт у вашому кластері.

API Kubernetes також покладається на автоматичне перетворення; наприклад, якщо у вас є HorizontalPodAutoscaler, то ви можете взаємодіяти з цим HorizontalPodAutoscaler, використовуючи будь-яку комбінацію версій v1 та v2 API HorizontalPodAutoscaler. Kubernetes відповідає за перетворення кожного API-запиту, щоб клієнти не бачили, яка версія насправді серіалізується.

Виселення, ініційоване API

Mon, 01 Jan 0001 00:00:00 +0000

Виселення, ініційоване API — процес, під час якого використовується Eviction API для створення обʼєкта Eviction, який викликає належне завершення роботи Podʼа.

Ви можете ініціювати виселення, викликавши Eviction API безпосередньо або програмно, використовуючи клієнт API-сервера, наприклад, команду kubectl drain. Це створює обʼєкт Eviction, що призводить до завершення роботи Podʼа через API-сервер.

Виселення ініційовані API дотримуються вашого налаштованого PodDisruptionBudgets та terminationGracePeriodSeconds.

Використання API для створення обʼєкта Eviction для Podʼа схоже на виконання контрольованої політикою операції DELETE на Podʼі.

Вказання бюджету розладів для вашого застосунку

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Версія вашого Kubernetes сервера має бути не старішою ніж v1.21.

Для перевірки версії введіть kubectl version.

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

Захист застосунку за допомогою PodDisruptionBudget

Визначте, який застосунок ви хочете захистити за допомогою PodDisruptionBudget (PDB).
Подумайте про те, як ваш застосунок реагує на розлади.
Створіть визначення PDB у вигляді файлу YAML.
Створіть обʼєкт PDB з файлу YAML.

Визначення застосунку для захисту

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

Зберігання у Windows

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає огляд зберігання, специфічного для операційної системи Windows.

Постійне зберігання

У Windows є багатошаровий файловий драйвер для монтування контейнерних шарів і створення копії файлової системи на основі NTFS. Всі шляхи файлів у контейнері вирішуються лише в межах контексту цього контейнера.

У Docker монтування томів може бути спрямоване лише на теку у контейнері, а не на окремий файл. Це обмеження не стосується containerd.
Монтування томів не може проєцювати файли або теки на файлову систему хосту.
Файлові системи тільки-читання не підтримуються, оскільки завжди потрібен доступ для запису до реєстру Windows та бази даних SAM. Однак томи тільки-читання підтримуються.
Маски користувача і дозволи для томів недоступні. Оскільки SAM не спільний між хостом і контейнером, немає зіставлення між ними. Всі дозволи вирішуються в межах контексту контейнера.

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

Мережеві аспекти Windows

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes підтримує використання як вузлів Linux, так і Windows, і можливе одночасне використання обох типів вузлів у межах одного кластеру. Ця сторінка надає огляд мережевих аспектів, специфічних для операційної системи Windows.

Мережева взаємодія контейнерів у Windows

Мережевий стек для контейнерів у Windows використовує CNI-втулки. Контейнери у Windows працюють схоже до віртуальних машин з погляду мережі. Кожен контейнер має віртуальний мережевий адаптер (vNIC), який підключений до віртуального комутатора Hyper-V (vSwitch). Host Networking Service (HNS) та Host Compute Service (HCS) спільно працюють для створення контейнерів і підключення віртуальних мережевих адаптерів контейнера до мереж. HCS відповідає за управління контейнерами, тоді як HNS відповідає за управління ресурсами мережі, такими як:

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

Mon, 01 Jan 0001 00:00:00 +0000

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

Дискреційний контроль доступу: Дозвіл на доступ до обʼєкта, такого як файл, базується на ідентифікаторі користувача (UID) та ідентифікаторі групи (GID).
Security Enhanced Linux (SELinux): Обʼєкти призначаються мітки безпеки.
Виконання з привілеями або без них.
Linux Capabilities: Надає процесу деякі привілеї, але не всі привілеї користувача root.
AppArmor: Використовуйте профілі програм для обмеження можливостей окремих програм.

Поведінка свопу на вузлах Linux

Mon, 01 Jan 0001 00:00:00 +0000

Щоб дозволити робочим навантаженням Kubernetes використовувати своп, на вузлі Linux необхідно вимкнути стандартну поведінку kubelet, яка полягає в тому, що kubelet зазнає невдачі при виявленні свопу, та вказати поведінку memory-swap як LimitedSwap:

Доступні варіанти поведінки свопу:

NoSwap: (стандартно) Робочі навантаження, що виконуються як Podʼи на цьому вузлі, не використовують і не можуть використовувати своп. Однак процеси поза межами Kubernetes, такі як системні демони (включаючи сам kubelet!), можуть використовувати своп. Така поведінка є корисною для захисту вузла від стрибків памʼяті на системному рівні, але вона не захищає самі робочі навантаження від таких стрибків.
LimitedSwap: Робочі навантаження Kubernetes можуть використовувати своп-памʼять. Обсяг своп, доступний для Podʼа, визначається автоматично.

Щоб дізнатися більше, прочитайте керування своп-памʼяттю.

Список перевірки безпеки застосунків

Mon, 01 Jan 0001 00:00:00 +0000

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

Як читати та використовувати цей документ:

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

Увага:

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

Базове посилення безпеки

Наведений нижче список містить рекомендації з базового посилення безпеки, які можуть застосовуватися до більшості застосунків, що розгортаються в Kubernetes.

Виділення IP-адрес ClusterIP Serviceʼам

Mon, 01 Jan 0001 00:00:00 +0000

У Kubernetes Service — це абстракція для експозиції застосунку, який працює на наборі Podʼів. Serviceʼи можуть мати віртуальну IP-адресу, доступну на рівні кластера (за допомогою Service з type: ClusterIP). Клієнти можуть підключатися за допомогою цієї віртуальної IP-адреси, і Kubernetes балансує трафік до цього Service між його Podʼами.

Як виділяються IP-адреси ClusterIP Сервісу?

Коли Kubernetes потрібно призначити віртуальну IP-адресу для Service, це відбувається одним із двох способів:

Власні shortcodes Hugo

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює, як використовувати shortcodes Hugo в документації Markdown для Kubernetes.

Детальніше про shortcodes можна дізнатися в документації Hugo.

Стан функції

На сторінці Markdown (.md файл) на цьому сайті ви можете додати shortcodes для відображення версії та стану документованої функції.

Демонстрація стану функції

Нижче наведено демонстрацію фрагмента стану функції, який відображає функцію як стабільну в останній версії Kubernetes.

{{< feature-state state="stable" >}}

Показується як:

Генерація довідкових сторінок для компонентів та інструментів Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як створювати довідкові сторінки для компонентів та інструментів Kubernetes.

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

Розпочніть з розділу Передумови у довідковому посібнику Quickstart для генерування документації.

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

Що далі

Налаштування постачальника облікових даних образів в kubelet

Mon, 01 Jan 0001 00:00:00 +0000

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

Починаючи з Kubernetes v1.20, kubelet може динамічно отримувати облікові дані для реєстру образів контейнерів за допомогою використання втулків. Kubelet та втулок спілкуються через stdio (stdin, stdout та stderr), використовуючи версійні API Kubernetes. Ці втулки дозволяють kubelet запитувати облікові дані для реєстру контейнерів динамічно, на відміну від зберігання статичних облікових даних на диску. Наприклад, втулок може звертатися до локального сервера метаданих, щоб отримати облікові дані з обмеженим терміном дії для образу, який завантажується kubelet.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Отримання доступу до API Kubernetes з Pod

Mon, 01 Jan 0001 00:00:00 +0000

Цей посібник демонструє, як отримати доступ до API Kubernetes з середини Pod.

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

Перегляд аналітики сайту

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка містить інформацію про інформаційну аналітичну панель kubernetes.io.

Переглянути панель.

Ця панель побудована за допомогою Google Looker Studio та відображає інформацію, зібрану на kubernetes.io за допомогою Google Analytics 4 з серпня 2022 року.

Використання панелі

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

Політики внутрішнього трафіку Service

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Використання політики внутрішнього трафіку Service

Ви можете увімкнути політику тільки для внутрішнього трафіку для Service, встановивши його .spec.internalTrafficPolicy в Local. Це вказує kube-proxy використовувати лише вузлові локальні endpoint для внутрішнього трафіку кластера.

Початкове завантаження TLS

Mon, 01 Jan 0001 00:00:00 +0000

У кластері Kubernetes компоненти на вузлах робочих навантажень, kubelet та kube-proxy, повинні взаємодіяти з компонентами панелі управління Kubernetes, зокрема з kube-apiserver. Для забезпечення приватності комунікації, її невтручання та переконання, що кожен компонент кластера спілкується з іншим довіреним компонентом, ми наполегливо рекомендуємо використовувати TLS-сертифікати клієнтів на вузлах.

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

Спілкування між контейнерами в одному Podʼі за допомогою спільного тому

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Керування потоком

Mon, 01 Jan 0001 00:00:00 +0000

API Priority and Fairness контролює поведінку сервера API Kubernetes у ситуації перевантаження. Ви можете знайти більше інформації про нього у розділі API Priority & Fairness документації.

Діагностика

Кожна відповідь HTTP від API-сервера з увімкненою функцією пріоритету та справедливості має два додаткові заголовки: X-Kubernetes-PF-FlowSchema-UID та X-Kubernetes-PF-PriorityLevel-UID, які вказують на схему потоку, що відповідала запиту, та рівень пріоритету, до якого він був призначений, відповідно. Імена обʼєктів API не включені в ці заголовки (щоб уникнути розкриття деталей у випадку, якщо користувач, який робить запит, не має дозволу на їх перегляд). Під час налагодження ви можете використовувати команду:

Налаштування DNS для кластера

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes пропонує надбудову DNS для кластера, яку типово увімкнено у більшості підтримуваних середовищ. У Kubernetes версії 1.11 і пізніших версіях рекомендовано використовувати CoreDNS, який стандартно встановлюється з kubeadm.

Для отримання додаткової інформації про налаштування CoreDNS для кластера Kubernetes дивіться Налаштування DNS-сервісу.

Докладнішу інформацію про налаштування CoreDNS для кластера Kubernetes див. у розділі Налаштування служби DNS.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Отримання образів з приватного реєстру

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як створити Pod, що використовує Secret для отримання образу з приватного реєстру або сховища контейнерних образів. Існує багато приватних реєстрів, які використовуються. У цьому завданні використовується Docker Hub як приклад реєстру.

🛇 Цей елемент посилається на сторонній проєкт або продукт, який не є частиною Kubernetes. Докладніше

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

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

Доступ до Service, що працюють в кластерах

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як підʼєднатись до Serviceʼів, що працюють у кластері Kubernetes.

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

Налаштування проб життєздатності, готовності та запуску

Mon, 01 Jan 0001 00:00:00 +0000

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

Для отримання додаткової інформації про проби див. Проби життєздатності, готовності та запуску

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

Загальний шаблон для проб життєздатності — використовує ту саму недорогу HTTP-точку доступу, що й для проб готовності, але з більшим значенням failureThreshold. Це гарантує, що Pod може спостерігатись як не готовий впродовж певного часу перед тим, як примусово завершити його роботу.

Управління політиками керування ЦП на вузлі

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes зберігає багато аспектів того, як Podʼи виконуються на вузлах, абстрагованими від користувача. Це зроблено навмисно. Проте деякі завдання вимагають більших гарантій з погляду часу реакції та/або продуктивності, щоб працювати задовільно. Kubelet надає методи для включення складніших політик розміщення завдань, зберігаючи абстракцію вільною від явних директив розміщення.

Для отримання докладної інформації щодо управління ресурсами, будь ласка, зверніться до документації Управління ресурсами для Podʼів та контейнерів.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

Менеджер памʼяті Kubernetes (Memory Manager) дозволяє функцію гарантованого виділення памʼяті (та великих сторінок) для Podʼів QoS класу Guaranteed.

Менеджер памʼяті використовує протокол генерації підказок для вибору найбільш відповідної спорідненості NUMA для точки доступу. Менеджер памʼяті передає ці підказки центральному менеджеру (Менеджеру топології). На основі як підказок, так і політики Менеджера топології, Pod відхиляється або допускається на вузол.

Встановлення надбудов

Mon, 01 Jan 0001 00:00:00 +0000

Надбудови розширюють функціональність Kubernetes.

Ця сторінка містить список доступних надбудов та посилання на відповідні інструкції з встановлення. Цей список не намагається бути вичерпним.

Мережа та мережеві політики

ACI надає інтегровану мережу контейнерів та мережеву безпеку з Cisco ACI.
Antrea працює на рівні 3/4, щоб надати мережеві послуги та послуги безпеки для Kubernetes, використовуючи Open vSwitch як мережеву панель даних. Antrea є проєктом CNCF на рівні Sandbox.
Calico є постачальником мережевих послуг та послуг мережевої політики. Calico підтримує гнучкий набір мережевих опцій, щоб ви могли вибрати найефективнішу опцію для вашої ситуації, включаючи мережі з та без оверлею, з або без BGP. Calico використовує той же рушій для забезпечення мережевої політики для хостів, Podʼів та застосунків на рівні шару сервісної мережі (якщо ви використовуєте Istio та Envoy).
Canal обʼєднує Flannel та Calico, надаючи мережеві рішення та мережеву політику.
Cilium: це рішення для мережі, спостережуваності та забезпечення безпеки з eBPF-орієнтованою панеллю даних. Cilium надає просту мережу Layer 3 з можливістю охоплення декількох кластерів в режимі маршрутизації або режимі налагодження/інкапсуляції та може застосовувати політики мережі на рівнях L3-L7 з використанням моделі безпеки на основі ідентифікації, що відʼєднана від мережевого адресування. Cilium може діяти як заміна для kube-proxy; він також пропонує додаткові функції спостережуваності та безпеки. Cilium — це проєкт CNCF рівня Graduated.
CNI-Genie: Дозволяє Kubernetes безперешкодно підключатися до різних втулків CNI, таких як Calico, Canal, Flannel або Weave. CNI-Genie — це проєкт CNCF на рівні Sandbox.
Contiv: надає налаштовану мережу (L3 з використанням BGP, оверлей використовуючи vxlan, класичний L2 та Cisco-SDN/ACI) для різних варіантів використання та повнофункціональний фреймворк політик. Проєкт Contiv є проєктом з повністю відкритими сирцями. Встановлювач надає як варіанти установки, як з допомогою kubeadm, так і без.
Contrail, заснований на Tungsten Fabric, є відкритою платформою для віртуалізації багатохмарних мереж та управління політиками. Contrail і Tungsten Fabric інтегровані з системами оркестрування, такими як Kubernetes, OpenShift, OpenStack і Mesos, і забезпечують режими ізоляції для віртуальних машин, контейнерів/подів і робочих навантажень на фізичному обладнанні.
Flannel: постачальник мережі на основі оверлеїв, який можна використовувати з Kubernetes.
Gateway API: відкритий проєкт, керований SIG Network, який надає виразний, розширюваний та рольовий API для моделювання мережевих сервісів.
Knitter є втулком для підтримки кількох мережевих інтерфейсів в Podʼі Kubernetes.
Multus: мультивтулок для підтримки кількох мереж у Kubernetes для підтримки всіх втулків CNI (наприклад, Calico, Cilium, Contiv, Flannel), а також навантаження SRIOV, DPDK, OVS-DPDK та VPP у Kubernetes.
OVN-Kubernetes: постачальник мережі для Kubernetes на основі OVN (Open Virtual Network), віртуальної мережевої реалізації, яка вийшла з проєкту Open vSwitch (OVS). OVN-Kubernetes забезпечує реалізацію мережі на основі оверлеїв для Kubernetes, включаючи реалізацію балансування навантаження на основі OVS та політики мережі.
Nodus: втулок контролера CNI на основі OVN для надання хмарних послуг на основі послуг хмарної обробки (SFC).
NSX-T Container Plug-in (NCP): забезпечує інтеграцію між VMware NSX-T та оркестраторами контейнерів, такими як Kubernetes, а також інтеграцію між NSX-T та контейнерними платформами CaaS/PaaS, такими як Pivotal Container Service (PKS) та OpenShift.
Nuage: платформа SDN, яка забезпечує мережеву політику між Podʼами Kubernetes та не-Kubernetes середовищами з можливістю моніторингу видимості та безпеки.
Romana: рішення мережі рівня Layer 3 для мереж Podʼів, яке також підтримує API NetworkPolicy.
Spiderpool: мережеве рішення underlay та RDMA для Kubernetes. Spiderpool підтримується на фізичному обладнані, віртуальних машинах та публічних хмарних середовищах.
Terway: це набір втулків CNI, заснований на мережевих продуктах VPC та ECS від AlibabaCloud. Він забезпечує нативну мережу VPC та мережеві політики в середовищах AlibabaCloud.
Weave Net: надає мережеве рішення та мережеві політики, буде продовжувати працювати з обох боків розділу мережі та не потребує зовнішньої бази даних.

Виявлення Сервісів

CoreDNS — це гнучкий, розширюваний DNS-сервер, який може бути встановлений як DNS в кластері для Podʼів.

Візуалізація та управління

Dashboard — це вебінтерфейс для управління та моніторингу Kubernetes.
Headlamp — це розширюваний інтерфейс користувача Kubernetes, який можна розгорнути в кластері або використовувати як десктопну програму.

Інфраструктура

KubeVirt — це надбудова для запуску віртуальних машин в Kubernetes. Зазвичай використовується в кластерах на розгорнутих на фізичному обладнані.
Node problem detector — працює на вузлах Linux та повідомляє про проблеми системи як у вигляді подій або стану Вузла.

Інструментування

kube-state-metrics

Старі надбудови

Існують ще кілька інших надбудов, які визнані застарілим та знаходяться у теці cluster/addons.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Для досягнення найкращої продуктивності потрібні оптимізації, що стосуються ізоляції ЦП, памʼяті та локальності пристроїв. Проте, в Kubernetes ці оптимізації обробляються роздільним набором компонентів.

Призначення Podʼів на вузли

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Розширення kubectl за допомогою втулків

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Вам потрібно мати встановлений працюючий бінарний файл kubectl.

Керування HugePages

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes підтримує виділення та використання заздалегідь розміщених великих сторінок (huge pages) застосунками в Podʼі. Ця сторінка описує, як користувачі можуть використовувати великі сторінки.

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

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

Вузол може резервувати великі сторінки різних розмірів, наприклад, наступний рядок у файлі /etc/default/grub резервує 2*1 ГБ памʼяті для сторінок розміром 1 ГБ і 512*2 МБ для сторінок розміром 2 МБ:

Налаштування служби DNS

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці пояснюється, як налаштувати ваші DNS Pod та настроїти процес розвʼязання імен DNS у вашому кластері.

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

Оголошені функції вузла

Mon, 01 Jan 0001 00:00:00 +0000

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

Вузли Kubernetes використовують заявлені функції для повідомлення про доступність конкретних нових або обмежених функцій. Компоненти панелі управління використовують цю інформацію для прийняття кращих рішень. Kube-scheduler за допомогою втулка NodeDeclaredFeatures гарантує, що поди розміщуються тільки на вузлах, які явно підтримують функції, необхідні для поду. Крім того, контролер допуску NodeDeclaredFeatureValidator перевіряє оновлення подів на відповідність оголошеним функціям вузла.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці показано, як призначити Pod Kubernetes на певний вузол за допомогою спорідненості вузла в кластері Kubernetes.

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

Простори імен користувачів

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Процес, який працює як root в контейнері, може працювати як інший (не-root) користувач на хості; іншими словами, процес має повні привілеї для операцій всередині простору користувача, але не має привілеїв для операцій за його межами.

Ви можете використовувати цю функцію, щоб зменшити можливий збиток, який може заподіяти скомпрометований контейнер хосту або іншим Podʼам на тому ж вузлі. Є кілька вразливостей безпеки, які оцінено як ВИСОКІ або КРИТИЧНІ, і які не можна було б використати при активних просторах користувачів. Передбачається, що простір користувачів також буде запобігати деяким майбутнім вразливостям.

Downward API

Mon, 01 Jan 0001 00:00:00 +0000

Іноді корисно, щоб контейнер мав інформацію про себе, не перебуваючи занадто повʼязаним із Kubernetes. downward API дозволяє контейнерам використовувати інформацію про себе чи кластер, не використовуючи клієнт Kubernetes або API-сервер.

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

Налагодження розвʼязання імен DNS

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Ваш кластер повинен бути налаштований на використання надбудови CoreDNS або її попередника, kube-dns.

Налаштування ініціалізації Podʼа

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці показано, як використовувати Init Container для ініціалізації Podʼа перед запуском контейнера застосунку.

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

Планування GPU

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes має стабільну підтримку для управління графічними обчислювальними пристроями (GPU) від AMD та NVIDIA на різних вузлах вашого кластера, використовуючи втулки пристроїв.

На цій сторінці описано, як користувачі можуть використовувати GPU і наведені деякі обмеження в реалізації.

Використання втулків пристроїв

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

Обробники подій життєвого циклу контейнера

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Оголошення мережевої політики

Mon, 01 Jan 0001 00:00:00 +0000

Цей документ допоможе вам розпочати використання API мережевої політики Kubernetes NetworkPolicy API, щоб оголосити політики мережі, які керують тим, як Podʼи спілкуються один з одним.

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

Розширена конфігурація Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці розглядаються теми з розширеної конфігурації Podʼів, включаючи PriorityClasses, RuntimeClasses, security context в Podʼах, а також представлені аспекти планування.

PriorityClasses

PriorityClasses дозволяють вам встановити важливість Podʼів відносно інших Podʼів. Якщо ви призначаєте клас пріоритету Podʼу, Kubernetes встановлює поле .spec.priority для цього Podʼа на основі PriorityClass, який ви вказали (ви не можете встановити .spec.priority безпосередньо). Якщо або коли Pod не може бути запланований, і проблема повʼязана з нестачею ресурсів, kube-scheduler намагається випередити Pod з нижчим пріоритетом, щоб зробити можливим планування Podʼа з вищим пріоритетом.

Налаштування Podʼів для використання ConfigMap

Mon, 01 Jan 0001 00:00:00 +0000

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

Концепція ConfigMap дозволяє виокремити конфігураційні параметри з образу контейнера, що робить застосунок більш переносним. Наприклад, ви можете завантажити та використовувати один й той самий образ контейнера для використання контейнера для потреб локальної розробки, тестування системи, або в операційному середовищі.

Розробка Cloud Controller Manager

Mon, 01 Jan 0001 00:00:00 +0000

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

Cloud Controller Manager (cloud-controller-manager) є компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

Відокремлюючи логіку сумісності між Kubernetes і базовою хмарною інфраструктурою, компонент cloud-controller-manager дає змогу хмарним провайдерам випускати функції з іншою швидкістю порівняно з основним проєктом Kubernetes.

Координовані вибори лідера

Mon, 01 Jan 0001 00:00:00 +0000

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

Kubernetes 1.35 включає бета-функцію, яка дозволяє компонентам панелі управління детерміновано обирати лідера через координовані вибори лідера. Це корисно для задоволення обмежень щодо несумісності версій Kubernetes під час оновлення кластера. Наразі єдина вбудована стратегія вибору — це OldestEmulationVersion, що надає перевагу лідеру з найнижчою версією емуляції, за яким йде бінарна версія, а потім позначка часу створення.

Поділ простору імен процесів між контейнерами у Podʼі

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Увімкнення або вимкнення API Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

На цій сторінці показано, як увімкнути або вимкнути версію API зі вузла панелі управління вашого кластера.

Конкретні версії API можна увімкнути або вимкнути, передаючи --runtime-config=api/<version> як аргумент командного рядка до сервера API. Значення для цього аргументу є розділеним комами списком версій API. Пізніші значення перекривають попередні.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Процес, що працює як root у контейнері, може працювати як інший (не root) користувач на хості; іншими словами, процес має повні привілеї для операцій всередині простору імен користувача, але не має привілеїв для операцій за межами простору імен.

Використання тому Image в Pod

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка демонструє, як налаштувати Pod для використання томів image. Це дозволяє монтувати вміст з OCI реєстрів всередині контейнерів.

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

Шифрування конфіденційних даних у спокої

Mon, 01 Jan 0001 00:00:00 +0000

Усі API в Kubernetes, які дозволяють записувати постійні дані ресурсів API, підтримують шифрування у спокої. Наприклад, ви можете увімкнути шифрування у спокої для Secret. Це шифрування у спокої є додатковим до будь-якого шифрування на рівні системи для кластера etcd або для файлових систем на вузлах, де ви запускаєте kube-apiserver.

На цій сторінці показано, як увімкнути та налаштувати шифрування даних API у спокої.

Розшифровування конфіденційних даних, які вже зашифровані у спокої

Mon, 01 Jan 0001 00:00:00 +0000

Усі API в Kubernetes, що дозволяють записувати постійні дані ресурсів, підтримують шифрування у спокої. Наприклад, ви можете увімкнути шифрування у спокої для Secret. Це шифрування у спокої додається до будь-якого шифрування системного рівня для кластера etcd або файлових систем на вузлах, де запущений kube-apiserver.

Ця сторінка показує, як перейти від шифрування даних API у спокої, щоб дані API зберігалися у незашифрованому вигляді. Ви можете зробити це для покращення продуктивності; проте, якщо шифрування було раціональним рішенням для деяких даних, то його також варто залишити.

Mixed Version Proxy

Mon, 01 Jan 0001 00:00:00 +0000

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

У Kubernetes 1.35 включено альфа-функцію, яка дозволяє API Server проксійовати запити ресурсів до інших рівноправних API-серверів. Це також дозволяє клієнтам отримати цілісне уявлення про ресурси, що обслуговуються в усьому кластері, за допомогою виявлення. Це корисно, коли існують кілька API-серверів, що працюють на різних версіях Kubernetes в одному кластері (наприклад, під час тривалого впровадження нового релізу Kubernetes).

Гарантоване планування для критичних Podʼів надбудов

Mon, 01 Jan 0001 00:00:00 +0000

Основні компоненти Kubernetes, такі як сервер API, планувальник і контролер-менеджер, працюють на вузлі панелі управління. Однак надбудови мають працювати на звичайному вузлі кластера. Деякі з цих надбудов є критичними для повноцінного функціонування кластера, наприклад, metrics-server, DNS та інтерфейс користувача. Кластер може перестати правильно працювати, якщо критичний Pod надбудови буде видалений (або вручну, або як побічний ефект іншої операції, такої як оновлення) і перейде в стан очікування (наприклад, коли кластер високо завантажений і інші очікувані Podʼи заплановані на місце, звільнене видаленим критичним Podʼом надбудови, або кількість доступних ресурсів на вузлі змінилася з якоїсь іншої причини).

Створення статичних Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

Статичні Podʼи керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження за ними з боку API сервера. На відміну від Podʼів, які керуються панеллю управління (наприклад, Deployment), kubelet спостерігає за кожним статичним Podʼом (і перезапускає його у разі невдачі).

Статичні Podʼи завжди привʼязані до одного Kubelet на конкретному вузлі.

Керівництво користувача агента маскування IP

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як налаштувати та ввімкнути ip-masq-agent.

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

Для перевірки версії введіть kubectl version.

Конвертація файлу Docker Compose в ресурси Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Що таке Kompose? Це інструмент конвертації для всього, що стосується композиції (зокрема Docker Compose) в ресурси систем оркестрування (Kubernetes або OpenShift).

Додаткову інформацію можна знайти на вебсайті Kompose за адресою https://kompose.io.

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

Забезпечення стандартів безпеки Podʼів шляхом конфігурування вбудованого контролера допуску

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Після альфа-релізу в Kubernetes v1.22, Pod Security Admission став стандартно доступним в Kubernetes v1.23, у вигляді бета. Починаючи з версії 1.25, Pod Security Admissio доступний загалом.

Для перевірки версії введіть kubectl version.

Якщо у вас не запущено Kubernetes 1.35, ви можете перемикнутися на перегляд цієї сторінки в документації для версії Kubernetes, яку ви використовуєте.

Обмеження використання сховища

Mon, 01 Jan 0001 00:00:00 +0000

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

У демонстрації використовуються наступні ресурси: ResourceQuota, LimitRange, та PersistentVolumeClaim.

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

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

Забезпечення стандартів безпеки Podʼів за допомогою міток простору імен

Mon, 01 Jan 0001 00:00:00 +0000

Простори імен можуть бути позначені, щоб забезпечити стандарти безпеки Podʼів. Три політики privileged, baseline та restricted широко охоплюють спектр безпеки та реалізуються за допомогою контролера допуску безпеки Podʼа.

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

Pod Security Admission був доступний в Kubernetes v1.23, у вигляді бета. Починаючи з версії 1.25, Pod Security Admission доступний загалом.

Для перевірки версії введіть kubectl version.

Вимога стандарту безпеки Pod `baseline` за допомогою міток простору імен

Цей маніфест визначає Простір імен my-baseline-namespace, який:

Міграція реплікованої панелі управління на використання менеджера керування хмарою

Mon, 01 Jan 0001 00:00:00 +0000

Менеджер керування хмарою — компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

Міграція з PodSecurityPolicy до вбудованого контролера допуску PodSecurity

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує процес міграції з PodSecurityPolicy до вбудованого контролера допуску PodSecurity. Це можна зробити ефективно за допомогою комбінації запуску dry-run та режимів audit та warn, хоча це стає складнішим, якщо використовуються мутуючі PSP.

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

Версія вашого Kubernetes сервера має бути не старішою ніж v1.22.

Для перевірки версії введіть kubectl version.

Якщо ви використовуєте відмінну від 1.35 версію Kubernetes, вам можливо захочеться перейти до перегляду цієї сторінки у документації для версії Kubernetes, яку ви фактично використовуєте.

Посібник з роботи з просторами імен

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes namespaces допомагають різним проєктам, командам або клієнтам спільно використовувати кластер Kubernetes.

Вони це роблять, надаючи наступне:

Область для Імен.
Механізм для прикріплення авторизації та політики до підрозділу кластера.

Використання кількох просторів імен є необовʼязковим.

У цьому прикладі показано, як використовувати простори імен Kubernetes для розділення вашого кластера.

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

Управління кластерами etcd для Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

etcd — це надійне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для всіх даних кластера.

Якщо ваш кластер Kubernetes використовує etcd як основне сховище, переконайтеся, що у вас є план резервного копіювання даних.

Ви можете знайти докладну інформацію про etcd в офіційній документації.

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

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

Резервування обчислювальних ресурсів для системних служб

Mon, 01 Jan 0001 00:00:00 +0000

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

kubelet надає можливість під назвою 'Node Allocatable', яка допомагає резервувати обчислювальні ресурси для системних служб. Kubernetes рекомендує адміністраторам кластера налаштовувати 'Node Allocatable' на основі щільності робочого навантаження на кожному вузлі.

Запуск компонентів вузла Kubernetes користувачем без прав root

Mon, 01 Jan 0001 00:00:00 +0000

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

У цьому документі описано, як запустити компоненти вузла Kubernetes, такі як kubelet, CRI, OCI та CNI, без прав root, використовуючи простір імен користувача.

Ця техніка також відома як rootless mode.

Примітка:

У цьому документі описано, як запустити компоненти вузла Kubernetes (і відповідно Podʼи), як не-root користувач.

Якщо ви шукаєте лише як запустити Pod як не-root користувача, див. SecurityContext.

Безпечне очищення вузла

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як безпечно очистити вузол, опційно дотримуючись PodDisruptionBudget, який ви визначили.

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

Це завдання передбачає, що ви виконали такі попередні умови:

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

(Необовʼязково) Налаштування бюджету відмови

Щоб забезпечити доступність ваших робочих навантажень під час технічного обслуговування, ви можете налаштувати PodDisruptionBudget.

Захист кластера

Mon, 01 Jan 0001 00:00:00 +0000

У цьому документі розглядаються теми, повʼязані з захистом кластера від випадкового або зловмисного доступу та надаються загальні рекомендації безпеки.

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

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

Встановлення параметрів Kubelet через файл конфігурації

Mon, 01 Jan 0001 00:00:00 +0000

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

Деякі кроки на цій сторінці використовують інструмент jq. Якщо у вас немає jq, ви можете встановити його через отримання оновлень програм вашої операційної системи або завантажити з https://jqlang.github.io/jq/.

Деякі кроки також включають встановлення curl, який також можна встановити засобами встановлення програмного забезпечення вашої операційної системи.

Частину параметрів конфігурації kubelet можна встановити за допомогою конфігураційного файлу на диску, як альтернативу командним прапорцям.

Надання параметрів через файл конфігурації є рекомендованим підходом, оскільки це спрощує розгортання вузлів та управління конфігурацією.

Спільне використання кластера з просторами імен

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як переглядати, працювати та видаляти простори імен. На сторінці також розказується, як використовувати простори імен Kubernetes для розділення вашого кластера.

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

Вам потрібен кластер Kubernetes.
Ви маєте базове розуміння про Pod, Service, та Deployment в Kubernetes.

Перегляд просторів імен

Перелік поточних просторів імен у кластері можна отримати за допомогою команди:

Оновлення кластера

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка надає огляд кроків, які вам слід виконати для оновлення кластера Kubernetes.

Спосіб оновлення кластера залежить від того, як ви спочатку розгорнули його та від будь-яких наступних змін.

На високому рівні кроки, які ви виконуєте, такі:

Оновити панель управління
Оновити вузли в вашому кластері
Оновити клієнтів, такі як kubectl
Відредагувати маніфести та інші ресурси на основі змін API, які супроводжують нову версію Kubernetes

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

Вам потрібно мати кластер. Ця сторінка присвячена оновленню з Kubernetes 1.34 до Kubernetes 1.35. Якщо ваш кластер зараз працює на Kubernetes 1.34, тоді, будь ласка, перевірте документацію для версії Kubernetes, на яку ви плануєте оновити.

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Використання постачальника KMS для шифрування даних

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як налаштувати постачальника Служби керування ключами (KMS) та втулок для шифрування конфіденційних даних. У Kubernetes 1.35 існують дві версії шифрування даних за допомогою KMS у спокої. Якщо це можливо, вам слід використовувати KMS v2, оскільки KMS v1 застарів (починаючи з Kubernetes v1.28) та є типово вимкненим (починаючи з Kubernetes v1.29). KMS v2 пропонує значно кращі характеристики продуктивності, ніж KMS v1.

Увага:

Ця документація стосується загальновживаної реалізації KMS v2 (і застарілої реалізації версії 1). Якщо ви використовуєте будь-які компоненти панелі управління старші за Kubernetes v1.29, будь ласка, перевірте відповідну сторінку в документації для версії Kubernetes, яку використовує ваш кластер. Ранні версії Kubernetes мали різну поведінку, яка може бути важливою для інформаційної безпеки.

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

Використання CoreDNS для виявлення Service

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка описує процес оновлення CoreDNS та як встановити CoreDNS замість kube-dns.

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

Використання NodeLocal DNSCache в кластерах Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка надає огляд функції NodeLocal DNSCache в Kubernetes.

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

Використання sysctl в кластері Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

У цьому документі описано, як налаштовувати та використовувати параметри ядра в межах кластера Kubernetes, використовуючи інтерфейс sysctl.

Примітка:

Починаючи з версії Kubernetes 1.23, kubelet підтримує використання / або . як роздільники для назв sysctl. Починаючи з версії Kubernetes 1.25, налаштування Sysctls для контейнера підтримує встановлення sysctl зі слешами. Наприклад, ви можете представити ту саму назву sysctl як kernel.shm_rmid_forced, використовуючи крапку як роздільник, або як kernel/shm_rmid_forced, використовуючи слеш як роздільник. Для отримання додаткових відомостей щодо методу конвертації параметра sysctl див. сторінку sysctl.d(5) проєкту Linux man-pages.

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

Примітка:

sysctl — це інструмент командного рядка, специфічний для Linux, який використовується для налаштування різних параметрів ядра, і він недоступний в операційних системах, що не базуються на Linux.

Перевірка підписаних артефактів Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

cosign (інструкція щодо встановлення)
curl (часто надається вашою операційною системою)
jq (завантажте jq)

Перевірка підписів бінарних файлів

В процесі підготовки випуску Kubernetes підписує всі бінарні артефакти (tarballs, файли SPDX, окремі бінарні файли) за допомогою безключового підписування cosign. Щоб перевірити певний бінарний файл, отримайте його разом з підписом та сертифікатом:

URL=https://dl.k8s.io/release/v1.35.0/bin/linux/amd64
BINARY=kubectl

FILES=(
 "$BINARY"
 "$BINARY.sig"
 "$BINARY.cert"
)

for FILE in "${FILES[@]}"; do
 curl -sSfL --retry 3 --retry-delay 3 "$URL/$FILE" -o "$FILE"
done

Потім перевірте блоб, використовуючи cosign verify-blob:

Представляємо контролер готовності вузлів

Tue, 03 Feb 2026 10:00:00 +0800

У стандартній моделі Kubernetes придатність вузла для робочих навантажень залежить від єдиного бінарного стану «Ready» («Готовий»). Однак у сучасних середовищах Kubernetes вузли потребують складних інфраструктурних залежностей, таких як мережеві агенти, драйвери сховищ, прошивка GPU або спеціальні перевірки працездатності, щоб бути повністю готовими до роботи, перш ніж вони зможуть надійно обслуговувати поди.

Сьогодні від імені проєкту Kubernetes я оголошую про запуск Node Readiness Controller. Цей проєкт впроваджує декларативну систему для управління позначками вузлів, розширюючи захисні барʼєри готовності під час завантаження вузлів за межі стандартних станів. Динамічно керуючи taints на основі спеціальних сигналів стану, контролер гарантує, що робочі навантаження розміщуються тільки на вузлах, які відповідають усім вимогам інфраструктури.

Нове перетворення з cgroup v1 CPU Shares на v2 CPU Weight

Fri, 30 Jan 2026 08:00:00 -0800

Я радий повідомити про впровадження вдосконаленої формули перетворення з cgroup v1 CPU shares на cgroup v2 CPU weight. Це вдосконалення вирішує критичні проблеми з розподілом пріоритетів CPU для робочих навантажень Kubernetes під час роботи на системах з cgroup v2.

Історія

Kubernetes спочатку був розроблений з урахуванням cgroup v1, де CPU shares визначалися просто шляхом присвоєння контейнеру CPU-запитів у вигляді millicpu.

Наприклад, контейнер, що запитує 1 CPU (1024m) отримає (cpu.shares = 1024).

Ingress NGINX: Заява комітетів з управління та реагування на загрози безпеки Kubernetes

Thu, 29 Jan 2026 00:00:00 +0000

У березні 2026 року Kubernetes припинить підтримку Ingress NGINX, важливої інфраструктури для приблизно половини хмарних середовищ. Припинення підтримки Ingress NGINX було оголошено на березень 2026 року після років публічних попереджень про те, що проєкт гостро потребує учасників та супровідників. Після припинення підтримки проєкту більше не буде випусків для виправлення помилок, патчів безпеки або будь-яких оновлень. Це не можна ігнорувати, відкидати або залишати на останню хвилину. Ми не можемо переоцінити серйозність ситуації та важливість негайного початку міграції на альтернативні рішення, такі як Gateway API або один із багатьох сторонніх контролерів Ingress.

Експерименти з Gateway API за допомогою kind

Wed, 28 Jan 2026 00:00:00 +0000

Цей документ проведе вас через налаштування локального експериментального середовища з Gateway API з використанням kind. Це середовище розроблено для навчання та тестування. Воно допомагає вам зрозуміти концепції Gateway API без складності промислового середовища.

Увага:

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

Огляд

У цьому посібнику ви:

Cluster API v1.12: Впровадження оновлень на місці та ланцюгових оновлень

Tue, 27 Jan 2026 08:00:00 -0800

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

Подібно до того, як ви можете використовувати StatefulSets або Deployments в Kubernetes для управління групою Pods, в Cluster API ви можете використовувати KubeadmControlPlane для управління набором машин панелі упрвління або MachineDeployments для управління групою робочих вузлів.

Випуск Cluster API v1.12.0 розширює можливості Cluster API, зменшуючи складності у звичайних операціях життєвого циклу завдяки впровадженню оновлень на місці та ланцюгових оновлень.

Headlamp у 2025 році: ключові моменти проєкту

Thu, 22 Jan 2026 10:00:00 +0800

Це повідомлення є підсумком публікації, яка спочатку була опублікована у блозі Headlamp.

Headlamp пройшов довгий шлях у 2025 році. Проєкт продовжує розвиватися — охоплює все більше команд на різних платформах, забезпечує нові робочі процеси та інтеграції за допомогою втулків, а також сприяє розширенню співпраці з боку спільноти.

Ми хотіли б поділитися кількома оновленнями та розповісти про те, як Headlamp розвивався протягом останнього року.

Оновлення

Приєднання до Kubernetes SIG UI

Цей рік став важливою віхою для проєкту: Headlamp тепер офіційно є частиною Kubernetes SIG UI. Цей крок ще більше наближає обговорення планів розвитку та дизайну до основної спільноти Kubernetes і підкріплює роль Headlamp як сучасного, розширюваного інтерфейсу для проєкту.

Оголошення про створення робочої групи Checkpoint/Restore Working Group

Wed, 21 Jan 2026 10:00:00 -0800

Спільнота навколо Kubernetes включає в себе ряд спеціальних груп за інтересами (SIG) та робочих груп (WG), які сприяють обговоренню важливих тем між зацікавленими учасниками. Сьогодні ми хотіли б оголосити про створення нової робочої групи Kubernetes Checkpoint Restore WG, яка зосередиться на інтеграції функціоналу Checkpoint/Restore в Kubernetes.

Мотивація та випадки використання

Робоча група обговорює кілька сценаріїв високого рівня:

Оптимізація використання ресурсів для інтерактивних робочих навантажень, таких як Jupyter notebook та чат-боти зі штучним інтелектом
Прискорення запуску застосунків з тривалим часом ініціалізації, включаючи Java-застосунки та служби LLM-інференції
Використання періодичних контрольних точок для забезпечення відмовостійкості довготривалих робочих навантажень, таких як розподілене навчання моделей
Забезпечення планування з урахуванням переривань з прозорою перевіркою/відновленням, що дозволяє витісняти Pod з нижчим пріоритетом, зберігаючи стан виконання застосунків
Спрощення міграції Podʼів між вузлами для балансування навантаження та обслуговування без переривання робочих навантажень.
Увімкнення перевірки для розслідування та аналізу інцидентів безпеки, таких як кібератаки, порушення безпеки даних та несанкціонований доступ.

У всіх цих сценаріях мета полягає в тому, щоб сприяти обговоренню ідей між спільнотою Kubernetes та екосистемою Checkpoint/Restore in Userspace (CRIU), яка постійно розширюється. Спільнота CRIU включає кілька проєктів, що підтримують ці випадки використання, зокрема:

Уніфікований доступ до сервера API за допомогою clientcmd

Mon, 19 Jan 2026 10:00:00 -0800

Якщо ви коли-небудь хотіли створювати консольного клієнта для API Kubernetes, особливо якщо ви розглядали можливість використання вашого клієнта як втулка kubectl, ви, можливо, замислювалися над тим, як зробити вашого клієнта звичним для користувачів kubectl. Швидкий погляд на вихідні дані kubectl options може вас збентежити: «Невже я повинен реалізувати всі ці опції?»

Не бійтеся, інші вже зробили за вас велику частину роботи. Насправді проєкт Kubernetes надає дві бібліотеки, які допоможуть вам обробляти аргументи командного рядка в стилі kubectl у програмах Go: clientcmd та cli-runtime (яка використовує clientcmd). У цій статті ми покажемо, як використовувати першу з них.

Kubernetes v1.35: До kuberc додано обмеження щодо виконуваних файлів, які викликаються kubeconfigs через exec plugin allowList

Fri, 09 Jan 2026 10:30:00 -0800

Чи знали ви, що kubectl може запускати довільні виконувані файли, включаючи скрипти оболонки, з повними правами користувача, який їх викликає, і навіть без вашого відома? Кожного разу, коли ви завантажуєте або автоматично генеруєте kubeconfig, поле users[n].exec.command може вказати виконуваний файл для отримання облікових даних від вашого імені. Не зрозумійте мене неправильно, це неймовірна функція, яка дозволяє вам пройти автентифікацію в кластері за допомогою зовнішніх постачальників ідентифікації. Проте, ви, мабуть, бачите проблему: чи знаєте ви точно, які виконувані файли ваш kubeconfig запускає у вашій системі? Чи довіряєте ви конвеєру, який згенерував ваш kubeconfig? Якщо на код, що генерує kubeconfig, було здійснено атаку на ланцюжок постачання, або якщо конвеєр генерації було скомпрометовано, зловмисник може робити неприємні речі з вашою машиною, змушуючи ваш kubeconfig виконувати довільний код.

Kubernetes v1.35: Змінювана спорідненість вузлів PersistentVolume (альфа)

Thu, 08 Jan 2026 10:30:00 -0800

API спорідненості вузлів PersistentVolume зʼявився ще в Kubernetes v1.10. Він широко використовується для позначення того, що томи можуть бути не однаково доступними для всіх вузлів у кластері. Раніше це поле було незмінним, а тепер воно стало змінюваним у Kubernets v1.35 (альфа). Ця зміна відкриває можливості для більш гнучкого управління томами в режимі онлайн.

Для чого робити спорідненість вузлів змінюваною?

Це викликає очевидне запитання: чому зараз зробити спорідненість вузлів змінюваною? Хоча робочі навантаження без збереження стану, такі як Deployments, можна вільно змінювати, і зміни будуть автоматично впроваджуватися шляхом повторного створення кожного Podʼа, PersistentVolumes (PV) мають стан і їх не можна легко створити заново без втрати даних.

Kubernetes v1.35: Кращий спосіб передачі токенів службових облікових записів до драйверів CSI

Wed, 07 Jan 2026 10:30:00 -0800

Якщо ви підтримуєте драйвер CSI, який використовує токени службових облікових записів, Kubernetes v1.35 приносить удосконалення, про яке вам варто знати. З моменту введення функції TokenRequests, токени службових облікових записів, запитувані драйверами CSI, передавалися їм через поле volume_context. Хоча це працювало, це не ідеальне місце для конфіденційної інформації, і ми бачили випадки, коли токени випадково реєструвалися в драйверах CSI.

Kubernetes v1.35 вводить рішення бета-версії для вирішення цієї проблеми: Опція драйвера CSI для токенів службових облікових записів через поле Secrets. Це дозволяє драйверам CSI отримувати токени службових облікових записів через поле secrets у NodePublishVolumeRequest, яке є відповідним місцем для конфіденційних даних у специфікації CSI.

Kubernetes v1.35: Розширені оператори толерантності для підтримки числових порівнянь (Alpha)

Mon, 05 Jan 2026 10:30:00 -0800

Багато робочих кластерів Kubernetes поєднують вузли на вимогу (вищий рівень SLA) та спот-вузли/вузли з правом витіснення (нижчий рівень SLA) для оптимізації витрат при збереженні надійності критичних робочих навантажень. Команди платформи потребують безпечного стандартного варіанту, який утримує більшість робочих навантажень подалі від ризикованих потужностей, одночасно дозволяючи певним робочим навантаженням підключатися з явними пороговими значеннями, такими як «Я можу толерувати вузли з імовірністю відмови до 5%».

Сьогодні Kubernetes taints і tolerations можуть відповідати точним значенням або перевіряти наявність, але вони не можуть порівнювати числові пороги. Вам потрібно буде створити дискретні категорії taint, використовувати зовнішні контролери допуску або приймати рішення про розміщення, що не є оптимальними.

Kubernetes v1.35: Новий рівень ефективності завдяки перезапуску Podʼів на місці

Fri, 02 Jan 2026 10:30:00 -0800

У версії Kubernetes 1.35 представлено нову потужну функцію, яка забезпечує довгоочікувану можливість: можливість викликати повне перезавантаження Podʼів на місці. Ця функція, Restart All Containers (альфа-версія в 1.35), дозволяє ефективно скинути стан Podʼів порівняно з ресурсоємним підходом, що передбачає видалення та повторне створення всього Podʼа. Ця функція особливо корисна для робочих навантажень AI/ML, дозволяючи розробникам застосунків зосередитися на основній логіці тренування, перекладаючи складні механізми обробки збоїв і відновлення в контейнери sidecars та декларативну конфігурацію Kubernetes. За допомогою RestartAllContainers та інших запланованих вдосконалень Kubernetes продовжує додавати будівельні блоки для створення найбільш гнучких, надійних та ефективних платформ для робочих навантажень AI/ML.

Kubernetes 1.35: Покращене відлагодження за допомогою версійованих API z-pages

Wed, 31 Dec 2025 10:30:00 -0800

Відлагодження компонентів панелі управління Kubernetes може бути складним завданням, особливо коли потрібно швидко зрозуміти стан компонента під час виконання або перевірити його конфігурацію. У Kubernetes 1.35 ми вдосконалюємо точки доступу z-pages для відлагодження за допомогою структурованих відповідей, які можна обробляти засобами машинного аналізу, що спрощує створення інструментів та автоматизацію робочих процесів з усунення несправностей.

Що таке z-сторінки?

z-сторінки — це спеціальні точки доступу для відлагодження, які надаються компонентами панелі управління Kubernetes. Введені як альфа-функція в Kubernetes 1.32, ці точки доступу забезпечують діагностику під час виконання для таких компонентів, як kube-apiserver, kube-controller-manager, kube-scheduler, kubelet та kube-proxy. Назва «z-сторінки» походить від домовленості про використання шляхів /*z (додвання останньої літери латинської абетки до шляху) для точок доступу для налагодження.

Kubernetes v1.35: Узгодження маршрутів на основі спостереження в Cloud Controller Manager

Tue, 30 Dec 2025 10:30:00 -0800

До Kubernetes v1.34 включно контролер маршрутів у реалізаціях Cloud Controller Manager (CCM), створених за допомогою бібліотеки k8s.io/cloud-provider, узгоджує маршрути через фіксований інтервал. Це призводить до непотрібних запитів до API хмарного провайдера, коли не відбуваються зміни маршрутів. Інші контролери, реалізовані через ту ж бібліотеку, вже використовують механізми на основі спостереження, використовуючи інформери для уникнення непотрібних викликів API. У версії v1.35 запроваджується нова функціональна можливість, яка дозволяє змінити поведінку контролера маршрутів на використання інформерів на основі спостереження.

Kubernetes v1.35: Представляємо планування з урахуванням навантаження

Mon, 29 Dec 2025 10:30:00 -0800

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

Kubernetes v1.35: Деталізоване управління допоміжними групами переходить в стан загальної доступності (GA)

Tue, 23 Dec 2025 10:30:00 -0800

Від імені Kubernetes SIG Node, ми раді оголосити про перехід деталізованого управління допоміжними групами до загальної доступності (GA) у Kubernetes v1.35!

Нове поле Pod supplementalGroupsPolicy було введено як opt-in альфа-функція для Kubernetes v1.31, а потім перейшло до бета у v1.33. Тепер ця функція є загальнодоступною. Ця функція дозволяє реалізувати більш точний контроль над допоміжними групами в контейнерах Linux, що може зміцнити позицію безпеки, особливо при доступі до томів. Крім того, вона також покращує прозорість деталей UID/GID у контейнерах, забезпечуючи покращений нагляд за безпекою.

Kubernetes v1.35: Конфігурація Kubelet Drop-in Directory переходить до GA

Mon, 22 Dec 2025 10:30:00 -0800

З останнім випуском Kubernetes v1.35 стала загальнодоступною підтримка теки для конфігураційних файлів kubelet. Нова стабільна функція спрощує управління конфігурацією kubelet у великих гетерогенних кластерах.

У версії 1.35 аргумент командного рядка kubelet --config-dir готовий до використання у промислових умовах і повністю підтримується, що дозволяє вказати теку, яка містить файли конфігурації kubelet. Усі файли в цій теці будуть автоматично обʼєднані з основною конфігурацією kubelet. Це дозволяє адміністраторам кластерів підтримувати єдину базову конфігурацію для kubelet, одночасно забезпечуючи цільові налаштування для різних груп вузлів або випадків використання, без складних інструментів або ручного управління конфігурацією.

Уникнення зомбі-учасників кластера при оновленні до etcd v3.6

Sun, 21 Dec 2025 00:00:00 +0000

Основний висновок? Завжди оновлюйтеся до etcd v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та дозволяж уникати появі зомбі-учасників.

Kubernetes 1.35: Зміна розміру Podʼа на місці переходить у стабільний стан

Fri, 19 Dec 2025 10:30:00 -0800

Цей випуск є важливим кроком: через понад 6 років після його первинної концепції функція In-Place Pod Resize (також відома як In-Place Pod Vertical Scaling), вперше представлена як альфа-версія в Kubernetes v1.27 і переведена в бета-версію в Kubernetes v1.33, тепер є стабільною (GA) в Kubernetes 1.35!

Цей перехід є важливою віхою для підвищення ефективності використання ресурсів та гнучкості робочих навантажень, що виконуються на Kubernetes.

Що таке In-Place Pod Resize?

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

Kubernetes v1.35: Завдання керовані зовнішніми контролерами переходять у загальну доступність

Thu, 18 Dec 2025 10:30:00 -0800

У Kubernetes v1.35 можливість вказати зовнішній контролер Завдань (через .spec.managedBy) переходить у загальну доступність.

Ця функція дозволяє зовнішнім контролерам брати на себе повну відповідальність за узгодження Завдань (Job), відкриваючи потужні моделі планування, такі як багатокластерне диспетчеризування з MultiKueue.

Навіщо делегувати узгодження Завдань?

Основною мотивацією для цієї функції є підтримка архітектур багатокластерного пакетного планування, таких як MultiKueue.

Архітектура MultiKueue розрізняє кластер управління та пул робочих кластерів:

Кластер управління відповідає за розподіл завдань, але не за їх виконання. Він повинен приймати обʼєкти Job для відстеження статусу, але пропускає створення та виконання Podʼів.
Кластери робочих вузлів отримують розподілені Завдання та виконують фактичні Podʼи.
Користувачі зазвичай взаємодіють із кластером управління. Оскільки статус автоматично передається назад, вони можуть спостерігати за прогресом Завдання «наживо» без доступу до кластерів робочих вузлів.
У робочих кластерах розподілені Завдання виконуються як звичайні Завдання, що управляються вбудованим контролером Завдань, без налаштування .spec.managedBy.

Використовуючи .spec.managedBy, контролер MultiKueue в кластері управління може взяти на себе узгодження Завдання. Він копіює статус із «дзеркального» Завдання, що виконується в робочому кластері, назад до кластера управління.

Kubernetes v1.35: Timbernetes («Світове дерево»)

Wed, 17 Dec 2025 10:30:00 -0800

Редактори: Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao

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

Цей випуск містить 60 вдосконалень, включаючи 17 стабільних, 19 бета- та 22 альфа-функції.

У цьому випуску також є деякі застарілі та видалені функції; обовʼязково ознайомтеся з ними.

Тема та логотип релізу

2025 рік розпочався у сяйві Octarine: The Color of Magic (v1.33) і промайнув під поривами Of Wind & Will (v1.34). Ми завершуємо цей рік, тримаючись за Світове дерево, натхненні Іггдрасілем, деревом життя, що поєднує багато світів. Як і будь-яке велике дерево, Kubernetes росте кільце за кільцем і реліз за релізом, формуючись під опікою глобальної спільноти.

Попередній огляд Kubernetes v1.35

Wed, 26 Nov 2025 00:00:00 +0000

З наближенням випуску Kubernetes v1.35 проєкт Kubernetes продовжує розвиватися. Функції можуть визнаватись застарілими, видаленими або заміненими для поліпшення загального стану проєкту. У цьому дописі в блозі описано заплановані зміни для випуску v1.35, про які, на думку команди випуску, вам слід знати, щоб забезпечити безперебійну роботу ваших кластерів Kubernetes та бути в курсі останніх розробок. Наведена нижче інформація базується на поточному стані версії v1.35 і може бути змінена до дати остаточного випуску.

Закінчення підтримки Ingress NGINX: що потрібно знати

Tue, 11 Nov 2025 10:30:00 -0800

Для забезпечення пріоритетності безпеки та захисту екосистеми, Kubernetes SIG Network та Комітет з реагування на загрози безпеки оголошують про майбутнє завершення підтримки Ingress NGINX. Підтримка буде продовжуватися до березня 2026 року. Після цього не буде нових випусків, виправлень помилок та оновлень для усунення будь-яких виявлених вразливостей безпеки. Наявні розгортання Ingress NGINX продовжуватимуть функціонувати, а інсталяційні артефакти залишатимуться доступними.

Ми рекомендуємо перейти на одну з багатьох альтернатив. Розгляньте можливість переходу на Gateway API, сучасну заміну Ingress. Якщо ви мусите продовжувати використовувати Ingress, багато альтернативних контролерів Ingress перелічено в документації Kubernetes. Далі ви знайдете додаткову інформацію про історію та поточний стан Ingress NGINX, а також про наступні кроки.

Gateway API 1.4: Нові можливості

Thu, 06 Nov 2025 09:00:00 -0800

Готові до революції у сфері мережевих технологій Kubernetes? Спільнота Kubernetes SIG Network представила загальнодоступну версію Gateway API (v1.4.0)! Випущена 6 жовтня 2025 року версія 1.4.0 зміцнює позиції сучасних, динамічних і розширюваних мережевих технологій у Kubernetes.

Gateway API v1.4.0 приносить три нові можливості до Стандартного каналу (GA-версія Gateway API):

BackendTLSPolicy для TLS між шлюзами та бекендами
supportedFeatures у статусі GatewayClass
Іменовані правила для маршрутів

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

7 типових помилок Kubernetes (і як я навчився їх уникати)

Mon, 20 Oct 2025 08:30:00 -0700

Не секрет, що Kubernetes може бути як потужним, так і іноді викликати розчарування. Коли я вперше почав займатися оркеструванням контейнерів, я зробив більше ніж достатньо помилок, щоб скласти цілий список підводних каменів. У цій публікації я хочу розглянути сім основних підводних каменів, з якими я стикався (або бачив, як стикалися інші), і поділитися кількома порадами, як їх уникнути. Незалежно від того, чи ви тільки починаєте знайомитися з Kubernetes, чи вже керуєте кластерами у промисловій експлуатації, сподіваюся, ці поради допоможуть вам уникнути зайвого стресу.

Представляємо втулок Headlamp для Karpenter — масштабування та видимість

Mon, 06 Oct 2025 00:00:00 +0000

Headlamp — це відкритий, розширюваний проєкт Kubernetes SIG UI, призначений для того, щоб ви могли досліджувати, керувати та налагоджувати ресурси кластера.

Karpenter — це проєкт Kubernetes Autoscaling SIG для виділення вузлів, який допомагає кластерам швидко та ефективно масштабуватися. Він запускає нові вузли за лічені секунди, добираючи відповідні типи екземплярів для навантажень і керує повним життєвим циклом вузлів, включаючи зменшення масштабу.

Новий втулок Headlamp Karpenter додає можливість перегляду активності Karpenter у реальному часі безпосередньо з інтерфейсу Headlamp. Він показує, які ресурси Karpenter відповідають обʼєктам Kubernetes, виводить метрики в реальному часі та демонструє події масштабування в міру їх виникнення. Ви можете здійснювати перевірку подів, що очікують на обробку, переглядати рішення щодо масштабування та редагувати ресурси, що керуються Karpenter, за допомогою вбудованої функції перевірки. Втулок Karpenter був створений у рамках проєкту за підтримки LFX.

Оголошення про підтримку Changed Block Tracking API (альфа)

Thu, 25 Sep 2025 05:00:00 -0800

Ми раді оголосити про альфа-підтримку механізму відстеження змінених блоків. Це покращує екосистему зберігання даних Kubernetes, надаючи ефективний спосіб для драйверів зберігання даних CSI ідентифікувати змінені блоки в знімках (snapshot) PersistentVolume. За допомогою драйвера, який може використовувати цю функцію, ви зможете скористатися швидшими та більш ефективними з точки зору використання ресурсів операціями резервного копіювання.

Якщо ви хочете спробувати цю функцію, перейдіть до розділу Початок роботи.

Що таке відстеження змінених блоків?

Відстеження змінених блоків дозволяє системам зберігання даних ідентифікувати та відстежувати зміни на рівні блоків між моментальними знімками, усуваючи необхідність сканування цілих томів під час операцій резервного копіювання. Це вдосконалення є зміною в інтерфейсі Container Storage Interface (CSI), а також у підтримці зберігання даних у самій системі Kubernetes. З увімкненою альфа-функцією ваш кластер може:

Kubernetes v1.34: Ресурси рівня Pod перейшли в стадію бета

Mon, 22 Sep 2025 10:30:00 -0800

Від імені спільноти Kubernetes я з радістю повідомляю, що функція Pod Level Resources (Ресурси рівня Pod) перейшла в стадію бета у версії Kubernetes v1.34 і є стандартно увімкненою! Ця важлива подія відкриває нові можливості для визначення та управління розподілом ресурсів для ваших Podʼів. Така гнучкість зумовлена можливістю вказати ресурси CPU та памʼяті для Podʼа в цілому. Ресурси на рівні Podʼа можна поєднувати зі специфікаціями на рівні контейнера, щоб точно визначити вимоги до ресурсів та обмеження, необхідні для вашого застосунку.

Kubernetes v1.34: Відновлення після збою розширення тому (GA)

Fri, 19 Sep 2025 10:30:00 -0800

Чи робили ви коли-небудь помилку при розширенні ваших постійних томів у Kubernetes? Хотіли вказати 2TB, але вказали 20TiB? Ця, здавалося б, незначна проблема була досить важкою для виправлення, і проєкту знадобилося майже 5 років, щоб її виправити. Автоматичне відновлення після розширення сховища існує вже деякий час у бета-версії; однак, з випуском v1.34, ми перевели її в загальну доступність.

Хоча завжди було можливо відновитися після збою розширення томів вручну, зазвичай це вимагало доступу адміністратора кластера і було нудно робити (див. вказане посилання для отримання додаткової інформації).

Kubernetes v1.34: Споживча ємність DRA

Thu, 18 Sep 2025 10:30:00 -0800

Динамічне виділення ресурсів (Dynamic Resource Allocation, DRA) — це API Kubernetes для управління дефіцитними ресурсами Podʼів та контейнерів. Він дозволяє гнучкі запити ресурсів, виходячи за межі простого виділення N кількості пристроїв, щоб підтримувати більш детальні сценарії використання. З DRA користувачі можуть запитувати специфічні типи пристроїв на основі їх атрибутів, визначати власні конфігурації, адаптовані до їх робочих навантажень, і навіть ділитися одним і тим же ресурсом між кількома контейнерами або Podʼами.

Kubernetes v1.34: Звіт про стан ресурсів DRA в Podʼах

Wed, 17 Sep 2025 10:30:00 -0800

Зростання популярності штучного інтелекту (AI) та машинного навчання (ML) та інших високопродуктивних робочих навантажень зробило спеціалізоване обладнання, таке як графічні процесори (GPU), процесори для обробки даних (TPU) та програмовані логічні матриці (FPGA), критично важливим компонентом багатьох кластерів Kubernetes. Однак, як обговорювалося в попередньому блозі про пошук збоїв у Podʼах з пристроями, коли це обладнання виходить з ладу, його може бути важко діагностувати, що призводить до значного часу простою. З випуском Kubernetes v1.34 ми раді оголосити про нову альфа-функцію, яка забезпечує необхідну видимість стану цих пристроїв.

Kubernetes v1.34: Volume Group Snapshots переходить в v1beta2

Tue, 16 Sep 2025 10:30:00 -0800

Volume group snapshots було представлено як функцію Alpha у випуску Kubernetes 1.27, зміна у Beta — у випуску Kubernetes 1.32. Останній випуск Kubernetes v1.34 переніс цю підтримку на другий бета-етап. Підтримка знімків групи томів спирається на набір додаткових API для групових знімків. Ці API дозволяють користувачам робити знімки, що відповідають аварійним ситуаціям, для набору томів. За лаштунками Kubernetes використовує селектор міток для групування кількох PersistentVolumeClaims для знімків. Основна мета полягає в тому, щоб дозволити вам відновити цей набір знімків на нові томи та відновити вашу роботу на основі точки відновлення, що відповідає аварійним ситуаціям.

Kubernetes v1.34: Виділений Taint Manager тепер Stable

Mon, 15 Sep 2025 10:30:00 -0800

Ця функція відокремлює відповідальність за управління життєвим циклом вузлів і виселенням podʼів на два окремі компоненти. Раніше контролер життєвого циклу вузлів обробляв як позначення вузлів як несправних з позначкам (taints) NoExecute, так і виселення podʼів з них. Тепер спеціалізований контролер виселення на основі позначок taint керує процесом, тоді як контролер життєвого циклу вузлів зосереджується виключно на проставлянні taintʼів. Це відокремлення не тільки покращує організацію коду, але й спрощує вдосконалення контролера виселення або створення власних реалізацій виселення на основі позначок.

Kubernetes 1.34: Автоконфігурація для драйвера Node Cgroup переходить у стадію загальної доступності (GA)

Fri, 12 Sep 2025 10:30:00 -0800

Історично, налаштування правильного драйвера cgroup було болючою точкою для користувачів, які запускали нові кластери Kubernetes. В системах Linux існують два різні драйвери cgroup: cgroupfs і systemd. У минулому як kubelet, так і реалізація CRI (така як CRI-O або containerd) повинні були бути налаштовані на використання одного й того ж драйвера cgroup, інакше kubelet поводився б неправильно без жодного явного повідомлення про помилку. Це було джерелом головного болю для багатьох адміністраторів кластерів. Тепер ми (майже) поклали край цьому головному болю.

Kubernetes v1.34: Mutable CSI Node Allocatable переходить в Beta

Thu, 11 Sep 2025 10:30:00 -0800

Функція для драйверів CSI, що дозволяє оновлювати інформацію про кількість підключених томів на вузлах, вперше представлена в альфа-версії Kubernetes v1.33, перейшла в бета-версію у випуску Kubernetes v1.34! Це є важливою віхою у підвищенні точності планування podʼівв із збереженням стану шляхом зменшення кількості збоїв, спричинених застарілою інформацією про ємність підключених томів.

Background

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

Kubernetes v1.34: Використання контейнера ініціалізації для визначення змінних середовища застосунку

Wed, 10 Sep 2025 10:30:00 -0800

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

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

Kubernetes v1.34: Кеш сервера API, що підтримує створення знімків стану

Tue, 09 Sep 2025 10:30:00 -0800

Роками спільнота Kubernetes працює над поліпшенням стабільності та передбачуваності продуктивності сервера API. Основна увага в цих зусиллях була зосереджена на обробці запитів list, які історично були основним джерелом високого використання памʼяті та великого навантаження на сховище etcd. З кожним випуском ми поступово розвʼязували цю проблему, і сьогодні ми раді оголосити про завершення останнього великого етапу цього процесу.

Функція кешу сервера API, що підтримує створення знімків, перейшла в бета-версію в Kubernetes v1.34, що стало кульмінацією зусиль впродовж кількох випусків, спрямованих на те, щоб практично всі запити на читання могли обслуговуватися безпосередньо з кешу сервера API.

Kubernetes v1.34: VolumeAttributesClass для зміни атрибутів томів тепер GA

Mon, 08 Sep 2025 10:30:00 -0800

API VolumeAttributesClass, який надає можливість користувачам динамічно змінювати атрибути томів, офіційно перейшов у стадію загальної доступності (GA) у Kubernetes v1.34. Це важлива віхa, яка забезпечує надійний і стабільний спосіб налаштування вашого постійного сховища безпосередньо в Kubernetes.

Що таке VolumeAttributesClass?

По суті, VolumeAttributesClass — це ресурс, що охоплює кластер, який визначає набір змінних параметрів для тому. Розглядайте це як "профіль" для вашого сховища, що дозволяє адміністраторам кластерів експонувати різні рівні якості обслуговування (QoS) або продуктивності.

Kubernetes v1.34: Політика заміни Pod для Jobs переходить у GA

Fri, 05 Sep 2025 10:30:00 -0800

В Kubernetes v1.34, функція Політика заміни Pod досягла загальної доступності (GA). Ця стаття описує функцію політики заміни Pod і те, як її використовувати у ваших Jobs.

Про політику заміни Pod

Стандартно контролер Job негайно відтворює Podʼи, як тільки вони виходять з ладу або починають завершувати роботу (коли вони мають мітку часу видалення).

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

Метрики PSI для Kubernetes переходять у бета-версію

Thu, 04 Sep 2025 10:30:00 -0800

У міру зростання розміру та складності кластерів Kubernetes розуміння стану та продуктивності окремих вузлів стає все більш важливим. Ми раді оголосити, що з Kubernetes v1.34 Метрики інформації про затримки (PSI) перейшли в бета-версію.

Що таке інформація про затримки (PSI)?

Pressure Stall Information (PSI) є функцією ядра Linux (версія 4.20 і новіші), яка забезпечує канонічний спосіб кількісно оцінити тиск на інфраструктурні ресурси з точки зору того, чи перевищує попит на ресурс поточну пропозицію. Вона виходить за межі простих метрик використання ресурсів і натомість вимірює кількість часу, протягом якого завдання затримуються через конкуренцію за ресурси. Це потужний спосіб виявлення та діагностування вузьких місць у ресурсах, які можуть вплинути на продуктивність застосунків.

Kubernetes v1.34: Інтеграція токенів службових облікових записів для витягування образів контейнерів переходить у стадію бета

Wed, 03 Sep 2025 10:30:00 -0800

Спільнота Kubernetes продовжує вдосконалювати найкращі практики безпеки, зменшуючи залежність від довготривалих облікових даних. Після успішного випуску альфа-версії в Kubernetes v1.33, Інтеграція токенів службових облікових записів для постачальників облікових даних Kubelet перейшла на бета-версію в Kubernetes v1.34, що наблизило нас до усунення довготривалих секретів витягування образів контейнерів із кластерів Kubernetes.

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

Kubernetes v1.34: Впровадження опції статичної політики менеджера CPU для розподілу кешу Uncore

Tue, 02 Sep 2025 10:30:00 -0800

Нова опція статичної політики менеджера CPU під назвою prefer-align-cpus-by-uncorecache була представлена в Kubernetes v1.32 як альфа-функція, а в Kubernetes v1.34 вона перейшла в бета-стадію. Ця опція політики менеджера CPU призначена для оптимізації продуктивності конкретних робочих навантажень, що працюють на процесорах з архітектурою розділеного кешу uncore. У цій статті пояснюється, що це означає і чому це корисно.

Розуміння функції

Що таке кеш uncore?

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

Kubernetes v1.34: DRA отримав статус GA

Mon, 01 Sep 2025 10:30:00 -0800

Kubernetes 1.34 вже тут, і він приніс величезну хвилю вдосконалень для Dynamic Resource Allocation (DRA)! Цей реліз знаменує важливу віху: багато API в групі resource.k8s.io отримали статус General Availability (GA), розкриваючи повний потенціал управління пристроями в Kubernetes. Крім того, кілька ключових функцій перейшли до бети, а нова порція альфа-функцій обіцяє ще більше виразності та гнучкості.

Давайте розглянемо, що нового для DRA в Kubernetes 1.34!

Ядро DRA тепер має статус GA

Головною особливістю релізу v1.34 є те, що ядро DRA отримало статус General Availability.

Kubernetes v1.34: Більш точний контроль над перезапуском контейнерів

Fri, 29 Aug 2025 10:30:00 -0800

З виходом Kubernetes 1.34, було представлено нову альфа-функцію, яка надає більш детальний контроль над перезапусками контейнерів у межах Pod. Ця функція, названа Container Restart Policy and Rules, дозволяє вам вказати політику перезапуску для кожного контейнера окремо, перевизначаючи глобальну політику перезапуску Podʼа. Крім того, вона також дозволяє перезапускати окремі контейнери на основі їх кодів виходу. Ця функція доступна за альфа-функціональною можливістю ContainerRestartRules.

Ця функція була давно очікуваною. Розглянемо, як вона працює і як ви можете її використовувати.

Kubernetes v1.34: Налаштування користувача (kuberc) доступні для тестування в kubectl 1.34

Thu, 28 Aug 2025 10:30:00 -0800

Чи хотіли ви будь-коли, щоб ви могли мати стандартно увімкнене інтерактивне видалення у kubectl? Або, можливо, ви хочете визначити власні псевдоніми, але не обовʼязково генерувати сотні з них вручну? Шукайте далі. SIG-CLI наполегливо працює над додаванням налаштувань користувача до kubectl, і ми раді оголосити, що ця функціональність досягає бета-версії в рамках випуску Kubernetes v1.34.

Як це працює

Повний опис цієї функціональності доступний в нашій офіційній документації, але в цьому дописі ми відповімо на обидва питання з початку цієї статті.

Kubernetes v1.34: Of Wind & Will (O' WaW)

Wed, 27 Aug 2025 10:30:00 -0800

Редактори: Agustina Barbetta, Alejandro Josue Leon Bellido, Graziano Casto, Melony Qin, Dipesh Rawat

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

Цей реліз складається з 58 покращень. З них 23 перейшли до стабільного стану, 22 входять до бета-версії, а 13 перейшли до альфа-версії.

У цьому релізі також є застарівання та видалення функцій; обовʼязково ознайомтеся з ними.

Налаштування Linux Swap для Kubernetes: детальний огляд

Tue, 19 Aug 2025 10:30:00 -0800

Функція Kubernetes NodeSwap, яка, ймовірно, отримає статус stable у майбутньому релізі Kubernetes v1.34, дозволяє використання swap: це значна зміна порівняно з традиційною практикою вимкнення swap для передбачуваної продуктивності. Ця стаття зосереджена виключно на налаштуванні swap на вузлах Linux, де ця функція доступна. Дозволяючи вузлам Linux використовувати вторинне сховище для додаткової віртуальної памʼяті, коли фізична RAM вичерпана, підтримка swap на вузлах спрямована на покращення використання ресурсів та зменшення кількості припинень процесів через нестачу памʼяті (OOM kills).

Попередній огляд Kubernetes v1.34

Mon, 28 Jul 2025 00:00:00 +0000

Kubernetes v1.34 очікукється наприкінці серпня 2025 року. Хоча він не міститиме видалень чи застарівань, у ньому буде велика кількість покращень. Ось деякі з функцій, які нас найбільше зацікавили в цьому циклі!

Зверніть увагу, що ця інформація відображає поточний стан розробки v1.34 і може змінитися до випуску нової версії.

Основні покращення Kubernetes v1.34

Нижче наведено деякі з помітних покращень, які, ймовірно, будуть включені до випуску v1.34, але це не вичерпний перелік усіх запланованих змін, і вміст релізу може змінюватися.

Оголошення про випуск etcd v3.6.0

Thu, 15 May 2025 16:00:00 -0800

Це оголошення спочатку було опубліковане в блозі etcd.

Сьогодні ми випускаємо etcd v3.6.0, перший мінорний реліз з моменту випуску etcd v3.5.0 15 червня 2021 року. Цей реліз вводить кілька нових функцій, робить значний прогрес у тривалих зусиллях, таких як підтримка зниження версії та міграція на v3store, і вирішує численні критичні та основні проблеми. Він також включає великі оптимізації в використанні памʼяті, покращуючи ефективність і продуктивність.

На додачу до функцій v3.6.0, etcd приєднався до Kubernetes як SIG (sig-etcd), що дозволяє нам покращити стійкість проєкту. Ми впровадили систематичне тестування на надійність, щоб забезпечити правильність і надійність. За допомоги робочої групи etcd-operator ми плануємо також покращити зручність використання.

Kubernetes v1.33: Оновлення в життєвому циклі контейнерів в Kubernetes v1.33

Wed, 14 May 2025 10:30:00 -0800

У Kubernetes v1.33 представлено декілька оновлень життєвого циклу контейнерів. Дія Sleep для хуків життєвого циклу контейнера тепер підтримує нульову тривалість сну (функція стандартно увімкнена). Також зʼявилася альфа-підтримка для налаштування сигналу зупинки, що надсилається контейнерам при завершенні їхньої роботи.

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

Нульове значення для дії Sleep

У Kubernetes v1.29 введено дію Sleep для хуків життєвого циклу контейнерів PreStop і PostStart. Дія Sleep дозволяє вашим контейнерам призупиняти роботу на певний час після запуску контейнера або перед його завершенням. Це було необхідно для забезпечення простого способу керування відповідним завершенням роботи. До появи дії Sleep люди використовували команду sleep за допомогою дії exec у своїх хуках життєвого циклу контейнера. Якщо ви хочете це зробити, вам потрібно мати двійковий файл для команди sleep в образі вашого контейнера. Це важко зробити, якщо ви використовуєте сторонні образи.

Kubernetes v1.33: Image Pull Policy працює так, як ви завжди вважали!

Mon, 12 May 2025 10:30:00 -0800

Image Pull Policy працює так, як ви завжди вважали!

Деякі речі в Kubernetes дивують, і поведінка imagePullPolicy може бути однією з них. Враховуючи, що Kubernetes - це все про запуск podʼів, може бути дивним дізнатися, що вже більш як 10 років існує застереження щодо обмеження доступу podʼів до автентифікованих образів у вигляді issue 18787! Дуже приємно, коли вдається розвʼязати проблему десятирічної давнини.

Примітка:

У цьому блозі ми часто будемо використовувати термін «облікові дані подів». У цьому контексті цей термін, як правило, інкапсулює автентифікаційні дані, які доступні для podʼів, щоб автентифікувати отримання образу контейнера.

IfNotPresent, навіть якщо я не повинен його мати

Суть проблеми в тому, що стратегія imagePullPolicy: IfNotPresent робила саме те, що в ній сказано, і нічого більше.

Kubernetes 1.33: Заповнювач томів перейшов у стан загальної доступності (GA)

Thu, 08 May 2025 10:30:00 -0800

Заповнювачі томів у Kubernetes тепер загальнодоступні (GA)! Функціональна можливість AnyVolumeDataSource вважається увімкненою у Kubernetes v1.33, що означає, що користувачі можуть вказати будь-який відповідний власний ресурс в якості джерела даних для PersistentVolumeClaim (PVC).

Приклад використання dataSourceRef у PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc1
spec:
 ...
 dataSourceRef:
 apiGroup: provider.example.com
 kind: Provider
 name: provider1

Що нового

У порівнянні з бета-версією є чотири основні покращення.

Заповнювач Pod є опціональним

Під час бета-версії учасники проєкту Kubernetes виявили потенційні витоки ресурсів при видаленні PersistentVolumeClaim (PVC) під час заповнення тома; ці витоки траплялися через обмеження в роботі з завершувачами. Напередодні переходу до стану загальної доступності проєкт Kubernetes додав підтримку видалення тимчасових ресурсів (PVC prime тощо), якщо видалено первинний PVC.

Kubernetes v1.33: Томи Image (Image Volumes) переходять в стан бета!

Tue, 29 Apr 2025 10:30:00 -0800

Томи Image було представлено як альфа фіункціонал в Kubernetes v1.31, як частину KEP-4639. В Kubernetes v1.33, ця функція переходить в стан бета.

Зверніть увагу, що стандартно цю можливість все ще вимкнено, оскільки не всі контейнерні середовища мають повну підтримку цієї можливості. CRI-O підтримує початкову можливість, починаючи з версії v1.31, а у версії v1.33 буде додано підтримку Томів Image як бета-версію. containerd додав підтримку можливості як альфа-версію, яка буде частиною випуску v2.1.0, і працює над бета-версією в рамках PR #11578.

Kubernetes v1.33: Продовження переходу від Endpoints до EndpointSlices

Thu, 24 Apr 2025 10:30:00 -0800

Відтоді як EndpointSlices (KEP-752) з’явились у версії v1.15 як alpha, а згодом стали стабільними (GA) у v1.21, API Endpoints у Kubernetes поступово втрачало актуальність. Нові можливості Service, як-от dual-stack networking та traffic distribution, підтримуються лише через API EndpointSlice, тож усі проксі-сервери сервісів, реалізації Gateway API та подібні контролери мусили перейти від використання Endpoints до EndpointSlices. Станом на сьогодні API Endpoints зберігається здебільшого задля сумісності — щоб не ламати робочі навантаження та скрипти користувачів, які досі його використовують.

Kubernetes v1.33: Octarine

Wed, 23 Apr 2025 10:30:00 -0800

Редактори: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav

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

Цей випуск складається з 64 покращень. З них 18 отримали статус Stable, 20 переходять до бета-версії, 24 — до альфа-версії, а 2 функції вважаються застарілими або вилученими.

У цьому випуску також є кілька помітних застарілостей і вилучень; обовʼязково прочитайте про них, якщо ви вже використовуєте старішу версію Kubernetes.

Попередній огляд Kubernetes v1.33

Wed, 26 Mar 2025 10:30:00 -0800

З наближенням релізу Kubernetes v1.33 проєкт Kubernetes продовжує розвиватися. Функції можуть застарівати вилучатись або замінятись для покращення загального стану проєкту. У цьому дописі описано деякі заплановані зміни для релізу v1.33, про які, на думку команди релізу, вам слід знати, щоб забезпечити безперебійну роботу вашого середовища Kubernetes та залишатися в курсі останніх розробок. Інформація нижче базується на поточному статусі релізу v1.33 і може змінитися до дати фінального випуску.

Процес видалення та застарівання API Kubernetes

Проєкт Kubernetes має добре задокументовану політику застарівання для функцій. Ця політика передбачає, що стабільні API можуть бути застарілими лише тоді, коли доступна новіша, стабільна версія того ж API, і що API мають мінімальний термін служби для кожного рівня стабільності. Застарілий API позначається для видалення в майбутніх релізах Kubernetes. Він продовжуватиме функціонувати до видалення (принаймні через рік після застарівання), але його використання призведе до показу попередження. Видалені API більше недоступні в поточній версії, і в цьому випадку вам потрібно перейти на використання заміни.

Kubernetes v1.32: Penelope

Wed, 11 Dec 2024 00:00:00 +0000

Редактори: Matteo Bianchi, Edith Puclla, William Rizzo, Ryota Sawada, Rashan Smith

Анонсуємо випуск Kubernetes v1.32: Penelope!

Як і у попередніх випусках, у Kubernetes v1.32 представлено нові стабільні, бета- та альфа-версії. Послідовний випуск високоякісних випусків підкреслює силу нашого циклу розробки та активну підтримку нашої спільноти. Цей випуск складається з 44 покращень. З них 13 перейшли до стабільного стану, 12 — до бета-версії, а 19 — до альфа-версії.

Тема та логотип релізу

Темою випуску Kubernetes v1.32 є «Penelope».

Попередній огляд Kubernetes v1.32

Fri, 08 Nov 2024 00:00:00 +0000

Чим ближче до дати випуску Kubernetes v1.32, тим більше проєкт розвивається та вдосконалюється. Функції можуть бути визнані застарілими, видалені або замінені на кращі для загального покращення проєкту.

Тут описані деякі заплановані зміни для випуску Kubernetes v1.32, які, на думку команди випуску, вам слід знати для продовження обслуговування вашого середовища Kubernetes та підтримки в актуальному стані з останніми змінами. Інформація, наведена нижче, базується на поточному стані випуску v1.32 і може змінитися до фактичної дати випуску.

DIY: Створіть власну хмару з Kubernetes (Частина 3)

Fri, 05 Apr 2024 07:40:00 +0000

Наближаючись до найцікавішої фази, ця стаття розглядає запуск Kubernetes всередині Kubernetes. Висвітлюються такі технології, як Kamaji та Cluster API, а також їх інтеграція з KubeVirt.

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

Почнемо з Cluster API.

Cluster API

Cluster API — це розширення для Kubernetes, яке дозволяє керувати кластерами Kubernetes як власними ресурсами користувача всередині іншого кластеру Kubernetes.

DIY: Створіть власну хмару з Kubernetes (Частина 2)

Fri, 05 Apr 2024 07:35:00 +0000

Продовжуємо нашу серію публікацій про те, як побудувати власну хмару, використовуючи лише екосистему Kubernetes. У попередній статті ми пояснили, як підготувати базовий дистрибутив Kubernetes на основі Talos Linux та Flux CD. У цій статті ми покажемо вам кілька різних технологій віртуалізації в Kubernetes та підготуємо все необхідне для запуску віртуальних машин у Kubernetes, зокрема сховища і мережі.

Ми будемо говорити про такі технології, як KubeVirt, LINSTOR і Kube-OVN.

Але спочатку пояснімо, навіщо потрібні віртуальні машини та чому не можна просто використовувати docker-контейнери для побудови хмари? Причина в тому, що контейнери не забезпечують достатнього рівня ізоляції. Хоча ситуація з кожним роком покращується, ми часто стикаємося з вразливостями, які дозволяють вийти з контейнерного середовища і підвищити привілеї в системі.

DIY: Створіть власну хмару з Kubernetes (Частина 1)

Fri, 05 Apr 2024 07:30:00 +0000

У Ænix ми дуже любимо Kubernetes і мріємо, що всі сучасні технології незабаром почнуть використовувати його чудові патерни.

Чи думали ви коли-небудь про створення власної хмари? Я впевнений, що так. Але чи можливо це зробити, використовуючи лише сучасні технології та підходи, не виходячи за межі затишної екосистеми Kubernetes? Наш досвід у розробці Cozystack змусив нас глибоко заглибитись у це питання.

Ви можете стверджувати, що Kubernetes не призначений для цього, і чому б просто не використовувати OpenStack на "звичайних" серверах та запускати Kubernetes всередині нього, як це задумано. Але в цьому випадку ви просто передаєте відповідальність зі своїх рук у руки адміністраторів OpenStack. Це додасть ще одну велику та складну систему до вашої екосистеми.

Огляд Kubernetes v1.30

Tue, 12 Mar 2024 00:00:00 +0000

Швидкий огляд: зміни у Kubernetes v1.30

Новий рік, новий реліз Kubernetes. Ми на половині релізного циклу і маємо чимало цікавих та чудових поліпшень у версії v1.30. Від абсолютно нових можливостей у режимі альфа до вже сталих функцій, які переходять у стабільний режим, а також довгоочікуваних поліпшень — цей випуск має щось для усіх, на що варто звернути увагу!

Щоб підготувати вас до офіційного випуску, ось короткий огляд удосконалень, про які ми найбільше хочемо розповісти!

pkgs.k8s.io: Представляємо репозиторії пакунків від спільноти Kubernetes

Tue, 15 Aug 2023 20:00:00 +0000

Від імені Kubernetes SIG Release, я дуже радий представити репозиторії програмного забезпечення від спільноти Kubernetes, для пакунків Debian та RPM: pkgs.k8s.io! Нові репозиторії пакунків є заміною для репозиторіїв, що надаються Google (apt.kubernetes.io та yum.kubernetes.io), які ми використовували з Kubernetes v1.5.

Цей допис містить інформацію про ці нові репозиторії пакунків. Що це означає для вас як кінцевого користувача, і як перейти на нові репозиторії?

ℹ️ Оновлення (26 березня 2024): застарілі репозиторії, що надаються Google, були прибрані 4 березня 2024. Більше неможливо встановлювати пакунки Kubernetes із застарілих репозиторіїв, що надаються Google. Перегляньте оголошення про припинення підтримки для отримання додаткової інформації про цю зміну.

Mon, 01 Jan 0001 00:00:00 +0000

Кодекс поведінки Спільноти

Як контрибʼютори, координатори (мейнтейнери) та учасники Спільноти CNCF, а також в інтересах сприяння відкритості та привітності спільноти, ми зобовʼязуємось поважати всіх осіб, які беруть участь у житті спільноти або роблять вклад в її діяльність шляхом подання звітів про проблеми, запитів на нові функції, оновлення документації, подання запитів на внесення змін чи виправлень, відвідування конференцій або подій, або участі в інших заходах спільноти або проєкту.

Mon, 01 Jan 0001 00:00:00 +0000

Вимоги:

Вам потрібна машина, що працює під управлінням Linux або macOS.
Вам потрібно встановити ці інструменти:
- Python версії v3.7.x+
- Git
- Golang версії 1.13+
- Pip для встановлення PyYAML
- PyYAML версії v5.1.2
- make
- gcc компілятор/лінкер
- Docker (Потрібен тільки для довідки по команді kubectl)
Ваша змінна середовища PATH повинна включати необхідні інструменти для збірки, такі як бінарники Go та python.
Вам потрібно знати, як створити pull request до репозиторію на GitHub. Це включає створення власного форку репозиторію. Для отримання додаткової інформації дивіться Робота з локальним клоном.

Mon, 01 Jan 0001 00:00:00 +0000

kubeadm: легке розгортання захищеного кластера Kubernetes

Опис

┌──────────────────────────────────────────────────────────┐
│ KUBEADM │
│ Easily bootstrap a secure Kubernetes cluster │
│ │
│ Please give us feedback at: │
│ https://github.com/kubernetes/kubeadm/issues │
└──────────────────────────────────────────────────────────┘

Приклад використання:

Створіть кластер з двох машин з одним вузлом панелі управління
(який керує кластером) та одним робочим вузлом
(де працюють ваші робочі навантаження, такі як Podʼи та Deployments).

┌──────────────────────────────────────────────────────────┐
│ На першій машині: │
├──────────────────────────────────────────────────────────┤
│ control-plane# kubeadm init │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│ На другій машині: │
├──────────────────────────────────────────────────────────┤
│ worker# kubeadm join &lt;arguments-returned-from-init&gt; │
└──────────────────────────────────────────────────────────┘

Повторіть другий крок на стількох інших машинах, скільки потрібно.

-h, --help

Довідка kubeadm

Mon, 01 Jan 0001 00:00:00 +0000

Генерує ключів сертифікатів

Опис

Ця команда виведе захищений випадково згенерований ключ сертифіката, який можна використовувати з командою "init".

Ви також можете скористатися командою "kubeadm init --upload-certs" без зазначення ключа сертифіката, і вона згенерує і виведе його для вас.

kubeadm certs certificate-key [flags]

Параметри

-h, --help
	Довідка certificate-key

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Перевіряє термін дії сертифікатів для кластера Kubernetes

Опис

Перевіряє термін дії сертифікатів у локальному PKI, яким керує kubeadm.

kubeadm certs check-expiration [flags]

Параметри

--allow-missing-template-keys Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується тільки до форматів виведення golang і jsonpath.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Генерує ключі та запити на підписання сертифікатів

Опис

Генерує ключі та запити на підписування сертифікатів (CSRs) для всіх сертифікатів, необхідних для роботи панелі управління. Ця команда також генерує часткові файли kubeconfig з даними приватного ключа в полі "users > user > client-key-data", і для кожного файлу kubeconfig створюється супутній файл ".csr".

Ця команда призначена для використання в Режимі Kubeadm з зовнішнім CA Kubeadm. Вона генерує CSRs, які ви можете подати на підписання до вашого зовнішнього центру сертифікації.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлення сертифікатів для кластера Kubernetes

kubeadm certs renew [flags]

Параметри

-h, --help
	довідка renew

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання адміністратором і для самого kubeadm.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на поточних файлах/сертифікатах, нема потреби їх поновлювати.

Типово поновлення намагається використовувати центр сертифікації в локальному PKI, керованому kubeadm; як альтернативу можна використовувати API сертифікатів K8s для поновлення сертифікатів, або, як останній варіант, згенерувати CSR-запит.

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

Mon, 01 Jan 0001 00:00:00 +0000

Поновлення всіх доступних сертифікатів

Опис

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

kubeadm certs renew all [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-h, --help

Довідка all

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

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

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат, який apiserver використовує для доступу до etcd.

Поновлення виконується безумовно, незалежно від дати закінчення терміну дії сертифіката; додаткові атрибути, такі як SAN, будуть базуватися на наявних файлах/сертифікатах, нема потреби їх поновлювати.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат для сервера API для підключення до kubelet.

Mon, 01 Jan 0001 00:00:00 +0000

Синопсис

Поновлює сертифікат для обслуговування API Kubernetes.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером контролера.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат для проб життєздатності для перевірки стану справності etcd.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат для вузлів etcd, щоб вони могли взаємодіяти один з одним.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат для обслуговування etcd.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлення сертифіката клієнта front proxy.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для використання менеджером планувальника.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Поновлює сертифікат, вбудований у файл kubeconfig для суперкористувача.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Взаємодія з зображеннями контейнерів, які використовує kubeadm

kubeadm config images [flags]

Параметри

-h, --help
	Доввідка images

Параметри успадковані від батьківських команд

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

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

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Виводить список образів, які буде використовувати kubeadm. Файл конфігурації використовується у випадку налаштування будь-яких образів або сховищ образів.

kubeadm config images list [flags]

Параметри

--allow-missing-template-keys Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли у шаблоні відсутнє поле або ключ мапи. Застосовується тільки до форматів виводу golang і jsonpath.

--config string

Шлях до файлу конфігурації kubeadm.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Варіанти:
ControlPlaneKubeletLocalMode=true|false (default=true)
NodeLocalCRISocket=true|false (BETA - default=true)
PublicKeysECDSA=true|false (DEPRECATED - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Витягує образи які використовує kubeadm з реєстру

kubeadm config images pull [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокету для підключення. Якщо порожньо, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--feature-gates string

Набір пар ключ=значення, що описують ворота функцій для різних можливостей. Варіанти:
ControlPlaneKubeletLocalMode=true|false (default=true)
NodeLocalCRISocket=true|false (BETA - default=true)
PublicKeysECDSA=true|false (DEPRECATED - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

Mon, 01 Jan 0001 00:00:00 +0000

Зчитує стару версію типів конфігураційного API kubeadm з файлу і виводе аналогічний обʼєкт конфігурації для нової версії

Опис

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

kubeadm.k8s.io/v1beta4

Крім того, kubeadm може записувати конфігурацію лише версії "kubeadm.k8s.io/v1beta4", але читати обидві версії. Отже, незалежно від того, яку версію ви передаєте параметру --old-config, API обʼєкт буде прочитано, десеріалізовано, встановлено стандартні значення, конвертовано, валідовано та повторно серіалізовано під час запису у stdout або --new-config, якщо вказано.

Mon, 01 Jan 0001 00:00:00 +0000

Вивід конфігурації

Опис

Ця команда виводить конфігурацію вказаних субкоманд. Докладніше: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Параметри

-h, --help
	довідка print

Параметри успадковані від батьківських команд

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Вивід стандартної конфігурації ініціалізації, яка може використовуватись у kubeadm init.

Опис

Ця команда виводить обʼєкти, такі як стандартну конфігурацію ініціалізації, які можуть бути використані у kubeadm init.

Зверніть увагу, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print init-defaults [flags]

Параметри

--component-configs strings

Список обʼєктів API конфігурації компонентів через кому для виводу типових значень. Доступні значення: [KubeProxyConfiguration KubeletConfiguration]. Якщо цей прапорець не встановлено, конфігурації компонентів не буде надруковано.

Mon, 01 Jan 0001 00:00:00 +0000

Вивід стандартної конфігурації для команди kubeadm join.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди join, яка використовується для 'kubeadm join'.

kubeadm config print join-defaults [flags]

Параметри

-h, --help
	довідка join-defaults

Параметри успадковані від батьківських команд

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Виводить стандартну конфігурацію для команди kubeadm reset.

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди reset, яка використовується для 'kubeadm reset'.

Зауважте, що конфіденційні значення, такі як поля Bootstrap Token, замінюються значеннями-заповнювачами, такими як "abcdef.0123456789abcdef", щоб пройти перевірку, але не виконувати реальні дії для створення токена.

kubeadm config print reset-defaults [flags]

Параметри

-h, --help
	Довідка reset-defaults

Параметри успадковані від батьківських команд

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Виводить стандартну конфігурацію для оновлення, яка може бути використана для 'kubeadm upgrade'

Опис

Ця команда виводить обʼєкти, такі як стандартна конфігурація команди upgrade, яка використовується для 'kubeadm upgrade'.

kubeadm config print upgrade-defaults [flags]

Параметри

-h, --help

Довідка upgrade-defaults

Mon, 01 Jan 0001 00:00:00 +0000

Зчитує файл, що містить конфігураційний API kubeadm, і повідомляє про будь-які проблеми під час валідації

Опис

Ця команда дозволяє перевірити файл конфігурації API kubeadm та повідомити про будь-які попередження та помилки. Якщо помилок немає, статус виводу буде нульовим, в іншому випадку він буде ненульовим. Будь-які проблеми з розбором, такі як невідомі поля API, спричинять помилки. Невідомі версії API та поля з недійсними значеннями також спричинять помилки. Будь-які інші помилки або попередження можуть бути повідомлені залежно від вмісту вхідного файлу.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу "init".

kubeadm init phase [flags]

Параметри

-h, --help
	Довідка phase

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Встановлює необхідні надбудови для проходження тестів на відповідність

kubeadm init phase addon [flags]

Параметри

-h, --help
	Довідка addon

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Вставляє всі надбудови.

kubeadm init phase addon all [flags]

Параметри

--apiserver-advertise-address string

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

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

Mon, 01 Jan 0001 00:00:00 +0000

Встановлює надбудову CoreDNS в кластер Kubernetes

Опис

Встановлює компоненти надбудови CoreDNS через сервер API. Зверніть увагу, що хоча DNS-сервер розгорнуто, його не буде заплановано, доки не буде встановлено CNI.

kubeadm init phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--feature-gates string

Набір пар ключ=значення, що описують функціональні можливості для різних функцій. Опції:
ControlPlaneKubeletLocalMode=true|false (default=true)
NodeLocalCRISocket=true|false (BETA - default=true)
PublicKeysECDSA=true|false (DEPRECATED - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

Mon, 01 Jan 0001 00:00:00 +0000

Встановлює надбудову kube-proxy в кластер Kubernetes

Опис

Встановлює компоненти надбудови kube-proxy через API-сервер.

kubeadm init phase addon kube-proxy [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane-endpoint string

Вказує стабільну IP-адресу або DNS-імʼя для панелі управління.

Mon, 01 Jan 0001 00:00:00 +0000

Генерує токени bootstrap, які використовуються для приєднання вузла до кластера

Опис

Токени bootstrap використовуються для встановлення двосторонньої довіри між вузлом, що приєднується до кластера, і вузлом панелі управління.

Ця команда виконує всі налаштування, необхідні для роботи токенів bootstrap, а потім створює початковий токен.

kubeadm init phase bootstrap-token [flags]

Приклади

# Налаштувати всі конфігурації токенів Bootstrap та створити 
# початковий токен, функціонально еквівалентний до того, що 
# генерується командою kubeadm init.
kubeadm init phase bootstrap-token

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Генерує сертифікати

Опис

Генерує сертифікати

kubeadm init phase certs [flags]

Параметри

-h, --help
	Довідка certs

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує всі сертифікати.

kubeadm init phase certs all [flags]

Параметри

--apiserver-advertise-address string

--apiserver-cert-extra-sans strings

Додаткові опціональні альтернативні імена субʼєкта (SANs) для використання в сертифікаті обслуговування API Server. Можуть бути як IP-адреси, так і DNS імена.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати, які apiserver використовує для доступу до etcd та зберігає їх у файлах apiserver-etcd-client.crt та apiserver-etcd-client.key

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-etcd-client [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати для сервера API для зʼєднання з kubelet та зберігає їх у файлах apiserver-kubelet-client.crt та apiserver-kubelet-client.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver-kubelet-client [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати для обслуговування API Kubernetes та зберігає їх у файли apiserver.crt та apiserver.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs apiserver [flags]

Операції

--apiserver-advertise-address string

--apiserver-cert-extra-sans strings

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує самопідписаний центр сертифікації Kubernetes, щоб надати ідентифікатори для інших компонентів Kubernetes та зберігає їх у файлах ca.crt та ca.key.

Якщо обидва файли вже існують, kubeadm оминає крок створення і використовує наявні файли.

kubeadm init phase certs ca [flags]

Операції

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Генерує самопідписаний центр сертифікації для надання ідентифікаторів для etcd

Опис

Ця команда генерує самопідписаний центр сертифікації (CA) для надання ідентифікаторів для etcd, та зберігає їх у файлах etcd/ca.crt та etcd/ca.key.

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

kubeadm init phase certs etcd-ca [flags]

Операції

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікат для проб життєздатності для перевірки справності etcd, та зберігає його у файлах etcd/healthcheck-client.crt та etcd/healthcheck-client.key.

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

kubeadm init phase certs etcd-healthcheck-client [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати для вузлів etcd для звʼязку між собою, та зберігає їх у файлах etcd/peer.crt та etcd/peer.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

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

kubeadm init phase certs etcd-peer [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати для обслуговування etcd, та зберігає їх у файлах etcd/server.crt та etcd/server.key.

Типові SANs: localhost, 127.0.0.1, 127.0.0.1, ::1

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

kubeadm init phase certs etcd-server [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує самопідписні CA для надання ідентифікаторів для front proxy, та зберігає їх у файлах front-proxy-ca.crt та front-proxy-ca.key.

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

kubeadm init phase certs front-proxy-ca [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати для клієнта front proxy, та зберігає їх у файлах front-proxy-client.crt та front-proxy-client.key.

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

kubeadm init phase certs front-proxy-client [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі

Опис

Генерує приватний ключ для підпису токенів службових облікових записів, що дозволяє їм мати власні публічні ключі, та записує їх у файли sa.key та sa.pub.

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

kubeadm init phase certs sa [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує всі маніфести статичних Podʼів потрібні для створення панелі управління

kubeadm init phase control-plane [flags]

Параметри

-h, --help
	Довідка control-plane

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує всі файли маніфестів статичних Podʼів.

kubeadm init phase control-plane all [flags]

Приклади

# Генерує всі файли маніфестів статичних Podʼів для компонентів панелі управління,
# функціонально еквівалентні до тих, що генеруються командою kubeadm init.
kubeadm init phase control-plane all

# Генерує всі файли маніфестів статичних Podʼів з використанням опцій, отриманих з конфігураційного файлу.
kubeadm init phase control-plane all --config config.yaml

Параметри

--apiserver-advertise-address string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує маніфест статичного Podʼа для kube-apiserver

kubeadm init phase control-plane apiserver [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує маніфест статичного Podʼа для kube-controller-manager

kubeadm init phase control-plane controller-manager [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка controller-manager

--image-repository string Типово: "registry.k8s.io"

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

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує маніфест статичного Podʼа для kube-scheduler

kubeadm init phase control-plane scheduler [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

-o, --experimental-output string Типово: "text"

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка scheduler

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local etcd

kubeadm init phase etcd [flags]

Параметри

-h, --help
	Довідка etcd

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує файл маніфесту статичного Podʼа для екземпляра local, одновузлового local etcd

kubeadm init phase etcd local [flags]

Приклади

# Генерує файл маніфесту статичного Podʼа для etcd, функціонально
# еквівалентного до того, що генерується командою kubeadm init.
kubeadm init phase etcd local

# Генерує файл маніфесту статичного Podʼа для etcd з використанням опцій
# отриманих з файлу конфігурації.
kubeadm init phase etcd local --config config.yaml

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує всі файли kubeconfig, необхідні для встановлення панелі управління та файл kubeconfig адміністратора

kubeadm init phase kubeconfig [flags]

Параметри

-h, --help
	Довідка kubeconfig

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Генерує файл kubeconfig для використання адміністратором та для самого kubeadm

Опис

Ця команда генерує файл kubeconfig для використання адміністратором та для самого kubeadm й зберігає його у файл admin.conf.

kubeadm init phase kubeconfig admin [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує всі файли kubeconfig.

kubeadm init phase kubeconfig all [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Генерує файл kubeconfig для використання менеджером контролерів

Опис

Генерує файл kubeconfig для використання менеджером контролерів та зберігає його у файл controller-manager.conf.

kubeadm init phase kubeconfig controller-manager [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

Mon, 01 Jan 0001 00:00:00 +0000

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження

Опис

Генерує файл kubeconfig, для kubelet для використання лише для потреб початкового завантаження та зберігає його у файлі kubelet.conf.

Зауважте, що цей файл має використовуватись лише для потреб початкового завантаження кластера. Після розгортання панелі управління, ви маєте запросити облікові дані для kubelet через CSR API.

kubeadm init phase kubeconfig kubelet [flags]

Параметри

--apiserver-advertise-address string

Mon, 01 Jan 0001 00:00:00 +0000

Генерує файл kubeconfig для використання планувальником

Опис

Генерує файл kubeconfig для використання планувальником та зберігає його у файл scheduler.conf.

kubeadm init phase kubeconfig scheduler [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує файл kubeconfig для суперкористувача та зберігає його у файл super-admin.conf.

kubeadm init phase kubeconfig super-admin [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлює налаштування, що стосуються kubelet, після початкового завантаження TLS

kubeadm init phase kubelet-finalize [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS"
kubeadm init phase kubelet-finalize all --config

Параметри

-h, --help
	Довідка kubelet-finalize

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Запускає всі фази kubelet-finalize.

kubeadm init phase kubelet-finalize all [flags]

Приклади

# Оновлення налаштувань, що стосуються kubelet, після початкового завантаження TLS
kubeadm init phase kubelet-finalize all --config

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Вмикає ротацію сертифікатів клієнтів kubelet

kubeadm init phase kubelet-finalize enable-client-cert-rotation [flags]

Параметри

Параметри успадковані від батьківських команд

--cert-dir string Типово: "/var/run/kubernetes"
	Тека, в якій знаходяться TLS-сертифікати. Якщо вказано --tls-cert-file та --tls-private-key-file, цей прапорець буде проігноровано.
--config string
	Шлях до файлу конфігурації.
--dry-run
	Не застосовувати жодних змін; просто вивести, що буде зроблено.
-h, --help
	Довідка enable-client-cert-rotation

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Записує налаштування kubelet та (пере)запускаємо kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запустимо kubelet.

kubeadm init phase kubelet-start [flags]

Приклади

# Записує файл динамічного оточення з прапорами kubelet з файлу InitConfiguration.
kubeadm init phase kubelet-start --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Позначає вузол як вузол панелі управління.

kubeadm init phase mark-control-plane [flags]

Приклади

# Застосовує мітку та taint панелі управління до поточного вузла, функціонально еквівалентно до того, що виконується командою kubeadm init.
kubeadm init phase mark-control-plane --config config.yaml

# Застосовує мітку та taint панелі управління до конкретного вузла
kubeadm init phase mark-control-plane --node-name myNode

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Виконує передпольотні перевірки для kubeadm init.

kubeadm init phase preflight [flags]

Приклади

# Виконує передпольотні перевірки для kubeadm init з конфігураційним файлом config.yaml
kubeadm init phase preflight --config config.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Показує команду join для панелі управління та робочого вузла.

kubeadm init phase show-join-command [flags]

Параметри

-h, --help
	Довідка show-join-command

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Завантажує сертифікати до kubeadm-certs

Опис

Завантажує сертифікати панелі управління в Secret kubeadm-certs

kubeadm init phase upload-certs [flags]

Параметри

--certificate-key string

Ключ, що використовується для шифрування сертифікатів панелі управління у Secret kubeadm-certs. Ключ сертифіката — це шістнадцятковий рядок, який є ключем AES розміром 32 байти

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантажує конфігурації kubeadm та kubelet у ConfigMap

kubeadm init phase upload-config [flags]

Параметри

-h, --help
	Довідка upload-config

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантажує всю конфігурацію в ConfigMap.

kubeadm init phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантажує конфігурацію кластера kubeadm ClusterConfig до ConfigMap з назвою kubeadm-config у просторі імен kube-system. Це дозволить правильно конфігурувати компоненти системи та спростить роботу користувачів під час оновлення.

Альтернативно, ви можете використовувати kubeadm config.

kubeadm init phase upload-config kubeadm [flags]

Приклади

# Завантаження конфігурації кластера
kubeadm init phase upload-config kubeadm --config=myConfig.yaml

Параметри

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Завантажує налаштування компонентів kubelet у ConfigMap

Опис

Завантажуємо конфігурацію kubelet, видобуту з обʼєкта kubeadm InitConfiguration, до ConfigMap kubelet-config у кластері

kubeadm init phase upload-config kubelet [flags]

Приклади

# Завантаження конфігурації kubelet з файла конфігурації kubeadm у ConfigMap в кластері
kubeadm init phase upload-config kubelet --config kubeadm.yaml

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Очікує, поки панель управління запуститься.

kubeadm init phase wait-control-plane [flags]

Параметри

-h, --help
	Довідка wait-control-plane

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу "join"

kubeadm join phase [flags]

Параметри

-h, --help
	Довідка phase

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Приєднує машину до екземпляра панелі управління.

kubeadm join phase control-plane-join [flags]

Приклади

# Приєднує машину до екземпляра панелі управління
kubeadm join phase control-plane-join all

Параметри

-h, --help
	Довідка control-plane-join

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Приєднує машину до екземпляру панелі управління.

kubeadm join phase control-plane-join all [flags]

Параметри

--apiserver-advertise-address string

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Додає нового учасника local etcd

kubeadm join phase control-plane-join etcd [flags]

Параметри

--apiserver-advertise-address string

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Позначає вузол як вузол панелі управління.

kubeadm join phase control-plane-join mark-control-plane [flags]

Параметри

--config string
	Шлях до конфігураційного файлу kubeadm.
--control-plane
	Створити новий екземпляр панелі управління на цьому вузлі
--dry-run
	Не застосовувати жодних змін; просто вивести, що буде зроблено.
-h, --help
	Довідка mark-control-plane
--node-name string
	Вкажіть імʼя вузла.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Готує машину до обслуговування панелі управління.

kubeadm join phase control-plane-prepare [flags]

Приклади

# Готує машину до обслуговування панелі управління
kubeadm join phase control-plane-prepare all

Параметри

-h, --help
	Довідка control-plane-prepare

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Готує машину для роботи як панелі управління.

kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує сертифікати для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags]

Параметри

--apiserver-advertise-address string

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

--discovery-file string

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

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує маніфести для нових компонентів панелі управління.

kubeadm join phase control-plane-prepare control-plane [flags]

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантажує сертифікати, спільні для вузлів панелі управління, з архіву kubeadm-certs Secret

kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [flags]

Параметри

--certificate-key string

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Генерує kubeconfig для нових компонентів панелі управління, які будуть додані до кластера.

kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags]

Параметри

--certificate-key string

--config string

Шлях до конфігураційного файлу kubeadm.

--control-plane

Створити новий екземпляр панелі управління на цьому вузлі

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Приєднати etcd до вузлів панелі управління

kubeadm join phase etcd-join [flags]

Приклади

# Приєднати etcd до екземпляра панелі управління
kubeadm join phase control-plane-join-etcd all

Параметри

--apiserver-advertise-address string

Якщо вузол має хостити новий екземпляр панелі управління, IP-адреса, яку сервер API буде оголошувати як ту, на якій він слухає. Якщо не встановлено, буде використовуватися стандартний інтерфейс.

--config string

Шлях до файлу конфігурації kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Записує налаштування kubelet, сертифікати та (пере)запускає kubelet

Опис

Записує файл з KubeletConfiguration та файл оточення з налаштуваннями kubelet для конкретного вузла, а потім (пере)запускає kubelet.

kubeadm join phase kubelet-start [api-server-endpoint] [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--cri-socket string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Чекати, поки kubelet завантажиться

kubeadm join phase kubelet-wait-bootstrap [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

--cri-socket string

Шлях до CRI сокета для підключення. Якщо не встановлено, kubeadm спробує автоматично визначити це значення; використовуйте цей параметр, лише якщо у вас встановлено більше одного CRI або якщо у вас нестандартний CRI сокет.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Виконує передполітні перевірки join

Опис

Виконує передполітні перевірки для kubeadm join.

kubeadm join phase preflight [api-server-endpoint] [flags]

Приклади

# Виконує передполітні перевірки для kubeadm join
kubeadm join phase preflight --config kubeadm-config.yaml

Параметри

--apiserver-advertise-address string

--apiserver-bind-port int32 Типово: 6443

Порт, до якого API-сервер буде привʼязуватися.

--certificate-key string

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Очікує запуску панелі управління

kubeadm join phase wait-control-plane [flags]

Параметри

-h, --help
	Довідка wait-control-plane

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Виводить файл kubeconfig для додаткового користувача.

kubeadm kubeconfig user [flags]

Приклади

# Виводить файл kubeconfig для додаткового користувача з іменем foo
kubeadm kubeconfig user --client-name=foo

# Виводить файл kubeconfig для додаткового користувача з іменем foo, використовуючи конфігураційний файл kubeadm bar
kubeadm kubeconfig user --client-name=foo --config=bar

Параметри

--client-name string

Імʼя користувача. Буде використовуватися як CN у разі створення клієнтських сертифікатів

--config string

Шлях до конфігураційного файлу kubeadm.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Використовуйте цю команду для виклику однієї фази процесу "reset"

kubeadm reset phase [flags]

Параметри

-h, --help
	Довідка phase

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Запускає очищення вузла.

kubeadm reset phase cleanup-node [flags]

Параметри

--cert-dir string Типово: "/etc/kubernetes/pki"

Шлях, де будуть збережені сертифікати

--cleanup-tmp-dir

Очистити теку "/etc/kubernetes/tmp"

--cri-socket string

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Виконує передполітні перевірки для kubeadm reset

Опис

Виконує передполітні перевірки для kubeadm reset.

kubeadm reset phase preflight [flags]

Параметри

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-f, --force

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

-h, --help

Довідка preflight

--ignore-preflight-errors strings

Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки від усіх перевірок.

Mon, 01 Jan 0001 00:00:00 +0000

Опмс

Видаляє члена local etcd для вузла панелі управління.

kubeadm reset phase remove-etcd-member [flags]

Параметри

--dry-run
	Не застосовувати жодних змін; просто вивести, що буде зроблено.
-h, --help
	Довідка remove-etcd-member
--kubeconfig string Типово: "/etc/kubernetes/admin.conf"
	Файл kubeconfig, який використовується для спілкування з кластером. Якщо прапорець не встановлено, може буити переглянутий набір стандартних місць для пошуку наявного файлу kubeconfig.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Створює токени запуску на сервері.

Опис

[token] — це власне токен, який потрібно записати. Це має бути безпечно згенерований випадковий токен виду "[a-z0-9]{6}.[a-z0-9]{16}". Якщо [token] не вказано, kubeadm згенерує випадковий токен замість нього.

kubeadm token create [token]

Параметри

--certificate-key string

Якщо використовується разом із '--print-join-command', виводить повний прапорець 'kubeadm join', необхідний для приєднання до кластера як панелі управління. Щоб створити новий ключ сертифіката, потрібно використовувати 'kubeadm init phase upload-certs --upload-certs'.

Mon, 01 Jan 0001 00:00:00 +0000

Видаляє токени запуску на сервері.

Опис

Ця команда видаляє токени запуску для вас.

Значення [token-value] — це повний токен у вигляді "[a-z0-9]{6}.[a-z0-9]{16}" або Token ID виду "[a-z0-9]{6}", який потрібно видалити.

kubeadm token delete [token-value] ...

Параметри

-h, --help
	довідка delete

Параметри успадковані від батьківських команд

--dry-run

Чи ввімкнути режим dry-run чи ні

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

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

Mon, 01 Jan 0001 00:00:00 +0000

Генерує та виводить токен запуску, але не створює його на сервері

Опис

Ця команда виведе випадково згенерований токен запуску, який можна використовувати з командами "init" та "join".

Ви не зобовʼязані використовувати цю команду для створення токена. Ви можете зробити це самостійно, якщо він має формат "[a-z0-9]{6}.[a-z0-9]{16}". Ця команда надається для зручності створення токенів у зазначеному форматі.

Ви також можете використовувати "kubeadm init" без вказання токена, і він буде згенерований та виведений для вас.

Mon, 01 Jan 0001 00:00:00 +0000

Виводить перелік токенів запуску на сервері

Опис

Ця команда виведе перелік всіх токенів запуску на сервері.

kubeadm token list [flags]

Параметри

--allow-missing-template-keys Типово: true

Якщо true, ігноруйте будь-які помилки в шаблонах, коли поле або ключ map відсутні в шаблоні. Застосовується лише до форматів виводу golang і jsonpath.

-h, --help

довідка list

-o, --output string Типово: "text"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлює кластер Kubernetes до вказаної версії.

Команда "apply [version]" виконує наступні етапи:

preflight Виконання перевірок перед запуском
control-plane Оновлення панелі управління
upload-config Завантаження конфігурації kubeadm та kubelet у ConfigMapі
 /kubeadm Завантаження конфігурації кластера kubeadm у ConfigMap
 /kubelet Завантаження конфігурації компоненту kubelet у ConfigMap
kubelet-config Оновлення конфігурації kubelet для цього вузла
bootstrap-token Налаштування токену bootstrap та правил cluster-info RBAC
addon Оновлення типових надбудов kubeadm
 /coredns Оновлення надбудови CoreDNS
 /kube-proxy Оновлення надбудови kube-proxy
post-upgrade Запуск завдань після оновлення

kubeadm upgrade apply [version]

Параметри

--allow-experimental-upgrades

Показує нестабільні версії Kubernetes як альтернативу для оновлення і дозволяє оновлювати до альфа/бета/версій кандидатів Kubernetes.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу "apply"

kubeadm upgrade apply phase [flags]

-h, --help
	Довідка phase

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлює стандартні надбудови kubeadm

kubeadm upgrade apply phase addon [flags]

Параметри

-h, --help
	Довідка addon

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

Оновлює всі надбудови

kubeadm upgrade apply phase addon all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

Оновлення надбудови CoreDNS

kubeadm upgrade apply phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка coredns

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлює надбудову kube-proxy

kubeadm upgrade apply phase addon kube-proxy [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Налаштовує токен bootstrap та правила cluster-info RBAC

kubeadm upgrade apply phase bootstrap-token [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка bootstrap-token

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлення панелі управління

kubeadm upgrade apply phase control-plane [flags]

Параметри

--certificate-renewal Типово: true

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

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлення конфігурації kubelet для цього вузла, завантаживши її з файлу kubelet-config ConfigMap, що зберігається у кластері

kubeadm upgrade apply phase kubelet-config [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Запуск завдань після оновлення

kubeadm upgrade apply phase post-upgrade [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка post-upgrade

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Запуск передпольотних перевірок перед оновленням

kubeadm upgrade apply phase preflight [flags]

Параметри

--allow-experimental-upgrades

--allow-release-candidate-upgrades

Показує версії кандидатів на випуск Kubernetes як альтернативу для оновлення і дозволяє оновлювати до версій кандидатів на випуск Kubernetes.

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантаження конфігурацій kubeadm та kubelet до ConfigMaps

kubeadm upgrade apply phase upload-config [flags]

-h, --help
	Довідка for upload-config

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантаження всіх конфігурацій до ConfigMaps

kubeadm upgrade apply phase upload-config all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантаження конфігурації кластера kubeadm ClusterConfiguration до ConfigMap

kubeadm upgrade apply phase upload-config kubeadm [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubeadm

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Завантаження конфігурації kubelet до ConfigMap

kubeadm upgrade apply phase upload-config kubelet [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Показує які відмінності можуть бути застосовані до наявних маніфестів статичних Pod. Дивіться також: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [version] [flags]

Параметри

--config string

Шлях до файлу конфігурації kubeadm.

-c, --context-lines int Типово: 3

Скільки рядків контексту в виведенні diff.

-h, --help

довідка diff

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

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

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Команда upgrade для вузлів в кластері.

Команда "node" виконує наступні фази:

preflight Виконання попереднії перевірок оновлення вузла
control-plane Оновлення екземпляру панелі управління, розгорнутий на цьому вузлі, якщо такий є
kubelet-config Оновлення конфігурацію kubelet для цього вузла
addon Оновлення стандартних надбудов kubeadm
 /coredns Оновлення надбудови CoreDNS
 /kube-proxy Оновлення надбудови kube-proxy
post-upgrade Запуск завдань після оновлення

kubeadm upgrade node [flags]

Параметри

--certificate-renewal Типово: true

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

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Використовуйте цю команду для виклику однієї фази робочого процесу "node"

kubeadm upgrade node phase [flags]

Параметри

-h, --help
	Довідка phase

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлення стандартних надбудов kubeadm

kubeadm upgrade node phase addon [flags]

Параметри

-h, --help
	Довідка addon

Параметри успадковані від батьківських команд

--rootfs string
	Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлення всіх надбудов

kubeadm upgrade node phase addon all [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка all

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлення надбудови CoreDNS

kubeadm upgrade node phase addon coredns [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка coredns

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлення надбудови kube-proxy

kubeadm upgrade node phase addon kube-proxy [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kube-proxy

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Оновлює екземпляр панелі управління, розгорнутої на цьому вузлі, якщо така є.

kubeadm upgrade node phase control-plane [flags]

Параметри

--certificate-renewal Типово: true

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

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

--etcd-upgrade Типово: true

Виконує оновлення etcd.

-h, --help

Довідка control-plane

Mon, 01 Jan 0001 00:00:00 +0000

Опис

kubeadm upgrade node phase kubelet-config [flags]

Параметри

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка kubelet-config

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Запуск завдань після оновлення

kubeadm upgrade node phase post-upgrade [flags]

--config string

Шлях до конфігураційного файлу kubeadm.

--dry-run

Не застосовувати жодних змін; просто вивести, що буде зроблено.

-h, --help

Довідка post-upgrade

--kubeconfig string Типово: "/etc/kubernetes/admin.conf"

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Ця команда виконує попередні перевірки для kubeadm upgrade node.

kubeadm upgrade node phase preflight [flags]

Параметри

--config string
	Шлях до конфігураційного файлу kubeadm.
-h, --help
	Довідка preflight
--ignore-preflight-errors strings
	Список перевірок, помилки яких будуть показані як попередження. Приклад: 'IsPrivilegedUser,Swap'. Значення 'all' ігнорує помилки всіх перевірок.

Параметри успадковані від батьківських команд

--rootfs string

Шлях до реальної кореневої файлової системи хоста. Це призведе до зміни корення (chroot) kubeadm на вказаних шлях

Mon, 01 Jan 0001 00:00:00 +0000

Опис

Перевіряє, до яких версій можна оновитися, і перевіряє, чи можна оновити ваш поточний кластер. Ця команда може бути виконана лише на вузлах панелі управління, де існує файл kubeconfig "admin.conf". Щоб пропустити перевірку Інтернету, вкажіть необовʼязковий параметр [version].

kubeadm upgrade plan [version] [flags]

Параметри

--allow-experimental-upgrades

Показати нестабільні версії Kubernetes як альтернативу для оновлення і дозволити оновлення до альфа/бета/кандидатів на випуск версій Kubernetes.

--allow-missing-template-keys Типово: true

Якщо true, ігнорувати будь-які помилки в шаблонах, коли поле або ключ map відсутній у шаблоні. Застосовується лише до форматів виведення golang та jsonpath.

Mon, 01 Jan 0001 00:00:00 +0000

Щоб запустити тести для локалізації, скористайтеся наступною командою:

go test k8s.io/website/content/<lang>/examples

де <lang> — це двосимвольне позначення мови. Наприклад:

go test k8s.io/website/content/en/examples

Mon, 01 Jan 0001 00:00:00 +0000

Документація Kubernetes

Цей репозиторій містить матеріали потрібні для створення вебсайту Kubernetes та документації. Ми раді, що ви хочете зробити свій внесок!

Користування цим репозиторієм

Ви можете запустити вебсайт локально, використовуючи Hugo (розширена версія), або ви можете запустити його в контейнерному середовищі. Ми наполегливо рекомендуємо використовувати контейнерне середовище, оскільки воно забезпечує однорідність розгортання та подібність до основного вебсайту.

Необхідні умови

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

Client Authentication (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

ExecCredential

`ExecCredential`

ExecCredential використовується втулками на основі exec для передачі облікових даних до HTTP транспортів.

Поле	Опис
`apiVersion` string	`client.authentication.k8s.io/v1`
`kind` string	`ExecCredential`
`spec` [Обовʼязкове] `ExecCredentialSpec`	Spec містить інформацію, передану транспортом втулку.
`status` `ExecCredentialStatus`	Status заповнюється втулоком і містить облікові дані, які транспорт повинен використовувати для контакту з API.

`Cluster`

Зустрічається в:

ExecCredentialSpec

Cluster містить інформацію, що дозволяє exec втулку спілкуватися з кластером Kubernetes, до якого здійснюється автентифікація.

Щоб забезпечити наявність у цій структурі всього необхідного для звʼязку з кластером Kubernetes (як це робиться через kubeconfig), поля повинні відображати структуру "k8s.io/client-go/tools/clientcmd/api/v1". Cluster, за винятком CertificateAuthority, оскільки дані CA завжди будуть передаватися втулку у вигляді байтів.

Client Authentication (v1beta1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

ExecCredential

`ExecCredential`

ExecCredential використовується втулками на основі exec для передачі облікових даних до HTTP транспортів.

Поле	Опис
`apiVersion` string	`client.authentication.k8s.io/v1beta1`
`kind` string	`ExecCredential`
`spec` [Обовʼязкове] `ExecCredentialSpec`	Spec містить інформацію, передану транспортом втулку.
`status` `ExecCredentialStatus`	Status заповнюється втулком і містить облікові дані, які транспорт повинен використовувати для контакту з API.

`Cluster`

Зустрічається в:

ExecCredentialSpec

Event Rate Limit Configuration (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

Configuration

`Configuration`

Configuration надає конфігурацію для контролера доступу EventRateLimit.

Поле	Опис
`apiVersion` string	`eventratelimit.admission.k8s.io/v1alpha1`
`kind` string	`Configuration`
`limits` [Обовʼязкове] `[]Limit`	limits — це обмеження на запити подій, що надходять. Обмеження можуть бути встановлені на події, отримані на рівні сервера, на рівні простору імен, на рівні користувача та на рівні джерела+обʼєкта. Потрібно принаймні одне обмеження.

`Limit`

Зустрічається в:

Configuration

Limit — це конфігурація для певного типу обмеження.

Поле Опис

type [Обовʼязкове]
LimitType

type — це тип обмеження, до якого застосовується ця конфігурація.

Image Policy API (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

ImageReview

`ImageReview`

ImageReview перевіряє, чи дозволений набір образів у поді.

Поле	Опис
`apiVersion` string	`imagepolicy.k8s.io/v1alpha1`
`kind` string	`ImageReview`
`metadata` `meta/v1.ObjectMeta`	Стандартні метадані обʼєкта. Докладніше: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata. Зверніться до документації Kubernetes API для полів метаданих `metadata`.
`spec` [Обовʼязкове] `ImageReviewSpec`	Spec містить інформацію про под, що оцінюється.
`status` `ImageReviewStatus`	Status заповнюється бекендом і вказує, чи слід дозволити Pod.

`ImageReviewContainerSpec`

Зустрічається в:

ImageReviewSpec

ImageReviewContainerSpec — це опис контейнера в запиті на створення Podʼа.

Поле Опис

image
string

Це може бути у вигляді image:tag або image@SHA:012345679abcdef.

kube-apiserver Admission (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

AdmissionReview

`AdmissionReview`

AdmissionReview описує запит/відповідь на перегляд доступу.

Поле	Опис
`apiVersion` string	`admission.k8s.io/v1`
`kind` string	`AdmissionReview`
`request` `AdmissionRequest`	request описує атрибути запиту на перегляд доступу.
`response` `AdmissionResponse`	response описує атрибути відповіді на перегляд доступу.

`AdmissionRequest`

Зʼявляється в:

AdmissionReview

AdmissionRequest описує атрибути доступу для запиту на перегляд доступу.

Поле Опис

uid [Обовʼязкове]
k8s.io/apimachinery/pkg/types.UID

uid — це ідентифікатор для індивідуального запиту/відповіді. Це дозволяє нам розрізняти випадки запитів, які є в іншому випадку ідентичними (паралельні запити, запити, коли попередні запити не змінили і т. д.). UID призначений для відстеження зворотного звʼязку (запит/відповідь) між KAS і WebHook, а не користувацьким запитом. Він підходить для співставлення записів журналу між вебхуком і apiserver для аудиту або налагодження.

kube-apiserver Audit Configuration (v1)

Mon, 01 Jan 0001 00:00:00 +0000

`Event`

Зустрічається в:

EventList

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

Поле Опис

apiVersion
string audit.k8s.io/v1

kind
string Event

level [Обовʼязково]
Level

Рівень аудиту, на якому була згенерована подія.

auditID [Обовʼязково]
k8s.io/apimachinery/pkg/types.UID

Унікальний ідентифікатор аудиту, згенерований для кожного запиту.

stage [Обовʼязково]
Stage

Стадія обробки запиту, коли був згенерований цей екземпляр події.

requestURI [Обовʼязково]
string

RequestURI — це URI запиту, який був надісланий клієнтом на сервер.

kube-apiserver Configuration (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Пакет v1 — це версія API v1.

Типи ресурсів

AdmissionConfiguration
AuthenticationConfiguration
AuthorizationConfiguration
EncryptionConfiguration
TracingConfiguration

`TracingConfiguration`

Зʼявляється в:

KubeletConfiguration
TracingConfiguration
TracingConfiguration
TracingConfiguration

TracingConfiguration надає версійну конфігурацію для клієнтів трасування OpenTelemetry.

Поле Опис

endpoint
string

Точка доступу колектора, до якої цей компонент буде надсилати трейси. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендовано не встановлювати, точкою доступу є стандартне значення otlp grpc, localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — це кількість зразків, які потрібно зібрати на мільйон відрізків. Рекомендується не встановлювати. Якщо не встановлено, семплер дотримується частоти дискретизації батьківського відрізка, але в іншому випадку ніколи не виконує дискретизацію.

kube-apiserver Configuration (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Пакет v1alpha1 — це версія API v1alpha1.

Типи ресурсів

AdmissionConfiguration
AuthenticationConfiguration
AuthorizationConfiguration
EgressSelectorConfiguration
TracingConfiguration

`TracingConfiguration`

Зʼявляється в:

KubeletConfiguration
TracingConfiguration

TracingConfiguration надає версійну конфігурацію для клієнтів OpenTelemetry tracing.

Поле Опис

endpoint
string

Endpoint колектора, куди цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендується не вказувати, і використовувати стандартно otlp grpc localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — це кількість зразків, які потрібно збирати на мільйон проміжків. Рекомендується не вказувати. Якщо не вказано, зразок буде відповідати ставці зразка батьківського проміжку, але інакше ніколи не буде зібраний.

kube-apiserver Configuration (v1beta1)

Mon, 01 Jan 0001 00:00:00 +0000

Пакет v1beta1 є версією v1beta1 API.

Типи ресурсів

AuthenticationConfiguration
AuthorizationConfiguration
EgressSelectorConfiguration
TracingConfiguration

`TracingConfiguration`

З’являється в:

KubeletConfiguration
TracingConfiguration
TracingConfiguration

TracingConfiguration надає версійні налаштування для клієнтів трасування OpenTelemetry.

Поле Опис

endpoint
string

Точка доступу колектора, до якого цей компонент буде надсилати трасування. Зʼєднання є незахищеним і наразі не підтримує TLS. Рекомендовано не встановлювати, стандартна точка доступу для otlp grpc — localhost:4317.

samplingRatePerMillion
int32

SamplingRatePerMillion — це кількість зразків для збору на мільйон відрізків. Рекомендовано не встановлювати. Якщо не задано, семплер дотримується частоти дискретизації батьківського діапазону а якщо ні, то ніколи не робить вибірки.

kube-controller-manager Configuration (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

CloudControllerManagerConfiguration
LeaderMigrationConfiguration
KubeControllerManagerConfiguration

`ClientConnectionConfiguration`

Зʼявляється у:

KubeSchedulerConfiguration
GenericControllerManagerConfiguration

ClientConnectionConfiguration містить деталі для конструювання клієнта.

Поле Опис

kubeconfig [Обовʼязково]
string

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes [Обовʼязково]
string

acceptContentTypes визначає заголовок Accept, що надсилається клієнтами при підключенні до сервера, замінюючи стандартне значення 'application/json'. Це поле буде контролювати всі зʼєднання з сервером, що використовуються конкретним клієнтом.

contentType [Обовʼязково]
string

contentType — тип контенту, який використовується при надсиланні даних на сервер з цього клієнта.

kube-proxy Configuration (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

KubeProxyConfiguration

`FormatOptions`

Зʼявляється в:

LoggingConfiguration

FormatOptions містить опції для різних форматів журналювання.

Поле	Опис
`text` [Обовʼязково] `TextOptions`	[Alpha] Текст містить опції для формату логування "текст". Доступно лише тоді, коли увімкнено функцію LoggingAlphaOptions.
`json` [Обовʼязково] `JSONOptions`	[Alpha] JSON містить опції для формату логування "json". Доступно лише тоді, коли увімкнено функцію LoggingAlphaOptions.

`JSONOptions`

Зʼявляється в:

FormatOptions

JSONOptions містить опції для формату логування "json".

Поле	Опис
`OutputRoutingOptions` [Обовʼязково] `OutputRoutingOptions`	(Члени `OutputRoutingOptions` вбудовуються у цей тип.) Немає опису.

`LogFormatFactory`

LogFormatFactory надає підтримку певного додаткового, не стандартного формату журналу.

kube-scheduler Configuration (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

DefaultPreemptionArgs
DynamicResourcesArgs
InterPodAffinityArgs
KubeSchedulerConfiguration
NodeAffinityArgs
NodeResourcesBalancedAllocationArgs
NodeResourcesFitArgs
PodTopologySpreadArgs
VolumeBindingArgs

`ClientConnectionConfiguration`

Зʼявляється у:

KubeSchedulerConfiguration

ClientConnectionConfiguration містить деталі для створення клієнта.

Поле Опис

kubeconfig [Обовʼязкове]
string

kubeconfig — шлях до файлу KubeConfig.

acceptContentTypes [Обовʼязкове]
string

acceptContentTypes визначає заголовок Accept, який надсилається клієнтами при підключенні до сервера, перевизначаючи стандатне значення 'application/json'. Це поле буде контролювати всі зʼєднання з сервером, що використовуються певним клієнтом.

contentType [Обовʼязкове]
string

contentType — тип вмісту, який використовується при надсиланні даних на сервер від цього клієнта.

kubeadm Configuration (v1beta3)

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

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

Список змін з версії v1beta2:

Видалено застаріле поле "ClusterConfiguration.useHyperKubeImage". Kubeadm більше не підтримує образ hyperkube.
Поле "ClusterConfiguration.dns.type" було видалено, оскільки CoreDNS є єдиним типом DNS-сервера, який підтримується kubeadm.
Додано теги "datapolicy" до полів, які містять секрети. Це призведе до того, що значення полів буде пропущено, коли структури API буде надруковано за допомогою klog.
Додано "InitConfiguration.skipPhases", "JoinConfiguration.SkipPhases", щоб дозволити пропустити список фаз під час виконання команд kubeadm init/join.
Додано "InitConfiguration.nodeRegistration.imagePullPolicy" та "JoinConfiguration.nodeRegistration.imagePullPolicy", щоб дозволити вказати політику отримання образів під час kubeadm "init" та "join". Значення має бути одним з "Always", "Never" або "IfNotPresent". "IfNotPresent" — це стандартне значення, яке використовувалося до цього оновлення.
Додано "InitConfiguration.patches.directory", "JoinConfiguration.patches.directory", щоб дозволити користувачеві конфігурувати теку, з якої буде братися патч для компонентів, розгорнутих за допомогою kubeadm.
Перенесено API BootstrapToken* та повʼязані з ним утиліти з групи API "kubeadm" до нової групи "bootstraptoken". API kubeadm версії v1beta3 більше не містить структур BootstrapToken*.

Міграція зі старих версій конфігурації kubeadm

kubeadm Configuration (v1beta4)

Mon, 01 Jan 0001 00:00:00 +0000

Огляд

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

Список змін з версії v1beta3:

v1.35:

Додано поле httpEndpoints до ClusterConfiguration.etcd.externalEtcd, яке можна використовувати для налаштування точок доступу HTTP для комунікації etcd у v1beta4. Це поле використовується для відокремлення трафіку HTTP (такого як точки доступу /metrics та /health) від трафіку gRPC, що обробляється endpoints. Таке розділення дозволяє краще контролювати доступ, оскільки точки доступу HTTP можуть бути відкриті без відкриття основного інтерфейсу gRPC. Відповідає конфігурації etcd --listen-client-http-urls. Якщо не вказано, endpoints буде використовуватися як для трафіку gRPC, так і для трафіку HTTP.

v1.34:

kubeconfig (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

Config

`Config`

Config містить інформацію, необхідну для підключення до віддалених кластерів Kubernetes як вказаний користувач

Поле Опис

apiVersion
string /v1

kind
string Config

kind
string

Спадкове поле з pkg/api/types.go TypeMeta. TODO(jlowdermilk): видалити його після усунення залежностей з низхідних напрямків.

apiVersion
string

Спадкове поле з pkg/api/types.go TypeMeta. TODO(jlowdermilk): видалити його після усунення залежностей з низхідних напрямків.

preferences,omitzero [Обовʼязкове]
Preferences

Preferences містить загальну інформацію для використання у взаємодії з CLI. Застаріле: це поле застаріле в версії 1.34. Воно не використовується жодним із компонентів Kubernetes.

Kubelet Configuration (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Типы ресурсов

CredentialProviderConfig

`CredentialProviderConfig`

CredentialProviderConfig є конфігурацією, що містить інформацію про кожного exec credential provider. Kubelet читає цю конфігурацію з диска та активує кожного провайдера відповідно до типу CredentialProvider.

Поле Опис

apiVersion
string kubelet.config.k8s.io/v1

kind
string CredentialProviderConfig

providers [Обовʼязково]
[]CredentialProvider

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

Kubelet Configuration (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

CredentialProviderConfig
ImagePullIntent
ImagePulledRecord

`CredentialProviderConfig`

CredentialProviderConfig є конфігурацією, що містить інформацію про кожен втулок облікових даних exec. Kubelet читає цю конфігурацію з диска та активує кожен втулок відповідно до типу CredentialProvider.

Поле Опис

apiVersion
string kubelet.config.k8s.io/v1alpha1

kind
string CredentialProviderConfig

providers [Обовʼязково]
[]CredentialProvider

Kubelet Configuration (v1beta1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

CredentialProviderConfig
ImagePullIntent
ImagePulledRecord
KubeletConfiguration
SerializedNodeConfigSource

`FormatOptions`

Зʼявляється в:

LoggingConfiguration

FormatOptions містить параметри для різних форматів логування.

Поле	Опис
`text` [Обовʼязково] `TextOptions`	[Alpha] Text містить параметри для формату логування "text". Доступно лише при увімкненій функціональній можливості LoggingAlphaOptions.
`json` [Обовʼязково] `JSONOptions`	[Alpha] JSON містить параметри для формату журналювання "json". Доступно лише при увімкненій функціональній можливості LoggingAlphaOptions.

`JSONOptions`

Зʼявляється в:

FormatOptions

JSONOptions містить параметри для формату логування "json".

Поле	Опис
`OutputRoutingOptions` [Обовʼязково] `OutputRoutingOptions`	(Члени `OutputRoutingOptions` вбудовані в цей тип.) Опис не надано.

`LogFormatFactory`

LogFormatFactory забезпечує підтримку певного додаткового формату логу, який не є стандартним.

Kubelet CredentialProvider (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

CredentialProviderRequest
CredentialProviderResponse

`CredentialProviderRequest`

CredentialProviderRequest включає образ, для якого kubelet вимагає автентифікацію. Kubelet передасть цей обʼєкт запиту втулку через stdin. Загалом втулки повинні відповідати тією ж версією API, яку вони отримали.

Поле Опис

apiVersion
string credentialprovider.kubelet.k8s.io/v1

kind
string CredentialProviderRequest

image [Обовʼязкове]
string

image — це образ контейнеа, який завантажується в рамках запиту втулка для автентифікатора. Втулки можуть за бажанням розпарсити образ для отримання будь-якої інформації, необхідної для отримання облікових даних.

serviceAccountToken [Обовʼязково]
string

serviceAccountToken - токен службового облікового запису, привʼязаного до пода, для якого витягується образ. Цей токен надсилається до втулка, лише якщо у конфігурації постачальника облікових даних kubelet'а вказано поле tokenAttributes.serviceAccountTokenAudience.

kuberc (v1alpha1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

Preference

`Preference`

Preference зберігає елементи конфігураційного файлу KubeRC

Поле Опис

apiVersion
string kubectl.config.k8s.io/v1alpha1

kind
string Preference

overrides [Обовʼязково]
[]CommandDefaults

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

aliases [Обовʼязково]
[]AliasOverride

aliases дозволяє визначати псевдоніми команд для наявних команд kubectl з необовʼязковими стандартними значеннями прапорців. Якщо імʼя аліасу збігається з вбудованою командою, вбудована команда завжди має пріоритет. Зміни прапорців, визначені в секції overrides, не застосовуються до аліасів для тієї ж команди. kubectl [ALIAS NAME] [USER_FLAGS] [USER_EXPLICIT_ARGS] розширюється до kubectl [COMMAND] # вбудований аліас команди вказує на [KUBERC_PREPEND_ARGS] [USER_FLAGS] [KUBERC_FLAGS] # решта прапорців, які не передані користувачем у [USER_FLAGS] [USER_EXPLICIT_ARGS] [KUBERC_APPEND_ARGS] наприклад.

kuberc (v1beta1)

Mon, 01 Jan 0001 00:00:00 +0000

Типи ресурсів

Preference

`Preference`

Preference зберігає елементи конфігураційного файлу KubeRC

Поле Опис

apiVersion
string kubectl.config.k8s.io/v1beta1

kind
string Preference

defaults [Обовʼязкове]
[]CommandDefaults

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

aliases [Обовʼязкове]
[]AliasOverride

aliases дозволяє визначати аліаси команд для наявних команд kubectl із необовʼязковими стандартними значеннями опцій. Якщо імʼя аліасу збігається з вбудованою командою, вбудована команда завжди має пріоритет. Параметри, перевизначені в розділі defaults, НЕ застосовуються до аліасів для тієї самої команди. kubectl [ALIAS NAME] [USER_OPTIONS] [USER_EXPLICIT_ARGS] розширюється до kubectl [COMMAND] # вбудований аліас команди вказує на [KUBERC_PREPEND_ARGS] [ USER_OPTIONS] [KUBERC_OPTIONS] # решта опцій, які не передаються користувачем у [USER_OPTIONS] [USER_EXPLICIT_ARGS] [KUBERC_APPEND_ARGS] наприклад

Kubernetes Custom Metrics (v1beta2)

Mon, 01 Jan 0001 00:00:00 +0000

Пакунок v1beta2 - це версія v1beta2 API custom_metrics.

Типи ресурсів

MetricListOptions
MetricValue
MetricValueList

`MetricListOptions`

MetricListOptions використовується для вибору метрик за їх селекторами міток

Поле	Опис
`apiVersion` string	`custom.metrics.k8s.io/v1beta2`
`kind` string	`MetricListOptions`
`labelSelector` `string`	Селектор для обмеження списку обʼєктів, що повертаються, за їхніми мітками. Стандартно — всі обʼєкти.
`metricLabelSelector` `string`	Селектор для обмеження списку метрик, що повертаються, за їхніми мітками

`MetricValue`

Зʼявляється в:

MetricValueList

MetricValue — це значення метрики для певного обʼєкта.

Поле Опис

apiVersion
string custom.metrics.k8s.io/v1beta2

kind
string MetricValue

describedObject [Обовʼязково]
core/v1.ObjectReference

посилання на описуваний обʼєкт

Kubernetes External Metrics (v1beta1)

Mon, 01 Jan 0001 00:00:00 +0000

Пакет v1beta1 є версією v1beta1 зовнішнього API метрик.

Типи ресурсів

ExternalMetricValue
ExternalMetricValueList

`ExternalMetricValue`

Зʼявляється в:

ExternalMetricValueList

ExternalMetricValue — це значення метрики для зовнішньої метрики. Окрема метрика ідентифікується за назвою метрики та набором рядкових міток. Для однієї метрики може бути кілька значень з різними наборами міток.

Поле Опис

apiVersion
string external.metrics.k8s.io/v1beta1

kind
string ExternalMetricValue

metricName [Обовʼязково]
string

назва метрики

metricLabels [Обовʼязково]
map[string]string

набір міток, які ідентифікують один часовий ряд для метрики

timestamp [Обовʼязково]
meta/v1.Time

вказує час, коли були створені метрики

Kubernetes Metrics (v1beta1)

Mon, 01 Jan 0001 00:00:00 +0000

Пакет v1beta1 є версією v1beta1 API метрик.

Типи ресурсів

NodeMetrics
NodeMetricsList
PodMetrics
PodMetricsList

`NodeMetrics`

Зʼявляється в:

NodeMetricsList

NodeMetrics встановлює метрики використання ресурсів вузла.

Поле	Опис
`apiVersion` string	`metrics.k8s.io/v1beta1`
`kind` string	`NodeMetrics`
`metadata` `meta/v1.ObjectMeta`	Стандартні метадані обʼєкта. Більше інформації: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata Звіряйтесь з документацією Kubernetes API для полів `metadata`.
`timestamp` [Обовʼязково] `meta/v1.Time`	Наступні поля визначають інтервал часу, з якого метрики були зібрані, з інтервалу [Timestamp-Window, Timestamp].
`window` [Обовʼязково] `meta/v1.Duration`	Опис відсутній.
`usage` [Обовʼязково] `core/v1.ResourceList`	Використання памʼяті — це робочий набір памʼяті.

`NodeMetricsList`

NodeMetricsList — це список NodeMetrics.

WebhookAdmission Configuration (v1)

Mon, 01 Jan 0001 00:00:00 +0000

Пакунок v1 є версією v1 API.

Типи ресурсів

WebhookAdmission

`WebhookAdmission`

WebhookAdmission надає конфігурацію для контролера доступу на основі webhook.<

Поле	Опис
`apiVersion` string	`apiserver.config.k8s.io/v1`
`kind` string	`WebhookAdmission`
`kubeConfigFile` [Обовʼязкове] `string`	KubeConfigFile — це шлях до файлу kubeconfig.

Довідник Метрик Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Метрики (v1.35)

Ця сторінка містить деталі метрик, які експортують різні компоненти Kubernetes. Ви можете запитувати точки доступу метрик для цих компонентів за допомогою HTTP-запиту та отримувати поточні дані метрик у форматі Prometheus.

Список стабільних метрик Kubernetes

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

apiserver_admission_controller_admission_duration_seconds

Гістограма затримки контролера допуску в секундах, визначена за назвою та розподілена для кожної операції та ресурсу API і типу (перевірка або допуск).

Рівень стабільності:STABLE
Тип: Histogram
Мітки:nameoperationrejectedtype

apiserver_admission_step_admission_duration_seconds

Гістограма затримки підетапу допуску в секундах для кожної операції, ресурсу API та типу етапу (валідація або допуск).

Рівень стабільності:STABLE
Тип: Histogram
Мітки:operationrejectedtype

apiserver_admission_webhook_admission_duration_seconds

Гістограма затримки вебхука в секундах, ідентифікована за назвою та розбита за кожною операцією, ресурсом API та типом (валідація або допуск).

Рівень стабільності:STABLE
Тип: Histogram
Мітки:nameoperationrejectedtype

apiserver_current_inflight_requests

Максимальна кількість поточних використаних запитів цього apiserver на тип запиту за останню секунду.

Рівень стабільності:STABLE
Тип: Gauge
Мітки:request_kind

apiserver_longrunning_requests

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

Рівень стабільності:STABLE
Тип: Gauge
Мітки:componentgroupresourcescopesubresourceverbversion

apiserver_request_duration_seconds

Розподіл затримки відповіді в секундах для кожного дієслова, значення dry run, групи, версії, ресурсу, субресурсу, області застосування та компонента.

Рівень стабільності:STABLE
Тип: Histogram
Мітки:componentdry_rungroupresourcescopesubresourceverbversion

apiserver_request_total

Лічильник запитів apiserver з розбивкою по кожному дієслову, dry run, групі, версії, ресурсу, області застосування, компоненту і коду HTTP-відповіді.

Рівень стабільності:STABLE
Тип: Counter
Мітки:codecomponentdry_rungroupresourcescopesubresourceverbversion

apiserver_requested_deprecated_apis

Вимірювач запитуваних застарілих API, розподілених за групами API, версією, ресурсом, субресурсом і видаленим_випуском.

Рівень стабільності:STABLE
Тип: Gauge
Мітки:groupremoved_releaseresourcesubresourceversion

apiserver_response_sizes

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

Рівень стабільності:STABLE
Тип: Histogram
Мітки:componentgroupresourcescopesubresourceverbversion

apiserver_storage_objects

[ЗАСТАРІЛО, розгляньте можливість використання apiserver_resource_objects замість цього]Кількість збережених обʼєктів на момент останньої перевірки з розподілом за типом. У разі помилки вибірки значення буде -1.

Рівень стабільності:STABLE
Тип: Gauge
Мітки:resource
Застаріло у версіях:1.34.0

apiserver_storage_size_bytes

Розмір сховища для файлу бази даних, фізично виділеного в байтах.

Рівень стабільності:STABLE
Тип: Custom
Мітки:storage_cluster_id

container_cpu_usage_seconds_total

Сукупний час процесора, який споживає контейнер, у секундах ядра

Рівень стабільності:STABLE
Тип: Custom
Мітки:containerpodnamespace

container_memory_working_set_bytes

Поточний робочий набір контейнера в байтах

Рівень стабільності:STABLE
Тип: Custom
Мітки:containerpodnamespace

container_start_time_seconds

Час запуску контейнера в секундах епохи Unix

Рівень стабільності:STABLE
Тип: Custom
Мітки:containerpodnamespace

cronjob_controller_job_creation_skew_duration_seconds

Час між запланованим запуском cronjob і створенням відповідного завдання

Рівень стабільності:STABLE
Тип: Histogram

job_controller_job_pods_finished_total

Кількість завершених Podʼів, які повністю відстежуються

Рівень стабільності:STABLE
Тип: Counter
Мітки:completion_moderesult

job_controller_job_sync_duration_seconds

Час, необхідний для синхронізації завдання

Рівень стабільності:STABLE
Тип: Histogram
Мітки:actioncompletion_moderesult

job_controller_job_syncs_total

Кількість синхронізацій завдання

Рівень стабільності:STABLE
Тип: Counter
Мітки:actioncompletion_moderesult

job_controller_jobs_finished_total

Кількість завершених завдань

Рівень стабільності:STABLE
Тип: Counter
Мітки:completion_modereasonresult

kube_pod_resource_limit

Ліміт ресурсів для робочих навантажень в кластері, з розбивкою за Podʼами. Це показує використання ресурсів, яке планувальник і kubelet очікують на кожен Pod для ресурсів, а також одиницю виміру для ресурсу, якщо така є.

Рівень стабільності:STABLE
Тип: Custom
Мітки:namespacepodnodeschedulerpriorityresourceunit

kube_pod_resource_request

Ресурси, запитувані робочими навантаженнями в кластері, з розбивкою за Podʼами. Це показує використання ресурсів, яке планувальник і kubelet очікують на кожен Pod для ресурсів, а також одиницю виміру для ресурсу, якщо така є.

Рівень стабільності:STABLE
Тип: Custom
Мітки:namespacepodnodeschedulerpriorityresourceunit

kubernetes_healthcheck

Ця метрика фіксує результат однієї перевірки справності.

Рівень стабільності:STABLE
Тип: Gauge
Мітки:nametype

kubernetes_healthchecks_total

Ця метрика фіксує результати всіх перевірок справності.

Рівень стабільності:STABLE
Тип: Counter
Мітки:namestatustype

node_collector_evictions_total

Кількість виселень Node, що відбулися з моменту запуску поточного екземпляра NodeController.

Рівень стабільності:STABLE
Тип: Counter
Мітки:zone

node_cpu_usage_seconds_total

Сукупний час процесора, споживаний вузлом у секундах ядра

Рівень стабільності:STABLE
Тип: Custom

node_memory_working_set_bytes

Поточний робочий набір вузла в байтах

Рівень стабільності:STABLE
Тип: Custom

pod_cpu_usage_seconds_total

Сукупний час процесора, споживаний Podʼом у секундах ядра

Рівень стабільності:STABLE
Тип: Custom
Мітки:podnamespace

pod_memory_working_set_bytes

Поточний робочий набір Podʼа в байтах

Рівень стабільності:STABLE
Тип: Custom
Мітки:podnamespace

resource_scrape_error

1, якщо сталася помилка під час отримання метрик контейнера, 0 в іншому випадку

Рівень стабільності:STABLE
Тип: Custom

scheduler_framework_extension_point_duration_seconds

Затримка для запуску всіх втулків певної точки розширення.

Рівень стабільності:STABLE
Тип: Histogram
Мітки:extension_pointprofilestatus

scheduler_pending_pods

Кількість відкладених Podʼів за типом черги. 'active' означає кількість Podʼів в activeQ; 'backoff' означає кількість Pods у backoffQ; 'unschedulable' означає кількість Podʼів в unschedulablePods, які планувальник намагався запланувати, але не зміг; 'gated' означає кількість незапланованих Podʼів, які планувальник ніколи не намагався запланувати, тому що вони є gated.

Рівень стабільності:STABLE
Тип: Gauge
Мітки:queue

scheduler_pod_scheduling_attempts

Кількість спроб успішно запланувати Pod.

Рівень стабільності:STABLE
Тип: Histogram

scheduler_preemption_attempts_total

Загальна кількість спроб випередження в кластері до цього часу

Рівень стабільності:STABLE
Тип: Counter

scheduler_preemption_victims

Кількість обраних жертв випередження

Рівень стабільності:STABLE
Тип: Histogram

scheduler_queue_incoming_pods_total

Кількість Podʼів, доданих до черг планування за подіями та типами черг.

Рівень стабільності:STABLE
Тип: Counter
Мітки:eventqueue

scheduler_schedule_attempts_total

Кількість спроб запланувати Podʼи, за результатом. "unscheduled" означає, що Pod не вдалося запланувати, тоді як "error" означає внутрішню проблему планувальника.

Рівень стабільності:STABLE
Тип: Counter
Мітки:profileresult

scheduler_scheduling_attempt_duration_seconds

Затримка спроби планування в секундах (алгоритм планування + привʼязка)

Рівень стабільності:STABLE
Тип: Histogram
Мітки:profileresult

Список бета-метрик Kubernetes

Бета-метрики дотримуються менш суворих API контрактів порівняно зі стабільними метриками. Жодні мітки не можуть бути видалені з бета-метрик протягом їхнього життєвого циклу, проте мітки можуть бути додані, поки метрика перебуває на етапі бета-тестування. Це забезпечує впевненість у тому, що бета-метрики підтримуватимуть існуючі панелі моніторингу та оповіщення, водночас дозволяючи вносити зміни в майбутньому.

Зміна репозиторія пакунків Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює, як увімкнути репозиторій пакунків для бажаного мінорного випуску Kubernetes під час оновлення кластера. Це потрібно лише для користувачів репозиторіїв пакунків, що підтримуються спільнотою та розміщені на pkgs.k8s.io. На відміну від застарілих репозиторіїв пакунків, репозиторії пакунків, що підтримуються спільнотою, структуровані таким чином, що для кожної мінорної версії Kubernetes є окремий репозиторій пакунків.

Примітка:

Цей посібник охоплює лише частину процесу оновлення Kubernetes. Для отримання додаткової інформації про оновлення кластерів Kubernetes див. посібник з оновлення.

Примітка:

Цей крок потрібно виконати лише під час оновлення кластера до іншого мінорного випуску. Якщо ви оновлюєтеся до іншого патч-релізу в межах тієї самої мінорної версії (наприклад, з v1.35.5 до v1.35.7), вам не потрібно дотримуватися цього посібника. Однак, якщо ви все ще використовуєте застарілі репозиторії пакунків, вам потрібно перейти на нові репозиторії пакунків, які підтримуються спільнотою, перед оновленням (див. наступний розділ для отримання деталей про те, як це зробити).

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

У цьому документі припускається, що ви вже використовуєте репозиторії пакунків, які підтримуються спільнотою (pkgs.k8s.io). Якщо це не так, наполегливо рекомендується перейти на репозиторії пакунків, які підтримуються спільнотою, як описано в офіційному оголошенні.

Змінювані політики допуску

Mon, 01 Jan 0001 00:00:00 +0000

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

На цій сторінці ви можете ознайомитися з інформацією про MutatingAdmissionPolicies. MutatingAdmissionPolicies дозволяють вам змінювати те, що відбувається, коли хтось вносить зміни до API Kubernetes. Якщо ви хочете використовувати декларативні політики лише для запобігання певному виду змін ресурсів (наприклад: захист платформених просторів імен від видалення), ValidatingAdmissionPolicy є простішою та ефективнішою альтернативою.

Щоб використовувати цю функцію, увімкніть функціональну можливість MutatingAdmissionPolicy (яка стандартно є вимкненою) і встановіть --runtime-config=admissionregistration.k8s.io/v1beta1=true на kube-apiserver.

Кодекс поведінки спільноти Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes дотримується Кодексу поведінки CNCF. Текст Кодексу поведінки CNCF відтворено нижче, коміт 71412bb02.

Кодекс поведінки Спільноти

Налагодження запущених Podʼів

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка пояснює, як налагоджувати Podʼи, що запущені (або зазнають збою) на вузлі.

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

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

Використання `kubectl describe pod` для отримання деталей про Podʼи

Для цього прикладу ми використовуватимемо Deployment для створення двох Podʼів, схожих на попередній приклад.

Налаштування ротації сертифікатів для Kubelet

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як увімкнути та налаштувати ротацію сертифікатів для kubelet.

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

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

Потрібна версія Kubernetes 1.8.0 або пізніша

Огляд

Kubelet використовує сертифікати для автентифікації в Kubernetes API. Типово ці сертифікати створюються з терміном дії один рік, щоб їх не потрібно було оновлювати занадто часто.

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

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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Переконфігурація стандартного ServiceCIDR Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

У цьому документі описано, як переналаштувати стандартний діапазон IP-адрес Service, призначених кластеру.

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

Покращення документації Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Цей вебсайт підтримується робочою групою Kubernetes SIG Docs. Проєкт Kubernetes вітає допомогу від усіх учасників, незалежно від їхнього досвіду!

Учасники, які мають намір працювати з документацією Kubernetes можуть:

Вдосконалювати наявний вміст
Створювати новий вміст
Перекладати документацію
Керувати та публікувати документацію під час релізного циклу Kubernetes

Команда блогів, частина SIG Docs, допомагає керувати офіційними блогами. Щоб дізнатися більше, прочитайте участь у блогах Kubernetes.

Примітка:

Щоб дізнатися більше про те, як зробити свій внесок в Kubernetes загалом, перегляньте загальний сайт документації для учасників.

Початок роботи

Будь-хто може відкрити тікет щодо документації або внести зміни через запит на злиття (PR) в репозиторій GitHub kubernetes/website. Для ефективної роботи в спільноті Kubernetes вам слід вміти працювати з git та GitHub.

Поради щодо налагодження Windows

Mon, 01 Jan 0001 00:00:00 +0000

Розвʼязання проблем на рівні вузла

Мої Podʼи застрягли на "Container Creating" або постійно перезавантажуються.

Переконайтеся, що ваш образ pause відповідає версії вашої операційної системи Windows. Див. Контейнер pause для перегляду останнього/рекомендованого образу pause та/або отримання додаткової інформації.

Примітка:
Якщо ви використовуєте containerd як оточення для виконання контейнерів, образ pause вказується в полі plugins.plugins.cri.sandbox_image файлу конфігурації config.toml.
Мої Podʼи показують статус як ErrImgPull або ImagePullBackOff.

Переконайтеся, що ваш Pod планується на сумісний вузол Windows.

Правила перевірки допуску

Mon, 01 Jan 0001 00:00:00 +0000

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

Ця сторінка надає огляд правил перевірки допуску.

Що таке правила перевірки допуску?

Правила перевірки допуску пропонують декларативну, вбудовану альтернативу веб-хукам перевірки допуску.

Правила перевірки допуску використовують мову загальних виразів (Common Expression Language, CEL). Правила перевірки допуску мають високу налаштовуваність, що дозволяє авторам визначати правила, які можуть бути параметризовані та обмежені ресурсами за необхідності адміністраторами кластера.

Які ресурси складають правила

Зазвичай правило складається з трьох ресурсів:

Приклад від Box

Mon, 01 Jan 0001 00:00:00 +0000

Виклик

Заснована у 2005 році, компанія з управління корпоративним контентом дозволяє своїм більш ніж 50 мільйонам користувачів керувати контентом у хмарі. Box був побудований в основному на використанні апаратного забезпечення у власних центрах обробки даних компанії, з монолітною кодовою базою PHP. Оскільки компанія розширювалася в глобальному масштабі, їй потрібно було зосередитися на тому, "як розподіляти робоче навантаження між різними хмарними інфраструктурами — від "bare metal" до публічної хмари", — розповідає Сем Годс, співзасновник і архітектор сервісів Box. "Це було величезним викликом, оскільки різні хмари, особливо "голий метал", мають дуже різні інтерфейси".

Ручна ротація сертифікатів центру сертифікації (CA)

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка показує, як робити вручну ротацію сертифікатів центру сертифікації (CA).

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

Сторінка тестування документації

Mon, 01 Jan 0001 00:00:00 +0000

Ця сторінка має дві мети:

Показати, як документація Kubernetes використовує Markdown
Надати документ "тестування", який можна використовувати для перевірки змін в HTML, CSS та шаблонах, що впливають на загальну документацію.

Рівні заголовків

Вищезазначений заголовок є H2. Заголовок сторінки відображається як H1. Наступні секції показують H3 - H6.

### H3

Заголовок H3.

#### H4

Заголовок H4.

##### H5

Заголовок H5.

###### H6

Заголовок H6.

Перетворюється на:

Управління TLS сертифікатами в кластері

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes надає API certificates.k8s.io, який дозволяє вам отримувати TLS сертифікати, підписані Центром Сертифікації (CA), який ви контролюєте. Ці CA та сертифікати можуть використовуватися вашими робочими навантаженнями для встановлення довіри.

API certificates.k8s.io використовує протокол, подібний до чернетки ACME.

Примітка:

Сертифікати, створені за допомогою API certificates.k8s.io, підписуються спеціальним CA. Можливо налаштувати ваш кластер так, щоб використовувати кореневий кластерний CA для цієї мети, але не слід на це покладатися. Не припускайте, що ці сертифікати будуть перевірятися кореневим кластерним CA.

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

Цикл випуску Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

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

Орієнтація на поліпшення, Тікети та PR для віх випуску

Цей документ орієнтований на розробників та учасників Kubernetes, які повинні створювати поліпшення, тікети або pull request (PR), що спрямовані на конкретну віху випуску.

TL;DR
Визначення
Цикл випуску
Видалення елементів з віхи
Додавання елемента до віхи
Інші обовʼязкові мітки

Процес управління поліпшеннями, тікетами та pull request у випуску Kubernetes охоплює кілька зацікавлених сторін:

Система оркестрування контейнерів промислового класу on Kubernetes

APIService

APIService

APIServiceSpec

Babylon Case Study

Задача

Рішення

ConfigMap

ConfigMap

CustomResourceDefinition

CustomResourceDefinition

CustomResourceDefinitionSpec

DeleteOptions

FlowSchema

FlowSchema

FlowSchemaSpec

LocalSubjectAccessReview

LocalSubjectAccessReview

MutatingAdmissionPolicyBindingList v1beta1

Pod

Pod

PodSpec

Контейнери

Service

Service

ServiceSpec

ServiceAccount

ServiceAccount

Вступ до kubectl

Набори команд

Декларативне управління застосунками

Binding

Binding

Операції

create створення Binding

HTTP запит

Параметри

Booz Allen Case Study

Задача

Рішення

ComponentStatus

ComponentStatus

DeviceClass

DeviceClass

Endpoints

Endpoints

LabelSelector

LimitRange

LimitRange

LimitRangeSpec

Secret

Secret

SelfSubjectAccessReview

SelfSubjectAccessReview

TokenRequest

TokenRequest

TokenRequestSpec

Booking.com Case Study

Задача

Рішення

CSIDriver

CSIDriver

EndpointSlice

EndpointSlice

Event

Event

ListMeta

MutatingWebhookConfiguration

MutatingWebhookConfiguration

PodTemplate

PodTemplate

PodTemplateList

Операції

get прочитати вказаний PodTemplate

HTTP-запит

Параметри

ResourceQuota

ResourceQuota

ResourceQuotaSpec

SelfSubjectRulesReview

`create` створення Binding

`get` прочитати вказаний PodTemplate