티스토리 뷰
Containers and Kubernetes
목차
1. Introduction to Containers
2. Introduction to Kubernetes
3. Introduction to Google Kubernetes Engine
4. Computing options
1. Introduction to Containers
예전에는 애플리케이션을 배포하는 기본 방법은 자체 물리적 컴퓨터에 있었습니다. 서버 하나를 설정하려면 물리적 공간, 전력, 냉각, 네트워크 연결을 찾은 다음 운영 체제, 소프트웨어 종속성, 마지막으로 애플리케이션을 설치해야 했습니다. 더 많은 처리 능력, 중복성, 보안 또는 확장성이 필요한 경우 컴퓨터를 더 추가하기도 하였습니다. 또한 각 컴퓨터가 하나의 목적 (예 : 데이터베이스, 웹 서버 또는 콘텐츠 전달)을 갖는 것은 매우 일반적이었습니다.
이 방식은 리소스를 낭비하고 배포, 유지 관리 및 확장하는데 많은 시간이 걸렸습니다. 또한 이식성이 별로 없었습니다. 응용 프로그램은 특정 운영체제용으로, 때로는 특정 하드웨어용으로 제작되었습니다.
가상화는 동일한 물리적 컴퓨터에서 여러 가상 서버와 운영 체제를 실행할 수 있게 함으로써 도움이 되었습니다. 하이퍼 바이저는 기본 하드웨어에서 운영 체제의 종속성을 깨뜨리고 여러 가상 머신이 해당 하드웨어를 공유할 수 있도록 하는 소프트웨어 계층입니다. KVM은 잘 알려진 하이퍼 바이저입니다. 오늘날 가상화를 사용하여 새 서버를 상당히 빠르게 배포할 수 있습니다.
가상화를 채택하면 새로운 솔루션을 배포하는 데 걸리는 시간이 줄어듭니다. 사용하는 물리적 컴퓨터의 자원을 덜 낭비하게 됩니다. 그리고 가상 머신을 이미지화하고 이동할 수 있기 때문에 이식성이 향상되었습니다. 그러나 응용 프로그램, 모든 종속성 및 운영 체제는 여전히 함께 번들로 제공됩니다. 한 하이퍼 바이저 제품에서 다른 하이퍼 바이저 제품으로 VM을 이동하는 것은 쉽지 않으며 VM을 시작할 때마다 운영 체제를 부팅하는 데 시간이 걸립니다.
단일 VM 내에서 여러 애플리케이션을 실행하면 또 다른 문제가 발생합니다. 종속성을 공유하는 애플리케이션은 서로 격리되지 않습니다. 한 응용 프로그램의 리소스 요구 사항으로 인해 다른 응용 프로그램에 필요한 리소스가 부족할 수 있습니다. 또한 한 응용 프로그램에 대한 종속성 업그레이드로 인해 다른 응용 프로그램의 작동이 중지될 수 있습니다.
엄격한 소프트웨어 엔지니어링 정책으로 이 문제를 해결할 수 있습니다. 예를 들어, 어떤 응용 프로그램도 변경할 수 없도록 종속성을 잠글 수 있습니다. 그러나 종속성을 가끔 업그레이드해야 하는 경우가 있어 새로운 문제가 발생합니다.
통합 테스트를 추가하여 애플리케이션이 작동하는지 확인할 수 있습니다. 그러나 종속성 문제는 해결하기 어려운 새로운 오류 모드를 유발할 수 있습니다. 그리고 애플리케이션 환경의 기본 무결성을 확인하기 위해 통합 테스트에 의존해야 하는 경우 개발 속도가 매우 느려집니다.
이 문제를 해결하는 VM 중심의 방법은 각 애플리케이션에 대해 전용 가상 머신을 실행하는 것입니다. 각 응용 프로그램은 고유 한 종속성을 유지하고 커널은 격리되므로 한 응용 프로그램이 다른 응용 프로그램의 성능에 영향을 주지 않습니다. 그 결과 두 개의 완전한 커널 사본이 실행됩니다.
이를 수백 또는 수천 개의 애플리케이션으로 확장하면 한계를 알 수 있습니다. 커널 업데이트를 시도할 때 대규모 시스템의 경우 전용 VM은 중복 및 낭비입니다. VM은 전체 운영 체제를 부팅해야 하므로 시작하는데 상대적으로 느립니다.
종속성 문제를 해결하는 보다 효율적인 방법은 응용 프로그램 및 해당 종속성 수준에서 추상화를 구현하는 것입니다. 전체 시스템 또는 전체 운영 체제를 가상화할 필요가 없으며 사용자 공간만 가상화할 수 있습니다. 사용자 공간은 커널 위에 있는 모든 코드이며 응용 프로그램과 해당 종속성을 포함합니다. 이것이 컨테이너를 생성한다는 의미입니다. 컨테이너는 애플리케이션 코드를 실행하기 위한 격리된 사용자 공간입니다.
컨테이너는 전체 운영 체제를 포함하지 않기 때문에 경량화되었습니다. 그것들은 매우 효율적으로 기본 시스템에 빡빡하게 일정을 잡거나 패킹할 수 있습니다. 또한 전체 VM을 부팅하고 각 애플리케이션에 대해 운영 체제를 초기화하지 않고 운영 체제 프로세스를 시작 및 중지하기 때문에 매우 빠르게 생성 및 종료할 수 있습니다.
이제 컨테이너를 애플리케이션 코드의 전달 수단으로 이해했습니다. 가볍고 독립형이며 리소스 효율적이며 이식 가능한 실행 가능한 패키지입니다. 데스크톱, 랩톱 및 서버에서 일반적인 방식으로 애플리케이션 코드를 개발합니다. 컨테이너를 사용하면 애플리케이션 런타임, 시스템 도구, 시스템 라이브러리 및 설정과 같은 소프트웨어 종속성에 대해 걱정하지 않고 VM에서 최종 코드를 실행할 수 있습니다. 필요한 모든 종속성으로 코드를 패키징 했으며 컨테이너를 실행하는 엔진이 런타임에 이를 사용할 수 있도록 합니다.
컨테이너는 확장 가능한 고성능 애플리케이션을 제공하는 애플리케이션 중심 방식이므로 개발자의 관심을 끌고 있습니다. 또한 컨테이너를 통해 개발자는 기본 하드웨어 및 소프트웨어에 대해 안전하게 가정할 수 있습니다.
Linux 커널을 사용하면 랩톱에서는 작동하지만 프로덕션에서는 작동하지 않는 코드가 더 이상 없습니다. 컨테이너는 동일하며 어디에서나 실행됩니다. 프로덕션 이미지를 기반으로 컨테이너를 증분 변경하는 경우 단일 파일 사본으로 매우 빠르게 배포할 수 있습니다.
마지막으로, 컨테이너를 사용하면 마이크로 서비스 디자인 패턴, 즉 느슨하게 결합된 세분화된 구성 요소를 사용하는 애플리케이션을 더 쉽게 빌드할 수 있습니다. 이 모듈 식 디자인 패턴을 통해 운영 체제는 전체 애플리케이션에 영향을 주지 않고 애플리케이션의 구성 요소를 확장하고 업그레이드할 수 있습니다. 애플리케이션과 그 종속성을 이미지라고 합니다. 컨테이너는 단순히 이미지의 실행 인스턴스입니다. 소프트웨어를 컨테이너 이미지로 빌드함으로써 개발자는 실행될 시스템에 대해 걱정하지 않고 애플리케이션을 쉽게 패키징하고 제공할 수 있습니다.
컨테이너 이미지를 빌드하고 실행하려면 소프트웨어가 필요합니다. Docker는 빌드와 실행을 할 수 있는 도구입니다. Docker는 컨테이너에서 애플리케이션을 만들고 실행할 수 있게 해주는 오픈 소스 기술이지만 Kubernetes처럼 대규모로 이러한 애플리케이션을 조정하는 방법을 제공하지 않습니다. 이 과정에서는 Google의 Cloud Build를 사용하여 Docker 형식의 컨테이너 이미지를 만듭니다.
컨테이너는 Linux의 기본 기능이 아닙니다. 대신 워크로드를 격리하는 능력은 여러 기술의 구성에서 비롯됩니다. 하나의 기초는 Linux 프로세스입니다. 각 Linux 프로세스에는 다른 모든 프로세스와 분리된 자체 가상 메모리 주소 공간이 있으며 Linux 프로세스는 빠르게 생성되고 파괴됩니다. 컨테이너는 Linux 네임 스페이스를 사용하여 애플리케이션이 볼 수 있는 항목 (프로세스 ID 번호, 디렉터리 트리, IP 주소 등)을 제어합니다. 그런데 Linux 네임 스페이스는 이 과정의 뒷부분에서 배우게 될 Kubernetes 네임 스페이스와 다릅니다.
컨테이너는 Linux cgroup을 사용하여 애플리케이션이 사용할 수 있는 CPU 시간, 메모리, I / O 대역폭 및 기타 리소스의 최대 소비를 제어합니다. 마지막으로 컨테이너는 통합 파일 시스템을 사용하여 애플리케이션과 해당 종속성을 깔끔하고 최소한의 계층 집합으로 효율적으로 캡슐화합니다.
컨테이너 이미지는 레이어로 구성됩니다. 이미지를 빌드하는 데 사용하는 도구는 '컨테이너 매니페스트'라는 파일에서 지침을 읽습니다. Docker 형식의 컨테이너 이미지의 경우 이를 Dockerfile이라고 합니다. Dockerfile의 각 명령어는 컨테이너 이미지 내부의 레이어를 지정합니다. 각 레이어는 읽기 전용입니다. (컨테이너 가이 이미지에서 실행되면 쓰기 가능한 임시 최상위 레이어도 있습니다.) 간단한 Dockerfile을 살펴보겠습니다. 이 Dockerfile에는 각각 계층을 생성하는 4 개의 명령이 포함됩니다.
FROM 문은 공용 저장소에서 가져온 기본 계층을 만드는 것으로 시작됩니다. 이것은 특정 버전의 Ubuntu Linux 런타임 환경입니다. COPY 명령은 빌드 도구의 현재 디렉토리에서 복사된 일부 파일을 포함하는 새 레이어를 추가합니다. RUN 명령은 "make"명령을 사용하여 애플리케이션을 빌드하고 빌드 결과를 세 번째 레이어에 넣습니다.
마지막으로 마지막 계층은 컨테이너가 시작될 때 컨테이너 내에서 실행할 명령을 지정합니다. 각 레이어는 이전 레이어와의 차이점 집합 일뿐입니다. Dockerfile을 작성할 때 변경될 가능성이 높은 계층부터 변경될 가능성이 가장 높은 계층까지 구성해야 합니다.
이미지에서 새 컨테이너를 시작하면 컨테이너 런타임이 기본 레이어 위에 새 쓰기 가능한 레이어를 추가합니다. 이 레이어를 종종 컨테이너 레이어라고 합니다. 새 파일 쓰기, 기존 파일 수정 및 파일 삭제와 같이 실행 중인 컨테이너에 대한 모든 변경 사항은 이 쓰기 가능한 컨테이너 계층에 기록됩니다. 그리고 그것들은 일시적입니다.
컨테이너가 삭제되면 이 쓰기 가능한 레이어의 내용은 영원히 손실됩니다. 기본 컨테이너 이미지는 변경되지 않습니다. 컨테이너에 대한이 사실은 애플리케이션 디자인에 영향을 줍니다. 데이터를 영구적으로 저장하려면 실행 중인 컨테이너 이미지가 아닌 다른 곳에 저장해야 합니다.
각 컨테이너에는 자체 쓰기 가능한 컨테이너 계층이 있고 모든 변경 사항이 이 계층에 저장되기 때문에 여러 컨테이너가 동일한 기본 이미지에 대한 액세스를 공유하면서도 자체 데이터 상태를 가질 수 있습니다.
이 다이어그램은 동일한 Ubuntu 15.04 이미지를 공유하는 여러 컨테이너를 보여줍니다. 각 레이어는 이전 레이어와의 차이점 집합 일 뿐이므로 더 작은 이미지를 얻을 수 있습니다. 예를 들어 기본 애플리케이션 이미지는 200MB이지만 다음 포인트 릴리스와의 차이는 200KB에 불과할 수 있습니다. 컨테이너를 만들 때 전체 이미지를 복사하는 대신 차이만 있는 레이어를 만듭니다. 컨테이너를 실행하면 컨테이너 런타임이 필요한 레이어를 가져옵니다. 업데이트할 때 차이만 복사하면 됩니다. 이것은 새로운 가상 머신을 실행하는 것보다 훨씬 빠릅니다.
공개적으로 사용 가능한 오픈 소스 컨테이너 이미지를 자체 이미지의 기반으로 사용하거나 수정하지 않은 용도로 사용하는 것은 매우 일반적입니다. 예를 들어 컨테이너 내부에 Ubuntu Linux 환경을 제공하는 'ubuntu'컨테이너 이미지를 이미 보았습니다. "Alpine"은 컨테이너에서 널리 사용되는 Linux 환경으로 매우 작습니다. nginx 웹 서버는 컨테이너 패키징에 자주 사용됩니다.
Google은 컨테이너 레지스트리 gcr.io를 유지합니다. 이 레지스트리에는 많은 공개, 오픈 소스 이미지가 포함되어 있으며 Google Cloud 고객도 이를 사용하여 Cloud IAM과 통합되는 방식으로 비공개 이미지를 저장합니다. Google Container Registry는 Cloud IAM과 통합되므로 예를 들어 공개되지 않은 이미지를 저장하는 데 사용할 수 있습니다. 대신 프로젝트에 비공개로 설정됩니다. Docker Hub Registry, GitLab 등 다른 공용 리포지토리에서도 컨테이너 이미지를 찾을 수 있습니다.
오픈 소스 docker 명령은 자체 컨테이너 이미지를 빌드하는 데 널리 사용되는 방법입니다. 널리 알려져 있고 널리 사용 가능합니다. docker 명령으로 컨테이너를 빌드할 때의 한 가지 단점은 빌드를 수행하는 컴퓨터를 신뢰해야 한다는 것입니다.
Google은 Cloud IAM과 통합된 컨테이너를 구축하기 위한 관리형 서비스를 제공합니다. 이 서비스를 Cloud Build라고 하며이 과정에서 사용합니다.
Cloud Build는 Cloud Source Repositories, Cloud Storage (GCP의 객체 저장소 서비스) 또는 GitHub 및 Bitbucket과 같은 git 호환 저장소와 같은 다양한 저장소 위치에서 빌드의 소스 코드를 검색할 수 있습니다. Cloud Build로 빌드를 생성하려면 일련의 단계를 정의합니다.
예를 들어 종속성을 가져오고, 소스 코드를 컴파일하고, 통합 테스트를 실행하나, Docker, Gradle 및 Maven과 같은 도구를 사용하도록 빌드 단계를 구성할 수 있습니다. Cloud Build의 각 빌드 단계는 Docker 컨테이너에서 실행됩니다. 그러면 Cloud Build가 새로 빌드된 이미지를 GKE뿐만 아니라 App Engine 및 Cloud Functions와 같은 다양한 실행 환경에 제공할 수 있습니다.
2. Introduction to Kubernetes
컨테이너가 매우 얇기 때문에 동료들은 이전에 보유한 가상 머신 수를 훨씬 초과하는 수로 컨테이너를 만들고 있습니다. 그리고 여기에서 실행되는 애플리케이션은 네트워크를 통해 통신해야 하지만 컨테이너가 서로를 찾을 수 있도록 하는 네트워크 패브릭이 없습니다.
도움이 필요합니다. 컨테이너 인프라를 어떻게 더 잘 관리할 수 있을까요? Kubernetes는 온 프레미스 또는 클라우드에서 컨테이너 인프라를 오케스트레이션 하고 관리하는 데 도움이 되는 오픈 소스 플랫폼입니다.
그렇다면 Kubernetes는 무엇입니까? 컨테이너 중심의 관리 환경입니다. 컨테이너화 된 애플리케이션의 배포, 확장, 로드 밸런싱, 로깅, 모니터링 및 기타 관리 기능을 자동화합니다. 이는 일반적인 서비스로서의 플랫폼 솔루션의 특징입니다. Kubernetes는 또한 광범위한 사용자 기본 설정 및 구성 유연성을 허용하는 등 서비스로서의 인프라의 기능을 용이하게 합니다.
Kubernetes는 선언적 구성을 지원합니다. 인프라를 선언적으로 관리할 때 원하는 상태를 달성하기 위해 일련의 명령을 실행하는 대신 달성하려는 원하는 상태를 설명합니다. Kubernetes의 역할은 배포된 시스템을 원하는 상태에 맞게 만들고 장애가 발생하더라도 그대로 유지하는 것입니다. 선언적 구성은 작업을 절약합니다. 시스템의 원하는 상태가 항상 문서화되기 때문에 오류 위험도 줄어듭니다.
Kubernetes는 또한 시스템 상태를 변경하는 명령을 실행하는 명령형 구성을 허용합니다. Kubernetes의 주요 강점 중 하나는 사용자가 선언한 상태로 시스템을 자동으로 유지하는 기능입니다. 숙련된 Kubernetes 관리자는 빠른 임시 수정 및 선언적 구성 구축 도구로만 명령형 구성을 사용합니다.
Kubernetes가 무엇인지 알았으니 이제 몇 가지 기능에 대해 이야기해 보겠습니다.
Kubernetes는 다양한 워크로드 유형을 지원합니다. Nginx 또는 Apache 웹 서버와 같은 상태 비 저장 애플리케이션과 사용자 및 세션 데이터를 지속적으로 저장할 수 있는 상태 저장 애플리케이션을 지원합니다. 또한 배치 작업 및 데몬 작업을 지원합니다.
Kubernetes는 리소스 사용률에 따라 컨테이너화 된 애플리케이션을 자동으로 확장 및 축소할 수 있습니다. 워크로드에 대한 리소스 요청 수준과 리소스 제한을 지정할 수 있으며 Kubernetes는 이를 준수합니다. 이러한 리소스 제어를 통해 Kubernetes는 클러스터 내의 전체 워크로드 성능을 향상할 수 있습니다.
개발자는 풍부한 플러그인 및 애드온 에코 시스템을 통해 Kubernetes를 확장합니다. 또한 Kubernetes는 오픈 소스이기 때문에 온 프레미스 또는 GCP와 같은 여러 클라우드 서비스 제공 업체에서 작업 부하 이동성을 지원합니다. 이를 통해 Kubernetes를 어디에나 배포할 수 있습니다. 벤더 종속 없이 Kubernetes 워크로드를 자유롭게 이동할 수 있습니다.
3. Introduction to Google Kubernetes Engine
GCP는 Google Kubernetes Engine이라는 관리 형 Kubernetes 솔루션을 제공합니다.
Google Kubernetes Engine은 Google 인프라의 관리형 Kubernetes 서비스입니다. GKE는 GCP에서 컨테이너화 된 애플리케이션을 위한 Kubernetes 환경을 배포, 관리, 확장하는 데 도움이 됩니다. 구체적으로 말하면 GKE는 GCP 컴퓨팅 제품의 구성 요소입니다. Kubernetes 워크로드를 클라우드로 쉽게 가져올 수 있습니다.
GKE는 완전 관리형이므로 기본 리소스를 프로비저닝 할 필요가 없습니다. GKE는 컨테이너 최적화 운영체제를 사용하여 작업 부하를 실행합니다. 이러한 운영 체제는 Google에서 유지 관리하며 최소한의 리소스 공간으로 빠르게 확장할 수 있도록 최적화되어 있습니다.
컨테이너 최적화 OS는 이 과정의 뒷부분에서 설명합니다. GKE를 사용하는 경우 먼저 Kubernetes 시스템을 인스턴스화 하도록 서비스를 지정합니다. 이 시스템을 클러스터라고 합니다. GKE의 자동 업그레이드 기능을 사용 설정하여 클러스터가 항상 안정적인 최신 버전의 Kubernetes로 자동 업그레이드되도록 할 수 있습니다.
GKE 클러스터에서 컨테이너를 호스팅 하는 가상 머신을 노드라고 합니다. GKE의 자동 복구 기능을 사용 설정하면 서비스가 비정상 노드를 대신 복구합니다. 클러스터의 각 노드에서 주기적으로 상태를 확인합니다. 노드가 비정상으로 확인되어 수리가 필요한 경우 GKE는 노드를 드레 이닝 (즉, 작업 부하가 정상적으로 종료됨)하고 노드를 다시 만듭니다. Kubernetes가 워크로드 확장을 지원하는 것처럼 GKE는 클러스터 자체 확장을 지원합니다.
GKE는 또한 Google의 ID 및 액세스 관리와 통합되므로 계정 및 역할 권한을 사용하여 액세스를 제어할 수 있습니다.
Stackdriver는 서비스, 컨테이너, 애플리케이션, 인프라를 모니터링하고 관리하기 위한 Google Cloud의 시스템입니다. GKE는 Stackdriver Monitoring과 통합되어 애플리케이션 성능을 이해하는 데 도움이 됩니다. GKE는 Google Virtual Private Cloud와 통합되며 GCP의 네트워킹 기능을 사용합니다.
마지막으로 GCP Console은 GKE 클러스터 및 해당 리소스에 대한 정보를 제공하고 해당 클러스터의 리소스를 보고, 검사하고, 삭제할 수 있도록 합니다. 오픈 소스 Kubernetes에는 대시 보드가 포함되어 있지만 안전하게 설정하려면 많은 작업이 필요합니다. 하지만 GCP Console은 관리할 필요가 없는 GKE 클러스터 및 작업 부하를 위한 대시 보드이며 Kubernetes 대시 보드보다 강력합니다.
4. Computing options
서비스는 Compute Engine, GKE, App Engine, Cloud Functions입니다. 이 포스팅을 읽으시면 각각을 선택하는 이유를 이해할 수 있습니다.
Compute Engine은 GCP에서 실행되는 가상 머신을 제공합니다. 사전 정의된 VM 구성을 선택할 수 있습니다. 성능 및 비용 요구 사항에 정확히 일치하도록 사용자 정의된 구성을 만들 수도 있습니다. 가상 머신에는 블록 스토리지가 필요합니다. Compute Engine은 영구 디스크와 로컬 SSD의 두 가지 주요 선택 사항을 제공합니다. 영구 디스크는 최대 64TB까지 확장할 수 있는 네트워크 저장소를 제공하며 백업 및 이동을 위해 이러한 디스크의 스냅 샷을 쉽게 만들 수 있습니다. 초당 매우 높은 입력 / 출력 작업을 지원하는 로컬 SSD를 선택할 수도 있습니다.
자동 확장을 지원하는 전역 부하 분산기 뒤에 Compute Engine 작업 부하를 배치할 수 있습니다. Compute Engine은 관리형 인스턴스 그룹이라는 기능을 제공합니다. 이를 통해 수요를 충족하기 위해 자동으로 배포되는 리소스를 정의할 수 있습니다. GCP는 초당 청구를 제공하여 Compute Engine 리소스 비용을 세밀하게 제어할 수 있습니다. 이러한 세분 성은 일괄 처리 작업과 같이 단기간 컴퓨팅 리소스를 배포할 때 비용을 줄이는 데 도움이 됩니다. Compute Engine은 안전하게 중단될 수 있는 작업 부하에 대해 훨씬 저렴한 가격을 제공하는 선점 형 가상 머신을 제공합니다.
그렇다면 사람들은 왜 Compute Engine을 선택합니까? Compute Engine을 사용하면 인프라를 완벽하게 제어할 수 있습니다. 운영 체제를 사용자 정의할 수 있으며 여러 운영 체제에 의존하는 애플리케이션을 실행할 수도 있습니다. 애플리케이션을 다시 작성하거나 변경하지 않고도 온 프레미스 워크로드를 GCP로 쉽게 들어 올리고 이동할 수 있습니다. Compute Engine은 다른 컴퓨팅 옵션이 애플리케이션 또는 요구 사항을 지원하지 않을 때 가장 좋은 옵션입니다.
App Engine은 Compute Engine과 완전히 다른 방향을 가지고 있습니다. App Engine은 완전 관리형 애플리케이션 플랫폼입니다. App Engine을 사용하면 서버 관리와 구성 배포가 필요 없습니다. 따라서 개발자인 경우 배포 부분에 대해 걱정하지 않고 애플리케이션 구축에 집중할 수 있습니다.
개발자인 경우 코드를 업로드하기 만하면 App Engine이 필요한 인프라를 배포합니다. App Engine은 자바, Node.js, Python, PHP, C #,. NET, Ruby, Go와 같은 널리 사용되는 언어를 지원합니다. 컨테이너 워크로드를 실행할 수도 있습니다.
Stackdriver 모니터링, 로깅, 디버깅 및 오류보고와 같은 진단도 App Engine과 긴밀하게 통합됩니다. Stackdriver의 실시간 디버깅 기능을 사용하여 소스 코드를 분석하고 디버깅할 수 있습니다. Stackdriver는 Cloud SDK, Cloud Source Repositories, IntelliJ, Visual Studio, Powershell과 같은 도구와 통합됩니다.
App Engine은 버전 제어 및 트래픽 분할도 지원합니다.
App Engine은 단순히 코드 작성에만 집중해야 하고 매우 안정적이고 확장 가능한 인프라 구축에 대해 걱정할 필요가 없는 경우 좋은 선택입니다. 환경을 배포하고 관리하는 대신 애플리케이션 구축에 집중할 수 있습니다.
App Engine의 사용 사례에는 웹 사이트, 모바일 앱 및 게임 백엔드가 포함되며 인터넷에 RESTful API를 제공하는 방법으로 사용됩니다.
마지막으로 이 과정의 주요 주제는 Google Kubernetes Engine입니다. Kubernetes는 컨테이너의 애플리케이션을 위한 오케스트레이션 시스템이라는 것을 배웠습니다. 배포, 확장, 로드 밸런싱, 로깅 및 모니터링, 기타 관리 기능을 자동화합니다.
Google Kubernetes Engine은 기능을 추가하고 다른 GCP 서비스와 자동으로 통합하여 GCP에서 Kubernetes 관리를 확장합니다. GKE는 클러스터 확장, 영구 디스크, 최신 버전의 Kubernetes를 사용한 자동 업그레이드, 비정상 노드 자동 복구를 지원합니다. Cloud Build, Container Registry, Stackdriver Monitoring, Stackdriver Logging과 기본적으로 통합됩니다.
온 프레미스 클러스터 내에서 실행되는 기존 워크로드를 GCP로 쉽게 이동할 수 있습니다. 공급 업체 종속도 없습니다.
전반적으로 GKE는 컨테이너화 된 애플리케이션, 클라우드 네이티브 분산 시스템, 하이브리드 애플리케이션에 매우 적합합니다. 이 과정에서는 Kubernetes와 GKE에 대해 자세히 설명합니다.
Cloud Functions는 이벤트에 연결된 간단한 단일 목적 함수를 위한 이벤트 기반의 서버리스 컴퓨팅 서비스입니다. Cloud Functions에서는 JavaScript 또는 Python으로 작성된 코드를 업로드하기만 하면 됩니다.
GCP는 해당 코드를 실행하기 위해 적절한 컴퓨팅 용량을 자동으로 배포합니다. 이러한 서버는 자동으로 확장되며 고 가용성 및 내결함성 설계로 배포됩니다. 코드 실행 시간에 대해서만 요금이 부과됩니다. 각 함수에 대해 호출 메모리 및 CPU 사용량은 100 밀리 초 단위로 측정되며 가장 가까운 증분으로 반올림됩니다. Cloud Functions는 영구 무료 등급도 제공하므로 많은 Cloud Function 사용 사례를 무료로 사용할 수 있습니다.
Cloud Functions를 사용하면 이벤트 (예 : 파일이 Google Cloud Storage에 업로드되거나 Cloud Pub / Sub를 통해 수신되는 메시지)를 기반으로 몇 밀리 초 이내에 코드가 트리거 됩니다. Cloud Functions는 사용자가 정의한 HTTP 엔드 포인트와 Firebase 모바일 애플리케이션 백엔드의 이벤트를 기반으로 트리거 될 수도 있습니다.
Cloud Functions는 마이크로 서비스 애플리케이션 아키텍처의 일부로 사용할 수 있습니다. 간단한 서버리스 모바일 또는 IoT 백엔드를 구축하거나 타사 서비스 및 API와 통합할 수도 있습니다. Cloud Storage 버킷에 업로드된 파일은 실시간으로 처리할 수 있습니다. 마찬가지로 쿼리 및 분석을 위해 데이터를 추출, 변환 및 로드할 수 있습니다. GCP 고객은 종종 가상 도우미, 동영상 또는 이미지 분석, 감정 분석과 같은 지능형 애플리케이션의 일부로 Cloud Functions를 사용합니다.
그렇다면 어떤 컴퓨팅 서비스를 채택해야 합니까? 당신이 어디에서 왔는지에 따라 많이 달라집니다. 물리적 서버 하드웨어에서 애플리케이션을 실행하는 경우 Compute Engine으로 이동하기 위한 저항이 가장 적은 경로가 됩니다. 각 VM이 관리되고 유지되는 수명이 긴 가상 머신에서 애플리케이션을 실행하고 있다면 어떨까요? 이 경우 Compute Engine으로 이동하는 것이 애플리케이션을 클라우드로 가져오는 가장 빠른 GCP 서비스라는 것을 알게 될 것입니다. 운영에 대해 전혀 생각하고 싶지 않다면? App Engine과 Cloud Functions는 좋은 선택입니다. 전문 분야 'Google Cloud Platform으로 애플리케이션 개발'에서 App Engine과 Cloud Functions의 차이점에 대해 자세히 알아볼 수 있습니다.
지금까지 이 과정이 소프트웨어 컨테이너가 그토록 유익한 이유를 이해하는 데 도움이 되었기를 바랍니다. 컨테이너화는 애플리케이션을 패키징 하는 가장 효율적이고 이식 가능한 방법입니다. 컨테이너화의 인기는 매우 빠르게 증가하고 있습니다. 실제로 Compute Engine과 App Engine 모두 컨테이너를 시작할 수 있습니다. Compute Engine은 사용자로부터 컨테이너 이미지를 수락하고 이를 포함하는 가상 머신 인스턴스를 시작합니다. Compute Engine 기술을 사용하여 결과 VM을 확장하고 관리할 수 있습니다. 그리고 App Engine 가변형 환경은 사용자로부터 컨테이너 이미지를 수락하고 App Engine이 코드 용으로 제공하는 것과 동일한 무 운영 환경에서 실행합니다.
하지만 App Engine이 제공하는 것보다 컨테이너화 된 작업 부하를 더 많이 제어하고 Compute Engine이 제공하는 것보다 더 밀집된 패킹을 원한다면 어떻게 해야 할까요? 점점 더 많이 사용되는 사용 사례는 GKE가 해결하도록 설계된 것입니다. 컨테이너 오케스트레이션의 Kubernetes 패러다임은 믿을 수 없을 정도로 강력하고 공급 업체 중립적이며 이를 중심으로 광범위하고 활기찬 커뮤니티가 개발되었습니다. Kubernetes를 GCP의 관리 형 서비스로 사용하면 작업이 절약되고 다른 모든 GCP 리소스도 활용할 수 있습니다. 물론 이미 온 프레미스 데이터 센터에서 Kubernetes를 실행하고 있다면 워크로드와 관리 접근 방식을 모두 가져올 수 있으므로 GKE로 전환하는 것이 좋습니다.