GA의 Amazon EKS Windows에는 버그가 있지만 가장 빠릅니다.

좋은 오후입니다. Windows 컨테이너용 AWS EKS(Elastic Kubernetes Service) 서비스를 설정하고 사용한 경험이나 사용 불가능성과 AWS 시스템 컨테이너에서 발견된 버그에 대해 공유하고 싶습니다. Windows 컨테이너용 이 서비스에 관심이 있는 분은 cat 아래에 문의하세요.

Windows 컨테이너가 인기 있는 주제가 아니며 이를 사용하는 사람이 거의 없다는 것을 알고 있지만, kubernetes 및 Windows에 대한 Habré에 대한 몇 가지 기사가 있었고 여전히 그런 사람들이 있기 때문에 이 기사를 쓰기로 결정했습니다.

처음

모든 것은 우리 회사의 서비스를 Windows 70%, Linux 30%인 kubernetes로 마이그레이션하기로 결정했을 때 시작되었습니다. 이를 위해 AWS EKS 클라우드 서비스가 가능한 옵션 중 하나로 간주되었습니다. 8년 2019월 1.11일까지 AWS EKS Windows는 퍼블릭 프리뷰 상태였고, 거기서는 이전 XNUMX 버전의 kubernetes가 사용되었지만 어쨌든 확인하고 이 클라우드 서비스가 어느 단계에 있는지, 작동 중인지 확인하기로 결정했습니다. 아니요, 포드 제거를 추가하는 데 버그가 있었지만 이전 포드는 Windows 작업자 노드와 동일한 서브넷의 내부 IP를 통해 응답을 중지했습니다.

따라서 동일한 EC2의 kubernetes에 있는 자체 클러스터를 선호하여 AWS EKS 사용을 포기하기로 결정했습니다. CloudFormation을 통해 모든 밸런싱 및 HA를 직접 설명하면 됩니다.

Amazon EKS Windows 컨테이너 지원, 이제 정식 출시됨

마틴 비비 | 08년 2019월 XNUMX일

내 클러스터의 CloudFormation에 템플릿을 추가하기 전에 다음 뉴스를 보았습니다. Amazon EKS Windows 컨테이너 지원, 이제 정식 출시됨

물론 저는 모든 작업을 제쳐두고 GA를 위해 무엇을 했는지, 그리고 Public Preview를 통해 모든 것이 어떻게 바뀌었는지 연구하기 시작했습니다. 예, AWS는 Windows 작업자 노드의 이미지를 버전 1.14로 업데이트했으며 EKS의 클러스터 자체 버전 1.14는 이제 Windows 노드를 지원합니다. 공개 미리보기 프로젝트 기타베 그들은 그것을 은폐하고 이제 여기 공식 문서를 사용한다고 말했습니다. EKS 윈도우 지원

EKS 클러스터를 현재 VPC 및 서브넷에 통합

모든 소스, 발표 및 문서의 위 링크에서 독점 eksctl 유틸리티 또는 CloudFormation + kubectl을 통해 클러스터를 배포하고 Amazon의 퍼블릭 서브넷만 사용하고 클러스터를 생성하는 것이 제안되었습니다. 새 클러스터에 대한 별도의 VPC.

이 옵션은 많은 사람들에게 적합하지 않습니다. 첫째, 별도의 VPC는 ​​비용 + 현재 VPC에 대한 피어링 트래픽에 대한 추가 비용을 의미합니다. 이미 AWS에 자체 다중 AWS 계정, VPC, 서브넷, 라우팅 테이블, 전송 게이트웨이 등을 갖춘 인프라가 이미 구축되어 있는 사람들은 무엇을 해야 합니까? 물론 이 모든 것을 중단하거나 다시 실행하고 싶지는 않으며 기존 VPC를 사용하여 새 EKS 클러스터를 현재 네트워크 인프라에 통합해야 하며, 분리를 위해 기껏해야 클러스터에 대한 새 서브넷을 생성해야 합니다.

제 경우에는 이 경로가 선택되었고 기존 VPC를 사용했으며 새 클러스터에 퍼블릭 서브넷 2개와 프라이빗 서브넷 2개만 추가했습니다. 물론 문서에 따라 모든 규칙이 고려되었습니다. Amazon EKS 클러스터 VPC 생성.

또한 한 가지 조건이 있었습니다. EIP를 사용하는 퍼블릭 서브넷에 작업자 노드가 없다는 것입니다.

eksctl 대 CloudFormation

클러스터를 배포하는 두 가지 방법을 모두 시도했다고 즉시 예약하겠습니다. 두 경우 모두 그림이 동일했습니다.

여기서는 코드가 더 짧기 때문에 eksctl만 사용한 예를 보여 드리겠습니다. eksctl을 사용하여 3단계로 클러스터를 배포합니다.

1. 나중에 시스템 컨테이너와 동일한 불운한 vpc-controller를 호스팅할 클러스터 자체 + Linux 작업자 노드를 생성합니다.

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-networking

기존 VPC에 배포하려면 서브넷의 ID만 지정하면 eksctl이 VPC 자체를 결정합니다.

작업자 노드가 프라이빗 서브넷에만 배포되도록 하려면 노드 그룹에 --node-private-networking을 지정해야 합니다.

2. 클러스터에 vpc-controller를 설치하면 작업자 노드를 처리하여 무료 IP 주소 수와 인스턴스의 ENI 수를 계산하여 추가 및 제거합니다.

eksctl utils install-vpc-controllers --name yyy --approve

3. vpc-controller를 포함하여 Linux 작업자 노드에서 시스템 컨테이너가 성공적으로 시작된 후 남은 작업은 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-networking

노드가 클러스터에 성공적으로 연결되고 모든 것이 정상인 것처럼 보이면 준비 상태가 되지만 아니요입니다.

vpc 컨트롤러 오류

Windows 작업자 노드에서 Pod를 실행하려고 하면 다음 오류가 발생합니다.

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]

더 자세히 살펴보면 AWS의 인스턴스가 다음과 같다는 것을 알 수 있습니다.

그리고 다음과 같아야 합니다:

이를 통해 vpc-controller가 어떤 이유로 해당 역할을 수행하지 못했고 포드가 사용할 수 있도록 새 IP 주소를 인스턴스에 추가할 수 없다는 것이 분명해졌습니다.

vpc-controller 포드의 로그를 살펴보면 다음과 같습니다.

kubectl 로그 -n 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.

Google에서 검색해도 아무런 결과가 나오지 않았습니다. 아직 그러한 버그를 발견한 사람이 없거나 버그에 대한 문제를 게시하지 않았기 때문에 먼저 옵션을 스스로 생각해야 했습니다. 가장 먼저 떠오른 것은 아마도 vpc-controller가 ip-10-xxx.ap-xxx.compute.internal을 확인하고 이에 도달할 수 없어 오류가 발생한다는 것입니다.

예, 실제로 우리는 VPC에서 사용자 지정 DNS 서버를 사용하고 원칙적으로 Amazon 서버를 사용하지 않으므로 이 ap-xxx.compute.internal 도메인에 대한 전달조차 구성되지 않았습니다. 이 옵션을 테스트했지만 결과가 나오지 않았고 테스트가 깨끗하지 않았을 수도 있으므로 기술 지원과 대화할 때 그들의 아이디어에 굴복했습니다.

실제로 아이디어가 없었기 때문에 모든 보안 그룹은 eksctl 자체에서 생성되었으므로 서비스 가능성에 대해 의심의 여지가 없었으며 라우팅 테이블도 정확했고 nat, dns, 작업자 노드를 통한 인터넷 액세스도 있었습니다.

또한 —node-private-networking을 사용하지 않고 작업자 노드를 퍼블릭 서브넷에 배포하는 경우 이 노드는 vpc-controller에 의해 즉시 업데이트되고 모든 것이 시계처럼 작동했습니다.

두 가지 옵션이 있습니다.

1. 포기하고 누군가가 AWS에서 이 버그를 설명하고 수정될 때까지 기다리면 AWS EKS Windows를 안전하게 사용할 수 있습니다. Windows는 방금 GA로 출시되었기 때문입니다(이 기사를 쓰는 시점에서 8일이 지났습니다). 많은 사람들이 아마도 그럴 것입니다. 나와 같은 길을 따라 가세요.
2. AWS Support에 글을 쓰고 모든 곳에서 수집된 로그를 통해 문제의 본질을 알리고 VPC와 서브넷을 사용할 때 해당 서비스가 작동하지 않는다는 것을 증명하십시오. 우리가 비즈니스 지원을 받은 것은 아무것도 아니므로 사용해야 합니다. 적어도 한 번은 :)

AWS 엔지니어와의 커뮤니케이션

포털에서 티켓을 생성한 후 실수로 웹(이메일 또는 지원 센터)을 통해 응답하기로 선택했습니다. 이 옵션을 통해 내 티켓에 심각도 - 시스템 손상이 있음에도 불구하고 며칠 후에 응답할 수 있습니다. 12시간 이내 응답을 의미했으며 비즈니스 지원 계획에는 연중무휴 24시간 지원이 포함되어 있기 때문에 최선을 다하길 바랐지만 언제나처럼 결과가 나왔습니다.

내 티켓은 금요일부터 월요일까지 할당되지 않은 상태로 남아 있었고, 다시 편지를 쓰기로 결정하고 채팅 응답 옵션을 선택했습니다. 잠시 기다린 후 Harshad Madhav가 나를 만나도록 약속되었고 시작되었습니다 ...

우리는 3시간 연속 온라인으로 디버깅하고, 로그를 전송하고, 문제를 에뮬레이션하기 위해 AWS 실험실에 동일한 클러스터를 배포하고, 내 부분에서 클러스터를 다시 생성하는 등의 작업을 수행했습니다. 로그를 보면 resol이 위에서 작성한 AWS 내부 도메인 이름이 작동하지 않는 것이 분명했고 Harshad Madhav가 나에게 전달 생성을 요청했는데 우리는 사용자 지정 DNS를 사용하고 있으며 이는 문제가 될 수 있습니다.

전송

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

그것이 끝났고 하루가 끝났습니다. Harshad Madhav가 확인하기 위해 답장을 보냈고 제대로 작동해야 했지만 아니요, 해결 방법은 전혀 도움이 되지 않았습니다.

그런 다음 2명의 엔지니어와 추가로 의사소통이 이루어졌습니다. 한 명은 단순히 채팅에서 나갔고 분명히 그는 복잡한 사례를 두려워했으며 두 번째는 디버깅, 로그 전송, 양쪽에 클러스터 생성의 전체 주기에 다시 하루를 보냈습니다. 결국 그는 방금 잘 말했습니다. 그것은 저에게 효과적입니다. 여기 있습니다. 공식 문서에서 모든 것을 단계별로 수행하면 당신과 당신은 성공할 것입니다.

문제를 어디서 찾을 수 있는지 모르면 떠나고 내 티켓에 다른 사람을 할당하라고 정중하게 요청했습니다.

결승

셋째 날, 새로운 엔지니어 Arun B.가 나에게 배정되었고, 그와의 의사소통이 시작될 때부터 이 사람이 이전 엔지니어 3명이 아니라는 것이 즉시 분명해졌습니다. 그는 전체 기록을 읽고 즉시 자신의 github에 있는 ps1에서 자신의 스크립트를 사용하여 로그를 수집하도록 요청했습니다. 여기에 다시 클러스터 생성, 명령 결과 출력, 로그 수집의 모든 반복이 이어졌지만 Arun B.는 나에게 묻는 질문에 따라 올바른 방향으로 움직이고 있었습니다.

vpc-controller에서 -stderrthreshold=debug를 활성화하는 지점에 도달한 시점은 언제였으며, 그 다음에는 무슨 일이 일어났습니까? 물론 작동하지 않습니다) 포드는 이 옵션으로 시작하지 않고 -stderrthreshold=info만 작동합니다.

우리는 여기서 끝냈고 Arun B.는 같은 오류가 발생하기 위해 내 단계를 재현하려고 노력할 것이라고 말했습니다. 다음날 Arun B로부터 응답을 받았습니다. 그는 이 사건을 포기하지 않았지만 vpc-controller의 리뷰 코드를 가져와 그것이 있는 위치와 작동하지 않는 이유를 찾았습니다.

따라서 VPC에서 기본 라우팅 테이블을 사용하는 경우 기본적으로 vpc-controller에 꼭 필요한 필수 서브넷과의 연결이 없으며 퍼블릭 서브넷의 경우 사용자 지정 라우팅 테이블이 있습니다. 연관성이 있는 것입니다.

필요한 서브넷이 포함된 기본 라우팅 테이블에 대한 연결을 수동으로 추가하고 노드 그룹을 다시 생성하면 모든 것이 완벽하게 작동합니다.

Arun B.가 실제로 이 버그를 EKS 개발자에게 보고하고 모든 것이 즉시 작동하는 새 버전의 vpc-controller를 보게 되기를 바랍니다. 현재 최신 버전은 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1입니다.
이 문제가 있습니다.

끝까지 읽어주신 모든 분들께 감사드리며, 구현에 앞서 프로덕션에서 사용할 모든 것을 테스트해 보세요.

출처 : habr.com