Про що ця стаття "Advanced Kubernetes Vocabulary for IT Professionals"?

Освоєння розширених термінів Kubernetes: CRD, шаблон оператора, webhooks допуску, RBAC і мережеві правила з чіткими визначеннями і прикладами використання.

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Коли опубліковано цю статтю?

Цю статтю опубліковано у 2026 році.

Advanced Kubernetes Vocabulary for IT Professionals

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

Нетипові визначення ресурсів (CRD)

** Нетипове визначення ресурсів ** (CRD) розширює API Kubernetes новими типами об’ єктів, якими може керувати ваш кластер. Замість обмеження на вбудовані об’ єкти, такі як Pod або Service, команди можуть визначати власні:

«Ми створили CRD, щоб представити DatabaseCluster об’єкт.»
«Схема CRD перевіряє поля на кожному створенні або оновленні»
«Видалення CRD вилучає всі екземпляри цього ресурсу з кластера.»

Ключові фрази

- визначити CRD * — зареєструвати новий тип ресурсу
- нетиповий екземпляр ресурсу * — один об’ єкт типу CRD
- схема CRD * — правила перевірки для нового типу

Операторний шаблон

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

«Оператор автоматизує те, що робив би людина — резервні копії, відключення, масштабування — на основі специфікації ресурсу»

Поширені фрази:

- write an operator * — створює логіку контролера
- цикл узгодження * — цикл, у якому оператор перевіряє і виправляє стан
- оператор, який запускається за рівнем * — оператор, який діє на поточний стан, а не на історію подій

Описує зрілість оператора

Оператори часто описуються за допомогою п’ ятирівневої моделі зрілості:

Basic install — автоматизує розгортання
** Безперервне оновлення ** — керує оновленнями версій
Повний життєвий цикл — обробка резервних копій і відновлення
** Глибокі огляди ** — показує показники і попередження
** Автопілот ** — горизонтальне масштабування, налаштування, виявлення аномалій

Веб-сервіси

** Admission webhooks ** перехоплюють запити API перед тим, як об’ єкти будуть збережені. Вони надають вам змогу застосовувати правила або динамічно змінювати об’ єкти.

Два типи:

** Перевірка webhook прийняття** — відкидає запити, які порушують правила (наприклад, « відмовити у будь- якому підрозділі без обмежень ресурсів »)
** Мутаційний webhook прийняття** — змінює запити перед їх записом (наприклад, « автоматично вставити контейнер sidecar »)

Використання в реченнях

«Перевірка webhook ** відхилено ** розгортання, тому що тег зображення був latest..»
«Ми використовуємо мутуючий webhook, щоб ввести навісний причіп для ведення журналу в кожен підрозділ.»
«The webhook timed out, so the API server fell back to the failure policy.» (англійською)

Корисні поєднання

Verb	Object
register	a webhook
configure	the failure policy
bypass	the webhook (in an emergency)
respond within	the timeout window

Рольовий контроль доступу (RBAC)

** RBAC ** керує тим, що суб’ єкти (користувачі, групи, облікові записи служб) можуть робити з певними ресурсами.

Чотири основні об’ єкти:

** Роль ** — надає права доступу у просторі назв
ClusterRole — надає права доступу для всього кластера
** RoleBinding ** — прив’ язує роль до об’ єкта у просторі імен
** ClusterRoleBinding ** — прив’ язує ClusterRole до об’ єкта кластера

Говоря про RBAC

«Обліковий запис сервісу не має дозволу get pods в просторі імен production»
«Ми зв’язали view ClusterRole до групи команди на виклику»
«Грант ** найменш привілейований ** доступ — тільки те, що потрібно завантаженню.»
«Конвейєр імплітує обліковий запис служби розгортання.»

** Підказка: ** У англійській мові ви можете * надавати * права доступу, * прив’ язувати * ролі і * відкликати * доступ. Не вживайте « дати дозвіл » у формальній документації — « надати » є точним дієсловом.

Мережева політика

Ресурс NetworkPolicy оголошує, які підсистеми можуть спілкуватися з якими іншими підсистемами (і зовнішніми кінцевими точками) за допомогою мережі.

** Правила вхідного трафіку ** — керування вхідним трафіком до підрозділу
** Правила виходу ** — керування вихідним трафіком з підрозділу
** Підбірник підрозділів ** — визначає підрозділи, до яких застосовується правило
** Selector namespaces ** — розширює правила між просторами назв

Зразкові речення

«The NetworkPolicy **забороняє всі вхідні дані за замовчуванням **, а потім дозволяє трафік тільки з фронтендів.»
«Ми додали ** правило виходу **, щоб дозволити пошуки DNS на порту 53.»
«Політика ізолює платіжну службу від решти кластера.»
Без NetworkPolicy, піди є не-ізолованими — весь трафік дозволений

Всі вони з’єднані між собою

Ось як ці терміни поєднуються у справжній розмові:

“Ми написали оператора, який підтримується CRD для нашого брокера повідомлень. Muting webhook вводить sidecar, який експортує метрику. RBAC забезпечує, що тільки обліковий запис оператора може управляти екземплярами брокера, і NetworkPolicies обмежує брокерські піди для спілкування тільки з клієнтами черги. “

Ключеві моменти

CRD — розширює API Kubernetes новими типами ресурсів
** Operator ** — автоматизує операційні завдання за допомогою циклу узгодження
** Admission webhook ** — перехоплює виклики API для перевірки або зміни об’ єктів
** RBAC ** — керує тим, хто може виконувати які дії з якими ресурсами
** NetworkPolicy ** — обмежує трафік між підсистемами і між підсистемами і зовнішніми пристроями

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

На практиці: Декодування нюансів — фокус на ясність

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

Розглянемо наступне: ви переглядали запит на витягування, надісланий колегою, давайте назовемо його Jian. Опис PR говорить: «Впроваджено новий Pod з Deployment, що націлений на Service. Використовувався Horizontal Pod Autoscaler для масштабування на основі використання процесора. “Хоча технічно точний, йому бракує ясності для когось, хто не глибоко знайомий з Kubernetes. Ефективнішим описом може бути: “Ця PR вводить нову службу, ‘OrderProcessor’, яка використовує розгортання і горизонтальний Pod Autoscaler для обробки вхідних запитів на замовлення. HPA налаштовано для автоматичного масштабування кількості підрозділів OrderProcessor на основі використання процесора, що забезпечує оптимальну продуктивність під змінним навантаженням. Ми також додали детальні показники моніторингу через Prometheus, щоб полегшити постійну оптимізацію.” Зауважте, як додавання контексту - * чому * Jian зробив щось, чого він намагається досягти - драматично покращує розуміння і полегшує більш продуктивний перегляд коду. Аналогічно, в обговореннях Slack, уникнення жаргону при поясненні складних концепцій є життєво важливим. Замість того, щоб сказати «Давайте масштабуємо це за допомогою HPA», краще сказати: «Ми повинні налаштувати систему, щоб автоматично коригувати кількість екземплярів, що працюють на основі рівнів трафіку»

Інша ключова область для ясності полягає в описі налаштувань у файлах YAML. Багато розробників інстинктивно пишуть resources: {} при визначенні Pod, але це не передає багато інформації. Важливим є більш описовий підхід. Наприклад, замість того, щоб просто сказати « Змінити масштаб », ви можете сказати: « Розгортання автоматично змінить масштаб до 3 реплік під час годин пік (визначено за використанням ЦП, що перевищує 70%) і зменшить до 1 репліки під час годин поза піком ». Такий рівень деталізації допоможе іншим користувачам зрозуміти заплановану поведінку і розв’ язати потенційні проблеми. Крім того, під час обговорення ролей RBAC, не вказуйте просто « Надати користувачеві « john » доступ для читання ». Замість цього, вкажіть * що * вони можуть робити: « Ця роль надає користувачеві « john » дозвіл на перегляд журналів піду з будь- якого простору імен у кластері »

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

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: nginx:latest
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"

Цей YAML визначає розгортання з назвою my-app, яке запускає дві репліки штампу Nginx. Розділ resources визначає обмеження процесора 500 міліядер і обмеження пам’яті 512 МБ для кожного контейнера. Зрозуміти цю конфігурацію — * чому * за межами — так само важливо, як знати, як створити її з kubectl.