Note. transl.: The original of this text was written by Rob Scott, the lead SRE engineer at ReactiveOps, which is behind the development of the announced project. We are very close to the idea of centralized validation of what is deployed in Kubernetes, so we are following such initiatives with interest.
Happy to introduce is an open source project that helps maintain the "health" of a Kubernetes cluster. We built Polaris to automate some of the best practices used by ReactiveOps to keep clusters running safely and reliably for a large number of clients. It's time to open source.
Time after time, we have seen how seemingly minor configuration flaws lead to serious problems that prevent engineers from sleeping at night. Something very simple - for example, the configuration of requests for resources that was overlooked due to forgetfulness (resource requests) - could break autoscaling and even lead to the fact that workloads were left without resources. If before, minor configuration oversights led to interruptions in production, now Polaris allows you to completely prevent them.
Polaris helps you avoid configuration issues that affect the stability, reliability, scalability, and security of your applications. It makes it easy to identify weaknesses in deployment configurations and prevent future problems. With Polaris, you can sleep soundly knowing that applications are deployed using a set of well-tested standards.
Polaris is made up of two key components:
- a dashboard that provides information on how well the existing deployments in the cluster are configured;
- an experimental test webhook that prevents deployments from rolling out that do not meet the accepted standard.
Polaris Dashboard
The Polaris Dashboard was created to provide a simple and visual way to see the current status of Kubernetes deployments and get recommendations for improvements. It provides a complete overview of the cluster and breaks down the results by category, namespace, and deployment.
The default standards set by Polaris are quite high, so don't be surprised if the score is lower than you expected. The main goal of Polaris is to set high standards and strive for a great default configuration. If the proposed configuration seems too rigid, it can be corrected during the deployment configuration process, optimizing for specific workloads.
As part of the Polaris publication, we decided not only to present the tool itself, but also to describe in detail the tests that are included in it. Each review includes a link to the relevant documentation explaining why we think it's important and links to additional resources on the topic.
Polaris Webhook
If the dashboard helps you get an overview of the current configuration of deployments, then the webhook enforces standards for all deployments that will only be rolled out to the cluster.
After the issues identified by the dashboard are fixed, a webhook can be used to ensure that the configuration never falls below the established standard again. The webhook will not allow deploying deployments in the cluster, the configuration of which contains significant deviations (of the “error” level).
The potential of this webhook is encouraging, but it still needs extensive testing to be considered production-ready. It is currently an experimental feature and part of a brand new Open Source project. Because it can interfere with deployment updates, use it with caution.
Beginning of work
I hope that while you are still reading this announcement, Polaris is a tool that you might find useful. Want to try Dashboard yourself? Deploying a panel in a cluster is very easy. It is installed with minimal rights (read only), and all data remains inside. To deploy Dashboard using kubectl, run:
kubectl apply -f https://raw.githubusercontent.com/reactiveops/polaris/master/deploy/dashboard.yamlNow you need to set up port forwarding in order to access the Dashboard through the 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 Helm. You can learn about this and much more from .
This is just the beginning.
We're happy with what we've already built into Polaris, but the story doesn't end there. There are many new tests on the way that I would like to add to expand the functionality. We are also looking for a better way to implement exception checking rules at the namespace or resource level. For more information about our plans, please see .
If you have the impression that Polaris can be useful, please take the time to try it out. We welcome any ideas, feedback, questions or pull requests. You can contact us at In or .
PS from translator
Read also on our blog:
- «";
- «";
- «";
- «».
Source: habr.com