쿠버네티스 공식문서 파헤치기 : 개요

https://kubernetes.io/ko/

운영 수준의 컨테이너 오케스트레이션

 

이 문서는 제가 쿠버네티스 공식문서를 혼자 보고 공부하는 곳입니다!

 

 

쿠버네티스가 무엇인가

쿠버네티스에서 컨테이너는 어플리케이션을 포장하고 실행하는 아주 좋은 방법이다.
컨테이너가 다운이 되면 다른 컨테이너를 다시 시작을 해야한다. 이 문제를 시스템에 의해 처리를 한다면
더 쉽지 않을까 하는 생각에서 만들어진 툴

 

---

쿠버네티스 컴포넌트

쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다.
노드 컴포넌트 = kubelet, kube-proxy
컨트롤 플레인 컴포넌트 = kube-api-server, kube-scheduler, cloud-controlled manager, 
  kube-controller-manager, etcd
 

출처 : 쿠버네티스 공식 사이트

컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(스케줄링)을 수행하고,
클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우

새로운 파드를 구동시키는 것)을 감지하고 반응한다.

 

컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다.(?)

(= 노드 컴포넌트에서는 여러 대의 컴퓨터가 있는데 거기서 어디서든 동작할 수 있다 라는 뜻?)

그러나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고,

사용자 컨테이너는 해당 머신 상에 동작시키지 않는다.

---

컨트롤 플레인 컴포넌트

kube-apiserver

API의 뜻?

우리가 쿠버네티스 컨트롤 플레인을 제어할 수 있도록 도와주는 인터페이스?

라고 생각하면 된다.

etcd

모든 클러스터 데이터를 담는 저장소로

키-값으로 데이터들이 저장된다.

(쿠버네티스 뒷단의 저장소)

 

kube-scheduler

노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트

 

스케줄링을 위해서 고려되는 요소는

리소스에 대한 개별 혹은 총제적 요구 사항,

하드웨어/소프트웨어/정책적 제약,

어피니티 및 안티-어피니티 명세,

데이터 지역성,

워크로드-간 간섭,

데드라인

 

kube-controller-manager

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

 

노드 컨트롤러 (Node)

레플리케이션 컨트롤러 (Replicas)

엔드포인트 컨트롤러 (Service & pod 연결)

서비스 어카운트 & 토큰 컨트롤러 (새로운 네임스페이스에 대한 기본 계정, API 접근 토큰 생성)

 

Cloud-controller-manager

이 컨트롤 플레인 컴포넌트를 통해서

클러스터와 클라우드 공급자 API에 연결할 수 있고

우리가 사용하고자 하는 클라우드 플랫폼과 상호 작용하는 컴포넌트와

클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다.

 

노드 컨트롤러 (노드가 멈추면 클라우드 상에서도 삭제가 됐는지 판별하기 위해 제공 사업자에게 확인하는 것)

라우트 컨트롤러(클라우드 인프라에 경로 구성하는 것)

서비스 컨트롤러(클라우드 제공 사업자 로드밸런서를 생성,업데이트,삭제하는 것)

---

노드 컴포넌트

동작 중인 파드를 유지,

쿠버네티스 런타임 환경(쿠버네티스가 실행되고 있는 동안의 동작 환경)을 제공,

모든 노드 상에서 동작한다.

 

kubelet

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

* 에이전트 = 사용자의 개입 없이 주기적으로 정보를 모으거나 또는 일부 다른 서비스를 수행하는 프로그램

파드에서 컨테이너가 확실하게 동작하도록 관리하는 것!

 

kubelet은 사용자가 제공하거나 명시된 파드 스펙(podspec)을 보고

건강하게 파드가 스펙에 따라서 동작하는지 확실하게 해준다.

 

쿠버네티스를 통해 생성되지 않은 컨테이너는 신경쓰지 않는다.

 

kube-proxy

클러스터의 각 노드에서 실행되는 네트워크 프록시로, 서비스 오브젝트 개념의 구현부이다.

 

*proxy = 프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다.

 

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

내부 네트워크 세션 or 외부에서 파드로 통신을 할 수 있도록 도와준다.

 

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

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

 

컨테이너 런타임

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

 

ex) docker, containerd, CRI-O, Kubernetes CRI를 구현한 모든 소프트웨어

---

애드온

클러스터 단위로 클러스터의 기능을 구현하는 것이다.

쿠버네티스의 리소스를 활용한다. (디플로이먼트, 데몬셋 등)

 

주요 애드온들

DNS (Domain Name System)

* 도메인 네임 시스템

= 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나

그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다.

특정 컴퓨터의 주소를 찾기 위해, 사람이 이해하기 쉬운

도메인 이름을 숫자로 된 식별 번호로 변환해 준다.

 

*도메인 네임 

= 도메인 네임은 넓은 의미로는 네트워크상에서 컴퓨터를 식별하는 호스트명을 가리키며,

좁은 의미에서는 도메인 레지스트리에게서 등록된 이름을 의미한다.

이를 통틀어서 ‘웹 주소’라고 부르는 경우도 있다. 

 

클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어,

쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.

쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다.

웹 UI (Dashboard)

쿠버네티스 클러스터를 위한 웹 기반 UI이다.

사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 어플리케이션에 대한

관리, 문제해결 등을 시각화해서 도와준다.

컨테이너 리소스 모니터링

컨테이너 리소스 모니터링은 중앙 데이터베이스 내의 컨테이너들에

대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

클러스터-레벨 로깅

클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께

중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

---

쿠버네티스 API

쿠버네티스 컨트롤 플레인의 핵심은

API 서버와 그것이 노출하는 HTTP API이다.

 

*API 서버

= Kubernetes API 서버는 포드, 서비스, 복제 컨트롤러 등을 포함하는

API 개체에 대한 데이터의 유효성을 검사하고 구성합니다.

API 서버는 REST 작업을 서비스하고 다른 모든 구성 요소가

상호 작용하는 클러스터의 공유 상태에 대한 프런트 엔드를 제공합니다.

 

---

쿠버네티스 오브젝트 이해하기

오브젝트

 

쿠버네티스 시스템에서 영속성을 가지는 개체라고 생각을 하면된다.

 

클러스터의 상태를 나타내기 위해 오브젝트를 이용하는데

다음과 같은 것들을 기술할 수 있다.

 

- 어떤 컨테이너화된 어플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)

- 그 어플리케이션이 이용할 수 있는 리소스

- 그 어플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책

 

오브젝트 = 하나의 의도를 담은 레코드

 

쿠버네티스 오브젝트를 동작시키려면 쿠버네티스 API를 이용해야 한다.

 

오브젝트 명세와 상태

 

오브젝트의 구성을 결정해주는 오브젝트 spec과 오브젝트 status에 관한 얘기이다.

 

status는 오브젝트의 현재 상태를 설명한다.

(쿠버네티스 시스템과 컴포넌트에 의해 제공된다.)

 

쿠버네티스 컨트롤 플레인은 모든 오브젝트의

실제 상태를 우리가 정의한 바라는 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다.

 

오브젝트 기술하기

 

우리가 오브젝트를 생성할 때, 오브젝트에 대한 기본적인 정보(이름과 같은)것과

우리가 원하는 상태를 spec에 기술해 주어야 한다.

 

오브젝트를 생성할 때는

직접 or kubectl을 통해서 생성할 수 있고,

쿠버네티스 API를 사용할 때는 API요청은 JSON 형식으로 정보를 포함하는데

보통 .yaml 파일로 kubectl에게 제공하는 것이 보통이다.

 

---

쿠버네티스 오브젝트 이름과 ID

클러스터의 각 오브젝트는 고유한 이름과 전체 클러스터에 걸쳐 고유한 UID를 가지고 있다.

 

*UID = 고유 아이디 (주민등록번호 같은 느낌)

 

이름이 APP 이라면 같은 pod에서는 APP이 하나만 존재할 수 있지만

deployment나, service를 APP으로 하고싶다면 생성이 가능하다.

(해당 유형의 리소스에 대해서 고유하다)

 

네임스페이스는 pod, deployment, service 등등 리소스에 대해서

따로 존재를 하고있고, 네임스페이스에서는 이름이 하나밖에

존재를 하지 못하지만 다른 네임스페이스끼리는 같은 이름이 존재 할 수 있다.

 

---

레이블과 셀렉터

레이블

Key - Value 쌍

이름을 부여하는 느낌으로 사용하지, 서비스에 직접적인 영향은 없다.

 

레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 

즉 파드를 생성할 때 필요한 컨테이너가 여러 개라면

컨테이너들에 레이블을 붙여 한꺼번에 정의를 할 수 있다.

 

Key값은 고유해야 한다.

---

 셀렉터

이름이나 UID와 다르게 레이블은 고유하지 않기 때문에,

여러 개가 존재 할 것이라는 것을 예상할 수 있다.

 

그래서 쿠버네티스에서는 셀렉터를 제공해서

쉽게 레이블을 가지고 있는 오브젝트를 찾을 수 있게 하였다.

 

셀렉터는 두 가지의 셀렉터 종류를 지원하는데

일치성 기준 혹은 집합성 기준이라는 두 종류의 셀렉터를 지원한다.

 

일치성 기준

 

= , == , != 와 같은 연산자를 사용해서

Key, Value를 파악해서 일치하는지 혹은 불일치하는지 확인하는 셀렉터이다.

 

예시로 파드가 노드를 선택할 때

이 파드는 

accelerator라는 key값을 가지고

nvidia-tesla-p100 이라는 value값을 가지는 node를 선택한다.

 

집합성 기준

 

in, notin, exists(key만 해당)의 3개의 연산자를 사용한다.

 

첫 번째 예시에서 키가 environment이고, 값이 production 혹은 qa인 모든 리소스를 선택하는 것이다.

두 번째 예시에서는 키가 tier이고 값이 frontend 혹은 backend인 값을 제외한 모든 리소스를 선택한다.

세 번째 예시에서는 키가 partition인 모든 리소스를 선택한다.

네 번째 예시에서는 키가 partition이 아닌 모든 리소스를 선택한다.

 

일치성 기준과 집합성 기준은 섞어서 사용할 수 있다.

 

---

어노테이션

임의의 비-식별 메타데이터를 오브젝트에 첨부할 때 사용하는 것이 어노테이션 이다.

 

어노테이션은 오브젝트를 식별하고 선택하는데 사용되는 것이 아니다.

 

추가적인 정보를 나타내고 싶을 때

key-value형식으로 추가 정보를 입력해준다.

 

---

필드 셀렉터

필드 셀렉터는 리소스 필터이다.

한 개 이상의 리소스 필드 값에 따라 리소스를 선택하기 위해 사용되는 것이 필드 셀렉터 이다.

 

= , ==, != 와 같은 연산자를 사용한다.

$ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다.