Use Kubernetes Owner References to establish relationship betwenn manager and simulation ICs

[stv0g]

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

[stv0g]

mentioned in commit eb40676

[stv0g]

In GitLab by @iripiri on Feb 25, 2022, 11:48

Bei den Owner References gibt es noch das Problem, dass Owner und Dependent im selben namespace sein müssen:

https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/

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?

[stv0g]

In GitLab by @skolen on Mar 2, 2022, 11:17

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

Service-name.namespace.svc.cluster.local

[stv0g]

In GitLab by @skolen on Mar 2, 2022, 11:19

Remark: Role-based access control needs to be fixed so that controller is able to control k8s

• could become simpler? from cluster-based roles to role/ role-bindings