지금까지 우리는 쿠버네티스를 구성하면서 터미널에 명령어를 입력하여 사용하는 명령적(Imperative)접근방식을 이용했다. 쿠버네티스는 선언적(Declarative)접근방식도 지원하는데 이번엔 이 방식을 사용해보자.
선언적 접근방식
선언적 접근방식은 터미널에 입력했던 설정들을 파일로 작성하여 실행하는 방식이다. 해당 방식은 IaC(Infrastructure as a Code)로도 잘 알려져있어 널리 쓰이고 있다. 이 방식의 장점은 편리하고 수정이 용이하다는 것이다.
우선 해당 방식을 사용하기 위해 지금까지 사용한 모든 객체를 삭제한다.
kubectl delete deployment/server
kubectl delete service/server
파일 작성
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment
해당링크에 deployment를 정의한 파일 예시가 있다. 이 내용을 참고해도 된다.
# deployment.yaml
# 버전) 공식문서가 가장 최신
apiVersion: apps/v1
# 생성하려는 객체
kind: Deployment
# 추가적인 정보
metadata:
name: server
# deployment 구성
spec:
# scaling
replicas: 2
# deployment가 제어할 pod 정보
selector:
matchLabels:
app: server
# pod 정보
template:
metadata:
labels:
app: server
spec:
containers:
- name: myfastapi
image: riroan/myserver:0.2
ports:
- containerPort: 8000
쿠버네티스 구성파일은 yaml형식으로 작성한다. 파일명은 임의로 정해도 된다. 위에서 작성한 파일은 기본적인 구조이고 해당하는 파일이 하는 역할은 아래 명령어와 같다.
kubectl create deployment server --image=riroan/server0.2
명령적으로 실행했을 때는 replicas를 따로 설정할 수 없었는데 (deployment를 생성 후 scale했어야 함) 선언적으로 하면 생성시에 replicas를 설정할 수 있다는 점이 눈에 띈다.
또 다른 독특한 점은 selector이다.
# deployment.yaml
...
# deployment가 제어할 pod 정보
selector:
matchLabels:
app: server
# pod 정보
template:
metadata:
labels:
app: server
...
메타데이터는 키-값쌍의 레이블을 지정할 수 있다. pod에 레이블을 지정하고 selector로 제어할 pod를 지정하였다. 이렇게 해서 현재 deployment는 app: server라는 레이블을 가진 pod를 제어한다고 알려준다.
이제 위 파일대로 설정된 deployment를 생성해보자.
kubectl apply -f deployment.yaml
정상적으로 2개의 pod를 가진 deployment가 생성되었다. 하지만 아직 접속할 수 없다. service가 없기 때문이다. service에 해당하는 설정파일도 만들어서 실행하자.
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: server
spec:
selector:
app: server
ports:
- protocol: 'TCP'
port: 8000
targetPort: 8000
type: LoadBalancer
이것도 역시 명령적으로 실행했을 때와 비교해보면 쉽게 이해할 수 있다.
kubectl expose deployment server --type=LoadBalancer --port=8000
눈에 띄는 것은 selector인데 selector에 있는 key-value 쌍은 위에서 정의한 pod이다. 해당하는 pod를 위한 서비스객체를 생성한다는 뜻이다.
이제 service.yaml도 적용하고 접속하면 정상적으로 접속되는 것을 확인할 수 있다.
kubectl apply -f service.yaml
minikube service server
다중 config vs 단일 config
현재 deployment와 service를 만들기 위해 2개의 파일을 만들었다. 하지만 이 두 파일을 하나의 파일로 합칠 수 있다. 합칠때는 ---로 구분한다.
# master.yaml
# 버전) 공식문서가 가장 최신
apiVersion: apps/v1
# 생성하려는 객체
kind: Deployment
# 추가적인 정보
metadata:
name: server
# deployment 구성
spec:
# scaling
replicas: 2
# deployment가 제어할 pod 정보
selector:
matchLabels:
app: server
# pod 정보
template:
metadata:
labels:
app: server
spec:
containers:
- name: myfastapi
image: riroan/myserver:0.2
ports:
- containerPort: 8000
---
# 버전) 공식문서가 가장 최신
apiVersion: v1
kind: Service
metadata:
name: server
spec:
selector:
app: server
ports:
- protocol: 'TCP'
port: 8000
targetPort: 8000
type: LoadBalancer
역시 파일명은 임의로 정하면 된다. 기존에 존재하는 객체를 삭제하고 정상적으로 동작하는지 확인하자.
kubectl delete -f deployment.yaml -f service.yaml
kubectl apply -f master.yaml
정상적으로 deployment와 service가 생성된 것을 확인할 수 있다.
'프로그래밍 > 쿠버네티스' 카테고리의 다른 글
[쿠버네티스] 8. EKS 무작정 사용하기 (1) (0) | 2023.07.09 |
---|---|
[쿠버네티스] 6. 쿠버네티스 핵심 기능 (0) | 2023.05.07 |
[쿠버네티스] 5. Deployment 업데이트 (0) | 2023.05.06 |
[쿠버네티스] 4. Service (0) | 2023.05.06 |
[쿠버네티스] 3. 쿠버네티스 구성요소 (0) | 2023.05.06 |