OpenStack Cinder CSI-volumklargjører

Niklas Hagman

OpenShift Platform Specialist

Denne veiledningen er laget for å hjelpe deg med å integrere Cinder CSI Volume Provisioner i OKD- eller OpenShift-klyngen din på en enkel måte. Den er utformet for å gjøre prosessen smidig, slik at integrasjonen blir sømløs og problemfri.

Veiledningen er dessuten ikke eksklusiv for OpenShift- eller OKD-miljøer; den kan enkelt tilpasses for bruk i et ren- (vanilla) Kubernetes-oppsett med en liten endring. Et viktig høydepunkt for OKD- og OpenShift-brukere er at Helm-chartets templates-katalog inkluderer Security Context Constraints (SCC) klyngerollebindinger. Denne kritiske funksjonen gjør at Cinder CSI pod-er kan kjøres med privilegert tilgang, i tråd med OpenShifts sikkerhetspraksis, og sikrer optimal funksjonalitet innenfor klyngens sikkerhetsrammeverk.

Gjennom denne veiledningen går vi trinn for trinn gjennom installasjonen, med klare instruksjoner og nyttige tips for å sikre en vellykket integrasjon. Enten du er ny i OpenShift eller en erfaren administrator, er målet å gi deg all nødvendig informasjon for å forbedre klyngens lagringskapabiliteter med Cinder CSI Volume Provisioner.

Konfigurere Secret for OpenStack-autentisering

Å sikre kommunikasjonen mellom Cinder CSI Volume Provisioner og OpenStack er avgjørende. Bruk av en applikasjonslegitimasjon gjør dette enklere ved å gi nødvendige autentiseringsdetaljer for interaksjon med OpenStack-tjenester.

1. Opprette en applikasjonslegitimasjon

Opprett en ny applikasjonslegitimasjon tilpasset dine behov. Hvis du tidligere har generert legitimasjoner, kan du vurdere å gjenbruke dem for Cinder CSI-tillegget. For å administrere legitimasjonene dine effektivt, bruk kommandoen nedenfor for å opprette et nytt sett eller liste opp eksisterende:

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

Når den er opprettet, hent ut auth_url, Application ID og Application secret for å aktivere OpenStack-autentisering:

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. Opprett et navnerom for lagrings-CSI

Opprett et dedikert navnerom for CSI for bedre oversikt og sikkerhet:

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

3. Forbered skykonfigurasjonen din

Generer en konfigurasjonsfil kodet i base64 for lagring i Kubernetes Secret. Denne konfigurasjonen lar applikasjonen din autentisere mot 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. Distribuer den kodede konfigurasjonen som hemmeligheten din

Bruk dette Kubernetes-manifestet for å lagre OpenStack-påloggingsinformasjonen din sikkert i det opprettede navnerommet:

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

Installasjonsprosess

Velge riktig versjon av Cinder CSI-volumprovisioner

Tilpass Cinder CSI-volumprovisioner-versjonen til Kubernetes-versjonen din. Hent Kubernetes-versjonen din og list opp tilgjengelige Helm chart-versjoner for å sikre kompatibilitet.

Hent OpenShift-versjonen din:

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 tilgjengelige Cinder CSI-versjoner:

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

Tilpass Kubernetes-versjonen din til versjonen i kolonnen app_version. Når du søker etter en spesifikk versjon, husk at det er Helm-chart-versjonen du angir, ikke Kubernetes-versjonen.

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

Når vi søker etter riktig versjon, bruker vi tilde-områdesammenligninger. Tilde-operatoren (~) brukes for områder på patch-nivå når en minor-versjon er angitt og for endringer på hovednivå når minor-nummeret mangler. I vårt eksempel er ~2.28 ekvivalent med >= 2.28, < 2.29.

I Chart.yaml, oppdater avhengighetene slik at det søkes etter samme versjon

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

Oppdater avhengigheter

helm dependency update

Hvis du har endringer, push dem til Git-repositoriet ditt.

Installere Cinder CSI‑volumprovisjonering

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

Kontroller med oc -n ${namespace} get pods at du har én controllerplugin-pod og nodeplugin-poder for hver node i klyngen.

oc -n ${namespace} get pods

Du har nå to forskjellige lagringsklasser du kan bruke.

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

Test Cinder CSI-volumprovisioner

Test Cinder CSI-volumprovisioneren ved å opprette en PersistentVolumeClaim og deretter en applikasjon som bruker denne PVC-en.

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

Når det lykkes, skal PersistentVolumeClaim ha statusen “Bound”.

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

Hvis du får problemer, start med å se i hendelsestabellen med oc -n ${namespace_test} events.

I OpenStack kan du bruke OpenStack CLI for å se volumet ditt.

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

Til slutt slett testen din:

oc delete namespace ${namespace_test}

Oppdatere installasjonen

Skulle det være oppdateringer tilgjengelige for Cinder CSI-provisioneren, bruk følgende kommando for å ta dem i bruk:

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

Avinstallering

Hvis du trenger å avinstallere Cinder CSI-provisioneren, kjør disse kommandoene:

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

Ofte stilte spørsmål

Utfordringen med å bruke Helms values.yaml for hemmeligheter

Selv om Helm-diagrammer gjør det enkelt å automatisere utrullinger, inkludert opprettelse av hemmeligheter via values.yaml-filen, medfører denne metoden betydelige sikkerhetsutfordringer, særlig i en GitOps-arbeidsflyt med ArgoCD.

For eksempel, når du konfigurerer openstack-cinder-csi-chartet, kan det være fristende å legge inn sensitive legitimasjonsopplysninger direkte i values.yaml-filen slik:

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 tilnærmingen fungerer fint for manuelle Helm-installasjoner. I et GitOps-oppsett der ArgoCD automatisk tar i bruk konfigurasjoner fra et Git-repositorium, er det imidlertid risikabelt å lagre hemmeligheter på denne måten. Hovedbekymringen er sikkerhet: å lagre sensitiv informasjon, som legitimasjonsopplysninger, i et Git-repositorium – selv om det er privat – utsetter infrastrukturen din for potensielle sikkerhetsbrudd.