Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Quando você cria implantações que usam contêineres do Windows Server no Serviço Kubernetes do Azure (AKS), há algumas diferenças em relação às implantações do Linux que você deve ter em mente. Para obter uma comparação detalhada das diferenças entre Windows e Linux no Kubernetes upstream, consulte Contêineres do Windows no Kubernetes.
Algumas das principais diferenças incluem:
- Identidade: o Windows Server usa um identificador de segurança binário (SID) maior armazenado no banco de dados do SAM (Gerenciador de Acesso à Segurança do Windows). Esse banco de dados não é compartilhado entre o host e contêineres ou entre contêineres.
- Permissões de ficheiro: o Windows Server usa uma lista de controlo de acesso baseada em SIDs em vez de uma máscara de bits de permissões e UID+GID.
- Caminhos de arquivo: A convenção no Windows Server é usar \ em vez de /. Nas especificações de pod que montam volumes, especifique o caminho corretamente para contêineres do Windows Server. Por exemplo, em vez de um ponto de montagem como /mnt/volume num contentor Linux, especifique uma letra de unidade e uma localização como /K/Volume para montar como a unidade K:.
Importante
A partir de 01 de março de 2026, o Azure Kubernetes Service (AKS) deixou de suportar pools de nós do Windows Server 2019. Grupos de nós com a versão 1.33+ do Kubernetes não podem usar o Windows Server 2019. A partir de 1 de abril de 2027, o AKS irá remover todas as imagens de nós existentes para o Windows Server 2019, o que significa que as operações de escalabilidade falharão. Para mais informações sobre esta descontinuação, consulte o problema do GitHub e o anúncio de descontinuação do Azure Updates. Para se manter informado sobre anúncios e atualizações, siga as notas de lançamento do AKS.
Importante
A partir de 15 de março de 2027, o Azure Kubernetes Service (AKS) deixou de suportar pools de nós do Windows Server 2022. Grupos de nós a executar Kubernetes versão 1.36+ não podem usar o Windows Server 2022. A partir de 01 de abril de 2028, o AKS irá remover todas as imagens de nós existentes para o Windows Server 2022, o que significa que as operações de escalabilidade irão falhar. Para mais informações sobre esta descontinuação, consulte o problema do GitHub e o anúncio de descontinuação do Azure Updates. Para se manter informado sobre anúncios e atualizações, siga as notas de lançamento do AKS.
Importante
A partir de 15 de maio de 2026, o AKS deixou de suportar o Canal Anual (Preview) do Windows Server. O AKS deixará de produzir novas imagens de nós do Canal Anual do Windows Server nem fornecerá correções de segurança. Não será possível criar novos pools de nós com o Canal Anual do Windows Server. A 15 de maio de 2027, o AKS irá remover todas as imagens existentes do Canal Anual do Windows Server, o que fará com que as operações de escalabilidade e remediação (reimagem e reimplantação) falhem. Para evitar interrupções, recomendamos a migração para o Canal de Serviço a Longo Prazo (LTSC).
- O Canal Anual do Windows Server utiliza imagens base do Windows Server 2022, que funcionarão no Windows Server 2022 e Windows Server 2025.
- Se estiver a usar Host Process Containers (HPC) ou a executar outros containers privilegiados para fins administrativos, é necessário realizar testes adicionais.
Para mais informações sobre esta reforma, consulte a edição Retirement GitHub. Para se manter informado sobre anúncios e atualizações, siga as notas de lançamento do AKS.
Este artigo aborda considerações importantes a ter em mente ao usar contêineres do Windows em vez de contêineres do Linux no Kubernetes. Para uma comparação detalhada de contêineres Windows e Linux, consulte Comparação com Linux.
Considerações
| Caraterística | Considerações sobre o Windows |
|---|---|
| Criação de clusters | • O primeiro pool de nós do sistema deve ser Linux. • O número máximo de nós por cluster é 5000. • O nome do conjunto de nós do Windows Server está limitado a seis caracteres. |
| Contentores privilegiados | Não suportado. O equivalente é contêineres HostProcess Containers (HPC). |
| Contentores HPC | • Os contentores HostProcess são a alternativa do Windows aos contentores privilegiados do Linux. Para obter mais informações, consulte Criar um pod do Windows HostProcess. |
| Azure Gestor de Política de Rede (Azure) | O Azure Network Policy Manager não suporta: • Portas nomeadas • Protocolo SCTP • Rótulos de correspondência negativa ou seletores de namespace (todos os rótulos, exceto "debug=true") • "exceto" blocos CIDR (um CIDR com exceções) • Windows Server 2019 |
| Atualização do nó | Os nós do Windows Server no AKS não aplicam automaticamente as atualizações do Windows. Em vez disso, execute uma atualização do pool de nós ou uma atualização da imagem do nó. Estas atualizações implementam novos nós com a imagem de nó de base mais recente do Windows Server 2019 e do Windows Server 2022, bem como as respetivas atualizações de segurança. |
| Limpeza de Imagens do AKS | Não suportado. |
| BYOCNI | Não suportado. |
| Open Service Mesh | Não suportado. |
| GPU | Suportado na pré-visualização. |
| GPU de várias instâncias | Não suportado. |
| VMs de 2ª geração | Suportado. Padrão no Windows Server 2025. |
| Configuração personalizada do nó | • A configuração do nó personalizado tem duas configurações: • kubelet: Suportado. • Configuração do SO: Não suportado. |
Próximos passos
Para obter mais informações sobre contêineres do Windows, consulte as Perguntas frequentes sobre contêineres do Windows Server.