k8 the straightforward series: Pt2 — Deployment + SVC

Shailyn Ortiz
5 min readAug 26, 2019

--

Preface

Yeah, blogs can have it too!

If you are here I hope you’ve read Pt1 where we construct “the app” and install Minikube, if you skipped ahead that’s ok too. I’m not about hard on limits, yo do you, just make sure you have a dockerized API in whatever language you want and make sure to use port 5000 or update the port definition accordingly.

Kubernetes

By you being here I assumed you knew a bit of Kubernetes, but let's assume you don’t.

Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.
From the k8 docs.

I’ll borrow a few concepts from another article that I have because the key is to work smart not hard (yeah, that was an excuse).

Deployments

You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate.
From the k8
docs.

Human Translation: In this resource, you can specify what you need and it will make sure that’s what you get (referring to pods).

Let’s get to it:

Create a file called Deployment.yaml and add the following content to it:

Type kubectl apply -f Deployment.yaml , you’ll see an output like the one below:

We have our service running in Kubernetes! But it isn’t actually working (at this point you may have come to realize that I like to intentionally leave you run thru errors).

Type kubectl get pods to list all the pods and it’s statuses

Fixing the issues

As you may see it says STATUS: ErrImagePull and what does this mean? Kubernetes isn’t able to find our Docker Image.

At this point you may be thinking: “But I built it, and I even ran it with docker” I hope that you have done that part. And this is definitely, true, you did! but you did it locally, we never upload that image anywhere, and Kubernetes is installed in another machine so it can’t see what your local Docker has.

Let’s start using the Docker engine inside the Kubernetes cluster:

Type eval $(minikube docker-env)

If everything went well there shouldn’t be any output.

Let’s rebuild our image:
Type docker build -t k8-the-straightforward-way:1 .
If everything went well the image will be built like the first time.

Delete the deployment:
type kubectl delete -f Deployment.yaml

Reapply the deployment:
Type kubectl apply -f Deployment.yaml

Everything should be running seamlessly now:
Type kubectl get pods

And by that we now have our app running in Kubernetes! But it’s unaccessible tho.

In this case, I’m not tricking the reader into learning to fix “day-to-day issues” that everybody gets but doesn’t talk about it because its “beginers-knowledge” thus making it hard for beginners to actually begin (? (what a complex sentence but I hope it makes sense).

This is the expected behavior as we haven’t defined our service.

Services

A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service.
From the k8
docs.

Human translation: Look at this resource as your router rules, under what names the traffic is redirected from the (cluster)network to your application(pod).

Getting to it:

Create a file called Service.yaml and add the following content to it:

Remember the metadata>labels from the deployment?

spec:    template:        metadata:            labels:                name: k8-the-straightforward-way

That’s what we use to route the traffic back to our app.

Type kubectl apply -f Service.yaml , you’ll see an output like the one below:

Let’s list our services running.
Type kubectl get svc (or kubectl get service or kubectl get services)

In order to access our service, we have a couple of ways:

A) Go into the Kubernetes cluster typing the following:
1. SSH into the cluster, type: minikube ssh
2. Issue a get request to the port in all the interfaces, type: curl 0.0.0.0:30489

B) The “real way” which is from outside the cluster:
1. Get the cluster IP, type: minikube ip
2. Issue a get request to the Cluster-IP at the port, type:

If you wonder were that 30489 come, Kubernetes assings a random port to each service, it does that to ensure that the port administration won’t be an issue, you can have all your apps internally listening on the same port and just route based on app name (which we will be covering in a few episodes)

Shameless self-promotion:

See you folks in the next chapter!

--

--

Shailyn Ortiz

Senior QA Engineer / Devops Engineer. — Docker/kubernetes preacher. — backend and automation — open source contributor