Kubernetes Tutorial - An Introduction to the Basics
Google created Kubernetes to help developers better manage their containerized applications across clusters. Although a beta version was released in 2014, the first stable release of Kubernetes was just made available in September 2018. The following Kubernetes tutorial will cover the basic architecture and uses for this popular new tool.
The need for containerization
Today’s internet users don’t tolerate downtime, so developers have had to find ways to perform maintenance and updates without interrupting their services. Containers, or isolated environments that include everything needed for an application to run, make it easy for developers to edit and deploy apps on the fly. Thus, containerization has become a preferred method for packaging, deploying and updating distributed web applications. Of course, managing such apps across more than one machine can get complicated very quickly. That’s why Google set out to develop an open source system that would simplify the “deployment, scaling and operations” of containerized applications across multiple hosts. The result was Kubernetes, which allows developers to create and manage “clusters” of physical and virtual machines in order to coordinate cooperation via a shared network.
The benefits of Kubernetes
Kubernetes alleviates the burdens of manually managing your containers in a large scale production environment. If set up properly, Kubernetes can save developers time and money by automating infrastructure resource management. For example, when an instance fails, Kubernetes automatically re-creates it. The end result is a smoother user experience and less downtime for your apps. Using Kubernetes comes with a learning curve, but the rewards are well worth the effort.
A Kubernetes cluster is a network of containers capable of communicating with each other. You can have a small cluster that runs on just one machine, or you can make massive clusters that operate across several machines. Machines in a cluster are assigned specific roles. A Kubernetes cluster typically consists of:
The master server
The master server is the primary machine responsible for facilitating communication between the cluster’s different components. The master server uses what’s called a declarative plan to run applications most efficiently using the available infrastructure.
The other machines in a Kubernetes cluster act as nodes that perform workloads with the assistance of local and external resources. Nodes communicate with the master through an agent called a kubelet. Configuration data for each node is stored in a distributed key-value store known as etcd.
Each node must have a container runtime, such as Docker, to process instructions from the master server. Docker’s job, of course, is to create and manage containers.
Containers need a network and IP addresses to facilitate communication. Web developers have several Kubernetes networks to choose from.
The Kubernetes API
End users can interact with the cluster via the main API, and developers control their containerized applications using a command line tool called kubectl. These components all work together to ensure that the desired state of an application matches the state of the cluster. A deeper look into Kubernetes’s inner workings could take up several web pages. Fortunately, the official Kubernetes documentation has all of that information. The Kubernetes website also has several interactive tutorials.
Objects and workloads
The Kubernetes object model provides primitives allowing developers to define workloads, facilitate scaling and interact with objects. These are the main types of objects and workloads you’ll be dealing with:
Containers are themselves contained in objects called pods. Pods are made up of one or more containers that work together and share a life cycle on the same node. For example, a pod may consist of a main container that runs the application server and a helper container responsible for retrieving files when it detects changes to external repositories. Kubernetes clusters manage each pod as a single unit.
Replication controllers and sets
Replication controllers and replication sets make horizontal scaling possible by defining pod templates and creating replicas to distribute workloads.
Deployments are the high-level objects that developers work with directly to manage the life cycles of pods. They describe the desired state of an application. When deployments get modified, Kubernetes automatically adjusts all replica sets, which makes it possible to perform updates without affecting application availability.
Pods are only accessible within their Kubernetes cluster, so to make your applications available to the outside word, pods must be exposed as services. A Kubernetes service groups together related pods and presents them to end users as a single entity.
Getting started with Kubernetes
Before you can start creating clusters with Kubernetes, you must download and install several things. For the purposes of this tutorial, we’ll need:
- Minikube, a lightweight distribution that lets you run Kubernetes clusters locally
- A virtualization software like VirtualBox
- Kubectl, the command line client for Kubernetes
- A container runtime like Docker
Creating a cluster
Let’s learn how to create a simple cluster using Kubernetes. We’ll use Minikube to create a small virtual machine and deploy a cluster with just one node.
1. Install VirtualBox
Download VirtualBox and follow the installation instructions for your OS. Alternatively, you can use KVM2 or any hypervisor you prefer.
2 Install Kubectl
Kubectl is how you, the developer, interact with your clusters. You can download kubectl and find installation instructions on the Kubernetes website.
3. Install Docker
4. Install Minikube
See the Minikube docs for everything you need to set up Minikube for Windows, Mac or Linux.
5. Run Minikube
After all that set up, creating a cluster requires just a single step. From the command line, enter:
Now, to confirm that your cluster is running, enter:
kubectl get nodes
If done correctly, you should see some information about your cluster such as its status and a version number.
If you followed the steps above and installed Minikube, then kubectl should have automatically configured itself to access the cluster you created. You can confirm this with the following command:
~/.kube/config file defines which API endpoints and clusters kubectl can access. Determining which cluster kubectl interacts with is referred to as “setting the context.” To see all of your available contexts, use this command:
kubectl config use-context minikube
You can change the context using the
KUBECONFIG variable. If everything was correctly configured, you should be able to open the Kubernetes dashboard in a browser with this command:
The Kubernetes dashboard
The Kubernetes dashboard tells you everything you need to know about your cluster. To determine if your dashboard is up and running, enter this command:
kubectl get pods -n kube-system
Look for an entry that begins with
kubernetes-dashboard. Before you can view your dashboard, you must run the following command to proxy to the API:
Now, the Kubernetes API will be available at
http://localhost:8001. To open your dashboard in a browser, visit the following URL:
Creating a service
As mentioned earlier, pods are initially only accessible via their internal IP addresses within a cluster. To make your containers accessible outside of Kubernetes, pods must be exposed as services. A Kubernetes service is basically an internal load balancer that serves as an ambassador for pods. To expose a pod, use this kubectl command:
kubectl expose deployment hello-node --type=LoadBalancer
--type=LoadBalancer flag lets Kubernetes know that you want to expose the service to the public. Just replace
hello-node with the name of your application’s container. You can view your newly created service with this command:
kubectl get services
If your cloud provider supports load balancers, you may be given an external IP address to access the service. If you’re using Minikube, the
--type=LoadBalancer flag makes your service accessible via the minikube service command.
Considering the tool’s complexity and usefulness, it’s hard to believe that Kubernetes is an open source tool. Don’t be intimidated by the seemingly complex architecture and confusing spelling. If you’re working on a big project across multiple machines, Kubernetes can make your life a lot easier.