מדריך הסופי ל-Pods ולשירותים ב-Kubernetes

מדריכים
Kubernetes

Kubernetes הוא פלטפורמת ניהול קונטיינרים עוצמתית, אך כדי לנצל את הפוטנציאל המלא שלה, חשוב להבין את המרכיבים המרכזיים שלה, כאשר פודים ושירותים משחקים תפקידים בסיסיים. במאמר זה, נצלול לתוך מה הם וכיצד הם עובדים יחד כדי לחשוף ולנהל גישה ליישומים שרצים בתוך אשכול Kubernetes.

מהו פוד?

פודים הם היחידות הקטנות ביותר שניתן לפרוס במחשוב שאתם יכולים ליצור ולנהל בKubernetes.

לפני שניצור פוד, נבדוק את משאבי ה-API הזמינים באשכול Kubernetes שלכם; אתם יכולים להשתמש בפקודה kubectl api-resources. פקודה זו מונה את משאבי ה-API הנתמכים על ידי שרת ה-API של Kubernetes, כולל שמותיהם הקצרים, קבוצות ה-API, ואם הם ממוספרים או לא. זה שימושי להבנת היכולות של האשכול שלכם, במיוחד כשעובדים עם משאבים מותאמים אישית או חוקרים תכונות חדשות של Kubernetes. פקודת kubectl explain משלימה זאת על ידי מתן מידע מפורט על משאבים בודדים.

בואו ניצור קובץ קונפיגורציה בסיסי לפוד שרץ קונטיינר Nginx פשוט.

צור קובץ בשם nginx-pod.yaml:

YAML

  

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

הנה הסבר קצר על המונחים שבהם השתמשנו:

  • apiVersion: v1: מציין את גרסת ה-API.
  • kind: Pod: מציין שהקונפיגורציה הזו היא לפוד.
  • metadata:name: שם הפוד.
  • מטה-נתונים: תווי-מפתח: זוגות של ערכים שיכולים לשמש לארגון ובחירת ה-Pod.
  • מפרט:מיכלים: רשימת מיכלים שירוצו ב-Pod.
  • מפרט:מיכלים:שם: שם המיכל.
  • מפרט:מיכלים:תמונה: התמונת מיכל לשימוש (במקרה זה, תמונת Nginx האחרונה).
  • מפרט:מיכלים:יציאות: היציאות לחשיפה מהמיכל.

השתמש ב־kubectl כדי ליישם את קובץ התצורה וליצור את ה-Pod:

  • kubectl apply -f nginx-pod.yaml

בדוק את מצב ה-Pod כדי לוודא שנוצר ורץ:

  • kubectl get pods

עליך לראות פלט דומה לזה:

Shell

  

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

בשלב הבא, מחק את ה-Pod:

  • kubectl delete pod nginx-pod

הפלט צריך להיראות דומה למה שלמעלה:

Shell

  

kubectl get pod
No resources found in default namespace.

מהו שירות?

יצירת שירות עבור פוד Nginx ב-Kubernetes מאפשרת לך לחשוף את היישום Nginx ולהפוך אותו לנגיש בתוך האשפה או מחוץ לה. הנה מדריך שלב אחרי שלב ליצירת שירות עבור פוד Nginx.

כדי לוודא שיש לך פוד Nginx רץ, אם עדיין לא יש לך אחד, צור קובץ YAML בשם nginx-pod.yaml:

YAML

  

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

יישם את קובץ התצורה של ה-Pod:

  • kubectl apply -f nginx-pod.yaml

צור קובץ YAML בשם nginx-service.yaml כדי להגדיר את ה-Service:

YAML

  

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

הנה מספר דברים לשימוש:

  • selector: בורר תווית כדי להתאים ל-Pod של Nginx.
  • app: nginx: זה צריך להתאים לתווית ב-Pod של Nginx.
  • type: ClusterIP: סוג ה-Service. ClusterIP מאפשר גישה ל-Service רק בתוך ה-Cluster. ניתן גם להשתמש ב-NodePort או ב-LoadBalancer כדי לחשוף את ה-Service חיצונית.

החל את תצורת ה-Service באמצעות kubectl:

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

  

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

מאחר וה-Service הוא מסוג ClusterIP, הוא נגיש רק בתוך ה-Cluster. כדי לגשת אליו מחוץ ל-Cluster, ניתן לשנות את סוג ה-Service ל-NodePort או ל-LoadBalancer.

כדי לחשוף את ה-Service חיצונית באמצעות NodePort, שנה את קובץ ה-nginx-service.yaml:

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

החל את תצורת ה-Service המעודכנת:

  • kubectl apply -f nginx-service.yaml

כעת תוכל לגשת ליישום Nginx באמצעות כתובת ה-IP של הצומת והפורט של הצומת (לדוגמה, http://<node-ip>:30007).

קרונות מרובים

שימוש בצפין יחיד לכל קופסא מספק את הקטנות וההפרדה המקסימליים. עם זאת, ישנם תרחישים בהם פריסת מספר קופסאות, המתייחסים לפעמים כקופסאות מרוכבות, בתוך קופסא יחידה היא מועילה. קופסאות המשניות אלה יכולות לבצע תפקידים שונים: עיבוד לוגים או שיפור הקופסא הראשית (קונספט sidecar), פעולה כפרוקסי למערכות חיצוניות (קונספט ambassador), או שינוי נתונים כך שיתאימו לפורמט חיצוני (קונספט adapter). קופסאות המשניות אלו משלימות את הקופסא הראשית על ידי ביצוע משימות שאינה עוסקת בהן.

להלן דוגמה לתצורת Pod של Kubernetes שכוללת קופסא ראשית הפועלת עם שרת Nginx וקופסא משנית הפועלת כ sidecar לטיפול בלוגים. הקופסא הצדדית משתמשת בקופסא פשוטה ללוגים כמו BusyBox כדי להדגים כיצד ניתן למעקב אחרי לוגי גישה של Nginx.

YAML

  

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. 
  • וודא כי ה-Pod פועל: kubectl get pods. 
  • בדוק את הלוגים של הקופסא הצדדית כדי לראות את לוגי הגישה של Nginx: kubectl logs -f <שם-ה-pod> -c log-sidecar.

על ידי מעקב אחר מדריכים אלה, תוכל למחוק את ה-Pod הקיים ולהחיל את התצורה החדשה, בהגדרת Pod עם תופס Nginx ותופס sidecar ללוגים. זה יבטיח כי התצורה החדשה תהיה פעילה ופועלת באשכול Kubernetes שלך.

קיומ פודים רבי תופסים ב-Kubernetes מציע מספר יתרונות, אשר מאפשרים פריסת אפליקציות גמישה ויעילה יותר, וניהול.

תבניות פודים רבי תופסים

תבנית תופס Sidecar

תופסי sidecar יכולים לשפר את האפליקציה הראשית על ידי הענקת פונקציות עזר כגון לוגים, ניהול הגדרות, או proxying. תבנית זו עוזרת להרחיב את הפונקציונאליות ללא שינוי בתופס הראשי. תופס sidecar יכול לטפל בלוגים על ידי איסוף והעברת לוגים מתופס האפליקציה הראשית.

תבנית השגריר

תופסי שגריר פועלים כ-proxy, ניהול תקשורת בין האפליקציה הראשית ושירותים חיצוניים. זה יכול לפשט אינטגרציה והגדרה. תופס שגריר עשוי לטפל בסיום SSL או בפונקציות שער API.

תבנית השגריר מעורבת בשימוש בתופס sidecar לניהול תקשורת בין האפליקציה הראשית ושירותים חיצוניים. תבנית זו יכולה לטפל במשימות כגון proxying, איזון משקלים, או ניהול חיבורים מאובטחים, ולכן להפשיל את המורכבות מתופס האפליקציה הראשית.

  • תופס אפליקציה ראשית: שרת אינטרנט פשוט שבוצעים בו בקשות HTTP
  • תופס שגריר: Envoy proxy מוגדר לניהול בקשות ל-API חיצוני
YAML

  

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

דוגמה זו מדגימה את תבנית ה-Ambassador ב־Kubernetes, שבה ה־Envoy proxy משמש כאמצעי לניהול תקשורת חיצונית עבור תכולת היישום הראשית. תבנית זו עוזרת להפשיר פשיטות תקשורת ומשפרת את הרמת ההפרדה והשמירה על היישום.

תבנית המתאימים

תכלית המתאימים היא לשנות או להמיר נתונים בין תכולת היישום הראשית ובין מערכות חיצוניות, ובכך לוודא תאימות ואינטגרציה. לדוגמה, מתאים יכול לשנות את נתוני הלוגים לפורמט שמתאים לדרישות שירות הלוגים החיצוני.

תבנית המתאימים ב־Kubernetes כוללת שימוש ב־sidecar container כדי להמיר נתונים בין תכולת היישום הראשית לבין מערכות חיצוניות. זה עשוי להיות שימושי כאשר היישום הראשי דורש נתונים בפורמט ספציפי שונה מהפורמט שמסופק או דרוש על ידי מערכות חיצוניות.

נניח כי יש לך תכולת יישום ראשית שיוצרת לוגים בפורמט מותאם אישית. עליך לשלוח את הלוגים הללו לשירות הלוגים החיצוני שדורש לוגים בפורמט סטנדרטי מסוים. ניתן להשתמש במתאם container כדי להמיר את נתוני הלוג לפורמט הנדרש לפני שליחתם לשירות החיצוני.

  • תכולת יישום ראשית: יישום פשוט שכותב לוגים בפורמט מותאם אישית.
  • מתאם Container: Container שקורא את הלוגים המותאמים, משנה אותם לפורמט JSON ושולח אותם לשירות הלוגים החיצוני.
YAML

  

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: {}

דוגמה זו מדגימה את תבנית המתאם ב־Kubernetes, שבה תיק המתאם ממיר נתונים מתוך תוך תוכן היישום הראשי לתבנית הנדרשת לפני ששולח אותם למערכת חיצונית. תבנית זו עוזרת לאינטגרציה של אפליקציות עם שירותים חיצוניים על ידי טיפול בהמרות פורמט הנתונים בתוך תוך תוכן הצד.

סיכום

רקעזה, ק־pods:

  • הם היחידות הקטנות ביותר שניתן להפעיל ב־Kubernetes.
  • מייצגים מופע יחיד של תהליך רץ.
  • יכולים להכיל תוך תוך תוכן.

שירותים:

  • מספקים כתובת IP יציבה ושם DNS לגישה אל pods.
  • מאפשרים איזון עומס באורח מאוזן בין סט של pods.
  • מקלים על גילוי שירות בתוך האשף.

Source:
https://dzone.com/articles/the-ultimate-guide-to-kubernetes-pods-and-services