IBM Cloud Docs
Customizando o roteamento ALB

Customizando o roteamento ALB

Modifique as configurações padrão para ALBs que executam a imagem Kubernetes Ingress.

Às vezes, você pode customizar roteamento para Ingress adicionando Kubernetes anotações NGINX (nginx.ingress.kubernetes.io/<annotation>). Kubernetes anotações NGINX são sempre aplicadas a todos os caminhos de serviço no recurso, e não é possível especificar nomes de serviço dentro das anotações. As anotações personalizadas do site IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) não são compatíveis.

Kubernetes Os controladores de ingresso (ALBs) em clusters criados a partir de 31 de janeiro de 2022 não processam recursos de ingresso que tenham anotações de snippet (por exemplo, nginx.ingress.kubernetes.io/configuration-snippet) por padrão, pois todos os novos clusters são implantados com a configuração allow-snippet-annotations: "false" no ConfigMap do ALB. Se você incluir qualquer fragmento de configuração recomendado aqui, será necessário editar o ConfigMap (kube-system/ibm-k8s-controller-config) do ALB e mudar allow-snippet-annotations: "false" para allow-snippet-annotations: "true".

Como adicionar uma porta do servidor a um cabeçalho do host

Para incluir uma porta do servidor na solicitação do cliente antes que a solicitação seja encaminhada para seu app backend, configure um proxy para serviços externos em uma anotação de fragmento do servidor ou como um campo ibm-k8s-controller-config ConfigMap .

Roteirização de solicitações recebidas com um ALB privado

Para rotear as solicitações recebidas aos seus apps com um ALB privado, especifique a anotação de classe private-iks-k8s-nginx no recurso Ingresso. Os ALBs privados são configurados para usar recursos com esta classe.

kubernetes.io/ingress.class: "private-iks-k8s-nginx"

Autenticando apps com App ID

Configure Ingress com IBM Cloud App ID para impor a autenticação para seus apps alterando os campos de Ingresso Kubernetes específicos. Veja Adicionando App ID autenticação em apps para obter mais informações.

Como configurar o tamanho máximo do corpo de solicitação do cliente

Para configurar o tamanho máximo do corpo que o cliente pode enviar como parte de uma solicitação, use o seguinte recurso Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-body-size: 8m

Ativação e desativação de buffering de dados de resposta do cliente

Você pode desativar ou ativar o armazenamento de dados de resposta no ALB enquanto os dados são enviados ao cliente. Esta configuração está desativada por padrão. Para ativar, configure o seguinte recurso Ingresso anotação.

nginx.ingress.kubernetes.io/proxy-buffering: "on"

Personalização dos tempos limite de conexão e leitura

Para configurar a quantidade de tempo que o ALB espera para se conectar e ler a partir do app back-end antes que o app back-end seja considerado indisponível, use as seguintes anotações.

nginx.ingress.kubernetes.io/proxy-connect-timeout: 62
nginx.ingress.kubernetes.io/proxy-read-timeout: 62

Customizando ações de erro

Para indicar ações personalizadas que o ALB pode executar para erros específicos do site HTTP, defina o campo custom-http-errors.

Alteração das portas padrão HTTP e HTTPS

Para alterar as portas padrão para o tráfego de rede HTTP (porta 80) e HTTPS (porta 443), modifique cada serviço ALB com os seguintes campos Kubernetes Ingress ibm-ingress-deploy-config ConfigMap.

Configuração de campo de exemplo.

httpPort=8080
httpsPort=8443

Customizando o cabeçalho da solicitação

Para adicionar informações de cabeçalho a uma solicitação de cliente antes de encaminhar a solicitação ao seu app back-end, use o seguinte Kubernetes ibm-k8s-controller-config configmap campo

proxy-set-headers: "ingress-nginx/custom-headers"

Para os requisitos de configmap custom-headers, consulte este exemplo.

Como personalizar o cabeçalho de resposta

Para adicionar informações de cabeçalho a uma resposta do cliente antes de enviá-lo para o cliente, use a seguinte anotação.

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

Adição de definições de caminho a serviços externos

Para incluir definições de caminho em serviços externos, como serviços hospedados no IBM Cloud, configure um proxy para serviços externos em um fragmento de localização Ou substitua o proxy por um redirecionamento permanente para serviços externos.

Redirecionamento de pedidos inseguros

Por padrão, as solicitações inseguras do cliente HTTP são redirecionadas para HTTPS. Para desativar essa configuração, use o campo e anotação a seguir.

  • ibm-k8s-controller-config ConfigMap campo
    ssl-redirect: "false"
    
  • Anotação do recurso Ingress:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    

Ativação e desativação do HTTP Strict Transport Security

Configure o navegador para acessar o domínio somente usando HTTPS. Esta opção está ativada por padrão.

  • Para incluir a idade máxima e a granularidade de subdomínio, consulte este blog do NGINX.
  • Para desativar, configure o campo de configmap ibm-k8s-controller-config.
    hsts: false
    

Como configurar um número máximo de solicitações de keepalive

Para configurar o número máximo de solicitações que podem ser servidas por meio de uma conexão keepalive, use o seguinte Kubernetes ibm-k8s-controller-config configmap campo.

keep-alive-requests: 100

O valor padrão para keep-alive-requests em Kubernetes Ingress é 100, que é muito menor do que o valor padrão de 4096 em IBM Cloud Kubernetes Service Ingress. Se você tiver migrado sua configuração do Ingress do IBM Cloud Kubernetes Service Ingress para o Kubernetes Ingress, poderá ser necessário mudar keep-alive-requests para passar nos testes de desempenho existentes.

Configurando um tempo máximo de solicitação de keepalive

Para configurar o tempo máximo que uma conexão keepalive fica aberta entre o cliente e o servidor proxy ALB, use o seguinte Kubernetes ibm-k8s-controller-config configmap campo.

keep-alive: 60

Configurando um número máximo de buffers de cabeçalho de grandes clientes

Para configurar o número máximo e o tamanho de buffers que leem grandes cabeçalhos de solicitação do cliente, use o seguinte Kubernetes ibm-k8s-controller-config configmap campo.

large-client-header-buffers: 4 8k

Modificando como o ALB corresponde ao URI de solicitação

Para modificar a forma como o ALB corresponde a URI de solicitação contra o caminho do app, use o seguinte Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/use-regex: "true"

Para obter mais informações, consulte este blog.

Incluindo configurações de blocos de localização personalizadas

Para adicionar uma configuração de bloco de localização personalizada para um serviço, use o seguinte Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

Configurando a autenticação mútua

Para configurar a autenticação mútua para o ALB, use o seguinte recurso Kubernetes Ingress resource annotations. Note que a autenticação mútua não pode ser aplicada em portas customizadas e deve ser aplicada na porta HTTPS.

nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"

Configurando tamanho do buffer de proxy

Para configurar o tamanho do buffer de proxy que lê a primeira parte da resposta, use o seguinte recurso Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"

Configurando números de buffer de proxy

Para configurar o número de buffers de proxy para o ALB, use o seguinte recurso Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

Configurando tamanho de buffer de proxy ocupado

Para configurar o tamanho de buffers de proxy que podem ser ocupados, use um trecho de localização . Para obter mais informações, consulte os Docs do NGINX.

Configurando quando um ALB pode transmitir uma solicitação

Para configurar quando o ALB pode transmitir uma solicitação para o próximo servidor upstream, use os seguintes campos Kubernetes Ingress.

  • Configuração global: campos de configmap ibm-k8s-controller-config:

    retry-non-idempotent: true
    proxy-next-upstream: error timeout http_500
    
  • Configuração por recurso: anotações do recurso Ingress:

    nginx.ingress.kubernetes.io/proxy-next-upstream: http_500
    nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: 50
    nginx.ingress.kubernetes.io/proxy-next-upstream-tries: 3
    

Limitação de taxa

Para limitar a taxa de processamento de pedidos e o número de conexões por uma chave definida para os serviços, use o recurso Ingresso anotações para limitação de taxa.

Removendo o cabeçalho de resposta

Você pode remover as informações de cabeçalho incluídas na resposta do cliente do aplicativo final de back-end antes que a resposta seja enviada ao cliente. Configure a remoção do cabeçalho de resposta em um snippet de localizaçãoou use o campo proxy_hide_header como um snippet de configuração no ibm-k8s-controller-config ConfigMap.

Reescrever caminhos

Para rotear o tráfego de rede de entrada em um caminho de domínio ALB para um caminho diferente que o seu app de back-end atende, use o seguinte Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/rewrite-target: /newpath

Customizando configurações de blocos do servidor

Para adicionar uma configuração de bloco de servidor personalizado, use o seguinte Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/server-snippet: |
    location = /health {
    return 200 'Healthy';
    add_header Content-Type text/plain;
    }

Roteamento de tráfego de rede

Para sempre rotear o tráfego de rede de entrada para o mesmo servidor de upstream usando um cookie adesivo, use o seguinte recurso Kubernetes Ingress resource annotations.

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name1"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
nginx.ingress.kubernetes.io/configuration-snippet: |
  more_set_headers "Set-Cookie: HttpOnly";

Por padrão, o controlador de Ingress do Kubernetes inclui os atributos Secure e HttpOnly nos sticky cookies, o que não pode ser alterado.

Permitindo o suporte de serviços SSL para criptografar o tráfego

Para permitir que o suporte a serviços SSL criptografe o tráfego para seus aplicativos upstream que exigem HTTPS, use a anotação de protocolo de backend do recurso Kubernetes Ingress e as anotações de autenticação de certificado de backend.

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: app1-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: 5
nginx.ingress.kubernetes.io/proxy-ssl-name: proxy-ssl-name=mydomain.com
nginx.ingress.kubernetes.io/proxy-ssl-verify: true

Acessando apps com portas TCP não padrão

Para acessar um app através de uma porta TCP não padrão, siga estes passos.

  1. Crie um configmap tcp-services para especificar a sua porta TCP, como as portas de exemplo a seguir. Para os requisitos do configmap tcp-services, consulte este blog.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: tcp-services
      namespace: kube-system
    data:
      9000: "<namespace>/<service>:8080"
    
  2. Crie o configmap no namespace kube-system.

    kubectl apply -f tcp-services.yaml -n kube-system
    
  3. Especifique o configmap tcp-services como um campo no configmap ibm-ingress-deploy-config.

    "tcpServicesConfig":"kube-system/tcp-services"
    
  4. Modifique cada serviço ALB para incluir as portas.

Como configurar um número máximo de pedidos de keepalive upstream

Para configurar o número máximo de solicitações que podem ser servidas por meio de uma conexão keepalive, use o seguinte Kubernetes ibm-k8s-controller-config ConfigMap campo.

upstream-keepalive-requests: 32

Configurando o tempo limite máximo de keepalive de upstream

Para configurar o tempo máximo que uma conexão keepalive fica aberta entre o servidor proxy ALB e o servidor upstream do seu app, use o seguinte Kubernetes ibm-k8s-controller-config configmap campo.

upstream-keepalive-timeout: 32

Customizando a implementação do ALB

Customize a implementação para ALBs que executam a imagem do Ingress do Kubernetes criando um configmap ibm-ingress-deploy-config.

  1. Obtenha os nomes dos serviços que expõem cada ALB.

    • Clusters clássicos:

      kubectl get svc -n kube-system | grep alb
      
    • Clusters de VPC: na saída, procure um nome de serviço que seja formatado como public-crc204dl7w0qf6n6sp7tug.

      kubectl get svc -n kube-system | grep LoadBalancer
      

Criando um ConfigMap para personalizar a implantação do Ingress

  1. Crie um arquivo YAML para um configmap do ibm-ingress-deploy-config. Para cada ID do ALB, é possível especificar uma ou mais das configurações opcionais a seguir. Note que é possível especificar apenas as definições que você deseja configurar, e não todas as configurações.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ibm-ingress-deploy-config
      namespace: kube-system
    data:
      <alb1-id>: '{"deepInspect":"<true|false>", "defaultBackendService":"<service_name>", "defaultCertificate":"<namespace>/<secret_name>", "defaultConfig":"<namespace>/<configmap-name>","enableSslPassthrough":"<true|false>", "httpPort":"<port>", "httpsPort":"<port>", "ingressClass":"<class>", "logLevel":<log_level>, "replicas":<number_of_replicas>, "tcpServicesConfig":"<kube-system/tcp-services>", "enableIngressValidation":"<true|false>"}'
      <alb2-id>: '{"deepInspect":"<true|false>", "defaultBackendService":"<service_name>", "defaultCertificate":"<namespace>/<secret_name>", "enableSslPassthrough":"<true|false>", "httpPort":"<port>", "httpsPort":"<port>", "ingressClass":"<class>","logLevel":<log_level>, "replicas":<number_of_replicas>, "tcpServicesConfig":"<kube-system/tcp-services>", "enableIngressValidation":"<true|false>"}'
    
    deepInspect
    Ative ou desative o inspetor abrangente de segurança de objetos do Ingress. Quando ativado, os ALBs inspecionam os valores de configuração em recursos do Ingress antes do processamento. Para obter mais informações, consulte o código-fonte ingress-nginx.
    Esse recurso está disponível para as versões do ALB 1.2.0 e posteriores e é ativado por padrão.
    defaultBackendService
    Especifique o nome de um serviço padrão opcional para receber solicitações quando nenhum host estiver configurado ou nenhum host correspondente for localizado. Este serviço substitui o serviço padrão fornecido pela IBM que gera uma mensagem 404. Você pode usar esse serviço para configurar páginas de erro customizadas ou para testar conexões.
    defaultCertificate
    Um segredo para um certificado TLS padrão aplicar em qualquer subdomínio que esteja configurado com ALBs do Ingress no formato secret_namespace/secret_name. Para criar um segredo, é possível executar o comando ibmcloud ks ingress secret create. Se um segredo para um certificado TLS diferente for especificado na seção spec.tls de um recurso Ingress e existir no mesmo namespace do recurso Ingress, ele será aplicado no lugar deste segredo padrão.
    defaultConfig
    Especifique um configmap padrão para seus ALBs. Digite o local do configmap que deseja utilizar no formato namespace/configmap-name. Por exemplo, kube-system/ibm-k8s-controller-config.
    enableAnnotationValidation
    Ative ou desative a validação de anotação do objeto do Ingress Quando ativados, os ALBs validam os valores de anotação nos recursos do Ingress antes do processamento. Para obter mais informações, consulte o código-fonte ingress-nginx.
    Esse recurso está disponível para as versões do ALB 1.9.0 e posteriores e é ativado por padrão.
    enableSslPassthrough
    Ative o passamento de SSL para o ALB. A conexão TLS não é finalizada e passa intacta.
    httpPort, httpsPort
    Exponha portas não padrão para o ALB do Ingress incluindo as portas HTTP ou HTTPS que você deseja abrir.
    ingressClass
    Se você tiver especificado uma classe diferente de public-iks-k8s-nginx ou private-iks-k8s-nginx em seu recurso do Ingress, especifique-a.
    logLevel
    Especifique o nível de log que deseja usar. Escolha entre os valores a seguir.
    2: Mostra os detalhes usando o comando **diff** para mostrar as mudanças na configuração em NGINX
    3: Mostra os detalhes sobre o serviço, regra do Ingress e mudanças de terminais no formato JSON.
    5: Configura o site NGINX no modo de depuração.
    Para obter mais informações sobre criação de log, consulte Criação de log de depuração.
    replicas
    Por padrão, cada ALB tem duas réplicas. Aumente as capacidades de processamento de ALB, aumentando o número de pods de ALB. Para obter mais informações, consulte Aumentando o número de réplicas do pod do ALB.
    tcpServicesConfig
    Especifique um configmap e o namespace no qual o configmap está localizado, como kube-system/tcp-services, que contém informações sobre como acessar seu serviço de app por meio de uma porta TCP não padrão.
    enableIngressValidation
    Ative a implementação do webhook de validação do Ingress para esse ALB O webhook valida os recursos do Ingress antes de ser aplicado no cluster para evitar configurações inválidas (O ALB processará apenas recursos do Ingress que pertencem à classe do Ingress que ele expõe.) Padrão: "false".
  2. Crie o configmap ibm-ingress-deploy-config em seu cluster.

    kubectl create -f ibm-ingress-deploy-config.yaml
    
  3. Para captar as mudanças, atualize seus ALBs. Observe que pode levar até cinco minutos para que as mudanças sejam aplicadas aos ALBs.

    ibmcloud ks ingress alb update -c <cluster_name_or_ID>
    
  4. Se você tiver especificado portas HTTP, HTTPS ou TCP não padrão, elas deverão ser abertas em cada serviço do ALB.

    1. Para cada serviço do ALB que você localizou na etapa 1, edite o arquivo YAML.

      kubectl edit svc -n kube-system <alb_svc_name>
      
    2. Na seção spec.ports, inclua as portas que você deseja abrir. Por padrão, as portas 80 e 443 ficam abertas. Para manter a 80 e a 443 abertas, não as remova deste arquivo. Qualquer porta que não esteja especificada é encerrada. Não especifique um nodePort. Após incluir a porta e aplicar as mudanças, um nodePort é automaticamente designado

      ...
      ports:
      - name: port-80
        nodePort: 32632
        port: 80
        protocol: TCP
        targetPort: 80
      - name: port-443
        nodePort: 32293
        port: 443
        protocol: TCP
        targetPort: 443
      - name: <new_port>
        port: <port>
        protocol: TCP
        targetPort: <port>
      ...
      
    3. Salve e feche o arquivo. As suas mudanças são aplicadas automaticamente.

Customizando a classe do Ingress

Uma classe Ingress associa um nome de classe a um tipo de controlador Ingress. Use o recurso IngressClass para customizar as aulas do Ingress.

Incluindo a autenticação do App ID em apps

Aplique a autenticação para os apps configurando o Ingress com o IBM Cloud App ID.

  1. Escolha uma instância do App ID existente ou crie uma nova.

    Uma instância do App ID pode ser usada em apenas um namespace em seu cluster. Para configurar o App ID para recursos do Ingress em diversos namespaces, repita as etapas nesta seção para especificar uma instância exclusiva do App ID para os recursos do Ingress em cada namespace.

    • Para usar uma instância existente, assegure-se de que o nome da instância de serviço contenha apenas caracteres alfanuméricos minúsculos e que seu comprimento não exceda 25 caracteres. Para mudar o nome, selecione Renomear serviço no menu de mais opções na página de detalhes da instância de serviço.
    • Para provisionar uma nova instância do App ID:
      1. Substitua o Nome do serviço pelo seu próprio nome exclusivo para a instância de serviço. O nome da instância de serviço deve conter apenas caracteres alfanuméricos em minúsculas e não pode ter mais de 25 caracteres.
      2. Escolha a mesma região na qual seu cluster está implementado.
      3. Clique em Criar.
  2. Inclua URLs de redirecionamento para seu app. Uma URL de redirecionamento é o terminal de retorno de chamada de seu app. Para evitar ataques de phishing, o IBM Cloud App ID valida a URL de solicitação com relação à lista de permissões de URLs de redirecionamento.

    1. No console de gerenciamento do App ID, navegue para Gerenciar autenticação.
    2. Na guia Provedores de identidade, certifique-se de que você tenha um Provedor de identidade selecionado. Se nenhum provedor de identidade for selecionado, o usuário não será autenticado, mas receberá um token de acesso para acesso anônimo ao aplicativo.
    3. Na guia Configurações de autenticação, inclua URLs de redirecionamento para o app no formato https://<hostname>/oauth2-<App_ID_service_instance_name>/callback. Observe que todas as letras no nome da instância de serviço devem ser especificadas como minúsculas.

    Se usar a função de logout do IBM Cloud App ID, você deverá anexar /sign_out ao domínio no formato https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out e incluir essa URL na lista de URLs de redirecionamento. Se quiser usar uma página de logout personalizada, você deverá definir whitelist_domains em ConfigMap para OAuth2-Proxy. Ligue para o terminal https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out com o parâmetro de consulta rd ou configure o cabeçalho X-Auth-Request-Redirect com a sua página de logout personalizada. Para obter mais detalhes, veja Inscrever-se.

  3. Ligue a instância de serviço do App ID ao seu cluster. O comando cria uma chave de serviço para a instância de serviço, ou você pode incluir a opção --key para usar as credenciais de chave de serviço existentes. Certifique-se de ligar a instância de serviço ao mesmo namespace no qual seus recursos do Ingress existem. Observe que todas as letras no nome da instância de serviço devem ser especificadas como minúsculas.

    ibmcloud ks cluster service bind --cluster <cluster_name_or_ID> --namespace <namespace> --service <App_ID_service_instance_name> [--key <service_instance_key>]
    

    Quando o serviço é ligado com sucesso ao seu cluster, é criado um segredo de cluster que mantém as credenciais de sua instância de serviço. Exemplo de saída da CLI:

    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. Ative o complemento ALB OAuth Proxy em seu cluster. Este complemento cria e gerencia os seguintes recursos do Kubernetes: uma implementação de OAuth2-Proxy para a instância de serviço do App ID, um segredo que contém a configuração da implementação do OAuth2-Proxy e um recurso do Ingress que configura ALBs para rotear as solicitações recebidas para a implementação do OAuth2-Proxy para a instância do App ID. O nome de cada um desses recursos começa com oauth2-.

    1. Ative o complemento alb-oauth-proxy.
      ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID>
      
    2. Verifique se o complemento ALB OAuth Proxy tem um status de Addon Ready.
      ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
      
  5. Nos recursos do Ingress para apps nos quais você deseja incluir a autenticação App ID, certifique-se de que o nome do recurso não exceda 25 caracteres de comprimento. Em seguida, inclua as seguintes anotações na seção metadata.annotations.

    1. Inclua a anotação auth-url a seguir. Esta anotação especifica a URL do OAuth2-Proxy para a instância do App ID, que serve como o OIDC Relying Party (RP) para o App ID. Observe que todas as letras no nome da instância de serviço devem ser especificadas como minúsculas.

      ...
      annotations:
         nginx.ingress.kubernetes.io/auth-url: https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth
      ...
      
    2. Às vezes, o cookie de autenticação usado pelo OAuth2-Proxy excede 4 KB. Portanto, é dividido em duas partes. O fragmento a seguir deve ser incluído para assegurar que ambos os cookies possam ser atualizados corretamente pelo OAuth2-Proxy

      ...
      annotations:
          nginx.ingress.kubernetes.io/configuration-snippet: |
          auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
          access_by_lua_block {
              if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
              ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
              end
          }
      ...
      
    3. Escolha quais tokens enviar no cabeçalho Authorization para o seu app. Para obter mais informações sobre ID e tokens de acesso, consulte a Documentação do App ID.

      • Para enviar apenas o ID Token, adicione a seguinte anotação:

        ...
        annotations:
            nginx.ingress.kubernetes.io/auth-response-headers: Authorization
        ...
        
      • Para enviar somente o Access Token, adicione as seguintes informações à anotação configuration-snippet. (Isso estende o fragmento da etapa 5.2.)

        ...
        annotations:
            nginx.ingress.kubernetes.io/configuration-snippet: |
            auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
            auth_request_set $access_token $upstream_http_x_auth_request_access_token;
            access_by_lua_block {
                if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                end
                if ngx.var.access_token ~= "" then
                ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token)
                end
            }
        ...
        
      • Para enviar o Access Token e o ID Token, adicione as seguintes informações à anotação configuration-snippet. (Isso estende o fragmento da etapa 5.2.)

        ...
         annotations:
            nginx.ingress.kubernetes.io/configuration-snippet: |
            auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
            auth_request_set $access_token $upstream_http_x_auth_request_access_token;
            auth_request_set $id_token $upstream_http_authorization;
            access_by_lua_block {
                if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                end
                if ngx.var.id_token ~= "" and ngx.var.access_token ~= "" then
                ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token .. " " .. ngx.var.id_token:match("%s*Bearer%s*(.*)"))
                end
            }
        ...
        
    4. Opcional: se o app suportar a estratégia de app da web além ou em vez de a estratégia de API, inclua a anotação nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri. Observe que todas as letras do nome da instância do serviço devem estar em minúsculas.

      • Se você especificar essa anotação e a autenticação para um cliente falhar, o cliente será redirecionado para a URL do OAuth2-Proxy para a instância do App ID. Este OAuth2-Proxy, que funciona como o OIDC Relying Party (RP) para o App ID, redireciona o cliente para a página de login do App ID para autenticação.
      • Se você não especificar essa anotação, um cliente deverá se autenticar com um token de acesso válido. Se a autenticação para um cliente falhar, a solicitação do cliente será rejeitada com uma mensagem de erro 401 Unauthorized.
  6. Reaplique seus recursos do Ingress para aplicar a autenticação do App ID. Após um recurso do Ingress com as anotações apropriadas ter sido reaplicado, o complemento ALB OAuth Proxy realiza uma implementação do OAuth2-Proxy, cria um serviço para a implementação e cria um recurso separado do Ingress para configurar o roteamento para as mensagens de implementação do OAuth2-Proxy. Não exclua esses recursos de complemento.

    kubectl apply -f <app_ingress_resource>.yaml -n namespace
    
  7. Verifique se a autenticação do App ID é imposta para seus apps.

    • Se os seus apps suportarem a estratégia de app da web: acesse a URL de seu app em um navegador da web. Se o App ID for aplicado corretamente, você será redirecionado para uma página de login de autenticação do App ID.
    • Se seus apps suportarem a estratégia de API: especifique seu token de acesso Bearer no cabeçalho de Autorização de solicitações para os apps. Para obter seu token de acesso, consulte a documentação do App ID. Se o App ID for aplicado corretamente, a solicitação será autenticada com sucesso e será roteada para o seu app. Se você enviar solicitações para seus apps sem um token de acesso no cabeçalho de Autorização ou se o token de acesso não for aceito pelo App ID, a solicitação será rejeitada.
  8. Opcional: se você usar políticas de rede ou outra solução de firewall em seu cluster para limitar o tráfego de saída, certifique-se de permitir o acesso ao serviço público AppID's a partir do seu cluster. Para obter o intervalo de endereços IP para esse serviço, envie uma solicitação por meio do suporte ao cliente.

  9. Opcional: é possível customizar o comportamento padrão do OAuth2-Proxy criando um ConfigMap do Kubernetes.

    1. Crie um arquivo YAML do ConfigMap que especifique valores para as configurações de OAuth2-Proxy que você deseja mudar.
      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 backend app via the X-Forwarded-Access-Token header.
        request_logging: <true|false>
        # Log all requests to the backend 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 when using the NGINX auth_request mode.
        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 NGINX auth_request mode.
        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. Aplique o recurso ConfigMap em seu complemento. As suas mudanças são aplicadas automaticamente.
      kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
      

Para obter a lista de alterações de cada versão do complemento ALB OAuth Proxy, consulte o registro de alterações do complemento IBM Cloud ALB OAuth Proxy.

Fazendo upgrade do complemento ALB OAuth Proxy

Para atualizar o complemento ALB OAuth Proxy, você deve primeiro desativar o complemento, depois reativá-lo e especificar a versão.

O processo de upgrade é não interruptivo, já que as instâncias do OAuth2 Proxy supervisionadas permanecem no cluster, mesmo quando o complemento está desativado.

  1. Desative o complemento .
    ibmcloud ks cluster addon disable alb-oauth-proxy --cluster <cluster_name_or_ID>
    
  2. Liste as versões de complemento disponíveis e decida qual versão deseja utilizar.
    ibmcloud ks cluster addon versions --addon alb-oauth-proxy
    
  3. Ative o complemento e especifique a opção --version. Se você não especificar uma versão, a versão padrão será ativada.
    ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID> [--version <version>]
    

Preservando o endereço IP de origem

Por padrão, os endereços IP de origem de solicitações do cliente não são preservados pelo ALB do Ingress. Para preservar os endereços IP de origem, é possível ativar o protocolo PROXY em clusters VPC ou mudar a externalTrafficPolicy em clusters clássicos.

Ativando o protocolo PROXY em clusters VPC

Para preservar o endereço IP de origem da solicitação do cliente em um cluster de VPC, você pode ativar o protocolo NGINX PROXY para todos os balanceadores de carga que expõem ALBs de entrada em seu cluster.

  1. Opcional Conclua as etapas a seguir se estiver usando o site Cloud Internet Services (CIS).

    1. Ative a configuração True client IP header no console CIS, clicando em Security > Advanced > True client IP header.
    2. Edite o site kube-system/ibm-k8s-controller-config configmap e defina allow-snippet-annotations: "true".
    3. Adicione a anotação nginx.ingress.kubernetes.io/server-snippet: real_ip_header CF-Connecting-IP;.
  2. Ative o protocolo PROXY. Para obter mais informações sobre os parâmetros deste comando, consulte a Referência da CLI. Após a execução desse comando, novos balanceadores de carga são criados com a configuração atualizada do protocolo PROXY. Dois endereços IP não usados de cada balanceador de carga devem estar disponíveis em cada sub-rede durante a recriação do balanceador de carga. Após a criação desses balanceadores de carga, os balanceadores de carga ALB existentes são excluídos. Esse processo de recriação do balanceador de carga pode causar interrupções de serviço.

    ibmcloud ks ingress lb proxy-protocol enable --cluster <cluster_name_or_ID> --cidr <subnet_CIDR> --header-timeout <timeout>
    
  3. Confirme se o protocolo PROXY está ativado para os balanceadores de carga que expõem ALBs em seu cluster.

    ibmcloud ks ingress lb get --cluster <cluster_name_or_ID>
    
  4. Para desativar posteriormente o protocolo PROXY, é possível executar o comando a seguir:

    ibmcloud ks ingress lb proxy-protocol disable --cluster <cluster_name_or_ID>
    

Mudando a externalTrafficPolicy em clusters clássicos

Preserve o endereço IP de origem para solicitações de cliente em um cluster clássico.

Nos clusters Classic, aumentar a contagem de réplicas do ALB para mais de 2 aumenta o número de réplicas, mas quando o " externalTrafficPolicy é configurado como " Local, as réplicas com mais de 2 não são usadas. Apenas 2 pods de balanceador de carga estão presentes no cluster (em uma configuração ativo-passivo) e, devido a essa política de tráfego, apenas encaminham o tráfego de entrada para o pod ALB no mesmo nó.

Por padrão, o endereço IP de origem da solicitação do cliente não é preservado. Quando uma solicitação do cliente para o seu app for enviada para o seu cluster, a solicitação será roteada para um pod para o serviço do balanceador de carga que expõe o ALB. Se nenhum pod de app existir no mesmo nó do trabalhador que o pod de serviço de balanceador de carga, o balanceador de carga encaminhará a solicitação para um pod de app em um nó do trabalhador diferente. O endereço IP de origem do pacote é mudado para o endereço IP público do nó do trabalhador no qual o pod do app é executado.

Para preservar o endereço IP de origem original da solicitação do cliente, é possível ativar a preservação de IP de origem. Preservar o IP do cliente é útil, por exemplo, quando os servidores de app precisam aplicar as políticas de segurança e de controle de acesso.

Quando a preservação do IP de origem está ativada, os balanceadores de carga mudam do encaminhamento do tráfego para um pod ALB em um nó de trabalho diferente para um pod ALB no mesmo nó de trabalho. Seus apps podem experienciar um tempo de inatividade durante esta mudança. Se você desativar um ALB, qualquer mudança de IP de origem que fizer no serviço do balanceador de carga que expõe o ALB será perdida. Quando você reativa o ALB, deve-se ativar o IP de origem novamente.

Para ativar a preservação de IP de origem, edite o serviço de balanceador de carga que expõe um ALB do Ingress:

  1. Ative a preservação de IP de origem para um único ALB ou para todos os ALBs em seu cluster.

    • Para configurar a preservação de IP de origem para um único ALB:

      1. Obtenha o ID do ALB para o qual você deseja ativar o IP de origem. Os serviços ALB têm um formato semelhante a public-cr18e61e63c6e94b658596ca93d087eed9-alb1 para um ALB público ou private-cr18e61e63c6e94b658596ca93d087eed9-alb1 para um ALB privado.

        kubectl get svc -n kube-system | grep alb
        
      2. Abra o YAML para o serviço de balanceador de carga que expõe o ALB.

        kubectl edit svc <ALB_ID> -n kube-system
        
      3. Em spec, mude o valor de externalTrafficPolicy de Cluster para Local.

      4. Salve e feche o arquivo de configuração. A saída é semelhante à seguinte:

        service "public-cr18e61e63c6e94b658596ca93d087eed9-alb1" edited
        
    • Para configurar a preservação de IP de origem para todos os ALBs públicos em seu cluster, execute o comando a seguir:

      kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^public" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Local"}}'; done
      

      Saída de exemplo

      "public-cr18e61e63c6e94b658596ca93d087eed9-alb1", "public-cr17e61e63c6e94b658596ca92d087eed9-alb2" patched
      
    • Para configurar a preservação de IP de origem para todos os ALBs privados em seu cluster, execute o comando a seguir:

      kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^private" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Local"}}'; done
      

      Saída de exemplo

      "private-cr18e61e63c6e94b658596ca93d087eed9-alb1", "private-cr17e61e63c6e94b658596ca92d087eed9-alb2" patched
      
  2. Verifique se o IP de origem está sendo preservado em seus logs de pods do ALB.

    1. Obtenha o ID de um pod para o ALB que você modificou.
      kubectl get pods -n kube-system | grep alb
      
    2. Abra os logs para esse pod do ALB. Verifique se o endereço IP para o campo client é o endereço IP de solicitação do cliente em vez do endereço IP do serviço de balanceador de carga.
      kubectl logs <ALB_pod_ID> nginx-ingress -n kube-system
      
  3. Agora, ao consultar os cabeçalhos para as solicitações que são enviadas para o seu app back-end, é possível ver o endereço IP do cliente no cabeçalho x-forwarded-for.

  4. Se você não desejar mais preservar o IP de origem, será possível reverter as mudanças feitas no serviço.

    • Para reverter a preservação do IP de origem para seus ALBs públicos:
      kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^public" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'; done
      
    • Para reverter a preservação do IP de origem para seus ALBs privados:
      kubectl get svc -n kube-system | grep alb | awk '{print $1}' | grep "^private" | while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'; done
      

Configurando protocolos SSL e cifras SSL no nível de HTTP

Ative protocolos e cifras SSL no nível do HTTP global, editando o configmap ibm-k8s-controller-config.

Por exemplo, se você ainda tiver clientes anteriores que requeiram o suporte do TLS 1.0 ou 1.1, essas versões do TLS deverão ser ativadas manualmente para substituir apenas a configuração padrão do TLS 1.2 e do TLS 1.3.

Quando você especifica os protocolos ativados para todos os hosts, os parâmetros TLSv1.1 e TLSv1.2 (1.1.13, 1.0.12) funcionam somente quando o OpenSSL 1.0.1 ou superior é usado. O parâmetro TLSv1.3 (1.13.0) funciona somente quando o OpenSSL 1.1.1 construído com o suporte TLSv1.3 é usado.

Para editar o configmap para ativar protocolos e cifras SSL:

  1. Edite o arquivo de configuração para o recurso do configmap ibm-k8s-controller-config.

    kubectl edit cm ibm-k8s-controller-config -n kube-system
    
  2. Inclua os protocolos e cifras SSL. Formate as cifras de acordo com o Formato de lista de cifras da biblioteca OpenSSL.

    apiVersion: v1
    data:
      ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"
      ssl-ciphers: "HIGH:!aNULL:!MD5:!CAMELLIA:!AESCCM:!ECDH+CHACHA20"
    kind: ConfigMap
    metadata:
      name: ibm-k8s-controller-config
      namespace: kube-system
    
  3. Salve o arquivo de configuração.

  4. Verifique se as mudanças de configmap foram aplicadas. As mudanças são aplicadas a seus ALBs automaticamente.

    kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
    

Enviando seu certificado customizado para clientes anteriores

Se você tiver dispositivos legados que não suportam o Server Name Indication (SNI) e usar um certificado TLS customizado nos recursos Ingress, você deverá editar as configurações de servidor do ALB para usar o certificado TLS customizado e o segredo TLS customizado.

Ao criar um cluster clássico, um certificado Let's Encrypt é gerado para o segredo do Ingress padrão que a IBM fornece. Se você criar um segredo customizado em seu cluster e especificá-lo para finalização do TLS em seus recursos do Ingress, o ALB do Ingress enviará o certificado para o seu segredo customizado ao cliente em vez do certificado Let's Encrypt padrão. No entanto, se um cliente não suportar SNI, o ALB do Ingress será padronizado para o certificado Let's Encrypt porque o segredo padrão é listado nas configurações de servidor padrão do ALB. Para enviar o certificado customizado para dispositivos que não suportam SNI, conclua as etapas a seguir para mudar as configurações de servidor padrão do ALB para o segredo customizado.

Os certificados Let's Encrypt gerados por padrão não são destinados ao uso de produção. Para as cargas de trabalho de produção, traga o seu próprio certificado customizado.

  1. Edite o recurso do Ingress alb-default-server.

    kubectl edit ingress alb-default-server -n kube-system
    
  2. Na seção spec.tls, mude o valor da configuração hosts.secretName para o nome de seu segredo customizado que contenha seu certificado customizado. Exemplo:

    spec:
        rules:
        ...
        tls:
        - hosts:
        - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
        secretName: <custom_secret_name>
    
  3. Salve o arquivo de recursos.

  4. Verifique se o recurso agora aponta para o nome do segredo customizado. As mudanças são aplicadas a seus ALBs automaticamente.

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

Ajuste fino do tratamento de conexões

As definições client-header-timeout, client-body-timeout e keep-alive 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.

O endereço client-header-timeout define o tempo máximo que o servidor aguarda por um cabeçalho de cliente completo. Da mesma forma, o client-body-timeout indica a duração que o servidor aguarda para que o cliente envie o corpo da solicitação. Esses dois tempos limite devem estar alinhados com o parâmetro keep-alive, que regula por quanto tempo o servidor mantém uma conexão aberta enquanto aguarda outras solicitações. Se esses tempos limite não corresponderem à configuração keep-alive, o NGINX encerrará a conexão, o que pode levar a um comportamento inesperado do cliente ou a falhas de solicitação.

Você pode definir os parâmetros acima no espaço de nomes ibm-k8s-controller-config ConfigMap no espaço de nomes kube-system.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  namespace: kube-system
data:
  ...
  client-body-timeout: "100"
  client-header-timeout: "100"
  keep-alive: "100"

Para obter mais informações, consulte a seção client-header-timeout, client-body-timeout e keep-alive na documentação do Ingress Nginx.

Ajuste de timeouts

Se os seus clusters estiverem expostos com IBM Cloud Cloud Internet Services (CIS) / Cloudflare e usarem o WAF (Web Application Firewall) ou o balanceamento de carga global, você deverá definir os parâmetros client-header-timeout, client-body-timeout e keep-alive no recurso ibm-k8s-controller-config localizado no espaço de nomes kube-system para valores superiores a 900 segundos para evitar o encerramento prematuro da conexão. Para obter mais informações, consulte a documentação da Cloudflare.

  1. Atualize os parâmetros client-header-timeout, client-body-timeout e keep-alive no ibm-k8s-controller-config ConfigMap dentro do namespace kube-system. Um exemplo de comando para definir cada parâmetro como 905 segundos é o seguinte:

    kubectl patch cm --patch '{"data": {"client-header-timeout": "905", "client-body-timeout": "905", "keep-alive": "905"}}' --type=merge -n kube-system ibm-k8s-controller-config
    
  2. Somente clusters VPC: também é necessário modificar o tempo limite de conexão ociosa para o balanceador de carga VPC. Ajuste o tempo limite do serviço public-cr<clusterid> LoadBalancer. Um exemplo de comando que o define como 910 segundos é o seguinte:

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

Ajustando o desempenho do ALB

Para otimizar o desempenho de seus ALBs do Ingress, é possível mudar as configurações padrão de acordo com suas necessidades.

Ativando o armazenamento em buffer do log e o tempo limite de liberação

Por padrão, o ALB do Ingress registra cada solicitação conforme ela chega. Se você tem um ambiente que é intensamente usado, a criação de log de cada solicitação à medida que ela chega pode aumentar significativamente a utilização de E/S do disco. Para evitar E/S de disco contínuas, é possível ativar o buffer de log e o tempo limite de liberação para o ALB editando o configmap ibm-k8s-controller-config do Ingress. Quando o armazenamento em buffer está ativado, em vez de executar uma operação de gravação separada para cada entrada de log, o ALB armazena em buffer uma série de entradas e as grava em um arquivo em uma única operação.

  1. Edite o configmap ibm-k8s-controller-config.

    kubectl edit cm ibm-k8s-controller-config -n kube-system
    
  2. Configure o limite para quando o ALB deve gravar o conteúdo armazenado em buffer no log.

    • Tamanho do buffer: inclua o campo buffer e configure-o para o quanto a memória de log pode reter no buffer antes que o ALB grave os conteúdos armazenados em buffer no arquivo de log. Por exemplo, se o valor padrão de 100KB for usado, o ALB gravará os conteúdos de buffer no arquivo de log toda vez que o buffer atingir 100 KB de conteúdo de log.
    • Intervalo de tempo: inclua o campo flush e configure-o com a frequência que o ALB deve gravar no arquivo de log. Por exemplo, se o valor padrão de 5m for usado, o ALB gravará os conteúdos de buffer no arquivo de log uma vez a cada 5 minutos.
    • Intervalo de tempo ou tamanho de buffer: quando flush e buffer forem configurados, o ALB gravará o conteúdo de buffer no arquivo de log com base no parâmetro de limite que seja correspondido primeiro.
    apiVersion: v1
    kind: ConfigMap
    data:
        access-log-params: "buffer=100KB, flush=5m"
      metadata:
    name: ibm-k8s-controller-config
    ...
    
  3. Salve e feche o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.

  4. Verifique se os logs para um ALB agora contêm conteúdo armazenado em buffer que é gravado de acordo com o tamanho de memória ou intervalo de tempo que você configurou.

    kubectl logs -n kube-system <ALB_ID> -c nginx-ingress
    

Mudando o número ou a duração das conexões keep-alive

As conexões keep-alive podem ter um grande impacto no desempenho reduzindo o uso de CPU e de rede que é necessário para abrir e fechar conexões. Para otimizar o desempenho de seus ALBs, é possível mudar o número máximo de conexões keep-alive entre o ALB e o cliente e por quanto tempo as conexões keep-alive podem durar.

  1. Edite o configmap ibm-k8s-controller-config.

    kubectl edit cm ibm-k8s-controller-config -n kube-system
    
  2. Mude os valores de keep-alive-requests e keep-alive.

    • keep-alive-requests: o número de conexões do cliente keep-alive que podem permanecer abertas para o ALB do Ingress. O padrão é 100.
    • keep-alive: o tempo limite, em segundos, durante o qual a conexão do cliente keep-alive permanece aberta para o ALB do Ingress. O padrão é 75.
    apiVersion: v1
    data:
      keep-alive-requests: 100
      keep-alive: 75
    kind: ConfigMap
    metadata:
      name: ibm-k8s-controller-config
      ...
    
  3. Salve e feche o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.

  4. Verifique se as mudanças de configmap foram aplicadas.

    kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
    

Mudando o número de conexões simultâneas ou de processos do trabalhador

Mude a configuração padrão para quantas conexões simultâneas os processos do trabalhador NGINX para um ALB podem manipular ou quantos processos do trabalhador podem ocorrer para um ALB.

Cada ALB possui processos do trabalhador NGINX que processam as conexões do cliente e se comunicam com os servidores de envio de dados para os apps que o ALB expõe. Ao mudar o número de processos do trabalhador por ALB ou quantas conexões os processos do trabalhador podem manipular, é possível gerenciar o número máximo de clientes que um ALB pode manipular. Calcule suas conexões máximas do cliente com a fórmula a seguir: maximum clients = worker_processes * worker_connections.

  • O campo max-worker-connections configura o número máximo de conexões simultâneas que podem ser manipuladas pelos processos do trabalhador NGINX para um ALB. O valor padrão é 16384. Observe que o parâmetro max-worker-connections inclui todas as conexões de proxy do ALB, não apenas conexões com clientes. Além disso, o número real de conexões simultâneas não pode exceder o limite no número máximo de arquivos abertos, que é configurado pelo parâmetro max-worker-open-files. Se você configurar o valor de max-worker-connections como 0, o valor de max-worker-open-files será usado como alternativa.
  • O campo worker-processes configura o número máximo de processos do trabalhador NGINX para um ALB. O valor padrão é "auto", o qual indica que o número de processos do trabalhador corresponde ao número de núcleos no nó do trabalhador no qual o ALB é implementado. Será possível mudar esse valor para um número se seus processos do trabalhador precisarem executar altos níveis de operações de E/S.
  1. Edite o configmap ibm-k8s-controller-config.

    kubectl edit cm ibm-k8s-controller-config -n kube-system
    
  2. Mude o valor de max-worker-connections ou worker-processes.

    apiVersion: v1
    data:
      max-worker-connections: 16384
      worker-processes: "auto"
    kind: ConfigMap
    metadata:
      name: ibm-k8s-controller-config
      ...
    
  3. Salve o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.

  4. Verifique se as mudanças de configmap foram aplicadas.

    kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
    

Mudando o número de arquivos abertos para processos do trabalhador

Mude o máximo padrão para o número de arquivos que podem ser abertos por cada processo do nó do trabalhador para um ALB.

Cada ALB possui processos do trabalhador NGINX que processam as conexões do cliente e se comunicam com os servidores de envio de dados para os apps que o ALB expõe. Se os seus processos do trabalhador estiverem atingindo o número máximo de arquivos que podem ser abertos, será provável ver um erro Too many open files em seus logs do NGINX. Por padrão, o parâmetro max-worker-open-files é configurado como 0, o que indica que o valor da fórmula a seguir é usado: system limit of maximum open files / worker-processes - 1024. Se você mudar o valor para outro número inteiro, a fórmula não será mais aplicada.

  1. Edite o configmap ibm-k8s-controller-config.

    kubectl edit cm ibm-k8s-controller-config -n kube-system
    
  2. Mude o valor de max-worker-open-files.

    apiVersion: v1
    data:
      max-worker-open-files: 0
    kind: ConfigMap
    metadata:
      name: ibm-k8s-controller-config
      ...
    
  3. Salve o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.

  4. Verifique se as mudanças de configmap foram aplicadas.

    kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
    

Ajustando o desempenho do kernel

Para otimizar o desempenho de seus ALBs do Ingress, também é possível mudar os parâmetros sysctl do kernel do Linux em nós do trabalhador. Os nós do trabalhador são provisionados automaticamente com o ajuste do kernel otimizado, portanto, mude essas configurações somente se você tiver requisitos de otimização de desempenho específicos.