Políticas de suporte para o Azure Kubernetes Service

Este artigo descreve as políticas e limitações de suporte técnico para o Serviço Kubernetes do Azure (AKS). Ele também detalha o gerenciamento do nó do agente, os componentes do plano de controle gerenciado, os componentes de código aberto de terceiros e o gerenciamento de segurança ou patch.

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

• Para obter informações sobre a versão, consulte as notas de versão do AKS.
• Para obter informações sobre recursos de visualização, consulte o roteiro do AKS.

Recursos gerenciados no AKS

Os componentes de nuvem de infraestrutura básica 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 fornece uma implantação completa do Kubernetes que oferece um conjunto comum de configurações e recursos necessários para o cluster. Como usuário do AKS, você tem opções limitadas de personalização e implantação. Em troca, você não precisa se preocupar ou gerenciar clusters do Kubernetes diretamente.

Com o AKS, você obtém um plano de controle totalmente 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 e opera todos os componentes do Kubernetes.

A Microsoft gerencia e monitora os seguintes componentes através do plano de controle:

• Servidores de API Kubelet ou 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, exceto quando BYOCNI é usado
• Qualquer outro complemento ou componente do sistema em execução no namespace kube-system.

O AKS não é uma solução de plataforma como serviço (PaaS). Alguns componentes, como nós de agente, têm responsabilidade compartilhada, onde você deve ajudar a manter o cluster AKS. A entrada do usuário é necessária, por exemplo, para aplicar um patch de segurança do sistema operacional (SO) do nó do agente.

Os serviços são gerenciados no sentido de que a Microsoft e a equipe AKS implantam, operam e são responsáveis pela disponibilidade e funcionalidade do serviço. Os clientes não podem alterar esses componentes gerenciados. A Microsoft limita a personalização para garantir uma experiência de usuário consistente e escalável.

Responsabilidade partilhada

Quando um cluster é criado, você define os nós do agente Kubernetes que o AKS 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 pode acessá-los apenas de forma limitada. O Suporte da Microsoft não pode entrar, executar comandos ou exibir logs para esses nós sem sua permissão ou assistência expressa.

Qualquer modificação feita diretamente nos nós do agente usando qualquer uma das APIs IaaS torna o cluster insuportável. Qualquer modificação aplicada aos nós do agente deve ser feita usando mecanismos nativos do kubernetes, como Daemon Sets.

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

Cobertura de suporte AKS

A Microsoft fornece suporte técnico para os seguintes exemplos:

• Conectividade com todos os componentes do Kubernetes que o serviço Kubernetes fornece e suporta, como o servidor de API.
• Gerenciamento, tempo de atividade, QoS e operações de 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. O suporte inclui backups automatizados e transparentes de todos os dados etcd a cada 30 minutos para planejamento de desastres e restauração do estado do cluster. Esses backups não estão disponíveis diretamente para você ou qualquer outra pessoa. Garantem a fiabilidade e a consistência dos dados. A reversão ou restauração sob demanda não é suportada como um recurso.
• Qualquer ponto de integração no driver do provedor de nuvem do Azure para Kubernetes. Isso inclui integrações em outros serviços do Azure, como balanceadores de carga, volumes persistentes ou rede (Kubernetes e Azure CNI, exceto quando o BYOCNI está em uso).
• Perguntas ou problemas sobre a personalização de componentes do plano de controle, como o servidor de API do Kubernetes, etcd e coreDNS.
• Problemas sobre rede, como CNI do Azure, kubenet ou outros problemas de acesso e funcionalidade à rede, exceto quando o BYOCNI está em uso. Os problemas podem incluir resolução de DNS, perda de pacotes, roteamento e assim por diante. A Microsoft suporta vários cenários de rede:
  • Kubenet e Azure CNI usando VNETs gerenciadas ou com sub-redes personalizadas (traga suas próprias).
  • Conectividade com outros serviços e aplicativos do Azure
  • Controladores de entrada e configurações de ingresso ou balanceador de carga
  • Desempenho e latência da rede
  • Políticas de rede

Nota

Todas as ações de cluster tomadas pela Microsoft/AKS são feitas com o seu consentimento sob uma função aks-service Kubernetes interna e vinculação aks-service-rolebindingde função interna. Essa função permite que o AKS solucione e diagnostique problemas de cluster, mas não pode modificar permissões nem criar funções ou associações de função ou outras ações de alto privilégio. O acesso à função só é habilitado em tíquetes de suporte ativo com acesso just-in-time (JIT).

A Microsoft não fornece suporte técnico para os seguintes cenários:

• 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 a funcionalidade, personalização e ajuste do cluster AKS (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 com clusters AKS. 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 provedor de nuvem do Kubernetes Azure ou outros bugs específicos do AKS, a Microsoft oferece suporte a 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.

• Plugins CNI personalizados ou de terceiros usados no modo BYOCNI .

• Cenários de stand-by e proativos. O Suporte da Microsoft fornece suporte reativo para ajudar a resolver problemas ativos de forma oportuna e profissional. No entanto, o suporte proativo ou em standby para ajudá-lo a eliminar riscos operacionais, aumentar a disponibilidade e otimizar o desempenho não é coberto. Os clientes elegíveis podem contactar a respetiva equipa de conta para serem nomeados para o serviço de Gestão de Eventos do Azure. É um serviço pago fornecido por engenheiros de suporte da Microsoft que inclui uma avaliação de risco de solução proativa e cobertura durante o evento.

Cobertura de suporte AKS para nós de agente

Responsabilidades da Microsoft para nós do agente AKS

A Microsoft e você compartilham a responsabilidade pelos nós do agente Kubernetes onde:

• A imagem base do sistema operacional tem adições necessárias (como monitoramento e agentes de 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. Esses componentes incluem o seguinte:
  • Kube-proxy
  • Túneis de rede que fornecem caminhos de comunicação para os componentes mestre do Kubernetes
  • Kubelet
  • containerd

Nota

Se um nó de agente não estiver operacional, o AKS poderá reiniciar componentes individuais ou todo o nó do agente. Essas operações de reinicialização são automatizadas e fornecem correção automática para problemas comuns. Se você quiser saber mais sobre os mecanismos de correção automática, consulte Reparo automático de nó

Responsabilidades do cliente para nós do agente AKS

A Microsoft fornece patches e novas imagens para os nós de imagem semanalmente, 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 regular de atualização de imagem do nó ou automatizá-lo.

Da mesma forma, o AKS 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 dos seus clusters atualizada e de acordo com a Política de Versão de Suporte do Kubernetes do AKS.

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

Nota

Os nós do agente AKS aparecem no portal do Azure como recursos IaaS padrão do Azure. No entanto, essas máquinas virtuais são implantadas em um grupo de recursos personalizado do Azure (prefixado com MC_*). Não é possível alterar a imagem base do sistema operacional ou fazer personalizações diretas nesses nós usando as APIs ou recursos IaaS. Quaisquer alterações personalizadas que não sejam realizadas a partir da API AKS não persistirão através de uma atualização, escala, atualização ou reinicialização. Além disso, qualquer alteração nas extensões dos nós, como CustomScriptExtension, pode levar a um comportamento inesperado e deve ser proibida. Evite executar alterações nos nós do agente, a menos que o Suporte da Microsoft o oriente a fazer alterações.

O AKS gerencia o ciclo de vida e as operações dos nós do agente em seu nome e não há suporte para a modificação dos recursos IaaS associados aos nós do agente. Um exemplo de uma operação sem suporte é a personalização de uma escala de máquina virtual de pool de nós definida alterando manualmente as configurações no portal do Azure ou na API.

Para configurações ou pacotes específicos da carga de trabalho, o AKS recomenda o uso do Kubernetes daemon sets.

O uso de contêineres privilegiados daemon sets e init do Kubernetes permite que você ajuste/modifique ou instale software de terceiros nos nós do agente de cluster. Exemplos de tais personalizações incluem a adição de software de verificação de segurança personalizado ou a atualização das configurações do sysctl.

Embora esse caminho seja recomendado se os requisitos acima se aplicarem, a engenharia e o suporte do AKS não podem ajudar a solucionar problemas ou diagnosticar 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, a equipe do AKS corrige todos os clusters afetados para mitigar o problema. Como alternativa, a equipe AKS fornece orientação de atualização.

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.

Manutenção e acesso ao nó

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

Portas de rede, acesso e NSGs

Você só pode personalizar os NSGs em sub-redes personalizadas. Você não pode personalizar NSGs em sub-redes gerenciadas ou no nível NIC dos nós do agente. O AKS tem requisitos de saída para pontos de extremidade específicos, para controlar a saída e garantir a conectividade necessária, consulte limitar o tráfego de saída. Para ingresso, os requisitos são baseados nos aplicativos que você implantou no cluster.

Nós parados, deslocalizados e não prontos

Se você não precisar que suas cargas de trabalho do AKS sejam executadas continuamente, você pode parar o cluster AKS, que para todos os nodepools e o plano de controle. Você pode iniciá-lo novamente quando necessário. Quando você interrompe um cluster usando o az aks stop comando, o estado do cluster é preservado por até 12 meses. Após 12 meses, o estado do cluster e todos os seus recursos são excluídos.

Não há suporte para a deslocalização manual de todos os nós de cluster das APIs IaaS, da CLI do Azure ou do portal do Azure para interromper um cluster ou pool de nós AKS. O cluster será considerado fora de suporte e interrompido pela AKS após 30 dias. Os clusters estão sujeitos à mesma política de preservação de 12 meses que um cluster interrompido corretamente.

Clusters com zero nós Ready (ou todos Not Ready) e zero VMs em execução serão interrompidos após 30 dias.

A AKS reserva-se o direito de arquivar planos de controlo que tenham sido configurados fora das diretrizes de suporte por períodos prolongados iguais e superiores a 30 dias. O AKS mantém backups de metadados etcd do cluster e pode realocar prontamente o cluster. Essa realocação é iniciada por qualquer operação PUT que traga o cluster de volta ao suporte, como uma atualização ou dimensionamento para nós de agente ativos.

Todos os clusters em uma assinatura suspensa serão interrompidos imediatamente e excluídos após 90 dias. Todos os clusters em uma assinatura excluída serão excluídos imediatamente.

Recursos do Kubernetes alfa e beta não suportados

O AKS suporta apenas recursos estáveis e beta dentro do projeto Kubernetes upstream. A menos que documentado de outra forma, o AKS não suporta nenhum recurso alfa 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 esses recursos como 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 se enquadram no suporte de melhor esforço , pois esses recursos estão em visualização e não se destinam à produção. As equipes de suporte técnico da AKS fornecem suporte apenas durante o horário comercial. Para obter mais informações, consulte Perguntas frequentes do 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. 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 o provedor de nuvem do Azure), o AKS e o pessoal do Azure estão comprometidos em corrigir problemas upstream na comunidade.

Quando a causa raiz de um problema de suporte técnico é devido a um ou mais bugs upstream, as equipes de suporte e engenharia do AKS irão:

• 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 repositório AKS. 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 persistência da solução.
  • Cronogramas aproximados para a inclusão do problema, com base na cadência de lançamento upstream.