Configurando um caminho privado Network Load Balancer for VPC

Nuvem Privada Virtual 4.16 e mais tarde

Em ambientes de VPC totalmente privados, sem acesso público à Internet, você pode usar um balanceador de carga de rede de caminho privado para equilibrar o tráfego de rede que flui para os aplicativos em execução nos clusters de VPC. Para obter mais informações, consulte os casos de uso do serviço Private Path.

Pré-requisitos

  1. Acesse o seu Red Hat OpenShift cluster.

  2. Se você ainda não tiver um aplicativo em execução, implemente um aplicativo em seu cluster. Certifique-se de incluir um rótulo na seção de metadados de seu arquivo de configuração de implementação. Esse rótulo customizado identifica todos os pods nos quais seu app é executado para incluí-los no balanceamento de carga.

Configurando o serviço “ LoadBalancer ”

  1. Copie a LoadBalancer configuração* e salve-a em um arquivo chamado lb.yaml.

    apiVersion: v1
kind: Service
metadata:
  name: <app_name>-vpc-nlb-<VPC_zone>
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "private-path" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" # Required
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
spec:
  type: LoadBalancer
  selector:
    <selector_key>: <selector_value>
  ports:
   - name: http
     protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   - name: https
     protocol: TCP
     port: 443
     targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  externalTrafficPolicy: Local # Specify Local or Cluster.

  2. Personalize os campos para seu caso de uso. Para obter uma lista completa de anotações, consulte Anotações e especificações.

  3. Salve as mudanças.

  4. Implante o serviço Load Balancer em seu cluster.

    oc apply -f lb.yaml

Criação de um serviço de caminho privado

Siga as instruções para criar um serviço de caminho privado.

Configuração de um Virtual Private Endpoint Gateway

Agora que você configurou um serviço de balanceador de carga, deve definir um gateway de ponto de extremidade privado virtual (VPE) para acessar os aplicativos em seu cluster.

Para obter mais informações, consulte Criação de um gateway de endpoint na interface do usuário.

Conexão com seus aplicativos por meio de seu VPE

Para obter informações sobre como se conectar aos seus aplicativos por meio do VPE, consulte Acesso ao seu ponto de extremidade privado virtual após configurar o gateway de ponto de extremidade.

Anotações e especificações

Analise as anotações e especificações necessárias e opcionais do VPC NLB.

Anotações e especificações necessárias

externalTrafficPolicy
Especifique Local ou Cluster.
Configure como Local para preservar o endereço IP de origem das solicitações do cliente para seus apps. Essa configuração impede que o tráfego de entrada seja encaminhado para um nó diferente. Esta opção também configura verificações de funcionamento de HTTP.
Se Cluster estiver configurado, o DSR será implementado apenas no nó do trabalhador para o qual o VPC NLB encaminha inicialmente a solicitação recebida. Após a chegada da solicitação de entrada, ela é encaminhada para um nó de trabalho que contém o pod do aplicativo, que pode estar em uma zona diferente. A resposta do pod do app é enviada ao nó do trabalhador original, e esse nó do trabalhador usa DSR para enviar a resposta diretamente de volta ao cliente, ignorando o VPC NLB. Esta opção também configura verificações de funcionamento do TCP.

Anotações e especificações opcionais

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name
Inclua um nome exclusivo para tornar seu balanceador de carga VPC persistente. Os balanceadores de carga VPC persistentes não são excluídos quando o cluster ao qual pertencem é excluído. Para obter mais informações, consulte Balanceadores de carga VPC persistentes. Essa anotação pode ser definida somente na criação do balanceador de carga. Ele não pode ser usado em uma operação de atualização.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
Essa anotação define o protocolo de verificação de integridade no recurso de balanceador de carga VPC associado ao serviço de balanceador de carga Kubernetes. As opções disponíveis são http, https ou tcp. Normalmente, o protocolo de verificação de integridade do VPC LB é determinado pelo valor da configuração externalTrafficPolicy na especificação do serviço do balanceador de carga Kubernetes. No entanto, essa anotação substitui essa lógica. Essa anotação não altera a forma como Kubernetes e o kube-proxy, em particular, se comportam em relação às várias configurações de externalTrafficPolicy.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port
A porta do serviço “ TCP ” utilizada para as verificações de integridade. Essa anotação se aplica somente se ibm-load-balancer-cloud-provider-vpc-health-check-protocol também for especificado. Se a porta TCP especificada estiver fora do intervalo de portas dos nós Kubernetes (30.000–32.767), o grupo de segurança da VPC aplicado aos nós de trabalho do cluster deverá ser modificado para permitir o tráfego de entrada nessa porta. Se essa anotação for aplicada a um serviço de balanceador de carga do Kubernetes associado a um VPC ALB, as regras de saída do grupo de segurança atribuído ao VPC ALB deverão ser modificadas para permitir o tráfego de saída para a porta TCP especificada. Para obter mais informações, consulte Noções básicas sobre redes de VPC de cluster seguras por padrão e Criação e gerenciamento de grupos de segurança de VPC.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets
Anotação para especificar a sub-rede a ser usada para atribuir os endereços IP ao ppNLB. Esses endereços IP são usados apenas internamente. O valor pode ser um ID de sub-rede da VPC, um nome de sub-rede da VPC ou um CIDR de sub-rede da VPC. Deve-se especificar somente uma sub-rede. Todo o tráfego de entrada parece estar vindo desses endereços IP. Embora todos os endereços estejam em uma única zona, o ppNLB ainda lida com o tráfego de entrada de todas as zonas. Se essa zona específica for desativada, o tráfego de entrada das outras zonas ainda funcionará. Se você não especificar essa anotação, a sub-rede será selecionada automaticamente e será usada a sub-rede do nó de trabalho do cluster que tiver mais endereços IP livres disponíveis. Para ver sub-redes em todos os grupos de recursos, execute ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector
Anotação para especificar um seletor de rótulo de nó de trabalho. Você pode configurar nós de trabalho específicos em seu cluster para receber tráfego especificando chaves seletoras de rótulo. É possível incluir apenas um seletor de rótulo na anotação, e esse seletor deve ser especificado no formato "key=value". Se essa anotação não for especificada, todos os nós de trabalho do seu cluster serão configurados para receber tráfego do VPC NLB. Essa anotação tem precedência sobre a anotação service.kubernetes.io/ibm-load-balancer-cloud-provider-zone , e quaisquer rótulos dedicated: edge nos nós de trabalho são ignorados. Para limitar o tráfego a uma zona específica, você pode usar essa anotação para especificar os nós de trabalho nessa zona. Observe que a definição de um novo rótulo em um nó de trabalho do cluster não configura automaticamente o nó de trabalho para receber tráfego; é necessário recriar ou atualizar o VPC NLB para que o nó de trabalho recém-rotulado receba tráfego.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path
A verificação de integridade URL caminho para verificações de integridade de HTTP e HTTPs. Essa anotação se aplica somente se ibm-load-balancer-cloud-provider-vpc-health-check-protocol estiver definido como http ou https. O caminho URL deve estar no formato de um destino de solicitação de formato de origem. Se essa anotação não for especificada e a anotação ibm-load-balancer-cloud-provider-vpc-health-check-protocol for definida como http ou https, o valor padrão / será aplicado.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay
Opcional. O número de segundos de espera entre as tentativas de verificação de integridade. Por padrão, esse valor é definido como 5 e tem um mínimo de 2 e um máximo de 60. Esse valor deve ser maior que o valor ibm-load-balancer-cloud-provider-vpc-health-check-timeout, que é definido como 2 por padrão.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout
Opcional. O número de segundos para aguardar uma resposta a uma verificação de integridade. Por padrão, esse valor é definido como 2 e tem um mínimo de 1 e um máximo de 59. Esse valor deve ser menor que o ibm-load-balancer-cloud-provider-vpc-health-check-delay, que é definido como 5 por padrão.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries
O número máximo de novas tentativas de verificação de integridade para o balanceador de carga VPC. Por padrão, esse valor é definido como 2 e tem um mínimo de 1 e um máximo de 10.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota
Opcional. O número de nós de trabalho por zona para os quais o balanceador de carga roteia. O valor padrão é 8. Para um cluster com nós de trabalho em três zonas, isso faz com que o balanceador de carga encaminhe o tráfego para um total de 24 nós de trabalho. O número total de nós de trabalho em todas as zonas para as quais o balanceador de carga roteia não pode exceder 50. Se o cluster tiver menos de 50 nós de trabalho em todas as zonas, especifique 0 para rotear para todos os nós de trabalho em uma zona.
selector
A chave de rótulo (<selector_key>) e o valor (<selector_value>) usados na seção spec.template.metadata.labels do YAML de implementação do app. Esse rótulo customizado identifica todos os pods nos quais seu app é executado para incluí-los no balanceamento de carga.
port
A porta na qual o serviço atende.
targetPort
Opcional: a porta para a qual o serviço direciona o tráfego. O aplicativo em execução no pod deve estar à escuta para tráfego de entrada TCP nessa porta de destino. A porta de destino geralmente é definida estaticamente na imagem que está sendo executada no pod do aplicativo. A porta de destino configurada no pod é diferente da porta do nó para o serviço e também pode ser diferente da porta externa que está configurada no VPC LB.