WHAT IS KUBERNETES?
According to the Kubernetes website,
·
"Kubernetes
is an open-source system for automating deployment, scaling, and management of
containerized applications".
·
Kubernetes comes from
the Greek word κυβερνήτης, which means helmsman or ship
pilot. With this analogy in mind, we can think of Kubernetes as the pilot
on a ship of containers.
·
Kubernetes is also
referred to as k8s (pronounced Kate's), as there are 8
characters between k and s.
·
Kubernetes was started
by Google and, with its v1.0 release in July 2015, Google donated it to
the Cloud
Native Computing Foundation (CNCF),
one of the largest sub-foundations of the Linux Foundation.
·
New Kubernetes versions
are released in 4 month cycles. The current stable version is 1.29 (as of
December 2023).
Kubernetes is a
portable, extensible, open-source platform for managing containerized workloads
and services, that facilitates both declarative configuration and automation. It has a large,
rapidly growing ecosystem. Kubernetes services, support, and tools are widely
available. The name Kubernetes originates from Greek, meaning helmsman or
pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines over 15 years of Google's experience running
production workloads at scale with best-of-breed ideas and practices from the
community
Going back in time
Let's take a look at why Kubernetes is so useful by going
back in time.
Traditional
deployment era: Early on,
organizations ran applications on physical servers. There was no way to define
resource boundaries for applications in a physical server, and this caused
resource allocation issues. For example, if multiple applications run on a
physical server, there can be instances where one application would take up
most of the resources, and as a result, the other applications would
underperform. A solution for this would be to run each application on a
different physical server. But this did not scale as resources were
underutilized, and it was expensive for organizations to maintain many physical
servers.
Virtualized
deployment era: As a solution, virtualization was introduced.
It allows you to run multiple Virtual Machines (VMs) on a single physical
server's CPU. Virtualization allows applications to be isolated between VMs and
provides a level of security as the information of one application cannot be
freely accessed by another application.
Virtualization allows
better utilization of resources in a physical server and allows better
scalability because an application can be added or updated easily, reduces
hardware costs, and much more. With virtualization you can present a set of
physical resources as a cluster of disposable virtual machines.
Each VM is a full
machine running all the components, including its own operating system, on top
of the virtualized hardware.
Container
deployment era: Containers are
similar to VMs, but they have relaxed isolation properties to share the
Operating System (OS) among the applications. Therefore, containers are
considered lightweight. Similar to a VM, a container has its own filesystem,
share of CPU, memory, process space, and more. As they are decoupled from the
underlying infrastructure, they are portable across clouds and OS
distributions.
Containers have become
popular because they provide extra benefits, such as:
- Agile application
creation and deployment: increased ease and efficiency of container image
creation compared to VM image use.
- Continuous
development, integration, and deployment: provides for reliable and frequent
container image build and deployment with quick and easy rollbacks (due to
image immutability).
- Dev and Ops separation
of concerns: create application container images at build/release time rather
than deployment time, thereby decoupling applications from infrastructure.
- Observability not only
surfaces OS-level information and metrics, but also application health and
other signals.
- Environmental
consistency across development, testing, and production: Runs the same on a
laptop as it does in the cloud.
- Cloud and OS
distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-premises, on major
public clouds, and anywhere else.
- Application-centric
management: Raises the level of abstraction from running an OS on virtual
hardware to running an application on an OS using logical resources.
- Loosely coupled,
distributed, elastic, liberated micro-services: applications are broken into
smaller, independent pieces and can be deployed and managed dynamically – not a
monolithic stack running on one big single-purpose machine.
- Resource isolation:
predictable application performance.
- Resource utilization:
high efficiency and density
Why you need Kubernetes and what it can do
Containers are a good
way to bundle and run your applications. In a production environment, you need
to manage the containers that run the applications and ensure that there is no
downtime. For example, if a container goes down, another container needs to
start. Wouldn't it be easier if this behavior was handled by a system?
That's how Kubernetes
comes to the rescue! Kubernetes provides you with a framework to run
distributed systems resiliently. It takes care of scaling and failover for your
application, provides deployment patterns, and more. For example, Kubernetes
can easily manage a canary deployment for your system.
Kubernetes provides
you with:
- Service discovery and load balancing Kubernetes can expose a container using
the DNS name or using their own IP address. If traffic to a container is high,
Kubernetes is able to load balance and distribute the network traffic so that
the deployment is stable.
- Storage orchestration Kubernetes allows you to automatically mount a storage
system of your choice, such as local storages, public cloud providers, and
more.
- Automated rollouts and rollbacks You can describe the desired state for
your deployed containers using Kubernetes, and it can change the actual state
to the desired state at a controlled rate. For example, you can automate
Kubernetes to create new containers for your deployment, remove existing
containers and adopt all their resources to the new container.
- Automatic bin packing You provide Kubernetes with a cluster of nodes that it can
use to run containerized tasks. You tell Kubernetes how much CPU and memory
(RAM) each container needs. Kubernetes can fit containers onto your nodes to
make the best use of your resources.
- Self-healing Kubernetes restarts containers that fail, replaces
containers, kills containers that don't respond to your user-defined health
check, and doesn't advertise them to clients until they are ready to serve.
- Secret and configuration management Kubernetes lets you store and manage
sensitive information, such as passwords, OAuth tokens, and SSH keys. You can
deploy and update secrets and application configuration without rebuilding your
container images, and without exposing secrets in your stack configuration.
The architecture of
Kubernetes(Master/Worker Node)
What happens in the Kubernetes control plane?
Control plane
Let’s begin in the nerve center of our Kubernetes cluster: The
control plane. Here we find the Kubernetes components that control the cluster,
along with data about the cluster’s state and configuration. These core
Kubernetes components handle the important work of making sure your containers
are running in sufficient numbers and with the necessary resources.
The control plane is in constant contact with your compute
machines. You’ve configured your cluster to run a certain way. The control
plane makes sure it does.
kube-apiserver
Need to interact with your Kubernetes cluster? Talk to the API.
The Kubernetes API is the front
end of the Kubernetes control plane, handling internal and external requests.
The API server determines if a request is valid and, if it is, processes it.
You can access the API through REST calls, through the kubectl command-line
interface, or through other command-line tools such as kubeadm.
kube-scheduler
Is your cluster healthy? If new containers are needed, where will
they fit? These are the concerns of the Kubernetes scheduler.
The scheduler considers the resource needs of a pod, such as CPU
or memory, along with the health of the cluster. Then it schedules the pod to
an appropriate compute node.
kube-controller-manager
Controllers take care of actually running the cluster, and the
Kubernetes controller-manager contains several controller functions in one. One
controller consults the scheduler and makes sure the correct number of pods is
running. If a pod goes down, another controller notices and responds. A controller
connects services to pods, so requests go to the right endpoints. And there are
controllers for creating accounts and API access tokens.
etcd
Configuration data
and information about the state of the cluster lives in etcd, a key-value store
database. Fault-tolerant and distributed, etcd is designed to be the ultimate
source of truth about your cluster.
What happens in a Kubernetes node?
Nodes
A Kubernetes cluster needs at least one compute node, but will
normally have many. Pods are scheduled and orchestrated to run on nodes.
Need to scale up the capacity of your cluster? Add more nodes.
Pods
A pod is the smallest and simplest unit in the Kubernetes object
model. It represents a single instance of an application. Each pod is made
up of a container or a series of tightly coupled containers, along with options
that govern how the containers are run. Pods can be connected to persistent
storage in order to run stateful applications.
Container runtime engine
To run the containers, each compute node has a container runtime
engine. Docker is one
example, but Kubernetes supports other Open Container Initiative-compliant
runtimes as well, such as rkt and CRI-O.
kubelet
Each compute node contains a kubelet, a tiny application that
communicates with the control plane. The kublet makes sure containers are
running in a pod. When the control plane needs something to happen in a node,
the kubelet executes the action.
kube-proxy
Each compute node also contains kube-proxy, a network
proxy for facilitating Kubernetes networking services. The kube-proxy handles
network communications inside or outside of your cluster—relying either on your
operating system’s packet filtering layer, or forwarding the traffic itself
No comments:
Post a Comment