Ich habe Schwierigkeiten mit dem Postfix Deployment.
Ohne Angabe einer StorageClass ist das Ergebnis:
+ # Source: postfix/templates/persistentvolumeclaim.yaml
+ apiVersion: "v1"
+ kind: "PersistentVolumeClaim"
+ metadata:
+ name: "postfix"
+ labels:
+ app.kubernetes.io/name: postfix
+ helm.sh/chart: postfix-1.7.1
+ app.kubernetes.io/instance: postfix
+ app.kubernetes.io/managed-by: Helm
+ app.kubernetes.io/component: "postfix"
+ spec:
+ accessModes: [ReadWriteOnce]
+ storageClassName: ""
+ resources:
+ requests:
+ storage: "1Gi"
Durch den leeren Wert kann k8s das Volume nicht herstellen. Mit expliziter Angabe funktioniert es.
Im weiteren Verlauf kommt ein Fehler:
MountVolume.SetUp failed for volume "tls" : secret "postfix-tls" not found
Unable to attach or mount volumes: unmounted volumes=[tls], unattached volumes=[kube-api-access-562m2 tls spool-postfix overrides]: timed out waiting for the condition
Der TLS key wurde als Secret mit dem Namen postfix-qfsmh angelegt.
Hallo @klimpel,
hier ein kurzer Zwischenstand zu den von dir angesprochenen Themen:
Durch den leeren Wert kann k8s das Volume nicht herstellen. Mit expliziter Angabe funktioniert es.
Mit Kubernetes v1.26 hat es eine Anpassung gegeben, auf die sich das Verhalten zurückführen lässt, siehe auch: Kubernetes v1.26: Retroactive Default StorageClass | Kubernetes
Sollte die bei beim auftreten des Fehlerbilds eingesetzte Version nicht 1.26+ sein, sende uns gerne ein kurzes Feedback dazu. Hier wird es zeitnah eine Korrektur geben.
Im weiteren Verlauf kommt ein Fehler:
[…]
Der TLS key wurde als Secret mit dem Namen postfix-qfsmh angelegt.
Das Problem ist durch ein nicht Versions-gepinntes Helm-Chart verursacht. Bei uns trat es nicht auf, da der Postfix DNS-seitig aufgelöst werden kann. Wir werden ein entsprechendes Pinning zeitnah einführen und beim kontrollierten Upgrade auf das aktuellere Helm-Chart die notwendige Änderung berücksichtigen. Sobald beide Punkte umgesetzt wurden, geben wir nochmal ein Feedback dazu.
Viele Grüße
Jayjay
Community Management Souveräner Arbeitsplatz
Mit Kubernetes v1.26 hat es eine Anpassung gegeben, auf die sich das Verhalten zurückführen lässt, siehe auch: Kubernetes v1.26: Retroactive Default StorageClass | Kubernetes
Der Artikel ist gut. Beschreibt auch gut das Verhalten. In dem konkreten Beispiel habe ich k8s v1.25.11 genutzt.
Ich kann mit dem manuellen Angeben der StorageClass als Workaround leben.
1 „Gefällt mir“
Hallo nochmal, lieber @klimpel,
ein kurzes Update: Beide Punkte - neues Verhalten bei der Angabe des storageClassName und Zertifikatsissue - sind nun mit dem aktuellen Stand in Main gelöst.
Viele Grüße
Jayjay
Community Management Souveräner Arbeitsplatz