Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Computação
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gerenciamento e governança
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migração
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análises
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Outros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Segurança e conformidade
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Serviços de mídia
Media Processing Center
Video On Demand
Live
SparkRTC
Armazenamento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Cloud Server Backup Service
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bancos de dados
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicações de negócios
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribuição de conteúdo e computação de borda
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluções
SAP Cloud
High Performance Computing
Serviços para desenvolvedore
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
MacroVerse aPaaS
KooPhone
KooDrive

Criação de um Serviço LoadBalancer

Atualizado em 2024-11-28 GMT+08:00

Cenário

Os Serviços LoadBalancer podem acessar cargas de trabalho da rede pública por meio do ELB, que é mais confiável do que o acesso baseado em EIP. O endereço de acesso de LoadBalancer está no formato de IP address of public network load balancer:Access port, por exemplo, 10.117.117.117:80.

Nesse modo de acesso, as solicitações são transmitidas por meio de um balanceador de carga do ELB para um nó e, em seguida, encaminhadas para o pod de destino por meio do Serviço.

Figura 1 LoadBalancer

Quando clusters do CCE Turbo e balanceadores de carga dedicados são usados, a rede de passagem é suportada para reduzir a latência do serviço e garantir perda de desempenho zero.

As solicitações de acesso externo são encaminhadas diretamente de um balanceador de carga para os pods. As solicitações de acesso interno podem ser encaminhadas para um pod por meio de um Serviço.

Figura 2 Rede de passagem

Restrições

  • Os Serviços LoadBalancer permitem que as cargas de trabalho sejam acessadas de redes públicas por meio do ELB. Este modo de acesso tem as seguintes restrições:
    • Balanceadores de carga criados automaticamente não devem ser usados por outros recursos. Caso contrário, esses balanceadores de carga não poderão ser completamente excluídos.
    • Não altere o nome do ouvinte do balanceador de carga em clusters v1.15 e anteriores. Caso contrário, o balanceador de carga não poderá ser acessado.
  • Depois que um Serviço é criado, se a configuração de afinidade for alternada do nível do cluster para o nível do nó, a tabela de rastreamento de conexão não será limpa. Recomendamos que você não modifique a configuração de afinidade de Serviço após a criação do Serviço. Para modificá-lo, crie um Serviço novamente.
  • Se a afinidade de serviço estiver definida para o nível do nó (ou seja, externalTrafficPolicy estiver definida como Local), o cluster poderá não conseguir aceder ao Serviço utilizando o endereço do ELB. Para mais detalhes, consulte Por que um Serviço falha ao ser acessado de dentro do cluster.
  • Os clusters do CCE Turbo suportam apenas afinidade de serviço em nível de cluster.
  • Balanceadores de carga ELB dedicados podem ser usados somente em clusters v1.17 e posteriores.
  • Os balanceadores de carga dedicados devem ser do tipo de rede (TCP/UDP) com suporte a redes privadas (com um IP privado). Se o Serviço precisar oferecer suporte a HTTP, as especificações dos balanceadores de carga dedicados devem usar HTTP/HTTPS (balanceamento de carga de aplicação) além do TCP/UDP (balanceamento de carga de rede).
  • Em um cluster do CCE, se a afinidade no nível do cluster estiver configurada para um Serviço LoadBalancer, as solicitações serão distribuídas para as portas de cada nó usando SNAT ao entrar no cluster. O número de portas de nó não pode exceder o número de portas de nó disponíveis no nó. Se a afinidade de serviço estiver no nível do nó (Local), não há tal restrição. Em um cluster do CCE Turbo, essa restrição se aplica aos balanceadores de carga do ELB compartilhados, mas não aos dedicados. Use balanceadores de carga do ELB dedicados em clusters do CCE Turbo.
  • Quando o modo de encaminhamento (proxy) do serviço de cluster é IPVS, o IP do nó não pode ser configurado como o IP externo do serviço. Caso contrário, o nó não está disponível.
  • 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.

Criação de um Serviço LoadBalancer

  1. Efetue logon no console do CCE e acesse o console do cluster.
  2. Escolha Networking no painel de navegação e clique em Create Service no canto superior direito.
  3. Configure parâmetros.

    • Service Name: especifique um nome do Serviço, que pode ser o mesmo que o nome da carga de trabalho.
    • Service Type: selecione LoadBalancer.
    • Namespace: namespace ao qual a carga de trabalho pertence.
    • Service Affinity: para mais detalhes, consulte externalTrafficPolicy (afinidade de serviço).
      • Cluster level: os endereços IP e as portas de acesso de todos os nós em um cluster podem acessar a carga de trabalho associada ao Serviço. O acesso ao Serviço causará perda de desempenho devido ao redirecionamento de rota e o endereço IP de origem do cliente não pode ser obtido.
      • Node level: somente o endereço IP e a porta de acesso do nó onde a carga de trabalho está localizada podem acessar a carga de trabalho associada ao Serviço. O acesso ao Serviço não causará perda de desempenho devido ao redirecionamento de rota e o endereço IP de origem do cliente pode ser obtido.
    • Selector: adicione um rótulo e clique em Confirm. Um Serviço seleciona um pod com base no rótulo adicionado. Você também pode clicar em Reference Workload Label para fazer referência ao rótulo de uma carga de trabalho existente. Na caixa de diálogo exibida, selecione uma carga de trabalho e clique em OK.
    • IPv6: esta função está desativada por padrão. Depois que essa função é ativada, o endereço IP do cluster do Serviço muda para um endereço IPv6. Para obter detalhes, consulte Criação de um cluster IPv4/IPv6 de pilha dupla no CCE. Este parâmetro está disponível apenas em clusters de v1.15 ou posterior com IPv6 habilitado (definido durante a criação do cluster).
    • 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.

      O console do CCE suporta a criação automática de balanceadores de carga. Selecione Auto create na caixa de listagem suspensa e defina 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.
      • Subnet, AZ, e Specifications (disponíveis apenas para balanceadores de carga dedicados): configure a sub-rede, a AZ e as especificações. Somente balanceadores de carga dedicados do tipo de rede (TCP/UDP) podem ser criados automaticamente.

      Você pode clicar em Edit na área Set ELB e configurar os parâmetros do balanceador de carga na caixa de diálogo Set 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.
      • Type: esta função está desativada por padrão. Você pode selecionar Source IP address. Sessão persistente baseada em endereço IP de origem significa que as solicitações de acesso do mesmo endereço IP são encaminhadas para o mesmo servidor back-end.

        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: configure a verificação de integridade do balanceador de carga.
      • Global health check: aplica-se apenas a portas que utilizam o mesmo protocolo. É aconselhável selecionar Custom health check.
      • Custom health check: aplica-se a portas que usam protocolos diferentes. Para obter detalhes sobre a definição YAML para verificação de integridade personalizada, consulte Configuração da verificação de integridade para várias portas.
      Tabela 1 Parâmetros de verificação de integridade

      Parâmetro

      Descrição

      Protocolo

      Quando o protocolo de Port é definido como TCP, o TCP e o HTTP são suportados. Quando o protocolo de Port é definido como UDP, o 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 (Node Port e Container Port 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.

    • Port
      • Protocol: protocolo utilizado pelo Serviço.
      • Service Port: porta utilizada pelo Serviço. O número da porta varia de 1 a 65535.
      • Container Port: porta na qual a carga de trabalho escuta. Por exemplo, o Nginx usa a porta 80 por padrão.
      • Health Check: se Health Check estiver definida como Custom health check, você poderá configurar a verificação de integridade para portas usando protocolos diferentes. Para mais detalhes, consulte Tabela 1.

      Quando um Serviço LoadBalancer é criado, um número de porta de nó aleatório (NodePort) é gerado automaticamente.

    • Annotation: o Serviço LoadBalancer tem algumas funções avançadas de CCE, que são implementadas por anotações. Para mais detalhes, consulte Uso de anotações para configurar o balanceamento de carga.

  4. Clique em OK.

Usar o kubectl para criar um Serviço (usando um balanceador de carga existente)

Você pode definir o Serviço ao criar uma carga de trabalho usando o kubectl. Esta seção usa uma carga de trabalho do Nginx como exemplo para descrever como adicionar um Serviço NodePort usando kubectl.

  1. Use o kubectl para se conectar ao cluster. Para mais detalhes, consulte Conexão a um cluster usando o kubectl.
  2. Crie os arquivos denominados nginx-deployment.yaml e nginx-elb-svc.yaml e edite-os.

    Os nomes dos arquivos são definidos pelo usuário. nginx-deployment.yaml e nginx-elb-svc.yaml são apenas exemplo de nomes de arquivo.

    vi nginx-deployment.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx 
            name: nginx
          imagePullSecrets:
          - name: default-secret

    vi nginx-elb-svc.yaml

    Antes de ativar a sessão persistente, certifique-se de que as seguintes condições sejam atendidas:

    • O protocolo de carga de trabalho é TCP.
    • A antiafinidade foi configurada entre os pods da carga de trabalho. Ou seja, todos os pods da carga de trabalho são implementados em nós diferentes. Para mais detalhes, consulte Política de agendamento (afinidade/antiafinidade).
    apiVersion: v1 
    kind: Service 
    metadata: 
      name: nginx
      annotations:
        kubernetes.io/elb.id: <your_elb_id>                         # ELB ID. Replace it with the actual value.
        kubernetes.io/elb.class: performance                   # Load balancer type
        kubernetes.io/elb.lb-algorithm: ROUND_ROBIN                   # Load balancer algorithm
        kubernetes.io/elb.session-affinity-mode: SOURCE_IP          # The sticky session type is source IP address.
        kubernetes.io/elb.session-affinity-option: '{"persistence_timeout": "30"}'     # Stickiness duration (min)
        kubernetes.io/elb.health-check-flag: 'on'                   # Enable the ELB health check function.
        kubernetes.io/elb.health-check-option: '{
          "protocol":"TCP",
          "delay":"5",
          "timeout":"10",
          "max_retries":"3"
        }'
    spec:
      selector: 
         app: nginx
      ports: 
      - name: service0 
        port: 80     # Port for accessing the Service, which is also the listener port on the load balancer.
        protocol: TCP 
        targetPort: 80  # Port used by a Service to access the target container. This port is closely related to the applications running in a container.
        nodePort: 31128  # Port number of the node. If this parameter is not specified, a random port number ranging from 30000 to 32767 is generated.
      type: LoadBalancer

    O exemplo anterior usa anotações para implementar algumas funções avançadas de balanceamento de carga, como sessão persistente e verificação de integridade. Para mais detalhes, consulte Tabela 2.

    Para obter mais anotações e exemplos relacionados a funções avançadas, consulte Uso de anotações para configurar o balanceamento de carga.

    Tabela 2 Parâmetros de anotações

    Parâmetro

    Obrigatório

    Tipo

    Descrição

    kubernetes.io/elb.id

    Sim

    String

    ID de um balanceador de carga aprimorado.

    Obrigatório quando um balanceador de carga existente deve ser associado.

    Como obter:

    No console de gerenciamento, clique em Service List e escolha Networking > Elastic Load Balance. Clique no nome do balanceador de carga de destino. Na página de guia Summary, localize e copie o ID.

    NOTA:

    O sistema se conecta preferencialmente ao balanceador de carga com base no campo kubernetes.io/elb.id. Se este campo não for especificado, o campo spec.loadBalancerIP é usado (opcional e disponível apenas em 1.23 e versões anteriores).

    Não use o campo spec.loadBalancerIP para se conectar ao balanceador de carga. Este campo será descartado pelo Kubernetes. Para obter detalhes, consulte Deprecação.

    kubernetes.io/elb.class

    Sim

    String

    Selecione um tipo adequado de balanceador de carga.

    O valor pode ser:

    NOTA:

    Se um Serviço LoadBalancer acessar um balanceador de carga dedicado existente, o balanceador de carga dedicado deve suportar redes TCP/UDP.

    kubernetes.io/elb.lb-algorithm

    Não

    String

    Especifica o algoritmo de balanceamento de carga do grupo de servidores back-end. O valor padrão é ROUND_ROBIN.

    Opções:

    • ROUND_ROBIN: algoritmo round robin ponderado
    • LEAST_CONNECTIONS: algoritmo de menor conexão ponderada
    • SOURCE_IP: algoritmo de hash do IP de origem
    NOTA:

    Se esse parâmetro for definido como SOURCE_IP, a configuração de peso (campo weight) dos servidores back-end vinculados ao grupo de servidores back-end será inválida e a sessão persistente não poderá ser ativada.

    kubernetes.io/elb.session-affinity-mode

    Não

    String

    A sessão persistente baseada em endereço IP de origem é suportada. Ou seja, as solicitações do mesmo endereço IP sejam encaminhadas para o mesmo servidor back-end.

    • Disabling sticky session: não configure este parâmetro.
    • Enabling sticky session: defina esse parâmetro como SOURCE_IP, indicando que a sessão persistente é baseada no endereço IP de origem.
    NOTA:

    Quando kubernetes.io/elb.lb-algorithm é definido como SOURCE_IP (source IP hash), sessão persistente não pode ser ativada.

    kubernetes.io/elb.session-affinity-option

    Não

    Tabela 3 object

    Tempo limite de sessão persistente expira.

    kubernetes.io/elb.health-check-flag

    Não

    String

    Se deve ativar a verificação de integridade do ELB.

    • Enabling health check: deixe este parâmetro em branco ou defina-o como on.
    • Disabling health check: defina este parâmetro como off.

    Se esse parâmetro estiver ativado, o campo kubernetes.io/elb.health-check-option também deve ser especificado ao mesmo tempo.

    kubernetes.io/elb.health-check-option

    Não

    Tabela 4 object

    Itens de configuração de verificação de integridade do ELB.

    Tabela 3 Estrutura de dados de elb.session-affinity-option

    Parâmetro

    Obrigatório

    Tipo

    Descrição

    persistence_timeout

    Sim

    String

    Tempo limite de sessão persistente, em minutos. Esse parâmetro é válido somente quando elb.session-affinity-mode é definido como SOURCE_IP.

    Intervalo de valores: 1 a 60. Valor padrão: 60

    Tabela 4 Estrutura de dados de elb.health-check-option

    Parâmetro

    Obrigatório

    Tipo

    Descrição

    delay

    Não

    String

    Tempo de espera inicial (em segundos) para iniciar a verificação de integridade.

    Intervalo de valores: 1 a 50. Valor padrão: 5

    timeout

    Não

    String

    Tempo limite de verificação de integridade, em segundos.

    Intervalo de valores: 1 a 50. Valor padrão: 10

    max_retries

    Não

    String

    Número máximo de tentativas de verificação de integridade.

    Intervalo de valores: 1 a 10. Valor padrão: 3

    protocol

    Não

    String

    Protocolo de verificação de integridade.

    Opções de valor: TCP ou HTTP

    path

    Não

    String

    URL de verificação de integridade. Este parâmetro precisa ser configurado quando o protocolo é HTTP.

    Valor padrão: /

    O valor pode conter de 1 a 10.000 caracteres.

  3. Crie uma carga de trabalho.

    kubectl create -f nginx-deployment.yaml

    Se forem exibidas informações semelhantes às seguintes, a carga de trabalho foi criada.

    deployment/nginx created

    kubectl get pod

    Se informações semelhantes às seguintes forem exibidas, a carga de trabalho está em execução.

    NAME                     READY     STATUS             RESTARTS   AGE
    nginx-2601814895-c1xhw   1/1       Running            0          6s

  4. Crie um Serviço.

    kubectl create -f nginx-elb-svc.yaml

    Se forem exibidas informações semelhantes às seguintes, o Serviço foi criado.

    service/nginx created

    kubectl get svc

    Se informações semelhantes às seguintes forem exibidas, o tipo de acesso foi definido e a carga de trabalho está acessível.

    NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
    kubernetes   ClusterIP      10.247.0.1       <none>        443/TCP        3d
    nginx        LoadBalancer   10.247.130.196   10.78.42.242   80:31540/TCP   51s

  5. Digite o URL na caixa de endereço do navegador, por exemplo, 10.78.42.242:80. 10.78.42.242 indica o endereço IP do balanceador de carga e 80 indica a porta de acesso exibida no console do CCE.

    O Nginx é acessível.

    Figura 3 Acessar o Nginx por meio do Serviço LoadBalancer

Usar o kubectl para criar um Serviço (criação automática de um balanceador de carga)

Você pode definir o Serviço ao criar uma carga de trabalho usando o kubectl. Esta seção usa uma carga de trabalho do Nginx como exemplo para descrever como adicionar um Serviço NodePort usando kubectl.

  1. Use o kubectl para se conectar ao cluster. Para mais detalhes, consulte Conexão a um cluster usando o kubectl.
  2. Crie os arquivos denominados nginx-deployment.yaml e nginx-elb-svc.yaml e edite-os.

    Os nomes dos arquivos são definidos pelo usuário. nginx-deployment.yaml e nginx-elb-svc.yaml são apenas exemplo de nomes de arquivo.

    vi nginx-deployment.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx 
            name: nginx
          imagePullSecrets:
          - name: default-secret

    vi nginx-elb-svc.yaml

    Antes de ativar a sessão persistente, certifique-se de que as seguintes condições sejam atendidas:

    • O protocolo de carga de trabalho é TCP.
    • A antiafinidade foi configurada entre os pods da carga de trabalho. Ou seja, todos os pods da carga de trabalho são implementados em nós diferentes. Para mais detalhes, consulte Política de agendamento (afinidade/antiafinidade).
    Exemplo de um Serviço usando um balanceador de carga compartilhado de rede pública:
    apiVersion: v1 
    kind: Service 
    metadata: 
      annotations:   
        kubernetes.io/elb.class: union
        kubernetes.io/elb.autocreate: '{
          "type": "public",
          "bandwidth_name": "cce-bandwidth-1551163379627",
          "bandwidth_chargemode": "bandwidth",
          "bandwidth_size": 5,
          "bandwidth_sharetype": "PER",
          "eip_type": "5_bgp"
        }'
        kubernetes.io/elb.enterpriseID: 0       # ID of the enterprise project to which the load balancer belongs
        kubernetes.io/elb.lb-algorithm: ROUND_ROBIN                   # Load balancer algorithm
        kubernetes.io/elb.session-affinity-mode: SOURCE_IP          # The sticky session type is source IP address.
        kubernetes.io/elb.session-affinity-option: '{"persistence_timeout": "30"}'     # Stickiness duration (min)
        kubernetes.io/elb.health-check-flag: 'on'                   # Enable the ELB health check function.
        kubernetes.io/elb.health-check-option: '{
          "protocol":"TCP",
          "delay":"5",
          "timeout":"10",
          "max_retries":"3"
        }'
      labels: 
        app: nginx 
      name: nginx 
    spec: 
      ports: 
      - name: service0 
        port: 80
        protocol: TCP 
        targetPort: 80
      selector: 
        app: nginx 
      type: LoadBalancer
    Exemplo de Serviço usando um balanceador de carga dedicado de rede pública (somente para clusters de v1.17 e posterior):
    apiVersion: v1
    kind: Service
    metadata:
      name: nginx
      labels:
        app: nginx
      namespace: default
      annotations:
        kubernetes.io/elb.class: performance
        kubernetes.io/elb.autocreate: '{
          "type": "public",
          "bandwidth_name": "cce-bandwidth-1626694478577",
          "bandwidth_chargemode": "bandwidth",
          "bandwidth_size": 5,
          "bandwidth_sharetype": "PER",
          "eip_type": "5_bgp",
          "available_zone": [
             ""
          ],
          "l4_flavor_name": "L4_flavor.elb.s1.small"
        }'
        kubernetes.io/elb.enterpriseID: 0       # ID of the enterprise project to which the load balancer belongs
        kubernetes.io/elb.lb-algorithm: ROUND_ROBIN                   # Load balancer algorithm
        kubernetes.io/elb.session-affinity-mode: SOURCE_IP          # The sticky session type is source IP address.
        kubernetes.io/elb.session-affinity-option: '{"persistence_timeout": "30"}'     # Stickiness duration (min)
        kubernetes.io/elb.health-check-flag: 'on'                   # Enable the ELB health check function.
        kubernetes.io/elb.health-check-option: '{
          "protocol":"TCP",
          "delay":"5",
          "timeout":"10",
          "max_retries":"3"
        }'
    spec:
      selector:
        app: nginx
      ports:
      - name: cce-service-0
        targetPort: 80
        nodePort: 0
        port: 80
        protocol: TCP
      type: LoadBalancer

    O exemplo anterior usa anotações para implementar algumas funções avançadas de balanceamento de carga, como sessão persistente e verificação de integridade. Para mais detalhes, consulte Tabela 5.

    Para obter mais anotações e exemplos relacionados a funções avançadas, consulte Uso de anotações para configurar o balanceamento de carga.

    Tabela 5 Parâmetros de anotações

    Parâmetro

    Obrigatório

    Tipo

    Descrição

    kubernetes.io/elb.class

    Sim

    String

    Selecione um tipo adequado de balanceador de carga.

    O valor pode ser:

    kubernetes.io/elb.autocreate

    Sim

    elb.autocreate object

    Se criar automaticamente um balanceador de carga associado ao Serviço.

    Exemplo

    • Se um balanceador de carga de rede pública for criado automaticamente, defina esse parâmetro com o seguinte valor:

      {"type":"public","bandwidth_name":"cce-bandwidth-1551163379627","bandwidth_chargemode":"bandwidth","bandwidth_size":5,"bandwidth_sharetype":"PER","eip_type":"5_bgp","name":"james"}

    • Se um balanceador de carga de rede privada for criado automaticamente, defina esse parâmetro com o seguinte valor:

      {"type":"inner","name":"A-location-d-test"}

    kubernetes.io/elb.subnet-id

    Nenhuma

    String

    ID da sub-rede onde o cluster está localizado. O valor pode conter de 1 a 100 caracteres.

    • Obrigatório quando um cluster v1.11.7-r0 ou anterior deve ser criado automaticamente.
    • Opcional para clusters posteriores à v1.11.7-r0.

    Para obter detalhes sobre como obter o valor, consulteQual é a diferença entre a API de sub-rede da VPC e a API de sub-rede do OpenStack Neutron.

    kubernetes.io/elb.enterpriseID

    Não

    String

    Clusters de v1.15 e versões posteriores suportam este campo. Nos clusters anteriores à v1.15, os balanceadores de carga são criados no projeto padrão por padrão.

    Esse parâmetro indica o ID do projeto empresarial no qual o balanceador de carga do ELB será criado.

    Se esse parâmetro não for especificado ou for definido como 0, os recursos serão vinculados ao projeto corporativo padrão.

    Como obter:

    Faça logon no console de gerenciamento e escolha Enterprise > Project Management na barra de menu superior. Na lista exibida, clique no nome do projeto empresarial de destino e copie o ID na página de detalhes do projeto empresarial.

    kubernetes.io/elb.lb-algorithm

    Não

    String

    Especifica o algoritmo de balanceamento de carga do grupo de servidores back-end. O valor padrão é ROUND_ROBIN.

    Opções:

    • ROUND_ROBIN: algoritmo round robin ponderado
    • LEAST_CONNECTIONS: algoritmo de menor conexão ponderada
    • SOURCE_IP: algoritmo de hash do IP de origem
    NOTA:

    Se esse parâmetro for definido como SOURCE_IP, a configuração de peso (campo weight) dos servidores back-end vinculados ao grupo de servidores back-end será inválida e a sessão persistente não poderá ser ativada.

    kubernetes.io/elb.session-affinity-mode

    Não

    String

    A sessão persistente baseada em endereço IP de origem é suportada. Ou seja, as solicitações do mesmo endereço IP sejam encaminhadas para o mesmo servidor back-end.

    • Disabling sticky session: não configure este parâmetro.
    • Enabling sticky session: defina esse parâmetro como SOURCE_IP, indicando que a sessão persistente é baseada no endereço IP de origem.
    NOTA:

    Quando kubernetes.io/elb.lb-algorithm é definido como SOURCE_IP (source IP hash), sessão persistente não pode ser ativada.

    kubernetes.io/elb.session-affinity-option

    Não

    Tabela 3 object

    Tempo limite de sessão persistente expira.

    kubernetes.io/elb.health-check-flag

    Não

    String

    Se deve ativar a verificação de integridade do ELB.

    • Enabling health check: deixe este parâmetro em branco ou defina-o como on.
    • Disabling health check: defina este parâmetro como off.

    Se esse parâmetro estiver ativado, o campo kubernetes.io/elb.health-check-option também deve ser especificado ao mesmo tempo.

    kubernetes.io/elb.health-check-option

    Não

    Tabela 4 object

    Itens de configuração de verificação de integridade do ELB.

    Tabela 6 Estrutura de dados de elb.autocreate

    Parâmetro

    Obrigatório

    Tipo

    Descrição

    name

    Não

    String

    Nome do balanceador de carga criado automaticamente.

    O valor pode conter de 1 a 64 caracteres. Somente letras, dígitos, sublinhados (_), hifens (-) e pontos (.) são permitidos.

    Padrão: cce-lb+service.UID

    type

    Não

    String

    Tipo de rede do balanceador de carga.

    • public: balanceador de carga de rede pública
    • inner: balanceador de carga de rede privada

    Padrão: inner

    bandwidth_name

    Sim para balanceadores de carga de rede pública

    String

    Nome da largura de banda. O valor padrão é cce-bandwidth-******.

    O valor pode conter de 1 a 64 caracteres. Somente letras, dígitos, sublinhados (_), hifens (-) e pontos (.) são permitidos.

    bandwidth_chargemode

    Não

    String

    Modo de cobrança de largura de banda.

    • bandwidth: cobrado pela largura de banda
    • traffic: cobrado pelo tráfego

    Padrão: bandwidth

    bandwidth_size

    Sim para balanceadores de carga de rede pública

    Integer

    Tamanho da largura de banda. O valor padrão é de 1 a 2000 Mbit/s. Configure este parâmetro com base na faixa de largura de banda permitida em sua região.

    O incremento mínimo para ajuste de largura de banda varia dependendo do intervalo de largura de banda.
    • O incremento mínimo é de 1 Mbit/s se a largura de banda permitida não exceder 300 Mbit/s.
    • O incremento mínimo é de 50 Mbit/s se a largura de banda permitida varia de 300 Mbit/s a 1000 Mbit/s.
    • O incremento mínimo é de 500 Mbit/s se a largura de banda permitida exceder 1000 Mbit/s.

    bandwidth_sharetype

    Sim para balanceadores de carga de rede pública

    String

    Modo de compartilhamento de largura de banda.

    • PER: largura de banda dedicada

    eip_type

    Sim para balanceadores de carga de rede pública

    String

    Tipo de EIP.

    • 5_telcom: China Telecom
    • 5_union: China Unicom
    • 5_bgp: BGP dinâmico
    • 5_sbgp: BGP estático

    vip_subnet_cidr_id

    Não

    String

    Sub-rede onde o balanceador de carga está localizado. Este campo é suportado por clusters de v1.21 ou posterior.

    Se esse parâmetro não for especificado, o balanceador de carga do ELB e o cluster estarão na mesma sub-rede.

    available_zone

    Sim

    Array of strings

    AZ onde o balanceador de carga está localizado.

    Você pode obter todas as AZs suportadas consultando a lista de AZ.

    Esse parâmetro está disponível apenas para balanceadores de carga compartilhados.

    l4_flavor_name

    Sim

    String

    Nome do flavor do balanceador de carga da camada 4.

    Você pode obter todos os tipos suportados consultando a lista de flavors.

    Esse parâmetro está disponível apenas para balanceadores de carga compartilhados.

    l7_flavor_name

    Não

    String

    Nome do flavor do balanceador de carga da camada-7.

    Você pode obter todos os tipos suportados consultando a lista de flavors.

    Esse parâmetro está disponível apenas para balanceadores de carga compartilhados. O valor deste parâmetro deve ser o mesmo de l4_flavor_name, ou seja, ambos são especificações elásticas ou especificações fixas.

    elb_virsubnet_ids

    Não

    Array of strings

    Sub-rede onde o servidor back-end do balanceador de carga está localizado. Se esse parâmetro for deixado em branco, a sub-rede do cluster padrão será usada. Os balanceadores de carga ocupam um número diferente de endereços IP de sub-rede com base em suas especificações. Não use os blocos CIDR de sub-rede de outros recursos (como clusters e nós) como o bloco CIDR do balanceador de carga.

    Esse parâmetro está disponível apenas para balanceadores de carga compartilhados.

    Exemplo:

    "elb_virsubnet_ids": [
       "14567f27-8ae4-42b8-ae47-9f847a4690dd"
     ]

  3. Crie uma carga de trabalho.

    kubectl create -f nginx-deployment.yaml

    Se forem exibidas informações semelhantes às seguintes, a carga de trabalho está sendo criada.

    deployment/nginx created

    kubectl get pod

    Se informações semelhantes às seguintes forem exibidas, a carga de trabalho está em execução.

    NAME                     READY     STATUS             RESTARTS   AGE
    nginx-2601814895-c1xhw   1/1       Running            0          6s

  4. Crie um Serviço.

    kubectl create -f nginx-elb-svc.yaml

    Se forem exibidas informações semelhantes às seguintes, o Serviço foi criado.

    service/nginx created

    kubectl get svc

    Se informações semelhantes às seguintes forem exibidas, o tipo de acesso foi definido e a carga de trabalho está acessível.

    NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
    kubernetes   ClusterIP      10.247.0.1       <none>        443/TCP        3d
    nginx        LoadBalancer   10.247.130.196   10.78.42.242   80:31540/TCP   51s

  5. Digite o URL na caixa de endereço do navegador, por exemplo, 10.78.42.242:80. 10.78.42.242 indica o endereço IP do balanceador de carga e 80 indica a porta de acesso exibida no console do CCE.

    O Nginx é acessível.

    Figura 4 Acessar o Nginx por meio do Serviço LoadBalancer

Usamos cookies para aprimorar nosso site e sua experiência. Ao continuar a navegar em nosso site, você aceita nossa política de cookies. Saiba mais

Feedback

Feedback

Feedback

0/500

Conteúdo selecionado

Envie o conteúdo selecionado com o feedback