Padrões de implantação heterogênea com 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, você pode 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 deixa de ser íntegro, ele para de enviar atualizações de status íntegras, e o mecanismo DNS pode deslocar o tráfego para as implantações que ainda sã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. Use provedores de serviços de infraestrutura de DNS, como NS1, Dyn, Akamai e outros, para direcionar o tráfego a várias implantações.

Manipulação de 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.

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

Definir o tipo de serviço como NodePort 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. Além de fornecer a configuração da porta em cada nó, a definição do tipo como LoadBalancer provisiona automaticamente um balanceador de carga externo e o configura para direcionar o tráfego para o cluster e os 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. A Entrada, um mecanismo de balanceamento de carga HTTP(S) (Camada 7), é um conjunto de regras que permitem 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, você pode conectar as redes subjacentes em cada implantação usando peering direto ou interconexões de rede gerenciadas por terceiros. O GCP oferece conectividade direta por meio de peering imediatamente 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 Google 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.

Depois que a conectividade estiver em vigor, o próximo passo será garantir o vínculo entre cada ambiente usando a VPN. Em cada implantação, você precisa de um gateway de VPN para proteger o tráfego entre as implantações. No GCP, o Google Cloud VPN protege o tráfego 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 Google 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ço

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. Você pode configurar o acesso a domínios "stub" particulares usando ConfigMap. Você pode usar a compatibilidade do Kubernetes a fim de 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 de dados no local dianteiros, você precisa de 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. No GCP, o Cloud VPN protege o tráfego com 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 no caso da infraestrutura dianteira de dados no local, é necessário configurar rotas e firewalls locais para permitir o tráfego somente de conjuntos específicos de instâncias do GCP.

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 GCP, o Cloud Load Balancing é compatível com HTTP(S), TCP e UDP com um único IP anycast globalmente disponível.

Em cenários híbridos como esses, implante pods e serviços no GKE, uma implantação gerenciada do Kubernetes disponível no GCP. O GKE 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ço

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. Com o tempo, outros aplicativos de nuvem que aproveitam componentes diferentes da API CRUD local podem ser implantados. A API CRUD pode adicionar funcionalidades ao longo do tempo, como APIs específicas de tarefas ou APIs que comandam a infraestrutura adicional 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 aplicativos de nuvem somente no GKE ou no Kubernetes, é possível configurar o mecanismo DNS interno do Kubernetes, kube-dns, para resolver domínios DNS particulares para endereços IP particulares 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 utilizadas com o GCP são Jenkins e 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 canais podem ser iniciados manualmente ou por meio de acionadores automáticos, como sistemas de CI externos, scripts cron ou outros canais. 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 canais 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 informações sobre a implantação do Spinnaker no GCP, 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 canais. 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 GCP 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, com compatibilidade para sequenciamento gradual e simultaneidade. As alterações de estado no processo de criação são publicadas automaticamente em um tópico do Cloud 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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…