Kubernetes API extensions (Operators) of your choice.
Fine-grained insights into platform workflows.
Enterprises are building their Kubernetes stacks using a variety of Kubernetes API extensions but then struggle to manage platform workflows created using the available APIs. At CloudARK we are pioneering Platform-as-Code technology that enables users to build and manage Kubernetes platform automation. This involves tagging Kubernetes API extension packages with a unique method (Platform-as-Code annotations on CRDs) that unlocks our open source KubePlus tooling to work for that specific stack.
Here is a simple example of how a CRD annotation on ClusterIssuer Custom Resource enables KubePlus to show various resource relationships in its workflow.
ClusterIssuer Custom Resource works based on annotation relationship on Ingress resources. So we have annotated this ClusterIssuer CRD with the following Platform-as-Code annotation:
resource/annotation-relationship: on:Ingress, key:cert-manager.io/cluster-issuer, value:INSTANCE.metadata.name
This enables KubePlus to show all resource relationship graphs involving ClusterIssuer Custom Resource as shown below:
$ kubectl connections cr ClusterIssuer wordpress-stack namespace1
::Final connections graph::
------ Branch 1 ------
Level:1 Ingress/wordpress-ingress [related to ClusterIssuer/wordpress-stack by:annotation]
Level:2 Service/wordpress [related to Ingress/wordpress-ingress by:specproperty]
Level:3 Pod/wordpress-pod [related to Service/wordpress by:label]
KubePlus allows you to improve your existing monitoring environment to get fine-grained insights into Custom Resources. Here is an example of improving Prometheus based monitoring to show CPU utilization at Custom Resource level instead of just Pod level.