A pod is the basic object of Kubernetes. It is in charge of encapsulating containers, storage resources, and network IPs.
One pod represents one instance of an application in Kubernetes. These pods are launched in a kubernetes cluster which is composed of nodes. A node is a worker machine (Vm or physical machine) that has a container runtime environment. This means that a pod runs on a node but can easily be instantiated on another node (for fault tolerance reason per example)
Pods are meant to be ephemeral in fact Kubernetes can scale the number of these pods to adapt for incoming traffic, consequently creating or deleting pods on demand.
You may be wondering how does Kubernetes manage traffic to this wavering number of pods, it all about the services.
Services / Ingress
The mortal nature of pods makes them unreliable for traffic delivery. Kubernetes’ solution is Service. It is an abstraction that maintains a logical list of pods that accept incoming traffic and expose an internal port to access the underlying pods.
Kubernetes service can hence manage changes in traffic by modifying the number of pods.
If your application needs to be accessed from outside your cluster, Kubernetes offers a component called Ingress. It sits on top of a service and manages external requests with SSL encryption.
You may ask yourself how does Kubernetes manage the scaling of pods and how can you manage their upgrade. Kubernetes’ solution for this is deployments.
Deployments are Kubernetes objects that manage pods. They allow you to deploy a specific version of your application and specify the number of pods you require for it to be operational.
When a new version is ready to go live in production, deployment can easily manage this upgrade with no downtime by applying two basic rules:
- maxSurge specifies the maximum number of pods that can be created beyond the desired pod count.
- Max Unavailable specifies the maximum number of pods that can be unavailable during the deployment.
These nodes are scheduled onto different nodes of the cluster and can be moved from one another seemingly.
With such ease to deploy and upgrade applications, you should never forget to test your application in a staging environment. You want of course to have all of your environments being independent, for that Kubernetes uses configmaps and secrets.
Configmap / Secrets
Configmap is a Kubernetes object that maintains a key value store that can easily be used by other Kubernetes objects such as pod, deployments, and services.
Thus you can define a configmap composed of all the specific variables for your environment.
Your security alert should be tingling right now, putting a password in plain text!
Kubernetes hopefully has a way to manage secrets.
It allows you to store sensitive information safely within kubernetes thanks to role based access and a specific way of sharing the secret with the pod that does not write it to the disk. You can encrypt all these secrets at rest with EncryptionConfiguration.
To finish off this presentation of Kubernetes essentials, one of the most used features is cronjobs. They are used to execute a task periodically, which in Kubernetes means launching an idempotent pod at a specific time of the day and then delete it when the job is finished. Hence not having pod continuously consume cpu resources for no reason.
schedule: "*/1 * * * *"
Kubernetes is one of the most mature container orchestrating platform on the market, with a robust set of tools that ensures reliability and maintainability. If you want to try and build your first cluster to play around with pods and services you can read this article or this one if you need to know the basic commands on kubernetes [kubectl] and to further learn about kubernetes.