Partilhar via

Migre sua carga de trabalho do Service Fabric para o AKS

  • Artigo

Muitas organizações migram para aplicativos em contêineres como parte de um esforço para adotar o desenvolvimento moderno de aplicativos, práticas recomendadas de manutenção e arquiteturas nativas da nuvem. Como as tecnologias continuam a evoluir, as organizações devem avaliar as muitas plataformas de aplicativos em contêineres disponíveis na nuvem pública.

Não há uma solução única para aplicativos, mas as organizações geralmente descobrem que o Serviço Kubernetes do Azure (AKS) atende aos requisitos de muitos de seus aplicativos em contêineres. O AKS é um serviço Kubernetes gerenciado que simplifica as implantações de aplicativos via Kubernetes gerenciando o plano de controle para fornecer serviços essenciais para cargas de trabalho de aplicativos. Muitas organizações usam o AKS como sua plataforma de infraestrutura principal e cargas de trabalho de transição hospedadas em outras plataformas para o AKS.

Este artigo descreve como migrar aplicativos em contêineres do Azure Service Fabric para o AKS. O artigo pressupõe que você esteja familiarizado com o Service Fabric, mas esteja interessado em saber como seus recursos e funcionalidades se comparam aos do AKS. O artigo também fornece práticas recomendadas para você considerar durante a migração.

Comparando o AKS com o Service Fabric

Para começar, consulte Escolher um serviço de computação do Azure, juntamente com outros serviços de computação do Azure. Esta secção destaca semelhanças e diferenças notáveis que são relevantes para a migração.

Tanto o Service Fabric quanto o AKS são orquestradores de contêineres. O Service Fabric fornece suporte para vários modelos de programação, mas o AKS suporta apenas contêineres.

  • Modelos de programação: o Service Fabric suporta várias maneiras de escrever e gerenciar seus serviços, incluindo contêineres Linux e Windows, Serviços Confiáveis, Atores Confiáveis, ASP.NET Core e executáveis convidados.

  • Contêineres no AKS: O AKS só suporta conteinerização com contêineres Windows e Linux que são executados no contêiner de tempo de execução do contêiner, que é gerenciado automaticamente.

O Service Fabric e o AKS fornecem integrações com outros serviços do Azure, incluindo Azure Pipelines, Azure Monitor, Azure Key Vault e Microsoft Entra ID.

Diferenças principais

Ao implantar um cluster tradicional do Service Fabric, em vez de um cluster gerenciado, você precisa definir explicitamente um recurso de cluster junto com muitos recursos de suporte em seus modelos do Azure Resource Manager (modelos ARM) ou módulos Bicep. Esses recursos incluem um conjunto de dimensionamento de máquina virtual para cada tipo de nó de cluster, grupos de segurança de rede e balanceadores de carga. É sua responsabilidade certificar-se de que esses recursos estão configurados corretamente. Por outro lado, o modelo de encapsulamento para clusters gerenciados do Service Fabric consiste em um único recurso de cluster gerenciado. Todos os recursos subjacentes para o cluster são abstraídos e gerenciados pelo Azure.

O AKS simplifica a implantação de um cluster Kubernetes gerenciado no Azure descarregando a sobrecarga operacional para o Azure. Como o AKS é um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção da integridade da infraestrutura. O Azure gerencia os nós mestres do Kubernetes, portanto, você só precisa gerenciar e manter os nós do agente.

Para mover sua carga de trabalho do Service Fabric para o AKS, você precisa entender as diferenças na infraestrutura subjacente para poder migrar com confiança seus aplicativos em contêineres. A tabela a seguir compara os recursos das duas plataformas de hospedagem.

Capacidade ou componente Service Fabric AKS
Aplicações não contentorizadas Sim No
Contentores de Linux e Windows Sim Sim
Plano de controle gerenciado pelo Azure Não Sim
Suporte para cargas de trabalho sem e com monitoração de estado Sim Sim
Colocação do nó de trabalhador Conjuntos de dimensionamento de máquina virtual, configurados pelo cliente Conjuntos de Dimensionamento de Máquina Virtual, Azure gerenciado
Manifesto de configuração XML YAML
Integração do Azure Monitor Sim Sim
Suporte nativo para serviços confiáveis e padrão de ator confiável Sim No
Pilha de comunicação baseada em WCF para serviços confiáveis Sim No
Armazenamento persistente Driver de volume do Azure Files Suporte para vários sistemas de armazenamento, como discos gerenciados, Arquivos do Azure e Armazenamento de Blob do Azure por meio de classes de Armazenamento CSI, volume persistente e declarações de volume persistentes
Modos de rede Integração da Rede Virtual do Azure Suporte para vários plug-ins de rede (Azure CNI, kubenet, BYOCNI), políticas de rede (Azure, Calico) e controladores de entrada (Application Gateway Ingress Controller, NGINX e muito mais)
Controladores de entrada Um proxy reverso integrado ao Service Fabric. Ele ajuda os microsserviços executados em um cluster do Service Fabric a descobrir e se comunicar com outros serviços que têm pontos de extremidade HTTP. Você também pode usar o Traefik no Service Fabric Controlador de entrada NGINX gerenciado, controladores comerciais e de código aberto de entrada BYO que usam balanceadores de carga públicos ou internos gerenciados pela plataforma, como controlador de entrada NGINX e Application Gateway Ingress Controller

Nota

Se você usa contêineres do Windows no Service Fabric, recomendamos usá-los no AKS para facilitar a migração.

Passos da Migração

Em geral, as etapas de migração do Service Fabric para o AKS são as seguintes.

Diagrama que mostra as etapas de migração do Service Fabric para o AKS.

  1. Estabeleça a arquitetura de implantação e crie o cluster AKS. O AKS fornece várias opções para configurar o acesso ao cluster, escalabilidade de nó e pod, acesso e configuração de rede e muito mais. Para obter mais informações sobre uma arquitetura de implantação típica, consulte Arquitetura de exemplo. A arquitetura de linha de base do AKS também fornece diretrizes de implantação e monitoramento de cluster. A construção do AKS fornece modelos de início rápido para implantar seu cluster AKS com base nos requisitos comerciais e técnicos.

  2. Rearquitete o aplicativo Service Fabric. Se você usar modelos de programação, como Serviços Confiáveis ou Atores Confiáveis, ou se usar outras construções específicas do Service Fabric, talvez seja necessário rearquitetar seu aplicativo. Para implementar o gerenciamento de estado ao migrar de Serviços Confiáveis, use o Distributed Application Runtime (Dapr). O Kubernetes fornece padrões e exemplos para migrar de Reliable Actors.

  3. Empacote o aplicativo como contêineres. Visual Studio fornece opções para gerar o Dockerfile e empacotar o aplicativo como contêineres. Envie por push as imagens de contêiner que você cria para o Registro de Contêiner do Azure.

  4. Reescreva os arquivos XML de configuração do Service Fabric como arquivos YAML do Kubernetes. Você implanta o aplicativo no AKS usando arquivos YAML ou como um pacote usando gráficos Helm. Para obter mais informações, consulte Manifesto de aplicativo e serviço.

  5. Implante o aplicativo no cluster AKS.

  6. Mude o tráfego para o cluster AKS com base em suas estratégias de implantação e monitore o comportamento, a disponibilidade e o desempenho do aplicativo.

Exemplo de arquitetura

O AKS e o Azure fornecem flexibilidade para configurar seu ambiente para atender às suas necessidades de negócios. O AKS está bem integrado com outros serviços do Azure. A arquitetura de linha de base AKS é um exemplo.

Diagrama que mostra uma arquitetura AKS de linha de base.

Como ponto de partida, familiarize-se com alguns conceitos-chave do Kubernetes e, em seguida, revise alguns exemplos de arquiteturas:

Nota

Ao migrar uma carga de trabalho do Service Fabric para o AKS, você pode substituir os Atores Confiáveis do Service Fabric pelo bloco de construção de atores do Dapr. Você pode substituir as Coleções Confiáveis do Service Fabric pelo bloco de construção de gerenciamento de estado do Dapr.

O Dapr fornece APIs que simplificam a conectividade de microsserviços. Para obter mais informações, consulte Introdução ao Dapr. Recomendamos que instale o Dapr como uma extensão AKS.

Manifesto de aplicativo e serviço

O Service Fabric e o AKS têm diferentes tipos de arquivo e construções de manifesto de aplicativo e serviço. O Service Fabric usa arquivos XML para definição de aplicativo e serviço. O AKS usa o manifesto do arquivo YAML do Kubernetes para definir objetos do Kubernetes. Não há ferramentas especificamente destinadas a migrar um arquivo XML do Service Fabric para um arquivo YAML do Kubernetes. No entanto, você pode aprender sobre como os arquivos YAML funcionam no Kubernetes examinando os recursos a seguir.

Você pode usar o Helm para definir manifestos YAML parametrizados e criar modelos genéricos substituindo valores estáticos e codificados por espaços reservados que podem ser substituídos por valores personalizados fornecidos no momento da implantação. Os modelos resultantes que contêm os valores personalizados são renderizados como manifestos válidos para o Kubernetes.

Kustomize introduz uma maneira livre de modelos para personalizar a configuração do aplicativo que simplifica o uso de aplicativos prontos para uso. Você pode usar Kustomize junto com Helm ou como uma alternativa para Helm.

Para obter mais informações sobre Helm e Kustomize, consulte os seguintes recursos:

Rede

O AKS fornece duas opções para a rede subjacente:

  • Traga sua própria rede virtual do Azure para provisionar os nós de cluster AKS em uma sub-rede de uma rede virtual que você fornece.

  • Permita que o provedor de recursos AKS crie uma nova rede virtual do Azure para você no grupo de recursos do nó que contém todos os recursos do Azure que um cluster usa.

Se você escolher a segunda opção, o Azure gerenciará a rede virtual.

O Service Fabric não oferece opções de plug-ins de rede. Se você usa AKS, você precisa escolher uma das seguintes opções:

  • Kubenet. Se você usar kubenet, os nós obterão um endereço IP da sub-rede de rede virtual do Azure. Os pods recebem um endereço IP de um espaço de endereço que é logicamente diferente do da sub-rede de rede virtual do Azure dos nós. A tradução de endereços de rede (NAT) é configurada para que os pods possam chegar aos recursos na rede virtual do Azure. O endereço IP de origem do tráfego é convertido via NAT para o endereço IP primário do nó. Essa abordagem reduz significativamente o número de endereços IP que você precisa reservar em seu espaço de rede para pods usarem.

  • Azure CNI. Se você usar a CNI (Container Networking Interface), cada pod receberá um endereço IP da sub-rede e poderá ser acessado diretamente. Esses endereços IP devem ser exclusivos em todo o espaço da rede e devem ser planejados com antecedência. Cada nó tem um parâmetro de configuração para o número máximo de pods suportados. Em seguida, você reserva o número equivalente de endereços IP para cada nó. Essa abordagem requer mais planejamento e muitas vezes leva ao esgotamento do endereço IP ou à necessidade de reconstruir clusters em uma sub-rede maior à medida que as demandas do seu aplicativo crescem. Você pode configurar o número máximo de pods que podem ser implantados em um nó ao criar o cluster ou ao criar novos pools de nós.

  • Rede de sobreposição CNI do Azure. Se você usar a Sobreposição CNI do Azure, os nós de cluster serão implantados em uma sub-rede da Rede Virtual do Azure. Os pods recebem endereços IP de um CIDR privado que são logicamente diferentes do endereço da rede virtual que hospeda os nós. O tráfego de pod e nó dentro do cluster usa uma rede de sobreposição. O NAT usa o endereço IP do nó para alcançar recursos fora do cluster. Esta solução guarda um número significativo de endereços IP de rede virtual e ajuda-o a dimensionar facilmente o cluster para tamanhos grandes. Uma vantagem adicional é que você pode reutilizar o CIDR privado em diferentes clusters AKS, o que estende o espaço IP disponível para aplicativos em contêineres no AKS.

  • Azure CNI Powered by Cilium. Azure CNI Powered by Cilium combina o plano de controle robusto do Azure CNI com o plano de dados do Cilium para ajudar a fornecer rede de alto desempenho e segurança aprimorada.

  • Traga o seu próprio plug-in CNI. O Kubernetes não fornece um sistema de interface de rede por padrão. Esta funcionalidade é fornecida por plug-ins de rede. O AKS fornece vários plug-ins CNI suportados. Para obter mais informações sobre plug-ins suportados, consulte Conceitos de rede para aplicativos no AKS.

Atualmente, os contêineres do Windows oferecem suporte apenas ao plug-in CNI do Azure. Várias opções para políticas de rede e controladores de entrada estão disponíveis.

No AKS, você pode usar políticas de rede do Kubernetes para segregar e ajudar a proteger as comunicações intrasserviço, controlando quais componentes podem se comunicar entre si. Por padrão, todos os pods em um cluster Kubernetes podem enviar e receber tráfego sem limitações. Para melhorar a segurança, você pode usar as políticas de rede do Azure ou as políticas de rede do Calico para definir regras que controlam o fluxo de tráfego entre microsserviços.

Se quiser usar o Gerenciador de Políticas de Rede do Azure, você deve usar o plug-in CNI do Azure. Você pode usar as políticas de rede do Calico com o plug-in CNI do Azure ou o plug-in CNI kubenet. O uso do Gerenciador de Políticas de Rede do Azure para nós do Windows é suportado apenas no Windows Server 2022. Para obter mais informações, consulte Proteger o tráfego entre pods usando políticas de rede no AKS. Para obter mais informações sobre a rede AKS, consulte Rede no AKS.

No Kubernetes, um controlador de entrada atua como um proxy de serviço e intermediário entre um serviço e o mundo exterior, permitindo que o tráfego externo acesse o serviço. O proxy de serviço normalmente fornece várias funcionalidades, como terminação TLS, roteamento de solicitação baseado em caminho, balanceamento de carga e recursos de segurança, como autenticação e autorização. Os controladores de entrada também fornecem outra camada de abstração e controle para rotear o tráfego externo para serviços Kubernetes com base em regras HTTP e HTTPS. Essa camada fornece um controle mais refinado sobre o fluxo de tráfego e o gerenciamento de tráfego.

No AKS, há várias opções para implantar, executar e operar um controlador de entrada. Uma opção é o Application Gateway Ingress Controller, que permite usar o Gateway de Aplicativo do Azure como o controlador de entrada para terminação TLS, roteamento baseado em caminho e como um firewall de acesso à Web. Outra opção é o controlador de entrada NGINX gerenciado, que fornece a opção gerenciada pelo Azure para o controlador de entrada NGINX amplamente usado. Traefik ingress controller é outro controlador de entrada popular para Kubernetes.

Cada um desses controladores de entrada tem pontos fortes e fracos. Para decidir qual usar, considere os requisitos do aplicativo e do ambiente. Certifique-se de usar a versão mais recente do Helm e ter acesso ao repositório Helm apropriado ao instalar um controlador de entrada não gerenciado.

Armazenamento persistente

Tanto o Service Fabric quanto o AKS têm mecanismos para fornecer armazenamento persistente para aplicativos em contêineres. No Service Fabric, o driver de volume de Arquivos do Azure, que é um plug-in de volume do Docker, fornece volumes de Arquivos do Azure para contêineres Linux e Windows. Ele é empacotado como um aplicativo do Service Fabric que você pode implantar em um cluster do Service Fabric para fornecer volumes para outros aplicativos em contêineres do Service Fabric dentro do cluster. Para obter mais informações, consulte Driver de volume do Azure Files para Service Fabric.

Os aplicativos executados no AKS podem precisar armazenar e recuperar dados de um sistema de armazenamento de arquivos persistente. O AKS integra-se com os serviços de armazenamento do Azure, como discos geridos do Azure, Azure Files, Blob Storage e Azure NetApp Storage (ANF). Ele também se integra com sistemas de armazenamento que não são da Microsoft, como Rook e GlusterFS , por meio de drivers CSI (Container Storage Interface).

O CSI é um padrão para expor sistemas de armazenamento de blocos e arquivos a cargas de trabalho em contêineres no Kubernetes. Os provedores de armazenamento que não são da Microsoft que usam CSI podem escrever, implantar e atualizar plug-ins para expor novos sistemas de armazenamento no Kubernetes ou para melhorar os existentes, sem a necessidade de alterar o código principal do Kubernetes e aguardar seus ciclos de lançamento.

O suporte ao driver de armazenamento CSI no AKS permite que você use nativamente estes serviços de armazenamento do Azure:

  • Azure Disks. Você pode usar o Azure Disks para criar um recurso Kubernetes DataDisk. Os discos podem usar o armazenamento premium do Azure apoiado por SSDs de alto desempenho ou o armazenamento padrão do Azure apoiado por HDDs ou SSDs padrão. Para a maioria das cargas de trabalho de produção e desenvolvimento, use o armazenamento premium. Os Discos do Azure são montados como ReadWriteOnce e só estão disponíveis para um nó no AKS. Para volumes de armazenamento que vários pods podem acessar simultaneamente, use os Arquivos do Azure.

    Por outro lado, o Service Fabric oferece suporte à criação de um cluster ou um tipo de nó que usa discos gerenciados, mas não aplicativos que criam dinamicamente discos gerenciados anexados por meio de uma abordagem declarativa. Para obter mais informações, consulte Implantar um tipo de nó de cluster do Service Fabric com discos de dados gerenciados.

  • Ficheiros do Azure. Você pode usar os Arquivos do Azure para montar um compartilhamento SMB 3.0 ou 3.1 apoiado por uma conta de armazenamento do Azure em pods. Com os Arquivos do Azure, você pode compartilhar dados entre vários nós e pods. Os Arquivos do Azure podem usar o armazenamento padrão do Azure apoiado por HDDs padrão ou o armazenamento premium do Azure apoiado por SSDs de alto desempenho.

    O Service Fabric fornece um driver de volume do Azure Files como um plug-in de volume do Docker que fornece volumes do Azure Files para contêineres do Docker. O Service Fabric fornece uma versão do driver para clusters Windows e outra para clusters Linux.

  • Armazenamento de Blob. Você pode usar o Armazenamento de Blob para montar o armazenamento de blob (ou armazenamento de objetos) como um sistema de arquivos em um contêiner ou pod. O armazenamento de Blob permite que um cluster AKS ofereça suporte a aplicativos que trabalham com grandes conjuntos de dados não estruturados, como dados de arquivos de log, imagens ou documentos e cargas de trabalho HPC. Se você ingerir dados no Armazenamento do Azure Data Lake, poderá montar diretamente o armazenamento e usá-lo no AKS sem configurar outro sistema de arquivos provisório. O Service Fabric não suporta nenhum mecanismo de montagem de armazenamento de blob no modo declarativo.

Para obter mais informações sobre opções de armazenamento, consulte Armazenamento no AKS.

Monitoramento de aplicativos e clusters

Tanto o Service Fabric quanto o AKS fornecem integração nativa com o Azure Monitor e seus serviços, como o Log Analytics. O monitoramento e o diagnóstico são essenciais para desenvolver, testar e implantar cargas de trabalho em qualquer ambiente de nuvem. O monitoramento inclui o monitoramento de infraestrutura e aplicativos.

Por exemplo, você pode acompanhar como seus aplicativos são usados, as ações que a plataforma Service Fabric realiza, sua utilização de recursos por meio de contadores de desempenho e a integridade geral do cluster. Você pode usar essas informações para diagnosticar e corrigir problemas e evitar que eles ocorram no futuro. Para obter mais informações, consulte Monitoramento e diagnóstico do Service Fabric. Ao hospedar e operar aplicativos em contêineres em um cluster do Service Fabric, você precisa configurar a solução de monitoramento de contêiner para exibir eventos e logs de contêiner.

No entanto, o AKS tem integração interna com o Azure Monitor e o Container Insights, que foi projetado para monitorar o desempenho de cargas de trabalho em contêineres implantadas na nuvem. O Container Insights fornece visibilidade de desempenho coletando métricas de memória e processador de controladores, nós e contêineres disponíveis no Kubernetes por meio da API de métricas.

Depois de habilitar o monitoramento de clusters do Kubernetes, as métricas e os logs de contêiner são coletados automaticamente por meio de uma versão conteinerizada do agente do Log Analytics para Linux. As métricas são enviadas para o banco de dados de métricas no Azure Monitor. Os dados de log são enviados para o espaço de trabalho do Log Analytics. Isso permite que você obtenha dados de monitoramento e telemetria para o cluster AKS e os aplicativos em contêineres que são executados sobre ele. Para obter mais informações, consulte Monitorar o AKS com o Azure Monitor.

Como uma solução alternativa ou complementar ao Container Insights, você pode configurar seu cluster AKS para coletar métricas no serviço gerenciado do Azure Monitor para Prometheus. Você pode usar essa configuração para coletar e analisar métricas em escala usando uma solução de monitoramento compatível com Prometheus, que é baseada no projeto Prometheus . O serviço totalmente gerenciado permite que você use a linguagem de consulta Prometheus (PromQL) para analisar o desempenho da infraestrutura monitorada e cargas de trabalho. Ele também permite que você receba alertas sem a necessidade de operar a infraestrutura subjacente.

O serviço gerenciado do Azure Monitor para Prometheus é um componente do Azure Monitor Metrics. Ele fornece mais flexibilidade nos tipos de dados métricos que você pode coletar e analisar usando o Azure Monitor. As métricas do Prometheus compartilham alguns recursos com métricas personalizadas e de plataforma, mas têm recursos extras para oferecer melhor suporte a ferramentas de código aberto como PromQLe Grafana.

Você pode configurar o serviço gerenciado do Azure Monitor para Prometheus como uma fonte de dados para o Azure Managed Grafana e o Grafana auto-hospedado, que pode ser executado em uma máquina virtual do Azure. Para obter mais informações, consulte Usar o serviço gerenciado do Azure Monitor para Prometheus como fonte de dados para o Grafana usando a identidade do sistema gerenciado.

Complementos para o AKS

Ao migrar do Service Fabric para o AKS, você deve considerar o uso de complementos e extensões. O AKS fornece funcionalidade extra suportada para seus clusters por meio de complementos e extensões como Kubernetes Event-driven Autoscaling (KEDA) e GitOps Flux v2. Muitas outras integrações fornecidas por projetos de código aberto e terceiros são comumente usadas com o AKS. A política de suporte do AKS não abrange integrações de código aberto e não Microsoft. Para obter mais informações, consulte Complementos, extensões e outras integrações com o AKS.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos