kubernetes 동작 원리

Kubernetes 동작 원리에 대하여 설명한다. 

 

1. 쿠버네티스 동작

• 사용자가 Docker Push 하여 Docker Machine에서 Docker Hub Site에 image 올린다.
  • Docker Hub Site가 아니여도 Local repository로 구성을 하여도 된다.
• Hub Site에 있는 docker image를 사용하여 kubctl 사용 POD를 생성 한다.
  • POD 생성 사용자 요청이 오면 Master API Server로 전달이 되고 API Server는 Docker 에게 
    사용자가 요청한 컨테이너를 생성해 달라고 Docker 에게 전달 한다.
  • Docker는 kubelet에서 전달 받은 받고 hub/local repository에서 docker imager를 가지고 컨테이너를 생성 한다.

 

2. 쿠버네티스 컨포넌트

Kubernetes 구성 요소들에 대하여 살펴 본다.

• 마스터 컴포넌트
  • etcd
    • key-value 타입의 저장소
  • kube-apiserver
    • k8s API를 사용하도록 요청을 받고 요청이 유효한지 검사
  • kube-scheduler
    • 파드를 실행할 노드 선택
  • kube-controller-manager
    • 파드를 관찰하며 개수를 보장
• 워커 노드 컴포넌트
  • kubelet
    • 모든 노드에서 실행되는 k8s 에이전트
    • 데몬 형태로 동작
  • kube-proxy
    • k8s의 network 동작을 관리
    • iptables rule을 구성
  • 컨테이너 런타임
    • 컨테이너를 실행하는 엔진
    • docker, containerd, runc

3. Kubernetes Architecture

3-1) API

• kubectl create 
• Api 요청 사항

3-2) etcd

• key:value 로 구성 되어 있는 저장소이다.
• worker node들에 대한 상태 정보를 가지고 있다.  (컨테이너 상태, 이미지 상태)

참고 : node에서 kubelet에는 cadvisor라고 모니터링 processor가 kubelet 설치시 damon에 포함 되어 있어 상태를
수시로 master에 보내고 Master Node에서는 etcd에 저장을 한다.

 

3-3) 사용자 요청

step1. master scheduler에게 요청

  etcd의 정보를 참고 하여 해당 node에서 pod를 생성해 줄래 요청 한다.

step2. node1의 kubelte에 요청

step3. kubelet는 docker에게 컨테이너 생성 요청

 

3-4) kuber-proxy

network 관련 부분을 처리 한다.

 

4. 애드온

추가로 구성 할 수있는 API (CNI는 kubernetes 설치 시 기본으로 설치 되어 있다.) 얘기 한다.

 

• 네트워크 애드온
  • CNI - weave, calico, flaneld, kube-route
• dns 애드온
  • coreDNS
• 대시보드 애드온
• 컨테이너 자원 모니터링
  • cAdvisor
• 클러스터 로깅
  • 컨테이너 로그, k8s 운영 로그들을 수집해서 중앙화
  • ELK(ElasticSearch, Logstash, Kibana), EFK(ElasticSearch, Fluentd, Kibana), DataDog
    (Web UI ELK 하나로 묶어서 제공)

: 대시보드 와 클러스터 로깅은 기본으로 설치 되어 있지 않다.

 

5. kubernets 1.20부터 docker 사용 중단

kubernetes 1.20 부터 docker 사용을 중단하게 되었다. (2020년 이후 버젼부터) 이에 대한 문제점 및 대처 방안을 검토해 본다. 

 

5-1) 이슈

kubernetes 1.20 이전에는 container이너 생성 시docker에게 전달하여 사용 요청을 하였는데 이제는 자체 적으로
docker을 이용하지 않고 container를 생성하게 되었다. 이에 기존 kuberctl 사용하여 pod에 container을 생성하게
되면 docker images, docker ps 사용 해당 컨테이너 항목을 보거나 삭제 관리를 할 수 있었는데 kubernetes 1.20
이후 부터를 사용 할 수 없게 되었다. 

 

5-2) 지원 중단 의미

쿠버네티스는 컨테이너 런타임으로 Docker 사용 하고 있었따. 하지만 kubernetes 1.20v 부터 Docker 지원을 중단
하게 되었다.  kubernets는 컨테이너 런타임과 통신할 때 CRI라는 표준 인터페이스를 사용하는데 Docker에서는
이를 지원 하지 않아 호환성 문제가 있었고 docker가 범용적으로 쓰고 있었기에 kubernetes에서는 Docker 와 Kubernetes
잇는 도커심(dockershim)를 사용 하여 RunTime 호출을 사용 하고 있었다. dockersim이 문제가 많고 관리 하기가
힘들어 dockershim을 제거 docker을 이용하지 않고 cri-containered 사용 container 생성 하는 구조로 변경 하였다. 

 

docker use / docker unuse

 

도커심 때문에 배포 속도가 느려지고 유지 관리자에게도 큰 부담을 안겨줬기 때문이죠. 근본적으로 ‘임시 방편’이었던 만큼 한계도 많았던 부분이 있어 이를 제거 하게 되었다고 한다. 

 

5-3) 쿠버네티스 RunTime cri 뭐를 사용 하지. (CRI (Container Runtime Interface))

그냥 컨테이너 런타임을 도커심을 통하지 않고 CRI를 준수하는 다른 컨테이너라 바꾸면 된다. cri 런타임 대체로는
“containerd”며 “CRI-O” 두가지 정도가 있는 것으로 보이고 새로 설치 시에는 cri-o(cri-tool)이 자동으로 생성이 되어
문제가 없고 기존에 docker를 사용한다면 upgrade가 필요 하다.

• 런타임 전환 방법
  link : https://velog.io/@whereisdw/kubernetes-k8s-1.24%EC%97%90%EC%84%9C-container-%EB%9F%B0%ED%83%80%EC%9E%84-%EB%B3%80%EA%B2%BD-%EB%B0%A9%EB%B2%95

 

5-4) docker는 버려야 하나.

아니다 docker image 자체는 ock(open container Initiative)와 호환되는 이미지기 때문에 여전히 image을 만들거나
배포하거나 생성 할 때 사용하면 된다. 다만 kubernetes에서의 container 생성 관련 run-time시에 docker을 사용하지
않는다는 의미로만 받아 들이면 될 거 같다. 

 

5-5) 참고 Link

link : https://www.openmaru.io/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%99%80-%EB%8F%84%EC%BB%A4/

link : https://fastcampus.co.kr/story_article_kubernetes