په GA کې د ایمیزون EKS وینډوز بګ لري، مګر ترټولو ګړندی دی

ماسپښین مو پخیر ، زه غواړم تاسو سره د وینډوز کانټینرونو لپاره د AWS EKS (Elastic Kubernetes Service) خدمت تنظیم کولو او کارولو کې خپله تجربه شریکه کړم ، یا د دې کارولو ناممکنیت په اړه ، او د AWS سیسټم کانټینر کې موندل شوي بګ د هغو لپاره. څوک چې د وینډوز کانټینرونو لپاره د دې خدمت سره علاقه لري ، مهرباني وکړئ د پیشو لاندې.

زه پوهیږم چې د وینډوز کانټینرونه یوه مشهوره موضوع نه ده، او لږ خلک یې کاروي، مګر ما بیا هم پریکړه وکړه چې دا مقاله ولیکئ، ځکه چې په کبرنیټس او وینډوز کې د Habré په اړه یو څو مقالې وې او لاهم داسې خلک شتون لري.

پیل

دا ټول هغه وخت پیل شول کله چې پریکړه وشوه چې زموږ په شرکت کې خدمتونه کوبرنیټس ته واستول شي، کوم چې 70٪ وینډوز او 30٪ لینکس دي. د دې هدف لپاره، د AWS EKS کلاوډ خدمت یو له ممکنه انتخابونو څخه ګڼل کیده. د اکتوبر تر 8 پورې، 2019، AWS EKS وینډوز په عامه لید کې و، ما له دې سره پیل وکړ، د کوبرنیټس زوړ 1.11 نسخه هلته کارول شوې وه، مګر ما پریکړه وکړه چې دا په هر حال کې وګورم او وګورم چې دا کلاوډ خدمت په کوم پړاو کې دی، ایا دا کار کوي. په هرصورت، لکه څنګه چې دا معلومه شوه، نه، دا د پوډونو لرې کولو اضافه کولو سره یوه ستونزه وه، پداسې حال کې چې زاړه د وینډوز کارګر نوډ په څیر د ورته سبنټ څخه د داخلي ip له لارې ځواب ورکول بند کړل.

له همدې امله ، پریکړه وشوه چې په ورته EC2 کې په کبرنیټس کې زموږ د خپل کلسټر په ګټه د AWS EKS کارول پریږدو ، یوازې موږ باید ټول توازن او HA پخپله د CloudFormation له لارې تشریح کړو.

د ایمیزون EKS وینډوز کانټینر ملاتړ اوس په عمومي ډول شتون لري

د مارټین بیبي لخوا | په 08 اکتوبر 2019

مخکې لدې چې ما د خپل کلستر لپاره CloudFormation ته د ټیمپلیټ اضافه کولو وخت درلود ، ما دا خبر ولید د ایمیزون EKS وینډوز کانټینر ملاتړ اوس په عمومي ډول شتون لري

البته، ما خپل ټول کار یو طرف ته پریښود او مطالعه یې پیل کړه چې دوی د GA لپاره څه کړي، او څنګه د عامه لید سره هرڅه بدل شوي. هو، AWS، ښه ترسره شوی، د وینډوز کارګر نوډ لپاره انځورونه 1.14 نسخه ته تازه کړل، په بیله بیا پخپله کلستر، نسخه 1.14 په EKS کې، اوس د وینډوز نوډونو ملاتړ کوي. پروژه د عامه لید لخوا په github دوی دا پټ کړل او وویل چې اوس دلته رسمي اسناد وکاروئ: د EKS وینډوز ملاتړ

په اوسني VPC او فرعي نیټونو کې د EKS کلستر یوځای کول

په ټولو سرچینو کې، د اعلان په پورته لینک کې او همدارنګه په اسنادو کې، وړاندیز شوی و چې کلستر یا د ملکیت eksctl یوټیلیټ یا د CloudFormation + kubectl له لارې ځای په ځای کړي، یوازې په ایمیزون کې د عامه فرعي نیټونو په کارولو سره، او همدارنګه د جوړولو لپاره. د نوي کلستر لپاره جلا VPC.

دا اختیار د ډیری لپاره مناسب نه دی؛ لومړی، یو جلا VPC پدې معنی دی چې د دې لګښت لپاره اضافي لګښتونه + ستاسو اوسني VPC ته د ټرافیک شریکول. هغه کسان چې مخکې له مخکې په AWS کې د خپلو څو AWS حسابونو، VPC، سبنیټ، د لارې میزونه، د ټرانزیټ دروازې او داسې نورو سره چمتو شوي زیربنا لري باید څه وکړي؟ البته، تاسو نه غواړئ دا ټول مات کړئ یا بیا ترسره کړئ، او تاسو اړتیا لرئ چې نوي EKS کلستر د اوسني شبکې زیربنا کې مدغم کړئ، د موجوده VPC په کارولو سره او د جلا کولو لپاره، په ډیری وخت کې د کلستر لپاره نوي فرعي سایټونه جوړ کړئ.

زما په قضیه کې ، دا لاره غوره شوې وه ، ما موجوده VPC کارولی و ، د نوي کلستر لپاره یوازې 2 عامه فرعي نیټونه او 2 خصوصي فرعي نیټونه اضافه کړل ، البته ، ټول مقررات د اسنادو سره سم په پام کې نیول شوي خپل ایمیزون EKS کلستر VPC جوړ کړئ.

یو شرط هم شتون درلود: د EIP په کارولو سره په عامه فرعي نښو کې هیڅ کارګر نوډونه ندي.

eksctl vs 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 ته د ځای په ځای کولو لپاره، یوازې د خپل فرعي نیټ ID مشخص کړئ، او eksctl به پخپله VPC وټاکي.

د دې لپاره چې ډاډ ترلاسه کړئ چې ستاسو د کارګر نوډونه یوازې شخصي فرعي شبکې ته ځای په ځای شوي، تاسو اړتیا لرئ د نوډ ګروپ لپاره --node-private-networking مشخص کړئ.

2. موږ په خپل کلستر کې vpc-controller نصب کوو، چې بیا به زموږ د کارګر نوډونه پروسس کوي، د وړیا 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 log -n kube-system

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 سرورونه کاروو او په اصولو کې، موږ د ایمیزون نه کاروو، نو حتی د دې ap-xxx.compute.internal ډومین لپاره فارورډ کول هم ندي ترتیب شوي. ما دا اختیار ازمویلی، او پایلې یې ندي راوړي، شاید ازموینه پاکه نه وه، او له همدې امله، نور، کله چې د تخنیکي مالتړ سره اړیکه ونیولم، ما د دوی نظر ته مخه کړه.

څرنګه چې په حقیقت کې هیڅ نظر نه و، ټولې امنیتي ډلې پخپله د eksctl لخوا رامینځته شوي، نو د دوی په خدمت کولو کې هیڅ شک نشته، د لارې میزونه هم سم وو، د کارګر نوډونو سره د انټرنیټ لاسرسی هم شتون درلود.

سربیره پردې ، که تاسو د —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 نورو انجینرانو سره اړیکه وه ، یو یې په ساده ډول له چیټ څخه ووت ، ظاهرا هغه د یوې پیچلې قضیې څخه ویره درلوده ، دوهم زما ورځ بیا د ډیبګ کولو په بشپړ دوره کې تیره کړه ، د لاګونو لیږلو ، په دواړو خواو کې کلسترونه رامینځته کول. په پای کې هغه یوازې ښه وویل، دا زما لپاره کار کوي، زه دلته یم، زه هر څه د رسمي اسنادو سره ګام په ګام ترسره کوم او تاسو او تاسو به بریالي شئ.

د کوم لپاره چې ما په نرمۍ سره له هغه څخه وغوښتل چې پریږدي او زما ټیکټ ته بل څوک وټاکئ که تاسو نه پوهیږئ چې ستونزه چیرته وګورئ.

وروستی

په دریمه ورځ یو نوی انجینر ارون بی زما لپاره وګمارل شو او د هغه سره د اړیکو له پیل څخه سمدستي څرګنده شوه چې دا هغه درې پخواني انجینران ندي. هغه ټول تاریخ ولوست او سمدلاسه یې وغوښتل چې په ps3 کې د خپل سکریپټ په کارولو سره لاګونه راټول کړي ، کوم چې د هغه ګیتوب کې و. دا بیا د کلسترونو رامینځته کولو ، د کمانډ پایلې تولیدولو ، د لاګونو راټولولو ټولو تکرارونو لخوا تعقیب شو ، مګر ارون بی ما ته د پوښتل شوي پوښتنو په قضاوت سم لوري ته روان و.

موږ کله د دوی په 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