Xin chào, tôi muốn chia sẻ với bạn trải nghiệm của tôi trong việc thiết lập và sử dụng dịch vụ AWS EKS (Dịch vụ Kubernetes đàn hồi) cho các bộ chứa Windows, hay nói đúng hơn là về việc không thể sử dụng dịch vụ này và lỗi được tìm thấy trong bộ chứa hệ thống AWS, đối với những dịch vụ đó. Những người quan tâm đến dịch vụ này dành cho vùng chứa Windows, vui lòng theo dõi cat.
Tôi biết rằng vùng chứa Windows không phải là một chủ đề phổ biến và ít người sử dụng chúng, nhưng tôi vẫn quyết định viết bài này, vì đã có một số bài viết về Habré trên kubernetes và Windows và vẫn còn những người như vậy.
bắt đầu
Mọi chuyện bắt đầu khi người ta quyết định chuyển các dịch vụ trong công ty chúng tôi sang kubernetes, 70% Windows và 30% Linux. Với mục đích này, dịch vụ đám mây AWS EKS được coi là một trong những lựa chọn khả thi. Cho đến ngày 8 tháng 2019 năm 1.11, AWS EKS Windows ở chế độ Xem trước công khai, tôi đã bắt đầu với nó, phiên bản XNUMX cũ của kubernetes đã được sử dụng ở đó, nhưng tôi vẫn quyết định kiểm tra xem dịch vụ đám mây này đang ở giai đoạn nào, liệu nó có hoạt động không hóa ra là không, có một lỗi với việc bổ sung loại bỏ các nhóm, trong khi các nhóm cũ ngừng phản hồi qua ip nội bộ từ cùng mạng con với nút nhân viên windows.
Do đó, chúng tôi đã quyết định từ bỏ việc sử dụng AWS EKS để chuyển sang sử dụng cụm riêng của chúng tôi trên kubernetes trên cùng một EC2, chỉ có điều chúng tôi sẽ phải tự mô tả tất cả hoạt động cân bằng và HA thông qua CloudFormation.
Hỗ trợ bộ chứa Windows của Amazon EKS hiện đã có sẵn rộng rãi
của Martin Beeby | vào ngày 08 tháng 2019 năm XNUMX
Trước khi có thời gian thêm mẫu vào CloudFormation cho cụm của riêng mình, tôi đã thấy tin này
Tất nhiên, tôi đặt tất cả công việc của mình sang một bên và bắt đầu nghiên cứu những gì họ đã làm cho GA cũng như mọi thứ đã thay đổi như thế nào với Bản xem trước công khai. Có, AWS, làm tốt lắm, đã cập nhật hình ảnh cho nút Windows Worker lên phiên bản 1.14, cũng như chính cụm đó, phiên bản 1.14 trong EKS, hiện hỗ trợ các nút Windows. Dự án được xem trước công khai tại Họ che đậy nó và nói bây giờ hãy sử dụng tài liệu chính thức ở đây:
Tích hợp cụm EKS vào VPC và mạng con hiện tại
Trong tất cả các nguồn, trong liên kết ở trên trong thông báo cũng như trong tài liệu, người ta đã đề xuất triển khai cụm thông qua tiện ích eksctl độc quyền hoặc thông qua CloudFormation + kubectl sau đó, chỉ sử dụng mạng con công cộng trong Amazon, cũng như tạo một VPC riêng biệt cho một cụm mới.
Tùy chọn này không phù hợp với nhiều người; thứ nhất, một VPC riêng biệt có nghĩa là chi phí bổ sung cho chi phí của nó + lưu lượng truy cập ngang hàng đến VPC hiện tại của bạn. Những người đã có sẵn cơ sở hạ tầng trong AWS với nhiều tài khoản AWS, VPC, mạng con, bảng định tuyến, cổng chuyển tuyến, v.v. nên làm gì? Tất nhiên, bạn không muốn phá vỡ hoặc làm lại tất cả những điều này và bạn cần tích hợp cụm EKS mới vào cơ sở hạ tầng mạng hiện tại, sử dụng VPC hiện có và để phân tách, nhiều nhất là tạo các mạng con mới cho cụm.
Trong trường hợp của tôi, đường dẫn này đã được chọn, tôi đã sử dụng VPC hiện có, chỉ thêm 2 mạng con công cộng và 2 mạng con riêng tư cho cụm mới, tất nhiên, tất cả các quy tắc đã được tính đến theo tài liệu .
Ngoài ra còn có một điều kiện: không có nút công nhân nào trong mạng con công cộng sử dụng EIP.
eksctl vs CloudFormation
Tôi sẽ đặt trước ngay rằng tôi đã thử cả hai phương pháp triển khai một cụm, trong cả hai trường hợp, hình ảnh đều giống nhau.
Tôi sẽ chỉ đưa ra một ví dụ bằng cách sử dụng eksctl vì mã ở đây sẽ ngắn hơn. Sử dụng eksctl, triển khai cụm theo 3 bước:
1. Chúng tôi tự tạo cụm + nút nhân viên Linux, sau này sẽ lưu trữ các bộ chứa hệ thống và cùng bộ điều khiển vpc xấu số đó.
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Để triển khai lên VPC hiện có, chỉ cần chỉ định id mạng con của bạn và eksctl sẽ tự xác định VPC.
Để đảm bảo rằng các nút công nhân của bạn chỉ được triển khai trên mạng con riêng tư, bạn cần chỉ định --node-private-networking cho nhóm nút.
2. Chúng tôi cài đặt bộ điều khiển vpc trong cụm của mình, sau đó cụm này sẽ xử lý các nút công nhân của chúng tôi, đếm số lượng địa chỉ IP miễn phí cũng như số lượng ENI trên phiên bản, thêm và xóa chúng.
eksctl utils install-vpc-controllers --name yyy --approve3.Sau khi bộ chứa hệ thống của bạn khởi chạy thành công trên nút nhân viên Linux, bao gồm cả bộ điều khiển vpc, tất cả những gì còn lại là tạo một nhóm nút khác với nhân viên 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-networkingSau khi nút của bạn đã kết nối thành công với cụm của bạn và mọi thứ có vẻ ổn, nút đó ở trạng thái Sẵn sàng, nhưng không.
Lỗi trong bộ điều khiển vpc
Nếu chúng tôi cố chạy nhóm trên nút Windows Worker, chúng tôi sẽ gặp lỗi:
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]Nếu tìm hiểu sâu hơn, chúng ta sẽ thấy rằng phiên bản của chúng ta trong AWS trông như thế này:
Và nó phải như thế này:
Từ đó, rõ ràng là bộ điều khiển vpc đã không hoàn thành vai trò của mình vì một số lý do và không thể thêm địa chỉ IP mới vào phiên bản để các nhóm có thể sử dụng chúng.
Hãy xem nhật ký của nhóm bộ điều khiển vpc và đây là những gì chúng ta thấy:
nhật ký kubectl -n hệ thống 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.Tìm kiếm trên Google không dẫn đến kết quả gì, vì dường như chưa có ai gặp phải lỗi như vậy hoặc chưa đăng vấn đề về nó, nên trước tiên tôi phải tự mình nghĩ ra các phương án. Điều đầu tiên tôi nghĩ đến là có lẽ bộ điều khiển vpc không thể phân giải ip-10-xxx.ap-xxx.compute.internal và tiếp cận nó, do đó xảy ra lỗi.
Có, thực sự, chúng tôi sử dụng máy chủ DNS tùy chỉnh trong VPC và về nguyên tắc, chúng tôi không sử dụng máy chủ Amazon, do đó, ngay cả việc chuyển tiếp cũng không được định cấu hình cho miền ap-xxx.compute.internal này. Tôi đã thử nghiệm tùy chọn này và nó không mang lại kết quả, có lẽ thử nghiệm không rõ ràng, và do đó, hơn nữa, khi liên hệ với bộ phận hỗ trợ kỹ thuật, tôi đã không chịu nổi ý tưởng của họ.
Vì thực sự không có bất kỳ ý tưởng nào nên tất cả các nhóm bảo mật đều do chính eksctl tạo ra, vì vậy không có nghi ngờ gì về khả năng sử dụng của chúng, các bảng lộ trình cũng chính xác, nat, dns, truy cập Internet bằng các nút công nhân cũng ở đó.
Hơn nữa, nếu bạn triển khai một nút công nhân đến một mạng con công cộng mà không sử dụng mạng —node-private-networking, thì nút này ngay lập tức được bộ điều khiển vpc cập nhật và mọi thứ hoạt động như kim đồng hồ.
Có hai lựa chọn:
- Hãy từ bỏ và đợi cho đến khi ai đó mô tả lỗi này trong AWS và họ sửa nó, khi đó bạn có thể sử dụng AWS EKS Windows một cách an toàn, vì chúng vừa được phát hành trong GA (đã 8 ngày trôi qua tại thời điểm viết bài này), nhiều người có thể sẽ đi theo con đường giống tôi.
- Viết thư cho Bộ phận hỗ trợ AWS và cho họ biết bản chất của vấn đề với hàng loạt nhật ký từ khắp mọi nơi và chứng minh cho họ thấy rằng dịch vụ của họ không hoạt động khi sử dụng VPC và mạng con của bạn, không phải vô cớ mà chúng tôi đã hỗ trợ Doanh nghiệp, bạn nên sử dụng ít nhất một lần :)
Giao tiếp với các kỹ sư AWS
Sau khi tạo một vé trên cổng, tôi đã chọn nhầm trả lời tôi qua Web - email hoặc trung tâm hỗ trợ, thông qua tùy chọn này họ có thể trả lời bạn sau vài ngày, mặc dù thực tế là vé của tôi có Mức độ nghiêm trọng - Hệ thống bị suy giảm có nghĩa là phản hồi trong vòng <12 giờ và vì gói hỗ trợ Doanh nghiệp có hỗ trợ 24/7 nên tôi đã hy vọng điều tốt nhất, nhưng nó vẫn diễn ra như mọi khi.
Vé của tôi chưa được chỉ định từ thứ Sáu cho đến thứ Hai, sau đó tôi quyết định viết thư lại cho họ và chọn tùy chọn Phản hồi trò chuyện. Sau khi chờ đợi một thời gian ngắn, Harshad Madhav được hẹn gặp tôi, và rồi mọi chuyện bắt đầu...
Chúng tôi đã sửa lỗi trực tuyến trong 3 giờ liên tục, chuyển nhật ký, triển khai cùng một cụm trong phòng thí nghiệm AWS để mô phỏng sự cố, tạo lại cụm từ phía tôi, v.v., điều duy nhất chúng tôi đạt được là từ nhật ký cho thấy rõ ràng rằng resol không hoạt động. Tên miền nội bộ AWS mà tôi đã viết ở trên và Harshad Madhav đã yêu cầu tôi tạo chuyển tiếp, được cho là chúng tôi sử dụng DNS tùy chỉnh và đây có thể là một vấn đề.
Chuyển tiếp
ap-xxx.compute.internal -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)Thế là xong, ngày đã kết thúc. Harshad Madhav đã viết thư lại để kiểm tra và nó sẽ hoạt động, nhưng không, giải pháp đó chẳng giúp ích được gì cả.
Sau đó, có liên lạc với 2 kỹ sư nữa, một người đơn giản bỏ cuộc trò chuyện, có vẻ như anh ta sợ một trường hợp phức tạp, người thứ hai lại dành cả ngày của tôi cho một chu trình gỡ lỗi đầy đủ, gửi nhật ký, tạo cụm ở cả hai bên, trong cuối cùng anh ấy chỉ nói tốt, nó hiệu quả với tôi, tôi đây tôi làm mọi thứ từng bước trong tài liệu chính thức và bạn và bạn sẽ thành công.
Tôi lịch sự yêu cầu anh ta rời đi và giao cho người khác nhận vé của tôi nếu bạn không biết tìm vấn đề ở đâu.
Chung kết
Vào ngày thứ ba, một kỹ sư mới Arun B. được giao cho tôi, và ngay từ khi bắt đầu liên lạc với anh ta, tôi đã thấy ngay rằng đây không phải là 3 kỹ sư trước đó. Anh ấy đọc toàn bộ lịch sử và ngay lập tức yêu cầu thu thập nhật ký bằng tập lệnh của riêng anh ấy trên ps1, trên github của anh ấy. Tiếp theo đó là tất cả các lần lặp lại việc tạo cụm, xuất kết quả lệnh, thu thập nhật ký, nhưng Arun B. đã đi đúng hướng dựa trên các câu hỏi được đặt ra cho tôi.
Khi nào chúng tôi bắt đầu kích hoạt -stderrthreshold=debug trong bộ điều khiển vpc của họ và điều gì xảy ra tiếp theo? tất nhiên là nó không hoạt động) pod đơn giản là không bắt đầu với tùy chọn này, chỉ -stderrthreshold=info hoạt động.
Chúng tôi đã hoàn thành ở đây và Arun B. nói rằng anh ấy sẽ cố gắng lặp lại các bước của tôi để gặp lỗi tương tự. Ngày hôm sau, tôi nhận được phản hồi từ Arun B. Anh ấy không bỏ qua trường hợp này mà lấy mã đánh giá bộ điều khiển vpc của họ và tìm ra vị trí của nó và tại sao nó không hoạt động:
Do đó, nếu bạn sử dụng bảng tuyến chính trong VPC của mình thì theo mặc định, nó không có liên kết với các mạng con cần thiết, rất cần thiết cho bộ điều khiển vpc, trong trường hợp mạng con công cộng, nó có một bảng tuyến tùy chỉnh đó có một sự liên kết.
Bằng cách thêm thủ công các liên kết cho bảng lộ trình chính với các mạng con cần thiết và tạo lại nhóm nút, mọi thứ đều hoạt động hoàn hảo.
Tôi hy vọng rằng Arun B. sẽ thực sự báo cáo lỗi này cho các nhà phát triển EKS và chúng ta sẽ thấy một phiên bản mới của bộ điều khiển vpc nơi mọi thứ sẽ hoạt động tốt. Hiện tại phiên bản mới nhất là: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
có vấn đề này
Cảm ơn tất cả những người đã đọc đến cuối, hãy kiểm tra mọi thứ bạn định sử dụng trong sản xuất trước khi triển khai.
Nguồn: www.habr.com