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

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

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

יתרונות

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

  • יש לכם גישה לאחסון NFS מנוהל באופן מלא דרך ממשקי ה-API של Kubernetes (kubectl).

  • אתם יכולים להשתמש במנהל התקן ה-CSI של GKE Filestore כדי להקצות באופן דינמי את ה-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
Zonal (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 אי אפשר להריץ את הפקודות שבמסמך הזה.

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

  • אם אתם רוצים להשתמש ב-Filestore ברשת VPC משותפת, קראו את הוראות ההגדרה הנוספות במאמר שימוש ב-Filestore עם VPC משותף.

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

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

כדי להפעיל את מנהל ההתקן באשכול Standard קיים:

gcloud

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

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

המסוף

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

    כניסה ל-Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

  3. בקטע Features, ליד השדה Filestore CSI driver, לוחצים על Edit Filestore CSI driver.

  4. מסמנים את התיבה Enable Filestore CSI driver.

  5. לוחצים על שמירת השינויים.

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

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

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

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

gcloud

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

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

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

המסוף

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

    כניסה ל-Google Kubernetes Engine

  2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.

  3. בקטע Features, ליד השדה Filestore CSI driver, לוחצים על Edit Filestore CSI driver.

  4. מבטלים את הסימון בתיבה Enable Filestore CSI driver.

  5. לוחצים על שמירת השינויים.

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

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

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

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

  2. כדי ליצור את המשאבים 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

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

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

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

kubectl get sc

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

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

  1. שומרים את המניפסט הבא בתור 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.

  2. כדי ליצור משאב StorageClass על סמך קובץ המניפסט filestore-example-class.yaml, מריצים את הפקודה הבאה:

    kubectl create -f filestore-example-class.yaml

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

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

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

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

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

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

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

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

    kubectl create -f pvc-example.yaml

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

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

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

  1. שומרים את המניפסט הבא בתור 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

  2. כדי ליצור פריסה שמבוססת על קובץ המניפסט filestore-example-deployment.yaml, מריצים את הפקודה הבאה:

    kubectl apply -f filestore-example-deployment.yaml

  3. מוודאים שהפריסה נוצרה בהצלחה:

    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, המערכת מעגלת את הערך באופן אוטומטי למינימום הזה.

  1. שומרים את המניפסט הבא בתור 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"

  2. יוצרים את המשאבים של VolumeAttributesClass:

    kubectl apply -f performance-tiers.yaml

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

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

  1. שומרים את המניפסט הבא בתור 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

  2. יוצרים את ה-PersistentVolumeClaim:

    kubectl apply -f pvc-custom-performance.yaml

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

  1. אם עומס העבודה דורש ביצועים גבוהים יותר, מעדכנים את 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
 ```

  2. מחילים את השינוי:

    kubectl apply -f pvc-custom-performance.yaml

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

  3. בודקים את סטטוס הביצועים:

    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-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. הוא ממפה משתמשים במערכות לקוח (פודים של 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 משותפת, צריך לבצע את השלבים הבאים:

  1. יצירת פרויקט מארח ופרויקט שירות.
  2. מפעילים את Kubernetes Engine API גם בפרויקט המארח וגם בפרויקט השירות.
  3. בפרויקט המארח, יוצרים רשת ורשת משנה.
  4. מפעילים VPC משותף בפרויקט המארח.
  5. בפרויקט המארח, מקצים את קישור התפקיד HostServiceAgent לחשבון השירות של GKE בפרויקט השירות.
  6. מפעילים גישה לשירות פרטי ברשת ה-VPC המשותפת.

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

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

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

    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 │
└──────────────────────┴───────────────┴─────────────────────────────┘

  2. יוצרים אשכול 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

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

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

  2. פורסים מחדש את המפרט של PersistentVolume. בשדה volumeAttributes, משנים את השדות הבאים כך שיהיו בהם אותם ערכים כמו במכונה של Filestore משלב 1:

    • ‫ip: משנים את הערך הזה לכתובת ה-IP של מכונת Filestore שהוקצתה מראש.
    • volume: משנים את הערך הזה לשם השיתוף של מכונת Filestore שהוקצתה מראש. ב-claimRef, חשוב לוודא שאתם מפנים לאותו PersistentVolumeClaim כמו בשלב 2.

  3. פורסים מחדש את המפרט של PersistentVolumeClaim.

  4. מריצים את הפקודה kubectl get pvc כדי לבדוק את סטטוס הקישור של PersistentVolumeClaim ו-PersistentVolume.

  5. פורסים מחדש את מפרט ה-Pod ומוודאים שה-Pod יכול לגשת שוב ל-Filestore share.

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