How Deployment, Service & Ingress are Related in Kubernetes Manifest?

While getting started to write yaml manifest of various Kubernetes resources, we get confused on label, selector, name etc. Let’s go through Deployment, Service and Ingress manifests:

Deployment

# Deployment
...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
...

Service

# Service
...
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: http
  selector:
    app: nginx
...

Ingress

#Ingress
...
spec:
  rules:
  - host: a.domain.com
    http:
      paths:
      - backend:
          serviceName: nginx-service
          servicePort: 80
...

It’s confusing right? This illustration speaks a lot:

CNCF: Deployment Strategies on Kubernetes

On the deployment configuration, replicas specifies the desired number of replicated pods with the label same as matchLabels directive which is in key, value format. If there are multiple labels, they are ANDed, that means we can have as many labels of pod but that should match at least all the matchLabels key, value pair.

These key-value label pairs make it easier to filter the resources based on label. For eg, if we add label tier: backend to backend deployment services, we can get deployment list with

kubectl get deployments -l tier=backend

Updating newer version of container

While changing the version of container(I am saying container, not pod because a pod can have multiple container — sidecar, got it?), we need to specify both the deployment name and container name.

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

Kubernetes Service

We have pods running on Kubernetes cluster which has to be connected by some way. That’s the job of Service.

Service abstracts the Pod IP addresses to a static service name so that the external requests can be proxied to multiple pods. We have different types of services: NodePort, ClusterIP, LoadBalancer which we will discuss on another post.

The proxying of requests to desired pod is based on selector spec on the service which should match the metadata labels on pod.

Ingress Communicates with Service

The service can be used only within the cluster. For, eg. within the cluster we can access nginx with command curl http://my-service where my-service is the service name with selector to nginx pod.

Now, we need to configure way to access the services out of cluster via IP address or some URL. Ingress comes here also for SSL termination to load balancing.

An Ingress is a collection of rules that allow inbound connections to reach the cluster services.

Ingress spec should provide the service name as backend(my-service in above case) and the port(servicePort) which is exposed by the service along with the URL route(/api, /login) or name based host(api.example.com, login.example.com).

Connect with me on LinkedIn, Twitter for more interesting updates.