[Terraform T101 4기 스터디] - 테라폼으로 AWS EKS 배포

★★cloudNet@ 팀의 가시다 님이 진행하는 Terraform 101 Study 4기 내용과 한빛미디어 테라폼으로 시작하는 IaC 책을 참고하여 정리하였습니다.

 Amazon EKS Blueprints for Terrform

참고 : https://aws-ia.github.io/terraform-aws-eks-blueprints/

Amazon EKS Blueprints for Terraform

▶ Amazon EKS Blueprints for Terrform 소개
EKS Blueprints for Terraform has been desined to be consumed in the following manners :
1. 참고 Reference : Users can refer to the patterns and snippets provided to help guide them to their desired solution.
Users will typically view how the pattern or snippet is configured to achieve the desired end result and then replicate that in their envireonment.
2. 복붙 Copy & Paste : Users can copy and paste the patterns and snippets into their own environment, using EKS Blueprints as the starting poiint for their implementation. Users can then adapt the initial pattern to customize it to their specific needs.

 

[ 고려사항 ]

• EKS Bueprints for Terraform are not intended to be consmed as-s directly from this project.
  > 그대로 사용은 의도된 것이 아님
• In "Terraform speak" - the patterns and snippets provdd in this repository are not desined to be consumed as a Terraform module.
  > 패턴과 스니펫은 Terraform 모듈로 사용하도록 설계되지 않음
• Therefore, the patterns providd only contain variables when certain information is reqired to deploy the pattern (i.e. - a Route53 hosted zne ID, or ACM certificate ARN) and generally use local variables. If you wish to deploy the patterns into a diferent region or with other changes, it is recommended that you make those modifications locally before applying the pattern.
  > 일반적으로 Loal 블록을 통해 변경하고, 특정 정보가 필요한 경우 (Route53 호스트영역 ID 등)만 variales 블록을 사용
• EKS Blueprints for Terraform will not expose variables and outputs in the same manner that Terraform modules foolow in order to avoi confusion around the consumption model.
  > 복잡성을 줄이기 위해 variables과 outputs을 최대한 노출하지 않음
• Howeer, we do hae a number of Terraform modules that were created to support EKS Blueprints in addition to the community hosted modules. Please see the respective projects for more details n the modules constructed to support EKS Blueprints for Terraform; those projects are listed
  > EKS Blueprints 지원을 위해 제작한 모듈은 아래와 같음
• terraform-aws-eks-blueprint-addon (단수)
  - Terraform odule which can provision an addon using the Terraform helm_release resource in adition to an IAM role for service account (IRSA).
  - 서비스 계정(IRSA)에 대한 IAM역할 외에도 Terraform 리소스를 사용하여 애드온을 프로비저닝할 수 있는 Terform 모듈입니다.
• terraform-aws-eks-blueprint-adons (복수)
  - Terraform module which can provision multiple addons; both EKS addons using the aws_eks_addon resource as well as Helm chart based addons using the terraform-aws-eks-blueprint-addon module.
  - 여러 애드온을 프로비저닝할 수 있는 Terraform 모듈입니다. - 'aws_eks_addon 기반 애드온' + 'terraform-aws-eks-blueprint-addon 모듈 사용 헬름 차트 기반 애드온'
• terraform-aws-eks-blueprints-teams
  - Terraform module that creates Kubernetes multi-tenancy resources and configurations, allowing both administrators and application devlopers to access only the resources which they are responsible for.
  - 관리자와 애플리케이션 개발자 모두 자신이 담당하는 리소스에만 액세스할 수 있도록 Kubernetes 멀티테넌시 리소스 및 구성을 생성하는 Terraform 모듈.

[ 기타 프로젝트 ]
1. GitOps

• terraform-aws-eks-ack-addons -  Terraform module to deploy ACK controllers onto EKS clusters
• crossplane-on-eks - Crossplane Blueprints is an open source repo to bootstrap Amazon EKS clusters and provision AWS resources using a library of Crossplane Compositions (XRs) with Composite Resource Definitions (XRDs).

2. Data on EKS

• data-on-eks - A collection of blueprints intended for data worloads on Amazon EKS.
• terraform-aws-eks-data-addons - Terraform module to deploy multiple addons that are specific to data workloads on EKS clusters.

3. Observability Accelerator

• terraform-aws-observability-accelerator - A set of opinionated modules to help you set up observability for your AWS environments with AWS-managed observability services such as Amazon Managed Service for Prometheus, Amazon Managed Grafana, AWS Distro for OpenTelemery (ADOT) and Amazon CloudWatch

4. Karpenter Blueprints

5. karpenter-blueprints - includes a list of common workload scenarios, some of them go in depth with the explanation of why configuring Karpenter and Kubernetes objects in such a way is important.

 

[주의사항Terraform Caveats]

• EKS Blueprints for Terraform does not intend to teach users the recommended practices for Terraform nor does it offer guidance on how users should structure their Terraform projects. 
  > 권장 사례나 테라폼 구성 지침을 제공하지 않습니다.
• The patterns provided are intended to show users how they can achieve a defined architecture or configuration in a way that they can quickly and easily get up and running to start interacting with that pattern. Therefore, there are a few caveats users should be aware of when using EKS Blueprints for Terraform
  > 최대한 빠르고 쉽게 목표 패턴 실행에 목적

1. We recognize that most users will already have an existing VPC in a separate Terraform workspace. However, the Patterns provided come complete with a VPC to ensure a stable, deployable example that has been tested and validated.
> 사용자가 기존 VPC가 있지만, 제공되는 패턴에서 안정적인 배포 보장을 위해 신규 VPC를 배포

2. Hashicorp does not recommend providing computed values in provider blocks, which means that the cluster configuration should be defined in a workspace separate from the resources deployed onto the cluster
> 분리 권고
- However, to simplify the pattern experience, we have defined everyting in one workspace and provided instructions to provision the patterns using a targeted apply approach. Users are encouraged to investigate a Terraform project structure that suites their needs; EKS Blueprints for Terraform does not have an opinion in this matter and will defer to Hashicorp's guidance.
> 단순화 하여 모든 것을 하나의 작업 공간에서 정의하고 배포함

3. Patterns are not intended to be consumed in-place in the same manner that one would consume a module. Therefore, we do not provide variables and outputs to expose various levels of configuration for the examples. Users can modify the pattern locally after cloning to suite their requirements.
> Local 블록 수정

4. Please see the FAQ section on authenticating Kubernetes based providers (kubernetes, helm, kubectl) to Amazon EKS clusters regarding the use of static tokens versus dynamic tokens using the awscli.

 

▶ [실습] Karpenter on EKS Fargate

This pattern demonstrate s how to provision Karpenter on a serverless cluster (serverless data plane) using Fargate Profiles.

 

1. Kapenter(카펜터)란?????? - AWS가 개발한 Kubernetes의 Worker Node 자동 확장 기능을 수행하는 오픈소스 프로젝트 2. Kapenter의 장점 - 운영 부담 절감 - 신속한 Node 추가와 제거 - 자동 Node 롤링 - 빠른 버전 업그레이드에 따른 기대 - 다양한 인스턴스 타입을 쉽게 적용

사전 준비 : awscli(IAM 관리자 수전 자격증명), terraform, kubectl, helm

aws --version
terraform --version
kubectl version --client=true
helm -h

버전 정보 확인

코드 준비

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints
cd terraform-aws-eks-blueprints/patterns/karpenter
tree

versions.tf

* terraform init 먼저 진행

terraform init
tree .terraform
cat .terraform/modules/modules.json | jq
tree .terraform/providers/registry.terraform.io/hashicorp -L 2

 

* terraform init 완료 후 VPC 배포

# VPC 정보 확인
aws ec2 describe-vpcs --filter 'Name=isDefault,Values=false' --output yaml

# vpc 배포 : 3분 소요
terraform apply -target="module.vpc" -auto-approve

# 배포 확인
terraform state list

.terraform 폴더 하위 확인

> providers 부분에 내가 선언한 aws, kubernetes 확인 가능

 

▶ main.tf <- local 블록 수정

main.tf 수정부분

main.tf 수정 후 terraform apply

* main.tf 코드 분석

- provider aws가 두개 존재
: public ECR은 us-east-1으로 설정되며 alias 존재(공개된 저장소 사용시에만)

- helm  provider 배포하려면 aws 자격증명 필요

- slice(list, startindex, endindex)
: startindex는 포함되고 endindex는 제외

> slice(["a", "b", "c", "d"], 1, 3)
[
  "b",
  "c",
]

* VPC 배포 진행 후 EKS 배포 (각각 시간 소요)

 

* EKS Cluster(main.tf)

: eks node 들은 프라이빗에서 동작하도록 설정(fargate는 프라이빗에서만 동작)

: fargate가 워커노드를 aws에서 관리

 

* EKS Addons

: coredns가 Fargate로 올라감

: resource 블록 - 자격증명 관련

 

vpc 생성 확인

aws 웹 콘솔에서 생성한 vpc 확인

서브넷 확인

# EKS 자격증명

: ~/.kube/config 안에 eks 자격증명 관련 셋팅 업데이트

aws eks --region ap-northeast-2 update-kubeconfig --name t101-karpenter

자격증명 확인

상세정보 확인

eks 생성 확인

 

# 노드 정보 확인

kubectl get nodes -L node.kubernetes.io/instance-type -L topology.kubernetes.io/zone

 

▶ karpenter 소개 : 노드 수명 주기 관리 솔루션, 몇 초 만에 컴퓨팅 리소스 제공

 

▶ karpenter 실습 - karpenter.yaml 수정 필요  (tag 부분)

karpenter.yaml 수정

 

* EKS 배포 후 node 및 pod 확인 시 error 발생
1번째 시도 - VPC 배포 > EKS 배포하면서 addon 배포 > 리소스 없음 및 Could not login to OCI registry "public.ecr.aws": login attempt to https://public.ecr.aws/v2/ failed with status: 403 Forbidden 에러 확인

2번째 시도 - 새로운 계정으로 VPC 배포 > EKS 배포 > pod 확인 시 pending > addon 배포 > Could not login to OCI registry "public.ecr.aws": login attempt to https://public.ecr.aws/v2/ failed with status: 403 Forbidden 에러 확인

3번째 시도 - 기존에 사용하던 계정으로 VPC 배포 > EKS 배포 > pod 확인 시 pending > addon 배포 > pod 정상동작확인(?????)

- 에러 원인 : AWS VPC CNI addon 설치가 안되어 네트워크 환경 제공이 안되서 파드가 pending 상태로 확인 - 해결 방법 : 실습 과정중 EKS 배포 후 addon 배포 후 pod 확인 시 정상적으로 올라오는 부분 확인

 

* 노트, 파드 정보 확

 

 

* helm chart 확인

 

▶ kube-ops-view 설치 : 노드의 파드 상태 정보를 웹 페이지에서 실시간으로 출력

 

웹 페이지를 통하여 파드 상태 정보 실시간 출력

 

▶ karpenter 실습

karpenter tag 부분 수정

pending 상태인 노드

deploy 삭제 후 노드 변화 확인

* 실습 완료 후 리소스 삭제

# kube-ops-view 삭제
helm uninstall kube-ops-view -n kube-system

# addon & karpenter helm 삭제 : 1분 소요
terraform destroy -target="module.eks_blueprints_addons" -auto-approve

# EKS 삭제 : 8분 소요
terraform destroy -target="module.eks" -auto-approve

# VPC 삭제 : vpc 삭제가 잘 안될 경우 aws 콘솔에서 vpc 수동 삭제 -> vnic 등 남아 있을 경우 해당 vnic 강제 삭제 
terraform destroy -auto-approve

# VPC 삭제 확인
aws ec2 describe-vpcs --filter 'Name=isDefault,Values=false' --output yaml

# kubeconfig 삭제
rm -rf ~/.kube/config

 

 

EKS Workshop

EKS Workshop 소개 : 다양한 주제 기술의 실습 랩 가이드 제공 - Link / Github - Link / Youtube - Link

• EKS 배포 툴 : eksctl - Link , terraform - Link ← 테라폼 배포는 현재 preview 단계 , CDK ← 곧 추가 예정

eks-workshop 각 tf 파일 확인

providers.tf

variables.tf

terraform apply 시 error 발생

: VPC 5개를 사용중이었어서 삭제 후 다시 terraform apply

 

생성된 EKS-VPC 확인

EKS 자격증명

클러스터 정보 확인

: access entry 생성 해야 정상적으로 클러스터 정보 확인 가능

 

# 각자 자신의 IAM User 의 access entry 생성

ACCOUNT ID, MYIAMUSER 값 확인

에러 발생 : An error occurred (InvalidParameterException) when calling the CreateAccessEntry operation : The specified prinsipalArn is invalid : invalid principal.

해결방법 : root IAM 사용자가 없어서 발생하는 에러, IAM 사용자 생성 후 정상 동작 확인

IAM 액세스 항목 확인

aws eks 상세정보 확인

 

 

EKS Blueprints for  Terraform and Argo CD [ 다시 해보기 ]

1. 워크샵 저장소 포크
: https://github.com/aws-samples/eks-blueprints-for-terraform-workshop 으로 이동
: 저장소 이름을 eks-blueprints-for-terraform-workshop으로 유지

 

2. GitHub 액세스 토큰 생성

1) Settings - 개발자 설정 - Personal access tokens - Fine-grained tokens 

2) Repository access, contents 설정

3. AWS CloudFormaion 배포 ( 템플릿 다운로드 후 CloiudFormation으로 이동하여 워크숍에 대한 스택 생성)

1) 기존 템플릿 선택 - 템플릿 파일 업로드

2) 스택 세부 정보 지정

cloudformation 스택

생성된 cloud 9 인스턴스 확인

4. 모듈 독립형 GitOps 클러스터

: 이 모듈에서는 Terraform을 사용하여 단일 EKS 클러스터를 생성하고 Argo CD를 사용하여 애드온 및 워크로드 구성

5. Amazon VPC 생성

1) Terraform 프로젝트 생성

2) Terraform 및 공급자 버전 정의

3) 변수 정의

4) VPC 구성
: 인터넷 게이트웨이, NAT게이트웨이, 기본 네트워크 리소스와 같은 필수 네트워킹 구성 요소와 함께 3개의 가용성 영역에 걸쳐 있는 퍼블릭 및 프라이빗 서브넷을 갖춘 VPC의 기본 인프라 설정

: vpc 태그 지정 (kubernetes 로드 밸런서 컨트롤러에서 동적으로 검색하기 위해)

 

5) 출력 생성 - EKS 클러스터를 생성할 때는 VPC와 개인 서브넷 사용

생성된 VPC 확인

6. EKS 클러스터 생성

: 프로비저닝된 VPC내에 EKS클러스터를 생성하고 EKS Terraform 모듈을 활용하여 배포 프로세스를 간소화

1) 원격 상태 생성

2) 변수 생성

3) EKS 클러스터 구성
: EKS 모듈을 사용하여 프라이빗 서브넷에 구성
: 각 가용성 영역에 하나씩, 3개의 EC2 인스턴스가 있는 관리형 노드 그룹을 프로비저닝하여 고가용성 보장
: EKS addon 설치
> VPC-CNI(VPC 프라이빗 서브넷에서 파드에 IP 주소 제공), kube-proxy(서비스에서 파드로의 내부 트래픽 라우팅), CoreDNS(내부 서비스 이름 확인)

4) 출력 정의
: EKS 클러스터에 액세스하는 명령과 워크숍에서 나중에 사용될 추가 세부 정보 포
5) 변수 값 정의

error 확인 필요

 

6) Terraform 변수 파일을 클러스터 연결

 

7) EKS 클러스터 생성

cd ~/environment/hub
terraform init
terraform apply -auto-approve