يحتوي Amazon EKS Windows في GA على أخطاء، ولكنه الأسرع

مساء الخير، أريد أن أشارككم تجربتي في إعداد واستخدام خدمة AWS EKS (خدمة Elastic Kubernetes) لحاويات Windows، أو بالأحرى حول استحالة استخدامها، والخطأ الموجود في حاوية نظام AWS، لهؤلاء المهتمين بهذه الخدمة لحاويات Windows، من فضلك تحت cat.

أعلم أن حاويات Windows ليست موضوعا شائعا، ويستخدمها عدد قليل من الناس، لكنني ما زلت قررت أن أكتب هذا المقال، حيث كان هناك مقالتان عن حبري على kubernetes وWindows ولا يزال هناك مثل هؤلاء الأشخاص.

بداية

بدأ كل شيء عندما تقرر ترحيل الخدمات في شركتنا إلى kubernetes، وهو 70% Windows و30% Linux. ولهذا الغرض، تم اعتبار الخدمة السحابية AWS EKS أحد الخيارات الممكنة. حتى 8 أكتوبر 2019، كان AWS EKS Windows في المعاينة العامة، لقد بدأت به، وتم استخدام الإصدار 1.11 القديم من kubernetes هناك، لكنني قررت التحقق منه على أي حال ومعرفة المرحلة التي كانت فيها هذه الخدمة السحابية، وما إذا كانت تعمل على الإطلاق، كما اتضح، لا، كان هناك خطأ مع إضافة إزالة القرون، بينما توقفت القديمة عن الاستجابة عبر IP الداخلي من نفس الشبكة الفرعية مثل عقدة عامل Windows.

لذلك، تقرر التخلي عن استخدام AWS EKS لصالح مجموعتنا الخاصة على kubernetes على نفس EC2، فقط سيتعين علينا وصف كل الموازنة وHA بأنفسنا عبر CloudFormation.

دعم Amazon EKS Windows Container متوفر الآن بشكل عام

بقلم مارتن بيبي | بتاريخ 08 أكتوبر 2019

قبل أن يتاح لي الوقت لإضافة قالب إلى CloudFormation لمجموعتي الخاصة، رأيت هذا الخبر دعم Amazon EKS Windows Container متوفر الآن بشكل عام

بالطبع، وضعت كل أعمالي جانبًا وبدأت في دراسة ما فعلوه من أجل GA، وكيف تغير كل شيء مع Public Preview. نعم، حسنًا، قامت AWS بتحديث الصور لعقدة عامل Windows إلى الإصدار 1.14، بالإضافة إلى المجموعة نفسها، الإصدار 1.14 في EKS، التي تدعم الآن عقد Windows. المشروع من خلال المعاينة العامة في githabe قاموا بالتستر عليه وقالوا الآن استخدم الوثائق الرسمية هنا: دعم EKS ويندوز

دمج مجموعة EKS في VPC والشبكات الفرعية الحالية

في جميع المصادر، في الرابط أعلاه الخاص بالإعلان وكذلك في الوثائق، تم اقتراح نشر المجموعة إما من خلال الأداة المساعدة eksctl الخاصة أو من خلال CloudFormation + kubectl بعد ذلك، فقط باستخدام الشبكات الفرعية العامة في Amazon، بالإضافة إلى إنشاء VPC منفصلة لمجموعة جديدة.

هذا الخيار غير مناسب للكثيرين؛ أولاً، تعني شبكة VPC المنفصلة تكاليف إضافية لتكلفتها + حركة المرور النظيرة إلى VPC الحالية. ما الذي يجب أن يفعله أولئك الذين لديهم بالفعل بنية تحتية جاهزة في AWS مع حسابات AWS المتعددة وVPC والشبكات الفرعية وجداول التوجيه وبوابة النقل وما إلى ذلك؟ بالطبع، لا ترغب في كسر أو إعادة كل هذا، وتحتاج إلى دمج مجموعة EKS الجديدة في البنية التحتية للشبكة الحالية، باستخدام VPC الحالي، وللفصل، على الأكثر إنشاء شبكات فرعية جديدة للمجموعة.

في حالتي، تم اختيار هذا المسار، واستخدمت VPC الحالي، وأضفت فقط شبكتين فرعيتين عامتين وشبكتين فرعيتين خاصتين للمجموعة الجديدة، وبالطبع، تم أخذ جميع القواعد في الاعتبار وفقًا للوثائق قم بإنشاء Amazon EKS Cluster VPC الخاص بك.

كان هناك أيضًا شرط واحد: عدم وجود عقد عاملة في الشبكات الفرعية العامة التي تستخدم EIP.

eksctl vs CloudFormation

سأحجز على الفور أنني جربت كلا الطريقتين لنشر المجموعة، وفي كلتا الحالتين كانت الصورة هي نفسها.

سأعرض مثالاً فقط باستخدام eksctl لأن الكود هنا سيكون أقصر. باستخدام eksctl، قم بنشر المجموعة في 3 خطوات:

1. نقوم بإنشاء المجموعة نفسها + عقدة Linux العاملة، والتي ستستضيف لاحقًا حاويات النظام ونفس وحدة تحكم 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. بعد إطلاق حاويات النظام بنجاح على العقدة العاملة لنظام التشغيل Linux، بما في ذلك وحدة التحكم vpc، كل ما تبقى هو إنشاء مجموعة عقدة أخرى باستخدام العاملين بنظام 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

بعد أن تم توصيل عقدتك بمجموعتك بنجاح ويبدو أن كل شيء على ما يرام، فهي في حالة جاهزة، ولكن لا.

خطأ في وحدة تحكم vpc

إذا حاولنا تشغيل البودات على عقدة عاملة Windows، فسوف نحصل على الخطأ:

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 وهذا ما نراه:

سجل كوبيكتل -ن نظام كوبي

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 من حل ip-10-xxx.ap-xxx.compute.internal والوصول إليه وبالتالي تحدث أخطاء.

نعم، في الواقع، نحن نستخدم خوادم DNS المخصصة في VPC، ومن حيث المبدأ، لا نستخدم خوادم Amazon، لذلك حتى إعادة التوجيه لم يتم تكوينها لهذا المجال ap-xxx.compute.internal. لقد اختبرت هذا الخيار، ولم يحقق نتائج، ربما لم يكن الاختبار نظيفا، وبالتالي، عند التواصل مع الدعم الفني، استسلمت لفكرتهم.

نظرًا لعدم وجود أي أفكار حقًا، تم إنشاء جميع مجموعات الأمان بواسطة eksctl نفسها، لذلك لم يكن هناك شك في قابليتها للخدمة، وكانت جداول التوجيه صحيحة أيضًا، وكان هناك أيضًا nat وdns والوصول إلى الإنترنت مع العقد العاملة.

علاوة على ذلك، إذا قمت بنشر عقدة عاملة على شبكة فرعية عامة دون استخدام —node-private-networking، فسيتم تحديث هذه العقدة على الفور بواسطة وحدة تحكم vpc وسيعمل كل شيء كالساعة.

كان هناك خياران:

1. استسلم وانتظر حتى يصف شخص ما هذا الخطأ في AWS ويقوم بإصلاحه، وبعد ذلك يمكنك استخدام AWS EKS Windows بأمان، لأنه تم إصداره للتو في GA (مرت 8 أيام في وقت كتابة هذه المقالة)، ربما سيفعل الكثيرون ذلك اتبع نفس المسار مثلي.
2. اكتب إلى دعم AWS وأخبرهم بجوهر المشكلة مع مجموعة كاملة من السجلات من كل مكان وأثبت لهم أن خدمتهم لا تعمل عند استخدام VPC والشبكات الفرعية الخاصة بك، فليس من قبيل الصدفة أن نحصل على دعم الأعمال، يجب عليك استخدامه ذلك مرة واحدة على الأقل :)

التواصل مع مهندسي AWS

بعد أن قمت بإنشاء تذكرة على البوابة، اخترت عن طريق الخطأ الرد علي عبر الويب - البريد الإلكتروني أو مركز الدعم، من خلال هذا الخيار يمكنهم الرد عليك بعد بضعة أيام على الإطلاق، على الرغم من أن تذكرتي بها خطورة - ضعف النظام، والذي كان ذلك يعني الرد خلال أقل من 12 ساعة، وبما أن خطة دعم الأعمال تتمتع بدعم على مدار 24 ساعة طوال أيام الأسبوع، فقد كنت أتمنى الأفضل، ولكن اتضح الأمر كما هو الحال دائمًا.

لقد تركت تذكرتي غير مخصصة من الجمعة حتى الاثنين، ثم قررت أن أكتب إليهم مرة أخرى واخترت خيار الرد على الدردشة. وبعد الانتظار لفترة قصيرة، تم تعيين هارشاد مادهاف لرؤيتي، ثم بدأ الأمر...

لقد قمنا بتصحيح الأخطاء عبر الإنترنت لمدة 3 ساعات متتالية، ونقل السجلات، ونشر نفس المجموعة في مختبر AWS لمحاكاة المشكلة، وإعادة إنشاء المجموعة من جهتي، وما إلى ذلك، الشيء الوحيد الذي توصلنا إليه هو أنه من من خلال السجلات، كان من الواضح أن القرار لا يعمل مع أسماء النطاقات الداخلية لـ AWS، وهو ما كتبت عنه أعلاه، وطلب مني Harshad Madhav إنشاء إعادة توجيه، ويُزعم أننا نستخدم DNS مخصص وقد يكون هذا مشكلة.

إعادة توجيه

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

وهذا ما حدث، لقد انتهى اليوم، وقد رد هارشاد مادهاف على الأمر للتحقق من الأمر ويجب أن يعمل، ولكن لا، لم يساعد الحل على الإطلاق.

ثم كان هناك اتصال مع مهندسين آخرين، أحدهما انسحب ببساطة من الدردشة، ويبدو أنه كان خائفًا من حالة معقدة، والثاني قضى يومي مرة أخرى في دورة كاملة من تصحيح الأخطاء، وإرسال السجلات، وإنشاء مجموعات على كلا الجانبين، في في النهاية، قال حسنًا، إنه يعمل بالنسبة لي، وأنا هنا أفعل كل شيء خطوة بخطوة في الوثائق الرسمية وسوف تنجح أنت وأنت.

لذلك طلبت منه بأدب المغادرة وتعيين شخص آخر على تذكرتي إذا كنت لا تعرف مكان البحث عن المشكلة.

خاتمة

في اليوم الثالث، تم تعيين مهندس جديد لي، آرون بي، ومنذ بداية التواصل معه كان من الواضح على الفور أن هذا لم يكن المهندسين الثلاثة السابقين. لقد قرأ التاريخ بأكمله وطلب على الفور جمع السجلات باستخدام البرنامج النصي الخاص به على ps3، والذي كان موجودًا على موقع github الخاص به. وأعقب ذلك مرة أخرى كل التكرارات لإنشاء المجموعات، وإخراج نتائج الأوامر، وجمع السجلات، ولكن آرون ب. كان يتحرك في الاتجاه الصحيح بناءً على الأسئلة المطروحة علي.

متى وصلنا إلى نقطة تمكين -stderrthreshold=debug في وحدة تحكم vpc الخاصة بهم، وماذا حدث بعد ذلك؟ بالطبع لا يعمل) الكبسولة ببساطة لا تبدأ بهذا الخيار، فقط -stderrthreshold=info هي التي تعمل.

لقد انتهينا هنا وقال آرون ب. إنه سيحاول إعادة إنتاج الخطوات التي قمت بها للحصول على نفس الخطأ. في اليوم التالي تلقيت ردًا من Arun B. ولم يتخل عن هذه الحالة، ولكنه تناول رمز المراجعة الخاص بوحدة التحكم vpc الخاصة به ووجد المكان الذي يوجد فيه ولماذا لا يعمل:

وبالتالي، إذا كنت تستخدم جدول التوجيه الرئيسي في VPC الخاص بك، فإنه افتراضيًا لا يحتوي على ارتباطات بالشبكات الفرعية الضرورية، والتي تعتبر ضرورية جدًا لوحدة تحكم vpc، وفي حالة الشبكة الفرعية العامة، فإنه يحتوي على جدول توجيه مخصص التي لديها جمعية.

من خلال إضافة ارتباطات جدول التوجيه الرئيسي يدويًا مع الشبكات الفرعية الضرورية وإعادة إنشاء مجموعة العقد، يعمل كل شيء بشكل مثالي.

آمل أن يقوم Arun B. بإبلاغ مطوري EKS بهذا الخطأ وسنرى إصدارًا جديدًا من وحدة التحكم vpc حيث سيعمل كل شيء خارج الصندوق. أحدث إصدار حاليًا هو: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
لديه هذه المشكلة.

شكرًا لكل من قرأ حتى النهاية، اختبر كل ما ستستخدمه في الإنتاج قبل التنفيذ.

المصدر: www.habr.com