Hinweise

Machen Sie sich vor Beginn mit den folgenden Hinweisen zur Verwendung von angepassten Gateways vertraut.

• Über das verwaltete Istio-Add-on können keine angepassten Gateways, die Sie erstellen, verwaltet oder abgleichen werden. Sie sind für das Erstellen, Verwalten und Pflegen dieser Ressourcen verantwortlich.
• Nachdem Sie Ihr angepasstes Gateway bereitgestellt haben, überprüfen Sie die Protokolle des Istio-Operator-Pods auf Syntaxfehler, indem Sie kubectl logs -n ibm-operators -l name=addon-istio-operator ausführen. Der Istio-Betreiber validiert und gleicht alle Änderungen an benutzerdefinierten IstioOperator (IOP) ab, die Sie vornehmen. Wenn Sie eine Abstimmungsschleife bemerken, die durch die info installer Reconciling IstioOperator Wiederholung in den Protokollen angezeigt wird, führen Sie die Schritte aus, um die Zeile in der Konfiguration zu finden, die den Schleifenfehler verursacht.
• Stellen Sie zudem sicher, dass die Option istio-global-proxy-accessLogFile in der Konfigurationszuordnung managed-istio-custom auf "/dev/stdout" gesetzt ist. Envoy-Proxys geben Zugriffsinformationen in ihrer Standardausgabe aus, die Sie anzeigen können, indem Sie kubectl logs-Befehle für die Envoy-Container ausführen.

Angepasstes Ingress-Gateway für öffentlichen Datenverkehr erstellen

Verwenden Sie eine Ressource IstioOperator (IOP), um eine angepasste Ingress-Gateway-Bereitstellung und einen öffentlichen Lastausgleichsservice in einem Namensbereich custom-gateways zu erstellen.

1. Installieren Sie das Istio-Add-on.

2. Erstellen Sie einen Namensbereich für das angepasste Ingress-Gateway.

   kubectl create namespace custom-gateways
   

3. Erstellen Sie eine YAML-Datei mit dem Namen custom-ingress-iop.yaml für eine Ressource IstioOperator (IOP). Um die angepassten Gateway-Pods zur Ausführung einer bestimmten Version von verwaltetem Istio zu zwingen, geben Sie die Version im Feld tag an. Weitere Informationen finden Sie unter Aktualisierungen und Versionen angepasster Gateways steuern.

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   metadata:
     namespace: ibm-operators
     name: custom-ingressgateway-iop
   spec:
     profile: empty
     hub: icr.io/ext/istio
     # tag: 1.23.5
     components:
       ingressGateways:
         - name: custom-ingressgateway
           label:
             istio: custom-ingressgateway
           namespace: custom-gateways
           enabled: true
           k8s:
             serviceAnnotations:
               service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
   

4. Erstellen Sie die IstioOperator (IOP)-Ressource in Ihrem Cluster. Der verwaltete Istio-Operator im Namensbereich ibm-operators verwendet die IOP-Ressource, um das Ingress-Gateway im Namensbereich custom-gateways mit einem öffentlichen Lastausgleichsservice bereitzustellen und zugänglich zu machen.

   kubectl apply -f ./custom-ingress-iop.yaml
   

5. Überprüfen Sie, ob die Ingress-Gateway-Bereitstellung und der Service im Namensbereich custom-gateways erstellt wurden.

   kubectl get deploy,svc -n custom-gateways
   

   Beispielausgabe

   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/custom-ingressgateway   1/1     1            1           4m53s
   
   NAME                            TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                                                                                                                      AGE
   service/custom-ingressgateway   LoadBalancer   172.21.98.120   52.117.68.222   15020:32656/TCP,80:30576/TCP,443:32689/TCP,15029:31885/TCP,15030:30198/TCP,15031:32637/TCP,15032:30869/TCP,31400:30310/TCP,15443:31698/TCP   4m53s
   

6. Notieren Sie in der Ausgabe für die Lastausgleichsfunktion service/custom-ingressgateway die IP-Adresse (für klassische Cluster) oder den Hostnamen in der Spalte EXTERNAL-IP.

Sie können jetzt den Namen dieser Lastausgleichsfunktion für das Ingress-Gateway (custom-ingressgateway) in einer Ressource vom Typ Gateway angeben, die den Port für Ihre über Istio verwaltete App definiert. Anschließend können Sie den Namen des Gateways (Gateway) in einer Ressource VirtualService angeben, die die Pfade für die Microservices in Ihrem Servicenetz definiert. Ein Beispiel für die Verwendung von Gateway und VirtualService in der Lastausgleichsfunktion Ihres angepassten Gateways finden Sie in der Beispielapp 'BookInfo'.

Angepasstes Ingress-Gateway für privaten Datenverkehr erstellen

Wenn Sie eine angepasste Ingress-Gateway-Bereitstellung erstellen und mit einem privaten Lastausgleichsservice zugänglich machen wollen, führen Sie die Schritte unter Angepasstes Ingress-Gateway für öffentlichen Datenverkehr erstellen aus. Wenn Sie den IOP in Schritt 3 erstellen, geben Sie die Annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private anstelle von public an.

Beachten Sie die folgenden Hinweise:

• Wenn Ihr klassischer Cluster nur mit privaten VLANs verbunden wird oder wenn für Ihren VPC-Cluster nur der private Cloud-Service-Endpunkt aktiviert ist, wird standardmäßig eine private Lastausgleichsfunktion erstellt, wenn Sie den IOP anwenden.
• Nur für klassische Cluster: ibmcloud ks nlb-dns create classic kann nicht zum Erstellen eines DNS-Datensatzes und einer von IBM bereitgestellten Unterdomäne für die IP-Adresse der Lastausgleichsfunktion des angepassten Gateways verwendet werden.

Aktualisierungen und Versionen angepasster Gateways steuern

Sie können die verwaltete Istio-Version angepasster Ingress-Gateways manuell aktualisieren und steuern.

IBM Cloud hält alle Ihre Istio-Komponenten auf dem aktuellen Stand, indem Patchaktualisierungen auf die neueste Version von Istio, die von IBM Cloud Kubernetes Service unterstützt wird, durch automatische Rollouts zur Verfügung gestellt werden. Wenn beispielsweise die Patch-Version 1.23.5 veröffentlicht wird, werden alle Eingangs-Gateway-Pods automatisch auf diese neueste Patch-Version aktualisiert. Aktualisierungen auf Patchversionen werden durch die Strategie der rollierenden Aktualisierungen durchgeführt, um Ausfallzeiten für Ihre Apps zu vermeiden. Allerdings können Sie automatische Aktualisierungen von angepassten Gateway-Pods auch unterbinden, wenn Sie zum Beispiel auf potenzielle Regressionen mit der neuesten Patchversion testen wollen.

Zur Verwaltung von Aktualisierungen für Ihre Ingress-Gateways könnten Sie die folgende Rollout-Strategie verwenden:

1. Erstellen Sie einen IOP für angepasstes Ingress-Gateway. Geben Sie im Feld tag eine Patchversion an, die mit der Steuerebenenversion übereinstimmt oder eine frühere Version ist. Sie können die Steuerebenenversion mithilfe des Befehls istioctl version ermitteln.
2. Wenn eine neue Patchversion für das verwaltete Istio-Add-on freigegeben wird, bearbeiten Sie die YAML-Datei des IOP nur für ein einziges angepasstes Gateway, um die neueste Patchversion zu verwenden. Wenden Sie den IOP anschließend in Ihrem Cluster erneut an.
3. Testen Sie nach der Aktualisierung der Pods des angepassten Gateways auf die neueste Patchversion alle Änderungen an dem angepassten Gateway.
4. Wenn Sie mit den Änderungen zufrieden sind, ändern Sie die Konfigurationen für die übrigen angepassten Gateways, um diese auf die neueste Patchversion zu aktualisieren.

Setzen Sie den Tag nicht auf eine Version, die höher als die Steuerebenenversion Ihres Istio-Add-ons ist.

Aktualisieren Sie die Pods Ihrer angepassten Gateways möglich bald nach der Freigabe einer Version. Angepasste Gateways, die mit früheren Versionen ausgeführt werden, können Sicherheitslücken ausgesetzt sein.

Zusätzliche Gateway-Anpassungen

Angepasste Ingress-Gateways können mit zusätzlichen Anpassungen konfiguriert werden. Dazu gehören zum Beispiel die Bereitstellung der Lastausgleichsfunktion eines Gateways in einer bestimmten Zone, die Angabe der Mindestanzahl von Gateway-Podreplikaten, das Planen von angepassten Gateway-Pods auf Edge-Knoten, das Hinzufügen von Lebenszyklushooks preStop für ordnungsgemäße Beendigungen und die Angabe von Anti-Affinität und Workerknotenaffinität.

Schauen Sie sich Beispiele für diese zusätzlichen Anpassungen in der folgenden YAML-Datei für einen Istio-Operator (IOP) an.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: ibm-operators
  name: custom-ingressgateway-iop
spec:
  profile: empty
  hub: icr.io/ext/istio
  # tag: 1.23.5 # Force the gateway to a specific managed Istio version
  components:
    ingressGateways:
      - name: custom-ingressgateway
        label:
          istio: custom-ingressgateway
        namespace: custom-gateways
        enabled: true
        k8s:
          serviceAnnotations:
            service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
            service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12" # Deploy the load balancer to a specific zone in your cluster
          hpaSpec: # Specify the minimum number of pod replicas
            minReplicas: 2
          tolerations: # Schedule the custom gateway pods onto edge nodes
          - key: dedicated
            value: edge
          env:
          - name: TERMINATION_DRAIN_DURATION
            value: 30s
          affinity:
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
              - podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: app
                      operator: In
                      values:
                      - istio-ingressgateway
                  topologyKey: kubernetes.io/hostname
                weight: 100
            nodeAffinity: # Example node affinities to control the zone or the edge
              preferredDuringSchedulingIgnoredDuringExecution: # Could be requiredDuringSchedulingIgnoredDuringExecution instead
                nodeSelectorTerms:
                - matchExpressions:
                  - key: ibm-cloud.kubernetes.io/zone
                    operator: In
                    values:
                    - "dal12" # Deploy the load balancer to a specific zone in your cluster
              preferredDuringSchedulingIgnoredDuringExecution:
              - preference:
                  matchExpressions:
                  - key: dedicated
                    operator: In
                    values:
                    - edge
                weight: 100

Angepasstes Egress-Gateway erstellen

In Version 1.8 und höher des verwalteten Istio-Add-ons können Sie angepasste Egress-Gateways erstellen. Egress-Gateways fungieren als Exitpunkt für den gesamten abgehenden Datenverkehr von Apps im Servicenetz an externe Ziele.

Sie können z. B. die folgende YAML-Datei für einen IOP in Ihrem Cluster anwenden, um ein angepasstes Egress-Gateway zu erstellen.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: ibm-operators
  name: custom-egressgateway-iop
spec:
  profile: empty
  hub: icr.io/ext/istio
  # tag: 1.23.5 # Force the Gateway to a specific version
  components:
    egressGateways:
      - name: custom-egressgateway
        label:
          istio: custom-egressgateway
        namespace: custom-gateways
        enabled: true

Weitere Informationen zur Konfiguration und Verwendung benutzerdefinierter Egress-Gateways finden Sie in der Istio-Open-Source-Dokumentation.

Standardgateways inaktivieren

Wenn Sie die istio-ingressgateway- oder istio-egressgateway-Standardbereitstellungen nach der Erstellung angepasster Gateways nicht benötigen, können Sie sie bei Bedarf inaktivieren.

Wenn Sie wünschen, dass Ihre Apps für Clients zugänglich sind, stellen Sie sicher, dass mindestens eine Gateway-Lastausgleichsfunktion aktiviert und zur Weiterleitung von Datenverkehr an Ihre Apps konfiguriert ist. Wenn Sie die standardmäßigen Gateway-Lastausgleichsfunktionen in allen Zonen inaktivieren, ist Ihre App nicht mehr zugänglich und kann nicht extern aufgerufen werden.

1. Bearbeiten Sie die Ressource managed-istio-custom für die Konfigurationszuordnung (configmap).

   kubectl edit cm managed-istio-custom -n ibm-operators
   

2. Inaktivieren Sie die Standard-Ingress-Gateways, indem Sie die Felder istio-ingressgateway-public-1|2|3-enabled auf "false" setzen.

   istio-ingressgateway-public-1-enabled: "false"
   istio-ingressgateway-public-2-enabled: "false"
   istio-ingressgateway-public-3-enabled: "false"
   

3. Zum Inaktivieren des Standard-Egress-Gateways fügen Sie das Feld istio-egressgateway-public-1-enabled: "false" hinzu.

   istio-egressgateway-public-1-enabled: "false"
   

4. Speichern und schließen Sie die Konfigurationsdatei.

5. Überprüfen Sie, ob die Standard-Gateway-Services entfernt wurden.

   kubectl get svc -n istio-system