[Kubernetes] Kubernetes Object란? basic-object 간략하게 알아보기(pod, volume, service, label, selector, namespace)

Kubernetes Object란?

쿠버네티스에서 사용하는 영구한 객체라고 합니다. 이러한 개체는 클러스터의 생성한 객체의 상태를 나타내는 데 사용됩니다. 또한 배포한 내용과 다를 시 쿠버네티스에서 자동 복구를 진행하고 현상 유지를 하려고 합니다. 즉, object는 쿠버네티스에서 사용하는 각 서비스의 형태라고 보시면 됩니다.

Object 종류

기본적인 object는 아래 4가지 입니다. 가장 먼저 알아야 할 object입니다.

• Pod : 쿠버네티스에서 실행 되는 컨테이너 묶음 단위
• Namespace : 리소스들을 구분하기 위한 관리 그룹, yaml 파일에 matadata에 존재합니다.
• Volume : 컨테이너에서 사용하는 데이터를 매핑하여 데이터를 저장 보존 하는 storage 개체
• Service : Pod의 접속하기 위한 접속 정보를 담고 있는 개체, pod는 생성되면 새로운 ip를 할당받기 때문에 Service로 묶어서 고정된 ip를 가지게 해야 함

 

쿠버네티스에서 Object 관리(작성?) 법

쿠버네티스에서 Object는 보통 yaml파일로 작성하여 생성 및 관리를 하게 됩니다. yaml 파일 작성 시에 어떤 object를 지칭할 것인지, 어떤 정보를 가지고 있을 것인지, 어떤 특징(spec)을 가질 것인지 기입하여 작성하고 이것을 기반으로 쿠버네티스에 관리 및 조작을 합니다.

• apiversion - app의 버전을 나타냅니다. 기본적으로 v1, v2등으로 작성하며, 이 형태는 개발자 별로 회사별로 다르게 나타 낼 수 있습니다.
• kind - object의 직접적인 형태를 기입합니다.
• metadata
  • namespace - DNS 호환 레이블, (default는 default)
  • name - 현재 네임스페이스 내에 이 개체를 식별하는 문자열에 해당 내용으로 select를 진행하여 해당 object의 내용을 확인할 수 있다.
  • label - 개체를 구성하고 분류하는 데 사용하는 key-value
  • annotation - 임의의 메타데이터를 저장하고 검색하기 위해 사용하는 key-value값의 맵
• Spec - 오브젝트를 생성할 때 내가 생성하고 싶은 특징을 정하여 표시한다.
• Status - 쿠버네티스에서 일반적인 시스템 안에 object의 상태를 나타냄

Object와 metadata, spec, status 간단 예시

apiVersion: v1
kind: Pod                                  # object 종류 기입하는 란
metadata:                                  # object의 정보
  name: test-pd
spec:                                      # object 명세
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:                           
  - name: test-volume                
    gcePersistentDisk:               
      pdName: my-data-disk
      fsType: ext4

 

Pod

• 1개 이상의 컨테이너 묶음 단위이며, 노드에 컨테이너를 실행하는 가장 기본 단위이다.
• Pod가 생성되면 유일한 IP주소를 가진다. 이 ip주소는 외부 노출용 주소가 아닌 Cluster에서 사용하는 주소이다.
• Pod안에 컨테이너 간 통신은 localhost로 통신하며 다른 Pod로 통신은 할당된 ip통신을 한다.
• Pod안에 Volume은 공유하나 다른 Pod는 공유하지 않는다.
• 외부에서 Pod에 접근하려고 하면 Pod의 Ip를 알 수 없기 때문에 Service나 Ingress 오브젝트를 사용하여 연결해주는 부분이 필요하다.

Pod 간단 예제

apiVersion: v1            # api 버전
kind: Pod                 # 오브젝트 종류 - Pod
metadata:
  name: nginx             # 오브젝트 정보 - Pod의 이름 nignx
spec:
  containers:             
  - name: nginx           # container 이름
    image: nginx:1.14.2   # 사용할 image
    ports:
    - containerPort: 80   # container가 사용할 포트 

 

Volume

Pod가 생성될 때 디스크에 있는 파일은 일시적이어서 Pod가 삭제되면 파일은 삭제됩니다. 그런데 Pod에서 사용하는 파일이 중요한 파일이어서 삭제되면 안 되는 경우는 어떻게 할까? Volume을 이용하여 파일을 다른 곳에 매핑하여 보관할 수 있습니다. Volume은 컨테이너의 파일을 외부에 저장하는 용도로 사용됩니다. Volume은 네트워크 디스크도 되지만, 클라우드에 저장소도 사용가능합니다.

Volume 간단 예제

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:                           # volume을 작성
  - name: test-volume                # volume 이름
    # This GCE PD must already exist.
    gcePersistentDisk:               # gce에 Volume설정 예제
      pdName: my-data-disk
      fsType: ext4

 

Service와 Label, selector

Service

Service라는 object는 여러 팟들을 하나로 묶음입니다. Pod는 생성이 되면 개별적인 IP를 받습니다. 하지만, Pod가 내려갔다가 다시 올라오면 새로운 IP를 받습니다. 이렇기 때문에 기본적으로 해당 그룹에 접근할 수 있는 고정적인 기준점이 필요한데 이때 사용하는 것이 Service입니다. 즉, Service는 Pod의 묶음을 추상화해서 그곳에 접근하면 알아서 해당 Pod에 접근 가능하도록 설정해주는 역할을 합니다.

Label과 selector

그럼 Service는 어떻게 Pod를 묶음 단위로 나눌 수 있을까요? 그것은 Label과 selector를 이용해서 묶습니다. 위와 같이 한 노드에 3개의 Pod가 있다고 가정하고. 2개의 Pod를 묶으려고 합니다. 이때 Pod에는 Label이라는 속성값을 주어야 하며, Service는 Selector라는 속성으로 Label에 작성된 내용을 기입을 하면 하나의 Service가 만들어집니다.

Label Selector 예제

apiVersion: apps/v1           
kind: Deployment               # Deployment 오브젝트 명시 
metadata:                     
  name: nginx-deployment      
  labels:                    
    app: nginx
spec:                         
  replicas: 2                 
  selector:                    # selector 명시
    matchLabels:
      app: nginx               # selector가 바라볼 Label 

 

Namespace

쿠버네티스에서 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공하는데, namespace는 리소스들의 묶음으로 이해하면 된다. 그림과 같이 Namespace - account, billing과 같이 기능별로 묶거나 개발/운영/테스트 환경 같이 배포 단계별로 묶을 수 있다. namespace별 접근 권한을 다르게 운영 리소스의 쿼타를 지정, 리소스를 나눠서 관리를 할 수 있다.

아래는 학습할 수 있는 케이스입니다.
namespace_best_practice , namespace_use_case

namespace 간단 예시

apiVersion: v1
kind: pod
metadata:
  name: my-app
  namespace: mynamespace  # pod를 생성 시 어떤 namespace를 바라 볼지 정함
spec:
...

 

마치며

이번 포스팅에서는 object의 개념, 간략한 yaml파일 작성법 및 기본 object의 대해 알아보았습니다. 쿠버네티스는 object단위로 움직이기 때문에 개념을 잘 알아야 할 것 같습니다. 오늘 알아본 내용보다 더 많은 object가 있습니다. 기본 object의 사용법을 먼저 익힌 다음 차츰 알아 가야 될 것 같습니다. 오늘도… 한걸음……




참고문헌
https://kubernetes.io/docs/concepts/workloads/pods/
https://kubernetes.io/docs/concepts/storage/volumes/
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/
https://yoo11052.tistory.com/189
https://ozt88.tistory.com/64