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 as políticas e limitações de suporte técnico para o AKS habilitado pelo Arc. O artigo também descreve o gerenciamento de nós de cluster, componentes do painel de controle, componentes de software livre de terceiros e gerenciamento de patch ou segurança.

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 preterida deve ser atualizado para uma versão com suporte para ser qualificado para suporte.
  • Depois que uma versão secundária for preterida, todos os clusters ainda em execução nesta 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 o Kubernetes ou as versões do sistema operacional e devem ser atualizados para a versão mais recente. Em alguns casos, essa atualização também poderá significar a re-implantação completa se o sistema não estiver em um estado íntegro.

Para obter informações sobre a versão, confira as notas sobre a versão do AKS Arc. Para obter informações sobre recursos em versão prévia, consulte Recursos de versão prévia 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 nem gerenciar o plano de controle de cluster do Kubernetes e a instalação diretamente. Componentes de nuvem de IaaS (infraestrutura como serviço) base, como componentes de computação ou rede, permitem que você acesse controles de baixo nível e opções de personalização.

Por outro lado, o AKS Arc fornece uma implantação turnkey do Kubernetes que fornece o conjunto comum de configurações e funcionalidades necessárias 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 da máquina virtual associadas:

  • kubelet ou servidores de API do Kubernetes.
  • etcd ou um repositório de chave-valor compatível, fornecendo QoS (Qualidade de Serviço), escalabilidade e runtime.
  • 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, painel 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. Não é possível 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 períodos 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, Suporte da Microsoft tem acesso limitado a eles. Suporte da Microsoft não consegue entrar para executar comandos ou exibir logs para esses nós sem sua permissão expressa ou assistência. Qualquer modificação direta dos nós do agente usando qualquer uma das APIs de IaaS torna o cluster sem suporte. 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 quaisquer metadados, como marcas e rótulos, ao cluster e aos nós, alterar 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 painel de controle do Kubernetes (por exemplo, painel 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 à instalação para Flannel e CNI do Calico. Esses CNIs são orientados pela comunidade e têm suporte. 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 de rede.

Observação

Todas as ações de cluster executadas pelas equipes de suporte do Microsoft AKS Arc são feitas com consentimento e assistência do usuário. 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 nas 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

    Suporte da Microsoft pode aconselhar sobre funcionalidade de cluster, personalização e ajuste 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 daquelas listadas na documentação do AKS Arc.

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

Responsabilidades da Microsoft para nós do 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 monitoramento e agentes de rede).

  • Os nós do agente recebem patches do sistema operacional automaticamente.

  • Os problemas com os componentes do painel 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 master do Kubernetes:
      • kubelet
      • Moby ou ContainerD

Observação

Se um nó de 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 do agente do AKS Arc

A Microsoft fornece patches e novas imagens para os 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 runtime corrigidos, você deve manter uma agenda de atualização regular ou automatizar a aplicação de patch.

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 dos clusters 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 de máquina virtual regulares. Essas máquinas virtuais são implantadas com uma imagem personalizada do sistema operacional e com suporte e componentes gerenciados do Kubernetes. 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. 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, escala, 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 de 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 ferramentas do Hyper-V.

Para configurações ou pacotes específicos da 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 em nós do agente de cluster. Por exemplo, você pode adicionar software de verificação de segurança personalizado ou configurações de atualização sysctl . 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 uma implantação daemon setpersonalizada.

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 não é recomendada porque as alterações podem tornar um cluster sem suporte.

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 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 de sistema do AKS Arc.

Clusters interrompidos ou desconectados

Conforme mencionado anteriormente, a desalocação manual de todos os nós de cluster por meio das APIs do Hyper-V, da CLI ou do 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 estão 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 operações do dia 2, como atualização e dimensionamento do pool de nós. Se o cluster de gerenciamento estiver 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 o Azure Stack HCI se conectem novamente e sincronizem com o Azure. Uma vez conectadas novamente, todas as operações do dia 2 devem ser recuperadas e continuar conforme o esperado. Confira Requisitos de conectividade do Azure do Azure do Azure Stack HCI para obter mais informações. Após 30 dias, o Azure Stack HCI impede a criação de novas máquinas virtuais.

Se o cluster estiver em execução no Windows Server 2019 ou no 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/término do período de 30 dias pode ser diferente do período de validade no AKS Arc e no Azure Stack HCI. Parar 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, os 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 de cluster com o Azure não pode ser recuperada e o Azure Stack HCI e o AKS Arc devem ser implantados novamente para poder se reconectar ao Azure.

Versão prévia sem suporte e recursos beta do Kubernetes

O AKS Arc dá suporte apenas a recursos estáveis e beta no projeto upstream Kubernetes. A menos que documentado de outra forma, o AKS Arc não dá suporte a nenhum recurso de versão prévia disponível no projeto upstream Kubernetes.

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 esses 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 na versão prévia pública recebem suporte de "melhor esforço", pois esses recursos estão em versão prévia e não são destinados à produção. Esses recursos são compatíveis apenas com as equipes de suporte técnico do AKS Arc 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 solucionados 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 o Azure Stack HCI), 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 uma ou mais upstream bugs, as equipes de engenharia e suporte 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 repositório do Azure Stack HCI e 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