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.

Cluster-Dienste

Clusterdienste werden in einem EKS-Cluster ausgeführt, es handelt sich jedoch nicht um Benutzer-Workloads. Wenn Sie einen Linux-Server haben, müssen Sie häufig Dienste wie NTP, Syslog und eine Container-Runtime ausführen, um Ihre Workloads zu unterstützen. Clusterdienste sind ähnlich und unterstützen Dienste, die Sie bei der Automatisierung und dem Betrieb Ihres Clusters unterstützen. In Kubernetes werden diese normalerweise im Kube-System-Namespace ausgeführt, und einige werden als ausgeführt. DaemonSets

Es wird erwartet, dass Clusterdienste eine hohe Verfügbarkeit haben und bei Ausfällen und zur Fehlerbehebung häufig von entscheidender Bedeutung sind. Wenn ein zentraler Clusterdienst nicht verfügbar ist, verlieren Sie möglicherweise den Zugriff auf Daten, die bei der Wiederherstellung helfen oder einen Ausfall verhindern können (z. B. hohe Festplattenauslastung). Sie sollten auf dedizierten Recheninstanzen wie einer separaten Knotengruppe oder AWS Fargate ausgeführt werden. Dadurch wird sichergestellt, dass die Cluster-Services auf gemeinsam genutzten Instances nicht durch Workloads beeinträchtigt werden, die möglicherweise hochskaliert werden oder mehr Ressourcen beanspruchen.

Skalieren Sie CoreDNS

Die Skalierung von CoreDNS hat zwei Hauptmechanismen. Reduzierung der Anzahl der Aufrufe des CoreDNS-Dienstes und Erhöhung der Anzahl der Replikate.

Reduzieren Sie externe Abfragen, indem Sie die Anzahl der N-Punkte verringern

Die Einstellung ndots gibt an, wie viele Punkte (auch bekannt als „Punkte“) in einem Domainnamen als ausreichend angesehen werden, um eine DNS-Abfrage zu vermeiden. Wenn Ihre Anwendung eine ndots-Einstellung von 5 (Standard) hat und Sie Ressourcen von einer externen Domain wie api.example.com (2 Punkte) anfordern, wird CoreDNS für jede Suchdomain abgefragt, die in/.conf für eine spezifischere Domain definiert ist. etc/resolv Standardmäßig werden die folgenden Domänen durchsucht, bevor eine externe Anfrage gestellt wird.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

Die region Werte namespace und werden durch Ihren Workloads-Namespace und Ihre Rechenregion ersetzt. Je nach Ihren Cluster-Einstellungen verfügen Sie möglicherweise über zusätzliche Suchdomänen.

Sie können die Anzahl der Anfragen an CoreDNS reduzieren, indem Sie die Ndots-Option Ihres Workloads verringern oder Ihre Domain-Anfragen vollständig qualifizieren, indem Sie ein Trailing hinzufügen. (z. B.). api.example.com. Wenn Ihr Workload über DNS eine Verbindung zu externen Diensten herstellt, empfehlen wir, ndots auf 2 zu setzen, damit Workloads das Clustern von DNS-Abfragen innerhalb des Clusters nicht unnötig machen. Sie können einen anderen DNS-Server und eine andere Suchdomain einrichten, wenn für die Arbeitslast kein Zugriff auf Dienste innerhalb des Clusters erforderlich ist.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

Wenn Sie ndots auf einen zu niedrigen Wert herabsetzen oder die Domänen, zu denen Sie eine Verbindung herstellen, nicht genügend Spezifität aufweisen (einschließlich der nachfolgenden.), schlagen DNS-Lookups möglicherweise fehl. Stellen Sie sicher, dass Sie testen, wie sich diese Einstellung auf Ihre Workloads auswirkt.

Skalieren Sie CoreDNS horizontal

CoreDNS-Instanzen können skaliert werden, indem zusätzliche Replikate zur Bereitstellung hinzugefügt werden. Es wird empfohlen, NodeLocal DNS oder den proportionalen Cluster-Autoscaler zu verwenden, um CoreDNS zu skalieren.

NodeLocal DNS erfordert die Ausführung einer Instanz pro Knoten — als —, DaemonSet wodurch mehr Rechenressourcen im Cluster benötigt werden. Dadurch werden jedoch fehlgeschlagene DNS-Anfragen vermieden und die Antwortzeit für DNS-Abfragen im Cluster verringert. Der proportionale Cluster-Autoscaler skaliert CoreDNS auf der Grundlage der Anzahl der Knoten oder Kerne im Cluster. Dies ist kein direkter Zusammenhang mit Anforderungsabfragen, kann aber je nach Workloads und Clustergröße nützlich sein. Die standardmäßige proportionale Skalierung besteht darin, für jeweils 256 Kerne oder 16 Knoten im Cluster ein zusätzliches Replikat hinzuzufügen — je nachdem, was zuerst eintritt.

Wenn Sie das CoreDNS EKS-Add-on verwenden, sollten Sie erwägen, die Autoscaling-Option zu aktivieren. https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html Der CoreDNS-Autoscaler passt die Anzahl der CoreDNS-Replikate dynamisch an, indem er die Anzahl der Knoten und die CPU-Kerne überwacht. Dabei wird eine Formel verwendet, die das Maximum von (nodes÷16) oder (CPU-Cores÷256) annimmt und bei Bedarf sofort hochskaliert und schrittweise herunterskaliert, um die Stabilität aufrechtzuerhalten.

Skalieren Sie den Kubernetes Metrics Server vertikal

Der Kubernetes Metrics Server unterstützt horizontale und vertikale Skalierung. Durch die horizontale Skalierung des Metrics Servers wird er hochverfügbar sein, aber er wird nicht horizontal skaliert, um mehr Cluster-Metriken verarbeiten zu können. Sie müssen den Metric-Server auf der Grundlage seiner Empfehlungen vertikal skalieren, da Knoten und gesammelte Metriken dem Cluster hinzugefügt werden.

Der Metrics-Server speichert die Daten, die er sammelt, aggregiert und bereitstellt, im Arbeitsspeicher. Wenn ein Cluster wächst, nimmt die Datenmenge zu, die der Metrics Server speichert. In großen Clustern benötigt der Metrics Server mehr Rechenressourcen als die in der Standardinstallation angegebene Speicher- und CPU-Reservierung. Sie können den Vertical Pod Autoscaler (VPA) oder den Addon Resizer verwenden, um den Metrics Server zu skalieren. Der Addon Resizer skaliert vertikal proportional zu den Worker-Nodes und VPA skaliert je nach CPU- und Speicherauslastung.

Dauer des CoreDNS Lameduck

Pods verwenden den kube-dns Service zur Namensauflösung. Kubernetes verwendet Destination NAT (DNAT), um den kube-dns Datenverkehr von Knoten zu CoreDNS-Backend-Pods umzuleiten. Während Sie das CoreDNS-Deployment skalieren, kube-proxy aktualisiert es die iptables-Regeln und -Ketten auf den Knoten, um den DNS-Verkehr an CoreDNS-Pods umzuleiten. Die Verbreitung neuer Endpunkte beim Hochskalieren und das Löschen von Regeln beim Herunterskalieren von CoreDNS kann je nach Größe des Clusters zwischen 1 und 10 Sekunden dauern.

Diese Übertragungsverzögerung kann zu Fehlern bei der DNS-Suche führen, wenn ein CoreDNS-Pod beendet wird, die Iptables-Regeln des Knotens jedoch nicht aktualisiert wurden. In diesem Szenario sendet der Knoten möglicherweise weiterhin DNS-Abfragen an einen beendeten CoreDNS-Pod.

Sie können Fehler bei der DNS-Suche reduzieren, indem Sie in Ihren CoreDNS-Pods eine https://coredns.io/plugins/health/ Lameduck-Dauer festlegen. Im Lameduck-Modus reagiert CoreDNS weiterhin auf Anfragen während des Fluges. Wenn Sie eine Lameduck-Dauer festlegen, wird der CoreDNS-Shutdown-Vorgang verzögert, sodass die Knoten die Zeit haben, die sie benötigen, um ihre Iptables-Regeln und -Ketten zu aktualisieren.

Wir empfehlen, die Dauer von CoreDNS-Lameduck auf 30 Sekunden einzustellen.

Prüfung der CoreDNS-Bereitschaft

Wir empfehlen, /ready anstelle von /health für den Bereitschaftstest von CoreDNS zu verwenden.

In Übereinstimmung mit der früheren Empfehlung, die Lameduck-Dauer auf 30 Sekunden festzulegen, sodass ausreichend Zeit für die Aktualisierung der Iptables-Regeln des Knotens vor der Pod-Beendigung zur Verfügung steht, stellt der Einsatz /ready statt /health für die CoreDNS-Bereitschaftsprüfung sicher, dass der CoreDNS-Pod beim Start vollständig vorbereitet ist, um umgehend auf DNS-Anfragen zu antworten.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

Weitere Informationen zum CoreDNS Ready-Plugin finden Sie unter https://coredns.io/plugins/ready/

Agenten zur Protokollierung und Überwachung

Die Protokollierung und Überwachung von Agents kann Ihre Cluster-Steuerungsebene erheblich belasten, da die Agenten den API-Server abfragen, um Protokolle und Metriken mit Workload-Metadaten anzureichern. Der Agent auf einem Knoten hat nur Zugriff auf die lokalen Knotenressourcen, um Dinge wie Container und Prozessnamen zu sehen. Wenn er den API-Server abfragt, kann er weitere Details wie den Namen und die Labels der Kubernetes-Bereitstellung hinzufügen. Dies kann bei der Fehlerbehebung äußerst hilfreich sein, sich jedoch nachteilig auf die Skalierung auswirken.

Da es so viele verschiedene Optionen für die Protokollierung und Überwachung gibt, können wir nicht für jeden Anbieter Beispiele zeigen. Bei Fluentbit empfehlen wir, das Abrufen von Metadaten vom lokalen Kubelet statt vom Kubernetes-API-Server Kube_Meta_Cache_TTL zu aktivieren Use_Kubelet und eine Zahl festzulegen, die wiederholte Aufrufe reduziert, wenn Daten zwischengespeichert werden können (z. B. 60).

Bei der Skalierung von Überwachung und Protokollierung gibt es zwei allgemeine Optionen:

Das Deaktivieren von Integrationen ist oft keine Option, da Sie Protokollmetadaten verlieren. Dadurch entfällt das Problem der API-Skalierung, aber es führt zu weiteren Problemen, da nicht die erforderlichen Metadaten zur Verfügung stehen, wenn sie benötigt werden.

Durch Sampling und Filterung wird die Anzahl der gesammelten Metriken und Protokolle reduziert. Dadurch wird die Anzahl der Anfragen an die Kubernetes-API reduziert und der Speicherbedarf für die gesammelten Metriken und Logs reduziert. Eine Reduzierung der Speicherkosten senkt die Kosten für das Gesamtsystem.

Die Möglichkeit, die Probenentnahme zu konfigurieren, hängt von der Agentsoftware ab und kann an verschiedenen Stellen der Aufnahme implementiert werden. Es ist wichtig, das Sampling so nah wie möglich am Agenten vorzunehmen, da dort wahrscheinlich die API-Serveranrufe stattfinden. Wenden Sie sich an Ihren Anbieter, um mehr über den Sampling-Support zu erfahren.

Wenn Sie CloudWatch Logs verwenden CloudWatch , können Sie mithilfe der in der Dokumentation beschriebenen Muster eine Agentenfilterung hinzufügen.

Um den Verlust von Protokollen und Messwerten zu vermeiden, sollten Sie Ihre Daten an ein System senden, das Daten im Falle eines Ausfalls auf dem empfangenden Endpunkt zwischenspeichern kann. Mit Fluentbit können Sie Amazon Kinesis Data Firehose verwenden, um Daten vorübergehend aufzubewahren, wodurch das Risiko einer Überlastung Ihres endgültigen Datenspeicherorts verringert werden kann.