Разбиране на Kubernetes Architecture

Нека научим подробно архитектурата на Kubernetes.


Предполагам, че имате основно разбиране за Кубернети. Ако не, вижте следните статии за въвеждане и инсталиране.

Kubernetes Въведение за начинаещи

Как да инсталирате Kubernetes на Ubuntu 18?

Kubernetes следва главно-робска архитектура. Kubernetes архитектурата има главен възел и работни възли. Има четири компонента на a главен възел.

  • Kube API сървър
  • контрольор
  • разписание
  • etcd

И, на възел на работника има три компонента.

  • kubelet
  • Kube-прокси
  • време на изпълнение на контейнера

Ето как изглежда архитектурата на Kubernetes:

kubernetes архитектура

Нека ви разкажа подробно за компонентите на главния възел и работните възли.

Главен възел

Главният възел управлява клъстера Kubernetes и той е входната точка за всички административни задачи. Можете да говорите с главния възел чрез CLI, GUI или API. За постигане на отказоустойчивост може да има повече от един главен възел в клъстера. Когато имаме повече от един главен възел, ще има режим на висока наличност и с един лидер, който изпълнява всички операции. Всички останали главни възли биха били последователите на главния възел на този лидер.

Също така, за да управлява състоянието на клъстера, Kubernetes използва etcd. Всички главни възли се свързват към etcd, който е разпределен ключ-стойност магазин.

kubernetes master възел

Нека ви обясня за всички тези компоненти един по един.

API сървър

API Server изпълнява всички административни задачи на главния възел. Потребителят изпраща останалите команди на API сървъра, който след това валидира заявките, след това ги обработва и изпълнява. etcd запазва полученото състояние на клъстера като разпределено хранилище ключ-стойност.

Scheduler

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

Управител на контролера

Непрекъсващите контролни цикли, които регулират състоянието на клъбер Kubernetes, се управляват от Управителя на контрола. Сега всеки от тези контролни вериги знае за желаното състояние на обекта, който управлява, и след това те преглеждат текущото им състояние чрез сървърите на API.

В контролния цикъл, ако желаното състояние не отговаря на текущото състояние на обекта, тогава коригиращите стъпки се предприемат от контролния цикъл, за да се приведе текущото състояние в същото като желаното състояние. Така че, мениджърът на контролера се уверява, че текущото ви състояние е същото като желаното състояние.

etcd

Etcd е разпределен ключ-стойност, който се използва за съхраняване на състоянието на клъстера. Така че, или трябва да бъде част от майстора на Kubernetes, или можете да го конфигурирате и външно. etcd се пише в goLang и се основава на Рафтов консенсус алгоритъм.

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

Може да има само един господар и всички останали майстори трябва да го следват. Освен за съхраняване на състоянието на клъстера, etcd се използва и за съхраняване на детайли за конфигурация, като подмрежите и конфигурационните карти.

Работен възел

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

И за да получите достъп до приложенията от външния свят, трябва да се свържете с работните възли, а не с главните възли.

kubernetes работник възел

Нека изследваме компонентите на работния възел.

Времетраене на контейнера

Времето за изпълнение на контейнера се използва основно за изпълнение и управление на непрекъснат жизнен цикъл на работния възел. Някои примери за време на изпълнение на контейнерите, които мога да ви дам, са контейнерите rkt, lxc и т.н. Често се забелязва, че Docker се нарича също и време за изпълнение на контейнера, но за да бъдем точни, нека ви кажа, че docker е платформа, която използва контейнери като време на изпълнение на контейнера.

Kubelet

Kubelet е основно агент, който работи на всеки работен възел и комуникира с главния възел. Така че, ако имате десет работни възела, тогава kubelet работи на всеки работен възел. Той получава дефиницията на шушулката по различни начини и изпълнява контейнерите, свързани с този порт. Той също така гарантира, че контейнерите, които са част от шушулките, винаги са здрави.

Kubelet се свързва към време на изпълнение на контейнера с помощта на gRPC рамка. Kubelet се свързва към интерфейса за изпълнение на контейнера (CRI) за извършване на контейнери и операции с изображение. Услугата за изображения отговаря за всички операции, свързани с изображението, докато услугата по време на изпълнение е отговорна за всички операции, свързани с шушулки и контейнери. Тези две услуги трябва да изпълняват две различни операции.

Нека ви кажа нещо интересно, време за изпълнение на контейнерите, което се твърдо кодира в Kubernetes, но с развитието на CRI, Kubernetes вече могат да използват различни времена на изпълнение на контейнерите, без да е необходимо да прекомпилират. Така че, всяко изпълнение на контейнера, което реализира CRI, може да се използва от Kubernetes за управление на шушулки, контейнери и изображения на контейнери. Docker shim и CRI контейнери са два примера за CRI shim. С помощта на докер шим, контейнерите се създават с помощта на докер, инсталиран на работните възли и след това вътрешно докер използва контейнер за създаване и управление на контейнери

Kube-прокси

Kube-proxy работи на всеки работен възел като мрежов прокси. Той слуша API сървъра за всяко създаване или изтриване на сервизна точка. За всяка сервизна точка kube-proxy задава маршрутите, така че да може да стигне до нея.

заключение

Надявам се това да ви помогне да разберете по-добре архитектурата на Kubernetes. Кубернетичните умения са винаги по заявка и ако търсите да се научите да изграждате кариерата, проверете това Удеми курс.

ЕТИКЕТИ:

  • докер

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map