A Kubernetes service gives a microservice a network identity. It creates a DNS record that exposes the application within the cluster; its configuration can also make the application reachable from outside. The application runs in a pod, while a deployment manages that pod and replaces it if it fails. Labels connect the deployment, pod, and service. section 6.15 section 6.4.3 section 6.8.3
Start with a YAML file containing both a Deployment and a Service. The deployment’s pod template labels the pod; the service’s selector uses the same label to expose the microservice to HTTP requests. Keeping both resources in one file is convenient, but they can be split into separate files. section 6.8.3
Listing 6.2 Deploying our microservice to Kubernetes on Azure
apiVersion: apps/v1
kind: Deployment
metadata:
name: video-streaming
spec:
replicas: 1
selector:
matchLabels:
app: video-streaming
template:
metadata:
labels:
app: video-streaming
spec:
containers:
- name: video-streaming
image: bmdk1.azurecr.io/video-streaming:1 #1
imagePullPolicy: IfNotPresent #2
env:
- name: PORT
value: "4000"
---
apiVersion: v1
kind: Service
metadata:
name: video-streaming
spec:
selector:
app: video-streaming
type: LoadBalancer #3
ports:
- protocol: TCP
port: 80
targetPort: 4000
In this Azure configuration, the service selects pods labeled app: video-streaming and maps TCP port 80 to the application’s port 4000. Type LoadBalancer requests an external load balancer and IP address. section 6.11.4
Deploy and check the service alongside the pod and deployment:
- Run `kubectl apply -f scripts/deploy.yaml` to create the resources described by the file. section 6.11.5
- Run `kubectl get pods`, `kubectl get deployments`, and `kubectl get services`. The services output shows where the service is exposed; one local NodePort example reports `80:30000/TCP`. section 6.8.5
- After testing, run `kubectl delete -f scripts/deploy.yaml` and check the same resource lists to confirm the service, deployment, and pod are gone. section 6.11.7
Choose external exposure deliberately. A LoadBalancer makes HTTP testing from a development computer possible, but it also exposes the microservice to attacks and abuse. Remove an experimental deployment when testing is finished. section 6.11.4 section 6.11.7
