aws-samples / terraform-eks-code Goto Github PK

Hi everyone! I had to update terraform version to 1.2.4 in order to work again. Could you please update that?

When following this guide: https://catalog.us-east-1.prod.workshops.aws/workshops/afee4679-89af-408b-8108-44f5b1065cc7/en-US/020-prerequisites/k8stools

I've raised an issue for a typo on line 184, but source setup doesn't work when called, which is one part of the issue. But using ./setup at least starts the setup

The output consistently gets stuck at this point below

Install OS tools
Update OS tools
Update pip
Uninstall AWS CLI v1
Install AWS CLI v2
Found preexisting AWS CLI installation: /usr/local/aws-cli/v2/current. Please rerun install script with --update flag.
AWS_REGION is eu-west-1
export ACCOUNT_ID=318781710241
export AWS_REGION=eu-west-1
export AZS=(eu-west-1a eu-west-1b eu-west-1c)
export TF_VAR_region=eu-west-1
eu-west-1
Check Cloud9 AWS Managed temporary credentials are disabled - in AWS Settings
Setup Terraform cache
Setup kubectl
Install kubectl v1.24.12
install eksctl
eksctl completion
helm
add helm repos
"eks" has been added to your repositories
kubectx
ssh key
ssm cli add on
install tfsec ...
pip3
git-remote-codecommit
CHANGED: partition=1 start=4096 old: size=20967391 end=20971487 new: size=67104735 end=67108831
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/nvme0n1p1     32756  6994     25763  22% /
Verify ....
jq in path
aws in path
wget in path
kubectl in path
terraform in path
eksctl in path
helm in path
kubectx in path
Enable bash_completion
PASSED: AWS_REGION is eu-west-1
PASSED: TF_VAR_region is eu-west-1
PASSED: ACCOUNT_ID is xxxxxxxxxxxx
Associate eksworkshop-admin

An error occurred (InvalidParameterValue) when calling the ReplaceIamInstanceProfileAssociation operation: Value (eksworkshop-admin) for parameter iamInstanceProfile.name is invalid. Invalid IAM Instance Profile name
ERROR: Encountered error associating instance profile eksworkshop-admin with Cloud9 environment
For final checks - run ./check

The eksworkshop-admin role has not been created in IAM and there does not appear to be any instance profile associated with the cloud9 instance.

Hello,

This doc (https://aws.amazon.com/blogs/mt/applying-managed-instance-policy-best-practices/) suggests that AmazonEC2RoleforSSM policy should be deprecated in favor of more granular AmazonSSMManagedInstanceCore.

Your declarations add both of them. Is deprecated one still necessary for some reason?

Thanks,
-Anatoli

When I run terraform validate in ~/environment/tfekscode/net, I get several errors like the one below:

│ Error: Reference to undeclared resource
│
│   on aws_subnet__eks-cicd-private1.tf line 5, in resource "aws_subnet" "subnet-00cc72ac5b0b79dd4":
│    5:   availability_zone               = data.aws_availability_zones.az.names[0]
│
│ A data resource "aws_availability_zones" "az" has not been declared in the root module.

I believe the solution could be to include the block of code below in the generated backend-net.tf file:

data "aws_region" "current" {}
data "aws_caller_identity" "current" {}
data "aws_availability_zones" "az" {
  state = "available"
}

Hello,

Thanks for such a wonderful workshop. Learned a lot from it. Sorry if my question is too trivial, but networking is not my forte.

Folder /net defines two groups of three private subnets, marked with p1, p2, and p3, and i1, i2, and i3 suffixes. There are four routing tables declared, named rtb-0102c621469c344cd, rtb-0329e787bbafcb2c4, rtb-041267f0474c24068, and rtb-0939e7f3ae6e7b829.

Then there is a bunch of aws_route_table_association__rtbassoci- files linking them. What I see (in master branch) is three declarations associating rtb-0329e787bbafcb2c4 with i1, i2, and i3 on one end and always p3 on the other. On the other hand, rtb-0102c621469c344cd and rtb-041267f0474c24068are associated with p2 and p1 respectively, but no i anything at all. Quite likely I am grossly misunderstanding the design, but my expectation was that one iN is to be associated with one pN. Could you please clarify?

And rtb-0939e7f3ae6e7b829 has no associations whatsoever. Does this mean that this routing table is not being used?

Thank you very much,
-Anatoli

This file: https://github.com/aws-samples/terraform-eks-code/blob/main/setup

Has a typo on line 184: inst ance_id=$(curl -sS http://169.254.169.254/latest/meta-data/instance-id)

Instance has an unwanted space in it

Hello,

Sorry for another question and probably off-topic question. Workshop documentation states that it only works in eu-west-1, which it does.

I've been trying to create K8s cluster in us-east-1, so I've used pretty much same steps to setup, then create net, iam. etc. However, I got stuck on nodeg step. Using same exact EC2 image name. Nodegroup is created successfully, but nodes do not join the cluster. Instance system log shows yum unable to access its repository. I verified that S3 Gateway is configured with all the subnets. Everything is the same, give or take the region identifier.

Not to burden you with my problems, but perhaps you are familiar with what may be causing it. Below is the relevant part of the log where my case starts deviating from your workshop's instance log.

ip-10-0-1-231 login: [   33.576209] cloud-init[2327]: One of the configured repositories failed (Unknown),
[   33.577812] cloud-init[2327]: and yum doesn't have enough cached data to continue. At this point the only
[   33.579377] cloud-init[2327]: safe thing yum can do is fail. There are a few ways to work "fix" this:
[   33.580930] cloud-init[2327]: 1. Contact the upstream for the repository and get them to fix the problem.
[   33.582206] cloud-init[2327]: 2. Reconfigure the baseurl/etc. for the repository, to point to a working
[   33.582450] cloud-init[2327]: upstream. This is most often useful if you are using a newer
[   33.582611] cloud-init[2327]: distribution release than is supported by the repository (and the
[   33.582772] cloud-init[2327]: packages for the previous distribution release still work).
[   33.582932] cloud-init[2327]: 3. Run the command with the repository temporarily disabled
[   33.583085] cloud-init[2327]: yum --disablerepo=<repoid> ...
[   33.583239] cloud-init[2327]: 4. Disable the repository permanently, so yum won't use it by default. Yum
[   33.583389] cloud-init[2327]: will then just ignore the repository until you permanently enable it
[   33.583548] cloud-init[2327]: again or use --enablerepo for temporary usage:
[   33.583705] cloud-init[2327]: yum-config-manager --disable <repoid>
[   33.583857] cloud-init[2327]: or
[   33.584004] cloud-init[2327]: subscription-manager repos --disable=<repoid>
[   33.584156] cloud-init[2327]: 5. Configure the failing repository to be skipped, if it is unavailable.
[   33.584307] cloud-init[2327]: Note that yum will try to contact the repo. when it runs most commands,
[   33.584463] cloud-init[2327]: so will have to try and fail each time (and thus. yum will be be much
[   33.584616] cloud-init[2327]: slower). If it is a very temporary problem though, this is often a nice
[   33.604566] cloud-init[2327]: compromise:
[   33.605569] cloud-init[2327]: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
[   33.606435] cloud-init[2327]: Cannot find a valid baseurl for repo: amzn2-core/2/x86_64
[   33.606626] cloud-init[2327]: Could not retrieve mirrorlist https://amazonlinux-2-repos-us-east-1.s3.dualstack.us-east-1.amazonaws.com/2/core/latest/x86_64/mirror.list error was
[   33.606781] cloud-init[2327]: 12: Timeout on https://amazonlinux-2-repos-us-east-1.s3.dualstack.us-east-1.amazonaws.com/2/core/latest/x86_64/mirror.list: (28, 'Failed to connect to amazonlinux-2-repos-us-east-1.s3.dualstack.us-east-1.amazonaws.com port 443 after 2702 ms: Connection timed out')
[   33.627903] cloud-init[2327]: Feb 28 22:40:34 cloud-init[2327]: util.py[WARNING]: Package upgrade failed
[   33.669498] cloud-init[2327]: Feb 28 22:40:34 cloud-init[2327]: cc_package_update_upgrade_install.py[WARNING]: 1 failed with exceptions, re-raising the last one
[   33.673120] cloud-init[2327]: Feb 28 22:40:34 cloud-init[2327]: util.py[WARNING]: Running module package-update-upgrade-install (<module 'cloudinit.config.cc_package_update_upgrade_install' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_package_update_upgrade_install.pyc'>) failed
[   34.141318] cloud-init[2485]: Cloud-init v. 19.3-44.amzn2 running 'modules:final' at Mon, 28 Feb 2022 22:40:34 +0000. Up 34.08 seconds.

I spent some time figuring out a weird problem. Why my deployment to cluster A would cause target groups in cluster B to be deregistered.
It turned out I sometimes set Cluster B as the current context from another terminal for other purposes, and the kubectl commands in this example will apply all changes (especially delete CRD) to cluster B (instead of cluster A).
Would be nice to remove this uncertainty from the equation. e.g. make sure to use and only use the cluster that we are working on.

Error: error creating EKS Node Group (mycluster1:ng1-mycluster1): InvalidRequestException: You are not authorized to launch instances with this launch template. Encoded authorization failure message: WFBzX1sxux3dveaW2vmVaummkLXF68KxIwqn-apcQQVI9u4kBHthz3U3L5ARFztIc7wxy3K2YBq6AdKigR2ZtM6z1Yu5K1TgIui-pXzWVbPbbNOg0feQjvipS357eIhAvv8m6L33Qg64JJ2GRwRiRnVXmAY3UOrxHxdfOA4ojesb9hcHsNS9dwbeEQ-345UH-kxwzTDmGycyZbbNlQWfQ0rcQYgiuWsECv4tbbj-Np2zHKMnnbFw2wJsNQicOxWeGK9UBQN08jFabq4gY99DG3QxN2W25IH0tYE4E0rPAyiqGpDaxOcoWJiBWMRWqUJbM5q4sW0J47XyI6nCEmCvmR3KmkeIUDnhJw6ElNmdYBQmW1Wd605GmTCbwyP4vNXVo0UHuU0UVt5PPbJ-N9zfp7tN40mofyN3uhmbN25ipCOFE1V21A2xlAxIceNDNt0-OGTr01vAjbaW9BFRyKU_vl5F3Bvfnl_L9KDJ-pXhiSAouGhS1l3gac_RYl3UqGtIeVGe0qnbiM1sgTWHIYV2hg5Hf7WTzB8pHPAJ8p3vl9UlcCGkuBU5KbUMlUXkZNbRbG8fcTlv-oUcmgSOgmnbgVfV9giUVgSdcrzXOrRBoHvLqlo6bI5EjUsF6whSixdNb9UGK74IXUHkLJ66it4W2_Qvw_WZ7fcfSIU4i4QRiUbIlN-17dDAVZx7yYHwKyUZjE41mjEctRi93qHy9FaB0PHz5HIBdnlwJEhQXr32Ho-bCCcDzeYL3a-oBrQ72dX30LtUyNOPpMxYIOuQRdk9wmPGFQVg9jRWs8L88jwCCuQg6ziFOnKrUinU6oELQk3Nd3nBUddHuETMfgQrQgH8ysg0oas6TO3tnuKdemDdEaOkKNPy0ykcuTiY1tR0lEJnN0TWN5myh0oZnY62HC33txxfRx7sGo8mqaKtFD0jLCocop76trp2CdNmorWJlBzlAALfOaDPR0ksm6PQrnRRLzvcGhCg6M0Jj-QNyjNOYuPjFxfF9-4gIxlkqyxOsYfMbyASKZVPRWWyqrUQ4Cdgzy_024BHn_arVGjEqFrI2yV34XEKMjTg6NESIPj2lACl8XkajSe12Vx0zTVSxbbVXZYnv8P-DmoOKIv4ADO-GKE_1mm5wtqfvCT9XCB30w2XhLC1OphlGbeHhvKlrXLYMu85WidnXbC9HdbauuHboqAvFDmzQNPeg6m6SYfw0yTc3fmzadzYk_qqg0E9_7QC1jXH1raNhSEu7kuMox3OgVk6VwpW5XywAolYVIpwoGKNl_rpdcM
│ {
│ RespMetadata: {
│ StatusCode: 400,
│ RequestID: "ac9755ae-f521-42f1-a764-f2800bd4499f"
│ },
│ Message: "You are not authorized to launch instances with this launch template. Encoded authorization failure message: WFBzX1sxux3dveaW2vmVaummkLXF68KxIwqn-apcQQVI9u4kBHthz3U3L5ARFztIc7wxy3K2YBq6AdKigR2ZtM6z1Yu5K1TgIui-pXzWVbPbbNOg0feQjvipS357eIhAvv8m6L33Qg64JJ2GRwRiRnVXmAY3UOrxHxdfOA4ojesb9hcHsNS9dwbeEQ-345UH-kxwzTDmGycyZbbNlQWfQ0rcQYgiuWsECv4tbbj-Np2zHKMnnbFw2wJsNQicOxWeGK9UBQN08jFabq4gY99DG3QxN2W25IH0tYE4E0rPAyiqGpDaxOcoWJiBWMRWqUJbM5q4sW0J47XyI6nCEmCvmR3KmkeIUDnhJw6ElNmdYBQmW1Wd605GmTCbwyP4vNXVo0UHuU0UVt5PPbJ-N9zfp7tN40mofyN3uhmbN25ipCOFE1V21A2xlAxIceNDNt0-OGTr01vAjbaW9BFRyKU_vl5F3Bvfnl_L9KDJ-_pXhiSAouGhS1l3gac_RYl3UqGtIeVGe0qnbiM1sgTWHIYV2hg5Hf7WTzB8pHPAJ8p3vl9UlcCGkuBU5KbUMlUXkZNbRbG8fcTlv-oUcmgSOgmnbgVfV9giUVgSdcrzXOrRBoHvLqlo6bI5EjUsF6whSixdNb9UGK74IXUHkLJ66it4W2_Qvw_WZ7fcfSIU4i4QRiUbIlN-17dDAVZx7yYHwKyUZjE41mjEctRi93qHy9FaB0PHz5HIBdnlwJEhQXr32Ho-bCCcDzeYL3a-oBrQ72dX30LtUyNOPpMxYIOuQRdk9wmPGFQVg9jRWs8L88jwCCuQg6ziFOnKrUinU6oELQk3Nd3nBUddHuETMfgQrQgH8ysg0oas6TO3tnuKdemDdEaOkKNPy0ykcuTiY1tR0lEJnN0TWN5myh0oZnY62HC33txxfRx7sGo8mqaKtFD0jLCocop76trp2CdNmorWJlBzlAALfOaDPR0ksm6PQrnRRLzvcGhCg6M0Jj-QNyjNOYuPjFxfF9-4gIxlkqyxOsYfMbyASKZVPRWWyqrUQ4Cdgzy_024BHn_arVGjEqFrI2yV34XEKMjTg6NESIPj2lACl8XkajSe12Vx0zTVSxbbVXZYnv8P-DmoOKIv4ADO-GKE_1mm5wtqfvCT9XCB30w2XhLC1OphlGbeHhvKlrXLYMu85WidnXbC9HdbauuHboqAvFDmzQNPeg6m6SYfw0yTc3fmzadzYk_qqg0E9_7QC1jXH1raNhSEu7kuMox3OgVk6VwpW5XywAolYVIpwoGKNl_rpdcM"
│ }
│
│ with aws_eks_node_group.ng1,
│ on aws_eks_node_group_ng1.tf line 3, in resource "aws_eks_node_group" "ng1":
│ 3: resource "aws_eks_node_group" "ng1" {