החלפה של אישורי CA של אשכולות אדמין

ב-Google Distributed Cloud נעשה שימוש באישורים ובמפתחות פרטיים כדי לאמת את התקשורת בין רכיבי מערכת Kubernetes באשכול אדמין. כשיוצרים אשכול אדמין, נוצרים אישורים חדשים של רשות אישורים (CA), ואישורי הבסיס האלה משמשים להנפקת אישורי עלים נוספים לרכיבי מערכת Kubernetes.

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

יש שלושה אישורי CA שמשמשים את מערכת Kubernetes באדמין קלאסטר:

  • אישור ה-CA של etcd מאבטח את התקשורת משרת ה-API של Kubernetes אל העותקים המשוכפלים של etcd, וגם את התקשורת בין העותקים המשוכפלים של etcd. האישור הזה הוא בחתימה עצמית.

  • אישור ה-CA של האשכול מאבטח את התקשורת בין שרת Kubernetes API לבין כל לקוחות Kubernetes API הפנימיים, לדוגמה, kubelet,‏ controller manager ו-scheduler. האישור הזה הוא בחתימה עצמית.

  • אישור ה-CA של שרת ה-proxy הקדמי מאבטח את התקשורת עם ממשקי API מצטברים. האישור הזה הוא בחתימה עצמית.

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

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

תקופת התפוגה תלויה בסוג האשכול ובגרסת היצירה שלו:

  • אשכולות מתקדמים:
    • תוקף ל-10 שנים
  • קלאסטרים לא מתקדמים:
    • נוצר לפני גרסה 1.5: תפוגה אחרי 10 שנים
    • נוצרו בין גרסאות 1.5 עד 1.16: תוקף של 5 שנים
    • נוצרו אחרי גרסה 1.16: תפוגה אחרי 30 שנה

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

מגבלות

  • שימו לב למגבלה הבאה בנוגע לאשכולות מתקדמים:

    • גרסה 1.31: אין תמיכה בסיבוב של רשות אישורים באשכולות מתקדמים.
    • גרסה 1.32 ואילך: יש תמיכה ברוטציה של CA באשכולות מתקדמים, אבל יש כמה הבדלים קלים שמצוינים במסמך הזה במקומות הרלוונטיים.

  • רוטציה של אישורי CA מוגבלת לאישורי etcd, לאישורי אשכול ולאישורי front-proxy שצוינו קודם.

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

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

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

  • אחרי שמתחילים את רוטציית אישורי ה-CA, אי אפשר לבטל אותה.

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

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

התחלת הסבב

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

gkectl update credentials certificate-authorities rotate \
    --admin-cluster \
    --config ADMIN_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ADMIN_CLUSTER_CONFIG: הנתיב של קובץ ההגדרות של אשכול האדמין

  • ‫ADMIN_CLUSTER_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין

ההתנהגות של הפקודה משתנה בהתאם לשאלה אם האפשרות 'אשכול מתקדם' מופעלת:

מושבתת

הפקודה gkectl update credentials certificate-authorities rotate מתחילה ומבצעת את המחצית הראשונה של הרוטציה. הפקודה מושהית כדי לאפשר לכם להריץ את הפקודה הבאה לעדכון קובץ ה-kubeconfig.

עדכון קובץ ה-kubeconfig

כשפקודת gkectl update credentials certificate-authorities rotate מושהית, מעדכנים את קובץ ה-kubeconfig של אשכול האדמין. הפעולה הזו מוסיפה אישור לקוח חדש ואישור CA חדש לקובץ kubeconfig. אישור הלקוח הישן מוסר מקובץ ה-kubeconfig, ואישור ה-CA הישן נשאר בקובץ ה-kubeconfig.

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

המשך הסבב

מריצים את הפקודה הבאה כדי לבצע את החלק השני של התהליך. הפקודה לא תמשיך עד ש-gkectl יוודא שקובץ ה-kubeconfig המעודכן נמצא בספרייה הנוכחית.

gkectl update credentials certificate-authorities rotate \
  --admin-cluster \
  --complete \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

בסיום הרוטציה, המערכת מדווחת על גרסת ה-CA הנוכחית.

עדכון חוזר של קובץ ה-kubeconfig

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

gkectl update credentials certificate-authorities update-kubeconfig \
  --admin-cluster \
  --config ADMIN_CLUSTER_CONFIG \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

מופעל

אם האפשרות 'אשכול מתקדם' מופעלת, הפקודה gkectl update credentials certificate-authorities rotate היא סינכרונית. הפקודה מוציאה הודעות סטטוס לתחנת העבודה של האדמין ככל שהרוטציה של רשות האישורים מתקדמת.

אחרי שהחלפת ה-CA מסתיימת בהצלחה, הפקודה יוצאת ונוצר אוטומטית קובץ kubeconfig חדש. קובץ ה-kubeconfig שציינתם בפקודה מוחלף בקובץ חדש. הפלט של הפקודה אמור להיראות כך:

Beginning CA rotation with generated CA
...
Successfully rotated CA for admin cluster. The kubeconfig file
"/home/ubuntu/kubeconfig" has been updated.
Done rotating certificate-authorities

הפצת קובץ ה-kubeconfig החדש

מפיצים את קובץ ה-kubeconfig של אשכול האדמין החדש לכל המשתמשים באשכול.