Os clusters Tanzu Kubernetes Grid, como alguns outros componentes e cargas de trabalho executados em namespaces Supervisor, exigem armazenamento persistente.
Políticas de armazenamento para o cluster Tanzu Kubernetes Grid
Para fornecer recursos de armazenamento persistente aos clusters Tanzu Kubernetes Grid, um administrador do vSphere configura políticas de armazenamento que descrevem diferentes requisitos de armazenamento. O administrador adiciona as políticas de armazenamento ao namespace em que o cluster Tanzu Kubernetes Grid está implantado. As políticas de armazenamento visíveis para o namespace determinam quais repositórios de dados o namespace pode acessar e usar para armazenamento persistente. Eles ditam como os nós de cluster e as cargas de trabalho são colocados no ambiente de armazenamento vSphere.
Com base nas políticas de armazenamento atribuídas ao namespace, vSphere with Tanzu cria classes de armazenamento Kubernetes correspondentes que aparecem automaticamente no namespace. Eles também são propagados para o cluster Tanzu Kubernetes Grid nesse namespace.
No cluster Tanzu Kubernetes Grid, as classes de armazenamento aparecem em duas edições, uma com o modo de associação Immediate e outra com o WaitForFirstConsumer. A edição escolhida pela equipe de DevOps depende dos seus requisitos.
Para obter mais informações sobre classes de armazenamento em clusters Tanzu Kubernetes Grid, consulte Usando classes de armazenamento para volumes persistentes.
Como os clusters do Tanzu Kubernetes Grid se integram ao armazenamento do vSphere
Para se integrar ao armazenamento Supervisor e vSphere, os clusters Tanzu Kubernetes Grid usam o Paravirtual CSI (pvCSI).
O pvCSI é a versão do driver CNS-CSI vSphere modificada para clusters Tanzu Kubernetes Grid. O pvCSI reside no cluster Tanzu Kubernetes Grid e é responsável por todas as solicitações relacionadas ao armazenamento originadas do cluster Tanzu Kubernetes Grid. As solicitações são entregues ao CNS-CSI, que as propaga para o CNS em vCenter Server. Como resultado, o pvCSI não tem comunicação direta com o componente CNS, mas depende do CNS-CSI para quaisquer operações de provisionamento de armazenamento. Ao contrário do CNS-CSI, o pvCSI não requer credenciais de infraestrutura. Ele é configurado com uma conta de serviço no namespace.
Para saber mais sobre os componentes do Supervisor usados para integração com o armazenamento do vSphere, consulte Armazenamento persistente para cargas de trabalho.
Como um volume persistente é criado
O seguinte ilustra como diferentes componentes interagem quando um engenheiro de DevOps realiza uma operação relacionada ao armazenamento no cluster Tanzu Kubernetes Grid, por exemplo, cria uma declaração de volume persistente (PVC).
O engenheiro de DevOps cria um PVC usando a linha de comando no cluster Tanzu Kubernetes Grid. Essa ação gera um PVC correspondente no Supervisor e aciona o CNS-CSI. O CNS-CSI invoca a API de volume de criação do CNS.
Após a criação bem-sucedida de um volume, a operação é propagada de volta por meio de Supervisor para o cluster Tanzu Kubernetes Grid. Como resultado dessa propagação, os usuários podem ver o volume persistente e a declaração de volume persistente no estado vinculado no Supervisor. E eles também veem o volume persistente e a declaração de volume persistente no estado vinculado no cluster Tanzu Kubernetes Grid.
Funcionalidade com suporte do pvCSI
O componente pvCSI que é executado no cluster Tanzu Kubernetes Grid é compatível com vários recursos de armazenamento do vSphere e do Kubernetes.
| Funcionalidade compatível | pvCSI com cluster Tanzu Kubernetes Grid |
|---|---|
| Suporte CNS no vSphere Client | Sim |
| Integridade do objeto aprimorada no vSphere Client | Sim (somente vSAN) |
| Volume persistente de bloco dinâmico (modo de acesso ReadWriteOnce) | Sim |
| Volume persistente de arquivo dinâmico (modo de acesso ReadWriteMany) | Sim (com vSAN Serviços de Arquivo) |
| vSphere Datastore | VMFS/NFS/vSAN/vVols |
| Volume Persistente Estático | Sim |
| Criptografia | Não |
| Expansão de volume offline | Sim |
| Expansão de volume on-line | Sim |
| Topologia de volume e zonas | Sim |
| Várias instâncias de plano de controle do Kubernetes | Sim |
| WaitForFirstConsumer | Sim |
| VolumeHealth | Sim |
