[쿠버네티스 인 액션] 1장 - 쿠버네티스 소개

1장에서 다루는 내용

• 최근 소프트웨어의 개발과 배포의 변화 이해
• 애플리케이션을 격리하고 컨테이너를 사용해 실행 환경 차이 줄이기
• 쿠버네티스에서 사용되는 컨테이너와 도커의 이해
• 쿠버네티스로 개발자와 시스템 관리자의 작업 간소화하기

서론

• 소프트웨어 애플리케이션은 원래 거대한 모놀리스였다.
• 레거시 시스템은 릴리스 주기가 느리고 비교적 업데이트가 자주 되지 않는다.
• 거대한 모놀리스 레거시 애플리케이션은 점차 마이크로서비스라는 독립적으로 실행되는 더 작은 구성 요소로 세분화 되고 있다.
• 오늘날 급변하는 비즈니스 요구사항을 충족시키려면 서로 분리되어 있는 마이크로서비스가 적합하다.
• 왜? 개별적으로 개발, 배포, 업데이트, 확장 가능하기 때문에.
• 허나, 배포 가능한 구성 요소가 많아질수록 이를 구성, 관리, 유지하기 어려워졌다.
• 이런 구성 요소를 자동으로 스케줄링하고 구성, 관리, 장애 처리를 포함하는 자동화가 필요하다.
• 이래서 나오게 된게 쿠버네티스이다.
• 쿠버네티스는 하드웨어 인프라를 추상화하고 데이터 센터 전체를 하나의 거대한 컴퓨팅 리소스로 제공한다.

1.1 쿠버네티스와 같은 시스템이 필요한 이유

1.1.1 모놀리스 애플리케이션에서 마이크로서비스로 전환

• 모놀리스 애플리케이션은 결합도가 높고 전체가 하나의 운영체제 프로세스로 실행되어 구성 요소 간의 경계가 불분명해지고 상호의존성의 제약이 커지면서 전체 시스템의 복잡성이 증가하고 품질이 저하된다.
• 일반적으로 시스템이 받아야하는 부하는 점점 증가하고 이를 처리하기 위해선 CPU, 메모리 등 자원이 필요하다.
• 기존에 구성된 서버를 증가하는 부하를 받게끔 만들려면 수직 확장(scale-up)과 수평 확장(scale-out)을 통해 해결해야 한다.
• 수직 확장은 비교적 비용이 많이 들고 확장하는 데 한계가 있다. 하드웨어는 정해져 있기 때문
• 수평 확장은 비용적으로 저렴하지만 애플리케이션 코드의 큰 변경이 필요하고 항상 가능한 것도 아님 모놀리스는 더더욱 그렇다.
• 그래서 이런 문제들을 해결하기 위해 기존의 모놀리스를 마이크로서비스라는 독립적으로 배포할 수 있는 작은 구성 요소로 분할했다.
• 각 마이크로서비스는 독립적인 프로세스로 실행되고 단순하고 잘 정의된 API로 다른 마이크로서비스와 통신한다.
• 마이크로서비스는 일반적으로 RESTful API를 제공하는 HTTP와 같은 동기 프로토콜과 AMQP와 같은 비동기 프로토콜로 통신한다.
• 마이크로 서비스는 구성 요소가 많아지면 요소 간의 종속성 또는 어떤 서버에 어떤 마이크로 서비스 프로세스를 띄워야하는지에 대한 고민으로 배포 관련 결정이 어려워진다.
• 마이크로서비스를 배포할 때 전체가 하나의 시스템처럼 동작할 수 있도록 누군가 또는 무언가가 제대로 구성해야 한다.
• 마이크로서비스 수가 증가함에 따라 이를 구성하는 것은 지루해지고 오류 발생의 가능성이 커진다. 또한 분산되어 있기 때문에 디버깅하기도 쉽지 않다.
• 마이크로서비스 아키텍처는 독립적으로 배포될 뿐 아니라 독립적인 방식으로 개발된다.
• 여러 애플리케이션을 실행하는 서버의 경우 필요한 라이브러리의 버전이 다른 경우가 있어 종속성 문제가 야기된다.
• 서로 다른 버전의 공유 라이브러리가 필요하거나 환경별(DEV, PRD 등)로 다른 특수한 요구사항이 있는 애플리케이션은 종속성 관리하기가 더 어렵다.

1.1.2 애플리케이션에 일관된 환경 제공

• 개발자와 운영 팀이 항상 해결해야 할 문제는 애플리케이션을 실행하는 환경이 다르다는 것이다.
• 그리고 애플리케이션 마다 환경에 따라 실행 환경을 동일화 해야 할 필요가 있다.
• 또한 프로덕션 머신 간에도 시간에 따라서 환경이 달라진다.
• 이러한 이유는 H/W, OS, Lib 등등 다양하다.
• 모든 애플리케이션에 동일한 환경을 주기 위해서는 정확히 동일한 환경을 만들어 줄 필요가 있다. (운영체제, 라이브러리, 시스템 구성, 네트워킹 환경 등)
• 또한 시간이 지남에 따라 환경이 변하는 것도 원치 않는다.

1.1.3 지속적인 배포로 전환 : 데브옵스와 노옵스

• 과거 개발 팀의 업무는 애플리케이션을 만들고 이를 배포하고 관리하며 계속 운영하는 운영 팀에 넘겨주는 것, 하지만 현대는 개발 팀이 배포하고 관리하는 것이 더 낫다고 깨달음.
• 즉, 개발자, QA, 운영 팀이 전체 프로세스에 협업해야 한다는 의미
• 개발자가 프로덕션 환경에서 많이 관여하게 되면 사용자가 무엇을 필요로 하고 어떤 문제가 있는 지, 운영 팀이 애플리케이션을 유지하면서 직면하는 문제가 무엇인지 잘 이해할 수 있다.
• 가장 좋은 방법은 개발자가 운영 팀에 물어보지 않고 직접 애플리케이션을 배포하는 것인데 애플리케이션을 이해하려면 인프라를 이해해야하기 때문에 개발자는 이런 정보를 대개 모른다.
• 또한 개발자는 기능을 개발하고 새로운 기능을 추가하는 것을 중점에 두지만 운영자는 시스템 보안, 사용률, 개발자에게 우선순위가 높지 않은 것에 대해 중점을 둔다.
• 하드웨어 인프라를 전혀 모르더라도 운영 팀을 거치지 않고 개발자가 애플리케이션을 직접 배포하는 것을 노옵스라고 한다.
• 쿠버네티스를 사용하면 하드웨어를 추상화하고 애플리케이션 배포, 실행을 위한 플랫폼으로서 개발자는 시스템 관리자 없이도 배포 가능하다.

1.2 컨테이너 기술 소개

• 쿠버네티스는 애플리케이션을 격리하기 위해서 리눅스 컨테이너 기술을 사용하기 때문에 도커나 rkt와 같은 컨테이너 기술을 알아야 한다.

1.2.1 컨테이너 이해

• 애플리케이션이 작은 수의 커다란 구성 요소로만 이루어진 경우 구성 요소에 전용 가상머신을 제공하고 고유한 운영체제 인스턴스를 제공해 환경을 격리할 수 있다.
• 그러나 각 구성 요소마다 가상머신을 제공하면 하드웨어 리소스를 낭비하게된다. 꼭 하드웨어 뿐만 아니라 가상머신을 개별적으로 구성하고 관리해야 해서 시스템 관리자의 작업량이 증가하기 때문에 인적 자원도 낭비된다.
• 컨테이너는 동일한 호스트 시스템에서 여러 개의 서비스를 실행할 수 있고, 동시에 서로 다른 환경을 만들어줄 뿐만 아니라 가상머신과 유사하게 서로 격리하지만 오버헤드가 훨씬 적다.
• 컨테이너에서 실행되는 프로세스는 다른 모든 프로세스와 마찬가지로 호스트 운영체제 내에서 실행된다. 허나 컨테이너 프로세스는 다른 프로세스와 격리돼 있다. 프로세스의 입장에서 보면 시스템과 운영체제에서 실행되는 유일한 프로세스인 것처럼 보인다.
• 컨테이너는 가상머신과 비교해 훨씬 가벼워서 동일한 하드웨어에서 더 많은 수의 소프트웨어 구성 요소를 실행 가능하다.
• 가상 머신은 시스템 프로세스까지 사용해야 하는데 컨테이너는 호스트 OS에서 실행되는 하나의 격리된 프로세스고, 애플리케이션이 소비하는 리소스만 소비하고 추가 프로세스의 오버헤드는 없다.
• 가상머신은 완전히 분리된 운영체제가 실행되고 동일한 베어메탈 하드웨어를 공유하게 된다. 이런 가상머신 아래에는 물리적 하드웨어 리소스를 각 가상머신 내부의 운영체제에서 사용할 수 있는 더 작은 리소스로 나누는 호스트 OS와 하이퍼바이저가 있다.
• 가상머신 내에서 실행되는 애플리케이션이 가상머신의 게스트 OS 커널에 대한 시스템 콜을 수행하면, 커널은 하이퍼바이저로 호스트의 물리적 CPU에서 x86 명령을 수행한다.

예를 들면 이런 구조

• 반면 컨테이너는 호스트 OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.
• 가상머신의 주요 이점은 각 가상머신이 자체 리눅스 커널을 실행해 완전한 격리를 제공하고, 컨테이너는 동일한 커널을 호출해 보안 위험이 발생할 수 있다.
• 가상머신은 자체 시스템 서비스를 실행하지만 컨테이너는 모두 동일한 OS에서 실행되므로 컨테이너는 시스템 서비스를 실행하지 않는다. 컨테이너에서 실행되는 프로세스는 즉시 시작된다는 말이다.
• 그렇다면 컨테이너는 어떻게 완벽히 프로세스를 격리하는가? 두 가지 메커니즘으로 가능하다.
  • 리눅스 네임스페이스로 각 프로세스가 시스템(파일, 프로세스, 네트워크 인터페이스, 호스트 이름 등)에 대한 독립된 뷰만 볼 수 있도록 한다.
  • 리눅스 컨트롤 그룹으로 프로세스가 사용할 수 있는 리소스(CPU, MEM, Network Bandwidth)의 양을 제한한다.
• 기본적으로 리눅스 시스템은 초기 구동 시 하나의 네임 스페이스가 있다.
• 네임 스페이스는 파일시스템, 프로세스 ID, 사용자 ID, 네트워크 인터페이스 등과 같은 시스템 리소스를 포함한다.
• 프로세스는 실행될 때 네임스페이스 중 하나에서 프로세스를 실행한다.
• 프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼 수 있고, 여러 종류의 네임스페이스가 있을 때 프로세스는 하나의 네임스페이스에만 속하는 것이 아니라 여러 네임스페이스에 속할 수 있다.
• 네임스페이스 종류는 아래와 같다.
  • 마운트 (mnt)
  • 프로세스 ID (pid)
  • 네트워크 (net)
  • 프로세스 간 통신 (ipc)
  • 호스트와 도메인 이름(uts)
  • 사용자 ID (user)
• 각 네임스페이스는 특정 리소스 그룹을 격리하는 데 사용된다.
• UTS는 해당 네임스페이스 내에서 실행 중인 프로세스가 사용할 호스트 이름과 도메인 이름을 결정한다.
• 두 개의 서로 다른 UTS 네임스페이스를 한 쌍의 프로세스에 지정하면 서로 다른 로컬 호스트 이름을 보게 할 수도 있다.
• 두 프로세스를 마치 두 개의 다른 시스템에서 실행 중인 것처럼 보이게 할 수 있다.
• 컨테이너 격리는 또한 시스템 리소스의 양을 제한할 수 있다.
• 이는 프로세스 또는 프로세스 그룹의 리소스 사용을 제한하는 리눅스 커널 기능인 cgroups로 이뤄진다.
• 이런 방식으로 프로세스는 다른 프로세스용으로 예약된 리소스를 사용할 수 없으며, 이는 각 프로세스가 별도의 시스템에서 실행될 때와 비슷하다.

1.2.2 도커 컨테이너 플랫폼 소개

• 도커는 컨테이너를 여러 시스템에 쉽게 이식 가능하게 하는 최초의 컨테이너 시스템이다.
• 도커는 라이브러리, 여러 종속성, 전체 운영체제 파일시스템까지도 다른 도커를 실행하는 컴퓨터에 애플리케이션을 프로비저닝 할 수 있다. 간편히 이식 가능한 패키지로 패키징하는 과정으로
• 도커로 패키징된 애플리케이션을 실행하면 함께 제공된 파일시스템을 정확히 볼 수 있다.
• 도커는 큰 모놀리스 가상 머신 이미지를 사용하는 대신 일반적으로 훨씬 작은 컨테이너 이미지를 사용한다.
• 도커 기반의 컨테이너 이미지는 여러 이미지에서 공유되고 재사용될 수 있는 레이어로 구성돼 있다는 것이다.
• 즉, 동일한 레이어를 포함하는 다른 컨테이너 이미지를 실행할 때 다른 레이어가 이미 다운로드된 경우 이미지의 특정 레이어만 다운로드하면 된다.
• 도커는 애플리케이션에서 필요한 몇 가지 라이브러리나 운영체제의 파일시스템에 설치되는 모든 파일을 포함시킬 수 있다. 도커를 사용하면 이 패키지를 중앙 저장소로 전송할 수 있으며, 도커를 실행하는 모든 컴퓨터에 전송할 수 있다.
• 도커는 주요 세 가지 개념을 갖고 있다.
  • 이미지 : 애플리케이션과 환경을 패키지화한 것 파일시스템과 실행파일 경로와 같은 메타데이터가 포함돼 있다.
  • 레지스트리 : 도커 이미지를 저장하고 다른 사람이나 컴퓨터 간에 해당 이미지를 쉽게 공유할 수 있는 저장소, 컴퓨터에서 이미지를 실행하거나 이미지를 레지스트리로 푸시(업로드)한 다음 다른 컴퓨터에서 이미지를 풀(다운로드)할 수 있다. Public 레지스트리와 Private 레지스트리가 있으며, Public은 누구나 이미지를 가져올 수 있고, Private는 사내 개발망 내에서만 사용한다.
  • 컨테이너 : 도커 기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너, 컨테이너는 도커를 실행하는 호스트에서 실행되는 프로세스이지만 호스트와 호스트에서 실행중인 프로세스와 완전히 격리되어 있다. (namespace)
    또 프로세스는 리소스 사용량이 제한 돼 있으므로 할당량만 액세스하고 사용 가능 (cgroup)
• 도커 이미지의 빌드, 배포, 실행은 이런 과정으로 이루어진다.
  • 개발자는 먼저 이미지를 만든 다음 레지스트리로 푸시
  • (퍼블릭 레지스트리의 경우) 이미지는 레지스트리에 접근할 수 있는 모든 사람이 사용 가능
  • 도커가 실행되는 다른 컴퓨터로 이미지를 가져와 이미지를 실행할 수 있다.
  • 도커는 이미지를 기반으로 격리된 컨테이너를 만들고 이미지의 일부로 지정된 바이너리 실행파일을 실행한다.

예를 들어 이런 과정

• 도커랑 가상머신은 어떻게 다른가?
  • 도커는 각각 컨테이너가 격리된 파일시스템이 있다. 허나, 컨테이너는 같은 파일을 공유할 수도 있다. 왜?
  • 도커 이미지는 레이어로 구성되어 있기 때문에 그렇다 이게 무슨 말이냐면 두 개의 이미지가 있다고 가정 했을 때 두 이미지는 기본 이미지로 동일한 이미지를 사용할 수 있다. 그렇다면 동일한 레이어가 포함될 수 있다는 말이다.
    A에서 썼던 레이어를 B에서도 동일하게 쓴다면 A로 전송한 레이어 정보를 갖고 있어 B 레이어로 다시 전송할 필요가 없기 때문에 네트워크로 이미지를 배포하는 속도가 빨라진다.
• 이미지 레이어란?
  • 레이어는 배포에만 도움이 될 뿐만 아니라 스토리지 공간을 줄이는 데 도움이 된다. 각 레이어는 동일 호스트에 한 번만 저장된다.
  • 레이어는 읽기 전용이기 때문에 동일한 파일을 공유하더라도 서로 격리되어 있다.
• 컨테이너 이미지의 제한적 이식성
  • 이론적으로 컨테이너 이미지는 도커를 실행하는 모든 리눅스 시스템에서 실행될 수 있지만 모든 컨테이너는 호스트의 리눅스 커널을 사용하기 때문에 컨테이너 위의 애플리케이션이 특정 커널 버전을 사용한다면 모든 리눅스 시스템에서 사용되지 못할수도 있다.
  • 또한, x86 아키텍처용으로 만들어진 애플리케이션을 ARM 기반 컴퓨터에서 도커가 실행된다고 해서 컨테이너화할 수 없다.
• 도커의 대안으로 rkt 라는 컨테이너 엔진이 있다.
  • 도커가 사람들에게 많이 쓰여진 뒤 컨테이너 형식과 런타임에 관한 개방된 업계 표준을 만들려고 OCI가 탄생했다.
  • 도커와 마찬가지로 rkt도 컨테이너를 실행하기 위한 플랫폼이다. 보안, 결합성, 공개 표준 준수에 중점을 둔다.
  • OCI 컨테이너 이미지 형식을 사용하며 일반 도커 컨테이너 이미지를 실행할 수도 있다.

1.3 쿠버네티스 소개

• 애플리케이션 구성 요소의 수가 많아짐에 따라 모든 구성 요소를 관리하고 비용 효율적으로 개발, 배포할 수 있는 솔루션을 개발해야만 했다.

1.3.1 쿠버네티스의 기원

• 구글은 쿠버네티스 이전에 보그(오메가)라는 내부 시스템을 개발해 애플리케이션을 관리 해왔다.
• 이를 기반으로 쿠버네티스를 출시했다.

1.3.2 넓은 시각으로 쿠버네티스 바라보기

• 쿠버네티스는 컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다.
• 리눅스 컨테이너 기능에 의존해 내부 세부 사항을 알 필요 없이 각 호스트에 애플리케이션을 자동으로 이기종 애플리케이션을 실행 가능하다.
• 애플리케이션은 격리된 환경에서 구동되고 하드웨어를 최대한 활용한다.
• 쿠버네티스를 사용하면 모든 노드가 하나의 거대한 컴퓨터인 것처럼 수천 대의 컴퓨터 노드에서 소프트웨어 애플리케이션을 실행할 수 있다. 기본 인프라를 추상화하고 개발과 운영 팀 모두의 개발, 배포, 관리를 단순화한다.
• 쿠버네티스는 마스터 노드와 여러 워커 노드로 구성된다.
• 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커 노드 클러스터에 배포한다. 구성 요소가 어느 노드에 배포되든지 개발자나 시스템 관리자에게 중요하지 않다.
• 애플리케이션은 클러스터에 걸쳐 분산되지만 배포된 위치에 상관없이 동일한 방식으로 서로 통신할 수 있다.
• 개발자는 쿠버네티스에 의존해 인프라 관련 서비스를 애플리케이션에 구현하지 않아도 된다.
• 서비스 디스커버리, 스케일링, 로드밸런싱, self-healing, 리더 선출 같은 것들이 포함된다.
• 그리하여, 개발자는 애플리케이션의 실제 기능을 구현하는 데 집중 가능하고 애플리케이션을 인프라와 통합하는 방법을 찾는 데 시간을 낭비하지 않아도 된다.
• 운영팀도 마찬가지로 쿠버네티스에 의존해 애플리케이션을 자동으로 구성해 편리하게 사용한다.

1.3.3 넓은 시각으로 쿠버네티스 바라보기

• 하드웨어 수준에서 쿠버네티스 클러스터는 여러 노드로 구성되며, 두 가지 유형으로 나눌 수 있다.
  • 마스터 노드는 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행한다.
  • 워커 노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다.

이런 구조

• 컨트롤 플레인
  • 컨트롤 플레인은 클러스터를 제어하고 작동시킨다. 하나의 마스터 노드에서 실행하거나 여러 노드로 분할되고 복제돼 고가용성을 보장할수 있는 여러 구성 요소로 구성된다.
  • 쿠버네티스 API 서버는 사용자, 컨트롤 플레인 구성 요소와 통신한다.
  • 스케줄러는 애플리케이션의 배포 가능한 각 구성 요소를 워크노드에 할당하는 애플리케이션의 배포를 담당한다.
  • 컨트롤러 매니저는 구성 요소 복제본, 워커 노드 추적, 노드 장애 처리 등과 같은 클러스터단의 기능을 수행한다.
  • Etcd는 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소다.
  • 컨트롤 플레인의 구성 요소는 클러스터 상태를 유지하고 제어하지만 애플리케이션을 실행하진 않는다. 이는 노드에 의해 이뤄진다.
• 노드
  • 워커 노드는 컨테이너화된 애플리케이션을 실행하고 모니터링하며 애플리케이션에 서비스를 제공한다.
  • 컨테이너 런타임은 컨테이너를 실행하는 도커, rkt 또는 다른 것들을 의미
  • Kubelet은 API 서버와 통신하고 노드의 컨테이너를 관리한다.
  • Kube-proxy는 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱한다.

1.3.4 쿠버네티스에서 애플리케이션 실행

• 쿠버네티스에서 애플리케이션을 실행하려면 일단 컨테이너 이미지가 필요하고, 해당 이미지를 레지스트리로 푸시한 다음 쿠버네티스 API 서버에 애플리케이션 디스크립션을 게시해야 한다.
• 이 디스크립션에는 컨테이너 이미지, 애플리케이션 구성 요소가 포함된 이미지, 해당 구성 요소가 서로 통신하는 방법, 동일 서버에 함께 배치돼야 하는 구성요소와 같은 정보가 포함된다. 또한 내부 또는 외부 클라이언트에 서비스를 제공하는 구성 요소와 하나의 IP 주소로 노출해 다른 구성 요소에서 검색 가능하게 해야 하는 구성 요소가 포함된다.
• API 서버가 애플리케이션 디스크립션을 처리할 때 스케줄러는 각 컨테이너에 필요한 리소스를 계산하고 각 노드에 할당되지 않은 리소스를 기반으로 사용 가능한 워커 노드에 지정된 컨테이너를 할당한다.
• 그런 다음 Kubelet은 컨테이너 런타임에 필요한 컨테이너 이미지를 가져와 컨테이너를 실행하도록 지시한다.
• 애플리케이션이 실행되면 쿠버네티스는 애플리케이션의 배포 상태가 사용자가 제공한 디스크립션과 일치하는지 지속적으로 확인한다.
• 프로세스가 중단되거나 응답이 중지될 때와 같이 인스턴스가 제대로 작동하지 않으면 쿠버네티스가 자동으로 다시 시작한다.
• 마찬가지로 워커 노드 전체가 종료되거나 액세스할 수 없게 되면 쿠버네티스는 이 노드에서 실행 중인 모든 컨테이너의 노드를 새로 스케줄링하고, 새로 선택한 노드에서 실행한다.
• 애플리케이션이 실행되는 동안 복제본 수를 늘릴지 줄일지 결정할 수있으며, 쿠버네티스는 추가 복제본을 기동하거나 초과 복제본을 정지시킬 것이다. 최적의 복제본 수를 결정하는 작업을 쿠버네티스에 맡길 수도 있다.
• 쿠버네티스는 컨테이너를 클러스터 안에서 이동시킬 수도 있다. 컨테이너가 외부 클라이언트나 클러스터에서 실행 중인 다른 컨테이너에 서비스를 제공하는 경우 이 컨테이너가 클러스터에서 지속적으로 이동한다면 어떻게 해야하는가? 또 이 컨테이너가 복제 돼 전체 클러스터에 분산되면 클라이언트가 서비스를 제공하는 컨테이너에 어떻게 접근할 수 있을까?
• 클라이언트가 특정 서비스를 제공하는 컨테이너를 쉽게 찾을 수 있도록 쿠버네티스에게 동일한 서비스를 제공하는 컨테이너를 알려주면 쿠버네티스는 하나의 고정 IP 주소로 모든 컨테이너를 노출하고 해당 주소를 클러스터에서 실행 중인 모든 애플리케이션에 노출한다. 이는 환경변수로 제공되지만 클라이언트는 DNS로 서비스 IP를 조회할 수도 있다.
• kube-proxy는 서비스를 제공하는 모든 컨테이너에서 서비스 연결이 로드밸런싱되도록 한다. 서비스 IP 주소는 일정하게 유지되므로 클라이언트는 컨테이너가 클러스터 내에서 이동하더라도 컨테이너에 할상 연결할 수 있다.

이런 느낌이지 않을까?

1.3.5 쿠버네티스 사용의 장점

• 쿠버네티스를 모든 서버에 설치하면 운영 팀이 더 이상 애플리케이션 배포를 처리할 필요가 없다. 컨테이너화된 애플리케이션은 이미 실행에 플요한 모든 것이 포함돼 있기 때문에, 운영 팀에서 추가적으로 설치할 필요가 없다.
• 쿠버네티스는 모든 워커 노드를 하나의 배포 플랫폼으로 제공하기 때문에 애플리케이션 개발자는 자체적으로 애플리케이션 배포를 시작할 수 있고, 클러스터를 구성한느 서버에 관해 알 필요가 없다.

그외 생략... (뒤에 다 나오는 내용들을 앞에서 소개한 것이라)

 

 

느낀 점

뒷 내용에 다 나오는 이야기들을 앞에 간략하게 서술하는 개요 같은 느낌이 들었다. 이미 한번 책을 훑어봐서 그런지 읽지 않아도 될 것같은 느낌도 받았는데, 기초적인 것들을 한번 더 다잡는 느낌으로 읽었음 정리할 때 마구잡이로 내용을 적지 않아도 될듯함.

정리

• 컨테이너나 쿠버네티스가 나오기 시작한데는 MSA라는 개념이 있다. MSA는 기존의 모놀리식 구조에서 벗어나서 애플리케이션이나 구성 요소들이 분산된 구조를 갖는 것. 왜? 모놀리식으로 가져가면 장애 전파나 단일 장애 지점을 만들 수 있고, 애플리케이션의 종속성이 너무 강해서 무언가 추가 되거나 뺄때 굉장히 곤란했기 때문에
• 쿠버네티스를 알기 위해서는 가상화 즉, 가상머신과 도커 컨테이너의 차이를 알고 시작하는 게 좋다.
• 도커 컨테이너는 동일한 호스트 OS를 실행하기 때문에 가상 머신과는 다른게 동일한 리눅스 커널을 사용한다. 가상 머신은 게스트 OS라는 또 다른 OS를 두어 각각 분리된 환경을 구성하기 때문에 보안적으로는 이점이 있으나 오버헤드가 너무 심하다. 그에 비해 도커는 동일한 리눅스 커널을 쓰고 리눅스 커널에서 사용하는 namespace와 cgroup으로 환경을 격리시키고 자원을 분리시켜 오버헤드를 줄이고 다른 환경에서 실행될 수 있게끔 한다.
• 도커는 이미지, 레지스트리, 컨테이너라는 세 가지 구조로 이루어져있음
  • 이미지는 레이어 기반으로 되어 있고, 애플리케이션을 패키지화 한 것. 파일 시스템이나 메타 데이터가 있다.
  • 이미지가 레이어 기반으로 되어있다는 이야기는 여러 개의 층으로 한 이미지를 구성하고 있다고 생각하면 되고, 패키지를 구성하는 작은 단위라고 생각하는 게 편할듯?
  • 레이어는 호스트에 저장되고 A 이미지를 구성해 레지스트리에서 이미지를 이미 가져 왔다고 가정했을 때 동일한 레이어가 있는 B 이미지가 있다면 그 동일한 이미지를 다시 가져오지 않아도 되어 배포 속도가 빨라지는 장점이 있음
  • 또한 이미 저장된 레이어를 사용하면 되기 때문에 스토리지 공간 활용에도 이점이 있다.
  • 이미지에 레이어가 한번 구성되고 나면 해당 레이어는 읽기 전용으로서 바뀌지 않으며 바꾸고 싶다면 이미지 기반으로 컨테이너를 띄워 읽기쓰기로 변경한 뒤 바꾸어야 함 (근데 컨테이너를 띄우고 내용을 바꾸고 바뀐 내용을 다시 이미지로 구성하지 않는다면 또 동일한 이미지로 띄워짐)
  • 레지스트리는 이미지를 저장하는 저장소라고 생각하면 된다. 이미지를 다른 사람들과 공유하고 저장하는 역할을 함. Private와 Public 환경이 있으며 Private는 주로 사내망에서 이미지를 저장하고 공유하기 위해서 사용하고, Public은 모든 사람들과 저장하고 공유하기 위해서 사용한다. 개발자는 이미지를 만들고 레지스트리에 푸시(업로드)하고 또 풀(다운로드)할 수 있음
  • 컨테이너는 리눅스에서 도커 런타임 기반으로 애플리케이션을 구성하는 하나의 단위라고 생각하면 됨
• 쿠버네티스는 많은 수의 컨테이너를 쉽게 관리하기 위해서 만들어진 오케스트레이션 도구이다.
• 쿠버네티스는 컨트롤 플레인과 워커 노드로 이루어져 있음
  • 컨트롤 플레인은 클러스터를 관리하는 역할을 해준다.
    • etcd : 클러스터 구성을 저장하는 분산 데이터 저장소
    • API 서버 : 개발자와 통신하고, 워커 노드와 통신하는 역할을 함
    • 스케줄러 : 실제 애플리케이션을 배포하는 역할을 함
    • 컨트롤러 매니저 : 구성 요소 복제본, 노드 장애 복구, 워커 노드 추적, 클러스터 단의 기능을 수행
  • 워커 노드는 실제 애플리케이션을 띄우는 역할을 한다.
    • Kubelet : 컨트롤 플레인의 API 서버와 통신하면서 노드와 컨테이너를 관리 함
    • Kube-proxy : 애플리케이션 간에 트래픽을 로드 밸런싱한다.
    • 컨테이너 런타임 : 도커나 rkt 와 같이 컨테이너를 띄우는 런타임

참고 자료

쿠버네티스 인 액션