구성요소 원리

Ryu·2021년 12월 14일

Kubernetes

목록 보기

1/9

쿠버네티스 구성요소

Control Plane / Master node

etcd = 데이터 베이스
api-server = 사용자 인증, 관리 등 전체적인 관리
controller = 다양한 controller
scheduler

Worker node

kubelet = register node, monitor node&pod 등
kube-proxy

쿠버네티스 시스템 구성요소는 오로지 api-server하고만 통신

kube-apiserver

API(Application Programming Interface)란
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램 간 상호작용을 촉진하며, 서로 정보를 교환 가능 하도록 하는 것

kube-apiserver = REST API Server
kube-apiserver는 사용자 인증, 관리 등 전체적인 클러스터에 요청을 받는 중요한 역할을 수행 (etcd에 저장)
kube-apiserver는 복잡한 컴포넌트가 아닌 흔히 사용하고 있는 REST API Server이며, 주로 kubectl CLI툴을 이용하여 클러스터에 요청을 수행
ko.wikipedia.org/wiki/REST

API Server 동작 방식

클라이언트 인증 - 인증 플러그인
- API 서버는 하나 이상의 플러그인에 의해 클라이언트 인증 수행
- HTTP 요청을 검사해 수행 - 인증 방법에 따라 인증서 혹은 HTTP 헤더에서 정보를 수집
- 플러그인은 클라이언트 사용자 정보를 추출하고 이 데이터는 인가 단계에서 사용
클라이언트 인가 - 인가 플러그인
- API 서버는 요청한 작업이 요청한 리소스를 대상으로 수행할 수 있는지를 판별
요청된 리소스 확인 및 수정 - Admission Controllers 플러그인
- 리소스 생성, 수정, 삭제 시 해당 요청은 Admission Controllers로 전송
- 누락된 필드를 초기값으로 설정 or 재정의
리소스 유효성 확인 및 저장
- API 서버는 오브젝트의 유효성을 검증 → etcd에 저장 → 클라이언트에게 응답을 반환

API Server 호출

$ kubectl cluster-info
Kubernetes control plane is running at https://10.178.0.41:26443

$ curl https://10.178.0.41:26443
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

인증 및 권한 부여

# kubeconfig 파일로부터 CA 인증서 추출
kubectl config view --minify --raw --output 'jsonpath={..cluster.certificate-authority-data}' | base64 -d > k8s-ca.cert

# --cacert 옵션으로 사용자가 명시적으로 CA 인증서 제공
curl --cacert k8s-ca.cert https://<IP>:<Port>

# JWT 토큰 추출
TOKEN=$(kubectl get secret $(kubectl get sa default -ojsonpath="{.secrets[0].name}") -ojsonpath="{.data.token}" | base64 -d)

# 권한 부여
kubectl create clusterrolebinding default-cluster-admin --clusterrole cluster-admin --serviceaccount default:default

# JWT 토큰을 헤더로 넣어서 사용자 인증
curl -k -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>

Handle

# Node list
curl -v -k -X GET -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>/api/v1/nodes

# Pod list
curl -v -k -X GET -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>/api/v1/namespaces/default/pods

# Pod delete
curl -v -k -X DELETE -H "Authorization: Bearer $TOKEN" https://<IP>:<Port>/api/v1/namespaces/default/pods/mynginx

# API에 대한 curl 호출 방법 출력
kubectl get service -v 9

etcd (HA Cluster)

key-value 형태의 분산된 데이터 저장소인 etcd는 오직 api-server와 통신

Cluster & HA Cluster

Kubernetes는 Master Node와 다수의 Worker Node로 구성
하나의 Master Node만 사용하게 될 경우 Master Node의 vm에 에러가 발생하면 Cluster는 다운
그래서 Master Node를 여러개 배치하여 HA Cluster로 구성

HA Cluster는 Master Node의 Instance(etcd, apiserver, controller, scheduler)가 각각의 Master Node에 배포

Options for HA topology

Stacked etcd topology

This topology couples the control planes and etcd members on the same nodes
하나의 Node Down 시 etcd가 2개가 되므로 정족수에 맞지 않아 고가용성에 문제가 발생??

External etcd topology

cluster와 etcd 분리 모형
Node Down 시 HA에 영향은 적지만 2배의 인스턴스가 필요
단점: This topology requires twice the number of hosts as the stacked HA topology.

etcd 클러스터화 (일관성 보장)

etcd를 클러스터로 구축하려면, etcd 인스턴스 간 통신에 필요한 포트를 열어야 한다.(클러스터 내부 통신용)
배포를 안전하게 하기 위해, etcd 인스턴스 간의 통신은 SSL을 이용하여 승인
RAFT 합의 알고리즘 사용
ko.wikipedia.org/wiki/래프트(컴퓨터과학)

※ etcd를 가지고 있는 node가 7개 초과 하면 안된다. (CSP 기준 5개 초과 X)

kube-proxy

proxy의 일반적인 역할은 connection을 통해 클라이언트와 서버의 트래픽을 전달

kube-proxy : process that runs on each node in the kubernetes cluster to look for new services and every time a new service is created, it creates the appropriate rules on each node to forward traffic to those services to the backend pods

Netfilter (Network Packet Filtering Framework)

Linux Kernel Space(관리자들이 존재하는 공간)에 위치
패킷의 생명주기를 모니터링하고 통제 및 조작할 수 있는 기능 제공 → Rule-based 패킷 처리 엔진
Tools = iptables, ip6tables, ebtables, arptables, ipset, nftables, IPVS(IP Virtual Server)
www.netfilter.org