2. 테라폼을 이용한 EKS 설치 및 로컬 관리 환경 구축
1. 코드를 이용한 쿠버네티스 설치의 장점
이 글을 읽으시는 독자가 쿠버네티스 담당자가 되어 EKS 설치 업무를 진행한다고 생각해 보겠습니다. EKS를 어떻게 설치하는 것이 좋을까요? 지금까지 어떻게 진행하였는지 생각해보고 앞으로 어떻게 하는 것이 좋은 방법인가 생각해 봅니다.
EKS 설치는 아마존 콘솔에서 GUI(Graph User Interface)를 이용하거나 eksctl 명령어로 가능합니다. 그러면 비교적 편리하게 설치할 수 있습니다. 하지만 다음 설치할 때도 매번 동일한 과정을 거쳐야 하므로 재사용성 측면에서 불편합니다. 무엇보다 실수할 가능성이 높습니다. 같은 EKS를 개발 환경, 운영 환경 혹은 다른 서비스 용도로도 만들어야 되는데, 그 때마다 일련의 GUI 메뉴 선택, 명령어 작업을 반복해야 합니다. 처음에 10분이 소요되었다면 다음번에도 동일하게 10분의 시간이 소요됩니다. 또한 작업에 필요한 모든 명령어를 사전에 검토할 수 없어 동료와 리뷰하는 것이 어렵습니다. 앞서 설명하였듯이 코드로 쿠버네티스를 관리하면 장점이 있듯이 EKS 즉, 인프라도 코드로 관리하면 많은 장점이 있습니다.
많은 분들이 이미 알고 계시겠지만 요즈음은 테라폼 등의 도구를 활용하여 인프라를 코드로 관리 – IaC(Infra as Code)하고 있습니다. 특히 테라폼을 퍼블릭 클라우드 환경에서 많이 사용합니다. 테라폼은 인프라스트럭처 자동화 도구로, 코드를 사용하여 클라우드 및 온프레미스 환경에서 인프라를 프로비저닝하고 관리합니다. 테라폼을 사용하면 인프라를 코드로 정의하여 관리할 수 있습니다. 이를 통해 반복적인 작업을 자동화하고, 변경 사항을 추적하며, 인프라 환경을 일관성 있게 유지할 수 있습니다. 테라폼은 선언적인 언어를 사용하여 리소스를 정의하며, 이를 통해 원하는 상태로 인프라를 구성할 수 있습니다.
EKS 설치 역시 테라폼을 이용할 수 있습니다. EKS를 테라폼을 사용하여 설치하면 다음의 이점이 있습니다.
1.코드를 사용한 인프라 관리
코드를 이용하므로 사전에 코드를 리뷰하여 문제점을 발견하는 등 협업에 매우 유리합니다. 깃헙 등으로 버전 관리하여 변경 사항을 쉽게 추적할 수 있습니다.
2.재사용성과 유지보수 용이
현업에서 개발, 스테이지, 운영 등 복수의 클러스터를 이용하고 있습니다. 같은 클러스터를 다시 만들 때 기존 코드를 그대로 사용할 수 있어 생산성이 향상됩니다.
테라폼을 사용하여 EKS를 만드는 방법도 다양합니다. 테라폼은 EKS 모듈을 지원하여 EKS와 관련된 VPC, Security Group, Subnet 등 다양한 관련 리소스를 코드를 중복 사용하지 않고 한번에 편리하게 설치할 수 있습니다. 테라폼 모듈은 특정 기능이나 리소스를 추상화하고 캡슐화하여, 복잡한 인프라 구성을 단순화하고 모듈화할 수 있게 해줍니다. 이를 통해 코드의 재사용성과 유지보수성을 향상시킬 수 있습니다.
테라폼 모듈을 사용하면 일반적인 시나리오나 패턴을 캡슐화하여, 다양한 프로젝트나 환경에서 동일한 구성을 쉽게 반복할 수 있습니다. 필자도 테라폼 모듈을 사용하여 EKS를 손쉽게 설치하고 있습니다.
2. 테라폼을 이용한 EKS 설치
그럼 실제 현업 환경에서 사용하고 있는 테라폼 EKS 설치 코드를 살펴보겠습니다. 해당 코드는 필자의 깃헙 코드에서 확인할 수 있습니다. EKS를 잘 모르는 상태에서 EKS 테라폼 코드를 보면 많은 것이 생소하여 이해가 되지 않습니다. 처음은 용어 정도만 익힌다고 생각하고 넘어가도 괜찮습니다. 차차 실제 사용하다 보면 처음에 어려웠던 여러 개념을 이해할 수 있습니다. 강조하지만 초반에 너무 완벽하게 배우려면 시간이 너무 많이 걸립니다. 필자는 처음에는 전체를 실습으로 완료하고 어렵거나 각자 필요한 부분은 다시 반복하는 것이 좀 더 효과적이라 생각합니다.
필자의 코드를 ‘git clone’을 이용하여 로컬에 내려받습니다.
Lvi-Jerry-LX2Y49939H:k8s jerry$ git clone https://github.com/junghoon2/k8s-class.git Cloning into 'k8s-class'... remote: Enumerating objects: 5021, done. remote: Counting objects: 100% (66/66), done. remote: Compressing objects: 100% (8/8), done. remote: Total 5021 (delta 60), reused 58 (delta 58), pack-reused 4955 Receiving objects: 100% (5021/5021), 4.78 MiB | 12.89 MiB/s, done. Resolving deltas: 100% (2232/2232), done.
아래 ‘terraform-eks’ 디렉토리를 확인하면 EKS 설치에 관련된 테라폼 코드를 확인할 수 있습니다.
Lvi-Jerry-LX2Y49939H:k8s jerry$ cd k8s-class/terraform-eks/ Lvi-Jerry-LX2Y49939H:terraform-eks jerry$ ls eks-addon.tf eks-cluster.tf irsa-role.tf karpenter.tf main.tf outputs.tf vpc.tf
먼저 locals 변수 관련된 설정입니다. locals 변수는 Terraform에서 locals 블록을 사용하여 지역 변수(local variables)를 정의합니다. locals 블록을 사용하여 변수를 정의하면, 이 변수는 해당 모듈 또는 설정 파일 내에서만 사용 가능하며 외부에서는 사용할 수 없습니다. 주로 중복되는 값이나 복잡한 표현식을 변수로 저장하여 코드를 더 관리하기 쉽게 만드는 데 사용됩니다.
임의로 locals 변수 파일을 저장할 수 있으나 필자는 main.tf 파일에 locals 블록을 등록하였습니다.
locals {
name = "singapore-test"
cluster_version = "1.26"
region = "ap-southeast-1"
vpc_cidr = "10.110.0.0/16"
azs = slice(data.aws_availability_zones.available.names, 0, 3)
tags = {
env = "dev"
user = "jerry"
}
}
. name
EKS 이름입니다. 한번 만들면 수정할 수 없기에 처음에 클러스터의 이름을 신중하게 결정합니다. 회사에 이미 정해진 Naming Convention(이름 작성 규칙)이 있으면 따르고 만약 없다면 명확한 의미 전달, 향후 확장성을 고려하여 일관되게 적용할 수 있는 규칙을 정합니다. 규칙없이 test-01 등으로 지으면 매우 곤란합니다. 스스로 설명 가능한(Self Explaining) 이름을 정의합니다. 필자의 회사들은 주로 {Product Name} – {Region} – {Env(test/stage/prod)}을 사용하였습니다. 어렵지 않게 정할 수 있으므로 꼭 미리 정하는 것을 권고합니다.
. region
일반적으로 ap-northeast-2, Seoul을 사용하는데, 해당 리전에 다른 eks가 설치되어 있어 필자는 구분을 위하여 ap-southeast-1, Singapore 리전을 선택하였습니다. 물론 같은 리전도 VPC로 구분할 수 있는데, 편의를 위하여 아예 리전까지 분리하였습니다. 필자와 같은 특별한 이유가 없다면 ap-northeast-2를 선택합니다.
. vpc_cidr
중요한 설정입니다. CIDR(Classless Inter-Domain Routing)은 IP 주소 공간을 효율적으로 관리하고 나누기 위해 사용되는 네트워크 주소체계입니다. 기존의 클래스 기반 주소 체계(Classful Network)를 보완하고 발전시킨 개념으로, 더 유연한 IP 주소 할당이 가능합니다. 기존에 사용중인 다른 VPC의 IP 대역과 겹치지 않는 유일한 IP 대역을 선택합니다. 혹시 온프레미스와 AWS 클라우드를 같이 사용하면 온프레미스 IP 대역과도 다른 것을 사용하는 것이 향후 Peering 구성 시 용이합니다.
IP 대역 역시 명확한 규칙이 있는게 좋습니다. 예를 들어 Prod 환경은 10.1.0.0/16, 10.2.0.0/16, Stage는 10.11.0.0/16, 10.12.0.0/16으로 나누고 리전별로 Seoul 10.0.0.0/16 ~ 10.50.0.0/16 Tokyo 10.51.0.0/16 ~ 10.100.0.0/16 등으로 나눌 수 있습니다. (혹은 172.16.0.0/16, 192.168.0.0/16 등으로) 처음에 규칙을 정하지 않아 서로 다른 VPC에 같은 대역을 사용하는 경우도 많이 있습니다.
. azs
가용성을 고려하여 3개의 az(Availability Zone)로 나누어서 할당합니다. 혹은 테스트 클러스터는 비용 절감을 위하여 하나의 AZ를 사용할 수 있습니다. 실제 운영 환경에서는 클러스터 내 각 노드 간 트래픽이 많이 발생하여 Data Transfer 비용이 생각보다 많이 발생합니다.
다음은 EKS 모듈 설정입니다.
module "eks" {
cluster_endpoint_public_access = true
cluster_addons = {
coredns = {
preserve = true
most_recent = true
timeouts = {
create = "25m"
delete = "10m"
}
}
kube-proxy = {
most_recent = true
}
vpc-cni = {
most_recent = true
}
}
vpc_id = module.vpc.vpc_id
subnet_ids = module.vpc.private_subnets
control_plane_subnet_ids = module.vpc.intra_subnets
# Extend cluster security group rules
cluster_security_group_additional_rules = {
ingress_nodes_ephemeral_ports_tcp = {
description = "Nodes on ephemeral ports"
protocol = "tcp"
from_port = 1025
to_port = 65535
type = "ingress"
source_node_security_group = true
}
}
# Extend node-to-node security group rules
node_security_group_additional_rules = {
ingress_self_all = {
description = "Node to node all ports/protocols"
protocol = "-1"
from_port = 0
to_port = 0
type = "ingress"
self = true
}
}
}
. cluster_endpoint_public_access
Test 클러스터 환경이라 EKS API 서비스의 외부 접근(public access)를 허용하였습니다. 하지만 실제 운영 환경에서는 보안 상 외부 접속을 막는 것을 권고합니다.
endpoint_private_access = "true" endpoint_public_access = "false"
위와 같이 설정하면 EKS와 같은 VPC 내부에서만 접속할 수 있습니다. EKS API 서버를 통하여 쿠버네티스의 모든 작업, 예를들어 파드와 노드 삭제 혹은 클러스터 전체 삭제까지 진행할 수 있으므로 조심해야 합니다. 필자는 VPN을 사용하여 내부 IP 대역으로 접속합니다. 만약 VPN를 사용하지 않으면 API에 접속할 수 있는 Public IP 대역을 제한하는 방법도 가능합니다.
. cluster_addons
EKS Addon은 Amazon EKS 클러스터에서 특정 기능이나 서비스를 쉽게 활성화하고 관리하기 위한 기능을 제공하는 확장 기능입니다. 네트워킹, DNS 등 EKS 구성에 필수적인 요소를 관리하기 용이합니다. Coredns, Kube-proxy, Vpc-cni 등을 미리 add-on으로 관리하면 향후 EKS 업그레이드 작업 시 신규 버전 정보만 명시하여 편리하게 업그레이드 할 수 있습니다.
. vpc_id
EKS 용도로 기존 VPC와 구분하여 전용 VPC를 사용하는 것을 권고합니다. 쿠버네티스 네트워크를 관리하는 CNI(Container Network Interface)로 EKS는 기본으로 VPC_CNI를 사용합니다. VPC_CNI는 파드와 노드의 IP 대역을 동일하게 사용하여 IP가 많이 필요합니다. 파드의 숫자가 1,000개 넘기는 것도 흔히 발생하여 IP가 부족할 수 있으므로 별도의 VPC를 사용하는 것을 권고합니다.
. subnet_ids
EKS 파드가 할당되는 Subnet 대역을 지정합니다. 외부와 파드의 공인 IP로 통신해야 하는 특별한 환경이 아니라면 보안 상 Subnet 대역은 Private IP 대역을 지정합니다.
. control_plane_subnet_ids
Control Plane의 파드가 할당되는 subnet 대역입니다. 컨트롤 플레인은 쿠버네티스 클러스터의 핵심 컴포넌트로, 클러스터 내의 모든 작업을 관리하고 제어하는 역할을 수행하는 시스템입니다. 자세한 설명으로 앞으로 실습과 함께 제공할 예정이며 지금은 일단 용어 정도만 알아도 충분합니다. 컨트롤 플레인의 네트워크 대역을 Public, Private이 아닌 좀 더 안전한 Intra 대역으로 지정합니다. 컨트롤 플레인은 인터넷 게이트웨이나 NAT 게이트웨이를 통한 외부 접근이 없으며, VPC 내부에서만 사용되는 리소스입니다.
다음은 nodegroup 설정입니다. 쿠버네티스는 실제 컨테이너 애플리케이션을 실행하는 VM 인스턴스가 필요합니다. EKS는 이를 노드그룹을 사용하여 효율적으로 그룹으로 관리하고 확장할 수 있습니다. 최근에는 기존의 노드 그룹을 사용하지 않고 카펜터를 이용하여 EKS의 EC2 노드를 많이 관리합니다. 카펜터는 노드와 파드의 리소스 사이즈를 관리하여 클러스터 내 리소스의 효율성을 최적화합니다. 이는 리소스 사이즈 조정을 자동화하여 클러스터 성능과 가용성을 향상시키는 데 많은 도움이 됩니다. 자세한 설명은 ‘8장. 노드 오토스케일링 – Karpenter’ 에서 다룹니다.
카펜터가 실행하는 노드는 카펜터 자신이 지정할 수 없어 카펜터가 실행하는 노드 그룹을 아래와 같이 정의합니다. (eks-cluster.tf)
eks_managed_node_group_defaults = {
ami_type = "AL2_x86_64"
attach_cluster_primary_security_group = true
iam_role_additional_policies = {
additional = aws_iam_policy.additional.arn
}
ebs_optimized = true
block_device_mappings = {
xvda = {
device_name = "/dev/xvda"
ebs = {
volume_size = 100
volume_type = "gp3"
iops = 3000
throughput = 150
# encrypted = true
# kms_key_id = aws_kms_key.ebs.arn
delete_on_termination = true
}
}
}
tags = local.tags
}
eks_managed_node_groups = {
base = {
name = "karpenter"
use_name_prefix = false
instance_types = ["t3.small"]
capacity_type = "SPOT"
min_size = 1
max_size = 5
desired_size = 1
subnet_ids = module.vpc.private_subnets
}
}
. eks_managed_node_group_defaults
노드 그룹의 기본 설정을 지정합니다. security group, iam_role 설정은 테라폼 기본 설정을 따랐습니다. 반면 디스크 용량 설정은 기본 설정에서 장애를 대비하여 넉넉하게 gp3 기반의 100Gi로 변경하였습니다.
. eks_managed_node_groups.capacity_type, instance_types
필자의 경우 운영 환경은 On-demand 인스턴스 타입으로 지정하고 Dev/Stage 환경은 Spot Instance를 사용하여 비용을 많이 줄였습니다. (on-demand에 비하여 대략 30% 가격) 테스트 EKS라 Spot Instance로 지정하였습니다.
참고로 Spot 환경에서 ‘instance_types’을 여러 개, 복수로 지정하면 Spot으로 지정할 리소스가 부족한 상황을 대비할 수 있습니다. 상황에 따라 [“t3.small’, “t3.large”, “m6i.large”] 등 복수로 지정할 수 있습니다.
마지막으로 vpc 설정입니다.(vpc.tf)
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~>3.12"
name = local.name
cidr = local.vpc_cidr
azs = local.azs
private_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 4, k)]
public_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 48)]
intra_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 52)]
enable_nat_gateway = true
enable_dns_hostnames = true
enable_flow_log = true
create_flow_log_cloudwatch_iam_role = true
create_flow_log_cloudwatch_log_group = true
public_subnet_tags = {
"kubernetes.io/role/elb" = 1
}
private_subnet_tags = {
"kubernetes.io/role/internal-elb" = 1
}
tags = local.tags
}
. module “vpc”.source
테라폼은 eks와 마찬가지로 별도의 vpc 모듈을 제공합니다.
. private_subnets, [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 4, k)]
이전 vpc_cidr = “10.110.0.0/16″의 CIDR에 4를 추가해서 /20 bit의 CIDR을 3개의 AZ(가용존), 즉 서울이라면 ap-northeast-2a, ap-northeast-2b, ap-northeast-2c에 할당합니다.
. public_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 48)]
intra_subnets = [for k, v in local.azs : cidrsubnet(local.vpc_cidr, 8, k + 52)]
/16 + 8 으로 /24 bit의 CIDR을 3개의 az에 할당합니다. 할당하는 IP는 이전 Private 네트워크 대역 이 후입니다.
실제 적용된 IP 대역을 AWS 콘솔에서 확인하면 아래와 같습니다.
/20 bit 3개, /24 bit 6개가 할당됩니다.
설정이 완료되어 테라폼을 이용하여 EKS를 설치할 수 있습니다. 이전에 ‘git clone’으로 내려받은 테라폼 코드가 저장된 디렉토리로 이동합니다.
Lvi-Jerry-LX2Y49939H:k8s jerry$ cd k8s-class/terraform-eks/ Lvi-Jerry-LX2Y49939H:terraform-eks jerry$ ls eks-addon.tf eks-cluster.tf irsa-role.tf karpenter.tf main.tf outputs.tf vpc.tf
테라폼 명령어로 EKS를 설치합니다.
tf init tf plan -out planfile tf apply planfile
20분 정도 지나면 정상적으로 설치가 완료됩니다. 완료되면 AWS EKS 콘솔에서 아래와 같이 확인할 수 있습니다. EKS 메뉴는 AWS 서비스 메뉴에서 ‘eks’를 검색합니다.
위와 같이 콘솔 화면에서 EKS 정보를 확인할 수 있으면 정상으로 EKS가 설치된 것 입니다.
3. 로컬 Kubectl 운영 환경 설정 – 쿠버네티스 환경 파일(~/.kube/config) 구성 및 Krew 플러그인 활용
쿠버네티스를 관리하기 위해서는 ‘kubectl’ 명령어 도구가 필요합니다. kubectl은 쿠버네티스 클러스터와 상호 작용하기 위해 사용하는 명령줄 인터페이스(CLI)입니다. 사용자가 클러스터의 리소스를 관리하고 모니터링하는 필수 도구입니다. 맥 환경은 homebrew를 이용하여 간단히 설치할 수 있습니다.
brew install kubectl kubectl version --client
참고로 Ubuntu 환경에서도 homebrew를 사용할 수 있습니다. 필자는 wsl ubuntu를 사용하는데 homebrew를 설치하여 사용하고 있습니다. (설치 방법 참조) 위와 동일한 명령어로 ‘kubectl’ 설치할 수 있습니다.
물론 apt 패키지 매니저를 이용해도 됩니다. 자세한 설치 방법은 쿠버네티스 공식 홈페이지에서 확인할 수 있습니다.
sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubectl
설치 후 쿠버네티스 공식 홈페이지의 가이드에 따라 자동 완성 및 Alias 설정을 완료합니다.
apt-get install bash-completion
echo 'source <(kubectl completion bash)' >>~/.bashrc echo 'alias k=kubectl' >>~/.bashrc echo 'complete -o default -F __start_kubectl k' >>~/.bashrc
추가로 아래의 Alias를 등록하면 kubectl 명령어를 좀 더 빠르게 실행할 수 있습니다.
alias kgp='kubectl get pods -o wide' alias kgn='kubectl get nodes -o wide' alias kgs='kubectl get svc -o wide' alias kgv='kubectl get pvc -o wide'
kubectl 도구 설치가 완료되었습니다. 다음으로 원격 EKS 클러스터를 로컬에서 관리하기 위해서는 개인 PC의 Kubernetes Config 파일(~/.kube/config) 수정이 필요합니다. 쿠버네티스의 ‘~/.kube/config’ 파일은 원격 쿠버네티스 클러스터의 주소 정보, 사용자 인증 정보 등을 포함합니다. 설정 파일의 형식은 YAML이며, 직접 편집하거나 ‘kubectl config’ 명령어를 사용할 수 있습니다.
아래는 필자의 PC에 등록한 쿠버네티스 Config 파일입니다. 동일하게 설정하면 원격 쿠버네티스 접속에 필요한 정보가 등록됩니다.
Kubernetes Config 파일의 구성은 아래와 같습니다. 크게 3개의 필드로 구성되었습니다.
. 클러스터(Clusters): 클러스터의 서버 주소와 기본 TLS 인증 정보를 포함합니다. 클러스터에 연결하기 위한 필수 정보입니다.
. 컨텍스트(Contexts): 클러스터와 사용자, 네임스페이스 정보를 포함합니다. 컨텍스트를 사용하면 여러 클러스터와 사용자를 신속하게 전환할 수 있습니다.
. 사용자(Users): 클라이언트의 인증 정보로, 클러스터와 통신하기 위한 인증 수단을 정의합니다. 이는 인증 토큰, 클라이언트 인증서, 사용자 이름 및 비밀번호 등이 될 수 있습니다. 참고로 EKS와 온프레미스 쿠버네티스는 서로 다른 인증 방법을 사용합니다.
그러면 ~/.kube/config 파일의 ‘Clusters’ 와 ‘Users’ 정보를 직접 수정하여 원격의 쿠버네티스 클러스터를 개인 PC에서 관리하겠습니다. EKS 쿠버네티스 Config 파일에 대한 자세한 추가 정보는 AWS 공식 문서에서 확인할 수 있습니다.
먼저 ‘clusters’ 필드의 서버 주소와 인증서 정보는 AWS EKS 관리 콘솔의 ‘개요’ 메뉴에서 확인할 수 있습니다.
해당 정보를 복사하여 위 스크린 샷을 참조하여 로컬 ~/.kube/config 파일에 등록합니다. 주소에 해당하는 ‘API 서버 엔드포인트’를 ‘server’에 인증서 정보인 ‘인증 기관’을 ‘certificate-authotiry-data’에 입력합니다.
다음의 cluster, context, user의 이름을 지정합니다. name은 임의로 정할 수 있어 각자 적당한 이름을 지정합니다. 저는 3가지 모두 동일하게 switch-singapore-test를 입력하였습니다.
마지막 ‘user’ 필드 입력입니다. 아래의 ‘–cluster-name’에는 설치 시 사용한 클러스터 이름(ex: singapore-test)을 입력합니다. env:name, value에는 각자 AWS Credential 정보를 입력합니다. AWS Credential 정보는 ~/.aws/credentials 파일에서 확인할 수 있습니다. EKS 설치에 사용한 Credential 정보를 입력하면 됩니다. ‘env:-name’에 AWS_PROFILE을 ‘env:value’에 AWS Credentials 파일의 Profile 이름을 입력합니다.
해당 설정을 완료하면 이제 로컬에서 kubectl 명령어를 실행할 수 있습니다.
$ (⎈ |switch-singapore-test:default) kubectl get nodes NAME STATUS ROLES AGE VERSION ip-10-110-9-40.ap-southeast-1.compute.internal Ready <none> 39d v1.26.4-eks-0a21954
위 명령어가 정상으로 실행되면 로컬에서 원격 클러스터를 관리할 수 있는 모든 준비가 완료되었습니다. 테스트 파드를 만들면 파드가 정상으로 실행됩니다.
$ (⎈ |switch-singapore-test:default) k run nginx --image=nginx pod/nginx created $ (⎈ |switch-singapore-test:default) k get pod NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 29s
추가로 AWS 콘솔에서 확인하면 VPC, Subnet, NAT Gateway 등이 자동으로 포함된 것을 보실 수 있습니다. 테라폼이 편리하게 모듈로 EKS 설치에 필요한 리소스를 일괄 설치하였습니다.
이상 테라폼을 이용하여 EKS를 설치하는 방법을 알아보았습니다.
테라폼을 이용하면 EKS 뿐만 아니라 EKS 실행에 필요한 다양한 리소스까지 함께 편리하게 설치됩니다. 테라폼은 추상화가 잘되어 있어 여러 리소스의 세부 설정을 완전히 몰라도 설치 및 운영에 큰 어려움이 없습니다. 각 회사 별 상황에 따라 조금씩 수정하여 최적화 과정을 거치면 됩니다.
해당 기술 블로그에 질문이 있으시면 언제든지 문의해 주세요. 직접 답변해 드립니다.
k8sqna@jennifersoft.com
1.테라폼 EKS 모듈 공식 홈페이지 : https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest
2.CNI는 4장 쿠버네티스 네트워크 이해에서 자세하게 설명하겠습니다.
3.카펜터 파드를 서버리스 Fargate를 이용하여 실행할 수도 있습니다.
4.운영 환경에서도 Stateless한 애플리케이션은 Spot Instance 사용 가능합니다.
5.로컬 PC에 테라폼이 설치되어 있어야 합니다. WSL2 Ubuntu 환경에서 Homebrew를 사용하면 맥과 동일하게 brew tap hashicorp/tap, brew install hashicorp/tap/terraform 명령어로 설치할 수 있습니다.
6.자세한 테라폼 명령어 설명은 해당 글의 범위를 벗어나 생략합니다. terraform init, plan, apply 에 관한 명령어는 검색을 통하여 다양하게 확인할 수 있습니다. https://techblog.woowahan.com/2646/
