Automatische Aktualisierungen aktivieren

Wenn Sie automatische Aktualisierungen aktivieren, werden Ihre ALBs auf die Version aktualisiert, die als Standardversion markiert ist. Wenn eine neuere Version zur Standardversion wird, werden Ihre ALBs automatisch auf diese Version aktualisiert.

Wenn in einer Zone in Ihrem Cluster nur ein Workerknoten vorhanden ist und Sie die Anzahl der ALB-Replikate auf 1 setzen, wird dieser einzelne ALB-Pod gelöscht und ein neuer Pod wird immer dann erstellt, wenn Aktualisierungen angewendet werden. Dieser Vorgang kann zu Verkehrsstörungen führen, selbst wenn Sie Worker-Knoten und ALB-Replikate in anderen Zonen haben. Um Verkehrsstörungen zu vermeiden, stellen Sie sicher, dass in jeder Zone mindestens zwei Worker-Knoten vorhanden sind und dass für jeden ALB zwei Replikate vorhanden sind. Beachten Sie, dass während des Aktualisierungsprozesses nur neue Verbindungen zum zweiten ALB-Pod weitergeleitet werden; vorhandene Verbindungen im aktualisierenden ALB-Pod werden sicher beendet. Starten Sie für vorhandene Verbindungen, die während der Aktualisierung beendet werden, eine Wiederholung in Clientanwendungen.

Wartungsfenster für automatische Aktualisierungen planen

Sie können automatische ALB-Updates steuern und verwalten, indem Sie einen benutzerdefinierten Zeitplan ( ConfigMap ) erstellen, in dem Sie den Zeitpunkt für die Updates festlegen.

Um einen Zeitpunkt für automatische Updates festzulegen, konfigurieren Sie die Schlüssel updateEndTime und updateStartTime in der Bereitstellungs ConfigMap. Jeder Schlüssel gibt einen zugeordneten Zeitpunkt im 24-Stunden-Format (HH:MM) an. Beachten Sie, dass diese Zeit in UTC (Coordinated Universal Time, koordinierte Weltzeit) angegeben wird und nicht in Ihrer Ortszeit.

1. Erstellen Sie eine YAML-Datei für Ihre Konfigurationszuordnung. Geben Sie die Felder updateEndTime updateStartTime, und als Schlüssel-Wert-Paare im Feld data an.

   Das folgende Beispiel ConfigMap richtet die automatische Aktualisierungsfunktion so ein, dass ALB-Pods in Ihrem Cluster zwischen 20:34 und 23:59 UTC aktualisiert werden.

   apiVersion: v1
   kind: ConfigMap
   metadata:
       name: ibm-ingress-deploy-config
       namespace: kube-system
   data:
       "updateStartTime": "20:34"
       "updateEndTime": "23:59"
   

2. Stellen Sie die Konfigurationszuordnung in Ihrem Cluster bereit. Die neuen Regeln werden bei der nächsten Aktualisierung angewendet.

   kubectl apply -f <filename>.yaml
   

Automatische Aktualisierungen inaktivieren

Um Fehlerkorrekturen und Sicherheitsupdates zu erhalten, lassen Sie automatische Updates aktiviert. Wenn automatische Aktualisierungen inaktiviert sind, sind Sie für die manuelle Aktualisierung Ihrer ALBs verantwortlich.

Sie können automatische Aktualisierungen für Ihre ALBs inaktivieren, indem Sie ibmcloud ks ingress alb autoupdate disable -c CLUSTER_NAME_OR_ID ausführen.

Verwenden Sie den Befehl ibmcloud ks ingress alb autoupdate get -c CLUSTER_NAME_OR_ID, um zu prüfen, ob automatische Aktualisierungen für den Cluster aktiviert sind. Wenn Sie die automatischen Aktualisierungen wieder aktivieren möchten, können Sie ibmcloud ks ingress alb autoupdate enable -c CLUSTER_NAME_OR_ID ausführen.

Manuelle Aktualisierungen anwenden

Sie können eine einmalige Aktualisierung Ihrer Ingress-ALB-Pods mit dem Befehl ibmcloud ks ingress alb update manuell anwenden. Dieser Befehl wendet die Standard-ALB-Imageversion an, aber Sie können eine andere Version anwenden, indem Sie die Option --version angeben. Weitere Informationen oder Befehlsoptionen finden Sie in der CLI-Referenz.

Wenn Sie Ihr ALB-Image mit der Option --version auf eine bestimmte Version aktualisieren möchten, müssen Sie automatische ALB-Aktualisierungen inaktivieren und diese dann so lange inaktivieren, wie Sie die angegebene Version ausführen wollen. Automatische Updates wenden immer die Standardversion an und überschreiben alle manuellen Updates, die Sie anwenden. Wenn Sie eine andere Version verwenden möchten, können Sie automatische Aktualisierungen nicht aktivieren.

• Um die verfügbaren ALB-Versionen aufzulisten, führen Sie den folgenden Befehl aus.

  ibmcloud ks ingress alb versions --region REGION
  

• Führen Sie den folgenden Befehl aus, um alle ALB-Pods im Cluster zu aktualisieren.

  ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID --version IMAGE_VERSION
  

• Führen Sie den folgenden Befehl aus, um die ALB für bestimmte ALBs zu aktualisieren:

  ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID --version IMAGE_VERSION --alb ALB_ID [--alb ALB_2_ID ...]
  

Unterstützte Imageversionen anzeigen

Führen Sie den folgenden Befehl aus, um die neuesten drei Versionen aufzulisten, die für alle Imagetypen unterstützt werden.

ibmcloud ks ingress alb versions

Beispielausgabe

Kubernetes Ingress versions
1.1.2_2507_iks (default)
1.2.1_2506_iks
0.35.0_1374_iks

Die Kubernetes Ingress-Version hat das Format <community_version>_<ibm_build>_iks. Die IBM Buildnummer gibt den aktuellsten Build des Release von NGINX für Kubernetes Ingress an, den IBM Cloud Kubernetes Service veröffentlicht hat. Beispiel: Die Version 1.1.2_2507_iks gibt den neuesten Build der 0.47.0 Ingress-NGINX-Version an. IBM Cloud Kubernetes Service stellt gegebenenfalls Builds der Community-Imageversion bereit, um Sicherheitslücken zu beheben.

Informationen zu den Änderungen in den einzelnen Versionen der Ingress-Images finden Sie im Ingress-Versionsänderungsprotokoll.

Auf eine frühere Version zurücksetzen

Wenn Ihre ALB-Pods kürzlich aktualisiert wurden, eine benutzerdefinierte Konfiguration für Ihre ALBs jedoch von der neuesten Image-Version betroffen ist, können Sie den Befehl ibmcloud ks ingress alb update mit der Option --version verwenden, um ALB-Pods auf eine frühere, unterstützte Version zurückzusetzen. Die Imageversion, in die Sie Ihre ALB ändern, muss eine unterstützte Imageversion sein, die in der Ausgabe von ibmcloud ks ingress alb versions aufgelistet ist.

Beachten Sie, dass Sie bei einer Zurücksetzung auf eine frühere Version automatische ALB-Aktualisierungen inaktivieren müssen und diese dann inaktiviert lassen müssen, solange Sie die frühere Version ausführen möchten. Automatische Updates wenden immer die neueste Version an und überschreiben alle manuellen Updates, die Sie anwenden. Wenn Sie eine frühere Version verwenden wollen, können Sie automatische Aktualisierungen nicht aktivieren.

Weitere ALBs in einer Zone erstellen

Jede ALB in einer Zone wird als zwei Pods auf verschiedenen Workerknoten bereitgestellt. Um Ihre ALB-Verarbeitungsfunktionen zu skalieren und mehr Verbindungen zu verarbeiten, können Sie zusätzliche ALBs in einer Zone erstellen. Die IP-Adresse der neuen ALB wird automatisch zu Ihrer Ingress-Unterdomäne hinzugefügt.

Wenn Sie einen Mehrzonencluster erstellen, wird in jeder Zone, in der Workerknoten vorhanden sind, eine öffentliche Standard-ALB erstellt. Wenn Sie später eine dieser drei ursprünglichen Zonen entfernen und Worker in einer anderen Zone hinzufügen, wird in dieser neuen Zone kein standardmäßiger öffentlicher ALB erstellt. Sie können in dieser neuen Zone jedoch manuell eine ALB zur Verarbeitung von Verbindungen erstellen.

Bei Verwendung der Ingress-Ressourcenvalidierung wird jede Erstellungs-und Aktualisierungsanforderung von allen ALBs validiert. Wenn keine Pods für eine bestimmte ALB-Instanz ausgeführt werden, können Sie Ingress-Ressourcen möglicherweise nicht auf Ihren Cluster anwenden. Stellen Sie sicher, dass mindestens ein aktiver Pod für jede ALB im aktivierten Status vorhanden ist. Weitere Informationen finden Sie unter Ingress deployment customization reference.

1. Erstellen Sie mithilfe des folgenden Befehls in jeder Zone, in der Workerknoten vorhanden sind, eine ALB:

   Der folgende Befehl gilt für klassische Cluster. Weitere Informationen und Befehlsoptionen finden Sie in der CLI-Referenz.

   ibmcloud ks ingress alb create --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID [--ip IP_ADDRESS] [--version image_version]
   

   Der folgende Befehl gilt für VPC-Cluster. Weitere Informationen und Befehlsoptionen finden Sie in der CLI-Referenz.

   ibmcloud ks ingress alb create vpc-gen2 --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone VPC_ZONE [--version image_version]
   

2. Überprüfen Sie, ob die ALBs, die Sie in jeder Zone erstellt haben, den Status enabled haben. Überprüfen Sie für klassische Cluster, ob eine ALB-IP zugeordnet ist. Überprüfen Sie für VPC-Cluster, ob Hostname der Lastausgleichsfunktion zugeordnet ist.

   ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID
   

   Beispielausgabe für einen klassischen Cluster.

   ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021       -
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019       -
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945       -
   

   Beispielausgabe für einen VPC-Cluster.

   ALB ID                                            Enabled   Status     Type      Load Balancer Hostname                 Zone         Build
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -                                      us-south-2   ingress:1.1.2_2507_iks
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -                                      us-south-1   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-2   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-1   ingress:1.1.2_2507_iks
   

Ändern der Anzahl der ALB-Pod-Replikate

Standardmäßig hat jede ALB 2 Replikate. Sie können Ihre ALB-Verarbeitungsfunktionen anpassen, indem Sie die Anzahl der ALB-Pods manuell ändern oder die dynamische automatische Skalierung aktivieren.

Ein einzelner ALB-Pod kann eine große Anzahl von Anforderungen verarbeiten. Wenn Zeitlimitüberschreitungen, langsame Antworten oder andere Überlastungen auftreten, überprüfen Sie den Status Ihrer Back-End-Anwendung. Stellen Sie sicher, dass ALB der Engpass Ihrer Anwendung ist, bevor Sie ALB-Pods skalieren. Andernfalls liefert sie möglicherweise nicht die erwarteten Ergebnisse.

Für klassische Cluster: Wenn in der Lastausgleichsservicekonfiguration der ALB der Wert externalTrafficPolicy auf Local gesetzt ist, skalieren Sie nicht über 2 Replikate. Klassische Lastausgleichsfunktionen werden mit einer festen Konfiguration von 2 Replikaten ausgeführt und können nur Datenverkehr an ALB-Pods weiterleiten, die sich auf demselben Knoten wie die Pods der Lastausgleichsfunktion befinden.

Standardmäßig werden regelmäßige Ingress-Versionsaktualisierungen automatisch auf Ihren ALBs implementiert. Wenn in einer Zone in Ihrem Cluster nur ein Workerknoten vorhanden ist und Sie die Anzahl der ALB-Replikate auf 1 setzen, wird dieser einzelne ALB-Pod gelöscht und ein neuer Pod wird immer dann erstellt, wenn Aktualisierungen angewendet werden. Dieser Prozess kann zu Unterbrechungen des Datenverkehrs führen, selbst wenn Sie Workerknoten und ALB-Replikate in anderen Zonen haben. Um Datenverkehrsstörungen zu verhindern, müssen Sie sicherstellen, dass in jeder Zone mindestens zwei Workerknoten vorhanden sind und dass für jede ALB zwei Replikate vorhanden sind. Beachten Sie, dass während des Aktualisierungsprozesses nur neue Verbindungen zum zweiten ALB-Pod weitergeleitet werden; vorhandene Verbindungen im aktualisierenden ALB-Pod werden sicher beendet. Es wird empfohlen, dass Clientanwendungen eine Wiederholung für vorhandene Verbindungen einleiten, die während der Aktualisierung beendet werden.

Ändern Sie die Anzahl der ALB-Replikate manuell, indem Sie eine ConfigMaperstellen. Beachten Sie, dass Sie Ihre ALB-Replikate nicht manuell skalieren können, wenn Sie Ihre ALB für die Verwendung dynamischer Skalierung konfiguriert haben.

1. Rufen Sie die IDs für Ihre Lastausgleichsfunktionen für Anwendungen (ALBs) ab.

   ibmcloud ks ingress alb ls -c CLUSTER_NAME_OR_ID
   

2. Erstellen Sie eine YAML-Datei für eine Konfigurationszuordnung (configmap) namens ibm-ingress-deploy-config. Fügen Sie für jede ALB '{"replicas":<number_of_replicas>}' hinzu. Dieses Beispiel erhöht die Anzahl der ALB-Pods auf 4 Replikate.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":4}'
     <alb2-id>: '{"replicas":4}'
     ...
   

3. Erstellen Sie die Konfigurationszuordnung ibm-ingress-deploy-config in Ihrem Cluster.

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. Um die Änderungen zu übernehmen, aktualisieren Sie Ihre ALBs. Bitte beachten Sie, dass es bis zu 5 Minuten dauern kann, bis die Änderungen wirksam werden.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Stellen Sie sicher, dass die Anzahl der ALB-Pods auf die von Ihnen angegebene Anzahl an Replikaten erhöht Ready wurde.

   kubectl get pods -n kube-system | grep alb
   

Beispielbefehle für die Konfiguration der dynamischen automatischen ALB-Skalierung

Beispielbefehl für dynamische Skalierung auf der Basis einer durchschnittlichen CPU-Auslastung von 60%.

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --cpu-average-utilization 60

Beispielbefehl für dynamische Skalierung auf der Basis angepasster Metriken, die in einer Datei mit dem Namen my-custom-metrics.yaml gespeichert sind.

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --custom-metrics-file my-custom-metrics.yaml

Durchschnittliche CPU-Auslastung berechnen

Die folgende Abbildung zeigt ein Beispielszenario für die Bestimmung der CPU-Auslastung bei der Planung Ihrer Konfiguration für automatische Skalierung.

Angenommen, Sie haben einen inaktiven Cluster mit zwei aktiven ALB-Replikaten, die keinen eingehenden Datenverkehr haben. Die CPU-Gesamtanforderung in diesem Fall ist 2*20m=40m. Eines der Replikate kann die 5m-CPU und die andere 7m-CPU verwenden. Die CPU-Auslastung kann anhand der folgenden Formel berechnet werden:

Automatische ALB-Skalierung inaktivieren

Führen Sie den Befehl aus, um die automatische Skalierung für eine ALB zu inaktivieren.

ibmcloud ks ingress alb autoscale unset --alb ALB --cluster CLUSTER