الانتقال إلى المحتوى الرئيسي
يوضح هذا الدليل كيفية تهيئة مجموعات ClickHouse وKeeper باستخدام المشغّل.

إعداد ClickHouseCluster

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

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

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

تكامل Keeper

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

إعداد KeeperCluster

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

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

نطاق العنقود

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

تخزين متعدد الأقراص (JBOD)

يقوم additionalVolumeClaimTemplates بإرفاق أقراص إضافية بكل نسخة متماثلة في ClickHouse، بالإضافة إلى dataVolumeClaimSpec الأساسي المطلوب لاستخدامها. يمثل كل عنصر قالب PVC — أي metadata.name مع spec الخاص بـ PVC. تُعالَج الأقراص بالطريقة نفسها تمامًا مثل قرص البيانات الأساسي — على هيئة volumeClaimTemplates في StatefulSet — لذلك تنشئ وحدة تحكم StatefulSet ملف PVC واحدًا لكل نسخة متماثلة وتحتفظ به، بالاسم <name>-<statefulset>-0.
يربط المشغّل كل وحدة تخزين إضافية عند /var/lib/clickhouse/disks/<name> ويضيفها إلى إعداد تخزين يُنشئه ClickHouse. تتحول الشرطات في الاسم إلى شرطات سفلية في معرّف القرص في ClickHouse، بينما يحتفظ مسار الربط بالاسم الأصلي. يوضع قرص البيانات الأساسي وكل قرص إضافي في وحدة تخزين واحدة ضمن سياسة التخزين default، بحيث يوزّع ClickHouse أجزاء البيانات الجديدة عليها جميعًا بالتناوب. وتكون السعة القابلة للاستخدام هي مجموع جميع الأقراص، كما أن كل جدول لا يعيّن storage_policy خاصًا به (بما في ذلك جداول system.*) يستخدم هذه المجموعة الموحّدة.
يجب أن تتطابق أسماء PVC مع ^[a-z]([-a-z0-9]*[a-z0-9])?$، وألا تتعارض مع اسم وحدة تخزين البيانات الأساسية. وكما هو الحال مع قرص البيانات الأساسي، فإن مجموعة الأقراص الإضافية تكون ثابتة عند الإنشاء: تُرفَض إضافة إدخالات أو إزالتها أو إعادة تسميتها بعد الإنشاء. يتم الاحتفاظ بـ PVCs الإضافية عند حذف العنقود، تمامًا مثل قرص البيانات الأساسي. يمكن توسيع حجم التخزين في إدخال موجود إذا كانت StorageClass تدعم التوسعة.

نطاق DNS للعنقود

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

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

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

وزّع الكبسولات عبر مناطق التوافر:
تأكد من أن عنقود Kubernetes لديك يضم عددًا كافيًا من العقد عبر مناطق مختلفة لاستيفاء قيود التوزيع.

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

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

راجع مرجع واجهة برمجة التطبيقات للاطلاع على جميع الخيارات المدعومة لقوالب الـ 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 تضم جميع عمليات الربط المحددة.

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

إعدادات TLS/SSL

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

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

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

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

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

إذا كان TLS مفعّلًا في KeeperCluster، فسيستخدم ClickHouseCluster اتصالًا آمنًا بعُقد Keeper تلقائيًا. يتحقق 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.

منافذ إضافية

يكشف المشغّل مجموعة ثابتة من المنافذ على كل Pod لـ ClickHouse وعلى الخدمة عديمة الرأس الخاصة به: 8123 لـ HTTP، و9000 لـ native، و9009 للاتصال بين الخوادم، و9001 للإدارة، و9363 لمقاييس Prometheus، بالإضافة إلى منافذ TLS البديلة 8443/9440 عند تمكين TLS. لجعل 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 وجداول التكامل مع النسخ المتماثلة الجديدة.

تسجيل الخادم

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

إعداد مخصص

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

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

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

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

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

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

مثال كامل للتهيئة:
آخر تعديل في ٢ يوليو ٢٠٢٦