BotKube v0.11.0 release brings a lot of improvements, bug fixes, and new features based on requests from the community.
BotKube is a lightweight bot for monitoring, alerting, and debugging your Kubernetes applications. You can easily integrate BotKube with multiple messaging platforms like Slack, Mattermost, MS Teams.
Please visit botkube.io to learn more about what BotKube can do.
We received a ton of requests to add Microsoft Teams integration from various platforms. But unfortunately, there were no official Go SDKs available for MS Teams bot. In addition to that, the Microsoft Bot Framework community had no plans to implement that the roadmap. Finally, we decided to implement our own “unofficial” Microsoft Botbuilder SDK for Go. And that’s how msbotbuilder-go SDK was born. You can checkout the Bot Framework SDK for Go announcement.
Unlike Slack or Mattermost, MS Teams apps communicate with backends by sending POST requests to the public endpoints. To establish communications between Teams app and respective backend, it needs to be reachable from the outside world. Now, there are few different ways to expose Kubernetes Service to the outside cluster. In the BotKube installation docs, we have documented the most common way i.e exposing using Ingress resources.
In this release, we have switched from typed clients to a generic dynamic client to monitor resources. This allows BotKube to monitor literally any Kubernetes resource including custom resources. With custom resource monitoring, BotKube helps you solve several interesting use cases, for example, monitoring Velero backup status or monitoring certificate status issued by cert-manager, etc.
Following is the resource config example for monitoring create/delete/error events and updates in status.phase fields in velero.io/v1/backups resource.
- name: velero.io/v1/backups
namespaces:
include:
- all
ignore:
-
events:
- create
- update
- delete
- error
updateSetting:
includeDiff: true
fields:
- status.phase
On event occurrence, BotKube will send notifications like -
BotKube v0.11.0 supports configuring the set of kubectl commands allowed for users to execute with BotKube. To configured commands, add a list of verbs and resources in the kubectl setting section in resource_config. For every command, BotKube maps it to @BotKube [verb] [resource] format and checks if the verb and resource exist in the provided configuration.
settings:
# Set cluster name to differentiate incoming messages
clustername: not-configured
# Kubectl executor configs
kubectl:
# Set true to enable kubectl commands execution
enabled: false
# List of allowed commands
commands:
# kubectl method which are allowed with BotKube command
verbs: ["api-resources", "api-versions", "cluster-info", "describe", "diff", "explain", "get", "logs", "top", "auth"]
# resources on which kubectl methods are allowed with BotKube commands
resources: ["deployments", "pods" , "namespaces", "daemonsets", "statefulsets", "storageclasses", "nodes"]
Complete configuration syntax is documented at BotKube Configuration.
This enables administrators to allow WRITABLE commands like patch, create, delete. The default BotKube RBAC rules provide access to READONLY commands. If you wish to configure WRITABLE commands, don’t forget to update the BotKube RBAC rules accordingly.
On messaging platforms, to check which commands are allowed for users to execute through BotKube, run the @BotKube commands list. Check out- Checking allowed commands for more details.
Find the complete BotKube v0.110 CHANGELOG documentation here..