Expand your Kubernetes knowledge with techniques to make your clusters dynamic and resilient.

DevOps for Developers

The world of DevOps has exploded with the help of technologies like Kubernetes and Docker.
In this course, you will learn about more advanced Kubernetes features such as monitoring, alerting, logging, and scaling - crucial concepts for any DevOps professional. You will learn how to monitor clusters, how to send alerts when potential issues arise, and how to query the whole system’s metrics and logs.
By the end of this course, you will have the required knowledge to make your clusters and applications truly dynamic and resilient, so that they require minimal manual involvement and are self-adaptive.

Kubernetes Monitoring, Logging and Auto-Scaling

# Installation of `Cluster Autoscaler`

We might need to install `Cluster Autoscaler` before we start using it. I said that we *might*, instead of saying that we *have to* because some Kubernetes flavors do come with `Cluster Autoscaler` baked in, while others don't. We'll go through each of the "big three" managed Kubernetes clusters. You might choose to explore all three of them, or to jump to the one you prefer. As a learning experience, I believe that it is beneficial to experience running Kubernetes in all three providers. Nevertheless, that might not be your view and you might prefer using only one. The choice is yours.

## Setting up `Cluster Autoscaler` in GKE

This will be the shortest section ever written. There's nothing to do in GKE if you specified the `--enable-autoscaling` argument when creating the cluster. It already comes with `Cluster Autoscaler` pre-configured and ready.

## Setting up `Cluster Autoscaler` in EKS

Unlike GKE, EKS does not come with `Cluster Autoscaler`. We'll have to configure it ourselves. We'll need to add a few tags to the Autoscaling Group dedicated to worker nodes, to put additional permissions to the Role we're using, and to install `Cluster Autoscaler`.

Let's get going.


```shell
export NAME=devops25
```

We stored the name of the cluster in the environment variable `NAME`.

### Adding permissions
We'll add a few additional permissions to the role created through eksctl. We do not know the name of the role, but we do know the pattern used to create it. Therefore, we'll retrieve the name of the role, before we add a new policy to it.

```shell
IAM_ROLE=$(aws iam list-roles \
 | jq -r ".Roles[] \
 | select(.RoleName \
 | startswith(\"eksctl-$NAME-nodegroup\")) \
 .RoleName")

echo $IAM_ROLE
```

The output of the latter command should be similar to the one that follows.

```
eksctl-devops25-nodegroup-0-NodeInstanceRole-UU6CKXYESUES
```

We listed all the roles, and we used `jq` to filter the output so that only the one with the name that starts with `eksctl-＄NAME-nodegroup-ng-143b-NodeInstanceRole` is returned. Once we filtered the roles, we retrieved the `RoleName` and stored it in the environment variable `IAM_ROLE`.


### Adding `JSON`

Next, we need `JSON` that describes the new policy. I already prepared one, so let's take a quick look at it.

```shell
cat scaling/eks-autoscaling-policy.json
```

The output is as follows.

```json
{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "autoscaling:DescribeAutoScalingGroups",
 "autoscaling:DescribeAutoScalingInstances",
 "autoscaling:DescribeLaunchConfigurations",
 "autoscaling:DescribeTags",
 "autoscaling:SetDesiredCapacity",
 "autoscaling:TerminateInstanceInAutoScalingGroup"
 ],
 "Resource": "*"
 }
 ]
}
```

If you're familiar with AWS (I hope you are), that policy should be straightforward. It allows a few additional actions related to `autoscaling`.

Finally, we can `put` the new policy to the role.

```shell
aws iam put-role-policy \
 --role-name $IAM_ROLE \
 --policy-name $NAME-AutoScaling \
 --policy-document file://scaling/eks-autoscaling-policy.json
```

Now that we added the required tags to the Autoscaling Group and that we created the additional permissions that will allow Kubernetes to interact with the group, we can install Cluster Autoscaler Helm Chart.

```shell
helm install aws-cluster-autoscaler \
 stable/cluster-autoscaler \
 --namespace kube-system \
 --set autoDiscovery.clusterName=$NAME \
 --set awsRegion=$AWS_DEFAULT_REGION \
 --set sslCertPath=/etc/kubernetes/pki/ca.crt \
 --set rbac.create=true

kubectl -n kube-system \
 rollout status \
 deployment aws-cluster-autoscaler
```

Once the Deployment is rolled out, the autoscaler should be fully operational.


## Setting up `Cluster Autoscaler` in AKS

At the time of this writing, `Cluster Autoscaler` does not work in AKS. At least, not always. It is still in the beta stage, and I cannot recommend it just yet. Hopefully, it will be fully operational and stable soon. When that happens, I will update this chapter with AKS-specific instructions. If you feel adventurous or you are committed to Azure, please follow the instructions from the [Cluster Autoscaler on Azure Kubernetes Service (AKS) - Preview](https://docs.microsoft.com/en-us/azure/aks/autoscaler) article. If it works, you should be able to follow the rest of this chapter.

This lesson will focus on how to set up Cluster Autoscaler in GKE, EKS and AKS.

Set up Cluster Autoscaler

Installation of Cluster Autoscaler

Installation of `Cluster Autoscaler`