Requisitos de produtos baseados em contêineres para AWS Marketplace - AWS Marketplace
Requisitos de segurançaRequisitos de acessoRequisitos de informações do clienteRequisitos de uso do produtoRequisitos de arquiteturaInstruções de uso do produto de contêinerRequisitos para produtos complementares do Amazon EKS

Requisitos de produtos baseados em contêineres para AWS Marketplace

O AWS Marketplace mantém os seguintes requisitos para todos os produtos baseados em contêiner e ofertas no 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 os metadados relacionados são revisados quando enviados para garantir que atendem ou excedem as diretrizes atuais do AWS Marketplace. Analisamos e ajustamos essas políticas para satisfazer nossos crescentes requisitos de segurança e outros requisitos de uso. O AWS Marketplaceverifica continuamente se os produtos existentes continuam atendendo a quaisquer alterações nesses requisitos. Se os produtos não estiverem em conformidade, o AWS Marketplace entrará 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.

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 os produtos baseados em contêiner exigirem acesso para gerenciar recursos da AWS, o acesso deverá ser obtido por meio de perfis do IAM para contas de serviço (se executadas por meio do Amazon Elastic Kubernetes Service (Amazon EKS)) ou perfis do IAM para tarefas (se executadas por meio do Amazon Elastic Container Service (Amazon ECS)) 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 Segurança do ECS e Segurança do EKS.

  • 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 explícito do cliente, exceto conforme exigido por BYOL (traga a 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. As edições Developer, Community e BYOL de software comercial terão suporte se o vendedor fornecer uma versão paga equivalente no 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êiner não devem exigir que o usuário execute o produto usando imagens externas do AWS Marketplace (por exemplo, imagens de contêiner 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 também deverá ser removido do AWS Marketplace.

    • 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, APIs externas 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 também deverá ser removido do AWS Marketplace.

    • 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 o produto for um complemento de outro produto ou produto de outro ISV, a descrição do produto deverá indicar que ele amplia a funcionalidade do outro produto e que, sem ele, 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 do AWS Marketplace devem ser enviadas ao repositório do Amazon Elastic Container Registry (Amazon ECR) do AWS Marketplace. 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êiner devem ser implantados no Amazon ECS, no Amazon EKS ou AWS Fargate.

  • Produtos pagos baseados em contêiner com preços contratuais e integração ao AWS License Manager devem ser implantados no Amazon EKS, Amazon ECS, AWS Fargate, Amazon EKS Anywhere, Amazon ECS Anywhere, Red Hat OpenShift Service na AWS (ROSA), clusters Kubernetes autogerenciados on-premises 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 de instruções de uso de produtos de AMI e contêiner para AWS Marketplace.

Requisitos para produtos complementares do Amazon EKS

Um complemento do Amazon EKS é um software que fornece recursos operacionais para aplicações Kubernetes, mas que não é específico da aplicação. Por exemplo, um complemento do Amazon EKS inclui agentes de observação ou drivers do Kubernetes que permitem que o cluster interaja com recursos da AWS 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 o Amazon EKS. É possível publicar uma versão do produto como um complemento do AWS Marketplace para o catálogo de complemento do Amazon EKS. O complemento aparece no console do Amazon EKS ao lado dos complementos mantidos pela AWS e outros fornecedores. Os compradores podem implantar o software como um complemento com a mesma facilidade com que usam os outros complementos.

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

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

Para publicar o produto de contêiner como complemento do AWS Marketplace, ele deve satisfazer os seguintes requisitos:

  • O produto de contêiner deve ser publicado no AWS Marketplace.

  • O produto de contêiner deve ser construído de forma compatível com as arquiteturas AMD64 e ARM64.

  • O produto de contêiner não deve usar o modelo de preço traga a sua própria licença (BYOL).

    nota

    O BYOL não é compatível com a entrega do complemento do Amazon EKS.

  • Você deve cumprir todos os requisitos de produtos baseados em contêiner, incluindo o envio de todas as imagens de contêiner e charts do Helm para repositórios do ECR gerenciados pelo AWS Marketplace. 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, Galeria pública do Amazon ECR, Docker Hub e Quay.

  • Helm charts: prepare seu software para ser implantado por meio de um chart do Helm. A estrutura complementar do Amazon EKS converte um chart do Helm em um manifesto. Alguns recursos do Helm não são compatíveis com os sistemas Amazon EKS. A lista a seguir descreve os requisitos que devem ser atendidos antes da integração. Nessa lista, todos os comandos do Helm usam o Helm versão 3.8.1:

    • Todos os objetos Capabilities são suportados, com exceção para .APIVersions. .APIVersions não é compatível com os APIs do Kubernetes personalizadas não integradas.

    • Somente os objetos Release.Name e Release.Namespace são compatíveis.

    • Os hooks Helm e as funções lookup não são compatíveis.

    • Todos os gráficos dependentes devem estar localizados no chart do Helm principal (especificado com o arquivo de caminho do repositório://...).

    • O chart do Helm deve passar com sucesso pelo Helm Lint e pelo Helm Template sem erros. O comando é o seguinte:

      • Helm Lint – 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 repositórios AWS Marketplace do Amazon ECR. Para criar um manifesto, use o comando de modelo Helm mostrado anteriormente. Pesquise no manifesto qualquer referência de imagem externa, como imagens busybox ou gcr. Faça upload de todas as imagens do contêiner junto com as dependências nos repositórios do AWS Marketplace Amazon ECR 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, nomear o software aws_mp_configuration_schema.json e empacotá-lo em um invólucro com o chart do Helm, consulte Complementos do Amazon EKS: configuração avançada.

    De acordo com a palavra-chave “$schema”, $schema deve ser um URI que aponte para um recurso válido application/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 instalação pós-complemento ou pré-complemento aos usuários finais. O produto não deve depender de nenhuma licença externa. O produto deve funcionar com base em direitos do AWS Marketplace.

    Para obter mais informações sobre aws_mp_configuration_schema.json, consulte Requisitos de configuração complementar e melhores práticas para fornecedores de complementos.

  • Identifique e crie o namespace no qual o software será implantado em: 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 no AWS Marketplace ou precisar se conectar a outro Serviços da AWS, certifique-se de que o chart do Helm crie serviceAccount por padrão. Se a criação do serviceAccount for feita por um parâmetro em um arquivo values.yaml, 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 chart do Helm não criar o serviceAccount, as permissões não poderão ser vinculadas ao serviceAccount.

  • Implantações ou conjuntos de daemons rastreáveis: certifique-se de que seu chart do Helm tenha um daemonset ou uma implantação. A estrutura de complementos do Amazon EKS rastreia a implantação de seus recursos do Amazon EKS 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.

  • Suporte para arquiteturas AMD e ARM: muitos clientes do Amazon EKS usam o ARM64 atualmente para usar instâncias do AWS Graviton. O software de terceiros deve oferecer suporte a ambas as arquiteturas.

  • Integre-se às APIs de licenciamento ou medição do AWS Marketplace: AWS Marketplace é compatível com vários modelos de cobrança. Para ter mais informações, consulte Integrações de faturamento, medição e licenciamento de produtos de contêiner. Se você quiser vender o produto por meio de mecanismos de PAYG, consulte Configurar a medição personalizada para produtos de contêineres com o Serviço de medição do AWS Marketplace. Se você quiser vender seu produto por meio de um modelo inicial ou de contrato, consulte Preços contratuais para produtos de contêiner com o AWS License Manager.

  • Faça o upload do software e de todos os artefatos e dependências: o chart 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 repositórios Amazon ECR privados do AWS Marketplace sob a mesma lista do 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.

  • Perfil do IAM: liste todas as políticas AWS Identity and Access Management (IAM) necessárias para que seu software funcione ou se conecte a outros Serviços da AWS.

  • Atualizações de versão: o Amazon EKS lança novas versões do Kubernetes algumas semanas após o lançamento upstream. À medida que as novas versões do cluster Amazon EKS 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 a nova versão do cluster Amazon EKS. 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 aprimore o Kubernetes ou o Amazon EKS: Gitops | monitoramento | registro em log | gerenciamento de certificados | gerenciamento de políticas | gerenciamento de custos | escalonamento automático | armazenamento | kubernetes-management | service-mesh | etcd-backup | ingress-service-type | balanceador de carga | registro local| rede | segurança | backup | ingress-controller | observabilidade

  • O software não pode ser a Container Network Interface (CNI).

  • O software deve ser vendido através do AWS Marketplace e integrado às APIs de licenciamento e medição de produtos pagos. Produtos BYOL não são aceitos.

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

O Amazon EKS exige configuração como uma string de esquema Helm JSON de provedores complementares. Os complementos que precisam das configurações necessárias ou permitem configurações opcionais devem incluir um arquivo aws_mp_configuration_schema.json com o chart do Helm enviado para AWS Marketplace. O Amazon EKS usará esse esquema para validar a entrada de configuração dos clientes e rejeitar chamadas de API 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, nodeSelector etc.

  • Configurações específicas do complemento, como chave de licença, ativação de recursos, URLs etc.

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

O Amazon EKS recomenda seguir as melhores práticas de configuração dos complementos do Amazon EKS.

Requisitos de esquema

Ao definir o esquema json, certifique-se de usar uma versão do jsonschema compatível com os complementos do 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 os complementos do Amazon EKS 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 para as propriedades do esquema. Essa descrição será usada para renderizar nomes de rótulos no console Amazon EKS para cada parâmetro de configuração.

Definição de RBAC

Os provedores de complementos precisam definir e fornecer as permissões de RBAC necessárias para instalar o complemento com êxito usando o princípio do privilégio mínimo. Se as permissões do RBAC precisarem ser alteradas para versões mais recentes do complemento ou quaisquer correções para abordar um CVE, os provedores de complementos precisarão informar a equipe do Amazon EKS 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 a complementos que precisam que os clientes configurem informações secretas, como chave de aplicativo, chave de API, senha etc. Atualmente, as APIs do Amazon EKS não suportam 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 complemento AWS Distro para OpenTelemetry.

"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.

Parameter 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 campo nodeSelector à especificação do 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
tolerations As tolerâncias são aplicadas aos frutos. As tolerâncias permitem que o programador programe pods com taints correspondentes. As tolerâncias permitem o agendamento, mas não garantem o agendamento. Talvez, mais comum com daemonsets
affinity O recurso de afinidade consiste em dois tipos de afinidade: a afinidade de nós funciona como o campo nodeSelector, mas é mais expressiva e permite especificar regras flexíveis; a afinidade/antiafinidade entre pods permite restringir os pods aos rótulos de outros pods. Talvez
topologySpreadConstraints Você pode usar restrições de dispersão de topologia para controlar como os pods são distribuídos nó 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 alcançar alta disponibilidade, bem como a utilização eficiente de 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 de workload, talvez seja necessário separar os componentes de nível superior no Esquema, quando necessário. Por exemplo, o driver CSI do Amazon EBS 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 esquema JSON 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 em values.yaml corresponda ao do esquema e dos dois artefatos (values.schema.json e values.yaml) permaneça sincronizado sempre que forem feitas alterações no chart do 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"
            ]
          }

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

Parâmetros de metadados de cluster como clusterName, region, 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 serviço Amazon EKS será automaticamente injetado pelos complementos do Amazon EKS e não será da responsabilidade do usuário especificar como opção de configuração. Esses parâmetros incluem:

  • Região AWS

  • Nome do cluster do Amazon EKS

  • ID de VPC do cluster

  • Registro de contêineres, especificamente para contas build-prod, que é usado por complementos de rede

  • IP do cluster DNS, especificamente para o complemento coredns

  • Endpoint de API de cluster do Amazon EKS

  • IPv4 habilitado no cluster

  • IPv6 habilitado no cluster

  • Delegação de prefixo para IPv6 habilitada 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 atributo parameterType predefinido definido pelo Amazon EKS. Os metadados da versão especificarão o mapeamento entre parameterType e o nome/caminho do parâmetro no modelo. Dessa forma, os valores podem ser transmitidos dinamicamente pelo Amazon EKS sem exigir que os clientes os especifiquem por meio de configurações, além de oferecer flexibilidade aos provedores complementares para definir seu próprio nome/caminho de modelo. Parâmetros como os acima, que o 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.

Parameter 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 backends 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 essa sonda estiver configurada, ela desativa as verificações de atividade e prontidão até que seja bem-sucedida, garantindo que essas sondas 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 que um número mínimo de PODS continue funcionando durante interrupções voluntárias. Um PDB limita o número de pods de uma aplicação replicada que ficam inativas simultaneamente devido a interrupções voluntárias. Por exemplo, uma aplicação baseada 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 frontend 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 perfil do IAM para contas de serviço Não, o ARN da função da conta de serviço do IAM está definido na API de complementos de alto nível do Amazon EKS. Uma exceção a essa regra é se seu complemento tiver várias implantações/controladores (como o Flux) e exigir ARNs de função IRSA separados.
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 todos os contêineres em um pod. Normalmente usado para definir o fsGroup, o que era necessário para o IRSA em clusters v1.19 e inferiores. Improvável, já que o Amazon EKS não é mais compatível com o Kubernetes v1.19
securityContext Um contexto de segurança define as configurações de privilégio e controle de acesso para todos os contêineres em um pod. 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 - os PSPs estão obsoletos
extraVolumeMounts/extraVolumes

Usado para IRSA em clusters que não são do Amazon EKS.

Não