[k8s] 쿠버네티스의 기본 오브젝트 (Pod, Service, Volume, Namespace)

쿠버네티스는 크게 오브젝트(object)와 오브젝트를 관리하는 컨트롤러(controller)로 나눠져 있다.오브젝트엔 어떤 것들이 있고 각각의 오브젝트에 대한 내용을 간단하게 정리해보았다.  

 

 

쿠버네티스 오브젝트

쿠버네티스 오브젝트는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 오브젝트를 생성하게 되면 쿠버네티스 시스템은 원하는 상태를 보장하기 위해 지속적으로 작동한다.

 

쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다.

 

거의 모든 쿠버네티스 오브젝트는 오브젝트 구성을 결정해주는 두 개의 중접된 오브젝트 필드인 status와 spec를 포함한다. 

• status : 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태를 설명 
• spec : 오브젝트의 특성으로 추구하는 상태를 설명 컨트롤러는 status가 spec과 일치하도록 오브젝트를 생성/삭제한다.

 

 

 

 

기본 오브젝트

쿠버네티스에는 쿠버네티스에 의해 배포 및 관리되는 가장 기본적인 오브젝트가 4가지 존재한다. 

• pod 
• service 
• volume
• namespace

 

 

 

Pod

파드는 쿠버네티스에서 가장 기본적인 배포 단위로 컨테이너를 포함하는 단위이다. 쿠버네티스의 특징 중 하나로 컨테이너를 개별적으로 하나씩 배포하는 것이 아닌 파드 단위로 배포한다. 이때 파드는 하나 이상의 컨테이너를 포함한다.

 

Pod를 생성할 때 Container, Label, Node Schedule에 대한 개념이 필요하다. 

 

파드 내 컨테이너는 중복된 포트를 사용할 수 없다. 

apiVersion: v1
kind: Pod
metadata:
 name: pod-1
spec:
 containers:
 - name: container1
   image: tmkube/p8000
   ports:
   - containerPort: 8000
 - name: container2
   image: tmkube/p8080
   ports:
   - containerPort: 8080

 

위는 Pod를 생성하는 yml 파일 예시이다. 하나의 Pod에 containerPort가 동일하다면 생성 시에 에러가 발생한다.   

Label은 키-값 쌍으로 구성된 메타데이터이다. 라벨은 특정 리소스를 식별하고 조직화하는 데 사용된다. 

 

아래의 예제에선 Service를 생성할 때 Pod들을 묶어 생성하는 걸 볼 수 있다. 

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    type: web
  ports:
    - port: 8080

 

 

label의 지정은 아래와 같이 할 수 있다. 하나의 Pod에 Label은 여러 개 지정 가능하다.

apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    type: web
    lo: dev
spec:
  containers:
  - name: container
    image: tmkube/init

 

 

Pod를 생성할 때 어디 Node에 생성할 지도 정해야 한다. 

직접 지정 하는 방식과 쿠버네티스가 자원 요소를 고려하여 자동으로 지정해주는 방식이 있다. 자동 지정은 Node Schedule이 수행해준다. 

 

직접 지정의 예시 yml 이다. nodeSelector의 hostname에 node이름을 지정해주면 된다.

apiVersion: v1
kind: Pod
metadata:
 name: pod-3
spec:
 nodeSelector:
  hostname: node1
 containers:
 - name: container
   image: tmkube/init

 

 

따로 hostname을 지정하지 않고 requests 옵션을 주면 Node Schedule이 각 Node들의 리소스 현황을 파악한 후 가장 적절한 Node에 Pod를 생성해준다. 

apiVersion: v1
kind: Pod
metadata:
  name: pod-4
spec:
  containers:
  - name: container
    image: tmkube/init
    resources:
      requests:
        memory: 2Gi
      limits:
        memory: 3Gi

 

 

 

 

 

Service

서비스는 파드 집합에서 실행중인 컨테이너를 네트워크 서비스로 노출하는 추상화 방법이다. 파드는 컨트롤러가 관리하므로 고정되어 있지 않고 클러스터 안을 옮겨 다닌다. 이 과정에서 노드를 옮겨 다니며 실행되기도 하고 클러스터 안 파드의 IP가 변경되고 한다.

이렇게 동적으로 변하는 파드들에 고정적으로 접근할 때 사용하는 방법이 쿠버네티스의 서비스이다. 서비스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하여 파드가 클러스터 안 어디에 있든 고정 주소를 통해 접근이 가능하다.

 

Service엔 3가지 종류가 있다.

 

1. ClusterIP

외부에서 접근이 불가하기 때문에 서비스 디버깅, 인증된 사용자 연결 등에 사용된다.

 

 

2. NodePort

외부에서 접근 가능하다. 하지만 Prod환경에서 사용하진 않고 임시로 연결을 허용할 때 사용한다. 즉 데모나 임시 연결 용이다.

 

 

type에 어떤 Service인지 지정해주면 된다. 주의해야할 점은 모든 Node에 동일한 Port를 할당한다. 

또한 이 Service는 로드밸런싱 또한 지원한다. 하지만 externalTrafficPolicy: Local 을 지정해주면 로드밸런싱을 지원하지 않고 지정한 곳으로만 트래픽을 보낼 수도 있다.  

apiVersion: v1
kind: Service
metadata:
 name: svc-2
spec:
 selector:
    app: pod
 ports:
   - port: 9000
     targetPort: 8080
     nodePort: 30000
 type: NodePort

 

 

 

3. Load Balancer

실제 운영 환경에선 이 Service를 사용한다. 

외부 접근이 가능하고 각각의 노드에 로드밸런싱을 지원한다.

개인 실습 환경에선 사용할 수 없고, GCP, AWS, Azure, OpenStack등을 이용할 때 사용 가능하다. 

 

 

 

 

 

 

Volume

컨테이너는 기본적으로 상태가 없는 앱 컨테이너를 사용한다. 상태가 없다는 것은 컨테이너 혹은 노드에 문제가 있어 컨테이너를 새로 실행했을 때 다른 노드로 자유롭게 옮길 수 있다는 뜻이다. 

이는 컨테이너의 장점이다. 하지만 컨테이너가 실행되지 않거나 삭제된다면 현재까지 저장한 데이터가 사라진다는 단점이 있다. 

앱의 특성에 따라 컨테이너에 문제가 발생해도 데이터를 보존해야 하는 경우가 생기는데, 이런 상황에서 사용하는 것이 볼륨이다. 볼륨은 컨테이너가 재시작하더라도 데이터를 유지한다.

 

 

Volume의 종류엔 emptyDir, hostPath, PVC/PV가 있다. 그리고 ConfigMap과 Secret도 소개하려 한다. 

 

 

emptyDir

파드가 노드에서 실행되는 동안 생성되는 임시 볼륨이다. Pod가 재생성되면 볼륨도 사라지기 때문에 일시적인 데이터를 저장하는 데 사용된다. 

 

 

HostPath

호스트 노드의 파일 시스템 경로에 파드를 마운트한다. 호스트 노드의 특정 디렉토리에 접근해야 할 때 사용한다. 

ex) 로그 파일 공유

 

 

PVC/PV

클러스터 내에서 독립적으로 관리되는 스토리지 리스소의다. PVC는 파드가 요청하는 스토리지 요구 사항을 정의한다. 

 

 

ConfigMap

설정 데이터를 키-값 쌍으로 저장하고 파드에 마운트한다. 애플리케이션의 설정 정보를 외부에서 관리할 때 사용한다. 환경 변수라고 생각하면 된다.

 

 

Secret

비밀번호, 토큰, 키 등의 민감한 데이터를 저장하고 파드에 마운트한다. 인코딩 디코딩 과정을 거친다. 

 

 

 

 

 

Namespace

네임스페이스는 쿠버네티스 클러스터 하나를 여러 개의 논리적인 단위로 나눠서 사용하는 것이다. 파드와 서비스등은 네임스페이스 별로 생성이나 관리가 될 수 있고, 사용자 권한 역시 네임스페이스 별로 나눠서 부여할 수 있다.

 

동일한 Namespace라면 Pod의 이름은 유일해야 하지만 두 개의 다른 네임스페이스에서 각각 동일한 이름의 파드를 생성할 수 있다. 

 

네임스페이스별로 리소스 할당량(Resource Quota)과 제한(Limit Range)을 설정할 수 있다. 이를 통해 각 네임스페이스가 사용할 수 있는 CPU, 메모리 등의 리소스를 제한하고 관리할 수 있다. 

 

Namespace의 생성은 아래와 같이 할 수 있다. 

apiVersion: v1
kind: Namespace
metadata:
  name: nm-1

 

 

이렇게 생성된 Namespace는 Pod생성 시 지정하여 Pod를 어떤 Namespace에 넣을 지 설정할 수 있다. 

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  namespace: nm-1
  labels:
    nm: pod1
spec:
  containers:
  ...

 

 

 

 

ResourceQuota와 LimitRange의 설정 방법은 각각 아래와 같다. 

 

- ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: rq-1
  namespace: nm-1
spec:
  hard:
    requests.memory: 3Gi
    limits.memory: 6Gi

 

 

- LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: lr-1
  namespace: nm-1
spec:
  limits:
  - type: Container
    min:
      memory: 1Gi
    max:
      memory: 4Gi
    defaultRequest:
      memory: 1Gi
    default:
      memroy: 2Gi
    maxLimitRequestRatio:
      memory: 3