Basics

Буквально в прошлой заметке поднимали новый кластер куба используя инструмент 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-драйверы и прочее. Добавление/Удаление нод кластера. Обновеление кластера. Стоит сделать отступление относительно установки дополнительных компонентов, все же рекомендуют накатывать компоненты независимо от kubespray. Так как обновление или обычная замена версии компонента, может привести к проблемкам. ...

Сегодня появилась задачка настроить мониторинг внешних web-сервисов из вне инфраструктуры. Условно запускаем инстанс где-нибудь на digital ocean, и начинаем выполнять пробы (проверки) на внешний контур инфры - http, ssh и прочее. Таска достаточно простая, развернул забикс напихал туда проверок и поехали. Но хочется чего нибудь не тривиального и модного =) Вообщем пришла идея попробовать развернуть схему Blackbox Exporter + Prometheus. blackbox_exporter - экспортер позволяющий нам снимать метрики с эндпоинтов поверх протоколов http, icmp, tcp, grpc и прочего. Что касается метрик, то получаем данныe по статусу конечной точки (доступна/недоступна), время ее отклика. И самое вкусное это дата истечение ssl сертификатов. ...

Немного теории Ранее разбирались с деплойментами, запускали наши (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. ...

Если вы используйте оконное окружение i3, то вероятно у вас возникала идея подстроить поведение определенных программ под себя. Например, я хочу что бы программа Lxappearance, которую использую для кастомизации, запускалась в режиме плавающего окна, а не на весь экран. И согласно документации, реализовать эту фичу можно путем добавление директивы в файл конфигурации: $ vim $HOME/.config/i3/config --- ################ Floating apps ################### for_window [class="Lxappearance"] floating enable Отлично, но есть нюанс с которым я столкнулся в процессе. ...

Wireguard - отличное решение, если нужно быстро организовать доступ к закрытому скоупу. Вот и ко мне прилетела задача, организовать доступ к exsi через vpn. Сам хост стоит в дата центре и имеет прямой доступ. После реализации vpn-сети, вырубим доступ. (Схема vpn-сети) Я поднял небольшую виртуалку, на которой поднимем wireguard-сервер, далее на микроте (который используется как фаервол/роутер) прокинем порт к vpn серверу. Установка WireGuard Подключаемся к серверу и ставим репозитории epel и eprepo: ...

В процессе добавления на мониторинг aix серверов в zabbix, заметил что в стандартном шаблоне нету метрик собирающих данные по памяти. Сервера мониторятся через агентов, поправить это будет не сложно. Для начала напишем скриптец, который дергает нужные данные, и добавим скрипт на выполнение заббикс-агенту. Сам сниппет: #!/bin/bash totalmem=`lsattr -El sys0 -a realmem | awk {'print $2'}` usedmem=`svmon -G -O unit=KB | head -4 | tail -1 | awk {'print $3'}` freemem=`expr $totalmem - $usedmem` case $1 in "--free") echo "$freemem" ;; "--used") echo "$usedmem" ;; "--total") echo "$totalmem" ;; *) echo "Flags:" echo " --free - Free mem" echo " --used - Used mem" echo " --total - Total mem" esac В переменную totalmem, записывается результат выполнения команды (lsattr). Команда lsattr отобразит все атрибуты определенного объекта или устройства системы, в нашем случаи мы дергаем все аттрибуты устройства sys0, ключ -a отобразит определенный аттрибут, мы берем значение аттрибута - realmem. В переменную usedmem, также указывается результат выполнение команды svmon. Команда svmon, отобразит информацию о текущем состоянии памяти. В значение переменной freemem, вычесляется из переменных $totalmem и $usedmem. (Кстати говоря, эту метрику можно сделать средствами заббикса) Далее идет условный оператор case, в котором перечисляются ключи. В зависимости от ключа, будет пролистено значение одной из трех переменных. Сам скрипт можно разместить в домашнем каталоге пользователя - zabbix, обычно это - /var/lib/zabbix или /home/zabbix: ...

Ранее для доступа к нашему поду, мы через утилиту 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. И могу быть сконфигурированы полями: ...