Contêineres Windows no Kubernetes

Aplicativos Windows constituem uma grande parte dos serviços e aplicações que rodam em muitas organizações. Contêineres Windows fornecem uma maneira de encapsular processos e empacotar dependências, facilitando o uso de práticas DevOps e seguindo padrões nativos da nuvem para aplicativos Windows.

Organizações com investimentos em aplicativos baseados em Windows e Linux não precisam procurar orquestradores separados para gerenciar suas cargas de trabalho, levando a eficiências operacionais aumentadas em suas implantações, independentemente do sistema operacional.

Nós Windows no Kubernetes

Para habilitar a orquestração de contêineres Windows no Kubernetes, inclua nós Windows em seu cluster Linux existente. A alocação de contêineres Windows em Pods no Kubernetes é similar à alocação de contêineres baseados em Linux.

Para executar contêineres Windows, seu cluster Kubernetes deve incluir múltiplos sistemas operacionais. Embora você possa executar a camada de gerenciamento apenas no Linux, você pode implantar nós de trabalho executando Windows ou Linux.

Nós Windows são suportados desde que o sistema operacional seja Windows Server 2019 ou Windows Server 2022.

Este documento usa o termo contêineres Windows para se referir a contêineres Windows com isolamento de processo. O Kubernetes não suporta a execução de contêineres Windows com isolamento Hyper-V.

Compatibilidade e limitações

Alguns recursos do nó estão disponíveis apenas se você usar um agente de execução de contêiner específico; outros não estão disponíveis em nós Windows, incluindo:

• HugePages: não suportado para contêineres Windows
• Contêineres privilegiados: não suportados para contêineres Windows. Contêineres HostProcess oferecem funcionalidade semelhante.
• TerminationGracePeriod: requer containerD

Nem todos os recursos de namespaces compartilhados são suportados. Veja Compatibilidade da API para mais detalhes.

Veja Compatibilidade de versão do sistema operacional Windows para detalhes sobre as versões do Windows nas quais o Kubernetes é testado.

Do ponto de vista da API e do kubectl, contêineres Windows se comportam de maneira muito semelhante aos contêineres baseados em Linux. No entanto, há algumas diferenças notáveis em funcionalidades-chave que são destacadas nesta seção.

Comparação com Linux

Elementos-chave do Kubernetes funcionam da mesma forma no Windows como no Linux. Esta seção refere-se a várias abstrações de carga de trabalho e como elas se mapeiam para o Windows.

• Pods

  Um Pod é o bloco de construção básico do Kubernetes — a menor e mais simples unidade no modelo de objeto do Kubernetes que você cria ou implanta. Você não pode implantar contêineres Windows e Linux no mesmo Pod. Todos os contêineres em um Pod são agendados em um único Nó, onde cada Nó representa uma plataforma e arquitetura específicas. As seguintes capacidades, propriedades e eventos do Pod são suportados com contêineres Windows:

  • Único ou múltiplos contêineres por Pod com isolamento de processo e compartilhamento de volume

  • Campos de status do Pod

  • Verificações de readiness (prontidão), liveness (operacionalidade) e startup (inicialização)

  • Hooks de ciclo de vida do Contêiner postStart e preStop

  • ConfigMap, Secrets: como variáveis de ambiente ou volumes

  • Volumes emptyDir

  • Montagens de pipe nomeado do host

  • Limites de recursos

  • Campo Sistema Operacional:

    O campo .spec.os.name deve ser definido como windows para indicar que o Pod atual usa contêineres Windows.

    Se você definir o campo .spec.os.name como windows, não deve definir os seguintes campos no .spec desse Pod:

    • spec.hostPID
    • spec.hostIPC
    • spec.securityContext.seLinuxOptions
    • spec.securityContext.seccompProfile
    • spec.securityContext.fsGroup
    • spec.securityContext.fsGroupChangePolicy
    • spec.securityContext.sysctls
    • spec.shareProcessNamespace
    • spec.securityContext.runAsUser
    • spec.securityContext.runAsGroup
    • spec.securityContext.supplementalGroups
    • spec.containers[*].securityContext.seLinuxOptions
    • spec.containers[*].securityContext.seccompProfile
    • spec.containers[*].securityContext.capabilities
    • spec.containers[*].securityContext.readOnlyRootFilesystem
    • spec.containers[*].securityContext.privileged
    • spec.containers[*].securityContext.allowPrivilegeEscalation
    • spec.containers[*].securityContext.procMount
    • spec.containers[*].securityContext.runAsUser
    • spec.containers[*].securityContext.runAsGroup

    Na lista acima, curingas (*) indicam todos os elementos em uma lista. Por exemplo, spec.containers[*].securityContext refere*se ao objeto SecurityContext para todos os contêineres. Se qualquer um desses campos for especificado, o Pod não será admitido pelo servidor API.

• Recursos de carga de trabalho incluindo:

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job
  • CronJob
  • ReplicationController
• Services

  Veja Balanceamento de carga e Services para mais detalhes.

Pods, recursos de carga de trabalho e Services são elementos críticos para gerenciar cargas de trabalho Windows no Kubernetes. No entanto, por si só, eles não são suficientes para habilitar o gerenciamento adequado do ciclo de vida de cargas de trabalho Windows em um ambiente nativo da nuvem dinâmico.

• kubectl exec
• Métricas de Pod e Contêiner
• Escalonamento horizontal de pods
• Quotas de recursos
• Preempção do scheduler

Opções de linha de comando para o kubelet

Algumas opções de linha de comando do kubelet se comportam de maneira diferente no Windows, conforme descrito abaixo:

• A opção --windows-priorityclass permite definir a prioridade de agendamento do processo kubelet (veja Gerenciamento de recursos de CPU)
• As flags --kube-reserved, --system-reserved e --eviction-hard atualizam NodeAllocatable
• A opção de despejo usando --enforce-node-allocable não está implementada
• Ao executar em um nó Windows, o kubelet não tem restrições de memória ou CPU. --kube-reserved e --system-reserved apenas subtraem de NodeAllocatable e não garantem recursos fornecidos para cargas de trabalho. Veja Gerenciamento de recursos para nós Windows para mais informações.
• A condição PIDPressure não está implementada
• O kubelet não executa ações de despejo de OOM

Compatibilidade da API

Existem diferenças sutis na forma como as APIs do Kubernetes funcionam para o Windows devido ao SO e ao agente de execução de contêiner. Algumas propriedades de carga de trabalho foram projetadas para Linux e falham ao rodar no Windows.

Em um nível alto, esses conceitos de SO são diferentes:

• Identidade: Linux usa userID (UID) e groupID (GID) que são representados como tipos inteiros. Nomes de usuário e grupo não são canônicos - eles são apenas um alias em /etc/groups ou /etc/passwd de volta para UID+GID. O Windows usa um identificador de segurança (SID) binário maior que é armazenado no banco de dados Windows Security Access Manager (SAM). Este banco de dados não é compartilhado entre o host e os contêineres, ou entre os contêineres.
• Permissões de arquivo: o Windows usa uma lista de controle de acesso baseada em SIDs, enquanto sistemas POSIX como Linux usam uma máscara de bits baseada em permissões de objeto e UID+GID, além de listas de controle de acesso opcionais.
• Caminhos de arquivo: a convenção no Windows é usar \ em vez de /. As bibliotecas Go IO normalmente aceitam ambos e simplesmente funcionam, mas quando você está definindo um caminho ou linha de comando que é interpretada dentro de um Contêiner, pode ser necessário usar \.
• Sinais: Aplicativos interativos do Windows lidam com a terminação de maneira diferente e podem implementar um ou mais destes:
  • Uma thread de interface do usuário manipula mensagens bem definidas, incluindo WM_CLOSE.
  • Aplicativos de console lidam com Ctrl-C ou Ctrl-break usando um Manipulador de Controle.
  • Serviços registram uma função Manipuladora de Controle de Serviço que pode aceitar códigos de controle SERVICE_CONTROL_STOP.

Códigos de saída de Contêiner seguem a mesma convenção onde 0 é sucesso e diferente de zero é falha. Os códigos de erro específicos podem diferir entre Windows e Linux. No entanto, códigos de saída passados dos componentes do Kubernetes (kubelet, kube-proxy) são inalterados.

Compatibilidade de campos para especificações de Contêiner

A lista a seguir documenta as diferenças entre como as especificações de Contêiner do Pod funcionam entre Windows e Linux:

• Huge pages não são implementadas no agente de execução de contêiner do Windows e não estão disponíveis. Elas requerem afirmação de um privilégio de usuário que não é configurável para contêineres.
• requests.cpu e requests.memory - as solicitações são subtraídas dos recursos disponíveis do nó, para que possam ser usadas para evitar o superprovisionamento de um nó. No entanto, elas não podem ser usadas para garantir recursos em um nó superprovisionado. Elas devem ser aplicadas a todos os contêineres como uma boa prática se o operador quiser evitar o superprovisionamento completamente.
• securityContext.allowPrivilegeEscalation - não é possível no Windows; nenhuma das capacidades está conectada
• securityContext.capabilities - capacidades POSIX não são implementadas no Windows
• securityContext.privileged - o Windows não suporta contêineres privilegiados, use contêineres HostProcess em vez disso
• securityContext.procMount - o Windows não possui um sistema de arquivos /proc
• securityContext.readOnlyRootFilesystem - não é possível no Windows; acesso de gravação é necessário para que o registro e processos do sistema rodem dentro do Contêiner
• securityContext.runAsGroup - não é possível no Windows, pois não há suporte para GID
• securityContext.runAsNonRoot - esta configuração impedirá que contêineres sejam executados como ContainerAdministrator, que é o equivalente mais próximo a um usuário root no Windows.
• securityContext.runAsUser - use runAsUserName em vez disso
• securityContext.seLinuxOptions - não é possível no Windows, pois o SELinux é específico do Linux
• terminationMessagePath - isso tem algumas limitações, pois o Windows não suporta mapeamento de arquivos únicos. O valor padrão é /dev/termination-log, que funciona porque não existe no Windows por padrão.

Compatibilidade de campos para especificações de Pod

A lista a seguir documenta as diferenças entre como as especificações de Pod funcionam entre Windows e Linux:

• hostIPC e hostPID - compartilhamento de namespace do host não é possível no Windows
• hostNetwork - veja abaixo
• dnsPolicy - definir o dnsPolicy do Pod como ClusterFirstWithHostNet não é suportado no Windows porque a rede do host não é fornecida. Pods sempre rodam com uma rede de Contêiner.
• podSecurityContext veja abaixo
• shareProcessNamespace - este é um recurso beta e depende de namespaces Linux que não estão implementados no Windows. O Windows não pode compartilhar namespaces de processos ou o sistema de arquivos raiz do Contêiner. Apenas a rede pode ser compartilhada.
• terminationGracePeriodSeconds - isso não está totalmente implementado no Docker no Windows, veja o issue no GitHub. O comportamento atual é que o processo ENTRYPOINT recebe CTRL_SHUTDOWN_EVENT, então o Windows espera 5 segundos por padrão e finalmente encerra todos os processos usando o comportamento normal de desligamento do Windows. O padrão de 5 segundos está na verdade no registro do Windows dentro do Contêiner, então pode ser substituído quando o Contêiner é construído.
• volumeDevices - este é um recurso beta e não está implementado no Windows. O Windows não pode anexar dispositivos de bloco bruto a pods.
• volumes
  • Se você definir um volume emptyDir, não pode definir sua fonte de volume para memory.
• Você não pode habilitar mountPropagation para montagens de volume, pois isso não é suportado no Windows.

Compatibilidade de campos para hostNetwork

O kubelet agora pode solicitar que pods em execução em nós Windows usem o namespace de rede do host em vez de criar um novo namespace de rede de pod. Para habilitar essa funcionalidade, passe --feature-gates=WindowsHostNetwork=true para o kubelet.

Compatibilidade de campos para o contexto de segurança do Pod

Apenas securityContext.runAsNonRoot e securityContext.windowsOptions dos campos securityContext do Pod funcionam no Windows.

Detector de problemas do nó

O detector de problemas do nó (veja Monitorando a integridade do nó) tem suporte preliminar para Windows. Para mais informações, visite a página do GitHub do projeto.

Contêiner de pausa

Em um Pod Kubernetes, um Contêiner de infraestrutura ou "pausa" é criado primeiro para hospedar o Contêiner. No Linux, os cgroups e namespaces que compõem um pod precisam de um processo para manter sua existência contínua; o processo de pausa fornece isso. Contêineres que pertencem ao mesmo pod, incluindo infraestrutura e contêineres de trabalho, compartilham um endpoint de rede comum (mesmo endereço IPv4 e/ou IPv6, mesmos espaços de porta de rede). O Kubernetes usa contêineres de pausa para permitir que contêineres de trabalho falhem ou reiniciem sem perder qualquer configuração de rede. O detector de problemas do nó (veja Monitorando a integridade do nó) tem suporte preliminar para Windows. Para mais informações, visite a página do GitHub do projeto. O Kubernetes mantém uma imagem multi-arquitetura que inclui suporte para Windows. Para o Kubernetes v1.32.0 a imagem de pausa recomendada é registry.k8s.io/pause:3.6. O código fonte está disponível no GitHub.

A Microsoft mantém uma imagem multi-arquitetura diferente, com suporte para Windows amd64 e Linux, que você pode encontrar como mcr.microsoft.com/oss/kubernetes/pause:3.6. Esta imagem é construída a partir do mesmo código fonte que a imagem mantida pelo Kubernetes, mas todos os binários do Windows são assinados pelo Authenticode pela Microsoft. O projeto Kubernetes recomenda usar a imagem mantida pela Microsoft se você estiver implantando em um ambiente de produção ou similar que exija binários assinados.

Agente de Execução de Contêiner

Você precisa instalar um agente de execução de contêiner em cada nó do cluster para que os Pods possam ser executados lá.

Os seguintes runtimes de Contêiner funcionam com Windows:

ContainerD

Você pode usar ContainerD 1.4.0+ como o agente de execução de contêiner para nós Kubernetes que executam Windows.

Aprenda como instalar o ContainerD em um nó Windows.

Mirantis Contêiner Runtime

Mirantis Container Runtime (MCR) está disponível como um agente de execução de contêiner para todas as versões do Windows Server 2019 e posteriores.

Veja Instalar MCR em servidores Windows para mais informações.

Compatibilidade de versão do sistema operacional Windows

Em nós Windows, aplicam-se regras estritas de compatibilidade onde a versão do SO do host deve corresponder à versão da imagem base do Contêiner. Apenas contêineres Windows com um sistema operacional de Contêiner do Windows Server 2019 são totalmente suportados.

Para o Kubernetes v1.32, a compatibilidade do sistema operacional para nós Windows (e Pods) é a seguinte:

Windows Server LTSC release

Windows Server 2019

Windows Server 2022

Windows Server SAC release

Windows Server versão 20H2

A política de desvio de versão do Kubernetes também se aplica.

Recomendações e considerações de hardware

• Processador de 64 bits com 4 núcleos de CPU ou mais, capaz de suportar virtualização
• 8GB ou mais de RAM
• 50GB ou mais de espaço livre em disco

Consulte Requisitos de hardware para o Windows Server na documentação da Microsoft para obter as informações mais atualizadas sobre requisitos mínimos de hardware. Para orientação sobre como decidir sobre recursos para nós de trabalho em produção, consulte Nós de trabalho em produção na documentação do Kubernetes.

Para otimizar os recursos do sistema, se uma interface gráfica de usuário não for necessária, pode ser preferível usar uma instalação do Windows Server que exclua a opção de instalação Windows Desktop Experience, já que esta configuração normalmente libera mais recursos do sistema.

Ao avaliar o espaço em disco para nós de trabalho Windows, observe que as imagens de Contêiner do Windows são tipicamente maiores que as imagens de Contêiner do Linux, com tamanhos de imagem de Contêiner variando de 300MB a mais de 10GB para uma única imagem. Além disso, observe que a unidade C: em contêineres Windows representa um tamanho virtual livre de 20GB por padrão, que não é o espaço consumido real, mas sim o tamanho do disco para o qual um único Contêiner pode crescer ao ocupar quando usa armazenamento local no host. Veja Contêineres no Windows - Documentação de Armazenamento de Contêiner para mais detalhes.

Obtendo ajuda e solucionando problemas

Sua principal fonte de ajuda para solucionar problemas em seu cluster Kubernetes deve começar com a página de Solução de Problemas.

Alguma ajuda adicional, específica para Windows, está incluída nesta seção. Logs são um elemento importante na solução de problemas no Kubernetes. Certifique-se de incluí-los sempre que buscar assistência de outros colaboradores. Siga as instruções no guia de contribuição do SIG Windows sobre coleta de logs.

Relatando problemas e solicitações de funcionalidades

Se você tiver algo que pareça um bug ou gostaria de fazer uma solicitação de recurso, siga o guia de contribuição do SIG Windows para criar uma nova issue. Você deve primeiro pesquisar na lista de issues existentes caso tenha sido relatado anteriormente e comentar com sua experiência na issue e adicionar logs adicionais. O canal SIG Windows no Slack do Kubernetes também é uma ótima maneira de obter suporte inicial e ideias de solução de problemas antes de criar um ticket.

Validando a operabilidade do cluster Windows

O projeto Kubernetes fornece uma especificação de Windows Operational Readiness, acompanhada por um conjunto de testes estruturados. Este conjunto é dividido em dois conjuntos de testes, principal (core) e estendido (extended), cada um contendo categorias destinadas a testar áreas específicas. Pode ser usado para validar todas as funcionalidades de um sistema Windows e híbrido (misturado com nós Linux) com cobertura total.

Para configurar o projeto em um cluster recém-criado, consulte as instruções no guia do projeto.

Ferramentas de implantação

A ferramenta kubeadm ajuda você a implantar um cluster Kubernetes, fornecendo a camada de gerenciamento para gerenciá-lo, e nós para executar suas cargas de trabalho.

O projeto cluster API do Kubernetes também fornece meios para automatizar a implantação de nós Windows.

Canais de distribuição do Windows

Para uma explicação detalhada dos canais de distribuição do Windows, consulte a documentação da Microsoft.

Informações sobre os diferentes canais de serviço do Windows Server, incluindo seus modelos de suporte, podem ser encontradas em Canais de serviço do Windows Server.