diff --git a/content/pt-br/docs/concepts/windows/intro.md b/content/pt-br/docs/concepts/windows/intro.md index 749dc125a46c2..bb53701394bf9 100644 --- a/content/pt-br/docs/concepts/windows/intro.md +++ b/content/pt-br/docs/concepts/windows/intro.md @@ -1,9 +1,4 @@ --- -reviewers: -- jayunit100 -- jsturtevant -- marosset -- perithompson title: Contêineres Windows no Kubernetes content_type: concept weight: 65 @@ -19,181 +14,181 @@ Organizações com investimentos em aplicativos baseados em Windows e Linux não ## Nós Windows no Kubernetes -Para habilitar a orquestração de containers Windows no Kubernetes, inclua nós Windows em seu cluster Linux existente. A alocação de contêineres Windows em {{< glossary_tooltip text="Pods" term_id="pod" >}} no Kubernetes é similar à alocação de contêineres baseados em Linux. +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 {{< glossary_tooltip text="Pods" term_id="pod" >}} 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 {{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}} apenas no Linux, você pode implantar nós de trabalho executando Windows ou Linux. {{< glossary_tooltip text="Nós" term_id="node" >}} Windows são [suportados](#windows-os-version-support) desde que o sistema operacional seja Windows Server 2019 ou Windows Server 2022. -Este documento usa o termo *containers Windows* para se referir a containers Windows com isolamento de processo. O Kubernetes não suporta a execução de containers Windows com [isolamento Hyper-V](https://docs.microsoft.com/pt-br/virtualization/windowscontainers/manage-containers/hyperv-container). +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](https://docs.microsoft.com/pt-br/virtualization/windowscontainers/manage-containers/hyperv-container). ## Compatibilidade e limitações {#limitations} -Alguns recursos do nó estão disponíveis apenas se você usar um [runtime de container](#container-runtime) específico; outros não estão disponíveis em nós Windows, incluindo: +Alguns recursos do nó estão disponíveis apenas se você usar um [agente de execução de contêiner](#container-runtime) específico; outros não estão disponíveis em nós Windows, incluindo: -- HugePages: não suportado para containers Windows -- Contêineres privilegiados: não suportados para contêineres Windows. [Contêineres HostProcess](/docs/tasks/configure-pod-container/create-hostprocess-pod/) oferecem funcionalidade semelhante. -- TerminationGracePeriod: requer containerD +* HugePages: não suportado para contêineres Windows +* Contêineres privilegiados: não suportados para contêineres Windows. [Contêineres HostProcess](/docs/tasks/configure-pod-container/create-hostprocess-pod/) oferecem funcionalidade semelhante. +* TerminationGracePeriod: requer containerD Nem todos os recursos de namespaces compartilhados são suportados. Veja [Compatibilidade da API](#api) para mais detalhes. Veja [Compatibilidade de versão do sistema operacional Windows](#windows-os-version-support) para detalhes sobre as versões do Windows nas quais o Kubernetes é testado. -Do ponto de vista da API e do kubectl, containers Windows se comportam de maneira muito semelhante aos containers baseados em Linux. No entanto, há algumas diferenças notáveis em funcionalidades-chave que são destacadas nesta seção. +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 {#compatibilidade-linux-semelhanças} +### Comparação com Linux {#compatibility-linux-similarities} 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](/docs/concepts/workloads/pods/)** +* [Pods](/docs/concepts/workloads/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 containers Windows e Linux no mesmo Pod. Todos os containers 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 containers Windows: + 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 containers 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 container `postStart` e `preStop` - - ConfigMap, Secrets: como variáveis de ambiente ou volumes - - Volumes `emptyDir` - - Montagens de pipe nomeado do host - - Limites de recursos - - **Campo OS**: + * Ú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 container `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 containers Windows. + 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 containers. Se qualquer um desses campos for especificado, o Pod não será admitido pelo servidor API. - -- **[Recursos de carga de trabalho](/pt-br/docs/concepts/workloads/controllers/)** incluindo: - - ReplicaSet - - Deployment - - StatefulSet - - DaemonSet - - Job - - CronJob - - ReplicationController -- **{{< glossary_tooltip text="Serviços" term_id="service" >}}** - - Veja [Balanceamento de carga e Serviços](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) para mais detalhes. + * `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 containers. Se qualquer um desses campos for especificado, o Pod não será admitido pelo servidor API. + +* [Recursos de carga de trabalho](/pt-br/docs/concepts/workloads/controllers/) incluindo: + * ReplicaSet + * Deployment + * StatefulSet + * DaemonSet + * Job + * CronJob + * ReplicationController +* {{< glossary_tooltip text="Services" term_id="service" >}} + + Veja [Balanceamento de carga e Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-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 container -- {{< glossary_tooltip text="Escalonamento horizontal de pods" term_id="horizontal-pod-autoscaler" >}} -- {{< glossary_tooltip text="Quotas de recursos" term_id="resource-quota" >}} -- Pré-empção do scheduler +* `kubectl exec` +* Métricas de Pod e container +* {{< glossary_tooltip text="Escalonamento horizontal de pods" term_id="horizontal-pod-autoscaler" >}} +* {{< glossary_tooltip text="Quotas de recursos" term_id="resource*quota" >}} +* Pré-empção do schedule* -### Opções de linha de comando para o kubelet {#compatibilidade-kubelet} +### Opções de linha de comando para o kubelet {#kubelet-compatibility} 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](/pt-br/docs/concepts/configuration/windows-resource-management/) -- As flags `--kube-reserved`, `--system-reserved` e `--eviction-hard` atualizam [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) -- 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](/pt-br/docs/concepts/configuration/windows-resource-management/) para mais informações. -- A condição `PIDPressure` não está implementada -- O kubelet não executa ações de despejo de OOM +* A opção `--windows-priorityclass` permite definir a prioridade de agendamento do processo kubelet (veja [Gerenciamento de recursos de CPU](/pt-br/docs/concepts/configuration/windows-resource-management/)) +* As flags `--kube-reserved`, `--system-reserved` e `--eviction-hard` atualizam [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +* 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](/pt-br/docs/concepts/configuration/windows-resource-management/) 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 {#api} -Existem diferenças sutis na forma como as APIs do Kubernetes funcionam para o Windows devido ao SO e ao runtime de container. Algumas propriedades de carga de trabalho foram projetadas para Linux e falham ao rodar no Windows. +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](https://docs.microsoft.com/pt-br/windows/security/identity-protection/access-control/security-identifiers) (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 containers, ou entre os containers. -- **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 container, 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`. +* 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](https://docs.microsoft.com/pt-br/windows/security/identity-protection/access-control/security-identifiers) (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 container, 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 container 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 container {#compatibilidade-v1-pod-spec-containers} +#### Compatibilidade de campos para especificações de container {#compatibility-v1-pod-spec-containers} A lista a seguir documenta as diferenças entre como as especificações de container do Pod funcionam entre Windows e Linux: -- **Huge pages** não são implementadas no runtime de container do Windows e não estão disponíveis. Elas requerem [afirmação de um privilégio de usuário](https://docs.microsoft.com/pt-br/windows/desktop/Memory/large-page-support) que não é configurável para containers. -- `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 overprovisioning 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 containers como uma boa prática se o operador quiser evitar o overprovisioning 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 containers privilegiados, use [HostProcess Containers](/docs/tasks/configure-pod-container/create-hostprocess-pod/) 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 container -- `securityContext.runAsGroup` - não é possível no Windows, pois não há suporte para GID -- `securityContext.runAsNonRoot` - esta configuração impedirá que containers sejam executados como `ContainerAdministrator`, que é o equivalente mais próximo a um usuário root no Windows. -- `securityContext.runAsUser` - use [`runAsUserName`](/pt-br/docs/tasks/configure-pod-container/configure-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 {#compatibilidade-v1-pod} +* 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](https://docs.microsoft.com/pt-br/windows/desktop/Memory/large-page-support) 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 [HostProcess contêineres](/docs/tasks/configure-pod-container/create-hostprocess-pod/) 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 container +* `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`](/pt-br/docs/tasks/configure-pod-container/configure-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 {#compatibility-v1-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](#compatibilidade-v1-pod-spec-containers-hostnetwork) -- `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 container. -- `podSecurityContext` [veja abaixo](#compatibilidade-v1-pod-spec-containers-securitycontext) -- `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 container. Apenas a rede pode ser compartilhada. -- `terminationGracePeriodSeconds` - isso não está totalmente implementado no Docker no Windows, veja o [issue no GitHub](https://github.com/moby/moby/issues/25982). 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 container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), então pode ser substituído quando o container é 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. +* `hostIPC` e `hostPID` - compartilhamento de namespace do host não é possível no Windows +* `hostNetwork` - [veja abaixo](#compatibility-v1-pod-spec-containers-hostnetwork) +* `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 container. +* `podSecurityContext` [veja abaixo](#compatibility-v1-pod-spec-containers-securitycontext) +* `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 container. Apenas a rede pode ser compartilhada. +* `terminationGracePeriodSeconds` - isso não está totalmente implementado no Docker no Windows, veja o [issue no GitHub](https://github.com/moby/moby/issues/25982). 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 container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), então pode ser substituído quando o container é 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 {#compatibilidade-v1-pod-spec-containers-hostnetwork} +#### Compatibilidade de campos para hostNetwork {#compatibility-v1-pod-spec-containers-hostnetwork} {{< feature-state for_k8s_version="v1.26" state="alpha" >}} 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. {{< note >}} -Esta funcionalidade requer um runtime de container que suporte essa funcionalidade. +Esta funcionalidade requer um agente de execução de contêiner que suporte essa funcionalidade. {{< /note >}} -#### Compatibilidade de campos para o contexto de segurança do Pod {#compatibilidade-v1-pod-spec-containers-securitycontext} +#### Compatibilidade de campos para o contexto de segurança do Pod {#compatibility-v1-pod-spec-containers-securitycontext} Apenas `securityContext.runAsNonRoot` e `securityContext.windowsOptions` dos campos [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) do Pod funcionam no Windows. ## Detector de problemas do nó -O detector de problemas do nó (veja [Monitorando a saúde do nó](/docs/tasks/debug/debug-cluster/monitor-node-health/) tem suporte preliminar para Windows. Para mais informações, visite a [página do GitHub](https://github.com/kubernetes/node-problem-detector#windows) do projeto. +O detector de problemas do nó (veja [Monitorando a integridade do nó](/docs/tasks/debug/debug-cluster/monitor-node-health/) tem suporte preliminar para Windows. Para mais informações, visite a [página do GitHub](https://github.com/kubernetes/node-problem-detector#windows) do projeto. ## Container de pausa -Em um Pod Kubernetes, um container de infraestrutura ou "pausa" é criado primeiro para hospedar o container. 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. Containers que pertencem ao mesmo pod, incluindo infraestrutura e containers 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 containers de pausa para permitir que containers de trabalho falhem ou reiniciem sem perder qualquer configuração de rede. - +Em um Pod Kubernetes, um container de infraestrutura ou "pausa" é criado primeiro para hospedar o container. 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ó](/docs/tasks/debug/debug-cluster/monitor-node-health/)) tem suporte preliminar para Windows. Para mais informações, visite a [página do GitHub](https://github.com/kubernetes/node-problem-detector#windows) do projeto. O Kubernetes mantém uma imagem multi-arquitetura que inclui suporte para Windows. Para o Kubernetes v{{< skew currentPatchVersion >}} a imagem de pausa recomendada é `registry.k8s.io/pause:3.6`. O [código fonte](https://github.com/kubernetes/kubernetes/tree/master/build/pause) 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](https://docs.microsoft.com/pt-br/windows-hardware/drivers/install/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. -## Runtimes de container {#container-runtime} +## Agente de Execução de Contêiner {#container-runtime} -Você precisa instalar um {{< glossary_tooltip text="runtime de container" term_id="container-runtime" >}} em cada nó do cluster para que os Pods possam ser executados lá. +Você precisa instalar um {{< glossary_tooltip text="agente de execução de contêiner" term_id="container-runtime" >}} em cada nó do cluster para que os Pods possam ser executados lá. Os seguintes runtimes de container funcionam com Windows: @@ -203,34 +198,34 @@ Os seguintes runtimes de container funcionam com Windows: {{< feature-state for_k8s_version="v1.20" state="stable" >}} -Você pode usar {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ como o runtime de container para nós Kubernetes que executam Windows. +Você pode usar {{< glossary_tooltip term_id="containerd" text="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](/docs/setup/production-environment/container-runtimes/#containerd). {{< note >}} -Há uma [limitação conhecida](/pt-br/docs/tasks/configure-pod-container/configure-gmsa/s) ao usar GMSA com containerd para acessar compartilhamentos de rede do Windows, o que requer um patch no kernel. +Há uma [limitação conhecida](pt-br/docs/tasks/configure-pod-container/configure-gmsa/) ao usar GMSA com containerd para acessar compartilhamentos de rede do Windows, o que requer um patch no kernel. {{< /note >}} ### Mirantis Container Runtime {#mcr} -[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) está disponível como um runtime de container para todas as versões do Windows Server 2019 e posteriores. +[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (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](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html) para mais informações. -## Compatibilidade de versão do Windows OS {#windows-os-version-support} +## Compatibilidade de versão do sistema operacional Windows{#windows-os-version-support} -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 container. Apenas containers Windows com um sistema operacional de container do Windows Server 2019 são totalmente suportados. +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 container. Apenas contêineres Windows com um sistema operacional de container do Windows Server 2019 são totalmente suportados. Para o Kubernetes v{{< skew currentVersion >}}, 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 2019 +: Windows Server 2022 -**Windows Server SAC release** +Windows Server SAC release -- Windows Server versão 20H2 +: Windows Server versão 20H2 A [política de desvio de versão](/docs/setup/release/version-skew-policy/) do Kubernetes também se aplica. @@ -250,7 +245,7 @@ Consulte [Requisitos de hardware para o Windows Server na documentação da Micr 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](https://learn.microsoft.com/pt-br/windows-server/get-started/install-options-server-core-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 container do Windows são tipicamente maiores que as imagens de container do Linux, com tamanhos de imagem de container variando de [300MB a mais de 10GB](https://techcommunity.microsoft.com/t5/containers/nano-server-x-server-core-x-server-which-base-image-is-the-right/ba-p/2835785) para uma única imagem. Além disso, observe que a unidade `C:` em containers 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 container pode crescer ao ocupar quando usa armazenamento local no host. Veja [Containers no Windows - Documentação de Armazenamento de Container](https://learn.microsoft.com/pt-br/virtualization/windowscontainers/manage-containers/container-storage#storage-limits) para mais detalhes. +Ao avaliar o espaço em disco para nós de trabalho Windows, observe que as imagens de container do Windows são tipicamente maiores que as imagens de container do Linux, com tamanhos de imagem de container variando de [300MB a mais de 10GB](https://techcommunity.microsoft.com/t5/containers/nano-server-x-server-core-x-server-which-base-image-is-the-right/ba-p/2835785) 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 container pode crescer ao ocupar quando usa armazenamento local no host. Veja [Contêineres no Windows - Documentação de Armazenamento de Container](https://learn.microsoft.com/pt-br/virtualization/windowscontainers/manage-containers/container-storage#storage-limits) para mais detalhes. ## Obtendo ajuda e solucionando problemas {#troubleshooting}