Criação de um ingress do ELB no console

Pré-requisitos

• Um ingress fornece acesso à rede para cargas de trabalho de back-end. Certifique-se de que uma carga de trabalho esteja disponível em um cluster. Se nenhuma carga de trabalho estiver disponível, implemente uma carga de trabalho referindo-se a Criação de uma Implantação, Criação de um StatefulSet ou Criação de um DaemonSet.
• Serviços suportados por ingresses lista os tipos de Serviços suportados pelos ingresses do ELB.

Precauções

• Recomenda-se que outros recursos não usem o balanceador de carga criado automaticamente por um ingress. Caso contrário, o balanceador de carga será ocupado quando o ingress for excluído, resultando em recursos residuais.
• Depois que um ingress é criado, atualize e mantenha a configuração dos balanceadores de carga selecionados no console do CCE. Não modifique a configuração no console do ELB. Caso contrário, o serviço de ingress pode ser anormal.
• O URL registrado em uma política de encaminhamento de entrada deve ser o mesmo que o URL usado para acessar o Serviço de back-end. Caso contrário, um erro 404 será retornado.
• Em um cluster usando o modo de proxy IPVS, se o ingress e o Serviço usarem o mesmo balanceador de carga do ELB, o ingress não pode ser acessado dos nós e contêineres no cluster porque o kube-proxy monta o endereço do Serviço LoadBalancer na ponte ipvs-0. Essa ponte intercepta o tráfego do balanceador de carga conectado ao ingress. Use balanceadores de carga do ELB diferentes para o ingress e o Serviço.
• Não conecte o ingress e o Serviço usando HTTP ao mesmo ouvinte do mesmo balanceador de carga. Caso contrário, ocorre um conflito de portas.
• Os balanceadores de carga dedicados devem ser do tipo de aplicação (HTTP/HTTPS) que suportam redes privadas (com um IP privado).
• Se vários ingresses forem usadas para se conectar à mesma porta do ELB no mesmo cluster, os itens de configuração do ouvinte (como o certificado associado ao ouvinte e o atributo HTTP2 do ouvinte) estão sujeitos à configuração da primeiro ingress.

Adicionar um ingress do ELB

Esta seção usa uma carga de trabalho de Nginx como um exemplo para descrever como adicionar um ingress do ELB.

1. Efetue logon no console do CCE e acesse o console do cluster.
2. Escolha Networking no painel de navegação, clique a guia Ingresses e clique em Create Ingress no canto direito superior.
3. Configure parâmetros de ingress.
   • Name: especifica o nome de uma entrada, por exemplo, ingress-demo.
   • Interconnect with Nginx: essa opção é exibida somente após a instalação do complemento Nginx Ingress controller. Se essa opção estiver disponível, o complemento nginx-ingress foi instalado. Ative essa opção criará um ingress de Nginx Desative-o se quiser criar um ingress do ELB. Para mais detalhes, consulte Criação de ingresses de Nginx no console.
   • Load Balancer

     Selecione o balanceador de carga para interconexão. Somente balanceadores de carga na mesma VPC que o cluster são compatíveis. Se nenhum balanceador de carga estiver disponível, clique em Create Load Balancer para criar um no console do ELB.

     Os balanceadores de carga dedicados devem oferecer suporte a HTTP ou HTTPS e o tipo de rede deve oferecer suporte a redes privadas.

     O console do CCE suporta a criação automática de balanceadores de carga. Selecione Auto create na caixa de listagem suspensa e configure os seguintes parâmetros:

     • Instance Name: insira o nome de um balanceador de carga.
     • Public Access: se ativado, um EIP com largura de banda de 5 Mbit/s será criado. Por padrão, é cobrado pelo tráfego.
     • AZ, Subnet e Specifications (disponível apenas para balanceadores de carga dedicados): selecione a AZ, sub-rede e as especificações. Somente balanceadores de carga dedicados do tipo de aplicações (HTTP/HTTPS) podem ser criados automaticamente.
   • Listener: o ingress configura um ouvinte para o balanceador de carga, que atende às solicitações do balanceador de carga e distribui o tráfego. Após a conclusão da configuração, um ouvinte é criado no balanceador de carga. O nome padrão do ouvinte é k8s__<Protocol type>_<Port number>, por exemplo, k8s_HTTP_80.
     • Front-End Protocol: HTTP e HTTPS estão disponíveis.
     • External Port: número da porta que está aberta para o endereço de serviço do ELB. O número da porta pode ser especificado aleatoriamente.
     • Certificate Source: o segredo do TLS e o certificado de servidor ELB são suportados.
     • Server Certificate: quando um ouvinte HTTPS for criado para um balanceador de carga, vincule um certificado ao balanceador de carga para oferecer suporte à autenticação criptografada para transmissão de dados de HTTPS.
       • TLS secret: para obter detalhes sobre como criar um segredo, consulte Criação de um segredo.
       • ELB server certificate: use o certificado criado no serviço ELB.
       

       Se já houver um ingress HTTPS para a porta escolhida no balanceador de carga, o certificado do novo ingress HTTPS deve ser igual ao certificado do ingress existente. Isso significa que um ouvinte tem apenas um certificado. Se dois certificados, cada um com um ingress diferente, forem adicionados ao mesmo ouvinte do mesmo balanceador de carga, somente o certificado adicionado mais cedo terá efeito no balanceador de carga.

     • SNI: o Server Name Indication (SNI) é um protocolo estendido do TLS. Ele permite que vários nomes de domínio de acesso baseados em TLS sejam fornecidos para sistemas externos usando o mesmo endereço IP e porta. Nomes de domínio diferentes podem usar certificados de segurança diferentes. Depois que o SNI é habilitado, o cliente tem permissão para enviar o nome de domínio solicitado ao iniciar uma solicitação de handshake TLS. Depois de receber a solicitação TLS, o balanceador de carga procura o certificado com base no nome de domínio na solicitação. Se o certificado correspondente ao nome de domínio for encontrado, o balanceador de carga retornará o certificado para autorização. Caso contrário, o certificado padrão (certificado de servidor) é retornado para autorização.
       

       • A opção SNI está disponível somente quando HTTPS é selecionado.

       • Esta função é suportada apenas em clusters de v1.15.11 e posteriores
       • Especifique o nome de domínio para o certificado de SNI. Apenas um nome de domínio pode ser especificado para cada certificado. Certificados de domínio curinga são suportados.
   • Forwarding Policies: quando o endereço de acesso de uma solicitação corresponde à política de encaminhamento (uma política de encaminhamento consiste em um nome de domínio e URL, por exemplo, 10.117.117.117:80/helloworld), a solicitação é encaminhada ao Serviço de destino correspondente para processamento. Você pode clicar em para adicionar várias políticas de encaminhamento.
     • Domain Name: nome de domínio atual. Certifique-se de que o nome de domínio tenha sido registrado e arquivado. Depois que uma regra de nome de domínio estiver configurada, você deve usar o nome de domínio para acesso.
     • URL Matching Rule
       • Prefix match: se o URL estiver definido como /healthz, o URL que atende ao prefixo poderá ser acessado, por exemplo, /healthz/v1 e /healthz/v2.
       • Exact match: o URL pode ser acessado somente quando é totalmente correspondido. Por exemplo, se o URL estiver definido como /healthz, apenas /healthz poderá ser acessado.
       • Regular expression: o URL é correspondido com base na expressão regular. Por exemplo, se a expressão regular for /[A-Za-z0-9_.-]+/test, todos os URLs que estejam em conformidade com essa regra poderão ser acessadas, por exemplo, /abcA9/test e /v1-Ab/test. Dois padrões de expressão regular são suportados: POSIX e Perl.
     • URL: caminho de acesso a ser registrado, por exemplo, /healthz.
       

       O caminho de acesso adicionado aqui deve existir na aplicação back-end. Caso contrário, o encaminhamento falha.

       Por exemplo, o URL de acesso padrão da aplicação Nginx é /usr/share/nginx/html. Ao adicionar /test à política de encaminhamento de ingress, certifique-se de que o URL de acesso da sua aplicação Nginx contenha /usr/share/nginx/html/test. Caso contrário, o erro 404 será retornado.

     • Destination Service: selecione um Serviço existente ou crie um Serviço. Os Serviços que não atendem aos critérios de pesquisa são automaticamente filtrados.
     • Destination Service Port: selecione a porta de acesso do Serviço de destino.
     • Configure ELB:
       • Algorithm: três algoritmos estão disponíveis: weighted round robin, weighted least connections algorithm ou source IP hash.
         

         • Weighted round robin: as solicitações são encaminhadas para servidores diferentes com base em seus pesos, que indicam o desempenho do processamento do servidor. Servidores back-end com pesos mais altos recebem proporcionalmente mais solicitações, enquanto servidores com pesos iguais recebem o mesmo número de solicitações. Este algoritmo é normalmente usado para conexões curtas, como serviços HTTP.
         • Weighted least connections: além do peso atribuído a cada servidor, o número de conexões processadas por cada servidor back-end também é considerado. As solicitações são encaminhadas ao servidor com a menor relação entre conexões e peso. Desenvolvido com base no algoritmo de menos conexões, o algoritmo weighted least connections atribui um peso a cada servidor de acordo com sua capacidade de processamento. Este algoritmo é normalmente usado para conexões persistentes, como conexões de bancos de dados.
         • Source IP hash: o endereço IP de origem de cada solicitação é calculado usando-se o algoritmo de hash para obter uma chave de hash única, e todos os servidores back-end são numerados. A chave gerada aloca o cliente a um servidor particular. Isso permite que solicitações de clientes diferentes sejam distribuídas no modo de balanceamento de carga e garante que as solicitações do mesmo cliente sejam encaminhadas para o mesmo servidor. Este algoritmo aplica-se a conexões TCP sem cookies.
       • Sticky Session: esta função está desativada por padrão. As opções são as seguintes:
         • Load balancer cookie: digite a Stickiness Duration, que varia de 1 a 1.440 minutos.
         • Application cookie: esse parâmetro está disponível apenas para balanceadores de carga compartilhados. Além disso, insira Cookie Name, que varia de 1 a 64 caracteres.
         

         Quando a política de distribuição utiliza o hash do IP de origem, a sessão adesiva não pode ser definida.

       • Health Check: defina a configuração de verificação de integridade do balanceador de carga. Se esta função estiver ativada, as seguintes configurações são suportadas:

         Parâmetro	Descrição
         Protocol	Quando o protocolo de porta é definido como TCP, TCP e HTTP são suportados. Quando o protocolo é definido como UDP, apenas UDP é suportado. Check Path (suportado apenas por HTTP para verificação de integridade): especifica o URL de verificação de integridade. O caminho de verificação deve começar com uma barra (/) e pode conter de 1 a 80 caracteres.
         Port	Por padrão, a porta de serviço (Porta de nó e porta de contêiner do Serviço) é usada para verificação de integridade. Você também pode especificar uma porta para verificação de integridade. Depois que a porta for especificada, uma porta de serviço chamada cce-healthz será adicionada ao Serviço. Node Port: se um balanceador de carga compartilhado for usado ou nenhuma instância de ENI estiver associada, a porta do nó será usada como a porta de verificação de integridade. Se este parâmetro não for especificado, uma porta aleatória será usada. O valor varia de 30000 a 32767. Container Port: quando um balanceador de carga dedicado é associado a uma instância de ENI, a porta do contêiner é usada para verificação de integridade. O valor varia de 1 a 65535.
         Check Period (s)	Especifica o intervalo máximo entre as verificações de integridade. O valor varia de 1 a 50.
         Timeout (s)	Especifica a duração máxima do tempo limite para cada verificação de integridade. O valor varia de 1 a 50.
         Max. Retries	Especifica o número máximo de tentativas de verificação de integridade. O valor varia de 1 a 10.

     • Operation: clique em Delete para excluir a configuração.
   • Annotation: os ingresses fornecem algumas funções avançadas do CCE, que são implementadas por anotações. Quando você usa o kubectl para criar um contêiner, as anotações serão usadas. Para mais detalhes, veja Criar um ingress - criar automaticamente um balanceador de carga e Criar um ingress - interconectarse com um balanceador de carga existente.

4. Após a conclusão da configuração, clique em OK. Depois que o ingress é criado, ele é exibido na lista de ingresses.

   No console do ELB, você pode ver o ELB criado automaticamente por meio do CCE. O nome padrão é cce-lb-ingress.UID. Clique no nome do ELB para acessar sua página de detalhes. Na página de guia Listeners, exiba as definições de rota do ingresso, incluindo o URL, a porta do ouvinte e a porta do grupo de servidores de back-end.

   

   Depois que um ingress for criado, atualize e mantenha o balanceador de carga selecionado no console do CCE. Não modifique a configuração no console do ELB. Caso contrário, o serviço de ingress pode ser anormal.

   Figura 1 Configuração de roteamento do ELB
   

5. Acesse a interface /healthz da carga de trabalho, por exemplo, carga de trabalho defaultbackend.
   1. Obtenha o endereço de acesso da interface /healthz da carga de trabalho. O endereço de acesso consiste no endereço IP do balanceador de carga, porta externa e URL de mapeamento, por exemplo, 10.**.**.**:80/healthz.
   2. Digite o URL da interface /healthz, por exemplo, http://10.**.**.**:80/healthz, na caixa de endereço do navegador para acessar a carga de trabalho, conforme mostrado em Figura 2.
      Figura 2 Acessar a interface /healthz de defaultbackend
      

Operações relacionadas

A estrutura de ingress do Kubernetes não contém o campo property. Portanto, o ingress criado pela API chamada pelo client-go não contém o campo property. O CCE fornece uma solução para garantir a compatibilidade com o client-go do Kubernetes. Para obter detalhes sobre a solução, consulte Como obter compatibilidade entre a propriedade do ingress e o cliente-go do Kubernetes?