إعداد ClickHouseCluster
الإعداد الأساسي
النسخ المتماثلة والشظايا
- النسخ المتماثلة: عدد مثيلات ClickHouse لكل شظية (لتحقيق التوفّر العالي)
- الشظايا: عدد التقسيمات الأفقية (لأغراض التوسّع)
replicas: 3 وshards: 2 ما مجموعه 6 كبسولات لـ ClickHouse.
تكامل Keeper
keeperClusterRef.namespace، يجب على المشغِّل مراقبة مساحتي الاسم كلتيهما. وإذا كان WATCH_NAMESPACE مُعدًّا، فأدرِج مساحتي الاسم الخاصتين بـ ClickHouse وKeeper في تلك القائمة.
إعداد KeeperCluster
تهيئة التخزين
dataVolumeClaimSpec، وهو
PersistentVolumeClaimSpec قياسي في Kubernetes. يحوّله المُشغِّل إلى PersistentVolumeClaim لكل نسخة متماثلة
يتم ربطه على مسار البيانات /var/lib/clickhouse:
لا يمكن للمُشغِّل تعديل PVC موجود إلا إذا كانت StorageClass الأساسية تدعم توسيع وحدة التخزين.
نطاق العنقود
يحدِّد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.
ميزانيات تعطيل الكبسولات
القيم الافتراضية
apply الجديدة بالفعل حماية من فقدان النصاب بالخطأ.
بالنسبة إلى ClickHouseCluster مكوّن من 3 شظايا مع
replicas: 3، ينشئ المشغّل ثلاثة PDBs، واحداً لكل شظية، بحيث يكون لكل منها minAvailable: 1.
تجاوز القيم الافتراضية
spec.podDisruptionBudget لتجاوز minAvailable أو maxUnavailable (واحد منهما فقط):
maxUnavailable، مع نسبة مئوية:
unhealthyPodEvictionPolicy إلى PDB الذي يتم إنشاؤه — ويكون ذلك مفيدًا عندما تحتاج إلى السماح بإخلاء الكبسولات التي لا تزال في حالة NotReady:
السياسات
spec.podDisruptionBudget.policy اختيار مدى صرامة إدارة المشغّل لـ PDBs:
مثال — عطّل إدارة PDB بالكامل على عنقود تطوير:
التعطيل على مستوى العنقود بالكامل
ENABLE_PDB الخاص بالمشغّل. عند ضبط ENABLE_PDB=false، يتجاوز المشغّل خطوة التسوية الخاصة بـ PDB لكل ClickHouseCluster وKeeperCluster، بغض النظر عن spec.podDisruptionBudget.policy الخاصة بهما، ولا يراقب موارد PodDisruptionBudget مطلقًا. لذلك، لا يحتاج ServiceAccount الخاص بالمشغّل إلى أذونات RBAC على poddisruptionbudgets.policy/v1، وهو ما يفيد عند تشغيل المشغّل باستخدام ServiceAccount مقيّد يستبعد تلك الأذونات عمدًا.
تكوين الحاوية
صورة حاوية مخصّصة
موارد الحاويات
متغيرات البيئة
ربط وحدات التخزين
يُسمح بتحديد عدة عمليات ربط لوحدات التخزين إلى
mountPath نفسه.
سينشئ المشغّل وحدة تخزين من نوع projected تضم جميع عمليات الربط المحددة.راجع مرجع واجهة برمجة التطبيقات للاطلاع على جميع خيارات قوالب الحاويات المدعومة.
إعدادات TLS/SSL
تهيئة نقاط نهاية آمنة
تنسيق Secret الخاص بشهادة SSL
tls.crt- شهادة الخادم بترميز PEMtls.key- المفتاح الخاص بترميز PEM
يتوافق هذا التنسيق مع الشهادات التي يُنشئها cert-manager.
اتصال ClickHouse-Keeper عبر TLS
caBundle تقوم بتهيئته.
للثقة في CA خاصة (على سبيل المثال، CA موقعة ذاتيًا أو داخلية)، قدّم مرجعًا إلى حزمة CA مخصصة:
External Secret
spec.externalSecret:
يجب أن يكون كائن Secret المشار إليه موجودًا في مساحة الاسم نفسها الخاصة بـ ClickHouseCluster. ولا يحذف المُشغِّل مطلقًا أي كائن 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.منافذ إضافية
8123 لـ HTTP، و9000 لـ native، و9009 للاتصال بين الخوادم، و9001 للإدارة، و9363 لمقاييس Prometheus، بالإضافة إلى منافذ TLS البديلة 8443/9440 عند تمكين TLS. لجعل ClickHouse يستمع إلى بروتوكولات إضافية — مثل MySQL أو PostgreSQL أو gRPC أو أي منفذ مخصّص — عرِّفها في spec.additionalPorts:
containerPorts الخاصة بالـ Pod وإلى الخدمة عديمة الرأس. ويمكن العثور على المثال الكامل في examples/custom_protocols.yaml.
مثال متكامل: MySQL wire protocol
9004:
قيود الحقول
المنافذ والأسماء المحجوزة
additionalPorts التي قد تتعارض مع المنافذ التي يستخدمها المشغّل نفسه. جميع المنافذ المرتبطة بـ TLS محجوزة دون قيد أو شرط حتى لا يؤدي تبديل spec.settings.tls.enabled لاحقًا إلى تعطيل عنقود كان صالحًا سابقًا.
تُرفض أيضًا الأسماء التالية — فهي معرّفات المشغّل الداخلية لأنواع البروتوكولات (وليست الأسماء المستعارة المفهومة للبشر):
ينتج عن الطلب المرفوض خطأ مثل:
فحص الإصدار وقناة الترقية
- الإبلاغ عن الإصدار — بالنسبة إلى
ClickHouseCluster، يشغّل مورد KubernetesJobصورة الحاوية مرة واحدة لاكتشاف إصدار ClickHouse قيد التشغيل؛ وبالنسبة إلىKeeperCluster، يقرأ المشغّل الإصدار الذي يبلّغ به الخادم من النسخ المتماثلة قيد التشغيل. ويُسجَّل الإصدار المكتشف في.status.versionوتستخدمه خطوات التسوية الأخرى (على سبيل المثال، لا يكون مفتاح named-collections الخاص بـExternal Secretمطلوبًا إلا بدءًا من ClickHouse25.12). - قناة الترقية — تحقّق دوري من موجز إصدارات ClickHouse العام (
https://clickhouse.com/data/version_date.tsv). ويبلّغ المشغغّل عمّا إذا كان إصدار أحدث متاحًا عبر شرط الحالةVersionUpgraded. وهو لا يرقّي العنقود من تلقاء نفسه مطلقًا — فالمستخدم هو من يتحكّم في وسم الصورة.
اختيار قناة الترقية
spec.upgradeChannel مجموعة الإصدارات الصادرة من المشروع الأصلي التي يقارن بها المشغّل. ويوجد الحقل نفسه في كلٍّ من ClickHouseCluster وKeeperCluster.
^(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
عند استخدام
passwordType: password، يُضبط clickhouse-client داخل الكبسولة
باستخدام كلمة المرور هذه، مما يكون مفيدًا عند تصحيح الأخطاء.استخدام ConfigMap
password_sha256_hex:
لا تضع كلمة مرور غير مشفّرة في ConfigMap. استخدم Secret لأي قيمة غير مشفّرة
(
passwordType: password).مستخدمون مخصّصون في التهيئة
مزامنة قاعدة البيانات
تسجيل الخادم
spec.settings.logger. كل حقل اختياري وله قيمة افتراضية آمنة، لذا فإن أي عنقود لا تُجري عليه أي تعديل يسجّل بالفعل عند مستوى trace في كلٍّ من وحدة تحكم الحاوية وملف سجل خاضع للتدوير على القرص.
يُبقي المشغّل التسجيل إلى وحدة التحكم مفعّلًا دائمًا لكي يعمل
kubectl logs، ويضيف التسجيل إلى الملف فوق ذلك عندما تكون logToFile بقيمة true. وينتج عن عنقود بالإعدادات الافتراضية كتلة logger التالية:
spec.settings.logger نفسه على KeeperCluster؛ لكن المشغّل يكتب ملفاته في هذه الحالة ضمن /var/log/clickhouse-keeper/.
يظل التسجيل إلى الطرفية مفعّلًا بغضّ النظر عن
logToFile، لذا يواصل kubectl logs العمل حتى عند تعطيل التسجيل إلى ملف. اضبط jsonLogs: true عند إرسال السجلات إلى مخزن سجلات منظَّم يحلّل JSON.إعداد مخصص
تهيئة إضافية مضمنة
extraConfig:
روابط مفيدة:
إعدادات المستخدمين الإضافيين المضمّنة
extraUsersConfig. ويُفيد ذلك في تعريف المستخدمين وملفات التعريف والحصص والامتيازات مباشرةً ضمن مواصفات العنقود.
يتم تخزين
extraUsersConfig في كائن ConfigMap ضمن k8s. تجنّب وضع الأسرار هناك بصيغة نصية مكشوفة.