[Kubernetes] Core Concepts 1 ( ETCD,Kube-API Server)

요즘 공부를 잘 안하는것 같아서 

Udemy의 강의를 듣고 블로그에 적어보려 한다. 이번에는 끝까지 열심히해야지 화이팅!

 

1. ETCD server

 

1. ETCD 란 무엇인가

자 이제 먼저 ETCD를 먼저 고민해보고자한다.

결론적으로 ETCD server 는 key-value 구조의 database server이다 . 

기본적으로 database는 table형태를 가지고 있지만 key-value 형태를 사용해 빠르고 읽고 쓰는 장점을 가지고 있다. 

 

2. ETCD in Kubernetes

이 etcd server는  kubeadm 을 사용하여 cluster를 세팅할 시에 pods 의 형태로 배포된다.

 

 

실제로 etcd-server의 pod의 로그를 보면 정기적으로 file을 지우고 
mvcc: store.index: compact 28068888
mvcc: finished scheduled compaction at 28068888 (took 2.03888ms)

등의 로그가 잔뜩 찍혀있다. 

 

 

우리가 kubectl get 을 사용해서 화면에 표기되는 정보는 전부 ETCD 서버에서 가져온다고 한다! 

 

실제로 서버에서 데이터를 읽고 쓰는 공간에 가보면 아래와 같은 key-value의 형태를 가진 파일이 들어있다. 

cd /var/lib/etcd/member/snap

cat 저장된snap파일에는 아래와 같은 pod의 정보 어떤 노드에 떠있는지 어떤 상태인지 등등이 적혀있다. 

 

,"value":"{\"name\":\"develop-master-001\",\"clientURLs\":[\"https://꺅내ip인걸:2379\"]}","modifiedIndex":2,"createdIndex":2}},ll,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null],"Size":4,"Front":0,"Back":4,"Capacity":1000},"StartIndex":1,"LastIndex":4}},"CurrentIndex":4,"Stats":{"getsSuccess":1987780,"getsFail":2,"setsSuccess":3,"setsFail":0,"deleteSuccess":0,"deleteFail":0,"updateSuccess":0,"updateFail":0,"createSuccess":1,"createFail":0,"compareAndSwapSuccess":0,"compareAndSwapFail":0,"compareAndDeleteSuccess":0,"compareAndDeleteFail":0,"expireCount":0,"watchers":0},"CurrentVersion":2}

 

3. ETCD에서 저장하는 정보

이밖에도 ETCD에 저장되는 정보로는

 

• Nodes
• PODs
• Configs
• Secrets
• Acounts
• Roles
• Bindings
• Others
• pkl 인증서 정보등등이 있다.

그래서 pkl 인증서 업그레이드 등을 했는데 401이 뜬다면 etcd pods를 재시작해서 시랭되는 경우도 종종 있다 .(나처럼 가령 비정상으로 kube-api 까지 모두 인증서 만료되어서 변경내용을 etcd에 자동으로 업데이트 못한경우 ㅜㅜ)

 

2. Kuba-API Server

우리가 kubectl command를 실행하면 일단 그 요청이 유효한 요청인지 검증한후 etcd server에 그 요청을 검색해서 response를 전ㄷ가하거나 실제 사용이 필요한 control-plan에게 그 요청을 전달하고 사용자에서 response를 전달합니다.

EX ) kubectl get nodes 커맨드 입력시

1. user 권한 검증
2. 유효한 requests인지 검증
3. etcd 데이터 조회
4. response 반환

EX) kubectl create -f pods.yaml

1. user 권한 검증
2. 유효한 requests인지 검증
3. data 검색
4. ETCD에 어떤 사용자가 create pods를 했다 update (아직 node할당전)
5. worker ndoe의 kubelet에 pods 생성 필요하다고요청넣기 (scheduler)
6. kubelet에서 container 띄우고 pods 생성 끝낫다고 api server에 response
7. kube-api server가 etcd에 데이터 업데이트 

• kube-api은 /etc/kubernetes/manifests/kube-apiserver.yaml 파일에 옵션이 정의되어있다.

3. Kube Controller Manager

kube controller manager의 가장 큰역할은 각종 kubernetes component(nodes, Deployment,Namespace,Endpoint,Replication ...)등을 모니터링 하고 다시 되살리는 일입니다.

EX ) 

1.   node-controller는 5초마다 Node를 감시 ( kube-apiserver를 통해 api rerquests를 날리고 response를 기다림)
2. Node가 동작하지 않게 된 경우 40초 후에 node가 상태 이상이라고 판단
3. 해당 노드위의 pod 를 전부 (Eviction)상태로 변경
4. 만약 eviction 된 pods 가 replica중 하나라면 replicaset을 모니터링하던 replication controller가 이를 감지
5. 다른 node에 eviction된 pods를 재 생성

위에 저 여러 컨트롤러는  /etc/kubernetes/manifests/kube-apiserver.yaml 

 

4. Kube Scheduler 

Kube scheduler는 여러 구성요소들을 담당하는 controller manager와는 다르게 오직 해당 pod가 어떤 node에 생성될지만 결정한다. 

kube scheduler는 해당 pods가 가지는 기준(nodeAffinity,nodeSelector 등등), 리소스 요구사항,해당 Node의 하드웨어 조건 등등 을 보고 해당 파드가 실행될 최상의 노드를 찾는다.

 

Scheduler가 노드를 선택하는 단계를보면 마치 아래의 그림과 같은 cluster 가 존재한다고 치자. 해당 cluster의 worker node 3대는 모두 같은 사양의 worker node라 가정했을때 아래와 같은 상황에서 NEW POD라는  pods 가 새로이 요청되면 kube Scheculder는 가장 적절히 배정될 수 있는 worker node를 선택한다. 

 

선택의 과정은 

1. filter node
2. /

        

 

사실 이번 게시글의 내용은 정말 간단한 기능과 concept만 정리한 것이고 위에 언급한 component 들의 option들을 한번보면 해당 구성요소들의 역할이 더욱 명확히 머리에 들어올 것이다.

해당내용도 한번 정리해보고자 하는데.... 해당 페이지에 정리하는건 너무 많은 양이 될듯하여 ㅠㅠ 다음 게시글에 정리하도록 하겠다!