Políticas de suporte do AKS ativadas 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 de suporte técnico e as limitações do AKS ativado pelo Arc. O artigo também descreve a gestão de nós de cluster, componentes do plano de controlo, componentes open source de terceiros e gestão de patches ou segurança.

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

  • A Microsoft oferece uma janela de suporte de 1 ano para cada versão secundária do Kubernetes, a partir da 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 do Kubernetes que opera numa versão secundária preterida tem de ser atualizado para uma versão suportada para ser elegível para suporte.
  • Assim que uma versão secundária for preterida, todos os clusters ainda em execução nesta versão continuarão a funcionar. Ainda pode realizar operações como aumentar ou reduzir verticalmente, mas o AKS Arc apresenta um aviso durante as operações do cluster.
  • Assim que uma versão secundária for preterida, esta é removida dos servidores da Microsoft. Nessa altura, os clusters do Kubernetes que utilizam esta versão não conseguem atualizar o Kubernetes ou as versões do SO e têm de ser atualizados para a versão mais recente. Em alguns casos, esta atualização também pode significar uma nova implementação completa se o sistema não estiver em bom estado de funcionamento.

Para obter informações sobre a versão, veja as notas de versão do AKS Arc. Para obter informações sobre as funcionalidades em pré-visualização, veja Funcionalidades de pré-visualização do AKS Arc.

Funcionalidades geridas no AKS Arc

Como utilizador do AKS Arc, tem opções de personalização e implementação limitadas. No entanto, não precisa de se preocupar ou gerir diretamente o plano de controlo e a instalação do cluster do Kubernetes. Os componentes de cloud de infraestrutura como serviço (IaaS), como componentes de computação ou de rede, permitem-lhe aceder a controlos de baixo nível e opções de personalização.

Por outro lado, o AKS Arc fornece uma implementação chave na mão do Kubernetes que lhe dá o conjunto comum de configurações e capacidades de que precisa para o seu cluster. Com o AKS Arc, obtém um plano de controlo parcialmente gerido. O plano de controlo contém todos os componentes e serviços de que precisa para operar e fornecer clusters do Kubernetes aos utilizadores finais. A Microsoft mantém todos os componentes do Kubernetes.

A Microsoft mantém os seguintes componentes através do cluster de gestão e das imagens de base de máquinas virtuais associadas:

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

O AKS Arc não é uma solução PaaS (Plataforma como Serviço). Alguns componentes, como clusters de cargas de trabalho, plano de controlo e nós de trabalho, têm responsabilidade partilhada. Os utilizadores têm de ajudar a manter o cluster do Kubernetes. A entrada do utilizador é necessária, por exemplo, para aplicar um patch de segurança do sistema operativo (SO) ou atualizar para uma versão mais recente do Kubernetes.

Os serviços são geridos no sentido em que a Microsoft e a equipa do AKS fornecem as ferramentas que implementam o cluster de gestão, o plano de controlo e os nós de agente para clusters de cargas de trabalho. Não pode alterar estes componentes geridos. A Microsoft limita a personalização para garantir uma experiência de utilizador consistente e dimensionável. Para obter uma solução totalmente personalizável na cloud, veja o motor do 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 garante qualquer runtime (ou outro) para clusters fora da lista de versões suportadas. "Fora do suporte" significa que:

  • O cluster funciona numa versão secundária preterida. A versão que está a executar está fora da lista de versões suportadas.
  • É-lhe pedido que atualize o cluster para uma versão suportada ao pedir suporte.

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

O AKS Arc segue os timeframes 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, veja as políticas de suporte:

Responsabilidade partilhada

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

Uma vez que os nós do agente executam código privado e armazenam dados confidenciais, Suporte da Microsoft tem acesso limitado aos mesmos. Suporte da Microsoft não consegue iniciar sessão para executar comandos ou ver registos destes nós sem a sua permissão expressa ou assistência. Qualquer modificação direta dos nós do agente através de qualquer uma das APIs IaaS torna o cluster inuportável. Qualquer modificação efetuada aos nós do agente tem de ser efetuada com mecanismos nativos do Kubernetes, como Daemon Sets.

Da mesma forma, embora possa adicionar metadados, como etiquetas e etiquetas, ao cluster e aos nós, alterar qualquer um dos metadados criados pelo sistema torna o cluster não suportado.

Cobertura de suporte do AKS Arc

A Microsoft fornece suporte técnico para as seguintes funcionalidades e componentes:

  • Conectividade a todos os componentes do Kubernetes que o serviço Kubernetes fornece e suporta, como o servidor de API.
  • Serviços do plano de controlo do Kubernetes (por exemplo, plano de controlo do Kubernetes, servidor de API, etc. e coreDNS).
  • Arquivo 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 controlo, como o servidor de API do Kubernetes, etc. e coreDNS.
  • Problemas com a rede, o acesso à rede e a funcionalidade. Os problemas podem incluir resolução de DNS, perda de pacotes e encaminhamento. A Microsoft suporta vários cenários de rede:
    • Suporte de instalação básico para Flannel e Calico CNI. Estes CNIs são orientados pela comunidade e suportados. Suporte da Microsoft fornece apenas suporte básico de instalação e configuração.
    • Conectividade a outros serviços e aplicações do Azure.
    • Controladores de entrada e configuração do balanceador de entrada ou de carga.
    • Desempenho e latência da rede.

Nota

Todas as ações de cluster executadas pelas equipas de suporte do Arc do Microsoft AKS são efetuadas com o consentimento e assistência do utilizador. 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 nas seguintes áreas:

  • Perguntas sobre como utilizar o Kubernetes. Por exemplo, Suporte da Microsoft não fornece conselhos sobre como criar controladores de entrada personalizados, utilizar cargas de trabalho de aplicações ou aplicar pacotes ou ferramentas de software open source ou de terceiros.

    Nota

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

  • Projetos open source de terceiros que não são fornecidos como parte do plano de controlo do Kubernetes ou implementados quando os clusters são criados no AKS Arc. Estes projetos podem incluir Istio, Helm, Envoy ou outros.

    Nota

    A Microsoft pode fornecer suporte de melhor esforço para projetos open source de terceiros, como o Helm. Quando a ferramenta open source de terceiros se integra com o Kubernetes ou outros erros específicos do AKS Arc, a Microsoft suporta exemplos e aplicações da documentação da Microsoft.

  • Software de origem fechada de terceiros. Este software pode incluir ferramentas de análise 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 para os nós de agente do AKS Arc

A Microsoft e os utilizadores partilham a responsabilidade pelos nós de agente do Kubernetes em que:

  • As adições necessárias à imagem de SO base (como agentes de monitorização e de rede).

  • Os nós do agente recebem patches de SO automaticamente.

  • Os problemas com os componentes do plano de controlo do Kubernetes que são executados nos nós do agente são remediados automaticamente durante o ciclo de atualização ou quando reimplementa um nó de agente. Estes componentes incluem:

    • kube-proxy
    • Túneis de rede que fornecem caminhos de comunicação para os componentes principais 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. Estas operações de reinício automatizadas fornecem remediação automática para problemas comuns.

Responsabilidades do cliente para os nós de 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 predefinição. Para manter o SO do nó do agente e os componentes de runtime corrigidos, deve manter uma agenda 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. Estas atualizações podem conter melhorias de segurança ou funcionalidade no Kubernetes. É responsável por manter a versão do Kubernetes dos clusters atualizada de acordo com a política de versões suportadas pelo AKS Arc.

Personalização de utilizadores de nós de agente

Nota

Os nós de agente do AKS Arc aparecem no Hyper-V como recursos de máquinas virtuais normais. Estas máquinas virtuais são implementadas com uma imagem personalizada do SO e componentes do Kubernetes suportados e geridos. Não pode alterar a imagem de SO base nem efetuar personalizações diretas a estes nós através das APIs ou recursos do Hyper-V. Quaisquer alterações personalizadas que não sejam efetuadas através da API AKS-HCI não persistem através de uma atualização, dimensionamento, atualização ou reinício e podem compor o cluster sem suporte. Evite efetuar alterações aos nós do agente, a menos que Suporte da Microsoft o direcione para efetuar alterações.

O AKS Arc gere o ciclo de vida e as operações das imagens do nó do agente em seu nome. A modificação dos recursos associados aos nós de agente não é suportada. Por exemplo, a personalização das definições de rede de uma máquina virtual ao alterar manualmente as configurações através da API ou ferramentas do Hyper-V não é suportada.

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

Quando utiliza contentores com privilégios daemon sets e init do Kubernetes, pode otimizar/modificar ou instalar software de terceiros em nós de agente de cluster. Por exemplo, pode adicionar software de análise de segurança personalizado ou definições de atualização sysctl . Embora este caminho seja recomendado se os requisitos anteriores se aplicarem, a engenharia e o suporte do AKS Arc não podem ajudar na resolução de problemas ou no diagnóstico de modificações que tornam o nó indisponível devido a uma implementação daemon setpersonalizada.

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

Se for encontrada uma falha de segurança num ou mais componentes geridos do AKS Arc, a equipa do AKS Arc corrige todas as imagens do SO afetadas para mitigar o problema e a equipa fornece orientações de atualização aos utilizadores.

Para nós de agente afetados por uma falha de segurança, a Microsoft notifica-o com detalhes sobre o impacto e os passos para corrigir ou mitigar o problema de segurança. Normalmente, os passos incluem uma atualização da imagem de nó ou uma atualização de patch de cluster.

Manutenção e acesso de nós

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

Portas de rede, conjuntos IP e acesso

Só pode personalizar as definições de rede com sub-redes definidas pelo AKS Arc. Não pode personalizar as definições de rede ao nível da NIC dos nós do agente. O AKS Arc tem requisitos de saída para pontos finais específicos, para controlar a saída e garantir a conectividade necessária. Para obter mais informações, veja Requisitos de sistema do AKS Arc.

Clusters parados ou desligados

Conforme indicado anteriormente, a desalocação manual de todos os nós de cluster através das APIs hyper-V, da CLI ou da MMC elimina o suporte do cluster.

Os clusters parados há mais de 90 dias já não podem ser atualizados. Os planos de controlo para clusters neste estado não têm suporte após 30 dias e não podem ser atualizados para a versão mais recente.

O cluster de gestão no AKS Arc tem de conseguir ligar-se ao Azure através do tráfego de saída HTTPS para pontos finais do Azure conhecidos, pelo menos a cada 30 dias, para manter as operações do dia 2, como a atualização e o dimensionamento do conjunto de nós. Se o cluster de gestão estiver desligado dentro do período de 30 dias, as cargas de trabalho continuarão a ser executadas e a funcionar conforme esperado até que o cluster de gestão e o Azure Stack HCI se liguem e sincronizem com o Azure. Uma vez novamente ligadas, as operações do dia 2 devem recuperar e continuar conforme esperado. Veja Azure Stack HCI Azure connectivity requirements (Requisitos de conectividade do Azure do Azure no 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 Windows Server 2022, a plataforma anfitriã subjacente não tem o requisito de ligação periódica 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 de cluster através das APIs de Hyper-V/CLI/MMC por períodos prolongados superiores a 30 dias e fora dos procedimentos de manutenção regulares torna o cluster fora do suporte.

Subscrição eliminada ou suspensa

Se a subscrição do Azure for suspensa ou eliminada, os clusters do AKS ficarão sem suporte após 60 dias, a menos que a subscrição seja restabelecida antes de atingir o limite de 60 dias. Todas as outras limitações descritas anteriormente também se aplicam. Depois de a subscrição ser eliminada, não é possível recuperar a ligação do cluster ao Azure e o Azure Stack HCI e o AKS Arc têm de ser novamente implementados para poder voltar a ligar ao Azure.

Funcionalidades do Kubernetes de pré-visualização e beta não suportadas

O AKS Arc só suporta funcionalidades estáveis e beta no projeto kubernetes a montante. Salvo indicação em contrário, o AKS Arc não suporta nenhuma funcionalidade de pré-visualização disponível no projeto kubernetes a montante.

Funcionalidades de pré-visualização ou sinalizadores de funcionalidades

Para funcionalidades que requerem testes alargados e comentários dos utilizadores, a Microsoft lança novas funcionalidades ou funcionalidades de pré-visualização por trás de um sinalizador de funcionalidade. Considere estas funcionalidades de pré-lançamento ou beta. As funcionalidades de pré-visualização ou as funcionalidades de sinalizador de funcionalidades não se destinam à produção. As alterações em curso nas APIs e no comportamento, correções de erros e outras alterações podem resultar em clusters instáveis e tempo de inatividade.

As funcionalidades na pré-visualização pública recebem suporte de "melhor esforço", uma vez que estas funcionalidades estão em pré-visualização e não se destinam à produção. Estas funcionalidades são suportadas pelas equipas de suporte técnico do AKS Arc apenas durante o horário comercial. Para obter mais informações, veja as FAQ do suporte do Azure.

Erros e problemas a montante

Dada a velocidade de desenvolvimento no projeto do Kubernetes a montante, surgem erros invariavelmente. Alguns destes erros não podem ser corrigidos ou resolvidos no sistema AKS Arc. Em vez disso, as correções de erros requerem patches maiores para projetos a montante (como o Kubernetes, sistemas operativos de nó ou agente e kernel). Para os componentes que a Microsoft detém (como os fornecedores de API de cluster para o Azure Stack HCI), o AKS Arc e o pessoal do Azure estão empenhados em corrigir problemas a montante na comunidade.

Quando um problema de suporte técnico é causado por um ou mais erros a montante, as equipas de suporte e engenharia do AKS Arc farão o seguinte:

  • Identifique e ligue os erros a montante com quaisquer detalhes de suporte para ajudar a explicar por que motivo este problema afeta o cluster ou a carga de trabalho. Os clientes recebem ligações para os repositórios necessários para que possam watch os problemas e ver quando uma nova versão irá fornecer correções.
  • Forneça possíveis soluções alternativas ou mitigação. Se o problema puder ser mitigado, é apresentado um problema conhecido no AKS no Azure Stack HCI e no repositório do Windows Server. O ficheiro de problema conhecido explica:
    • O problema, incluindo ligações para erros a montante.
    • A solução e os detalhes sobre uma atualização ou outra opção para a solução.
    • Linhas cronológicas aproximadas para a inclusão do problema, com base na cadência de lançamento a montante.

Passos seguintes