Padrões de implantação heterogênea com o Kubernetes

Neste artigo, descrevemos os padrões comuns para criar implantações heterogêneas de nível de produção usando o Kubernetes. Vamos analisar três casos de uso e descrever os detalhes arquitetônicos que você pode usar para criar implantações para eles. As descrições arquitetônicas incluem o Kubernetes em geral e o Google Kubernetes Engine (GKE) em particular.

Implantações heterogêneas

Geralmente, as implantações heterogêneas envolvem a conexão de dois ou mais ambientes ou regiões de infraestrutura diferentes para atender a uma necessidade técnica ou operacional específica. As implantações heterogêneas são chamadas de "híbridas", "de várias nuvens" ou "públicas-particulares", dependendo das características específicas delas. Para os propósitos deste artigo, as implantações heterogêneas incluem aquelas que abrangem regiões dentro de um único ambiente de nuvem, vários ambientes de nuvem pública (várias nuvens) ou uma combinação de ambientes de nuvem locais e públicos (híbridos ou públicos-particulares).

Vários desafios comerciais e técnicos podem surgir em implantações que se limitam a um único ambiente ou região:

  • Recursos esgotados: em qualquer ambiente único, particularmente em ambientes locais, talvez os recursos de computação, rede e armazenamento não atendam às suas necessidades de produção.
  • Alcance geográfico limitado: as implantações em um único ambiente exigem que pessoas geograficamente distantes umas das outras acessem uma implantação. O tráfego delas pode viajar ao redor do mundo até um local central.
  • Disponibilidade limitada: os padrões de tráfego na escala da Web desafiam os aplicativos a permanecerem tolerantes a falhas e resilientes.
  • Aprisionamento tecnológico: a plataforma do fornecedor e as abstrações da infraestrutura podem impedi-lo de portar aplicativos.
  • Recursos inflexíveis: seus recursos podem ser limitados a um determinado conjunto de ofertas de computação, armazenamento ou rede.

As implantações heterogêneas podem ajudar a superar esses desafios, mas precisam ser projetadas por meio de processos e procedimentos programáticos e deterministas. Procedimentos de implantação únicos ou ad-hoc podem tornar as implantações ou os processos frágeis e intolerantes a falhas. Os processos ad-hoc podem perder dados ou sofrer queda de tráfego. Os bons processos de implantação precisam ser repetíveis e usar abordagens comprovadas para gerenciar o aprovisionamento, a configuração e a manutenção.

Três cenários comuns de implantação heterogênea são implantações de várias nuvens, infraestrutura dianteira de dados no local e processos de integração contínua/entrega contínua (CI/CD, na sigla em inglês).

Nas seções a seguir, descrevemos alguns casos de uso comuns para implantações heterogêneas, juntamente com abordagens bem projetadas usando o Kubernetes e outros recursos de infraestrutura.

Várias nuvens

As implantações de várias nuvens, em que todas as implantações são relativamente semelhantes, são alguns dos padrões de implantação heterogênea mais comuns usados ​​com o Kubernetes.

Um uso das implantações de várias nuvens envolve a escolha do direcionamento do tráfego. Nas implantações mais simples, você pode enviar porcentagens específicas de tráfego de entrada para determinadas implantações. Nas implantações criadas com base em infraestruturas locais e de nuvem pública, você pode enviar mais tráfego à infraestrutura de nuvem, seja para facilitar uma migração de longo prazo ou para compensar recursos locais restritos.

Outro uso comum das implantações de várias nuvens é a configuração de uma implantação altamente disponível, capaz de suportar a falha de qualquer ambiente único. Nesses cenários, você pode orquestrar a mesma implantação do Kubernetes em cada um dos ambientes desejados. Cada implantação precisa ser capaz de aumentar o escalonamento para atender às necessidades de todo o tráfego, caso haja falha em um ambiente único.

Por fim, use várias nuvens para criar implantações fisicamente mais próximas dos usuários. Colocar implantações o mais próximas possível dos usuários finais pode minimizar a latência de solicitação e resposta.

Direcionamento de tráfego

Uma implantação robusta de várias nuvens usa um serviço de gerenciamento de tráfego DNS a fim de resolver consultas DNS para as implantações individuais. Para casos de uso gerais de divisão de tráfego, é possível configurar mecanismos de gerenciamento de tráfego DNS para dividir o tráfego em porcentagens nas implantações individuais.

Divisão de tráfego

Para implantações altamente disponíveis, configure o mecanismo DNS usando verificações de integridade personalizadas de cada ambiente. Quando um ambiente se torna não íntegro, ele para de enviar atualizações de status íntegras e envia atualizações de status não íntegras, e o mecanismo DNS pode transferir o tráfego para implantações que ainda estão íntegras.

Quando a latência para o usuário é crítica, os mecanismos DNS podem usar o endereço IP de uma solicitação de entrada a fim de determinar a localização aproximada e, em seguida, direcionar o tráfego para a implantação mais próxima dessa região geográfica. É possível usar provedores de serviços de infraestrutura de DNS, como NS1, Dyn, Akamai e outros, para rotear o tráfego em várias implantações.

Como processar solicitações

À medida que o DNS direciona o tráfego para implantações específicas, um balanceador de carga precisa receber solicitações de entrada e, em seguida, direcioná-las a um cluster do Kubernetes. O Kubernetes oferece dois mecanismos para expor pods ao tráfego de entrada: Serviços e Entrada.

Quando os pods são implantados em um cluster do Kubernetes, eles não são facilmente acessíveis a outros aplicativos ou sistemas dentro ou fora do cluster. Para tornar os pods acessíveis, você precisa primeiro criar um serviço. Por padrão, um serviço aceita automaticamente conexões de dentro do cluster, mas também pode ser configurado para aceitar conexões de fora dele.

Se você quiser configurar um serviço para aceitar solicitações externas, defina o tipo de serviço como NodePort ou LoadBalancer.

Ao definir o tipo como NodePort, você expõe uma porta exclusiva para cada serviço em todos os nós no cluster do Kubernetes. Essa porta exclusiva permite que cada nó aceite conexões e solicitações de entrada de balanceamento de carga do proxy para os pods apropriados.

O tipo de serviço LoadBalancer é um superconjunto do NodePort. Ao definir o tipo como LoadBalancer, além de incluir a configuração de porta em cada nó, você provisiona automaticamente um balanceador de carga externo e o configura para direcionar o tráfego ao cluster e aos pods subsequentes.

Os serviços no Kubernetes são uma construção de Camada 4, o que significa que podem ser compatíveis com a acessibilidade somente por meio do uso de endereços IP e números de porta. Entrada, um mecanismo de balanceamento de carga HTTP(S) (Camada 7), é um conjunto de regras que permite que as conexões de entrada acessem os serviços de cluster do Kubernetes de back-end. É possível configurar o mecanismo Entrada para oferecer outras funcionalidades de camada de aplicativo aos Serviços, como URLs externamente acessíveis, balanceamento de carga de tráfego de entrada, terminação SSL ou hospedagem virtual baseada em nomes. O tráfego de entrada pode ser direcionado para pods, exposto por meio de serviços, usando cabeçalhos de host HTTP ou caminhos de URL HTTP.

Tráfego direcionado para pods

Serviços compartilhados

Quando você executa implantações de várias nuvens, talvez seja necessário executar um ou mais serviços compartilhados, como um banco de dados, em cada implantação. A comunicação entre os serviços compartilhados precisa ser segura e de baixa latência.

Para conectividade de baixa latência e alta largura de banda, conecte as redes subjacentes em cada implantação usando peering direto ou interconexões de rede gerenciadas por terceiros. O Google Cloud oferece conectividade por meio de peering direto com o Google em qualquer um dos locais de extremidade de rede disponíveis. Para facilitar o peering direto, há uma série de requisitos técnicos. Quando não é possível atender a esses requisitos, outra opção é o Cloud Interconnect. Use os provedores de serviços do Cloud Interconnect para se conectar à extremidade da rede do Google com conectividade de nível empresarial.

Quando a conexão estiver pronta, a próxima etapa é proteger o link entre cada ambiente usando a VPN. Você precisa de um gateway de VPN em cada implantação para proteger o tráfego entre as implantações. O Cloud VPN faz isso no Google Cloud usando uma conexão VPN IPSec. O Cloud VPN é compatível com vários túneis VPN para agregar largura de banda e permite roteamento estático ou dinâmico por meio do Cloud Router.

Gerenciamento de cluster

Na implantação de várias nuvens, você pode administrar e controlar cada cluster do Kubernetes como uma entidade individual. Para fazer isso, você precisa criar manualmente os pods e serviços em cada cluster. O benefício disso é que, mesmo que cada implantação tenha alguns aplicativos e serviços compartilhados, ela também pode ter aplicativos e serviços adequados apenas para si.

Por exemplo, talvez seja necessário que suas implantações sejam distribuídas geograficamente, mas pode haver serviços específicos de país ou região que não são apropriados para todos os locais geográficos.

As implantações em que a divisão do tráfego está distribuída de modo desigual podem precisar implantar pods e serviços por cluster para garantir que as solicitações e o tráfego de entrada sejam tratados adequadamente.

Descoberta de serviços

As implantações de várias nuvens precisam usar a descoberta de serviços para garantir que aplicativos e serviços diferentes possam se encontrar facilmente no ambiente de execução. A descoberta de serviços elimina a necessidade de esquemas ou convenções de nomeação complexos ou frágeis, que podem precisar ser conhecidos antes da implantação. Os mecanismos de descoberta de serviços precisam ser transparentes para os aplicativos de origem e destino. Em implantações de várias nuvens, esses mecanismos precisam permitir que aplicativos e serviços descubram serviços em execução local e remotamente em outros clusters.

Em implantações projetadas e implantadas como clusters individuais autônomos, os mecanismos de descoberta de serviços precisam reconhecer data centers. Ou seja, eles precisam ser capazes de operar como sistemas distribuídos coordenados, com a capacidade de enviar solicitações para o cluster apropriado com base na solicitação de entrada, disponibilidade local e capacidade de carga. Sistemas de terceiros, como Consul, Linkerd, e outros, podem facilitar a detecção de serviços entre clusters e entre ambientes com as implantações do Kubernetes em várias nuvens.

O Kubernetes oferece compatibilidade com a resolução de zonas DNS particulares no cluster do Kubernetes. Essa compatibilidade é útil em cenários híbridos ou de várias nuvens em que os nomes de domínio totalmente qualificados dos outros clusters são conhecidos, e o tráfego pode ser facilmente encaminhado para eles. É possível configurar o acesso a domínios de stub particulares usando ConfigMap. O uso da compatibilidade do Kubernetes é possível para resolver zonas DNS particulares como um mecanismo autônomo para enviar solicitações a clusters específicos do Kubernetes, ou em conjunto com sistemas externos, como o Consul.

Arquitetura

No diagrama a seguir, mostramos um exemplo de arquitetura de implantação de várias nuvens.

Implantação de várias nuvens

Infraestrutura dianteira de dados no local

É possível projetar suas implantações de nuvem para ampliar recursos além dos que estão disponíveis em suas implantações particulares ou locais. Por exemplo: projetar e implantar aplicativos baseados em nuvem capazes de acessar infraestruturas ou sistemas de dados particulares.

Lembre-se de que as implantações particulares ou locais podem ser limitadas no que diz respeito a disponibilidade, portabilidade ou flexibilidade de recursos. A migração para implantações baseadas em nuvem pode resolver essas limitações, mas isso pode não ser possível devido a arquiteturas legadas, conformidade de segurança ou outros requisitos de software. Em tais cenários, é possível criar e implantar novos aplicativos em ambientes de nuvem que tenham maior flexibilidade ou capacidade do que os ambientes particulares ou locais.

Arquitetura

No diagrama a seguir, mostramos um exemplo de arquitetura com uma infraestrutura dianteira de dados no local de aplicativos de nuvem.

Infraestrutura dianteira de dados no local

Rede

Para implantações em que os aplicativos de nuvem são uma infraestrutura dianteira de dados no local, é necessária conectividade segura e de baixa latência para minimizar o tempo total de resposta do aplicativo aos usuários finais. Use o Cloud Interconnect ou o peering direto para minimizar a latência e maximizar a largura de banda disponível entre os ambientes locais e de nuvem. Depois que a conectividade é estabelecida, cada implantação precisa ter um gateway de VPN para proteger o tráfego entre elas. O Cloud VPN faz isso no Google Cloud usando uma conexão VPN IPSec. O Cloud VPN é compatível com vários túneis VPN para agregar largura de banda e permite roteamento estático ou dinâmico por meio do Cloud Router. Como a segurança é uma preocupação crítica ao criar a infraestrutura principal de dados local, configure rotas e firewalls locais para permitir o tráfego apenas de conjuntos específicos de instâncias do Google Cloud.

Arquitetura da nuvem

Na parte de nuvem dessas implantações híbridas, os componentes da arquitetura precisam incluir um balanceador de carga apropriado, uma infraestrutura de hospedagem de aplicativos, um gateway VPN e um mecanismo de descoberta de serviço. A escolha do balanceador de carga dependerá dos requisitos dos aplicativos voltados ao usuário final. Para implantações no Google Cloud, o Cloud Load Balancing oferece suporte para HTTP(S), TCP e UDP com um único IP Anycast disponível globalmente.

Em cenários híbridos como esses, é possível implantar pods e serviços no GKE, uma implantação gerenciada do Kubernetes disponível no Google Cloud. que direciona o tráfego de saída para a infraestrutura local. Ele usa o Cloud VPN para proteger o tráfego e o Cloud Router para configurar rotas estáticas ou dinâmicas. Essa configuração garante que somente o tráfego do cluster do GKE seja transferido por conexão VPN.

Arquitetura local

A parte local dessa implantação contém a infraestrutura de dados que faz o backup dos aplicativos na nuvem. Para a maioria das implantações desta natureza, implantar uma API CRUD na frente dos sistemas de dados oferece vários benefícios.

Se os sistemas de dados exigirem níveis elevados de segurança ou conformidade, uma API CRUD poderá ser útil para ajudar na auditoria e no registro de conexões e consultas de entrada. Se a infraestrutura de dados for executada em um sistema legado, uma API CRUD poderá ajudar a fornecer opções de conectividade mais modernas para aplicativos mais recentes.

Nos dois casos, a API CRUD pode ajudar a desacoplar mecanismos de autorização e autenticação de banco de dados incorporados daqueles necessários aos aplicativos e fornecer a quantidade da funcionalidade de CRUD que os aplicativos exigem. Especificamente, se for necessário expor apenas um subconjunto de dados a aplicativos de recebimento de dados, uma API pode ser útil para gerenciar o acesso aos dados.

Por meio de auditorias de conexões e consultas, a API também pode ajudar a definir a estratégia de migração de longo prazo dos dados subjacentes. Se apenas um subconjunto de dados for necessário e não se enquadrar nas políticas rigorosas de segurança ou conformidade, esses dados poderão ser migrados para plataformas em nuvem.

O diagrama de arquitetura acima mostra a API CRUD hospedada no Kubernetes executado no local. O uso do Kubernetes no local não é tecnicamente necessário, mas oferece vantagens: à medida que mais equipes consideram o Kubernetes um destino de implantação na infraestrutura de nuvem, elas podem se beneficiar com o desenvolvimento de mais conhecimento sobre o uso e a operação do sistema.

A infraestrutura local precisa configurar o gateway de VPN e quaisquer firewalls para permitir que o tráfego acesse a API CRUD apenas de fontes conhecidas, para minimizar possíveis problemas de segurança.

Descoberta de serviços

Em cenários de implantação híbrida, você precisa usar a descoberta de serviços para garantir que diferentes aplicativos e serviços possam se conectar facilmente no ambiente de execução. Posteriormente, poderão ser implantados outros aplicativos de nuvem que utilizam diferentes componentes da API CRUD local. Essa API pode adicionar outras funcionalidades ao longo do tempo, como APIs específicas a tarefas ou que criam outras infraestruturas principais de dados no local. Nesses tipos de cenários de implantação, o ciclo de lançamento dos aplicativos de nuvem pode ser bem diferente da funcionalidade CRUD local. Usar um mecanismo externo de detecção de serviços, como o Consul ou o Linkerd, pode fornecer um acoplamento flexível de recursos e versões, para que possam iterar de maneira independente em cada ambiente.

Se você planeja implantar apps em nuvem apenas no GKE ou no Kubernetes, pode configurar o mecanismo DNS interno do Kubernetes kube-dns a fim de resolver domínios DNS particulares para endereços IP privados no ambiente local. Nessa configuração, os pods em execução no ambiente de nuvem podem usar consultas DNS padrão para acessar os serviços em execução no ambiente local com facilidade. Para mais informações, consulte Como configurar zonas DNS particulares e servidores de nomes de upstream no Kubernetes.

Cargas de trabalho CI/CD

As cargas de trabalho de várias nuvens iniciadas de implantações locais existentes podem se beneficiar da migração de cargas de trabalho mais focadas para ambientes de nuvem.

As cargas de trabalho de integração contínua (CI, na sigla em inglês) são boas candidatas para a migração, porque a capacidade dos ambientes de nuvem de escalonar automaticamente os recursos de computação pode ajudar a reduzir o tempo da conclusão do código até os artefatos criados.

As cargas de trabalho de entrega contínua (CD, na sigla em inglês) também podem se beneficiar da execução em ambientes de nuvem, o que permite aprovisionamento e implantação mais fáceis de ambientes de teste. A migração pode aumentar o número de processos de criação paralelos para testes de unidade. Outro possível benefício é o aumento do número de implantações de teste para testes de integração completa e outros testes automatizados.

Normalmente, as cargas de trabalho CI/CD baseadas em nuvem e centradas em contêineres usam o seguinte processo de alto nível:

  • Desenvolvimento. Os desenvolvedores confirmam e enviam alterações de código para repositórios de origem locais ou hospedados remotamente.
  • Criação. Um serviço de criação pesquisa continuamente o repositório de código-fonte. Ao detectar novas mudanças, o serviço inicia o processo de criação.
  • Teste de unidade. O processo cria a fonte, executa testes de unidade e cria uma imagem de contêiner resultante.
  • Teste de integração. O processo cria um cluster de teste, implanta a imagem do contêiner com os respectivos artefatos associados e executa testes de integração.
  • Preparação. Após a conclusão bem-sucedida, as imagens do contêiner são marcadas com os metadados da versão de lançamento.
  • Implantação. Como medida opcional, os desenvolvedores ou administradores podem implantar novos artefatos para produção.

Casos de uso

As ferramentas de CI/CD mais usadas com o Google Cloud são o Jenkins e o Spinnaker. Jenkins é um sistema conhecido de CI/CD de código aberto que pode ser implantado em instâncias de computação autônomas ou como uma série de pods e serviços no Kubernetes. Spinnaker é um sistema de CD de código aberto capaz de orquestrar e automatizar a entrega de software para vários destinos. Ele pode aproveitar os sistemas CI, como Jenkins, ou outras ferramentas, como o Cloud Build.

Jenkins e Kubernetes

Para cargas de trabalho CI/CD que usam Jenkins com o Kubernetes, consulte a documentação a seguir, que revisa as práticas recomendadas, os padrões comuns de configuração e a orquestração da entrega contínua:

Spinnaker

O Spinnaker é uma plataforma de CD de várias nuvens de código aberto que pode orquestrar fluxos de trabalho de implantação de software e gerenciamento de cluster. Os recursos de gerenciamento de cluster do Spinnaker oferecem a capacidade de provisionar e controlar recursos da nuvem, como grupos de instâncias, instâncias, firewalls e balanceadores de carga. Os fluxos de trabalho de implantação de software consistem em canais, e cada um é composto por uma sequência de ações, chamadas de estágios. Um estágio em um pipeline do Spinnaker pode passar parâmetros para o próximo estágio. Os pipelines podem ser iniciados manualmente ou por meio de acionadores automáticos, como sistemas de CI externos, scripts cron ou outros pipelines. O Spinnaker vem com vários estágios predefinidos para preparar e implantar imagens, trabalhar com grupos de instâncias e solicitar a entrada do usuário. Na imagem a seguir, descrevemos como os pipelines do Spinnaker lançam o software.

Pipeline do Spinnaker

O software é criado e depois testado. Se ele for aprovado em todos os testes, uma imagem imutável é preparada e fica disponível na nuvem. Quando a imagem está disponível, ela pode ser implantada em clusters para atualizar o software em execução.

Arquitetura

Ao trabalhar com implantações de contêiner, o Spinnaker aproveita os sistemas de CI externos, como Jenkins ou Cloud Build, para executar as etapas de criação, teste e preparação. O Spinnaker orquestra a implantação de destino usando estágios de pipeline padrão. Na imagem a seguir, mostramos a arquitetura desse sistema.

Spinnaker com Jenkins

Para mais informações sobre como implantar o Spinnaker no Google Cloud, consulte Como executar o Spinnaker no Compute Engine.

Criação com o Jenkins

O Jenkins funciona bem com a compatibilidade do Spinnaker para os acionadores iniciarem pipelines. Você pode usar as criações do Jenkins para acionar automaticamente os canais do Spinnaker. Em um pipeline do Spinnaker, os estágios do script de Jenkins podem executar os estágios de teste e preparação do processo de lançamento. Os estágios incorporados de gerenciamento de cluster do Spinnaker podem orquestrar a implantação de destino. Para mais informações, consulte o exemplo da Implantação do Spinnaker Hello.

Como criar com o Cloud Build

O Cloud Build é um serviço do Google Cloud totalmente gerenciado que cria imagens de contêiner em um ambiente rápido, consistente e confiável. O Cloud Build integra-se diretamente ao Cloud Source Repositories para acionar construções automaticamente com base em alterações feitas em fontes ou tags de repositório. O Cloud Build executa criações em contêineres do Docker e pode ser compatível com qualquer etapa de criação personalizada que possa ser empacotada em um contêiner. As criações no Cloud Build são altamente personalizáveis e compatíveis com sequenciamento gradual e simultaneidade. As alterações de estado no processo de compilação são publicadas automaticamente em um tópico do Pub/Sub.

O Spinnaker não é compatível diretamente com o Cloud Build, mas ele oferece compatibilidade com o Container Registry, o registro de contêiner usado automaticamente pelo Cloud Build. É possível configurar o Spinnaker para pesquisar o Container Registry e iniciar o canal com base na detecção de versões ou tags de imagem de contêiner atualizadas. Nesses cenários, configure o Cloud Build para executar os estágios de criação, teste e preparação do processo de lançamento. Leia os detalhes sobre a configuração do Spinnaker para usar o Container Registry na documentação do Spinnaker.

Orquestração de implantações do Kubernetes

Os mecanismos incorporados de gerenciamento de cluster do Spinnaker são compatíveis com o Kubernetes. Os Grupos de servidores e os Balanceadores de carga no Spinnaker correspondem aos Conjuntos de réplicas e aos Serviços no Kubernetes, respectivamente.

Na documentação a seguir, revisamos as etapas necessárias para configurar o Spinnaker a fim de implantar pods e serviços no Kubernetes:

A seguir