Boa tarde, quero compartilhar com vocês minha experiência na configuração e utilização do serviço AWS EKS (Elastic Kubernetes Service) para containers Windows, ou melhor, sobre a impossibilidade de utilização, e o bug encontrado no container do sistema AWS, para aqueles quem estiver interessado neste serviço para contêineres Windows, consulte cat.
Eu sei que os contêineres do Windows não são um tópico popular e poucas pessoas os usam, mas ainda assim decidi escrever este artigo, já que havia alguns artigos sobre Habré sobre kubernetes e Windows e ainda existem essas pessoas.
começo
Tudo começou quando foi decidido migrar os serviços da nossa empresa para o kubernetes, que é 70% Windows e 30% Linux. Para tanto, o serviço de nuvem AWS EKS foi considerado uma das opções possíveis. Até 8 de outubro de 2019, o AWS EKS Windows estava em Public Preview, comecei com ele, a versão antiga 1.11 do kubernetes era usada lá, mas resolvi verificar mesmo assim e ver em que estágio esse serviço de nuvem estava, se estava funcionando de jeito nenhum, como se viu, não, havia um bug com a adição de remoção de pods, enquanto os antigos paravam de responder via ip interno da mesma sub-rede do nó de trabalho do Windows.
Portanto, foi decidido abandonar o uso do AWS EKS em favor de nosso próprio cluster em kubernetes no mesmo EC2, apenas teríamos que descrever nós mesmos todo o balanceamento e HA via CloudFormation.
Suporte a contêineres do Windows do Amazon EKS agora disponível ao público
por Martin Beeby | em 08 de outubro de 2019
Antes que eu tivesse tempo de adicionar um modelo ao CloudFormation para meu próprio cluster, vi esta notícia
Claro, deixei todo o meu trabalho de lado e comecei a estudar o que eles fizeram para o GA e como tudo mudou com o Public Preview. Sim, AWS, muito bem, atualizou as imagens do nó do trabalhador do Windows para a versão 1.14, assim como o próprio cluster, versão 1.14 no EKS, agora suporta nós do Windows. Projeto em pré-visualização pública em Eles encobriram e disseram agora usar a documentação oficial aqui:
Integração de um cluster EKS à VPC e às sub-redes atuais
Em todas as fontes, no link acima no anúncio e também na documentação, foi proposto implantar o cluster por meio do utilitário proprietário eksctl ou por meio de CloudFormation + kubectl depois, usando apenas sub-redes públicas na Amazon, além de criar um VPC separada para um novo cluster.
Esta opção não é adequada para muitos; em primeiro lugar, uma VPC separada significa custos adicionais pelo seu custo + tráfego de peering para sua VPC atual. O que devem fazer aqueles que já possuem uma infraestrutura pronta na AWS com suas próprias contas múltiplas da AWS, VPC, sub-redes, tabelas de rotas, gateway de trânsito e assim por diante? Claro, você não quer quebrar ou refazer tudo isso e precisa integrar o novo cluster EKS à infraestrutura de rede atual, usando o VPC existente e, para separação, no máximo criar novas sub-redes para o cluster.
No meu caso foi escolhido esse caminho, usei o VPC existente, adicionei apenas 2 sub-redes públicas e 2 sub-redes privadas para o novo cluster, claro, todas as regras foram levadas em consideração conforme a documentação .
Havia também uma condição: nenhum nó de trabalho em sub-redes públicas usando EIP.
eksctl versus CloudFormation
De imediato, farei uma reserva que tentei os dois métodos de implantação de um cluster, em ambos os casos o quadro era o mesmo.
Mostrarei um exemplo usando apenas eksctl, pois o código aqui será mais curto. Usando eksctl, implante o cluster em 3 etapas:
1. Criamos o próprio cluster + nó de trabalho Linux, que posteriormente hospedará os contêineres do sistema e o mesmo controlador vpc malfadado.
eksctl create cluster
--name yyy
--region www
--version 1.14
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx
--asg-access
--nodegroup-name linux-workers
--node-type t3.small
--node-volume-size 20
--ssh-public-key wwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami auto
--node-private-networkingPara implantar em uma VPC existente, basta especificar o ID de suas sub-redes e o eksctl determinará a própria VPC.
Para garantir que seus nós do trabalhador sejam implementados apenas em uma sub-rede privada, é necessário especificar --node-private-networking para nodegroup.
2. Instalamos o vpc-controller em nosso cluster, que então processará nossos nós de trabalho, contando a quantidade de endereços IP livres, bem como a quantidade de ENIs na instância, adicionando-os e removendo-os.
eksctl utils install-vpc-controllers --name yyy --approve3. Depois que os contêineres do sistema forem iniciados com sucesso no nó de trabalho do Linux, incluindo o vpc-controller, tudo o que resta é criar outro grupo de nós com trabalhadores do Windows.
eksctl create nodegroup
--region www
--cluster yyy
--version 1.14
--name windows-workers
--node-type t3.small
--ssh-public-key wwwwwwwwww
--nodes 1
--nodes-min 1
--nodes-max 2
--node-ami-family WindowsServer2019CoreContainer
--node-ami ami-0573336fc96252d05
--node-private-networkingDepois que seu nó tiver se conectado com êxito ao cluster e tudo parecer estar bem, ele estará no status Pronto, mas não.
Erro no controlador vpc
Se tentarmos executar pods em um nó de trabalho do Windows, obteremos o erro:
NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]Se olharmos mais a fundo, vemos que nossa instância na AWS se parece com isto:
E deveria ser assim:
A partir disso fica claro que o vpc-controller não cumpriu sua parte por algum motivo e não conseguiu adicionar novos endereços IP à instância para que os pods pudessem utilizá-los.
Vejamos os logs do pod vpc-controller e é isso que vemos:
registro do kubectl -n sistema kube
I1011 06:32:03.910140 1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162 1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238 1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423 1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211 1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229 1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302 1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313 1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.As pesquisas no Google não levaram a nada, já que aparentemente ninguém havia detectado tal bug ainda, ou não havia postado um problema sobre ele, eu mesmo tive que pensar nas opções primeiro. A primeira coisa que me veio à mente foi que talvez o controlador vpc não consiga resolver ip-10-xxx.ap-xxx.compute.internal e alcançá-lo e, portanto, ocorrem erros.
Sim, de fato, usamos servidores DNS customizados na VPC e, em princípio, não usamos os da Amazon, portanto nem mesmo o encaminhamento foi configurado para este domínio ap-xxx.compute.internal. Testei essa opção e não deu resultado, talvez o teste não tenha sido limpo e, portanto, ainda mais, ao me comunicar com o suporte técnico, sucumbi à ideia deles.
Como não havia realmente nenhuma ideia, todos os grupos de segurança foram criados pelo próprio eksctl, então não havia dúvidas sobre sua operacionalidade, as tabelas de rotas também estavam corretas, nat, dns, acesso à Internet com nós de trabalho também estavam lá.
Além disso, se você implantar um nó de trabalho em uma sub-rede pública sem usar —node-private-networking, esse nó será atualizado imediatamente pelo controlador vpc e tudo funcionará perfeitamente.
Havia duas opções:
- Desista e espere até que alguém descreva esse bug na AWS e o corrija, e então você poderá usar o AWS EKS Windows com segurança, porque eles acabaram de lançar no GA (8 dias se passaram no momento em que este artigo foi escrito), muitos provavelmente irão siga o mesmo caminho que eu.
- Escreva para o AWS Support e conte a essência do problema com um monte de logs de todos os lugares e prove que o serviço deles não funciona ao usar seu VPC e sub-redes, não é à toa que tivemos suporte comercial, você deveria usar pelo menos uma vez :)
Comunicação com engenheiros da AWS
Tendo criado um ticket no portal, optei erroneamente por me responder via Web - e-mail ou central de suporte, através desta opção eles poderão responder em poucos dias, apesar de meu ticket ter Gravidade - Sistema prejudicado, o que significou uma resposta em menos de 12 horas e, como o plano de suporte empresarial tem suporte 24 horas por dia, 7 dias por semana, eu esperava o melhor, mas deu certo como sempre.
Meu ticket ficou sem atribuição de sexta até segunda, então resolvi escrever para eles novamente e escolhi a opção de resposta por chat. Depois de esperar um pouco, Harshad Madhav foi designado para me ver, e então tudo começou...
Depuramos com ele online por 3 horas seguidas, transferindo logs, implantando o mesmo cluster no laboratório da AWS para emular o problema, recriando o cluster da minha parte e assim por diante, a única coisa que descobrimos é que de nos logs ficou claro que a resolução não estava funcionando nos nomes de domínio internos da AWS, sobre os quais escrevi acima, e Harshad Madhav me pediu para criar o encaminhamento, supostamente usamos DNS personalizado e isso pode ser um problema.
Encaminhamento
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Foi o que foi feito, o dia acabou. Harshad Madhav escreveu de volta para verificar e deveria funcionar, mas não, a resolução não ajudou em nada.
Depois houve comunicação com mais 2 engenheiros, um simplesmente saiu do chat, aparentemente estava com medo de um caso complexo, o segundo passou meu dia novamente em um ciclo completo de depuração, envio de logs, criação de clusters em ambos os lados, no final ele apenas disse bem, funciona para mim, aqui estou eu faço tudo passo a passo na documentação oficial e você e você terão sucesso.
Ao que pedi educadamente que ele saísse e designasse outra pessoa para o meu tíquete se você não soubesse onde procurar o problema.
Final
No terceiro dia, um novo engenheiro, Arun B., foi designado para mim, e desde o início da comunicação com ele ficou imediatamente claro que não se tratava dos três engenheiros anteriores. Ele leu todo o histórico e imediatamente pediu para coletar os logs usando seu próprio script no ps3, que estava em seu github. Isso foi seguido novamente por todas as iterações de criação de clusters, saída de resultados de comandos, coleta de logs, mas Arun B. estava se movendo na direção certa, a julgar pelas perguntas que me foram feitas.
Quando chegamos ao ponto de ativar -stderrthreshold=debug em seu controlador vpc e o que aconteceu a seguir? claro que não funciona) o pod simplesmente não inicia com esta opção, apenas -stderrthreshold=info funciona.
Terminamos aqui e Arun B. disse que tentaria reproduzir meus passos para obter o mesmo erro. No dia seguinte recebo uma resposta de Arun B. ele não abandonou o caso, mas pegou o código de revisão do seu controlador vpc e encontrou o local onde está e porque não funciona:
Assim, se você usa a tabela de rotas principal em sua VPC, então por padrão ela não possui associações com as sub-redes necessárias, que são tão necessárias para o vpc-controller, no caso de uma sub-rede pública, ela possui uma tabela de rotas customizada que tem uma associação.
Ao adicionar manualmente associações para a tabela de rotas principal com as sub-redes necessárias e recriar o grupo de nós, tudo funciona perfeitamente.
Espero que Arun B. realmente relate esse bug aos desenvolvedores do EKS e veremos uma nova versão do vpc-controller onde tudo funcionará imediatamente. Atualmente a versão mais recente é: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
tem esse problema.
Obrigado a todos que leram até o final, testem tudo que vão usar em produção antes da implementação.
Fonte: habr.com