Hello, and welcome to our series covering Kubernetes.
This time I will introduce, and define, some basic terminology you will encounter on your
journey into the Kubernetes world.
As mentioned previously, Kubernetes has a steep learning curve...
All too often this begins with the terminology being used.
So if you know what these terms are referring to, their relevance should become clearer
for you.
So let's get started with:
The Pod
Pods are the basic building block of Kubernetes and are used to define the application.
They may consist of a single container, or more usually multiple containers.
A Pod may be deployed onto a single Worker node, or multiple nodes, within the Kubernetes
cluster.
The composition of the Pod is defined by the application's deployment definition - which
we'll introduce later.
The Pods themselves very often require extra configuration in order to work correctly and
these are known as Secrets and ConfigMap.
So let's start off with Secrets.
Secrets represent sensitive data that you want to manage access to
By default they use Base64 encoding, so aren't really a security feature, instead they prevent
casual observers from accessing this data.
Next up there's the ConfigMap
This is just a resource definition that can be loaded into a Pod.
It can be key-value pair, a body of text or even a binary file.
ConfigMaps can be Application specific, or settings that are shared with many Pods.
They are read-only, meaning that the Pods themselves cannot alter a ConfigMap.
However there is more to deploying an application than simply defining which containers to execute.
What about how to deploy it, or how does it communicate to your customers, or what to
do if a Node goes down, etc?
This is where these next terms enter into the picture.
So let's take a look at this, starting with Deployment
This instructs Kubernetes how to deploy your application.
For example you may specify that your application is deployed as two replica Pods each consisting
of a single container - in this instance the Pods could be split across two Worker nodes.
In a different deployment, your application may consist of one Pod consisting of two containers
- in this instance the containers will remain on the single Worker node, because a Pod cannot
be split across more than one node.
The next term, the ReplicaSet, is used to ensure the application's desired state is
maintained.
To do this the ReplicaSet describes the structure of the deployed application.
It is the ReplicaSet that manages the availability of a pre-defined number of pods running within
the deployment at all times.
The ReplicaSet process achieves this by starting, monitoring, and restarting Pods as needed.
But what use is an application that can not communicate with your customers across the
intranet, or internet?
This is where the Service helps by providing the mechanism to expose the application's
Pod, or Pods, for network access.
They may enable network traffic to communicate between Pods in the cluster, or may enable
communication to/from the external world.
So last, but not least, there are a couple more terms you will often hear - which are
External resources and StatefulSet.
Let's cover them in the same oder, starting with 'External Resources'
This refers to anything that enables the containers within a Pod to access external resources,
such as physical storage which is handed by 'Volumes', or configuration which is handed
by a mixture of 'ConfigMaps' and 'Secrets' - both of which I introduced at the start
of this video.
So the last term we'll cover today is the StatefulSet
This is used in deployments where there is for example a requirement to start Pods in
set order, or assign them defined unique identifiers.
In other words this ensures consistent identities are always applied.
These identities represent things such as network definitions, storage, etc.
Say for example, your application consists of a web-based application which is reliant
on an underlying database.
In this instance the start process would ensure the database is up & running prior to starting
the web-based application.
For now, that is probably enough detail, because each of these concepts can become complicated
very quickly so they're best left to be covered on another day.
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.