Project Pacific Project Pacific is a re-architecture of vSphere with Kubernetes as its control plane. To a developer, Project Pacific looks like a Kubernetes cluster where they can use Kubernetes declarative syntax to manage cloud resources like virtual machines, disks and networks. To the IT admin, Project Pacific looks like vSphere – but with the new ability to manage a whole application instead of always dealing with the individual VMs that make it up. Project Pacific will enable enterprises to accelerate development and operation of modern apps on  VMware vSphere  while continuing to take advantage of existing investments in technology, tools and skillsets. By leveraging Kubernetes as the control plane of vSphere, Project Pacific will enable developers and IT operators to build and manage apps comprised of containers and/or virtual machines. This approach will allow enterprises to leverage a single platform to operate existing and modern apps side-by-side. The

vMotion VMware vMotion enables the live migration of running virtual machines from one physical server to another with zero downtime, continuous service availability, and complete transaction integrity. It is transparent to users. vMotion advantage: Automatically optimize and allocate entire pools of resources for maximum hardware utilization and availability. Perform hardware maintenance without any scheduled downtime. Proactively migrate virtual machines away from failing or underperforming servers. Virtual machine and its host must meet resource and configuration requirements for the virtual machine files and disks to be migrated with vMotion in the absence of shared storage. vMotion in an environment without shared storage is subject to the following requirements and limitations: The hosts must be licensed for vMotion. The hosts must be running  ESXi  5.1 or later. The hosts must meet the networking requirement for vMotion. See  vSphere vMotion Net

Enhanced vMotion (EVC) vSphere Enhanced vMotion is a feature through which workload can be live migrated from one ESXi host to another ESXi host which are running on different CPU generation but with same cpu vendor. EVC in vSphere was introduced in vSphere 5.1 using vMotion and Storage vMotion terminology. EVC can be enabled at the vSphere ESXi Cluster and on VM's. Figure 1 VMware EVC Mode works by masking unsupported processor having different generation of same vendor and presenting a homogeneous processor to all the vm's in a cluster. The benefit of EVC is that you can add ESXi host consist of latest processors to exising cluster without incurring any downtime. The VMware Compatibility Guide is the best way to determine which EVC modes are compatible with the processors used in your cluster.  Below in  figure 1 demonstrates how to determine which EVC mode to use given 3 types of Intel processors. https://www.vmware.com/resources/compatibility/s

Rolling Updates and Rollbacks in K8s In our environment everyone has several application deployed and running successfully. Each application comes with a version and time by time application vendor releases new version of it where new version consist of new features and previous bug fixes. Now, its become must task to update our applications to leverage new features. So, how will be make the strategy to upgrade our applications into production environment. Its quite difficult to update all the application at once as it would hamper the stability of the environment. In Kubernetes there is default strategy of deployment called Rolling updates where we do not destroy all the application at one, instead we bring down the application older version and bring back the new version of the application one by one. By doing this application never goes down and upgrade is seamless. It's require to specify the upgrade strategy into the deployment. If there is no suc

Monitoring cluster components  of Kubernetes (K8s) There are various type of monitoring we can perform at the cluster, node level and pod level. At cluster level we can monitor like number nodes running, how many are healthy, performance status, network usage etc.   At the POD level we can monitor disk and cpu, memory utilisation, Performance metrics of each POD about its resources. To utilise the experience of monitoring on kubernetes cluster we can use “ Metrics server ”  We can have 1 metrics server per cluster. It's retrieves the information about Nodes , PODS aggregate them and store them into memory.  Matrics server is IN-MEMORY solution where the data or information which it fatch from nodes and pod will be in memory and does not store it in disk.  As Metrics server is " IN-MEMORY " where it's not possible to retrieve the historical data about the kubernetes resources. To get the historical data its require to use advance to

What Is Kubernetes..... Running a container on a laptop is relatively simple. But, connecting containers across multiple hosts, scaling them, deploying applications without downtime, and service discovery among several aspects, can be difficult.                                             Kubernetes is the one which addresses those challenges from the start with a set of primitives and a powerful open and extensible API. The ability to add new objects and controllers allows easy customization for various production needs.  According to the  kubernetes.io  website, Kubernetes is:  "an open-source system for automating deployment, scaling, and management of containerized applications".  Kubernetes is that it builds on 15 years of experience at Google in a project called borg.   Kubernetes is inspired by Borg - the internal system used by Google to manage its applications (e.g. Gmail, Apps, GCE). Methodology of Kubernetes Deploying c