This post was originally published on this site
In this blog post we will cover the following topics
- What is Tanzu Mission Control? - So, this isn't just for VMware environments? - Getting Started Tanzu Mission Control - - TMC Resource Hierarchy - - Creating a Cluster Group - - Attaching a cluster to Tanzu Mission Control - - Viewing your Cluster Objects - - - Overview - - - Nodes - - - Namespaces - - - Workloads - Where can I demo/test/trial this myself?
The follow up blog posts are;
- Tanzu Mission Control - - Cluster Inspections - - - What Inspections are available - - - Performing Inspections - - - Viewing Inspections - - Workspaces and Policies - - - Creating a workspace - - - Creating a managed Namespace - - - Policy Driven Cluster Management - - - Creating Policies
What is Tanzu Mission Control?
Tanzu Mission control is a cloud offering, which gives you a single point of control, monitoring and management, regardless of the Kubernetes deployment and their location (e.g Tanzu Kubernetes Grid, OpenShift Container Platform, Azure Kubernetes to name but a few).
- Manage Kubernetes Cluster Lifecycle through the deployment and day 2 operations
- Attach Clusters for centralized operations and management
- Centralized policy management
- Apply access, network and container registry policies consistently across your Kubernetes clusters and namespaces
- Global visibility for diagnosing and troubleshooting issues with your Kubernetes clusters
- Inspection runbooks to validate the configuration of your clusters
- Current offerings are;
- Conformance; validating binaries running in your cluster to ensure proper configuration and running.
- CIS benchmark; evaluation against the CIS Benchmark for Kubernetes published by the Center for Internet Security.
- Lite; node conformance test to validate your nodes meet the Kubernetes requirements.
- Current offerings are;
So, this isn’t just for VMware environments?
Nope, this is a cloud and Kubernetes neutral offering. You can attach CNCF conformant Kubernetes clusters to Tanzu Mission Control no matter where they are running: on vSphere, in any public clouds, or through other Kubernetes vendors.
Getting Started Tanzu Mission Control
TMC Resource Hierarchy
In the Tanzu Mission Control resource hierarchy, there are three levels at which you can specify policies.
- Object groups (Cluster groups and Workspaces)
- Kubernetes objects (Clusters and Namespaces)
You can set direct policies for a given object, but each object can also inherit based on the parent objects. So pretty much what you’ve been used to in the past with policies and hierarchies.
Creating a Cluster Group
A Cluster Group is a logical object to bring together multiple Kubernetes clusters. You can set user access policies to be able to view/edit/control cluster group objects and their child objects (clusters).
Cluster groups provide an infrastructure view, and all clusters must be attached to a group.
To create a Cluster Group;
- Select the Cluster Group from the navigation
- Click New Cluster Group
- Supply a name, description and labels are optional and can be edited after creation
Once create, you will see it’s clearly empty, but once you start attaching clusters and making them part of your group, they will start to look like the below.
Here you can see I have a Azure Kubernetes Service instance connected, and awaiting the attachment of another cluster.
Attaching a cluster to Tanzu Mission Control
To attach a cluster, you will configure the cluster in TMC first, this will produce a YAML to run against your Kubernetes infrastructure. This YAML will create a Service Agent and other extensions under its own namespace ‘vmware-system-tmc’.
To setup a cluster;
- Either directly on the Clusters page, or viewed within your Cluster Group page, select Attach Cluster
- Selecting New Cluster is part of the automatic provisioning and lifecycle capability which supports running Tanzu Kubernetes Grid in native AWS.
Supply a name for your Cluster, and choose if it’s part of a Cluster Group. Description and Labels are optional.
Note: You are unable to move clusters between cluster groups after they are attached, you must de-attach and go through the process again if you make a mistake.
In this example, I am going to attach my OpenShift Container Platform (OCP) Cluster to TMC, showing the capability to attach any Kubernetes cluster
In the below screenshot you can see I am attaching this to my earlier created cluster group.
The next page gives you the command to a unique YAML file that will setup the services to connect to your cluster. This is valid for 48 hours.
You also can view and download the YAML yourself, for example if you wanted to edit the namespace which it will create and run in.
Note: cluster agent extensions running on the cluster make connections to Tanzu Mission Control URLs for outbound communications. You will need to whitelist these URLs on port 443; *.tmc.cloud.vmware.com - URLs in this domain include the Tanzu Mission Control service for your organization, as well as the authentication and authorization services. vmware-docker-olympus-extensions.bintray.io - This URL is a Bintray location from which Tanzu Mission Control retrieves the cluster agent extensions to deploy on your cluster. cell-whitesand-aws-usw2-core-47acfezm.s3.amazonaws.com This URL is an AWS S3 bucket in which Tanzu Mission Control stores the results of cluster inspections.
Below you can see the output when I apply the command against my OpenShift environment.
Once deployed to your environment, click the Verify Connection button, and wait for a successful message. This was pretty much instantaneous for me.
Clicking View Your Cluster will take you to into the cluster object itself.
Viewing your Cluster Objects
Now we have created a cluster, we can view the information pulled from the Kubernetes cluster. It took a few minutes for all my cluster information to update when first created. I assume the larger and busier your environments, the longer that first pull of data will be.
On the overview page, we can view the overall cluster health and configuration.
- Cluster Health
This is aggregation of health of the components and nodes in the cluster. The status of the cluster can be
HEALTHY - All nodes and components are healthy, heartbeat is received from cluster every one minute. UNHEALTHY - Status if either of the below are true; - one or more of the cluster's masters - one or more of the cluster's components WARNING - Status if any worker nodes state is warning, unhealthy or unknown. UNKNOWN - Status if master nodes or cluster components are in unknown state. DISCONNECTED - Status if no heartbeat is received from the cluster for more than 3 minutes from the cluster.
- Kubernetes Provider and Version
- Count of;
- Control Plane + Worker nodes
- Cluster resources totals and utilization
- Component Health
Tanzu Mission Control monitors the health of the following components running in the cluster:
- one or more etcd components (etcd-0, etcd-1, etcd-2, and so on)
Component status conditions are reported every 45 seconds, the status of components can be;
HEALTHY - Reported value of component is healthy. UNHEALTHY - Last reported value of the component is not healthy. UNKNOWN - Last reported value of the component is not either true/false for healthy, or the value is Unknown. This state will also be set if component heartbeat has not been received for more than three minutes.
- Agent and Extension Health
This is the health status of the TMC components installed on your cluster to allow for monitoring and management of that cluster.
On the Nodes page, you will see all the nodes that make up your cluster. And you can click into each node to see further information, such as the state of individual conditions.
Node Health on the following;
- NodeReady condition (viewed when you run “Kubectl get nodes“)
TMC uses these conditions to determine health, the status of each condition is assumed unchanged until the node reports a change.
Node Health Status in TMC will be listed as one of the following;
HEALTHY - NodeReady = True, and all other conditions are healthy, then the node is healthy. UNHEALTHY - NodeReady = False. The node is also unhealthy if NodeReady is True and more than half of the other conditions are in an unhealthy state. WARNING - NodeReady = True, but some (less than half) of the other conditions are in an unhealthy state. UNKNOWN - NodeReady = any value other than True or False. This status will also show if a no heartbeat from the node has been received for more than three minutes.
The Namespace page within your cluster view will list all namespaces.
Here you will see the state of managed. Currently from an attached cluster, all namespaces will be unmanaged.
When TMC manages your namespaces, they will be connected to a workspace (which will be covering in this follow up blog post), and policies can be assigned that manage the namespace.
You can attach a namespace in this view by selecting the object and clicking the Attach Namespaces button, when you do this you will be prompted to select a workspace.
Clicking a Namespace will, you will see the CPU and Memory usage, as well as the workloads associated (Deployments, DaemonSet, StatefulSet, ReplicaSet).
And by clicking one of those Workload objects, you will see the associated pods, and YAML configuration they are running.
The Cluster Workloads tab will show you all Deployment, DaemonSet, StatefulSet and ReplicaSet on the Cluster. From here you’ll be able to see the associated Namespace and Workspace (if applicable).
The final tab, Inspections, will allow you to run and view any selected cluster inspections. A feature we will cover in this follow up blog post.
Where can I demo/test/trial this myself?
You can get hands on experience of Tanzu Mission Control yourself over on the VMware Hands-on-Lab website, which is always free!
HOL-2032-01-CNA – VMware Tanzu Mission Control
- In this lab you will be exposed to various aspects of VMware’s Tanzu Mission Control including Kubernetes cluster lifecycle management, health checks, environment at a glance monitoring, access policies, and conformance testing.
If you would like to Trial this against your own environment, or simply to speak to an expert, contact your local VMware rep, or fill in this form.
Wrap-up and Resources
In Summary, we setup our first objects in TMC and started to look at the information pulled through for monitoring purposes.
As a reminder, to take real advantage of TMC I recommend you read the follow posts;
- Tanzu Mission Control - - Cluster Inspections - - Workspaces and Policies
And I’ll sign off with links to the official resources.
- Tanzu Mission Control
And a small plug for my colleague Simon Conyard’s Blog – https://virtual-simon.co.uk
The post VMware Tanzu Mission Control – Getting started with your first cluster appeared first on @Saintdle.