Рековери с к8с и дрейфа руля

Мы используем helm для управления всеми нашими ресурсами в кластере k8s. Недавно у нас был инцидент, когда некоторые ресурсы k8s были изменены вне helm (подробнее о первопричине см. ниже).

Однако конечным результатом является то, что у нас есть некоторые ресурсы k8s в нашем кластере, которые не соответствуют тому, что указано в диаграмме управления выпуска.

Пример:

У нас есть диаграмма руля, которая содержит HorizontalPodAutoscaler. Если я сделаю что-то вроде:

helm get myservice-release

Я увижу что-то вроде этого:

---
# Source: myservice/charts/default-deployment/templates/default_deployment.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: myservice-autoscaler
  labels:     
    app: myservice
spec:
  minReplicas: 2
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myservice-deployment
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 85

Однако, если я сделаю:

kubectl get hpa myservice-autoscaler -o yaml

spec.{max,min}Replicas не соответствует таблице:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/conditions: '{REDACTED}'
    autoscaling.alpha.kubernetes.io/current-metrics: '{REDACTED}'
  creationTimestamp: "{REDACTED}"
  labels:
    app: myservice
  name: myservice-autoscaler
  namespace: default
  resourceVersion: "174526833"
  selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/myservice-autoscaler
  uid: {REDACTED}
spec:
  maxReplicas: 1
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myservice-deployment
  targetCPUUtilizationPercentage: 85
status:
  currentCPUUtilizationPercentage: 9
  currentReplicas: 1
  desiredReplicas: 1
  lastScaleTime: "{REACTED}"

Я подозреваю, что в ресурсах k8s есть более чем один случай дрейфа.

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

Обновлено:

Для тех из вас, кто заинтересован, это было вызвано двумя диаграммами helm, управляющими одними и теми же ресурсами (автомасштабирование), которые устанавливают разные значения.

Это произошло из-за того, что два выпуска Helm, предназначенные для разных пространств имен, оказались в одном и том же и были обновлены с помощью --force.

Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
5
0
499
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Вы можете проверить, сколько ревизий для текущей версии доступно, а затем получить значения из каждой ревизии.

Выполните helm get values --revision int32 RELEASE_NAME, чтобы оценить различия.

Пожалуйста, дайте мне знать, если это помогло.

Спасибо за идею. Это на самом деле заставило меня обнаружить основную причину дрейфа (обновленное описание выше). В конечном итоге мы выбрали kubectl diff, чтобы почувствовать дрейф.

themarex 29.07.2019 13:41
Ответ принят как подходящий

Мы нашли способ сделать это масштабируемым способом. Обратите внимание, что для этого решения требуется Kubernetes 1.13 для поддержки kubectl diff.

Общая идея состоит в том, чтобы получить состояние руля и применить его с помощью kubectl, чтобы снова синхронизировать их. Это может быть небезопасно в вашем кластере, проверьте изменения с помощью kubectl diff.

  1. Получить состояние от руля: helm get manifest {service}-release > {service}-release.yaml

  2. Проверьте, есть ли разница с объектами k8s: kubectl diff -f {service}-release.yaml

  3. Перезапишите состояние k8s состоянием руля: kubectl apply -f {service}-release.yaml

Другие вопросы по теме