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

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