Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Opsi penyimpanan persisten

Apa yang dimaksud dengan plugin volume in-tree vs. out-tree?

Sebelum pengenalan Container Storage Interface (CSI), semua plugin volume berada di dalam pohon yang berarti mereka dibangun, ditautkan, dikompilasi, dan dikirim dengan binari inti Kubernetes dan memperluas inti Kubernetes API. Ini berarti bahwa menambahkan sistem penyimpanan baru ke Kubernetes (plugin volume) memerlukan pemeriksaan kode ke dalam repositori kode Kubernetes inti.

Out-of-tree Plugin volume dikembangkan secara independen dari basis kode Kubernetes, dan digunakan (diinstal) pada cluster Kubernetes sebagai ekstensi. Ini memberi vendor kemampuan untuk memperbarui driver di luar band, yaitu terpisah dari siklus rilis Kubernetes. Hal ini sebagian besar dimungkinkan karena Kubernetes telah menciptakan antarmuka penyimpanan atau CSI yang menyediakan vendor cara standar untuk berinteraksi dengan k8s.

Anda dapat memeriksa lebih lanjut tentang kelas penyimpanan Amazon Elastic Kubernetes Services (EKS) dan Driver CSI di https://docs.aws.amazon.com/eks/latest/userguide/storage.html

In-tree Plugin Volume untuk Windows

Volume Kubernetes memungkinkan aplikasi, dengan persyaratan persistensi data, untuk digunakan di Kubernetes. Pengelolaan volume persist attaching/detaching en terdiri provisioning/resizing dari provisioning/de - volume, volume node Ku to/from bernetes, dan volume mounting/dismounting wadah to/from individu dalam pod. Kode untuk menerapkan tindakan manajemen volume ini untuk back-end atau protokol penyimpanan tertentu dikirimkan dalam bentuk plugin volume Kubernetes (In-tree Plugin Volume). Di Amazon Elastic Kubernetes Services (EKS) kelas plugin volume Kubernetes berikut didukung di Windows:

In-tree Plugin Volume: aws ElasticBlockStore

Untuk menggunakan plugin In-tree volume pada node Windows, perlu untuk membuat tambahan StorageClass untuk menggunakan NTFS sebagai FsType. Pada EKS, default StorageClass menggunakan ext4 sebagai FsType default.

A StorageClass menyediakan cara bagi administrator untuk menggambarkan “kelas” penyimpanan yang mereka tawarkan. Kelas yang berbeda mungkin dipetakan ke tingkat kualitas layanan, kebijakan cadangan, atau kebijakan sewenang-wenang yang ditentukan oleh administrator cluster. Kubernetes tidak berpendapat tentang apa yang diwakili oleh kelas. Konsep ini kadang-kadang disebut “profil” di sistem penyimpanan lain.

Anda dapat memeriksanya dengan menjalankan perintah berikut:

kubectl describe storageclass gp2

Output:

Name:            gp2
IsDefaultClass:  Yes
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClas
","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"name":"gp2"},"parameters":{"fsType"
"ext4","type":"gp2"},"provisioner":"kubernetes.io/aws-ebs","volumeBindingMode":"WaitForFirstConsumer"}
,storageclass.kubernetes.io/is-default-class=true
Provisioner:           kubernetes.io/aws-ebs
Parameters:            fsType=ext4,type=gp2
AllowVolumeExpansion:  <unset>
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     WaitForFirstConsumer
Events:                <none>

Untuk membuat yang baru StorageClass untuk mendukung NTFS, gunakan manifes berikut:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gp2-windows
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ntfs
volumeBindingMode: WaitForFirstConsumer

Buat StorageClass dengan menjalankan perintah berikut:

kubectl apply -f NTFSStorageClass.yaml

Langkah selanjutnya adalah membuat Persistent Volume Claim (PVC).

A PersistentVolume (PV) adalah bagian penyimpanan di cluster yang telah disediakan oleh administrator atau disediakan secara dinamis menggunakan PVC. Ini adalah sumber daya di cluster seperti node adalah sumber daya cluster. Objek API ini menangkap detail implementasi penyimpanan, baik itu NFS, iSCSI, atau sistem penyimpanan khusus penyedia cloud.

A PersistentVolumeClaim (PVC) adalah permintaan penyimpanan oleh pengguna. Klaim dapat meminta ukuran dan mode akses tertentu (misalnya, mereka dapat dipasang ReadWriteOnce, ReadOnlyMany atau ReadWriteMany).

Pengguna membutuhkan PersistentVolumes atribut yang berbeda, seperti kinerja, untuk kasus penggunaan yang berbeda. Administrator cluster harus dapat menawarkan berbagai PersistentVolumes yang berbeda dalam lebih banyak cara daripada hanya ukuran dan mode akses, tanpa mengekspos pengguna pada detail tentang bagaimana volume tersebut diimplementasikan. Untuk kebutuhan ini, ada StorageClass sumber daya.

Dalam contoh di bawah ini, PVC telah dibuat dalam jendela namespace.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-windows-pv-claim
  namespace: windows
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp2-windows
  resources:
    requests:
      storage: 1Gi

Buat PVC dengan menjalankan perintah berikut:

kubectl apply -f persistent-volume-claim.yaml

Manifes berikut membuat Pod Windows, mengatur VolumeMount as C:\Data dan menggunakan PVC sebagai penyimpanan terlampirC:\Data.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: windows-server-ltsc2019
  namespace: windows
spec:
  selector:
    matchLabels:
      app: windows-server-ltsc2019
      tier: backend
      track: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: windows-server-ltsc2019
        tier: backend
        track: stable
    spec:
      containers:
      - name: windows-server-ltsc2019
        image: mcr.microsoft.com/windows/servercore:ltsc2019
        ports:
        - name: http
          containerPort: 80
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "C:\\data"
          name: test-volume
      volumes:
        - name: test-volume
          persistentVolumeClaim:
            claimName: ebs-windows-pv-claim
      nodeSelector:
        kubernetes.io/os: windows
        node.kubernetes.io/windows-build: '10.0.17763'

Uji hasilnya dengan mengakses pod Windows melalui PowerShell:

kubectl exec -it podname powershell -n windows

Di dalam Windows Pod, jalankan: ls

Output:

PS C:\> ls


    Directory: C:\


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----          3/8/2021   1:54 PM                data
d-----          3/8/2021   3:37 PM                inetpub
d-r---          1/9/2021   7:26 AM                Program Files
d-----          1/9/2021   7:18 AM                Program Files (x86)
d-r---          1/9/2021   7:28 AM                Users
d-----          3/8/2021   3:36 PM                var
d-----          3/8/2021   3:36 PM                Windows
-a----         12/7/2019   4:20 AM           5510 License.txt

Direktori data disediakan oleh volume EBS.

Out-of-tree untuk Windows

Kode yang terkait dengan plugin CSI dikirimkan sebagai skrip dan binari di luar pohon yang biasanya didistribusikan sebagai gambar kontainer dan diterapkan menggunakan konstruksi Kubernetes standar seperti dan. DaemonSets StatefulSets Plugin CSI menangani berbagai tindakan manajemen volume di Kubernetes. Plugin CSI biasanya terdiri dari plugin node (yang berjalan pada setiap node sebagai a DaemonSet) dan plugin pengontrol.

Plugin node CSI (terutama yang terkait dengan volume persisten yang diekspos sebagai perangkat blok atau melalui sistem file bersama) perlu melakukan berbagai operasi istimewa seperti pemindaian perangkat disk, pemasangan sistem file, dll. Operasi ini berbeda untuk setiap sistem operasi host. Untuk node pekerja Linux, plugin node CSI yang dikontainer biasanya digunakan sebagai wadah istimewa. Untuk node pekerja Windows, operasi istimewa untuk plugin node CSI yang dikontainer didukung menggunakan csi-proxy, biner mandiri yang dikelola komunitas yang perlu diinstal sebelumnya pada setiap node Windows.

Amazon EKS Windows AMI yang Dioptimalkan termasuk CSI-proxy mulai April 2022. Pelanggan dapat menggunakan Driver SMB CSI di node Windows untuk mengakses Amazon FSx untuk Windows File Server, Amazon FSx untuk NetApp ONTAP SMB Shares, and/or AWS Storage Gateway — File Gateway.

Blog berikut memiliki rincian implementasi tentang cara mengatur SMB CSI Driver untuk menggunakan Amazon FSx untuk Windows File Server sebagai penyimpanan persisten untuk Windows Pod.

Amazon FSx for Windows File Server

Pilihannya adalah menggunakan Amazon FSx untuk Windows File Server melalui fitur SMB yang disebut SMB Global Mapping yang memungkinkan untuk memasang berbagi SMB di host, kemudian meneruskan direktori pada share itu ke dalam wadah. Wadah tidak perlu dikonfigurasi dengan server, berbagi, nama pengguna, atau kata sandi tertentu - itu semua ditangani di host sebagai gantinya. Wadah akan bekerja sama seperti jika memiliki penyimpanan lokal.

Dalam contoh di bawah ini, jalur G:\Directory\app-state nya adalah berbagi SMB pada Windows Node.

apiVersion: v1
kind: Pod
metadata:
  name: test-fsx
spec:
  containers:
  - name: test-fsx
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command:
      - powershell.exe
      - -command
      - "Add-WindowsFeature Web-Server; Invoke-WebRequest -UseBasicParsing -Uri 'https://dotnetbinaries.blob.core.windows.net/servicemonitor/2.0.1.6/ServiceMonitor.exe' -OutFile 'C:\\ServiceMonitor.exe'; echo '<html><body><br/><br/><marquee><H1>Hello EKS!!!<H1><marquee></body><html>' > C:\\inetpub\\wwwroot\\default.html; C:\\ServiceMonitor.exe 'w3svc'; "
    volumeMounts:
      - mountPath: C:\dotnetapp\app-state
        name: test-mount
  volumes:
    - name: test-mount
      hostPath:
        path: G:\Directory\app-state
        type: Directory
  nodeSelector:
      beta.kubernetes.io/os: windows
      beta.kubernetes.io/arch: amd64

Blog berikut memiliki rincian implementasi tentang cara mengatur Amazon FSx untuk Windows File Server sebagai penyimpanan persisten untuk Windows Pod.