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.
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;
}
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.
-
Crie um configmap
tcp-services
para especificar a sua porta TCP, como as portas de exemplo a seguir. Para os requisitos do configmaptcp-services
, consulte este blog.apiVersion: v1 kind: ConfigMap metadata: name: tcp-services namespace: kube-system data: 9000: "<namespace>/<service>:8080"
-
Crie o configmap no namespace
kube-system
.kubectl apply -f tcp-services.yaml -n kube-system
-
Especifique o configmap
tcp-services
como um campo no configmapibm-ingress-deploy-config
."tcpServicesConfig":"kube-system/tcp-services"
-
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
.
-
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
-
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çãospec.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
ouprivate-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 emNGINX
3
: Mostra os detalhes sobre o serviço, regra do Ingress e mudanças de terminais no formato JSON.5
: Configura o siteNGINX
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"
.
-
Crie o configmap
ibm-ingress-deploy-config
em seu cluster.kubectl create -f ibm-ingress-deploy-config.yaml
-
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>
-
Se você tiver especificado portas HTTP, HTTPS ou TCP não padrão, elas deverão ser abertas em cada serviço do ALB.
-
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>
-
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 umnodePort
. Após incluir a porta e aplicar as mudanças, umnodePort
é 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> ...
-
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.
-
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:
- 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.
- Escolha a mesma região na qual seu cluster está implementado.
- Clique em Criar.
-
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.
- No console de gerenciamento do App ID, navegue para Gerenciar autenticação.
- 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.
- 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 formatohttps://<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á definirwhitelist_domains
em ConfigMap para OAuth2-Proxy. Ligue para o terminalhttps://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out
com o parâmetro de consultard
ou configure o cabeçalhoX-Auth-Request-Redirect
com a sua página de logout personalizada. Para obter mais detalhes, veja Inscrever-se. -
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>
-
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-
.- Ative o complemento
alb-oauth-proxy
.ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID>
- Verifique se o complemento ALB OAuth Proxy tem um status de
Addon Ready
.ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
- Ative o complemento
-
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
.-
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 ...
-
À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 peloOAuth2-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 } ...
-
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çãoconfiguration-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 oID Token
, adicione as seguintes informações à anotaçãoconfiguration-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 } ...
-
-
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
.
-
-
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
-
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.
-
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.
-
Opcional: é possível customizar o comportamento padrão do OAuth2-Proxy criando um ConfigMap do Kubernetes.
- 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
- 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
- Crie um arquivo YAML do ConfigMap que especifique valores para as configurações de OAuth2-Proxy que você deseja mudar.
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.
- Desative o complemento .
ibmcloud ks cluster addon disable alb-oauth-proxy --cluster <cluster_name_or_ID>
- Liste as versões de complemento disponíveis e decida qual versão deseja utilizar.
ibmcloud ks cluster addon versions --addon alb-oauth-proxy
- 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.
-
Opcional Conclua as etapas a seguir se estiver usando o site Cloud Internet Services (CIS).
- Ative a configuração True client IP header no console CIS, clicando em Security > Advanced > True client IP header.
- Edite o site
kube-system/ibm-k8s-controller-config configmap
e definaallow-snippet-annotations: "true"
. - Adicione a anotação
nginx.ingress.kubernetes.io/server-snippet: real_ip_header CF-Connecting-IP;
.
-
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>
-
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>
-
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:
-
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:
-
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 ouprivate-cr18e61e63c6e94b658596ca93d087eed9-alb1
para um ALB privado.kubectl get svc -n kube-system | grep alb
-
Abra o YAML para o serviço de balanceador de carga que expõe o ALB.
kubectl edit svc <ALB_ID> -n kube-system
-
Em
spec
, mude o valor deexternalTrafficPolicy
deCluster
paraLocal
. -
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
-
-
Verifique se o IP de origem está sendo preservado em seus logs de pods do ALB.
- Obtenha o ID de um pod para o ALB que você modificou.
kubectl get pods -n kube-system | grep alb
- 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
- Obtenha o ID de um pod para o ALB que você modificou.
-
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
. -
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
- Para reverter a preservação do IP de origem para seus ALBs públicos:
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:
-
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
-
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
-
Salve o arquivo de configuração.
-
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.
-
Edite o recurso do Ingress
alb-default-server
.kubectl edit ingress alb-default-server -n kube-system
-
Na seção
spec.tls
, mude o valor da configuraçãohosts.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>
-
Salve o arquivo de recursos.
-
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.
-
Atualize os parâmetros
client-header-timeout
,client-body-timeout
ekeep-alive
noibm-k8s-controller-config
ConfigMap dentro do namespacekube-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
-
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.
-
Edite o configmap
ibm-k8s-controller-config
.kubectl edit cm ibm-k8s-controller-config -n kube-system
-
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 de100KB
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 de5m
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
ebuffer
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 ...
- Tamanho do buffer: inclua o campo
-
Salve e feche o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.
-
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.
-
Edite o configmap
ibm-k8s-controller-config
.kubectl edit cm ibm-k8s-controller-config -n kube-system
-
Mude os valores de
keep-alive-requests
ekeep-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 ...
-
Salve e feche o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.
-
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âmetromax-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âmetromax-worker-open-files
. Se você configurar o valor demax-worker-connections
como0
, o valor demax-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.
-
Edite o configmap
ibm-k8s-controller-config
.kubectl edit cm ibm-k8s-controller-config -n kube-system
-
Mude o valor de
max-worker-connections
ouworker-processes
.apiVersion: v1 data: max-worker-connections: 16384 worker-processes: "auto" kind: ConfigMap metadata: name: ibm-k8s-controller-config ...
-
Salve o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.
-
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.
-
Edite o configmap
ibm-k8s-controller-config
.kubectl edit cm ibm-k8s-controller-config -n kube-system
-
Mude o valor de
max-worker-open-files
.apiVersion: v1 data: max-worker-open-files: 0 kind: ConfigMap metadata: name: ibm-k8s-controller-config ...
-
Salve o arquivo de configuração. As mudanças são aplicadas a seus ALBs automaticamente.
-
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.