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

גישה למכונות Filestore באמצעות מנהל התקן Filestore CSI

מנהל ההתקן של Filestore CSI הוא הדרך העיקרית להשתמש במכונות Filestore עם Google Kubernetes Engine‏ (GKE). מנהל ההתקן של Filestore CSI מספק חוויה מנוהלת לחלוטין, שמבוססת על Google Cloud מנהל ההתקן של Filestore CSI בקוד פתוח.

גרסת מנהל התקן ה-CSI של Filestore קשורה למספרי הגרסאות המשניות של Kubernetes. גרסת מנהל ההתקן של Filestore CSI היא בדרך כלל מנהל ההתקן העדכני ביותר שזמין בזמן שבו הגרסה המשנית של Kubernetes משוחררת. הדרייברים מתעדכנים באופן אוטומטי כשמשדרגים את האשכול לתיקון האחרון של GKE.

יתרונות

מנהל ההתקן של Filestore CSI מספק את היתרונות הבאים:

יש לכם גישה לאחסון NFS מנוהל לחלוטין דרך ממשקי ה-API של Kubernetes (kubectl).
אתם יכולים להשתמש במנהל ההתקן של GKE Filestore CSI כדי להקצות באופן דינמי את ה-PersistentVolumes.
אתם יכולים להשתמש בתמונות מצב של נפחים באמצעות מנהל התקן ה-CSI של GKE Filestore. אפשר להשתמש בתמונות מצב של אמצעי אחסון ב-CSI כדי ליצור גיבויים של Filestore.

גיבוי של Filestore יוצר עותק דיפרנציאלי של הקובץ המשותף, כולל כל הנתונים והמטא-נתונים של הקובץ, ומאחסן אותו בנפרד מהמכונה. אפשר לשחזר את העותק הזה רק למכונה חדשה של Filestore. אי אפשר לשחזר למכונה קיימת של Filestore. כדי להפעיל גיבויים של Filestore, אתם יכולים להשתמש ב-API של תמונת המצב של הנפח ב-CSI על ידי הוספת השדה type:backup בסיווג של תמונת המצב של הנפח.
אפשר להשתמש בהרחבת נפח עם מנהל התקן ה-CSI של GKE Filestore. הרחבת נפח האחסון מאפשרת לשנות את גודל הקיבולת של נפח האחסון.
כדי לגשת למכונות קיימות של Filestore, אתם יכולים להשתמש במכונות של Filestore שהוקצו מראש בעומסי עבודה של Kubernetes. אתם יכולים גם ליצור או למחוק באופן דינמי מכונות של Filestore ולהשתמש בהן בעומסי עבודה ב-Kubernetes באמצעות StorageClass או Deployment.
תמיכה בשיתופים מרובים של Filestore ל-GKE. התכונה הזו מאפשרת ליצור מכונה של Filestore ולהקצות לה כמה PersistentVolumes קטנים יותר שמותקנים ב-NFS, בו-זמנית בכל מספר של אשכולות GKE.
תמיכה בהתאמת ביצועים לעומס באופן עצמאי. אתם יכולים לשנות באופן דינמי את הביצועים של Filestore‏ (IOPS) בלי קשר לנפח האחסון בזמן הריצה, בלי להפריע לשירות.

דרישות

כדי להשתמש במנהל ההתקן של Filestore CSI, האשכולות צריכים לעמוד בדרישות הבאות:
- גרסת GKE הנדרשת תלויה ברמת השירות של Filestore ובתכונות שבהן אתם מתכוונים להשתמש. בטבלה רמות שירות, פרוטוקולים וגרסאות GKE נתמכים מפורטים השילובים הנתמכים.
- מנהל התקן ה-CSI של Filestore נתמך באשכולות שמשתמשים בצומתי Linux בלבד. אין תמיכה בצומתי Windows Server.
- הגודל המינימלי של מכונה הוא 1 TiB.
מידע נוסף זמין במאמר רמות שירות.

רמות שירות, פרוטוקולים וגרסאות GKE נתמכות

בטבלה הבאה מפורטים השילובים הנתמכים של רמות השירות והפרוטוקולים של Filestore, וגרסאות GKE המינימליות הנדרשות לשימוש עם מנהל ההתקן של Filestore CSI.

רמת שירות	סוג השיתוף	הגרסה המינימלית של GKE ל-NFSv3	הגרסה המינימלית של GKE ל-NFSv4.1
Enterprise	שיתוף יחיד, שיתוף מרובה	1.25	‫1.33 (שיתוף יחיד בלבד)
אזורית (‎1 TiB - 9.75 TiB)	שיתוף יחיד	1.31	1.33
אזורי (‎10 TiB - 100 TiB)	שיתוף יחיד	1.27	1.33
אזורי (‎1 TiB - 9.75 TiB)	שיתוף יחיד	1.33.4-gke.1172000	1.33.4-gke.1172000
אזורי (10 TiB עד 100 TiB)	שיתוף יחיד	1.33.4-gke.1172000	1.33.4-gke.1172000
‫HDD בסיסי (100 GiB עד 63.9 TiB)	שיתוף יחיד	1.33	לא נתמך
HDD בסיסי	שיתוף יחיד	1.21	לא נתמך
SSD בסיסי	שיתוף יחיד	1.21	לא נתמך

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

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

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

מפעילים את Cloud Filestore API ואת Google Kubernetes Engine API.

הפעלת ממשקי ה-API

כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי להוריד את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא תומכות בהרצת הפקודות שבמסמך הזה.
הערה: אם ה-CLI של gcloud כבר מותקן, צריך להגדיר את המאפיין compute/region. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב Standard. אם צריך, יוצרים אשכול Autopilot. מנהל ההתקן של Filestore CSI מופעל כברירת מחדל באשכולות Autopilot.
אם אתם רוצים להשתמש ב-Filestore ברשת VPC משותפת, עיינו בהוראות ההגדרה הנוספות במאמר שימוש ב-Filestore עם VPC משותף.

הפעלת מנהל ההתקן של Filestore CSI באשכול Standard

בגרסה 1.36.3 של Google Kubernetes Engine ואילך, GKE מפעיל את מנהל ההתקן של Filestore CSI כברירת מחדל בכל האשכולות החדשים של Standard ו-Autopilot.

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

gcloud

gcloud container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

מחליפים את CLUSTER_NAME בשם של האשכול הקיים.

המסוף

נכנסים לדף Google Kubernetes Engine במסוף Google Cloud .

כניסה ל-Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
בקטע Features, לצד השדה Filestore CSI driver, לוחצים על Edit Filestore CSI driver.
מסמנים את התיבה Enable Filestore CSI driver.
לוחצים על שמירת השינויים.

אם אתם רוצים להשתמש ב-Filestore ברשת VPC משותפת, קראו את המאמר הפעלת מנהל ההתקן של Filestore CSI באשכול חדש עם VPC משותף.

אחרי שמפעילים את מנהל ההתקן של Filestore CSI, אפשר להשתמש בו בנפחי Kubernetes באמצעות שם מנהל ההתקן והמקצה: filestore.csi.storage.gke.io.

השבתת מנהל ההתקן של Filestore CSI

אפשר להשבית את מנהל התקן ה-CSI של Filestore באשכול קיים מסוג Autopilot או Standard באמצעות ה-CLI של Google Cloud או מסוף Google Cloud .

gcloud

gcloud container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

מחליפים את הערכים הבאים:

‫CLUSTER_NAME: השם של האשכול הקיים.
‫REGION: האזור של האשכול (למשל, us-central1).

המסוף

במסוף Google Cloud , נכנסים לתפריט Google Kubernetes Engine.

כניסה ל-Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
בקטע Features, לצד השדה Filestore CSI driver, לוחצים על Edit Filestore CSI driver.
מבטלים את הסימון של התיבה Enable Filestore CSI driver.
לוחצים על שמירת השינויים.

גישה למכונות קיימות של Filestore באמצעות מנהל התקן ה-CSI של Filestore

בקטע הזה מתואר התהליך הרגיל לשימוש בנפח אחסון של Kubernetes כדי לגשת למכונות Filestore קיימות באמצעות מנהל התקן CSI של Filestore ב-GKE:

יצירת PersistentVolume ו-PersistentVolumeClaim כדי לגשת למכונה

יוצרים קובץ מניפסט כמו זה שמוצג בדוגמה הבאה, ונותנים לו את השם preprov-filestore.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: PV_NAME
spec:
  storageClassName: ""
  capacity:
    storage: 1Ti
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  csi:
    driver: filestore.csi.storage.gke.io
    volumeHandle: "modeInstance/FILESTORE_INSTANCE_LOCATION/FILESTORE_INSTANCE_NAME/FILESTORE_SHARE_NAME"
    volumeAttributes:
      ip: FILESTORE_INSTANCE_IP
      volume: FILESTORE_SHARE_NAME
      protocol: FILESYSTEM_PROTOCOL
  claimRef:
    name: PVC_NAME
    namespace: NAMESPACE
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: PVC_NAME
  namespace: NAMESPACE
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: "" # Set to an empty value to prevent assigning a default StorageClass
  resources:
    requests:
      storage: 1Ti

כדי לקשר PersistentVolumeClaim ל-PersistentVolume סטטי קיים, צריך להגדיר את השדה storageClassName למחרוזת ריקה ("") במפרט של PersistentVolumeClaim. ההגדרה הזו מונעת ממערכת ברירת המחדל שמודעת למצב הגישה להקצות StorageClass כברירת מחדל לבקשה. מידע נוסף מופיע במאמר הקצאת StorageClass שמוגדר כברירת מחדל.

כדי ליצור את המשאבים PersistentVolumeClaim ו-PersistentVolume על סמך קובץ המניפסט preprov-filestore.yaml, מריצים את הפקודה הבאה:
```
kubectl apply -f preprov-filestore.yaml
```

כדי לציין את פרוטוקול מערכת הקבצים NFSv4.1, מגדירים את השדה protocol לערך NFS_V4_1 בשדה volumeAttributes של אובייקט PersistentVolume. כדי להשתמש בפרוטוקול מערכת הקבצים NFSv3, מגדירים את השדה protocol לערך NFS_V3 או משמיטים את השדה protocol.

לאחר מכן, יוצרים פריסה שצורכת את הנפח.

יצירת נפח באמצעות מנהל ההתקן של Filestore CSI

בקטעים הבאים מתואר התהליך הרגיל לשימוש בנפח אחסון של Kubernetes שמגובה על ידי מנהל התקן CSI של Filestore ב-GKE:

יצירת StorageClass
שימוש ב-PersistentVolumeClaim כדי לגשת לאמצעי האחסון
יצירת פריסה שצורכת את אמצעי האחסון

יצירת StorageClass

אחרי שמפעילים את מנהל ההתקן של Filestore CSI, ‏GKE מתקין באופן אוטומטי את ה-StorageClasses הבאים להקצאת מכונות של Filestore:

‫zonal-rwx, באמצעות רמת Filestore zonal.
‫enterprise-rwx, באמצעות Filestore Enterprise, שבה כל PersistentVolume של Kubernetes ממפה למכונה של Filestore.
‫enterprise-multishare-rwx, באמצעות רמת הארגון של Filestore, שבה כל PersistentVolume של Kubernetes ממפה לשיתוף של מכונה נתונה של Filestore. מידע נוסף זמין במאמר שיתוף של כמה משאבים ב-Filestore ל-Google Kubernetes Engine.
standard-rwx, באמצעות רמת השירות הבסיסית של Filestore HDD.
premium-rwx, באמצעות רמת השירות הבסיסית של Filestore SSD.

כל StorageClass זמין רק באשכולות GKE שפועלים בגרסאות GKE הנתמכות שלהם. כאן מפורטות הגרסאות הנתמכות שנדרשות לכל רמת שירות.

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

kubectl get sc

אפשר גם להתקין StorageClass אחר שמשתמש במנהל התקן ה-CSI של Filestore, על ידי הוספת filestore.csi.storage.gke.io בשדה provisioner.

צריך לציין באיזו רשת ליצור את המכונה החדשה של Filestore. ה-StorageClasses שמותקנים באופן אוטומטי משתמשים ברשת שמוגדרת כברירת מחדל שנוצרה בשביל אשכולות GKE. אם מחקתם את הרשת הזו או שאתם רוצים להשתמש ברשת אחרת, אתם צריכים ליצור StorageClass חדש, כמו שמתואר בשלבים הבאים. אחרת, ה-StorageClasses שמותקנים באופן אוטומטי לא יפעלו.

שומרים את המניפסט הבא בתור filestore-example-class.yaml:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: standard
  network: default
```
במניפסט, כדאי להביא בחשבון את הגדרת הפרמטרים הבאה:
- הגדרה של volumeBindingMode ל-Immediate מאפשרת להתחיל מיד בהקצאת אמצעי האחסון. זה אפשרי כי אפשר לגשת למכונות Filestore מכל אזור. לכן, בניגוד לדיסק לאחסון מתמיד של Compute Engine, ב-GKE אין צורך לדעת באיזה אזור הפוד מתוזמן. כשמגדירים את הערך WaitForFirstConsumer, המערכת של GKE מתחילה את ההקצאה רק אחרי שה-Pod מתוזמן. מידע נוסף זמין במאמר VolumeBindingMode.
- אפשר לציין כל רמה נתמכת של Filestore בפרמטר tier (לדוגמה, BASIC_HDD,‏ BASIC_SSD,‏ ZONAL או ENTERPRISE).
- אפשר להשתמש בפרמטר network כשמקצים מכונות Filestore ברשתות VPC שאינן ברירת המחדל. ברשתות VPC שהן לא ברירת המחדל צריך להגדיר כללים מיוחדים של חומת אש.
- אפשר להשתמש בפרמטר protocol כדי להגדיר את פרוטוקול מערכת הקבצים של מכונת Filestore. הערכים האפשריים הם NFS_V3 (ברירת מחדל) ו-NFS_V4_1. פרוטוקול ברירת המחדל הוא NFS_V3.
כדי ליצור משאב StorageClass על סמך קובץ המניפסט filestore-example-class.yaml, מריצים את הפקודה הבאה:
```
kubectl create -f filestore-example-class.yaml
```

אם אתם רוצים להשתמש ב-Filestore ברשת VPC משותפת, קראו את המאמר יצירת StorageClass כשמשתמשים במנהל התקן CSI של Filestore עם VPC משותף.

שימוש ב-PersistentVolumeClaim כדי לגשת לאמצעי האחסון

אפשר ליצור משאב PersistentVolumeClaim שמפנה ל-StorageClass של מנהל ההתקן של Filestore CSI.

אפשר להשתמש ב-StorageClass מותקן מראש או ב-StorageClass בהתאמה אישית.

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

ב-GKE בגרסה 1.37.1 ואילך, Filestore משתמש במערכת ברירת מחדל שמזהה את מצב הגישה. אם יוצרים PersistentVolumeClaim שמבקש את מצב הגישה ReadWriteMany ומשמיטים את השדה storageClassName, אז GKE מגדיר אוטומטית את ברירת המחדל של הבקשה ל-StorageClass regional-rwx.

במניפסט הבא של PersistentVolumeClaim מוצגת התנהגות ברירת המחדל האוטומטית הזו:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-default
spec:
  accessModes:
  - ReadWriteMany
  # storageClassName is omitted, so GKE assigns `regional-rwx`.
  resources:
    requests:
      storage: 1Ti

הפניה ל-StorageClass ספציפי

קובץ המניפסט הבא לדוגמה יוצר PersistentVolumeClaim שמפנה ל-StorageClass בשם filestore-example.

שומרים את קובץ המניפסט הבא בתור pvc-example.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

כדי ליצור משאב PersistentVolumeClaim על סמך קובץ המניפסט pvc-example.yaml, מריצים את הפקודה הבאה:
```
kubectl create -f pvc-example.yaml
```

יצירת פריסה שצורכת את אמצעי האחסון

במניפסט של הפריסה בדוגמה הבאה נעשה שימוש במשאב PersistentVolume בשם pvc-example.yaml.

כמה Pods יכולים לחלוק את אותו PersistentVolumeClaim.

שומרים את המניפסט הבא בתור filestore-example-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: mypvc
      volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

כדי ליצור פריסה שמבוססת על קובץ המניפסט filestore-example-deployment.yaml, מריצים את הפקודה הבאה:
```
kubectl apply -f filestore-example-deployment.yaml
```
מוודאים שהפריסה נוצרה בהצלחה:
```
kubectl get deployment
```
יכול להיות שיעבור קצת זמן עד להשלמת ההקצאה של מכונות Filestore. לפני כן, הפריסות לא ידווחו על סטטוס READY. כדי לבדוק את ההתקדמות, אפשר לעקוב אחרי הסטטוס של PersistentVolumeClaim באמצעות הפקודה הבאה:
```
kubectl get pvc
```
כשההקצאה של אמצעי האחסון תסתיים, הסטטוס של PersistentVolumeClaim אמור להשתנות ל-BOUND.

איך משנים באופן דינמי את הביצועים של Filestore באמצעות VolumeAttributesClass

מנהל ההתקן של Filestore CSI תומך בביצועים בהתאמה אישית לרמות שירות אזוריות ושל תחום מוגדר. הגדרת ביצועים בהתאמה אישית מאפשרת לכם להתאים את ביצועי האפליקציה לפי צורכי עומס העבודה, ולהגדיל או להקטין אותם לפי הצורך. מוודאים שגרסת אשכול GKE היא 1.35 ואילך.

כדי לאפשר התאמה חלקה של הביצועים, אתם יכולים להגדיר כמה רמות ביצועים באמצעות VolumeAttributesClass API. כשיש רמות מוגדרות מראש, אפשר לעדכן באופן דינמי את הגדרות הביצועים בנפחים קיימים על ידי מעבר ביניהם בזמן הריצה, בלי להקצות מחדש את הנפח או להשבית את המערכת.

רמות הביצועים שמוגדרות כברירת מחדל

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

שם רמת הביצועים	פרמטר	‫IOPS מקסימלי
`filestore-high-performance-fixed`	`max-iops`	`"17000"`
`filestore-min-performance-scaling`	`max-iops-per-tb`	`"4000"`
`filestore-moderate-performance-scaling`	`max-iops-per-tb`	`"10000"`

הגדרת רמות ביצועים

כדי להגדיר כמה רמות ביצועים, יוצרים משאבים מסוג VolumeAttributesClass. בדוגמה הבאה, אתם יוצרים רמת ביצועים בינונית וגבוהה באמצעות קצב IOPS קבוע (max-iops). אתם יכולים גם להשתמש ביחס IOPS ל-TiB‏ (max-iops-per-tb) שמשתנה באופן לינארי בהתאם לגודל הנפח.

צריך לציין ערכים של max-iops או max-iops-per-tb שמניבים לפחות 2,000 פעולות קלט/פלט לשנייה (IOPS) שהוקצו. אם מספר ה-IOPS המחושב נמוך מ-2,000, המערכת מעגלת את הערך באופן אוטומטי למינימום הזה.

שומרים את המניפסט הבא בתור performance-tiers.yaml:

apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: filestore-moderate
driverName: filestore.csi.storage.gke.io
parameters:
  max-iops: "4000"
---
apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: filestore-high
driverName: filestore.csi.storage.gke.io
parameters:
  max-iops: "10000"
---
apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: filestore-density-based
driverName: filestore.csi.storage.gke.io
parameters:
  max-iops-per-tb: "5000"

יוצרים את המשאבים של VolumeAttributesClass:
```
kubectl apply -f performance-tiers.yaml
```

יצירת PersistentVolumeClaim עם רמת ביצועים ראשונית

כדי ליצור PersistentVolumeClaim עם הגדרת ביצועים, צריך להפנות ל-VolumeAttributesClass במשאב PersistentVolumeClaim.

שומרים את המניפסט הבא בתור pvc-custom-performance.yaml, עם הפניה לרמה filestore-moderate:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: filestore-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: regional-rwx
  volumeAttributesClassName: filestore-moderate
  resources:
    requests:
      storage: 1Ti

יוצרים את PersistentVolumeClaim:

kubectl apply -f pvc-custom-performance.yaml

עדכון של PersistentVolumeClaim כדי להשתמש ברמת ביצועים אחרת

כשהעומס בעבודה דורש ביצועים גבוהים יותר, מעדכנים את volumeAttributesClassName בקובץ pvc-custom-performance.yaml ל-filestore-high:

 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: filestore-pvc
 spec:
   accessModes:
     - ReadWriteMany
   storageClassName: regional-rwx
   volumeAttributesClassName: filestore-high
   resources:
     requests:
       storage: 1Ti
 ```

מחילים את השינוי:
```
kubectl apply -f pvc-custom-performance.yaml
```
מנהל ההתקן של Filestore CSI מעבד את העדכון באופן דינמי.
בודקים את סטטוס הביצועים:
```
kubectl describe pvc filestore-pvc
```
בודקים את הקטע Events בפלט הפקודה כדי לוודא שהמאפיינים שונו בהצלחה.

הוספת תוויות למכונות של Filestore

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

אפשר להוסיף תוויות באמצעות המפתח labels ב-StorageClass.parameters. אפשר לתייג מכונה של Filestore במידע על PersistentVolumeClaim או PersistentVolume שעבורם נוצרה המכונה. המפתחות והערכים של התוויות המותאמות אישית צריכים לעמוד במוסכמות מתן השמות של התוויות. בדוגמה הזו של מחלקת אחסון ב-Kubernetes מוסבר איך להחיל תוויות בהתאמה אישית על מכונה של Filestore.

שימוש בפרוטוקול מערכת הקבצים NFSv4.1 עם Filestore

מנהל ההתקן של Filestore CSI תומך בפרוטוקול מערכת הקבצים NFSv4.1 עם GKE בגרסה 1.33 ואילך. במקרה של הקצאה סטטית, מגדירים את השדה protocol לערך NFS_V4_1 בשדה volumeAttributes של אובייקט PersistentVolume.

להקצאה דינמית, מגדירים את השדה protocol לערך NFS_V4_1 בפרמטרים של אובייקט StorageClass.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: enterprise-nfsv41-rwx
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise
  instance-storageclass-label: "enterprise-nfsv41-rwx"
  protocol: NFS_V4_1
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

מידע נוסף זמין במאמר מגבלות של NFSv4.1.

שימוש ב-fsgroup עם אמצעי אחסון של Filestore

‫Kubernetes משתמש ב-fsGroup כדי לשנות את ההרשאות והבעלות על אמצעי האחסון כך שיתאימו ל-fsGroup שביקש המשתמש ב-SecurityContext של ה-Pod. fsGroup היא קבוצה משלימה שחלה על כל הקונטיינרים ב-Pod. אפשר להחיל fsgroup על אמצעי אחסון שהוקצו על ידי מנהל התקן ה-CSI של Filestore.

הגדרת כללי גישה לכתובות IP עם נפחי אחסון ב-Filestore

ב-Filestore יש תמיכה בכללי בקרת גישה שמבוססים על כתובות IP לנפחי אחסון. התכונה הזו זמינה באשכולות GKE שפועלים בגרסה 1.29.5 ואילך.

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

אפשר להגדיר את הכללים האלה ישירות דרך Filestore API, או דרך מנהל ההתקן של Filestore CSI כשיוצרים נפח אחסון. אפשר לספק את ההגדרות שנבחרו בפורמט JSON ב-StorageClass באמצעות הפרמטר nfs-export-options-on-create.

הדוגמה הבאה למניפסט מראה איך לציין את ההגדרות:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: "enterprise"
  nfs-export-options-on-create: '[
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/24"
      ],
      "squashMode": "ROOT_SQUASH",
      "anonUid": "1003",
      "anonGid": "1003"
    },
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/28"
      ],
      "squashMode": "NO_ROOT_SQUASH"
    }
  ]'

אפשרויות אבטחה

כללי הגישה לכתובות IP ב-Filestore מפשטים את ההגדרה של הרשאות לאחסון קבצים משותפים לעומסי העבודה ב-GKE. כדי להבין איך מנוהלים הבעלות על הקבצים והגישה אליהם, צריך להבין כמה מושגי מפתח:

מיפויים של NFS ומשתמשים: NFS (מערכת קובצי רשת) הוא הפרוטוקול שמשמש את Filestore. הוא ממפה משתמשים במערכות לקוח (Pod של GKE) למשתמשים בשרת Filestore. אם קובץ בשרת נמצא בבעלות של מזהה משתמש 1003, ולקוח מתחבר עם מזהה משתמש 1003, תהיה לו גישה לקובץ.
דחיסת הרשאות של משתמש root ו-anonUid:
- Root Squashing ROOT_SQUASH הוא אמצעי אבטחה שמונע מלקוחות לגשת למכונה של Filestore עם הרשאות בסיסיות מלאות. כשהאפשרות root squashing מופעלת, משתמשי root במערכות הלקוח ממופים למשתמש ללא הרשאות, שצוין בהגדרה anonUid.
- No Root Squashing (NO_ROOT_SQUASH): הלקוחות יכולים לגשת למכונה של Filestore עם הרשאות בסיסיות מלאות, מה שנוח להגדרה הראשונית אבל פחות מאובטח לפעולות רגילות.
הגדרה ראשונית והרשאות: כברירת מחדל, מכונה חדשה של Filestore נמצאת בבעלות מלאה של משתמש ה-root. אם תפעילו את האפשרות "דחיסת הרשאות של משתמש הבסיס" בלי להגדיר קודם הרשאות למשתמשים אחרים, תאבדו את הגישה. לכן צריך לפחות כלל אחד של ייצוא NFS עם NO_ROOT_SQUASH כדי להגדיר בהתחלה את הגישה למשתמשים ולקבוצות אחרים.

המלצות

הגדרה ראשונית: תמיד צריך להתחיל עם כלל ייצוא אחד לפחות של NFS שמציין טווח של אדמינים עם הרשאות READ_WRITE ומאפשר גישה ל-NO_ROOT_SQUASH. אתם יכולים להשתמש בגישה הזו כדי ליצור ספריות, להגדיר הרשאות ולהקצות בעלות לפי הצורך.
אבטחה: כדי לשפר את האבטחה, מפעילים את האפשרות Root squashing‏ (ROOT_SQUASH). שימו לב שאחרי שיוצרים נפח אחסון, אפשר לשנות את כללי הגישה רק באמצעות Filestore API.
גישה משותפת: משתמשים ב-fsGroup בהקשרי האבטחה של Pod כדי לנהל את הבעלות הקבוצתית על אמצעי אחסון משותפים. חשוב לוודא שההגדרה לא חופפת למצב ROOT_SQUASH. אם תנסו לעשות את זה, תופיע הודעת השגיאה Access denied.

שימוש ב-Filestore עם VPC משותף

בקטע הזה מוסבר איך להשתמש במכונה של Filestore ברשת VPC משותפת מפרויקט שירות.

הגדרת אשכול עם VPC משותף

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

הפעלת מנהל ההתקן של Filestore CSI באשכול חדש עם VPC משותף

כדי להפעיל את מנהל ההתקן של Filestore CSI באשכול חדש עם VPC משותף, מבצעים את הפעולות הבאות:

מאמתים את רשתות המשנה שאפשר להשתמש בהן ואת הטווחים המשניים. כשיוצרים אשכול, צריך לציין את רשת המשנה ואת טווחי כתובות ה-IP המשניים שבהם ישתמשו ה-Pods והשירות של האשכול.

gcloud container subnets list-usable \
   --project=SERVICE_PROJECT_ID \
   --network-project=HOST_PROJECT_ID

הפלט אמור להיראות כך:

PROJECT                   REGION       NETWORK     SUBNET  RANGE
HOST_PROJECT_ID  us-central1  shared-net  tier-1  10.0.4.0/22
┌──────────────────────┬───────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
├──────────────────────┼───────────────┼─────────────────────────────┤
│ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
│ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
└──────────────────────┴───────────────┴─────────────────────────────┘

יוצרים אשכול GKE. בדוגמאות הבאות מוסבר איך משתמשים ב-CLI של gcloud כדי ליצור אשכול Autopilot או אשכול Standard שמוגדר ל-VPC משותף. בדוגמאות הבאות נעשה שימוש בשמות של הרשת, רשת המשנה והטווח מיצירת רשת ושתי רשתות משנה.

טייס אוטומטי

gcloud container clusters create-auto tier-1-cluster \
   --project=SERVICE_PROJECT_ID \
   --region=COMPUTE_REGION \
   --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
   --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
   --cluster-secondary-range-name=tier-1-pods \
   --services-secondary-range-name=tier-1-services

רגילה

gcloud container clusters create tier-1-cluster \
   --project=SERVICE_PROJECT_ID \
   --zone=COMPUTE_REGION \
   --enable-ip-alias \
   --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
   --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
   --cluster-secondary-range-name=tier-1-pods \
   --services-secondary-range-name=tier-1-services \
   --addons=GcpFilestoreCsiDriver

יוצרים כללים של חומת אש כדי לאפשר תקשורת בין צמתים, Pods ושירותים באשכול. בדוגמה הבאה אפשר לראות איך יוצרים כלל חומת אש בשם my-shared-net-rule-2.
```
gcloud compute firewall-rules create my-shared-net-rule-2 \
   --project HOST_PROJECT_ID \
   --network=NETWORK_NAME \
   --allow=tcp,udp \
   --direction=INGRESS \
   --source-ranges=10.0.4.0/22,10.4.0.0/14,10.0.32.0/20
```
בדוגמה, ערכי ה-IP של טווחי המקור מגיעים מהשלב הקודם שבו אימתתם את רשתות המשנה והטווחים המשניים שאפשר להשתמש בהם.

יצירת StorageClass כשמשתמשים במנהל התקן CSI של Filestore עם VPC משותף

בדוגמה הבאה מוסבר איך יוצרים StorageClass כשמשתמשים במנהל התקן CSI של Filestore עם VPC משותף:

cat <<EOF | kubectl apply -f -

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-sharedvpc-example
provisioner: filestore.csi.storage.gke.io
parameters:
  network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
  connect-mode: PRIVATE_SERVICE_ACCESS
  reserved-ip-range: RESERVED_IP_RANGE_NAME
allowVolumeExpansion: true

EOF

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

‫HOST_PROJECT_ID: המזהה או השם של הפרויקט המארח של רשת ה-VPC המשותפת.
‫SHARED_VPC_NAME: השם של רשת ה-VPC המשותפת שיצרתם קודם.
‫RESERVED_IP_RANGE_NAME: השם של טווח כתובות ה-IP השמורות הספציפי שבו רוצים להקצות את מכונת Filestore. השדה הזה אופציונלי. אם מציינים טווח כתובות IP שמורות, צריך לציין טווח כתובות עם שם במקום ערך CIDR ישיר.

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

חיבור מחדש של אמצעי אחסון לשיתוף יחיד ב-Filestore

אם אתם משתמשים ב-Filestore עם רמת HDD בסיסי, SSD בסיסי או Enterprise (שיתוף יחיד), אתם יכולים לפעול לפי ההוראות הבאות כדי לחבר מחדש את מכונות Filestore הקיימות לעומסי העבודה ב-GKE.

כדי למצוא את הפרטים של מכונת Filestore שהוקצתה מראש, פועלים לפי ההוראות במאמר קבלת מידע על מכונה ספציפית.
פורסים מחדש את המפרט של PersistentVolume. בשדה volumeAttributes, משנים את השדות הבאים כך שישתמשו באותם ערכים כמו במכונה של Filestore משלב 1:
- ‫ip: משנים את הערך הזה לכתובת ה-IP של מכונת Filestore שהוקצתה מראש.
- volume: משנים את הערך הזה לשם השיתוף של מכונת Filestore שהוקצתה מראש. ב-claimRef, ודאו שאתם מפנים לאותו PersistentVolumeClaim כמו בשלב 2.
פורסים מחדש את המפרט של PersistentVolumeClaim.
מריצים את הפקודה kubectl get pvc כדי לבדוק את סטטוס הקישור של PersistentVolumeClaim ו-PersistentVolume.
פורסים מחדש את מפרט ה-Pod ומוודאים שה-Pod יכול לגשת שוב ל-Filestore share.

גישה למכונות Filestore באמצעות מנהל התקן Filestore CSI קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

יתרונות

דרישות

רמות שירות, פרוטוקולים וגרסאות GKE נתמכות

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

הפעלת מנהל ההתקן של Filestore CSI באשכול Standard

gcloud

המסוף

השבתת מנהל ההתקן של Filestore CSI

gcloud

המסוף

גישה למכונות קיימות של Filestore באמצעות מנהל התקן ה-CSI של Filestore

יצירת PersistentVolume ו-PersistentVolumeClaim כדי לגשת למכונה

יצירת נפח באמצעות מנהל ההתקן של Filestore CSI

יצירת StorageClass

שימוש ב-PersistentVolumeClaim כדי לגשת לאמצעי האחסון

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

הפניה ל-StorageClass ספציפי

יצירת פריסה שצורכת את אמצעי האחסון

איך משנים באופן דינמי את הביצועים של Filestore באמצעות VolumeAttributesClass

רמות הביצועים שמוגדרות כברירת מחדל

הגדרת רמות ביצועים

יצירת PersistentVolumeClaim עם רמת ביצועים ראשונית

עדכון של PersistentVolumeClaim כדי להשתמש ברמת ביצועים אחרת

הוספת תוויות למכונות של Filestore

שימוש בפרוטוקול מערכת הקבצים NFSv4.1 עם Filestore

שימוש ב-fsgroup עם אמצעי אחסון של Filestore

הגדרת כללי גישה לכתובות IP עם נפחי אחסון ב-Filestore

אפשרויות אבטחה

המלצות

שימוש ב-Filestore עם VPC משותף

הגדרת אשכול עם VPC משותף

הפעלת מנהל ההתקן של Filestore CSI באשכול חדש עם VPC משותף

טייס אוטומטי

רגילה

יצירת StorageClass כשמשתמשים במנהל התקן CSI של Filestore עם VPC משותף

חיבור מחדש של אמצעי אחסון לשיתוף יחיד ב-Filestore

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

גישה למכונות Filestore באמצעות מנהל התקן Filestore CSI