Доступ до застосунків у кластері

• 1: Розгортання та доступ до Інфопанелі Kubernetes
• 2: Доступ до кластерів
• 3: Налаштування доступу до декількох кластерів
• 4: Використання перенаправлення портів для доступу до застосунків у кластері
• 5: Використання Service для доступу до застосунку у кластері
• 6: Зʼєднання фронтенду з бекендом за допомогою Service
• 7: Створення зовнішнього балансувальника навантаження
• 8: Отримання переліку всіх образів контейнерів, що працюють у кластері
• 9: Налаштування Ingress у Minikube з використанням NGINX Ingress Controller
• 10: Спілкування між контейнерами в одному Podʼі за допомогою спільного тому
• 11: Налаштування DNS для кластера
• 12: Доступ до Service, що працюють в кластерах

1 - Розгортання та доступ до Інфопанелі Kubernetes

Інфопанель Kubernetes — це вебінтерфейс для кластерів Kubernetes. Ви можете використовувати Інфопанель для розгортання контейнерізованих застосунків в кластері Kubernetes, керувати ресурсами кластера, відстежувати та виправляти проблеми в роботі застосунків. Ви можете використовувати Інфопанель для перегляду роботи застосунків у вашому кластері, створення або зміни ресурсів Kubernetes (таких як Deployment, Job, DaemonSet та інші). Наприклад, ви можете масштабувати Deployment, ініціювати поступове оновлення, перезапустити Pod чи розгорнути новий застосунок за допомоги помічника з розгортання.

Інфопанель також надає інформацію про стан ресурсів Kubernetes у вашому кластері та про помилки, що можуть виникати.

Розгортання Dashboard UI

Стандартно Інфопанель не встановлена в кластері Kubernetes. Щоб розгорнути Інфопанель, ви повинні виконати наступну команду:

# Додайте репозиторій kubernetes-dashboard
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
# Розгорніть Helm Release з назвою "kubectl-dashboard" скориставшись чартом kubernetes-dashboard
helm upgrade \
    --install \
      kubernetes-dashboard \
      kubernetes-dashboard/kubernetes-dashboard \
    --create-namespace \
    --namespace kubernetes-dashboard

Отримання доступу до Dashboard UI

Для захисту даних вашого кластера, Dashboard типово розгортається з мінімальною конфігурацією RBAC. Наразі Dashboard підтримує лише вхід за допомогою токену на предʼявника (Bearer Token). Для створення токена для цього демо ви можете скористатися нашим посібником зі створення користувача.

Проксі з командного рядка

Ви можете увімкнути доступ до Dashboard за допомогою інструменту командного рядка kubectl, виконавши наступну команду:

kubectl proxy

Kubectl зробить Dashboard доступним за адресою http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/.

Інтерфейс можна лише відкрити з машини, на якій виконується команда. Дивіться kubectl proxy --help для отримання додаткових опцій.

Вітальна сторінка

Коли ви отримуєте доступ до Інфопанелі в порожньому кластері, ви побачите вітальну сторінку. Ця сторінка містить посилання на цей документ, а також кнопку для розгортання вашого першого застосунку. Крім того, ви можете побачити, які системні застосунки запускаються стандартно у просторі імен kube-system вашого кластера, наприклад, сама Інфопанель.

Розгортання контейнеризованих застосунків

Dashboard дозволяє створювати та розгортати контейнеризований застосунок як Deployment та необов’язковий Service за допомогою простого майстра. Ви можете або вручну вказати деталі застосунку, або завантажити YAML або JSON файл маніфесту, що містить конфігурацію застосунку.

Натисніть кнопку CREATE у верхньому правому куті будь-якої сторінки, щоб розпочати.

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

Майстер розгортання очікує, що ви надасте наступну інформацію:

• Назва застосунку (обов’язково): Назва вашого застосунку. Мітка з цією назвою буде додана до Deployment та Service (якщо є), які будуть розгорнуті.

  Назва застосунку повинна бути унікальною в межах вибраного простору імен Kubernetes. Вона повинна починатися з малої літери та закінчуватися малою літерою або цифрою, і містити лише малі літери, цифри та дефіси (-). Обмеження на довжину становить 24 символи. Початкові та кінцеві пробіли ігноруються.

• Образ контейнера (обов’язково): URL публічного Docker образу контейнера у будь-якому реєстрі, або приватного образу (зазвичай розміщеного в Google Container Registry або Docker Hub). Специфікація образу контейнера повинна закінчуватися двокрапкою.

• Кількість Podʼів (обов’язково): Кількість Podʼів, з використанням яких ви хочете розгорнути свій застосунок. Значення повинно бути позитивним цілим числом.

  Буде створено Deployment, щоб підтримувати потрібну кількість Podʼів у вашому кластері.

• Service (необов’язково): Для деяких частин вашого застосунку (наприклад, фронтендів) ви можете захотіти експонувати Service на зовнішню, можливо, публічну IP-адресу за межами вашого кластера (зовнішній Service).

  Примітка:

  Для зовнішніх Service, можливо, вам доведеться відкрити один або кілька портів для цього.

  Інші Service, які видно тільки всередині кластера, називаються внутрішніми Service.

  Незалежно від типу Service, якщо ви вирішите створити Service і ваш контейнер слухає на порту (вхідному), вам потрібно вказати два порти. Service буде створено, шляхом зіставлення порту (вхідного) на цільовий порт, який бачить контейнер. Цей Service буде переспрямовувати трафік на ваші розгорнуті Podʼи. Підтримувані протоколи — TCP та UDP. Внутрішнє DNS-імʼя для цього Service буде значенням, яке ви вказали як назву застосунку вище.

Якщо необхідно, ви можете розгорнути розділ Advanced options, де можна вказати більше налаштувань:

• Опис: Текст, який ви введете тут, буде додано як анотацію до Deployment та відображатиметься в деталях застосунку.

• Мітки: Стандартні мітки, що використовуються для вашого застосунку, - це назва застосунку та версія. Ви можете вказати додаткові мітки, які будуть застосовані до Deployment, Service (якщо є) та Podʼів, такі як release, environment, tier, partition та release track.

  Приклад:

  release=1.0
  tier=frontend
  environment=pod
  track=stable
  

• Простір імен: Kubernetes підтримує кілька віртуальних кластерів, що працюють поверх одного фізичного кластера. Ці віртуальні кластери називаються просторами імен. Вони дозволяють розділити ресурси на логічно названі групи.

  Dashboard пропонує всі доступні простори імен у розгортаючомуся списку та дозволяє створити новий простір імен. Назва простору імен може містити максимум 63 алфавітно-цифрових символи та дефіси (-), але не може містити великі літери. Назви просторів імен не повинні складатися лише з цифр. Якщо назва встановлена як число, наприклад 10, Pod буде розміщений у просторі імен default.

  У разі успішного створення простору імен він обирається стандартним. Якщо створення не вдається, вибирається перший простір імен.

• Secret завантаження образу: У випадку, якщо вказаний Docker образ контейнера є приватним, він може вимагати облікові дані Secret завантаження.

  Dashboard пропонує всі доступні Secret у розгортаючомуся списку та дозволяє створити новий. Назва Secret повинна відповідати синтаксису доменного імені DNS, наприклад new.image-pull.secret. Вміст Secret повинен бути закодований у base64 і вказаний у файлі .dockercfg. Назва Secret може складатися максимум з 253 символів.

  У разі успішного створення Secret завантаження образу він обирається стандартним. Якщо створення не вдається, жоден Secret не застосовується.

• Вимога до процесора (ядра) та Вимога до пам'яті (MiB): Ви можете вказати мінімальні обмеження ресурсів для контейнера. Стандартно Podʼи працюють без обмежень на процесор і памʼять.

• Команда запуску та Аргументи команди запуску: Стандартно ваші контейнери виконують вказану Docker образом контейнера команду запуску. Ви можете використовувати опції команд і аргументів для перевизначення стандартної команди.

• Запуск у привілейованому режимі: Це налаштування визначає, чи є процеси в привілейованих контейнерах еквівалентними процесам, що виконуються з правами root на хості. Привілейовані контейнери можуть використовувати можливості, такі як маніпулювання мережею та доступ до пристроїв.

• Змінні середовища: Kubernetes експонує Service через змінні середовища. Ви можете складати змінні середовища або передавати аргументи до ваших команд, використовуючи значення змінних середовища. Вони можуть використовуватися в застосунках для пошуку Service. Значення можуть посилатися на інші змінні за допомогою синтаксису $(VAR_NAME).

Завантаження YAML або JSON файлу

Kubernetes підтримує декларативну конфігурацію. У цьому стилі всі конфігурації зберігаються в маніфестах (конфігураційних файлах YAML або JSON). Маніфести використовують схеми ресурсів API Kubernetes.

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

Використання Dashboard

Наступні розділи описують вигляди інтерфейсу користувача Dashboard Kubernetes; що вони забезпечують і як їх можна використовувати.

Навігація

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

Dashboard показує більшість типів об'єктів Kubernetes та групує їх у кілька категорій меню.

Огляд адміністратора

Для адміністраторів кластерів та просторів імен Dashboard перелічує вузли (Nodes), простори імен (Namespaces) та постійні томи (PersistentVolumes) і має детальні елементи для них. Список вузлів містить метрики використання ЦП та памʼяті, агреговані по всіх вузлах. Детальний вигляд показує метрики для вузла, його специфікацію, стан, виділені ресурси, події та Podʼи, що працюють на вузлі.

Навантаження

Показує всі застосунки, що працюють у вибраному просторі імен. Елемент перераховує застосунки за типом навантаження (наприклад: Deployments, ReplicaSets, StatefulSets). Кожен тип навантаження можна переглядати окремо. Списки узагальнюють корисну інформацію про навантаження, таку як кількість готових Podʼів для ReplicaSet або поточне використання памʼяті для Pod.

Детальні панелі для навантажень показують інформацію про стан та специфікацію і показують звʼязки між обʼєктами. Наприклад, Podʼи, які контролює ReplicaSet, або нові ReplicaSets та HorizontalPodAutoscalers для Deployments.

Services

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

Сховище

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

ConfigMaps та Secrets

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

Переглядач логів

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

Що далі

Для отримання додаткової інформації дивіться сторінку проєкту Kubernetes Dashboard.

2 - Доступ до кластерів

В цій темі обговорюється кілька способів взаємодії з кластерами.

Перший доступ з kubectl

При першому доступі до Kubernetes API ми пропонуємо використовувати Kubernetes CLI, kubectl.

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

Перевірте розташування та облікові дані, про які знає kubectl, за допомогою цієї команди:

kubectl config view

Багато з прикладів надають введення до використання kubectl, а повна документація знаходиться у довіднику kubectl.

Прямий доступ до REST API

Kubectl опрацьовує розташування та автентифікацію до apiserver. Якщо ви хочете безпосередньо звертатися до REST API за допомогою http-клієнта, такого як curl або wget, або вебоглядача, існує кілька способів знайти розташування та автентифікуватись:

• Запустіть kubectl в режимі проксі.
  • Рекомендований підхід.
  • Використовує збережене розташування apiserver.
  • Перевіряє особу apiserver за допомогою самопідписного сертифікату. Немає можливості MITM.
  • Виконує автентифікацію на apiserver.
  • У майбутньому може здійснювати інтелектуальне балансування навантаження та відмовостійкість на стороні клієнта.
• Надайте розташування та облікові дані безпосередньо http-клієнту.
  • Альтернативний підхід.
  • Працює з деякими типами клієнтського коду, які не працюють з проксі.
  • Потрібно імпортувати кореневий сертифікат у ваш оглядач для захисту від MITM.

Використання kubectl proxy

Наступна команда запускає kubectl в режимі, де він діє як зворотний проксі. Вона обробляє розташування apiserver та автентифікацію. Запустіть її так:

kubectl proxy --port=8080

Дивіться опис kubectl proxy для отримання додаткової інформації.

Після цього ви можете досліджувати API за допомогою curl, wget або оглядача, замінюючи localhost на [::1] для IPv6, ось так:

curl http://localhost:8080/api/

Вихід буде схожий на це:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Без kubectl proxy

Використовуйте kubectl apply і kubectl describe secret... для створення токена для стандартного облікового запису за допомогою grep/cut:

Спочатку створіть Secret, запитуючи токен для облікового запису стандартного ServiceAccount:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

Далі, зачекайте, поки контролер токенів не заповнить Secret токеном:

while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
  echo "waiting for token..." >&2
  sleep 1
done

Отримайте і використовуйте згенерований токен:

APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

Вихід буде схожий на це:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Використовуючи jsonpath:

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

Вихід буде схожий на це:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Вищенаведені приклади використовують прапорець --insecure. Це залишає їх вразливими до атак MITM. Коли kubectl отримує доступ до кластера, він використовує збережений кореневий сертифікат та клієнтські сертифікати для доступу до сервера. (Вони встановлюються в теку ~/.kube). Оскільки сертифікати кластера зазвичай самопідписні, це може вимагати спеціальної конфігурації, щоб змусити вашого http-клієнта використовувати кореневий сертифікат.

У деяких кластерах apiserver не вимагає автентифікації; він може працювати на localhost або бути захищеним файрволом. Для цього немає стандарту. Контроль доступу до API описує, як адміністратор кластера може це налаштувати.

Програмний доступ до API

Kubernetes офіційно підтримує клієнтські бібліотеки для Go та Python.

Клієнт Go

• Щоб отримати бібліотеку, виконайте наступну команду: go get k8s.io/client-go@kubernetes-<kubernetes-version-number>, дивіться INSTALL.md для детальних інструкцій з встановлення. Дивіться https://github.com/kubernetes/client-go щоб дізнатися, які версії підтримуються.
• Напишіть додаток на основі клієнтів client-go. Зверніть увагу, що client-go визначає свої власні API обʼєкти, тому, якщо необхідно, будь ласка, імпортуйте визначення API з client-go, а не з основного репозиторію, наприклад, import "k8s.io/client-go/kubernetes" є правильним.

Go клієнт може використовувати той же файл kubeconfig, що й CLI kubectl для знаходження та автентифікації до apiserver. Дивіться цей приклад.

Якщо застосунок розгорнуто як Pod у кластері, будь ласка, зверніться до наступного розділу.

Клієнт Python

Щоб використовувати клієнта Python, виконайте наступну команду: pip install kubernetes. Дивіться сторінку Python Client Library для інших варіантів встановлення.

Клієнт Python може використовувати той же файл kubeconfig, що й CLI kubectl для знаходження та автентифікації до apiserver. Дивіться цей приклад.

Інші мови

Існують клієнтські бібліотеки для доступу до API з інших мов. Дивіться документацію для інших бібліотек щодо того, як вони автентифікуються.

Доступ до API з Pod

При доступі до API з Pod, розташування та автентифікація на API сервері дещо відрізняються.

Будь ласка, перевірте Доступ до API з Pod для отримання додаткової інформації.

Доступ до сервісів, що працюють на кластері

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

Запит перенаправлення

Можливості перенаправлення були визнані застарілими та видалені. Будь ласка, використовуйте проксі (дивіться нижче) замість цього.

Так багато проксі

Існує кілька різних проксі, які ви можете зустріти при використанні Kubernetes:

1. kubectl proxy:

   • працює на десктопі користувача або в Pod
   • проксі з локальної адреси до Kubernetes apiserver
   • клієнт проксі використовує HTTP
   • проксі apiserver використовує HTTPS
   • знаходить apiserver
   • додає заголовки автентифікації

2. apiserver proxy:

   • є бастіоном, вбудованим у apiserver
   • зʼєднує користувача ззовні кластера з IP-адресами кластера, які інакше можуть бути недосяжні
   • працює в процесах apiserver
   • клієнт проксі використовує HTTPS (або http, якщо apiserver налаштований відповідним чином)
   • проксі може використовувати HTTP або HTTPS, як обрано проксі, використовуючи доступну інформацію
   • може використовуватися для доступу до Node, Pod або Service
   • забезпечує балансування навантаження при використанні для доступу до Service

3. kube proxy:

   • працює на кожному вузлі
   • проксі UDP та TCP
   • не розуміє HTTP
   • забезпечує балансування навантаження
   • використовується лише для доступу до Service

4. Проксі/Балансувальник навантаження перед apiserver(ами):

   • існування та реалізація варіюється від кластера до кластера (наприклад, nginx)
   • знаходиться між усіма клієнтами та одним або декількома apiserver
   • діє як балансувальник навантаження, якщо є кілька apiserver.

5. Хмарні балансувальники навантаження на зовнішніх сервісах:

   • надаються деякими постачальниками хмарних послуг (наприклад, AWS ELB, Google Cloud Load Balancer)
   • створюються автоматично, коли сервіс Kubernetes має тип LoadBalancer
   • використовують лише UDP/TCP
   • реалізація варіюється серед постачальників хмарних послуг.

Користувачі Kubernetes зазвичай не повинні турбуватися про будь-що, крім перших двох типів. Адміністратор кластера зазвичай забезпечить правильне налаштування останніх типів.

3 - Налаштування доступу до декількох кластерів

Ця сторінка показує, як налаштувати доступ до декількох кластерів за допомогою конфігураційних файлів. Після того, як ваші кластери, користувачі та контексти визначені в одному або декількох конфігураційних файлах, ви можете швидко перемикатися між кластерами, використовуючи команду kubectl config use-context.

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

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

• Killercoda
• Play with Kubernetes

Щоб перевірити, чи встановлений kubectl, виконайте команду kubectl version --client. Версія kubectl повинна бути в межах однієї мінорної версії API сервера вашого кластера.

Визначення кластерів, користувачів і контекстів

Припустимо, у вас є два кластери: один для розробки, а інший для тестування. У кластері development ваші фронтенд розробники працюють в просторі імен frontend, а розробники, які опікуються зберіганням даних працюють в просторі імен storage. У кластері test розробники працюють в стандартному просторі імен default або створюють додаткові простори імен за потреби. Доступ до кластера розробки вимагає автентифікації за сертифікатом. Доступ до тестового кластера вимагає автентифікації за іменем користувача та паролем.

Створіть теку з назвою config-exercise. У вашій теці config-exercise створіть файл з назвою config-demo з наступним вмістом:

apiVersion: v1
kind: Config
preferences: {}

clusters:
- cluster:
  name: development
- cluster:
  name: test

users:
- name: developer
- name: experimenter

contexts:
- context:
  name: dev-frontend
- context:
  name: dev-storage
- context:
  name: exp-test

Конфігураційний файл описує кластери, користувачів і контексти. Ваш файл config-demo має структуру для опису двох кластерів, двох користувачів і трьох контекстів.

Перейдіть до теки config-exercise. Виконайте ці команди, щоб додати деталі кластера до вашого конфігураційного файлу:

kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify

Додайте відомості про користувачів до вашого конфігураційного файлу:

kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-file
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password

Додайте деталі контексту до вашого конфігураційного файлу:

kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter

Відкрийте ваш файл config-demo, щоб побачити додані деталі. Як альтернативу відкриттю файлу config-demo, можна використовувати команду config view.

kubectl config --kubeconfig=config-demo view

Вивід показує два кластери, двох користувачів і три контексти:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: test
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    # Примітка до документації (цей коментар НЕ є частиною виводу команди).
    # Зберігання паролів у конфігурації клієнта Kubernetes є ризикованим.
    # Кращою альтернативою буде використання втулка облікових даних
    # і зберігати облікові дані окремо.
    # Див. https://kubernetes.io/docs/reference/access-authn-authz/authentication/client-go-credential-plugins
    password: some-password
    username: exp

Файли fake-ca-file, fake-cert-file та fake-key-file вище є заповнювачами для шляхів до сертифікатів. Вам потрібно замінити їх на реальні шляхи до сертифікатів у вашому середовищі.

Іноді ви можете захотіти використовувати дані у форматі Base64 замість окремих файлів сертифікатів; у такому випадку вам потрібно додати суфікс -data до ключів, наприклад, certificate-authority-data, client-certificate-data, client-key-data.

Кожен контекст є трійкою (кластер, користувач, простір імен). Наприклад, контекст dev-frontend означає: "Використовувати облікові дані користувача developer для доступу до простору імен frontend у кластері development".

Встановіть поточний контекст:

kubectl config --kubeconfig=config-demo use-context dev-frontend

Тепер, коли ви введете команду kubectl, дія буде застосовуватися до кластера і простору імен, вказаних у контексті dev-frontend. І команда буде використовувати облікові дані користувача, вказаного у контексті dev-frontend.

Щоб побачити лише інформацію про конфігурацію, повʼязану з поточним контекстом, використовуйте прапорець --minify.

kubectl config --kubeconfig=config-demo view --minify

Вивід показує інформацію про конфігурацію, повʼязану з контекстом dev-frontend:

api

Version: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
current-context: dev-frontend
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file

Тепер припустимо, що ви хочете попрацювати деякий час у тестовому кластері.

Змініть поточний контекст на exp-test:

kubectl config --kubeconfig=config-demo use-context exp-test

Тепер будь-яка команда kubectl, яку ви введете, буде застосовуватися до стандартного простору імен default кластера test. І команда буде використовувати облікові дані користувача, вказаного у контексті exp-test.

Перегляньте конфігурацію, повʼязану з новим поточним контекстом exp-test.

kubectl config --kubeconfig=config-demo view --minify

Нарешті, припустимо, що ви хочете попрацювати деякий час у просторі імен storage кластера development.

Змініть поточний контекст на dev-storage:

kubectl config --kubeconfig=config-demo use-context dev-storage

Перегляньте конфігурацію, повʼязану з новим поточним контекстом dev-storage.

kubectl config --kubeconfig=config-demo view --minify

Створення другого конфігураційного файлу

У вашій теці config-exercise створіть файл з назвою config-demo-2 з наступним вмістом:

apiVersion: v1
kind: Config
preferences: {}

contexts:
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up

Вищезазначений конфігураційний файл визначає новий контекст з назвою dev-ramp-up.

Встановіть змінну середовища KUBECONFIG

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

Linux

export KUBECONFIG_SAVED="$KUBECONFIG"

Windows PowerShell

$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG

Змінна середовища KUBECONFIG є списком шляхів до конфігураційних файлів. Список розділяється двокрапкою для Linux і Mac та крапкою з комою для Windows. Якщо у вас є змінна середовища KUBECONFIG, ознайомтеся з конфігураційними файлами у списку.

Тимчасово додайте два шляхи до вашої змінної середовища KUBECONFIG. Наприклад:

Linux

export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2"

Windows PowerShell

$Env:KUBECONFIG=("config-demo;config-demo-2")

У вашій теці config-exercise виконайте цю команду:

kubectl config view

Вивід показує обʼєднану інформацію з усіх файлів, зазначених у вашій змінній середовища KUBECONFIG. Зокрема, зверніть увагу, що обʼєднана інформація містить контекст dev-ramp-up з файлу config-demo-2 і три контексти з файлу config-demo:

contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test

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

Ознайомтеся з текою $HOME/.kube

Якщо у вас вже є кластер і ви можете використовувати kubectl для взаємодії з кластером, то, ймовірно, у вас є файл з назвою config у теці $HOME/.kube.

Перейдіть до теки $HOME/.kube і перегляньте, які файли там знаходяться. Зазвичай, там є файл з назвою config. Також можуть бути інші конфігураційні файли у цій теці. Ознайомтеся зі змістом цих файлів.

Додайте $HOME/.kube/config до вашої змінної середовища KUBECONFIG

Якщо у вас є файл $HOME/.kube/config і він ще не зазначений у вашій змінній середовища KUBECONFIG, додайте його до вашої змінної середовища KUBECONFIG зараз. Наприклад:

Linux

export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config"

Windows PowerShell

$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"

Перегляньте інформацію про конфігурацію, обʼєднану з усіх файлів, які зараз зазначені у вашій змінній середовища KUBECONFIG. У вашій теці config-exercise введіть:

kubectl config view

Очищення

Поверніть вашу змінну середовища KUBECONFIG до її оригінального значення. Наприклад:

Linux

export KUBECONFIG="$KUBECONFIG_SAVED"

Windows PowerShell

$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED

Перевірте субʼєкт, представлений kubeconfig

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

Існує підкоманда kubectl для перевірки атрибутів субʼєкта, таких як імʼя користувача, для вашого вибраного контексту клієнта Kubernetes: kubectl auth whoami.

Детальніше читайте у Доступ до інформації автентифікації клієнта через API.

Що далі

• Організація доступу до кластерів за допомогою файлів kubeconfig
• kubectl config

4 - Використання перенаправлення портів для доступу до застосунків у кластері

Ця сторінка показує, як використовувати kubectl port-forward для підключення до сервера MongoDB, який працює у кластері Kubernetes. Такий тип підключення може бути корисним для налагодження бази даних.

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

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

  • Killercoda
  • Play with Kubernetes
  Версія вашого Kubernetes сервера має бути не старішою ніж v1.10. Для перевірки версії введіть kubectl version.
• Встановіть MongoDB Shell.

Створення розгортання та сервісу MongoDB

1. Створіть Deployment, що запускає MongoDB:

   kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
   

   Вивід успішної команди підтверджує, що Deployment створено:

   deployment.apps/mongo created
   

   Перегляньте стан Podʼа, щоб переконатися, що він готовий:

   kubectl get pods
   

   Вивід відображає показує Pod:

   NAME                     READY   STATUS    RESTARTS   AGE
   mongo-75f59d57f4-4nd6q   1/1     Running   0          2m4s
   

   Перегляньте стан Deployment:

   kubectl get deployment
   

   Вивід відображає, що Deployment було створено:

   NAME    READY   UP-TO-DATE   AVAILABLE   AGE
   mongo   1/1     1            1           2m21s
   

   Deployment автоматично керує ReplicaSet. Перегляньте стан ReplicaSet, використовуючи:

   kubectl get replicaset
   

   Вивід показує, що ReplicaSet був створений:

   NAME               DESIRED   CURRENT   READY   AGE
   mongo-75f59d57f4   1         1         1       3m12s
   

2. Створіть Service для доступу до MongoDB в мережі:

   kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
   

   Вивід успішної команди підтверджує, що Service був створений:

   service/mongo created
   

   Перевірте створений Service:

   kubectl get service mongo
   

   Вивід показує створений Service:

   NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
   mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
   

3. Переконайтеся, що сервер MongoDB працює у Pod та слухає на порту 27017:

   # Замініть mongo-75f59d57f4-4nd6q на імʼя Pod
   kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
   

   Вивід показує порт для MongoDB у цьому Pod:

   27017
   

   27017 є офіційним TCP портом для MongoDB.

Перенаправлення локального порту на порт Pod

1. kubectl port-forward дозволяє використовувати імʼя ресурсу, такого як імʼя Podʼа, для вибору відповідного Podʼа для перенаправлення портів.

   # Замініть mongo-75f59d57f4-4nd6q на імʼя Pod
   kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
   

   що те саме, що і

   kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
   

   або

   kubectl port-forward deployment/mongo 28015:27017
   

   або

   kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
   

   або

   kubectl port-forward service/mongo 28015:27017
   

   Будь-яка з наведених вище команд працює. Вивід схожий на це:

   Forwarding from 127.0.0.1:28015 -> 27017
   Forwarding from [::1]:28015 -> 27017
   

   Примітка:

   kubectl port-forward не повертає інформацію. Щоб продовжити вправи, вам потрібно буде відкрити інший термінал.

2. Запустіть інтерфейс командного рядка MongoDB:

   mongosh --port 28015
   

3. На командному рядку MongoDB введіть команду ping:

   db.runCommand( { ping: 1 } )
   

   Успішний запит ping повертає:

   { ok: 1 }
   

Дозвольте kubectl вибрати локальний порт

Якщо вам не потрібен конкретний локальний порт, ви можете дозволити kubectl вибрати та призначити локальний порт і таким чином позбавити себе від необхідності керувати конфліктами локальних портів, з дещо простішим синтаксисом:

kubectl port-forward deployment/mongo :27017

Інструмент kubectl знаходить номер локального порту, який не використовується (уникаючи низьких номерів портів, оскільки вони можуть використовуватися іншими застосунками). Вивід схожий на:

Forwarding from 127.0.0.1:63753 -> 27017
Forwarding from [::1]:63753 -> 27017

Обговорення

Підключення до локального порту 28015 пересилаються на порт 27017 Podʼа, який запускає сервер MongoDB. З цим підключенням ви можете використовувати свій локальний робочий компʼютер для налагодження бази даних, яка працює у Pod.

Що далі

Дізнайтеся більше про kubectl port-forward.

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

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

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

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

• Killercoda
• Play with Kubernetes

Цілі

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

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

Ось конфігураційний файл для Deployment застосунку:

service/access/hello-application.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  selector:
    matchLabels:
      run: load-balancer-example
  replicas: 2
  template:
    metadata:
      labels:
        run: load-balancer-example
    spec:
      containers:
        - name: hello-world
          image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
          ports:
            - containerPort: 8080
              protocol: TCP

1. Запустіть застосунок Hello World у вашому кластері: Створіть Deployment застосунку, використовуючи файл вище:

   kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
   

   Попередня команда створює Deployment та повʼязаний з ним ReplicaSet. ReplicaSet має два Podʼи кожен з яких запускає застосунок Hello World.

2. Перегляньте інформацію про Deployment:

   kubectl get deployments hello-world
   kubectl describe deployments hello-world
   

3. Перегляньте інформацію про ваші обʼєкти ReplicaSet:

   kubectl get replicasets
   kubectl describe replicasets
   

4. Створіть обʼєкт Service, який експонує Deployment:

   kubectl expose deployment hello-world --type=NodePort --name=example-service
   

5. Перегляньте інформацію про Service:

   kubectl describe services example-service
   

   Вивід буде схожий на цей:

   Name:                   example-service
   Namespace:              default
   Labels:                 run=load-balancer-example
   Annotations:            <none>
   Selector:               run=load-balancer-example
   Type:                   NodePort
   IP:                     10.32.0.16
   Port:                   <unset> 8080/TCP
   TargetPort:             8080/TCP
   NodePort:               <unset> 31496/TCP
   Endpoints:              10.200.1.4:8080, 10.200.2.5:8080
   Session Affinity:       None
   Events:                 <none>
   

   Занотуйте значення NodePort для Service. Наприклад, у попередньому виводі значення NodePort становить 31496.

6. Перегляньте Podʼи, що запускають застосунок Hello World:

   kubectl get pods --selector="run=load-balancer-example" --output=wide
   

   Вивід буде схожий на цей:

   NAME                           READY   STATUS    ...  IP           NODE
   hello-world-2895499144-bsbk5   1/1     Running   ...  10.200.1.4   worker1
   hello-world-2895499144-m1pwt   1/1     Running   ...  10.200.2.5   worker2
   

7. Отримайте публічну IP-адресу одного з ваших вузлів, що запускає Pod Hello World. Як ви отримаєте цю адресу залежить від того, як ви налаштували свій кластер. Наприклад, якщо ви використовуєте Minikube, ви можете побачити адресу вузла, виконавши команду kubectl cluster-info. Якщо ви використовуєте trptvgkzhb Google Compute Engine, ви можете використати команду gcloud compute instances list для перегляду публічних адрес ваших вузлів.

8. На обраному вами вузлі створіть правило брандмауера, яке дозволяє TCP-трафік на вашому порту вузла. Наприклад, якщо ваш Service має значення NodePort 31568, створіть правило брандмауера, яке дозволяє TCP-трафік на порт 31568. Різні постачальники хмарних послуг пропонують різні способи налаштування правил брандмауера.

9. Використовуйте адресу вузла та порт вузла для доступу до застосунку Hello World:

   curl http://<public-node-ip>:<node-port>
   

   де <public-node-ip> — це публічна IP-адреса вашого вузла, а <node-port> — це значення NodePort для вашого Service. Відповідь на успішний запит буде повідомленням з привітанням:

   Hello, world!
   Version: 2.0.0
   Hostname: hello-world-cdd4458f4-m47c8
   

Використання конфігураційного файлу Service

Як альтернатива використанню kubectl expose, ви можете використовувати конфігураційний файл Service для створення Service.

Очищення

Щоб видалити Service, введіть цю команду:

kubectl delete services example-service

Щоб видалити Deployment, ReplicaSet та Podʼи, що запускають застосунок Hello World, введіть цю команду:

 kubectl delete deployment hello-world

Що далі

Ознайомтесь з посібником Підключення застосунків за допомогою Service.

6 - Зʼєднання фронтенду з бекендом за допомогою Service

Це завдання показує, як створити мікросервіси frontend та backend. Мікросервіс бекенд є сервісом для привітання. Фронтенд експонує backend за допомогою nginx та обʼєкта Kubernetes Service.

Цілі

• Створити та запустити зразок мікросервісу бекенд hello за допомогою обʼєкта Deployment.
• Використовувати обʼєкт Service для надсилання трафіку до кількох реплік мікросервісу бекенд.
• Створити та запустити мікросервіс фронтенд nginx, також використовуючи обʼєкт Deployment.
• Налаштувати мікросервіс фронтенд для надсилання трафіку до мікросервісу бекенд.
• Використовувати обʼєкт Service типу LoadBalancer для експонування мікросервісу фронтенд назовні кластера.

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

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

• Killercoda
• Play with Kubernetes

Це завдання використовує Service з зовнішніми балансувальниками навантаження, які вимагають підтримуваного середовища. Якщо ваше середовище не підтримує це, ви можете використовувати Service типу NodePort.

Створення бекенд за допомогою Deployment

Бекенд — це простий мікросервіс для привітань. Ось конфігураційний файл для розгортання:

service/access/backend-deployment.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "gcr.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http
              containerPort: 80
...

Створіть Deployment для бекенду:

kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml

Перегляньте інформацію про Deployment:

kubectl describe deployment backend

Вивід буде схожий на цей:

Name:                           backend
Namespace:                      default
CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
Labels:                         app=hello
                                tier=backend
                                track=stable
Annotations:                    deployment.kubernetes.io/revision=1
Selector:                       app=hello,tier=backend,track=stable
Replicas:                       3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:                   RollingUpdate
MinReadySeconds:                0
RollingUpdateStrategy:          1 max unavailable, 1 max surge
Pod Template:
  Labels:       app=hello
                tier=backend
                track=stable
  Containers:
   hello:
    Image:              "gcr.io/google-samples/hello-go-gke:1.0"
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable
OldReplicaSets:                 <none>
NewReplicaSet:                  hello-3621623197 (3/3 replicas created)
Events:
...

Створення обʼєкта Service hello

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

Спочатку ознайомтеся з конфігураційним файлом Service:

service/access/backend-service.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
    tier: backend
  ports:
  - protocol: TCP
    port: 80
    targetPort: http
...

У конфігураційному файлі можна побачити, що Service з назвою hello маршрутизує трафік до Podʼів з мітками app: hello та tier: backend.

Створіть Service для бекенду:

kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml

На цьому етапі у вас є Deployment backend, що виконує три репліки вашого hello застосунку, та Service, який може маршрутизувати трафік до них. Проте цей Service не є доступним та не може бути доступний за межами кластера.

Створення frontend

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

Фронтенд надсилає запити до Podʼів backend, використовуючи DNS-імʼя, надане Serviceʼу бекенд. DNS-імʼя — це hello, яке є значенням поля name у конфігураційному файлі examples/service/access/backend-service.yaml.

Podʼи у Deployment фронтенд запускають образ nginx, налаштований для проксіювання запитів до Service бекенда hello. Ось конфігураційний файл nginx:

service/access/frontend-nginx.conf

# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
    # hello is the internal DNS name used by the backend Service inside Kubernetes
    server hello;
}
server {
listen 80;
location / {
    # The following statement will proxy traffic to the upstream named Backend
    proxy_pass http://Backend;
}
}

Подібно до бекенду, фронтенд має Deployment та Service. Важливою відмінністю між Serviceʼами бекендаа та фронтенда є те, що конфігурація для Service фронтенда має type: LoadBalancer, що означає, що Service використовує балансувальник навантаження, який надається вашим хмарним провайдером, і буде доступним за межами кластеру.

service/access/frontend-service.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: hello
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
...

service/access/frontend-deployment.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: hello
      tier: frontend
      track: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: hello
        tier: frontend
        track: stable
    spec:
      containers:
        - name: nginx
          image: "gcr.io/google-samples/hello-frontend:1.0"
          lifecycle:
            preStop:
              exec:
                command: ["/usr/sbin/nginx","-s","quit"]
...

Створіть Deployment та Service фронтенд:

kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml

Вивід підтверджує, що обидва ресурси створено:

deployment.apps/frontend created
service/frontend created

Взаємодія з Service фронтенду

Після створення Service типу LoadBalancer, ви можете використати цю команду, щоб знайти зовнішню IP-адресу:

kubectl get service frontend --watch

Вивід показує конфігурацію Service frontend та спостерігає за змінами. Спочатку зовнішня IP-адреса вказана як <pending>:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   <pending>     80/TCP   10s

Як тільки зовнішня IP-адреса буде надана, конфігурація оновлюється і включає нову IP-адресу під заголовком EXTERNAL-IP:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m

Цю IP-адресу тепер можна використовувати для взаємодії з Service frontend ззовні кластера.

Надсилання трафіку через фронтенд

Тепер фронтенд та бекенд зʼєднані. Ви можете звернутися до точки доступу використовуючи команду curl з зовнішньою IP-адресою вашого Service фронтенду.

curl http://${EXTERNAL_IP} # замініть це на EXTERNAL-IP, який ви бачили раніше

Вивід показує повідомлення, згенероване бекендом:

{"message":"Hello"}

Очищення

Щоб видалити Serviceʼи, введіть цю команду:

kubectl delete services frontend backend

Щоб видалити Deploymentʼи, ReplicaSet та Podʼи, які запускають бекенд та фронтенд застосунки, введіть цю команду:

kubectl delete deployment frontend backend

Що далі

• Дізнайтеся більше про Service
• Дізнайтеся більше про ConfigMap
• Дізнайтеся більше про DNS для Service та Podʼів

7 - Створення зовнішнього балансувальника навантаження

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

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

Ви також можете використовувати Ingress замість Service. Для отримання додаткової інформації ознайомтеся з документацією Ingress.

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

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

• Killercoda
• Play with Kubernetes

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

Створення Service

Створення Service з маніфесту

Щоб створити зовнішній балансувальник навантаження, додайте до специфікації вашого маніфесту Service наступний рядок :

    type: LoadBalancer

Ваш маніфест може виглядати так:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  type: LoadBalancer

Створення Service за допомогою kubectl

Ви можете також створити Service за допомогою команди kubectl expose та її прапорця --type=LoadBalancer:

kubectl expose deployment example --port=8765 --target-port=9376 \
        --name=example-service --type=LoadBalancer

Ця команда створює новий Service, використовуючи ті ж селектори, що й вказаний ресурс (у випадку наведеного прикладу — Deployment під назвою example).

Для отримання додаткової інформації, включаючи необовʼязкові прапорці, зверніться до довідника команди kubectl expose.

Пошук вашої IP-адреси

Ви можете знайти IP-адресу, створену для вашого Service, отримавши інформацію про Service через kubectl:

kubectl describe services example-service

що повинно дати результат, схожий на цей:

Name:                     example-service
Namespace:                default
Labels:                   app=example
Annotations:              <none>
Selector:                 app=example
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.3.22.96
IPs:                      10.3.22.96
LoadBalancer Ingress:     192.0.2.89
Port:                     <unset>  8765/TCP
TargetPort:               9376/TCP
NodePort:                 <unset>  30593/TCP
Endpoints:                172.17.0.3:9376
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

IP-адреса балансувальника навантаження вказана поруч з LoadBalancer Ingress.

minikube service example-service --url

Збереження вихідної IP-адреси клієнта

Типово, вихідна IP-адреса, яку бачить цільовий контейнер, не є оригінальною вихідною IP-адресою клієнта. Щоб увімкнути збереження IP-адреси клієнта, можна налаштувати наступні поля в .spec Service:

• .spec.externalTrafficPolicy — вказує, чи бажає цей Service маршрутизувати зовнішній трафік до вузлів локально або по всьому кластеру. Є два доступні варіанти: Cluster (стандартно) і Local. Cluster приховує вихідну IP-адресу клієнта та може спричинити другий перехід на інший вузол, але має гарне загальне розподілення навантаження. Local зберігає вихідну IP-адресу клієнта та уникає другого переходу для сервісів типу LoadBalancer та NodePort, але є ризик потенційно нерівномірного розподілення трафіку.
• .spec.healthCheckNodePort — вказує порт для перевірки стану вузлів (числовий номер порту) для Service. Якщо ви не вкажете healthCheckNodePort, контролер Service виділить порт з діапазону NodePort вашого кластера. Ви можете налаштувати цей діапазон, встановивши параметр командного рядка API-сервера --service-node-port-range. Service використовуватиме значення healthCheckNodePort, якщо ви його вкажете, за умови, що type Service встановлено як LoadBalancer і externalTrafficPolicy встановлено як Local.

Встановлення externalTrafficPolicy на Local у маніфесті Service активує цю функцію. Наприклад:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  externalTrafficPolicy: Local
  type: LoadBalancer

Застереження та обмеження при збереженні вихідних IP-адрес

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

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

Якщо NumServicePods << NumNodes або NumServicePods >> NumNodes, спостерігається майже рівномірний розподіл, навіть без коефіцієнтів.

Внутрішній трафік між Podʼами повинен поводитися подібно до Service типу ClusterIP, з рівною ймовірністю для всіх Podʼів.

Балансувальники для збору сміття

У звичайному випадку, відповідні ресурси балансувальника навантаження у хмарного провайдера повинні бути видалені незабаром після видалення Service типу LoadBalancer. Але відомо, що є різні крайні випадки, коли хмарні ресурси залишаються після видалення асоційованого Service. Для запобігання цьому було введено захист за допомогою завершувачів для Service LoadBalancers. Використовуючи завершувачі, ресурс Service ніколи не буде видалено, поки відповідні ресурси балансувальника навантаження також не будуть видалені.

Зокрема, якщо Service має type LoadBalancer, контролер Service додасть завершувач з назвою service.kubernetes.io/load-balancer-cleanup. Завершувач буде видалений тільки після видалення ресурсу балансувальника навантаження. Це запобігає залишенню ресурсів балансувальника навантаження навіть у крайніх випадках, таких як падіння контролера сервісу.

Постачальники зовнішніх балансувальників навантаження

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

Коли type Service встановлено як LoadBalancer, Kubernetes забезпечує функціональність, еквівалентну type ClusterIP для Podʼів у кластері, і розширює її, програмуючи (зовнішній для Kubernetes) балансувальник навантаження з записами для вузлів, що є місцем розташування відповідних Podʼів Kubernetes. Панель управління Kubernetes автоматизує створення зовнішнього балансувальника навантаження, перевірки стану (якщо необхідно), і правила фільтрації пакетів (якщо необхідно). Після того як хмарний провайдер виділить IP-адресу для балансувальника навантаження, панель управління знаходить цю зовнішню IP-адресу та вносить її в обʼєкт Service.

Що далі

• Ознайомтеся з підручником Підключення застосунків за допомогою Service
• Дізнайтеся більше про Service
• Дізнайтеся більше про Ingress

8 - Отримання переліку всіх образів контейнерів, що працюють у кластері

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

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

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

• Killercoda
• Play with Kubernetes

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

Перелік всіх образів контейнерів у всіх просторах імен

• Отримайте всі Podʼи у всіх просторах імен за допомогою kubectl get pods --all-namespaces.
• Форматуйте вивід для включення лише списку імен образів контейнерів, використовуючи -o jsonpath={.items[*].spec['initContainers', 'containers'][*].image}. Це рекурсивно розбирає поле image з отриманого JSON.
  • Ознайомтеся з довідником по jsonpath для додаткової інформації про використання jsonpath.
• Форматуйте вивід за допомогою стандартних інструментів: tr, sort, uniq.
  • Використовуйте tr для заміни пробілів на нові рядки.
  • Використовуйте sort для сортування результатів.
  • Використовуйте uniq для агрегування кількості образів.

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

Jsonpath інтерпретується наступним чином:

• .items[*]: для кожного отриманого значення.
• .spec: отримати spec.
• ['initContainers', 'containers'][*]: для кожного контейнера.
• .image: отримати образ.

Отримання переліку образів контейнерів в розрізі Podʼів

Форматування може бути додатково налаштоване за допомогою операції range для ітерації по елементах індивідуально.

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort

Отримання переліку образів контейнерів за мітками Podʼів

Щоб опрацьовувати лише Podʼи, які відповідають конкретній мітці, використовуйте прапорець -l. Наступне відповідає збігам лише для Podʼів з мітками, що відповідають app=nginx.

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx

Отримання переліку образів контейнерів в розрізі просторів імен Podʼів

Щоб опрацьовувати лише Podʼи в конкретному просторі імен, використовуйте прапорець namespace. Наступне відповідає збігам лише для Podʼів у просторі імен kube-system.

kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}"

Отримання переліку образів контейнерів з використанням go-template замість jsonpath

Як альтернативу jsonpath, Kubectl підтримує використання go-templates для форматування виходу:

kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"

Що далі

Довідники

• Jsonpath
• Go template

9 - Налаштування Ingress у Minikube з використанням NGINX Ingress Controller

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

Ця сторінка показує, як налаштувати простий Ingress, який маршрутизує запити до Service 'web' або 'web2' залежно від HTTP URI.

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

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

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

• Killercoda
• Play with Kubernetes

Створіть кластер minikube

Якщо ви ще не налаштували кластер локально, виконайте minikube start, щоб створити кластер.

Увімкніть Ingress-контролер

1. Для увімкнення NGINX Ingress Controller, виконайте наступну команду:

   minikube addons enable ingress
   

2. Переконайтеся, що NGINX Ingress Controller працює:

   kubectl get pods -n ingress-nginx
   

   Примітка:

   Це може зайняти до хвилини, перш ніж ви побачите що ці Podʼи, що працюють нормально.

   Вивід подібний до:

   NAME                                        READY   STATUS      RESTARTS    AGE
   ingress-nginx-admission-create-g9g49        0/1     Completed   0          11m
   ingress-nginx-admission-patch-rqp78         0/1     Completed   1          11m
   ingress-nginx-controller-59b45fb494-26npt   1/1     Running     0          11m
   

Розгорніть застосунок hello world

1. Створіть Deployment за допомогою наступної команди:

   kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
   

   Вивід має бути:

   deployment.apps/web created
   

   Переконайтеся, що Deployment перебуває у стані Ready:

   kubectl get deployment web 
   

   Вивід має бути подібний до:

   NAME   READY   UP-TO-DATE   AVAILABLE   AGE
   web    1/1     1            1           53s
   

2. Опублікуйте Deployment:

   kubectl expose deployment web --type=NodePort --port=8080
   

   Вивід має бути:

   service/web exposed
   

3. Переконайтеся, що Service створено і він доступний на порті вузла:

   kubectl get service web
   

   Вивід подібний до:

   NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
   web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
   

4. Відвідайте Service через NodePort, використовуючи команду minikube service. Дотримуйтесь інструкцій для вашої платформи:

   • Linux
   • MacOS

   minikube service web --url
   

   Вивід подібний до:

   http://172.17.0.15:31637
   

   Виконайте запит до URL, отриманого у попередньому кроці:

   curl http://172.17.0.15:31637 
   

   # Команду потрібно виконати в окремому терміналі.
   minikube service web --url 
   

   Вивід подібний до:

   http://127.0.0.1:62445
   ! Оскільки ви використовуєте драйвер Docker на darwin, термінал має бути відкритий для його запуску.
   

   В іншому терміналі виконайте запит до URL, отриманого у попередньому кроці:

   curl http://127.0.0.1:62445 
   

   
   

   Вивід подібний до:

   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
   

   Тепер ви можете отримати доступ до застосунку прикладу через IP-адресу Minikube і NodePort. Наступний крок дозволяє отримати доступ до застосунку, використовуючи ресурс Ingress.

Створіть Ingress

Наступний маніфест визначає Ingress, який надсилає трафік до вашого Service через hello-world.example.

1. Створіть файл example-ingress.yaml з наступним вмістом:

   service/networking/example-ingress.yaml

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: example-ingress
   spec:
     ingressClassName: nginx
     rules:
       - host: hello-world.example
         http:
           paths:
             - path: /
               pathType: Prefix
               backend:
                 service:
                   name: web
                   port:
                     number: 8080

2. Створіть обʼєкт Ingress, виконавши наступну команду:

   kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
   

   Вивід має бути:

   ingress.networking.k8s.io/example-ingress created
   

3. Переконайтеся, що IP-адреса встановлена:

   kubectl get ingress
   

   Примітка:

   Це може тривати кілька хвилин.

   Ви повинні побачити IPv4-адресу у стовпці ADDRESS; наприклад:

   NAME              CLASS   HOSTS                 ADDRESS        PORTS   AGE
   example-ingress   nginx   hello-world.example   172.17.0.15    80      38s
   

4. Перевірте, що Ingress-контролер спрямовує трафік, дотримуючись інструкцій для вашої платформи:

   Примітка:

   Мережа обмежена, якщо використовується драйвер Docker на MacOS (Darwin), і IP вузла не доступний безпосередньо. Щоб Ingress працював, потрібно відкрити новий термінал і виконати minikube tunnel. Необхідні дозволи sudo, тому надайте пароль при запиті.
   • Linux
   • MacOS

   curl --resolve "hello-world.example:80:$( minikube ip )" -i http://hello-world.example
   

   minikube tunnel
   

   Вивід подібний до:

   Tunnel successfully started
   
   NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
   
   The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
   sudo permission will be asked for it.
   Starting tunnel for service example-ingress.
   

   В іншому терміналі виконайте наступну команду:

   curl --resolve "hello-world.example:80:127.0.0.1" -i http://hello-world.example
   

   
   Ви повинні побачити:

   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
   

5. За бажанням ви також можете відвідати hello-world.example зі свого оглядача.

   Додайте рядок у кінець файлу /etc/hosts на вашому компʼютері (потрібні права адміністратора):

   • Linux
   • MacOS

   Знайдіть зовнішню IP-адресу, як вказано у звіті minikube

     minikube ip 
   

   
   

     172.17.0.15 hello-world.example
   

   Примітка:

   Змініть IP-адресу відповідно до виводу з minikube ip.

   127.0.0.1 hello-world.example
   

   
   

   Після цього ваш вебоглядач надсилатиме запити на URL-адреси hello-world.example до Minikube.

Створіть другий Deployment

1. Створіть інший Deployment, виконавши наступну команду:

   kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
   

   Вивід має бути:

   deployment.apps/web2 created
   

   Переконайтеся, що Deployment перебуває у стані Ready:

   kubectl get deployment web2 
   

   Вихід має бути подібний до:

   NAME   READY   UP-TO-DATE   AVAILABLE   AGE
   web2   1/1     1            1           16s
   

2. Опублікуйте другий Deployment:

   kubectl expose deployment web2 --port=8080 --type=NodePort
   

   Вивід має бути:

   service/web2 exposed
   

Редагування поточного Ingress

1. Відредагуйте поточний маніфест example-ingress.yaml та додайте наступні рядки в кінці:

   - path: /v2
     pathType: Prefix
     backend:
       service:
         name: web2
         port:
           number: 8080
   

2. Застосуйте зміни:

   kubectl apply -f example-ingress.yaml
   

   Ви маєте побачити:

   ingress.networking/example-ingress configured
   

Перевірка вашого Ingress

1. Отримайте доступ до першої версії застосунку Hello World.

   • Linux
   • MacOS

   curl --resolve "hello-world.example:80:$( minikube ip )" -i http://hello-world.example
   

   minikube tunnel
   

   Вивід подібний до:

   Tunnel successfully started
   
   NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
   
   The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
   sudo permission will be asked for it.
   Starting tunnel for service example-ingress.
   

   В іншому терміналі виконайте наступну команду:

   curl --resolve "hello-world.example:80:127.0.0.1" -i http://hello-world.example
   

   
   

   Вивід подібний до:

   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
   

2. Отримайте доступ до другої версії застосунку Hello World.

   • Linux
   • MacOS

   curl --resolve "hello-world.example:80:$( minikube ip )" -i http://hello-world.example/v2
   

   minikube tunnel
   

   Вивід подібний до:

   Tunnel successfully started
   
   NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...
   
   The service/ingress example-ingress requires privileged ports to be exposed: [80 443]
   sudo permission will be asked for it.
   Starting tunnel for service example-ingress.
   

   В іншому терміналі виконайте наступну команду:

   curl --resolve "hello-world.example:80:127.0.0.1" -i http://hello-world.example/v2
   

   Вивід подібний до:

   Hello, world!
   Version: 2.0.0
   Hostname: web2-75cd47646f-t8cjk
   

   Примітка:

   Якщо ви виконали необовʼязковий крок для оновлення /etc/hosts, ви також можете відвідати hello-world.example та hello-world.example/v2 зі свого огляача.

Що далі

• Докладніше про Ingress
• Докладніше про Контролери Ingress
• Докладніше про Service

10 - Спілкування між контейнерами в одному Podʼі за допомогою спільного тому

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

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

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

• Killercoda
• Play with Kubernetes

Створення Pod, що запускає два контейнери

У цьому завданні ви створите Pod, який запускає два контейнери. Ці два контейнери спільно використовують Том, який вони можуть використовувати для спілкування. Ось конфігураційний файл для Podʼа:

pods/two-container-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:

  restartPolicy: Never

  volumes:
  - name: shared-data
    emptyDir: {}

  containers:

  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

У конфігураційному файлі видно, що Pod має Том з назвою shared-data.

Перший контейнер, зазначений у конфігураційному файлі, запускає сервер nginx. Шлях монтування для спільного тому — /usr/share/nginx/html. Другий контейнер базується на образі debian і має шлях монтування /pod-data. Другий контейнер виконує наступну команду і потім завершується.

echo Hello from the debian container > /pod-data/index.html

Зверніть увагу, що другий контейнер записує файл index.html в кореневу теку сервера nginx.

Створіть Pod і два контейнери:

kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml

Перегляньте інформацію про Pod та контейнери:

kubectl get pod two-containers --output=yaml

Ось частина вихідних даних:

apiVersion: v1
kind: Pod
metadata:
    ...
    name: two-containers
    namespace: default
    ...
spec:
    ...
    containerStatuses:

    - containerID: docker://c1d8abd1 ...
    image: debian
    ...
    lastState:
        terminated:
        ...
    name: debian-container
    ...

    - containerID: docker://96c1ff2c5bb ...
    image: nginx
    ...
    name: nginx-container
    ...
    state:
        running:
    ...

Ви бачите, що контейнер debian завершив роботу, а контейнер nginx все ще працює.

Отримайте доступ до shell контейнера nginx:

kubectl exec -it two-containers -c nginx-container -- /bin/bash

У вашому shell перевірте, що nginx працює:

root@two-containers:/# apt-get update
root@two-containers:/# apt-get install curl procps
root@two-containers:/# ps aux

Вихідні дані схожі на це:

USER       PID  ...  STAT START   TIME COMMAND
root         1  ...  Ss   21:12   0:00 nginx: master process nginx -g daemon off;

Згадайте, що контейнер debian створив файл index.html в кореневій теці nginx. Використовуйте curl, щоб надіслати GET запит на сервер nginx:

root@two-containers:/# curl localhost

Вихідні дані показують, що nginx обслуговує вебсторінку, написану контейнером debian:

Hello from the debian container

Обговорення

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

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

Що далі

• Дізнайтеся більше про шаблони для композитних контейнерів.

• Дізнайтеся про композитні контейнери для модульної архітектури.

• Перегляньте Налаштування Pod для використання тому для зберігання.

• Перегляньте Налаштування Pod для спільного використання простору процесів між контейнерами.

• Перегляньте Том.

• Перегляньте Pod.

11 - Налаштування DNS для кластера

Kubernetes пропонує надбудову DNS для кластера, яку типово увімкнено у більшості підтримуваних середовищ. У Kubernetes версії 1.11 і пізніших версіях рекомендовано використовувати CoreDNS, який стандартно встановлюється з kubeadm.

Для отримання додаткової інформації про налаштування CoreDNS для кластера Kubernetes дивіться Налаштування DNS-сервісу. Приклад, який демонструє, як використовувати Kubernetes DNS з kube-dns, дивіться у прикладі втулка Kubernetes DNS.

12 - Доступ до Service, що працюють в кластерах

Ця сторінка показує, як підʼєднатись до Serviceʼів, що працюють у кластері Kubernetes.

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

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

• Killercoda
• Play with Kubernetes

Доступ до Serviceʼів, що працюють у кластері

У Kubernetes Вузли, Podʼи та Serviceʼи мають власні IP-адреси. У багатьох випадках IP-адреси вузлів, Podʼів та деякі IP-адреси Service у кластері не можуть бути маршрутизовані, тому вони не будуть досяжними з машини за межами кластера, такої як ваш настільний компʼютер.

Способи приєднання

Ви маєте кілька варіантів приєднання до вузлів, Podʼів та Serviceʼів ззовні кластера:

• Доступ до Servicʼів через публічні IP-адреси.
  • Використовуйте Service з типом NodePort або LoadBalancer, щоб зробити Service доступним ззовні кластера. Дивіться документацію Service та kubectl expose.
  • Залежно від середовища вашого кластера, це може тільки відкрити Service для вашої корпоративної мережі, або ж зробити його доступним в інтернеті. Подумайте, чи є Service безпечним для відкриття. Чи має він власну автентифікацію?
  • Розміщуйте Podʼи за Serviceʼами. Щоб отримати доступ до одного конкретного Pod з набору реплік, наприклад, для налагодження, додайте унікальну мітку до Podʼа і створіть новий Service, який обирає цю мітку.
  • У більшості випадків розробнику застосунків не потрібно безпосередньо звертатися до вузлів за їх IP-адресами.
• Доступ до Serviceʼів, вузлів або Podʼів за допомогою проксі-дієслова (Proxy Verb).
  • Виконує автентифікацію та авторизацію на api-сервері перед доступом до віддаленого Service. Використовуйте це, якщо Service недостатньо безпечні для відкриття в інтернеті, або для доступу до портів на IP-адресі вузла, або для налагодження.
  • Проксі можуть викликати проблеми для деяких вебзастосунків.
  • Працює тільки для HTTP/HTTPS.
  • Описано тут.
• Доступ з вузла або Podʼа в кластері.
  • Запустіть Pod та отримайте доступ до shell у ньому за допомогою kubectl exec. Підʼєднуйтесь до інших вузлів, Podʼів та Serviceʼів з цього shell.
  • Деякі кластери можуть дозволити вам підʼєднатись по SSH до вузла в кластері. Звідти ви можете отримати доступ до Serviceʼів кластера. Це нестандартний метод і працюватиме на одних кластерах, але на інших — ні. Оглядачі та інші інструменти можуть бути встановлені або не встановлені. DNS кластера може не працювати.

Виявлення вбудованих Service

Зазвичай у кластері є кілька Serviceʼів, які запускаються у просторі імен kube-system. Отримайте їх список за допомогою команди kubectl cluster-info:

kubectl cluster-info

Вихідні дані подібні до цього:

Kubernetes master is running at https://192.0.2.1
elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy

Це показує URL з проксі-дієсловом для доступу до кожного Service. Наприклад, у цьому кластері ввімкнено кластерне логування (з використанням Elasticsearch), до якого можна звернутися за адресою https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/ за умови наявності відповідних облікових даних або через проксі kubectl за адресою: http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/.

Ручне створення URL-адрес проксі api-сервера

Як згадувалося вище, ви використовуєте команду kubectl cluster-info, щоб отримати URL проксі для Service. Щоб створити URL-адреси проксі, що включають точки доступу Service, суфікси та параметри, додайте до URL проксі Serviceʼу: http://kubernetes_master_address/api/v1/namespaces/namespace_name/services/[https:]service_name[:port_name]/proxy

Якщо ви не задали імʼя для вашого порту, вам не потрібно вказувати port_name в URL. Ви також можете використовувати номер порту замість port_name для іменованих та неіменованих портів.

Стандартно апі-сервер проксює до вашого Serviceʼу за допомогою HTTP. Щоб використовувати HTTPS, додайте префікс до імені Serviceʼу https:: http://<kubernetes_master_address>/api/v1/namespaces/<namespace_name>/services/<service_name>/proxy.

Підтримувані формати для сегмента <service_name> URL-адреси:

• <service_name> — проксює до стандартного порту або до неіменованого порту за допомогою http
• <service_name>:<port_name> — проксює до вказаного імені порту або номера порту за допомогою http
• https:<service_name>: — проксює до стандартного порту або до неіменованого порту за допомогою https (зверніть увагу на кінцеву двокрапку)
• https:<service_name>:<port_name> — проксює до вказаного імені порту або номера порту за допомогою https

Приклади

• Для доступу до точки доступу сервісу Elasticsearch _search?q=user:kimchy, використовуйте:

  http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
  

• Для доступу до інформації про стан кластера Elasticsearch _cluster/health?pretty=true, використовуйте:

  https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
  

  Інформація про стан подібна до цієї:

  {
    "cluster_name" : "kubernetes_logging",
    "status" : "yellow",
    "timed_out" : false,
    "number_of_nodes" : 1,
    "number_of_data_nodes" : 1,
    "active_primary_shards" : 5,
    "active_shards" : 5,
    "relocating_shards" : 0,
    "initializing_shards" : 0,
    "unassigned_shards" : 5
  }
  

• Для доступу до https інформації про стан кластера Elasticsearch _cluster/health?pretty=true, використовуйте:

  https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
  

Використання вебоглядачів для доступу до Serviceʼів, що працюють у кластері

Ви можете вставити URL-адресу проксі api-сервера у адресний рядок оглядача. Однак:

• Вебоглядачі зазвичай не можуть передавати токени, тому вам може доведеться використовувати базову автентифікацію (пароль). Api-сервер можна налаштувати для роботи з базовою автентифікацією, але ваш кластер може бути не налаштований для цього.
• Деякі вебзастосунки можуть не працювати, особливо ті, що використовують клієнтський javascript для створення URL-адрес, не знаючи про префікс шляху проксі.