Is the deployment label used by the service?

BPDev

3/11/24, 10:33 PM

I tried being more explicit when naming labels in a Kubernetes configuration file, thinking that deployments use the pod labels and services use the deployment labels.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-depl
  labels:
    app: auth-depl-label
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth-pod-label
  template:
    metadata:
      labels:
        app: auth-pod-label
    spec:
      containers:
      - name: auth-pod
        image: bogdan-pechounov/auth
        ports:
        - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: auth-srv
spec:
  selector:
    app: auth-depl-label
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 3000
    targetPort: 3000

However, minikube service auth-srv yields a This site can’t be reached error in Chrome. In the minikube dashboard, the service is pending and there are no pods associated with the service.

Using the pod labels instead does work, which makes me wonder what the deployment labels are for.

apiVersion: v1
kind: Service
metadata:
  name: auth-srv
spec:
  selector:
    app: auth-pod-label
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 3000
    targetPort: 3000

full code (skaffold dev to start)

1 + 1

kubernetes

mdaniel

3/11/24, 11:26 PM

While not directly related to your question about labels, the minikube's Load Balancer is `Pending` because it is waiting for a "cloud provider" to provision a LoadBalancer, which is unlikely to happen in your minikube setup. Best to use a `NodePort` or other trickery when running outside of a cloud. That's a whole other can of worms, but using the search feature will show plenty of questions and answers about that, too, since it's so common

Score:0

Server

mdaniel

3/11/24, 11:24 PM

which makes me wonder what the deployment labels are for.

Every label is just a way to refer to a collection of resources without knowing their names. However, as you pointed out, kubernetes itself uses labels in a couple of ways related to your question:

Deployments use labels for tracking the health and cardinality of their managed Pods (since the names of Pods are mostly random)
Services use labels for tracking the Pods in Ready state to which traffic should be sent

With Deployments, one also needs to exercise caution that the Deployment object itself has labels, but those are not related to the template: { metadata: { labels: {} } } that are stamped onto newly created Pods and those are the ones which must be a subset of the matchLabels: for a Deployment to manage them

Same story with the Service, which again can have its own labels but are unrelated to the labels it uses for Service membership. Be aware that while it is super common to have the labels in matchLabels: be the same as those in the Service's selector:, they otherwise have no relationship to one another

This is a perfectly fine setup, since the Deployment cares only about the Pods being awesome and the Service cares only about those Pods being v1, and both are fulfilled by newly spawned Pods from the Deployment because of the template's labels applied to them

kind: Deployment
spec:
  ...
  matchLabels:
    app: awesome
  template:
    metadata:
      labels:
        app: awesome
        release: v1
---
kind: Service
spec:
  selector:
    release: v1

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Is the deployment label used by the service?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.