[쿠버네티스 쉽게 이해하기 5] 쿠버네티스 오브젝트 정의 파일 쉽게 만들기

쿠버네티스 오브젝트를 생성하기 위해서는 보통 명세Specification를 정의한 야믈 파일을 만들어야 합니다.

공식적인 명칭은 매니페스트(Manifest)파일인데, 대부분 야믈 파일이라고 부릅니다. 

여러분들이 직접 오브젝트 정의 파일을 만들어야 할 경우도 많기 때문에 이번에는 오브젝트 정의 파일을 쉽게 만드는 방법을 배워 보도록 하겠습니다.
먼저 오브젝트 정의 파일의 구조와 문법을 이해하고 기존 오브젝트를 이용하여 새로운 오브젝트 정의 파일을 빠르게 만드는 법을 설명하겠습니다.

이전 절에서 실습한 오브젝트 중 네임스페이스, 서비스 어카운트, 컨피그맵, 시크릿, 클러스터롤 바인딩, 롤바인딩은 야믈 파일로도 만들 수 있지만 kubectl로 바로 만들 수 있기도 합니다.
이 방법은 이후 각 리소스에 대해 다루면서 설명하겠습니다.

5.1 쿠버네티스 오브젝트 정의 파일 구조

모든 오브젝트 정의 파일은 kind, apiVersion, metadata, 리소스별 추가 항목으로 구성되어 있습니다.

예를 들어 서비스 ‘member’의 오브젝트 정의 파일은 아래와 같습니다.

apiVersion: v1 kind: Service metadata:   name: member   namespace: ott spec:   type: ClusterIP   selector:     app: member   ports:   - name: port1     port: 3001     targetPort: 3001

kind는 이 오브젝트가 어떤 리소스인지를 나타냅니다. 쿠버네티스 리소스 목록은 아래 명령으로 확인할 수 있습니다.

[root@osboxes temp]# k api-resources

주요 쿠버네티스 리소스는 아래와 같습니다.
정의할 오브젝트의 리소스 종류(KIND)를 ‘kind’ 항목에 지정하면 됩니다.

리소스명 (NAME)	단축명 (SHORT NAMES)	API Group/VERSION (APIVERSION)	네임스페이스 정의 (NAME SPACED)	리소스 종류 (KIND)
clusterrolebindings		rbac.authorization.k8s.io/v1	False	ClusterRoleBinding
clusterroles		rbac.authorization.k8s.io/v1	False	ClusterRole
configmaps	cm	v1	True	ConfigMap
cronjobs	cj	batch/v1	True	CronJob
daemonsets	ds	apps/v1	True	DaemonSet
deployments	deploy	apps/v1	True	Deployment
endpoints	ep	v1	True	Endpoints
horizontalpodautoscalers	hpa	autoscaling/v1	True	HorizontalPodAutoscaler
ingresses	ing	networking.k8s.io/v1	True	Ingress
jobs		batch/v1	True	Job
namespaces	ns	v1	False	Namespace
networkpolicies	netpol	networking.k8s.io/v1	True	NetworkPolicy
nodes	no	v1	False	Node
persistentvolumeclaims	pvc	v1	True	PersistentVolumeClaim
persistentvolumes	pv	v1	False	PersistentVolume
pods	po	v1	True	Pod
podsecuritypolicies	psp	policy/v1beta1	False	PodSecurityPolicy
replicasets	rs	apps/v1	True	ReplicaSet
rolebindings		rbac.authorization.k8s.io/v1	True	RoleBinding
secrets		v1	True	Secret
serviceaccounts	sa	v1	True	ServiceAccount
services	svc	v1	True	Service
statefulsets	sts	apps/v1	True	StatefulSet
storageclasses	sc	storage.k8s.io/v1	False	StorageClass

<팁>
위 표를 모두 외울 필요는 없습니다.
리소스 이름만 알면 아래 명령으로 필요한 리소스의 종류명, API 버전을 알 수 있습니다.
kubectl api-resources | grep {리소스명}

[root@osboxes ott]# k api-resources | grep services services  svc    v1     true    Service

</>

<팁>
쿠버네티스 오브젝트에 대해 어떤 명령을 내릴 때 리소스의 단축명(SHORTNAMES)을 사용할 수 있습니다.
예를 들어 ‘k get configmaps’과 ‘k get cm’은 동일한 결과를 리턴 합니다.
또한 리소스명의 마지막 ‘s’는 생략해도 됩니다. 즉 ‘k get configmap’도 동작 합니다.
</>

‘apiVersion’은 쿠버네티스 리소스가 사용하는 API 그룹과 API 버전을 지정 합니다.
위 쿠버네티스 목록의 ‘API VERSION’열에 있는 값을 지정하면 됩니다.

‘metadata’는 오브젝트의 기본 정보를 정의하는 부분입니다.
하위에 반드시 있어야 할 항목은 ‘name’입니다. ‘name’에는 오브젝트의 이름을 지정 합니다.
또한 특정 네임스페이스에 생성하는 오브젝트는 ‘namespace’ 항목도 추가할 수 있습니다.
위 리소스 목록에서 ‘네임스페이스 정의(NAMESPACED)’가 ‘True’인 리소스만 ‘namespace’를 지정할 수 있습니다.

‘리소스별 추가항목'은 리소스별로 모두 다르기 때문에 쿠버네티스의 공식 문서를 참조하여 정의하여야 합니다.
쿠버네티스 공식 문서 주소는 ‘https://kubernetes.io/docs/home/’입니다.
아래와 같이 검색 기능을 이용하여 필요한 리소스의 정보와 예제를 참고하면 됩니다.

5.2 쿠버네티스 오브젝트 정의 파일 규칙

오브젝트 정의 파일은 야믈yaml 또는 제이슨json 형식으로 작성할 수 있습니다.
하지만 거의 모든 사람들이 야믈 형식을 사용하고 있습니다. 쿠버네티스 엔진은 내부적으로 야믈을 제이슨으로 변환하여 요청을 처리 합니다.

야믈 파일의 공통 규칙은 아래와 같습니다.
- 들여쓰기(인덴테이션Indentation)는 공백이나 탭으로 통일
- 키Key는 대소문자 구별
- 키Key와 값Value은 콜론으로 구별하고 콜론 뒤에는 한 칸 띄움
- 복수 값 지정할 때는 대시(‘-’)를 이용하고 대시 뒤에는 한 칸 띄움

<팁>
들여쓰기는 거의 모든 사람들이 공백을 사용합니다.
</>

아래는 일부 예외는 있지만 대부분의 야믈 항목에 적용되는 규칙입니다.
- 복수형으로 끝나는 키Key 이름의 값은 대시로 복수값 지정. 단, annotations, labels, matchLabels는 예외적으로 대시를 사용하지 않고 복수값 지정함

아래 예에서 ❶ annotations는 복수형이지만 하위 값들을 지정할 때 ‘-’를 사용하지 않았습니다.
반면 ❷ rules와 ❸ paths는 하위 값들을 지정할 때 ‘-’를 사용하여 정의 합니다.

- 상위 항목의 들여쓰기와 복수값을 지정하는 대시의 들여쓰기는 동일하게 함
예를 들어 위 인그레스 오브젝트의 ‘paths’항목의 들여쓰기와 하위 값 ‘- path’의 들여쓰기는 동일 합니다. 하위값의 대시를 상위 항목 보다 한 단계 들여쓰기해도 문제는 없으나 대부분 동일하게 맞춥니다.

처음에는 야믈 파일 작성 시 위 공통 규칙을 어기거나 오타로 인해 시행 착오를 많이 거칩니다.
위 공통 규칙을 위배 했는지는 아래 사이트에서 미리 검사해 볼 수 있습니다.
하지만 아쉽게도 쿠버네티스에서 정의되지 않은 키 이름이거나 값이 틀린 것까지는 검사하지 못합니다. 단순히 야믈 문법만 검사해 주는 페이지 입니다. 그래도 초기에는 도움이 좀 됩니다.
http://www.yamllint.com/

<팁>
kubectl의 옵션인 ‘--dry-run=client’을 이용하여 명령을 실제 실행하기 전에 그 명령이 유효한지 검사해 볼 수 있습니다.
아래는 ‘apiVersion: apps/v2’로 했을때의 검사 결과 입니다.

[root@osboxes temp]# kubectl apply -f deploy.yaml --dry-run=client error: unable to recognize "deploy.yaml": no matches for kind "Deployment" in version "apps/v2"

</>

5.3 기존 오브젝트를 이용한 오브젝트 정의 파일 만들기

기존에 동일한 종류의 리소스로 배포된 오브젝트가 있다면 그 오브젝트의 야믈 내용을 이용해서 쉽게 새로운 오브젝트를 만들 수가 있습니다.

아래와 같은 순서로 하시면 됩니다.

1) 기존 오브젝트의 야믈 내용을 파일로 추출
‘get’명령과 ‘-o yaml’ 옵션을 이용하여 오브젝트 정의 내용을 구하고 그 결과를 파일로 만듭니다.

문법: kubectl get {리소스KIND} [-n {네임스페이스}] -o yaml > {야믈 파일명}
예) kubectl get ing -n ott -o yaml > mying.yaml

2) 야믈 파일 수정
공통으로 제거할 항목은 metadata 하위의 ❶ kubectl.kubernetes.io/last-applied-configuration, ❷ creationTimestamp, ❸ generation, ❹ resourceVersion, ❺ uid 입니다.
generation은 리소스에 따라 없을 수 있습니다.
kubectl.kubernetes.io/last-applied-configuration도 생성된 후 오브젝트 정의 내용이 변경되지 않았다면 없습니다.
그리고 ❻ status 항목과 그 하위 모든 항목도 삭제 하셔야 합니다.

다른 리소스는 위 공통 삭제 항목만 삭제하면 되는데 서비스와 퍼시스턴트 볼륨은 추가로 삭제할 항목들이 더 있습니다.

서비스 오브젝트는 공통 삭제 항목 외에 ❻ spec.clusterIP와 ❼ spec.clusterIPs항목도 추가로 제거 하셔야 합니다.

퍼시스턴트 볼륨은 공통 삭제 항목 외에 ❻ spec.claimRef항목도 삭제 하셔야 합니다.

삭제할 항목들을 모두 제거 후 metadata.name과 metadata.namespace의 값을 적절히 변경 하십시오.


3) 수정한 야믈 파일을 이용하여 오브젝트 생성
‘apply’명령과 ‘-f’옵션을 이용하여 오브젝트를 생성 합니다.
문법: kubectl apply -f {야믈 파일명}
예) kubectl apply -f mying.yaml


4) 실습 하기
인그레스 ‘ott’의 야믈 내용을 이용하여 새로운 인그레스를 만들어 보겠습니다.

배천 노드에 ‘~/k8s/temp’디렉토리를 만들고 이동 합니다.
그리고 인그레스 ‘ott’의 야믈 내용을 mying.yaml파일로 만듭니다.

[root@osboxes ott]# mkdir -p ~/k8s/temp && cd ~/k8s/temp [root@osboxes temp]# k get ing ott -n ott -o yaml > mying.yaml

vim 에디터로 mying.yaml파일을 열어 공통 삭제 항목들을 제거 합니다.

[root@osboxes temp]# vim mying.yaml

❶ 오브젝트 이름은 ‘ottnew’로 하고 ❷ host 주소도 변경 합니다. 주소의 IP가 본인 클러스터의 컨트롤 플레인이나 워커 노드의 퍼블릭 IP인지 확인 합니다.

mying.yaml 파일을 이용하여 새로운 인그레스 ‘ottnew’를 생성 합니다.

[root@osboxes temp]# k apply -f mying.yaml ingress.networking.k8s.io/ottnew created [root@osboxes temp]# k get ing -n ott NAME     CLASS    HOSTS                         ADDRESS         PORTS   AGE ott      <none>   ott.169.56.70.201.nip.io      169.56.70.201   80      174m ottnew   <none>   ottnew.169.56.70.201.nip.io   169.56.70.201   80      24s

웹브라우저에서 인그레스 ‘ottnew’의 주소로 잘 동작 하는지 테스트 합니다.
위 예에서는 아래 주소로 접근해서 테스트 하면 됩니다.

http://ottnew.169.56.70.201.nip.io/member/members/user1

잘 되시죠 ?

이제 여러분은 기존 오브젝트만 있다면 야믈 내용을 복사하여 빠르게 원하는 오브젝트를 생성하실 수 있게 되었습니다.

 

쿠버네티스 쉽게 이해하기 시리즈 목차

[쿠버네티스 쉽게 이해하기 1] 쿠버네티스 설치하기
[쿠버네티스 쉽게 이해하기 2] 쿠버네티스 아키텍처
[쿠버네티스 쉽게 이해하기 3] 한장으로 이해하는 쿠버네티스 리소스
[쿠버네티스 쉽게 이해하기 4] 쿠버네티스 개발에서 배포까지 실습
[쿠버네티스 쉽게 이해하기 5] 쿠버네티스 오브젝트 정의 파일 쉽게 만들기
[쿠버네티스 쉽게 이해하기 6] 꼭 알아야 할 쿠버네티스 주요 명령어
[쿠버네티스 쉽게 이해하기 7] 파드 실행 및 통제를 위한 워크로드 컨트롤러
[쿠버네티스 쉽게 이해하기 8] 파드 로드 밸런서 서비스
[쿠버네티스 쉽게 이해하기 9] 서비스 로드 밸런서 인그레스
[쿠버네티스 쉽게 이해하기 10] 환경변수 컨피그맵과 시크릿
[쿠버네티스 쉽게 이해하기 11] 데이터 저장소 사용을 위한 PV/PVC
[쿠버네티스 쉽게 이해하기 12] 헬스 체크를 위한 스타트업 프로브, 라이브니스 프로브, 레디니스 프로브
[쿠버네티스 쉽게 이해하기 13] 통합 로깅을 위한 EFK 스택
[쿠버네티스 쉽게 이해하기 14] 인증Authentication과 알백RBAC 방식의 인가Authorization
[쿠버네티스 쉽게 이해하기 15] 더 알면 좋을 주제들: 무중단 배포, 모니터링, HPA