GKE يرفع الحد إلى 512 Pod لكل عقدة: هل ينبغي استخدامه؟

غيّرت Google Cloud في 25 سبتمبر 2026 حدًا فعليًا في سعة Kubernetes: أصبحت عناقيد GKE Standard تدعم حتى 512 Pod لكل عقدة، أي ضعف الحد السابق البالغ 256. وتخصص GKE للعقد المضبوطة بين 257 و512 Pod نطاق `/22` يحوي 1,024 عنوان IP للـPods.

قد يبدو العنوان دعوة لحشر أحمال أكثر في عدد أقل من الأجهزة، لكنه في الحقيقة خيار تصميم إضافي. ترتبط كثافة Pods بحجم العقدة ونطاقات IP الثانوية وكلفة DaemonSets والجدولة ومدة الصيانة وعدد الأحمال التي تفقدها عند تعطل عقدة واحدة. يخبرك الحد بما تستطيع GKE دعمه، لا بما يجب أن تختاره أهداف الاعتمادية لديك.

ما الذي تغير، وما الذي بقي كما هو؟

ينطبق الحد الجديد على GKE Standard. ويبقى الحد الافتراضي 110 Pods لكل عقدة، ويحجز عادةً نطاق `/24` يحتوي 256 عنوان Pod لكل عقدة. أما GKE Autopilot فما زال يختار قيمة ديناميكية تصل إلى 256 ولا يسمح للمشغّل بضبطها.

توضح وثائق إعداد الحد الأقصى للـPods أن القيمة تُختار عند إنشاء Standard cluster أوnode pool ولا يمكن تغييرها بعد ذلك. لن تتحول pools الحالية إلى 512 لمجرد ارتفاع حد المنصة. يحتاج التبني إلى إنشاء node pool جديدة بالكثافة المطلوبة ونقل الأحمال إليها عمدًا.

وهذا حد جدولة، لا وعدًا بأن CPU أوالذاكرة أوالقرص أوالشبكة أوkubelet تستطيع تحمل 512 نسخة من أي حمل. تستهلك System Pods مواقع أيضًا، ويحدد كل من requests وlimits وsidecars وprobes وحجم logs وعدد الاتصالات السقف العملي.

حسابات IP تصبح القيد الأول

تستخدم GKE نطاقات alias IP في VPC-native حتى يحصل كل Pod على عنوان فريد. ويحتوي النطاق المخصص للعقدة عمدًا على ضعف الحد الأقصى على الأقل: 110 Pods تستخدم `/24` بعدد 256 عنوانًا، و129–256 تستخدم `/23` بعدد 512، و257–512 تستخدم `/22` بعدد 1,024.

يغير ذلك عدد كتل العقد التي تدخل في secondary Pod range. يحتوي `/16` على 65,536 عنوانًا؛ تقسيمه إلى كتل `/24` يعطي 256 كتلة عقدة نظريًا، بينما يعطي `/22` عدد 64 فقط. هذه أعداد توزيع عناوين قبل حصص GKE الأخرى وحدود السعة الفعلية، وليست ضمانًا لحجم cluster.

قد ينفد secondary range أسرع من فريق فعّل 512 لتقليل عدد العقد إذا احتاج autoscaling إلى عدد كبير منها. افحص النطاق الحالي وبقية node pools وهامش النمو أولًا. تدعم GKE إضافة نطاقات Pod غير متصلة، لكن ذلك قرار تصميم شبكة وليس بديلًا عن sizing صحيح للـpool الأصلية.

لماذا تبدو الكثافة العالية جذابة؟

تحمل كل عقدة Kubernetes كلفة ثابتة: نظام تشغيل وkubelet وcontainer runtime وعوامل المراقبة والأمان وعدة DaemonSet Pods غالبًا. تجميع application Pods خفيفة على عدد أقل من العقد الكبيرة قد يقلل هذه الكلفة المكررة. وقد يفيد أحمالًا فيها مئات workers صغيرة ومتجانسة عندما تتوفر موارد في العقدة لكن حد Pods القديم كان يجبر autoscaler على إضافة أجهزة.

يعتمد الاقتصاد على الحمل. قد يستهلك service-mesh sidecar ذاكرة واتصالات أكثر من application container. وقد تعالج عوامل logs والأمان stream لكل container. ويمكن أن تصبح image pulls وephemeral storage وDNS القيد قبل امتلاء CPU requests. قِس footprint الكامل لكل Pod، لا request الحاوية الرئيسية فقط.

توصي أفضل ممارسات الشبكات في Google بعقد تحتوي 16 CPU core على الأقل عند ضبط أكثر من 110 Pods. ويقدم دليل تخطيط العناقيد الكبيرة إشارة أخرى: vCPU واحدة على الأقل لكل عشرة Pods، ويذكر أن حد 512 يفترض متوسط حاويتين أو أقل لكل Pod. هذه إرشادات تخطيط وليست إثباتًا أن عقدة 16-core آمنة عند 512.

يكبر الـBlast Radius التشغيلي

إذا استضافت العقدة 80 Pod، فإن فقدانها يطلب من بقية cluster إعادة جدولة قرابة 80 حملًا. أما عند 500 فينشئ الفشل موجة تعافٍ أكبر بكثير: Pending Pods وimage pulls وتحديثات endpoints وحركة DNS وربط storage وcold starts. يجب موازنة السعة الموفرّة في التشغيل الطبيعي بسعة احتياطية تمتص هذه الموجة.

تصبح الصيانة الإرادية أثقل أيضًا. يستخدم Kubernetes drain واجهة Eviction ويحترم PodDisruptionBudgets، لذلك قد تستغرق عقدة كثيفة تحتوي أحمالًا محمية وقتًا أطول لتفرغ أو تتوقف بسبب budgets متعارضة. أما node-pressure eviction غير الإرادي فمختلف وقد لا يحترم PDB. لذلك تجعل الكثافة اختبار مسار الصيانة الطبيعي ومسار الفشل القاسي ضروريين.

وتوزيع replicas هو الحماية الثانية. تستطيع Topology Spread Constraints توزيع النسخ عبر hostnames وzones بدل السماح لعقدة عالية السعة بجمع معظم نسخ خدمة واحدة. تحد PDBs الاضطراب الإرادي المتزامن، لكنها لا توزع Pods ولا تعيد السعة المفقودة؛ استخدم كل أداة لوظيفتها.

طرح آمن عبر Node Pool عالية الكثافة

ابدأ بـcanary pool مخصصة، لا بتغيير يشمل cluster. اختر أحمالًا stateless وخفيفة لها عدة replicas ووقت startup محدود ولا تعتمد على local disk هش. أبقِ قواعد البيانات وأنظمة quorum والعوامل الحساسة للـlatency خارج أول انتقال.

gcloud container node-pools create density-canary \
  --cluster=production \
  --max-pods-per-node=512 \
  --machine-type=<large-machine-type> \
  --num-nodes=<small-canary-count>

تحقق من الأمر الدقيق ومن دعم machine type في المنطقة وrelease channel المستهدفة قبل التنفيذ. ضع label وtaint للـpool الجديدة حتى لا يدخلها إلا الحمل المختار. انقل Deployment واحدة كل مرة واحتفظ بمسار رجوع إلى pool القديمة.

راقب CPU وذاكرة العقدة واستهلاك kubelet وruntime وPod startup latency وأخطاء DNS وconnection tracking وسلوك CNI وضغط الصور وephemeral storage وتدفق log agents وPending Pods وقرارات autoscaler وعدد Pods في كل عقدة. ثم نفذ تمرينين مضبوطين: drain لعقدة كثيفة تحت budgets العادية، ومحاكاة فقدان عقدة أثناء حركة قريبة من الذروة.

النجاح ليس «استطعنا جدولة 512»، بل بقاء application latency ضمن هدفه، وبدء replacement Pods خلال recovery target، ووجود headroom في pools الأخرى، واستقرار الشبكة والمراقبة أثناء churn.

قائمة فحص لتخطيط السعة

احسب مساحة العناوين لكل pool قبل موارد العقدة. عند 512 Pod مضبوطة، احجز `/22` لكل عقدة محتملة، بما فيها surge capacity أثناء upgrades. وتأكد أن maximums في cluster autoscaler لا تسمح بإنشاء عقد أكثر مما يستطيع Pod range عنونته.

بعد ذلك تعامل مع العقدة كـfailure domain. احسب عدد replicas من الخدمة نفسها التي قد تجتمع فيها، وافرض توزيع hostname وzone حيث يلزم، وتأكد أن فقدان عقدة واحدة لا يتجاوز افتراضات error budget. اختبر PDBs مقابل عدد النسخ الحقيقي وقِس مدة drain بدل افتراض كفاية manifests.

وأدخل الكلفة الثابتة والمتغيرة: DaemonSets لكل عقدة، وsidecars لكل Pod، وعدد containers، وتخزين الصور، والاتصالات المفتوحة، وlogs وmetrics. قد يقلل الحد الأعلى الكلفة الثابتة لكل عقدة بينما يزيد الضغط المتغير لكل Pod. غالبًا تكون النقطة المثلى أقل من الحد الصلب.

متى يكون 512 منطقيًا؟

يناسب الخيار أساطيل الخدمات الصغيرة stateless وevent consumers وCI workers أوالأحمال متعددة tenants الخفيفة فوق أجهزة كبيرة، خصوصًا عندما كانت كلفة DaemonSets أوحد 256 تسبب scale-out مبكرًا. وقد يفيد batch pools متخصصة تتحمل إعادة تشغيل مركزة.

لكنه ليس default جيدًا لعناقيد مختلطة ذات requests غير دقيقة أوsidecars كبيرة أوأحمال stateful أوtermination طويل أوضوابط توزيع ضعيفة. وإذا كان الهدف توفير عناوين Pod، فالكثافة الأعلى تحجز عناوين أكثر لكل عقدة؛ تخفيض الحد الأقصى يحفظ مساحة عناوين لعدد أكبر من العقد.

القرار العملي هو التعامل مع 512 كحد أعلى جديد لـpool مصممة خصيصًا. أنشئ pool جديدة، وأثبت صحة IP plan، وحجّم العقد الكبيرة من قياسات per-Pod، ووزع replicas، واختبر drain والفقد، واحتفظ بسعة rollback. وسعت GKE مساحة التصميم، لكن هندسة المنصة الموثوقة ما زالت تختار نقطة التشغيل.

إعداد: Noor Yasser