골드에그

Amazon EKS 가 마스터 노드를 Amazon EKS Node groups 가 워커 노드를 관리해준다.

EKS 인증

1 . kubectl 명령을 내리면 Kubernetes Master Node 서버에 API 호출

Kubernetes API 서버 인증 토큰과 IAM 인증 토큰(Kubeconfig 파일) 토큰을 함께 보냄.

2 . 요청한 사용자가 IAM User 가 맞는지만 확인

별도로 Policy 정책은 확인하지 않음. aws-auth 라는 configmap 을 생성함. (Kubectl edit configmap aws-auth -n kube-system 명령어로 확인 가능)

Groups 에는 쿠버네티스 RBAC 권한 정보가 포함됨.

EKS 역할

영역으로 분류

특정 네임스페이스 내 리소스 사용 권한 설정과 클러스터 전역의 리소스 사용 권한 설정으로 나뉠 수 있다.

책임으로 분류

IAM Role 과 유사하게 리소스에 대한 권한이 명시적으로 기재되어 있는 Role 과 해당 Role 의 권한을 할당받을 사용자나 그룹을 설정하는 Role Binding 으로 이루어져 있다.

사용자 추가하고 싶을 때

1 . IAM Role 생성

정책들은 확인하지 않고 사용자인지만 확인하기 때문에 빈 역할만 생성해도 된다.

2 . aws-auth Configmap 의 mapRole 에 추가

3 . ClusterRole 또는 Role 생성

4 . ClusterRoleBinding 또는 RoleBinding 생성

5 . aws-auth Configmap 의 mapRole 에 group 설정

6 . 대상 사용자의 kubeconfig 파일에 인증 정보 설정

kubectl 명령어를 호출할 때, 어떤 role 로 실행할지 명시를 해주어야 하기 때문에 이 설정이 필요하다.

EKS 네트워크 구조

단일 호스트일 때 쿠버네티스 네트워크는 eth0 물리 네트워크 인터페이스, docker0 브릿지 네트워크, veth0 가상 네트워크 인터페이스 구조로 구성되어 있다. Pod 안에 여러 개의 컨테이너를 생성하면 가상 네트워크 인터페이스를 공유하면서 하나의 IP 를 부여받게 된다. Pause 컨테이너를 통해 공유하게 된다.

참고로 도커에서는 --net=container:컨테이너이름 옵션을 주게되면 위와 같이 컨테이너 간 네트워크 공유를 할 수 있다.

다중 호스트일 때는 위와 같이 각 호스트 간 내부 IP 가 충돌하는 문제가 발생할 수 있다. 그래서 각 호스트가 여러 개 되어도 각 컨테이너를 찾아갈 수 있게 모든 호스트의 브릿지 네트워크에 각기 다른 IP 를 할당하는 Overay Network 구조를 생각하게 되었다.

쿠버네티스 코어에 있는 것은 아니고 weave net 이나 AWS CNI, calico, flannel 등 쿠버네티스 플러그인으로 제공한다. 그 중 Amazon EKS 는 AWS CNI 를 사용한다.

그런데 AWS CNI 는 다른 플러그인과 다르게 가상 IP 를 부여하는 것이 아닌 VPC IP Range 내부 IP 를 할당하게 된다.

DaemonSet 의 IPAM 이라는 모듈에서 ENI 로부터 IP 를 받아 Pod 를 할당하게 되는데

ENI 가 할당할 수 있는 IP 수를 초과하면 추가로 ENI 를 생성해서 IP 를 부여한다.

인스턴스 유형마다 최대 ENI 개수와 ENI 당 할당할 수 있는 최대 IP 주소가 다르다.

Amazon EC2 인스턴스 유형 사양 - Amazon EC2 (네(트워크 사양 참고)

따라서 최대로 띄울 수 있는 Pod 의 수 = 인스턴스 유형에 따른 ENI 수 * (ENI 별 IP 수 - 1) 개이다. (ENI 자체가 할당 받는 IP 주소가 한 개 있으므로)

EKS 볼륨 관리

Pod 가 내려가면 데이터가 날라가기 때문에 안정적인 데이터 관리가 필요하다.

심플하게 안정적인 저장소를 준비한 다음 컨테이너에 안정적인 저장소를 마운트하면 된다. EBS 나 EFS 를 준비한다.

1 . Storage Class 를 생성

어떤 저장소를 사용할 것인지 명시한다.

2 . Persistent Volume Claim 생성

어떤 스펙으로 생성할 것인지 명시한다.

3 . 컨테이너에 마운트

EKS 모니터링

마스터 노드 로그는 대상 클러스터 로깅 설정으로 CloudWatch 에 로그가 적재되고 확인할 수 있다.

Pod 모니터링은 Container Insights 를 통해 확인할 수 있다.

1 . 워커 노드의 IAM Role 편집

2 . CloudWatchAgentServerPolicy 정책 추가

3 . 빠른 시작 설정

4 . CloudWatch 페이지 이동

5 . Container Insights 선택

6 . 대상 EKS 클러스터 선택

출처

쿠알못이 Amazon EKS로 안정적인 서비스 운영하기 - 최용호 (넥슨코리아) :: AWS Community Day 2020 (youtube.com)

쿠버네티스 정의

컨테이너를 도커 런타임에 올려서 관리 및 운영, 클러스터 서비스를 지원해주는 프레임워크.

쿠버네티스 구조

[ 요약 ]

[ 상세 ]

components -> api -> etcd 순으로 watch 하고 있다가 변경 사항이 발생하면 watch 대상에게 notify 를 한다.

위 구조에서 components 는 API 서버와 Pod 를 제외한 나머지들 (Controller Manager, Scheduler, Kublet) API 서버에 있는 리소스들은 사실상 etcd 내부에 있는 내용들이다.

쿠버네티스 실행 흐름

(kubectl get events)

Deployment -> ReplicaSet -> Pod 순으로 실행된다.

7번 pod 선정에 대한 내용 로직들은 다음과 같다.

스케줄러가 kubelet 에서 보내준 노드 / 컨테이너 지표(CPU, Memory 사용량), Affinity, Taint 설정 등을 종합적으로 분석하여 새로운 파드를 생성할 워크 노드를 선정한다.

쿠버네티스 고가용성

쿠버네티스 구조를 보면 나머지 구성 정보는 Pod 가 재빠르게 뜨면 문제가 없을 수 있지만, API 서버와 etcd 는 죽으면 가용성에 문제가 생긴다. 그래서 API 서버는 2대, etcd 는 3대가 최소 필요하다. etcd 는 RAFT 라는 분산합의 알고리즘으로 인해 홀수 개를 유지해야 해서 최소 3대가 필요하다.

출처

쿠알못이 Amazon EKS로 안정적인 서비스 운영하기 - 최용호 (넥슨코리아) :: AWS Community Day 2020 (youtube.com)