에 대한 컨테이너 기반 제품 요구 사항 AWS Marketplace - AWS Marketplace

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에 대한 컨테이너 기반 제품 요구 사항 AWS Marketplace

AWS Marketplace 는 의 모든 컨테이너 기반 제품 및 제품에 대해 다음 요구 사항을 유지합니다 AWS Marketplace. 이러한 요구 사항은 고객을 위해 안전하고 신뢰할 수 있는 디지털 카탈로그를 홍보하는 데 도움이 됩니다. 또한 판매자는 특정 제품의 요구 사항을 충족할 수 있도록 추가 컨트롤 및 프로토콜 구현을 검토하는 것이 좋습니다.

모든 제품 및 관련 메타데이터는 제출 시 검토되어 현재 AWS Marketplace 요구 사항을 충족하거나 초과하는지 확인합니다. 진화하는 보안 및 기타 사용 요구 사항을 충족하기 위해 이러한 정책을 검토하고 조정합니다. 는 기존 제품이 이러한 요구 사항에 대한 변경 사항을 계속 충족하는지 AWS Marketplace 지속적으로 확인합니다. 제품이 규정 준수를 벗어나는 경우 AWS Marketplace 에서 제품을 업데이트하기 위해 연락을 드릴 것입니다. 경우에 따라 문제가 해결될 때까지 새 구독자가 제품을 일시적으로 사용할 수 없게 될 수 있습니다.

보안 요구 사항

모든 컨테이너 기반 제품은 다음과 같은 보안 요구 사항을 준수해야 합니다.

  • Docker 컨테이너 이미지에는 알려진 맬웨어, 바이러스 또는 취약성이 없어야 합니다. 컨테이너 제품에 새 버전을 추가하면 해당 버전에 포함된 컨테이너 이미지가 스캔됩니다.

  • 컨테이너 기반 제품에 AWS 리소스 관리에 대한 액세스가 필요한 경우 사용자에게 액세스 키를 요청하는 대신 IAM 서비스 계정의 역할(Amazon Elastic Kubernetes Service(Amazon EKS)를 통해 실행되는 경우) 또는 IAM 작업의 역할(Amazon Elastic Container Service(Amazon ECS)을 통해 실행되는 경우)을 통해 액세스해야 합니다.

  • 컨테이너 기반 제품을 실행하려면 최소 권한만 있으면 됩니다. 자세한 내용은 ECS 보안EKS 보안 섹션을 참조하세요.

  • 컨테이너 이미지는 기본적으로 루트가 아닌 권한으로 실행되도록 구성해야 합니다.

액세스 요구 사항

모든 컨테이너 기반 제품은 다음과 같은 액세스 요구 사항을 준수해야 합니다.

  • 컨테이너 기반 제품은 초기 무작위 암호를 사용해야 합니다. 컨테이너 기반 제품은 외부 관리 액세스(예: 웹 인터페이스를 통해 애플리케이션에 로그인)에 초기 고정 암호 또는 빈 암호를 사용하면 안 됩니다. 구매자는 이 무작위 암호를 입력해야만 보안 인증 정보를 설정하거나 변경할 수 있습니다.

  • 애플리케이션에 대한 모든 외부 액세스는 고객이 명시적으로 동의하고 활성화해야 합니다.

고객 정보 요구 사항

모든 컨테이너 기반 제품은 다음과 같은 고객 정보 요구 사항을 준수해야 합니다.

  • 소프트웨어는 BYOL (자신의 라이선스 가져오기)에서 요구하는 경우를 제외하고 고객의 인지 및 명시적 동의 없이 고객 데이터를 수집하거나 내보내서는 안 됩니다. 고객 데이터를 수집하거나 내보내는 애플리케이션은 다음 지침을 준수해야 합니다.

    • 고객 데이터 수집은 셀프 서비스이고, 자동화되고, 안전해야 합니다. 구매자는 판매자가 소프트웨어 배포를 승인할 때까지 기다릴 필요가 없어야 합니다.

    • 고객 데이터에 대한 요구 사항은 목록의 설명 또는 사용 지침에 명확하게 명시되어야 합니다. 여기에는 수집되는 데이터, 고객 데이터가 저장되는 위치 및 사용 방법이 포함됩니다. 예: 이 제품은 사용자의 이름과 이메일 주소를 수집합니다. 이 정보는 <회사 이름>에서 전송하고 저장합니다. 이 정보는 <제품 이름> 제품과 관련하여 구매자에게 연락하는 용도로만 사용됩니다.

    • 결제 정보를 수집하면 안 됩니다.

제품 사용 요구 사항

모든 컨테이너 기반 제품은 다음과 같은 제품 사용 요구 사항을 준수해야 합니다.

  • 판매자는 완전히 작동하는 제품만 등록할 수 있습니다. 시험 또는 평가 목적의 베타 또는 프리릴리스 제품은 허용되지 않습니다. 상용 소프트웨어의 개발자, 커뮤니티 및 BYOL 에디션은 판매자가 무료 에디션 제공 후 90일 AWS Marketplace 이내에 에 동등한 유료 버전을 제공하는 경우 지원됩니다.

  • 모든 컨테이너 기반 제품의 사용 지침에는 컨테이너 기반 제품을 배포하는 모든 단계가 포함되어야 합니다. AWS Marketplace의 해당 컨테이너 이미지를 가리키는 명령 및 배포 리소스를 사용 지침에서 제공해야 합니다.

  • 컨테이너 기반 제품에는 구독자가 소프트웨어를 사용하는 데 필요한 모든 컨테이너 이미지가 포함되어야 합니다. 또한 컨테이너 기반 제품은 사용자가 외부의 이미지 AWS Marketplace (예: 타사 리포지토리의 컨테이너 이미지)를 사용하여 제품을 시작할 필요가 없어야 합니다.

  • 컨테이너와 해당 소프트웨어는 셀프 서비스 방식으로 배포할 수 있어야 하며 추가 결제 방법이나 비용이 필요 없어야 합니다. 배포 시 외부 종속성이 필요한 애플리케이션은 다음 지침을 준수해야 합니다.

    • 요구 사항은 목록의 설명 또는 사용 지침에 명시되어야 합니다. 예: 이 제품을 올바르게 배포하려면 인터넷 연결이 필요합니다. 배포 시 <패키지 목록> 패키지가 다운로드됩니다.

    • 판매자는 모든 외부 종속성의 사용과 가용성 및 보안에 대한 책임이 있습니다.

    • 외부 종속성을 더 이상 사용할 수 없는 경우 제품 AWS Marketplace 도 에서 제거해야 합니다.

    • 외부 종속성은 추가 결제 방법이나 비용이 필요 없어야 합니다.

  • 외부 또는 판매자APIs나 제3자가 AWS 서비스 관리하는 등 구매자의 직접 통제를 받지 않는 외부 리소스에 대한 지속적인 연결이 필요한 컨테이너는 다음 지침을 따라야 합니다.

    • 요구 사항은 목록의 설명 또는 사용 지침에 명시되어야 합니다. 예: 이 제품은 지속적인 인터넷 연결이 필요합니다. 정상적으로 작동하려면 <리소스 목록>과 같은 지속적인 외부 서비스가 필요합니다.

    • 판매자는 모든 외부 리소스의 사용과 가용성 및 보안에 대한 책임이 있습니다.

    • 외부 리소스를 더 이상 사용할 수 없는 경우 제품 AWS Marketplace 도 에서 제거해야 합니다.

    • 외부 리소스는 추가 결제 방법이나 비용이 필요 없어야 하며 연결 설정이 자동화되어야 합니다.

  • AWS Marketplace에서 사용할 수 없는 업셀 서비스, 추가 제품 또는 다른 클라우드 플랫폼으로 사용자를 유도하는 언어가 제품 소프트웨어 및 메타데이터에 포함되면 안 됩니다.

  • 제품이 다른 제품 또는 다른 ISV의 제품에 대한 추가 기능인 경우 제품 설명에 다른 제품의 기능을 확장하고 제품이 없으면 제품의 유틸리티가 매우 제한적이라는 내용이 표시되어야 합니다. 예: 이 제품은 <제품 이름>의 기능을 확장하며, <제품 이름> 제품이 없으면 이 제품의 유용성이 매우 제한됩니다. 이 목록의 모든 기능을 사용하려면 <제품 이름>의 자체 라이선스가 필요할 수 있습니다.

아키텍처 요구 사항

모든 컨테이너 기반 제품은 다음과 같은 아키텍처 요구 사항을 준수해야 합니다.

  • 에 대한 소스 컨테이너 이미지는 가 소유한 Amazon Elastic Container Registry(AmazonECR) 리포지토리로 푸시 AWS Marketplace 해야 합니다 AWS Marketplace. 컨테이너 제품 목록마다 AWS Marketplace Management Portal 의 서버 제품 아래에서 이러한 리포지토리를 생성할 수 있습니다.

  • 컨테이너 이미지는 Linux 기반이어야 합니다.

  • 유료 컨테이너 기반 제품은 Amazon ECS, Amazon 또는 EKS에 배포할 수 있어야 합니다AWS Fargate.

  • 계약 요금과 와의 통합이 적용된 유료 컨테이너 기반 제품은 Amazon EKS, Amazon ECS, AWS Fargate Amazon EKS Anywhere, Amazon ECS Anywhere, Red Hat OpenShift Service on AWS (ROSA), 자체 관리형 온프레미스 Kubernetes 클러스터 또는 Amazon Elastic Compute Cloud에 배포 AWS License Manager 해야 합니다.

컨테이너 제품 사용 지침

컨테이너 제품에 대한 사용 지침을 생성할 때에는 에 대한 제품 사용 지침 생성 AMI 및 컨테이너 AWS Marketplace의 단계와 지침을 따릅니다.

Amazon EKS 추가 기능 제품에 대한 요구 사항

Amazon EKS 추가 기능은 에 운영 기능을 제공하는 소프트웨어입니다.Kubernetes 애플리케이션에만 해당되지는 않습니다. 예를 들어 Amazon EKS 추가 기능에는 관측성 에이전트 또는 Kubernetes 클러스터가 네트워킹, 컴퓨팅 및 스토리지를 위한 기본 AWS 리소스와 상호 작용할 수 있도록 허용하는 드라이버입니다.

컨테이너 제품의 판매자는 Amazon 를 포함한 여러 배포 옵션 중에서 선택할 수 있습니다EKS. Amazon AWS Marketplace 추가 기능 카탈로그에 EKS 추가 기능으로 제품 버전을 게시할 수 있습니다. 추가 기능은 AWS 및 다른 공급업체가 유지 관리하는 추가 기능 옆에 Amazon EKS 콘솔에 나타납니다. 구매자는 다른 추가 기능과 마찬가지로 소프트웨어를 추가 기능으로 쉽게 배포할 수 있습니다.

자세한 내용은 Amazon 사용 설명서의 Amazon EKS 추가 기능을 참조하세요. EKS

컨테이너 제품을 AWS Marketplace 추가 기능으로 준비

컨테이너 제품을 AWS Marketplace 추가 기능으로 게시하려면 다음 요구 사항을 충족해야 합니다.

  • 컨테이너 제품은 에 게시되어야 합니다 AWS Marketplace.

  • 컨테이너 제품은 AMD64 및 ARM64 아키텍처와 호환되도록 구축되어야 합니다.

  • 컨테이너 제품은 Bring Your Own License(BYOL) 요금 모델 을 사용해서는 안 됩니다.

    참고

    BYOL 는 Amazon EKS 추가 기능 전송에 지원되지 않습니다.

  • 모든 컨테이너 이미지 푸시 및 Helm 는 AWS Marketplace 관리형 Amazon 리포지토리로 차트를 ECR 만듭니다. 이 요구 사항에는 와 같은 오픈 소스 이미지가 포함됩니다nginx. 이미지 및 차트는 Amazon ECR Public Gallery ,Docker Hub, 및 Quay.

  • Helm 차트 - 를 통해 배포할 소프트웨어 준비 Helm 차트. Amazon EKS 추가 기능 프레임워크는 Helm 매니페스트에 차트를 추가합니다. 약간 Helm Amazon EKS 시스템에서는 기능이 지원되지 않습니다. 다음 목록은 온보딩 전에 충족해야 하는 요구 사항을 설명합니다. 이 목록에서 Helm 명령 사용 Helm 버전 3.8.1:

    • 에 대한 경우를 제외하고 모든 Capabilities 객체가 지원됩니다.APIVersions. .APIVersions는 non-built-in 사용자 지정에 대해 지원되지 않습니다.Kubernetes APIs.

    • Release.NameRelease.Namespace 객체만 지원됩니다.

    • Helm 후크와 lookup 함수는 지원되지 않습니다.

    • 모든 종속 차트는 기본 차트 내에 있어야 합니다.Helm 차트(리포지토리 경로 file://...로 지정).

    • 는 Helm 차트가 성공적으로 전달되어야 합니다.Helm 보풀 및 Helm 오류가 없는 템플릿입니다. 명령은 다음과 같습니다.

      • Helm 보풀 - helm lint helm-chart

        일반적인 문제에는 상위 차트의 메타데이터에 선언되지 않은 차트가 포함됩니다. 예제: chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed

      • Helm 템플릿 - helm template chart-name chart-location —set k8version=Kubernetes-version —kube-version Kubernetes-version —namespace addon-namespace —include-crds —no-hooks —f any-overriden-values

        —f 플래그로 재정의된 구성을 전달합니다.

    • 모든 컨테이너 바이너리를 AWS Marketplace Amazon ECR리포지토리에 저장합니다. 매니페스트를 생성하려면 Helm 앞서 표시된 템플릿 명령입니다. 매니페스트에서 busybox 또는 이미지와 같은 외부 gcr 이미지 참조를 검색합니다. 요청 드롭다운의 리포지토리 추가 옵션을 사용하여 생성된 AWS Marketplace Amazon ECR 리포지토리에 종속성과 함께 모든 컨테이너 이미지를 업로드합니다.

  • 사용자 지정 구성 - 배포 중에 사용자 지정 변수를 추가할 수 있습니다. 최종 사용자 환경을 식별하는 방법에 대한 자세한 내용은 소프트웨어 이름을 지정aws_mp_configuration_schema.json하고 를 사용하여 래퍼에 패키징합니다.Helm 차트에서 Amazon EKS 추가 기능: 고급 구성 을 참조하세요.

    '$schema' 키워드에 따라 는 유효한 application/schema+json 리소스를 가리키URI는 이어야 $schema 합니다.

    이 파일은 암호, 라이선스 키 및 인증서와 같은 민감한 정보를 수락해서는 안 됩니다.

    보안 암호 및 인증서 설치를 처리하려면 최종 사용자에게 설치 pre-Add-on 후 단계를 제공할 수 있습니다. 제품은 외부 라이선스에 의존해서는 안 됩니다. 제품은 AWS Marketplace 권한에 따라 작동해야 합니다.

    의 제한 사항에 대한 자세한 내용은 섹션을 aws_mp_configuration_schema.json참조하세요추가 구성 요구 사항 및 추가 기능 공급자에 대한 모범 사례.

  • 소프트웨어가 배포될 네임스페이스 식별 및 생성 - 제품의 첫 번째 릴리스에서는 템플릿화된 네임스페이스를 추가하여 소프트웨어가 배포될 네임스페이스를 식별해야 합니다.

  • 해당하는 serviceAccount 경우 생성 - 소프트웨어가 의 유료 소프트웨어 AWS Marketplace 이거나 다른 에 연결해야 하는 경우 AWS 서비스Helm 차트serviceAccount는 기본적으로 생성됩니다. serviceAccount 생성이 values.yaml 파일의 파라미터로 처리되는 경우 파라미터 값을 로 설정합니다true. 예: serviceAccount.create = true. 이는 고객이 이미 필요한 권한이 있는 기본 노드 인스턴스에서 권한을 상속하여 추가 기능을 설치하도록 선택할 수 있기 때문에 필요합니다. Helm 차트가 를 생성하지 않으면 serviceAccount권한을 에 연결할 수 없습니다serviceAccount.

  • 추적 가능한 배포 또는 데몬셋 - Helm 차트에 데몬셋 또는 배포가 있는지 확인합니다. Amazon EKS 추가 기능 프레임워크는 이를 사용하여 Amazon EKS 리소스의 배포를 추적합니다. 추적 가능한 배포 또는 데몬셋이 없으면 추가 기능에 배포 오류가 발생합니다. 추가 기능에 배포 또는 데몬셋이 없는 경우, 예를 들어 추가 기능이 추적 불가능한 사용자 지정 리소스 또는 Kubernetes 작업의 집합을 배포하는 경우 더미 배포 또는 데몬셋 객체를 추가합니다.

  • AMD 및 ARM 아키텍처 지원 - 많은 Amazon EKS 고객이 ARM64 현재 AWS Graviton 인스턴스를 사용합니다. 타사 소프트웨어는 두 아키텍처를 모두 지원해야 합니다.

  • APIs 의 라이선스 또는 측정과 통합 AWS Marketplace - 여러 결제 모델을 AWS Marketplace 지원합니다. 자세한 내용은 컨테이너 제품 결제, 측정 및 라이선스 통합 단원을 참조하십시오. PAYG 메커니즘을 통해 제품을 판매하려면 섹션을 참조하세요AWS Marketplace 측정 서비스를 사용하여 컨테이너 제품에 대한 사용자 지정 측정 구성. 선결제 또는 계약 모델을 통해 제품을 판매하려면 섹션을 참조하세요를 사용한 컨테이너 제품의 계약 요금 AWS License Manager.

  • 소프트웨어와 모든 아티팩트 및 종속성 업로드 - Helm 차트는 자체적으로 구성되어야 하며 외부 소스의 종속성이 필요하지 않아야 합니다. 예를 들어,GitHub. 소프트웨어에 외부 종속성이 필요한 경우 동일한 AWS Marketplace 목록의 AWS Marketplace 프라이빗 Amazon 리ECR포지토리로 종속성을 푸시해야 합니다.

  • 웹 사이트에 배포 지침 제공 - 고객이 create-addon 명령을 통해 소프트웨어를 배포하는 방법을 식별할 수 있도록 배포 안내서를 호스팅할 것을 요청합니다.

  • IAM 역할 - 소프트웨어가 작동하거나 다른 와 연결하는 데 필요한 모든 AWS Identity and Access Management (IAM) 정책을 나열합니다 AWS 서비스.

  • 버전 업데이트 - Amazon은 업스트림 EKS 릴리스 몇 주 후에 새 Kubernetes 버전을 릴리스합니다. 새로운 Amazon EKS 클러스터 버전이 일반적으로 출시됨에 따라 공급업체는 45일 이내에 새 Amazon EKS 클러스터 버전 릴리스와 호환되도록 소프트웨어를 인증하거나 업데이트해야 합니다. 현재 버전의 추가 기능이 새 Kubernetes 버전을 지원하는 경우 버전 호환성 매트릭스를 업데이트할 수 있도록 동일한 버전을 검증하고 인증합니다. 새 Kubernetes 버전 릴리스를 지원하기 위해 새 추가 기능이 필요한 경우 온보딩을 위해 새 버전을 제출하세요.

  • 파트너의 소프트웨어는 다음 유형 중 하나에 해당하거나 Kubernetes 또는 Amazon을 강화할 운영 소프트웨어여야 합니다EKS. Gitops | 모니터링 | 로깅 | 인증서 관리 | 정책 관리 | 비용 관리 | 오토스케일링 | 스토리지 | kubernetes 관리 | service-mesh | etcd-backup | ingress-service-type load-balancer | local-registry| 네트워킹 | 보안 | 백업 | 수신 컨트롤러 | 관찰 가능성

  • 소프트웨어는 컨테이너 네트워크 인터페이스(CNI)일 수 없습니다.

  • 소프트웨어는 유료 제품의 라이선스 AWS Marketplace 및 측정 APIs 기능을 통해 판매되고 통합되어야 합니다. BYOL 제품은 허용되지 않습니다.

추가 구성 요구 사항 및 추가 기능 공급자에 대한 모범 사례

AmazonEKS에는 추가 기능 공급자의 Helm JSON 스키마 문자열로 구성해야 합니다. 필수 구성이 필요하거나 선택적 구성을 허용하는 추가 기능에는 에 제출된 Helm 차트가 있는 aws_mp_configuration_schema.json 파일이 포함되어야 합니다 AWS Marketplace. AmazonEKS은 이 스키마를 사용하여 고객의 구성 입력을 검증하고 스키마를 준수하지 않는 입력 값이 있는 API 호출을 거부합니다. 추가 구성은 일반적으로 두 가지 범주로 분류됩니다.

  • 레이블, 허용 오차nodeSelector, 등과 같은 일반 Kubernetes 속성에 대한 구성

  • 라이선스 키, 기능 활성화, URLs등과 같은 추가 기능별 구성

이 섹션에서는 일반적인 Kubernetes 속성과 관련된 첫 번째 범주에 중점을 둡니다.

Amazon은 Amazon EKS 추가 기능 구성에 대한 모범 사례를 따를 것을 EKS 권장합니다.

스키마 요구 사항

json 스키마를 정의할 때 Amazon EKS 추가 기능에서 지원하는 json 스키마 버전을 사용해야 합니다.

지원되는 스키마 목록:

  • https://json-schema.org/draft-04/schema

  • https://json-schema.org/draft-06/schema

  • https://json-schema.org/draft-07/schema

  • https://json-schema.org/draft/2019-09/schema

다른 json 스키마 버전을 사용하면 Amazon EKS 추가 기능과 호환되지 않으므로 이 문제가 해결될 때까지 추가 기능을 릴리스할 수 없습니다.

예제 Helm 스키마 파일

{ "$schema": "http://json-schema.org/schema#", "type": "object", "properties": { "podAnnotations": { "description": "Pod Annotations" "type": "object" }, "podLabels": { "description": "Pod Labels" "type": "string" }, "resources": { "type": "object" "description": "Resources" }, "logLevel": { "description": "Logging Level" "type": "string", "enum": [ "info", "debug" ] }, "config": { "description": "Custom Configuration" "type": "object" } } }
camelCase

구성 파라미터는 여야 camelCase하며 이 형식을 준수하지 않으면 거부됩니다.

설명은 필수입니다.

스키마 속성에 대한 의미 있는 설명은 항상 포함하세요. 이 설명은 각 구성 파라미터에 대해 Amazon EKS 콘솔에서 레이블 이름을 렌더링하는 데 사용됩니다.

RBAC 정의

추가 기능 공급자는 최소 RBAC 권한 원칙을 사용하여 추가 기능을 성공적으로 설치하는 데 필요한 권한을 정의하고 제공해야 합니다. 최신 버전의 추가 기능 또는 를 해결하기 위한 수정 사항에 대한 RBAC 권한을 변경해야 하는 경우 CVE추가 기능 공급자는 Amazon EKS 팀에 이 변경 사항을 알려야 합니다. 각 Kubernetes 리소스에 필요한 권한은 객체의 리소스 이름으로 제한되어야 합니다.

apiGroups: ["apps"] resources: ["daemonsets"] resourceNames: ["ebs-csi-node"] verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
보안 암호 관리

이 섹션은 고객이 애플리케이션 키, API 키, 암호 등과 같은 비밀 정보를 구성해야 하는 추가 기능에만 적용됩니다. 현재 AmazonEKSAPIs은 보안 영향으로 인해 일반 텍스트로 보안 정보 전달을 지원하지 않습니다. 그러나 고객은 구성을 사용하여 추가 기능에 필요한 키를 포함하는 Kubernetes 보안 암호의 이름으로 전달할 수 있습니다. 고객은 사전 조건 단계와 동일한 네임스페이스를 가진 키를 포함하는 Kubernetes 보안 암호 객체를 생성한 다음 추가 기능을 생성할 때 구성 블롭을 사용하여 보안 암호의 이름으로 전달해야 합니다. 고객이 실수로 스키마 속성을 실제 키로 오인하지 않도록 추가 기능 공급자의 이름을 스키마 속성으로 지정하는 것이 좋습니다. 예: appSecretName connectionSecretName 등

요약하면, 추가 기능 공급자는 스키마를 활용하여 고객이 보안 암호의 이름을 전달할 수 있지만 보안 암호 자체를 실제로 보유할 키는 전달할 수 없습니다.

예제 구성 값

스키마에 구성 예제를 포함시켜 고객이 추가 기능을 구성할 수 있도록 할 수 있습니다. 다음 예제는 OpenTelemetry 추가 기능을 위한 AWS Distro 스키마에서 가져온 것입니다.

"examples": [ { "admissionWebhooks": { "namespaceSelector": {}, "objectSelector": {} }, "affinity": {}, "collector": { "amp": { "enabled": true, "remoteWriteEndpoint": "https://aps-workspaces.us-west-2.amazonaws.com/workspaces/ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api/v1/remote_write" }, "cloudwatch": { "enabled": true }, "mode": "deployment", "replicas": 1, "resources": { "limits": { "cpu": "256m", "memory": "512Mi" }, "requests": { "cpu": "64m", "memory": "128Mi" } }, "serviceAccount": { "annotations": {}, "create": true, "name": "adot-collector" }, "xray": { "enabled": true } }, "kubeRBACProxy": { "enabled": true, "resources": { "limits": { "cpu": "500m", "memory": "128Mi" }, "requests": { "cpu": "5m", "memory": "64Mi" } } }, "manager": { "env": {}, "resources": { "limits": { "cpu": "100m", "memory": "128Mi" }, "requests": { "cpu": "100m", "memory": "64Mi" } } }, "nodeSelector": {}, "replicaCount": 1, "tolerations": [] } ]

구성에 허용되는 공통 파라미터

다음은 고객 응대 Helm 스키마 파일의 권장 파라미터입니다.

파라미터 설명 기본값이 있어야 합니까?
additionalLabels 추가 기능으로 관리되는 모든 Kubernetes 객체에 Kubernetes 레이블을 추가합니다. 아니요
additionalAnnotations 추가 기능으로 관리되는 모든 Kubernetes 객체에 Kubernetes 주석을 추가합니다. 아니요
podLabels 추가 기능으로 관리되는 포드에 Kubernetes 레이블을 추가합니다. 아니요
podAnnotations 추가 기능으로 관리되는 포드에 Kubernetes 주석을 추가합니다. 아니요
logLevel 추가 기능에서 관리하는 구성 요소의 로그 수준입니다.
nodeSelector 가장 간단한 권장 노드 선택 제약 조건입니다. nodeSelector 필드를 포드 사양에 추가하고 대상 노드에 포함할 노드 레이블을 지정할 수 있습니다. Linux 노드 전용과 같은 잠재적
허용 오차 포드에는 허용치가 적용됩니다. 허용 오차를 사용하면 스케줄러가 일치하는 taints가 있는 포드를 예약할 수 있습니다. 허용 한도는 예약을 허용하지만 예약을 보장하지는 않습니다. 아마도 데몬셋에서 더 흔할 수 있습니다.
친화성 친화성 기능은 nodeSelector 필드와 같은 노드 친화성 함수의 두 가지 유형으로 구성되지만 표현력이 뛰어나고 소프트 규칙을 지정할 수 있습니다. 포드 간 친화성/친화성 방지 기능을 사용하면 포드를 다른 포드의 레이블에 대해 제약할 수 있습니다. 가능
topologySpreadConstraints 토폴로지 분산 제약 조건을 사용하여 리전, 영역, 노드 및 기타 사용자 정의 토폴로지 도메인과 같은 장애 도메인 간에 클러스터 간에 포드가 분산되는 방식을 제어할 수 있습니다. 이렇게 하면 고가용성과 효율적인 리소스 사용률을 달성하는 데 도움이 될 수 있습니다. 가능
리소스 요청/제한 각 컨테이너에 필요한 cpu/memory의 양을 지정합니다. 요청을 설정하는 것이 좋습니다. 한도는 선택 사항입니다.
복제본 추가 기능으로 관리되는 포드의 복제본 수입니다. 데몬셋에는 적용되지 않습니다.
참고

워크로드 예약 구성 파라미터의 경우 필요한 경우 스키마에서 최상위 구성 요소를 분리해야 할 수 있습니다. 예를 들어 Amazon EBS CSI 드라이버에는 컨트롤러와 노드 에이전트라는 두 가지 주요 구성 요소가 포함되어 있습니다. 고객은 각 구성 요소에 대해 서로 다른 노드 선택기/내약성이 필요합니다.

참고

JSON 스키마에 정의된 기본값은 전적으로 사용자 설명서용이며 values.yaml 파일에 올바른 기본값을 가질 필요성을 대체하지 않습니다. 기본 속성을 사용하는 경우 의 기본값이 스키마의 기본값과 values.yaml 일치하고 Helm 차트를 변경할 때마다 두 아티팩트(values.schema.jsonvalues.yaml)가 동기화되어 있는지 확인하세요.

"affinity": { "default": { "affinity": { "nodeAffinity": { "preferredDuringSchedulingIgnoredDuringExecution": [ { "preference": { "matchExpressions": [ { "key": "eks.amazonaws.com/compute-type", "operator": "NotIn", "values": [ "fargate" ] } ] }, "weight": 1 } ] }, "podAntiAffinity": { "preferredDuringSchedulingIgnoredDuringExecution": [ { "podAffinityTerm": { "labelSelector": { "matchExpressions": [ { "key": "app", "operator": "In", "values": [ "ebs-csi-controller" ] } ] }, "topologyKey": "kubernetes.io/hostname" }, "weight": 100 } ] } } }, "description": "Affinity of the controller pod", "type": [ "object", "null" ] }

구성에 허용되지 않는 공통 파라미터

clusterName, , region, vpcId accountId등의 클러스터 메타데이터 파라미터는 다양한 추가 기능(예: Elastic Load Balancing Controller)에 필요할 수 있습니다. Amazon EKS 서비스에서 알려진 파라미터와 유사한 모든 파라미터는 Amazon EKS 추가 기능에서 자동으로 주입되며 구성 옵션으로 지정할 책임은 사용자에게 없습니다. 이러한 파라미터에는 다음이 포함됩니다.

  • AWS 리전

  • Amazon EKS 클러스터 이름

  • VPC 클러스터의 ID

  • 컨테이너 레지스트리, 특히 네트워킹 추가 기능에 사용되는 build-prod 계정용

  • DNS 클러스터 IP, 특히 코어 추가 기능용

  • Amazon EKS 클러스터 API 엔드포인트

  • IPv4 클러스터에서 활성화됨

  • IPv6 클러스터에서 활성화됨

  • 클러스터에서 IPv6 활성화된 에 대한 접두사 위임

추가 기능 공급자는 해당 파라미터에 대해 정의된 템플팅이 있는지 확인해야 합니다. 위의 각 파라미터에는 Amazon 에서 정의한 사전 정의된 parameterType 속성이 있습니다EKS. 릴리스 메타데이터는 parameterType 및 간의 매핑을 지정합니다name/path of the parameter in the template. This way, the values can be dynamically passed-in by Amazon EKS without requiring customers to specify these through configurations and also gives flexibility to add-on providers to define their own template name/path. Amazon이 동적으로 주입EKS해야 하는 위와 같은 파라미터는 스키마 파일에서 제외해야 합니다.

릴리스 메타데이터의 매핑 예제

"defaultConfiguration": [ { "key": "image.containerRegistry", "parameterType": "CONTAINER_REGISTRY" } ]

다음은 고객 응대 Helm 스키마 파일에서 구성할 수 없는 파라미터입니다. 파라미터에는 수정할 수 없는 기본값이 있거나 추가 기능 템플릿에 전혀 포함되지 않아야 합니다.

파라미터 설명 기본값이 있어야 합니까?
image Kubernetes 클러스터에 배포될 컨테이너 이미지입니다. 아니요, 추가 기능 정의를 통해 관리됩니다.
imagePullSecrets 보안 암호를 사용하여 프라이빗 레지스트리에서 가져오도록 포드를 구성합니다. N/A
livenessProbe Kubelet 프로세스는 실시간 프로브를 사용하여 컨테이너를 다시 시작해야 하는 시기를 파악합니다. 예를 들어, 라이브니스 프로브는 애플리케이션이 실행 중이지만 진행할 수 없는 교착 상태를 포착할 수 있습니다. 이러한 상태에서 컨테이너를 다시 시작하면 버그에도 불구하고 애플리케이션을 더 쉽게 사용할 수 있습니다.
readinessProbe 컨테이너에 대한 준비 프로브가 있어야 합니다. 이렇게 하면 데이터 플레인에서 실행되는 Kubelet 프로세스가 컨테이너가 트래픽을 제공할 준비가 된 시점을 알 수 있습니다. 포드는 모든 컨테이너가 준비되면 준비된 것으로 간주됩니다. 이 신호의 한 가지 사용은 서비스의 백엔드로 사용되는 포드를 제어하는 것입니다. 포드가 준비되지 않으면 서비스 로드 밸런서에서 제거됩니다.
startupProbe kubelet은 시작 프로브를 사용하여 컨테이너 애플리케이션이 시작된 시기를 파악합니다. 이러한 프로브가 구성된 경우 성공할 때까지 실시간 및 준비 확인을 비활성화하여 해당 프로브가 애플리케이션 시작을 방해하지 않도록 합니다. 이를 통해 느린 시작 컨테이너에 대한 실시간 검사를 채택하여 kubelet이 가동 및 실행되기 전에 컨테이너가 죽지 않도록 할 수 있습니다. 선택 사항
podDisruptionBudget 포드 중단 예산(PDB)을 정의하여 자발적 중단 중에 최소 수의 PODS 계속 실행되도록 합니다. 는 자발적 중단으로 인해 동시에 다운되는 복제된 애플리케이션의 포드 수를 PDB 제한합니다. 예를 들어, 쿼럼 기반 애플리케이션은 실행 중인 복제본 수가 쿼럼에 필요한 수보다 적지 않도록 하고자 합니다. 웹 프런트 엔드는 로드에 대한 복제본 수가 총계의 특정 백분율 아래로 절대 떨어지지 않도록 해야 할 수 있습니다. 예, 두 개 이상의 복제본으로 기본 설정된 경우
serviceAccount (이름) 실행할 서비스 계정 포드의 이름입니다.
serviceAccount (주석) 서비스 계정에 적용되는 주석입니다. 일반적으로 서비스 계정의 IAM 역할 기능에 사용됩니다. 아니요. IAM 서비스 계정 역할은 최상위 Amazon EKS 추가 기능 에 ARN 설정되어 있습니다API. 이 규칙의 예외는 추가 기능에 여러 배포/컨트롤러(예: Flux)가 있고 별도의 IRSA 역할이 필요한 경우입니다ARNs.
priorityClassName 우선 순위는 다른 포드와 비교한 포드의 중요성을 나타냅니다. 포드를 예약할 수 없는 경우 스케줄러는 보류 중인 포드를 예약할 수 있도록 우선 순위가 낮은 포드를 선점(제거)하려고 시도합니다. 예. 대부분의 추가 기능은 클러스터 기능에 중요하며 기본적으로 우선 순위 클래스가 설정되어 있어야 합니다.
podSecurityContext 보안 컨텍스트는 포드 또는 컨테이너에 대한 권한 및 액세스 제어 설정을 정의합니다. 일반적으로 v1.19 및 하위 클러스터IRSA에서 에 fsGroup 필요한 를 설정하는 데 사용됩니다. 아마도 Amazon이 더 이상 Kubernetes v1.19를 지원하지 EKS 않는 경우
securityContext 보안 컨텍스트는 포드 또는 컨테이너에 대한 권한 및 액세스 제어 설정을 정의합니다.
updateStrategy 이전 포드를 새 포드로 대체하는 데 사용되는 전략을 지정합니다.
nameOverride 포드의 이름을 재정의합니다. 아니요
podSecurityPolicy

파라미터에 대한 제한을 적용합니다.

아니요 - 더 PSPs 이상 사용되지 않습니다.
extraVolumeMounts/extraVolumes

Amazon이 아닌 EKS 클러스터IRSA에서 에 사용됩니다.

아니요