لاحظ أنه ربما يتعين علينا أيضًا إعادة تسمية الخدمة إلى lbservice أو شيء ما لتمييزها عن أنواع الخدمات الأخرى.

كجزء من هذا ، سأقوم بإزالة كائنات الخدمة من الخادم الأساسي وتسهيل استخدام موازنات الأحمال الأخرى ، مثل HAProxy و nginx.

سيكون من الجيد إذا كان التعريف المنطقي للخدمة (الاستعلام و / أو الاسم العام) قادرًا على الاستخدام / التخصص بعدة طرق - كموازن تحميل بسيط مثبت عبر البنية التحتية ، كموازن تحميل كامل أكثر ميزة مثل nginx أو haproxy الذي توفره البنية التحتية أيضًا ، كنقطة نهاية قابلة للاستعلام يمكن للمتكامل الاستقصاء / الانتظار عليها (GET / services / foo -> {endpoints: [{host، port}، ...]}) ، أو كمعلومات متاحة للمضيفين لفضح موازنات الحمل المحلي. من الواضح أن هذه يمكن أن تكون حالات استخدام مختلفة متعددة وبالتالي تنقسم إلى مواردها الخاصة ، ولكن وجود بعض المرونة في تحديد النية (التوحيد تحت lb) بشكل متميز عن الآلية يجعل من السهل تلبية مجموعة واسعة من المتطلبات.

smarterclayton أوافق على فصل السياسة والآلية.

الأساسيات التي نحتاجها:

1. القدرة على استطلاع / مشاهدة مجموعة محددة بواسطة محدد التسمية. لست متأكدًا مما إذا كانت هناك مشكلة تم رفعها حتى الآن.
2. القدرة على الاستعلام عن عناوين IP pod (# 385).

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

الأوليان اللذان وصفهما @ bgrant0607 هل يستحق إبقاء هذه المشكلة مفتوحة؟ أم أن هناك قضايا أكثر تحديدًا يمكننا تقديمها؟

لا أعتقد أن zookeeper قد تم حله - لأنك بحاجة إلى المعرف الفريد في كل حاوية. أعتقد أنه يمكنك القيام بذلك باستخدام 3 وحدات تحكم منفصلة للنسخ المتماثل (واحدة لكل مثيل) أو وضع على وحدة تحكم النسخ المتماثل.

أعتقد أن تصميم الخدمة يستحق بعض المناقشة كما يلاحظ بريان. حاليًا يقرن تجريد البنية التحتية (الوكيل المحلي) بآلية للتعرض (متغيرات البيئة في جميع الحاويات) مع استعلام التسمية. هناك حالة استخدام صالحة بنفس القدر لبروكسي الحافة الذي يأخذ مضيف / مسارات L7 ويوازنهم في استعلام التسمية ، بالإضافة إلى البروتوكولات الداعمة مثل http (s) ومآخذ الويب. بالإضافة إلى ذلك ، تتمتع الخدمات اليوم بحد نطاق صارم يبلغ 60 ألف خلفية ، يتم مشاركتها عبر المجموعة بأكملها (مقدار عناوين IP المخصصة). يجب أن يكون من الممكن تشغيل وكيل محلي على العميل الذي يعمل بالوكيل فقط على الخدمات التي يحتاجها هذا المضيف ، وكذلك لتجنب الحاويات التي تحتاج إلى معرفة المنفذ الخارجي. يمكننا نقل هذه المناقشة إلى # 494 إذا لزم الأمر.

معالجة مشكلة الخدمات الفردية والخدمات غير ذات التحجيم التلقائي مع النسخ المتماثل الثابت ، مثل قواعد البيانات المنسوخة من قبل السيد والعبد ، ومخازن القيمة الرئيسية مع مجموعات الأقران ذات الحجم الثابت (على سبيل المثال ، إلخ ، حارس الحديقة) ، إلخ.

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

الاقتراح: يجب علينا إنشاء نكهة جديدة للخدمة ، تسمى خدمات Cardinal ، والتي تعين عناوين N IP بدلاً من عنوان واحد فقط. ستؤدي الخدمات Cardinal تعيينًا ثابتًا لعناوين IP هذه إلى مثيلات N المستهدفة بواسطة محدد التسمية الخاص بها (على سبيل المثال ، N المحدد ، وليس فقط العديد من الأهداف الموجودة). بمجرد أن يكون لدينا DNS (# 1261 ، # 146) ، فإنه سيعين أسماء DNS يمكن التنبؤ بها بناءً على بادئة متوفرة ، مع لواحق من 0 إلى N-1. يمكن تسجيل التعيينات في التعليقات التوضيحية أو الملصقات الخاصة بالقرون المستهدفة.

سيحافظ هذا على فصل تعيين الدور عن هويات البودات ووحدات التحكم في النسخ المتماثل ، مع توفير أسماء وعناوين IP ثابتة ، والتي يمكن استخدامها في آليات تكوين التطبيقات القياسية.

حدثت بعض المناقشات حول أنواع مختلفة من موازنة الحمل في تصميم الخدمات v2: # 1107.

سأقدم قضية منفصلة لانتخاب رئيسي.

تضمين التغريدة

يجب أن تستمر التخصيصات في القرون عبر بعض آليات تحديد معايير البيئة (من المؤكد تقريبًا).

بالنسبة لمثال الخ ، سأقوم بإنشاء:

• وحدة تحكم النسخ المتماثل 1: 1 جراب ، مشيرًا إلى حجم تخزين مستقر أ
• وحدة تحكم النسخ المتماثل 2: 1 جراب ، مشيرًا إلى حجم تخزين مستقر ب
• وحدة تحكم النسخ المتماثل 3: 1 جراب ، مشيرًا إلى حجم تخزين مستقر C.
• خدمة الكاردينال "etcd" مشيراً إلى القرون

إذا مات الكبسولة 2 ، فإن وحدة التحكم في النسخ 2 تنشئ نسخة جديدة منه وتعيد إرفاقها بالمجلد B. تعرف خدمة Cardinal Service 'etcd' أن هذا الكبسولة جديدة ، ولكن كيف تعرف أنها يجب أن تكون عنصرية 2 (والتي تأتي من البيانات المخزنة على المجلد ب)؟

بدلاً من 3 وحدات تحكم للنسخ المتماثل ، فلماذا لا تكون وحدة تحكم التجزئة ، والتي
ينظر إلى ملصق مثل "kubernetes.io/ShardIndex" عند اتخاذ القرارات. إذا
تريد تجزئة ثلاثية الاتجاهات ، فهي تصنع 3 قرون بمؤشرات 0 ، 1 ، 2. أشعر بذلك
تم إسقاط هذا من قبل ، لكن لا يمكنني إعادة بناء المشكلة التي تسببت فيها
رأسي.

يبدو من الخطأ وضع هذا العبء على عاتق المستخدمين إذا كان هذا نسبيًا
سيناريو شائع.

هل تعتقد أنه من المهم أن يتغير عنوان IP الاسمي لحجرة معينة بسبب
تغييرات غير ذات صلة في المجموعة؟ فمثلا:

في الوقت 0 ، تشكل القرون (A ، B ، C) خدمة أساسية ، مع IP
10.0.0. {1-3} على التوالي

في الوقت 1 ، تموت العقدة التي تستضيف البود ب

في الوقت 2 ، تقوم وحدة التحكم في النسخ المتماثل التي تقود B بإنشاء جراب D جديد

في الوقت 3 ، تتغير الخدمة الأساسية إلى (A ، C ، D) باستخدام IP's 10.0.0. {1-3}
على التوالى

ملحوظة: تغير "IP المستقر" للقرص C من 10.0.0.3 إلى 10.0.0.2 عند المجموعة
تغيرت العضوية. أتوقع أن يؤدي هذا إلى أشياء سيئة في الجري
روابط.

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

يوم الخميس ، 2 أكتوبر 2014 الساعة 10:17 صباحًا ، Clayton Coleman [email protected]
كتب:

يجب أن تستمر التعيينات في البودات عبر البعض
آلية معلمات البيئة (شبه مؤكد).

بالنسبة لمثال الخ ، سأقوم بإنشاء:

• وحدة تحكم النسخ المتماثل 1: 1 جراب ، مشيرًا إلى مستقر
  حجم التخزين أ
• أصل وحدة تحكم النسخ المتماثل 2: 1 جراب ، مشيرًا إلى مستقر
  حجم التخزين ب
• وحدة تحكم النسخ المتماثل 3: 1 جراب ، مشيرًا إلى مستقر
  حجم التخزين ج
• خدمة الكاردينال "etcd" مشيراً إلى القرون

إذا مات pod 2 ، يقوم جهاز التحكم في النسخ 2 بإنشاء نسخة جديدة منه و
يعيد إرفاقه بالمجلد B. يعرف Cardinal service "etcd" أن هذا الجراب موجود
جديد ، ولكن كيف يعرف أنه يجب أن يكون العنصر 2 (الذي يأتي من
البيانات المخزنة في المجلد ب)؟

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

أعتقد أن أداة التحكم في التجزئة منطقية وربما تكون أكثر فائدة في سياق الخدمة الأساسية.

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

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

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

ثالثًا ، أوافق على أننا بحاجة إلى النظر في كيفية تفاعل ذلك مع اقتراح البيانات الدائمة (# 1515) -erictune .

رابعًا ، أوافق على أننا ربما نحتاج إلى عكس الهوية في الكبسولة. وفقًا لـ # 386 ، من الناحية المثالية ، سيتم استخدام آلية قياسية لجعل تعيينات اسم IP و DNS مرئية للحجرة. كيف ستظهر أسماء IP والمضيف المستعارة عادةً في Linux؟

خامسًا ، اقترحت أن نضمن استقرار التخصيص من خلال تسجيل المهام في الكبسولات عبر الملصقات أو التعليقات التوضيحية.

سادساً ، المشكلة مع "وحدة تحكم التجزئة" التي تحل محل وحدة التحكم في النسخ المتماثل هي أنني أريد فصل تعيين الدور عن إدارة الصورة / البيئة. أرى وحدة تحكم النسخ توفر الأخير (راجع https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

في حالة البيانات الدائمة ، حسب # 1515:

1. بالنسبة للقرون المتينة ، سيعمل هذا الاقتراح فقط. سيكون التنازل مستقرًا للقرن الدائم.
2. بالنسبة لكائنات البيانات المنفصلة ، ستحتاج الخدمة الأساسية أيضًا إلى تعيين دور الإدارة لكائنات البيانات ، وستؤجل تعيين الدور إلى البودات حتى بعد مطابقتها مع البيانات. أعتقد أن هذا سيكون واضحًا.

/ ccerictune

أعتقد أنك كنت تحاول أن تجعل المحادثة أسهل ، لكني لست متأكدًا من نجاحها.

إعادة: التجزئة - أليست "مجموعة النسخ المتماثلة ذات الهوية المميزة" تجزئة بشكل أساسي؟

إعادة: 1 وحدة تحكم النسخ المتماثل - ليس لدينا وحدة تحكم في النسخ تقوم بتعيين فهارس اليوم. لا أعتقد أننا نريد ذلك ، أليس كذلك؟

رد: إخبار الكبسولة بهويتها الخاصة - الخدمة عبارة عن طبقة نظيفة فوق الكبسولة. سيكون من الفوضى إخبار الخدمة عن البود الوشيك حتى تتمكن من تعيين IP قبل وجوده. أعتقد أن المعرّف يجب أن يكون جزءًا من الكبسولة ، على سبيل المثال ملصق ShardIndex أو شيء من هذا القبيل. يمكننا عكس ذلك في الحجرة (بطريقة ما) ويمكن للخدمة استخدام ذلك لتعيين IP. إذا سمحنا للخدمة Cardinal بالقيام بذلك بنفسها ، فسيكون البود قد بدأ بالفعل بحلول الوقت الذي تم تعيينه فيه. يمكن أن يكون لدينا بيانات وصفية لكل وحدة كما نفعل مع الأجهزة الافتراضية في الحملة العالمية للتعليم ، لكن هذا اقتراح أكبر.

لا ، تقديم هويات ثابتة ومتميزة ليس ضروريًا ولا كافيًا للتجزئة. راجع # 1064 للحصول على التفاصيل ، التي أضفتها هناك للتو.

لا ، لا نريد وحدة تحكم النسخ لتعيين الفهارس. لقد اقترحت عمدًا أن تقوم خدمات Cardinal بذلك بدلاً من ذلك.

نعم ، أتوقع وجود البودات (ومن المحتمل أن تكون قد بدأت) قبل تعيين الأدوار لها (المؤشرات). كان ذلك متعمدا. يجب أيضًا أن يكون من الممكن إلغاء مهمة.

نهج الهوية المحتمل: قم بإنشاء عنوان IP مستعار غير دائم في الحاوية وقم بتوفير بحث DNS عكسي في تطبيق DNS.

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

إذا كان مدير الخدمة على استعداد لإبعاد بعض الدول عما هي عليه
حاليًا ، يمكننا فقط تذكر التعيينات التي تم إجراؤها مسبقًا
ومحاولة احترامهم.

في الخميس ، 2 أكتوبر 2014 ، الساعة 8:59 مساءً ، كتب bgrant0607 [email protected] :

نهج الهوية المحتمل: قم بإنشاء عنوان IP مستعار غير دائم في ملف
حاوية وتوفير بحث DNS عكسي في تنفيذ DNS.

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

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

إعادة. أتذكر التعيينات ، فأنا أوافق - راجع https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

ومع ذلك ، لا أعرف مدى صلة ذلك بالتعليق الذي رددت عليه.

GitHub والبريد الإلكتروني لا يختلطان. آسف

في الخميس ، 2 أكتوبر 2014 الساعة 9:39 مساءً ، كتب bgrant0607 [email protected] :

إعادة. بتذكر التعيينات ، أوافق - انظر # 260 (تعليق)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

ومع ذلك ، لا أعرف مدى صلة ذلك بالتعليق الذي رددت عليه.

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

اقترح تيم "الاسمي" ، وهو ما أوافق عليه بشكل أفضل.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

أنا أحب الاسمية كذلك. سوف أكره شرحه للمستخدمين ، ولكن غالبًا ما يتم استخدامه للتكوين الذي تم إنشاؤه (على سبيل المثال ، ستكون مجموعة النسخ المتماثلة الاسمية mongodb بمثابة وحدة تحكم في النسخ ، خدمة رمزية ، وحدات تخزين ، لذا فهي معقدة إلى حد ما).

----- رسالة أصلية -----

اقترح تيم "الاسمي" ، وهو ما أوافق عليه بشكل أفضل.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

مشكلتان أراها:

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

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

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

مثال على تشغيل zookeeper بخدمة واحدة لكل مثيل: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

لذلك أعلم أن هذا خيط قديم ، لكنه يضرب موضوعًا قريبًا وعزيزًا بالنسبة لي ؛-)

بشرط أن يتمكن النظام من دفع السجلات إلى الأمام + عكس "الخدمات الاسمية" غير nat'd إلى skydns واستخدام الأسماء كحقن ENV في الكبسولات التي تستخدم تلك الخدمة ، فهل هناك قيود أخرى؟

قد يبدو الأمر غريبًا بعض الشيء في حالة ZK حيث يستخدم كل عنصر في النصاب العناصر الأخرى ، على سبيل المثال:
يستخدم zk1: zk2 ، zk3
يستخدم zk2: zk1 ، zk3
يستخدم zk3: zk1 ، zk2

ولكن من الناحية النظرية يجب أن تعمل بشكل صحيح؟ شريطة أن نتمكن من إضافة السجلات العكسية للخدمات الاسمية.

@ bgrant0607 هل أفتقد أي شيء؟

يصبح الأمر أكثر غرابة عندما ترغب التطبيقات الأخرى في استخدام الخدمة الشاملة التي تقدمها. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

timothysc ما تقترحه سيعمل إذا كانت zk1 و zk2 و zk3 عبارة عن خدمات ، مرة واحدة على الأقل يتم دعم الخدمات متعددة المنافذ.

نعم ، هناك قبيح هنا ، رغم ذلك.

لا يعرف الكبسولة قيد التشغيل ما هي الخدمات "الأمامية" لها. على سبيل المثال ، أعطيت خدمة
لمثيل واحد من الخلفية ، لا يعرف VIP المستخدم للوصول إلى الخدمة
الخلفية (ما لم تطلب تلك المعلومات من خلال معرفة الخدمة
اسم). في الخدمة الاسمية (N) ، سيكون لديك N backends و N VIPs (و
من المفترض أن أسماء N DNS أو اسم N-address) ، لكن الخلفية ستظل كذلك
لا يعرفون كبار الشخصيات الخاصة بهم. قد يلاحظون مجموعة أسماء DNS ، لكن
لا أعرف (دون التحقيق) أيهما هو نفسه. هذا من شأنه أن يجعل ZK الخاص بك
من الصعب استخدام الشخصيات المهمة (يتم أيضًا تمثيل الشخصيات المهمة بشكل ملحوظ في الوقت الحالي).

البدائل:

1) قم بإعداد خدمة واحدة (N) واطلب من كل مثيل التحقيق في جميع الشخصيات المهمة لنفسك

2) قم بإعداد مثيلات N service (1) واستخدم الملصقات وأعلام cmdline إلى
قم بتعيين الفهارس يدويًا ، واجعل كل خلفية ZK تعرف (مسبقًا) اسم DNS
لبعضها البعض ZK الخلفية

3) قم بعمل DNS لمحددات الملصقات ، وقم بتعيين اسم DNS لمجموعة النسخ المتماثلة ZK ،
نأمل أن يستخدم العملاء DNS بشكل صحيح

4) قم بتشغيل جسور kube2zk جنبًا إلى جنب مع كل ZK يقوم بمزامنة نقاط نهاية kubernetes ->
تكوين ZK

5) تصميم طريقة بديلة لتعيين الشخصيات المهمة أو المؤشرات الأكثر
استبدال وحدة تحكم مركزية من الخدمة المركزية. بريندان وأنا
طرح بعض الأفكار هنا منذ فترة ، ولكن لم يكن لديه وقت لمتابعة
عليه.

بالنسبة لـ DNS العكسي - لست متأكدًا من أنني أرى دوره؟ انا لست ضد
دعمه (على سبيل المثال ، اطلب من
ينطبق هنا. لا تأتي حركة المرور أبدًا "من" عنوان IP للخدمة.

تيم

يوم السبت ، 7 مارس 2015 الساعة 8:56 مساءً ، Brian Grant [email protected]
كتب:

timothysc https://github.com/timothysc ما تقترحه سيعمل إذا
كانت zk1 و zk2 و zk3 خدمات ، على الأقل مرة واحدة كانت الخدمات متعددة المنافذ
أيد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) يبدو مثل هذا الاقتراح.

أنا من أشد المعجبين بـ 5 - البودات التي تعرف أن دورها هو الخطوة الأولى ، والبودات التي لها اسم DNS فريد أو تستخدم نقاط النهاية للحصول على IP للآخرين والتفاعل معها هو اثنان. ستكون القدرة على البحث عن pod ip في نقاط النهاية بواسطة معرف دور ثابت هو الثالث.

في 8 آذار (مارس) 2015 ، الساعة 11:06 صباحًا ، كتب Tim Hockin [email protected] :

نعم ، هناك قبيح هنا ، رغم ذلك.

لا يعرف الكبسولة قيد التشغيل ما هي الخدمات "الأمامية" لها. على سبيل المثال ، أعطيت خدمة
لمثيل واحد من الخلفية ، لا يعرف VIP المستخدم للوصول إلى الخدمة
الخلفية (ما لم تطلب تلك المعلومات من خلال معرفة الخدمة
اسم). في الخدمة الاسمية (N) ، سيكون لديك N backends و N VIPs (و
من المفترض أن أسماء N DNS أو اسم N-address) ، لكن الخلفية ستظل كذلك
لا يعرفون كبار الشخصيات الخاصة بهم. قد يلاحظون مجموعة أسماء DNS ، لكن
لا أعرف (دون التحقيق) أيهما هو نفسه. هذا من شأنه أن يجعل ZK الخاص بك
من الصعب استخدام الشخصيات المهمة (يتم أيضًا تمثيل الشخصيات المهمة بشكل ملحوظ في الوقت الحالي).

البدائل:

1) قم بإعداد خدمة واحدة (N) واطلب من كل مثيل التحقيق في جميع الشخصيات المهمة لنفسك

2) قم بإعداد مثيلات N service (1) واستخدم الملصقات وأعلام cmdline إلى
قم بتعيين الفهارس يدويًا ، واجعل كل خلفية ZK تعرف (مسبقًا) اسم DNS
لبعضها البعض ZK الخلفية

3) قم بعمل DNS لمحددات الملصقات ، وقم بتعيين اسم DNS لمجموعة النسخ المتماثلة ZK ،
نأمل أن يستخدم العملاء DNS بشكل صحيح

4) قم بتشغيل جسور kube2zk جنبًا إلى جنب مع كل ZK يقوم بمزامنة نقاط نهاية kubernetes ->
تكوين ZK

5) تصميم طريقة بديلة لتعيين الشخصيات المهمة أو المؤشرات الأكثر
استبدال وحدة تحكم مركزية من الخدمة المركزية. بريندان وأنا
طرح بعض الأفكار هنا منذ فترة ، ولكن لم يكن لديه وقت لمتابعة
عليه.

بالنسبة لـ DNS العكسي - لست متأكدًا من أنني أرى دوره؟ انا لست ضد
دعمه (على سبيل المثال ، اطلب من
ينطبق هنا. لا تأتي حركة المرور أبدًا "من" عنوان IP للخدمة.

تيم

يوم السبت ، 7 مارس 2015 الساعة 8:56 مساءً ، Brian Grant [email protected]
كتب:

timothysc https://github.com/timothysc ما تقترحه سيعمل إذا
كانت zk1 و zk2 و zk3 خدمات ، على الأقل مرة واحدة كانت الخدمات متعددة المنافذ
أيد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

سأخصص بعض الوقت لكتابة هذه الفكرة أكثر قليلاً ، إذن.

يوم الأحد 8 مارس 2015 الساعة 10:25 صباحًا ، Clayton Coleman [email protected]
كتب:

أنا معجب كبير بـ 5 - القرون التي تعلم أن دورها هو الخطوة الأولى ، القرون
الحصول على هوية DNS فريدة من نوعها أو استخدام نقاط النهاية للحصول على IP و
الرد عليه اثنان. القدرة على البحث عن pod ip في نقاط النهاية بواسطة a
سيكون معرف الدور المستقر ثالثًا.

في 8 آذار (مارس) 2015 الساعة 11:06 صباحًا ، أرسل Tim Hockin [email protected]
كتب:

نعم ، هناك قبيح هنا ، رغم ذلك.

لا يعرف الكبسولة قيد التشغيل ما هي الخدمات "الأمامية" لها. على سبيل المثال نظرا أ
الخدمات
لمثيل واحد من الخلفية ، فإن VIP المستخدم للوصول إلى الخدمة غير معروف
بواسطة
الخلفية (ما لم تطلب تلك المعلومات من خلال معرفة الخدمة
اسم). في الخدمة الاسمية (N) ، سيكون لديك N backends و N VIPs
(و
من المفترض أن أسماء DNS N أو اسم N-address) ، لكن الخلفية ستفعل
ما زال
لا يعرفون كبار الشخصيات الخاصة بهم. قد يلاحظون مجموعة أسماء DNS ، لكن
لا أعرف (دون التحقيق) أيهما هو نفسه. هذا من شأنه أن يجعل ZK الخاص بك
من الصعب استخدام الشخصيات المهمة (يتم أيضًا تمثيل الشخصيات المهمة بشكل ملحوظ في الوقت الحالي).

البدائل:

1) قم بإعداد خدمة واحدة (N) واطلب من كل مثيل التحقيق في جميع الشخصيات المهمة لنفسك

2) قم بإعداد مثيلات N service (1) واستخدم الملصقات وأعلام cmdline إلى
قم بتعيين المؤشرات يدويًا ، واجعل كل خلفية ZK تعرف (مسبقًا) DNS
اسم
لبعضها البعض ZK الخلفية

3) قم بعمل DNS لمحددات الملصقات ، وقم بتعيين اسم DNS لمجموعة النسخ المتماثلة ZK ،
نأمل أن يستخدم العملاء DNS بشكل صحيح

4) قم بتشغيل جسور kube2zk جنبًا إلى جنب مع كل ZK يقوم بمزامنة نقاط نهاية kubernetes
->
تكوين ZK

5) تصميم طريقة بديلة لتعيين الشخصيات المهمة أو المؤشرات الأكثر
استبدال وحدة تحكم مركزية من الخدمة المركزية. بريندان وأنا
طرح بعض الأفكار هنا منذ فترة ، ولكن لم يكن لدي وقت لذلك
إتبع
عليه.

بالنسبة لـ DNS العكسي - لست متأكدًا من أنني أرى دوره؟ انا لست ضد
دعمه (على سبيل المثال ، اطلب من
ينطبق هنا. لا تأتي حركة المرور أبدًا "من" عنوان IP للخدمة.

تيم

يوم السبت ، 7 مارس 2015 الساعة 8:56 مساءً ، Brian Grant [email protected]
كتب:

timothysc https://github.com/timothysc ما تقترحه سيعمل
إذا
كانت zk1 و zk2 و zk3 خدمات ، على الأقل مرة واحدة كانت الخدمات متعددة المنافذ
أيد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

thockin re: عكس DNS ، دعنا

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

RC التي طبقت تسمية فريدة (الأعضاء = #) على كل جراب تقوم بإنشائه ، وتحاول إنشاء تسلسل يصل إلى N من النسخ المتماثلة ، ثم خدمة بدون رأس قامت بإنشاء اسم A و CNAME لكل قيمة من تصنيف "عضو" (# .service.namespace.local) ، حيث يخدم الجذر كل تلك service.namespace.local -> round robin -> 1.service.namespace.local ، 2.service.namespace.local يبدو محليًا.

_يمكننا استخدام جراب IPs صارم لملصقات DNS الفردية تلك. يصبح إنشاء عناوين IP وهمية لكل واحد مكلفًا ولن تتمكن الحاوية من إرسال عنوان IP الخاص بها إلى شخص ما.

----- رسالة أصلية -----

thockin re: عكس DNS ، دعنا
متطلبات.

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

timothysc re: عكس DNS - ما هو DNS العكسي؟ مصدر- IP الخاص بـ
روابط؟ لا شيء من ذلك يعمل في kube. الاتصالات من خلال الخدمات
وكيل ، لذلك لا يعمل source-ip في المقام الأول (يمكن إصلاحه).

لا أعرف ZK - هل يمكنك شرح ما يحاولون تجاوزه بالعكس
DNS؟ يبدو أنه افتراض هش للغاية.

يوم الإثنين 9 مارس 2015 الساعة 9:05 صباحًا ، Timothy St. Clair [email protected]
كتب:

thockin https://github.com/thockin re: عكس DNS ، دعنا نلوح فقط
أيدينا حول ونعتبره شرطا.

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

أعتقد أن تجربتي (وربما تيم) هي أن غالبية البرامج المجمعة اليوم تتوقع ما يلي:

• كل عقدة لها هوية مستقرة
• هذه الهوية هي اسم DNS
• لا يجب أن يكون عنوان IP الخاص بالهوية الأساسية مستقرًا
• تتوقع العقدة تعريف نفسها للعقد الأخرى إما عن طريق هويتها المستقرة (DNS) أو عنوان IP العام الخاص بها
• تتوقع بعض البرامج المجمعة عنوان IP الخاص بالعقدة التي يصل إليها العميل لمطابقة عنوان IP يمكنه الإعلان عن نفسه للآخرين في المجموعة ولكي يكون عنوان IP هذا قابلاً للوصول.

----- رسالة أصلية -----

timothysc re: عكس DNS - ما هو DNS العكسي؟ مصدر- IP الخاص بـ
روابط؟ لا شيء من ذلك يعمل في kube. الاتصالات من خلال الخدمات
وكيل ، لذلك لا يعمل source-ip في المقام الأول (يمكن إصلاحه).

لا أعرف ZK - هل يمكنك شرح ما يحاولون تجاوزه بالعكس
DNS؟ يبدو أنه افتراض هش للغاية.

يوم الإثنين 9 مارس 2015 الساعة 9:05 صباحًا ، Timothy St. Clair [email protected]
كتب:

thockin https://github.com/thockin re: عكس DNS ، دعنا نلوح فقط
أيدينا حول ونعتبره شرطا.

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

يوم الاثنين ، 9 آذار (مارس) 2015 الساعة 12:49 مساءً ، كلايتون كولمان
كتب [email protected] :

RC الذي طبق تسمية فريدة (الأعضاء = #) على كل جراب يقوم بإنشائه ، ويحاول إنشاء تسلسل يصل إلى
N النسخ المتماثلة ، ثم خدمة بدون رأس قامت بإنشاء اسم A و CNAME لكل قيمة من قيم "العضو"
التسمية (# .service.namespace.local) ، حيث يخدم الجذر كل تلك الخدمات .namespace.local -> round
robin -> 1.service.namespace.local ، 2.service.namespace.local يبدو محليًا.

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

• VIPs ، PDs ، مؤشرات عامة ، وما إلى ذلك. الجميل هو أنه عندما يكون pod
  يموت ، يتم إرجاع الرمز المميز إلى التجمع ، وعندما يتم استبدال هذا الكبسولة
  يتم إعادة استخدام هذا الرمز المميز.

تأتي المشكلة مع العمل على كيفية تحويل "الرمز التعسفي" إلى
شيء ذو مغزى.

_يمكننا استخدام جراب IPs صارم لملصقات DNS الفردية تلك. يصبح إنشاء عناوين IP وهمية لكل واحد مكلفًا ولن تتمكن الحاوية من إرسال عنوان IP الخاص بها إلى شخص ما.

لم أحاول ، لكني أراهن أنه يمكننا جعل الخدمات الاسمية تفعل SNAT بالكامل
و DNAT لأنهم 1: 1. ستكون هذه طريقة لتحقيق الاستقرار
لكل حجرة IPs بدون عناوين IP قابلة للترحيل.

----- رسالة أصلية -----

thockin re: عكس DNS ، دعنا
متطلبات.

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

بعيدًا عني أن أسبح في اتجاه التيار - إذا كانت هناك تطبيقات كافية تتوقع حقًا أن يقوم DNS بذلك
تعمل بهذه الطريقة ، يمكننا جعلها تعمل بهذه الطريقة.

رسم:

يؤدي إنشاء وحدة تحكم النسخ R إلى إنشاء اسم DNS "$ R.rc" وهو ملف
تجمع جراب IPs "ضمن" ذلك RC. كل جراب P يحصل على اسم DNS
"$ P. $ R.rc". BUt ما هو P؟ يمكن أن تكون مؤشرات بسيطة ، ولكن هذا صحيح
عضتنا بشدة داخليا. يمكن أن تكون سلاسل عشوائية مثل GenerateName ،
لكن يجب عليهم البقاء على قيد الحياة بعد موت / إعادة تشغيل البود (وربما يجب على أسماء مضيفي البودات
مباراة؟).

يوم الثلاثاء ، 10 مارس 2015 ، الساعة 7:59 صباحًا ، Clayton Coleman [email protected]
كتب:

أعتقد أن تجربتي (وربما تيم) هي أن غالبية التجمعات العنقودية
يتوقع البرنامج اليوم ما يلي:

• كل عقدة لها هوية مستقرة
• هذه الهوية هي اسم DNS
• لا يجب أن يكون عنوان IP الخاص بالهوية الأساسية مستقرًا
• تتوقع العقدة تعريف نفسها للعقد الأخرى إما من خلال ثباتها
  الهوية (DNS) أو عنوان IP العام الخاص بها
• تتوقع بعض البرامج المجمعة عنوان IP الخاص بالعقدة للعميل
  يصل إليه لمطابقة عنوان IP يمكنه الإعلان عن نفسه للآخرين في
  الكتلة ومن أجل أن يكون IP هذا قابلاً للوصول.

----- رسالة أصلية -----

timothysc re: عكس DNS - ما هو DNS العكسي؟ مصدر- IP الخاص بـ
روابط؟ لا شيء من ذلك يعمل في kube. الاتصالات من خلال الخدمات
وكيل ، لذلك لا يعمل source-ip في المقام الأول (يمكن إصلاحه).

لا أعرف ZK - هل يمكنك شرح ما يحاولون تجاوزه بالعكس
DNS؟ يبدو أنه افتراض هش للغاية.

يوم الاثنين ، 9 آذار (مارس) 2015 الساعة 9:05 صباحًا ، تيموثي سانت كلير <
[email protected]>
كتب:

thockin https://github.com/thockin re: عكس DNS ، دعنا نلوح فقط
أيدينا حول ونعتبره شرطا.

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

أود نوعًا ما أن يتم إرفاق DNS بالخدمات الاسمية بدلاً من RC.

ما هي نقطة الألم مع المؤشرات البسيطة داخليًا؟ ف> 5000؟

----- رسالة أصلية -----

بعيدًا عني أن أسبح في اتجاه التيار - إذا كانت هناك تطبيقات كافية تتوقع حقًا أن يقوم DNS بذلك
تعمل بهذه الطريقة ، يمكننا جعلها تعمل بهذه الطريقة.

رسم:

يؤدي إنشاء وحدة تحكم النسخ R إلى إنشاء اسم DNS "$ R.rc" وهو ملف
تجمع جراب IPs "ضمن" ذلك RC. كل جراب P يحصل على اسم DNS
"$ P. $ R.rc". BUt ما هو P؟ يمكن أن تكون مؤشرات بسيطة ، ولكن هذا صحيح
عضتنا بشدة داخليا. يمكن أن تكون سلاسل عشوائية مثل GenerateName ،
لكن يجب عليهم البقاء على قيد الحياة بعد موت / إعادة تشغيل البود (وربما يجب على أسماء مضيفي البودات
مباراة؟).

يوم الثلاثاء ، 10 مارس 2015 ، الساعة 7:59 صباحًا ، Clayton Coleman [email protected]
كتب:

أعتقد أن تجربتي (وربما تيم) هي أن غالبية التجمعات العنقودية
يتوقع البرنامج اليوم ما يلي:

• كل عقدة لها هوية مستقرة
• هذه الهوية هي اسم DNS
• لا يجب أن يكون عنوان IP الخاص بالهوية الأساسية مستقرًا
• تتوقع العقدة تعريف نفسها للعقد الأخرى إما من خلال ثباتها
  الهوية (DNS) أو عنوان IP العام الخاص بها
• تتوقع بعض البرامج المجمعة عنوان IP الخاص بالعقدة للعميل
  يصل إليه لمطابقة عنوان IP يمكنه الإعلان عن نفسه للآخرين في
  الكتلة ومن أجل أن يكون IP هذا قابلاً للوصول.

----- رسالة أصلية -----

timothysc re: عكس DNS - ما هو DNS العكسي؟ مصدر- IP الخاص بـ
روابط؟ لا شيء من ذلك يعمل في kube. الاتصالات من خلال الخدمات
وكيل ، لذلك لا يعمل source-ip في المقام الأول (يمكن إصلاحه).

لا أعرف ZK - هل يمكنك شرح ما يحاولون تجاوزه بالعكس
DNS؟ يبدو أنه افتراض هش للغاية.

يوم الاثنين ، 9 آذار (مارس) 2015 الساعة 9:05 صباحًا ، تيموثي سانت كلير <
[email protected]>
كتب:

thockin https://github.com/thockin re: عكس DNS ، دعنا نلوح فقط
أيدينا حول ونعتبره شرطا.

سوف ينكسر ZK بدونه ، وكذلك العديد من الأنظمة الموزعة الأخرى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 لكبار الشخصيات بغلاف خاص 1: 1. أعتقد أن هذه ستكون حالة شائعة.

ما زلت قلقًا بشأن تغيير تعيينات DNS ديناميكيًا. أفضل طريقة لا تتطلب ذلك.

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

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

smarterclayton المؤشرات البسيطة ليست مشكلة بسبب الحجم. إنه بسبب النموذج. انظر تعليقاتي منذ بضع دقائق. المؤشرات البسيطة هي السبيل للذهاب إذا كان من الممكن تخصيصها بشكل مستقل ديناميكيًا عن هوية pod و RC.

بالنظر إلى أن إحدى المشكلات تكمن في الافتراضات الموجهة نحو النظام ، فهل هناك شيء يمكن أن يفعله Linux لنا هنا؟ على سبيل المثال ، هل يمكننا إنشاء عنوان IP مستعار أو شيء ما في حاوية خدمة VIP؟

مرحبا شباب،

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

يوم الثلاثاء ، 10 مارس 2015 ، الساعة 3:56 مساءً ، Brian Grant [email protected]
كتب:

بالنظر إلى أن إحدى المشكلات تتعلق بالافتراضات الموجهة نحو النظام ، فهناك
شيء يمكن أن يفعله لينكس لنا هنا؟ على سبيل المثال ، هل يمكننا إنشاء IP
الاسم المستعار أو شيء من هذا القبيل في الحاوية لخدمة VIP؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

سأخرج من جيبي في اليومين المقبلين - الأسبوع المقبل هو كذلك.

في 10 آذار (مارس) 2015 ، الساعة 11:33 مساءً ، كتب Tim Hockin [email protected] :

مرحبا شباب،

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

يوم الثلاثاء ، 10 مارس 2015 ، الساعة 3:56 مساءً ، Brian Grant [email protected]
كتب:

بالنظر إلى أن إحدى المشكلات تتعلق بالافتراضات الموجهة نحو النظام ، فهناك
شيء يمكن أن يفعله لينكس لنا هنا؟ على سبيل المثال ، هل يمكننا إنشاء IP
الاسم المستعار أو شيء من هذا القبيل في الحاوية لخدمة VIP؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

+1 للأسبوع القادم ، ربما جلسة Hangout.

بدس هذا الموضوع مرة أخرى بسبب ظهور مواضيع ذات صلة (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417 ، https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 ، https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147، # 6393).

1. كيف نقوم بتعيين هويات الشبكة (أسماء DNS و / أو عناوين IP) للقرون الفردية ، والتي قد تكون مفردة أو جزءًا من مجموعة اسمية؟
2. كيف ننقل الهوية إلى حاويات داخل جراب؟

هل يجب علينا تحديد موعد جلسة Hangout ، أو استخدام جلسة Hangout أسبوعية للمجتمع؟

أيضًا https://github.com/openshift/mongodb/pull/14 حيث بدأنا في وضع نموذج أولي لما سيكون عليه النمط العام لتهيئة مجموعة العضوية (شيء يمكننا وضعه في حاوية أو مكتبة أو ...)

تضمين التغريدة

----- رسالة أصلية -----

بدس هذا الموضوع مرة أخرى بسبب ظهور مواضيع ذات صلة
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417 ،
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902 ،
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147 ،

6393).

1. كيف نقوم بتعيين هويات الشبكة (أسماء DNS و / أو عناوين IP) إلى
   القرون الفردية ، والتي قد تكون مفردة أو جزء من مجموعة اسمية؟
2. كيف ننقل الهوية إلى حاويات داخل جراب؟

هل يجب علينا تحديد موعد جلسة Hangout ، أو استخدام جلسة Hangout أسبوعية للمجتمع؟

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC ، أحد أجزاء هذا اللغز هو الاختيار الرئيسي رقم 1542.

نعم ، لقد ناقشنا ذلك. بالنسبة لمعظم المجموعات التي يمكنها القيام بالعضوية الانتخابية الخاصة بها ، تكون العضوية الانتخابية هي الأهم (اكتشاف العضوية من نقاط نهاية Kube ، تنطبق على الكتلة) ، ولكن هناك دائمًا طرق مختلفة للتعامل معها. على سبيل المثال ، تستخدم Cassandra أساسًا Kube كمصدر خارجي للحقيقة للعضوية ، لذا فهي SEP وهذا يجعل انتخاب القيادة أسهل. على الرغم من أنني أؤمن بالاعتماد على كيفية تأخر الأعضاء ، فقد ينتهي بك الأمر بقسم إذا سقطت العضوية.

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

لاحظ أن مشكلة توصيل عنوان IP للخدمة إلى حاوية تشبه توصيل عنوان IP خارجي إلى جهاز افتراضي: https://cloud.google.com/compute/docs/networking. تقوم GCE بترجمة العناوين الخارجية من / إلى العناوين الداخلية ، ويتم توصيل العناوين الخارجية عبر خادم البيانات الوصفية: http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS مشابه: http://169.254.169.254/latest/meta-data/public-ipv4 .

smarterclayton لقد قمت بتحديث نموذج mongo الأولي للعلاقات العامة: https://github.com/openshift/mongodb/pull/17

يتم الآن استخدام Pod طلقة واحدة لتهيئة النسخة المتماثلة

إعادة. ربط هذه الآلية بوحدة تحكم النسخ / الجزء:

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

فكرة تجمع الرموز تبدو رائعة. أعتقد فقط أنه يجب فصله عن المنسقين المقيمين.

يمكن أن يقترن هذا بوحدة تحكم ذات مستوى أعلى ، إذا أردنا إضافة واحدة. سوف نعلق أكثر على # 1743 و / أو # 503.

لا ينبغي أن يقترن هذا حقًا بـ DeploymentController المقترح في # 1743. لن ينجح ذلك مع سيناريو العديد من مسارات الإصدار المستقلة ، ولا في الحالة التي يريد فيها شخص ما التحكم في طرحه باستخدام آلية مختلفة ، مثل التحديث المتداول بتبديل الأسماء المقترح. لأسباب مماثلة ، لن أقوم بربط أسماء DNS بأسماء كائنات pod / RC / DC.

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

لتسهيل توصيل الهوية وصولاً إلى الحاويات الموجودة في الحاوية (على سبيل المثال ، عن طريق استبدال var. الذي تمت مناقشته في # 2316) ، سيكون من المفيد تعيين حقل على الحاوية عند تعيين / عدم تعيين الدور ، عبر مصدر فرعي. يمكن أن يعالج ذلك أيضًا مشكلة المتانة.

يجب أن نحتفظ بمساحة في مخطط DNS للمثيلات الاسمية - # 6666.

يمكنني شراء أنه يمكننا تجربة استخدام pod IPs وإعادة تعيين DNS فقط للمثيلات الاسمية ، لكل https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406.

أيضًا ، قمت بإزالة هذا من الإصدار 1.0 في فبراير (على الرغم من عدم وجود خريطة الطريق. md) ، لكن المناقشة في # 6393 تشير إلى أنه يمكن إضافتها مرة أخرى.

مقترح بواسطة thockin :
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

نعم ، سيجعل "من أنا" أمرًا سهلاً حقًا عبر أدوات الاسم القياسية.

في 10 أبريل 2015 ، الساعة 8:11 مساءً ، كتب Brian Grant [email protected] :

مقترح بواسطة thockin :
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

/يشترك

لست متأكدًا من فهمي للمتطلبات هنا بعد الآن.

هناك علاقة متأصلة من N إلى M بين الخدمات والقرون ، من خلال
تصميم النظام. تتوقع أشياء مثل DNS العكسي عمومًا الحصول على ملف
إجابة واحدة: بالنظر إلى IP الخاص بجراب ، احصل على اسم أساسي. كل وثيقة مكتوبة
حول DNS يقول "لا تقم بإرجاع سجلات عكسية متعددة". منذ جراب يمكن أن يكون
في خدمات N ، لا يمكن أن تكون هذه الاستجابة الفردية متعلقة بالخدمة حقًا. نحن
يمكن إجراء بحث عكسي عن اسم متعارف عليه ثم بحث TXT عن ذلك
اسم "ما هي الخدمات التي تقدمها" ، ولكن من الصعب الحفاظ عليها وهو كذلك
في الأساس بروتوكول مخصص على أي حال.

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

لذا فأنا لست متأكدًا مما نريد فعله بهذا ، باستثناء تحديد العدد
من الخدمات يمكن أن يكون الكبسولة "أقل" ، الأمر الذي يبدو مروعًا.

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

يمكننا الذهاب إلى أقصى الحدود وإعداد قواعد iptables على كبسولات SNAT / DNAT في ملف
حتى يتمكنوا جميعًا من رؤية بعضهم البعض على الشخصيات المهمة. على سبيل المثال ، مجموعة من القرون
(P1، P2، P3) سيحصلون على شخصيات مهمة (V1، V2، V3). سوف حركة المرور من P1 إلى V2
يبدو أنها قادمة من V1 ، إلخ. يمكن للعملاء الوصول إلى V {1،2،3}. ولكن ماذا
هل هذا يحل المشكلة حقا؟ إنه يعطي عناوين IP مستقرة ولكن ليس هذا ملف
مشكلة عامة لخدمات مقطوعة الرأس في كل مكان؟

يوم الثلاثاء ، 21 نيسان (أبريل) 2015 الساعة 2:17 مساءً ، ديفيد أوبنهايمر < [email protected]

كتب:

/يشترك

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

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

على سبيل المثال ، يحتوي zookeeper على هوية لكل عقدة. يجب أن تظل هذه الهوية مستقرة في عضوية الكتلة - يمكن أن يكون هناك جرابان يعتقدان أنهما مضيف 1 ، ولكن إذا اختفى host1 لا يمكن لـ host435 استبداله. قد يكون هناك قرص ثابت معاد استخدامه لهذا الكبسولة التي تنتقل من مكان إلى آخر ، ولكن عندما تفعل ذلك ، يجب أن تكون البود قادرة على تحديد تلك الهوية. لكننا بحاجة إلى طريقة لتعيين ذلك #.

أظن أن الطريقة التي أفكر بها في الخدمات الاسمية تدور دائمًا حول تمكين البرامج الحالية بعضوية صغيرة (3/5/7) ، وليست حالة استخدام متعددة المئات مرنة تمامًا. ربما يتعين علينا فصل حالة الاستخدام هذه عن هذه المناقشة.

في 22 أبريل 2015 ، الساعة 1:59 صباحًا ، كتب Tim Hockin [email protected] :

لست متأكدًا من فهمي للمتطلبات هنا بعد الآن.

هناك علاقة متأصلة من N إلى M بين الخدمات والقرون ، من خلال
تصميم النظام. تتوقع أشياء مثل DNS العكسي عمومًا الحصول على ملف
إجابة واحدة: بالنظر إلى IP الخاص بجراب ، احصل على اسم أساسي. كل وثيقة مكتوبة
حول DNS يقول "لا تقم بإرجاع سجلات عكسية متعددة". منذ جراب يمكن أن يكون
في خدمات N ، لا يمكن أن تكون هذه الاستجابة الفردية متعلقة بالخدمة حقًا. نحن
يمكن إجراء بحث عكسي عن اسم متعارف عليه ثم بحث TXT عن ذلك
اسم "ما هي الخدمات التي تقدمها" ، ولكن من الصعب الحفاظ عليها وهو كذلك
في الأساس بروتوكول مخصص على أي حال.

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

لذا فأنا لست متأكدًا مما نريد فعله بهذا ، باستثناء تحديد العدد
من الخدمات يمكن أن يكون الكبسولة "أقل" ، الأمر الذي يبدو مروعًا.

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

يمكننا الذهاب إلى أقصى الحدود وإعداد قواعد iptables على كبسولات SNAT / DNAT في ملف
حتى يتمكنوا جميعًا من رؤية بعضهم البعض على الشخصيات المهمة. على سبيل المثال ، مجموعة من القرون
(P1، P2، P3) سيحصلون على شخصيات مهمة (V1، V2، V3). سوف حركة المرور من P1 إلى V2
يبدو أنها قادمة من V1 ، إلخ. يمكن للعملاء الوصول إلى V {1،2،3}. ولكن ماذا
هل هذا يحل المشكلة حقا؟ إنه يعطي عناوين IP مستقرة ولكن ليس هذا ملف
مشكلة عامة لخدمات مقطوعة الرأس في كل مكان؟

يوم الثلاثاء ، 21 نيسان (أبريل) 2015 الساعة 2:17 مساءً ، ديفيد أوبنهايمر < [email protected]

كتب:

/يشترك

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

يمكن لنوع من وحدات التحكم تعيين / إلغاء تعيين بعض الحقول على الكبسولات ديناميكيًا. لا يمكن الخلط بينه وبين هوية البود ولا RC. ربط هوية الشبكة بهويات pod أو RC معطل تمامًا.

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

هناك عدد من قيود DNS التي نرغب في المضي قدمًا فيها على المدى الطويل (إبطال ذاكرة التخزين المؤقت ، ودعم الاقتراع الطويل ، وما إلى ذلك). ربما تكون سجلات PTR المتعددة مجرد عنصر آخر تمت إضافته إلى تلك القائمة.

البديل الآخر هو أنه يمكننا إعطاء عنوان IP للخدمة لكل مجموعة من الخدمة الاسمية ثم حل المشكلات التي تنشأ.

----- رسالة أصلية -----

يمكن لنوع من وحدات التحكم تعيين / إلغاء تعيين بعض الحقول على الكبسولات ديناميكيًا. هو - هي
فقط لا يمكن دمجها مع هوية البود أو RC. ربط هوية الشبكة
هويات pod أو RC مكسورة تمامًا.

لن أحاول إجراء بحث عكسي عن DNS يعمل بشكل عادي أو مقطوع الرأس
الخدمات ، ولا أعتقد أنه من غير المعقول فرض حد أقصى واحد رمزي
service per pod - والتي لا يجب أن تحد من أنواع الخدمات الأخرى في
الكل.

هناك عدد من قيود DNS التي نرغب في دفعها على المدى الطويل
(إبطال ذاكرة التخزين المؤقت ، ودعم الاقتراع الطويل ، وما إلى ذلك). سجلات PTR متعددة
ربما يكون مجرد عنصر آخر تمت إضافته إلى تلك القائمة.

البديل الآخر هو أنه يمكننا تقديم عنوان IP للخدمة لكل مجموعة من ملفات
خدمة رمزية ثم حل المشاكل التي تخلق.

تتوقع الكثير من هذه الخدمات أن عنوان IP الذي لديهم (اسمه) يحل إلى عنوان IP الذي يتصلون به - لذلك إذا اتصلوا بـ X على 172.1.1.1 ، فإن X تعتقد أن رقمه 172.1.1.1. هذا ليس كل البرامج ، ولكن بعضها. عادة ما يكون اسم DNS على الرغم من ذلك ، مما يعني أن IP يمكن أن يتغير تحته.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

أخشى أن هذا كله لا يزال مجرّدًا بعض الشيء بالنسبة لي.

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

هذا ليس شرطا. إنه غامض للغاية بحيث لا يمكن تطبيقه.

على سبيل المثال ، يحتوي zookeeper على هوية لكل عقدة. يجب أن تبقى تلك الهوية
مستقرة في عضوية الكتلة

ما هي الهوية؟ عنوان IP؟ تم تمرير علامة سلسلة إلى البرنامج؟
و env فار؟ كيف تتعلم عملية zk ما هي هويتها؟

يمكن لنوع من وحدات التحكم تعيين / إلغاء تعيين بعض الحقول على الكبسولات ديناميكيًا

والذي سيؤدي إلى إعادة تشغيل تلك البودات ، ولا يزال لا يجيب على
سؤال ما هي الحقول ، وما هي القيم ، وما هو المنطق لإخبار الكبسولة؟

يمكن أن أرى شيئًا مثل توسيع التعليقات التوضيحية إلى أعلام سطر الأوامر
(كما نناقش مع env vars) أو فقط في env vars. على سبيل المثال
المراقب يكتب التعليقات التوضيحية ["zookeeper.com/index"] = 9 ، نقوم بالتحويل
$ .metatdata ["zookeeper.com/index"] إلى ZK_INDEX env. لكني أفعل هذا
لأعلى ، لم أر أي مطالب ملموسة تقول بالضبط ما هو zookeeper (أو
أيا كان) الحاجة.

لا أعتقد أنه من غير المعقول فرض خدمة رمزية واحدة كحد أقصى
لكل جراب

أعتقد أنه سيكون من الصعب تنفيذ مثل هذه القيود. النظام كذلك
مقترنة بشكل فضفاض وغير متزامن أن فرض هذه الحدود قد يكون أسوأ من
فقط حل المشاكل.

يمكننا إعطاء IP خدمة لكل جراب من الخدمة الاسمية

هذا هو المكان الذي بدأنا فيه ، لكن ...

يتوقع الكثير من هذه الخدمات أن عنوان IP لديهم (اسمهم)
يحل إلى IP الذي يتصلون به - لذلك إذا اتصلوا بـ X على 172.1.1.1 ،
ثم يعتقد X أنه 172.1.1.

لا ترضي عناوين IP الخاصة بالخدمة هذا ، إلا إذا قمنا بشيء أكثر تعمقًا مثل
ذكرت مع SNAT / DNAT. وحتى في ذلك عيوب حقيقية.

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

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

يوم الأربعاء 22 أبريل 2015 الساعة 10:12 صباحًا ، Clayton Coleman [email protected]
كتب:

----- رسالة أصلية -----

يمكن لبعض أنواع وحدات التحكم تعيين / إلغاء تعيين بعض الحقول بشكل ديناميكي
القرون. هو - هي
فقط لا يمكن دمجها مع هوية البود أو RC. ربط الشبكة
هوية
هويات pod أو RC مكسورة تمامًا.

لن أحاول إجراء بحث عكسي عن DNS يعمل بشكل عادي أو مقطوع الرأس
الخدمات ، ولا أعتقد أنه من غير المعقول فرض حد أقصى واحد
اسمى، صورى شكلى، بالاسم فقط
service per pod - والتي لا يجب أن تحد من أنواع الخدمات الأخرى في
الكل.

هناك عدد من قيود DNS التي نرغب في المضي قدمًا فيها على المدى الطويل
يركض
(إبطال ذاكرة التخزين المؤقت ، ودعم الاقتراع الطويل ، وما إلى ذلك). متعددة PTR
السجلات
ربما يكون مجرد عنصر آخر تمت إضافته إلى تلك القائمة.

البديل الآخر هو أنه يمكننا تقديم عنوان IP للخدمة لكل مجموعة من ملفات
خدمة رمزية ثم حل المشاكل التي تخلق.

يتوقع الكثير من هذه الخدمات أن يتم حل عنوان IP لديهم (اسمهم)
إلى عنوان IP الذي يتصلون به - لذلك إذا اتصلوا بـ X على 172.1.1.1 ، فعندئذٍ X
يعتقد أن 172.1.1.1. هذا ليس كل البرامج ، ولكن بعضها. عادة ما يكون
على الرغم من اسم DNS ، مما يعني أنه يمكن تغيير IP تحته.

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

معظم الأمثلة متعددة المنافذ عبارة عن أنظمة مجمعة. فمثلا:
ZK : اسم مضيف قابل للحل أو عنوان IP في ملف تكوين ، بالإضافة إلى "معرف" (على سبيل المثال ، فهرس: 1 ، 2 ، 3 ، ...) في ملف

يجب أن ننظر أيضًا في بعض قواعد البيانات.

كل ما نقوم به لن يعمل من أجل كل شيء. نحن فقط بحاجة للعثور على المكان المناسب.

----- رسالة أصلية -----

أخشى أن هذا كله لا يزال مجرّدًا بعض الشيء بالنسبة لي.

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

هذا ليس شرطا. إنه غامض للغاية بحيث لا يمكن تطبيقه.

على سبيل المثال ، يحتوي zookeeper على هوية لكل عقدة. يجب أن تبقى تلك الهوية
مستقرة في عضوية الكتلة

ما هي الهوية؟ عنوان IP؟ تم تمرير علامة سلسلة إلى البرنامج؟
و env فار؟ كيف تتعلم عملية zk ما هي هويتها؟

يمكن لنوع من وحدات التحكم تعيين / إلغاء تعيين بعض الحقول على الكبسولات ديناميكيًا

والذي سيؤدي إلى إعادة تشغيل تلك البودات ، ولا يزال لا يجيب على
سؤال ما هي الحقول ، وما هي القيم ، وما هو المنطق لإخبار الكبسولة؟

يمكن أن أرى شيئًا مثل توسيع التعليقات التوضيحية إلى أعلام سطر الأوامر
(كما نناقش مع env vars) أو فقط في env vars. على سبيل المثال
المراقب يكتب التعليقات التوضيحية ["zookeeper.com/index"] = 9 ، نقوم بالتحويل
$ .metatdata ["zookeeper.com/index"] إلى ZK_INDEX env. لكني أفعل هذا
لأعلى ، لم أر أي مطالب ملموسة تقول بالضبط ما هو zookeeper (أو
أيا كان) الحاجة.

لا أعتقد أنه من غير المعقول فرض خدمة رمزية واحدة كحد أقصى
لكل جراب

أعتقد أنه سيكون من الصعب تنفيذ مثل هذه القيود. النظام كذلك
مقترنة بشكل فضفاض وغير متزامن أن فرض هذه الحدود قد يكون أسوأ من
فقط حل المشاكل.

يمكننا إعطاء IP خدمة لكل جراب من الخدمة الاسمية

هذا هو المكان الذي بدأنا فيه ، لكن ...

يتوقع الكثير من هذه الخدمات أن عنوان IP لديهم (اسمهم)
يحل إلى IP الذي يتصلون به - لذلك إذا اتصلوا بـ X على 172.1.1.1 ،
ثم يعتقد X أنه 172.1.1.

لا ترضي عناوين IP الخاصة بالخدمة هذا ، إلا إذا قمنا بشيء أكثر تعمقًا مثل
ذكرت مع SNAT / DNAT. وحتى في ذلك عيوب حقيقية.

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

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

أعتقد أن هذا أمر حكيم ، يجب أن نخصص الوقت على وجه التحديد لحل مجموعة من الأمثلة المعروفة. لدينا 3 من جانبنا يمكننا الاستفادة منها للحصول على أمثلة ملموسة (مجموعة نسخ MongoDB ، Zookeeper ، Mysql Master / Slave) بالإضافة إلى الأمثلة الموجودة في kube / الأمثلة. ربما جلسة عمل لتجزئة العناصر ، ووضع حدود للمشاكل غير القابلة للحل ، وتحديد ما تبقى.

اقترح تغيير اسم هذه الميزة حيث يمكن استخدامها أيضًا للوظائف المجمعة لتعيين رقم معرف جزء.

الوظائف المجمعة لها متطلبات مختلفة إلى حد ما ، لذلك أود أن أبقيها منفصلة.

مثال على zookeeper: https://github.com/openshift/origin/pull/1965

مثال على احتياجات ish الاسمية للخدمة https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

أنا في حيرة من أمري لماذا لا يزال الاتجاه غير واضح هنا - لا سيما من موظفي Google. تدير Google خدمات ذات حالة جيدة في ظل Borg لسنوات عديدة ، ومن الواضح تمامًا ما هو مطلوب لهذا النوع من عبء العمل:

• معرّف ثابت يمثل الكبسولة الحالية من مجموعة "الأجزاء" (النسخ المتماثلة غير المتطابقة) (في borg ، هذا هو "رقم المهمة" - عدد صحيح بسيط). يجب أن يظل هذا المعرف ثابتًا عبر عمليات إعادة جدولة / إعادة تشغيل الكبسولة.
• طريقة لتعداد جميع أجزاء "النظير" والاتصال بها ، ربما باستخدام معرفاتهم الثابتة بطريقة ما (في borg ، هذه بادئة ممتلئة مع رقم المهمة)

.. وانتهينا.

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

يمكن تزوير هذا الآن عن طريق إنشاء خدمة / منفذ فريد لكل جزء وتشغيل وحدة تحكم النسخ المتماثل مع النسخ المتماثلة: 1 ولكن من غير المناسب إدارة عدد كبير من القطع "يدويًا" مثل هذا.

قد تكون الطريقة الطبيعية لتنفيذ ذلك في kubernetes هي:

• تحصل البودات على متغيرات بيئة إضافية تعطي فهرس القطع الخاص بها (عدد صحيح) وإجمالي عدد القطع (أو ربما تنقلها عبر واجهة برمجة التطبيقات المتجه نحو الأسفل؟).
• تحصل وحدات التحكم في النسخ المتماثل على عدد "الأجزاء" (الافتراضي: 1) ، ويتم إعادة تفسير "النسخ المتماثلة" لتعني "النسخ المتماثلة داخل كل جزء" (الافتراضي: 1). عند تقليص مجموعة النسخ المتماثلة ، يجب أن تقتل من النهاية (للإبقاء على مؤشرات الشظايا متجاورة). لاحظ أن تغيير "القطع" سيتطلب إعادة تشغيل متدحرجة للقرون التي يتم التحكم فيها لتحديث var var "إجمالي القطع" (جيد ، لا تريد أن يحدث ذلك على الفور).
• تحصل الخدمات على عدد "أجزاء" مشابه يعين نطاقًا متجاورًا من المنافذ إلى المحدد العادي بالإضافة إلى محدد "فهرس جزء" ضمني.
• يمكن للقرون العثور على شظايا أخرى باستخدام SERVICE_PORT (أو متغير env جديد؟) + إزاحة فهرس الأجزاء.

لاحظ ما ورد أعلاه يتدهور بأمان إلى السلوك الحالي عندما تكون القطع = 1.

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

كما ذكرت سابقًا ، يرتبط هذا ارتباطًا وثيقًا بما يتعين علينا القيام به لدعم الوظائف المجمعة مع مهام العمل الثابتة (ما كنت أسميه "النوع 1" هنا: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142)

الميزات الأخرى التي نحتاج إلى مواءمتها إذا قمنا بتغيير RC (أو أضفنا شيئًا جديدًا) هي كيف يتناسب النشر ، على وجه التحديد:

كيف أقوم بتحديث مستمر إلى:

1. RC منتظم
2. متحكم بيرنودي
3. جهاز تحكم عن بعد مجزأ
4. وظيفة دفعة؟

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

----- رسالة أصلية -----

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

كما ذكرت سابقًا ، يرتبط هذا ارتباطًا وثيقًا بما يتعين علينا القيام به
دعم المهام المجمعة مع تعيين العمل الثابت (ما كنت أسميه "النوع 1"
هنا:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

لقد اخترنا عدم إعطاء الأولوية لهذا (وقمنا تلقائيًا بإنشاء مطالبات حجم ثابتة) لـ 1.0 نظرًا لوجود العديد من الحلول البديلة ، مثل إنشاء خدمة واحدة و RC والمطالبة المستمرة بالحجم لكل مثيل.

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

وحدة تحكم لكل عقدة / برنامج خفي: نقطة جيدة. تعتبر الفهارس المعينة بكثافة نموذجًا سيئًا لهذه الحالة. ماذا تفعل عندما تختفي عقدة بشكل دائم ، على سبيل المثال؟ تصبح المؤشرات متفرقة. أوصي بأننا لا ندعم ذلك.

وظائف الدُفعات: كما تمت مناقشته في # 1624 ، نرغب في تعيين الفهارس بناءً على الإكمالات ، وليس البودات قيد التشغيل حاليًا.

كما نوقش أعلاه ، يجب أن يأخذ تعيين الفهرس في الاعتبار التخزين المرتبط ، مثل مطالبات وحدة التخزين الثابتة - تنبع الهوية من هوية الشبكة (اسم DNS و / أو عنوان IP) والتخزين.

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

هناك 3 بدائل للتعيين:

1. مهمة المنتسب مع نوع خاص من الخدمة. الخدمة لديها بالضبط النطاق الصحيح. (سنحتاج أيضًا في النهاية إلى خدمات إقليمية.) سيكون هذا نوعًا من الهجين بين الخدمات العادية والخدمات مقطوعة الرأس. هذا ما تخيلته عندما اقترحت هذه الآلية في الأصل. سيتم تسجيل المهمة في نقاط النهاية. ستكون نقاط النهاية و / أو DNS التي تشبه نظام أسماء النطاقات مقطوعة الرأس هي الطرق الواضحة لتعداد جميع الأقران.
2. أنشئ نوعًا جديدًا من العناصر مشابهًا للخدمة ، ولكن للخدمات الاسمية فقط. من المحتمل أن نحتاج إلى كائن جديد لتسجيل المهمة أيضًا. هذا من شأنه أن يوسع سطح API الخاص بنا دون داع ، IMO.
3. "اسحب" بدلاً من "ادفع". تمت جدولة البودات للمضيفين بدون وحدة تحكم صريحة ، حتى مع قيود العقدة (المحدد) أو إحدى آليات مكافحة التقارب المقترحة (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). هذا مشابه أيضًا لتخصيص خدمة VIP. يمكننا أن نفعل شيئًا مشابهًا للخدمات الاسمية. سيحدد pod (أو قالب pod) تجمع الفهرس الذي يريد تعيين فهرس منه. على عكس الخدمات العامة ، لا نتوقع أن تحتاج البودات إلى تخصيص مؤشرات متعددة من مجموعات مختلفة. سيتم تسجيل المهمة في مواصفات جراب.
4. الإيجابيات: أبسط للمستخدمين. لا يتطلب شيئًا آخر. يسمح بتعيين من قبل المستخدمين.
5. السلبيات: تختلف عن أنواع الخدمات الأخرى.

من الناحية المثالية ، ستستخدم مهمة PVC نفس النموذج.

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

اعتبارات أخرى:

1. كيفية إيصال الفهرس / الهوية للأقران. DNS هو الجواب الواضح.
2. كيفية توصيل الفهرس / الهوية للحاويات الموجودة في الكبسولة. متغيرات البيئة ، DNS العكسي ، ... لن يتغير الفهرس المعين ديناميكيًا ، على الرغم من أنه قد يتم تغيير ربط DNS بينما لا يزال البود موجودًا. أرغب في اختيار آلية تتوقع التطبيقات بالفعل أن تعمل في بيئات أخرى ، وكما هو الحال مع مناقشة واجهة برمجة التطبيقات (API) الأوسع نطاقًا (# 386) ، لا أريد ربط التطبيقات بمتغيرات البيئة الخاصة بـ Kubernetes ، ولكن EnvVarSource الجديد و env var استبدال (# 7936) من شأنه أن يساعد في تجنب ذلك.

أنا لا أتفق مع بعض ما قلته ، لكن دعنا ننتظر لمواصلة هذا النقاش حتى ما بعد الإصدار 1.0.

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

مثال على حالة الاستخدام هو موازن تحميل nginx الذي يشير إلى هذه المجموعات من القرون بواسطة أسماء المجال. لذلك عندما تأتي الكبسولات وتذهب ، من المتوقع دائمًا أن يتم إصلاح أسماء النطاقات من xxx-0001 إلى xxx-000N.

ravigadde يرجى قراءة تعليقي الأخير على هذه المشكلة: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

ركض في هذه المشكلة أثناء محاولة إعداد حاوية RabbitMQ. يعتمد استمرار Rabbit على اسم المضيف ، لذا فإن وجود أسماء مضيف متغيرة يعني أنك تفقد قاعدة بيانات Mnesia عند إعادة تشغيل الحاوية.

حاولت المعالجة باستخدام تكوين الصورة (اسم المضيف مباشرة والأرنب) ومتغيرات ENV وواجهة برمجة التطبيقات لأسفل. لم يكن قادرًا على حل المشكلة - لا يزال Rabbit يلتقط اسم Pod الذي تم إنشاؤه. الحل مؤقتًا بالتبديل من استخدام وحدة تحكم النسخ المتماثل وفقًا لاقتراحmikedanese .

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

يقوم RabbitMQ بتسمية دليل قاعدة البيانات باستخدام اسم المضيف الحالي للنظام. إذا تغير اسم المضيف ، يتم إنشاء قاعدة بيانات فارغة جديدة. لتجنب فقدان البيانات ، من الضروري إعداد اسم مضيف ثابت وقابل للحل.

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

أو عند بدء التشغيل قم بربط مسار اسم المضيف بموقع ثابت

في 11 تموز (يوليو) 2015 ، الساعة 5:26 مساءً ، كتب Mike Danese [email protected] :

إذا فهمت بشكل صحيح ، فإن جراب rabbitmq (تم إنشاؤه باستخدام نسخة متماثلة
تحكم) في الأرنب كليري
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
المثال سيفقد البيانات عند فشل pod حتى إذا تم تخزين البيانات على ملف
قرص دائم. من rabbitmq doc:

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

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

هذا مثال على سبب عدم اشتقاق اسم المضيف من اسم البود - # 4825

لإعطاء هذه ركلة بسيطة:

هناك العديد من المشكلات الأساسية التي يجب حلها:

1. تحتاج بعض المكونات إلى هوية فريدة لكل جراب مرتبط بتخزينها على القرص
   
   
   
   1. لمزيد من التجاعيد ، يحتاج بعض هؤلاء (حارس الحديقة في بعض الحالات) إلى أن يكون اسم المضيف قابلاً للحل ومطابقة
   
   
2. تحتاج بعض المكونات التي تم تحجيمها إلى تخزين دائم يختلف لكل جراب (تشير القرون إلى PVCs التي تختلف لكل جراب ، مرتبطة بالهوية مرة أخرى)
   
   
   
   1. في بعض الأحيان يجب إنشاء هذه الأحجام عند الطلب عند توسيع نطاقها
   
   
   2. في بعض الأحيان يجب إعادة استخدام هذه الأحجام من المسبح وليس إعادة إنشائها
   
   
3. قد تتسع بعض المكونات لعشرات الآلاف من الحالات ، حيث يصبح تتبع الهويات الفردية المخصصة أمرًا غير عملي
   
   
   
   1. من المحتمل أن تكون غالبية الاستخدامات للاسمية ما بين 2 إلى 7 مثيلات من البود (معظم قواعد البيانات القابلة للتطوير الحالية ، ومعظم الإعدادات المشتركة متعددة البرامج الرئيسية)
   
   
4. لا ترغب بعض المكونات في تنفيذ الانتخابات الرئيسية الخاصة بها ، ولكن دع النظام الأساسي يدير ذلك من خلال جعل إحدى الهويات عشوائية (تصبح الهوية 1 هي الهوية الرئيسية)
5. عندما نحل هذه المشكلات ، سيظل المستخدمون بحاجة إلى إجراء تغييرات على البودات (عبر عمليات النشر) والتأكد من الاحتفاظ بأي هوية أو إعادة تخصيصها.

لا تحتاج جميعها بالضرورة إلى حلها بنفس الحل. على سبيل المثال ، أعتقد أن هناك فرقًا كبيرًا بين هوية الكتلة صغيرة الحجم (2-7) وهوية الكتلة واسعة النطاق (> 7). على سبيل المثال ، في الحالة الكبيرة ، يكون هذا البرنامج أقل اهتمامًا بالفجوات ، أو يحتوي على بروتوكول توافق / عضوية قائم. في الحالة الصغيرة ، يحتاج البرنامج إلى مزيد من المساعدة في تحديد الهوية. سأفصل هذه البرامج إلى مجموعة سحابية أصلية (> 7) وبرامج مجمعة قائمة (2-7).

أوافق على 1 أ و 1 ب و 2 أ. يبدو 2b كمشكلة مختلفة ، على الرغم من أنه ربما يمكن للحل إعادة استخدام نفس النمط.

أعتقد أن المقياس (3) يشير بشكل أساسي إلى أن الحل البديل لخدمة واحدة و RC لكل مثيل ليس مناسبًا ، على الرغم من أنني أتفق مع التمييز بين السحابة الأصلية مقابل لا.

يمكن معالجة الانتخابات الرئيسية (4) بشكل منفصل.

نتفق أيضًا مع (5).

أعتقد أن معظم متطلبات التصميم واضحة في هذه المرحلة.

أسئلة التصميم المتبقية:

1. تخصيص الشخصيات المهمة أو السماح بتغيير عناوين IP؟ يرتبط هذا ارتباطًا وثيقًا بما إذا كانت الحاويات بحاجة إلى أن تكون قادرة على اكتشاف عناوين IP الخاصة بها عبر Linux أم لا ، حيث لا يمكن اكتشاف الشخصيات المهمة حاليًا عبر النظام. أفترض أنهم بحاجة إلى أن يكونوا قادرين على اكتشاف عناوين IP الخاصة بهم ، لكن يمكنهم استخدام واجهة برمجة التطبيقات لأسفل ، كما هو الحال مع pod IP (# 12595). السماح بتغيير عناوين IP (بسبب استخدام pod IPs) يعني حدًا لمعدل تغيير IP ، بسبب DNS TTLs والتخزين المؤقت "bugs". في مرحلة ما ، نعتزم أيضًا جعل pod IPs قابلة للترحيل ، على الرغم من (# 3949) ، لذلك لن يكون تغيير عناوين IP إلى الأبد.

ثانيًا. الدفع (إلى القرون) مقابل السحب (من القرون). يتم ربط الخدمات والمنسقين المقيمين بشكل فضفاض عن قصد بالبودات ، وبالتالي يستخدم كلاهما نموذج "الدفع". ستكون الخدمات الاسمية مرتبطة ارتباطًا جوهريًا بهوية الكبسولة (وإن لم يكن ذلك بشكل دائم - يجب أن تكون البودات قابلة للاستبدال). وبالتالي ، أرى حافزًا أقل لنموذج الدفع. حالات التخصيص الأخرى ، مثل الجدولة ، و esp. الربط الحصري ، مثل مطالبات الحجم الثابتة للأحجام الدائمة ، استخدم نموذج request / ack ، المعروف أيضًا باسم "pull". هذا هو النموذج الذي أفضله حاليًا للخدمات الاسمية.

أي شخص لديه آراء حول (أنا)؟

الانتخابات الرئيسية هي # 1542 ، وتتم مناقشتها كجزء من تنفيذ HA (على سبيل المثال ، # 12884).

لا أعرف ماذا تقصد بالدفع والجذب.

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

أنا أبدأ بالبديهية القائلة بأنه بمجرد تشغيل الكبسولة ، لا يمكنك حقًا
تغيير جراب قيد التشغيل. هناك بعض الاستثناءات لهذا (على سبيل المثال الظاهري
محتويات نظام الملفات) ولكن الأشياء التي يبدو أنها مهمة (env vars ، IP ،
hostname) تتعثر مع كل ما تبدأ به.

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

سأقوم فقط بعمل تيار من الوعي وأرى ما لا ينتن.

الفكرة 1: ThingPools and patches.

حدد كائنًا جديدًا لواجهة برمجة التطبيقات أو شيء يتيح لك تحديد مجموعة من
أشياء. ما هو الشيء؟ الشيء هو عبارة عن سلسلة (أو ربما كائن JSON blob)
له نوع معدود. يمكنك إنشاء مجموعة من الأشياء وتلك الأشياء
لك لاستخدامها. تشمل أنواع الأشياء VUIDs (أسماء المضيف) ، والسلاسل ، وكبار الشخصيات.

حدد بنية API جديدة يمكن تمريرها لإنشاء العمليات - أ
تصحيح. التصحيح هو تعليمات حول كيفية تصحيح الكائن الموجود
خلقت. أحد خيارات التصحيح هو "تخصيص من ThingPool".

لتجميع هذه الأشياء معًا:

حدد ThingPool {meatadata.name: my-quorum-hostnames، type: VUID،
autogenerate: 5،} // ينشئ مجموعة من 5 VUIDs صالحة

تحديد RC {النسخ المتماثلة: 5 ...}

في إنشاء RC (POST) ، أرسل أيضًا تصحيحًا: {what:
"podTemplate.spec.containers [*]. metadata.VUID" ، التجمع: "my-quorum-hostnames"
}

ستطبق عملية POST التصحيح على RC - تخصيص VUID واحد
لكل حاوية من ThingPool. في أي وقت يتم فيه قتل الكبسولة وإعادة إنشائها ،
يتم إرجاع VUID إلى التجمع وستحصل عليه الحجرة التالية التي سيتم تشغيلها.

يمكنك استخدام هذا لتوليد مجموعة من السلاسل ("0" إلى "99") والعصا
هؤلاء في var. يمكنك استخدام هذا لتخصيص مجموعة من الشخصيات المهمة و
ثم قم بتعيين هؤلاء الشخصيات المهمة إلى الكبسولات (ستكون ميزة جديدة - البود المتين
عناوين IP - لست متأكدًا من كيفية قياس ذلك :) يمكنك إنشاء مجموعة من
أسماء PersistentVolumeClaim وتصحيح حجم المطالبة الذي يستخدمه كل جراب.

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

فكرة 2: تحديد مجموعة من القرون. لا تتظاهر بأنها خدمة. إنه أقرب
إلى Borg Job. إنه يشبه RC لكنه يعين ترتيبًا عاديًا للقرون عليه
الضوابط - أرقام الأجزاء. يتحكم في مجموعة VUIDs (لكننا لا نريد ذلك
اسم المضيف ليكون شيئًا يمكن للمستخدمين تعيينه ، هممم ...).

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

في الثلاثاء ، 18 آب (أغسطس) 2015 الساعة 7:28 مساءً ، أرسل بريان غرانت إخطارات @github.com
كتب:

أوافق على 1 أ و 1 ب و 2 أ. ومع ذلك ، يبدو أن 2b مشكلة مختلفة
ربما يمكن للحل إعادة استخدام نفس النمط.

أعتقد أن المقياس (3) يشير بشكل أساسي إلى أن الحل البديل لخدمة واحدة و
RC لكل مثيل ليس مناسبًا ، على الرغم من أنني أتفق مع التمييز بين
السحابة الأصلية في مقابل لا.

يمكن معالجة الانتخابات الرئيسية (4) بشكل منفصل.

نتفق أيضًا مع (5).

أعتقد أن معظم متطلبات التصميم واضحة في هذه المرحلة.

أسئلة التصميم المتبقية:

1. تخصيص الشخصيات المهمة أو السماح بتغيير عناوين IP؟ يرتبط ارتباطًا وثيقًا بهذا ما إذا كان
يجب أن تكون الحاويات قادرة على اكتشاف عناوين IP الخاصة بها عبر Linux أم لا ،
نظرًا لأنه لا يمكن اكتشاف الشخصيات المهمة حاليًا عبر النظام. أفترض أنهم يفعلون ذلك
يجب أن تكون قادرًا على اكتشاف عناوين IP الخاصة بهم ، ولكن يمكنهم استخدام واجهة برمجة التطبيقات لأسفل ، مثل
مع pod IP (# 12595 https://github.com/kubernetes/kubernetes/pull/12595).
السماح بتغيير عناوين IP (بسبب استخدام pod IPs) يعني حدًا للمعدل
من تغيير عنوان IP ، بسبب TTLs و "أخطاء" التخزين المؤقت. في مرحلة ما ، نحن
تنوي أيضًا جعل pod IPs قابلة للترحيل ، على الرغم من (# 3949
https://github.com/kubernetes/kubernetes/issues/3949) ، لذا قم بتغيير عناوين IP
لن يكون إلى الأبد.

ثانيًا. الدفع (إلى القرون) مقابل السحب (من القرون). الخدمات والمنسقين المقيمين
يقترن عن قصد بالقرون ، وبالتالي يستخدم كلاهما "الدفع"
نموذج. ستكون الخدمات الاسمية مرتبطة ارتباطًا جوهريًا بهوية الكبسولة
(وإن لم يكن بشكل دائم - يجب استبدال القرون). وبالتالي فهمت
أقل دافعًا لنموذج الدفع. حالات التخصيص الأخرى ، مثل
الجدولة ، و esp. الربط الحصري ، مثل مطالبات الحجم الثابتة لـ
الأحجام الثابتة ، استخدم نموذج الطلب / ack ، المعروف أيضًا باسم "السحب". هذا هو حاليا
النموذج الذي أفضله للخدمات الاسمية.

أي شخص لديه آراء حول (أنا)؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

ربما لم أقصد حقًا إتقان الانتخابات كما تفكر بها - أكثر من ذلك
عند إنشاء وظائف حيث تحتاج مجموعة من الحالات إلى التهيئة
(بدون تنسيق صريح) امتلاك المثال الذي يعتقد أنه
عادة ما يكون التحدث "1" إلى البودات الأخرى كافيًا لتمهيد كتلة. ان
المثال هو mongodb حيث تحتاج إلى بدء مجموعة النسخ المتماثلة - إذا كانت القرون
التي تعتقد أنها تبدأ "2" أو "3" ، يمكنك الحصول عليها في الحالات التي تكون فيها
بدء الانقسام. لكن "1" يمكن أن تبدأ بأمان في كل مرة ، وبعد ذلك
حاول إضافة الأعضاء الآخرين (الذين لديهم حالة ثابتة يمكنهم استخدامها
تحديد ما إذا كانوا بالفعل جزءًا من كتلة). يعتمد على
الضمانات التي توفرها خدمة الهوية التي قد لا تحصل عليها في الواقع
ناجحًا ، ولكن ليس عليك إنشاء جراب منفصل بالخارج لـ
تهيئة خدمتك (على الرغم من أن هذا ليس فظيعًا أيضًا).

يوم الثلاثاء ، 18 أغسطس 2015 الساعة 11:59 مساءً ، Brian Grant [email protected]
كتب:

انتخاب ماجستير # 1542
https://github.com/kubernetes/kubernetes/issues/1542 ، ويجري
تمت مناقشته كجزء من تنفيذ HA (على سبيل المثال ، # 12884
https://github.com/kubernetes/kubernetes/pull/12884).

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

smarterclayton إنه جانب لمشكلة الخدمات الاسمية ، لكن ليس من الآمن التمهيد كما تصفه. إذا تمت إعادة تشغيل "1" على جهاز جديد وحدث أنه غير قادر على الوصول إلى العقد الحالية ، فسيتم إعادة تمهيد التشغيل ، والآن لديك اثنين من mongodb يزعمان أنهما موثوقان. تحتاج إلى تغيير تعريف الوظيفة لإزالة القدرة على التمهيد بعد اكتمال التمهيد.

كما قد يشير thockin إلى ذلك ، أعتقد أننا

أرى حالتين مختلفتين تمامًا موصوفتين أعلاه - تختلفان حسب مصدر الحقيقة:

_ وصفي: _ "أريد تشغيل الأجزاء N ، وإذا كان هناك أكثر أو أقل من ذلك ، فقم بإجراء التغييرات لإعادتها إلى N."
_ وصفي: _ "أريد الاكتشاف التلقائي لجميع الأجزاء المتاحة ، واسمحوا لي أن أكتشف بطريقة ما عندما تأتي وتذهب."

أعتقد أن هذه مختلفة ويجب وصفها بشكل مختلف (على الرغم من أنها قد تقدم بيانات وصفية مماثلة لبودات التشغيل الفعلية).

وقد تضمنت المناقشة أيضًا تسييج الموارد وضمانات الوصول الفردي. Afaics ، الحالة _only_ حيث يجب القيام بذلك داخل k8s هي تركيب وحدات تخزين ثابتة بعيدة (لأن تركيب fs يجب أن يتم خارج الحاوية) ، وهذا سهل جدًا عن طريق أقفال etcd إذا لم تكن خدمة وحدة التخزين البعيدة الأساسية ' ر بالفعل توفير سياج داخليا. يمكن التعامل مع جميع الحالات الأخرى بواسطة وظائف المستخدم بأنفسهم ، باستخدام خدمة القفل الموزع (أو الوصول إلى الخدمات التي توفر القفل داخليًا). إن مطالبة الوظائف بتنفيذ الإقفال الخاص بها يفتح جميع أنواع الأنماط (المهمة الثابتة ، والتخصيص الانتهازي ، و "قطع الغيار الساخنة" ، إلخ) واستراتيجيات عدم القدرة على الوصول / الاسترداد (الفشل الصعب ، والاستمرار مع آخر شيء ، وما إلى ذلك).

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

فقط للتذكير: يوجد عدد كبير من المنافذ خلف VIP واحد. أوافق على أننا لا نريد ترحيل عناوين IP لأن ذلك يبدو صعبًا على الشبكة الأساسية على نطاق واسع ، ومن الصعب على الشبكة التعامل مع التكرارات المؤقتة أثناء حالات حافة الفشل / الاسترداد. ومع ذلك ، أعتقد أنه من الممكن تمامًا تعيين منفذ خدمة فريد لكل عضو جزء وبيانات وكيل لكل مثيل جراب - حتى بالنسبة للوظائف الكبيرة جدًا. (يفترض هذا الاقتراح أن الوكلاء لا يزالون هو الاتجاه الذي نريد أن نسير فيه مع k8s - لم أواكب أي نقاش حديث حول هذا المجال)

بالدفع ، قصدت أن موردًا آخر ، مثل خدمة أو وحدة تحكم ، سيراقب مجموعات من البودات عبر محدد الملصقات ويمنح "أشياء" (أسماء DNS قابلة للحل ، وكبار الشخصيات ، و PVCs) عليها.

عن طريق السحب ، كنت أعني أن الكبسولة ستطلب صراحة تخصيص "شيء" ، والذي سيكون مرتبطًا به بعد ذلك عبر شيء مثل / ملزم.

فيما يتعلق بتغيير البودات قيد التشغيل: يختلف تغيير البودات بعد الإنشاء عن تغيير البودات ذات الحاويات قيد التشغيل. المجدول ينفذ غير متزامن. التهيئة ، على سبيل المثال. تم تعيين PodIP في وقت متأخر أيضًا. تمت مناقشته بشكل عام في # 3585.

فيما يتعلق بما إذا كانت هذه "خدمة" حقًا أم لا:

• يجب تخصيص الأشياء عبر مجموعات من البودات
• الشيء (على سبيل المثال ، أسماء DNS) يجب ألا يكون مرتبطًا جوهريًا باسم مورد البود
• يجب أن يكون الشيء قابلاً للتحويل من حجرة إلى أخرى
• يحتاج الكبسولة إلى "معرفة" (أو أن تكون قادرًا على اكتشاف من خلال واجهة برمجة التطبيقات (API) لأسفل) ما هو الشيء الذي تم تعيينه له (خاصة اسم DNS و VIP).
• هناك شيء واحد نحتاج إلى دعمه وهو DNS القابل للحل
• كان سؤالي الوحيد المهم ما إذا كنا بحاجة إلى كبار الشخصيات. أنا بخير مع عدم استخدام الشخصيات المهمة.
• إنه ليس مثاليًا ، ولكن يمكن للمستخدم إنشاء خدمة ثانية بدون رأس تستهدف المجموعة الكاملة لاكتشاف الأقران عبر DNS و / أو نقاط النهاية.

الفكرة (1) ، ThingPools + Patches هي فكرة مثيرة للاهتمام. أود أن أصفه بأنه نهج "جذب". ThingPool ليست سيئة ، لكني قلق من أن التصحيحات سيكون من الصعب استخدامها ، ولا أرغب في إجراء هندسة عكسية للمعلومات الدلالية من التصحيحات داخل النظام لتوفير سلوك مقبول حول دورة حياة التخزين ، وما إلى ذلك. د تفضل شيئًا خاصًا بالمجال. أيضًا ، لن تعمل ThingPools المستقلة لأسماء DNS و PVCs ، حيث يجب تخصيصها بشكل مشترك.

أصف الفكرة (2) على أنها نهج "دفع". لا أرغب في تكرار العمل على المنسقين المقيمين وعمليات النشر ، لذلك لا ينبغي أن نقدم وحدة تحكم أخرى في البودات. قد يكون المحيل على ما يرام ، لكنه يقترن بشكل فضفاض أكثر من اللازم ولا يتطابق مع سابقة لكيفية تعاملنا مع المهمة.

إعادة. حشو المعلومات في env vars: حدث هذا بالنسبة إلى Job أيضًا. أرغب في حشو المعلومات في تعليق توضيحي وتوسيع واجهة برمجة التطبيقات لأسفل حتى أتمكن من طلب تعليقات توضيحية محددة. أريد الاستمرار في السماح للمستخدمين بطلب المعلومات التي يحتاجون إليها فقط واختيار أسماء env var.

إعادة. تعيين منافذ مختلفة لكل حالة: لن يعمل ذلك مع العديد من التطبيقات القديمة ، كما أنه غير متوافق مع تصميم نظامنا.

إعادة. توجيهي: الحفاظ على تشغيل N هو ما يفعله ReplicationController.

إعادة. وصفي: هذه خدمات مقطوعة الرأس موجودة بالفعل.

إعادة. القفل: نعم ، هذه هي واجهة برمجة تطبيقات التأجير الجارية.

تتم مناقشة توفير التخزين في # 6773 (دفع) و # 12450 (سحب).

لقد فات الأوان الآن ، لكنني سأحاول بطريقة ما تخصيص وقت لتقديم اقتراح بعد قليل من النوم.

ملاحظة سريعة: خدمات مقطوعة الرأس لا تخصص لكبار الشخصيات

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

وقضايا التخزين المحلي الدائم ذات صلة: # 7562 ، # 1515 ، # 598

المزيد من التحديثات السريعة حيث أقوم في الغالب بمراجعات العلاقات العامة الأخرى:

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

إعادة. التخصيص / التعيين: أريد تجنب إضافة المزيد من أنواع القوالب إلى ReplicationController و Deployment و Daemon وما إلى ذلك ، وأريد أن يكون التخزين والأسماء قادرين على الترحيل عبر وحدات التحكم بسهولة عبر البودات (إذا كان هذا ما يريده المستخدم).

في 19 آب (أغسطس) 2015 ، الساعة 1:04 صباحًا ، كتب Angus Lees [email protected] :

smarterclayton https://github.com/smarterclayton إنه جانبا لملف
مشكلة في الخدمات الاسمية ، ولكن ليس من الآمن التمهيد كما أنت
وصف. إذا تم إعادة تشغيل "1" على جهاز جديد وحدث أنه غير قادر
للوصول إلى العقد الحالية ، ستتم إعادة تمهيد التشغيل والآن لديك اثنين
يدعي mongodb أنه موثوق. تحتاج إلى تغيير الوظيفة
تعريف لإزالة القدرة على التمهيد بعد التمهيد هو
إكمال.

من الممكن تمامًا أن يحدث تداخل في هذه الحالة - ولكن في معظم الحالات
الحالات التي نتحدث عنها عن التخزين الدائم بأقفال حتى تتمكن من حظرها
على أي حال إلى أن أصدرت gce / AWS سياجك وكنت قادرًا على إرفاقه. لذا
أنت تضحي بالتوافر على bootstrapping ولكن ليس بالضرورة في وقت التشغيل
(ما لم تكن على مساحة تخزين غير مسورة ، وفي هذه الحالة أوافق على أن هذا لن يكون كذلك
آمنة)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

في 19 آب (أغسطس) 2015 ، الساعة 1:35 صباحًا ، كتب Angus Lees [email protected] :

كما أعتقد أن https://github.com/thockin قد يشير إلى ذلك
نحن نخلط هنا بلا داع بين عدة ميزات متشابهة ولكن مختلفة

• ونقوم بتضمين أكثر مما هو ضروري تمامًا على مستوى k8s.

أرى حالتين مختلفتين تمامًا موصوفتين أعلاه - تختلفان حسب المصدر
الحقيقة:

_ وصفي: _ "أريد تشغيل N أجزاء ، وإذا كان هناك أكثر أو أقل
من ذلك ، ثم قم بإجراء تغييرات لإعادته إلى N. "
_وصفيًا: _ "أريد الاكتشاف التلقائي لجميع الأجزاء المتاحة و
اسمحوا لي أن أكتشف بطريقة ما عندما يأتون ويذهبون ".

أعتقد أن هذه مختلفة ويجب وصفها بشكل مختلف (على الرغم من

قد يقدمون بيانات وصفية مماثلة للقرون قيد التشغيل الفعلية).

وقد اشتملت المناقشة أيضًا على سياج الموارد والوصول الفردي
ضمانات. Afaics ، الحالة _only_ حيث يلزم القيام بذلك داخل k8s
يقوم (afaics) بتركيب وحدات تخزين بعيدة - لأنه يجب القيام بتثبيت fs
خارج الحاوية. يمكن التعامل مع جميع الحالات الأخرى بواسطة وظائف المستخدم
أنفسهم ، باستخدام خدمة القفل الموزعة (أو الوصول إلى الخدمات التي
توفير القفل داخليا). يطلب من الوظائف القيام بفتح القفل الخاص بهم
حتى جميع أنواع الأنماط (التخصيص الثابت ، التخصيص الانتهازي ، "الساخن
قطع الغيار "، وما إلى ذلك) واستراتيجيات عدم القدرة على الوصول / الاسترداد (الفشل الذريع ،
تابع-بآخر-معروف ، إلخ).

أقترح نقل طلب ميزة سياج الموارد العامة للخروج من هذا
bug (ونطبق سياجًا ببساطة من خلال توفير وصفة للتشغيل
مختلف خدمات القفل الموزعة على k8s دون مزيد من المشاركة من قبل
k8s نفسها).

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

فقط للتذكير: يوجد عدد كبير من المنافذ خلف VIP واحد. أوافق نحن
لا تريد ترحيل عناوين IP لأن ذلك يبدو صعبًا على الشبكة الأساسية
على نطاق واسع ، ومن الصعب على الشبكة التعامل مع التكرارات المؤقتة
أثناء حالات حافة الفشل / الاسترداد. ومع ذلك ، أعتقد أنه _هو_ ممكن تمامًا
لتعيين منفذ خدمة فريد لكل عضو جزء وبيانات وكيل لكل منها
مثيل pod - حتى بالنسبة للوظائف الكبيرة جدًا. (هذا الاقتراح يفترض أن
لا يزال الوكلاء هم الاتجاه الذي نريد أن نسير فيه مع k8s - لم أواصل ذلك
مع أي مناقشة حديثة حول هذه المنطقة)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

تحريف طفيف لفكرة ThingPool + Patchesthockin:

النموذج: قائمة الموارد + المعلمات والاستبدال. راجع https://github.com/openshift/origin/blob/master/pkg/template/api/types.go للحصول على الإلهام. كود # 503 ، # 1743 ، # 4210 ، # 6487.

TemplatePool. في الأساس ThingPool. يُنشئ مثيلات مفهرسة بشكل مكثف للقالب عند الطلب بدلاً من عدد النسخ المتماثلة.

من أجل المتعة / الاتساق: يمكن لـ v2 ReplicationController نسخ قوالب عشوائية بدلاً من البودات فقط. المرجع # 170 (نوع من). ربما ليس ضروريًا إذا كان كل التخصيص مدفوعًا بتكرار pod.

سيكون البديل الرئيسي شيئًا أكثر تحديدًا بالمجال ، ويركز على اسم المضيف وتجمعات PVC ، ولكن لن تعمل مجموعات منفصلة لكل منها. يجب أن يكون التجمع الفردي قادرًا على تخصيص مجموعات من أسماء المضيف و (من المحتمل أن تكون متعددة) PVC. تتمثل إحدى ميزات TemplatePool في أنه يمكن لأي شخص استخدامه لتخصيص خدمة واحدة (ربما خارجية) لكل نسخة متماثلة ، وأتمتة حل Zookeeper الحالي. لا أعرف ما إذا كانت هناك موارد أخرى قد يرغب شخص ما في تكرارها بشكل مشابه 1 إلى 1 مع البودات ، ولكن بالنظر إلى المعدل الذي تنمو به واجهة برمجة التطبيقات الخاصة بنا ، فلن أراهن على عدم وجودها.

smarterclayton لمعلوماتك عندما

نعم ، هناك خطأ ما في gmail + github + iPhones.

يوم الخميس ، 20 آب (أغسطس) 2015 ، الساعة 2:24 مساءً ، برين جرانت [email protected]
كتب:

smarterclayton https://github.com/smarterclayton لمعلوماتك عند الرد
عبر البريد الإلكتروني مع التعليقات المضمنة ، تكون ردودك غير قابلة للقراءة ، سواء في
gmail وعلى جيثب. في gmail ، لا توجد فواصل أسطر وفي جيثب هناك
ليست بادئات اقتباس ، لذلك يصعب نقاش إجابتك بصرف النظر عن ملف
يتم اقتباس النص.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

أجرينا محادثة سريعة اليوم ، بعض النقاط البارزة:

تحدثت عن فئات التطبيقات الثلاثة:

• التطبيقات التي هي تطبيقات ويب عديمة الحالة (تعمل فقط مع RCs)
• تطبيقات ذات مقياس عملاق تستخدم أساتذة خارجية ولديها تماسك قائم
  بروتوكولات (كاساندرا ، إنفينيباند) للتعامل مع الإجماع
• البرامج المجمعة ذات الحالة الصغيرة مثل Mongodb و rethinkdb و volt و etcd
  مجموعات zookeeper و riak و redis التي تحتاج إلى بعض الأنماط لتعمل بشكل جيد
  
  
  
  • هوية فريدة (عادة)
  
  
  • وحدة تخزين فريدة ثابتة لكل مثيل يتم إعادة استخدامها (عادةً)
  
  
  • عنوان IP الثابت أو اسم DNS (بشكل شائع) - عادةً ما يكون اسم DNS هو
    
    يقف لعنوان IP مستقر
  
  
  • اسم مضيف مستقر (نادرًا)
  
  

اليوم ، يمكنك حل الهوية الفريدة والحجم الثابت من خلال امتلاك N
وحدات تحكم النسخ ، عنوان IP ثابت مع خدمات N. نحن نريد أو نحب
لعدم طلب N RC والخدمات لبعض حالات الاستخدام هذه.

تحدثنا عن اقتراحات تيم وبريان ، بدون ترتيب معين:

• يمثل TemplatePool مشكلة لأن الناسخ يحتاج إلى الامتداد
  سلطة إنشاء كائنات عبر الكتلة بأكملها ، ويجب أن تعرف
  حيث كل نقطة نهاية API.
  
  
  
  • يمكن أن يكون لديك نقطة نهاية نموذج إنشاء مثيل ، ولكن لا تزال بحاجة إلى ذلك
    
    حل مشكلة تفويض السلطة (مع حسابات الخدمة؟)
  
  
  • تحديد موقع الأشياء وتقييد الإذن هي أشياء طويلة الأجل
  
  
• "هوية الحجرة" الملقب بالحقل vuid الذي تحدثنا عنه - تم تقديم الحجة
  واتفقوا عمومًا على أنه لا يحتاج إلى أن يكون فريدًا عالميًا فقط
  فريد داخل المجال الذي يتوقع الكبسولة استخدامه.
  
  
  
  • يمكن لمخصص الفهرس الافتراضي (قليل أو كثيف) تعيين هذه القيمة
    
    بعد الإنشاء ، ويمكن أن تنتظر kubelet لبدء القرون حتى تحصل على ملف
    
    الهوية (قد تحتاج للإشارة إلى أنهم ينتظرون واحدة)
  
  
  • الفهارس الكثيفة مفيدة بشكل عام للأشياء البسيطة ، ولكن بسبب ذلك
    
    هو إنشاء ما بعد وفصله عن kubelet يمكن أن يكون مختلفًا
    
    أنواع خوارزميات التخصيص (عدد كثيف ، حلقة تجزئة متسقة ،
    
    عشوائي ، إلخ)
  
  
• تبدو القوالب البسيطة على الكبسولات مكانًا جيدًا للبدء ، لكننا نحتاج إلى ذلك
  لجعلها متوافقة مع سلسلة الأدوات الحالية لدينا بطريقة لا تفعل ذلك
  كسرها تماما
  
  
  
  • استخدم حقل الهوية لتصميم نماذج الحقول الأخرى
  
  
• أضف حقل اسم مضيف على مواصفات الحجرة التي يمكن للمستخدمين تعيينها بأنفسهم و
  حدد المعلمات مع الهوية
• السماح لخدمة بدون رأس بالرد على استفسارات نظام أسماء النطاقات لنقاط النهاية من خلال
  الهوية (اجعل وحدة التحكم في نقاط النهاية تتحقق من الهوية من الكبسولة
  في نقاط النهاية) التي تضمن بعض الاستقرار
• السماح بطريقة ما بتحديد معلمات مطالبات الحجم الثابتة أو تغييرها إلى
  السحب من مجموعة (أو لديك وحدة تحكم في المسبح ، وتأكد من وجود وحدة تخزين واحدة لكل
  الهوية ، أو اجعل المتحكم في الهوية يستمد من التجمعات) ، يحتاج إلى التفكير
• تحتاج إلى أدوات تجعل من السهل تحويل البيئة / واجهة برمجة التطبيقات لأسفل إلى
  ملفات التكوين (متعامدة ، لكن يجب أن تكون أسهل)
• لا تزال هناك بعض المخاوف بشأن هذا النمط

يوم الخميس ، 20 أغسطس 2015 الساعة 3:34 مساءً ، كلايتون كولمان [email protected]
كتب:

نعم ، هناك خطأ ما في gmail + github + iPhones.

يوم الخميس ، 20 آب (أغسطس) 2015 ، الساعة 2:24 مساءً ، برين جرانت [email protected]
كتب:

smarterclayton https://github.com/smarterclayton لمعلوماتك عند الرد
عبر البريد الإلكتروني مع التعليقات المضمنة ، تكون ردودك غير قابلة للقراءة ، سواء في
gmail وعلى جيثب. في gmail ، لا توجد فواصل أسطر وفي جيثب هناك
ليست بادئات اقتباس ، لذلك يصعب نقاش إجابتك بصرف النظر عن ملف
يتم اقتباس النص.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

كلايتون كولمان | مهندس رئيسي ، OpenShift

مشكلة أخرى: شهادات TLS لأعضاء الخدمات الاسمية

شهادات TLS للخدمات بشكل عام ستكون أيضًا شيئًا جيدًا (موقعة
من قبل الكتلة CA تلقائيًا عند الطلب).

في الخميس ، 20 آب (أغسطس) 2015 الساعة 5:19 مساءً ، كتب Brian Grant [email protected] :

مشكلة أخرى: شهادات TLS لأعضاء الخدمات الاسمية

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

كلايتون كولمان | مهندس رئيسي ، OpenShift

نعم: # 11725

إعادة:

• أضف حقل اسم مضيف على مواصفات الحجرة التي يمكن للمستخدمين تعيينها بأنفسهم و
  حدد المعلمات مع الهوية
• السماح لخدمة بدون رأس بالرد على استفسارات نظام أسماء النطاقات لنقاط النهاية من خلال
  الهوية (اجعل وحدة التحكم في نقاط النهاية تتحقق من الهوية من الكبسولة
  في نقاط النهاية) التي تضمن بعض الاستقرار

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

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

شيء مثل:

Hostname string
Subdomain string

أعلاه HostNetwork في PodSpec.

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

أعتقد أننا يجب أن نعيد الغرض من المشكلة رقم 4825 من أجل ذلك وأن نجعل شخصًا ما يعمل عليها. إنه أكثر صلابة بكثير وعمل أقل من البقية.

السماح بطريقة ما بتحديد معلمات مطالبات الحجم الثابتة أو تغييرها إلى
السحب من مجموعة (أو لديك وحدة تحكم في المسبح ، وتأكد من وجود وحدة تخزين واحدة لكل
الهوية ، أو اجعل المتحكم في الهوية يستمد من التجمعات) ، يحتاج إلى التفكير

أعتقد أن هناك شيئين حول الادعاءات يمكن أن يساعدا هنا:

1. قم بتغيير الربط من 1: 1 إلى 1: N
   
   
   
   1. pvc.Spec.VolumeName إلى pvc.Spec.VolumeNames [] كمرجع ملزم
   
   
2. pvc.Spec.Singelton منطقية تشير إلى ما إذا كان يجب ربط المطالبة مرة واحدة تمامًا للمشاركة أو السماح بربط المطالبة عدة مرات.

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

سيظل من المهم مطابقة الحجم الصحيح للحجرة اليمنى.

يجب أن يكون لديك خريطة الهويات لأسماء المجلد.

الجمعة، 21 أغسطس 2015 في 03:17، مارك Turansky [email protected]
كتب:

السماح بطريقة ما بتحديد معلمات مطالبات الحجم الثابتة أو تغييرها إلى
السحب من مجموعة (أو لديك وحدة تحكم في المسبح ، وتأكد من وجود وحدة تخزين واحدة لكل
الهوية ، أو اجعل المتحكم في الهوية يستمد من التجمعات) ، يحتاج إلى التفكير

أعتقد أن هناك شيئين حول الادعاءات يمكن أن يساعدا هنا:

1. قم بتغيير الربط من 1: 1 إلى 1: N
   
   
   
   1. pvc.Spec.VolumeName إلى pvc.Spec.VolumeNames [] باعتبارها الربط
      
      المرجعي
   
   
2. pvc.Spec.Singelton المنطقية التي تشير إلى ما إذا كان يجب أن تكون المطالبة ملزمة
   مرة واحدة بالضبط للمشاركة أو السماح للمطالبة بالالتزام عدة مرات.

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

سيظل من المهم مطابقة الحجم الصحيح للحجرة اليمنى.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

في الجمعة 21 آب (أغسطس) 2015 الساعة 12:56 صباحًا ، كتب Brian Grant [email protected] :

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

لنكن واضحين - إذا لم نقم بتعيين نطاق فرعي ، فلا يمكننا السماح للمستخدمين بتقديمه
أسماء المضيف الخاصة بهم. إذا قمنا بتعيين المجال الفرعي ، فعلينا القيام بذلك في a
بطريقة فريدة بما يكفي (في مساحة DNS ، والتي تعني حاليًا عبر
مساحة الاسم). جعل المجال الفرعي هو اسم الخدمة
فريد بما فيه الكفاية.

نظرًا لبعض قيود DNS (نطاق TLD واحد) ، هذا
يعني بشكل واقعي أننا نعطي المستخدمين حقلي DNS_LABEL - اسم المضيف
والمجموعة الاسمية. للحصول على مثال ملموس:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

سيؤدي هذا إلى رؤية الكبسولة:

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

وخدمة DNS لسجلات A و PTR مقابل foo.bar.my-app.nom.cluster.local

هذا مستوى أعمق من هيكل DNS الحالي ، لكنني أعتقد
النقاط الحالية لدينا = 5 تغطي هذا. بالتناوب ، يمكننا القول أن أ
مساحة الاسم هي اللقب ، ووضعه مرة أخرى على المستخدمين لتعيين فريد
أسماء المضيفين في مساحة الاسم. ستكون نتيجة DNS
foo.my-app.pod.cluster.local الذي يعكس الخدمات. يمكننا حتى
اجعلهم أكثر تشابهًا عن طريق إضافة حقل اسم مضيف اختياري إلى الخدمات.

سنقوم بتسليم DNS المستند إلى اسم المضيف فقط إذا كان النطاق الفرعي يطابق ذلك لـ
خدمة من النوع الصحيح. يمكننا أيضًا دمج الاثنين في حقل واحد.

أقل جزء مفضل لدي في هذا هو أن Pod يقول "أنا جزء
من خدمة "بار" (في المثال أعلاه).

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

أعتقد أننا يجب أن نعيد الغرض من المشكلة رقم 4825 من أجل ذلك وأن نجعل شخصًا ما يعمل عليها. إنه أكثر صلابة بكثير وعمل أقل من البقية.

إنه بالتأكيد شيء يمكن أن يبدأ على الفور ، ولكن (لهؤلاء
المتابعة في المنزل) إنها مجرد آلية لتنفيذ البود
الهوية ، وليس سياسة إدارة مجموعات الهويات.

في يوم الجمعة ، 21 آب (أغسطس) 2015 الساعة 3:17 مساءً ، كتب Mark Turansky [email protected] :

أعتقد أن هناك شيئين حول الادعاءات يمكن أن يساعدا هنا:

1. قم بتغيير الربط من 1: 1 إلى 1: N

هذا هو المكان الذي بدأت فيه ، لكن ...

يوم الجمعة ، 21 آب (أغسطس) 2015 الساعة 12:38 مساءً ، كلايتون كولمان
كتب [email protected] :

يجب أن يكون لديك خريطة الهويات لأسماء المجلد.

نعم. لقد تبين أن هذه مشكلة نموذجية.
سواء كنت تفكر في المشكلة على أنها "قالب جراب" فيه البعض
تحتوي الحقول على عناصر نائبة يتم ملؤها بواسطة "مجموعة استبدال"
مأخوذة من تجمع في وقت التشغيل أو تعتقد أنها جراب موحَّد بالكامل
المواصفات التي يتم "تصحيحها" باستخدام "مجموعة استبدال" مستمدة من مجموعة
في وقت التشغيل - فهي متشابهة وغير سارة بنفس القدر.

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

لدينا العديد من الأمثلة على الكبسولات التي تخضع لخدمتين أو ثلاث خدمات ، واحدة من أجل
الانتشار ، واحد للتعرض والآخر لاختبار التعرض.

فيما يتعلق بالهوية ، يجب أن يكون لكل جراب تم إنشاؤه بواسطة وحدة تحكم خفية هوية معينة مشتقة من هوية العقدة وهوية وحدة التحكم. قد تكون هذه حالة تكون فيها الهوية واضحة (pod x على المضيف y لها هوية f (y)) وجزء من مسؤولية daemons.

smarterclayton لذا فإن ومرتبة لأعضاء المجموعة. كيف يمكن أن يعمل ذلك عندما تكون الهوية مرتبطة بالعقدة التي سيتم جدولة الكبسولة عليها؟

وحدة تحكم Daemon _only_ لها هوية في سياق العقدة التي تكون pod
تشغيل. وحدات تحكم النسخ المتماثل والخدمات مختلفة. الشيطان
تقول وحدة التحكم "يجب أن يكون هناك واحد من هؤلاء يعمل على كل عقدة". هناك
هي ليست هوية أخرى يمكن أن تمتلكها الكبسولة باستثناء عقدتها.

يوم الجمعة ، 11 سبتمبر 2015 الساعة 1:13 صباحًا ، Angus Lees [email protected]
كتب:

smarterclayton https://github.com/smarterclayton لذا فهو شائع (لكن ليس
عام) هنا هو الحفاظ على قائمة ثابتة ومنظمة من المجموعات
أفراد. أعتقد أن هذا يعني أنه لا ينبغي ربط الهوية بـ
العقدة التي تصادف جدولة الكبسولة عليها.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

smarterclayton آه ، لقد تحولت هذه المشكلة بوضوح إلى شيء أكثر من طلب الميزة الأصلي - لقد فقدت ما كنت أحاول بنائه هنا ، لذا

عذرًا ، لم أقصد الإشارة إلى أن النقطة لم تكن ذات صلة. التحدي هو أننا بحاجة إلى تحديد المجموعات ونشرها في الكبسولة. نحتاج إلى أن يكون الكبسول متفاعلًا مع العضوية في المجموعة (حجم التحميل X الذي يطابق هوية الحجرة في المجموعة). هناك سؤال مفتوح - هل يمكن أن يكون الكبسولة عضوًا في مجموعتين في وقت واحد وله هوية فريدة في أي منهما؟

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

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

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

عندئذٍ يمكن أن تستخدم الأحجام الثابتة في الكبسولة PVCs بناءً على اسم الكبسولة. يمكن أن يضمن مجمع PVC وجود مطالبات كافية لمجموعة مراقبة من المنسقين المقيمين. يمكن لوحدة التحكم الخفية اختيار الأسماء الحتمية لاسم العقدة. يمكننا أيضًا توصيل أسماء DNS بأسماء pod في خدمة بناءً على بعض الأنماط.

هذا يبدو أكثر بخلًا من إضافة حقل هوية مميز على الكبسولة. هذا يعني أن القرون لا تزال ليست حيوانات أليفة ، ولكن يمكن أن تكون أسمائها (وهذا ليس بيانًا غير معقول). لا يمكننا منع تشغيل حالتين من نفس عملية pod على الكتلة في نفس الوقت ، ولكن يمكننا تقديم ضمان قوي (ونفعل) أن الاسم قيد الاستخدام فقط في مكان واحد اليوم.

يعني "مجموعة ملحوظة من الأسماء" أعلاه. سيكون DNS لنقطة النهاية هو hashpodname.ept.service.namespace.svc.cluster.local. لدينا بالفعل اسم الكبسولة على نقطة النهاية ، لذلك لا يتعين علينا إضافة أي شيء.

ذات الصلة بـ https://github.com/kubernetes/contrib/tree/master/service-loadbalancer الذي يقترح حل هذه المشكلة كتكرار تالٍ محتمل

لماذا نناقش DaemonSet هنا؟ تم حل ذلك بواسطة رقم 12893 ، IMO.

smarterclayton دعونا لا نعيد النظر في اشتقاق الهوية من أسماء https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

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

يبدو أن فائدة شيء مثل تجريد فهرس مهام Borg تستمر في الظهور _لحالات استخدام معينة _ وليس من الواضح بالنسبة لي سبب عدم قدرتنا على تقديمها كخيار.

DaemonSet لا أعتقد أنه يحل حالة تخزين نظام الملفات الموزعة
(Gluster) حيث يحتاج كل مضيف إلى هوية متسقة للانضمام مرة أخرى
الكتلة. سأحفر أكثر ولكن أعتقد أنه قد لا يزال بحاجة إلى شيء على طول
احتياجات # 260 - لا أعرف ما إذا كان اسم المضيف كافياً إذا أعدت التوصيل
قرص مضيف على مثيل جديد. ربما لم أفهم ما DaemonSet
المقدمة و # 12893 تم تسليمها ، لكن لا أعتقد أن هذه هي مشكلة ملف
مضيف النظام الذي يريد إعادة استخدام القرص.

يوم الأربعاء ، 16 سبتمبر ، 2015 الساعة 12:22 صباحًا ، Brian Grant [email protected]
كتب:

smarterclayton https://github.com/smarterclayton دعونا لا نعاود الزيارة
اشتقاق الهوية من أسماء الكبسولات ، ولا استخدام RCs لتعيين الهوية.
تمت مناقشة مشاكل هذه الأساليب هنا: # 260 (تعليق)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

كمثال ملموس ، تخيل مجموعة إلخ. لديها 7 مثيلات ، و 7
أحجام. أريد (من أجل الجدل) الأسماء والمجلدات الخ د -1
من خلال etcd-7 و etcd-pvc-1 من خلال etc-pvc-7.

النشر المتداول لديه MaxUnavailable 90٪ (أو ما يعادله) ، MaxSurge 0٪. هو - هي
لتقليص حجم RC القديم ، ورفع مستوى RC الجديد. RC القديم برشاقة
يحذف etcd-5. يختفي على الفور من مجموعة RC الفعالة. الجديد
يحاول RC إنشاء etcd-5 (من خلال ملاحظة الفجوة المحددة). يتلقى أ
"بالفعلExistsException". إنه يعامل ذلك على أنه تراجع واستعادة. ذات مرة
لقد ذهب etcd-5 حقًا ، إنه قادر على المضي قدمًا. بمجرد أن يصبح etcd-5 جاهزًا ، فإن DC
ينتقل إلى الخطوة التالية.

بالنسبة للبديل - تم تعيين الهوية على الكبسولة - يتم تصغير جهاز التحكم عن بعد القديم. أ
يتم إنشاء جراب جديد على الفور باسم جديد. لا يمكن تشغيل الكبسولة الجديدة
لأنه يحتاج إلى مجموعة هوية لمعرفة أي PVC يتم تركيبه من أجله
الصوت. يذهب إلى حلقة انتظار على Kubelet. المتحكم في الهوية
يشاهد بعض مجموعة محددات التسمية ويلاحظ أن الهوية etcd-5 ليست كذلك
المخصصة. يقوم بتعيين الهوية etcd-5 على الكبسولة الجديدة. يلاحظ الكوبيليت
هذا التغيير ومن ثم يمكنه معرفة PVC المراد تركيبه ، يبدأ الكبسولة
(بافتراض فصل الحجم عن العقدة الأخرى).

من الناحية الهيكلية ، هذه متشابهة جدًا. هذا الأخير يسمح بداية التداخل.
كلاهما يتطلب تعيين PVC.

يوم الأربعاء 16 سبتمبر 2015 الساعة 12:39 صباحًا ، كلايتون كولمان [email protected]
كتب:

DaemonSet لا أعتقد أنه يحل حالة تخزين نظام الملفات الموزعة
(Gluster) حيث يحتاج كل مضيف إلى هوية متسقة للانضمام مرة أخرى
الكتلة. سأحفر أكثر ولكن أعتقد أنه قد لا يزال بحاجة إلى شيء على طول
احتياجات # 260 - لا أعرف ما إذا كان اسم المضيف كافياً إذا أعدت التوصيل
قرص مضيف على مثيل جديد. ربما لم أفهم ما DaemonSet
المقدمة و # 12893 تم تسليمها ، لكن لا أعتقد أن هذه هي مشكلة ملف
مضيف النظام الذي يريد إعادة استخدام القرص.

يوم الأربعاء ، 16 سبتمبر ، 2015 الساعة 12:22 صباحًا ، Brian Grant [email protected]
كتب:

smarterclayton https://github.com/smarterclayton دعونا لا نعاود الزيارة
اشتقاق الهوية من أسماء الكبسولات ، ولا استخدام RCs لتعيين الهوية.
تمت مناقشة مشاكل هذه الأساليب هنا: # 260 (تعليق)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

كلايتون كولمان | مهندس رئيسي ، OpenShift

الشيء الذي يجعل هذه المشكلة صعبة ، بالنسبة لي ، ليس إنشاء مجموعة فريدة مستقرة من الأسماء أو استخدام مجموعة من PDs. المشكلة هي القيام بالاثنين في نفس الوقت. وإذا قمت بتوسيع ذلك ، فلماذا لا يتم تجميع أي معرّف في المواصفات بهذا الشكل؟

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

هذه القضية باقية وبقيت وأخشى أن يكون لدينا شلل تحليلي.

أتمنى أن يكون لدينا المزيد من الأمثلة لحالات استخدام التجميع الأخرى. اعتقدت جلستر
سيكون مختلفًا ولكنه مجرد متغير آخر في
cassandra / etcd / mongo / zookeeper "أريد إعادة استخدام مجلد وأحتاج إلى
تذكر من قلت إنني كنت من قبل ". لم يكن لدينا دور قائم على أساس (أنا
تريد أن تجعل أول N pods منسقي و M التالي عمال) مثال
للدعم.

يوم الأربعاء ، 16 سبتمبر ، 2015 الساعة 12:46 صباحًا ، Tim Hockin [email protected]
كتب:

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

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

لقد ظلت هذه القضية باقية وبقيت وأخشى أن يكون لدينا تحليل
شلل.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

الشيطان

12893 عيّن اسم مضيف pod على اسم مضيف العقدة عند استخدام شبكة مضيفة ، وهو أمر معقول تمامًا لاستخدامه لـ DaemonSet ، نظرًا لأن هؤلاء قد يستخدمون hostPort ، على أي حال.

أيضًا ، القصد من ذلك هو دمج DaemonSet مع وحدة تحكم العقدة من أجل توفير التسامح الضمني غير المحدود # 1574 ، ولتمكين "الجدولة" قبل تمكين الجدولة للعقد بشكل عام. قد يكون تحديد الأولويات الضمني معقولًا أيضًا.

بالنسبة لنظام التخزين العنقودي ، يمكنني تخيل توفير أقراص إضافية على كل مضيف يتم الوصول إليها عبر hostPath فقط بواسطة نظام التخزين - لن يتم استخدامها بواسطة Docker ولا بواسطة blankDir.

فيما يتعلق بالهوية ، لا أرى مشكلة في الاقتراح هنا: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

ظلت هذه المشكلة قائمة بشكل رئيسي بسبب عدم وجود أولوية كافية ، المنظمة البحرية الدولية.

للتحدث عن كلايتون (أو ربما لمجرد قول نفس الأشياء ولكن الغباء):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

المعنى الضمني هو أن RC (أو شيء ما) يدرك أن هذه مجموعة هوية ، ويعين فهرسًا من IdentPool ، ويخصص تلك الهوية لاسم pod ، ثم يطلع على الداخل لمعرفة ما إذا تم تعيين أي حقول أخرى تتمحور حول الهوية - الهوية الحجم في هذه الحالة.

إنه ليس عامًا تمامًا (لا يمكنك تجميع أي حقل عشوائي) ولكن يمكننا إضافة المزيد من خيارات التعرف على الهوية حسب الحاجة

لدي شعور بأنه إذا قمنا بتثبيت المواصفات التي أحببناها في هذا الأمر ، فقد يتم إنجازها عاجلاً وليس آجلاً.

حتى كتابة المواصفات تستغرق وقتًا.

فيما يتعلق بـ IdentityPool / VolumePool ، قررنا بالفعل منذ وقت طويل أن العديد من التجمعات لن تعمل.

الموعد النهائي لإكمال التعليمات البرمجية 1.1 هو يوم الجمعة. هل يمكننا من فضلك لا نفعل هذا الآن؟

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

أضع التصميم على الأقل على الإصدار 1.2 - مرشح.

آسف لم أكن واضحًا في الرسم التخطيطي الخاص بي - لدى RC (أو IC؟) مفهوم
التجمع الأساسي أو الفهرس. بمجرد تعيين جراب فهرس في IC ، هذا
يتم استخدام الفهرس للفهرسة في كافة الحقول التي تركز على التجمع.

إذا قمنا بتقسيم النموذج ، أفترض أن RC لا يمكنه ذلك
تحور القالب. هذا اصعب قليلا

أنا بخير للتوقف عن الحديث عن هذا الأسبوع. ظهرت للتو في بلدي
البريد الوارد وأنا كنت أمضغ هذه الفكرة ...

يوم الثلاثاء ، 15 سبتمبر 2015 الساعة 10:09 مساءً ، Brian Grant [email protected]
كتب:

حتى كتابة المواصفات تستغرق وقتًا.

فيما يتعلق IdentityPool / VolumePool ، قررنا بالفعل وقتًا طويلاً
قبل أن العديد من حمامات السباحة لن تعمل.

الموعد النهائي لإكمال التعليمات البرمجية 1.1 هو يوم الجمعة. هل يمكننا من فضلك لا نفعل هذا الآن؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

نعم ، كانت هناك أشياء فقط أثارت المناقشات من جانبنا.
مشاكل العملاء تنتظر عدم وجود عملية تحرير.

يوم الأربعاء 16 سبتمبر 2015 الساعة 1:14 صباحًا ، Tim Hockin [email protected]
كتب:

آسف لم أكن واضحًا في الرسم التخطيطي الخاص بي - لدى RC (أو IC؟) مفهوم
التجمع الأساسي أو الفهرس. بمجرد تعيين جراب فهرس في IC ، هذا
يتم استخدام الفهرس للفهرسة في كافة الحقول التي تركز على التجمع.

إذا قمنا بتقسيم النموذج ، أفترض أن RC لا يمكنه ذلك
تحور القالب. هذا اصعب قليلا

أنا بخير للتوقف عن الحديث عن هذا الأسبوع. ظهرت للتو في بلدي
البريد الوارد وأنا كنت أمضغ هذه الفكرة ...

يوم الثلاثاء ، 15 سبتمبر 2015 الساعة 10:09 مساءً ، Brian Grant [email protected]
كتب:

حتى كتابة المواصفات تستغرق وقتًا.

فيما يتعلق IdentityPool / VolumePool ، قررنا بالفعل وقتًا طويلاً
قبل أن العديد من حمامات السباحة لن تعمل.

الموعد النهائي لإكمال التعليمات البرمجية 1.1 هو يوم الجمعة. هل يمكننا من فضلك لا نفعل هذا
الآن؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

كلايتون كولمان | مهندس رئيسي ، OpenShift

تدور المناقشة حول أرقام IP و Pods ولكن في تجربتي مع Mongo & Zookeeper ، يجب أن تظل Pods غير ذات صلة (لا تصبح حيوانات أليفة). يحتاج المجلد الثابت _volume_ إلى رقم رمزي لأن هذا المجلد يسجل رقم IP الخاص بـ "وحدات التخزين" الأخرى. أيا كان Pod الذي يتصاعد هذا الحجم ، يجب أن يكون قادرًا على استخدام رقم IP المسجل بطريقة ما. الحجم هو حيوان أليف ...

أعتقد أن اسم DNS الثابت في الوقت المناسب لوحدة التخزين والمخصص للقرص الذي يقوم بتركيب وحدة التخزين سيقطع شوطًا طويلاً.

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

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

نعم ، يعتبر pod IP أكثر من اختراق قصير المدى.

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

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

في 23 سبتمبر 2015 ، الساعة 11:33 صباحًا ، كتب Peter Kriens [email protected] :

يدور النقاش حول أرقام IP و Pods ولكن في تجربتي مع
مونغو وزوكيبير IP يجب أن تظل القرون غير ذات صلة (لا تصبح حيوانات أليفة).
يحتاج الحجم الثابت إلى رقم رمزي منذ أن يسجل هذا المجلد
رقم IP الخاص بـ "المجلدات" الأخرى. مهما كان بود الذي يتصاعد هذا الحجم
يجب أن تكون قادرًا على استخدام رقم IP المسجل بطريقة ما. الحجم هو
حيوان أليف ...

اسم DNS ثابت في الوقت المناسب لوحدة تخزين ويتم تخصيصه إلى Pod
يتصاعد حجم سيقطع شوطا طويلا على ما أعتقد.

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

إعطاء اسم DNS ثابت بناءً على وحدة التخزين المركبة وإمكانية
التعامل مع عضوية المجموعة مع رمز مخصص يجب أن يجعل من الممكن
التعامل مع هذا النوع من الأنظمة على ما أعتقد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/ بينغ

يمكنك العثور على مثال لإعداد مجموعة ZK ضمن Kubernetes باستخدام الإمكانات الموجودة على https://hub.docker.com/r/elevy/zookeeper/. الشرط الأساسي هو عناوين IP وأسماء مضيفين ثابتة لأعضاء المجموعة. يتم تحقيق ذلك باستخدام خدمات فردية لكل عضو في الكتلة. التجعد الوحيد هو أن ZK سيحاول بشكل افتراضي الارتباط بـ IP الذي يحل اسم المضيف الخاص به ، ولكن يمكن تجنب ذلك من خلال معلمة التكوين.

تضمين التغريدة

أفكار أثناء ركوب الدراجة إلى المكتب قبل بضعة أيام:

أفكر حاليًا في هذا باعتباره وحدة تحكم PetSet ، أو ربما وحدة تحكم ShardSet ، إذا أراد الناس التفكير في الأمر بهذه الطريقة ، كما تمت مناقشته في البداية: https://github.com/kubernetes/kubernetes/issues/260# طلب إصدار -57671926.

الحالة التي نحاول معالجتها هي حيث توجد N حيوانات أليفة متشابهة ، لكنها لا تزال حيوانات أليفة - فهي ليست قابلة للاستبدال.

ما زلت أعتقد أن ربط هذا بـ ReplicationController لا يمكن أن يعمل ، جزئيًا لأن ReplicationController لديه قالب واحد فقط. يجب أن تكون PetSet / ShardSet عملية تجريد ذات مستوى أعلى ، مثل Deployment أو DaemonSet. من المحتمل أن تقوم PetSet بإنشاء كائن PodTemplate واحد لكل مثيل.

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

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

لا أريد تمثيل مقياس PetSet في أكثر من مكان ، مثل وحدة التحكم وفي مجموعة الهوية ، أو في وحدة التحكم وفي الخدمة ، لأن ذلك سيجعل القياس صعبًا / محرجًا.

لا أعتقد أننا بحاجة إلى قوالب للأغراض العامة لهذه الحالة. نحتاج فقط إلى التخلص من الكبسولات ذات التخزين المرتبط بهويات الشبكة المتينة والمتوقعة. كان المعادل التقريبي كافياً في بورغ. لذلك ، أميل بشدة نحو شيء ما على غرار # 12450 ، ولكن في قالب البودات بدلاً من البودات نفسها. ربما تكون مجموعة من قوالب VolumeClaimTemplates ثابتة بالإضافة إلى قالب podTemplate. لا أريد إضافة بديل خيالي لجميع مصادر وحدة التخزين الخاصة بمزود السحابة ، خاصة وأننا نريد إهمال تلك المصادر على أي حال. يجب أن تكون إضافة متطلبات و / أو محددات إضافية إلى PVCs كافية. سنحتاج أيضًا إلى أن نكون قادرين على توفير وحدات تخزين ثابتة بطريقة ما في مرحلة ما.

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

ثم يتغير اسم المضيف والخدمة مقطوعة الرأس المذكورة أعلاه ، هنا:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

العمل على اقتراح الآن ، سيكون لديك مسودة قريبا.

الاقتراح معروض في https://github.com/kubernetes/kubernetes/pull/18016

... أين نحن مع PetSet؟

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

1. تعيّن خدمة "postgres" جولة روبن لجميع البودات في مجموعة النسخ المتماثلة ، لكن خرائط الخدمة "postgres-master" لحجرة واحدة فقط.
2. الجراب الرئيسي يموت.
3. يحدث تجاوز الفشل. كجزء من تجاوز الفشل ، يقوم المعلم الجديد بتحديث Kube-master عبر واجهة برمجة التطبيقات "للاستيلاء" على خدمة postgres-master.
4. عند القيام بذلك ، يتم إنهاء جميع الاتصالات السابقة لـ postgres-master.

jberkus ، تم دمج كود ألفا الأولي لتمكين PetSets أو أنه في انتظار الدمج. سيبدأingvagabund من فريقي في تجميع أمثلة تستفيد من PetSet لمعرفة ما الذي يعمل بشكل جيد وما الذي لا يزال بحاجة إلى التحسين. أوصيك بالتواصل معه إذا كان لديك بعض حالات الاستخدام المحددة التي تريد تجميعها واختبارها.

ncdc هل تم عمل كل شيء من أجل هذا في

تضمين التغريدة

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

في 19 أيار (مايو) 2016 ، الساعة 10:25 صباحًا ، أرسل Brandon Philips [email protected]
كتب:

ncdc https://github.com/ncdc هل تم عمل كل شيء من أجل هذا في الإصدار 1.3 ؟ أنه
غير واضح لأن الاقتراح غير مدمج ولم يكن هناك علاقات عامة أخرى
الرجوع إلى هذا لفترة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

أين يمكنني أن أجد مستندات لهذا؟ أود اختباره في حالة استخدام تجاوز فشل قاعدة البيانات.

آه ها ، فقط ما نحتاجه خبير postgres :)

راجع https://github.com/kubernetes/contrib/pull/921 للحصول على أمثلة ، يمكنني الإجابة على أي أسئلة حول تكوين [db of choice] كمجموعة حيوانات أليفة. لدينا مجموعة من الرسومات تحت عنوان "تطبيقات / جليل" التسمية (على سبيل المثال: https://github.com/kubernetes/kubernetes/issues/23790،philips سيكون مثالا etcd يكون كبيرا). لم أكتب مستنداتي بعد ، وسأفعل ذلك في الأسابيع القليلة الماضية من 1.3 (لا يزال هناك 5 أسابيع لإصدارها بعد اكتمال الشفرة يوم الجمعة).

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

لإعطائك مراجعة سريعة ، تمنحك الحيوانات الأليفة اليوم هوية شبكة متسقة (DNS ، اسم المضيف) تتطابق مع وحدة تخزين محمولة على الشبكة ، وضمانات للطلب. لذلك إذا قمت بإنشاء حيوان أليف replicas: 3 ، فستحصل على:
الخدمة الحاكمة: * .galear.default.svc.cluster.local
mysql-0 - حجم 0
mysql-1 - المجلد 1: لا يبدأ حتى يتم تشغيل 0 وجاهزًا
mysql-2 - المجلد 2: لا يبدأ حتى يصبح الرقم 1 جاهزًا

يمكن أن تستخدم البودات DNS لاكتشاف الخدمة من خلال البحث عن سجلات SRV المدرجة ضمن الخدمة الحاكمة. هذا ما تفعله هذه الحقيبة البسيطة: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. لذلك إذا كنت تستخدم الباحث عن النظير من خلال حاوية init كما في الأمثلة أعلاه ، فلن يبدأ mysql-1 حتى ترى حاوية init (mysql-1، mysql-0) في DNS ، وتكتب التكوين المناسب.

يتم توفير وحدات التخزين بواسطة موفر ديناميكي (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md) ، لذلك إذا لم يكن لديك واحد تعمل في مجموعتك ولكنك تريد فقط إنشاء نموذج أولي ، يمكنك ببساطة استخدام blankDir. حالة "جاذبية البيانات" (https://github.com/kubernetes/kubernetes/issues/7562) لا تعمل حتى الآن ، ولكنها ستنجح في النهاية.

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

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

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

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

يمكنك الحصول عليها إذا كنت تبني من HEAD

دمج bprashanth في الريبو الرئيسي؟ عظيم شكرا. سوف تفعل.

https://github.com/kubernetes/contrib/tree/master/pets

yaml المضمنة في سلاسل التعليقات التوضيحية؟ oof، ouch :(. شكرًا على الرغم من ذلك ، سوف نحقق في صنع مجموعة كاساندرا.

هذا هو json. إنها ميزة ألفا مضافة إلى كائن GA (حاويات init في pods).
chrislovecnm يعمل على كاساندرا ، ربما فقط ترغب في انتظاره.

paralin هنا ما أعمل عليه. لا يوجد وقت لتوثيقها والحصول عليها في k8s repo الآن ، ولكن هذه خطة طويلة الأجل. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra يعمل معي محليًا ، على HEAD.

تعمل أحدث صورة C * في العرض التوضيحي جيدًا.

لدينا مشكلة مفتوحة لمزيد من الوثائق. غمزة وينك ، knudge bprashanth

مثال على مجموعات الحيوانات الأليفة مع مجموعة إلخ [1].

[1] https://github.com/kubernetes/contrib/pull/1295

تأكد من التقاط طلبات التصميم في مستند الاقتراح بعد الانتهاء من المراجعة

في 30 حزيران (يونيو) 2016 ، الساعة 1:25 صباحًا ، كتب Jan Chaloupka [email protected] :

مثال على مجموعات الحيوانات الأليفة مع مجموعة إلخ [1].

[1] kubernetes / Contrib # 1295
https://github.com/kubernetes/contrib/pull/1295

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

مستندات الحيوانات الأليفة هي https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md و https://github.com/kubernetes/kubernetes.github. io / tree / release-1.3 / docs / user-guide / petset / bootstrapping ، أخطط لإغلاق هذه المشكلة وفتح واحدة جديدة تتناول نقل الحيوانات الأليفة إلى بيتا ما لم يعترض أي شخص

https://github.com/kubernetes/kubernetes/issues/28718