Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Einrichten des Amazon Cloud-Anbieters

Wichtig:

In Kubernetes 1.27 und später müssen Sie einen externen AWS Cloud Provider verwenden. Interne Cloud-Provider laufen aus. Der Amazon Cloud Provider wurde vollständig entfernt und funktioniert nach einem Upgrade auf Kubernetes 1.27 nicht mehr. Die nachstehenden Schritte sind weiterhin erforderlich, um einen Amazon Cloud Provider einzurichten. Sie können einen externen Cloud Provider einrichten, nachdem Sie eine IAM-Rolle erstellt und die ClusterID konfiguriert haben.

Sie können auch von einem internen zu einem externen AWS Cloud Provider in Kubernetes 1.26 und früher migrieren. Alle bestehenden Cluster müssen vor dem Upgrade auf v1.27 migrieren, um funktionsfähig zu bleiben.

Ab Kubernetes 1.23 müssen Sie das CSIMigrationAWS Feature-Gate deaktivieren, um den internen AWS Cloud Provider zu verwenden. Sie können dies tun, indem Sie feature-gates=CSIMigrationAWS=false als zusätzliches Argument für den Kubelet, Controller-Manager, API-Server und Scheduler des Clusters in der erweiterten Clusterkonfiguration festlegen.

Wenn Sie Amazon als Cloud Provider verwenden, können Sie die folgenden Funktionen nutzen:

Lastenausgleicher: Starten Sie einen AWS Elastic Load Balancer (ELB), wenn Sie Layer-4 Load Balancer in Portzuordnung auswählen oder wenn Sie ein Service mit type: LoadBalancer starten.
Persistente Volumes: Verwenden Sie AWS Elastic Block Stores (EBS) für persistente Volumes.

Siehe das cloud-provider-aws README für weitere Informationen über den Amazon Cloud Provider.

Um den Amazon Cloud Provider einzurichten,

Erstellen Sie eine IAM-Rolle und fügen Sie sie den Instanzen hinzu
Konfigurieren Sie die ClusterID

1. Erstellen Sie eine IAM-Rolle und fügen Sie sie den Instanzen hinzu.

Alle Knoten, die dem Cluster hinzugefügt werden, müssen in der Lage sein, mit EC2 zu interagieren, damit sie Ressourcen erstellen und entfernen können. Sie können diese Interaktion aktivieren, indem Sie eine IAM-Rolle verwenden, die der Instanz zugewiesen ist. Siehe Amazon-Dokumentation: Erstellen einer IAM-Rolle, wie Sie eine IAM-Rolle erstellen. Es gibt zwei Beispielrichtlinien:

Die erste Richtlinie gilt für die Knoten mit der controlplane-Rolle. Diese Knoten müssen in der Lage sein, EC2-Ressourcen zu erstellen/zu entfernen. Die folgende IAM-Richtlinie ist ein Beispiel; bitte entfernen Sie alle nicht benötigten Berechtigungen für Ihren Anwendungsfall.
Die zweite Richtlinie gilt für die Knoten mit der etcd- oder worker-Rolle. Diese Knoten müssen nur in der Lage sein, Informationen von EC2 abzurufen.

Beim Erstellen eines Amazon EC2-Clusters müssen Sie den IAM-Instanzprofilnamen (nicht ARN) der erstellten IAM-Rolle beim Erstellen der Node-Vorlage angeben.

Beim Erstellen eines benutzerdefinierten Clusters müssen Sie die IAM-Rolle manuell an die Instanz(en) anhängen.

IAM-Richtlinie für Knoten mit der controlplane-Rolle:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeLaunchConfigurations",
        "autoscaling:DescribeTags",
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVolumes",
        "ec2:CreateSecurityGroup",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyVolume",
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateRoute",
        "ec2:DeleteRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteVolume",
        "ec2:DetachVolume",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:DescribeVpcs",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:AttachLoadBalancerToSubnets",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancerPolicy",
        "elasticloadbalancing:CreateLoadBalancerListeners",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteLoadBalancerListeners",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DeleteListener",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:DescribeLoadBalancerPolicies",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:ModifyListener",
        "elasticloadbalancing:ModifyTargetGroup",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
        "iam:CreateServiceLinkedRole",
        "kms:DescribeKey"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

IAM-Richtlinie für Knoten mit der etcd- oder worker-Rolle:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ec2:DescribeAvailabilityZones",
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:DescribeRepositories",
        "ecr:ListImages",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    }
  ]
}

2. Konfigurieren Sie die ClusterID.

Die folgenden Ressourcen müssen mit einem ClusterID getaggt werden:

Knoten: Alle in Rancher hinzugefügten Hosts.
Teilnetz: Das für Ihren Cluster verwendete Teilnetz.
Sicherheitsgruppe: Die Sicherheitsgruppe, die für Ihren Cluster verwendet wird.

Taggen Sie nicht mehrere Sicherheitsgruppen. Das Taggen mehrerer Gruppen führt zu einem Fehler beim Erstellen eines Elastic Load Balancers (ELB).

Wenn Sie einen Amazon EC2-Cluster erstellen, wird die ClusterID automatisch für die erstellten Knoten konfiguriert. Andere Ressourcen müssen weiterhin manuell getaggt werden.

Verwenden Sie den folgenden Tag:

Schlüssel = kubernetes.io/cluster/<cluster-id> Wert = owned

Die Festlegung des Wertes des Tags auf owned teilt dem Cluster mit, dass alle Ressourcen mit diesem Tag von diesem Cluster besessen und verwaltet werden.

Wenn Sie Ressourcen zwischen Clustern teilen, können Sie das Tag ändern auf:

Schlüssel = kubernetes.io/cluster/<cluster-id> Wert = shared.

Der Zeichenfolgenwert, <cluster-id>, ist die ID des Kubernetes-Clusters.

Taggen Sie eine Ressource nicht mit mehreren besessenen oder geteilten Tags.

Verwendung des Amazon Elastic Container Registry (ECR)

Die kubelet-Komponente hat die Fähigkeit, ECR-Anmeldeinformationen automatisch zu erhalten, wenn das in Erstellen Sie eine IAM-Rolle und fügen Sie sie den Instanzen hinzu erwähnte IAM-Profil an die Instanz(en) angehängt ist. Bei der Verwendung einer Kubernetes-Version älter als v1.15.0 muss der Amazon-Cloud-Anbieter im Cluster konfiguriert werden. Ab Kubernetes-Version v1.15.0 kann die kubelet ECR-Anmeldeinformationen erhalten, ohne dass der Amazon-Cloud-Anbieter im Cluster konfiguriert ist.

Verwendung des Out-of-Tree AWS Cloud Providers

RKE2
RKE

Benennungskonventionen für Knoten und andere Voraussetzungen müssen befolgt werden, damit der Cloud-Anbieter die Instanz korrekt finden kann.

Von Rancher verwaltete RKE2/K3s-Cluster unterstützen nicht die Konfiguration von providerID. Die Engine setzt jedoch den Knotennamen korrekt, wenn die folgende Konfiguration im Bereitstellungs-Cluster-Objekt festgelegt ist:

spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: aws

Diese Option wird an die Konfiguration der verschiedenen Kubernetes-Komponenten weitergegeben, die auf dem Knoten ausgeführt werden, und muss pro Komponente überschrieben werden, um zu verhindern, dass der in-tree-Anbieter unbeabsichtigt ausgeführt wird:

Überschreiben auf Etcd:

spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kubelet-arg:
            - cloud-provider=external
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/etcd-role
              operator: In
              values:
                - 'true'

Überschreiben auf Control Plane:

spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
        disable-cloud-controller: true
        kube-apiserver-arg:
          - cloud-provider=external
        kube-controller-manager-arg:
          - cloud-provider=external
        kubelet-arg:
          - cloud-provider=external
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'

Überschreiben auf Worker:

spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kubelet-arg:
            - cloud-provider=external
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/worker-role
              operator: In
              values:
                - 'true'

Wählen Sie Amazon, wenn Sie sich auf den oben genannten Mechanismus verlassen, um die Anbieter-ID festzulegen. Andernfalls wählen Sie den Externen (out-of-tree) Cloud-Anbieter, der --cloud-provider=external für Kubernetes-Komponenten festlegt.

Geben Sie das aws-cloud-controller-manager Helm-Chart als zusätzliches Manifest zur Installation an:

spec:
  rkeConfig:
    additionalManifest: |-
      apiVersion: helm.cattle.io/v1
      kind: HelmChart
      metadata:
        name: aws-cloud-controller-manager
        namespace: kube-system
      spec:
        chart: aws-cloud-controller-manager
        repo: https://kubernetes.github.io/cloud-provider-aws
        targetNamespace: kube-system
        bootstrap: true
        valuesContent: |-
          hostNetworking: true
          nodeSelector:
            node-role.kubernetes.io/control-plane: "true"
          args:
            - --configure-cloud-routes=false
            - --v=5
            - --cloud-provider=aws

Die Namenskonventionen für Knoten und andere Voraussetzungen müssen beachtet werden, damit der Cloud-Anbieter die Instanz finden kann. Von Rancher bereitgestellte Cluster unterstützen nicht die Konfiguration von providerID.

Wenn Sie IP-basierte Benennungen verwenden, müssen die Knoten nach der Instanz benannt werden, gefolgt vom regionalen Domänennamen (ip-xxx-xxx-xxx-xxx.ec2.<region>.internal). Wenn Sie einen benutzerdefinierten Domänennamen in den DHCP-Optionen festgelegt haben, müssen Sie --hostname-override auf kube-proxy und kubelet setzen, um dieser Benennungsrichtlinie zu entsprechen.

Um die Namenskonventionen für Knoten zu erfüllen, erlaubt Rancher das Setzen von useInstanceMetadataHostname, wenn der External Amazon Cloud-Anbieter ausgewählt ist. Das Aktivieren von useInstanceMetadataHostname wird den EC2-Metadatenservice abfragen und /hostname als hostname-override für kubelet und kube-proxy festlegen:

rancher_kubernetes_engine_config:
  cloud_provider:
    name: external-aws
    useInstanceMetadataHostname: true

Sie dürfen useInstanceMetadataHostname nicht aktivieren, wenn Sie benutzerdefinierte Werte für hostname-override für benutzerdefinierte Cluster festlegen. Wenn Sie einen benutzerdefinierten Cluster erstellen, fügen Sie --node-name dem docker run Knotenregistrierungsbefehl hinzu, um hostname-override — festzulegen, zum Beispiel "$(hostname -f)". Dies kann manuell oder durch die Verwendung von Erweiterte Optionen anzeigen in der Rancher-Benutzeroberfläche erfolgen, um Node Name hinzuzufügen.

Wählen Sie den Cloud-Anbieter aus.

Die Auswahl von Externes Amazon (out-of-tree) setzt --cloud-provider=external und aktiviert useInstanceMetadataHostname. Wie in Schritt 1 erwähnt, wird das Aktivieren von useInstanceMetadataHostname den EC2-Metadatenservice abfragen und http://169.254.169.254/latest/meta-data/hostname als hostname-override für kubelet und kube-proxy festlegen.

Sie müssen useInstanceMetadataHostname deaktivieren, wenn Sie einen benutzerdefinierten Knotennamen für benutzerdefinierte Cluster über node-name festlegen.
```
rancher_kubernetes_engine_config:
  cloud_provider:
    name: external-aws
    useInstanceMetadataHostname: true/false
```
Bestehende Cluster, die einen Externen Cloud-Anbieter verwenden, setzen --cloud-provider=external für Kubernetes-Komponenten, aber der Knotenname wird nicht gesetzt.
Installieren Sie den AWS Cloud-Controller-Manager, nachdem der Cluster mit der Bereitstellung abgeschlossen ist. Beachten Sie, dass der Cluster nicht erfolgreich bereitgestellt ist und die Knoten sich weiterhin in einem uninitialized Zustand befinden, bis Sie den Cloud-Controller-Manager bereitstellen. Dies kann manuell oder über Helm-Charts in der UI erfolgen.

Verweisen Sie auf die offizielle AWS Upstream-Dokumentation für den Cloud-Controller-Manager.

Installation des Helm-Charts über die Kommandozeilenschnittstelle

RKE2
RKE

Offizielle Upstream-Dokumente für die Installation des Helm-Charts finden Sie auf GitHub.

Fügen Sie das Helm-Repository hinzu:

helm repo add aws-cloud-controller-manager https://kubernetes.github.io/cloud-provider-aws
helm repo update

Erstellen Sie eine values.yaml Datei mit den folgenden Inhalten, um die Standard-values.yaml zu überschreiben:

# values.yaml
hostNetworking: true
tolerations:
  - effect: NoSchedule
    key: node.cloudprovider.kubernetes.io/uninitialized
    value: 'true'
  - effect: NoSchedule
    value: 'true'
    key: node-role.kubernetes.io/control-plane
nodeSelector:
  node-role.kubernetes.io/control-plane: 'true'
args:
  - --configure-cloud-routes=false
  - --use-service-account-credentials=true
  - --v=2
  - --cloud-provider=aws
clusterRoleRules:
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - '*'
  - apiGroups:
      - ""
    resources:
      - nodes/status
    verbs:
      - patch
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - list
      - patch
      - update
      - watch
  - apiGroups:
      - ""
    resources:
      - services/status
    verbs:
      - list
      - patch
      - update
      - watch
  - apiGroups:
     - ''
    resources:
      - serviceaccounts
    verbs:
    - create
    - get
  - apiGroups:
      - ""
    resources:
      - persistentvolumes
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - create
      - get
      - list
      - watch
      - update
  - apiGroups:
      - coordination.k8s.io
    resources:
      - leases
    verbs:
      - create
      - get
      - list
      - watch
      - update
  - apiGroups:
      - ""
    resources:
      - serviceaccounts/token
    verbs:
      - create

Installieren Sie das Helm-Chart:

helm upgrade --install aws-cloud-controller-manager aws-cloud-controller-manager/aws-cloud-controller-manager --values values.yaml

Überprüfen Sie, ob das Helm-Chart erfolgreich installiert wurde:

helm status -n kube-system aws-cloud-controller-manager

(Optional) Überprüfen Sie, ob das Update des Cloud-Controller-Managers erfolgreich war:
```
kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
```

Offizielle Upstream-Dokumente für die Installation des Helm-Charts finden Sie auf GitHub.

Fügen Sie das Helm-Repository hinzu:

helm repo add aws-cloud-controller-manager https://kubernetes.github.io/cloud-provider-aws
helm repo update

Erstellen Sie eine values.yaml Datei mit den folgenden Inhalten, um die Standard-values.yaml zu überschreiben:

# values.yaml
hostNetworking: true
tolerations:
  - effect: NoSchedule
    key: node.cloudprovider.kubernetes.io/uninitialized
    value: 'true'
  - effect: NoSchedule
    value: 'true'
    key: node-role.kubernetes.io/controlplane
nodeSelector:
  node-role.kubernetes.io/controlplane: 'true'
args:
  - --configure-cloud-routes=false
  - --use-service-account-credentials=true
  - --v=2
  - --cloud-provider=aws
clusterRoleRules:
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - '*'
  - apiGroups:
      - ""
    resources:
      - nodes/status
    verbs:
      - patch
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - list
      - patch
      - update
      - watch
  - apiGroups:
      - ""
    resources:
      - services/status
    verbs:
      - list
      - patch
      - update
      - watch
  - apiGroups:
     - ''
    resources:
      - serviceaccounts
    verbs:
    - create
    - get
  - apiGroups:
      - ""
    resources:
      - persistentvolumes
    verbs:
      - get
      - list
      - update
      - watch
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - create
      - get
      - list
      - watch
      - update
  - apiGroups:
      - coordination.k8s.io
    resources:
      - leases
    verbs:
      - create
      - get
      - list
      - watch
      - update
  - apiGroups:
      - ""
    resources:
      - serviceaccounts/token
    verbs:
      - create

Installieren Sie das Helm-Chart:

helm upgrade --install aws-cloud-controller-manager -n kube-system aws-cloud-controller-manager/aws-cloud-controller-manager --values values.yaml

Überprüfen Sie, ob das Helm-Chart erfolgreich installiert wurde:

helm status -n kube-system aws-cloud-controller-manager

Falls vorhanden, bearbeiten Sie das Daemonset, um den Standard-Knotenauswähler node-role.kubernetes.io/control-plane: "" zu entfernen:
```
kubectl edit daemonset aws-cloud-controller-manager -n kube-system
```
(Optional) Überprüfen Sie, ob das Update des Cloud-Controller-Managers erfolgreich war:
```
kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
```

Helm Chart-Installation über die Benutzeroberfläche

RKE2
RKE

Klicken Sie auf ☰ und wählen Sie dann den Namen des Clusters aus der linken Navigation aus.
Wählen Sie Apps > Repositories aus.
Klicken Sie auf die Erstellen Schaltfläche.
Geben Sie https://kubernetes.github.io/cloud-provider-aws im Feld Index-URL ein.
Wählen Sie Apps > Charts aus der linken Navigation und installieren Sie aws-cloud-controller-manager.
Wählen Sie den Namespace kube-system aus und aktivieren Sie Helm-Optionen vor der Installation anpassen.

Fügen Sie die folgenden Containerargumente hinzu:

  - '--use-service-account-credentials=true'
  - '--configure-cloud-routes=false'

Fügen Sie get zu verbs für serviceaccounts Ressourcen in clusterRoleRules hinzu. Dies ermöglicht es dem Cloud-Controller-Manager, beim Starten Dienstkonten abzurufen.
```
  - apiGroups:
      - ''
    resources:
      - serviceaccounts
    verbs:
      - create
      - get
```

Von Rancher bereitgestellte RKE2-Knoten sind mit node-role.kubernetes.io/control-plane markiert. Aktualisieren Sie die Toleranzen und den nodeSelector:

tolerations:
  - effect: NoSchedule
    key: node.cloudprovider.kubernetes.io/uninitialized
    value: 'true'
  - effect: NoSchedule
    value: 'true'
    key: node-role.kubernetes.io/control-plane

nodeSelector:
  node-role.kubernetes.io/control-plane: 'true'

Derzeit gibt es ein bekanntes Problem, bei dem der Knotenauswähler nicht über die Rancher-Benutzeroberfläche aktualisiert werden kann. Fahren Sie mit der Installation des Charts fort und bearbeiten Sie dann das Daemonset manuell, um das nodeSelector festzulegen:

nodeSelector:
  node-role.kubernetes.io/control-plane: 'true'

Installieren Sie das Chart und bestätigen Sie, dass das Daemonset aws-cloud-controller-manager läuft. Überprüfen Sie, ob aws-cloud-controller-manager Pods im Ziel-Namespace (kube-system, sofern nicht in Schritt 6 geändert) laufen.

Klicken Sie auf ☰ und wählen Sie dann den Namen des Clusters aus der linken Navigation aus.
Wählen Sie Apps > Repositories aus.
Klicken Sie auf die Erstellen Schaltfläche.
Geben Sie https://kubernetes.github.io/cloud-provider-aws im Feld Index-URL ein.
Wählen Sie Apps > Charts aus der linken Navigation und installieren Sie aws-cloud-controller-manager.
Wählen Sie den Namespace kube-system aus und aktivieren Sie Helm-Optionen vor der Installation anpassen.

Fügen Sie die folgenden Containerargumente hinzu:

  - '--use-service-account-credentials=true'
  - '--configure-cloud-routes=false'

Fügen Sie get zu verbs für serviceaccounts Ressourcen in clusterRoleRules hinzu. Dies ermöglicht es dem Cloud-Controller-Manager, beim Starten Dienstkonten abzurufen:
```
  - apiGroups:
      - ''
    resources:
      - serviceaccounts
    verbs:
      - create
      - get
```

Von Rancher bereitgestellte RKE-Knoten sind mit node-role.kubernetes.io/controlplane markiert. Aktualisieren Sie die Toleranzen und den nodeSelector:

tolerations:
  - effect: NoSchedule
    key: node.cloudprovider.kubernetes.io/uninitialized
    value: 'true'
  - effect: NoSchedule
    value: 'true'
    key: node-role.kubernetes.io/controlplane

nodeSelector:
  node-role.kubernetes.io/controlplane: 'true'

Derzeit gibt es ein bekanntes Problem, bei dem nodeSelector nicht über die Rancher-Benutzeroberfläche aktualisiert werden kann. Fahren Sie mit der Installation des Charts fort und bearbeiten Sie dann das Daemonset manuell, um das nodeSelector festzulegen:

nodeSelector:
  node-role.kubernetes.io/controlplane: 'true'

Installieren Sie das Chart und bestätigen Sie, dass das Daemonset aws-cloud-controller-manager erfolgreich bereitgestellt wird:
```
kubectl rollout status deployment -n kube-system aws-cloud-controller-manager
```