Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

יתרונות

לדרייבר Filestore CSI יש את היתרונות הבאים:

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

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

דרישות

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

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

בטבלה הבאה מפורטים השילובים הנתמכים של רמות שירות, פרוטוקולים וגרסאות 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.

^* בהתאם לגישה לתכונה של מכונות קטנות, טווח הקיבולת הנמוך של מכונות אזוריות ב-Filestore יכול להיות ‎100 GiB עד ‎10,239 GiB או ‎1 TiB עד ‎9.75 TiB. מידע נוסף זמין במאמר בנושא איך יוצרים אירועים קטנים של Filestore.

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

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

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

הפעלת ממשקי API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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 באשכול רגיל

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

כדי להפעיל את ה-driver באשכול קיים מסוג Standard, מבצעים את השלבים הבאים:

gcloud

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

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

המסוף

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

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

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

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

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

אפשר להשבית את מנהל התקן ה-CSI של Filestore באשכול קיים של Autopilot או Standard באמצעות Google Cloud CLI או מסוף 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
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
בקטע תכונות, לצד השדה Filestore CSI driver, לוחצים על Edit Filestore CSI driver.
מבטלים את הסימון של תיבת הסימון Enable Filestore CSI driver.
לוחצים על שמירת השינויים.

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

בקטע הזה מתואר התהליך האופייני לשימוש בנפח אחסון של Kubernetes כדי לגשת למופעי Filestore קיימים באמצעות מנהל התקן Filestore CSI ב-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: ""
  resources:
    requests:
      storage: 1Ti

כדי ליצור את המשאבים 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 שמגובה על ידי מנהל התקן Filestore CSI ב-GKE:

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

יצירת StorageClass

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

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

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

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

kubectl get sc

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

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

שומרים את קובץ המניפסט הבא בשם 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 מכל אזור. לכן, ל-GKE לא צריך להיות מידע על האזור שבו ה-Pod מתוזמן, בניגוד לדיסק מתמשך ב-Compute Engine. אם המאפיין מוגדר ל-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 כשמשתמשים בדרייבר Filestore CSI עם VPC משותף.

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

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

אפשר להשתמש ב-StorageClass שהותקן מראש או ב-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.

כמה פודים יכולים לחלוק את אותו משאב 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. כדי לעקוב אחרי ההתקדמות, מריצים את הפקודה הבאה כדי לבדוק את הסטטוס של ה-PVC:
```
kubectl get pvc
```
אחרי שהקצאת נפח האחסון תסתיים, סטטוס ה-PVC אמור להיות 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. המפתחות והערכים של התוויות המותאמות אישית צריכים לעמוד במוסכמות מתן השמות של התוויות. כדי להחיל תוויות מותאמות אישית על מופע Filestore, אפשר לעיין בדוגמה של מחלקת אחסון ב-Kubernetes.

שימוש בפרוטוקול מערכת קבצים 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-multishare-rwx
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise
  multishare: "true"
  instance-storageclass-label: "enterprise-multishare-rwx"
  protocol: NFS_V4_1
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

אי אפשר לטעון את מופע Filestore באמצעות פרוטוקול NFSv4.1 כשהערך של mountOptions מוגדר ל-nfsvers=3 באובייקט StorageClass.

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

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

הגדרת כללי גישה ל-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 ‏ (Network File System) הוא הפרוטוקול שמשמש את Filestore. המיפוי מתבצע על ידי מיפוי משתמשים במערכות לקוח (GKE Pods) למשתמשים בשרת Filestore. אם קובץ בשרת נמצא בבעלות של משתמש עם מזהה 1003, ולקוח מתחבר עם מזהה משתמש 1003, תהיה לו גישה לקובץ.
Root squashing ו-anonUid:
- ‫Root Squashing ROOT_SQUASH היא תכונת אבטחה שמונעת מלקוחות לגשת למופע Filestore עם הרשאות מלאות של root. כשהאפשרות root squashing מופעלת, משתמשי root במערכות לקוח ממופים למשתמש ללא הרשאות שמוגדר בהגדרה anonUid.
- No Root Squashing ‏ (NO_ROOT_SQUASH) מאפשר ללקוחות לגשת למופע Filestore עם הרשאות מלאות של root. זה נוח להגדרה ראשונית, אבל פחות מאובטח לפעולות רגילות.
הגדרה ראשונית והרשאות: כברירת מחדל, מופע חדש של Filestore נמצא בבעלות מלאה של משתמש הבסיס. אם תפעילו את האפשרות 'החלפת הרשאות של משתמש root' בלי להגדיר קודם הרשאות למשתמשים אחרים, תאבדו את הגישה. לכן, כדי להגדיר גישה למשתמשים ולקבוצות אחרים, צריך לפחות כלל ייצוא אחד של NFS עם NO_ROOT_SQUASH.

המלצות

הגדרה ראשונית: תמיד מתחילים עם לפחות כלל ייצוא אחד של NFS שמציין טווח אדמין עם הרשאות READ_WRITE ומאפשר גישה NO_ROOT_SQUASH. אפשר להשתמש בגישה הזו כדי ליצור ספריות, להגדיר הרשאות ולהקצות בעלות לפי הצורך.
אבטחה: כדי לשפר את האבטחה, מפעילים את האפשרות 'הסרת הרשאות שורש' (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 או אשכול רגיל שמוגדר ל-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

יוצרים כללים של חומת אש כדי לאפשר תקשורת בין הצמתים, קבוצות ה-Pod והשירותים באשכול. בדוגמה הבאה אפשר לראות איך יוצרים כלל חומת אש בשם 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 כשמשתמשים בדרייבר Filestore CSI עם VPC משותף

בדוגמה הבאה אפשר לראות איך יוצרים StorageClass כשמשתמשים בדרייבר Filestore CSI עם 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 עם רמת השירות basic HDD,‏ basic SSD או enterprise (שיתוף יחיד), אתם יכולים לפעול לפי ההוראות האלה כדי להתחבר מחדש למופע Filestore הקיים שלכם לעומסי העבודה ב-GKE.

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

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

יתרונות

דרישות

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

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

הפעלת דרייבר Filestore CSI באשכול רגיל

gcloud

המסוף

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

gcloud

המסוף

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

יצירת PersistentVolume ו-PersistentVolumeClaim כדי לגשת למופע

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

יצירת StorageClass

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

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

שינוי דינמי של ביצועי Filestore באמצעות VolumeAttributesClass

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

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

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

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

הוספת תוויות למופעי Filestore

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

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

הגדרת כללי גישה ל-IP באמצעות נפחי Filestore

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

המלצות

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

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

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

טייס אוטומטי

רגילה

יצירת StorageClass כשמשתמשים בדרייבר Filestore CSI עם VPC משותף

חיבור מחדש של נפחי שיתוף יחיד ב-Filestore

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

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

שינוי דינמי של ביצועי Filestore באמצעות `VolumeAttributesClass`

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

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