شرح Kubernetes: دليل عملي لعام

ملخص

Kubernetes هي المنصة القياسية في الصناعة لتنسيق الحاويات (container orchestration) التي تعمل على أتمتة نشر وتوسيع وإدارة التطبيقات المعبأة في حاويات. يغطي هذا الدليل الشامل كل شيء بدءًا من المفاهيم الأساسية وصولاً إلى ممارسات الإنتاج المتقدمة، بما في ذلك:

• البنية الأساسية ومكونات Kubernetes
• أساسيات الشبكات (Services، Ingress، Network Policies)
• أفضل ممارسات الأمان باستخدام RBAC و Pod Security
• مقارنة تفصيلية مع Docker Swarm و HashiCorp Nomad
• دليل تعليمي خطوة بخطوة لنشر AWS EKS
• الميزات المتقدمة مثل Horizontal Pod Autoscaling و StatefulSets
• حالات استخدام واقعية عبر مختلف الصناعات

مكتملًا بأمثلة عملية، ورسوم بيانية توضيحية، وتكوينات جاهزة للإنتاج، يوفر هذا الدليل كل ما تحتاجه لإتقان Kubernetes في الممارسة العملية.

ما هو Kubernetes ولماذا تحتاجه؟

يتم بناء التطبيقات الحديثة بشكل متزايد كأنظمة موزعة تتكون من خدمات مصغرة (microservices) معبأة في حاويات. بينما تقوم الحاويات (مثل Docker) بتغليف التطبيقات والاعتمادات، فإن إدارة هذه الحاويات عبر خوادم متعددة يطرح تحديات كبيرة. هنا يأتي دور Kubernetes (K8s) - وهي منصة مفتوحة المصدر مصممة لأتمتة نشر وتوسيع وإدارة التطبيقات المعبأة في حاويات.

المشكلة الأساسية التي يحلها Kubernetes هي تنسيق الحاويات عبر مجموعة (cluster) من الأجهزة. بدون منسق (orchestrator)، ستحتاج إلى إدارة ما يلي يدويًا:

• أي الخوادم تقوم بتشغيل أي الحاويات
• كيفية تواصل الحاويات مع بعضها البعض
• توسيع الحاويات بناءً على الحمل
• التعامل مع فشل الحاويات
• طرح التحديثات بدون توقف عن العمل

يوفر Kubernetes نهجًا تعريفيًا (declarative) لإدارة الحاويات. بدلاً من كتابة أوامر تنفيذية (imperative)، فإنك تعلن عن الحالة المرغوبة لتطبيقك، ويعمل Kubernetes باستمرار للحفاظ على تلك الحالة. على سبيل المثال، إذا حددت أنك تريد تشغيل ثلاث نسخ متطابقة (replicas) من تطبيق الويب الخاص بك، فسيقوم Kubernetes تلقائيًا بإنشاء وصيانة ثلاث نسخ بالضبط، وإعادة تشغيل الحاويات الفاشلة أو نقلها إلى عقد (nodes) سليمة حسب الحاجة.

تشمل المفاهيم الأساسية في Kubernetes ما يلي:

• Pods: أصغر الوحدات القابلة للنشر التي يمكن إنشاؤها وإدارتها في Kubernetes. يمثل الـ Pod نسخة واحدة من عملية قيد التشغيل ويمكن أن يحتوي على حاوية واحدة أو أكثر تشترك في موارد التخزين والشبكة.

• Deployments: تجريد عالي المستوى يدير الحالة المرغوبة لـ Pods و ReplicaSets. تتيح الـ Deployments تحديثات تعريفية لـ Pods و ReplicaSets.

• Services: تجريد يحدد مجموعة منطقية من الـ Pods وسياسة للوصول إليها. تتيح الـ Services الوصول عبر الشبكة إلى مجموعة من الـ Pods.

• Nodes: الأجهزة العاملة (worker machines) التي تشغل التطبيقات المعبأة في حاويات. تقوم كل عقدة بتشغيل kubelet، الذي يتواصل مع لوحة التحكم (control plane).

• Control Plane: طبقة تنسيق الحاويات التي تعرض الـ API والواجهات لتعريف ونشر وإدارة دورة حياة الحاويات.

أصبح Kubernetes هو المعيار الفعلي لتنسيق الحاويات، مع اعتماده من قبل 96% من المؤسسات التي تستخدم الحاويات في بيئة الإنتاج¹. إن نظامه البيئي الغني، وحياده تجاه الموردين، ودعم المجتمع القوي يجعله أداة أساسية لنشر التطبيقات الحديثة.

مكونات Kubernetes الأساسية

فهم بنية Kubernetes أمر بالغ الأهمية للنشر الفعال واستكشاف الأخطاء وإصلاحها. تتكون مجموعة (cluster) Kubernetes من جزأين رئيسيين: لوحة التحكم (control plane) وعقد العمل (worker nodes).

مكونات لوحة التحكم (Control Plane)

تتخذ لوحة التحكم قرارات عالمية بشأن المجموعة وتستجيب لأحداث المجموعة. تشمل مكوناتها:

1. API Server: الواجهة الأمامية للوحة تحكم Kubernetes، حيث يعرض Kubernetes API. تمر جميع الاتصالات بين المكونات عبر خادم الـ API.

2. etcd: مخزن قيم-مفاتيح (key-value store) متسق وعالي التوفر يستخدم كمخزن خلفي لـ Kubernetes لجميع بيانات المجموعة. يقوم بتخزين التكوين والحالة الكاملة للمجموعة.

3. Scheduler: يراقب الـ Pods المنشأة حديثًا والتي ليس لها عقدة معينة ويختار عقدة لتعمل عليها بناءً على متطلبات الموارد والسياسات والقيود الأخرى.

4. Controller Manager: يقوم بتشغيل عمليات التحكم التي تنظم حالة المجموعة. ومن الأمثلة على ذلك Node Controller و Replication Controller و Endpoints Controller.

5. Cloud Controller Manager: يربط مجموعتك بـ API الخاص بمزود الخدمة السحابية، ويفصل المكونات التي تتفاعل مع المنصة السحابية عن تلك التي تتفاعل فقط مع مجموعتك.

مكونات العقدة (Node)

تقوم عقد العمل بتشغيل التطبيقات الفعلية. تقوم كل عقدة بتشغيل:

1. Kubelet: وكيل يضمن تشغيل الحاويات في الـ Pod. يأخذ مجموعة من PodSpecs ويضمن أن الحاويات الموصوفة تعمل وسليمة.

2. Kube-proxy: يحافظ على قواعد الشبكة على العقد، مما يتيح الاتصال الشبكي بالـ Pods الخاصة بك من جلسات الشبكة داخل أو خارج مجموعتك.

3. Container Runtime: البرنامج المسؤول عن تشغيل الحاويات (مثل Docker، containerd، CRI-O).

إليك تمثيل مرئي لبنية Kubernetes:

+-------------------------------------------------+
|                  Control Plane                  |
|  +-----------+   +------+   +----------------+  |
|  | API       |   | etcd |   | Controller     |  |
|  | Server    |   |      |   | Manager        |  |
|  +-----------+   +------+   +----------------+  |
|         \           |           /               |
|          \          |          /                |
|           \         |         /                 |
|            \        |        /                  |
|             \       |       /                   |
|              \      |      /                    |
|               \     |     /                     |
|                \    |    /                      |
|                 \   |   /                       |
|                  \  |  /                        |
|                   \ | /                         |
|                    \|/                          |
|                  +------+                       |
|                  | Scheduler |                  |
|                  +------+                       |
|                         \                       |
+--------------------------|----------------------+
                           |
                           v
+-------------------------------------------------+
|                  Worker Nodes                   |
|  +-------------------------------------------+  |
|  | Node                                     |  |
|  |  +-------------+   +------------------+  |  |
|  |  | Kubelet     |   | Kube-proxy       |  |  |
|  |  +-------------+   +------------------+  |  |
|  |  +------------------------------------+  |  |
|  |  | Container Runtime (e.g., containerd)|  |  |
|  |  +------------------------------------+  |  |
|  +-------------------------------------------+  |
|  +-------------------------------------------+  |
|  | Node                                     |  |
|  |  +-------------+   +------------------+  |  |
|  |  | Kubelet     |   | Kube-proxy       |  |  |
|  |  +-------------+   +------------------+  |  |
|  |  +------------------------------------+  |  |
|  |  | Container Runtime (e.g., containerd)|  |  |
|  |  +------------------------------------+  |  |
|  +-------------------------------------------+  |
+-------------------------------------------------+

الإدارة التعريفية مقابل الإدارة التنفيذية

يستخدم Kubernetes نموذجًا تعريفيًا (declarative) حيث تصف الحالة المرغوبة في ملفات تكوين YAML أو JSON. على سبيل المثال، إليك تكوين Deployment بسيط:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.10
        ports:
        - containerPort: 80

يعلن هذا التكوين أننا نريد تشغيل ثلاث نسخ متطابقة من حاوية nginx في جميع الأوقات. ستعمل لوحة تحكم Kubernetes باستمرار للحفاظ على هذه الحالة المرغوبة.

شبكات Kubernetes

تتيح شبكات Kubernetes الاتصال بين الحاويات، والـ Pods، والـ Services، والعملاء الخارجيين. فهم نموذج الشبكات الخاص بها أمر بالغ الأهمية لبناء وتشغيل التطبيقات الموزعة.

مفاهيم الشبكات الأساسية

1. Pod Networking: يحصل كل Pod على عنوان IP خاص به. تشترك الحاويات داخل الـ Pod في نفس مساحة اسم الشبكة (network namespace) ويمكنها التواصل عبر localhost.

2. Services: الـ Service هو تجريد يحدد مجموعة منطقية من الـ Pods وسياسة للوصول إليها. تتيح الـ Services فك الارتباط (loose coupling) بين الـ Pods التابعة.

3. Ingress: يدير الوصول الخارجي إلى الخدمات في المجموعة، عادةً عبر HTTP/HTTPS. يوفر Ingress موازنة الحمل، وإنهاء SSL، والاستضافة الافتراضية القائمة على الاسم.

4. Network Policies: تحدد كيفية السماح لمجموعات من الـ Pods بالتواصل مع بعضها البعض ومع نقاط نهاية الشبكة الأخرى.

أنواع الـ Services

يوفر Kubernetes عدة أنواع من الـ Services:

1. ClusterIP: يعرض الـ Service على عنوان IP داخلي للمجموعة. هذا هو النوع الافتراضي (ServiceType).

2. NodePort: يعرض الـ Service على عنوان IP الخاص بكل عقدة (Node) عند منفذ ثابت.

3. LoadBalancer: يعرض الـ Service خارجيًا باستخدام موازن حمل خاص بمزود الخدمة السحابية.

4. ExternalName: يربط الـ Service بمحتويات حقل externalName عن طريق إرجاع سجل CNAME.

إليك مثال على تعريف Service:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer

متحكمات Ingress

متحكم Ingress مسؤول عن تنفيذ الـ Ingress، عادةً باستخدام موازن حمل. تشمل الخيارات الشائعة ما يلي:

• Nginx Ingress Controller
• Traefik
• HAProxy
• AWS ALB Ingress Controller

مثال على مورد Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.Kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              number: 80

سياسات الشبكة (Network Policies)

تسمح لك سياسات الشبكة بالتحكم في تدفق حركة المرور على مستوى عنوان IP أو المنفذ (port). على سبيل المثال، لتقييد حركة المرور بين خدمات الواجهة الأمامية (frontend) والخدمات الخلفية (backend):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379

أفضل الممارسات الأمنية في Kubernetes

يتطلب تأمين عنقود (cluster) Kubernetes نهج الدفاع المتعمق. إليك الممارسات الأمنية الرئيسية التي يجب على كل مسؤول عنقود تنفيذها:

1. التحكم في الوصول القائم على الأدوار (RBAC)

ينظم RBAC الوصول إلى موارد Kubernetes بناءً على الأدوار المعينة للمستخدمين. اتبع دائمًا مبدأ "الحد الأدنى من الصلاحيات".

مثال على Role و RoleBinding:

# Role definition
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

# Role binding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

2. سياقات أمان الـ Pod

حدد سياقات الأمان لتقييد قدرات وصلاحيات الحاويات (containers):

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true

3. سياسات الشبكة (Network Policies)

قم بتنفيذ تقسيم الشبكة باستخدام سياسات الشبكة للتحكم في حركة المرور بين الـ pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

4. أمان الصور (Image Security)

• استخدم سجلات حاويات (registries) موثوقة
• افحص الصور بحثًا عن الثغرات الأمنية
• استخدم أسرار سحب الصور (image pull secrets) للسجلات الخاصة
• قم بتنفيذ توقيع الصور والتحقق منها

5. إدارة الأسرار (Secrets Management)

لا تقم أبدًا بتخزين البيانات الحساسة في صور الحاويات أو ملفات التكوين. استخدم أسرار (Secrets) Kubernetes:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded "admin"
  password: cGFzc3dvcmQ=  # base64 encoded "password"

6. التحديثات الدورية والترقيع (Patching)

• حافظ على تحديث مكونات Kubernetes
• قم بترقيع أنظمة تشغيل العقد العاملة (worker nodes) بانتظام
• راقب الثغرات الأمنية (CVEs) التي تؤثر على مكونات العنقود الخاص بك

Kubernetes مقابل البدائل: Docker Swarm و Nomad

بينما يهيمن Kubernetes على مشهد تنسيق الحاويات، إلا أنه ليس الخيار الوحيد. لنقارن بين Kubernetes و Docker Swarm و HashiCorp Nomad.

Kubernetes

نقاط القوة:

• مجموعة ميزات غنية لعمليات النشر المعقدة
• نظام بيئي واسع ودعم مجتمعي كبير
• ناضج ومُختبر في بيئات الإنتاج
• دعم قوي للتطبيقات التي تتطلب حالة (stateful)
• خيارات متقدمة للشبكات والتخزين

نقاط الضعف:

• منحنى تعلم أكثر حدة
• تعقيد تشغيلي أعلى
• يستهلك موارد أكثر

الأفضل لـ: عمليات النشر واسعة النطاق والمعقدة التي تتطلب ميزات متقدمة وتوافرًا عاليًا.

Docker Swarm

نقاط القوة:

• سهل الإعداد والاستخدام
• تكامل وثيق مع نظام Docker البيئي
• استهلاك أقل للموارد
• بنية مألوفة لمستخدمي Docker

نقاط الضعف:

• قابلية توسع محدودة مقارنة بـ Kubernetes
• ميزات أقل لعمليات النشر المعقدة
• تطوير أقل نشاطًا منذ تحول Docker نحو Kubernetes

الأفضل لـ: عمليات النشر الصغيرة والمتوسطة حيث تُعطى الأولوية للبساطة على الميزات المتقدمة.

HashiCorp Nomad

نقاط القوة:

• بنية خفيفة وبسيطة
• يدعم أعباء العمل غير المعتمدة على الحاويات
• جدولة مرنة
• سهل التشغيل والصيانة

نقاط الضعف:

• نظام بيئي ومجتمع أصغر
• ميزات مدمجة أقل من Kubernetes
• أقل نضجًا للخدمات المصغرة (microservices) المعقدة

الأفضل لـ: أعباء العمل المختلطة (حاويات وغير حاويات) في البيئات الأصغر.

مقارنة الميزات

الميزة	Kubernetes	Docker Swarm	Nomad
اكتشاف الخدمات (Service Discovery)	نعم	نعم	نعم
موازنة الحمل (Load Balancing)	نعم	نعم	نعم
التوسع التلقائي (Auto-scaling)	نعم	محدود	نعم
التحديثات المتتالية (Rolling Updates)	نعم	نعم	نعم
الشفاء الذاتي (Self-healing)	نعم	نعم	نعم
تنسيق التخزين (Storage Orchestration)	نعم	محدود	نعم
إدارة الأسرار (Secret Management)	نعم	نعم	نعم
دعم السحابة المتعددة	ممتاز	جيد	جيد
منحنى التعلم	حاد	سهل	متوسط
دعم المجتمع	ممتاز	جيد	جيد
الجاهزية للإنتاج	ممتاز	جيد	جيد

دروس تطبيقية في Kubernetes: نشر تطبيق على AWS EKS

سيرشدك هذا البرنامج التعليمي خطوة بخطوة خلال نشر تطبيق عينة على Amazon Elastic Kubernetes Service (EKS).

المتطلبات الأساسية

1. حساب AWS مع الأذونات المناسبة
2. تثبيت وتكوين AWS CLI
3. تثبيت eksctl
4. تثبيت kubectl
5. تثبيت Docker

الخطوة 1: إنشاء عنقود EKS

# Create cluster configuration file (cluster.yaml)
cat <<EOF > cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: nerdlevel-cluster
  region: us-west-2
  version: "1.27"
managedNodeGroups:
  - name: ng-1
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 1
    maxSize: 3
EOF

# Create the cluster
eksctl create cluster -f cluster.yaml

سيستغرق هذا من 10 إلى 15 دقيقة للاكتمال. تحقق من العنقود:

kubectl get nodes

الخطوة 2: نشر تطبيق عينة

قم بإنشاء deployment و service:

# app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nerdlevel-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nerdlevel-app
  template:
    metadata:
      labels:
        app: nerdlevel-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 2
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: nerdlevel-service
spec:
  selector:
    app: nerdlevel-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

قم بتطبيق التكوين:

kubectl apply -f app-deployment.yaml

الخطوة 3: التحقق من النشر

تحقق من حالة النشر الخاص بك:

kubectl get deployments
kubectl get pods
kubectl get services

احصل على عنوان IP الخارجي لـ LoadBalancer الخاص بك:

kubectl get svc nerdlevel-service -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

افتح عنوان URL المقدم في متصفحك لرؤية صفحة ترحيب NGINX.

الخطوة 4: إعداد التوسع التلقائي الأفقي للـ Pod (HPA)

قم بإنشاء HPA للنشر الخاص بك:

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nerdlevel-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nerdlevel-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

قم بتطبيق HPA:

kubectl apply -f hpa.yaml

الخطوة 5: التنظيف

عند الانتهاء، قم بحذف العنقود لتجنب الرسوم غير الضرورية:

eksctl delete cluster --name nerdlevel-cluster --region us-west-2

مفاهيم متقدمة في Kubernetes

التوسع التلقائي الأفقي للـ Pod (HPA)

يقوم HPA تلقائيًا بتوسيع عدد الـ Pods في النشر بناءً على استخدام وحدة المعالجة المركزية (CPU) الملاحظ أو مقاييس مخصصة أخرى. تضمن البرنامج التعليمي السابق مثالاً على HPA.

StatefulSets

تُستخدم StatefulSets للتطبيقات التي تتطلب حالة (stateful) وتحتاج إلى معرفات شبكة مستقرة وتخزين دائم. مثال:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "gp2"
      resources:
        requests:
          storage: 1Gi

DaemonSets

تضمن DaemonSets أن جميع (أو بعض) العقد تقوم بتشغيل نسخة من الـ Pod. تشمل حالات الاستخدام الشائعة جمع السجلات ومراقبة العقد.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
      - key: node-role.Kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluent/fluentd-Kubernetes-daemonset:v1.16-debian-elasticsearch8-1
        env:
          - name: FLUENT_ELASTICSEARCH_HOST
            value: "elasticsearch-logging"
          - name: FLUENT_ELASTICSEARCH_PORT
            value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/Docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/Docker/containers

تعريفات الموارد المخصصة (CRDs)

تعمل CRDs على توسيع API الخاص بـ Kubernetes لإنشاء موارد مخصصة. إليك مثال على إنشاء CRD لمورد مخصص:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: websites.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                url:
                  type: string
                content:
                  type: string
  scope: Namespaced
  names:
    plural: websites
    singular: website
    kind: Website
    shortNames:
    - ws

حالات استخدام Kubernetes: تطبيقات العالم الحقيقي

يُستخدم Kubernetes عبر مختلف الصناعات لحل تحديات متنوعة. إليك بعض أمثلة العالم الحقيقي:

1. التجارة الإلكترونية: التعامل مع طفرات حركة المرور

الشركة: بائع تجزئة رئيسي عبر الإنترنت
التحدي: التعامل مع طفرات حركة المرور التي تصل إلى 10 أضعاف خلال مواسم العطلات
الحل: يقوم التوسع التلقائي في Kubernetes بمعالجة طفرات حركة المرور عن طريق إضافة المزيد من مثيلات التطبيق تلقائيًا خلال أوقات الذروة.
النتائج: وقت تشغيل بنسبة 99.99% خلال مواسم الذروة، وتقليل تكاليف البنية التحتية بنسبة 40% خلال أوقات خارج الذروة.

2. الخدمات المالية: بنية الخدمات المصغرة (Microservices)

الشركة: بنك عالمي
التحدي: تحديث الأنظمة القديمة مع الحفاظ على الأمان والامتثال
الحل: يتيح Kubernetes انتقالاً تدريجيًا إلى Microservices مع سياسات شبكة قوية و RBAC.
النتائج: تقليل أوقات النشر من أسابيع إلى ساعات، وتحسين مرونة النظام، وتتبع أفضل للامتثال.

3. الرعاية الصحية: معالجة الصور الطبية

الشركة: مزود صور طبية
التحدي: معالجة الصور الطبية الكبيرة بمتطلبات حوسبة متفاوتة
الحل: يدير Kubernetes العقد (Nodes) المسرعة بواسطة GPU لمعالجة الصور والعقد القياسية للخدمات الأخرى.
النتائج: تقليل وقت المعالجة بنسبة 70%، وتحسين استخدام الموارد، ونتائج أفضل للمرضى من خلال تشخيص أسرع.

4. بث الوسائط: توصيل المحتوى العالمي

الشركة: منصة بث فيديو
التحدي: تقديم المحتوى عالميًا بزمن وصول (Latency) منخفض
الحل: مجموعات (Clusters) Kubernetes منتشرة في مناطق متعددة مع توجيه ذكي لحركة المرور.
النتائج: تقليل زمن الوصول بنسبة 50%، وتحسين تجربة المشاهد، وتقليل تكاليف النطاق الترددي بنسبة 30%.

5. إنترنت الأشياء (IoT): حوسبة الحافة (Edge Computing)

الشركة: مزود IoT صناعي
التحدي: معالجة البيانات عند "الحافة" مع اتصال محدود
الحل: توزيعات Kubernetes خفيفة الوزن (مثل K3s) منشورة على أجهزة الحافة.
النتائج: تقليل تكاليف نقل البيانات بنسبة 80%، وتحسين قدرات المعالجة في الوقت الفعلي، وموثوقية أفضل في المواقع البعيدة.

قاموس مصطلحات Kubernetes

• Cluster: مجموعة من العقد (Nodes) التي تشغل تطبيقات في حاويات (Containers) وتتم إدارتها بواسطة Kubernetes.
• Container: حزمة خفيفة الوزن ومستقلة وقابلة للتنفيذ تتضمن كل ما يلزم لتشغيل برنامج ما.
• Deployment: كائن في Kubernetes يدير تطبيقًا مكررًا (Replicated application).
• Ingress: كائن في API يدير الوصول الخارجي إلى الخدمات في Cluster.
• Kubelet: وكيل يعمل على كل Node ويضمن تشغيل الحاويات داخل Pod.
• Namespace: Cluster افتراضي داخل Cluster فيزيائي، يُستخدم لتقسيم موارد الـ Cluster بين مستخدمين متعددين.
• Node: جهاز عامل في Kubernetes، قد يكون جهازًا افتراضيًا (VM) أو جهازًا فيزيائيًا.
• Pod: أصغر وحدة يمكن نشرها في Kubernetes، ويمكن أن تحتوي على حاوية واحدة أو أكثر.
• ReplicaSet: يضمن تشغيل عدد محدد من نسخ الـ Pod في أي وقت معين.
• Service: تجريد يحدد مجموعة منطقية من الـ Pods وسياسة للوصول إليها.
• Volume: دليل يحتوي على بيانات، يمكن للحاويات في الـ Pod الوصول إليه.

Footnotes

1. CNCF Annual Survey 2022 ↩