K8s

Немного теории Ранее разбирались с деплойментами, запускали наши (stateless) приложения и демонстрировали фишки self-healing в кубернетес. В рамках этого топика разберемся томами (volumes), поймем как мы может запускать приложения с сохранением состояния. В кубернетес есть несколько разновидностей типов томов. Некоторые из типов являются универсальными и подходят для локального хранения данных, какие-то могут быть приспособлены для специфичных задач. Один pod может использовать одновременно несколько типов томов. Тип volume может быть: emptyDir - пустой каталог, который может использоваться для хранения временных файлов. Время жизни этого тома тесно связанно с жизнью пода. Все данные теряются после сметри пода. hostPath - этот тип используется для монтирование каталогов из файловой системы самого хоста. Данные остаются, после завершения цикла жизни пода и могут быть переиспользованы другим подом. gitRepo - том, который инициализируется при проверке содержимого git-репозитория. nfs - общий nfs ресурс, монтируемый в под. local - локальные смонтированные устройства на узлах. cephfs, glusterfs, rdb, vsphereVolume - тип используемый, для монтирования сетевых файловых хранилищ. confingMap, secret - специальны тип, используемый для предоставления поду определенных ресурсов kubernetes. persistentVolume, persistentVolumeClaim - способ использования заранее и динамически резервируемые постоянные хранилища. В рамках этой записи упор будет на постоянных томах и дополнительных абстракциях вокруг постоянных томов. Название типа - PV (PersistentVolume) постоянные тома, обусловлено способу хранение данных, то есть хранилище не привязывается сроку жизни пода. Данные не теряются, если pod умрет, перезапустится или запуститься на другой ноде. Существует многожество реализации постоянных томов, например: nfs, glusterfs, cephfs, fc, iscsi, googleDisk. ...

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

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

ConfigMap В kubernetes есть объект ConfigMap, который хранит конфигурации для других объектов куба. ConfigMap может быть использован в случаях, когда мы хотим: Во внутрь контейнера прокинуть файл с конфигурацией для нашего приложения, через read-only volume; Добавить переменные окружения во внутрь контейнера; Передать в контейнер агрументы командной строки. Мы можем хранить любую информацию в манифесте конфигмапы (кроме паролей и etc..), в кластере создаем новый configmap-объект и описываем его конфигурацию, в поле data. Далее включаем объект в деплоймент, поле template: -> containers:. При запуске пода, кубернетес примонтирует конфигмап как volume. ...

В этом посте хотелось бы поделиться заметками относительно использования Probe в кубернетес. И предоставить понимание того, на чем строиться ресурс менеджмент - реквесты и лимиты, QoS-классы. Probes В kubernetes реализован механизм проверки доступности нашего приложения. Существую 3 типа проверок: Liveness Probe - выполняет контроль за состоянием приложения в процессе его жизни. Liveness проверки выполняются постоянно. В случаи, если выполнение liveness пробы завершилось с результатом - failed, то kubernetes перезапустил приложение (под). Readiness Probe - выполняют проверки за состоянием контейнеров, для того что бы понять готов ли под принимать клиентский трафик. В случаи неудачного выполнения readiness проды, приложение убирается из балансировки. Так же как и с liveness, readiness пробы выполняются постоянно, с некой переодичностью. Startup Probe - с помошью startup пробы мы можем проверить, что наше приложение действительно проинициализировалось и готово принимать принимать запросы. Startup проба выполняется только до последнего успешного выполнения, после чего разблокирует выполнение других проб (liveness и readiness). Такой механизм может быть полезен, когда наш контейнер долго запускается, и чтобы избежать преждевременного убийства контейнера другими пробами они блокируются. Теперь напишем деплоймент, и будем разбираться с настройками проб. apiVersion: apps/v1 kind: Deployment metadata: name: deployment-with-probes spec: replicas: 2 selector: matchLabels: app: my-app strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate template: metadata: labels: app: my-app spec: containers: - image: nginx:1.12 name: nginx-web ports: - containerPort: 80 readinessProbe: failureThreshold: 3 httpGet: path: / port: 80 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 livenessProbe: failureThreshold: 3 httpGet: path: / port: 80 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 initialDelaySeconds: 10 startupProbe: httpGet: path: / port: 80 failureThreshold: 30 periodSeconds: 10 Пробы указываются в контексте - containers. И могу быть сконфигурированы полями: ...