☰

Kubernetes Persistent Volume Claim NodeAffinity-Fehler

tag-icon • tag-icon kubernetes
Kubernetes Persistent Volume Claim NodeAffinity-Fehler

Ich möchte also ein MSSQL-Pod auf Kubernetes bereitstellen, obwohl ich einige Probleme beim Bereitstellen meines persistenten Volumes habe.

Ich habe zuerst meine Speicherklasse in meinen Namespaces bereitgestellt, die anscheinend bereitgestellt ist. Mein persistentes Volume wurde nicht mit dem Status „Ausstehend“ von mssql bereitgestellt, und bei Verwendung des Befehls „Beschreiben“ wurde angezeigt, dass mein Volume nicht gebunden werden konnte.

Also habe ich diese Art von Fehler gegoogelt und bin auf eine andere persistente Volume-Konfiguration gestoßen, die mich dazu veranlasst hat, meine YAML-Datei zu ändern, obwohl ich jetzt auf einen anderen Fehler gestoßen bin.

Dieser Fehler wurde in diesem Forum bereits gestellt, aber die Antwort scheint nicht zu meinem Problem zu passen oder es zu beheben. -> Referenz:gleicher Fehler

Fehlermeldung:

das persistente Volume pvc-mssql ist ungültig: spec.persistentvolumesource: verboten: ist nach der Erstellung unveränderlich nodeaffinity: ungültiger Wert: core.volumenodeaffinity(erforderlich:(*core.nodeselector) (0xc007163b00)}: Feld ist unveränderlich

Fehlerbild

meine Speicherklasse (bereitgestellt):

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

mein PVC (fehlerhaft):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pvc-mssql
  labels:
    type: local
spec:
  capacity:
    storage: 12Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  hostPath:
    path: /mnt/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - master-production-internal

mein mssql (wartet auf die Bereitstellung):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mssql
  labels:
    app: mssql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      containers:
      - name: mssql
        image: mcr.microsoft.com/mssql/server
        resources:
          requests:
            cpu: 1
            memory: 2Gi
        env:
          - name: ACCEPT_EULA
            value: "Y"
          - name: SA_PASSWORD
            value: mypassword
        ports:
        - containerPort: 1433
        volumeMounts:
        - name: mssql
          mountPath: /var/opt/mssql
      volumes:
      - name: mssql
        persistentVolumeClaim:
          claimName: pvc-mssql

alle werden natürlich im selben Namespace bereitgestellt. Mein Kubernetes besteht aus 4 Knoten, also 4 VMs, wobei jede VM etwa 2 VCPUs und 4 GB RAM mit 128 GB Festplattenspeicher hat und Ubuntu-Server läuft: konfiguriert mit Fail2Ban, UFW, ich habe 1 Master und 3 Knoten. Ich habe die neueste Version, der Cluster wurde vor weniger als 2 Monaten bereitgestellt.

Was scheint das Problem zu sein und/oder was muss ich an meinem PVC ändern und vielleicht muss ich etwas an meinem MSSQL-Bereitstellungs-YAML ändern?

Wenn ich den Fehler meines MSSQL richtig verstehe, kann es das Shred-Volume nicht an einen anderen Knoten binden. Deshalb habe ich jetzt einen bestimmten Knoten in meinem PVC, der mein Master ist. <- Ist das auch richtig oder sollte ich es ändern?

Antwort1

Ich habe dies erreicht, indem ich den MSSQL- und Mongo-Pod ohne Anspruch auf ein dauerhaftes Volumen bereitgestellt habe.

verwandte Informationen