간단한 쿠버네티스 아키텍처 알아보기

글 시작전에 쿠버네티스를 공부하다 거의 절망했는데 (도커 친구 같은 너.. 도커도 힘든데 너는 그냥 모르겠다...)

날 구제해준 영상 강의가 있어, 한 번 보고, 다시 한 번 보면서 그림그리면서 정리한 것을

다시 블로그에 정리해서 올리면서 복기하려고 한다.

(그 강의는 아래 참고자료에 있다. 진짜 추천👍👍👍)

 

쿠버네티스에서 강조하는 <Desired State>

• 상태체크 (Observe)
  • 현재 상태와 원하는 상태가 맞는지 (현재 상태 == 원하는 상태) 확인하는 것
    즉, 컨테이너 하나만 떠 있어야 하는데, 실제로도 하나만 떠 있는지 확인하는 것이다.
• 차이점 발견 (Diff)
  • 컨테이너 하나가 떠 있어야 하는데, 떠 있지 않으면 차이점을 발견한 것이다.
• 조치 (act)
  • 컨테이너 하나가 있어야 하지만, 그렇지 않기 때문에 컨테이너 하나를 띄워준다.

이 같은 작업을 계속해서 반복하는 것이고, 쿠버네티스의 근간이 되는 패턴? 이다.

 

간단한 쿠버네티스 아키텍처

참고자료 영상 캡처

크게 Master 영역과, Node 영역으로 구분할 수 있다.

먼저 Master 영역을 보자.

• etcd (엣시디, 엣지디 등등 다양하게 부른다.)
  • 모든 상태와 데이터를 저장하는 일종의 데이터베이스이다.
  • 현재 상태가 어땠는지, 어떤 상태를 원하는지에 대한 모든 기록이 담겨 있다.
    => 그만큼 굉장히 중요하고, 백업이 필수인 요소이다.
  • Key - Value 형태로 데이터를 저장한다.
  • 분산 시스템으로 구성해서 안전성을 높이며, 가볍고 E빠르면서 정확하게 설계해야 한다.
  • TTL, watch 같은 부가 기능도 제공한다.
• API Server (교통 경찰 같은 존재)
  • 상태를 바꾸거나, 조회를 한다. 
  • 어드민(왼쪽 컴퓨터 모양)에서 요청을 보내거나, 스케줄러, 컨트롤러, 프록시, 큐블렛 모두 상태에 관한 조회와 수정 요청은 API Server 에게 보낸다.
    => etcd 를 직접 통신할 수 있는 것은 API Server 뿐이다.
  • REST API 형태로 제공된다.
  • 요청을 받았을 때, 권한을 체크해서 적절한 권한이 없을 경우 요청을 차단하는 역할도 한다.
  • 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신이 가능하다.
• Scheduler
  • 새로 생성된 Pod(파드 or 팟)을 감지하고 실행할 노드를 선택하는 역할을 한다.
  • 노드의 현재 상태와 Pod의 요구사항을 체크한다.
    이 때, 노드에 라벨을 부여할 수 있고, 이럴 경우에 특정 라벨에 해당하는 노드에 배포가 가능하다.
• Controller
  • 끊임없이 상태를 체크하고, 원하는 상태를 유지하도록 한다.
    위에 나온 Desired State 형태이다.
  • 논리적으로 다양한 컨트롤러가 존재할 수 있다.
    => 노드만 체크하는 컨트롤러가 있을 수 있고, 엔드포인트만 체크하는 컨트롤러가 있을 수 있다.
  • 복잡성을 낮추기 위해 하나의 프로세스(단일)로 실행한다.

정리하면 API Server 는 etcd 에 저장된 상태들을 조회하거나 수정하고, 상태들을 Desired State 로 지속적으로 체크하는 Controller 가 있고, Pod가 적절한 노드에 배치되도록 하는 Scheduler 가 있다. 그리고 etcd는 오로지 API Server 만 가능하다.

 

두 번째, Node 영역을 보자.

 

• kubelet (큐블렛)
  • 각 노드에서 실행되는 것
  • Pod를 실행하고 중지하고 상태를 체크하는 것이다
• Proxy
  • 네트워크 프록시와 부하 분산 역할을 한다.
  • 성능 상의 이유로 별도의 프록시 프로그램 대신, iptables 나 IPVS 를 사용한다.

중간 중간 나온 Pod 는 무엇인가?

• Pod (팟 or 파드라고 부른다)
  • 쿠버네티스에서 가장 작은 배포 단위이다.
    => 컨테이너 배포가 아니라 Pod를 배포하는 것이다.
  • 전체 클러스에서 고유한 IP를 Pod 에게 할당한다.
  • 여러 개의 컨테이너가 하나의 Pod에 속할 수 있다.
    => 하나의 Pod 에 두 개의 컨테이너가 뜰 수 있다는 것이다.

그리고 이 작은 Pod를 또 감싸는 친구가 있다.

• ReplicaSet
  • 여러 개의 Pod를 관리하는 것이다.
  • 하나의 ReplicaSet에 replicas 가 3이면, 3개의 Pod를 가지고 있는 것이다.
  • 만약 replicas 가 3에서 4로 바뀌면, ReplicaSet은 Pod를 하나 더 띄운다.
    => 신규 Pod을 생성하거나 기존 Pod를 제거해서 원하는 수 (Replicas)를 유지한다. => 알아서 혼자 스스로
• Deployment
  • 배포 버전을 관리하는 것으로 ReplicaSet 을 감싸고 있다.

요약하면 Deployment 안에 ReplicaSet이 있고, 그 ReplicaSet 안에 replicas 의 수 만큼의 Pod가 관리되고 있는 것이다.

다만, 직접 Pod를 만들지 않는다. 

그러면 아래와 같은 구조가 된다.

그럼 이 때, 무중단 배포는 어떻게 진행될까, 그것은 replicaSet을 여러 개 만들면서 차근차근 옮기듯이 진행된다.

Deployment 가 version 2로 바뀌면서, v2의 ReplicaSet을 만들고, 점차 v1의 ReplicaSet의 Pod 개수를 줄여나가 오른쪽 이미지와 같이 변경된다.

 

이 동영상을 보고 쿠버네티스 문서를 보니 그제야 눈에 좀 들어온다.

네트워크 관련 서비스는 시간 날 때 또 정리해서 올려야겠다.

---

- 참고자료

https://www.youtube.com/watch?v=Ia8IfowgU7s&list=PLIUCBpK1dpsNf1m-2kiosmfn2nXfljQgb