[KUBERNETES] 05. 쿠버네티스의 오브젝트 (1)

[KUBERNETES] 05. 쿠버네티스의 오브젝트 (1)

---

🔔 쿠버네티스의 오브젝트

쿠버네티스의 구성 단위로서 각각의 오브젝트는 쿠버네티스 API의 리소스 종류에 맞게 설정되고 생성되며, 오브젝트는 지정된 상태가 유지되도록 쿠버네티스에 의해 제어된다.

🔔 오브젝트 스펙(Object Spec)

오브젝트들은 모두 오브젝트의 특성(설정정보)을 기술한 오브젝트 스펙으로 정의되고 커맨드 라인을 통해 오브젝트 생성시 인자로 전달하여 정의를 하거나 또는 YAML 이나 JSON 파일로 스펙을 정의할 수 있다.

🔔 기본 오브젝트 (Basic Object)

컨테이너화되어 배포되는 애플리케이션의 워크로드를 기술하는 오브젝트

📜 파드(Pod)

쿠버네티스에서 배포할 수 있는 가장 작은 단위로 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가진다.

컨테이너를 하나만 사용하는 경우도 반드시 파드로 감싸서 관리해야 하며, 파드에 속한 컨테이너는 스토리지와 네트워 크를 공유하고 서로 localhost로 접근할 수 있다.

📜 서비스(Service)

파드(Pod)는 일시적인 존재라 한 곳에 고정되어 있지 않고 클러스터 내부를 옮겨다니며 이 과정에서 파드(Pod)의 IP 주소는 계속 변경된다 이렇게 동적으로 변하는 파드 (Pod)들에 고정된 방법으로 접근하기 위해 사용하는 것이 서비스(Service)이다.

서비스(Service)는 파드를 외부 네트워크와 연결하는 역학을 수행한다 즉, 서버 역할 을 하는 파드가 클라이언트의 요청을 받을 수 있도록 대표 IP 주소를 취득하여 내부 DNS에 서비스 이름을 도메인으로 등록하기 때문에 서비스 디스커버리와 대표 IP 주소 로의 요청 트패픽을 지정된 파드들에 부하분산하며 전송하는 역할도 수행한다.

(a) ClusterIP

클러스터 내부 IP를 할당하는 타입 즉, 클러스터 내부에서만 접근이 가능하며 외부에서는 접근이 불가능(타입을 지정하지 않으면 기본으로 설정됨)

(b) NodePort

클러스터 외부에서도 노드의 IP 주소와 포트번호를 통해 접근할 수 있게하는 타입

• 공개 포트번호의 범위는 30000~32767이며, 클라이언트가 노드의 IP주소, 포트로 전송한 요청은 최종적으로 파드에게 전달된다.

• NodePort 타입의 서비스를 만들면 클러스터의 모든 노드에 지정한 포트가 열리게 되고, 각 노드가 수령한 요청은 대상이 되는 파드들에게 부하분산되어 전송된다.

• 주의해야 할 것은 사용자가 특정 노드를 지정해서 접속하고 있는데, 해당 노드가 하드웨어 점검 등의 이유로 셧다운된다면 서비스를 이용할 수 없게된다.

(c) LoadBalancer

AWS의 ECS(Elastic Container Service), GCP의 GKE(Google Kubernetes Engine) 같은 클라우드 서비스를 사용할때 사용가능한 타입

• 파드(Pod)를 클라우드에서 제공하는 로드밸런서와 연결해서 그 로드밸런서의 IP 주소를 이용해 클러스터 외부에서 접근이 가능하다.

  
  

(d) ExternalName

ExternalName은 NodePort, LoadBalancer와 다르게 외부에서 접근하기 위한 서비스 타입이 아니며, 내부 파드가 외부 특정 FQDN에 쉽게 접근하기 위한 서비스 타입

• k8s 클러스터 외부의 DNS 이름을 서비스 이름으로 등록함으로써 접속하기 위한 외부 FQDN 주소가 바뀌더라도, 서비스 이름은 그대로 유지할 수 있어 애플리케이션을 다시 작성하거나 빌드하지 않아도 된다.

📜 볼륨

파드(Pod)나 컨테이너는 실행 시에만 존재하는 일시적인 존재하기 때문에 데이터를 잃지 않기 위해서는 전원이 꺼져도 데이터가 유지되도록 스토리지 시스템에 저장해야 한다.

(a) 볼륨(Volume) 타입

구분	설명
임시볼륨	emptyDir은 노드의 디스크를 파드(Pod)가 일시적으로 사용하는 방법으로, 같은 파드의 컨테이너 간에는 볼륨을 공유할 수 있으나 다른 파드에서는 접근할 수 없고 파드가 종료되면 emptyDir은 삭제된다.
로컬 보륨	hostpath는 동일한 노드의 디스크를 사용하지만 같은 노드에 배포된 서로 다른 파드에서 볼륨을 공유할 수 있으며, 파드와 함께 삭제되지는 않지만 각 노드의 디스크를 사용하기 때문에 다른 노드에 배포된 파드 간의 데이터를 공유할 수 없다. 그리고 노드가 정지되면 데이터에 접근할 수 없게 되므로 hostpath는 외부 스토리지가 아직 준비 중인 상황에서 간단하게 사용하는 용도의 수준으로 바라봐야 한다.
네트워크(외부) 볼륨	외부 스토리지 시스템과 연동한 경우, 모든 노드에서 외부 스토리지 시스템에 접근할 수 있어야 한다 그러면 노드가 정지되어도 파드가 다른 노드에 이동하여 애플리케이션을 문제 없이 수행할 수 있다. 여기서 주의할 것은 외부 스토리지 시스템을 사용하단고 해서 반드시 여러 노드에서 볼륨을 공유할 수 있는 건 아니라는 점이다 이는 스토리지는 시스템의 동작 방식에 따라 다른데 예를 들어 NAS 처럼 파일 시스템을 공유하는 시스템의 경우 여러 노드에서 볼륨을 공유할 수 있으나 iSCSI 처럼 블록 스토리지를 기반으로 하는 경우에는 한 개의 노드에서만 접근할 수 있다.

(b) 퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC)

디스크 볼륨을 설정하려면 물리 디스크를 생성과 설정에 대한 자세하게 이해할 필요가 있지만, 쿠버네티스는 인프라에 대한 복잡성을 추상화를 통해 간단하게 하고 인프라에 종속적인 부분은 시스템 관리자가 설정하도록 하여, 개발자는 이에 대한 이해 없이 간단하게 사용할 수 있는 디스크 볼륨 부분에 퍼시스턴트 볼륨(PV)와 퍼시스턴트 볼륨 클레임(PVC)라는 개념을 도입하였다.

시스템 관리자가 실제 물리 디스크를 생성한 후 이 디스크를 PV라는 이름으로 쿠버네티스에 등록하면 개발자는 파드(Pod)를 생성할 때 볼륨을 정의하고 이 볼륨 정의 부분에 물리적 디스크에 대한 특성을 정의하는 것이 아니라 PVC를 지정하여 관리자가 생성한 PV와 연결한다.

즉, 관리자에 의해 생성된 물리 디스크를 쿠버네티스 클러스터로 표현한 것이 PV이고, Pod의 볼륨과 이 PV를 연결하는 기능을 PVC가 된다.

(c) PV와 PVC LifeCycle

【Provisioning】

볼륨 오브젝트를 사용하기 위해서는 먼저 실제 저장할 수 있는 공간을 확보해야 하며, 저장 공간이 확보되면 PV가 해당 저장 공간을 바라보며 생성된다. 즉, Provisioning은 스토리지를 확보하여 PV를 만드는 단계에 해당되며, 만드는 방법으로는 정적(Static)과 동적(Dynamic) 방법이 있다.

【Binding】

Provisioning을 통해 만들어진 PV를 PVC와 연결하는 단계, PVC는 사용자가 요청하는 볼륨이 PV에 생성되면 그 요청은 받아들여져 할당해주는게 된다. 만약, PVC가 요청한 볼륨이 PV에 없다면 해당 요청은 무한정 남아 있게 되고 PVC 요청하는 볼륨이 PV에 생성되면 그 요청은 받아들여져 할당해주게 된다.

【Using】

파드(Pod)는 PVC를 볼륨으로서 사용하며, 클러스터는 PVC를 확인하여 바인딩된 PV를 찾고 볼륨을 파드에서 사용할 수 있도록 해준다. 만약 파드가 사용중인 PVC를 삭제하려고 하면 “Storage Object in Use Protection”이라는 보호 기능에 의해 바로 삭제되지는 않는다. 그 이유는 사용 중인 데이터를 임의의로 삭제하면 치명적인 결과를 가져올 수 있기 때문이다 그래서 만약 삭제 요청을 하였다면 파드가 PVC를 사용하지 않을때까지 삭제 요청은 연기된다.

【Reclaiming】

PV는 기존 사용했던 PVC가 아니더라도 다른 PVC로 재활용이 가능하기 때문에 사용이 종료된 PVC를 삭제할 때, 사용했던 PV의 데이터를 어떻게 처리할지에 대한 설정을 하게된다. 그 설정은 PV의 YAML 파일에 정의된 persistentVolumeReclaimeProxy의 설정에 따라 결정되며, 이때 Delete, Retain, Recycle 3가지 상태를 가지게 된다.

(d) Dynamic Provisiong

클라우드 서비스 환경이 아닌 온프레미스 환경으로 구성된 쿠버네티스는 PV를 수동으로 생성하고 PVC에 바인딩 한 후에, 파드(Pod)에서 사용할 수 있지만 1.6버전 부터 동적 생성 기능을 지원하게 되어 관리자가 별도로 디스크를 생성하고 PV를 생성할 필요 없이 PVC만 정의하면 이에 맞는 물리 디스크를 생성 및 PV 생성을 자동화 해준다.

📜 인그레스(Ingress)

네트워크 트래픽은 인그레스(Ingress)와 이그레스(Egress)으로 구분하며, 인그레스는 외부로부터 서버 내부로 유입되는 트래픽을 이그레스는 서버 내부에서 외부로 나가는 트래픽을 의미한다.

k8s의 인그레스는 외부에서 k8s 클러스터 내부에서 실행 중인 디플로이먼트와 서비스에 접근하기 위한, 일종의 관문 같은 역할을 담당한다.

• 인그레스를 제외한 외부 요청을 처리할 수 있는 선택지는 NodePort, ExternalIP 등이 있지만 이러한 방법들은 Layer4 에서의 요청을 처리하며, 네트워크 요청에 대한 세부적인 처리 로직을 구현하기는 한계가 있다.

• 하지만 k8s의 인그레스는 Layer7 에서의 요청을 처리할 수 있으며, 외부로부터 들어오는 요청에 대한 로드밸런싱, TLS/SSL 인증처리, 특정 HTTP 경로의 라우팅 등을 자세하게 정의할 수 있다.

• 그리고 인그레스 자체는 이런 규칙들을 정의해둔 오브젝트이고, 이런 규칙들을 실제로 동작해주는게 인그레스 컨트롤러라고 부르는 특별한 웹 서버에 적용함으로써 추상화된 단계에서 서비스 처리 로직을 정의할 수 있다.

KUBERNETES 카테고리 내 다른 글 보러가기