[k8s/쿠버네티스] - Deployment로 애플리케이션 배포

안녕하세요~

오늘은 쿠버네티스 환경에서 Application을 배포하는 과정에 대한

설명으로 간단하게 Deployment 를 소개해드릴까 합니다 ㅎㅎ

 

제가 최근에 도커 이미지를 만들어보는 Dockerfile만들기라는 포스팅을 게제했는데요

 

이번 게시글에서는

위 게시글을 좀 더 확장하여 만든 이미지 파일을 배포해보는 실습을 할까합니다~!

 

Deployment란?

먼저 Pod에 대한 개념적인 설명은 위 게시글을 참조해주세요~

Deployment

Deployment는 Pod와 Replicaset에 대한 선언과 업데이트를 관리해주는 모듈입니다~!

 

앗 그렇다면 Pod와 Replicaset은 뭐지?

 

Pod는 여러 개의 Container를 운영하는 가장 기초적인 모듈이고,

Replicaset은 동일 Pod에 대한 가용성을 안정적으로 보장받기 위한 모듈입니다~!

 

아하,

그러니까 Deployment는 Pod와 Replicaset을 효율적으로 관리하기 위한 모듈이구나~

혹은 2개의 모듈을 한번에 관리하기 위한 모듈이구나 라고 생각하시면 좋을 것 같아요 ㅎㅎ

만들어보기

쿠버네티스는 kubectl 이라는 kubernetes control 이라는 명령을 통해 실행할 수 있고,

제일 큰 장점은 yaml/yml 파일로 모든 것을 해결할 수 있다는 것이에요 ㅎㅎ

 

바로 yml 파일부터 만들러 가봅시다~!

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.python.server: deployment
  name: pyhon-server # deployment의 이름
spec:
  replicas: 4 # 개체수
  selector:
    matchLabels:
      app.python.server: node # pod의 label을 선택해서 가져오기
  template:
    metadata:
      labels:
        app.python.server: node # pod의 label을 지정
    spec:
      containers:
        - image: server_flask:0.0.7
          name: python-server
          ports:
            - containerPort: 8080
          volumeMounts:
            - mountPath: /temp
              name: volume-host
      volumes: # 참고할 volume 지정
        - name: volume-host # volume 의 이름 지정
          hostPath:
            path: /Users/huisam/volume # volume으로 할 path
            type: DirectoryOrCreate # type 지정

예시에도 잘 나와있지만, 위 예시에서는

replicaset을 4개로 지정한 모습이에요~!

 

Pod에 대한 spec은 spec.template.spec.containers 로 지정한 모습을 볼 수 있고,

저는 app.python.server=node 라는 label를 지정했어요 ㅎㅎ

 

쿠버네티스는 아시다시피 이러한 label을 지정하는 것이 너무나 중요합니다~!

실제 MSA 환경에서는 수많은 도커 이미지(App)들이 존재할 것이고, 배포 및 관리하는 단위가 많을 것이기 때문이죠~!

 

그럼 이제 실제로 배포하기전에 Service도 간단하게 만들어 볼게요~!

 

Servcie는 뭐지?

 

쉽게 생각하면 Pod의 Load Balancer라고 생각하면 쉽습니다 ㅎㅎ

동일한 속성을 가진 Pod는 여러개 존재할 것이고, 이에 대한 트래픽 분산이 필요한데

이를 도와주는 것이 바로 Service에요~!

apiVersion: v1
kind: Service
metadata:
  name: python-service
  labels:
    app.python.server: service # service의 레이블
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 2222 # service의 port
    targetPort: 8080 # pod의 target port
  selector:
    app.python.server: node # 연결 시킬 pod의 label

그럼 이제 준비가 되었으니 한번 Command 명령어를 통해 해보도록 하겠습니다~!

 

Command Line

저는 작업의 편의성을 위해 위에서 설명한 2개의 yml 파일을 하나로 합쳤습니다!

먼저~

생성 명령어

상당히 길죠?

위에서는 kubectl이라는 명령어 prefix를 붙이고, create -f 명령을 통해 한번에 service와 deployment를 실행시켰습니다~!

그러면 위 명령에 대한 결과로 service, pod, replicaset이 정상적으로 생성되겠죠~?

이제는 앞으로는 kubectl을 kc라고 하겠습니다

 

저는 귀찮아서 alias을 붙였거든요 ㅎㅎ

 

생성된 결과

한번에 4개의 Pod가 생성되었고, 정상적으로 label이 설정된 것을 볼 수 있습니다 ㅎㅎ

Pod의 저 pod-template-hash는 우리가 직접적으로 deployment에 pod를 명시했기 때문에 나오는 결과에요~!

 

또한 localhost의 2222번 port를 service의 32449번 port로 매핑 시켜주었고, 

매핑된 service는 알아서 Pod의 Endpoint로 설정되게 해줄 것입니다 ㅎㅎ

요렇게 말이죠~!

각각의 Pod의 IP에서 8080번 Port로 연결된 것을 볼 수 있습니다 ㅎㅎ

 

그럼 한번 요청을 쏘아볼까요~?

2222번 포트에 요청 날려보기

정상적으로 응답이 오는 것을 볼 수 있네요 ㅎㅎ

근데 replicaset을 줄여보고 싶은데 ㅠㅠ 어떻게 할까요

바로 scale명령을 통해서 할 수 있습니다~! ㅎㅎ

scale down 하기

deployment의 replica를 2개로 설정하겠다~! 라는 명령입니다 ㅎㅎ

그럼 history관리는 어떻게 되고 있는지 한번 보러 가볼까요?

 

먼저, 이러한 명령을 쳐주세요~!

k8s describe

describe이라는 명령을 치시면 해당 모듈에 대한 자세한 항목들을 볼 수 있는데요,

여기서는 놀랍게도 deployment가 Rolling Update라는 정책을 사용하고 있음을 볼 수 있습니다 ㅎㅎ

deployment의 기본 정책은 Rolling Update이고, yml에 명시를 한다면 다른 정책을 사용할 수 있어요~!

 

History를 스크롤을 아래로 조금만 내려보시면~!

Events

Events라는 항목의 Tab에서 확인할 수 있는데 어느 시점에 Scale up / down 되었는지 확인할 수 있네요 ㅎㅎ

 

그러면 이제 위에서 설정하지 못한 Template에 대한 설명을 해볼게요~!

 

Yaml Template

기본적으로 k8s에서 yml로 명시하지 않으면 대게 default값이 많습니다

우리 개발자들은 항상 default 값을 알고 사용하는 것이 중요합니다~! 꼭 꼭

• .spec.template.spec.restartPolicy : Pod를 재시작 하는 정책으로, 기본은 항상 Always
• .spec.replicas : 필요한 Pod의 수를 선택하는 선택적 필드며, 기본은 항상 1
• .spec.selector : Pod를 선택하는 label의 selector로서, apps/v1 으로 배포할 경우, spec.template.metadata.labels 하고 항상 일치해야 한다
• .spec.strategy : Pod를 대체하는(재배포) 전략으로, 기본은 RollingUpdate, 선택지로는 Recreate 가 존재
  • 자세한 내용은 참고
  • RollingUpdate 시에 선택해야 되는 선택지들이 몇 개 있다
    • .spec.strategy.rollingUpdate.maxUnavailable : 업데이트 진행되는 도중에 사용할 수 없는 최대 파드의 수를 지정하는 것
      • 기본값은 25 으로, 25%를 의미하며, 75%의 Pod은 항상 가용하도록 설정하는 것이다
    • .spec.strategy.rollingUpdate.maxSurge : 업데이트 진행되는 도중에 최대로 생성할 수 있는 파드의 수를 의마한다
      • 기본값은 25 으로, 25%를 의미하며, 기존 및 새 Pod의 수를 의도한 갯수의 125% 를 넘지 않도록 한다
• spec.progressDeadlineSeconds : deployment를 진행되다가 실패했을 때, 실패 상황을 보고해야 하는데, 실패했으니 대기시간에 대한 설정이 필요하다. 그래서 설정해주는 것. 기본은 항상 600 이며 600초를 의미한다.
• spec.volumes : Pod에 제공할 볼륨을 설정하고,
• spec.containers[*].volumeMounts : 컨테이너에 마운트 할 위치를 지정
  • name : volume의 이름 지정
  • type : volume에 해당하는 type을 지정해야 하는데, 자세한 것은 링크 참고
  • path : volume에 해당하는 path 지정

가장 중요한 설정

( CPU Memory 추후 포스팅 예정 )

마치며

저희는 지금까지 Deployment에 대한 간략한 실습을 해보았는데요,

 

요번 포스팅에서 진행한 실습은 아주아주 기초적인 실습으로

실제 운영환경에서는 각각의 Container에 대한 CPU, Memory 설정과

Service에 대한 Load Balancing 설정(대게 클라우드 벤더 회사를 따라가나 실제 필요한 경우도 있음)

그리고, App Update될 때마다 yml 파일에 대한 관리 전략 등은 많이 빠져있습니다

 

나중에 기회가 되면 위 항목들에 대한 포스팅을 추가해서 다시 작성할 것이구요 ㅎㅎ

부족한 점이나 필요한 기술 항목들이 느껴진다면 댓글 부탁드립니다~!

참고

쿠버네티스 디플로이먼트