[45] EKS 코드

* 앱 스케일링이 먼저, 인프라 스케일링은 나중에

 

version에 K8s도 넣어줘야 한다

 

 

---------------------------------NETWORKS-------------------------------------

 

1. variables.tf에 list(string) 으로

- cidr

- az

를 넣어둔다

 

-> 서브넷도, rt assoc도 count 순회하면서 자동 생성

 

------------------------

 

2.

이 서브넷을 public subnet으로 표시

(인터넷용 ELB/NLE 배치 가능) 

k8s에서 type: LoadBalancer로 외부 노출용 서비스를 만들 때 AWS가 어느 서브넷에 LB를 만들까? 를 고를때 힌트로 쓰는 태그

1 값 자체는 플래그 느낌으로 통일해서 1로 넣음

 

*

내부용

"kubernetes.io/role/internal-elb" = "1"

 

*클러스터 태그도 같이 필요해진다.

kubernetes.io/cluster/<cluster_name> = "shared" / "owned"

이 태그가 없으면 컨트롤러가 서브넷을 디스커버리할때 "이 서브넷 우리 클러스터 거 맞아?" 판단 못해서 LB생성이 꼬일 수 있다.

 

shared = 여러 클러스터 / 리소스 공유 가능

owned = 이 클러스터 전용 (클러스터 삭제 시 정리 대상이 되기 쉬움)

 

 

-----------------EKS--------------------------------

 

1, terraform-aws-modules/eks/aws 모듈이 EKS Control Plane(클러스터) 생성

2. EKS Managed Node Group 생성

+ 보안그룹 / IRSA(옵션) / 애드온 등 부가 설정을 한번에 묶어줌

 

-> 이 Worker Nodes들이 kubelet / container runtime(containerd) + CNI plugin가 돌면서 Pod를 실행한다.

클러스터(컨트롤 플레인) 는 지시하고 조정

노드(Worker) 는 실제로 Pod를 돌린다.

 

data.aws_eks_cluster.this

만들어진 클러스터의 endpoint / CA 등 메타데이터 조회

 

data.aws_eks_cluster_auth.this

그 클러스터에 붙을 인증 토큰(짧은 수명) 발급

 

provider "kubernetes"

위 data에서 가져온

- endpoint(API 서버 주소)

- cluster_ca_certificate (TLS 검증용 CA)

- token (요청 인증)

으로 Terraform이 K8s API에 접속하게 만드는 구조

 

AWS Provider로 EKS를 만들고 -> K8s provider로 안에 리소스를 넣는다.

 

 

 

 

 

-----------------------------------EKS-ACCESS--------------------------------

미리 생성하면 오류가 생기므로, depends_on 설정

 

--------------------------------------K8S-APP-------------------------------------

- 네임스페이스

- 디플로이먼트

- 서비스

 

네임스페이스로 격리하고 -> Pod template / replica set -> Service로 해당 파드셋에 대해 엔드포인트 제공한다

 

*kubernetes_* 리소스들은 어느 클러스터에 만들지를 리소스에서 정하지 않고

provider "kubernetes" 가 가리키는 클러스터에 만든다

 

Terraform 입장에서는

- AWS provider : EKS를 만든다

- K8S provicer : endpoint / CA / token으로 그 클러스터에 접속해서 namespace / deploy / service를 만든다

 

------------------------------------------------------------------------------------

그래서 리소스가 k8s_namespace_v1 이런 식으로만 보여도, 실제 대상은 provider가 결정

*실무에서는 provider alias로 dev/prod 클러스터를 분리하기도 함

 

 

 

네임스페이스는 '바구니/구획' 이어서 name만으로 충분히 시작 가능

격리 포인트

- 리소스 이름 충돌 방지

- RBAC 권한 경계 (누가 어디까지 할 수 있나)

- ResourceQuota / LimiRange 등 '자원 제한' 도 네임스페이스 단위로 걸 수 있음

 

replicas :  몇 개 띄울지

selector.match_labels: 이 deployment가 관리할 Pod(ReplicaSet)의 라벨 기준

template.metadata.labels: 실제로 생성될 Pod에 붙는 라벨

img / container port : 컨테이너 스펙

 

***

selector.match_labels와 templage.metadata.labels는 반드시 일치해야 한다

지금 코드는 둘 다 {app = "nginx" } 라서 OK

이게 어긋나면 deployment가 만든 Pod를 자기가 못 찾는 이상한 상황이 생김

 

그리고 container_port는 "컨테이너 리슨 포트" 를 선언하는 값

네트워킹을 실제로 여는 건 Pod/Node의 iptables, service, CNI 등이지만

컨테이너 수준에서 "이 포트로 서비스한다" 는 의미로 흔히 적는다

 

Service는 Pod집합(라벨로 선택된) 에 대한 안정적인 가상 IP(cluster_ip)와 DNS 이름을 제공한다

 

selector :

{app = "nginx"} 라벨 가진 Pod들을 백엔드로 묶음

 

Port : service가 노출하는 퐅트

target_port =  선택된 Pod(정확히는 Pod의 Container_port로 가는) 포트

 

type = LoadBalancer

AWS에선 클라우드 로드밸런서를 자동 생성해 외부에서 접근 가능한 엔드포인트를 만들어준다