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

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

  • PersistentVolume defines a storage volume independent of the normal Pod-lifecycle. It’s managed outside of the particular Pod that it resides in.
  • 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.

  1. Environment – developmenttestproduction
  2. App version – beta1.2.1
  3. Type – clientserverdb



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

K8s Namespaces


Avoid creating namespace with prefix kube-, since it is reserved for Kubernetes system namespaces.
You can list the current namespaces in a cluster using
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
  • default The default namespace for objects with no other namespace
  • kube-system The namespace for objects created by the Kubernetes system
  • kube-public This 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.yaml format.

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 namespace
  • 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.
  • status describes 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
  name: nginx-deployment
  replicas: 2 #tells deployment to run 2 pods
        app: nginx
      - name: nginx
        image: library/nginx:1.16
        - 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.




Leave a Reply

Your email address will not be published. Required fields are marked *