OpenStack Cinder CSI-volumenklargører

Niklas Hagman

OpenShift Platform Specialist

Denne vejledning hjælper dig med uden besvær at integrere Cinder CSI Volume Provisioner i din OKD- eller OpenShift-klynge. Den er udformet til at strømline processen, så integrationen bliver sømløs og problemfri.

Desuden er denne vejledning ikke eksklusiv for OpenShift- eller OKD-miljøer; den kan let tilpasses til brug i standard Kubernetes-opsætninger med en enkel ændring. Et centralt højdepunkt for OKD- og OpenShift-brugere er, at der i Helm-chartets templates-mappe er inkluderet ClusterRoleBindings til Security Context Constraints (SCC). Denne vigtige funktion gør det muligt for Cinder CSI-pods at køre med privilegeret adgang, så de følger OpenShifts sikkerhedspraksis og fungerer optimalt inden for din klynges sikkerhedsramme.

Gennem hele denne vejledning guider vi dig trin for trin gennem installationsprocessen med klare instruktioner og nyttige tips, så integrationen bliver en succes. Uanset om du er ny i OpenShift eller en erfaren administrator, har denne vejledning til formål at give dig al den nødvendige information til at forbedre din klynges lagerkapaciteter med Cinder CSI Volume Provisioner.

Opsætning af din Secret til OpenStack-autentificering

At sikre kommunikationen mellem Cinder CSI Volume Provisioner og OpenStack er altafgørende. Brug af et Application Credential muliggør dette ved at levere de nødvendige autentificeringsoplysninger til interaktion med OpenStack-tjenester.

1. Opret et Application Credential

Start med at oprette et nyt Application Credential, der er tilpasset dine behov. Hvis du tidligere har oprettet legitimationsoplysninger, kan du overveje at genbruge dem til Cinder CSI-plugin’et. For at administrere dine legitimationsoplysninger effektivt kan du bruge kommandoen nedenfor til at oprette et nyt sæt eller liste eksisterende:

openstack application credential create <app-cred-name>
openstack application credential list

Efter oprettelsen skal du hente auth_url, Application ID og Application secret for at aktivere OpenStack-godkendelse:

auth_url=$(openstack configuration show -f json | jq .auth_url)

json_output=$(openstack application credential create cinder-csi --format json)
app_id=$(echo $json_output | jq -r '.id')
app_secret=$(echo $json_output | jq -r '.secret')

echo "auth_url: ${auth_url}"
echo "Application ID: ${app_id}"
echo "Application secret: ${app_secret}"

2. Opret et namespace til Storage CSI

Opret et dedikeret namespace til CSI’en for at styrke overblik og sikkerhed:

namespace="csi"
oc create namespace ${namespace}

3. Forbered din cloud-konfiguration

Generer en base64-kodet konfigurationsfil til lagring i en Kubernetes Secret. Denne konfiguration gør det muligt for din applikation at autentificere sig over for OpenStack:

cloud_config="[Global]
auth-url=${auth_url}
application-credential-id=${app_id}
application-credential-secret=${app_secret}"

cloud_config_encoded=$(echo "${cloud_config}" | base64 | tr -d '\n')
echo -e "${cloud_config_encoded}" | base64 -d

4. Udrul den kodede konfiguration som din Secret

Brug dette Kubernetes-manifest til sikkert at gemme dine OpenStack-legitimationsoplysninger i det oprettede namespace:

oc apply -f - <<EOF
kind: Secret
apiVersion: v1
metadata:
  name: cinder-csi-cloud-config
  namespace: ${namespace}
data:
  cloud.conf: ${cloud_config_encoded}
type: Opaque
EOF

Installationsproces

Valg af den korrekte Cinder CSI-volumeprovisioner-version

Match Cinder CSI-provisionerens version med din Kubernetes-version. Hent din Kubernetes-version og oplist de tilgængelige Helm chart-versioner for at sikre kompatibilitet.

Hent din OpenShift-version:

oc version

Client Version: 4.15.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: 4.15.0
Kubernetes Version: v1.28.6+6216ea1

Vis tilgængelige Cinder CSI-versioner:

namespace="${namespace:-csi}"
helm repo -n ${namespace} add cpo https://kubernetes.github.io/cloud-provider-openstack
helm search -n ${namespace} repo cpo/openstack-cinder-csi --versions

Sørg for, at din Kubernetes-version matcher versionen i kolonnen app_version. Når du søger efter en specifik version, skal du huske, at det er Helm chart-versionen, du angiver, ikke Kubernetes-versionen.

helm search -n ${namespace} repo cpo/openstack-cinder-csi --version '~2.28'

Når vi søger efter den rette version, bruger vi tilde-intervalsammenligninger. Tilde-operatoren (~) bruges til patch-niveauintervaller, når en minorversion er angivet, og til major-niveauintervaller, når minor-tallet mangler. I vores eksempel svarer ~2.28 til >= 2.28, < 2.29.

I Chart.yaml skal du opdatere afhængighederne, så der søges efter den samme version.

dependencies:
  - name: openstack-cinder-csi
    version: "~2.28"
    repository: "https://kubernetes.github.io/cloud-provider-openstack"

Opdater afhængigheder

helm dependency update

Hvis du har ændringer, så push dem til dit Git-repository.

Installering af Cinder CSI-volumenklargører

namespace="${namespace:-csi}"
helm install -n ${namespace} cinder-csi .

Kontrollér med oc -n ${namespace} get pods, at du har én controllerplugin-pod og nodeplugin-pods for hver node i din klynge.

oc -n ${namespace} get pods

Du har nu to forskellige lagringsklasser, du kan bruge.

oc get storageclass -o custom-columns=Name:.metadata.name,Provisoner:.provisioner

Test Cinder CSI-volume-provisioner

Test Cinder CSI-volume-provisioner ved at oprette en Persistent Volume Claim og derefter en applikation, der bruger denne PVC.

namespace_test="csi-test"
oc create namespace ${namespace_test}

oc apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-pvc-cinderplugin
  namespace: ${namespace_test}
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-cinder-sc-delete
EOF

oc apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: ${namespace_test}
spec:
  containers:
    - image: docker.io/nginxinc/nginx-unprivileged
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 8080
          protocol: TCP
      volumeMounts:
        - mountPath: /var/lib/www/html
          name: csi-data-cinderplugin
  volumes:
    - name: csi-data-cinderplugin
      persistentVolumeClaim:
        claimName: csi-pvc-cinderplugin
        readOnly: false
EOF

Persistent Volume Claim’en bør være “Bound”, når den er oprettet med succes.

oc -n ${namespace_test} get pvc -o custom-columns=Name:.metadata.name,Status:.status.phase,Volume:.spec.volumeName

Hvis du har problemer, så start med at kigge i events-tabellen med oc -n ${namespace_test} events.

I OpenStack kan du bruge OpenStack CLI til at se dit volumen.

openstack volume show pvc-ed60e725-93e8-447c-bc18-ca33546f2ce8

Til sidst skal du slette din test:

oc delete namespace ${namespace_test}

Opdatering af din installation

Hvis der er opdateringer til Cinder CSI-provisioneren, skal du bruge følgende kommando til at anvende dem:

namespace="${namespace:-csi}"
helm upgrade -n ${namespace} cinder-csi .

Afinstallation

Hvis du skal afinstallere Cinder CSI-provisioneren, skal du køre disse kommandoer:

namespace="${namespace:-csi}"
helm install -n ${namespace} cinder-csi .
oc delete namespace ${namespace}

Ofte stillede spørgsmål

Udfordringen ved at bruge Helms values.yaml til Secrets

Selvom Helm-charts gør det nemt at automatisere udrulninger, inklusive oprettelse af Secrets via values.yaml-filen, medfører denne metode betydelige sikkerhedsudfordringer, især i en GitOps-arbejdsgang med ArgoCD.

For eksempel kan man, når man konfigurerer openstack-cinder-csi-chartet, blive fristet til at indlejre følsomme adgangsoplysninger direkte i values.yaml-filen, således:

openstack-cinder-csi:
  secret:
    enabled: true
    create: true
    name: cinder-csi-cloud-config
    data:
      cloud.conf: |-
        [Global]
        auth-url=<auth_url>
        application-credential-id=<app_id>
        application-credential-secret=<app_secret>        

Denne tilgang fungerer fint til manuelle Helm-installationer. Men i et GitOps-setup, hvor ArgoCD automatisk anvender konfigurationer fra et Git-repo, er det risikabelt at gemme secrets på denne måde. Den primære bekymring er sikkerhed: at lagre følsomme data, såsom adgangsoplysninger, i et Git-repo — selv hvis det er privat — udsætter din infrastruktur for potentielle sikkerhedsbrud.