Práticas recomendadas de IA/ML no Kubernetes: o essencial

A execução de cargas de trabalho de IA/ML em grande escala no Kubernetes pode parecer navegar em um labirinto de alocações de recursos, obstáculos de segurança e demandas de monitoramento, especialmente se você não tiver um plano sólido. Claro, é empolgante ver tarefas de rede neural como reconhecimento de imagem ou previsão de rotatividade, mas sempre há a preocupação de levar seu cluster ao limite.

O MLOps é uma âncora amigável aqui, preenchendo a lacuna entre cientistas de dados, pessoal de DevOps e equipes de segurança como um conjunto de ideias e ferramentas que ajudam você a acompanhar a criação, o teste e o lançamento do modelo. Ele incentiva uma colaboração estreita, para que um cientista de dados em uma equipe e um guru do Kubernetes em outra possam atualizar um modelo com confiança sem pisar um no outro's dedos dos pés. Quando o MLOps encontra a orquestração de contêineres, você obtém uma maneira mais previsível de controlar pipelines de IA.

Nosso objetivo com este artigo é compartilhar as melhores práticas para executar tarefas complexas de IA no Kubernetes. Nós'Falarei sobre dimensionamento, agendamento, segurança, gerenciamento de recursos e outros elementos importantes para engenheiros de plataforma experientes e pessoas que estão entrando no aprendizado de máquina no Kubernetes. Ao percorrer cada seção, você'vou pegar dicas práticas para proteger seu cluster de Riscos de segurança da IA, mantenha seus custos sob controle e dê aos seus modelos o poder de computação que eles desejam.

Práticas de codificação segura do Kubernetes [folha de dicas]

Esta folha de dicas de 10 páginas fornece orientação avançada e acionável para desenvolvedores de infraestrutura e plataforma protegerem aplicativos em contêineres.

Baixar PDF

Gestão de recursos

Antes de criar contêineres para treinamento ou inferência, é importante garantir que os recursos de cluster correspondam à intensidade de suas cargas de trabalho. Afinal, ignorar as demandas da GPU ou pular o dimensionamento adequado da CPU leva a um desempenho lento, mortes aleatórias de falta de memória e equipes desapontadas. 

Alocação de GPU e hardware especializado

GPUs, TPUs e outros aceleradores são como os carros esportivos em um cluster's garagem. Eles permitem que você treine modelos massivos ou lide com uma taxa de transferência enorme durante a inferência. Disponibilizar esses recursos de hardware dentro dos pods depende de plug-ins de dispositivo fornecidos pelo Kubernetes. Por exemplo, adicionando o plug-in oficial do dispositivo NVIDIA, você pode solicitar fatias de GPU por pod.

Uma dica importante? Definir solicitações de recursos adequadas garante que o agendador identifique o nó certo com a GPU correta. Se você ignorar essas definições de recursos, sua carga de trabalho poderá pousar em um nó sem o acelerador, causando falhas de trabalho. Também é útil rotular os nós de GPU com algo como nvidia.com/gpu=true para direcioná-los facilmente por meio de nodeSelector ou nodeAffinity.

O trecho de código abaixo mostra uma especificação básica de pod que solicita uma GPU da NVIDIA:

apiVersion: v1
tipo: Pod
metadados:
  Nome: GPU-Training-Pod
Especificação:
  Recipientes:
  - nome: gpu-training-container
    Imagem: nvcr.io/nvidia/tensorflow:22.01-tf2-py3
    Recursos:
      Limites:
        nvidia.com/gpu: 1
  nodeSelector:
    nvidia.com/gpu: "verdadeiro"

Dimensionamento de CPU e memória

Nem todo pipeline de dados ou trabalho de treinamento de modelo precisa de uma GPU. Muitas tarefas funcionam perfeitamente bem em CPUs se você dimensioná-las corretamente. Ao definir solicitações e limites, o agendador do Kubernetes sabe quantos pods cabem em um nó. Sem esses parâmetros, você corre o risco de um agendamento incorreto ou pods competindo pelos mesmos núcleos de CPU. Para levar o agendamento para o próximo nível, adicione Dimensionamento automático de cluster para absorver picos repentinos no tráfego ou empregos de treinamento.

Lembre-se de observar cuidadosamente as métricas de uso reais, usando um sistema de monitoramento como o Prometheus. Se os pods atingirem consistentemente 90% da CPU, ajuste ligeiramente as solicitações. Por outro lado, se os pods permanecerem em torno de 20% de uso da CPU, você poderá reduzir suas solicitações. 

Abaixo está um exemplo de implantação que define solicitações e limites de CPU e memória:

apiVersion: apps/v1
tipo: Implantação
metadados:
  Nome: ml-inference-deployment
Especificação:
  réplicas: 2
  modelo:
    Especificação:
      Recipientes:
      - nome: ml-inference-container
        imagem: your-registry/ml-inference:latest
        Recursos:
          Solicitações:
            CPU: "500 metros atrás do mar"
            memória: "512 milhas"
          Limites:
            CPU: "1000m"
            memória: "1024 milhas"

Dimensionar suas cargas de trabalho de IA/ML

Uma vez que você'Depois de definir como solicitar e alocar recursos, é hora de escalar. Em alguns cenários, você dimensionará pods de inferência horizontalmente para lidar com solicitações de entrada com picos. Em outros, você agendará grandes trabalhos de treinamento que podem precisar de tipos de nó especializados.

Escala horizontal e vertical

O dimensionamento horizontal é o que você precisa para lidar com cargas de usuário imprevisíveis, especialmente para pontos de extremidade de inferência. É uma prática recomendada configurar Alunos da HPA para observar o uso da CPU ou GPU e, em seguida, ativar novos pods quando as coisas esquentarem. Ainda assim, o dimensionamento vertical pode ser uma resposta melhor se o contêiner precisar de mais memória ou núcleos de CPU em um único nó. O Vertical Pod Autoscaler (VPA) pode ajudá-lo a ajustar solicitações de cargas de trabalho estáveis ao longo do tempo.

Aqui'é um trecho de um HPA referenciando uma implantação por uso da CPU:

apiVersion: autoscaling/v2
tipo: HorizontalPodAutoscaler
metadados:
  Nome: Inference-HPA
Especificação:
  scaleTargetRef:
    apiVersion: apps/v1
    tipo: Implantação
    Nome: Inference-Deployment
  minReplicas: 2
  maxReplicas: 15
  Métricas:
  - tipo: Recurso
    recurso:
      Nome: CPU
      alvo:
        tipo: Utilização
        utilização média: 75

Trabalhos em lotes e agendamento

O treinamento em larga escala geralmente é melhor como um processo em lote. Para simplificar seu pipeline, use o Kubernetes Jobs para experimentos únicos e o CronJobs para tarefas agendadas, como retreinamento noturno. Ao adotar essa abordagem, cada execução de trabalho bem-sucedida significa que o modelo ou artefato pode ser armazenado automaticamente em algum lugar para uso posterior.

Um trabalho em lotes bem estruturado garante que as tarefas de treinamento de longa duração não sobrecarreguem os nós do cluster. Para conseguir isso, você pode solicitar recursos de GPU ou CPU da mesma maneira que qualquer outro pod, certificando-se de gerenciá-los com eficiência.

Abaixo está um CronJob que inicia uma execução de treinamento noturna:

apiVersion: batch/v1
tipo: CronJob
metadados:
  Nome: Nightly-Model-Training
Especificação:
  horário: "0 2 * * *"
  jobTemplate:
    Especificação:
      modelo:
        Especificação:
          Recipientes:
          - nome: contêiner de treinamento
            imagem: seu-registro/imagem-de-treinamento:mais recente
            Recursos:
              Limites:
                nvidia.com/gpu: 1
            comando: ["pitão", "train.py"]
          restartPolicy: Nunca

Estratégias híbridas e multicluster

Às vezes, é necessário distribuir cargas de trabalho em vários Clusters do Kubernetes, especialmente se você quiser redundância ou executar alguns trabalhos no local e outros na nuvem. Isso pode economizar dinheiro e reduzir o risco. Ferramentas como Antos Ofereça um console de gerenciamento que mostre como os trabalhos são distribuídos. Se houver'é um problema em um ambiente, você pode fazer failover para outro, dando-lhe tranquilidade quando você'fazendo malabarismos com tarefas críticas de inferência voltadas para o usuário.

Armazenamento e gerenciamento de dados

Uma vez que seus trabalhos possam ser dimensionados com eficiência, os dados assumem o centro das atenções. Onde é armazenado? Com que rapidez você pode lê-lo? Como você faz backup? Essas perguntas surgem muito ao lidar com grandes conjuntos de dados de treinamento e são cruciais para evitar que a recuperação de dados se torne um gargalo.

Classes de armazenamento de alto desempenho

StorageClasses com suporte de SSDs são ideais para cargas de trabalho de treinamento com grandes demandas de leitura/gravação. Para aproveitá-los ao máximo, defina um PersistentVolumeClaim (PVC) que faça referência ao StorageClass correto e às provisões de cluster adequadas para armazenamento de backup. Além disso, certifique-se de monitorar IOPS de leitura/gravação (operações de entrada/saída por segundo) para confirmar se os volumes de armazenamento podem lidar com a taxa de transferência necessária.

Abaixo está um PVC que solicita uma classe de armazenamento de alto desempenho:

piVersão: v1
tipo: PersistentVolumeClaim
metadados:
  Nome: Fast-PVC
Especificação:
  modos de acesso:
    - ReadWriteOnce
  storageClassName: ssd de alto desempenho
  Recursos:
    Solicitações:
      armazenamento: 100Gi

Localidade e armazenamento em cache de dados

No treinamento distribuído, a localidade dos dados é importante. Quando os trabalhadores obtêm dados de volumes remotos, a latência da rede pode causar lentidão. A solução? Coloque camadas de cache na frente do armazenamento remoto ou escolha volumes SSD locais de nó. Outra estratégia é executar um contêiner sidecar de cache no mesmo pod, que lida com leituras e gravações de dados, melhorando o desempenho em fluxos de trabalho específicos.

O snippet abaixo mostra um contêiner sidecar que fornece cache para dados de treinamento:

apiVersion: apps/v1
tipo: Implantação
metadados:
  Nome: Treinamento-Implantação
Especificação:
  réplicas: 2
  seletor:
    matchLabels:
      aplicativo: aplicativo de treinamento
  modelo:
    metadados:
      Rótulos:
        aplicativo: aplicativo de treinamento
    Especificação:
      Recipientes:
      - nome: caching-sidecar
        imagem: your-registry/caching-sidecar:latest
        volumeMounts:
          - nome: cache-volume
            mountPath: /cache
      - nome: contêiner de treinamento
        imagem: seu-registro/imagem-de-treinamento:mais recente
        volumeMounts:
          - nome: cache-volume
            mountPath: /dataset
      Volumes:
        - nome: cache-volume
          emptyDir: {}

Backup e controle de versão

O rastreamento de versões de modelos é padrão por um bom motivo: se novos modelos falharem na produção (ei, isso acontece!), você precisará de reversões frequentes. Além de armazenar artefatos de modelo no armazenamento de objetos, também é importante executar backups programados. Mesmo se você'Re usando um serviço de nuvem que fornece backups automáticos, backups extras são o caminho a percorrer para evitar problemas no futuro.

Abaixo está um Fluxo de trabalho do Argo que faz upload de artefatos de modelo para um bucket remoto no S3:

apiVersion: argoproj.io/v1alpha1
tipo: Fluxo de trabalho
metadados:
  generateName: model-backup-
Especificação:
  ponto de entrada: modelo de backup
  Modelos:
  - nome: modelo de backup
    recipiente:
      imagem: seu-registro/ferramenta de backup:mais recente
      comando: ["modelo de backup"]
      args: ["--model-path=/modelos", "--destination=s3://ml-backups"]

Considerações de segurança

Nós'todos nós vimos as manchetes sobre clusters sendo sequestrados ou dados sendo exfiltrados - como o maio de 2024 incidente de acesso não autorizado no Hugging Face onde os invasores visaram sua plataforma de hospedagem de modelo de IA. Essas violações destacam o porquê Segurança do Kubernetes e Segurança de IA tornaram-se uma grande prioridade. Quando você combina cargas de trabalho em contêineres com pipelines de ML avançados, os vetores de ameaças se multiplicam rapidamente. Deixar's percorrem algumas maneiras de manter esses riscos sob controle.

25 agentes de IA. 257 ataques reais. Quem vence?

Desde a descoberta zero-day até a escalação de privilégios na nuvem, testamos 25 combinações agente-modelo em 257 desafios reais de segurança ofensiva. Os resultados podem te 👀 surpreender

Seu e-mail de trabalho aqui

Veja qual agente venceu

Fundamentos da segurança do Kubernetes

Para fortalecer a segurança, siga estas práticas recomendadas:

• Verificar imagens de contêiner para detectar vulnerabilidades antes da implantação.

• Impor o RBAC (controle de acesso baseado em função) para restringir quem pode implantar, modificar ou excluir cargas de trabalho.

• Aplicar padrões de segurança de pod (PSS) para evitar configurações incorretas que possam expor clusters a ameaças.

• Limitar o acesso a Registros de contêiner e monitorar alterações não autorizadas.

• Marcar imagens com referências estáveis para garantir que apenas versões verificadas sejam usadas na produção.

Aqui'é um snippet RBAC que concede privilégios mínimos a um namespace:

tipo: Função
apiVersion: rbac.authorization.k8s.io/v1
metadados:
  Namespace: ml-project
  nome: ml-project-role
réguas:
- apiGroups: ["", "Apps"]
  Recursos: ["Vagens", "Implantações"]
  verbos: ["Obter", "lista", "criar", "atualização", "excluir"]
---
tipo: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadados:
  Nome: ml-project-rolebinding
  Namespace: ml-project
Assuntos:
- tipo: Usuário
  Nome: ML-User
  apiGroup: rbac.authorization.k8s.io
ref função:
  tipo: Função
  nome: ml-project-role
  apiGroup: rbac.authorization.k8s.io

Proteção de integridade do modelo

À medida que os modelos de IA se tornam mais poderosos e amplamente implantados, eles também se tornam alvos de ataques adversários, envenenamento de dados e desvio de distribuição. Os invasores podem manipular dados de treinamento para prejudicar o desempenho do modelo ou explorar pontos fracos na lógica do modelo. 

Para mitigar essas ameaças, monitore os dados recebidos em busca de anomalias, use ferramentas de detecção de desvios para detectar quando o desempenho do seu modelo no mundo real começa a cair e treine (ou treine novamente) apenas em conjuntos de dados verificados. Manter essa vigilância ajuda a garantir que seu modelo permaneça preciso e resiliente diante de ameaças em evolução.

Abaixo está um exemplo de trecho do Python mostrando como você pode usar a biblioteca Alibi Detect para detectar desvios de dados:

de alibi_detect.cd import KSDrift
importar numpy como np

# Dados de referência (por exemplo, dados de treinamento de linha de base)
X_ref = np.random.rand(1000, 10)

# Novos dados de entrada (por exemplo, amostras de tráfego ao vivo)
X = np.random.rand(1000, 10) # Substituir pelos dados de produção reais

# Inicialize o detector de desvio
cd = KSDrift(X_ref, p_val=0,05)

# Execute a verificação de desvio
preds = cd.predict(X)

se preds['data_drift']:
    print("Desvio de dados detectado! Valor de p:", preds['p_val'])
    # Opcionalmente, dispare um pipeline ou alerta de retreinamento
mais:
    print("Nenhum desvio de dados detectado. Valor de p:", preds['p_val'])

Assinatura de imagem

Depois de tomar medidas para preservar a integridade do modelo, a próxima camada de defesa é confirmar a autenticidade de um modelo assinando imagens de contêiner que contêm seus artefatos de modelo. Ferramentas como Assine Facilite a adição de assinaturas digitais, enquanto a criptografia em repouso e uma cadeia de custódia para dados de treinamento ajudam a proteger ainda mais seu ecossistema, especialmente em setores regulamentados. 

Você pode assinar sua imagem de contêiner com um comando simples Cosign:

$ cosign sign --key cosign.key seu-registro/sua-imagem:tag

Além disso, adicione etapas automatizadas de verificação de código em pipelines de CI. Isso ajuda a detectar possíveis vulnerabilidades nas dependências antes que elas cheguem à produção. Abaixo está um snippet de código que integra o Trivy, um verificador de segurança de código aberto, em um pipeline do GitHub Actions:

Nome: Code-scanning-workflow
em: [empurrar, pull_request]
Empregos:
  varredura:
    é executado: ubuntu-mais recente
    Passos:
    - Usos: Ações/checkout@v2
    - nome: Digitalizar com Trivy
      Usos: Aquasecurity/Trivy-action@master
      com:
        ref imagem: "seu-registro/sua-imagem:mais recente"
        formato: "mesa"

Isolamento de rede e confiança zero

A proteção de cargas de trabalho de IA começa com um forte isolamento de rede. Uma abordagem eficaz é definir Políticas de rede que restringem quais pods e Espaços de nomes podem se comunicar uns com os outros. Além disso,'para evitar a execução de cargas de trabalho de IA/ML junto com outros aplicativos no mesmo cluster. Ao segmentar cargas de trabalho com base na finalidade, como separar serviços de inferência de aplicativos Web gerais, você minimiza o risco de movimento lateral em caso de violação.

Essa abordagem se alinha aos princípios de confiança zero, em que cada parte do tráfego de rede é tratada com cautela, mesmo que's internos ao cluster. Combinadas com um forte gerenciamento de acesso de identidade, essas proteções ajudam a evitar vazamentos acidentais de dados e tentativas de infiltração.

Aqui'é uma NetworkPolicy que limita o tráfego apenas ao namespace de inferência:

apiVersion: networking.k8s.io/v1
tipo: NetworkPolicy
metadados:
  nome: allow-namespace-traffic
  namespace: inferência
Especificação:
  podSelector: {}
  Entrada:
  -De:
    - namespaceSelector:
        matchLabels:
          Objetivo: Inferência

Visibilidade de ponta a ponta: do código ao tempo de execução

As cargas de trabalho de IA/ML apresentam desafios complexos de segurança e conformidade que abrangem todo o ciclo de vida, desde o desenvolvimento do código até a execução do tempo de execução. Sem visibilidade total, configurações incorretas, vulnerabilidades e desvios podem se infiltrar em seus clusters do Kubernetes, aumentando o risco de violações.

Para lidar com isso, as equipes precisam de uma estratégia de segurança que abranja todos os estágios do pipeline de IA: verificação de configurações de infraestrutura como código (IaC), proteção de imagens de contêiner, Aplicando proteções de tempo de execuçãoe Monitoramento contínuo para anomalias. Ao integrar controles de segurança em todo o pipeline, você garante que as cargas de trabalho de IA permaneçam resilientes e em conformidade.

A Wiz oferece uma plataforma que permite rastrear vulnerabilidades, problemas de conformidade e postura de segurança em todo o cluster em tempo real. Aproveite o painel do Wiz para detectar problemas de imagem de contêiner, configurações incorretas e até mesmo Segredos À espreita no código:

Observabilidade: monitoramento, registro e rastreamento

Ao ajustar seu cluster para cargas de trabalho de machine learning, você está buscando uma visão cristalina do que'está acontecendo. Isso significa coletar métricas de pods, armazenar logs em um local centralizado e rastrear solicitações entre microsserviços. A observabilidade completa torna a solução de problemas um acéfalo quando algo falha.

Métricas e alertas

O Prometheus geralmente fica no centro de sua pilha de monitoramento, ajudando você a rastrear as principais métricas de desempenho. Para garantir operações suaves de IA/ML, use uma combinação de ferramentas:

• Prometeu coleta métricas de uso de CPU, memória e GPU de serviços de inferência de modelo.

• Grafana Fornece painéis em tempo real para visualizar o desempenho do cluster e detectar anomalias.

• Regras de alerta acionar automaticamente notificações (por exemplo, alertas do Slack) quando o uso de recursos exceder os limites definidos.

Abaixo está uma PrometheusRule que alerta sobre o alto uso da GPU:

Abaixo está uma PrometheusRule que alerta sobre o alto uso da GPU:

apiVersion: monitoring.coreos.com/v1
tipo: PrometheusRule
metadados:
  Nome: gpu-usage-rules
  namespace: monitoramento
Especificação:
  Grupos:
  - Nome: gpu-alerts
    réguas:
    - alerta: HighGPUUsage
      expr: nvidia_gpu_utilization > 90
      para: 5m
      Rótulos:
        Gravidade: Aviso
      Anotações:
        resumo: "Alto uso de GPU detectado"

Rastreamento distribuído e insights de desempenho

O OpenTelemetry é uma ótima opção para rastreamento distribuído, especialmente se o pipeline de IA incluir vários microsserviços. Cada serviço emite intervalos de rastreamento, ajudando você a identificar onde pode existir um gargalo. Essa abordagem não tem preço ao depurar solicitações lentas ou anomalias aleatórias de desempenho em fluxos de processamento de dados.

Veja como o OpenTelemetry Collector e o Jaeger trabalham juntos para fornecer rastreamento de ponta a ponta e insights de desempenho para cargas de trabalho de IA/ML:

Correlacionando segurança e desempenho com o Wiz

Às vezes, uma queda de desempenho está vinculada a um evento relacionado à segurança. O Wiz ajuda você a ver essa correlação combinando descobertas de segurança com dados de desempenho. Talvez um processo suspeito esteja consumindo recursos de GPU ou uma vulnerabilidade conhecida esteja levando à instabilidade do cluster. Quando você vê esses padrões, o Wiz solicita uma correção imediata.

🚨Relatório de Pesquisa em Segurança Kubernetes 2025

Novos insights de 200.000+ contas em nuvem revelam os riscos mais recentes, tendências de ataque e lacunas de segurança nos ambientes Kubernetes.

Baixar PDF

CI/CD para fluxos de trabalho de IA/ML

Todos nós sabemos que o envio de um modelo treinado envolve mais do que apenas copiar um arquivo. Você deseja automatizar totalmente a criação, o teste e a implantação de artefatos de ML. É aqui que os pipelines de CI/CD são úteis. Você pode encadear tarefas que executam testes, verificam imagens, enviam-nas para um registro e, em seguida, distribuem novas versões para produção.

Automatizando o gerenciamento do ciclo de vida do modelo

Ferramentas como Tekton ou Fluxos de trabalho do Argo permitem que você defina pipelines para todo o ciclo de vida do modelo, desde a preparação de dados até o treinamento e a implantação. Cada estágio é acionado automaticamente sempre que você confirma uma alteração, o que mantém o processo consistente. Você também pode adicionar verificações de validação para garantir que um modelo atenda aos limites de precisão predefinidos antes de marcá-lo para produção. Isso ajuda a evitar que modelos de baixo desempenho sejam implantados e afetem a experiência do usuário.

Abaixo está um Tekton PipelineRun que dá início à construção e implantação do modelo:

apiVersion: tekton.dev/v1beta1
tipo: PipelineRun
metadados:
  nome: ml-pipeline-run
Especificação:
  pipelineRef:
    Nome: ml-build-deploy-pipeline
  Espaços de trabalho:
  - nome: dados compartilhados
    volumeClaimTemplate:
      Especificação:
        accessModes: ["ReadWriteOnce"]
        Recursos:
          Solicitações:
            armazenamento: 5Gi
  parâmetros:
  - nome: nome do modelo
    valor: "modelo meu-ml"

Artefatos imutáveis e GitOps

É útil marcar imagens com hashes de commit para que você saiba exatamente qual versão do código ou modelo você're correndo. O GitOps estende essa prática permitindo que você armazene manifestos do Kubernetes em um repositório Git. Todas as alterações nesses manifestos são aplicadas automaticamente ao cluster de maneira controlada. Esse método ajuda você a rastrear com precisão quando e por que as mudanças acontecem.

Aqui's an Aplicativo Argo CD referenciando o repositório Git para gerenciar configurações de implantação:

apiVersion: argoproj.io/v1alpha1
tipo: Aplicação
metadados:
  Nome: ml-inference-app
Especificação:
  destino:
    Namespace: ML-Inference
    Servidor: https://kubernetes.default.svc
  fonte:
    repoURL: 'https://github.com/your-org/ml-deploy-configs.git'
    targetRevision: main
    Caminho: manifestos/inferência
  projeto: padrão
  syncPolicy:
    automatizado:
      ameixa: verdadeiro
      selfHeal: verdadeiro

Otimização de desempenho

Os modelos precisam responder rapidamente e não desperdiçar horas caras de GPU ou CPU. Felizmente, pequenos ajustes nos parâmetros HPA ou nas regras de balanceamento de carga podem reduzir milissegundos preciosos e reduzir os custos por uma margem sólida.

Balanceamento de carga

O balanceamento de carga com recursos de entrada ajuda a rotear o tráfego para o serviço de inferência correto. Para separar diferentes versões de um modelo, você tem a opção de usar o roteamento baseado em caminho.

Abaixo está uma entrada com roteamento baseado em caminho para vários serviços de inferência:

apiVersion: networking.k8s.io/v1
tipo: Ingresso
metadados:
  Nome: Inference-Ingress
Especificação:
  réguas:
  - Anfitrião: ml.example.com
    http:
      Caminhos:
      - caminho: /v1/
        pathType: Prefixo
        back-end:
          serviço:
            Nome: Inference-Model-v1
            porta:
              Número: 8081
      - caminho: /v2/
        pathType: Prefixo
        back-end:
          serviço:
            Nome: Inference-Model-v2
            porta:
              Número: 8081

Perfil de custo e otimização

Todo mundo gosta de observar como seus nós de GPU, nós de CPU e uso de memória se alinham com os gastos. Mas ajustar manualmente os recursos pode ser demorado e ineficiente. É aí que ferramentas como Karpenter e Piloto automático pode dimensionar automaticamente os nós do cluster para atender às demandas de recursos, evitando o provisionamento manual de nós. Para cargas de trabalho de treinamento que não precisam de computação persistente, aproveitando Instâncias spot pode reduzir drasticamente os custos, apenas certifique-se de que seu pipeline possa lidar com possíveis interrupções.

Veja abaixo um exemplo de configuração do Karpenter para corresponder tipos de instância a cargas de trabalho:

apiVersion: karpenter.sh/v1alpha5
tipo: Provisionador
metadados:
  Nome: Padrão
Especificação:
  Requisitos:
    -chave: "node.kubernetes.io/instance-type"
      operador: Em
      valores: ["m5.large", "m5.xlarge"]
  provedor:
    subnetSelector:
      karpenter.sh/discovery: "my-cluster"
    securityGroupSelector:
      karpenter.sh/discovery: "my-cluster"

Outra maneira de economizar muito? Use uma ferramenta como o Wiz para ver se há fatores de custo relacionados a recursos mal configurados ou padrões de uso incomuns. O Wiz também ajuda a proteger os nós durante a criação para garantir que eles não sejam apenas dimensionados automaticamente, mas também seguros.

Conclusão

Nós'falei sobre várias estratégias para fluxos de trabalho de aprendizado de máquina no Kubernetes. Do gerenciamento de recursos às melhores práticas de segurança de IA e à conexão de pipelines Tekton, nós'vi como cada peça pode contribuir para uma plataforma estável. A ideia principal é ficar de olho nos riscos de segurança da IA, observar os custos excessivos e construir um pipeline em que as pessoas confiem. 

Ao implementar essas práticas recomendadas, você minimiza as interrupções do cluster e ajuda os cientistas de dados a enviar atualizações com confiança. Nós'Estou animado para ver como essas sugestões se encaixam em seu trabalho. Nós'adoraria ouvir sobre o que você cria, as lições que descobre e como continua aprimorando seu aprendizado de máquina nos fluxos de trabalho do Kubernetes.

Essa jornada pode parecer complicada, mas com as ferramentas certas, como o Wiz's recursos de verificação, painéis e conformidade em tempo real, você pode criar um ambiente mais seguro para treinamento e inferência. Se você'Está procurando refinar e dimensionar seus projetos de IA/ML enquanto se mantém seguro, dê ao Wiz uma chance para uma visão abrangente das vulnerabilidades do contêiner, configurações de cluster e benchmarks de conformidade. Com o Wiz, você pode manter seus clusters íntegros, econômicos e protegidos contra invasões.

Proteja sua nuvem do código à produção

Saiba por que as empresas de crescimento mais rápido escolhem a Wiz para proteger containers, Kubernetes e ambientes de nuvem desde o tempo de compilação até o tempo real.

E-mail de trabalho*

Nome*

Sobrenome*

País

Número de telefone*

Empresa*

Mantenha-me atualizado sobre lançamentos de produtos Wiz, notícias do setor e eventos (você pode cancelar a assinatura a qualquer momento)

Inscreva-me nos e-mails de resumo do blog Wiz

Enviar

Para obter informações sobre como a Wiz lida com seus dados pessoais, consulte nosso Política de Privacidade.

Seu e-mail de trabalho aqui

Ver demonstração