목차

1. Blue/Green
2. canary
3. rolling update

Blue/Green 배포

블루-그린 배포는 로드 밸런서, Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼 또는 자동화된 배포 파이프라인을 비롯한 다양한 기술을 사용하여 구현할 수 있습니다. 핵심은 모든 문제에 대해 애플리케이션을 모니터링하면서 이전 버전에서 새 버전으로 트래픽을 점진적으로 전환하는 방법을 갖는 것입니다.

이 방식은 새 버전의 소프트웨어 애플리케이션을 릴리스하는 데 사용되는 배포 전략입니다. 이 접근 방식에서는 애플리케이션의 새 버전이 이전 버전과 함께 배포되지만 처음에는 트래픽이 이전 버전으로만 전달됩니다. 새 버전이 테스트되고 안정적인 것으로 확인되면 트래픽을 완전히 제공하고 이전 버전이 더 이상 필요하지 않을 때까지 트래픽이 점차 새 버전으로 이동됩니다.

"블루-그린 배포"라는 이름은 응용 프로그램의 이전 버전을 "블루" 버전이라고 하고 새 버전을 "그린" 버전이라고 한다는 사실에서 유래되었습니다. 이 접근 방식은 기존 배포 방법에 비해 다음과 같은 몇 가지 이점을 제공합니다.

• 장점
  
  1. 가동 중지 시간 최소화
     블루-그린 업데이트를 사용하면 트래픽이 전환되기 전에 새 버전이 이전 버전과 함께 배포되므로 가동 중지 시간이 최소화됩니다.
     
     
  2. 손쉬운 롤백
     새 버전에서 문제가 감지되면 두 버전이 동시에 실행되므로 이전 버전으로 쉽게 롤백할 수 있습니다.
     
     
  3. 위험 감소
     애플리케이션의 두 버전이 동시에 실행되기 때문에 사용자에게 영향을 미치는 문제나 오류의 위험이 줄어듭니다.
• 단점
  
  1. 비용
     두 버전의 애플리케이션을 동시에 배포하고 실행해야 하므로 블루-그린 업데이트에는 더 높은 인프라 비용이 필요합니다.
     
     
  2. 복잡성
     두 개의 별도 배포를 관리하는 것은 단일 배포를 관리하는 것보다 더 복잡할 수 있습니다.

작동 방식예시

1. 웹 애플리케이션 시나리오에서 애플리케이션의 프런트 엔드 코드를 업데이트한다고 가정합니다. 블루-그린 배포를 사용하면 프런트 엔드 코드의 새 버전("녹색" 버전)을 만들고 기존 버전("청색" 버전)과 함께 배포합니다. 트래픽은 처음에 녹색 버전이 테스트되는 동안 파란색 버전으로 전달됩니다. 그린 버전이 철저히 테스트되면 트래픽이 완전히 처리되고 블루 버전이 해제될 수 있을 때까지 트래픽이 점차 그린 버전으로 전환됩니다.
   
   
2. 마이크로서비스 아키텍처에는 애플리케이션을 제공하기 위해 함께 작동하는 여러 서비스가 있을 수 있습니다. 블루-그린 배포를 사용하면 이전 버전("블루" 버전)을 계속 실행하면서 각 서비스를 한 번에 하나씩 새 버전("그린" 버전)으로 업데이트합니다. 모든 서비스가 업데이트되면 트래픽을 완전히 처리하고 이전 버전이 더 이상 필요하지 않을 때까지 트래픽이 새 버전으로 전환됩니다.
   
   
3. 클라우드 인프라 환경에서는 고가용성을 보장하기 위해 실행 중인 애플리케이션의 여러 인스턴스가 있을 수 있습니다. 블루-그린 배포를 사용하면 기존 인스턴스("파란색" 인스턴스)와 함께 새 버전의 애플리케이션("녹색" 인스턴스)으로 새 인스턴스 세트를 생성합니다. 트래픽은 처음에 녹색 인스턴스가 테스트되는 동안 파란색 인스턴스로 전달됩니다. 녹색 인스턴스가 철저히 테스트되면 트래픽을 완전히 처리하고 파란색 인스턴스를 폐기할 수 있을 때까지 트래픽이 점차 녹색 인스턴스로 전환됩니다.

블루-그린 배포를 통해 다운타임이나 사용자 중단 없이 새 버전으로 원활하게 전환할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

Blue/Green 배포 방식을 사용하는 기업

• Netflix
  Netflix는 블루-그린 배포를 사용하여 새 버전의 소프트웨어를 배포하는 것으로 유명합니다. 예를 들어 스트리밍 서비스를 업데이트할 때 이전 버전("파란색" 서버)과 함께 새로운 서버 집합("녹색" 서버)에 새 버전을 배포합니다. 그린 서버가 완전히 테스트되고 작동되면 트래픽을 완전히 처리할 때까지 트래픽이 점진적으로 이동되며 블루 서버는 해제될 수 있습니다.
  
  
• AWS
  AWS Elastic Beanstalk는 블루-그린 배포 접근 방식을 사용하여 애플리케이션에 업데이트를 배포합니다. 업데이트된 버전의 애플리케이션을 위한 새 환경을 생성하고 트래픽을 완전히 제공할 때까지 점진적으로 트래픽을 라우팅하며 문제가 발생할 경우 이전 환경이 계속 실행됩니다.

Canary(카나리/카나리아) 배포

카나리 배포는 사용자 또는 서버의 작은 하위 집합이 나머지 사용자 또는 서버보다 먼저 새 버전의 애플리케이션으로 업데이트되는 배포 기술입니다. 이를 통해 더 많은 청중에게 배포하기 전에 라이브 환경에서 새 버전을 테스트할 수 있습니다.

"카나리"라는 이름은 유독 가스에 대한 조기 경보 시스템으로 탄광에서 카나리를 사용하는 관행에서 유래되었습니다. 마찬가지로 소프트웨어 개발에서 카나리 배포는 애플리케이션의 새 버전과 관련된 문제나 오류에 대한 조기 경고 시스템 역할을 합니다.

카나리 배포는 사용자 또는 서버의 하위 집합에 새 릴리스를 점진적으로 롤아웃하고 나머지 사용자 또는 서버에 대해 기존 버전을 계속 실행하여 통제된 방식으로 새 소프트웨어 릴리스를 테스트하는 데 사용되는 기술입니다.

• 장점
  
  1. 위험 감소
     카나리 업데이트를 사용하면 모든 사용자에게 배포하기 전에 더 작은 사용자 또는 서버 하위 집합에서 새로운 기능이나 업데이트를 테스트할 수 있으므로 모든 사용자에게 영향을 미치는 문제나 오류의 위험을 줄일 수 있습니다.
     
     
  2. 초기 피드백
     사용자 또는 서버의 더 작은 하위 집합에서 새 업데이트를 테스트함으로써 조직은 모든 ​​사람에게 배포되기 전에 새 버전에 대한 초기 피드백을 받을 수 있습니다.
     
     
  3. 손쉬운 롤백
     새 버전에서 문제가 감지되면 일부 사용자 또는 서버만 영향을 받았기 때문에 이전 버전으로 쉽게 롤백할 수 있습니다.
• 단점
  
  1. 복잡성
     여러 배포를 관리하는 것은 단일 배포를 관리하는 것보다 더 복잡할 수 있습니다.
     
     지연된 롤아웃
     새 버전은 일부 사용자 또는 서버에만 롤아웃되므로 모든 사용자 또는 서버에 대한 롤아웃이 지연될 수 있습니다.

카나리 배포는 트래픽 분할, 기능 플래그 또는 점진적 롤아웃과 같은 다양한 기술을 사용하여 구현할 수 있습니다. 핵심은 애플리케이션의 성능을 모니터링하면서 애플리케이션을 점진적으로 업데이트하고 필요한 경우 신속하게 롤백하는 방법을 갖추는 것입니다.

작동 방식 예시

1. 많은 사용자에게 서비스를 제공하는 웹 애플리케이션이 있고 새 기능을 릴리스하려고 합니다. 한 번에 모든 사용자에게 기능을 릴리스하는 대신 카나리 배포를 사용하여 사용자 하위 집합에서 새 기능을 테스트하기로 결정합니다.
   
   
2. 소수의 사용자(예: 5%)를 카나리 그룹의 일부로 식별하고 나머지 사용자는 애플리케이션의 기존 버전을 계속 사용합니다.
   
   
3. 새 버전의 애플리케이션을 서버의 하위 집합에 배포하고 사용자 비율에 따라 애플리케이션의 이전 버전과 새 버전 모두에 트래픽을 전달하도록 로드 밸런서를 구성합니다.
   
   
4. 사용자가 사이트를 방문함에 따라 로드 밸런서는 애플리케이션의 새 버전으로 이동하는 사용자 비율을 점진적으로 늘립니다.
   
   
5. 새 버전의 애플리케이션을 주의 깊게 모니터링하여 문제나 오류가 없는지 확인합니다.
   
   
6. 문제가 감지되면 신속하게 배포를 롤백하고 모든 사용자를 이전 버전으로 다시 리디렉션할 수 있습니다.
   
   
7. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 새 버전으로 이동하는 사용자 비율을 늘려 모든 사용자에게 점진적으로 새 기능을 출시할 수 있습니다.

카나리 배포를 통해 모든 사용자에게 한 번에 영향을 주지 않고 통제된 환경에서 새로운 기능을 테스트할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

Canary 배포 방식을 사용하는 기업

• Facebook
  Facebook은 카나리 배포를 사용하여 소프트웨어의 새 버전을 모든 사용자에게 배포하기 전에 소수의 사용자에게 테스트합니다. 예를 들어 모바일 앱을 업데이트할 때 소규모 사용자 하위 집합에 새 버전을 출시하고 더 많은 사용자에게 점진적으로 출시하기 전에 피드백을 모니터링할 수 있습니다.
  
  
• LinkedIn
  LinkedIn은 카나리 배포를 사용하여 웹 사이트의 새 버전을 테스트합니다. 새 버전을 서버의 하위 집합에 배포하고 점진적으로 트래픽을 해당 서버로 라우팅하면서 나머지 서버에서 이전 버전을 계속 실행합니다. 이를 통해 모든 사용자에게 릴리스하기 전에 실제 환경에서 새 버전을 테스트할 수 있습니다.

Rolling Update 배포

롤링 업데이트 배포는 배포 프로세스 중에 응용 프로그램을 실행하고 사용자가 사용할 수 있도록 유지하면서 이전 버전에서 새 버전으로 원활하고 점진적으로 전환할 수 있는 소프트웨어 응용 프로그램을 업데이트하기 위한 전략입니다.

롤링 업데이트 배포는 애플리케이션에 대한 트래픽을 관리하기 위해 로드 밸런서 또는 기타 기술과 함께 자주 사용됩니다. 롤링 업데이트 배포의 주요 이점은 새 버전이 완전히 배포되어 작동할 때까지 애플리케이션의 이전 버전을 계속 사용할 수 있기 때문에 사용자의 중단 및 중단 시간을 최소화한다는 것입니다.

롤링 업데이트를 사용하면 업데이트 프로세스 중에 애플리케이션을 실행하고 사용자가 사용할 수 있도록 유지하면서 애플리케이션의 이전 버전에서 새 버전으로 원활하고 점진적으로 전환할 수 있습니다. 새 버전을 한 번에 서버 하위 집합에 배포하고 성능을 면밀히 모니터링함으로써 조직은 모든 ​​사용자 또는 서버에 한 번에 영향을 미치는 문제나 오류의 위험을 최소화할 수 있습니다.

• 장점
  
  1. 가동 중지 시간 최소화
     롤링 업데이트를 통해 상당한 가동 중지 시간이나 사용자 중단 없이 점진적으로 업데이트를 배포할 수 있습니다.
     
     
  2. 손쉬운 롤백
     새 버전에서 문제가 감지되면 두 버전의 애플리케이션이 동시에 실행되므로 이전 버전으로 쉽게 롤백할 수 있습니다.
     
     
  3. 비용 효율적
     한 번에 한 버전의 애플리케이션만 실행되므로 롤링 업데이트는 인프라 비용이 적게 듭니다.
     
     
• 단점:
  
  1. 더 긴 배포 시간
     새 버전이 모든 서버에 롤아웃되기 전에 서버 하위 집합에 점진적으로 배포되므로 롤링 업데이트를 배포하는 데 시간이 더 오래 걸릴 수 있습니다.
     
     
  2. 문제 위험
     새버전이 점진적으로 배포되기 때문에 배포 과정에서 사용자에게 영향을 미치는 문제 또는 오류의 위험이 있습니다.

작동 방식 예시

1. 애플리케이션의 새 버전을 준비하여 시작합니다. 여기에는 코드 변경, 새 기능 추가 또는 라이브러리 또는 종속성 업데이트가 포함될 수 있습니다.
   
   
2. 나머지 서버에서 실행 중인 이전 버전을 유지하면서 서버의 하위 집합에 새 버전을 배포합니다. 로드 밸런서를 사용하여 애플리케이션의 이전 버전과 새 버전 간에 트래픽을 라우팅할 수 있습니다.
   
   
3. 새 버전의 애플리케이션으로 전달되는 트래픽 비율을 점진적으로 늘립니다. 예를 들어 트래픽의 10%를 새 버전으로 보낸 다음 20%, 50% 등으로 늘릴 수 있습니다.
   
   
4. 애플리케이션의 새 버전을 주의 깊게 모니터링하여 문제나 오류가 없는지 확인하십시오. 문제가 감지되면 신속하게 배포를 롤백하고 트래픽을 이전 버전으로 다시 리디렉션할 수 있습니다.
   
   
5. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 모든 트래픽을 새 버전으로 리디렉션하고 이전 버전을 폐기할 수 있습니다.

롤링 업데이트를 사용하면 중단 시간이나 사용자 중단 없이 새 버전으로 원활하게 전환할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

Rolling Update 배포를 사용하는 기업

Google
Google은 롤링 업데이트를 자주 사용하여 새 버전의 서비스를 배포합니다. 예를 들어 검색 엔진 알고리즘을 업데이트할 때 서버의 하위 집합에 새 버전을 점진적으로 롤아웃하고 나머지 서버에서는 이전 버전을 계속 실행합니다. 이를 통해 Google은 새 버전을 면밀히 모니터링하고 문제나 버그를 식별하며 필요한 경우 신속하게 배포를 롤백할 수 있습니다. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 모든 서버에 출시됩니다.

이 글을 읽고 배포 방법을 결정할 때 유의할 점은 "Google이 쓰니까 이게 더 좋은거야"라는 생각은 금물이라는 것 입니다. 각자가 맡은 프로젝트가 어떤 것인지 잘 파악하고, 어떤 방식으로 진행하는것이 더 효율적이고 비용절감이 가능할지 생각하는게 먼저가 되야합니다.

목차

1. 여러 특정 애플리케이셔을 하나의 파드안에 넣어도 될까?
2. 문제점 예시
3. 개별 확장이 가능하도록 파드를 분할하자.
4. 파드에서 여러 컨테이너를 사용하는 경우

1. 여러 특정 애플리케이셔을 하나의 파드안에 넣어도 될까?
   
   파드를 각각 별도의 머신으로 생각할 수도 있을 것 같습니다. 하지만, 파드는 특정한 애플리케이션만을 호스팅합니다. 즉, 한 호스트에 모든 유형의 애플리케이션을 넣었던 이전과 달리, 파드는 그렇게 사용하지 않는다는 뜻입니다. 파드는 상대적으로 가볍기 때문에 오버헤드 없이 필요한 만큼 파드들을 가질 수 있습니다. 모든 것을 파드 하나에 넣는 대신 애플리케이션을 여러 파드로 구성하고, 각 파드에는 밀접하게 관련있는 구성 요소나 프로세스만 포함해야 합니다.
   
   그렇다면 프론트엔드 애플리케이션 서버와 백엔드 데이터베이스로 구성된 다중 레이어 애플리케이션을 구성할 때 단일 파드 또는 두개의 파드로 구성해야만 할까요?
   
   이전에 다루었던 것과 마찬가지로 하나의 파드에는 하나의 컨테이너를 동작시키는 것을 권장했었는데요. 일반적으로 프런트엔드 애플리케이션 서버와 백엔드 데이터베이스도 마찬가지로 두 개의 별도 포드로 분리하는 것이 좋은데, 리소스 요구 사항과 확장 요구 사항이 다르기 때문입니다.
   
   프런트엔드 애플리케이션 서버는 사용자 요청을 처리하고 애플리케이션 로직을 실행하기 위해 더 많은 CPU 및 메모리 리소스가 필요할 수 있는 반면, 백엔드 데이터베이스는 데이터를 관리하기 위해 더 많은 스토리지 및 디스크 I/O 리소스가 필요할 수 있습니다. 또한 증가된 트래픽을 처리하기 위해 프런트엔드 애플리케이션 서버를 수평으로 확장해야 할 수 있는 반면 백엔드 데이터베이스는 증가한 데이터 볼륨을 처리하기 위해 수직으로 확장해야 할 수 있습니다.
   
   프런트엔드와 백엔드를 두 개의 별도 포드로 분리하면 내결함성과 안정성이 향상됩니다. Pod 중 하나에 오류가 발생하면 다른 포드가 중단 없이 계속 작동하여 전체 애플리케이션에 대한 오류의 영향을 줄일 수 있습니다.
   
   
2. 문제점 예시
   
   실제로 프론트엔드 서버와 데이터베이스 컨테이너 두 개로 구성된 단일 파드를 실행하지 못하는 것은 아닙니다. 하지만 프론트엔드와 백엔드가 같은 파드에 있다면, 둘은 항상 같은 노드에서 실행될 것 입니다. 만약에 두 노드를 가진 쿠버네티스 클러스터가 있고 이 파드 하나만 있다면, 워커 노드 하나만 사용하고 두 번째 노드에서 이용할 수 있는 컴퓨팅 소스(GPU, 메모리)를 활용하지 않고 그냥 버리게 됩니다. 파드를 두 개로 분리한다면 쿠버네티스가 프론트엔드를 한 노드로 그리고 백엔드는 다른 노드에 스케줄링해 인프라스트럭처의 활용도를 향상시킬 수 있습니다.
   
   
3. 개별 확장이 가능하도록 파드를 분할하자.
   
   두 컨테이너를 하나의 파드에 넣지 말아야 하는 또 다른 이유는 스케일링 때문입니다. 파드는 스케일링의 기본 단위인데, 쿠버네티스는 개별 컨테이너를 수평으로 확장할 수 없습니다. 대신 전체 파드를 수평으로 확장합니다. 만약 프론트엔드와 백엔드 컨테이너로 구성된 파드를 두 개로 늘리면, 결국 프론트엔드 컨테이너 두 개와 백엔드 컨테이너 두 개를 갖습니다.
   
   위에서 설명한 것 처럼 일반적으로 프론트엔드 구성 요소는 백엔드와 완전히 다른 스케일링 요구 사항을 갖고 있어 개별적으로 확장하는 경향이 있습니다. 데이터 베이스와 같은 벡엔드는 (상태를 갖지 않는) 프론트엔드 웹 서버에 비해 확장하기가 훨씬 어렵습니다. 컨테이너를 개별적으로 스케일링하는 것이 필요하다면, 별도 파드에 배포해야 합니다.
   
   
4. 파드에서 여러 컨테이너를 사용하는 경우
   
   보통 하나의 파드에 여러 컨테이너가 들어간다면 그것은 밀접하게 관련되어 있으며, 일반적으로 주 컨테이너와 보조 컨테이너로 이루어 집니다. 이러한 방법은 다양한 시나리오에서 유용할 수 있지만 각 컨테이너의 책임과 리소스 요구 사항을 신중하게 고려해야 합니다.
   
   
   1. 사이드카 패턴
      Pod 내의 여러 컨테이너에 대한 일반적인 사용 사례는 기본 컨테이너가 기본 애플리케이션 로직을 실행하고 사이드카로 알려진 보조 컨테이너가 지원 서비스를 실행하는 사이드카 패턴입니다. 예를 들어 캐싱 및 연결 관리를 처리하는 사이드카 컨테이너를 통해 Redis 데이터베이스와 통신하는 웹 애플리케이션 컨테이너가 있을 수 있습니다.
      
      
   2. 다중 컨테이너 애플리케이션
      Pod 내 다중 컨테이너의 또 다른 사용 사례는 함께 실행해야 하는 여러 구성 요소로 구성된 복잡한 애플리케이션이 있는 경우입니다. 예를 들어 각 마이크로서비스가 단일 Pod 내의 자체 컨테이너에서 실행되는 마이크로서비스 기반 애플리케이션이 있을 수 있습니다.
      
      
   3. 로깅 및 모니터링
      Pod 내의 여러 컨테이너에 대한 또 다른 일반적인 사용 사례는 로깅 및 모니터링입니다. 기본 애플리케이션 논리를 실행하는 기본 컨테이너와 로그 및 메트릭을 수집하여 중앙 모니터링 시스템으로 보내는 보조 컨테이너가 있을 수 있습니다.
      
      
   4. 도우미 컨테이너
      데이터 백업, 구성 관리 또는 주기적인 데이터 처리와 같은 도우미 작업을 위해 Pod 내에서 여러 컨테이너를 사용할 수도 있습니다.
      
      
   5. 주요 컨테이너에 보완 프로세스 추가
      파드 안에 주 컨테이너는 특정 디렉터리에서 파일을 제공하는 웹 서버일 수 있으며, 추가 컨테이너는 외부 소스에서 주기적으로 콘텐츠를 받아 웹 서버의 디렉터리에 저장합니다. 두 컨테이너를 모두에 마운트하는 방법이 있는데, 이에 대해서는 차후에 다뤄보도록 하겠습니다.
      
      * 사이드카 컨테이너가 실제 사용 되는 예를 들어보자면, 로그 로테이터와 수집기, 데이터 프로세서, 통신 어댑터 등이 있습니다.
      
      
5. 파드에서 여러 컨테이너를 사용하는 경우 고려해볼 사항
   
   컨테이너를 파드로 묶어 그룹으로 만들 떄는, 즉 두 개의 컨테이너를 단일 파드로 넣을지 아니면 두 개의 별도 파드에 넣을지를 결정하기 위해서는 다음과 같은 질문에 대해 생각해봐야 할 필요가 있습니다.
   
   
   1. 컨테이너를 함께 실행해야 하는가, 혹은 서로 다른 호스트에서 실행할 수 있는가?
   2. 여러 컨테이너가 모여 하나의 구성 요소를 나타내는가, 혹은 개별적인 구성 요소인가?
   3. 컨테이너가 함께, 혹은 개별적으로 스케일링돼야 하는가?

기본적으로 특정한 이유 때문에 컨테이너를 단일 파드로 구성하는 것을 요구하지 않는다면, 분리된 파드에서 컨테이너를 실행하는 것이 좋습니다.

이번 포스팅은 구분선이 존재하지 않아 글을 읽는데 어려움을 느끼셨을지도 모르겠습니다. 아직 시작한지 얼마 되지 않아 다양한 시도를하고 있고, 해당 내용은 한 가지 내용에 대해 여러 측면을 설명하다 보니 이런 형식을 띄게 되었습니다. 피드백, 욕설, 칭찬 모두 환영합니다. 어떤 의견이든 댓글로 남겨주시면 그에 대해 조사하거나, 조취를 취해보겠습니다. 오늘도 읽어주셔서 감사합니다!

목차

1. pod란?
2. 여러 프로세스를 실행하는 하나의 컨테이너 VS 하나의 프로세스를 실하는 다중 컨테이너
3. 하나의 파드 안에 하나의 컨테이너 사용을 권장하는 이유
4. 파드의 특징
5. 사이드카?

pod란?

Kubernetes 파드는 Kubernetes 개체 모델에서 가장 작고 간단한 배포 가능한 단위입니다. 파드는 동일한 네트워크 네임스페이스와 스토리지 볼륨을 공유하는 하나 이상의 컨테이너를 포함할 수 있는 클러스터에서 실행 중인 프로세스의 단일 인스턴스를 나타냅니다.

쿠버네티스 파드는 항상 두 개 이상의 컨테이너를 포함하지는 않습니다  보통은 파드 하나에 컨테이너 하나가 포함되어 있습니다. 파드는 노드 중 한 곳에서 작동하고 여러 개의 컨테이너를 가질 수 있지만, 반대로 여러 노드에 걸쳐서 작동하는 것은 불가능합니다.

Pod는 설계가 일시적으로 되어있습니다. 즉, 전체 애플리케이션에 영향을 주지 않고 언제든지 생성, 삭제 및 교체할 수 있습니다. 또한 애플리케이션 워크로드의 요구 사항을 충족하기 위해 자동으로 확장 또는 축소할 수 있습니다.

Kubernetes 클러스터의 각 파드에는 고유한 IP 주소가 할당되며 공유 네트워크를 통해 동일한 클러스터의 다른 파드와 통신할 수 있습니다. 이를 통해 파드가 함께 작동하여 응집력 있는 서비스를 제공할 수 있으며 각 파드는 전체 애플리케이션 아키텍처에서 특정 기능을 수행합니다.

Kubernetes 파드는 원하는 파드 상태를 관리하는 선언적 방법을 제공하는 배포라는 상위 수준 객체에 의해 관리됩니다. 이를 통해 다운타임 없이 애플리케이션의 손쉬운 확장, 롤링 업데이트 및 롤백이 가능합니다.

여러 프로세스를 실행하는 하나의 컨테이너 VS 하나의 프로세스를 실하는 다중 컨테이너

컨테이너가 격리된 가상 머신과 비슷한 느낌이라 한 컨테이너에 여러 프로세스를 실행하는 것이 더 효율적이지 않을지 생각할 수 있을 것 같습니다. 하지만 컨테이너는 설계될 당시에 단일 프로세스를 실행하도록 제작되었습니다. 물론 프로세스가 자기 자신의 자식 프로세스를 만드는 경우를 제외한다면 말이죠.

하나의 컨테이너에 여러 프로세스를 작동시킬 경우 어떠한 문제가 발생했을 때 로그를 추적하는 것이 쉽지가 않습니다. 따라서 하나의 컨테이너에는 하나의 프로세스만 작동시키게 된 것이죠. 이외의 사항들은 밑에서 더 자세히 살펴보도록 하겠습니다.

하나의 파드 안에 하나의 컨테이너 사용을 권장하는 이유

단순성, 확장성 및 결함 격리의 핵심 원칙을 중심으로 하는 여러 가지 이유로 인해 Kubernetes에서 파드당 하나의 컨테이너만 보유하는 것이 좋습니다. 이러한 이유는 다음과 같습니다.

1. 단일 책임 원칙
   단일 책임 원칙에 따라 각 파드(Pod)에는 관심사를 명확하게 분리할 수 있는 특정 작업 또는 기능이 있어야 합니다. 단일 파드(Pod)에 기능이 다른 여러 컨테이너가 있는 경우 시스템을 관리하고 유지하기가 더 어려워집니다.
   
   
2. 손쉬운 확장
   Kubernetes에서 확장은 일반적으로 포드 수준에서 수행됩니다. 포드당 하나의 컨테이너가 있으면 애플리케이션의 개별 구성 요소를 독립적으로 확장하기가 더 쉬워집니다. 이는 시스템의 전반적인 확장성과 응답성을 개선하는 데 도움이 됩니다.
   
   
3. 오류 격리
   포드당 단일 컨테이너를 실행하면 오류를 더 잘 격리하고 계단식 오류를 방지할 수 있습니다. 다중 컨테이너 파드(Pod)에서 컨테이너가 실패하면 동일한 파드(Pod)의 다른 컨테이너에 잠재적으로 영향을 미칠 수 있습니다. 단일 컨테이너 포드를 사용하면 장애가 특정 포드로 제한되므로 문제 해결 및 복구가 더 쉬워집니다.
   
   
4. 리소스 관리
   Kubernetes는 CPU, 메모리 및 스토리지 할당을 포함하는 포드 수준에서 리소스 관리를 제공합니다. 포드당 하나의 컨테이너를 사용하면 애플리케이션의 각 구성 요소에 대한 리소스를 개별적으로 효과적으로 관리할 수 있습니다. 이렇게 하면 최적의 리소스 사용이 보장되고 동일한 포드 내의 컨테이너 간 리소스 경합이 방지됩니다.
   
   
5. 간소화된 모니터링 및 로깅
   포드당 단일 컨테이너가 있을 때 모니터링 및 로깅이 더욱 간단해집니다. 이 접근 방식을 사용하면 로그 및 메트릭을 특정 구성 요소와 쉽게 연결하여 문제를 식별하고 성능을 분석하기가 더 쉬워집니다.
   
   
6. 수명 주기 관리
   Pod의 각 컨테이너는 동일한 수명 주기를 공유합니다. 단일 포드에 여러 컨테이너가 있는 경우 개별 컨테이너의 수명 주기를 관리하는 데 문제가 발생할 수 있습니다. 포드당 단일 컨테이너를 실행하면 각 구성 요소의 수명 주기를 개별적으로 관리하기가 쉬워져 필요할 때 원활한 업데이트 및 롤백이 보장됩니다.

사이드카 패턴 또는 밀접하게 결합된 서비스와 같은 다중 컨테이너 포드에 대한 유효한 사용 사례가 있지만 포드당 하나의 컨테이너 권장 사항을 준수하면 Kubernetes 배포에서 단순성, 확장성 및 복원력을 유지하는 데 도움이 됩니다.

파드의 특징

여러 프로세스를 컨테이너 하나로 묶지 않기 때문에, 컨테이너를 함께 묶고 하나의 단위로 관리할 수 있는 또 다른 상위 구조가 필요합니다. 이 때문에 파드가 필요한 것입니다.

컨테이너 모음을 사용해 밀접하게 연관된 프로세스를 함께 실행하고 단일 컨테이너 안에서 모두 함께 실행하고 단일 컨테이너 안에서 모두 함께 실행되는 것처럼 거의 동일한 환경을 제공할 수 있으면서도 이들을 격리된 상태로 유지할 수 있습니다. 이런 방식으로 두 가지의 장점을 모두 활용합니다. 컨테이너가 제공하는 모든 기능을 활용하는 동시에 프로세스가 함께 실행되는 것처럼 보이게 할 수 있습니다.

1. 같은 파드에서 컨테이너 간 부분 격리
   개별 컨테이너가 아닌 컨테이너 그룹으로 생각해 봅시다. 그룹 안에 있는 컨테이너가 특정한 리소스를 공유하기 위해 각 컨테이너가 완벽하게 격리되지 않도록 합니다. 쿠버네티스는 파드 안에 있는 모든 컨테이너가 자체 네임스페이스가 아닌 동일한 리눅스 네임스페이스를 공유하도록 도커를 설정합니다.
   
   파드의 모든 컨테이너는 동일한 네트워크 네임스페이스와 UTS 네임스페이스(UNIX Timesharing System Namespace) 안에서 실행되기 때문에, 모든 컨테이너는 같은 호스트 이름과 네트워크 인터페이스를 공유합니다. 비슷하게 파드의 모든 컨테이너는 동일한 IPC 네임스페이스 아래에서 실행돼 IPC를 통해 서로 통신할 수 있습니다. 최신 쿠버네티스와 도커에서는 동일한 PID 네임스페이스를 공유할 수 있지만, 기본적으로 활성화돼 있지는 않습니다.
   
   그러나 파일시스템에 한해서는 사정이 조금 다릅니다. 대부분의 컨테이너 파일 시스템은 컨테이너 이미지에서 나오기 때문에, 기본적으로 파일 시스템은 다른 컨테이너와 완전히 분리됩니다. 그러나 쿠버네티스의 볼륨 개념을 이용해 컨테이너가 파일 디렉터리를 공유하는 것이 가능합니다.
   
   
2. 컨테이너가 동일한 IP와 포트 공간을 공유
   여기서 중요한 한 가지는 파드 안의 컨테이너가 동일한 네트워크 네임스페이스에서 실행되기 때문에, 동일한 IP 주소와 포트 공간을 공유한다는 것입니다. 이는 동일한 파드 안 컨테이너에서 실행 중인 프로세스가 같은 포트 번호를 사용하지 않도록 주의해야 함을 의미합니다. 그렇지 않으면 포트 충돌이 발생하기 때문입니다.
   
   이는 동일한 파드일 때만 해당되고 다른 파드에 있는 컨테이너는 서로 다른 포트 공간을 갖기 때문에 포트 충돌이 일어나지 않습니다. 파드 안에 있는 모든 컨테이너는 동일한 루프백 네트워크 이너페이스를 갖기 때문에, 컨테이너들이 로컬 호스트를 통해 서로 통신할 수 있습니다.
   
   
3. 파드 간 플랫 네트워크
   쿠버네티스 클러스터의 모든 파드는 하나의 플랫 한 공유 네트워크 주소 공간에 상주하므로 모든 파드는 다른 파드의 IP 주소를 사용해 접근하는 것이 가능합니다. 둘 사이에는 어떠한 NAT도 존재하지 않습니다. 두 파드가 서로 네트워크 패킷을 보내면, 상대방의 실제 IP 주소를 패킷 안에 있는 출발지 IP 주소에서 찾을 수 있습니다.
   
   결과적으로 파드 사이에서 통신은 항상 단순합니다. 두 파드가 동일 혹은 서로 다른 워커 노드에 있는지는 중요하지 않으며, 두 경우 모두 파드 안에 있는 컨테이너는 NAT 없는 플랫 네트워크를 통해 서로 통신하는 것이 가능합니다. 이것은 실제 노드 간 네트워크 토폴로지에 관계없이, 근거리 네트워크(LAN)에 있는 컴퓨터 간의 통신과 비슷합니다. LAN상에 있는 컴퓨터처럼 각 파드는 고유 IP를 가지며 모든 다른 파드에서 이 네트워크를 통해 접속할 수 있습니다. 이는 일반적으로 물리 네트워크 위에 추가적인 소프트 웨어 정의 네트워크 계층을 통해 달성됩니다.

사이드카?

사이드카는 보조 컨테이너가 동일한 포드 내에서 기본 컨테이너와 함께 실행되는 디자인 패턴을 나타냅니다. 사이드카 컨테이너는 기본 컨테이너의 핵심 기능을 변경하지 않고 추가 기능 또는 지원을 제공하여 기본 컨테이너를 보완합니다. 이 패턴은 관심사를 분리하고 애플리케이션의 모듈성을 향상시킵니다.

사이드카 컨테이너의 일반적인 사용 사례는 다음과 같습니다.

1. 로그 관리
   사이드카 컨테이너는 로그 집계, 처리 및 중앙 로깅 서비스로의 전달을 담당할 수 있습니다. 이렇게 하면 기본 컨테이너가 로그 관리에 대한 걱정 없이 핵심 기능에 집중할 수 있습니다.
   
   
2. 모니터링
   사이드카 컨테이너는 기본 컨테이너에서 애플리케이션별 메트릭을 수집하고 이를 Prometheus와 같은 모니터링 시스템에 노출할 수 있습니다. 이는 애플리케이션 논리에서 모니터링 작업을 분리하는 데 도움이 됩니다.
   
   
3. 프록시
   사이드카 컨테이너는 기본 컨테이너에 대한 수신 또는 발신 네트워크 트래픽을 처리하는 프록시 역할을 할 수 있습니다. 예를 들어 사이드카는 트래픽 라우팅, 부하 분산 및 보안 정책과 같은 서비스 메시 기능을 구현할 수 있습니다.
   
   
4. 보안
   사이드카 컨테이너를 사용하여 보안 정책을 시행하거나 비밀 및 자격 증명을 관리하여 중요한 데이터를 기본 컨테이너와 분리할 수 있습니다.

사이드카 패턴은 파드(Pod)에 둘 이상의 컨테이너를 포함하지만 사이드카 컨테이너가 기본 컨테이너와 밀접하게 결합되어 해당 기능을 직접 지원하기 때문에 파드당 하나의 컨테이너를 권장하는 사항에 대해 예외입니다.

목차

1. Docker의 단점
2. Kubernetes 시작
3. Kubernetes란?
4. Kubernetes 구성
5. Kubernetes 핵심 기능
6. 마치며

Docker의 단점

이전에 우리는 Docker를 사용하기까지 과정과 Docker에 대해서 알아보았습니다. 하지만 그렇게 유용한 Docker도 점점 시스템에 배포 가능한 애플리케이션 구성 요소의 수가 많아짐에 따라 모든 구성 요소의 관리가 더욱 어려워졌고, 이로 인해 수천 개의 소프트웨어 구성 요소를 관리하고 비용 효율적으로 개발, 배포할 수 있는 솔루션을 개발해야만 했습니다. 다음은 해당 내용 외에 Docker의 단점을 조금 모아보았습니다.

1. 학습 곡선
   Docker는 컨테이너화 및 DevOps 관행에 익숙하지 않은 사람들을 위해 가파른 학습 곡선을 가질 수 있습니다.
   
   
2. 보안
   컨테이너는 호스트 운영 체제의 커널을 공유합니다. 즉, 하나의 컨테이너가 손상되면 동일한 호스트의 다른 컨테이너도 취약해질 수 있습니다.
   
   
3. 리소스 오버헤드
   실행 중인 컨테이너는 호스트 시스템의 성능에 영향을 미칠 수 있는 상당한 양의 리소스를 소비할 수 있습니다.
   
   
4. 복잡성
   Docker는 애플리케이션의 패키징 및 배포를 단순화하지만 특히 대규모 환경에서 전체 시스템 아키텍처에 복잡성을 추가할 수 있습니다.
   
   
5. 무분별한 이미지 확산
   도커 이미지는 빠르게 축적되어 관리하기 어려워져 "이미지 무분별한 확산"이라는 현상이 발생합니다.
   
   
6. 제한된 이식성
   Docker 컨테이너는 여러 운영 체제 간에 이식 가능하지만 시스템 아키텍처 및 커널 버전의 차이로 인해 이식성에 여전히 몇 가지 제한이 있습니다.
   
   
7. 볼륨 관리
   Docker 컨테이너에서 영구 데이터를 관리하는 것은 어려울 수 있습니다. 컨테이너를 삭제하거나 다시 빌드할 때 데이터가 손실되지 않도록 컨테이너 외부에 데이터를 저장해야 하기 때문입니다.

Kubernetes 시작

오랫 동안 구글은 보그(Borg)라는 내부 시스템을 개발해 애플리케이션 개발자와 시스템 관리자가 수천 개의 애플리케이션과 서비스를 관리하는 데 도움을 줬습니다. 개발과 관리를 단순화할 뿐 아니라 인프라 활용률을 크게 높일 수 있었는데, 이는 조직이 그만큼 클 때 중요해집니다. 사용률이 조금만 올라도 수백만 달러가 절약되므로 이런 시스템의 필요성을 충분했습니다.

이후 구글은 10년 가량 보그와 오메가를 비밀로 유지하다 2014년 보그, 오메가, 기타 내부 구글 시스템을 경험을 바탕으로 오픈 소스 시스템인 쿠버네티스를 출시했습니다.

Kubernetes란?

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 설계된 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. 원래 Google에서 개발했으며 현재 CNCF(Cloud Native Computing Foundation)에서 관리하고 있습니다.

일반적으로 "K8s"라고 하는 Kubernetes는 분산 시스템의 원칙을 기반으로 하며 여러 호스트에서 컨테이너화된 워크로드를 관리하는 데 사용되어 자동 확장, 자가 복구 및 로드 밸런싱을 제공합니다. 이를 통해 개발자는 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있으므로 클라우드 네이티브 애플리케이션을 구축하고 배포하는 데 널리 사용됩니다.

Kubernetes는 단일 컴퓨팅 리소스를 형성하기 위해 함께 그룹화되는 물리적 또는 가상 머신일 수 있는 노드의 클러스터를 생성하여 작동합니다. 이러한 노드는 노드에 대한 컨테이너 예약 및 배포, 상태 모니터링, 확장 및 로드 밸런싱 관리를 담당하는 컨트롤 플레인에서 관리합니다.

Kubernetes의 주요 기능 중 하나는 자동 확장 및 자가 복구를 포함하여 컨테이너화된 애플리케이션의 관리를 자동화하는 기능입니다. 즉, 컨테이너가 실패하거나 종료되면 Kubernetes는 애플리케이션이 계속해서 원활하게 실행되도록 다른 노드에서 컨테이너를 자동으로 다시 시작합니다.

또한 Kubernetes는 개발자가 고도로 확장 가능하고 유연한 방식으로 애플리케이션을 관리할 수 있도록 하는 풍부한 API 및 도구 세트를 제공합니다. 여기에는 업데이트 롤링, 버전 관리 및 업데이트 롤백을 위한 도구와 서비스 검색, 로드 밸런싱 및 스토리지에 대한 기본 제공 지원이 포함됩니다.

* 참고로 K8s는 K ubernete s. 즉, K와 s 사이에 8개의 알파벳이 있어서 이렇게 표현합니다.

Kubernetes 구성

가장 간단한 구성으로는 하나의 마스터 노드와 여러 워커 노드로 구성됩니다. 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커 노드 클러스터에 배포합니다. 구성 요소가 어떤 노드에 배포되는지는 개발자나 시스템 관리자에게 중요하지 않습니다. 따로 설정하지 않아도, 현재 가장 적은 양을 가지고 있는 노드로 자동으로 분배가 되기 때문이죠.

개발자는 특정 애플리케이션이 함께 실행되도록 지정할 수 있고 쿠버네티스는 여러 애플리케이션을 동일한 워커 노드에 배포합니다. 다른 애플리케이션은 클러스터에 걸쳐서 분산되지만 배포된 위치에 상관없이 동일한 방식으로 서로 통신할 수 있습니다.

Kubernetes 핵심 기능

1. 개발자가 애플리케이션 핵심 기능에 집중할 수 있도록 해줍니다.
   쿠버네티스는 클러스터의 운영체제로 생각할 수 있지만 애플리케이션 개발자가 특정 인프라 관련 서비스를 애플리케이션에 구현하지 않아도 됩니다. 대신 쿠버네티스에 의존해 이런 서비스를 제공하고 있습니다. 여기에는 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더 선출 같은 것들이 포함됩니다. 따라서 애플리케이션 개발자는 애플리케이션의 실제 기능을 구현하는 데 집중할 수 있으며 애플리케이션을 인프라와 통합하는 방법을 찾는 데 시간을 낭비하지 않아도 됩니다.
   
   
2. 운영 팀이 효과적으로 리소스를 활용할 수 있도록 해줍니다.
   쿠버네티스는 클러스터 어딘가에 컨테이너화된 애플리케이션을 실행하고 구성 요소 간에 서로를 찾는 방법에관한 정보를 제공하고 모든 애플리케이션을 계속 실행하게 합니다. 애플리케이션은 어떤 노드에서 실행되든 상관이 없기 때문에 쿠버네티스는 언제든지 애플리케이션을 재배치하고 애플리케이션을 조합함으로써 리소스를 수동 스케줄링보다 훨씬 더 잘 활용할 수 있습니다.

여기까지 컨테이너의 전후를 알아보았고, 간단하게(?) 도커와 쿠버네티스에 대해서도 알아보았습니다. 이제 도커 실습과 명령어 정리, 쿠버네티스의 더 깊은 이론과 기능들은 각각 카테고리에서 다룰 예정입니다.

근 1달 조금 넘는 기간동안 에티버스 러닝에서 하이브리드 클라우드 교육을 받으면서 "내가 정말 클라우드를 할 수 있을까?" 싶은 생각이 정말 많이 들었습니다. 어렵기도 어렵거니와 각 배운 내용이 어디에 사용되는지 또, 이제야 클라우드의 테두리에 발을 디뎠기 때문에 저번주까지만 해도 클라우드가 감조차 오지 않았었죠.

그런데 이번주부터 배우는 컨테이너 시스템부터 뭔가 클라우드의 테두리가 그려지는 느낌입니다. 뭔가 가슴속 응어리가 조금씩 풀어지는 듯한 느낌이라 기분이 좋습니다. 뭐든 꾸준히 하면 점차 빛을 본다는 게 완전히 틀린 말은 아닌가 봅니다.

블로그를 계속 작성하고 있지만 애드센스가 떨어져 변화를 주고 있는데, 이번 컨테이너 시리즈 제목이 굉장히 만족스럽습니다. 포스팅 200개에 다달아가며 이 작명 센스도 늘어나나 봅니다. 이것을 읽는 독자분들은 어떤지 잘 모르겠지만요. 이번주는 전환점이 되는 포인트인 듯한 느낌입니다. 이번 마무리도 역시 모든 독자분들, IT 업계 종사자들 모두 화이팅입니다. 감사합니다.

p.s 최근 알아야할 정보의 양이 늘어나며 실습이 아닌 이론 위주의 포스팅이 되고 있습니다. 이 부분은 정말 죄송하게 생각하고 있고, 학습이 마무리되고 프로젝트로 넘어가면 실습 위주 포스팅이 가능할 듯합니다. 더 양질의 정보를 제공할 수 있도록 노력하겠습니다. 다시 한번 감사합니다.

목차

1. Docker란?
2. Docker 개념
3. 개발자가 Docker를 사용하는 과정
4. Docker 이미지 레이어
5. 컨테이너의 한계
6. 마치며

Docker란?

Docker는 2013년에 처음 등장한 컨테이너 기반 가상화 도구입니다. 이를 통해 컨테이너를 쉽게 관리하고 이미지를 생성하여 외부 서버에 배포할 수 있습니다. Docker는 애플리케이션을 빠르게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼입니다. Linux 컨테이너를 생성하고 사용할 수 있게 해주는 컨테이너화 기술입니다. Docker를 사용하면 가상 머신과 같은 독립적인 실행 환경을 만들 수 있지만 실제로 운영 체제를 설치하지 않고도 설치 크기가 작아지고 실행 속도가 빨라집니다.

Docker는 Docker 엔진, Dockerfile 및 Docker 허브를 비롯한 다양한 구성 요소로 구성됩니다. Docker 엔진은 컨테이너를 구축, 실행 및 관리할 수 있게 해주는 핵심 구성 요소입니다. Dockerfile은 Docker 이미지 생성을 자동화하는 스크립트입니다. Docker 허브는 Docker 이미지용 리포지토리로, 미리 빌드된 이미지를 찾거나 자신의 이미지를 업로드하여 다른 사람과 공유할 수 있습니다.

Docker의 주요 이점 중 하나는 응용 프로그램 및 서비스를 쉽게 생성, 관리 및 배포할 수 있습니다는 것입니다. Docker를 사용하면 종속성 및 구성을 포함하여 애플리케이션을 실행하는 데 필요한 모든 것이 포함된 이미지를 만든 다음 Docker가 설치된 모든 서버에 배포할 수 있습니다. Docker 컨테이너는 이식 가능합니다. 즉, 기본 운영 체제나 하드웨어에 관계없이 모든 시스템에서 동일한 컨테이너를 실행할 수 있습니다.

Docker 개념

Docker는 애플리케이션을 패키징, 배포, 실행하기 위한 플랫폼입니다. 애플리케이션을 전체 환경과 함께 패키지화할 수 있습니다. 애플리케이션에서 필요한 몇 가지 라이브러리나 운영체제의 파일 시스템에 설치되는 모든 파일을 포함시킬 수 있습니다. Docker를 사용하면 이 패키지를 중앙 저장소로 전송할 수 있으며, Docker를 실행하는 모든 컴퓨터에 전송할 수 있습니다.

Docker의 주요 3가지 개념은 다음과 같습니다.

1. 이미지
   애플리케이션과 해당 환경을 패키지화한 것 입니다. 여기에는 애플리케이션에서 사용할 수 있는 파일 시스템과 이미지가 실행될 때 실행될 때 실행돼야 하는 실행파일 경로와 같은 메타데이터가 포함돼 있습니다.
   
   
2. 레지스트리
   Docker 이미지를 저장하고 다른 사람이나 컴퓨터 간에 해당 이미지를 쉽게 공유할 수 있는 저장소입니다. 이미지를 빌드할 때 빌드하는 컴퓨터에서 이미지를 실행하거나 이미지를 레지스트리로 푸시(업로드)한 다음 다른 컴퓨터에서 이미지를 풀(다운로드)할 수 있습니다. 일부 공개 레지스트리는 누구나 이미지를 가져올 수 있으며, 비공개 레지스트리는 특정 살마이나 컴퓨터만 액세스할 수 있습니다.
   
   
3. 컨테이너
   Docker 기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너입니다. 실행중인 컨테이너는 Docker를 실행하는 호스트에서 실행되는 프로세스이지만 호스트와 호스트에서 실행 중인 다른 프로세스와 완전히 격리돼 있습니다. 또 프로세스는 리소스 사용이 제한돼 있으므로 할당된 리소스의 양(GPU, RAM 등)만 사용할 수 있습니다.

개발자가 Docker를 사용하는 과정

Docker 이미지 레이어

Docker 이미지는 이미지 인스턴스를 실행하는 컨테이너의 청사진과 같습니다. 이미지는 서로 위에 쌓인 여러 레이어로 구성되며 각 레이어는 이미지의 다른 부분을 나타냅니다.

케이크처럼 생각하세요. 케이크의 각 층은 다른 재료 또는 구성 요소이며 모두 함께 쌓으면 완전한 케이크가 됩니다. 마찬가지로 Docker 이미지의 각 계층은 이미지에 추가되는 서로 다른 지침 집합을 나타냅니다.

이미지를 기반으로 컨테이너를 실행할 때 Docker는 최상위 계층 아래의 모든 계층에 대해 읽기 전용 파일 시스템을 사용합니다. 최상위 계층은 변경을 허용하는 유일한 계층이므로 컨테이너가 실행되는 동안 변경된 사항은 해당 최상위 계층에 기록됩니다.

이 계층 구조는 Docker 이미지를 효율적으로 만듭니다. 일부 계층이 로컬에 이미 캐시되어 있는 경우 Docker가 매번 처음부터 시작하는 대신 해당 계층을 재사용하여 새 이미지를 빌드할 수 있기 때문입니다. 즉, 더 적은 디스크 공간으로 더 빠르게 이미지를 구축하고 배포할 수 있습니다.

컨테이너의 한계

"컨테이너 이미지의 제한된 이식성" 이라고 표현하는 이 유형은 시스템 또는 플랫폼용으로 생성된 이미지가 다른 유형의 시스템 또는 플랫폼에서 제대로 작동하지 않을 수 있다는 사실을 나타냅니다. 이는 운영 체제 또는 아키텍처와 같은 기본 인프라의 차이 때문입니다.

예를 들어 Linux 기반 시스템용으로 생성된 이미지는 Windows 기반 시스템에서 제대로 작동하지 않을 수 있습니다. 이러한 제한된 이식성은 다른 환경 또는 클라우드 플랫폼 간에 컨테이너화된 애플리케이션을 이동하기 어렵게 만들 수 있으며 다른 시스템 간의 호환성을 보장하기 위해 추가적인 노력이 필요할 수 있습니다.

그러나 컨테이너화는 기존의 모놀리식 애플리케이션에 비해 여전히 더 높은 수준의 이식성을 제공합니다. 종속성 및 런타임 환경이 이미지 자체 내에 패키징되어 다양한 호스트 및 환경 간에 애플리케이션을 더 쉽게 이동할 수 있기 때문입니다.

이러한 특징을 가지고 있는 Docker는 점점 사용량이 많아지면서, 보안, 복잡성 등 여러 문제에 직면하게 되었습니다. 이에 따라 이 문제들을 해결할 수단을 개발하게 되는데 그것이 바로 "쿠버네티스"입니다. 다음 시간에는 도커의 문제점과 쿠버네티스에 대해 알아보도록 하겠습니다. 오늘도 읽어주신 모든 여러분들께 감사합니다.

목차

1. 컨테이너 도입 계기
2. 컨테이너 격리 기술의 원리
3. 컨테이너와 가상화 머신 각각의 특징
4. 컨테이너를 다루는 시스템

컨테이너 도입 계기

애플리케이션이 적은 수의 커다란 구성 요소로만 이뤄졌을 때에는 각 구성 요소에 전용 가상 머신을 제공하고 고유한 운영체제 인스턴스를 제공해 환경을 격리할 수 있었습니다. 하지만 이런 구성 요소가 점점 작아지고 숫자가 만하지기 시작하면서 하드웨어 리소스를 낭비하지 않으면서 비용을 줄일 수 있는 방안을 찾아야 했고, 비용을 줄이기 위해 각 구성 요소마다 가상 머신 없이 제공하기 시작했습니다.

이것은 리소스 낭비를 줄이는 것 뿐만 아니라 각각의 가상 머신을 개별적으로 구성하고 관리하는 시스템 관리자의 작업량을 줄이고 이에 따라 인적 자원 낭비도 막을 수 있었습니다.

컨테이너 격리 기술의 원리

1. 리눅스 네임스페이스(namespace)
   기본적으로 각 리눅스 시스템은 초기 구동 시 하나의 네임스페이스가 있습니다. 파일 시스템, 프로세스 ID, 사용자 ID, 네트워크 인터페이스 등과 같은 모든 시스템 리소스는 하나의 네임스페이스에 속합니다. 또 네임스페이스는 기본 네임스페이스에만 국한되지 않고 추가 네임스페이스를 생성하고 리소스를 구성할 수 있습니다.
   
   프로세스를 실행할 때 해당 네임스페이스 중 하나에서 프로세스를 실행합니다. 프로세스는 동일한 네임스페이스 내에 있는 리소스만 볼 수 있는데, 여러 종류의 네임스페이스가 있기 때문에 프로세스는 하나의 네임스페이스에만 속하는 것이 아닌 여러 네임스페이스에 속할 수 있습니다.
   
   네임스페이스의 종류는 다음과 같습니다. 하지만 이뿐 아니라 다른 네임 스페이스들도 있다는 것을 명심해야 합니다.
   1. 마운트(mnt)
   2. 프로세스 ID(pid)
   3. 네트워크(net)
   4. 프로세스 간 통신(ipc)
   5. 호스트와 도메인 이름(uts)
   6. 사용자 ID(user)
   우리가 앞으로 배울 쿠버네티스에서 네임스페이스를 사용하면, 같은 이름의 Service를 다른 네임스페이스에서 사용할 수 있으므로, 개발, 스테이징, 프로덕션 등 여러 개발 환경에서 동일한 구성을 사용할 수 있습니다.
   
   
2. 프로세스 가용 리소스 제한
   컨테이너가 사용할 수 있는 시스템 리소스의 양을 제한하는 것은 리눅스 커널 기능인 cgroups로 이루어집니다. 이를 통해 프로세스는 설정된 양 이상의 CPU, 메모리, 네트워크 대역폭 등을 사용할 수 없습니다. 이런 방식으로 프로세스는 다른 프로세스용으로 예약된 리소스를 사용할 수 없으며, 이는 각 프로세스가 별도의 시스템에서 실행될 때와 비슷합니다.

컨테이너와 가상화 머신 각각의 특징

• 가상 머신(VM)
  
  
  1. VM은 프로세서, 메모리, 스토리지 및 네트워크 리소스를 포함한 전체 하드웨어 스택을 가상화합니다.
  2. 각 VM은 호스트 OS와 다를 수 있는 자체 전체 운영 체제(OS)를 실행합니다.
  3. VM은 서로 격리되어 있어 강력한 보안 및 장애 격리를 제공합니다.
  4. VM은 전체 OS가 필요하기 때문에 컨테이너에 비해 오버헤드가 높아 크기가 커지고 시작 시간이 느려집니다.
  5. VM은 가상 하드웨어를 관리하고 VM에 리소스를 할당하는 소프트웨어 계층인 하이퍼바이저에 의해 관리됩니다.
  6. VM은 완전한 OS 격리가 필요한 애플리케이션이나 OS 요구 사항이 다른 애플리케이션을 실행하는 데 더 적합합니다.
     
     
• 컨테이너
  
  
  1. 컨테이너는 OS를 가상화하여 호스트와 동일한 OS 커널을 공유하지만 네임스페이스라고 하는 격리된 환경에서 실행됩니다.
  2. 컨테이너에는 전체 OS가 필요하지 않으므로 VM에 비해 크기가 작고 시작 시간이 더 빠릅니다.
  3. 컨테이너는 프로세스 수준에서 서로 격리되어 일정 수준의 보안 및 결함 격리를 제공하지만 VM만큼 강력하지는 않습니다.
  4. 컨테이너는 호스트 OS 커널을 공유하고 필요한 애플리케이션 종속성만 포함하므로 VM에 비해 오버헤드가 낮습니다.
  5. 컨테이너는 컨테이너 인스턴스 생성, 실행 및 관리를 담당하는 Docker 또는 containerd와 같은 컨테이너 런타임에 의해 관리됩니다.
  6. 컨테이너는 배포에 더 적합합니다.

이 중 큰 차이점은 애플리케이션이 CPU를 사용할 때 VM은 하이퍼바이저를 거쳐, 가상 CPU를 거쳐, 커널을 거치고, 애플리케이션으로 이동하는 단계를 거치지만, 컨테이너는 커널에서 바로 애플리케이션으로 연결됨으로 엄청난 속도, 용량에서 차이가 납니다.

컨테이너를 다루는 시스템

컨테이너 기술은 오랫동안 사용돼 왔는데, 도커 컨테이너 플랫폼의 등장으로 더 널리 알려지게 되었습니다. 도커는 컨테이너를 여러 시스템에 쉽게 이식이 가능하게 만들어준 최초의 컨테이너 시스템입니다. 단순화에는 성공했지만, 한번에 하나씩만 생성 가능한 등 몇몇 단점으로 인해 자동화와 편리성을 증가시켜 개발된 것이 쿠버네티스입니다. 이 2가지는 다음 포스팅에서 더 자세하게 다루어 보도록 하겠습니다.

쉽게 이야기하자면 처음 컨테이너를 쉽게 이용할 수 있도록 만들어준 시스템이 "Docker", 이 Docker를 더 편하게 다룰 수 있도록 만들어준 것이 "Kubernetes"이다. 쿠버네티스는 맨 앞 K와 맨 끝 s 사이에 8개 알파벳이 들어가 "k8s"라고도 합니다.