github-mirrors/terraform-aws-eks
1
0
Fork 0
mirror of https://github.com/ysoftdevs/terraform-aws-eks.git synced 2026-04-18 06:49:37 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: Update Karpenter example version; add additional clarification on access entry migration to upgrade guide (#2924)

Browse Source
This commit is contained in:
Bryant Biggs
2024-02-12 16:34:23 -05:00
committed by GitHub
parent 659401d9bf
commit d6d97519d4
2 changed files with 14 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/UPGRADE-20.0.md
View File

@@ -221,6 +221,11 @@ Changing the `authentication_mode` is a one-way decision. See [announcement blog
> Switching authentication modes on an existing cluster is a one-way operation. You can switch from CONFIG_MAP to API_AND_CONFIG_MAP. You can then switch from API_AND_CONFIG_MAP to API. You cannot revert these operations in the opposite direction. Meaning you cannot switch back to CONFIG_MAP or API_AND_CONFIG_MAP from API. And you cannot switch back to CONFIG_MAP from API_AND_CONFIG_MAP. > Switching authentication modes on an existing cluster is a one-way operation. You can switch from CONFIG_MAP to API_AND_CONFIG_MAP. You can then switch from API_AND_CONFIG_MAP to API. You cannot revert these operations in the opposite direction. Meaning you cannot switch back to CONFIG_MAP or API_AND_CONFIG_MAP from API. And you cannot switch back to CONFIG_MAP from API_AND_CONFIG_MAP.
> [!IMPORTANT]
> If migrating to cluster access entries and you will NOT have any entries that remain in the `aws-auth` ConfigMap, you do not need to remove the configmap from the statefile. You can simply follow the migration guide and once access entries have been created, you can let Terraform remove/delete the `aws-auth` ConfigMap.
>
> If you WILL have entries that remain in the `aws-auth` ConfigMap, then you will need to remove the ConfigMap resources from the statefile to avoid any disruptions. When you add the new `aws-auth` sub-module and apply the changes, the sub-module will upsert the ConfigMap on the cluster. Provided the necessary entries are defined in that sub-module's definition, it will "re-adopt" the ConfigMap under Terraform's control.
### authentication_mode = "CONFIG_MAP" ### authentication_mode = "CONFIG_MAP"
If using `authentication_mode = "CONFIG_MAP"`, before making any changes, you will first need to remove the configmap from the statefile to avoid any disruptions: If using `authentication_mode = "CONFIG_MAP"`, before making any changes, you will first need to remove the configmap from the statefile to avoid any disruptions:
@@ -232,11 +237,10 @@ terraform state rm 'module.eks.kubernetes_config_map.aws_auth[0]' # include if T
Once the configmap has been removed from the statefile, you can add the new `aws-auth` sub-module and copy the relevant definitions from the EKS module over to the new `aws-auth` sub-module definition (see before after diff above). Once the configmap has been removed from the statefile, you can add the new `aws-auth` sub-module and copy the relevant definitions from the EKS module over to the new `aws-auth` sub-module definition (see before after diff above).
#### ⚠️ Node IAM Roles > [!CAUTION]
> You will need to add entries to the `aws-auth` sub-module for any IAM roles used by nodegroups and/or Fargate profiles - the module no longer handles this in the background on behalf of users.
You will need to add entries for any IAM roles used by nodegroups and/or Fargate profiles - the module no longer handles this in the background on behalf of users. >
> When you apply the changes with the new sub-module, the configmap in the cluster will get updated with the contents provided in the sub-module definition, so please be sure all of the necessary entries are added before applying the changes.
When you apply the changes with the new sub-module, the configmap in the cluster will get updated with the contents provided in the sub-module definition, so please be sure all of the necessary entries are added before applying the changes.
### authentication_mode = "API_AND_CONFIG_MAP" ### authentication_mode = "API_AND_CONFIG_MAP"
@@ -244,6 +248,9 @@ When using `authentication_mode = "API_AND_CONFIG_MAP"` and there are entries th
Once the `authentication_mode` has been updated, next you will need to remove the configmap from the statefile to avoid any disruptions: Once the `authentication_mode` has been updated, next you will need to remove the configmap from the statefile to avoid any disruptions:
> [!NOTE]
> This is only required if there are entries that will remain in the `aws-auth` ConfigMap after migrating. Otherwise, you can skip this step and let Terraform destroy the ConfigMap.
```sh ```sh
terraform state rm 'module.eks.kubernetes_config_map_v1_data.aws_auth[0]' terraform state rm 'module.eks.kubernetes_config_map_v1_data.aws_auth[0]'
terraform state rm 'module.eks.kubernetes_config_map.aws_auth[0]' # include if Terraform created the original configmap terraform state rm 'module.eks.kubernetes_config_map.aws_auth[0]' # include if Terraform created the original configmap

4
examples/karpenter/main.tf
View File

@@ -42,7 +42,7 @@ data "aws_ecrpublic_authorization_token" "token" {
locals { locals {
name = "ex-${replace(basename(path.cwd), "_", "-")}" name = "ex-${replace(basename(path.cwd), "_", "-")}"
cluster_version = "1.28" cluster_version = "1.29"
region = "eu-west-1" region = "eu-west-1"
vpc_cidr = "10.0.0.0/16" vpc_cidr = "10.0.0.0/16"
@@ -169,7 +169,7 @@ resource "helm_release" "karpenter" {
repository_username = data.aws_ecrpublic_authorization_token.token.user_name repository_username = data.aws_ecrpublic_authorization_token.token.user_name
repository_password = data.aws_ecrpublic_authorization_token.token.password repository_password = data.aws_ecrpublic_authorization_token.token.password
chart = "karpenter" chart = "karpenter"
version = "v0.33.1" version = "v0.34.0"
wait = false wait = false
values = [ values = [