kubewatch

kubewatch copied to clipboard

This PR

• Adds "Event" config section in the .kubewatch.yaml file for granular alerting
• Makes Event config optional
• Makes Resource config optional for backward compatibility
• Enables configuration of alerts either using the "Resource" config or "Event" Config
• Renames "Services" option to "Service" option in .kubewatch.yaml file
• Populates Namespace details from events key, if the Namespace filed is empty

Upon Merging

• Enables the user to customize alerts based on the Event configuration provided. eg: pod - alerts on creation and deletion events can be configured. svc - alerts on deletion can be configured individually.

Example Configs:

Using Resource Config:

$ cat ~/.kubewatch.yaml
handler:
  slack:
    token: xoxb-xxxxxxxxx-yyyyyyyyyy
    channel: kube-watch-test
resource:
  deployment: false
  replicationcontroller: false
  replicaset: false
  daemonset: false
  service: true
  pod: true
  job: false
  persistentvolume: false
  namespace: false
  secret: false
  configmap: false
  ingress: false
namespace: ""

Using Resource Config Sends all events to the specified channel. Note: This section is kept unchanged for backward compatibility.

Using Event Config:

$ cat ~/.kubewatch.yaml 
handler:
  slack:
    token: xoxb-xxxxx-yyyyyyy
    channel: kube-watch-test

event:
    global:                       // global section alerts for all events
     - pod
     - deployment
    create:                       // create section alerts for resource object creation
     - service
    update:                       // update section for resource object updation
     - 
    delete:                       // delete section alerts for resource object deletion
     - job
     - service

namespace: ""

Using Event Config

• all events for pod and deployment
• create and delete events for service
• delete events for job

will be sent to the specified channel.

This PR addresses Issue #105 and #163.

I would like to discuss on this PR and get it merged with peer reviews and feedbacks.

@tylerauerbeck, @jbianquetti-nami, @jjo
do help with your views, comments, and feedbacks.

We could discuss on this feature (when people are free) for improvements like,

• labels and selectors for monitoring parricular resources
• annotation based alerting
• ~~default alerts on critical events like node reboot ,node not ready~~ (proposed through #179 )

Altering the current config suitably, would support customisation.

def want this + label selectors to further target specific things to monitor

Remider Ping Could this be reviewed and merged..?

• annotation based alerting
• alerts on critical events like node reboot ,node not ready

Altering the current config suitably, would support customisation.

FYI, These features are now avalilable with Botkube (0.9.0) People in need can make use of it. :+1:

Botkube lack other features (like Teams integration), i hope that this PR will be merged since i think that it will be useful for a lot of users: now even on small k8s deployment, a small activity like a deployment or a scaleup, create a lot of notifications (6 or more) ... this makes the notifications unreadable and mute-prone

rebased into master

conflicts

resolved conflicts and rebased into the master

@mkmik rebased into master

Any news on this?