Presented by Polaris to keep Kubernetes clusters healthy
Note trans. : The original of this text was written by Rob Scott, the lead SRE engineer of 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 similar initiatives with interest.
I am pleased to introduce 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 in ReactiveOps to support the safe and reliable operation of clusters with a large number of clients. It's time to open the source code.
')
Time after time we witnessed how seemingly minor flaws in the configuration led to serious problems that prevented engineers from sleeping at night. Something quite simple — for example, the missed on forgetfulness configuration of resource requests — could break autoscaling and even cause workloads to remain without resources. If earlier minor oversights in the configuration led to interruptions in the production, now Polaris allows to prevent them completely.
Polaris helps to avoid configuration problems that affect the stability, reliability, scalability and security of your applications. It makes it easy to identify flaws in the configurations of a deployment and prevent future problems. With Polaris, you can sleep soundly, knowing that applications are deployed using a set of well-tested standards.
Polaris consists of two key components:
The panel in Polaris was created for a simple and clear opportunity to see the current status of deployment Kubernetes and get recommendations for improvements. It provides a complete overview of the cluster, and also splits the results into categories, namespaces and deployments.
The standards set by default in 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 an excellent default configuration. If the proposed configuration seems too tight, it can be corrected during the configuration of the deployment, 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 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 to get an overview of the current configurations of deployments, then a web hook ensures standards are met for all deployments that will only roll out to the cluster.
After the problems identified by the dashboard are fixed, you can use a web-hook so that the configuration will never fall below the established standard. The web hook will not allow deployment deployments in a cluster, the configuration of which contains significant deviations (“error” levels).
The potential of this web-hook is encouraging, but in order to recognize it as ready for production, careful testing is still required. At the moment, this is an experimental opportunity and part of a completely new Open Source project. Since it may interfere with the update of your deployment, use it with caution.
I hope that since you are still reading this announcement, Polaris is a tool that may be useful to you. Want to try Dashboard yourself? Expand the panel in a cluster is very easy. It is installed with minimal rights (read only), and all data remains inside. To deploy the dashboard using kubectl, run:
Now you need to configure port forwarding to enter the Dashboard via 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 build in Polaris, but the story does not end there. On the way there are many new tests that I would like to add in order to expand the functionality. We are also looking for the best way to implement exclusion 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 can be useful - please take the time to try it. We will gladly 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 am pleased to introduce 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 in ReactiveOps to support the safe and reliable operation of clusters with a large number of clients. It's time to open the source code.
')
Time after time we witnessed how seemingly minor flaws in the configuration led to serious problems that prevented engineers from sleeping at night. Something quite simple — for example, the missed on forgetfulness configuration of resource requests — could break autoscaling and even cause workloads to remain without resources. If earlier minor oversights in the configuration led to interruptions in the production, now Polaris allows to prevent them completely.
Polaris helps to avoid configuration problems that affect the stability, reliability, scalability and security of your applications. It makes it easy to identify flaws in the configurations of a deployment and prevent future problems. With Polaris, you can sleep soundly, knowing that applications are deployed using a set of well-tested standards.
Polaris consists of two key components:
- dashboards that provide information on how properly configured deployments are in the cluster;
- an experimental test webhook that prevents deployments from rolling out, which does not meet the accepted standard.
Polaris dashboard
The panel in Polaris was created for a simple and clear opportunity to see the current status of deployment Kubernetes and get recommendations for improvements. It provides a complete overview of the cluster, and also splits the results into categories, namespaces and deployments.
The standards set by default in 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 an excellent default configuration. If the proposed configuration seems too tight, it can be corrected during the configuration of the deployment, 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 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 to get an overview of the current configurations of deployments, then a web hook ensures standards are met for all deployments that will only roll out to the cluster.
After the problems identified by the dashboard are fixed, you can use a web-hook so that the configuration will never fall below the established standard. The web hook will not allow deployment deployments in a cluster, the configuration of which contains significant deviations (“error” levels).
The potential of this web-hook is encouraging, but in order to recognize it as ready for production, careful testing is still required. At the moment, this is an experimental opportunity and part of a completely new Open Source project. Since it may interfere with the update of your deployment, use it with caution.
Beginning of work
I hope that since you are still reading this announcement, Polaris is a tool that may be useful to you. Want to try Dashboard yourself? Expand the panel in a cluster is very easy. It is installed with minimal rights (read only), and all data remains inside. To deploy the dashboard using kubectl, run:
kubectl apply -f https://raw.githubusercontent.com/reactiveops/polaris/master/deploy/dashboard.yaml Now you need to configure port forwarding to enter the Dashboard via the local port 8080:
kubectl port-forward --namespace polaris svc/polaris-dashboard 8080:80 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 .
This is just the beginning.
We are pleased that we have already managed to build in Polaris, but the story does not end there. On the way there are many new tests that I would like to add in order to expand the functionality. We are also looking for the best way to implement exclusion 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 can be useful - please take the time to try it. We will gladly accept any ideas, feedback, questions or pull requests. You can contact us on the project website , on GitHub or on Twitter .
PS from translator
Read also in our blog:
Source: https://habr.com/ru/post/454706/
All Articles