본문 바로가기
개발공부 개발새발/Kubernetes

Kubernetes ) 선언적 접근 방식으로 쿠버네티스 사용해보기

by 휴일이 2024. 4. 22.

명령적 접근 방식의 단점

  1. 명령을 외워야 한다.
  2. 반복 명령을 해야 한다. docker run 명령을 일일히 입력해야하는 것처럼..
    1. deployment 구성 파일이 있으면 좋겠다!!!?
  • 쿠버에도 리소스 정의 파일이 있으며, 이용 가능함!

선언적 접근 방식

일반적으로 사용되는 방식

  • apply 명령을 실행하여 클러스터에 적용하려는 구성이 포함된 yml 파일을 가리킨다.
  • 야물 파일을 이용해서 원하는 상태를 정의한다.
  • 구성파일이 변경되어도 쿠버네티스가 변경 사항을 살펴보고 적절한 변경을 수행한다.
  • docker-compose 와 비슷하다!

장점

  • 매번 명령을 다시 입력할 필요가 없고 오류가 덜 발생.
    • 유지 관리가 더 쉽다.
  • 변경해도 반복 필요 없음.
  • 하나만 변경할 수 있고 공유도 매우 쉽다.
  • 동료가 작성한 파일을 보며 구성 방법 빠르게 확인 가능
    • 다음에 어떻게 실행하는지 안 물어봐도 됨 ㅋㅋ굿

선언적 접근 방식 사용

일단 yaml 파일을 생성한다. 이름은 자기 맘이다. 나는 deployment.yml 이라고 정의하겠다.

최소한의 구성

deployment.yml

# 쿠버네티스 구성 파일에서 사용해야하는 구문이다.
# apiVersion 키를 차장보려면 document 나 kubernetes deployment yaml 등을 검색해보자.
apiVersion: apps/v1
# 생성하려는 쿠버네티스 객체 종류 정의 , 여기서는 deployment
kind: Deployment
# 생성하는 객체의 이름 등의 정보
metadata:
  # 객체 이름
  name: second-app-deployment
# 사양
spec:
  # 디폴트 값으로 가지고 있는 pod 의 수 (설정 안 하면 1)
  replicas: 1
  # pod 정의
  template:
    # 위에서 이미 deployment 에 대해 정의했기 때문에, deployment의 template 은 무조건 pod 임. 그래서 따로 추가 X
    # kind: Pod
    # 쿠버의 세 객체니까 metadata 필요
    metadata:
      # 레이블
      labels: 
        # 내가 원하는 키밸류 추가 가능
        app: second-app
    # pod 구성 방법 정의 (pod 사양)
    spec:
      # 파드 구성 컨테이너
      # 여러 컨테이너 정할 수 있으니 컨테이너 추가 가능
      containers: 
        - name: second-node
          image: holidaykang/kube-first-app:3
        # - name: ...
          # image: ...


# delployment.yml 를 기반으로 실행
kubectl apply -f=deployment.yml
  • 하지만 이렇게 실행하면 selector 가 없다는 오류가 뜬다.

yml 수정 → selector 추가

# 쿠버네티스 구성 파일에서 사용해야하는 구문이다.
# apiVersion 키를 차장보려면 document 나 kubernetes deployment yaml 등을 검색해보자.
apiVersion: apps/v1
# 생성하려는 쿠버네티스 객체 종류 정의 , 여기서는 deployment
kind: Deployment
# 생성하는 객체의 이름 등의 정보
metadata:
  # 객체 이름
  name: second-app-deployment
# 사양
spec:
  # 디폴트 값으로 가지고 있는 pod 의 수 (설정 안 하면 1)
  replicas: 1
  # 쿠버네티스가 관리해야하는 pod 중에서 제어할 pod 를 선택한다.
  # 만약 deployment 가 생성된 후 pod 수를 확장한다면 새 pod 는 이미 존재하는 deployment 에 의해 관리되어야 할 것.
  # 그래서 deployment 는 외부에 있는 모든 pod 를 지속적으로 감시하고 제어해야하는 pod 가 있는지 살펴야 한다..
  # 거의 모든 리소스와 작동한다. like Azure
  selector: 
    # Label 일치하는 파드
    matchLabels:
      app: second-app
      tier: backend
    # 표현 일치
    # matchExpressions:

  # pod 정의
  template:
    # 위에서 이미 deployment 에 대해 정의했기 때문에, deployment의 template 은 무조건 pod 임. 그래서 따로 추가 X
    # kind: Pod
    # 쿠버의 세 객체니까 metadata 필요
    metadata:
      # 레이블
      labels: 
        # 내가 원하는 키밸류 추가 가능
        # 여러 레이블 추가 가능
        app: second-app
        tier: backend
    # pod 구성 방법 정의 (pod 사양)
    spec:
      # 파드 구성 컨테이너
      # 여러 컨테이너 정할 수 있으니 컨테이너 추가 가능
      containers: 
        - name: second-node
          image: holidaykang/kube-first-app:3
        # - name: ...
          # image: ...
  • kubectl apply -f=deployment.yaml 하면 deployment 생성됨.
  • 이제 서비스를 만들어보자!

service.yml 추가

service 를 정의하자

# 공식 문서에서는 v1 이 core 그룹인데, core 는 생략 가능함
apiVersion: v1
# 서비스를 만들기 위해
kind: Service
metadata:
  name: backend
spec:
  # 이 리소스에게 제어되거나, 연결되어야 하는 다른 리소스, (이 service 의 일부가 되는 pod 정의)
  # service 는 pod 를 클러스터나 외부에게 노출함.
  # service 로는 deployment 를 제어하는 것이 아니라 pod 제어
  selector: 
    # 레이블 지정
    # 다른 티어를 가져도 app:second-app 레이블이 있다면 제어
    # app: second-app 레이블이 있는 모든 pod 를 노출,
    app: second-app
    # tier: backend
    # 노출 포트 지정 (다중 지정 가능)
  ports:
      # 프로토콜
    - protocol: 'TCP'
      # 외부 포트
      port: 80
      # 컨테이너 내부 포트
      targetPort: 8080
  # 외부 엑세스를 원하면 LoadBalancer
  type: LoadBalancer
# service 생성
kubectl apply -f service.yaml

# minikube 에 노출
minikube service backend(서비스이름)

 

 

minikube 로 노출한 서비스 호에엥~~

 

 

리소스 업데이트

deplyment 및 service 변경은, yml 에서 간단하게 변경하고 파일을 적용하면 클러스터에서 변경한다!

# 쿠버네티스 구성 파일에서 사용해야하는 구문이다.
# apiVersion 키를 차장보려면 document 나 kubernetes deployment yaml 등을 검색해보자.
apiVersion: apps/v1
# 생성하려는 쿠버네티스 객체 종류 정의 , 여기서는 deployment
kind: Deployment
# 생성하는 객체의 이름 등의 정보
metadata:
  # 객체 이름
  name: second-app-deployment
# 사양
spec:
  **# 파드 수를 3으로 변경
	replicas: 3**
  # 쿠버네티스가 관리해야하는 pod 중에서 제어할 pod 를 선택한다.
  # 만약 deployment 가 생성된 후 pod 수를 확장한다면 새 pod 는 이미 존재하는 deployment 에 의해 관리되어야 할 것.
  # 그래서 deployment 는 외부에 있는 모든 pod 를 지속적으로 감시하고 제어해야하는 pod 가 있는지 살펴야 한다..
  # 거의 모든 리소스와 작동한다. like Azure
  selector: 
    # Label 일치하는 파드
    matchLabels:
      app: second-app
      tier: backend
    # 표현 일치
    # matchExpressions:

  # pod 정의
  template:
    # 위에서 이미 deployment 에 대해 정의했기 때문에, deployment의 template 은 무조건 pod 임. 그래서 따로 추가 X
    # kind: Pod
    # 쿠버의 세 객체니까 metadata 필요
    metadata:
      # 레이블
      labels: 
        # 내가 원하는 키밸류 추가 가능
        # 여러 레이블 추가 가능
        app: second-app
        tier: backend
        
    # pod 구성 방법 정의 (pod 사양)
    spec:
      # 파드 구성 컨테이너
      # 여러 컨테이너 정할 수 있으니 컨테이너 추가 가능
      containers: 
        - name: second-node
          image: holidaykang/kube-first-app:3
        # - name: ...
          # image: ...


# 변경된 yml 을 다시 적용한다.
kubectl apply -f=deployment.yaml
  • 이 후 파드를 가져오면 3개의 파드가 정상 실행되는 것을 확인 가능.
  • 이미지 변경 등도 파일만 바꾸면 된당.

리소스 삭제

이름으로 대상을 지정해서 삭제할 수도 있지만, 관련 파일 이름을 호출도 가능하다.

# 이 파일에 의해 생성된 리소스들 삭제
kubectl delete -f=deployment.yaml -f=service.yaml

단일 파일로 합치기

deployment + service 파일을 하나로 합쳐보자.

  • service 를 먼저 배치하는 것이 낫다
# 공식 문서에서는 v1 이 core 그룹인데, core 는 생략 가능함
apiVersion: v1
# 서비스를 만들기 위해
kind: Service
metadata:
  name: backend
spec:
  # 이 리소스에게 제어되거나, 연결되어야 하는 다른 리소스, (이 service 의 일부가 되는 pod 정의)
  # service 는 pod 를 클러스터나 외부에게 노출함.
  # service 로는 deployment 를 제어하는 것이 아니라 pod 제어
  selector: 
    # 레이블 지정
    # 다른 티어를 가져도 app:second-app 레이블이 있다면 제어
    # app: second-app 레이블이 있는 모든 pod 를 노출,
    app: second-app
    # tier: backend
    # 노출 포트 지정 (다중 지정 가능)
  ports:
      # 프로토콜
    - protocol: 'TCP'
      # 외부 포트
      port: 80
      # 컨테이너 내부 포트
      targetPort: 8080
  # 외부 엑세스를 원하면 LoadBalancer
  type: LoadBalancer

      
# 완전히 새로운 객체가 시작됨을 의미하는 구문 (대시 3개)
---
# 쿠버네티스 구성 파일에서 사용해야하는 구문이다.
# apiVersion 키를 차장보려면 document 나 kubernetes deployment yaml 등을 검색해보자.
apiVersion: apps/v1
# 생성하려는 쿠버네티스 객체 종류 정의 , 여기서는 deployment
kind: Deployment
# 생성하는 객체의 이름 등의 정보
metadata:
  # 객체 이름
  name: second-app-deployment
# 사양
spec:
  # 디폴트 값으로 가지고 있는 pod 의 수 (설정 안 하면 1)
  replicas: 3
  # 쿠버네티스가 관리해야하는 pod 중에서 제어할 pod 를 선택한다.
  # 만약 deployment 가 생성된 후 pod 수를 확장한다면 새 pod 는 이미 존재하는 deployment 에 의해 관리되어야 할 것.
  # 그래서 deployment 는 외부에 있는 모든 pod 를 지속적으로 감시하고 제어해야하는 pod 가 있는지 살펴야 한다..
  # 거의 모든 리소스와 작동한다. like Azure
  selector: 
    # Label 일치하는 파드
    matchLabels:
      app: second-app
      tier: backend
    # 표현 일치
    # matchExpressions:

  # pod 정의
  template:
    # 위에서 이미 deployment 에 대해 정의했기 때문에, deployment의 template 은 무조건 pod 임. 그래서 따로 추가 X
    # kind: Pod
    # 쿠버의 세 객체니까 metadata 필요
    metadata:
      # 레이블
      labels: 
        # 내가 원하는 키밸류 추가 가능
        # 여러 레이블 추가 가능
        app: second-app
        tier: backend
    # pod 구성 방법 정의 (pod 사양)
    spec:
      # 파드 구성 컨테이너
      # 여러 컨테이너 정할 수 있으니 컨테이너 추가 가능
      containers: 
        - name: second-node
          image: holidaykang/kube-first-app:3
        # - name: ...
          # image: ...

서비스를 먼저 배치하는 것이 나은 이유

  • 리소스는 위에서 아래로 생성된다.
  • service 의 selector 때문에 이후 생성되는 모든 부분이 동적으로 추가된다.
  • 서비스가 생성될 때 레이블과 일치하는 새로운 부분이 생성되면 서비스에 동적으로 추가되기 때문에 서비스를 먼저 배치하는 것이 오히려 권장된다.
# 합쳐진 파일을 apply 해도 정상 동작한다.
kubectl apply -f=master-deployment.yaml

selector

다른 리소스를 리소스에 연결한다.

# 기본
selector:
	app: second-app
	
# 신식 : 라벨 매칭
selector:
	# 라벨이 매치되는가?
	matchLabels:
		app: second-app
	
# 신식 : 표현 매칭
selector:
	# 표현이 매치되는가?
	matchExpressions:
		app: second-app
			# operator: 조건 설정
			# 여기서는 app 에서 values 범위에 있는 모든 값을 선택한다는 뜻.
			# 자세한 건 documentation ㄱㄱ
			- {key: app, operator: In, values: [second-app, first-app]}


# selector 로 삭제 가능
# deployment, service 를 레이블별로 삭제
kubectl delete deployments,service -l group=example

활성 프로브

컨테이너가 정상 실행하는지 확인하는 것=활성프로브, 자체 정의 가능하다.

    spec:
      # 파드 구성 컨테이너
      # 여러 컨테이너 정할 수 있으니 컨테이너 추가 가능
      containers: 
        - name: second-node
          image: holidaykang/kube-first-app:3
          # 컨테이너 정상 실행인지 확인하는 자체 활성 프로브 정의
          livenessProbe: 
            # get 요청으로
            httpGet: 
              # 이쪽에다 해봐
              path: /
              # 8080 포트써서
              port: 8080
            # n 초마다 확인
            periodSeconds: 3
            # 쿠버가 처음으로 상태를 확인할 때까지 기다려야되는 시간 n 초
            initialDelaySeconds: 5
  • 여러 옵션이 있음.

언제나 최신 이미지 가져오기

containers: 
        - name: second-node
          image: holidaykang/kube-first-app:3
					# 이미지 당겨오는 전략
					# 태그를 지정하지 않아도 항상 최신 이미지 가져오기
					# 아님 이미지에 태그 :lastest 쓰기
					imagePullPolicy: Always
728x90

'개발공부 개발새발 > Kubernetes' 카테고리의 다른 글

Kubernetes ) Environment  (0) 2024.04.24
Kubernetes ) Volume  (0) 2024.04.24
Kubernetes ) 명령적 접근 방식으로 쿠버네티스 사용해보기  (0) 2024.04.22
Kubernetes ) 쿠버네티스가 뭐냐~면  (0) 2024.04.17

관련글

티스토리툴바