Compartilhar via

Como funciona a Ponte para Kubernetes

  • Artigo

Observação

A Microsoft planeja não manter mais ativamente o projeto Bridge to Kubernetes. Nos próximos meses, faremos a transição do projeto para um estado de arquivamento. Enquanto isso, o projeto ainda está disponível para uso e download. Durante esse período, esperamos explorar e recomendar projetos da comunidade que forneçam benefícios semelhantes ao Bridge to Kubernetes para seu uso futuro. Se você tiver dúvidas, entre em contato conosco em nosso quadro de problemas no GitHub.

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:

A animação mostra o isolamento, com dois desenvolvedores trabalhando com o mesmo 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:

Diagrama do cluster sem o 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.

Diagrama do cluster com o Bridge to Kubernetes habilitado.

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).