Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Certificats personnalisés et gestion du DNS Route 53 pour HyperPod Inference

Les étapes suivantes vous montrent comment utiliser vos propres certificats ACM pour les points de terminaison d' HyperPodinférence et éventuellement configurer l'opérateur pour gérer les enregistrements DNS Route 53 pour votre domaine personnalisé.

Avec les certificats personnalisés, vous fournissez un ARN de certificat ACM et l'opérateur l'attache à l'Application Load Balancer (ALB), surveille son état de santé et prend en charge la détection automatique des renouvellements. L'opérateur prend en charge les certificats ACM approuvés par le public, les certificats CA AWS privés et les certificats importés depuis des autorités de certification externes.

Les certificats personnalisés peuvent être utilisés seuls ou combinés à la gestion DNS de Route 53. La gestion du DNS Route 53 nécessite un certificat personnalisé et utilise le nom de domaine indiqué dans la configuration de votre certificat pour créer et gérer les enregistrements DNS.

Conditions préalables

Avant de commencer, vérifiez les points suivants :

Configuration des autorisations IAM

Le rôle d'exécution de l'opérateur d'inférence nécessite des autorisations supplémentaires pour les certificats personnalisés et la gestion du DNS Route 53. Ajoutez les politiques suivantes à votre rôle d'exécution d' HyperPod inférence.

Autorisations ACM et Amazon S3 pour les certificats personnalisés

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

Autorisations Route 53 pour la gestion du 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>"
        }
    ]
}

Remplacez <region><account-id>,<tls-certificate-bucket>, et <hosted-zone-id> par vos valeurs réelles. Vous pouvez étendre l'ARN de la ressource ACM à des certificats spécifiques pour une sécurité renforcée.

Configuration d'un certificat personnalisé

Pour utiliser un certificat personnalisé, ajoutez la customCertificateConfig section à votre JumpStartModel spécification InferenceEndpointConfig ou tlsConfig à votre spécification. Les dnsConfig champs tlsConfig et sont identiques dans les deux CRD.

Les champs suivants sont disponibles dans customCertificateConfig et tlsConfig :

Voici un exemple de fichier YAML permettant de créer un point de terminaison avec un certificat personnalisé.

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"

Vous pouvez ajouter des customCertificateConfig éléments à un déploiement déjà en cours d'exécution. L'opérateur détecte le changement lors de la prochaine réconciliation, valide le certificat, l'attache à l'ALB et télécharge le certificat public sur Amazon S3. Aucune interruption de service ni aucun redéploiement ne sont nécessaires.

Configuration de la gestion DNS de Route 53

La gestion du DNS Route 53 nécessite la configuration d'un certificat personnalisé et utilise le nom de domaine detlsConfig.customCertificateConfig.domainName. Si vous n'avez pas configuré de certificat personnalisé, consultez Configuration d'un certificat personnalisé d'abord.

Pour activer la gestion DNS de Route 53, ajoutez la dnsConfig section suivante à vos spécifications :

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 section peut être ajoutée en même customCertificateConfig temps ou ultérieurement à un déploiement existant. L'opérateur crée les enregistrements DNS lors de la prochaine réconciliation sans redémarrer vos pods.

Lorsque vous déployez avecdnsConfig, l'opérateur :

Utiliser un certificat personnalisé sans gestion DNS de Route 53

La gestion du DNS Route 53 est facultative. Si vous souhaitez gérer vos propres enregistrements DNS, omettez dnsConfig cette section et configurez votre domaine manuellement.

Pour trouver le nom d'hôte ALB pour votre déploiement, le nom d'entrée dépend de l'activation ou non du routage intelligent.

Sans routage intelligent : l'entrée est nommée alb-<deployment-name> dans votre espace de noms.

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

Avec le routage intelligent : l'entrée est nommée alb-<deployment-name>-<namespace> dans l'espace de hyperpod-inference-system noms.

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

Créez un enregistrement DNS dans votre fournisseur DNS pointant votre domaine vers ce nom d'hôte ALB :

Vérification du statut de votre déploiement

Vérifiez le statut du certificat personnalisé

kubectl describe InferenceEndpointConfig my-model -n my-namespace

Recherchez la tlsCertificate section dans le statut :

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

Valeurs d'intégrité du certificat :

L'opérateur vérifie l'expiration du certificat toutes les 24 heures. Lorsqu'il détecte qu'un certificat a été renouvelé dans ACM (la NotAfter date change), il télécharge automatiquement le certificat public sur Amazon S3 et émet un événement. CertificateRenewed

Vérifiez l'état du DNS

Recherchez la dnsStatus section :

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

Valeurs de santé du DNS :

Testez le point de terminaison déployé

Si vous avez configuré la gestion DNS de Route 53, appelez votre point de terminaison à l'aide de votre domaine personnalisé une fois que l'état du DNS s'est affichéActive. Si vous n'avez configuré qu'un certificat personnalisé sans gestion DNS, utilisez le nom d'hôte ALB depuis l'entrée (voir). Utiliser un certificat personnalisé sans gestion 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

Gérez vos certificats personnalisés et vos enregistrements DNS

Modification du domaine ou de la zone hébergée

Vous pouvez mettre à jour le domainName (incustomCertificateConfig) ou hostedZoneId (indnsConfig) sur un déploiement en cours. La modification du nom de domaine déclenche à la fois la revalidation du certificat et le transfert DNS : le nouveau domaine doit être valide dans votre certificat ACM (en tant que SAN ou joker correspondant).

L'opérateur effectue une découpe en toute sécurité :

Au cours de la transition, les anciens et les nouveaux domaines sont transférés vers l'ALB. L'enregistrement de propriété TXT a un TTL de 300 secondes (5 minutes), de sorte que les clients DNS peuvent mettre en cache l'ancien enregistrement jusqu'à 5 minutes après le nettoyage.

Nettoyage

Lorsque vous supprimez InferenceEndpointConfig ou supprimez la dnsConfig section, l'opérateur supprime automatiquement les enregistrements Route 53 A et TXT qu'il a créés. L'opérateur supprime uniquement les enregistrements dont il est propriétaire (vérifié par l'enregistrement TXT de propriété).

Résolution des problèmes

Utilisez ces étapes de débogage si votre certificat personnalisé ou votre configuration DNS ne fonctionne pas comme prévu.