[Kubernetes] 개념

배포 변화

• 전통적인 배포: 애플리케이션을 물리 서버에서 실행. 고비용
• 가상화된 배포: 단일 물리 서버가 VM으로 여러 개의 애플리케이션을 실행
• 컨테이너 개발: VM과 유사하지만 확장성이 좋고 비용 절감, 속도 측면에서 유리함.

---

쿠버네티스

• 컨테이너화된 워크로드와 서비스를 관리하기 위한 플랫폼
• 사람 대신 MSA의 수많은 컨테이너를 관리하는 플랫폼
• 이미지 다운, 이미지 구동, 로드 밸런서 연결, 상태 유지 관리 등등의 일을 외주한다.
• YML파일인 Manifest를 명세해서 쿠버네티스에 전달하여 사용 가능

---

쿠버네티스 아키텍처

• Cluster: Control Plane + Worker Nodes로 구성된 하나의 단위
• Control Plane(Master Node): 의사 결정. 정적인 개수가 정해져 있음
• Data Plane(Worker Nodes): 실제로 행동. 동적으로 개수가 변경

Control Plane

• API Server
  
  • 유일한 명령 진입점
  • Developer로부터 명령을 받음
  • 마스터로 전달되는 모든 요청을 받아들이는 REST API 서버
• Scheduler
  • API Server로부터 요청 정보를 받음
  • 요청에 따라 적절하게 컨테이너를 워커 노드에 배치
• etcd
  • 클러스터 내 모든 메타 정보 저장소
  • API Server에서 결정한 모든 메타 정보가 저장됨
• Controller Manager
  • 현재 상태와 원하는 상태를 지속적으로 확인
  • 이벤트에 따라 특정 동작을 수행하는 컨트롤러
• Cloud Controller
  • 클라우드 플랫폼에 특화된 리소스를 제어하는 Controller

Data Plane

• Kubelet
  • 지속적으로 API Server에게 요청을 날림
  • 현재 노드에 할당된 컨테이너가 있는지 확인
  • 컨테이너의 라이프 사이클 관리
• Container Runtime
  • 컨테이너 실행 환경
  • 내부에 파드 존재
• Kube-proxy
  • 컨테이너의 네트워킹을 담당하는 프록시
• 기타 등등의 오브젝트들

---

쿠버네티스 Pod

• 클러스터 내부 배포의 최소 단위 (클러스터 - 노드 - 파드)
• 하나 이상의 컨테이너가 캡슐화되어 배포됨
• 파드마다 고유 IP 할당
• 파드는 일반적으로 하나의 IP만 가짐
• 파드 내부의 컨테이너들은 동일한 스토리지, 네트워크 공유 가능
• 특정 네임스페이스 안에서 실행됨
• 반영속적임

Control-loop

• 자동화된 복구 지원
• 리소스를 지속적으로 모니터링하여 생명 주기에 따라 정해진 작업 수행
• Control-loop을 지속적으로 돌면서 현재 상태가 요청한 상태와 동일해지도록 작업 수행
• Control-loop: 연산을 통해 현재 상태 확인 -> 컨트롤러가 현재 상태를 받아서 요청한 상태와 비교 -> 액션 -> 반복 ...

Deployment

• 애플리케이션 업데이트 및 배포에 유리
• 업데이트 자동화
• Deployment 객체를 사용하여 무중단 배포 지원
• 롤링 업데이트 지원 (일정 개수의 파드만 새 버전으로 교체, 교체 완료되면 다음 파드 교체)
• 롤링 업데이트되는 파드의 비율 자동 조절
• 롤백 가능
• Replicaset을 통해 스케일링 가능 (Replicaset: 파드 집합을 안정적으로 유지)

로드 밸런싱

• 기존의 로드 밸런싱
  • 기존에는 로드 밸런서(혹은 스위치)가 IP가 고정된 인터페이스를 찾아가던 방식
• k8s 로드 밸런싱
  • 경량화된 컨테이너를 포함하는 파드는 쉽게 삭제되고 생성됨.
  • IP 주소만으로 찾을수가 없음
  • 서비스 디스커버리로 해결 가능

서비스 디스커버리

• 특정 서비스를 담당하는 파드가 생성/삭제될 때마다 Service Registry에 Add Entry
• 서버 사이드 서비스 디스커버리
  • Service는 Cluster IP라는 가상 IP를 갖는다.
  • Service가 파드에 대해 부하 분산(로드 밸런싱)
• 클라이언트 사이드 서비스 디스커버리
  • etcd에 파드의 ip에 등록이 되어 있음.
  • 클라이언트가 API Server에 요청하면 etcd를 통해 파드 목록을 가져오고, 사용자가 선택함.

Kube-proxy

• 클라이언트가 서비스에 접근할 때 적절한 백엔드 포트로 트래픽 전달
• API Server로부터 엔드포인트(파드) 리스트 정보를 받아 IPTABLES를 갱신함.
• 각 노드에서 실행됨

IPTABLES

• 네트워크 규칙을 관리하는 테이블
• 모든 워커 노드가 동일한 한 개의 테이블을 참조한다.
• input으로 들어온 ClusterIP가 매칭되면 서비스에 해당하는 파드의 IP들을 확률로 분산시킨다.(로드 밸런싱)

---

리소스

• 쿠버네티스 운영을 위해 필요한 자원들

애플리케이션 실행

• Pod: 다수의 컨테이너가 묶인 최소 단위
• ReplicaSet: Pod의 오토스케일링 담당
• Deployment: ReplicaSet을 생성하거나 갱신함으로써 배포 단위 관리.
• DaemonSet: 노드에 최소 하나씩 있어야 되는 애플리케이션(로그 수집기 등) 운영 (Pod 배치, kube-proxy 운영 등)
• StatefulSet: Pod에 고유성(이름, IP 등)을 부여하여 상태 유지

네트워크 관리

• Service: 전반적인 네트워크 관리. ClusterIP를 사용하여 파드 간 통신, 로드밸런싱 지원. External IP를 제공하여 외부 통신 수행
• Ingress: 애플리케이션 계층(L7)에서 클러스터 외부 접근 관리. URL 기반 라우팅, SSL 암호화 등 수행

설정 정보 관리

• ConfigMap: 애플리케이션 설정 정보(구성 파일, 포트 번호 등)를 K-V 형식으로 관리. 파일이나 환경 변수로 취급됨
• Secrets: 보안이 요구되는 정보(DB 비밀번호, OAuth token 등)를 관리.

배치 잡

• Job: 단발성 배치 작업. 실패 시 Job 컨트롤러에 의해 작업이 성공할 때까지 파드 재생성
• CronJob: 반복적인 배치 작업

그 외

• Persistent Volume: 영구적 볼륨을 제공하는 시스템과 연동하여 볼륨을 생성하거나 삭제
• PersistentVolumeClaim: PersistentVolume을 파드에서 사용하기 위한 요청을 나타내는 리소스
• Node: 기본 작업 단위
• Namespace: 리소스가 속한 논리적으로 분리된 공간
• ResourceQuota: 네임스페이스 별로 사용할 수 있는 리소스 상한 설정
• NetworkPolicy: 파드 간 통신 제어
• ServiceAccount: 파드가 쿠버네티스 API와 상호 작용할 때 사용하는 계정. 파드에게 적절한 권한 부여 가능
• Role: 네임스페이스에 속한 리소스에 대해 접근 권한 및 조작 정의
• ClusterRole: 클러스터 전체 리소스에 대해 접근 권한 및 조작 정의
• RoleBinding/ClusterRoleBinding: Role/ClusterRole을 사용자, 그룹, ServiceAccount와 연결

---

단일 노드에서 파드끼리의 통신에 대해 공부해볼 것. veth와 관련이 있다.