June 4, 2019 at 10:27Introduced by Polaris to Keep Kubernetes Clusters Healthy
- Transfer
Note perev. : The original of this text was written by Rob Scott, a leading 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 being deployed in Kubernetes, so we are following with interest these initiatives.
I’m pleased to present Polaris , an open source project that helps maintain the health of the Kubernetes cluster. We created Polaris to automate some of the best practices used by ReactiveOps to maintain the safe and reliable operation of clusters across a large number of clients. It's time to open source.
Over and over we became witnesses of how seemingly minor flaws in the configuration led to serious problems that prevented engineers from sleeping at night. Something quite simple - for example, the resource requests configuration lost by forgetfulness - could break auto-scaling and even lead to workloads being left without resources. Previously, minor configuration oversights led to production interruptions, but now Polaris can completely prevent them.
Polaris helps you avoid configuration problems 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 has two key components:
The panel in Polaris was created for a simple and clear opportunity to see the current state of deployment'ov in Kubernetes and to receive recommendations for improvements. It provides a complete overview of the cluster, and also breaks down the results into categories, namespaces, and deployment.
The default Polaris standards are pretty high, so don't be surprised if the rating is lower than you expected. The main goal of Polaris is to set high standards and strive for an excellent default configuration. If the proposed configuration seems too rigid, it can be fixed during the deployment configuration process, optimizing for specific workloads.
As part of the Polaris publication, we decided not only to introduce the tool itself, but also to describe in detail the tests that are included in it. Each check includes a link to the relevant documentation, which explains why we consider this important, and provides links to additional resources on this topic.
If the dashboard helps you get an overview of the current deployment configuration, then the web hook ensures compliance with the standards for all deployments that will only roll out into the cluster.
Once the problems identified by the dashboard have been fixed, you can use the web hook so that the configuration never again falls below the established standard. A web hook will not allow deployment in a cluster of deployments whose configuration contains significant deviations (of the “error” level).
The potential of this web hook is encouraging, but rigorous testing is still required to make it ready for production. This is currently an experimental feature and part of a completely new Open Source project. Since it may interfere with deployment updates, use it with caution.
I hope that since 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, do:
Now you need to configure port forwarding to access the Dashboard through the local port 8080:
Of course, there are many other ways to use and deploy Polaris, including using Helm. You can learn more about this and more from the Polaris repository on GitHub .
We are pleased that we have already managed to integrate into Polaris, but the story does not end there. There are many new tests on the way that I would like to add in order to expand the functionality. We are also looking for the best way to implement the exception checking rules at the namespace or resource level. If you want more information about our plans, check out the roadmap .
If you have the impression that Polaris might be useful - please take a moment to try it. We are happy to accept any ideas, feedback, questions or pull requests. You can contact us on the project website , on GitHub or on Twitter .
Read also in our blog:
I’m pleased to present Polaris , an open source project that helps maintain the health of the Kubernetes cluster. We created Polaris to automate some of the best practices used by ReactiveOps to maintain the safe and reliable operation of clusters across a large number of clients. It's time to open source.
Over and over we became witnesses of how seemingly minor flaws in the configuration led to serious problems that prevented engineers from sleeping at night. Something quite simple - for example, the resource requests configuration lost by forgetfulness - could break auto-scaling and even lead to workloads being left without resources. Previously, minor configuration oversights led to production interruptions, but now Polaris can completely prevent them.
Polaris helps you avoid configuration problems 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 has two key components:
- a dashboard that provides information on how correctly the deployments existing in the cluster are configured;
- An experimental test webhook that prevents deployments from rolling out, which do not meet the accepted standard.
Polaris dashboard
The panel in Polaris was created for a simple and clear opportunity to see the current state of deployment'ov in Kubernetes and to receive recommendations for improvements. It provides a complete overview of the cluster, and also breaks down the results into categories, namespaces, and deployment.
The default Polaris standards are pretty high, so don't be surprised if the rating is lower than you expected. The main goal of Polaris is to set high standards and strive for an excellent default configuration. If the proposed configuration seems too rigid, it can be fixed during the deployment configuration process, optimizing for specific workloads.
As part of the Polaris publication, we decided not only to introduce the tool itself, but also to describe in detail the tests that are included in it. Each check includes a link to the relevant documentation, which explains why we consider this important, and provides links to additional resources on this topic.
Polaris webhook
If the dashboard helps you get an overview of the current deployment configuration, then the web hook ensures compliance with the standards for all deployments that will only roll out into the cluster.
Once the problems identified by the dashboard have been fixed, you can use the web hook so that the configuration never again falls below the established standard. A web hook will not allow deployment in a cluster of deployments whose configuration contains significant deviations (of the “error” level).
The potential of this web hook is encouraging, but rigorous testing is still required to make it ready for production. This is currently an experimental feature and part of a completely new Open Source project. Since it may interfere with deployment updates, use it with caution.
Beginning of work
I hope that since 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, do:
kubectl apply -f https://raw.githubusercontent.com/reactiveops/polaris/master/deploy/dashboard.yamlNow you need to configure port forwarding 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 using Helm. You can learn more about this and more from the Polaris repository on GitHub .
This is just the beginning.
We are pleased that we have already managed to integrate into Polaris, but the story does not end there. There are many new tests on the way that I would like to add in order to expand the functionality. We are also looking for the best way to implement the exception checking rules at the namespace or resource level. If you want more information about our plans, check out the roadmap .
If you have the impression that Polaris might be useful - please take a moment to try it. We are happy to accept any ideas, feedback, questions or pull requests. You can contact us on the project website , on GitHub or on Twitter .
PS from the translator
Read also in our blog: