2.7. CRD
2.7.1. 사용자 정의 리소스 정의를 사용하여 Kubernetes API 확장
Operator는 Kubernetes 확장 메커니즘인 CRD(사용자 정의 리소스 정의)를 사용하므로 Operator에서 관리하는 사용자 정의 오브젝트가 네이티브 Kubernetes 오브젝트처럼 보이고 작동합니다. 이 가이드에서는 클러스터 관리자가 CRD를 생성하고 관리하여 OpenShift Container Platform 클러스터를 확장할 수 있는 방법을 설명합니다.
2.7.1.1. 사용자 정의 리소스 정의
Kubernetes API에서 리소스는 특정 종류의 API 오브젝트 컬렉션을 저장하는 끝점입니다. 예를 들어 기본 제공 Pod 리소스에는 Pod 오브젝트의 컬렉션이 포함됩니다.
CRD(사용자 정의 리소스 정의) 오브젝트는 클러스터에서 종류라는 새로운 고유한 오브젝트 유형을 정의하고 Kubernetes API 서버에서 전체 라이프사이클을 처리하도록 합니다.
CR(사용자 정의 리소스) 오브젝트는 클러스터 관리자가 클러스터에 추가한 CRD에서 생성하므로 모든 클러스터 사용자가 새 리소스 유형을 프로젝트에 추가할 수 있습니다.
클러스터 관리자가 새 CRD를 클러스터에 추가하면 Kubernetes API 서버는 전체 클러스터 또는 단일 프로젝트(네임스페이스)에서 액세스할 수 있는 새 RESTful 리소스 경로를 생성하여 반응하고 지정된 CR을 제공하기 시작합니다.
클러스터 관리자가 다른 사용자에게 CRD에 대한 액세스 권한을 부여하려면 클러스터 역할 집계를 사용하여 admin, edit 또는 view 기본 클러스터 역할이 있는 사용자에게 액세스 권한을 부여할 수 있습니다. 클러스터 역할 집계를 사용하면 이러한 클러스터 역할에 사용자 정의 정책 규칙을 삽입할 수 있습니다. 이 동작은 새 리소스를 기본 제공 리소스인 것처럼 클러스터의 RBAC 정책에 통합합니다.
특히 운영자는 CRD를 필수 RBAC 정책 및 기타 소프트웨어별 논리와 함께 패키지로 제공하는 방식으로 CRD를 사용합니다. 또한 클러스터 관리자는 Operator의 라이프사이클 외부에서 클러스터에 CRD를 수동으로 추가하여 모든 사용자에게 제공할 수 있습니다.
클러스터 관리자만 CRD를 생성할 수 있지만 기존 CRD에 대한 읽기 및 쓰기 권한이 있는 개발자의 경우 기존 CRD에서 CR을 생성할 수 있습니다.
2.7.1.2. 사용자 정의 리소스 정의 생성
사용자 정의 리소스(CR) 오브젝트를 생성하려면 클러스터 관리자가 먼저 CRD(사용자 정의 리소스 정의)를 생성해야 합니다.
사전 요구 사항
-
cluster-admin사용자 권한을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
프로세스
CRD를 생성하려면 다음을 수행합니다.
다음 필드 유형을 포함하는 YAML 파일을 생성합니다.
CRD에 대한 YAML 파일의 예
apiVersion: apiextensions.k8s.io/v1 1 kind: CustomResourceDefinition metadata: name: crontabs.stable.example.com 2 spec: group: stable.example.com 3 versions: name: v1 4 scope: Namespaced 5 names: plural: crontabs 6 singular: crontab 7 kind: CronTab 8 shortNames: - ct 9
- 1
apiextensions.k8s.io/v1API를 사용합니다.- 2
- 정의의 이름을 지정합니다.
group및plural필드의 값을 사용하는<plural-name>.<group>형식이어야 합니다. - 3
- API의 그룹 이름을 지정합니다. API 그룹은 논리적으로 관련된 오브젝트의 컬렉션입니다. 예를 들어
Job또는ScheduledJob과 같은 배치 오브젝트는 모두 배치 API 그룹(예:batch.api.example.com)에 있을 수 있습니다. 조직의 FQDN(정규화된 도메인 이름)을 사용하는 것이 좋습니다. - 4
- URL에 사용할 버전 이름을 지정합니다. 각 API 그룹은 여러 버전(예:
v1alpha,v1beta,v1)에 있을 수 있습니다. - 5
- 특정 프로젝트(
Namespaced) 또는 클러스터의 모든 프로젝트(Cluster)에서 사용자 정의 오브젝트를 사용할 수 있는지 지정합니다. - 6
- URL에서 사용할 복수형 이름을 지정합니다.
plural필드는 API URL의 리소스와 동일합니다. - 7
- CLI 및 디스플레이에서 별칭으로 사용할 단수형 이름을 지정합니다.
- 8
- 생성할 수 있는 오브젝트의 종류를 지정합니다. 유형은 CamelCase에 있을 수 있습니다.
- 9
- CLI의 리소스와 일치하는 짧은 문자열을 지정합니다.
참고기본적으로 CRD는 클러스터 범위이며 모든 프로젝트에서 사용할 수 있습니다.
CRD 오브젝트를 생성합니다.
$ oc create -f <file_name>.yaml
다음에 새 RESTful API 끝점이 생성됩니다.
/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...
예를 들어 예제 파일을 사용하면 다음 끝점이 생성됩니다.
/apis/stable.example.com/v1/namespaces/*/crontabs/...
이 끝점 URL을 사용하여 CR을 생성하고 관리할 수 있습니다. 오브젝트 종류는 생성한 CRD 오브젝트의
spec.kind필드를 기반으로 합니다.
2.7.1.3. 사용자 정의 리소스 정의에 대한 클러스터 역할 생성
클러스터 관리자는 기존 클러스터 범위의 CRD(사용자 정의 리소스 정의)에 권한을 부여할 수 있습니다. admin, edit, view 기본 클러스터 역할을 사용하는 경우 해당 규칙에 클러스터 역할 집계를 활용할 수 있습니다.
이러한 각 역할에 대한 권한을 명시적으로 할당해야 합니다. 권한이 더 많은 역할은 권한이 더 적은 역할의 규칙을 상속하지 않습니다. 역할에 규칙을 할당하는 경우 권한이 더 많은 역할에 해당 동사를 할당해야 합니다. 예를 들어 보기 역할에 get crontabs 권한을 부여하는 경우 edit 및 admin 역할에도 부여해야 합니다. admin 또는 edit 역할은 일반적으로 프로젝트 템플릿을 통해 프로젝트를 생성한 사용자에게 할당됩니다.
사전 요구 사항
- CRD를 생성합니다.
프로세스
CRD의 클러스터 역할 정의 파일을 생성합니다. 클러스터 역할 정의는 각 클러스터 역할에 적용되는 규칙이 포함된 YAML 파일입니다. OpenShift Container Platform 컨트롤러는 사용자가 지정하는 규칙을 기본 클러스터 역할에 추가합니다.
클러스터 역할 정의에 대한 YAML 파일의 예
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 1 metadata: name: aggregate-cron-tabs-admin-edit 2 labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" 3 rbac.authorization.k8s.io/aggregate-to-edit: "true" 4 rules: - apiGroups: ["stable.example.com"] 5 resources: ["crontabs"] 6 verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] 7 --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view 8 labels: # Add these permissions to the "view" default role. rbac.authorization.k8s.io/aggregate-to-view: "true" 9 rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" 10 rules: - apiGroups: ["stable.example.com"] 11 resources: ["crontabs"] 12 verbs: ["get", "list", "watch"] 13
- 1
rbac.authorization.k8s.io/v1API를 사용합니다.- 2 8
- 정의의 이름을 지정합니다.
- 3
- 관리 기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
- 4
- 편집 기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
- 5 11
- CRD의 그룹 이름을 지정합니다.
- 6 12
- 이러한 규칙이 적용되는 CRD의 복수형 이름을 지정합니다.
- 7 13
- 역할에 부여된 권한을 나타내는 동사를 지정합니다. 예를 들어
admin및edit역할에는 읽기 및 쓰기 권한을 적용하고view역할에는 읽기 권한만 적용합니다. - 9
view기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.- 10
cluster-reader기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
클러스터 역할을 생성합니다.
$ oc create -f <file_name>.yaml
2.7.1.4. 파일에서 사용자 정의 리소스 생성
CRD(사용자 정의 리소스 정의)가 클러스터에 추가되면 CR 사양을 사용하여 파일에서 CLI를 통해 CR(사용자 정의 리소스)을 생성할 수 있습니다.
사전 요구 사항
- 클러스터 관리자가 클러스터에 CRD를 추가했습니다.
프로세스
CR에 대한 YAML 파일을 생성합니다. 다음 예제 정의에서
cronSpec및image사용자 정의 필드는Kind: CronTab의 CR에 설정됩니다.Kind는 CRD 오브젝트의spec.kind필드에서 제공합니다.CR에 대한 YAML 파일의 예
apiVersion: "stable.example.com/v1" 1 kind: CronTab 2 metadata: name: my-new-cron-object 3 finalizers: 4 - finalizer.stable.example.com spec: 5 cronSpec: "* * * * /5" image: my-awesome-cron-image
파일을 생성한 후 오브젝트를 생성합니다.
$ oc create -f <file_name>.yaml
2.7.1.5. 사용자 정의 리소스 검사
CLI를 사용하여 클러스터에 존재하는 CR(사용자 정의 리소스) 오브젝트를 검사할 수 있습니다.
사전 요구 사항
- CR 오브젝트는 액세스할 수 있는 네임스페이스에 있습니다.
프로세스
특정 종류의 CR에 대한 정보를 얻으려면 다음을 실행합니다.
$ oc get <kind>
예를 들면 다음과 같습니다.
$ oc get crontab
출력 예
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
리소스 이름은 대소문자를 구분하지 않으며 CRD에 정의된 단수형 또는 복수형 양식이나 짧은 이름을 사용할 수 있습니다. 예를 들면 다음과 같습니다.
$ oc get crontabs
$ oc get crontab
$ oc get ct
CR의 원시 YAML 데이터를 볼 수도 있습니다.
$ oc get <kind> -o yaml
예를 들면 다음과 같습니다.
$ oc get ct -o yaml
출력 예
apiVersion: v1 items: - apiVersion: stable.example.com/v1 kind: CronTab metadata: clusterName: "" creationTimestamp: 2017-05-31T12:56:35Z deletionGracePeriodSeconds: null deletionTimestamp: null name: my-new-cron-object namespace: default resourceVersion: "285" selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object uid: 9423255b-4600-11e7-af6a-28d2447dc82b spec: cronSpec: '* * * * /5' 1 image: my-awesome-cron-image 2
2.7.2. 사용자 정의 리소스 정의에서 리소스 관리
이 가이드에서는 개발자가 CRD(사용자 정의 리소스 정의)에서 제공하는 CR(사용자 정의 리소스)을 관리하는 방법을 설명합니다.
2.7.2.1. 사용자 정의 리소스 정의
Kubernetes API에서 리소스는 특정 종류의 API 오브젝트 컬렉션을 저장하는 끝점입니다. 예를 들어 기본 제공 Pod 리소스에는 Pod 오브젝트의 컬렉션이 포함됩니다.
CRD(사용자 정의 리소스 정의) 오브젝트는 클러스터에서 종류라는 새로운 고유한 오브젝트 유형을 정의하고 Kubernetes API 서버에서 전체 라이프사이클을 처리하도록 합니다.
CR(사용자 정의 리소스) 오브젝트는 클러스터 관리자가 클러스터에 추가한 CRD에서 생성하므로 모든 클러스터 사용자가 새 리소스 유형을 프로젝트에 추가할 수 있습니다.
특히 운영자는 CRD를 필수 RBAC 정책 및 기타 소프트웨어별 논리와 함께 패키지로 제공하는 방식으로 CRD를 사용합니다. 또한 클러스터 관리자는 Operator의 라이프사이클 외부에서 클러스터에 CRD를 수동으로 추가하여 모든 사용자에게 제공할 수 있습니다.
클러스터 관리자만 CRD를 생성할 수 있지만 기존 CRD에 대한 읽기 및 쓰기 권한이 있는 개발자의 경우 기존 CRD에서 CR을 생성할 수 있습니다.
2.7.2.2. 파일에서 사용자 정의 리소스 생성
CRD(사용자 정의 리소스 정의)가 클러스터에 추가되면 CR 사양을 사용하여 파일에서 CLI를 통해 CR(사용자 정의 리소스)을 생성할 수 있습니다.
사전 요구 사항
- 클러스터 관리자가 클러스터에 CRD를 추가했습니다.
프로세스
CR에 대한 YAML 파일을 생성합니다. 다음 예제 정의에서
cronSpec및image사용자 정의 필드는Kind: CronTab의 CR에 설정됩니다.Kind는 CRD 오브젝트의spec.kind필드에서 제공합니다.CR에 대한 YAML 파일의 예
apiVersion: "stable.example.com/v1" 1 kind: CronTab 2 metadata: name: my-new-cron-object 3 finalizers: 4 - finalizer.stable.example.com spec: 5 cronSpec: "* * * * /5" image: my-awesome-cron-image
파일을 생성한 후 오브젝트를 생성합니다.
$ oc create -f <file_name>.yaml
2.7.2.3. 사용자 정의 리소스 검사
CLI를 사용하여 클러스터에 존재하는 CR(사용자 정의 리소스) 오브젝트를 검사할 수 있습니다.
사전 요구 사항
- CR 오브젝트는 액세스할 수 있는 네임스페이스에 있습니다.
프로세스
특정 종류의 CR에 대한 정보를 얻으려면 다음을 실행합니다.
$ oc get <kind>
예를 들면 다음과 같습니다.
$ oc get crontab
출력 예
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
리소스 이름은 대소문자를 구분하지 않으며 CRD에 정의된 단수형 또는 복수형 양식이나 짧은 이름을 사용할 수 있습니다. 예를 들면 다음과 같습니다.
$ oc get crontabs
$ oc get crontab
$ oc get ct
CR의 원시 YAML 데이터를 볼 수도 있습니다.
$ oc get <kind> -o yaml
예를 들면 다음과 같습니다.
$ oc get ct -o yaml
출력 예
apiVersion: v1 items: - apiVersion: stable.example.com/v1 kind: CronTab metadata: clusterName: "" creationTimestamp: 2017-05-31T12:56:35Z deletionGracePeriodSeconds: null deletionTimestamp: null name: my-new-cron-object namespace: default resourceVersion: "285" selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object uid: 9423255b-4600-11e7-af6a-28d2447dc82b spec: cronSpec: '* * * * /5' 1 image: my-awesome-cron-image 2
