여기에서 나온 정보를 학습한 내용입니다.

Visual Studio Code Dev Containers 확장을 사용하여 컨테이너 기반 개발 환경을 가져오고 만들고 구성합니다.

이 모듈을 마치면 다음을 수행할 수 있습니다.

  • Visual Studio Code Dev Containers 확장을 설치합니다.
  • Docker에서 프로젝트를 로드 및 연결합니다.
  • 로컬 컴퓨터에서 컨테이너의 포트에 액세스합니다.
  • 컨테이너에서 작업하는 동안 설정을 사용자 지정합니다.
  • 컨테이너 환경에 소프트웨어를 추가합니다.

Visual Studio Code 개발 컨테이너 확장을 사용하여 Docker 컨테이너 내에서 개발할 수 있습니다.

다양한 언어와 런타임 환경을 중심으로 소프트웨어 컨설팅을 수행하는 에이전시에서 근무한다고 가정합니다. 모든 개발자가 Visual Studio Code를 사용하고 있습니다. 에이전시에서는 수십 개의 프로젝트가 진행 중이며, 각각 고유한 구성 및 런타임 요구 사항이 있습니다. 에이전시 개발자는 먼저 머신을 설정하거나 구성하지 않고도 모든 프로젝트에서 작업할 수 있어야 합니다.

이 모듈에서는 기존 프로젝트에 구성 파일을 추가합니다. 이러한 파일은 프로젝트가 “작동하는” 환경을 빌드하는 방법을 Visual Studio Code에 알려줍니다. Dev Container 구성을 사용하여 런타임 환경을 구성합니다. 또한 Docker와 Visual Studio Code가 있는 모든 사용자가 사용할 수 있는 개발 환경의 구성을 자동화합니다.

필수 구성 요소

  • 소프트웨어 개발에 대한 기본 지식(예: 코드 실행 또는 새 언어 설치의 의미)
  • Docker 및 기본 Docker 지식:
  • Git 및 Git 리포지토리에 대한 기본 지식

연습 - 프로제트 준비

샘플 리포지토리 복제

  1. Docker Desktop이 머신에 설치되어 실행 중인지 확인합니다.
  2. 샘플 리포지토리의 URL을 클립보드에 복사합니다.
    https://github.com/MicrosoftDocs/mslearn-python-products
  3. Visual Studio Code의 새 인스턴스를 엽니다.
  4. 사이드바에서 리포지토리 복제 단추를 선택하거나 F1 키를 눌러 명령 팔레트를 열고 Git: Clone을 검색합니다.
  5. 클립보드에서 URL을 붙여넣습니다.
  6. 디스크에서 프로젝트를 복제할 수 있는 위치를 선택합니다.
  7. Visual Studio Code의 알림에서 열기를 선택합니다.
  8. 작성자를 신뢰할 수 있는지 묻는 팝업이 표시되면 예, 작성자를 신뢰합니다를 선택합니다.

dev container

이 확장의 작동 방식

Dev Containers extension 을 사용하면 특정 기술 스택 또는 종속성이 이미 설정된 개발 컨테이너를 가져와 프로젝트를 열고, 로컬 머신에 아무것도 다운로드하지 않고도 코드가 제대로 작동하는지 확인할 수 있습니다. Dev Containers 실행 중인 컨테이너에 Visual Studio Code를 연결하는 방식으로 작동합니다. 작업 영역 파일은 로컬 파일 시스템에서 탑재되거나 컨테이너에 복사 또는 복제됩니다.

Visual Studio Code Extension은 컨테이너 안에 설치되고 내부에서 실행됩니다. 여기서 확장은 도구, 플랫폼, 파일 시스템에 대한 모든 권한을 갖습니다. 개발자에게 이 환경은 Visual Studio Code에서 정상적으로 프로젝트를 연 것과 같습니다.

다른 컨테이너에 연결하는 것만으로 전체 개발 환경을 원활하게 전환할 수 있습니다. 이 확장은 ‘.devcontainer’ 라는 폴더에 포함된 몇 가지 구성 파일을 기반으로 모든 설정을 처리합니다.

기존 프로젝트에 개발 컨테이너 추가

    1. F1 키를 눌러 명령 팔레트를 엽니다.
    2. Dev Container: new Dev Container를 누릅니다
    3. python 3를 선택합니다
    4. default 버전을 선택합니다.

[!info] 저는 microsoft 기본가이인 3.11 버전으로 하면 container가 생성이 안되는 일이 있었습니다. 그래서, default 버전으로 변경했습니다.

    1.  
    2. container가 실행되는 것을 확인할 수 있습니다.
    3. 명령줄에서 close remote connection을 한 후에 다시 프로젝트 파일을 열면 현재 로컬 폴더를 포함하는 Folder contians a Dev Container configuration file. Reopen folder to develop in a contain라는 알림창을 확인할 수 있습니다.

만약 이게 안 나온다면, 명령 줄에서 dev container: contain

  1.  

python 프로젝트 실행

종속성 설치

pip3 install --user -r requirements.txt
pip3 install flask

실행

$ python3 app.py

...
[notice] A new release of pip is available: 23.2.1 -> 23.3.2
[notice] To update, run: pip install --upgrade pip
vscode ➜ /workspaces/mslearn-python-products (main) $ python3 app.py 
 * Serving Flask app 'app'
 * Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:5000
Press CTRL+C to quit
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 717-269-910

[!info] flask 오류로 실행이 안된다면, pip3 install --upgrade flask 를 실행해서 업그레이드 후 진행 합니다.

실행이 되는 것을 확인했다.

project 편집기 설정 사용자 지정

에이전시의 프로젝트 중 하나에 대해 개발 컨테이너를 설정했습니다. 이제 이 프로젝트는 Docker 및 Dev Containers 확장이 있는 사용자를 위해 “저절로 작동”합니다. 여전히 종속성을 설치해야 합니다. 잘 모르는 몇 가지 Visual Studio Code 확장이 필요할 수도 있습니다.

다행히 devcontainer.json 파일을 사용하여 모든 프로젝트 설정을 완전하게 사용자 지정하고 자동화할 수 있습니다.

devcontainer.json 자세히 보기

Products Dashboard 프로젝트의 .devcontainer/devcontainer.json 파일에 있는 기본 옵션을 살펴보겠습니다. 한 번에 모두 확인하려면 다소 길기 때문에 섹션별로 살펴보겠습니다.

빌드 구성

image 속성은 컨테이너 이미지로 알려져 있는 항목을 기준으로 컨테이너를 만드는 방법을 정의합니다.

JSON

"image": "mcr.microsoft.com/devcontainers/python:0-3.11"
},

이 이미지는 devcontainers/images 리포지토리에서 호스트되며 여기서 자세히 확인할 수 있습니다.

Dockerfile 또는 Docker Compose 파일로 알려진 파일을 사용하여 설정을 구성할 수도 있습니다. 이러한 파일은 .devcontainer 폴더에 저장되며 추가 소프트웨어 설치와 같은 특정 설치 요구 사항을 추가로 구성할 수 있습니다. dev container 설명서에서 자세히 알아볼 수 있습니다.

기능

Dev Containers Extension은 자체 포함되고 공유 가능한 설치 코드 단위 및 개발 컨테이너 구성입니다. 이름은 그 중 하나를 참조하면 사용자 또는 협력자가 사용할 수 있도록 개발 컨테이너에 도구, 런타임 또는 라이브러리 "기능"을 빠르고 쉽게 추가할 수 있다는 아이디어에서 비롯되었습니다.

VS Code 명령 Dev Containers: 개발 컨테이너 구성 파일 추가를 사용하는 경우 Git 또는 Azure CLI 설치와 같은 기존 개발 컨테이너 구성을 사용자 지정하는 스크립트 목록이 표시됩니다.

프로젝트 설정

파일의 뒤쪽 섹션에서는 프로젝트 구성을 직접 처리합니다.

customizations는 VS Code 및 GitHub Codespaces와 같은 개발 컨테이너를 지원하는 제품에 대한 제품별 속성을 설정합니다.

예를 들어 컴퓨터별 설정을 컨테이너에 복사하도록 vscode.settings를 설정할 수 있습니다. 고유한 Visual Studio Code 설정에 해당 설정이 있을 수도 있습니다. settings에 프로젝트를 추가하여 이러한 프로젝트를 여는 누구든지 이러한 특정 VS Code 설정을 가져오도록 할 수 있습니다.

이 Python 컨테이너에서는 기본 이미지 mcr.microsoft.com/devcontainers/python:0-3.11에서 이러한 설정을 볼 수 있습니다. 이러한 설정은 사용자에게 향상된 Python 편집 환경을 제공합니다.

  • extensions 배열을 사용하면 컨테이너에 연결할 때 Visual Studio Code에 설치할 Visual Studio Code 확장을 지정할 수 있습니다. Dev Containers를 사용하는 경우 일반적인 Visual Studio Code 설정과 이미 설치한 모든 확장은 표시되지 않습니다. 여기에서 확장은 ID로 지정됩니다.

postCreateCommand

postCreateCommand 속성을 사용하면 컨테이너가 생성된 후 원하는 명령을 실행할 수 있습니다. 첫 번째 연습에서는 종속성을 설치하기 위해 pip3 명령을 실행해야 했습니다. 하지만 그 방법을 어떻게 알 수 있나요? 방법을 모를 수도 있습니다. 자동으로 수행되어 다른 사용자가 걱정하지 않아도 되도록 여기에서 구성할 수 있습니다.

다음 연습에서는 프로젝트의 여러 부분을 자동화하여 다른 개발자가 즉시 성공할 수 있도록 devcontainer.json 파일을 수정합니다.

vscode extension 자동 설치

remote 로 열려 있는 vscode에서 extension을 설치하고, 설치한 extension을 마우스 우클릭을 누른 다음에, Add to devcontainer.json을 누른다.

~/.devcontain/devcontainer.json 에 다음 값이 추가된 것을 확인할 수 있다.

{
    "name": "Python 3",
    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "image": "mcr.microsoft.com/devcontainers/python:1-3.12-bullseye",
    "customizations": {
        "vscode": {
            "extensions": [
                "wholroyd.jinja"
            ]
        }
    }
}

python 종속성 자동 설치

flaks 버전이 낮기 때문에, devcontainer.json파일을 다음과 같이 수정한다.

# Flask Framework
Flask==3.0.0

devcontainer.json에 아래 내용을 추가 한다.

...
    "postCreateCommand": "pip3 install --user -r requirements.txt"

rebuild 을 다시 선택한다.

이제 컨테이너가 사용자 지정되고 에이전시에 대해 자동화됩니다. Dev Containers를 사용하여 이 프로젝트를 여는 개발자는 즉시 프로젝트를 실행하고 코드 작성을 시작할 수 있습니다.

# 기존 컨테이너에 소프트웨어 추가

사용자 지정 컨테이너는 에이전시에 적합합니다. Dev Containers의 기능을 사용하여 미리 구성된 개발 컨테이너를 추가할 수 있었으며, 지금까지의 연습을 통해 devcontainer.json 파일을 활용해 환경을 사용자 지정할 수 있었습니다. 그러나 해당 이미지나 미리 구성된 개발 컨테이너에서 사용할 수 있는 것 외에 다른 소프트웨어를 추가하려면 어떻게 해야 할까요?

위 페이지에서 추가할 수 있는 기능들에 대해서 확인 할수 있습니다

devcontainer.json파일에 아래와 같이 추가 합니다.

"features": {
    "ghcr.io/devcontainers/features/node:1": {
        "version": "18"
    }
}

rebuild 를 실행하면 node가 추가 설치 된 것을 확인할 수 있습니다

$ node -v

rust function 추가하기

"features": {
    "ghcr.io/devcontainers/features/rust:1": {
        "version": "1.70.0"
    }
}
반응형

Google Kubernetes Engine(GKE)에서는 Google 인프라를 사용하여 컨테이너화된 애플리케이션을 배포, 관리 및 확장할 수 있는 관리형 환경을 제공합니다. Kubernetes Engine 환경은 컨테이너 클러스터를 형성하도록 그룹화된 여러 머신(구체적으로 Compute Engine 인스턴스)으로 구성되어 있습니다. 이번 실습에서는 GKE를 사용하여 직접 컨테이너를 생성하고 애플리케이션을 배포해 봅니다.

Google Kubernetes Engine을 사용한 클러스터 조정

GKE 클러스터는 Kubernetes 오픈소스 클러스터 관리 시스템을 기반으로 합니다. Kubernetes는 컨테이너 클러스터와 상호작용할 수 있는 메커니즘을 제공합니다. Kubernetes 명령어와 리소스를 사용하면 애플리케이션을 배포 및 관리하고 관리 작업을 수행하고 정책을 설정하며 배포된 워크로드의 상태를 모니터링할 수 있습니다.

Kubernetes는 널리 쓰이는 Google 서비스와 동일한 설계 원칙을 따르고 있어 자동 관리, 애플리케이션 컨테이너의 모니터링 및 활성 여부 프로브, 자동 확장, 순차적 업데이트와 같은 이점을 그대로 누릴 수 있습니다. 10년 이상 컨테이너로 프로덕션 워크로드를 실행해 온 Google의 경험이 녹아든 기술을 활용하여 컨테이너 클러스터에서 애플리케이션을 실행할 수 있습니다.

Google Cloud 기반 Kubernetes

GKE 클러스터를 실행하면 Google Cloud의 고급 클러스터 관리 기능을 활용할 수 있습니다. 예를 들면 다음과 같습니다.

Kubernetes 관련 기본 사항을 배웠으므로 이제 GKE를 사용하여 컨테이너화된 애플리케이션을 30분 이내에 배포하는 방법을 알아봅니다. 실습 환경을 설정하려면 아래 단계를 따르세요.

작업 1. 기본 컴퓨팅 영역 설정

컴퓨팅 영역이란 클러스터와 리소스가 존재하는 리전 내 대략적인 위치를 의미합니다. 예를 들어 us-central1-aus-central1 리전에 속한 영역입니다. Cloud Shell에서 새 세션을 시작합니다.

  1. 기본 컴퓨팅 리전 설정
  2. $ gcloud config set compute/region us-west3 Updated property [compute/region].
  3. 기본 컴퓨팅 영역 설정
  4. $ gcloud config set compute/zone us-west3-b Updated property [compute/zone].

작업 2. GKE 클러스터 만들기

클러스터는 1개 이상의 클러스터 마스터 머신과 노드라는 여러 작업자 머신으로 구성됩니다. 노드란 클러스터를 구성하기 위해 필요한 Kubernetes 프로세스를 실행하는 Compute Engine 가상 머신(VM) 인스턴스입니다.

참고: 클러스터 이름은 영문자로 시작하고 영숫자 문자로 끝나야 하며 40자(영문 기준) 이하여야 합니다.

다음 명령어를 실행합니다.

  1. 클러스터 만들기
    $ gcloud container clusters create --machine-type=e2-medium --zone=us-west3-b lab-cluster
    

Default change: VPC-native is the default mode during cluster creation for versions greater than 1.21.0-gke.1500. To create advanced routes based clusters, please pass the --no-enable-ip-alias flag
Default change: During creation of nodepools or autoscaling configuration changes for cluster versions greater than 1.24.1-gke.800 a default location policy is applied. For Spot and PVM it defaults to ANY, and for all other VM kinds a BALANCED policy is used. To change the default values use the --location-policy flag.
Note: Your Pod address range (--cluster-ipv4-cidr) can accommodate at most 1008 node(s).
Creating cluster lab-cluster in us-west3-b... Cluster is being deployed...working..

NAME: lab-cluster
LOCATION: us-west3-b
MASTER_VERSION: 1.22.8-gke.202
MASTER_IP: 34.67.240.12
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.22.8-gke.202
NUM_NODES: 3
STATUS: RUNNING


출력에 표시되는 경고는 모두 무시해도 괜찮습니다. 클러스터 생성이 완료되기까지 **몇 분**이 걸릴 수 있습니다.(나는 5분 넘게 걸림)

## 작업 3. 클러스터의 사용자 인증 정보 얻기

클러스터를 만든 후 클러스터와 상호작용하려면 사용자 인증 정보가 필요합니다.

1. **클러스터에 인증**:

```bash
$ gcloud container clusters get-credentials lab-cluster

Fetching cluster endpoint and auth data.
kubeconfig entry generated for lab-cluster.

작업 4. 클러스터에 애플리케이션 배포

이제 클러스터에 컨테이너화된 애플리케이션을 배포할 수 있습니다. 이번 실습에서는 hello-app을 클러스터에서 실행합니다.

GKE는 Kubernetes 객체를 사용하여 클러스터의 리소스를 만들고 관리합니다. 웹 서버와 같은 스테이트리스(Stateless) 애플리케이션을 배포할 때는 Kubernetes에서 배포 객체를 사용합니다. 서비스 객체는 인터넷에서 애플리케이션에 액세스하기 위한 규칙과 부하 분산 방식을 정의합니다.

  1. hello-app 컨테이너 이미지에서 새 배포 hello-server를 생성하려면 다음 kubectl create 명령어를 실행합니다.
    $ kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0
    

deployment.apps/hello-server created


2. 애플리케이션을 외부 트래픽에 노출할 수 있는 Kubernetes 리소스인 **Kubernetes Service를 생성**하려면 다음 [kubectl expose](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#expose) 명령어를 실행합니다.

```bash
$ kubectl expose deployment hello-server --type=LoadBalancer --port 8080

이 명령어에서

  • --port는 컨테이너가 노출될 포트를 지정합니다.
  • type="LoadBalancer"는 컨테이너의 Compute Engine 부하 분산기를 생성합니다.
  1. hello-server 서비스를 검사하려면 kubectl get을 실행합니다.
    $ kubectl get service
    

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-server LoadBalancer 10.4.9.208 34.106.132.253 8080:30570/TCP 54s
kubernetes ClusterIP 10.4.0.1 443/TCP 5m29s


> **참고:** 외부 IP 주소가 생성되기까지 1분 정도 걸릴 수 있습니다. `EXTERNAL-IP` 열이 **대기중** 상태이면 위 명령어를 다시 실행하세요.

4. 웹브라우저에서 애플리케이션을 보려면 새 탭을 열고 다음 주소를 입력합니다. 여기서 `[EXTERNAL IP]`는 `hello-server`의 `EXTERNAL-IP`로 바꿉니다.
```bash
http://[EXTERNAL-IP]:8080  -- browser로 접속

Hello, world!
Version: 1.0.0
Hostname: hello-server-5597d96dd4-v5mmm

작업 5. 클러스터 삭제

  1. 클러스터를 삭제하려면 다음 명령어를 실행합니다.
    $ gcloud container clusters delete lab-cluster 
  • [lab-cluster] in [us-west3-b]

Do you want to continue (Y/n)?

Deleting cluster lab-cluster...working


메시지가 표시되면 **Y**를 입력하여 확인합니다.

클러스터를 삭제하는 데 몇 분 정도 걸릴 수 있습니다. Google Kubernetes Engine(GKE)에서 GKE 클러스터 삭제하기에 대한 자세한 내용은 [클러스터 삭제](https://cloud.google.com/kubernetes-engine/docs/how-to/deleting-a-cluster)를 참조하세요.
반응형

Apache Mesos vs Kubernetes

주의할 점은 Kubernetes를 Mesos와 직접 비교하는 것은 완전히 공정하지 않다는 것입니다. 우리가 추구하는 대부분의 컨테이너 오케스트레이션 기능은 Marathon과 같은 Mesos 프레임워크 중 하나에서 제공됩니다. 따라서 올바른 관점에서 상황을 유지하기 위해 Kubernetes를 직접 Mesos가 아닌 Marathon과 비교하려고 합니다.

이러한 시스템의 원하는 속성 중 일부를 기반으로 이러한 오케스트레이션 시스템을 비교할 것입니다.

지원되는 워크로드

Mesos는 컨테이너화되거나 비컨테이너화될 수 있는 다양한 유형의 워크로드를 처리하도록 설계되었습니다. 우리가 사용하는 프레임워크에 따라 다릅니다. 우리가 보았듯이 Marathon과 같은 프레임워크를 사용하여 Mesos에서 컨테이너화된 워크로드를 지원하는 것은 매우 쉽습니다.

반면 Kubernetes는 컨테이너화된 워크로드에서만 작동합니다. 가장 광범위하게 Docker 컨테이너와 함께 사용하지만 Rkt와 같은 다른 컨테이너 런타임을 지원합니다. 앞으로 Kubernetes는 더 많은 유형의 워크로드를 지원할 수 있습니다.

확장성(Scalability) 지원

Marathon은 애플리케이션 정의 또는 사용자 인터페이스를 통한 확장을 지원합니다. Autoscaling은 Marathon에서도 지원됩니다. 또한 모든 종속성을 자동으로 확장하는 애플리케이션 그룹을 확장할 수 있습니다.

Pod는 Kubernetes의 기본 실행 단위입니다. Pod는 Deployment에서 관리할 때 확장할 수 있습니다. 이것이 Pod가 항상 배포로 정의되는 이유입니다. 스케일링은 수동 또는 자동일 수 있습니다.

고가용성(High Availability) 처리

Marathon의 애플리케이션 인스턴스는 고가용성을 제공하는 Mesos 에이전트에 분산됩니다. 일반적으로 Mesos 클러스터는 여러 에이전트로 구성됩니다. 또한 ZooKeeper는 쿼럼 및 리더 선택을 통해 Mesos 클러스터에 고가용성을 제공합니다.

마찬가지로 Kubernetes의 포드는 여러 노드에 복제되어 고가용성을 제공합니다. 일반적으로 Kubernetes 클러스터는 여러 작업자 노드로 구성됩니다. 또한 클러스터에는 여러 마스터가 있을 수도 있습니다. 따라서 Kubernetes 클러스터는 컨테이너에 고가용성을 제공할 수 있습니다.

서비스 검색 및 로드 밸런싱

Mesos-DNS는 애플리케이션에 대한 서비스 검색 및 기본 로드 밸런싱을 제공합니다. Mesos-DNS는 각 Mesos 작업에 대한 SRV 레코드를 생성하고 작업을 실행하는 시스템의 IP 주소 및 포트로 변환합니다. Marathon 애플리케이션의 경우 Marathon-lb를 사용하여 HAProxy를 사용하여 포트 기반 검색을 제공할 수도 있습니다.

Kubernetes에 배포하면 포드가 동적으로 생성 및 소멸됩니다. 따라서 일반적으로 서비스 검색을 제공하는 Service를 통해 Kubernetes에서 Pod를 노출합니다. Kubernetes의 서비스는 포드에 대한 디스패처 역할을 하므로 로드 밸런싱도 제공합니다.

업그레이드 및 롤백 수행

Marathon에서 애플리케이션 정의에 대한 변경 사항은 배포로 처리됩니다. 배포는 애플리케이션의 시작, 중지, 업그레이드 또는 확장을 지원합니다. Marathon은 또한 최신 버전의 애플리케이션을 배포하기 위한 롤링 시작(Rolling Start)을 지원합니다. 그러나 롤백은 간단하며 일반적으로 업데이트된 정의를 배포해야 합니다.

Kubernetes의 배포는 업그레이드 및 롤백을 지원합니다. 우리는 이전 포드를 새 포드로 교체하면서 취할 배포 전략을 제공할 수 있습니다. 일반적인 전략은 재생성 또는 롤링 업데이트입니다. 배포의 롤아웃 기록은 기본적으로 Kubernetes에서 유지 관리되므로 이전 버전으로 쉽게 롤백할 수 있습니다.

로깅 및 모니터링

Mesos에는 모든 클러스터 구성 요소를 스캔하고 상태 및 기타 Metric과 관련된 데이터를 사용할 수 있도록 하는 진단 유틸리티가 있습니다. 사용 가능한 API를 통해 데이터를 쿼리하고 집계할 수 있습니다. 이 데이터의 대부분은 Prometheus와 같은 외부 도구를 사용하여 수집할 수 있습니다.

Kubernetes는 리소스 Metric 또는 전체 Metric 파이프라인으로 다른 개체와 관련된 자세한 정보를 제공합니다. 일반적인 방법은 Kubernetes 클러스터에 ELK 또는 Prometheus+Grafana와 같은 외부 도구를 배포하는 것입니다. 이러한 도구는 클러스터 Metric을 수집하고 훨씬 사용자 친화적인 방식으로 제공할 수 있습니다.

저장소(Storage)

Mesos에는 상태 저장 애플리케이션을 위한 영구 로컬 볼륨이 있습니다. 예약된 리소스에서만 영구 볼륨을 생성할 수 있습니다. 일부 제한 사항이 있는 외부 저장소도 지원할 수 있습니다. Mesos는 스토리지 공급업체와 컨테이너 오케스트레이션 플랫폼 간의 공통 API 세트인 CSI(Container Storage Interface)에 대한 실험적인 지원을 제공합니다.

Kubernetes는 상태 저장 컨테이너에 대해 여러 유형의 영구 볼륨을 제공합니다. 여기에는 iSCSI, NFS와 같은 스토리지가 포함됩니다. 또한 AWS, GCP와 같은 외부 스토리지도 지원합니다. Kubernetes의 Volume 객체는 이 개념을 지원하며 CSI를 비롯한 다양한 유형으로 제공됩니다.

네트워킹

Mesos의 컨테이너 런타임은 두 가지 유형의 네트워킹 지원, 컨테이너당 IP 및 네트워크 포트 매핑을 제공합니다. Mesos는 컨테이너에 대한 네트워킹 정보를 지정하고 검색하기 위한 공통 인터페이스를 정의합니다. Marathon 애플리케이션은 호스트 모드 또는 브리지 모드에서 네트워크를 정의할 수 있습니다.

Kubernetes의 네트워킹은 각 포드에 고유한 IP를 할당합니다. 이렇게 하면 컨테이너 포트를 호스트 포트에 매핑할 필요가 없습니다. 또한 이러한 포드가 노드 간에 서로 통신할 수 있는 방법을 정의합니다. 이것은 Cilium, Contiv와 같은 네트워크 플러그인에 의해 Kubernetes에서 구현됩니다.

무엇을 사용할까?

명확한 결과를 기대하지만, 어떤 기술이 다른 기술보다 우수하다고 선언하는 것은 전적으로 공정하지 않습니다. 우리가 보았듯이 Kubernetes와 Mesos는 모두 강력한 시스템이며 상당히 경쟁적인 기능을 제공합니다.

그러나 성능은 상당히 중요한 측면입니다. Kubernetes 클러스터는 5000개 노드로 확장할 수 있으며 Marathon on Mesos 클러스터는 최대 10,000개의 에이전트를 지원하는 것으로 알려져 있습니다. 대부분의 실제 사례에서 우리는 그러한 큰 클러스터를 다루지 않을 것입니다.

마지막으로 유연성과 워크로드 유형으로 귀결됩니다. 새로 시작하고 컨테이너화된 워크로드만 사용할 계획이라면 Kubernetes가 더 빠른 솔루션을 제공할 수 있습니다. 그러나 컨테이너와 비컨테이너가 혼합된 기존 워크로드가 있는 경우 Mesos with Marathon이 더 나은 선택이 될 수 있습니다.

다른 대안

Kubernetes와 Apache Mesos는 꽤 강력하지만, 이 공간에서 유일한 시스템은 아닙니다. 우리가 이용할 수 있는 유망한 대안들이 꽤 많이 있습니다.. 자세한 내용은 다루지 않겠지만 몇 가지 항목을 간단히 나열해 보겠습니다.

  • Docker Swarm: 도커 스웜은 도커 컨테이너를 위한 오픈 소스 클러스터링 및 스케줄링 도구이다. Docker 호스트의 클러스터를 관리하는 명령줄 유틸리티가 제공됩니다. Kubernetes나 메소스와 달리 도커 컨테이너에 한정되어 있습니다.
  • Nomad: Nomad는 HashiCorp의 유연한 워크로드 조정자로 컨테이너형 또는 컨테이너형이 아닌 애플리케이션을 관리합니다. Nomad는 Docker 컨테이너와 같은 애플리케이션을 배포하기 위한 선언적 인프라(Infrastructure-as-code)를 활성화합니다.
  • OpenShift: 오픈시프트는 레드햇의 컨테이너 플랫폼으로, 쿠버네티스가 주관하고 관리합니다. OpenShift는 Kubernetes가 제공하는 통합 이미지 레지스트리, 소스-이미지 빌드, 네이티브 네트워킹 솔루션과 같은 많은 기능을 제공합니다.
반응형

+ Recent posts