From a6030bd16f2477581b0f6728247faeb4b21fa208 Mon Sep 17 00:00:00 2001 From: ruban suthan Date: Mon, 18 Mar 2024 14:04:53 +1100 Subject: [PATCH] new update for eks-cluster-upgrades --- _posts/2023-08-03-eks-cluster-upgrades.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2023-08-03-eks-cluster-upgrades.md b/_posts/2023-08-03-eks-cluster-upgrades.md index 26893c7..ae73628 100644 --- a/_posts/2023-08-03-eks-cluster-upgrades.md +++ b/_posts/2023-08-03-eks-cluster-upgrades.md @@ -66,7 +66,7 @@ Steps from 6 to 18 are common to any migration of stateful apps, not limited to > important thing to keep in mind when reusing retained PVs is deploying a new PV with the same name would not work as in deploying a new release with `PVC.spec.volumeName`. This will open up anyone to hijack the PVs by just knowings its name. Hence an admin intervention is required to delete the `PV.Spec.ClaimRef` from the retained PVs or pre-fill `PV.Spec.ClaimRef` with a pointer to the new PVC as explained [here](https://github.com/kubernetes/kubernetes/issues/48609#issuecomment-314066616) -In the end, the traffic was fully transferred to the new cluster, and the old cluster was taken down when it was confirmed that the entire rollout was successful. +These steps were thoroughly tested against the UAT cluster with different versions of the addons especially the service meshes and the app versions consequently decided the steps were fool proof before production execution. Production execution went on as planned with few minor hiccups which will require another blog post along the similar lines later.