Мой первый день в мой первый 41 год.
- доброе утро, солнышко!
- доброе утро, Сашенька, желаю тебе отличной погоды и хорошего настроения!
- доброе утро, госуслуги!
- доброе утро, Сашенька, желаю тебе отличных свершений и хорошей недели!
- доброе утро мэрия Москвы!
- доброе утро, Александр, желаем тебе лучшего и вот твой купон на квартиру в Москве и новый Айпад
- доброе утро, мой негосударствнный пенсионный фонд, на который я потратил 21 год своей жизни и все пенсионные накопления!
- доброе утро, дурачок, добро пожаловать во взрослую жизнь и весь наш фонд сегодня подал на банкротство и угадай, что с твоими деньгами и пенсией
- доброе утро, солнышко!
- доброе утро, Сашенька, желаю тебе отличной погоды и хорошего настроения!
- доброе утро, госуслуги!
- доброе утро, Сашенька, желаю тебе отличных свершений и хорошей недели!
- доброе утро мэрия Москвы!
- доброе утро, Александр, желаем тебе лучшего и вот твой купон на квартиру в Москве и новый Айпад
- доброе утро, мой негосударствнный пенсионный фонд, на который я потратил 21 год своей жизни и все пенсионные накопления!
- доброе утро, дурачок, добро пожаловать во взрослую жизнь и весь наш фонд сегодня подал на банкротство и угадай, что с твоими деньгами и пенсией
❤3
- "а можете ли вы, мои новые интерны, вводить эти команды? всё ли хорошо тут? ответьте, пожалуйста, на вопрос"
- "да вроде хорошо. мы часть команд не знаем, но вроде всё как обычно, гит адд, гит коммит и гит пуш. а может и нельзя, мы не знаем часть команд, мы обычно кнопку в vscode жмём"
#git
git add .
git commit -m "fix" --no-verify
git push origin main --force
git tag -f prod
git push --force origin prod
git clean -fdx
git reset --hard HEAD~5
git push --force-with-lease
git reflog expire --expire=now --all
git gc --aggressive --prune=now
- "да вроде хорошо. мы часть команд не знаем, но вроде всё как обычно, гит адд, гит коммит и гит пуш. а может и нельзя, мы не знаем часть команд, мы обычно кнопку в vscode жмём"
#git
😁6👍1
- "А расскажите, пожалуйста, что не так или так в этом докерфайле. Что выглядит нормально, что смущает, что кажется вы сделали бы иначе? Что может быть вы переделали. На что и почему. Или вообще тут всё идеально и трогать ничего не надо. Поделитесь мыслями. можете пользоваться любой документацией, любой информацией в интернете, кроме AI. Особого лимита времени тут нет, просто говорите всё, что вы об этом думаете, это главное. Правильного/правильных ответов тут нет, интересно всё то, что вы об этом всём думаете."
Давным-давно я проводил интервью и спрашивал кандидатов обо всяком.
В один момент времени я начал использовать этот замечательный докерфайл.
Лично мне он помогал определить сильные и слабые стороны кандидата(да, надо было много работать с кубером и докер имаджами на этой вакансии). На базе него я иногда задавал дополнительные наводящие вопросы: про readOnlyRootFilesystem/allowPrivilegeEscalation/capabilities, про опыт с бекендом, опыт с фронтом, про контекст и так далее. Не для доёба, нет, кому оно нужно.
Просто понять насколько глубоко в бездну нырял кандидат со своим опытом и сможет ли не перейти на темную сторону упоротых девелоперов, пройдя этапы собеседования.
Конечно же я знаю множество инженеров, кто найдёт миллионов доводов, что собеседование неправильное, не верное, вопросы говно, файл тупорылый, такое не надо спрашивать и многое другое.
Да всё возможно.
Однако тут нанимал я, а не кто-то другой, так что козырь самодура🤡 интервьюера был у меня в руках.
Сейчас подобные наработки я использую, чтобы гонять своих интернов на логику и получения опыта без хлебания половника подливы говна из клоунско-птушных легаси проектов с монорепой монолитом.
#собеседование #интервью #всратость #docker
FROM ubuntu:latest
COPY ./ /app
WORKDIR /app
RUN apt-get update
RUN apt-get install -y cowsay
RUN apt-get upgrade
RUN apt-get -y install libpq-dev imagemagick gsfonts ruby-full ssh supervisor
RUN gem install bundler
RUN echo "vm.swappiness=10" >> /etc/sysctl.conf && chmod -R 777 /tmp
RUN curl -sL https://deb.nodesource.com/setup_9.x | sudo bash -
RUN apt-get install -y nodejs
RUN bundle install --without development test --path vendor/bundle
RUN rm -rf /usr/local/bundle/cache/*.gem
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
CMD [“/app/init.sh”]
Давным-давно я проводил интервью и спрашивал кандидатов обо всяком.
В один момент времени я начал использовать этот замечательный докерфайл.
Лично мне он помогал определить сильные и слабые стороны кандидата(да, надо было много работать с кубером и докер имаджами на этой вакансии). На базе него я иногда задавал дополнительные наводящие вопросы: про readOnlyRootFilesystem/allowPrivilegeEscalation/capabilities, про опыт с бекендом, опыт с фронтом, про контекст и так далее. Не для доёба, нет, кому оно нужно.
Просто понять насколько глубоко в бездну нырял кандидат со своим опытом и сможет ли не перейти на темную сторону упоротых девелоперов, пройдя этапы собеседования.
Конечно же я знаю множество инженеров, кто найдёт миллионов доводов, что собеседование неправильное, не верное, вопросы говно, файл тупорылый, такое не надо спрашивать и многое другое.
Да всё возможно.
Однако тут нанимал я, а не кто-то другой, так что козырь самодура🤡 интервьюера был у меня в руках.
Сейчас подобные наработки я использую, чтобы гонять своих интернов на логику и получения опыта без хлебания половника подливы говна из клоунско-птушных легаси проектов с монорепой монолитом.
#собеседование #интервью #всратость #docker
👍9👌1
Перетащил на второй гравитрон пару старых кластеров.
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).
#AWS #CostOptimization
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).
#AWS #CostOptimization
👍7
Использовать CloudWatch Alerts это достаточная большая боль, если мы говорим про IaC.
Неблагодарная задача.
Нет нормальной поддержки циклов, автодискавери и фильтрации.
* все примеры ниже без модулей, без костылей, без новой графаны, чистый терраформ и ямлописаки
Например у вас есть AWS Redis.
Банально с одним шардом для двух нод вам надо сделать буквально следующее:
Это лишь один шард, всего две ноды.
Помножить на существующие 4 кластера + 3 окружения итого у нас сотни строчек.
Потом это улетает в SNS, там, скорее всего на Lambda, оттуда скрипты питона на ваш Slack.
Прямо скажем неудобно.
Могу предложить решение лучше:
если у вас используется Alertmanager и AWS EKS(Kubernetes), то заметно удобнее держать его там.
Установка клаудвоч экспортера(разово):
Конфиг клаудвоч экспортёра:
В данном примере показаны различные вариации использования.
Так же научите(разово) собирать метрики от вашего прометиуса/виктории метрикс
#AWS
Неблагодарная задача.
Нет нормальной поддержки циклов, автодискавери и фильтрации.
* все примеры ниже без модулей, без костылей, без новой графаны, чистый терраформ и ямлописаки
Например у вас есть AWS Redis.
Банально с одним шардом для двух нод вам надо сделать буквально следующее:
# Alarm for Primary Node
resource "aws_cloudwatch_metric_alarm" "redis_cpu_primary" {
alarm_name = "${var.project_prefix}-${var.environment}-redis-cpu-primary"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "300"
metric_name = "CPUUtilization"
namespace = "AWS/ElastiCache"
period = "60"
statistic = "Average"
threshold = "80"
alarm_description = "Redis CPU utilization is too high on primary node"
alarm_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
ok_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
dimensions = {
CacheClusterId = "${aws_elasticache_replication_group.******.id}-001"
}
}
# Alarm for Replica Node
resource "aws_cloudwatch_metric_alarm" "redis_cpu_replica" {
alarm_name = "${var.project_prefix}-${var.environment}-redis-cpu-replica"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = "300"
metric_name = "CPUUtilization"
namespace = "AWS/ElastiCache"
period = "60"
statistic = "Average"
threshold = "80"
alarm_description = "Redis CPU utilization is too high on replica node"
alarm_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
ok_actions = ["arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-health-notification"]
dimensions = {
CacheClusterId = "${aws_elasticache_replication_group.******.id}-002"
}
}
Это лишь один шард, всего две ноды.
Помножить на существующие 4 кластера + 3 окружения итого у нас сотни строчек.
Потом это улетает в SNS, там, скорее всего на Lambda, оттуда скрипты питона на ваш Slack.
Прямо скажем неудобно.
Могу предложить решение лучше:
если у вас используется Alertmanager и AWS EKS(Kubernetes), то заметно удобнее держать его там.
Установка клаудвоч экспортера(разово):
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm upgrade cloudwatch-exporter prometheus-community/prometheus-cloudwatch-exporter \
--install \
--version 0.25.0 \
--namespace monitoring \
--set aws.aws_access_key_id="${{ secrets.AWS_ACCESS_KEY_ID }}" \
--set aws.aws_secret_access_key="${{ secrets.AWS_SECRET_ACCESS_KEY }}" \
--values=EKS/cloudwatch-values.yaml
Конфиг клаудвоч экспортёра:
config: |-
region: us-east-1
period_seconds: 30
delay_seconds: 30
metrics:
- aws_namespace: AWS/RDS
aws_metric_name: CPUUtilization
aws_dimensions: [DBInstanceIdentifier]
aws_dimension_select_regex:
DBInstanceIdentifier: [".*production.*"]
aws_statistics: [Average]
- aws_namespace: AWS/SQS
aws_metric_name: ApproximateNumberOfMessagesVisible
aws_dimensions: [QueueName]
aws_dimension_select_regex:
QueueName: [".*production.*"]
aws_statistics: [Sum]
- aws_namespace: AWS/ES
aws_metric_name: FreeStorageSpace
period_seconds: 60
aws_dimensions: [DomainName, ClientId, NodeId]
aws_statistics: [Minimum]
- aws_namespace: AWS/ElastiCache
aws_metric_name: CPUUtilization
period_seconds: 60
aws_dimensions: [CacheClusterId]
aws_statistics: [Average]
В данном примере показаны различные вариации использования.
Так же научите(разово) собирать метрики от вашего прометиуса/виктории метрикс
- job_name: 'cloudwatch-exporter'
scrape_interval: 30s
static_configs:
- targets: ['cloudwatch-exporter-prometheus-cloudwatch-exporter.monitoring.svc.cluster.local:9106']
#AWS
✍1
Всё, метрики от клаудвоча в вашем прометиусе.
Можете создавать любые алёрты.
Например вот так для редиса:
или для RDS:
❤️Profit!
Всё! Больше ничего делать не надо!
Сколько бы вы потом не создали сотен и тысяч SQS/Redis/RDS - вам не надо для каждого из них писать отдельный алёрт!
То есть мы ну вообще никак не завязаны на конкретных инстансах или нодах!
Просто один раз установка экспортёра, один раз внести сбор метрик для прометиуса(если нет автодискавери) и добавить демешны/фильтры.
⚠️ВАЖНО
Важно понимать, что каждый запрос от клаудвоч экспортёра до клаудвоча это деньги.
- нужно собирать метрики не часто, чтобы не чарджить в большую сумму
- можно фильтровать(в конфиге пример с production)
- нужно собирать ровно то, что вам нужно, например только cpu usage average, min/max нам для самого алёрта не надо
- тайминги надо выставить для вас - чтобы не очень часто, чтобы много платить, но чтобы и не слишком редко - тогда вы будете поздно получать алёрты
#AWS
Можете создавать любые алёрты.
Например вот так для редиса:
- alert: REDIS_HIGH_CPU_USAGE
expr: aws_elasticache_cpuutilization_average > 80
for: 5m
labels:
severity: critical
emoji: 🔥
annotations:
summary: '`{{ $labels.cacheclusterid }}` is using {{ $value }}% of CPU. <https://****.grafana-workspace.us-east-1.amazonaws.com/d/AWSERedis/aws-elasticache-redis?var-cacheclusterid={{ $labels.cacheclusterid }}|Dashboard> | <https://****.pagerduty.com/incidents|PD>'
или для RDS:
- alert: RDS_HIGH_CPU_USAGE
expr: round(avg_over_time(aws_rds_cpuutilization_average[5m]), 0.01) > 80
for: 5m
labels:
severity: critical
emoji: 🔥
annotations:
summary: '`{{ $labels.dbinstance_identifier }}` is using {{ $value }}% of CPU. <https://****.grafana-workspace.us-east-1.amazonaws.com/d/AWSRDSdbi/aws-rds?var-dbinstanceidentifier={{ $labels.dbinstance_identifier }}|Dashboard> | <https://***.pagerduty.com/incidents|PD>'
❤️Profit!
Всё! Больше ничего делать не надо!
Сколько бы вы потом не создали сотен и тысяч SQS/Redis/RDS - вам не надо для каждого из них писать отдельный алёрт!
То есть мы ну вообще никак не завязаны на конкретных инстансах или нодах!
Просто один раз установка экспортёра, один раз внести сбор метрик для прометиуса(если нет автодискавери) и добавить демешны/фильтры.
⚠️ВАЖНО
Важно понимать, что каждый запрос от клаудвоч экспортёра до клаудвоча это деньги.
- нужно собирать метрики не часто, чтобы не чарджить в большую сумму
- можно фильтровать(в конфиге пример с production)
- нужно собирать ровно то, что вам нужно, например только cpu usage average, min/max нам для самого алёрта не надо
- тайминги надо выставить для вас - чтобы не очень часто, чтобы много платить, но чтобы и не слишком редко - тогда вы будете поздно получать алёрты
#AWS
🤩2
Почти год назад я ввязался в поддержку одного небольшого проекта.
Признаюсь и я, и команда из этого проекта были откровенно слабыми.
Я категорически слабо разбирался в базах данных, тюнинге, а на проекте никто не понимал что происходит.
База "тупила", клиенты были недовольны, никто не понимал куда копать.
Мы, словно угля в топку, накидывали неделя за неделей ресурсами всё выше и выше, лишь бы поезд ехал, но все понимали, что рано или поздно мы упрёмся в максимум типа инстанса и поезд остановится.
Откровенно говоря я даже не понимал как вот это всё работает, замучав всех в русскоязычных чатах глупыми вопросами по БД перформансу.
Так или иначе я пришёл к мнению, что надо внедрять мониторинг и алёртинг базы данных.
- Мы научились готовить PMM(расширенный бесплатный аналог AWS Performance Insights).
Он нам показал исторически на графиках куча мест, где у нас было сделано не оптимально(селекты, делиты и так далее).
- Мы научились мониторить стандартные метрики БД.
CPU usage, memory free/usage и другие системные ресурсы.
- Этого было мало, мы научились мониторить и алёртить сложные запросы.
Мне пришлось нырнуть дальше и у нас появились борды с MySQL slow query и алёртинг на их.
На правах внезапного репоста этого блога продублирую ссылку на свою статью, как мониторить/алёртить
https://medium.com/@kruchkov.alexandr/monitoring-and-alerting-for-slow-logs-in-amazon-rds-12dd048e16db
* Помню, что медиум это для многих неудобно, но я уже не вспомню зачем я публикую заметки именно там.
#AWS #RDS
Признаюсь и я, и команда из этого проекта были откровенно слабыми.
Я категорически слабо разбирался в базах данных, тюнинге, а на проекте никто не понимал что происходит.
База "тупила", клиенты были недовольны, никто не понимал куда копать.
Мы, словно угля в топку, накидывали неделя за неделей ресурсами всё выше и выше, лишь бы поезд ехал, но все понимали, что рано или поздно мы упрёмся в максимум типа инстанса и поезд остановится.
Откровенно говоря я даже не понимал как вот это всё работает, замучав всех в русскоязычных чатах глупыми вопросами по БД перформансу.
Так или иначе я пришёл к мнению, что надо внедрять мониторинг и алёртинг базы данных.
- Мы научились готовить PMM(расширенный бесплатный аналог AWS Performance Insights).
Он нам показал исторически на графиках куча мест, где у нас было сделано не оптимально(селекты, делиты и так далее).
- Мы научились мониторить стандартные метрики БД.
CPU usage, memory free/usage и другие системные ресурсы.
- Этого было мало, мы научились мониторить и алёртить сложные запросы.
Мне пришлось нырнуть дальше и у нас появились борды с MySQL slow query и алёртинг на их.
На правах внезапного репоста этого блога продублирую ссылку на свою статью, как мониторить/алёртить
AWS RDS slow logs (8.0.mysql_aurora.3.06.0), которую я писал в 2024 году.https://medium.com/@kruchkov.alexandr/monitoring-and-alerting-for-slow-logs-in-amazon-rds-12dd048e16db
* Помню, что медиум это для многих неудобно, но я уже не вспомню зачем я публикую заметки именно там.
#AWS #RDS
🔥5👍1
Сейчас на этом проекте всё работает как часы, инстансы совсем не жирные, а у разработчиков даже есть дашборда, куда они бегут, получив алёрты (их несколько разных).
Получив алёрт, ребята самостоятельно анализируют запросы, которые роняют базу и тут же пилят пулл-реквесты с безжалостным выпиливанием таких косяков. Поезд едет дальше.
#AWS #RDS #MySQL
Получив алёрт, ребята самостоятельно анализируют запросы, которые роняют базу и тут же пилят пулл-реквесты с безжалостным выпиливанием таких косяков. Поезд едет дальше.
#AWS #RDS #MySQL
🔥5❤3👍1
Для последнего проекта для AWS EKS использовал AMI на базе
https://aws.amazon.com/bottlerocket/
Название амишки и версию в голове и коде не держу, смелости и дурости у меня много, так что у меня идёт latest (на самом деле там почти хардкод, просто выглядит пугающе). Сбоев не было никогда из-за последнего в ssm.
С точки зрения кода там просто:
Если пугает такое обновление версий, то можно залепить такое и обновлять раз в месяц/квартал вручную.
Стратегий у меня несколько:
- event-driven
- load-driven
Ноды готовы очень быстро. При тюнинге в основном секунд 15.
В самых худших кейсах 2 минут 24 секунды. Такое было раз 5 по наблюдениям.
Зависит от типа инстанса, региона и спот ли.
Например типичный сценарий. Есть сервис в десятках подов, кто читает SQS. Они разные и цели у них разные.
- всего 2 ноды, 0 подов с без рабочей нагрузки.
- прилетели тонны мессаджей в AWS SQS, секунд за 5-15 на бурст в 100000+ сообщений
- KEDA через 5 секунд после threshold поднимается пару десятков подов
- кластер-автоскейлер/карпентер (зависит от проекта) поднимает одну или несколько нод в нод группу.
* Кластер автоскейлер мгновенно триггерит, если видит, что не хватает ресурсов и хоть что-то в
- сами ноды на ботлрокете поднимаются секунд за 12-15, каждая из нод. то есть через 15 секунд в основном уже
- поды на новых нодах шедулятся, проходят 2 пробы(startup, readiness), ещё 8-15 секунд.
- приложение готово к работе и разбирает мессаджи в sqs (+20 секунд к таймингам, если на этой SQS long polling)
- после разбора sqs всё тушится к нулям через KEDA, чтобы не платить
Ради теста повторил, лог такой:
Как видно ноды очень быстро стартуют. Это самый главный плюс.
Почему
- крайне быстрый старт нод, основная причина
- чуть более удобная(для меня) кастомизация kubelet, хоть там и не любимый мной TOML
- ну а как же без пункта best-CV-project, надо и новые вещи изучать
#AWS #EKS #bottlerocket
bottlerocket.https://aws.amazon.com/bottlerocket/
Название амишки и версию в голове и коде не держу, смелости и дурости у меня много, так что у меня идёт latest (на самом деле там почти хардкод, просто выглядит пугающе). Сбоев не было никогда из-за последнего в ssm.
С точки зрения кода там просто:
locals {
aws_ami_name = "bottlerocket"
aws_ami_architecture = "x86_64"
aws_ami_type = "${upper(local.aws_ami_name)}_${local.aws_ami_architecture}"
}
data "aws_ssm_parameter" "eks_ami_image_version" {
name = "/aws/service/${local.aws_ami_name}/aws-k8s-${aws_eks_cluster.eks.version}/${local.aws_ami_architecture}/latest/image_version"
}
resource "aws_eks_node_group" "blue-green-group" {
...
ami_type = local.aws_ami_type
release_version = data.aws_ssm_parameter.eks_ami_image_version.value
...Если пугает такое обновление версий, то можно залепить такое и обновлять раз в месяц/квартал вручную.
lifecycle {
ignore_changes = [release_version]
...
}Стратегий у меня несколько:
- event-driven
- load-driven
Ноды готовы очень быстро. При тюнинге в основном секунд 15.
В самых худших кейсах 2 минут 24 секунды. Такое было раз 5 по наблюдениям.
Зависит от типа инстанса, региона и спот ли.
Например типичный сценарий. Есть сервис в десятках подов, кто читает SQS. Они разные и цели у них разные.
- всего 2 ноды, 0 подов с без рабочей нагрузки.
- прилетели тонны мессаджей в AWS SQS, секунд за 5-15 на бурст в 100000+ сообщений
- KEDA через 5 секунд после threshold поднимается пару десятков подов
- кластер-автоскейлер/карпентер (зависит от проекта) поднимает одну или несколько нод в нод группу.
* Кластер автоскейлер мгновенно триггерит, если видит, что не хватает ресурсов и хоть что-то в
Pending статусе из POD-ов- сами ноды на ботлрокете поднимаются секунд за 12-15, каждая из нод. то есть через 15 секунд в основном уже
ready.- поды на новых нодах шедулятся, проходят 2 пробы(startup, readiness), ещё 8-15 секунд.
- приложение готово к работе и разбирает мессаджи в sqs (+20 секунд к таймингам, если на этой SQS long polling)
- после разбора sqs всё тушится к нулям через KEDA, чтобы не платить
Ради теста повторил, лог такой:
ip-10-1-33-89.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 1s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal NotReady <none> 10s v1.30.5-eks-baa6d11
ip-10-1-33-89.ec2.internal Ready <none> 13s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 0s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 5s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal NotReady <none> 10s v1.30.5-eks-baa6d11
ip-10-1-34-52.ec2.internal Ready <none> 14s v1.30.5-eks-baa6d11
Как видно ноды очень быстро стартуют. Это самый главный плюс.
Почему
bottlerocket:- крайне быстрый старт нод, основная причина
- чуть более удобная(для меня) кастомизация kubelet, хоть там и не любимый мной TOML
#AWS #EKS #bottlerocket
🆒3❤1
Я ещё буду писать про bottlerocket для AWS EKS и, особенно, про его тюнинг, там много любопытного.
👍10
Мне уже двое написали про
Немного теории:
В Kubernetes существует два типа эвикции (выселения) подов:
- Kubernetes сначала посылает сигнал SIGTERM поду, давая ему время корректно завершить работу
- Pod получает grace period (период отсрочки) для завершения работы
- По умолчанию grace period составляет 30 секунд
Можно настроить через параметр
- Происходит немедленное удаление пода
- Pod получает сигнал SIGKILL
- Используется когда нужно срочно освободить ресурсы
Настраивается через параметр
Основные триггеры эвикции:
-
-
-
-
Пороговые значения можно задавать как в процентах, так и в абсолютных величинах (например, 100Mi для памяти).
Дефолтные значения ванильного k8s можете посмотреть тут:
https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
Для
❕Выше была общая теория, ниже практика.
#AWS #EKS #bottlerocket
bottlerocket, так что не теряя времени, пока смелые духом не запустили это в прод, продолжу.Немного теории:
В Kubernetes существует два типа эвикции (выселения) подов:
Soft Eviction (Мягкое выселение):- Kubernetes сначала посылает сигнал SIGTERM поду, давая ему время корректно завершить работу
- Pod получает grace period (период отсрочки) для завершения работы
- По умолчанию grace period составляет 30 секунд
Можно настроить через параметр
--eviction-soft-grace-period /--eviction-softHard Eviction (Жёсткое выселение):- Происходит немедленное удаление пода
- Pod получает сигнал SIGKILL
- Используется когда нужно срочно освободить ресурсы
Настраивается через параметр
--eviction-hardОсновные триггеры эвикции:
-
memory.available: доступная память-
nodefs.available: место на диске ноды-
nodefs.inodesFree: свободные иноды-
imagefs.available: место для образов контейнеровПороговые значения можно задавать как в процентах, так и в абсолютных величинах (например, 100Mi для памяти).
Дефолтные значения ванильного k8s можете посмотреть тут:
https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
Для
AL2023 вот такие дефолт значения:memory.available: "100Mi"
nodefs.available: "10%"
nodefs.inodesFree: "5%"
imagefs.available: "15%"
❕Выше была общая теория, ниже практика.
#AWS #EKS #bottlerocket
🤔1
У
Вы это можете проверить командой на ноде
Ну или же посмотреть в конфиге:
https://github.com/bottlerocket-os/bottlerocket/blob/1.20.x/packages/kubernetes-1.29/kubelet-kubeconfig
Там пусто.
Что же это значит?
Это значит, что по дефолту если у вас:
- под(ы) с эфемерным хранилищем сожрёт все место на ноде
- под(ы) без лимитов цпу сожрёт всё процессорное время на ноде
- под(ы) без лимитов памяти сожрёт всю память на ноде
- диск заполнится имаджами под(а/ов) и гарбадж коллектор не успеет отработать
Ваша нода умрёт. Системные компоненты перестанут работать, кублету не хватит памяти и нода умрёт.
Нода не защищена от неконтролируемых действий со стороны подов.
Давайте это исправим:
- создадим темплейт/конфиг
- внутри добавим нечто типа такого
- добавить этот конфиг через юзердату
Не буду описывать все параметры, они описаны тут:
https://bottlerocket.dev/en/os/1.20.x/api/settings/kubernetes/#eviction-hard
https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#description-of-settings
Цифры можете брать из дефолта(выше писал), в моём примере цифры ровно под те требования, которые есть у меня в моим кластерам и приложениям. Не обязательно использовать все параметры, что есть в моём примере, можете только 4 параметра использовать.
* если вы хотите выдать доступ к вашим нодам, то в моем конфиге надо false поменять на true и дальше по инструкции
https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#control-container
#AWS #EKS #bottlerocket
bottlerocket нет дефолтных значений.Вы это можете проверить командой на ноде
apiclient -u /settings | jq
Ну или же посмотреть в конфиге:
https://github.com/bottlerocket-os/bottlerocket/blob/1.20.x/packages/kubernetes-1.29/kubelet-kubeconfig
Там пусто.
Что же это значит?
Это значит, что по дефолту если у вас:
- под(ы) с эфемерным хранилищем сожрёт все место на ноде
- под(ы) без лимитов цпу сожрёт всё процессорное время на ноде
- под(ы) без лимитов памяти сожрёт всю память на ноде
- диск заполнится имаджами под(а/ов) и гарбадж коллектор не успеет отработать
Ваша нода умрёт. Системные компоненты перестанут работать, кублету не хватит памяти и нода умрёт.
Нода не защищена от неконтролируемых действий со стороны подов.
Давайте это исправим:
- создадим темплейт/конфиг
bottlerocket.tpl в нашем репозитории- внутри добавим нечто типа такого
[settings.kubernetes]
api-server = "${endpoint}"
cluster-certificate = "${cluster_auth_base64}"
cluster-name = "${cluster_name}"
pod-pids-limit = 1024
image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80
container-log-max-files = 50
container-log-max-size = "100Mi"
[settings.kubernetes.system-reserved]
cpu = "200m"
ephemeral-storage = "1Gi"
memory = "1Gi"
[settings.kubernetes.kube-reserved]
memory = "893Mi"
[settings.kernel]
lockdown = "integrity"
[settings.host-containers.admin]
enabled = ${enable_admin_container}
[settings.host-containers.control]
enabled = ${enable_control_container}
[settings.kubernetes.eviction-hard]
"memory.available" = "1Gi"
"nodefs.available" = "20%"
"nodefs.inodesFree" = "5%"
"imagefs.available" = "15%"
[settings.kubernetes.eviction-soft]
"memory.available" = "10%"
[settings.kubernetes.eviction-soft-grace-period]
"memory.available" = "30s"
- добавить этот конфиг через юзердату
resource "aws_launch_template" "node-launch-template" {
...
user_data = base64encode(templatefile("${path.module}/../../templates/bottlerocket.tpl",
{
"cluster_name" = aws_eks_cluster.eks.name #обязательный параметр!!!
"endpoint" = aws_eks_cluster.eks.endpoint #обязательный параметр!!!
"cluster_auth_base64" = aws_eks_cluster.eks.certificate_authority[0].data #обязательный параметр!!!
"aws_region" = var.AWS_DEFAULT_REGION #обязательный параметр!!!
"enable_admin_container" = false
"enable_control_container" = true
}
))
}Не буду описывать все параметры, они описаны тут:
https://bottlerocket.dev/en/os/1.20.x/api/settings/kubernetes/#eviction-hard
https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#description-of-settings
Цифры можете брать из дефолта(выше писал), в моём примере цифры ровно под те требования, которые есть у меня в моим кластерам и приложениям. Не обязательно использовать все параметры, что есть в моём примере, можете только 4 параметра использовать.
* если вы хотите выдать доступ к вашим нодам, то в моем конфиге надо false поменять на true и дальше по инструкции
https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#control-container
#AWS #EKS #bottlerocket
🤩2
Коллеги запилили фронтенд сервис для инфры. Тупо страничка с ссылками на инфра ресурсы с SSO авторизацией.
На скрине объединил вид нескольких вкладок для демо.
В нем сделаны ссылки на бОльшую часть инфры по окружениям.
Оказалось очень удобно переходить по линкам, чем помнить адреса на память или держать 100500 вкладок.
Для онбординга тоже топ.
Сорс выкладывать не буду - думаю любая AI вам за 5 минут нагенерит код тайпскрипта такого решения.
Просто поделился мелким удобством идеей.
На скрине объединил вид нескольких вкладок для демо.
В нем сделаны ссылки на бОльшую часть инфры по окружениям.
Оказалось очень удобно переходить по линкам, чем помнить адреса на память или держать 100500 вкладок.
Для онбординга тоже топ.
Сорс выкладывать не буду - думаю любая AI вам за 5 минут нагенерит код тайпскрипта такого решения.
Просто поделился мелким удобством идеей.
🔥4👍1
* старый репост
"Как я проетерял полдня, но понял что не всегда свежая версия это хорошая версия..."
Утомили постоянные
#terragrunt
"Как я проетерял полдня, но понял что не всегда свежая версия это хорошая версия..."
Switched terragrunt to version "0.72.3"
time terragrunt plan
Acquiring state lock. This may take a few moments...
No changes. Your infrastructure matches the configuration.
real 0m54.200s
user 0m28.351s
sys 0m2.390s
Switched terragrunt to version "0.54.15"
time terragrunt plan
Acquiring state lock. This may take a few moments...
No changes. Your infrastructure matches the configuration.
real 0m43.498s
user 0m31.284s
sys 0m4.366s
Switched terragrunt to version "0.56.0"
time terragrunt plan
Acquiring state lock. This may take a few moments...
No changes. Your infrastructure matches the configuration.
real 3m29.356s
user 2m27.303s
sys 0m14.885s
Утомили постоянные
circular dependency hell на terragrunt, но ничего не поделать, каждые 5-15 версий это говно вылезает, приходится просто подбирать вариант "и багов немного, и время выполнения не больше 50 секунд(по "эталонному" модулю).#terragrunt
🤔2
"Вернись обратно"
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
Переключиться на предыдущий контекст Kubernetes
Переключиться на предыдущий namespace в Kubernetes
Переключиться на предыдущую ветку в git
Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
Именно такую фразу я сказал на стриме своему интерну и он, само собой, её ни черта не понял.
Да чего я выделываюсь, я бы и сам её не понял без контекста😅
Переключиться в предыдущую рабочую директорию
cd - Переключиться на предыдущий контекст Kubernetes
kubectx - Переключиться на предыдущий namespace в Kubernetes
kubens -Переключиться на предыдущую ветку в git
git checkout -Возможно есть что-то ещё c похожим поведением, но я, в основном, использую только это в работе.
#devops #очевидное #вероятное
👍10❤2
Не амазоном едины.
Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
На стеке
ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
- создавать новые
То есть через
Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics
Айти развивается очень быстро.
Каждый день появляется много новых практик, инструментов, подходов и всё новое устаревает уже через пару лет.
Индустрия не успевает сама за собой.
Давайте поговорим о метриках.
У нас есть миллионы метрик.
Для нод, для кубера, для PV, для контейнеров, виртуальных машин и даже баз данных в кубере, для приложений.
Однако мы живём в современном мире гетерогенных сетей и несовершенстве
observability.Те метрики и подходы, которые были в 2011 году, в 2019 году и, особенно, 2025 году, безнадёжно отстали и редко показывают актуальную информацию.
Пример.
для одного только
Azure у нас есть целая матрица IOPS дисков, которая зависит от размера и сторадж класса + бёрстабл мод по времени.https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#standard-ssd-size
Штатные метрики есть, но они слишком убоги и отсталые:
- сколько осталось айнод
- сколько осталось места на диске(в нашем случае PV)
Как оперативно отслеживать нет ли где в кубернетисе ситуации, когда мы упираемся в предел по IOPS дискам?
PVC у нас несколько СОТЕН и десятки кластеров.
Везде разные классы и размеры.
Вручную прописывать это бред.
Штатно метрик у нас нет.
На помощь нам приходят
records.На стеке
victoria metrics(да вообще и в прометиусе тоже на самом деле) мы легко можем создавать такую сущность как vmalert и vmrule.ВМалёрт просто берёт правила алёртов и отправляет на ручку алёртменеджера.
У vmrule есть две функции:
- создавать
rule для алёртов- создавать новые
recordsТо есть через
records мы можем создавать свои, абсолютно удобные для нас метрики со своими лейблами. Или обогащать существущие метрики новыми лейблами.
Идея тут какая была:
- делаем матчинг между разными видами метрик(у них не матчатся лейблы)
- делаем ещё раз чтобы потом можно было матчить
- создаем матрицу "тип стораджа = максимальный IOPS для него"
- выводим новую метрику "текущий IOPS"
- выводим новую метрику "коэффициент IOPS" где 0 это 0%, а 1 это 100%.
Новую метрику можно использовать как для графиков в графане, так и для алёртов.
На базе подобного подхода мы НЕ зависим какой у нас тип сторадж класса, какой у нас размер PVC и так далее.
У нас есть матчинг POD-PVC-StorageClass-IOPS и мы просто готовую метрику получаем, а калькуляция уже внутри.
Например
pvc_iops_utilization_percent = 80 говорит о том, что мы для этого кластера/неймспейса/пода упирираемся в 80% от возможностей этого диска, использующего этот тип стораджа класса.И нам не важно какой там сторадж класс. мы просто знаем, что считаеся всё внутри Victoria metrics и мы просто на выходе получаем готовую метрику с лейблами (cluster namespace po etc) и мы дальше это где угодно используем:
- графана дашборды
- алёрты
❕Важно понимать, что это пока мой около MVP, в арифметике или логике могут быть мои ошибки, опечатки, неточности и в будущем я буду планировать это анализировать и актуализировать реальным данным.
Я могу по своему не знанию чего-то не учитывать и обязательно это поправлю в будущем.
#azure #metrics #victoriametrics
👏3👍1
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMAlert
metadata:
name: ${NAME}
namespace: ${NAMESPACE}
spec:
replicaCount: 1
datasource:
url: ${URL_DATASOURCE}
notifier:
url: ${URL_NOTIFIER}
evaluationInterval: "30s"
selectAllByDefault: true
remoteWrite:
url: http://vminsert-victoria-metrics-cluster.service:8480/insert/0/prometheus/
---
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMRule
metadata:
name: vmrule-storage-iops
namespace: ${NAMESPACE}
spec:
groups:
- name: storage_monitoring
interval: 30s
rules:
- record: storage_class_iops_limits
expr: |
sum by(persistentvolume, storageclass, cluster) (
(kube_persistentvolume_info{storageclass=~"azureblob-fuse-premium|azureblob-nfs-premium"} * 15000) or
(kube_persistentvolume_info{storageclass=~"managed-premium|managed-csi-premium|managed-premium-burstable"} * 20000) or
(kube_persistentvolume_info{storageclass=~"managed|managed-csi|default"} * 6000) or
(kube_persistentvolume_info{storageclass="managed-csi-os-warm-nodes"} * 6000) or
(kube_persistentvolume_info{storageclass=~"azurefile-premium|azurefile-csi-premium|azurefile-nonroot|azurefile-sc-fips|sc-rwm"} * 100000) or
(kube_persistentvolume_info{storageclass=~"azurefile|azurefile-csi|azurefile-standart-nonroot"} * 10000) or
(kube_persistentvolume_info * 500)
)
- record: pod_pvc_info
expr: |
max by(cluster, exported_namespace, pod, persistentvolumeclaim) (
kube_pod_spec_volumes_persistentvolumeclaims_info
)
- record: pvc_storage_info
expr: |
max by(cluster, exported_namespace, persistentvolumeclaim, storageclass) (
kube_persistentvolumeclaim_info
)
- record: pvc_current_iops
expr: |
sum by(cluster, pod, namespace, persistentvolumeclaim, storageclass) (
(
rate(container_fs_reads_total{
device!~"(/dev/)?(mmcblk.p.+|nvme.+|rbd.+|vd.+|xvd.+|dm-.+|md.+|dasd.+)",
device=~"/dev/sd[b-z].*"
}[5m]) +
rate(container_fs_writes_total{
device!~"(/dev/)?(mmcblk.p.+|nvme.+|rbd.+|vd.+|xvd.+|dm-.+|md.+|dasd.+)",
device=~"/dev/sd[b-z].*"
}[5m])
)
)
* on(cluster, pod) group_left(persistentvolumeclaim, exported_namespace)
pod_pvc_info
* on(cluster, exported_namespace, persistentvolumeclaim) group_left(storageclass)
pvc_storage_info
- record: pvc_iops_utilization_percent
expr: |
sum by(cluster, namespace, pod, persistentvolumeclaim, storageclass) (pvc_current_iops)
* 100
/ on(cluster, storageclass) group_left()
max by(cluster, storageclass) (storage_class_iops_limits)
---
- alert: HighIOPSUtilization
expr: round(pvc_iops_utilization_percent) > 85
for: 40m
labels:
severity: warning
annotations:
summary: "IOPS is `{{ $value }}%` on `{{ $labels.cluster }}`/`{{ $labels.namespace }}`/`{{ $labels.pod }}`."
✍1
Ну вот и график в графане.
Максимум IOPS(из документации Ажура) и текущая нагрузка.
#azure #metrics #victoriametrics
Максимум IOPS(из документации Ажура) и текущая нагрузка.
#azure #metrics #victoriametrics
😁2👍1
Утро началось с осознания, что:
- кросс-кластер алертинг нужен иногда (и он сработал)
- частоту верещания этого, пусть и важнейшего алерта, можно уменьшить
- киверно это пздц ублюдочная хйня, уронил весь кластер. Точнее он и Харбор.
Про киверно отдельно напишу всратую стори, это просто глупо как он работает. 🙈
* Кросс-кластер алертинг это когда есть система мониторинга и алертинга и есть где-то далеко в стороне система наблюдающая за ней. И обе друг за другом. Чтобы если вообще всё упало, то было кому сообщать, что всё упало. Про него тоже отдельно напишу пост, как раз материал для шеринга 😅
- кросс-кластер алертинг нужен иногда (и он сработал)
- частоту верещания этого, пусть и важнейшего алерта, можно уменьшить
- киверно это пздц ублюдочная хйня, уронил весь кластер. Точнее он и Харбор.
Про киверно отдельно напишу всратую стори, это просто глупо как он работает. 🙈
* Кросс-кластер алертинг это когда есть система мониторинга и алертинга и есть где-то далеко в стороне система наблюдающая за ней. И обе друг за другом. Чтобы если вообще всё упало, то было кому сообщать, что всё упало. Про него тоже отдельно напишу пост, как раз материал для шеринга 😅
🔥8