Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

EKS-Datenebene

Um hochverfügbare und ausfallsichere Anwendungen zu betreiben, benötigen Sie eine hochverfügbare und belastbare Datenebene. Eine elastische Datenebene stellt sicher, dass Kubernetes Ihre Anwendungen automatisch skalieren und reparieren kann. Eine robuste Datenebene besteht aus zwei oder mehr Worker-Knoten, kann mit der Arbeitslast wachsen und schrumpfen und wird nach Ausfällen automatisch wiederhergestellt.

Sie haben zwei Möglichkeiten für Worker-Knoten mit EKS: EC2Instances und Fargate. Wenn Sie sich für EC2 Instanzen entscheiden, können Sie die Worker-Knoten selbst verwalten oder von EKS verwaltete Knotengruppen verwenden. Sie können einen Cluster mit einer Mischung aus verwalteten, selbstverwalteten Worker-Knoten und Fargate haben.

EKS on Fargate bietet den einfachsten Weg zu einer belastbaren Datenebene. Fargate führt jeden Pod in einer isolierten Rechenumgebung aus. Jeder Pod, der auf Fargate läuft, erhält seinen eigenen Worker-Knoten. Fargate skaliert die Datenebene automatisch, während Kubernetes Pods skaliert. Sie können sowohl die Datenebene als auch Ihre Arbeitslast skalieren, indem Sie den horizontalen Pod-Autoscaler verwenden.

Die bevorzugte Methode zur Skalierung von EC2 Worker-Knoten ist die Verwendung von Kubernetes Cluster Autoscaler, EC2Auto Scaling Scaling-Gruppen oder Community-Projekten wie Atlassians Escalator.

Empfehlungen

Verwenden Sie EC2 Auto Scaling Scaling-Gruppen, um Worker-Knoten zu erstellen

Es hat sich bewährt, Worker-Knoten mithilfe von EC2 Auto Scaling Scaling-Gruppen zu erstellen, anstatt einzelne EC2 Instances zu erstellen und sie dem Cluster hinzuzufügen. Auto Scaling Groups ersetzen automatisch alle beendeten oder ausgefallenen Knoten und stellen sicher, dass der Cluster immer die Kapazität hat, Ihren Workload auszuführen.

Verwenden Sie Kubernetes Cluster Autoscaler, um Knoten zu skalieren

Cluster Autoscaler passt die Größe der Datenebene an, wenn es Pods gibt, die nicht ausgeführt werden können, weil der Cluster nicht über ausreichende Ressourcen verfügt. Das Hinzufügen eines weiteren Worker-Knotens wäre hilfreich. Cluster Autoscaler ist zwar ein reaktiver Prozess, er wartet jedoch, bis sich die Pods aufgrund unzureichender Kapazität im Cluster im Status Ausstehend befinden. Wenn ein solches Ereignis eintritt, werden dem Cluster EC2 Instanzen hinzugefügt. Immer wenn die Kapazität des Clusters knapp wird, sind neue Replikate — oder neue Pods — nicht verfügbar (im Status Ausstehend), bis Worker-Knoten hinzugefügt werden. Diese Verzögerung kann sich auf die Zuverlässigkeit Ihrer Anwendungen auswirken, wenn die Datenebene nicht schnell genug skaliert werden kann, um den Workload-Anforderungen gerecht zu werden. Wenn ein Worker-Knoten ständig nicht ausgelastet ist und alle seine Pods auf anderen Worker-Knoten eingeplant werden können, beendet Cluster Autoscaler ihn.

Konfigurieren Sie Over-Provisioning mit Cluster Autoscaler

Cluster Autoscaler löst eine Skalierung der Datenebene aus, wenn Pods im Cluster bereits ausstehend sind. Daher kann es zu einer Verzögerung zwischen dem Zeitpunkt kommen, zu dem Ihre Anwendung mehr Replikate benötigt, und dem Zeitpunkt, zu dem sie tatsächlich mehr Replikate erhält. Eine Möglichkeit, dieser möglichen Verzögerung Rechnung zu tragen, besteht darin, mehr Replikate als erforderlich hinzuzufügen, wodurch die Anzahl der Replikate für die Anwendung erhöht wird.

Ein anderes von Cluster Autoscaler empfohlenes Muster verwendet Pause-Pods und die Priority Preemption-Funktion. Der Pause-Pod führt einen Pause-Container aus, der, wie der Name schon sagt, lediglich als Platzhalter für Rechenkapazität dient, die von anderen Pods in Ihrem Cluster verwendet werden kann. Da er mit einer sehr niedrigen zugewiesenen Priorität ausgeführt wird, wird der Pause-Pod vom Knoten entfernt, wenn ein weiterer Pod erstellt werden muss und der Cluster keine verfügbare Kapazität hat. Der Kubernetes-Scheduler bemerkt, dass der Pause-Pod gelöscht wurde, und versucht, ihn neu zu planen. Da der Cluster jedoch voll ausgelastet ist, bleibt der Pause-Pod ausstehend, worauf der Cluster Autoscaler reagiert, indem er Knoten hinzufügt.

Verwenden von Cluster Autoscaler mit mehreren Auto Scaling Scaling-Gruppen

Führen Sie den Cluster-Autoscaler mit aktiviertem Flag aus. --node-group-auto-discovery Auf diese Weise kann der Cluster Autoscaler alle Autoscaling-Gruppen finden, die ein bestimmtes definiertes Tag enthalten, und verhindert, dass jede Autoscaling-Gruppe im Manifest definiert und verwaltet werden muss.

Verwenden von Cluster Autoscaler mit lokalem Speicher

Standardmäßig skaliert der Cluster Autoscaler keine Knoten, bei denen Pods mit angehängtem lokalen Speicher bereitgestellt wurden. Setzen Sie das --skip-nodes-with-local-storage Flag auf False, damit Cluster Autoscaler diese Knoten herunterskalieren kann.

Verteilen Sie die Worker-Knoten und die Arbeitslast auf mehrere AZs

Sie können Ihre Workloads vor Ausfällen in einer einzelnen AZ schützen, indem Sie Worker-Knoten und Pods in mehreren AZs ausführen. Sie können die AZ, in der die Worker-Knoten erstellt werden, mithilfe der Subnetze steuern, in denen Sie die Knoten erstellen.

Wenn Sie Kubernetes 1.18+ verwenden, ist die empfohlene Methode zur Verteilung von Pods die Verwendung von Topology Spread AZs Constraints für Pods.

Bei der folgenden Bereitstellung werden Pods nach Möglichkeit verteilt, sodass diese Pods trotzdem ausgeführt werden können, AZs wenn nicht:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1

In älteren Versionen von Kubernetes können Sie Pod-Anti-Affinitätsregeln verwenden, um Pods für mehrere Pods zu planen. AZs Das folgende Manifest informiert den Kubernetes-Scheduler darüber, Pods lieber einzeln zu planen. AZs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx

Stellen Sie sicher, dass die Kapazität in jeder AZ vorhanden ist, wenn Sie EBS-Volumes verwenden

Wenn Sie Amazon EBS zur Bereitstellung persistenter Volumes verwenden, müssen Sie sicherstellen, dass sich die Pods und das zugehörige EBS-Volume in derselben AZ befinden. Zum Zeitpunkt der Erstellung dieses Artikels sind EBS-Volumes nur innerhalb einer einzigen AZ verfügbar. Ein Pod kann nicht auf EBS-gestützte persistente Volumes zugreifen, die sich in einer anderen AZ befinden. Der Kubernetes-Scheduler weiß, in welcher AZ sich ein Worker-Knoten befindet. Kubernetes plant immer einen Pod, für den ein EBS-Volume in derselben AZ wie das Volume erforderlich ist. Wenn jedoch in der AZ, in der sich das Volume befindet, keine Worker-Knoten verfügbar sind, kann der Pod nicht geplant werden.

Erstellen Sie für jede AZ eine Auto Scaling Scaling-Gruppe mit ausreichender Kapazität, um sicherzustellen, dass der Cluster immer über die Kapazität verfügt, Pods in derselben AZ zu planen wie die EBS-Volumes, die sie benötigen. Darüber hinaus sollten Sie die --balance-similar-node-groups Funktion in Cluster Autoscaler aktivieren.

Wenn Sie eine Anwendung ausführen, die ein EBS-Volume verwendet, für die jedoch keine hohe Verfügbarkeit erforderlich ist, können Sie die Bereitstellung der Anwendung auf eine einzige AZ beschränken. In EKS wird den Worker-Knoten automatisch ein failure-domain.beta.kubernetes.io/zone Label hinzugefügt, das den Namen der AZ enthält. Sie können die Labels sehen, die Ihren Knoten zugewiesen sind, indem Sie den Befehl ausführenkubectl get nodes --show-labels. Weitere Informationen zu den integrierten Knotenbezeichnungen finden Sie hier. Sie können Knotenselektoren verwenden, um einen Pod in einer bestimmten AZ zu planen.

Im folgenden Beispiel wird der Pod nur in us-west-2c AZ geplant:

apiVersion: v1
kind: Pod
metadata:
  name: single-az-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - us-west-2c
  containers:
  - name: single-az-container
    image: kubernetes/pause

Persistente Volumes (von EBS unterstützt) werden ebenfalls automatisch mit dem Namen AZ gekennzeichnet. Sie können anhand der Ausführung kubectl get pv -L topology.ebs.csi.aws.com/zone sehen, zu welcher AZ Ihr persistenter Datenträger gehört. Wenn ein Pod erstellt wird und ein Volume beansprucht, plant Kubernetes den Pod auf einem Knoten in derselben AZ wie das Volume.

Stellen Sie sich dieses Szenario vor: Sie haben einen EKS-Cluster mit einer Knotengruppe. Diese Knotengruppe hat drei Worker-Knoten, die auf drei verteilt sind AZs. Sie haben eine Anwendung, die ein EBS-gestütztes persistentes Volume verwendet. Wenn Sie diese Anwendung und das entsprechende Volume erstellen, wird der zugehörige Pod im ersten der drei Anwendungen erstellt. AZs Dann wird der Worker-Knoten, auf dem dieser Pod ausgeführt wird, fehlerhaft und kann anschließend nicht mehr verwendet werden. Cluster Autoscaler ersetzt den fehlerhaften Knoten durch einen neuen Worker-Knoten. Da sich die Autoscaling-Gruppe jedoch über drei erstreckt AZs, wird der neue Worker-Knoten möglicherweise in der zweiten oder dritten AZ gestartet, aber nicht in der ersten AZ, wie es die Situation erfordert. Da das EBS-Volume mit AZ-Einschränkungen nur in der ersten AZ existiert, in dieser AZ jedoch keine Worker-Knoten verfügbar sind, kann der Pod nicht geplant werden. Daher sollten Sie in jeder AZ eine Knotengruppe erstellen, sodass immer genügend Kapazität zur Verfügung steht, um Pods auszuführen, die in anderen nicht geplant werden können. AZs

Alternativ kann EFS die automatische Clusterskalierung vereinfachen, wenn Anwendungen ausgeführt werden, die persistenten Speicher benötigen. Clients können von allen AZs in der Region aus gleichzeitig auf EFS-Dateisysteme zugreifen. Selbst wenn ein Pod, der EFS-gestütztes persistentes Volume verwendet, beendet und in einer anderen AZ geplant wird, kann er das Volume mounten.

Erkennen Sie Knotenprobleme mit dem Node Monitoring Agent

Ausfälle in Worker-Knoten können sich auf die Verfügbarkeit Ihrer Anwendungen auswirken. Sie können den Node Monitoring Agent verwenden, um Gesundheitsprobleme zu erkennen und anzuzeigen. Sie können auch die auto Knotenreparatur aktivieren, um Knoten automatisch zu ersetzen, wenn Probleme erkannt werden.

Der Node Monitoring Agent ist als Funktion für alle Amazon EKS Auto Mode-Cluster enthalten. Für andere Clustertypen können Sie den Monitoring-Agenten als Amazon EKS-Add-on hinzufügen. Weitere Informationen finden Sie unter auto Knotenreparatur aktivieren und Probleme mit dem Knotenstatus untersuchen im Amazon EKS-Benutzerhandbuch.

Reservieren Sie Ressourcen für System- und Kubernetes-Daemons

Sie können die Stabilität von Worker-Knoten verbessern, indem Sie Rechenkapazität für das Betriebssystem und die Kubernetes-Daemons reservieren. Pods — insbesondere solche, die nicht limits deklariert wurden — können Systemressourcen überlasten, sodass Knoten in eine Situation geraten, in der Betriebssystemprozesse und Kubernetes-Daemons (kubelet, Container-Runtime usw.) mit Pods um Systemressourcen konkurrieren. Sie können kubelet Flags verwenden --system-reserved und --kube-reserved Ressourcen für Systemprozesse (udev, usw.) bzw. sshd Kubernetes-Daemons reservieren.

Wenn Sie das EKS-optimierte Linux-AMI verwenden, sind CPU, Arbeitsspeicher und Speicher standardmäßig für das System und die Kubernetes-Daemons reserviert. Wenn Worker-Knoten, die auf diesem AMI basieren, gestartet werden, EC2 werden Benutzerdaten so konfiguriert, dass sie das bootstrap.shSkript auslösen. Dieses Skript berechnet CPU- und Speicherreservierungen auf der Grundlage der Anzahl der CPU-Kerne und des gesamten auf der Instance verfügbaren Speichers. EC2 Die berechneten Werte werden in die KubeletConfiguration Datei geschrieben, die sich unter /etc/kubernetes/kubelet/kubelet-config.json befindet.

Möglicherweise müssen Sie die Systemressourcenreservierung erhöhen, wenn Sie benutzerdefinierte Daemons auf dem Knoten ausführen und die standardmäßig reservierte Menge an CPU und Arbeitsspeicher nicht ausreicht.

eksctlbietet die einfachste Möglichkeit, die Ressourcenreservierung für System- und Kubernetes-Daemons anzupassen.

Implementieren Sie QoS

Für kritische Anwendungen sollten Sie erwägen, requests = limits für den Container im Pod zu definieren. Dadurch wird sichergestellt, dass der Container nicht beendet wird, wenn ein anderer Pod Ressourcen anfordert.

Es hat sich bewährt, CPU- und Speicherbegrenzungen für alle Container zu implementieren, um zu verhindern, dass ein Container versehentlich Systemressourcen verbraucht und dadurch die Verfügbarkeit anderer Prozesse am selben Standort beeinträchtigt.

Konfiguration und Dimensionierung von Ressourcenanforderungen/-limits für alle Workloads

Bei der Dimensionierung von Ressourcenanforderungen und der Limits für Workloads können einige allgemeine Richtlinien angewendet werden:

Das Ermitteln von Ressourcenanforderungen kann schwierig sein, aber Tools wie der Vertical Pod Autoscaler können Ihnen helfen, die richtige Größe der Anfragen zu finden, indem Sie die Nutzung der Container-Ressourcen zur Laufzeit beobachten. Zu den weiteren Tools, die für die Bestimmung der Anforderungsgrößen nützlich sein können, gehören:

Konfigurieren Sie Ressourcenkontingente für Namespaces

Namespaces sind für die Verwendung in Umgebungen mit vielen Benutzern vorgesehen, die auf mehrere Teams oder Projekte aufgeteilt sind. Sie bieten einen Gültigkeitsbereich für Namen und bieten eine Möglichkeit, Clusterressourcen auf mehrere Teams, Projekte und Workloads aufzuteilen. Sie können den aggregierten Ressourcenverbrauch in einem Namespace einschränken. Das ResourceQuotaObjekt kann die Anzahl der Objekte, die in einem Namespace erstellt werden können, nach Typ sowie die Gesamtmenge der Rechenressourcen einschränken, die von Ressourcen in diesem Projekt verbraucht werden können. Sie können die Gesamtsumme der Speicher- und/oder Rechenressourcen (CPU und Arbeitsspeicher) begrenzen, die in einem bestimmten Namespace angefordert werden können.

Wenn das Ressourcenkontingent für einen Namespace für Rechenressourcen wie CPU und Arbeitsspeicher aktiviert ist, müssen Benutzer Anforderungen oder Grenzwerte für jeden Container in diesem Namespace angeben.

Erwägen Sie, Kontingente für jeden Namespace zu konfigurieren. Erwägen SieLimitRanges, diese Option zu verwenden, um automatisch vorkonfigurierte Grenzwerte auf Container innerhalb eines Namespaces anzuwenden.

Beschränken Sie die Nutzung von Container-Ressourcen innerhalb eines Namespace

Ressourcenkontingente helfen dabei, die Menge an Ressourcen zu begrenzen, die ein Namespace verwenden kann. Das LimitRangeObjekt kann Ihnen dabei helfen, die minimalen und maximalen Ressourcen zu implementieren, die ein Container anfordern kann. Mithilfe von LimitRange Ihnen können Sie eine Standardanforderung und Grenzwerte für Container festlegen. Dies ist hilfreich, wenn die Festlegung von Limits für Rechenressourcen in Ihrer Organisation nicht üblich ist. Wie der Name schon sagt, LimitRange kann die minimale und maximale Nutzung von Rechenressourcen pro Pod oder Container in einem Namespace durchgesetzt werden. Außerdem kann die minimale und maximale Speicheranforderung pro PersistentVolumeClaim Namespace durchgesetzt werden.

Erwägen Sie die Verwendung LimitRange in Verbindung mitResourceQuota, um Grenzwerte sowohl auf Container- als auch auf Namespace-Ebene durchzusetzen. Durch die Festlegung dieser Grenzwerte wird sichergestellt, dass sich ein Container oder ein Namespace nicht auf Ressourcen auswirkt, die von anderen Mandanten im Cluster verwendet werden.

CoreDNS

CoreDNS erfüllt Funktionen zur Namensauflösung und Serviceerkennung in Kubernetes. Es ist standardmäßig auf EKS-Clustern installiert. Aus Gründen der Interoperabilität trägt der Kubernetes-Service für CoreDNS weiterhin den Namen kube-dns. CoreDNS-Pods werden als Teil einer Bereitstellung im kube-system Namespace ausgeführt, und in EKS werden standardmäßig zwei Replikate mit deklarierten Anforderungen und Grenzwerten ausgeführt. DNS-Abfragen werden an den kube-dns Dienst gesendet, der im Namespace ausgeführt wird. kube-system

Empfehlungen

CoreDNS-Metriken überwachen

CoreDNS hat Unterstützung für Prometheus eingebaut. Sie sollten insbesondere die Überwachung der CoreDNS-Latenz (vor der Version 1.7.0 wurde die Metrik aufgerufencore_dns_response_rcode_count_total)coredns_dns_request_duration_seconds_sum, der Fehler (coredns_dns_responses_total, NXDOMAIN, SERVFAIL FormErr) und des Speicherverbrauchs von CoreDNS Pod in Betracht ziehen.

Zur Fehlerbehebung können Sie kubectl verwenden, um CoreDNS-Protokolle anzuzeigen:

for p in $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].metadata.name}'); do kubectl logs $p -n kube-system; done

Verwenden NodeLocal DNSCache

Sie können die Cluster-DNS-Leistung verbessern, indem Sie Folgendes NodeLocalDNSCacheausführen: Diese Funktion führt einen DNS-Caching-Agenten auf Clusterknoten als DaemonSet aus. Alle Pods verwenden den DNS-Caching-Agenten, der auf dem Knoten ausgeführt wird, für die Namensauflösung, anstatt Service zu verwendenkube-dns.

cluster-proportional-scalerFür CoreDNS konfigurieren

Eine weitere Methode zur Verbesserung der Cluster-DNS-Leistung besteht darin, die CoreDNS-Bereitstellung automatisch horizontal auf der Grundlage der Anzahl der Knoten und CPU-Kerne im Cluster zu skalieren. Horizontal cluster-proportional-autoscaler ist ein Container, der die Größe der Anzahl der Replikate einer Bereitstellung auf der Grundlage der Größe der planbaren Datenebene ändert.

Knoten und die Summe der CPU-Kerne in den Knoten sind die beiden Metriken, mit denen Sie CoreDNS skalieren können. Sie können beide Metriken gleichzeitig verwenden. Wenn Sie größere Knoten verwenden, basiert die CoreDNS-Skalierung auf der Anzahl der CPU-Kerne. Wenn Sie dagegen kleinere Knoten verwenden, hängt die Anzahl der CoreDNS-Replikate von den CPU-Kernen in Ihrer Datenebene ab. Die proportionale Autoscaler-Konfiguration sieht wie folgt aus:

linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'

Auswahl eines AMI mit Node Group

EKS bietet optimierte Lösungen EC2 AMIs , mit denen Kunden sowohl selbstverwaltete als auch verwaltete Knotengruppen erstellen können. Diese AMIs werden in jeder Region für jede unterstützte Kubernetes-Version veröffentlicht. EKS markiert diese AMIs als veraltet, wenn irgendwelche CVEs Fehler entdeckt werden. Daher wird empfohlen, bei der Auswahl eines AMI für die AMIs Knotengruppe nicht veraltete Versionen zu verwenden.

Veraltete Versionen AMIs können mithilfe der Ec2 describe-images API mit dem folgenden Befehl gefiltert werden:

aws ec2 describe-images --image-id ami-0d551c4f633e7679c --no-include-deprecated

Sie können ein veraltetes AMI auch erkennen, indem Sie überprüfen, ob die Describe-Image-Ausgabe ein AS-Feld enthält. DeprecationTime Zum Beispiel:

aws ec2 describe-images --image-id ami-xxx --no-include-deprecated
{
    "Images": [
        {
            "Architecture": "x86_64",
            "CreationDate": "2022-07-13T15:54:06.000Z",
            "ImageId": "ami-xxx",
            "ImageLocation": "123456789012/eks_xxx",
            "ImageType": "machine",
            "Public": false,
            "OwnerId": "123456789012",
            "PlatformDetails": "Linux/UNIX",
            "UsageOperation": "RunInstances",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/xvda",
                    "Ebs": {
                        "DeleteOnTermination": true,
                        "SnapshotId": "snap-0993a2fc4bbf4f7f4",
                        "VolumeSize": 20,
                        "VolumeType": "gp2",
                        "Encrypted": false
                    }
                }
            ],
            "Description": "EKS Kubernetes Worker AMI with AmazonLinux2 image, (k8s: 1.19.15, docker: 20.10.13-2.amzn2, containerd: 1.4.13-3.amzn2)",
            "EnaSupport": true,
            "Hypervisor": "xen",
            "Name": "aws_eks_optimized_xxx",
            "RootDeviceName": "/dev/xvda",
            "RootDeviceType": "ebs",
            "SriovNetSupport": "simple",
            "VirtualizationType": "hvm",
            "DeprecationTime": "2023-02-09T19:41:00.000Z"
        }
    ]
}