[Kubernetes] Object

쿠버네티스는 크게 오브젝트(object)와 오브젝트를 관리하는 컨트롤러(controller)로 나눠어져 있다.

 

💡 쿠버네티스 오브젝트

쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다.
구체적으로 말하자면, 다음 같이 기술할 수 있다.

• 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
• 그 애플리케이션이 이용할 수 있는 리소스
• 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
  
  

대부분의 쿠버네티스 오브젝트는 오브젝트 구성을 결정하는 두개의 중접된 오브젝트 필드인 status와 spec를 포함한다.

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

 

💡 생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, 쿠버네티스 API를 이용해야 한다. 예를 들어, kubectl 커맨드-라인 인터페이스를 이용할 때, CLI는 사용자 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 클라이언트 라이브러리 중 하나를 이용하여 사용자정의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.

 

쿠버네티스 오브젝트 기술

쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 kubectl을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. 대부분의 경우 정보를 .yaml 파일로 kubectl에 제공한다. kubectl은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.

 

요구되는 필드

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

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

💡 필드에 대한 자세한 설명은 Kubernetes API Reference Docs 참조

 

📌 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec을 보여주는 .yaml 파일 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

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

 

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

 

✍️ Service
서비스는 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법이다.
파드는 컨트롤러가 관리하므로 고정되어 있지 않고 클러스터 안을 옮겨 다닌다. 이 과정에서 노드를 옮겨 다니며 실행되기도 하고 클러스터 안 파드의 IP가 변경되고 한다. 이렇게 동적으로 변하는 파드들에 고정적으로 접근할 때 사용하는 방법이 쿠버네티스의 서비스이다.
서비스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하여 파드가 클러스터 안 어디에 있든 고정 주소를 통해 접근이 가능하다.

 

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

 

✍️ Volume
쿠버네티스에서 파드는 고정된 개념이 아니며 끊임없이 사라지고 생성된다. 그렇기 때문에 파드는 디렉터리도 임시로 사용한다. 파드가 사라지더라도 사용할 수 있는 디렉터리는 볼륨 오브젝트를 통해 생성하여 사용할 수 있다.

 

 

쿠버네티스 컨트롤러

💡 컨트롤러란?

• 파드를 관리하는 역할을 한다. 다양한 목적에 따라 쿠버네티스에서 제공하는 컨트롤러를 사용하면 된다. 쿠버네티스에서 제공하는 컨트롤러의 종류로는 "레플리케이션 컨트롤러", "레플리카 세트", "디플로이먼트", "데몬" , "스테이트풀세트", "크론잡" 등이 있다.

📌 용도별 컨트롤러

일반적으로 상태를 유지하지 않아도 되는 파드를 관리하는 경우
-> 레플리케이션 컨트롤러(Relication Controller)
-> 레플리카 세트(Replica Set)
-> 디플로이먼트(Deployment)

클러스터 전체에 배포가 필요한 파드를 관리하는 경우
-> 데몬 셋(Deamon Set)
-> 상태관리가 필요한 파드를 관리하는 경우
-> 스테이트풀세트(Stateful Set)

배치성 작업을 진행하는 파드를 관리하는 경우
-> 크론잡(Cronjob)

✍️ 레플리케이션 컨트롤러(Replication controller)
쿠버네티스 프로젝트 초기부터 존재하던 컨트롤러이다. 실행할 파드의 개수를 지정할 수 있고 지정한 개수만큼 파드가 유지되도록 관리한다. 현재는 레플리케이션 컨트롤러와 비슷한 역할을 하는 컨트롤러들을 많이 사용한다.

✍️ 레플리카 세트(ReplicaSet)
기본적으로 하는 역할은 레플리케이션 컨트롤러와 비슷하지만 집합기반의 셀렉터(Selector)를 지원한다. 집합기반의 셀렉터는 in, notin, exists와 같은 연산을 제공하며 조건에 따라 필요로하는 레이블을 선택할 수 있다. 추가로 레플리카 세트에서는 파드 업데이트시 rolling-update가 가능하다.

 

✍️ 디플로이먼트(Deployment)
상태가 없는 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러이다. 디플로이먼트는 레플리카세트를 관리하면서 좀 더 앱 배포에 관련된 자세한 작업이 가능하다. 단순 파드의 배포뿐만이 아닌 배포 방식, 버전 롤백 등이 설정 가능하다.

 

✍️ 데몬세트(Deamon Set)
데몬세트는 클러스터 전체 노드에 특정 파드를 실행할 때 사용한다. 예를 들어 노드마다 존재하는 로그 수집기나 시스템 리소스를 받아 볼 수 있는 Exporter 같은 것들이 있다. 데몬셋이 대상으로 하고 있던 노드가 클러스터에 제거되는 경우, 다른 노드로 이동하여 파드를 실행시키지 않고 제거되는 특성이 있다.

 

✍️ 스테이트 풀 세트(StatefulSet)
레플리케이션 컨트롤러, 레플리카세트, 디플로이먼트가 stateless한 파드를 관리하는 용도였다면, 스테이트 풀 세트는 상태가 있는 파드를 관리하는 컨트롤러이다. 상태가 있다는 의미는 컨테이너가 종료 되더라도 컨테이너에서 필요로 하는 데이터가 남게(Stateful 한 상태)되어 파드를 재시작 하더라도 데이터를 보존할 수 있다.

 

✍️ 잡(Job)
배치성 작업을 진행하기 위해 사용하는 컨트롤러이다. 실행된 후 종료해야 하는 성격의 작업을 실행시킬 때 사용하는 컨트롤러라고 볼 수 있다. 잡의 종류로는 단일잡 / 완료된 잡 개수가 있는 병렬 잡 / 워크 큐가 있는 병렬잡이 있다.

 

✍️ 크론잡(CronJob)
크론잡은 잡을 시간 기준으로 관리하도록 진행한다. 지정한 시간에 한번만 잡을 실행하거나 지정한 시간동안 주기적으로 잡을 반복할 수 있다.

 

📌 ReplicaSet & Deployment

 

ReplicaSet
Deployment의 개념중에서 가장 중요한것은 ReplicaSet이다. Replication Controller의 새로운 버전으로 Label Selector를 통해 노드 상의 여러 Pod의 생성/복제/삭제 등의 라이프 싸이클을 관리한다.

• 지정한 Replica의 숫자만큼 Pod 수 생성/유지
• Label Selector를 통한 Pod 타겟팅

 

Deployment

• Kubernetes에서 어플리케이션 단위를 관리하는 Controller 이며 Kubernetes의 최소 유닛인 Pod에 대한 기준스펙을 정의한 Object이다.
• Kubernetes에서는 각 Object를 독립적으로 생성하기 보다는 Deployment를 통해서 생성하는 것을 권장하고 있으며, Pod와 ReplicaSet의 기준정보를 지정할 수 있다.
• 이러한 Deployment는
  • Pod의 배포되고 update 되는 모든 버전을 추적할 수 있다.
  • 배포된 Pod에 대한 rollback을 수행할 수 있다.
  • Pod의 scale in / out 되는 기준을 정의한다.

📌 즉, 개념적으로 Deployment = ReplicaSet +Pod+history이며 ReplicaSet 을 만드는 것보다
     더 윗 단계의 선언(추상표현)이다.

References
https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/
https://real-dongsoo7.tistory.com/134