Мы используем 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
.
Вы можете проверить, сколько ревизий для текущей версии доступно, а затем получить значения из каждой ревизии.
Выполните helm get values --revision int32 RELEASE_NAME
, чтобы оценить различия.
Пожалуйста, дайте мне знать, если это помогло.
Мы нашли способ сделать это масштабируемым способом. Обратите внимание, что для этого решения требуется Kubernetes 1.13 для поддержки kubectl diff
.
Общая идея состоит в том, чтобы получить состояние руля и применить его с помощью kubectl
, чтобы снова синхронизировать их. Это может быть небезопасно в вашем кластере, проверьте изменения с помощью kubectl diff
.
Получить состояние от руля: helm get manifest {service}-release > {service}-release.yaml
Проверьте, есть ли разница с объектами k8s: kubectl diff -f {service}-release.yaml
Перезапишите состояние k8s состоянием руля: kubectl apply -f {service}-release.yaml
Спасибо за идею. Это на самом деле заставило меня обнаружить основную причину дрейфа (обновленное описание выше). В конечном итоге мы выбрали
kubectl diff
, чтобы почувствовать дрейф.