As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Configurar um cluster do Amazon EKS no Studio
Você faz a maior parte dessa configuração na página de detalhes do HyperPod cluster no console de SageMaker IA. Abra o console do SageMaker AI, escolha HyperPod clusters, escolha seu cluster e, em seguida, escolha a guia Configuração. Em Acesso ao cluster para SageMaker domínios, escolha Gerenciar acesso. É aqui que você cria ou visualiza um domínio e anexa as políticas de acesso ao cluster que permitem que os usuários do Studio acessem o cluster.
A captura de tela a seguir mostra a seção Acesso ao cluster para SageMaker domínios na guia Configuração.
As instruções a seguir descrevem como configurar um cluster do Amazon EKS no Studio.
-
Na página Gerenciar acesso, selecione um domínio existente. O acesso do Studio a um HyperPod cluster é executado por meio de um domínio, e a função de execução do domínio é a principal do IAM que o Studio usa para atuar em seu cluster. Para ter informações sobre como criar um domínio, consulte Guia para se configurar com a Amazon SageMaker AI.
-
Anexe as seguintes permissões à sua função de execução a partir do console do IAM.
Para obter informações sobre funções de execução de SageMaker IA e como editá-las, consulteCompreendendo as permissões de espaço e os perfis de execução do domínio.
Para saber como anexar políticas a um grupo ou usuário do IAM, consulte Adicionar e remover permissões de identidade do IAM.
Antes de anexar a política, substitua os dois ARNs de exemplo pelos seus próprios:
-
arn:aws:sagemaker:us-east-1:111122223333:cluster/hyperpod-cluster-nameSubstitua pelo ARN HyperPod do seu cluster. -
arn:aws:eks:us-east-1:111122223333:cluster/eks-cluster-nameSubstitua pelo ARN do seu cluster Amazon EKS. Ele aparece duas vezes, dentroUseEksClusterPermissionse dentroDescribeSpacesAddon, onde carrega um rastro./*
Esses são dois recursos diferentes com dois ARNs diferentes. Encontre o ARN do HyperPod cluster no console do SageMaker AI e o ARN do cluster Amazon EKS no console do Amazon EKS. Se você deixar os valores de exemplo em vigor, o Studio não poderá descrever seu cluster e a guia Tarefas não será carregada.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DescribeHyperpodClusterPermissions", "Effect": "Allow", "Action": [ "sagemaker:DescribeCluster" ], "Resource": "arn:aws:sagemaker:us-east-1:111122223333:cluster/hyperpod-cluster-name" }, { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Allow", "Action": [ "ecr:CompleteLayerUpload", "ecr:GetAuthorizationToken", "ecr:UploadLayerPart", "ecr:InitiateLayerUpload", "ecr:BatchCheckLayerAvailability", "ecr:PutImage" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudwatch:PutMetricData", "cloudwatch:GetMetricData" ], "Resource": "*" }, { "Sid": "UseEksClusterPermissions", "Effect": "Allow", "Action": [ "eks:DescribeCluster", "eks:AccessKubernetesApi", "eks:MutateViaKubernetesApi" ], "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/eks-cluster-name" }, { "Sid": "DescribeSpacesAddon", "Effect": "Allow", "Action": "eks:DescribeAddon", "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/eks-cluster-name/*" }, { "Sid": "ListClustersPermission", "Effect": "Allow", "Action": [ "sagemaker:ListClusters" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ssm:StartSession", "ssm:TerminateSession" ], "Resource": "*" } ] } -
-
Anexe políticas de acesso ao cluster à função de execução. A política do IAM na etapa anterior permite que a função de execução chame as AWS APIs. Ele não concede à função nenhuma permissão dentro do cluster Kubernetes. Cluster-access as políticas fazem isso, e somente uma função com as corretas anexadas alcança o cluster. Anexe-os em Gerenciar acesso, no domínio ou no perfil do usuário.
Selecione a função de execução para o domínio ou perfil de usuário ao qual você está concedendo acesso e, em seguida, selecione as políticas de que seus usuários precisam. Escolha se deseja definir o escopo do acesso a um namespace ou a todo o cluster, definindo o escopo para um namespace quando as equipes compartilham um cluster e, em seguida, salve. O escopo de um namespace também restringe quais tarefas esses usuários podem ver no Studio. Para saber o que cada política permite, como definir o escopo do acesso e, em vez disso, conceder um conjunto personalizado de permissões, consulteRestringir a visualização de tarefas no Studio para clusters do EKS.
Conceder acesso dessa forma cria a entrada de acesso do Amazon EKS para a função de execução para você, portanto, não há uma etapa separada no console do Amazon EKS. Para os conceitos por trás do modelo de acesso, consulte Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso EKS.
-
(Opcional) Para garantir uma experiência mais tranquila, recomendamos que você adicione tags aos seus clusters. Para obter informações sobre como adicionar tags, consulte Como Editar um SageMaker HyperPod cluster atualizar seu cluster usando o console de SageMaker IA.
Associe seu espaço de trabalho do Amazon Managed Grafana ao seu domínio do Studio. Use essa tag para vincular ao seu espaço de trabalho Grafana diretamente do seu cluster no Studio. Adicione a tag a seguir ao seu cluster para identificá-la com seu ID do espaço de trabalho Grafana,.
ws-idChave da tag = “
grafana-workspace”; valor da tag = “ws-id”.
Restringir a visualização de tarefas no Studio para clusters do EKS
Você pode restringir a visibilidade dos usuários a namespaces específicos do Kubernetes, garantindo que os usuários possam acessar os recursos de que precisam e, ao mesmo tempo, manter controles de acesso rígidos.
Há duas maneiras de fazer isso. O escopo de uma política de acesso a clusters para um namespace é feito inteiramente no console e é a opção mais simples. Uma função RBAC personalizada do Kubernetes oferece controle sobre os verbos e recursos exatos que um usuário obtém, ao custo de gerenciar a função sozinho.
Restrinja com uma política de acesso a clusters
HyperPod fornece políticas de acesso ao cluster que você anexa em Gerenciar acesso na guia Configuração. Anexe somente as políticas de que um conjunto de usuários precisa e defina o escopo do acesso a um namespace em vez de ao cluster inteiro. Esse é o mesmo fluxo da terceira etapa acima.
Recomendamos que você anexe todas as políticas à função para ter uma experiência completa HyperPod no Studio. Cada política cobre uma parte diferente da experiência, portanto, deixar uma de fora remove a capacidade que ela concede. Anexe um subconjunto somente quando você pretende reter um recurso desse conjunto de usuários.
| Política | O que isso permite |
|---|---|
AmazonSagemakerHyperpodTrainingPolicy |
Envie e gerencie cargas de trabalho de treinamento. Acesso total aRayCluster, e RayJobRayCronJob, ao Kubeflow HyperPodPyTorchJob PyTorchJobMPIJob, e aos trabalhos e pods TFJob do Kubernetes. Leia o acesso a logs de pods, mapas de configuração, eventos, serviços, contas de serviço, cotas de recursos, intervalos de limite, implantações, conjuntos de estado, conjuntos de réplicas e filas e cargas de trabalho locais do Kueue. Pode criar umRayDashboardConnection. |
AmazonSagemakerHyperpodInferencePolicy |
Implante e gerencie cargas de trabalho de inferência. Acesso total aos RayCluster eRayService, para JumpStartModel InferenceEndpointConfigSageMakerEndpointRegistration, e e aos pods. Leia o acesso a registros de pods, mapas de configuração, eventos, serviços, contas de serviço, cotas de recursos, faixas de limite, implantações, conjuntos de estado, conjuntos de réplicas, autoescaladores horizontais de pods, entradas e filas e cargas de trabalho locais do Kueue. Pode criar umRayDashboardConnection. |
AmazonSagemakerHyperpodSpacePolicy |
Use espaços para desenvolvimento interativo. Acesso total aos Workspace recursos e acesso de leitura a modelos de espaço de trabalho, estratégias de acesso e modelos de integração. Leia o acesso a pods, serviços, contas de serviço, declarações de volume persistentes, eventos, cotas de recursos, vinculações, conjuntos de daemons, implantações e conjuntos de réplicas. Pode criar umWorkspaceConnection, que é o que abre um espaço. |
AmazonSagemakerHyperpodSpaceTemplatePolicy |
Leia os modelos de espaço compartilhado. Anexe o escopo ao jupyter-k8s-shared namespace, onde estão os modelos, e não ao namespace em que seus usuários trabalham. |
AmazonSagemakerHyperpodUserClusterPolicy |
Veja os recursos de todo o cluster, que a interface do usuário do Studio precisa renderizar. Acesso de leitura a namespaces e nós, obtenha acesso a definições de recursos personalizadas, acesso de leitura às filas do cluster Kueue, variações de recursos e classes de prioridade de carga de trabalho e permissão para verificar o acesso do próprio usuário. Anexe-o com escopo ao cluster em vez de a um namespace. |
Acesso total significa obter, listar, assistir, criar, atualizar, corrigir e excluir.
Essas são políticas de acesso a clusters do Amazon EKS, não políticas gerenciadas pelo IAM. Seus ARNs assumem o formatoarn:<partition>:eks::aws:cluster-access-policy/<name>. Anexar uma por meio de Manage access cria a entrada de acesso do Amazon EKS para a função de execução, que é o que aplica a política à função.
Restrinja com uma função RBAC personalizada do Kubernetes
Use um papel personalizado quando quiser conceder um conjunto personalizado de permissões em vez das fornecidas por uma política de acesso a clusters. A configuração a seguir permite que os administradores concedam acesso específico e limitado aos cientistas de dados para visualizar tarefas dentro do cluster. Esta configuração concede as seguintes permissões:
-
Listar e obter pods.
-
Listar e receber eventos.
-
Obter definições de recursos personalizadas (CRDs.)
Configuração YAML
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pods-events-crd-cluster-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] - apiGroups: [""] resources: ["events"] verbs: ["get", "list"] - apiGroups: ["apiextensions.k8s.io"] resources: ["customresourcedefinitions"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pods-events-crd-cluster-role-binding subjects: - kind: Group name: pods-events-crd-cluster-level apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pods-events-crd-cluster-role apiGroup: rbac.authorization.k8s.io
-
Salve a configuração YAML em um arquivo denominado
cluster-role.yaml. -
Aplique a configuração usando o site
kubectldo Kubernetes: kubectl apply -f cluster-role.yaml -
Verifique a configuração:
kubectl get clusterrole pods-events-crd-cluster-role kubectl get clusterrolebinding pods-events-crd-cluster-role-binding -
Atribua usuários ao grupo
pods-events-crd-cluster-levelpor meio do seu provedor de identidades ou do IAM.