Nick Huanca
75f70352ba
**Changes** - Refactored the way controllers work to be an interface - Added configurable controllers to include in scans - Added daemonsets, jobs and cronjobs in scans - Added `ReplicationController` type controllers to the supported list - Adjusted logic for failed YAML parsing to bubble up errors - Added better logic for calculating summaries on cluster wide results - Relocated responsibilities for counting types into validators vs spreading it around more packages - Fixed bug where cronjob parsing was using wrong KIND - Added fixtures for mocking new controller types - Added example yamls to test scanning files - Added functions to NamespacedResult(s) to reduce code complexity deep set iterations - Refactored how results get added to namespacedresults so adding more later is easier - Minor signature changes for interface implementing structs for controllers
1.7 KiB
Health Checks
Polaris supports validating the presence of readiness and liveness probes in pods.
| key | default | description |
|---|---|---|
healthChecks.readinessProbeMissing |
warning |
Fails when a readiness probe is not configured for a pod. |
healthChecks.livenessProbeMissing |
warning |
Fails when a liveness probe is not configured for a pod. |
Background
Readiness and liveness probes can help maintain the health of applications running inside Kubernetes. By default, Kubernetes only knows whether or not a process is running, not if it's healthy. Properly configured readiness and liveness probes will also be able to ensure the health of an application.
Readiness probes are designed to ensure that an application has reached a "ready" state. In many cases there is a period of time between when a webserver process starts and when it is ready to receive traffic. A readiness probe can ensure the traffic is not sent to a pod until it is actually ready to receive traffic.
Liveness probes are designed to ensure that an application stays in a healthy state. When a liveness probe fails, the pod will be restarted.