As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Opções de armazenamento persistente
## O que é um plug-in de volume dentro da árvore versus um plug-in de volume fora da árvore?
Antes da introdução da Container Storage Interface (CSI), todos os plug-ins de volume estavam em árvore, o que significa que eram criados, vinculados, compilados e enviados com os principais binários do Kubernetes e ampliavam a API principal do Kubernetes. Isso significava que adicionar um novo sistema de armazenamento ao Kubernetes (um plug-in de volume) exigia a verificação do código no repositório de código principal do Kubernetes.
Out-of-tree os plug-ins de volume são desenvolvidos independentemente da base de código do Kubernetes e são implantados (instalados) nos clusters do Kubernetes como extensões. Isso dá aos fornecedores a capacidade de atualizar os drivers fora da banda, ou seja, separadamente do ciclo de lançamento do Kubernetes. Isso é amplamente possível porque o Kubernetes criou uma interface de armazenamento ou CSI que fornece aos fornecedores uma maneira padrão de interagir com o k8s.
Você pode conferir mais sobre as classes de armazenamento do Amazon Elastic Kubernetes Services (EKS) e os drivers CSI em https://docs.aws.amazon.com/eks/latest/userguide/storage.html
## In-tree Plugin de volume para Windows
Os volumes do Kubernetes permitem que aplicativos, com requisitos de persistência de dados, sejam implantados no Kubernetes. O gerenciamento de volumes persistentes consiste provisioning/de em: volumes, attaching/detaching um volume, um nó provisioning/resizing do Kubernetes e to/from um volume (contêineres to/from individuais em mounting/dismounting um pod). **O código para implementar essas ações de gerenciamento de volume para um back-end ou protocolo de armazenamento específico é enviado na forma de um plug-in de volume do Kubernetes (plug-ins de volume). In-tree ** No Amazon Elastic Kubernetes Services (EKS), a seguinte classe de plug-ins de volume do Kubernetes é compatível com o Windows:
*In-tree Plug-in de volume:* [aws ElasticBlockStore](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore)
Para usar o plug-in de In-tree volume nos nós do Windows, é necessário criar um adicional StorageClass para usar o NTFS como o FSType. No EKS, o padrão StorageClass usa ext4 como o FSType padrão.
StorageClass A fornece uma forma de os administradores descreverem as “classes” de armazenamento que oferecem. Classes diferentes podem ser mapeadas para níveis de qualidade de serviço, políticas de backup ou políticas arbitrárias determinadas pelos administradores do cluster. O Kubernetes não tem opinião sobre o que as classes representam. Esse conceito às vezes é chamado de “perfis” em outros sistemas de armazenamento.
Você pode verificar isso executando o seguinte comando:
```
kubectl describe storageclass gp2
```
Saída:
```
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:
MountOptions:
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events:
```
Para criar o novo StorageClass para oferecer suporte ao **NTFS**, use o seguinte manifesto:
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: gp2-windows
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
fsType: ntfs
volumeBindingMode: WaitForFirstConsumer
```
Crie o StorageClass executando o seguinte comando:
```
kubectl apply -f NTFSStorageClass.yaml
```
A próxima etapa é criar uma Declaração de Volume Persistente (PVC).
A PersistentVolume (PV) é uma parte do armazenamento no cluster que foi provisionada por um administrador ou provisionada dinamicamente usando PVC. É um recurso no cluster, assim como um nó é um recurso do cluster. Esse objeto de API captura os detalhes da implementação do armazenamento, seja NFS, iSCSI ou um sistema de armazenamento específico do provedor de nuvem.
A PersistentVolumeClaim (PVC) é uma solicitação de armazenamento feita por um usuário. As solicitações podem solicitar tamanhos e modos de acesso específicos (por exemplo, elas podem ser montadas ReadWriteOnce ReadOnlyMany ou ReadWriteMany).
Os usuários precisam PersistentVolumes de atributos diferentes, como desempenho, para diferentes casos de uso. Os administradores de cluster precisam ser capazes de oferecer uma variedade PersistentVolumes que difere em mais formas do que apenas tamanho e modos de acesso, sem expor os usuários aos detalhes de como esses volumes são implementados. Para essas necessidades, existe o StorageClass recurso.
No exemplo abaixo, o PVC foi criado nas janelas do namespace.
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-windows-pv-claim
namespace: windows
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2-windows
resources:
requests:
storage: 1Gi
```
Crie o PVC executando o seguinte comando:
```
kubectl apply -f persistent-volume-claim.yaml
```
O manifesto a seguir cria um Windows Pod, configura o VolumeMount as `C:\Data` e usa o PVC como armazenamento conectado`C:\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'
```
Teste os resultados acessando o pod do Windows por meio de PowerShell:
```
kubectl exec -it podname powershell -n windows
```
Dentro do Windows Pod, execute: `ls`
Saída:
```
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
```
O **diretório de dados** é fornecido pelo volume do EBS.
## Out-of-tree para Windows
O código associado aos plug-ins CSI é fornecido como scripts e binários fora da árvore que normalmente são distribuídos como imagens de contêiner e implantados usando construções padrão do Kubernetes, como e. DaemonSets StatefulSets Os plug-ins CSI lidam com uma ampla variedade de ações de gerenciamento de volume no Kubernetes. Os plug-ins CSI geralmente consistem em plug-ins de nó (que são executados em cada nó como um DaemonSet) e plug-ins de controlador.
Os plug-ins de nós CSI (especialmente aqueles associados a volumes persistentes expostos como dispositivos de bloco ou em um sistema de arquivos compartilhado) precisam realizar várias operações privilegiadas, como varredura de dispositivos de disco, montagem de sistemas de arquivos etc. Essas operações são diferentes para cada sistema operacional host. Para nós de trabalho Linux, os plug-ins de nós CSI em contêineres são normalmente implantados como contêineres privilegiados. Para nós de trabalho do Windows, as operações privilegiadas para plug-ins de nós CSI em contêineres são suportadas usando o [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), um binário autônomo e gerenciado pela comunidade que precisa ser pré-instalado em cada nó do Windows.
[A AMI otimizada para Windows do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) inclui CSI-proxy a partir de abril de 2022. Os clientes podem usar o [driver SMB CSI](https://github.com/kubernetes-csi/csi-driver-smb) nos nós do Windows para acessar o Amazon FSx for [Windows File Server, o Amazon FSx for](https://aws.amazon.com/fsx/windows/) [ONTAP SMB Shares, o AWS and/or [Storage NetApp ](https://aws.amazon.com/storagegateway/file/) Gateway — File](https://aws.amazon.com/fsx/netapp-ontap/) Gateway.
O [blog](https://aws.amazon.com/blogs/modernizing-with-aws/using-smb-csi-driver-on-amazon-eks-windows-nodes/) a seguir tem detalhes de implementação sobre como configurar o SMB CSI Driver para usar o Amazon FSx for Windows File Server como um armazenamento persistente para Windows Pods.
## Amazon FSx para Windows File Server
Uma opção é usar o Amazon FSx for Windows File Server por meio de um recurso SMB [chamado SMB Global](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/persistent-storage) Mapping, que possibilita montar um compartilhamento SMB no host e depois passar os diretórios desse compartilhamento para um contêiner. O contêiner não precisa ser configurado com um servidor, compartilhamento, nome de usuário ou senha específicos. Em vez disso, tudo isso é tratado no host. O contêiner funcionará da mesma forma como se tivesse armazenamento local.
O mapeamento global de pequenas e médias empresas é transparente para o orquestrador e é montado por meio do HostPath qual pode **implicar preocupações seguras**.
No exemplo abaixo, o caminho `G:\Directory\app-state` é um compartilhamento SMB no 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 '