آمازون EKS Windows در GA دارای اشکال است، اما سریعترین است

عصر بخیر، می‌خواهم تجربه خود را در راه‌اندازی و استفاده از سرویس AWS EKS (سرویس Kubernetes Elastic) برای کانتینرهای ویندوز، یا بهتر بگوییم در مورد عدم امکان استفاده از آن و اشکال یافت شده در کانتینر سیستم AWS، با شما به اشتراک بگذارم. کسانی که علاقه مند به این سرویس برای کانتینرهای ویندوز هستند، لطفا زیر cat.

من می دانم که کانتینرهای ویندوز موضوع محبوبی نیستند و افراد کمی از آنها استفاده می کنند، اما من همچنان تصمیم گرفتم این مقاله را بنویسم، زیرا چند مقاله در مورد Habré در مورد kubernetes و Windows وجود دارد و هنوز هم چنین افرادی وجود دارند.

شروع

همه چیز از زمانی شروع شد که تصمیم گرفتیم خدمات شرکت ما را به kubernetes منتقل کنیم، که 70٪ ویندوز و 30٪ لینوکس است. برای این منظور سرویس ابری AWS EKS به عنوان یکی از گزینه های ممکن در نظر گرفته شد. تا 8 اکتبر 2019، AWS EKS Windows در پیش نمایش عمومی بود، من با آن شروع کردم، نسخه قدیمی 1.11 kubernetes آنجا استفاده می شد، اما تصمیم گرفتم آن را بررسی کنم و ببینم این سرویس ابری در چه مرحله ای است، آیا کار می کند یا خیر. به هیچ وجه، همانطور که مشخص شد، نه، یک اشکال با افزودن حذف پادها وجود داشت، در حالی که نسخه های قدیمی از طریق ip داخلی از همان زیرشبکه گره کارگر ویندوز پاسخ نمی دادند.

بنابراین، تصمیم گرفته شد که استفاده از AWS EKS را به نفع خوشه خودمان در kubernetes در همان EC2 کنار بگذاریم، فقط باید خودمان از طریق CloudFormation تمام تعادل و HA را توصیف کنیم.

پشتیبانی کانتینر ویندوز آمازون EKS اکنون به طور کلی در دسترس است

توسط مارتین بیبی | در 08 اکتبر 2019

قبل از اینکه فرصتی برای اضافه کردن یک الگو به CloudFormation برای کلاستر خودم داشته باشم، این خبر را دیدم پشتیبانی کانتینر ویندوز آمازون EKS اکنون به طور کلی در دسترس است

البته، همه کارم را کنار گذاشتم و شروع به مطالعه کردم که آنها برای GA چه کردند و اینکه چگونه همه چیز با Public Preview تغییر کرد. بله، AWS، آفرین، تصاویر مربوط به گره کارگر ویندوز را به نسخه 1.14 به روز کرد، همچنین خود کلاستر، نسخه 1.14 در EKS، اکنون از گره های ویندوز پشتیبانی می کند. پروژه توسط پیش نمایش عمومی در github آنها آن را پنهان کردند و گفتند حالا از اسناد رسمی اینجا استفاده کنید: پشتیبانی از ویندوز EKS

ادغام یک خوشه EKS در VPC و زیر شبکه های فعلی

در همه منابع، در لینک بالا در اعلامیه و همچنین در مستندات، پیشنهاد شده است که خوشه را از طریق ابزار اختصاصی eksctl یا از طریق CloudFormation + kubectl پس از آن، فقط با استفاده از زیرشبکه های عمومی در آمازون و همچنین ایجاد یک راه اندازی شود. VPC را برای یک خوشه جدید جدا کنید.

این گزینه برای بسیاری مناسب نیست؛ اولاً، یک VPC جداگانه به معنای هزینه اضافی برای هزینه آن + ترافیک همتا به VPC فعلی شما است. کسانی که از قبل یک زیرساخت آماده در AWS با حساب‌های AWS متعدد، VPC، زیرشبکه‌ها، جدول‌های مسیر، دروازه ترانزیت و غیره دارند، چه باید بکنند؟ البته، شما نمی خواهید همه اینها را بشکنید یا دوباره انجام دهید، و باید خوشه EKS جدید را در زیرساخت شبکه فعلی با استفاده از VPC موجود و حداکثر برای جداسازی، زیرشبکه های جدید برای خوشه ایجاد کنید.

در مورد من این مسیر انتخاب شد، من از VPC موجود استفاده کردم، فقط 2 زیر شبکه عمومی و 2 زیر شبکه خصوصی برای خوشه جدید اضافه کردم، البته طبق مستندات تمام قوانین در نظر گرفته شد. آمازون EKS Cluster 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-controller را در کلاستر خود نصب می کنیم، که سپس گره های کارگر ما را پردازش می کند، تعداد آدرس های IP رایگان و همچنین تعداد ENI های موجود در نمونه را شمارش می کند و آنها را اضافه و حذف می کند.

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

3. بعد از اینکه کانتینرهای سیستم شما با موفقیت روی گره کارگر لینوکس شما راه اندازی شد، از جمله vpc-controller، تنها چیزی که باقی می ماند این است که گروه گره دیگری با ویندوز ورکرها ایجاد کنید.

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-controller

اگر بخواهیم پادها را روی یک گره ویندوز کارگر اجرا کنیم، با خطا مواجه می شویم:

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-controller به دلایلی قسمت خود را انجام نداده و نمی تواند آدرس های IP جدیدی را به نمونه اضافه کند تا پادها بتوانند از آنها استفاده کنند.

بیایید به گزارش های غلاف کنترلر vpc نگاه کنیم و این چیزی است که می بینیم:

لاگ کوبکتل -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-controller نتواند ip-10-xxx.ap-xxx.compute.internal را حل کند و به آن برسد و بنابراین خطاهایی رخ می دهد.

بله، در واقع، ما از سرورهای DNS سفارشی در VPC استفاده می‌کنیم و اصولاً از سرورهای آمازون استفاده نمی‌کنیم، بنابراین حتی انتقال برای این دامنه ap-xxx.compute.internal پیکربندی نشده است. من این گزینه را آزمایش کردم و نتیجه ای به ارمغان نیاورد، شاید تست تمیز نبود، و بنابراین، در ادامه، هنگام برقراری ارتباط با پشتیبانی فنی، تسلیم ایده آنها شدم.

از آنجایی که واقعا هیچ ایده ای وجود نداشت، همه گروه های امنیتی توسط خود eksctl ایجاد شده بودند، بنابراین در مورد قابلیت سرویس دهی آنها شکی وجود نداشت، جدول های مسیر نیز درست بودند، nat، dns، دسترسی به اینترنت با گره های کارگر نیز وجود داشت.

علاوه بر این، اگر یک گره کارگر را در یک زیرشبکه عمومی بدون استفاده از —node-private-networking مستقر کنید، این گره بلافاصله توسط vpc-controller به روز می شود و همه چیز مانند ساعت کار می کند.

دو گزینه وجود داشت:

1. آن را رها کنید و صبر کنید تا کسی این باگ را در AWS توصیف کند و آن را برطرف کند، و سپس می توانید با خیال راحت از ویندوز AWS EKS استفاده کنید، زیرا آنها به تازگی در GA منتشر شده اند (از زمان نوشتن این مقاله 8 روز گذشته است)، احتمالاً بسیاری از آنها این کار را انجام خواهند داد. همان راه من را دنبال کن .
2. به پشتیبانی AWS بنویسید و اصل مشکل را با یک سری گزارش از همه جا به آنها بگویید و به آنها ثابت کنید که سرویس آنها هنگام استفاده از VPC و زیرشبکه های شما کار نمی کند، بیهوده نیست که ما پشتیبانی Business داشتیم، شما باید از آن استفاده کنید. حداقل یک بار :)

ارتباط با مهندسان AWS

با ایجاد یک بلیط در پورتال، من به اشتباه انتخاب کردم که از طریق وب - ایمیل یا مرکز پشتیبانی به من پاسخ دهم، از طریق این گزینه آنها می توانند پس از چند روز به شما پاسخ دهند، علیرغم اینکه بلیط من دارای Severity - System اختلال بود، که به معنای پاسخ در کمتر از 12 ساعت بود، و از آنجایی که طرح پشتیبانی کسب و کار دارای پشتیبانی 24 ساعته است، من به بهترین ها امیدوار بودم، اما مثل همیشه نتیجه داد.

بلیط من از جمعه تا دوشنبه بدون تعیین تکلیف مانده بود، سپس تصمیم گرفتم دوباره برای آنها نامه بنویسم و ​​گزینه پاسخ چت را انتخاب کردم. پس از مدت کوتاهی انتظار، هرشاد مدهاو به دیدار من منصوب شد و سپس شروع شد...

ما 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 که در github او بود جمع آوری کند. این دوباره با تمام تکرارهای ایجاد خوشه ها، خروجی نتایج فرمان، جمع آوری گزارش ها دنبال شد، اما Arun B. با قضاوت بر اساس سؤالاتی که از من پرسیده شد، در مسیر درست حرکت می کرد.

چه زمانی به نقطه فعال کردن -stderrthreshold=debug در vpc-controller رسیدیم و بعد چه اتفاقی افتاد؟ البته کار نمی کند) پاد به سادگی با این گزینه شروع نمی شود، فقط -stderrthreshold=info کار می کند.

ما اینجا را تمام کردیم و آرون بی گفت که سعی می کند مراحل من را تکرار کند تا همان خطا را دریافت کند. روز بعد از Arun B پاسخی دریافت کردم. او این مورد را رها نکرد، اما کد بررسی vpc-controller خود را گرفت و مکانی را پیدا کرد که در آن قرار دارد و چرا کار نمی کند:

بنابراین، اگر از جدول مسیر اصلی در VPC خود استفاده می‌کنید، به‌طور پیش‌فرض با زیرشبکه‌های لازم که برای کنترلر vpc ضروری است، ارتباط ندارد، در مورد یک زیرشبکه عمومی، یک جدول مسیر سفارشی دارد. که انجمن دارد

با افزودن دستی ارتباط برای جدول مسیر اصلی با زیرشبکه های لازم و ایجاد مجدد گروه گره، همه چیز به خوبی کار می کند.

من امیدوارم که Arun B. واقعاً این باگ را به توسعه دهندگان EKS گزارش کند و شاهد نسخه جدیدی از vpc-controller باشیم که همه چیز خارج از جعبه کار خواهد کرد. در حال حاضر آخرین نسخه این است: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
این مشکل را دارد

با تشکر از همه کسانی که تا آخر مطالعه کردند، قبل از اجرا، همه چیزهایی را که قرار است در تولید استفاده کنید، آزمایش کنید.

منبع: www.habr.com