The word Kubernetes comes from the Greek word 'Helmsman'. A helmsman is the person who navigates the ship ensuring the steady and desired course. Whether the seas are turbulent or not, or if some component of ship fails, or the load of containers on ship needs to be re-balanced; its the job of Helmsman or Kubernetes to make sure ship maintains its desired state until it reaches its destination.
For managing software containers, then, Kubernetes seems like an apt name. These containers comprise of the ready-to-run code, code's run-time, and code dependencies. These containers are then encapsulated within abstraction of Pods. Pods are container of one ore more containers which are tightly coupled. These Pods are then abstracted into Replicaset which are copies of the pods for high availability. These replicasets are abstracted into Deployment which is a stateless object of Kubernetes. Then there is Service object of Kubernetes which exposes the application to the networks connected to the Kubernetes cluster. All of these objects run in data plane section of Kubernetes.
In order to manage all the deployments, services, pods, and other objects Kubernetes has master nodes in something called as Control Plane. This control plane interfaces with data plane through api server. Then there are controllers to ensure desired state of nodes, pods and other objects in data plane, Scheduler to to schedule new pods on pertinent nodes, ETCD key-value persistent data store to store configuration and state of your whole Kubernetes cluster, cloud provider specific cloud manager etc.
Just step back a bit and think why we are doing this? All of this complexity just to provision a software in stead and reliable way? Isn't developing software complicated enough that we have to resort to such complexity to manage it? That is why it makes sense to delegate management of Kubernetes Control Plane to a Managed Kubernetes Service provider like Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), Linode Kubernetes Service (LKS), and there are few others.
Why not focus more and more on making software aligned to user expectations and experience rather than managing the software needed to provision and maintain this software? Other than Kubernetes, modern software also has to reside in some git oriented repository, follow the agile methodology, go through a pipeline, get packaged into a container image and then mounted on Kubernetes. Handing over management of Kubernetes control plane, and some part of data plane to a managed service only makes sense. All the managed service providers mentioned above and few others are Cloud Native Computing Foundation (CNCF) certified. They go through rigorous security and compliance checks all the time. They keep the K8s versions updated and stable and much more.
If you are running Kubernetes on-prem or in cloud and still managing its control plane by itself, I will be very interested to learn the reason behind it. Please share in the comments. Thanks.
For managing software containers, then, Kubernetes seems like an apt name. These containers comprise of the ready-to-run code, code's run-time, and code dependencies. These containers are then encapsulated within abstraction of Pods. Pods are container of one ore more containers which are tightly coupled. These Pods are then abstracted into Replicaset which are copies of the pods for high availability. These replicasets are abstracted into Deployment which is a stateless object of Kubernetes. Then there is Service object of Kubernetes which exposes the application to the networks connected to the Kubernetes cluster. All of these objects run in data plane section of Kubernetes.
In order to manage all the deployments, services, pods, and other objects Kubernetes has master nodes in something called as Control Plane. This control plane interfaces with data plane through api server. Then there are controllers to ensure desired state of nodes, pods and other objects in data plane, Scheduler to to schedule new pods on pertinent nodes, ETCD key-value persistent data store to store configuration and state of your whole Kubernetes cluster, cloud provider specific cloud manager etc.
Just step back a bit and think why we are doing this? All of this complexity just to provision a software in stead and reliable way? Isn't developing software complicated enough that we have to resort to such complexity to manage it? That is why it makes sense to delegate management of Kubernetes Control Plane to a Managed Kubernetes Service provider like Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), Linode Kubernetes Service (LKS), and there are few others.
Why not focus more and more on making software aligned to user expectations and experience rather than managing the software needed to provision and maintain this software? Other than Kubernetes, modern software also has to reside in some git oriented repository, follow the agile methodology, go through a pipeline, get packaged into a container image and then mounted on Kubernetes. Handing over management of Kubernetes control plane, and some part of data plane to a managed service only makes sense. All the managed service providers mentioned above and few others are Cloud Native Computing Foundation (CNCF) certified. They go through rigorous security and compliance checks all the time. They keep the K8s versions updated and stable and much more.
If you are running Kubernetes on-prem or in cloud and still managing its control plane by itself, I will be very interested to learn the reason behind it. Please share in the comments. Thanks.
No comments:
Post a Comment