GA ಯಲ್ಲಿ Amazon EKS ವಿಂಡೋಸ್ ದೋಷಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ವೇಗವಾಗಿದೆ

ಶುಭ ಮಧ್ಯಾಹ್ನ, ವಿಂಡೋಸ್ ಕಂಟೈನರ್‌ಗಳಿಗಾಗಿ AWS EKS (Elastic Kubernetes Service) ಸೇವೆಯನ್ನು ಹೊಂದಿಸುವಲ್ಲಿ ಮತ್ತು ಬಳಸುವಲ್ಲಿ ನನ್ನ ಅನುಭವವನ್ನು ನಿಮ್ಮೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಬಯಸುತ್ತೇನೆ ಅಥವಾ ಬದಲಿಗೆ ಅದನ್ನು ಬಳಸುವ ಅಸಾಧ್ಯತೆ ಮತ್ತು AWS ಸಿಸ್ಟಮ್ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ದೋಷದ ಬಗ್ಗೆ ವಿಂಡೋಸ್ ಕಂಟೈನರ್‌ಗಳಿಗಾಗಿ ಈ ಸೇವೆಯಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿರುವವರು, ದಯವಿಟ್ಟು ಬೆಕ್ಕು ಅಡಿಯಲ್ಲಿ.

ವಿಂಡೋಸ್ ಕಂಟೇನರ್‌ಗಳು ಜನಪ್ರಿಯ ವಿಷಯವಲ್ಲ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ ಮತ್ತು ಕೆಲವೇ ಜನರು ಅವುಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಆದರೆ ನಾನು ಇನ್ನೂ ಈ ಲೇಖನವನ್ನು ಬರೆಯಲು ನಿರ್ಧರಿಸಿದೆ, ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ವಿಂಡೋಸ್‌ನಲ್ಲಿ ಹಬ್ರೆ ಕುರಿತು ಒಂದೆರಡು ಲೇಖನಗಳು ಇದ್ದವು ಮತ್ತು ಅಂತಹ ಜನರು ಇನ್ನೂ ಇದ್ದಾರೆ.

Начало

ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿನ ಸೇವೆಗಳನ್ನು 70% ವಿಂಡೋಸ್ ಮತ್ತು 30% ಲಿನಕ್ಸ್‌ನ kubernetes ಗೆ ಸ್ಥಳಾಂತರಿಸಲು ನಿರ್ಧರಿಸಿದಾಗ ಇದು ಪ್ರಾರಂಭವಾಯಿತು. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, AWS EKS ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಸಂಭವನೀಯ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ. ಅಕ್ಟೋಬರ್ 8, 2019 ರವರೆಗೆ, AWS EKS ವಿಂಡೋಸ್ ಸಾರ್ವಜನಿಕ ಪೂರ್ವವೀಕ್ಷಣೆಯಲ್ಲಿತ್ತು, ನಾನು ಅದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದೆ, ಹಳೆಯ 1.11 ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿಯನ್ನು ಅಲ್ಲಿ ಬಳಸಲಾಗಿದೆ, ಆದರೆ ನಾನು ಅದನ್ನು ಹೇಗಾದರೂ ಪರಿಶೀಲಿಸಲು ನಿರ್ಧರಿಸಿದೆ ಮತ್ತು ಈ ಕ್ಲೌಡ್ ಸೇವೆಯು ಯಾವ ಹಂತದಲ್ಲಿದೆ, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ನೋಡಲು ನಿರ್ಧರಿಸಿದೆ ಅದು ಬದಲಾದಂತೆ, ಇಲ್ಲ, ಪಾಡ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದರ ಜೊತೆಗೆ ದೋಷವಿತ್ತು, ಆದರೆ ಹಳೆಯವುಗಳು ವಿಂಡೋಸ್ ವರ್ಕರ್ ನೋಡ್‌ನ ಅದೇ ಸಬ್‌ನೆಟ್‌ನಿಂದ ಆಂತರಿಕ ಐಪಿ ಮೂಲಕ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದವು.

ಆದ್ದರಿಂದ, ಅದೇ EC2 ನಲ್ಲಿ kubernetes ನಲ್ಲಿ ನಮ್ಮದೇ ಕ್ಲಸ್ಟರ್ ಪರವಾಗಿ AWS EKS ಬಳಕೆಯನ್ನು ತ್ಯಜಿಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು, ನಾವು ಕ್ಲೌಡ್ ಫಾರ್ಮೇಶನ್ ಮೂಲಕ ಎಲ್ಲಾ ಸಮತೋಲನ ಮತ್ತು HA ಅನ್ನು ನಾವೇ ವಿವರಿಸಬೇಕಾಗಿದೆ.

Amazon EKS ವಿಂಡೋಸ್ ಕಂಟೈನರ್ ಬೆಂಬಲ ಈಗ ಸಾಮಾನ್ಯವಾಗಿ ಲಭ್ಯವಿದೆ

ಮಾರ್ಟಿನ್ ಬೀಬಿ ಅವರಿಂದ | 08 OCT 2019 ರಂದು

ನನ್ನ ಸ್ವಂತ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಕ್ಲೌಡ್ ಫಾರ್ಮೇಶನ್‌ಗೆ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಸೇರಿಸಲು ನಾನು ಸಮಯ ಹೊಂದುವ ಮೊದಲು, ನಾನು ಈ ಸುದ್ದಿಯನ್ನು ನೋಡಿದೆ Amazon EKS ವಿಂಡೋಸ್ ಕಂಟೈನರ್ ಬೆಂಬಲ ಈಗ ಸಾಮಾನ್ಯವಾಗಿ ಲಭ್ಯವಿದೆ

ಸಹಜವಾಗಿ, ನಾನು ನನ್ನ ಎಲ್ಲಾ ಕೆಲಸವನ್ನು ಪಕ್ಕಕ್ಕೆ ಇರಿಸಿ ಮತ್ತು ಅವರು GA ಗಾಗಿ ಏನು ಮಾಡಿದರು ಮತ್ತು ಸಾರ್ವಜನಿಕ ಪೂರ್ವವೀಕ್ಷಣೆಯೊಂದಿಗೆ ಎಲ್ಲವೂ ಹೇಗೆ ಬದಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಹೌದು, AWS, ಚೆನ್ನಾಗಿ ಮಾಡಲಾಗಿದೆ, ವಿಂಡೋಸ್ ವರ್ಕರ್ ನೋಡ್‌ಗಾಗಿ ಚಿತ್ರಗಳನ್ನು ಆವೃತ್ತಿ 1.14 ಗೆ ನವೀಕರಿಸಲಾಗಿದೆ, ಹಾಗೆಯೇ ಕ್ಲಸ್ಟರ್ ಸ್ವತಃ, EKS ನಲ್ಲಿ ಆವೃತ್ತಿ 1.14, ಈಗ ವಿಂಡೋಸ್ ನೋಡ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಮುನ್ನೋಟದಿಂದ ಯೋಜನೆ ಗಿಥಬ್ ಅವರು ಅದನ್ನು ಮುಚ್ಚಿಹಾಕಿದರು ಮತ್ತು ಈಗ ಅಧಿಕೃತ ದಾಖಲೆಗಳನ್ನು ಇಲ್ಲಿ ಬಳಸಿ ಎಂದು ಹೇಳಿದರು: EKS ವಿಂಡೋಸ್ ಬೆಂಬಲ

ಪ್ರಸ್ತುತ VPC ಮತ್ತು ಸಬ್‌ನೆಟ್‌ಗಳಿಗೆ EKS ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಯೋಜಿಸುವುದು

ಎಲ್ಲಾ ಮೂಲಗಳಲ್ಲಿ, ಪ್ರಕಟಣೆಯ ಮೇಲಿನ ಲಿಂಕ್‌ನಲ್ಲಿ ಮತ್ತು ದಾಖಲಾತಿಯಲ್ಲಿ, ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ವಾಮ್ಯದ eksctl ಯುಟಿಲಿಟಿ ಮೂಲಕ ಅಥವಾ ಕ್ಲೌಡ್ ಫಾರ್ಮೇಷನ್ + kubectl ಮೂಲಕ ನಿಯೋಜಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ, ಅಮೆಜಾನ್‌ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿ, ಹಾಗೆಯೇ ರಚಿಸುವುದು ಹೊಸ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಪ್ರತ್ಯೇಕ VPC.

ಈ ಆಯ್ಕೆಯು ಅನೇಕರಿಗೆ ಸೂಕ್ತವಲ್ಲ; ಮೊದಲನೆಯದಾಗಿ, ಪ್ರತ್ಯೇಕ VPC ಎಂದರೆ ಅದರ ವೆಚ್ಚಕ್ಕೆ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚಗಳು + ನಿಮ್ಮ ಪ್ರಸ್ತುತ VPC ಗೆ ಪೀರಿಂಗ್ ಟ್ರಾಫಿಕ್. ತಮ್ಮದೇ ಆದ ಬಹು AWS ಖಾತೆಗಳು, VPC, ಸಬ್‌ನೆಟ್‌ಗಳು, ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು, ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಮತ್ತು ಮುಂತಾದವುಗಳೊಂದಿಗೆ AWS ನಲ್ಲಿ ಈಗಾಗಲೇ ಸಿದ್ದವಾಗಿರುವ ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೊಂದಿರುವವರು ಏನು ಮಾಡಬೇಕು? ಸಹಜವಾಗಿ, ನೀವು ಎಲ್ಲವನ್ನೂ ಮುರಿಯಲು ಅಥವಾ ಪುನಃ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ, ಮತ್ತು ನೀವು ಪ್ರಸ್ತುತ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಹೊಸ EKS ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ VPC ಅನ್ನು ಬಳಸಿ ಮತ್ತು ಪ್ರತ್ಯೇಕಿಸಲು, ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಹೊಸ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ರಚಿಸಬೇಕು.

ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ, ನಾನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ VPC ಅನ್ನು ಬಳಸಿದ್ದೇನೆ, ಹೊಸ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಕೇವಲ 2 ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ಗಳು ಮತ್ತು 2 ಖಾಸಗಿ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇನೆ, ಸಹಜವಾಗಿ, ಎಲ್ಲಾ ನಿಯಮಗಳನ್ನು ದಸ್ತಾವೇಜನ್ನು ಪ್ರಕಾರ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ನಿಮ್ಮ Amazon EKS ಕ್ಲಸ್ಟರ್ VPC ಅನ್ನು ರಚಿಸಿ.

ಒಂದು ಷರತ್ತು ಕೂಡ ಇತ್ತು: EIP ಅನ್ನು ಬಳಸುವ ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ಗಳಲ್ಲಿ ಯಾವುದೇ ವರ್ಕರ್ ನೋಡ್‌ಗಳಿಲ್ಲ.

eksctl vs ಕ್ಲೌಡ್ ಫಾರ್ಮೇಶನ್

ನಾನು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಎರಡೂ ವಿಧಾನಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದೆ ಎಂದು ನಾನು ಈಗಿನಿಂದಲೇ ಕಾಯ್ದಿರಿಸುತ್ತೇನೆ, ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಚಿತ್ರವು ಒಂದೇ ಆಗಿರುತ್ತದೆ.

ಇಲ್ಲಿ ಕೋಡ್ ಚಿಕ್ಕದಾಗಿರುವುದರಿಂದ ನಾನು eksctl ಅನ್ನು ಮಾತ್ರ ಬಳಸಿಕೊಂಡು ಉದಾಹರಣೆಯನ್ನು ತೋರಿಸುತ್ತೇನೆ. eksctl ಅನ್ನು ಬಳಸಿ, ಕ್ಲಸ್ಟರ್ ಅನ್ನು 3 ಹಂತಗಳಲ್ಲಿ ನಿಯೋಜಿಸಿ:

1. ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ + ಲಿನಕ್ಸ್ ವರ್ಕರ್ ನೋಡ್, ಇದು ನಂತರ ಸಿಸ್ಟಮ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದೇ ದುರದೃಷ್ಟಕರ vpc-ನಿಯಂತ್ರಕವನ್ನು ಮಾಡುತ್ತದೆ.

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 ಗೆ ನಿಯೋಜಿಸಲು, ನಿಮ್ಮ ಸಬ್‌ನೆಟ್‌ಗಳ ಐಡಿಯನ್ನು ಸೂಚಿಸಿ, ಮತ್ತು eksctl VPC ಅನ್ನು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತದೆ.

ನಿಮ್ಮ ವರ್ಕರ್ ನೋಡ್‌ಗಳನ್ನು ಖಾಸಗಿ ಸಬ್‌ನೆಟ್‌ಗೆ ಮಾತ್ರ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನೀವು ನೋಡ್‌ಗ್ರೂಪ್‌ಗಾಗಿ --node-private-networking ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿದೆ.

2. ನಾವು ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ vpc-ನಿಯಂತ್ರಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ, ಅದು ನಂತರ ನಮ್ಮ ವರ್ಕರ್ ನೋಡ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಉಚಿತ IP ವಿಳಾಸಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸುತ್ತದೆ, ಹಾಗೆಯೇ ENI ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸುತ್ತದೆ, ಅವುಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ತೆಗೆದುಹಾಕುತ್ತದೆ.

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

3. vpc-ಕಂಟ್ರೋಲರ್ ಸೇರಿದಂತೆ ನಿಮ್ಮ ಲಿನಕ್ಸ್ ವರ್ಕರ್ ನೋಡ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಸಿಸ್ಟಂ ಕಂಟೈನರ್‌ಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ವಿಂಡೋಸ್ ವರ್ಕರ್‌ಗಳೊಂದಿಗೆ ಮತ್ತೊಂದು ನೋಡ್‌ಗ್ರೂಪ್ ಅನ್ನು ರಚಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ.

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-ನಿಯಂತ್ರಕದಲ್ಲಿ ದೋಷ

ನಾವು ವಿಂಡೋಸ್ ವರ್ಕರ್ ನೋಡ್‌ನಲ್ಲಿ ಪಾಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ನಾವು ದೋಷವನ್ನು ಪಡೆಯುತ್ತೇವೆ:

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 ನಲ್ಲಿನ ನಮ್ಮ ನಿದರ್ಶನವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ:

ಮತ್ತು ಅದು ಹೀಗಿರಬೇಕು:

ವಿಪಿಸಿ-ನಿಯಂತ್ರಕವು ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಅದರ ಭಾಗವನ್ನು ಪೂರೈಸಲಿಲ್ಲ ಮತ್ತು ಹೊಸ IP ವಿಳಾಸಗಳನ್ನು ನಿದರ್ಶನಕ್ಕೆ ಸೇರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಎಂಬುದು ಇದರಿಂದ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಇದರಿಂದ ಪಾಡ್‌ಗಳು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು.

ವಿಪಿಸಿ-ನಿಯಂತ್ರಕ ಪಾಡ್‌ನ ಲಾಗ್‌ಗಳನ್ನು ನೋಡೋಣ ಮತ್ತು ಇದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ:

kubectl ಲಾಗ್ -ಎನ್ ಕುಬೆ-ಸಿಸ್ಟಮ್

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.

ಗೂಗಲ್‌ನಲ್ಲಿನ ಹುಡುಕಾಟಗಳು ಯಾವುದಕ್ಕೂ ಕಾರಣವಾಗಲಿಲ್ಲ, ಸ್ಪಷ್ಟವಾಗಿ ಯಾರೂ ಅಂತಹ ದೋಷವನ್ನು ಇನ್ನೂ ಹಿಡಿದಿಲ್ಲ, ಅಥವಾ ಅದರಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಪೋಸ್ಟ್ ಮಾಡಿಲ್ಲ, ನಾನು ಮೊದಲು ಆಯ್ಕೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕಾಗಿತ್ತು. ಮನಸ್ಸಿಗೆ ಬಂದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಬಹುಶಃ vpc-ನಿಯಂತ್ರಕವು ip-10-xxx.ap-xxx.compute.internal ಅನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ದೋಷಗಳು ಸಂಭವಿಸುತ್ತವೆ.

ಹೌದು, ವಾಸ್ತವವಾಗಿ, ನಾವು VPC ಯಲ್ಲಿ ಕಸ್ಟಮ್ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ತಾತ್ವಿಕವಾಗಿ, ನಾವು Amazon ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ap-xxx.compute.internal ಡೊಮೇನ್‌ಗಾಗಿ ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ಸಹ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿಲ್ಲ. ನಾನು ಈ ಆಯ್ಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿದೆ, ಮತ್ತು ಅದು ಫಲಿತಾಂಶಗಳನ್ನು ತರಲಿಲ್ಲ, ಬಹುಶಃ ಪರೀಕ್ಷೆಯು ಸ್ವಚ್ಛವಾಗಿಲ್ಲ, ಮತ್ತು ಆದ್ದರಿಂದ, ಮತ್ತಷ್ಟು, ತಾಂತ್ರಿಕ ಬೆಂಬಲದೊಂದಿಗೆ ಸಂವಹನ ಮಾಡುವಾಗ, ನಾನು ಅವರ ಕಲ್ಪನೆಗೆ ಶರಣಾಗಿದ್ದೇನೆ.

ನಿಜವಾಗಿಯೂ ಯಾವುದೇ ಆಲೋಚನೆಗಳಿಲ್ಲದ ಕಾರಣ, ಎಲ್ಲಾ ಭದ್ರತಾ ಗುಂಪುಗಳನ್ನು eksctl ಮೂಲಕ ರಚಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅವರ ಸೇವೆಯ ಬಗ್ಗೆ ಯಾವುದೇ ಸಂದೇಹವಿಲ್ಲ, ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು ಸಹ ಸರಿಯಾಗಿವೆ, nat, dns, ವರ್ಕರ್ ನೋಡ್‌ಗಳೊಂದಿಗೆ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವೂ ಇತ್ತು.

ಇದಲ್ಲದೆ, ನೀವು —ನೋಡ್-ಪ್ರೈವೇಟ್-ನೆಟ್‌ವರ್ಕಿಂಗ್ ಅನ್ನು ಬಳಸದೆಯೇ ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ಗೆ ವರ್ಕರ್ ನೋಡ್ ಅನ್ನು ನಿಯೋಜಿಸಿದರೆ, ಈ ನೋಡ್ ಅನ್ನು ತಕ್ಷಣವೇ vpc-ನಿಯಂತ್ರಕದಿಂದ ನವೀಕರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲವೂ ಗಡಿಯಾರದ ಕೆಲಸದಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಎರಡು ಆಯ್ಕೆಗಳಿದ್ದವು:

1. ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಿ ಮತ್ತು ಯಾರಾದರೂ AWS ನಲ್ಲಿ ಈ ದೋಷವನ್ನು ವಿವರಿಸುವವರೆಗೆ ನಿರೀಕ್ಷಿಸಿ ಮತ್ತು ಅವರು ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತಾರೆ, ಮತ್ತು ನಂತರ ನೀವು ಸುರಕ್ಷಿತವಾಗಿ AWS EKS ವಿಂಡೋಸ್ ಅನ್ನು ಬಳಸಬಹುದು, ಏಕೆಂದರೆ ಅವರು GA ಯಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಿದ್ದಾರೆ (ಈ ಲೇಖನವನ್ನು ಬರೆಯುವ ಸಮಯದಲ್ಲಿ 8 ದಿನಗಳು ಕಳೆದಿವೆ), ಅನೇಕರು ಬಹುಶಃ ನನ್ನಂತೆಯೇ ಅದೇ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿ.
2. AWS ಬೆಂಬಲಕ್ಕೆ ಬರೆಯಿರಿ ಮತ್ತು ಎಲ್ಲೆಡೆಯಿಂದ ಲಾಗ್‌ಗಳ ಸಂಪೂರ್ಣ ಗುಂಪಿನೊಂದಿಗೆ ಸಮಸ್ಯೆಯ ಸಾರವನ್ನು ಅವರಿಗೆ ತಿಳಿಸಿ ಮತ್ತು ನಿಮ್ಮ VPC ಮತ್ತು ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಬಳಸುವಾಗ ಅವರ ಸೇವೆಯು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂದು ಅವರಿಗೆ ಸಾಬೀತುಪಡಿಸಿ, ನಾವು ವ್ಯಾಪಾರದ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದ್ದು ಯಾವುದಕ್ಕೂ ಅಲ್ಲ, ನೀವು ಬಳಸಬೇಕು ಒಮ್ಮೆಯಾದರೂ :)

AWS ಎಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ

ಪೋರ್ಟಲ್‌ನಲ್ಲಿ ಟಿಕೆಟ್ ರಚಿಸಿದ ನಂತರ, ನಾನು ತಪ್ಪಾಗಿ ವೆಬ್ - ಇಮೇಲ್ ಅಥವಾ ಬೆಂಬಲ ಕೇಂದ್ರದ ಮೂಲಕ ನನಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದೆ, ಈ ಆಯ್ಕೆಯ ಮೂಲಕ ಅವರು ಕೆಲವು ದಿನಗಳ ನಂತರ ನಿಮಗೆ ಉತ್ತರಿಸಬಹುದು, ನನ್ನ ಟಿಕೆಟ್‌ನ ತೀವ್ರತೆ - ಸಿಸ್ಟಮ್ ದುರ್ಬಲಗೊಂಡಿದ್ದರೂ ಸಹ, <12 ಗಂಟೆಗಳ ಒಳಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅರ್ಥೈಸಲಾಗಿದೆ, ಮತ್ತು ವ್ಯಾಪಾರ ಬೆಂಬಲ ಯೋಜನೆಯು 24/7 ಬೆಂಬಲವನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ನಾನು ಉತ್ತಮವಾದದ್ದನ್ನು ಆಶಿಸಿದ್ದೇನೆ, ಆದರೆ ಅದು ಯಾವಾಗಲೂ ಹಾಗೆ ಆಯಿತು.

ನನ್ನ ಟಿಕೆಟ್ ಅನ್ನು ಶುಕ್ರವಾರದಿಂದ ಸೋಮವಾರದವರೆಗೆ ನಿಯೋಜಿಸಲಾಗಿಲ್ಲ, ನಂತರ ನಾನು ಅವರಿಗೆ ಮತ್ತೊಮ್ಮೆ ಬರೆಯಲು ನಿರ್ಧರಿಸಿದೆ ಮತ್ತು ಚಾಟ್ ಪ್ರತಿಕ್ರಿಯೆ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದೆ. ಸ್ವಲ್ಪ ಸಮಯ ಕಾದ ನಂತರ ಹರ್ಷದ್ ಮಾಧವ್ ನನ್ನನ್ನು ನೋಡಲು ನೇಮಿಸಲಾಯಿತು, ಮತ್ತು ನಂತರ ಅದು ಪ್ರಾರಂಭವಾಯಿತು ...

ನಾವು ಅದರೊಂದಿಗೆ ಸತತವಾಗಿ 3 ಗಂಟೆಗಳ ಕಾಲ ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ಡೀಬಗ್ ಮಾಡಿದ್ದೇವೆ, ಲಾಗ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸುತ್ತೇವೆ, ಸಮಸ್ಯೆಯನ್ನು ಅನುಕರಿಸಲು AWS ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಅದೇ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, ನನ್ನ ಕಡೆಯಿಂದ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದು ಮತ್ತು ಹೀಗೆ, ನಾವು ಬಂದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ಅದು ಲಾಗ್‌ಗಳಲ್ಲಿ ನಾನು ಮೇಲೆ ಬರೆದಿರುವ AWS ಆಂತರಿಕ ಡೊಮೇನ್ ಹೆಸರುಗಳು ರೆಸೊಲ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಹರ್ಷದ್ ಮಾಧವ್ ಅವರು ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ರಚಿಸಲು ನನ್ನನ್ನು ಕೇಳಿದರು, ನಾವು ಕಸ್ಟಮ್ DNS ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಇದು ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು.

ಫಾರ್ವರ್ಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ

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

ಅದನ್ನೇ ಮಾಡಲಾಗಿತ್ತು, ದಿನವು ಮುಗಿದಿದೆ, ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ಹರ್ಷದ್ ಮಾಧವ್ ಮತ್ತೆ ಬರೆದರು ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡಬೇಕು, ಆದರೆ ಇಲ್ಲ, ನಿರ್ಣಯವು ಸಹಾಯ ಮಾಡಲಿಲ್ಲ.

ನಂತರ ಇನ್ನೂ 2 ಇಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನವಿತ್ತು, ಒಬ್ಬರು ಸರಳವಾಗಿ ಚಾಟ್‌ನಿಂದ ಹೊರಬಂದರು, ಸ್ಪಷ್ಟವಾಗಿ ಅವರು ಸಂಕೀರ್ಣ ಪ್ರಕರಣಕ್ಕೆ ಹೆದರುತ್ತಿದ್ದರು, ಎರಡನೆಯವರು ಮತ್ತೆ ನನ್ನ ದಿನವನ್ನು ಡೀಬಗ್ ಮಾಡುವ, ಲಾಗ್‌ಗಳನ್ನು ಕಳುಹಿಸುವ, ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ರಚಿಸುವ ಪೂರ್ಣ ಚಕ್ರದಲ್ಲಿ ಕಳೆದರು. ಕೊನೆಯಲ್ಲಿ ಅವರು ಚೆನ್ನಾಗಿ ಹೇಳಿದರು, ಇದು ನನಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇಲ್ಲಿ ನಾನು ಅಧಿಕೃತ ದಾಖಲೆಯಲ್ಲಿ ಹಂತ ಹಂತವಾಗಿ ಎಲ್ಲವನ್ನೂ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ನೀವು ಮತ್ತು ನೀವು ಯಶಸ್ವಿಯಾಗುತ್ತೀರಿ.

ಅದಕ್ಕೆ ನಾನು ಅವನನ್ನು ಬಿಟ್ಟು ಬೇರೆಯವರನ್ನು ನನ್ನ ಟಿಕೆಟ್‌ಗೆ ನಿಯೋಜಿಸಿ ಎಂದು ವಿನಯದಿಂದ ಕೇಳಿದೆ, ನಿಮಗೆ ಸಮಸ್ಯೆ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ.

ಅಂತಿಮ

ಮೂರನೇ ದಿನ, ನನಗೆ ಹೊಸ ಇಂಜಿನಿಯರ್ ಅರುಣ್ ಬಿ. ಅವರನ್ನು ನಿಯೋಜಿಸಲಾಯಿತು, ಮತ್ತು ಅವರೊಂದಿಗೆ ಸಂವಹನದ ಪ್ರಾರಂಭದಿಂದಲೂ ಇದು ಹಿಂದಿನ 3 ಎಂಜಿನಿಯರ್‌ಗಳಲ್ಲ ಎಂದು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟವಾಯಿತು. ಅವರು ಸಂಪೂರ್ಣ ಇತಿಹಾಸವನ್ನು ಓದಿದರು ಮತ್ತು ತಕ್ಷಣವೇ ಅವರ ಗಿಥಬ್‌ನಲ್ಲಿರುವ ps1 ನಲ್ಲಿ ತಮ್ಮದೇ ಆದ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಕೇಳಿದರು. ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ರಚಿಸುವುದು, ಕಮಾಂಡ್ ಫಲಿತಾಂಶಗಳನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡುವುದು, ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಮುಂತಾದ ಎಲ್ಲಾ ಪುನರಾವರ್ತನೆಗಳಿಂದ ಇದನ್ನು ಮತ್ತೆ ಅನುಸರಿಸಲಾಯಿತು, ಆದರೆ ಅರುಣ್ ಬಿ. ನನಗೆ ಕೇಳಿದ ಪ್ರಶ್ನೆಗಳಿಂದ ನಿರ್ಣಯಿಸುತ್ತಾ ಸರಿಯಾದ ದಿಕ್ಕಿನಲ್ಲಿ ಚಲಿಸುತ್ತಿದ್ದರು.

ಅವರ vpc-ನಿಯಂತ್ರಕದಲ್ಲಿ -stderrthreshold=debug ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಹಂತಕ್ಕೆ ನಾವು ಯಾವಾಗ ಬಂದೆವು ಮತ್ತು ಮುಂದೆ ಏನಾಯಿತು? ಸಹಜವಾಗಿ ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ) ಈ ಆಯ್ಕೆಯೊಂದಿಗೆ ಪಾಡ್ ಸರಳವಾಗಿ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ, -stderrthreshold=info ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ನಾವು ಇಲ್ಲಿ ಮುಗಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದೇ ದೋಷವನ್ನು ಪಡೆಯಲು ನನ್ನ ಹೆಜ್ಜೆಗಳನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ ಎಂದು ಅರುಣ್ ಬಿ. ಮರುದಿನ ನಾನು ಅರುಣ್ ಬಿ ಅವರಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇನೆ. ಅವರು ಈ ಪ್ರಕರಣವನ್ನು ತ್ಯಜಿಸಲಿಲ್ಲ, ಆದರೆ ಅವರ vpc-ನಿಯಂತ್ರಕದ ವಿಮರ್ಶೆ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರು ಮತ್ತು ಅದು ಇರುವ ಸ್ಥಳವನ್ನು ಮತ್ತು ಅದು ಏಕೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಕಂಡುಕೊಂಡರು:

ಹೀಗಾಗಿ, ನಿಮ್ಮ VPC ಯಲ್ಲಿ ನೀವು ಮುಖ್ಯ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಬಳಸಿದರೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದು ಅಗತ್ಯ ಸಬ್‌ನೆಟ್‌ಗಳೊಂದಿಗೆ ಸಂಬಂಧಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಇದು vpc- ನಿಯಂತ್ರಕಕ್ಕೆ ತುಂಬಾ ಅವಶ್ಯಕವಾಗಿದೆ, ಸಾರ್ವಜನಿಕ ಸಬ್‌ನೆಟ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಕಸ್ಟಮ್ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಹೊಂದಿರುತ್ತದೆ ಅದು ಸಂಘವನ್ನು ಹೊಂದಿದೆ.

ಅಗತ್ಯ ಸಬ್‌ನೆಟ್‌ಗಳೊಂದಿಗೆ ಮುಖ್ಯ ಮಾರ್ಗ ಕೋಷ್ಟಕಕ್ಕೆ ಸಂಘಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಸೇರಿಸುವ ಮೂಲಕ ಮತ್ತು ನೋಡ್‌ಗ್ರೂಪ್ ಅನ್ನು ಮರು-ರಚಿಸುವ ಮೂಲಕ, ಎಲ್ಲವೂ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಅರುಣ್ ಬಿ. ನಿಜವಾಗಿಯೂ ಈ ದೋಷವನ್ನು EKS ಡೆವಲಪರ್‌ಗಳಿಗೆ ವರದಿ ಮಾಡುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ ಮತ್ತು ನಾವು vpc-ನಿಯಂತ್ರಕದ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನೋಡುತ್ತೇವೆ, ಅಲ್ಲಿ ಎಲ್ಲವೂ ಬಾಕ್ಸ್‌ನಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಪ್ರಸ್ತುತ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯು: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ.

ಕೊನೆಯವರೆಗೂ ಓದಿದ ಎಲ್ಲರಿಗೂ ಧನ್ಯವಾದಗಳು, ಅನುಷ್ಠಾನಕ್ಕೆ ಮೊದಲು ನೀವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಳಸಲಿರುವ ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷಿಸಿ.

ಮೂಲ: www.habr.com