Version: v1.8

Component Replication

In KubeVela, we can dispatch resources across the clusters using deploy workflow step and override, topology policy. But projects like OpenYurt have finer-grained division like node pool. This requires to dispatch some similar resources to the same cluster. These resources are called replication. Back to the example of OpenYurt, it can integrate KubeVela and replicate the resources then dispatch them to the different node pool.

To replicate component, replication policy is added as a built-in policy. It can be only used together with deploy workflow step. If using replication policy in deploy workflow step, a new field context.replicaKey will be added to when rendering the component. You can use this field to dispatch the resources to the same cluster with different replicaKey.

Component Replication - 图1note

replication policy is only supported in KubeVela version 1.6.0+.

Component Replication - 图2tip

context.replicaKey is always used in metadata.name in ComponentDefinition or TraitDefinition when dispatching resources to avoid name conflict. We’ll see it later in the example.

The following ComponentDefinition is an example which make use of replication policy. It uses context.replicaKey to add suffixes to resource names.

  1. import (
  2. "strconv"
  3. )
  4. "replica-webservice": {
  5. alias: ""
  6. annotations: {}
  7. attributes: {
  8. status: {}
  9. workload: {
  10. definition: {
  11. apiVersion: "apps/v1"
  12. kind: "Deployment"
  13. }
  14. type: "deployments.apps"
  15. }
  16. }
  17. description: "Webservice, but can be replicated"
  18. labels: {}
  19. type: "component"
  20. }
  21. template: {
  22. output: {
  23. apiVersion: "apps/v1"
  24. kind: "Deployment"
  25. metadata: {
  26. if context.replicaKey != _|_ {
  27. name: context.name + "-" + context.replicaKey
  28. }
  29. if context.replicaKey == _|_ {
  30. name: context.name
  31. }
  32. }
  33. spec: {
  34. selector: matchLabels: {
  35. "app.oam.dev/component": context.name
  36. if context.replicaKey != _|_ {
  37. "app.oam.dev/replicaKey": context.replicaKey
  38. }
  39. }
  40. template: {
  41. metadata: {
  42. labels: {
  43. if parameter.labels != _|_ {
  44. parameter.labels
  45. }
  46. "app.oam.dev/name": context.appName
  47. "app.oam.dev/component": context.name
  48. if context.replicaKey != _|_ {
  49. "app.oam.dev/replicaKey": context.replicaKey
  50. }
  51. }
  52. }
  53. spec: {
  54. containers: [{
  55. name: context.name
  56. image: parameter.image
  57. if parameter["ports"] != _|_ {
  58. ports: [ for v in parameter.ports {
  59. {
  60. containerPort: v.port
  61. name: "port-" + strconv.FormatInt(v.port, 10)
  62. }}]
  63. }
  64. }]
  65. }
  66. }
  67. }
  68. }
  69. exposePorts: [
  70. for v in parameter.ports {
  71. port: v.port
  72. targetPort: v.port
  73. name: "port-" + strconv.FormatInt(v.port, 10)
  74. },
  75. ]
  76. outputs: {
  77. if len(exposePorts) != 0 {
  78. webserviceExpose: {
  79. apiVersion: "v1"
  80. kind: "Service"
  81. metadata: {
  82. if context.replicaKey != _|_ {
  83. name: context.name + "-" + context.replicaKey
  84. }
  85. if context.replicaKey == _|_ {
  86. name: context.name
  87. }
  88. }
  89. spec: {
  90. selector: {
  91. "app.oam.dev/component": context.name
  92. if context.replicaKey != _|_ {
  93. "app.oam.dev/replicaKey": context.replicaKey
  94. }
  95. }
  96. ports: exposePorts
  97. }
  98. }
  99. }
  100. }
  101. parameter: {
  102. // +usage=Which image would you like to use for your service
  103. // +short=i
  104. image: string
  105. // +usage=Which ports do you want customer traffic sent to, defaults to 80
  106. ports?: [...{
  107. // +usage=Number of port to expose on the pod's IP address
  108. port: int
  109. }]
  110. }
  111. }

Copy the definition to file replica-webservice.cue and apply the definition:

  1. vela def apply replica-webservice.cue

Then user can apply application below. Replication policy is declared in application.spec.policies. And it is used in deploy step to influence its result.

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: app-replication-policy
  5. spec:
  6. components:
  7. - name: hello-rep
  8. type: replica-webservice
  9. properties:
  10. image: crccheck/hello-world
  11. ports:
  12. - port: 80
  13. expose: true
  14. policies:
  15. - name: replication-default
  16. type: replication
  17. properties:
  18. keys: [ "beijing","hangzhou" ]
  19. selector: [ "hello-rep" ]
  20. workflow:
  21. steps:
  22. - name: deploy-with-rep
  23. type: deploy
  24. properties:
  25. policies: [ "replication-default" ]

Then application will dispatch two deployments and two services:

  1. vela status app-replication-policy --detail --tree
  1. CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
  2. local ─── default─┬─ Service/hello-rep-beijing updated 2022-11-03 11:26:03 Type: ClusterIP Cluster-IP: 10.43.26.211 External-IP: <none>
  3. Port(s): 80/TCP Age: 3h10m
  4. ├─ Service/hello-rep-hangzhou updated 2022-11-03 11:26:03 Type: ClusterIP Cluster-IP: 10.43.36.44 External-IP: <none>
  5. Port(s): 80/TCP Age: 3h10m
  6. ├─ Deployment/hello-rep-beijing updated 2022-11-03 11:26:03 Ready: 1/1 Up-to-date: 1 Available: 1 Age: 3h10m
  7. └─ Deployment/hello-rep-hangzhou updated 2022-11-03 11:26:03 Ready: 1/1 Up-to-date: 1 Available: 1 Age: 3h10m

There are three policies that can use in deploy step: topology, override and replication. They can be used together to both replicate component and dispatch them to different clusters. Here is the rules when they are use together:

  1. The applying order of policies is topology -> override -> replication. More information can be found in Multi cluster Application
    • topology pick up which cluster to dispatch. If not used, application deploy resources to local cluster by default.
    • override modifies the component properties. If not used, no properties will be changed.
    • replication will turn one component into multiple ones.

Component Replication - 图3note

By default, the hub cluster where KubeVela locates is registered as the local cluster. You can use it like a managed cluster in spite that you cannot detach it or modify it.

  1. override and replication can be used together. But override will affect all replication of the component. It is mainly used to modify component properties for different clusters.

Last updated on May 6, 2023 by Tianxin Dong