PaaS 환경 구축/운영 방식 추가
1. 쿠버네티스 아키텍처
1.1 인프라 환경에 따른 쿠버네티스 구축
(1) Legacy 형태
기존 IaaS가 없는 상태에서 쿠버네티스 구축
(2) SDDC 형태 1
IaaS가 있는 상태에서 k8s 구축
(3) SDDC 형태 2
Private Cloud의 장점에 최적화된 구성
논의주제 : PaaS를 어디에서 서비스 하는것이 최적인가요?
1.2 쿠버네티스 구축 예시
1.2.1 Stack 별 서버 분류
1.2.2 서버 네트워크 구성
1.3 하이브리드 구축 예시
1.3.1 AWS 환경 ( **은행)
1.3.2 private cloud 이용 (**전자)
cloud 위치별 사용자 연결
초기 dns 에 연결되면, bind9에서 ip주소에 따른 위치 연결
Mgt 서버에서 프라이빗 클라우드 사용량을 확인하고, private/eks노드를 만들어서 Endpoint 제공
L4 switch를 통해 haproxy를 타고, 등록된 정보를 확인하고 그 서버로 접근
2. 쿠버네티스 구성요소
2.1 Control Plane
(1) kube-apiserver
쿠버네티스 클러스터로 들어오는 요청을 가장 앞에서 접수하는 역할을 합니다.
kubectl을 사용하여 명령을 수행할 경우 kube-apiserver로 전송합니다.
(2) kube-scheduler
새로 생성된 파드를 감지하고, 어떤 노드에 배치되어야 하는지 판단합니다.
파드 스케줄링 결정을 위해 요구사항, 정책제어, 어피니티, 라벨 등 요소를 고려합니다.
(3) kube-controller-manager
컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트
노드 컨트롤러 : 노드가 다운되었을 때 통지와 대응에 관한 책임을 가집니다.
잡 컨트롤러 : 일회성 작업인 Job 오브젝트를 감시하여 해당 작업을 완료할 때까지 동작하는 파드를 생성합니다.
엔드포인트 컨트롤러 : 서비스와 파드를 연결합니다.
서비스 어카운트&토큰 컨트롤러 : 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성합니다.
(4) ETCD
모든 클러스터 데이터를 담는 Key-Value 저장소입니다.
etcd 백업 기능으로 특정 시간의 데이터 백업 수행합니다.
2.2 Node 컴포넌트
(1) kubelet
클러스터의 각 노드에서 실행되는 에이전트
파드에서 컨테이너가 확실하게 동작하도록 관리합니다.
파드 스펙(PodSpec)을 받아 컨테이너 동작을 확실히하며, 쿠버네티스를 통해 생성되지 않은 컨테이너는 관리하지 않습니다.
(2) kube-proxy
각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스 서비스 개념의 구현부
노드의 네트워크 규칙을 유지 관리하여, 클러스터&파드의 통신을 가능하게 해줍니다.
2.3 공통 컴포넌트
(1) Container Runtime
컨테이너 실행을 담당하는 소프트웨어
쿠버네티스 CRI 구현체인 containerd, CRI-O 와 같은 런타임을 지원합니다.
쿠버네티스에서는 도커를 런타임으로 지원하였으나, v1.24 버전부터 기본 엔진에서 제외했습니다.
그림 출처 - https://www.docker.com/products/container-runtime/
(2) Container Network Interface (CNI)
컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준
CNI를 준수하는 다양한 플러그인이 존재(Calico, Weave, Cilium 등)
CNI 요구사항
veth 페어 생성 및 컨테이너 네트워크 인터페이스와 연결
파드 네트워크 대역 확인 후 IP 설정
CNI 설정 파일 작성
IP 설정 및 관리
컨테이너 내 기본 라우팅 정보 삽입(default route rule)
다른 노드들에게 IP 라우팅 정보 전달(advertising the routes)
호스트 서버에 라우팅 정보 삽입
네트워크 정책에 따라 트래픽 처리
…
2.3 쿠버네티스 컴포넌트 통신 플로우
Control Plane의 API Server와 Worker Node의 kubelet을 통해 클러스터 관리합니다.
관리자는 kubectl 명령어를 사용하여 클러스터를 관리합니다.
사용자는 Proxy(Service IP)를 통해 접근하여 서비스 접속할 수 있습니다.