Migrar os Aplicativos Spring do Azure para o Serviço de Kubernetes do Azure
Observação
Os planos Básico, Standard e Enterprise serão preteridos a partir de meados de março de 2025, com um período de desativação de 3 anos. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para mais informações, confira o anúncio de desativação dos Aplicativos Spring do Azure.
O plano consumo e dedicado Standard será preterido a partir de 30 de setembro de 2024, com um desligamento completo após seis meses. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para mais informações, confira Migrar o plano dedicado e consumo Standard dos Aplicativos Spring do Azure para os Aplicativos de Contêiner do Azure.
Este artigo se aplica a:✅ Básico/Standard ✅ Enterprise
Este artigo fornece uma visão geral da migração dos Aplicativos Spring do Azure para o Serviço de Kubernetes do Azure (AKS).
Os Aplicativos Spring do Azure são uma solução PaaS (plataforma como serviço) projetada especificamente para aplicativos Spring Boot. Isso facilita a implantação, a execução e o gerenciamento desses aplicativos. Os Aplicativos Spring do Azure cuidam da infraestrutura, do dimensionamento e do monitoramento, para que os desenvolvedores possam se concentrar em seu código.
O AKS é uma oferta de IaaS (infraestrutura como serviço) que fornece um ambiente do Kubernetes totalmente gerenciado. O AKS oferece mais controle sobre como seus aplicativos são implantados e gerenciados. Ele dá suporte a uma ampla gama de aplicativos em contêineres e permite que a personalização atenda às necessidades específicas.
Migrar aplicativos dos Aplicativos Spring do Azure para o AKS significa migrar de um ambiente gerenciado para um que oferece mais flexibilidade. Esse processo requer a adoção de novas ferramentas e práticas para obter os mesmos resultados no AKS que você teve com os Aplicativos Spring do Azure.
Mapeamento de conceito
Como os Aplicativos Spring do Azure e o AKS são diferentes tipos de ofertas de serviço de nuvem, não é totalmente preciso para mapear os conceitos dos Aplicativos Spring do Azure diretamente para o AKS. Além disso, os Aplicativos Spring do Azure dependem de muitos componentes internos quando usados em ambientes de produção, que não estão listados aqui. O diagrama e a tabela a seguir fornecem um mapeamento simples de conceitos dos Aplicativos Spring do Azure para o AKS para ajudar você a entender as noções básicas. Em um ambiente de produção real, você deve considerar as soluções mais seguras e confiáveis.
| Excluir o serviço dos Aplicativos Spring do Azure | Serviço de Kubernetes do Azure |
|---|---|
| Uma Instância de serviço hospeda e protege um limite para aplicativos e outros recursos e oferece suporte a uma rede virtual personalizada. | Um Cluster é a unidade básica de implantação. Em um cluster, um Namespace é uma subdivisão virtual usada para organizar e isolar recursos. Ele compartilha a mesma infraestrutura de rede subjacente definida pela rede virtual do cluster. Escolher entre um cluster dedicado ou um cluster compartilhado com namespaces depende de suas necessidades comerciais. |
| Um Aplicativo é um aplicativo de negócios que serve como um recurso filho em uma instância de serviço. | Um Aplicativo de negócios é um conceito virtual nos Aplicativos Spring do Azure e é composto por vários recursos no AKS. A Entrada controla o acesso externo aos serviços e define as regras para o roteamento de tráfego para serviços diferentes. Um Serviço abstrai o acesso a um conjunto de pods. Você pode executar uma opção de implantação azul-verde atualizando um serviço para apontar para uma versão diferente de uma implantação usando rótulos. |
| Uma Implantação é a versão de um aplicativo. Um aplicativo pode ter uma implantação de produção e uma implantação de preparo. | Uma Implantação gerencia a distribuição e o ciclo de vida de um aplicativo ou serviço específico. Também permite atualizações e reversões contínuas, possibilitando alterações controladas no aplicativo de conexão remota, sem tempo de inatividade. |
| Uma Instância de aplicativo é a unidade de runtime mínima gerenciada pelo serviço. | Um Pod representa um ou mais contêineres firmemente acoplados e hospeda uma única instância de um aplicativo ou carga de trabalho em execução. |
Considerações de rede
Antes de provisionar um cluster do AKS, é importante considerar cuidadosamente as configurações de rede. Essas decisões podem afetar significativamente o desempenho, a escalabilidade e a segurança de seus aplicativos.
O AKS depende de plug-ins da CNI (Interface de Rede de Contêiner) para gerenciar a rede em seus clusters. Esses plug-ins lidam com tarefas críticas, como atribuir endereços IP a pods, rotear o tráfego entre eles e habilitar a comunicação por meio dos Serviços do Kubernetes. O AKS dá suporte a vários plug-ins de CNI adaptados às diferentes necessidades de rede, fornecendo flexibilidade no design do cluster.
O AKS oferece dois modelos principais de rede: redes de sobreposição e redes planas. As redes de sobreposição atribuem endereços IP privados a pods, separados da sub-rede da Rede Virtual do Azure dos nós do AKS. Esse modelo é escalonável e conserva endereços IP de rede virtual, mas usa a NAT (Conversão de Endereços de Rede) para o tráfego que sai do cluster. Por outro lado, as redes planas atribuem endereços IP de pod diretamente da mesma sub-rede da Rede Virtual do Azure que os nós, permitindo que serviços externos acessem os pods sem a NAT. Embora as redes planas habilitem a comunicação direta do pod, elas exigem um espaço de endereços IP de rede virtual mais amplo.
O planejamento de IP adequado é essencial para uma operação tranquila do AKS. É importante garantir que as sub-redes tenham endereços IP suficientes para todos os recursos, evitar intervalos sobrepostos e deixar espaço para crescimento futuro para evitar problemas de conectividade e interrupções. Para obter mais informações, confira Visão geral da rede CNI do Serviço de Kubernetes do Azure.
Para lidar com o tráfego de entrada no AKS, você pode usar balanceadores de carga ou controladores de entrada. Os balanceadores de carga operam na Camada 4, distribuindo tráfego com base em protocolos e portas, enquanto os controladores de entrada funcionam na Camada 7, oferecendo recursos avançados, como roteamento baseado em URL e a terminação de TLS/SSL. Os controladores de entrada reduzem a necessidade de vários IPs públicos gerenciando o tráfego para vários aplicativos por meio de um único IP. Para os aplicativos Web, os controladores de entrada são preferenciais, pois fornecem melhor gerenciamento de tráfego e integração com os recursos do Kubernetes. Para obter mais informações, confira Entrada do NGINX gerenciada com o complemento de roteamento de aplicativos.
Para proteger o tráfego de rede no AKS, use o WAF (Firewalls de Aplicativo Web) como o Gateway de Aplicativo do Azure para proteger contra ataques como cross-site scripting e cookie poisoning, ao mesmo tempo em que gerencia o roteamento de tráfego e a terminação de TLS/SSL. Além disso, implemente políticas de rede para controlar a comunicação entre pods definindo regras em manifestos YAML, com base em rótulos, namespaces ou portas. Essas políticas, que estão disponíveis apenas para os nós baseados em Linux, garantem um melhor controle de tráfego e segurança dentro do cluster. Para mais informações, consulte Proteger o tráfego entre os pods usando as políticas de rede no AKS.
Provisionar o
Para provisionar um cluster do AKS, você pode usar o portal do Azure, a CLI do Azure ou os modelos do ARM. O processo normalmente envolve selecionar a região desejada, definir o tamanho e o tipo do pool de nós e escolher o modelo de rede: CNI do Azure ou Kubenet. Você também deve configurar as opções de autenticação, como a integração do Microsoft Entra ID para controle de acesso do usuário. Para monitoramento e dimensionamento, você pode habilitar o Azure Monitor e configurar o dimensionamento automático com base no uso de recursos. Após o provisionamento, você pode gerenciar o cluster usando kubectl ou a CLI do Azure. Para obter instruções detalhadas sobre o provisionamento do AKS, visite Criar um cluster do AKS.
Acesso e identidade
O AKS oferece várias maneiras de gerenciar a autenticação, a autorização e o controle de acesso para os clusters do Kubernetes. Você pode usar o RBAC (controle de acesso baseado em função) do Kubernetes para conceder aos usuários, grupos e contas de serviço acesso somente aos recursos necessários. Para obter mais informações, consulte Usando a autorização do RBAC. O AKS também dá suporte ao Microsoft Entra ID e ao RBAC do Azure para melhorar a segurança e o controle, permitindo que você atribua e gerencie permissões de maneira mais simplificada.
Para obter melhor segurança, recomendamos integrar o AKS ao Microsoft Entra ID. Essa integração usa protocolos OpenID Connect e OAuth 2.0 para autenticação. Os usuários se autenticam usando as credenciais do Microsoft Entra ao interagir com o cluster do AKS, com suas permissões de acesso regidas pelo administrador do cluster. Para obter mais informações, confira Habilitar a autenticação de identidade gerenciada do Azure para clusters do Kubernetes com kubelogin
A ID de Carga de Trabalho do Microsoft Entra integra os recursos nativos do Kubernetes com os provedores de identidade externos por meio da federação OIDC (OpenID Connect). Ela usa a Projeção de Volume de Token da Conta de Serviço para atribuir as identidades do Kubernetes a pods por meio de contas de serviço anotadas. Com esses tokens, os aplicativos do Kubernetes podem autenticar e acessar recursos do Azure com segurança usando o Microsoft Entra ID. Essa configuração funciona perfeitamente com bibliotecas como as bibliotecas de clientes do Azure Identity (Azure.Identity) ou a MSAL (Biblioteca de Autenticação da Microsoft) para simplificar a autenticação de suas cargas de trabalho. Para saber como configurar um cluster e configurar seu pod de aplicativo com identificação de cargas de trabalho, confira Implantar e configurar a identidade da carga de trabalho.
Colocar aplicativos em contêineres
A conteinerização de aplicativos em imagens de contêiner é essencial para implantação no AKS. Ela garante que as implantações sejam consistentes, portáteis e escalonáveis. O uso de imagens de contêiner oferece flexibilidade no gerenciamento de diferentes versões de aplicativos. Isso facilita as atualizações e reversões e melhora a eficiência dos recursos, permitindo que vários contêineres sejam executados em um único host.
Os Aplicativos Spring do Azure ajudam os usuários a criar imagens de contêiner e implantar aplicativos de diferentes maneiras. Você pode implantar a partir do código-fonte, de artefatos criados como arquivos JAR ou WAR ou diretamente de uma imagem de contêiner. Para saber como implantar em um arquivo JAR ou WAR, confira Criar uma imagem de contêiner de um JAR ou WAR. Para saber como implantar no código-fonte, confira Containerizar um aplicativo usando Paketo Buildpacks.
Para monitorar o desempenho de aplicativos implantados no AKS, você pode integrar o agente do APM (Monitoramento de Desempenho de Aplicativos) durante o processo de conteinerização. Para obter mais informações, confira Integrar o monitoramento de desempenho do aplicativo em imagens de contêiner.
Implantar aplicativos e componentes do Spring Cloud
Para implantar aplicativos no AKS, você pode usar as Implantações, que são usadas pelos Aplicativos Spring do Azure ou StatefulSets, dependendo das necessidades do seu aplicativo. Para aplicativos sem monitoração de estado, como microsserviços, você normalmente usaria uma Implantação, que gerencia as réplicas do seu aplicativo e garante que elas funcionem sem problemas. Esse tipo é usado pelos Aplicativos Spring do Azure. Por outro lado, os StatefulSets são ideais para aplicativos que exigem armazenamento persistente ou identidades estáveis, como bancos de dados ou serviços com necessidades de estado.
Junto com a implantação do aplicativo, você também precisa definir um Serviço para expor seus pods de back-end. Um serviço é uma abstração que permite definir um conjunto lógico de pods e habilitar o acesso de rede a eles. Essa funcionalidade é crucial para o balanceamento de carga e a comunicação entre pods.
Ao implantar os componentes do Spring Cloud, como o Spring Cloud Config ou o Spring Cloud Gateway, você geralmente usaria as Implantações para os serviços sem estado. Para os serviços de back-end que precisam de armazenamento ou estado estáveis, você pode escolher StatefulSets.
Os links a seguir fornecem exemplos de referência de imagens de contêiner e arquivos de manifesto para os Componentes do Spring Cloud:
Monitorar
O monitoramento é uma parte crucial do gerenciamento de aplicativos implantados no AKS. O AKS fornece uma variedade de ferramentas para acompanhar e analisar o status do cluster e das cargas de trabalho, incluindo soluções integradas como o Azure Monitor, o Azure Log Analytics e o Prometheus. Para obter mais informações, consulte os seguintes artigos:
- Prometheus gerenciado para a coleta de métricas.
- Insights de contêineres para coleta de logs
- Espaço Gerenciado do Azure para Grafana para visualização.
Além do Azure Monitor e do Prometheus, você também pode usar outras soluções de monitoramento, como Datadog, New Relic ou ELK (Elastic Stack). Você pode integrar essas ferramentas ao AKS para coletar logs, métricas e rastreamentos, oferecendo várias informações sobre o desempenho do cluster.
Tutorial
Fornecemos um tutorial para demonstrar a experiência de ponta a ponta da execução do aplicativo da loja ACME Fitness no AKS. Para obter mais informações, confira acme-fitness-store/azure-kubernetes-service. Este tutorial fornece diretrizes práticas e serve como referência. O AKS é altamente flexível, portanto, você precisa escolher as configurações e personalizações com base em seus requisitos específicos.