Políticas de suporte para Serviço de Kubernetes do Azure

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

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

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

Recursos gerenciados no AKS

O AKS é uma combinação de IaaS (Infraestrutura como Serviço) e PaaS (Plataforma como Serviço). Componentes de nuvem iaaS base, como componentes de computação ou rede, fornecem acesso a controles de baixo nível e opções de personalização. Por outro lado, o AKS fornece uma implantação pronta para uso do Kubernetes que fornece um conjunto comum de configurações e funcionalidades de que você precisa para o cluster. Como usuário do AKS, você tem opções limitadas de personalização e implantação e não gerencia clusters do Kubernetes diretamente.

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

Microsoft gerencia e monitora os seguintes componentes por meio do plano de controle:

• O servidor de API do Kubernetes e kubelet.
• etcd ou um repositório de chave-valor compatível, fornecendo Qualidade de Serviço (QoS), escalabilidade e tempo de execução.
• Serviços DNS como o CoreDNS.
• kube-proxy e rede de cluster, exceto quando BYOCNI é usado.
• Todos os outros complementos ou componentes do sistema em execução no namespace kube-system.

Alguns componentes, como nós do agente, têm responsabilidade compartilhada, em que você precisa ajudar a manter o cluster do AKS. A entrada de usuário é necessária, por exemplo, para aplicar um patch de segurança do sistema operacional do nó do agente.

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

Responsabilidade compartilhada

Ao criar um cluster, você define os nós de agente do Kubernetes que o AKS cria. Suas cargas de trabalho são executadas nesses nós. Tenha em mente as seguintes restrições do nó do agente:

• Suporte da Microsoft tem acesso limitado. Como os nós do agente executam código privado e armazenam dados confidenciais, o Suporte da Microsoft não pode acessar esses nós, executar comandos neles nem visualizar os logs desses nós sem sua autorização explícita ou sua assistência.
• Use mecanismos nativos do Kubernetes para alterações. Qualquer modificação feita diretamente nos nós do agente por meio das APIs de IaaS torna o cluster sem suporte. Aplicar alterações usando mecanismos nativos do Kubernetes como um DaemonSet.
• Não altere os metadados criados pelo sistema. Você pode adicionar metadados como marcas e rótulos, mas alterar os metadados criados pelo sistema torna o cluster sem suporte.

Divisão de responsabilidade

A matriz a seguir resume a responsabilidade de suporte em um cluster do AKS e contrasta o AKS com o Kubernetes autogerenciado que você executa localmente. No AKS, Microsoft gerencia o plano de controle e a plataforma principal. Você gerencia sua configuração de nó, cargas de trabalho, configuração de rede e dados. As áreas compartilhadas são onde Microsoft fornece e mantém uma funcionalidade e você a habilita, configura ou agenda. Use a matriz como um guia rápido e, em seguida, consulte as seções detalhadas abaixo para ver os detalhes específicos do suporte.

Use a seguinte chave para ler a matriz:

Para as áreas compartilhadas na matriz a seguir, a tabela mostra o que Microsoft fornece e pelo que você é responsável:

Cobertura de suporte do AKS

As seções a seguir descrevem os cenários suportados e não suportados no suporte técnico do AKS.

Cenários com suporte

Microsoft fornece suporte técnico para os seguintes exemplos:

Quaisquer ações no cluster realizadas pela Microsoft ou pelo AKS são executadas com o seu consentimento no âmbito de uma função interna do Kubernetes aks-service e de uma vinculação de função interna aks-service-rolebinding, que vincula a função à identidade de serviço do Suporte da Microsoft aks-support. Essa função permite que o AKS solucione e diagnostice problemas de cluster, mas não pode modificar permissões ou criar funções ou associações de função ou executar outras ações de alto privilégio. O acesso à função só é habilitado em tíquetes de suporte ativos com acesso JIT (just-in-time).

Cenários sem suporte

Microsoft não fornece suporte técnico para os cenários a seguir.

Alguns desses cenários têm mais nuances sobre o que Microsoft ainda podem ajudar. Para obter mais informações, consulte Detalhes sobre cenários sem suporte.

Detalhes sobre cenários sem suporte

Vários cenários sem suporte adicionaram nuances sobre o que Microsoft ainda podem ajudar com:

• Como usar o Kubernetes. Suporte da Microsoft não fornece conselhos sobre como criar controladores de entrada personalizados, usar cargas de trabalho de aplicativo ou aplicar pacotes ou ferramentas de software não Microsoft ou de software livre. Suporte da Microsoft pode aconselhar sobre a funcionalidade do cluster AKS, a personalização e o ajuste (por exemplo, procedimentos e problemas de operações do Kubernetes).
• Projetos de software livre não Microsoft. Esses projetos não são fornecidos como parte do plano de controle do Kubernetes ou implantados com clusters do AKS e podem 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 ao provedor de nuvem Azure do Kubernetes ou a outros problemas específicos do AKS, a Microsoft oferece suporte a exemplos e aplicativos da documentação da Microsoft.
• Personalizações de rede. Para personalizações diferentes das listadas na documentação do AKS, 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. Na medida do possível, o Suporte da Microsoft pode orientar sobre a configuração necessária para o Firewall do Azure, mas não sobre outros dispositivos de terceiros.
• Controladores de ingresso que não são da Microsoft. Para controladores como nginx, kongou traefik, isso inclui problemas de funcionalidade que surgem após operações específicas do AKS, como um controlador de entrada deixando de funcionar após uma atualização de versão do Kubernetes, que pode decorrer de incompatibilidades entre a versão do controlador de entrada e a nova versão do Kubernetes. Para uma opção totalmente compatível, considere uma opção de controlador de entrada gerenciada por Microsoft.
• Scripts personalizados do DaemonSet Embora usar DaemonSet seja a abordagem recomendada para ajustar, modificar ou instalar software que não seja da Microsoft nos nós de agente quando os parâmetros do arquivo de configuração não forem suficientes, o Suporte da Microsoft não pode solucionar problemas decorrentes dos scripts personalizados devido à natureza personalizada desses scripts.
• Suporte em espera e proativo. Suporte da Microsoft fornece suporte reativo para resolver problemas ativos. O suporte em espera ou proativo para eliminar riscos operacionais, aumentar a disponibilidade e otimizar o desempenho não é abordado. Clientes elegíveis podem entrar em contato com a equipe da conta para serem nomeados para o serviço de Gerenciamento de Eventos do Azure, um serviço pago que inclui uma avaliação proativa de risco da solução e cobertura durante o evento.
• CVEs com menos de 30 dias de idade. Desde que você use o VHD atualizado, não deverá haver nenhuma CVE nas imagens de contêiner cuja correção disponibilizada pelo fornecedor tenha mais de 30 dias. É sua responsabilidade atualizar o VHD, filtrar o relatório de CVEs e fornecer ao Suporte da Microsoft uma lista contendo apenas os CVEs com uma correção do fornecedor disponível há mais de 30 dias. A Microsoft então trabalha internamente para tratar componentes com uma correção disponibilizada pelo fornecedor há mais de 30 dias. A Microsoft fornece suporte relacionado a CVE somente para componentes gerenciados pela Microsoft, como imagens de nó do AKS e imagens de contêiner gerenciadas implantadas no cluster durante a criação do cluster ou por meio de um complemento gerenciado. Para obter mais informações, consulte o gerenciamento de vulnerabilidades para AKS (Serviço de Kubernetes do Azure).
• Exemplos de código personalizado. Suporte da Microsoft pode fornecer e examinar pequenos exemplos de código em um caso de suporte para demonstrar como usar recursos de um produto Microsoft, mas não pode fornecer exemplos de código personalizados específicos para seu ambiente ou aplicativo.
• Lógica personalizada do Azure Policy. Suporte da Microsoft pode fornecer diretrizes gerais sobre como as definições de Azure Policy personalizadas são aplicadas e avaliadas no AKS. A solução de problemas detalhada da lógica de política criada pelo cliente (incluindo políticas baseadas em Rego), como por que uma política específica permite ou nega uma carga de trabalho, geralmente está fora do escopo do suporte.

Traga seus próprios limites de suporte de CNI

Quando você implanta um cluster com BYOCNI (use sua própria CNI) usando --network-plugin none, o Suporte da Microsoft não pode ajudar com problemas relacionados à CNI. Você é responsável pelo ciclo de vida do plug-in CNI e deve buscar suporte do fornecedor de plug-in CNI. Microsoft ainda dá suporte a problemas que não estão relacionados à CNI.

Para obter mais informações, consulte Traga sua própria CNI (BYOCNI).

Cobertura de suporte do AKS para nós do agente

As seções a seguir descrevem as responsabilidades da Microsoft e do cliente nos nós de agente do AKS.

A tabela a seguir resume, de forma resumida, as responsabilidades do nó de agente. As seções a seguir fornecem os detalhes.

Responsabilidades da Microsoft pelos nós do agente do AKS

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

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

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 a autoremediação para problemas comuns. Para saber mais sobre os mecanismos de autoremediação, consulte Reparo Automático do Nó.

Responsabilidades do cliente pelos nós do agente do AKS

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

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

Da mesma forma, o AKS lança regularmente novos patches e versões secundárias do Kubernetes. 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 e de acordo com a política de versão de suporte do Kubernetes para AKS. Use a atualização automática do cluster ou perfis de atualização automática do Gerenciador de Frota para manter clusters em uma versão secundária com suporte. Se um cluster permanecer em uma versão sem suporte após o término do período de carência de suporte da plataforma, o AKS o atualizará automaticamente. Para obter mais informações, consulte atualizações iniciadas pela plataforma.

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

O AKS gerencia o ciclo de vida e as operações de nós do agente em seu nome e não há suporte para a modificação dos recursos de IaaS associados aos nós do agente. Um exemplo de uma operação sem suporte é personalizar um conjunto de dimensionamento de máquinas virtuais do pool de nós alterando manualmente as configurações no portal do Azure ou a partir da API.

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

O uso de contêineres privilegiados inite DaemonSet do Kubernetes permite que você ajuste/modifique ou instale software que não seja da Microsoft nos nós de agente do cluster. Os exemplos dessas personalizações incluem adicionar software personalizado de verificação de segurança ou atualizar configurações de sysctl.

Embora esse caminho seja recomendado se os requisitos acima se aplicarem, a engenharia e o suporte do AKS não poderão 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 patch

Se uma falha de segurança for encontrada em um ou mais dos componentes gerenciados do AKS, a equipe do AKS aplica patches a todos os clusters afetados para atenuar o problema. Como alternativa, a equipe do AKS fornece diretrizes de atualização.

Para os nós do agente afetados por uma falha de segurança, a Microsoft notifica você com os detalhes sobre o impacto e as etapas para corrigir ou atenuar o problema de segurança.

Manutenção e acesso do nó

Embora você possa fazer login nos nós do agente e modificá-los, não faça isso. As alterações podem tornar um cluster sem suporte.

Portas de rede, acesso e NSGs

Você pode personalizar NSGs (grupos de segurança de rede) somente em sub-redes personalizadas. A tabela a seguir mostra onde você pode personalizar NSGs:

O AKS tem requisitos de saída de rede para pontos de extremidade específicos. Para controlar a saída e garantir a conectividade necessária, confira limitar o tráfego de saída. Para o Ingress, os requisitos dependem dos aplicativos que você implanta no cluster.

Nós parados, desalocados e Não prontos

A tabela a seguir resume o que acontece com um cluster do AKS em cada estado de ciclo de vida e a linha do tempo associada:

Se você não precisar que as cargas de trabalho do AKS sejam executadas continuamente, interrompa o cluster do AKS, o que interrompe todos os pools de nós e o plano de controle, e inicie-o novamente quando necessário. Desalocar os nós manualmente usando as APIs de IaaS, o CLI do Azure ou o portal Azure não é uma maneira compatível de parar um cluster.

O AKS reserva-se o direito de arquivar planos de controle 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 coloque novamente em um estado com suporte, como uma atualização ou um redimensionamento para nós de agente ativos.

Recursos de Kubernetes alfa e beta sem suporte

O AKS dá suporte a recursos estáveis e beta dentro do projeto upstream do Kubernetes, mas não recursos alfa, a menos que documentados de outra forma. A tabela a seguir resume o suporte por tipo de recurso:

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 novos recursos de visualização ou recursos por trás de um sinalizador de recurso. Considere esses recursos como recursos beta ou de pré-lançamento.

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 em versão preliminar pública se enquadram no suporte de melhor esforço, pois esses recursos estão em versão prévia e não são destinados à produção. As equipes de suporte técnico do AKS fornecem suporte somente durante o horário comercial. Para obter mais informações, consulte Azure Perguntas frequentes sobre suporte.

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 do AKS. 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 Microsoft possui (como o provedor de nuvem Azure), o AKS e a equipe de Azure estão comprometidos em corrigir problemas upstream na comunidade.

Quando a causa raiz de um problema de suporte técnico deve-se a um ou mais bugs de upstream, as equipes de suporte e engenharia do AKS:

• 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 fornece correções.
• Fornecer possíveis soluções alternativas ou uma mitigação. Se o problema puder ser mitigado, um problema conhecido será registrado no repositório do AKS. 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 persistência da solução.
  • Linhas do tempo aproximadas para a inclusão do problema, com base na cadência da versão de upstream.

Conteúdo relacionado

• Tipos de preço do AKS
• Versões do Kubernetes com suporte no AKS
• Suporte de longo prazo para AKS
• Atualizar automaticamente um cluster do AKS
• Atualizar automaticamente as imagens do sistema operacional dos nós do AKS
• Gerenciamento de vulnerabilidades para AKS
• Reparo automático do nó do AKS
• Traga sua própria CNI (BYOCNI)