이 페이지에서는 Kubernetes 앱 패키징에 대한 요구사항과 이러한 요구사항을 충족하기 위한 가이드라인을 설명합니다.
앱 패키지는 사용자의 Kubernetes 클러스터에 배포되는 컨테이너 이미지 및 구성 파일의 번들입니다. Google Cloud 콘솔에서 Google Kubernetes Engine으로의 앱 배포를 지원하려면 앱 패키지에 배포 컨테이너가 포함되어야 합니다. 배포 컨테이너는 구성 파일을 푸시하고 메타 데이터를 Kubernetes API에 표시합니다.
Google Cloud 사용자는 앱 패키지를 통해 다음을 수행할 수 있습니다.
- Cloud Marketplace 카탈로그에서 앱 탐색
- Google Cloud 콘솔을 사용하여 GKE 또는 GKE Enterprise 클러스터에 앱 배포
- Google Cloud 콘솔을 사용하여 실행 중인 앱과 상호작용합니다.
패키지에는 Google Cloud 콘솔을 통한 배포를 지원하는 것 외에도 사용자가 kubectl 및 Helm과 같은 도구를 사용하여 CLI(명령줄 인터페이스)에서 개발자의 앱을 배포할 수 있는 단계가 패키지에 포함되어 있어야 합니다.
앱 패키지 예는 Google 클릭하여 배포 솔루션을 위한 GitHub 저장소를 참조하세요. 이 저장소에는 WordPress 및 Elasticsearch와 같은 인기 있는 오픈소스 앱을 위한 패키지가 포함되어 있습니다.
시작하기 전에
- Google Cloud 환경을 설정했는지 확인합니다.
- 앱 실행을 위한 구성 파일, 사용자 가이드, 기타 리소스에 대한 공개 Git 저장소를 만듭니다. GitHub나 Cloud Source Repositories와 같은 공급자를 사용하거나 고유 서버에서 저장소를 호스팅할 수 있습니다. 배포하는 각 제품에 대해 전용 저장소를 사용하는 것이 좋습니다.
개요
앱은 다음 요구사항을 충족해야 합니다.
저장소에 대한 오픈소스 라이선스가 포함된 LICENSE 파일이 Git 저장소에 있어야 합니다.
Git 저장소에는 앱을 배포하는 구성 파일이 있어야 합니다. 구성 파일은 Kubernetes YAML 매니페스트 또는 Helm 차트일 수 있습니다.
구성에는 앱을 설명하는 애플리케이션 커스텀 리소스가 포함되어야 합니다.
구성 요구사항을 참조하세요.
앱은 x86 프로세서를 사용하는 노드에서 실행해야 합니다.
선택적으로 앱이 Istio와 호환되도록 하려면 Istio를 실행하는 클러스터의 제한사항을 검토하세요.
앱이 상업용(비BYOL)인 경우 고객에게 요금을 정확하게 청구할 수 있도록 앱의 사용량을 Google에 보고해야 합니다. 사용량 보고를 Google에 전송하는 사용량 기반 청구 에이전트를 앱에 통합하는 것이 좋습니다.
청구 에이전트 통합 요구사항을 참조하세요.
앱의 모든 컨테이너 이미지를 Artifact Registry 또는 Container Registry의 레지스트리에 업로드해야 합니다. 레지스트리에는 사용자가 Google Cloud 콘솔에서 앱을 배포할 때 앱 구성을 Kubernetes API에 푸시하는 deployer 이미지도 레지스트리에 포함되어 있어야 합니다.
앱 이미지 빌드 요구사항을 참조하세요.
앱에 대한 통합 테스트를 포함해야 합니다.
확인 절차 요구사항을 참조하세요.
명령줄에서 앱을 배포하고, 앱을 구성하고, 앱을 사용하기 위한 단계를 사용자 가이드에 포함해야 합니다.
사용자 가이드 요구사항을 참조하세요.
구성 요구사항
구성은 Kubernetes 매니페스트 또는 Helm 차트로 제공할 수 있습니다.
구성은 다음 요구사항을 충족해야 합니다.
불안정한 API로부터 사용자를 보호하려면 베타 또는 일반 공개된 Kubernetes 리소스만 사용하세요.
구성은 애플리케이션 커스텀 리소스를 배포해야 합니다. 애플리케이션 리소스에는 사용자가 Cloud Marketplace UI를 통해 앱을 배포할 때 사용자에게 표시되는 정보가 포함되어 있습니다.
애플리케이션 리소스는 앱과 연관된 Kubernetes 구성요소를 집계하고 사용자가 이러한 리소스를 하나의 그룹으로 관리할 수 있게 해주는 커스텀 리소스입니다.
애플리케이션 리소스를 만드는 방법 및 예제는 애플리케이션 GitHub 저장소를 참조하세요.
구성은
envsubst을 사용하거나 플래그로 대체할 수 있는 매개변수를 사용해야 합니다.다음 매개변수를 대체할 수 있어야 합니다.
네임스페이스: 모든 구성 리소스는 단일 네임스페이스에 속해야 합니다. Cloud Marketplace 사용자는 앱을 배포할 때 이 네임스페이스를 구성합니다. 지정한 리소스가 사용자가 선택한 네임스페이스에 만들어지도록 매니페스트에 네임스페이스를 하드 코딩하지 마세요. 네임스페이스는 경우에 따라
RoleBinding에서ServiceAccount을 참조할 때와 같이 리소스 정의 내부에도 표시됩니다. 이러한 모든 참조는 매개변수화되어야 합니다.앱 이름: 애플리케이션 리소스의 인스턴스 이름입니다. 앱의 여러 인스턴스가 단일 네임스페이스에 배포된 경우 이름 충돌을 방지하기 위해 이 문자열을 각 앱 리소스의 이름에 포함해야 합니다.
컨테이너 이미지:
PodSpec와 같은 모든 이미지 참조는 대체 가능해야 합니다. 그러면 Cloud Marketplace가 이러한 참조를 재정의하여 Artifact Registry에 게시된 이미지를 가리킬 수 있습니다. 또한 고객이 수정된 이미지를 대체할 수 있습니다.라이선스 보안 비밀: 앱이 상업용 측정을 수행하는 경우 보안 비밀 리소스 이름을 매개변수로 수락해야 합니다. 보안 비밀에는 앱이 Google에 사용량 데이터를 전송하기 위해 사용하는 사용량 보고 사용자 인증 정보가 포함되어 있습니다.
GitHub의 구성 매개변수에 대해 자세히 알아보세요.
클라이언트 측 도구를 사용하여 앱을 배포할 수 있어야 합니다. 예를 들어 Helm을 사용하는 경우 배치는
--client-only명령줄 플래그와 함께 작동해야 합니다.
Istio를 사용하는 클러스터의 제한 사항
앱이 Istio와 호환되도록 하려면 이 섹션에 설명된 제한 사항을 검토하세요. Istio 개요는 Istio란 무엇인가요?을 참조하세요.
고객이 클러스터에서 Istio를 실행할 경우, Istio는 기본적으로 앱 Pod 간 네트워크 트래픽을 제어합니다. 다음과 같은 경우 네트워크 통신이 차단될 수 있습니다.
Pod가 클러스터의 IP 주소를 사용하는
kubectl명령어를 실행할 경우, 명령어가 실패할 수 있습니다.앱이 Pod 간 통신 또는 IP 기반 통신을 사용할 경우, 클러스터 형성 단계가 실패할 수 있습니다.
OS 패키지 저장소와 같은 타사 서비스에 대한 외부 연결이 차단될 수도 있습니다. 외부 서비스에 대한 액세스를 사용 설정하려면 고객이 Istio 이그레스 트래픽을 구성해야 합니다.
LoadBalancer 또는 인그레스 리소스 대신 Istio 게이트웨이를 사용하여 수신 연결을 구성하는 것이 좋습니다.
구성에 Helm을 사용하는 경우 배포 이미지의 스키마에서 x-google-marketplace ISTIO_ENABLED 속성을 사용하세요. 이 속성이 true인 경우, 배포자는 배포를 수정해야 합니다(예: Istio 사이드카 준비 대기).
고객의 앱 Pod 간 통신 설정을 지원하려면 문서의 배포 후 섹션에 관련 단계를 추가하는 것이 좋습니다.
청구 에이전트 통합 요구사항
상업용 앱을 판매하는 경우, 앱을 UBB(사용량 기반 결제) 에이전트와 통합하는 것이 좋습니다.
이 에이전트는 Google의 사용량 보고 엔드포인트인 Service Control에 대한 인증 및 보고를 처리합니다. 가격 책정 모델을 제출하면, Cloud Marketplace팀이 앱의 보고 대상 서비스를 만들고 사용량 측정을 위한 청구 측정항목을 만듭니다.
이 에이전트는 또한 로컬 집계, 장애 복구, 재시도를 관리합니다. 사용 시간 측정을 위해서는 하트비트를 자동으로 보고하도록 에이전트를 구성할 수 있습니다.
또한 에이전트는 보고 상태를 노출하기 때문에 에이전트가 사용량 데이터를 성공적으로 보고하고 있는지를 앱에서 감지할 수 있습니다.
고객은 Cloud Marketplace에서 앱을 구매하여 배포 시 앱에 첨부된 라이선스를 얻습니다.
청구 에이전트와 통합할 때는 사용량 보고가 실패할 때의 앱 작동 방식을 고려하세요. 다음 중 하나에 해당할 수 있습니다.
고객이 구독을 취소했습니다.
고객이 보고 채널을 실수로 사용 중지한 경우. 예를 들어 고객이 에이전트를 실수로 삭제하거나 잘못 구성할 수 있고, 네트워크에서 에이전트가 Google의 보고 엔드포인트에 액세스하는 것을 차단할 수도 있습니다.
권장사항에 따라 사용량을 보고하고 Google에서 사용량 데이터를 받지 못하고 고객에게 비용이 청구되지 않는 경우를 처리합니다.
청구 에이전트 통합
앱과 동일한 pod에서 실행되는 사이드카 컨테이너 또는 SDK를 사용하여 에이전트를 통합할 수 있습니다.
사이드카 방식에서는 에이전트가 앱 컨테이너와 동일한 Kubernetes 포드에서 자체 컨테이너로 실행됩니다. 앱은 에이전트의 로컬 REST 인터페이스와 통신합니다.
SDK 방식에서는 에이전트를 앱 바이너리에 컴파일하거나 연결되어 있어야 합니다. SDK는 기본적으로 Go용으로 구현되며, Python용 결합을 포함합니다.
일반적으로 사이드카 방식은 통합 작업이 덜 복잡하고, SDK는 실수로 인한 사용 중지 상황에 보다 안정적입니다.
자세한 통합 단계는 사용량 기반 청구 에이전트 GitHub 저장소의 README를 참조하세요. 샘플 구현을 보려면 앱 및 도구 저장소의 예시를 참조하세요.
사용량 보고를 위한 사용자 인증 정보
청구 에이전트는 사용량 보고를 Google에 전송할 수 있게 해주는 사용자 인증 정보가 필요합니다. Cloud Marketplace는 사용자가 Cloud Marketplace에서 앱을 배포할 때 이러한 사용자 인증 정보를 생성하고, 앱이 배포되기 전에 사용자 인증 정보가 대상 Kubernetes 네임스페이스에서 Secret 상태로 유지되도록 보장합니다.
이 보안 비밀의 이름은 앱에 REPORTING_SECRET 스키마 속성으로 전달됩니다.
보고 보안 비밀을 사용하는 매니페스트 예는 GitHub의 WordPress 앱 예를 참조하세요.
보안 비밀에는 다음 필드가 포함됩니다.
|
고객의 소프트웨어 구입 및 사용 동의를 나타내는 식별자입니다. |
|
사용량 보고서와 함께 Google Service Control에 전달되는 사용 자격과 연관된 식별자입니다. |
|
Google Service Control에 인증하는 데 사용되는 Google Cloud Service 계정 JSON 키입니다. |
제품이 앱 외에 SaaS 구성요소를 제공하는 경우, SaaS 구성 요소가 Cloud Marketplace Procurement 서비스를 사용하여 자격 ID의 유효성을 주기적으로 확인하도록 선택적으로 지정할 수 있습니다. Procurement 서비스에 액세스하려면 파트너 엔지니어에게 문의하세요.
앱에 전달되는 다른 매개변수에 대한 자세한 내용은 이 섹션의 뒷부분에 있는 앱에 전달된 매개변수를 참조하세요.
컨테이너 이미지 빌드 요구사항
앱은 하나 이상의 앱 컨테이너 이미지로 구성됩니다. 또한 저장소에는 고객이 Cloud Marketplace UI에서 앱을 배포할 때 사용되는 배포 컨테이너가 포함되어야 합니다.
컨테이너 이미지는 일반적으로 Dockerfile 및 docker
build 명령줄 도구를 사용하여 빌드됩니다. Dockerfile 및 컨테이너 빌드 지침은 앱의 공개 저장소에 게시하는 것이 좋습니다. 이를 게시하면 고객이 이미지를 수정하거나 다시 작성할 수 있으며 때로는 엔터프라이즈 프로덕션 환경의 이미지를 인증해야 합니다.
앱 이미지가 Debian과 같은 기본 이미지 또는 Python 또는 OpenJDK와 같은 언어 런타임 이미지에 의존하는 경우 Cloud Marketplace의 인증 컨테이너 이미지 중 하나를 사용하는 것이 좋습니다. 이렇게 하면 보안 패치 등과 같이 기본 이미지에 대한 업데이트가 적시에 수행되도록 보장할 수 있습니다.
앱 이미지를 빌드한 후에는 환경을 설정할 때 Artifact Registry 또는 Container Registry에서 만든 스테이징 레지스트리에 이미지를 푸시합니다.
Artifact Registry 또는 Container Registry 저장소는 구조가 다음과 같아야 합니다.
앱의 기본 이미지는 저장소의 루트에 있어야 합니다. 예를 들어 Artifact Registry 또는 Container Registry 저장소가
gcr.io/exampleproject/exampleapp인 경우 앱의 이미지는gcr.io/exampleproject/exampleapp에 있어야 합니다.배치 컨테이너의 이미지는
deployer이라는 폴더에 있어야 합니다. 위의 예시에서 배치 이미지는gcr.io/exampleproject/exampleapp/deployer에 있어야 합니다.앱에서 추가 컨테이너 이미지를 사용하는 경우 각 추가 이미지는 기본 이미지 아래의 자체 폴더에 있어야 합니다. 예를 들어 앱에
proxy이미지가 필요한 경우 이미지를gcr.io/exampleproject/exampleapp/proxy에 추가합니다.앱의 모든 이미지에는 출시 트랙과 현재 버전으로 태그가 지정되어야 합니다. 예를 들어
2.0출시 트랙에서2.0.5버전을 출시하는 경우 모든 이미지에2.0및2.0.5태그가 지정되어야 합니다. 출시 구성에 대해 알아보기.
예를 들어 다음 이미지는 Grafana Cluster Kubernetes 앱의 Artifact Registry 및 Container Registry 저장소를 보여줍니다. 출시 트랙은 5.3이며 앱에는 기본 앱 이미지, 자체 폴더의 배포자 이미지, debian9의 Debian 9 이미지가 포함되어 있습니다. 저장소의 모든 이미지에는 동일한 트랙 5.3 및 해당 트랙의 버전 5.3.4로 태그가 지정됩니다. 또한 배포자에 선언된 대로 애플리케이션 리소스에 대한 커스텀 리소스 정의(CRD)의 '버전' 필드와 일치해야 합니다.
저장소는 gcr.io/cloud-marketplace/google/grafana에 있습니다.
제품 식별자를 선택할 때 이전에 선택한 컨테이너 이미지 식별자를 사용합니다.
이미지를 Artifact Registry 또는 Container Registry에 업로드하려면 레지스트리 이름으로 태그를 지정한 다음 gcloud을 사용하여 이미지를 푸시합니다. 예를 들어 다음 명령어를 사용하여 example-pro의 이미지를 푸시합니다.
docker build -t gcr.io/my-project/example-pro:4.0 # release track 4.0
docker tag gcr.io/my-project/example-pro:4.0 gcr.io/my-project/example-pro:4.0.3 # release version 4.0.3
docker push gcr.io/my-project/example-pro:4.0
docker push gcr.io/my-project/example-pro:4.0.3
이미지를 태그 지정하고 레지스트리에 푸시하기 위한 자세한 단계는 Artifact Registry 또는 Container Registry 문서의 관련 문서를 참고하세요.
배포 컨테이너 요구사항
배포 컨테이너(또는 배포자)는 고객이 Cloud Marketplace에서 제품을 배포할 때 사용됩니다. 배포자 이미지는 앱의 Kubernetes 구성 및 클라이언트 도구(예: kubectl 또는 Helm)를 패키징합니다. 이 도구는 Kubernetes API로 구성을 푸시합니다. 배포자는 일반적으로 사용자가 앱을 배포할 때 실행하는 것과 동일한 명령줄 명령어 모음을 사용해야 합니다.
배포자를 만들려면 도구 저장소의 marketplace 디렉토리에서 배포 컨테이너의 기본 이미지 중 하나를 사용합니다.
- 구성에
kubectl을 사용하는 경우 kubectl 기본 이미지를 사용합니다. - 구성에 Helm 차트를 사용하는 경우 Helm 기본 이미지를 사용합니다.
기본 이미지에는 소유자 참조 지정, 비밀번호 생성, 배포 후 삭제와 같은 작업에 필요한 기본 제공 유틸리티가 있습니다.
배포자 이미지 빌드를 위한 단계는 애플리케이션 배포자 빌드를 참조하세요.
앱에 전달되는 매개변수
배포 컨테이너는 고객이 개발자의 앱을 선택할 때 고객으로부터 수집해야 하는 매개변수를 선언해야 합니다. 그런 다음 이러한 매개변수는 사용자가 앱을 배포할 때 배포 컨테이너에 제공됩니다.
이러한 매개변수를 구성하려면 배포 컨테이너 이미지에 YAML 형식의 JSON 스키마(경로: /data/schema.yaml)가 포함되어 있어야 합니다.
schema.yaml 만드는 방법을 배우려면 배포자 스키마를 참조하세요.
GPU 클러스터 요청
앱에 특정 GPU 요구사항이 있거나 GPU가 많이 사용되는 경우 배포자 스키마를 사용하여 클러스터의 GPU 유형과 수를 지정할 수 있습니다. GPU 요구 사항을 지정하면 지원 클러스터 생성이 중지됩니다.
앱에서 일반 Nvidia GPU 또는 특정 Nvidia 플랫폼을 요청할 수 있습니다.
검증 프로세스 요구사항
앱은 인증 시스템에서 실행되어 다음을 보장합니다.
- 설치 성공: 모든 리소스가 적용되고 정상 상태가 되기를 기다립니다.
- 기능 테스트 통과: 배포자는 테스터 포드를 시작하고 종료 상태를 감시합니다. 0은 성공을, 0이 아닌 것은 실패를 의미합니다.
- 제거 성공: 앱 및 모든 리소스가 클러스터에서 성공적으로 제거되었습니다.
앱을 Google Cloud Marketplace에 게시하려면 성공적인 결과가 필요합니다.
이러한 기능을 패키징, 실행 및 확인하는 방법에 대한 자세한 내용은 확인 통합에 대한 문서를 따르세요.
사용자 가이드 요구사항
사용자 가이드에는 다음 정보가 포함되어야 합니다.
개요
- 기본 기능 및 구성 옵션이 포함된 일반 앱 개요 이 섹션은 또한 Cloud Marketplace에 게시된 제품에 연결되어야 합니다.
1회 설정
kubectl또는 Helm과 같은 클라이언트 구성 도구(해당되는 경우)- 클러스터가 애플리케이션 리소스를 관리할 수 있도록 애플리케이션 CRD(CustomResourceDefinition) 설치
- 상업용 앱을 판매하는 경우 Cloud Marketplace에서 라이선스 보안 비밀을 획득하고 배포하는 단계
설치
- 앱 배포를 위한 명령어
- UI 구성에서 사용 가능한 매개변수 전달
- 변경 불가능한 다이제스트에 대한 이미지 참조 고정
배포자 스키마에 커스텀 입력 필드를 추가하는 경우 예상 값에 대한 정보를 추가합니다.(해당되는 경우)
기본 사용
- 관리 콘솔에 연결(해당되는 경우)
- 클라이언트 도구 연결 및 샘플 명령어 실행(해당되는 경우)
- 사용자 이름 및 비밀번호 수정
- 수신 사용 설정 및 TLS 인증서 설치(해당되는 경우)
백업 및 복원
- 앱 상태 백업
- 백업에서 앱 상태 복원
이미지 업데이트
- 패치 및 소규모 업데이트를 위한 앱 이미지 업데이트
확장
- 앱 확장(해당되는 경우)
삭제
- 앱 삭제
- PersistentVolumeClaims와 같이 의도적으로 분리되었을 수 있는 모든 리소스 삭제