Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Certificados personalizados y administración de DNS de Route 53 para HyperPod inferencia

Los siguientes pasos le muestran cómo usar sus propios certificados ACM para los puntos finales de HyperPod inferencia y, si lo desea, configurar el operador para que administre los registros DNS de Route 53 para su dominio personalizado.

Con los certificados personalizados, usted proporciona un ARN de certificado ACM y el operador lo adjunta al Application Load Balancer (ALB), supervisa su estado y admite la detección automática de renovaciones. El operador admite los certificados ACM de confianza pública, los certificados de CA AWS privados y los certificados importados de entidades de certificación externas.

Los certificados personalizados se pueden usar solos o combinados con la administración de DNS de Route 53. La administración de DNS de Route 53 requiere un certificado personalizado y usa el nombre de dominio de la configuración del certificado para crear y administrar registros de DNS.

Requisitos previos

Antes de comenzar, compruebe que:

Configurar los permisos de IAM

La función de ejecución del operador de inferencia requiere permisos adicionales para los certificados personalizados y la administración de DNS de Route 53. Agregue las siguientes políticas a su función de ejecución de HyperPod inferencias.

Permisos de ACM y Amazon S3 para certificados personalizados

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ACMCustomCertificateAccess",
            "Effect": "Allow",
            "Action": [
                "acm:DescribeCertificate",
                "acm:GetCertificate"
            ],
            "Resource": "arn:aws:acm:<region>:<account-id>:certificate/*"
        },
        {
            "Sid": "S3CertificateUpload",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectTagging"
            ],
            "Resource": "arn:aws:s3:::<tls-certificate-bucket>/*",
            "Condition": {
                "StringEquals": {
                    "s3:RequestObjectTag/CreatedBy": "HyperPodInference"
                }
            }
        }
    ]
}

Permisos de Route 53 para la administración de DNS

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Route53DNSManagement",
            "Effect": "Allow",
            "Action": [
                "route53:GetHostedZone",
                "route53:ListResourceRecordSets",
                "route53:ChangeResourceRecordSets"
            ],
            "Resource": "arn:aws:route53:::hostedzone/<hosted-zone-id>"
        }
    ]
}

Sustituya <region> <account-id><tls-certificate-bucket>,, y <hosted-zone-id> por sus valores reales. Puede limitar el ARN del recurso ACM a certificados específicos para aumentar la seguridad.

Configure un certificado personalizado

Para usar un certificado personalizado, agrega la customCertificateConfig sección tlsConfig a tu JumpStartModel especificación InferenceEndpointConfig o. Los dnsConfig campos tlsConfig y son idénticos en ambos CRD.

Los siguientes campos están disponibles en customCertificateConfig ytlsConfig:

El siguiente es un ejemplo de archivo YAML para crear un punto final con un certificado personalizado.

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-model
  namespace: my-namespace
spec:
  modelName: my-llm
  instanceType: ml.g5.24xlarge
  invocationEndpoint: v1/chat/completions
  replicas: 2
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: my-model-bucket
      region: us-west-2
    modelLocation: models/my-llm
  tlsConfig:
    customCertificateConfig:
      acmArn: arn:aws:acm:us-west-2:123456789012:certificate/abc12345-1234-1234-1234-abc123456789
      domainName: api.example.com
    tlsCertificateOutputS3Uri: s3://my-tls-bucket
  worker:
    image: my-inference-image:latest
    modelInvocationPort:
      containerPort: 8000
      name: http
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model
    resources:
      limits:
        nvidia.com/gpu: "4"
      requests:
        cpu: "6"
        memory: 30Gi
        nvidia.com/gpu: "4"

Puede añadirlo customCertificateConfig a una implementación que ya esté en ejecución. El operador detecta el cambio en la siguiente reconciliación, valida el certificado, lo adjunta al ALB y carga el certificado público en Amazon S3. No se requiere ningún tiempo de inactividad ni redespliegue.

Configurar la administración de DNS de Route 53

La administración de DNS de Route 53 requiere la configuración de un certificado personalizado y utiliza el nombre de dominio desdetlsConfig.customCertificateConfig.domainName. Si no ha configurado un certificado personalizado, consulte Configure un certificado personalizado primero.

Para habilitar la administración de DNS de Route 53, agrega la dnsConfig sección a tus especificaciones:

spec:
  tlsConfig:
    customCertificateConfig:
      acmArn: arn:aws:acm:us-west-2:123456789012:certificate/abc12345-1234-1234-1234-abc123456789
      domainName: api.example.com
    tlsCertificateOutputS3Uri: s3://my-tls-bucket
  dnsConfig:
    hostedZoneId: Z1234567890ABC

La dnsConfig sección se puede agregar al mismo customCertificateConfig tiempo o agregarse más adelante a una implementación existente. El operador crea los registros de DNS en la siguiente reconciliación sin necesidad de reiniciar los pods.

Al realizar el despliegue condnsConfig, el operador:

Use un certificado personalizado sin la administración de DNS de Route 53

La administración de DNS de Route 53 es opcional. Si quieres administrar tus propios registros de DNS, omite la dnsConfig sección y configura tu dominio manualmente.

Para encontrar el nombre de host ALB para su implementación, el nombre de entrada depende de si el enrutamiento inteligente está habilitado.

Sin enrutamiento inteligente: la entrada se nombra en su espacio de nombresalb-<deployment-name>.

kubectl get ingress alb-<deployment-name> -n <namespace> \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Con el enrutamiento inteligente: la entrada se nombra en el espacio de nombresalb-<deployment-name>-<namespace>. hyperpod-inference-system

kubectl get ingress alb-<deployment-name>-<namespace> -n hyperpod-inference-system \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Cree un registro de DNS en su proveedor de DNS que dirija su dominio a este nombre de host de ALB:

Verificación del estado de la implementación

Compruebe el estado del certificado personalizado

kubectl describe InferenceEndpointConfig my-model -n my-namespace

Busque la tlsCertificate sección en el estado:

Status:
  Tls Certificate:
    Certificate ARN:    arn:aws:acm:us-west-2:123456789012:certificate/abc12345-...
    Certificate Health: Valid
    Certificate Domain Names:
      api.example.com
    Last Cert Expiry Time: 2027-04-23T00:00:00Z

Valores de salud del certificado:

El operador comprueba la caducidad del certificado cada 24 horas. Cuando detecta que un certificado se ha renovado en ACM (la NotAfter fecha cambia), vuelve a cargar automáticamente el certificado público en Amazon S3 y emite un evento. CertificateRenewed

Compruebe el estado del DNS

Busca la dnsStatus sección:

Status:
  Dns Status:
    Managed By Operator: true
    Record Name:         api.example.com
    Hosted Zone Id:      Z1234567890ABC
    Dns Health:          Active
    Message:             DNS record resolves successfully

Valores de estado del DNS:

Pruebe el punto final implementado

Si configuró la administración de DNS de Route 53, invoque su punto final con su dominio personalizado una vez que se muestre Active el estado del DNS. Si solo configuró un certificado personalizado sin administración de DNS, utilice el nombre de host ALB de la entrada (consulte). Use un certificado personalizado sin la administración de DNS de Route 53

curl -X POST https://api.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "my-llm", "messages": [{"role": "user", "content": "Hello"}]}'

aws sagemaker-runtime invoke-endpoint \
  --endpoint-name my-model \
  --content-type "application/json" \
  --body '{"model": "my-llm", "messages": [{"role": "user", "content": "Hello"}]}' \
  --region us-west-2 \
  --cli-binary-format raw-in-base64-out \
  /dev/stdout

Administre sus certificados personalizados y registros de DNS

Cambiar el dominio o la zona alojada

Puede actualizar el domainName (incustomCertificateConfig) o hostedZoneId (indnsConfig) en una implementación en ejecución. Al cambiar el nombre de dominio, se vuelve a validar el certificado y se cambia el DNS; el nuevo dominio debe ser válido en tu certificado ACM (ya sea si coincide con un SAN o un comodín).

El operador realiza una transición segura:

Durante la transición, tanto los dominios antiguos como los nuevos pasan al ALB. El registro de propiedad del TXT tiene un TTL de 300 segundos (5 minutos), por lo que los clientes DNS pueden almacenar en caché el registro anterior durante un máximo de 5 minutos después de limpiarlo.

Limpieza

Al eliminar la dnsConfig sección InferenceEndpointConfig o eliminarla, el operador elimina automáticamente los registros Route 53 A y TXT que creó. El operador solo elimina los registros de su propiedad (verificados mediante el registro TXT de propiedad).

Resolución de problemas

Siga estos pasos de depuración si su certificado personalizado o la configuración de DNS no funcionan según lo esperado.