Hello, and welcome to our series covering Kubernetes.
So why Kubernetes?
Well, it's probably fair to say that most administrators, these days, have already heard
of Kubernetes
If so you'll hopefully be aware that Kubernetes' primary purpose is to simplify the management
of large container-based deployments.
You are probably already aware how easy it is to run a single instance of an application
using Podman.
But it's unlikely that you'd deploy into production on a single node.
So imagine having to manually deploy, and manage this across your production cluster.
Keeping track of, and managing, all of the individual container's states would most likely
very quickly become a nightmare administrative task.
This is what Kubernetes was designed to simplify.
Something it achieves by acting as an interface between the underlying cluster machines and
the application, or applications, you have deployed onto them.
Thereby freeing the DevOps team from having to manually monitor, and react too, any infrastructure-related
issues that may arise.
This includes events such as:
* horizontal scaling - bring new nodes online as load fluctuates, or during the rollout
of application updates * load-balancing - ensuring load is distributed
across a cluster evenly * self-healing - restarting an application
as, when or if needed
So what's not to like about a system that reduces the likelihood of getting a panicked
midnight call to resolve an outage?
It can also help to automatically rollout new updates to existing deployments; either
across the entire cluster, or even a sub-section of the cluster (for testing purposes).
If that isn't enough to persuade you of its usefulness, then perhaps the fact that it
has an open architecture which numerous vendors use to provide plugins covering things like
storage, networking, security, etc.
Kubernetes is even open with regard to the container runtime you can use; we use Podman
in our case, or even alternatives such as CRI-O, Docker, etc.
So what architecture do you need to use Kubernetes?
The minimum requirement is a cluster of computers also known as nodes.
So what defines a node?
Well, a node a machine, which may be virtual or physical, where an operating system & Kubernetes
has been installed.
In the Kubernetes world each node is assigned to one of two roles (which are known as planes);
either a Control Plane, or the Workload Plane.
This means your cluster is divided into two groups:
* The Control nodes which run the Control Plane Kubernetes components; their role is
to control the whole of the cluster.
* The Worker Nodes which together comprise the Workload Plane; their role is run the
applications deployed onto them.
Both of these planes combine to make a working Kubernetes cluster, but how do they achieve
this?
The Control Plane acts like the cluster's 'brain' and can be a single node, or more
usually a cluster itself.
So let's look more closely at one of the Control Nodes Kubernetes components:
* API Server - processes and validates RESTful requests, and executes the operation
* Scheduler - controls & tracks which worker node each application is executing on
* Controllers - act on deployed applications via API Server requests
* etcd - undertakes all networking functions and routes network traffic
Remember the Control Plane node, or nodes, do not run your applications, that is what
the Workload Plane's nodes role is...
Each Worker node within the Workload Plane is instructed by the Control Plane to run,
monitor and provide connectivity for any application deployed onto this Kubernetes cluster.
Now let's look at one of the Worker node's Kubernetes components:
* Kubelet - An agent that allows nodes to communicate with the API server
* Proxy - provides network functionality including load-balancing, routing, etc.
* Pod - This requires a container runtime which is Podman on Oracle Linux or Oracle
Cloud Native Environment installs, but can be any other such runtime on other Linux releases
- for example Docker, etc.
You wouldn't be the first person who may be thinking that all of this seems to be very
complex, and indeed it is.
Kubernetes is well known for having a very steep learning curve.
However it replays the time invested through the functionality it delivers in the day-to-day
management of your deployed applications.
In short if you have a medium to large Microservice based application to be deployed then Kubernetes
is probably worth the investment in time, effort & expenditure for your admin team to
learn.
However, please remember that whilst Kubernetes is designed to make managing complex applications
deployments easier (managing & monitoring availability, etc), it is not big a 'one stop'
shop for everything.
This means there are some limitations to what Kubernetes can manage for you, for example:
* It cannot create the Nodes used for the Worker or Control Plane Nodes - these need
to be created and then made available for Kubernetes to use.
* It cannot install itself onto a Node - someone else has to install it
* It cannot create any other resources that it may subsequently be needed for use, for
example it can't install filesystems for storage, etc.
Kubernetes is however, extremely flexible and very resilient at managing complex micro
service-based deployments.
This completes this overview of what Kubernetes is and how it can help you.
Many thanks for taking the time out to watch, and be sure to keep an eye for further instalments
in this series...
For additional information about Kubernetes please access the Oracle Linux documentation,
or Oracle Linux Learning Library.