Conservation de l'adresse IP source

Pour préserver les adresses IP source, vous pouvez activer le protocole PROXY pour les clusters de VPC. Cette option est disponible pour les clusters qui exécutent la version 4.13 ou ultérieure.

Le protocole PROXY offre un moyen pratique de transporter des informations de connexion, telles que l'adresse d'un client, à travers plusieurs couches de NAT ou de proxies TCP. Pour plus d'informations sur le protocole PROXY, voir la spécification HAProxy.

Par défaut, le contrôleur Ingress reçoit les connexions qui contiennent uniquement l'adresse source associée à l'équilibreur de charge. Vous pouvez activer le protocole PROXY dans les clusters de VPC pour configurer l'équilibreur de charge afin de conserver l'adresse du client d'origine pour les connexions reçues par le contrôleur Ingress.

Personnalisation du routage Ingress avec des annotations

Si vous souhaitez personnaliser les règles de routage de votre application, vous pouvez utiliser des annotations « HAProxy » spécifiques à chaque route dans les ressources Ingress que vous définissez.

Ces annotations prises en charge sont au format haproxy.router.openshift.io/<annotation> ou router.openshift.io/<annotation>. Les annotationsIBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) et les annotations NGINX (nginx.ingress.kubernetes.io/<annotation>) ne sont pas prises en charge pour le contrôleur Ingress ou Ingress dans la version 4 Red Hat OpenShift.

Activation de la journalisation des accès

HTTP Les journaux d'accès contiennent des informations sur les requêtes HTTP entrantes. Les journaux d'accès sont utiles pour déboguer des problèmes complexes, mais le OpenShift routeur ne prend pas en charge la journalisation des accès par défaut. Pour OpenShift les clusters, vous pouvez configurer la journalisation des accès pour les routeurs, ce qui se traduit par la présence d'un conteneur sidecar dans le pod du routeur qui exécute un syslog serveur et écrit les journaux d'accès dans son fichier stdout.

1. Modifiez la configuration de IngressController et ajoutez la configuration suivante à .spec.

   logging:
     access:
       destination:
         type: Container
       httpCaptureHeaders:
         request:
         - maxLength: 256
           name: Host
       httpLogFormat: '{"time_date":"%t","client":"%ci","host":"%[capture.req.hdr(0)]","ssl_version":"%sslv","request_method":"%HM",
                      "request_uri":"%HU","status":%ST,"upstream_addr":"%si:%sp","request_time":%Tt,"upstream_connect_time":%Tc,
                      "upstream_header_time":%Tr,"termination_state":"%ts"}'
   

   edit, commande

   kubectl edit ingresscontroller -n openshift-ingress-operator default
   ingresscontroller.operator.openshift.io/default edited
   

2. Vérifier si les pods du routeur utilisent deux conteneurs.

   kubectl get pod -n openshift-ingress -w
   

   Exemple de sortie

   NAME                              READY   STATUS    RESTARTS   AGE
   router-default-66945cc7c4-4xlnh   2/2     Running   0          36s
   router-default-66945cc7c4-5cxpn   2/2     Running   0          36s
   

3. Vérifier les journaux d'accès.

   kubectl logs -n openshift-ingress router-default-66945cc7c4-4xlnh -c logs
   

   Exemple de sortie

   ...
   2025-01-28T12:29:07.038592+00:00 router-default-7fc484bbb8-qfm5d router-default-7fc484bbb8-qfm5d haproxy[41]:{"time_date":
   "28/Jan/2025:12:29:06.879","client":"10.5.207.79","host":"alb-autoscale-example-service-default.pvg-classic-z9g5zltmgb1ir
   -1e7743ca80a399c9cff4eaf617434c72-0000.us-south.stg.kube.appdomain.cloud","ssl_version":"TLSv1.3","request_method":
   "GET","request_uri":"/","status":200,"upstream_addr":"172.30.210.252:8080","request_time":159,"upstream_connect_time":1,
   "upstream_header_time":2,"termination_state":"--"}
   2025-01-28T12:29:09.572129+00:00 router-default-7fc484bbb8-qfm5d router-default-7fc484bbb8-qfm5d haproxy[41]: {"time_date":
   "28/Jan/2025:12:29:09.405","client":"10.5.207.79","host":"alb-autoscale-example-service-default.pvg-classic-z9g5zltmgb1ir
   -1e7743ca80a399c9cff4eaf617434c72-0000.us-south.stg.kube.appdomain.cloud","ssl_version":"TLSv1.3","request_method":"GET",
   "request_uri":"/","status":200,"upstream_addr":"172.30.210.252:8080","request_time":166,"upstream_connect_time":0,
   "upstream_header_time":3,"termination_state":"--"}
   ...
   

Amélioration de la gestion des connexions

Les paramètres clientTimeout et serverTimeout sont des configurations cruciales qui dictent la durée pendant laquelle les connexions restent actives entre les clients, le contrôleur Ingress et les serveurs dorsaux. Ces délais jouent un rôle important dans l'optimisation du traitement des demandes, en particulier lorsqu'il s'agit de connexions client de longue durée, de réponses retardées de la part des serveurs dorsaux et de la protection de ressources précieuses contre une occupation inutile.

Si vous prévoyez que les clients garderont les connexions ouvertes pendant une période plus longue, il est conseillé d'augmenter le paramètre clientTimeout pour répondre à ces scénarios. Inversement, si vos serveurs dorsaux présentent une latence élevée en raison de volumes de trafic importants ou de charges de traitement, le réglage de serverTimeout peut permettre aux serveurs d'achever le traitement des demandes avant que le contrôleur d'ingestion ne mette fin à la connexion.

Vous pouvez modifier les paramètres ci-dessus dans votre ressource IngressController:

apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tuningOptions:
    clientTimeout: 5s
    serverTimeout: 5s

Pour plus d'informations sur les options de réglage, consultez la OpenShift documentation.