안녕하세요. 킷도우입니다.
지난 번 AWS SAA 자격증 합격의 기세를 몰아서 이번엔 CKA 자격증을 취득해 보고자합니다.
자격증 준비하면서 개념 정리한 내용들을 공유드려봅니다.
CKA 강의로 유명한 Udemy CKA with practice tests의 내용을 참고한 것입니다.
개념 설명이 매우 상세히 잘 돼있어 단순 자격증 취득 목적을 넘어 스킬 향상에도 많은 도움이 되는 것을 느낍니다.
거두절미하고 바로 개념 정리 들어갑니다.
Kubernetes Cluster Architecture
- Master Node
*컨테이너를 적재하는 주체로써 컨테이너의 위치를 감시, 추적 등의 전적인 적재 과정을 총괄
*ETCD 클러스터(고가용 key-value store) : 어떤 워커 노드에 컨테이너가 저장돼 있는지 등의 쿠버네티스 클러스터 전반적인 정보들이 이 여기에 저장된다.
*Kube Scheduler : 어떤 워커 노드에 컨테이너를 실을 지, 워커 노드의 용량 혹은 다른 정책, 제약 조건들이 있는지 파악
*Node Controller : 노드를 관리한다. 새 노드를 클러스터에 온보딩하고 노드가 사용 불가능하거나 파괴되는 상황을 처리
*Replication Controller : 원하는 컨테이너 수가 복제 그룹에서 항상 실행되도록 보장한다.
*Kube apiserver : 클러스터 내에서 모든 작업을 오케스트레이션한다. 위 요소들을 모두 연결하는 높은 수준의 관리자
- Worker Node
* 컨테이너를 실질적으로 적재하는 곳
* Kubelet : 각 노드에서 실행되는 에이전트로 워커 노드의 선장 역할. Kube apiserver의 지시를 듣고 필요한대로 노드에서 컨테이너를 배포하거나 파괴한다.
* Kube Proxy : 한 노드의 한 컨테이너에서 웹 서버가 실행되고 다른 노드의 다른 컨테이너는 DB를 실행한다고 했을 때 웹 서버는 DB에 도달 가능해야 하고 이를 돞는 서비스
- Container Runtime Engine
* 컨테이너를 실행시킬 수 있는 엔진. Docker가 가장 유명하다.
* 도커가 모든 노드에 설치 돼 있다.
* containerd 나 rocket 도 있으나, docker가 가장 많이 쓰임
* CRI : Container Runtime Interface라고 해서 어떤 런타임 업체든 쿠버네티스 클러스터에서 작업하게 지원해준다. 단 OCI(Open Container Initiative) 표준을 준수해야한다. rocket, contaienrd는 이를 준수하여 쿠버네티스를 쓸 수 있는 런타임 엔진이다. but, docker는 CRI 를 준수하기 위해 만들어지지 않았고, 쿠버네티스 전부터 만들어진 서비스로 쿠버네티스는 dockershim을 만들어 CRI 밖에서 Docker를 지속적으로 지원하는 임시 방편을 만들었다. but 현재는 쿠버네티스 v1.24를 승인하면서 Docker 자체는 쿠버네티스 지원 런타임에서 제거됐다.(dockershim이 유지보수 문제가 점점 커졋기 때문)
ETCD
분산되고 신뢰할 수 있는 key-value 스토어로 안전하며 신속하다.
- key value store
.전통적으로 데이터베이스는 테이블 형식이다. 관계형 데이터베이스가 대표적이다. but 테이블로 관리하면 새로운 컬럼을 추가함에 따라 모든 행이 영향을 받고 그에 따라 빈 공간들 불필요하게 생긴다. key-value 형태로 저장하면 개인데 대한 정보는 각 개인은 문서를 하나 갖고, 그 개인에 관한 모든 정보가 해당 파일에 저장된다. 이런 파일은 어떤 형식이나 구조로든 될 수 있고, 한 파일의 변화는 다른 파일에 영향을 주지 않는다. 보통 파일 형식으로 JSON이나 Yaml을 사용한다.
- ETCD in kubernetes
*쿠버네티스 클러스터에 대한 정보를 저장한다. Nodes, pods, configs, secrets, Accounts, Roles, Bindings 등
*kubectl 을 실행할 때 얻게 되는 모든 정보는 ETCD 서버에서 가져온다.
*클러스터에 변화를 줄 때 가령 노드를 추가하거나 파드를 배포할 때 replicaset 추가나 모든 update는 etcd 서버에 저장됨.
* ETCD에 업데이트될 때 작업이 완료된 것으로 간주
*클러스터를 어떻게 설정하냐에 따라 ETCD는 다양하게 배포된다.
Kube apiserver
*kubectl 명령어 쓸 때 kube-apiserver에 요청이 도달
*kube apiserver는 요청이 들어오면 첫 째로 user 인증 및 유효성 검사를 한다. 그 후 ETCD CLUSTER에서 데이터를 회수해 요청된 정보로 응답한다. kubectl 명령어를 사용하지 않고도 POST 형식의 URL 데이터 요청으로 kube apiserver에 요청할 수 있다.
* 파드의 생성 과정
1. 사용자가 파드를 생성해 달라고 kubectl 또는 curl 명령어를 활용해 요청을 한다.
2. kube apiserver는 먼저 사용자를 인증하고 유효성 검사를 한다.
3. 이 때 바로 파드가 생성되고 워커 노드에 할당되지 않는다. 파드 개체가 생성된다. 이는 어느 노드에도 할당되지 않은 것이다.
4. ETCD에 해당 파드 정보를 업데이트하고 파드가 생성됐다고 사용자에게 알린다.
5. kube-scheduler는 지속적으로 apiserver를 모니터링하고 노드를 할당받지 못한 파드가 있다는 것을 인지한다.
6. kube scheduler는 올바른 노드를 식별해 파드를 할당하도록 새 파드를 켜고 다시 kube apiserver와 통신한다.
7. apiserver는 해당 정보를 etcd와 통신하여 업데이트한다. 그리고 워커 노드의 kublet에게 전달한다.
8. kubelet은 파드를 생성하고 컨테이너 런타임 엔진에 지시해 앱 이미지를 배포합니다.
9. 완료되면 다시 apiserver에 해당 정보를 업데이트하고 apiserver는 해당 정보를 etcd 클러스터에 업데이트합니다.
Kube Controller Manager
다양한 컨트롤러를 관리한다.(마스터 노드의 사무실이다)
- Node Controller
*노드의 상태를 모니터링하고, 응용 프로그램이 계속 실행되도록 필요한 행동을 한다. By Kube apiserver
*Node Monitor Period는 5초 간격이다.
*Node Monitor Grace Period(유예기간)는 40초이다. 즉 5초 간격으로 노드의 상태를 계속 체크하지만 Unreachable로 마킹하여 표시하는데 40초가 걸리는 것. 다시 재생할 수 있으니 40초까지 기다려준다는 의미아닐까 싶다.
*Pod Eviction Timeout(퇴거 시간 초과) 5분 -> 죽은 파드가 다시 올라오는데 걸리는 시간으로 만약 5분이 지나도 노드가 올라오지 않으면 겅간한 상태의 노드로 프로비저닝된다.
- Replication Controller
*복제품 세트의 상태를 모니터링하고 원하는 수의 파드가 replicaset 내에서 항상 사용 가능하도록 한다.
* 하드가 죽으면 다른 파드가 살아난다.
- 기타
*이 외에도 많은 컨트롤러 들이 존재한다. Deployment Controller, Namespace Controller, Endpoint Controller 등등 이 모든 Controller 들이 Kube-Controller-Manager에 패키징화 돼있다.
Kube Scheduler
* 노드 파드의 일정 관리를 책임진다.
* kube scheduler는 어느 파드가 어느 노드에 들어갈지만 결정한다.
*파드를 노드에 위치시키는 것은 kubelet의 일이다.
*kube scheduler는 오직 어떤 파드를 어떤 노드에 넣을지만을 결정한다.
*kube scheduler가 필요한 이유는 수 많은 노드와 파드 중에서 파드를 적재적소에 위치시켜야하기에 필요한 것이다.
*여기서 적재적소라 함은 노드에 파드를 수용할 사이즈가 충분히 있는지 검토하는 것 등을 의미한다.
*scheduler는 가장 최적의 노드에 파드를 위치시키도록 적합한 것을 계속 찾는다. by filtering 로직
*filter에는 resource filter가 있고 cpu, ram을 보고 부적합한 파드를 거른다. 이 외 여러 필터가 있다.
Kubelet
* 워커 노드의 선장 역할이자 마스터 노드가 연락할 수 있는 유일한 통로
* 워커 노드에 파드를 위치 시킨다.
* 워커 노드의 상태와 파드의 상태를 일정 간격으로 평가하고 kube apiserver에 보고한다.
Kube proxy
* kubernetes cluster에서는 모든 파드가 다 서로 통신할 수 있다.
* 파드 네트워킹 솔루션을 클러스터에 배포했기 때문이다.
* 파드 네트워크는 내부 가상 네트워크로 모든 파드가 연결되는 클러스터 내 모든 노드에 걸쳐 있다.
* 이 네트워크를 통해 서로 통신할 수 있다.
* 한 쪽은 웹, 한 쪽 노드엔 DB가 배포됐다고 가정하자. 이 웹은 서버의 IP를 활용해 DB에 도달할 수 있다. 하지만 DB 파드의 수가 늘어나면 그 IP가 같을거라는 보장은 없다. 따라서 DB에 접근하기 위해서는 SERVICE를 이용한다. 클러스터에 걸처 응용 프로그램을 노출할 서비스를 생성한다. 그럼 웹 어플리케이션은 서비스 이름이 DB인 것을 찾아 액세스 할 수 있는 것이다. 이 서비스는 파드 네트워크에 join할 수 없다. 이 서비스는 autual thing이 아니다. 파드같은 컨테이너가 아니고, 인터페이스도 없고, 듣는 프로세스도 없다. 단지 쿠버네티스 메모리에만 존재하는 가상 구성 요소이다. 그러나 이 서비스는 또한 클러스터를 가로질러 어떤 노드에서도 접근 가능해야 한다. 이게 어떻게 가능할까? 바로 이래서 Kube Proxy가 필요한 것이다. Kube Proxy는 쿠버네티스 클러스터의 각 노드에서 실행되는 프로세스이다. 이것이 바로 새 서비스를 찾아주는 역할을 한다. 새 서비스가 생성될 때 마다 각 노드에 적절한 규칙을 만들어 그 서비스로 트래픽을 전달한다. 백엔드 포드로 말이다. (여기선 DB) 한 가지 방법은 iptables 규칙을 이용하는 것이다. 클러스터의 각 노드에 iptables 규칙을 만들어 서비스의 IP로 향하는 트래픽을 향하게 합니다.
2탄도 기대해주세요.
★킷도우 웹 개발 기초 강의가 오픈됐습니다!
궁금하신 분들은 아래 링크를 참고해 주세요~
킷도우의 첫 강의! - 웹 개발 기초 (프론트엔드, 백엔드, DB까지 총 10시간에 걸쳐 주문 게시판 만
안녕하세요. IT Window 킷도우입니다. 드디어 고대하고 고대하던 웹 개발 강의를 완성했습니다. VOD(동영상)는 인프런에서만!(전자책 포함) https://inf.run/BqmE 실무 환경 그대로 주문게시판 만들기 웹
kitdow.tistory.com
감사합니다!
댓글