Hinzufügen eines Server-Ports zum Host-Header

Standardmäßig verarbeitet Traefik den Header „ Host “ auf eine Weise, die mit den meisten modernen Anwendungen kompatibel ist. Es wird nicht empfohlen, die Header-Datei „ Host “ so zu ändern, dass ein Port hinzugefügt wird. Bevor Sie Änderungen vornehmen, sollten Sie sich darüber informieren, wie Traefik den Header standardmäßig behandelt, und verstehen, wann ein Überschreiben sinnvoll ist.

Standardmäßige Verarbeitung von „ Host “-Headern

Traefik leitet den ursprünglichen „ Host “-Header standardmäßig weiter mit passHostHeader: true. Es fügt automatisch die folgenden separaten weitergeleiteten Header hinzu, anstatt den Port in den „ Host “-Header einzubetten:

• X-Forwarded-Host

• X-Forwarded-Port

Überschreiben des „ Host “-Headers für ältere Anwendungen

Wenn Ihre App den im Header „ Host “ eingebetteten Port benötigt, verwenden Sie die Traefik-Header-Middleware, um diesen zu überschreiben.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      Host: "legacy-app.example:8080"

Wenden Sie die Middleware mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an. Stellen Sie sicher, dass die CRD-Verarbeitung aktiviert ist (Standardeinstellung). Informationen zur Konfiguration der CRD-Verarbeitung finden Sie im Handbuch „ ibm-ingress-deploy-config ConfigMap processTraefikCRDs Feld “.

Weiterleitung eingehender Anfragen über einen privaten ALB

Standardmäßig verarbeiten öffentliche ALBs Ingress-Ressourcen. Um eingehende Anfragen stattdessen über einen privaten ALB weiterzuleiten, geben Sie die Klasse „ private-iks-traefik “ im Feld „ spec.ingressClassName “ Ihrer Ingress-Ressource an.

spec.ingressClassName: "private-iks-traefik"

Authentifizierung von Apps mit App ID

Konfigurieren Sie Traefik Ingress mit IBM Cloud App ID, um die Authentifizierung für Ihre Apps durchzusetzen. Weitere Informationen finden Sie unter „ App ID-Authentifizierung zu Apps hinzufügen “.

Festlegen der maximalen Größe des Client-Anfrage-Hauptteils

Standardmäßig legt Traefik keine Begrenzung für die Größe des Anfragetextes eines Clients fest. Um einen Höchstwert festzulegen, erstellen Sie eine Buffering-Middleware und wenden Sie diese auf Ihre Ingress-Ressource an.

Traefik weist jede Anfrage, die das konfigurierte Limit überschreitet, mit der Antwort „ HTTP “ (413) zurück.

1. Erstellen Sie eine Traefik -Buffering-Middleware-Ressource. Setzen Sie „ maxRequestBodyBytes “ auf die maximale Anzahl an Bytes, die der Client senden kann. Im folgenden Beispiel wird ein Limit von 2 MB (2097152 Byte) festgelegt.

   # Example (Kubernetes Middleware)
   apiVersion: traefik.io/v1alpha1
   kind: Middleware
   metadata:
     name: limit
   spec:
     buffering:
       maxRequestBodyBytes: 2097152
   

2. Wenden Sie die Middleware mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Aktivieren der Pufferung von Client-Antwortdaten

Standardmäßig überträgt Traefik Antworten direkt, ohne sie zwischenzuspeichern. Mit der Buffering-Middleware kann Traefik Antworten im Arbeitsspeicher zwischenspeichern oder auf die Festplatte schreiben, bevor sie an den Client gesendet werden. Verwenden Sie diese Middleware nur, wenn Ihre App sie benötigt, da eine Antwortpufferung in den meisten Fällen nicht empfohlen wird.

Um die Antwortpufferung zu aktivieren, führen Sie die folgenden Schritte aus:

1. Erstellen Sie eine Traefik -Buffering-Middleware-Ressource. Setzen Sie „ maxResponseBodyBytes “ auf die maximale Antwortgröße in Byte und „ memResponseBodyBytes “ auf den Schwellenwert, ab dem die Antwort auf die Festplatte geschrieben wird, anstatt im Arbeitsspeicher gehalten zu werden. Im folgenden Beispiel werden insgesamt bis zu 5 MB gepuffert, wobei der erste 1 MB im Arbeitsspeicher gehalten wird.

   # Example (Kubernetes Middleware)
   apiVersion: traefik.io/v1alpha1
   kind: Middleware
   metadata:
     name: response-buffer
   spec:
     buffering:
       maxResponseBodyBytes: 5242880    # 5 MB max response size
       memResponseBodyBytes: 1048576    # 1 MB in memory, then disk
   

2. Wenden Sie die Middleware mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Anpassen der Zeitlimits

Traefik bietet zwei Arten von Timeout-Einstellungen: Timeouts zwischen dem Client und dem ALB sowie Timeouts zwischen dem ALB und Ihrer Backend-Anwendung. Konfigurieren Sie sie separat, je nachdem, wo der Engpass liegt.

Um die Timeouts für die Verbindung vom Client zum ALB festzulegen, konfigurieren Sie die entsprechenden Felder „ ibm-ingress-deploy-config “ und „ ConfigMap “:

• Um festzulegen, wie lange eine eingehende Anfrage an HTTP oder HTTPS auf die Antwort der Traefik-Instanz wartet, verwenden Sie die Felder „ httpReadTimeout “ und „ httpsReadTimeout “.
• Um die maximale Dauer bis zum Ablauf der Antwortzeit zu konfigurieren, verwenden Sie die Felder „ httpWriteTimeout “ und „ httpsWriteTimeout “.
• Um die maximale Dauer festzulegen, für die eine Keepalive-Verbindung offen bleibt, bevor sie geschlossen wird, verwenden Sie die Felder „ httpIdleTimeout “ und „ httpsIdleTimeout “.

Um das Verbindungs- und Lese-Timeout zwischen dem ALB und Ihrer Backend-Anwendung festzulegen, verwenden Sie ServersTransport, um den Transport zwischen Traefik und Ihren „ HTTP “-Servern zu konfigurieren.

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: mytransport
spec:
  forwardingTimeouts:
    dialTimeout: 30s
    responseHeaderTimeout: 10s
    idleConnTimeout: 90s

Bei VPC-Clustern müssen Sie außerdem das Zeitlimit für inaktive Verbindungen im Load-Balancer-Dienst anpassen, über den Ihr öffentlicher ALB bereitgestellt wird. Ersetzen Sie „ CLUSTER_ID “ durch Ihre Cluster-ID, die Sie über den Befehl „ ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID “ abrufen können. Im folgenden Beispiel wird das Timeout auf 910 Sekunden festgelegt:

kubectl annotate svc -n kube-system public-cr<clusterid> service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910"

Traefik unterstützt für seine Timeouts den Wert „ 0 “, wodurch das Timeout deaktiviert wird.

Die Annotation „ ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout “ auf dem VPC-Load-Balancer unterstützt keinen Wert von Null. Sie können einen Timeout-Wert zwischen 50 Sekunden und 7200 Sekunden (2 Stunden) festlegen. Wenn Sie einen Wert von mehr als 2 Stunden benötigen, eröffnen Sie bitte einen Support-Fall und legen Sie die geschäftlichen Gründe dafür dar.

Wenn Ihre Cluster über IBM Cloud Internet Services (CIS) oder Cloudflare mit aktivierter Web Application Firewall (WAF) oder globalem Lastausgleich erreichbar sind, legen Sie diese Zeitlimits auf mehr als 900 Sekunden fest. Weitere Informationen finden Sie in der Cloudflare-Dokumentation.

Nachdem Sie die Ressource „ ServersTransport “ erstellt haben, wenden Sie diese mithilfe der Traefik-Service -Annotation auf Ihre Service-Ressource an.

Anpassen von Fehlermaßnahmen

Um benutzerdefinierte Aktionen festzulegen, die der ALB bei bestimmten Fehlern von „ HTTP “ ausführen kann, konfigurieren Sie die Traefik-Fehler-Middleware. Nachdem Sie die Middleware erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Ändern der Standardports für HTTP und HTTPS

Standardmäßig hören ALBs auf Port 80 für HTTP und auf Port 443 für HTTPS. Falls Ihr Cluster nicht standardmäßige Ports benötigt, können Sie diese Werte für jeden ALB ändern, indem Sie die Felder „ httpPort “ und „ httpsPort “ unter „ ibm-ingress-deploy-config “ ConfigMap verwenden.

Anpassen des Request-Headers

Verwenden Sie die Traefik-Header-Middleware, um Header-Felder zu einer Client-Anfrage hinzuzufügen, zu überschreiben oder zu entfernen, bevor diese an Ihre Backend-Anwendung weitergeleitet wird. Dies ist nützlich, um Kontextinformationen wie Skriptnamen, Mandanten-IDs oder andere Metadaten einzubinden, die Ihre App benötigt.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      X-Script-Name: "test"

Nachdem Sie die Middleware erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Anpassen des Antwort-Headers

Verwenden Sie die Traefik-Header-Middleware, um Header-Felder zu einer Antwort hinzuzufügen, zu überschreiben oder zu entfernen, bevor diese an den Client gesendet wird. Dies ist nützlich, um Sicherheitsrichtlinien durchzusetzen, „ CORS “-Header hinzuzufügen oder interne Header zu entfernen, bevor sie den Client erreichen.

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customResponseHeaders:
      X-Custom-Response-Header: "value"

Nachdem Sie die Middleware erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Umleitung unsicherer Anfragen

Um den Zugriff ausschließlich über HTTPS zu erzwingen und alle eingehenden HTTP-Anfragen dauerhaft an den Endpunkt HTTPS umzuleiten, legen Sie das Feld „ httpsRedirect “ im ibm-ingress-deploy-config ConfigMap.

Aktivieren und Deaktivieren von „ HTTP: Strict Transport Security“

HTTP „Strict Transport Security“ ( HSTS ) weist Browser an, auf eine Domain ausschließlich über HTTPS zuzugreifen, wodurch Angriffe durch Protokoll-Downgrade verhindert werden. Diese Funktion ist bei Traefik optional. Aktivieren Sie diese Funktion mithilfe der Headers-Middleware und der Felder „ stsSeconds “, „ stsIncludeSubdomains “ und „ stsPreload “.

# Example (Kubernetes Middleware) - produces: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: security-headers
spec:
  headers:
    stsSeconds: 31536000            # max-age=1 year
    stsIncludeSubdomains: true
    stsPreload: true

Wenden Sie die Middleware mithilfe der folgenden Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Anpassen der Art und Weise, wie der ALB die Anfrage-URI zuordnet

Standardmäßig verwendet Traefik den Matcher „ PathPrefix “, um Anfragen weiterzuleiten. Wenn Ihre App eine exakte Pfadübereinstimmung oder ein auf regulären Ausdrücken basierendes Routing erfordert, überschreiben Sie den Matcher mithilfe der folgenden Traefik -Ingress-Annotation.

traefik.ingress.kubernetes.io/router.pathmatcher: PathRegexp

Gegenseitige Authentifizierung konfigurieren

Bei der gegenseitigen Authentifizierung ( TLS ) ( mTLS ) müssen sowohl der Server als auch der Client gültige Zertifikate vorweisen, wodurch eine stärkere Authentifizierung gewährleistet wird als bei der Standard- TLS. Um die Authentifizierung mittels Client-Zertifikat auf Ihrem ALB zu erzwingen, erstellen Sie eine TLSOption-Ress ource, die auf das geheime Zertifikat Ihrer Zertifizierungsstelle verweist.

# Example (Kubernetes TLSOption)
apiVersion: traefik.io/v1alpha1
kind: TLSOption
metadata:
  name: mtls
  namespace: default
spec:
  minVersion: VersionTLS12
  clientAuth:
    secretNames:
      - my-ca-secret
    clientAuthType: RequireAndVerifyClientCert

Nachdem Sie die Ressource „ TLSOption “ erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Konfigurieren des Wiederholungsverhaltens für Upstream-Anfragen

Wenn ein Backend-Server nicht antwortet, kann Traefik die Anfrage automatisch bei einem anderen Upstream-Server erneut versuchen. Konfigurieren Sie das Wiederholungsverhalten mithilfe der Traefik -Retry-Middleware. Nachdem Sie die Middleware erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Durchsatzbegrenzung

Die Ratenbegrenzung schützt Ihre Backend-Anwendungen vor Traffic-Spitzen und Missbrauch, indem sie die Anzahl der Anfragen begrenzt, die der ALB innerhalb eines bestimmten Zeitfensters verarbeitet. Konfigurieren Sie die Ratenbegrenzung mithilfe der Traefik -Middleware „ RateLimit “. Nachdem Sie die Middleware erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Pfade neu schreiben

Mit der Pfadumschreibung können Sie einen öffentlichen Pfad URL bereitstellen, der sich von dem Pfad unterscheidet, auf dem Ihre Backend-Anwendung auf Verbindungen wartet. Beispielsweise können Sie Anfragen, die unter /app eingehen, an eine Backend-Anwendung weiterleiten, die unter / auf Anfragen wartet. Verwenden Sie eine der folgenden Traefik-Ressourcen, je nachdem, ob Sie eine feste Ersetzung oder eine musterbasierte Ersetzung benötigen:

• Die Traefik - ReplacePath-Middleware-Ressource
• Die Traefik - ReplacePathRegex-Middleware-Ressource

# Example Replace the path with /foo
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepath
spec:
  replacePath:
    path: "/foo"

# Example Replace path with regex
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepathregex
spec:
  replacePathRegex:
    regex: "^/foo/(.*)"
    replacement: "/bar/$1"

Wenden Sie die Middleware mithilfe der folgenden Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Verkehrsweiterleitung mit Sticky-Cookies

„Sticky Sessions“ stellen sicher, dass die Anfragen eines Clients während der gesamten Dauer einer Sitzung stets an denselben Backend-Server weitergeleitet werden. Dies ist nützlich für zustandsbehaftete Anwendungen, die Sitzungsdaten lokal auf dem Server speichern. Aktivieren Sie „Sticky Sessions“, indem Sie die Traefik -Service-Annotation „sticky cookie“ in Ihrer Ingress-Ressource konfigurieren.

Verschlüsselung des Datenverkehrs zwischen Ihrer App und dem ALB

Standardmäßig leitet Traefik den Datenverkehr über „ HTTP “ an Ihre Backend-Anwendung weiter. Falls Ihre App verschlüsselte Upstream-Verbindungen benötigt, verwenden Sie eine ServersTransport Ressource, um „ TLS “ zwischen dem ALB und Ihrer App zu konfigurieren, einschließlich des CA-Zertifikats und des erwarteten Servernamens.

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: backend-transport
spec:
  rootCAs:
    - secret: my-ca-cert
  serverName: <myapp.example.com> # must match your certificate

Wenden Sie die Annotation „ ServersTransport “ mithilfe der folgenden Traefik-Service -Annotation auf Ihre Service-Ressource an.

ALB-Bereitstellung anpassen

Die Datei „ ibm-ingress-deploy-config “ ( ConfigMap ) steuert Einstellungen auf ALB-Ebene wie die Anzahl der Replikate, Ports, die Protokollierungsstufe, Timeout-Werte und den Ingress-Anbieter. Verwenden Sie diese „ ConfigMap “, um Konfigurationsänderungen auf einen oder mehrere ALBs in Ihrem Cluster anzuwenden, ohne einzelne Ingress-Ressourcen zu ändern.

1. Rufen Sie die Namen der Services ab, die die einzelnen ALBs zugänglich machen. Notieren Sie sich die Namen der Dienste, da Sie diese in den folgenden Schritten benötigen.

   • Klassische Cluster:

       kubectl get svc -n kube-system | grep alb
       ```
   * VPC-Cluster: Suchen Sie in der Ausgabe nach einem Servicenamen, der zum Beispiel wie folgt formatiert ist: `public-crc204dl7w0qf6n6sp7tug`.
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

2. Erstellen Sie eine YAML-Datei für eine Konfigurationszuordnung (configmap) namens ibm-ingress-deploy-config. Für jede ALB-ID können Sie eine oder mehrere der folgenden optionalen Einstellungen angeben. Sie müssen nur die Einstellungen angeben, die Sie konfigurieren möchten.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
     <alb2-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
   

   replicas

   Standardmäßig verfügt jede ALB über zwei Replikate. Führen Sie ein Scale-up für die Verarbeitungsfunktionen Ihrer ALB durch, indem Sie die Anzahl der ALB-Pods erhöhen. Weitere Informationen finden Sie unter Anzahl der ALB-Podreplikate erhöhen.

   ingressClass

   Falls Sie in Ihrer Ingress-Ressource eine andere Klasse als „ public-iks-traefik “ oder „ private-iks-traefik “ angegeben haben, geben Sie hier den Klassennamen ein.

   httpPort, httpsPort

   Machen Sie die Nicht-Standardports für die Ingress-ALB zugänglich, indem Sie die HTTP-oder HTTPS-Ports hinzufügen, die Sie öffnen möchten.

   Standardwerte: 80/443.

   logLevel

   Geben Sie die Protokollierungsstufe an. Wählen Sie aus: TRACE, DEBUG, INFO, WARN, ERROR, FATAL, PANIC.

   Standard: INFO.

   ingressProvider

   Geben Sie an, welcher Traefik-Ingress-Anbieter für diesen ALB verwendet werden soll. Die gültigen Werte sind im Folgenden aufgelistet:

   ingress: Verwendet den eigenen Ingress-Controller von Traefik. Es verarbeitet Traefik-spezifische Annotationen an Ingress-Ressourcen.

   ingress-nginx: Verwendet eine temporäre Kompatibilitätsschicht für Ingress- NGINX in Traefik. Es verarbeitet Annotationen, die für Ingress- NGINX erstellt wurden, und ahmt, soweit möglich, das Verhalten von Ingress- NGINX nach. Verwenden Sie diesen Wert, um die Migration von Ingress- NGINX zu Traefik zu erleichtern.

   Standard: ingress.

   processTraefikCRDs

   Bei der Einstellung „ true “ verarbeitet Traefik zusätzlich zu den Ingress-Ressourcen auch seine eigenen CRD-Ressourcen. Zu den unterstützten CRDs gehören IngressRoute, Middleware und TLSOption. Die vollständige Liste finden Sie in der Traefik-Dokumentation zu CRDs.

   Standard: true.

   traefikIngressNginxAllowExternalNameServices

   Aktiviert die Unterstützung für „ ExternalName “-Dienste für Ingress-Objekte, die vom „ ingress-nginx “-Anbieter verarbeitet werden. Diese Option gilt nur, wenn „ ingressProvider “ auf „ ingress-nginx “ gesetzt ist.

   Standard: true.

   traefikCRDAllowCrossNamespace

   Ermöglicht es Ressourcen im IngressRoute-Namespace (Traefik CRD), auf Ressourcen in anderen Namespaces zu verweisen.

   Standard: false.

   traefikCRDAllowExternalNameServices

   Ermöglicht es „ IngressRoute “-Ressourcen (Traefik CRD), auf „ ExternalName “-Dienste zu verweisen.

   Standard: false.

   httpReadTimeout, httpsReadTimeout

   Konfiguriert das Lese-Timeout für „ HTTP “ / „ HTTPS “ zwischen dem ALB und dem Client. Der Wert muss eine ganze Zahl in Sekunden sein; wird er auf Null gesetzt, wird das Timeout deaktiviert.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   httpWriteTimeout, httpsWriteTimeout

   Konfiguriert das Schreib-Timeout für „ HTTP “ / „ HTTPS “ zwischen dem ALB und dem Client. Der Wert muss eine ganze Zahl in Sekunden sein; wird er auf Null gesetzt, wird das Timeout deaktiviert.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   httpIdleTimeout, httpsIdleTimeout

   Konfiguriert das Zeitlimit für die Leerlaufverbindung ( HTTP ) / HTTPS (Keepalive) zwischen dem ALB und dem Client. Der Wert muss eine ganze Zahl in Sekunden sein; wird er auf Null gesetzt, wird das Timeout deaktiviert.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   Wenn Sie IBM Cloud Internet Services (CIS) oder Cloudflare mit einer Web Application Firewall (WAF) oder globalem Lastausgleich verwenden, stellen Sie diesen Wert auf mehr als 900 Sekunden ein. Weitere Informationen finden Sie unter „ Zeitlimits anpassen “.

   httpsRedirect

   Aktiviert eine permanente Weiterleitung aller eingehenden HTTP-Anfragen an den Endpunkt HTTPS.

   Standard: false.

   customEntryPoints

   Legt zusätzliche benutzerdefinierte Einstiegspunkte für Traefik fest. Der Name des Einstiegspunkts ist der Schlüssel des Objekts. Die folgenden Einstiegspunktnamen sind reserviert und dürfen nicht verwendet werden: web, websecure, traefik, hc, und http https.

   Bei einer ungültigen Konfiguration der Einstiegspunkte wird keiner der benutzerdefinierten Einstiegspunkte verarbeitet!

   customEntryPoints.<name>.port

   Zu verwendender Port des Einstiegspunkts. Dieses Feld ist obligatorisch. Stellen Sie sicher, dass es nicht mit anderen Ports in Konflikt gerät.

   Der hier definierte Port und das Protokoll müssen manuell auf dem Load Balancer freigegeben werden; Anweisungen hierzu finden Sie weiter unten.

   customEntryPoints.<name>.protocol

   Protokoll des zu verwendenden Einstiegspunkts. Dieses Feld ist obligatorisch. Gültige Werte sind TCP und UDP.

   customEntryPoints.<name>.readTimeout

   Konfiguriert das Lese-Timeout des Einstiegspunkts zwischen dem ALB und dem Client. Der Wert muss eine ganze Zahl in Sekunden sein; wird er auf Null gesetzt, wird das Timeout deaktiviert.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   customEntryPoints.<name>.writeTimeout

   Konfiguriert das Schreib-Timeout des Einstiegspunkts zwischen dem ALB und dem Client. Der Wert muss eine ganze Zahl in Sekunden sein; wird er auf Null gesetzt, wird das Timeout deaktiviert.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   customEntryPoints.<name>.idleTimeout

   Konfiguriert das Timeout für den Leerlauf (Keepalive) des Einstiegspunkts zwischen dem ALB und dem Client. Der Wert muss eine ganze Zahl in Sekunden sein; wird er auf Null gesetzt, wird das Timeout deaktiviert.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   customEntryPoints.<name>.udpTimeout

   Konfiguriert das Zeitlimit für den Leerlauf des Einstiegspunkts für den UDP-Listener. Dieses Feld wird nur für Endpunkte berücksichtigt, die das Protokoll UDP verwenden. Der Wert muss eine ganze Zahl in Sekunden und größer als Null sein.

   Weitere Informationen finden Sie in der Traefik-Dokumentation.

   tolerations

   Legt zusätzliche benutzerdefinierte Toleranzen für die ALB-Pods fest. Weitere Informationen finden Sie unter Taints und Toleranzen.

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

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

4. Aktualisieren Sie Ihre ALBs, um die Änderungen zu übernehmen. Es kann bis zu fünf Minuten dauern, bis Änderungen wirksam werden. Wenn der Befehl ohne Ausgabe beendet wird, wurde die Aktualisierung erfolgreich übermittelt.

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. Wenn Sie nicht standardmäßige HTTP- oder HTTPS-Ports angegeben oder zusätzliche Einstiegspunkte erstellt haben, müssen Sie die Ports auf jedem ALB-Dienst öffnen.

   1. Bearbeiten Sie für jeden ALB-Service, den Sie in Schritt 1 gefunden haben, die YAML-Datei.

       kubectl edit svc -n kube-system <alb_svc_name>
       ```
   2. Fügen Sie im Abschnitt `spec.ports` die Ports hinzu, die Sie öffnen möchten. Standardmäßig sind Port 80 und 443 geöffnet. Wenn Sie die Ports 80 und 443 geöffnet bleiben sollen, entfernen Sie sie nicht aus dieser Datei. Ein Port, der nicht angegeben wird, wird geschlossen. Geben Sie keinen Wert für `nodePort` an. Nachdem Sie den Port hinzugefügt und die Änderungen angewendet haben, wird automatisch ein Wert für `nodePort` zugeordnet.
   
   ```sh {: codeblock}
       ...
       ports:
       - name: port-80
         port: 80
         protocol: TCP
         targetPort: 80
       - name: port-443
         port: 443
         protocol: TCP
         targetPort: 443
       - name: <new_port>
         port: <port>
         protocol: TCP
         targetPort: <port>
       ...
       ```
   3. Speichern und schließen Sie die Datei. Ihre Änderungen werden automatisch angewendet.
   
   

Ingress-Klasse anpassen

Eine Ingress-Klasse ordnet einen Klassennamen einem Ingress-Controller-Typ zu, wodurch mehrere Controller im selben Cluster nebeneinander existieren können. Verwenden Sie die IngressClass Ressource, um eine benutzerdefinierte Klasse für Ihre ALBs zu definieren.

Traefik verarbeitet nur Ingress-Klassen, bei denen „ .spec.controller “ auf „ traefik.io/ingress-controller “ gesetzt ist.

App ID-Authentifizierung zu Apps hinzufügen

Schützen Sie Ihre Apps vor unauthentifiziertem Zugriff, indem Sie IBM Cloud App ID in Ihren Ingress ALB. Wenn die Authentifizierung konfiguriert ist, leitet der ALB Anfragen über einen „ OAuth2-Proxy “ weiter, der die Anmeldedaten bei App ID überprüft, bevor der Datenverkehr an Ihre App weitergeleitet wird.

1. Wählen Sie eine vorhandene Instanz aus oder erstellen Sie eine neue App ID-Instanz.

   Eine App ID-Instanz kann nur in einem Namensbereich in Ihrem Cluster verwendet werden. Wenn Sie App ID für Ingress-Ressourcen in mehreren Namensbereichen konfigurieren möchten, wiederholen Sie die Schritte in diesem Abschnitt, um eine eindeutige App ID-Instanz für die Ingress-Ressourcen in jedem Namensbereich anzugeben.

   • Um eine vorhandene Instanz zu verwenden, stellen Sie sicher, dass der Name der Serviceinstanz ausschließlich aus Kleinbuchstaben und Ziffern besteht und nicht länger als 25 Zeichen ist. Wenn Sie den Namen ändern möchten, wählen Sie Service umbenennen im Menü "Weitere Optionen" auf der Detailseite der Serviceinstanz aus.
   • Gehen Sie wie folgt vor, um eine neue App ID-Instanz bereitzustellen:
     1. Ersetzen Sie Servicename durch Ihren eindeutigen Namen für die Serviceinstanz. Der Name der Service-Instanz darf nur aus Kleinbuchstaben und Ziffern bestehen und darf nicht länger als 25 Zeichen sein.
     2. Wählen Sie die Region aus, in der Ihr Cluster implementiert ist.
     3. Klicken Sie auf Erstellen.

2. Fügen Sie Umleitungs-URLs für Ihre App hinzu. Eine Umleitungs-URL ist der Callback-Endpunkt Ihrer App. Um Phishing-Attacken zu verhindern, validiert die IBM Cloud App ID die Anforderungs-URL anhand der Zulassungsliste mit Umleitungs-URLs.

   1. Navigieren Sie in der App ID-Managementkonsole zu Authentifizierung verwalten.
   2. Stellen Sie sicher, dass Sie auf der Registerkarte Identitätsprovider einen Identitätsprovider ausgewählt haben. Wenn kein Identitätsanbieter ausgewählt ist, werden Sie nicht authentifiziert, erhalten jedoch ein Zugriffstoken für den anonymen Zugriff auf die App.
   3. Fügen Sie auf der Registerkarte Authentifizierungseinstellungen Umleitungs-URLs für Ihre App im Format https://<hostname>/oauth2-<App_ID_service_instance_name>/callback hinzu. Alle Buchstaben im Namen der Service-Instanz müssen in Kleinbuchstaben geschrieben sein.

   Wenn Sie die Abmeldefunktion IBM Cloud App ID verwenden, fügen Sie Ihrer Domain im Format /sign_out hinzu https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out und nehmen Sie diesen Link URL in die Liste der Weiterleitungs-URLs auf. Um eine benutzerdefinierte Abmeldeseite zu verwenden, setzen Sie „ whitelist_domains “ in der Datei „ OAuth2-Proxy “ ConfigMap. Rufen Sie den Endpunkt „ https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out “ mit dem Abfrageparameter „ rd “ auf oder setzen Sie den Header „ X-Auth-Request-Redirect “ mit der URL Ihrer benutzerdefinierten Abmeldeseite URL. Weitere Informationen finden Sie unter „ Abmelden “.

3. Binden Sie die App ID-Serviceinstanz an den Cluster. Der Befehl erstellt einen Dienstschlüssel für die Dienstinstanz. Alternativ können Sie die Option --key angeben, um vorhandene Anmeldedaten für den Dienstschlüssel zu verwenden. Binden Sie die Service-Instanz an denselben Namespace, in dem sich Ihre Ingress-Ressourcen befinden. Alle Buchstaben im Namen der Service-Instanz müssen in Kleinbuchstaben geschrieben sein.

   ibmcloud ks cluster service bind --cluster CLUSTER_NAME_OR_ID --namespace NAMESPACE --service APP_ID_SERVICE_INSTANCE_NAME [--key SERVICE_INSTANCE_KEY]
   

   Wenn der Dienst erfolgreich an Ihren Cluster gebunden wurde, wird ein Cluster-Secret erstellt, das die Anmeldedaten für Ihre Dienstinstanz enthält. Das folgende Beispiel zeigt die Ausgabe:

   ibmcloud ks cluster service bind --cluster mycluster --namespace mynamespace --service appid1
   Binding service instance to namespace...
   OK
   Namespace:    mynamespace
   Secret name:  binding-<service_instance_name>
   

4. Aktivieren Sie das Add-on für den ALB-OAuth-Proxy in Ihrem Cluster. Dieses Add-on erstellt und verwaltet die folgenden Ressourcen von „ Kubernetes “: eine „ OAuth2-Proxy “-Bereitstellung für Ihre „ App ID “-Serviceinstanz, ein Secret, das die Konfiguration von „ OAuth2-Proxy “ enthält, sowie eine „Ingress“-Ressource, die eingehende Anfragen an die „ OAuth2-Proxy “-Bereitstellung weiterleitet. Der Name jeder Ressource beginnt mit oauth2-.

   1. Aktivieren Sie das alb-oauth-proxy-Add-on.

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. Stellen Sie sicher, dass das Add-on für den ALB-OAuth-Proxy den Status `Addon Ready` (Add-on bereit) aufweist. Warten Sie einige Minuten und führen Sie den Befehl erneut aus, falls der Status „ `Enabling` “ anzeigt.
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. Stellen Sie in den Ingress-Ressourcen für Apps, für die Sie die „ App ID “-Authentifizierung hinzufügen möchten, sicher, dass der Name der Ressource nicht länger als 25 Zeichen ist. Konfigurieren Sie anschließend die „ ForwardAuth “-Middleware:

   1. Erstellen Sie eine Traefik - ForwardAuth-Middleware-Ressource. Die legt address die URL des OAuth2-Proxy für Ihre App ID-Instanz fest, die als OIDC-Relying Party (RP) fungiert. Alle Buchstaben im Namen der Service-Instanz müssen in Kleinbuchstaben geschrieben sein.

       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           tls:
             insecureSkipVerify: true
       ```
       Standardmäßig überprüft Traefik die alternativen IP-Namen (SANs) von TLS. IBM-Die bereitgestellten Zertifikate werden diese Validierung voraussichtlich nicht bestehen; verwenden Sie daher die Option „ `insecureSkipVerify: true` “. Diese Einstellung stellt sicher, dass die Traefik-Instanz bzw. der ALB mit den Deployment-Instanzen von „ `oauth2-proxy` “ kommunizieren kann.
       {: note}
   
   2. Wählen Sie aus, welche Tokens im Header `Authorization` an Ihre App gesendet werden sollen. Weitere Informationen zu ID- und Zugriffstoken finden Sie in der [Dokumentation zu App ID.](/docs/appid?topic=appid-tokens)
       * Um nur die „ `ID Token` “ zu senden, fügen Sie die Option „ `authResponseHeaders` “ zu Ihrer „ ForwardAuth “-Middleware hinzu:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
       * Um nur die „ `Access Token` “ zu senden, fügen Sie die Option „ `authResponseHeaders` “ zu Ihrer „ ForwardAuth “-Middleware hinzu:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
               tls:
                 insecureSkipVerify: true
           ```
       * Um sowohl die „ `Access Token` “ als auch die „ `ID Token` “ zu versenden, fügen Sie die Option „ `authResponseHeaders` “ zu Ihrer „ ForwardAuth “-Middleware hinzu:
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
   3. Optional: Wenn Ihre App zusätzlich zur [API-Strategie](/docs/appid?topic=appid-key-concepts#term-api-strategy) oder anstelle dieser die [Web-App-Strategie](/docs/appid?topic=appid-key-concepts#term-web-strategy) unterstützt, fügen Sie die „ `authSigninURL` “ zu Ihrer „ ForwardAuth “-Middleware hinzu. Alle Buchstaben im Namen der Service-Instanz müssen in Kleinbuchstaben geschrieben sein.
   
   ```yaml {: codeblock}
       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           authResponseHeaders:
             - X-Auth-Request-Access-Token
             - Authorization
           authSigninURL: /oauth2-<App_ID_service_instance_name>/sign_in?rd={url}
           tls:
             insecureSkipVerify: true
       ```
       * Wenn Sie „ `authSigninURL` “ angeben und die Authentifizierung für einen Client fehlschlägt, wird der Client auf „ OAuth2-Proxy “ weitergeleitet, von wo aus er anschließend zur Anmeldeseite „ App ID “ weitergeleitet wird.
       * Wenn Sie keine Angabe machen `authSigninURL`, muss sich ein Client mit einem gültigen Bearer-Token authentifizieren. Wenn die Authentifizierung fehlschlägt, wird die Anfrage mit dem Fehler „ `401 Unauthorized` “ abgelehnt.
   
   

6. Optional: Falls Ihre Konfiguration dies erfordert, erstellen Sie eine Traefik ServersTransport Ressource an, um die Überprüfung von „ TLS “ für Anfragen zu überspringen, die an die Service-Ressource Ihrer App weitergeleitet werden.

   # Example (Kubernetes ServersTransport)
   apiVersion: traefik.io/v1alpha1
   kind: ServersTransport
   metadata:
     name: skip-tls-verify
   spec:
     insecureSkipVerify: true
   

   Wenden Sie die Annotation „ ServersTransport “ mithilfe der Traefik-Service -Annotation auf Ihre Service-Ressource an.

7. Bearbeiten Sie Ihre Ingress-Ressourcen, um die Authentifizierung über „ App ID “ zu erzwingen, indem Sie die von Ihnen erstellte Middleware „ ForwardAuth “ anwenden. Verwenden Sie die folgende Traefik-Ingress -Annotation.

   traefik.ingress.kubernetes.io/router.middlewares: "default-oauth-verify@kubernetescrd"
   

   Nachdem eine Ingress-Ressource mit den entsprechenden Annotationen erneut angewendet wurde, stellt das ALB- OAuth-Proxy-Add-on eine Bereitstellung oauth2-proxy bereit, erstellt einen Dienst für die Bereitstellung und legt eine separate Ingress-Ressource an, um das Routing für die Bereitstellung oauth2-proxy zu konfigurieren. Diese Add-on-Ressourcen dürfen Sie nicht löschen.

8. Stellen Sie sicher, dass die App ID-Authentifizierung für Ihre Apps erzwungen wird.

   • Wenn Ihre App die Web-App-Strategie unterstützt: Rufen Sie die Seite URL Ihrer App in einem Webbrowser auf. Wurde App ID ordnungsgemäß angewendet, werden Sie an eine Anmeldeseite für App ID mit Authentifizierung weitergeleitet.
   • Wenn Ihre App die API-Strategie unterstützt: Geben Sie Ihr Bearer Zugriffstoken im Authorization-Header von Anfragen an die Apps an. Informationen zum Abrufen Ihres Zugriffstokens finden Sie in der Dokumentation zu App ID. Wenn App ID korrekt angewendet wird, wird die Anforderung erfolgreich authentifiziert und an Ihre App weitergeleitet. Wenn Sie Anfragen an Ihre Apps senden, ohne dass im Authorization-Header ein Zugriffstoken enthalten ist, oder wenn das Zugriffstoken von App ID nicht akzeptiert wird, wird die Anfrage abgelehnt.

9. Optional: Wenn Sie in Ihrem Cluster Netzwerkrichtlinien oder eine andere Firewall-Lösung verwenden, um den ausgehenden Datenverkehr zu beschränken, stellen Sie sicher, dass Ihr Cluster auf den öffentlichen Dienst „ App ID “ zugreifen kann. Um den IP-Adressbereich für diesen Dienst zu erhalten, reichen Sie bitte eine Anfrage beim Kundensupport ein.

10. Optional: Sie können das Standardverhalten des OAuth2-Proxys anpassen, indem Sie eine Kubernetes-Konfigurationszuordnung erstellen.

    1. Erstellen Sie eine YAML-Datei für die Konfigurationszuordnung, die Werte für die OAuth2-Proxy-Einstellungen angibt, die Sie ändern möchten.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: oauth2-<App_ID_service_instance_name>
          namespace: <ingress_resource_namespace>
        data:
          auth_logging: <true|false>
          # Log all authentication attempts.
          auth_logging_format:
          # Format for authentication logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#logging-configuration
          cookie_csrf_expire: "15m"
          # Expiration time for CSRF cookie. Default is "15m".
          cookie_csrf_per_request: <true|false>
          # Enable multiple CSRF cookies per request, making it possible to have parallel requests. Default is "false".
          cookie_domains:
          # A list of optional domains to force cookies to. The longest domain that matches the request’s host is used. If there is no match for the request’s host, the shortest domain is used. Example: sub.domain.com,example.com
          cookie_expire: "168h0m0s"
          # Expiration time for cookies. Default: "168h0m0s".
          cookie_samesite: ""
          # SameSite attribute for cookies. Supported values: "lax", "strict", "none", or "".
          email_domains: ""
          # Authenticate IDs that use the specified email domain. To authenticate IDs that use any email domain, use "*". Default: "". Example: example.com,example2.com
          pass_access_token: <true|false>
          # Pass the OAuth access token to the back-end app via the X-Forwarded-Access-Token header.
          request_logging: <true|false>
          # Log all requests to the back-end app.
          request_logging_format:
          # Format for request logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#request-log-format
          scope:
          # Scope of the OAuth authentication. For more info, see https://oauth.net/2/scope/
          set_authorization_header: <true|false>
          # Set the Authorization Bearer response header when the app responds to the Ingress ALB, such as when using the Traefik ForwardAuth Middleware.
          set_xauthrequest: <true|false>
          # Set X-Auth-Request-User, X-Auth-Request-Email, and X-Auth-Request-Preferred-Username response headers when the app responds to the Ingress ALB, such as when using the Traefik ForwardAuth Middleware.
          standard_logging: <true|false>
          # Log standard runtime information.
          standard_logging_format:
          # Format for standard logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#standard-log-format
          tls_secret_name:
          # The name of a secret that contains the server-side TLS certificate and key to enable TLS between the OAuth2-Proxy and the Ingress ALB. By default, the TLS secret defined in your Ingress resources is used.
          whitelist_domains:
          # Allowed domains for redirection after authentication. Default: "". Example: example.com,*.example2.com For more info, see: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#command-line-options
          oidc_extra_audiences:
          # Additional audiences which are allowed to pass verification.
          cookie_refresh:
          # Refresh the cookie after this duration. Example: "15m". To use this feature, you must enable "Refresh token" for the AppID instance. For more info, see: /docs/appid?topic=appid-managing-idp&interface=ui#idp-token-lifetime
        ```
    2. Wenden Sie die Konfigurationszuordnungsressource auf das Add-on an. Ihre Änderungen werden automatisch angewendet.
    ```sh {: pre}
        kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
        ```
    

Eine Liste der Änderungen für jede Version des ALB- OAuth-Proxy-Add-ons finden Sie im Änderungsprotokoll für das ALB- OAuth-Proxy-Add-on unter IBM Cloud.

Aktualisierung des ALB- OAuth-Proxy-Add-ons

Um das ALB- OAuth-Proxy-Add-on auf eine neuere Version zu aktualisieren, deaktivieren Sie die aktuelle Installation und aktivieren Sie sie anschließend mit der gewünschten Version erneut. Ihre bestehenden „ oauth2-proxy “-Instanzen werden während des Upgrades nicht unterbrochen.

Der Upgrade-Prozess erfolgt ohne Unterbrechung, da die überwachten oauth2-proxy Instanzen auch dann im Cluster verbleiben, wenn das Add-on deaktiviert ist.

1. Inaktivieren Sie das -Add-on.

   ibmcloud ks cluster addon disable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
   

2. Listen Sie die verfügbaren Add-on-Versionen auf und geben Sie die Version an, die Sie verwenden möchten. Die Ausgabe zeigt die verfügbaren Versionen an und gibt an, welche Version die Standardversion ist.

   ibmcloud ks cluster addon versions --addon alb-oauth-proxy
   

3. Aktivieren Sie das Add-on und geben Sie die Option --version an. Wenn Sie keine Version angeben, wird die Standardversion aktiviert.

   ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID [--version VERSION]
   

Quellen-IP-Adresse beibehalten

Standardmäßig behält der Ingress-ALB die ursprüngliche Quell-IP-Adresse von Client-Anfragen nicht bei. Dies kann dazu führen, dass IP-basierte Zugriffskontrollen, Protokollierungen und Sicherheitsrichtlinien nicht ordnungsgemäß funktionieren. Wählen Sie die für Ihren Clustertyp geeignete Methode aus, um die Beibehaltung der Quell-IP zu aktivieren.

TLS-Protokolle und Verschlüsselungsalgorithmen konfigurieren

Verwenden Sie eine TLSOption-Ressource, um Mindestversionen von „ TLS “ vorzuschreiben, Verschlüsselungssuiten einzuschränken und weitere „ TLS “-Verbindungsparameter für den Datenverkehr zu konfigurieren, der Ihren ALB erreicht. Nachdem Sie die Ressource „ TLSOption “ erstellt haben, wenden Sie diese mithilfe der Traefik-Ingress -Annotation auf Ihre Ingress-Ressource an.

Angepasstes Zertifikat an ältere Clients senden

Ältere Geräte, die Server Name Indication (SNI) nicht unterstützen, können nicht aushandeln, welches „ TLS “-Zertifikat verwendet werden soll, sodass sie statt Ihres benutzerdefinierten Zertifikats das Standard-Let’s-Encrypt-Zertifikat des ALB erhalten. Um sicherzustellen, dass diese Geräte Ihr benutzerdefiniertes Zertifikat erhalten, passen Sie die Standard-Servereinstellungen des ALB so an, dass sie auf Ihr benutzerdefiniertes „ TLS “-Secret verweisen.

Die standardmäßig generierten Let' s Encrypt-Zertifikate sind nicht für den Einsatz in Produktionsumgebungen bestimmt. Verwenden Sie für Produktionsworkloads ein eigenes angepasstes Zertifikat.

Wenn Sie einen klassischen Cluster erstellen, stellt „ IBM “ ein Let’s Encrypt-Zertifikat für das Standard-Ingress-Secret bereit. Wenn Sie ein benutzerdefiniertes Geheimnis erstellen und dieses in Ihren Ingress-Ressourcen für die „ TLS “-Terminierung angeben, sendet der ALB Ihren Clients Ihr benutzerdefiniertes Zertifikat anstelle des Let’s Encrypt-Zertifikats. Wenn ein Client jedoch SNI nicht unterstützt, greift der ALB standardmäßig auf das Let's Encrypt-Zertifikat zurück, da der Standard-Secret in den Standard-Server-Einstellungen des ALB aufgeführt ist. Um Ihr benutzerdefiniertes Zertifikat an Geräte zu senden, die SNI nicht unterstützen, führen Sie die folgenden Schritte aus.

1. Bearbeiten Sie die Ingress-Ressource alb-default-server.

   kubectl edit ingress alb-default-server -n kube-system
   

2. Ändern Sie im Abschnitt spec.tls den Wert der Einstellung hosts.secretName in den Namen Ihres angepassten geheimen Schlüssels, der Ihr angepasstes Zertifikat enthält.

   spec:
     rules:
     ...
     tls:
     - hosts:
       - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
       secretName: <custom_secret_name>
   

3. Speichern Sie die Ressourcendatei.

4. Stellen Sie sicher, dass die Ressource jetzt auf den Namen Ihres geheimen Schlüssels verweist. Die Änderungen werden automatisch auf Ihre ALBs angewendet. Überprüfen Sie in der Ausgabe, ob „ spec.tls[].secretName “ mit Ihrem benutzerdefinierten Geheimniseintrag übereinstimmt.

   kubectl get ingress alb-default-server -n kube-system -o yaml
   

ALB-Leistung optimieren

Worker-Knoten werden automatisch mit einer optimierten Kernel-Konfiguration bereitgestellt, die für die meisten Workloads geeignet ist. Falls Ihr Cluster bestimmte Anforderungen hinsichtlich hohem Durchsatz oder geringer Latenz stellt, können Sie die Kernel-Parameter „ Linux “ sysctl auf den Worker-Knoten anpassen, um die ALB-Leistung weiter zu optimieren. Ändern Sie diese Einstellungen nur, wenn Sie einen konkreten Bedarf an einer Leistungsoptimierung haben, da falsche Werte den Knoten destabilisieren können.

Nächste Schritte

• Verwalten Sie Ihre Ingress-ALBs, um ALBs in Ihrem Cluster zu skalieren, zu aktualisieren oder zu deaktivieren.
• Richten Sie Ingress ein, um Ihre Apps mithilfe des verwalteten Ingress-Dienstes zugänglich zu machen.
• Debuggen Sie Ingress, um häufige Ingress-Probleme zu diagnostizieren und zu beheben.

Zugehörige Links

• Traefik-Dokumentation
• Traefik-Middleware-Referenz
• Traefik-CRD-Referenz
• Dokumentation zu IBM Cloud App ID