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 configurer éventuellement 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'associe à l'Application Load Balancer (ALB), surveille son état 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 Route 53. La gestion DNS de 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 des 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 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 renforcer la sécurité.

Configuration d'un certificat personnalisé

Pour utiliser un certificat personnalisé, ajoutez la customCertificateConfig section tlsConfig à votre JumpStartModel spécification InferenceEndpointConfig ou. 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 la modification lors de la prochaine réconciliation, valide le certificat, le joint à l'ALB et télécharge le certificat public sur Amazon S3. Aucune interruption ni aucun redéploiement ne sont nécessaires.

Configuration de la gestion DNS de Route 53

La gestion DNS de 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 à votre spécification :

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 effectuez un déploiement avecdnsConfig, l'opérateur :

Utiliser un certificat personnalisé sans gestion DNS Route 53

La gestion DNS de 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 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 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 l'état 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 de santé 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 terminal 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 DNS s'afficheActive. Si vous avez configuré uniquement 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 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

Modifier le domaine ou la zone hébergée

Vous pouvez mettre à jour le domainName (incustomCertificateConfig) ou hostedZoneId (indnsConfig) sur un déploiement en cours d'exécution. La modification du nom de domaine déclenche à la fois la revalidation du certificat et le basculement du DNS : le nouveau domaine doit être valide dans votre certificat ACM (sous forme de SAN ou de correspondance générique).

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

Pendant la transition, les anciens et les nouveaux domaines sont transférés à l'ALB. L'enregistrement de propriété TXT a un TTL de 300 secondes (5 minutes). Les clients DNS peuvent donc mettre en cache l'ancien enregistrement pendant 5 minutes au maximum après le nettoyage.

Nettoyage

Lorsque vous supprimez la section InferenceEndpointConfig ou que vous 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

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