Conexões VLAN para nós do trabalhador

Todos os nós do trabalhador devem ser conectados a uma VLAN privada para que cada nó do trabalhador possa enviar e receber informações de outros nós do trabalhador. A VLAN privada fornece sub-redes privadas que são usadas para designar endereços IP privados para seus nós do trabalhador e serviços de app privados. É possível criar um cluster com nós do trabalhador que também estão conectados a uma VLAN pública. A VLAN pública fornece sub-redes públicas que são usadas para designar endereços IP públicos para seus nós do trabalhador e serviços de aplicativo públicos. No entanto, caso precise proteger seus aplicativos na interface de rede pública, há várias opções disponíveis para proteger seu cluster, como a criação de políticas de rede d Calico ou o isolamento de cargas de trabalho da rede externa em nós de trabalho de borda.

Na primeira vez que você criar um cluster em uma zona, uma VLAN pública e uma VLAN privada nessa zona serão automaticamente provisionadas para você na sua conta da infraestrutura do IBM Cloud. Se você especificar que os nós do trabalhador devem ser conectados a somente uma VLAN privada, somente uma VLAN privada nessa zona será provisionada automaticamente. Para cada cluster subsequente que for criado nessa zona, será possível especificar o par de VLANs que você deseja usar. É possível reutilizar as mesmas VLANs públicas e privadas que foram criadas para você porque diversos clusters podem compartilhar VLANs.

Para obter mais informações sobre VLANs, sub-redes e endereços IP, consulte Visão geral de rede no IBM Cloud Kubernetes Service.

É necessário criar seu cluster usando sub-redes customizadas? Consulte Usando sub-redes existentes para criar um cluster.

Comunicação do nó do trabalhador entre sub-redes e VLANs

Em diversas situações, os componentes no cluster devem ter permissão para se comunicar por meio de várias VLANs privadas. Por exemplo, para criar um cluster multizona, se você tiver várias VLANs para um cluster ou várias sub-redes na mesma VLAN, os nós do trabalhador em diferentes sub-redes na mesma VLAN ou em VLANs diferentes não poderão se comunicar automaticamente. Deve-se ativar o Virtual Routing and Forwarding (VRF) ou o VLAN Spanning para sua conta de infraestrutura da IBM Cloud.

• Virtual Routing and Forwarding (VRF): o VRF permite que todas as VLANs privadas e sub-redes em sua conta de infraestrutura se comuniquem entre si. Além disso, o VRF é necessário para permitir que os seus trabalhadores e o principal se comuniquem por meio do terminal em serviço de nuvem privada e se comuniquem com outras instâncias da IBM Cloud que suportam terminais em serviço de nuvem privada. Para verificar se um VRF já está ativado, use o comando ibmcloud account show. Para ativar o VRF, execute ibmcloud account update --service-endpoint-enable true. Essa saída de comando solicita que você abra um caso de suporte para ativar sua conta para usar o VRF e os terminais em serviço. O VRF elimina a opção VLAN Spanning para sua conta porque todas as VLANs são capazes de se comunicar. Quando o VRF for ativado, qualquer sistema que estiver conectado a qualquer uma das VLANs privadas na mesma conta do IBM Cloud poderá se comunicar com os nós do trabalhador do cluster. É possível isolar seu cluster de outros sistemas na rede privada, aplicando políticas de rede privada do Calico.
• Expansão de VLAN: Não é possível habilitar o endpoint do serviço de nuvem privada se você optar por habilitar a expansão de VLAN em vez do VRF. Habilite o spanning de VLAN quando não for possível ou não for desejável habilitar o VRF, como nos casos em que não for necessário que o mestre esteja acessível na rede privada ou se você utilizar um dispositivo de gateway para acessar o mestre pela VLAN pública. Observe que, por exemplo, se você já tiver um dispositivo de gateway e, em seguida, adicionar um cluster, as novas sub-redes portáteis encomendadas para o cluster não serão configuradas no dispositivo de gateway, mas a extensão de VLAN permite o roteamento entre as sub-redes.

Somente terminal em serviço público

Se você não quiser ou não puder ativar a VRF para a conta, os nós do trabalhador poderão se conectar automaticamente ao principal do Kubernetes por meio da VLAN pública através do terminal em serviço de nuvem pública.

• A comunicação entre os nós do trabalhador e o principal é estabelecida de forma segura pela rede pública por meio do terminal em serviço de nuvem pública.
• O principal é acessível publicamente a usuários de cluster autorizados somente por meio do terminal em serviço de nuvem pública. Os usuários do cluster podem acessar com segurança seu mestre do Kubernetes na Internet para executar os comandos kubectl, por exemplo.
• Opcionalmente, você pode proteger o acesso aos endpoints de serviço público e privado do cluster usando restrições baseadas em contexto.

Terminais em serviço de nuvem pública e privada

Para tornar o seu principal acessível de forma pública ou privada aos usuários de cluster, é possível ativar os terminais em serviço de nuvem pública e privada. O VRF é necessário em sua conta do IBM Cloud e deve-se ativar sua conta para usar os terminais em serviço. Para ativar o VRF e os terminais em serviço, execute ibmcloud account update --service-endpoint-enable true.

• Se os nós do trabalhador estiverem conectados às VLANs públicas e privadas, a comunicação entre os nós do trabalhador e o principal será estabelecida pela rede privada por meio do terminal em serviço de nuvem privada e pela rede pública por meio do terminal em serviço de nuvem pública. Ao rotear metade do tráfego do trabalhador para o principal pelo terminal público e metade pelo terminal privado, a comunicação entre eles é protegida contra possíveis indisponibilidades da rede pública ou da rede privada. Se os nós do trabalhador estiverem conectados somente a VLANs privadas, a comunicação entre os nós do trabalhador e o principal será estabelecida pela rede privada somente por meio do terminal em serviço de nuvem privada.
• O principal é publicamente acessível a usuários de cluster autorizados por meio do terminal em serviço de nuvem pública. O principal será acessível de forma privada por meio do terminal em serviço de nuvem privada se os usuários de cluster autorizados estiverem na rede privada da IBM Cloud ou conectados à rede privada por meio de uma conexão VPN ou do IBM Cloud Direct Link. Observe que se deve expor o terminal do principal por meio de um balanceador de carga privado para que os usuários possam acessar o principal por meio de uma VPN ou uma conexão IBM Cloud Direct Link.
• Opcionalmente, você pode proteger o acesso aos endpoints de serviço público e privado do cluster usando restrições baseadas em contexto.

Somente terminal em serviço privado

Para tornar o seu principal acessível somente de forma privada, é possível ativar o terminal em serviço de nuvem privada. O VRF é necessário em sua conta do IBM Cloud e deve-se ativar sua conta para usar os terminais em serviço. Para ativar o VRF e os terminais em serviço, execute ibmcloud account update --service-endpoint-enable true. Observe que usar somente o terminal em serviço de nuvem privada incorre em nenhuma cobrança de largura da banda faturada ou medida.

• A comunicação entre os nós do trabalhador e o principal é estabelecida pela rede privada por meio do terminal em serviço de nuvem privada.
• O principal será acessível de forma privada se os usuários do cluster autorizados estiverem em sua rede privada do IBM Cloud ou estiverem conectados à rede privada por meio de uma conexão VPN ou DirectLink. Observe que se deve expor o terminal principal por meio de um balanceador de carga privado para que os usuários possam acessar o principal por meio de uma conexão VPN ou DirectLink.
• Opcionalmente, você pode proteger o acesso aos endpoints de serviço público e privado do cluster usando restrições baseadas em contexto.

Comunicação com outros serviços da IBM Cloud por meio da rede privada ou pública

Seus nós do trabalhador podem se comunicar de forma automática e segura com outros serviços da IBM Cloud que suportam terminais em serviço de nuvem privada, como o IBM Cloud® Container Registry, por meio da rede privada de infraestrutura da IBM Cloud. Se um serviço da IBM Cloud não suportar terminais em serviço de nuvem privada, seus nós do trabalhador devem ser conectados a uma VLAN pública para poderem se comunicar de forma segura com os serviços por meio da rede pública.

Se você usa políticas do Calico ou um dispositivo de gateway para controlar as redes públicas ou privadas de seus nós do trabalhador, deve-se permitir o acesso aos endereços IP públicos dos serviços que suportam terminais em serviço de nuvem pública e, opcionalmente, aos endereços IP privados dos serviços que suportam terminais em serviço de nuvem privada.

• Permitir acesso aos endereços IP públicos dos serviços nas políticas do Calico
• Permitir acesso aos endereços IP privados de serviços que suportam terminais em serviço de nuvem privada em políticas do Calico
• Permitir acesso a endereços IP públicos de serviços e aos endereços IP privados de serviços que suportam terminais em serviço de nuvem privada em um firewall do dispositivo de gateway

IBM Cloud® Direct Link para comunicação por meio da rede privada com recursos em data centers no local

Para conectar seu cluster ao seu data center no local, como com o IBM Cloud Private, é possível configurar o IBM Cloud Direct Link. Com o IBM Cloud Direct Link, você cria uma conexão privada direta entre seus ambientes de rede remota e o IBM Cloud Kubernetes Service sem rotear na Internet pública.

Conexão VPN para comunicação pela rede pública com recursos em data centers locais

• Nós de trabalho que estão conectados a VLANs públicas e privadas: Configure um serviço de VPN em seu cluster para fornecer um canal de comunicação seguro de ponta a ponta pela Internet entre seu cluster e uma rede local. Existem várias opções de código aberto, consulte Conectividade VPN clássica.

• Nós de trabalho conectados apenas a uma VLAN privada: Configure um ponto de extremidade de VPN em um dispositivo gateway, como o Vyatta ( Virtual Router Appliance ).

Se você planeja conectar seu cluster a redes no local, confira as informações úteis a seguir:

• Você pode ter conflitos de sub-rede com o intervalo padrão fornecido pela IBM 172.30.0.0/16 para pods e o intervalo 172.21.0.0/16 para serviços. É possível evitar conflitos de sub-rede ao criar um cluster pela CLI, especificando um CIDR de sub-rede personalizado para os pods na opção --pod-subnet e um CIDR de sub-rede personalizado para os serviços na opção --service-subnet .
• Se a sua solução VPN preserva os endereços IP de origem de solicitações, é possível criar rotas estáticas customizadas para garantir que seus nós do trabalhador possam rotear respostas do seu cluster de volta para a sua rede no local.
• Note que os intervalos de sub-rede 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 e 172.20.0.0/16 são proibidos por serem reservados para a funcionalidade do plano de controle do IBM Cloud Kubernetes Service.

Tráfego privado para apps de cluster

Ao implementar um app no cluster, talvez você queira tornar o app acessível apenas para usuários e serviços que estão na mesma rede privada do cluster. O balanceamento de carga privado é ideal para tornar seu app disponível para solicitações de fora do cluster sem o expor ao público em geral. Também é possível usar o balanceamento de carga privado para testar o acesso, o roteamento de solicitação e outras configurações para seu app antes de ele ser exposto posteriormente para o público com serviços de rede pública. Para permitir solicitações de tráfego privado de fora do cluster para seus apps, é possível criar serviços de rede privada do Kubernetes, como NodePorts privados, NLBs e ALBs do Ingress. Em seguida, é possível usar as políticas pré-DNAT do Calico para bloquear o tráfego para NodePorts públicos de serviços de rede privada. Para obter mais informações, consulte Planejando o balanceamento de carga externa privada.

Tráfego público para apps de cluster

Para tornar seus apps externamente acessíveis por meio da Internet pública, é possível criar NodePorts públicos, Network Load Balancers (NLBs) e Application Load Balancers (ALBs) do Ingress. Os serviços de rede pública se conectam a essa interface de rede pública, fornecendo seu app com um endereço IP público e, dependendo do serviço, uma URL pública. Quando um app é publicamente exposto, qualquer pessoa que tenha o endereço IP de serviço público ou a URL configurada para ele pode enviar uma solicitação para seu app. É possível usar políticas pré-DNAT do Calico para controlar o tráfego para serviços de rede públicos, como permitir o tráfego apenas por meio de determinados endereços IP de origem ou CIDRs e bloquear todo o outro tráfego. Para obter mais informações, consulte Planejando o balanceamento de carga externa pública.

Para maior segurança, você pode isolar as cargas de trabalho de rede nos nós de trabalho de borda.

Os nós do trabalhador de borda podem melhorar a segurança de seu cluster permitindo que menos nós do trabalhador conectados a VLANs públicas sejam acessados externamente e isolando a carga de trabalho de rede. Quando você rotula nós do trabalhador como nós de borda, os pods NLB e ALB são implementados somente para os nós do trabalhador especificados. Além disso, para impedir que outras cargas de trabalho sejam executadas nos nós de borda, é possível marcar esses nós como “tainted ”. Em seguida, é possível implementar os NLBs públicos e privados e ALBs para nós de borda. Por exemplo, se os nós do trabalhador estiverem conectados a somente uma VLAN privada, mas você precisar permitir acesso público a um app em seu cluster, será possível criar um conjunto de trabalhadores de borda no qual os nós de borda estão conectados a VLANs públicas e privadas. É possível implementar NLBs e ALBs públicos nesses nós de borda para assegurar que somente esses trabalhadores manipulem conexões públicas.

Comunicação de trabalhador para trabalhador em clusters clássicos com cargas de trabalho voltadas à Internet

Para alcançar essa configuração, você cria um cluster conectando os nós do trabalhador a VLANs públicas e privadas.

Se você criar o cluster com VLANs públicas e privadas, não será possível remover todas as VLANs públicas desse cluster posteriormente. A remoção de todas as VLANs públicas de um cluster faz com que diversos componentes do cluster parem de funcionar. Em vez disso, crie um novo conjunto de trabalhadores que esteja conectado a somente uma VLAN privada.

Comunicação de trabalhador para trabalhador e de usuário para mestre em clusters clássicos com cargas de trabalho voltadas à Internet

É possível escolher permitir a comunicação de trabalhador para principal e de usuário para principal pelas redes públicas e privadas ou somente pela rede pública.

• Terminais em serviço de nuvem pública e privada: sua conta deve ser ativada com o VRF e ativada para usar terminais em serviço. A comunicação entre os nós do trabalhador e o principal é estabelecida pela rede privada por meio do terminal em serviço de nuvem privada e pela rede pública por meio do terminal em serviço de nuvem pública. O principal é publicamente acessível a usuários de cluster autorizados por meio do terminal em serviço de nuvem pública.
• Terminal em serviço público: se você não quiser ou não puder ativar a VRF para sua conta, os nós do trabalhador e usuários de cluster autorizados poderão se conectar automaticamente ao principal do Kubernetes por meio da rede pública através do terminal em serviço de nuvem pública.

Comunicação de trabalhador com outros serviços ou redes com cargas de trabalho voltadas à Internet

Seus nós do trabalhador podem se comunicar de forma automática e segura com outros serviços da IBM Cloud que suportam terminais em serviço de nuvem privada por meio da rede privada de infraestrutura da IBM Cloud. Se um serviço da IBM Cloud não suportar terminais em serviço de nuvem privada, os trabalhadores poderão se comunicar de forma segura com os serviços por meio da rede pública. É possível bloquear as interfaces públicas ou privadas de nós do trabalhador usando políticas de rede do Calico para isolamento de rede pública ou de rede privada. Talvez seja necessário permitir acesso aos endereços IP públicos e privados dos serviços que você deseja usar nessas políticas de isolamento do Calico.

Se os nós de trabalho precisarem acessar serviços em redes privadas fora da sua conta IBM Cloud, consulte Configuração da conectividade de rede privada

Comunicação externa para apps que são executados em nós do trabalhador com cargas de trabalho voltadas à Internet

Para expor um app em seu cluster na Internet, é possível criar um serviço público de balanceador de carga de rede (NLB) ou balanceador de carga de aplicativo (ALB) do Ingress. É possível melhorar a segurança de seu cluster, criando um conjunto de nós do trabalhador que são rotulados como nós de borda. Os pods para serviços de rede pública são implementados nos nós de borda para que as cargas de trabalho de tráfego externo sejam isoladas para somente alguns trabalhadores em seu cluster. É possível controlar ainda mais o tráfego público para os serviços de rede que expõem seus apps criando políticas pré-DNAT do Calico, como políticas de lista de permissões e de lista de bloqueios.

Pronto para iniciar com um cluster neste cenário? Depois de planejar sua configuração de alta disponibilidade, consulte Criação de clusters.

Comunicação de trabalhador para trabalhador, comunicação de trabalhador para mestre e de usuário para mestre com um dispositivo de gateway

Se configurar os nós do trabalhador apenas em uma VLAN privada e não quiser ou não puder ativar a VRF para a conta, você deverá configurar um dispositivo de gateway para fornecer conectividade de rede entre os nós do trabalhador e o principal por meio da rede pública. Por exemplo, você pode escolher configurar um Virtual Router Appliance.

É possível configurar o dispositivo de gateway com políticas de rede customizadas para fornecer segurança de rede dedicada para seu cluster e para detectar e corrigir intrusão de rede. Ao configurar um firewall na rede pública, deve-se abrir as portas necessárias e os endereços IP privados para cada região para que o principal e os nós do trabalhador possam se comunicar. Se esse firewall também é configurado para a rede privada, deve-se também abrir as portas necessárias e os endereços IP privados para permitir a comunicação entre os nós do trabalhador e permitir que seu cluster acesse os recursos de infraestrutura pela rede privada. Deve-se também ativar o VLAN Spanning para sua conta para que as sub-redes possam rotear na mesma VLAN e entre VLANs.

Comunicação do trabalhador com outros serviços ou redes com um dispositivo de gateway

Para conectar com segurança os nós de trabalho e os aplicativos a uma rede local ou a serviços fora do site IBM Cloud, consulte Configuração da conectividade de rede privada

Os nós do trabalhador podem se comunicar com segurança com outros serviços do IBM Cloud e serviços públicos fora do IBM Cloud por meio de seu dispositivo de gateway. É possível configurar o firewall para permitir o acesso a endereços IP públicos e privados somente dos serviços que você deseja usar

Comunicação externa com apps que são executados em nós do trabalhador com um dispositivo de gateway

Para fornecer acesso privado a um app em seu cluster, é possível criar um balanceador de carga de rede (NLB) ou um balanceador de carga de aplicativo (ALB) do Ingress privado para expor seu app somente para a rede privada. Se for necessário fornecer acesso público limitado a um app no cluster, será possível criar um NLB ou ALB público para expor o app. Como todo o tráfego passa por seu firewall do dispositivo de gateway, é possível controlar o tráfego público e privado para os serviços de rede que expõem seus apps abrindo as portas de serviço e os endereços IP em seu firewall para permitir o tráfego de entrada para esses serviços.

Pronto para iniciar com um cluster neste cenário? Depois de planejar sua configuração de alta disponibilidade, consulte Criação de clusters.

Comunicação de trabalhador para trabalhador para clusters privados

Para realizar essa configuração, crie um cluster conectando os nós do trabalhador a somente uma VLAN privada. Para fornecer conectividade entre o cluster mestre e os nós do trabalhador sobre a rede privada por meio somente do terminal em serviço de nuvem privada, a conta deve ser ativada com o VRF e ativada para usar terminais em serviço. Como o cluster fica visível a qualquer recurso na rede privada quando o VRF é ativado, é possível isolar o cluster de outros sistemas na rede privada aplicando políticas de rede privada do Calico.

Note que você pode ter conflitos de sub-rede entre os intervalos padrão para nós de trabalhadores, pods e serviços e as sub-redes em redes no local. Você cria seu cluster sem as sub-redes fornecidas pel IBM, incluindo a opção --no-subnet. Depois que o cluster é criado, é possível incluir sub-redes customizadas nele. Além disso, é possível especificar um CIDR de sub-rede personalizado para pods e serviços usando as opções --pod-subnet e --service-subnet no comando ibmcloud ks cluster create ao criar seu cluster.

Comunicação de trabalhador para principal e de usuário para principal para clusters privados

O mestre do Kubernetes será acessível por meio do terminal em serviço de nuvem privada se os usuários de cluster autorizados estiverem na rede privada da IBM Cloud ou conectados à rede privada, por exemplo, por meio de uma conexão VPN clássica ou do IBM Cloud Direct Link. No entanto, a comunicação com o mestre do Kubernetes pelo terminal em serviço de nuvem privada deve passar pelo intervalo de endereço IP 166.X.X.X, que não é roteável por meio de uma conexão VPN clássica ou por meio do IBM Cloud Direct Link. É possível expor o terminal em serviço de nuvem privada do principal para os usuários de cluster usando um balanceador de carga de rede (NLB) privado. O NLB privado expõe o terminal em serviço de nuvem privada do principal como um intervalo de endereço IP interno 10.X.X.X que os usuários podem acessar com a conexão VPN ou do IBM Cloud Direct Link. Se você ativar somente o terminal em serviço de nuvem privada, será possível usar o painel do Kubernetes ou ativar temporariamente o terminal em serviço de nuvem pública para criar o NLB privado.

Comunicação de trabalhador com outros serviços ou redes para clusters privados

Seus nós do trabalhador podem se comunicar de forma automática e segura com outros serviços da IBM Cloud que suportam terminais em serviço de nuvem privada, como o IBM Cloud® Container Registry, por meio da rede privada de infraestrutura da IBM Cloud. Por exemplo, ambientes de hardware dedicados para todas as instâncias de plano padrão do IBM Cloudant suportam terminais em serviço de nuvem privada. Se um serviço da IBM Cloud não suportar terminais em serviço de nuvem privada, o cluster não poderá acessar esse serviço.

Comunicação externa com apps que são executados em nós do trabalhador para clusters privados

Para fornecer acesso privado a um app no cluster, é possível criar um balanceador de carga de rede (NLB) privado ou balanceador de carga do aplicativo (ALB) do Ingress. Esses serviços de rede do Kubernetes expõem seu app somente à rede privada para que qualquer sistema no local com uma conexão à sub-rede em que o IP do NLB esteja possa acessar o app.

Pronto para iniciar com um cluster neste cenário? Depois de planejar sua configuração de alta disponibilidade, consulte Criação de clusters.