Skip to content
This repository has been archived by the owner on Jun 20, 2023. It is now read-only.

Deployment's selector should be immutable #16

Open
stang opened this issue Feb 20, 2019 · 3 comments
Open

Deployment's selector should be immutable #16

stang opened this issue Feb 20, 2019 · 3 comments

Comments

@stang
Copy link

stang commented Feb 20, 2019

Currently, Deployment's selector is populated based on deployment.spec.template.metadata.labels, which itself comes from the deployment.metadata.labels.

This works fine as long as the deployment.metadata.labels are not modified between two deployments. In the other cases, it will raise an immutable field error.

https://github.com/bitnami-labs/kube-libsonnet/blob/master/kube.libsonnet#L385-L387

Ultimately, pod labels can have for a wider range of use-cases which should not be tight to the Deployment selector.

An alternative approach would be to use a deterministic value to populate the the deployment.spec.template.metadata.labels and selector (eg: I think that ksonnet-lib uses the {app: metadata.name}).

kupson added a commit to kupson/kube-libsonnet that referenced this issue Mar 23, 2019
Fixes issue bitnami#16 - Deployment's selector should be immutable

Scenario:
- Deployment is created with kube.libsonnet, CI process adds additional labels
  e.g. "ci-job-id"
- Deployment is updated with the same process but the CI process was updated to
  add new label e.g. "ci-cluster"
- kubectl apply fails as the selector field is immutable

This adds an additional label "app" to Pod, Deployment, StatefulSet, DaemonSet,
Job and CronJob objects and use it when those objects needs to be referred by
selectors.
kupson added a commit to rkwaysltd/k8slab-kube-libsonnet that referenced this issue May 25, 2020
@kupson
Copy link

kupson commented May 25, 2020

Example repository with workaround discussed in pull request #17 - https://github.com/rkwaysltd/k8slab-kube-libsonnet

@ghostsquad
Copy link

I'm doing something to allow labels to differ between the deployment itself and the pod template

_Object(apiVersion, kind, name):: super._Object(apiVersion, kind, name) {
    local this = self,
    metadata+: {
      labels_:: { app: std.join('-', std.split(this.metadata.name, ':')) },
      labels: std.prune(self.labels_ + lm.obj.lookupAll(self, "self_labels_", {})),
    },
},
  
Deployment(name, namespace):: super.Deployment(name) {
    local dp = self,

    metadata+: {
      namespace: namespace,
      pod_only_labels_:: {},
      self_labels_:: {},

      labels: std.prune(self.labels_ + self.self_labels_),
    },
    spec+: {
      template+: {
        metadata: {
          labels: std.prune(dp.metadata.labels_ + dp.metadata.pod_only_labels_),
        },
        spec+: $.PodSpec,
      },
    },
  },

my library is an overlay of bitnami's library.

@ghostsquad
Copy link

ghostsquad commented Jan 22, 2021

the bitnami library is technically doing this correctly, in that, the select points to the pod labels. Which matches the documentation.

selector: {
        matchLabels: deployment.spec.template.metadata.labels,
      },

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#selector

.spec.selector must match .spec.template.metadata.labels, or it will be rejected by the API.

The problem I found is that I needed a way to have the deployment labels differ from the pod labels.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants