This guidance will demonstrate how to use kpt to manage KubeVela applications.
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:
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.
- Follow the instructions in the installation document to get KubeVela installed.
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.
So release your KubeVel app only needs two steps.
-
Create/Fork a github repo.
-
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
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
$ 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
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.
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.
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.
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"}
With kpt, you could see an overview of your App.
$ kpt cfg count sampleapp
Application: 1
ConfigMap: 1
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!