Самият Kubernetes не е готова за работа платформа – той е рамка, в която потребителите могат да изградят своя собствена платформа. Обикновено потребителите трябва да интегрират множество продукти и услуги, за да осигурят пълна функционалност. Типовете продукти и услуги, които се добавят към Kubernetes, дават представа за мащаба на процеса: съхранение на данни (AWS, Ceph); инструменти за внедряване (Terraform); контейнери и шаблони/регистрация на услуги (Docker, Rancher, Helm, JFrog); логване/метрики (Grafana, Prometheus); инструменти за разработка на CI/CD конвейери (Jenkins, GitLab CI/CD или Tekton); балансиране на натоварването (NetScaler).
Защо е необходим Kubernetes?
Контейнерите, например реализирани чрез Docker, са добър начин за пакетиране и стартиране на приложения. В производствена (production) среда трябва да управлявате контейнерите, които изпълняват приложенията, и да гарантирате, че няма прекъсвания (downtime). Например, ако един контейнер спре, трябва да се стартира друг, който да поеме неговата функция. Именно тук се намесва Kubernetes.
Kubernetes предоставя рамка за устойчиво управление на разпределени системи. Той се грижи за мащабирането и устойчивостта при отказ (failover) на вашето приложение, предоставя модели за внедряване и други
Някои от ключовите възможности, които потребителите обикновено внедряват чрез Kubernetes, са:
- Откриване на услуги и балансиране на натоварването (Service discovery and load balancing): Kubernetes може да експонира DNS име и да балансира/разпределя мрежовия трафик между множество възли, за да поддържа стабилността на внедряването.
- Оркестрация на съхранението (Storage orchestration): С Kubernetes можете автоматично да монтирате всяка система за съхранение по Ваш избор.
- Автоматизирани актуализации и връщане на версии (Automated rollouts and rollbacks): Можете да опишете желаното състояние на Вашите контейнери чрез Kubernetes и той може да промени текущото състояние до желаното с контролирано темпо.
- Автоматично разпределение (Automatic bin packing): Предоставяте на Kubernetes клъстер от възли, които той използва за изпълнение на контейнеризирани задачи. Указвате колко CPU и памет (RAM) са нужни на всеки контейнер, а Kubernetes ги разпределя по възлите така, че да използва ресурсите най-ефективно.
- Самовъзстановяване (Self-healing): Kubernetes рестартира дефектирали контейнери, заменя ги, спира контейнери, които не отговарят на проверките за изправност (health checks), и т.н.
Кои са ключовите концепции и компоненти на Kubernetes?
Около фундаменталните концепции и компоненти в Kubernetes съществува богата номенклатура и терминология. Ето някои основни термини за разбиране на архитектурата и работата на една Kubernetes среда:
- Kubernetes Cluster (Клъстер): Набор от възли (nodes), които изпълняват контейнеризирани приложения. Контейнеризацията пакетира приложението заедно с неговите зависимости и необходими услуги. Контейнерите са по-леки и гъвкави от виртуалните машини.
- Pod (Под): Най-малките единици за изчислителна мощ, които могат да бъдат създавани и управлявани в Kubernetes. Pod е група от един или повече контейнера със споделени ресурси за съхранение и мрежа, както и спецификация за начина им на работа. Съдържанието на един Pod винаги се разполага и планира заедно.
среда за изпълнение на контейнери (container runtime) и kube-proxy. Всеки възел се управлява от контролния панел (control plane) и съдържа услугите, необходими за работата на Pod-овете.
- Container Image (Контейнерен образ): Готов за стартиране софтуерен пакет, съдържащ всичко необходимо за работата на едно приложение: код, среда за изпълнение, системни библиотеки и настройки по подразбиране.
- Container Runtime: Софтуерът, отговорен за изпълнението на контейнерите. Kubernetes поддържа среди като containerd, CRI-O и др.
- DaemonSet: Гарантира, че всички възли изпълняват копие на даден Pod. Когато се добавят нови възли към клъстера, към тях се добавят и съответните Pod-ове. При премахване на възли, тези Pod-ове се почистват автоматично.
- Namespace (Пространство от имена): Механизъм за изолиране на групи ресурси в рамките на един клъстер. Имената на ресурсите трябва да бъдат уникални в рамките на едно пространство.
- Control Plane (Контролен панел): „Мозъкът“ на Kubernetes клъстера. Той управлява общото състояние, оркестрира планирането и внедряването на подове и следи тяхното здраве. Включва компоненти като API сървър, scheduler и controller manager.
- ReplicaSet: Гарантира, че определен брой копия (реплики) на даден Pod работят по всяко време. Помага за поддържане на желаното ниво на наличност и мащабируемост.
- Deployment: Абстракция от по-високо ниво, която управлява жизнения цикъл на подовете и ReplicaSet-овете. Позволява декларативни актуализации, плавни превключвания (rolling updates), връщане на версии и мащабиране.
- Service (Услуга): Абстракция, която дефинира логически набор от подове и политика за достъп до тях. Осигурява стабилна мрежова точка (endpoint) за достъп и позволява балансиране на натоварването.
-
Ingress: API обект, който управлява външния достъп до услугите в клъстера. Осигурява маршрутизация на входящия трафик, правила за балансиране и SSL терминиране (обикновено чрез HTTP/HTTPS).
Как се внедрява Kubernetes?
Въпреки че Kubernetes може да бъде внедрен локално (on-premises) или в облака от самите потребители, става все по-популярно използването на управлявани услуги (managed services) или корпоративни продукти. Те надграждат базовия Kubernetes и премахват необходимостта от тромавата интеграция и поддръжка.
Например, с Amazon EKS, потребителите могат да създадат клъстер чрез конзолата на AWS, CLI или API. EKS поема инфраструктурата, настройките на контролния панел, мащабирането и актуализациите. Потребителите внедряват приложенията си чрез Kubernetes манифести или образи от Amazon Elastic Container Registry (ECR).
Azure AKS предлага подобна услуга в платформата на Microsoft Azure, като поема управлението на главните възли (master nodes) и интеграцията с други услуги на Azure. Приложенията се внедряват чрез манифести или образи от Azure Container Registry (ACR).
Red Hat OpenShift е корпоративно поддържана дистрибуция, която предоставя допълнителни функции върху Kubernetes. Може да се внедри локално, в публични облаци или в хибридни среди. OpenShift предлага вграден регистър за контейнери, мониторинг и инструменти за разработчици, предоставяйки цялостна платформа за управление.
Във всеки от случаите процесът включва настройка на клъстера, конфигуриране на мрежата и сигурността и внедряване на приложенията (често чрез Docker). Управляваните услуги се грижат за високата наличност, мащабирането и поддръжката (кръпки за сигурност и актуализации на версиите), позволявайки на потребителите да се фокусират върху своя софтуер.
Защо е важен мониторингът на Kubernetes?
В днешния технологичен пейзаж Kubernetes играе жизненоважна роля. В момента той е един от най-широко използваните и известни DevOps инструменти, прилаган екстензивно от организации от всякакъв мащаб – от стартъпи до големи предприятия. Големите компании често разполагат с множество Kubernetes клъстери, разпръснати в различни облачни среди или хибридни облаци (комбинация от локална инфраструктура и един или повече облачни доставчици).
Въпреки че Kubernetes решава много съществуващи ИТ проблеми, той идва със своя собствена сложност. Когато трябва да се грижите за множество клъстери, тази сложност нараства. Ето защо ефективният мониторинг на тези среди е критичен. Ако пренебрегнете внедряването на проактивен мониторинг и оставите вашата Kubernetes среда ненаблюдавана, ще научавате за проблемите едва след като те вече са възникнали.
Кои са ключовите метрики за мониторинг на Kubernetes?
- Използване на CPU и памет на клъстера: Това ви позволява да вземате решения дали да добавите още ресурси към съществуващ възел или да коригирате заявките (requests) и лимитите (limits) за подовете.
- Събития CrashLoopBackOff: Статусът CrashLoopBackOff означава, че даден под се стартира, срива се, стартира се отново и пак се срива – това прави всяко зависимо приложение нестабилно.
- Грешки при Persistent Volumes: Kubernetes поддържа работни натоварвания със състояние (stateful) чрез използване на Persistent Volumes. Базите данни и подобни приложения обикновено разчитат на наличността на тези обеми за съхранение.
- Проблеми с Horizontal Pod AutoScaler (HPA): HPA позволява автоматично мащабиране на броя на подовете въз основа на целеви стойности (например CPU натоварване). За да зададете подходяща цел, трябва да наблюдавате производителността и поведението на приложението.
- Състояние на възлите (Node Conditions): Здравето на възела се определя от няколко метрики като CPU, памет, мрежа, диск, капацитет за подове и др.
- Събития на възлите (Node Events): Контейнерът може да не се стартира поради проблеми с възела (например „Out of Memory“). Мониторингът на тези събития помага за откриването на множество дефекти.
- Проблеми при внедряването (Deployment Issues): Внедряването включва управление на жизнения цикъл на подовете, включително надграждането им. Ако броят на наличните подове е по-малък от желания в продължение на няколко минути, внедряването се счита за „нездравословно“.
- Подове със статус Pending: Ако подът е в статус „Pending“, той не може да бъде разпределен към възел. Важно е да се диагностицират причините за това състояние.
- Проблеми с DaemonSet: Администраторът трябва да следи дали броят на наличните и работещите DaemonSets съвпада. Несъответствието означава, че един или повече от тях са се провалили.
- Здраве на клъстера (Cluster Health Conditions): Следете дали някой от възлите изпитва недостиг на ресурси: Disk Pressure (диск), Memory Pressure(памет), PID Pressure (твърде много процеси) или Network Pressure (мрежа).
- Проследяване на контейнерни образи: Контейнерите могат да не стартират, ако необходимите образи липсват в хранилището или да работят некоректно, ако е изтеглен остарял образ.
- Мониторинг на Control Plane: Контролният панел съдържа критични услуги като etcd, scheduler, controller-manager и API server, които задължително трябва да бъдат наблюдавани.
- Мониторинг на ресурсите на подовете: Важно е да се следят лимитите и консумацията на CPU и памет за всеки контейнер в пода, за да се избегнат OOM (Out of Memory) и други подобни грешки.
- Типове услуги (Service Types): Компонентът Service управлява балансирането на натоварването. Добра практика е да се одитира типът услуга, присвоен на пода, за да се намалят рисковете за сигурността.
- Мониторинг на Garbage Collection (GC): Ако процесът по почистване на паметта (GC) не работи оптимално, производителността на възлите може да се влоши значително.
