English에서 번역 • 원문 보기 AWS re:Invent 2024 기간 동안 AWS는 EKS에 새로운 기능인 EKS 자동 모드를 출시했으며, 이는 이전 블로그에서 자세히 다룬 바 있습니다
이번 블로그에서는 OG "terraform-eks-module"을 사용해 EKS 자동 모드로 클러스터를 만드는 방법과 제 eks.tf 코드를 어떻게 단순화했는지 살펴보겠습니다.
또한 자동 모드 기능 이전에 EK 클러스터에 사용한 테라폼 코드와 자동 모드 기능을 사용한 후 사용된 테라폼 코드의 차이점, 그리고 EKS를 전혀 모르는 초보자에게 어떻게 도움이 되었는지에 대해서도 이야기할 것입니다.
동기
- AWS용 Terraform 제공업체는 EKS 자동 모드에 필요한 자원('compute_config, storage_config, storage_config, kubernetes_network_config.elastic_load_balancing')을 추가하는 새 버전 v5.79.0을 출시했습니다.
- Terraform eks 모듈은 EKS 자동 모드와 EKS 하이브리드 노드 지원을 가능하게 하는 새 버전 v20.31.0을 출시했습니다.
EKS 자동 모드에 Terraform AWS EKS 모듈을 사용해 봅시다
따라 하고 싶으면 이 저장소를 사용해 작동하는 코드를 확인하세요.
새 클러스터에 EKS 자동 모드를 활성화하세요
- EKS 자동 모드로 생성된 하나의 노드 풀(범용 )
- 클러스터 내에 노드나 포드가 없고(워크로드가 실행되지 않음), 또는 지금까지 노드를 프로비저닝하지 않았는데, 그게 이제 EKS 자동 모드의 역할이기 때문이에요라고 말할 수도 있습니다.
- 이 코드를 사용해 샘플을 설치하는 순간, EKS 자동 모드가 Ec2 노드를 스스로 프로비저닝합니다. 제 쪽에서는 노드 프로비저닝에 대해 정말 마법 같은 제로 관리가 있었습니다.
참고: 샘플 앱을 배포하려면 kubectl set context 명령어를 실행하고 terraform apply를 다시 실행해야 합니다. 클러스터를 만들 때 샘플 앱은 배포되지 않은 이유는 컨텍스트가 설정되지 않았기 때문입니다.
AWS EK --Region US-East-1 Update-KubeConfig --Name TF-module-Support --profile CK-Test
테라포름 적용
쿠벡틀 겟 PO
이름 준비 상태 재시작 연령
test-65b7dbddd4-j6mbt 1/1 실행 중 0 104s
test-65b7dbddd4-wdz56 1/1 런닝 0 104s
무엇이 차이를 만들고 있는지
- 'cluster_compute_config' 자원은 모듈 측에서 EKS 자동 모드를 활성화하거나 비활성화하는 데 사용되는 차이 또는 자원 사용량입니다.
- Terraform에서는 AWS 제공자 측에서 EKS 자동 모드를 활성화하거나 비활성화하는 데 사용됩니다
cluster_compute_config = {
enabled = 참
node_pools = ["범용 목적"]
}
- 'cluster_compute_config' 옵션 덕분에 이제 'eks_managed_node_group_defaults', 'eks_managed_node_groups', 'node_security_group_additional_rules'을 언급할 필요도 없고, 그 개념들이 무엇인지도 알 필요가 없습니다.
다음 코드는 작아 보일 수 있지만, EKS와 노드 프로비저닝에 대해 아는 사람이 개념을 이해해야 한다면 이 코드를 어떻게 작성해야 할지 알아낼 수 있습니다. 하지만 이제 EKS 자동 모드 때문에 더 이상 관리가 불가능합니다. 와, 정말 세련되네요.
# 더 이상 필요하지 않은 코드
eks_managed_node_group_defaults = {
ami_type = "AL2_x86_64"
instance_types = ["m5.large"]
# instance_types = ["t3.small"]
# vpc_security_group_ids = [aws_security_group.all_worker_mgmt.id]
iam_role_additional_policies = {
ebs_policy = "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy" #IAM CSI 드라이버에 필요한 권한
auto_scaling_policy = "arn:aws:iam::aws:policy/AutoScalingFullAccess"
cloudwatch_container_insights_agent_policy = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
xray_policy = "arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess"
}
}
eks_managed_node_groups = {
node_group = {
min_size = 2
max_size = 5
desired_size = local.node_group_desired_size
}
}
node_security_group_additional_rules = {
http_traffic_node_to_node = {
description = "자신으로부터 인바운드 HTTP 허용"
from_port = 80
to_port = 80
프로토콜 = "TCP"
self = 참
유형 = "입구"
}
}
# 관리 노드 그룹 원하는 크기를 트리거하기 위해
리소스 "null_resource" "update_desired_size" {
트리거 = {
desired_size = local.node_group_desired_size
}
Provisioner "Local-Exec" {
인터프리터 = ["/bin/bash", "-c"]
command = <-EOT
aws eks update-nodegroup-config \
--cluster-name ${module.eks.cluster_name} \
--nodegroup-name ${element(split(":", module.eks.eks_managed_node_groups["node_group"].node_group_id), 1)} \
--scaling-config desiredSize=${local.node_group_desired_size} \
--region us-east-1 \
--profile ck-test
EOT
}
}
What isn't supported
- 기존 EKS 클러스터에서 EKS를 활성화하고자 하는 경우, 현재 Terraform AWS 제공자 측 버그로 인해 자동 모드가 불가능합니다**.**
DevOps, IaC 관점에서
- 우리는 EKS 자동 모드를 어떻게 활용할 수 있는지 확인했습니다; 이는 새로운 클러스터에서 인프라(컴퓨트)를 계획하거나 프로비저닝할 필요가 없었던 컨테이너 워크로드에 대한 게임 체인저 기능입니다.
- 그럼에도 불구하고 Terraform AWS 제공자 측과 EKS 측에서 기존 클러스터의 자동 모드를 활성화하기 위해 일부 버그 수정이 필요합니다.
- EKS 자동 모드는 사용자의 작업을 줄여줄 뿐만 아니라 IaC(terraform 코드)도 단순화하는 데 성공했습니다.
- terraform, terraform-eks-module의 소비자로서 이 기능이 지원된 속도를 보는 것은 정말 놀라운 일입니다. 이 커뮤니티를 지원해 준 브라이언트 빅스에게 모두 감사드립니다.