Immutable-инфраструктура и ее преимущества

3. Упрощение конфигурации. Не нужно помнить, что и на какой машине установлено, если есть готовый образ, из которого она создана, со своим описанием в виде файла конфигурации.

4. Благодаря согласованной конфигурации машин проще выкатывать обновления и тестировать новые версии.

5. Инстансы с одним и тем же приложением одинаковы.

Если использовать практики infrastructure as a code и идемпотентность, то эти пункты можно реализовать на изменяемой инфраструктуре.

Immutable-инфраструктура и ее преимущества

1. Возможность версионирования.

a. Можно отследить, в каком из обновлений возникла ошибка.

2. Конфигурационные файлы выступают в качестве документации состояния инфраструктуры. 

Вы это можете делать и с изменяемой инфраструктурой.

Immutable-инфраструктура и ее преимущества

1. Отсутствие документации версий инфраструктуры, трудно отследить проблемы, которые могли возникнуть из-за выкатки новой версии.

Это применимо как изменяемой так и к неизменяемой инфраструктуре.

Immutable-инфраструктура и ее преимущества

Спасибо за пост. Как связано понимание этих концепции и что любой инструмент может перестать быть опенсорсом? Скорее эти фразу стоило разделить на 2 предложения.

Kubernetes в Тензоре

Спасибо за интересный пост.

Встроенный в Cilium механизм BGP не поддерживает BFD.

Не делали issue?

Для реализации выбрали Kyverno.  Дополнительно написали GUI.

Планируете ли выложить в open source?

При развёртывании Deployment, StatefulSet и подобных ресурсов "автоматом" создаём для них VPA-ресурс в режиме рекомендаций. Для удобной визуализации разработали GUI.

Планируете ли выложить в open source?

Через DaemonSet запускаем Core Dump Handler на всех нодах. Он собирает дампы и закидывает их в S3-хранилище, а триггер уведомляет об этом эксплуатацию. Его мы немного пропатчили.

Планируете ли отправить PR с исправлением?

Вышел Linux 6.5

В https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5 и в https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13 можно найти коммит с названием "drm/amdgpu: Fix desktop freezed after gpu-reset"

Пишут что в https://launchpad.net/ubuntu/+source/linux/6.2.0-25.25 это исправлено: "drm/amdgpu: Fix desktop freezed after gpu-reset". Я как выставил параметры ядра в Grub, так и не убирал их, поэтому не знаю исправили ли они проблему или нет.

Появился репозиторий с новыми версиями ядра Linux для Debian и Ubuntu

Попробуйте добавить  amdgpu.dcdebugmask=0x10 in /etc/default/grub:

...
GRUB_CMDLINE_LINUX="... amdgpu.dcdebugmask=0x10"
...

Возможно вам помогут другие параметры ядра. Мои параметры:

GRUB_CMDLINE_LINUX_DEFAULT="initcall_blacklist=acpi_cpufreq_init amd_pstate=passive amd_pstate.shared_mem=1 amdgpu.noretry=0 amdgpu.dcdebugmask=0x10"

Обсуждение issue здесь: https://gitlab.freedesktop.org/drm/amd/-/issues/2443

Исправлено в Linux Kernel 6.5-rc1

11 полезных плагинов для kubectl

А можете подробнее рассказать про "Этот плагин обнаруживает проблемы и потенциальные уязвимости в вашем конфигурационном файле Kubernetes и предлагает рекомендации по исправлению." у kubepug?

Я не нашел этого у них https://github.com/rikatz/kubepug

Как создавать Kubernetes секреты из Vault, используя external-secrets-operator

Да, вы правы. Kubernetes auth позволяет использовать short-lived token, что выглядит безопаснее. Мое мнение что app-role проще, чем Kubernetes auth.

Как создавать Kubernetes секреты из Vault, используя external-secrets-operator

В pod можно использовать секрет вот так

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      optional: true

Источник примера https://kubernetes.io/docs/concepts/configuration/secret/

15 лет «Фланта»: переход от сервисной компании к продуктовой, покупка внешнего продукта, вера в Open Source

Есть сравнение Mimir и Victoriametrics - https://victoriametrics.com/blog/mimir-benchmark/

Резюме
В этом бенчмарке было два раунда тестов.

В первом раунде Miami и Victoria Metrics работали с одинаковой нагрузкой и на одном и том же оборудовании. Контрольными результатами были следующие:

• VictoriaMetrics использует на 1,7 процессора меньше при той же рабочей нагрузке;

• VictoriaMetrics использует в 5 раз меньше оперативной памяти для того же количества активных серий;

• VictoriaMetrics использует в 3 раза меньше места для хранения данных, собранных в течение 24 часов во время тестирования.
  

Во втором раунде нагрузка была увеличена в 5 раз с использованием того же оборудования. У Mimir было недостаточно ресурсов, чтобы справиться с нагрузкой, поэтому была доступна только статистика VictoriaMetrics.

Логировали, логировали, да вылогировали. Почему мы сменили EBK на Loki

Вышел первый релиз VictoriaLogs - https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v0.1.0-victorialogs

Docs: https://docs.victoriametrics.com/VictoriaLogs/
Helm Chart: https://github.com/VictoriaMetrics/helm-charts/tree/master/charts/victoria-logs-single

Так же подготовили Benchmark for VictoriaLogs, взять можно из https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/deployment/logs-benchmark

Bug report + feature request ждём в https://github.com/VictoriaMetrics/VictoriaMetrics/issues/new

Логировали, логировали, да вылогировали. Почему мы сменили EBK на Loki

Спасибо за пост. Жаль, что в статье довольно мало технических деталей.

Логировали, логировали, да вылогировали. Почему мы сменили EBK на Loki

Чат по Loki в telegram https://t.me/ru_loki

Infrastructure as a Code: ожидания и реальность

Книгу я читал. Я спрашивал именно про инфраструктурный код (terraform hcl, kubernetes yaml). И в этой главе не написано что "SRE 50% времени пишут инфраструктурный код (terraform hcl, kubernetes yaml)". Процитируйте, предложение из этой главы где это написано.

Infrastructure as a Code: ожидания и реальность

Нет там утверждения что SRE 50% времени пишут инфраструктурный код. Там 50 % людей обычные разработчики, а 50 % людей разработчики, которые знают UNIX и сеть.

Главное в подходе Google к управлению сервисами — принцип формирования
SRE-команд. Всех сотрудников SRE можно разделить на две основные категории:
50–60 % SR-инженеров — это разработчики Google или, если быть более точным,
люди, которые были наняты по стандартной процедуре найма разработчиков
Google; остальные 40–50 % — это те, кто имеет практически полную квалифи-
кацию разработчика (например, 85–99 % требуемых навыков) и дополнительно
владеет навыками, полезными для SRE, которые редко встречаются у разработчи-
ков. В данный момент мы чаще всего обращаем внимание на знание систем UNIX
и работу с сетями (с первого по третий уровень модели OSI).

Infrastructure as a Code: ожидания и реальность

Спасибо за пост. А где написано что SRE 50% времени пишут инфраструктурный код (terraform hcl, kubernetes yaml) ?

Коварство метрик памяти Kubernetes (и cgroups)

@lexore Спасибо за пост. Я пытаюсь найти информацию. Может вы подскажите. Как правильно высчитать сколько выставлять request cpu/memory для pod в k8s ? Выставлять значения, которые pod потребляет через 5 минут после старта? Или выставлять request cpu/memory средния в течение дня значения?

Управлять инструментом, который управляет всем: наш путь к GitOps

Спасибо за пост.

Я пришел в Dynatech из компании, где Weave Flux использовался во всех кластерах Kubernetes. Здесь также применялся этот оператор, но управлялся через него минимальный процент конфигурации. Стало очевидно, что для улучшения процессов нужно переходить к GitOps. 

Но ведь Flux это GitOps: https://www.weave.works/oss/flux/ - Flux provides GitOps for both apps and infrastructure

О том, как я сломал Ubuntu и убил день на то, чтобы починить

Какая версия Ubuntu? Сделали issue?