Multi Cluster Distribution
This section requires you to know the basics about how to deploy multi-cluster application with policy and workflow. You can refer to Multi-cluster Delivery for container images, they're working in the same way.
You can reference and distribute existing Kubernetes objects with KubeVela in the following scenarios:
- Copying secrets from the hub cluster into managed clusters.
- Promote deployments from canary clusters into production clusters.
- Using Kubernetes apiserver as the control plane and storing all Kubernetes objects data in external databases. Then dispatch those data into real Kuberenetes managed clusters.
#
Refer to Existing Kubernetes Objects in ComponentTo use existing Kubernetes objects in the component, you need to use the ref-objects
typed component and declare which resources you want to refer to. For example, in the following example, the secret image-credential-to-copy
in namespace examples
will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
#
Details for the ref-objects typed componentThe most simple way to specify resources is to directly use resource: secret
or resource: deployment
to describe the kind of resources. If no name
or labelSelector
is set, the application will try to find the resource with the same name as the component name in the application's namespace. You can also explicitly specify name
and namespace
for the target resource as well.
In addition to name
and namespace
, you can also specify the cluster
field to let the application component refer to resources in managed clusters. You can also use the labelSelector
to select resources in replace of finding resources by names.
In the following example, the application will select all deployments in the hangzhou-1 cluster inside the examples namespace, which matches the desided labels. Then the application will copy these deployments into hangzhou-2 cluster.
In some cases, you might want to restrict the scope for the application to access resources. You can set the
--ref-objects-available-scope
tonamespace
orcluster
in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
#
Working with TraitThe ref-objects typed component can also be used together with traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
There are several commonly used trait that could be used together with the ref-objects, particularly for Deployment.
#
Container ImageThe container-image
trait can be used to change the default image settings declared in the original deployment.
By default, the container-image
will replace the original image in the main container (the container uses the name of the component).
You can modify other containers by setting the containerName
field.
You can also modify the ImagePullPolicy as well.
Multiple container patch is also available.
#
CommandThe command
trait can be used to modify the original running command in deployment's pods.
The above configuration can be used to patch the main container (the container that uses the name of the component). If you would like to modify another container, you could use the field containerName
.
If you want to replace the existing args in the container, instead of the command, use the args
parameter.
If you want to append/delete args to the existing args, use the addArgs
/delArgs
parameter. This can be useful if you have lots of args to be managed.
You can also configure commands in multiple containers.
#
Environment VariableWith the trait env
, you can easily manipulate the declared environment variables.
For example, the following usage shows how to set multiple environment variables in the main container (the container uses the component's name). If any environment variable does not exist, it will be added. If exists, it will be updated.
You can remove existing environment variables by setting the unset
field.
If you would like to clear all the existing environment variables first, and then add new variables, use replace: true
.
If you want to modify the environment variable in other containers, use the containerName
field.
You can set environment variables in multiple containers as well.
#
Labels & AnnotationsTo add/update/remove labels or annotations for the workload (like Kubernetes Deployment), use the labels
or annotations
trait.
#
JSON Patch & JSON Merge PatchExcept for the above trait, a more powerful but more complex way to modify the original resources is to use the json-patch
or json-merge-patch
trait. They follow the RFC 6902 and RFC 7386 respectively. Usage examples are shown below.