[Kubernetes] Object의 정의와 관리

✔️ Object 

쿠버네티스 오브젝트 이해하기

 

✔️ Object 리스트 확인

kubectl api-resouces

해당 명령을 통해 쿠버네티스에서 생성할 수 있는 모든 종류의 오브젝트를 확인할 수 있다.

NAME

SHORTNAMES

APIVERSION

NAMESPACED

KIND

NAME과 KIND의 차이는 NAME은 소문자로 시작하며 복수형이다.

KIND는 대문자로 시작하며 명사 + 명사 조합일 경우 반드시 명사의 첫글자를 대문자로 쓴다는 것이다.
KIND는 일반적으로 단수형이다. (예외 Endpoints)

 

NAME은 kubectl 명령어에서 오브젝트를 지정할 때 사용한다.

kubectl get nodes
kubectl get services
kubectl get pods
kubectl get no
kubectl get svc

SHORTNAMES이 없는 리소스도 있으며 SHORTNAMES 또한 오브젝트를 지정할 때 사용한다.
하지만 SHORTNAMES는 yaml 파일에서 사용할 수 없다.

APIVERSION - 사용 가능한 API 버전이다.

NAMESPACED - 네임스페이스 개념 사용 유무이다.

KIND - 오브젝트의 종류이다.

 

✔️ 오브젝트 정의

<오브젝트의 명세와 상태>

• 명세 : spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에 원하는 특징(의도한 상태)에 대한 설명을 제공해서 생성한다.
• 상태 : 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태를 설명한다.

k8s의 리소스를 생성하는 yaml은 기본적으로 다음 4가지의 구성을 가진다.

• apiversion: 지원하는 오브젝트의 버전
• kind: 오브젝트의 종류
• metadata: 오브젝트의 메타데이터 (이름, 네임스페이스, 레이블, 어노테이션 등)
• spec: 오브젝트를 선언한다.

오브젝트 종류에 따라 spec이 없는 경우도 있으나 극히 드물다.

 

example.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

kubectl explain <Resource Name>

해당 오브젝트를 어떻게 정의해야 하는지를 확인할 수 있다.
문서로 정리되어 있지 않아 해당 명령어로만 확인할 수 있다. 

yaml 파일에서 어떻게 정의하는지 version은 어떤 버전이 있는지를 확인할 수 있다.

KIND:
VERSION:
DESCRIPTION:
FIELDS: 
    apiVersion <string>
    kind <string>
    metadata <Object>
    spec <Object>
    staus <Object>

status - k8s 클러스터 시스템에서 해당 리소스의 가장 최근에 관찰된 상태 정보를 저장한다. read-only 속성이다.

 

kubectl explain pods.apiVersion
KIND:     Pod
VERSION:  v1

FIELD:    apiVersion <string>

DESCRIPTION:
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

오브젝트의 세부 속성을 계층적으로 내려가며 확인할 수 있다.

kubectl explain pods
kubectl explain pods.metadata
kubectl explain pods.spec
kubectl explain pods.spec.containers
kubectl explain pods.spec.containers.images
kubectl explain pods.spec --recursive
kubectl explain pods.spec.containers --recursive

해당 오브젝트에 적용 가능한 모든 필드에 대한 변수형을 확인할 수 있다.

직접 yaml 작성할 때 explain 명령어를 자주 봐야한다.

 

✔️ apiversion - 오브젝트의 버전

API 개요 | Kubernetes

kubectl api-versions

현재 사용하는 k8s 버전에서 지원하는 API 목록을 확인할 수 있다.
마이너 버전이 바뀜에 따라 지원되는 API 종류와 버전이 다를 수 있다.

apps/v1

• apps: 그룹
• v1: 버전core 그룹 : 그룹이 없는 api는 core 그룹이다.

k8s의 기능 확장으로 여러 형태의 그룹을 붙여서 API를 구분하여 사용하기 시작했다.

버전은 크게 3가지 형태가 존재한다.

• Stable
  • vX
  • v1, v2
  • 안정화된 버전
• Beta
  • v1betaX, v2betaX
  • 충분히 검증되어 오류는 거의 없다.
  • 단, 버전이 올라가면 기능 변경이 있을 수 있다.
    • downtime 발생 가능성이 있음 : 특정 기능을 사용하기 위해 재시작 필요
  • Mission Critical : 절대로 죽으면 안되는 형태의 서비스로 고가용성, 24/7 필수
    가능하면 beta 버전을 사용하지 않는 것을 권장한다.
• Alpha
  • v1alphaX, v2alphaX
  • 기본적으로 비활성화되어 있다.
  • 개발중인 API : 언제든지 기능 변경이 있을 수 있고 잦은 오류의 가능성이 존재

개발 순서
Dev -> Alpha -> Beta -> Stable

v1alpha1 -> v1alpha2 -> v1alpha3 -> v1beta1 -> v1beta2 -> v1

vagrant@k8s-node1:~$ kubectl api-versions
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2

오토 스케일링의 경우 v1이 있고 v2의 beta1, beta2가 있다.
즉, 오토 스케일링 그룹에 속하는 오브젝트는 세가지 버전을 사용할 수 있다.

안정적인 사용을 위해서는 v1을 사용하며 최신 기능을 사용하려면 v2beta1, v2beta2를 사용한다.

 

✔️ kind - 오브젝트의 종류

생성하려는 오브젝트의 종류가 무엇인지를 지정한다.

• Label/LabelSelector
• Workload
  • Pod
  • Controller
    • ReplicationController
    • ReplicaSets
    • DaemonSets
    • Jobs
    • CronJobs
    • Deployments
    • StatefulSets
    • HorizontalPodAutoscaler

• Network
  • Service
  • Endpoints
  • Ingress

• Storage
  • PersistentVolume
  • PersistentVolumeClaim
  • ConfigMap
  • Secret

• Authentication
  • ServiceAccount
  • RBAC
    • Role
    • ClusterRole
    • RoleBinding
    • ClusterRoleBinding

• Resource Isolation
  • Namespaces

• Resource Limits
  • Limits
  • Requests
  • ResourceQuota
  • LimitRange

• Scheduling
  • NodeName
  • NodeSelector
  • Affinity
    • Node Affinity
    • Pod Affinity
    • Pod Anti Affinity
  • Taints/Tolerations
  • Drain/Cordon

✔️ metadata - 오브젝트의 메타데이터

metadata - 오브젝트의 메타데이터를 지정한다.
메타데이터란 데이터를 설명하기 위한 데이터를 말한다.

우리가 리눅스에서 ls -l 명령을 실행하면
파일의 이름, 권한, 하드링크의 개수가 몇개인지 등 파일에 대한 정보를 알 수 있는데 이를 파일의 메타데이터라 한다.

오브젝트의 메타데이터에는 리소스의 이름, 리소스의 라벨(Label), 주석(annotation) 등을 붙인다.

 

✔️ spec - 오브젝트를 선언한다.

오브젝트의 정의에서 가장 중요한 부분은 spec이다.
spec의 하위에는 여러가지 내용이 들어갈 수 있는데 kind에 따라서 spec의 내용이 달라진다.
즉, 어떤 종류의 오브젝트를 정의하느냐에 따라서 spec의 내용이 달라진다.

리스트가 아니므로 정의하는 내용의 순서는 상관없다.

 

✔️ 오브젝트 관리

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/object-management/

• 명령형 커맨드 : YAML 작성하지 않고 명령어로만 오브젝트를 정의하는 것
  • kubectl create
  • kubectl run
  • kubectl expose
    
    
• 명령형 오브젝트 구성 : YAML 파일 작성으로 오브젝트를 정의
  

YAML 파일 코드 수준에서 순서를 지키는 것이 아니다.
하나의 어플리케이션을 구축하기 위해서는 여러개의 오브젝트를 사용해야 하는데,
여러개의 YAML 파일이 10개(Pod, Svc, Endpoints, PV, PVC ...)가 있다면 하나씩 순서를 지키면서 실행하는 것

• • kubectl create  -f a.yaml 
    
  • kubectl replace  -f a.yaml
    
  • kubectl patch  -f a.yaml
    
  • kubectl delete  -f a.yaml
    
    
• 선언형 오브젝트 구성 : YAML 파일의 모음을 한번에 실행하는 것
  • kubectl apply  -f resources/

 

-f : 파일 옵션
명령형, 선언형 오브젝트 구성은 파일을 지정하느냐 디렉토리를 지정하느냐에 따라 구분되기도 한다.