Compartilhar 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 de aplicativos modernos, as melhores práticas de manutenção e as 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 de Kubernetes do Azure (AKS) atende aos requisitos de muitos dos seus aplicativos conteinerizados. O AKS é um serviço gerenciado do Kubernetes que simplifica as implantações de aplicativos por meio do Kubernetes gerenciando o painel de controle para fornecer serviços principais para cargas de trabalho de aplicativos. Muitas organizações usam o AKS como sua plataforma de infraestrutura primária e fazem a transição de cargas de trabalho hospedadas em outras plataformas para o AKS.

Este artigo descreve como migrar aplicativos conteinerizados 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 a serem consideradas durante a migração.

Comparando o AKS com o Service Fabric

Para começar, examine Escolher um serviço de computação do Azure, juntamente com outros serviços de computação do Azure. Esta seçã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 só dá suporte a contêineres.

  • Modelos de programação: o Service Fabric oferece suporte a 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ó dá suporte à conteinerização com contêineres do Windows e do Linux executados no containerd de runtime 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.

Principais diferenças

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 ARM (modelos do Azure Resource Manager) 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 estejam 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 do cluster são abstraídos e gerenciados pelo Azure.

O AKS simplifica a implantação de um cluster do Kubernetes gerenciado no Azure descarregando a sobrecarga operacional para o Azure. Como o AKS é um serviço Kubernetes hospedado, o Azure lida com as tarefas críticas para você, como o monitoramento da integridade e a manutenção 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 e funcionalidades das duas plataformas de hospedagem.

Capacidade ou componente Service Fabric AKS
Aplicativos não conteinerizados. Sim No
Contêineres do Windows e do Linux Sim Sim
Plano de controle gerenciado pelo Azure Não Sim
Suporte para cargas de trabalho sem monitoração de estado e com monitoração de estado Sim Sim
Colocação do nó de trabalho Conjuntos de dimensionamento de máquina virtual, configurados pelo cliente Conjuntos de dimensionamento de máquina virtual, gerenciados pelo Azure
Manifesto de configuração XML YAML
Integração com o 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 no WCF para Reliable Services Sim No
Armazenamento persistente Volume de driver de Arquivos do Azure Suporte para vários sistemas de armazenamento, como Managed Disks, Arquivos do Azure e Armazenamento de Blobs do Azure por meio de classes de armazenamento CSI, volume persistente e declarações de volume persistente
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 software livre de entrada BYO que usam balanceadores de carga públicos ou internos gerenciados pela plataforma, como o controlador de entrada NGINX e o Controlador de Entrada do Gateway de Aplicativo

Observação

Se você usar contêineres do Windows no Service Fabric, recomendamos que você os use no AKS para facilitar a migração.

Etapas 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 do AKS. O AKS fornece várias opções para configurar o acesso ao cluster, a escalabilidade do nó e do pod, o acesso e a configuração da 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 o cluster do AKS com base nos requisitos técnicos e de negócios.

  2. Rearquitetar o aplicativo do Service Fabric. Se você usar modelos de programação, como Reliable Services ou Reliable Actors, ou se usar outros constructos específicos do Service Fabric, talvez seja necessário rearquitetar seu aplicativo. Para implementar o gerenciamento de estado ao migrar do Reliable Services, use o Dapr (Distributed Application Runtime). O Kubernetes fornece padrões e exemplos para migrar de Reliable Actors.

  3. Empacote o aplicativo como contêineres. O 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 do Helm. Para obter mais informações, consulte Manifesto do aplicativo e do serviço.

  5. Implante o aplicativo no cluster do AKS.

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

Arquitetura de exemplo

O AKS e o Azure fornecem flexibilidade para configurar o ambiente para atender às suas necessidades de negócios. O AKS também se integra bem aos outros serviços do Azure. A arquitetura de linha de base do AKS é um exemplo.

Diagrama que mostra uma arquitetura do AKS de linha de base.

Como ponto de partida, familiarize-se com alguns conceitos importantes do Kubernetes e, em seguida, revise algumas arquiteturas de exemplo:

Observação

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 você instale o Dapr como uma extensão do AKS.

Manifesto do aplicativo e serviço

O Service Fabric e o AKS têm diferentes tipos de arquivo de manifesto de aplicativo e serviço e construções. 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.

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

Para obter mais informações sobre o Helm e o 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 do AKS em uma sub-rede de uma rede virtual que você fornece.

  • Permita que o provedor de recursos do 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 fornece uma opção de plug-ins de rede. Se você usar o AKS, precisará escolher uma das seguintes opções:

  • kubenet. Se você usa o kubenet, os nós obtêm um endereço IP da sub-rede da rede virtual do Azure. Os pods recebem um endereço IP de um espaço de endereço que é logicamente diferente daquele da sub-rede da rede virtual do Azure dos nós. A NAT (Conversão de Endereços de Rede) é configurada para que os pods possam alcançar recursos na rede virtual do Azure. O endereço IP de origem do tráfego é convertido pelo NAT no endereço IP primário do nó. Essa abordagem reduz muito o número de endereços IP que você precisa reservar no espaço de rede para uso dos pods.

  • CNI do Azure. Se você usar a CNI (Container Networking Interface), cada pod obterá um endereço IP da sub-rede e poderá ser acessado diretamente. Esses endereços IP devem ser exclusivos em todo o seu espaço de 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 aos quais ele dá suporte. Em seguida, reserve o número equivalente de endereços IP para cada nó. Essa abordagem exige mais planejamento e, muitas vezes, leva à exaustão do endereço IP ou à necessidade de recriar os clusters em uma sub-rede maior conforme as demandas de aplicativo aumentam. 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.

  • Sistema de rede de Sobreposição da CNI do Azure. Se você usar a Sobreposição da 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 acessar recursos fora do cluster. Essa solução economiza um número significativo de endereços IP de rede virtual e ajuda você a dimensionar perfeitamente seu cluster para tamanhos grandes. Uma vantagem adicional é que você pode reutilizar o CIDR privado em diferentes clusters do AKS, estendendo o espaço IP disponível para aplicativos conteinerizados no AKS.

  • CNI do Azure da Plataforma Cilium. O 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 seu próprio plug-in CNI. O Kubernetes não fornece um sistema de interface de rede por padrão. Essa funcionalidade é fornecida por plug-ins de rede. O AKS fornece vários plug-ins CNI com suporte. Para obter mais informações sobre plug-ins com suporte, 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 usa políticas de rede do Kubernetes para separar e ajudar a proteger as comunicações entre serviços controlando os componentes que podem se comunicar entre si. Por padrão, todos os pods de um cluster de Kubernetes podem enviar e receber tráfego sem limitações. Para melhorar a segurança, pode utilizar as políticas de rede do Azure ou políticas de rede do Calico para definir regras que controlam o fluxo de tráfego entre diferentes microsserviços.

Se você quer usar o Gerenciador de Políticas de Rede do Azure, use 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 do kubenet. O uso do Gerenciador de Políticas de Rede do Azure para nós do Windows tem suporte apenas no Windows Server 2022. Para mais informações, consulte Proteger o tráfego entre os pods usando as políticas de rede no AKS. Para obter mais informações sobre a rede do 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 externo, 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 do 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 Controlador de Entrada do Gateway de Aplicativo, 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. O controlador de entrada Traefik é 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 apropriado do Helm 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 a aplicativos conteinerizados. 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 do Linux e do Windows. Ele é empacotado como um aplicativo do Service Fabric que pode implantar em um cluster do Service Fabric para fornecer volumes a outros aplicativos conteinerizados do Service Fabric dentro do cluster. Para obter mais informações, consulte Driver de volume do Arquivos do Azure para o Service Fabric.

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

A CSI é um padrão para expor sistemas de blocos e de armazenamento de arquivos arbitrários a cargas de trabalho conteinerizadas no Kubernetes. Os provedores de armazenamento que não são da Microsoft que usam CSI podem gravar, 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:

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

    Por outro lado, o Service Fabric dá 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.

  • Arquivos do Azure. Você pode usar o 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 em vários nós e pods. O Arquivos do Azure pode usar o Armazenamento Standard do Azure, com o suporte de HDDs padrão ou o Armazenamento Premium do Azure, com o suporte de SSDs de alto desempenho.

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

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

Para saber mais sobre as opções de armazenamento, consulte Armazenamento no AKS.

Monitoramento de aplicativos e clusters

O Service Fabric e 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 monitoramento de infraestrutura e aplicativos.

Por exemplo, você pode controlar como seus aplicativos são usados, as ações realizadas pela plataforma do Service Fabric, a utilização de recursos com contadores de desempenho e a integridade geral do seu 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 no Service Fabric. Ao hospedar e operar aplicativos conteinerizados 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 oferece visibilidade de desempenho coletando métricas de processador e memória de controladores, nós e contêineres disponíveis no Kubernetes por meio da API de Métricas.

Depois que você habilitar o monitoramento com base em clusters do Kubernetes, as métricas e os logs do contêiner serã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 seu workspace do Log Analytics. Isso permite que você obtenha dados de monitoramento e telemetria para o cluster do AKS e os aplicativos em contêineres 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 do 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 o Prometheus, que é baseada no projeto do Prometheus . O serviço totalmente gerenciado permite que você use a linguagem de consulta Prometheus (PromQL) para analisar o desempenho da infraestrutura e das cargas de trabalho monitoradas. Ele também permite que você receba alertas sem precisar operar a infraestrutura subjacente.

O serviço gerenciado do Azure Monitor para Prometheus é um componente das Métricas do Azure Monitor. Ele fornece mais flexibilidade nos tipos de dados de métrica que você pode coletar e analisar usando o Azure Monitor. As métricas do Prometheus compartilham alguns recursos com métricas de plataforma e personalizadas, 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 fonte de dados para o Espaço Gerenciado do Azure para Grafana e o Grafana auto-hospedado, que pode ser executado em uma máquina virtual do Azure. Para 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 com suporte para seus clusters por meio de complementos e extensões como o Kubernetes Event-driven Autoscaling (KEDA) e o GitOps Flux v2. Também há muitas outras integrações fornecidas por projetos de código aberto e de terceiros que são comumente usadas com o AKS. A política de suporte do AKS não abrange integrações de software livre e que não são da Microsoft. Para obter mais informações, consulte Complementos, extensões e outras integrações com o AKS..

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

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

Próximas etapas