Just as before, the worker nodes also get their own hidden anti-affinity compute policy that will spread them amongst the hosts.Īlright, so what happens when a physical node fails? As boring as it sounds, vSphere HA does exactly what it’s supposed to do. The control plane nodes are separated for the integrity of etcd, but what about the worker nodes? It’s critical to keep the worker nodes separated on different hosts as much as possible because any Kubernetes deployment that uses multiple replicas will have containers spread across them. When datastores other than vSAN are used, it is recommended to place the three control plane virtual machines on different datastores for availability reasons. If you are a vSAN customer, everything will work as expected out-of-the-box. Each cluster will have its own hidden anti-affinity compute policy created. What about the workload clusters? These same exact rules and policies are applied to workload clusters and their control plane nodes as well. When a host needs to be placed in maintenance mode, vSphere will bend on the policy and allow two control plane nodes to exist on the same host, if necessary. After setup is complete, the hidden anti-affinity compute policy will utilize vMotion to migrate control plane nodes when necessary to make sure they are not on the same host. This will ensure that the Supervisor control plane nodes will not run on the same host.
Never put all your eggs (or, in the case of etcd, a majority of your members) in one basket.ĭuring the deployment process, a firm anti-affinity compute policy is applied to the Supervisor using vSphere ESX Agent Manager. This is crucial to the integrity of the etcd cluster that maintains the state of the Kubernetes cluster that is deployed by default. This satisfies the first rule of availability because the Supervisor Cluster (Kubernetes management cluster) is a three-node control plane. Lastly, a feature of Cluster API plays a vital role for multi-layer availability.Īt minimum, vSphere with Tanzu requires a three-host vSphere cluster for setup and configuration. This will uncover some hidden affinity rules and how that interacts with vSphere functionality. Let’s break this down in a few different ways so we can see how the requirements for vSphere with Tanzu come into play. We know that vSphere HA worked, but how does it function when using vSphere with Tanzu? Something on the physical host failed but thankfully vSphere High Availability (HA) worked just as intended and all your Kubernetes clusters and containers are functional once again. You hustle back to your desk, spill a little coffee on your notepad, and open the VMware vSphere client to see a host in a disconnected state. The notifications say services were down but are now back up. The phone in your pocket begins vibrating as a flurry of emails show services are bouncing. Picture this… You just got your second cup of coffee and you’re walking back to your desk.