Skip to content

Commit 559d209

Browse files
committed
update readme
1 parent eb7d8b1 commit 559d209

File tree

2 files changed

+6
-8
lines changed

2 files changed

+6
-8
lines changed

_examples/aks/README.md

Lines changed: 4 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -27,23 +27,21 @@ export KUBECONFIG=$(terraform output kubeconfig_path|jq -r)
2727
kubectl get pods -n test
2828
```
2929

30-
However, in a real-world scenario, this config file would have to be replaced periodically as the AKS client certificates eventually expire (see the [Azure documentation](https://docs.microsoft.com/en-us/azure/aks/certificate-rotation) for the exact expiry dates). If the certificates are replaced, the AKS module will have to be targeted to pull in the new credentials before they can be passed into the Kubernetes or Helm providers.
30+
However, in a real-world scenario, this config file would have to be replaced periodically as the AKS client certificates eventually expire (see the [Azure documentation](https://docs.microsoft.com/en-us/azure/aks/certificate-rotation) for the exact expiry dates). If the certificates (or other authentication attributes) are replaced, run `terraform apply` to pull in the new credentials.
3131

3232
```
33-
terraform state rm module.kubernetes-config
34-
terraform plan
3533
terraform apply
3634
export KUBECONFIG=$(terraform output kubeconfig_path|jq -r)
3735
kubectl get pods -n test
3836
```
3937

40-
This approach prevents the Kubernetes and Helm provider from using cached, invalid credentials, which would cause provider configuration errors durring the plan and apply phases. (The resources that were previously deployed will not be affected by the `state rm`).
38+
This approach prevents the Kubernetes and Helm providers from attempting to use cached, invalid credentials, which would cause provider configuration errors durring the plan and apply phases.
4139

42-
## Replacing the AKS cluster, or its authentication credentials
40+
## Replacing the AKS cluster and re-creating the Kubernetes / Helm resources
4341

4442
When the cluster is initially created, the Kubernetes and Helm providers will not be initialized until authentication details are created for the cluster. However, for future operations that may involve replacing the underlying cluster (for example, changing VM sizes), the AKS cluster will have to be targeted without the Kubernetes/Helm providers, as shown below. This is done by removing the `module.kubernetes-config` from Terraform State prior to replacing cluster credentials, to avoid passing outdated credentials into the providers.
4543

46-
This will create the new cluster and the Kubernetes resources in a single apply. If this is being applied to an existing cluster (such as in the case of credential rotation), the existing Kubernetes/Helm resources will continue running and simply undergo a credential refresh.
44+
This will create the new cluster and the Kubernetes resources in a single apply.
4745

4846
```
4947
terraform state rm module.kubernetes-config

_examples/aks/aks-cluster/main.tf

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,8 +12,8 @@ resource "azurerm_kubernetes_cluster" "test" {
1212
default_node_pool {
1313
name = "default"
1414
node_count = 1
15-
#vm_size = "Standard_DS2_v2"
16-
vm_size = "Standard_A2_v2"
15+
vm_size = "Standard_DS2_v2"
16+
#vm_size = "Standard_A2_v2"
1717
}
1818

1919
identity {

0 commit comments

Comments
 (0)