6.3 KiB
title
| title |
|---|
| Overview |
This documentation will explain what is Application object and why you need it.
Motivation
Encapsulation based abstraction is probably the mostly widely used approach to enable easier developer experience and allow users to deliver the whole application resources as one unit. For example, many tools today encapsulate Kubernetes Deployment and Service into a Web Service module, and then instantiate this module by simply providing parameters such as image=foo and ports=80. This pattern can be found in cdk8s (e.g. web-service.ts ), CUE (e.g. kube.cue), and many widely used Helm charts (e.g. Web Service).
Despite the efficiency and extensibility in defining abstractions, both DSL tools (e.g. cdk8s , CUE and Helm templating) are mostly used as client side tools and can be barely used as a platform level building block. This leaves platform builders either have to create restricted/inextensible abstractions, or re-invent the wheels of what DSL/templating has already been doing great.
KubeVela allows platform teams to create developer-centric abstractions with DSL/templating but maintain them with the battle tested Kubernetes Control Loop.
Application
First of all, KubeVela introduces an Application CRD as its main abstraction that could capture a full application deployment. To model the modern microservices, every application is composed by multiple components with attached traits (operational behaviors). For example:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: application-sample
spec:
components:
- name: foo
type: webservice
properties:
image: crccheck/hello-world
port: 8000
traits:
- type: ingress
properties:
domain: testsvc.example.com
http:
"/": 8000
- type: sidecar
properties:
name: "logging"
image: "fluentd"
- name: bar
type: aliyun-oss # cloud service
bucket: "my-bucket"
The schema of component and trait specification in this application is actually enforced by another set of building block objects named "definitions", for example, ComponentDefinition and TraitDefinition.
XxxDefinition resources are designed to leverage encapsulation solutions such as CUE, Helm and Terraform modules to template and parameterize Kubernetes resources as well as cloud services. This enables users to assemble templated capabilities into an Application by simply setting parameters. In the application-sample above, it models a Kubernetes Deployment (component foo) to run container and a Alibaba Cloud OSS bucket (component bar) alongside.
This abstraction mechanism is the key for KubeVela to provide PaaS-like experience (i.e. app-centric, higher level abstractions, self-service operations etc) to end users, with benefits highlighted as below.
No "Juggling" Approach to Manage Kubernetes Objects
For example, as the platform team we want to leverage Istio as the Service Mesh layer to control the traffic to certain Deployment instances. But this could be really painful today because we have to enforce end users to define and manage a set of Kubernetes resources in a "juggling" approach. For example, in a simple canary rollout case, the end users have to carefully manage a primary Deployment, a primary Service, a root Service, a canary Deployment, a canary Service, and have to probably rename the Deployment instance after canary promotion (this is actually unacceptable in production because renaming will lead to the app restart). What's worse, we have to expect the users properly set the labels and selectors on those objects carefully because they are the key to ensure proper accessibility of every app instance and the only revision mechanism our Istio controller could count on.
The issue above could be even painful if the component instance is not Deployment, but StatefulSet or custom workload type. For example, normally it doesn't make sense to replicate a StatefulSet instance during rollout, this means the users have to maintain the name, revision, label, selector, app instances in a totally different approach from Deployment.
Standard Contract Behind The Abstraction
KubeVela is designed to relieve such burden of managing versionized Kubernetes resources manually. In nutshell, all the needed Kubernetes resources for an app are now encapsulated in a single abstraction, and KubeVela will maintain the instance name, revisions, labels and selector by the battle tested reconcile loop automation, not by human hand. At the meantime, the existence of definition objects allow the platform team to customize the details of all above metadata behind the abstraction, even control the behavior of how to do revision.
Thus, all those metadata now become a standard contract that any "day 2" operation controller such as Istio or rollout can rely on. This is the key to ensure our platform could provide user friendly experience but keep "transparent" to the operational behaviors.
No Configuration Drift
Light-weighted and flexible in defining abstractions, any of the existing encapsulation solutions today work at client side, for example, DSL/IaC (Infrastructure as Code) tools and Helm. This approach is easy to be adopted and has less invasion in the user cluster.
But client side abstractions always lead to an issue called Infrastructure/Configuration Drift, i.e. the generated component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes.
Hence, all abstractions in KubeVela is designed to be maintained with Kubernetes Control Loop and leverage Kubernetes control plane to eliminate the issue of configuration drifting, and still keeps the flexibly and velocity enabled by existing encapsulation solutions (e.g. DSL/IaC and templating).