0

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
  • 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
    – mdaniel
    Commented Mar 11, 2023 at 23:26

1 Answer 1

0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .