Amazon EKS Windows ໃນ GA ມີແມງໄມ້, ແຕ່ໄວທີ່ສຸດ

ສະບາຍດີຕອນບ່າຍ, ຂ້ອຍຢາກແບ່ງປັນປະສົບການຂອງຂ້ອຍໃນການຕັ້ງຄ່າແລະໃຊ້ບໍລິການ AWS EKS (Elastic Kubernetes Service) ສໍາລັບ Windows containers, ຫຼືແທນທີ່ຈະເປັນໄປບໍ່ໄດ້ໃນການນໍາໃຊ້ມັນ, ແລະຂໍ້ບົກພ່ອງທີ່ພົບເຫັນຢູ່ໃນຖັງລະບົບ AWS, ສໍາລັບຜູ້ທີ່ ຜູ້ທີ່ມີຄວາມສົນໃຈໃນການບໍລິການນີ້ສໍາລັບເຄື່ອງບັນຈຸ Windows, ກະລຸນາພາຍໃຕ້ cat.

ຂ້ອຍຮູ້ວ່າ Windows containers ບໍ່ແມ່ນຫົວຂໍ້ທີ່ນິຍົມ, ແລະມີຄົນຈໍານວນຫນ້ອຍໃຊ້ມັນ, ແຕ່ຂ້ອຍກໍ່ຍັງຕັດສິນໃຈຂຽນບົດຄວາມນີ້, ນັບຕັ້ງແຕ່ມີສອງບົດຄວາມກ່ຽວກັບ Habré ກ່ຽວກັບ kubernetes ແລະ Windows ແລະຍັງມີຄົນດັ່ງກ່າວ.

Начало

ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນໃນເວລາທີ່ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະຍ້າຍການບໍລິການໃນບໍລິສັດຂອງພວກເຮົາໄປ kubernetes, ເຊິ່ງແມ່ນ 70% Windows ແລະ 30% Linux. ສໍາລັບຈຸດປະສົງນີ້, ການບໍລິການຟັງ AWS EKS ໄດ້ຖືກພິຈາລະນາເປັນຫນຶ່ງໃນທາງເລືອກທີ່ເປັນໄປໄດ້. ຈົນຮອດວັນທີ 8 ຕຸລາ 2019, AWS EKS Windows ຢູ່ໃນ Public Preview, ຂ້ອຍເລີ່ມຕົ້ນດ້ວຍມັນ, kubernetes ເວີຊັ່ນ 1.11 ເກົ່າຖືກໃຊ້ຢູ່ບ່ອນນັ້ນ, ແຕ່ຂ້ອຍຕັດສິນໃຈກວດເບິ່ງມັນແລ້ວເບິ່ງວ່າບໍລິການຄລາວນີ້ຢູ່ໃນຂັ້ນຕອນໃດ, ບໍ່ວ່າຈະເຮັດວຽກຢູ່. ທັງຫມົດ, ຍ້ອນວ່າມັນໄດ້ຫັນອອກ, ບໍ່, ມັນມີຂໍ້ບົກພ່ອງທີ່ມີການເພີ່ມການຖອນ pods, ໃນຂະນະທີ່ຄົນເກົ່າຢຸດເຊົາການຕອບສະຫນອງຜ່ານ ip ພາຍໃນຈາກ subnet ດຽວກັນກັບ node ຂອງ windows worker.

ດັ່ງນັ້ນ, ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະປະຖິ້ມການນໍາໃຊ້ AWS EKS ໃນເງື່ອນໄຂຂອງກຸ່ມຂອງພວກເຮົາເອງໃນ kubernetes ໃນ EC2 ດຽວກັນ, ພຽງແຕ່ພວກເຮົາຈະຕ້ອງອະທິບາຍການດຸ່ນດ່ຽງທັງຫມົດແລະ HA ຕົວເຮົາເອງຜ່ານ CloudFormation.

Amazon EKS Windows Container Support ປະຈຸບັນມີຢູ່ທົ່ວໄປແລ້ວ

ໂດຍ Martin Beeby | ໃນວັນທີ 08 ຕຸລາ 2019

ກ່ອນທີ່ຂ້ອຍຈະມີເວລາທີ່ຈະເພີ່ມແມ່ແບບໃສ່ CloudFormation ສໍາລັບກຸ່ມຂອງຂ້ອຍເອງ, ຂ້ອຍໄດ້ເຫັນຂ່າວນີ້ Amazon EKS Windows Container Support ປະຈຸບັນມີຢູ່ທົ່ວໄປແລ້ວ

ແນ່ນອນ, ຂ້ອຍວາງວຽກທັງຫມົດຂອງຂ້ອຍໄວ້ແລະເລີ່ມສຶກສາສິ່ງທີ່ພວກເຂົາເຮັດສໍາລັບ GA, ແລະວ່າທຸກສິ່ງທຸກຢ່າງມີການປ່ຽນແປງແນວໃດກັບ Public Preview. ແມ່ນແລ້ວ, AWS, ເຮັດໄດ້ດີ, ອັບເດດຮູບພາບສຳລັບ windows worker node ເປັນເວີຊັນ 1.14, ເຊັ່ນດຽວກັນກັບ cluster ຕົວມັນເອງ, ເວີຊັນ 1.14 ໃນ EKS, ຕອນນີ້ຮອງຮັບ windows nodes. ໂຄງການໂດຍສາທາລະນະ Preview ຢູ່ github ພວກເຂົາເຈົ້າໄດ້ກວມເອົາມັນແລະເວົ້າວ່າໃນປັດຈຸບັນນໍາໃຊ້ເອກະສານຢ່າງເປັນທາງການທີ່ນີ້: EKS ສະຫນັບສະຫນູນ Windows

ການລວມກຸ່ມ EKS ເຂົ້າໄປໃນ VPC ແລະເຄືອຂ່າຍຍ່ອຍໃນປະຈຸບັນ

ໃນແຫຼ່ງທັງຫມົດ, ໃນການເຊື່ອມຕໍ່ຂ້າງເທິງກ່ຽວກັບການປະກາດເຊັ່ນດຽວກັນກັບໃນເອກະສານ, ມັນໄດ້ຖືກສະເຫນີໃຫ້ນໍາໃຊ້ກຸ່ມບໍ່ວ່າຈະຜ່ານ eksctl utility ທີ່ເປັນເຈົ້າຂອງຫຼືຜ່ານ CloudFormation + kubectl ຫຼັງຈາກ, ພຽງແຕ່ໃຊ້ subnets ສາທາລະນະໃນ Amazon, ເຊັ່ນດຽວກັນກັບການສ້າງ. VPC ແຍກຕ່າງຫາກສໍາລັບກຸ່ມໃຫມ່.

ທາງເລືອກນີ້ບໍ່ເຫມາະສົມສໍາລັບຫຼາຍໆຄົນ; ທໍາອິດ, VPC ແຍກຕ່າງຫາກຫມາຍຄວາມວ່າຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມສໍາລັບຄ່າໃຊ້ຈ່າຍຂອງມັນ + peering ການຈະລາຈອນກັບ VPC ໃນປັດຈຸບັນຂອງທ່ານ. ຜູ້ທີ່ມີໂຄງສ້າງພື້ນຖານທີ່ກຽມພ້ອມແລ້ວໃນ AWS ທີ່ມີບັນຊີຫຼາຍ AWS ຂອງຕົນເອງ, VPC, ເຄືອຂ່າຍຍ່ອຍ, ຕາຕະລາງເສັ້ນທາງ, ປະຕູທາງຜ່ານແລະອື່ນໆຄວນເຮັດແນວໃດ? ແນ່ນອນ, ທ່ານບໍ່ຕ້ອງການທີ່ຈະທໍາລາຍຫຼືເຮັດໃຫມ່ທັງຫມົດນີ້, ແລະທ່ານຕ້ອງການປະສົມປະສານກຸ່ມ EKS ໃຫມ່ເຂົ້າໃນໂຄງສ້າງເຄືອຂ່າຍໃນປະຈຸບັນ, ໂດຍໃຊ້ VPC ທີ່ມີຢູ່ແລ້ວແລະ, ສໍາລັບການແຍກຕ່າງຫາກ, ສ່ວນຫຼາຍແມ່ນສ້າງ subnets ໃຫມ່ສໍາລັບ cluster.

ໃນກໍລະນີຂອງຂ້ອຍ, ເສັ້ນທາງນີ້ຖືກເລືອກ, ຂ້ອຍໃຊ້ VPC ທີ່ມີຢູ່, ເພີ່ມພຽງແຕ່ 2 subnets ສາທາລະນະແລະ 2 subnets ສ່ວນຕົວສໍາລັບ cluster ໃຫມ່, ແນ່ນອນ, ກົດລະບຽບທັງຫມົດຖືກພິຈາລະນາຕາມເອກະສານ. ສ້າງ Amazon EKS Cluster VPC ຂອງທ່ານ.

ນອກຈາກນີ້ຍັງມີເງື່ອນໄຂຫນຶ່ງ: ບໍ່ມີ nodes ພະນັກງານໃນເຄືອຂ່າຍຍ່ອຍສາທາລະນະທີ່ໃຊ້ EIP.

eksctl ທຽບກັບ CloudFormation

ຂ້ອຍຈະຈອງທັນທີທີ່ຂ້ອຍໄດ້ພະຍາຍາມທັງສອງວິທີການຂອງການນໍາໃຊ້ກຸ່ມ, ໃນທັງສອງກໍລະນີຮູບພາບແມ່ນຄືກັນ.

ຂ້ອຍຈະສະແດງຕົວຢ່າງພຽງແຕ່ໃຊ້ eksctl ນັບຕັ້ງແຕ່ລະຫັດຢູ່ທີ່ນີ້ຈະສັ້ນກວ່າ. ໂດຍໃຊ້ eksctl, ນຳໃຊ້ກຸ່ມໃນ 3 ຂັ້ນຕອນ:

1. ພວກເຮົາສ້າງກຸ່ມຕົວມັນເອງ + Linux worker node, ເຊິ່ງຕໍ່ມາຈະເປັນເຈົ້າພາບລະບົບ containers ແລະ vpc-controller ທີ່ບໍ່ມີໂຊກຊະຕາອັນດຽວກັນນັ້ນ.

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 ຕົວຂອງມັນເອງ.

ເພື່ອໃຫ້ແນ່ໃຈວ່າ nodes ພະນັກງານຂອງທ່ານຖືກນໍາໄປໃຊ້ກັບເຄືອຂ່າຍຍ່ອຍສ່ວນຕົວເທົ່ານັ້ນ, ທ່ານຈໍາເປັນຕ້ອງລະບຸ --node-private-networking ສໍາລັບ nodegroup.

2. ພວກເຮົາຕິດຕັ້ງ vpc-controller ໃນກຸ່ມຂອງພວກເຮົາ, ເຊິ່ງຈະດໍາເນີນການ nodes ພະນັກງານຂອງພວກເຮົາ, ນັບຈໍານວນຂອງທີ່ຢູ່ IP ຟຣີ, ເຊັ່ນດຽວກັນກັບຈໍານວນຂອງ ENIs ໃນຕົວຢ່າງ, ເພີ່ມແລະເອົາອອກ.

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

3. ຫຼັງຈາກກ່ອງບັນຈຸລະບົບຂອງທ່ານໄດ້ເປີດຕົວຢ່າງສໍາເລັດຜົນໃນ node ພະນັກງານ Linux ຂອງທ່ານ, ລວມທັງ vpc-controller, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການສ້າງ nodegroup ອື່ນກັບຜູ້ເຮັດວຽກ 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

ຫຼັງຈາກ node ຂອງທ່ານໄດ້ເຊື່ອມຕໍ່ຢ່າງສໍາເລັດຜົນກັບ cluster ຂອງທ່ານແລະທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າດີ, ມັນຢູ່ໃນສະຖານະກຽມພ້ອມ, ແຕ່ບໍ່ແມ່ນ.

ຜິດພາດໃນ vpc-controller

ຖ້າພວກເຮົາພະຍາຍາມແລ່ນ pods ເທິງ windows worker node, ພວກເຮົາຈະໄດ້ຮັບຂໍ້ຜິດພາດ:

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]

ຖ້າພວກເຮົາເບິ່ງເລິກກວ່າ, ພວກເຮົາເຫັນວ່າ instance ຂອງພວກເຮົາໃນ AWS ມີລັກສະນະນີ້:

ແລະມັນຄວນຈະເປັນແບບນີ້:

ຈາກນີ້ມັນເປັນທີ່ຊັດເຈນວ່າ vpc-controller ບໍ່ໄດ້ປະຕິບັດສ່ວນຫນຶ່ງຂອງມັນດ້ວຍເຫດຜົນບາງຢ່າງແລະບໍ່ສາມາດເພີ່ມທີ່ຢູ່ IP ໃຫມ່ໃຫ້ກັບຕົວຢ່າງເພື່ອໃຫ້ pods ສາມາດນໍາໃຊ້ໄດ້.

ໃຫ້ເບິ່ງບັນທຶກຂອງ vpc-controller pod ແລະນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາເຫັນ:

ບັນທຶກ kubectl -n ລະ​ບົບ cube​

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 ແລະເຂົ້າເຖິງມັນແລະດັ່ງນັ້ນຈຶ່ງເກີດຄວາມຜິດພາດ.

ແມ່ນແລ້ວ, ແທ້ຈິງແລ້ວ, ພວກເຮົາໃຊ້ເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ກໍາຫນົດເອງໃນ VPC ແລະ, ໃນຫຼັກການ, ພວກເຮົາບໍ່ໄດ້ໃຊ້ Amazon, ດັ່ງນັ້ນເຖິງແມ່ນວ່າການສົ່ງຕໍ່ບໍ່ໄດ້ຖືກຕັ້ງຄ່າສໍາລັບໂດເມນ ap-xxx.compute.internal ນີ້. ຂ້າພະເຈົ້າໄດ້ທົດສອບທາງເລືອກນີ້, ແລະມັນບໍ່ໄດ້ນໍາເອົາຜົນໄດ້ຮັບ, ບາງທີການທົດສອບແມ່ນບໍ່ສະອາດ, ແລະດັ່ງນັ້ນ, ຕື່ມອີກ, ເມື່ອຕິດຕໍ່ສື່ສານກັບການສະຫນັບສະຫນູນດ້ານວິຊາການ, ຂ້າພະເຈົ້າ succumbed ກັບຄວາມຄິດຂອງເຂົາເຈົ້າ.

ເນື່ອງຈາກວ່າບໍ່ມີຄວາມຄິດແທ້ໆ, ກຸ່ມຄວາມປອດໄພທັງຫມົດໄດ້ຖືກສ້າງຂື້ນໂດຍ eksctl ຕົວມັນເອງ, ດັ່ງນັ້ນບໍ່ມີຄວາມສົງໃສກ່ຽວກັບການບໍລິການຂອງພວກເຂົາ, ຕາຕະລາງເສັ້ນທາງແມ່ນຖືກຕ້ອງ, nat, dns, ການເຂົ້າເຖິງອິນເຕີເນັດກັບ worker nodes ກໍ່ຢູ່ທີ່ນັ້ນ.

ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າທ່ານໃຊ້ node worker ກັບ subnet ສາທາລະນະໂດຍບໍ່ຕ້ອງໃຊ້ -node-private-networking, node ນີ້ຈະຖືກປັບປຸງທັນທີໂດຍ vpc-controller ແລະທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຄືກັບໂມງ.

ມີສອງທາງເລືອກ:

1. ໃຫ້ມັນຂຶ້ນແລະລໍຖ້າຈົນກ່ວາຜູ້ໃດຜູ້ຫນຶ່ງອະທິບາຍ bug ນີ້ໃນ AWS ແລະພວກເຂົາແກ້ໄຂມັນ, ແລະຫຼັງຈາກນັ້ນທ່ານສາມາດນໍາໃຊ້ AWS EKS Windows ໄດ້ຢ່າງປອດໄພ, ເພາະວ່າພວກເຂົາພຽງແຕ່ປ່ອຍອອກມາໃນ GA (8 ມື້ຜ່ານໄປໃນເວລາທີ່ຂຽນບົດຄວາມນີ້), ຫຼາຍຄົນອາດຈະ ປະຕິບັດຕາມເສັ້ນທາງດຽວກັນກັບຂ້ອຍ.
2. ຂຽນຫາ AWS Support ແລະບອກພວກເຂົາເຖິງຄວາມສໍາຄັນຂອງບັນຫາທີ່ມີຈໍານວນບັນທຶກທັງຫມົດຈາກທຸກບ່ອນແລະພິສູດໃຫ້ພວກເຂົາວ່າການບໍລິການຂອງພວກເຂົາບໍ່ເຮັດວຽກໃນເວລາທີ່ໃຊ້ VPC ແລະເຄືອຂ່າຍຍ່ອຍຂອງເຈົ້າ, ມັນບໍ່ແມ່ນສໍາລັບສິ່ງທີ່ພວກເຮົາສະຫນັບສະຫນູນທຸລະກິດ, ທ່ານຄວນໃຊ້ ມັນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ :)

ການສື່ສານກັບວິສະວະກອນ AWS

ໄດ້ສ້າງຕົ໋ວຢູ່ໃນປະຕູ, ຂ້ອຍຜິດພາດເລືອກທີ່ຈະຕອບຂ້ອຍຜ່ານທາງເວັບ - ອີເມລ໌ຫຼືສູນສະຫນັບສະຫນູນ, ໂດຍຜ່ານທາງເລືອກນີ້, ພວກເຂົາສາມາດຕອບເຈົ້າຫຼັງຈາກສອງສາມມື້ທັງຫມົດ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າຕົ໋ວຂອງຂ້ອຍມີຄວາມຮ້າຍແຮງ - ຄວາມບົກຜ່ອງຂອງລະບົບ, ເຊິ່ງ. ຫມາຍເຖິງການຕອບສະຫນອງພາຍໃນ <12 ຊົ່ວໂມງ, ແລະນັບຕັ້ງແຕ່ແຜນການສະຫນັບສະຫນູນທຸລະກິດມີການສະຫນັບສະຫນູນ 24/7, ຂ້ອຍຫວັງວ່າຈະດີທີ່ສຸດ, ແຕ່ມັນກໍ່ກາຍເປັນສະເຫມີ.

ປີ້ຂອງຂ້ອຍຖືກປະໄວ້ໂດຍບໍ່ໄດ້ມອບໝາຍຈາກວັນສຸກຈົນຮອດວັນຈັນ, ຈາກນັ້ນຂ້ອຍຈຶ່ງຕັດສິນໃຈຂຽນຫາເຂົາເຈົ້າອີກເທື່ອໜຶ່ງ ແລະເລືອກຕົວເລືອກການຕອບແຊັດ. ຫຼັງຈາກລໍຖ້າເປັນເວລາສັ້ນໆ, Harshad Madhav ໄດ້ຖືກແຕ່ງຕັ້ງໃຫ້ເຂົ້າໄປເບິ່ງຂ້ອຍ, ແລະຫຼັງຈາກນັ້ນມັນໄດ້ເລີ່ມຕົ້ນ ...

ພວກເຮົາໄດ້ແກ້ໄຂກັບມັນອອນໄລນ໌ເປັນເວລາ 3 ຊົ່ວໂມງຕິດຕໍ່ກັນ, ການໂອນບັນທຶກ, ນໍາໃຊ້ກຸ່ມດຽວກັນຢູ່ໃນຫ້ອງທົດລອງ AWS ເພື່ອເຮັດຕາມບັນຫາ, ການສ້າງກຸ່ມຂອງຂ້ອຍຄືນໃຫມ່, ແລະອື່ນໆ, ສິ່ງດຽວທີ່ພວກເຮົາມາຮອດແມ່ນມາຈາກ. ບັນທຶກມັນເປັນທີ່ຊັດເຈນວ່າການແກ້ໄຂບໍ່ເຮັດວຽກ AWS ພາຍໃນຊື່ໂດເມນ, ທີ່ຂ້າພະເຈົ້າໄດ້ຂຽນກ່ຽວກັບຂ້າງເທິງ, ແລະ Harshad Madhav ໄດ້ຂໍໃຫ້ຂ້ອຍສ້າງການສົ່ງຕໍ່, ຖືກກ່າວຫາວ່າພວກເຮົາໃຊ້ DNS ທີ່ກໍາຫນົດເອງແລະນີ້ອາດຈະເປັນບັນຫາ.

Forwarding

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

ນັ້ນແມ່ນສິ່ງທີ່ໄດ້ເຮັດ, ມື້ໄດ້ສິ້ນສຸດລົງ, Harshad Madhav ຂຽນຄືນເພື່ອກວດເບິ່ງມັນແລະມັນຄວນຈະເຮັດວຽກ, ແຕ່ບໍ່ແມ່ນ, ການແກ້ໄຂບໍ່ໄດ້ຊ່ວຍຫຍັງເລີຍ.

ຫຼັງຈາກນັ້ນ, ໄດ້ມີການຕິດຕໍ່ສື່ສານກັບວິສະວະກອນອີກ 2 ຄົນ, ຜູ້ຫນຶ່ງພຽງແຕ່ອອກຈາກການສົນທະນາ, ປາກົດຂື້ນວ່າລາວຢ້ານກໍລະນີທີ່ສັບສົນ, ທີສອງໃຊ້ເວລາມື້ຂອງຂ້ອຍອີກເທື່ອຫນຶ່ງໃນວົງຈອນອັນເຕັມທີ່ຂອງ debugging, ສົ່ງບັນທຶກ, ສ້າງກຸ່ມທັງສອງດ້ານ, ໃນ ໃນທີ່ສຸດລາວພຽງແຕ່ເວົ້າດີ, ມັນເຮັດວຽກສໍາລັບຂ້ອຍ, ນີ້ຂ້ອຍແມ່ນຂ້ອຍເຮັດທຸກຢ່າງໂດຍຂັ້ນຕອນໃນເອກະສານທາງການແລະເຈົ້າແລະເຈົ້າຈະປະສົບຜົນສໍາເລັດ.

ທີ່ຂ້າພະເຈົ້າໄດ້ຂໍໃຫ້ລາວອອກໄປຢ່າງສຸພາບແລະມອບຫມາຍໃຫ້ຜູ້ອື່ນໃນປີ້ຂອງຂ້ອຍຖ້າທ່ານບໍ່ຮູ້ວ່າຈະຊອກຫາບັນຫາຢູ່ໃສ.

Finale

ໃນມື້ທີສາມ, ວິສະວະກອນໃຫມ່ Arun B. ໄດ້ຖືກມອບຫມາຍໃຫ້ຂ້ອຍ, ແລະຈາກຈຸດເລີ່ມຕົ້ນຂອງການສື່ສານກັບລາວມັນເຫັນໄດ້ຊັດເຈນວ່ານີ້ບໍ່ແມ່ນວິສະວະກອນ 3 ຄົນທີ່ຜ່ານມາ. ລາວໄດ້ອ່ານປະຫວັດສາດທັງຫມົດແລະທັນທີຂໍໃຫ້ເກັບກໍາຂໍ້ມູນບັນທຶກໂດຍໃຊ້ script ຂອງຕົນເອງໃນ ps1, ເຊິ່ງຢູ່ໃນ github ຂອງລາວ. ນີ້ໄດ້ຖືກປະຕິບັດຕາມອີກເທື່ອຫນຶ່ງໂດຍການເຮັດຊ້ໍາກັນທັງຫມົດຂອງການສ້າງກຸ່ມ, ຜົນໄດ້ຮັບຄໍາສັ່ງ, ເກັບກໍາຂໍ້ມູນບັນທຶກ, ແຕ່ Arun B. ກໍາລັງເຄື່ອນຍ້າຍໄປໃນທິດທາງທີ່ຖືກຕ້ອງຕາມຄໍາຖາມທີ່ຖາມຂ້ອຍ.

ເມື່ອໃດທີ່ພວກເຮົາມາຮອດຈຸດຂອງການເປີດໃຊ້ -stderrthreshold=debug ໃນ vpc-controller ຂອງພວກເຂົາ, ແລະສິ່ງທີ່ເກີດຂຶ້ນຕໍ່ໄປ? ແນ່ນອນມັນບໍ່ເຮັດວຽກ) ຝັກພຽງແຕ່ບໍ່ໄດ້ເລີ່ມຕົ້ນດ້ວຍທາງເລືອກນີ້, ພຽງແຕ່ -stderrthreshold=info ເຮັດວຽກ.

ພວກເຮົາສໍາເລັດຢູ່ທີ່ນີ້ແລະ Arun B. ເວົ້າວ່າລາວຈະພະຍາຍາມເຮັດຊ້ໍາຂັ້ນຕອນຂອງຂ້ອຍເພື່ອໃຫ້ມີຂໍ້ຜິດພາດຄືກັນ. ໃນມື້ຕໍ່ມາຂ້າພະເຈົ້າໄດ້ຮັບການຕອບຮັບຈາກ Arun B. ລາວບໍ່ໄດ້ປະຖິ້ມກໍລະນີນີ້, ແຕ່ໄດ້ເອົາລະຫັດທົບທວນຄືນຂອງ vpc-controller ຂອງພວກເຂົາແລະຊອກຫາບ່ອນທີ່ມັນຢູ່ແລະເປັນຫຍັງມັນບໍ່ເຮັດວຽກ:

ດັ່ງນັ້ນ, ຖ້າທ່ານໃຊ້ຕາຕະລາງເສັ້ນທາງຕົ້ນຕໍໃນ VPC ຂອງທ່ານ, ໂດຍຄ່າເລີ່ມຕົ້ນມັນບໍ່ມີການເຊື່ອມໂຍງກັບເຄືອຂ່າຍຍ່ອຍທີ່ຈໍາເປັນ, ເຊິ່ງມີຄວາມຈໍາເປັນຫຼາຍສໍາລັບ vpc-controller, ໃນກໍລະນີຂອງ subnet ສາທາລະນະ, ມັນມີຕາຕະລາງເສັ້ນທາງທີ່ກໍາຫນົດເອງ. ທີ່​ມີ​ສະ​ມາ​ຄົມ​.

ໂດຍການເພີ່ມສະມາຄົມດ້ວຍຕົນເອງສໍາລັບຕາຕະລາງເສັ້ນທາງຕົ້ນຕໍກັບເຄືອຂ່າຍຍ່ອຍທີ່ຈໍາເປັນ, ແລະການສ້າງ nodegroup ອີກເທື່ອຫນຶ່ງ, ທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກຢ່າງສົມບູນ.

ຂ້າພະເຈົ້າຫວັງວ່າ Arun B. ຈະລາຍງານຂໍ້ບົກພ່ອງນີ້ກັບຜູ້ພັດທະນາ EKS ແລະພວກເຮົາຈະເຫັນ vpc-controller ຮຸ່ນໃຫມ່ທີ່ທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກອອກຈາກກ່ອງ. ໃນປັດຈຸບັນສະບັບຫລ້າສຸດແມ່ນ: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ມີບັນຫານີ້.

ຂອບໃຈທຸກຄົນທີ່ອ່ານຈົນຈົບ, ທົດສອບທຸກຢ່າງທີ່ເຈົ້າຈະໃຊ້ໃນການຜະລິດກ່ອນການຈັດຕັ້ງປະຕິບັດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com