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.

VPC-Konfiguration

Dedizierte VPC für Cluster

Standardmäßig eksctl create cluster wird eine dedizierte VPC für den Cluster erstellt. Dies geschieht, um Interferenzen mit vorhandenen Ressourcen aus verschiedenen Gründen zu vermeiden, unter anderem aus Sicherheitsgründen, aber auch, weil es schwierig ist, alle Einstellungen in einer vorhandenen VPC zu erkennen.

VPC CIDR ändern

Wenn Sie Peering mit einer anderen VPC einrichten müssen oder einfach einen größeren oder kleineren Bereich von benötigen IPs, können Sie dies mit --vpc-cidr Flag ändern. Anleitungen zur Auswahl von CIDR-Blöcken, die für die Verwendung in einer AWS-VPC zugelassen sind, finden Sie in den AWS-Dokumenten.

Wenn Sie einen IPv6 Cluster erstellen, können Sie ihn VPC.IPv6Cidr in der Cluster-Konfigurationsdatei konfigurieren. Diese Einstellung befindet sich nur in der Konfigurationsdatei, nicht in einem CLI-Flag.

Wenn Sie einen IPv6 IP-Adressblock besitzen, können Sie auch Ihren eigenen IPv6 Pool mitbringen. Informationen zum Importieren Ihres eigenen Pools finden Sie unter Bringen Sie Ihre eigenen IP-Adressen (BYOIP) zu EC2 Amazon. Verwenden Sie dann die VPC.IPv6Cidr in der Cluster-Konfigurationsdatei enthaltene Konfigurationsdatei, um Eksctl zu konfigurieren.

Verwenden Sie eine vorhandene VPC: gemeinsam mit kops

Sie können die VPC eines vorhandenen Kubernetes-Clusters verwenden, der von kops verwaltet wird. Diese Funktion soll das Peering von Migrationsclustern erleichtern. and/or

Wenn Sie zuvor einen Cluster mit kops erstellt haben, z. B. mit Befehlen, die dem Folgenden ähneln:

export KOPS_STATE_STORE=s3://kops
kops create cluster cluster-1.k8s.local --zones=us-west-2c,us-west-2b,us-west-2a --networking=weave --yes

Sie können in demselben einen EKS-Cluster AZs mit denselben VPC-Subnetzen erstellen (HINWEIS: mindestens 2 AZs/subnets sind erforderlich):

eksctl create cluster --name=cluster-2 --region=us-west-2 --vpc-from-kops-cluster=cluster-1.k8s.local

Bestehende VPC verwenden: andere benutzerdefinierte Konfiguration

eksctlbietet eine gewisse, aber nicht vollständige Flexibilität für benutzerdefinierte VPC- und Subnetztopologien.

Sie können eine vorhandene VPC verwenden, indem Sie private and/or öffentliche Subnetze mit den Flags --vpc-private-subnets und --vpc-public-subnets bereitstellen. Es liegt an Ihnen, sicherzustellen, dass die von Ihnen verwendeten Subnetze korrekt kategorisiert sind, da es keine einfache Möglichkeit gibt, zu überprüfen, ob ein Subnetz tatsächlich privat oder öffentlich ist, da die Konfigurationen variieren.

Anhand dieser Flags eksctl create cluster wird die VPC-ID automatisch bestimmt, es werden jedoch keine Routing-Tabellen oder andere Ressourcen wie internet/NAT Gateways erstellt. Es werden jedoch spezielle Sicherheitsgruppen für die ursprüngliche Knotengruppe und die Kontrollebene erstellt.

Sie müssen sicherstellen, dass mindestens 2 Subnetze in unterschiedlichen AZs Subnetzen bereitgestellt werden. Dieser Zustand wird von EKS überprüft. Wenn Sie eine vorhandene VPC verwenden, werden die folgenden Anforderungen nicht von EKS oder Eksctl durchgesetzt oder überprüft, und EKS erstellt den Cluster. Einige Grundfunktionen des Clusters funktionieren auch ohne diese Anforderungen. (Tagging ist beispielsweise nicht unbedingt erforderlich. Tests haben gezeigt, dass es möglich ist, einen funktionierenden Cluster zu erstellen, ohne dass in den Subnetzen Tags gesetzt werden. Es gibt jedoch keine Garantie dafür, dass dies immer gilt, und Tagging wird empfohlen.)

Standardanforderungen:

Möglicherweise gibt es weitere Anforderungen, die von EKS oder Kubernetes gestellt werden, und es liegt ganz bei Ihnen, diese Anforderungen einzuhalten up-to-date. and/or recommendations, and implement those as needed/possible

Die von eksctl angewendeten Standardeinstellungen für Sicherheitsgruppen reichen möglicherweise aus, um den Zugriff mit Ressourcen in anderen Sicherheitsgruppen gemeinsam zu nutzen. Wenn Sie die ingress/egress Regeln der Sicherheitsgruppen ändern möchten, müssen Sie möglicherweise ein anderes Tool verwenden, um Änderungen zu automatisieren, oder Sie müssen dies über die EC2 Konsole tun.

Verwenden Sie im Zweifelsfall keine benutzerdefinierte VPC. Bei Verwendung eksctl create cluster ohne --vpc-* Flags wird der Cluster immer mit einer voll funktionsfähigen dedizierten VPC konfiguriert.

Beispiele

Erstellen Sie einen Cluster mit einer benutzerdefinierten VPC mit 2x privaten und 2x öffentlichen Subnetzen:

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0426fb4a607393184 \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-009fa0199ec203c37

oder verwenden Sie die folgende äquivalente Konfigurationsdatei:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    private:
      us-west-2a:
          id: "subnet-0ff156e0c4a6d300c"
      us-west-2c:
          id: "subnet-0426fb4a607393184"
    public:
      us-west-2a:
          id: "subnet-0153e560b3129a696"
      us-west-2c:
          id: "subnet-009fa0199ec203c37"

nodeGroups:
  - name: ng-1

Erstellen Sie einen Cluster mit einer benutzerdefinierten VPC mit drei privaten Subnetzen und sorgen Sie dafür, dass die erste Knotengruppe diese Subnetze verwendet:

eksctl create cluster \
  --vpc-private-subnets=subnet-0ff156e0c4a6d300c,subnet-0549cdab573695c03,subnet-0426fb4a607393184 \
  --node-private-networking

oder verwenden Sie die folgende äquivalente Konfigurationsdatei:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    private:
      us-west-2d:
          id: "subnet-0ff156e0c4a6d300c"
      us-west-2c:
          id: "subnet-0549cdab573695c03"
      us-west-2a:
          id: "subnet-0426fb4a607393184"

nodeGroups:
  - name: ng-1
    privateNetworking: true

Erstellen Sie einen Cluster mit benutzerdefinierten öffentlichen VPC 4x-Subnetzen:

eksctl create cluster \
  --vpc-public-subnets=subnet-0153e560b3129a696,subnet-0cc9c5aebe75083fd,subnet-009fa0199ec203c37,subnet-018fa0176ba320e45

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-test
  region: us-west-2

vpc:
  id: "vpc-11111"
  subnets:
    public:
      us-west-2d:
          id: "subnet-0153e560b3129a696"
      us-west-2c:
          id: "subnet-0cc9c5aebe75083fd"
      us-west-2a:
          id: "subnet-009fa0199ec203c37"
      us-west-2b:
          id: "subnet-018fa0176ba320e45"

nodeGroups:
  - name: ng-1

Weitere Beispiele finden Sie im Ordner des Repos: examples

Benutzerdefinierte Sicherheitsgruppe für gemeinsam genutzte Knoten

eksctlerstellt und verwaltet eine Sicherheitsgruppe für gemeinsam genutzte Knoten, die die Kommunikation zwischen nicht verwalteten Knoten und der Cluster-Steuerebene und den verwalteten Knoten ermöglicht.

Wenn Sie stattdessen Ihre eigene benutzerdefinierte Sicherheitsgruppe angeben möchten, können Sie das sharedNodeSecurityGroup Feld in der Konfigurationsdatei überschreiben:

vpc:
  sharedNodeSecurityGroup: sg-0123456789

Standardmäßig eksctl werden bei der Erstellung des Clusters Regeln zu dieser Sicherheitsgruppe hinzugefügt, um die Kommunikation mit und von der Standard-Cluster-Sicherheitsgruppe zu ermöglichen, die EKS erstellt. Die standardmäßige Clustersicherheitsgruppe wird sowohl von der EKS-Steuerebene als auch von verwalteten Knotengruppen verwendet.

Wenn Sie die Sicherheitsgruppenregeln selbst verwalten möchten, können Sie die Erstellung der Regeln eksctl verhindern, indem Sie false in der Konfigurationsdatei Folgendes festlegenmanageSharedNodeSecurityGroupRules:

vpc:
  sharedNodeSecurityGroup: sg-0123456789
  manageSharedNodeSecurityGroupRules: false

NAT-Gateway

Das NAT-Gateway für einen Cluster kann alsDisable, Single (Standard) oder konfiguriert werdenHighlyAvailable. Bei dieser HighlyAvailable Option wird in jeder Availability Zone der Region ein NAT-Gateway bereitgestellt, sodass auch bei einem Ausfall einer AZ die Knoten in der anderen AZs weiterhin mit dem Internet kommunizieren können.

Es kann über das --vpc-nat-mode CLI-Flag oder in der Cluster-Konfigurationsdatei wie im folgenden Beispiel angegeben werden:

vpc:
  nat:
    gateway: HighlyAvailable # other options: Disable, Single (default)

Das vollständige Beispiel finden Sie hier.