Lassen Sie uns über einige der besten Praktiken sprechen, die bei der Verwendung von Kubernetes befolgt werden sollten.

Kubernetes ist eine Open-Source-Plattform für die Container-Orchestrierung, die die Bereitstellung von Containern, die kontinuierliche Skalierung und De-Skalierung, den Container-Lastausgleich und vieles mehr automatisiert.

Da die Containerisierung auf vielen Produktionsservern mit Tausenden von Containern eingesetzt wird, ist es sehr wichtig, diese gut zu verwalten, und genau das tut Kubernetes.

Wenn Sie Kubernetes verwenden, müssen Sie die besten Praktiken für eine bessere Container-Orchestrierung übernehmen.

Im Folgenden finden Sie eine Liste der besten Kubernetes-Praktiken, die Sie befolgen müssen.

#1. Legen Sie Ressourcenanforderungen und Limits fest

Wenn Sie eine große Anwendung auf einem Produktionscluster mit begrenzten Ressourcen bereitstellen und den Knoten der Speicher oder die CPU ausgeht, wird die Anwendung nicht mehr funktionieren. Diese Ausfallzeit der Anwendung kann enorme Auswirkungen auf das Geschäft haben. Sie können dieses Problem jedoch lösen, indem Sie Ressourcenanfragen und -limits einrichten.

Ressourcenanfragen und -limits sind die Mechanismen in Kubernetes, um die Nutzung von Ressourcen wie Speicher und CPU zu kontrollieren. Wenn ein Pod die gesamte CPU und den gesamten Arbeitsspeicher verbraucht, bekommen die anderen Pods keine Ressourcen mehr und können die Anwendung nicht mehr ausführen. Um die Zuverlässigkeit zu erhöhen, müssen Sie daher Ressourcenanforderungen und -begrenzungen für die Pods festlegen.

Zu Ihrer Information: Das Limit wird immer höher sein als die Anforderung. Ihr Container wird nicht laufen, wenn Ihre Anfrage höher ist als das festgelegte Limit. Sie können Anfragen und Limits für jeden Container in einem Pod festlegen. Die CPU wird in Millicores und der Speicher in Bytes (Megabyte/Mebibyte) angegeben.

Unten sehen Sie ein Beispiel für die Festlegung eines Limits von 500 Millicores CPU und 128 Mebibytes und die Festlegung einer Quote für Anfragen von 300 Millicores CPU und 64 Mebibytes.

container:
- name: prodcontainer1
    bild: ubuntu
    ressourcen:
        anfragen:
            speicher: "64Mi"
            cpu: "300m"
        grenzen:        
            arbeitsspeicher: "128Mi"
            cpu: "500m"

#2. Verwenden Sie livenessProbe und readinessProbe

Zustandsüberprüfungen sind in Kubernetes sehr wichtig.

Es gibt zwei Arten von Gesundheitsprüfungen – ReadinessProbes und LivenessProbes.

Readiness Probes werden verwendet, um zu prüfen, ob die Anwendung bereit ist, den Datenverkehr zu verarbeiten oder nicht. Diese Sonde muss in Kubernetes bestanden werden, bevor es beginnt, den Datenverkehr an den Pod zu senden, auf dem die Anwendung in einem Container läuft. Kubernetes sendet den Datenverkehr erst dann an den Pod, wenn dieser Readiness-Check fehlschlägt.

Liveness Probes werden verwendet, um zu prüfen, ob die Anwendung noch läuft (alive) oder ob sie angehalten wurde (dead). Wenn die Anwendung ordnungsgemäß läuft, unternimmt Kubernetes nichts. Wenn Ihre Anwendung tot ist, startet Kubernetes einen neuen Pod und führt die Anwendung darin aus.

Wenn diese Prüfungen nicht ordnungsgemäß durchgeführt werden, werden die Pods möglicherweise beendet oder erhalten Benutzeranfragen, bevor sie überhaupt bereit sind.

Es gibt drei Arten von Sonden, die für die Überprüfung der Funktionsfähigkeit und Bereitschaft verwendet werden können: HTTP, Command und TCP.

Lassen Sie mich ein Beispiel für die gängigste Sonde zeigen, die HTTP-Sonde.

In diesem Fall enthält Ihre Anwendung einen HTTP-Server. Wenn Kubernetes einen Pfad zum HTTP-Server anpingt und eine HTTP-Antwort erhält, markiert es die Anwendung als gesund, andernfalls als ungesund.

apiVersion: v1
art: Pod
metadaten:
 name: container10
spez:
 container:
   - bild: ubuntu
     name: container10
     livenessProbe:
       httpGet:
         pfad: /prodhealth
         port: 8080

#3. Kleine Container-Images erstellen

Es ist besser, kleinere Container-Images zu verwenden, da sie weniger Speicherplatz benötigen und Sie die Images schneller ziehen und erstellen können. Da die Größe des Images kleiner ist, ist auch die Wahrscheinlichkeit von Sicherheitsangriffen geringer.

Es gibt zwei Möglichkeiten, die Containergröße zu reduzieren – die Verwendung eines kleineren Basis-Images und eines Builder-Musters. Derzeit ist das neueste NodeJS-Basis-Image 345 MB groß, während das NodeJS-Alpine-Image nur 28 MB groß ist, also mehr als zehnmal kleiner. Verwenden Sie also immer die kleineren Images und fügen Sie die für die Ausführung Ihrer Anwendung erforderlichen Abhängigkeiten hinzu.

Um die Container-Images noch kleiner zu halten, können Sie ein Builder-Muster verwenden. Der Code wird im ersten Container erstellt und dann wird der kompilierte Code in den endgültigen Container gepackt, ohne alle Compiler und Tools, die für die Erstellung des kompilierten Codes erforderlich sind, wodurch das Container-Image noch kleiner wird.

#4. Gewähren Sie sichere Zugriffsebenen (RBAC)

Ein sicherer Kubernetes-Cluster ist sehr wichtig.

Der Zugriff auf den Cluster sollte gut konfiguriert sein. Sie müssen die Anzahl der Anfragen pro Benutzer pro Sekunde/Minute/Stunde, die erlaubten gleichzeitigen Sitzungen pro IP-Adresse, die Anfragegröße und die Beschränkung auf Pfade und Hostnamen festlegen. Dies wird dazu beitragen, den Cluster vor DDoS-Angriffen zu schützen.

Entwickler und DevOps-Ingenieure, die an einem Kubernetes-Cluster arbeiten, sollten eine bestimmte Zugriffsebene haben. Die rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes ist hier nützlich. Sie können Roles und ClusterRoles verwenden, um die Zugriffsprofile zu definieren. Um die Konfiguration von RBAC zu erleichtern, können Sie den Open-Source rbac-managers verwenden, der Ihnen bei der Vereinfachung der Syntax hilft, oder Sie verwenden Rancher, das standardmäßig RBAC bietet.

apiVersion: rbac.authorization.k8s.io/v1
art: ClusterRole
metadaten:
  name: cluster-role
regeln:
- apiGroups: [""]
  ressourcen: ["pods"]
  verbs: ["get", "list"]

In Kubernetes Secrets werden vertrauliche Informationen wie Authentifizierungstoken, Passwörter und SSH-Schlüssel gespeichert. Sie sollten Kubernetes Secrets niemals auf dem IaC-Repository überprüfen, da es sonst für diejenigen, die Zugriff auf Ihr Git-Repository haben, sichtbar wird.

DevSecOps ist jetzt ein Schlagwort, das DevOps und Sicherheit betrifft. Die Unternehmen nehmen den Trend auf, da sie die Bedeutung dieses Themas erkannt haben.

#5. Auf dem Laufenden bleiben

Es wird empfohlen, immer die neueste Version von Kubernetes auf dem Cluster zu installieren.

Die neueste Version von Kubernetes enthält neue Funktionen, Aktualisierungen früherer Funktionen, Sicherheitsupdates, Fehlerbehebungen usw. Wenn Sie Kubernetes mit einem Cloud-Anbieter verwenden, ist die Aktualisierung sehr einfach.

#6. Namespaces verwenden

Kubernetes wird mit drei verschiedenen Namespaces ausgeliefert – default, kube-system und kube-public.

Diese Namespaces spielen in einem Kubernetes-Cluster eine sehr wichtige Rolle für die Organisation und Sicherheit zwischen den Teams.

Es ist sinnvoll, den Standard-Namensraum zu verwenden, wenn Sie ein kleines Team sind, das nur mit 5-10 Microservices arbeitet. Ein schnell wachsendes Team oder eine große Organisation wird jedoch mehrere Teams haben, die an einer Test- oder Produktionsumgebung arbeiten, so dass jedes Team zur einfacheren Verwaltung einen eigenen Namespace haben muss.

Andernfalls kann es passieren, dass sie versehentlich die Anwendung/Funktion eines anderen Teams überschreiben oder stören, ohne es zu bemerken. Es wird empfohlen, mehrere Namespaces zu erstellen und diese zu verwenden, um Ihre Dienste in überschaubare Teile zu unterteilen.

Hier ist ein Beispiel für die Erstellung von Ressourcen innerhalb eines Namespaces:

apiVersion: v1
art: Pod
metadaten:
   name: pod01
namensraum: prod
   bezeichnungen:
      bild: pod01
spez:
   container:
- name: prod01
  Bild: ubuntu

#7. Labels verwenden

Wenn Ihre Kubernetes-Installationen wachsen, werden sie unweigerlich mehrere Dienste, Pods und andere Ressourcen umfassen. Diese im Auge zu behalten, kann mühsam werden. Noch schwieriger ist es, Kubernetes zu beschreiben, wie diese verschiedenen Ressourcen zusammenwirken und wie sie repliziert, skaliert und gewartet werden sollen. Labels in Kubernetes sind bei der Lösung dieser Probleme sehr hilfreich.

Labels sind Schlüssel-Wert-Paare, die zur Organisation von Elementen innerhalb der Kubernetes-Oberfläche verwendet werden.

Zum Beispiel: app: kube-app, phase: test, role: front-end. Sie werden verwendet, um Kubernetes zu beschreiben, wie verschiedene Objekte und Ressourcen innerhalb des Clusters zusammenarbeiten.

apiVersion: v1
art: Pod
metadaten:
 name: test-pod
 bezeichnungen:
   umgebung: testing
   team: test01
spez:
 container:
   - name: test01
     bild: "Ubuntu"
     ressourcen:
       grenzen:
        cpu: 1

Sie können also den Aufwand für die Kubernetes-Produktion verringern, indem Sie die Ressourcen und Objekte immer kennzeichnen.

#8. Audit-Protokollierung

Um Bedrohungen im Kubernetes-Cluster zu erkennen, ist das Auditing von Protokollen sehr wichtig. Auditing hilft bei der Beantwortung von Fragen wie: Was ist passiert, warum ist es passiert, wer hat es getan usw.

Alle Daten im Zusammenhang mit den an kube-apiserver gestellten Anfragen werden in einer Protokolldatei namens audit.log gespeichert. Diese Protokolldatei ist im JSON-Format strukturiert.

In Kubernetes wird das Audit-Protokoll standardmäßig in <em>/var/log/audit.log</em> gespeichert und die Audit-Richtlinie befindet sich in <em>/etc/kubernetes/audit-policy.yaml</em>.

Um die Audit-Protokollierung zu aktivieren, starten Sie den kube-apiserver mit diesen Parametern:

--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log

Hier ist ein Beispiel für eine audit.log-Datei, die für die Protokollierung von Änderungen in den Pods konfiguriert ist:

apiVersion: audit.k8s.io/v1
art: Richtlinie
omitStages:
  - "RequestReceived"
regeln:
  - stufe: RequestResponse
    ressourcen:
    - group: ""
      resources: ["pods"]
   - ebene: Metadaten
     ressourcen:
     - group: ""
      ressourcen: ["pods/log", "pods/status"]

Im Falle eines Problems im Kubernetes-Cluster können Sie jederzeit zurückgehen und die Audit-Protokolle überprüfen. So können Sie den korrekten Zustand des Clusters wiederherstellen.

#9. Affinitätsregeln anwenden (Node/Pod)

In Kubernetes gibt es zwei Mechanismen, um Pods besser mit den Nodes zu verknüpfen – Pod- und Node-Affinität. Es wird empfohlen, diese Mechanismen für eine bessere Leistung zu verwenden.

Mit der Node-Affinität können Sie Pods anhand definierter Kriterien auf den Nodes einplanen. Je nach den Anforderungen des Pods wird der passende Node ausgewählt und in einem Kubernetes-Cluster zugewiesen.

apiVersion: v1
art: Pod
metadaten:
  name: ubuntu
spec:
  affinität:
    nodeAffinity:    
preferredDuringSchedulingIgnoredDuringExecution:
      - gewicht: 2
        präferenz:        
matchExpressions:
          - schlüssel: disktype
            operator: In
            werte:
            - ssd   
  container:
  - name: ubuntu
    image: ubuntu
    imagePullPolicy: IfNotPresent

Mit der Pod-Affinität können Sie mehrere Pods auf demselben Knoten einplanen (zur Verbesserung der Latenzzeit) oder sich dafür entscheiden, Pods auf separaten Knoten zu halten (für hohe Verfügbarkeit), um die Leistung zu steigern.

apiVersion: v1
art: Pod
metadaten:
  name: ubuntu-pod
spec:
  affinität:
    podAffinität:
     
requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
         
matchExpressions:
          - key: Sicherheit
            operator: In
            werte:
            - S1
        topologyKey: ausfall-domain.beta.kubernetes.io/zone
  container:
  - name: ubuntu-pod
    abbild: ubuntu

Nachdem Sie die Arbeitslast Ihres Clusters analysiert haben, müssen Sie entscheiden, welche Affinitätsstrategie Sie verwenden möchten.

#10. Kubernetes Beendigung

Kubernetes beendet die Pods, wenn sie nicht mehr benötigt werden. Sie können dies durch einen Befehl oder einen API-Aufruf einleiten. Die ausgewählten Pods gehen in den Beendigungsstatus über und es wird kein Datenverkehr an diese Pods gesendet. Anschließend wird eine SIGTERM-Nachricht an diese Pods gesendet, woraufhin die Pods heruntergefahren werden.

Die Pods werden ordnungsgemäß beendet, standardmäßig beträgt die Gnadenfrist 30 Sekunden. Wenn die Pods noch laufen, sendet Kubernetes eine SIGKILL-Nachricht, die die Pods zwangsweise herunterfährt. Schließlich werden diese Pods von Kubernetes aus dem API-Server auf dem Master-Rechner entfernt.

Falls Ihre Pods immer mehr als 30 Sekunden benötigen, können Sie diese Gnadenfrist auf 45 oder 60 Sekunden erhöhen.

apiVersion: v1
art: Pod
metadaten:
 name: container10
spez:
 container:
   - bild: ubuntu
     name: container10
  terminationGracePeriodSeconds: 60

Fazit

Ich hoffe, dass Ihnen diese Best Practices bei einer besseren Container-Orchestrierung mit Kubernetes helfen werden. Versuchen Sie, diese in Ihrem Kubernetes-Cluster zu implementieren, um bessere Ergebnisse zu erzielen.

Als nächstes lernen Sie die besten Kubernetes-Tools für den DevOps-Erfolg kennen.