Кому захочется, чтобы его продукт лежал? Мы уверены — никому не понравится открыть новости и увидеть сообщения про сбой в его компании. Бизнес хочет видеть 99,999% доступности. Но за счёт чего она достигается?

Читайте в статье от нашего эксперта, Кирилла Борисова:

Привет, я Кирилл Борисов. SRE, ночной траблшутер, инцидент-менеджер и лучший друг SLO|SLA|SLI. Спикер конференций Highload++, Devops, DevOops, ProITFest. Чиню проблемы по фотографии :)

Сегодня расскажу, какие механизмы в k8s используются, чтобы достичь высокой доступности и отказоустойчивости.

Affinity и Anti-Affinity в Kubernetes

Чтобы управлять размещением подов на узлах кластера, в Kubernetes есть механизмы affinity и anti-affinity. Они помогают оптимизировать использование ресурсов, обеспечить надежность и управлять топологией развертывания приложений.

1. Affinity

Node Affinity: Позволяет задать предпочтения для размещения подов на определенных узлах. Например, можно указать, что поды должны быть развернуты только на узлах с определенными метками.

Pod Affinity: Позволяет задать правила для размещения подов рядом с другими подами. Например, можно указать, что поды должны быть развернуты на тех же узлах, где уже работают другие поды с определенными метками.

2. Anti-Affinity:

Pod Anti-Affinity: Позволяет задать правила для предотвращения размещения подов на тех же узлах, где уже работают другие поды с определенными метками. Это помогает распределить поды по разным узлам и повысить надежность.

Применение в различных кейсах

Оптимизация ресурсов:

Node Affinity позволяет лучше использовать ресурсы узлов, направляя поды на узлы с нужными характеристиками (например, SSD диски, GPU и т.д.).

Повышение надежности и отказоустойчивости:

Pod Anti-Affinity помогает распределить поды одного приложения по разным узлам, что снижает риск единой точки отказа. Например, реплики одного сервиса могут быть развернуты на разных узлах для обеспечения доступности при сбое одного из узлов.

Управление топологией сети:

Pod Affinity может использоваться для развертывания подов в одной зоне доступности (AZ) или на близких узлах для уменьшения сетевых задержек и повышения производительности.

Примеры использования

1. Node Affinity

Пример, где поды размещаются на узлах с меткой disktype=ssd:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
```

2. Pod Affinity

Пример, где поды размещаются на тех же узлах, что и поды с меткой app=store:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: frontend
    image: nginx
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - store
        topologyKey: "kubernetes.io/hostname"
```

3. Pod Anti-Affinity

Пример, где поды не должны размещаться на тех же узлах, что и другие поды с меткой app=store:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: frontend
    image: nginx
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - store
        topologyKey: "kubernetes.io/hostname"
```

Заключение

Affinity и anti-affinity в Kubernetes — инструменты для управления размещением подов. Они помогают лучше использовать ресурсы, повышать надежность системы и обеспечить гибкость при развертывании приложений. Правильное применение этих механизмов позволяет создавать более устойчивые и производительные системы.

---

Tolerations

В Kubernetes, Tolerations — это один из механизмов, который позволяет управлять размещением подов на узлах кластера. Они используются вместе с Node Affinity и Node Selectors для достижения более гибкого и управляемого распределения подов по узлам.

 Основные понятия

Tolerations — специальные параметры, которые назначаются подам и позволяют им игнорировать определённые taints узлов. Это как «разрешение» для пода быть размещённым на узле с определенным taint.

Taints — метки, которые наносятся на узлы и служат для ограничения размещения подов. Если узел имеет taint, поды не будут размещены на этом узле, если они не имеют соответствующих Tolerations.

 В каких кейсах используются Tolerations

1. Управление ресурсами и изоляция:

Пулы узлов: В кластере могут быть узлы с различными ресурсами и предназначением. Например, можно пометить узлы с мощными CPU и GPU специальными taints и разрешить размещение на них только подов, которые требуют высокопроизводительных вычислений.

Изоляция сред: Узлы могут быть помечены для различных сред (разработка, тестирование, производство). Подам из разных сред назначаются соответствующие tolerations для обеспечения изоляции.

2. Обслуживание и обновления:

Мягкое завершение узлов: Когда узел должен быть выведен из эксплуатации для обслуживания или обновления, на него можно нанести taint. Поды с соответствующими tolerations смогут продолжать работу до завершения своих задач, а новые поды не будут размещаться на этом узле.

3. Критические сервисы:

Размещение критических подов: Для критических подов можно использовать tolerations, чтобы они размещались на узлах, которые защищены от размещения других подов. Это обеспечивает стабильность и доступность критически важных сервисов.

Примеры использования

1. Tolerations для узлов с определенными метками:

 ```yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
   spec:
     tolerations:
     - key: "key1"
       operator: "Equal"
       value: "value1"
       effect: "NoSchedule"
   ```

В этом примере под будет размещён только на узлах, у которых есть taint с ключом "key1" и значением "value1" и эффектом "NoSchedule".

2. Игнорирование всех taints с определённым эффектом:

 ```yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
   spec:
     tolerations:
     - operator: "Exists"
       effect: "NoExecute"
   ```

Этот под будет игнорировать все taints с эффектом "NoExecute", что позволяет ему оставаться на узле даже если на него наносится такой taint

3. Tolerations с временным интервалом:

 ```yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: example-pod
   spec:
     tolerations:
     - key: "key2"
       operator: "Equal"
       value: "value2"
       effect: "NoExecute"
       tolerationSeconds: 3600
   ```

Под будет размещен на узле с указанным taint и сможет оставаться на нём в течение 3600 секунд (1 час), прежде чем будет удалён.

Решаемые проблемы

Гибкое управление ресурсами: Tolerations позволяют точно контролировать, какие поды могут быть размещены на каких узлах, что обеспечивает оптимальное использование ресурсов.

Изоляция и безопасность: Можно обеспечить изоляцию подов, предотвращая их размещение на неподходящих узлах.

Упрощение обслуживания: Tolerations позволяют проводить обслуживание узлов без значительного влияния на работу критических подов.

Tolerations в Kubernetes — инструменты для управления размещением подов в кластере. Они позволяют эффективно распределять ресурсы, обеспечивать изоляцию различных сред и упрощать процессы обслуживания и обновления узлов. Правильное использование Tolerations помогает поддерживать стабильность и эффективность работы всего кластера.

---

PodDisruption Budget в Kubernetes

PodDisruption Budget (PDB) — это объект Kubernetes, который помогает поддерживать высокую доступность приложений во время плановых и неплановых операций кластера, таких как обновления или сбои узлов. PDB определяет минимальное количество работающих Pod-ов, которые должны оставаться активными в любой момент времени, что позволяет ограничить количество одновременно нарушаемых Pod-ов.

Основные концепции

Pod: Наименьшая единица развертывания в Kubernetes, которая может содержать один или несколько контейнеров.

Disruption: Плановая или неплановая операция, которая может привести к остановке или перезапуску Pod-ов.

Budget: Ограничение на количество разрешенных нарушений.

Основные компоненты PDB

minAvailable: Минимальное количество Pod-ов, которые должны оставаться доступными.

maxUnavailable: Максимальное количество Pod-ов, которые могут быть недоступны в любой момент времени.

В каких кейсах используются PDB

1. Обновления кластера: Обновление узлов или программного обеспечения Kubernetes, что может потребовать перезагрузки Pod-ов.

2. Автоматические обновления и масштабирование: Использование Deployment, StatefulSet или DaemonSet для автоматического обновления или масштабирования Pod-ов.

3. Ремонт и замена узлов: Периодическое техническое обслуживание или замена физических или виртуальных узлов.

4. Резервирование ресурсов: Обеспечение наличия достаточного количества Pod-ов для обработки трафика или выполнения задач, даже во время непредвиденных сбоев.

Проблемы, которые помогает решить PDB

Обеспечение доступности: PDB помогает поддерживать доступность приложения, ограничивая количество одновременно нарушаемых Pod-ов.

Управление обновлениями: Обновления кластера и приложений могут быть выполнены безопасно, не вызывая значительных простоев.

Повышение надежности: Гарантия того, что критически важные сервисы останутся работоспособными даже при сбоях.

 Примеры использования PDB

1. Создание PDB для Deployment

 ```yaml
    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: my-app-pdb
    spec:
      minAvailable: 2
      selector:
        matchLabels:
          app: my-app
    ```

В этом примере PDB определяет, что всегда должно быть как минимум 2 доступных Pod-а с меткой app: my-app.

2. Использование PDB с maxUnavailable

В данном случае PDB указывает, что одновременно может быть недоступен только один Pod с меткой app: my-app.

3. PDB для StatefulSet

```yaml
    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: my-statefulset-pdb
    spec:
      minAvailable: 3
      selector:
        matchLabels:
          app: my-statefulset
    ```

Для StatefulSet PDB гарантирует, что минимум 3 Pod-а будут оставаться доступными, что особенно важно для приложений, требующих постоянного состояния.

PodDisruption Budget — это важный инструмент для управления доступностью и надежностью приложений в Kubernetes. Он позволяет администраторам кластера выполнять плановые операции и масштабировать приложения без значительных простоев, что особенно критично для высоконагруженных и критически важных сервисов. Использование PDB способствует более стабильной и предсказуемой работе кластера. 

---

Horizontal Pod Autoscaler 

Horizontal Pod Autoscaler (HPA) является важным компонентом в Kubernetes, который автоматизирует процесс масштабирования подов (pods) на основе использования ресурсов (CPU, памяти и пользовательских метрик). HPA помогает динамически адаптировать количество реплик подов, что позволяет приложениям оставаться стабильными и эффективными при изменении нагрузки.

В каких кейсах используется HPA

1. Веб-приложения:

   • Проблема: Веб-приложения часто сталкиваются с непредсказуемыми всплесками трафика.

   • Решение HPA: Автоматическое увеличение количества подов при повышении нагрузки и уменьшение при снижении трафика помогает поддерживать производительность и снизить затраты.

2. Обработка данных в реальном времени:

   • Проблема: Сервисы обработки данных могут испытывать внезапное увеличение объема данных для обработки.

   • Решение HPA: HPA может автоматически масштабировать количество подов для обработки данных, чтобы справиться с изменениями объема данных в реальном времени.

3. Фоновые задачи и очереди сообщений:

   • Проблема: Обработка фоновых задач и очередей сообщений может быть нерегулярной и зависеть от времени суток или событий.

   • Решение HPA: Масштабирование подов в зависимости от длины очереди или других пользовательских метрик позволяет обеспечить своевременную обработку задач.

Проблемы, которые решает HPA

1. Автоматическое масштабирование:

   • HPA позволяет автоматизировать процесс масштабирования подов, что устраняет необходимость ручного вмешательства и уменьшает вероятность ошибок.

2. Оптимизация использования ресурсов:

   • HPA помогает оптимизировать использование ресурсов, поддерживая необходимое количество подов в зависимости от текущей нагрузки, что снижает затраты на инфраструктуру.

3. Обеспечение стабильности и высокой доступности:

   • Динамическое масштабирование помогает предотвратить перегрузки и падение приложений, поддерживая их стабильность и доступность.

Примеры использования HPA

Масштабирование на основе использования CPU:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Этот пример конфигурации HPA масштабирует поды в Deployment example-deployment в зависимости от использования CPU. Когда среднее использование CPU превышает 50%, количество подов увеличивается, и наоборот.

Масштабирование на основе пользовательских метрик:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: custom-metrics-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: custom-metrics-deployment
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods
    pods:
      metric:
        name: queue_length
      target:
        type: AverageValue
        averageValue: 30

В этом примере HPA масштабирует поды в зависимости от пользовательской метрики queue_length. Когда среднее значение метрики превышает 30, количество подов увеличивается.

Horizontal Pod Autoscaler — инструмент, который помогает обеспечивать адаптивное масштабирование приложений в зависимости от текущих потребностей. Использование HPA позволяет оптимизировать использование ресурсов, повысить стабильность и доступность приложений, а также уменьшить эксплуатационные затраты. Примеры конфигурации HPA демонстрируют его гибкость и возможность адаптации под различные сценарии использования, что делает его незаменимым инструментом для современных облачных приложений.

Как-то так!

Hidden text

А если вы хотите разобраться глубже в кубах и других тонкостях их настройки — до 7 июля ещё можно присоединиться к потоку нашего курса «Kubernetes Мега». 5 недель обучения и сертификация по итогам. Программа и детали — по ссылке.