Принес вам интересное от компании Флант

https://habr.com/ru/companies/flant/articles/877608/

Получение SSL сертификата для нашего приложения в k8s с помощью cert-manager

И так. У нас есть задеплоенное в dev кластер куба приложение. Мы хотим его вывесить наружу и получить для него SSL сертификат.

Давайте приступим:

1. Устанавливаем в кластер компонент cert-manager:

В инфраструктурном репозитории, в каталоге cluster, переименовываем 04-app.yaml в 06-app.yaml
Добавляем в этот же каталог kustomization для cert-manager, он будет устанавливаться после ingress-nginx
В components создаем каталог cert-manager и добавляем туда namespace.yaml и hr-cert-manager.yaml

2. Теперь нам нужно создать такую сущность как ClusterIssuer, чтобы выпускать сертификаты с помощью Lets Encrypt

Добавим в каталог cluster kustomization
В components создадим каталог letsencrypt и добавим туда issuer.yaml
ВАЖНО! Для тестов и во избежание временной блокировки со стороны lets encrypt в параметре server: сначала лучше указать https://acme-staging-v02.api.letsencrypt.org/directory
Когда сертификат будет успешно получен - можно заменить обратно на значение, которое приведено в issuer.yaml

3. В файле 06-app.yaml меняем зависимость c ingress-nginx на letsencrypt

4. Создаем файл cert.yaml в components/app-example. Это наш сертификат, который будет получен от Lets Encrypt. Он будет сохранен в k8s secret под названием app-example-tls

5. Пушим всё в репозиторий, отслеживаем статус через flux get all -A. Когда все пройдет успешно - проверим, что сертификат создан:
kubectl get secret -n app-example

Вы должны увидеть следующую строку:

NAME            TYPE              DATA   AGE
app-example-tls kubernetes.io/tls 2      5m6s

6. Осталось только поправить ingress.yaml и values.yaml в helm чарте нашего приложения. Смотрите коммит

Пушим в репозиторий приложения, дожидаемся деплоя и проверяем.
Теперь приложение должно открываться по адресу https://app-example.example.com и иметь действительный сертификат!

В след. посте начнем подключать БД к нашему приложению и устанавливать в кластер PostgreSQL (На тестовых средах это нормально. В проде не рекомендую дежрать БД в кластере)

Добавляем в кластер поддержку хранения данных с помощью local-path-provisioner

Для нашего тестового приложения в dev кластере нам потребовалась БД.

Так как кластер тестовый - мы можем разместить СУБД прямо в кластере, а не где-то на серверах снаружи.

Чтобы СУБД было где хранить данные - мы сегодня займемся добавлением персистентного хранилища в наш кластер.

В кубе за хранение данных отвечают такие сущности как Storage Class, Persistent Volume и Persistent Volume Claim.

Также есть различный софт, который интегрирует разные системы хранения с вышеуказанными сущностями куба.

Мы воспользуемся одним из самых простых - local-path-provisioner. Данный софт просто создает папку на локальном диске, подключенном к ноде кластера и пишет данные туда. Не поддерживает ограничение размера запрошенного Persistent Volume, не умеет переевозить PV с ноды на ноду, но в тестовом кластере нам это не нужно.

Давайте приступать:

1. В каталоге cluster снова переименуем 06-app.yaml в 07-app.yaml и поменяем там зависимость с letsencrypt на local-path-provisioner
2. Добавим файл 06-local-path-provisioner.yaml в каталог cluster
3. Внесем необходимые изменения в файл kustomization.yaml
4. В components создадим папку local-path-provisioner и добавим туда namespace.yaml
5. Создадим Helm Release для local-path-provisioner.

Тут есть одна хитрость. Helm chart лежит не где-то в репозитории чартов, а прямо в репозитории с исходным кодом.
Но это не проблема. FluxCD позволяет установить чарт в кластер и в этом случае. В документации описано как можно провернуть данную затею.

Создаем GitRepository и указываем, что Flux должен игнорировать все, кроме указанной папки в git репозитории.

В Helm Release ссылаемся на наш git репозиторий и указываем путь, где искать чарт.

6. Пушим все в репозиторий, дожидаемся синхронизации и проверяем, что все прошло успешно:

Выполняем kubectl get storageclass

Должен появиться storage class с именем local-path

Вот и всё! В следующем посте установим PostgreSQL в кластер и подключим базу к нашему приложению

Stay tuned!

Deptrac внезапно сменил репозиторий

Сегодня утром обнаружил, что инструмент deptrac внезапно и без каких-либо объявлений сменил репозиторий с https://github.com/qossmic/deptrac на https://github.com/deptrac/deptrac/

Насколько я понял репозиторий мигрировал целиком и скорее всего все хорошо. Но будьте бдительны, возможно это вредоносная активность.
На packagist пакет пока находится по старому имени, но устанавливается из нового репа.

Как разберусь с ситуацией подробнее - напишу

Deptrac в порядке

Я создал issue для того, чтобы разобраться в ситуации.
Еще один представитель организации qossmic (не связанный с тем, что осуществил перенос репозитория) ответил, что у компании ребрендинг и они решили выделить deptrac в отдельную организацию.

Полагаю, что злонамеренных действий тут нет. У Qossmic действительно сейчас ребрендинг и их старый сайт ведет на сайт, который указан в комментарии к моему issue.

Ждем пока появится на packagist как deptrac/deptrac и можно обновляться

Чат канала

Раз уж я сегодня разразился постами - у меня есть еще один)

У нас есть чат канала - https://t.me/AppliedTryndology

Изначально он создавался для комментариев, но нас уже достаточно много - добавляйтесь. Будем общаться в более свободной форме

Flux CD - wait: true

Я тут весь в делах и переделке домашней инфраструктуры, поэтому пост про Postgres в кластере немного буксует.
Но я решил сегодня с вами поделиться еще одним маленьким лайфхаком.

Тут я писал как правильно определить порядок применения манифестов в кластере. Но я обнаружил, что некоторые манифесты начинают применяться до того, как предыдущий шаг выполнен. Чтобы заставить Flux вести себя как подобает, мы добавим еще одну опцию:

wait: true

Это заставляет Flux начинать применять следующий манифест только тогда, когда все ресурсы предыдущего шага прошли healthcheck проверки.

Смотрите коммит.

Stay tuned!

Устанавливаем Postgres в кластер

Storage в кластере мы настроили. Пришла пора установить Postgres.
Делать мы это будем с помощью проекта cloudnative-pg. Давайте приступим:

1. В каталоге cluster переименовываем 07-app.yaml в 10-app.yaml
2. Добавляем 07-app-example-namespace.yaml. В каталоге components создаем app-example-namespace, туда переносим файл namespace.yaml из app-example. Это нужно для того, чтобы установить наш экземпляр postgres в namespace приложения. Поэтому мы отдельным шагом сначала создаем namespace
3. Добавляем в каталог cluster файл 08-postgres-operator.yaml. Создаем в components каталог postgres-operator. Там будет два традиционных файла для установки оператора через helm - namespace.yaml и hr-cnpg-operator.yaml. Операторы в кубе - это специальный софт, который добавляет в кластер свои кастомные ресурсы, с помощью которых можно конфигурировать и создавать то, чем оператор управляет. В нашем случае - это postgres. Подробнее про операторы можно почитать тут и тут
4. Добавляем в каталог cluster 09-postgres.yaml. Создаем в components каталог postgres. Там будет лежать единственный файл с настройками нашего инстанса СУБД - postgres.yaml. Здесь мы указываем, что хотим 1 инстанс, указываем какой storageClass нужно использовать для хранения данных - local-path. Его мы добавляли в этом посте. И указываем объем места, который будет использоваться для нашей БД.
5. Вносим изменения в kustomization.yaml
6. Пушим все в наш инфраструктурный репозиторий и отслеживаем статус через flux get all -A

Проверяем, что БД успешно создалась, вводим kubectl get po -n app-example. Должен появиться под с именем app-example-db-1. Это инстанс нашей СУБД.
Данные для подключения автоматически сгенерировались и хранятся в секрете с именем app-example-db-app.

Мы молодцы! База у нас теперь есть. В следующем посте будем подключать ее к приложению.

Stay tuned!

Подключаем БД в приложение

Постгрес у нас есть. Теперь давайте его состыкуем с нашим приложением.

1. Добавляем базу в приложение и делаем api эндпоинт, перейдя по которому мы увидим текст, полученный из БД. Я приведу здесь весь коммит, но его можно не изучать целиком. Важные моменты с инфраструктурной точки зрения:

- Добавляются ENV переменные, необходимые для подключения к БД

- В Dockerfile в секцию CMD добавляем запуск миграций, перед тем как запустить RoadRunner. Для dev среды такой подход оправдан, так как у нас одна реплика приложения. Этот момент исправим, когда будем делать prod кластер

2. Осталось передать реальные ENV переменные, которые будут прокинуты в контейнер при запуске приложения в кластере:

Поправим helm chart приложения. Нам нужен файл deployment.yaml. В раздел containers добавляем секцию env

env:
  - name: APP_ENV
    value: prod
  - name: DB_NAME
    valueFrom:
      secretKeyRef:
        name: app-example-db-app
        key: dbname
  - name: DB_USER
    valueFrom:
      secretKeyRef:
        name: app-example-db-app
        key: user
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-example-db-app
        key: password
  - name: DB_HOST
    valueFrom:
      secretKeyRef:
        name: app-example-db-app
        key: host

Переменная APP_ENV передается напрямую, а вот данные для подключения к базе берутся из k8s секрета app-example-db-app. Таким образом наше приложение подключается к готовой базе и мы даже не знаем с какими доступами, так как секрет сгенерировался автоматически при создании экземпляра БД.

Пушим в репо, приложение собирается и деплоится в кластер. Переходим по адресу https://app-example.example.com/api/v1/get-string-from-db и получаем json из картинки к посту.

В dev кластере нам осталось добавить сбор логов и минимальный мониторинг.

Не переключайтесь :)

Heredoc в Dockerfile. Важное дополнение

В июле прошлого года я написал пост о возможности избавиться от && в Dockerfile и писать красиво с помощью Heredoc синтаксиса.
С тех пор везде продвигал этот метод.
На Пыхапе, во время выступления на открытом микрофоне, меня спросили:

А разве в этом случае сборка будет останавливаться при возникновении ошибки?

С уверенностью сказал, что да, будет. С этим нет никаких проблем.

Однако вчера, во время отладки одной сборки, я обнаружил, что это не всегда так.

Допустим у нас есть такой блок

RUN <<EOF
    apt-get update
    apt-get install --no-install-recommends -y \
        openssh-client \
        rsync \
        non-existent-package
    apt-get clean
EOF

Сборка в этом случае не прервется, хотя non-existent-package в репозитории не найден и на этом блоке мы должны упасть.

Чтобы это поправить, достаточно в такой многострочный RUN добавлять set -e. Это заставит скрипт немедленно прерваться при возникновении ошибки.

Правильный вариант:

RUN <<EOF
    set -e
    apt-get update
    apt-get install --no-install-recommends -y \
        openssh-client \
        rsync \
        non-existent-package
    apt-get clean
EOF

Раньше я этого не замечал, потому что копипастил из своих докерфайлов, где уже был set -xe.

Будьте внимательны, всем отличных выходных и стабильных сборок!

Сегодня будет крутой эфир про Talos Linux. Это дистрибутив, специально заточенный под k8s. Я буду о нем рассказывать, когда перейдем к prod кластеру. Ну а пока присоединяйтесь вечером к просмотру! https://www.youtube.com/watch?v=liso5CNn4G4

k9s

Что-то у меня не хватило на этой неделе сил на полноценный пост, поэтому сегодня делюсь с вами прикольной утилитой - k9s.
На стриме в прошлом году Павел Бучнев из фартанов мне ее посоветовал и у меня наконец дошли руки попробовать.

Штука очень прикольная. Это как Midnight Commander, но для кубов. Можно провалиться в каждый под, посмотреть логи, потребляемые ресурсы (Для этого в кластере должен быть установлен metrics server), describe пода и другое. Присутствует удобное переключение между namespace. На сайте проекта можно посмотреть демки и подробнее ознакомиться с инструментом.

Enjoy!

Добавляем Grafana Loki в кластер

Сегодня будем добавлять в кластер подсистему логирования. Я уже несколько лет использую стэк Loki + Promtail + Grafana. Рассмотрим первый кусочек этого стэка - Loki

Приступим:

1. Добавляем в наш инфраструктурный репозиторий файл 11-loki.yaml

В нем, как и в 10-app-example.yaml, мы указываем, что sops должен расшифровывать наши секреты

2. Прописываем loki в kustomization.yaml

3. Создаем каталог loki в components

4. Первым файлом в нем будет традиционный namespace.yaml

5. Вторым файлом будет секрет, в котором будут храниться данные для подключения к S3 хранилищу. Именно в S3 мы будем хранить логи.

В Dev среде я использую minio в качестве S3 Object Storage.
В minio создаем учетные данные для подключения loki и три бакета - loki-dev-admin, loki-dev-chunks и loki-dev-ruler.
Создаем файл секрета следующего содержания:

apiVersion: v1
kind: Secret
metadata:
  name: loki-envs
  namespace: loki
stringData:
  S3_LOKI_ENDPOINT: "s3.example.com"
  S3_LOKI_DSN: "https://ваш-access-key:ваш-secret-key@s3.example.com."
  S3_LOKI_REGION: "local"
  S3_LOKI_SECRET_ACCESS_KEY: "ваш-secret-key"
  S3_LOKI_ACCESS_KEY_ID: "ваш-access-key"
  S3_LOKI_INSECURE: "false"

Шифруем его с помощью sops: sops --encrypt --encrypted-regex '^(data|stringData)$' --pgp 'B1B740FC8FCA25D9BE0C118CED0FB16FAF7A8471' --in-place s3-secret.yaml

6. Ну и наконец третий файл - hr-loki.yaml

Мы будем деплоить loki в режиме SingleBinary, когда все компоненты собраны в одном бинарном файле.
Для dev среды этого более чем достаточно, так как отказоустойчивость и разделение на чтение/запись нам тут не нужны.
Подробнее о режимах loki можно почитать в официальной документации.

Из важного в конфиге:

- В данной секции мы говорим loki, чтобы он брал настройки из env переменных, содержащихся в ранее созданном секрете:

      extraArgs:
        - -config.expand-env=true
      extraEnvFrom:
        - secretRef:
            name: loki-envs

- Обязательно задаем requests and limits для каждого контейнера. Умолчания в helm чарте loki не позволяют нам запуститься с имеющимися у нас ресурсами и они скорее подходят для prod конфигуарции. В dev режиме loki потребляет значительно меньше, поэтому я снизил запросы и лимиты до разумных пределов.

- Далее идет конфиг самого loki. Здесь указываем из каких переменных мы должны брать настройки для подключения к S3 и тюним некоторые параметры. При тюнинге я руководствовался этой статьей. Она уже устарела, но некоторые вещи из нее все еще можно почерпнуть

- Срок хранения логов устанавливаем в 7 дней

Пушим всё в репозиторий, дожидаемся применения. Если все прошло успешно, увидим следующие запущенные поды:

loki-0
loki-canary-vmtvs
loki-chunks-cache-0
loki-gateway-f5b6b9dd8-xzlds
loki-results-cache-0

Первый кирпичик в нашей системе логирования готов! В след. посте будем настраивать отправку логов кластера в loki, не переключайтесь!

Полезное от Сергея Предводителева. Я не знал некоторых вещей

Promtail - отправляем логи в loki

Loki у нас в кластере теперь есть, пришла пора туда что-нибудь отправить. Для этого мы будем использовать инструмент promtail. В нашем стэке он отвечает за сбор логов со всех подов кластера и отправку их в loki

Приступим:

С этого поста и дальше я не буду описывать в каких директориях создаются файлы, вы уже наверняка сами знаете где :) А если забыли - можно посмотреть в предыдущих постах или в репозитории на гитхабе

1. Создаем файл 12-promtail.yaml, установка promtail будет идти после установки loki
2. Прописываем его в kustomization.yaml
3. И создаем hr-promtail.yaml. Там указываем запросы и лимиты для подов promtail и указываем ему, что логи нужно писать в формате json

namespace мы тут не создаем, так как поды promtail будут запускаться в неймспейсе loki

Пушим в репозиторий, убеждаемся, что поды корректно создались. Мы должны увидеть два пода, по одному на каждую ноду в кластере. Этот режим запуска в k8s называется daemonset

Вот так просто мы добавили отправку логов! В след. посте установим графану и наконец-то сможем посмотреть на логи, которые прилетают к нам от подов

Stay tuned!

Немного запоздало, но сегодня продолжение прошлого стрима по Talos Linux. Практическая часть. Можно посмотреть как все работает в лайв-демо. Сам смотрю не сначала. Буду в записи смотреть после окончания стрима

https://www.youtube.com/watch?v=tw7rg5MazcQ

Заменяем promtail на fluentbit

Под постом про отправку логов @gam6itko подметил, что promtail объявлен как deprecated и завершит свою жизнь в 26 году

Сама графана предлагает как замену использовать ее продукт alloy. Я пощупал и мне не понравилось

Во-первых это комбайн, он занимается не только отправкой логов, во-вторых кушает больше ресурсов

Поэтому мы будем менять promtail на fluentbit. Он легковесный и прекрасно справляется со своей задачей

Присупим:

1. Переименовываем 12-promtail.yaml в 12-fluentbit.yaml. Там меняем название kustomization и путь до компонента

2. Не забываем переименовать также и в kustomization.yaml

3. Переименовываем директорию promtail в fluentbit в components

4. Добавляем туда hr-fluentbit.yaml. Здесь есть несколько важных моментов:

- Мы должны указать кубу, чтобы поды fluentbit могли запускаться на master ноде кластера. Делается это указанием следующих tolerations:

tolerations:
  - key: node-role.kubernetes.io/master
    operator: Exists
    effect: NoSchedule
  - key: node-role.kubernetes.io/control-plane
    operator: Exists
    effect: NoSchedule

- Указываем fluentbit'у, что он должен писать логи в loki. Настраиваем labels, чтобы было удобнее потом смотреть логи по конкретным namespace, pod и так далее:

[OUTPUT]
    Name loki
    Match *
    Host loki.loki.svc
    Port 3100
    Retry_Limit False
    Labels namespace=$kubernetes['namespace_name'], node=$kubernetes['host'], pod=$kubernetes['pod_name'], container=$kubernetes['container_name'] 
    Auto_kubernetes_labels On

5. Пушим всё в инфраструктурный репозиторий. Проверяем, что создалось 2 пода - на мастере и на воркер ноде

Готово! Всегда пользуйтесь актуальными и поддерживаемыми продуктами ;)

Добавляем grafana в кластер

Мы добавили loki для хранения логов, fluentbit для отправки логов в loki. Теперь пришел черед добавить графану, чтобы логи можно было смотреть

Давайте приступать:

1. Добавляем файл 13-grafana.yaml. Указываем, что устанавливать будем после fluentbit и добавляем раздел decryption, так как нам потребуются секреты

2. Прописываем графану в kustomization.yaml

3. В компонентах создаем namespace.yaml

4. Добавляем cert.yaml. Он нам понадобится для защищенного доступа к графане через ingress

5. Создаем admin-password-secret.yaml. Здесь прописываем две ENV переменные для графаны, которые содержат имя пользователя и пароль администратора для доступа через веб-интерфейс

Шифруем через sops:

sops --encrypt --encrypted-regex '^(data|stringData)$' --pgp 'B1B740FC8FCA25D9BE0C118CED0FB16FAF7A8471' --in-place admin-password-secret.yaml

6. Добавляем ingress.yaml, чтобы получить доступ к графане извне. Не забываем прописать tls секцию и имя секрета с сертификатом

7. Ну и наконец hr-grafana.yaml. Здесь обратите внимание на раздел envValueFrom, где задаются env переменные, содержащие логин и пароль к графане. Мы указываем, что брать их нужно из нашего секрета, созданного на 5 шаге. Также в разделе datasource мы сразу указываем loki и не даем его изменять из веб-интерфейса

8. Пушим всё в репозиторий. Дожидаемся применения в кластере. Если все прошло по плану - по адресу grafana.example.com (само собой нужно заменить на свой домен) вы увидите веб-интерфейс графаны. Логинимся с указанным нами логином и паролем. Заходим в раздел Explore, в разделе Label filters выбираем namespace, по подам которого мы хотим посмотреть логи и нажимаем Run Query. Получаем картину со скрина к посту

Мы молодцы! В след. постах начнем подключать мониторинг кластера

Stay tuned!

Добавляем Prom++ в кластер

Праздники закончились. Пора снова писать посты :) Графана есть. Логи собираются. Теперь нужно настроить маломальский мониторинг

Раньше для этого использовался Prometheus, сейчас модно использовать Victoria Metrics, так как эта система потребляет меньше ресурсов. Но не так давно ребята из компании Флант зарелизили свой prometheus совместимый инструмент, еще более экономичный. В прод его тащить рановато, но ничто нам не мешает попробовать запустить prompp в dev кластере

Начнем:

Первым делом нам нужно поставить kube-prometheus-stack. Данный helm чарт включает в себя много всего, но мы будем пока что использовать следующий набор компонентов:

kube-state-metrics - отвечает за сбор разных метрик кластера
prometheus-operator - управляет созданием инстансов прометеуса. Им мы будем создавать инстанс prompp
prometheus-node-exporter - экспортер метрик хостовой системы на нодах нашего кластера

1. Добавляем 14-kube-prometheus-stack.yaml

2. Прописываем его в kustomization.yaml

3. Добавляем namespace.yaml. В этом namespace у нас будут жить все компоненты мониторинга

4. Добавляем kube-prometheus-stack.yaml

Здесь отключаем установку графаны, алертменеджера (алертами займемся позже) и самого prometheus, так как мы будем ставить prompp через оператор

Теперь мы можем установить сам prompp:

5. Добавляем 15-prompp.yaml. Он будет устанавливаться после kube-prometheus-stack

6. Прописываем в kustomization.yaml

7. Добавляем prompp.yaml. Указываем storage class и объем места под хранение метрик

Пушим всё в репо, дожидаемся выполнения через flux. По итогу в namespace monitoring должны появиться поды всех компонентов. Node exporter запустится в кол-ве двух штук, по одному на ноду кластера

Вот и всё! В следующем посте будем подключать это добро к графане и добавлять необходимые дашборды