Share via

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

  • Artigo

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

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

Recursos gerenciados no AKS

Os componentes de nuvem de IaaS (infraestrutura como serviço) base, como componentes de computação ou de rede, oferecem 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. Em troca, você não precisa se preocupar com os clusters do Kubernetes diretamente nem gerenciá-los.

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. A Microsoft mantém e opera todos os componentes do Kubernetes.

A Microsoft gerencia e monitora os seguintes componentes usando o painel de controle:

  • Servidor de API do Kubelet ou do Kubernetes
  • Etcd ou um repositório de valor-chave compatível, fornecendo QoS (Qualidade de Serviço), escalabilidade e runtime
  • Serviços DNS (por exemplo, kube-dns ou CoreDNS)
  • Proxy ou sistema de rede do Kubernetes, exceto quando BYOCNI é usado
  • Todos os outros complementos ou componentes do sistema em execução no namespace kube-system.

O AKS não é uma solução de PaaS (plataforma como serviço). 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 gerenciados no sentido de que a Microsoft e a equipe do AKS implantam, operam e são responsáveis pela disponibilidade e pela 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 escalonável.

Responsabilidade compartilhada

Quando um cluster é criado, você define os nós do agente do Kubernetes criados pelo AKS. Suas cargas de trabalho são executadas nesses nós.

Como os nós do agente executam um código particular e armazenam dados confidenciais, o Suporte da Microsoft só pode acessá-los de uma forma limitada. O Suporte da Microsoft não pode se conectar a esses nós, executar comandos neles nem ver os logs deles sem a sua assistência ou permissão expressa.

Qualquer modificação feita diretamente nos nós do agente por meio de uma das APIs de IaaS torna o cluster sem suporte. Qualquer modificação aplicada aos nós do agente precisa ser feita por meio de mecanismos nativos do Kubernetes, como Daemon Sets.

Da mesma forma, embora você possa adicionar os metadados ao cluster e aos nós, como marcas e rótulos, a alteração de um dos metadados criados pelo sistema torna o cluster sem suporte.

Cobertura de suporte do AKS

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

  • Conectividade com todos os componentes do Kubernetes que o serviço de Kubernetes oferece e dá suporte, como o servidor de API.
  • Gerenciamento, tempo de atividade, QoS e operações dos serviços do painel de controle do Kubernetes (por exemplo, painel 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 do etcd a cada 30 minutos para planejamento de desastre e restauração de estado do cluster. Esses backups não estão disponíveis diretamente para você nem para qualquer outro. Eles garantem a confiabilidade e a consistência dos dados. Não há suporte para reversão nem restauração sob demanda 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 CNI do Azure, exceto quando BYOCNI estiver em uso).
  • Perguntas ou problemas sobre a personalização de componentes do painel de controle, como o servidor de API do Kubernetes, etcd e coreDNS.
  • Problemas sobre redes, como CNI do Azure, kubenet ou outros problemas de acesso e funcionalidade de rede, exceto quando BYOCNI estiver em uso. Os problemas podem incluir resolução de DNS, perda de pacotes, roteamento e assim por diante. A Microsoft dá suporte a vários cenários de rede:
    • Kubenet e CNI do Azure 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 entrada ou do balanceador de carga
    • Desempenho e latência de rede
    • Políticas de rede

Observação

Todas as ações de cluster tomadas pela Microsoft/AKS são feitas com o seu consentimento em uma função interna do Kubernetes aks-service e associação da função interna aks-service-rolebinding. Essa função permite que o AKS diagnostique e solucione problemas de cluster, mas não pode modificar permissões nem criar funções ou associações de função nem 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).

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 faz recomendações sobre como criar controladores de entrada personalizados, usar cargas de trabalho de aplicativos ou aplicar pacotes ou ferramentas de software livre ou de terceiros.

    Observação

    O Suporte da Microsoft pode recomendar a funcionalidade, a personalização e o ajuste do cluster do AKS (por exemplo, problemas e procedimentos de operações do Kubernetes).

  • Projetos de software livre de terceiros que não são fornecidos como parte do painel de controle do Kubernetes ou implantados com clusters do AKS. Esses projetos podem incluir Istio, Helm, Envoy ou outros.

    Observação

    A Microsoft pode fornecer suporte de melhor esforço para projetos de software livre de terceiros, como o Helm. Nos casos em que a ferramenta de software livre de terceiros se integra ao provedor de nuvem do Azure no Kubernetes ou outros bugs específicos do AKS, a Microsoft dá suporte a exemplos e aplicativos da documentação da Microsoft.

  • Software closed-source de terceiros. Esse software pode incluir ferramentas de verificação de segurança e software ou dispositivos de rede.

  • Personalizações de rede diferentes daquelas listadas na documentação do AKS.

  • Plug-ins CNI personalizados ou de terceiros usados no modoBYOCNI.

  • Cenários de espera e proativos. O Suporte da Microsoft fornece suporte reativo para ajudar a resolver problemas ativos em tempo hábil e de maneira profissional. No entanto, o suporte de espera ou proativo para ajudá-lo a eliminar riscos operacionais, aumentar a disponibilidade e otimizar o desempenho não são abordados. Os clientes qualificados podem entrar em contato com sua equipe de conta para serem indicados para o serviço Gerenciamento de Eventos do Azure. Ele é um serviço pago fornecido por engenheiros de suporte da Microsoft que inclui uma cobertura e avaliação de risco de solução proativas durante o evento.

Cobertura de suporte do AKS para nós do agente

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 rede e monitoramento).
  • Os nós do agente recebem patches do sistema operacional automaticamente.
  • Os problemas com os componentes do painel 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 mestres do Kubernetes
    • Kubelet
    • containerd

Observação

Se um nó do 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. Caso deseje saber mais sobre os mecanismos de correção automática, confira Reparo automático de nós

Responsabilidades do cliente pelos nós do agente do AKS

A Microsoft fornece patches e novas imagens para seus nós de imagem semanalmente, mas não os corrigi automaticamente por padrão. Para manter os componentes de runtime e do sistema operacional do nó do agente corrigidos, você deve manter um agendamento de atualização regular 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 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.

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

Observação

Os nós do agente do AKS são exibidos no portal do Azure como recursos padrão de IaaS 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 nem fazer personalizações diretas nesses nós usando os recursos ou as APIs de IaaS. Todas as alterações personalizadas que não forem realizadas da API do AKS não serão persistidas por uma atualização, uma escala, uma atualização ou uma reinicialização. Além disso, as alterações nas extensões dos nós, como CustomScriptExtension, podem levar a um comportamento inesperado e precisam ser proibidas. Evite fazer alterações nos nós do agente, a menos que o Suporte da Microsoft oriente você a fazê-las.

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 daemon sets do Kubernetes.

O uso de Kubernetes daemon sets com privilégios e contêineres de inicialização permite que você ajuste/modifique ou instale software de terceiros em nós do agente de cluster. Os exemplos dessas personalizações incluem adicionar software personalizado de verificação de segurança ou atualizar configurações de sysctl.

Embora esse seja um caminho recomendado se os requisitos acima forem aplicáveis, a engenharia e o suporte do AKS não poderão ajudar na solução de problemas nem no diagnóstico de modificações que tornam o nó indisponível por conta de um daemon set personalizado implantado.

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 se conectar e alterar os nós do agente, essa operação não é recomendada porque as alterações podem tornar o cluster sem suporte.

Portas de rede, acesso e NSGs

Você só pode personalizar os NSGs em sub-redes personalizadas. Não é possível personalizar os NSGs em sub-redes gerenciadas ou no nível da 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, confira Limitar o tráfego de saída. Para entrada, os requisitos são baseados nos aplicativos que você implantou no cluster.

Nós parados, desalocados e Não prontos

Se as cargas de trabalho do AKS não precisarem ser executadas continuamente, você poderá parar o cluster do AKS, o que vai parar os pools de nós e o painel de controle. Você pode iniciá-lo novamente quando necessário. Quando você parar um cluster usando o comando az aks stop, o estado dele é preservado por até 12 meses. Após 12 meses, o estado do cluster e todos os respectivos recursos são excluídos.

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

Os clusters sem nenhum nó Pronto (ou todos Não prontos) e nenhuma VM Em execução serão interrompidos após 30 dias.

O AKS reserva-se o direito de arquivar painéis de controle que foram configurados fora das diretrizes de suporte por longos períodos iguais e superiores a 30 dias. O AKS mantém backups dos metadados do cluster etcd e pode realocar o cluster imediatamente. Essa realocação é iniciada por qualquer operação PUT que retorne o cluster para suporte, como uma atualização ou escala para os 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 de Kubernetes alfa e beta sem suporte

O AKS só dá suporte a recursos estáveis e beta no projeto upstream do Kubernetes. Salvo indicação em contrário, o AKS não dá suporte a recursos alfa disponíveis no projeto upstream do Kubernetes.

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 novas versões prévias dos recursos 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 na versão prévia 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 Perguntas Frequentes de Suporte do Azure.

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 os componentes detidos pela Microsoft (como o provedor de nuvem do Azure), as equipes do AKS e do Azure estão comprometidas em corrigir problemas de 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 fornecerá correções.

  • Fornecer possíveis soluções alternativas ou uma mitigação. Se o problema puder ser mitigado, um problema conhecido será arquivado 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.