‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

חידוש ידני של אישורים לאשכולות שפג תוקפם

חידוש ידני של אישורים מאפשר לשחזר את הפעולות של מישור הבקרה ב-Google Distributed Cloud כשפג התוקף של אישורי Transport Layer Security ‏ (TLS). לא תוכלו לנהל את עומסי העבודה ואת מחזורי החיים של האשכולות עד שתחדשו את אישורי ה-TLS שפג תוקפם. במאמר תפוגת תוקף של אישורים מוסבר מה קורה כשתוקף האישורים פג.

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

שגיאות שנגרמו בגלל שתוקף האישור פג

אם פג התוקף של אישורי ה-TLS באשכול, בקרי הליבה לא יכולים ליצור חיבורי TLS עם שרת ה-API של Kubernetes. היעדר הקישוריות גורם לשגיאות הבאות:

לא ניתן להתחבר לשרת: x509

כשמשתמשים ב-kubectl כדי לקבל את צומתי האשכול, התגובה כוללת שגיאה שהאישורים פגו, כמו בפלט לדוגמה הבא:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```
לא ניתן להתחבר: x509 או החיבור נדחה

אישורים שפג תוקפם חוסמים את הגישה לאשכול etcd, כי עמיתים לא יכולים לתקשר זה עם זה. יכול להיות שביומני ה-etcd יהיו רשומות של שגיאות כמו:
```
W | rafthttp: health check for peer 6221a1d241bb2d0a could not connect: x509: certificate
has expired or is not yet valid
I | embed: rejected connection from "10.200.0.4:46108" (error "remote error: tls: bad
certificate", ServerName "")
```

בדיקת זמני התפוגה של האישורים

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

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

sudo kubeadm certs check-expiration

בפלט הפקודה מופיעים האישורים שנוצרו על ידי kubeadm לרכיבים של מישור הבקרה, וגם תאריך התפוגה שלהם, כמו שמוצג בפלט לדוגמה הבא:

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Nov 28, 2021 19:09 UTC   53m                                     no
apiserver                  Nov 28, 2021 19:09 UTC   53m             ca                      no
apiserver-etcd-client      Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
apiserver-kubelet-client   Nov 28, 2021 19:09 UTC   53m             ca                      no
controller-manager.conf    Nov 28, 2021 19:09 UTC   53m                                     no
etcd-healthcheck-client    Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
etcd-peer                  Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
etcd-server                Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
front-proxy-client         Nov 28, 2021 19:09 UTC   53m             front-proxy-ca          no
scheduler.conf             Nov 28, 2021 19:09 UTC   53m                                     no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Nov 26, 2031 18:06 UTC   9y              no
etcd-ca                 Nov 26, 2031 18:06 UTC   9y              no
front-proxy-ca          Nov 26, 2031 18:06 UTC   9y              no

מריצים את הפקודה הבאה כדי לבדוק את זמני התפוגה של אישורי kubelet:
```
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
```
התגובה לכל פקודה אמורה להיראות כמו פלט הדוגמה הבא:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
אם כל הצמתים של מישור הבקרה אותחלו באותו זמן, מועדי התפוגה של האישורים יהיו בהפרש של כמה דקות זה מזה. היחס הזה בין הזמנים חל על כל הצמתים במישור הבקרה. כדי לאמת את מועדי התפוגה, אפשר להריץ את הפקודות הקודמות בכל צומת במישור הבקרה.

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

grep 'client-certificate-data' KUBECONFIG_PATH | \
    awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2

התגובה אמורה להיראות כך:

Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT

מריצים את הפקודה הבאה כדי לחפש את תאריך התפוגה של האישור של kubeconfig באשכול האדמין:
```
kubectl get secret/CLUSTER_NAME-kubeconfig \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG \
    -o jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | \
    awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫CLUSTER_NAME: שם האשכול שאתם מחדשים את האישורים שלו.
- ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול שאתם מחדשים את האישורים שלו.
התגובה אמורה להיראות כך:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
אישור ה-kubeconfig באשכול האדמין והאישור בקובץ kubeconfig בתחנת העבודה של האדמין זהים. לכן, הפלט של הפקודה הזו והפקודה מהשלב הקודם חייבים להיות זהים.

חידוש אישורים באופן ידני

כדי לחדש באופן ידני אישורי TLS לאשכול, צריך לפעול לפי ההוראות בקטעים הבאים.

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

מבצעים את השלבים הבאים בכל צומת של מישור הבקרה באשכול הרלוונטי:

מגבים את התיקייה /etc/kubernetes.

מריצים את הפקודה הבאה של kubeadm כדי לחדש את כל האישורים. הפקודה מחדשת את האישורים באמצעות רשויות האישורים (CA) הקיימות במחשב:

sudo kubeadm certs renew all

פלט הפקודה דומה לדוגמה הבאה:

certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healthcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed

כדי לוודא שלאישורים יש מועד תפוגה חדש, מריצים את הפקודה הבאה:
```
sudo kubeadm certs check-expiration
```
לא כל הרכיבים של מישור הבקרה תומכים בטעינה מחדש של אישורים דינמיים. כדי לאסוף את האישורים המחודשים, בשלבים הבאים מפעילים מחדש את הקונטיינרים הבאים: kube-apiserver,‏ kube-scheduler ו-kube-controller-manager.

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

הערה: אם פג התוקף של האישורים, מומלץ לבצע קודם את השלב הבא במאגר kube-apiserver. אחר כך עוצרים את הקונטיינרים kube-scheduler ו-kube-controller-manager.
1. מוצאים את המזהה של כל מאגר:
```
sudo crictl ps | grep CONTAINER_NAME
```
  מחליפים את CONTAINER_NAME בשם של אחד מהקונטיינרים הבאים: kube-apiserver,‏ kube-scheduler או kube-controller-manager.
  
  התגובה אמורה להיראות כך:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  מזהה מאגר התגים הוא הערך שמופיע בעמודה הראשונה.
2. עוצרים כל קונטיינר:
```
sudo crictl stop CONTAINER_ID
```
  מחליפים את CONTAINER_ID במזהה הקונטיינר מהשלב הקודם.
  
  כשהקונטיינר שהופסק נסגר, kubelet יוצר קונטיינר חדש במקומו ומוחק את הקונטיינר שהופסק. אם מופיעה שגיאה, כמו context deadline exceeded (קוד שגיאה DeadlineExceeded), מריצים מחדש את הפקודה.

מוודאים שהקישוריות חזרה

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

כדי לאמת את החיבור לשרת ה-API של Kubernetes, מריצים את הפקודה הבאה של kubectl בכל צומת של מישור הבקרה:
```
kubectl get nodes --kubeconfig /etc/kubernetes/admin.conf
```

התשובה צריכה להחזיר את רשימת הצמתים של האשכול. אם האישורים חודשו כמו שצריך, לא יוחזרו שגיאות TLS או שגיאות אישורים.

עדכון הסוד של kubeconfig באשכול

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

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

משתמשים ב-sed כדי להחליף את kubernetes בקובץ admin.conf בשם של האשכול, וכותבים את השינויים בקובץ חדש, kubeconfig_secret.conf:
```
sed "s/kubernetes/CLUSTER_NAME/g" \
    /etc/kubernetes/admin.conf > /etc/kubernetes/kubeconfig_secret.conf
```

כדי לוודא שהקובץ kubeconfig_secret.conf עודכן, משתמשים ב-diff:

diff /etc/kubernetes/admin.conf /etc/kubernetes/kubeconfig_secret.conf

בתגובה מוצגים כל המקומות שבהם הקובץ kubeconfig_secret.conf שונה מהקובץ המעודכן admin.conf. לדוגמה, אם ביצעתם את השלב הקודם באשכול בשם demo-cluster, הפלט ייראה כך:

6c6
<   name: kubernetes
---
>   name: demo-cluster
9,12c9,12
<     cluster: kubernetes
<     user: kubernetes-admin
<   name: kubernetes-admin@kubernetes
< current-context: kubernetes-admin@kubernetes
---
>     cluster: demo-cluster
>     user: demo-cluster-admin
>   name: demo-cluster-admin@demo-cluster
> current-context: demo-cluster-admin@demo-cluster
16c16
< - name: kubernetes-admin
---
> - name: demo-cluster-admin

מריצים את הפקודות הבאות כדי לעדכן את הסוד של kubeconfig באשכול:

CLUSTER_KUBECONFIG_BASE64=$(base64 /etc/kubernetes/kubeconfig_secret.conf -w 0)

kubectl get secret/CLUSTER_NAME-kubeconfig \
    -n CLUSTER_NAMESPACE \
    --kubeconfig /etc/kubernetes/admin.conf -o json | jq \
    --arg conf "${CLUSTER_KUBECONFIG_BASE64}" '.data."value" |= $conf' | kubectl apply \
    --kubeconfig /etc/kubernetes/admin.conf -f -

החלפת קובץ ה-kubeconfig של האשכול

כדי להחליף את קובץ ה-kubeconfig של האשכול בקובץ עם האישורים המחודשים, מבצעים את השלבים הבאים:

מעתיקים את הקובץ admin.conf מאחד מהצמתים של מישור הבקרה של האשכול לתחנת העבודה של האדמין.

כפי שצוין בקטעים הקודמים, הקובץ admin.conf נמצא בספרייה etc/kubernetes בצמתים של מישור הבקרה של האשכול.
כדי ליצור את קובץ ה-kubeconfig החדש, מריצים את הפקודה הבאה של kubectl בתחנת העבודה של האדמין:
```
kubectl --kubeconfig ADMIN_CONF_PATH get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}'  | \
    base64 --decode > new_kubeconfig.conf
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ADMIN_CONF_PATH: הנתיב של הקובץ admin.conf שהועתק לתחנת העבודה של האדמין מצומת של מישור הבקרה.
- ‫CLUSTER_NAME: שם האשכול שאתם מחדשים את האישורים שלו.
- ‫CLUSTER_NAMESPACE: מרחב השמות של האשכול שאתם מחדשים את האישורים שלו.
הקובץ new_kubeconfig.conf מכיל את נתוני האישור המעודכנים.
כדי לוודא שה-kubeconfig החדש פועל, מריצים פקודת kubectl כלשהי באמצעות פרטי הכניסה החדשים:
```
kubectl get nodes --kubeconfig new_kubeconfig.conf
```
מחליפים את התוכן של קובץ ה-kubeconfig הישן ששמור בספריית האשכול בתחנת העבודה של האדמין, בתוכן של קובץ ה-kubeconfig החדש new-kubeconfig.conf.

כברירת מחדל, הנתיב לקובץ התצורה של האשכול הוא bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

אימות האישורים של kubelet והפעלה מחדש של `etcd-defrag`

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

נכנסים לצומת של מישור הבקרה ומריצים את הפקודות הבאות כדי לבדוק את מועד התפוגה של אישור הלקוח ואישור השירות של kubelet:

אישורי Kubelet עוברים רוטציה באופן אוטומטי כל עוד אפשר להגיע למישור הבקרה. תקופת החידוש האוטומטי של אישורי kubelet קצרה יותר מתקופת התפוגה של אישורי הרכיבים של מישור הבקרה. לכן, סביר להניח שאישורי kubelet חודשו לפני:
```
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
```
הפלט של כל אחת מהפקודות אמור להיראות כמו בדוגמה הבאה:
```
Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT
```
מריצים את הפקודה הבאה כדי להפעיל מחדש את הקונטיינר של etcd-defrag:

הקונטיינר etcd-defrag משתמש באישורי הלקוח של apiserver-etcd כדי לתקשר עם etcd, וצריך להפעיל אותו מחדש כדי לקבל את האישורים המעודכנים.
```
kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
```

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

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

אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care. במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל:

הדרישות לפתיחת בקשת תמיכה.
כלים שיעזרו לכם לפתור בעיות, כמו הגדרת הסביבה, יומנים ומדדים.
רכיבים נתמכים.