Kubernetes

You’ve built your Kubernetes cluster(s). You’ve built your apps in containers. You’ve architected your services so that losing a single instance doesn’t cause an outage. And you’re ready for cloud scale. You deploy your application and are waiting to sit back and “profit.” When your application spins up and starts taking on load, you are able to change the number of replicas to handle the additional load, but what about the promises of cloud and scaling? Wouldn’t it be better to deploy the application and let the platform scale the application automatically? ...

Containerizing applications and running them on Kubernetes doesn’t mean we can forget all about resource utilization. Our thought process may have changed because we can much more easily scale-out our application as demand increases, but many times we need to consider how our containers might fight with each other for resources. Resource Requests and Limits can be used to help stop the “noisy neighbor” problem in a Kubernetes Cluster. Resource Requests and Limits - The Theory Kubernetes uses the concept of a “Resource Request” and a “Resource Limit” when defining how many resources a container within a pod should receive. Lets look at each of these topics on their own, starting with resource requests. ...

VMware offers a Kubernetes Cloud Provider that allows Kubernetes (k8s) administrators to manage parts of the vSphere infrastructure by interacting with the Kubernetes Control Plane. Why is this needed? Well, being able to spin up some new virtual disks and attaching them to your k8s cluster is especially useful when your pods need access to persistent storage for example. The Cloud providers (AWS, vSphere, Azure, GCE) obviously differ between vendors. Each cloud provider has different functionality that might be exposed in some way to the Kubernetes control plane. For example, Amazon Web Services provides a load balancer that can be configured with k8s on demand if you are using the AWS provider, but vSphere does not (unless you’re using NSX). ...

VMware recently released the 1.0 release of Tanzu Kubernetes Grid (TKG) which aims at decreasing the difficulty of deploying conformant Kubernetes clusters across infrastructure. This post demonstrates how to use TKG to deploy a management cluster to vSphere. If you’re not familiar with TKG yet, you might be curious about what a Management Cluster is. The management cluster is used to manage one to many workload clusters. The management cluster is used to spin up VMs on different cloud providers, and lay down the Kubernetes bits on those VMs, thus creating new clusters for applications to be build on top of. TKG is built upon the ClusterAPI project so this post pretty accurately describes the architecture that TKG uses. ...

Controlling access to a Kubernetes cluster is an ongoing activity that must be done in conjunction with developer needs and is often maintained by operations or security teams. Tanzu Mission Control (TMC) can help use setup and manage these access policies across fleets of Kubernetes clusters, making everyone’s life a little bit easier. Setup Users Before we can assign permissions to a user or group, we need to have a user or group to assign these permissions. By logging into the VMware Cloud Services portal (cloud.VMware.com) and going to the Identity and Access Management Tab we can create and invite new users. You can see I’ve created a user. ...

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. ...