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.io One of the best resources to learn about Kubernetes is at this official Kubernetes site by Google.
- Kubernetes overview An overview on Kubernetes, all its parts and how it works
- Free Azure Account If you want to try out AKS, Azure Kubernetes Service, you will need a free Azure account
- Kubernetes in the Cloud Do you feel you know everything about Kubernetes already and just want to learn how to use a managed service? Then this link is for you
- Documentation on AKS, Azure Kubernetes Service Azure Kubernetes Service, a managed Kubernetes
- Best practices on AKS You already know AKS and want to learn how to use it better?
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
Top comments (39)
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
But... it's i18n, because 18 letters have been dropped.
...doh!
After running the below
kubectl run kubernetes-first-app --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080
When I run
kubectl get deployments
its gives back like No resources found in default namespace.So I ran like
kubectl create deployment kubernetes-first-app --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080
Then the deployment list can able to work. Not sure whether I missed any earlier steps.
It's failed to start on my machine:
Seems like the error message is saying what's wrong
Here's a thread where people seem to have a similar issue, maybe that helps?
github.com/kubernetes/minikube/iss...
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. UseKubernetes
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 doKubernetes
certification.np :). Here's some resources to get you started docs.microsoft.com/en-us/azure/aks... dotnet.microsoft.com/apps/aspnet/m...
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
You're welcome 😀
Excellent post @softchris !
There are a couple of typos:
curl http://localhost:8001/api/v1/namespaces/default/pod/$POD_NAME
should becurl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME
curl http:localhost:8080
should becurl http://localhost:8080
Thanks :) Appreciate your comments
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
Excellent introduction! Thank you!
Thank you :)
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 ☸️
part two is here dev.to/azure/kubernetes-part-ii-re... working on part 3 :)