A relatively simple, unified method for reporting on Kubernetes resource issues.
Go
12
6 commits
updated Mar 5, 2020
(KAY-ter-ade)
The point of k8eraid is to provide a relatively simple, unified method for reporting on Kubernetes resource issues.
How is this different from metrics based alerters (ie: Prometheus with AlertManager)?
This tool directly integrates with the Kubernetes API to look up the actual real state of resources and their changes. That means where metrics based systems are good for looking up a snapshot of status based on specifications (X number of pods running right now), k8eraid can look up the current status as well as see if the status has recently changed by looking at the timestamps for API metadata like deletion times and pod state readiness times. Additionally, the configuration for k8eraid is simple enough that it is easy to expand or remove alerting and monitoring as you see fit. Not only that but k8eraid is incredibly lightweight, using about 100KB of memory at runtime to look up the status of 100 individual resources, making it a prime, lightweight candidate for allowing multiple teams in a shared environment to deploy per-namespace and allowing them to manage alerting as they see fit!
| Kubernetes version | Works |
|---|---|
| 1.6.X | :white_check_mark: |
| 1.7.X | :white_check_mark: |
| 1.9.X | :white_check_mark: |
| 1.10.X | :white_check_mark: |
| Resource | Statuses |
|---|---|
| Pods | Minimum pod count, pod restarts, Failed scheduling, Stuck terminating |
| Deployments | Minimum replica count |
| Daemonsets | Minimum replica count, Failed scheduling |
| Nodes | Out of disk, Memory pressure, Disk pressure, Node readiness, Node count |
K8eraid can not only perform these checks against single resources, but you can specify "global" rules using "*". Additionally, global rules can use filters based on resource labels!
| Alert type | Options |
|---|---|
| stderr | |
| smtp | Mail server, Port, Password ENV var, Subject, From address, To address |
| pagerdutyV2 | Service key ENV var, Proxy server, Subject |
| webhook | Server, Proxy server, Subject |
# get from DockerHub
docker pull bloomberg/k8eraid
There are five types of objects in a config- "deployments", "pods", "daemonsets", "nodes", and "alerters". Each of these objects contain one or more desired definitions. There are a few important rules that you will need to remember when configuring your rules, most of these are due to the way the kubernetes client functions in list vs get functions.
{
"name": "foobarbaz-pod",
"filterNamespace": "default",
"filterLabel": "",
"alerter": "stderr",
"reportStatus": {
"minPods": 1,
"podRestarts": true,
"failedScheduling": true,
"pendingThreshold": 120
}
}
{
"name": "*",
"filterNamespace": "",
"filterLabel": "monitor=true",
"alerter": "example-email",
"reportStatus": {
"minPods": 1,
"podRestarts": false,
"failedScheduling": true,
"stuckTerminating": true,
"pendingThreshold": 10
}
}
{
"name": "foobar-deployment",
"filter": "default",
"alerter": "example-pagerduty",
"reportStatus": {
"minReplicas": 3,
"pendingThreshold": 10
}
}
{
"name": "*",
"filter": "",
"alerter": "stderr",
"reportStatus": {
"minReplicas": 1,
"pendingThreshold": 30
}
}
{
"name": "daemon-of-glory",
"filter": "",
"alerter": "stderr",
"reportStatus": {
"checkReplicas": true,
"failedScheduling": true,
"pendingThreshold": 10
}
}
{
"name": "*",
"filter": "monitor=true",
"alerter": "stderr",
"reportStatus": {
"minNodes": 10,
"outOfDisk": true,
"memoryPressure": true,
"diskPressure": true,
"readiness": true,
"pendingThreshold": 300
}
}
stdout is a default constant alerter name that will always spew errors to stdout where the application is running. No special configuration is needed.
All other alert types may be configured multiple different ways each with unique names- allowing you to change alert behavior based on your rules as desired.
Example smtp alert named "example-email", this will email me@example.com when called upon
{
"name": "example-email",
"toAddress": "me@example.com",
"fromAddress": "kubernetes@example.com",
"mailServer": "smtp.example.com",
"port": 25,
"subject": "Observed issue with Kubernetes cluster"
}
{
"name": "gmail-email",
"toAddress": "me@example.com",
"fromAddress": "foo@gmail.com",
"mailServer": "smtp.gmail.com",
"port": 587,
"passwordEnvVar": "GMAIL_PW",
"subject": "Observed issue with Kubernetes cluster"
}
{
"name": "example-pagerduty",
"serviceKeyEnvVar": "PD_KEY",
"proxyServer": "http://proxy.example.com:80",
"subject": "Observed issue with Kubernetes cluster"
}
Got features or bugfixes? please feel free to contribute with code or issues!
vim-gogo-mode.elvscode-gomake build
make buildcontainer
make testcontainer
make container
Go
96.7%
Makefile
2.8%
A relatively simple, unified method for reporting on Kubernetes resource issues.
Go
12
6 commits
updated Mar 5, 2020
(KAY-ter-ade)
The point of k8eraid is to provide a relatively simple, unified method for reporting on Kubernetes resource issues.
How is this different from metrics based alerters (ie: Prometheus with AlertManager)?
This tool directly integrates with the Kubernetes API to look up the actual real state of resources and their changes. That means where metrics based systems are good for looking up a snapshot of status based on specifications (X number of pods running right now), k8eraid can look up the current status as well as see if the status has recently changed by looking at the timestamps for API metadata like deletion times and pod state readiness times. Additionally, the configuration for k8eraid is simple enough that it is easy to expand or remove alerting and monitoring as you see fit. Not only that but k8eraid is incredibly lightweight, using about 100KB of memory at runtime to look up the status of 100 individual resources, making it a prime, lightweight candidate for allowing multiple teams in a shared environment to deploy per-namespace and allowing them to manage alerting as they see fit!
| Kubernetes version | Works |
|---|---|
| 1.6.X | :white_check_mark: |
| 1.7.X | :white_check_mark: |
| 1.9.X | :white_check_mark: |
| 1.10.X | :white_check_mark: |
| Resource | Statuses |
|---|---|
| Pods | Minimum pod count, pod restarts, Failed scheduling, Stuck terminating |
| Deployments | Minimum replica count |
| Daemonsets | Minimum replica count, Failed scheduling |
| Nodes | Out of disk, Memory pressure, Disk pressure, Node readiness, Node count |
K8eraid can not only perform these checks against single resources, but you can specify "global" rules using "*". Additionally, global rules can use filters based on resource labels!
| Alert type | Options |
|---|---|
| stderr | |
| smtp | Mail server, Port, Password ENV var, Subject, From address, To address |
| pagerdutyV2 | Service key ENV var, Proxy server, Subject |
| webhook | Server, Proxy server, Subject |
# get from DockerHub
docker pull bloomberg/k8eraid
There are five types of objects in a config- "deployments", "pods", "daemonsets", "nodes", and "alerters". Each of these objects contain one or more desired definitions. There are a few important rules that you will need to remember when configuring your rules, most of these are due to the way the kubernetes client functions in list vs get functions.
{
"name": "foobarbaz-pod",
"filterNamespace": "default",
"filterLabel": "",
"alerter": "stderr",
"reportStatus": {
"minPods": 1,
"podRestarts": true,
"failedScheduling": true,
"pendingThreshold": 120
}
}
{
"name": "*",
"filterNamespace": "",
"filterLabel": "monitor=true",
"alerter": "example-email",
"reportStatus": {
"minPods": 1,
"podRestarts": false,
"failedScheduling": true,
"stuckTerminating": true,
"pendingThreshold": 10
}
}
{
"name": "foobar-deployment",
"filter": "default",
"alerter": "example-pagerduty",
"reportStatus": {
"minReplicas": 3,
"pendingThreshold": 10
}
}
{
"name": "*",
"filter": "",
"alerter": "stderr",
"reportStatus": {
"minReplicas": 1,
"pendingThreshold": 30
}
}
{
"name": "daemon-of-glory",
"filter": "",
"alerter": "stderr",
"reportStatus": {
"checkReplicas": true,
"failedScheduling": true,
"pendingThreshold": 10
}
}
{
"name": "*",
"filter": "monitor=true",
"alerter": "stderr",
"reportStatus": {
"minNodes": 10,
"outOfDisk": true,
"memoryPressure": true,
"diskPressure": true,
"readiness": true,
"pendingThreshold": 300
}
}
stdout is a default constant alerter name that will always spew errors to stdout where the application is running. No special configuration is needed.
All other alert types may be configured multiple different ways each with unique names- allowing you to change alert behavior based on your rules as desired.
Example smtp alert named "example-email", this will email me@example.com when called upon
{
"name": "example-email",
"toAddress": "me@example.com",
"fromAddress": "kubernetes@example.com",
"mailServer": "smtp.example.com",
"port": 25,
"subject": "Observed issue with Kubernetes cluster"
}
{
"name": "gmail-email",
"toAddress": "me@example.com",
"fromAddress": "foo@gmail.com",
"mailServer": "smtp.gmail.com",
"port": 587,
"passwordEnvVar": "GMAIL_PW",
"subject": "Observed issue with Kubernetes cluster"
}
{
"name": "example-pagerduty",
"serviceKeyEnvVar": "PD_KEY",
"proxyServer": "http://proxy.example.com:80",
"subject": "Observed issue with Kubernetes cluster"
}
Got features or bugfixes? please feel free to contribute with code or issues!
vim-gogo-mode.elvscode-gomake build
make buildcontainer
make testcontainer
make container
Go
96.7%
Makefile
2.8%