Políticas de Suporte para Azure Kubernetes Service

Este artigo descreve políticas de suporte técnico e limitações para o Azure Kubernetes Service (AKS). Também detalha a gestão de nós de agente, componentes geridos do plano de controlo, componentes de código aberto que não são da Microsoft e a gestão de segurança ou de correções.

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

• Para informações sobre lançamentos, consulte notas de lançamento AKS.
• Para informações sobre funcionalidades de pré-visualização, consulte o roteiro AKS.

Recursos gerenciados no AKS

O AKS é uma combinação de Infraestrutura como Serviço (IaaS) e Plataforma como Serviço (PaaS). Os componentes base da cloud IaaS, como componentes de computação ou de rede, fornecem acesso a controlos 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 utilizador de AKS, tens opções limitadas de personalização e implementação e não geres clusters 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 gere e monitoriza os seguintes componentes através do plano de controlo:

• O servidor de API do Kubernetes e kubelet.
• etcd ou um armazenamento de chave-valor compatível, fornecendo Qualidade de Serviço (QoS), escalabilidade e runtime.
• Serviços DNS como o CoreDNS.
• kube-proxy e redes em cluster, exceto quando é usado BYOCNI .
• Qualquer outro add-on ou componente do sistema em execução no namespace kube-system.

Alguns componentes, como os nós agente, têm responsabilidade partilhada, onde 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 geridos no sentido em que a Microsoft e a equipa AKS implementam, operam e são responsáveis pela disponibilidade e funcionalidade dos serviços. Os clientes não podem alterar esses componentes gerenciados. A Microsoft limita a personalização para garantir uma experiência de utilizador consistente e escalável.

Responsabilidade partilhada

Quando crias um cluster, defines os nós agentes Kubernetes que o AKS cria. As suas cargas de trabalho correm nestes nós. Tenha em mente as seguintes restrições dos nós agentes:

• O Suporte da Microsoft tem acesso limitado. Como os seus nós agente executam código privado e armazenam dados sensíveis, o Suporte da Microsoft não pode iniciar sessão, executar comandos ou visualizar registos para estes nós sem a sua permissão ou assistência expressa.
• Use mecanismos nativos do Kubernetes para as alterações. Qualquer modificação feita diretamente aos nós agentes através das APIs IaaS torna o cluster insuportável. Aplique alterações usando mecanismos nativos do Kubernetes, como um DaemonSet.
• Não altere os metadados criados pelo sistema. Pode adicionar metadados, como tags e rótulos. No entanto, alterar quaisquer metadados criados pelo sistema faz com que o cluster deixe de ter suporte.

Divisão de responsabilidade

A matriz seguinte resume a responsabilidade de suporte num cluster AKS e contrasta o AKS com o Kubernetes autogerido que executa localmente. No AKS, a Microsoft gere o plano de controlo e a plataforma central. Geres a configuração dos teus nós, cargas de trabalho, configuração de rede e dados. As áreas partilhadas são onde a Microsoft fornece e mantém uma funcionalidade e você a ativa, configura ou agenda. Utilize a matriz como guia de referência rápida e, em seguida, consulte as secções detalhadas abaixo para obter informações específicas sobre o suporte.

Use a seguinte chave para ler a matriz:

Para as áreas partilhadas na matriz seguinte, a tabela mostra o que a Microsoft fornece e pelo que é responsável:

Cobertura de suporte AKS

As secções seguintes descrevem os cenários suportados e não suportados para o suporte técnico do AKS.

Cenários suportados

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

Quaisquer ações no cluster realizadas pela Microsoft ou pelo AKS são efetuadas com o seu consentimento ao abrigo de uma função aks-service predefinida do Kubernetes e de uma associação de função aks-service-rolebinding predefinida, que associa a função à identidade de serviço aks-support do Suporte da Microsoft. Este papel permite ao AKS resolver problemas e diagnosticar problemas de cluster, mas não pode modificar permissões, criar funções ou atribuições de papéis, nem realizar outras ações de alto privilégio. O acesso a funções só é ativado em pedidos de suporte ativo com acesso JIT (just-in-time).

Cenários não suportados

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

Alguns destes cenários têm mais nuances sobre o que a Microsoft ainda pode ajudar. Para mais informações, consulte Detalhes sobre cenários não suportados.

Detalhes sobre cenários não suportados

Vários cenários não suportados acrescentaram nuances sobre o que a Microsoft ainda pode ajudar:

• Como usar o Kubernetes. O Suporte da Microsoft não fornece conselhos sobre como criar controladores de entrada personalizados, usar cargas de trabalho de aplicações ou aplicar pacotes ou ferramentas de software que não sejam da Microsoft ou open-source. O Suporte da Microsoft pode aconselhar sobre a funcionalidade, personalização e afinação do cluster AKS (por exemplo, questões e procedimentos operacionais do Kubernetes).
• Projetos open-source que não sejam da Microsoft. Estes projetos não são fornecidos como parte do plano de controlo Kubernetes nem implementados com clusters AKS, podendo incluir Istio, Helm, Envoy ou outros. A Microsoft pode fornecer suporte de melhor esforço para projetos como o Helm. Quando a ferramenta se integra com o fornecedor de cloud do Azure para o Kubernetes ou quando ocorrem outros erros específicos do AKS, a Microsoft presta suporte a exemplos e aplicações baseados na documentação da Microsoft.
• Personalizações de rede. Para personalizações além das listadas na documentação do AKS, o Suporte da Microsoft não pode configurar dispositivos ou dispositivos virtuais destinados a fornecer tráfego de saída para o cluster, como VPNs ou firewalls. Numa base de melhor esforço, o Suporte da Microsoft pode aconselhar sobre a configuração necessária para o Azure Firewall, mas não para outros dispositivos que não sejam da Microsoft.
• Controladores de entrada que não sejam da Microsoft. Para controladores como nginx, kong, ou traefik, isto inclui problemas de funcionalidade que surgem após operações específicas do AKS, como um controlador de entrada que deixa de funcionar após uma atualização da versão Kubernetes, que pode resultar de incompatibilidades entre a versão do controlador de entrada e a nova versão Kubernetes. Para uma opção totalmente suportada, considere uma opção de controlador de entrada gerida pela Microsoft.
• Scripts personalizados do DaemonSet. Embora a utilização DaemonSet seja a abordagem recomendada para ajustar, modificar ou instalar software não Microsoft em nós agentes quando os parâmetros dos ficheiros de configuração são insuficientes, o Suporte da Microsoft não consegue resolver problemas decorrentes dos scripts personalizados devido à sua natureza personalizada.
• Apoio em espera e proativo. O Suporte da Microsoft fornece suporte reativo para resolver problemas ativos. Apoio de prontidão ou proativo para eliminar riscos operacionais, aumentar a disponibilidade e otimizar o desempenho não está coberto. Os clientes elegíveis podem contactar a sua equipa de contas para serem nomeados para o serviço Azure Event Management, um serviço pago que inclui uma solução proativa, avaliação de risco e cobertura durante o evento.
• CVEs com menos de 30 dias. Desde que executes o VHD atualizado, não deverás ter quaisquer CVEs em imagens de contentor para os quais exista uma correção do fornecedor há mais de 30 dias. É tua responsabilidade atualizar o VHD, depois filtrar o relatório CVE e fornecer ao Suporte da Microsoft uma lista apenas dos CVEs com uma correção do fornecedor com mais de 30 dias. A Microsoft trabalha então internamente para resolver componentes com uma correção do fornecedor lançada há mais de 30 dias. A Microsoft fornece suporte relacionado com CVE apenas para componentes geridos pela Microsoft, como imagens de nós AKS e imagens de contentores geridos implementadas durante a criação do cluster ou através de um complemento gerido. Para mais informações, consulte Vulnerability management for Azure Kubernetes Service (AKS).
• Exemplos de código personalizados. O Suporte da Microsoft pode fornecer e rever pequenos exemplos de código dentro de um caso de suporte para demonstrar como usar funcionalidades de um produto Microsoft, mas não pode fornecer exemplos de código personalizados específicos para o seu ambiente ou aplicação.
• Lógica personalizada do Azure Policy. O Suporte da Microsoft pode fornecer orientações gerais sobre como definições personalizadas do Azure Policy são aplicadas e avaliadas no AKS. A resolução detalhada de problemas da lógica de políticas criada pelo cliente (incluindo políticas baseadas em Rego), como o motivo pelo qual uma política específica permite ou recusa uma carga de trabalho, está geralmente fora do âmbito do suporte.

Traga os seus próprios limites de apoio CNI

Quando implementa um cluster com o Bring your Own CNI (BYOCNI) usando --network-plugin none, o Suporte da Microsoft não pode ajudar com problemas relacionados com CNI. És responsável pelo ciclo de vida dos plugins CNI e deves procurar suporte junto do fornecedor dos plugins CNI. A Microsoft continua a suportar problemas que não estão relacionados com o CNI.

Para mais informações, consulte Traga o seu próprio CNI (BYOCNI).

Cobertura de suporte AKS para nós de agenciamento

As secções seguintes descrevem as responsabilidades da Microsoft e do cliente para os nós de agente do AKS.

A tabela seguinte resume rapidamente as responsabilidades dos nós agentes. As secções que se seguem fornecem o detalhe.

Responsabilidades da Microsoft em relação a nodos de agente AKS

Tu e a Microsoft partilham a responsabilidade pelos nós de agentes Kubernetes onde:

• A imagem base do sistema operativo inclui adições necessárias, tais como agentes de monitorização e rede.
• Os nós do agente recebem patches do sistema operacional automaticamente.
• O sistema resolve automaticamente problemas com os componentes do plano de controlo Kubernetes que funcionam nos nós agente. Estes componentes incluem os seguintes itens:
  • kube-proxy
  • Túneis de rede que fornecem caminhos de comunicação para o plano de controlo Kubernetes
  • kubelet
  • containerd

Se um nó de agente não estiver operacional, o AKS poderá reiniciar componentes individuais ou todo o nó do agente. Estas operações de reinício são automatizadas e fornecem remediação automática para problemas comuns. Para saber mais sobre os mecanismos de auto-remediação, consulte Reparação Automática de Nó.

Responsabilidades do cliente em relação a nós do agente AKS

A Microsoft fornece atualizações e novas imagens para os seus nós de imagem semanalmente. Para manter o sistema operacional do nó do agente e os componentes de tempo de execução atualizados, você deve aplicar esses patches e atualizações regularmente, manual ou automaticamente. A Microsoft não suporta imagens de nós com mais de 90 dias. Para obter mais informações, consulte:

• Atualize manualmente as imagens dos nós do AKS.
• Atualizar automaticamente as imagens dos nós do AKS.

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 de nós de agente pelo utilizador

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 não suportada é personalizar um grupo de escalonamento de máquinas virtuais de um pool de nós alterando manualmente as configurações no portal do Azure ou pela API.

Para configurações ou pacotes específicos de carga de trabalho, o AKS recomenda o uso de um Kubernetes DaemonSet.

A utilização de contentores privilegiados do Kubernetes DaemonSet e init permite-lhe ajustar/modificar ou instalar software que não seja da Microsoft nos nós de agente do 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 DaemonSetpersonalizada.

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 os agentes 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.

Manutenção de nós e acesso

Embora possas iniciar sessão nos nós de agente e modificá-los, não realizes esta operação. As alterações podem tornar um cluster insuportável.

Portas de rede, acesso e NSGs

Pode personalizar grupos de segurança de rede (NSGs) apenas em sub-redes personalizadas. A tabela seguinte mostra onde pode personalizar os NSGs:

O AKS tem requisitos de saída para endpoints específicos. Para controlar a saída e garantir a conectividade necessária, veja limitar o tráfego de saída. Para ingress, os requisitos baseiam-se nas aplicações que implementas no cluster.

Nós parados, deslocalizados e não prontos

A tabela seguinte resume o que acontece a um cluster AKS em cada estado do ciclo de vida e na linha temporal associada:

Se não precisares que as cargas de trabalho do AKS sejam executadas continuamente, pare o cluster do AKS, o que interrompe todos os conjuntos de nós e o plano de controlo, e reinicie-o quando necessário. Desalocar manualmente os nós através das APIs de IaaS, da CLI do Azure ou do portal do Azure não é um método suportado para parar um cluster.

O AKS reserva-se o direito de arquivar planos de controlo configurados fora das diretrizes de suporte por períodos de 30 dias ou mais. O AKS mantém backups dos metadados do cluster etcd e pode realocar o cluster em qualquer operação PUT que o volte a colocar num estado suportado, como uma atualização ou um dimensionamento para nós de agente ativos.

Recursos do Kubernetes alfa e beta não suportados

O AKS suporta funcionalidades estáveis e em versão beta no projeto Kubernetes, mas não funcionalidades alfa, salvo indicação em contrário na documentação. A tabela seguinte resume o suporte por tipo de funcionalidade:

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 em versão de avaliação pública enquadram-se no suporte de melhor esforço, pois esses recursos estão em versão de avaliação e não se destinam à produção. As equipas de apoio técnico da AKS prestam apoio apenas durante o horário comercial. Para mais informações, consulte Azure FAQ de Apoio.

Problemas e bugs de origem (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, correções de bugs exigem patches maiores para projetos a montante (como Kubernetes, sistemas operativos de nós ou agentes, e kernel). Para os componentes que a Microsoft possui (como o fornecedor de serviços cloud Azure), o pessoal da AKS e do Azure está empenhado em resolver problemas a montante 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 poderem acompanhar os problemas e ver quando uma nova versão oferece correções.
• Forneça possíveis soluções alternativas ou atenuação. Se o problema puder ser mitigado, um problema conhecido é arquivado no repositório AKS. O relatório 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 resolução do problema, com base na cadência de lançamento upstream.

Conteúdo relacionado

• Escalões de preços do AKS
• Versões do Kubernetes suportadas no AKS
• Apoio a longo prazo ao AKS
• Atualizar automaticamente um cluster AKS
• Atualização automática das imagens do sistema operativo dos nós AKS
• Gestão de vulnerabilidades para AKS
• Reparação automático do nó do AKS
• Traga o seu próprio CNI (BYOCNI)