Posts

What do you do if you’ve already provisioned some Kubernetes clusters before you got Tanzu Mission Control? Or maybe you’re inheriting some new clusters through an acquisition? Or a new team came on board and were using their own installation? Whatever the case, Tanzu Mission Control will let you manage a conformant Kubernetes cluster but you must first attach it. Attach An Existing Cluster For this example, I’ll be attaching a pre-existing Kubernetes cluster on vSphere infrastructure. This cluster was deployed via kubeadm as documented in this previous article about deploying Kubernetes on vSphere. ...

Kubernetes releases a new minor version every quarter and updating your existing clusters can be a chore. With updates coming at you pretty quickly and new functionality being added all the time, having a way to upgrade your clusters is a must, especially if you are managing multiples of clusters. Tanzu Mission Control can take the pain out of upgrading these clusters. It should be mentioned that the cluster upgrade procedure only works for clusters that were previously deployed through Tanzu Mission Control. If an existing cluster is attached to TMC after deployment, these cluster lifecycle steps won’t work. ...

No matter what flavor of Kubernetes you’re using, the cluster should have some high level of common functionality with the upstream version. To ensure this is the case Kubernetes conformance tests can validate your clusters. These tests are run by Sonobuoy which is an open source community standard. Tanzu Mission Control can run these tests on your clusters to ensure this conformance. They are a great way to make sure your cluster was installed, configured and operating properly. ...

I’ve written about deploying clusters in the past, but if you are a TMC customer, those steps can be skipped altogether. TMC will let us deploy a Kubernetes cluster and add it to management, all from the GUI or CLI. For this example, I’ll create a new Kubernetes cluster within my AWS account. Before we setup the cluster, we need to configure access to our AWS Account so that TMC can manage resources for us. ...

When we need to segment resources within a Kubernetes cluster, we often use a namespace. Namespaces can be excellent resources to create a boundary for either networking, role based access, or simply for organizational purposes. It may be common to have some standard namespaces across all of your clusters. Maybe you have corporate monitoring standards and the tools live in a specific namespace, or you always have an ingress namespace thats off limits to developers or something. Managing namespaces across cluster could be tedious, but Tanzu Mission Control lets us manage these namespaces centrally from the TMC console. ...

A pretty common task that a Kubernetes administrator must do is to resize the cluster. We need more nodes to handle more workloads, or we’ve overprovisioned a cluster and are trying to save costs. This usually took some custom automation scripts such as node autoscaler, or it was done manually based on request. Tanzu Mission Control can resize our cluster very simply from the TMC portal. Scale Out a Cluster Within the TMC Portal, find the cluster that needs to be resized. Within the cluster screen, find the “Node pools” menu. Node pools define the worker nodes that are part of the Kubernetes cluster thats been deployed. ...

Most of the blog posts I write about Kubernetes have examples using publicly available images from public image registries like DockerHub or Google Container Registry. But in the real world, companies use private registries for storing their container images. There are a list of reasons why you might want to do this including: Custom code is inside the container such as business logic or other intellectual property. On-premises private repos provide solutions to bandwidth or firewall restrictions. Custom scanning software is being integrated for vulnerability management. In this post, we’ll setup our Kubernetes cluster to be able to use a private container registry. ...

Recently I was tasked with setting up some virtual machines to be used as a load balancer for a Kubernetes cluster. The environment we were deploying our Kubernetes cluster didn’t have a load balancer available, so we thought we’d just throw some envoy proxies on some VMs to do the job. This post will show you how the following tasks were completed: Deploy Envoy on a pair of CentOS7 virtual machines. Configure Envoy with health checks for the Kubernetes Control Plane Install keepalived on both servers to manage failover. Configure keepalived to failover if a server goes offline, or the envoy service is not started. Deploy Envoy The first step will be to setup a pair of CentOS 7 servers. I’ve used virtual servers for this post, but baremetal would work the same. Also, similar steps could be used if you prefer debian as your linux flavor. ...

Its 2020 and I’ve had plenty of time at home due to the social distancing and global pandemic going on. I’ve also been putting off purchasing any new home gear, thinking to myself that maybe the cloud only model will be my next lab, but it isn’t yet. Due to the work I’ve been doing with vSphere 7 and Kubernetes clusters, I couldn’t avoid updating my hardware any longer. Here’s the updated home lab for any enthusiasts. ...

Sometimes things don’t go quite as we’ve planned. When that happens in a computer system, we turn to the logs to tell us what went wrong, and to give us some clues on either how to fix the issue, or where to look for the next clue.This post focuses on where to look for issues in your Kubernetes deployment. Before we dive into the logs, we must acknowledge that there are different ways to install a kubernetes cluster. The pieces and parts can be deployed as system services or containers, and the way to obtain their logs will change. This post uses a previous post about a k8s install as an example of where to find those logs. ...