Cloud Health for Kubernetes Clusters and VMs

Tying an Azure Subscription (or AWS account) to Cloud health portal

You have two options (for Azure). Either use an EA (get an Enrollment ID from your EA) and use this on the CH portal to enroll your subscription.

OR

Create a Service Principal in AAD. A Service Principal is a special AAD only identity and can be used to grant access to Azure resources. In this case, we need to  provide Global Reader rights to an entire Azure Subscription (which is granted via the Service Principal).  This principal is associated with an enterprise AAD app for Cloudhealth.

Do you need to install VM agents?

From the CH Metrics Screen , you should see CPU, Memory and Disk related metrics.

These can come from the Azure API as well as from the agents.

• CPU – Can come straight from the API – without needing any CH agent
• Memory: Retrieved from Azure via API call (provided the VM is running the Azure Diagnostics plugin). If no Azure diagnostics or AWS Cloudwatch agent, the CloudHealth Agent is required
• Disk Usage: Retrieved from Azure Guest Metrics or through CloudHealth Agent

Which should you use?

For now, CH metrics work well with just the API enablement (no agents needed). For K8 clusters though, usage data requires the agents to be installed. API will just provide allocation data.

Using Perspectives to Group Assets

Lets you filter your VMs by tags or by name

Step 1 – Create New Perspective – Pick the tag values

Step 2 – Add Group

Can I filter (add perspective) by anything other than RGs?

Yes. VM Scale Sets, AD based groupings and several other Azure groupings can be used for creating perspectives.

RAM or Disk Usage data may not show up – only CPU shows up.

Why am I not seeing RI data under Assets?

RI Recommendations on the VMs may not always show up.

Where do I see the Netapp Usage?

It should show up as an account (under Assets)

VMs and Cloud Health

Agent installation for VMs

Kubernetes and Cloud Health

Basic Terminology in Kubernetes

Cluster = Set of nodes (VMs)

Pods represent individual processes on your container – pods share the same network and disk. Same pod = same

Namespaces  – Organizational Breakup. Different cost centers

Step 1 – Collector (agent) install
The collector can be installed as a Deployment or as a Pod (if Pod dies, doesn’t come back up)

Step 2 – Pick clusters to monitor from the CH menu

Pick the clusters from the CH menu. Should show Status Healthy. Meaning the cluster is reporting back to Cloud health. correctly.

Step 3 – Create CH Perspectives (group the container resources)

Cloud Health ‘Perspectives’ are a way to group cost allocation.

• Group by cost center (namespace)
• Group by nodes
• Group by pods

Install the CH agent in a Kubernetes cluster

Instructions

Collector Pod Agents

Instructions

Using Kops (this post is for AWS – can be easily translated to KOPs on Azure or GCP)

Using Kops

Deploying KOPS itself:

https://github.com/kubernetes/kops/

Configuration

The configuration of the cluster and its associated resources:

1. EC2 2 node cluster
2. route53 configured with MYDOMAIN domain which is used by kops to setup kubernetes API access
3.  Configure the application for nodePort instead of loadBalancing. (This will avoid use of load balancers)
4. The VPC is automatically configured by KOPs on cluster creation.

Once the application is up, you simply install the cloudhealth container collector on the Kubernetes kops cluster.

(following commands and kubernetes-collector-pod-template.yaml file are from cloudhealth)

    export CHT_API_TOKEN=78347783759db01a596f42er33453345

    export CHT_CLUSTER_NAME=kops-masteraccount

    kubectl create secret generic --namespace default --from-literal=api-token=$CHT_API_TOKEN --from-literal=cluster-name=$CHT_CLUSTER_NAME cloudhealth-config

    kubectl create -f kubernetes-collector-pod-template.yaml

Once the collector is configured, it will show up in Cloudhealth: (kop-masteraccount collector shows healthy)