[쿠버네티스 아키텍처] 1. 구성 및 설계
현재 상태와 Desired State(원하는 상태)를 계속 체크하고(ex.컨테이너 하나가 떠있어야 되는데 잘 떠있는지), 만약 문제가 있다면 조치를 한다. 이 단순한 작업을 잘 반복하면 서버 관리에 문제가 없을 것이다.
Last updated
Was this helpful?
현재 상태와 Desired State(원하는 상태)를 계속 체크하고(ex.컨테이너 하나가 떠있어야 되는데 잘 떠있는지), 만약 문제가 있다면 조치를 한다. 이 단순한 작업을 잘 반복하면 서버 관리에 문제가 없을 것이다.
Last updated
Was this helpful?
44BIT님의 강의를 듣고 정리한 내용입니다.
쿠버네티스가 무엇인지, 그냥 컨테이너를 개발하고 배포하는 것과 무엇이 다른지는 공식 문서 에 잘 설명되어 있다. 본격적으로 공부하기 전에 어떤 느낌인지 이해한 바로는, 쿠버네티스는 기존 분산 시스템을 좀 더 탄력적으로 실행할 수 있도록 도와주고(유연성), 제공되는 프레임워크, 배포 패턴 등에서 서비스의 규모에 맞게 실행할 수 있도록 개발자의 선택지가 더 다양한 것 같다(선택권).
즉, 쿠버네티스는 사용자의 선택권과 유연성을 지켜주면서 확장과 이식이 용이한 컨테이너 관리 오픈소스 플랫폼이다.
하드웨어 유닛
노드(node) : 쿠버네티스에서 최소 단위의 컴퓨팅 하드웨어
클러스터(cluster) : 효율적인 리소스 공유와 균형 배분을 위해 여러 노드를 묶은 그룹
소프트웨어 유닛
컨테이너(container) : 하나 이상의 프로세스 모음. 실행에 필요한 파일도 모두 들어있어 머신 간 이식이 가능.
포드(pod) : 하나 이상의 컨테이너 모음. 리소스 공유의 장점을 극대화하기 위해 패키지로 묶여 있음.
✅ 쿠버네티스에서 포드를 사용하는 이유
포드와 클러스터의 관계 때문에 쿠버네티스는 직접 컨테이너를 실행하지 않는다. 그 대신 포드를 실행하면서 포드 속의 각 컨테이너가 동일한 리소스 및 로컬 네트워크를 공유하게 한다. 이렇게 컨테이너를 포드로 구성하는 것이 쿠버네티스의 유명한 기능, 바로 복제(Replication)의 토대가 된다.
컨테이너를 모아 포드를 만들면, 어떤 포드 하나가 과부하 상태가 되었을 때 쿠버네티스는 자동으로 이를 복제한 다음 클러스터에 배포할 수 있는 것이다.
출처 :
쿠버네티스 구조를 공부하기 전, 먼저 Desired State 개념을 이해하면 좋다. 서버 관리에서 중요한 개념이자 쿠버네티스의 근간을 아우르는 시스템이다. 현재 상태와 Desired State(원하는 상태)를 계속 체크하고(컨테이너 하나가 떠있어야 되는데 잘 떠있는지 등), 만약 문제가 있다면 조치를 하고. 이 단순한 작업을 잘 반복하면 서버 관리에 문제가 없을 것이다.
쿠버네티스의 구조는 위 그림과 같다. 강의 제일 끝부분에 나오는데, 미리 캡쳐를 해봤다. 크게 보면 Master와 Node라는 구조 속에서 서버 관리 흐름이 진행되는 것이다. 위 그림처럼 처음 보는 용어가 가득한 결론은 잠시 다시 잊고, 각각의 개념을 강의 순서대로 익혀보자.
서버 관리에서 state(상태)의 종류는 다양할 수 있다. 쿠버네티스에서는 클러스터 상태의 각 특정한 부분을 관리하는 많은 컨트롤러 를 사용한다. 쿠버네티스 디자인 원리의 핵심이기도 한데, 상태를 제어할 때 루프가 하나로 연결되어 있는 모놀리식(monolithic) 집합보다 간단하게 컨트롤러를 여러 개 사용하는게 편리하기 때문이다.
컨트롤러 개념 덕분에 위에서 배운 Desired State 루프가 아래 그림처럼 굉장히 많아질 수 있다.
기능별로 쪼개고 추상화했기 때문에 각각의 기능을 관리하기가 편해지는 것이고, 이를 통해 관리 자동화를 실현할 수 있게 된다.
CPU 또는 메모리와 같은 포드(컨테이너의의 집합이자 쿠버네티스 애플리케이션의 최소 단위)의 리소스 요구 사항과 함께 클러스터의 상태를 고려한다. 그런 다음 포드를 적절한 컴퓨팅 노드에 예약한다. 쉽게 말해서 여유있는 서버를 찾아 컨테이너를 어디에 띄울지 결정하는 것.
상태를 저장하고 조회하는 DB인 엣지디(etcd)가 있다. etcd는 모든 상태와 데이터를 확실하게 저장해야한다. 따라서 백업은 필수이며, 아래 같은 특징을 가지고 있다.
고가용성 : 분산 시스템으로 구성하여(보통 엣지디를 3대정도 띄운다고 한다) 안정성을 높임
일관성 : 가볍고 빠르면서 정확하게 설계
key-value 형태로 데이터 저장
TTL(time to live), watch 등 부가기능 제공
마스터의 조율자 역할을 하는 API Server 이다. 데이터와 상태를 조회하거나 변경하는 요청은 모두 API 서버를 통해(거쳐서) 이뤄진다. 아래와 같은 특징을 가지고 있다.
상태를 바꾸거나 조회
ectd와 유일하게 통신하는 모듈
권한 체크 (권한이 없으면 요청 거부)
REST API
노드에는 크게 두 가지 컴포넌트가 떠있는데, 프록시(Proxy)와 큐블릿(Kubelet) 이다. 이 두 컴포넌트도 마스터와 통신을 할 때 API Server를 통해서만 요청와 응답를 얻을 수 있다.
네트워크 프록시 역할(부하 분산)을 하긴 하지만 실제로 요청/응답을 받는 프록시가 떠있는 개념은 아니고, 내외부 통신 설정만 관리하는 역할을 한다.
iptables 또는 IPVS를 사용한다.
각 노드에서 실행되며, pod를 실행하거나 중지하고 상태를 체크한다. 도커 등 아니라 다양한 CRI(Container Runtime Interface), 즉 컨테이너를 pod로 감싸 확실하게 관리하는 임무를 가지고 있는 것이다.
