الأمازون EX ويندوز في GA مع الأخطاء ، ولكن أسرع من أي شخص

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

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

بداية

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

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

أمازون EKS Windows حاوية دعم متاح الآن بشكل عام

مارتن بيبي | في 08 أكتوبر 2019

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

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

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

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

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

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

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

eksctl مقابل CloudFormation

سوف أبدي تحفظًا على الفور أنني جربت طريقتي نشر الكتلة ، في كلتا الحالتين كانت الصورة واحدة.

سأعرض مثالاً فقط مع استخدام eksctl لأن الرمز أقصر هنا. باستخدام eksctl cluster نشر في 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 نفسه.

لكي يتم نشر عقدة العامل الخاصة بك فقط على الشبكة الفرعية الخاصة ، يجب عليك تحديد - عقدة شبكة خاصة لشبكة nodegroup.

2. قم بتثبيت vpc-controller في مجموعتنا ، والتي ستقوم بعد ذلك بمعالجة العقد الخاصة بنا عن طريق حساب عدد عناوين IP المجانية ، بالإضافة إلى عدد ENI في المثيل ، إضافة وإزالتها.

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

3. بعد بدء تشغيل حاويات النظام بنجاح على عقدة عامل نظام التشغيل 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 

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

خطأ في وحدة تحكم 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-controller وهذا ما نراه:


لم تؤد عمليات بحث Google إلى أي شيء ، لأنه من الواضح أن أحداً لم يكتشف مثل هذا الخطأ بعد ، أو حسنًا ، أو نشر مشكلة في ذلك ، كان علي أن أفكر أولاً وقبل كل شيء في الخيارات. أول ما يتبادر إلى الذهن هو أنه ربما لا تستطيع وحدة التحكم vpc أن تفكر في ip-10-xxx.ap-xxx.compute.internal وتصل إليه ، وبالتالي تقع الأخطاء.

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

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

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

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

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

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

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

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

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

الشحن

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

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

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

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

خاتمة

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

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

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



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

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

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

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

تحديث: علة جديدة # 2

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

المشكلة:
نشر التطبيق على Kubernetes ، اضبط النشر ، النسخ المتماثلة> 1 ، وانظر الصورة التالية. يبدأ الجراب الجديد بشكل طبيعي ويعمل ، في حين يفقد الجراب القديم واجهة شبكته. نعم ، نعم ، قرنة قديمة تماما دون شبكة ، على الرغم من أنه لا يزال معلقا في حالة التشغيل. قم بتقليل النسخ المتماثلة أو زيادتها ، وحذف السنفات بحيث لا تفعل دائمًا فقط الجود الذي دخل آخر مرة في حالة التشغيل ، وكل الباقي لن يعمل. بغض النظر ، تبدأ القرون أو على أخرى مختلفة في نفس العقدة.

الحل:
نعم ، اتضح مرة أخرى أن المشكلة كانت في التكوين المخصص لـ VPC الخاص بنا ، أي إذا كنت تستخدم مجموعة خيارات DHCP التي تشير إلى القيمة المخصصة لحقل اسم المجال ، أو كانت فارغة تمامًا (كما في حالتي ، لقد قمت بتغيير خوادم أسماء النطاقات فقط ، لم أكن بحاجة إلى الباقي) سوف تواجه مشكلة غير مفهومة مع اختفاء واجهات الشبكة داخل أجهزة الكمبيوتر بعد الإطلاق.

تحتاج إلى تسجيله في مجموعة خيارات DHCP:

 domain-name = <aws-region-name>.compute.internal; 

وبعد ذلك ، يجب إعادة تثبيت جميع العقد الخاصة بك بحيث تقوم المكونات أثناء التسجيل بتمهيد الإعدادات الصحيحة.

فيما يلي تفاصيل كيفية تأثير خيار اسم المجال هذا على العقد الخاصة بك:



هذه المرة ، طلبت منهم إضافة وثائق على الأقل إلى AWS EKS for Windows ، وهي "ميزات" خدمتهم.