Requisitos de productos basados en contenedores para AWS Marketplace - AWS Marketplace
Requisitos de seguridadRequisitos de accesoRequisitos de información del clienteRequisitos de uso del productoRequisitos relativos a la arquitecturaInstrucciones de uso del producto de contenedorRequisitos de los productos complementarios de Amazon EKS

Requisitos de productos basados en contenedores para AWS Marketplace

AWS Marketplace mantiene los siguientes requisitos para todos los productos y ofertas basados en contenedores en AWS Marketplace. Estos requisitos ayudan a promover un catálogo seguro y fiable para nuestros clientes. También animamos a los vendedores a revisar la implementación de controles y protocolos adicionales, según proceda, para satisfacer las necesidades de sus productos específicos.

Todos los productos y sus metadatos relacionados se revisan cuando se envían para garantizar que cumplan o superen los requisitos de AWS Marketplace actuales. Revisamos y ajustamos estas políticas para adaptarlas a nuestros requisitos de seguridad en evolución y otros requisitos de uso. AWS Marketplace verifica continuamente que los productos existentes cumplan continuamente cualquier cambio en estos requisitos. Si los productos no cumplen las normas, AWS Marketplace se pondrá en contacto con usted para actualizarlos. En algunos casos, es posible que su producto no esté disponible temporalmente para los nuevos suscriptores hasta que se resuelvan los problemas.

Requisitos de seguridad

Todos los productos basados en contenedores deben cumplir los siguientes requisitos de seguridad:

  • Las imágenes de los contenedores de Docker deben estar libres de cualquier malware, virus o vulnerabilidad conocidos. Cuando agrega una nueva versión a su producto de contenedor, se escanean las imágenes de los contenedores incluidas en la versión.

  • Si sus productos basados en contenedores requieren acceso para administrar los recursos de AWS, el acceso debe realizarse mediante roles de IAM para las cuentas de servicio (si se ejecutan a través de Amazon Elastic Kubernetes Service [Amazon EKS]) o roles de IAM para las tareas (si se ejecutan a través de Amazon Elastic Container Service [Amazon ECS]) en lugar de solicitar una clave de acceso a los usuarios.

  • Los productos basados en contenedores solo requerirán privilegios mínimos para funcionar. Para obtener más información, consulte Seguridad de ECS y Seguridad de EKS.

  • De forma predeterminada, las imágenes de los contenedores deben configurarse para que se ejecuten con privilegios que no sean de tipo raíz.

Requisitos de acceso

Todos los productos basados en contenedores deben cumplir los siguientes requisitos de acceso:

  • Los productos basados en contenedores deben usar una contraseña inicial aleatoria. Los productos basados en contenedores no deben utilizar contraseñas iniciales fijas o en blanco para el acceso administrativo externo (por ejemplo, para iniciar sesión en la aplicación a través de una interfaz web). Se debe solicitar al comprador esta contraseña aleatorizada para poder establecer o cambiar sus propias credenciales.

  • Los clientes deben aceptar y habilitar explícitamente cualquier acceso externo a la aplicación.

Requisitos de información del cliente

Todos los productos basados en contenedores deben cumplir los siguientes requisitos de información del cliente:

  • El software no debe recopilar ni exportar datos del cliente sin su conocimiento y consentimiento expreso, tal y como exige BYOL (Bring Your Own License). Las aplicaciones que recopilan o exportan datos de clientes deben seguir estas pautas:

    • La recopilación de los datos de los clientes debe ser de tipo autoservicio, automatizada y segura. Los compradores no deben tener que esperar a que los vendedores aprueben la implementación del software.

    • Los requisitos relativos a los datos de los clientes deben estar claramente indicados en la descripción o en las instrucciones de uso del anuncio. En concreto, se deberá incluir la información que se recopila, la ubicación en la que se almacenarán los datos del cliente y cómo se utilizarán. Por ejemplo, este producto recopila su nombre y dirección de correo electrónico. Esta información es enviada y almacenada por <nombre de la empresa>. Esta información solo se utilizará para contactar con el comprador en relación con <nombre del producto>.

    • No se debe recopilar información de pago.

Requisitos de uso del producto

Todos los productos basados en contenedores deben cumplir los siguientes requisitos de uso del producto:

  • Los vendedores solo pueden publicar productos que funcionen correctamente. No se permiten productos con una versión beta o con una versión preliminar para prueba o evaluación. Se admiten las ediciones para desarrolladores, comunitarias y BYOL del software comercial si el vendedor proporciona una versión de pago equivalente en AWS Marketplace en un plazo de 90 días a partir de la fecha de entrega de la edición gratuita.

  • Las instrucciones de uso de un producto basado en contenedores deben incluir todos los pasos necesarios para implementar los productos basados en contenedores. Las instrucciones de uso deben incluir comandos y recursos de implementación que apunten a las imágenes del contenedor correspondiente en AWS Marketplace.

  • Los productos basados en contenedores deben incluir todas las imágenes de contenedor que el suscriptor necesite para utilizar el software. Además, los productos basados en contenedores no deben requerir que el usuario lance el producto con imágenes fuera de AWS Marketplace (por ejemplo, imágenes de contenedor de repositorios de terceros).

  • Los contenedores y su software deben poder implementarse en forma de autoservicio y no deben requerir métodos de pago ni costes adicionales. Las aplicaciones que requieren dependencias externas durante la implementación deben seguir estas pautas:

    • El requisito debe indicarse en la descripción o en las instrucciones de uso del listado. Por ejemplo, este producto requiere una conexión a Internet para implementarse correctamente. Los siguientes paquetes se descargan durante la implementación: <lista del paquete>.

    • Los vendedores son responsables del uso, y de garantizar la disponibilidad y seguridad de todas las dependencias externas.

    • Si las dependencias externas ya no están disponibles, también se debe retirar el producto de AWS Marketplace.

    • Las dependencias externas no deben requerir métodos de pago ni costes adicionales.

  • Los contenedores que requieran una conexión continua a recursos externos que no estén bajo el control directo del comprador (por ejemplo, API externas o Servicios de AWS administrados por el vendedor o un tercero) deben seguir estas pautas:

    • El requisito debe indicarse en la descripción o en las instrucciones de uso del listado. Por ejemplo, Este producto requiere una conexión a Internet continua. Se requieren los siguientes servicios externos continuos para funcionar correctamente: <lista de recursos>.

    • Los vendedores son responsables del uso, y de garantizar la disponibilidad y seguridad de todos los recursos externos.

    • Si los recursos externos ya no están disponibles, el producto también debe retirarse de AWS Marketplace.

    • Los recursos externos no deben requerir métodos de pago ni costes adicionales y la configuración de la conexión debe ser automática.

  • El software y los metadatos del producto no deben contener lenguaje que redirija a los usuarios a otras plataformas de nube, productos adicionales ni servicios de venta incremental que no estén disponibles en AWS Marketplace.

  • Si su producto es un complemento de otro producto o de un producto de otro proveedor de software independiente, en la descripción del producto se debe indicar que amplía la funcionalidad del otro producto y que, sin él, su utilidad es muy limitada. Por ejemplo, Este producto amplía la funcionalidad de <nombre del producto> y, sin él, su utilidad es muy limitada. Tenga en cuenta que es posible que <nombre del producto> necesite su propia licencia para obtener todas las funciones de este listado.

Requisitos relativos a la arquitectura

Todos los productos basados en contenedores deben cumplir los siguientes requisitos relacionados con la arquitectura:

  • Las imágenes del contenedor de origen para AWS Marketplace deben enviarse al repositorio Amazon Elastic Container Registry (Amazon ECR) propiedad de AWS Marketplace. Puede crear estos repositorios en AWS Marketplace Management Portal en la sección de productos del servidor para cada uno de sus listados de productos de contenedor.

  • Las imágenes de contenedor deben estar basadas en Linux.

  • Los productos de pago basados en contenedores deben poder implementarse en Amazon ECS, Amazon EKS o AWS Fargate.

  • Los productos de pago basados en contenedores con precios por contrato y una integración en AWS License Manager deben desplegarse en Amazon EKS, Amazon ECS, AWS Fargate, Amazon EKS Anywhere, Amazon ECS Anywhere, Red Hat OpenShift Service en AWS (ROSA), clústeres de Kubernetes autoadministrados de forma local o en Amazon Elastic Compute Cloud.

Instrucciones de uso del producto de contenedor

Al crear las instrucciones de uso para su producto de contenedor, siga los pasos y las instrucciones de Creación de instrucciones de uso de productos de AMI y contenedor para AWS Marketplace.

Requisitos de los productos complementarios de Amazon EKS

Un complemento de Amazon EKS es un software que proporciona capacidades operativas para aplicaciones de Kubernetes, pero no es específico de la aplicación. Por ejemplo, un complemento de Amazon EKS incluye agentes de observabilidad o controladores de Kubernetes que permiten al clúster interactuar con recursos de AWS subyacentes para redes, computación y almacenamiento.

Como vendedor de productos de contenedor, puede elegir entre varias opciones de implementación, incluido Amazon EKS. Puede publicar una versión del producto como complemento de AWS Marketplace en el catálogo de complementos de Amazon EKS. El complemento aparece en la consola de Amazon EKS junto a los complementos mantenidos por AWS y otros proveedores. Sus compradores pueden implementar el software como complemento de la misma manera que lo hacen con otros complementos.

Para obtener más información, consulte Complementos de Amazon EKS en la Guía del usuario de Amazon EKS.

Preparación del producto de contenedor como complemento de AWS Marketplace

Para publicar su producto de contenedor como complemento de AWS Marketplace, debe cumplir los siguientes requisitos:

  • Su producto de contenedor debe estar publicado en AWS Marketplace.

  • El producto de contenedor debe estar diseñado de forma compatible con las arquitecturas AMD64 y ARM64.

  • Su producto de contenedor no debe usar el modelo de precios Bring Your Own License (BYOL).

    nota

    BYOL no es compatible para la entrega de complemento de Amazon EKS.

  • Debe cumplir todos los requisitos de los productos basados en contenedores, incluido el envío de todas las imágenes de los contenedores y los gráficos de Helm a los repositorios de ECR administrados de AWS Marketplace. Este requisito incluye imágenes de código abierto, por ejemplo, nginx. Las imágenes y los gráficos no se pueden alojar en otros repositorios externos, incluidos, entre otros, Amazon ECR Public Gallery, Docker Hub y Quay.

  • Gráficos de Helm: prepare el software para implementarlo mediante un gráfico de Helm. El marco de complementos de Amazon EKS convierte un gráfico de Helm en un manifiesto. Algunas características de Helm no son compatibles con los sistemas de Amazon EKS. En la siguiente lista se describen los requisitos que deben cumplirse antes de la incorporación. En esta lista, todos los comandos Helm utilizan la versión 3.8.1 de Helm:

    • Se admiten todos los objetos de Capabilities, con la excepción de .APIVersions. .APIVersions no es compatible con las API de Kubernetes personalizadas no integradas.

    • Solo se admiten los objetos , Release.Name y Release.Namespace.

    • Los enlaces de Helm y la función de lookup no se admiten.

    • Todos los gráficos dependientes deben estar ubicados dentro del gráfico principal de Helm (especificado con la ruta del repositorio archivo://...).

    • El gráfico de Helm debe superar correctamente Helm Lint y Helm Template sin errores. Los comandos son los siguientes:

      • Helm Lint: helm lint helm-chart

        Entre los problemas más habituales se incluyen gráficos no declarados en los metadatos del gráfico principal. Por ejemplo, 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

        Apruebe cualquier configuración anulada con el indicador —f.

    • Guarde todos los archivos binarios de los contenedores en los repositorios de AWS Marketplace Amazon ECR. Para crear un manifiesto, utilice el comando de plantilla Helm que se muestra anteriormente. Busque en el manifiesto cualquier referencia a imágenes externas, como imágenes busybox o imágenes gcr. Cargue todas las imágenes de contenedor junto con las dependencias en los repositorios de AWS Marketplace Amazon ECR creados mediante la opción Agregar repositorio en el menú desplegable de solicitudes.

  • Configuración personalizada: puede añadir variables personalizadas durante la implementación. Para obtener información sobre cómo identificar la experiencia del usuario final, asignar un nombre al software aws_mp_configuration_schema.json y empaquetarlo en un contenedor con el gráfico de Helm, consulte Amazon EKS add-ons: Advanced configuration.

    Según la palabra clave “$schema”, $schema debe ser un URI que apunte a un recurso de application/schema+json válido.

    Este archivo no debe aceptar información confidencial, como contraseñas, claves de licencia y certificados.

    Para gestionar las instalaciones secretas y certificadas, puede proporcionar a los usuarios finales los pasos de instalación previos o posteriores a la instalación del complemento. El producto no debe depender de ninguna licencia externa. El producto debe funcionar en función de los derechos de AWS Marketplace.

    Para obtener más información acerca de las limitaciones de aws_mp_configuration_schema.json, consulte Requisitos de configuración de complementos y mejores prácticas para proveedores de complementos.

  • Identifique y cree el espacio de nombres en el que se implementará el software: en la primera versión del producto, debe identificar el espacio de nombres en el que se implementará el software añadiendo un espacio de nombres con plantilla.

  • Cree la serviceAccount si procede: si el software es de pago en AWS Marketplace o debe conectarse con otro Servicios de AWS, asegúrese de que el gráfico de Helm crea serviceAccount de forma predeterminada. Si la creación de serviceAccount la gestiona un parámetro de un archivo values.yaml, defina el valor del parámetro en true. Por ejemplo, serviceAccount.create = true. Esto es necesario porque el cliente podría optar por instalar el complemento heredando los permisos de la instancia del nodo subyacente, que ya tiene los permisos necesarios. Si el gráfico de Helm no crea la serviceAccount, los permisos no se pueden vincular a la serviceAccount.

  • Implementaciones o daemonsets rastreables: asegúrese de que el gráfico de Helm tenga un daemonset o una implementación. El marco de complementos de Amazon EKS realiza un seguimiento de la implementación de los recursos de Amazon EKS que los usan. Sin una implementación o un daemonset rastreable, el complemento será objeto de un error de implementación. Si el complemento no tiene una implementación o un daemonset, por ejemplo, si despliega varios recursos personalizados o un trabajo de Kubernetes que no se puede rastrear, añada una implementación o un objeto de daemonset ficticio.

  • Compatibilidad con arquitecturas AMD y ARM: muchos clientes de Amazon EKS utilizan ARM64 en la actualidad para utilizar instancias de AWS Graviton. El software de terceros debe ser compatible con ambas arquitecturas.

  • Integración con las API de licencias o medición de AWS Marketplace: AWS Marketplace es compatible con varios modelos de facturación. Para obtener más información, consulte Integraciones de facturación, medición y licencias de productos de contenedor. Si desea vender el producto mediante los mecanismos de PAYG, consulte Configuración de medición personalizada para productos de contenedores con AWS Marketplace Metering Service. Si desea vender el producto mediante un modelo por adelantado o por contrato, consulte Precios por contrato de productos de contenedor con AWS License Manager.

  • Cargue el software y todos los artefactos y dependencias: el gráfico de Helm debe ser independiente y no debe requerir dependencias de orígenes externos, por ejemplo. GitHub. Si el software requiere dependencias externas, las dependencias deben enviarse a los repositorios privados de AWS Marketplace Amazon ECR que se encuentren en la misma publicación de AWS Marketplace.

  • Proporcione instrucciones de implementación en el sitio web: le pedimos que aloje una guía de implementación para que los clientes identifiquen cómo implementar el software mediante el comando create-addon.

  • Roles de IAM: enumere todas las políticas de AWS Identity and Access Management (IAM) necesarias para que el software funcione o se conecte con otros Servicios de AWS.

  • Actualizaciones de versiones: Amazon EKS publica nuevas versiones de Kubernetes unas semanas después de la versión anterior. A medida que las nuevas versiones del clúster de Amazon EKS estén disponibles de forma general, los proveedores disponen de 45 días para certificar o actualizar su software para que sea compatible con la nueva versión del clúster de Amazon EKS. Si sus versiones actuales del complemento son compatibles con la nueva versión de Kubernetes, valide y certifique las mismas para que podamos actualizar la matriz de compatibilidad de versiones. Si se necesita una nueva versión del complemento que sea compatible con el lanzamiento de la nueva versión de Kubernetes, envíe la nueva versión para su incorporación.

  • El software del socio debe pertenecer a uno de los siguientes tipos o ser un software operativo que mejore Kubernetes o Amazon EKS: Gitops | monitorización | registro | administración de certificaciones | administración de políticas | administración de costos | autoescalado | almacenamiento | administración de kubernetes | malla de servicios | copia de seguridad de etcd | tipo de servicios de ingreso | equilibrador de carga | registro local | redes | seguridad | copia de seguridad | controlador de entrada | observabilidad

  • El software no puede ser una interfaz de red de contenedores (CNI).

  • El software debe venderse a través de AWS Marketplace e integrarse con las API de medición y licencias para productos de pago. No se aceptan productos BYOL.

Requisitos de configuración de complementos y mejores prácticas para proveedores de complementos

Amazon EKS requiere la configuración como una cadena de esquema JSON de Helm para los proveedores de complementos. Los complementos que necesiten configuraciones obligatorias o que permitan configuraciones opcionales deben incluir un archivo aws_mp_configuration_schema.json con el gráfico de Helm enviado a AWS Marketplace. Amazon EKS utilizará este esquema para validar la entrada de configuración de los clientes y rechazar las llamadas a la API con valores de entrada que no se ajusten al esquema. Las configuraciones de complementos suelen clasificarse en dos categorías:

  • Configuración de propiedades generales de Kubernetes, como etiquetas, tolerancias, nodeSelector, etc.

  • Configuraciones específicas del complemento, como la clave de licencia, la habilitación de características, las URL, etc.

Esta sección se centra en la primera categoría relacionada con las propiedades generales de Kubernetes.

Amazon EKS recomienda seguir las prácticas recomendadas en relación con la configuración de los complementos de Amazon EKS.

Requisitos de esquema

Al definir el esquema json, asegúrese de utilizar una versión de jsonschema compatible con los complementos de Amazon EKS.

La lista de esquemas compatibles:

  • 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

El uso de cualquier otra versión del esquema json no es compatible con los complementos de Amazon EKS y provocará que el complemento no se pueda lanzar hasta que se solucione este problema.

Ejemplo de archivo de esquema de 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

Los parámetros de configuración deben ser CamelCase y se rechazarán si no se sigue este formato.

Las descripciones son obligatorias

Incluya siempre descripciones significativas de las propiedades del esquema. Esta descripción se utilizará para representar los nombres de las etiquetas en la consola de Amazon EKS para cada parámetro de configuración.

Definición de RBAC

Los proveedores de complementos deben definir y proporcionar los permisos de RBAC necesarios para instalar correctamente el complemento utilizando el principio del privilegio mínimo. Si es necesario cambiar los permisos de RBAC para las versiones más recientes del complemento o correcciones para abordar un CVE, los proveedores de complementos deberán informar al equipo de Amazon EKS acerca de este cambio. Los permisos necesarios para cada recurso de Kubernetes deben restringirse al nombre del recurso del objeto. 

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

Esta sección solo se aplica a los complementos que requieren que los clientes configuren información secreta, como la clave de la aplicación, la clave de API, la contraseña, etc. Actualmente, las API de Amazon EKS no admiten la transmisión de información secreta en texto sin formato, debido a las implicaciones de seguridad. Sin embargo, los clientes pueden usar la configuración para pasar el nombre del Kubernetes Secret que contiene las claves que necesita el complemento. Como requisito previo, los clientes deberán crear objetos de Kubernetes Secret que contengan las claves con el mismo espacio de nombres y, a continuación, pasar el nombre del objeto Secret mediante el blob de configuración al crear el complemento. Recomendamos que los proveedores de complementos asignen un nombre a las propiedades del esquema para que los clientes no lo confundan accidentalmente con la clave real. Por ejemplo: appSecretName, connectionSecretName etc.

En resumen, los proveedores de complementos pueden aprovechar el esquema para permitir a los clientes introducir el nombre del secreto, pero no las claves que realmente contienen el secreto.

Valores de configuración de ejemplo

Puede incluir ejemplos de configuración en su esquema para ayudar a los clientes con la configuración de los complementos. El siguiente ejemplo procede del esquema del 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 comunes que se permiten para la configuración

A continuación se indican los parámetros recomendados en un archivo de esquema de Helm orientado al cliente.

Parámetro Descripción ¿Debería tener un valor predeterminado?
additionalLabels Añada etiquetas de Kubernetes a todos los objetos de Kubernetes administrados por el complemento. No
additionalAnnotations Añada anotaciones de Kubernetes a todos los objetos de Kubernetes administrados por el complemento. No
podLabels Añada etiquetas de Kubernetes a los pods administrados por el complemento. No
podAnnotations Añada anotaciones de Kubernetes a los pods administrados por el complemento. No
logLevel Registre nivel para los componentes administrados por el complemento. Sí
nodeSelector La forma más sencilla recomendada de restricción de selección de nodos. Puede agregar el campo nodeSelector a la especificación del Pod y especificar las etiquetas de nodo que quiere que tenga el nodo de destino. Potencialmente, por ejemplo, solo nodos de Linux
toleraciones Las tolerancias se aplican a los pods. Las tolerancias permiten al programador programar los pods con taints correspondientes. Las tolerancias permiten la programación, pero no garantizan la programación. Tal vez, más común con daemonsets
affinity La característica de afinidad consta de dos tipos de afinidad: la afinidad de nodo funciona como el campo nodeSelector, pero es más expresiva y permite especificar reglas flexibles; la afinidad/antiafinidad entre pods permite restringir los pods según las etiquetas de otros pods. Quizás
topologySpreadConstraints Puede utilizar restricciones de propagación de topología para controlar cómo se distribuyen los pods en el clúster entre dominios de error, como regiones, zonas, nodos y otros dominios de topología que define el usuario. Esto puede ayudar a lograr una alta disponibilidad, así como una utilización eficiente de los recursos. Quizás
resource request/limits Especifique la cantidad de cpu/memoria que necesita cada contenedor. Se recomienda encarecidamente configurar las solicitudes. Los límites son opcionales. Sí
réplicas Número de réplicas de los pods administrados por el complemento. No se aplica a daemonsets. Sí
nota

Para los parámetros de configuración de programación de la carga de trabajo, es posible que necesite separar los componentes de nivel superior del esquema cuando sea necesario. Por ejemplo, el controlador de CSI de Amazon EBS contiene dos componentes principales, el controlador y el agente de nodo; los clientes requieren selectores o tolerancias de nodos diferentes para cada componente.

nota

Los valores predeterminados definidos en el esquema JSON son únicamente para fines de documentación del usuario y no eliminan la necesidad de tener el valor predeterminado legítimo en el archivo values.yaml. Si utiliza la propiedad predeterminada, asegúrese de que la propiedad en values.yaml coincida con la del esquema y de que los dos artefactos (values.schema.json y values.yaml) permanezcan sincronizados siempre que se realicen cambios en el gráfico de 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 comunes que no se permiten para la configuración

Puede que varios complementos (por ejemplo, el controlador de Elastic Load Balancing) requieran parámetros de metadatos de clúster como clusterName, region, vpcId, accountId y otros. Los complementos de Amazon EKS inyectarán automáticamente cualquier parámetro similar a estos que conozca el servicio Amazon EKS y no será responsabilidad del usuario especificarlo como opción de configuración. Entre estos parámetros se incluyen los siguientes:

  • Región AWS

  • Nombre de clúster de Amazon EKS

  • ID de VPC del clúster

  • Registro de contenedores, específicamente para las cuentas de build-prod, que utilizan los complementos de red

  • IP del clúster de DNS, específicamente para el complemento coredns

  • Punto de conexión de API de clúster de Amazon EKS

  • IPv4 habilitado en el clúster

  • IPv6 habilitado en el clúster

  • La delegación de prefijos para IPv6 está habilitada en el clúster

Los proveedores de complementos deben asegurarse de tener definidas las plantillas para dichos parámetros aplicables. Cada uno de los parámetros anteriores tendrá un atributo parameterType predefinido por Amazon EKS. Los metadatos de la versión especificarán la asignación entre el parameterType y la ruta/el nombre del parámetro en la plantilla. De esta forma, Amazon EKS puede transferir los valores de forma dinámica sin necesidad de que los clientes los especifiquen mediante las configuraciones y, además, aporta flexibilidad a los proveedores de complementos para definir su propio nombre/ruta de plantilla. Los parámetros como los anteriores que Amazon EKS necesita inyectar de forma dinámica deben excluirse del archivo de esquema.

Ejemplo de asignación a partir de metadatos de la versión

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

A continuación se indican los parámetros que no se recomienda que puedan configurarse en un archivo de esquema de Helm orientado al cliente. Los parámetros deben tener valores predeterminados no modificables, o bien no incluirse en absoluto en la plantilla del complemento.

Parámetro Descripción ¿Debería tener un valor predeterminado?
imagen Imagen de contenedor que se implementará en el clúster de Kubernetes. No, se administra mediante la definición del complemento
imagePullSecrets Configuración de un pod para usar un secreto y extraerlo de un registro privado. N/A
livenessProbe El proceso de Kubelet utiliza sondeos de estado para saber cuándo reiniciar un contenedor. Por ejemplo, los sondeos de estado podrían detectar un bloqueo en el que una aplicación se está ejecutando pero no progresa. Reiniciar un contenedor en ese estado puede contribuir a que la aplicación esté más disponible a pesar de los errores. Sí
readinessProbe Es importante que tenga un sondeo de preparación para sus contenedores. De esta forma, el proceso de Kubelet que se ejecuta en el plano de datos sabrá cuándo el contenedor está listo para atender el tráfico. Un pod se considera listo preparado cuando todos sus contenedores están listos. Uno de los usos de esta señal es controlar qué pods se utilizan como backends para los servicios. Cuando un pod no está listo, se elimina de los equilibradores de carga del servicio. Sí
startupProbe El kubelet usa sondeos de inicio para saber cuándo se ha iniciado una aplicación de contenedor. Si se configura un sondeo de este tipo, deshabilita las comprobaciones de actividad y preparación hasta que se realice correctamente, asegurándose de que esos sondeos no interfieran con el inicio de la aplicación. Esto se puede utilizar para adoptar comprobaciones de actividad de los contenedores que se inician lentamente y evitar que el kubelet los elimine antes de que estén en funcionamiento. Opcional
podDisruptionBudget Defina un presupuesto de interrupción de pods (PDB) para garantizar que un número mínimo de PODS sigan funcionando durante las interrupciones voluntarias. Un PDB limita la cantidad de pods de una aplicación replicada que están inactivos simultáneamente debido a interrupciones voluntarias. Por ejemplo, una aplicación basada en quórum quiere asegurarse de que el número de réplicas en ejecución nunca sea inferior al número necesario para un quórum. Es posible que un frontend web quiera asegurarse de que la cantidad de réplicas que sirvan a la carga nunca descienda por debajo de un porcentaje determinado del total. Sí, si el valor predeterminado es de más de dos réplicas
serviceAccount (name) Nombre de la cuenta de servicio bajo la que funcionarán los pods. Sí
serviceAccount (annotations) Anotaciones aplicadas a la cuenta de servicio. Normalmente se utiliza para la característica de roles de IAM para cuentas de servicio No, el ARN del rol de la cuenta de servicio de IAM está configurado en la API de complementos de Amazon EKS de nivel superior. Una excepción a esta regla es si el complemento tiene varias implementaciones o controladores (como Flux) y requiere ARN de rol IRSA independientes.
priorityClassName La prioridad indica la importancia de un pod en relación con otros pods. Si no se puede programar un pod, el programador intenta evitar (expulsar) los pods de menor prioridad para poder programar el pod pendiente. Sí. La mayoría de los complementos son fundamentales para la funcionalidad del clúster y deberían tener una clase de prioridad establecida de forma predeterminada.
podSecurityContext Un contexto de seguridad define la configuración de privilegios y control de acceso un pod o un contenedor. Normalmente se utilizaba para configurar fsGroup, que era necesario para IRSA en los clústeres de la versión 1.19 y versiones anteriores. Es poco probable, dado que Amazon EKS ya no es compatible con Kubernetes v1.19
securityContext Un contexto de seguridad define la configuración de privilegios y control de acceso un pod o un contenedor. Sí
updateStrategy Especifica la estrategia utilizada para reemplazar los Pods antiguos por otros nuevos. Sí
nameOverride Anula el nombre de los pods. No
podSecurityPolicy

Aplica restricciones a los parámetros.

 No, los PSP están en desuso
extraVolumeMounts/extraVolumes

Se utiliza para IRSA en clústeres que no son de Amazon EKS.

No