Unterstützung für die Verbesserung dieser Seite beitragen
Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.
Knotenklasse für Amazon EKS erstellen
Amazon-EKS-Knotenklassen sind Vorlagen, die eine differenzierte Steuerung der Konfiguration Ihrer im EKS Auto Mode verwalteten Knoten ermöglichen. Eine Knotenklasse definiert Einstellungen auf Infrastrukturebene, die für Knotengruppen in Ihrem EKS-Cluster gelten, einschließlich Netzwerkkonfiguration, Speichereinstellungen und Ressourcen-Kennzeichnung. In diesem Thema wird erläutert, wie Sie eine Knotenklasse erstellen und konfigurieren, um Ihre spezifischen Betriebsanforderungen zu erfüllen.
Wenn Sie die Bereitstellung und Konfiguration von EC2-Instances in EKS Auto Mode über die Standardeinstellungen hinaus anpassen müssen, erhalten Sie durch die Erstellung einer Knotenklasse präzise Kontrolle über wichtige Infrastruktur-Parameter. Beispielsweise können Sie zur Erhöhung der Sicherheit die Platzierung in einem privaten Subnetz festlegen, für leistungssensitive Workloads flüchtigen Instance-Speicher konfigurieren oder zur Kostenverteilung benutzerdefinierte Tags zuweisen.
Erstellung einer Knotenklasse
Um eine NodeClass zu erstellen, gehen Sie wie folgt vor:
-
YAML-Datei (zum Beispiel
nodeclass.yaml) mit Ihrer Knotenklassen-Konfiguration erstellen -
Konfiguration mithilfe von
kubectlauf Ihren Cluster anwenden -
Verweisen Sie in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter Einen Knotenpool für EKS Auto Mode erstellen.
Sie müssen kubectl installiert und konfiguriert haben. Weitere Informationen finden Sie unter Einrichtung zur Verwendung von Amazon EKS.
Beispiel für eine grundlegende Knotenklasse
Hier ist ein Beispiel für eine Knotenklasse:
apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: private-compute spec: subnetSelectorTerms: - tags: Name: "private-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" ephemeralStorage: size: "160Gi"
Diese NodeClass erhöht die Menge des flüchtigen Speichers auf dem Knoten.
Wenden Sie diese Konfiguration wie folgt an
kubectl apply -f nodeclass.yaml
Verweisen Sie anschließend in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter Einen Knotenpool für EKS Auto Mode erstellen.
Knotenklassen-Zugriffseintrag erstellen
Wenn Sie eine benutzerdefinierte Knotenklasse erstellen, müssen Sie einen EKS-Zugriffseintrag erstellen, damit die Knoten dem Cluster beitreten können. EKS erstellt automatisch Zugriffseinträge, wenn Sie die integrierte Knotenklasse und Knoten-Pools verwenden.
Informationen zur Funktionsweise von Zugriffseinträgen finden Sie unter IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren
Beim Erstellen von Zugriffseinträgen für EKS-Auto-Mode-Knotenklassen müssen Sie den EC2-Zugriffseintragstyp verwenden.
Zugriffseintrag mit der CLI erstellen
Um einen Zugriffseintrag für EC2-Knoten zu erstellen und die EKS-Auto-Node-Richtlinie zuzuordnen:
Aktualisieren Sie die folgenden CLI-Befehle mit Ihrem Cluster-Namen und der Knotenrollen-ARN. Die Knotenrollen-ARN ist in der Knotenklasse YAML angegeben.
# Create the access entry for EC2 nodes aws eks create-access-entry \ --cluster-name <cluster-name> \ --principal-arn <node-role-arn> \ --type EC2 # Associate the auto node policy aws eks associate-access-policy \ --cluster-name <cluster-name> \ --principal-arn <node-role-arn> \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \ --access-scope type=cluster
Zugriffseintrag mit CloudFormation erstellen
Um einen Zugriffseintrag für EC2-Knoten zu erstellen und die EKS-Auto-Node-Richtlinie zuzuordnen:
Aktualisieren Sie die folgende CloudFormation mit Ihrem Cluster-Namen und der ARN der Knotenrolle. Die Knotenrollen-ARN ist in der Knotenklasse YAML angegeben.
EKSAutoNodeRoleAccessEntry: Type: AWS::EKS::AccessEntry Properties: ClusterName: <cluster-name> PrincipalArn: <node-role-arn> Type: "EC2" AccessPolicies: - AccessScope: Type: cluster PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy DependsOn: [ <cluster-name> ] # previously defined in CloudFormation
Informationen zum Bereitstellen von CloudFormation-Stacks finden Sie unter Erste Schritte mit CloudFormation
Knotenklassen-Spezifikation
apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: my-node-class spec: # Required fields role: MyNodeRole # IAM role for EC2 instances subnetSelectorTerms: - tags: Name: "private-subnet" kubernetes.io/role/internal-elb: "1" # Alternative using direct subnet ID # - id: "subnet-0123456789abcdef0" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Alternative approaches: # - id: "sg-0123456789abcdef0" # - name: "eks-cluster-security-group" # Optional: Pod subnet selector for advanced networking podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" # Alternative using direct subnet ID # - id: "subnet-0987654321fedcba0" # must include Pod security group selector also podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg" # Alternative using direct security group ID # - id: "sg-0123456789abcdef0" # Optional: Selects on-demand capacity reservations and capacity blocks # for EKS Auto Mode to prioritize. capacityReservationSelectorTerms: - id: cr-56fac701cc1951b03 # Alternative Approaches - tags: Name: "targeted-odcr" # Optional owning account ID filter owner: "012345678901" # Optional fields snatPolicy: Random # or Disabled networkPolicy: DefaultAllow # or DefaultDeny networkPolicyEventLogs: Disabled # or Enabled ephemeralStorage: size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T iops: 3000 # Range: 3000-16000 throughput: 125 # Range: 125-1000 # Optional KMS key for encryption kmsKeyID: "arn:aws:kms:region:account:key/key-id" # Accepted formats: # KMS Key ID # KMS Key ARN # Key Alias Name # Key Alias ARN advancedNetworking: # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass. # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet. associatePublicIPAddress: false # Optional: Forward proxy, commonly requires certificateBundles as well # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use [] noProxy: #Max 50 entries - localhost #Max 255 characters each - 127.0.0.1 #- ::1 # IPv6 localhost #- 0:0:0:0:0:0:0:1 # IPv6 localhost - 169.254.169.254 # EC2 Instance Metadata Service #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service # Domains to exclude, put all VPC endpoints here - .internal - .eks.amazonaws.com # Optional: Custom certificate bundles. certificateBundles: - name: "custom-cert" data: "base64-encoded-cert-data" # Optional: Additional EC2 tags (with restrictions) tags: Environment: "production" Team: "platform" # Note: Cannot use restricted tags like: # - kubernetes.io/cluster/* # - karpenter.sh/provisioner-name # - karpenter.sh/nodepool # - karpenter.sh/nodeclaim # - karpenter.sh/managed-by # - eks.amazonaws.com/nodeclass
Überlegungen
-
Wenn Sie überprüfen möchten, über wie viel lokalen Speicherplatz eine Instance verfügt, können Sie den Knoten beschreiben, um die flüchtige Speicher-Ressource anzuzeigen.
-
Volume-Verschlüsselung – EKS verwendet den konfigurierten benutzerdefinierten KMS-Schlüssel, um das schreibgeschützte Root-Volume der Instance und das schreibgeschützte Daten-Volume zu verschlüsseln.
-
IAM-Rolle des Knotens ersetzen – Wenn Sie die einer
NodeClasszugeordneten IAM-Rolle ändern, müssen Sie einen neuen Zugriffseintrag erstellen. EKS erstellt während der Cluster-Erstellung automatisch einen Zugriffseintrag für die IAM-Rolle des Knotens. Die IAM-Rolle des Knotens erfordert dieAmazonEKSAutoNodePolicy-EKS-Zugriffsrichtlinie. Weitere Informationen finden Sie unter IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren. -
Maximale Pod-Dichte – EKS begrenzt die maximale Anzahl von Pods auf einem Knoten auf 110. Diese Begrenzung wird nach der vorhandenen Berechnung der maximalen Pods angewendet. Weitere Informationen finden Sie unter Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs.
-
Tags – Wenn Sie Tags von Kubernetes auf EC2 übertragen möchten, müssen Sie zusätzliche IAM-Berechtigungen konfigurieren. Weitere Informationen finden Sie unter Weitere Informationen zu Identität und Zugriff in EKS Auto Mode.
-
Standard-Knotenklasse – Benennen Sie Ihre benutzerdefinierte Knotenklasse
defaultnicht. Dies liegt daran, dass EKS Auto Mode eineNodeClassmit dem Namendefaultenthält, die automatisch bereitgestellt wird, wenn Sie mindestens ein integriertesNodePoolaktivieren. Informationen zur Aktivierung des integriertenNodePoolsfinden Sie unter Aktivierung oder Deaktivierung integrierter NodePools. -
subnetSelectorTerms-Verhalten bei mehreren Subnetzen – Wenn mehrere Subnetze vorhanden sind, die densubnetSelectorTerms-Bedingungen entsprechen oder die Sie anhand der ID angeben, erstellt der EKS Auto Mode Knoten, die über die Subnetze verteilt sind.-
Wenn sich die Subnetze in verschiedenen Availability Zones (AZs) befinden, können Sie Kubernetes-Features wie Pod-Topologie-Verteilungsbeschränkungen
und Topologiebasiertes Routing verwenden, um Pods und Datenverkehr über die Zonen zu verteilen. -
Wenn es in derselben AZ mehrere Subnetze gibt, die mit
subnetSelectorTermsübereinstimmen, erstellt EKS Auto Mode Pods auf jedem Knoten, die über die Subnetze in dieser AZ verteilt sind. EKS Auto Mode erstellt sekundäre Netzwerkschnittstellen auf jedem Knoten in den anderen Subnetzen derselben AZ. Die Auswahl erfolgt anhand der Anzahl der verfügbaren IP-Adressen in jedem Subnetz, um die Subnetze effizienter zu nutzen. Sie können jedoch nicht festlegen, welches Subnetz EKS Auto Mode für jeden Pod verwendet. Wenn Sie möchten, dass Pods in bestimmten Subnetzen ausgeführt werden, verwenden Sie stattdessen Subnetz-Auswahl für Pods.
-
Subnetz-Auswahl für Pods
Die podSubnetSelectorTerms- und podSecurityGroupSelectorTerms-Felder und ermöglichen erweiterte Netzwerkkonfigurationen, indem sie es Pods ermöglichen, in anderen Subnetzen als ihren Knoten ausgeführt zu werden. Diese Trennung bietet eine verbesserte Kontrolle über das Routing des Netzwerkverkehrs und die Sicherheitsrichtlinien. Beachten Sie, dass podSecurityGroupSelectorTerms zusammen mit podSubnetSelectorTerms erforderlich sind.
Anwendungsfälle
Verwenden Sie podSubnetSelectorTerms, wenn Sie Folgendes benötigen:
-
Trennen Sie den Infrastruktur-Datenverkehr (Knoten-zu-Knoten-Kommunikation) vom Anwendungs-Datenverkehr (Pod-zu-Pod-Kommunikation).
-
Wenden Sie auf Knoten-Subnetze andere Netzwerkkonfigurationen an als auf Pod-Subnetze.
-
Implementieren Sie unterschiedliche Sicherheitsrichtlinien oder Routing-Regeln für Knoten und Pods.
-
Konfigurieren Sie Reverse-Proxys oder Netzwerkfilter speziell für den Knoten-Datenverkehr, ohne den Pod-Datenverkehr zu beeinträchtigen. Verwenden Sie
advancedNetworkingundcertificateBundles, um Ihren Reverse-Proxy und alle selbstsignierten oder privaten Zertifikate für den Proxy zu definieren.
Beispielkonfiguration
apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole # Subnets for EC2 instances (nodes) subnetSelectorTerms: - tags: Name: "node-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Separate subnets for Pods podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg"
Überlegungen zu Subnetz-Selektoren für Pods
-
Reduzierte Pod-Dichte: Bei Verwendung von
podSubnetSelectorTermskönnen weniger Pods auf jedem Knoten ausgeführt werden, da sich die primäre Netzwerkschnittstelle des Knotens im Knoten-Subnetz befindet und nicht für Pods im Pod-Subnetz verwendet werden kann -
Einschränkungen des Subnetz-Selektors: Die Standardkonfigurationen
subnetSelectorTermsundsecurityGroupSelectorTermsgelten nicht für die Auswahl des Pod-Subnetzes. -
Netzwerk-Planung: Stellen Sie sicher, dass in den Knoten- und Pod-Subnetzen ausreichend IP-Adressraum vorhanden ist, um Ihre Workload-Anforderungen zu erfüllen.
-
Routing-Konfiguration: Stellen Sie sicher, dass die Routing-Tabelle und die Netzwerkzugriffssteuerungsliste (ACL) der Pod-Subnetze ordnungsgemäß für die Kommunikation zwischen Knoten- und Pod-Subnetzen konfiguriert sind.
-
Availability Zones: Stellen Sie sicher, dass Sie Pod-Subnetze über mehrere AZs hinweg erstellt haben. Wenn Sie ein bestimmtes Pod-Subnetz verwenden, muss es sich in derselben AZ wie die Knoten-Subnetz-AZ befinden