Kubernetes 구성 및 Object (yaml 작성)[2]

728x90

개요

쿠버네티스의 일반적인 구성은 포드(pod)를 그냥 띄우는 경우는 거의 없다. 보통은 Deployment를 생성을 하고 ReplicaSet을 설정하여 pod를 자동으로 생성하는 구조를 갖는다. 만약 외부에서 접근을 필요로 할 때는 Service를 붙여서 사용하면 된다.

아래 yaml은 테스트할 때 사용한 yaml이다. 아래 내용으로 자세히 설명할 것이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devops-spring-deployment
spec:
  selector:
    matchLabels:
      app: springboot
  replicas: 1
  template:
    metadata:
      labels:
        app: springboot
    spec:
      containers:
        - name: springboot01
          image: 192.168.0.103:5000/springboot01
          imagePullPolicy: Always
          ports:
            - containerPort: 8081
              protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: devops-spring-service
spec:
  type: NodePort
  ports:
    - port: 80
      protocol: TCP
      targetPort: 8081
  selector:
    app: springboot

구성 요소

apiVersion

apiVersion은 특정 개체를 만드는 데 사용되는 Kubernetes API의 버전을 지정하는 데 사용되는 키이다. Kubernetes 리소스마다 apiVersions 및 종류가 달라서 Kubernetes 설명서를 참조하여 각 리소스에 사용할 적절한 값을 결정해야 한다. apiVersion의 종류는 "kubectl api-versions" 명령어로 확인할 수 있다.

Kind

Kubernetes Object의 유형을 지정하는 데 사용되는 키입니다. 종류 키의 값은 정의되는 개체의 유형에 따라 달라지며 "Deployment", "Service", "ConfigMap", "pod" 등과 같은 값들이 있다.

Metadata

바로 윗줄(kind, template 등등)에서 정한 Object에 대한 추가 정보를 작성한다. 일반적으로 사용하는 키들에 대해 설명해 보자면

name

정의 중인 Object의 이름을 지정

Labels

Object의 그룹화를 위한 설정으로 위에 예시처럼 "app: springboot"으로 작성하면 app이며 springboot란 이름으로 그룹 짓는 것이다.

annotations

말 그래로 주석으로 Object의 정보나 설명 같은 것을 작성한다. 예시는 이런 식이다.

...
metadata:
  name: my-pod
  annotations:
    build-info: |
      Build Date: 2022-05-06
      Git Commit: abc1234
      Built By: John Doe
 ...
 metadata:
  name: my-service
  annotations:
    last-updated: 2022-05-06T14:30:00Z
 ...
 metadata:
  name: my-deployment
  annotations:
    description: This deployment runs my application in a production environment.

namespace

Cluster 내에서 Object가 속할 namespace를 지정을 구성하고 격리한다. 단일 Kubernetes 클러스터에서 여러 팀 또는 프로젝트와 함께 작업할 때 유용하다. 서로 다른 응용 프로그램 또는 환경에 대한 리소스를 격리하고 관리하는 한다.

spec

Object의 원하는 상태를 정의합니다. 복제본 수, 사용할 컨테이너 이미지, 노출할 포트 등과 같은 개체의 구성 및 동작을 지정한다. spec 섹션의 정확한 내용은 정의되는 Object의 유형에 따라 다릅니다. 주로 사용되는 Deployment와 Service를 설명하자면

Deployment

- replicas : 원하는 복제본 수

- selector : 관리해야 하는 포드를 해당 labels을 보고 결정한다.

...
spec:
  selector:
    matchLabels:
      app: springboot
...

app: springboot로 되어있는 labels를 설정

- template : Deployment에 의해 생성될 포드의 템플릿을 지정합니다. template 필드는 metadata 및 spec의 두 하위 필드를 포함하는 Object이다.

metadata : Deployment로 생성된 포드에 적용될 레이블을 지정
spec : Deployment에 의해 생성된 포드의 원하는 상태를 지정

template:
  metadata:
    labels:
      app: my-app
  spec:
    containers:
    - name: my-container
      image: my-image
      ports:
      - containerPort: 8080

Deployment에 의해 생성된 팟(Pod)에 app: my-app 레이블이 있어야 하며 Pod에 my-image 이미지를 실행하는 my-container라는 단일 컨테이너가 있어야 하고 컨테이너가 포트 8080에서 수신 대기하도록 지정하는 것이다.

- strategy : Deployment를 업데이트할 때 사용할 배포 전략입니다. type (Recreate, RollingUpdate)은 2가지가 있다.

Recreate : 새 Pod를 만들기 전에 기존 Pod를 모두 삭제한다. 이로 인해 이전 포드가 종료되고 새 포드가 생성되므로 일시적인 다운타임이 발생할 수 있다.

RollingUpdate : 이전 포드를 새 포드로 교체한다.

maxSurge: 업데이트 과정에서 원하는 복제본 수 이상으로 생성할 수 있는 최대 포드 수이다. 예를 들어 원하는 replicas 개수가 3개이고 'maxSurge'가 1개로 설정되어 있다면 업데이트 과정에서 최대 4개의 pod를 생성할 수 있다.
maxUnavailable: 업데이트 프로세스 중에 사용할 수 없는 최대 포드 수이다. 예를 들어 원하는 replicas 개수가 3개이고 'maxUnavailable'이 1개로 설정되어 있다면 업데이트 과정에서 최대 1개의 파드를 사용할 수 없다.

...
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
...

- minReadySeconds : 새로 생성된 pod가 사용 가능한 것으로 간주되기 전에 준비되어야 하는 시간(초)을 지정한다. 설정되지 않은 경우 Kubernetes는 준비 확인을 통과하는 즉시 사용 가능한 포드로 간주한다.

- revisionHistoryLimit : 유지해야 하는 이전 버전의 최대 개수를 지정한다. revisionHistoryLimit이 3으로 설정되면 Kubernetes는 최대 3개의 이전 버전 배포를 유지한다. 새 개정이 생성되고 이전 개정이 이미 3개 있는 경우 새 개정을 위한 공간을 만들기 위해 가장 오래된 개정이 삭제된다. 값을 0으로 설정하면 배포에 대한 개정 기록이 비활성화된다.

ex)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image
        ports:
        - containerPort: 8080

Pod의 복제본 3개를 생성하도록 지정(replicas), 이 Deployment로 생성된 pod에 app: my-app 레이블이 있어야 함을 지정(selector), template의 metadata 필드는 Pod에 app: my-app 레이블이 있어야 함을 지정하고 spec 필드는 팟에 my-container라는 이름의 단일 컨테이너가 있어야 함을 지정(template), image가 "my-image"인 포드(image)이며 필드는 컨테이너가 포트 8080에서 수신 대기하도록 지정한다.(containerPort)

Service

- selector : 서비스가 트래픽을 라우팅해야 하는 Pod의 레이블과 일치하는 레이블 선택기를 지정합니다.

- ports : 수신 대기하고 트래픽을 전달해야 하는 포트를 지정한다.

name : YAML 파일의 다른 부분에서 포트를 참조하는 데 사용할 수 있는 포트의 선택적 이름
port : 서비스가 청취해야 하는 포트 번호
targetPort : 서비스가 포드에서 트래픽을 전달해야 하는 포트 번호로 이것은 숫자 포트 번호이거나 Pod의 containerPort 필드에 정의된 명명된 포트
protocol: 포트에 사용할 프로토콜이며 TCP 또는 UDP일 수 있습니다. 이 필드를 지정하지 않으면 'TCP'로 간주다.

ex)

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - name: http
    port: 80
    targetPort: 8080
  - name: metrics
    port: 9090
    targetPort: metrics

해당 yaml은 포드의 포트 8080을 80 포트로 라우팅, 포드의 'metrics'라는 명명된 포트는 포트 9090 라우팅 된다는 것이다.
(tartgetPort: pod의 포트, port : 서비스의 포트) Kind가 Service일 때 ports 필드는 필수이며 지정하지 않으면 서비스가 올바르게 작동하지 않습니다. 또한 여러 컨테이너가 포함된 포드를 실행하는 경우 트래픽을 원하는 컨테이너로 올바르게 라우팅 하려면 각 컨테이너에 대해 서로 다른 'targetPort' 값을 지정해야 할 수 있다.