Note: translation.: The original text was written by Rob Scott — a leading SRE engineer at ReactiveOps, the company behind the announced project. We closely align with the idea of centralized validation for what gets deployed in Kubernetes, so we are keenly following such initiatives.
Glad to introduce — an open-source project that helps maintain the "health" of Kubernetes clusters. We created Polaris to automate some of the best practices used at ReactiveOps to ensure the safe and reliable operation of clusters for a large number of clients. It’s time to open-source it.
Time and again, we witnessed how seemingly minor oversights in configuration led to significant problems that kept engineers up at night. Something as simple as a forgotten configuration for resource requests (resource requests) — could break auto-scaling and even result in workloads being starved of resources. While minor configuration errors used to lead to production outages, Polaris now allows us to fully prevent them.
Polaris helps avoid configuration issues that affect the stability, reliability, scalability, and security of your applications. It makes it easy to identify deficiencies in deployment configurations and prevent future problems. With Polaris, you can sleep easy knowing that applications are deployed using a set of well-validated standards.
Polaris consists of two key components:
- a monitoring dashboard that provides information on how correctly configured the existing deployments in the cluster are;
- an experimental validation webhook that prevents deployments that do not meet the accepted standard from being rolled out.
Polaris Dashboard
The dashboard in Polaris was created for a simple and clear way to see the current state of deployments in Kubernetes and receive improvement recommendations. It provides a comprehensive overview of the cluster and breaks down results by categories, namespaces, and deployments.
The standards set in Polaris by default are quite high, so don't be surprised if your rating comes in lower than expected. The primary goal of Polaris is to establish high standards and strive for excellent default configurations. If the proposed configuration feels too rigid, it can be adjusted during the deployment configuration process to optimize for specific workloads.
As part of the Polaris release, we decided not only to present the tool itself but also to describe in detail the tests included in it. Each check includes a link to the relevant documentation, explaining why we consider it important and providing links to additional resources on the topic.
Polaris Webhook
While the dashboard helps provide an overview of the current deployment configuration, the webhook ensures compliance with standards for all deployments that will be pushed to the cluster.
After addressing the issues identified by the dashboard, you can use the webhook to ensure that the configuration never falls below the established standard again. The webhook will prevent deployments with significant deviations (error level) from being launched in the cluster.
The potential of this webhook is inspiring; however, to deem it production-ready, thorough testing is still required. Currently, this is an experimental feature and part of a brand-new Open Source project. As it may hinder deployment updates, use it cautiously.
Getting Started
I hope that since you are still reading this announcement, Polaris is a tool that can prove useful for you. Want to try the Dashboard yourself? Deploying the dashboard in a cluster is very easy. It installs with minimal rights (read-only), and all data remains internal. To deploy the Dashboard using kubectl, execute:
kubectl apply -f https://raw.githubusercontent.com/reactiveops/polaris/master/deploy/dashboard.yamlNow you need to set up port forwarding to access the Dashboard through local port 8080:
kubectl port-forward --namespace polaris svc/polaris-dashboard 8080:80Of course, there are many other ways to use and deploy Polaris, including using Helm. You can find out about this and much more from .
This is just the beginning
We are pleased with what we've already integrated into Polaris, but this story is far from over. Many new tests are on the horizon that we would like to add to enhance functionality. We are also looking for the best way to implement exception-checking rules at the namespace or resource level. If you want to know more about our plans, check out the .
If you think Polaris could be useful, please take the time to try it out. We welcome any ideas, feedback, questions, or pull requests. You can reach us at , in or in .
P.S. from the translator
Also read in our blog:
- «»;
- «»;
- «»;
- «».
Source: habr.com
