@ivorscott thanks for the PR! At this point, I think it's wise to pin the version of kubectl, but I think we should pin to the same version of eks we deploy. Thoughts? Currently this is 1.21 which, coincidentally, seems to be the latest static version present in CDK (as of version 2.25). I see they now have a static method of which lets one specify a "custom" version of EKS, maybe that's the path we should go down. I haven't tested that, so not sure if we could introduce "1.23" there without issues. If that's possible, I would suggest going down that route and lifting the desired EKS version for the workshop so that it's fed to both the script you changed, as well as the EKS Stack file as a constant.
I'll test to see if we can truly deploy a 1.23 version with CDK 2.25.
@ivorscott thanks for the PR! At this point, I think it's wise to pin the version of kubectl, but I think we should pin to the same version of eks we deploy. Thoughts? Currently this is 1.21 which, coincidentally, seems to be the latest static version present in CDK (as of version 2.25). I see they now have a static method
ofwhich lets one specify a "custom" version of EKS, maybe that's the path we should go down. I haven't tested that, so not sure if we could introduce "1.23" there without issues. If that's possible, I would suggest going down that route and lifting the desired EKS version for the workshop so that it's fed to both the script you changed, as well as the EKS Stack file as a constant.I'll test to see if we can truly deploy a 1.23 version with CDK 2.25.
Originally posted by @tobuck-aws in https://github.com/aws-samples/aws-saas-factory-eks-saas-workshop/issues/13#issuecomment-1138764323