الدليل النهائي للبودات والخدمات في Kubernetes

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

ما هو بود؟

البودز هي أصغر وحدات الحوسبة التي يمكنك إنشاؤها وإدارتها في كوبرنيتيس.

قبل إنشاء بود، دعنا نتحقق من موارد الواجهة البرمجية المتاحة في مجموعة كوبرنيتيس الخاصة بك؛ يمكنك استخدام الأمر kubectl api-resources. يقوم هذا الأمر بسرد موارد واجهة البرمجة التي يدعمها خادم واجهة برمجة التطبيقات الخاص بكوبرنيتيس، بما في ذلك أسماءها المختصرة، ومجموعات الواجهة البرمجية، وما إذا كانت تحت مسمى ما أم لا. يعتبر هذا مفيدًا لفهم قدرات مجموعتك، خاصة عند العمل مع موارد مخصصة أو استكشاف ميزات كوبرنيتيس الجديدة. يكمل الأمر kubectl explain هذا من خلال توفير معلومات مفصلة حول الموارد الفردية.

دعنا نقوم بإنشاء ملف تكوين بود أساسي لبود يعمل بواسطة حاوية Nginx بسيطة.

أنشئ ملفًا بالاسم nginx-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

إليك شرح موجز للمصطلحات المستخدمة:

• apiVersion: v1: يحدد إصدار واجهة البرمجة.
• kind: Pod: يشير إلى أن هذا التكوين هو لبود.
• metadata:name: اسم البود.
• البيانات الوصفية: العلامات: أزواج المفاتيح والقيم التي يمكن استخدامها لتنظيم واختيار الحاوية.
• المواصفات:الحاويات: قائمة الحاويات التي ستعمل في الحاوية.
• المواصفات:الحاويات:الاسم: اسم الحاوية.
• المواصفات:الحاويات:الصورة: صورة الحاوية المراد استخدامها (في هذه الحالة، صورة Nginx الأحدث).
• المواصفات:الحاويات:المنافذ: المنافذ المراد عرضها من الحاوية.

استخدم kubectl لتطبيق ملف التكوين وإنشاء الحاوية:

• kubectl apply -f nginx-pod.yaml

تحقق من حالة الحاوية للتأكد من أنه قد تم إنشاؤها وأنها تعمل:

• kubectl get pods

يجب أن ترى إخراجًا مماثلاً لهذا:

NAME         READY   STATUS    RESTARTS    AGE
nginx-pod    1/1     Running   0           10s

ثم، احذف الحاوية:

• kubectl delete pod nginx-pod

يجب أن يبدو الإخراج مشابهًا للتالي:

kubectl get pod
No resources found in default namespace.

ما هو الخدمة؟

إنشاء خدمة لحاوية Nginx في Kubernetes يسمح لك بعرض تطبيق Nginx وجعله متاحًا داخل أو خارج العقدة. فيما يلي دليل خطوة بخطوة لإنشاء خدمة لحاوية Nginx.

للتأكد من أن لديك حاوية Nginx تعمل، إذا لم يكن لديك بالفعل، قم بإنشاء ملف YAML بالاسم nginx-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

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

• kubectl apply -f nginx-pod.yaml

أنشئ ملف YAML بالاسم nginx-service.yaml لتعريف الخدمة:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
       targetPort: 80
  type: ClusterIP

إليك بعض الأمور التي يجب ملاحظتها:

• selector: محدد العلامة لتطابق حاوية Nginx.
• app: nginx: يجب أن تتطابق هذه العلامة مع العلامة في حاوية Nginx.
• type: ClusterIP: نوع الخدمة. يجعل ClusterIP الخدمة قابلة للوصول فقط داخل العنقود. يمكنك أيضًا استخدام NodePort أو LoadBalancer لتعريض الخدمة خارجيًا.

قم بتطبيق تكوين الخدمة باستخدام kubectl:

• kubectl apply -f nginx-service.yaml
• kubectl get services

NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
nginx-service    ClusterIP   10.96.0.1        <none>        80/TCP    10s

نظرًا لأن الخدمة من نوع ClusterIP، فإنه يمكن الوصول إليها فقط داخل العنقود. للوصول إليها من خارج العنقود، يمكنك تغيير نوع الخدمة إلى NodePort أو LoadBalancer.

لتعريض الخدمة خارجيًا باستخدام NodePort، قم بتعديل ملف nginx-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
       targetPort: 80
      nodePort: 30007  # Specify a node port in the range 30000-32767 (optional)
  type: NodePort

قم بتطبيق تكوين الخدمة المحدث:

• kubectl apply -f nginx-service.yaml

يمكنك الآن الوصول إلى تطبيق Nginx باستخدام عنوان IP للعقدة ومنفذ العقدة (على سبيل المثال، http://<node-ip>:30007).

الحاويات المتعددة في الحاويات

باستخدام حاوية واحدة لكل حاوية يوفر أقصى درجة من التفصيل والانفصال. ومع ذلك، هناك سيناريوهات حيث يكون نشر عدة حاويات، ويُشار إليها في بعض الأحيان بحاويات مركبة، داخل حاوية واحدة مفيدًا. يمكن لهذه الحاويات الثانوية أداء أدوار مختلفة: التعامل مع تسجيل الأحداث أو تعزيز الحاوية الأساسية (مفهوم الجناح الجانبي)، أو العمل كوكيل للأنظمة الخارجية (مفهوم السفير)، أو تعديل البيانات لتناسب تنسيقًا خارجيًا (مفهوم المحول). تكمل هذه الحاويات الثانوية الحاوية الأساسية من خلال أداء المهام التي لا تتعامل معها.

فيما يلي مثال على تكوين حاوية Kubernetes Pod يتضمن حاوية أساسية تعمل كخادم Nginx وحاوية ثانوية تعمل كجناح جانبي للتعامل مع تسجيل الأحداث. تستخدم الحاوية الجانبية حاوية تسجيل بسيطة مثل BusyBox لتوضيح كيف يمكنها تتبع سجلات الوصول إلى Nginx.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-with-logging-sidecar
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx
  - name: log-sidecar
    image: busybox:latest
    command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx
  volumes:
  - name: shared-logs
    emptyDir: {}

ثم ستقوم بما يلي:

• حفظ تكوين YAML في ملف، على سبيل المثال، nginx-with-logging-sidecar.yaml.
• تطبيق التكوين باستخدام kubectl:kubectl apply -f nginx-with-logging-sidecar.yaml.
• التحقق من تشغيل الحاوية: kubectl get pods.
• فحص سجلات الحاوية الجانبية لرؤية سجلات الوصول إلى Nginx: kubectl logs -f <اسم الحاوية> -c log-sidecar.

عن طريق اتباع هذه الخطوات، ستقوم بحذف Pod الحالي وتطبيق التكوين الجديد، مع إعداد Pod يحتوي على حاوية Nginx وحاوية جانبية لتسجيل السجلات. سيضمن ذلك أن التكوين الجديد ساري المفعول ويعمل في عنقود Kubernetes الخاص بك.

توفر Pods المتعددة في Kubernetes العديد من المزايا، مما يتيح نشر وإدارة التطبيقات بشكل أكثر مرونة وكفاءة.

أنماط الـ Pods المتعددة

نمط الـ Sidecar

تتمكن حاويات الـ Sidecar من تعزيز التطبيق الأساسي عن طريق توفير وظائف إضافية مثل تسجيل السجلات أو إدارة التكوين أو الوكيل البروكسي. يساعد هذا النمط في توسيع الوظائف بدون تعديل الحاوية الأساسية. يمكن للحاوية الجانبية التعامل مع تسجيل السجلات عن طريق جمعها وإعادتها من الحاوية الرئيسية للتطبيق.

نمط الـ Ambassador

تعمل حاويات الـ Ambassador كوكيل بروكسي، حيث تدير التواصل بين التطبيق الأساسي والخدمات الخارجية. يمكن أن يبسط هذا النمط التكامل والتكوين. يمكن أن تتولى حاوية الـ Ambassador إنهاء SSL أو وظائف بوابة الواجهة البرمجية (API Gateway).

ينطوي نمط الـ Ambassador على استخدام حاوية جانبية لإدارة التواصل بين التطبيق الأساسي والخدمات الخارجية. يمكن لهذا النمط التعامل مع مهام مثل البروكسي وتوازن الأحمال أو إدارة الاتصالات الآمنة، وبالتالي يتم تجريد التعقيد بعيدًا عن الحاوية الأساسية للتطبيق.

• الحاوية الأساسية للتطبيق: خادم ويب بسيط يقوم بإجراء طلبات HTTP
• حاوية الـ Ambassador: بروكسي Envoy مكون لإدارة طلبات واجهة البرمجة الخارجية

apiVersion: v1
kind: Pod
metadata:
  name: app-with-ambassador
spec:
  containers:
  - name: web-app
    image: python:3.8-slim
    command: ["python", "-m", "http.server", "8000"]
    volumeMounts:
    - name: config-volume
      mountPath: /etc/envoy
  - name: envoy-proxy
    image: envoyproxy/envoy:v1.18.3
    args: ["-c", "/etc/envoy/envoy.yaml"]
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: config-volume
      mountPath: /etc/envoy
  volumes:
  - name: config-volume
    configMap:
      name: envoy-config

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-config
data:
  envoy.yaml: |
    static_resources:
      listeners:
      - name: listener_0
        address:
          socket_address:
            address: 0.0.0.0
            port_value: 8080
        filter_chains:
        - filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stat_prefix: ingress_http
              route_config:
                name: local_route
                virtual_hosts:
                - name: local_service
                  domains: ["*"]
                  routes:
                  - match:
                      prefix: "/"
                    route:
                      cluster: external_service
              http_filters:
              - name: envoy.filters.http.router
      clusters:
      - name: external_service
        connect_timeout: 0.25s
        type: LOGICAL_DNS
        lb_policy: ROUND_ROBIN
        load_assignment:
          cluster_name: external_service
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: api.example.com
                    port_value: 80

يبرز هذا المثال نمط السفير في Kubernetes، حيث يعمل Envoy proxy كوسيط لإدارة الاتصال الخارجي لحاوية التطبيق الأساسية. يساعد هذا النمط في تجريد تعقيدات الاتصال وتعزيز القابلية للتوسع والصيانة.

نمط محول

يمكن لحاويات المحول تعديل أو تحويل البيانات بين التطبيق الأساسي والأنظمة الخارجية، مما يضمن التوافق والتكامل. على سبيل المثال، يمكن لحاوية المحول إعادة تنسيق بيانات السجلات لتلبية متطلبات خدمة تسجيل خارجية.

نمط المحول في Kubernetes يتضمن استخدام حاوية جانبية لتحويل البيانات بين حاوية التطبيق الأساسية والأنظمة الخارجية. يمكن أن يكون ذلك مفيدًا عندما يتطلب التطبيق الأساسي البيانات بتنسيق معين يختلف عن التنسيق الذي يوفره أو يتطلبه الأنظمة الخارجية.

لنفترض أن لديك حاوية تطبيق أساسية تولد سجلات بتنسيق مخصص. تحتاج إلى إرسال هذه السجلات إلى خدمة تسجيل خارجية تتطلب سجلات بتنسيق موحد معين. يمكن استخدام حاوية محول لتحويل بيانات السجل إلى التنسيق المطلوب قبل إرسالها إلى الخدمة الخارجية.

• حاوية التطبيق الأساسية: تطبيق بسيط يقوم بكتابة السجلات بتنسيق مخصص.
• حاوية المحول: حاوية تقوم بقراءة السجلات المخصصة، وتحويلها إلى تنسيق JSON وإرسالها إلى خدمة تسجيل خارجية.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-adapter
spec:
  containers:
  - name: log-writer
    image: busybox
    command: ["sh", "-c", "while true; do echo \"$(date) - Custom log entry\" >> /var/log/custom/app.log; sleep 5; done"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/custom
  - name: log-adapter
    image: busybox
    command: ["sh", "-c", "tail -f /var/log/custom/app.log | while read line; do echo \"$(echo $line | sed 's/ - / - {\"timestamp\": \"/;s/$/\"}/')\" >> /var/log/json/app.json; done"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/custom
    - name: json-logs
      mountPath: /var/log/json
  - name: log-sender
    image: busybox
    command: ["sh", "-c", "while true; do cat /var/log/json/app.json | grep -v '^$' | while read line; do echo \"Sending log to external service: $line\"; done; sleep 10; done"]
    volumeMounts:
    - name: json-logs
      mountPath: /var/log/json
  volumes:
  - name: shared-logs
    emptyDir: {}
  - name: json-logs
    emptyDir: {}

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

الملخص

باختصار، الأشجار:

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

الخدمات:

• توفر عنوان IP واسم DNS ثابتين للوصول إلى الأشجار.
• تمكين التوازن بين الأحمال عبر مجموعة من الأشجار.
• تيسير اكتشاف الخدمة داخل العنقريبة.