쿠버네티스 (Kubernetes)

 

1. 컨테이너 오케스트레이션

1) 개요

• 다수의 컨테이너를 유기적으로 연결 및 실행할 뿐 아니라 상태를 추적하고 보존하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어주는 것

 

2) 솔루션

• Docker Swarm
  • 간단하고 설치도 용이한데 기능이 다양하지 않아 소규모 환경에서는 유용하지만 대규모 환경에서는 거의 사용하지 않음
• Mesos
  • 아파치의 오픈 소스 프로젝트로 트위터, 에어비엔비, 애플, 우버 등에서 사용한 검증된 솔루션으로 대규모 서버 환경에서 자원을 유연하게 공유하고 하나의 자원처럼 관리하는 DC/OS의 지원으로 매우 간결하지만 기능적으로 충분하긴 하지만 여러 가지 솔루션을 유기적으로 구성해야 하는 부담 발생
• nomad
  • 베이그런트를 제작한 해시코프에서 만든 솔루션으로 특징은 Docker Swarm과 거의 유사함
• Kubernetes
  • 다른 솔루션 보다는 진입 장벽이 높음
  • 거의 모든 벤더와 오픈 소스 진영에서 쿠버네티스를 지원하고 그에 맞게 통합 및 개발하고 있음

 

 

2. 쿠버네티스 (Kubernetes)

1) 개요

• 컨테이너 기반의 애플리케이션을 개발하고 배포할 수 있도록 설계된 오픈 소스 플랫폼으로 컨테이너 오케스트레이션 도구의 일종
• k8s 라고도 함 (Kubernetes) k 와 s 사이에 알파벳 8개가 있어서 임 아주 작명 센스가 유치뽕짝임
• Kubernetes를 일반적 프로그래머가 관리하는 일은 거의 없음
  • 대규모 시스템을 개발하는 프로그래머가 대규모 서버군을 직접 관리하는 일은 드물다.
  • 클라우드 환경을 개발(퍼블릭이나 프라이빗 클라우드 구축)하거나 클라우드 환경의 애플리케이션을 관리하는 경우 kubernetes는 필수 항목 중 하나임
  • kubernetes는 여러 대의 물리적 서버에 걸쳐 실행되는 것을 전제로 함
    • 네트워크 지식을 어느 정도 필요로 함
  • 어떤 일을 할 수 있는 가에 대한 지식은 시스템을 개발할 때 유용하기 때문에 공부!!
    • 대규모 배치 처리를 하는 경우
      • 운영체제 차원에서 가능
      • python 의 airflow에서 가능
      • kubernetes의 cron 기능으로 가능

 

2) 리소스

• node
  • 컨테이너가 배치되는 서버
• namespace
  • 쿠버네티스 클러스터 안의 가상 클러스터
• pod
  • 컨테이너 집합 중 가장 작은 단위 - Micron Service 단위
• replicaset
  • 같은 스펙을 갖는 파드의 집합
• deployment
  • 레플리카 세트의 리비전을 관리
• service
  • 파드에 접근하기 위한 경로
• ingress
  • 서비스를 쿠버네티스 클러스터 외부에 노출
• configmap
  • 설정 정보를 정의해 파드에 전달
• persistent volume
  • 파드가 사용할 스토리지
• persistent volume claim
  • 퍼시스턴트 볼륨을 동적으로 확보
• storge class
  • 스토리지 종료
• stateful set
  • 같은 스펙으로 동일한 파드를 여러 개 생성 및 관리하는 것
• job
  • 상주 실행 (계속 구동중인 서비스)을 목적으로 하지 않는 파드를 여러개 생성하고 정상적인 종료를 보장
• cron job
  • 스케줄링

 

3) 노드 (node)

• 쿠버네티스 리소스 중 가장 큰 개념
• 쿠버네티스의 관리 대상으로 등록된 컨테이너가 배치되는 대상
• 쿠버네티스 클러스터 전체를 관리하는 마스터 노드가 1개 이상 배치되고 그 안에 여러 워커 노드가 배치되어 하나의 클러스터를 구성함
• 워커 노드
  • 컨테이너 런타임이 설치된 환경에서 컨테이너 또는 도커를 실행하고 유지 및 관리하는 노드
    • 리눅스 -> 도커 엔진 -> 각종 컨테이너들이 배치(파드)

 

4) 파드 (pod) 와 컨테이너

• 파드는 쿠버네티스에서 생성할 수 있는 가장 작은 배포 단위
• 파드 외에 서비스, 볼륨, 네임스페이스를 묶어 오브젝트라고 하고 파드는 하나 이상의 컨테이너로 구성됨
• 쿠버네티스는 파드 단위로 배포 (도커는 컨테이너 단위로 배포)

 

5) 특징

• 무중단 서비스
  • 서비스 중단 없이 애플리케이션을 업그레이드 할 수 있음
• 클라우드 벤더 종속성 해결 (Lock-In - 특정 벤더에 종속)
  • 현재 서비스 중인 모든 public cloud vender 가 Docker와 Kubernetes를 위한 서비스를 제공
• 효율적인 자원 관리
  • 컨테이너나 파드를 사용하면 OS 자원 소모를 줄인 상태에서 서비스들의 독립성을 보장할 수 있음
• 유연한 확장성
  • 파드의 개수를 늘리거나 줄이기가 쉬움
• 항상 바람직한 상태를 유지함
  • 쿠버네티스는 파드를 항상 바람직한 상태가 되도록 자동으로 관리
  • 도커 컴포즈는 복제를 할 때 복제할 개수를 정하는 것 외에 아무 기능을 수행하지 않지만 쿠버네티스는 모니터링 기능을 탑재하고 있음
    • 하나의 파드가 중지되면 자동으로 새로운 파드를 생성하여 파드의 수를 유지하게 함

 

6) 기본 구조 - 클라우드 환경을 구축하는 경우 중요함

• 클러스터
  • 마스터 노드
    • 쿠버네티스 클러스터 전체를 관리하는 시스템으로 Control plane라고도 함
    • 마스터 노드가 되는 컴퓨터에는 kuberctl(명령어 해석기)을 설치
  • 워커 노드
    • 마스터 노드의 명령을 받아 파드를 생성하고 서비스하는 머신
  • 컨테이너 런타임
    • 파드를 실행하는 엔진으로 도커가 가장 많이 사용 됨
  • 영구 스토리지
    • 데이터를 반 영구적으로 저장하기 위한 저장소 개념

 

• 컴포넌트 - 마스터 노드에 존재
  • API Server
    • 클러스터로 요청이 들어왔을 때 그 요청이 유효한지 검증하는 컴포넌트
    • 사용자의 권한 확인 및 명령어 검증 등을 하는 부분
    • 명령이 유효하면 워커 노드에게 파드의 생성을 지시 (파드 생성 전)
  • etcd
    • 상태 정보를 저장하고 있는 컴포넌트
    • API 서버는 파드를 생성한다는 사실을 etcd에 알리는데 이 때 클러스터의 상태를 저장함
    • key-value 형태로 저장하고 사용자에게 파드 생성됨을 알리지만 아직 파드 생성 전인 상태
  • scheduler
    • 파드를 어떠한 노드에 할당할지 결정하는데 이 때 cpu나 메모리의 사용량을 잠조하여 결정
    • 파드를 어떤 워커 노드에 위치시킬지 확인하고 그 사실을 API 서버에 알리면 API 서버가 etcd에 알려 저장
  • kybelet (유일하게 워커노드에 존재하는 컴포넌트)
    • 워커 노드에 존재하며 API 서버로부터 파드의 생성 정보를 전달받아 파드를 생상하고 운영을 수행하는 컴포넌트
    • 파드를 생성하면 해당 정보를 API 서버에 전달 API 서버는 그 정보를 etcd에 저장
  • Controller Manager
    • 다양한 컴포넌트의 상태를 지속적으로 모니터링하고 실행상태를 유지하도록 해주는 컴포넌트
    • Public Cloud에서 이 부분을 별도의 서비스로 만들어서 제공함
    • 가장 유명한 서비스가 AWS의 EKS
  • Proxy
    • 클러스터의 모든 노드에서 동작하는 네트워크의 프록시
    • 네트워크 규칙을 관리하고 클러스터 내부와 외부의 통신을 담당
  • 컨테이너 런타임
    • 도커로 주로 사용되었는데 최근의 버전에서는 더 이상 도커를 지원하지 않고 containerd를 지원

 

7) 외부 서비스

• Public Cloud 서비스 제공업체들은 PaaS 형식의 서비스로 제공
• Private Cloud 를 사용하면 직접 설치해야 하지만 Public Cloud를 사용하는 경우는 제공되는 서비스를 이용 가능

 

• AWS 의 EKS
• MS 의 AKS
• Google 의 GKE
• Kakao Cloud 의 DKOS
• Suse 의 Rancher
• Redhat 의 Openshift

 

8) 경량 버전의 쿠버네티스

• k3s
  • Ranceher 에서 개발한 쿠버네티스의 경량 버전
• minikube
  • 단일 노드의 쿠버네티스 클러스터 환경을 제공
  • 명령행 도구 설치 : https://kubernetes.io/ko/docs/tasks/tools

 

사진 삭제

명령행 도구 설치

 

사진 삭제

 

사진 삭제

쿠버네티스는 도커에서 바로 설치할 수 있음

 

 

3. Pod

1) 개요

• Pod는 Kubernetes 의 기본 배포 단위
• 하나의 pod에 여러 개의 컨테이너를 포함시킬 수 있는데 이러한 패턴을 Sidecar 패턴이라고 함
• 기본 기능을 하는 컨테이너와 부가 기능을 하는 컨테이너가 결합하는 방식
• 하나 이상의 컨테이너로 애플리케이션을 구현하다 보면 서로 강한 결합을 갖는 방식이 나은 경우가 종종 있어 이런 경우 하나의 파드로 묶어 일괄 배포 한다.

MySQL <-> Go <-> Nginx

이렇게 3개의 컨테이너가 필요한 경우 이 컨테이너 간의 관계를 조사
MySQL은 Go에서 사용을 하고 다른 컨테이너에서도 사용
Go 프로그램은 Nginx 에서만 사용하는 경우

위 경우 배포 방식은 3가지 정도 있음
- 모든 컨테이너를 별개로 배포하고 각 컨테이너의 포트를 전부 오픈
- 3개의 컨테이너를 하나의 파드로 묶어 배포하고 MySQL 만 외부에 연결하여 사용
- MySQL만 별도의 컨테이너로 배포하고 Go와 Nginx는 하나의 파드로 묶어서 배포

되도록이면 같이 사용되는 것 끼리 묶는 것이 좋지만 목적이 공용인 것이 있다면 별도의 컴포넌트
또는 피드로 배포하는 것이 좋다.

 

 

2) 생성 방법

• 명령어를 직접 입력해서 생성
• yaml 파일을 만들어서 생성 - 권장
  • 최근에는 인프라를 만드는 것을 수동으로 하지 않고 코드로 수행하는 것 (IaC)을 권장

 

3) 명령어를 이용해 pod를 생성

• 생성 명령
  • kubectl create
    • 생성
  • kubectl apply
    • create 와 replace의 혼합으로 생성과 변경

 

• 아파치 웹서버(httpd)를 하나만 복제하여 80번 포트를 개방하는 형태로 pod를 생성
  • kubectl create deployment my-httpd --image=httpd --replicas=1 --port=80

 

사진 삭제

사진 설명을 입력하세요.

• • deployment
    • 스테이트리스 형태의 pod 생성
  • my-https
    • 디플로이먼트 이름
  • --image=httpd
    • pod를 생성할 때 사용하는 이미지
  • --replicas=1
    • 실행 상태로 유지 될 pod의 개수
  • --port=80
    • pod에 접근할 때 사용할 포트 번호

 

• Stateless 와 Stateful
  • Stateless
    • 사용자가 애플리케이션을 사용할 때 상태나 세션을 저장해 둘 필요가 없는 애플리케이션을 생성할 때 사용하는 옵션
  • Stateful
    • 사용자가 애플리케이션을 사용할 때 상태나 세션을 별도로 데이터베이스에 저장해야 하는 애플리케이션에 사용 (웹 에플리케이션이 여기에 해당)

 

• Deployment가 제대로 되었는지 확인
  • kubectl get deployment

 

사진 삭제

사진 설명을 입력하세요.

• • NAME : 이름
  • READY : 레플리카의 개수
  • UP-TO-DATE : 최신 상태로 업데이트 된 레플리카의 개수
  • AVAILABLE : 사용 가능한 레플리카의 개수
  • AGE : 실행되고 있는 시간

 

• 자세한 정보 출력
  • kubectl get deployment -o wide
    • 이미지 이름이나 컨테이너 이름도 출력

 

사진 삭제

사진 설명을 입력하세요.

 

• 파드 정보 확인
  • deployment 대신 pod
  • kubectl get pod
  • kubectl get pod -o wide

 

사진 삭제

사진 설명을 입력하세요.

 

• deployment 삭제
  • kubectl delete deployment my-httpd

 

사진 삭제

사진 설명을 입력하세요.

 

 

4) pod에 접속

• 파드 생성
  • kubectl create deployment my-httpd --image=httpd --replicas=1 --port=80

 

• 파드 이름 확인
  • kubectl get pod

 

사진 삭제

사진 설명을 입력하세요.

• 파드 내부에 접속
  • kubectl exec -it 접속할 파드의 이름 --/bin/bash
  • kubectl exec -it my-httpd-7547bdb59f-vq2gg -- /bin/bash
  • 나갈때는 exit 입력

 

사진 삭제

사진 설명을 입력하세요.

• pod 로그 관리
  • 모니터링 할 때 이용 - 대부분의 클라우드 사업자는 이 로그를 GUI 환경에서 볼 수 있는 기능을 제공
  • kubectl logs 파드의 이름
  • kubectl logs my-httpd-7547bdb59f-vq2gg

 

 

4. Deployment

1) 개요

• kubernetes 에서 상태가 없는 애플리케이션 배포에 사용
• 레플리카 셋의 상위 개념
  • 파드 -> 레플리카 셋 -> 디플로이먼트

 

2) 업데이트 시 배포 전략

• Rolling Update
  • kubernetes 의 기본 배포 전략
  • 새 버전의 애플리케이션을 배포할 때 새 버전의 애플리케이션은 하나씩 늘려가고 기존 버전의 애플리케이션은 하나씩 줄여가는 방식

v1 을 2개 배포 후 새로운 v2가 배포되는 경우
v1, v1 >> v1, v1, v2 >> v1, v2, v2 >> v2, v2

 

• • 안정적인 배포 방식이지만 업데이트가 느리다는 단점이 있음
  • 배포할 때 maxSurge 와 maxUnavailable 옵션을 이용해 최대로 생성하는 파드의 개수와 최대로 삭제할 파다의 개수를 설정하도록 함

startey:
 type : RollingUpdate
 rollingUpdate:
  maxSurge : 25%
  maxUnavailable : 25%

 

 

• • 쿠버네티스는 이전 버전을 기억을 하고 있기 때문에 롤백 가능함
    • kubectl rollout undo [Deployment 이름]
    • 이전 상태로 되돌아 감

소스코드 -> 코드 repository -> 이미지 build -> docker 나 kubernetes

소스 코드 차원에서 이전 commit 으로 되돌려서 push를 하면 이전 commit으로 롤백 된 효과를 만들 수
있음

 

 

• recreate 업데이트
  • 예전 On-Premiss 에서 많이 사용하던 방식으로 모든 파드를 중지시키고 새로운 버전으로 재생성 하는 방식
  • 빠르게 업데이트가 가능
  • 새로운 버전의 pod에 문제가 발생하게 되면 대처가 늦다는 단점 (이전 파드를 중지시켰기 때문)

 

• Blue/Green 업데이트
  • 애플리케이션의 이전 버전과 최신 버전을 같이 운영
  • 서비스는 최신 버전만 이루어지며 이전 버전은 테스트 목적으로 사용
  • 새로운 버전의 pod에 문제가 발생하게 되면 빠르게 대응 가능
  • 자원 소모가 심함 (새버전과 이전버전 모두 운영하기 때문)

 

• Canary 업데이트
  • 블루 그린과 유사하며 주로 새로운 기능을 테스트 할 때 이용
  • 두 개의 버전을 모두 배포하는데 새로운 버전에는 트래픽을 조금씩 증가시키고 50%에 도달하면 업데이트를 일시 중지
  • 테스트가 끝나면 이전 버전은 모두 제거 가능
  • sticky session을 이용하면 사용자가 한 번 접속한 서버에 계속 접속하도록 하는 것도 가능함

V1, V1 -> V1, V1, V2, V2
업데이트를 수행한 뒤 처음에는 V2에는 5% 정도의 traffic만 보내고
설정에 따라 일정 비율 씩 V2에 트래픽을 증가시킨다.
V2 트래픽이 50%에 도달하면 업데이트 일시 중지 시킨 뒤 안정화가 된 후 두 개 중 하나의 버전을 제거