Cluster-Dienste

Clusterdienste werden innerhalb eines EKS-Clusters 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 aufweisen und sind bei Ausfällen und bei der Fehlerbehebung häufig von entscheidender Bedeutung. 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 skaliert werden oder mehr Ressourcen verbrauchen.

CoreDNS skalieren

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 Punkte verringern

Die Einstellung ndots gibt an, wie viele Punkte (auch bekannt als „Punkte“) in einem Domainnamen als ausreichend angesehen werden, um DNS-Abfragen 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 in /etc/resolv.conf definierte Suchdomäne für eine spezifischere Domain abgefragt. 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 keine überflüssigen Cluster-DNS-Abfragen innerhalb des Clusters durchführen. Sie können einen anderen DNS-Server und eine andere Suchdomäne einrichten, wenn für den Workload 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 Trailing.), ist es möglich, dass DNS-Lookups fehlschlagen. Stellen Sie sicher, dass Sie testen, wie sich diese Einstellung auf Ihre Workloads auswirkt.

CoreDNS horizontal skalieren

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

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

Skalieren Sie den Kubernetes Metrics Server vertikal

Der Kubernetes Metrics Server unterstützt die horizontale und vertikale Skalierung. Durch die horizontale Skalierung wird der Metrics Server zwar hochverfügbar sein, aber er kann nicht horizontal skaliert werden, um mehr Cluster-Metriken verarbeiten zu können. Sie müssen den Metrics Server auf der Grundlage seiner Empfehlungen vertikal skalieren, wenn 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 Addon Resizer verwenden, um den Metrics Server zu skalieren. Der Addon Resizer skaliert vertikal proportional zu den Worker-Knoten und VPA skaliert basierend auf der CPU- und Speicherauslastung.

Dauer CoreDNS CoreDNS-Lameduck

Pods verwenden den kube-dns Dienst für die Namensauflösung. Kubernetes verwendet Destination NAT (DNAT), um den kube-dns Verkehr von Knoten zu CoreDNS-Backend-Pods umzuleiten. Während Sie die CoreDNS-Bereitstellung skalieren, werden die iptables-Regeln und -Ketten auf Knoten kube-proxy aktualisiert, um den DNS-Verkehr auf CoreDNS-Pods umzuleiten. Das Propagieren 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 Lameduck-Dauer festlegen. Im Lameduck-Modus wird CoreDNS weiterhin auf Anfragen während des Fluges antworten. Die Festlegung einer Lameduck-Dauer verzögert den Vorgang zum Herunterfahren von CoreDNS und gibt den Knoten die Zeit, die sie benötigen, um ihre iptables-Regeln und -Ketten zu aktualisieren.

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

CoreDNS-Bereitschaftstest

Wir empfehlen die Verwendung /ready anstelle von /health für die Bereitschaftsprüfung von CoreDNS.

In Übereinstimmung mit der früheren Empfehlung, die Lameduck-Dauer auf 30 Sekunden festzulegen, um ausreichend Zeit für die Aktualisierung der iptables-Regeln des Nodes vor der Pod-Beendigung zu haben, stellt die Verwendung /ready statt /health für die CoreDNS-Bereitschaftsprobe sicher, dass der CoreDNS-Pod beim Start vollständig darauf vorbereitet ist, 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 protokollieren und überwachen

Protokollierungs- und Überwachungsagenten können Ihre Cluster-Steuerebene 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. Bei der Abfrage des API-Servers können weitere Details wie der Name und die Labels der Kubernetes-Bereitstellung hinzugefügt werden. 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, Use_Kubelet zum Abrufen von Metadaten aus dem lokalen Kubelet statt vom Kubernetes API-Server zu aktivieren und auf eine Zahl festzulegen, die wiederholte Aufrufe reduziert, wenn Daten Kube_Meta_Cache_TTL zwischengespeichert werden können (z. B. 60).

Die Skalierung von Überwachung und Protokollierung bietet zwei allgemeine Optionen:

• Integrationen deaktivieren

• Probenahme und Filterung

Das Deaktivieren von Integrationen ist oft keine Option, da Sie Protokoll-Metadaten verlieren. Dadurch wird das Problem der API-Skalierung behoben, es werden jedoch weitere Probleme auftreten, da die erforderlichen Metadaten bei Bedarf nicht zur Verfügung stehen.

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 Protokolle reduziert. Durch die Reduzierung der Speicherkosten werden die Kosten für das Gesamtsystem gesenkt.

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

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

Um den Verlust von Protokollen und Messdaten zu vermeiden, sollten Sie Ihre Daten an ein System senden, das Daten im Falle eines Ausfalls am Empfangsendpunkt 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.