Requisitos de segurança Requisitos de acesso Requisitos de informações do cliente Requisitos de uso do produto Requisitos de arquitetura Instruções de uso do produto de contêiner Requisitos para produtos EKS complementares da Amazon

Requisitos de produtos baseados em contêineres para AWS Marketplace

AWS Marketplace mantém os seguintes requisitos para todos os produtos e ofertas baseados em contêineres em. AWS Marketplace Esses requisitos ajudam a promover um catálogo seguro e confiável para nossos clientes. Também incentivamos os vendedores a revisar a implementação de controles e protocolos adicionais, conforme aplicável, para atender às necessidades de produtos específicos.

Todos os produtos e seus metadados relacionados são revisados quando enviados para garantir que atendam ou excedam AWS Marketplace os requisitos atuais. Analisamos e ajustamos essas políticas para atender aos nossos crescentes requisitos de segurança e outros requisitos de uso. AWS Marketplace verifica continuamente se os produtos existentes continuam atendendo a quaisquer alterações nesses requisitos. Se os produtos não estiverem em conformidade, AWS Marketplace entraremos em contato com você para atualizar seu produto. Em alguns casos, o produto poderá ficar temporariamente indisponível para novos assinantes até que os problemas sejam resolvidos.

Tópicos

Requisitos de segurança
Requisitos de acesso
Requisitos de informações do cliente
Requisitos de uso do produto
Requisitos de arquitetura
Instruções de uso do produto de contêiner
Requisitos para produtos EKS complementares da Amazon

Requisitos de segurança

Todos os produtos baseados em contêiner devem cumprir os seguintes requisitos de segurança:

As imagens do contêiner do Docker devem estar livres de qualquer malware, vírus ou vulnerabilidade conhecidos. Quando você adiciona uma nova versão ao produto de contêiner, as imagens de contêiner incluídas na versão são verificadas.
Se seus produtos baseados em contêineres exigirem acesso para gerenciar AWS recursos, o acesso deve ser obtido por meio de IAMfunções para contas de serviço (se executadas por meio do Amazon Elastic Kubernetes Service EKS (Amazon IAM)) ou funções para tarefas (se executadas por meio do Amazon Elastic Container Service ECS (Amazon)) em vez de solicitar uma chave de acesso dos usuários.
Os produtos baseados em contêiner devem exigir apenas privilégios mínimos para serem executados. Para obter mais informações, consulte ECSEKSsegurança e proteção.
Por padrão, as imagens de contêiner devem ser configuradas para serem executadas com privilégios não raiz.

Requisitos de acesso

Todos os produtos baseados em contêiner devem cumprir os seguintes requisitos de acesso:

Os produtos baseados em contêiner devem usar uma senha inicial aleatória. Os produtos baseados em contêiner não devem usar senhas iniciais fixas ou em branco para acesso administrativo externo (por exemplo, para fazer login no aplicativo por meio de uma interface da Web). O comprador deve fornecer essa senha aleatória antes de definir ou alterar suas próprias credenciais.
Qualquer acesso externo ao aplicativo deve ser explicitamente acordado e habilitado pelos clientes.

Requisitos de informações do cliente

Todos os produtos baseados em contêiner devem aderir aos requisitos de informações do cliente a seguir:

O software não deve coletar ou exportar dados do cliente sem o conhecimento e o consentimento expresso do cliente, exceto conforme exigido por BYOL (Traga sua própria licença). Os aplicativos que coletam ou exportam dados de clientes devem seguir estas diretrizes:
- A coleta dos dados do cliente deve ser de autoatendimento, automatizada e segura. Os compradores não precisam esperar que os vendedores aprovem a implantação do software.
- Os requisitos de dados do cliente devem ser claramente indicados na descrição ou nas instruções de uso da lista. Isso inclui o que é coletado, o local onde os dados do cliente serão armazenados e como serão usados. Por exemplo, Este produto coleta seu nome e endereço de e-mail. Essas informações são enviadas e armazenadas pela <nome da empresa>. Essas informações serão usadas apenas para entrar em contato com o comprador em relação ao <nome do produto>.
- As informações de pagamento não devem ser coletadas.

Requisitos de uso do produto

Todos os produtos baseados em contêiner devem aderir aos requisitos de uso de produto a seguir:

Os vendedores só podem listar produtos totalmente funcionais. Não são permitidos produtos beta ou em fase de pré-lançamento para fins de teste ou avaliação. Há suporte para desenvolvedores, comunidades e BYOL edições de software comercial se o vendedor fornecer uma versão paga equivalente em AWS Marketplace até 90 dias após o fornecimento da edição gratuita.
Todas as instruções de uso de um produto baseado em contêiner devem incluir todas as etapas para implantar produtos baseados em contêiner. As instruções de uso devem fornecer comandos e recursos de implantação apontando para as imagens de contêiner correspondentes no AWS Marketplace.
Os produtos baseados em contêiner devem incluir todas as imagens de contêiner de que um assinante precisa para usar o software. Além disso, os produtos baseados em contêineres não devem exigir que o usuário inicie o produto usando imagens externas AWS Marketplace (por exemplo, imagens de contêineres de repositórios de terceiros).
Os contêineres e o software devem ser implantados de forma autossuficiente e não devem exigir métodos ou custos adicionais de pagamento. Os aplicativos que exigem dependências externas na implantação devem seguir estas diretrizes:
- O requisito deve ser divulgado na descrição ou nas instruções de uso da lista. Por exemplo, Este produto requer uma conexão com a Internet para ser implantado corretamente. Os pacotes a seguir são baixados na implantação: <lista de pacotes>.
- Os vendedores são responsáveis pelo uso e pela garantia da disponibilidade e segurança de todas as dependências externas.
- Se as dependências externas não estiverem mais disponíveis, o produto AWS Marketplace também deverá ser removido.
- As dependências externas não devem exigir métodos ou custos adicionais de pagamento.
Os contêineres que exigem uma conexão contínua com recursos externos que não estão sob o controle direto do comprador — por exemplo, externos APIs ou Serviços da AWS gerenciados pelo vendedor ou por terceiros — devem seguir estas diretrizes:
- O requisito deve ser divulgado na descrição ou nas instruções de uso da lista. Por exemplo, Este produto requer uma conexão contínua com a Internet. Os seguintes serviços externos contínuos são necessários para funcionar adequadamente: <lista de recursos>.
- Os vendedores são responsáveis pelo uso e pela garantia da disponibilidade e segurança de todos os recursos externos.
- Se os recursos externos não estiverem mais disponíveis, o produto AWS Marketplace também deverá ser removido.
- Os recursos externos não devem exigir métodos de pagamento ou custos adicionais e a configuração da conexão deve ser automatizada.
Os metadados e software do produto não devem conter linguagem que redirecione os usuários para outras plataformas de nuvem, produtos adicionais ou serviços de vendas adicionais que não estão disponíveis no AWS Marketplace.
Se seu produto for um complemento de outro produto ou produto de outra pessoaISV, a descrição do produto deve indicar que ela amplia a funcionalidade do outro produto e que, sem ela, seu produto tem utilidade muito limitada. Por exemplo, Este produto amplia a funcionalidade de <nome do produto> e sem ele, este produto tem uma utilidade muito limitada. Observe que <nome do produto> pode exigir uma licença própria para a funcionalidade completa desta lista.

Requisitos de arquitetura

Todos os produtos baseados em contêiner devem cumprir os seguintes requisitos de arquitetura:

As imagens do contêiner de origem AWS Marketplace devem ser enviadas para o repositório Amazon Elastic Container Registry (AmazonECR) de propriedade AWS Marketplace da. Você pode criar esses repositórios no Portal de gerenciamento do AWS Marketplace nos produtos de servidor para cada uma das suas listas de produtos de contêiner.
As imagens de contêiner devem ser baseadas em Linux.
Os produtos pagos baseados em contêineres devem poder ser implantados na Amazon, ECS Amazon EKS ou. AWS Fargate
Produtos pagos baseados em contêineres com preços contratuais e integração AWS License Manager devem ser implantados na Amazon, AmazonECS, EKS Amazon Anywhere, AWS Fargate Amazon EKS ECS Anywhere, Red Hat OpenShift Service on AWS (ROSA), clusters Kubernetes autogerenciados no local ou no Amazon Elastic Compute Cloud.

Instruções de uso do produto de contêiner

Ao criar as instruções de uso do produto de contêiner, siga as etapas e as orientações em Criação AMI e embalagem de instruções de uso do produto para AWS Marketplace.

Requisitos para produtos EKS complementares da Amazon

Um EKS complemento da Amazon é um software que fornece recursos operacionais para Kubernetes aplicativos, mas não é específico para o aplicativo. Por exemplo, um EKS complemento da Amazon inclui agentes de observabilidade ou Kubernetes drivers que permitem que o cluster interaja com AWS os recursos subjacentes para rede, computação e armazenamento.

Como vendedor de produtos de contêineres, você pode escolher entre várias opções de implantação, incluindo a AmazonEKS. Você pode publicar uma versão do seu produto como um AWS Marketplace complemento no catálogo de EKS complementos da Amazon. Seu complemento aparece no EKS console da Amazon ao lado dos complementos mantidos por AWS e outros fornecedores. Seus compradores podem implantar seu software como um complemento com a mesma facilidade com que usam os outros complementos.

Para obter mais informações, consulte os EKScomplementos da Amazon no Guia do EKS usuário da Amazon.

Preparação do produto de contêiner como um complemento do AWS Marketplace

Para publicar seu produto de contêiner como um AWS Marketplace complemento, ele deve atender aos seguintes requisitos:

Seu produto de contêiner deve ser publicado em AWS Marketplace.
Seu produto de contêiner deve ser construído de forma compatível com ambas AMD64 as ARM64 arquiteturas.
Seu produto de contêiner não deve usar o modelo de preços Bring Your Own License (BYOL).

nota
BYOLnão é compatível com a entrega de EKS complementos da Amazon.
Você deve cumprir todos os requisitos de produtos baseados em contêineres, incluindo o envio de todas as imagens de contêineres e Helm gráficos em ECR repositórios AWS Marketplace gerenciados da Amazon. Esse requisito inclui imagens de código aberto, por exemplo,nginx. Imagens e gráficos não podem ser hospedados em outros repositórios externos, incluindo, mas não se limitando a, Amazon ECR Public Gallery, Docker Hub e Quay.
Helm gráficos - Prepare seu software para ser implantado por meio de um Helm gráfico. A estrutura EKS complementar da Amazon converte um Helm gráfico em um manifesto. Alguns Helm os recursos não são suportados nos EKS sistemas da Amazon. A lista a seguir descreve os requisitos que devem ser atendidos antes da integração. Nesta lista, todos Helm uso de comandos Helm versão 3.8.1:
- Todos os Capabilities objetos são suportados, com exceção de.APIVersions. .APIVersionsnão é compatível com non-built-in customização Kubernetes APIs.
- Somente os Release.Namespace objetos Release.Name e são suportados.
- Helm ganchos e a lookup função não são suportados.
- Todos os gráficos dependentes devem estar localizados dentro do principal Helm gráfico (especificado com o arquivo de caminho do repositório://...).
- A ferramenta Helm o gráfico deve ser aprovado com sucesso Helm Fiapos e Helm Modelo sem erros. Os comandos são os seguintes:
  - Helm Fiapos — helm lint helm-chart
    
    Problemas comuns incluem gráficos não declarados nos metadados do gráfico principal. Por exemplo, chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed
  - Helm Modelo — 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
    
    Passe todas as configurações substituídas com a bandeira. —f
- Armazene todos os binários do contêiner nos ECR repositórios AWS Marketplace da Amazon. Para criar um manifesto, use o Helm comando de modelo que foi mostrado anteriormente. Pesquise no manifesto qualquer referência de imagem externa, como gcr imagens busybox ou. Faça upload de todas as imagens do contêiner junto com as dependências nos ECR repositórios AWS Marketplace da Amazon criados usando a opção Adicionar repositório no menu suspenso de solicitações.
Configuração personalizada — Você pode adicionar variáveis personalizadas durante a implantação. Para obter informações sobre como identificar a experiência do usuário final, nomeie o software aws_mp_configuration_schema.json e empacote-o em um invólucro com o Helm gráfico, consulte EKSComplementos da Amazon: configuração avançada.

De acordo com a palavra-chave “$schema”, $schema deve ser URI aquela que aponta para um recurso válidoapplication/schema+json.

Esse arquivo não deve aceitar nenhuma informação confidencial, como senhas, chaves de licença e certificados.

Para lidar com segredos e instalações de certificados, você pode fornecer etapas de pre-Add-on pós-instalação ou instalação aos usuários finais. O produto não deve depender de nenhuma licença externa. O produto deve funcionar com base em AWS Marketplace direitos.

Para obter mais informações sobre limitações paraaws_mp_configuration_schema.json, consulteRequisitos de configuração complementar e melhores práticas para fornecedores de complementos.
Identifique e crie o namespace no qual o software será implantado — Na primeira versão do seu produto, você deve identificar o namespace no qual o software será implantado adicionando um namespace modelado.
Crie o, serviceAccount se aplicável — Se o software for um software pago ativado AWS Marketplace ou precisar se conectar a outro Serviços da AWS, certifique-se de que o Helm gráfico criado serviceAccount por padrão. Se a serviceAccount criação for feita por um parâmetro em um values.yaml arquivo, defina o valor do parâmetro como. true Por exemplo, serviceAccount.create = true. Isso é necessário porque o cliente pode optar por instalar o complemento herdando as permissões da instância do nó subjacente, que já tem as permissões necessárias. Se o gráfico do Helm não criar oserviceAccount, as permissões não poderão ser vinculadas aoserviceAccount.
Implantações ou conjuntos de daemons rastreáveis — Certifique-se de que seu gráfico do Helm tenha um daemonset ou uma implantação. A estrutura de EKS complementos da Amazon rastreia a implantação de seus EKS recursos da Amazon usando-os. Sem uma implantação rastreável ou um daemonset, seu complemento enfrentará um erro de implantação. Se seu complemento não tiver uma implantação ou um daemonset, por exemplo, se ele implantar vários recursos personalizados ou um trabalho do Kubernetes que não são rastreáveis, adicione uma implantação fictícia ou um objeto daemonset.
Support AMD e ARM arquiteturas — Muitos EKS clientes da Amazon usam ARM64 hoje para usar instâncias AWS Graviton. O software de terceiros deve oferecer suporte a ambas as arquiteturas.
Integre-se ao licenciamento ou à medição APIs do AWS Marketplace — AWS Marketplace suporta vários modelos de cobrança. Para obter mais informações, consulte Integrações de faturamento, medição e licenciamento de produtos de contêiner. Se você quiser vender seu produto por meio de PAYG mecanismos, consulteConfigurando a medição personalizada para produtos de contêineres com o AWS Marketplace Metering Service. Se você quiser vender seu produto por meio de um modelo inicial ou de contrato, consultePreços contratuais para produtos em contêineres com AWS License Manager.
Faça o upload do software e de todos os artefatos e dependências — O gráfico do Helm deve ser independente e não deve exigir dependências de fontes externas, por exemplo, GitHub. Se o software exigir dependências externas, as dependências devem ser enviadas para ECR repositórios privados AWS Marketplace da Amazon na mesma lista. AWS Marketplace
Forneça instruções de implantação em seu site — Solicitamos que você hospede um guia de implantação para que os clientes identifiquem como implantar seu software por meio do comando create-addon.
IAMfunções — Liste todas as AWS Identity and Access Management (IAM) políticas necessárias para que seu software funcione ou se conecte a outros Serviços da AWS.
Atualizações de versão — A Amazon EKS lança novas versões do Kubernetes algumas semanas após o lançamento upstream. À medida que as novas versões do EKS cluster da Amazon se tornam disponíveis ao público em geral, os fornecedores têm 45 dias para certificar ou atualizar seu software para que seja compatível com o lançamento da nova versão do EKS cluster da Amazon. Se suas versões atuais do complemento forem compatíveis com a nova versão do Kubernetes, valide e certifique a mesma para que possamos atualizar a matriz de compatibilidade da versão. Se for necessária uma nova versão complementar para dar suporte à nova versão do Kubernetes, envie a nova versão para integração.
O software do parceiro deve se enquadrar em um dos seguintes tipos ou ser um software operacional que aprimorará o Kubernetes ou o AmazonEKS: Gitops | monitoramento | registro | gerenciamento de certificados | gerenciamento de políticas | gerenciamento de custos | escalonamento automático | armazenamento | gerenciamento de kubernetes | service-mesh | etcd-backup | | balanceador de carga | registro local | rede | segurança | backup | controlador de entrada | observabilidade ingress-service-type
O software não pode ser Container Network Interface (CNI).
O software deve ser vendido AWS Marketplace e integrado ao licenciamento e à medição de produtos APIs pagos. BYOLprodutos não são aceitos.

Requisitos de configuração complementar e melhores práticas para fornecedores de complementos

A Amazon EKS exige a configuração como uma string de JSONesquema Helm dos provedores complementares. Os complementos que precisam das configurações necessárias ou permitem configurações opcionais devem incluir um aws_mp_configuration_schema.json arquivo com o Helm Chart enviado para. AWS Marketplace A Amazon EKS usará esse esquema para validar a entrada de configuração dos clientes e rejeitar API chamadas com valores de entrada que não estejam em conformidade com o esquema. As configurações complementares geralmente se enquadram em duas categorias:

Configuração para propriedades gerais do Kubernetes, como rótulos, tolerâncias etc. nodeSelector
Configurações específicas do complemento, como chave de licença, habilitação de recursos etc. URLs

Esta seção se concentra na primeira categoria relacionada às propriedades gerais do Kubernetes.

EKSA Amazon recomenda seguir as melhores práticas em relação à configuração dos EKS complementos da Amazon.

Requisitos do esquema
Parâmetros comuns que são permitidos para configuração
Parâmetros comuns que não são permitidos para configuração

Requisitos do esquema

Ao definir o esquema json, certifique-se de usar uma versão do jsonschema compatível com os complementos da Amazon. EKS

A lista de esquemas compatíveis:

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

O uso de qualquer outra versão do esquema json é incompatível com EKS os complementos da Amazon e fará com que o complemento não possa ser lançado até que isso seja corrigido.

Exemplo de arquivo de esquema 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

Os parâmetros de configuração devem ser camelCase e serão rejeitados se não seguirem esse formato.

As descrições são obrigatórias

Sempre inclua descrições significativas das propriedades do esquema. Essa descrição será usada para renderizar nomes de rótulos no EKS console da Amazon para cada parâmetro de configuração.

RBACdefinição

Os provedores de complementos precisam definir e fornecer as RBAC permissões necessárias para instalar o complemento com êxito usando o princípio do privilégio mínimo. Se RBAC as permissões precisarem ser alteradas para versões mais recentes do complemento ou quaisquer correções para resolver um problemaCVE, os provedores de complementos precisarão informar a EKS equipe da Amazon sobre essa alteração. As permissões necessárias para cada recurso do Kubernetes devem ser restritas ao nome do recurso do objeto.


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

Gerenciamento de segredos

Esta seção se aplica somente aos complementos que precisam que os clientes configurem informações secretas, como chave do aplicativo, API chave, senha etc. Atualmente, a Amazon EKS APIs não suporta a transmissão de informações secretas em texto simples devido às implicações de segurança. No entanto, os clientes podem usar a configuração para passar o nome do segredo do Kubernetes que contém as chaves necessárias para o complemento. Os clientes precisarão criar objetos secretos do Kubernetes contendo as chaves com o mesmo namespace como etapa de pré-requisito e, em seguida, passar o nome do segredo usando o blob de configuração ao criar o complemento. Recomendamos que os provedores de complementos nomeiem as propriedades do esquema para que os clientes não as confundam acidentalmente com a chave real. Por exemplo: appSecretName, connectionSecretName etc.

Em resumo, os provedores de complementos podem aproveitar o esquema para permitir que os clientes passem o nome do segredo, mas não as chaves que realmente conterão o segredo em si.

Exemplos de valores de configuração

Você pode incluir exemplos de configuração em seu esquema para ajudar os clientes na configuração de complementos. O exemplo a seguir é do esquema do AWS Distro for 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": []
      }
    ]

Parâmetros comuns que são permitidos para configuração

A seguir estão os parâmetros recomendados em um arquivo de esquema do Helm voltado para o cliente.

Parâmetro	Descrição	Deveria ter um padrão?
additionalLabels	Adicione rótulos do Kubernetes a todos os objetos do Kubernetes gerenciados pelo complemento.	Não
additionalAnnotations	Adicione anotações do Kubernetes a todos os objetos do Kubernetes gerenciados pelo complemento.	Não
podLabels	Adicione rótulos do Kubernetes aos pods gerenciados pelo complemento.	Não
podAnnotations	Adicione anotações do Kubernetes aos pods gerenciados pelo complemento.	Não
logLevel	Nível de registro para componentes gerenciados pelo complemento.	Sim
nodeSelector	Forma mais simples recomendada de restrição de seleção de nós. Você pode adicionar o nodeSelector campo à especificação do seu pod e especificar os rótulos dos nós que você deseja que o nó de destino tenha.	Potencialmente, por exemplo, somente nós Linux
tolerâncias	As tolerâncias são aplicadas aos frutos. As tolerâncias permitem que o programador programe pods com as manchas correspondentes. As tolerâncias permitem o agendamento, mas não garantem o agendamento.	Talvez, mais comum com daemonsets
afinidade	O recurso de afinidade consiste em dois tipos de afinidade: a afinidade de nós funciona como o nodeSelector campo, mas é mais expressiva e permite especificar regras flexíveis; a afinidade/antiafinidade entre pods permite que você restrinja os pods aos rótulos de outros pods.	Talvez
topologySpreadConstraints	Você pode usar restrições de distribuição de topologia para controlar como os pods são distribuídos em seu cluster entre domínios de falha, como regiões, zonas, nós e outros domínios de topologia definidos pelo usuário. Isso pode ajudar a obter alta disponibilidade, bem como a utilização eficiente dos recursos.	Talvez
solicitação/limites de recursos	Especifique a quantidade de CPU/memória que cada contêiner precisa. É altamente recomendável que as solicitações sejam definidas. Os limites são opcionais.	Sim
réplicas	Número de réplicas dos pods gerenciados pelo complemento. Não aplicável para daemonsets.	Sim

nota

Para os parâmetros de configuração do agendamento da carga de trabalho, talvez seja necessário separar os componentes de nível superior no Esquema, quando necessário. Por exemplo, o EBS CSI driver da Amazon contém dois componentes principais, controlador e agente de nó. Os clientes precisam de seletores/tolerâncias de nós diferentes para cada componente.

nota

Os valores padrão definidos no JSON esquema são apenas para fins de documentação do usuário e não substituem a necessidade de ter o padrão correto no arquivo. values.yaml Se estiver usando a propriedade padrão, certifique-se de que o padrão in values.yaml corresponda ao do esquema e dos dois artefatos (values.schema.jsonevalues.yaml) permaneça sincronizado sempre que forem feitas alterações no Helm Chart.


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

Parâmetros comuns que não são permitidos para configuração

Parâmetros de metadados de clusterclusterName, comoregion,vpcId,accountId, e outros, podem ser exigidos por vários complementos (por exemplo, Elastic Load Balancing Controller). Qualquer parâmetro semelhante a esses que seja conhecido pelo EKS serviço da Amazon será automaticamente injetado pelos EKS complementos da Amazon e não será da responsabilidade do usuário especificar como opção de configuração. Esses parâmetros incluem:

AWS região
Nome EKS do cluster Amazon
VPCID do cluster
Registro de contêineres, especificamente para contas build-prod, que é usado por complementos de rede
DNSIP do cluster, especificamente para o complemento coredns
APIEndpoint EKS de cluster da Amazon
IPv4habilitado no cluster
IPv6habilitado no cluster
Delegação de prefixo para IPv6 habilitado no cluster

Os provedores de complementos precisam garantir que você tenha modelos definidos para esses parâmetros aplicáveis. Cada um dos parâmetros acima terá um parameterType atributo predefinido definido pela AmazonEKS. Os metadados da versão especificarão o mapeamento entre o. parameterType e o. 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 Parâmetros como os acima, que a Amazon EKS precisa injetar dinamicamente, devem ser excluídos do arquivo do esquema.

Exemplo de mapeamento a partir dos metadados da versão


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

A seguir estão os parâmetros que não devem ser configurados em um arquivo de esquema Helm voltado para o cliente. Os parâmetros devem ter padrões não modificáveis ou não devem ser incluídos no modelo complementar.

Parâmetro	Descrição	Deveria ter um padrão?
image	Imagem do contêiner que será implantada no cluster Kubernetes.	Não, gerenciado por meio da definição de complemento
imagePullSecrets	Configurando um pod para usar um segredo para extrair de um registro privado.	N/D
livenessProbe	O processo Kubelet usa sondas de atividade para saber quando reiniciar um contêiner. Por exemplo, testes de atividade podem detectar um impasse, em que um aplicativo está em execução, mas não consegue progredir. Reiniciar um contêiner nesse estado pode ajudar a tornar o aplicativo mais disponível, apesar dos bugs.	Sim
readinessProbe	É importante que você tenha uma sonda de prontidão para seus contêineres. Dessa forma, o processo Kubelet executado em seu plano de dados saberá quando o contêiner está pronto para atender ao tráfego. Um pod é considerado pronto quando todos os seus contêineres estão prontos. Um uso desse sinal é controlar quais pods são usados como back-ends para serviços. Quando um pod não está pronto, ele é removido dos balanceadores de carga de serviço.	Sim
startupProbe	O kubelet usa testes de inicialização para saber quando um aplicativo de contêiner foi iniciado. Se esse teste estiver configurado, ele desativará as verificações de atividade e prontidão até que seja bem-sucedido, garantindo que esses testes não interfiram na inicialização do aplicativo. Isso pode ser usado para adotar verificações de atividade em contêineres de inicialização lenta, evitando que eles sejam eliminados pelo kubelet antes de serem instalados e funcionando.	Opcional
podDisruptionBudget	Defina um orçamento de interrupção do pod (PDB) para garantir um número mínimo de PODS manutenção em funcionamento durante interrupções voluntárias. A PDB limita o número de pods de um aplicativo replicado que ficam inativos simultaneamente devido a interrupções voluntárias. Por exemplo, um aplicativo baseado em quórum gostaria de garantir que o número de réplicas em execução nunca fique abaixo do número necessário para um quórum. Um front-end da web pode querer garantir que o número de réplicas que atendem à carga nunca caia abaixo de uma certa porcentagem do total.	Sim, se usar como padrão mais de duas réplicas
serviceAccount (nome)	Nome da conta de serviço sob a qual os pods serão executados.	Sim
serviceAccount (anotações)	Anotações aplicadas à conta de serviço. Normalmente usado para o recurso IAM Funções para Contas de Serviço	Não, a função da conta de IAM serviço ARN é definida nos EKS complementos API de alto nível da Amazon. Uma exceção a essa regra é se seu complemento tiver várias implantações/controladores (como o Flux) e exigir uma função separada. IRSA ARNs
priorityClassName	A prioridade indica a importância de um pod em relação a outros pods. Se um pod não puder ser agendado, o programador tentará antecipar (despejar) pods de menor prioridade para possibilitar o agendamento do pod pendente.	Sim. A maioria dos complementos é essencial para a funcionalidade do cluster e deve ter uma classe de prioridade definida por padrão.
podSecurityContext	Um contexto de segurança define as configurações de privilégio e controle de acesso para um pod ou contêiner. Normalmente usado para definir fsGroup - o que era necessário para IRSA clusters v1.19 e inferiores.	Improvável, já que a Amazon EKS não oferece mais suporte ao Kubernetes v1.19
securityContext	Um contexto de segurança define as configurações de privilégio e controle de acesso para um pod ou contêiner.	Sim
updateStrategy	Especifica a estratégia usada para substituir os pods antigos por novos.	Sim
nameOverride	Substitua o nome dos pods.	Não
podSecurityPolicy	Imponha restrições aos parâmetros.	Não - PSPs estão obsoletas
extraVolumeMounts/extraVolumes	Usado IRSA em EKS clusters que não são da Amazon.	Não

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Testando e lançando seu produto

Preços de produtos em contêineres