Implantar cargas de trabalho

Esta página descreve as etapas para implantar cargas de trabalho no hardware 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 do Distributed Cloud e faça o pedido do hardware do Distributed Cloud.

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

Os instaladores do Google concluem a instalação física, e o administrador do sistema conecta o Distributed Cloud à 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 . Depois, você estará pronto para provisionar pools de nós e implantar cargas de trabalho no Distributed Cloud.

Visão geral da implantação

Para implantar uma carga de trabalho no hardware da Distributed Cloud, faça o seguinte:

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

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

  3. Opcional: Configure a rede do Distributed Cloud.

  4. Crie um cluster 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 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.

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

  12. Opcional: conecte o cluster do Distributed Cloud a Google Cloud:

    1. Crie uma conexão VPN com seu Google Cloud projeto.

    2. Verifique se a conexão VPN está funcionando.

  13. Opcional: configure o Acesso privado do Google para permitir que seus pods acessem APIs e serviços doGoogle Cloud usando o Cloud VPN.

  14. Opcional: configure o Private Service Connect para permitir que seus pods acessem APIs e serviços doGoogle Cloud usando o Cloud VPN.

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 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

Implantar um contêiner com funções SR-IOV

O exemplo a seguir ilustra como implantar um pod que usa os recursos do operador de função de rede SR-IOV do Distributed Cloud.

Criar os componentes de rede do Distributed Cloud

Crie os componentes de rede necessários do Distributed Cloud da seguinte maneira. Para mais informações sobre esses componentes, consulte Recursos de rede do Distributed Cloud.

  1. Crie uma rede:

    gcloud edge-cloud networking networks create NETWORK_NAME \
    --location=REGION \
    --zone=ZONE_NAME \
    --mtu=MTU_SIZE

    Substitua:

    • NETWORK_NAME: um nome descritivo que identifica de forma exclusiva essa rede.
    • REGION: a Google Cloud região a que a zona de destino do Distributed Cloud pertence.
    • ZONE_NAME: o nome da zona de destino do Distributed Cloud.
    • MTU_SIZE: o tamanho da unidade máxima de transmissão (MTU) para essa rede. Os valores válidos são 1.500 e 9.000. Esse valor precisa corresponder ao tamanho da MTU da rede default e ser o mesmo para todas as redes.

  2. Crie uma sub-rede:

    gcloud edge-cloud networking subnets create SUBNETWORK_NAME \
    --network=NETWORK_NAME \
    --ipv4-range=IPV4_RANGE \
    --vlan-id=VLAN_ID \
    --location=REGION \
    --zone=ZONE_NAME

    Substitua:

    • SUBNETWORK_NAME: um nome descritivo que identifica exclusivamente esta sub-rede.
    • NETWORK_NAME: a rede que encapsula esta sub-rede.
    • IPV4_RANGE: o intervalo de endereços IPv4 que esta sub-rede abrange no formato de endereço IP/prefixo.
    • VLAN_ID: o ID da VLAN de destino para essa sub-rede.
    • REGION: a Google Cloud região a que a zona de destino do Distributed Cloud pertence.
    • ZONE_NAME: o nome da zona de destino do Distributed Cloud.

  3. Monitore o status da sub-rede até que ela seja criada:

    watch -n 30 'gcloud edge-cloud networking subnets list \
    --location=REGION \
    --zone=ZONE_NAME

    Substitua:

    • REGION: a Google Cloud região a que a zona de destino do Distributed Cloud pertence.
    • ZONE_NAME: o nome da zona de destino do Distributed Cloud.

    O status passa de PENDING para PROVISIONING e, por fim, para RUNNING.

    Registre o ID da VLAN, o bloco CIDR da sub-rede e o endereço IP do gateway para o bloco CIDR. Você vai usar esses valores mais tarde neste procedimento.

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 os switches ToR para funções de rede SR-IOV

Siga as etapas desta seção para configurar as interfaces de rede em cada switch ToR do Distributed Cloud no rack do Distributed Cloud para operação de funções de rede SR-IOV.

  1. Crie um arquivo chamado mlnc6-pcie1-tor1-sriov.yaml com o conteúdo a seguir. Esse arquivo configura a primeira interface de rede no primeiro switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor1_sriov

  2. Crie um arquivo chamado mlnc6-pcie1-tor2-sriov.yaml com o conteúdo a seguir. Esse arquivo configura a segunda interface de rede no primeiro switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor2_sriov

  3. Crie um arquivo chamado mlnc6-pcie2-tor1-sriov.yaml com o conteúdo a seguir. Esse arquivo configura a primeira interface de rede no segundo switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor1_sriov

  4. Crie um arquivo chamado mlnc6-pcie2-tor2-sriov.yaml com o conteúdo a seguir. Esse arquivo configura a segunda interface de rede no segundo switch ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor2_sriov

  5. Aplique os arquivos de configuração de ToR ao cluster usando os seguintes comandos:

    kubectl apply -f mlnc6-pcie1-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie1-tor2-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor2-sriov.yaml

    Os nós afetados são isolados, esvaziados e reinicializados.

  6. Monitore o status dos nós usando o seguinte comando:

    watch -n 5 'kubectl get sriovnetworknodestates -o yaml -A | \ 
grep "syncStatus\|pool-"|sed "N;s/\n/ /"'

    Quando todos os nós afetados mostrarem syncStatus: Succeeded, pressione Ctrl+C para sair do loop de comando de monitoramento.

    O comando retorna uma saída semelhante à seguinte, indicando que os recursos da função de rede SR-IOV foram ativados nos switches ToR:

    Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource                       Requests     Limits
--------                       --------     ------
cpu                            2520m (3%)   7310m (9%)
memory                         3044Mi (1%)  9774Mi (3%)
ephemeral-storage              0 (0%)       0 (0%)
hugepages-1Gi                  0 (0%)       0 (0%)
hugepages-2Mi                  0 (0%)       0 (0%)
devices.kubevirt.io/kvm        0            0
devices.kubevirt.io/tun        0            0
devices.kubevirt.io/vhost-net  0            0
gke.io/mlnx6_pcie1_tor1_sriov  3            3
gke.io/mlnx6_pcie1_tor2_sriov  0            0
gke.io/mlnx6_pcie2_tor1_sriov  0            0
gke.io/mlnx6_pcie2_tor2_sriov  0            0

Configurar um recurso NetworkAttachmentDefinition

Configure um recurso NetworkAttachmentDefinition para o cluster da seguinte maneira:

  1. Crie um arquivo chamado network-attachment-definition.yaml com o seguinte conteúdo:

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net1
annotations:
  k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_pcie1_tor1_sriov
spec:
config: '{
"type": "sriov",
"cniVersion": "0.3.1",
"vlan": VLAN_ID,
"name": "sriov-network",
"ipam": {
  "type": "host-local",
  "subnet": "SUBNETWORK_CIDR",
  "routes": [{
     "dst": "0.0.0.0/0"
  }],
  "gateway": "GATEWAY_ADDRESS"
}
}'

Substitua:

  • VLAN_ID: o ID da VLAN da sub-rede criada anteriormente neste guia.
  • SUBNETWORK_CIDR: o bloco CIDR da sub-rede.
  • GATEWAY_ADDRESS: o endereço IP do gateway da sub-rede.

  1. Aplique o recurso ao cluster usando o seguinte comando:

    kubectl apply -f network-attachment-definition.yaml

Implantar um pod com funções de rede SR-IOV

Conclua as etapas desta seção para implantar um pod com funções de rede SR-IOV no cluster. O campo annotations no arquivo de configuração do pod especifica o nome do recurso NetworkAttachmentDefinition criado anteriormente neste guia e o namespace em que ele foi implantado (default neste exemplo).

  1. Crie um arquivo de especificação do pod chamado sriovpod.yaml com o seguinte conteúdo:

         apiVersion: v1
     kind: Pod
     metadata:
     name: sriovpod
     annotations:
        k8s.v1.cni.cncf.io/networks: default/sriov-net1
     spec:
     containers:
     - name: sleeppodsriov
        command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
        image: busybox
        securityContext:
           capabilities:
           add:
              - NET_ADMIN

  2. Aplique o arquivo de especificação do pod ao cluster usando o seguinte comando:

    kubectl apply -f sriovpod.yaml

  3. Verifique se o pod foi iniciado usando o comando a seguir:

    kubectl get pods

  4. Estabeleça um shell de linha de comando para o pod usando o seguinte comando:

    kubectl exec -it sriovpod -- sh

  5. Confirme se o pod está se comunicando com os switches ToR usando o recurso de operador de função de rede SR-IOV com o seguinte comando no shell do pod:

    ip addr

    O comando retorna uma saída semelhante a esta:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host 
      valid_lft forever preferred_lft forever
51: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq qlen 1000
   link/ether 2a:af:96:a5:42:ab brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.11/25 brd 192.168.100.127 scope global net1
      valid_lft forever preferred_lft forever
228: eth0@if229: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
   link/ether 46:c9:1d:4c:bf:32 brd ff:ff:ff:ff:ff:ff
   inet 10.10.3.159/32 scope global eth0
      valid_lft forever preferred_lft forever
   inet6 fe80::44c9:1dff:fe4c:bf32/64 scope link 
      valid_lft forever preferred_lft forever

    As informações retornadas para a interface net1 indicam que a conectividade de rede entre os switches ToR e o pod foi estabelecida.

Limitações para cargas de trabalho da Distributed Cloud

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

Limitações de carga de trabalho do Linux

O Distributed Cloud é 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_RESOURCE
  • SYS_TIME

Restrições de namespace

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

  • hostPID
  • hostIPC
  • hostNetwork

Restrições de tipo de recurso

O Distributed Cloud 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 não é compatível com o contexto de segurança do modo privilegiado.

Restrições de vinculação de pod

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

hostPath restrições de volume

O Distributed Cloud 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 permite apenas os seguintes tipos de recursos PersistentVolumeClaim:

  • csi
  • nfs
  • local

Restrições de tipo de volume

O Distributed Cloud permite apenas os seguintes tipos de volumes:

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

Restrições de tolerância de pod

O Distributed Cloud não permite pods criados pelo usuário em nós do plano de controle. Especificamente, o Distributed Cloud 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 não é compatível com a representação de usuários ou grupos.

Restrições de namespace de gerenciamento

O Distributed Cloud não permite que os usuários acessem os seguintes namespaces:

  • kube-system, exceto para excluir ippools.whereabouts.cni.cncf.io
  • anthos-identity-service
  • cert-manager
  • gke-connect
  • kubevirt
  • metallb-system, exceto para editar recursos configMap e definir intervalos de endereços IP de balanceamento de carga.
  • nf-operator
  • sriov-network-operator

Restrições de webhook

O Distributed Cloud restringe 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

A seguir