הפעלה אוטומטית של צמתי GKE באמצעות DaemonSets

במדריך הזה נסביר איך להתאים אישית את הצמתים של אשכול Google Kubernetes Engine ‏ (GKE) באמצעות DaemonSets. ‫DaemonSet עוזר לוודא שכל הצמתים (או צמתים נבחרים) מריצים עותק של Pod. כשמוסיפים צמתים חדשים לאשכול, הם מריצים גם Pod מ-DaemonSet.

אם הכלים והמערכות שבהם אתם משתמשים כדי לאתחל את האשכולות שונים מהכלים והמערכות שבהם אתם משתמשים כדי להריץ את עומסי העבודה, אתם מגדילים את המאמץ שנדרש לניהול הסביבה. לדוגמה, אם אתם משתמשים בכלי לניהול הגדרות כדי לאתחל את צמתי האשכול, אתם מסתמכים על הליך שמתבצע מחוץ לסביבת זמן הריצה שבה פועלים שאר עומסי העבודה. שימוש ב-DaemonSet מאפשר לכם להשתמש באותם כלים לניהול עומסי העבודה שבהם אתם משתמשים כדי לשנות את צמתי GKE.

מטרת המדריך הזה היא לעזור לאדמינים של מערכות, למהנדסי מערכות או למפעילי תשתית לייעל את ההפעלה של אשכולות Kubernetes.

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את הנושאים הבאים:

במדריך הזה תלמדו איך להשתמש ב-taints וב-tolerations של Kubernetes כדי לוודא שקובץ DaemonSet מגדיר את הצמתים לפני שעומסי העבודה של האפליקציה מתוזמנים בהם.

מטרות

במדריך הזה תלמדו:

  • הקצאת אשכול GKE.
  • כדי למנוע תזמון של עומסי עבודה לפני החלת הגדרת הצומת, צריך להגדיר את מאגר הצמתים כ-tainted.
  • פורסים DaemonSet שמגדיר צמתים ומסיר את ה-taint.
  • מוודאים שצמתי האשכול מוגדרים ושההכתמה הוסרה.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

  1. נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

השלכות אבטחה של DaemonSet עם הרשאות

השימוש בהגדרה securityContext: privileged: true ב-DaemonSet (או בכל Pod) הוא שימושי, אבל יש לו השלכות משמעותיות על האבטחה כי הוא משבית את רוב הגבולות של בידוד הקונטיינרים עבור ה-Pod הזה. חשוב להיות מודעים למגבלות ולסיכוני האבטחה הבאים שקשורים לשימוש ב-Google Workspace:

  • בריחה מקונטיינר או פגיעה במארח: פגיעות באפליקציה או בתמונה של קונטיינר עם הרשאות יכולה להוביל ישירות לגישת root בצומת המארח.
  • הפרה של הרשאות מינימליות: מצב הרשאות מעניק את כל היכולות, כנראה הרבה יותר ממה שנדרש למשימה ספציפית. הגישה הרחבה הזו מגדילה את פוטנציאל הנזק אם המאגר ייפרץ.
  • ערעור היציבות של הצומת: פקודות מקריות או זדוניות עלולות לפעול בתוך הקונטיינר עם הרשאות, למשל ערכים שגויים של sysctl או פקודות כמו rm -rf /host/boot. סוגי הפקודות האלה עלולים לגרום לקריסה או לפגום במערכת ההפעלה של צומת המארח.
  • תנועה לרוחב: פריצה לצומת אחד דרך DaemonSet מורשה מאפשרת לתוקף להשיג דריסת רגל חזקה כדי לתקוף צמתים אחרים, את מישור הבקרה של Kubernetes או מערכות מחוברות.
  • חשיפת נתונים: גישה בלתי מוגבלת למערכת הקבצים של המארח (/) עלולה לחשוף מידע אישי רגיש שמאוחסן בצומת, כולל פרטי כניסה, מפתחות או נתונים ששייכים ל-Pods אחרים אם הם משתמשים בנפחים של hostPath.
  • שטח התקפה מוגדל: מצב הרשאות חושף יותר קריאות מערכת ותכונות של ליבת המארח לניצול פוטנציאלי מתוך הקונטיינר.

כדי להימנע מסיכוני אבטחה, חשוב להכיר את השיטות המומלצות ואת אמצעי ההגנה הבאים:

  • לא להשתמש במצב הרשאות: הגישה הכי מאובטחת היא להימנע לחלוטין מההגדרה privileged: true.
  • שימוש ביכולות של Linux: אם נדרשות הרשאות גבוהות, אפשר להעניק יכולות ספציפיות של Linux כמו NET_ADMIN, SYS_ADMIN, SYS_MODULE בשדה securityContext.capabilities.add במקום הרשאה מלאה. הגישה הזו מבוססת על העיקרון של הרשאות מינימליות, שאנחנו ממליצים עליו במקום לתת הרשאות רחבות.
  • הגבלת ההיקף: מריצים DaemonSets עם הרשאות רק במאגרי צמתים ייעודיים, שאולי הם tainted, כדי לצמצם את ההשפעה הפוטנציאלית אם קונטיינר ייפרץ.
  • אכיפת מדיניות: אפשר להשתמש בכלים כמו Policy Controller או Gatekeeper כדי ליצור מדיניות שמגבילה פריסה של קונטיינרים עם הרשאות, מבצעת ביקורת עליהם או דורשת הצדקה לפריסה שלהם.
  • סריקה ושימוש בתמונות מהימנות: שימוש ב-Binary Authorization ובסריקת תמונות קפדנית עוזר לוודא שרק קובצי אימג' של קונטיינרים שנבדקו ומהימנים מופעלים עם הרשאות מורחבות.
  • מצמצמים את הנתיבים של המארח: כדאי להגדיר רק את הנתיבים הספציפיים של המארח שנדרשים, ולהשתמש ב-readOnly: true כשזה אפשרי. מומלץ להימנע מהרכבה של כל מערכת הקבצים הבסיסית (/).
  • עורכים בדיקות שוטפות: בודקים מעת לעת את כל עומסי העבודה שמופעלים עם ההגדרה privileged: true.

הפעלת הסביבה

בקטע הזה תבצעו את הפעולות הבאות:

  1. מפעילים את ממשקי ה-API של Cloud שנדרשים.
  2. הקצאת חשבון שירות עם הרשאות מוגבלות לצמתים באשכול GKE.
  3. מכינים את אשכול GKE.
  4. נותנים למשתמש הרשאות אדמין באשכול.

הפעלת ממשקי Cloud API

  1. פותחים את Cloud Shell.

    פותחים את Cloud Shell.

  2. בוחרים את הפרויקט Google Cloud :

    gcloud config set project project-id

    מחליפים את project-id במזהה שלGoogle Cloud הפרויקט שיצרתם או בחרתם עבור המדריך הזה.

  3. מפעילים את Kubernetes Engine API:

    gcloud services enable container.googleapis.com

הקצאת חשבון שירות לניהול אשכולות GKE

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

התפקידים שנדרשים לחשבון השירות הם:

  • תפקיד צופה בנתוני המעקב (roles/monitoring.viewer). התפקיד הזה מאפשר גישת קריאה בלבד לנתוני המעקב.
  • התפקיד 'כתיבת מדדים של מעקב' (roles/monitoring.metricWriter). התפקיד הזה מאפשר כתיבת נתוני מעקב.
  • התפקיד 'כתיבה ביומן' (roles/logging.logWriter). התפקיד הזה מעניק הרשאות לכתיבת יומנים.

כדי להקצות חשבון שירות:

  1. ב-Cloud Shell, מאתחלים משתנה סביבה שמאחסן את השם של חשבון השירות:

    GKE_SERVICE_ACCOUNT_NAME=ds-init-tutorial-gke

  2. יוצרים חשבון שירות:

    gcloud iam service-accounts create "$GKE_SERVICE_ACCOUNT_NAME" \
  --display-name="$GKE_SERVICE_ACCOUNT_NAME"

  3. מאתחלים משתנה סביבה שמאחסן את השם של חשבון האימייל של חשבון השירות:

    GKE_SERVICE_ACCOUNT_EMAIL="$(gcloud iam service-accounts list \
    --format='value(email)' \
    --filter=displayName:"$GKE_SERVICE_ACCOUNT_NAME")"

  4. מקשרים את התפקידים בניהול הזהויות והרשאות הגישה (IAM) לחשבון השירות:

    gcloud projects add-iam-policy-binding \
    "$(gcloud config get-value project 2> /dev/null)" \
    --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
    --role roles/monitoring.viewer
gcloud projects add-iam-policy-binding \
    "$(gcloud config get-value project 2> /dev/null)" \
    --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
    --role roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding \
    "$(gcloud config get-value project 2> /dev/null)" \
    --member serviceAccount:"$GKE_SERVICE_ACCOUNT_EMAIL" \
    --role roles/logging.logWriter

הכנת אשכול GKE

בקטע הזה מפעילים את אשכול GKE, מעניקים הרשאות ומסיימים את הגדרת האשכול.

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

  • ב-Cloud Shell, יוצרים ומפעילים אשכול GKE אזורי:

    gcloud container clusters create ds-init-tutorial \
    --enable-ip-alias \
    --machine-type=n1-standard-2 \
    --metadata disable-legacy-endpoints=true \
    --node-labels=app=default-init \
    --node-locations us-central1-a,us-central1-b,us-central1-c \
    --no-enable-basic-auth \
    --no-issue-client-certificate \
    --num-nodes=1 \
    --location us-central1 \
    --service-account="$GKE_SERVICE_ACCOUNT_EMAIL"

החלת הגדרות של צמתים באמצעות DaemonSet

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

  1. להקצות Pods לצמתים עם דחייה (taint) באמצעות טולרנטיות לדחייה (taint).
  2. מריץ קונטיינר init עם הרשאות מיוחדות שמחיל קודם את הגדרת הצומת באמצעות sysctl, ואז מסיר את הכתם מהצומת באמצעות kubectl. הסרת ה-taint מאפשרת לתזמן את הצומת לעומסי עבודה.
  3. מתזמן ומריץ קונטיינר להשהיה שנשאר במצב סרק ולא צורך משאבים, כדי למנוע מ-DaemonSet לתזמן מחדש את ה-Pod שמשמש להגדרה.

במדריך הזה מוגדר פרמטר הליבה vm.max_map_count=262144 כדוגמה לתצורה.

  1. החלת דחייה (taint) על מאגר הצמתים שמוגדר כברירת מחדל:

    gcloud container node-pools update default-pool \
  --cluster=ds-init-tutorial \
  --node-taints=node.config.status/stage=configuring:NoSchedule \
  --region=us-central1

    עם ה-taint הזה, אפשר לתזמן במאגר הצמתים הזה רק Pods שסובלים אותו, כמו ה-Pod של DaemonSet.

  2. מוודאים שההכתמה הוחלה:

    kubectl describe nodes -l cloud.google.com/gke-nodepool=default-pool | grep Taints

    סטטוס הצומת צריך להיות node.config.status/stage=configuring:NoSchedule.

  3. שומרים את קובץ המניפסט הבא בשם auto-untaint-daemonset.yaml:

    # WARNING: This DaemonSet runs as privileged, which has significant
# security implications. Only use this on clusters where you have
# strict controls over what is deployed.
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: node-config-sa
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-patcher-role
rules:
- apiGroups: [""]
  resources: ["nodes"]
  # Permissions needed to read and remove a taint from the node.
  verbs: ["get", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-config-binding
subjects:
- kind: ServiceAccount
  name: node-config-sa
  namespace: default
roleRef:
  kind: ClusterRole
  name: node-patcher-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: auto-untaint-daemonset
  labels:
    app: auto-untaint-configurator
spec:
  selector:
    matchLabels:
      app: auto-untaint-configurator
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: auto-untaint-configurator
    spec:
      serviceAccountName: node-config-sa
      hostPID: true
      # Toleration now matches the taint on your node.
      tolerations:
      - key: "node.config.status/stage"
        operator: "Equal"
        value: "configuring"
        effect: "NoSchedule"
      volumes:
      - name: host-root-fs
        hostPath:
          path: /
      initContainers:
      - name: configure-and-untaint
        image: ubuntu:22.04 # Using a standard container image.
        securityContext:
          privileged: true # Required for chroot and sysctl.
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        volumeMounts:
        - name: host-root-fs
          mountPath: /host
        command: ["/bin/bash", "-c"]
        args:
        - |
          # Using explicit error checking for each critical command.

          # Define the configuration and taint details.
          SYSCTL_PARAM="vm.max_map_count"
          SYSCTL_VALUE="262144"
          TAINT_KEY="node.config.status/stage"

          echo "Running configuration on node: ${NODE_NAME}"

          # 1. APPLY CONFIGURATION
          echo "--> Applying ${SYSCTL_PARAM}=${SYSCTL_VALUE}..."
          if ! chroot /host sysctl -w "${SYSCTL_PARAM}=${SYSCTL_VALUE}"; then
            echo "ERROR: Failed to apply sysctl parameter." >&2
            exit 1
          fi
          echo "--> Configuration applied successfully."

          # 2. UNTAINT THE NODE
          # This command removes the taint from the node this Pod is running on.
          echo "--> Untainting node ${NODE_NAME} by removing taint ${TAINT_KEY}..."
          if ! /host/home/kubernetes/bin/kubectl taint node "${NODE_NAME}" "${TAINT_KEY}:NoSchedule-"; then
            echo "ERROR: Failed to untaint the node." >&2
            exit 1
          fi
          echo "--> Node has been untainted and is now schedulable."
      # The main container is minimal; it just keeps the Pod running.
      containers:
      - name: pause-container
        image: registry.k8s.io/pause:3.9

    קובץ המניפסט הזה יוצר ServiceAccount,‏ ClusterRole ו-ClusterRoleBinding כדי להעניק ל-DaemonSet הרשאה להסיר taints מצמתים. ‫DaemonSet פורס Pod לכל צומת שסובל את configuring:NoSchedule ה-taint. ה-Pod הזה מריץ קונטיינר init עם הרשאות שחל על הגדרת sysctl (vm.max_map_count=262144) ומסיר את ה-taint של הצומת, מה שהופך את הצומת לניתן לתזמון. לאחר מכן מופעל קונטיינר להשהיה כדי להשאיר את ה-Pod פעיל.

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

  4. החלת המניפסט:

    kubectl apply -f auto-untaint-daemonset.yaml

  5. מוודאים שפודים של DaemonSet נוצרו וממתינים עד שהם מגיעים למצב Running:

    kubectl get pods -l app=auto-untaint-configurator -o wide

    המצב Running מציין שהקונטיינר של init הושלם בהצלחה. חשוב לרשום את שם ה-Pod כדי שתוכלו להשתמש בו לאימות האתחול בקטע הבא.

אימות של תהליך האתחול

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

  1. כדי לראות את הפלט של אחד מה-Pods, בודקים את היומנים של קונטיינר האתחול:

    kubectl logs POD_NAME -c configure-and-untaint

    מחליפים את POD_NAME בשם ה-Pod.

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

  2. מוודאים שההכתמה הוסרה:

    kubectl describe nodes -l cloud.google.com/gke-nodepool=default-pool | grep Taints

    סטטוס הצומת צריך להיות Taints: <none>, או להציג כתמים עם המפתח node.config.status/stage.

הסרת המשאבים

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

פינוי מקום בפרויקט

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

  1. ב-Cloud Shell, מוחקים את אשכול GKE:

    gcloud container clusters delete ds-init-tutorial --quiet --region us-central1

  2. מוחקים את חשבון השירות:

    gcloud iam service-accounts delete "$GKE_SERVICE_ACCOUNT_EMAIL" --quiet

מחיקת הפרויקט

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך.

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

המאמרים הבאים