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

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

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

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

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

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

מטרות

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

  • הקצאת אשכול GKE.
  • לסמן מאגר צמתים כפגום כדי למנוע תזמון של עומסי עבודה לפני החלת הגדרת הצומת.
  • פריסת 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 או מערכות מחוברות.
  • חשיפת נתונים: גישה בלתי מוגבלת למערכת הקבצים של המארח (/) יכולה לחשוף מידע אישי רגיש שמאוחסן בצומת, כולל פרטי כניסה, מפתחות או נתונים ששייכים לפודים אחרים אם הם משתמשים בנפחי 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 APIs

  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 משתמשים בחשבון השירות הזה במקום בחשבון השירות שמוגדר כברירת מחדל. מומלץ לתת לחשבון השירות רק את התפקידים והרשאות הגישה שנדרשים כדי להריץ את האפליקציה.

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

  • התפקיד Monitoring Viewer (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. מתוזמנים פודים בצמתים מוכתמים באמצעות סבילות לכתם.
  2. מריץ קונטיינר init עם הרשאות מיוחדות שמחיל קודם את הגדרת הצומת באמצעות sysctl, ואז מסיר את ה-taint מהצומת באמצעות kubectl. הסרת הכתם מאפשרת לתזמן את הצומת לעומסי עבודה.
  3. הכלי מתזמן ומריץ קונטיינר להשהיה שנשאר במצב סרק ולא צורך משאבים, כדי למנוע את התזמון מחדש של ה-Pod שמשמש להגדרה על ידי DaemonSet.

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

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

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

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

  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 לכל צומת שסובל את ה-taint‏ configuring:NoSchedule. ה-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. בודקים את יומני הקונטיינר של ה-init של אחד מה-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>, או להציג taints עם המפתח 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.

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