Preservando o endereço IP de origem

Para preservar endereços IP de origem, é possível ativar o protocolo PROXY para clusters VPC. Essa opção está disponível para clusters que executam a versão 4.13 ou posterior.

O protocolo PROXY oferece uma maneira conveniente de transportar informações de conexão, como o endereço de um cliente, entre várias camadas de proxies NAT ou TCP. Para obter mais informações sobre o protocolo PROXY, consulte a especificação HAProxy.

Por padrão, o controlador do Ingress recebe conexões que contêm apenas o endereço de origem associado com o balanceador de carga É possível ativar o protocolo PROXY em clusters de VPC para configurar o balanceador de carga para preservar o endereço do cliente original para conexões que o controlador do Ingress recebe

Customizando o roteamento do Ingress com anotações

Se você quiser personalizar as regras de roteamento do seu aplicativo, pode usar anotações HAProxy específicas para cada rota nos recursos do Ingress que você definir.

Essas anotações suportadas estão no formato haproxy.router.openshift.io/<annotation> ou router.openshift.io/<annotation>Anotações IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) e anotações NGINX (nginx.ingress.kubernetes.io/<annotation>) não são suportadas para o controlador de ingresso ou o recurso de ingresso no Red Hat OpenShift versão 4.

Ativando a criação de log de acesso

HTTP Os registros de acesso contêm informações sobre as solicitações HTTP recebidas. Ter registros de acesso é útil ao depurar problemas complexos, mas o OpenShift roteador não oferece suporte a registros de acesso por padrão. Para OpenShift clusters, você pode configurar o registro de acesso para roteadores, o que resulta em um contêiner sidecar no pod do roteador que executa um syslog servidor e grava registros de acesso em seu stdout.

1. Edite a configuração IngressController e adicione a seguinte configuração à .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"}'
   

   comando edit

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

2. Verifique se os pods do roteador estão executando dois contêineres.

   kubectl get pod -n openshift-ingress -w
   

   Exemplo de saída

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

3. Verifique os registros de acesso.

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

   Exemplo de saída

   ...
   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":"--"}
   ...
   

Ajuste fino do tratamento de conexões

Os parâmetros clientTimeout e serverTimeout são configurações cruciais que determinam por quanto tempo as conexões permanecem ativas entre os clientes, o controlador Ingress e os servidores back-end. Esses tempos limite desempenham uma função importante na otimização do tratamento de solicitações, principalmente ao lidar com conexões de clientes de longa duração, respostas atrasadas de servidores de back-end e proteção de recursos valiosos contra a ocupação desnecessária.

Se você prevê que os clientes manterão as conexões abertas por um período mais longo, é recomendável aumentar a configuração clientTimeout para atender a esses cenários. Por outro lado, se os servidores de backend tiverem alta latência devido a grandes volumes de tráfego ou cargas de processamento, o ajuste de serverTimeout pode fornecer a permissão necessária para que os servidores concluam o processamento da solicitação antes que o controlador Ingress encerre a conexão.

Você pode alterar os parâmetros acima em seu recurso IngressController:

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

Para obter mais informações sobre as opções de ajuste, consulte a OpenShift documentação.