핵심 개념
쿠버네티스의 핵심 개념을 한 줄로 표현하자면, 계속해서 원하는 상태를 만들기 위해 현재 상태를 바꾸는 플랫폼입니다. 예를 들어 내가 원하는 컨테이너를 쿠버네티스에 알려주면 (Desired State) 쿠버네티스는 계속해서 Current State(현재상태) 를 체크합니다. 단순히 컨테이너 뿐만 아니라 네임스페이스나 네트워크, 스토리지 같은 부분도 동일하게 동작합니다.
마스터와 노드
쿠버네티스는 가장 먼저 클러스터 구조를 이해해야 합니다. 클러스터는 여러 대의 컴퓨터가 모여서 같은 목적으로 수행되는 컴퓨터들의 집합이라고 볼 수 있는데, 이때 클러스터 전체를 관리하는 컨트롤러로 마스터가 존재하고, 컨테이너가 배포되는 물리적인 머신을 노드라고 합니다.
마스터에는 kube-api-server, kube-controller-manager, kube-scheduler, cloud-controller-manager, etcd 등의 컴포넌트가 실행됩니다.
Master
kube-apiserver
kube-apiserver는 쿠버네티스 클러스터의 api를 사용할 수 있도록 하는 control plain 컴포넌트입니다. 즉, api 서버는 쿠버네티스 프론트엔드로서 클러스터로 온 요청이 유효한지 검증하고, api 서버를 통해 다른 컴포넌트가 서로 필요한 정보를 주고 받게 됩니다. 특히 etcd에는 api서버만 접근할 수 있습니다.
etcd
etcd는 쿠버네티스에서 필요한 모든 데이터를 키-값 형태로 저장하는 데이터베이스 역할을 합니다.
etcd는 서버 하나당 프로세스 1개만 사용할 수 있는데, 보통 etcd자체를 클러스터링 한 후 여러 개 마스터 서버에 분산해서 실행해 안정성을 보장하도록 합니다.
key와 value로 저장되어서, yaml,json 형태로 볼 수 있다.
kube-scheduler
현재 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택해서 새로운 파드를 실행해주는 역할을 합니다. 처음 파드가 실행될 때 최소 할당되어야 하는 ram과 같은 설정들을 할 수 있는데, 이러한 조건에 맞추어 알맞은 노드에 파드를 실행시켜주는 자동화 작업을해주게 됩니다.
kube-controller-manager
쿠버네티스의 파드들을 관리하는 컨트롤러입니다. 컨트롤러 각각은 논리적으로 개별 개별 프로세스지만 복잡도를 줄이려고 모든 컨트롤러를 바이너라 파일로 컴파일해서 단일 프로세스로 실행합니다.
kube-controller-manager에는 파드 pod controller, replicaset-controller, demonset-controller등이 있고 여러 컨트롤러를 통해 클러스터 전반의 상태를 유지하고 관리합니다.
cloud-controller-manager
cloud-controller-manager는 쿠버네티스의 컨트롤러를 클라우드 서비스와 연결해서 관리할 수 있는 컴포넌트입니다.
노드용으로 실행되는 컴포넌트는 kubelet, kube-proxy, 컨테이너 런타임, pod가 있습니다.
Node
kubelet
kubelet은 클러스터 안 모든 노드에서 실행되는 에이전트입니다. 파드스펙(PodSpec) 설정을 전달받아서 파드 컨테이너의 실행을 직접적으로 관리하고 해당 컨테이너가 정상적으로 실행하는지 헬스 체크를 진행합니다.
단, 노드 안에 있는 컨테이너라도 쿠버네티스를 통해서 만들어지지 않은 컨테이너는 관리하지 않습니다.
kube-proxy
쿠버네티스는 클러스터 안에서 별도의 가상 네트워크를 생성하고 관리하게 되는데, kube-proxy는 이런 가상 네트워크 동작을 관리하는 컴포넌트입니다.
컨테이너 런타임
실제로 컨테이너를 실행시키는 컴포넌트입니다. 가장 많이 사용하는 컨테이너 런타임으로 Docker를 주로 사용합니다.
오브젝트
쿠버네티스를 이해하기 위해 가장 중요한 부분이 오브젝트입니다. 가장 기본적인 구성단위가 되는 기본 오브젝트(Basic Object)와, 기본 오브젝트를 생성하고 관리하는 추가적인 기능을 가진 컨트롤러(Controller)로 이루어집니다. 그리고 이러한 오브젝트의 스펙(설정)이외에 메타 정보들로 구성이 되게 됩니다.
오브젝트 스펙
오브젝트들은 모두 오브젝트의 특성을 기술한 오브젝트 스펙으로 기술됩니다. 오브젝트 스펙을 기술하기 위해서는 cli를 이용해 직접 명령어를 실행시키거나, yaml 파일이나 json과 같은 템플릿 형식으로 오브젝트 스펙을 정의할 수 있습니다.
- 최근에는 거의 yaml 파일을 이용해 기술하고 있습니다.
기본 오브젝트(Basic Object)
쿠버네티스에 의해 배포 및 관리되는 오브젝트로 Pod, ReplicaSet, Deployment,Service, Volume, Namespace 등이 있습니다.
Namespace
네임스페이스는 하나의 쿠버네티스 클러스터 안의 논리적인 구분 단위입니다. pod나 service 등은 네임 스페이스 별로 생성이나 관리될 수 있고, 사용자의 권한 역시 네임 스페이스 별로 나눠서 부여할 수 있습니다.
예를 들어 하나의 클러스터 내에서 개발/운영/테스트 환경과 같이 3개의 네임 스페이스로 나눠서 각각의 네임스페이스를 논리적으로 독립해서 운영할 수 있게 됩니다. 주의할 점은 방금 언급한 대로 논리적으로 분리한 것이기 때문에 다른 네임 스페이스간의 pod끼리도 통신이 가능하게 됩니다.
따라서 높은 수준의 분리 정책을 원할 경우에는 클러스터 자체를 분리하는 것을 권장합니다.
가장 기본적인 4개의 필드로 템플릿을 구성해 보았습니다. 위에서부터 하나씩 살펴보도록 하겠습니다.
-
apiVersion: 사용하려는 쿠버네티스의 api버전을 명시합니다. kubectl-api-versions 명령어로 사용 가능한 버전 목록을 확인할 수 있습니다.
-
kind: 어떤 종류의 오브젝트 또는 컨트롤러의 작업인지 명시합니다.
-
metadata: 메타데이터를 설정합니다.
-
spec: 파드가 어떤 컨테이너를 가지고 어떻게 동작할지를 명시합니다.
