[4] 쿠버네티스 오브젝트 (1)

쿠버네티스는 클러스터 환경에서 컨테이너 기반 애플리케이션을 배포하고 서비스하며 관리하는 컨테이너 애플리케이션 오케스트레이터 역할을 한다. 쿠버네티스에서 컨테이너 기반 애플리케이션을 포함하여 애플리케이션을 배포하고 관리하는 역할을 하는 객체들을 모두 쿠버네티스 오브젝트 라고 한다. 구체적으로는 다음의 의미를 갖는다.

• 동작 중인 컨테이너 기반 애플리케이션
• 컨테이너 기반 애플리케이션을 구동시키는 노드
• 애플리케이션이 사용할 수 있는 리소스
• 재구동, 업그레이드 및 내결함성에 대한 애플리케이션의 정책

쿠버네티스 오브젝트를 생성하게 되면 쿠버네티스 시스템은 해당 오브젝트가 존재하는지 확인하기 위해 지속적으로 작동한다. 그리고 쿠버네티스 오브젝트는 명세(spec)과 상태(status)를 갖는 객체이다. 여기서 명세는 오브젝트에 대한 특성에 대한 설명으로, 의도한 상태 (desired status)를 포함한다. 쿠버네티스 컨트롤 플레인은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 지속적으로 관리한다.

이번 글에서는 쿠버네티스 오브젝트에 대한 간단한 소개를 할 것이다. 세부적인 내용은 추후에 글을 따로 쓸 예정이다.

파드 (Pod)

파드는 쿠버네티스에서 생성하고 관리할 수 있는 컨테이너 기반 애플리케이션의 최소 단위이다. 파드는 하나 이상의 컨테이너를 가지며 파드 내 컨테이너들은 스토리지와 네트워크 리소스(IP 등등..)을 공유한다. 그러므로 같은 파드 내 컨테이너 애플리케이션은 localhost로 통신할 수 있다. 그리고 파드 내 컨테이너들은 항상 공존하고 같이 스케줄링되며 같은 컨텍스트에서 작동한다.

워크로드

파드가 컨테이너 기반 애플리케이션의 최소 단위이긴 하지만, 쿠버네티스에서는 파드를 단독으로 생성해서 사용하지 않는다. 그 대신에, Deployment 또는 Job과 같은 워크로드 리소스를 사용하여 생성하는데 워크로드는 파드 집합을 관리하여 파드 집합이 지정된 개수만큼, 올바른 종류의 파드가 실행될 수 있도록 보장하는 컨트롤러를 의미한다.

워크로드로는 Deployment, ReplicaSet, StatefulSet, DaemenSet, Job, CronJob 등이 있지만 이 글에서는 Deployment, ReplicaSet만 다룰 예정이다.

레플리카셋 (ReplicaSet)

레플리카셋은 원하는 개수(Desired)만큼 파드가 유지될 수 있도록 관리해주는 워크로드이다. 만약 특정 에러로 인해 어떤 파드가 죽더라도 레플리카셋이 이를 감시해 죽은 파드를 다시 자동으로 띄우는 역할을 하게 된다. 그리고 레플리카셋에 원하는 개수를 변경한다면 스케일링의 효과를 가지게 된다.

디플로이먼트 (Deployment)

하지만 쿠버네티스에서는 레플리카셋을 단독으로 생성하여 파드의 개수를 유지시키도록 하지 않는다. 대신 디플로이먼트를 생성하면 자동으로 레플리카셋을 만들어준다. 디플로이먼트는 파드의 생성과 삭제, 업데이트를 관리하는 오브젝트로 레플리카셋이 할 수 있는 역할 외에 파드의 새로운 상태로 정의하여 파드를 업데이트 할 수 있다. 업데이트 뿐만 아니라 이전의 상태로 되돌리는 롤백도 가능하다.

네트워크

위에서 설명한 파드와 워크로드만를 이용하여 애플리케이션을 클러스터 내에 구동시킬 수 있다. 하지만 파드와 워크로드만으로 클러스터 외부로 서비스할 수 없다. 서비스 할 수 없는 이유를 간략하게 설명하겠다.

파드가 죽는다면..?

먼저 파드와 디플로이먼트가 생성되고, 해당 파드에게 요청하는 클라이언트가 있다고 가정하자. 해당 클라이언트는 먼저 파드의 IP를 알고있고, 10.244.2.2 로 통신하고 있다. 하지만, 어떠한 이유로 파드가 죽어버리면 디플로이먼트가 이를 감지하고 새로운 파드를 생성한다. 하지만 새로 생성된 파드의 IP는 기존의 IP와는 다르게 할당되며, 클라이언트는 새로 생성된 파드의 IP를 알지 못하는 문제가 생긴다.

파드는 외부와 단절되어있다.

근본적으로는 파드는 클러스터 내부에서만 접근이 가능하며, 클러스터 외부로 노출되어있지 않는다. 그래서 클러스터 외부에서 해당 파드에 직접 요청할 수가 없다. 파드를 외부로 노출시키려면 (1) 포트포워딩 을 이용하거나 (2) 쿠버네티스 서비스 오브젝트를 이용하면 된다. 포트포워딩은 테스팅 목적이 강하므로 서비스에 대해 알아보자.

서비스

쿠버네티스에서 서비스는 파드의 논리적 집합과 파드 집합에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 위에서 설명한 문제점을 서비스를 이용하여 해결할 수 있다. 서비스는 다음 기능을 제공한다.

• 파드 디스커버리
• 파드 로드밸런싱
• 외부로 서비스 노출 가능 (type 별로 다름)

서비스를 생성하면 레이블 셀렉터를 이용하여 레이블 셀렉터와 일치하는 파드를 탐색한다. 서비스는 레이블 셀렉터와 일치하는 파드의 IP를 엔드포인트로 관리한다. 그리고 서비스를 생성하면 서비스 이름을 기반으로 DNS가 생성되는데, DNS 이름으로 들어오는 요청들을 엔드포인트로 로드밸런싱하는 역할을 한다. 그리고 서비스를 이용하여 파드들을 외부로 노출시킬 수 있다. 서비스 타입의 종류는 총 4가지가 있다.

• ClusterIP: 클러스터 내부 통신용
• NodePort: 클러스터 내부 / 외부 통신용, 노드의 포트를 사용한다. (30000-32767)
• LoadBalancer: 클라우드 프로바이더를 사용하는 경우 클라우드 로드밸런서를 사용하여 외부로 노출시킨다.
• ExternalName: 사실 이건 잘 모르겠다.

인그레스

인그레스는 HTTP/HTTPS 기반의 클러스터 내부 서비스에 대한 외부 접근을 관리하는 오브젝트이며, 인그레스를 통해 호스트 및 패스 기반 라우팅 룰을 정의할 수 있다. 인그레스를 사용하면 보통 80(HTTP)/443(HTTPS) 포트를 통해 HTTP(S) 서비스를 외부로 노출시킬 수 있다. 사실 인그레스는 라우팅 룰을 정의하는 오브젝트일 뿐이며, 실제 라우팅 역할을 하는 것은 인그레스 컨트롤러이다. 즉, 인그레스를 이용하려면 인그레스 컨트롤러를 설치해야 한다. (종류는 다양하며, 대표적으로는 nginx 인그레스 컨트롤러가 있다.)

 

Volume

파드가 생성되면 컨테이너만의 공간이 생성되고, 이 공간은 임시적으로 사용된다. 하지만 파드가 죽는다면 해당 공간은 사라지게 되는데, 웹 애플리케이션과 같은 Stateless한 애플리케이션의 경우에는 문제가 없지만 Mysql과 같은 영구 데이터를 저장하는 파드의 경우, 또는 컨테이너 간에 임시 파일을 공유해야 하는 경우라면 문제가 발생할 수 있다. 

 

그래서 파드의 라이프사이클에 관계 없이 지속되는 공간이 필요한데 쿠버네티스는 볼륨 이라는 이름으로 해당 공간을 사용할 수 있도록 지원한다. 쿠버네티스에는 크게 임시 볼륨과 퍼시스턴트 볼륨이라는 유형의 볼륨을 지원한다.

 

 

마무리

이번 장에서는 기초적인 쿠버네티스 오브젝트의 종류에 대해 간단히 살펴보았다. 이번 장에서 소개한 오브젝트 외에도 쿠버네티스에서 지원하는 다양한 오브젝트가 있으며, 사용자가 직접 오브젝트를 정의하여 쿠버네티스 API를 확장해서 사용할 수 있는 CRD (Custom Resource Definition)도 있다. 이 CRD는 K8s에서 연동할 수 있는 오픈소스에서 많이 개발하며, 대표적으로는 Istio, ArgoCD 등이 있다.

 

다음 장에서는 쿠버네티스 오브젝트에서 공통적으로 가지는 항목에 대하여 알아볼 것이다.

 

2022.01.02 - [DevOps/Kubernetes] - [4] 쿠버네티스 오브젝트 (2)

[4] 쿠버네티스 오브젝트 (2)