No cenário analisado, os servidores do cluster Red Hat OpenShift consomem volumes de disco através do protocolo Fibre Channel (FC). Já o Red Hat OpenShift como plataforma, utiliza o Operator HPE CSI para criar Persistent Volume Claims (PVCs) do tipo Block via FC (RWO), e do tipo File via NFS (RWX).
Eu não sou afiliado à HP, nem tampouco tenho interesses particulares no assunto. Também não sou especialista em produtos HP. Minha opinião sobre o tema supracitado é neutra, e neste material estou apenas apresentando uma visão técnica dos fatos.
De forma alguma este artigo tem a intenção de manipular opiniões, beneficiar ou denegrir produtos, ou ainda afetar decisões relacionadas a compra de insumos.
Neste laboratório foram utilizadas as seguintes versões de software:
* Red Hat OpenShift 4.14.30
* HPE CSI Operator 2.4.2
* HPE Primera Operating System 4.5.21
A documentação da HP pode ser encontrada aqui. No entanto, já aviso que ela possui inconsistências e gaps, o que dependendo da implementação a ser realizada, podem gerar problemas. Desculpe se isso gera algum desconforto em alguém, mas é a verdade até a presente data.
Para saber mais sobre o Operator HPE CSI, visite sua página.
A propósito, o GIT do projeto pode ser encontrado aqui. Não deixe de ler as ISSUES deste projeto, pois elas contém dicas importantes.
Existem algumas, onde o que mais me incomodou foi a falta de explicações claras sobre determinados itens, além dos erros. Vou citar apenas 1 exemplo de erro, para que esta parte do material não fique muito enfadonha.
Na documentação oficial HP, está escrito para usarmos a porta TCP 8080:
Porém, em outra parte da mesma documentação, está escrito para usar TCP 443:
Curioso, não?
Eu compreendo que nem sempre as pessoas envolvidas em um produto tem tempo de atualizar documentos ou criar KBs (knowledge bases) públicos. Porém, documentação errada é uma questão que atrapalha bastante quem trabalha como arquiteto, consultor ou sysadmin. Especialmente quando tempo disponível é um fator crítico.
A divergência de informação citada acima foi fácil de resolver, bastando apenas analisar como foi feito o deploy do serviço primera3par-csp-svc, identificando assim a porta TCP em uso no POD.
# oc get services -n hpe-storage
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hpe-csi-operator-controller-manager-metrics-service ClusterIP XX.YY.ZZ.KK <none> 8443/TCP 10d
primera3par-csp-svc ClusterIP XX.YY.ZZ.KK <none> 8080/TCP 10d
Mas nem tudo é simples assim…
Antes de seguir com as soluções para problemas comuns, vamos dar uma olhada no operator. Na versão utilizada, ao ser instalado, o operator prepara o ambiente e carrega um Helm Chart, onde este último faz toda a implementação dos recursos necessários.
# oc get all -n hpe-storage
NAME READY STATUS RESTARTS AGE
pod/hpe-csi-controller-746d8f6748-6j68d 9/9 Running 3 (4d23h ago) 4d23h
pod/hpe-csi-node-677tk 2/2 Running 0 4d23h
pod/hpe-csi-node-bwklp 2/2 Running 0 4d23h
pod/hpe-csi-node-f2fdb 2/2 Running 9 (36h ago) 4d23h
pod/hpe-csi-node-f7n8m 2/2 Running 0 4d23h
pod/hpe-csi-node-kbc6d 2/2 Running 0 4d23h
pod/hpe-csi-node-l6nx5 2/2 Running 0 4d23h
pod/hpe-csi-node-m6k78 2/2 Running 0 4d23h
pod/hpe-csi-node-n75z2 2/2 Running 0 4d23h
pod/hpe-csi-node-qv8df 2/2 Running 0 4d23h
pod/hpe-csi-node-r6msx 2/2 Running 0 4d23h
pod/hpe-csi-node-stj5w 2/2 Running 0 4d23h
pod/hpe-csi-node-wm5fb 2/2 Running 0 4d23h
pod/hpe-csi-node-zzftk 2/2 Running 0 4d23h
pod/hpe-csi-operator-controller-manager-585f579bb9-mzwnd 2/2 Running 0 10d
pod/primera3par-csp-55d5db7dcf-s76jp 1/1 Running 0 10d
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/hpe-csi-operator-controller-manager-metrics-service ClusterIP 172.XX.YY.ZZ <none> 8443/TCP 10d
service/primera3par-csp-svc ClusterIP 172.XX.YY.ZZ <none> 8080/TCP 10d
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/hpe-csi-node 13 13 13 13 13 <none> 10d
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/hpe-csi-controller 1/1 1 1 10d
deployment.apps/hpe-csi-operator-controller-manager 1/1 1 1 10d
deployment.apps/primera3par-csp 1/1 1 1 10d
NAME DESIRED CURRENT READY AGE
replicaset.apps/hpe-csi-controller-746d8f6748 1 1 1 4d23h
replicaset.apps/hpe-csi-controller-76f8c46d98 0 0 0 10d
replicaset.apps/hpe-csi-operator-controller-manager-585f579bb9 1 1 1 10d
replicaset.apps/primera3par-csp-55d5db7dcf 1 1 1 10d
Por sua vez, quando o serviço NFS é ativado em um segundo momento, seus recursos são outros, e utilizam um namespace diferente.
# oc get all -n hpe-nfs
NAME READY STATUS RESTARTS AGE
pod/hpe-nfs-6ccb97de-wwxlc 1/1 Running 0 5d2h
pod/hpe-nfs-cfa86445-7rdg9 1/1 Running 0 5d3h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/hpe-nfs-6ccb97de-7100-439e ClusterIP XX.YY.ZZ.KK <none> 49000/TCP,2049/TCP,2049/UDP,32803/TCP,32803/UDP,20048/TCP,20048/UDP,111/TCP,111/UDP,662/TCP,662/UDP,875/TCP,875/UDP 5d2h
service/hpe-nfs-cfa86445-46ee-42cf ClusterIP XX.YY.ZZ.KK <none> 49000/TCP,2049/TCP,2049/UDP,32803/TCP,32803/UDP,20048/TCP,20048/UDP,111/TCP,111/UDP,662/TCP,662/UDP,875/TCP,875/UDP 5d3h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/hpe-nfs-6ccb97de-7100-439e-8d05-355724b2b844 1/1 1 1 5d2h
deployment.apps/hpe-nfs-cfa86445-46ee-42cf-bf4b-74a3208f3fb8 1/1 1 1 5d3h
NAME DESIRED CURRENT READY AGE
replicaset.apps/hpe-nfs-6ccb97de-7100-439e-8d05-355724b2b844-6cc696b949 1 1 1 5d2h
replicaset.apps/hpe-nfs-cfa86445-46ee-42cf-bf4b-74a3208f3fb8-ccc694958 1 1 1 5d3h
É importante saber quais componentes foram criados durante a instalação do operator, pois isso é fundamental para análise dos problemas.
Agora a parte que provavelmente você estava esperando. Irei listar aqui todos os erros que encontrei, até finalmente conseguir utilizar com sucesso o Storage HP Primera.
StorageClass:
failed to provision volume with StorageClass "hpe-standard": rpc error: code = Aborted desc = There is already an operation pending for the specified id CreateVolume:pvc-ec2b
Storage Authentication:
level=error msg="Allowing panic to escape" file="csp_manager.go:50" level=info msg="[ REQUEST-ID 100177 ] -- <<<<< createArraySession" file="panic.go:884" http: panic serving X.X.X.X:51022: &{[] 1000 unable to connect to X.X.X.X: dial tcp X.X.X.X:22: connect: connection timed out
Service Account:
level=error msg="Failed to delete node yyyyyyyyyy - hpenodeinfos.storage.hpe.com \"yyyyyyyyyy\" is forbidden: User \"system:serviceaccount:hpe-storage:hpe-csi-node-sa\" cannot delete resource \"hpenodeinfos\" in API group \"storage.hpe.com\" at the cluster scope" file="flavor.go:321"
level=error msg="Error obtaining node info by uuid xceg7621- Get \"https://XX.XX.XX.XX:443/apis/storage.hpe.com/v1/hpenodeinfos\": dial tcp XX.XX.XX.XX:443: i/o timeout\n" file="flavor.go:193"
Antes de qualquer coisa, é importante informar algo neste ítem. Diferentemente de outras soluções NFS enterprise que utilizei, onde o storage em si fornecia um serviço NFS centralizado, aqui isso não acontece.
Volumes NFS fornecidos pelo HPE CSI são entregues através de um POD standalone que executa um contêiner NFS Server, criado especificamente para a entrega do volume RWX solicitado.
Ou seja, cada volume RWX criado terá seu próprio POD rodando um serviço NFS. Este POD por sua vez, possuirá um volume RWO de uso exclusivo.
Dependendo da carga de trabalho, talvez esta não seja a solução mais escalável e redundante possível, porém é assim que o produto HP Primera funciona.
🟢 Dica: Para expandir um volume NFS do HPE CSI, será necessário expandir o volume RWO referente ao POD que está fornecendo o serviço NFS para o namespace, e não o volume NFS diretamente.
🔴 AVISO: No momento em que escrevi este material, existia um limite de 32 volumes NFS por node do cluster OpenShift/Kubernetes. É importante considerar esta informação, pois este detalhe pode causar impactos quando múltiplas aplicações estiverem solicitando volumes RWX.
Agora vamos aos erros comuns referentes à volumes NFS:
Internal Server Error:
connection.go:252] GRPC error: rpc error: code = Internal desc = Failed to add ACL to volume pvc-fd1xxx for node &{ yyyyyyyyyy fcef9324-dbcb-186f-709a-ca1834942843 [0xc0005a3840] [0xc0005a3880 0xc0005a3890 0xc0005a38a0 0xc0005a38b0] [0xc0005a38c0 0xc0005a38d0] } via CSP, err: Request failed with status code 500 and errors Error code (Internal Server Error) and message (VLUN creation error: failed to find any ready target port on array XX.XX.XX.XX)
csi_handler.go:234] Error processing "csi-12f7d8c840b4759988": failed to attach: rpc error: code = Internal desc = Failed to add ACL to volume pvc-fd1xxx for node &{ yyyyyyyyyy fd1xxx-2843 [0xc0005a3840] [0xc0005a3880 0xc0005a3890 0xc0005a38a0 0xc0005a38b0] [0xc0005a38c0 0xc0005a38d0] } via CSP, err: Request failed with status code 500 and errors Error code (Internal Server Error) and message (VLUN creation error: failed to find any ready target port on array XX.XX.XX.XX)
FailedAttachVolume:
Warning FailedAttachVolume pod/hpe-nfs-e13575db-zdv4v AttachVolume.Attach failed for volume "pvc-8ebf57-c9f6" : rpc error: code = Internal desc = Failed to add ACL to volume pvc-8ebf57-c9f6 for node &{ yyyyyyyyyy 0bd8957e-9323 [0xc000f26a00] [0xc000f26a40 0xc000f26a50 0xc000f26a60 0xc000f26a70] [0xc000f26a80 0xc000f26a90] } via CSP, err: Request failed with status code 500 and errors Error code (Internal Server Error) and message (VLUN creation error: failed to find any ready target port on array XX.XX.XX.XX)
FailedMount:
Warning FailedMount pod/hpe-nfs-e13575db-zzdln Unable to attach or mount volumes: unmounted volumes=[hpe-nfs-e13575d-d21042f], unattached volumes=[hpe-nfs-e13575d-d21042f], failed to process volumes=[]: timed out waiting for the condition
ProvisioningFailed:
Warning ProvisioningFailed persistentvolumeclaim/my-rwx-nfs failed to provision volume with StorageClass "hpe-nfs": rpc error: code = DeadlineExceeded desc = context deadline exceeded
ProvisionStorage:
Warning ProvisionStorage persistentvolumeclaim/my-rwx-nfs gave up waiting for deployment hpe-nfs-e13575d-3d21042f to be available
Warning ProvisionStorage persistentvolumeclaim/my-rwx-nfs rollback of an existing pvc hpe-nfs-e13575d-3d21042f is under progress
Permission denied:
Volume NFS monta, mas dá acesso negado ao tentar gravar arquivos.
sh-4.4$ echo 1 > /my-first-nfs/ok
sh: /my-first-nfs/ok: Permission denied
😓 Como você pode perceber, foram muitos os problemas enfrentados. Será mesmo que o storage funciona? Estaria quebrado?
O primeiro passo para solucionar qualquer problema, é obter o máximo de informação possível nos logs disponíveis.
A HP sugere a utilização de comandos como os abaixo para obtenção de logs.
$ kubectl logs daemonset.apps/hpe-csi-node hpe-csi-driver -n hpe-storage
$ kubectl logs deployment.apps/hpe-csi-controller hpe-csi-driver -n hpe-storage
Embora estas sugestões ajudem, serão necessárias ainda mais informações.
Este script não é nada elegante, ou algo que eu possa me orgulhar. São apenas alguns comandos empilhados, para obter de uma só vez todas as informações necessárias para análise dos problemas. Use ele como base, e faça as alterações que forem pertinentes a seu ambiente.
#!/bin/bash
echo "--------------------"
echo "| HPE-STORAGE LOGS |"
echo "--------------------"
oc logs -n hpe-storage daemonset.apps/hpe-csi-node --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage deployment.apps/hpe-csi-controller --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage deployment.apps/hpe-csi-operator-controller-manager --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage deployment.apps/nimble-csp --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage deployment.apps/primera3par-csp --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage service/alletra6000-csp-svc --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage service/alletra9000-csp-svc --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage service/alletrastoragemp-csp-svc --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage service/hpe-csi-operator-controller-manager-metrics-service --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage service/nimble-csp-svc --all-containers=true
echo; echo; echo; echo
oc logs -n hpe-storage service/primera3par-csp-svc --all-containers=true
echo; echo; echo; echo
PODs=$(oc get pods -n hpe-storage -o custom-columns=POD:.metadata.name --no-headers)
for X in $PODs
do
oc logs -n hpe-storage pod/$X --all-containers=true
done
echo; echo; echo; echo
RSs=$(oc get replicaset -n hpe-storage -o custom-columns=POD:.metadata.name --no-headers)
for Y in $RSs
do
oc logs -n hpe-storage replicaset.apps/$Y
done
echo; echo; echo; echo
echo "CSI LOGS FROM NODE:"
ssh -i /root/xxxxx/id_rsa_xxxxx core@yyyyy "cat /var/log/hpe-csi-node.log"
echo; echo; echo; echo
echo "----------------"
echo "| HPE-NFS LOGS |"
echo "----------------"
oc get pv | grep hpe-nfs
echo
oc get pvc -n hpe-nfs
echo
oc get pvc -ntesting
echo
PODs=$(oc get pods -n hpe-nfs -o custom-columns=POD:.metadata.name --no-headers)
for X in $PODs
do
oc logs -n hpe-nfs pod/$X --all-containers=true
done
echo; echo; echo; echo
oc get events -n hpe-nfs
echo; echo; echo; echo
oc -n testing get pvc my-rwx-nfs -o yaml
echo; echo; echo; echo
oc get events -n testing
Ao coletar todos estes logs de uma vez, ficou um pouco mais clara a correlação dos eventos, e quais processos estavam acontecendo nas operações de solicitação de volumes persistentes.
Eu não sou nenhum especialista em produtos HP, então talvez tenha um jeito mais simples de fazer o debug. Esta foi apenas a forma que encontrei para conseguir os dados que eu precisava.
Neste tópico irei apresentar os templates YAML que utilizei para fazer a inegração com sucesso, pontuando nos mesmos alguns itens importantes que fizeram com que os volumes de storage pudessem efetivamente ser utilizados.
Em alguns momentos precisei fazer a leitura dos códigos .golang com a finalidade de entender se um item específico estava mal documentado, ou para descobrir como parametrizar algumas configurações adequadamente. Por isso, talvez meus templates sejam um pouco diferentes dos encontrados nos canais tradicionais.
Também irei mostrar alguns comandos que podem ser utilizados para rastrear os privilégios que uma Service Account (SA) necessita, e como ajustar as Security Context Constraints (SCC) para esta SA.
⚠️ Não tenho a intenção aqui de dizer que a forma com a qual obtive sucesso é a mais correta ou algo nesse sentido. O que apresento aqui é uma solução que funcionou para o meu caso específico. Minha recomendação é que sempre procure o suporte oficial de qualquer produto, antes de implementar soluções encontradas na internet. No meu caso, o SLA do suporte da HP não atendia os requisitos de tempo do projeto, então precisei colocar a mão na massa para encontrar soluções.
A configuração de backend se refere a como o OpenShift irá se comunicar com o storage HPE Primera.
Um exemplo do template completo pode ser visualizado abaixo.
# cat hpe-backend-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: hpe-backend
namespace: hpe-storage
stringData:
serviceName: primera3par-csp-svc
servicePort: "8080"
backend: YOUR_STORAGE_IP
username: YOUR_STORAGE_LOGIN
password: YOUR_STORAGE_PASSWORD
Na configuração do driver, deixe ativado apenas o modelo de storage que está em uso (no caso, o modelo é Primera).
No meu cenário, também foi necessário declarar backendType: primera.
Um exemplo do template completo pode ser visualizado abaixo.
# cat hpe-csi-driver.yaml
apiVersion: storage.hpe.com/v1
kind: HPECSIDriver
metadata:
name: hpecsidriver
namespace: hpe-storage
spec:
csp:
affinity: {}
labels: {}
nodeSelector: {}
tolerations: []
node:
affinity: {}
labels: {}
nodeSelector: {}
tolerations: []
disable:
alletra6000: true <--- SUPPORT DISABLED
alletra9000: true <--- SUPPORT DISABLED
alletraStorageMP: true <--- SUPPORT DISABLED
nimble: true <--- SUPPORT DISABLED
primera: false
iscsi:
chapPassword: ''
chapUser: ''
controller:
affinity: {}
labels: {}
nodeSelector: {}
tolerations: []
disableNodeConfiguration: false
disableNodeConformance: false
disableNodeGetVolumeStats: false
imagePullPolicy: IfNotPresent
kubeletRootDir: /var/lib/kubelet/
logLevel: warn
registry: quay.io
backendType: primera
Os parâmetros a seguir precisaram ser ajustados:
- cpg: “SSD_r6”
- hostSeesVLUN: “true”
- reclaimPolicy: Delete
- allowVolumeExpansion: true
- allowOverrides: description,accessProtocol
O CPG pode ser consultado direto no storage Primera.
$ primera cli% showvv
-Rsvd(MiB)- --(MiB)--
Id Name Prov Compr Dedup Type CopyOf BsId Rd -Detailed_State- Snp Usr VSize
2 .mgmtdata full NA NA base --- 2 RW normal 0 524288 524288
3 .shared.SSD_r6_0 dds NA NA base --- 3 RW normal 0 1024 67108864
(...)
Um exemplo do template completo pode ser visualizado abaixo.
# cat hpe-sc-fc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
name: hpe-standard
provisioner: csi.hpe.com
parameters:
csi.storage.k8s.io/fstype: xfs
csi.storage.k8s.io/controller-expand-secret-name: hpe-backend
csi.storage.k8s.io/controller-expand-secret-namespace: hpe-storage
csi.storage.k8s.io/controller-publish-secret-name: hpe-backend
csi.storage.k8s.io/controller-publish-secret-namespace: hpe-storage
csi.storage.k8s.io/node-publish-secret-name: hpe-backend
csi.storage.k8s.io/node-publish-secret-namespace: hpe-storage
csi.storage.k8s.io/node-stage-secret-name: hpe-backend
csi.storage.k8s.io/node-stage-secret-namespace: hpe-storage
csi.storage.k8s.io/provisioner-secret-name: hpe-backend
csi.storage.k8s.io/provisioner-secret-namespace: hpe-storage
description: "Volume created by the HPE CSI Driver for Kubernetes"
accessProtocol: fc
cpg: "SSD_r6"
hostSeesVLUN: "true"
reclaimPolicy: Delete
allowVolumeExpansion: true
allowOverrides: description,accessProtocol
Este foi um dos itens mais problemáticos, pois ao passo que um problema se resolvia, outro aparecia. Por fim, foi possível obter uma combinação funcional de parâmetros de configuração.
A HP recomenda usar formatação EXT4 para volumes NFS.
Feitas as devidas ressalvas, os parâmetros a seguir precisaram ser ajustados:
- csi.storage.k8s.io/fstype: ext4
- cpg: “SSD_r6”
- accessProtocol: fc
- hostSeesVLUN: “true”
- nfsResources: “true”
- fsMode: “775”
- allowOverrides: description,nfsNamespace
- allowMutations: description,nfsNamespace
- reclaimPolicy: Delete
- volumeBindingMode: Immediate
- allowVolumeExpansion: false
Um exemplo do template completo pode ser visualizado abaixo.
# cat hpe-sc-nfs.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: hpe-nfs
annotations:
storageclass.kubernetes.io/is-default-class: "no"
provisioner: csi.hpe.com
parameters:
csi.storage.k8s.io/controller-expand-secret-name: hpe-backend
csi.storage.k8s.io/controller-expand-secret-namespace: hpe-storage
csi.storage.k8s.io/controller-publish-secret-name: hpe-backend
csi.storage.k8s.io/controller-publish-secret-namespace: hpe-storage
csi.storage.k8s.io/node-publish-secret-name: hpe-backend
csi.storage.k8s.io/node-publish-secret-namespace: hpe-storage
csi.storage.k8s.io/node-stage-secret-name: hpe-backend
csi.storage.k8s.io/node-stage-secret-namespace: hpe-storage
csi.storage.k8s.io/provisioner-secret-name: hpe-backend
csi.storage.k8s.io/provisioner-secret-namespace: hpe-storage
description: "NFS backend volume created by the HPE CSI Driver for Kubernetes"
csi.storage.k8s.io/fstype: ext4
cpg: "SSD_r6"
accessProtocol: fc
hostSeesVLUN: "true"
nfsResources: "true"
fsMode: "775"
allowOverrides: description,nfsNamespace
allowMutations: description,nfsNamespace
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: false
Se tudo correr bem, volumes NFS RWX poderão ser utilizados para suas aplicações.
Tipicamente, um deployment de um serviço, igualmente utiliza uma conta de serviço.
⛔️ AVISO: Caso nos seus logs não existam erros do tipo is forbidden: User, NÃO EXECUTE OS PASSOS ABAIXO.
Quais privilégios são necessários?
Para encontrar os privilégios necessários para um determinado deployment, utilize os passos a seguir.
⚠️ Nota: O ideal é criar uma política customizada, que contenha exatamente os privilégios necessários, nos componentes onde se fizer necessário. Caso isso não seja possível, siga com os exemplos abaixo.
1) Utilize o scc-subject-review para encontrar o nível de privilégio necessário que a conta de serviço utilizada no deployment precisa para realizar suas funções.
$ oc get deployment primera3par-csp -o yaml | oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Deployment/primera3par-csp privileged
2) Verifique qual a conta de serviço está sendo utilizada neste deployment:
$ oc describe deployment primera3par-csp | grep Account
Service Account: hpe-csp-sa
3) Atribua o privilégio necessário para a conta de serviço.
$ oc adm policy add-scc-to-user privileged -z hpe-csp-sa
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:privileged added: "hpe-csp-sa"
Caso os erros ainda persistam nos logs e os volumes não possam ser utilizados, siga investigando outros deployments realizados pelo operator HPE CSI.
Exemplo:
$ oc get deployment hpe-csi-controller -o yaml | oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Deployment/hpe-csi-controller privileged
$ oc describe deployment hpe-csi-controller | grep Account
Service Account: hpe-csi-controller-sa
$ oc get deployment hpe-csi-operator-controller-manager -o yaml | oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Deployment/hpe-csi-operator-controller-manager anyuid
1) Seguindo a mesma lógica, utilize o scc-subject-review para encontrar o nível de privilégio necessário que a conta do serviço NFS precisa.
$ oc -n hpe-nfs get deployment.apps/hpe-nfs-9e44f5e6-2c43-4863-95f6-298f30cb1149 -o yaml | oc adm policy scc-subject-review -f -
RESOURCE ALLOWED BY
Deployment/hpe-nfs-9e44f5e6-2c43-4863-95f6-298f30cb1149 privileged
2) Encontre a conta de serviço que executa o serviço NFS:
$ oc -n hpe-nfs get deployment.apps/hpe-nfs-9e44f5e6-2c43-4863-95f6-298f30cb1149 -o yaml | grep -i account
serviceAccount: hpe-csi-nfs-sa
serviceAccountName: hpe-csi-nfs-sa
3) Atribua o privilégio necessário a conta de serviço:
$ oc adm policy add-scc-to-user privileged -z hpe-csi-nfs-sa
Espero que estas dicas ajudem a quem estiver passando pelas mesmas dificuldades que passei a resolverem seus problemas, e assim evitar atrasos em seus projetos. O Storage HP Primera é um produto interessante e flexível, que possui um jeito peculiar de trabalhar algumas funções. Isso pode causar alguma estranheza em sysadmins mais conservadores, porém nada que não possa ser aprendido e aproveitado.
Gostou do conteúdo? Dê uma olhada nesses outros artigos interessantes! 🔥
Apoie este conteúdo clicando em um dos banners de nossos anunciantes. ❤️