You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Das Deployment welches das villas-controller Python Skript startet sollte als Owner der Kubernetes Jobs eingetragen werden welches es startet.
Das führt dann dazu, dass Kubernetes automatisch alle noch verbleibenden Jobs löscht wenn das villas-controller Deployment gelöscht wird.
Um das zu realisieren muss villas-controller erstmal erkennen, in welchem Pod/Deployment es selbst läuft.
Dies können wir erreichen indem wir die Kubernetes Downward API nutzen um diese Information als Umgebungsvariable im villas-controller verfügbar zu machen.
villas-controller kann dann basierend auf diesen Umgebungsvariablen die Owner Referenzen setzen.
Das sollte aber nur dann geschehen, wenn villas-controller auch wirklich selbst in Kubernetes läuft und die Umgebungsvariablen verfügbar sind.
Cross-namespace owner references are disallowed by design. Namespaced dependents can specify cluster-scoped or namespaced owners. A namespaced owner must exist in the same namespace as the dependent.
Dieses Problem ist im EONERC cluster noch nicht aufgefallen, weil dort eine ältere Server Version (v1.18.0) läuft. Im Jupyter Cluster (v1.21.6) wird das Event OwnerRefInvalidNamespace erzeugt.
D.h. der controller, der im namespace des villas deployments läuft, kann nicht owner der jobs sein, die im separaten controller namespace erstellt werden. War die Trennung der namespaces dafür gedacht, dass dadurch eine geringere Menge von events im controller namespace beobachtet werden muss? Gibt es für die Trennung andere bzw. weitere Gründe? Können wir überlegen, die namespaces zusammenzulegen oder kann die controller Komponente in den controller namespace verschoben werden?
Solution: move controller to controller namespace --> fix in helmchart, remember to use correct schema when accessing services in other namespace e.g. for addressing broker, for example
See: https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications
Das Deployment welches das villas-controller Python Skript startet sollte als Owner der Kubernetes Jobs eingetragen werden welches es startet.
Das führt dann dazu, dass Kubernetes automatisch alle noch verbleibenden Jobs löscht wenn das villas-controller Deployment gelöscht wird.
Um das zu realisieren muss villas-controller erstmal erkennen, in welchem Pod/Deployment es selbst läuft.
Dies können wir erreichen indem wir die Kubernetes Downward API nutzen um diese Information als Umgebungsvariable im villas-controller verfügbar zu machen.
villas-controller kann dann basierend auf diesen Umgebungsvariablen die Owner Referenzen setzen.
Das sollte aber nur dann geschehen, wenn villas-controller auch wirklich selbst in Kubernetes läuft und die Umgebungsvariablen verfügbar sind.
/cc @iripiri
The text was updated successfully, but these errors were encountered: