Configurando Balanceadores de Carga e Balanceadores de Carga da Rede

É possível criar balanceadores de carga e de carga de rede do Oracle Cloud Infrastructure para controlar o acesso a serviços em execução em um cluster:

• Ao criar um cluster no workflow 'Criação Personalizada', você seleciona uma VCN existente contendo os recursos de rede a serem usados pelo novo cluster. Se você quiser usar um balanceador de carga ou um balanceador de carga de rede para controlar o tráfego na VCN, selecione uma sub-rede pública ou privada existente nessa VCN para hospedá-la.
• Quando você cria um cluster no workflow 'Criação Rápida', a VCN que é criada automaticamente contém uma sub-rede regional pública para hospedar um balanceador de carga ou um balanceador de carga de rede. Se quiser hospedar um balanceador de carga ou um balanceador de carga de rede em uma sub-rede privada, você poderá adicionar uma sub-rede privada à VCN posteriormente.

Como alternativa, você pode definir um serviço interno do Kubernetes do tipo LoadBalancer (geralmente referido simplesmente como 'balanceador de carga interno') em um cluster para permitir que outros programas em execução na mesma VCN que o cluster acessem serviços no cluster. Um balanceador de carga interno pode ser provisionado:

• como um balanceador de carga ou como um balanceador de carga da rede
• com um endereço IP público ou com um endereço IP privado (designado pelo serviço do Balanceador de Carga ou pelo serviço do Balanceador de Carga de Rede)
• em uma sub-rede pública ou em uma sub-rede privada

Um balanceador de carga ou um balanceador de carga de rede com um endereço IP público é chamado de público. Um balanceador de carga público ou um balanceador de carga de rede pode ser hospedado em uma sub-rede pública ou em uma sub-rede privada.

Um balanceador de carga ou um balanceador de carga de rede com um endereço IP privado é chamado de privado. Um balanceador de carga privado ou um balanceador de carga de rede pode ser hospedado em uma sub-rede pública ou em uma sub-rede privada.

Por padrão, os balanceadores de carga internos são provisionados com endereços IP públicos e hospedados em sub-redes públicas.

Para obter mais informações:

• sobre balanceadores de carga públicos e privados do Oracle Cloud Infrastructure, consulte Tipos de Balanceador de Carga.
• sobre balanceadores de carga de rede pública e privada do Oracle Cloud Infrastructure, consulte Tipos de Balanceador de Carga de Rede

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 8100
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/internal: "true"
    oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Quando um serviço Kubernetes do tipo LoadBalancer é implantado em um cluster, o Kubernetes Engine cria um balanceador de carga público ou balanceador de carga de rede do Oracle Cloud Infrastructure para aceitar o tráfego no cluster. Por padrão, o balanceador de carga público do Oracle Cloud Infrastructure ou o balanceador de carga de rede recebe um endereço IP público efêmero. No entanto, um endereço IP público efêmero é temporário e dura apenas durante a vida útil do balanceador de carga público ou do balanceador de carga de rede.

Se quiser que o balanceador de carga público do Oracle Cloud Infrastructure ou o balanceador de carga de rede criado pelo Kubernetes Engine tenha a mesma implantação de endereço IP público após a implantação, você poderá designar a ele um endereço IP público reservado do pool de endereços IP públicos reservados. Para obter mais informações sobre como criar e exibir endereços IP públicos reservados, consulte Endereços IP Públicos.

Para designar um endereço IP público reservado ao balanceador de carga público do Oracle Cloud Infrastructure ou ao balanceador de carga de rede criado pelo Kubernetes Engine, adicione a propriedade LoadBalancerIP na seção de especificação do arquivo de manifesto que define o serviço do tipo LoadBalancer e especifique o endereço IP público reservado.

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Observe o seguinte:

• Se você definir a propriedade loadBalancerIP do serviço LoadBalancer, não poderá mais tarde alterar diretamente o endereço IP do balanceador de carga público ou do balanceador de carga de rede do Oracle Cloud Infrastructure criado pelo Kubernetes Engine. Se você quiser alterar o endereço IP, exclua o serviço LoadBalancer, especifique outro endereço IP público reservado no arquivo de manifesto e implante o serviço LoadBalancer novamente.
• Se você não definir a propriedade loadBalancerIP do serviço LoadBalancer, não poderá alternar posteriormente diretamente o endereço IP do balanceador de carga público do Oracle Cloud Infrastructure ou do balanceador de carga de rede que o Kubernetes Engine cria de um endereço IP efêmero para um endereço IP público reservado. Se você quiser alternar o endereço IP efêmero para um endereço IP público reservado, exclua o serviço do tipo LoadBalancer, defina a propriedade loadBalancerIP para um endereço IP público reservado no arquivo de manifesto e implante o serviço do tipo LoadBalancer novamente.
• Você pode excluir o serviço do tipo LoadBalancer e liberar o endereço IP público reservado para outros usos (por exemplo, para designá-lo a outro serviço do tipo LoadBalancer).
• Você não poderá especificar um endereço IP público reservado para um serviço do tipo LoadBalancer se o mesmo endereço IP já estiver designado a outro recurso (como uma instância de computação ou outro serviço do tipo LoadBalancer).
• Você não pode adicionar a propriedade loadBalancerIP ao arquivo de manifesto para um serviço do balanceador de carga interno (ou seja, um arquivo de manifesto que inclua a anotação service.beta.kubernetes.io/oci-load-balancer-internal: "true" ou oci-network-load-balancer.oraclecloud.com/internal: "true").

• Por padrão, o endereço IP público reservado que você especifica como a propriedade loadBalancerIP de um serviço do tipo LoadBalancer no arquivo de manifesto deve ser um recurso no mesmo compartimento do cluster. Se você quiser especificar um endereço IP público reservado em outro compartimento:

  • para balanceadores de carga públicos, adicione a seguinte política à tenancy:

    ALLOW any-user to read public-ips in tenancy where request.principal.type = 'cluster'
    ALLOW any-user to manage floating-ips in tenancy where request.principal.type = 'cluster'

  • para balanceadores de carga de rede, adicione a seguinte política à tenancy:

    ALLOW any-user to use private-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id=target.compartment.id}
    ALLOW any-user to manage public-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id=target.compartment.id}

Os grupos de segurança de rede (NSGs) do Oracle Cloud Infrastructure permitem controlar o tráfego dentro e fora de recursos e entre recursos. As regras de segurança definidas para um NSG garantem que todos os recursos desse NSG tenham a mesma postura de segurança. Para obter mais informações, consulte Grupos de Segurança de Rede.

Você pode usar NSGs para controlar o acesso ao balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure provisionado pelo Kubernetes Engine para um serviço Kubernetes do tipo LoadBalancer.

Ao usar NSGs para controlar o acesso, devem existir regras de segurança apropriadas para permitir tráfego de entrada e saída de/para a sub-rede do balanceador de carga ou do balanceador de carga de rede. Consulte Regras de Segurança para Balanceadores de Carga e Balanceadores de Carga de Rede.

Se você decidir usar NSGs para controlar o acesso a balanceadores de carga ou balanceadores de carga de rede:

• Você pode ter os NSGs e as regras de segurança totalmente gerenciados para você pelo oci-cloud-controller-manager (consulte Especificando Opções de Gerenciamento de Regra de Segurança para Balanceadores de Carga e Balanceadores de Carga de Rede).
• Você mesmo pode gerenciar os NSGs e as regras de segurança e adicionar o balanceador de carga ou o balanceador de carga de rede aos NSGs existentes (conforme descrito nesta seção).
• Você pode fazer com que o oci-cloud-controller-manager gerencie algumas regras de segurança em um NSG, enquanto gerencia outras regras de segurança em um NSG diferente.

Para controlar o acesso usando um NSG que você gerencia, inclua anotações no arquivo de manifesto para especificar o NSG ao qual deseja adicionar o balanceador de carga ou o balanceador de carga de rede.

oci.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Observe o seguinte:

• O NSG especificado deve estar na mesma VCN que o balanceador de carga ou o balanceador de carga de rede do Oracle Cloud Infrastructure.
• Se o NSG especificado pertencer a outro compartimento do cluster, inclua uma instrução de política semelhante à seguinte em uma política do serviço IAM:

  ALLOW any-user to use network-security-groups in TENANCY where ALL { request.principal.type = 'cluster' }

  Se você considerar essa instrução de política muito permissiva, poderá restringir a permissão para especificar explicitamente o compartimento ao qual o NSG pertence e/ou especificar explicitamente o cluster. Por exemplo:

  Allow any-user to use network-security-groups in compartment <compartment-ocid> where all { request.principal.id = '<cluster-ocid>' }

• Você pode especificar até cinco NSGs, em uma lista separada por vírgulas, no formato:

  oci.oraclecloud.com/oci-network-security-groups: "<nsg1-ocid>,<nsg2-ocid>,<nsg3-ocid>,<nsg4-ocid>,<nsg5-ocid>"

• Para remover um balanceador de carga ou um balanceador de carga de rede de um NSG ou alterar o NSG em que o balanceador de carga ou o balanceador de carga de rede está, atualize a anotação e aplique novamente o manifesto.

• Se você decidir controlar o acesso a um balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure usando um NSG que você gerencia, a Oracle recomenda que você desative o gerenciamento da lista de segurança do Kubernetes adicionando uma das seguintes anotações na seção de metadados do arquivo de manifesto para o balanceador de carga ou o balanceador de carga de rede, respectivamente:

  service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "None"

  oci-network-load-balancer.oraclecloud.com/security-list-management-mode:  "None"

  Como alternativa, você pode adicionar a seguinte anotação equivalente:

  oci.oraclecloud.com/security-rule-management-mode: "None" 

  Se você seguir a recomendação e adicionar a anotação, o gerenciamento da lista de segurança do Kubernetes não será ativado. Você precisa configurar NSGs com regras de segurança de entrada e saída para pools de nós e para o ponto final da API do Kubernetes (para obter mais informações, consulte Configuração de Regra de Segurança em Grupos de Segurança de Rede e/ou Listas de Segurança e Exemplo de Configurações de Recursos de Rede). Você também precisa configurar NSGs com regras de segurança de entrada e saída para a porta de integridade do kube-proxy, para o intervalo de portas de verificação de integridade e para balanceadores de carga.

As regras de segurança controlam o acesso aos balanceadores de carga e aos balanceadores de carga de rede do Oracle Cloud Infrastructure provisionados para serviços do Kubernetes do tipo LoadBalancer. As regras de segurança podem ser gerenciadas (ou seja, criadas, atualizadas e excluídas) das seguintes maneiras:

• Em um grupo de segurança de rede ou NSG (recomendado) As regras de segurança em um NSG se aplicam a qualquer recurso do Kubernetes adicionado ao NSG. Como tal, os NSGs podem fornecer controle de acesso refinado a recursos individuais.
• Em uma lista de segurança. As regras de segurança em uma lista de segurança se aplicam a todos os recursos do Kubernetes em uma sub-rede. As listas de segurança não fornecem controle de acesso refinado a recursos individuais na sub-rede.

Para obter informações importantes sobre como as regras de segurança funcionam e verificar uma comparação geral entre listas de segurança e grupos de segurança de rede, consulte Regras de Segurança.

Você mesmo pode gerenciar as regras de segurança, criando, atualizando e excluindo regras conforme necessário. Como alternativa, você pode especificar que o oci-cloud-controller-manager (que é executado no plano de controle do cluster) deve gerenciar algumas ou todas as regras de segurança para você. O Kubernetes Engine usa o oci-cloud-controller-manager para provisionar balanceadores de carga e balanceadores de carga de rede para serviços do Kubernetes do tipo LoadBalancer.

Você usa anotações diferentes para especificar se o oci-cloud-controller-manager gerencia regras de segurança para um balanceador de carga ou balanceador de carga de rede em um NSG ou em uma lista de segurança, da seguinte forma:

• Para gerenciar regras de segurança em um NSG, use a anotação oci.oraclecloud.com/security-rule-management-mode: "NSG" (recomendado).

  Se quiser que o oci-cloud-controller-manager gerencie regras de segurança em um NSG (conforme recomendado pela Oracle), use a anotação oci.oraclecloud.com/security-rule-management-mode: "NSG". Para obter mais informações sobre como usar essa anotação, consulte Usando a anotação oci.oraclecloud.com/security-rule-management-mode para gerenciar regras de segurança em NSGs e listas de segurança.

• Para gerenciar regras de segurança em uma lista de segurança, use a anotação oci.oraclecloud.com/security-rule-management-mode ou as anotações service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode e oci-network-load-balancer.oraclecloud.com/security-list-management-mode.

  Se você quiser que o oci-cloud-controller-manager gerencie regras de segurança na lista de segurança de um balanceador de carga ou sub-rede do balanceador de carga de rede, faça o seguinte:

  • Use a anotação oci.oraclecloud.com/security-rule-management-mode, definida como "SL-All" ou "SL-Frontend". Para obter mais informações sobre como usar essa anotação, consulte Usando a anotação oci.oraclecloud.com/security-rule-management-mode para gerenciar regras de segurança em NSGs e listas de segurança.
  • Use as anotações service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode e oci-network-load-balancer.oraclecloud.com/security-list-management-mode respectivamente, definidas como "All" ou "Frontend". Para obter mais informações sobre como usar essas duas anotações, consulte Especificando Opções de Gerenciamento de Lista de Segurança ao Provisionar um Balanceador de Carga do OCI e Especificando Opções de Gerenciamento de Lista de Segurança ao Provisionar um Balanceador de Carga de Rede do OCI, respectivamente.

Independentemente das anotações que você usa e se você ou o oci-cloud-controller-manager gerencia regras de segurança em uma lista de segurança ou em um NSG, também é possível especificar o OCID de um ou mais NSGs adicionais aos quais você deseja que o oci-cloud-controller-manager adicione o balanceador de carga ou o balanceador de carga de rede. Nesse caso, você usa a anotação oci.oraclecloud.com/oci-network-security-groups ou oci-network-load-balancer.oraclecloud.com/oci-network-security-groups. Observe que o oci-cloud-controller-manager não gerencia as regras de segurança nos NSGs adicionais especificados por essas anotações; portanto, é sua responsabilidade gerenciar as regras de segurança. Para obter mais informações sobre como usar as anotações oci.oraclecloud.com/oci-network-security-groups ou oci-network-load-balancer.oraclecloud.com/oci-network-security-groups, consulte Especificando Grupos de Segurança de Rede (recomendado).

Os balanceadores de carga e os balanceadores de carga de rede do Oracle Cloud Infrastructure aplicam uma política de verificação de integridade para monitorar continuamente os servidores de backend. Verificação de integridade é um teste para confirmar a disponibilidade do servidor de backend e pode ser uma solicitação ou uma tentativa de conexão. Se um servidor falhar na verificação de integridade, o balanceador de carga ou o balanceador de carga da rede colocará o servidor temporariamente fora de rotação. Se subsequentemente o servidor for aprovado na verificação de integridade, o balanceador de carga ou o balanceador de carga da rede o retornará à rotação.

As políticas de verificação de integridade incluem vários parâmetros, cada um com um valor padrão. Quando o Kubernetes Engine provisiona um balanceador de carga do OCI ou balanceador de carga de rede para um serviço Kubernetes do tipo LoadBalancer, você pode substituir os valores padrão do parâmetro de verificação de integridade incluindo anotações na seção de metadados do arquivo de manifesto. Posteriormente, você poderá adicionar, modificar e excluir essas anotações. Se você excluir uma anotação que especificava um valor para um parâmetro de verificação de integridade, o balanceador de carga ou o balanceador de carga de rede usará o valor padrão do parâmetro.

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-health-check-retries: "5"
    service.beta.kubernetes.io/oci-load-balancer-health-check-interval: "15000"
    service.beta.kubernetes.io/oci-load-balancer-health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/health-check-retries: "5"
    oci-network-load-balancer.oraclecloud.com/health-check-interval: "15000"
    oci-network-load-balancer.oraclecloud.com/health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Observe que, se você não especificar explicitamente os valores do parâmetro de verificação de integridade, incluindo anotações na seção de metadados do arquivo de manifesto, os seguintes padrões serão usados:

Para obter mais informações sobre o balanceador de carga do Oracle Cloud Infrastructure e as políticas de verificação de integridade do balanceador de carga da rede, consulte:

• Verificações de Integridade para Balanceadores de Carga
• Políticas de Verificação de Integridade para Balanceadores de Carga de Rede

O tráfego de entrada para um balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure é distribuído entre os servidores de backend em um conjunto de backend. Por padrão, quando o Kubernetes Engine provisiona um balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure para um serviço Kubernetes do tipo LoadBalancer, todos os nós de trabalho do cluster são incluídos no conjunto de backend.

No entanto, você tem a opção de selecionar apenas um subconjunto de nós de trabalho em um cluster para incluir no conjunto de backend de um determinado balanceador de carga ou balanceador de carga de rede. A inclusão de subconjuntos dos nós de trabalho de um cluster nos conjuntos de backend de diferentes balanceadores de carga e balanceadores de carga de rede permite que você apresente um único cluster do Kubernetes como vários clusters lógicos (serviços).

oci.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
    oci-network-load-balancer.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Use a notação do seletor de label padrão do Kubernetes para especificar as chaves e os valores de label nas anotações na seção de metadados do arquivo de manifesto. Para obter mais informações sobre a notação do seletor de label do Kubernetes padrão, consulte Seletores de label na documentação do Kubernetes.

A tabela fornece alguns exemplos de notação do seletor de label do Kubernetes padrão.

Quando o Kubernetes Engine provisiona um balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure para um serviço Kubernetes do tipo LoadBalancer, você pode usar um portão de preparação de pod para garantir que o tráfego só seja roteado para pods que foram adicionados com sucesso ao conjunto de backend e que estejam prontos para receber tráfego. Observe que você pode especificar portas de preparação de pods para pods em execução em nós virtuais, mas não para pods em execução em nós gerenciados. Não defina portas de preparação de pods para pods em execução em nós gerenciados.

Os portões de preparação para pods são condições adicionais para indicar que um pod está pronto para receber tráfego. Os portões de preparação para pods permitem implementar verificações de prontidão personalizadas complexas e podem ajudar a obter tempo de inatividade zero durante implantações contínuas. Para obter mais informações, consulte detalhes de preparação do pod na documentação do Kubernetes.

Ao provisionar um balanceador de carga ou balanceador de carga de rede, o conjunto de backend compreende os endereços IP das réplicas de pod de uma implantação que têm uma condição de Ready. A atualização da implantação (por exemplo, para usar uma nova imagem) aciona a substituição de réplicas de pod existentes por novas réplicas de pod. No entanto, a substituição de todas as réplicas de pod pode levar algum tempo e causar indisponibilidade de backend porque:

• As réplicas de pod existentes podem ser encerradas antes que o conjunto de backend seja atualizado com os endereços IP das novas réplicas de pod.
• O conjunto de backend pode ser atualizado com os endereços IP das novas réplicas de pod antes que as novas réplicas de pod estejam prontas para receber tráfego.

A especificação do uso de um gate de preparação de pod garante que os backends estejam sempre disponíveis para o balanceador de carga ou o balanceador de carga de rede. Os pods existentes não são encerrados até que novos pods sejam adicionados ao conjunto de backend e os novos pods estejam prontos para receber tráfego.

Para especificar que o Kubernetes Engine deve injetar um portão de preparação de pod na especificação de pod de cada pod criado em um namespace específico, adicione o label loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled ao namespace digitando:

kubectl label ns <namespace> loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

O exemplo a seguir mostra como criar um balanceador de carga com um gate de preparação de pod.

Primeiro, rotule o namespace pdr para especificar o gate de preparação de pod para o namespace, digitando:

kubectl label ns pdr loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

A saída do comando confirma que o namespace foi rotulado:

namespace/pdr labeled

Em seguida, implante o Nginx no namespace pdr digitando:

kubectl apply -f https://raw.githubusercontent.com/oracle-devrel/oci-oke-virtual-nodes/main/nginx-svc/nginx.yaml -n pdr

Liste os pods no namespace pdr digitando:

kubectl get pods -n pdr

Agora você pode demonstrar o uso do gate de preparação do pod atualizando a versão da imagem no manifesto Nginx e reaplicando o manifesto, para que os pods existentes sejam substituídos por novos pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.1
...

Reaplique o manifesto digitando:

kubectl apply -f ./nginx.yaml -n pdr

Observe os novos pods que estão sendo implantados digitando:

kubectl get pods -o wide -n pdr

Por exemplo:

NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
nginx-678976847c-8bqs7   1/1     Running   0          44m   10.0.10.153   10.0.10.253   <none>           1/1
nginx-678976847c-ttqms   1/1     Running   0          47m   10.0.10.201   10.0.10.253   <none>           1/1

Observe o status de um dos novos pods digitando:

kubectl describe pod <pod-name> -n pdr

Por exemplo:

kubectl describe pod nginx-678976847c-ttqms  -n pdr

A saída do comando confirma o status do gate de preparação podreadiness.loadbalancer.oraclecloud.com. Por exemplo:

...
Readiness Gates:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
Conditions:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
  PodScheduled                                                     True 
  Initialized                                                      True 
  Ready                                                            True 
  ContainersReady                                                  True 

Quando o Kubernetes Engine provisiona um balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure para um serviço Kubernetes do tipo LoadBalancer, você pode especificar como rotear o tráfego originado de dentro de um cluster para o endereço IP do balanceador de carga ou do balanceador de carga de rede.

Em clusters que executam o Kubernetes versão 1.30 ou posterior, o portão de recursos do Kubernetes LoadBalancerIPMode está ativado e o campo ipMode de um serviço do tipo LoadBalancer tem o valor padrão "VIP". Quando ipMode tem o valor "VIP", o tráfego enviado para o endereço IP de um serviço do tipo LoadBalancer de um pod dentro do cluster é roteado diretamente para pods de aplicativos para otimizar o desempenho, ignorando o serviço LoadBalancer. Para obter mais informações, consulte Especificando IPMode do status do balanceador de carga na documentação do Kubernetes.

No entanto, em algumas situações, você pode decidir que o roteamento de tráfego direto para pods de aplicativos não é apropriado. Por exemplo, se o tráfego originado em um cluster for roteado diretamente para pods de aplicativos, você não poderá implementar o encerramento de SSL no nível do balanceador de carga.

Para especificar como rotear o tráfego enviado para o endereço IP do balanceador de carga ou do balanceador de carga de rede de dentro do cluster, adicione a seguinte anotação na seção de metadados do arquivo de manifesto:

oci.oraclecloud.com/ingress-ip-mode: <value>

em que <value> é um dos seguintes:

• "VIP" : Todo o tráfego proveniente do cluster e enviado para o endereço IP de um serviço do tipo LoadBalancer é roteado diretamente para os pods do aplicativo para otimizar o desempenho, ignorando o serviço LoadBalancer.
• "proxy" : Todo o tráfego originado no cluster e enviado para o endereço IP de um serviço do tipo LoadBalancer é roteado para o balanceador de carga ou balanceador de carga de rede do Oracle Cloud Infrastructure que foi provisionado para o serviço LoadBalancer. O balanceador de carga ou o balanceador de carga de rede encaminha o tráfego para os pods do aplicativo.

Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/ingress-ip-mode: "proxy"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

Observe que, se você não especificar a anotação oci.oraclecloud.com/ingress-ip-mode ou posteriormente remover a anotação, a propriedade ipMode de um serviço do tipo LoadBalancer terá o valor padrão "VIP".

Observe também que, ao usar um balanceador de carga de rede privada com a anotação oci-network-load-balancer.oraclecloud.com/is-preserve-source definida como true, o balanceador de carga de rede tem uma limitação conhecida que não permite tráfego em que o nó de origem e o nó de backend de destino são o mesmo nó. Essa limitação impede a comunicação entre pods no mesmo nó por meio do balanceador de carga de rede quando as seguintes condições são atendidas:

• A anotação oci.oraclecloud.com/ingress-ip-mode está definida como proxy .
• A anotação oci-network-load-balancer.oraclecloud.com/is-preserve-source está definida como true .
• O balanceador de carga da rede é privado.

Você pode excluir nós de trabalho específicos da lista de servidores de backend no conjunto de backend de um balanceador de carga ou de rede do Oracle Cloud Infrastructure. Para obter mais informações, consulte node.kubernetes.io/exclude-from-external-load-balancers.

Você pode adicionar tags a um balanceador de carga ou balanceador de carga de rede que o Kubernetes Engine provisiona para um serviço Kubernetes do tipo LoadBalancer. O serviço Tagging permite que você agrupe recursos diferentes entre compartimentos e também permite anotar recursos com seus próprios metadados. Consulte Aplicando Tags a Balanceadores de Carga.