쿠버네티스란?

https://www.redhat.com/ko/topics/containers/kubernetes-architecture

쿠버네티스 아키텍처(Kubernetes architecture) 개념 & 구성

 

 

Kubernetes의 이해

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼입니다.

쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 합니다.

쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있습니다.

쿠버네티스 서비스, 기술지원 및 도구는 어디서나 쉽게 이용할 수 있습니다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다.

구글이 2014년에 쿠버네티스 프로젝트를 오픈화 했고 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티 최고의 아이디어와 적용사례가 결합되어 있다.

 

 

도커는 이미지를 buid,push 역할을 하고 있다는 느낌적인 느낌~

쿠버네티스는 repo로부터 이미지를 pull, run(가져오고 배포하는) 역할을 하고 있다는 느낌적인 느낌~

 

 

 

 

Kubernetes 아키텍처

여기서 중요하게 볼 부분은 화살표! (방향성 때문)

Control Plane = Docker master node

각 Node = worker1, worker2, worker3

점선: csp가 가지고 있는 controller

 

주기적으로 node들이 API서버에 접속해서 사용자들이 무슨 지시를 했는지(yaml) 물어봐서 업무가 진행됨

그렇다면 control plane이 업무를 받고 가만히 있느냐? 

key:value store(KVS) = NoSQL 를 이용해서 정보를 etcd(오픈소스)라고 하는 곳에 저장을한다.

 

kube-apiserver?

API는 쿠버네티스 클러스터의 frontend 기능을 담당함.

API 서버는 REST call 형태로 클러스터 내부와 외부에서 요청을 받아 이를 처리한다.

Client는 API 서버를 통해 요청을 전송하고, node와 pod에 접속이 가능하다.

 

etcd?

etcd에는 raft 알고리즘 기반의 분산형 key-value 저장소!

클러스터의 상태와 관련된 정보드이 저장된다.

 

kube-scheduler?

워쿼워드 상태가 어떤지 물어보고 골고루 배치시켜준다.

 

kube-controller-manager?

클러스터 운영에 필요한 controller들을 모아둔 하나의 binary.

컨트롤러를 구성하는 마스터 상의 컴포넌트!

논리적으로 각 컨트롤러는 개별 프로세스지만 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고

단일 프로세스 내에서 실행된다.

워커노드들이 마스터에 접근해올 때 필요한 '토큰'이라는 것도 여기서 씀.

 

- Node controller : 노드 상태 관리(노드가 다운되었을 때 통지와 대응에 관한 책임을 가짐)

- Job controller(rplication controller;복제) : Job specification에 맞춰서 해당 작업이 실행될 수 있는 pod 생성함

(시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가짐)

- Endpoint controller: Endpoint object(Services, Pods) 생성함 (서비스와 파드 연결 시킴)

- Service Account & Token Cotroller: default accout 생성하고 namespace별로 access token 관리함

(새로운 네임스페이스에 대한 기본계정과 API 접근 토큰 생성)

cloud-controller-manager?

(로드밸런서 셋팅 및 public IP제공이 용이함)

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.

클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호작용하는 컴포넌트와 클러스터와 상호작용하는 컴포넌트를 분리할 수 있다.

Coud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다.

자신의 사내 또는 PC내부의 학습환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다.

 

내가 다루지 못하는 것 중에서 service contorller 그니까 로드밸런서를 제공해줌.

접속하기 위한 public ip나 CLB에 있는 도메인 주소를 쉽게 전세계(외부)에 전달할 수 있도록 도와준다.

큐브컨트롤러 매니저와 비슷하지만 서비스 컨트롤러를 이용해서 쉽게 외부와 접근이 가능하다는 것이 큰 차이점!

 

kube-controller-manager와 마찬가지로 cloud-controller-manager는

논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다.

수평적으로 확장(두개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.

 

- Node controller : 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인

- Route controller : 기본 클라우드 인프라에 경로를 제공

- Service controller : 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제

 

노드 안에는 이렇게 파드들이 있다.

 

쿠버네티스 클러스터는 한개 이상의 클러스터 노드로 구성된다.

클러스터 노드는 마스터 노드에 의해 관리되며 실제로 container를 실행하는 기능을 담당한다.

모든 클러스터 노드에는 Kubelet과 kubep-proxy 서비스가 실행된다.

 

노드 컴포넌트?

동작중인 파드를 유지시키고 쿠버네티스 런타임(=docker)환경을 제공하며 모든 노드 상에서 동작함

-> 보통 runtime은 software를 의미하기 때문에 docker, containered, rkt 등이 될 수 있다.

 

kubelet?

클러스터의 각 노드에서 실행되는 일종의 에이전트.

오더를 받고 확인해서 파드를 생성하고 컨테이너가 동작하도록 한다.

kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

kubelet은 다양한 매커니즘을 통해 제공된 파드스펙의 집합을 받아서

컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다.

kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

(사용자가 임의로 만든 것까지 관리하지 않는다.)

 

Kube-proxy?

라우터기능. 포워드기능. 로드밸런서 기능을 해준당

쿠버네티스 클러스터의 각 노드에서 실행되는 네트워크 프록시. 쿠버네티스의 서비스 개념의 구현부.

노드의 네트워크 규칙을 유지 및 관리한다.

이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

kube-proxy는 운영체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다.

그렇지 않으면 kube-proxy는 트래픽 자체를 포워드 한다.

시스템 파드들 내부에 있음.

 

Container runtime?

컨테이너 실행을 담당하는 일종의 소프트웨어.

kubernetes CRI(Container Runtime Interface)를 구현해야 한다.
container runtime으로 docker, containerd 등이 있다.

containerd를 runtime으로 하는 최신버전을 이용해보자.

이번에는 다운그레이드 버전인 docker runtime 1.19버전으로 실습을 할 예정.