Version: v1.1

Multi-Cluster App Delivery

This section will introduce how to use KubeVela for multi-cluster application delivery and why.

Introduction

There are more and more situations come out that organizations need multi-cluster technology for application delivery:

  • For scalability, a single Kubernetes cluster has its limit around 5K nodes or less, it is unable to handle the large scale application load.
  • For stability/availability, application can deploy in multi-cluster for backup which provides more stability and availability.
  • For security, you may need to deploy in different zones/areas as government policy requires.

The following guide will the multi-cluster that helps you easily deploy an application to different environments.

Preparation

You can simply join an existing cluster into KubeVela by specify its KubeConfig like below.

  1. vela cluster join <your kubeconfig path>

It will use field context.cluster in KubeConfig as the cluster name automatically, you can also specify the name by --name parameter. For example:

  1. vela cluster join stage-cluster.kubeconfig --name cluster-staging
  2. vela cluster join prod-cluster.kubeconfig --name cluster-prod

After clusters joined, you could list all clusters managed by KubeVela currently.

  1. $ vela cluster list
  2. CLUSTER TYPE ENDPOINT
  3. cluster-prod tls https://47.88.4.97:6443
  4. cluster-staging tls https://47.88.7.230:6443

You can also detach a cluster if you’re not using it any more.

  1. $ vela cluster detach cluster-prod

If there’s still any application running in the cluster, the command will be rejected.

Deploy Application to multi cluster

KubeVela regards a Kubernetes cluster as an environment, so you can deploy an application into one or more environments.

Below is an example, deploy to a staging environment first, check the application running well, and finally promote to production environment.

For different environments, the deployment configuration can also have some nuance. In the staging environment, we only need one replica for the webservice and do not need the worker. In the production environment, we setup 3 replicas for the webservice and enable the worker.

  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4. name: example-app
  5. namespace: default
  6. spec:
  7. components:
  8. - name: hello-world-server
  9. type: webservice
  10. properties:
  11. image: crccheck/hello-world
  12. port: 8000
  13. traits:
  14. - type: scaler
  15. properties:
  16. replicas: 1
  17. - name: data-worker
  18. type: worker
  19. properties:
  20. image: busybox
  21. cmd:
  22. - sleep
  23. - '1000000'
  24. policies:
  25. - name: example-multi-env-policy
  26. type: env-binding
  27. properties:
  28. envs:
  29. - name: staging
  30. placement: # selecting the cluster to deploy to
  31. clusterSelector:
  32. name: cluster-staging
  33. selector: # selecting which component to use
  34. components:
  35. - hello-world-server
  36. - name: prod
  37. placement:
  38. clusterSelector:
  39. name: cluster-prod
  40. patch: # overlay patch on above components
  41. components:
  42. - name: hello-world-server
  43. type: webservice
  44. traits:
  45. - type: scaler
  46. properties:
  47. replicas: 3
  48. - name: health-policy-demo
  49. type: health
  50. properties:
  51. probeInterval: 5
  52. probeTimeout: 10
  53. workflow:
  54. steps:
  55. # deploy to staging env
  56. - name: deploy-staging
  57. type: deploy2env
  58. properties:
  59. policy: example-multi-env-policy
  60. env: staging
  61. # manual check
  62. - name: manual-approval
  63. type: suspend
  64. # deploy to prod env
  65. - name: deploy-prod
  66. type: deploy2env
  67. properties:
  68. policy: example-multi-env-policy
  69. env: prod

After the application deployed, it will run as the workflow steps.

You can refer to Env Binding and Health Check policy user guide for parameter details.

It will deploy application to staging environment first, you can check the Application status by:

  1. > kubectl get application example-app
  2. NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
  3. example-app hello-world-server webservice workflowSuspending true Ready:1/1 10s

We can see that the workflow is suspended at manual-approval:

  1. ...
  2. status:
  3. workflow:
  4. appRevision: example-app-v1:44a6447e3653bcc2
  5. contextBackend:
  6. apiVersion: v1
  7. kind: ConfigMap
  8. name: workflow-example-app-context
  9. uid: 56ddcde6-8a83-4ac3-bf94-d19f8f55eb3d
  10. mode: StepByStep
  11. steps:
  12. - id: wek2b31nai
  13. name: deploy-staging
  14. phase: succeeded
  15. type: deploy2env
  16. - id: 7j5eb764mk
  17. name: manual-approval
  18. phase: succeeded
  19. type: suspend
  20. suspend: true
  21. terminated: false
  22. waitCount: 0

You can also check the health status in the status.service field below.

  1. ...
  2. status:
  3. services:
  4. - env: staging
  5. healthy: true
  6. message: 'Ready:1/1 '
  7. name: hello-world-server
  8. scopes:
  9. - apiVersion: core.oam.dev/v1alpha2
  10. kind: HealthScope
  11. name: health-policy-demo
  12. namespace: test
  13. uid: 6e6230a3-93f3-4dba-ba09-dd863b6c4a88
  14. traits:
  15. - healthy: true
  16. type: scaler
  17. workloadDefinition:
  18. apiVersion: apps/v1
  19. kind: Deployment

You can use resume command after everything verified in statging cluster:

  1. > vela workflow resume example-app
  2. Successfully resume workflow: example-app

Recheck the Application status:

  1. > kubectl get application example-app
  2. NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
  3. example-app hello-world-server webservice running true Ready:1/1 62s
  1. status:
  2. services:
  3. - env: staging
  4. healthy: true
  5. message: 'Ready:1/1 '
  6. name: hello-world-server
  7. scopes:
  8. - apiVersion: core.oam.dev/v1alpha2
  9. kind: HealthScope
  10. name: health-policy-demo
  11. namespace: default
  12. uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
  13. traits:
  14. - healthy: true
  15. type: scaler
  16. workloadDefinition:
  17. apiVersion: apps/v1
  18. kind: Deployment
  19. - env: prod
  20. healthy: true
  21. message: 'Ready:3/3 '
  22. name: hello-world-server
  23. scopes:
  24. - apiVersion: core.oam.dev/v1alpha2
  25. kind: HealthScope
  26. name: health-policy-demo
  27. namespace: default
  28. uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
  29. traits:
  30. - healthy: true
  31. type: scaler
  32. workloadDefinition:
  33. apiVersion: apps/v1
  34. kind: Deployment
  35. - env: prod
  36. healthy: true
  37. message: 'Ready:1/1 '
  38. name: data-worker
  39. scopes:
  40. - apiVersion: core.oam.dev/v1alpha2
  41. kind: HealthScope
  42. name: health-policy-demo
  43. namespace: default
  44. uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
  45. workloadDefinition:
  46. apiVersion: apps/v1
  47. kind: Deployment

All the step status in workflow is succeeded:

  1. ...
  2. status:
  3. workflow:
  4. appRevision: example-app-v1:44a6447e3653bcc2
  5. contextBackend:
  6. apiVersion: v1
  7. kind: ConfigMap
  8. name: workflow-example-app-context
  9. uid: e1e7bd2d-8743-4239-9de7-55a0dd76e5d3
  10. mode: StepByStep
  11. steps:
  12. - id: q8yx7pr8wb
  13. name: deploy-staging
  14. phase: succeeded
  15. type: deploy2env
  16. - id: 6oxrtvki9o
  17. name: manual-approval
  18. phase: succeeded
  19. type: suspend
  20. - id: uk287p8c31
  21. name: deploy-prod
  22. phase: succeeded
  23. type: deploy2env
  24. suspend: false
  25. terminated: false
  26. waitCount: 0

More use cases

KubeVela can provide many strategies to deploy an application to multiple clusters by composing env-binding policy and workflow steps.

You can have a glimpse of how does it work as below:

alt

More use cases about the multi cluster application deployment are coming soon.