Como funciona a Ponte para Kubernetes

O Bridge to Kubernetes é uma ferramenta de desenvolvimento iterativo para criar aplicativos de microsserviço direcionados ao Kubernetes. A extensão Bridge to Kubernetes está disponível para Visual Studio e Visual Studio Code (VS Code).

O Bridge to Kubernetes permite que você execute e depure o código em seu computador de desenvolvimento. Esse computador ainda está conectado ao cluster do Kubernetes com o restante do aplicativo ou serviços. Se você tiver uma arquitetura de microsserviços grande com muitos serviços e bancos de dados interdependentes, replicar essas dependências no computador de desenvolvimento pode ser difícil. A criação e a implantação de código no cluster do Kubernetes para cada alteração de código podem ser lentas, demoradas e difíceis.

O Bridge to Kubernetes cria uma conexão entre o computador de desenvolvimento e o cluster. Essa abordagem evita a necessidade de criar e implantar seu código no cluster. Você pode testar e desenvolver seu serviço no contexto, conectado ao cluster. Essa abordagem permite que você depure sem criar mais nenhuma configuração do Docker ou do Kubernetes.

O Bridge to Kubernetes redireciona o tráfego entre o cluster do Kubernetes conectado e o computador de desenvolvimento. O código local e os serviços no cluster do Kubernetes podem se comunicar como se estivessem no mesmo cluster do Kubernetes.

O Bridge to Kubernetes permite replicar variáveis de ambiente e volumes montados no cluster do Kubernetes para o computador de desenvolvimento. O acesso a variáveis de ambiente e volumes montados permite que você trabalhe no código sem precisar replicar essas dependências.

Requisitos

Observação

O Bridge to Kubernetes não funciona com clusters do Kubernetes do Docker for Desktop. Para usar o Bridge to Kubernetes, você precisa de uma das seguintes configurações:

Você pode usar o Bridge to Kubernetes para estabelecer uma conexão com o cluster do Kubernetes. Essa conexão redireciona o tráfego de e para um pod existente no cluster para o computador de desenvolvimento.

Observação

Ao usar o Bridge to Kubernetes, você será solicitado a fornecer o nome do serviço a ser redirecionado para o computador de desenvolvimento. Essa opção é uma maneira conveniente de identificar um pod para redirecionamento. Todo o redirecionamento entre o cluster do Kubernetes e o computador de desenvolvimento é para um pod. Para obter mais informações, confira Disponibilizar um serviço.

No VS Code, o Bridge to Kubernetes dá suporte a todas as linguagens de programação, desde que você possa executá-las localmente. No Visual Studio, o Bridge to Kubernetes dá suporte ao .NET Core. O Bridge to Kubernetes não dá suporte ao .NET Framework no Visual Studio porque ele exige suporte a nós do Windows.

Cuidado

O Bridge to Kubernetes destina-se apenas ao uso em cenários de desenvolvimento e teste. Ele não se destina nem tem suporte para uso com clusters de produção ou serviços dinâmicos em uso ativo.

Para obter recursos atuais e planos futuros, confira o roteiro do Bridge to Kubernetes.

Estabelecer uma conexão

Quando o Bridge to Kubernetes estabelece uma conexão com o cluster, ele executa as seguintes ações:

  • Solicita que você configure o serviço para substituir no cluster, a porta no computador de desenvolvimento a ser usada para o código e a tarefa de inicialização do código como uma ação realizada apenas uma vez.
  • Substitui o contêiner no pod no cluster por um contêiner de agente remoto que redireciona o tráfego para o computador de desenvolvimento.
  • Executa kubectl port-forward em seu computador de desenvolvimento para encaminhar o tráfego do computador de desenvolvimento para o agente remoto em execução no cluster.
  • Coleta informações de ambiente do cluster usando o agente remoto. Essas informações de ambiente incluem variáveis de ambiente, serviços visíveis, montagens de volume e montagens secretas.
  • Configura o ambiente no Visual Studio para que o serviço no computador de desenvolvimento possa acessar as mesmas variáveis como se estivesse em execução no cluster.
  • Atualiza o seu arquivo hosts para mapear serviços em seu cluster para endereços IP locais em seu computador de desenvolvimento. Essas entradas de arquivo hosts permitem que o código em execução no computador de desenvolvimento faça solicitações para outros serviços em execução no cluster. Para atualizar o arquivo hosts, o Bridge to Kubernetes precisa de acesso de administrador em seu computador de desenvolvimento.
  • Começa a executar e depurar o código no computador de desenvolvimento. Se necessário, o Bridge to Kubernetes libera as portas necessárias em seu computador de desenvolvimento interrompendo serviços ou processos que estão usando essas portas no momento.

Usar o Bridge to Kubernetes

Depois de estabelecer uma conexão com o cluster, execute e depure o código nativamente no computador, sem transporte em contêineres. O código interage com o cluster. Qualquer tráfego de rede recebido pelo agente remoto é redirecionado para a porta local especificada durante a conexão. Seu código em execução nativamente pode aceitar e processar esse tráfego. As variáveis de ambiente, os volumes e os segredos do cluster são disponibilizados para o código em execução no computador de desenvolvimento.

O Bridge to Kubernetes adiciona entradas de arquivo de hosts e encaminhamento de porta para seu computador desenvolvedor. Seu código pode enviar tráfego de rede para serviços em execução no cluster usando os nomes de serviço do cluster. Esse tráfego é encaminhado para os serviços em execução no cluster. O tráfego é roteado entre o computador de desenvolvimento e o cluster o tempo todo que você está conectado.

Além disso, o Bridge to Kubernetes fornece uma maneira de replicar variáveis de ambiente e arquivos montados disponíveis para pods em seu cluster no computador de desenvolvimento por meio do arquivo KubernetesLocalProcessConfig.yaml. Você também pode usar esse arquivo para criar variáveis de ambiente e montagens de volume.

Observação

Durante a conexão com o cluster, além de 15 minutos, o Bridge to Kubernetes executa um processo chamado EndpointManager com permissões de administrador no computador local.

Você pode depurar em paralelo, com vários serviços. Inicie o número de instâncias do Visual Studio você deseja depurar. Verifique se seus serviços escutam em portas diferentes localmente. Configure e depure-os separadamente. Não há suporte para isolamento neste cenário.

Configuração adicional

O arquivo KubernetesLocalProcessConfig.yaml permite replicar variáveis de ambiente e arquivos montados disponíveis para seus pods no cluster. Quando você usa o Visual Studio, o arquivo KubernetesLocalConfig.yaml precisa estar no mesmo diretório que o arquivo de projeto do serviço. Para obter mais informações, confira Configurar o Bridge to Kubernetes.

Usar recursos de roteamento para desenvolver isoladamente

Por padrão, o Bridge to Kubernetes redireciona todo o tráfego de um serviço para o computador de desenvolvimento. Em vez disso, você pode usar recursos de roteamento para redirecionar apenas solicitações de um subdomínio para o computador de desenvolvimento. Esses recursos de roteamento permitem que você use o Bridge to Kubernetes para desenvolver isoladamente e evitar interromper outros tráfegos no cluster.

A seguinte animação mostra dois desenvolvedores trabalhando no mesmo cluster isoladamente:

Animation shows isolation, with two developers working with the same cluster.

Quando você habilita o trabalho isoladamente, o Bridge to Kubernetes executa as seguintes ações, além de se conectar ao cluster do Kubernetes:

  • Verifica se o cluster do Kubernetes não tem o Azure Dev Spaces habilitado.
  • Replica o serviço escolhido no cluster no mesmo namespace e adiciona um rótulo routing.visualstudio.io/route-from=SERVICE_NAME e uma anotação routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME.
  • Configura e inicia o gerenciador de roteamento no mesmo namespace no cluster do Kubernetes. O gerenciador de roteamento usa um seletor de rótulo para procurar o rótulo routing.visualstudio.io/route-from=SERVICE_NAME e a anotação routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME ao configurar o roteamento no namespace.

Observação

O Bridge to Kubernetes verifica se o Azure Dev Spaces está habilitado no cluster do Kubernetes. Ele solicita que você desabilite o Azure Dev Spaces antes de usar o Bridge to Kubernetes.

O gerenciador de roteamento executa as seguintes ações quando é iniciado:

  • Duplica todas as entradas, incluindo entradas do balanceador de carga, encontradas no namespace usando o GENERATED_NAME para o subdomínio.
  • Cria um pod envoy para cada serviço associado a entradas duplicadas com o subdomínio GENERATED_NAME.
  • Cria outro pod envoy para o serviço no qual você está trabalhando isoladamente. Essa configuração permite que solicitações com o subdomínio sejam roteadas para o computador de desenvolvimento.
  • Configura regras de roteamento para cada pod envoy para lidar com o roteamento de serviços com o subdomínio.

O seguinte diagrama mostra um cluster do Kubernetes antes que o Bridge to Kubernetes se conecte ao cluster:

Diagram of cluster without Bridge to Kubernetes.

O diagrama a seguir mostra o mesmo cluster com o Bridge to Kubernetes habilitado no modo de isolamento. Aqui, você pode ver o serviço duplicado e os pods envoy que dão suporte ao roteamento em isolamento.

Diagram of cluster with Bridge to Kubernetes enabled.

Quando o cluster recebe uma solicitação com o subdomínio GENERATED_NAME, ele adiciona um cabeçalho kubernetes-route-as=GENERATED_NAME à solicitação. Os pods envoy lidam com o roteamento dessa solicitação para o serviço apropriado no cluster. Para uma solicitação para o serviço que está sendo trabalhado isoladamente, o cluster redireciona a solicitação para o computador de desenvolvimento pelo agente remoto.

Quando o cluster recebe uma solicitação sem o subdomínio GENERATED_NAME, ele não adiciona um cabeçalho à solicitação. Os pods envoy lidam com o roteamento dessa solicitação para o serviço apropriado no cluster. Para uma solicitação para o serviço que está sendo substituído, os pods o encaminham para o serviço original em vez do agente remoto.

Importante

Cada serviço no cluster precisa encaminhar o cabeçalho kubernetes-route-as=GENERATED_NAME ao fazer solicitações adicionais. Por exemplo, quando serviceA recebe uma solicitação, ele faz uma solicitação para serviceB antes de retornar uma resposta. Neste exemplo, serviceA precisa encaminhar o cabeçalho kubernetes-route-as=GENERATED_NAME na solicitação dele para serviceB. Algumas linguagens de programação, como ASP.NET, podem ter métodos para lidar com a propagação de cabeçalho.

Quando você se desconecta do cluster, por padrão, o Bridge to Kubernetes remove todos os pods envoy e o serviço duplicado.

Observação

A implantação e o serviço do gerenciador de roteamento permanecem em execução no namespace. Para remover a implantação e o serviço, execute os comandos a seguir para seu namespace.

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl delete service routingmanager-service -n NAMESPACE

Diagnóstico e registro em log

Ao usar o Bridge to Kubernetes para se conectar ao cluster, o computador registra o diagnóstico em log. Ele os armazena no diretório TEMP do computador de desenvolvimento na pasta Bridge to Kubernetes.

Autorização do RBAC do Kubernetes

O Kubernetes fornece RBAC (controle de acesso baseado em função) para gerenciar permissões para usuários e grupos. Para obter mais informações, consulte a documentação do Kubernetes. Você pode definir as permissões para um cluster habilitado para RBAC criando um arquivo YAML e usando kubectl para aplicá-lo ao cluster.

Para definir permissões no cluster, crie ou modifique um arquivo YAML, como permissions.yml. Use seu namespace para <namespace> e os usuários e grupos que precisam de acesso.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - kind: User
    name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: dev-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

Aplique as permissões usando o seguinte comando:

kubectl -n <namespace> apply -f <yaml file name>

Limitações

O Bridge to Kubernetes tem as seguintes limitações:

  • Um pod pode ter apenas um contêiner em execução nesse pod para que o Bridge to Kubernetes se conecte com êxito.
  • Atualmente, os pods do Bridge to Kubernetes precisam ser contêineres do Linux. Não há suporte para contêineres do Windows.
  • O Bridge to Kubernetes precisa de permissões elevadas para ser executado no computador de desenvolvimento para editar o arquivo de hosts.
  • O Bridge to Kubernetes não pode ser usado em clusters com o Azure Dev Spaces habilitado.

Próximas etapas

Para começar a usar o Bridge to Kubernetes para conectar o computador de desenvolvimento local ao cluster, confira Usar o Bridge to Kubernetes (VS) ou Usar o Bridge to Kubernetes (VS Code).