📍 해당 글은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 듣고 정리했습니다.
신뢰할 수 있고 분산된 key-value store로, 간단하고 안전하며 신속하다.
전통적인 테이블형의 데이터베이스와 다르게 Document나 page 형태로 데이터를 저장한다.
관계형 데이터베이스에서는 새로운 데이터가 추가될 때 테이블 전체가 영향을 받아서 빈 셀, null 값이 생길 수 있다. 하지만 Key-Value Store는 형식이나 구조에 제약이 없고 한 파일의 변화가 다른 파일에 영향을 주지 않는다. 데이터가 복잡해지면 JSON이나 YAML 같은 데이터 포맷을 사용할 수 있다.
바이너리 다운로드
curl -L https//github.com/etcd-io/etcd/releases/download/v3.3.11/etcd-v3.3.11-linux-amd64.tar.gz -o etcd-v3.3.11-linux-amd64.tar.gz
압축 해제
tar xzvf etcd-v3.3.11-linux-amd64.tar.gz
ETCD Service 실행
./etcd
이렇게 실행을 마치면 2379 포트(default 값)에서 대기하던 서비스가 시작된다.
ETCD Contorl Client
라는 ETCD와 함께 제공되는 기본 클라이언트는 command line client로 이를 사용해서 Key-Value 쌍을 저장하고 검색할 수 있다.
./etcdctl set key1 value1 # 데이터 저장
./etcdctl get key1 # 데이터 검색
./etcdctl --version # etcdctl 및 Api 버전 확인
etcdctl version: 3.3.11
API version: 2 # api v2
### API v2 에서 v3로 변경하기
export ETCDCTL_ALI=3
./etcdctl version
etcdctl version: 3.3.11
API version: 3.3 # api v3
ETCDCTL
은 ETCD와 상호작용하는데 사용하는 CLI 도구이다.
ETCDCTL은 두 가지의 API 버전(v2, v3)이 있다. 버전이 다르면 이용할 수 있는 명령어가 다르다.
그 외에도 ETCDCTL이 ETCD API 서버에 인증할 수 있도록 인증서 파일의 경로를 지정해야한다. 인증서 관련 강의는 보안 섹션에서 진행한다.
# 이전 레슨의 명령어를 작동을 위하여 사용하는
# ECTD API 버전과 인증서 파일의 경로를 지정한 명령어.
kubectl exec etcd-master -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl get / --prefix --keys-only --limit=10 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key"
kubectl
명령어를 실행하면, kubectl 유틸리티는 실제로 kube-apiserver에 접근한다. kube-apiserver는 가장 먼저 요청을 인증하고 검증한다. 그 다음 etcd 클러스터로부터 데이터를 받아서 요청한 정보와 함께 응답한다.
kube-apiserver는 클러스터에서 변경을 위한 모든 작업의 중심이다. ETCD와 소통하는 유일한 컴포넌트로 scheduler, kube-controll-manager, kubelet 등 다른 컴포넌트들은 kube-apiserver를 사용하여 업데이트를 수행한다.
💡 kube-apiserver 요약
- 클러스터를 변경하기 위한 모든 작업의 중심
- 인증, 요청 검증, ETCD 데이터 읽기 및 업데이트하는 역할을 수행
- ETCD와 소통하는 유일한 컴포넌트
💡 < Pod 생성 예제 순서 요약>
1. Authenticate User
2. Validate Request
3. Retrieve data
4. Update ETCD
5. Scheduler
6. Kubelet
kubeadm
을 사용하여 세팅했다고 가정하면,
kubeadm
은 마스터 노드에 위치한 kube-system namespace
의 pod로 kubeadmin-apiserver
를 배포한다.
pod의 definition file(정의 파일)을 확인하면 옵션들을 볼 수 있다.
cat /etc/kubernetes/manifests/kube-apiserver.yaml
이때 중간 쯤에 위치한 --etcd-server
옵션은 etcd서버의 위치를 지정하는 옵션이다. kube-apiserver는 --etcd-server
옵션을 통해 etcd 서버와 연결된다.
옵션을 볼 수 있는 다른 방법으로는 마스터 노드의 프로세스를 확인하는 것이다.
ps -aux | grep kube-apiserver
다양한 컨트롤러를 관리하는 구성요소로, 시스템 내의 구성 요소들의 상태를 지속적으로 모니터링하고, 필요한 조치를 취하며 전체 시스템을 원하는 기능과 상태로 동작하게 만들어 준다.
kubeadm
은 kube-controller-manager
를 마스터 노드에 위치한 kube-system-namespace
에 파드로 배포한다. 따라서 아래 명령어로 확인할 수 있다.
kubectl get pods -n kube-system
kube-controller-manager
의 옵션은 /etc/kubernetes/manifests 폴더 안에 있는 pod 정의 파일에서 확인할 수 있다.
cat /etc/kubernetes/manifests/kube-controller-manager.yaml
다른 방법으로는 마스터 노드에 있는 프로세스를 확인하면 된다.
Scheduler는 파드의 스케줄링을 담당한다. 어떤 파드가 어떤 노드로 가야하는 지를 결정하는 것이다.
스케줄러는 파드가 배치될 노드를 결정하면, kubelet
이 실제로 배치를 담당한다.
스케줄러는 특정 기준에 따라 파드가 배치될 노드를 결정한다. cpu, memory 같은 리소스 요구 사항, taints, toleration, 선호도 규칙, 노드 셀렉터 등이 기준이 될 수 있다.
먼저 pod의 프로필(기준)에 맞지 않는 노드는 필터링한다.
그 다음 노드에 순위를 매긴다. 우선순위 함수를 사용하여 0부터 10까지의 점수를 할당한다. 예를 들어 노드의 남은 리소스 양을 계산하여 가장 리소스가 많이 남은 곳에 배치할 수 있다. 이런 기준들은 커스터마이징하여 자신만의 스케줄러를 만들 수 있다.
⚠️ Scheduler는 스케줄링을 담당할 뿐 실제로 노드에 pod를 배치하는 것은 아니다 ❗
Scheduler
는 단지 파드가 배치될 노드를 결정하고, pod를 노드에 배치하는 것은kubelet
의 역할이다.
kubeadm
은 kube-controller-manager
를 마스터 노드에 위치한 kube-system-namespace
에 파드로 배포한다. 따라서 아래 명령어로 확인할 수 있다.
kubectl get pods -n kube-system
옵션은 아래 두 가지 방법으로 가능하다.
# 1
cat /etc/kubernetes/manifests/kube-scheduler.yaml
# 2
ps -aux | grep kube-scheduler