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

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

  • 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 este período, o AKS Arc lança versões secundárias ou de patch subsequentes para garantir o suporte contínuo.
  • Um cluster Kubernetes que opera em uma versão secundária preterida deve ser atualizado para uma versão suportada para ser elegível para suporte.
  • Quando 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 aumentar ou diminuir o dimensionamento, mas o AKS Arc exibe um aviso durante as operações de cluster.
  • Quando 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 os recursos na visualização, 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 de cluster do Kubernetes e a instalação diretamente. Os componentes de nuvem de infraestrutura como serviço (IaaS) de base, como componentes de computação ou de 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 completa do Kubernetes que oferece o conjunto comum de configurações e recursos necessários para seu cluster. Com o AKS Arc, você obtém um plano de controle parcialmente gerenciado. O plano de controle contém todos os componentes e serviços necessários para operar e fornecer clusters 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 de base da máquina virtual associadas:

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

O AKS Arc não é uma solução de plataforma como serviço (PaaS). 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 AKS fornecem as ferramentas que implantam o cluster de gerenciamento, o plano 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 escalável. Para uma solução totalmente personalizável na nuvem, consulte o mecanismo AKS.

Política de versão suportada

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

O AKS Arc não faz nenhuma garantia de tempo de execução (ou outras) para clusters fora da lista de versões suportadas. "Fora do apoio" significa que:

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

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

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

Responsabilidade partilhada

Quando um cluster é criado, você define os nós do agente 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 IaaS torna o cluster insuportá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, 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 Kubernetes fornece e suporta, como o servidor de API.
  • Serviços de 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 Faturação do Azure.
  • Perguntas ou problemas sobre a personalização de componentes do plano 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 suporta vários cenários de rede:
    • Suporte básico de instalação para Flannel e Calico CNI. Estas CNIs são orientadas e apoiadas 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 ingresso ou balanceador de carga.
    • Desempenho e latência da rede.

Nota

Todas as ações de cluster tomadas pelas equipes de suporte do Microsoft AKS Arc são feitas com o consentimento e assistência do usuário. O Suporte da Microsoft não inicia sessão no cluster a menos que 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 fornece conselhos sobre como criar controladores de entrada personalizados, usar cargas de trabalho de aplicativos ou aplicar pacotes ou ferramentas de software de terceiros ou de código aberto.

    Nota

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

  • Projetos de código aberto de terceiros que não são fornecidos como parte do plano de controle do Kubernetes ou implantados quando clusters são criados no AKS Arc. Esses projetos podem incluir Istio, Helm, Envoy ou outros.

    Nota

    A Microsoft pode fornecer suporte de melhor esforço para projetos de código aberto de terceiros, como o Helm. Onde a ferramenta de código aberto de terceiros se integra com o Kubernetes ou outros bugs específicos do AKS Arc, a Microsoft suporta exemplos e aplicativos da documentação da Microsoft.

  • Software de código fechado de terceiros. Este software pode incluir ferramentas de verificação de segurança e dispositivos de rede ou software.

  • 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 pelos nós do agente AKS Arc

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

  • A imagem base do sistema operacional exigiu adições (como agentes de monitoramento e rede).
  • Os nós do agente recebem patches do sistema operacional automaticamente.
  • 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 mestre do Kubernetes:
      • kubelet
      • Moby ou ContainerD

Nota

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 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 tempo de execução corrigidos, você deve manter um cronograma de atualização regular ou automatizar a aplicação de patches.

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

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

Nota

Os nós do agente 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 Kubernetes suportados e gerenciados. Não é possível alterar a imagem base do sistema operacional ou fazer personalizações diretas nesses nós usando as APIs ou recursos do Hyper-V. Quaisquer alterações personalizadas que não sejam feitas por meio da API 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 executar alterações nos nós do agente, a menos que o Suporte da Microsoft o oriente a fazer alterações.

O AKS Arc gerencia o ciclo de vida e as operações das imagens do 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 a personalização das 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 da carga de trabalho, você deve usar conjuntos de daemon do Kubernetes.

Ao usar contêineres privilegiados daemon sets e init 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 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 podem 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 patches

Se uma falha de segurança for encontrada em um ou mais dos componentes gerenciados do AKS Arc, a equipe do AKS Arc corrige todas as imagens do sistema operacional afetadas para mitigar o problema, e a equipe fornece orientação 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 mitigar 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 ao 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 endpoints 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 descrito anteriormente, a desalocação manual de todos os nós do cluster por meio das APIs do Hyper-V, CLI ou MMC torna o cluster sem suporte.

Os clusters interrompidos por mais de 90 dias não podem mais ser atualizados. Os planos de controle para clusters nesse estado estão fora de 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 do 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 Azure Stack HCI se reconectem e sincronizem com o Azure. Uma vez reconectadas, todas as operações do dia 2 devem se recuperar e continuar conforme o esperado. Consulte Azure Stack HCI Requisitos de conectividade do Azure 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 sendo executado 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.

Nota

O início/fim 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 do 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.

Subscrição eliminada ou suspensa

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

Recursos de visualização e beta do Kubernetes não suportados

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

Visualizar recursos ou sinalizadores de recursos

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

Os recursos na visualização pública recebem suporte ao "melhor esforço", pois esses recursos estão em visualização e não se destinam à produção. Esses recursos são suportados pelas equipes de suporte técnico do AKS Arc apenas durante o horário comercial. Para obter mais informações, consulte as Perguntas frequentes de suporte do Azure.

Bugs e problemas upstream

Dada a velocidade de desenvolvimento no projeto Kubernetes upstream, bugs invariavelmente surgem. Alguns desses bugs não podem ser corrigidos ou resolvidos dentro do sistema AKS Arc. Em vez disso, as correções de bugs exigem patches maiores para projetos upstream (como Kubernetes, sistemas operacionais de nó ou 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 o pessoal 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:

  • Identifique e vincule os bugs upstream com quaisquer detalhes de suporte para ajudar a explicar por que esse problema afeta seu cluster ou 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.
  • Forneça possíveis soluções alternativas ou atenuação. Se o problema puder ser atenuado, um problema conhecido será arquivado no AKS no Azure Stack HCI e no repositório do Windows Server. O arquivo de problema conhecido explica:
    • O problema, incluindo links para bugs upstream.
    • A solução alternativa e os detalhes sobre uma atualização ou outra opção para a solução.
    • Cronogramas aproximados para a inclusão do problema, com base na cadência de lançamento upstream.

Próximos passos