Warning - FailedAttachVolume error - statefulset alatt ContainerCreating

Linux-haladó

Sziasztok,

statefulset krealasa utan a kovetkezo allapot nem valt at Running-ba:

mysql-set-mig-1                                 0/1     ContainerCreating   0          4m25s

 

# kubectl get events -n testns --sort-by='.metadata.creationTimestamp'
.
.
.
61s         Normal    Created                  pod/mysql-set-mig-0   Created container mysql
60s         Normal    Scheduled                pod/mysql-set-mig-1   Successfully assigned testns/mysql-set-mig-1 to xxxxxxx
61s         Warning   FailedAttachVolume       pod/mysql-set-mig-1   Multi-Attach error for volume "pvc-xxx-xxxx-xxxx-xxxx-xxxx
xxxxx" Volume is already used by pod(s) mysql-set-mig-0

 

Azt olvastam, hogy a pvc-t RWO (ReadWriteOnce) helyett RWX (ReadWriteMany) kene hasznalnom, amit azonban a cluster nem enged.

 

Hiba:

Failed to provision volume with StorageClass "vsphere": invalid AccessModes [ReadWriteMany]:

only AccessModes [ReadWriteOnce] are supported

Hogy lehetne ezt a hibat orvosolni?

Koszonom elore a segitseget.

Ardi

  • 363 megtekintés

( gabrielakos v | 2023. 09. 20., sze – 08:56 )

Olyan storage class kéne neked ami támogatja ezt a működést. NFS például szerintem ilyen. 

zászló, zászló, szív

( denton | 2023. 09. 20., sze – 09:12 )

Hol csinálod ezt melyik cloudba?

Azure alatt a storage account nem játszott samba-val, csak a managed disk.

A network storagek nem lesznek jók neki, szinte tuti.

 

Jah és bocsika, belefutottál egy kezdő problémába :)

Multi-Attach

 

Mysql nem fog menni neked multi pod-ban. Nem tudod 2 pod-ból használni ugyanazt a storage-t.

Ha több mysql-t szeretnél, akkor két totál különállót kell kreálnod és replikálnod.

Egyébként cloudban ellenjavalt alapvetően a konténeres db. Arra vannak a drága PaaS -ok.

szerk ide:

írja is amúgy tök egyértelműen a hibát, hogy nem faxa a ReadWriteMany, helyette kell a ReadWriteOnce. A many pont arra van, ha többen akarják egyszerre írni. Itt ez nem játszik. Az is lehet csak azt kell visszatoszni once-ra, de sztem a network volume nem lesz jó.

( ardi | 2023. 09. 20., sze – 09:54 )

Hello,

ReadWriteOnce eseten kapom a hibat.

# kubectl get events -n testns --sort-by='.metadata.creationTimestamp'
.
.
.
61s         Normal    Created                  pod/mysql-set-mig-0   Created container mysql
60s         Normal    Scheduled                pod/mysql-set-mig-1   Successfully assigned testns/mysql-set-mig-1 to xxxxxxx
61s         Warning   FailedAttachVolume       pod/mysql-set-mig-1   Multi-Attach error for volume "pvc-xxx-xxxx-xxxx-xxxx-xxxx
xxxxx" Volume is already used by pod(s) mysql-set-mig-0

amugy egy mysql-t szeretnek, vmi backuppal. Azt hittem, ez a megoldas jo lesz ra.

Ardi

Továbbra se írtad, hogy melyik cloud, vagy sima földi szerver saját clusterrel?

 

Ott írja amúgy tök egyértelműen amit mondtam.

 

2 podod van, gondolom replikák

mysql-set-mig-0
mysql-set-mig-1

 

Mysql-es pod nem fog menni replicas -al. Felejtsed el.

Sőt a klasszikus Deployment objektum is bepusztulhat ha RollingUpdate-al megy, pont ezért mert nem használhatja ugyanazt a volume-t 2 mysql egyszerre. Emiatt speciel a statefullset mondjuk oké mert nem RollingUpdate-zel. Csak épp a deployok lesznek downtime-osok.

De a replikákat felejtsed el mysql esetén. Ez nem lenne amúgy se backup, mert csak a szoftver van replikálva, a tárolás mögötte közös.

Ha igazi backupot akarsz, akkor csinálj rá kubernetesben cronjob-ot és x időnként nyomj egy mysqldump-ot targz-vel amit elmozgatsz egy távoli meghajtóra.

Vagyis on prem.

Mindenképp kell az nfs? Ha replicas: 1, akkor megy vele?

Ha igen, akkor definiálj külön backup podot, annak külön nfs mappát. Aztán mehet a data-in replication. De sztem az nfs nem lesz jó, ha esetleg el is indul, nem lesz kielégítő a minőség.

Akkor már hostPath

Mukodik.

Most ott akadtam meg, hogy mysql-client podban probalok bejutni az adatbazisba, de nem tudom a nevet.

A pelda szerint:

For access, you will need a MySQL server name. The syntax of the MySQL server in the Kubernetes cluster is given below:

stateful_name-ordinal_number.mysql.default.svc.cluster.local

#Example
mysql-set-0.mysql.default.svc.cluster.local

mysql -u root -p -h mysql-set-mig-0.default.svc.cluster.local
Enter password:
ERROR 2005 (HY000): Unknown MySQL server host 'mysql-set-mig-0.default.svc.cluster.local' (-2)
$

Hol talalom meg a clusteremben a FQDN-et?

Ardi

Alapvetően sehol.

Nyitnod kell kifelé egy portot, jellemzően Service objektummal, NodePort-al.

https://stackoverflow.com/questions/57030925/how-do-i-access-mysql-as-a…

Nem túl szerencsés kinyitni a külvilág felé.

 

Ez localhoston menne is valszeg 127.0.0.1 -el, kifelé, hát már más lenne a sztori, a node ip-vel megy elvileg. Viszont fene tudja milyen beállításaid vannak a clusterben, tűzfal, stb.

Kezdetnek kubectl exec-el be tudsz lépni a pod-ba, és ott már van mysql parancsod.

Valszeg egyszerűbb lenne feltenned valami webes klienst a mysql mellé külön pod-ban, pl (fujj) phpmyadmin-t ami csatlakozik rá. Ahhoz mondjuk kicsit ingress-ezni kellene, illetve érdemes az alap auth mellé legaláb egy basic auth-ot is betenni fölé.

bocsi - nalam volt a hiba. rossz jelszot adtam meg:

 

sh-4.4# /usr/bin/mysql -uroot -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 17
Server version: 8.1.0 MySQL Community Server - GPL

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

legalabb ez megy. koszonom.

A leírás alapján már kell legyen "mysql" nevű serviced ha megcsináltad a "Create a Service for the StatefulSet Application"-ban leírtakat.

kubectl get services -outputjába benne kell legyen a service, namespacen belül simán "mysql"-re lesz dns feloldásod AFAIK.

De egy "kubectl get all" output is hasznos lehet nekünk a debuggoláshoz.

nos igen, van mar service mysql nev alatt.

$ kubectl get all -n testns
NAME                                                READY   STATUS             RESTARTS   AGE
pod/mysql-client                                    1/1     Running            0          84m
pod/mysql-set-mig-0                                 1/1     Running            0          16m

NAME                                            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/mysql                                   ClusterIP   None           <none>        3306/TCP   17h

NAME                             READY   AGE
statefulset.apps/mysql-set-mig   1/1     123m

 

$ kubectl get svc -n testns|grep mysql
mysql                                   ClusterIP   None           <none>        3306/TCP   18h

Ennyit tudtam kinyerni.

Ardi

Negatív. Ingress http kérésekre van kitalálva, mögötte egy nginx LB-vel.

Tudnod kellene a node külső ip címét, amire ki van bind-olva a port.

 

ez elvileg kiadja mint external ip:

kubectl get nodes -o wide

 

(nem próbáltam még külső ip-re kitenni mysql portot, nem voltam ennyire elvetemült. Szóval próbáld ki)

[szerk]:

nehezítés, ha multi node-s a cucc. nem mind1 melyik node-n fut a konténer.

jól értem, hogy azt tanácsolod hogy a workeren futó podra próbáljon meg csatlakozni? a workereknek nem tűzfal mögött kéne csücsülniük? akkor már miért nem inkább kubectl port-forward? de ez is csak debugra jó, amúgy NodePort kell neki (on premen LoadBalancer gondolom nicns konfigurálva)

Javíts ki ha tévednék, de LB továbbra is http kéréseket kezel (legalábis a felhőkben), ergó mysql nem fog kimenni rajta.

Tanácsolni nem tanácsolom, mert szerintem nem jó ötlet, sztem debugra se, illetve ahogy én is írtam feljebb, kéne legyen tűzfal vagy valami rá.

Mindenesetre edukációs jelleggel lehet játszani vele.

Azure alatt belülre nyitottam simán Node-ra portot, igaz az http volt, de nem LB típus volt. Externálba még nem próbáltam, de lassan kíváncsi leszek és kipróbálom DO alatt (most abban dolgozom).

Kész is, ezzel spec megy....

A droplet (VM) azaz a node ip címén el lehet érni a mysql-t a 30000 -es porton. fujj.....

 

apiVersion: v1
kind: Namespace
metadata:
  name: mysql-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
  namespace: mysql-test
  labels:
    app: mysql-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql-app
  template:
    metadata:
      labels:
        app: mysql-app
    spec:
      containers:
        - name: mysql
          image: mysql:8
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: root
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
  namespace: mysql-test
spec:
  type: NodePort
  selector:
    app: mysql-app
  ports:
    - port: 3306
      targetPort: 3306
      nodePort: 30000

Ez egy nagyon tipikus Kubernetes jelenség.
Látszólag egyszerűen lehet(ne) fault-tolerant high-available mysql-t csinálni. 

De nem így, ez nem lesz jó megoldás.

A Kubernetes se csodaszer, elejétől a végéig végig kéne gondolni a működést.

zászló, zászló, szív

... azaz végig kéne gondolni hogy:

- tényleg akarom-e a mysql replikációt?
- hogyan akarom a mysql replikációt?

Mert a jelen setup egyelőre annyit sugall hogy valamiért akarsz két mysql-t egymás mellé, hogy azok milyen viszonyban vannak egymással arról semmit sem tudunk.

Ettől fogg függeni hogy a ReadWriteOnce vagy a ReadWriteMany kell-e neked a pvc-re.
Éééés majd ettől fog függeni hogy a vmware storage class megfelel-e vagy valami mást kell keresni.

Ha a "microservice" felől közelítünk akkor már a statefulset se annyira "konform", de a ReadWriteMany storage pláne nem. Érdemes ezekről tudni hogy ezek a Kubernetes filozófiába mind-mind a gyakorlati életből adódó, muszájból belekínlódott dolgok.

zászló, zászló, szív

A doksi amit linkelt elég világosan fogalmaz:
 

Remember that while Kubernetes helps you set up a stateful application, you will need to set up the data cloning and data sync by yourself. This cannot be done by the StatefulSets.

Szóval a doksi segít csinánlni 3 mysql podot saját RWO volumeokkal + a szükséges servicet és utána az adatok szinkronizációját baszd össze úgy ahogy tudod, hibátlan! :D

nincs probléma, tisztában vagyok vele, hogy a kubinak nem dolga a mysqlt összekapcsolni, de mégis hiányárzetem támad (igen ez szubjektív) a doksit akkor tekinteném teljesenek ha leírták volna hogyan rakd össze azt a mysql master slave clustert kubernetes alatt, hamár ezzel példálóznak vagy legalább linkelnének róla egy doksit/blogot.

Tény, hogy beginner sztorinak betehettek volna inkább egy nginx/apache2-s példát is. Bár ott kevésbé lenne "látványos" a külön volume podonként.

Szerintem nagyon elvitte volna a témát ha belemennek a mysql-be is, linkelni lehetett volna, tény, hogy egy master-slave nem nagy kunszt.

( blackluck v | 2023. 09. 20., sze – 13:31 )

Azt nezd meg, hogy kulon pvc-t hasznal-e a 2 mysql pod, ha nem akkor az konfig hiba es kulon pvc kell nekik.
De valoszinu valami mysql operatorral (vagy valami mukodo megoldassal) lett kirakva ami ezt rendesen kulon pvc-kent kezeli, ez esetben a gondod nem azzal lesz, hanem a vsphere-csi-driver/kubelet/stb. hibaja miatt nem tudta lecsatolni rendesen (vagy legalabbis vmware azt hiszi) arrol a node-rol a pvc-t ahol korabban futott ez a pod, ezert most mikor indulna masik node-on akkor nem engedi felcsatolni, mert (azt hiszi) meg fel van csatolva a masik node-on.

Ilyenkor vsphere-csi-controller, vsphere-csi-node logokat erdemes atnezni, illetve annak a node-nak a kubelet logjait amin korabban futott a pod. Illetve ezeknek ujrainditasaval lehet probalkozni, esetleg ezek ujrainditasaval.

Illetve erdemes lehet megnezni csi driver frissitest ha regen volt, sok hasonlo hibat is javitottak.
(Amennyiben ez meg valami regebbi rendszer es in-tree vsphere csi van hasznalva, tehat ami meg a kubelet resze es nem futnak kulon ilyen vpshere-csi podok akkor arrol erdemes lenne migralni.)