Distributed Cloud Container Platform for Kubernetes (ACK One) allows you to use a Fleet instance to deploy an application across multiple clusters. You can also use different configurations to deploy the application across multiple clusters. This topic describes the rules for using different configurations to deploy an application across multiple clusters.
Rule 1: Change the number of replicated pods created by a Deployment
Use the following YAML template to change the number of replicated pods to five for the Deployment that you want to deploy in the managedcluster-cd****
cluster.
Example
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: cluster-beijing
namespace: demo
type: topology
properties:
# Specify the cluster to which you want to deploy the application.
clusters: ["managedcluster-cd****"]
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-replic-beijing
namespace: demo
# Specify the configuration that is used to override the base configuration.
type: override
properties:
components:
# Reference the component that is defined in the Application object by specifying the name of the component. Then, you can specify the Kubernetes resources that you want to override in the component.
- name: "demo"
# Specify the type of configuration that you want to override. In this example, set the type to scaler and change the number of replicated pods created by the Deployment to five.
traits:
- type: scaler
properties:
replicas: 5
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: deploy-demo
namespace: demo
steps:
- type: deploy
name: deploy-beijing
properties:
# Specify the override configuration and the cluster to which the override configuration is applied in the workflow.
policies: ["override-replic-beijing", "cluster-beijing"]
---
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
annotations:
app.oam.dev/publishVersion: version1
name: demo
namespace: demo
spec:
# Define a component.
components:
- name: demo
type: ref-objects
properties:
objects:
- apiVersion: apps/v1
kind: Deployment
name: demo
# Specify the workflow that is used to deploy the Kubernetes object with the override configuration.
workflow:
ref: deploy-demo
How to override configurations
To change the number of replicated pods created by the Deployment, you must specify the following information:
components
: Define a component in the Application object, reference the component, and specify the Kubernetes objects that you want to override in the component.NoteThe override configuration applies only to the first Kubernetes object that you specified in the component.
traits
: Specify the configuration that is used to override the base configuration by using ACK One. This parameter helps simplify the procedure for overriding configurations. In this example, the type is set toscaler
to change the number of replicated pods created by the Deployment.Parameter
Description
traits. type: scaler
The
type
parameter in thetraits
section specifies the type of configuration that you want to override.traits. properties. replicas
This parameter specifies the number of replicated pods created by a Deployment.
Destination cluster: In the
steps
parameter of theWorkflow
object, specify the Policy object that contains the override configuration and the Policy object that contains the destination cluster. This way, you can use the workflow to deploy the Kubernetes object with the override configuration to the destination cluster.
Rule 2: Change the container image of a Deployment
Use the following YAML template to change the container image of a Deployment.
Example
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-image-beijing
namespace: demo
type: override
properties:
components:
- name: "demo"
# Specify the type of configuration that you want to override. In this example, set the type to container-image and change the container image of a Deployment.
traits:
- type: container-image
properties:
containerName: demo
image: registry.cn-hangzhou.aliyuncs.com/acs/rollouts-demo:green
imagePullPolicy: Always
Parameter description
Parameter | Description |
| The |
| The |
| The |
| The |
Rule 3: Modify the command of a container in a Deployment
Use the following YAML template to modify the command of a container in a Deployment.
Example
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-command
namespace: demo
type: override
properties:
components:
- name: "demo"
# Specify the type of configuration that you want to override. In this example, set the type to command and modify the command of a container in a Deployment.
traits:
- type: command
properties:
containerName: demo
# Override the command parameter in the container.
command: ["demo-command", "demo-parameter1", "demo-parameter2"]
# Override the args parameter in the container.
args: ["demo-parameter1", "demo-parameter2"]
# Add arguments.
addArgs: ["new-parameter1"]
# Delete arguments.
delArgs: ["parameter1-to-delete"]
Parameter description
Parameter | Description |
| The |
| The |
| The |
| The |
| The arguments that you want to add to the |
| The arguments that you want to delete from the |
Rule 4: Modify the environment variables of a container in a Deployment
Use the following YAML template to modify the environment variables of a container in a Deployment.
Example
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-command
namespace: demo
type: override
properties:
components:
- name: "demo"
# Specify the type of configuration that you want to override. In this example, set the type to env and modify the environment variables of a container in a Deployment.
traits:
- type: env
properties:
containerName: demo
# Add new environment variables. If you add an environment variable whose name is the same as the name of an existing environment variable, the value of the existing environment variable is overridden.
env:
key_first: value_first
key_second: value_second
# Delete environment variables from the env parameter of a container.
unset: ["ENV1"]
Parameter description
Parameter | Description |
| The |
| The |
| The new environment variables that you want to add. If you add an environment variable whose name is the same as the name of an existing environment variable, the value of the existing environment variable is overridden. |
| The environment variables that you want to delete from the env parameter of the container. |
Rule 5: Modify resource parameters by using JSON Patch
Use the following YAML template to modify resource parameters by using JSON Patch.
Example
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-json-path
namespace: demo
type: override
properties:
components:
- name: "demo"
# Specify the type of configuration that you want to override. In this example, set the type to json-patch and modify the parameters of the resource by using JSON Patch.
traits:
- type: json-patch
properties:
operations:
# The op: add operation allows you to add a parameter to the resource. In this example, a label is added.
- op: add
path: "/metadata/labels/label-to-add-key"
value: label-to-add-key-value
# The op: replace operation allows you to change the value of a parameter of the resource. In this example, the value of an existing label is changed.
- op: replace
path: "/metadata/labels/label-to-replace-key"
value: label-modified-value
# The op: remove operation allows you to delete a parameter from the resource. In this example, an existing label is deleted.
- op: remove
path: "/metadata/labels/label-to-remove-key"
Parameter description
Parameter | Description |
| The |
| The parameter that you want to add to the resource. |
| The value that is used to replace the value of an existing parameter. |
| The parameter that you want to delete from the resource. |
Rule 6: Modify resource parameters by using JSON Merge
If you use JSON Patch to modify resource parameters, you must specify the value of each parameter that you want to modify. This operation is time-consuming and complex when you need to modify a large number of resource parameters. In this case, you can use JSON Merge to simplify the configuration.
Use the following YAML template to modify resource parameters in the ConfigMaps of different clusters by using JSON Patch.
Example
#Create a ConfigMap on the Fleet instance.
apiVersion: v1
kind: ConfigMap
metadata:
name: demo
namespace: demo
data:
confg-not-override: "not-override"
confg-to-override: "value"
config-file-to-override: |
{
"feature-parameters": {
"key1": "value1",
"key2": "value2",
}
}
config-to-delete: "to-delete"
---
#Create an override policy.
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-configmap
namespace: demo
type: override
properties:
components:
- name: "demo"
#Specify the type of configuration that you want to override. In this example, set the type to json-merge-patch. json-merge-patch allows you to modify resources by defining resource objects in properties and merging the defined resource objects with the base resource objects.
traits:
- type: json-merge-patch
properties:
#The first level of the resource that you want to modify.
data:
#Modify the value of confg-to-override.
confg-to-override: "value-override"
#Add config-to-add.
config-to-add: "to-add"
#Modify the content of config-file-to-override.
config-file-to-override: |
{
"feature-parameters": {
"key1": "value1-override",
"key2": "value2-override",
}
}
#Delete config-to-delete.
config-to-delete: null
---
#The modified resource.
apiVersion: v1
kind: ConfigMap
metadata:
name: demo
namespace: demo
data:
#confg-not-override remains unchanged.
confg-not-override: "not-override"
confg-to-override: "value-override"
config-file-to-override: |
{
"feature-parameters": {
"key1": "value1-override",
"key2": "value2-override",
}
}
Parameter description
Parameter | Description |
| The resource object that you define and merge with the base resource object. |