admin
helm upgrade --install jira-exporter -f jira-exporter/values.yaml jira-exporterhelm create NAMEGitOps ist ein Ansatz für die Verwaltung von Infrastruktur- und Anwendungsdeklarationen in einer Kubernetes- oder Cloud-native-Umgebung. Im Wesentlichen bedeutet GitOps, dass das gesamte Systemzustandsmanagement und die Bereitstellung von Anwendungen in einem Git-Repository verwaltet werden.
Hier sind einige Kernkonzepte von GitOps:
- Git als Single Source of Truth: Alle Änderungen an der Infrastruktur und den Anwendungen werden in einem Git-Repository verfolgt. Dieses Repository fungiert als einzige Quelle der Wahrheit für den Zustand des Systems.
- Declarative Configuration: Die Infrastruktur- und Anwendungsdeklarationen werden in einer deklarativen Sprache (z.B. YAML) geschrieben, was bedeutet, dass sie den gewünschten Endzustand beschreiben, nicht die Schritte, um dorthin zu gelangen.
- Automatisierung durch Continuous Deployment: Änderungen, die in das Git-Repository eingecheckt werden, lösen automatisierte Bereitstellungsprozesse aus. Diese Prozesse aktualisieren den tatsächlichen Systemzustand, um mit dem im Git-Repository definierten Zustand übereinzustimmen.
- Observability und Monitoring: GitOps-Systeme bieten in der Regel Mechanismen zur Überwachung des Systemzustands und zur Erfassung von Metriken, um sicherzustellen, dass das System den gewünschten Zustand beibehält.
- Rollback-Fähigkeit: Da der Systemzustand in Git gespeichert ist, ist es einfach, zu früheren Versionen zurückzukehren, wenn ein Problem auftritt.
Durch die Nutzung von GitOps können Entwickler und Betriebsteams eine konsistente und effiziente Methode zur Verwaltung von Infrastruktur und Anwendungen implementieren, die stark auf Automatisierung und Best Practices für die Versionskontrolle setzt.
helm template hpa ingress-nginx -f ingress-nginx/values.yaml- hpa = Name
- ingress-nginx = Verzeichnis mit dem Chart
- -f Datei mit Values
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/*/nginx_ingress_controller_per_second" | jq .Dieser Modus wird verwendet, wenn Traffic flapping erwartet wird oder die Anzahl der Pods nicht zu früh verkleinert werden soll, weil späte Lastspitzen erwartet werden.
Erstelle einen HPA mit der folgender Konfiguration:
behavior:
scaleDown:
stabilizationWindowSeconds: 600
policies:
- type: Pods
value: 5
periodSeconds: 600Dieser Modus wird benötigt um nicht runter zu skalieren da dies ggf. über einen externen Prozess geschieht
Erstelle einen HPA mit der folgender Konfiguration:
behavior:
scaleDown:
selectPolicy: DisabledDieser Modus wird benötigt um langsam hoch zu skalieren
Erstelle einen HPA mit der folgender Konfiguration:
behavior:
scaleUp:
policies:
- type: Pods
value: 1
periodSeconds: 300Wenn die Anwendung mit 1 Pod gestartet wird, wird sie schrittweise vergrößert:
1 -> 2 -> 3 -> 4Dieser Modus wird benötigt um bei schnellem Traffic aufkommen hoch zu skalieren und langsam Pods löschen um kein Risiko vom zu schnellem runter skalieren einzugehen.
Erstelle einen HPA mit der folgender Konfiguration:
behavior:
scaleUp:
policies:
- type: Percent
value: 900
periodSeconds: 60
scaleDown:
policies:
- type: Pods
value: 1
periodSeconds: 600 # (i.e., scale down one pod every 10 min)Dieses Verhalten entspricht dem Muster für das Hochskalieren wie im vorherigen Beispiel. Allerdings wird auch das Verhalten beim runter skalieren angegeben. Das scaleUp-Verhalten ist schnell, wie im vorherigen Beispiel erläutert
Beim runter skalieren wird jedoch nur alle 10 Minuten ein Pod gelöscht.
1000 -> 1000 -> 1000 -> … (7 more min) -> 999Dieser Modus wird benötigt um bei schnellem Traffic aufkommen hoch zu skalieren
Erstelle einen HPA mit der folgender Konfiguration:
behavior:
scaleUp:
policies:
- type: Percent
value: 900
periodSeconds: 60Die Zahl 900 bedeutet, dass das Neunfache der aktuellen Anzahl von Pods hinzugefügt werden kann, so dass die Anzahl der Replikate effektiv das Zehnfache der aktuellen Größe beträgt. Alle anderen Parameter werden nicht angegeben (es werden die Standardwerte verwendet)
Wenn die Anwendung mit 1 Pod gestartet wird, wird sie mit der folgenden Anzahl von Pods skaliert:
1 -> 10 -> 100 -> 1000Auf diese Weise können sehr schnell maxReplicas erreicht werden.
Das Downskaling erfolgt auf die übliche Weise (siehe Stabilisierungsfenster im Abschnitt Stabilisierungsfenster weiter unten und die Algorithmusdetails in der offiziellen HPA-Dokumentation)