• Home
    • Platform as Code
    • Operator Maturity Model
    • Multi-tenancy management
    • Training
  • Blog
    • Home
    • Technology
      • Platform as Code
      • Operator Maturity Model
    • Offerings
      • Multi-tenancy management
      • Training
    • Blog
  • Home
  • Blog
CloudARK

Platform-as-Code

Platform-as-CodePlatform-as-Code

Consistent way to build multi-tenant SaaS on Kubernetes.

image217

 Kubernetes multi-tenancy involves creating per-tenant instances of an application ensuring isolation between the instances. It starts with a Helm chart for the application deployment. Platform engineering challenge is to convert this deployment workflow into a service that can be used repeatedly for every tenant with required controls and tracking.  Platform-as-Code is a framework to design such multi-tenant platform services from Helm charts. 

Platform-as-Code

  •  Platform-as-Code is a framework to design multi-tenant platform services from Helm charts with the required isolation guarantees and consumption metrics. 
  • It involves taking a Helm chart of an operational workflow and building a CRD (Kubernetes API) to deliver it as a service, along with attaching required policies and Prometheus monitoring to it.  

image218

Stack level multi-tenancy

In this scenario, platform teams prepare the cluster for running multiple instances of an application stack. It requires platform service/s to simplify repeated deployment of the stack with required isolation, CPU/memory resource allocation and monitoring. Platform-as-Code can be used to create Kubernetes APIs to deliver such platform services. 

image219

Team level multi-tenancy

In this scenario, platform teams prepare the cluster to be used by various internal product teams. This involves creating different users and roles with appropriate privileges in addition to offering multi-tenant application services for these teams. Platform-as-Code can be used to deliver services in such multi-user environments as well. 

KubePlus

Open-source framework to design multi-tenant platform services as-Code

Github
image220

CRD for CRDs

Design your platform services from Helm charts

image221

Resource relationship graphs

Visualize your platform workflows

CRD for CRDs

Kubernetes CRD for CRDs

KubePlus offers a CRD named ResourceComposition to 

  • Compose new CRDs (Custom Resource Definitions) to publish platform services from Helm charts
  • Define policies (e.g. Node selection, CPU/Memory limits, etc.) for managing resources of the platform services
  • Get aggregated CPU/Memory/Storage Prometheus metrics for the platform services

Resource relationship graphs

Kubernetes Resource Relationship Graphs

Platform workflows are realized by establishing relationships between available Kubernetes Resources / APIs (built-in or Custom). These relationships are primarily of four types - (1) Owner references, (2) Labels, (3) Annotations, (4) Spec Properties. KubePlus is able to runtime construct Kubernetes Resource relationship graphs. This enables KubePlus to build resource topologies and offer fine grained visibility and control over the platform service. 

Building a sample platform service

Kubernetes Platform Service

Here we demonstrate how a platform team can build a MySQL service for their product team/s to consume. The cluster has base Kubernetes and MySQL Operator installed. 

The platform workflow requirements are: 

  1. Create a PersistentVolume of required type for MySQL instance. 
  2. Create Secret objects for MySQL instance and AWS backup.
  3. Create MySQL instance with backup target as AWS S3 bucket.  
  4. Setup a policy in such a way that Pods created under this service will have specified Resource Request and Limits.  
  5. Get aggregated CPU/Memory metrics for the overall workflow. 

Kubernetes CRD for CRDs

Here is a new platform service named MysqlService as Kubernetes API. 

A new CRD named MysqlService has been created here using ResourceComposition. You feed a platform workflow Helm chart that created required underlying resources, and additionally provide policy and monitoring inputs for the workflow.  The Spec Properties of MysqlService come from values.yaml of the Helm chart. 

Product teams can use this service to get MySQL database for their application and all the required setups will be performed transparently by this service.

Platform Service in use

Kubernetes Resource Relationship Graphs

Resource relationship graph of MysqlService instance

 Here  is a visual representation of the complete resource relationship graph of the MysqlService instance. This can be discovered using KubePlus kubectl plugin - 'kubectl connections MysqlService mysql1'.  You can see that the platform workflow specified in the Helm chart gets deployed when the instance of the MysqlService is created along with the specified policies and monitoring inputs. 

Prometheus metrics for Custom Resources

CPU utilization in Prometheus for MysqlService instance

KubePlus provides aggregated CPU/Memory/Storage metrics in Prometheus format for the service that can be discovered in your monitoring infrastructure.

Empower your platform engineering with Platform-as-Code subscription.

Find out more


  • GitHub
  • Twitter
  • Partners
  • Contact
  • About

Copyright © 2021 CloudARK

This website uses cookies.

We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.

Accept