Políticas de apoio ao Serviço Azure Kubernetes em Azure Stack HCI

Este artigo fornece detalhes sobre políticas técnicas de suporte e limitações para o Serviço Azure Kubernetes em Azure Stack HCI (AKS on Azure Stack HCI). O artigo também detalha a gestão do noses de cluster de gestão, componentes de avião de controlo, componentes de código aberto de terceiros e gestão de segurança ou patch.

Atualizações e lançamentos de serviços

Funcionalidades geridas em AKS no Azure Stack HCI

A infraestrutura base como um serviço (IaaS) componentes em nuvem, como componentes de computação ou de rede, permitem-lhe o acesso a controlos de baixo nível e opções de personalização. Em contraste, o AKS no Azure Stack HCI fornece uma implementação de Kubernetes chave na mão que lhe dá o conjunto comum de configurações e capacidades que necessita para o seu cluster. Como utilizador AKS no Azure Stack HCI, tem opções limitadas de personalização e implementação. Em troca, não precisa de se preocupar ou gerir diretamente o plano de controlo e instalação do cluster Kubernetes.

Com a AKS no Azure Stack HCI, obtém-se um plano de controloparcialmente gerido. O plano de controlo contém todos os componentes e serviços necessários para operar e fornecer clusters Kubernetes aos utilizadores finais. Todos os componentes kubernetes são mantidos pela Microsoft.

A Microsoft mantém os seguintes componentes através do cluster de gestão e das imagens de base da Máquina Virtual associadas:

  • Servidores API kubelet ou Kubernetes.
  • Etcd ou uma loja de valor-chave compatível, fornecendo Qualidade de Serviço (QoS), escalabilidade e tempo de execução.
  • Serviços DNS (por exemplo, kube-dns ou CoreDNS).
  • Procuração de Kubernetes ou networking.
  • Qualquer addon adicional ou componente do sistema em execução no espaço de nome do sistema kube.

AKS on Azure Stack HCI não é uma solução plataforma-as-a-service (PaaS). Alguns componentes, como o plano de controlo de clusters de carga de trabalho e os nós dos trabalhadores, têm responsabilidade partilhada,onde os utilizadores devem ajudar a manter o AKS no cluster HCI Azure Stack HCI. A entrada do utilizador é necessária, por exemplo, para aplicar um patch de segurança do sistema operativo (OS) ou uma atualização para uma versão mais recente de Kubernetes.

Os serviços são geridos no sentido de que a Microsoft e a equipa AKS na Azure Stack HCI fornecem a ferramenta que implementa o cluster de gestão, o plano de controlo e os nós de agente para clusters de carga de trabalho. Os clientes não podem alterar estes componentes geridos. A Microsoft limita a personalização para garantir uma experiência consistente e escalável do utilizador. Para obter uma solução totalmente personalizável na nuvem, consulte o Motor AKS.

Responsabilidade partilhada

Quando um cluster é criado, você define os nós de agente Kubernetes que AKS em Azure Stack HCI cria. As suas cargas de trabalho são executadas nestes nós.

Como os nós do seu agente executam código privado e armazenam dados sensíveis, o Microsoft Support só pode aceder aos mesmos de forma muito limitada. O Microsoft Support não pode iniciar sessão, executar comandos ou visualizar registos para estes nós sem a sua autorização expressa ou assistência.

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

Da mesma forma, embora possa adicionar quaisquer metadados ao cluster e aos nós, tais como tags e etiquetas, alterar qualquer um dos metadados criados no sistema tornará o cluster sem suporte.

Cobertura de suporte AKS na Azure Stack HCI

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

  • Conectividade a todos os componentes kubernetes que o serviço Kubernetes fornece e suporta, como o servidor API.

  • Fornecendo os serviços de avião de controlo kubernetes (avião de controlo Kubernetes, servidor API, etcd, e coreDNS, por exemplo).

  • Fornecendo a loja de dados Etcd.

  • Integração com a Azure Arc e o serviço Azure Billing.

  • Questões ou questões sobre a personalização de componentes do plano de controlo, tais como o servidor API de Kubernetes, etcd e coreDNS.

  • Questões sobre questões de networking, acesso à rede e problemas de funcionalidade. As questões podem incluir resolução de DNS, perda de pacotes, encaminhamento, e assim por diante. A Microsoft suporta vários cenários de networking:

    • Suporte básico de instalação para Flannel e Calico CNI. Estes CNIs são orientados e apoiados pela comunidade. O CSS fornecerá apenas suporte básico de instalação e configuração.

    • Conectividade com outros serviços e aplicações da Azure.

    • Ingress controladores e configurações de entradas ou balançadores de carga.

    • Desempenho da rede e latência

Nota

Quaisquer ações de cluster tomadas pela Microsoft/AKS no Azure Stack HCI são feitas com o consentimento e assistência do utilizador. O Microsoft Support não entrará no seu cluster a menos que configuure o acesso ao engenheiro de suporte.

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

  • Perguntas sobre como usar Kubernetes. Por exemplo, o Microsoft Support não fornece conselhos sobre como criar controladores de entrada personalizados, usar cargas de trabalho de aplicação ou aplicar pacotes ou ferramentas de software de terceiros ou de código aberto.

    Nota

    O Microsoft Support pode aconselhar sobre a funcionalidade do cluster HCI do Azure Stack HCI, personalização e afinação (por exemplo, problemas e procedimentos de operações da Kubernetes).

  • Projetos de código aberto de terceiros que não são fornecidos como parte do avião de controlo Kubernetes ou implantados quando aKS em Azure Stack HCI clusters são criados. Estes projetos podem incluir Istio, Helm, Envoy, ou outros.

    Nota

    A Microsoft pode fornecer o melhor suporte de esforço para projetos de código aberto de terceiros, como o Helm. Quando a ferramenta de código aberto de terceiros se integra com Kubernetes ou outros bugs específicos de AKS em Azure Stack HCI, a Microsoft suporta exemplos e aplicações a partir da documentação da Microsoft.

  • Software de origem fechada de terceiros. Este software pode incluir ferramentas de verificação de segurança e dispositivos de rede ou software.

  • Personalizações de rede que não as listadas na documentação HCI da AKS em Azure Stack HCI.

Cobertura de suporte AKS on Azure Stack HCI para nós de agente

Responsabilidades da Microsoft pela AKS nos nós de agente HCI da Azure Stack

A Microsoft e os utilizadores partilham a responsabilidade pelos nós de agente da Kubernetes onde:

  • A imagem base de SO requer adições (tais como agentes de monitorização e de rede).
  • Os nós de agente recebem patches de SO automaticamente.
  • Os problemas com os componentes do avião de controlo Kubernetes que funcionam nos nós do agente são automaticamente remediados durante o ciclo de atualização ou quando volta a implantar um nó de agente. Estes componentes incluem o seguinte:
    • Kube-proxy
    • Túneis de ligação em rede que fornecem caminhos de comunicação para os componentes principais de Kubernetes
    • Kubelet
    • Moby ou ContainerD

Nota

Se um nó de agente não estiver operacional, a AKS on Azure Stack HCI pode 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 questões comuns.

Responsabilidades do cliente da AKS em nós de agente HCI da Azure Stack

A Microsoft fornece patches e novas imagens para os seus nós de imagem mensalmente, mas não as corrige automaticamente por padrão. Para manter o seu agente node OS e componentes de tempo de execução remendados, deve manter um horário de atualização regular ou automatizá-lo.

Da mesma forma, a AKS em Azure Stack HCI lança regularmente novos patches de kubernetes e versões menores. Estas atualizações podem conter melhorias de segurança ou funcionalidades em Kubernetes. É responsável por manter a versão kubernetes dos seus clusters atualizada e de acordo com a AKS na Azure Stack HCI Kubernetes Support Version Policy.

Personalização do utilizador dos nós de agente

Nota

Os nós de agente HCI AKS em Azure Stack aparecem no Hiper-V como recursos de máquina virtual regulares. Estas máquinas virtuais são implantadas com uma imagem de SO personalizada e componentes Kubernetes suportados/geridos. Não é possível alterar a imagem base do SO ou fazer quaisquer personalizações diretas a estes nós utilizando os APIs ou recursos hiper-V. Quaisquer alterações personalizadas que não sejam feitas através do AKS na Azure Stack HCI API não persistirão através de uma atualização, escala, atualização ou reinicialização e podem tornar o cluster sem suporte. Evite efetuar alterações nos nós do agente, a menos que o Microsoft Support o direcione para fazer alterações.

A AKS on Azure Stack HCI gere o ciclo de vida e as operações da imagem do nó do agente em seu nome - modificando os recursos associados aos nós do agente não é suportado. Um exemplo de uma operação não apoiada é personalizar as definições de rede de máquinas virtuais alterando manualmente configurações através da API hiper-V ou ferramentas.

Para configurações ou pacotes específicos da carga de trabalho, a AKS on Azure Stack HCI recomenda a utilização de Kubernetes .

A utilização de recipientes privilegiados e init da Kubernetes daemon sets permite-lhe sintonizar/modificar ou instalar software de 3ª parte nos nós do agente de cluster. Exemplos de tais personalizações incluem adicionar software de verificação de segurança personalizado ou atualizar definições de sysctl.

Embora este caminho seja recomendado se os requisitos acima referidos se aplicarem, a AKS na engenharia HCI Azure Stack HCI não pode ajudar na resolução de problemas ou no diagnóstico de modificações que tornem o nó indisponível devido a um personalizado implantado daemon set .

Questões de segurança e remendos

Se uma falha de segurança for encontrada em um ou mais dos componentes geridos da AKS em Azure Stack HCI, a equipa AKS on Azure Stack HCI irá corrigir todas as imagens de SO afetadas para mitigar o problema e a equipa dará orientações de upgrade aos utilizadores.

Para os nós de agente afetados por uma falha de segurança, a Microsoft irá notificá-lo com detalhes sobre o impacto e os passos para corrigir ou mitigar o problema de segurança (normalmente uma atualização de imagem de nó ou uma atualização de patch de cluster).

Manutenção e acesso do nó

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

Portas de rede, piscinas IP e acesso

Só pode personalizar as definições de rede utilizando sub-redes definidas AKS em Azure Stack HCI. Não pode personalizar as definições de rede ao nível de NIC dos nós do agente. A AKS on Azure Stack HCI tem requisitos de saída para pontos finais específicos, para controlar as saídas e garantir a conectividade necessária, ver Requisitos do Sistema.

Aglomerados parados ou desatribuidos

Como indicado anteriormente, a desalocação manual de todos os nós de cluster através das APIs/CLI/MMC hiper-V torna o cluster fora de suporte.

Os agrupamentos que estão parados por mais de 90 dias deixarão de poder ser atualizados. Os aviões de controlo para aglomerados neste estado ficarão sem apoio após 30 dias, não sendo capazes de atualizar para a versão mais recente após 60 dias.

Se a sua subscrição Azure for suspensa ou eliminada, o seu cluster ficará sem suporte após 60 dias.

Características alfa e beta não suportadas

AKS on Azure Stack HCI suporta apenas funcionalidades estáveis e beta dentro do projeto Kubernetes a montante. Salvo documentação em contrário, a AKS em Azure Stack HCI não suporta qualquer funcionalidade alfa disponível no projeto Kubernetes a montante.

Funcionalidades de pré-visualização ou bandeiras de recurso

Para funcionalidades e funcionalidades que requerem testes alargados e feedback do utilizador, a Microsoft lança novas funcionalidades de pré-visualização ou funcionalidades por trás de uma bandeira de funcionalidade. Considere estas funcionalidades como funcionalidades pré-lançados ou beta.

As funcionalidades de pré-visualização ou as características da bandeira não são destinadas à produção. Mudanças contínuas em APIs e comportamento, correções de erros e outras alterações podem resultar em aglomerados instáveis e tempo de inatividade.

As funcionalidades de pré-visualização públicas estão sob o suporte de "melhor esforço", uma vez que estas funcionalidades estão em pré-visualização e não se destinam à produção e são apoiadas pela AKS em equipas de suporte técnico HCI da Azure Stack HCI apenas durante o horário de trabalho. Para obter mais informações, consulte:

Insetos e problemas a montante

Dada a rapidez de desenvolvimento no projeto Kubernetes a montante, surgem invariavelmente bugs. Alguns destes bugs não podem ser remendados ou trabalhados dentro do sistema AKS on Azure Stack HCI. Em vez disso, as correções de bugs requerem patches maiores para projetos a montante (como Kubernetes, sistemas operativos de nó ou agente e kernel). Para os componentes que a Microsoft detém (como os fornecedores de API do cluster Azure Stack HCI), a AKS no Azure Stack HCI e o pessoal da Azure Stack HCI estão empenhados em corrigir problemas a montante na comunidade.

Quando um problema de suporte técnico é causado por um ou mais bugs a montante, as equipas de suporte e engenharia da AKS on Azure Stack HCI:

  • Identifique e ligue os bugs a montante com quaisquer detalhes de suporte para ajudar a explicar por que este problema afeta o seu cluster ou carga de trabalho. Os clientes recebem links para os repositórios necessários para que possam ver os problemas e ver quando um novo lançamento irá fornecer correções.
  • Fornecer potenciais soluções ou mitigação. Se a questão puder ser atenuada, um problema conhecido será arquivado no repositório AKS on Azure Stack HCI. O arquivo conhecido explica:
    • A questão, incluindo links para bugs a montante.
    • A solução e detalhes sobre uma atualização ou outra persistência da solução.
    • Prazos ásperos para a inclusão da edição, com base na cadência de libertação a montante.