Understanding the chaos: VCF by "VMware by Broadcom"

 

Being in and around the VMware space for around 7 years, I believe it is my inherent responsibility to give “VMware by Broadcom” a chance to explain why and what happened after the acquisition.

When Broadcom revised the VMware Solution ecosystem, it absolutely failed to communicate to the customers, the intent and vision behind the transition to the cloud/platform operating model and we have all witnessed that this definitely created a big drift in understanding and adoption of this idea.

It has been challenging for all of us to get that mindshare and the customers also failed to get that transitional momentum. This is due to the fact that the infrastructure is divided between different teams in most organizations. There is an infrastructure team, there are developers and designers, the Windows, Unix, Storage, Network, Network Security, Cybersecurity, monitoring teams and so on.

It is very true that any form of a digital transformation strategy has a People’s piece and a Process piece to it apart from the obvious Financial and Technology perspective.

By not being able to corelate the IT Piece to People and the Process piece, created a certain drift and there you see a lot of blogs and YouTube videos posting about how VMware is dying after the Broadcom acquisition.

Let’s not forget, VMware is at the very core of many digital transformation strategies by bringing to the market their most selling product which all of us know by the name of vSphere.

The customers took vSphere at the center, added the Storage and Network, wrapped it up with Security and there you go, that is the simplest expression/definition of any traditional IT Infrastructure.

But, as Customers embarked on their respective digital transformation journeys, they tried to modernize their infrastructure services and bring cloud methodologies to it. However, due to the fact that they lacked a lot of Integrations and APIs that were essential to the delivery of these services, the thought process of modernization did not flourish well with the traditional 3 Tier architecture. This bought hinderance in scaling up and innovation.

This big gap between the provisioning and the delivery of the services using traditional infrastructure led to adoption of Cloud Migrations strategies and customers rapidly started moving their applications to public clouds.

We may all agree that the public clouds definitely have the right architecture in terms of running a Software defined Architecture on x86 hardware. On top of that, by orchestrating and automating the processes, they allow for the delivery of the consumption layer with much ease.

Migrating to public cloud is not new and while it is so essential, I want to state some facts.

As per the IDC White Paper - August 2024, 51% customers are concerned with privacy and 39% customers consider cloud migration expensive and complex to manage.

In my personal opinion, the application that are not optimized for the cloud should never be migrated to the public cloud unless you are willing to pay heavy bills.

All of what you read above was either factual or my personal opinion. Now, I will conclude this blog with my understanding about VCF.

With the adoption of VCF, your own IT admins who have been managing your Virtual Infrastructure till now, will be empowered with the tools they will require to build, deploy and operate a private cloud infrastructure and using cloud methodologies as a part of that. They will have tools for capacity management so that they can operate at scale, not just around On-premise but globally deployed infrastructure as well. The ability to provide flexibility in order to Modernize with Security and resilience is what our customers have been looking for.

 

 

 

What happens when you run a kubectl command?

 I will start this blog with a fun fact:

Do you know why Kubernetes is also referred to as K8s.

Because, there are 8 letters between the alphabet K and S.

 

Okay! Now, let’s start this blog by answering this very important question, What happens when you run a kubectl command?

Note:The crux of this blog will revolve more around the architecture of Kubernetes.

What is Kubectl?

In simple words, Kubectl is a command line tool to interact with the Kubernetes cluster and It looks like this,

Kuberctl run nginx –image-nginx

For the purpose of this blog, I will assume that your Kubernetes cluster is deployed and you have all the necessary components in place. 

LET’S RUN THE POD NOW!!

Type Kuberctl run nginx –image-nginx to run nginx (NGINX is a web server) pod .  

With this command, we are basically telling Kubernetes that we want to run our nginx  container in our cluster.

This request first goes to API server.

Note : When we are talk about kubernetes, we have to consider that we will be dealing with some machines. It can be BareMetal machines, Raspberry PI or Virtual Machines. In this case, let’s say we have two virtual machines.

We will call one VM as worker node and another VM as control plane node. When we issued a command to run NGINX , it will run on the worker node, which means, this VM will be actually running our NGINX container.

And the control plane node will manage everything.

Let’s discuss mode about control plane node and how the container is getting managed.

 

What is API server?

API server: It is the main brain of Kubernetes. Anything that you are doing with kubernetes will go to API server. All the calls that you provide either with YAML file or JSON file or CLI  goes to the API Server

After running Kuberctl run nginx –image-nginx to run nginx pod command ,

- The API Server will perform Authentication, Authorization, Admission.

- User is authenticated with the headers passed, then Authorized by RBAC.

- Admission will be done as per the policies. It will check and validate the kubectl command parameter       and validate it.

- Then, it will saved in ETCD.

What is ETCD?

It is a component in the control plane node which acts as key value store for kubernetes cluster.  All the cluster states and cluster information is saved in ETCD.

For HA, we need 3 ETCD nodes following (2n+1) formula where n is FTT value. In case of ETCD, RAFT Algorithm is used to conduct the election and choose Master and Slave between the multiple  ETCD nodes.

After API server perform the authentication, authorization and admission of the request to run NGINX container.

Kube Scheduler comes into the picture.

Kube Scheduler?

The job of the scheduler is to find the best fit node to run the pod.

Scheduler is aware about the capacity of the worker node. Since, it has all the information, it intelligently chooses the appropriate node where the pod should be running.

Once the labels are updated in the pod, it will pass on this information to API Server and API Server will save this information ETCD.

Note: Only API Server will talk to ETCD. Rest all other components will only talk to the API Server.

All this was happening in the control plane node. Now, the process moves on the the worker node. In this section we will talk about the major components in the worker node starting with Kubelet.

What is a Kubelet:  

Kubelet is the component in the worker node which keeps on polling API server to check if any container/pod needs to run.

In the control plane node, Kube-scheduler  always keeps track of what and where the container needs to run. As soon as the API Server, get the message from the Kube Scheduler that a container needs to run, it will inform the kubelet.

Informing the Kubelet involves passing on full information about the container/pod to the Kubelet. Now the Kubelet has all the information about the container.

Kubelet will then talk to CRI (controller Runtime Interface) , CNI (Controller Network Interface) and CSI (Controller Storage Interface). Some processes which go on during this step are fetching the image from the registry, attaching the network, setting the IP Address, attaching the storage.

What is Kube-Proxy?

Kube-Proxy is the component in the worker node which maintains the network rules on the node. The pods need to communicate with the pods in the same  node or pods in the different node. The network rules maintained by kube-proxy aloows network communication to pod from the network sessions inside or outside of your cluster.

 Now, that Scheduler has decided and Kubelet has initiated the process, we will have a running container/pod in the node chosen by the Kube-Scheduler.

Disclaimer: The process explained above is not the technical deep dive into Kubernetes, rather in this blog I have mentioned only a few major components in the Kubernetes Architecture. The intend to write this blog is to give you a fair idea about  how the container/pod is created.

KUBERNETES universe is very vast and there is much much more to it. 

 

Keep Learning || Keep Sharing  :)