Introduction to Containers and Kubernetes

기본 배포 방식 vs 가상화

기본 배포 방식

1. 애플리케이션을 배포하는 기본 방식은 실제 컴퓨터에 배포하는 것이었다.
2. 앱을 설치하려면 물리적 공간, 전원 냉각 장치, 네트워크 연결을 준비한 후 운영체제를 깔고 소프트웨어 종속 항목을 먼저 설치해야 한다.

기본 배포 방식의 문제점

1. 리소스 낭비가 크고 대규모 배포와 유지보수에 많은 시간이 소요된다.
2. 이동하기가 매우 어렵다.
3. 애플리케이션은 특정 운영체제에 맞게 빌드되었고 특정 하드웨어에 맞춰 빌드되는 경우도 있다.

가상화 이점

1. 가상화를 통해 여러 가상 서버와 운영체제를 동일한 물리적 컴퓨터에서 실행할 수 있다.
2. 하이퍼바이저는 소프트웨어 레이어로서 기본 하드웨어에서 운영체제의 종속성을 해소하여 여러 가상 머신이 하드웨어 하나를 공유할 수 있다.
3. 새 서버를 빠르게 배포할 수 있습니다.
4. 새 솔루션 배포 시간이 짧아집니다.
5. 가상 머신은 이미지를 만들어 이동할 수 있기 때문에 사용하는 물리적 컴퓨터의 리소스 낭비가 줄어들고 이동성이 향상된다.

VM의 문제점

1. 애플리케이션, 모든 종속 항목과 운영체제는 여전히 번들로 묶여 있습니다.
2. VM을 하이퍼바이저 제품 간에 이동하는 것은 쉽지 않다.
3. VM을 시작할 때마다 운영체제를 부팅하는 시간이 소요됩니다.
4. 단일 VM에서 여러 애플리케이션을 실행 시 문제점
   1. 종속 항목을 공유하는 애플리케이션이 서로 격리되지 않는 문제가 있다.
   2. 특정 애플리케이션의 리소스 요구사항 때문에 다른 애플리케이션에서 필요한 리소스를 확보하지 못할 수 있다.
   3. 특정 애플리케이션의 종속 항목 업그레이드로 인해 다른 애플리케이션이 실행 중지될 수 있습니다.
5. 위와 같은 문제를 엄격한 소프트웨어 엔지니어링 정책으로 문제 해결을 할 수 있다.
   1. 종속 항목은 종종 업그레이드가 필요하다.
   2. 애플리케이션 작동을 확인하는 통합 테스트를 추가할 수 있다.
   3. 종속 항목 문제가 새 장애를 일으키고 해결이 어려울 수도 있다.
   4. 애플리케이션 환경의 기본 무결성을 확인하기 위해 통합 테스트를 이용해야 하는 경우 개발 속도가 크게 저하된다.
6. 종속 항목을 잠그고 어느 애플리케이션에서도 이를 변경할 수 없도록 할 수 있지만 새 문제가 생깁니다.

VM 중심으로 이 문제를 해결하는 방법

1. 애플리케이션마다 전용 가상 머신을 실행하는 것 수십만 개 애플리케이션으로 확장하면 문제가 발생한다.
   1. 대규모 시스템의 경우 전용 VM은 중복적이며 낭비입니다.
   2. 전체 운영체제를 부팅해야 하기 때문에 VM은 시작하는 속도가 비교적 느리다.
2. 각 애플리케이션에서 고유 종속 항목을 유지 관리하고 커널이 격리되어 있으므로 애플리케이션끼리 성능에 영향을 미치지 않습니다.
3. 종속 항목 문제를 더 효율적으로 해결하려면 애플리케이션과 종속 항목 수준에서 추상화를 구현한다.
4. 전체 머신 또는 전체 운영체제가 아니라 사용자 공간만 가상화하면 됩니다.

컨테이너란?

• 사용자 공간은 커널 위에 있는 모든 코드이며 애플리케이션과 종속 항목을 포함합니다. 이것이 컨테이너를 만든다는 의미이다.
• 컨테이너는 단일 애플리케이션 코드를 실행하는 격리된 사용자 공간이다.

컨테이너의 장점

1. 운영체제 전체를 실행하지 않으므로 가볍다.
2. 기본 시스템 위에서 예약하고 패키징 하므로 매우 효율적이다.
3. 컨테이너는 아주 빠르게 만들고 종료할 수 있다.
4. 애플리케이션을 구성하는 프로세스만 시작 또는 중지하고 전체 VM을 부팅하거나 각 애플리케이션의 운영체제를 초기화하지 않기 때문입니다.
5. 시스템의 나머지는 신경 쓰지 않아도 된다.
   1. VM에서 최종 코드를 실행할 때 소프트웨어 종속 항목 즉 애플리케이션 런타임, 시스템 도구 시스템 라이브러리, 기타 설정에 신경 쓰지 않아도 됩니다
6. 가볍고 독립적이고 리소스 효율이 높으며 이동성이 우수한 실행 패키지이다.

개발자 관점 컨테이너 이점

1. 애플리케이션 중심으로 확장성 높은 고성능 애플리케이션을 제공하기 때문이다.
2. 컨테이너를 사용하면 개발자가 기본 하드웨어와 소프트웨어를 전제로 작업할 수 있다.
3. 모든 환경에서 동일한 컨테이너가 동일하게 실행된다.
4. 개발 프로세스가 빨라진다.
   1. 프로덕션 이미지를 기반으로 컨테이너를 점진적으로 변경하고 파일 복사 한 번으로 이를 빠르게 배포할 수 있습니다.
5. 컨테이너는 애플리케이션을 쉽게 빌드할 수 있다.
   1. 애플리케이션은 마이크로 서비스 설계 패턴 즉, 느슨하게 결합되고 세분화된 구성요소를 사용합니다.
   2. 이 모듈식 설계 패턴은 운영체제를 확장하고 애플리케이션의 구성요소를 업그레이드하면서도 전체 애플리케이션에는 영향을 주지 않습니다

컨테이너 설명

애플리케이션과 종속 항목을 '이미지'라고 합니다. 간단히 말해 컨테이너는 실행 중인 이미지 인스턴스입니다.

1. 컨테이너는 Linux 네임스페이스를 사용하여 애플리케이션에 제공할 항목인 프로세스 ID 번호, 디렉터리 트리, IP 주소 등을 제어합니다.
2. 컨테이너는 Linux cgroup으로 애플리케이션이 사용할 수 있는 CPU 시간, 메모리, I/O 대역폭 기타 리소스의 최대 사용량을 제어합니다.
3. 컨테이너는 유니온 파일 시스템을 사용하여 애플리케이션과 종속 항목을 간결한 최소 레이어 모음으로 효율적으로 캡슐화합니다.
4. 컨테이너 이미지는 여러 레이어로 구조화됩니다.

컨테이너 빌드

• 이미지 빌드에 사용하는 도구는 '컨테이너 매니페스트'라는 파일에서 안내를 읽어옵니다.
• Docker 형식의 컨테이너 이미지의 경우 이를 Dockerfile이라고 합니다.
• Dockerfile의 안내에 따라 컨테이너 이미지 내부 레이어가 지정됩니다. 각 레이어는 읽기 전용입니다. 이 이미지에서 컨테이너를 실행하는 경우 쓰기 가능한 임시 최상위 레이어도 생성됩니다.
• Dockerfile의 명령어 4개는 각각 하나의 레이어를 생성합니다.

Dockerfile 명령어

• FROM 문으로 기본 레이어를 공개 저장소에서 가져와 생성합니다.
• COPY 명령어로 새 레이어를 추가한다.
• RUN 명령어는 make 명령어를 사용하여 애플리케이션을 빌드하고 빌드 결과를 세 번째 레이어에 배치합니다.
• 마지막 레이어는 실행 시 컨테이너 내에 실행할 명령어를 지정합니다.
• Dockerfile을 작성할 때는 변경할 가능성이 가장 낮은 레이어에서 변경할 가능성이 가장 높은 레이어로 구성해야 합니다.
• 요즘은 배포 및 실행하는 컨테이너에 애플리케이션을 빌드하는 것은 권장하지 않습니다.
• 요즘은 애플리케이션 패키징에 다단계 빌드 프로세스를 이용하는데 이 경우 한 컨테이너에서 최종 실행 가능한 이미지를 빌드하고 다른 컨테이너에는 애플리케이션 실행에 필요한 항목만 포함합니다.

컨테이너 레이어

• 이미지에서 새 컨테이너를 만들면 컨테이너 런타임에서는 쓰기 가능한 레이어를 기본 레이어 위에 추가합니다. 이 레이어를 보통 '컨테이너 레이어'라고 합니다.
• 실행 중인 컨테이너에 대한 새 파일 쓰기, 기존 파일 수정 및 파일 삭제와 같은 모든 변경사항은 쓰기 가능하고 얇은 컨테이너 레이어에 기록됩니다. 각 컨테이너에는 쓰기 가능한 고유의 컨테이너 레이어가 있고 모든 변경사항이 이 레이어에 저장되므로 여러 컨테이너가 동일한 기본 이미지에 액세스 권한을 공유하면서도 자체 데이터 상태를 보유합니다.
• 이는 모두 임시 변경사항이므로 컨테이너가 삭제되면 이 레이어의 내용도 영구 삭제됩니다. 기본 컨테이너 이미지 자체는 변경되지 않은 상태로 유지됩니다. 애플리케이션을 설계할 때 이러한 컨테이너의 특징을 고려해야 합니다. 데이터를 영구적으로 저장하고 싶다면 실행 중인 컨테이너 이미지가 아닌 다른 곳에서 작업해야 합니다.
• 컨테이너를 실행하면 컨테이너 런타임에서 필요한 레이어를 가져옵니다. 업데이트할 때는 차이가 나는 항목만 복사하면 됩니다. 이렇게 하면 새 가상 머신을 실행하는 것보다 훨씬 빠릅니다.

Kubernetes란?

1. Kubernetes는 오픈소스 플랫폼으로서 컨테이너 인프라를 온프레미스 또는 클라우드에서 조정, 관리할 수 있습니다.
2. Kubernetes는 컨테이너 중심의 관리 환경이다.
3. Kubernetes는 컨테이너화 된 애플리케이션의 배포, 확장, 부하 분산, 로깅, 모니터링, 기타 관리 기능을 자동화합니다. 이러한 기능은 전형적인 Platform as a Service 솔루션 특징입니다.
4. Kubernetes는 Infrastructure as a Service 기능도 지원합니다. 예를 들어 다양한 사용자 환경설정과 구성 유연성을 지원합니다.
5. Kubernetes는 선언적 구성을 지원합니다 인프라를 선언적으로 관리하는 경우 일련의 명령어를 실행하는 게 아니라 달성하려는 상태를 설명하여 원하는 상태를 달성합니다.
6. Kubernetes는 배포된 시스템을 원하는 상태로 만들고 장애가 발생해도 상태를 유지합니다. 선언적 구성은 작업 부담을 덜어줍니다. 원하는 시스템 상태가 항상 문서화되어 있기 때문에 오류의 위험도 줄어듭니다.
7. Kubernetes는 명령형 구성도 지원하며 이 경우 명령어를 실행하여 시스템 상태를 변경합니다.
8. Kubernetes의 주요 장점 중 하나가 선언한 시스템 상태를 자동으로 유지할 수 있다는 점입니다.

Kubernetes의 기능

1. Kubernetes는 다양한 워크로드 유형을 지원합니다. Nginx, Apache 웹 서버 같은 스테이트리스(Stateless) 애플리케이션과 사용자 및 세션 데이터를 영구 저장할 수 있는 스테이트풀(Stateful) 애플리케이션을 지원하고 일괄 작업 및 데몬 태스크도 지원합니다.
2. Kubernetes는 리소스 사용률에 따라 컨테이너화 된 애플리케이션을 자동으로 수평 확장 및 축소할 수 있습니다.
3. 워크로드의 리소스 요청 수준과 리소스 한도를 지정하면 Kubernetes가 그대로 준수합니다.
4. Kubernetes는 이처럼 리소스를 제어하여 클러스터 내의 전반적인 워크로드 성능을 개선합니다.
5. 개발자는 Kubernetes를 통해 플러그인, 부가기능을 확장할 수 있습니다.
6. Kubernetes 선언적 관리 모델을 관리가 필요한 매우 다양한 다른 작업에 적용하고 있습니다.
7. Kubernetes는 오픈소스이므로 온프레미스 또는 GCP를 비롯한 여러 클라우드 서비스 제공업체 간 워크로드 이동성도 지원합니다.  따라서 Kubernetes를 어디든 배포할 수 있으며 공급업체의 제약 없이 워크로드를 자유롭게 이동할 수 있습니다.

Google Kubernetes Engine

1. GKE를 사용하면 GCP에서 컨테이너화된 애플리케이션을 위해 Kubernetes 환경을 배포, 관리, 확장할 수 있습니다. 구체적으로 GKE는 GCP 컴퓨팅 기능의 구성 요소이며 이를 통해 Kubernetes 워크로드를 클라우드에 손쉽게 배포할 수 있습니다.
2. GKE는 완전 관리형 서비스로 기본 리소스를 프로비저닝 할 필요가 없습니다. GKE는 컨테이너 최적화 운영체제를 사용합니다. Google이 관리하는 이 운영체제는 빠른 확장에 최적화되어 있으며 리소스 사용은 최소화합니다.
3. GKE를 사용하면 먼저 Kubernetes 시스템을 인스턴스 화하는데 이러한 시스템을 '클러스터'라고 합니다 GKE의 자동 업그레이드 기능을 사용 설정하면 클러스터가 자동으로 업그레이드되어 항상 최신 버전의 Kubernetes로 유지됩니다.
4. Identity and Access Management와도 통합되므로 계정 및 역할 권한을 사용해 액세스를 제어할 수 있습니다.
5. GKE는 Stackdriver Monitoring과 통합되어 애플리케이션 성능을 파악할 수 있게 해 줍니다.
   • Stackdriver는 Google Cloud 시스템으로 서비스, 컨테이너, 애플리케이션, 인프라를 모니터링하고 관리합니다.
6. GKE는 virtual private cloud 즉 VPC와 통합되며 GCP의 네트워킹 기능을 사용합니다.
7. GCP Console은 GKE 클러스터와 리소스에 대한 정보를 제공하며 여기에서 클러스터의 리소스를 확인, 검사, 삭제할 수 있습니다.
8. Kubernetes에는 대시보드가 포함되어 있지만 안전하게 설정하려면 상당한 노력이 필요합니다 하지만 GCP Console은 관리할 필요가 없는 GKE 클러스터 및 워크로드의 대시보드로 Kubernetes 대시보드보다 성능이 훨씬 우수합니다.

노드

1. GKE 클러스터 내에서 컨테이너를 호스팅 하는 가상 머신을 '노드'라고 합니다.
2. GKE의 자동 복구 기능을 사용 설정하면 서비스가 비정상 노드를 자동으로 복구합니다.
3. 각 클러스터 노드에서 정기적으로 상태를 확인합니다. 노드가 비정상 상태로 확인되어 복구가 필요하다면 GKE에서 노드를 드레이닝 즉, 워크로드를 정상적으로 종료하고 노드를 다시 생성합니다.

Compute Engine

1. GCP에서 실행되는 가상 머신을 제공합니다.
2. 사전 정의된 VM 구성을 선택할 수 있습니다. 이 과정이 개발된 시점을 기준으로 이러한 가상 머신의 크기는 3 테라바이트 이상의 메모리를 갖춘 최대 160개의 vCPU에 이릅니다 또한 성능 및 비용 요구사항과 정확히 일치하도록 맞춤 설정된 구성을 생성할 수도 있습니다.
3. 영구 디스크와 로컬 SSD라는 두 가지 주요 옵션을 제공합니다. 초당 입출력 작업 수가 매우 높은 로컬 SSD를 선택할 수도 있습니다. 영구 디스크는 최대 64 테라바이트까지 수직 확장할 수 있는 네트워크 스토리지를 제공하며 백업 및 이동성을 위해 영구 디스크의 스냅샷을 쉽게 만들 수 있습니다.
4. 자동 확장을 지원하는 전역 부하 분산기 뒤에 Compute Engine 워크로드를 배치할 수 있습니다.
5. Compute Engine은 관리형 인스턴스 그룹이라는 기능을 제공합니다.
   • 이 기능을 사용하여 수요를 충족하기 위해 자동으로 배포되는 리소스를 정의할 수 있습니다.
6. GCP는 초당 청구를 제공하여 Compute Engine 리소스 비용을 세부적으로 제어할 수 있습니다. 이러한 세부적인 제어 덕분에 일괄 처리 작업과 같이 짧은 기간에 컴퓨팅 리소스를 배포할 때 비용을 절감할 수 있습니다.
7. Compute Engine은 안전하게 중단될 수 있는 워크로드에 대해 가격이 훨씬 저렴한 선점형 가상 머신을 제공합니다.
8. Compute Engine을 사용하면 인프라를 완전히 제어할 수 있습니다
   • 운영체제를 맞춤 설정하고 여러 운영체제를 사용하는 애플리케이션을 실행할 수도 있습니다.
   • 애플리케이션을 다시 작성하거나 아무것도 변경하지 않아도 온프레미스 워크로드를 GCP로 쉽게 리프트 앤 시프트 할 수 있습니다.
9. 다른 컴퓨팅 옵션이 애플리케이션이나 요구사항을 지원하지 않을 때 선택할 수 있는 가장 좋은 옵션입니다.

App Engine

1. App Engine은 완전 관리형 애플리케이션 플랫폼입니다.
2. App Engine을 사용한다는 것은 실버 관리 및 구성 배포가 필요 없음을 뜻합니다. 개발자라면 배포에 대해 크게 걱정하지 않고 애플리케이션 빌드에 집중할 수 있습니다. 단순히 코드를 사용하기만 하면 App Engine에서 필요한 인프라를 배포합니다.
3. App Engine은 Java, Node.js, Python, PHP, C#, .Net, Ruby, Go 등 많이 사용되는 언어를 지원합니다. 컨테이너 워크로드를 실행할 수도 있습니다.
4. Stackdriver Monitoring, Logging, 디버깅 및 Error Reporting과 같은 진단도 App Engine과 긴밀하게 통합됩니다. Stackdriver를 실시간 디버깅 기능으로 사용하여 소스 코드를 분석하고 디버깅할 수 있습니다. Stackdriver는 Cloud SDK, Cloud Source Repositories, Intelligent, Visual Studio, PowerShell과 같은 도구와 통합됩니다.
5. App Engine은 또한 버전 제어 및 트래픽 분할도 지원합니다.
6. RESTful API는 개발자가 쉽게 작업하고 확장할 수 있으며 App Engine을 사용하면 쉽게 운영할 수 있습니다.

Google Kubernetes Engine

1. Kubernetes는 배포, 확장, 부하 분산, 로깅, 모니터링, 기타 관리 기능을 자동화합니다. Google Kubernetes Engine은 기능을 추가하고 다른 GCP 서비스와 자동으로 통합하여 GCP에서의 Kubernetes 관리를 확장합니다.
2. GKE는 클러스터 확장, 영구 디스크, 최신 버전의 Kubernetes로 자동 업데이트, 비정상 노드에 대한 자동 복구를 지원합니다.
3. GKE는 Cloud Build, Container Registry, Stackdriver Monitoring, Stackdriver Logging과의 통합 기능이 내장되어 있습니다. 온프레미스 클러스터로 실행되는 기존 워크로드는 GCP로 쉽게 이동할 수 있습니다 공급업체에 종속되지 않습니다.
4. GKE는 컨테이너화 된 애플리케이션, 클라우드 기반 분산 시스템, 하이브리드 애플리케이션에 매우 적합합니다.

Cloud Run

1. Cloud Run은 웹 요청 또는 Cloud Pub/Sub 이벤트를 통해 스테이트리스(Stateless) 컨테이너를 실행할 수 있는 관리형 컴퓨팅 플랫폼입니다.
2. Cloud Run은 서버리스입니다 모든 인프라 관리를 추상화하므로 애플리케이션 개발에만 집중할 수 있습니다.
3. Cloud Run을 사용하면 완전 관리형 또는 자체 GKE 클러스터에서 컨테이너를 실행할 수 있습니다.
4. Cloud Run을 사용하면 서버에 대해 걱정할 필요 없이 요청 또는 이벤트 기반 스테이트리스(Stateless) 워크로드를 실행할 수 있습니다.
5. 트래픽에 따라 거의 즉시 0에서 자동으로 확장 및 축소되므로 확장 구성을 걱정할 필요가 없습니다.
6. Cloud Run은 100밀리 초 단위로 계산하여 사용하는 리소스에 대해서만 비용을 청구합니다. 따라서 초과 프로비저닝 된 리소스의 비용을 지불할 필요가 없습니다.
7. Cloud Run은 100밀리 초 단위로 계산하여 사용하는 리소스에 대해서만 비용을 청구합니다 따라서 초과 프로비저닝 된 리소스의 비용을 지불할 필요가 없습니다.
8. HTTP 요청을 통해 전달되는 요청이나 이벤트를 수신 대기하는 스테이트리스(Stateless) 컨테이너를 배포할 수 있습니다.
9. Cloud Run을 사용하면 원하는 프레임워크와 도구를 사용하여 모든 언어로 애플리케이션을 빌드하고 해당 서버 인프라를 관리 및 유지할 필요 없이 단 몇 초 만에 배포할 수 있습니다.