[Kubernetes] 쿠버네티스의 기본 구조와 개념

핵심 개념

쿠버네티스의 핵심 개념을 한 줄로 표현하자면, 계속해서 원하는 상태를 만들기 위해 현재 상태를 바꾸는 플랫폼입니다. 예를 들어 내가 원하는 컨테이너를 쿠버네티스에 알려주면 (Desired State) 쿠버네티스는 계속해서 Current State(현재상태) 를 체크합니다. 단순히 컨테이너 뿐만 아니라 네임스페이스나 네트워크, 스토리지 같은 부분도 동일하게 동작합니다.

 

 

---

마스터와 노드

쿠버네티스는 가장 먼저 클러스터 구조를 이해할 필요가 있습니다. 클러스터는 여러 대의 컴퓨터가 모여서 같은 목적으로 수행되는 컴퓨터들의 집합이라고 볼 수 있는데, 이때 클러스터 전체를 관리하는 컨트롤러로서 마스터가 존재하고, 컨테이너가 배포되는 물리적인 머신을 노드라고 하게 됩니다.

 

 

 

마스터에는 kube-api-server, kube-controller-manager, kube-scheduler, cloud-controller-manager, etcd 등의 컴포넌트가 실행됩니다. 상세한 내용은 아래와 같습니다.

 

Master

kube-apiserver

kube-apiserver는 쿠버네티스 클러스터의 api를 사용할 수 있도록 하는 컨트롤 플레인 컴포넌트 입니다. 즉 api 서버는 쿠버네티스 프론트 엔드로서 클러스터로 온 요청이 유효한지 검증하고, api서버를 통해 다른 컴포넌트가 서로 필요한 정보를 주고받게 됩니다. 특히 etcd에는 api 서버만 접근할 수 있습니다.

 

etcd

etcd는 쿠버네티스에서 필요한 모든 데이터를 키-값 형태로 저장하는 저장하는 데이터베이스 역할을 합니다. etcd는 서버 하나당 프로세스 1개만 사용할 수 있는데, 보통 etcd 자체를 클러스터링 한 후 여러 개 마스터 서버에 분산해서 실행해 안정성을 보장하도록 합니다.

 

kube-scheduler

현재 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택해서 새로운 파드를 실행해주는 역할을 합니다. 처음 파드가 실행될 때 최소 할당되어야 하는 ram과 같은 설정들을 할 수 있는데, 이러한 조건에 맞추어 알맞은 노드에 파드를 실행시켜주는 자동화 작업해주게 됩니다.

 

kube-controller-manager

쿠버네티스의 파드들을 관리하는 컨트롤러입니다. 컨트롤러 각각은 논리적으로 개별 프로세스지만 복잡도를 줄이려고 모든 컨트롤러를 바이너리 파일로 컴파일해서 단일 프로세스로 실행합니다.

 

cloud-controller-manager

cloud-controller-manager는 쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해서 관리하는 컴포넌트입니다.

 

 

노드용으로 실행되는 컴포넌트는 kubelet, kube-proxy, 컨테이너 런타임이 있습니다.

 

Node

kubelet

kubelet은 클러스터 안 모든 노드에서 실행되는 에이전트입니다. 파드스펙(PodSpec) 설정을 전달받아서 파드 컨테이너의 실행을 직접적으로 관리하고 해당 컨테이너가 정상적으로 실행되는지 헬스 체크를 진행합니다.

단, 노드 안에 있는 컨테이너라도 쿠버네티스를 통해서 만들어지지 않은 컨테이너는 관리하지 않습니다.

 

kube-proxy

쿠버네티스는 클러스터 안에서 별도의 가상 네트워크를 생성하고 관리하게 되는데, kube-proxy는 이런 가상 네트워크의 동작을 관리하는 컴포넌트입니다.

 

컨테이너 런타임

실제로 컨테이너를 실행시키는 컴포넌트입니다. 가장 많이 사용하는 런타임으로 Docker를 주로 사용합니다.

 

---

오브젝트

쿠버네티스를 이해하기 위해 가장 중요한 부분이 오브젝트입니다. 가장 기본적인 구성단위가 되는 기본 오브젝트와(Basic Object)와, 기본 오브젝트를 생성하고 관리하는 추가적인 기능을 가진 컨트롤러(Controller)로 이루어집니다. 그리고 이러한 오브젝트의 스펙(설정)이외에 메타 정보들로 구성이 되게 됩니다.

 

오브젝트 스펙

오브젝트들은 모두 오브젝트의 특성을 기술한 오브젝트 스펙으로 기술됩니다. 오브젝트 스펙을 기술하기 위해서는 cli를 이용해 직접 명령어를 실행시키거나, yaml 파일이나 json과 같은 템플릿 형식으로 오브젝트 스펙을 정의할 수 있습니다.

 

※ 최근에는 거의 yaml파일을 이용해 기술하고 있습니다.

 

 

기본 오브젝트(Basic Object)

쿠버네티스에 의해 배포 및 관리되는 가장 기본적인 오브젝트로 Pod, Service Volume, Namespace 4가지가 있습니다.

 

---

Namespace

네임스페이스는 하나의 쿠버네티스 클러스터 안의 논리적인 구분 단위입니다. pod나 service 등은 네임 스페이스 별로 생성이나 관리될 수 있고, 사용자의 권한 역시 네임 스페이스 별로 나눠서 부여할 수 있습니다.

 

예를 들어 하나의 클러스터 내에 개발 / 운영 / 테스트 환경과 같이 3개의 네임 스페이스로 나눠서 각각의 네임스페이스를 논리적으로 독립해서 운영할 수 있게 됩니다. 주의할 점은 방금 언급한 대로 논리적인 분리한 것이기 때문에 다른 네임스페이스간의 pod끼리도 통신이 가능하게 됩니다.

 

따라서 높은 수준의 분리 정책을 원할 경우에는 클러스터 자체를 분리하는 것을 권장합니다.

 

---

템플릿

쿠버네티스 클러스터의 오브젝트나 컨트롤러가 어떤 상태여야 하는지를 적용할 때 YAML 형식의 템플릿을 사용합니다. YAML은 문법이 간결하고 주석도 지원하기 때문에 가독성이 좋습니다.

 

YAML은 기본적으로 3가지 형식이 있는데, 가장 단순한 형태로는 Scalars가 있습니다. key-value로 이루어진 형식으로 stirng값과 number 값을 value로 가집니다

Name: ooeunz
Url: ooeunz.tistory.com
since: 2019

 

다음은 배열 형태를 저장하는 Sequences로 -를 이용해서 표현합니다.

Skills:
    - java
    - docker
    - kubernetes

 

마지막으로 value 값에 또 다른 key-value 형태의 해쉬맵이 들어가는 Mappings입니다.

Desk:
    Height: 170
    Width: 100

 

이외에도 주석은 #으로 표현하고, ---를 이용해서 구분자를 사용할 수 있습니다.

그럼 실제 템플릿의 기본 형식을 살펴보겠습니다.

apiVersion: v1
kind: Pod
metadate:
spec:

가장 기본적인 4개의 필드로 템플릿을 구성해 보았습니다. 위에서부터 하나씩 살펴보도록 하겠습니다.

• apiVersion: 사용하려는 쿠버네티스의 api 버전을 명시합니다. kubectl api-versions 명령어로 사용 가능한 버전 목록을 확인할 수 있습니다.
• kind: 어떤 종류의 오브젝트 또는 컨트롤러의 작업인지 명시합니다.
• metadata: 메타데이터를 설정합니다.
• spec: 파드가 어떤 컨테이너를 가지고 어떻게 동작할지를 명시합니다.

.spec과 .metadata는 각각 하위에 다양한 필드를 가지고 있습니다. kubectl explain 명령어를 이용해 하위 필드에 대한 내용과 역할을 살펴볼 수 있습니다. 그 예시는 아래와 같습니다.

 

kubectl explain pods : pods의 하위 필드와 설명

kubectl explain pods.metadata : pods의 하위 필더인 metadata의 하위 필드와 설명

kubectl explain pods --recurisive : 해당 필드에 포함된 모든 하위 필드를 한 번에 보기

 

 

다음 포스팅부터는 Basic Object를 하나씩 하나씩 살펴보도록 하겠습니다.