Kubernetes لأحمال عمل ML

خبرة Kubernetes تفصل مهندسي MLOps عن DevOps العام. توقع أسئلة عميقة حول أنماط K8s الخاصة بـ ML.

سؤال المقابلة الأساسي: نشر ML

السؤال: "صمم نشر Kubernetes لنموذج يخدم 10,000 طلب في الثانية."

إطار الإجابة:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-serving
spec:
  replicas: 10  # ابدأ بالتوسع الأفقي
  selector:
    matchLabels:
      app: model-serving
  template:
    metadata:
      labels:
        app: model-serving
    spec:
      containers:
      - name: model-server
        image: model-serving:v1.2.3
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
            nvidia.com/gpu: "1"  # طلب GPU
          limits:
            memory: "8Gi"
            cpu: "4"
            nvidia.com/gpu: "1"
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30  # وقت تحميل النموذج
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 60
          periodSeconds: 10
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: model-serving
              topologyKey: "kubernetes.io/hostname"

المفاهيم الرئيسية التي يختبرها المحاورون

المفهوم	لماذا يهم لـ ML	السؤال الشائع
Requests مقابل Limits	ذاكرة GPU لا يمكن تجاوزها	"ماذا يحدث إذا لم تحدد limits؟"
Tolerations	عقد GPU غالباً مُلوثة	"كيف تجدول على عقد GPU؟"
Probes	النماذج تستغرق وقتاً للتحميل	"لماذا initialDelaySeconds مهم؟"
Anti-affinity	التوزيع للتوفر	"كيف تتعامل مع فشل العقد؟"

Horizontal Pod Autoscaler لـ ML

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: model-serving-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: model-serving
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: inference_latency_p99
      target:
        type: AverageValue
        averageValue: "100m"  # هدف 100ms
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300  # تقليص محافظ
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

متابعة المقابلة: "لماذا استقرار التقليص أطول من التوسع؟"

الإجابة: "تسخين النموذج مكلف. التقليص السريع جداً يسبب ارتفاعات في زمن الاستجابة عند عودة الحركة. نستخدم استقرار 5 دقائق لتجنب التذبذب."

تعمق في جدولة GPU

# تسميات العقد لأنواع GPU
kubectl label nodes gpu-node-1 gpu-type=a100
kubectl label nodes gpu-node-2 gpu-type=t4

# Pod مع اختيار GPU محدد
spec:
  nodeSelector:
    gpu-type: a100
  containers:
  - name: training
    resources:
      limits:
        nvidia.com/gpu: 4  # طلب 4 A100s

سؤال المقابلة: "كيف ستتعامل مع وظائف التدريب متعددة GPU؟"

الإجابة: "استخدم Kubernetes Jobs مع نسخ متعددة، كل منها يطلب 1+ GPU. للتدريب الموزع، استخدم Training Operator من Kubeflow الذي يدير موارد PyTorchJob أو TFJob مع شبكات pod-to-pod مناسبة."

نصيحة احترافية: اعرف الفرق بين nvidia.com/gpu وأنواع موارد GPU الأخرى (amd.com/gpu، intel.com/gpu) للمناقشات المستقلة عن السحابة.

في الدرس التالي، سنستكشف البنية التحتية لتقديم النماذج. :::