Kubernetes: podul nu poate monta un PVC, chiar dacă acesta din urmă pare să fie legat corespunzător de un PV

âBună ziua.

Întâmpin o problemă în timp ce încerc să implementez un pod care a fost configurat să utilizeze un volum persistent.Instalarea mea este găzduită pe Hetzner Cloud și Kubernetes a fost configurat conform instrucțiunilor puse la dispoziție de furnizor. Configurația de bază pare ok, deoarece pot implementa de ex. Portainer dintr-unul din manifestele furnizate: monteaza corect PVC-ul si ruleaza. Deoarece configurația implicită nu creează o stocare persistentă, de fiecare dată când anulez și reinstalez Portainer toate datele se pierd.

Așa că am continuat cu crearea unui Volum persistent, dar pasul final nu funcționează. Nu pot spune dacă problema este una generică Kubernetes sau este legată de integrarea mea cu Hetzner - dar cred că are sens să verific prima ipoteză. Așa că întreb aici înainte de a merge pe forumul Hetzner.

Pași:

1. Am creat un volum folosind interfața de utilizator Hetzner Cloud.

2. Apoi am implementat un PV:

    apiVersion: v1
    fel: spațiu de nume
    metadate:
      nume: portainer
    ---
    apiVersion: v1
    fel: PersistentVolume
    metadate:
      nume: pv-portainer-test
      namespace: portainer
      etichete:
        env: test
    specificație:
      storageClassName: portainer-test
      Moduri de acces:
        - ReadWriteOnce
      capacitate:
        stocare: 10Gi
      persistentVolumeReclaimPolicy: Păstrați
      volumMod: Sistem de fișiere
      csi:
        driver: csi.hetzner.cloud
        fsType: ext4
        volumHandle: „pv_id”

pv_id este ID-ul volumului pe care îl pot vedea cu interfața de utilizator Hetzner.

Pot vedea PV-ul cu kubelet get pv -A:

SPAȚIU DE NUME NUME CAPACITATE MODURI DE ACCES POLITICI DE REVENIRE STAREA VENIREA DEPOZITARE CLASA MOTIV Vârsta
            persistentvolume/pv-portainer-test 10Gi RWO Retain Available portainer-test 71s

Rețineți că spațiul de nume nu a fost definit... dar presupun că aceasta nu este o problemă serioasă. Poate greșesc.

3. Am desfășurat Portainer de la Aici și următorul patch:â

    fel: PersistentVolumeClaim
    apiVersion: v1
    metadate:
      nume: portainer
      namespace: portainer
    specificație:
      storageClassName: portainer-test
      Moduri de acces:
        - ReadWriteOnce
      resurse:
        cereri:
          stocare: "10Gi"

Acum cu kubectl obține pvc,pv -A Văd că PVC-ul a fost legat de PV:

âSPAȚIU DE NUMELE NUME STAREA VOLUM CAPACITATE MODURI DE ACCES DEPOZITARE CLASA VÂRĂ
portainer persistentvolumeclaim/portainer Bound pv-portainer-test 10Gi RWO portainer-test 16m

SPAȚIU DE NUME NUME CAPACITATE MODURI DE ACCES POLITICI DE REVENIRE STAREA VENIREA DEPOZITARE CLASA MOTIV Vârsta
            persistentvolume/pv-portainer-test 10Gi RWO Retain Bound portainer/portainer portainer-test 17m

4. Dar podul Portainer rămâne în ContainerCreating statut pentru totdeauna.â Cu kubectl descrie vad motivul:

Avertisment FailedAttachVolume 2s (x7 peste 38s) attachdetach-controller AttachVolume.Attach a eșuat pentru volumul „pv-portainer-test”: eroare rpc: code = FailedPrecondition desc = eșuat la publicarea volumului: volumul este atașat

Deci se pare că se plânge pentru că PV-ul este deja atașat... dar într-adevăr ar fi trebuit să fie atașat tocmai de acel pod.

Problema nu era legată de k8-uri, ci specifică lui Hetzner. În configurația proiectului lăsasem volumul atașat la un server fix, ceea ce evident l-a făcut indisponibil pentru atașare prin driverul CSI. Un utilizator la Forumul Hetzner Cloud mi-a indicat asta.

Oricum, aș dori să-i mulțumesc lui Bazhikov, deoarece mi-a dat câteva indicii care au fost utile în rezolvarea altor probleme.

De obicei, nu trebuie să creați mai întâi PV, când creați PVC, PV este creat automat. Cu toate acestea, să rămânem așa cum este și există îndoieli cu privire la clasa ta de stocare portainer-test, cum ai creat-o?

Dacă începeți de la început, presupun că ați creat secretul pentru tokenul API pentru Hetzner și ați activat driverele CSI, nu? Apoi se solicită PVC și se desfășoară Pod nu ar trebui să fie o problemă, cu excepția cazului în care tipul de driver este acceptat de Kubernetes. Nu știu ce tip aveți, dar vă rugăm să rețineți că Kubernetes suporturi pentru csi.hetzner.cloud numai v0.3, v1.0 versiuni.

Să presupunem că ați făcut totul corect înainte și că versiunea Kubernetes (1.13 sau mai nouă) și versiunile driverului sunt bune. Atunci, iată ghid despre cum să creați manual un obiect PersistentVolume pentru a reprezenta volumul existent:

apiVersion: v1
fel: PersistentVolume
metadate:
  nume: pv-portainer-tes
specificație:
  capacitate:
    stocare: 10Gi
  Moduri de acces:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Păstrați
  csi:
    driver: csi.hetzner.cloud
    volumMâner: portainer
    readOnly: fals
    fsType: ext4
    volumAtribute:
      foo: bar
    controllerPublishSecretRef:
      nume: secretul meu1
      namespace: mynamespace
    nodeStageSecretRef:
      nume: mysecret2
      namespace: mynamespace
    nodePublishSecretRef
      nume: mysecret3
      namespace: mynamespace

Atunci atașați și montați volumul prin implementarea unui Pod. Când podul care face referire la un volum CSI este programat, Kubernetes va declanșa operațiunile corespunzătoare împotriva pluginului CSI extern (ControllerPublishVolume, NodeStageVolume, NodePublishVolume etc.) pentru a se asigura că volumul specificat este atașat, montat și gata de utilizare de către containerele din păstaie.

Și rețineți: există o limită pentru driverele csi de până la 16, vă rugăm să verificați dacă limita dvs. nu este aproape de 16