쿠버네티스 학습

쿠버네티스

 

쿠버네티스 사용이유?

각 서비스마다 장비를 설치

• 쿠버네티스 사용 전
  • 기업 입장에서 미리 트래픽을 예측하기 어렵고 엄청 많은 자원을 준비하기에도 비용적으로 쉽지 않습니다.
  • 시간과 날짜에 따라, 그리고 사회적인 사건에 따라 트래픽이 매우 달라집니다.
  • 특히 네이버의 경우, 한 서비스만 운영하는 것이 아니라 여러 서비스를 운영하느라 자원을 관리하기 더욱 힘듭니다.
• 쿠버네티스 사용 후
  • 필요한 자원의 양을 예측해서 적정 수준의 장비를 사용할 수 있습니다.
  • 만약 특정 서비스에 더 많이 트래픽을 사용하게 된다면 Auto Scailing 기능을 통해 자원을 알아서 맞춰줍니다.

서버 장애 대응

• 쿠버네티스 사용 전
  • 서비스 중 어떤서버가 고장난 경우 대비할 서버가 필요하기 때문에 각 서비스마다 장비가 추가로 필요합니다.
• 쿠버네티스 사용 후
  • 서비스중인 특정 서버가 고장난 경우 Auto Healing 기능을 통해 장애가 난 서버를 다른 서버로 옮겨줍니다.

서비스 버전 업데이트

• 쿠버네티스 사용 전
  • 서비스 중단이 허용된다면 모든 서버를 중지했다가 한번에 버전업을 합니다.
  • 무중단 서비스의 경우 서비스가 끊기지 않게 서버를 하나씩 버전업을 합니다.
• 쿠버네티스 사용 후
  • Deployment 오브젝트를 통해 업데이트 방식을 자동적으로 처리될 수 있도록 해줍니다.

그 외에도

• 여러 기능의 운영 자동화를 지원합니다.
• 운영환경이 더욱 간편해지고 서비스 효율이 증가합니다.
• 서버를 효율적으로 사용하면서 장비가 줄어들면 그만큼 유지보수 비용이 줄어듭니다.

 

 

VM vs Container

시스템 구조

• VM
  • 장비 위에 Host OS가 올라갑니다.
  • HostOS 위에 VM을 가상화시켜줄 Hypervisor가 올라갑니다.
  • Hypervisor 위에 원하는 여러 Guest OS가 올라갑니다.
    • 각 GuestOS 또한 Host OS와 같이 독립적인 OS로써 사용할 수 있습니다.
• Container
  • 장비 위에 Host OS가 올라갑니다.
  • Host OS 위에 컨테이너를 가상화해줄 소프트웨어(Docker)가 올라갑니다.
  • Docker가 컨테이너들을 만들어 줍니다.
  • 각 컨테이너들은 어떤 OS에서 띄우더라도 실행환경이 같습니다. (Docker가 그렇게 해줌)

성능

• VM은 각각의 OS를 HostOS위에 띄워야 해서 느리고 무겁습니다.
• Container는 HostOS의 자원을 이용해 각 컨테이너에서 사용하기 때문에 빠르고 가볍습니다.

유연성

• VM은 각 Guest OS를 원하는 OS에 맞게 사용할 수 있습니다.
• Container는 서로 다른 OS용 컨테이너를 사용할 수 없습니다.

보안

• VM은 어떤 Guest OS가 뚫리더라도 다른 Guest OS와 Host OS와는 분리되어 있습니다.
• Container는 한 컨테이너가 뚫려서 Host OS가 영향을 받으면 다른 컨테이너들도 영향을 받을 수 있습니다.

 

철학

• VM
  • 보통 서비스를 할 때 한가지 언어를 사용해 여러 모듈을 띄웁니다.
  • 이 때 VM위에서 돌아가고 있는 모듈 중 어떤 모듈이 과부하가 걸린다면
  • VM을 한개 더 만들고 모듈들이 포함된 서비스를 한개 더 띄웁니다.
  • 다른 모듈들은 괜찮은데 특정 모듈 때문에 모든 모듈이 VM에 더 돌아가게 되므로 낭비가 됩니다.
• Container
  • 서비스의 각 모듈을 서로 다른 컨테이너에 담아둡니다.
  • 그 모듈에 맞는 최적화된 언어를 사용할 수 있습니다.
  • 여러 의미에 맞는 컨테이너를 하나의 Pod로 묶을 수 있습니다.
    • Pod: 하나의 배포단위
  • 내가 필요한 Pod만 확장할 수 있습니다.

 

 

Getting Started

예시

다른 장치에 같은 앱을 띄우려면?

• 어떤 장비의 Linux에서 Hello World라는 노드 앱을 띄운다고 가정합니다.
• Hello World 앱을 다른 장비에서 띄워보려고 하지만 Node.js가 설치되어 있지 않아 못 띄웁니다.

그러면 어떤 방법으로 띄울 수 있을까?

• Docker 환경을 구축합니다.
  • Hello World라는 앱을 띄울 수 있는 환경(Node.js)을 컨테이너 이미지로 만듭니다.
  • 컨테이너 이미지를 Docker Hub에 올린 후 다른 장치에서 받을 수 있게 합니다.
  • 다른 장치에서 Dockerfile을 이용해 다음 과정을 실행하여 컨테이너를 만듭니다.
    • 다른 장치에서 컨테이너 이미지를 받아옵니다.
    • 컨테이너 이미지에서 8000번 포트를 열어둡니다.
    • 컨테이너 이미지에 Hello World 파일을 복사합니다.
    • Hello World 파일을 실행합니다.
  • 서비스를 하기 위해 8100 포트를 열어 8000번 포트에 연결해줍니다.
• Kubernetes 환경을 구축합니다.
  • Docker 환경 구축 단계에서 만든 컨테이너 이미지를 Docker Hub에 올립니다.
  • Pod에 컨테이너 이미지를 받아와 Pod를 8000 포트에 구동시킵니다.
  • 외부에서 접근할 수 있는 Service를 만들어 8200 포트를 열어 8000 포트랑 연결해줍니다.

 

 

Kubernetes Overview

클러스터

• 쿠버네티스는 서버 한대는 마스터로 사용하고 다른 서버들은 노드로 사용합니다.
• 한 마스터에 여러 노드들이 연결됩니다.
• 이것이 하나의 쿠버네티스 클러스터라는 개념으로 묶입니다.
• 마스터는 쿠버네티스의 전반적인 기능들을 컨트롤하는 역할입니다.
• 노드들은 자원을 제공하는 역할입니다.
• 클러스터의 자원을 늘이고 싶다면 노드를 추가하면 됩니다.

네임스페이스

• 클러스터 내부의 네임스페이스가 쿠버네티스 오브젝트들을 독립된 공간으로 분리합니다.
• 네임스페이스에는 쿠버네티스 최소 배포단위인 Pod이 있습니다.

Pod

• Pod 안에는 여러 Container가 있습니다

Container

• Container 하나 당 하나의 App이 동작합니다.
• 그래서 Pod 안에서 여러 앱들이 동작할 수 있습니다.

Volume

• Pod에 문제가 생겨서 재생성이 되면 내부 데이터들이 날아갑니다.
• Volume을 만들어서 Pod에 연결하면 데이터는 여기 별도로 저장할 수 있습니다.
• 그래서 Pod이 재생성되서 데이터가 날아가는 문제를 해결할 수 있습니다.

Service

• Pod들에게 외부로부터 연결이 가능하게 IP를 할당해주는 Service가 있습니다.
• Service는 서로 다른 네임스페이스의 Pod들에게는 연결할 수 없습니다.

ResourceQuota / LimitRange

• 네임스페이스에 ResourceQuota와 LimitRange를 달아줍니다.
• 한 네임스페이스에서 사용할 수 있는 자원의 양을 한정시킬 수 있습니다.
• Pod의 개수를 제한 시키거나, CPU나 메모리도 제한시킬 수 있습니다.

ConfigMap / Secret

• Pod 생성 시 Container안에 환경변수 값을 세팅하거나 파일을 마운팅할 수 있는데 ConfigMap이나 Secret을 통해 할 수 있습니다.

Controller

• Controller는 Pod들을 관리해주는 일을 합니다.
• Controller의 종류가 많아 각각의 사용용도가 존재합니다.

1. Replication Controller, ReplicaSet

• Pod이 죽으면 감지해서 다시 살립니다.
• Pod의 개수를 늘이거나 줄일 수 있습니다. (Scale In, Scale Out)

2. Deployment

• 배포후에 Pod들을 새 버전으로 업그레이드 해줍니다.
• 업그레이드 중 문제가 생기면 롤백을 쉽게 할 수 있게 도와줍니다.

3. DaemonSet

• 한 노드의 Pod이 하나씩만 유지되도록 해줍니다.

4. CronJob

• Job은 어떤 특정 작업만 하고 종료시켜야 하는 역할을 Pod이 수행하도록 합니다.
• 이런 Job을 주기적으로 실행해야 할 때 Cron Job을 사용합니다.