k8s

Буквально в прошлой заметке поднимали новый кластер куба используя инструмент kubespray. Сегодня же проработаем задачу постоянных томов для этого кластера. Напомню, что это было три виртуалки, размещенные на vmware инфраструктуре. И сразу же появилась идея провижинить постоянные тома в vSphere, у которой начиная с версии vSphere 6.7 (Update3) стала доступна поддержка Cloud Native Storage (CNS). Немного теории Cloud Native Storage (CNS) - это некая прослойка между vSphere и K8s, которая дает нам возможности для создания и управления постоянными томами в экосистеме vSphere....

В этой заметке развернем кластер куба используя инструмент - kubespray. Если вы уже читали про методы установки кластера, то косвенно знакомы с kubespray. Вкратце это сборник ansible-плэйбуков и ролей, дающий нам возможности: Основное это установка кластера k8s, установка как актуальной версии, так у более старой версии кластера, Установка контейнерного runtime (Docker, Cri-o, Containerd), Установка сетевых решений (Calico, Flannel), Установка и настройка кластера etcd, Возможность установки дополнительных компонентов - это DNS, Ingress-контроллеры, Cert-менеджеры, Storage-драйверы и прочее....

Немного теории Ранее разбирались с деплойментами, запускали наши (stateless) приложения и демонстрировали фишки self-healing в кубернетес. В рамках этого топика разберемся томами (volumes), поймем как мы может запускать приложения с сохранением состояния. В кубернетес есть несколько разновидностей типов томов. Некоторые из типов являются универсальными и подходят для локального хранения данных, какие-то могут быть приспособлены для специфичных задач. Один pod может использовать одновременно несколько типов томов. Тип volume может быть: emptyDir - пустой каталог, который может использоваться для хранения временных файлов....

Ingress В прошлой заметке разбирались и запускали сервисы. Как отмечалось, объект сервис на практике применим только для работы внутри кластера. Но также нам нечего не мешает опубликовать наше приложения используя тип сервиса - NodePort. Эта схема будет работать и считается самой простой, но за ней могут стоять большие проблемы. Во первых каждый такой сервис публикует свой порт наружу. В случаи, если у нас какой то публичный кластер не в закрытом сетевом контуре это проблема....

Ранее для доступа к нашему поду, мы через утилиту kubectl реализовывали проброс портов во внутрь пода. Эта история хоть и работает, но вообще не годиться для ежедневной эксплуатации. Так как состояние пода эфемерно, то есть под может сломаться или перезапуститься, изчезнуть или появиться на другой ноде. Соответствено, kubernetes назначает поду новый ip, и клиенты нашего приложения даже не догадываются об изменениях. В дополнение у нашего приложения может быть несколько его реплик....