IT Infra/Kubernetes

kubernetes 오브젝트 정리(1)

Daniel.Lee 2022. 1. 3. 23:07

Master & Node

쿠버네티스의 클러스터 구조

  • Master
    • 클러스터 전체를 관리하는 컨트롤러
  • Node
    • 클러스터를 구성하는 가상 또는 물리머신

오브젝트(Object)

쿠버네티스에서 가장 기본적인 구성단위가 되는 기본 오브젝트(Basic Object)와 컨트롤러(Controller)로 이루어져있다.

  • 기본 오브젝트(Basic Object)
    • 배포되어 있는 워크로드를 구성하는 오브젝트들로 Pod, Service, Volume, Namespace 가 있다.
  • 컨트롤러(Controller)
    • 기본 오브젝트만으로 애플리케이션을 설정 및 배포가 가능하지만 이를 조금 더 편리하게 관리하기 위해서 사용된다.
    • 컨트롤러에는 Replication Controller(RC), Replication set, DaemonSet, Job, StatefulSet, Deployment 가 있다.

기본 오브젝트(Object) - Pod

Pod는 가장 기본적인 배포 단위로, 컨테이너를 포함하는 단위이다. 쿠버네티스는 하나의 컨테이너를 개별적으로 배포하는 것이 아닌 Pod라는 단위로 배포하는데, Pod는 하나 이상의 컨테이너를 포함하고 있다.
간단한 Pod를 정의한 Yaml을 정리해보면 아래와 같다.

apiVersion: v1
kind: Pod
metadata:
	name: jeus
spec:
	containers:
		-name:jeus
		 image: jeus:7
		 ports:
			-containerPort: 8090

정의된 것들을 하나씩 살펴보자면

  • apiVersion
    • 이 스크립트를 실행하기 위한 쿠버네티스 API 버전이다. 보통 v1을 사용
  • Kind
    • 리소스 종류를 정의한다.
    • Pod에 대해 정의를 하므로, Pod 라고 작성
  • metadata
    • 리소스의 각종 메타 데이타를 넣는데, 라벨이나 리소스의 이름 등등 각종 메타데이터를 작성
  • spec
    • 리소스에 대한 상세한 스펙을 정의한다.
    • pod는 컨테이너를 보유하고 있으므로, container를 정의한다.
    • 하위에는 이름, 설정된 이미지, 포트 등을 작성한다.

Pod는 2가지 특징이 있다.

  • Pod 내의 컨테이너는 IP 와 Port를 공유한다.
  • Pod 내 배포된 컨테이너 간에 디스크 볼륨을 공유할 수 있다.

기본 오브젝트(Object) - Volume

Pod는 생성될 때 기본적으로, 컨테이너마다 로컬디스크가 생성이 되는데 컨테이너가 새로 시작되거나 새로 배포될 때마다, 디스크에 기록된 내용들이 유실된다.
그래서 DB와 같이 영구적으로 파일을 저장해야 하는데 이러한 형태의 스토리지를 쿠버네티스에서는 볼륨이라고 한다.
볼륨은 컨테이너의 외장 디스크로 생각하면 쉽다. Pod가 생성될 때 컨테이너에 마운트 되어서 사용한다.
쿠버네티스는 다양한 외장 디스크를 추상화 된 형태로 제공된다. iSCSI나 NFS와 같은 온프렘 기반의 일반적인 외장 스토리지 이외에도, 클라우드의 외장 스토리지인 AWS EBS, Google PD,에서 부터 github, glusterfs와 같은 다양한 오픈소스 기반의 외장 스토리지나 스토리지 서비스를 지원하여, 스토리지 아키텍처 설계에 다양한 옵션을 제공한다.
아래 그림을 보면 이해를 조금 더 쉽게 할 수 있다.

기본 오브젝트(Object) - Serivce

서비스를 정의할 때에는 어떤 Pod를 서비스로 묶을 것인지를 정의하는데, 그 정의를 할 때 사용하는 것이 **라벨(label)**과 **라벨 셀렉터(label selector)**라는 개념이다. 각 Pod를 생성할 때 메타데이터 정보 부분에 라벨을 정의할 수 있다. 서비스는 라벨 셀렉터에서 특정 라벨을 가지고 있는 Pod만 선택을 해서 서비스에 묶이게 된다.
라벨(label)은 쿠버네티스의 리소스를 선택하는데 사용이 된다. 각 리소스들은 라벨을 가질 수있고, 라벨 검색 조건에 따라서 특정 라벨을 가지고 있는 리소스만을 선택할 수도 있다. 라벨로 선택된 리소스들만 Service에 연결을 하거나 특정 라벨로 선택된 리소스만 네트워크 접근 권한을 부여하는 등의 행위를 할 수있다. 라벨은 metadata 섹션에 키/값 쌍으로 정의가 가능하며, 하나의 리소스에는 하나의 라벨이 아닌 여러 라벨을 동시 적용할 수있다.

metadata:
	labels:
		key1 : value1
		key2 : value2

위 처럼 정의된 라벨들을 라벨셀렉터가 선택을 해서 묶게 되는 것이다.

위의 그림을 YAML로 정리해 보면 아래와 같다.

kind: Service
apiVersion: v1
metadata:
	name: my-service
spec:
	selector:
		app:myapp
	port:
	-protocol: TCP
	 port: 80
	 targetPort: 9376

정의된 것들을 살펴보면

  • spec부분에 서비스에 대한 스펙을 정의
    • selector에서 라벨이 app:myapp인 Pod만을 선택해서 서비스에서 서비스를 제공
    • 서비스의 80번 포트의 요청을 컨테이너의 9376 포트로 연결해서 서비스 제공

기본 오브젝트(Object) - Namespace

네임스페이스는 클러스터 내의 논리적인 분리단위라고 이해하면 쉽다.
Pod, Service 등 , 네임스페이스 별로 생성이나 관리가 가능하고, 사용자의 권한 또한 네임스페이스 별로 나눠서 부여할 수 있다.
간단하게 정리를 해보자면,

  • 사용자 별로 네임스페이스별 접근 권한을 다르게 설정하고 운영할 수 있다.
  • 네임스페이스별로 리소스의 할당량을 지정할 수 있다.
    • ex. 개발 쪽은 cpu 10, 운영 쪽은 cpu 20
  • 네임스페이스별로 리소스를 나눠서 관리할 수 있다.(Pod, Service)

주의할 점은 네임스페이스는 위에서 설명했다싶이 논리적인 분리단위이지, 물리적으로 환경을 분리한 것이 아니다.
다른 네임스페이스 간의 Pod끼리 통신도 가능하다.
높은 수준의 분리 정책을 원할 경우에는 네임스페이스 보단 쿠버네티스 클러스터 자체를 분리하는 것을 권장한다.

컨트롤러(Controller)-Replication Controller

Replication Controller는 Pod를 지정된 숫자로 가동시키고, 관리하는 역할을 한다.
**Replication Controller(줄여서 RC라고 표현)**는 Replica 수, Pod Selector, Pod Template 이렇게 ****크게 3가지 파트로 구성되어진다.

  • Replica 수
    • RC에 의해서 관리되는 Pod의 갯수를 나타내는데, 그 갯수만큼 Pod의 수를 유지하도록 한다.
  • Pod Selector
    • Pod 라벨을 기반으로 하여, RC가 관리할 Pod를 가져 오는데 사용한다.
  • Pod Template
    • Pod를 추가로 기동을 하게 될 때, 어떻게 Pod를 만들지에 대한 정보를 정의한다.

Replication Controller를 YAML로 정리하면 아래와 같다.

apiVersion:v1
kind:ReplicationController
metadata:
	name:nginx
spec:
	replicas:3
	selector:
		app:nginx
	template:
		metadata:
			name:nginx
			labels:
				app:nginx
		spec:
			containers:
				-name:nginx
				image:nginx
				ports:
				-containerPort:80

컨트롤러(Controller)-ReplicaSet

ReplicaSet은 Replication Controller 의 새로운 버전이라고 보면 된다
큰 차이는 없고 그냥 같은 것이라고 봐도 무방하다.
차이가 있다면 Replication Controller 는 Equality 기반 Selector를 이용하는데 반해, Replica Set은 Set 기반의 Selector를 이용한다.

컨트롤러(Controller)-Deployment

Deployment는 Replication controller와 Replica Set의 상위 추상화 개념이다.
실제 운영에서는 ReplicaSet 이나 Replication Controller를 사용하는 것보다, 좀 더 추상화된 Deployment를 사용한다.
Deployment는 Pod 배포를 위해서 RC를 생성하고 관리하는 역할을 하며, 특히 롤백을 위한 기존 버전의 RC 관리등 여러가지 기능을 포괄적으로 포함하고 있다.

  • 롤링업데이트 방식
    • Pod를 하나씩 업그레이드 하는 방식을 사용한다.
    • 새로운 버전(v2)의 RC를 만든 후에 기존에 존재하는 RC(v1)의 replica수를 하나 씩 줄이면서 새로운 RC(v2)의 replica수를 늘리는 방식이다
      • 아래 그림을 보면 조금 더 이해하기 수월할 꺼라고 생각한다.


참조: 조대협님 블로그(https://bcho.tistory.com/)