Не так давно писал про то как мы накручивали отказоустойчивость у Grafana
И там мы использовали affinity rules
В k8s есть множество различных возможностей для управления тем как поды будут размещены внутри кластера
К примеру, у нас есть 3 зоны доступности A,B,D (особенно внимательные наверняка увидели Yandex Cloud) и нам нужно сделать так что бы 3 пода "разъехались" гарантированно по трем разным зонам, при этом если одна зона не доступна под не мигрировал в другую
Зачем - кейс с blackbox экспортером и мониторингом каких то "внешних" ресурсов из разных зон доступности, дублировать проверки из одной и той же зоны мы не хотим
Для решения этой задачи нам прекрасно подойдет Pod Topology Spread Constraints
Доп конфигурация для официального helm чарта может выглядеть следующим образом:
replicas: 3
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/name: prometheus-blackbox-exporter
Что произойдет:
-- мы поставили 3 реплики
-- поды разъедутся по одному в каждую зону
-- если какая то зона отвалится, под будет висеть в статусе Pending
Благодаря этому поды разъезжаются по разным зонам, в случае тотального падения зоны под не переезжает в доступную зону и метрики не дублируются =)