DevOps не горит

Коллеги, всем привет! =) Поговорим про DNS внутри k8s и зачем нам нужен Node-local-dns Суть следующая: — k8s из коробки предоставляет нам весьма удобный Service Discovery (вспомним те же самые сущности типа Service) — все это настраивается и менеджится автоматически — да и работает все это весьма неплохо НО при этом мы можем схватить следующий кейс У нас в кластере много сервисов (имею ввиду приложений), которые общаются между собой, и подов всех сервисов у нас достаточно много В какой то момент DNS у нас просто может отказать (из-за перегруза), отказать с концами, что потенциально приведет к практически полному выходу из строя кластера (имеется ввиду что сервисы не смогут найти друг друга по доменным именам или такой поиск будет сильно затруднен) Ииииии естественно мы однажды встряли с такой проблемой да еще и в проде ^_^ Что с этим можно сделать что бы стало хорошо и не упасть в будущем? Вспоминаем как устроен DNS: — authoritative DNS - самый главный DNS сервер, у которого все зоны и всякое такое — DNS recursor (иногда его еще называют resolver) - для простоты понимания, это проксян, который ооочень быстро обрабатывает DNS запросы, может их кэшировать, и может выполнять некоторую логику, тем самым сильно разгружая authoritative DNS Получается что в нашем случае (если у вас кубик в проде - у вас тоже ^_^) нам нужен “рекурсор”, который разгрузит kube-dns и упростит/ускорит работу с DNS для приложений внутри k8s И тут на сцену выходи Node-local-dns =) Он как раз и будет выполнять роль DNS recursor У себя мы его деплоим при помощи вот этого чарта Все достаточно просто, но есть некоторые моменты на которые стоит обратить внимание Для начала нужно узнать адрес kube dns Достаточно выполнить команду

kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}

На выходите мы получим ip адрес котрый нам понадобится позже У себя мы используем cilium в качестве основного CNI, по этому в values нужно добавить следующий блок

config:
  localDnsIp: 192.168.14.12 ##Адрес который мы получили ранее, адрес для примера
  cilium: ##Создаем ciliumlocalredirectpolicies для редиректа DNS трафика
    clusterDNSService: kube-dns 
    clusterDNSNamespace: kube-system
    udp:
      enabled: true
      portName: dns
    tcp:
      enabled: true
      portName: dns-tcp

После правки этой части values и деплоя чарта у нас появится CiliumLocalRedirectPolicy внутри кластера Который будет выглядеть так:

apiVersion: cilium.io/v2
kind: CiliumLocalRedirectPolicy
metadata:
  annotations:
    meta.helm.sh/release-name: node-local-dns
    meta.helm.sh/release-namespace: kube-system
  labels:
    app.kubernetes.io/name: node-local-dns
    helm.sh/chart: node-local-dns-1.6.0
    helm.toolkit.fluxcd.io/name: node-local-dns
    helm.toolkit.fluxcd.io/namespace: kube-system
  name: node-local-dns
  namespace: kube-system
spec:
  redirectBackend:
    localEndpointSelector:
      matchLabels:
        app.kubernetes.io/instance: node-local-dns
        app.kubernetes.io/name: node-local-dns
    toPorts:
    - name: dns
      port: "53"
      protocol: UDP
    - name: dns-tcp
      port: "53"
      protocol: TCP
  redirectFrontend:
    serviceMatcher:
      namespace: kube-system
      serviceName: kube-dns

Нужно нам это как раз для того что бы редиректить DNS запросы к kube-dns сервису, туда куда нам надо, а именно в node-local-dns Не забываем настроить дополнительные tolerations, если они у вас есть, суть в том что node-local-dns развертывается при помощи Daemonset и полагаться на мысль о том что Daemonset не реагирует на “кастомные” taints не правильно =) После успешного развертывания скорее всего вам не составит труда навесить мониторинг на node-local-dns Базовый дашборд, который взят из Grafana Dashboards, выглядит достаточно информативно Ну и собственно на этом все, основная часть конфига не этом окончена =) Более подробно как работает DNS внутри k8s вы можете почитать тут Надеюсь мой пост поможет вам стать более надежными ^_^

Вижу что мои слайды вам нравятся🤣 Подкину еще один Знаете что за мем, ставите - 🔥 Не знаете, но вам понравилась картинка - 👍

Коллеги, привет! =) Готовлюсь к внутреннему митапчику и буду рассказывать как мы считаем DORA-метрики Есть у меня такой слайд Как вам?=) Если понравился и ты понял о чем он, ставь - 🔥 Если не понял, ставь - 👍 Ну и всем хорошего понедельника ^_^

Что там с fluxcd? Коллеги, всем привет!) Проскочила тут в интернетах вот такая новость Если вкратце - у Flux проблемы, большинство разработчиков либо ушли, либо “навострили лыжи”, в том числе и Stefan Prodan который является мейнтейнером FluxCD И тут мы резко всей командой задумались - “А что делать если FluxCD падет смертью храбрых?” У себя FluxCD мы используем для бутстрапа и конфигурирования k8s кластеров как основной инструмент Пути тут, казалось бы, два: - FluxCD - опенсорс и имеет достаточно большое комьюнити, активных разработчиков там достаточно, даже если кор мейнтейнеры уйдут, по идеи проект подхватят и он продолжить жить/развиваться - Если FluxCD все таки “погибнет” нам точно придется искать альтернативу, и “десять девяток”, что выбор падет на ArgoCD (развивается он семимильными шагами и мы уже местами его используем) Несмотря на то что FluxCD мы любим и умеем, периодически с ним были и свои “приколы”: - Как же было весело когда FluxCD прыгнул из 0.4 в 2.0.0 практически без совместимости - Зависимостями управлять там ооочень не тривиально Как говориться посидим посмотрим ^_^ PS - ArgoCD (а точнее Argo Rollouts) мы используем в связке с Istio Service Mesh и Prometheus для организации Canary Deployment и я об этом точно напишу =)

Всех с пятничкой, коллеги ^_^ Немного ранее я рассказывал про свои приключения с обновлением кластера k8s с elasticsearch на борту Пришло время рассказать как мы обновляем кластера с нашими backend-сервисами Какие у нас есть особенности: - у нас есть возможность делать кластера достаточно большими, не только на момент обновления - все backend-сервисы у нас stateless (они не хранят свое состояние), даже если у них есть RabbitMQ, Redis, etc. - об этом мы заранее договорились с разработкой. Если нужно какое то хранение состояния (база, очередь), все необходимое выносится за пределы кластера k8s и берется managed в облаке (кстати у нас Ya.cloud) Дизайн кластеров: - мультимастер - мастера размазаны в разные зоны доступности (A,B,C) - минимум 2 нод группы для приложений в зонах A и B с автоскейлингом - может быть дополнительная нод группа для “определенных” задач Первое с чего мы всегда начинаем, это проверка “что у нас там с API k8s? нет ли чего то удаленного в API?” Для этого мы используем утилитку pluto от FairwindsOps После проверки: - Все хорошо - можно смело обновляться - Есть какие то замечания - обновляем какие то компоненты, в общем решаем проблемы с API Обновление происходит в несколько этапов: 1 - обновляем мастера на +1 версию 2 - добавляем новую нод группу с +1 версией в нужной нам зоне (A или B ) 3 - “кордоним” все ноды в кластере 4 - первую/обновляемую нод группу “фиксируем” по размеру, что бы не начали создаваться новые ноды со старой версией k8s (напоминаю что у нас автоскейлинг) 5 - “дрейним” первую/обновляемую нод группу 6 - проверяем по телеметрии что все ок и все работает 7 - при необходимости - повторяем Не раз уже делаем так и все ок ^_^ PS - RMQ, Redis, etc. внутри k8s у нас в кластерном режиме и PV. Но относимся мы к ним все равно как к стейтлесс сервисам. И как мы знаем (надеюсь что вы знаете), PV не реплицируются между зонами я Ya.Cloud, по этому мы обновляем зону за зоной, что бы “подики” могли примонтировать свои PV. PSS - однажды я вам расскажу про то как мы меняли сетевой плагин в кластере, спойлер - ухххх было весело =)

Всем, привет! =) Прерываю пред/пост новогоднее молчание ^_^ Примерно как и Иван Василич я начал свой первый спринт в этому году А самое интересное в этом то, что самая веселая таска в этом спринте - это обновление кластера k8s с elasticsearch внутри аж на 3 версии Индексы в эластике не большие, эластик используем для полнотекстового поиска всяких штук в нашем мобильном приложении Чуть больше деталей: Elasticsearch мы крутим при помощи ECK operator Конфигурируем при помощи ECK Custom Resource operator В целом, в таком сетапе, гонять elk в нутри k8s достаточно приятно, проблем не замечали =) Самое сложно в таком обновление было, обновлять через 3 версии k8s, и каждое обновление должно быть плавным. То есть: — обновили мастера — создали новую нод группу, перенесли доп тулинг (Prometheus, Alertmanager, Certmanaget, NodeLocalDNS, Cert-updater, etc.) — создали новую нод группу, перенесли ПО ОДНОМУ мастеру elasticsearch — создали новую нод группу, перенесли ПО ОДНОЙ data ноде elasticsearch (в промежутках проверяя что с кластером и индексами все ок, все зеленое) На все про все чуть более 6 часов, за один заход =) Мораль этой истории в том, что обновляйтесь регулярно, не откладывайте на потом =)

Что делать если нужен k8s запущенный локально? По долгу службы я тестирую достаточно много "новых штук". И достаточно часто я делаю это локально, на своей машине. Речь сейчас пойдет про запуск k8s локально. Какие есть инструменты для запуска: - minikube - отличный инструмент, пользуюсь им давно, есть множество вариантов запуска, драйверов, плагинов и т.д.

minikube start --cpus 6 --memory 8192 --kubernetes-version=1.28.3 --cni=calico --driver=hyperkit.  

На выходе получим k8s версии 1.28.3, с сетевым плагином calico, а hyperkit это как раз драйвер для запуска в MacOS (k8s будет внутри ВМ). - kind - весьма неплохой инструмент, умеет в достаточно расширенный конфиг, декларативное описание конфигурации, и так как кластер запускается в docker-контейнерах все это можно запустить в условной CI/CD пайплайне. Пример описания кластера:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  image: kindest/node:v1.21.10@sha256:84709f09756ba4f863769bdcabe5edafc2ada72d3c8c44d6515fc581b66b029c
- role: worker
  image: kindest/node:v1.21.10@sha256:84709f09756ba4f863769bdcabe5edafc2ada72d3c8c44d6515fc581b66b029c

Ну и запустить мы можем следующей командой:

kind create cluster --config kind-config.yaml

- Не забываем о том что в Docker Desktop тоже есть возможность запуска k8s кластера, но его я не использовал ниразу ^_^ - Что еще - k3s, k0s, k3d, orbstack, etc. Ну а что использовать - решать только вам =) UPD - minikube, kind я запускал на маке x86

Пссс, парень, немного "ускорения" не желаешь? Сегодня хочу рассказать про одну интересную книгу, а именно "Ускоряйся! Наука DevOps : Как создавать и масштабировать высокопроизводительные цифровые организации" (Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations) Несмотря на то что книга была написана в 2018 году, она не теряет актуальность и сейчас. Если кому то сложно читать на английском, то есть перевод на русский язык. В ней описаны основные принципы DevOps, а также приведены примеры реализации этих принципов в реальных компаниях. В ней достаточно много примеров и, что важно, описаны они достаточно понятно. Много про метрики как бизнеса, так и приложений. Ну и не забываем про культуру DevOps и вцелом роль "айтишечки" в больших организациях. К прочтению рекомендую ^_^ Достать вы ее сможете сами, вы же сильные мальчики и девочки =)

В образе ничего лишнего быть не должно, а как дебажить то?!?!?!?! Так как мы в моем канальчике будем говориться в основном про k8s, то на дебаге внутри pod`а мы и остановимся. На помощь нам придет ephemerial containers который позволит нам подключиться к pod`у и посмотреть что там происходит. Ephemerial-containers с нами с 1.25 версии. Работают они следующим образом, у нас есть pod нашего приложения, в котором нет буквально ничего, кроме как самого приложения. Даже оболочки там может и не быть, да и мы можем достаточными параноиками, что бы по-серьезному накрутить безопасность. Ephemerial-containers позволяют нам добавить в наш pod еще один контейнер, который будет работать параллельно с нашим приложением. И как раз в этом контейнере могут быть все необходимые утилиты для дебага. Как это может выглядеть на примере. Все эксперименты проводятся на k8s 1.28.3, запускаем при помощи minikube. Для начала запустим под нашего приложения:

apiVersion: v1
kind: Pod
metadata:
  name: simple-app
spec:
  containers:
  - name: simple-app
    image: mrgreyves/simple-app:0.3
    env:
      - name: VERSION
        value: "1"
    ports:
    - containerPort: 8000

После того как наш pod "поднимется" мы сделаем describe и увидим следующее (нас интересует только раздел containers):

Containers:
  simple-app:
    Container ID:   docker://94339c2434b41ab2dc3b12e002f3d694f9aeeda60bd375851ddbc68997fecad4
    Image:          mrgreyves/simple-app:0.3
    Image ID:       docker-pullable://mrgreyves/simple-app@sha256:704a51301a1ab21b32f736c3d9db15cbfe2fe311b525a9e6e397c9195baeb33d
    Port:           8000/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 17 Dec 2023 14:49:31 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      VERSION:  1
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c7f75 (ro)

В pod`e запущен только одни контейнер, пришло время добавить ephemerial-container для дебага. Вполнить это мы можем следующей командой.

kubectl debug -it --attach=false simple-app --image=praqma/network-multitool --target=simple-app

Где первый simple-app это имя пода к которуму мы хотим добавить ephemerial-container, а второй simple-app это имя контейнера внутри pod`а к которому мы хотим подключиться. praqma/network-multitool - образ со всем необходимым тулингом для дебага. Повторно выполняем describe и видим следующее:

Containers:
  simple-app:
    Container ID:   docker://94339c2434b41ab2dc3b12e002f3d694f9aeeda60bd375851ddbc68997fecad4
    Image:          mrgreyves/simple-app:0.3
    Image ID:       docker-pullable://mrgreyves/simple-app@sha256:704a51301a1ab21b32f736c3d9db15cbfe2fe311b525a9e6e397c9195baeb33d
    Port:           8000/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 17 Dec 2023 14:49:31 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      VERSION:  1
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c7f75 (ro)
Ephemeral Containers:
  debugger-v658k:
    Container ID:   docker://6813011cff1f7dd68758d9476a4c7237ba00b3e6c8e6e8e3094dfce6485ae936
    Image:          praqma/network-multitool
    Image ID:       docker-pullable://praqma/network-multitool@sha256:97b15098bb72df10f7c4e177b9c0e2435ec459f16e79ab7ae2ed3f1eb0e79d19
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Sun, 17 Dec 2023 14:52:52 +0300
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>

Теперь у нас два контейнера =) Ну а подключиться ко второму контейнеру мы можем вот так:

k exec -it simple-app -c debugger-v658k -- bash

Вжух и мы внутри нашего debug контейнера, внутри которого есть все нужные нам инструменты. Порой полезная вещь, рекомендую к использованию ^_^

Среда сборки != Среда выполнения => или про то, о чем стоит помнить во время сборки Docker образов За всю свою инженерную бытность я повидал всякое, особенно в Dockerfile`ах. Там были и ssh сервера, и MSSQL Server, и systemd, и много чего еще. Всегда стоит помнить о том, что в готовом образе должна должно быть только ваше приложение и только те библиотеки и зависимости, которые необходимы для его работы. Такая история хорошо ложится на компилируемые языки программирования, а именно на многими любимый Golang. Мы вполне можем применить multistage, в котором соберем наш "бинарь" в образе в котором есть все необходимое для сборки, а дальше мы наш бинарь отправим в более легковесный образ, например, в Alpine. По итогу мы получим небольшой образ, в котором нет ничего лишнего. Его достаточно просто распространять, да и вектор атаки существенно ниже. А еще мы можем "конкретно угореть" и собрать образ на базе scratch =) Диагностические утилиты, точно стоит оставить за бортом =) Не забывайте про это ^_^

По следам Selectel Admin Meetup: Prometheus Service Discovery Пришло время рассказать о своем докладе =) Кажется что удалось раскрыть тему и она оказалось вполне себе нужной. После митапа ребята говорили что некоторым из них уже пора строить что-то подобное и инфа из моего доклада им как раз подойдет. Надеюсь что "нормально" ответил на все вопросы из зала =) А вот что я упустил, так это историю с DrillDown dashboard, про которую были вопросы. Да и по количесту рук было видно что не все знают что это за подход и точно не пользуются им. Постараюсь это исправить, в планах как будет чуть больше свободного времени, собрать небольшой стенд который как раз и позволит раскрыть историю с DrillDown dashboard. Пока что в голове идея о том что этот стенд должен быть с использованием Docker, что бы каждый мог запустить его локально и что-то потыкать. Как стенд будет готов, обязательно сделаю отдельный пост. Моя презентация тут

По следам Selectel Admin Meetup: ChatGPT Маша рассказывала о том как ChatGPT помогает в инфраструктурной разработки Что хочу отметить сразу: - хорошо что были добавлены промпты и результаты ответов - разбор истории ожидания vs. реальность - акценты на том как стоит использовать различные ИИ "помогаторы" Полностью согласен с Машей в том что ChatGPT это не панацея, а скорее дополнительный инструмент. Он врятли решит за тебя поставленную задачу, но может, вполне себе, подкинуть пару-тройку идей. Насколько часто я пользуюсь ChatGPT? Не часто, хотя вчера он мне помогал с конфигурированием echoprometheus middleware ^_^ Был интересный вопрос о том, на каких датасетах, то есть данных, учить различные ИИ что бы он, в инженерном плане, стал сильно умнее? Конечно же в "интернетах" есть большое количество весьма неплохих примеров решения тех или иных задач. Но самый крутой код, наработки и тд конечно же внутри компаний, в закрытых контурах и щедро смазанный NDA. Если такие компания хотят своего ИИ "помогатора" выход для них это только selfhosted модели и дообучение на своих датасетах. Что еще можно посмотреть: - LocalAI - сборник ИИ альтернатив ChatGPT которые можно запустить локально хоть на своем ноуте Маша, спасибо большое, было круто ^_^ А в этом посте просто мои рассуждения =) Презентация Маши тут

Если вы любите подкасты и воскресным вечером вам стало скучно. Рекомендую посмотреть/послушать 12 выпуск подкаста "Магнитное поле" Мой коллега Антон Огородников рассказывает как у нас устроена разработка, какие подходы мы используем и тд. А еще он рассказывает про PaaS и весь наш туллинг для разработчиков. В разработке которого я, в том числе, тоже принимаю участие ^_^ Сам подкаст можно найти тут

По следам Selectel Admin Meetup: GitOps Антон рассказывал о том как они готовят ML инфраструктуру для клиентов Что хочу отметить сразу: - интересно посмотреть как ресурсы связаны между собой - как ресурсы упакованы в pipeline и как он вызывается Был интересный вопрос о том, а что будет если Gitlab, который является источником правды упадет? Тут достаточно все просто - падание Gitlab не так страшно, так как в моменте на "скорость полета" это не повлияет. Все ресурсы уже созданы. Если надо что-то обновить/добавить, а Gitlab "валяется", станет несколько сложнее. Думаю что команда которая отвечает за Gitlab как сервис вполне себе озаботилась и отказоустойчивостью, и резервированием, и резервными копиями. А вот потеря terraform state со всеми его ресурсами - это уже беда. Так как частей инфраструктуры которые были созданы при помощи terraform много. Соотвественно state нужно бекапить, часто, в надежное место, и иногда еще и проверять. "Секретные данные" которые используются в Gitlab pipeline, скорее всего хранятся в Vault, так что его отказоустойчивостью тоже стоит заняться. Из несовсем очевидных историй, которые стоит подсветить, это то что количество downstream pipeline не бесконечно и в определенных случаях, когда вложенность pipeline становится больше 3х, все это может сломаться =( Мы в своем infra pipeline как раз с этим и столкнулись, решение вроде и простое, переделать структуру репозитория, но достаточно трудоемкое. Что еще можно посмотреть/интегрировать: - Terragrunt - как раз таки позволит переиспользовать код и добавить ооочень крутую шаблонизацию - Atlantis - возможно тоже стоит посмотреть, выглядит так что он достаточно просто интегрируется с CI/CD системами Антон, спасибо большое за доклад, было очень интересно! ^_^ А в этом посте просто мои рассуждения =) Презентация Антона тут

https://www.youtube.com/live/HQntkIDRjC4?si=z-npH1mxf9cAHNTU А вот и ссылка на трансляцию, присоединяйтесь Я выступаю после 20-00

Скоро начнётся митап Кто в Питере, приходите Ссылку на трансляцию приложу позже

Если вы любите подкасты и хотите узнать что-то новое Особенно внутри Magnit Tech Рекомендую посмотреть выпуск подкаската "Магнитное поле" с Юрием Мисников (CTO) и Татьяной Коваль (Директор по архитектуре и инфраструктуре) Коллеги рассказывают как все устроено у нас и делятся своим опытом https://youtu.be/khDzaLQdcr0

И в продолжение темы про Observability и все вот эти штуки В 2022 году на DevOps Conf рассказывал как мы у себя его и строили Получился у нас достаточно большой комбайн, который мы в дальнейшем стали распространять по другим домена Magnit Tech Видео доклада тут Если вы предпочитаете читать, то расшифровка тут ЗЫ - материал полностью актуален на 2022 год, но в 2023 году многие вещи были переосмыслены и координально перестроены, однажды я расскажу об этом =)

7 декабря 2023 Буду на оффлайн митапе в Selectel Трансляция так же будет Расскажу как можно организовать Service Discovery в связке Hashicrop Consul и Prometheus Приходи, будет интересно