IBM Cloud Docs
Configurando as sub-redes de VPC

Configurando as sub-redes de VPC

Nuvem privada virtual

Mude o conjunto de endereços IP públicos ou privados móveis disponíveis incluindo sub-redes no seu cluster de VPC do IBM Cloud® Kubernetes Service.

O conteúdo nesta página é específico para clusters de VPC. Para obter informações sobre clusters clássicos, veja Configurando sub-redes e endereços IP para clusters clássicos.

Visão geral da rede VPC no IBM Cloud Kubernetes Service

Entenda os conceitos básicos da rede VPC em clusters do IBM Cloud Kubernetes Service.

Subnets

Antes de criar um cluster VPC pela primeira vez, deve-se criar uma sub-rede VPC em cada zona em que deseja implementar nós do trabalhador. Uma sub-rede de VPC é um intervalo de endereço IP privado especificado (bloco CIDR) e que configura um grupo de nós do trabalhador e pods como se eles fossem anexados ao mesmo fio físico.

Ao criar um cluster, é possível especificar apenas uma sub-rede da VPC existente para cada zona. Cada nó do trabalhador incluído em um cluster é implementado com um endereço IP privado da sub-rede do VPC nessa zona. Após o provisionamento do nó do trabalhador, o endereço IP dele persiste após uma operação reboot, mas é mudado após operações replace e update.

Não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Quantos endereços IP são necessários para minha sub-rede VPC?

Ao criar a sub-rede VPC, certifique-se de criar uma sub-rede com endereços IP suficientes para o cluster, como 256. O número de endereços IP contidos em uma sub-rede de VPC não pode ser alterado posteriormente.

Tenha em mente as reservas de endereço IP a seguir.

  • 5 endereços IP são reservados por VPC de cada sub-rede por padrão.
  • é necessário 1 endereço IP de uma sub-rede em cada zona em que seu cluster tem nós de trabalho para o gateway de pontos de extremidade privados virtuais(VPE).
  • Um endereço IP é necessário por nó do trabalhador em seu cluster.
  • Um endereço IP é necessário sempre que você atualiza ou substitui um nó do trabalhador. Esses endereços IP são eventualmente recuperados e disponibilizados para reutilização.
  • Dois endereços IP são usados sempre que você cria um balanceador de carga público ou privado. Se você tiver um cluster multizona, esses dois endereços IP serão distribuídos entre as zonas, portanto, a sub-rede poderá não ter um endereço IP reservado.
  • Outros recursos de rede que você configurou para o cluster, como um Ajuste automático de escala de VPNaaS ou LBaaS, podem requerer endereços IP adicionais ou ter outras limitações de serviço. Por exemplo, o ajuste automático de escala de LBaaS pode escalar até 16 endereços IP por balanceador de carga.

Quais intervalos de IP posso usar para minhas sub-redes de VPC?

O intervalo de endereço IP padrão para sub-redes VPC 10.0.0.0 a 10.255.255.255. Para obter uma lista de intervalos de endereços IP por zona da VPC, consulte Prefixos de endereço padrão da VPC.

Se for necessário criar o seu cluster usando sub-redes com intervalo customizado, consulte a orientação para prefixos de endereço customizado. No entanto, se usar sub-redes customizadas para nós do trabalhador, você deverá assegurar que o intervalo de IPs para as sub-redes do nó do trabalhador não sobreponha a sub-rede do pod do cluster. A sub-rede do pod varia, dependendo das opções de sub-rede durante a criação do cluster e do tipo de infraestrutura do cluster:

  • Se você especificou sua própria sub-rede de pod na opção --pod-subnet durante a criação do cluster, seus pods receberão endereços IP desse intervalo.
  • Se você não especificou uma sub-rede de pod personalizada durante a criação de cluster, seu cluster usa a sub-rede padrão de pod. No primeiro cluster que você cria em uma VPC, a sub-rede de pod padrão é 172.17.0.0/18. No segundo cluster que você cria naquela VPC, a sub-rede de pod padrão é 172.17.64.0/18. Em cada cluster subsequente, o intervalo de sub-rede do pod é a próxima sub-rede disponível não sobreposta /18.

Como faço para criar sub-redes para acesso à infraestrutura clássica?

Se você ativar o acesso clássico ao criar sua VPC, os prefixos de endereço padrão de acesso clássico determinarão automaticamente os intervalos de IP de todas as sub-redes criadas. No entanto, os intervalos de IP padrão para sub-redes VPC de acesso clássico entram em conflito com as sub-redes do plano de controle do IBM Cloud Kubernetes Service. Em vez disso, você deve criar a VPC sem os prefixos de endereço padrão automáticos e, em seguida, criar seus próprios prefixos de endereço e sub-redes dentro desses intervalos para seu cluster.

Posso especificar sub-redes para pods e serviços em meu cluster?

Se você planeja conectar seu cluster a redes no local por meio do IBM Cloud Direct Link ou de um serviço de VPN, é possível evitar conflitos de sub-rede especificando um CIDR de sub-rede customizado que forneça os endereços IP privados para os seus pods e um CIDR de sub-rede customizado para fornecer os endereços IP privados para serviços.

Para especificar pods personalizados e sub-redes de serviço durante a criação do cluster, use as opções --pod-subnet e --service-subnet no comando ibmcloud ks cluster create da CLI.

Para ver as sub-redes de pod e de serviço que o seu cluster usa, procure os campos Pod Subnet e Service Subnet na saída de ibmcloud ks cluster get.

Pods

Intervalo padrão

No primeiro cluster que você cria em uma VPC, a sub-rede de pod padrão é 172.17.0.0/18. No segundo cluster que você cria naquela VPC, a sub-rede de pod padrão é 172.17.64.0/18. Em cada cluster subsequente, o intervalo de sub-rede do pod é a próxima sub-rede disponível não sobreposta /18.

Requisitos de tamanho

Ao especificar uma sub-rede customizada, considere o tamanho do cluster que você planeja criar e o número de nós do trabalhador que pode ser incluído no futuro. A sub-rede deve ter um CIDR de pelo menos /23, que fornece IPs de pod suficientes para um máximo de quatro nós do trabalhador em um cluster. Para clusters maiores, use /22 para ter endereços IP de pod suficientes para oito nós do trabalhador, /21 para ter endereços IP de pod suficientes para 16 nós do trabalhador e assim por diante.

Para clusters VPC, é possível especificar o tamanho da sub-rede, incluindo-o na opção --pod-subnet Por exemplo: --pod-subnet 0.0.0.0/X em que X é o tamanho de sub-rede do pod necessário. Em seguida, a sub-rede do pod é selecionada automaticamente. Ao alocar a sub-rede do pod automaticamente, a alocação será iniciada em 172.17.0.0, a maior sub-rede será limitada a 13 e o menor tamanho de sub-rede será limitado a 23.

Há um limite global para nós de trabalho. Não é possível exceder 500 nós de trabalho em todos os clusters de uma região.

Requisitos de intervalo

As sub-redes de pod e de serviço não podem se sobrepor e a sub-rede de pod não pode sobrepor as sub-redes de VPC para os nós do trabalhador. A sub-rede escolhida precisa estar dentro de um dos intervalos a seguir.

  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.255.255

  • 198.18.0.0 - 198.19.255.255

Serviços

Intervalo padrão
Todos os serviços implementados no cluster recebem a designação de um endereço IP privado no intervalo 172.21.0.0/16 por padrão.
Requisitos de tamanho
Ao especificar uma sub-rede customizada, a sub-rede deve ser especificada no formato CIDR com um tamanho de pelo menos /24, que permite um máximo de 255 serviços no cluster ou mais.
Requisitos de intervalo
As sub-redes de pod e serviço não podem se sobrepor. A sub-rede escolhida precisa estar dentro de um dos intervalos a seguir.

  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.255.255

  • 198.18.0.0 - 198.19.255.255

Gateways públicos

Um gateway público ativa uma sub-rede e todos os nós do trabalhador que estão conectados à sub-rede para estabelecer conexões de saída para a Internet. Se os nós do trabalhador precisarem acessar um terminal público fora do cluster, será possível ativar um gateway público nas sub-redes VPC nas quais os nós do trabalhador são implementados.

Se um serviço da IBM Cloud não suportar terminais em serviço de nuvem privada, seus nós do trabalhador deverão ser conectados a uma sub-rede que tem um gateway público conectado a ela. Os pods nesses nós do trabalhador podem se comunicar de forma segura com os serviços sobre a rede pública por meio do gateway público da sub-rede. Observe que um gateway público não é necessário em suas sub-redes para permitir o tráfego de rede de entrada da Internet para os ALBs ou os serviços LoadBalancer.

Dentro de uma VPC, é possível criar apenas um gateway público por zona, mas esse gateway público pode ser conectado a várias sub-redes dentro da zona. Para obter mais informações sobre gateways públicos, consulte a documentação Rede para VPC.

Terminais privados virtuais (VPEs)

Consulte Entendendo a rede VPC de cluster segura por padrão para obter informações sobre VPEs.

Segmentação de rede

A segmentação de rede descreve a abordagem para dividir uma rede em diversas sub-redes. Os apps que são executados em uma sub-rede não podem ver ou acessar apps em outra sub-rede. Para obter mais informações sobre as opções de segmentação de rede para sub-redes de VPC, consulte este tópico de segurança do cluster.

As sub-redes fornecem um canal de conectividade entre os nós do trabalhador no cluster. Além disso, qualquer sistema conectado a qualquer uma das sub-redes privadas no mesmo VPC pode se comunicar com os trabalhadores. Por exemplo, todas as sub-redes em uma VPC podem se comunicar por meio do roteamento privado de camada 3 com um roteador integrado da VPC.

Se tiver diversos clusters que devam se comunicar uns com os outros, será possível criá-los na mesma VPC. No entanto, se os clusters não precisarem se comunicar, será possível conseguir uma melhor segmentação de rede criando os clusters em VPCs separadas. Também é possível criar listas de controle de acesso (ACLs) para suas sub-redes do VPC mediarem o tráfego na rede privada. As ACLs consistem em regras de entrada e saída que definem qual entrada e saída é permitida para cada sub-rede do VPC.

Limitações de rede de VPC

Ao criar sub-redes do VPC para seus clusters, tenha em mente os recursos e as limitações a seguir.

  • O tamanho padrão do CIDR de cada sub-rede do VPC é /24 e pode suportar até 253 nós do trabalhador. Se planejar implementar mais de 250 nós do trabalhador por zona em um cluster, considere criar uma sub-rede de um tamanho maior.
  • Depois de criar uma sub-rede VPC, você não pode redimensioná-lo ou alterar seu intervalo IP.
  • Diversos clusters na mesma VPC podem compartilhar sub-redes VPC. No entanto, as sub-redes de pod e de serviço customizadas não podem ser compartilhadas entre vários clusters.
  • As sub-redes VPC estão vinculadas a uma região de campus único com várias zonas e não podem abranger várias zonas ou regiões.
  • Depois de criar uma sub-rede, você não pode movê-la para uma zona, região ou VPC diferente.
  • No caso de nós do trabalhador conectados a uma sub-rede existente em uma zona, não é possível mudar a sub-rede para essa zona no cluster.
  • Os intervalos 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16 são proibidos.
  • Dentro de uma VPC, é possível criar apenas um gateway público por zona, mas esse gateway público pode ser conectado a várias sub-redes dentro da zona.
  • Os prefixos de endereço padrão de acesso clássico entram em conflito com as sub-redes para o plano de controle do IBM Cloud Kubernetes Service. Você deve criar a VPC sem os prefixos de endereço padrão automáticos e, em seguida, criar seus próprios prefixos de endereço e sub-redes dentro desses intervalos para seu cluster.

Criando uma sub-rede de VPC e anexando um gateway público

Crie uma sub-rede de VPC para seu cluster e, opcionalmente, anexe um gateway público à sub-rede.

Criando uma sub-rede de VPC no console

Use o console do IBM Cloud para criar uma sub-rede de VPC para seu cluster e, opcionalmente, anexe um gateway público à sub-rede.

  1. No painel de sub-rede da VPC, clique em Criar.
  2. Insira um nome para sua sub-rede e selecione o nome do VPC criado.
  3. Selecione o local e a zona nos quais deseja criar a sub-rede.
  4. Especifique o número de endereços IP a serem criados.
    • As sub-redes VPC fornecem endereços IP para os seus nós do trabalhador e serviços de balanceador de carga no cluster, portanto, crie uma sub-rede VPC com endereços IP suficientes, como 256. Não é possível mudar o número de IPs que uma sub-rede VPC terá depois.
    • Se você inserir um intervalo de IP específico, não use os intervalos reservados a seguir: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16.
  5. Escolha se deseja conectar um gateway de rede pública à sua sub-rede. É necessário um gateway de rede pública quando você deseja que o seu cluster acesse terminais públicos, como uma URL pública de outro app ou um serviço da IBM Cloud que suporta somente terminais em serviço de nuvem pública.
  6. Clique em Criar sub-rede.
  7. Use a sub-rede para criar um cluster, criar um novo conjunto de trabalhadores ou incluir a sub-rede em um conjunto de trabalhadores existente.> Não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Criando uma sub-rede de VPC na CLI

Use a CLI do IBM Cloud para criar uma sub-rede de VPC para seu cluster e, opcionalmente, anexe um gateway público à sub-rede.

Antes de Iniciar

  1. Em sua linha de comandos, efetue login em sua conta da IBM Cloud e vise a região e o grupo de recursos da IBM Cloud nos quais você deseja criar seu cluster de VPC. Para ver as regiões suportadas, consulte Criando uma VPC em uma região diferente. O grupo de recursos do cluster pode diferir do grupo de recursos da VPC. Insira suas credenciais do IBM Cloud quando solicitadas. Se você tiver um ID federado, use a opção --sso para fazer login.
    ibmcloud login -r <region> [-g <resource_group>] [--sso]
  2. Crie uma VPC na mesma região na qual deseja criar o cluster.

Para criar uma sub-rede VPC, siga estas etapas.

  1. Obtenha o ID da VPC na qual você deseja criar a sub-rede.

    ibmcloud ks vpcs

  2. Crie a sub-rede. Para obter mais informações sobre as opções neste comando, consulte a Referência da CLI.

    ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address>
    • As sub-redes VPC fornecem endereços IP para os seus nós do trabalhador e serviços de balanceador de carga no cluster, portanto, crie uma sub-rede VPC com endereços IP suficientes, como 256. Não é possível mudar o número de IPs que uma sub-rede VPC terá depois.
    • Não use os seguintes intervalos reservados: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, e 172.20.0.0/16.

  3. Verifique se você tem um gateway público nas zonas nas quais deseja criar um cluster. Dentro de uma VPC, é possível criar apenas um gateway público por zona, mas esse gateway público pode ser conectado a várias sub-redes dentro da zona.

    ibmcloud is public-gateways

    Exemplo de saída

    ID                                     Name                                       VPC                          Zone         Floating IP                  Created                     Status      Resource group
26426426-6065-4716-a90b-ac7ed7917c63   test-pgw                                   testvpc(36c8f522-.)          us-south-1   169.xx.xxx.xxx(26466378-.)   2019-09-20T16:27:32-05:00   available   -
2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   team3(ff537d43-.)            us-south-2   169.xx.xxx.xxx(2ba9a280-.)   2019-08-02T10:30:29-05:00   available   -
    • Se você já tiver um gateway público em cada zona, observe os IDs dos gateways públicos.
    • Se você não tiver um gateway público em cada zona, crie um. Considere nomear o gateway público no formato <cluster>-<zone>-gateway. Na saída, anote o ID do gateway público.
    ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>

    Exemplo de saída

    ID               26466378-6065-4716-a90b-ac7ed7917c63
Name             mycluster-us-south-1-gateway
Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
Status           pending
Created          2019-09-20T16:27:32-05:00
Zone             us-south-1
VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
Resource group   -

  4. Usando os IDs do gateway público e da sub-rede, conecte o gateway público à sub-rede.

    ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>

    Exemplo de saída

    ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
Name                mysubnet1
IPv4 CIDR           10.240.xx.xx/24
Address available   250
Address total       256
ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
Created             2019-08-21T09:43:11-05:00
Status              available
Zone                us-south-1
VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)

  5. Use a sub-rede para criar um cluster, criar um novo conjunto de trabalhadores ou incluir a sub-rede em um conjunto de trabalhadores existente. Não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Criando sub-redes VPC para acesso clássico

Se você ativar o acesso clássico ao criar sua VPC, os prefixos de endereço padrão de acesso clássico determinarão automaticamente os intervalos de IP de todas as sub-redes criadas. No entanto, os intervalos de IP padrão para sub-redes VPC de acesso clássico entram em conflito com as sub-redes do plano de controle do IBM Cloud Kubernetes Service. Em vez disso, deve-se criar a VPC sem os prefixos automáticos de endereço padrão e criar os próprios prefixos de endereço. Em seguida, sempre que você criar sub-redes para o seu cluster, elas serão criadas dentro dos intervalos de prefixo de endereço criados.

Criando sub-redes VPC para acesso clássico no console

  1. Crie uma VPC de acesso clássico sem prefixos de endereço padrão.
    1. No painel Nuvens privadas virtuais, clique em Criar.
    2. Insira detalhes para o nome, grupo de recursos e quaisquer tags.
    3. Marque a caixa de seleção para Ativar acesso a recursos clássicos e desmarque a caixa de seleção para Criar um prefixo padrão para cada zona.
    4. Selecione a região para a VPC.
    5. Clique em Criar nuvem particular virtual.
  2. Crie prefixos de endereço em cada zona.
    1. Clique no nome de sua VPC para visualizar seus detalhes.
    2. Clique na guia Prefixos de endereço e clique em Criar.
    3. Para cada zona na qual você planeja criar sub-redes, crie um ou mais prefixos de endereço. Os prefixos de endereço devem estar em um dos seguintes intervalos: 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255.
  3. Crie sub-redes que usem seus prefixos de endereço.
    1. No painel de sub-rede da VPC, clique em Criar.
    2. Insira um nome para sua sub-rede e selecione o nome de sua VPC de acesso clássico.
    3. Selecione o local e a zona nos quais deseja criar a sub-rede.
    4. Selecione o prefixo de endereço criado para essa zona.
    5. Especifique o número de endereços IP a serem criados. As sub-redes VPC fornecem endereços IP para os seus nós do trabalhador e serviços de balanceador de carga no cluster, portanto, crie uma sub-rede VPC com endereços IP suficientes, como 256. Não é possível mudar o número de IPs que uma sub-rede VPC terá depois.
    6. Escolha se deseja conectar um gateway de rede pública à sua sub-rede. É necessário um gateway de rede pública quando você deseja que o seu cluster acesse terminais públicos, como uma URL pública de outro app ou um serviço da IBM Cloud que suporta somente terminais em serviço de nuvem pública.
    7. Clique em Criar sub-rede.
  4. Use as sub-redes para criar um cluster. Não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Criando sub-redes VPC para acesso clássico por meio da CLI

  1. Em sua linha de comandos, efetue login em sua conta da IBM Cloud e vise a região e o grupo de recursos da IBM Cloud nos quais você deseja criar seu cluster de VPC. Para ver as regiões suportadas, consulte Criando uma VPC em uma região diferente. O grupo de recursos do cluster pode diferir do grupo de recursos da VPC. Insira suas credenciais do IBM Cloud quando solicitadas. Se você tiver um ID federado, use a opção --sso para fazer login.
    ibmcloud login -r <region> [-g <resource_group>] [--sso]
  2. Crie uma VPC de acesso clássico sem prefixos de endereço padrão. Na saída, copie o ID da VPC.
    ibmcloud is vpc-create <name> --classic-access --address-prefix-management manual
  3. Para cada zona na qual você planeja criar sub-redes, crie um ou mais prefixos de endereço. Os prefixos de endereço devem estar em um dos seguintes intervalos: 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255.
    ibmcloud is vpc-address-prefix-create <prefix_name> <vpc_id> <zone> <prefix_range>
  4. Crie sub-redes em cada zona que usem seus prefixos de endereço. Para obter mais informações sobre as opções neste comando, consulte a Referência da CLI. As sub-redes VPC fornecem endereços IP para os seus nós do trabalhador e serviços de balanceador de carga no cluster, portanto, crie uma sub-rede VPC com endereços IP suficientes, como 256. Não é possível mudar o número de IPs que uma sub-rede VPC terá depois.
    ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address> --ipv4-cidr-block <prefix_range>
  5. Opcional: anexe um gateway de rede pública à sua sub-rede. É necessário um gateway de rede pública quando você deseja que o seu cluster acesse terminais públicos, como uma URL pública de outro app ou um serviço da IBM Cloud que suporta somente terminais em serviço de nuvem pública.
    1. Crie um gateway público em cada zona. Considere nomear o gateway público no formato <cluster>-<zone>-gateway. Na saída, anote o ID do gateway público.
      ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
      Exemplo de saída
      ID               26466378-6065-4716-a90b-ac7ed7917c63
Name             mycluster-us-south-1-gateway
Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
Status           pending
Created          2019-09-20T16:27:32-05:00
Zone             us-south-1
VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
Resource group   -
    2. Usando os IDs do gateway público e da sub-rede, conecte o gateway público à sub-rede.
      ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
      Exemplo de saída
      ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
Name                mysubnet1
IPv4 CIDR           10.240.xx.xx/24
Address available   250
Address total       256
ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
Created             2019-08-21T09:43:11-05:00
Status              available
Zone                us-south-1
VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
  6. Use as sub-redes para criar um cluster. Não exclua as sub-redes que você anexa ao seu cluster durante a criação do cluster ou ao incluir nós do trabalhador em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.

Restringindo o tráfego de rede pública a uma sub-rede com um gateway público

Melhore a segurança de seu cluster do IBM Cloud® Kubernetes Service, permitindo que menos nós do trabalhador tenham acesso externo por meio de um gateway público de sub-rede da VPC.

Se os pods em seus nós do trabalhador precisarem se conectar a um terminal externo público, será possível anexar um gateway público à sub-rede na qual esses nós do trabalhador estão. Por exemplo, seu cluster de VPC pode conectar-se automaticamente a outros serviços da IBM Cloud que suportam terminais em serviço de nuvem privada, como o IBM Cloud Container Registry. No entanto, se precisar acessar serviços da IBM Cloud que suportam somente terminais em serviço de nuvem pública, é possível conectar um gateway público à sub-rede para que seus pods possam enviar solicitações por meio da rede pública.

É possível isolar esse tráfego de rede em seu cluster conectando um gateway público a apenas uma sub-rede em seu cluster. Em seguida, é possível usar a afinidade do app para implementar pods de app que requerem acesso a terminais externos para somente a sub-rede com um gateway público conectado.

Em clusters VPC, uma sub-rede é limitada a uma zona. Ao conectar um gateway público a apenas uma sub-rede e planejar os pods do app que requerem acesso público aos nós do trabalhador somente nessa sub-rede, esses pods são isolados para uma zona em seu cluster.

  1. Destine a região da VPC para a qual seu cluster é implementado.

    ibmcloud target -r <region>

  2. Verifique se você possui um gateway público em uma zona na qual possui nós do trabalhador. Dentro de uma VPC, é possível criar apenas um gateway público por zona, mas esse gateway público pode ser conectado a várias sub-redes dentro da zona.

    ibmcloud is public-gateways

    Exemplo de saída

    ID                                     Name                                       VPC                          Zone         Floating IP                  Created                     Status      Resource group
26426426-6065-4716-a90b-ac7ed7917c63   test-pgw                                   testvpc(36c8f522-.)          us-south-1   169.xx.xxx.xxx(26466378-.)   2019-09-20T16:27:32-05:00   available   -
2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   team3(ff537d43-.)            us-south-2   169.xx.xxx.xxx(2ba9a280-.)   2019-08-02T10:30:29-05:00   available   -

    • Se você já tiver um gateway público em uma zona na qual tenha trabalhadores e no VPC em que seu cluster está, anote o ID do gateway.

    • Se não houver um gateway público em uma zona na qual existem trabalhadores e na VPC em que o cluster está, crie um gateway público. Considere nomear o gateway público no formato <cluster>-<zone>-gateway. Na saída, anote o ID do gateway público.

      ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>

      Exemplo de saída

      ID               26466378-6065-4716-a90b-ac7ed7917c63
Name             mycluster-us-south-1-gateway
Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
Status           pending
Created          2019-09-20T16:27:32-05:00
Zone             us-south-1
VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
Resource group   -

  3. Liste os nós do trabalhador em seu cluster. Para a zona na qual você ativou o gateway público, anote o IP primário de um nó do trabalhador.

    ibmcloud ks worker ls -c <cluster_name_or_ID>

    Exemplo de saída

    ID                                                   Primary IP     Flavor   State    Status   Zone         Version
kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac   10.240.02.00   c2.2x4   normal   Ready    us-south-2   1.33.7
kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623   10.240.01.00   c2.2x4   normal   Ready    us-south-1   1.33.7

  4. Descreva o nó do trabalhador. Na saída de Rótulos, observe o ID da sub-rede no rótulo ibm-cloud.kubernetes.io/subnet-id, como 5f5787a4-f560-471b-b6ce-20067ac93439 no exemplo a seguir.

    kubectl describe node <worker_primary_ip>

    Exemplo de saída

    NAME:               10.240.01.00
Roles:              <none>
Labels:             arch=amd64
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=c2.2x4
beta.kubernetes.io/os=linux
failure-domain.beta.kubernetes.io/region=us-south
failure-domain.beta.kubernetes.io/zone=us-south-1
ibm-cloud.kubernetes.io/ha-worker=true
ibm-cloud.kubernetes.io/iaas-provider=gc
ibm-cloud.kubernetes.io/internal-ip=10.240.0.77
ibm-cloud.kubernetes.io/machine-type=c2.2x4
ibm-cloud.kubernetes.io/os=UBUNTU_20_64
ibm-cloud.kubernetes.io/region=us-south
ibm-cloud.kubernetes.io/sgx-enabled=false
ibm-cloud.kubernetes.io/subnet-id=5f5787a4-f560-471b-b6ce-20067ac93439
ibm-cloud.kubernetes.io/worker-id=kube-bl25g33d0if1cmfn0p8g-vpcprod-default-00001093
ibm-cloud.kubernetes.io/worker-pool-id=bl25g33d0if1cmfn0p8g-5aa474f
ibm-cloud.kubernetes.io/worker-pool-name=default
ibm-cloud.kubernetes.io/worker-version=1.15.3_1517
ibm-cloud.kubernetes.io/zone=us-south-1
kubernetes.io/arch=amd64
kubernetes.io/hostname=10.240.0.77
kubernetes.io/os=linux
Annotations:        node.alpha.kubernetes.io/ttl: 0
...

  5. Usando os IDs do gateway público e da sub-rede, conecte o gateway público à sub-rede. Os nós do trabalhador que são implementados nessa sub-rede dessa zona agora têm acesso aos terminais externos.

    ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>

    Exemplo de saída

    ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
Name                mysubnet1
IPv4 CIDR           10.240.xx.xx/24
Address available   250
Address total       256
ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
Created             2019-08-21T09:43:11-05:00
Status              available
Zone                us-south-1
VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)

  6. No arquivo de implementação para o app, inclua uma regra de afinidade para o rótulo do ID de sub-rede localizado na etapa 4.

    Na seção afinidade deste YAML de exemplo, ibm-cloud.kubernetes.io/subnet-id é o key e <subnet_ID> é o value.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: ibm-cloud.kubernetes.io/subnet-id
                operator: In
                values:
                - <subnet_ID>
...

  7. Aplique o arquivo de configuração de implementação atualizado.

    kubectl apply -f with-node-affinity.yaml

  8. Verifique se os pods de app foram implementados nos nós do trabalhador corretos.

    1. Liste os pods em seu cluster. Na saída, identifique um pod para seu app. Anote o endereço IP privado do NODE do nó do trabalhador no qual o pod está.

      kubectl get pods -o wide

      Nesta saída de exemplo, o pod do app cf-py-d7b7d94db-vp8pq está em um nó do trabalhador com o endereço IP 10.240.01.00.

      NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
cf-py-d7b7d94db-vp8pq  1/1       Running             0          15d       172.30.xxx.xxx   10.240.01.00

    2. Liste os nós do trabalhador em seu cluster. Na saída, procure os nós do trabalhador na zona na qual você anexou o gateway público. Verifique se o nó do trabalhador com o endereço IP privado que você identificou na etapa anterior está implementado nesta zona.

      ibmcloud ks worker ls --cluster <cluster_name_or_ID>

      Exemplo de saída

      ID                                                   Primary IP     Flavor   State    Status   Zone         Version
kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac   10.240.02.00   c2.2x4   normal   Ready    us-south-2   1.33.7
kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623   10.240.01.00   c2.2x4   normal   Ready    us-south-1   1.33.7

  9. Opcional: se você usar listas de controle de acesso (ACLs) para controlar o tráfego de rede do cluster, crie regras de entrada e saída nessa ACL de sub-rede para permitir ingresso e saída para os terminais públicos externos que seus pods devem acessar.