github-mirrors/terraform-aws-eks
1
0
Fork 0
mirror of https://github.com/ysoftdevs/terraform-aws-eks.git synced 2026-03-18 23:43:49 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: Correct spelling mistakes (#2334)

Browse Source 
Resolves undefined
This commit is contained in:
Bryant Biggs
2022-12-08 09:35:28 -05:00
committed by GitHub
parent 7124d7603a
commit ca03fd9ec1
9 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
examples/eks_managed_node_group/README.md
View File

@@ -14,7 +14,7 @@ See the [AWS documentation](https://docs.aws.amazon.com/eks/latest/userguide/man
## Container Runtime & User Data
When using the default AMI provided by the EKS Managed Node Group service (i.e. - not specifying a value for `ami_id`), users should be aware of the limitations of configuring the node bootstrap process via user data. Due to not having direct access to the bootrap.sh script invocation and therefore its configuration flags (this is provided by the EKS Managed Node Group service in the node user data), a workaround for ensuring the appropriate configuration settings is shown below. The following example shows how to inject configuration variables ahead of the merged user data provided by the EKS Managed Node Group service as well as how to enable the containerd runtime using this approach. More details can be found [here](https://github.com/awslabs/amazon-eks-ami/issues/844).
When using the default AMI provided by the EKS Managed Node Group service (i.e. - not specifying a value for `ami_id`), users should be aware of the limitations of configuring the node bootstrap process via user data. Due to not having direct access to the bootstrap.sh script invocation and therefore its configuration flags (this is provided by the EKS Managed Node Group service in the node user data), a workaround for ensuring the appropriate configuration settings is shown below. The following example shows how to inject configuration variables ahead of the merged user data provided by the EKS Managed Node Group service as well as how to enable the containerd runtime using this approach. More details can be found [here](https://github.com/awslabs/amazon-eks-ami/issues/844).
```hcl
...

4
examples/eks_managed_node_group/main.tf
View File

@@ -130,7 +130,7 @@ module "eks" {
ami_id = data.aws_ami.eks_default_bottlerocket.image_id
platform = "bottlerocket"
# Use module user data template to boostrap
# Use module user data template to bootstrap
enable_bootstrap_user_data = true
# This will get added to the template
bootstrap_extra_args = <<-EOT
@@ -165,7 +165,7 @@ module "eks" {
# Current default AMI used by managed node groups - pseudo "custom"
ami_id = data.aws_ami.eks_default_arm.image_id
# This will ensure the boostrap user data is used to join the node
# This will ensure the bootstrap user data is used to join the node
# By default, EKS managed node groups will not append bootstrap script;
# this adds it back in using the default template provided by the module
# Note: this assumes the AMI provided is an EKS optimized AMI derivative

6
examples/fargate_profile/main.tf
View File

@@ -152,7 +152,7 @@ resource "null_resource" "remove_default_coredns_deployment" {
}
# We are removing the deployment provided by the EKS service and replacing it through the self-managed CoreDNS Helm addon
# However, we are maintaing the existing kube-dns service and annotating it for Helm to assume control
# However, we are maintaining the existing kube-dns service and annotating it for Helm to assume control
command = <<-EOT
kubectl --namespace kube-system delete deployment coredns --kubeconfig <(echo $KUBECONFIG | base64 --decode)
EOT
@@ -168,7 +168,7 @@ resource "null_resource" "modify_kube_dns" {
KUBECONFIG = base64encode(local.kubeconfig)
}
# We are maintaing the existing kube-dns service and annotating it for Helm to assume control
# We are maintaining the existing kube-dns service and annotating it for Helm to assume control
command = <<-EOT
echo "Setting implicit dependency on ${module.eks.fargate_profiles["kube_system"].fargate_profile_pod_execution_role_arn}"
kubectl --namespace kube-system annotate --overwrite service kube-dns meta.helm.sh/release-name=coredns --kubeconfig <(echo $KUBECONFIG | base64 --decode)
@@ -223,7 +223,7 @@ resource "helm_release" "coredns" {
]
depends_on = [
# Need to ensure the CoreDNS updates are peformed before provisioning
# Need to ensure the CoreDNS updates are performed before provisioning
null_resource.modify_kube_dns
]
}

6
examples/karpenter/main.tf
View File

@@ -292,7 +292,7 @@ resource "null_resource" "remove_default_coredns_deployment" {
}
# We are removing the deployment provided by the EKS service and replacing it through the self-managed CoreDNS Helm addon
# However, we are maintaing the existing kube-dns service and annotating it for Helm to assume control
# However, we are maintaining the existing kube-dns service and annotating it for Helm to assume control
command = <<-EOT
kubectl --namespace kube-system delete deployment coredns --kubeconfig <(echo $KUBECONFIG | base64 --decode)
EOT
@@ -308,7 +308,7 @@ resource "null_resource" "modify_kube_dns" {
KUBECONFIG = base64encode(local.kubeconfig)
}
# We are maintaing the existing kube-dns service and annotating it for Helm to assume control
# We are maintaining the existing kube-dns service and annotating it for Helm to assume control
command = <<-EOT
echo "Setting implicit dependency on ${module.eks.fargate_profiles["kube_system"].fargate_profile_pod_execution_role_arn}"
kubectl --namespace kube-system annotate --overwrite service kube-dns meta.helm.sh/release-name=coredns --kubeconfig <(echo $KUBECONFIG | base64 --decode)
@@ -363,7 +363,7 @@ resource "helm_release" "coredns" {
]
depends_on = [
# Need to ensure the CoreDNS updates are peformed before provisioning
# Need to ensure the CoreDNS updates are performed before provisioning
null_resource.modify_kube_dns
]
}