السحابة المتعددة: Azure وGCP

GKE: كوبيرنيتيس بالطريقة الجوجلية

18 دقيقة الدرس 7 من 28

GKE: كوبيرنيتيس بالطريقة الجوجلية

جوجل هي من اخترعت كوبيرنيتيس. وGKE ليس مجرد نقل لكوبيرنيتيس مفتوح المصدر إلى منصة GCP — بل هو التطبيق المرجعي الذي تديره الفرق الهندسية ذاتها التي تشغّل كوبيرنيتيس على نطاق كوكبي داخل بنية جوجل التحتية. كل إصدار من GKE يصدر قبل أن يستقر الإصدار المكافئ من النسخة الذاتية الإدارة. هذا الأصل مهم: الإعدادات الافتراضية لـ GKE تُجسّد قرارات استغرق من جوجل سنواتٍ من ألم الإنتاج الفعلي للوصول إليها. يستعرض هذا الدرس تلك القرارات — Autopilot مقابل Standard، وتصميم Node Pools، وWorkload Identity — لتتمكن من تشغيل GKE بحكمة من يمتلك خبرة إنتاج حقيقية على نطاق كبير.

Autopilot مقابل Standard: الإعداد الافتراضي الصحيح

يوفر GKE وضعين تشغيليين يتوازنان بين التحكم والبساطة التشغيلية.

الوضع Standard يمنحك تحكماً كاملاً في إعداد العقد: تختار نوع الآلة، وحجم القرص، وتخصيص GPU، ونظام تشغيل العقدة (Container-Optimized OS أو Ubuntu)، وكل إعداد kubelet. أنت مسؤول عن حجم Node Pool، وإعداد مُوزّع الحمل التلقائي للعنقود، ودفع تكلفة الطاقة الخاملة للعقد. يُعدّ الوضع Standard الخيار الصحيح حين تحتاج إلى أجهزة خاصة (TPUs أو GPU A100)، أو معلمات نواة محددة، أو DaemonSets يجب تشغيلها على كل عقدة دون استثناء.

الوضع Autopilot يُزيل إدارة العقد بالكامل. تُعلن عن Pods؛ وتقوم GCP تلقائياً بتوفير العقد الأساسية وتصحيحها وتوسيع نطاقها. تدفع وفق وحدات المعالجة والذاكرة المطلوبة لكل Pod، لا وفق عدد العقد. يُطبّق Autopilot وضعاً أمنياً مُصلَّباً افتراضياً: لا حاويات ذات امتيازات، ولا شبكة مضيف، ولا وحدات تخزين hostPath، وطلبات موارد إلزامية على كل حاوية. لـ 80 % من أحمال عمل الإنتاج — خدمات الويب، وواجهات البرمجة، والمهام الدفعية، والخدمات المصغّرة — يُعدّ Autopilot الإعداد الافتراضي الصحيح إنتاجياً. إنه يُزيل المصدر الأول لعناء التشغيل في GKE: ضبط حجم Node Pools.

نموذج فوترة Autopilot يُمثّل تحولاً جذرياً في التفكير. في الوضع Standard، تقبع عقدة بـ 8 vCPU خاملةً بين عمليات النشر وتظل تُكلّفك. أما في Autopilot فتدفع فقط عن مجموع وحدات المعالجة والذاكرة المطلوبة عبر جميع Pods الجارية. تختفي العقد المُفرطة في التوفير كعامل تكلفة. وعلى نطاق واسع يُخفض هذا فواتير الحوسبة عادةً بنسبة 30-50 % مقارنةً بعناقيد Standard غير المُحسَّنة.

معايير اختيار Autopilot أو Standard

استخدم Autopilot ما لم يكن لديك متطلب محدد يُجبرك على Standard:

استخدم Autopilot: خدمات عديمة الحالة، وأحمال عمل مدفوعة بالأحداث، وعناقيد مطوّرين متعددة المستأجرين، وتحسين التكلفة كهدف أساسي، ودون متطلبات خاصة لنظام التشغيل أو النواة.
استخدم Standard: DaemonSets ذات امتيازات (إضافات CNI، أو عوامل أمان مبنية على eBPF)، وأحمال عمل GPU/TPU، وNode Pools من نوع spot للمهام الدفعية الضخمة، وtaints مخصصة تُطبَّق على مستوى نظام التشغيل، أو متطلبات امتثال تفرض صور نظام تشغيل محددة.

إنشاء عنقود Autopilot يتطلب علامة واحدة فقط:

# إنشاء عنقود Autopilot في us-central1
gcloud container clusters create-auto prod-cluster \
  --region=us-central1 \
  --release-channel=regular \
  --network=prod-vpc \
  --subnetwork=prod-gke-subnet \
  --cluster-secondary-range-name=pods \
  --services-secondary-range-name=services

# الحصول على بيانات الاعتماد
gcloud container clusters get-credentials prod-cluster \
  --region=us-central1

Node Pools في الوضع Standard

حين يكون الوضع Standard ضرورياً، يصبح تصميم Node Pool قراراً معمارياً من الدرجة الأولى. Node Pool هو مجموعة من العقد المتطابقة في نوع الآلة، والقرص، ونظام التشغيل، والتسميات. يتيح لك GKE تشغيل عدة Node Pools في عنقود واحد، وهكذا تحقق عناقيد الإنتاج كفاءة التكلفة إلى جانب اتفاقيات أداء الخدمة.

عنقود GKE Standard في الإنتاج بثلاثة Node Pools: النظام (الإضافات)، والتطبيقات (أحمال العمل العامة)، والـ GPU (الاستدلال/التدريب على عقد spot).

النمط المعياري هو ثلاثة Node Pools: pool النظام صغير للإضافات (مُقيَّد بـ CriticalAddonsOnly لمنع Pods التطبيقات من الجدولة عليه)، وpool التطبيقات العامة مع تفعيل Cluster Autoscaler، وpool متخصص (GPU، أو ذاكرة عالية، أو spot) للأحمال الحساسة للتكلفة.

# إنشاء عنقود Standard مع pool نظام
gcloud container clusters create prod-cluster \
  --region=us-central1 \
  --release-channel=regular \
  --enable-ip-alias \
  --network=prod-vpc \
  --subnetwork=prod-gke-subnet \
  --node-pool=system-pool \
  --machine-type=e2-standard-4 \
  --num-nodes=1 \
  --node-taints=CriticalAddonsOnly=true:NoSchedule

# إضافة pool التطبيقات مع التوسع التلقائي
gcloud container node-pools create app-pool \
  --cluster=prod-cluster \
  --region=us-central1 \
  --machine-type=n2-standard-8 \
  --num-nodes=3 \
  --enable-autoscaling \
  --min-nodes=3 \
  --max-nodes=20 \
  --disk-type=pd-ssd \
  --disk-size=100

# إضافة pool GPU spot لأحمال تعلم الآلة
gcloud container node-pools create gpu-pool \
  --cluster=prod-cluster \
  --region=us-central1 \
  --machine-type=a2-highgpu-1g \
  --accelerator=type=nvidia-tesla-a100,count=1 \
  --spot \
  --num-nodes=0 \
  --enable-autoscaling \
  --min-nodes=0 \
  --max-nodes=5 \
  --node-taints=nvidia.com/gpu=present:NoSchedule

افصل دائماً بين أحمال عمل النظام والتطبيقات. قيّد pool النظام بـ CriticalAddonsOnly=true:NoSchedule. هذا يمنع Pods التطبيقات — خاصةً تلك التي تُعاني من تسرب الذاكرة — من إزاحة DaemonSets الحيوية للعنقود مثل fluentd أو kube-proxy تحت ضغط الذاكرة. في جوجل هذا النمط إلزامي لأي عنقود يتجاوز 10 عقد.

Workload Identity: الطريقة الصحيحة لمنح صلاحيات السحابة

أكثر أخطاء أمان GKE شيوعاً هو تخزين مفتاح حساب خدمة GCP كـ Kubernetes Secret وتركيبه داخل Pods. يمكن استخراج المفاتيح، وتدويرها بشكل خاطئ، والتخلي عنها داخل صور الحاويات. Workload Identity يُلغي المفاتيح تماماً بربط Kubernetes ServiceAccount بـ GCP IAM Service Account عبر تبادل رمز OIDC متحدّث — يحصل Pod على رمز قصير العمر تلقائياً دون بيانات اعتماد ثابتة في أي مكان.

يعمل الربط في ثلاث خطوات: تفعيل Workload Identity على العنقود، إضافة annotation على Kubernetes ServiceAccount تشير إلى GCP IAM Service Account، ومنح GCP IAM Service Account دور roles/iam.workloadIdentityUser على زوج Namespace/ServiceAccount في كوبيرنيتيس.

# 1. تفعيل Workload Identity على عنقود قائم
gcloud container clusters update prod-cluster \
  --region=us-central1 \
  --workload-pool=YOUR_PROJECT_ID.svc.id.goog

# 2. إنشاء GCP IAM Service Account لحمل العمل
gcloud iam service-accounts create api-service-sa \
  --display-name="API Service SA"

# منحه الصلاحيات التي يحتاجها فعلاً (مبدأ الحد الأدنى من الصلاحيات)
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="serviceAccount:api-service-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# 3. ربط Kubernetes ServiceAccount بـ GCP IAM SA
gcloud iam service-accounts add-iam-policy-binding \
  api-service-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:YOUR_PROJECT_ID.svc.id.goog[api-namespace/api-service-ksa]"

يحتاج مانيفست Kubernetes ServiceAccount إلى annotation واحدة فقط لإتمام الربط:

# kubernetes/service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-service-ksa
  namespace: api-namespace
  annotations:
    iam.gke.io/gcp-service-account: api-service-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com
---
# استخدامه في Deployment — دون تركيب أي Secret
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
  namespace: api-namespace
spec:
  template:
    spec:
      serviceAccountName: api-service-ksa   # <-- هذا كل ما هو مطلوب
      containers:
        - name: api
          image: gcr.io/YOUR_PROJECT_ID/api:v1.2.0
          # تكتشف مكتبات GCP Client الرمز تلقائياً
          # عبر خادم البيانات الوصفية على 169.254.169.254

لا يعمل Workload Identity إذا كان Node Pool لا يزال يعمل بإصدارات قديمة جداً. تحقق بالأمر kubectl describe node | grep -i workload وتأكد من أن العقد تعمل بإصدار GKE 1.18+ (جميع قنوات الإصدار تجاوزت ذلك بكثير). أيضاً، أي Pod يتصل بخادم البيانات الوصفية لـ GCP مباشرةً للحصول على بيانات اعتماد على مستوى العقدة (هجوم حركة جانبية كلاسيكي) يُحجَب بواسطة Workload Identity — يُعيد خادم البيانات الوصفية رمزاً مقيداً بـ Kubernetes SA المرتبطة فحسب، وليس بـ SA للعقدة. هذا حد أمني بالغ الأهمية.

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

تشترك عناقيد GKE في قناة إصدار — rapid أو regular أو stable. تُدير جوجل جميع ترقيات مستوى التحكم تلقائياً على العناقيد المشتركة في قناة. يمكن تكوين ترقيات العقد بـ surge upgrades (رفع عقد إضافية قبل تصريف القديمة) أو blue/green node pool upgrades (pool موازٍ كامل، تحويل حركة المرور، حذف القديم). للإنتاج، قناة regular مع ترقيات blue/green هي الأساس الموصى به: تظل محدَّثاً دون تشغيل إصدارات غير مختبرة، والترقيات تتم دون توقف.

Autopilot يتولى الترقيات بالكامل نيابةً عنك. في الوضع Standard، اضبط surge upgrades بالتكوين: --max-surge-upgrade=1 --max-unavailable-upgrade=0. هذا يضمن توفر عقدة إضافية واحدة على الأقل خلال الترقية المتدرجة حتى لا يُزاح أي حمل عمل دون وجود موضع بديل له.

أنماط فشل الإنتاج الواجب معرفتها

ثغرات PodDisruptionBudget أثناء ترقيات العقد: إذا لم تُعرّف PDB، سيُصرّف GKE عقدة بعدوانية وستشهد خدمتك أخطاء. عرّف minAvailable: 2 لأي Deployment إنتاجي يحتوي على أكثر من replica واحدة.
استنفاد عناوين IP: يحجز GKE في وضع VPC-native شبكة CIDR ثانوية كبيرة للـ Pods. إذا صغّرت الشبكة الفرعية الثانوية عند إنشاء العنقود، ستصطدم بسقف عناوين IP بصمت — تفشل Pods الجديدة في الجدولة برسالة no available IP addresses. خطط لذروة عدد الـ Pods مضافاً إليها 30 % هامش منذ اليوم الأول.
زمن استجابة خادم البيانات الوصفية لـ Workload Identity: قد يستغرق أول جلب رمز من 169.254.169.254 من 200 إلى 400 مللي ثانية عند البداية الباردة. سخّن مكتبات GCP Client عند بدء تشغيل التطبيق، وليس عند كل طلب على حدة.