> For the complete documentation index, see [llms.txt](https://kirell.gitbook.io/madman/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kirell.gitbook.io/madman/k8s/bazovaya-arkhetiktura.md).

# Базовая архетиктура

Рассмотрим 2 вида узлов 1 - master 2 - slave

рабочие сервисы (node \ узел ) сервис кластера выполняющий всю работу

На каждой ноде должны быть установлены минимум эти компоненты!

1. Kublet процесс самого kubernetes правляет и планирует
2. среда выполнения контейнера например Docker но может быть и любая другая технология.
3. отвечает за пересылку запросов от служб к модулям Kube Proxy и логику отправляющую запрос на ту же node которой был отправлен запрос. Таким образом мы избигаем большого количества запросов и расходы на сеть

Взаимодействие с кластером....

1. как опеределяетья время запуска приложения
2. какие процессы отслеживаются если реплика или бд умерает и т.д а затем пеерносит или запускает снова
3. когда происходит добовление нового сервера как он присоеденяеться к кластеру чтобы запускать на нем модули и т.д Все эти процессы управления управляються главными узлами или Master node 4 процесса запущены на всех master node которые управляют состоянием кластера и рабочими node
   1. API Server для взаимодействия с кластером CLI или GUI. Так же выступает в роле Getkeeper для аутентификации\
      ![](https://1157917639-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7L67rzjIjPt1uSm1L4KK%2Fuploads%2FCk7oLqDqeAKh1A8ZiGj8%2Fimage.png?alt=media\&token=285e128a-6663-4f6b-87fa-8523e0e50cfd)
   2. Scheduler или планировщик решает на каком узле будет запущен процесс нового модуля от master node идет запрос в slave дергает Kublet и запускает нужный нам процесс\
      ![](https://1157917639-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7L67rzjIjPt1uSm1L4KK%2Fuploads%2FQzOzhaDFf6Dskg68RZxX%2Fimage.png?alt=media\&token=6630d1ac-2b1a-483a-be9c-d0419cb91e0c)
   3. controller manager когда модули умерают нужно перенести их когда это будет возможно. он выполняет эту роль. Отслеживает состояние кластра. Для этого он отпраляет запрос в scheduler планировку этих мертвых модулей\
      ![](https://1157917639-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7L67rzjIjPt1uSm1L4KK%2Fuploads%2F72xRO5StnIXMuDDtM6lb%2Fimage.png?alt=media\&token=f8afaebd-75c5-4813-b390-27e03fcf351e)

      <br>
   4. ETCD - хранилище ключевых значений состояние кластера (мозг кластера) каждое назначение в кластере, когда модуль назначаеться или умирает все эти значения сохраняются в ETCD. Но в нем не храняться фактические данные приложения.\
      ![](https://1157917639-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7L67rzjIjPt1uSm1L4KK%2Fuploads%2F1xHKUKdwwN4z0sj6ui6Z%2Fimage.png?alt=media\&token=319342aa-eb99-4ec6-b1a3-0abfb1cdb5c3)\
      \
      \
      Exumple Cluster Set-Up \
      2 master node требуеться меньше ресурсов \
      3 worker nodes требуеться больше ресурсов\
      \
      ![](https://1157917639-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7L67rzjIjPt1uSm1L4KK%2Fuploads%2FcWRgTnw80yzGby82zgDw%2Fimage.png?alt=media\&token=ce2273ab-0be3-4ec2-a3b0-671ece7a4936)