Компоненти Kubernetes

В результаті розгортання Kubernetes ви отримуєте кластер.

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

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

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

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

Компонент панелі управління приймають глобальні рішення щодо кластера (наприклад, планування), а також виявляють та реагують на події кластера (наприклад, запуск нового Podʼу якщо поле replicas Deploymentʼу не задовільне).

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

kube-apiserver

Сервер API є компонентом панелі управління Kubernetes, який надає доступ до API Kubernetes. Сервер API є фронтендом для панелі управління Kubernetes.

Основна реалізація сервера API Kubernetes — kube-apiserver. kube-apiserver спроєктований для горизонтального масштабування, тобто масштабується за допомогою розгортання додаткових екземплярів. Ви можете запустити кілька екземплярів kube-apiserver та балансувати трафік між ними.

etcd

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

Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є план резервного копіювання даних.

Ви можете знайти докладну інформацію про etcd в офіційній документації.

kube-scheduler

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

При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity та anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання.

kube-controller-manager

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

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

Існує багато різних типів контролерів. Декілька прикладів:

• Контролер вузла (Node controller): Відповідає за виявлення та реакцію, коли вузли виходять з ладу.
• Контролер завдань (Job controller): Спостерігає за обʼєктами Job, які представляють одноразові завдання, а потім створює Podʼи для виконання цих завдань до завершення.
• Контролер EndpointSlice: Заповнює обʼєкти EndpointSlice (для надання звʼязку між Serviceʼами та Podʼами).
• Контролер облікового запису служби (ServiceAccount controller): Створює стандартні облікові записи служби для нових просторів імен.

Вище наведений перелік не є вичерпним.

cloud-controller-manager

Компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

cloud-controller-manager запускає лише ті контролери, які є специфічними для вашого хмарного постачальника. Якщо ви використовуєте Kubernetes на власних серверах або у навчальному середовищі на своєму ПК, кластер не має менеджера хмарових контролерів.

Так само як і з kube-controller-manager, cloud-controller-manager обʼєднує кілька логічно незалежних кілець управління в єдиний виконуваний файл, який ви запускаєте як один процес. Ви можете масштабувати його горизонтально (запускати більше одного екземпляра), щоб покращити продуктивність чи допомогти витримати випадки відмов.

Наступні контролери можуть мати залежності від хмарного постачальника:

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

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

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

kubelet

Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів в Podʼах.

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

kube-proxy

kube-proxy є мережевим проксі, що запущений на кожному вузлі кластера і реалізує частину концепції Kubernetes Service.

kube-proxy забезпечує підтримання мережевих правил на вузлах. Ці правила обумовлюють підключення мережею до ваших Podʼів всередині чи поза межами кластера.

kube-proxy використовує шар фільтрації пакетів операційної системи, за його наявності. В іншому випадку kube-proxy скеровує трафік самостійно.

Середовище виконання контейнерів (Container runtime)

Основний компонент, який дозволяє Kubernetes ефективно запускати контейнери. Він відповідає за керування виконанням і життєвим циклом контейнерів у середовищі Kubernetes.

Kubernetes підтримує середовища виконання контейнерів, такі як containerd, CRI-O, та будь-яку іншу реалізацію Kubernetes CRI (інтерфейс виконання контейнерів).

Доповнення

Доповнення використовують ресурси (DaemonSet, Deployment, та інші) для реалізації функцій кластера. Оскільки вони надають функції на рівні кластера, ресурси простору імен для додатків належать до простору імен kube-system.

Деякі доповнення описані нижче; за повним переліком доповнень звертайтесь до розділу Доповнення.

DNS

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

Кластерний DNS — це DNS-сервер, додатковий до інших DNS-серверів у вашому середовищі, який обслуговує DNS-записи для служб Kubernetes.

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

Web UI (Dashboard)

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

Моніторинг ресурсів контейнера

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

Логування на рівні кластера

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

Втулки мережі

Втулки мережі – це програмні компоненти, які впроваджують специфікацію інтерфейсу мережі контейнера (CNI). Вони відповідають за виділення IP-адрес для Podʼів та уможливлюють їм взаємодію один з одним у межах кластера.

Що далі

Дізнайтесь також про:

• Вузли та обмін трафіком між ними та панеллю управління.
• Контролери Kubernetes.
• kube-scheduler, який є стандартним планувальником Kubernetes.
• Офіційна документація etcd.
• Кілька середовищ виконання контейнерів в Kubernetes.
• Інтеграці з хмарними постачальниками з використанням cloud-controller-manager.
• Команди kubectl.