Итак, я много слышал о Kubernetes И как люди находят это таким крутым. Это действительно заинтриговало меня, и я хотел глубже взглянуть на архитектура .
Вот моя попытка поставить мои знания на простом языке.
Как мы знаем, Kubernetes это инструмент оркестровки контейнера, который произвел революцию в процессе развертывания. Все говорят об этом, и изо дня в день все больше и больше компаний принимают это. Давайте поймем его структуру.
Если у вас есть какие -либо сомнения во время прохождения блога, не стесняйтесь обращаться к Kubernetes Официальная документация Анкет Вы также можете обратиться к этому блог чтобы получить краткое Введение в Kubernetes Анкет
Прежде чем погрузиться в архитектуру, давайте впервые поймем несколько концепций, которые помогут понять рабочий процесс K8S (Kubernetes) лучше.
Основные концепции Kubernetes
1. Декларатив против императива
Давайте поймем это с примером, предположим, вас попросили водить машину ровно 60 км/час. Чтобы достичь этого, вы, вероятно, попытались бы ускорить автомобиль, пока не достигнете 60 км/час, и если автомобиль превышает 60 км/час, вы попытаетесь замедлить его.
Это Декларативная модель где вы описываете желаемое состояние не заявляя о действиях, необходимых для достижения туда.
С другой стороны, если бы вам просто сказали замедлить или ускорить машину, это будет Императивная модель где вам был предоставлен список действий, которые создадут желаемое состояние Анкет
Так что важно понять, что Kubernetes Бежит на Декларативная модель Это экономит нам много времени и энергии. Мы можем просто сказать: «Убедитесь, что есть четыре капсула, работающие», вместо того, чтобы сформулировать его «запустить этот стручок, запустить этот капсул». K8s позаботится обо всем остальном для нас.
2. Контур управления
Контрольные петли являются одной из основных функций, которые делают Kubernetes такой особенный. Почти каждая структура в Kubernetes использует какой -то цикл управления, где вы описываете Государство о желаемых объектах, а не фактических шагов, чтобы добраться туда.
Это цикл, который постоянно работает и включает в себя следующие процессы:
наблюдать : он наблюдает текущее состояние Kubernetes кластер Анкет
diff : сравнивает текущее состояние кластера с желаемым состоянием.
Акт : Убедитесь, что нынешнее состояние соответствует желаемому состоянию.
3. Примирение
Если вы поняли цикл управления и декларативные заявления, это в основном реализация двух. Примирение — это простой процесс, который гарантирует, что Фактическое состояние выглядит как желаемое состояние через наблюдение, дифференциал и цикл управления ACT.
Kubernetes Architecture
Теперь, когда мы поняли о состояния и Контрольные петли В Kubernetes это будет подходящее время, чтобы познакомиться с фактическим Архитектура Kubernetes Анкет
Изучение K8 может быть ошеломляющим Поэтому я постараюсь предоставить очень высокий взгляд на то, как он структурирован. Проверьте Официальная документация для ссылки.
1. Мастер -узел
Слева у нас есть Мастер -узел и связаны с ним несколько рабочие узлы Анкет Мастер -узел запускает несколько важных процессов, которые важны для запуска Kubernetes. Он также контролирует и управляет рабочими узлами.
Мастер -узел — это место, где план действия, необходимый для выравнивания текущего состояния с желаемое состояние сформирован. Мастер -узел в основном состоит из следующего компонента:
Kube-Apiserver : Это Самый важный Компонент, ответственный за обработку всех внутренних и внешних запросов. Kube-Apiserver позволяет общаться между Мастер -узел и рабочие узлы Анкет
Kube-Schedular : Это в основном создает новые стручки и решает, на каком рабочем узле его можно развернуть. Он также состоит из всех ресурсов для создания и развертывания стручки на рабочие узлы Если старая стручка умирает.
Kube-Controller-Manager : Это работает Процессы контроллера На заднем плане, которые заботятся о кластере. Одна из функций контроллеров — общаться с Kube-Schedular Когда стручок умирает и следит за желаемое состояние То, о чем мы говорили, достигается.
ETCD : Это Ключевая стоимость Хранить базу данных, в которой хранится состояние Kubernetes кластер, как количество стручков, их состояние и т. Д.
2. Работник узел
Справа у нас есть Узел рабочих Анкет В то время как Мастер -узел Заполняет задачи, которые важны для функционирования Kubernetes, это Узел рабочих Это выполняет задачи, выполненные пользователем.
Для запуска кластера может быть более одного рабочего узла, но для запуска кластера необходимо, но хотя бы один рабочий узел необходим для запуска кластера.
Прежде чем посмотреть на компоненты рабочего узла, давайте сначала поймем, что стручки находятся.
Стручки это наименьшее устройство в Kubernetes. Они состоят из одного или многих контейнеры и действовать как один экземпляр приложения.
Теперь возвращаюсь к рабочие узлы , они состоит из:
Двигатель выполнения контейнера : Это двигатель, который запускает контейнеры Внутри POD Анкет Например, у нас есть Docker На рисунке выше. Вы можете прочитать больше о Docker здесь
Кубелет : Он взаимодействует с двигателем времени выполнения контейнера (Docker) и гарантирует, что необходимые контейнеры работают внутри стручков. Это также облегчает связь между рабочим узлом и главным узлом.
Kube-Proxy : Это обеспечивает как внутреннюю, так и внешнюю сеть среди стручки Анкет
Вывод
Ты достиг конец! Это был краткий обзор Kubernetes Architecture Анкет Я надеюсь, что теперь у вас есть более четкая картина концепций, стоящих за этим.
Есть несколько деталей, которые я пропустил, чтобы сохранить объяснение простым, но не стесняйтесь проверять Документация Анкет Я действительно надеюсь, что вам понравился блог, и вы даете мне знать в комментариях, если вы это сделали.
Не стесняйтесь подключить со мной на Twitter И скачите, я буду более чем счастлив поговорить.:)
Этот блог является частью моего #100daysofkubernetes вызов. Проверьте мое путешествие на Twitter Когда вы заходите.: D.
Спасибо за чтение!:)
Оригинал: «https://dev.to/lakshya806/kubernetes-architecture-simplified-2-4aag»