Home / server / Questions / 1125917
Accepted
BPDev
Asked: 2023-03-12 06:33:34 +0800 CST

Is the deployment label used by the service?

  • 772

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)

kubernetes

1 Answers

  1. Best Answer

    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