kubernetes - 명령적 접근 방식과 선언적 접근 방식

명령적 접근 방식과 선언적 접근 방식

• 사용자가 쿠버네티스와 상호 작용할 수 있는 두 가지 기본 적인 접근 방식이다.

 

명령적 접근 방식

• 사용자가 쿠버네티스에게 개별 명령어를 통해 명령을 직접 내린다.
• 개별적으로 명령을 내리기 때문에 실수가 있을 확률이 높다.
• 빠른 일회성 작업, 임시 작업, 테스트 작업에 유용하지만 복잡한 시나리오의 구축을 위해서는 반복성과 확장성이 부족하여 사용하기 힘들다.

 

선언적 접근 방식

• yaml 파일을 활용해 쿠버네티스의 클러스터 상태를 정의하여 명령을 내리는 방식이다.
• 반복성과 확장성을 통한 구성 관리의 용이함으로 쿠버네티스에서 컨테이너화된 애플리케이션을 관리할 때 일관성을 보장하고 효과적으로 협업할 수 있게 한다.

 

 

nginx 웹 서버 deployment 객체 만들기

 

명령적 접근 방식

kubectl create deployment nginx-deployment --image=nginx:latest --replicas=3

터미널에 명령을 입력하는 방식으로 명령을 내린다.

 

 

선언적 접근 방식

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest

 

# yaml 파일을 선언하기 위한 명령어
kubectl apply -f nginx-deployment.yaml

• yaml 파일을 실행하는 명령어이다.

 

kubectl delete -f deployment.yaml -f=service.yaml

• 위와 같이 삭제하려는 파일 이름을 가리켜 호출하여 삭제할 수도 있다.
• 파일을 삭제하는 것이 아니라 파일에 의해 생성된 리소스를 삭제하는 것이다.

 

deployment 객체 yaml 파일 추가 예시

apiVersion: apps/v1 # 현재 최신 apiVersion은 kubernetes 웹 페이지나 구글링을 통해 찾아보자.
kind: Deployment # 생성하려는 항목
metadata: # 생성하는 객체의 이름과 같은 중요 데이터가 들어간다.
  name: second-app-deployment
spec: # yaml 파일의 핵심이며, deployment를 구성하는 방법을 정의 
  replicas: 1 # 디폴트 값으로 가지고자 하는 pod 인스턴스의 수 (기본은 1개) 
  selector:
    matchLabels: # deployment 객체가 제어할 pod 레이블의 키-값 쌍을 추가
      app: second-app
      tier: backend
      # deployment에 속한 pod를 deployment에게 알려주는 역할이다.
  template: # 생성하고자 하는 pod를 정의한다. 따라서 kind는 적을 필요없다. pod를 정의하는 것이기 때문.
    metadata: # 위의 metadata는 deployment 객체에 대한 것이고, 이 metadata는 pod 객체에 대한 것이다.
      labels: # 키: value의 형태로 key든 value든 원하는대로 지정 가능
        app: second-app
        tier: backend
    spec: # pod를 구성하는 방법을 정의
      containers:
        - name: second-node
          image: wonyongg/kub-first-app:2
        # - name: ...
          # image: ...

 

 

service 객체 yaml 파일 예시

apiVersion: v1
kind: Service
metadata:
    name: backend
spec:
  selector: # service 객체에 제어되거나, 연결되어야 하는 다른 리소스
  # service 객체는 matchLabel 없이 키-값 쌍으로 직접 레이블을 지정한다.
    app: second-app
  ports:
    - protocol: 'TCP' # 디폴트값
      port: 80 # 노출시키려는 외부 포트
      targetPort: 8080 # 컨테이너 내부에서 수신중인 포트
    # - protocol: 'TCP'
    #   port: 443
    #   targetPort: 443
  type: LoadBalancer # 가장 일반적으로 사용되며 외부와 엑세스
  # ClusterIP : 디폴트 값이며, 내부적으로 노출된 IP
  # NordPort : 기본적으로 실행되는 워커 노드의 IP와 포트에 노출
# 명령어 minikube service backend

 

 

다중 config yaml 파일 예시

# master-deployment.yaml
apiVersion: v1
kind: Service
metadata:
    name: backend
spec:
  selector: # service 객체에 제어되거나, 연결되어야 하는 다른 리소스
  # service 객체는 matchLabel 없이 키-값 쌍으로 직접 레이블을 지정한다.
    app: second-app
  ports:
    - protocol: 'TCP' # 디폴트값
      port: 80 # 노출시키려는 외부 포트
      targetPort: 8080 # 컨테이너 내부에서 수신중인 포트
    # - protocol: 'TCP'
    #   port: 443
    #   targetPort: 443
  type: LoadBalancer # 가장 일반적으로 사용되며 외부와 엑세스
  # ClusterIP : 디폴트 값이며, 내부적으로 노출된 IP
  # NordPort : 기본적으로 실행되는 워커 노드의 IP와 포트에 노출
# 명령어 minikube service backend

--- 

apiVersion: apps/v1 # 현재 최신 apiVersion은 kubernetes 웹 페이지나 구글링을 통해 찾아보자.
kind: Deployment # 생성하려는 항목
metadata: # 생성하는 객체의 이름과 같은 중요 데이터가 들어간다.
  name: second-app-deployment
spec: # yaml 파일의 핵심이며, deployment를 구성하는 방법을 정의 
  replicas: 1 # 디폴트 값으로 가지고자 하는 pod 인스턴스의 수 (기본은 1개) 
  selector:
    matchLabels: # deployment 객체가 제어할 pod 레이블의 키-값 쌍을 추가
      app: second-app
      tier: backend
      # deployment에 속한 pod를 deployment에게 알려주는 역할이다.
  template: # 생성하고자 하는 pod를 정의한다. 따라서 kind는 적을 필요없다. pod를 정의하는 것이기 때문.
    metadata: # 위의 metadata는 deployment 객체에 대한 것이고, 이 metadata는 pod 객체에 대한 것이다.
      labels: # 키: value의 형태로 key든 value든 원하는대로 지정 가능
        app: second-app
        tier: backend
    spec: # pod를 구성하는 방법을 정의
      containers:
        - name: second-node
          image: wonyongg/kub-first-app:2
        # - name: ...
          # image: ...

• 여러 yaml 파일을 하나의 파일로 만들 수 있다.
• 방법은 간단하다. '---'로 config를 구분하여 나누면 된다.
  • 3개의 대시여야 한다. 완전히 새로운 객체가 시작됨을 의미하는 yaml의 구문이기 때문이다.
• service와 deployment를 동일한 파일 중 하나에 결합하는 경우 service를 먼저 배치하는 것이 좋다.
• 리소스는 위에서 아래로 생성되기 때문에 service 리소스가 먼저 생성되면 selector가 모든 부분을 동적으로 추가한다.

 

다중 config yaml 파일 적용 예시 

 

 

 

 

참고

Udemy - Docker & Kubernetes : 실전 가이드