1. 쿠버네티스란?
컨테이너 오케스트레이션 툴로서 컨테이너화된 어플리케이션과 리소스를 확장 및 축소합니다
또한 자동 배치, 자동 재시작, 자동 복제, 자동 확장을 사용해 어플리케이션 상태 확인과 셀프 복구를 수행, 선언적으로 서비스를 관리함으로써 배포된 어플리케이션이 항상 배포 목적대로 실행됩니다
2. EKS란
AWS에서 만든 관리형 kubernetes 서비스로서 eks를 사용하면 쿠버네티스 설치부터 운영까지 eks가 많은 역할을 수행하여 직접 쿠버네티스 클러스터를 구성하고 관리하는 것보다 쉽게 쿠버네티스를 사용 가능
a. EKS 아키텍쳐
eks는 api-server etcd controller manager 클라우드 컨트롤메니저로 구성
ㄱ. api서버가 kubectl 명령어를 통해 사용자의 요청을 받으면 etcd에 저장되어 있는 저장정보를 스케쥴러에게 전달
ㄴ. 스케쥴러는 etcd를 통해 받은 정보를 바탕으로 pod가 어느 워커 노드에서 실행될지 정하게 되고 이를 api 서버에 반환
ㄷ. api 서버는 스케쥴러가 정한 워커 노드에 있는 kubelet에게 실행할 파드스펙 정보를 전달하게 되고 이를 바탕으로 pod를 생성
ㄹ. controller 메니저는 각 노드마다 실행되고 있는 kubelet에 cadvisor에 의해 수집된 정보를 감시하고 있다가 파드가 죽더라도 일정한 레플리카 수를 유지
ㅁ. cloud controller manager는 클러스터에서 실행되는 리소스를 실제 클라우드 상에 생성
3. 쿠버네티스 스토리지
a. emptydir
Pod의 컨테이너 간에 Volume을 공유하기 위해 사용하며 컨테이너 간 파일을 공유
pod내의 컨테이너간의 볼륨을 yaml에 지정된 있는 디렉터리에 복사 pod 삭제 시 볼륨도 삭제됨
Pod가 실행되는 도중에만 필요한 휘발성 데이터 저장에 용이
b. hostPath
Pod 밖의 호스트와 Volume을 공유하면 파드가 삭제당해도 볼륨파일 보존 가능
Pod에 있는 데이터를 Node의 볼륨과 공유하여 휘발성인 pod 데이터의 안정성을 보장
c. PV/PVC
PV: 데이터 분석을 위한 최적화. 볼륨을 생성하고 클러스터에 등록한 것
PVC: 필요한 저장 공간·RW 모드 등 요청사항을 기술한 명세로서 PV에 전달하는 요청. PV와 바인딩을 목적으로 사용
ㄱ.PV는 가상 스토리지로서 인스턴스 관리자에 의해 생성
ㄴ.사용자 볼륨으로 PVC를 요청
ㄷ.이미 생성된 PV중에 요청에 적합한 PV를 선택하여 PVC의 스토리지로 사용
-> disk provisioning
ㄹ.PVC를 볼륨으로 포함한 Pod 생성
사용한 PV는 persistentVolumeclaimPolicy에 의해 처리 방식이 상이
Retain : PV의 데이터를 그대로 보존
Recycle : 재사용하게될 경우 기존의 PV 데이터들을 모두 삭제 후 재사용
Delete : 사용이 종료되면 해당 볼륨을 삭제
4. AWS EBS Controller
a. EBS CSI driver 동작 방식
pvc 생성시 마다 PV를 동적으로 생성 및 attach
b. persistentvolume, persistentvolumeclaim의 accessModes는 ReadWriteOnce로 설정하는 이유?
NFS가 아닌 EBS이므로 다중 노드에서 조작 불가
c. EBS스토리지 기본 설정이 동일 AZ에 있는 EC2 인스턴스(에 배포된 파드)에 연결해야하는 이유와 파드 스케쥴링 방안?
()
5. 쿠버네티스 네트워크
a. Calico CNI
Calico는 Overlay 방식을 통해 노드간 통신
Overlay Network는 기본적으로 패킷을 encapsulation 해서 통신 노드간에 가상 Tunnel을 생성하고, 각 노드에 위치한 가상의 터널의 Endpoint를 통해 캡슐화 된 패킷을 전달하는 방식을 활용하여 복잡한 네트워크 환경에서의 통신을 추상화
b. AWS VPC CNI
eks 상에서 Pod는 VPC 내 사설 ip를 할당
aws vpc cni는 파드의 IP 네트워크 대역과 노드(워커)의 IP 대역이 같아서 직접 통신이 가능하다
c. Kube-Proxy
다른 ip 대역에 있는 서비스로 요청을 보냈을 때 파드끼리 통신할경우 kube-proxy를 통해 통신
kube-proxy는 모든 노드에 daemonset 형식으로 실행
클러스터 내에 서비스가 생성되면 api 서버가 새로 생성된 서비스의 클러스터 아이피를 모든 노드의 kube-proxy에 업데이트
kube-proxy는 iptables에 규칙을 추가하고 모든 패킷을 감시
사용자가 보낸 요청을 iptables에 추가된 규칙에 맞춰 서비스에 엔드포인트로 묶여 있는 pod에 요청을 전달
d. CoreDNS
1. 서비스 디스커버리: CoreDNS는 Kubernetes 클러스터 내에서 서비스 디스커버리를 제공
컨테이너에서 실행되는 애플리케이션은 DNS 이름을 사용하여 다른 서비스를 찾고 통신 가능
-> 확장 및 마이그레이션에 유리
2. 사용자 정의 및 확장성: CoreDNS는 적은 노력을 통해 구현 및 확장 가능한 서비스구성
3. Kubernetes API와의 통합: CoreDNS는 Kubernetes API 서버와 원활하게 통합
-> Kubernetes API를 쿼리함으로써 클러스터 내의 서비스, 엔드포인트 및 기타 리소스를 자동으로 검색
참고자료: https://h-susu.tistory.com/13
6. 쿠버네티스 서비스
a. ClusterIP
k8s 클러스터의 기본이 되는 서비스
ClusterIP를 생성하면 클러스터 내에서만 소통할 수 있는 가상 IP가 Service에 할당
ClusterIP에 대한 통신은 kube-proxy라는 Worker Node에서 실행되는 시스템에 따라 같은 라벨이 붙여진 pod로 전송
b. NodePort
Worker Node의 IP 주소와 미리 지정한 포트 번호로 외부에서 액세스할 수 있는 특징을 가진 Service
또한, NodePort 타입의 Service에서 수신한 트래픽은 클러스터 내부로 전달되어 적절한 pod로 배분
이로 인해 NodePort 타입의 Service 생성시에는, 클러스터 내부에의 전송을 위해 ClusterIP도 자동적으로 할당
c. LoadBalancer
클라우드 프로바이더가 제공하는 LB를 이용해, 클러스터 외부에 공개
ㄱ. 외부에서 온 액세스를 외부 LB에서 수신.
ㄴ. 외부 LB와 k8s의 LoadBalancer 타입의 Service의 연계에 의해 외부 액세스가 각 Worker Node의 NodePort를 목적지로 전달
ㄷ. NodePort에서 CulsterIP로 전송되고, Pod로 전송
7. Ingress란
클러스터의 서비스에 대한 외부 액세스(주로 HTTP)를 관리하는 API 개체로서 부하 분산, SSL 종단, 도메인 기반 가상 호스팅 기능을 제공합니다.
Ingress를 사용하면 여러 개의 다른 도메인 이름으로 온 HTTPS 요청을 하나의 IP 주소로 수신 한 후 여러 개의 다른 호스트 이름으로 전달 가능
a. ingress Controller에 동작과정
ingress는 외부로부터 들어오는 규칙을 정의해 둔 자원으로 이런 규칙들을 실제로 동작하게 해주는 것이 ingress-controller
ㄱ. ingress controller는 deployment 형태로 배포되어 클러스터 내에 ingress 리소스의 생성 여부를 감시
ㄴ. 인그레스가 생성되면 aws상의 alb를 생성
ㄷ. 생성된 alb를 설정하여 ingress 규칙에 따라 지정 타겟그룹으로 사용자의 요청을 전송
8.스테이트풀센 & 헤드리스 서비스
a. Headless서비스란?
일반적으로 Service는 ClusterIP를 가지며 여러 Pod에 대한 로드 밸런싱을 수행하는 기능을 제공
따라서, 서비스에 액세스하는 측에서는 Service의 ClusterIP 주소만 인식 후 접속
Headless의 경우 ClusterIP 및 로드 밸런싱 기능 미제공
대신 DNS 라운드 로빈 형식(headless selector 기반)으로 해당 포드의 IP를 직접 액세스 소스로 반환
사용자는 반환된 IP를 바탕으로 직접 Pod에 액세스
b. StatefulSet이란?
StatefulSet은 프로그램이 오류로 다시 시작될 때 파일 시스템에 데이터를 저장하고 다시 연결할 수 있는 응용 프로그램을 개발자가 배포할 수 있도록 하는 것
StatefulSet 을 배포하면 K8s는 각 복제본에 고유한 상태(볼륨)를 할당하여 배포 및 업데이트 순서를 보장
특정 StatefulSet 에 세 개의 복제본을 지정할 경우
ㄱ. StatefulSet 은 순서대로 배포하고 각각에 고유한 PVC 를 할당
ㄴ. StatefulSet 을 삭제하거나 확장하면 처음 배포할 때와 동일한 순서로 삭제되거나 확장되며 PVC 는 삭제되지 않으므로 데이터 안전성을 보장
c. StatefulSet에 헤드리스 서비스가 필요한 이유
d. StatefulSet 리소스를 사용하려면 반드시 쌍을 이루는 헤드리스 서비스가 반드시 필요
StatefulSet이 생성하는 Pod는 일반적으로 각각에 PersistentVolume이 할당되어 다른 데이터를 저장
-> 저장하는 데이터가 다르다는 것은 모든 Pod에서 동일한 프로그램이 움직이고 있어도, 어느 Pod에 요청하는지에 따라 결과가 다르다는 것 이때 Headless 서비스를 사용할 경우 어떤 포드에 요청할지 대상 호스트 이름을 명시하고 사용 가능
