Fix "Deployment not deleted with Flink"

Fix and Closes #248 (closed)

added Bug label

see #248 (closed) for more details

assigned to @stu208458

assigned to @she and unassigned @stu208458

mentioned in issue #248 (closed)

added 1 commit

• b5420942 - fix: wait only for pods which have exactly the same much labels and not only the same app lable

Compare with previous version

The problem of #248 (closed) is that the flink-jobmanager has the same label app=flink as the flink-taskmanager. So when we delete the flink-taskmanager, we wait for all pods with the label app=flink. But since we don't delete the pods related to the flink-jobmanager, we wait for the pods associated with the flink-jobmanager instead of the pods associated with the flink-taskmanager.

If two different deployments (or a deployment and a statefulset) have exactly the same matchLabels, we would get the error again. I'm not sure if this is a "valid" scenario or not? I would think that the matchLabels of two different deployments/statefulsets should never be exactly the same in Kubernetes. What do you think? @she

Ah good catch. Is it possible in Kubernetes that two deployments have excatly the same matchLabels? matchLabels are used by the deployment to identify its associated pods, right?

Yes, technically it is possible to deploy two different deployments that differ only in the metadata.name. However, I am not sure if this is a good practice.

If I am correct, Kubernetes then creates two replicaSets that control the individual pods. The pods then have the ownerReferences field that points to the corresponding replicaSet. The ReplicaSet is associated with the metadata.name of the deployment. So this would not be a problem if the deployments have the same matchLabels.

But other Kubernetes resources (e.g., a service) only look for the labels of a pod. So when you create a service or similar, you can not decide which pods this service should be associated with. So, i am not sure if it make any sense to deploy two deployments with exactly the same matchLabels.

Kubernetes labels are a bit confusing. :D

Maybe interesting readings:

• https://medium.com/@zwhitchcox/matchlabels-labels-and-selectors-explained-in-detail-for-beginners-d421bdd05362
• https://stackoverflow.com/questions/54172198/why-dont-two-kubernetes-replicasets-with-same-selector-conflict-with-each-other
• https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/

approved this merge request

resolved all threads

merged

mentioned in commit c3821898