Skip to main content

​
Customer-managed VPC (BYO-VPC) for GCP

إذا كنت تفضّل استخدام شبكة VPC الحالية لنشر ClickHouse BYOC بدلًا من أن يقوم ClickHouse Cloud بتجهيز VPC جديدة، فاتبع الخطوات أدناه. يوفّر هذا النهج قدرًا أكبر من التحكم في تكوين الشبكة، ويتيح لك دمج ClickHouse BYOC ضمن البنية التحتية الحالية لشبكتك.
1

تكوين شبكة VPC الحالية

  1. خصّص شبكة فرعية خاصة واحدة على الأقل في منطقة تدعمها ClickHouse BYOC لعنقود ClickHouse Kubernetes (GKE). تأكد من أن الشبكة الفرعية تحتوي على نطاق CIDR لا يقل عن /24 (على سبيل المثال: 10.0.0.0/24) لتوفير عدد كافٍ من عناوين IP لعُقد عنقود GKE.
  2. داخل الشبكة الفرعية الخاصة، خصّص نطاق IPv4 ثانويًا واحدًا على الأقل لاستخدامه لوحدات Pod في عنقود GKE. يجب أن يكون النطاق الثانوي /21 على الأقل. لا توفّر النطاقات الأصغر عددًا كافيًا من عناوين IP لوحدات Pod كي يتمكّن عنقود GKE من إكمال عملية التجهيز، وسيفشل إعداد البنية التحتية.
  3. فعّل Private Google Access على الشبكة الفرعية. يتيح ذلك لعُقد GKE الوصول إلى واجهات برمجة تطبيقات Google وخدماتها من دون الحاجة إلى عناوين IP خارجية.
لعرض الخدمات عبر Private Service Connect، تحتاج أيضًا إلى شبكة فرعية مخصصة بالغرض PRIVATE_SERVICE_CONNECT في شبكة VPC هذه. يمكنك إنشاؤها الآن أو لاحقًا، قبل تفعيل private link.
2

ضمان اتصال الشبكة

بوابة Cloud NAT تأكد من نشر بوابة Cloud NAT لـ VPC. فهي توفّر الاتصال الصادر للمثيلات التي لا تملك عناوين IP خارجية، ويعتمد عليها أمران:
  • Tailscale. تُسجَّل مكونات ClickHouse BYOC لدى مستوى التحكم الخاص بـ Tailscale، الذي يوفّر شبكة آمنة قائمة على مبدأ انعدام الثقة لعمليات الإدارة الخاصة من دون الحاجة إلى وصول عام وارد.
  • صور الحاويات. بعض الصور التي يشغّلها النشر غير منسوخة إلى سجل BYOC، بما في ذلك صور المجتمع، ويتم سحبها من سجلاتها الأصلية.
لن تُكمل شبكة VPC التي لا تمتلك مسارًا صادرًا عملية التجهيز؛ إذ يتحقق التحقق المسبق من وجود بوابة Cloud NAT تغطي الشبكة. ولا توجد قائمة منشورة واحدة بنقاط النهاية؛ فإذا كانت سياسة شبكتك تتطلب جردًا صريحًا، فتواصل مع الدعم لمراجعة إعدادك.DNS Resolution تأكد من أن VPC لديك تتمتع بآلية DNS resolution تعمل بشكل صحيح، وأنها لا تحجب أسماء DNS القياسية ولا تتداخل معها أو تستبدلها. يعتمد ClickHouse BYOC على DNS لتحليل أسماء خوادم التحكم الخاصة بـ Tailscale ونقاط نهاية خدمة ClickHouse. إذا لم يكن DNS متاحًا أو كان تكوينه غير صحيح، فقد تتعذر خدمات BYOC عن الاتصال أو العمل بشكل صحيح.
3

إعداد البنية التحتية لـ BYOC

عند النقر على Set up Infrastructure، يُجري ClickHouse Cloud تلقائيًا التحقق المسبق قبل التجهيز. فهو يتحقق من أن حساب خدمة الإدارة لديه الأذونات المطلوبة وأن واجهات برمجة تطبيقات Google Cloud المطلوبة مفعّلة، كما يتحقق من صحة شبكة VPC التي تحضرها بنفسك: من إمكانية تحليل الشبكة والشبكة الفرعية، ومن أن النطاق الأساسي للشبكة الفرعية والنطاق الثانوي لوحدات Pod كبيران بما يكفي، ومن وجود بوابة Cloud NAT تغطي الشبكة. وإذا كان أي عنصر مفقودًا، فسيتوقف الإعداد مع بيان المشكلات المحددة التي يجب إصلاحها.
في وحدة تحكم ClickHouse Cloud، قم بتكوين ما يلي عند إعداد بنية تحتية جديدة:
  1. ضمن VPC configuration، اختر Use existing VPC.
  2. أدخل اسم شبكة VPC.
  3. أدخل اسم الشبكة الفرعية التي خصصتها لـ ClickHouse.
  4. اختياريًا، أدخل Secondary range names لتحديد أي من النطاقات الثانوية للشبكة الفرعية يستخدمه GKE لوحدات Pod. اتركه فارغًا لاستخدامها جميعًا؛ ويجب أن يكون كل اسم تُدرجه موجودًا مسبقًا على الشبكة الفرعية.
  5. إذا كانت شبكة VPC لديك موجودة في مشروع مضيف لشبكة Shared VPC، فأدخل Shared VPC host project ID. اتركه فارغًا عندما تكون شبكة VPC في المشروع نفسه الذي توجد فيه البنية التحتية. راجع شبكة Shared VPC من مشروع مضيف أدناه.
  6. انقر على Set up Infrastructure لبدء التجهيز.

​
شبكة VPC المشتركة من مشروع مضيف

يمكنك تشغيل BYOC في مشروع خدمة على شبكة موجودة في مشروع مضيف منفصل من نوع Shared VPC، ما يتيح لك إبقاء إدارة الشبكات مركزية. فشبكة VPC وشبكاتها الفرعية مملوكة للمشروع المضيف، بينما تعمل البنية التحتية لـ BYOC في مشروع خدمة مرفق به. وتبقى المتطلبات المذكورة أعلاه كما هي؛ غير أنها تنطبق على الشبكة الفرعية في المشروع المضيف. هناك متطلبان مسبقان خاصان بهذا الإعداد:
  • فعّل المشروع المضيف كمضيف Shared VPC، وأرفق مشروع الخدمة به، قبل أن تبدأ. كلتا الخطوتين مطلوبة، وهما خطوتان منفصلتان: المشروع الذي ليس مضيف Shared VPC أصلاً يجب تفعيله كمضيف أولاً، وعندئذ فقط يمكن إرفاق مشروع الخدمة. ويشترط عنقود GKE على Shared VPC وجود هذا الإرفاق. أما عملية التحقق المسبق فتقرأ شبكتك وشبكتك الفرعية عبر الأذونات الممنوحة على المشروع المضيف سواء أكان الإرفاق قائماً أم لا، لذا تنجح في الحالتين، ثم يفشل التجهيز لاحقاً عند إنشاء العنقود. وكلتا العمليتين على مستوى المنظمة وينفذهما من يتولى إدارة Shared VPC في منظمتك؛ ولا يمكن لـ Terraform الخاص بالـ onboarding القيام بهما نيابة عنك.
  • شغّل Terraform الخاص بالـ onboarding مع تحديد المشروع المضيف. مرّر shared_vpc_host_project_id وshared_vpc_host_subnet_region وshared_vpc_host_private_subnet_id إلى onboarding module. والقيمة shared_vpc_host_private_subnet_id هي الشبكة الفرعية المضيفة التي تعمل فيها عُقد GKE لديك — تلك التي هيّأتها أعلاه — وليست الشبكة الفرعية الخاصة بـ Private Service Connect الموضحة أدناه. فتوجيهها إلى شبكة PSC الفرعية يضع إذن roles/compute.networkUser على الشبكة الفرعية الخاطئة، فيفشل التجهيز عند إنشاء العنقود. ويكتب الاستدعاء الواحد في المشروعين معاً، لذا تحتاج الـ credentials التي تشغّله إلى صلاحيات Admin على IAM في مشروع الخدمة وفي المشروع المضيف.
الأذونات التي تضيفها الوحدة إلى مشروعك المضيف محدودة النطاق، لكنها ليست جميعها للقراءة فقط: الصف الأخير هو صلاحية الكتابة الوحيدة، وهي ممنوحة لوكيل خدمة GKE في مشروعك أنت لا لـ ClickHouse. فحساب خدمة إدارة ClickHouse لا يكتب أبداً في المشروع المضيف. كما تفعّل الوحدة واجهة container.googleapis.com في المشروع المضيف، وهو ما يجهّز وكيل خدمة GKE الخاص بذلك المشروع. بعد ذلك أدخل المشروع المضيف في حقل Shared VPC host project ID الموضّح أعلاه. وإذا أردت استخدام Private Link، فأنشئ شبكة فرعية منفصلة من نوع PRIVATE_SERVICE_CONNECT في المشروع المضيف، ضمن الشبكة والمنطقة نفسيهما للشبكة الفرعية للعُقد. فهي توجد إلى جانب الشبكة الفرعية للعُقد ولا تحل محلها، وليست الشبكة الفرعية التي تمرّرها في shared_vpc_host_private_subnet_id.
آخر تعديل في ٢٦ سبتمبر ٢٠٢٦