Среда сборки != Среда выполнения => или про то, о чем стоит помнить во время сборки Docker образов
За всю свою инженерную бытность я повидал всякое, особенно в Dockerfile`ах.
Там были и ssh сервера, и MSSQL Server, и systemd, и много чего еще.
Всегда стоит помнить о том, что в готовом образе должна должно быть только ваше приложение и только те библиотеки и зависимости, которые необходимы для его работы.
Такая история хорошо ложится на компилируемые языки программирования, а именно на многими любимый Golang.
Мы вполне можем применить multistage, в котором соберем наш "бинарь" в образе в котором есть все необходимое
для сборки, а дальше мы наш бинарь отправим в более легковесный образ, например, в Alpine.
По итогу мы получим небольшой образ, в котором нет ничего лишнего.
Его достаточно просто распространять, да и вектор атаки существенно ниже.
А еще мы можем "конкретно угореть" и собрать образ на базе scratch =)
Диагностические утилиты, точно стоит оставить за бортом =)
Не забывайте про это ^_^
За всю свою инженерную бытность я повидал всякое, особенно в Dockerfile`ах.
Там были и ssh сервера, и MSSQL Server, и systemd, и много чего еще.
Всегда стоит помнить о том, что в готовом образе должна должно быть только ваше приложение и только те библиотеки и зависимости, которые необходимы для его работы.
Такая история хорошо ложится на компилируемые языки программирования, а именно на многими любимый Golang.
Мы вполне можем применить multistage, в котором соберем наш "бинарь" в образе в котором есть все необходимое
для сборки, а дальше мы наш бинарь отправим в более легковесный образ, например, в Alpine.
По итогу мы получим небольшой образ, в котором нет ничего лишнего.
Его достаточно просто распространять, да и вектор атаки существенно ниже.
А еще мы можем "конкретно угореть" и собрать образ на базе scratch =)
Диагностические утилиты, точно стоит оставить за бортом =)
Не забывайте про это ^_^
👍11
В образе ничего лишнего быть не должно, а как дебажить то?!?!?!?!
Так как мы в моем канальчике будем говориться в основном про k8s, то на дебаге внутри pod`а мы и остановимся.
На помощь нам придет ephemerial containers который позволит нам подключиться к pod`у и посмотреть что там происходит.
Ephemerial-containers с нами с 1.25 версии.
Работают они следующим образом, у нас есть pod нашего приложения, в котором нет буквально ничего, кроме как самого приложения.
Даже оболочки там может и не быть, да и мы можем достаточными параноиками, что бы по-серьезному накрутить безопасность.
Ephemerial-containers позволяют нам добавить в наш pod еще один контейнер, который будет работать параллельно с нашим приложением.
И как раз в этом контейнере могут быть все необходимые утилиты для дебага.
Как это может выглядеть на примере. Все эксперименты проводятся на k8s 1.28.3, запускаем при помощи minikube.
Для начала запустим под нашего приложения:
После того как наш pod "поднимется" мы сделаем describe и увидим следующее
(нас интересует только раздел containers):
В pod`e запущен только одни контейнер, пришло время добавить ephemerial-container для дебага.
Вполнить это мы можем следующей командой.
Где первый simple-app это имя пода к которуму мы хотим добавить ephemerial-container, а второй simple-app это имя контейнера внутри pod`а к которому мы хотим подключиться.
praqma/network-multitool - образ со всем необходимым тулингом для дебага.
Повторно выполняем describe и видим следующее:
Теперь у нас два контейнера =)
Ну а подключиться ко второму контейнеру мы можем вот так:
Вжух и мы внутри нашего debug контейнера, внутри которого есть все нужные нам инструменты.
Порой полезная вещь, рекомендую к использованию ^_^
Так как мы в моем канальчике будем говориться в основном про 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 контейнера, внутри которого есть все нужные нам инструменты.
Порой полезная вещь, рекомендую к использованию ^_^
🔥22❤1👍1
Пссс, парень, немного "ускорения" не желаешь?
Сегодня хочу рассказать про одну интересную книгу, а именно "Ускоряйся! Наука DevOps : Как создавать и масштабировать высокопроизводительные цифровые организации"
(Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)
Несмотря на то что книга была написана в 2018 году, она не теряет актуальность и сейчас.
Если кому то сложно читать на английском, то есть перевод на русский язык.
В ней описаны основные принципы DevOps, а также приведены примеры реализации этих принципов в реальных компаниях.
В ней достаточно много примеров и, что важно, описаны они достаточно понятно.
Много про метрики как бизнеса, так и приложений. Ну и не забываем про культуру DevOps и вцелом роль "айтишечки" в больших организациях.
К прочтению рекомендую ^_^
Достать вы ее сможете сами, вы же сильные мальчики и девочки =)
Сегодня хочу рассказать про одну интересную книгу, а именно "Ускоряйся! Наука DevOps : Как создавать и масштабировать высокопроизводительные цифровые организации"
(Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)
Несмотря на то что книга была написана в 2018 году, она не теряет актуальность и сейчас.
Если кому то сложно читать на английском, то есть перевод на русский язык.
В ней описаны основные принципы DevOps, а также приведены примеры реализации этих принципов в реальных компаниях.
В ней достаточно много примеров и, что важно, описаны они достаточно понятно.
Много про метрики как бизнеса, так и приложений. Ну и не забываем про культуру DevOps и вцелом роль "айтишечки" в больших организациях.
К прочтению рекомендую ^_^
Достать вы ее сможете сами, вы же сильные мальчики и девочки =)
👍13🔥5
Что делать если нужен k8s запущенный локально?
По долгу службы я тестирую достаточно много "новых штук".
И достаточно часто я делаю это локально, на своей машине.
Речь сейчас пойдет про запуск k8s локально.
Какие есть инструменты для запуска:
- minikube - отличный инструмент, пользуюсь им давно, есть множество вариантов запуска, драйверов, плагинов и т.д.
- kind - весьма неплохой инструмент, умеет в достаточно расширенный конфиг, декларативное описание конфигурации, и так как
кластер запускается в docker-контейнерах все это можно запустить в условной CI/CD пайплайне.
Пример описания кластера:
- Что еще - k3s, k0s, k3d, orbstack, etc.
Ну а что использовать - решать только вам =)
UPD - minikube, kind я запускал на маке x86
По долгу службы я тестирую достаточно много "новых штук".
И достаточно часто я делаю это локально, на своей машине.
Речь сейчас пойдет про запуск k8s локально.
Какие есть инструменты для запуска:
- minikube - отличный инструмент, пользуюсь им давно, есть множество вариантов запуска, драйверов, плагинов и т.д.
На выходе получим k8s версии 1.28.3, с сетевым плагином calico, а hyperkit это как раз драйвер для запуска в MacOS (k8s будет внутри ВМ).
minikube start --cpus 6 --memory 8192 --kubernetes-version=1.28.3 --cni=calico --driver=hyperkit.
- 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
- Не забываем о том что в Docker Desktop тоже есть возможность запуска k8s кластера, но его я не использовал ниразу ^_^
kind create cluster --config kind-config.yaml
- Что еще - k3s, k0s, k3d, orbstack, etc.
Ну а что использовать - решать только вам =)
UPD - minikube, kind я запускал на маке x86
👍9🔥4
Всем, привет! =)
Прерываю пред/пост новогоднее молчание ^_^
Примерно как и Иван Василич я начал свой первый спринт в этому году
А самое интересное в этом то, что самая веселая таска в этом спринте - это обновление кластера 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 с elasticsearch внутри аж на 3 версии
Индексы в эластике не большие, эластик используем для полнотекстового поиска всяких штук в нашем мобильном приложении
Чуть больше деталей:
Elasticsearch мы крутим при помощи ECK operator
Конфигурируем при помощи ECK Custom Resource operator
В целом, в таком сетапе, гонять elk в нутри k8s достаточно приятно, проблем не замечали =)
Самое сложно в таком обновление было, обновлять через 3 версии k8s, и каждое обновление должно быть плавным.
То есть:
— обновили мастера
— создали новую нод группу, перенесли доп тулинг (Prometheus, Alertmanager, Certmanaget, NodeLocalDNS, Cert-updater, etc.)
— создали новую нод группу, перенесли ПО ОДНОМУ мастеру elasticsearch
— создали новую нод группу, перенесли ПО ОДНОЙ data ноде elasticsearch (в промежутках проверяя что с кластером и индексами все ок, все зеленое)
На все про все чуть более 6 часов, за один заход =)
Мораль этой истории в том, что обновляйтесь регулярно, не откладывайте на потом =)
👍15⚡2🔥1💯1
Всех с пятничкой, коллеги ^_^
Немного ранее я рассказывал про свои приключения с обновлением кластера 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 на борту
Пришло время рассказать как мы обновляем кластера с нашими 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 - однажды я вам расскажу про то как мы меняли сетевой плагин в кластере, спойлер - ухххх было весело =)
👍10🔥4
Что там с 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 и я об этом точно напишу =)
Коллеги, всем привет!)
Проскочила тут в интернетах вот такая новость
Если вкратце - у 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 и я об этом точно напишу =)
👍13
Коллеги, всем привет! =)
Поговорим про 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
Достаточно выполнить команду
На выходите мы получим ip адрес котрый нам понадобится позже
У себя мы используем cilium в качестве основного CNI, по этому в values нужно добавить следующий блок
После правки этой части values и деплоя чарта у нас появится CiliumLocalRedirectPolicy внутри кластера
Который будет выглядеть так:
Нужно нам это как раз для того что бы редиректить DNS запросы к kube-dns сервису, туда куда нам надо, а именно в node-local-dns
Не забываем настроить дополнительные tolerations, если они у вас есть, суть в том что node-local-dns развертывается при помощи Daemonset и полагаться на мысль о том что Daemonset не реагирует на “кастомные” taints не правильно =)
После успешного развертывания скорее всего вам не составит труда навесить мониторинг на node-local-dns
Базовый дашборд, который взят из Grafana Dashboards, выглядит достаточно информативно
Ну и собственно на этом все, основная часть конфига не этом окончена =)
Более подробно как работает DNS внутри k8s вы можете почитать тут
Надеюсь мой пост поможет вам стать более надежными ^_^
Поговорим про 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 вы можете почитать тут
Надеюсь мой пост поможет вам стать более надежными ^_^
🔥17❤1
Коллеги, всем привет!=)
4 марта буду на DevOps Conf 2024 где в 10:00 в зале Уфа
буду рассказывать как мы устроены и как сделали запуск новых новых
сервисов максимально быстрым
Ссылка на доклад тут
Кто хочет пообщаться вживую, буду очень рад =)
4 марта буду на DevOps Conf 2024 где в 10:00 в зале Уфа
буду рассказывать как мы устроены и как сделали запуск новых новых
сервисов максимально быстрым
Ссылка на доклад тут
Кто хочет пообщаться вживую, буду очень рад =)
devopsconf.io
Владимир Дроздецкий на DevOpsConf 2024
Перед тем, как начать разработку нового сервиса, нужно сделать много мелких шагов:* создать репозиторий,* настроить репозиторий,* добавить шаблон сервиса,* добавить шаблон CI/CD pipeline,* добавить шаблон helm app-chart для деплоя в различные окружения,*…
🔥19❤4⚡2💯1
Коллеги, всем привет!=)
DevOps Conf 2024 отгремел, я уже почти от него отдохнул и понемногу врываюсь в рабочие будни
Я к вам с хорошими новостями =)
20 марта 2024 в 18-00
Состоится online meetup
Где MagnitTech (я и мои коллеги) и Sbermarket Tech расскажим про всякое-интересное
Буду рассказывать как устроены наши пайплайны, как устроена выкатка сервисов, расскажу про DORA-metrics
Обязательно приходи, будет интересно ^_^
Ссылка на регистрацию тут
DevOps Conf 2024 отгремел, я уже почти от него отдохнул и понемногу врываюсь в рабочие будни
Я к вам с хорошими новостями =)
20 марта 2024 в 18-00
Состоится online meetup
Где MagnitTech (я и мои коллеги) и Sbermarket Tech расскажим про всякое-интересное
Буду рассказывать как устроены наши пайплайны, как устроена выкатка сервисов, расскажу про DORA-metrics
Обязательно приходи, будет интересно ^_^
Ссылка на регистрацию тут
🔥20👍4
Коллеги, всем привет=)
Вчера прошел митап который я анонсил немного ранее
Ссылку на запись конечно же прикладываю =)
К сожалению, в последнее время пишу не так часто, увы накопилось очень много всего
Обязательно обещаю исправиться =)
В ближайших планах рассказать вам про Goldilocks и особенностях его работы с VPA, да и mattermost не обойду стороной =)
Вчера прошел митап который я анонсил немного ранее
Ссылку на запись конечно же прикладываю =)
К сожалению, в последнее время пишу не так часто, увы накопилось очень много всего
Обязательно обещаю исправиться =)
В ближайших планах рассказать вам про Goldilocks и особенностях его работы с VPA, да и mattermost не обойду стороной =)
🔥16❤5
Коллеги, всем привет!)
А вот и очередная заметка на моем канальчике ^_^
В ней я рассказываю про "Златовласку" и управление ресурсами
Заодно потестировал telegra.ph как площадку для написания постов,
к сожалению объема поста уже не хватает
Приятного чтения =)
А вот и очередная заметка на моем канальчике ^_^
В ней я рассказываю про "Златовласку" и управление ресурсами
Заодно потестировал telegra.ph как площадку для написания постов,
к сожалению объема поста уже не хватает
Приятного чтения =)
🔥9
Друзья, всем привет! ^_^
Мы с коллегами делаем “Observability meetup”
Когда - 17 апреля 2024, 18-05
Кто выступает - Magnit Tech, MTC, Hilbert Team, Ozon
Темы:
— Как внедрить распределенную трассировку на open source инструментах
*Спикер: Алексей Колосков, Lead DevOps в Hilbert Team*
— Трассировка: как приручить 200 тысяч спанов в секунду при помощи Grafana Tempo и искать трейсы за 3 секунды
*Спикер: Сергей Будников, ведущий инженер DevOps в Magnit Tech*
— Alerts-Registry. Одно место управления алертами
*Спикер: Анна Гобрусева, руководитель команды инструментов мониторинга Ozon*
— Мониторинг под ключ
*Спикер: Андрей Кречетов, ведущий инженер DevOps в МТС*
Оффлайн (в нашем офисе в МСК) + Онлайн (на Youtube)
Фанфакт - наверняка вы привыкли видеть меня как спикера, а в этот раз я буду ведущим ^_^
Ссылка на регистрацию и подробная информация
Приходи лично, смотри трансляцию, будет интересно =)
Мы с коллегами делаем “Observability meetup”
Когда - 17 апреля 2024, 18-05
Кто выступает - Magnit Tech, MTC, Hilbert Team, Ozon
Темы:
— Как внедрить распределенную трассировку на open source инструментах
*Спикер: Алексей Колосков, Lead DevOps в Hilbert Team*
— Трассировка: как приручить 200 тысяч спанов в секунду при помощи Grafana Tempo и искать трейсы за 3 секунды
*Спикер: Сергей Будников, ведущий инженер DevOps в Magnit Tech*
— Alerts-Registry. Одно место управления алертами
*Спикер: Анна Гобрусева, руководитель команды инструментов мониторинга Ozon*
— Мониторинг под ключ
*Спикер: Андрей Кречетов, ведущий инженер DevOps в МТС*
Оффлайн (в нашем офисе в МСК) + Онлайн (на Youtube)
Фанфакт - наверняка вы привыкли видеть меня как спикера, а в этот раз я буду ведущим ^_^
Ссылка на регистрацию и подробная информация
Приходи лично, смотри трансляцию, будет интересно =)
🔥19
Observability meetup - итоги
Коллеги, всем привет!
На прошлой недели прошел первый митап Magnit Tech и он был посвящен Observability
Ууууух, было интересно, обычно я выступаю на митах, в этот раз я был ведущим/модератором/тамадой
Определенно это новый, интересный опыт, теперь я точно знаю каково людям которые ведут =)
Что было:
— Поговорили про трейсинг и когда разработчики не хотят имплементить либы для трассировки в код
— Как раскачать Grafana Tempo до 200к span/s
— Как устроены алерты в Ozon и про инструмент Alert-registry
— Как устроен алертинг в МТС и как его доставлять до кластеров (в том числе и baremetall)
Запись митапа доступна по ссылке
Все презентации можно посмотреть тут
Если вы были с нами оффлайн, то новые аватарки можно добыть тут
В ближайшее время, обязательно напишу обо всех докладах по отдельности, stay tuned =)
Коллеги, всем привет!
На прошлой недели прошел первый митап Magnit Tech и он был посвящен Observability
Ууууух, было интересно, обычно я выступаю на митах, в этот раз я был ведущим/модератором/тамадой
Определенно это новый, интересный опыт, теперь я точно знаю каково людям которые ведут =)
Что было:
— Поговорили про трейсинг и когда разработчики не хотят имплементить либы для трассировки в код
— Как раскачать Grafana Tempo до 200к span/s
— Как устроены алерты в Ozon и про инструмент Alert-registry
— Как устроен алертинг в МТС и как его доставлять до кластеров (в том числе и baremetall)
Запись митапа доступна по ссылке
Все презентации можно посмотреть тут
Если вы были с нами оффлайн, то новые аватарки можно добыть тут
В ближайшее время, обязательно напишу обо всех докладах по отдельности, stay tuned =)
🔥17
Вечерний пост или Docker image infratools
Периодически мне нужен docker образ с некоторым количеством тулинга что бы подебажить что-то внутри k8s, а внутри запущенного подика снова устанавливать все что понадобится максимально ну такое.
Наконец то дошли руки и я его собрал =)
Сам докер образ и его репа вот тут
Заодно немного размял пальцы с Github Actions и вспомнил почему он мне не очень нравится😂😂😂
А еще я включил комментарии, так что можем пообщаться там =)
Надеюсь образ вам пригодится, а если вам что-то понадобится - смело создавайте пулл-реквесты =)
Периодически мне нужен docker образ с некоторым количеством тулинга что бы подебажить что-то внутри k8s, а внутри запущенного подика снова устанавливать все что понадобится максимально ну такое.
Наконец то дошли руки и я его собрал =)
Сам докер образ и его репа вот тут
Заодно немного размял пальцы с Github Actions и вспомнил почему он мне не очень нравится😂😂😂
А еще я включил комментарии, так что можем пообщаться там =)
Надеюсь образ вам пригодится, а если вам что-то понадобится - смело создавайте пулл-реквесты =)
🔥6👍1
Observability meetup - итоги P-1
Коллеги, всем привет! =)
Поговорим про доклады Observability meetup который мы не так давно провели
Первый доклад от Алексея Колоскова - Как внедрить распределенную трассировку на open source инструментах
Доклад интересен тем что Алексей рассказывает про историю выбора туллинга для построения распределенной трассировки с учетом определенных ограничений
И самое интересное ограничение в том что разработка не очень хочет имплементить либы для трассировки в свой код
Конечно же в таком случае можно втащить Istio и получить трассировку и много всего интересного, НО это большой “кусок” того за чем надо присматривать
Решение оказалось достаточно простым - использование OTEL-collector который как раз за счет инструментирования (Instrumentation) позволяет формировать трейсы
Интересный подход и интересная реализация
Ссылка на доклад с тайм кодом тут
Коллеги, всем привет! =)
Поговорим про доклады Observability meetup который мы не так давно провели
Первый доклад от Алексея Колоскова - Как внедрить распределенную трассировку на open source инструментах
Доклад интересен тем что Алексей рассказывает про историю выбора туллинга для построения распределенной трассировки с учетом определенных ограничений
И самое интересное ограничение в том что разработка не очень хочет имплементить либы для трассировки в свой код
Конечно же в таком случае можно втащить Istio и получить трассировку и много всего интересного, НО это большой “кусок” того за чем надо присматривать
Решение оказалось достаточно простым - использование OTEL-collector который как раз за счет инструментирования (Instrumentation) позволяет формировать трейсы
Интересный подход и интересная реализация
Ссылка на доклад с тайм кодом тут
👍6🔥4