Різне · 28 березня 2023, 9:30 1953

20 запитань для співбесіди з Kubernetes. Шаблони проєктування контейнерів

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Це переклад матеріалу з Medium, але ми з радістю опублікуємо ваші підбірки запитань, надсилайте на [email protected]

1. Що таке Pod?

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

2. Чи можна помістити кілька контейнерів у под?

Так. Под, який містить один контейнер, є single-контейнерним подом, і це найпоширеніший випадок використання kubernetes. Под, який містить кілька взаємопов’язаних контейнерів, відноситься до мультиконтейнерного пода.

3. Назвіть шаблони контейнерів, які ви зустрічаєте або використовуєте?

1. Init Container Pattern
2. Sidecar Container Pattern
3. Adapter Container Pattern
4. Ambassador Container Pattern

4. Що таке Init Container Pattern?

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

Усі контейнери ініціалізації виконуватимуться послідовно, і якщо в контейнері ініціалізації виникне помилка, модуль буде перезапущено, що означає, що всі контейнери ініціалізації буде виконано знову. Тому такі контейнери краще проєктувати простими, швидкими і ідемпотентними (такими, що повторне виконання не змінює результату досягнутого під час першого виконання).

5. Наведіть приклад Init Container Pattern?

Репозиторій з прикладом. .

apiVersion: v1
kind: Pod
metadata:
  name: init-container-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  # These containers are run during pod initialization
  initContainers:
  - name: busybox
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "echo '<html><h1>Hi I am from Init container</h1><html>' >> /work-dir/index.html"]
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

7. Коли ви використовуєте Init Container Pattern?

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

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

8. Як налаштувати обмеження ресурсів для Init Container Pattern?

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

* Врахувати найвищі обмеження ресурсів контейнера ініціалізації (оскільки контейнери ініціалізації працюють послідовно).

* Додати всі обмеженя ресурсів основних контейнерів (оскільки всі контейнери програми працюють паралельно).

9. Що таке Sidecar Container Design?

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

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

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

10. Наведіть приклад Sidecar Container Design?

Репозиторій з прикладом.

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-container-demo
spec:
  containers:
  - image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo echo $(date -u) 'Hi I am from Sidecar container' >> /var/log/index.html; sleep 5;done"]
    name: sidecar-container
    resources: {}
    volumeMounts:
    - name: var-logs
      mountPath: /var/log
  - image: nginx
    name: main-container
    resources: {}
    ports:
      - containerPort: 80
    volumeMounts:
    - name: var-logs
      mountPath: /usr/share/nginx/html
  dnsPolicy: Default
  volumes:
  - name: var-logs
    emptyDir: {}

11. Коли ви використовуєте Sidecar Container Design?

Коли ви хочете розширити функціональність контейнера в поді, не змінюючи його.
Для синхронізації коду основного контейнера з git server pull.
Для надсилання log events на зовнішній сервер.
Для завдань, пов’язаних із мережею.

12. Як налаштувати обмеження ресурсів для Sidecar Container Pattern?

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

* Додати всі обмеження ресурсів для основних контейнерів, а також контейнерів Sidecar (оскільки всі контейнери працюють паралельно).

13. Що таке Adapter Container Pattern?

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

Уявіть, що у вас є модуль з єдиним подом, який працює дуже добре, але він не має однакового інтерфейсу з іншими системами для інтеграції або роботи з ним. Як зробити так, щоб цей под мав уніфікований інтерфейс із стандартизованим форматом, щоб інші системи могли працювати з ним? Adapter Container Pattern допомагає саме в цій ситуації.

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

14. Наведіть приклад Adapter Container Pattern?

Репозиторій з прикладомю.

apiVersion: v1
kind: Pod
metadata:
  name: adapter-container-demo
spec:
  containers:
  - image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u)'#This is log' >> /var/log/file.log; sleep 5;done"]
    name: main-container
    resources: {}
    volumeMounts:
    - name: var-logs
      mountPath: /var/log
  - image: bbachin1/adapter-node-server
    name: adapter-container
    imagePullPolicy: Always
    resources: {}
    ports:
      - containerPort: 3080
    volumeMounts:
    - name: var-logs
      mountPath: /var/log
  dnsPolicy: Default
  volumes:
  - name: var-logs
    emptyDir: {}

15. Коли ви використовуєте Adapter Container Pattern?

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

16. Як налаштувати обмеження ресурсів для Adapter Container Pattern?

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

* Додати всі обмеженя ресурсів основних контейнерів, а також контейнерів адаптера (оскільки всі контейнери працюють паралельно)

17. Що таке шаблон Ambassador Container Pattern?

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

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

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

18. Наведіть приклад Ambassador Container Pattern?

Репозиторій з прикладом.

apiVersion: v1
kind: Pod
metadata:
  name: ambassador-container-demo
spec:
  containers:
  - image: bbachin1/main-container
    name: main-container
    imagePullPolicy: Always
    resources: {}
    ports:
      - containerPort: 9000
  - image: bbachin1/nginx-server-proxy
    name: ambassador-container
    imagePullPolicy: Always
    resources: {}
    ports:
      - containerPort: 3000
  dnsPolicy: Default

19. Коли використовувати Ambassador Container Pattern?

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

20. Як налаштувати обмеження ресурсів для Ambassador Container Pattern?

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

* Додати всі обмеженя ресурсів основних контейнерів, а також контейнерів-амбасадорів (оскільки всі контейнери працюють паралельно).

Шаблони контейнерів в деталях: