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: + Configure capacidades de inferencia en sus SageMaker HyperPod clústeres de Amazon. Para obtener más información, consulte [Configuración de los HyperPod clústeres para la implementación de modelos](sagemaker-hyperpod-model-deployment-setup.md). + Instalaste [kubectl](https://kubernetes.io/docs/reference/kubectl/) en tu terminal. + Aprovisionó o importó un certificado TLS en ACM en la misma región que su clúster. AWS HyperPod El certificado debe estar en el estado **Emitido** e incluir una cadena de certificados (CA intermedia y raíz). Self-signed Los certificados importados a ACM no se admiten como certificados personalizados porque carecen de una cadena de certificados. + (Para la administración de DNS de Route 53) Creó una zona alojada de Route 53 para su dominio. Se recomiendan las zonas alojadas públicas. Las zonas alojadas privadas funcionan para la creación de registros, pero el operador verifica la resolución del DNS mediante el solucionador de DNS del pod, que se basa en el solucionador de DNS de la VPC. En el caso de las zonas alojadas privadas, la VPC debe tener habilitados la resolución de DNS y los nombres de host DNS, y la zona alojada privada debe estar asociada a la VPC del clúster. ## 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:::certificate/*" }, { "Sid": "S3CertificateUpload", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectTagging" ], "Resource": "arn:aws:s3:::/*", "Condition": { "StringEquals": { "s3:RequestObjectTag/CreatedBy": "HyperPodInference" } } } ] } ``` **nota** Si el nombre de su bucket de Amazon S3 comienza por`hyperpod-tls`, los permisos de Amazon S3 ya están incluidos en la política `AmazonSageMakerHyperPodInferenceAccess` gestionada y solo necesita añadir la declaración ACM. ### 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/" } ] } ``` Sustituya `` ````,, y `` 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` y`tlsConfig`: `tlsConfig.customCertificateConfig.acmArn`(Obligatorio, cadena) El ARN de su certificado ACM. Debe estar en el estado **emitido**. `tlsConfig.customCertificateConfig.domainName`(Obligatorio, cadena) El nombre de dominio del certificado que se va a utilizar. + Debe ser un dominio específico, no un comodín. En el caso de los certificados comodín (por ejemplo,`*.example.com`), especifique el subdominio específico (por ejemplo,). `api.example.com` + Debe estar en minúsculas. + Debe coincidir con uno de los nombres de dominio que figuran en el certificado. `tlsConfig.tlsCertificateOutputS3Uri`(Condicional, cadena) URI de Amazon S3 donde el operador carga el certificado público. Necesario, a menos que el operador se haya instalado con la variable de `TLS_CERTIFICATE_OUTPUT_S3URI` entorno configurada. Si no está seguro de si se configuró, especifíquelo de forma explícita. 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. **importante** Si eliminas la `customCertificateConfig` sección de una implementación en ejecución, el operador vuelve a generar un nuevo certificado autofirmado. Esto reemplaza su CA-signed certificado en el ALB. ## 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 desde`tlsConfig.customCertificateConfig.domainName`. Si no ha configurado un certificado personalizado, consulte [Configure un certificado personalizado](#sagemaker-hyperpod-model-deployment-custom-certs-configure) 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 con`dnsConfig`, el operador: 1. Valida la existencia de la zona alojada y que el dominio pertenece a la zona alojada (por ejemplo, `api.example.com` requiere una zona alojada`example.com`). 1. Comprueba los registros A existentes en el dominio de destino para evitar sobrescrituras accidentales. 1. Crea **un registro A** (alias) que apunta tu dominio a la ALB y un **registro TXT** con un marcador de propiedad (`hyperpod-inference/owner=/`) para evitar conflictos entre puntos finales. No modifique ni elimine el registro TXT manualmente. 1. Consulta la resolución del DNS cada 30 segundos hasta que se resuelva el dominio y, a continuación, marca el estado como`Active`. Si el registro no se resuelve en 10 minutos, el estado pasa a`Error`. **nota** La administración de DNS de Route 53 no bloquea. Los errores en la creación o propagación de los registros DNS no impiden que el punto final de inferencia alcance el `Ready` estado. El punto final permanece accesible a través del nombre de host predeterminado del ALB. Compruebe si hay `dnsStatus` errores en la sección del estado del recurso. DNS-specific ## 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 nombres`alb-`. ``` kubectl get ingress alb- -n \ -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' ``` **Con el enrutamiento inteligente:** la entrada se nombra en el espacio de nombres`alb--`. `hyperpod-inference-system` ``` kubectl get ingress alb-- -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: + **Route 53**: cree **un registro A** con el **alias** activado, que apunte al ALB. + **Otros proveedores de DNS**: crea un **registro CNAME que dirija tu dominio al nombre** DNS de ALB. Los registros CNAME no se pueden usar en el dominio raíz (por ejemplo,`example.com`); usa un subdominio similar. `api.example.com` **nota** Si se vuelve a crear el ALB (por ejemplo, después de eliminar y volver a implementar el punto final), el nombre de host del ALB cambia. Debe actualizar el registro de DNS manualmente. La administración de DNS de Route 53 gestiona esto automáticamente. ## 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: + **Válido**: el certificado está a más de 60 días de caducidad. + **Vencimiento: el** certificado vence en un plazo de 60 días. Se emite un evento de advertencia de Kubernetes ()`CertificateExpiring`. + **Caducado**: el certificado ha caducado. Se emite un evento de advertencia de Kubernetes (`CertificateExpired`). 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: + **Activo**: el registro DNS se resuelve correctamente. Tu dominio personalizado está listo para usarse. + **Pendiente**: se crearon registros DNS en Route 53 pero aún no se han propagado. El operador vuelve a realizar la comprobación cada 30 segundos. + **Error: no** se pudo crear o propagar el registro DNS. Comprueba el `Message` campo para obtener más información. ### 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](#sagemaker-hyperpod-model-deployment-custom-certs-no-dns) ``` curl -X POST https://api.example.com/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "my-llm", "messages": [{"role": "user", "content": "Hello"}]}' ``` **nota** Para invocar a través del punto final de la SageMaker IA, configúrelo en sus especificaciones `InferenceEndpointConfig` o `endpointName` `sageMakerEndpoint.name` en las suyas. `JumpStartModel` Si no `endpointName` se establece, no se crea ningún punto final de SageMaker IA y solo está disponible la invocación directa al ALB. ``` 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` (in`customCertificateConfig`) o `hostedZoneId` (in`dnsConfig`) 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: 1. Crea nuevos registros DNS en la nueva zona o para el nuevo dominio. 1. Comprueba que los nuevos registros se hayan resuelto. 1. Elimina los registros DNS antiguos solo después de confirmar que los nuevos registros están activos. 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. + **La implementación falla debido a un error de acceso a Amazon S3.** Compruebe que el bucket de Amazon S3 especificado en `tlsCertificateOutputS3Uri` existe y se encuentra en la misma región. Compruebe que la función de ejecución del operador tenga `s3:PutObject` `s3:PutObjectTagging` permisos en el bucket. El operador valida el acceso de escritura a Amazon S3 cargando un objeto de prueba de cero bytes durante la implementación inicial. + **La validación del certificado falla.** Compruebe que el certificado ACM esté en el `ISSUED` estado:`aws acm describe-certificate --certificate-arn --region `. Compruebe que `domainName` coincida con un dominio o una SAN del certificado. Para los certificados comodín (`*.example.com`), utilice un subdominio específico, como. `api.example.com` + **Se produce un error al crear el registro DNS.** Compruebe que el ID de la zona alojada sea correcto y que la función de ejecución del operador tenga permisos de Route 53. Compruebe que el dominio pertenezca a la zona alojada (por ejemplo, `api.example.com` requiere una zona alojada para`example.com`). Si ve un conflicto de delegación de NS, utilice en su lugar el ID de zona hospedada de la zona delegada. Si ve un conflicto de registros, significa que otro punto final o proceso externo es propietario del registro A en ese dominio. + **El registro DNS muestra que está pendiente durante un período prolongado.** Compruebe que los registros NS de la zona alojada estén debidamente delegados por el registrador del dominio principal. El operador usa el solucionador de DNS del pod (normalmente CoreDNS), que puede almacenar en caché los resultados. Tras 10 minutos sin resolución, el estado pasa a. `Error` + **Advertencias de caducidad del certificado.** Renueve o sustituya el certificado en ACM. En el caso ACM-issued de los certificados, ACM gestiona la renovación automáticamente. En el caso de los certificados importados, importe un certificado nuevo. El operador detecta la renovación automáticamente y vuelve a cargar el certificado público en Amazon S3.