Compartilhar via

Políticas de suporte para AKS habilitado pelo Azure Arc

  • Artigo

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Este artigo fornece detalhes sobre políticas e limitações de suporte técnico para o AKS habilitado pelo Arc. O artigo também descreve o gerenciamento de nó de cluster, componentes do plano de controle, componentes de software livre de terceiros e gerenciamento de segurança ou patches.

Atualizações de serviço e versões

  • A Microsoft oferece uma janela de suporte de 1 ano para cada versão secundária do Kubernetes, começando com a data de lançamento inicial. Durante esse período, o AKS Arc lança versões secundárias ou de patch subsequentes para garantir o suporte contínuo.
  • Um cluster do Kubernetes que opera em uma versão secundária obsoleta deve ser atualizado para uma versão compatível para ser qualificado para suporte.
  • Depois que uma versão secundária for preterida, todos os clusters ainda em execução nessa versão continuarão a funcionar. Você ainda pode executar operações como escalar ou reduzir verticalmente, mas o AKS Arc exibe um aviso durante as operações de cluster.
  • Depois que uma versão secundária é preterida, ela é removida dos servidores da Microsoft. Nesse ponto, os clusters do Kubernetes que usam essa versão não podem atualizar as versões do Kubernetes ou do sistema operacional e devem ser atualizados para a versão mais recente. Em alguns casos, essa atualização também pode significar uma reimplantação completa se o sistema não estiver em um estado íntegro.

Para obter informações sobre a versão, consulte as notas de versão do AKS Arc. Para obter informações sobre recursos em versão prévia, consulte Recursos de visualização do AKS Arc.

Recursos gerenciados no AKS Arc

Como usuário do AKS Arc, você tem opções limitadas de personalização e implantação. No entanto, você não precisa se preocupar ou gerenciar o plano de controle e a instalação do cluster do Kubernetes diretamente. Os componentes básicos de nuvem de infraestrutura como serviço (IaaS), como componentes de computação ou rede, permitem acesso a controles de baixo nível e opções de personalização.

Por outro lado, o AKS Arc fornece uma implantação do Kubernetes pronta para uso que fornece o conjunto comum de configurações e recursos necessários para o cluster. Com o AKS Arc, você obtém um plano de controle parcialmente gerenciado. O painel de controle contém todos os componentes e serviços de que você precisa para operar e fornecer clusters do Kubernetes aos usuários finais. A Microsoft mantém todos os componentes do Kubernetes.

A Microsoft mantém os seguintes componentes por meio do cluster de gerenciamento e das imagens base de máquina virtual associadas:

  • kubelet ou servidores de API do Kubernetes.
  • etcd ou um armazenamento de chave-valor compatível, fornecendo QoS (Qualidade de Serviço), escalabilidade e tempo de execução.
  • Serviços DNS (por exemplo, kube-dns ou CoreDNS).
  • Proxy ou rede do Kubernetes.
  • Qualquer outro complemento ou componente do sistema em execução no kube-system namespace.

O AKS Arc não é uma solução de PaaS (plataforma como serviço). Alguns componentes, como clusters de carga de trabalho, plano de controle e nós de trabalho, têm responsabilidade compartilhada. Os usuários devem ajudar a manter o cluster do Kubernetes. A entrada do usuário é necessária, por exemplo, para aplicar um patch de segurança do sistema operacional (SO) ou atualizar para uma versão mais recente do Kubernetes.

Os serviços são gerenciados no sentido de que a Microsoft e a equipe do AKS fornecem as ferramentas que implantam o cluster de gerenciamento, o painel de controle e os nós do agente para clusters de carga de trabalho. Você não pode alterar esses componentes gerenciados. A Microsoft limita a personalização para garantir uma experiência de usuário consistente e escalonável. Para obter uma solução totalmente personalizável na nuvem, consulte o mecanismo do AKS.

Política de versão com suporte

As versões do Kubernetes no AKS Arc seguem a política de versão do Kubernetes.

O AKS Arc não faz nenhuma garantia de runtime (ou outra) para clusters fora da lista de versões com suporte. "Fora do suporte" significa que:

  • Seu cluster opera em uma versão secundária preterida. A versão que você está executando está fora da lista de versões compatíveis.
  • Você será solicitado a atualizar o cluster para uma versão com suporte ao solicitar suporte.

Para obter informações sobre as versões do Kubernetes com suporte, consulte Versões do Kubernetes com suporte.

O AKS Arc segue os prazos de suporte à versão da plataforma para esses produtos. Ou seja, o AKS Arc não tem suporte em versões sem suporte desses produtos. Para obter mais informações, consulte suas políticas de suporte:

Responsabilidade compartilhada

Quando um cluster é criado, você define os nós do agente do Kubernetes que o AKS Arc cria. Suas cargas de trabalho são executadas nesses nós.

Como os nós do agente executam código privado e armazenam dados confidenciais, o Suporte da Microsoft tem acesso limitado a eles. O Suporte da Microsoft não pode entrar para executar comandos ou exibir logs para esses nós sem sua permissão ou assistência expressa. Qualquer modificação direta dos nós do agente usando qualquer uma das APIs de IaaS torna o cluster incompatível. Qualquer modificação feita nos nós do agente deve ser feita usando mecanismos nativos do Kubernetes, como Daemon Sets.

Da mesma forma, embora você possa adicionar metadados, como tags e rótulos, ao cluster e aos nós, a alteração de qualquer um dos metadados criados pelo sistema torna o cluster sem suporte.

Cobertura de suporte do AKS Arc

A Microsoft fornece suporte técnico para os seguintes recursos e componentes:

  • Conectividade com todos os componentes do Kubernetes que o serviço de Kubernetes oferece e dá suporte, como o servidor de API.
  • Serviços do plano de controle do Kubernetes (por exemplo, plano de controle do Kubernetes, servidor de API, etcd e coreDNS).
  • Armazenamento de dados Etcd.
  • Integração com o Azure Arc e o serviço de Cobrança do Azure.
  • Perguntas ou problemas sobre a personalização de componentes do painel de controle, como o servidor de API do Kubernetes, etcd e coreDNS.
  • Problemas com rede, acesso à rede e funcionalidade. Os problemas podem incluir resolução de DNS, perda de pacotes e roteamento. A Microsoft dá suporte a vários cenários de rede:
    • Suporte básico de instalação para Flannel e Calico CNI. Esses CNIs são orientados e apoiados pela comunidade. O Suporte da Microsoft fornece apenas suporte básico de instalação e configuração.
    • Conectividade com outros serviços e aplicativos do Azure.
    • Controladores de entrada e configuração de entrada ou balanceador de carga.
    • Desempenho e latência da rede.

Observação

Todas as ações de cluster executadas pelas equipes de suporte do Microsoft AKS Arc são feitas com o consentimento e a assistência do usuário. O Suporte da Microsoft não faz logon no cluster, a menos que você configure o acesso para o engenheiro de suporte.

A Microsoft não fornece suporte técnico para as seguintes áreas:

  • Perguntas sobre como usar o Kubernetes. Por exemplo, o Suporte da Microsoft não faz recomendações sobre como criar controladores de entrada personalizados, usar cargas de trabalho de aplicativos ou aplicar pacotes ou ferramentas de software livre ou de terceiros.

    Observação

    O Suporte da Microsoft pode aconselhar sobre a funcionalidade, a personalização e o ajuste do cluster no AKS Arc; por exemplo, problemas e procedimentos de operações do Kubernetes.

  • Projetos de software livre de terceiros que não são fornecidos como parte do painel de controle do Kubernetes ou implantados quando os clusters são criados no AKS Arc. Esses projetos podem incluir Istio, Helm, Envoy ou outros.

    Observação

    A Microsoft pode fornecer suporte de melhor esforço para projetos de software livre de terceiros, como o Helm. Quando a ferramenta de software livre de terceiros se integra ao Kubernetes ou a outros bugs específicos do AKS Arc, a Microsoft dá suporte a exemplos e aplicativos da documentação da Microsoft.

  • Software closed-source de terceiros. Esse software pode incluir ferramentas de verificação de segurança e software ou dispositivos de rede.

  • Personalizações de rede diferentes das listadas na documentação do AKS Arc.

Cobertura de suporte do AKS Arc para nós de agente

Responsabilidades da Microsoft para nós de agente do AKS Arc

A Microsoft e os usuários compartilham a responsabilidade pelos nós do agente do Kubernetes nos quais:

  • A imagem base do sistema operacional exigia adições (como agentes de monitoramento e rede).
  • Os nós do agente recebem patches do sistema operacional automaticamente.
  • Os problemas com os componentes do plano de controle do Kubernetes executados nos nós do agente são corrigidos automaticamente durante o ciclo de atualização ou quando você reimplanta um nó do agente. Esses componentes incluem:
    • kube-proxy
    • Túneis de rede que fornecem caminhos de comunicação para os componentes principais do Kubernetes:
      • kubelet
      • Moby ou ContainerD

Observação

Se um nó do agente não estiver operacional, o AKS Arc poderá reiniciar componentes individuais ou todo o nó do agente. Essas operações de reinicialização automatizadas fornecem correção automática para problemas comuns.

Responsabilidades do cliente para nós de agente do AKS Arc

A Microsoft fornece patches e novas imagens para seus nós de imagem mensalmente, mas não os corrige automaticamente por padrão. Para manter o sistema operacional do nó do agente e os componentes de tempo de execução corrigidos, você deve manter um agendamento de atualização regular ou automatizar a aplicação de patches.

Da mesma forma, o AKS Arc lança regularmente novos patches do Kubernetes e versões secundárias. Essas atualizações podem conter aprimoramentos de segurança ou de funcionalidade para o Kubernetes. Você é responsável por manter a versão do Kubernetes do cluster atualizada de acordo com a política de versões com suporte do AKS Arc.

Personalização de nós do agente pelo usuário

Observação

Os nós do agente do AKS Arc aparecem no Hyper-V como recursos regulares da máquina virtual. Essas máquinas virtuais são implantadas com uma imagem personalizada do sistema operacional e componentes do Kubernetes com suporte e gerenciados. Você não pode alterar a imagem base do sistema operacional ou fazer personalizações diretas para esses nós usando as APIs ou recursos do Hyper-V. Todas as alterações personalizadas que não são feitas por meio da API do AKS-HCI não persistem por meio de uma atualização, dimensionamento, atualização ou reinicialização e podem tornar o cluster sem suporte. Evite fazer alterações nos nós do agente, a menos que o Suporte da Microsoft oriente você a fazê-las.

O AKS Arc gerencia o ciclo de vida e as operações das imagens de nó do agente em seu nome. Não há suporte para a modificação dos recursos associados aos nós do agente. Por exemplo, não há suporte para personalizar as configurações de rede de uma máquina virtual alterando manualmente as configurações por meio da API ou das ferramentas do Hyper-V.

Para configurações ou pacotes específicos de carga de trabalho, você deve usar conjuntos de daemon do Kubernetes.

Ao usar contêineres privilegiados daemon sets e de inicialização do Kubernetes, você pode ajustar/modificar ou instalar software de terceiros nos nós do agente de cluster. Por exemplo, você pode adicionar software de verificação de segurança personalizado ou atualizar sysctl configurações. Embora esse caminho seja recomendado se os requisitos anteriores se aplicarem, a engenharia e o suporte do AKS Arc não poderão ajudar na solução de problemas ou no diagnóstico de modificações que tornam o nó indisponível devido a um daemon set.

Problemas de segurança e aplicação de patch

Se uma falha de segurança for encontrada em um ou mais dos componentes gerenciados do AKS Arc, a equipe do AKS Arc corrigirá todas as imagens do sistema operacional afetadas para atenuar o problema e a equipe fornecerá diretrizes de atualização aos usuários.

Para nós de agente afetados por uma falha de segurança, a Microsoft notifica você com detalhes sobre o impacto e as etapas para corrigir ou atenuar o problema de segurança. Normalmente, as etapas incluem uma atualização de imagem de nó ou uma atualização de patch de cluster.

Manutenção e acesso do nó

Embora você possa entrar e alterar os nós do agente, essa operação é desencorajada porque as alterações podem tornar um cluster insuportável.

Portas de rede, pools de IP e acesso

Você só pode personalizar as configurações de rede usando sub-redes definidas pelo AKS Arc. Não é possível personalizar as configurações de rede no nível da NIC dos nós do agente. O AKS Arc tem requisitos de saída para pontos de extremidade específicos, para controlar a saída e garantir a conectividade necessária. Para obter mais informações, consulte Requisitos do sistema do AKS Arc.

Clusters parados ou desconectados

Conforme descrito anteriormente, a desalocação manual de todos os nós de cluster por meio das APIs do Hyper-V, CLI ou MMC torna o cluster sem suporte.

Os clusters que são interrompidos por mais de 90 dias não podem mais ser atualizados. Os planos de controle para clusters nesse estado ficam sem suporte após 30 dias e não podem ser atualizados para a versão mais recente.

O cluster de gerenciamento no AKS Arc deve ser capaz de se conectar ao Azure por meio do tráfego de saída HTTPS para pontos de extremidade conhecidos do Azure pelo menos a cada 30 dias para manter as operações de dia 2, como atualização e dimensionamento do pool de nós. Se o cluster de gerenciamento for desconectado dentro do período de 30 dias, as cargas de trabalho continuarão a ser executadas e funcionarão conforme o esperado até que o cluster de gerenciamento e/ou o Local do Azure se reconectem e sincronizem com o Azure. Depois de reconectadas, todas as operações do dia 2 devem se recuperar e continuar conforme o esperado. Consulte Requisitos de conectividade do Azure Local do Azure para obter mais informações. Após 30 dias, o Azure Local impede a criação de novas máquinas virtuais.

Se o cluster estiver em execução no Windows Server 2019 ou Windows Server 2022, a plataforma de host subjacente não terá o requisito de conexão recorrente de 30 dias.

Observação

O início/fim do período de 30 dias pode ser diferente do período de validade no AKS Arc e no Azure Local. Interromper ou desalocar manualmente todos os nós de cluster por meio das APIs/CLI/MMC do Hyper-V por períodos prolongados superiores a 30 dias e fora dos procedimentos de manutenção regulares torna o cluster sem suporte.

Assinatura excluída ou suspensa

Se sua assinatura do Azure for suspensa ou excluída, seus clusters do AKS ficarão sem suporte após 60 dias, a menos que a assinatura seja restabelecida antes que o limite de 60 dias seja atingido. Todas as outras limitações descritas anteriormente também se aplicam. Depois que a assinatura é excluída, a conexão do cluster com o Azure não pode ser recuperada e o Azure Local e o AKS Arc devem ser reimplantados para poder se reconectar ao Azure.

Recursos beta e de visualização do Kubernetes sem suporte

O AKS Arc só dá suporte a recursos estáveis e beta no projeto upstream do Kubernetes. A menos que documentado de outra forma, o AKS Arc não dá suporte a nenhum recurso de visualização disponível no projeto Kubernetes upstream.

Versões prévias dos recursos ou sinalizadores de recurso

Para recursos e funcionalidades que exigem testes estendidos e comentários do usuário, a Microsoft lança novas versões prévias dos recursos ou recursos por trás de um sinalizador de recurso. Considere estes recursos de pré-lançamento ou beta. As versões prévias dos recursos ou os recursos do sinalizador de recurso não são destinados à produção. As alterações contínuas em APIs e comportamento, correções de bugs e outras alterações podem resultar em clusters e tempo de inatividade instáveis.

Os recursos em visualização pública recebem suporte de "melhor esforço", pois esses recursos estão em versão prévia e não se destinam à produção. Esses recursos são compatíveis com as equipes de suporte técnico do AKS Arc somente durante o horário comercial. Para obter mais informações, consulte as perguntas frequentes sobre suporte do Azure.

Problemas e bugs de upstream

Devido à velocidade de desenvolvimento no projeto upstream do Kubernetes, invariavelmente surgem bugs. Alguns desses bugs não podem ser corrigidos ou contornados no sistema AKS Arc. Em vez disso, as correções de bugs exigem patches maiores para os projetos upstream (como Kubernetes, sistemas operacionais de nó ou do agente e kernel). Para componentes que a Microsoft possui (como os provedores de API de cluster para Azure Local), o AKS Arc e a equipe do Azure estão comprometidos em corrigir problemas upstream na comunidade.

Quando um problema de suporte técnico é causado por um ou mais bugs upstream, as equipes de suporte e engenharia do AKS Arc farão o seguinte:

  • Identificar e vincular os bugs anteriores com os detalhes de suporte para ajudar a explicar por que esse problema afeta o cluster ou a carga de trabalho. Os clientes recebem links para os repositórios necessários para que possam observar os problemas e ver quando uma nova versão fornecerá correções.
  • Fornecer possíveis soluções alternativas ou uma mitigação. Se o problema puder ser atenuado, um problema conhecido será arquivado no AKS no Azure Local e no repositório do Windows Server. O arquivamento de problemas conhecidos explica:
    • O problema, incluindo links para bugs de upstream.
    • A solução alternativa e os detalhes sobre uma atualização ou outra opção para a solução.
    • Linhas do tempo aproximadas para a inclusão do problema, com base na cadência da versão de upstream.

Próximas etapas