No new CLI to learn
Flexibility to choose platform elements
Declarative platform YAML definition
Learn how Platform-as-Code approach enables teams to compose their platforms with Kubernetes API extensions and build their application workflows declaratively.
One of the key reasons for Kubernetes’s popularity is its extensibility. Kubernetes API extensions (commonly referred as Operators) extend Kubernetes API to manage third-party software as native Kubernetes objects. There are 400+ GitHub repositories with Operator implementations for middleware like databases, queues, loggers, etc. Kubernetes API extensions or Operators form foundation for Platform-as-Code experience.
Platform-as-Code refers to the process that application developers follow to create declarative platform workflows in Kubernetes YAMLs leveraging Custom Resources introduced by Operators along with built-in Resources. This involves discovering relevant information about the Custom Resources and binding the required Resources to define a workflow.
- DevOps engineer is responsible for assembling the platform layer by selecting required Kubernetes CRDs/Operators.
- Application developer then consumes this platform layer by creating custom platform stacks composing various Custom and in-built Resources together through Kubernetes YAMLs.
Above figure demonstrates this Platform-as-Code approach as a flow diagram. We have developed KubePlus API discovery add-on to further simplify discovery and use Custom Resources introduced by Operators towards building Platforms as-Code.
We are building comprehensive guidelines for curating Operators / API extensions for their enterprise readiness.
We have developed KubePlus API discovery add-on to simplify discovery and use of Kubernetes Custom Resources towards building Platform as Code workflows. Once installed on the Kubernetes cluster, this add-on offers new API endpoints (e.g. ‘man’, ‘composition’) that enable application developers to query static and dynamic information about various Custom Resources available in the cluster. This information is very useful towards using individual Custom Resources as well as binding them together in a workflow.
This add-on currently focusses on providing required information to build interactions between Kubernetes Custom & built-in Resources manually in Kubernetes YAMLs and ultimately define a Platform-as-Code workflow. In the roadmap, we plan to develop additional automation in this add-on that will help with automatic resolution and binding between Custom Resources within a Platform-as-Code workflow.
For more details on architecture, demo and usage guidance checkout GitHub page.
- Use ‘man’ endpoint to find out static usage information about Moodle Custom Resource:
# kubectl get --raw "/apis/platform-as-code/v1/man?kind=Moodle"
Use ‘composition’ endpoint to find out composition information of underlying resources of Moodle Custom Resource's moodle1 instance:
# kubectl get --raw "/apis/platform-as-code/v1/composition?kind=Moodle&instance=moodle1&namespace=ns1"
Comprehensive guidelines for Operator interoperability and discoverability in multi-Operator platform stacks.
Extend Kubernetes without any custom automation using Curated Operators for Platform-as-Code.
Repeatable and shareable way of creating application platforms as-Code with Kubernetes YAMLs.