Implantar cargas de trabalho

Esta página descreve as etapas para implantar cargas de trabalho no hardware conectado do Google Distributed Cloud e as limitações que você precisa seguir ao configurar as cargas de trabalho.

Antes de concluir estas etapas, atenda aos requisitos de instalação conectada do Distributed Cloud e peça o hardware do Distributed Cloud.

Quando o hardware do Google Distributed Cloud conectado chega ao destino escolhido, ele já está pré-configurado com hardware, Google Cloude algumas configurações de rede especificadas no pedido do Distributed Cloud conectado.

Os instaladores do Google concluem a instalação física, e o administrador do sistema conecta o Distributed Cloud Connected à rede local.

Depois que o hardware é conectado à sua rede local, ele se comunica com Google Cloud para fazer o download de atualizações de software e se conectar ao seu projetoGoogle Cloud . Assim, você poderá provisionar pools de nós e implantar cargas de trabalho no Distributed Cloud Connected.

Visão geral da implantação

Para implantar uma carga de trabalho no hardware conectado do Distributed Cloud, siga estas etapas:

  1. Opcional: Ative a API Distributed Cloud Edge Network.

  2. Opcional: Inicialize a configuração de rede da sua zona conectada do Distributed Cloud.

  3. Opcional: Configure a rede do Distributed Cloud.

  4. Crie um cluster conectado do Distributed Cloud.

  5. Opcional: Ative o suporte para chaves de criptografia gerenciadas pelo cliente (CMEK) para armazenamento local se quiser integrar ao Cloud Key Management Service para ativar o suporte a CMEK para os dados da sua carga de trabalho. Para informações sobre como o Distributed Cloud Connected criptografa dados de carga de trabalho, consulte Segurança de armazenamento local.

  6. Crie um pool de nós. Nesta etapa, você atribui nós a um pool de nós e, opcionalmente, configura o pool de nós para usar o Cloud KMS para encapsular e desencapsular a frase secreta do Linux Unified Key Setup (LUKS) para criptografar dados de carga de trabalho.

  7. Receba as credenciais de um cluster para testá-lo.

  8. Conceda aos usuários acesso ao cluster atribuindo a eles o papel de Leitor de contêineres de borda (roles/edgecontainer.viewer) ou o papel de Administrador de contêineres de borda (roles/edgecontainer.admin) no projeto.

  9. Atribua aos usuários acesso granular baseado em papéis aos recursos do cluster usando RoleBinding e ClusterRoleBinding.

  10. Opcional: Ative o suporte do ambiente de execução de VMs no Google Distributed Cloud para executar cargas de trabalho em máquinas virtuais no Distributed Cloud Connected.

  11. Opcional: Ative o suporte a GPU para executar cargas de trabalho baseadas em GPU no Distributed Cloud Connected.

Implante o balanceador de carga do NGINX como um serviço

O exemplo a seguir ilustra como implantar o servidor NGINX e expô-lo como um serviço em um cluster conectado do Distributed Cloud:

  1. Crie um arquivo YAML chamado nginx-deployment.yaml com o seguinte conteúdo:

    apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

  2. Aplique o arquivo YAML ao cluster usando o seguinte comando:

    kubectl apply -f nginx-deployment.yaml

  3. Crie um arquivo YAML chamado nginx-service.yaml com o seguinte conteúdo:

    apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

  4. Aplique o arquivo YAML ao cluster usando o seguinte comando:

    kubectl apply -f nginx-deployment.yaml

  5. Use o comando a seguir para receber o endereço IP externo atribuído ao serviço pelo balanceador de carga do MetalLB:

    kubectl get services

    O comando retorna uma saída semelhante a esta:

    NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

Configurar os recursos NodeSystemConfigUpdate

Configure um recurso de operador de função de rede NodeSystemConfigUpdate para cada nó no cluster da seguinte maneira.

  1. Liste os nós em execução no pool de nós do cluster de destino usando o seguinte comando:

    kubectl get nodes | grep -v master

    O comando retorna uma saída semelhante a esta:

    NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200

    Registre os nomes dos nós retornados e derive os nomes abreviados deles. Por exemplo, para o nó pool-example-node-1-01-b2d82cc7, o nome abreviado é node101.

  2. Para cada nó registrado na etapa anterior, crie um arquivo de recursos NodeSystemConfigUpdate dedicado com o seguinte conteúdo:

    apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

    Substitua:

    • NODE_NAME: o nome completo do nó de destino. Por exemplo, pool-example-node-1-01-b2d82cc7.
    • NODE_SHORT_NAME: o nome abreviado do nó de destino derivado do nome completo. Por exemplo, node101.

    Nomeie cada arquivo como node-system-config-update-NODE_SHORT_NAME.yaml.

  3. Aplique cada um dos arquivos de recursos NodeSystemConfigUpdate ao cluster usando o seguinte comando:

    kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml

    Substitua NODE_SHORT_NAME pelo nome abreviado do nó de destino correspondente.

    Quando você aplica os recursos ao cluster, cada nó afetado é reinicializado, o que pode levar até 30 minutos.

    1. Monitore o status dos nós afetados até que todos sejam reinicializados:
    kubectl get nodes | grep -v master

    O status de cada nó muda de not-ready para ready à medida que as reinicializações são concluídas.

Configurar um pod para cache de imagens

É possível configurar um pod em execução em um cluster conectado do Distributed Cloud para armazenar em cache a imagem dele. O pod começa a usar a imagem armazenada em cache depois que ela é extraída do repositório pela primeira vez. Se o nó que hospeda o pod ficar sem armazenamento, novas imagens não serão armazenadas em cache, e o cache de imagens atual será limpo para garantir que suas cargas de trabalho continuem sendo executadas sem interrupções.

A configuração do pod precisa atender aos seguintes pré-requisitos:

  • Defina o rótulo gdce.baremetal.cluster.gke.io/cache-image: true no pod.
  • Se você estiver usando um repositório de imagens particular, o recurso ImagePullSecret precisará ser do tipo kubernetes.io/dockerconfigjson.
  • Defina a política de extração do pod como IfNotPresent para garantir que a cópia em cache da imagem de destino seja sempre usada. Se uma cópia em cache não estiver disponível localmente, a imagem será extraída do repositório.

O exemplo a seguir ilustra uma configuração de pod com o cache ativado:

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

O exemplo a seguir ilustra uma configuração de implantação com o cache ativado:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Limitações para cargas de trabalho da Distributed Cloud

Ao configurar as cargas de trabalho conectadas da Distributed Cloud, você precisa obedecer às limitações descritas nesta seção. Essas limitações são aplicadas pelo Distributed Cloud Connected em todas as cargas de trabalho que você implanta no hardware conectado do Distributed Cloud.

Limitações de carga de trabalho do Linux

O Distributed Cloud Connected é compatível apenas com os seguintes recursos do Linux para cargas de trabalho:

  • AUDIT_READ
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • IPC_LOCK
  • IPC_OWNER
  • KILL
  • MKNOD
  • NET_ADMIN
  • NET_BIND_SERVICE
  • NET_RAW
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT
  • SYS_NICE
  • SYS_PACCT
  • SYS_PTRACE
  • SYS_RESOURCE
  • SYS_TIME

Restrições de namespace

O Distributed Cloud Connected não aceita os seguintes namespaces:

  • hostPID
  • hostIPC
  • hostNetwork

Restrições de tipo de recurso

O Distributed Cloud Connected não é compatível com o tipo de recurso CertificateSigningRequest, que permite que um cliente peça a emissão de um certificado X.509 com base em uma solicitação de assinatura.

Restrições de contexto de segurança

O Distributed Cloud Connected não é compatível com o contexto de segurança do modo privilegiado.

Restrições de vinculação de pod

O Distributed Cloud Connected não permite vincular pods a portas de host no namespace HostNetwork. Além disso, o namespace HostNetwork não está disponível.

hostPath restrições de volume

O Distributed Cloud Connected permite apenas os seguintes volumes hostPath com acesso de leitura/gravação:

  • /dev/hugepages
  • /dev/infiniband
  • /dev/vfio
  • /dev/char
  • /sys/devices

PersistentVolumeClaim restrições de tipo de recurso

O Distributed Cloud Connected permite apenas os seguintes tipos de recursos PersistentVolumeClaim:

  • csi
  • nfs
  • local

Restrições de tipo de volume

O Distributed Cloud Connected permite apenas os seguintes tipos de volume:

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim
  • projected
  • secret

Restrições de tolerância de pod

O Distributed Cloud Connected não permite pods criados pelo usuário em nós do plano de controle. Especificamente, o Distributed Cloud Connected não permite o agendamento de pods com as seguintes chaves de tolerância:

  • ""
  • node-role.kubernetes.io/master
  • node-role.kubernetes.io/control-plane

Restrições de representação

O Distributed Cloud Connected não é compatível com a representação de usuários ou grupos.

Restrições de namespace de gerenciamento

O Distributed Cloud Connected não permite o acesso aos seguintes namespaces:

  • ai-system
  • ai-speech-system
  • ai-ocr-system
  • ai-translation-system
  • anthos-identity-service
  • cert-manager
  • dataproc-system
  • dataproc-PROJECT_ID
  • dns-system
  • g-istio-system
  • gke-connect
  • gke-managed-metrics-server
  • gke-operators
  • g-ospf-servicecontrol-system
  • g-ospf-system
  • g-pspf-system
  • gke-system
  • gpc-backup-system
  • iam-system
  • kube-node-lease
  • kube-public
  • kube-system, exceto para excluir ippools.whereabouts.cni.cncf.io
  • metallb-system, exceto para editar recursos configMap e definir intervalos de endereços IP de balanceamento de carga.
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

PROJECT_ID indica o ID do projeto Google Cloud de destino.

Evite usar namespaces com o prefixo g- no nome. Esses namespaces são normalmente reservados e usados pelo Distributed Cloud Connected.

Restrições de webhook

O Distributed Cloud Connected restringe os webhooks da seguinte maneira:

  • Qualquer webhook mutante criado exclui automaticamente o namespace kube-system.
  • Os webhooks mutantes estão desativados para os seguintes tipos de recursos:
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Restrições de prioridade do pod

O Distributed Cloud Connected exige que você defina a prioridade dos pods de carga de trabalho como um valor menor que 500000000.

Configurar a classe de ambiente de execução para um pod

Com o Distributed Cloud Connected, é possível especificar a classe de tempo de execução de um pod na configuração dele usando o campo runtimeClassName. Isso substitui a classe de runtime padrão especificada no nível do cluster. As classes de ambiente de execução disponíveis são runc e gvisor. Exemplo:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Se você omitir isso na configuração do pod, ele vai usar a classe especificada no nível do cluster. A classe de ambiente de execução padrão no nível do cluster é runc, a menos que você configure uma classe de ambiente de execução padrão usando o parâmetro --default-container-runtime, conforme descrito em Criar e gerenciar clusters.

Se você mudar a classe de execução no nível do pod ou do cluster, reinicie os pods afetados para que a mudança entre em vigor.

Classe de tempo de execução gvisor

Especificar a classe de tempo de execução gvisor muda o pod para o tempo de execução seguro da Open Container Initiative (OCI) com base no gVisor. O gVisor é uma solução de sandbox que introduz isolamento forte entre a carga de trabalho e o host.

A seguir