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
We see lots of situation today where customers choose to do rolling update of their EKS clusters. This is the way to go when you just have 1 version to catch-up, to be able to keep your cluster up to date. The Rolling update mechanism has no rollback possible on the control plane, so it is just a one way go.
There are case where customers may need to upgrade several versions at a time, ou simply want to be able to quickly rollback the operation in case of issue. This is where the Blue/Green cluster approach can be used.
When using EKS and SSP constructs, then there are lots of part that are created from the cluster such as
IAM Roles for service Accounts
Persistent Volumes
Load Balancers and DNS endpoints
While using tools like external-dns or csi drivers, it is easy to create and attach DNS name to a workload defined in the cluster, and to specify volumes to be used.
In the case of a Blue/Green migration, there are thinkgs that we would want to recreate (deployments, roles..) but we will want our new Green cluster, to inherate of the persistent volumes ov previous cluster, and that the DNS created for the cluster A will be migrated to cluster B.
This issue is to see how ssp-amazon-eks pattern can be used to help such migration pattern.
The text was updated successfully, but these errors were encountered:
I am unclear on the strategy related to the persistent volumes. Is the expectation to back them up and restore for the second cluster? Or do you propose to create an identical configuration with respect to the AZs so that the same volumes could be mounted? It will have limited use case with multi-attach.
If the volume was creating byt K8s via PVC, then I don't see how the new cluster could inherit the volume. So Maybe in this a solution with velero backup/restore would be an option ?
At least for stateless workloads this would be easier, but still need to address how to recover from LB/DNS registration to allow migration from cluster A to cluster B smoothly.
We see lots of situation today where customers choose to do rolling update of their EKS clusters. This is the way to go when you just have 1 version to catch-up, to be able to keep your cluster up to date. The Rolling update mechanism has no rollback possible on the control plane, so it is just a one way go.
There are case where customers may need to upgrade several versions at a time, ou simply want to be able to quickly rollback the operation in case of issue. This is where the Blue/Green cluster approach can be used.
When using EKS and SSP constructs, then there are lots of part that are created from the cluster such as
While using tools like external-dns or csi drivers, it is easy to create and attach DNS name to a workload defined in the cluster, and to specify volumes to be used.
In the case of a Blue/Green migration, there are thinkgs that we would want to recreate (deployments, roles..) but we will want our new Green cluster, to inherate of the persistent volumes ov previous cluster, and that the DNS created for the cluster A will be migrated to cluster B.
This issue is to see how ssp-amazon-eks pattern can be used to help such migration pattern.
The text was updated successfully, but these errors were encountered: