10 Best Practices von Kubernetes für eine bessere Container-Orchestrierung

Lassen Sie uns über einige der Best Practices 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 verwendet wird, ist es sehr wichtig, sie gut zu verwalten, und genau das ist es Kubernetes tut.

Wenn Sie Kubernetes verwenden, müssen Sie die Best Practices für eine bessere Container-Orchestrierung anwenden.

Hier finden Sie eine Liste der Best Practices von Kubernetes, die Sie befolgen müssen.

# 1. Festlegen von Ressourcenanforderungen und -limits

Wenn Sie eine große Anwendung in einem Produktionscluster mit begrenzten Ressourcen bereitstellen, in denen den Knoten der Arbeitsspeicher oder die CPU ausgehen, funktioniert die Anwendung nicht mehr. Diese Ausfallzeit der Anwendung kann enorme Auswirkungen auf das Geschäft haben. Sie können dies jedoch lösen, indem Sie Ressourcenanforderungen und -beschränkungen haben.

Anforderungen und Ressourcenbeschränkungen sind die Mechanismen in Kubernetes, um die Verwendung von Ressourcen wie Speicher und CPU zu steuern. Wenn ein Pod die gesamte CPU und den gesamten Speicher belegt, gehen den anderen Pods die Ressourcen aus und sie können die Anwendung nicht ausführen. Daher müssen Sie Ressourcenanforderungen und -beschränkungen für die Pods festlegen, um die Zuverlässigkeit zu erhöhen.

Nur zu Ihrer Information, das Limit wird immer höher sein als die Anfrage. Ihr Container wird nicht ausgeführt, wenn Ihre Anforderung höher als das definierte Limit ist. Sie können Anforderungen und Grenzwerte für jeden Container in einem Pod festlegen. Die CPU wird mit Millicores definiert, und der Speicher wird mit Bytes (Megabyte / Mebibyte) definiert.

Im Folgenden finden Sie ein Beispiel für das Festlegen eines Grenzwerts für 500 Millicore CPU und 128 Mebibyte sowie für das Festlegen eines Kontingents für Anforderungen auf 300 Millicore CPU und 64 Mebibyte.

containers:
- name: prodcontainer1
    image: ubuntu
    resources:
        requests:
            memory: “64Mi”
            cpu: “300m”
        limits:                              
            memory: “128Mi”
            cpu: “500m”

# 2. Verwenden Sie LivenessProbe und ReadinessProbe

Gesundheitschecks sind in Kubernetes sehr wichtig.

Es bietet zwei Arten von Gesundheitschecks - Bereitschaft Sonden und Lebendigkeit Sonden.

Mithilfe von Bereitschaftssonden wird überprüft, ob die App bereit ist, den Datenverkehr zu bedienen, oder nicht. Dieser Test muss Kubernetes übergeben, bevor er den Datenverkehr an den Pod sendet, auf dem die Anwendung in einem Container ausgeführt wird. Kubernetes sendet den Datenverkehr nicht mehr an den Pod, bis diese Überprüfung des Bereitschaftszustands fehlschlägt.

Mithilfe von Liveness-Tests wird überprüft, ob die App noch ausgeführt wird (aktiv ist) oder gestoppt wurde (tot). Wenn die App ordnungsgemäß ausgeführt wird, unternimmt Kubernetes nichts. Wenn Ihre Anwendung tot ist, startet Kubernetes einen neuen Pod und führt die Anwendung darin aus.

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

Es gibt drei Arten von Sonden, die zur Überprüfung der Lebendigkeit und Bereitschaft verwendet werden können: HTTP, Befehl, und TCP.

Lassen Sie mich ein Beispiel für die häufigste zeigen, bei der es sich um die HTTP-Sonde handelt.

Hier befindet sich in Ihrer Anwendung ein HTTP-Server. Wenn Kubernetes einen Pfad zum HTTP-Server anpingt und eine HTTP-Antwort erhält, wird angezeigt, dass die Anwendung fehlerfrei oder ansonsten fehlerhaft ist.

apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
     livenessProbe:
       httpGet:
         path: /prodhealth
         port: 8080

# 3. Erstellen Sie Bilder mit kleinen Containern

Es wird bevorzugt, kleinere Container-Images zu verwenden, da weniger Speicherplatz benötigt wird und Sie die Images schneller abrufen und erstellen können. Da das Bild kleiner ist, ist auch die Wahrscheinlichkeit von Sicherheitsangriffen geringer.

Es gibt zwei Möglichkeiten, die Containergröße zu reduzieren: Verwenden eines kleineren Basisabbilds und eines Builder-Musters. Derzeit ist das neueste NodeJS-Basisbild 345 MB groß, während das alpine NodeJS-Bild nur 28 MB groß ist und mehr als zehnmal kleiner ist. Verwenden Sie daher immer die kleineren Bilder und fügen Sie die Abhängigkeiten hinzu, die zum Ausführen Ihrer Anwendung erforderlich sind.

Um die Containerbilder noch kleiner zu halten, können Sie ein Builder-Muster verwenden. Der Code wird im ersten Container erstellt, und dann wird der kompilierte Code ohne alle Compiler und Tools, die zum Erstellen des kompilierten Codes erforderlich sind, in den endgültigen Container gepackt, 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 Anforderungen pro Benutzer pro Sekunde / Minute / Stunde, die pro IP-Adresse zulässigen gleichzeitigen Sitzungen, die Anforderungsgröße und die Beschränkung auf Pfade und Hostnamen definieren. Dies hilft dabei, den Cluster vor Sicherheit zu schützen DDoS-Angriffe.

Entwickler und DevOps-Ingenieure, die an einem Kubernetes-Cluster arbeiten, sollten über eine definierte Zugriffsebene verfügen. Hier ist die rollenbasierte Zugriffssteuerung (RBAC) von Kubernetes hilfreich. Sie können Rollen und Clusterrollen verwenden, um die Zugriffsprofile zu definieren. Um die Konfiguration von RBAC zu vereinfachen, können Sie Open Source verwenden rbac-manager verfügbar, um Ihnen bei der Vereinfachung der Syntax oder Verwendung zu helfen RancherStandardmäßig wird RBAC bereitgestellt.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Kubernetes Secrets speichern vertrauliche Informationen wie Authentifizierungstoken, Kennwörter und SSH-Schlüssel. Sie sollten niemals Kubernetes Secrets auf der überprüfen IaC Andernfalls wird es denjenigen zugänglich gemacht, die Zugriff auf Ihr Git-Repository haben.

DevSecOps ist jetzt ein Schlagwort, das über DevOps und Sicherheit spricht. Die Organisationen nehmen den Trend an, da sie dessen Bedeutung verstehen.

# 5. Auf dem Laufenden bleiben

Es wird empfohlen, immer die neueste Version von Kubernetes im 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. Verwenden Sie Namespaces

Kubernetes liefert drei verschiedene Namespaces aus - Standard, Würfelsystem, und kube-öffentlich.

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-Namespace zu verwenden, wenn Sie ein kleines Team sind, das nur mit 5-10 Microservices arbeitet. In einem schnell wachsenden Team oder einer großen Organisation arbeiten jedoch mehrere Teams an einer Test- oder Produktionsumgebung. Daher muss jedes Team über einen separaten Namespace verfügen, um die Verwaltung zu vereinfachen.

Wenn sie dies nicht tun, werden sie möglicherweise versehentlich die Anwendung / Funktion eines anderen Teams überschreiben oder stören, ohne es zu merken. Es wird empfohlen, mehrere Namespaces zu erstellen und diese zum Segmentieren Ihrer Dienste in verwaltbare Blöcke zu verwenden.

Hier ist ein Beispiel für das Erstellen von Ressourcen in einem Namespace:

apiVersion: v1
kind: Pod
metadata:
   name: pod01
namespace: prod
   labels:
      image: pod01
spec:
   containers:
- name: prod01
  Image: ubuntu

# 7. Verwenden Sie Etiketten

Wenn Ihre Kubernetes-Bereitstellungen zunehmen, umfassen sie ausnahmslos mehrere Dienste, Pods und andere Ressourcen. Das Verfolgen dieser kann umständlich werden. Noch schwieriger kann es sein, die Kubernetes zu beschreiben, wie diese verschiedenen Ressourcen interagieren, wie sie repliziert, skaliert und gewartet werden sollen. Labels in Kubernetes sind sehr hilfreich bei der Lösung dieser Probleme.

Beschriftungen sind Schlüssel-Wert-Paare, mit denen Elemente innerhalb der Kubernetes-Oberfläche organisiert werden.

Zum Beispiel App: Kube-App, Phase: Test, Rolle: Frontend. Sie werden verwendet, um die Kubernetes zu beschreiben, wie verschiedene Objekte und Ressourcen innerhalb des Clusters zusammenarbeiten.

apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 labels:
   environment: testing
   team: test01
spec:
 containers:
   - name: test01
     image: "Ubuntu"
     resources:
       limits:
        cpu: 1

So können Sie den Schmerz der Kubernetes-Produktion reduzieren, indem Sie die Ressourcen und Objekte immer beschriften.

# 8. Audit-Protokollierung

Um Bedrohungen im Kubernetes-Cluster zu identifizieren, ist die Überwachung von Protokollen sehr wichtig. Auditing hilft bei der Beantwortung von Fragen wie was passiert ist, warum es passiert ist, wer es gemacht hat usw.

Alle Daten zu den an kube-apiserver gestellten Anforderungen werden in einer Protokolldatei namens aufgerufen audit.log. Diese Protokolldatei ist im JSON-Format strukturiert.

In Kubernetes wird das Überwachungsprotokoll standardmäßig in gespeichert <em>/var/log/audit.log</em> und die Prüfungsrichtlinie ist vorhanden bei <em>/etc/kubernetes/audit-policy.yaml</em>.

Starten Sie den kube-apiserver mit folgenden Parametern, um die Überwachungsprotokollierung zu aktivieren:

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

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

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
   - level: Metadata
     resources:
     - group: ""
      resources: ["pods/log", "pods/status"]

Sie können jederzeit zurückgehen und Überwachungsprotokolle überprüfen, wenn Probleme im Kubernetes-Cluster auftreten. Es wird Ihnen helfen, den korrekten Status des Clusters wiederherzustellen.

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

In Kubernetes gibt es zwei Mechanismen, um Pods besser mit den Knoten zu verknüpfen: Schote und Knoten Affinität. Es wird empfohlen, diese Mechanismen für eine bessere Leistung zu verwenden.

Mithilfe der Knotenaffinität können Sie Pods auf den Knoten anhand definierter Kriterien planen. Abhängig von den Pod-Anforderungen wird der passende Knoten in einem Kubernetes-Cluster ausgewählt und zugewiesen.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
spec:
  affinity:
    nodeAffinity:    
preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 2
        preference:        
matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: ubuntu
    image: ubuntu
    imagePullPolicy: IfNotPresent

Mithilfe der Pod-Affinität können Sie mehrere Pods auf demselben Knoten planen (zur Verbesserung der Latenz) oder Pods auf separaten Knoten belassen (für hohe Verfügbarkeit), um die Leistung zu steigern.

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod
spec:
  affinity:
    podAffinity:
     
requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
         
matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: ubuntu-pod
    image: ubuntu

Nachdem Sie die Arbeitslast Ihres Clusters analysiert haben, müssen Sie entscheiden, welche Affinitätsstrategie verwendet werden soll.

# 10. Kubernetes Kündigung

Kubernetes beendet die Pods, wenn sie nicht mehr benötigt werden. Sie können es über einen Befehl oder einen API-Aufruf initiieren. Die ausgewählten Pods werden beendet und es wird kein Datenverkehr an diese Pods gesendet. Eine SIGTERM-Nachricht wird dann an diese Pods gesendet, wonach die Pods heruntergefahren werden.

Die Pods werden ordnungsgemäß beendet. Standardmäßig beträgt die Nachfrist 30 Sekunden. Wenn die Pods noch ausgeführt werden, sendet Kubernetes eine SIGKILL-Nachricht, die die Pods zwangsweise herunterfährt. Schließlich werden diese Pods von Kubernetes vom API-Server auf dem Master-Computer entfernt.

Wenn Ihre Pods immer länger als 30 Sekunden dauern, können Sie diese Nachfrist auf 45 oder 60 Sekunden verlängern.

apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
  terminationGracePeriodSeconds: 60

Fazit

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

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