Skip to main content
يوضح هذا الدليل كيفية تهيئة مجموعات ClickHouse وKeeper باستخدام المشغّل.

إعداد ClickHouseCluster

الإعداد الأساسي

النسخ المتماثلة والشظايا

  • النسخ المتماثلة: عدد مثيلات ClickHouse لكل شظية (لتحقيق التوفّر العالي)
  • الشظايا: عدد التقسيمات الأفقية (لأغراض التوسّع)
سيُنشئ عنقود يحتوي على replicas: 3 وshards: 2 ما مجموعه 6 كبسولات لـ ClickHouse.

تكامل Keeper

يحتاج كل عنقود ClickHouse إلى مجموعة عُقد Keeper من أجل التنسيق. عيّن حقلًا واحدًا فقط من الحقلين keeperClusterRef وexternalKeeper؛ إذ يُرفض العنقود الذي يعيّن كليهما أو لا يعيّن أيًّا منهما. اجعل keeperClusterRef يشير إلى KeeperCluster يديره هذا المشغِّل:
عند تعيين keeperClusterRef.namespace، يجب على المشغِّل مراقبة مساحتي الاسم كلتيهما. وإذا كان WATCH_NAMESPACE مُعدًّا، فأدرِج مساحتي الاسم الخاصتين بـ ClickHouse وKeeper في تلك القائمة.

Keeper المُدار خارجيًا

استخدم externalKeeper لتشغيل ClickHouse مع مجموعة Keeper لا يديرها المشغّل — سواء كانت تابعة لمشغّل آخر، أو تعمل في عنقود Kubernetes مختلف، أو على أجهزة افتراضية أو خوادم فعلية (bare metal)، أو مشتركة بين عدة أنظمة:
القيمة الافتراضية لـ port هي 9181. أما host فهو اسم DNS أو عنوان IP، مع وضع عناوين IPv6 بين أقواس مربعة. اضبط tls: Enabled للاتصال عبر TLS، واجعل قيمة port هي المنفذ الذي تستمع عليه مجموعة Keeper للاتصالات الآمنة:
يتحقق ClickHouse من شهادات Keeper بالاستناد إلى مخزن الثقة الخاص بالنظام، إضافةً إلى أي caBundle تقوم بتهيئته. راجع الاتصال بين ClickHouse وKeeper عبر TLS. عندما تتشارك عدة عناقيد ClickHouse مجموعة Keeper واحدة، خصّص لكلٍّ منها znode جذرية مستقلة عبر settings.extraConfig، كي لا تتداخل البيانات الوصفية الخاصة بالـ replication والمستخدمون المعرّفون بلغة SQL والمجموعات المسمّاة (named collections) فيما بينها. أنشئ الـ znode قبل بدء تشغيل ClickHouse، ولا تغيّرها بعد ذلك:
لا تضع zookeeper.root في settings.extraReloadableConfig، إذ إن إعادة التحميل ستُبدّل جذر عنقود قيد التشغيل وتترك جداوله المتماثلة في وضع القراءة فقط. وإذا كانت لعقدة znode الجذرية قوائم تحكم في الوصول (ACLs)، فيجب أن تسمح لـ keeper-identity الخاصة بالعنقود بإنشاء عقد znode فرعية. لا يُجري المشغّل أي تغييرات على هذه الخوادم، ولا ينتظر جاهزيتها قبل إجراء التسوية لـ ClickHouse. وتقع مسؤولية الحفاظ على إتاحة مجموعة Keeper على عاتق المستخدم. تعمل المصادقة بالطريقة نفسها المتّبعة مع Keeper الذي يديره المشغّل؛ إذ يقرأ المشغّل المفتاح keeper-identity من Secret الخاص بالعنقود ويمرّره إلى ClickHouse. راجع External Secret للاطلاع على بنية Secret.

إعداد KeeperCluster

تسليم القيادة عند الإنهاء

تتضمن حاوية Keeper خطاف preStop افتراضيًا يطلب من النسخة المتماثلة التخلي عن قيادة Raft قبل توقفها، وينتظر اكتمال التسليم قبل السماح بإنهاء الحاوية. يُنفَّذ هذا الخطاف عند كل إيقاف سلس للحاوية، لا عند عمليات الطرح التي يبدؤها المشغّل فحسب: فإخلاء الحاوية بواسطة descheduler، أو تفريغ العقدة، أو أي إجراء يتخذه مُوسّع تلقائي، كلها تُطلق الخطاف نفسه، لأنه معالج preStop على مستوى kubelet وليس منطقًا ضمن حلقة التسوية (reconcile loop). ومن دون هذا الخطاف، تؤدي إعادة تشغيل القائد الحالي إلى بقاء مجموعة Keeper بلا قائد إلى أن يكتمل انتخاب قائد جديد، وقد يستغرق ذلك عدة ثوانٍ تحت الحمل، فيظهر لـ ClickHouse في صورة فقدان للاتصال بـ Keeper وارتفاع في زمن استجابة الاستعلامات. يطلب الخطاف من النسخة المتماثلة التنازل عن القيادة (عبر أمر Keeper رباعي الأحرف ydld، المُرسَل من خلال منفذ http_control)، ثم يستطلع حالة النسخة المتماثلة إلى أن تكفّ عن كونها القائد، بدلًا من إرسال الطلب والسماح للحاوية بالتوقف فورًا؛ ذلك أن الطلب المُرسَل دون انتظار تأكيد (fire-and-forget) قد يخسر السباق مع SIGTERM تحت حمل الكتابة، ومن ثَمّ فإن الانتظار هو ما يضمن بقاء الفترة الخالية من القائد محدودة. لا يحتاج الخطاف إلى أي تهيئة، ولا يتسبب في أي خلل عند عدم دعمه: ففي إصدارات Keeper الأقدم من 26.3، التي لا تدعم بعدُ أوامر القيادة المستخدمة هنا، لا يكون للطلب أي أثر، وتتوقف الحاوية كما لو لم يكن الخطاف موجودًا. ولأن الخطاف يُشغّل برنامجًا نصيًا لـ shell، فإنه يتطلب وجود bash في الصورة؛ فإذا كنت تستخدم صورة Keeper من نوع distroless أو scratch، فتجاوزه أو أزِله عبر containerTemplate.lifecycle — راجع مرجع واجهة برمجة التطبيقات.

تهيئة التخزين

قم بتهيئة التخزين الدائم باستخدام dataVolumeClaimSpec، وهو PersistentVolumeClaimSpec قياسي في Kubernetes. يحوّله المُشغِّل إلى PersistentVolumeClaim لكل نسخة متماثلة يتم ربطه على مسار البيانات /var/lib/clickhouse:
لا يمكن للمُشغِّل تعديل PVC موجود إلا إذا كانت StorageClass الأساسية تدعم توسيع وحدة التخزين.
يغطي الدليل المخصّص للتخزين ووحدات التخزين إرفاق أقراص إضافية ضمن تهيئة متعددة الأقراص (JBOD)، والتشغيل من دون وحدة تخزين دائمة، وتوسيع السعة، وسياسات التخزين المخصّصة، وتشفير البيانات المخزّنة، والقواعد التي تحدد ما لا يمكن تغييره بعد الإنشاء.

نطاق العنقود

يحدِّد spec.clusterDomain لاحقة DNS في Kubernetes التي يستخدمها المشغِّل عند إنشاء أسماء المضيفين المؤهلة بالكامل للكبسولات التي يكتبها في إعدادات خادم ClickHouse. وتكون القيمة الافتراضية هي cluster.local، وهو موجود في كلٍّ من ClickHouseCluster وKeeperCluster.
بالنسبة إلى النسخ المتماثلة في ClickHouse، ينشئ المشغِّل خدمة عديمة الرأس حاكمة باسم <cluster-name>-clickhouse-headless لتخدم حركة مرور العملاء. كما ينشئ خدمات لكل نسخة متماثلة باسم <cluster-name>-clickhouse-internal-<shard>-<index> تنشر الكبسولات غير الجاهزة لحركة المرور الداخلية وطلبات الإدارة من المشغِّل. يمكن استخدامها لاستعادة النسخة المتماثلة إذا لم تتمكن من أن تصبح جاهزة بنفسها. تستخدم عقد Keeper أسماء الكبسولات عبر خدمتها عديمة الرأس: <pod>.<headless-service>.<namespace>.svc.<clusterDomain>.
لا تُجرِ override لهذا إلا إذا كان kubelet في عنقودك يعمل باستخدام --cluster-domain مختلف عن cluster.local. إذا لم تتطابق القيمة مع نطاق العنقود الفعلي، فلن يتمكن ClickHouse من حل أسماء مضيفات Keeper والنسخ المتماثلة، مما يؤدي إلى فشل التنسيق واستعلامات Distributed مع ظهور أخطاء في حل أسماء DNS. اضبط القيمة نفسها على ClickHouseCluster وKeeperCluster الذي يشير إليه.

إعدادات الكبسولة

التوزيع الطوبولوجي والتقارب التلقائيان

وزّع pod عبر مناطق التوافر:
تأكد من أن عنقود Kubernetes لديك يضم عددًا كافيًا من العقد عبر مناطق مختلفة لاستيفاء قيود التوزيع.
عند استخدام مُوسّع تلقائي للعقد (Karpenter أو Cluster Autoscaler)، لا يمكن لقيد التوزيع وحده تجهيز منطقة لا تحتوي على أي عقد بعد — إذ يكتفي المُجدول بالمناطق المرئية له. اضبط topologyMinDomains على عدد مناطق التوافر لفرض التوزيع:
يتطلب topologyMinDomains وجود topologyZoneKey. تبقى pod في حالة Pending ما دام عدد المناطق المتاحة أقل من المطلوب، لذا أبقِ القيمة ضمن المناطق التي يستطيع عنقودك توفيرها.

الإعداد اليدوي

يمكن تحديد قواعد مخصّصة لتقارب/تنافر الجرابات وقيود توزيع الطوبولوجيا.

راجع مرجع واجهة برمجة التطبيقات للاطلاع على جميع الخيارات المدعومة لقوالب الـ Pod.

ميزانيات تعطيل الكبسولات

ينشئ المشغّل مورد PodDisruptionBudget ‏(PDB) لكل عنقود، بحيث لا تتسبب الاضطرابات الطوعية — مثل تفريغ العقد، وعمليات الترقية المتدرجة، وعمليات الإخلاء التي ينفذها المُوسّع التلقائي — في إسقاط عدد كافٍ من الكبسولات بما يؤدي إلى فقدان quorum أو الإخلال بالتوافر. بالنسبة إلى عناقيد ClickHouse التي تضم أكثر من شظية واحدة، يتم إنشاء PDB واحدة لكل شظية حتى لا يُحتسب الاضطراب في شظية واحدة ضمن شظية أخرى.

القيم الافتراضية

يحدّد المشغّل قيماً افتراضية آمنة بناءً على حجم العنقود، بحيث توفّر عملية apply الجديدة بالفعل حماية من فقدان النصاب بالخطأ. بالنسبة إلى ClickHouseCluster مكوّن من 3 شظايا مع replicas: 3، ينشئ المشغّل ثلاثة PDBs، واحداً لكل شظية، بحيث يكون لكل منها minAvailable: 1.

تجاوز القيم الافتراضية

استخدم spec.podDisruptionBudget لتجاوز minAvailable أو maxUnavailable (واحد منهما فقط):
أو بصيغة maxUnavailable، مع نسبة مئوية:
يُرفَض تعيين كلٍّ من minAvailable وmaxUnavailable بواسطة الويب هوك الخاص بالتحقق. اختر أحدهما — فحتى Kubernetes نفسه لا يسمح باستخدامهما معًا.
يمكنك أيضًا تمرير الحقل unhealthyPodEvictionPolicy إلى PDB الذي يتم إنشاؤه — ويكون ذلك مفيدًا عندما تحتاج إلى السماح بإخلاء الكبسولات التي لا تزال في حالة NotReady:

السياسات

يتيح لك spec.podDisruptionBudget.policy اختيار مدى صرامة إدارة المشغّل لـ PDBs: مثال — عطّل إدارة PDB بالكامل على عنقود تطوير:
مثال — احتفِظ بـ PDB الذي أنشأته يدويًا بجوار العنقود وامنع المشغّل من التعامل معه:

التعطيل على مستوى العنقود بالكامل

يمكن أيضًا تعطيل إدارة PDB على مستوى العنقود بالكامل عبر متغير البيئة ENABLE_PDB الخاص بالمشغّل. عند ضبط ENABLE_PDB=false، يتجاوز المشغّل خطوة التسوية الخاصة بـ PDB لكل ClickHouseCluster وKeeperCluster، بغض النظر عن spec.podDisruptionBudget.policy الخاصة بهما، ولا يراقب موارد PodDisruptionBudget مطلقًا. لذلك، لا يحتاج ServiceAccount الخاص بالمشغّل إلى أذونات RBAC على poddisruptionbudgets.policy/v1، وهو ما يفيد عند تشغيل المشغّل باستخدام ServiceAccount مقيّد يستبعد تلك الأذونات عمدًا.
هذا مخصّص للبيئات التي تعتمد سياسات التعطيل الخاصة بها (مثلًا عبر Gatekeeper / Kyverno) ولا تريد أي تدخّل من المشغّل على الإطلاق.

تكوين الحاوية

صورة حاوية مخصّصة

استخدم صورة حاوية محددة لـ ClickHouse:

موارد الحاويات

اضبط CPU والذاكرة لحاويات ClickHouse:

متغيرات البيئة

أضِف متغيرات بيئة مخصّصة:

ربط وحدات التخزين

أضف عمليات ربط إضافية لوحدات التخزين:
يُسمح بتحديد عدة عمليات ربط لوحدات التخزين إلى mountPath نفسه. سينشئ المشغّل وحدة تخزين من نوع projected تضم جميع عمليات الربط المحددة.

مجسّات الصحة

يهيّئ المشغّل مجسّات الحيوية (liveness) والجاهزية (readiness) على كل حاوية من حاويات ClickHouse وKeeper. لا يُضبط أي مجسّ بدء تشغيل (startup) افتراضيًا. يستخدم ClickHouse وKeeper إعدادات التوقيت الافتراضية نفسها: يفتح ClickHouse مستمع الاتصال بين الخوادم قبل تحميل الجداول، ثم يفتح مستمعات العملاء بعد ذلك؛ ولهذا يتحمّل مجسّ الحيوية بطء تحميل الجداول، في حين يدلّ نجاح مجسّ الجاهزية على أن النسخة المتماثلة أصبحت جاهزة لخدمة الاستعلامات. يمكنك تجاوز إعدادات أي مجسّ عبر spec.containerTemplate في أيٍّ من الموردين. على سبيل المثال، لتخصيص مجسّ الحيوية في ClickHouse:
أي مجسّ تضبطه يحلّ محلّ الإعداد الافتراضي للمشغّل بالكامل، ولا يُدمج معه حقلاً بحقل. حدّد المعالج (httpGet أو tcpSocket أو exec) وكل حقل توقيت يهمّك؛ فالحقول المُغفلة تأخذ القيم الافتراضية لـ Kubernetes (مثل timeoutSeconds: 1 وfailureThreshold: 3)، لا قيم المشغّل المذكورة أعلاه.

مجسّ بدء التشغيل

استخدم startupProbe عندما تحتاج الحاوية إلى وقت للبدء أطول مما يسمح به مجسّ الحيوية، وهو بالإعدادات الافتراضية نحو 60 ثانية من التأخير الأولي، تليها 10 فحوصات فاشلة يفصل بين كل منها 5 ثوانٍ. يؤجّل Kubernetes تشغيل مجسّي الحيوية والجاهزية إلى أن ينجح مجسّ بدء التشغيل، فلا يؤدي البدء البطيء إلى الدخول في حلقة متكررة من إعادة التشغيل. على سبيل المثال، امنح نسخة متماثلة من Keeper تعيد تطبيق لقطة كبيرة مهلةً تصل إلى 10 دقائق لتبدأ في قبول الاتصالات:
بعد نجاح مجسّ بدء التشغيل (مجسّ startup)، تتولى مجسّات الحيوية (الحيوية) والجاهزية (الجاهزية) المعتادة المهمة من بعده.

راجع مرجع واجهة برمجة التطبيقات للاطلاع على جميع خيارات قوالب الحاويات المدعومة.

إعدادات TLS/SSL

تهيئة نقاط نهاية آمنة

مرّر مرجعًا إلى Kubernetes Secret يحتوي على شهادات TLS لتمكين نقاط النهاية الآمنة

تنسيق Secret الخاص بشهادة SSL

من المتوقع أن يحتوي Secret على زوج الشهادة والمفتاح الخاص بالخادم:
  • tls.crt - شهادة الخادم بترميز PEM
  • tls.key - المفتاح الخاص بترميز PEM
يتوافق هذا التنسيق مع الشهادات التي يُنشئها cert-manager.

اتصال ClickHouse-Keeper عبر TLS

إذا كان TLS مفعّلًا في KeeperCluster المُشار إليه عبر keeperClusterRef، فسيستخدم ClickHouseCluster اتصالًا آمنًا بعُقد Keeper تلقائيًا. أما عند استخدام externalKeeper، فاضبط tls: Enabled بدلًا من ذلك، واضبط port لكل عقدة على منفذ العميل الآمن لمجموعة Keeper (على سبيل المثال 9281). يتحقق ClickHouseCluster من شهادات عُقد Keeper باستخدام مخزن الثقة في النظام، بالإضافة إلى أي caBundle تقوم بتهيئته. للثقة في CA خاصة (على سبيل المثال، CA موقعة ذاتيًا أو داخلية)، قدّم مرجعًا إلى حزمة CA مخصصة:

External Secret

ينشئ المشغّل افتراضيًا مورد Secret ويتولى إدارته، ويحتوي هذا المورد على بيانات الاعتماد الداخلية للعنقود (كلمة مرور الاتصال بين الخوادم، وكلمة مرور الإدارة، وهوية Keeper، وسرّ العنقود، ومفتاح named-collections). ويحمل هذا الـ Secret اسم العنقود ويقع ضمن مساحة اسم العنقود. إذا كنت تريد إدارة بيانات الاعتماد هذه بنفسك — على سبيل المثال، بتوفيرها من HashiCorp Vault أو AWS Secrets Manager أو External Secrets Operator — فاجعل المشغّل يشير إلى Secret موجود مسبقًا باستخدام spec.externalSecret:
يجب أن يكون كائن Secret المشار إليه موجودًا في مساحة الاسم نفسها الخاصة بـ ClickHouseCluster. ولا يحذف المُشغِّل مطلقًا أي كائن Secret لم يُنشئه.

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

يجب أن يحتوي Secret على المفاتيح التالية: يكون Secret الكامل كما يلي:

السياسة: المراقبة مقابل الإدارة

يتحكم spec.externalSecret.policy في كيفية تعامل المشغّل مع المفاتيح المطلوبة الناقصة:
حتى مع policy: Manage يجب أن يكون كائن Secret موجودًا بالفعل في مساحة الاسم — فالمشغّل لا ينشئ كائن Secret نفسه مطلقًا، بل يكتب فقط المفاتيح المُولَّدة إلى كائن موجود. وإذا كان كائن Secret المُشار إليه غير موجود، فتُعلَّق التسوية بسبب ExternalSecretNotFound بغض النظر عن السياسة.
اختر Observe عندما يكون النظام الخارجي (Vault أو ESO أو sealed-secrets أو GitOps) هو مصدر الحقيقة وتريد أن يُخفق المشغّل بوضوح عند وجود خطأ في الإعداد. واختر Manage عندما تريد تهيئة أولية مكتفية ذاتيًا، مع الاحتفاظ بملكية كائن Secret نفسه (على سبيل المثال، لأخذ نسخة احتياطية منه).

شرط الحالة واستكشاف الأخطاء وإصلاحها

يعرض المشغِّل شرط ExternalSecretValid ضمن ClickHouseCluster.status.conditions. افحصه عندما يبدو أن عملية التسوية عالقة:
الأسباب المحتملة: يعيد المشغّل إدراج عملية التسوية في قائمة الانتظار ما دام كائن Secret غير صالح، لذا بمجرد إضافة المفاتيح المفقودة ستلتقطها عملية التسوية التالية تلقائيًا — ولا حاجة إلى إعادة تشغيل الـ pods.
تعتمد مجموعة المفاتيح المطلوبة على إصدار ClickHouse المستخدم حاليًا. لا يتم التحقق من named-collections-key إلا بعد أن يكتشف فحص الإصدار الخاص بالمشغّل ClickHouse 25.12 أو أحدث. في الإصدارات الأقدم، قد لا يكون هذا المفتاح موجودًا في كائن Secret. ويكون disk-encryption-key مطلوبًا فقط عند تعيين spec.settings.encryption.

منافذ إضافية

يكشف المشغّل مجموعة ثابتة من المنافذ على كل Pod لـ ClickHouse وعلى الخدمة عديمة الرأس العامة الخاصة به: 8123 لـ HTTP، و9000 لـ أصلي، و9009 للاتصال بين الخوادم، و9001/9002 للإدارة، و9363 لمقاييس Prometheus، بالإضافة إلى منافذ TLS البديلة 8443/9440 عند تمكين TLS. كما تُكشف منافذ interserver والإدارة عبر الخدمات الداخلية لكل نسخة متماثلة، بحيث تتمكن النسخ المتماثلة والمشغّل من التواصل قبل أن تصبح النسخة المتماثلة جاهزة. لجعل ClickHouse يستمع إلى بروتوكولات إضافية — مثل MySQL أو PostgreSQL أو gRPC أو أي منفذ مخصّص — عرِّفها في spec.additionalPorts:
يضيف المشغّل هذه المنافذ إلى containerPorts الخاصة بالـ Pod وإلى الخدمة عديمة الرأس العامة. ويمكن العثور على المثال الكامل في examples/custom_protocols.yaml.
يفتح additionalPorts المنافذ على مستوى Kubernetes فقط. لكنه لا يهيّئ خادم ClickHouse للاستماع عليها. ويجب أيضًا تمكين البروتوكول المقابل في spec.settings.extraConfig.protocols. وبدون ذلك، سيكون المنفذ مفتوحًا على الـ Service، لكن لن يستجيب أي شيء داخل الـ Pod.

مثال متكامل: MySQL wire protocol

لإتاحة ClickHouse عبر MySQL wire protocol على المنفذ 9004:
بعد تطبيق ذلك، تحقّق من داخل الكتلة:

قيود الحقول

المنافذ والأسماء المحجوزة

يرفض الـ webhook الخاص بالتحقق إدخالات additionalPorts التي قد تتعارض مع المنافذ التي يستخدمها المشغّل نفسه. جميع المنافذ المرتبطة بـ TLS محجوزة دون قيد أو شرط حتى لا يؤدي تبديل spec.settings.tls.enabled لاحقًا إلى تعطيل عنقود كان صالحًا سابقًا. تُرفض أيضًا الأسماء التالية — فهي معرّفات المشغّل الداخلية لأنواع البروتوكولات (وليست الأسماء المستعارة المفهومة للبشر): ينتج عن الطلب المرفوض خطأ مثل:

فحص الإصدار وقناة الترقية

ينفّذ المشغّل مهمتين مستقلتين تتعلقان بإصدارات العنقود:
  1. الإبلاغ عن الإصدار — بالنسبة إلى ClickHouseCluster، يشغّل مورد Kubernetes Job صورة الحاوية مرة واحدة لاكتشاف إصدار ClickHouse قيد التشغيل؛ وبالنسبة إلى KeeperCluster، يقرأ المشغّل الإصدار الذي يبلّغ به الخادم من النسخ المتماثلة قيد التشغيل. ويُسجَّل الإصدار المكتشف في .status.version وتستخدمه خطوات التسوية الأخرى (على سبيل المثال، لا يكون مفتاح named-collections الخاص بـ External Secret مطلوبًا إلا بدءًا من ClickHouse 25.12).
  2. قناة الترقية — تحقّق دوري من موجز إصدارات ClickHouse العام (https://clickhouse.com/data/version_date.tsv). ويبلّغ المشغغّل عمّا إذا كان إصدار أحدث متاحًا عبر شرط الحالة VersionUpgraded. وهو لا يرقّي العنقود من تلقاء نفسه مطلقًا — فالمستخدم هو من يتحكّم في وسم الصورة.

اختيار قناة الترقية

يحدِّد spec.upgradeChannel مجموعة الإصدارات الصادرة من المشروع الأصلي التي يقارن بها المشغّل. ويوجد الحقل نفسه في كلٍّ من ClickHouseCluster وKeeperCluster.
القيم المسموح بها (التي يتحقق منها CRD باستخدام النمط ^(lts|stable|\d+\.\d+)?$): في بيئات الإنتاج، يُفضَّل عمومًا تثبيت القناة على قيمة <major>.<minor> صريحة (مثل 25.8). فهذا يقيّد العنقود بخط الإصدار الرئيسي المقصود، ويتيح للمُشغِّل إظهار تحذير WrongReleaseChannel إذا انجرفت أي نسخة متماثلة، لسبب ما، إلى إصدار رئيسي مختلف — وهو أمر يكتسب أهمية خاصة عندما يُشار إلى الصورة بواسطة digest (@sha256:...) بدلًا من tag مقروء بشريًا. أما القيمة الافتراضية الفارغة فهي مناسبة لعناقيد التطوير حيث لا تكون القفزات بين الإصدارات الرئيسية مصدر قلق.

شروط الحالة

يكشف الشرطان التاليان نتيجة الـ فحص وفحص الترقية: افحصها باستخدام:

تجاوز Job فحص الإصدار

ينطبق هذا على ClickHouseCluster فقط. لم يعد KeeperCluster يشغّل Job لفحص الإصدار — إذ تُقرأ نسخته مباشرةً من نسخ Keeper المتماثلة العاملة — لذلك فإن spec.versionProbeTemplate مهمل ولا يكون له أي تأثير هناك. يُنَفَّذ الفحص باعتباره Job عاديًا في Kubernetes. إذا كانت في عنقودك سياسات قبول تتطلب قيم Tolerations محددة، أو محددات عُقد، أو سياقات أمان، أو إذا كنت تريد تقييد مدة بقاء مهام الفحص المكتملة، فتجاوز القالب عبر spec.versionProbeTemplate:
اسم الحاوية version-probe هو الاسم الافتراضي للمشغّل — إذ إن الإدخال ضمن containers: يطابقه بالاسم، لذا يُجري المشغّل دمجًا عميقًا للحقول التي يوفّرها المستخدم فوق القيم الافتراضية.

عناصر تحكم على مستوى المشغّل

يتحكم خياران في مدير المشغّل بحلقة التحقق من الترقية على مستوى عام: اضبط --disable-version-update-checks=true في البيئات المعزولة عن الشبكة أو عندما لا يكون مسموحًا بخروج الحركة إلى clickhouse.com.

إعدادات ClickHouse

كلمة مرور المستخدم default

يضبط spec.settings.defaultUserPassword كلمة مرور المستخدم المضمّن default. وفّر القيمة من مفتاح في Secret (مستحسن) أو في ConfigMap تنشئه، بدلًا من تضمينها مباشرةً داخل CR:
حدِّد واحدًا فقط من secret أو configMap، على أن يشتمل أيٌّ منهما على كلٍّ من name (الكائن) وkey (الإدخال الذي يحتوي على كلمة المرور).

أنواع كلمات المرور

يُحدِّد passwordType كيفية تفسير ClickHouse للقيمة. وتكون قيمته الافتراضية password (نص صريح)؛ أما البدائل فهي صيغ مُجزَّأة مثل password_sha256_hex و password_double_sha1_hex. ويُفضَّل استخدام نوع مُجزَّأ حتى لا يُخزَّن النص الصريح مطلقًا. راجع إعدادات مستخدمي ClickHouse للاطلاع على القائمة الكاملة.

مثال كامل باستخدام Secret

أنشئ Secret، ثم أشِر إلى مفتاحه:
عند استخدام passwordType: password، يُضبط clickhouse-client داخل الكبسولة باستخدام كلمة المرور هذه، مما يكون مفيدًا عند تصحيح الأخطاء.
بالنسبة إلى كلمة مرور مُجزّأة، خزّن قيمة التجزئة بدلًا من النص غير المشفّر:

استخدام ConfigMap

يعمل ConfigMap بالطريقة نفسها، لكن محتوياته ليست محمية كما في Secret. استخدمه فقط للقيم غير الحساسة أو للقيم التي جرى تجزئتها بالفعل، مثل بصمة password_sha256_hex:
لا تضع كلمة مرور غير مشفّرة في ConfigMap. استخدم Secret لأي قيمة غير مشفّرة (passwordType: password).

مستخدمون مخصّصون في التهيئة

قم بتهيئة مستخدمين إضافيين في ملفات التهيئة. أنشئ ConfigMap وSecret للمستخدم:
أضِف تهيئة مخصّصة إلى ClickHouseCluster:

مزامنة قاعدة البيانات

فعِّل المزامنة التلقائية لقاعدة البيانات للنسخ المتماثلة الجديدة:
عند التفعيل، يزامن المُشغِّل جداول Replicated وجداول التكامل مع النسخ المتماثلة الجديدة. تحمل كل Pod للنسخة المتماثلة بوابة الجاهزية clickhouse.com/ReplicaInitialized، لذلك لا تُنشر النسخة المتماثلة الجديدة عبر الخدمة عديمة الرأس العامة إلا بعد أن يُكمل المُشغِّل تهيئتها: إذ تُحوَّل قاعدة البيانات default إلى محرك Replicated ويُزامَن المخطط. وحتى ذلك الحين، يصل إليها المُشغِّل والنسخ المتماثلة الأخرى عبر خدمتها الداخلية. عند استخدام enableDatabaseSync: false، يضع المُشغِّل علامة التهيئة على النسخ المتماثلة فورًا، لذا تعتمد الجاهزية على فحوصات الحاوية وحدها. لا يحذف المُشغِّل مطلقًا قاعدة بيانات default غير Replicated والمملوءة بالبيانات. تبدأ هذه النسخة المتماثلة مع ذلك في خدمة حركة مرور العملاء بعد إعداد المخطط، لكن العنقود يبلّغ عن SchemaInSync=False بالسبب DefaultDatabaseNotReplicated إلى أن تعالج قاعدة البيانات تلك بنفسك. قبل إزالة نسخة متماثلة عند التخفيض التدريجي، يُفرِّغ المُشغِّل أولًا حركة مرور العملاء منها، وينتظر حتى تتوقف عن النشر، ويُكرِّر بياناتها المتبقية إلى النسخ المتماثلة الباقية، ثم يحذفها فقط بعد ذلك.

تسجيل الخادم

اضبط سجل خادم ClickHouse عبر spec.settings.logger. كل حقل اختياري وله قيمة افتراضية آمنة، لذا فإن أي عنقود لا تُجري عليه أي تعديل يسجّل بالفعل عند مستوى information في كلٍّ من وحدة تحكم الحاوية وملف سجل خاضع للتدوير على القرص.
يُبقي المشغّل التسجيل إلى وحدة التحكم مفعّلًا دائمًا لكي يعمل kubectl logs، ويضيف التسجيل إلى الملف فوق ذلك عندما تكون logToFile بقيمة true. وينتج عن عنقود بالإعدادات الافتراضية كتلة logger التالية:
ينطبق مقطع spec.settings.logger نفسه على KeeperCluster؛ لكن المشغّل يكتب ملفاته في هذه الحالة ضمن /var/log/clickhouse-keeper/، ويضبط مستوى مسجّل Raft ‏(raft_logs_level) على قيمة level نفسها.
يظل التسجيل إلى الطرفية مفعّلًا بغضّ النظر عن logToFile، لذا يواصل kubectl logs العمل حتى عند تعطيل التسجيل إلى ملف. اضبط jsonLogs: true عند إرسال السجلات إلى مخزن سجلات منظَّم يحلّل JSON.

جداول سجلات النظام

يُفعّل المشغّل جداول النظام query_log وpart_log وtext_log وmetric_log وasynchronous_metric_log. وبما أنها تشترك مع بياناتك في وحدة التخزين نفسها، يفرض عليها spec.settings.systemLogsTTLDays مدة احتفاظ باستخدام TTL على مستوى الجدول. يضبط خطاف الويب المخصّص لتعيين القيم الافتراضية هذا الإعداد على 30 إذا أنشأت عنقودًا دون تحديد الحقل. اضبطه على 0 لتعطيل TTL صراحةً.
ينطبق الإعداد الافتراضي على العناقيد الجديدة فقط. أما العنقود الذي أُنشئ قبل استحداث systemLogsTTLDays، فتبقى جداول سجلات النظام فيه بلا حدّ زمني للاحتفاظ بها حتى تضبط الحقل بنفسك.
يبدأ سريان TTL عند إعادة تشغيل الخادم في المرة التالية. يمكنك تغيير قيمته لكل جدول على حدة، أو ضبط أي إعداد آخر لسجلات النظام، أو تعطيل أحد الجداول تمامًا باستخدام السمة @remove — وكل ذلك من خلال extraConfig:
لا يعني تعطيل الجدول حذفه: تبقى البيانات الموجودة على القرص حتى تحذف الجدول بنفسك.
يعيد ClickHouse إنشاء جدول النظام إذا تغيّرت قيمة TTL الخاصة به، ويحتفظ بالبيانات القديمة في جدول أُعيدت تسميته، مثل system.text_log_0. احذف هذه الجداول عندما لا تعود بحاجة إلى سجلّها.

إعداد مخصص

تهيئة إضافية مضمنة

بدلًا من ربط ملفات تهيئة مخصّصة، يمكنك تحديد خيارات تهيئة إضافية لـ ClickHouse مباشرةً. أضف تهيئة مخصّصة لـ ClickHouse باستخدام extraConfig:

تهيئة إضافية قابلة لإعادة التحميل

يؤدي أي تغيير في extraConfig إلى إعادة تشغيل وحدات pod الخاصة بـ ClickHouse، لأن المشغّل لا يستطيع تحديد الإعدادات التي تُطبَّق وقت التشغيل. وللإعدادات التي يستطيع ClickHouse إعادة تحميلها دون إيقاف التشغيل — وأشيعها named_collections — استخدم extraReloadableConfig بدلًا من ذلك. يطبّق المشغّل التغييرات بإعادة تحميل التهيئة، دون إعادة تشغيل وحدات pod:
ضع كل قسم من المستوى الأعلى في أحد الحقلين extraConfig أو extraReloadableConfig فقط؛ ويُصدر المشغّل تحذيرًا إذا تضمّن الحقلان القسم نفسه.
عند استخدام extraReloadableConfig، فإنك تؤكد أن إعداداته قابلة لإعادة التحميل بأمان. أما الإعداد الذي يتطلب إعادة التشغيل، فلن يسري مفعوله إذا وُضع هنا إلا عند إعادة التشغيل التالية، دون ظهور أي خطأ.

إعدادات المستخدمين الإضافيين المضمّنة

يمكنك أيضًا تحديد إعدادات إضافية لمستخدمي ClickHouse باستخدام extraUsersConfig. ويُفيد ذلك في تعريف المستخدمين وملفات التعريف والحصص والامتيازات مباشرةً ضمن مواصفات العنقود.
يتم تخزين extraUsersConfig في كائن ConfigMap ضمن k8s. تجنّب وضع الأسرار هناك بصيغة نصية مكشوفة.

راجع الوثائق للاطلاع على جميع خيارات إعداد مستخدمي ClickHouse المدعومة.

مثال على التهيئة

مثال كامل للتهيئة:

المزامنة الدورية

إلى جانب الاستجابة لأحداث Kubernetes، يعيد الـ مشغّل مطابقة (reconcile) كل عنقود على فترات زمنية ثابتة. ويبقي ذلك شروط الحالة محدَّثة بالنسبة للحالات التي لا يمكن لأي watch رصدها — مثل صحة الـ نسخة متماثلة في ClickHouse، و quorum الخاص بـ Keeper — كما يعيد محاولة إجراءات المعالجة مثل تنظيف الـ pod العالق. ويُتحكَّم في هذه الفترة عبر متغير البيئة RESYNC_PERIOD الخاص بالـ مشغّل (القيمة الافتراضية 30s). وهو ينطبق على موارد KeeperCluster، حيث تُعطِّل القيمة 0 المزامنة الدورية. أما موارد ClickHouseCluster فتستطلع system.warnings في ClickHouse كل 30 ثانية، وهو ما يعيد تشغيل عملية التسوية أصلاً، لذا لا تأثير لـ RESYNC_PERIOD عليها حالياً.
يطابق الـ مشغّل العناقيد بالتزامن؛ ويُحدَّد عدد عمليات المطابقة المتوازية لكل وحدة تحكم بواسطة MAX_CONCURRENT_RECONCILES (القيمة الافتراضية 4).

إيقاف التسوية مؤقتًا

أضف التعليق التوضيحي clickhouse.com/pause-reconciliation: "true" إلى ClickHouseCluster أو KeeperCluster لإيقاف تسويته بواسطة المشغّل. عندئذٍ، يُبلّغ المشغّل عن ReconcileSucceeded=False مع السبب ReconciliationPaused للمورد، ويتركه دون تغيير — وهو ما يفيد عند الحاجة إلى التدخل اليدوي إذا كان المشغّل سيُلغي تغييراتك. خلال فترة الإيقاف، يُبلّغ المشغّل عن جميع شروط الحالة (بما فيها Ready وHealthy) بالقيمة Unknown مع السبب ReconciliationPaused، لأنه لا يراقب العنقود. أزل التعليق التوضيحي لاستئناف التسوية؛ وستُطبَّق التغييرات المعلّقة في المواصفة عند إجراء التسوية التالية.