المرجع التبادلي مع kubernetes / kubernetes: المشكلة رقم 62822

شكرا للتحديث!

/ تعيينleblancd
/ نوع الميزة
/ شبكة سيج
/ معلم 1.11

leblancd أي وثيقة تصميم متاحة؟

/ سم مكعبthockindcbwluxas @ kubernetes / سيج-شبكة ميزة طلبات

idvoretskyi - لا يوجد مستند تصميم حتى الآن ، لكننا سنبدأ في التعاون على واحد قريبًا.

هل هذا يعني أن Kubernetes Ingress سيدعم Dual-Stack؟
هل هذا يعني أن CNI (Calico) سيحتاج إلى تشغيل Dual stack (على سبيل المثال BIRD و BIRD6 daemons)؟

@ sb1975 - فيما يتعلق بدعم الدخول المزدوج ، هذا شيء سنحتاج إلى تجزئته ، ولكن هذه هي أفكاري الأولية:

• يعتمد دعم إدخال المكدس المزدوج في الغالب على وحدة التحكم في الدخول التي تستخدمها (سواء كانت مدعومة وكيف يتم تنفيذها). من المحتمل أن تحتاج وحدات التحكم في الدخول الحالية إلى بعض التغييرات لدعم المكدس المزدوج.
• أتوقع ألا يتغير تكوين الإدخال لوحدة تحكم الدخول النموذجية (قد يستمر التكوين على سبيل المثال بتعيين عنوان L7 إلى اسم خدمة / منفذ خدمة ، دون ذكر عائلة V4 / V6)
• في الحالة التي تحتوي فيها الخدمة على كبسولات نقطة نهاية ذات مكدس مزدوج ، فقد تحتاج وحدة (وحدات) التحكم في الدخول إلى تغييرات لتعيين حزم الإدخال بناءً على عائلة الحزم ، أي تعيين حزم إدخال IPv4 إلى نقطة نهاية IPv4 ، وتعيين حزم إدخال IPv6 إلى نقطة نهاية IPv6. لأغراض ترجيح موازنة الحمل ، يجب أن تُحسب نقطة نهاية المكدس المزدوجة كهدف نقطة نهاية واحدة.

- قد نرغب في التفكير في دعم FUTURE لوجود خريطة تحكم دخول عبر عائلات V4 / V6 (خريطة إدخال حزم IPv4 إلى واجهة IPv6 الخلفية ، والعكس بالعكس) ، ولكن تطويرنا الأولي سيكون للمكدس المزدوج الصارم (أي منفصل ومستقل مداخن).

فيما يتعلق بـ Calico ومكونات CNI الأخرى:

• لن يكون من الضروري تشغيل مكونات CNI الإضافية في وضع المكدس المزدوج إذا كان سيناريو المجموعة لا يتطلب مكدسًا مزدوجًا ، فيجب أن تظل قادرة على تشغيل IPv4 فقط أو IPv6 فقط (إذا كان البرنامج الإضافي يدعمها).
• من المحتمل أن يتطلب دعم المكدس المزدوج تغييرات في المكونات الإضافية المختلفة لـ CNI ، ولكن هذا العمل يعتبر خارج نطاق مشكلة Kubernetes هذه (نحن نركز على جعل Kubernetes يعمل مع أي مكون إضافي تعسفي مزدوج المكدس ، ربما باستخدام المكوِّن الإضافي لـ bridge كـ مرجع) ، وسيتم عمل CNI بشكل منفصل على أساس كل حالة على حدة.
• بالنسبة إلى Calico على وجه التحديد ، لست خبيرًا ولكني أعتقد أنه يمكن تكوين برنامج BIRD الخفي واحد للتعامل مع كل من مسارات IPv4 و IPv6 (ابحث عن "template bgp" هنا: http://bird.network.cz/؟get_doc&v= 20 & f = bird-3.html # ss3.1). ومع ذلك ، على الرغم من أن Calico تدعم بالفعل العناوين المزدوجة في الحجرة ، فقد تكون هناك تغييرات مطلوبة لتشغيل توجيه BGP لكلتا العائلتين.

leblancd : هذا هو السيناريو:

1. لنفترض أننا سنستخدم جهاز تحكم دخول NGINX
2. أنا أعرض خدماتي عبر Ingress.
3. أنا أقوم بتشغيل القرون الخاصة بي التي تم تكوينها على مكدس مزدوج
4. أحاول الوصول إلى الخدمة عن بُعد باستخدام سجلات نظام أسماء النطاقات A و AAAA.
   أتمنى كل هؤلاء
5. باختصار: أريد الاتصال بواجهات pod باستخدام عناوين IPv4 أو IPv6 ، كما تم حلها بواسطة استفساراتي الخاصة بسجلات A و / أو AAAA لاسم خدمة pod.
   هل يمكنني المشاركة في هذه المبادرة للاختبار والتوثيق والهندسة المعمارية: لكني بحاجة إلى بعض الإرشادات.
   كيف يمكنني التعرف على التقدم المحرز في هذا من فضلك.

@ sb1975 - سؤال جيد إعادة. NGINX تحكم دخول مع كومة مزدوجة. أنا لست خبيرًا في جهاز التحكم في دخول NGINX (ربما يمكن لشخص أكثر دراية القفز إليه) ، ولكن إليك كيف أرى تدفق العمل:

• عندما تحاول الوصول إلى خدمات Kube من الخارج ، يجب أن يقوم جهاز التحكم في DNS الخاص بك بحل الخدمة بسجلات A و AAAA DNS لوحدة التحكم في الدخول. سيكون اختيار العميل / التطبيق الخاص بك هو استخدام سجل A مقابل سجل AAAA للوصول إلى وحدة التحكم في الدخول. لذا فإن الوصول الخارجي إلى وحدة التحكم في الدخول سيكون مكدسًا مزدوجًا.
• في وحدة تحكم إدخال NGINX ، ستنظر NGINX بعد ذلك في عنوان URL L7 (بغض النظر عن وجود الطلب في حزمة IPv4 أو IPv6) وتوازن التحميل لنقاط نهاية المنبع. إذا تم تكوين موازن تحميل وحدة التحكم في الدخول باستخدام ipv6 = on (وهو افتراضي ، راجع https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns) ، ونقطة نهاية الخدمة هي مكدس مزدوج ، ثم يجب أن يحتوي التكوين الرئيسي على كل من مدخلات IPv4 و IPv6 لكل نقطة نهاية مكدس مزدوج. كما تم تصميمه ، يتعامل موازن تحميل NGINX مع إدخال IPv4 وإدخال IPv6 لنقطة نهاية كخوادم منفصلة . (راجع السطر في المستند السابق ذكره "إذا انتقل اسم المجال إلى عدة عناوين IP ، فسيتم حفظ العناوين في التكوين الرئيسي وتحميل متوازن.") يمكن اعتبار ذلك أخبارًا جيدة أو أخبارًا سيئة. والخبر السار هو أن موازنة التحميل ستتم عبر نقاط نهاية IPv4 و IPv6 (مما يمنحك بعض التكرار) ، حيث يمكن على سبيل المثال تعيين طلب IPv4 الوارد إلى نقطة نهاية IPv4 أو IPv6. لكن الأخبار السيئة المحتملة تتعلق بدقة موازنة التحميل: سيتم التعامل مع الاتصال بنقطة نهاية IPv4 والاتصال بنقطة نهاية IPv6 المقابلة (لاعتبارات موازنة التحميل) على أنهما تحميلان لنقاط نهاية منفصلة ، بدلاً من تحميلين منفصلين إلى نفس نقطة النهاية . إذا كان هذا التفصيل لموازنة التحميل مصدر قلق ، فيمكن لشخص ما تعطيل موازنة التحميل إلى IPv6 (أو IPv4 ، إذا كان هناك مقبض تكوين لذلك؟) ، بحيث تكون موازنة التحميل على نقاط نهاية IPv4 فقط. أو ، ربما يمكن تعديل موازن تحميل NGINX للتعامل مع اتصال بعنوان IPv4 والاتصال بعنوان IPv6 المقابل له على أنه يتم تحميل 2 إلى نفس نقطة النهاية.

بالنسبة للمساعدة والمشاركة ، سيكون هذا موضع تقدير كبير! نحن على وشك البدء في العمل بجدية على المكدس المزدوج (لقد تأخر قليلاً بسبب العمل على تشغيل CI لـ IPv6 فقط). آمل أن أخرج بمخطط تفصيلي لمواصفات (مستند Google Doc أو KEPs WIP) قريبًا ، وسأبحث عن مساعدة في المراجعة ، وربما كتابة بعض الأقسام. سنحتاج أيضًا بالتأكيد إلى المساعدة في الوثائق الرسمية (بما يتجاوز مواصفات التصميم) ، وتحديد وتنفيذ اختبارات E2E مزدوجة المكدس. تتضمن بعض المجالات التي ما زلت أرسمها قليلاً في التصميم ما يلي:

• كيف تتأثر مجسات الصحة / الحيوية / الجاهزية أو يتم التعامل معها باستخدام المكدس المزدوج
• هل سيكون هناك تأثير على سياسات الشبكة؟
• مخاوف موازن التحميل؟
• مخاوف البرنامج المساعد موفر السحابة؟
• مخاوف دخول L3 / L4؟
  إذا كنت قد فكرت في أي من هؤلاء ، فربما يمكنك المساعدة في هذه الأقسام؟

نحن نفكر أيضًا في نهج وسيط "مكدس مزدوج عند الحافة" (مع IPv6 داخل المجموعة فقط) ، حيث يكون الوصول من خارج المجموعة إلى خدمات K8s مزدوج المكدس ، ولكن سيتم تعيين هذا (على سبيل المثال عبر NGINX دخول وحدة التحكم) إلى نقاط نهاية IPv6 فقط داخل الكتلة (أو استخدم NAT46 عديم الحالة). يجب أن تكون البودات والخدمات في المجموعة كلها IPv6 ، ولكن الميزة الكبرى هي أن الوصول الخارجي المزدوج سيكون متاحًا بسرعة أكبر بكثير من منظور وقت الوصول إلى السوق.

/ معلم 1.12

leblancd / caseydavenport - ألاحظ الكثير من المناقشات هنا وتغييرًا بارزًا.
هل يجب سحب هذا من 1.11 علامة فارقة؟

justaugustus - نعم ، يجب نقل هذا إلى 1.12. هل أحتاج إلى حذف صف في جدول بيانات الإصدار ، أم أن هناك أي شيء أحتاج إلى القيام به لتغيير هذا؟

leblancd لقد قمت بتغطيتها. شكرا للمتابعة! :)

leblancd @ kubernetes / طلبات ميزات الشبكة sig -

تمت إزالة هذه الميزة من المرحلة السابقة ، لذلك نود تسجيل الوصول ومعرفة ما إذا كانت هناك أي خطط لذلك في Kubernetes 1.12.

إذا كان الأمر كذلك ، فيرجى التأكد من أن هذه المشكلة محدثة بجميع المعلومات التالية:

• وصف ميزة من سطر واحد (يمكن استخدامه كملاحظة إصدار):
• جهة الاتصال الأساسية (المسؤول):
• SIGs المسؤولة:
• رابط اقتراح التصميم (مجتمع الريبو):
• رابط إلى e2e و / أو اختبارات الوحدة:
• المراجع (المراجعون) - (لـ LGTM) يوصون بموافقة أكثر من 2 من المراجعين (واحد على الأقل من ملف OWNERS في منطقة الكود) على المراجعة. يفضل المراجعون من عدة شركات:
• الموافق (من المحتمل أن يكون من SIG / المنطقة التي تنتمي إليها الميزة):
• هدف الميزة (أي الهدف يساوي أي حدث رئيسي):
  
  
  
  • هدف إطلاق ألفا (س ص)
  
  
  • هدف إصدار بيتا (س ص)
  
  
  • هدف الإطلاق المستقر (xy)
  
  

اضبط ما يلي:

• وصف
• معين (ق)
• ملصقات:
  
  
  
  • المرحلة / {alpha، beta، stabil}
  
  
  • سيج / *
  
  
  • النوع / الميزة
  
  

يرجى ملاحظة أن تجميد الميزات هو 31 يوليو ، وبعد ذلك ستتطلب أي مشكلات غير مكتملة للميزات طلب استثناء ليتم قبوله في المرحلة الرئيسية.

بالإضافة إلى ذلك ، يرجى الانتباه إلى المواعيد النهائية التالية ذات الصلة:

• الموعد النهائي لمحرر المستندات (فتح العناصر النائبة PRs): 8/21
• تجميد حالة الاختبار: 8/28

يرجى التأكد من تضمين ملاحظات الإصدار ذات الصلة في جميع العلاقات العامة الخاصة بالميزات أيضًا.

شحن سعيد!

/ ccjustaugustus @ kacole2robertsandoval @ rajendar38

leblancd -
ميزة تجميد اليوم. هل تخطط لتخرج هذا إلى Beta في Kubernetes 1.12؟
إذا كان الأمر كذلك ، فهل يمكنك التأكد من تحديث كل شيء ، حتى يمكنني تضمينه في جدول بيانات تتبع ميزة 1.12؟

مرحبًا justaugustus - يجب أن تنتقل حالة الإصدار التجريبي إلى Kubernetes 1.13. نحن نحقق تقدمًا (وإن كان بطيئًا) في تصميم KEP (https://github.com/kubernetes/community/pull/2254) ، ونقترب من إعادة التفاعل مع اختبار CI للعلاقات العامة ، ولكن Kubernetes 1.12 كان الهدف متفائلًا بعض الشيء.

سوف أقوم بتحديث الوصف / الملخص أعلاه بالمعلومات التي طلبتها مسبقًا. شكرا لك على صبرك.

/ إزالة المرحلة ألفا
/ المرحلة بيتا

لا تقلق ،leblancd. شكرا للتحديث!

مرحبا،justaugustusleblancd

لقد قرأت للتو التحديث الذي يشير إلى نقل الإصدار التجريبي إلى 1.13 للمكدس المزدوج. ما هو تاريخ الإصدار المتوقع 1.13؟ نحن في الواقع نبحث عن دعم مكدس مزدوج. إنه قرار go-nogo أن ينتقل منتجنا إلى الحاويات.

@ navjotsingh83 - لا أعتقد أنه تم تحديد تاريخ إصدار Kubernetes 1.13. لا أرى 1.13 مدرجًا في وثائق إصدارات Kubernetes .

@leblancd navjotsingh83 يتم نشر 1.13 الافراج عن الجدول الزمني . إنها دورة إصدار قصيرة مع تجميد الرمز في 15 نوفمبر. هل تعتقد أنه حان الوقت الكافي لترقية هذه الميزة إلى الإصدار التجريبي. هل يمكنك تحديث هذه المشكلة بمستوى ثقتك ، وما الذي ينتظره من حيث الكود والاختبار وإكمال المستندات؟

وفقًا للمناقشة في اجتماع شبكة SIG ، على الرغم من أنه سيتم إنجاز عمل كبير على هذه الميزة في 1.13 ، فمن غير المتوقع الانتقال إلى Beta في 1.13. إزالة معلم وفقا لذلك.

/ معلم واضح

@ kacole2 لإزالة هذا من جدول بيانات التحسينات 1.13

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

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

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

leblancd مرحبًا - أنا قائد التحسين لـ 1.14 وأنا أتحقق من هذه المشكلة لمعرفة العمل (إن وجد) المخطط له لإصدار 1.14. تجميد التحسينات هو 29 يناير وأريد أن أذكر أن جميع التحسينات يجب أن تحتوي على KEP

leblancd يريد متابعة تعليقك السابق المتعلق بإنشاء ترسيم على حافة المجموعة لـ IPv4 / IPv6:

"نحن نفكر أيضًا في نهج وسيط" مكدس مزدوج عند الحافة "(مع IPv6 داخل المجموعة فقط) ، حيث يكون الوصول من خارج المجموعة إلى خدمات K8s ثنائي المكدس ، ولكن سيتم تعيين هذا (على سبيل المثال عبر NGINX ingress controller) إلى نقاط نهاية IPv6 فقط داخل الكتلة (أو استخدم NAT46 عديم الحالة). يجب أن تكون البودات والخدمات في المجموعة كلها IPv6 ، ولكن الميزة الكبرى هي أن الوصول الخارجي المزدوج سيكون متاحًا بسرعة أكبر بكثير من منظور الوقت للوصول إلى السوق. "

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

KevinAtDesignworx إذا كان نهج الحافة المزدوجة المكدس ولكن curl -v 93.184.216.34 -H "Host: example.com" ) ، أعتقد حقًا أنه أفضل نهج. إذا كانت بنيتك الأساسية يمكنها استخدام IPv6 ، فلماذا عناء استخدام IPv4 باستثناء الحافة لأسباب تتعلق بالتوافق. ومع ذلك ، إذا كان هذا النهج يعني أنه لا يمكنني الوصول إلى مواقع الويب القديمة التي تستخدم ipv4 فقط من داخل مجموعتي ، فأنا لست متأكدًا بعد الآن.

حسنًا ، هناك 464XLAT لذا فإن ipv6 فقط داخل الحاوية سيكون ممكنًا.

KevinAtDesignworx - إذا كان استخدام وحدة التحكم في الدخول سيعمل في السيناريو الخاص بك ، فمن الممكن تكوين وحدة تحكم دخول NGINX للتشغيل المزدوج المكدس من الخارج (وكيل لعائلة واحدة داخل المجموعة): https://github.com/leblancd/ # تثبيت kube-v6- a-double-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

يجب أن تعمل وحدات التحكم في الدخول على الشبكة المضيفة على كل عقدة ، لذلك يجب إعداد وحدات التحكم على أنها مجموعة خفية (وحدة تحكم دخول واحدة على كل عقدة). هذا يفترض:

• العقد الخاصة بك هي مكدس مزدوج (على عكس البودات والخدمات كونها عائلة واحدة)
• يحتوي / etc / hosts الخاص بك على كل عقدة على إدخالات IPv6 ، وإدخالات IPv6 فقط (لا توجد عناوين IPv4) لاسم مضيف تلك العقدة.

سيكون هذا بالإضافة إلى NAT64 / DNS64 للاتصالات من عملاء V6 داخل الكتلة إلى خوادم IPv4 الخارجية فقط.

يعد NAT46 بدون حالة خيارًا أيضًا ، لكنني لم أجرب ذلك ، لذلك ليس لدي أي أدلة تكوين لذلك.

leblancd أي عمل مخطط هنا لـ 1.15؟ يبدو أنه لم يتم قبول KEP بعد في هذه المرحلة أيضًا. شكرا!

leblancd يريد متابعة تعليقك السابق المتعلق بإنشاء ترسيم على حافة المجموعة لـ IPv4 / IPv6:

"نحن نفكر أيضًا في نهج وسيط" مكدس مزدوج عند الحافة "(مع IPv6 داخل المجموعة فقط) ، حيث يكون الوصول من خارج المجموعة إلى خدمات K8s ثنائي المكدس ، ولكن سيتم تعيين هذا (على سبيل المثال عبر NGINX ingress controller) إلى نقاط نهاية IPv6 فقط داخل الكتلة (أو استخدم NAT46 عديم الحالة). يجب أن تكون البودات والخدمات في المجموعة كلها IPv6 ، ولكن الميزة الكبرى هي أن الوصول الخارجي المزدوج سيكون متاحًا بسرعة أكبر بكثير من منظور الوقت للوصول إلى السوق. "

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

من داخل الحاوية (وهو ipv6 فقط) يتم إرسال طلب curl (مثل curl -v 93.184.216.34 -H "Host: example.com") إلى خارج المجموعة. أعتقد أنه سيعطي خطأ لوجهة غير معروفة أو وجهة لا يمكن الوصول إليها ، ما لم يكن هناك مسار ipv4 على المضيف حيث توجد الحاوية.

@ GeorgeGuo2018 إذا كانت k8s ستنفذ DNS64 / NAT64 فإنها ستعمل. يعتمد ذلك بشكل كبير على المدى الذي ستنتقل إليه k8s في حلول 464xlat / plat وما يجب التعامل معه على أجهزة التوجيه الطرفية ، إلخ ...

في الواقع أعتقد أنه سيكون من الممكن باستخدام DaemonSet / Deployment الذي يستخدم شبكة المضيف و Tayga داخل مساحة اسم نظام kube بحيث يستخدم DNS64 الداخلي tayga للخروج خارج الشبكة.

يبدو وكأنه حل بالنسبة لي.

نقوم بتشغيل شبكة IPv6 فقط داخليًا ويعمل NAT64 / DNS64 بشكل جيد بالنسبة لنا. بالنسبة لبعض العناصر القديمة حيث لم يكن هناك دعم IPv6 على الإطلاق ، انتهى بنا الأمر باستخدام clatd مباشرة حيث كانت هناك حاجة إليه. (في حالتنا مباشرة على VM.)

@ kacole2 - أرغب في تتبع هذا لـ 1.15. أنا أعمل على دمج العلاقات العامة التالية - https://github.com/kubernetes/enhancements/pull/808

على وجه التحديد لـ 1.15 سنضيف دعمًا لما يلي:

• تعديلات نوع API
  
  
  
  • أنواع Kubernetes
  
  
  • أنواع CRI
  
  
• شبكة جراب مزدوج المكدس (جراب IP متعدد)
• دعم متعدد الأسرة kubenet

cccaseydavenport لتتبع المعالم ^

@ kacole2 تم دمج KEP الآن. اسمحوا لي أن أعرف ما إذا كان هناك أي شيء آخر نحتاجه لتعقب هذا في 1.15

مرحبًا leblancd @ lachie83 فقط للتذكير الودود ، نحن نبحث عن

@ kacole2 تم دمج KEP الآن. اسمحوا لي أن أعرف ما إذا كان هناك أي شيء آخر نحتاجه لتعقب هذا في 1.15

@ lachie83 مرحبًا ،

@ kacole2 تم دمج KEP الآن. اسمحوا لي أن أعرف ما إذا كان هناك أي شيء آخر نحتاجه لتعقب هذا في 1.15

في الواقع ، أريد معرفة ما إذا كان دعم المكدس المزدوج سيضاف بالتأكيد في k8s 1.15.

leblancd من المقرر أن يكون العنصر النائب PR مقابل k8s.io dev-1.15 يوم الخميس 30 مايو.

leblancd من المقرر أن يكون العنصر النائب PR مقابل k8s.io dev-1.15 يوم الخميس 30 مايو.

هل يمكنني اعتبار أن دعم المكدس المزدوج سيكون متاحًا في الإصدار 1.15؟

@ GeorgeGuo2018 لا يزال موجودًا على ورقة التحسين لـ 1.15 ولكن فقط قائد التحسين @ kacole2 يمكنه تزويدك بتفاصيل أفضل عن ذلك.

مرحبًا @ lachie83leblancd. تجميد الرمز يوم الخميس 30 مايو 2019 @ EOD PST . يجب أن تكون جميع التحسينات المدخلة على الإصدار كاملة التعليمات البرمجية ، بما في ذلك الاختبارات ، وأن تكون مستندات PRs مفتوحة.

يرجى سرد كافة العلاقات العامة الحالية k / k حتى يمكن تتبعها في حالة التجميد. إذا لم يتم دمج PRs بالتجميد ، فإن هذه الميزة ستنزلق لدورة الإصدار 1.15. سيتم السماح فقط بقضايا حظر الإصدار والعلاقات العامة في الحدث.

أرى أن kubernetes / kubernetes # 62822 في المنشور الأصلي لا يزال مفتوحًا. هل هناك علاقات عامة أخرى نتوقع دمجها أيضًا؟

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

simplytunde - نقدر الرؤساء. أنا أعمل على جمع مستندات العلاقات العامة معًا هذا الأسبوع.

@ GeorgeGuo2018 - سيكون هذا KEP متعدد الإصدارات. نحن نخطط لمرحلة الهبوط 1 في 1.15. يرجى إلقاء نظرة على خطة التنفيذ في KEP لمزيد من التفاصيل - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -خطة.

simplytunde - لقد أنشأت المستندات https://github.com/kubernetes/website/pull/14600. أخطط لإكماله وجعله جاهزًا للمراجعة خلال اليومين المقبلين.

@ kacole2 شكرا على ping. لقد قمت بتحديث جدول التحسينات 1.15 باستخدام k / k PR الذي نتتبعه (https://github.com/kubernetes/kubernetes/pull/73977) جنبًا إلى جنب مع مسودة مستندات العلاقات العامة (https://github.com/ kubernetes / موقع / pull / 14600). ما زلنا على المسار الصحيح حاليًا لدمج هذا العلاقات العامة قبل تجميد الرمز. LMK إذا فاتني أي شيء آخر

@ kacole2 بعد المناقشة مع claurence وفريق الإصدار قررنا إزالة هذا من 1.15 معلم. يرجى المضي قدمًا وإزالته وتحديث جدول البيانات بالشكل المناسب. شكرا على كل ما تبذلونه من المساعدة حتى الآن.

/ معلم واضح

simplytunde لقد علقت أيضًا على مستندات العلاقات العامة. هل يمكنك التأكد من حذفك من 1.15 أيضًا؟

مرحبا @ lachie83leblancd، وأنا 1.16 تعزيز الظل. هل ستتخرج هذه الميزة بمراحل ألفا / بيتا / مستقرة في 1.16؟ يرجى إعلامي حتى يمكن إضافته إلى جدول بيانات التتبع 1.16 .

التواريخ الرئيسية هي تجميد التحسين 7/30 وتجميد الرمز 8/29.

شكرا لك.

يغطي https://github.com/kubernetes/dns/issues/315 إضافة IPv6 / AAAA إلى مواصفات اكتشاف خدمة DNS .

@ lachie83leblancd أي فكرة إذا كان هذا سيتخرج في 1.16 لتتبعه؟

@ evillgenius75 @ kacole2 يجب تتبع هذا في 1.16. ستكون هذه الميزة في حالة ألفا. سنقوم بتنفيذ المرحلة 1 والمرحلة 2 كما هو محدد في KEP هو 1.16

تتبع KEP

• https://github.com/kubernetes/enhancements/pull/808

مدمج k / k PRs (حاليًا في المستوى الرئيسي سيكون في 1.16)

• [MERGED] المرحلة 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [MERGED] اختبارات المرحلة 1 e2e - https://github.com/kubernetes/kubernetes/pull/78801
• [MERGED] تنظيف اختبار المرحلة 1 e2e - https://github.com/kubernetes/kubernetes/pull/80001
• خدمات المرحلة 2 / نقاط النهاية - https://github.com/kubernetes/kubernetes/pull/79386
• المرحلة 2 kube-proxy - https://github.com/kubernetes/kubernetes/pull/79576

العلاقات العامة المرتبطة

• دعم IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• مستندات المرحلة الأولى - سيتم إعادة فتحها بمجرد الانتهاء من أمثلة الأدوات - https://github.com/kubernetes/website/pull/14600
• [MERGED] تنظيف - إسقاط العقدةDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• دعم أحجام أقنعة متعددة لأرقام المجموعة - https://github.com/kubernetes/kubernetes/pull/79993
• وظيفة E2e Prow لـ dualstack https://github.com/kubernetes/test-infra/pull/12966

مرحبًا ، leblancd ، أنا قائد إصدار مستندات v1.16.

هل يتطلب هذا التحسين (أو العمل المخطط للإصدار 1.16) أي مستندات جديدة (أو تعديلات)؟

مجرد تذكير ودود أننا نبحث عن علاقات عامة ضد k / website (فرع dev-1.16) بحلول يوم الجمعة 23 أغسطس. سيكون من الرائع أن تكون هذه هي بداية التوثيق الكامل ، ولكن حتى العنصر النائب PR مقبول. اسمحوا لي أن أعرف إذا كان لديك أي أسئلة!

simplytunde ها هو مستندات العلاقات العامة - https://github.com/kubernetes/website/pull/16010

@ lachie83 تجميد كود التذكير الودي لـ 1.16 يوم الخميس 8/29. (كأنك لا تعرف ذلك). يبدو أن هذه العلاقات العامة لا تزال معلقة:
خدمات المرحلة 2 / نقاط النهاية - kubernetes / kubernetes # 79386
المرحلة 2 kube-proxy - kubernetes / kubernetes # 79576

مرتبط:
دعم أحجام أقنعة متعددة لأقراص العنقود - kubernetes / kubernetes # 79993
وظيفة E2e Prow لـ dualstack kubernetes / test-infra # 12966

مرحبا @leblancd lachie83 يبدو كما لو https://github.com/kubernetes/kubernetes/pull/79576 و https://github.com/kubernetes/kubernetes/pull/79993 لم دمج قبل تجميد رمز وانها ليست في تجمع Tide Merge . هذه الميزة سوف تصطدم من الإصدار 1.16. إذا كنت لا تزال ترغب في أن يكون هذا جزءًا من الإصدار 1.16 ، فيرجى تقديم استثناء

@ kacole2 نعتذر عن التأخير في الرد. كانت العلاقات العامة الأولية تتبع https://github.com/kubernetes/kubernetes/pull/79386. بالنسبة إلى kubernetes / kubernetes # 79576 ، اتخذنا قرارًا بتأجيل ذلك إلى 1.17 والتركيز بدلاً من ذلك على https://github.com/kubernetes/kubernetes/pull/82091 (بالاتفاق مع sig-network) التي تحقق نفس أهداف المرحلة 2 التي تم وضعها في KEP. تم تتبع العلاقات العامة الأخرى ذات الصلة في هذا الإصدار https://github.com/kubernetes/kubernetes/pull/80485 والتي تم دمجها أيضًا. تم أيضًا تأجيل kubernetes / kubernetes # 79993 إلى 1.17

يا هناك @ lachie83leblancd - 1.17 تحسينات تؤدي هنا. أردت تسجيل الوصول ومعرفة ما إذا كنت تعتقد أن هذا التحسين سينتقل إلى ألفا / بيتا / مستقر في 1.17؟

جدول الإصدار الحالي هو:

• الاثنين 23 سبتمبر - تبدأ دورة الإصدار
• الثلاثاء ، 15 أكتوبر ، التخلص من الذخائر المتفجرة بتوقيت المحيط الهادئ - تجميد التحسينات
• الخميس ، 14 نوفمبر ، التخلص من الذخائر العنقودية - تجميد الرمز
• الثلاثاء ، 19 تشرين الثاني (نوفمبر) - يجب إكمال المستندات ومراجعتها
• الاثنين 9 كانون الأول (ديسمبر) - تم إصدار Kubernetes 1.17.0

إذا قمت بذلك ، فيرجى إدراج جميع العلاقات العامة k / k ذات الصلة في هذه المشكلة حتى يمكن تتبعها بشكل صحيح. 👍

شكرا!

/ معلم واضح

مرحبا بوب. شكرا على رسالتك. ما زلت أخطط للمرحلة الثالثة من هذا التحسين والتي ستكمل التعزيز حتى اكتماله. سيظل هذا التحسين في الإصدار الأولي في نهاية هذا الإصدار ولكن سيكون هناك عمل متعلق بالمرحلة 3 والذي سيصل إلى k / k كجزء من 1.17.

فيما يلي قائمة بالمخرجات عالية المستوى لـ 1.17 للمكدس المزدوج. سوف أقوم بتحديث هذه القائمة طوال الإصدار.

• IPtables dual-stack proxier - https://github.com/kubernetes/kubernetes/pull/79576
• دعم واجهة برمجة التطبيقات لأسفل لـ Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e اختبار مكون إضافي CNI
• تغييرات ملف المضيف (يجب إضافة عنوان IPv6 لاسم المضيف / etc / hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• نوع مزدوج المكدس - https://github.com/kubernetes-sigs/kind/pull/692
• تحديث مجموعة e2e - https://github.com/kubernetes/kubernetes/pull/80725
• دعم شريحة نقطة النهاية
• دعم Dual-Stack لـ Kubeadm - https://github.com/kubernetes/kubeadm/issues/1612

أقدر ذلك كثيرًا ، شكرًا لك بلطف @ lachie83 ❤️

/ معلم الإصدار 1.17.0

mrbobbytables لقد أضفت أيضًا عامة لتفاصيل العمل المذكور أعلاه كجزء من المرحلة 3 في KEP بعد توصيل الخطة عبر شبكة sig. لا يزال KEP نفسه في حالة implementable وهذه التغييرات هي مجرد توثيق للعمل المخطط كجزء من 1.17 على وجه التحديد.

في مرحلة ما ، أود التأكد من أن https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ يغطي IPv6 DNS. https://github.com/kubernetes/website/issues/15434 يتتبع هذا التغيير ؛ أذكرها هنا لتدوين الإسناد الترافقي.

تم تحديث KEP لإضافة اختبارات المرحلة 2 e2e - https://github.com/kubernetes/enhancements/pull/1311

مرحبًا @ lachie83 ، أنا أحد ظلال مستندات الإصدار 1.17.
هل يتطلب هذا التحسين (أو العمل المخطط له للإصدار 1.17) أي مستندات جديدة (أو تعديلات على المستندات الحالية)؟ إذا لم يكن الأمر كذلك ، فهل يمكنك تحديث ورقة تعقب التحسين 1.17 (أو إخباري وسأفعل ذلك)

إذا كان الأمر كذلك ، مجرد تذكير ودود أننا نبحث عن علاقات عامة ضد k / موقع الويب (الفرع dev-1.17) بحلول يوم الجمعة ، 8 نوفمبر ، يمكن أن يكون مجرد عنصر نائب للعلاقات العامة في هذا الوقت. اسمحوا لي أن أعرف إذا كان لديك أي أسئلة!

MustafaHosny اللهم امين

نظرًا لأننا نقترب من الموعد النهائي للعلاقات العامة في عنصر Docs النائب في الثامن من تشرين الثاني (نوفمبر). يرجى محاولة الحصول على واحد في مقابل فرع k / website dev-1.17.

مرحبًا هناك @ lachie83 ، أعلم أنك تحتفظ بعلامات تبويب ، لكني بحاجة إلى الظهور والإشارة إليها على أي حال 🙈
أصبح تجميد الكود قاب قوسين أو أدنى (14 نوفمبر). كيف تبدو الأشياء؟ هل كل شيء على المسار الصحيح ليتم دمجه قبل ذلك الحين؟

شكرا!

ياmrbobbytables! شكرا على ping. نحن نتتبع العلاقات العامة التالية للهبوط في 1.17. قد يكون هناك واحد أو اثنين من العلاقات العامة المرتبطة بهذا التغيير والتي تأتي أيضًا. ستحتاج هذه التغييرات إلى مستندات. سأرفع عنصر نائب مستندات العلاقات العامة

• دعم Dualstack لوضع kube-proxy iptables pr / 82462
• Dualstack downward api pr / 82462
• إضافة IPvs metaproxier endpointslice support pr / 84089
• السماح بأقنعة cidr متعددة العقد في kube-controller-manager pr / 79993

irvifa - هنا العنصر النائب مستندات العلاقات العامة. https://github.com/kubernetes/website/pull/17457

رائع شكرا 🎉 @ lachie83

@ lachie83 غدًا هو تجميد الكود لدورة الإصدار 1.17. يبدو أن k / k PRs لم يتم دمجها بعد. 😬 نحن نضع علامة على هذا على أنه معرض للخطر في ورقة تتبع التحسين 1.17.
هل تعتقد أنه سيتم دمجهم بواسطة EoD ليوم 14 (الخميس)؟ بعد هذه النقطة ، لن يُسمح إلا بقضايا حظر الإصدار والعلاقات العامة في الحدث الرئيسي باستثناء استثناء.

شكرًا بوب - سأناقش هذا الأمر مع شبكة سيج اليوم وسأقدم تحديثًا.

ياmrbobbytables. فيما يلي قائمة بالعلاقات العامة التي نعمل على دمجها بواسطة EoD اليوم وتمت الموافقة عليها من قبل sig-network.

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

من المرجح أن يتم دفع العلاقات العامة المتبقية إلى 1.18 - https://github.com/kubernetes/kubernetes/pull/82462

mrbobbytables يؤكد فقط أن جميع

عظيم ، شكرا @ lachie83!

وهي حية! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

نخطط لنقل هذا التحسين إلى الإصدار التجريبي في 1.18. يمكن العثور على معايير التخرج المحسّنة وخطط الاختبار في KEP جنبًا إلى جنب مع هذا PR - https://github.com/kubernetes/enhancements/pull/1429

/ معلم 1.18

@ lachie83 : المعلم المقدم غير صالح لهذا المستودع. المراحل الرئيسية في هذا المستودع: [ keps-beta ، keps-ga ، v1.17 ، v1.18 ، v1.19 ، v1.20 ، v1.21 ]

استخدم /milestone clear لمسح المرحلة الرئيسية.

/ معلم الإصدار 1.18.1

نخطط لنقل هذا التحسين إلى الإصدار التجريبي في 1.18. يمكن العثور على معايير التخرج المحسّنة وخطط الاختبار في KEP جنبًا إلى جنب مع PR - # 1429

نشكرك على التحديث @ lachie83 ، لقد قمت متتبع في جدول بيانات 1.18!

يرجى تتبع العلاقات العامة التالية كجزء من العمل للوصول إلى 1.18. https://github.com/kubernetes/kubernetes/pull/82462

إضافة علاقات عامة أخرى ذات صلة للتتبع:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

شكرا @ lachie83!

مرحبًا @ lachie83 ، هل لديك أي علاقات عامة أخرى يجب أن

مرحبا، @ lachie83leblancd - أنا الظل مستندات على فريق 1.18 الإصدار.

هل يتطلب هذا التحسين المخطط لـ 1.18 أي مستندات جديدة أو تعديلات على المستندات الحالية؟

إذا لم يكن الأمر كذلك ، فهل يمكنك تحديث ورقة تعقب التحسين 1.18 (أو إخباري وسأفعل ذلك)

إذا كانت تحديثات المستند مطلوبة ، فتذكير بأن العناصر النائبة PRs مقابل k / موقع الويب (الفرع dev-1.18) مستحقة بحلول يوم الجمعة ، 28 فبراير.

اسمحوا لي أن أعرف إذا كان لديك أي أسئلة!

إذا أراد أي شخص المساعدة في توثيق IPV6 أو العناصر ذات المكدس المزدوج للإصدار 1.18 ، فأعطني تنبيهًا. قد أكون قادرة على مساعدة.

مرحبًا @ lachie83 ،

يبدو أن kubernetes-sigs / kind # 692 لم يندمج بعد. هل هذا مهم لتخرجك من بيتا؟

مرحبًا jeremyrickardsethmccombs ، سنضطر إلى سحب هذا من التخرج إلى https://github.com/kubernetes/kubernetes/pull/86895. إلى أن نحصل على طريقة معقولة للمضي قدمًا ، لا أعتقد أنه من الحكمة نقل هذا إلى الإصدار التجريبي لـ 1.18

/ معلم واضح

@ lachie83 شكرا لك على التحديث. لقد قمت بإزالة هذا التحسين من الإنجاز. نتطلع إلى هذا في 1.19. :)

أود أن أؤكد أن حالة تحسين المكدس المزدوج تظل في alpha في 1.18. أنا أعمل حاليًا مع المجتمع لتقييم العمل المخطط لإكماله في 1.19. من المحتمل أن يظل هذا التحسين في حالة ألفا في 1.19 ولكني أود التأكيد. سأتخذ أيضًا إجراءً بشأن تحديث المستندات لتعكس حالة التحسين في مستندات 1.18.

إذا كانت هناك صفحات على موقع الويب تعرض Kubernetes مزدوج المكدس كإصدار تجريبي ، فيرجى تقديم تلك الصفحات مقابل k / website كأولوية / أخطاء مهمة قريبًا.

مرحبًا @ lachie83 - 1.19 تحسينات

جدول الإصدار الحالي هو:

• الاثنين 13 أبريل: الأسبوع 1 - تبدأ دورة الإصدار
• الثلاثاء 19 مايو: الأسبوع السادس - تجميد التحسينات
• الخميس 25 يونيو: الأسبوع 11 - تجميد الرمز
• الخميس 9 يوليو: الأسبوع 14 - يجب إكمال المستندات ومراجعتها
• الثلاثاء 4 أغسطس: الأسبوع 17 - تم إصدار Kubernetes v1.19.0

إذا كانت هناك صفحات على موقع الويب تعرض Kubernetes مزدوج المكدس كإصدار تجريبي ، فيرجى تقديم تلك الصفحات مقابل k / website كأولوية / أخطاء مهمة قريبًا.

sftim لقد رفعت اثنين من العلاقات العامة لمعالجة

palnabarun نحن نعمل على تحديث Dualstack KEP في الإطار الزمني للإصدار 1.19 ، لكننا لا نعتقد حاليًا أننا سنقوم بتغيير كود الهبوط في الإصدار 1.19. لدينا مشكلة حظر واحدة في العمل الذي تم إنجازه بالفعل (بفضل وجوده في حالة alpha ). مشكلة الحظر هي https://github.com/kubernetes/kubernetes/pull/86895. نخطط لمعالجة ذلك من خلال تحديث متابعة KEP https://github.com/kubernetes/enhancements/pull/1679 ولكن الأمر سيستغرق بعض الوقت للحصول على إجماع على التغيير المقترح. في هذه المرحلة ، سيظل تحسين Dualstack في حالة alpha حتى نعالج مشكلة الحظر هذه مع التنفيذ الحالي. سأقدم تحديثات مع تقدم الأمور.

شكرا لك لاتشي على التحديثات. أنا أقدر كل الجهود! : قليلا_ابتسامة_الوجه:

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

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

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

نود أن يتم تتبع هذا التحسين في 1.20. سيتم إعادة تنفيذه في حالة ألفا وفقًا لـ kep المحدث - https://github.com/kubernetes/enhancements/pull/1679. يرجى تتبع العلاقات العامة التالية للتنفيذ - https://github.com/kubernetes/kubernetes/pull/91824. نحن نخطط لإكمال المراجعة ودمج العلاقات العامة في وقت مبكر من دورة الإصدار 1.20.

أحدث تخرج مزدوج المكدس إلى حالة بيتا كما تمت مناقشته في اجتماع شبكة SIG في 17 سبتمبر ، لأولئك الذين يلعبون في المنزل:

• يجب حل الغموض في الفحص الصحي kubelet dual-stack. عبر https://github.com/kubernetes/enhancements/pull/1975
• يجب إنهاء ودمج خدمات العلاقات العامة الحالية المزدوجة المكدس (قيد المراجعة النشطة) ؛ عبر https://github.com/kubernetes/kubernetes/pull/91824
• يجب إنهاء سلوك عناوين IP للعقدة المزدوجة المكدسة ؛ عبر https://github.com/kubernetes/enhancements/pull/1665
• يجب تحديد التغييرات (إن وجدت) المطلوبة لحقل Spec.LoadBalancerIPs الخاص بالخدمة

يتم العمل بنشاط على كل هذه العناصر ، ولا يزال 1.20 هدفًا لتخرج بيتا API مزدوج المكدس. ومع ذلك ، على الرغم من بذل قصارى جهدنا ، هناك دائمًا فرصة لن يتم حل شيء ما في الوقت المناسب ، وإذا كان الأمر كذلك ، فستقرر SIG Network ما إذا كانت ستستمر في التخرج إلى Beta أم لا في اجتماعاتنا العامة. الكل مرحب به للانضمام

dcbw شكرًا جزيلاً لك على التحديث (آسف لم أستطع إجراء المكالمة). هل من المنطقي الحصول على هذا التحسين إلى الإصدار التجريبي في 1.20 أو مجرد البقاء في ألفا؟ إذا أردنا الانتقال إلى الإصدار التجريبي ، فهل تظل معايير التخرج في KEP منطقية بالنظر إلى أن هذا إعادة تنفيذ https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # معايير

dcbw شكرًا جزيلاً لك على التحديث (آسف لم أستطع إجراء المكالمة). هل من المنطقي الحصول على هذا التحسين إلى الإصدار التجريبي في 1.20 أو مجرد البقاء في ألفا؟ إذا أردنا الانتقال إلى الإصدار التجريبي ، فهل تظل معايير التخرج في KEP منطقية بالنظر إلى أن هذا إعادة تنفيذ https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # معايير

إنه ليس إعادة تطبيق حقًا ، رغم ذلك. كل الأعمال السابقة لا تزال صالحة والعمل في 1.20 يبني فوقه لإنهاء التغييرات الأخيرة المطلوبة التي تم تحديدها. تفسيري لمناقشة sig-network هو أن القائمة dcbw المنشورة هي مجموعة المشكلات المعروفة المتبقية التي يجب حلها من أجل التخرج.

تحية للجميع،

1.20 تحسينات الرصاص هنا ، سأقوم بتعيين هذا على أنه متتبع ، يرجى إعلامي إذا تغير أي شيء :)

كتذكير ، تجميد التحسينات هو السادس من أكتوبر.

كملاحظة ، يستخدم KEP تنسيقًا قديمًا قمنا بتحديثه إلى: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

أفضل،
كيرستن

/ معلم v1.20

مرحبًا ، russellb -

إنه ليس إعادة تطبيق حقًا ، رغم ذلك. كل الأعمال السابقة لا تزال صالحة والعمل في 1.20 يبني فوقه لإنهاء التغييرات الأخيرة المطلوبة التي تم تحديدها.

نظرًا لتغييرات واجهة برمجة التطبيقات في https://github.com/kubernetes/kubernetes/pull/91824 ، هناك اختلاف كافٍ في أن تمييز المكدس المزدوج على أنه alpha لـ 1.20 سيتيح مساحة لأي عمليات إعادة تنفيذ أخرى تكون ضرورية. أعلم أننا جميعًا متحمسون للنسخة التجريبية ، لكن دعنا أولاً نحصل على العلاقات العامة بـ +9,319 −3,261 ونترك الغبار يستقر. :)

نظرًا لتغييرات واجهة برمجة التطبيقات في kubernetes / kubernetes # 91824 ، هناك اختلاف كافٍ في أن تمييز المكدس المزدوج على أنه ألفا لـ 1.20 سيتيح مساحة لأي عمليات إعادة تنفيذ أخرى تكون ضرورية. أعلم أننا جميعًا متحمسون للنسخة التجريبية ، لكن دعنا أولاً نحصل على العلاقات العامة بـ +9,319 −3,261 ونترك الغبار يستقر. :)

bridgetkromhout نعم ، نحتاج إلى الوصول إلى https://github.com/kubernetes/kubernetes/pull/91824 قبل أن نتمكن من اتخاذ أي قرار بشأن جاهزية واجهة برمجة التطبيقات. آمل حقًا أن نتمكن من القيام بذلك في أسرع وقت ممكن.

تحية للجميع،

1.20 ظل تحسين هنا 👋

نظرًا لأنه من المقرر أن يكون هذا التحسين في 1.20 ، يرجى مراعاة هذه التواريخ القادمة المهمة:
الجمعة 6 تشرين الثاني (نوفمبر): الأسبوع الثامن - الموعد النهائي لعنصر العلاقات العامة للمستندات
الخميس 12 تشرين الثاني (نوفمبر): الأسبوع التاسع - تجميد الرمز

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

شكرا لك!

مرحباkinarashahkikisdeliveryservice - لقد أكد على دعوة سيج شبكة أننا بحاجة إلى هذا تصنيف ألفا عن 1.20. إنها إعادة تنفيذ كاملة تحتاج إلى وقت للنقع والاختبار في مرحلة ألفا.

مرحبًا @ lachie83 ، 1.20 Docs shadow هنا.

هل يتطلب هذا التحسين المخطط لـ 1.20 أي مستندات جديدة أو تعديل للمستندات الحالية؟

إذا كان الأمر كذلك، يرجى تتبع الخطوات هنا لفتح PR ضد dev-1.20 فرع في k/website الريبو. يمكن أن يكون هذا PR مجرد عنصر نائب في هذا الوقت ويجب إنشاؤه قبل 6 تشرين الثاني (نوفمبر) .

ألقِ نظرة أيضًا على التوثيق للحصول على إصدار حتى تتعرف على متطلبات المستندات للإصدار.

شكرا لك!

شكرًا @ reylejano-rxm - لقد فتحنا kubernetes / الموقع الإلكتروني # 24725

مرحبا @ lachie83

شكرا لإنشاء مستندات العلاقات العامة!

يرجى مراعاة التواريخ القادمة المهمة:

• الجمعة 6 تشرين الثاني (نوفمبر): الأسبوع الثامن - انتهاء الموعد النهائي للعلاقات العامة في Docs Placeholder !
• الخميس 12 تشرين الثاني (نوفمبر): الأسبوع التاسع - تجميد الرمز
• الاثنين 23 تشرين الثاني (نوفمبر): الأسبوع الحادي عشر - العلاقات العامة للمستندات جاهزة للمراجعة

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

مرحباkinarashahkikisdeliveryservice - لقد أكد على دعوة سيج شبكة أننا بحاجة إلى هذا تصنيف ألفا عن 1.20. إنها إعادة تنفيذ كاملة تحتاج إلى وقت للنقع والاختبار في مرحلة ألفا.

يا @ lachie83

بالنظر إلى ما سبق ، أفترض أن هذا لا يزال مخصصًا لـ alpha كما هو؟ لا أرى أي علاقات عامة معلقة تحتاج إلى الدمج / تم دمج العمل بالفعل.

_للتذكير فقط بأن تجميد الرمز سيأتي في غضون يومين يوم الخميس ، 12 نوفمبر . يجب دمج جميع PRs بحلول ذلك التاريخ ، وإلا فإن الاستثناء مطلوب.

شكرا!
كيرستن

مرحبًا ، kikisdeliveryservice - نعم ، دعم مكدس IPv4 / IPv6 المزدوج (

إليك التقدم الذي أحرزناه في هذا التحسين:

1) تم دمج الرمز من https://github.com/kubernetes/kubernetes/pull/91824 - سيكون ألفا لـ 1.20
2) تحديثات الوثائق التي تغطي هذا التغيير في الكود موجودة في https://github.com/kubernetes/website/pull/24725/ - تمت مراجعتها ودمجها في فرع dev-1.20

هل هناك أي شيء آخر مطلوب لـ 1.20 لم نكمله في هذا التحسين؟

bridgetkromhout شكرًا على التحديث الواضح ، كل شيء على ما يرام!

يبدو أن LoadBalancerIP في ServiceSpec ليس جزءًا من تنفيذ المكدس المزدوج حتى الآن. هل هناك أي خطة لدعمه أم فاتني؟

مرحبًا chenwng - التغييرات على رمز موفر السحابة لـ Loadbalancers خارج النطاق حاليًا كما هو محدد في KEP هنا - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md # تحميل -موازن-عملية.

يمكنك المساعدة من خلال تقديم حالة الاستخدام والتغييرات المقترحة لفهم ما إذا كنا بحاجة إلى إجراء أي تعديلات على KEP.

chenwng هناك KEP قيد العمل مقابل LoadBalancerIPs في مجموعات مكدسة مزدوجة - https://github.com/kubernetes/enhancements/pull/1992

شكرا على المعلومات ، aramase ، @ lachie83 .