待翻译：Run interactive IDEs on Amazon EKS with SageMaker AI to power up your AI workflows

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

To power up AI workflows on Amazon Elastic Kubernetes Service (Amazon EKS), data scientists need interactive IDEs like JupyterLab and Code Editor. Yet running those IDEs usually means leaving the cluster that hosts their pipelines, moving to a standalone JupyterHub deployment or a local laptop. That switch leaves them without the GPU nodes, shared storage, and AWS Identity and Access Management (IAM) roles their pipelines depend on. The Amazon SageMaker AI Spaces add-on for Amazon EKS closes that gap. It runs managed JupyterLab and Code Editor environments on the cluster that you already operate. Standing up a standalone JupyterHub environment with GPU access, storage, and authentication typically takes a platform team 3–5 days. With the add-on, a data scientist launches a fully configured Space in about 5 minutes. In this post, you install the SageMaker AI Spaces add-on on an Amazon EKS cluster. You set up the supporting add-ons and IAM roles, deploy the AWS Load Balancer Controller, request a TLS certificate, and create an AWS Key Management System (AWS KMS) encryption key. You then create your first Space and reach it through a presigned URL in the browser and from VS Code over SSH-over-SSM. Finally, you review how to move your team to OpenID Connect (OIDC) sign-in with Amazon Cognito. Solution overview The solution runs on a single EKS cluster in three layers: Network and access. Amazon Route 53 resolves a wildcard domain to an internet-facing Application Load Balancer (ALB) with TLS from AWS Certificate Manager (ACM). For VS Code, AWS Systems Manager tunnels directly to the Space pod. Cluster routing. The AWS Load Balancer Controller provisions the ALB. Traefik routes by hostname. Auth middleware validates tokens using AWS Key Management Service (AWS KMS) for JSON Web Token (JWT) encryption. Compute and storage. Space pods run on private-subnet workers. The Amazon Elastic Block Store (Amazon EBS) CSI driver provides persistent volumes, and Amazon Elastic File System (Amazon EFS) or Amazon FSx handle shared or high-throughput storage. EKS Pod Identity grants pods scoped IAM roles. Consolidating interactive and training workloads on one cluster keeps GPU nodes busy between jobs. This can lift GPU utilization by up to 30 percent compared with a dedicated notebook fleet. It also avoids the cost of an always-on GPU environment, which can run into thousands of dollars a month. Figure 1: Solution architecture Prerequisites To follow along, you need an AWS account with the AWS Command Line Interface (AWS CLI) 2.x or later configured for your target AWS Region, plus kubectl 1.30 or later and Helm v3. You also need a Route 53 public hosted zone for a domain you own, referenced as throughout this post, and IAM permissions to create roles, policies, EKS add-ons, access entries, Pod Identity associations, ACM certificates, and KMS keys. The Spaces add-on must be version 0.1.4 or later, because earlier versions supported Amazon SageMaker HyperPod only. Figure 2: Route 53 hosted zone with validation records Set these variables once. The rest of the post reuses them. export CLUSTER_NAME= export REGION= export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) Every IAM role in this post is assumed by a Kubernetes service account through EKS Pod Identity, so they all share one trust policy. Save it once and reuse it: cat > pod-identity-trust.json 38m v1.34.6-eks-bbe087e ip-10-0-2-96.ec2.internal Ready 38m v1.34.6-eks-bbe087e Confirm the system pods are healthy across the add-on namespaces with kubectl get pods -A. Every pod in kube-system, cert-manager, and external-dns should be Running before you continue. External DNS needs Route 53 permissions to manage records. Create the role, attach a least-privilege policy, and bind it through Pod Identity: aws iam create-role --role-name ExternalDNSRole \ --assume-role-policy-document file://pod-identity-trust.json aws iam put-role-policy --role-name ExternalDNSRole \ --policy-name ExternalDNSRoute53Policy \ --policy-document '{ "Version":"2012-10-17", "Statement":[ {"Effect":"Allow","Action":["route53:ChangeResourceRecordSets"], "Resource":"arn:aws:route53:::hostedzone/*"}, {"Effect":"Allow","Action":["route53:ListHostedZones","route53:ListResourceRecordSets","route53:ListTagsForResource"], "Resource":"*"} ]}' aws eks create-pod-identity-association \ --cluster-name $CLUSTER_NAME --region $REGION \ --namespace external-dns --service-account external-dns \ --role-arn arn:aws:iam::${ACCOUNT_ID}:role/ExternalDNSRole kubectl rollout restart deployment -n external-dns external-dns Security note: Scope each Pod Identity role to minimum actions and resources. Prefer explicit resource ARNs over wildcards, and confirm only the intended service account can assume the role. Install the AWS Load Balancer Controller The AWS Load Balancer Controller provisions the ALB that fronts your Spaces UI. Install it with Helm. Define the controller’s IAM policy, role, and Pod Identity association: curl -sS -o /tmp/lbc-iam-policy.json \ https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json aws iam create-policy --policy-name AWSLoadBalancerControllerIAMPolicy \ --policy-document file:///tmp/lbc-iam-policy.json aws iam create-role --role-name AWSLoadBalancerControllerRole \ --assume-role-policy-document file://pod-identity-trust.json aws iam attach-role-policy --role-name AWSLoadBalancerControllerRole \ --policy-arn arn:aws:iam::${ACCOUNT_ID}:policy/AWSLoadBalancerControllerIAMPolicy aws eks create-pod-identity-association \ --cluster-name $CLUSTER_NAME --region $REGION \ --namespace kube-system --service-account aws-load-balancer-controller \ --role-arn arn:aws:iam::${ACCOUNT_ID}:role/AWSLoadBalancerControllerRole Install the Helm chart. Pass vpcId and region explicitly. On chart v3.2+, the controller fails if it auto-detects the VPC through EC2 metadata, which EKS blocks for pods. helm repo add eks https://aws.github.io/eks-charts helm repo update eks helm install aws-load-balancer-controller eks/aws-load-balancer-controller \ -n kube-system \ --set clusterName=$CLUSTER_NAME \ --set serviceAccount.create=true \ --set serviceAccount.name=aws-load-balancer-controller \ --set region=$REGION \ --set vpcId=$VPC_ID kubectl rollout status deployment -n kube-system aws-load-balancer-controller --timeout=180s Both controller replicas come up: NAME READY UP-TO-DATE AVAILABLE AGE aws-load-balancer-controller 2/2 2 2 174m Create the certificate, key, and SSM configuration The Spaces add-on needs a TLS certificate, a KMS key for JWT encryption, and SSM service settings for remote access. Request an ACM certificate covering your domain and a wildcard, using DNS validation, then read back the CNAME records ACM expects: CERT_ARN=$(aws acm request-certificate \ --domain-name "" \ --subject-alternative-names "*." \ --validation-method DNS \ --region $REGION \ --query CertificateArn --output text) # Read the CNAME records ACM expects, then add them to your Route 53 # hosted zone. The console's 'Create records in Route 53' button # does this for you. aws acm describe-certificate --certificate-arn "$CERT_ARN" \ --region $REGION \ --query 'Certificate.DomainValidationOptions[].ResourceRecord' Wait for the certificate status to reach Issued, then copy the ARN. Figure 3: Certificate issued for the domain Security note: DNS validation verifies domain ownership and triggers ACM automatic renewal. Keep the validation CNAMEs in Route 53. Removing them breaks renewal. Create a KMS encryption key. The auth middleware calls kms:GenerateDataKey per JWT, so the key must be symmetric ENCRYPT_DECRYPT, which is the CLI default: KMS_KEY_ARN=$(aws kms create-key --region $REGION \ --description "SageMaker Spaces JWT encryption" \ --query 'KeyMetadata.Arn' --output text) aws kms create-alias --region $REGION \ --alias-name alias/sagemaker-spaces-jwt \ --target-key-id "$KMS_KEY_ARN" Turn on the SSM advanced-instances tier. Session Manager tunnels to hybrid managed instances, which is what VS Code remote uses, require this tier (about $0.00695/hr per Space pod): aws ssm update-service-setting --region $REGION \ --setting-id arn:aws:ssm:$REGION:${ACCOUNT_ID}:servicesetting/ssm/managed-instance/activation-tier \ --setting-value advanced Install the Spaces add-on You create IAM roles for the Spaces controller and auth middleware, then install the add-on. Start with the SSM managed-instance role that each Space pod uses in the SSM fleet: aws iam create-role --role-name SageMakerSpacesSSMManagedNodeRole \ --assume-role-policy-document '{ "Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}] }' aws iam attach-role-policy --role-name SageMakerSpacesSSMManagedNodeRole \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore Next, create the Spaces controller role. It needs SSM, PassRole, and KMS permissions. Save the following policy as spaces-controller-policy.json, replacing , , and with your own values: { "Version": "2012-10-17", "Statement": [ { "Sid": "SSMAccountLevel", "Effect": "Allow", "Action": [ "ssm:CreateActivation", "ssm:DeleteActivation", "ssm:DescribeActivations", "ssm:DescribeInstanceInformation", "ssm:DeregisterManagedInstance", "ssm:ListTagsForResource", "ssm:AddTagsToResource", "ssm:ListDocuments", "ssm:DescribeSessions" ], "Resource": "*" }, { "Sid": "SSMDocumentMgmt", "Effect": "Allow", "Action": [ "ssm:CreateDocument", "ssm:DescribeDocument", "ssm:GetDocument", "ssm:UpdateDocument", "ssm:UpdateDocumentDefaultVersion", "ssm:DeleteDocument" ], "Resource": "arn:aws:ssm:::document/SageMaker-Space*" }, { "Sid": "SSMSessionMgmt", "Effect": "Allow", "Action": [ "ssm:StartSession", "ssm:TerminateSession", "ssm:ResumeSession", "ssm:GetConnectionStatus" ], "Resource": [ "arn:aws:ssm:::document/SageMaker-Space*", "arn:aws:ssm:::managed-instance/*", "arn:aws:ssm:::document/AWS-StartSSHSession" ] }, { "Sid": "PassSSMManagedNodeRole", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam:::role/SageMakerSpacesSSMManagedNodeRole", "Condition": { "StringEquals": { "iam:PassedToService": "ssm.amazonaws.com" } } }, { "Sid": "KMSForJWT", "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt", "kms:Encrypt", "kms:DescribeKey" ], "Resource": "" } ] } Create the role and attach the policy: aws iam create-role --role-name SageMakerSpacesControllerRole \ --assume-role-policy-document file://pod-identity-trust.json aws iam put-role-policy --role-name SageMakerSpacesControllerRole \ --policy-name SageMakerSpacesControllerPolicy \ --policy-document file://spaces-controller-policy.json Bind controller and auth middleware service accounts to this role through Pod Identity: for SA in jupyter-k8s-controller-manager jupyter-k8s-authmiddleware; do aws eks create-pod-identity-association \ --cluster-name $CLUSTER_NAME --region $REGION \ --namespace jupyter-k8s-system --service-account $SA \ --role-arn arn:aws:iam::${ACCOUNT_ID}:role/SageMakerSpacesControllerRole done Security note: For tighter separation of duties, split this into two roles: one with SSM actions for the controller, and one with KMS encrypt and decrypt for the auth middleware. Define addon-config.yaml with your domain, certificate ARN, key ARN, and managed-node role name: jupyter-k8s: # 'enable' (not 'enabled') is correct here, per the official AWS docs: # https://docs.aws.amazon.com/sagemaker/latest/dg/operator-install.html # The jupyter-k8s and jupyter-k8s-aws-hyperpod subcharts use different # schemas, so clusterWebUI below correctly uses 'enabled'. Not a typo. workspacePodWatching: enable: true jupyter-k8s-aws-hyperpod: clusterWebUI: enabled: true domain: "" awsCertificateArn: "" traefik: shouldInstall: true auth: kmsKeyId: "" remoteAccess: enabled: true ssmManagedNod [truncated for AI cost control]