[Kubernetes] 쿠버네티스 오브젝트

쿠버네티스 오브젝트는 클러스터 상태를 나타내는 단위로 의도를 담은 레코드이다.

오브젝트를 생성하게 되면 k8s는 그 오브젝트 생성을 보장하기 위해 지속적으로 작동한다.

오브젝트를 생성함으로써, 클러스터 워크로드가 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전달한다.

이것이 바로 클러스터에 대한 의도한 상태가 된다.

 

공식 문서의 정의를 조금 풀어보면

오브젝트는 쿠버네티스 클러스터 내에서 일어나는 모든 것을 설명해 주는 레코드인데,

복제본이 몇 개 필요하고 네트워크 설정은 어떻게 하고 등이 이 레코드에 담기게 된다. 

이들은 영속성을 가지기 때문에 쿠버네티스는 이 레코드에 적힌 대로 유지하기 위해서 노력한다.

 

오브젝트에는 무엇이?👀

오브젝트에 대해서 더 알아보기 전에 그럼 오브젝트에는 무엇이 있을까

오브젝트는 기본 오브젝트와 기본 오브젝트를 더 편하게 쓰기 위해서 존재하는 추가적인 오브젝트가 존재 한다.

 

기본 오브젝트(Basic Object)

• 파드 (Pod) 
  • 쿠버네티스 실행의 최소 단위, 컨테이너의 집합
• 서비스 (Service)
  • 파드의 IP는 유동적이기 때문에 통신하기 위해서는 고정적인 IP와 로드밸런싱 등을 지원
• 볼륨 (Volume)
  • 영구적인 스토리지
• 네임스페이스 (Namespace)
  • 리소스의 논리적 격리를 위해서 사용

 

추가적인 오브젝트

• 디플로이먼트 (Deployment)
• 레플리카셋 (ReplicaSet)
• 스테이트풀셋 (StatefulSet)
• 데몬 셋 (DaemonSet)
• 컨피그맵 (ConfigMap)
• PV (PersistentVolume)
• PVC (PersistentVolumeClaim)

 

오브젝트 명세 (spec)와 상태(status)

거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해 주는 두 개의 중첩된 오브젝트 필드를 포함하는데,

오브젝트 spec과 오브젝트 status이다.

spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에 원하는 특징(의도한 상태)에 대한 설명을 제공해서 설정한다.

status는 쿠버네티스 오브젝트의 상태로, 컨트롤 플레인은 오브젝트의 현재 상태와 정의한/의도한 상태와 일치시키려고 관리한다.

 

오브젝트 기술하기

보통. yaml 파일로 kubectl에 제공하여 오브젝트를 기술한다.(kubectl이 API 요청이 이루어질 때, json 변환)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

요구되는 필드

생성하고자 하는 쿠버네티스 오브젝트에 대한. yaml 파일 내, 다음 필드를 위한 값들을 설정해 줘야 한다.

• apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
• kind - 어떤 종류의 오브젝트를 생성하고자 하는지
• metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분 지어 줄 데이터
• spec - 오브젝트에 대해 어떤 상태를 의도하는지를 기술하며, 정확한 포맷은 오브젝트 마다 상이

 

오브젝트 이름과 ID

클러스터의 각 오브젝트 해당 유형의 리소스에 대한 고유한 이름과 전체 클러스터에 걸쳐 고유한 UID를 소유

 

레이블과 셀렉터

레이블은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍으로 오브젝트 식별에 사용자가 사용

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }

 

ex: "environment" : "dev", "environment" : "qa", "environment" : "production"

 

접두사/이름 형식

접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: kube-scheduler, kube-controller-manager, kube-apiserver, kubectl 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어 있다.

레이블은 이름과 uid와 다르게 고유하지 않다. 다수의 오브젝트가 같은 레이블을 가지는 경우가 존재

레이블 셀럭터를 통해 우리는 오브젝트를 식별할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100**

accelerator가 nvidia-tesla-p100인 레이블을 가진 노드 선택

 

네임스페이스

네임스페이스란 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘이다.

이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간 유일할 필요는 없다.

네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트(디플로이먼트, 서비스)에만 유효하고

클러스터 범위 오브젝트(스토리지 클래스, pv)에는 적용 불가이다.

초기 네임스페이스

초기에 4개의 네임스페이스를 가지게 된다.

default

쿠버네티스에는 이 네임스페이스가 포함되어 있으므로 먼저 네임스페이스를 생성하지 않고도 새 클러스터를 사용할 수 있다.

kube-node-lease

이 네임스페이스는 각 노드와 연관된 리스 오브젝트를 갖는다. 노드 리스는 kubelet이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.

kube-public

이 네임스페이스는 모든 클라이언트(인증되지 않은 클라이언트 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.

kube-system

쿠버네티스 시스템에서 생성한 오브젝트(시스템 프로세스)를 위한 네임스페이스.

kubectl get namespace

 

모든 오브젝트가 네임스페이스에 속하지 않는다

노드, pv, 네임스페이스 자체도 네임스페이스에 속하지 않는다.

# 네임스페이스에 속하는 리소스
kubectl api-resources --namespaced=true

# 네임스페이스에 속하지 않는 리소스
kubectl api-resources --namespaced=false

 

어노테이션

오브젝트에 대한 부가적인 정보를 저장하고 관리하는 데 사용된다.

라벨과 다르게 어노테이션은 오브젝트를 식별하거나 선택하기 위해서 사용되지 않는다.

어노테이션은 키/값 쌍으로 이루어진다.

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "<https://hub.docker.com/>"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

 

 

[참고 자료]

쿠버네티스 공식 문서

- https://kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 컴포넌트