Persyaratan produk berbasis kontainer untuk AWS Marketplace - AWS Marketplace
Persyaratan keamananPersyaratan aksesPersyaratan informasi pelangganPersyaratan penggunaan produkPersyaratan arsitekturPetunjuk penggunaan produk kontainerPersyaratan untuk produk EKS add-on Amazon

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Persyaratan produk berbasis kontainer untuk AWS Marketplace

AWS Marketplace mempertahankan persyaratan berikut untuk semua produk dan penawaran berbasis kontainer di. AWS Marketplace Persyaratan ini membantu mempromosikan katalog yang aman, terjaga, dan dapat dipercaya untuk pelanggan kami. Kami juga mendorong penjual untuk meninjau implementasi kontrol dan protokol tambahan yang berlaku untuk memenuhi kebutuhan produk spesifik mereka.

Semua produk dan metadata terkait ditinjau ketika dikirimkan untuk memastikan bahwa mereka memenuhi atau melampaui persyaratan saat ini AWS Marketplace . Kami meninjau dan menyesuaikan kebijakan ini untuk memenuhi persyaratan keamanan dan penggunaan lainnya yang terus berkembang. AWS Marketplace terus memverifikasi bahwa produk yang ada terus memenuhi setiap perubahan pada persyaratan ini. Jika produk tidak sesuai, AWS Marketplace akan menghubungi Anda untuk memperbarui produk Anda. Dalam beberapa kasus, produk Anda mungkin sementara tidak tersedia untuk pelanggan baru hingga masalah teratasi.

Persyaratan keamanan

Semua produk berbasis kontainer harus mematuhi persyaratan keamanan berikut:

  • Citra kontainer Docker harus bebas dari malware, virus, atau kerentanan yang diketahui. Saat Anda menambahkan versi baru ke produk kontainer Anda, gambar kontainer yang disertakan dalam versi dipindai.

  • Jika produk berbasis kontainer Anda memerlukan akses untuk mengelola AWS sumber daya, akses harus dicapai melalui IAMperan untuk akun layanan (jika dijalankan melalui Amazon Elastic Kubernetes Service EKS (Amazon IAM)) atau peran untuk tugas (jika dijalankan melalui Amazon Elastic Container Service ECS (Amazon)) alih-alih meminta kunci akses dari pengguna.

  • Produk berbasis kontainer hanya memerlukan sedikit hak istimewa untuk dijalankan. Untuk informasi selengkapnya, lihat ECSkeamanan dan EKSkeamanan.

  • Citra kontainer harus dikonfigurasi untuk dijalankan dengan hak non-root secara default.

Persyaratan akses

Semua produk berbasis kontainer harus mematuhi persyaratan akses berikut:

  • Produk berbasis kontainer harus menggunakan kata sandi acak awal. Produk berbasis kontainer tidak boleh menggunakan kata sandi tetap atau kosong awal untuk akses administratif eksternal (misalnya, untuk masuk ke aplikasi melalui antarmuka web). Pembeli harus diminta untuk kata sandi acak ini sebelum diizinkan untuk mengatur atau mengubah kredensialnya sendiri.

  • Setiap akses dari luar ke aplikasi harus secara eksplisit disetujui dan diaktifkan oleh pelanggan.

Persyaratan informasi pelanggan

Semua produk berbasis kontainer harus mematuhi persyaratan informasi pelanggan berikut:

  • Perangkat lunak tidak boleh mengumpulkan atau mengekspor data pelanggan tanpa sepengetahuan pelanggan dan menyatakan persetujuan kecuali sebagaimana disyaratkan oleh BYOL (Bawa Lisensi Anda Sendiri). Aplikasi yang mengumpulkan atau mengekspor data pelanggan harus mengikuti pedoman ini:

    • Pengumpulan data pelanggan harus swalayan, otomatis, dan aman. Pembeli tidak perlu menunggu penjual menyetujui untuk menyebarkan perangkat lunak.

    • Persyaratan untuk data pelanggan harus dinyatakan dengan jelas dalam deskripsi atau petunjuk penggunaan daftar. Ini termasuk apa yang dikumpulkan, lokasi di mana data pelanggan akan disimpan, dan bagaimana data itu akan digunakan. Misalnya, Produk ini mengumpulkan nama dan alamat email Anda. Informasi ini dikirim ke dan disimpan oleh<company name>. Informasi ini hanya akan digunakan untuk menghubungi pembeli sehubungan dengan. <product name>

    • Informasi pembayaran tidak boleh dikumpulkan.

Persyaratan penggunaan produk

Semua produk berbasis kontainer harus mematuhi persyaratan penggunaan produk berikut:

  • Penjual hanya bisa mencantumkan produk yang berfungsi penuh. Produk beta atau prarilis untuk tujuan uji coba atau evaluasi tidak diperbolehkan. Pengembang, komunitas, dan BYOL edisi perangkat lunak komersial didukung jika penjual menyediakan versi berbayar yang setara AWS Marketplace dalam waktu 90 hari setelah menyediakan edisi gratis.

  • Semua petunjuk penggunaan produk berbasis kontainer harus meliputi semua langkah untuk men-deploy produk berbasis kontainer. Petunjuk penggunaan harus menyediakan perintah dan sumber daya deployment yang menunjuk ke citra kontainer yang sesuai pada AWS Marketplace.

  • Produk berbasis kontainer harus meliputi semua citra kontainer yang dibutuhkan pelanggan untuk menggunakan perangkat lunak. Selain itu, produk berbasis kontainer tidak boleh mengharuskan pengguna untuk meluncurkan produk menggunakan gambar apa pun dari luar AWS Marketplace (misalnya, gambar kontainer dari repositori pihak ketiga).

  • Kontainer dan perangkat lunaknya harus dapat digunakan dengan cara swalayan dan tidak boleh memerlukan metode atau biaya pembayaran tambahan. Aplikasi yang memerlukan dependensi eksternal pada penerapan harus mengikuti pedoman ini:

    • Persyaratan harus diungkapkan dalam deskripsi atau petunjuk penggunaan daftar. Misalnya, Produk ini memerlukan koneksi internet untuk digunakan dengan benar. Paket-paket berikut diunduh saat penerapan:. <list of package>

    • Penjual bertanggung jawab atas penggunaan dan memastikan ketersediaan dan keamanan semua dependensi eksternal.

    • Jika dependensi eksternal tidak lagi tersedia, produk harus dihapus AWS Marketplace juga.

    • Dependensi eksternal tidak boleh memerlukan metode atau biaya pembayaran tambahan.

  • Kontainer yang memerlukan koneksi berkelanjutan ke sumber daya eksternal yang tidak berada di bawah kendali langsung pembeli — misalnya, eksternal APIs atau Layanan AWS dikelola oleh penjual atau pihak ketiga — harus mengikuti pedoman ini:

    • Persyaratan harus diungkapkan dalam deskripsi atau petunjuk penggunaan daftar. Misalnya, Produk ini membutuhkan koneksi internet yang berkelanjutan. Layanan eksternal yang sedang berlangsung berikut ini diperlukan untuk berfungsi dengan baik:. <list of resources>

    • Penjual bertanggung jawab atas penggunaan dan memastikan ketersediaan dan keamanan semua sumber daya eksternal.

    • Jika sumber daya eksternal tidak lagi tersedia, produk harus dihapus AWS Marketplace juga.

    • Sumber daya eksternal tidak boleh memerlukan metode atau biaya pembayaran tambahan dan pengaturan koneksi harus otomatis.

  • Perangkat lunak produk dan metadata tidak boleh berisi bahasa yang mengarahkan pengguna ke platform cloud lain, produk tambahan, atau layanan upsell yang tidak tersedia di AWS Marketplace.

  • Jika produk Anda merupakan add-on untuk produk lain atau produk lainISV, deskripsi produk Anda harus menunjukkan bahwa itu memperluas fungsionalitas produk lain dan bahwa tanpanya, produk Anda memiliki utilitas yang sangat terbatas. Misalnya, Produk ini memperluas fungsionalitas dan tanpa itu, produk ini memiliki utilitas yang sangat terbatas<product name>. Harap dicatat bahwa mungkin memerlukan lisensi sendiri untuk fungsionalitas penuh dengan daftar ini. <product name>

Persyaratan arsitektur

Semua produk berbasis kontainer harus mematuhi persyaratan arsitektur berikut:

  • Gambar wadah sumber untuk AWS Marketplace harus didorong ke repositori Amazon Elastic Container Registry (AmazonECR) yang dimiliki oleh. AWS Marketplace Anda dapat membuat repositori ini di produk server Portal Manajemen AWS Marketplace bawah untuk setiap daftar produk kontainer Anda.

  • Citra kontainer harus didasarkan pada Linux.

  • Produk berbasis kontainer berbayar harus dapat digunakan di Amazon, ECS Amazon EKS, atau. AWS Fargate

  • Produk berbasis container berbayar dengan harga kontrak dan integrasi AWS License Manager harus diterapkan di Amazon, Amazon, Amazon Anywhere, Amazon AnywhereECS, EKS AWS Fargate Amazon ECS AnywhereEKS, Red Hat OpenShift Service on AWS (ROSA), cluster Kubernetes yang dikelola sendiri di lokasi, atau di Amazon Elastic Compute Cloud.

Petunjuk penggunaan produk kontainer

Saat membuat petunjuk penggunaan untuk produk kontainer Anda, ikuti langkah-langkah dan panduan diMembuat AMI dan mengkontainer petunjuk penggunaan produk untuk AWS Marketplace.

Persyaratan untuk produk EKS add-on Amazon

EKSAdd-on Amazon adalah perangkat lunak yang menyediakan kemampuan operasional Kubernetes aplikasi tetapi tidak spesifik untuk aplikasi. Misalnya, EKS add-on Amazon mencakup agen observabilitas atau Kubernetes driver yang memungkinkan cluster berinteraksi dengan AWS sumber daya yang mendasari untuk jaringan, komputasi, dan penyimpanan.

Sebagai penjual produk kontainer, Anda dapat memilih di antara beberapa opsi penerapan termasuk AmazonEKS. Anda dapat mempublikasikan versi produk Anda sebagai AWS Marketplace add-on ke dalam katalog EKS add-on Amazon. Add-on Anda muncul di EKS konsol Amazon di samping add-on yang dikelola oleh AWS dan vendor lain. Pembeli Anda dapat menggunakan perangkat lunak Anda sebagai add-on semudah mereka melakukan add-on lainnya.

Untuk informasi selengkapnya, lihat EKSadd-on Amazon di Panduan EKS Pengguna Amazon.

Mempersiapkan produk kontainer Anda sebagai AWS Marketplace add-on

Untuk mempublikasikan produk kontainer Anda sebagai AWS Marketplace add-on, produk tersebut harus memenuhi persyaratan berikut:

  • Produk kontainer Anda harus dipublikasikan di AWS Marketplace.

  • Produk kontainer Anda harus dibangun kompatibel untuk keduanya AMD64 dan ARM64 arsitektur.

  • Produk kontainer Anda tidak boleh menggunakan model harga Bring Your Own License (BYOL).

    catatan

    BYOLtidak didukung untuk pengiriman EKS add-on Amazon.

  • Anda harus mematuhi semua persyaratan produk berbasis kontainer termasuk mendorong semua gambar kontainer dan Helm grafik ke dalam ECR repositori Amazon yang AWS Marketplace dikelola. Persyaratan ini mencakup gambar sumber terbuka, misalnya,nginx. Gambar dan bagan tidak dapat di-host di repositori eksternal lainnya termasuk, namun tidak terbatas pada, Galeri ECRPublik Amazon, Docker Hub, dan Quay.

  • Helm grafik - Siapkan perangkat lunak Anda untuk digunakan melalui Helm grafik. Kerangka kerja EKS add-on Amazon mengonversi a Helm bagan menjadi manifes. Beberapa Helm fitur tidak didukung dalam EKS sistem Amazon. Daftar berikut menjelaskan persyaratan yang harus dipenuhi sebelum orientasi. Dalam daftar ini, semua Helm perintah menggunakan Helm versi 3.8.1:

    • Semua Capabilities objek didukung, dengan pengecualian untuk.APIVersions. .APIVersionstidak didukung untuk non-built-in kustom Kubernetes APIs.

    • Hanya Release.Namespace objek Release.Name dan yang didukung.

    • Helm kait dan lookup fungsinya tidak didukung.

    • Semua grafik dependen harus ditempatkan di dalam grafik utama Helm bagan (ditentukan dengan file jalur repositori://...).

    • Bagian Helm grafik harus berhasil lulus Helm Lint dan Helm Template tanpa kesalahan. Perintahnya adalah sebagai berikut:

      • Helm Serat — helm lint helm-chart

        Masalah umum termasuk bagan yang tidak dideklarasikan dalam metadata bagan induk. Sebagai contoh, chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed.

      • Helm Template - 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

        Lewati konfigurasi yang diganti dengan bendera. —f

    • Simpan semua binari kontainer di repo AWS Marketplace AmazonECR. Untuk membuat manifes, gunakan Helm perintah template yang ditampilkan sebelumnya. Cari manifes untuk referensi gambar eksternal seperti busybox atau gcr gambar. Unggah semua gambar kontainer bersama dengan dependensi ke ECR repo AWS Marketplace Amazon yang dibuat dengan menggunakan opsi Add Repository di dropdown permintaan.

  • Konfigurasi kustom - Anda dapat menambahkan variabel kustom selama penerapan. Untuk informasi tentang cara mengidentifikasi pengalaman pengguna akhir, beri nama perangkat lunakaws_mp_configuration_schema.json, dan paket ke dalam pembungkus dengan Helm bagan, lihat EKSPengaya Amazon: Konfigurasi lanjutan.

    Menurut Kata Kunci “$schema”, $schema harus menjadi yang menunjuk ke URI sumber daya yang validapplication/schema+json.

    File ini tidak boleh menerima informasi sensitif apa pun seperti kata sandi, kunci lisensi, dan sertifikat.

    Untuk menangani rahasia dan instalasi sertifikat, Anda dapat memberikan langkah pasca atau pre-Add-on instalasi kepada pengguna akhir. Produk tidak boleh bergantung pada lisensi eksternal apa pun. Produk harus bekerja berdasarkan AWS Marketplace hak.

    Untuk informasi selengkapnya tentang batasanaws_mp_configuration_schema.json, lihatPersyaratan konfigurasi add-on dan praktik terbaik untuk penyedia add-on.

  • Identifikasi dan buat namespace tempat perangkat lunak akan digunakan - Dalam rilis pertama produk Anda, Anda harus mengidentifikasi namespace tempat perangkat lunak akan digunakan dengan menambahkan namespace templat.

  • Buat serviceAccount jika berlaku — Jika perangkat lunak adalah perangkat lunak berbayar AWS Marketplace atau harus terhubung dengan yang lain Layanan AWS, pastikan bahwa Helm grafik dibuat secara serviceAccount default. Jika serviceAccount kreasi ditangani oleh parameter dalam values.yaml file, atur nilai parameter ketrue. Misalnya, serviceAccount.create = true. Ini diperlukan karena pelanggan mungkin memilih untuk menginstal add-on dengan mewarisi izin dari instance node yang mendasarinya yang sudah memiliki izin yang diperlukan. Jika bagan Helm tidak membuatserviceAccount, maka izin tidak dapat dikaitkan dengan. serviceAccount

  • Penerapan atau Daemonset yang Dapat Dilacak — Pastikan bagan Helm Anda memiliki daemonset atau penerapan. Kerangka EKS addon Amazon melacak penyebaran EKS sumber daya Amazon Anda menggunakannya. Tanpa penerapan atau daemonset yang dapat dilacak, addon Anda akan menghadapi kesalahan penerapan. Jika addon Anda tidak memiliki deployment atau daemonset, misalnya, jika addon Anda menerapkan sekumpulan sumber daya Kustom atau pekerjaan Kubernetes yang tidak dapat dilacak, tambahkan deployment dummy atau objek daemonset.

  • Support untuk AMD dan ARM arsitektur - Banyak EKS pelanggan Amazon menggunakan ARM64 saat ini untuk menggunakan instance AWS Graviton. Perangkat lunak pihak ketiga harus mendukung kedua arsitektur.

  • Integrasikan dengan lisensi atau pengukuran APIs dari AWS Marketplace - AWS Marketplace mendukung beberapa model penagihan. Untuk informasi selengkapnya, lihat Integrasi penagihan, pengukuran, dan lisensi produk kontainer. Jika Anda ingin menjual produk Anda melalui PAYG mekanisme, lihatMengkonfigurasi pengukuran khusus untuk produk kontainer dengan AWS Marketplace Metering Service. Jika Anda ingin menjual produk Anda melalui model dimuka atau kontrak, lihatHarga kontrak untuk produk kontainer dengan AWS License Manager.

  • Unggah perangkat lunak dan semua artefak dan dependensi — Bagan Helm harus mandiri, dan tidak boleh memerlukan dependensi dari sumber eksternal, misalnya, GitHub. Jika perangkat lunak memerlukan dependensi eksternal, maka dependensi harus didorong ke ECR repositori AWS Marketplace Amazon pribadi di bawah daftar yang sama. AWS Marketplace

  • Berikan instruksi penerapan di situs web Anda — Kami meminta Anda meng-host panduan penyebaran bagi pelanggan untuk mengidentifikasi cara menerapkan perangkat lunak Anda melalui perintah create-addon.

  • IAMperan — Buat daftar semua AWS Identity and Access Management (IAM) kebijakan yang diperlukan agar perangkat lunak Anda berfungsi atau terhubung dengan yang lain Layanan AWS.

  • Pembaruan versi — Amazon EKS merilis versi Kubernetes baru beberapa minggu setelah rilis upstream. Karena versi EKS cluster Amazon baru tersedia secara umum, vendor memiliki waktu 45 hari untuk mengesahkan atau memperbarui perangkat lunak mereka agar kompatibel dengan rilis versi EKS cluster Amazon yang baru. Jika versi add-on Anda saat ini mendukung versi Kubernetes yang baru, validasi dan sertifikasi yang sama sehingga kami dapat memperbarui matriks kompatibilitas versi. Jika versi add-on baru diperlukan untuk mendukung rilis versi Kubernetes yang baru, silakan kirimkan versi baru untuk orientasi.

  • Perangkat lunak mitra harus termasuk dalam salah satu jenis berikut ini atau menjadi perangkat lunak operasional yang akan meningkatkan Kubernetes atau AmazonEKS: Gitops | monitoring | logging | manajemen sertifikat | manajemen kebijakan | manajemen biaya | autoscaling | penyimpanan | kubernetes-management | service-mesh | dll-backup | | load-balancer | lokal-registry| jaringan | Keamanan | backup | ingress-controller | observability ingress-service-type

  • Perangkat lunak tidak dapat berupa Antarmuka Jaringan Kontainer (CNI).

  • Perangkat lunak harus dijual melalui AWS Marketplace dan terintegrasi dengan Lisensi dan pengukuran APIs untuk produk berbayar. BYOLproduk tidak diterima.

Persyaratan konfigurasi add-on dan praktik terbaik untuk penyedia add-on

Amazon EKS memerlukan konfigurasi sebagai string JSONskema Helm dari penyedia add-on. Pengaya yang memerlukan konfigurasi yang diperlukan atau mengizinkan konfigurasi opsional harus menyertakan aws_mp_configuration_schema.json file dengan Bagan Helm yang dikirimkan ke. AWS Marketplace Amazon EKS akan menggunakan skema ini untuk memvalidasi input konfigurasi dari pelanggan dan menolak API panggilan dengan nilai input yang tidak sesuai dengan skema. Konfigurasi add-on biasanya termasuk dalam dua kategori:

  • Konfigurasi untuk properti Kubernetes umum seperti label, toleransi, dll. nodeSelector

  • Konfigurasi yang khusus add-on seperti kunci lisensi, pemberdayaan fitur, URLs dll.

Bagian ini difokuskan pada kategori pertama yang terkait dengan properti Kubernetes umum.

Amazon EKS merekomendasikan mengikuti praktik terbaik seputar konfigurasi EKS add-on Amazon.

Persyaratan skema

Saat mendefinisikan skema json, pastikan Anda menggunakan versi jsonschema yang didukung oleh add-on Amazon. EKS

Daftar skema yang didukung:

  • 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

Menggunakan versi skema json lainnya tidak kompatibel dengan EKS add-on Amazon dan akan menyebabkan add-on tidak dapat dirilis hingga ini diperbaiki.

Contoh file skema 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

Parameter konfigurasi haruscamelCase, dan akan ditolak jika tidak mengikuti format ini.

Deskripsi diperlukan

Selalu sertakan deskripsi yang bermakna untuk properti skema. Deskripsi ini akan digunakan untuk membuat nama label di EKS konsol Amazon untuk setiap parameter konfigurasi.

RBACdefinisi

Penyedia add-on perlu menentukan dan memberikan RBAC izin yang diperlukan untuk berhasil menginstal add-on menggunakan prinsip hak istimewa paling sedikit. Jika RBAC izin perlu diubah untuk versi add-on yang lebih baru atau perbaikan apa pun untuk mengatasi masalahCVE, penyedia add-on perlu memberi tahu tim Amazon EKS tentang perubahan ini. Izin yang diperlukan untuk setiap sumber daya Kubernetes harus dibatasi pada nama sumber daya objek. 

apiGroups: ["apps"]
resources: ["daemonsets"]
resourceNames: ["ebs-csi-node"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
Manajemen Rahasia

Bagian ini hanya berlaku untuk add-on yang membutuhkan pelanggan untuk mengonfigurasi informasi rahasia seperti kunci aplikasi, API kunci, kata sandi, dll. Saat ini, Amazon EKS APIs tidak mendukung penyampaian informasi rahasia dalam teks biasa karena implikasi keamanan. Namun, pelanggan dapat menggunakan konfigurasi untuk meneruskan nama Rahasia Kubernetes yang menyimpan kunci yang dibutuhkan oleh add-on. Pelanggan akan diminta untuk membuat objek Kubernetes Secret yang berisi kunci dengan namespace yang sama sebagai langkah prasyarat dan kemudian meneruskan nama Secret menggunakan gumpalan konfigurasi saat membuat add-on. Kami menyarankan agar penyedia add-on memberi nama properti skema sehingga pelanggan tidak sengaja salah mengira itu sebagai kunci yang sebenarnya. Misalnya: appSecretName, connectionSecretName dll.

Singkatnya, penyedia add-on dapat memanfaatkan skema untuk memungkinkan pelanggan melewati nama rahasia tetapi bukan kunci yang benar-benar akan menyimpan rahasia itu sendiri.

Contoh nilai konfigurasi

Anda dapat menyertakan contoh konfigurasi dalam skema Anda untuk membantu pelanggan dengan konfigurasi add-on. Contoh berikut adalah dari skema AWS Distro untuk OpenTelemetry add-on.

"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": []
      }
    ]

Parameter umum yang diizinkan untuk konfigurasi

Berikut ini adalah parameter yang direkomendasikan dalam file skema Helm yang dihadapi pelanggan.

Parameter Deskripsi Haruskah memiliki default?
additionalLabels Tambahkan label Kubernetes ke semua objek Kubernetes yang dikelola oleh add-on. Tidak
additionalAnnotations Tambahkan anotasi Kubernetes ke semua objek Kubernetes yang dikelola oleh add-on. Tidak
podLabels Tambahkan label Kubernetes ke pod yang dikelola oleh add-on. Tidak
podAnnotations Tambahkan anotasi Kubernetes ke pod yang dikelola oleh add-on. Tidak
logLevel Tingkat log untuk komponen yang dikelola oleh add-on. Ya
nodeSelector Bentuk kendala pemilihan simpul yang direkomendasikan paling sederhana. Anda dapat menambahkan nodeSelector field ke spesifikasi Pod Anda dan menentukan label node yang Anda inginkan untuk dimiliki oleh node target. Berpotensi, misalnya node Linux saja
toleransi Toleransi diterapkan pada polong. Toleransi memungkinkan scheduler untuk menjadwalkan pod dengan taints yang cocok. Toleransi memungkinkan penjadwalan tetapi tidak menjamin penjadwalan. Mungkin, lebih umum dengan daemonset
afinitas Fitur afinitas terdiri dari dua jenis afinitas: Afinitas node berfungsi seperti nodeSelector bidang tetapi lebih ekspresif dan memungkinkan Anda untuk menentukan aturan lunak, afinitas/anti-afinitas antar pod memungkinkan Anda untuk membatasi Pod terhadap label pada Pod lain. Mungkin
topologySpreadConstraints Anda dapat menggunakan batasan penyebaran topologi untuk mengontrol bagaimana Pod tersebar di seluruh klaster Anda di antara domain kegagalan seperti wilayah, zona, node, dan domain topologi yang ditentukan pengguna lainnya. Ini dapat membantu mencapai ketersediaan tinggi serta pemanfaatan sumber daya yang efisien. Mungkin
permintaan/batas sumber daya Tentukan berapa banyak cpu/memori yang dibutuhkan setiap wadah. Permintaan sangat disarankan untuk diatur. Batas bersifat opsional. Ya
replika Jumlah replika pod yang dikelola oleh add-on. Tidak berlaku untuk daemonset. Ya
catatan

Untuk parameter konfigurasi penjadwalan beban kerja, Anda mungkin perlu memisahkan komponen tingkat atas dalam Skema jika diperlukan. Misalnya, EBS CSI driver Amazon berisi dua komponen utama, controller dan node agent - pelanggan memerlukan pemilih simpul/toleransi yang berbeda untuk setiap komponen.

catatan

Nilai default yang didefinisikan dalam JSON skema adalah murni untuk tujuan dokumentasi pengguna saja dan tidak menggantikan kebutuhan untuk memiliki default yang sah dalam file. values.yaml Jika menggunakan properti default, pastikan bahwa default dalam values.yaml cocok dengan skema dan dua artefak (values.schema.jsondanvalues.yaml) tetap sinkron setiap kali perubahan dilakukan pada Bagan Helm.

"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"
            ]
          }

Parameter umum yang tidak diizinkan untuk konfigurasi

Parameter metadata cluster seperticlusterName,,region, vpcIdaccountId, dan lainnya mungkin diperlukan oleh berbagai add-on (misalnya, Elastic Load Balancing Controller). Parameter apa pun yang mirip dengan ini yang diketahui oleh EKS layanan Amazon akan secara otomatis disuntikkan oleh EKS add-on Amazon, dan tidak memikul tanggung jawab pengguna untuk menentukan sebagai opsi konfigurasi. Parameter ini meliputi:

  • AWS wilayah

  • Nama EKS klaster Amazon

  • VPCID dari cluster

  • Registri kontainer, khusus untuk akun build-prod, yang digunakan oleh add-on jaringan

  • DNSIP cluster, khusus untuk add-on coredns

  • Titik API akhir EKS klaster Amazon

  • IPv4diaktifkan pada cluster

  • IPv6diaktifkan pada cluster

  • Delegasi awalan untuk IPv6 diaktifkan di cluster

Penyedia add-on perlu memastikan Anda memiliki template yang ditentukan untuk parameter yang berlaku tersebut. Masing-masing parameter di atas akan memiliki parameterType atribut yang telah ditentukan sebelumnya yang ditentukan oleh AmazonEKS. Metadata rilis akan menentukan pemetaan antara dan. 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 Parameter seperti di atas yang EKS perlu disuntikkan Amazon secara dinamis harus dikecualikan dari file skema.

Contoh pemetaan dari metadata rilis

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

Berikut ini adalah parameter yang tidak disarankan untuk dapat dikonfigurasi dalam file skema Helm yang dihadapi pelanggan. Entah parameter harus memiliki default yang tidak dapat dimodifikasi, atau tidak disertakan sama sekali dalam template add-on.

Parameter Deskripsi Haruskah memiliki default?
gambar Container image yang akan di-deploy pada cluster Kubernetes. Tidak, dikelola melalui definisi add-on
imagePullSecrets Mengkonfigurasi pod untuk menggunakan rahasia untuk menarik dari registri pribadi. N/A
livenessProbe Proses Kubelet menggunakan liveness probe untuk mengetahui kapan harus me-restart sebuah container. Misalnya, liveness probe dapat menangkap kebuntuan, di mana aplikasi berjalan, tetapi tidak dapat membuat kemajuan. Memulai ulang wadah dalam keadaan seperti itu dapat membantu membuat aplikasi lebih tersedia meskipun ada bug. Ya
readinessProbe Penting bahwa Anda memiliki probe kesiapan untuk wadah Anda. Dengan cara ini proses Kubelet yang berjalan di pesawat data Anda akan tahu kapan container siap melayani lalu lintas. Sebuah Pod dianggap siap ketika semua kontainernya sudah siap. Salah satu penggunaan sinyal ini adalah untuk mengontrol Pod mana yang digunakan sebagai backend untuk Layanan. Ketika sebuah Pod tidak siap, Pod akan dihapus dari Service load balancer. Ya
startupProbe Kubelet menggunakan probe startup untuk mengetahui kapan aplikasi container telah dimulai. Jika probe seperti itu dikonfigurasi, itu menonaktifkan pemeriksaan keaktifan dan kesiapan hingga berhasil, memastikan probe tersebut tidak mengganggu startup aplikasi. Ini dapat digunakan untuk mengadopsi pemeriksaan keaktifan pada kontainer awal yang lambat, menghindari mereka dibunuh oleh kubelet sebelum mereka aktif dan berjalan. Opsional
podDisruptionBudget Tentukan Pod Discruption Budget (PDB) untuk memastikan jumlah minimum PODS tetap berjalan selama gangguan sukarela. A PDB membatasi jumlah Pod dari aplikasi yang direplikasi yang turun secara bersamaan dari gangguan sukarela. Misalnya, aplikasi berbasis kuorum ingin memastikan bahwa jumlah replika yang berjalan tidak pernah dibawa di bawah angka yang dibutuhkan untuk kuorum. Front end web mungkin ingin memastikan bahwa jumlah replika yang melayani beban tidak pernah turun di bawah persentase tertentu dari total. Ya, jika default ke lebih dari dua replika
serviceAccount (nama) Nama pod akun layanan akan berjalan di bawah. Ya
serviceAccount (anotasi) Anotasi diterapkan ke akun layanan. Biasanya digunakan untuk fitur IAM Peran untuk Akun Layanan Tidak, peran akun IAM layanan ARN diatur di EKS add-on API Amazon tingkat atas. Pengecualian untuk aturan ini adalah jika add-on Anda memiliki beberapa penerapan/pengontrol (seperti Flux) dan memerlukan peran terpisah. IRSA ARNs
priorityClassName Prioritas menunjukkan pentingnya sebuah Pod relatif terhadap Pod lainnya. Jika Pod tidak dapat dijadwalkan, scheduler akan mencoba untuk mencegah (mengusir) Pod prioritas yang lebih rendah untuk memungkinkan penjadwalan Pod yang tertunda. Ya. Sebagian besar add-on sangat penting untuk fungsionalitas cluster, dan harus memiliki kelas prioritas yang ditetapkan secara default.
podSecurityContext Konteks keamanan mendefinisikan pengaturan hak istimewa dan kontrol akses untuk Pod atau Container. Biasanya digunakan untuk mengatur fsGroup - yang diperlukan untuk IRSA di v1.19 dan cluster yang lebih rendah. Tidak mungkin, mengingat Amazon EKS tidak lagi mendukung Kubernetes v1.19
securityContext Konteks keamanan mendefinisikan pengaturan hak istimewa dan kontrol akses untuk Pod atau Container. Ya
updateStrategy Menentukan strategi yang digunakan untuk mengganti Pod lama dengan yang baru. Ya
nameOverride Ganti nama pod. Tidak
podSecurityPolicy

Menegakkan pembatasan pada parameter.

 Tidak - tidak PSPs digunakan lagi
extraVolumeMounts/extraVolumes

Digunakan untuk IRSA di EKS cluster non Amazon.

Tidak