Getting Started with Kubernetes: Deploy a Docker Container with Kubernetes in 5 minutes

Kubernetes has been the cool kid in Container-Orchestration-Town for quite a while now and with the software industry moving towards Containerization at breakneck speeds, it’s high time you learned how to tango with Kubernetes.

Nuff talk, let’s get started.

Requirements:

1. You need a bit of experience with docker. (As long as you know and understand the basics of building and running a container you’ll be more than fine)
2. You have a Kubernetes cluster running somewhere. (Doesn’t matter if it’s minikube on your local machine or with a Cloud Provider like Google Kubernetes Engine (GKE)/ Amazon Elastic Kubernetes Service (EKS)/ Azure Container Service (AKS)(/ etc.) — I’ll be using GKE, but it won’t make a difference in terms of using K8s (shorthand for Kubernetes) to run a Container in them.
    — If you need to set up a cluster @Kanchana Wickremasinghe has written a nice article on Creating a Kubernetes Cluster with Google Kubernetes Engine (GKE) under 5 minutes
3. You have a working Docker Image of your application in an image repository somewhere. — I’ll be using Google’s Container Repository (gcr.io) but again, you can use whatever you want, it won’t make a difference.
   — If you prefer to use an image on your local machine you can use that instead of a repository link.

Step 1: Pull the image from the Repository and create a Container on the Cluster

$ kubectl run my-app --image=gcr.io/some-repo/my-app:v1 --port=3000
deployment "my-app" created

Note: My application is hosted on port 3000 so I’m opening port 3000 when I run the container, if your application doesn’t require a port just remove the port parameter.

If you want to see this container running in your cluster, simply call for the pods. (Kubernetes groups containers together in ‘Pods’. Since our container is by itself, it’ll be in a pod of it’s own.)

$ kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
my-app            1/1       Running   0          10m

Note: If you check immediately after deployment, you might see the STATUS as ContainerCreating. This means K8s is still creating a Container from your image; just wait a few seconds (or minutes depending on the size of your container) and run this command again.

Step 2: Expose the Kubernetes Deployment through a Load Balancer

$ kubectl expose deployment my-app --type=LoadBalancer --port=8080 --target-port=3000
service "my-app" exposed

Now we need to expose our Container with a Kubernetes Load Balancer to the world! — how hard was that eh?

I’m forwarding my port exposed on the Container (which is port 3000) to port 8080 (a random pick — no particular reason to use this port. ). Just remember that the target-port and port arguments are synonymous to port forwarding 8080:3000 (port:target-port) as you’d do with docker run -p 8080:3000 my-app (external:internal)

Step 3: Find the external IP of your Container

First let’s get the deployment service details from our cluster.

$ kubectl get svc
NAME     TYPE           CLUSTER-IP      EXTERNAL-IP     
my-app   LoadBalancer   10.11.452.237   56.170.30.123

And now you know the external IP address of your container.

my-app is now exposed on http://56.170.30.123:8080 through a Kubernetes Load Balancer!

(Extra) Step 4: Use Kubernetes Rolling Updates

Say you’ve updated this application. Do we have to go through this again to update it on the Cluster? Nope.

I’m going to make a few changes and push a new image with a new v2 tag to gcr.io. gcr.io/some-repo/my-app:v2

We can now get K8s to update our application with just one command -

$ kubectl set image deployment/my-app  my-app=gcr.io/some-repo/my-app:v2

And that’s it — Kubernetes will pull your new image and update your current deployment through a Rolling Update.

(Extra) Step 4: Clean Up

$ kubectl delete deployment my-app
$ kubectl delete svc my-app

Final Remarks

Now you’ve learned how to manually create a basic deployment with Kubernetes. But there’s much more to it than what we’ve seen so far in this guide. For a production system, you’d want to use a deployment.yaml file that specifies all these plus resource limitations, replica sets, so on and so forth.

Follow the Platformer Blog for more articles on Kubernetes and Container Orchestration!