Delve into advanced Kubernetes features like monitoring, alerting, logging, and auto-scaling. Gain insights into creating resilient, self-adaptive clusters and applications with minimal manual intervention.

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.

Advanced Kubernetes Techniques: Monitoring, Logging, Auto-Scaling

## Pulling the code

The [vfarcic/k8s-specs](https://github.com/vfarcic/k8s-specs) repository will continue to serve as our source of Kubernetes definitions. We'll make sure that it is up-to-date by pulling the latest version.

> 🔍 All the commands from this chapter are available in the <a href="https://gist.github.com/c9dc5d5693cee746ee47071c222b110b">05-hpa-custom-metrics.sh</a> Gist.

```shell
cd k8s-specs

git pull
```

## Gists and specifications

Choose the flavor you want and run the commands from its `.sh` file to create the cluster and the required specifications needed in this chapter. The requirements are the same as those we had in the previous chapter. The only exception is **EKS**. We'll continue using the same Gists as before for all other Kubernetes flavors.

> **NOTE:** In the end, you will see a command to `DELETE` the cluster too. Don't execute that command. Use the `DELETE` command only when you need to delete the cluster, preferably at the end of the chapter. 



> <h3>A note to EKS users</h3>
> 🔍 Even though three t2.small nodes we used so far have more than enough memory and CPU, they might not be able to host all the Pods we'll create. EKS (by default) uses AWS networking. A t2.small instance can have a maximum of three network interfaces, with four IPv4 addresses per each. That means that we can have up to twelve IPv4 addresses on each t2.small node. Given that each Pod needs to have its own address, that means that we can have a maximum of twelve Pods per node. In this chapter, we might need more than thirty-six Pods across the cluster. Instead of creating a cluster with more than three nodes, we'll add Cluster Autoscaler (CA) to the mix, and let the cluster expand if needed. We already explored CA in one of the previous chapters and the setup instructions are now added to the Gist <a href="https://gist.github.com/868bf70ac2946458f5485edea1f6fc4c">eks-hpa-custom.sh</a>.


Please use one of the Gists that follow to create a new cluster. If you already have a cluster you'd like to use for the exercises, please use the Gists to validate that it fulfills all the requirements.


# Pulling the code

The [vfarcic/k8s-specs](https://github.com/vfarcic/k8s-specs) repository will continue to serve as our source of Kubernetes definitions. We'll make sure that it is up-to-date by pulling the latest version.

> 🔍 All the commands from this chapter are available in the <a href="https://gist.github.com/c9dc5d5693cee746ee47071c222b110b">05-hpa-custom-metrics.sh</a> Gist.

```shell
cd k8s-specs

git pull
```

# Gists and specifications

Choose the flavor you want and run the commands from its `.sh` file to create the cluster and the required specifications needed in this chapter. The requirements are the same as those we had in the previous chapter. The only exception is **EKS**. We'll continue using the same Gists as before for all other Kubernetes flavors.

> **NOTE:** In the end, you will see a command to `DELETE` the cluster too. Don't execute that command. Use the `DELETE` command only when you need to delete the cluster, preferably at the end of the chapter. 



> # A note to EKS users
> 🔍 Even though three t2.small nodes we used so far have more than enough memory and CPU, they might not be able to host all the Pods we'll create. EKS (by default) uses AWS networking. A t2.small instance can have a maximum of three network interfaces, with four IPv4 addresses per each. That means that we can have up to twelve IPv4 addresses on each t2.small node. Given that each Pod needs to have its own address, that means that we can have a maximum of twelve Pods per node. In this chapter, we might need more than thirty-six Pods across the cluster. Instead of creating a cluster with more than three nodes, we'll add Cluster Autoscaler (CA) to the mix, and let the cluster expand if needed. We already explored CA in one of the previous chapters and the setup instructions are now added to the Gist <a href="https://gist.github.com/868bf70ac2946458f5485edea1f6fc4c">eks-hpa-custom.sh</a>.


Please use one of the Gists that follow to create a new cluster. If you already have a cluster you'd like to use for the exercises, please use the Gists to validate that it fulfills all the requirements.


This lesson focuses on creating a cluster and the necessary requirements and gists for this chapter.

Before Getting Started

Autoscaling Deployments and StatefulSets

Auto-Scaling Nodes Of A Kubernetes Cluster

Collecting and Querying Metrics and Sending Alerts

Debugging Issues Discovered Through Metrics and Alerts

Extending HorizontalPodAutoscaler With Custom Metrics

Visualizing Metrics And Alerts

Collecting And Querying Logs

Conclusion

Creating a Cluster

Pulling the code #

Gists and specifications #