클라우드 네이티브 애플리케이션 부트캠프 알림

티스토리 뷰

2. 쿠버네티스 아키텍처

쿠버네티스를 처음 설치 하시는 분들은 가이드 대로 따라하기는 하는데 왜 이 작업을 해야 하는지 이해가 안되는 게 있을 겁니다.
그 궁금증들은 앞으로 과정을 진행하면서 자연스럽게 풀리게 될 겁니다.
쿠버네티스를 본격적으로 공부하기 전에 다른 제품들처럼 쿠버네티스도 아키텍처부터 이해할 필요가 있습니다.

먼저 쿠버네티스를 구성하는 컴포넌트들에 대해 이해하도록 하겠습니다.
컨테이너를 실행하고 관리하기 위해 어떻게 각 컴포넌트가 역할을 나눠서 하는지를 이해하면 이후에 쿠버네티스 리소스를 학습할 때 동작 원리가 좀 더 명확히 이해 됩니다.

두번째로 클러스터Cluster, 컨텍스트Context, 노드Node, 네임스페이스Namespace의 개념에 대해 배우도록 하겠습니다.
이 개념에 대해 이해하시면 어떤 원리로 클라이언트인 배천노드에서 서버인 쿠버네티스 클러스터로 연결이 되는지 알 수 있게 됩니다. 또한 여러개의 쿠버네티스 클러스터를 접근하는 방법도 아시게 될 겁니다.

2.1 쿠버네티스 컴포넌트

쿠버네티스 컴포넌트를 쉽게 이해하려면 프로젝트 수행 조직을 생각해 보면 됩니다.
프로젝트를 수행을 위한 역할은 PM(Project Manager-프로젝트 관리자), PMO(Project Management Officer-프로젝트 관리 담당자), PL(Part Leader-업무파트 담당자), 멤버로 구성 됩니다.
그리고 PMS(Project Management System-프로젝트관리 시스템)를 통하여 산출물과 진척 상황을 공유 합니다.
예를 들어 요기요 같은 온라인 음식 주문 서비스를 개발하는 프로젝트가 있다고 생각해 봅시다.
그 프로젝트 구조는 아래와 같을 겁니다.





❶ 요구사항 접점: 고객PM이나 고객현업들은 신규/변경 요구 사항에 대한 모든 요청을 PM에게 함
❷ 진행상황 통제: 각 업무파트의 진행이 잘 되고 있는지 통제
❸ 업무배분: 신규/변경 요구사항에 대한 업무 배분을 수행
❹ 제반 정보 저장: 산출물과 제반 진행 상황에 대한 정보를 저장
❺ 주문/결제 업무 개발 관리: 각 파트리더는 업무 파트의 개발이 원활히 진행되는지 통제
❻ 고객과 멤버 연결: 고객의 요청에 맞는 개발 담당자 연결

이러한 프로젝트 관리 구조를 쿠버네티스 아키텍처를 구성하는 컴포넌트와 매치하면 아래와 같습니다.




❶ API Server: CLI나 API호출을 통한 모든 요청을 수신하는 접점 서버
고객PM이나 고객현업들이 신규/변경 요구 사항에 대한 모든 요청을 PM에게 하듯이 쿠버네티스 클러스터로 들어오는 모든 요청을 받아 처리할 컴포넌트에게 전달하는 역할을 합니다.

❷ Controller Manager: 노드, 네임스페이스, 서비스, 파드를 통제하는 컴포넌트
PMO가 각 업무파트의 진행이 잘 되고 있는지 통제 하듯이 클러스터를 구성하는 노드, 네임스페이스, 서비스, 파드를 통제하는 컴포넌트입니다.
구체적으로는 4가지 역할을 합니다. 네임스페이스는 쿠버네티스 오브젝트를 목적별로 그룹핑한 구성 단위입니다. 조금 후에 좀 더 자세히 설명합니다. End Point 리소스는 Service리소스가 Pod를 연결하기 위한 리소스입니다. Service리소스 설명시 다시 설명 하겠습니다.

  • 노드 컨트롤: 노드가 다운되었을때 통지와 조치
  • 네임스페이스 컨트롤: 새 네임스페이스 생성 시 기본 계정(Service Account)과 인증 토큰(Secret) 생성
  • 서비스 컨트롤: 새 Service 생성 시 Pod의 주소를 갖고 있는 End Point 리소스 생성
  • 파드 컨트롤: 지정된 파드 수가 항상 유지 되도록 통제


❸ Scheduler: 파드를 어느 노드에 생성할 지 결정하는 컴포넌트
PMO가 신규/변경 요구사항을 어떤 업무 파트에 배정할 지 결정 하듯이 파드를 어떤 노드에 생성할 지 결정 합니다.
노드의 리소스(CPU/메모리) 사용 현황이나 배포 정의 야믈에 정의된 명세를 고려하여 결정 합니다.

❹ etcd: 쿠버네티스 오브젝트 명세와 상태 정보를 저장하는 키-값(Key-Value) 구조의 데이터베이스
PMS에 산출물과 제반 진행 상황 정보가 저장되듯이 인그레스, 서비스, 파드 등의 쿠버네티스 오브젝트 명세와 상태 정보가 저장됩니다.
etcd에 모든 쿠버네티스 오브젝트의 정보가 저장되어 있기 때문에 쿠버네티스 클러스터를 백업할 때 이 etcd만 백업하면 됩니다.

❺ kubelet: 워커노드에 실행된 컨테이너가 잘 동작하도록 관리하는 컨포넌트
주문/결제 파트리더가 자신이 맡은 업무 파트의 개발이 원활히 진행되는지 관리 하듯이 자신의 노드에 실행된 컨테이너가 정상적으로 동작하도록 관리하는 역할을 합니다.

❻ kube-proxy: 쿠버네티스 외부 또는 내부와 파드를 연결해주는 네트워크 프록시 컴포넌트
파트리더가 고객의 요청에 맞는 개발 담당자를 연결해 주듯이 요청에 따른 파드를 연결해 주는 역할을 합니다.
쉽게 말하면 서비스 오브젝트와 파드를 연결해주는 프록시입니다.

❼ CoreDNS: 쿠버네티스의 서비스와 파드 주소를 관리하는 DNS(Domain Name Server) 컴포넌트
인그레이스가 서비스를 연결하거나 서비스가 파드를 연결할 때 그 주소를 CoreDNS에서 찾아서 연결하게 됩니다.

PM, PMO, PMS가 각 업무 파트를 관리 하듯이 API Server, Controller Manager, Scheduler, etcd는 각 워커 노드의 쿠버네티스 오브젝트들을 관리 합니다. 그래서 이 컴포넌트들은 컨트롤 플레인에 설치 됩니다.
파트리더가 자신의 업무 파트를 관리 하듯이 kubelet과 kube-proxy는 자신의 워커 노드에 배포된 컨테이너가 잘 동작할 수 있도록 관리 합니다. 그래서 이 컴포넌트들은 워커 노드에 설치 됩니다.

지금까지 설명한 쿠버네티스 아키텍처를 기술적으로 표현하면 아래와 같습니다.

어떠십니까 ? 이젠 이 그림만 봐도 각 컴포넌트가 무엇이고 어떤 역할을 하는지 아시겠죠 ?
‘cloud-controller manager’컴포넌트는 AWS, Azure, Google, IBM 등 퍼블릭 클라우드와의 연동을 통제하는 컴포넌트 입니다. 우리는 바닐라 쿠버네티스를 설치하였기 때문에 이 컴포넌트는 생성되지 않습니다.

<그림>

출처: [EKS입문] Kubernetes 구성요소 1
</>

실제 각 컴포넌트가 쿠버네티스 클러스터에 존재하는지 확인해 보겠습니다.

[root@osboxes work]# k get po -n kube-system
NAME                             READY   STATUS    RESTARTS   AGE
coredns-969848984-7s5h5          1/1     Running   0          3d22h
coredns-969848984-jnbwh          1/1     Running   0          3d22h
etcd-master                      1/1     Running   0          3d22h
kube-apiserver-master            1/1     Running   0          3d22h
kube-controller-manager-master   1/1     Running   0          3d22h
kube-proxy-99rwj                 1/1     Running   0          3d22h
kube-proxy-bnpdf                 1/1     Running   0          3d22h
kube-scheduler-master            1/1     Running   0          3d22h

위와 같이 API Server, Controller Manager, Scheduler, etcd, coredns가 Pod로 실행되어 있습니다.
kubelet은 Pod가 아닌 에이젼트로 설치되어 있어 나오지 않습니다.
kube-proxy는 두개가 실행되어 있습니다. 각각 컨트롤 플레인과 워커 노드에 실행된 것입니다.

2.2 클러스터Cluster, 컨텍스트Context, 노드Node, 네임스페이스Namespace 이해

클러스터는 컨트롤 플레인과 워커 노드들을 합쳐서 부르는 용어입니다.
클러스터는 컨트롤 타워 역할을 하는 컨트롤 플레인과 컨테이너가 실행되는 워커 노드로 구성되어 있습니다.
워커 노드는 줄여서 ‘노드’라고도 많이 부릅니다.
여기 까지는 이미 이해하셨으리라고 생각 합니다.

그럼 컨텍스트Context와 네임스페이스Namespace는 뭘까요 ?
클러스터와 노드가 물리적인 구성 단위라면 컨텍스트와 네임스페이스는 논리적인 구성 단위입니다.
네임스페이스는 쿠버네티스 오브젝트들을 논리적으로 묶은 구성단위입니다.
이미지 레지스트리와 깃 레지스트리의 오거니제이션과 동일한 개념입니다.
이미지 레지스트리에서 유사한 성격의 이미지 리포지토리들을 묶어 오거니제이션으로 관리 했고, 깃 레지스트리에서에서는 유사한 성격의 깃 리포지토리들을 묶어 오거니제이션으로 관리했습니다.
쿠버네티스도 인그레스, 서비스, 파드같은 오브젝트들을 유사한 목적별로 그룹핑하여 네임스페이스라는 단위로 관리 합니다.
예를 들어 워커 노드 2대에 주문서비스를 위한 파드 2개와 결제서비스를 위한 파드 2개를 배포한다고 생각해 봅시다.
주문과 결제는 성격이 다른 업무서비스입니다. 파드끼리는 컨테이너화 되어 있기 때문에 상호 격리는 되어 있지만 성격이 다른 업무서비스가 섞여 있는것은 관리하기 힘듭니다.
그래서 아래와 같이 업무 성격별로 네임스페이스를 나누고 네임스페이스별로 파드를 나누어 관리하는 것이 편합니다.
또한 네임스페이스별로 사용할 수 있는 CPU와 메모리 제한을 줄 수도 있습니다.
쿠버네티스 오브젝트들은 일부 오브젝트를 제외하고는 이렇게 네임스페이스별로 관리 됩니다.


컨텍스트는 연결 대상이 되는 클러스터, 네임스페이스, 유저를 묶은 구성 단위입니다.
컨텍스트는 ‘상황이나 문맥'을 뜻하는 영어 단어입니다. 단어 뜻과 같이 상황별로 연결 대상 그룹을 나눈것이 컨텍스트 입니다.
예를 들어 클러스터가 한국과 미국에 있고 업무별로 관리하거나 운영하는 역할이 나뉘어져 있다고 생각해 봅시다.
이 경우 컨텍스트를 아래와 같이 4개로 나누어 관리할 수 있습니다.
사용하는 컨텍스트에 따라서 대상 클러스터, 네임스페이스, 유저를 다르게 관리하는 것입니다. 유저에게는 해당 클러스터와 네임스페이스에 대한 적절한 권한 부여를 하여 보안을 보장 할 수 있습니다.



컨텍스트 정의는 쿠버네티스 컨피그 파일에서 합니다.
설치 시 컨트롤 플레인으로부터 배천노드의 ‘~/.kube’디렉토리에 복사한 ‘config’파일이 쿠버네티스 컨피그 파일입니다.
아래 명령으로 쿠버네티스 컨피그를 확인할 수 있습니다.

[root@osboxes work]# k config view


컨피그 파일 내용을 보면서 컨텍스트에 대해 좀 더 확실하게 이해해 봅시다.

❶ 컨텍스트 리스트를 이 항목 아래에 정의 합니다.
❷ 현재 컨텍스트는 name이 ‘kubernetes-admin@kubernetes’이라는 의미 입니다.
❸ 현재 컨텍스트의 대상 클러스터가 ‘kubernetes’입니다.
❹ 현재 컨텍스트의 접근 유저는 ‘kubernetes-admin’입니다.
❺ 대상 클러스터의 인증 토근과 API Server 주소를 알 수 있습니다.
❻ 현재 컨텍스트의 접근 유저인 kubernetes-admin의 인증 토큰입니다.
※ 대상 네임스페이스가 없기 때문에 기본 네임스페이스인 ‘default’로 연결 됩니다.

쿠버네티스 컨피그에 연결 대상 클러스터, 네임스페이스, 유저를 정의한 컨텍스를 추가하고 그 컨텍스트를 현재 컨텍스트로 바꾸면 새로운 컨텍스트로 연결할 수 있습니다.
그 기술적 방법은 ‘14. 인증과 알백 방식의 인가’에서 설명 하겠습니다.

 

쿠버네티스 쉽게 이해하기 시리즈 목차

[쿠버네티스 쉽게 이해하기 1] 쿠버네티스 설치하기
[쿠버네티스 쉽게 이해하기 2] 쿠버네티스 아키텍처
[쿠버네티스 쉽게 이해하기 3] 한장으로 이해하는 쿠버네티스 리소스
[쿠버네티스 쉽게 이해하기 4] 쿠버네티스 개발에서 배포까지 실습
[쿠버네티스 쉽게 이해하기 5] 쿠버네티스 오브젝트 정의 파일 쉽게 만들기
[쿠버네티스 쉽게 이해하기 6] 꼭 알아야 할 쿠버네티스 주요 명령어
[쿠버네티스 쉽게 이해하기 7] 파드 실행 및 통제를 위한 워크로드 컨트롤러
[쿠버네티스 쉽게 이해하기 8] 파드 로드 밸런서 서비스
[쿠버네티스 쉽게 이해하기 9] 서비스 로드 밸런서 인그레스
[쿠버네티스 쉽게 이해하기 10] 환경변수 컨피그맵과 시크릿
[쿠버네티스 쉽게 이해하기 11] 데이터 저장소 사용을 위한 PV/PVC
[쿠버네티스 쉽게 이해하기 12] 헬스 체크를 위한 스타트업 프로브, 라이브니스 프로브, 레디니스 프로브
[쿠버네티스 쉽게 이해하기 13] 통합 로깅을 위한 EFK 스택
[쿠버네티스 쉽게 이해하기 14] 인증Authentication과 알백RBAC 방식의 인가Authorization
[쿠버네티스 쉽게 이해하기 15] 더 알면 좋을 주제들: 무중단 배포, 모니터링, HPA

댓글

클라우드 네이티브 애플리케이션 부트캠프 알림