Skip to content

Latest commit

 

History

History
 
 

05.KUBEVELA_KPT_Demo

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 

Managing KubeVela applications with kpt

This guidance will demonstrate how to use kpt to manage KubeVela applications.

What is kpt?

Pioneered by Kubernetes community, Configuration-as-Data emphasizes that "configuration should be treated as data and leverage pipelines for manipulation and policy enforcement". In Kubernetes, Configuration-as-Data approach builds upon the design of the Kubernetes resource model (KRM). As a result, today any resource we applied to Kubernetes is a piece of data that represents the desired state for certain part of application or infrastructure in the real system.

With the heart of Configuration-as-Data, a typical Kubernetes native application management workflow just looks like a "pipeline". See the picture below:

img

In this workflow, kpt is the manipulator of data. Stored in data source like Git, the original data (e.g. deployment.yaml) will pass through a pipeline of kpt functionalities to be manipulated into the desire state step by step. For example, labels added, replicas modified and image updated etc.

Pre-requisites

  • Follow the instructions in the installation document to get KubeVela installed.

Create App Repository for kpt

kpt directly use GitHub repo as App Repository, so no action needed.

With the help of kpt, we could directly use GitHub Repo as App Repository without organizing apps in any fixed format.

Release your application to App Repository

So release your KubeVel app only needs two steps.

  1. Create/Fork a github repo.

  2. Commit and push your app.

    git add sampleapp/
    git commit -m "my sampleapp commit"
    git remote add origin [email protected]:<your-account>/<your-app-repo>.git
    git push -u origin master

Fetch KubeVela app from remote Repository

Using our example repository for this demo.

You could fetch KubeVel app from remote Repository using kpt pkg get.

$ kpt pkg get https://github.com/oam-dev/samples.git/5.OAM_KPT_Demo/repository/sampleapp sampleapp

fetching package /5.OAM_KPT_Demo/repository/sampleapp from https://github.com/oam-dev/samples to sampleapp
$ kpt tree sampleapp
sampleapp
├── Kptfile
└── app.yaml

0 directories, 2 files

Deploy sample app

$ kubectl apply -f sampleapp/
application.core.oam.dev/example-app created

Check the underlying Deployment instance generated by KubeVela.

$ kubectl get deploy
NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
example-component                       3/3     3            3           1m

Sync with Remote App Repository

When some changes occurred both local and remote apps, you could sync and merge with kpt.

For example, we changed our sampleapp and tag it as v0.1.0, then our local sampleapp also is changed.

kpt pkg update [email protected] --strategy=resource-merge

Ref to update section of kpt for more details.

Properties Setting

kpt setters is a powerful feature which naturally matches to the idea of "separate concerns" design from KubeVela.

In KubeVela, developers can claim certain fields in the application YAML as "configurable", so in the following workflow, operators (or the platform) will be allowed to modify these fields.

Now this goal can be easily achieved with help of kpt.

Create setter by App Developer and Operator

Let's say the developer and operator need to claim fields as "configurable" for the application, they can add kpt setters here:

$ kpt cfg create-setter sampleapp/ image nginx:latest --field "image" --description "use to set image for component" --set-by "sampleapp developer"
$ kpt cfg create-setter sampleapp/ replicas 3 --field "replicas" --description "use to set replicas of component" --set-by "sampleapp operator"

Then the app operator can see which properties are configurable in this application like this:

$ kpt cfg list-setters sampleapp/
  NAME        VALUE       SET BY            DESCRIPTION             COUNT   REQUIRED   IS SET
  image      nginx:latest            use to set image for component   1       No         Yes
  replicas   3                       use to set replicas of           1       No         Yes

It's very clear and easy to understand.

Set Property Value by App Operator

Then the application operator can set image with a new tag like this:

$ kpt cfg set sampleapp image nginx:1.16.0
set 1 fields

Or set replicas like this:

$ kpt cfg set sampleapp replicas 5
set 1 fields

Check the application and you will find corresponding fileds' value has been changed.

$ cat sampleapp/app.yaml

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: example-app
spec:
  components:
  - name: example-component
    type: webservice
    properties:
      image: nginx:1.16.0 # {"$kpt-set":"image"}
    traits:
    - type: scaler
      properties:
        replicas: 5 # {"$kpt-set":"replicas"}

App Overview

With kpt, you could see an overview of your App.

$ kpt cfg count sampleapp
Application: 1
ConfigMap: 1

Live apply

kpt includes the next-generation apply commands developed out of the Kubernetes cli-utils repository as the kpt live apply command.

This means with kpt live apply command, we could wait for the controller reconcile.

$ kpt live init sampleapp
Initialized: ./5.OAM_KPT_Demo/sampleapp/inventory-template.yaml
$ kpt live apply sampleapp --reconcile-timeout=1m 
application.core.oam.dev/example-app configured
1 resource(s) applied. 0 created, 0 unchanged, 1 configured, 0 failed
application.core.oam.dev/example-app is Current: Resource is current
application.core.oam.dev/example-app is Current: Resource is current
0 resource(s) pruned, 0 skipped, 0 failed

Happly building KubeVela apps with kpt!