التقرير مخصص للقضايا العملية المتعلقة بتطوير مشغل في Kubernetes ، وتصميم بنيته ومبادئ التشغيل الأساسية.
في الجزء الأول من التقرير ، سننظر في:
- ما هو عامل التشغيل في Kubernetes ولماذا هو مطلوب ؛
- كيف يقوم المشغل بالضبط بتبسيط إدارة الأنظمة المعقدة ؛
- ما يمكن للمشغل وما لا يستطيع المشغل.
بعد ذلك ، دعنا ننتقل إلى مناقشة الهيكل الداخلي للمشغل. ضع في اعتبارك بنية المشغل وتشغيله خطوة بخطوة. دعنا نحلل بالتفصيل:
- التفاعل بين المشغل و Kubernetes ؛
- ما هي الوظائف التي يقوم بها المشغل وما الذي يفوضه إلى Kubernetes.
ضع في اعتبارك إدارة الأجزاء والنسخ المتماثلة لقاعدة البيانات في Kubernetes.
بعد ذلك ، سنناقش مشكلات تخزين البيانات:
- كيفية العمل مع التخزين الثابت من وجهة نظر المشغل ؛
- مخاطر استخدام التخزين المحلي.
في الجزء الأخير من التقرير ، سننظر في أمثلة عملية للتطبيق مع Amazon أو Google Cloud Service. يستند التقرير إلى مثال على تجربة التطوير والتشغيل لمشغل ClickHouse.
فيديو:
اسمي فلاديسلاف كليمينكو. أردت اليوم أن أتحدث عن تجربتنا في تطوير مشغل وتشغيله ، وهو مشغل متخصص لإدارة مجموعات قواعد البيانات. على سبيل المثال لإدارة مجموعة ClickHouse.
لماذا تتاح لنا الفرصة للتحدث عن المشغل و ClickHouse؟
- نحن ندعم ونطور ClickHouse.
- في الوقت الحالي ، نحاول تقديم مساهمتنا ببطء في تطوير ClickHouse. ونحن في المرتبة الثانية بعد Yandex من حيث مقدار التغييرات التي تم إجراؤها في ClickHouse.
- نحن نحاول عمل مشاريع إضافية لنظام ClickHouse البيئي.
أود التحدث عن أحد هذه المشاريع. هذا عن عامل ClickHouse لـ Kubernetes.
في تقريري أود أن أتطرق إلى موضوعين:
- الموضوع الأول هو كيفية عمل مشغل قاعدة بيانات ClickHouse في Kubernetes.
- الموضوع الثاني هو كيف يعمل أي عامل ، أي كيف يتفاعل مع Kubernetes.
ومع ذلك ، سوف يتقاطع هذان السؤالان في جميع أنحاء تقريري.
من سيكون مهتمًا بسماع ما أحاول قوله؟
- الأكثر إثارة للاهتمام سيكون أولئك الذين يستغلون المشغلين.
- أو بالنسبة لأولئك الذين يرغبون في صنعها من أجل فهم كيفية عملها في الداخل ، وكيف يتفاعل المشغل مع Kubernetes ، وما هي المزالق التي قد تظهر.
لفهم ما سنناقشه اليوم بشكل أفضل ، سيكون من الجيد معرفة كيفية عمل Kubernetes ولديك خلفية أساسية في الحوسبة السحابية.
ما هو ClickHouse؟ هذه قاعدة بيانات عمود مع تفاصيل في المعالجة عبر الإنترنت للاستعلامات التحليلية. وهو مفتوح المصدر بالكامل.
ونحن بحاجة لمعرفة شيئين فقط. يجب أن تعرف أن هذه قاعدة بيانات ، لذا فإن ما سأخبرك به سيكون قابلاً للتطبيق على أي قاعدة بيانات تقريبًا. وحقيقة أن مقاييس ClickHouse DBMS بشكل جيد للغاية تعطي قابلية التوسع الخطية تقريبًا. وبالتالي ، فإن حالة الكتلة هي حالة طبيعية لـ ClickHouse. ونحن مهتمون أكثر بمناقشة كيفية خدمة مجموعة ClickHouse في Kubernetes.
لماذا هو مطلوب هناك؟ لماذا لا يمكننا الاستمرار في تشغيله بأنفسنا؟ والإجابات فنية جزئياً وتنظيمية جزئياً.
- من الناحية العملية ، نواجه في كثير من الأحيان موقفًا تكون فيه جميع المكونات تقريبًا موجودة بالفعل في Kubernetes في الشركات الكبيرة. تبقى قواعد البيانات خارج.
- وكثيراً ما يُطرح السؤال: "هل يمكن وضعها في الداخل؟". لذلك ، تحاول الشركات الكبيرة إنتاج أقصى توحيد للإدارة من أجل التمكن بسرعة من إدارة مستودعات البيانات الخاصة بهم.
- وهذا يساعد بشكل خاص إذا كنت بحاجة إلى أقصى فرصة لتكرار نفس الشيء في مكان جديد ، أي إمكانية النقل القصوى.
ما مدى سهولة أو صعوبة ذلك؟ هذا ، بالطبع ، يمكن القيام به يدويًا. لكن هذا ليس بهذه السهولة ، لأننا نضيف تعقيد إدارة Kubernetes نفسها ، ولكن في نفس الوقت يتم فرض تفاصيل ClickHouse. واتضح مثل هذا التجميع.
وإجمالاً ، يوفر هذا مجموعة كبيرة إلى حد ما من التقنيات ، والتي أصبحت بالفعل من الصعب جدًا إدارتها ، لأن Kubernetes تجلب مشكلاتها اليومية إلى التشغيل ، وتقوم ClickHouse بإحضار مشكلاتها إلى التشغيل اليومي. خاصة إذا كان لدينا العديد من ClickHouses ، وعلينا أن نفعل شيئًا معهم باستمرار.
يحتوي ClickHouse ذو التكوين الديناميكي على عدد كبير نسبيًا من المشكلات التي تخلق حملًا ثابتًا على DevOps:
- عندما نريد تغيير شيء ما في ClickHouse ، على سبيل المثال ، إضافة نسخة متماثلة أو جزء ، فإننا نحتاج إلى إدارة التكوين.
- ثم قم بتغيير مخطط البيانات ، لأن ClickHouse لديها طريقة تجزئة محددة. هناك من الضروري وضع مخطط البيانات ، ووضع التكوينات.
- تحتاج إلى إعداد المراقبة.
- مجموعة من السجلات لشظايا جديدة ، للنسخ المتماثلة الجديدة.
- اعتني بالشفاء.
- وإعادة التشغيل.
هذه أعمال روتينية أود أن أيسرها كثيرًا.
تساعد Kubernetes نفسها كثيرًا في التشغيل ، ولكن في أشياء النظام الأساسية.
Kubernetes رائع في تسهيل وأتمتة أشياء مثل:
- الانتعاش.
- إعادة تشغيل.
- ادارة التخزين.
هذا جيد ، هذا هو الاتجاه الصحيح ، لكنه بعيد تمامًا عن كيفية تشغيل مجموعة قواعد البيانات.
أريد المزيد ، أريد أن تعمل قاعدة البيانات بأكملها معنا في Kubernetes.
أرغب في الحصول على شيء مثل الزر الأحمر السحري الكبير الذي تضغط عليه ويكون لديك مجموعة منتشرة وصيانتها طوال دورة الحياة بأكملها مع المهام اليومية التي تحتاج إلى حل. مجموعة ClickHouse في Kubernetes.
وحاولنا إيجاد حل من شأنه تسهيل العمل. هذا هو عامل تشغيل ClickHouse لـ Kubernetes من Altinity.
المشغل هو برنامج تتمثل مهمته الرئيسية في إدارة البرامج الأخرى ، أي أنه مدير.
ويحتوي على أنماط سلوكية. يمكنك تسميتها المعرفة المقننة حول مجال الموضوع.
وتتمثل مهمته الرئيسية في تسهيل الحياة على DevOps وتقليل الإدارة المصغرة بحيث يفكر (DevOps) بالفعل في المصطلحات عالية المستوى ، أي بحيث لا يقوم (DevOps) بالإدارة الدقيقة ، بحيث لا يقوم يدويًا بتكوين جميع تفاصيل.
والمشغل وحده هو مساعد الروبوت الذي يكافح مع المهام الدقيقة ويساعد DevOps.
لماذا المشغل مطلوب؟ يبرع في مجالين:
- عندما لا يتمتع اختصاصي ClickHouse بالخبرة الكافية ، ولكن من الضروري بالفعل تشغيل ClickHouse ، فإن المشغل يسهل العملية ويسمح لك بتشغيل مجموعة ClickHouse بتكوين معقد إلى حد ما ، مع عدم الخوض في الكثير من التفاصيل حول كيفية عمل كل شيء في الداخل . أنت فقط تكلفه بمهام عالية المستوى ، وهي تعمل.
- والمهمة الثانية التي تظهر فيها نفسها بشكل أفضل هي عندما يكون من الضروري أتمتة عدد كبير من المهام النموذجية. يزيل المهام الدقيقة من مسؤولي النظام.
هناك حاجة ماسة إلى هذا سواء من قبل أولئك الذين بدأوا رحلتهم للتو ، أو من قبل أولئك الذين يحتاجون إلى القيام بالكثير من الأتمتة.
ما هو الفرق بين النهج القائم على المشغل والأنظمة الأخرى؟ هناك أيضا هيلم. كما أنه يساعد في تثبيت ClickHouse ، ويمكنك رسم مخططات الدفة ، والتي ستقوم حتى بتثبيت مجموعة ClickHouse بأكملها. إذن ما هو الفرق بين العامل ومن نفسه ، على سبيل المثال ، هيلم؟
يتمثل الاختلاف الأساسي الرئيسي في أن Helm تدور حول إدارة الحزم ، ويذهب المشغل خطوة إلى الأمام. هذا هو دعم دورة الحياة بأكملها. هذا ليس التثبيت فقط ، فهذه مهام يومية تشمل التحجيم والتجزئة ، أي كل ما يجب القيام به خلال دورة الحياة (إذا لزم الأمر ، ثم الإزالة أيضًا) - كل هذا يقرره المشغل. يحاول أتمتة دورة حياة البرنامج بالكامل وخدمتها. هذا هو اختلافها الأساسي عن الحلول الأخرى المقدمة.
كان هذا هو الجزء التمهيدي ، دعنا ننتقل.
كيف نبني مشغلنا؟ نحن نحاول معالجة المشكلة من أجل إدارة مجموعة ClickHouse كمورد واحد.
هنا لدينا بيانات الإدخال على الجانب الأيسر من الصورة. هذا هو YAML بمواصفات الكتلة ، والتي يتم تمريرها بشكل كلاسيكي من خلال kubectl إلى Kubernetes. هناك ، يلتقطها عاملنا ، ويقوم بسحره. ونتيجة لذلك ، حصلنا على مثل هذا المخطط. هذا هو تنفيذ ClickHouse في Kubernetes.
وبعد ذلك سننظر ببطء في كيفية عمل المشغل ، وما هي المهام النموذجية التي يمكن حلها. سننظر فقط في المهام النموذجية ، لأن لدينا وقتًا محدودًا. ولن يتم إخباره بكل شيء يمكن أن يقرره المشغل.
لنبدأ من الممارسة. مشروعنا مفتوح المصدر تمامًا ، لذا يمكنك معرفة كيفية عمله على GitHub. ويمكنك المتابعة من الاعتبارات ، إذا كنت تريد فقط البدء ، فيمكنك البدء بدليل البدء السريع.
إذا كنت تريد أن تفهم بالتفصيل ، فإننا نحاول الحفاظ على الوثائق بشكل لائق إلى حد ما.
لنبدأ بمشكلة عملية. المهمة الأولى التي نريد جميعًا أن نبدأ بها هي تشغيل المثال الأول بطريقة ما. كيف يتم تشغيل ClickHouse بمساعدة عامل تشغيل ، دون معرفة كيف يعمل؟ نحن نكتب بيان ، لأن كل التواصل مع k8s هو التواصل من خلال البيانات.
هنا مثل هذا البيان المعقد. ما أبرزناه باللون الأحمر هو ما نحتاج إلى التركيز عليه. نطلب من المشغل إنشاء مجموعة تسمى demo.
في الوقت الحالي ، هذه أمثلة أساسية. لم يتم وصف التخزين بعد ، لكننا سنعود إلى التخزين بعد قليل. في الوقت الحالي ، سنلاحظ تطور الكتلة في الديناميات.
لقد أنشأنا هذا البيان. نحن نطعمه لمشغلنا. عمل السحر.
ننظر إلى وحدة التحكم. هناك ثلاثة مكونات مهمة - هذه هي Pod ، و Service-a ، و StatefulSet.
لقد نجح المشغل ، ويمكننا أن نرى بالضبط ما صنعه.
هو يخلق شيئا مثل هذا. لدينا StatefulSet ، Pod ، ConfigMap لكل نسخة طبق الأصل ، ConfigMap للمجموعة بأكملها. بالضرورة الخدمات كنقاط دخول إلى الكتلة.
الخدمات هي خدمة موازن التحميل المركزية ويمكن لكل نسخة متماثلة لكل جزء.
هنا تبدو الكتلة الأساسية لدينا شيء من هذا القبيل. إنه من عقدة واحدة.
دعنا نذهب أبعد من ذلك ، سوف نعقد. تحتاج إلى شظايا الكتلة.
مهامنا تنمو ، والديناميات بدأت. نريد أن نضيف شظية. نحن نتابع التطوير. نغير مواصفاتنا. نشير إلى أننا نريد شريحتين.
هذا هو نفس الملف الذي نطوره ديناميكيًا مع نمو النظام. لا يوجد تخزين ، سيتم مناقشة التخزين بشكل أكبر ، هذه قضية منفصلة.
نقوم بإطعام مشغل YAML ونرى ما سيحدث.
فكر المشغل وجعل الكيانات التالية. لدينا بالفعل حاضرتان ، وثلاث خدمات ، وفجأة ، مجموعتان من الحالات. لماذا 2 StatefulSets؟
كان الأمر كذلك على الرسم التخطيطي - هذه هي حالتنا الأولية ، عندما كان لدينا جراب واحد.
أصبح الأمر كذلك. حتى الآن ، كل شيء بسيط ، لقد تم تكراره.
ولماذا أصبحت مجموعة الدولة اثنتين؟ هنا نحتاج إلى الاستطراد ومناقشة مسألة كيفية إدارة Pods في Kubernetes.
يوجد مثل هذا الكائن يسمى StatefulSet ، والذي يسمح لك بإنشاء مجموعة من البودات من قالب. العامل الرئيسي هنا هو القالب. ويمكنك تشغيل العديد من الكبسولات في مجموعة StatefulSet واحدة وفقًا لقالب واحد. والعبارة الرئيسية هنا هي "قالب واحد العديد من القرون".
وكان هناك إغراء كبير لتكوين الكتلة بأكملها ، وتجميعها في مجموعة واحدة ذات حالة. ستعمل ، لا توجد مشكلة في ذلك. لكن هناك تحذير واحد. إذا أردنا تجميع كتلة غير متجانسة ، أي من عدة إصدارات من ClickHouse ، فستبدأ أسئلتنا. نعم ، يمكن لـ StatefulSet إجراء تحديث متجدد ، ولكن هناك يمكنك طرح إصدار جديد ، وشرح أنك لا تحتاج إلى تجربة أكثر من العديد من العقد في نفس الوقت.
ولكن إذا قمنا باستقراء المهمة وقلنا إننا نريد إنشاء مجموعة غير متجانسة تمامًا ولا نريد التغيير من الإصدار القديم إلى الإصدار الجديد باستخدام التحديث المتداول ، ولكننا نريد ببساطة إنشاء مجموعة غير متجانسة من حيث الإصدارات المختلفة ClickHouse ومن حيث التخزين المختلفة. نريد ، على سبيل المثال ، عمل بعض النسخ المتماثلة على أقراص منفصلة ، على أقراص بطيئة ، بشكل عام ، لبناء مجموعة غير متجانسة تمامًا. ونظرًا لحقيقة أن StatefulSet تقدم حلاً موحدًا من قالب واحد ، فلا توجد طريقة للقيام بذلك.
بعد بعض التفكير ، تقرر أننا نفعل هذا. لدينا كل نسخة طبق الأصل في مجموعة الحالة الخاصة بها. هناك بعض العيوب في هذا الحل ، ولكن من الناحية العملية ، كل هذا يلخص المشغل بالكامل. وهناك الكثير من الفوائد. يمكننا بناء مثل هذه الكتلة تمامًا كما نريد ، على سبيل المثال ، مجموعة غير متجانسة تمامًا. لذلك ، في الكتلة التي لدينا فيها شريحتان مع نسخة متماثلة واحدة ، سيكون لدينا مجموعتان من الحالات و 2 Pods على وجه التحديد لأننا اخترنا هذا النهج نظرًا للأسباب المذكورة أعلاه للقدرة على بناء مجموعة غير متجانسة.
دعنا نعود إلى المهام العملية. في مجموعتنا ، نحتاج إلى تكوين المستخدمين ، أي تحتاج إلى إجراء بعض إعدادات ClickHouse في Kubernetes. يوفر المشغل كل الاحتمالات لذلك.
يمكننا كتابة ما نريده مباشرة في YAML. يتم تعيين جميع خيارات التكوين مباشرة من YAML هذا إلى تكوينات ClickHouse ، والتي يتم نشرها بعد ذلك في جميع أنحاء المجموعة.
يمكنك أيضا أن تكتب مثل هذا. هذا على سبيل المثال. يمكن تشفير كلمة المرور. يتم دعم جميع خيارات تكوين ClickHouse على الإطلاق. هنا مجرد مثال.
يتم توزيع تكوين الكتلة كـ ConfigMap. من الناحية العملية ، لا يتم تحديث ConfigMap على الفور ، لذلك إذا كان هناك مجموعة كبيرة ، فإن عملية دفع التكوين تستغرق بعض الوقت. لكن كل هذا مناسب جدًا للاستخدام.
نحن نعقد المهمة. الكتلة تتطور. نريد نسخ البيانات. وهذا يعني أن لدينا بالفعل جزأين ، نسخة متماثلة واحدة لكل منهما ، تم تكوين المستخدمين. نحن ننمو ونريد التكرار.
ماذا نحتاج للتكرار؟
نحن بحاجة إلى ZooKeeper. في ClickHouse ، تم إنشاء النسخ المتماثل باستخدام ZooKeeper. هناك حاجة إلى ZooKeeper حتى تحصل نسخ ClickHouse المتماثلة المختلفة على توافق في الآراء بشأن كتل البيانات التي توجد عليها ClickHouse.
يمكن لأي شخص استخدام ZooKeeper. إذا كان لدى المؤسسة ZooKeeper خارجي ، فيمكن استخدامه. إذا لم يكن كذلك ، فيمكنك التثبيت من مستودعنا. هناك أداة تثبيت تجعل هذا الأمر برمته أسهل.
ويظهر مخطط تفاعل النظام بأكمله على هذا النحو. لدينا Kubernetes كمنصة. يقوم بتنفيذ بيان ClickHouse. ZooKeeper لقد صورت هنا. ويتفاعل العامل مع كل من ClickHouse و ZooKeeper. أي يتم الحصول على تفاعل.
وكل هذا ضروري لـ ClickHouse لتكرار البيانات بنجاح إلى k8s.
دعنا الآن نلقي نظرة على المهمة نفسها ، كيف سيبدو مظهر التكرار.
نضيف قسمين إلى البيان الخاص بنا. الأول هو مكان الحصول على ZooKeeper ، والذي يمكن أن يكون إما داخل Kubernetes أو خارجيًا. هذا مجرد وصف. ونحن نطلب النسخ المقلدة. أولئك. نريد نسختين طبق الأصل. في المجموع ، يجب أن يكون لدينا 4 قرون عند الإخراج. نتذكر عن التخزين ، وسوف يعود قليلا. التخزين هو أغنية منفصلة.
كان الأمر كذلك.
يصبح مثل هذا. يتم إضافة النسخ المتماثلة. الرابع لم يكن مناسبًا ، نعتقد أنه قد يكون هناك الكثير منهم. ويتم إضافة ZooKeeper على الجانب. أصبحت الأنماط أكثر تعقيدًا.
وقد حان الوقت لإضافة المهمة التالية. سنضيف التخزين المستمر.
بالنسبة للتخزين المستمر ، لدينا خيارات تنفيذ مختلفة.
إذا كنا نعمل في مزود خدمة سحابية ، على سبيل المثال ، باستخدام Amazon و Google ، فهناك إغراء كبير لاستخدام التخزين السحابي. إنه مريح للغاية ، إنه جيد.
وهناك خيار آخر. هذا للتخزين المحلي ، عندما يكون لدينا أقراص محلية على كل عقدة. يعد هذا الخيار أكثر صعوبة في التنفيذ ، ولكنه في نفس الوقت أكثر إنتاجية.
دعونا نرى ما لدينا فيما يتعلق بالتخزين السحابي.
هناك مزايا. من السهل جدًا تكوينه. نحن ببساطة نطلب من مزود خدمة السحابة الذي من فضلك يمنحنا تخزينًا بهذه السعة ، كذا وكذا. يتم رسم الفصول من قبل مقدمي الخدمة بشكل مستقل.
وهناك عيب. بالنسبة للبعض ، هذا عيب غير ناقد. بالطبع ، سيكون هناك بعض تراكبات الأداء. إنه مناسب جدًا للاستخدام وموثوق به ، ولكن هناك بعض التراجع المحتمل في الأداء.
ومنذ ذلك الحين يركز ClickHouse على الأداء ، حتى أنه يمكنك القول إنه يضغط على كل ما هو ممكن ، لذلك يحاول العديد من العملاء الضغط على أقصى أداء.
وللحصول على أقصى استفادة منه ، نحتاج إلى تخزين محلي.
يوفر Kubernetes ثلاثة أفكار تجريدية لاستخدام التخزين المحلي في Kubernetes. هذا:
- فارغه
- هوستباث.
- محلّي
ضع في اعتبارك كيف يختلفان ، وكيف يتشابهان.
أولاً ، في جميع الطرق الثلاثة ، لدينا تخزين - هذه هي الأقراص المحلية الموجودة على نفس عقدة k8s المادية. لكن لديهم بعض الاختلافات.
لنبدأ بالأبسط ، أي الفارغ. ما هو في الممارسة؟ نحن من نطلب من نظام الحاويات (غالبًا Docker) من مواصفاتنا تزويدنا بإمكانية الوصول إلى مجلد على قرص محلي.
من الناحية العملية ، يقوم عامل الإرساء بإنشاء مجلد مؤقت في مكان ما في مساراته الخاصة ، ويطلق عليه تجزئة طويلة. ويوفر واجهة للوصول إليه.
كيف ستعمل من حيث الأداء؟ سيعمل هذا بسرعة القرص المحلي ، أي هذا هو الوصول الكامل إلى المسمار الخاص بك.
لكن هذه الحالة لها عيبها. المثابرة في هذه الحالة مشكوك فيها إلى حد ما. عند الحركة الأولى لرسو السفن مع الحاويات ، يتم فقد الثبات. إذا أراد Kubernetes نقل هذا Pod إلى قرص آخر لسبب ما ، فستفقد البيانات.
هذا النهج جيد للاختبارات ، لأنه يظهر بالفعل السرعة العادية ، لكن هذا الخيار غير مناسب لشيء خطير.
لذلك ، هناك نهج ثان. هذا هو hostPath. إذا نظرت إلى الشريحة السابقة وهذه الشريحة ، يمكنك رؤية اختلاف واحد فقط. غادر مجلدنا عامل الإرساء مباشرة إلى عقدة Kubernetes. إنه أسرع قليلاً هنا. نكتب المسار مباشرة على نظام الملفات المحلي حيث نرغب في تخزين بياناتنا.
هذه الطريقة لها مزايا. هذا هو بالفعل ثابت حقيقي وكلاسيكي. على القرص الخاص بنا ، ستتم كتابة البيانات إلى بعض العناوين.
هناك أيضا عيوب. هذا هو تعقيد الإدارة. قد ترغب Kubernetes الخاصة بنا في نقل Pod إلى عقدة مادية أخرى. هذا هو المكان الذي تلعب فيه DevOps. يجب أن تشرح بشكل صحيح للنظام بأكمله أنه يمكنك فقط نقل هذه البودات إلى هذه العقد التي يوجد عليها شيء مثبت على طول هذه المسارات ، وليس أكثر من عقدة واحدة في كل مرة. إنه صعب بما فيه الكفاية.
لهذه الأغراض على وجه الخصوص ، قمنا بإنشاء قوالب في مشغلنا لإخفاء كل هذا التعقيد. ويمكنك فقط أن تقول: "أريد أن يكون لدي مثيل واحد من ClickHouse لكل عقدة فعلية وعلى طول هذا المسار كذا وكذا."
لكن هذه الحاجة ليست لنا فقط ، لذا فإن السادة من Kubernetes نفسها يفهمون أيضًا أن الناس يريدون الوصول إلى الأقراص المادية ، لذا فهم يقدمون مستوى ثالثًا.
يطلق عليه محلي. لا يوجد فرق عمليًا عن الشريحة السابقة. في وقت سابق فقط كان من الضروري أن ننفذ بأيدينا أنه لا يمكننا نقل هذه القرون من عقدة إلى عقدة ، لأنه يجب إرفاقها على طول مسار كذا وكذا إلى القرص المادي المحلي ، والآن يتم تغليف كل هذه المعرفة في Kubernetes نفسها. واتضح أنه أسهل بكثير في التهيئة.
دعنا نعود إلى مهمتنا العملية. دعنا نعود إلى نموذج YAML. هنا لدينا مساحة تخزين حقيقية. لقد عدنا إلى هذا. قمنا بتعيين قالب VolumeClaim الكلاسيكي كما في k8s. ونحن نصف نوع التخزين الذي نريده.
بعد ذلك ، سيطلب k8s التخزين. خصصها لنا في مجموعة الدولة. وفي النهاية ، سيظهر تحت تصرف ClickHouse.
كان لدينا مثل هذا المخطط. كان التخزين الثابت الخاص بنا باللون الأحمر ، والذي بدا وكأنه يشير إلى ضرورة القيام بذلك.
ويتحول إلى اللون الأخضر. الآن تم الانتهاء من مخطط مجموعة ClickHouse on k8s بالكامل. لدينا شظايا ، نسخ متماثلة ، ZooKeeper ، لدينا ثبات حقيقي ، والذي يتم تنفيذه بطريقة أو بأخرى. المخطط يعمل بالفعل بكامل طاقته.
نستمر في العيش. مجموعتنا تنمو. وتحاول Aleksey إطلاق إصدار جديد من ClickHouse.
تنشأ مهمة عملية - لاختبار الإصدار الجديد من ClickHouse على مجموعتنا. وبالطبع ، لا أريد طرح كل ذلك ، أريد أن أضع إصدارًا جديدًا في مكان ما في الزاوية البعيدة في نسخة متماثلة واحدة ، أو ربما ليس إصدارًا واحدًا جديدًا ، ولكن إصدارين في وقت واحد ، لأنه يتم إصدارهما كثيرًا.
ماذا يمكن ان نقول عن هذا؟
هنا لدينا مثل هذه الفرصة. هذه قوالب البودات. يمكنك الطلاء ، يسمح لك عاملنا تمامًا ببناء مجموعة غير متجانسة. أولئك. التكوين ، بدءًا من جميع النسخ المتماثلة في مجموعة ، وتنتهي بكل نسخة متماثلة شخصية ، أي إصدار نريد ClickHouse ، والإصدار الذي نريد تخزينه. يمكننا تكوين الكتلة بالكامل في مثل هذا التكوين الذي نحتاجه.
دعنا نتعمق في الداخل قليلاً. قبل ذلك ، تحدثنا عن كيفية عمل مشغل ClickHouse فيما يتعلق بخصائص ClickHouse.
الآن أود أن أقول بضع كلمات حول كيفية عمل أي عامل بشكل عام ، وكذلك كيفية تفاعله مع K8s.
ضع في اعتبارك التفاعل مع K8s لتبدأ. ماذا يحدث عندما نقوم بتطبيق kubectl؟ من خلال API ، تظهر كائناتنا في etcd.
على سبيل المثال ، كائنات Kubernetes الأساسية: pod و StatefulSet و service وما إلى ذلك من خلال القائمة.
ومع ذلك ، لم يحدث شيء مادي حتى الآن. يجب أن تتحقق هذه الأشياء في كتلة.
هذا هو المكان الذي تأتي فيه وحدة التحكم. وحدة التحكم هي مكون k8s خاص يمكنه تجسيد هذه الأوصاف. يعرف كيف وماذا يفعل جسديا. إنه يعرف كيفية تشغيل الحاويات ، وما يجب تهيئته هناك حتى يعمل الخادم.
ويتجسد أشياءنا في K8s.
لكننا لا نريد العمل فقط مع pods و StatefulSets ، بل نريد إنشاء ClickHouseInstallation ، أي كائن من نوع ClickHouse ، من أجل العمل معه ككل. حتى الآن ، لا يوجد مثل هذا الاحتمال.
لكن K8s لديها شيء جميل آخر. نريد أن يكون لدينا مثل هذا الكيان المعقد في مكان ما ، حيث يتم تجميع مجموعتنا من القرون ومجموعة الدولة.
وماذا يجب أن نفعل لهذا؟ أولاً ، يدخل تعريف المورد المخصص إلى المشهد. ما هذا؟ هذا وصف لـ K8s سيكون لديك نوع بيانات آخر نريد إضافته إلى pod ، StatefulSet ، مورد مخصص سيكون معقدًا من الداخل. هذا وصف لهيكل البيانات.
نرسله هناك أيضًا عبر تطبيق kubectl. أخذها Kubernetes بسعادة.
والآن في التخزين لدينا ، فإن الكائن في etcd لديه الفرصة لكتابة مورد مخصص يسمى ClickHouseInstallation.
لكن في الوقت الحالي ، لن يحدث أي شيء آخر. بمعنى ، إذا أنشأنا الآن ملف YAML الذي نظرنا فيه مع وصف للجزء والنسخ المتماثلة ونقول "kubectl application" ، فسيقول Kubernetes ذلك ، ويضعه في الخ ، ويقول: "رائع ، لكني لا أعرف ماذا نفعل معها. لا أعرف كيفية صيانة ClickHouseInstallation ".
وفقًا لذلك ، نحتاج إلى شخص ما لمساعدة Kubernetes في خدمة نوع البيانات الجديد. على اليسار ، لدينا وحدة تحكم Kubernetes للمخزون تعمل مع أنواع بيانات المخزون. وعلى اليمين ، يجب أن يكون لدينا وحدة تحكم مخصصة يمكنها العمل مع أنواع البيانات المخصصة.
وبطريقة أخرى يطلق عليه المشغل. لقد أخذته هنا على وجه التحديد لـ Kubernetes ، لأنه يمكن أيضًا تنفيذه خارج K8s. في أغلب الأحيان ، بالطبع ، يتم تنفيذ جميع العبارات بلغة Kubernetes ، لكن لا شيء يمنعها من الوقوف في الخارج ، لذلك يتم إبرازها هنا بشكل خاص.
وبالفعل ، بدوره ، فإن وحدة التحكم المخصصة ، المعروفة أيضًا باسم المشغل ، تتفاعل مع Kubernetes من خلال واجهة برمجة التطبيقات. إنه يعرف بالفعل كيفية التفاعل مع API. وهو يعرف بالفعل كيفية تجسيد مخطط معقد نريد صنعه من مورد مخصص. هذا هو بالضبط ما يفعله المشغل.
كيف يعمل المشغل؟ دعنا نلقي نظرة على الجانب الأيمن لنرى كيف يفعل ذلك. سنكتشف كيف يتجسد المشغل كل هذا وكيف يحدث المزيد من التفاعل مع K8s.
المشغل هو البرنامج. هي موجهة نحو الحدث. يشترك المشغل في الأحداث باستخدام Kubernetes API. تحتوي Kubernetes API على نقاط دخول حيث يمكنك الاشتراك في الأحداث. وإذا تغير شيء ما في K8s ، فإن Kubernetes يرسل الأحداث إلى الجميع ، أي الذين اشتركوا في نقطة واجهة برمجة التطبيقات هذه سيتلقون إخطارات.
يشترك المشغل في الأحداث ، ويجب أن يقوم بنوع من رد الفعل. مهمتها هي الاستجابة للأحداث الناشئة.
يتم إنشاء الأحداث من خلال بعض التحديثات. يصل ملف YAML الخاص بنا مع وصف ClickHouseInstallation. ذهب إلى الخ عن طريق تطبيق kubectl. حدث عمل هناك ، ونتيجة لذلك ، جاء هذا الحدث إلى عامل التشغيل ClickHouse. تلقى العامل هذا الوصف. وعليه أن يفعل شيئًا. إذا وصل تحديث إلى كائن ClickHouseInstallation ، فأنت بحاجة إلى تحديث الكتلة. ومهمة المشغل هي تحديث الكتلة.
ماذا يفعل؟ أولاً ، نحتاج إلى وضع خطة عمل لما سنفعله بهذا التحديث. يمكن أن تكون التحديثات صغيرة جدًا ، على سبيل المثال. صغير في تنفيذ YAML ، ولكن يمكن أن يؤدي إلى تغييرات كبيرة جدًا في الكتلة. لذلك ، يقوم المشغل بوضع خطة ، ثم يلتزم بها.
يبدأ ، وفقًا لهذه الخطة ، بغلي هذا الهيكل في الداخل من أجل تجسيد القرون والخدمات ، أي للقيام بما هي مهمتها الرئيسية. يشبه بناء مجموعة ClickHouse في Kubernetes.
الآن دعونا نتطرق إلى شيء مثير للاهتمام. هذا هو تقسيم المسؤولية بين Kubernetes والمشغل ، أي ما يفعله Kubernetes وما يفعله المشغل وكيف يتفاعلون مع بعضهم البعض.
Kubernetes مسؤول عن أشياء النظام ، أي لمجموعة أساسية من الكائنات التي يمكن تفسيرها على أنها نطاق نظام. يعرف Kubernetes كيفية بدء تشغيل pods ، وكيفية إعادة تشغيل الحاويات ، وكيفية إنشاء وحدات تخزين ، وكيفية العمل مع ConfigMap ، أي أي شيء يمكن أن يسمى نظام.
يعمل المشغلون في المناطق الخاضعة. كل مشغل مصنوع حسب مجاله. صنعنا لـ ClickHouse.
ويتفاعل المشغل بدقة من حيث مجال الموضوع ، مثل إضافة نسخة طبق الأصل ، وعمل مخطط ، وإعداد المراقبة. هناك مثل هذا التقسيم.
دعنا نلقي نظرة على مثال عملي لكيفية حدوث فصل الاهتمامات هذا عندما نقوم بإضافة إجراء نسخة طبق الأصل.
تأتي المهمة إلى المشغل - لإضافة نسخة متماثلة. ما الذي يفعله المشغل؟ سيحسب المشغل أنه من الضروري إنشاء مجموعة StatefulSet جديدة ، والتي من الضروري فيها وصف مثل هذه القوالب ، مطالبة الحجم.
قام بإعدادها كلها ونقلها إلى K8s. يقول إنه يحتاج إلى ConfigMap و StatefulSet و Volume. Kubernetes يعمل. يجسد الوحدات الأساسية التي يعمل بها.
ثم يبدأ تشغيل ClickHouse-worker مرة أخرى. لديه بالفعل حجرة مادية يمكنك فعل شيء عليها بالفعل. ويعمل ClickHouse-worker مرة أخرى من حيث مجال الموضوع. أولئك. على وجه التحديد ، ClickHouse ، لتضمين نسخة متماثلة في كتلة ، يجب عليك أولاً تكوين مخطط البيانات الموجود في هذه المجموعة. وثانياً ، يجب تضمين هذه الملاحظة في المراقبة حتى يمكن تتبعها بوضوح. المشغل قام بإعداده بالفعل.
وفقط بعد ذلك ، يتم تشغيل ClickHouse نفسها ، أي كيان آخر أعلى مستوى. إنها بالفعل قاعدة بيانات. له مثيله الخاص ، النسخة المتماثلة المكونة التالية ، والتي تكون جاهزة للانضمام إلى المجموعة.
اتضح أن سلسلة التنفيذ وفصل المسؤولية عند إضافة نسخة متماثلة طويلة بما يكفي.
نواصل مهامنا العملية. إذا كانت المجموعة موجودة بالفعل ، فيمكنك ترحيل التكوين.
لقد صنعناه بحيث يكون من الممكن المرور إلى ملف xml الحالي ، والذي يفهمه ClickHouse.
يمكنك ضبط ClickHouse. مجرد النشر في المناطق هو ما تحدثت عنه عند شرح HostPath ، التخزين المحلي. هذه هي الطريقة التي يتم بها نشر المناطق بشكل صحيح.
المهمة العملية التالية هي المراقبة.
إذا تغيرت مجموعتنا ، فنحن بحاجة إلى تكوين المراقبة بشكل دوري.
دعنا نلقي نظرة على الرسم التخطيطي. لقد نظرنا بالفعل في الأسهم الخضراء هنا. لنلقِ نظرة الآن على الأسهم الحمراء. هذه هي الطريقة التي نريد أن نراقب بها عنقودنا. كيف تصل المقاييس من مجموعة ClickHouse إلى Prometheus ، ثم إلى Grafana.
ما هي مشكلة المراقبة؟ لماذا يتم تقديم هذا على أنه نوع من الإنجاز؟ الصعوبة تكمن في الديناميات. عندما يكون لدينا مجموعة واحدة وهي ثابتة ، فيمكنك إعداد المراقبة مرة واحدة وعدم الإزعاج بعد الآن.
ولكن إذا كان لدينا الكثير من المجموعات ، أو كان هناك شيء ما يتغير باستمرار ، فإن العملية تكون ديناميكية. وإعادة تشكيل المراقبة باستمرار هي مضيعة للموارد والوقت ؛ حتى كسول فقط. هذا يحتاج إلى أتمتة. تكمن الصعوبة في ديناميات العملية. والمشغل يقوم بأتمتة هذا بشكل جيد للغاية.
كيف تطورت مجموعتنا؟ في البداية كان هكذا.
ثم كان هكذا.
في النهاية ، أصبح هكذا.
ويتم المراقبة تلقائيًا بواسطة المشغل. نقطة دخول واحدة.
وننظر فقط إلى المخرج في لوحة القيادة Grafana ، كيف تغلي حياة مجموعتنا بالداخل.
بالمناسبة ، يتم أيضًا توزيع لوحة معلومات Grafana مع المشغل لدينا في الكود المصدري مباشرةً. يمكنك الاتصال والاستخدام. أعطتني لقطة الشاشة هذه من قبل DevOps لدينا.
إلى أين نود أن نذهب بعد ذلك؟ هذا:
- تطوير أتمتة الاختبار. المهمة الرئيسية هي الاختبار الآلي للإصدارات الجديدة.
- نريد أيضًا حقًا أتمتة التكامل مع ZooKeeper. وتخطط للتكامل مع مشغل ZooKeeper. أولئك. تمت كتابة عامل تشغيل لـ ZooKeeper ، ومن المنطقي أن يبدأ المشغلان في الاندماج لبناء حل أكثر ملاءمة.
- نريد إجراء فحوصات أكثر تعقيدًا في الحياة.
- لقد أبرزت باللون الأخضر أن لدينا ميراثًا للقوالب في الطريق - تم ، أي مع الإصدار التالي من المشغل ، سيكون لدينا بالفعل وراثة القالب. هذه أداة قوية تسمح لك ببناء تكوينات معقدة من القطع.
- ونريد أتمتة المهام المعقدة. الشيء الرئيسي هو إعادة التقسيم.
لنقم ببعض النتائج الوسيطة.
ماذا نحصل نتيجة لذلك؟ وهل يستحق ذلك أم لا؟ هل أحتاج حتى إلى محاولة سحب قاعدة البيانات إلى Kubernetes وتطبيق عامل التشغيل بشكل عام ومشغل Alitnity بشكل خاص.
عند الإخراج نحصل على:
- تبسيط وأتمتة التكوين والنشر والصيانة بشكل كبير.
- مراقبة مدمجة على الفور.
- وقوالب مقننة جاهزة للاستخدام للمواقف المعقدة. بالفعل لا يلزم إجراء نوع إضافة نسخة متماثلة يدويًا. يتم ذلك من قبل المشغل.
يبقى السؤال الأخير فقط. لدينا بالفعل قاعدة بيانات في Kubernetes ، الافتراضية. ماذا عن أداء مثل هذا الحل ، خاصة وأن ClickHouse محسّن للأداء؟
الجواب هو كل شيء على ما يرام! لن أصف بالتفصيل ، هذا موضوع تقرير منفصل.
ولكن هناك مشروع مثل TSBS. ما هي مهمتها الرئيسية؟ هذا هو اختبار أداء قاعدة البيانات. هذه محاولة للمقارنة بين الدافئ والدافئ والناعم.
كيف يعمل؟ يتم إنشاء مجموعة واحدة من البيانات. ثم يتم تشغيل مجموعة البيانات هذه على نفس مجموعة الاختبار على قواعد بيانات مختلفة. وكل قاعدة بيانات تحل مشكلة واحدة بالطريقة الممكنة. وبعد ذلك يمكنك مقارنة النتائج.
إنه يدعم بالفعل مجموعة كبيرة من قواعد البيانات. لقد حددت ثلاثة منها رئيسية. هذا:
- مقياس الوقت ب.
- التدفق
- بيت النقر.
تم إجراء مقارنة أيضًا مع حل آخر مماثل. مقارنة مع RedShift. تم إجراء المقارنة على موقع أمازون. ClickHouse هو أيضًا متقدم على الجميع في هذا الأمر.
ما هي الاستنتاجات التي يمكن استخلاصها مما قلته؟
- DB في Kubernetes ممكن. ربما يمكنك فعل أي شيء ، لكن بشكل عام يبدو أنك تستطيع ذلك. من المؤكد أن ClickHouse في Kubernetes ممكن بمساعدة عامل التشغيل لدينا.
- يساعد المشغل على أتمتة العمليات ويبسط الحياة حقًا.
- الأداء طبيعي.
- ويبدو لنا أنه يمكن ويجب استخدامه.
المصدر المفتوح - انضم إلينا!
كما قلت ، المشغل منتج مفتوح المصدر تمامًا ، لذا سيكون جيدًا جدًا إذا استخدمه أكبر عدد ممكن من الأشخاص. نضم الان! نحن في انتظاركم جميعا!
شكرا لك!
الأسئلة
شكرا على التقرير! اسمي انطون. أنا من SEMrush. أنا أتساءل ما الأمر مع قطع الأشجار. نسمع عن المراقبة ، لكن لا شيء عن التسجيل ، إذا تحدثنا عن المجموعة بأكملها. على سبيل المثال ، لدينا مجموعة على الأجهزة. ونستخدم التسجيل المركزي ، ونجمعه في كومة مشتركة بالوسائل القياسية. ومن هناك نحصل على البيانات التي تهمنا.
سؤال جيد ، أي تسجيل الدخول في قائمة المهام. مشغلنا لم يقم بأتمتة هذا حتى الآن. لا يزال المشروع في طور التطوير ، ولا يزال صغيرًا جدًا. نحن نتفهم الحاجة إلى قطع الأشجار. هذا أيضا موضوع مهم جدا. وربما لا تقل أهمية عن المراقبة. لكن أول ما كان على قائمة التنفيذ كان المراقبة. سيكون هناك قطع الأشجار. بطبيعة الحال ، نحاول أتمتة جميع جوانب حياة الكتلة. لذلك ، فإن الجواب هو أنه في الوقت الحالي ، للأسف ، لا يعرف المشغل كيفية القيام بذلك ، لكن هذا في الخطط ، سنفعله. إذا كنت ترغب في الانضمام ، ثم سحب الطلب ، من فضلك.
مرحبًا! شكرا على التقرير! لدي سؤال معياري متعلق بالأحجام الثابتة. عندما نقوم بإنشاء تكوين باستخدام هذا المشغل ، كيف يحدد المشغل على أي عقدة لدينا قرص أو مجلد؟ يجب أن نشرح له أولاً ، من فضلك ، وضع ClickHouse الخاص بنا بالضبط على هذه العقد التي تحتوي على قرص؟
بقدر ما أفهم ، هذا السؤال هو استمرار للتخزين المحلي ، وخاصة الجزء المضيف منه. إنه يشبه الشرح للنظام بأكمله أنه من الضروري إطلاق الكبسولة بالضبط على هذه العقدة ، والتي لدينا قرص متصل فعليًا ، مثبت على مسار كذا وكذا. هذا قسم كامل لمسته بشكل سطحي للغاية ، لأن الإجابة فيه كبيرة جدًا.
باختصار ، يبدو مثل هذا. بالطبع ، نحن بحاجة إلى توفير هذه الكميات. في الوقت الحالي ، لا يوجد توفير ديناميكي في التخزين المحلي ، لذلك يجب على DevOps قطع الأقراص نفسها ، وهنا هذه الكميات. ويجب أن يشرحوا توفير Kubernetes ، أنه سيكون لديك مجلدات ثابتة من فئة كذا وكذا ، والتي تقع في عقد كذا وكذا. بعد ذلك سيكون من الضروري أن نوضح لـ Kubernetes أن البودات التي تتطلب كذا وكذا فئة تخزين محلية تحتاج إلى جدولتها وفقًا للتسميات فقط لعقد كذا وكذا. لهذه الأغراض ، المشغل لديه القدرة على تعيين نوع من الملصقات وواحد لكل مثيل مضيف. واتضح أن البودات سيتم توجيهها بواسطة Kubernetes لتعمل فقط على العقد التي تفي بالمتطلبات ، والملصقات ، بعبارات بسيطة. يقوم المسؤولون بتعيين التسميات وتوفير الأقراص يدويًا. وبعد ذلك تتدرج.
ويساعد الخيار الثالث المحلي فقط في جعله أسهل قليلاً. كما أكدت بالفعل ، هذا عمل شاق للضبط ، والذي يساعد في النهاية على الحصول على أقصى أداء.
لدي سؤال ثان يتعلق بهذا. تم تصميم Kubernetes بطريقة لا تهمنا ما إذا كنا نفقد عقدة أم لا. ماذا نفعل في هذه الحالة إذا فقدنا العقدة التي لدينا فيها شظية؟
نعم ، تم وضع Kubernetes في الأصل على أن علاقتنا مع القرون لدينا تشبه الماشية ، ولكن هنا يصبح كل قرص مثل حيوان أليف. هناك مشكلة لا يمكننا التخلص منها. ويسير تطوير Kubernetes في الاتجاه الذي يستحيل معه التعامل معه فلسفيًا تمامًا ، كمورد مهمل تمامًا.
الآن سؤال عملي. ماذا تفعل إذا فقدت العقدة التي كان القرص عليها؟ هنا يتم حل المشكلة على مستوى أعلى. في حالة ClickHouse ، لدينا نسخ متماثلة تعمل على مستوى أعلى ، أي على مستوى ClickHouse.
ما هو التصرف؟ DevOps هي المسؤولة عن ضمان عدم ضياع البيانات. يجب أن يقوم بإعداد النسخ المتماثل بشكل صحيح ويجب أن يضمن تشغيل النسخ المتماثل. في النسخة المتماثلة على مستوى ClickHouse ، يجب تكرار البيانات. هذه ليست المهمة التي يحلها المشغل. وليست المهمة التي يحلها Kubernetes نفسه. هذا على مستوى ClickHouse.
ماذا تفعل إذا سقطت عقدة الحديد؟ واتضح أنه سيكون من الضروري وضع الثاني ، وتحريك القرص بشكل صحيح عليه ، وتطبيق الملصقات. وبعد ذلك ، سوف يفي بالمتطلبات التي تمكن Kubernetes الموجودة عليه من تشغيل مثيل pod. سوف Kubernetes إطلاقه. عدد القرون الخاص بك لا يكفي للعدد المحدد. سوف يمر خلال الدورة التي عرضتها. وعلى أعلى مستوى ، سوف تفهم ClickHouse أن لدينا نسخة طبق الأصل تم إدخالها ، ولا تزال فارغة ونحتاج إلى البدء في نقل البيانات إليها. أولئك. هذه العملية لا تزال مؤتمتة بشكل سيئ.
شكرا على التقرير! عندما تحدث كل أنواع الأشياء السيئة ، يتعطل المشغل ويعيد التشغيل ، وفي تلك اللحظة تصل الأحداث ، هل تقوم بمعالجة هذا بطريقة ما؟
ماذا يحدث إذا تعطل المشغل وأعاد تشغيله ، نعم؟
نعم. وفي تلك اللحظة جاءت الأحداث.
يتم تقسيم مهمة ما يجب القيام به في هذه الحالة جزئيًا بين المشغل و Kubernetes. Kubernetes لديه القدرة على إعادة تشغيل حدث وقع. يعيد. ومهمة المشغل هي التأكد من أنه عند إعادة تشغيل سجل الأحداث عليه ، فإن هذه الأحداث غير فعالة. وحتى لا يكسر تكرار نفس الحدث نظامنا بالنسبة لنا. والمشغل لدينا يتعامل مع هذه المهمة.
مرحبًا! شكرا على التقرير! ديمتري زافيالوف ، شركة سميدوف. هل من المخطط إضافة خيارات التخصيص مع haproxy إلى المشغل؟ بعض الموازن الآخر مثير للاهتمام إلى جانب الموازن القياسي ، بحيث يكون ذكيًا ويفهم أن ClickHouse حقيقي هناك.
هل تتحدث عن الدخول؟
نعم ، استبدل Ingress بـ haproxy. في haproxy ، يمكنك تحديد طبولوجيا الكتلة حيث يوجد بها نسخ متماثلة.
حتى الآن ، لم نفكر في الأمر. إذا كنت في حاجة إليها ويمكن أن تشرح سبب الحاجة إليها ، فسيكون من الممكن تنفيذها ، خاصة إذا كنت ترغب في المشاركة. سنكون سعداء للنظر في الخيار. الإجابة المختصرة هي لا ، ليس لدينا حاليًا مثل هذه الوظيفة. شكرًا على النصيحة ، سنلقي نظرة على هذا. وإذا قمت بشرح حالة الاستخدام وسبب ضرورتها من الناحية العملية ، على سبيل المثال ، إنشاء مشكلات على GitHub ، فسيكون ذلك رائعًا.
بالفعل.
بخير. نحن منفتحون على أي اقتراحات. ويتم وضع haproxy في قائمة المهام. قائمة المهام تتزايد ولا تتقلص بعد. لكن هذا جيد ، فهذا يعني أن المنتج مطلوب.
المصدر: www.habr.com