Облако и инфраструктура

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

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

После масштабирования веб-сервиса пользовательская сессия начинает пропадать при каждом втором запросе. Какой механизм маршрутизации мог породить такое поведение?

Ситуация: множество экземпляров сервиса не может открыть новые исходящие соединения через NAT-шлюз, хотя целевые узлы доступны. Какой механизм может исчерпать ресурс NAT?

В конфигурации StatefulSet реплика с индексом 0 не становится Ready, поэтому остальные реплики не появляются. Как параметр управления подами объясняет это поведение?

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: worker
spec:
  serviceName: worker
  replicas: 3
  podManagementPolicy: OrderedReady
  selector:
    matchLabels:
      app: worker
  template:
    metadata:
      labels:
        app: worker
    spec:
      containers:
        - name: worker
          image: example/worker:1.0
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

После удаления объекта Deployment его ReplicaSet и поды исчезают не сразу, но в итоге удаляются автоматически. Какой механизм Kubernetes обеспечивает эту цепочку удаления?

В облачном аккаунте пользователю одновременно назначили разрешение на чтение бакета и явный запрет для этого же действия. Как система IAM принимает итоговое решение?

Часть подов продолжает обращаться к старому IP после смены записи DNS. Какой механизм объясняет такое поведение?

Разберите ситуацию: новый под остаётся в Pending, хотя на узле нет свободной памяти, но его приоритет выше уже работающих подов. Как механизм вытеснения позволяет планировщику разместить его?

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical
value: 100000
preemptionPolicy: PreemptLowerPriority
---
apiVersion: v1
kind: Pod
metadata:
  name: payments
spec:
  priorityClassName: critical
  containers:
    - name: app
      image: example/payments:2.0
      resources:
        requests:
          memory: 2Gi

У нескольких реплик контроллера есть общая задача, которую одновременно должна выполнять только одна. Как механизм распределённого лидерства предотвращает параллельное выполнение этой задачи?