정리중
목표
1.
주요 오브젝트 및 API의 핵심 구성 요소를 포함한 Kubernetes의 주요 구성 요소에 대해 설명할 수 있다.
2.
Amazon EKS가 Kubernetes ControlPlane을 어떻게 관리하는지 설명할 수 있다.
3.
Amazon EKS를 직접 구축할 수 있다.
4.
Amazon EKS Cluster에 Application을 배포할 수 있다.
5.
Amazon EKS Cluster를 모니터링하고 확장할 수 있다.
6.
Amazon EKS의 효율성, 복원력, 비용 최적화 사이에서의 타협점을 설명할 수 있다.
7.
효율적이고 안전한 통신을 구성할 수 있다.
8.
Amazon EKS Cluster를 보호하는 방법을 설명할 수 있다.
9.
Amazon EKS의 업그레이드를 관리할 수 있다.
1일차
emptyDir : 파드 내 컨테이너 간 볼륨 공유
hostPath : 노드 내 파드 간 볼륨 공유
Persistent : 클러스터 내 노드 간 볼륨 공유
왜 pv, pvc로 나누었을까?
pv는 클러스터 레벨에서 생성되고, pvc를 각 노드에 생성해서 연결하는 개념
pvc는 pv를 자원으로써 접근할 수 있도록 해준다.
EFS에 pv를 생성하고 파드와 연결하려면 CSI(Container Storage Interface) 드라이버를 이용한다.
스토리지 유형
EBS : 최근 여러EC2(Node)에 동시에 연결할 수 있으나, 느려질 수 있음. 네트워크로 EC2와 연결되므로.
이경우 아래 2가지 유형을 사용한다.
EFS(NFS기반)
FSx(SAMBA기반)
ConfigMap과 Secret
파드가 실행될때 필요한 정보들을 저장하는 용도 = ConfigMap
보안 자격증명 등의 보안성이 필요한 경우 = Secret * 저장할때 base64로 인코딩 후 넣어야함
사용방법
1.
어플리케이션에서 환경변수를 이용해 사용
2.
볼륨처럼 연결해 사용
Namesapce : 논리적 분리 단위
서로 통신은 가능하지만 리소스 간 네이밍 충돌 방지를 위해 사용
Deployment -> controlled by -> ReplicasSet -> controlled by -> Pod
•
Pod Scheduling이란?
조건자, 우선순위를 가지고 파드를 어떤 노드에 배치할것인가?
1.
조건자: 볼륨 요구 사항
A,B,C 가용영역에 워커노드(EC2)가 각각 존재하고 A 가용영역에 EBS를 생성한 경우,
이 EBS를 pvc로 연결한 파드는 B,C에는 스케쥴링 될 수 없다. 왜냐하면 EBS는 가용영역 단위의 서비스이기 때문임.
이를 해결하기위해서는 리전 단위의 EFS를 사용해야함
2.
조건자: 리소스 요구 사항
request: guarantee(보장)의 개념
limit : burstable의 개념 *burstable의 의미는 request ≠ limit
Node1에 할당된 메모리 : 1000MB | P1의 request : 300M, limit : 500M | P2의 request : 400M, limit : 500M
P1의 실제 메모리 사용량 : 200M
P2의 실제 메모리 사용량 : 200M
일때, P3(request: 400M, limit : 800M)이 Node1에 스케쥴링 가능할까? No
즉, 스케쥴링 기준은 실제 메모리 사용량이 아니라 request기준으로 판단한다.
노드 메모리 용량을 초과하는 경우 파드는 Pending 상태로 대기한다.
압축가능 리소스 : CPU(MI; milicore), I/O
압축불가능 리소스 : Memory(M; megabyte)
*압축가능하다라는 의미는 시분할(Time Slicing)이 가능한 리소스를 의미
압축가능 리소스인 CPU 예시
Node1에 할당된 CPU : 1000MI | P1의 request : 300MI, limit : 500MI | P2의 request : 400MI, limit : 500MI
P1의 실제 메모리 사용량 : 500MI
P2의 실제 메모리 사용량 : 500MI
일때, P3(request: 250M, limit : 800M)이 Node1에 스케쥴링 가능할까? Yes
즉, 압축가능한리소스는 노드 할당값을 넘어도 시분할을 통해 스케쥴링된다.
압축불가능 리소스인 Memory 예시
request기준으로는 충족하지만, 실사용량으로는 스케쥴링이 불가능하다. 하지만 실제로 스케쥴링되며, 기존 파드를 재시작 후 스케쥴링된다.
파드가 종료될 가능성에 대한 판단
Pod의 QoS는 kubectl describe pod [PodName] 명령어 결과 내 QoS Class 항목에서 확인 가능하다.
Pod 리소스 제한은 Namespace단위로 ResourceQuota로 설정 가능
그렇다면 실무적으로 Request와 Limit값을 산정하는 기준은?
일반적으로 권장되는 기준
- Request = 평균 사용량 * 1.1
- Limit = Peak Time
근본적인 해결책은 AutoScaling을 통한 수평적 확장 !
Taint와 Tolerations
NodeSelector(안쓰는추세) - Label를 가지고 있는 경우만 적용가능 = 표현식이 부족하다. 따라서 대신 어피티니를 사용하도록 권고됨
NodeAffinity -operator를 통한 다양한 표현식을 사용할 수 있으므로 사용 권장됨.
Daemonset - 로깅용도로 주로 사용