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.

VPCund Überlegungen zum Subnetz

Für den Betrieb eines EKS Clusters sind neben AWS VPC Kubernetes-Netzwerkkenntnissen auch Netzwerkkenntnisse erforderlich.

Wir empfehlen Ihnen, sich mit den Kommunikationsmechanismen der EKS Steuerungsebene vertraut zu machen, bevor Sie mit dem Entwurf Ihrer Cluster VPC oder der Implementierung vorhandener Cluster beginnen. VPCs

Weitere Informationen finden Sie unter VPCÜberlegungen zu Clustern und Überlegungen zu EKS Amazon-Sicherheitsgruppen bei der Architektur von Subnetzen, mit denen Sie verwendet werden sollen. VPC EKS

Übersicht

EKSCluster-Architektur

Ein EKS Cluster besteht aus zweiVPCs:

Die Knoten im Kunden VPC müssen in der Lage sein, eine Verbindung zum verwalteten API Serverendpunkt im herzustellen. AWS VPC Auf diese Weise können sich die Knoten bei der Kubernetes-Steuerebene registrieren und Anfragen zur Ausführung von Anwendungs-Pods empfangen.

Die Knoten stellen über (a) einen EKS öffentlichen Endpunkt oder (b) eine kontenübergreifende elastische Netzwerkschnittstelle (X-ENI), die von verwaltet wird, eine Verbindung zur EKS Kontrollebene her. EKS Wenn ein Cluster erstellt wird, müssen Sie mindestens zwei VPC Subnetze angeben. EKSplatziert ENI in jedem Subnetz, das bei der Clustererstellung angegeben wurde (auch Cluster-Subnetze genannt), ein X-. Der API Kubernetes-Server verwendet diese Cros-Accounts, um mit Knoten ENIs zu kommunizieren, die in den vom Kunden verwalteten Cluster-Subnetzen bereitgestellt werden. VPC

Beim Start des Knotens wird das EKS Bootstrap-Skript ausgeführt und die Kubernetes-Knotenkonfigurationsdateien werden installiert. Als Teil des Startvorgangs auf jeder Instanz werden die Container-Runtime-Agents, Kubelet- und Kubernetes-Node-Agents gestartet.

Um einen Knoten zu registrieren, kontaktiert Kubelet den Kubernetes-Cluster-Endpunkt. Es stellt eine Verbindung entweder mit dem öffentlichen Endpunkt außerhalb des VPC oder mit dem privaten Endpunkt innerhalb von her. VPC Kubelet erhält API Anweisungen und sendet regelmäßig Statusaktualisierungen und Heartbeats an den Endpunkt.

EKSKommunikation auf der Kontrollebene

EKSbietet zwei Möglichkeiten, den Zugriff auf den Cluster-Endpunkt zu kontrollieren. Mit der Endpunktzugriffskontrolle können Sie wählen, ob der Endpunkt über das öffentliche Internet oder nur über Ihren erreicht werden kannVPC. Sie können den öffentlichen Endpunkt (was die Standardeinstellung ist), den privaten Endpunkt oder beide gleichzeitig einschalten.

Die Konfiguration des API Cluster-Endpunkts bestimmt den Pfad, den Knoten nehmen, um mit der Steuerungsebene zu kommunizieren. Beachten Sie, dass diese Endpunkteinstellungen jederzeit über die EKS Konsole oder geändert werden könnenAPI.

Öffentlicher Endpunkt

Dies ist das Standardverhalten für neue EKS Amazon-Cluster. Wenn nur der öffentliche Endpunkt für den Cluster aktiviert ist, verlassen API Kubernetes-Anfragen, die aus Ihrem Cluster stammen VPC (z. B. der Worker-Node zur Steuerung der Kommunikation auf der Ebene)VPC, das Netzwerk, aber nicht das Amazon-Netzwerk. Damit Knoten eine Verbindung zur Kontrollebene herstellen können, benötigen sie eine öffentliche IP-Adresse und eine Route zu einem Internet-Gateway oder eine Route zu einem NAT Gateway, wo sie die öffentliche IP-Adresse des NAT Gateways verwenden können.

Öffentlicher und privater Endpunkt

Wenn sowohl der öffentliche als auch der private Endpunkt aktiviert sind, VPC kommunizieren API Kubernetes-Anfragen innerhalb des Systems mit der Steuerungsebene über das X- ENIs in Ihrem. VPC Ihr API Cluster-Server ist über das Internet zugänglich.

Privater Endpunkt

Es gibt keinen öffentlichen Zugriff auf Ihren API Server über das Internet, wenn nur der private Endpunkt aktiviert ist. Der gesamte Datenverkehr zu Ihrem API Clusterserver muss aus Ihrem Cluster VPC oder einem verbundenen Netzwerk stammen. Die Knoten kommunizieren mit dem API Server über X- ENIs in IhremVPC. Beachten Sie, dass Clusterverwaltungstools Zugriff auf den privaten Endpunkt haben müssen. Erfahren Sie mehr darüber, wie Sie von außerhalb des Amazonas eine Verbindung zu einem privaten EKS Amazon-Cluster-Endpunkt herstellen könnenVPC.

Beachten Sie, dass der API Serverendpunkt des Clusters von öffentlichen DNS Servern in eine private IP-Adresse von aufgelöst wirdVPC. In der Vergangenheit konnte der Endpunkt nur innerhalb von aufgelöst werdenVPC.

VPCKonfigurationen

Amazon VPC unterstützt IPv4 und IPv6 adressiert. Amazon EKS unterstützt IPv4 standardmäßig. A VPC muss ein IPv4 CIDR Block zugeordnet sein. Sie können Ihrem optional mehrere IPv4 Classless Inter-Domain Routing (CIDR) -Blöcke und mehrere IPv6 CIDR Blöcke zuordnen. VPC Wenn Sie einen erstellenVPC, müssen Sie einen IPv4 CIDR Block für die VPC aus den privaten IPv4 Adressbereichen, wie in RFC 1918 beschrieben, angeben. Die zulässige Blockgröße liegt zwischen einem /16 Präfix (65.536 IP-Adressen) und einem /28 Präfix (16 IP-Adressen).

Wenn Sie einen neuen Block erstellenVPC, können Sie einen einzelnen IPv6 CIDR Block anhängen und bis zu fünf, wenn Sie einen vorhandenen Block ändern. VPC Die Präfixlänge der IPv6 CIDR Blockgröße kann zwischen /44 und /60 und für die IPv6 Subnetze zwischen /44/ und /64 liegen. Sie können einen IPv6 CIDR Block aus dem von Amazon verwalteten IPv6 Adresspool anfordern. Weitere Informationen finden Sie im Abschnitt VPCCIDRBlöcke des VPC Benutzerhandbuchs.

EKSAmazon-Cluster unterstützen IPv4 sowohl als auchIPv6. Standardmäßig verwenden EKS Cluster IPv4 IP. Wenn Sie dies IPv6 bei der Clustererstellung angeben, können Sie IPv6 Cluster verwenden. IPv6Cluster benötigen Dual-Stack VPCs und Subnetze.

Amazon EKS empfiehlt, bei der Clustererstellung mindestens zwei Subnetze zu verwenden, die sich in unterschiedlichen Availability Zones befinden. Die Subnetze, die Sie bei der Clustererstellung übergeben, werden als Cluster-Subnetze bezeichnet. Wenn Sie einen Cluster erstellen, EKS erstellt Amazon bis zu 4 kontoübergreifende Konten (x-account oder x-ENIs) ENIs in den von Ihnen angegebenen Subnetzen. Die X- ENIs werden immer bereitgestellt und für den Cluster-Administrationsdatenverkehr wie Protokollzustellung, Exec und Proxy verwendet. Vollständige VPC Informationen zu den Subnetzanforderungen finden Sie im EKS Benutzerhandbuch.

Kubernetes-Worker-Knoten können in den Cluster-Subnetzen ausgeführt werden, dies wird jedoch nicht empfohlen. Während Cluster-Upgrades stellt Amazon zusätzliche EKS Subnetze ENIs in den Cluster-Subnetzen bereit. Wenn Ihr Cluster horizontal skaliert wird, verbrauchen Worker-Knoten und Pods möglicherweise die IPs im Cluster-Subnetz verfügbaren Ressourcen. Um sicherzustellen, dass genügend verfügbar sind, sollten IPs Sie daher die Verwendung von dedizierten Cluster-Subnetzen mit der Netzmaske /28 in Betracht ziehen.

Kubernetes-Worker-Knoten können entweder in einem öffentlichen oder einem privaten Subnetz ausgeführt werden. Ob ein Subnetz öffentlich oder privat ist, bezieht sich darauf, ob der Verkehr innerhalb des Subnetzes über ein Internet-Gateway geleitet wird. Öffentliche Subnetze haben einen Routing-Tabelleneintrag zum Internet über das Internet-Gateway, private Subnetze jedoch nicht.

Der Verkehr, der woanders entsteht und Ihre Knoten erreicht, wird als Ingress bezeichnet. Der Verkehr, der von den Knoten ausgeht und das Netzwerk verlässt, wird als Egress bezeichnet. Knoten mit öffentlichen oder elastischen IP-Adressen (EIPs) innerhalb eines Subnetzes, das mit einem Internet-Gateway konfiguriert ist, ermöglichen den Zugriff von außerhalb des. VPC Private Subnetze verfügen in der Regel über ein Routing zu einem NATGateway, wodurch eingehender Datenverkehr zu den Knoten in den Subnetzen von außerhalb nicht zugelassen wird, VPC während der Datenverkehr von den Knoten aus dem (ausgehenden) Netzwerk verlassen kann. VPC

IPv6Weltweit ist jede Adresse über das Internet routbar. Die IPv6 Adressen, die den Knoten und Pods zugeordnet sind, sind öffentlich. Private Subnetze werden unterstützt, indem Internet-Gateways (EIGW) nur für ausgehenden Datenverkehr implementiert werdenVPC, die ausgehenden Datenverkehr zulassen und gleichzeitig den gesamten eingehenden Verkehr blockieren. Bewährte Methoden für die Implementierung von IPv6 Subnetzen finden Sie im Benutzerhandbuch. VPC

Sie können Subnetze auf drei verschiedene Arten konfigurierenVPC:

Nur öffentliche Subnetze verwenden

In denselben öffentlichen Subnetzen werden sowohl Knoten als auch Eingangsressourcen (wie Load Balancer) erstellt. Markieren Sie das öffentliche Subnetz mit, um Load Balancer kubernetes.io/role/elbzu erstellen, die mit dem Internet verbunden sind. In dieser Konfiguration kann der Cluster-Endpunkt als öffentlich, privat oder beides (öffentlich und privat) konfiguriert werden.

Verwendung von privaten und öffentlichen Subnetzen

Knoten werden in privaten Subnetzen erstellt, wohingegen Ingress-Ressourcen in öffentlichen Subnetzen instanziiert werden. Sie können öffentlichen, privaten oder beides (öffentlich und privat) Zugriff auf den Cluster-Endpunkt aktivieren. Je nach Konfiguration des Cluster-Endpunkts erfolgt der Knotenverkehr über das NAT Gateway oder denENI.

Es werden nur private Subnetze verwendet

Sowohl Knoten als auch Ingress werden in privaten Subnetzen erstellt. Verwendung des kubernetes.io/role/internal-elbSubnetz-Tags zum Aufbau interner Load Balancer. Für den Zugriff auf den Endpunkt Ihres Clusters ist eine VPN Verbindung erforderlich. Sie müssen AWS PrivateLinkfür alle Amazon EC2 - ECR und S3-Repositorys aktivieren. Nur der private Endpunkt des Clusters sollte aktiviert werden. Wir empfehlen, die Anforderungen für EKS private Cluster durchzugehen, bevor Sie private Cluster bereitstellen.

Kommunikation zwischen VPCs

Es gibt viele Szenarien, in denen mehrere VPCs und separate EKS Cluster für diese bereitgestellt werden müssenVPCs.

Sie können Amazon VPC Lattice verwenden, um Dienste konsistent und sicher über mehrere VPCs Konten hinweg zu verbinden (ohne dass zusätzliche Konnektivität durch Dienste wie VPC Peering AWS PrivateLink oder AWS Transit Gateway bereitgestellt werden muss). Erfahren Sie hier mehr.

Amazon VPC Lattice arbeitet im Link-Local-Adressraum in IPv4 und und bietet Konnektivität zwischen DienstenIPv6, die sich möglicherweise überschneiden. IPv4 Aus Gründen der betrieblichen Effizienz empfehlen wir dringend, EKS Cluster und Knoten in IP-Bereichen bereitzustellen, die sich nicht überschneiden. Falls Ihre Infrastruktur VPCs überlappende IP-Bereiche umfasst, müssen Sie Ihr Netzwerk entsprechend gestalten. Wir empfehlen Private NAT Gateway oder den benutzerdefinierten Netzwerkmodus VPC CNI in Verbindung mit einem Transit-Gateway, um Workloads zu integrieren, um sich überschneidende CIDR Probleme EKS zu lösen und gleichzeitig RFC1918 routingfähige IP-Adressen beizubehalten.

Wenn Sie der Dienstanbieter sind und Ihren Kubernetes-Dienst und Ihren Ingress (entweder ALB oderNLB) in separaten Konten mit Ihrem Kunden teilen möchten, sollten Sie die Nutzung AWS PrivateLinkdieses Dienstes VPC in Erwägung ziehen.

Teilen VPC über mehrere Konten hinweg

Viele Unternehmen haben Amazon VPCs gemeinsam genutzt, um die Netzwerkadministration zu rationalisieren, Kosten zu senken und die Sicherheit mehrerer AWS Konten in einem AWS Unternehmen zu verbessern. Sie verwenden AWS Resource Access Manager (RAM), um unterstützte AWSRessourcen sicher mit einzelnen AWS Konten, Organisationseinheiten (OUs) oder der gesamten AWS Organisation zu teilen.

Sie können EKS Amazon-Cluster, verwaltete Knotengruppen und andere unterstützende AWS Ressourcen (wie LoadBalancers Sicherheitsgruppen, Endpunkte usw.) in gemeinsam genutzten VPC Subnetzen von einem anderen AWS Konto aus bereitstellen. AWS RAM Die folgende Abbildung zeigt ein Beispiel für eine High-Level-Architektur. Dies ermöglicht zentralen Netzwerkteams die Kontrolle über die Netzwerkkonstrukte wie VPCs Subnetze usw., während Anwendungs- oder Plattformteams gleichzeitig EKS Amazon-Cluster in ihren jeweiligen AWS Konten bereitstellen können. Eine vollständige Anleitung dieses Szenarios ist in diesem Github-Repository verfügbar.

Überlegungen zur Verwendung gemeinsam genutzter Subnetze

Sicherheitsgruppen

Eine Sicherheitsgruppe steuert den Datenverkehr, der die Ressourcen erreichen und verlassen darf, mit denen er verknüpft ist. Amazon EKS verwendet Sicherheitsgruppen, um die Kommunikation zwischen der Kontrollebene und den Knoten zu verwalten. Wenn Sie einen Cluster erstellen, EKS erstellt Amazon eine Sicherheitsgruppe mit dem Nameneks-cluster-sg-my-cluster-uniqueID. EKSordnet diese Sicherheitsgruppen den verwalteten Knoten ENIs und den Knoten zu. Die Standardregeln ermöglichen es, dass der gesamte Datenverkehr frei zwischen Ihrem Cluster und Ihren Knoten fließt. Außerdem lassen sie den gesamten ausgehenden Datenverkehr zu jedem Ziel zu.

Wenn Sie einen Cluster erstellen, können Sie Ihre eigenen Sicherheitsgruppen angeben. Bitte beachten Sie die Empfehlung für Sicherheitsgruppen, wenn Sie eigene Sicherheitsgruppen angeben.

Empfehlungen

Erwägen Sie eine Multi-AZ-Bereitstellung

AWSRegionen bieten mehrere physisch getrennte und isolierte Availability Zones (AZ), die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mit Availability Zones können Sie Anwendungen entwerfen und betreiben, die automatisch und ohne Unterbrechung ein Failover zwischen Availability Zones durchführen. Amazon empfiehlt EKS dringend, EKS Cluster in mehreren Availability Zones bereitzustellen. Bitte erwägen Sie, bei der Erstellung des Clusters Subnetze in mindestens zwei Availability Zones anzugeben.

Kubelet, das auf Knoten ausgeführt wird, fügt dem Knotenobjekt automatisch Labels hinzu, wie z. topology.kubernetes.io/region=us-west-2 Wir empfehlen, Node-Labels in Verbindung mit den Beschränkungen der Pod-Topologie zu verwenden, um zu kontrollieren, wie Pods über Zonen verteilt werden. Diese Hinweise ermöglichen es dem Kubernetes-Scheduler, Pods so zu platzieren, dass die erwartete Verfügbarkeit besser ist. Dadurch wird das Risiko verringert, dass sich ein korrelierter Ausfall auf Ihren gesamten Workload auswirkt. Beispiele für Node-Selector- und AZ-Spread-Beschränkungen finden Sie unter Zuweisen von Knoten zu Pods.

Sie können die Subnetze oder Verfügbarkeitszonen definieren, wenn Sie Knoten erstellen. Die Knoten werden in Cluster-Subnetzen platziert, wenn keine Subnetze konfiguriert sind. EKSDurch die Unterstützung verwalteter Knotengruppen werden die Knoten je nach verfügbarer Kapazität automatisch auf mehrere Availability Zones verteilt. Karpenter berücksichtigt die AZ-Spread-Platzierung, indem die Knoten auf die angegebenen Werte skaliert werden, AZs sofern Workloads die Topologie-Spread-Grenzen definieren.

AWSElastic Load Balancer werden vom Load AWS Balancer Controller für einen Kubernetes-Cluster verwaltet. Es stellt einen Application Load Balancer (ALB) für Kubernetes-Eingangsressourcen und einen Network Load Balancer (NLB) für Kubernetes-Dienste vom Typ Loadbalancer bereit. Der Elastic Load Balancer Balancer-Controller verwendet Tags, um die Subnetze zu erkennen. ELBDer Controller benötigt mindestens zwei Availability Zones (AZs), um eingehende Ressourcen erfolgreich bereitzustellen. Erwägen Sie die Einrichtung von Subnetzen in mindestens zweiAZs, um die Sicherheit und Zuverlässigkeit geografischer Redundanz zu nutzen.

Stellen Sie Knoten in privaten Subnetzen bereit

AVPC, das sowohl private als auch öffentliche Subnetze einbezieht, ist die ideale Methode für die Bereitstellung von Kubernetes-Workloads. EKS Erwägen Sie, mindestens zwei öffentliche Subnetze und zwei private Subnetze in zwei unterschiedlichen Verfügbarkeitszonen einzurichten. Die zugehörige Routentabelle eines öffentlichen Subnetzes enthält eine Route zu einem Internet-Gateway. Pods können über ein NAT Gateway mit dem Internet interagieren. Private Subnetze werden von Internet-Gateways in der Umgebung nur für ausgehenden Datenverkehr unterstützt (). IPv6 EIGW

Die Instanziierung von Knoten in privaten Subnetzen bietet maximale Kontrolle über den Datenverkehr zu den Knoten und ist für die überwiegende Mehrheit der Kubernetes-Anwendungen wirksam. Eingangsressourcen (wie Load Balancer) werden in öffentlichen Subnetzen instanziiert und leiten den Datenverkehr an Pods weiter, die in privaten Subnetzen betrieben werden.

Ziehen Sie den Modus „Nur privat“ in Betracht, wenn Sie strenge Sicherheitsvorkehrungen und Netzwerkisolierung benötigen. In dieser Konfiguration werden drei private Subnetze in unterschiedlichen Availability Zones innerhalb der AWS Region bereitgestellt. VPC Die in den Subnetzen bereitgestellten Ressourcen können nicht auf das Internet zugreifen, und das Internet kann auch nicht auf die Ressourcen in den Subnetzen zugreifen. Damit Ihre Kubernetes-Anwendung auf andere AWS Dienste zugreifen kann, müssen Sie PrivateLink Schnittstellen und/oder Gateway-Endpunkte konfigurieren. Sie können interne Load Balancer einrichten, um den Datenverkehr mithilfe des Load AWS Balancer Controllers an Pods umzuleiten. Die privaten Subnetze müssen mit (kubernetes.io/role/internal-elb: 1) gekennzeichnet sein, damit der Controller Load Balancer bereitstellen kann. Damit sich Knoten beim Cluster registrieren können, muss der Cluster-Endpunkt auf den privaten Modus gesetzt werden. Vollständige Anforderungen und Überlegungen finden Sie im Leitfaden für private Cluster.

Ziehen Sie den öffentlichen und privaten Modus für den Cluster-Endpunkt in Betracht

Amazon EKS bietet Cluster-Endpunktmodi public-and-private nur öffentlich und nur privat an. Der Standardmodus ist nur öffentlich. Wir empfehlen jedoch, den Cluster-Endpunkt im öffentlichen und privaten Modus zu konfigurieren. Mit dieser Option können API Kubernetes-Aufrufe innerhalb Ihres Clusters VPC (z. B. node-to-control-plane Kommunikation) den privaten VPC Endpunkt nutzen und der Datenverkehr bleibt innerhalb des Clusters. VPC Ihr API Cluster-Server kann dagegen über das Internet erreicht werden. Wir empfehlen jedoch dringend, die CIDR Blöcke einzuschränken, die den öffentlichen Endpunkt verwenden können. Erfahren Sie, wie Sie den Zugriff auf öffentliche und private Endgeräte konfigurieren, einschließlich der Begrenzung von CIDR Blöcken.

Wir empfehlen einen ausschließlich privaten Endpunkt, wenn Sie Sicherheit und Netzwerkisolierung benötigen. Wir empfehlen, eine der im EKSBenutzerhandbuch aufgeführten Optionen zu verwenden, um eine private Verbindung zu einem API Server herzustellen.

Konfigurieren Sie Sicherheitsgruppen sorgfältig

Amazon EKS unterstützt die Verwendung benutzerdefinierter Sicherheitsgruppen. Alle benutzerdefinierten Sicherheitsgruppen müssen die Kommunikation zwischen Knoten und der Kubernetes-Steuerebene ermöglichen. Bitte überprüfen Sie die Portanforderungen und konfigurieren Sie die Regeln manuell, wenn Ihre Organisation keine offene Kommunikation zulässt.

EKSwendet die benutzerdefinierten Sicherheitsgruppen, die Sie bei der Clustererstellung angeben, auf die verwalteten Schnittstellen an (X-ENIs). Sie werden jedoch nicht sofort Knoten zugeordnet. Beim Erstellen von Knotengruppen wird dringend empfohlen, benutzerdefinierte Sicherheitsgruppen manuell zuzuordnen. Bitte erwägen Sie, securityGroupSelectorTerms zu aktivieren, um die Erkennung benutzerdefinierter Sicherheitsgruppen durch Karpenter bei der automatischen Skalierung von Knoten zu ermöglichen.

Wir empfehlen dringend, eine Sicherheitsgruppe zu erstellen, um den gesamten Kommunikationsverkehr zwischen den Knoten zuzulassen. Während des Bootstrap-Vorgangs benötigen Knoten eine ausgehende Internetverbindung, um auf den Cluster-Endpunkt zugreifen zu können. Bewerten Sie die Anforderungen für den ausgehenden Zugriff, z. B. die Verbindung vor Ort und den Zugriff auf die Container-Registry, und legen Sie die Regeln entsprechend fest. Bevor Sie Änderungen in der Produktionsumgebung vornehmen, empfehlen wir Ihnen dringend, die Verbindungen in Ihrer Entwicklungsumgebung sorgfältig zu überprüfen.

Stellen Sie NAT Gateways in jeder Availability Zone bereit

Wenn Sie Knoten in privaten Subnetzen (IPv4undIPv6) bereitstellen, sollten Sie erwägen, in jeder Availability Zone (AZ) ein NAT Gateway einzurichten, um eine zonenunabhängige Architektur zu gewährleisten und die AZ-übergreifenden Ausgaben zu reduzieren. Jedes NAT Gateway in einer AZ wird redundant implementiert.

Verwenden Sie Cloud9 für den Zugriff auf private Cluster

AWSCloud9 ist webbasiert und IDE kann mithilfe AWS von Systems Manager sicher in privaten Subnetzen ohne Eingangszugriff ausgeführt werden. Egress kann auch auf der Cloud9-Instanz deaktiviert werden. Erfahren Sie mehr über die Verwendung von Cloud9 für den Zugriff auf private Cluster und Subnetze.

📝 Bearbeiten Sie diese Seite auf GitHub