You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
>Customers with fast release cycles often leverage CI/CD pipelines. In those cases, you might consider altering the build and release pipelines instead of re-deploying the AKS clusters in the target region.
22
+
23
+
## Prerequisites
24
+
25
+
Before you begin the relocation planning stage, first review the following prerequisites:
26
+
27
+
- Ensure that the target region has enough capacity (VM SKUs) to accommodate the new cluster nodes.
28
+
29
+
- Validate that you have resource creation permissions to the target subscription and check that Azure policy isn’t restricting the regions to which AKS can be deployed.
30
+
31
+
- (Optional) Collect the Infrastructure as code (IaC) templates or scripts with which you provisioned the source AKS cluster.
32
+
33
+
- Collect the Kubernetes manifests in order to re-create the application workload within the target cluster
34
+
35
+
>[!TIP]
36
+
>Evaluate a GitOps approach to workload deployment where Kubernetes configuration manifests are stored in a git repo and automatically applied by a GitOps operator running within the cluster, such as [Flux](https://fluxcd.io/). A GitOps approach makes re-deploying workloads to different clusters as simple as installing the GitOps controller and pointing it at the repo.
37
+
38
+
- Review cluster ingress implementation.
39
+
40
+
- Document the DNS changes required to point a public domain to the cluster ingress endpoint.
41
+
42
+
- Review whether the cluster stores any state data, such as any persistent volumes, that you need to migrate to the target cluster.
43
+
44
+
- Document public TLS certificate management and distribution.
45
+
46
+
- Capture any IP addresses defined in the AKS API service whitelist.
47
+
48
+
- Understand all dependent resources. Some of the resources could be:
-[Virtual Network configuration](./relocation-virtual-network.md). Define sufficient subnet sizes to allow container IP growth if using the Azure advanced networking model
54
+
- Public IP address
55
+
- Virtual Network Gateway (VNG). If site-to-site communication is required to an on-premises environment in the target region, a VNG must be created in the target virtual network.
56
+
- Azure Private Endpoint. Azure PaaS resources utilizing private link endpoints will need to be reviewed, and new private link instances created in the target region. i.e., ACR, Azure SQL DB, KeyVault, etc.
-[Azure Container registry](relocation-container-registry.md) For optimal performance when pulling images, the registry should exist in the target region. Azure Container Registry can replicate images between ACR instances. If you use Azure Container Registry to authenticate to the container registry, the new AKS cluster’s managed identity can be the granted ‘AcrPull’ RBAC role.
62
+
- Azure Managed Disks
63
+
- Azure Files
64
+
65
+
## Prepare
66
+
67
+
Before you begin the cluster relocation process, make sure to complete the following preparations:
68
+
69
+
1. Deploy Virtual Network with a number of subnets of sufficient size to accommodate the AKS cluster nodes, and, optionally, pods if using Azure CNI networking
70
+
71
+
1. If you are using Azure Key Vault, [Deploy the Key Vault](./relocation-key-vault.md).
72
+
73
+
1. Ensure that the relevant TLS ingress certificates are available for deployment, ideally in a secure store such as Azure Key Vault.
74
+
75
+
1. Deploy a container registry. Either sync the source registry images automatically or re-build and push new images to the target registry using a CI/CD pipeline or script.
76
+
77
+
1.[Deploy an Azure Monitor workspace](./relocation-log-analytics.md).
78
+
79
+
1. (Optional) [Deploy Azure Application Gateway](./relocation-app-gateway.md) to handle ingress traffic Application Gateway Ingress Controller (AGIC) can tightly integrate with the cluster
80
+
81
+
1. Deploy any data sources required by the cluster workload and restore or sync the source data.
82
+
83
+
1. Execute existing IaC artifacts defined in a CI/CD pipeline that were used to deploy the source cluster and the services it depends upon. Change the code or template input parameters to redeploy to a different resource group and Azure region.
84
+
85
+
86
+
87
+
## Redeploy
88
+
89
+
Deploy the AKS cluster without any data migration, by following the steps below:
90
+
91
+
1. Manually run the existing IaC artifacts on a local workstation to create the target environment in Azure.
92
+
93
+
1. If there are no existing IaC assets, the current cluster configuration [can be exported as an ARM template](/azure/azure-resource-manager/templates/export-template-portal) and executed against the target region. [IaC templates](/azure/templates/) are created from scratch or are modified versions of sample templates using Bicep, JSON, Terraform or another solution.
94
+
95
+
>[!NOTE]
96
+
>- Private Link connections, ACR connected registries and Azure Monitor workspace data sources are not currently exported using this method and must therefore be removed from the generated template before execution.
97
+
98
+
1. Deploy the container workload to the AKS cluster, which can be achieved in two ways:
99
+
-*Pull* Manifests are pulled from a repo and applied by a controller running within the cluster, known as a GitOps approach.
100
+
-*Push.* Manifests are pushed to the cluster using the Kubernetes API service and kubectl command line tool, either from a CI/CD pipeline or local workstation.
101
+
102
+
1. Perform testing and validation on the new cluster to ensure it performs as anticipated.
103
+
104
+
1. Change your public DNS entries to point to the external ingress IP of the target cluster (Azure Public Load Balancer IP or Application Gateway Public IP).
105
+
106
+
1. A deployment using global load-balancing solution such as Azure DNS or Azure Traffic Manager needs to add the
107
+
108
+
## Redeploy with data migration
109
+
110
+
AKS workloads that use local storage, such as persistent volumes, to store data or host database services within the cluster can be backed up on a source cluster and restored to a target cluster. You can perform backup and restoration by using a variety of OSS and paid-for tools such as [Velero](https://velero.io/), [TrilioVault](https://trilio.io/), and [Kasten K10](https://www.veeam.com/products/cloud/kubernetes-data-protection.html).
111
+
112
+
The high-level steps are as follows:
113
+
114
+
1. Deploy the container workload to the AKS cluster, which can be achieved in two ways:
115
+
-*Pull* Manifests are pulled from a repo and applied by a controller running within the cluster, known as a GitOps approach.
116
+
-*Push.* Manifests are pushed to the cluster using the Kubernetes API service and kubectl command line tool, either from a CI/CD pipeline or local workstation.
117
+
118
+
1. Install the backup tool in the source cluster and perform a backup of all cluster objects, volumes, deployments, etc. to an Azure storage account in the source region.
119
+
120
+
1. Create a storage account in the target region and copy the backup across from the source region.
121
+
122
+
1. Install the backup solution in the target cluster.
123
+
124
+
1. Restore the backup to the target cluster.
125
+
126
+
127
+
## Cleanup
128
+
129
+
## Related content
130
+
131
+
132
+
-[Use Azure portal to export a template](/azure/azure-resource-manager/templates/export-template-portal)
0 commit comments