Welcome back to the 2nd series of my Kubernetes series This post would be a continuation of my previous post, please click on the link below to read the first post in case you haven’t read it
In my previous post, we looked at important concepts like what is container orchestration, the architecture of a Kubernetes cluster ( Master and Worker node), setting up Minkube locally and basic Kubectl CLI commands.
So this new post (2nd series), we would be covering important concepts such as
- Some elements of Kubernetes Objects like Kubernetes Secrets, ConfigMap, Volumes, Deployment, StatefulSet, Namespace, and Ingress
- K8s Configuration YAML file
Kubernetes Objects are abstractions that represent the state of the service that’s deployed in the cluster.
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
- What containerized applications are running (and on which nodes)
- The resources available to those applications
- The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance
By creating an object, you’re effectively telling the Kubernetes system what you want your cluster’s workload to look like; this is your cluster’s desired state.
Let’s take a look at the different Kubernetes objects, from smallest to biggest. This list is not exhaustive; check out the Kubernetes documentation for more details:
This defines a set of key-value pairs that can be injected into pods, typically as environment variables or files. This allows us to share configurations between different defined pods, for example, a ConfigMap can be used to dynamically set the value of an environment variable.
While ConfigMaps are great for most configuration data, sensitive data like passwords, security tokens, database info(username and password) are very sensitive.
Secrets enable container images to be created without bundling sensitive data. This allows containers to remain portable across environments. Secrets are exposed to Pods via an explicit declaration in Pod manifests and the Kubernetes API.
The files that are inside a container are ephemeral (lasting for a very short time) and will be lost if the container stops its execution.
A volume is a form of persistent storage that can be used to maintain data information and share information between containers in a pod.
For E.g. If you have a pod that has a database, if your pod dies or get restarted, you could lose data, so volume helps you attach physical storage on a hard drive, remote or cloud storage, etc
- A PersistentVolume defines a storage volume independent of the normal Pod-lifecycle. It’s managed outside of the particular Pod that it resides in.
- A PersistentVolumeClaim is a request to use the PersistentVolume by a user.
This is a grouping of one or more identical pods and it helps us handle Stateless apps.
A deployment’s primary purpose is to declare how many replicas of a pod should be running at a time. When a deployment is added to the cluster, it will automatically spin up the requested number of pods, and then monitor if any of the pods die, the deployment will start another until the defined number is reached.
Image source: Google cloud blog
Service is an abstract way to expose an application running on a set of pods as a network service.
Since pods are created and recreated and have different IPs, to allow services to access them, a service needs to define the name that other elements can use to discover it.
In other words, it routes requests to the proper pods.
Labels are key/value pairs that are attached to resources (like Pods) which are used to organize related resources. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users but do not directly imply semantics to the core system.
- Environment –
- App version –
- Type –
While service is internal, an Ingress is external. An ingress is an API object that manages external access to the services in a cluster, typically HTTP.
Ingress may provide load balancing, SSL termination, and name-based virtual hosting.
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.
Depending on your Kubernetes installation, you may need to install an Ingress controller.
StatefulSet is the workload API object used to manage stateful applications like Database.
It manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods.
Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
A job creates one or more pods that are expected to finish. While a deployment will assume that any pod that’s finishing is a problem and will start another, jobs will retry until the proper number of successes is met.
The finished pods are not deleted, which means we can check their logs. Jobs are one-off executions. There are also Cron Jobs, which will run at specific times.
Think of K8s Namespace as a “virtual cluster” inside your Kubernetes cluster.
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
Namespaces are intended for use in environments with many users spread across multiple teams, or projects.
For clusters with a few to tens of users, you should not need to create or think about namespaces at all.
A tech team using K8s could have namespaces for their different resources, e.g Team A working on Database resources, Team B Monitoring resource(e.g. Prometheus), Team C on Logging resource (ELK Stack), and Web server resource (Nginx & Ingress), etc
Avoid creating namespace with prefix
kube-, since it is reserved for Kubernetes system namespaces.
kubectl get namespace
This would be the output
NAME STATUS AGE default Active 14d kube-node-lease Active 14d kube-public Active 14d kube-system Active 14d kubernetes-dashboard Active 16h
defaultThe default namespace for objects with no other namespace
kube-systemThe namespace for objects created by the Kubernetes system
kube-publicThis namespace is created automatically and is readable by all users (including those not authenticated) e.t.c.
If you want to read more about namespaces, you can check out this Google Cloud blog
K8s Configuration YAML file
Now, we have touched on the basics of Kubernetes Objects, we are going to see how these Kubernetes objects can be expressed in a
Object configuration file/configuration file: A file that defines the configuration for a Kubernetes object. Configuration files are typically stored in source control, such as Git.
Overview of the content:
Parts of a Kubernetes configuration file include
apiVersion– Kubernetes API version
kind– the type of object you want to create
metadata– info about the object so that it can be uniquely identified and optional
spec– desired state of the object, you have to set this when you create the object, providing a description of the characteristics you want the resource to have in its desired state.
statusdescribes the current state of the object, supplied and updated by the Kubernetes system and its components. The Kubernetes control plane (master node)continually and actively manages every object’s actual state to match the desired state you supplied.
apiVersion: v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 #tells deployment to run 2 pods template: metadata: labels: app: nginx spec: containers: - name: nginx image: library/nginx:1.16 ports: - containerPort: 5000
We will save this file above as nginx_pod.yml. We’ll create it by using the apply command, set a namespace for it, and monitor that it’s running with the following commands
$ kubectl apply -f nginx_pod.yml --namespace=nginx_example pod/nginx created
$ kubectl get pods --namespace=nginx_example
In this post, we described the different objects (elements) that define a cluster in the Kubernetes nomenclature and Kubernetes configuration file.
The next post would be the last deploying our Dockerized Flask and Vue app which we covered at this post deployed to the Kubernetes cluster.
- Jaime Buelta – Hands-On Docker for Microservices with Python
- Kubernetes docs
- Best practices for K8s configuration file