The spec: field of Deployments has two mandatory fields: replicas: and template:. The replicas: field specifies the number of Pods to maintain while the template: field is the PodSpec to instantiate.

A third, optional but recommended, field is selector:. It specifies which Pods the Deployment manages.

For our purposes here, the template: field provides labels: for this template and the PodSpec under spec:.

The primary field we are interested in at the moment is containers:, which is a list of containers belonging to the Pod. We assign each container a name:, specify the image: to use, the imagePullPolicy:, and the environment variables for the container as a list under env:.

The spec: field for Services is quite a bit simpler. Similar to the Deployment's selector, we specify a key:value pair of Pods to route requests to.

We then specify the service type and a list of ports to map from the outside world to our Pods.

See, much simpler? Finally, on to our first round with minikube.

minikube start

This command starts our Kubernetes instance. Without the -p flag, this uses the default minikube profile. We prefer using a different one, like FlixTube.

Instead of appending -p FlixTube to every command, we can also use the MINIKUBE_PROFILE environment variable like so:

export MINIKUBE_PROFILE=FlixTube

Either way works, but I find using the .env file much simpler.

1. minikube start
2. cd video-streaming
3. docker build -t video-streaming:1 -f Dockerfile.prod
4. cd ..
5. minikube kubectl -- apply -f deploy.yml
6. minikube kubectl -- delete -f delete.yml
7. minikube stop

eval $(minikube docker-env)

This lets all docker commands use the minikube image registry by default, so you won't yet see any images with docker image ls.

cd video-streaming
docker build -t video-streaming:1 -f Dockerfile.prod
cd ..

This builds our production Dockerfile for the video-streaming microservice, tags it with the version 1, and pushes it to the minikube image registry.

This is where the Terminology and Configuration sections come in handy. We need to create a video-streaming-deployment and a video-streaming-service to access our service.

The configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: video-streaming-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: video-streaming
  template:
    metadata:
      labels:
        app: video-streaming
    spec:
      containers:
        - name: video-streaming
          image: video-streaming:1
          imagePullPolicy: Never
          env:
            - name: PORT
              value: "4000"
---
apiVersion: v1
kind: Service
metadata:
  name: video-streaming-service
spec:
  selector:
    app: video-streaming
  type: NodePort
  ports:
    - protocol: TCP
      port: 80
      targetPort: 4000
      nodePort: 30000

Notice spec.ports[0].nodePort. That's the port we will access our service through.

minikube ip

Visit http://[ip]:30000/video and watch the sample video play.

Marvelous!

minikube docker -- delete -f deploy.yml

Not destroying your Deployments and Services wastes disk space.

minikube stop

This shuts minikube down for now.

Repetition is the key to mastery. Try these steps yourself without looking at this guide.

Did you succeed? Can you recite them from memory as if you were teaching them to someone?

Congrats if you can! You're well on your way to mastering the minikube Kubernetes distribution.

We won't have the Docker images on our production machines, so we will need to pull the image if it doesn't already exist. That involves a tiny change to the imagePullPolicy of each of our containers.=:

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: video-streaming:1
          imagePullPolicy: IfNotPresent
          env:
            - name: PORT
              value: "4000"

Notice we use IfNotPresent instead of Never.

Production Kubernetes environments will require Services to use type LoadBalancer to distribute traffic instead of NodePort. One tiny change makes that possible:

apiVersion: v1
kind: Service
metadata:
  name: video-streaming-service
spec:
  selector:
    app: video-streaming
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80
      targetPort: 4000

Earlier we accessed the NodePort directly via the IP given to us by minikube ip. That works locally during development, but it will fail in Production.

A LoadBalancer gives us a static IP that routes traffic to all healthy Pods in our Production environment, but minikube only gives us a Cluster IP by default.

Fortunately, minikube also provides a way to expose the LoadBalancer IP to our dev machine so we can test our services locally with the same configuration we will use in Production.

How? In another terminal, run the following command:

minikube tunnel

You will likely be prompted for your password, but then you'll see output similar to this:

Status:
        machine: flixtube
        pid: 129134
        route: 10.96.0.0/12 -> 192.168.58.2
        minikube: Running
        services: [video-streaming]
    errors:
                minikube: no errors
                router: no errors
                loadbalancer emulator: no errors

Return to your original tunnel and execute the following command:

minikube kubectl -- get services

This will show you an External IP you can access from your browser:

NAME              TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
kubernetes        ClusterIP      10.96.0.1       <none>          443/TCP        3d19h
video-streaming   LoadBalancer   10.96.104.195   10.96.104.195   80:31953/TCP   37m

The steps you just followed will let you access your microservices application as if it's deployed to GCP, AWS, LiNode, or any provider of your choice whenever you are ready.