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
Copy file name to clipboardExpand all lines: docs/book/src/developers/tilt-with-aks-as-mgmt-ilb.md
+19-10Lines changed: 19 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,13 @@
1
1
# Tilt with AKS as Management Cluster with Internal Load Balancer
2
2
3
3
## Introduction
4
+
4
5
This guide is explaining how to set up and use Azure Kubernetes Service (AKS) as a management cluster for Cluster API Provider Azure (CAPZ) development using Tilt and an internal load balancer (ILB).
5
6
6
7
While the default Tilt setup recommends using a KIND cluster as the management cluster for faster development and experimentation, this guide demonstrates using AKS as an alternative management cluster. We also cover additional steps for working with stricter network policies - particularly useful for organizations that need to maintain all cluster communications within their Azure Virtual Network (VNet) infrastructure with enhanced access controls.
7
8
8
9
### Who is this for?
10
+
9
11
- Developers who want to use AKS as the management cluster for CAPZ development.
10
12
- Developers working in environments with strict network security requirements.
11
13
- Teams that need to keep all Kubernetes API traffic within Azure VNet
@@ -31,8 +33,10 @@ While the default Tilt setup recommends using a KIND cluster as the management c
31
33
- If `tilt-settings.yaml` file exists in the root of your repo, clear out any values in `kustomize_settings` unless you want to use them instead of the values that will be set by running `make aks-create`.
32
34
33
35
### Managed Identity & Registry Setup
36
+
34
37
1. Have a managed identity created from Azure Portal.
35
38
2. Add the following lines to your shell config such as `~/.bashrc` or `~/.zshrc`
3. Be sure to reload with `source ~/.bashrc` or `source ~/.zshrc` and then verify the correct env vars values return with `echo $AZURE_CLIENT_ID` and `echo $REGISTRY`.
46
51
47
52
## Steps to Use Tilt with AKS as the Management Cluster
48
53
49
-
1. In tilt-settings.yaml, set subscription_type to "corporate" and remove any other env values unless you want to override env variables created by `make aks-create`. Example:
50
-
```
51
-
.
52
-
.
53
-
.
54
-
kustomize_substitutions:
55
-
SUBSCRIPTION_TYPE: "corporate"
56
-
.
54
+
1. Ensure that the tilt-settings.yaml in root of the repository looks like below
55
+
56
+
```yaml
57
+
kustomize_substitutions: {}
58
+
allowed_contexts:
59
+
- "kind-capz"
60
+
container_args:
61
+
capz-controller-manager:
62
+
- "--v=4"
57
63
```
64
+
65
+
- Add env variables in `kustomize_substitutions` if you want the added env variables to take precedence over the env values exported by running `make aks-create`.
66
+
- Port over an variables set in `tilt-settings.json` to `tilt-settings.yaml`'s `kustomize_substitution:{}` and delete `tilt-settings.json` if present in your local.
58
67
2. `make clean`
59
68
- This make target does not need to be run every time. Run it to remove bin and kubeconfigs.
60
69
3. `make generate`
@@ -96,7 +105,7 @@ Running an e2e test locally in a restricted environment calls for some workaroun
96
105
2. Assign that managed identity a contributor role to your subscription
97
106
3. Set `AZURE_CLIENT_ID_USER_ASSIGNED_IDENTITY`, `AZURE_OBJECT_ID_USER_ASSIGNED_IDENTITY`, and `AZURE_USER_ASSIGNED_IDENTITY_RESOURCE_ID` to the user-assigned managed identity.
98
107
99
-
####Update prow template with apiserver ILB networking solution
108
+
### Update prow template with apiserver ILB networking solution
100
109
101
110
There are three sections of a prow template that need an update.
102
111
@@ -180,7 +189,7 @@ A sample kustomize command for updating a prow template via its kustomization.ya
#### Peer Vnets of the management cluster and the workload cluster
192
+
#### Peer VNets of the management cluster and the workload cluster
184
193
185
194
Peering VNets, creating a private DNS zone with the FQDN of the workload cluster, and updating NSGs of the management and workload clusters can be achieved by running `scripts/peer-vnets.sh`.
0 commit comments