Isolierung von Ingress-Ressourcen auf Edge-Worker-Knoten

Wenn Sie ALB-Pods auf Edge-Worker-Knoten zuweisen möchten, müssen Sie einen Worker-Pool erstellen oder einen vorhandenen verwenden, der mindestens zwei Edge-Worker-Knoten pro Zone umfasst. Dadurch wird sichergestellt, dass stets Edge-Knoten verfügbar sind, auf denen die ALB-Pods eingeplant werden können.

Wenn Sie einen ALB-Pod aktualisieren, wird ein neuer Pod bereitgestellt, der den bestehenden ersetzt. Um die Verfügbarkeit des ALB während des Updates zu gewährleisten, wird im Rahmen eines rollierenden Updates jeweils nur ein Pod ersetzt, sodass stets mindestens ein ALB-Pod aktiv bleibt. Allerdings gelten für ALB-Pods Anti-Affinitätsregeln, die verhindern, dass zwei ALB-Pods auf demselben Worker ausgeführt werden. Wenn in einer Zone mindestens zwei Edge-Knoten vorhanden sind, kann der neue ALB-Pod auf einem davon ausgetauscht werden, während der andere weiterläuft.

Um eine hohe Verfügbarkeit des ALB zu gewährleisten, wird die Kennzeichnung als Edge-Knoten ignoriert, wenn in den einzelnen Regionen nicht genügend Edge-Knoten vorhanden sind, und die ALB-Pods werden auch auf Nicht-Edge-Knoten verteilt.

Die Schritte zur Isolierung von ALB-Workloads auf Edge-Knoten sind sowohl für die klassische als auch für die VPC-Infrastruktur identisch. Die Namenskonvention für die externe IP-Adresse des ALB ist jedoch je nach Typ unterschiedlich. Bei ALBs in der klassischen Infrastruktur handelt es sich bei der externen IP-Adresse um eine Standard-IP-Adresse wie beispielsweise 169.46.17.2. Bei ALBs in einer VPC-Infrastruktur ist die externe IP-Adresse ein Hostname wie beispielsweise f3bee8b5-us-south.lb.appdomain.cloud.

Vorbereitende Schritte

Stellen Sie sicher, dass Sie über die folgenden IAM-Rollen verfügen:
- Beliebige Plattformzugriffsrolle für den Cluster
- Servicezugriffsrolle Schreibberechtigter oder Manager für alle Namensbereiche
Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

Isolierung von Workloads auf Edge-Worker-Knoten

So isolieren Sie Ihre Workload auf Edge-Worker-Knoten:

Erstellen Sie einen Worker-Pool mit der Bezeichnung „ dedicated=edge “ oder fügen Sie die Bezeichnung zu einem Ihrer bestehenden Worker-Pools hinzu.

Um einen „Classic“-Worker-Pool zu erstellen, können Sie den Befehl „ worker-pool create classic “ verwenden.

    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Um einen VPC-Worker-Pool zu erstellen, können Sie den [Befehl](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-create-vpc-gen2-cli) „ `worker-pool create vpc-gen2` “ verwenden.
```sh {: pre}
    ibmcloud oc worker-pool create vpc-gen2 --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Um einen bestehenden Worker-Pool zu kennzeichnen, können Sie den [Befehl](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-label-set-cli) „ `worker-pool label set` “ verwenden.
```sh {: pre}
    ibmcloud oc worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
    ```

Stellen Sie sicher, dass der Worker-Pool und die Workerknoten die Bezeichnung dedicated=edge haben.

Um den Worker-Pool zu überprüfen, verwenden Sie den Befehl „ get “.

    ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* Überprüfen Sie das Feld **Labels** der Ausgabe des folgenden Befehls, um einzelne Workerknoten zu überprüfen.
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

Rufen Sie alle vorhandenen ALBs im Cluster ab. Überprüfen Sie die Befehlsausgabe. Notieren Sie sich für jeden ALB, dessen Status auf „aktiviert“ gesetzt ist, die ALB-ID und die Build-Nummer.

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID

Beispielausgabe

ALB ID                                Enabled   State     Type      Load Balancer Hostname                      Zone         Build                                  Status
private-crc81nk5l10gfhdql4i3qg-alb1   true      enabled   private   e9dd35e6-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   enabled
public-crc81nk5l10gfhdql4i3qg-alb1    true      enabled   public    38daf55c-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   healthy

Führen Sie unter Verwendung der Ausgabe des vorherigen Schritts den Befehl ibmcloud ks ingress alb update für jede aktivierte ALB aus. Mit diesem Befehl wird die ALB erneut auf einem Edge-Workerknoten bereitgestellt.

Wenn Sie diesen Befehl ausführen, um die ALB auf einem Edge-Workerknoten erneut bereitzustellen, wird die ALB auch auf die neueste Version aktualisiert. Wenn Sie die ALB nicht auf die neueste Version aktualisieren möchten, fügen Sie die Option „ --version “ hinzu und geben Sie die Version an, die in der Ausgabe des vorherigen Schritts unter „Build“ aufgeführt ist.
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID> --alb <ALB_ID> [--version <build_version>]
```
Beispielausgabe
```
Updating ALB pods for private-crc81nk5l10gfhdql4i3qg-alb1 to version '3.7.4_348800920_iks' in cluster crc81nk5l10gfhdql4i3qg...
OK
```

Confirm that all ALB pods are deployed to edge nodes. Each public and private ALB that is enabled in your cluster has two pods.

kubectl describe nodes -l dedicated=edge | grep alb

Beispielausgabe

kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-27pv4    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-7p9q6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-s77z6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-kvs9f    0 (0%)        0 (0%)      0 (0%)           0 (0%)

Vergewissern Sie sich, dass keine ALB-Pods auf Nicht-Edge-Knoten bereitgestellt werden.
```
kubectl describe nodes -l dedicated!=edge | grep alb
```
Wenn die ALB-Pods ordnungsgemäß auf Edge-Knoten bereitgestellt werden, werden keine ALB-Pods zurückgegeben. Das bedeutet, dass Ihre ALBs erfolgreich ausschließlich auf Edge-Worker-Knoten neu eingeplant wurden.

Nächste Schritte

Nachdem Sie nun die Worker-Knoten in einem Worker-Pool mit „ dedicated=edge “ gekennzeichnet und alle vorhandenen ALBs auf den Edge-Knoten neu bereitgestellt haben, werden alle nachfolgend zum Cluster hinzugefügten ALBs ebenfalls auf einem Edge-Knoten in Ihrem Edge-Worker-Pool bereitgestellt. Als Nächstes können Sie weitere dass Workloads nicht auf Edge-Worker-Knoten ausgeführt werden verhindern.