GA ਵਿੱਚ ਐਮਾਜ਼ਾਨ EKS ਵਿੰਡੋਜ਼ ਵਿੱਚ ਬੱਗ ਹਨ, ਪਰ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੈ

ਸ਼ੁਭ ਦੁਪਿਹਰ, ਮੈਂ ਤੁਹਾਡੇ ਨਾਲ ਵਿੰਡੋਜ਼ ਕੰਟੇਨਰਾਂ ਲਈ AWS EKS (ਇਲਾਸਟਿਕ ਕੁਬਰਨੇਟਸ ਸਰਵਿਸ) ਸੇਵਾ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਵਰਤਣ ਵਿੱਚ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਜਾਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਅਸੰਭਵਤਾ ਬਾਰੇ, ਅਤੇ ਉਹਨਾਂ ਲਈ AWS ਸਿਸਟਮ ਕੰਟੇਨਰ ਵਿੱਚ ਪਾਏ ਗਏ ਬੱਗ ਬਾਰੇ। ਜੋ ਵਿੰਡੋਜ਼ ਕੰਟੇਨਰਾਂ ਲਈ ਇਸ ਸੇਵਾ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ, ਕਿਰਪਾ ਕਰਕੇ ਬਿੱਲੀ ਦੇ ਹੇਠਾਂ।

ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਵਿੰਡੋਜ਼ ਕੰਟੇਨਰ ਇੱਕ ਪ੍ਰਸਿੱਧ ਵਿਸ਼ਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਬਹੁਤ ਘੱਟ ਲੋਕ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਮੈਂ ਫਿਰ ਵੀ ਇਹ ਲੇਖ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਕਿਉਂਕਿ ਕੁਬਰਨੇਟਸ ਅਤੇ ਵਿੰਡੋਜ਼ ਉੱਤੇ ਹੈਬਰੇ ਉੱਤੇ ਕੁਝ ਲੇਖ ਸਨ ਅਤੇ ਅਜੇ ਵੀ ਅਜਿਹੇ ਲੋਕ ਹਨ।

Начало

ਇਹ ਸਭ ਉਦੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਜਦੋਂ ਸਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਸੇਵਾਵਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਕਿ 70% ਵਿੰਡੋਜ਼ ਅਤੇ 30% ਲੀਨਕਸ ਹੈ। ਇਸ ਮੰਤਵ ਲਈ, AWS EKS ਕਲਾਉਡ ਸੇਵਾ ਨੂੰ ਸੰਭਵ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੰਨਿਆ ਗਿਆ ਸੀ। ਅਕਤੂਬਰ 8, 2019 ਤੱਕ, AWS EKS ਵਿੰਡੋਜ਼ ਪਬਲਿਕ ਪੂਰਵਦਰਸ਼ਨ ਵਿੱਚ ਸੀ, ਮੈਂ ਇਸਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ, kubernetes ਦਾ ਪੁਰਾਣਾ 1.11 ਸੰਸਕਰਣ ਉੱਥੇ ਵਰਤਿਆ ਗਿਆ ਸੀ, ਪਰ ਮੈਂ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਇਹ ਦੇਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਇਹ ਕਲਾਉਡ ਸੇਵਾ ਕਿਸ ਪੜਾਅ 'ਤੇ ਸੀ, ਕੀ ਇਹ ਕੰਮ ਕਰ ਰਹੀ ਸੀ। ਬਿਲਕੁਲ, ਜਿਵੇਂ ਕਿ ਇਹ ਸਾਹਮਣੇ ਆਇਆ, ਨਹੀਂ, ਇਹ ਪੌਡਾਂ ਨੂੰ ਹਟਾਉਣ ਦੇ ਨਾਲ ਇੱਕ ਬੱਗ ਸੀ, ਜਦੋਂ ਕਿ ਪੁਰਾਣੇ ਲੋਕਾਂ ਨੇ ਵਿੰਡੋਜ਼ ਵਰਕਰ ਨੋਡ ਦੇ ਸਮਾਨ ਸਬਨੈੱਟ ਤੋਂ ਅੰਦਰੂਨੀ ਆਈਪੀ ਦੁਆਰਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਸੀ।

ਇਸ ਲਈ, ਉਸੇ EC2 'ਤੇ kubernetes 'ਤੇ ਸਾਡੇ ਆਪਣੇ ਕਲੱਸਟਰ ਦੇ ਹੱਕ ਵਿੱਚ AWS EKS ਦੀ ਵਰਤੋਂ ਨੂੰ ਛੱਡਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਿਰਫ਼ ਸਾਨੂੰ ਕਲਾਉਡਫੋਰਮੇਸ਼ਨ ਦੁਆਰਾ ਸਾਰੇ ਸੰਤੁਲਨ ਅਤੇ HA ਦਾ ਵਰਣਨ ਕਰਨਾ ਹੋਵੇਗਾ।

ਐਮਾਜ਼ਾਨ EKS ਵਿੰਡੋਜ਼ ਕੰਟੇਨਰ ਸਪੋਰਟ ਹੁਣ ਆਮ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੈ

ਮਾਰਟਿਨ ਬੀਬੀ ਦੁਆਰਾ | 08 ਅਕਤੂਬਰ 2019 ਨੂੰ

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਮੇਰੇ ਕੋਲ ਮੇਰੇ ਆਪਣੇ ਕਲੱਸਟਰ ਲਈ CloudFormation ਵਿੱਚ ਇੱਕ ਟੈਂਪਲੇਟ ਜੋੜਨ ਦਾ ਸਮਾਂ ਸੀ, ਮੈਂ ਇਹ ਖਬਰ ਦੇਖੀ ਐਮਾਜ਼ਾਨ EKS ਵਿੰਡੋਜ਼ ਕੰਟੇਨਰ ਸਪੋਰਟ ਹੁਣ ਆਮ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੈ

ਬੇਸ਼ੱਕ, ਮੈਂ ਆਪਣੇ ਸਾਰੇ ਕੰਮ ਨੂੰ ਪਾਸੇ ਰੱਖ ਦਿੱਤਾ ਅਤੇ ਅਧਿਐਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਕਿ ਉਨ੍ਹਾਂ ਨੇ GA ਲਈ ਕੀ ਕੀਤਾ, ਅਤੇ ਪਬਲਿਕ ਪ੍ਰੀਵਿਊ ਨਾਲ ਸਭ ਕੁਝ ਕਿਵੇਂ ਬਦਲਿਆ। ਹਾਂ, AWS, ਬਹੁਤ ਵਧੀਆ, ਵਿੰਡੋਜ਼ ਵਰਕਰ ਨੋਡ ਲਈ ਚਿੱਤਰਾਂ ਨੂੰ ਵਰਜਨ 1.14 ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤਾ ਹੈ, ਨਾਲ ਹੀ ਕਲੱਸਟਰ ਖੁਦ, EKS ਵਿੱਚ ਸੰਸਕਰਣ 1.14, ਹੁਣ ਵਿੰਡੋਜ਼ ਨੋਡਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। 'ਤੇ ਪਬਲਿਕ ਪੂਰਵਦਰਸ਼ਨ ਦੁਆਰਾ ਪ੍ਰੋਜੈਕਟ github ਉਨ੍ਹਾਂ ਨੇ ਇਸ ਨੂੰ ਕਵਰ ਕੀਤਾ ਅਤੇ ਕਿਹਾ ਕਿ ਹੁਣ ਇੱਥੇ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ: EKS ਵਿੰਡੋਜ਼ ਸਪੋਰਟ

ਮੌਜੂਦਾ VPC ਅਤੇ ਸਬਨੈੱਟ ਵਿੱਚ ਇੱਕ EKS ਕਲੱਸਟਰ ਨੂੰ ਜੋੜਨਾ

ਸਾਰੇ ਸਰੋਤਾਂ ਵਿੱਚ, ਘੋਸ਼ਣਾ ਦੇ ਉੱਪਰ ਦਿੱਤੇ ਲਿੰਕ ਦੇ ਨਾਲ-ਨਾਲ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ, ਕਲੱਸਟਰ ਨੂੰ ਜਾਂ ਤਾਂ ਮਲਕੀਅਤ eksctl ਉਪਯੋਗਤਾ ਦੁਆਰਾ ਜਾਂ CloudFormation + kubectl ਦੁਆਰਾ ਤੈਨਾਤ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਿਰਫ ਐਮਾਜ਼ਾਨ ਵਿੱਚ ਜਨਤਕ ਸਬਨੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਨਾਲ, ਨਾਲ ਹੀ ਇੱਕ ਬਣਾਉਣ ਲਈ ਇੱਕ ਨਵੇਂ ਕਲੱਸਟਰ ਲਈ ਵੱਖਰਾ VPC।

ਇਹ ਵਿਕਲਪ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ; ਪਹਿਲਾਂ, ਇੱਕ ਵੱਖਰੀ VPC ਦਾ ਮਤਲਬ ਹੈ ਇਸਦੀ ਲਾਗਤ + ਤੁਹਾਡੇ ਮੌਜੂਦਾ VPC ਲਈ ਪੀਅਰਿੰਗ ਟ੍ਰੈਫਿਕ ਲਈ ਵਾਧੂ ਲਾਗਤਾਂ। ਉਹਨਾਂ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ AWS ਵਿੱਚ ਆਪਣੇ ਮਲਟੀਪਲ AWS ਖਾਤਿਆਂ, VPC, ਸਬਨੈੱਟ, ਰੂਟ ਟੇਬਲ, ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਅਤੇ ਹੋਰਾਂ ਨਾਲ ਤਿਆਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹੈ? ਬੇਸ਼ੱਕ, ਤੁਸੀਂ ਇਸ ਸਭ ਨੂੰ ਤੋੜਨਾ ਜਾਂ ਦੁਬਾਰਾ ਕਰਨਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ VPC ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਨਵੇਂ EKS ਕਲੱਸਟਰ ਨੂੰ ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ, ਵੱਖ ਕਰਨ ਲਈ, ਵੱਧ ਤੋਂ ਵੱਧ ਕਲੱਸਟਰ ਲਈ ਨਵੇਂ ਸਬਨੈੱਟ ਬਣਾਓ।

ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਇਹ ਮਾਰਗ ਚੁਣਿਆ ਗਿਆ ਸੀ, ਮੈਂ ਮੌਜੂਦਾ VPC ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਨਵੇਂ ਕਲੱਸਟਰ ਲਈ ਸਿਰਫ 2 ਜਨਤਕ ਸਬਨੈੱਟ ਅਤੇ 2 ਪ੍ਰਾਈਵੇਟ ਸਬਨੈੱਟ ਸ਼ਾਮਲ ਕੀਤੇ, ਬੇਸ਼ਕ, ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅਨੁਸਾਰ ਸਾਰੇ ਨਿਯਮਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ ਆਪਣਾ Amazon EKS ਕਲੱਸਟਰ VPC ਬਣਾਓ.

ਇੱਥੇ ਇੱਕ ਸ਼ਰਤ ਵੀ ਸੀ: EIP ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਜਨਤਕ ਸਬਨੈੱਟ ਵਿੱਚ ਕੋਈ ਵਰਕਰ ਨੋਡ ਨਹੀਂ ਹੈ।

eksctl ਬਨਾਮ CloudFormation

ਮੈਂ ਤੁਰੰਤ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰਾਂਗਾ ਕਿ ਮੈਂ ਇੱਕ ਕਲੱਸਟਰ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੇ ਦੋਵੇਂ ਤਰੀਕਿਆਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਤਸਵੀਰ ਇੱਕੋ ਜਿਹੀ ਸੀ।

ਮੈਂ ਸਿਰਫ 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 ਪਤਿਆਂ ਦੀ ਗਿਣਤੀ ਦੇ ਨਾਲ-ਨਾਲ ENIs ਦੀ ਸੰਖਿਆ, ਉਹਨਾਂ ਨੂੰ ਜੋੜਨਾ ਅਤੇ ਹਟਾਉਣਾ।

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 ਵਿੱਚ ਸਾਡੀ ਉਦਾਹਰਣ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

ਅਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

ਇਸ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ ਕਿ vpc-ਕੰਟਰੋਲਰ ਨੇ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਆਪਣਾ ਹਿੱਸਾ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਅਤੇ ਉਦਾਹਰਣ ਵਿੱਚ ਨਵੇਂ IP ਐਡਰੈੱਸ ਨਹੀਂ ਜੋੜ ਸਕਿਆ ਤਾਂ ਜੋ ਪੌਡਜ਼ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਣ।

ਆਉ vpc-ਕੰਟਰੋਲਰ ਪੌਡ ਦੇ ਲੌਗਸ ਨੂੰ ਵੇਖੀਏ ਅਤੇ ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ:

kubectl ਲਾਗ -n ਕੁਬੇ-ਸਿਸਟਮ

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, ਵਰਕਰ ਨੋਡਾਂ ਦੇ ਨਾਲ ਇੰਟਰਨੈਟ ਪਹੁੰਚ ਵੀ ਸੀ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਤੁਸੀਂ —node-private-networking ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਵਰਕਰ ਨੋਡ ਨੂੰ ਇੱਕ ਜਨਤਕ ਸਬਨੈੱਟ ਵਿੱਚ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਨੋਡ ਤੁਰੰਤ 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