helm 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)
Folgende Tools werden lokal benötigt:
- kubectl
- kind und docker
- helm
Cluster erstellen
kind create cluster
clusterctl init --infrastructure vsphere
clusterctl config cluster k8s-dev --kubernetes-version=v1.20.1 --control-plane-machine-count=3 --worker-machine-count=3 > deploy_dev.yaml
kubectl apply -f deploy_dev.yaml
kubectl get kubeadmcontrolplane --all-namespaces
clusterctl get kubeconfig k8s-dev > k8s-dev.kubeconfig
export KUBECONFIG=k8s-dev.kubeconfig
docker login
kubectl create secret generic regcred --from-file=.dockerconfigjson=/home/xforze/.docker/config.json --type=kubernetes.io/dockerconfigjson
kubectl create secret -n kube-system generic regcred --from-file=.dockerconfigjson=/home/xforze/.docker/config.json --type=kubernetes.io/dockerconfigjson
kubectl create secret -n tigera-operator generic tigera-pull-secret --from-file=.dockerconfigjson=/home/xforze/.docker/config.json --type=kubernetes.io/dockerconfigjson
# Install Weavenet
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
# Install Calico
kubectl create -f https://docs.projectcalico.org/archive/v3.18/manifests/tigera-operator.yaml
kubectl create -f https://docs.projectcalico.org/archive/v3.18/manifests/custom-resources.yaml
</pre>
Add insecure Flag to vsphere-csi-driver
kubectl edit secret -n kube-system csi-vsphere-config
[Global]
insecure-flag = "true"
Add a Storageclass:
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: example-vanilla-block-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true" # Optional
provisioner: csi.vsphere.vmware.com
allowVolumeExpansion: true # Optional: only applicable to vSphere 7.0U1 and above
parameters:
datastoreurl: "ds:///vmfs/volumes/vsan:52cdfa80721ff516-ea1e993113acfc77/" # Optional Parameter
storagepolicyname: "vSAN Default Storage Policy" # Optional Parameter
csi.storage.k8s.io/fstype: "ext4" # Optional Parameter
Add en example pvc:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: example-vanilla-block-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: example-vanilla-block-sc