-
쿠버네티스 기초 개념카테고리 없음 2022. 6. 6. 00:04
#쿠버네티스란
#도커컴포즈와 쿠버네티스의 차이
#마스터노드와 워커노드의 컴포넌트
#pod,service,레플리카세트,디플로이먼트
쿠버네티스는 컨테이너 오케스트레이션 도구의 일종이다.
컨테이너 오케스트레이션이란 시스템 전체를 총괄하고 여러개의 컨테이너를 관리하는 일을 말한다.
k8s 라고도 하는데 kubernetes k와 s사이에 8글자가 있어서..
본질상 일반적인 프로그래머가 k8s 를 활발하게 사용할 일은 없다.
여러 개(동일한 구성의 컨테이너 세트)의 컨테이너(서버)를 관리하는 도구인데, 많은 수의 서버로 구성되는 대규모 시스템을 관리할 일이 많이 없기 때문이다.
다만 쿠버네티스로 어떤 일을 할 수 있는가에 대한 지식은 시스템 개발 시 유용할 수 있다.
쿠버네티스로 관리되는 시스템은 이를 전제로 개발해야한다.
도커는 한 대의 물리적 서버에서 실행되는 경우가 많았지만,
쿠버네티스는 여러 물리서버가 존재하는 것을 전제로 한다.
또 물리 서버 한 대마다 여러 개 컨테이너가 있다.
docker run 커맨드의 중복, docker-compose 의 중복이 여러 물리 서버에 걸쳐있으면 일일이 모니터링, 장애대응, 업데이트 하기 번거롭기 때문에 쿠버네티스는 이런 수고를 덜어주는 도구이다,
도커컴포즈파일과 비슷한 매니페스트 파일만 정의하면 모든 물리서버에 컨테이너를 생성하고 관리해준다.
쿠버네티스는 전체적인 제어를 담당하는 마스터노드와 실제 동작을 담당하는 워커노드라는 두가지 유형의 노드로 구성된다.
노드는 물리서버와 거의 일치하는 개념이다.
마스터 노드는 이름 그대로 감독과 같은 존재이다. 마스터노드에서는 컨테이너를 실행하지 않는다.
워커 노드에서 실행되는 컨테이너를 관리하는 역할을 한다.
워커노드는 컨테이너가 동작하는 실제 서버에 해당하므로 컨테이너 엔진이 있어야한다.
이렇게 마스터, 워커 노드로 구성된 일종의 쿠베시스템을 클러스터라고 한다.
클러스터는 마스터노드에 설정된 내용에 까라 워커노드가 관리되며 자율적으로 동작한다.
관리자는 마스터노드 초기 설정 후 가끔 조정만 하며, 워커 노드를 직접 관리할 일이 없다.
쿠버네티스 설치에 CNI(가상네트워크드라이버), etcd(컨테이너 관리용 DB), 도커엔진같은 컨테이너 엔진이 필요하다.
CNI 는 마스터, 워커 노드 양쪽에 다 있어야하지만, etcd 는 마스터에만, 도커엔진은 워커노드에만 있으면 된다.
관리자 pc 에는 kubectl 을 설치해 이를 통해 마스터노드를 설정한다.
컨트롤플레인을 통해 master 는 worker를 관리한다.
컨트롤 플레인은 다섯가지 컴포넌트로 구성된다.
kube-apiserver: 외부 통신 프로세스, kubectl 에서 명령 받아 실행
kube-controller-manager: 컨트롤러를 통합 관리, 실행
kube-scheduler: 파트를 워커노드에 할당
cloud-controller-manager: 클라우드 서비스와 연동해 서비스를 생성
etcd: 클러스터 관련 정보 전반을 관리하는 데이터베이스
worker 노드에는
kube-let: 마스터에 kube-scheduler 와 연동해 워커노드에 파드를 배치하고 실행한다. 또 실행 중인 pod 를 정기적으로 모니터링하고 kube-scheduler에 통지한다.
kube-proxy: 네트워크 통신의 라우팅 매커니즘
*도커 컴포즈로 컨테이너 수를 변경할 순 있지만 모니터링은 할 수 없다. always 옵션이 있긴하다.
쿠버네티스는 모니터링으로 볼륨 갯수, 컨테이너 갯수 등 상태를 유지하는 기능이 있다.
여러 물리 서버에 걸쳐 시스템 구성이 가능하다.
쿠버네티스의 기능은 '자동으로 상태를 유지하는' 것이므로 컨테이너를 삭제하고 싶다면 '바람직한 상태' 에 대해 수정해야한다.
부하에 맞춰 컨테이너 수 조정이 가능하다.
쿠버네티스의 매니페스트 파일은 etcd 에서 관리된다. 하지만 커맨드로 정의파일을 수정할 수도 있는데, 이 경우에는 정의 파일과 etcd 정보가 일치하지 않게 된다.
pod 는 컨테이너와 볼륨을 묶은 개념이다.
기본적으로 pod 하나에 컨테이너 한 개이지만, 파드 1개에 컨테이너가 여러 개 있을 수 있다.
*파드에 볼륨이 없는 경우도 있다.
컨테이너 관리단위는 pod 이다.
이 pod 를 모은 것이 서비스이다. 여러 개의 pod 를 이끄는 반장이라고 할 수 있다.
서비스가 관리하는 pod 는 기본적으로 모두 동일한 구성을 갖는다.
다른 구성을 가진 파드는 다른 서비스로 관리한다.
서비스는 여러 개의 파드를 이끄는 반장이므로 파드가 여러 개의 워커 동작해도 서비스가 이를 모두 관리할 수 있다.
각 서비스는 자동적으로 고정된 IP(Cluster IP) 를 부여받으며 이 주소로 들어오는 통신을 처리한다.
서비스의 역할을 쉽게 말하면 로드밸런서이다.
내부적으로는 여러개의 파드가 있어도 밖에서는 하나의 IP주소(Cluster IP)만 볼 수 있으며, 이 주소로 접근하면 서비스가 통신을 적절히 분배해주는 구조다.
서비스가 분배하는 통신은 1개의 워커 노드 안으로 국한된다.
여러 워커 노드 간 분배는 실제로 로드밸런서나 인그레스가 담당한다.
로드밸런서는 별도의 노드나 물리적 전용 하드웨어로 구성한다.
동일한 구성의 pod 는 여러 워커노드에 걸쳐 배포가 가능하고 하나의 서비스로도 관리 가능하다.
레플리카세트는 파드 수를 관리하는 반장이다.
파드는 서비스, 레플리카세트라는 두 반장에 의해 관리된다.
레플리카세트가 관리하는 동일한 구성의 파드를 레플리카라고도 부른다.
레플리카세트 원하는대로 다루기 어려워 디플로이먼트와 함께 쓰일 때가 많다.
디플로이먼트는 배포를 관리하는 요소로 파드가 가용하는 이미지 등 파드에 대한 정보를 갖고 있다.
디플로이먼트가 레플리카보다 상사다.
AWS EKS 는 마스터노드에 해당하는 서비스다.
워커노드는 EC2 나 Fargate로 생성된다.
- 도커데스크톱에 kubenetes 옵션 선택해 사용 가능하다. etcd, CNI 가 포함되어 있다.
- 리눅스에서는 minikube 로 학습이 가능하다.
*실제로 여러 물리서버에 클러스터 구축을 할 때 kubeadm 도구로 CNI etcd 쉽게 설치 가능하다.
kubeadm join 으로 워커노드를 마스터노드에 연결할 수 있다,
매니페스트 파일은 도커 컴포즈와 달리 이름이 지정돼있지 않다. 리소스 단위로 작성한다.
초보가 주로 작성하는 매니페스트는 아래 두 가지이다.
- 디플로이먼트 : 레플리카세트와 파드가 포함돼있음
- 서비스
컴포즈파일과 마찬가지로 주 항목이 있다. apiversion(core/v1,apps/v1), kind(리소스종류), metadata, spec (리소스내용)
메타데이터는 키-값의 형태로 설정한다.
메타데이터에 리소스 이름이나 레이블을 기재할 수 있다.
namespace 는 리소스 세분화한 DNS 호환 테이블 역할을 한다.
회원 등급별로 다른 pod 로 운영하고자할 때, 리소스 레이블로 파드를 지정할 수 있다.
서비스::
type: 서비스 유형
ports :
- port: 서비스의 포트
targetport: 컨테이너 포트
protocol: 통신에 사용하는 프로토콜
nodeport: 워커노드의 포트
type : 외부로부터 서비스에 어떤 유형의 IP 주소 (혹은 DNS) 로 접근할지 설정
1. Cluster IP: 외부에서는 접근불가, 클러스터 IP 로 서비스에 접근함
2. NodePort: 워커노드의 IP 를 통해 서비스에 접근하도록 함 (개발 목적)
3. LoadBalancer: 사용자 웹 접근, 로드밸런서 IP 로 서비스에 접근
4. External Name: 파드에서 서비스를 통해 외부로 나가기 위한 설정
실습 시 로드밸런서가 없으므로, 노드포트로 많이 한다.
디플로이먼트와 서비스 둘 다 matchLabels 라는 설정이 있는 동작방식이 달라 유의해야한다.
디플로이먼트에서는 '이 조건이 부합하는 경우' 같은 설정이 가능하다, 서비스에서는 불가능하므로 사용하지 않는 것이 좋다.
반응형