Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

Implantando Kubernetes em Clusters Windows

Ao provisionar um cluster personalizado, o Rancher utiliza o RKE2 para instalar o Kubernetes em seus nós existentes.

Em um cluster Windows provisionado com o Rancher, o cluster deve conter nós Linux e Windows. O plano de controle do Kubernetes pode ser executado apenas em nós Linux, e os nós Windows podem ter apenas o papel de worker. Os nós Windows podem ser usados apenas para implantar cargas de trabalho.

Para um resumo das funcionalidades do Kubernetes suportadas no Windows, consulte a documentação do Kubernetes sobre funcionalidade e limitações suportadas para usar Kubernetes com Windows ou o guia para agendar contêineres Windows no Kubernetes.

SUSE® Rancher Prime: RKE2 Funcionalidades para Clusters Windows

Listadas abaixo estão as principais funcionalidades do RKE2 para provisionamento de clusters Windows:

Contêineres Windows com RKE2 alimentado por containerd
Provisionamento adicionado de clusters personalizados Windows RKE2 diretamente da interface do Rancher
Calico e Flannel CNI para clusters personalizados Windows RKE2
As versões SAC do Windows Server (2004 e 20H2) estão incluídas na prévia técnica

O Rancher permitirá que os pods de carga de trabalho Windows sejam implantados, por padrão, em nós Windows e em nós Linux com o papel de worker. Ao criar clusters mistos no RKE2, você deve editar o nodeSelector no gráfico para direcionar os pods a serem colocados em um nó Windows compatível. Consulte a documentação do Kubernetes para mais informações sobre como usar nodeSelector para atribuir pods a nós.

Contêineres HostProcess no Windows RKE2 são suportados no Kubernetes v1.24.1 e superior. Consulte a documentação upstream para mais informações.

Requisitos Gerais

Os requisitos gerais de rede e do sistema operacional para nós do Windows são os mesmos que para outras instalações do Rancher.

Requisitos do SO

Nosso suporte para Windows Server e contêineres do Windows corresponde ao ciclo de vida oficial da Microsoft para LTSC (Canal de Manutenção de Longo Prazo) e SAC (Canal Semestral).

Para as datas do ciclo de vida de suporte para Windows Server, consulte a Documentação da Microsoft.

Kubernetes Version

Para mais informações sobre as versões dos componentes do Kubernetes, consulte as matrizes de suporte para versões do RKE2.

Requisitos do Nó

Os hosts no cluster precisam ter pelo menos:

2 núcleos de CPU
5 GB de memória
50 GB de espaço em disco

O Rancher não provisionará o nó se ele não atender a esses requisitos.

Requisitos de Rede

Antes de provisionar um novo cluster, certifique-se de que você já instalou o Rancher em um dispositivo que aceita tráfego de rede de entrada. Isso é necessário para que os nós do cluster se comuniquem com o Rancher. Se você ainda não instalou o Rancher, consulte a documentação de instalação antes de prosseguir com este guia.

O Rancher suporta Windows usando Calico e Flannel como provedores de rede.

Se você estiver configurando conjuntos de opções DHCP para uma nuvem privada virtual AWS, observe que no campo de opção domain-name apenas um nome de domínio pode ser especificado. De acordo com as opções DHCP documentação:

Alguns sistemas operacionais Linux aceitam vários nomes de domínio separados por espaços. No entanto, outros sistemas operacionais Linux e Windows tratam o valor como um único domínio, o que resulta em comportamento inesperado. Se o seu conjunto de opções DHCP estiver associado a uma VPC que possui instâncias com vários sistemas operacionais, especifique apenas um nome de domínio.

Rancher no VMware vSphere com ESXi 6.7u2 e superior

Se você estiver usando o Rancher no VMware vSphere com ESXi 6.7u2 ou posterior com Red Hat Enterprise Linux 8.3, CentOS 8.3 ou SUSE Enterprise Linux 15 SP2 ou posterior, é necessário desativar o recurso de descarregamento de hardware do adaptador de rede virtual vmxnet3. A falha em fazer isso resultará na falha de todas as conexões de rede entre pods em diferentes nós do cluster com erros de timeout. Todas as conexões de pods do Windows para serviços críticos em execução em nós Linux, como CoreDNS, também falharão. É possível que conexões externas também falhem. Esse problema é resultado das distribuições Linux habilitando o recurso de descarregamento de hardware em vmxnet3 e um bug no recurso de descarregamento de hardware vmxnet3 que resulta no descarte de pacotes para tráfego de sobreposição de convidados. Para resolver esse problema, é necessário desativar o recurso de descarregamento de hardware vmxnet3. Essa configuração não persiste após a reinicialização, portanto, é necessário desativá-la a cada inicialização. A recomendação é criar um arquivo de unidade systemd em /etc/systemd/system/disable_hw_offloading.service, que desativa o recurso de descarregamento de hardware vmxnet3 na inicialização. Um exemplo de arquivo de unidade systemd que desativa o recurso de descarregamento de hardware vmxnet3 é o seguinte. Observe que <VM network interface> deve ser personalizado para a interface de rede do host vmxnet3, por exemplo, ens192:

[Unit]
Description=Disable vmxnet3 hardware offloading feature

[Service]
Type=oneshot
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-segmentation off
ExecStart=ethtool -K <VM network interface> tx-udp_tnl-csum-segmentation off
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Em seguida, defina as permissões apropriadas no arquivo de unidade systemd:

chmod 0644 /etc/systemd/system/disable_hw_offloading.service

Por fim, habilite o serviço systemd:

systemctl enable disable_hw_offloading.service

Requisitos de Arquitetura

Os nós de gerenciamento do cluster Kubernetes (etcd e controlplane) devem ser executados em nós Linux.

Os nós worker, onde suas cargas de trabalho serão implantadas, geralmente serão nós Windows, mas deve haver pelo menos um nó worker que seja executado em Linux para rodar o agente do cluster Rancher, DNS, servidor de métricas e contêineres relacionados ao Ingress.

Arquitetura Recomendada

Recomendamos a arquitetura mínima de três nós listada na tabela abaixo, mas você sempre pode adicionar mais workers Linux e Windows para escalar seu cluster para redundância:

Nó	Sistema operacional	Função(s) do Cluster Kubernetes	de finalidade
Nó 1	Linux (Ubuntu Server 18.04 recomendado)	Plano de controle, etcd, worker	Gerenciar o cluster Kubernetes
Nó 2	Linux (Ubuntu Server 18.04 recomendado)	Subordinado	Suportar o agente do Cluster Rancher, servidor de Métricas, DNS e Ingress para o cluster
Nó 3	Windows (Windows Server Core versão 1809 ou superior necessária, versão 2022 recomendada)	Subordinado	Execute seus contêineres Windows

Nó

Sistema operacional

Função(s) do Cluster Kubernetes

de finalidade

Nó 1

Linux (Ubuntu Server 18.04 recomendado)

Plano de controle, etcd, worker

Gerenciar o cluster Kubernetes

Nó 2

Linux (Ubuntu Server 18.04 recomendado)

Subordinado

Suportar o agente do Cluster Rancher, servidor de Métricas, DNS e Ingress para o cluster

Nó 3

Windows (Windows Server Core versão 1809 ou superior necessária, versão 2022 recomendada)

Subordinado

Execute seus contêineres Windows

Requisitos de Contêiner

O Windows requer que os contêineres sejam construídos na mesma versão do Windows Server em que estão sendo implantados. Portanto, os contêineres devem ser construídos na versão Windows Server Core 1809 ou superior. Se você tiver contêineres existentes construídos para uma versão anterior do Windows Server Core, eles devem ser reconstruídos na versão Windows Server Core 1809 ou superior.

Requisitos Específicos do Provedor de Nuvem

Se você definir um provedor de nuvem Kubernetes em seu cluster, alguns passos adicionais são necessários. Você pode querer definir um provedor de nuvem se desejar aproveitar as capacidades de um provedor de nuvem, por exemplo, para provisionar automaticamente armazenamento, balanceadores de carga ou outra infraestrutura para seu cluster. Consulte esta página para detalhes sobre como configurar um cluster de nós de provedor de nuvem que atenda aos pré-requisitos.

Se você estiver usando o provedor de nuvem GCE (Google Compute Engine), deve fazer o seguinte:

Ative o provedor de nuvem GCE no cluster.yml seguindo esses passos.
Ao provisionar o cluster no Rancher, escolha Provedor de nuvem personalizado como o provedor de nuvem na interface do Rancher.

Tutorial: Como Criar um Cluster com Suporte a Windows

Este tutorial descreve como criar um cluster provisionado pelo Rancher com os três nós na arquitetura recomendada.

Para configurar um cluster com suporte a nós e contêineres Windows, você precisará concluir as tarefas abaixo.

1. Provisionar Hosts

Para começar a provisionar um cluster em nós existentes com suporte a Windows, prepare seus hosts.

Seus hosts podem ser:

VMs hospedadas na nuvem
VMs de clusters de virtualização
Servidores bare-metal

Você irá provisionar três nós:

Um nó Linux, que gerencia o plano de controle do Kubernetes, armazena seu etcd e, opcionalmente, pode ser um worker.
Um segundo nó Linux, que será outro worker.
O nó Windows, que executará seus contêineres Windows como um worker.

Nó	Sistema operacional
Nó 1	Linux (Ubuntu Server 18.04 recomendado)
Nó 2	Linux (Ubuntu Server 18.04 recomendado)
Nó 3	Windows (versão Windows Server Core 1809 ou superior necessária, versão 2022 recomendada)

Nó

Sistema operacional

Nó 1

Linux (Ubuntu Server 18.04 recomendado)

Nó 2

Linux (Ubuntu Server 18.04 recomendado)

Nó 3

Windows (versão Windows Server Core 1809 ou superior necessária, versão 2022 recomendada)

Se seus nós forem hospedados por um Provedor de Nuvem e você quiser suporte à automação, como balanceadores de carga ou dispositivos de armazenamento persistente, seus nós têm requisitos de configuração adicionais. Para mais detalhes, veja Selecionando Provedores de Nuvem.

2. Crie o Cluster em Nós Existentes

As instruções para criar um cluster Windows em nós existentes são muito semelhantes às instruções gerais para criar um cluster personalizado com alguns requisitos específicos para Windows.

No canto superior esquerdo, clique em ☰ > Gerenciamento de Cluster.
Na página Clusters, clique em Criar.
Clique em Custom.
Digite um nome para seu cluster no campo Nome do Cluster.
No menu suspenso Versão do Kubernetes, selecione uma versão do Kubernetes suportada.
No campo Rede de Contêineres, selecione Calico ou Flannel.
Clique em Criar.

3. Adicione nós ao cluster

Esta seção descreve como registrar seus nós Linux e worker em seu cluster. Você executará um comando em cada nó, que instalará o rancher-system-agent e permitirá que o Rancher gerencie cada nó.

Adicionar nó Master Linux

Nesta seção, preenchemos um formulário na interface do Rancher para obter um comando personalizado para instalar o agente Rancher no nó Master Linux. Em seguida, copiaremos o comando e o executaremos em nosso nó Master Linux para registrar o nó no cluster.

O primeiro nó em seu cluster deve ser um host Linux que tenha tanto os papéis de Plano de Controle quanto de etcd. No mínimo, ambos os papéis devem estar habilitados para este nó, e este nó deve ser adicionado ao seu cluster antes que você possa adicionar hosts Windows.

Após a criação do cluster, navegue até a aba Registro.
Em Passo 1 na seção Papel do Nó, selecione os três papéis. Embora você possa escolher apenas os papéis etcd e Plano de Controle, recomendamos selecionar os três.
Opcional: Se você clicar em Mostrar Avançado, poderá configurar configurações adicionais, como especificar o(s) endereço(s) IP, substituir o nome do host do nó ou adicionar rótulos ou taints ao nó.
Em Passo 2, na seção Registro, copie o comando exibido na tela para sua área de transferência.
Acesse seu host Linux via SSH e execute o comando que você copiou para sua área de transferência.

Resultado:

Seu cluster foi criado e atribuído ao estado de Atualizando. O Rancher está configurando seu cluster.

Pode levar alguns minutos para que o nó se registre e apareça na aba Máquinas.

Você poderá acessar o cluster assim que seu estado mudar para Ativo.

Adicionar nó worker Linux

Nesta seção, executamos um comando para registrar o nó worker Linux no cluster.

Após o provisionamento inicial do seu cluster, seu cluster possui apenas um único host Linux. Em seguida, adicionamos outro host Linux worker, que será usado para suportar agente do cluster Rancher, servidor de métricas, DNS e Ingress para seu cluster.

Após a criação do cluster, navegue até a aba Registro.
Em Passo 1 na seção Papel do Nó, selecione worker.
Opcional: Se você clicar em Mostrar Avançado, poderá configurar opções adicionais, como especificar o(s) endereço(s) IP, substituir o nome do host do nó ou adicionar rótulos ou taints ao nó.
Em Passo 2, na seção Registro, copie o comando exibido na tela para sua área de transferência.
Acesse seu host Linux via SSH e execute o comando que você copiou para sua área de transferência.

Resultado:

O papel worker está instalado em seu host Linux, e o nó se registra no Rancher. Pode levar alguns minutos para que o nó seja registrado em seu cluster.

Taints em nós worker Linux

Para cada nó worker Linux adicionado ao cluster, os seguintes taints serão adicionados ao nó worker Linux. Ao adicionar este taint ao nó worker Linux, quaisquer cargas de trabalho adicionadas ao cluster Windows serão automaticamente agendadas para o nó worker Windows. Se você quiser agendar cargas de trabalho especificamente no nó worker Linux, precisará adicionar tolerâncias a essas cargas de trabalho.

Chave do Taint Valor do Taint Efeito do Taint

cattle.io/os

linux

NoSchedule

Adicionar um nó worker Windows

Nesta seção, executamos um comando para registrar o nó worker Windows no cluster.

O comando de registro para adicionar os workers Windows só aparece após o cluster estar em execução com Linux etcd, plano de controle e nós worker.

Após a criação do cluster, navegue até a aba Registro.
Em Passo 1 na seção Papel do Nó, selecione worker.
Opcional: Se você clicar em Mostrar Avançado, poderá configurar opções adicionais, como especificar o(s) endereço(s) IP, substituir o nome do host do nó ou adicionar rótulos ou taints ao nó.
Em Passo 2, na seção Registro, copie o comando para os workers Windows exibido na tela para sua área de transferência.
Faça login em seu host Windows usando sua ferramenta preferida, como Microsoft Remote Desktop. Execute o comando copiado para sua área de transferência no Console do PowerShell como Administrador.
Opcional: Repita estas instruções se você quiser adicionar mais nós Windows ao seu cluster.

Resultado:

O papel worker está instalado em seu host Windows, e o nó se registra no Rancher. Pode levar alguns minutos para que o nó seja registrado em seu cluster.

Agora você tem um cluster Kubernetes Windows.

Próximas etapas opcionais

Após criar seu cluster, você pode acessá-lo através da interface do Rancher. Como uma melhor prática, recomendamos configurar essas maneiras alternativas de acessar seu cluster:

Acesse seu cluster com a CLI kubectl: Siga estas etapas para acessar clusters com kubectl em sua estação de trabalho. Neste caso, você será autenticado através do proxy de autenticação do servidor Rancher, e então o Rancher o conectará ao cluster downstream. Este método permite que você gerencie o cluster sem a interface do Rancher.
Acesse seu cluster com a CLI kubectl, usando o endpoint autorizado do cluster: Siga estas etapas para acessar seu cluster com kubectl diretamente, sem autenticar através do servidor Rancher. Recomendamos configurar este método alternativo para acessar seu cluster, para que, caso você não consiga se conectar ao Rancher, ainda possa acessar o cluster.

Configuração para Classes de Armazenamento no Azure

Se você estiver usando VMs do Azure para seus nós, pode usar Arquivos do Azure como uma StorageClass para o cluster. Para detalhes, consulte esta seção.