בדף הזה מוסבר איך להתאים אישית דיסק אתחול של צומת באשכולות ובמאגרי צמתים של Google Kubernetes Engine (GKE).
סקירה כללית
כשיוצרים אשכול GKE או מאגר צמתים, אפשר לבחור את סוג ה-Persistent Disk שעליו מותקנת מערכת הקבצים של צומת Kubernetes לכל צומת. כברירת מחדל, ב-GKE נעשה שימוש בדיסקים קשיחים מאוזנים בגרסה 1.24 ואילך. אפשר גם לציין סוגים אחרים של Persistent Disk, כמו standard או SSD. מידע נוסף זמין במאמר בנושא אפשרויות אחסון.
לדיסקים מאוזנים ולדיסקים מתמידים שמבוססים על SSD יש מכסות דיסק שונות ממכסות הדיסק המתמיד הסטנדרטי. אם אתם עוברים מדיסקים רגילים לדיסקים מאוזנים, יכול להיות שתצטרכו לבקש הגדלה של המכסות. מידע נוסף זמין במאמר בנושא מכסות משאבים.
היתרונות של שימוש בדיסק אתחול SSD
שימוש בדיסק מתמיד שמבוסס על SSD כדיסק אתחול לצמתים מציע כמה יתרונות מבחינת ביצועים:
- לצמתים יש זמני אתחול מהירים יותר.
- הקבצים הבינאריים והקבצים שמוגשים מהקונטיינרים זמינים לצומת מהר יותר. השימוש ב-SSD יכול לשפר את הביצועים של עומסי עבודה שדורשים הרבה פעולות קלט/פלט, כמו אפליקציות להצגת אתרים שמארחות קבצים סטטיים או עבודות אצווה קצרות שדורשות הרבה פעולות קלט/פלט.
- הביצועים של קלט/פלט (I/O) של קבצים שמאוחסנים במדיה המקומית של הצומת (שנחשפת דרך
hostPathאוemptyDir) יכולים להשתפר.
ציון סוג דיסק האתחול של הצומת
אתם יכולים לציין את סוג דיסק האתחול כשאתם יוצרים אשכול או מאגר צמתים.
gcloud
כדי ליצור אשכול עם דיסק אתחול בהתאמה אישית, מריצים את הפקודה הבאה.
הערך [DISK-TYPE] יכול להיות אחד מהערכים הבאים:
-
pd-balanced(ברירת המחדל בגרסה 1.24 ואילך) -
pd-standard(ברירת המחדל בגרסה 1.23 או בגרסה ישנה יותר) pd-ssdhyperdisk-balanced
מידע נוסף זמין במאמר סוגי Persistent Disk.
gcloud container clusters create [CLUSTER_NAME] --disk-type [DISK_TYPE]
כדי ליצור מאגר צמתים באשכול קיים:
gcloud container node-pools create [POOL_NAME] --disk-type [DISK_TYPE]
לדוגמה, הפקודה הבאה יוצרת אשכול, example-cluster, עם סוג הדיסק המתמיד שמבוסס על SSD, pd-ssd:
gcloud container clusters create example-cluster --disk-type pd-ssd
המסוף
כדי לבחור את דיסק האתחול כשיוצרים את האשכול באמצעות מסוף Google Cloud :
נכנסים לדף Create a Kubernetes cluster במסוף Google Cloud .
מגדירים את האשכול לפי הצורך.
בתפריט הניווט, מרחיבים את default-pool ולוחצים על Nodes (צמתים).
ברשימה הנפתחת Boot disk type, בוחרים סוג של Persistent Disk.
לוחצים על יצירה.
כדי ליצור מאגר צמתים עם דיסק אתחול בהתאמה אישית לאשכול קיים:
נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
לוחצים על הכרטיסייה Nodes (צמתים).
לוחצים על add_box Create user-managed node pool (יצירת מאגר צמתים בניהול המשתמש).
מגדירים את מאגר הצמתים לפי הצורך.
בתפריט הניווט, לוחצים על Nodes.
ברשימה הנפתחת Boot disk type, בוחרים סוג של Persistent Disk.
לוחצים על יצירה.
הגנה על דיסקים של אתחול צמתים
דיסק האתחול של הצומת מאחסן את קובץ האימג' של הקונטיינר, חלק מיומני התהליכים של המערכת, יומני ה-Pod ושכבת הקונטיינר שניתנת לכתיבה כברירת מחדל.
אם עומסי העבודה שלכם משתמשים בנפחים של configMap, emptyDir או hostPath, יכול להיות שה-Pods שלכם יכתבו נתונים נוספים בדיסקים של אתחול הצמתים. כדי למנוע את זה, אתם יכולים להגדיר את emptyDir כך שהוא יגובה על ידי tmpfs. הוראות מפורטות זמינות במאמרי העזרה של Kubernetes.
מכיוון שהנפחים secret, downwardAPI ו-projected מגובים על ידי tmpfs, הפודים שמשתמשים בהם לא כותבים נתונים לדיסק האתחול של הצומת.
כברירת מחדל, Google Cloud מצפינה את תוכן הלקוחות במנוחה, כולל דיסקי האתחול של הצמתים, ו-GKE מנהלת את ההצפנה בשבילכם בלי שתצטרכו לבצע שום פעולה.
עם זאת, כשמשתמשים בנפחים שכותבים לדיסק האתחול של הצומת, יכול להיות שתרצו לשלוט יותר באופן שבו נתוני עומס העבודה מוגנים ב-GKE. כדי לעשות את זה, אפשר למנוע מפודים לכתוב לדיסקי אתחול של צמתים או להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) לדיסקי אתחול של צמתים.
מניעת כתיבה של Pods לדיסקי אתחול
כדי למנוע מפודים לכתוב נתונים ישירות לדיסק האתחול של הצומת, אתם יכולים להשתמש באחת מהשיטות הבאות.
Policy Controller
Policy Controller היא תכונה של GKE Enterprise שמאפשרת להצהיר על מדיניות מותאמת אישית ולאכוף אותה בקנה מידה גדול באשכולות GKE בציים.
- התקנה של Policy Controller
- מגדירים אילוץ שמגביל את סוגי הווליומים הבאים באמצעות תבנית האילוצים
k8sPspVolumeTypes:configMap-
emptyDir(אם לא מגובה על ידי tmpfs) hostPathהוראות זמינות במאמר שימוש בספריית תבניות האילוצים במסמכי Policy Controller.
האילוץ הבא מגביל את סוגי אמצעי האחסון האלה בכל ה-Pods באשכול:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
name: deny-boot-disk-writes
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
volumes:
- configMap
- emptyDir
- hostPath
בקרת אישור בקשות של PodSecurity
בקרת הכניסה המובנית של Kubernetes PodSecurity מאפשרת לכם לאכוף רמות שונות של תקני אבטחת הפודים במרחבי שמות ספציפיים או באשכול. המדיניות המוגבלת מונעת מ-Pods לכתוב לדיסק האתחול של הצומת.
כדי להשתמש בבקרת הכניסה PodSecurity, אפשר לעיין במאמר החלת מדיניות אבטחה מוגדרת מראש ברמת ה-Pod באמצעות PodSecurity.
הצפנה בניהול הלקוח
אם אתם רוצים לשלוט ברוטציית מפתחות ההצפנה ולנהל אותה בעצמכם, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK). המפתחות האלה משמשים להצפנה של המפתחות להצפנת נתונים, שבאמצעותם מוצפנים הנתונים שלכם. כדי ללמוד איך להשתמש ב-CMEK עבור דיסקים לאתחול צמתים, קראו את המאמר שימוש במפתחות הצפנה בניהול הלקוח.
מגבלה של CMEK לדיסקים של אתחול צמתים היא שאי אפשר לשנות אותו אחרי יצירת מאגר הצמתים. כלומר:
- אם מאגר הצמתים נוצר עם הצפנה בניהול הלקוח, אי אפשר להשבית את ההצפנה בדיסקי אתחול בהמשך.
- אם מאגר הצמתים נוצר בלי הצפנה בניהול הלקוח, אי אפשר להפעיל הצפנה בדיסקים של מערכת ההפעלה בשלב מאוחר יותר. עם זאת, אתם יכולים ליצור מאגר צמתים חדש עם הצפנה באמצעות מפתחות בניהול הלקוח, ולמחוק את מאגר הצמתים הקודם.
מגבלות
לפני שמגדירים דיסק אתחול בהתאמה אישית, חשוב לקחת בחשבון את המגבלות הבאות:
המאמרים הבאים
- כך מציינים פלטפורמת CPU מינימלית.
- מידע נוסף על הצפנה בניהול הלקוח
- מידע נוסף על שימוש במפתחות הצפנה בניהול הלקוח ב-GKE