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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-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 ממשיך לנסות להשלים את הפעולה עד שהצמתים נוצרים מחדש.

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