أظن ذلك؟ ولكن لماذا لا تستخدم فقط git repo؟

يوم الخميس ، 7 أغسطس 2014 الساعة 10:11 مساءً ، Tim Hockin [email protected]
كتب:

سيؤدي هذا إلى تعيين دعم وحدات التخزين الأصلية لـ Docker والسماح به
الأشخاص لبناء البيانات المخبوزة مسبقًا وإصدارها كحاويات. ربما للقراءة فقط؟
لم أعتقد ذلك الآن ...

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

المزيد من الإضافات أفضل؟ أردت أن أضعها هناك ، لأننا نقوم بالفرز
من التباعد عن دعم أحجام Docker الأصلية. من الواضح أنه ليس عاجلاً :)

يوم الخميس ، 7 أغسطس 2014 الساعة 10:18 مساءً ، brendandburns [email protected]
كتب:

أظن ذلك؟ ولكن لماذا لا تستخدم فقط git repo؟

يوم الخميس ، 7 أغسطس 2014 الساعة 10:11 مساءً ، Tim Hockin [email protected]
كتب:

سيؤدي هذا إلى تعيين دعم وحدات التخزين الأصلية لـ Docker والسماح به
الأشخاص لبناء البيانات المخبوزة مسبقًا وإصدارها كحاويات. يمكن
يقرأ فقط؟
لم أعتقد ذلك الآن ...

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

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

المزيد من الاستخدامات المحتملة لهذا:

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

يمكن استخدام git repo لبعض هذه الحالات ، لكن بالنسبة للآخرين سيكون أقل من مثالي.

إذا كانت الصورة الأساسية لملف عامل ميناء (على سبيل المثال FROM fedora ) هي توزيعة Linux ،
إذن ، لن يكون مزعجًا أن يكون لديك مجموعة من Linux Standard Base
نوع الملفات في ما يُفترض حقًا أن يكون حزمة بيانات فقط؟

من ناحية أخرى ، إذا كان يتم الإنشاء باستخدام tar -c . | docker import - myimage ، فما هي ميزة صورة عامل إرساء على ملف tar؟

يوم الثلاثاء ، 30 سبتمبر 2014 الساعة 9:00 مساءً ، bgrant0607 [email protected]
كتب:

المزيد من الاستخدامات المحتملة لهذا:

• نشر البرامج النصية / البرامج لخطافات دورة الحياة: أحد العناصر الرئيسية
  نقاط خطاف دورة الحياة (# 140
  https://github.com/GoogleCloudPlatform/kubernetes/issues/140) هو
  افصل التطبيقات عن بيئة التنفيذ (Kubernetes في هذا
  قضية). إذا كان يجب نشر البرامج النصية / البرامج النصية للربط كجزء من ملف
  حاوية التطبيق ، التي تقوض هذا الهدف.
• تكوين الحزمة الديناميكية بشكل عام: سيكون هذا أكثر
  على غرار نموذج الحزمة الداخلي الخاص بنا ، حيث يمكننا إدارته بشكل مستقل
  نظام الملفات الأساسي ، وقت تشغيل اللغة ، التطبيق ، البرامج المساعدة لـ
  التصحيح ، إلخ.
• نشر التكوين
• نشر بيانات الإدخال

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

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

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

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

في الأربعاء 1 أكتوبر 2014 الساعة 7:20 صباحًا ، كتب erictune [email protected] :

إذا كانت الصورة الأساسية لملف عامل ميناء (على سبيل المثال FROM fedora ) هي توزيعة Linux ،
إذن ، لن يكون مزعجًا أن يكون لديك مجموعة من Linux Standard Base
نوع الملفات في ما يُفترض حقًا أن يكون حزمة بيانات فقط؟

من ناحية أخرى ، إذا كان يتم الإنشاء باستخدام tar -c . | docker import - myimage ، فما هي ميزة صورة عامل إرساء على ملف tar؟

يوم الثلاثاء ، 30 سبتمبر 2014 الساعة 9:00 مساءً ، bgrant0607 [email protected]
كتب:

المزيد من الاستخدامات المحتملة لهذا:

• نشر البرامج النصية / البرامج لخطافات دورة الحياة: أحد العناصر الرئيسية
  نقاط خطاف دورة الحياة (# 140
  https://github.com/GoogleCloudPlatform/kubernetes/issues/140) هو
  افصل التطبيقات عن بيئة التنفيذ (Kubernetes في هذا
  قضية). إذا كان يجب نشر البرامج النصية / البرامج النصية للربط كجزء من ملف
  حاوية التطبيق ، التي تقوض هذا الهدف.
• تكوين الحزمة الديناميكية بشكل عام: سيكون هذا أكثر
  على غرار نموذج الحزمة الداخلي الخاص بنا ، حيث يمكننا إدارته بشكل مستقل
  نظام الملفات الأساسي ، وقت تشغيل اللغة ، التطبيق ، البرامج المساعدة لـ
  التصحيح ، إلخ.
• نشر التكوين
• نشر بيانات الإدخال

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

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

.

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

thockin تعجبني الفكرة الأولية المتمثلة في وجود نوع وحدة تخزين جديدة لدعم حاوية حجم بيانات عامل الشحن ، والتي تتطابق مع مفهوم الحزمة المشتركة والحزمة المشتركة وما إلى ذلك داخليًا. يمكنني أيضًا رؤية حالات الاستخدام المحتملة المدرجة بواسطة @ bgrant0607. لكن من فضلك لا تنزل إلى الطريق مثل Docker اليوم: قم بالإعلان عن الحاوية كحجم بيانات ، وفي هذه الحالة ، سنقدم مستوى آخر من التعقيد من التبعيات للحاويات الموجودة داخل الكبسولة ، أو حتى التبعيات بين الكبسولات يحتوي فقط على حاوية حجم بيانات ، وما إلى ذلك. أعتقد أن فكرتك الأولية عن وجود نوع وحدة تخزين يشير في الواقع إلى حاوية حجم عامل إرساء أو وحدة تخزين أخرى للقراءة فقط هي طريقة أفضل على المدى الطويل.

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

لا أعتقد أننا نعرف ما يريده الناس حقًا في هذا الفضاء حتى الآن.

يوم الأربعاء 1 أكتوبر 2014 الساعة 10:57 صباحًا ، كتب Dawn Chen [email protected] :

thockin https://github.com/thockin أحب الفكرة الأولية لامتلاك
نوع وحدة تخزين جديدة لدعم حاوية حجم بيانات عامل الإرساء ، والتي تتطابق
الحزمة المشتركة ، الحزمة المشتركة ، إلخ. مفهوم داخليًا. يمكنني أيضًا رؤية ملف
حالات الاستخدام المحتملة المدرجة بواسطة @ bgrant0607 https://github.com/bgrant0607.
لكن من فضلك لا تنزل إلى الطريق مثل Docker اليوم: أعلن عن ملف
حاوية كحجم بيانات ، وفي هذه الحالة ، سنقوم بإدخال أخرى
مستوى تعقيد التبعيات للحاويات داخل جراب ، أو حتى
التبعيات بين البودات إذا كان البود يحتوي فقط على حاوية حجم بيانات ، وما إلى ذلك
فكر في فكرتك الأولية عن وجود نوع وحدة تخزين والذي يشير في الواقع إلى ملف
تعتبر حاوية حجم عامل الإرساء أو أي وحدة تخزين أخرى للقراءة فقط طريقة أفضل لـ
على المدى الطويل.

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

يظهر نفس التأثير الصافي حيث يمكن تحقيق هذه المشكلة دون إدخال نوع وحدة تخزين جديد باستخدام حاويتين في حجرة وبعض الغلاف ملفوف حول سطور أوامر الحاوية السفلية (راجع https://github.com/GoogleCloudPlatform/kubernetes/issues/ 1589 # issuecomment-58043463).

كيفية تحديد الحاوية كمجلد مقابل التسلسل المستند إلى سطر الأوامر؟

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

هناك الكثير من الطرق للقيام بذلك ، ولا حاجة لنوع وحدة التخزين الجديدة في رأيي. حاولت توحيد طريقة هيكلة البيانات وجعل مزودي وحدات التخزين المختلفين ممكنًا. تتراوح هذه من أحجام المضيف ، وحاويات حجم البيانات ، والحاويات الجانبية مع منطق إضافي إلى الحجم كخدمة ، حيث يمكن أن تتكامل k8s بشكل كبير. البداية متاحة بالفعل عبر git كحجم. أعتقد أن المجلدات الأصلية في Docker كافية ، لكنها تفتقر إلى المعيار. تتوفر الأفكار الأكثر تفصيلاً في Docker / docker # 9277.

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

@ bgrant0607 ما زالوا مدعومين في عامل

+1 لدعم الحاوية كحجم. لدي سيناريو حيث لدي حاوية تحتوي على مجموعة من البيانات المخبأة بها لاستخدامها بواسطة حاويات أخرى ، مما يساعد في الحفاظ على البيانات "محلية" للعمل الذي يتم إنجازه.

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

1. لا يذكر أن VOLUME / - volumes-from / container-as-volume غير مدعوم
2. لا يذكر الحلول الممكنة
3. لا يذكر إمكانية استرداد الأشياء من git repo

من المهم ملاحظة أن استخدام git repo ليس هو نفسه. يتطلب الوصول إلى git repo بأمان من Google Cloud (أو في أي مكان يتم استخدام Kubernetes فيه). علاوة على ذلك ، من غير الواضح كيف يمكن الوصول إلى المستودعات غير العامة ، ما لم يتم تشفير المستخدم وكلمة المرور في سلسلة Kubernetes GitRepo # repository JSON / YAML. كما يتطلب أيضًا أن يتم إيداع القطعة (القطع) المرغوبة للتحكم في المصدر. ويفصل صورة Docker عن القطعة الأثرية (التي قد تكون مرغوبة أو غير مرغوب فيها).

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

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

+1 @ rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حاويات حجم البيانات.

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

@ rehevkor5 فكرت في نفس الشيء حول حاويات حجم البيانات في البداية (يجب كتابتها على أنها من الصفر) حتى قرأت هذا (والذي قد يكون أو لا يكون صحيحًا): http://container42.com/2014/11/18/data جنون الحاوية فقط / يبدو أن الحل الخاص بك يفعل هذا بالضبط؟

هناك بعض الأشياء التي تحدث هنا ، وأهمها (على ما أعتقد) بعضها
الالتباس.

يدعم Kubernetes فكرة "وحدة تخزين فارغة" قابلة للكتابة تتم مشاركتها
عبر الحاويات داخل جراب ، دون اللجوء إلى أدلة المضيف -
هذا هو حجم Dir الفارغ.

السؤال الآن ينزل إلى "لكنني لا أريد دليل _الفراغ_ ، أنا
يريد"السؤال الذي أعتقد أننا بحاجة إلى تسويته هو ماذا
اليكون. نحن ندعم حاليًا ميزة pull-from-git ، وهو أمر عادل
مثيل واحد لنمط أكبر - "اذهب واحضر بعض البيانات المطبوخة مسبقًا مرة واحدة
قبل بدء جرابتي ".

يمكننا دعم عدد لا يحصى من أنواع مجلدات "الجلب مرة واحدة" ، git ، cvs ، svn ،
حاويات docker (المزيد أدناه) ، عناوين URL ، ملفات tarfiles مضمنة base64 ،
stdout من برنامج آخر ، وما إلى ذلك. لا أعتقد أننا نريد دعم هؤلاء
كل ذلك كمكونات إضافية لوحدة التخزين - يمكن إجراؤها كلها تقريبًا بواسطة ملف
حاوية غير مميزة دون أي مساعدة من kubelet. أكثر ، بسرعة
الوصول إلى ميزات المتابعة مثل "... وإعادة السحب من git كل 10
دقائق "- الأشياء التي تتوقف عن كونها" تجلب مرة واحدة "وتبدأ في النشاط
إدارة ، ولكن لا تتطلب امتيازات. نحن نستفيد كثيرا من هذا
الأشياء داخليا.

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

الآن ، دعنا نفكر في حالة حاويات حجم بيانات عامل الإرساء. ما هو
الدلالة التي يطلبها الناس حقًا؟ فعلا:

• "تشغيل" حاوية بيانات ثم كشف الجذور الكاملة لذلك التشغيل؟
• "قم بتشغيل" حاوية بيانات ثم قم بتعريض كافة وحدات التخزين (من
  Dockerfile) كمجلدات kubernetes؟
• "قم بتشغيل" حاوية بيانات ثم قم بعمل ما يعادل -volumes-from into
  حاويات kubernetes؟

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

عنصر العمل: أرغب كثيرًا في الأشخاص الذين يستخدمون حاويات بيانات عامل الإرساء
لوصف السلوك الذي يتوقعونه هنا.

العودة إلى حاويات السيارات الجانبية كأحجام. يمكنني تخيل شيء مثل:

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data"،
المصدر: FromContainer {
الاسم: "محرجًا" ، // ما الذي يحدث هنا؟
الصورة: "kubernetes / git-volume"
EnvVars: [
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
}
}
] ،
الحاويات: [... استخدام git-data ...]
}

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

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

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data" ، المصدر: EmptyDir {}}
] ،
حاويات: [
{
الاسم: "git-puller" ،
الصورة: "kubernetes / git-volume"
EnvVars: [
{DATADIR: "/ المجلد"}،
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
VolumeMounts: [{Name: "git-data"، MountPath: "/ vol"}]
} ،
{... الحاوية التي تقرأ git-data ...}
]
}
}

لا يزال مطولًا جدًا. هل يمكننا أن نفعل ما هو أفضل؟

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

أعتقد أن شيئًا كهذا هو السبيل للذهاب. التفاصيل في الظهور ، المدخلات
مطلوب.

يوم السبت ، 10 كانون الثاني (يناير) 2015 ، الساعة 5:42 مساءً ، إشلي آيتكن إخطارات @github.com
كتب:

+1 @ rehevkor5 https://github.com/rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حاويات حجم البيانات.

لست متأكدًا من كيفية استخلاص بيانات r / w بعيدًا عن المضيف
حاليا. كان لدي انطباع بأن k8s كانت تدور حول تجريد
host ، لكن حجم المضيف يقدم جميع أنواع مواصفات المضيف ، مثل الامتلاك
لمشاركة نفس اسم المستخدم / المجموعة للوصول إلى البيانات.

@ rehevkor5 https://github.com/rehevkor5 فكرت في نفس الشيء
حاويات حجم البيانات في البداية (يجب كتابتها على أنها من الصفر) حتى أنا
اقرأ هذا (الذي قد يكون أو لا يكون صحيحًا):
http://container42.com/2014/11/18/data-only-container-madness/

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

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

البيانات الدائمة هي موضوع أكبر بكثير :)

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

هناك بعض الأشياء التي تحدث هنا ، وأهمها (على ما أعتقد) بعضها
الالتباس.

يدعم Kubernetes فكرة "وحدة تخزين فارغة" قابلة للكتابة تتم مشاركتها
عبر الحاويات داخل جراب ، دون اللجوء إلى أدلة المضيف -
هذا هو حجم Dir الفارغ.

السؤال الآن ينزل إلى "لكنني لا أريد دليل _الفراغ_ ، أنا
يريد"السؤال الذي أعتقد أننا بحاجة إلى تسويته هو ماذا
اليكون. نحن ندعم حاليًا ميزة pull-from-git ، وهو أمر عادل
مثيل واحد لنمط أكبر - "اذهب واحضر بعض البيانات المطبوخة مسبقًا مرة واحدة
قبل بدء جرابتي ".

يمكننا دعم عدد لا يحصى من أنواع مجلدات "الجلب مرة واحدة" ، git ، cvs ، svn ،
حاويات docker (المزيد أدناه) ، عناوين URL ، ملفات tarfiles مضمنة base64 ،
stdout من برنامج آخر ، وما إلى ذلك. لا أعتقد أننا نريد دعم هؤلاء
كل ذلك كمكونات إضافية لوحدة التخزين - يمكن إجراؤها كلها تقريبًا بواسطة ملف
حاوية غير مميزة دون أي مساعدة من kubelet. أكثر ، بسرعة
الوصول إلى ميزات المتابعة مثل "... وإعادة السحب من git كل 10
دقائق "- الأشياء التي تتوقف عن كونها" تجلب مرة واحدة "وتبدأ في النشاط
إدارة ، ولكن لا تتطلب امتيازات. نحن نستفيد كثيرا من هذا
الأشياء داخليا.

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

الآن ، دعنا نفكر في حالة حاويات حجم بيانات عامل الإرساء. ما هو
الدلالة التي يطلبها الناس حقًا؟ فعلا:

• "تشغيل" حاوية بيانات ثم كشف الجذور الكاملة لذلك التشغيل؟
• "قم بتشغيل" حاوية بيانات ثم قم بتعريض كافة وحدات التخزين (من
  Dockerfile) كمجلدات kubernetes؟
• "قم بتشغيل" حاوية بيانات ثم قم بعمل ما يعادل -volumes-from into
  حاويات kubernetes؟

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

عنصر العمل: أرغب كثيرًا في الأشخاص الذين يستخدمون حاويات بيانات عامل الإرساء
لوصف السلوك الذي يتوقعونه هنا.

العودة إلى حاويات السيارات الجانبية كأحجام. يمكنني تخيل شيء مثل:

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data"،
المصدر: FromContainer {
الاسم: "محرجًا" ، // ما الذي يحدث هنا؟
الصورة: "kubernetes / git-volume"
EnvVars: [
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
}
}
] ،
الحاويات: [... استخدام git-data ...]
}

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

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

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data" ، المصدر: EmptyDir {}}
] ،
حاويات: [
{
الاسم: "git-puller" ،
الصورة: "kubernetes / git-volume"
EnvVars: [
{DATADIR: "/ المجلد"}،
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
VolumeMounts: [{Name: "git-data"، MountPath: "/ vol"}]
} ،
{... الحاوية التي تقرأ git-data ...}
]
}
}

لا يزال مطولًا جدًا. هل يمكننا أن نفعل ما هو أفضل؟

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

أعتقد أن شيئًا كهذا هو السبيل للذهاب. التفاصيل في الظهور ، المدخلات
مطلوب.

يوم السبت ، 10 كانون الثاني (يناير) 2015 ، الساعة 5:42 مساءً ، إشلي آيتكن إخطارات @github.com
كتب:

+1 @ rehevkor5 https://github.com/rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حجم البيانات
حاويات.

لست متأكدًا من كيفية استخلاص بيانات r / w بعيدًا عن المضيف
حاليا. كان لدي انطباع بأن k8s كانت تدور حول تجريد
host ، لكن حجم المضيف يقدم جميع أنواع مواصفات المضيف ، مثل الامتلاك
لمشاركة نفس اسم المستخدم / المجموعة للوصول إلى البيانات.

@ rehevkor5 https://github.com/rehevkor5 فكرت في نفس الشيء
حاويات حجم البيانات في البداية (يجب كتابتها على أنها من الصفر) حتى أنا
اقرأ هذا (الذي قد يكون أو لا يكون صحيحًا):
http://container42.com/2014/11/18/data-only-container-madness/

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

سأحاول وصف حالة استخدام لحاوية بيانات. سآخذ مع جراب
3 حاويات سأسميها "استيعاب" و "معالجة" و "بيانات".

حاوية الاستيعاب مسؤولة عن استلام الرسائل بطريقة ما
وإخبار حاوية "العملية" بتنفيذ العمل.

تعمل حاوية العملية ، ولكنها تتطلب الوصول إلى البيانات المقدمة بواسطة
حاوية "البيانات" ، خارج kubernetes ، يتم ذلك باستخدام عمال الإرساء
"مجلدات من". يمكن أن تكون هذه "البيانات" 100 ميغا بايت ، ولكن في أغلب الأحيان
10-15 جيجا بايت.

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

نأمل أن يكون هذا منطقيًا.

شكرا

يوم الأحد 11 كانون الثاني (يناير) 2015 الساعة 12:18 صباحًا ، Tim Hockin [email protected]
كتب:

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

البيانات الدائمة هي موضوع أكبر بكثير :)

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

هناك بعض الأشياء التي تحدث هنا ، وأهمها (على ما أعتقد) بعضها
الالتباس.

يدعم Kubernetes فكرة "وحدة تخزين فارغة" قابلة للكتابة
مشترك
عبر الحاويات داخل جراب ، دون اللجوء إلى أدلة المضيف -
هذا هو حجم Dir الفارغ.

السؤال الآن ينزل إلى "لكنني لا أريد دليل _الفراغ_ ، أنا
يريد"السؤال الذي أعتقد أننا بحاجة إلى تسويته هو ماذا
اليكون. نحن ندعم حاليًا pull-from-git ، وهو
مجرد
مثيل واحد لنمط أكبر - "اذهب لجلب بعض البيانات المطبوخة مسبقًا
بمجرد
قبل بدء جرابتي ".

يمكننا دعم عدد لا يحصى من أنواع مجلدات "الجلب مرة واحدة" ، git ، cvs ، svn ،
حاويات docker (المزيد أدناه) ، عناوين URL ، ملفات tarfiles مضمنة base64 ،
stdout من برنامج آخر ، وما إلى ذلك. لا أعتقد أننا نريد دعم هؤلاء
كل ذلك كمكونات إضافية لوحدة التخزين - يمكن إجراؤها كلها تقريبًا بواسطة ملف
حاوية غير مميزة دون أي مساعدة من kubelet. أكثر ، بسرعة
الوصول إلى ميزات المتابعة مثل "... وإعادة السحب من git كل 10
دقائق "- الأشياء التي تتوقف عن كونها" تجلب مرة واحدة "وتبدأ في النشاط
إدارة ، ولكن لا تتطلب امتيازات. نحن نستفيد كثيرا من هذا
الأشياء داخليا.

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

الآن ، دعنا نفكر في حالة حاويات حجم بيانات عامل الإرساء. ما هو
الدلالة التي يطلبها الناس حقًا؟ فعلا:

• "تشغيل" حاوية بيانات ثم كشف الجذور الكاملة لذلك التشغيل؟
• "قم بتشغيل" حاوية بيانات ثم قم بتعريض كافة وحدات التخزين (من
  Dockerfile) كمجلدات kubernetes؟
• "قم بتشغيل" حاوية بيانات ثم قم بما يعادل --volumes-from
  إلى
  حاويات kubernetes؟

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

عنصر العمل: أرغب كثيرًا في الأشخاص الذين يستخدمون حاويات بيانات عامل الإرساء
لوصف السلوك الذي يتوقعونه هنا.

العودة إلى حاويات السيارات الجانبية كأحجام. يمكنني تخيل شيء مثل:

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data"،
المصدر: FromContainer {
الاسم: "محرجًا" ، // ما الذي يحدث هنا؟
الصورة: "kubernetes / git-volume"
EnvVars: [
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
}
}
] ،
الحاويات: [... استخدام git-data ...]
}

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

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

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data" ، المصدر: EmptyDir {}}
] ،
حاويات: [
{
الاسم: "git-puller" ،
الصورة: "kubernetes / git-volume"
EnvVars: [
{DATADIR: "/ المجلد"}،
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
VolumeMounts: [{Name: "git-data"، MountPath: "/ vol"}]
} ،
{... الحاوية التي تقرأ git-data ...}
]
}
}

لا يزال مطولًا جدًا. هل يمكننا أن نفعل ما هو أفضل؟

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

أعتقد أن شيئًا كهذا هو السبيل للذهاب. التفاصيل في الظهور ، المدخلات
مطلوب.

يوم السبت ، 10 كانون الثاني (يناير) 2015 ، الساعة 5:42 مساءً ، آشلي أيتكين < [email protected]

كتب:

+1 @ rehevkor5 https://github.com/rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حجم البيانات
حاويات.

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

@ rehevkor5 https://github.com/rehevkor5 اعتقدت نفس الشيء
حول
حاويات حجم البيانات في البداية (يجب كتابتها على أنها من الصفر)
إلى أن
اقرأ هذا (الذي قد يكون أو لا يكون صحيحًا):
http://container42.com/2014/11/18/data-only-container-madness/

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

.

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

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

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

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

الحجة الأخرى الوحيدة هي أن تكون عامل الإرساء متوافقًا تمامًا من الناحية اللغوية ،
ولكن بصراحة ، فإن مجلدات السلوك جامدة من الناحية المعنوية ، وقد لا تكون كذلك
تستحق التوافق معها.
في 11 كانون الثاني (يناير) 2015 ، الساعة 9:26 صباحًا ، كتب "Craig Wickesser" [email protected] :

سأحاول وصف حالة استخدام لحاوية بيانات. سآخذ مع جراب
3 حاويات سأسميها "استيعاب" و "معالجة" و "بيانات".

حاوية الاستيعاب مسؤولة عن استلام الرسائل بطريقة ما
وإخبار حاوية "العملية" بتنفيذ العمل.

تعمل حاوية العملية ، ولكنها تتطلب الوصول إلى البيانات المقدمة
بواسطة
حاوية "البيانات" ، خارج kubernetes ، يتم ذلك باستخدام عمال الإرساء
"مجلدات من". يمكن أن تكون هذه "البيانات" 100 ميغا بايت ، ولكن في أغلب الأحيان
10-15 جيجا بايت.

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

نأمل أن يكون هذا منطقيًا.

شكرا

يوم الأحد 11 كانون الثاني (يناير) 2015 الساعة 12:18 صباحًا ، Tim Hockin [email protected]
كتب:

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

البيانات الدائمة هي موضوع أكبر بكثير :)

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

هناك بعض الأشياء التي تحدث هنا ، وأهمها (على ما أعتقد) بعضها
الالتباس.

يدعم Kubernetes فكرة "وحدة تخزين فارغة" قابلة للكتابة
مشترك

عبر الحاويات داخل جراب ، دون اللجوء إلى أدلة المضيف

هذا هو حجم Dir الفارغ.

يتحول السؤال الآن إلى "لكنني لا أريد دليل _الفراغ_ ،
أنا
يريد"السؤال الذي أعتقد أننا بحاجة إلى حله هو
ماذا او ما
اليكون. نحن ندعم حاليًا pull-from-git ، وهو
مجرد
مثيل واحد لنمط أكبر - "اذهب لجلب بعض البيانات المطبوخة مسبقًا
بمجرد
قبل بدء جرابتي ".

يمكننا دعم عدد لا يحصى من أنواع مجلدات "الجلب مرة واحدة" ، git ، cvs ، svn ،
حاويات docker (المزيد أدناه) ، عناوين URL ، ملفات tarfiles مضمنة base64 ،
stdout من برنامج آخر ، إلخ. لا أعتقد أننا نريد دعمه
أولئك
كل ذلك كمكونات إضافية لوحدة التخزين - يمكن إجراؤها كلها تقريبًا بواسطة ملف
حاوية غير مميزة دون أي مساعدة من kubelet. المزيد ، أنت
بسرعة
الوصول إلى ميزات المتابعة مثل "... وإعادة السحب من git كل 10
دقائق "- الأشياء التي تتوقف عن كونها" تجلب مرة واحدة "وتبدأ في النشاط
إدارة ، ولكن لا تتطلب امتيازات. نحن نستفيد كثيرا من هذا
الأشياء داخليا.

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

الآن ، دعنا نفكر في حالة حاويات حجم بيانات عامل الإرساء. ماذا او ما
يكون
الدلالة التي يطلبها الناس حقًا؟ فعلا:

• "تشغيل" حاوية بيانات ثم كشف الجذور الكاملة لذلك
  يركض؟
• "قم بتشغيل" حاوية بيانات ثم قم بتعريض كافة وحدات التخزين (من
  Dockerfile) كمجلدات kubernetes؟
• "قم بتشغيل" حاوية بيانات ثم قم بما يعادل --volumes-from
  إلى
  حاويات kubernetes؟

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

عنصر العمل: أرغب كثيرًا في الأشخاص الذين يستخدمون بيانات عامل الإرساء
حاويات
لوصف السلوك الذي يتوقعونه هنا.

العودة إلى حاويات السيارات الجانبية كأحجام. يمكنني تخيل شيء ما
مثل:

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data"،
المصدر: FromContainer {
الاسم: "محرجًا" ، // ما الذي يحدث هنا؟
الصورة: "kubernetes / git-volume"
EnvVars: [
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
}
}
] ،
الحاويات: [... استخدام git-data ...]
}

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

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

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data" ، المصدر: EmptyDir {}}
] ،
حاويات: [
{
الاسم: "git-puller" ،
الصورة: "kubernetes / git-volume"
EnvVars: [
{DATADIR: "/ المجلد"}،
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
VolumeMounts: [{Name: "git-data"، MountPath: "/ vol"}]
} ،
{... الحاوية التي تقرأ git-data ...}
]
}
}

لا يزال مطولًا جدًا. هل يمكننا أن نفعل ما هو أفضل؟

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

أعتقد أن شيئًا كهذا هو السبيل للذهاب. التفاصيل في الظهور ،
إدخال
مطلوب.

يوم السبت ، 10 كانون الثاني (يناير) 2015 الساعة 5:42 مساءً ، آشلي أيتكين <
[email protected]

كتب:

+1 @ rehevkor5 https://github.com/rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حجم البيانات
حاويات.

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

@ rehevkor5 https://github.com/rehevkor5 اعتقدت نفس الشيء
حول
حاويات حجم البيانات في البداية (يجب كتابتها على أنها من الصفر)
إلى أن
اقرأ هذا (الذي قد يكون أو لا يكون صحيحًا):
http://container42.com/2014/11/18/data-only-container-madness/

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

https://github.com/GoogleCloudPlatform/kubernetes/issues/831#issuecomment -69480057

.

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

.

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

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

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

بعد فهم "emptydir" بشكل أفضل ، أوافق ، حالة الاستخدام التي قدمتها
ستعمل مع ما يدعمه Kubernetes اليوم.

شكرا.

يوم الأحد ، 11 كانون الثاني (يناير) 2015 الساعة 1:36 مساءً ، Tim Hockin [email protected]
كتب:

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

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

الحجة الأخرى الوحيدة هي أن تكون عامل الإرساء متوافقًا تمامًا من الناحية اللغوية ،
ولكن بصراحة ، فإن مجلدات السلوك جامدة من الناحية المعنوية ، وقد لا تكون كذلك
تستحق التوافق معها.
في 11 كانون الثاني (يناير) 2015 ، الساعة 9:26 صباحًا ، "Craig Wickesser" [email protected]
كتب:

سأحاول وصف حالة استخدام لحاوية بيانات. سآخذ جراب
مع
3 حاويات سأسميها "استيعاب" و "معالجة" و "بيانات".

حاوية الاستيعاب مسؤولة عن استلام الرسائل بطريقة ما
وإخبار حاوية "العملية" بتنفيذ العمل.

تعمل حاوية العملية ، ولكنها تتطلب الوصول إلى البيانات المقدمة
بواسطة
حاوية "البيانات" ، خارج kubernetes ، يتم ذلك باستخدام عمال الإرساء
"مجلدات من". يمكن أن تكون هذه "البيانات" 100 ميغا بايت ، ولكن في أغلب الأحيان
10-15 جيجا بايت.

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

نأمل أن يكون هذا منطقيًا.

شكرا

يوم الأحد 11 كانون الثاني (يناير) 2015 الساعة 12:18 صباحًا ، Tim Hockin [email protected]
كتب:

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

البيانات الدائمة هي موضوع أكبر بكثير :)

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

هناك بعض الأشياء التي تحدث هنا ، وأهمها (على ما أعتقد) بعضها
الالتباس.

يدعم Kubernetes فكرة "وحدة تخزين فارغة" قابلة للكتابة
مشترك

عبر الحاويات داخل جراب ، دون اللجوء إلى أدلة المضيف

هذا هو حجم Dir الفارغ.

الآن السؤال ينزل إلى "لكنني لا أريد _ فارغ_"
الدليل،
أنا
يريد"السؤال الذي أعتقد أننا بحاجة إلى حله هو
ماذا او ما
اليكون. نحن ندعم حاليًا pull-from-git ، وهو
مجرد
مثيل واحد لنمط أكبر - "اذهب واحضر بعضًا مطبوخًا مسبقًا
البيانات
بمجرد
قبل بدء جرابتي ".

يمكننا دعم عدد لا يحصى من أنواع مجلدات "الجلب مرة واحدة" ، git ، cvs ،
svn ،
حاويات docker (المزيد أدناه) ، عناوين URL ، ملفات tarfiles مضمنة base64 ،
stdout من برنامج آخر ، إلخ. لا أعتقد أننا نريد دعمه
أولئك
كل ذلك كمكونات إضافية لوحدة التخزين - يمكن إجراؤها كلها تقريبًا بواسطة ملف
حاوية غير مميزة دون أي مساعدة من kubelet. المزيد ، أنت
بسرعة
الوصول إلى ميزات المتابعة مثل "... وإعادة سحبها من git كل
10
دقائق "- الأشياء التي تتوقف عن كونها" تجلب مرة واحدة "وتبدأ في النشاط
إدارة ، ولكن لا تتطلب امتيازات. نحن نستفيد كثيرا من هذا
الأشياء داخليا.

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

الآن ، دعنا نفكر في حالة حاويات حجم بيانات عامل الإرساء.
ماذا او ما
يكون
الدلالة التي يطلبها الناس حقًا؟ فعلا:

• "تشغيل" حاوية بيانات ثم كشف الجذور الكاملة لذلك
  يركض؟
• "قم بتشغيل" حاوية بيانات ثم قم بتعريض كافة وحدات التخزين (من
  Dockerfile) كمجلدات kubernetes؟
• "قم بتشغيل" حاوية بيانات ثم قم بما يعادل --volumes-from
  إلى
  حاويات kubernetes؟

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

عنصر العمل: أرغب كثيرًا في الأشخاص الذين يستخدمون بيانات عامل الإرساء
حاويات
لوصف السلوك الذي يتوقعونه هنا.

العودة إلى حاويات السيارات الجانبية كأحجام. يمكنني تخيل شيء ما
مثل:

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data"،
المصدر: FromContainer {
الاسم: "محرجًا" ، // ما الذي يحدث هنا؟
الصورة: "kubernetes / git-volume"
EnvVars: [
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
}
}
] ،
الحاويات: [... استخدام git-data ...]
}

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

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

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data" ، المصدر: EmptyDir {}}
] ،
حاويات: [
{
الاسم: "git-puller" ،
الصورة: "kubernetes / git-volume"
EnvVars: [
{DATADIR: "/ المجلد"}،
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
VolumeMounts: [{Name: "git-data"، MountPath: "/ vol"}]
} ،
{... الحاوية التي تقرأ git-data ...}
]
}
}

لا يزال مطولًا جدًا. هل يمكننا أن نفعل ما هو أفضل؟

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

أعتقد أن شيئًا كهذا هو السبيل للذهاب. التفاصيل في الظهور ،
إدخال
مطلوب.

يوم السبت ، 10 كانون الثاني (يناير) 2015 الساعة 5:42 مساءً ، آشلي أيتكين <
[email protected]

كتب:

+1 @ rehevkor5 https://github.com/rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حجم البيانات
حاويات.

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

@ rehevkor5 https://github.com/rehevkor5 اعتقدت نفس الشيء
حول
حاويات حجم البيانات في البداية (يجب كتابتها على أنها من الصفر)
إلى أن
اقرأ هذا (الذي قد يكون أو لا يكون صحيحًا):
http://container42.com/2014/11/18/data-only-container-madness/

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

https://github.com/GoogleCloudPlatform/kubernetes/issues/831#issuecomment -69480057

.

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

https://github.com/GoogleCloudPlatform/kubernetes/issues/831#issuecomment -69484090

.

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

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

.

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

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

أنا لا أحاول تفادي دعم ميزة رائعة. في حالة
بيانات غير قابلة للتغيير ، سيتحمل القرص الفارغ نسخة و 2x من استخدام القرص. هذا ليس
مقبول. السؤال الذي أطرحه هو ما إذا كانت حالة الاستخدام هذه مثيرة للاهتمام ،
وإذا كان الأمر كذلك ، فماذا يعتقد الناس الدلالي أنه "واضح".

ثم هناك قضية البيانات الحية المحدثة. هل الحمولة الأولية
شيء؟ ما نوع واجهة برمجة التطبيقات (API) التي ستلتقط هذه الفكرة؟ هل البيانات الثابتة مجرد ملف
حالة خاصة من هذا؟
في 11 كانون الثاني (يناير) 2015 الساعة 10:43 صباحًا ، تلقيت "Craig Wickesser" [email protected]
كتب:

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

بعد فهم "emptydir" بشكل أفضل ، أوافق ، حالة الاستخدام التي قدمتها
ستعمل مع ما يدعمه Kubernetes اليوم.

شكرا.

يوم الأحد ، 11 كانون الثاني (يناير) 2015 الساعة 1:36 مساءً ، Tim Hockin [email protected]
كتب:

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

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

الحجة الأخرى الوحيدة هي أن تكون عامل الإرساء متوافقًا تمامًا من الناحية اللغوية ،
ولكن بصراحة ، فإن مجلدات السلوك جامدة من الناحية المعنوية ، ربما
ليس
تستحق التوافق معها.
في 11 كانون الثاني (يناير) 2015 ، الساعة 9:26 صباحًا ، "Craig Wickesser" [email protected]
كتب:

سأحاول وصف حالة استخدام لحاوية بيانات. سآخذ جراب
مع
3 حاويات سأسميها "استيعاب" و "معالجة" و "بيانات".

حاوية الاستيعاب مسؤولة عن استلام الرسائل في بعض
موضه
وإخبار حاوية "العملية" بتنفيذ العمل.

تعمل حاوية العملية ، لكنها تتطلب الوصول إلى البيانات
متاح
بواسطة
حاوية "البيانات" ، خارج kubernetes ، يتم ذلك باستخدام عمال الإرساء
"مجلدات من". يمكن أن تكون هذه "البيانات" 100 ميغا بايت ، ولكن في أغلب الأحيان
يكون
10-15 جيجا بايت.

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

نأمل أن يكون هذا منطقيًا.

شكرا

يوم الأحد 11 كانون الثاني (يناير) 2015 الساعة 12:18 صباحًا ، Tim Hockin [email protected]

كتب:

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

البيانات الدائمة هي موضوع أكبر بكثير :)

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

هناك بعض الأشياء التي تحدث هنا ، والأهم (على ما أعتقد)
بعض
الالتباس.

يدعم Kubernetes فكرة "وحدة تخزين فارغة" قابلة للكتابة
يكون
مشترك
عبر الحاويات داخل حجرة ، دون اللجوء إلى المضيف

الدلائل

هذا هو حجم Dir الفارغ.

الآن السؤال ينزل إلى "لكنني لا أريد _ فارغ_"
الدليل،
أنا
يريد"السؤال الذي أعتقد أننا بحاجة إلى حله
يكون
ماذا او ما
اليكون. نحن ندعم حاليًا ميزة pull-from-git ، والتي
يكون
مجرد
مثيل واحد لنمط أكبر - "اذهب واحضر بعضًا مطبوخًا مسبقًا
البيانات
بمجرد
قبل بدء جرابتي ".

يمكننا دعم عدد لا يحصى من أنواع مجلدات "الجلب مرة واحدة" ، git ، cvs ،
svn ،
حاويات عامل التحميل (المزيد أدناه) ، عناوين URL ، ترميز base64 في السطر
تارفيلز
stdout من برنامج آخر ، إلخ. لا أعتقد أننا نريد دعمه
أولئك
كل ذلك كمكونات إضافية لوحدة التخزين - يمكن إجراؤها كلها تقريبًا بواسطة
ا
حاوية غير مميزة دون أي مساعدة من kubelet. المزيد ، أنت
بسرعة
الوصول إلى ميزات المتابعة مثل "... وإعادة السحب من git
كل
10
دقائق "- الأشياء التي تتوقف عن كونها" تجلب مرة واحدة "وتبدأ في الوجود
نشيط
إدارة ، ولكن لا تتطلب امتيازات. نحن نستفيد كثيرا من
مثل
الأشياء داخليا.

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

الآن ، دعنا نفكر في حالة حاويات حجم بيانات عامل الإرساء.
ماذا او ما
يكون
الدلالة التي يطلبها الناس حقًا؟ فعلا:

• "تشغيل" حاوية بيانات ثم كشف الجذور الكاملة لذلك
  يركض؟
• "قم بتشغيل" حاوية بيانات ثم قم بتعريض كافة وحدات التخزين (من
  Dockerfile) كمجلدات kubernetes؟
• "قم بتشغيل" حاوية بيانات ثم قم بما يعادل
  - مجلدات - من
  إلى
  حاويات kubernetes؟

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

عنصر العمل: أرغب كثيرًا في الأشخاص الذين يستخدمون بيانات عامل الإرساء
حاويات
لوصف السلوك الذي يتوقعونه هنا.

العودة إلى حاويات السيارات الجانبية كأحجام. يمكنني تخيل شيء ما
مثل:

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data"،
المصدر: FromContainer {
الاسم: "محرجًا" ، // ما الذي يحدث هنا؟
الصورة: "kubernetes / git-volume"
EnvVars: [
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
}
}
] ،
الحاويات: [... استخدام git-data ...]
}

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

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

جراب {
المواصفات: {
أحجام: [
{الاسم: "git-data" ، المصدر: EmptyDir {}}
] ،
حاويات: [
{
الاسم: "git-puller" ،
الصورة: "kubernetes / git-volume"
EnvVars: [
{DATADIR: "/ المجلد"}،
{REPO: " http://github.com/yourname/something "}،
{RESYNC: "صحيح"}،
{RESYNC_INTERVAL: 60}
]
VolumeMounts: [{Name: "git-data"، MountPath: "/ vol"}]
} ،
{... الحاوية التي تقرأ git-data ...}
]
}
}

لا يزال مطولًا جدًا. هل يمكننا أن نفعل ما هو أفضل؟

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

أعتقد أن شيئًا كهذا هو السبيل للذهاب. التفاصيل في الظهور ،
إدخال
مطلوب.

يوم السبت ، 10 كانون الثاني (يناير) 2015 الساعة 5:42 مساءً ، آشلي أيتكين <
[email protected]

كتب:

+1 @ rehevkor5 https://github.com/rehevkor5

أشعر بخيبة أمل لسماع أن k8s لا يدعم حجم البيانات
حاويات.

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

@ rehevkor5 https://github.com/rehevkor5 اعتقدت نفس الشيء
شيء
حول
حاويات حجم البيانات في البداية (يجب كتابتها كـ FROM
خدش)
إلى أن
اقرأ هذا (الذي قد يكون أو لا يكون صحيحًا):
http://container42.com/2014/11/18/data-only-container-madness/

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

https://github.com/GoogleCloudPlatform/kubernetes/issues/831#issuecomment -69480057

.

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

https://github.com/GoogleCloudPlatform/kubernetes/issues/831#issuecomment -69484090

.

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

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

https://github.com/GoogleCloudPlatform/kubernetes/issues/831#issuecomment -69502422

.

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

.

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

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

P2 لتوثيق هذا على الأقل بشكل أفضل.

ألن تكون حاوية بيانات عامل الإرساء فقط ثابتة؟ سيكون من الرائع استخدامه مع kubernetes ، لأنني أحتاج إلى بيانات ثابتة بدون iscsi أو NFS أو host_dir (مشاكل الإذن). سأستخدم Fedora Atomic كمثال تابع واحد.

pwFoo حاليًا لا توجد آلية لمشاركة حاويات البيانات فقط بين التوابع المتعددة.

لدي إعداد مضيف / تابع واحد وأحتاج إلى تخزين محلي ثابت. Hostdir بدون إذن الإصلاح ليس حلاً ، لأن المستخدم داخل الحاوية ليس لديه أذونات للكتابة إلى وحدة التخزين.

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

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

"hostPath": { "path": "/tmp/mypod", "uid": 93, "gid": 76, "mode": 0700 }

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

لكن أولاً - هل يمكنك شرح ما تعنيه كلمة "المثابرة" بالنسبة لك؟ تحت ماذا
الشروط هي البيانات المحفوظة؟ ما هو العمر المحدد؟

يوم الأربعاء 22 أبريل 2015 الساعة 7:36 صباحًا ، كتب pwFoo [email protected] :

لدي إعداد مضيف / تابع واحد وأحتاج إلى تخزين محلي ثابت.
Hostdir بدون إذن الإصلاح ليس حلاً ، لأن المستخدم بالداخل
الحاوية ليس لديها أذونات للكتابة إلى وحدة التخزين.

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

مرحبا ثوكين ،

أحتاج إلى إعادة التشغيل لحفظ وحدات التخزين المستخدمة لتخزين قواعد بيانات mysql أو محتوى webspace. لذا فإن العمر المطلوب هو إلى الأبد (لا يعتمد على الخدمة / الجراب / وقت تشغيل المضيف). يجب حفظ التغييرات مباشرة.

نظرًا لأن لديّ إعداد تابع واحد ، يجب أن يكون hostdir بأذونات صحيحة / قابلة للتعديل (uid / gid) جيدًا في الوقت الحالي.

يعتبر

حسنًا ، سأفكر في هذا الأمر. ومع ذلك ، لا توجد وعود في الإطار الزمني.

في الجمعة ، 24 أبريل 2015 الساعة 12:47 صباحًا ، كتب pwFoo [email protected] :

مرحبا ثوكين ،

أحتاج إلى إعادة التشغيل لحفظ وحدات التخزين المستخدمة لتخزين قواعد بيانات mysql أو مساحة الويب
المحتوى. لذا فإن العمر المطلوب هو إلى الأبد (لا يعتمد على الخدمة / البود /
الجهوزية المضيف). يجب حفظ التغييرات مباشرة.

لأن لدي إعداد مينيون واحد ، هوستدير مع الصحيح / قابل للتعديل
الأذونات (uid / gid) يجب أن تكون جيدة في الوقت الحالي.

يعتبر

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

شكرا thockin :)

أريد أن أكون قادرًا على تحميل ملف BUSYBOX الثنائي من صورة busybox إلى حاوية بها صورة لا تحتوي على غلاف.

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

يوم الثلاثاء ، 12 مايو 2015 ، الساعة 4:53 مساءً ، Paul Morie [email protected]
كتب:

أريد أن أكون قادرًا على تحميل ملف BUSYBOX الثنائي من صورة BUSYBOX إلى ملف
حاوية بصورة لا تحتوي على غلاف.

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

لا شك thockin ، أردت فقط تسجيله
في الثلاثاء ، 12 مايو 2015 ، الساعة 8:18 مساءً ، كتب Tim Hockin [email protected] :

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

يوم الثلاثاء ، 12 مايو 2015 ، الساعة 4:53 مساءً ، Paul Morie [email protected]
كتب:

أريد أن أكون قادرًا على تحميل ملف BUSYBOX الثنائي من صورة BUSYBOX إلى ملف
حاوية بصورة لا تحتوي على غلاف.

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

.

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

أعتقد أن الأشخاص سيرغبون في إدارة عدة مجموعات ملفات مميزة بشكل منفصل:

• الصورة الأساسية
• أدوات التصحيح (مثل sh)
• وقت تشغيل اللغة العامة / البيئة / المتطلبات الأساسية
• تبعيات التطبيق الأخرى
• تطبيق
• بيانات التطبيق الثابتة
• تكوين التطبيق
• أسرار مختلفة (SSL ، ssh ، ...)

+1 يريد هذا!

حالة الاستخدام الخاصة بي هي كما يلي:

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

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

elibixby مثير للاهتمام - هل يمكنك فقط تحميل تلك البرامج النصية والمكتبات في مجلد NFS؟ أم أن هذا معقد للغاية بالنسبة للحل؟

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

pingthockin ، ما رأيك إذا كنا ندعم volumes-from داخل Pod كما ذكرت في # 12526؟

حسن:
لن يغير سلوك Pod
سيحررني من القيام بأشياء cp لإفراغ_دير (لا يمكنني فعل cp في Dockerfile لأن dest هو مجلد وحدة تخزين)
إنه يحل 90٪ مما يريده الناس في هذه المشكلة ويقدم طريقة جديدة لنشر التطبيقات

سيء:
نوع من طريقة الرصيف ، قد لا يحبها بعض المالكين ...

أعمال أخرى حول:
يمكننا أن نجعل blank_dir لا تنظف المحتويات في مجلد المجلد. فقط عن طريق النسخ الاحتياطي واستعادة المحتويات لاستضافة dir (هذا ما فعله docker -v).

cc @ dchen1107erictune

/ ccdalanlan

resouer زوجان من الأفكار على volumes-from :

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

+1
حالة الاستخدام المتواضعة الخاصة بي هي:

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

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

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

@ saad-ali آخر لقائمة الانتظار

+1 ، أنا فقط بحاجة إلى شيء كهذا أيضًا.

بعض الأفكار / الأفكار:

1. يجب أن نقرر ما إذا كانت هذه الميزة ستعتمد على تكوين المضيف ؛ # 8702 يتعامل مع تعميم تمثيل الصور في API ؛ أفضل عدم إنشاء ميزة عامل الإرساء فقط إذا كان بإمكاننا تجنبها. لست متأكدًا من أننا يجب أن نذهب إلى أبعد من الوعد بدعم أي تنسيق للصورة يريد المستخدم استخدامه بغض النظر عن تكوين المضيف ، ولكن هناك بالتأكيد بعض إمكانية الربط الضمني بين هذه الميزة ووقت تشغيل الحاوية الذي تستخدمه ، وذلك يجب أن يكون على الأقل صريحًا.
2. لا أحب فكرة أن تتزامن الحاويات مع البيانات لتجنب السباقات. أعتقد أنه إذا تقدمنا ​​بهذه الميزة ، فيجب أن تكون البيانات متاحة في الحجرة عند بدء تشغيل البود. لإنجاز ذلك باستخدام عامل الإرساء ، أعتقد أننا سنحتاج إلى تشغيل حاوية ، ونسخ عامل الإرساء مسارًا خارج الحاوية إلى المضيف ، وحذف الحاوية. ربما هناك أشياء أكثر تعقيدًا يمكننا القيام بها لتخزين الأشياء مؤقتًا لتجنب القيام بذلك في كل مرة نبدأ فيها الكبسولة.

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

1. نعم اتفق معك. الميزات الخاصة بـ Docker ليست جيدة. على الأقل ، نحتاج إلى تحديد ذلك بناءً على containerRuntime وتحذير المستخدم
2. في الواقع ، نسخ البيانات هو ما أحاول فعله في الأصل في # 12526. ولكن في الوقت الحالي ، لا يدعم Pod مهمة لمرة واحدة بشكل جيد: أ) سيعيد RC إعادة تشغيل الحاوية باستمرار ، ب) إعادة تشغيل السياسة ليست خاصة بالحاوية.

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

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

هذه المشكلة هي كيفية إنشاء طريقة ملائمة وقابلة للتوسيع للحصول على البيانات في وحدات التخزين. يعد استمرار البيانات المحلية مشكلة أخرى - # 7562. حالة استخدام --volumes-from فقط لتتبع وحدة تخزين مشتركة أثناء استخدامها ليست ذات صلة بـ Kubernetes.

أعتقد أن هناك حالتين على الأقل يمكننا دعمهما هنا:

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

بعض القضايا التي يجب حلها مع هذا الأخير:

• سلوك إعادة المحاولة - على سبيل المثال ، التمييز بين الفشل الدائم من الممكن إعادة المحاولة
• تحديث السلوك
  
  
  
  • هل نسمح بتحديث حاوية الإعداد؟
  
  
  • إذا كان الأمر كذلك ، فهل هذا يقتل جميع حاويات البودات قيد التشغيل؟ أو فقط تلك التي تعتمد على الحجم (الأحجام) التي تكتبها؟
  
  
• ما هو سياق التنفيذ ، مثل سياق الأمان المسموح به ، والأسرار المتاحة ، ووحدات التخزين الأخرى المرئية ، وما يحدث للسجلات ، وما إلى ذلك.
  
  
  
  • ستكون الإجابات أبسط إذا كانت مجرد حاوية بنموذج تبعية بسيط (على سبيل المثال ، جميع حاويات الإعداد بشكل متزامن أو بترتيب عشوائي ، ثم جميع حاويات الكبسولات العادية إذا / بمجرد نجاح جميع حاويات الإعداد).
  
  
  • ومع ذلك ، فإن عدم معرفة مكان كتابة البيانات (على سبيل المثال ، أي حجم) ، وما إذا كانت الحاوية آمنة للتنفيذ على وحدات تخزين غير فارغة ، وما إذا كان لها آثار جانبية أخرى ، وما إلى ذلك ، يمكن أن تجعل إعادة المحاولة وتحديث الدلالات أكثر صعوبة ، وتقليل العزلة بين حاوية الإعداد وبقية الكبسولة (على سبيل المثال ، احتمال كشف الأسرار).
  
  
• من الناحية المثالية ، أي خلفية تخزين موجودة - EmptyDir (tmpfs أو قرص) ، PD ، NFS ، إلخ - ستكون قابلة للاستخدام. لأي شيء بخلاف EmptyDir جديد ، يجب أن تكون الحاوية آمنة للاستدعاء على وحدة تخزين غير فارغة.
  
  
  
  • يشير هذا إلى أنه لا ينبغي تمثيل الآلية كنوع وحدة تخزين جديد ، ولكن ربما كخطاف لتهيئة الحجم.
  
  
  • إذا كانت الحاوية بأكملها مرئية للحاوية ، فسيكون من المنطقي تمثيل الحاوية كخطاف جراب أو خاصية حاوية خاصة أكثر من كونها خطاف وحدة تخزين.
  
  
• تسطيح الأخطاء (وربما التقدم؟)
• المصدر والتدقيق وما إلى ذلك.

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

من المحتمل أن يكون هذا مشابهًا لحالة استخدام الحاوية git . ومع ذلك ، من السهل استخدام صور عامل الإرساء باعتبارها الطريقة الوحيدة لتوزيع القطع الأثرية وكذلك _not_ check-in minified css / js.

حاليًا ، نحقق ذلك بإحدى طريقتين:

1. نسخ الملفات في البداية من حاوية أخرى في الحاوية.
2. تثبيت nginx في صورتنا بحيث يمكن استخدام نفس الحاوية إما للأصول الثابتة أو لخادم التطبيقات.

هتافات!

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

scrisenbery برنامج نصي لبدء bash ينتظر وجود الملفات. مثال:

_حاوية توفر الملفات_

# Copy the files to a temporary shared folder
cp -r /src/files /mnt/shared/files_tmp

# Rename the folder so that all files are available atomically
mv /mnt/shared/files_tmp /mnt/shared/files

_حاوية تتطلب ملفات_

# Sleep until the shared files exist
until [ -d /mnt/shared/files ]; do sleep 1; done

# Start the application
./start.sh

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

kjvalencik في الوقت الحالي ، نستخدم نقطة إدخال الحاويات (وهي عبارة عن logstash في هذه الحالة) ونرسل لها وسيطة للعثور على ملف التكوين في الدليل المثبت.

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

scrisenbery لا يزال بإمكانك استخدام الصورة الافتراضية ، لكنك تحتاج إلى توفير نقطة الدخول الخاصة بك التي تستدعي الصورة الافتراضية. مثال لم يتم اختباره:

kind: Pod
apiVersion: v1
metadata:
  name: logstash
spec:
  containers:
  - name: config
    image: my-logstash-config-container
    command:
    - /bin/bash
    - -c
    - cp /src/logstash.conf /mnt/shared/logstash.conf;
      while true; sleep 10; done
    volumeMounts:
    - name: shared
      mountPath: /mnt/shared
  - name: logstash
    image: logstash
    command:
    - /bin/bash
    - -c
    - until [ -e /mnt/shared/logstash.conf ]; do sleep 1; done &&
      /docker-entrypoint.sh logstash agent -f /mnt/shared/logstash.conf
    volumeMounts:
    - name: shared
      mountPath: /mnt/shared
  volumes:
  - name: shared
    emptyDir: {}

bkeroackdsc ليس لدي أي مشاكل في القيام بذلك. المفتاح هو التأكد من أن جميع الملفات أصبحت متاحة تلقائيًا - وبالتالي ، فإن الأمر cp إلى موقع مؤقت ثم أمر mv .

مع ذلك ، ما زلت أرغب في رؤية هذه الميزة مطبقة من أجل تقليل التنسيق المعياري.

على الرغم من أن إحدى مزايا طريقة cp هي أنه يمكنك إعادة تشغيل الحاوية التي تنقل الملفات إلى الدليل المشترك لتحديث البيانات دون إزالة وإعادة جدولة الحاوية بأكملها.

تعديل : secrets . http://kubernetes.io/v1.0/docs/user-guide/secrets.html

@ scrisenbery مثال باستخدام الأسرار.

أنشئ هذا الملف في نفس الدليل مثل logstash.conf .
logstash-secret.yaml.sh

#!/bin/bash

DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
CONF=$(base64 $DIR/logstash.conf | tr -d "\n")

cat << EOF
kind: Secret
apiVersion: v1
metadata:
  name: logash-config
data:
  logstash.conf: $CONF
EOF

خلق السر

./logstash-secret.yaml.sh | kubectl create -f -

جراب Logstash

kind: Pod
apiVersion: v1
metadata:
  name: logstash
spec:
  containers:
  - name: logstash
    image: logstash
    args:
    - -f
    - /mnt/config/logstash.conf
    volumeMounts:
    - name: logstash-config
      mountPath: /mnt/config
  volumes:
  - name: logstash-config
    secret:
      secretName: logstash-config

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

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

1. احذف السر القديم
2. قم بإنشاء السر الجديد
3. إعادة التشغيل المتداول للبودات التي تستخدم السر

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

kjvalencik هل العمل السري في JSON مقابل YAML؟

ملاحظة سريعة:

نحتاج (على الأقل) شيئين:

1. جبل من صورة أخرى
2. تشغيل الحاوية لملء وحدة تخزين

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

@ scrisenbery : أعتقد أن الهدف # 6477 هو تغطية حالة ملف التكوين قبل أن نواجه هذه المشكلة. إنني أتطلع بالفعل إلى هذه المشكلة بالنسبة إلى blob sidecars الكبيرة: أشياء مثل ملفات .jar ، أو ملحقات Jenkins ، وما إلى ذلك ، التي تريد تكوينها باستخدام صورة أساسية.

شكرًا zmerlynn ، لم أجد ذلك من قبل. يبدو أن هذا لا يزال قيد التنفيذ أيضًا ، أليس كذلك؟ إذن في الوقت الحالي أنا مقيد بالأسرار؟

scrisenbery شاهد تعليقاتي حول وضع السيارة https://gist.github.com/resouer/378bcdaef1d9601ed6aa

وآسف لتأخري في الرد.

طلب اخر:
http://stackoverflow.com/questions/33672380/how-to-build-a-sidecar-container-for-passing-files-from-a-machine-outside-of-the

كان شخص ما من RH ينظر إلى جبل من صورة أخرى - rhatdan ، الذي كان
الذي - التي؟

في 11 تشرين الثاني (نوفمبر) 2015 ، الساعة 2:41 مساءً ، كتب Brian Grant [email protected] :

ملاحظة سريعة:

نحتاج (على الأقل) شيئين:

1. جبل من صورة أخرى
2. تشغيل الحاوية لملء وحدة تخزين

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

لدينا القدرة عبر التركيب الذري لتركيب صور الحاوية.

في 17/11/2015 06:36 مساءً ، كتب كلايتون كولمان:

شخص من RH كان ينظر إلى جبل من صورة أخرى -rhatdan ،
من كان
الذي - التي؟

في 11 تشرين الثاني (نوفمبر) 2015 ، الساعة 2:41 مساءً ، كتب Brian Grant [email protected] :

ملاحظة سريعة:

نحتاج (على الأقل) شيئين:

1. جبل من صورة أخرى
2. تشغيل الحاوية لملء وحدة تخزين

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

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

عندما قدمت هذا الخطأ ، قصدت حقًا أنه يمكننا "تشغيل" الحاويات التي تحتوي على تعريفات VOLUME ثم استخدام تلك الموجودة في حاويات التطبيق (كما هو الحال في --volumes-from ولكن يمكن تحميلها في أي مكان). هذا كل شئ. الحاويات الأولية نظيفة ، ويجب أن نفعل ذلك تمامًا ، لكني قدمت هذا ردًا على "لديّ جميع بياناتي في حاوية مع تحديد VOLUME في Dockerfile - لماذا لا يمكنني استخدامها". أفضل ما يمكنني قوله لا يؤدي إلى أي نسخ.

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

لذا ، حاويات البيانات ، نعم ، يجب علينا ذلك.

هل ما زلنا بحاجة إلى القدرة على عمل مجلدات من؟

راجع للشغل ، فإن القدرة على تركيب صورة أخرى ستمنحنا إمكانية تكوين مشابهة لما نحصل عليه من مدير الحزم في Borg:
https://www.usenix.org/sites/default/files/conference/protected-files/lisa_2014_talk.pdf

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

يوم الخميس ، 19 تشرين الثاني (نوفمبر) 2015 الساعة 7:30 مساءً ، Brian Grant [email protected]
كتب:

راجع للشغل ، فإن القدرة على تركيب صورة أخرى ستمنحنا قابلية التركيب
مشابه لما نحصل عليه من مدير الحزم في Borg:

https://www.usenix.org/sites/default/files/conference/protected-files/lisa_2014_talk.pdf

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

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

يوم الجمعة ، 20 تشرين الثاني (نوفمبر) 2015 الساعة 2:27 صباحًا ، Tim Hockin [email protected]
كتب:

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

يوم الخميس ، 19 تشرين الثاني (نوفمبر) 2015 الساعة 7:30 مساءً ، Brian Grant [email protected]
كتب:

راجع للشغل ، فإن القدرة على تركيب صورة أخرى ستمنحنا قابلية التركيب
مشابه لما نحصل عليه من مدير الحزم في Borg:

https://www.usenix.org/sites/default/files/conference/protected-files/lisa_2014_talk.pdf

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

.

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

ccerinboyd

حالات استخدام أخرى:

16010

https://github.com/flynn/flynn/tree/master/slugrunner ، إذا لم يكن يدعم بالفعل السحب من عنوان URL

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

تحدث جو بيدا أيضًا عن هذا التركيب في ميداس في هذه المدونة الرائعة .

بالنسبة لحالة الاستخدام الخاصة بنا ، سيكون من الرائع وضع طبقات بسيطة من صور عامل الإرساء الثابتة (سواء من خلال --volumes-from أو واجهات برمجة التطبيقات لمجلدات Kubernetes). غالبًا ما يكون لدينا أصول ثابتة متوسطة الحجم (أقل من 4 جيجابايت) يتم إعادة استخدامها بواسطة آلاف الكبسولات بطريقة للقراءة فقط. ستكون إعادة استخدام ذاكرة التخزين المؤقت لصورة عامل الإرساء لهذه الأنواع من الأصول أفضل بكثير من نظامنا الحالي (إرفاق وحدات تخزين من اللقطات بهذه البيانات إلى كل مثيل عامل ثم تثبيت هذا المسار hostDir لكل حاوية.

أضافت philips لك كما تحدثت عن هذا في كلمتك الرئيسية :) هل يمكنكم يا رفاق تخصيص مورد لتنفيذ هذا (كبداية) لـ 1.3؟

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

markpaychex هل ConfigMap لا يحل هذه المشكلة بالنسبة لك؟

pmorie ستعمل مع بعض الأشياء ولكن لا أعتقد أنها ستغطي جميع القواعد (مثل ملفات xml من المكتبات التي تتطلب التهيئة من ملف والملفات المذكورة مختلفة في بيئات مختلفة).

markpaychex ، يمكنك عرض مفاتيح configmap في ملفات ، ومورد واجهة برمجة التطبيقات لا يعرف تمامًا ما ترميه في الملفات - يمكنك تخزين json blobs و yaml blobs و xml وما تريده.

markpaychex عذرًا ، المقصود منه الارتباط بالمستندات سابقًا على ConfigMap ، يرجى إعلامي إذا كان هذا يساعد في توضيح:

http://kubernetes.io/docs/user-guide/configmap/

pmorie نعم قد يعمل ذلك ،

لدينا أيضًا حاجة لذلك ، خاصة لتشغيل nginx & php-fpm. لا يعد مستودع git حلاً مقبولاً بالنسبة لنا بسبب الأذونات على المستودعات ، ونفضل أن يتم إنشاء الملفات الفعلية في صورة يمكن توزيعها لحفظ التبعيات الخارجية على خوادم git وما إلى ذلك.

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

أي تحديث على هذا؟

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

يقترح https://github.com/kubernetes/kubernetes/pull/23666 حاويات init التي يمكن استخدامها لملء وحدات التخزين مسبقًا. سيؤدي هذا إلى التخلص من الكثير من الحاجة إلى حجم حاوية ثابت للقراءة فقط. الحجة الوحيدة التي يمكن أن أراها لأنني ما زلت أرغب في وحدة تخزين مدعومة من الحاوية هي أنه مع حاويات init ، ما زلت بحاجة إلى التنزيل مرة واحدة لكل جراب - مقابل وحدة تخزين مدعومة من الحاوية ، سيتم تنزيلها مرة واحدة فقط لكل عقدة (نظرًا لأن الحاوية هي مخبأة بواسطة العقدة) - والذي سيكون تحسينًا رائعًا لمجموعات البيانات الثابتة الكبيرة جدًا.

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

في يوم الإثنين 25 أبريل 2016 الساعة 2:02 ظهرًا ، كتب سعد علي [email protected] :

23666 https://github.com/kubernetes/kubernetes/pull/23666 يقترح

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

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

@ saad-ali أعتقد أن المقترحات هنا أفضل من حاويات init لغرض تهيئة وحدات التخزين. راجع https://github.com/kubernetes/kubernetes/pull/23666#discussion_r59081733 والتعليقات الأخرى في تلك العلاقات العامة لمزيد من التفاصيل.

لا يمكن أبدًا تنفيذ أنواع وحدات التخزين المخصصة للصور بشكل فعال
مع حاويات init (مجرد نماذج أولية) ، لذلك لا تزال هذه حاجة صالحة.

يوم الجمعة ، 29 أبريل 2016 الساعة 4:58 مساءً ، Brian Grant [email protected]
كتب:

@ saad-ali https://github.com/saad-ali أعتقد أن المقترحات هنا
متفوقة على حاويات التهيئة لغرض تهيئة وحدات التخزين. انظر # 23666
(تعليق)
https://github.com/kubernetes/kubernetes/pull/23666#discussion_r59081733
وغيرها من التعليقات في هذا العلاقات العامة لمزيد من التفاصيل.

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

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

ملاحظة - @ saad-ali معذرة ، هناك الكثير من المناقشات والحجج الإضافية هنا ... هل من الصحيح أن هناك نية لتنفيذ حاويات البيانات كأنواع وحدات التخزين في الإصدار 1.4 كما هو موضح هنا ، أم أنني أسيء الفهم؟

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

يوم الخميس ، 14 تموز (يوليو) 2016 ، الساعة 11:32 صباحًا ، Kevin Kuhl [email protected]
كتب:

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

ملاحظة - @ saad-ali https://github.com/saad-ali معذرة ، هناك الكثير
المناقشة والحجة الإضافية هنا ... هل من الصحيح أن هناك
العزم على تنفيذ حاويات البيانات كأنواع وحدات التخزين في الإصدار 1.4 كما هو محدد
هنا أم أنا أسوء الفهم؟

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

هل من الصحيح أن هناك نية لتنفيذ حاويات البيانات كأنواع وحدات التخزين في الإصدار 1.4

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

@ alph486 هل يمكنني طرح سؤال أساسي؟ إذا كنت تقوم بالفعل بقطع وحدة تخزين عامل إرساء ، فلماذا لا تبنيها في جراب؟ على سبيل المثال

apiVersion: v1
kind: Pod
metadata:
  name: MLApp
  labels:
    app: mlapp
spec:
  containers:
    - name: static-model
      image: my-static-model-image
      volumeMounts:
        - name: model-storage
          mountPath: /data/model-storage
    - name: model-processor
      image: my-model-processor-image
      volumeMounts:
        - name: model-storage
          mountPath: /data/model-storage
  volumes:
    - name: model-storage
      emptyDir: {}

ثم ، عندما يبدأ my-static-model-image ، انسخ المحتوى الثابت إلى وحدة تخزين ، والمعزوفة ، تتم مشاركته.

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

aronchick @ alph486 هذا النمط يبدو جيدًا بالنسبة لي. إنه استخدام جديد للأوليات الموجودة ، ويبدو أنه يؤدي المهمة.

هل ستوفر حاويات الحجم فائدة كبيرة على نمط aronchick ؟

كانت الفكرة هي تجنب نسخها وإدارتها.

يوم الجمعة ، 15 تموز (يوليو) 2016 ، الساعة 1:55 مساءً ، Elson Rodriguez [email protected]
كتب:

aronchick https://github.com/aronchick @ alph486
https://github.com/alph486 يبدو هذا النمط جيدًا بالنسبة لي. إنها رواية
استخدام الأوليات الموجودة ، ويبدو أنها تؤدي المهمة.

هل ستوفر حاويات الحجم فائدة كبيرة علىaronchick
نمط https://github.com/aronchick ؟

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

في حين أن هذا هو النسخ ، فهو ليس يدويًا (حقًا) ، أليس كذلك؟

فكرة مجنونة - بما أن الحاويات تشترك في مساحة الذاكرة ، فهل سيكون الارتباط الرمزي متاحًا بين الحاويات؟

أنا أتابع هذه المشكلة منذ أكثر من عام الآن.

في مثالaronchick الأخير

https://github.com/kubernetes/kubernetes/issues/831#issuecomment -23300722

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

شكرا لك.

تتطلب ارتباطاتaronchick الرمزية مساحة تحميل مشتركة ، وهي ليست لدينا.

@ ae6rt ما اقترحه ديفيد كان:

عندما يبدأ my-static-model-image ، انسخ المحتوى الثابت إلى وحدة تخزين ، والمعزوفة ، تتم مشاركتها.

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

هل أفهم من هذا أن استخدام سيارة جانبية تحتوي على بيانات و
يشاركها بكتابة رابط رمزي
إلى دليل على نظام الملفات الخاص به لن يعمل عند الوصول إليه من ملف
حاوية "رئيسية" (أخرى) في الحجرة؟

يوم الأحد 17 يوليو 2016 الساعة 11:35 مساءً Tim Hockin [email protected]
كتب:

طلبaronchick https://github.com/aronchick symlinks تحميلًا مشتركًا
الفضاء الذي ليس لدينا.

@ ae6rt https://github.com/ae6rt ما اقترح ديفيد كان:

عندما يبدأ my-static-model-image ، انسخ المحتوى الثابت إلى مجلد ،
والمعزوفة ، يتم مشاركتها.

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

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

صيح. سيتم حل الارتباط الرمزي بالنسبة للقارئ.

يوم الأحد ، 17 تموز (يوليو) 2016 ، الساعة 9:43 مساءً ، Kevin Kuhl [email protected]
كتب:

هل أفهم من هذا أن استخدام سيارة جانبية تحتوي على بيانات و
يشاركها بكتابة رابط رمزي
إلى دليل على نظام الملفات الخاص به لن يعمل عند الوصول إليه من ملف
حاوية "رئيسية" (أخرى) في الحجرة؟

يوم الأحد 17 يوليو 2016 الساعة 11:35 مساءً Tim Hockin [email protected]
كتب:

طلبaronchick https://github.com/aronchick symlinks تحميلًا مشتركًا
الفضاء الذي ليس لدينا.

@ ae6rt https://github.com/ae6rt ما اقترح ديفيد كان:

عندما يبدأ my-static-model-image ، انسخ المحتوى الثابت إلى مجلد ،
والمعزوفة ، يتم مشاركتها.

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

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

.

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

مع اقتراب CRI ، بقدر ما أعتقد أن هذا حل يحتاجه معظم الناس ، فإنه يعقد محاولة تنفيذ شيء كهذا. thockin / @ dchen1107 هل هناك ميزة تجميد في kubelet حتى تصل CRI إلى alpha؟

ليس تجميدًا بحد ذاته ، ولكن كل تغيير جديد يحتاج إلى معالجة كيفية تفاعله
مع CRI

يوم الخميس ، 22 سبتمبر 2016 الساعة 8:59 صباحًا ، Clayton Coleman [email protected]
كتب:

مع ظهور CRI في الأفق ، بقدر ما أعتقد أن هذا هو الحل لمعظم الناس
الحاجة ، فإنه يعقد محاولة تنفيذ شيء من هذا القبيل.
thockin https://github.com/thockin / @ dchen1107
https://github.com/dchen1107 هل هناك ميزة تجميد في kubelet
حتى تصل CRI إلى alpha؟

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

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

هذا يأتي بشكل كافٍ من المستخدمين النهائيين من جانبنا الآن ، فأنا أميل إلى ذلك
قم بزيادة الأولوية لـ 1.6 لمحاولة ذلك.

يوم الخميس ، 22 سبتمبر 2016 الساعة 12:02 مساءً ، Tim Hockin [email protected]
كتب:

ليس تجميدًا بحد ذاته ، ولكن كل تغيير جديد يحتاج إلى معالجة كيفية تفاعله
مع CRI

يوم الخميس ، 22 سبتمبر 2016 الساعة 8:59 صباحًا ، كلايتون كولمان < [email protected]

كتب:

مع ظهور CRI في الأفق ، بقدر ما أعتقد أن هذا هو الحل لمعظم الناس
الحاجة ، فإنه يعقد محاولة تنفيذ شيء من هذا القبيل.
thockin https://github.com/thockin / @ dchen1107
https://github.com/dchen1107 هل هناك ميزة تجميد في kubelet
حتى تصل CRI إلى alpha؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
831 # issuecomment-248946693> ،
أو كتم الخيط
المصادقة / AFVgVCKIfJhDq4w49ZRzDI_szbvuG70rks5qsqXggaJpZM4CVXlA>

.

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

سوف يتطلب الأمر بعض الألعاب البهلوانية للقيام به بشكل سليم.

يوم الخميس ، 22 سبتمبر 2016 الساعة 9:13 صباحًا ، Clayton Coleman [email protected]
كتب:

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

هذا يأتي بشكل كافٍ من المستخدمين النهائيين من جانبنا الآن ، فأنا أميل إلى ذلك
قم بزيادة الأولوية لـ 1.6 لمحاولة ذلك.

يوم الخميس ، 22 سبتمبر 2016 الساعة 12:02 مساءً ، Tim Hockin [email protected]
كتب:

ليس تجميدًا في حد ذاته ، ولكن كل تغيير جديد يحتاج إلى معالجة كيفية ذلك
يتفاعل
مع CRI

يوم الخميس ، 22 سبتمبر 2016 الساعة 8:59 صباحًا ، كلايتون كولمان <
[email protected]

كتب:

مع CRI يلوح في الأفق ، بقدر ما أعتقد أن هذا هو الحل الأكثر
اشخاص
الحاجة ، فإنه يعقد محاولة تنفيذ شيء من هذا القبيل.
thockin https://github.com/thockin / @ dchen1107
https://github.com/dchen1107 هل هناك ميزة تجميد في ملف
kubelet
حتى تصل CRI إلى alpha؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
831 # issuecomment-248946693> ،
أو كتم الخيط
المصادقة / AFVgVCKIfJhDq4w49ZRzDI_szbvuG70rks5qsqXggaJpZM4CVXlA>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
831 # issuecomment-248947660> ،
أو كتم الخيط
p1NDn3hpUS0Nw6CKWzbx3exfjvWhks5qsqaCgaJpZM4CVXlA>
.

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

في الواقع.

يوم الخميس ، 22 سبتمبر 2016 الساعة 12:18 مساءً ، Tim Hockin [email protected]
كتب:

سوف يتطلب الأمر بعض الألعاب البهلوانية للقيام به بشكل سليم.

يوم الخميس ، 22 سبتمبر 2016 الساعة 9:13 صباحًا ، كلايتون كولمان < [email protected]

كتب:

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

هذا يأتي بشكل كافٍ من المستخدمين النهائيين من جانبنا الآن ، فأنا أميل إلى ذلك
قم بزيادة الأولوية لـ 1.6 لمحاولة ذلك.

يوم الخميس ، 22 سبتمبر 2016 الساعة 12:02 مساءً ، Tim Hockin [email protected]
كتب:

ليس تجميدًا في حد ذاته ، ولكن كل تغيير جديد يحتاج إلى معالجة كيفية ذلك
يتفاعل
مع CRI

يوم الخميس ، 22 سبتمبر 2016 الساعة 8:59 صباحًا ، كلايتون كولمان <
[email protected]

كتب:

مع CRI يلوح في الأفق ، بقدر ما أعتقد أن هذا هو الحل الأكثر
اشخاص
الحاجة ، فإنه يعقد محاولة تنفيذ شيء من هذا القبيل.
thockin https://github.com/thockin / @ dchen1107
https://github.com/dchen1107 هل هناك ميزة تجميد في ملف
kubelet
حتى تصل CRI إلى alpha؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
831 # issuecomment-248946693> ،
أو كتم الخيط
المصادقة / AFVgVCKIfJhDq4w49ZRzDI_szbvuG70rks5qsqXggaJpZM4CVXlA>

.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
831 # issuecomment-248947660> ،
أو كتم الخيط
p1NDn3hpUS0Nw6CKWzbx3exfjvWhks5qsqaCgaJpZM4CVXlA>
.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
831 # issuecomment-248950801> ،
أو كتم الخيط
NPtjUzgOWnpiDks5qsqlFgaJpZM4CVXlA>

.

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

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

ما هو CRI؟

CRI هي واجهة برمجة تطبيقات kubelet الداخلية التي تلخص أوقات تشغيل الحاوية ، و
يسمح بالمبادلة في rkt ، docker ، OCI ، hyper ، إلخ.

يوم الخميس ، 22 سبتمبر 2016 الساعة 10:59 صباحًا ، Derek Mahar [email protected]
كتب:

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

ما هو CRI؟

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

cc فعل

ديريك:
https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/container-runtime-interface-v1.md

يوم الخميس ، 22 سبتمبر 2016 الساعة 10:58 صباحًا Derek Mahar [email protected]
كتب:

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

ما هو CRI؟

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

حالة استخدام أخرى:

• يمكن للمستخدمين تسجيل الدخول عبر SFTP وتحميل / تنزيل الوسائط إلى موقع الويب
• يتم تخزين شفرة مصدر PHP في حاوية Apache عبر Docker ADD
• يوجد بروتوكول SFTP في حاويته الخاصة ، لذا لا يتعين على Apache تشغيل الامتيازات
• في وقت لاحق ، سيكون حجم "الوسائط" عبارة عن حاوية NFS عندما يكون أكثر استقرارًا.

جراب

• حاوية اباتشي
  
  
  
  • تحميل وحدة تخزين PD "الوسائط"
  
  
• الحاوية SFTP (يتم تشغيلها بامتياز لربط التثبيت عند بدء التشغيل بمستخدمي SFTP home dir)
  
  
  
  • تحميل وحدة تخزين PD "الوسائط"
  
  

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

1) قم بتشغيل برنامج نصي للترقية على Apache (لدينا بائع يتطلب هذا النوع من الترقية).
2) تسجيل الدخول إلى SFTP وتنزيل ملفات "المصدر" التي تم تغييرها إلى مستودع git محلي.
3) إعادة بناء حاوية Apache واختبارها.

الحل:

يمكننا تحميل ملف فارغ في كلتا الحاويات ونسخ المصدر من Apache إلى مجلد Dir الفارغ بعد الترقية ، مما يجعله متاحًا لحاوية SFTP.

نظرًا لأننا نشغل حاوية SFTP "بامتياز" ، فقد نتمكن من التحميل في مجلد حاويات Apache / var / www / html / site ولكني لست متأكدًا من كيفية القيام بذلك.

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

رائع ، خيط طويل ، حاولت قراءة كل شيء ، لكن ربما فاتني شيء على طول الطريق.

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

justechn إذا فهمت متطلباتك ، يجب أن تفعل StateFulset ما تريد. اعتمادًا على السحابة ، ستوفر لك PV مرتبطة بمثيل قاعدة البيانات. في GCE - سيكون هذا قرص PD عادي - يمكنك التقاطه ، والنسخ الاحتياطي ، وما إلى ذلك ،

+1

قد يكون هذا مفيدًا لبناء FaaS ، أيضًا:

https://github.com/kubeless/kubeless/issues/148

وللبيانات التي تكون كبيرة جدًا بالنسبة إلى ConfigMap.

من اجتماع المجتمع اليوم: سيكون من الرائع أن يقوم شخص ما بعمل نموذج أولي لهذا على أنه FlexVolume

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

@ bgrant0607 أو أي شخص آخر مهتم بإثبات المفهوم؟ يرجى مراجعة https://github.com/dims/docker-flexvol

dims أنيق! أفترض أنه يمكنني ملء هذا الحجم باستخدام ADD /my-files /data-store ؟

@ bgrant0607 نعم بالطبع ، تم تحديث حاوية العينة وإضافة بعض الآثار - https://github.com/dims/docker-flexvol#container -image-with-pre-selected-volume

رائع جدا dims

(تحرير: أسماء :))

@ bgrant0607thockin @ alph486 - إضافة دعم لجعل نسخة من صورة حاوية كاملة متوفرة لجراب في مناقشة متواجد حاليا

dims مثال حالة الاستخدام: # 16010. و FaaS ، وفصل التطبيقات / التبعيات / وقت التشغيل بشكل عام. وبيانات التطبيق كبيرة جدًا بالنسبة لـ ConfigMap.

مفيد أيضًا لنمط "التكوين غير القابل للتغيير" (على سبيل المثال ، راجع https://github.com/k8spatterns/examples/blob/master/configuration/ImmutableConfiguration/README.adoc كيف يتم تنفيذه حاليًا عبر حاويات init).

إذا كنا لا نريد الاعتماد على إنشاء / تصدير عامل الإرساء ، فإن الخيارات الأخرى للاستكشاف هي

1. بوسيتا / ديمغكس
2. حاويات / صورة مباشرة أو باستخدام skopeo CLI
3. استكشاف قطعة صورة من containerd (إما كمكتبة أو عبر grpc)

على الرغم من أن الرقم 2 لا يبدو أنه يدعم سحق الصورة

هنا حالة استخدام - أي أفكار أو تعليقات موضع تقدير.

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

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

ما هو مفضل هو الحصول على صورتين ، واحدة لـ "did" ، وواحدة للتطبيق ، ولكن يمكنك تشغيل أوامر docker في حاوية "did" من حاوية التطبيق.

يمكنني القيام بذلك باستخدام مجلدات من و / var/run/docker.sock المتصاعدة في حاوية التطبيق من حاوية "فعلت".

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

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

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

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

تعجبني حقًا فكرة حاوية عامل الإرساء كمجلد من وجهة نظر ، فهي تتيح لك إعادة استخدام كل البنية لتوزيع الحاويات. سجلات doccker القابلة للتطوير ، والتخزين المؤقت للصور ، وما إلى ذلك ، كما تتيح لك فصل الاهتمامات. يمكنك إنشاء موقع ويب ثابت قابل للتطوير من خلال وجود حاوية حجم بها محتوى الويب الخاص بك وحاوية رئيسية لـ nginx. سيكون لكل جراب بعد ذلك حاويتان كوحدة قابلة للتطوير ، وكل واحدة قابلة للتحديث على حدة.

renewooller هل جربت الحجم المرن؟ https://github.com/dims/docker-flexvol

لا ، فاتني ذلك. شكرا على المؤشر. انه مشوق جدا. :)

أهلا،

أقوم بإضافة حالة الاستخدام الخاصة بي كمثال. يبدو أن عامل التحميل - flexvol هو ما أحتاجه. يجب أن يعمل استخدام eemptyDir مع النسخ أيضًا ولكنه سيء.

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

الفكرة هي إنشاء جراب بحاوية nginx واحدة وتركيب الملفات من حاويات عامل التحميل كوحدات تخزين.

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

لذلك إذا كانت لدي صورة تسمى my-container-image في الريبو الخاص بي:
""

• الاسم: الاختبار
  فليكسفولوم:
  سائق: "dims.io/docker-flexvol"
  والخيارات:
  الصورة: "my-container- image: v1 "
  الاسم: "/ data-store"
  and update the pod to contain:
• الاسم: الاختبار
  فليكسفولوم:
  سائق: "dims.io/docker-flexvol"
  والخيارات:
  الصورة: "my-container- image: v2 "
  الاسم: "/ data-store"
  ""

أتوقع أن يُجري Kubernetes تحديثًا مستمرًا للإصدار الجديد من تطبيقي باستخدام my-container- image: v2

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

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

أما بالنسبة إلى kubeadm المنبع وما إلى ذلك ، إذا أراد شخص ما أخذ زمام المبادرة ، فيمكنني المساعدة.

شكرا،
يخفت

سأكون مهتمًا بالحصول على هذا في مخطط الدفة بطريقة ما ... رأيت أدوات تحميل حاوية مدمجة لكنهم يقولون إنها لا تعمل مع flexVolumes. ربما شيء مثل:
https://github.com/openstack/kolla-kubernetes/blob/master/helm/microservice/ceph-rbd-daemonset/templates/ceph-rbd-daemonset.yaml

مع مساحات اسم جبل مشتركة؟

بالتناوب ، إذا تمكنا من الحصول على jq مرتبط بشكل ثابت ، فقد نتمكن من تمرير الملفين مباشرة على المضيف ....

أو ، أعتقد أننا يمكن أن نبصق الفرق ونشغل jq في حاوية ... docker run -i --rm jq ....

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

في جميع الحالات ، يعود الأمر إلى الرغبة في تعريض الملفات الثابتة لأكثر من عملية / حاوية واحدة.

بالنسبة لنا هذا يعني:

• كشف dir من الحاوية A (php runtime with static frontend) إلى الحاوية B (العامة nginx) لخدمة الملفات الثابتة (css / js) فقط.
• كشف dir من الحاوية A (static js frontend) إلى الحاوية B (nginx عام) لخدمة تلك الملفات.

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

ربما يمكن حل بعض الحالات عن طريق حجب إجراء النسخ المطلوب والتأكد من نجاحه.

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

على أي حال ، فقط سنتان.

كشف dir من الحاوية A (php runtime with static frontend) إلى الحاوية B (العامة nginx) لخدمة الملفات الثابتة (css / js) فقط.
كشف dir من الحاوية A (static js frontend) إلى الحاوية B (nginx عام) لخدمة تلك الملفات.

لقد وجدت أن تصميمات Docker الحديثة متعددة المراحل تسمح لك إلى حد كبير بالقيام بذلك على مستوى بناء عامل الإرساء.

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

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

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

+1

يجب أن يجعل دعم وحدة تخزين csi المؤقتة مع https://github.com/kubernetes-csi/csi-driver-image-populator هذا الأمر ممكنًا. :)

@ kfox1111 رائع ، شكرًا!

راجع للشغل ، تم وصف آلية "الحزمة" الداخلية القابلة للإنشاء في Google في هذا الحديث:
https://www.usenix.org/sites/default/files/conference/protected-files/lisa_2014_talk.pdf
والذي ورد في كتاب SRE:
https://landing.google.com/sre/sre-book/chapters/release-engineering/

+1