loading...
Cover image for Learn Kubernetes, Part I, Basics, Deployment and Minikube
Microsoft Azure

Learn Kubernetes, Part I, Basics, Deployment and Minikube

softchris profile image Chris Noring Updated on ・7 min read

Follow me on Twitter, happy to take your suggestions on topics or improvements /Chris

Kubernetes is about orchestrating containerized apps. Docker is great for your first few containers. As soon as you need to run on multiple machines and need to scale/up down and distribute the load and so on, you need an orchestrator - you need Kubernetes

This is the first part of a series of articles on Kubernetes, cause this topic is BIG!.

  • Part I - from the beginning, Part I, Basics, Deployment and Minikube we are here
  • Part II introducing Services and Labeling In this part, we deepen our knowledge of Pods and Nodes. We also introduce Services and labeling using labels to query our artifacts.
  • Part III Scaling Here we cover how to scale our app
  • Part IV - Auto scaling In this part we look at how to set up auto-scaling so we can handle sudden large increases of incoming requests

In this part I hope to cover the following:

  • Why Kubernetes and Orchestration in General
  • Hello world: Minikube basics, talking through Minikube, simple deploy example
  • Cluster and basic commands, Nodes, 
  • Deployments, what it is and deploying an app
  • Pods and Nodes, explain concepts and troubleshooting

 Why Orchestration

Well, it all started with containers. Containers gave us the ability to create repeatable environments so dev, staging, and prod all looked and functioned the same way. We got predictability and they were also light-weight as they drew resources from the host operating system. Such a great breakthrough for Developers and Ops but the Container API is really only good for managing a few containers at a time. Larger systems might consist of 100s or 1000+ containers and needs to be managed as well so we can do things like scheduling, load balancing, distribution and more.

At this point, we need orchestration the ability for a system to handle all these container instances. This is where Kubernetes comes in.

Resources

Kubernetes 

So what do we know about Kubernetes?

It's an open-source system for automating deployment, scaling, and management of containerized applications

Let'start with the name. It's Greek for Helmsman, the person who steers the ship. Which is why the logo looks like this, a steering wheel on a boat:

It's Also called K8s so K ubernete s, 8 characters in the middle are removed. Now you can impress your friends that you know why it's referred to as K8.

Here is some more Jeopardy knowledge on its origin. Kubernetes was born out of systems called Borg and Omega. It was donated to CNCF, Cloud Native Computing Foundation in 2014. It's written in Go/Golang.

If we see past all this trivia knowledge, it was built by Google as a response to their own experience handling a ton of containers. It's also Open Source and battle-tested to handle really large systems, like planet-scale large systems.

So the sales pitch is:

Run billions of containers a week, Kubernetes can scale without increasing your ops team

Sounds amazing right, billions of containers cause we are all Google size. No? :) Well even if you have something like 10-100 containers, it's for you.

 Getting started

Ok ok, let's say I buy into all of this, how do I get started?

Impatient ey, sure let's start to do something practical with Minikube

Ok, sounds good I'm a coder, I like practical stuff. What is Minikube?

Minikube is a tool that lets us run Kubernetes locally

Oh, sweet, millions of containers on my little machine?

Well, no, let's start with a few and learn Kubernetes basics while at it.

Installation

To install Minikube lets go to this installation page

It's just a few short steps that means we install

  • a Hypervisor
  • Kubectl (Kube control tool)
  • Minikube

 Run

Get that thing up and running by typing:

minikube start

It should look something like this:

You can also ensure that kubectl have been correctly installed and running:

kubectl version

Should give you something like this in response:

Ok, now we are ready to learn Kubernetes.

 Learning kubectl and basic concepts

In learning Kubernetes lets do so by learning more about kubectl a command line program that lets us interact with our Cluster and lets us deploy and manage applications on said Cluster.

The word Cluster just means a group of similar things but in the context of Kubernetes, it means a Master and multiple worker machines called Nodes. Nodes were historically called Minions

, but not so anymore.

The master decides what will run on the Nodes, which includes things like scheduled workloads or containerized apps. Which brings us to our next command:

kubectl get nodes

This should give us a result like this:

What this tells us what Nodes we have available to do work.

Next up let's try to run our first app on Kubernetes with the run command like so:

kubectl run kubernetes-first-app --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080

This should give us a response like so:

Next up lets check that everything is up and running with the command:

kubectl get deployments

This shows the following in the terminal:

In putting our app on the Kluster, by invoking the run command, Kubernetes performed a few things behind the scenes, it:

  • searched for a suitable node where an instance of the application could be run, there was only one node so it got chosen
  • scheduled the application to run on that Node
  • configured the cluster to reschedule the instance on a new Node when needed

Next up we are going to introduce the concept Pod, so what is a Pod?

A Pod is the smallest deployable unit and consists of one or many containers, for example, Docker containers. That's all we are going to say about Pods at the moment but if you really really want to know more have a read here

The reason for mentioning Pods at this point is that our container and app is placed inside of a Pod. Furthermore, Pods runs in a private isolated network that, although visible from other Pods and services, it cannot be accessed outside the network. Which means we can't reach our app with say a curl command.

We can change that though. There is more than one way to expose our application to the outside world for now however we will use a proxy.

Now open up a 2nd terminal window and type:

kubectl proxy

This will expose the kubectl as an API that we can query with HTTP request. The result should look like:

Instead of typing kubectl version we can now type curl http://localhost:8001/version and get the same results:

The API Server inside of Kubernetes have created an endpoint for each pod by its pod name. So the next step is to find out the pod name:

kubectl get pods

This will list all the pods you have, it should just be one pod at this point and look something like this:

Then you can just save that down to a variable like so:

Lastly, we can now do an HTTP call to learn more about our pod:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME

This will give us a long JSON response back (I trimmed it a bit but it goes on and on...)

Maybe that's not super interesting for us as app developers. We want to know how our app is doing. Best way to know that is looking at the logs. Let's do that with this command:

kubectl logs $POD_NAME

As you can see below we know get logs from our app:

Now that we know the Pods name we can do all sorts of things like checking its environment variables or even step inside the container and look at the content.

kubectl exec $POD_NAME env

This yields the following result:

Now lets step inside the container:

kubectl exec -ti $POD_NAME bash

We are inside! This means we can see what the source code looks like even:

cat server.js

Inside of our container, we can now reach the running app by typing:

curl http://localhost:8080

Summary

This is where we will stop for now.
What did we actually learn?

  • Kubernetes, its origin what it is
  • Orchestration why you will soon need it
  • Concepts like Master, Nodes and Pods
  • Minikube, kubectl and how to deploy an image onto our Cluster

Feel like you have a ton more to learn? You're right this is a big topic.

I hope you follow along on the next upcoming parts where we will learn more about Nodes, Pods, Services, Scaling, Updating and eventually how to use a managed service in the Cloud.

Click here for the Next part

Posted on by:

softchris profile

Chris Noring

@softchris

https://twitter.com/chris_noring Cloud Developer Advocate at Microsoft, Google Developer Expert

Microsoft Azure

Any language. Any platform.

Discussion

markdown guide
 

It's Also called K8s so Kubernete*s*, 8 characters in the middle are removed. Now you can impress your friends that you know why it's referred to as K8.

I always thought the reason for this is that "ete" in "Kubernetes" sounds like an 8, so we have "Kubern8s". What kind of eights? Well, "Kubern" eights are not a real thing, so we skip the "ubern", and now we have "K'8s", which just becomes "K8s".

 

Hi Thorsten. This is what Google themselves say..

kubernetes.io/docs/concepts/overvi...

But who knows what else is true ;)

 

Yeah it's a similar principle to internationalisation being shortened to i11n as it has 11 letters in the middle and just makes it quicker to type and slightly quicker to say

 

Hi Chris,

I have a doubt whether Its worth for .NET developers to learn kubernetes. Can you explain by adding some comment on below post. I have posted it long ago but no answers.

dev.to/shaijut/kubernetes-vs-azure...

 

hi Shaijut. In trying to answer you I must make some assumptions. When you say .NET you mean .NET and not .NET Core.. Let's assume you are doing .NET Core, so you can easily containerize. Otherwise I think App Service is your only option. For me, Kubernetes vs App Service is a matter of what architecture I have. If I have several Microservices rather than a Monolith then I need an orchestrator like Docker Swarm, Kubernetes or similar. The reason is to be able to scale easily, load balance and whatever else you need. App Service does a decent job of scaling as it is a PaaS but I would say if you have a very large operation 500k users and a Microservice Architecture it makes sense to look further into Kubernetes and AKS for example . Azure Service Fabric is another option we have. For ppl already using it, keep using it. For others, look into AKS.. We support multiple ecosystems for containers but all indications I have says the future is Kubernetes. Don't take that as an official statement though

 

Thanks for detail explanation 😄, Actually I heard someone saying two points 1. For .NET Core Apps Azure Service Fabric is good choice. 2. Use Kubernetes for other stacks like Java, NodeJS etc...

So from your comments I am able conclude that I being a .NET Developer its worth to learn Kubernetes. Actually planning to do Kubernetes certification.

 

Excellent post @softchris !

There are a couple of typos:

  • curl http://localhost:8001/api/v1/namespaces/default/pod/$POD_NAME should be curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME

  • curl http:localhost:8080 should be curl http://localhost:8080

 

Thanks :) Appreciate your comments

 

Thanks for this awesome writeup. I think there's a little typo here

Instead of typing kubectl proxy we can now type curl http://localhost:8001/version and get the same results:

I think it should be

Instead of typing kubectl version we can now type curl http://localhost:8001/version and get the same results:

 

Hi thanks. Appreciate you pointing that out :)

 

Great read, thanks for sharing your knowledge in an easy to understand way. Looking forward to part 3.

Just a small suggestion. A link to the next article in the series at the bottom helps the reader move on without having to scroll all the way back to the top to find the link

 

Hi Sam. Thanks for that. Will update it

 
 

Really nice post.

I got a small setup at home for some local services with docker-compose. Do you think its worth it to switch to k8s with a single node (master)? Or is it to much overhead to maintain it?

 

hi Martin.. I'd say it depends. If you are hosting it in the Cloud then horizontal scaling is enabled by default and that might be all you need. To me it sounds like it might be overkill but trying it out on a hobby basis is how most of us learn anything

 

Thanks Chris for this, I too am fascinated by Kubernetes, wrote up a post on

dev.to/inspire99/why-do-we-need-ku...

 

For windows 10 users with HyperV, you must explicitly specify 'hyperv' as a driver since minikube use VirtualBox by default.

minikube start --vm-driver=hyperv

 

Dang it. Take my heart. I appreciate that high quality gif.

 

Great, soft, and effective introduction about k8s. I'm looking forward for part two. In fact, I'm looking forward to the entire series. Please do more ☸️

 
 
 
 
 

Nice read, Chris. Looking for next part!

 

Thanks a lot. I learn so much of all your articles

 

hi Lucas. That's very nice of you to say. Thank you.. :)

 

Nodes were historically called Minions, but not so anymore. :(

 

yea it's the most disappointing thing about K8s :)

 
 

hi Ariaseta. Thanks for the comment :). The 2nd part is gonna be published in the next week.

 

Exceptional Post on Dev.to about Kubernetes a.k.a K8. Already looking forward to Part II

 

hi Ali. Really appreciate that comment.. thank you.. Yes will work hard to release second part in the next few days :)