[Kubernetes Study - 02] 기본 개념 이해

참고 블로그 : 조대협의 블로그

쿠버네티스 #2 - 개념 이해 (1/2)

 

오브젝트

• 구성요소
  • 기본적인 구성단위가 되는 기본 오브젝트
  • 기본 오브젝트를 생성하고 관리하는 컨트롤러
  • 추가정보인 메타정보
  • 오브젝트 스펙 : 오브젝트의 특성을 기술한 것. yaml이나 json으로 스펙 정의 (manifest file)

 

기본 오브젝트

• 종류
  • Pod : 컨테이너화 된 애플리케이션
  • Service : 로드밸런서
  • Volume : 디스크
  • Namespace : 패키지명

 

Pod

• 쿠버네티스의 가장 기본적인 배포 단위, 컨테이너를 포함하는 배포 단위.
  • Pod은 하나 이상의 컨테이너를 포함하며 여러 컨테이너를 묶어서 배포한다.
  • Pod은 동적으로 생성되고, 장애가 생기면 자동으로 restart 되고 IP가 바뀐다.
• Pod 내의 컨테이너는 IP와 Port를 공유한다.
  • 두 개의 컨테이너가 하나의 Pod를 통해서 배포되었을 때, [localhost](<http://localhost>)를 통해서 통신이 가능하다.
• Pod 내에 배포된 컨테이너 간에는 디스크 볼륨을 공유할 수 있다.

  • 예를 들어, 애플리케이션만 올라가는것이 아니라 Reverse proxy, 로그 수집기등 다양한 주변 솔루션이 같이 배포 되는 경우가 많고, 특히 로그 수집기의 경우에는 애플리케이션 로그 파일을 읽어서 수집한다.

    애플리케이션 (Tomcat, node.js)와 로그 수집기를 다른 컨테이너로 배포할 경우, 일반적인 경우에는 컨테이너에 의해서 파일 시스템이 분리되기 때문에, 로그 수집기가 애플리케이션이 배포된 컨테이너의 로그파일을 읽는 것이 불가능 하지만, 쿠버네티스의 경우 하나의 Pod 내에서는 컨테이너들끼리 볼륨을 공유할 수 있기 때문에 다른 컨테이너의 파일을 읽어올 수 있다.

Volume

• Pod이 시작되면 컨테이너 마다 로컬 디스크가 생성되는데, 로컬 디스크는 컨테이너가 재시작 되거나, 다시 배포될 때 마다 디스크에 기록된 내용이 날아간다. DB와 같이 영속적으로 저장해야되는 경우에는 Volume를 사용한다.
  • 컨테이너의 외장 디스크라고 생각하면 된다. Pod이 시작될 때, 컨테이너에 마운트해서 사용한다.
• Volume은 동일 Pod 내 컨테이너간 공유가 가능하다.

 

Service

• 여러개의 Pod을 서비스하면 각 Pod은 ip가 서로 다를 것이다. 이를 로드밸런서를 이용해 하나의 IP와 포트로 묶어서 서비스를 해야하는데 이러한 기능을 Service에서 할 수 있다.
• Pod의 경우 동적으로 생성이 되고, 장애가 생기면 자동으로 restart 되면서 그 IP가 바뀌기 때문에, 로드밸런서에서 Pod의 목록을 지정할 때는 IP주소를 이용하는 것은 어렵다.
• 또한 오토 스케일링으로 인하여 Pod 가 동적으로 추가 또는 삭제되기 때문에, 이렇게 추가/삭제된 Pod 목록을 로드밸런서가 유연하게 선택해 줘야 한다.
• 그래서 사용하는 것이 라벨(label)과 라벨 셀렉터(label selector) 라는 개념이다.

서비스를 정의할때, 어떤 Pod를 서비스로 묶을 것인지를 정의하는데, 이를 라벨 셀렉터라고 한다. 각 Pod를 생성할때 메타데이타 정보 부분에 라벨을 정의할 수 있다. 서비스는 라벨 셀렉터에서 특정 라벨을 가지고 있는 Pod만 선택하여 서비스에 묶게 된다.

아래 그림은 서비스가 라벨이 myapp인 서비스만 골라내서 서비스에 넣고, 그 Pod간에만 로드밸런싱을 통하여 외부로 서비스를 제공하는 형태이다.

 

 

Namespace

• 쿠버네티스 클러스터 내의 논리적 분리단위
• 하나의 클러스터 내에 개발/운영/테스트 환경이 있을 때 클러스터를 개발/운영/테스트 3개의 namespace로 나눠서 운영할 수 있다.
• Namespace의 기능
  • 사용자별로 namespace의 접근 권한을 다르게 설정 가능
  • namespace 마다 리소스를 다르게 설정 가능.
    • 개발 namespace 는 CPU 100, 운영 namespace에는 CPU 400
• namespace는 논리적인 분리 단위이지 물리적이나 기타 장치를 통해서 환경을 분리(Isolation)한것이 아니다. 다른 namespace간의 pod 라도 통신은 가능하다.
• 물론 네트워크 정책을 이용하여, namespace간의 통신을 막을 수 있지만 높은 수준의 분리 정책을 원하는 경우에는 쿠버네티스 클러스터 자체를 분리하는 것을 권장한다.

 

 

컨트롤러

• 컨트롤러는 기본 오브젝트를 생성하고 관리해주는 역할을 한다
• 종류 : Replication Controller, Replication Set, DaemonSet, Job, StatefulSet, Deployment

Replication Controller(줄여서 RC)

• Selector : label을 기반으로 RC가 관리하는 Pod을 가지고 온다.
• Replica : RC에 의해서 관리되는 Pod의 수. 정해놓은 숫자만큼 Pod가 유지되도록 Pod를 추가,삭제 한다.
• Template : Pod를 추가로 생성할 때, 그 Pod의 정보(도커 이미지, 포트, 라벨 등)을 정의하는 부분
  • 기존에 생성되어 있는 Pod가 template

Replica Set

• RC의 새 버전. Set 기반의 Selector 사용

 

Deployment

• Replication controller와 Replica Set의 좀 더 상위 추상화 개념. 실제 운영에서는 Deployment를 더 많이 사용한다.
• 블루/그린 배포
  • 블루(예전)버전으로 서비스 하고 있던 시스템을 그린(새로운)버전으로 배포한 후, 트래픽을 블루에서 그린으로 한번에 돌리는 방식.
  • 새로운 RC를 만들고, 새로운 템플릿으로 Pod를 생성하고 생성이 끝나면 서비스를 새로운 Pod로 옮기는 방식. 배포가 완료되고 문제가 없으면 예전 버전의 RC와 Pod는 삭제
• 롤링 업그레이드

  • Pod를 하나씩 업그레이드 해가는 방식

  • 새로운 RC를 만들고, 기존 RC에서 replica 수를 하나 줄이고, 새로운 RC에는 replica를 하나 추가한다.

  • 만약, 배포가 잘못 되었을 경우 기존 RC의 replica를 원래대로 늘리고 새로운 RC의 replica를 0으로 만들어서 기존 버전으로 롤백이 가능하다.