개발공부 개발새발/Kubernetes

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

휴일이 2024. 4. 22. 15:58

명령적 접근 방식의 단점

  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