Kubernetes Operators extend Kubernetes APIs by adding Custom Resources that embed application specific automation. There are 1000+ GitHub repositories of variety of Operators to handle middleware functions like databases, backup/restore etc. Enterprise DevOps teams use these community Operators or build Operators in-house for creating their Kubernetes native stacks.
How do you simplify discovery & use of Custom Resources?
How do you troubleshoot & monitor Custom Resources?
Any ‘as-Code’ system is designed to offer a common declarative language to provision and manage a technology stack leveraging underlying APIs / resources. In the Kubernetes world, Kubernetes YAML itself supports Custom Resources (APIs) added by the various Operators. The challenge is in discovery and use of these Custom Resources as part of workload orchestration. Platform-as-Code offers generic tooling (KubePlus) that augments your existing tools like Helm, kubectl or Prometheus to simplify discovery, use, troubleshooting and monitoring of Custom Resources.
Platform-as-Code offers generic tooling that simplifies discovery, use, troubleshooting and monitoring of Custom Resources added by the Operators. This involves tagging Kubernetes Operator packages with a unique method (Platform-as-Code annotations on CRDs) that unlocks our open source KubePlus tooling to work for those specific Operators.
# kubectl connections
Custom Resource aware resource topologies
# kubectl grouplogs
Aggregate logs at workflow or Custom Resource level
CPU/ Memory/Storage utilization for workflows or Custom Resources
Resource binding functions
Simplify creating connections between resources.
Deployment workflows are realized by establishing relationships between available Kubernetes Resources (built-in or Custom). These relationships are primarily of four types.
-> (1) Owner references – A resource internally creates additional resources (e.g. MysqlCluster when instantiated, creates Pods and Services). These sub-resources are related to the parent resource through Owner reference relationship.
-> (2) Labels and (3) Annotations – Labels or Annotations are key/value pairs that are attached to Kubernetes resources. Resource A can depend on a specific label or annotation to be given on Resource B to take some action.
-> (4) Spec Properties – Resource A’s Spec property may depend on a value coming from Resource B.
At the core, KubePlus is able to construct these relationship graphs at runtime that include Custom or built-in resources. These are used to enable troubleshooting, monitoring and workflow management.
Kubernetes monitoring environments are designed to support monitoring for built-in resources like Pods and Services. KubePlus allows you to improve your existing monitoring environment to get CPU/Memory/Storage insights for Custom Resources from your stack. This significantly helps in troubleshooting and planning at workflow level.
Here is an example of improving Prometheus based monitoring to show CPU utilization for MysqlCluster Custom Resource.