Compartilhar via

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

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 iaaS (infraestrutura básica como serviço), como componentes de computação ou rede, permitem que você acesse 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:

  • Servidores de API kubelet ou Kubernetes.
  • 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 kube-dns ou CoreDNS.
  • Proxy ou 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 deve ser feita usando mecanismos nativos do Kubernetes, como um DaemonSet.

Da mesma forma, embora você possa adicionar qualquer metadado 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 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

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

  • Conectividade com todos os componentes do Kubernetes que o serviço Kubernetes fornece e dá suporte, como o servidor de API.
  • Gerenciamento, disponibilidade, QoS e operações dos serviços do plano de controle do Kubernetes, como o controle do plano do Kubernetes, o servidor de API etcd e o coreDNS.
  • etcd armazenamento de dados. O suporte inclui backups automatizados e transparentes de todos os etcd dados 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 ou 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 a outros serviços do Azure, como balanceadores de carga, volumes persistentes ou rede (Kubernetes e CNI do Azure, exceto quando BYOCNI está em uso).
  • Perguntas ou problemas sobre a personalização de componentes do plano de controle, como o servidor etcdde API do Kubernetes e o coreDNS.
  • Problemas de rede, como CNI do Azure, kubenet ou outros problemas de acesso e funcionalidade de rede, exceto quando BYOCNI está 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 gerenciados pela Microsoft ou configurações de balanceador de carga.
    • Desempenho e latência de rede.
    • Componentes e funcionalidades de políticas de rede gerenciadas pela Microsoft.

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).

Cenários sem suporte

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.

    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.

    A Microsoft pode fornecer suporte dentro do possível para projetos de código aberto 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.

  • Configuração e solução de problemas de código ou comportamento específico do aplicativo de ferramentas ou aplicativos de terceiros em execução no cluster do AKS. Isso inclui problemas de implantação de aplicativo não relacionados à própria plataforma AKS.

  • Emissão, renovação ou gerenciamento de certificados para aplicativos em execução no AKS.

  • Personalizações de rede diferentes daquelas listadas na documentação do AKS. Por exemplo, o Suporte da Microsoft não pode configurar dispositivos ou dispositivos virtuais destinados a fornecer tráfego de saída para o cluster do AKS, como VPNs ou firewalls.

    Com base no melhor esforço, o Suporte da Microsoft pode aconselhar sobre a configuração necessária para o Firewall do Azure, mas não para outros dispositivos de terceiros.

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

  • Configuração e solução de problemas de políticas de rede não gerenciadas pela Microsoft. Embora haja suporte para o uso de políticas de rede, o Suporte da Microsoft não pode investigar problemas decorrentes de configurações de política de rede personalizadas.

  • Configurando ou solucionando problemas de controladores de entrada não gerenciados pela Microsoft, como nginx, , kongetc traefik. Isso inclui resolver 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. Esses problemas podem 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 usar uma opção de controlador de entrada gerenciada pela Microsoft.

  • Configurando ou solucionando problemas de DaemonSet (incluindo scripts) usados para personalizar as configurações de nó. Embora o uso DaemonSet seja a abordagem recomendada para ajustar, modificar ou instalar software de terceiros em nós do agente de cluster quando os parâmetros de arquivo de configuração são insuficientes , o Suporte da Microsoft não pode solucionar problemas decorrentes dos scripts personalizados usados DaemonSet devido à sua natureza personalizada.

  • 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 em 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 suas respectivas equipes 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.

  • Vulnerabilidades/CVEs com uma correção do fornecedor com menos de 30 dias. Desde que você esteja executando o VHD atualizado, não deve executar nenhuma vulnerabilidade de imagem de contêiner/CVEs com uma correção de fornecedor com mais de 30 dias. É responsabilidade do cliente atualizar o VHD e fornecer listas filtradas para o suporte da Microsoft. Depois de atualizar o VHD, é responsabilidade do cliente filtrar o relatório de vulnerabilidades/CVEs e fornecer uma lista apenas com vulnerabilidades/CVEs cuja correção pelo fornecedor tem mais de 30 dias. Se esse for o caso, o suporte da Microsoft garantirá que trabalhará internamente e resolverá os componentes com uma correção de fornecedor lançada há mais de 30 dias. Além disso, a Microsoft fornece suporte relacionado a vulnerabilidades/CVE somente para componentes gerenciados pela Microsoft. Por exemplo, imagens de nós do AKS, que são imagens de contêiner gerenciadas para aplicativos que são implantados durante a criação do cluster ou por meio da instalação de um complemento gerenciado. Para obter mais detalhes sobre o gerenciamento de vulnerabilidades do AKS, visite o gerenciamento de vulnerabilidades do AKS (Serviço de Kubernetes do Azure).

  • Amostras de código ou scripts personalizados. Embora o Suporte da Microsoft possa fornecer pequenos exemplos de código e revisões de pequenos exemplos de código em um caso de suporte para demonstrar como usar recursos de um produto da Microsoft, o Suporte da Microsoft não pode fornecer exemplos de código personalizados específicos para seu ambiente ou aplicativo.

Cobertura de suporte do AKS para nós do agente

As seções a seguir descrevem as responsabilidades da Microsoft e do cliente em relação aos nós de agente do AKS.

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.
  • Os problemas com os componentes do painel de controle do Kubernetes executados nos nós do agente são corrigidos automaticamente. Esses componentes incluem os seguintes itens:
    • Kube-proxy
    • Túneis de rede que fornecem caminhos de comunicação para os componentes mestres 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. Se você quiser saber mais sobre os mecanismos de autoremediação, consulte Reparo Automático do Nó.

Responsabilidades do cliente pelos nós do agente do AKS

A 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. Para obter mais informações, consulte:

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

Note

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_\*). Você não pode alterar a imagem do sistema operacional base ou fazer personalizações diretas para esses nós usando as APIs ou recursos de IaaS. As alterações personalizadas que não são executadas a partir da API do AKS não persistem após uma atualização, escalonamento, modificação ou reinicialização. Além disso, qualquer alteração nas extensões dos nós, como a CustomScriptExtension , pode levar a um comportamento inesperado e deve ser proibida. 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 KubernetesDaemonSet.

O uso de contêineres de inicialização com privilégios de Kubernetes DaemonSet e init permite que você ajuste/modifique ou instale softwares de terceiros em nós do 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 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ê pode personalizar somente os NSGs em sub-redes personalizadas. Você pode não personalizar 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 ingresso, os requisitos são baseados nas aplicações implantadas no cluster.

Nós parados, desalocados e Não prontos

Se você não precisar que suas cargas de trabalho do AKS estejam sendo executadas continuamente, poderá parar o cluster do AKS, o que interrompe todos os pools de nós e o plano 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 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 de metadados de cluster etcd e pode realocar prontamente o cluster. 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. A menos que esteja documentado de outra forma, o AKS não dá suporte a nenhum recurso alfa disponível 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 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 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 componentes que a Microsoft possui (como o provedor de nuvem do Azure), o AKS e a equipe do 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á 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.
  • Last updated on