fix tiny typo (#1480)

Signed-off-by: Gallardot <tttick@163.com>

design/vela-core/APIServer-Catalog.md

@@ -51,7 +51,7 @@ There are two distinguished layers:
 - **API layer**: It defines the API discovery and serving endpoints that Vela APIServer implementation must follow. This is the integration point for external system components (e.g. UI) to contact.
 - **Storage layer**: It describes the storage systems and objects that Vela APIServer syncs data with behind the scene. There are three types of storage:
   - **K8s cluster**: Vela APIServer manages multiple k8s clusters with regard to the applications and definitions custom resources.
-  - **Catalog server**: Vela APIServer manages mulitple catalogs which contain COTS application pacakges. Currently in our use case the catalogs resides in Git repos. In the future we can extend this to other catalog storage like file server, object storage.
+  - **Catalog server**: Vela APIServer manages multiple catalogs which contain COTS application pacakges. Currently in our use case the catalogs resides in Git repos. In the future we can extend this to other catalog storage like file server, object storage.
   - **MySQL database**: Vela APIServer stores global, cross-cluster, cross catalog information in a MySQL database. These data do not exist in k8s or catalog and thus need to be managed by APIServer in a separate database. The database is usually hosted on cloud.
 
 #### Environment API

design/vela-core/app_deployment.md

@@ -105,7 +105,7 @@ In the following example, we are assuming the app has deployed v1 now and is upg
 
 We will make sure the spec works for the following environments:
 
-- K8s ingress + service (traffic split percetange determined by replica number)
+- K8s ingress + service (traffic split percentages determined by replica number)
 - Istio service mesh
 
 Here is the workflow with Istio:

design/vela-core/apply-once-only.md

@@ -142,7 +142,7 @@ Besides the condition in `apply-once-only`, `apply-once-only-force` has one more
 
 Three available options are provided to a vela-core runtime setup flag named `apply-one-only`, referring to three modes:
 
-- off - `apply-once-only` is disabeld, this is the default option
+- off - `apply-once-only` is disabled, this is the default option
 - on - `apply-once-only` is enabled
 - force - `apply-once-only-force` is enabled
 

design/vela-core/apply-workload-and-trait.md

@@ -152,7 +152,7 @@ status:
 # update with original manifest fails
 # reconciling also fails for cannot applying trait
 ```
-Additonally, if a trait has no immutable field, update will eliminate all fields set by others.
+Additionally, if a trait has no immutable field, update will eliminate all fields set by others.
 ```yaml
 # original trait manifest
 kind: Bar

design/vela-core/restful-interface.md

@@ -136,7 +136,7 @@ const cueTemplate appCreateMode = "appFile"
 ```go
 type appConfigValue struct {
     appName string       `json:"appName"`
-    defintion runtime.RawExtension `json:"defintion"` // the content
+    definition runtime.RawExtension `json:"definition"` // the content
     definitionName string `json:"definitionName"` // use to find the definition
     definitionType string `json:"definitionType"`
 }
@@ -161,7 +161,7 @@ const cueTemplate appUpdateMode = "appFile"
 ```go
 
 type appConfigValue struct {
-    defintion runtime.RawExtension `json:"defintion"` // the content
+    definition runtime.RawExtension `json:"definition"` // the content
 }
 ```
 

design/vela-core/rollout-design.md

@@ -179,7 +179,7 @@ just change the application, and the system will pick up the change, then apply
  depends on the workload type and we will list each in the 
  [rollout with different workload](#Rollout plan work with different type of workloads) section
  . This special AC logic is also the real magic for the other rollout scenario to work as AC
-  controller is the only entity that is directly responsible for emiting the workload to the k8s.
+  controller is the only entity that is directly responsible for emitting the workload to the k8s.
 
 
 #### ApplicationDeployment workflow 

docs/en/cue/cross-namespace-resource.md

@@ -4,7 +4,7 @@ title:  Define resources located in defferent namespace with application
 
 In this section, we will introduce how to use cue template create resources (workload/trait) in different namespace with the application.
 
-By default, the `metadata.namespace` of K8s resource in CuE template is automatically filled with the same namespace of the applicaiton.
+By default, the `metadata.namespace` of K8s resource in CuE template is automatically filled with the same namespace of the application.
 
 If you want to create K8s resources running in a specific namespace witch is different with the application, you can set the `metadata.namespace` field.
 KubeVela will create the resources in the specified namespace, and create a resourceTracker object as owener of those resources.

docs/en/platform-engineers/debug-test-cue.md

@@ -571,7 +571,7 @@ context:
 
 ## Dry-Run the `Application`
 
-When CUE template is good, we can use `vela system dry-run` to dry run and check the rendered resources in real Kubernetes cluster. This command will exactly execute the same render logic in KubeVela's `Application` Controller adn output the result for you.
+When CUE template is good, we can use `vela system dry-run` to dry run and check the rendered resources in real Kubernetes cluster. This command will exactly execute the same render logic in KubeVela's `Application` Controller and output the result for you.
 
 First, we need use `mergedef.sh` to merge the definition and cue files.