סיבוב של כתובת ה-IP של מישור הבקרה

בדף הזה מוסבר איך לבצע רוטציה של כתובות IP במישור הבקרה באשכולות של Google Kubernetes Engine ‏ (GKE).

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

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

מידע על רוטציית פרטי כניסה ב-GKE

לרשות האישורים (CA) של שורש האשכול יש משך חיים מוגבל. כשאישור רשות האישורים פג, כל פרטי הכניסה שנחתמו על ידי רשות האישורים כבר לא תקפים, כולל אישור הלקוח של האשכול (משדה ה-API‏ MasterAuth), המפתח והאישור של שרת ה-API ואישורי הלקוח kubelet. משך החיים של פרטי הכניסה של האשכול תלוי בתאריך שבו יצרתם את האשכול או בתאריך שבו ביצעתם לאחרונה רוטציה של פרטי הכניסה.

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

  • רוטציית פרטי כניסה:

    • הפונקציה מחליפה את כתובת ה-IP שרמת הבקרה משתמשת בה עבור שרת Kubernetes API.
    • מבצעים רוטציה לרשות האישורים (CA) הבסיסית של האשכול.
    • החלפת מפתחות של חשבונות שירות ב-Kubernetes, שמשמשים לחתימה ולאימות של פרטי הכניסה של חשבונות שירות.
    • מסובבת את שכבת הצבירה CA.

  • רוטציה של כתובות IP:

    • הפונקציה מחליפה את כתובת ה-IP שרמת הבקרה משתמשת בה עבור שרת Kubernetes API.
    • מבצעים רוטציה לרשות האישורים (CA) הבסיסית של האשכול.

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

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

ביצוע סבב IP

רוטציית כתובות IP היא תהליך רב-שלבי:

  1. כשמתחילים רוטציה של כתובות IP, מישור הבקרה מתחיל לפעול בכתובת ה-IP החדשה בנוסף לכתובת ה-IP המקורית.
  2. ‫GKE יוצר מחדש את מאגרי הצמתים כדי להשתמש בכתובת ה-IP החדשה, תוך התחשבות בזמינות לצורך תחזוקה. אפשר גם ליצור מחדש את מאגרי הצמתים באופן ידני על ידי ביצוע שדרוג של גרסת מאגר הצמתים לאותה גרסת GKE שבה הצמתים כבר פועלים.
  3. אחרי שמתחילים את הרוטציה, צריך לעדכן את לקוחות ה-API של האשכול (למשל מכונות פיתוח שמשתמשות בממשק שורת הפקודה kubectl) כדי להתחיל לתקשר עם מישור הבקרה באמצעות כתובת ה-IP החדשה.
  4. בסיום הרוטציה, מישור הבקרה מפסיק להעביר תנועה עם כתובת ה-IP הקודמת.

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

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

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

התחלת הסיבוב

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

    gcloud container clusters update CLUSTER_NAME \
    --start-ip-rotation

    מחליפים את CLUSTER_NAME בשם האשכול.

    הפלט אמור להיראות כך:

    This will start an IP Rotation on cluster CLUSTER_NAME.
The master will be updated to serve on a new IP address in addition to
the current IP address. Google Kubernetes Engine will then schedule recreation of all nodes
to point to the new IP address.  If maintenance window is
used, nodes are not recreated until a maintenance window occurs. See
documentation on how to manually update nodes. This operation is
long-running and will block other operations on the cluster (including
delete) until it has run to completion.
Do you want to continue (Y/n)?

    הפקודה הזו מגדירה את מישור הבקרה כך שיפעל בשתי כתובות IP: הכתובת המקורית וכתובת חדשה.

  2. מאשרים את הסיבוב ומשאירים את המעטפת פתוחה עד לסיום הפעולה.

הפעלה מחדש של רכיבים בתוך האשכול עם חיבורים לטווח ארוך

אחרי שמתחילים רוטציה של כתובת IP או של פרטי כניסה, מתבצעת גם רוטציה של רשות האישורים (CA) של האשכול. יכול להיות שרכיבים מסוימים בתוך האשכול ששומרים על חיבורי TLS לטווח ארוך, כמו metrics-server ו-konnectivity-agent, לא יבטחו באופן אוטומטי ב-CA החדש של האשכול.

במצב כזה, החיבורים האלה עלולים להיכשל כשמתקשרים עם צמתים או עם נקודות קצה אחרות של האשכול, ויכול להיות שיופיעו שגיאות של לחיצת יד ב-TLS ביומני הרכיבים, כמו x509: certificate signed by unknown authority.

אם השגיאות האלה מופיעות אחרי שמתחילים רוטציה, יכול להיות שצריך להפעיל מחדש את ה-Pods באופן ידני. הפעלה מחדש מאלצת את ה-Pod לאתחל מחדש את החיבור שלו ולטעון את אישורי ה-CA החדשים של האשכול. לדוגמה, כדי להפעיל מחדש את metrics-server ואת konnectivity-agent, מריצים את הפקודות הבאות:

kubectl rollout restart deployment metrics-server -n kube-system
kubectl rollout restart deployment konnectivity-agent -n kube-system

יצירה מחדש של צמתים

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

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

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

    gcloud container clusters upgrade CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

    מחליפים את VERSION בגרסת GKE זהה לגרסה שבה נעשה שימוש באשכול.

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

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

  1. כדי לעקוב אחרי פעולת הרוטציה, מריצים את הפקודה הבאה:

    gcloud container operations list \
    --filter="operationType=UPGRADE_NODES AND status=RUNNING" \
    --format="value(name)"

    הפקודה הזו מחזירה את מזהה הפעולה של פעולת שדרוג הצומת.

  2. כדי לבדוק את סטטוס הפעולה, מעבירים את מזהה הפעולה לפקודה הבאה:

    gcloud container operations wait OPERATION_ID

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

עדכון לקוחות API

אחרי שמפעילים את רוטציית כתובות ה-IP, צריך לעדכן את כל לקוחות ה-API מחוץ לאשכול (למשל kubectl במכונות של מפתחים) כך שיצביעו על כתובת ה-IP החדשה.

כדי לעדכן את לקוחות ה-API, מריצים את הפקודה הבאה לכל לקוח:

gcloud container clusters get-credentials CLUSTER_NAME

עדכון של כתובות IP וכללים לחומת אש שהוזנו ישירות לקוד

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

השלמת הסבב

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

כדי להשלים את הרוטציה, מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --complete-ip-rotation

הפלט אמור להיראות כך:

This will complete the in-progress IP Rotation on cluster CLUSTER_NAME.
The master will be updated to stop serving on the old IP address and only
serve on the new IP address. Make sure all API clients have been updated
to communicate with the new IP address (e.g. by running `gcloud container
clusters get-credentials --project PROJECT_ID --region COMPUTE_REGION
CLUSTER_NAME`). This operation is long-running and will
block other operations on the cluster (including delete) until it has
run to completion.

אם רוטציית כתובות ה-IP לא הושלמה ומוחזרת הודעת שגיאה שדומה להודעה הבאה, כדאי לעיין במאמר שגיאה 400: צריך ליצור מחדש את מאגר הצמתים:

ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

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

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