Configurando o terminal em serviço de nuvem privada

Ative o terminal em serviço de nuvem privada para o seu cluster.

O terminal em serviço de nuvem privada torna o principal do Kubernetes acessível de forma privada. Os nós do trabalhador e seus usuários de cluster autorizados podem se comunicar com o mestre do Kubernetes sobre a rede privada. Para determinar se é possível ativar o terminal em serviço de nuvem privada, consulte Comunicação do trabalhador com o principal e do usuário com o principal. Note que não é possível desativar o terminal em serviço de nuvem privada depois de ativá-lo.

Você criou um cluster somente com um terminal em serviço de nuvem privada antes de ativar a sua conta para o VRF e terminais em serviço? Tente configurar o terminal em serviço de nuvem pública para poder usar seu cluster até que seus casos de suporte sejam processados para atualizar a sua conta.

1. Ative o VRF em sua conta de infraestrutura do IBM Cloud. Para verificar se um VRF já está ativado, use o comando ibmcloud account show.

2. Ative sua conta do IBM Cloud para usar os terminais em serviço.

3. Ative o terminal em serviço de nuvem privada.

   ibmcloud ks cluster master private-service-endpoint enable --cluster CLUSTER_NAME_OR_ID
   

4. Atualize o servidor da API do principal do Kubernetes para usar o terminal em serviço de nuvem privada. É possível seguir o prompt na CLI ou executar manualmente o comando a seguir. A atualização do mestre pode levar diversos minutos para ser concluída.

   ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
   

5. Crie um configmap para controlar o número máximo de nós do trabalhador que podem estar indisponíveis por vez em seu cluster. Quando você atualiza seus nós do trabalhador, o configmap ajuda a evitar o tempo de inatividade para seus apps, pois os apps são reagendados de forma ordenada em nós do trabalhador disponíveis.

6. Atualize todos os nós do trabalhador em seu cluster para selecionar a configuração do terminal em serviço de nuvem privada.

   Emitindo o comando de atualização, os nós do trabalhador são recarregados para selecionar a configuração de terminal em serviço. Se nenhuma atualização do trabalhador está disponível, deve-se recarregar os nós do trabalhador manualmente. Se você recarregar, certifique-se de bloquear, drenar e gerenciar o pedido para controlar o número máximo de nós do trabalhador que estão indisponíveis por vez.

   ibmcloud ks worker update --cluster CLUSTER_NAME_OR_ID --worker WORKER1,WORKER2
   

7. Se o cluster estiver em um ambiente atrás de um firewall:

   • Permita que seus usuários de cluster autorizados executem comandos kubectl para acessar o principal por meio do terminal em serviço de nuvem privada.
   • Permita o tráfego de rede de saída para os IPs privados para recursos de infraestrutura e para os serviços do IBM Cloud que você planeja usar.

8. Opcional: para usar somente o terminal em serviço de nuvem privada:

   1. Desative o terminal em serviço de nuvem pública.
   2. Configure o acesso ao principal no terminal em serviço de nuvem privada.

Configurando o terminal em serviço de nuvem pública

Ative ou desative o terminal em serviço de nuvem pública para o seu cluster.

O terminal em serviço de nuvem pública torna o principal do Kubernetes acessível publicamente. Seus nós do trabalhador e seus usuários de cluster autorizados podem se comunicar de forma segura com o mestre do Kubernetes na rede pública. Para obter mais informações, consulte Comunicação de trabalhador para principal e de usuário para principal.

Alternando do terminal em serviço de nuvem pública para o terminal em serviço de nuvem privada

Ative os nós do trabalhador para se comunicarem com o principal por meio da rede privada em vez da rede pública, ativando o terminal em serviço de nuvem privada.

Por padrão, todos os clusters que estão conectados a uma VLAN pública e a uma privada usam o terminal em serviço de nuvem pública. Seus nós do trabalhador e seus usuários de cluster autorizados podem se comunicar de forma segura com o mestre do Kubernetes na rede pública. Para permitir que os nós do trabalhador se comuniquem com o principal do Kubernetes por meio da rede privada em vez da rede pública, é possível ativar o terminal em serviço de nuvem privada. Em seguida, é possível desativar, opcionalmente, o terminal em serviço de nuvem pública.

• Se você ativar o terminal em serviço de nuvem privada e também mantiver o terminal em serviço de nuvem pública ativado, os trabalhadores sempre se comunicarão com o principal por meio da rede privada, mas os seus usuários poderão se comunicar com o principal por meio da rede pública ou privada.
• Se você ativar o terminal em serviço de nuvem privada mas desativar o terminal em serviço de nuvem pública, os trabalhadores e usuários deverão se comunicar com o principal por meio da rede privada.

Não é possível desativar o endpoint do serviço de nuvem privada depois de ativá-lo.

1. Ative o VRF em sua conta de infraestrutura do IBM Cloud. Para verificar se um VRF já está ativado, use o comando ibmcloud account show.

2. Ative sua conta do IBM Cloud para usar os terminais em serviço.

3. Ative o terminal em serviço de nuvem privada.

   ibmcloud ks cluster master private-service-endpoint enable --cluster CLUSTER_NAME_OR_ID
   

4. Atualize o servidor da API do principal do Kubernetes para usar o terminal em serviço de nuvem privada seguindo o prompt da CLI ou executando manualmente o seguinte comando. A atualização do mestre pode levar diversos minutos para ser concluída.

   ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
   

5. Crie um configmap para controlar o número máximo de nós do trabalhador que podem estar indisponíveis por vez em seu cluster. Quando você atualiza seus nós do trabalhador, o configmap ajuda a evitar o tempo de inatividade para seus apps, pois os apps são reagendados de forma ordenada em nós do trabalhador disponíveis.

6. Atualize todos os nós do trabalhador em seu cluster para selecionar a configuração do terminal em serviço de nuvem privada.

   Emitindo o comando de atualização, os nós do trabalhador são recarregados para selecionar a configuração de terminal em serviço. Se nenhuma atualização do trabalhador está disponível, deve-se recarregar os nós do trabalhador manualmente. Se você recarregar, certifique-se de bloquear, drenar e gerenciar o pedido para controlar o número máximo de nós do trabalhador que estão indisponíveis por vez.

   ibmcloud ks worker update --cluster CLUSTER_NAME_OR_ID --worker WORKER1,WORKER2
   

7. Opcional: para usar somente o terminal em serviço de nuvem privada:

   1. Desative o terminal em serviço de nuvem pública.

       ibmcloud ks cluster master public-service-endpoint disable --cluster CLUSTER_NAME_OR_ID
       ```
   2. [Configure o acesso ao principal no terminal em serviço de nuvem privada](/docs/containers?topic=containers-access-private-classic).
   
   
   
   

Mudando as conexões VLAN do nó do trabalhador

Ao criar um cluster, você escolhe se deseja conectar os nós do trabalhador a uma VLAN privada e pública ou a uma VLAN somente privada. Os nós do trabalhador fazem parte de conjuntos de trabalhadores que armazenam metadados de rede que incluem as VLANs a serem usadas para fornecer os nós do trabalhador futuros no conjunto. Você pode desejar mudar a configuração da conectividade VLAN do seu cluster posteriormente, em casos como os seguintes.

• As VLANs do conjunto de trabalhadores em uma zona fica sem capacidade e você precisa fornecer uma nova VLAN para seus nós do trabalhador do cluster usarem.
• Você tem um cluster com nós do trabalhador que estão em VLANs públicas e privadas, mas você deseja mudar para um cluster somente privado.
• Você tem um cluster somente privado, mas deseja alguns nós do trabalhador, como um conjunto de trabalhadores de nós de borda na VLAN pública para expor seus apps na Internet.

Tentando alterar o terminal em serviço para comunicação do trabalhador principal no lugar? Consulte os tópicos para configurar os terminais em serviço públicos e privados.

A remoção de todos os trabalhadores de uma VLAN remove o endereço IP do Ingresso ALB na zona da VLAN.

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Para mudar as VLANs que um conjunto de trabalhadores usa para fornecer nós do trabalhador:

1. Liste os nomes dos conjuntos de trabalhadores em seu cluster.

   ibmcloud ks worker-pool ls --cluster CLUSTER_NAME_OR_ID
   

2. Determine as zonas para um dos conjuntos de trabalhadores. Na saída, procure o campo Zonas.

   ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
   

3. Para cada zona que você localizou na etapa anterior, obtenha uma VLAN pública e privada disponível que sejam compatíveis entre si.

   1. Verifique as VLANs públicas e privadas disponíveis que estão listadas em Tipo na saída.

       ibmcloud ks vlan ls --zone ZONE
       ```
   2. Verifique se as VLANs públicas e privadas na zona são compatíveis. Para serem compatíveis, o **Roteador** deve ter o mesmo ID de pod. Nesta saída de exemplo, os IDs do pod **Roteador** correspondem: `01a` e `01a`. Se o ID de um pod fosse `01a` e o outro fosse `02a`, não seria possível configurar esses IDs de VLAN públicos e privados para o conjunto de trabalhadores.
   ```sh {: screen}
       ID        Name   Number   Type      Router         Supports Virtual Workers
       229xxxx          1234     private   bcr01a.dal12   true
       229xxxx          5678     public    fcr01a.dal12   true
       ```
   3. Se for necessário solicitar uma nova VLAN pública ou privada para a zona, será possível solicitar no [console da IBM Cloud](/docs/vlans?topic=vlans-ordering-premium-vlans#ordering-premium-vlans) ou usar o comando a seguir. Lembre-se de que as VLANs devem ser compatíveis, com os IDs de pod correspondentes do **Roteador** como na etapa anterior. Se você estiver criando um par de novas VLANs públicas e privadas, elas deverão ser compatíveis uma com a outra.
   ```sh {: pre}
       ibmcloud sl vlan create -t [public|private] -d <zone> -r <compatible_router>
       ```
   4. Observe os IDs das VLANs compatíveis.
   
   

4. Configure um conjunto de trabalhadores com os novos metadados de rede da VLAN para cada zona. É possível criar um novo conjunto de trabalhadores, ou modificar um conjunto de trabalhadores existente.

   • Criar um pool de workers: Consulte a seção sobre como adicionar nós de trabalho criando um novo pool de workers.

   • Modificar um conjunto de trabalhadores existente: configure os metadados de rede do conjunto de trabalhadores para usar a VLAN para cada zona. Os nós do trabalhador que já foram criados no conjunto continuam a usar as VLANs anteriores, mas novos nós do trabalhador no conjunto usam novos metadados de VLAN que você configurou.

   • Exemplo para incluir VLANs públicas e privadas, como, se você mudar de somente privada para privada e pública:

       ibmcloud ks zone network-set --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --public-vlan PUBLIC_VLAN_ID
       ```
   - Exemplo para incluir apenas uma VLAN privada, como mudar de VLANs públicas e privadas para somente privadas quando há uma [conta ativada para VRF que usa terminais em serviço](/docs/account?topic=account-vrf-service-endpoint):
   
   ```sh {: pre}
       ibmcloud ks zone network-set --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --private-only
       ```
   

5. Inclua nós do trabalhador no conjunto de trabalhadores redimensionando o conjunto.

   ibmcloud ks worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --size-per-zone NUMBER_OF_WORKERS_PER_ZONE
   

   Para remover nós do trabalhador que usam os metadados de rede anteriores, mude o número de trabalhadores por zona para duplicar o número anterior de trabalhadores por zona. Posteriormente nessas etapas, é possível unir, drenar e remover os nós do trabalhador anteriores.

6. Verifique se os novos nós do trabalhador são criados com os endereços IP público e IP Privado apropriados na saída. Por exemplo, se você mudar o conjunto de trabalhadores de uma VLAN pública e privada para somente privada, os novos nós do trabalhador terão apenas um IP privado. Se você mudar o conjunto de trabalhadores de VLANs somente privadas para públicas e privadas, os novos nós do trabalhador terão IPs públicos e privados.

   ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
   

7. Opcional: remova os nós do trabalhador com os metadados de rede anteriores do conjunto de trabalhadores.

   1. Na saída da etapa anterior, observe o ID dos nós do trabalhador que você deseja remover do conjunto de trabalhadores.
   2. Remova o nó do trabalhador.

       ibmcloud ks worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_NAME_OR_ID
       ```
   3. Verifique se o nó do trabalhador foi removido.
   ```sh {: pre}
       ibmcloud ks worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
       ```
   4. Rebalanceie o conjunto de trabalhadores.
   ```sh {: pre}
       ibmcloud ks worker-pool rebalance --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
       ```
   
   
   

8. Opcional: Repita as etapas 2 a 7 para cada grupo de trabalhadores do seu cluster. Depois de concluir essas etapas, todos os nós do trabalhador em seu cluster são configurados com as novas VLANs.

9. Os ALBs padrão em seu cluster ainda estão ligados à VLAN antiga porque seus endereços IP são de uma sub-rede na VLAN. Como os ALBs não podem ser movidos através de VLANs, é possível criar ALBs nas novas VLANs e desativar aqueles nas VLANs antigas.

10. Opcional: se você não precisar mais das sub-redes nas VLANs antigas, será possível removê-las.