Kubernetes

Kubernetes 기초 - Custom Resources

사실 나도 모름 2024. 1. 24. 23:22
  1. CustimResources의 이해
  2. CustomResourcesDefinition 사용

1. CustomResources의 이해

https://kubernetes.io/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/

 

커스텀 리소스

커스텀 리소스 는 쿠버네티스 API의 익스텐션이다. 이 페이지에서는 쿠버네티스 클러스터에 커스텀 리소스를 추가할 시기와 독립형 서비스를 사용하는 시기에 대해 설명한다. 커스텀 리소스를

kubernetes.io

 

 

Resources의 정의

Kubernetes API에서 특정 종류의 API 오브젝트 모음을 저장하는 Endpoint

 

우리가 kubectl api-resources 명령으로 모든 리소스들의 정보를 볼 수 있다.

각 리소스들

 

이 부분에서 네임스페이스에 종속된 리소스(true)도 있지만 종속되지 않은 리소스(false)도 있다.

우리가 주의 깊게 확인해야 할 부분은 APIVERSION이다.

yaml 파일을 구성할 때 항상 등장하는 필드기 때문에 모를리는 없을 것이다.

 

각 리소스들은 apiGroup을 갖는다.

API Group이 무엇인지는 이전 포스트에서 Role과 RoleBinding에 대한 내용에서도 한번 나오기도했다.

apiVersion의 구조
<API Group>/<Version>

 

 

오늘 살펴볼 CustomResourceDefinition 줄여서 CRD라고 불리는 것을 정의하기 위해서는 특정 API Group에 소속되어야 하며 우리가 원하는 대로 리소스를 정의해야 한다.

또한 네임스페이스에 종속되는지, apiVersion은 어떻게 되는지, 이름을 줄여서 쓸 수 있는지, 상세 스펙에 어떤 필드를 갖는지 등 모든 정보를 자신이 정의하는 것이다.

즉, pod나 ingress, deployment 와 같은 리소스처럼 자신만의 리소스를 정의하여 사용할 수 있는 것이 CustomResourceDefinition이 되겠다.

 

 

 

 


2. CustomResourcesDefinition 사용

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

 

Extend the Kubernetes API with CustomResourceDefinitions

This page shows how to install a custom resource into the Kubernetes API by creating a CustomResourceDefinition. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

kubernetes.io

 

 

공식 문서에 나온 예시는 다음과 같다.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # name must match the spec fields below, and be in the form: <plural>.<group>
  name: crontabs.stable.example.com
spec:
  # group name to use for REST API: /apis/<group>/<version>
  group: stable.example.com
  # list of versions supported by this CustomResourceDefinition
  versions:
    - name: v1
      # Each version can be enabled/disabled by Served flag.
      served: true
      # One and only one version must be marked as the storage version.
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer
  # either Namespaced or Cluster
  scope: Namespaced
  names:
    # plural name to be used in the URL: /apis/<group>/<version>/<plural>
    plural: crontabs
    # singular name to be used as an alias on the CLI and for display
    singular: crontab
    # kind is normally the CamelCased singular type. Your resource manifests use this.
    kind: CronTab
    # shortNames allow shorter string to match your resource on the CLI
    shortNames:
    - ct

 

위의 예시는 CronTab이라는 유형의 사용자 정의 리소스를 생성하는 yaml 코드다.

위 코드에서 spec.group으로 명시한 stable.example.com과 spec.versions.name으로 명시한 v1이 합쳐서 apiVersion이 되는 것이다.

그리고 spec필드 하위에 기재된 properties가 우리가 yaml 코드를 작성할 때 명시하는 spec의 상세 정보들을 기재하는 것이며, 가장 아래에 names가 곧 리소스의 이름이 되는 것이다.

 

생성된 CRD를 사용하여 CronTab 오브젝트를 생성하는 yaml 코드를 구성하면 다음과 같을 것이다.

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image

 

 

가장 위의 yaml코드를 실행하면 CRD가 하나 생성된다.

우리가 정의한 리소스가 kubectl api-resources에도 출력된다.

crontabs

 

 

두번째 yaml코드를 실행하여 오브젝트를 생성해보자.

crontab 오브젝트
yaml 형태로 표시하면 다음과 같이 된다.

 

우리는 앞서 CRD를 정의할 때 scope에 Namespaced라고 정의했기 때문에 다른 네임스페이스에 생성도 가능하고 replicas 필드도 정의했기에 replicas의 기능을 이용할 수 있다.

 

CRD를 삭제하면 기존에 생성했던 crontab 오브젝트들도 함께 사라진다.

실제로 많이 사용하는지는 의문이지만 특정 응용프로그램이나 서비스의 관리와 확장의 목적으로 사용되는 것이므로 그냥 이런게 있구나 정도로 알아두면 좋을 듯하다.

'Kubernetes' 카테고리의 다른 글

Kubernetes 기초 - Helm(2)  (0) 2024.01.27
Kubernetes 기초 - Helm(1)  (0) 2024.01.25
kubernetes 기초 - RBAC(2)  (0) 2024.01.24
Kubernetes 기초 - RBAC(1)  (0) 2024.01.23
Kubernetes 기초 - Storage(5)  (0) 2024.01.23