Para informações sobre a versão, consulte as notas da versão conectada do Distributed Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 momento da compra.

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

Depois que o hardware é conectado à 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:

Opcional: Ative a API Distributed Cloud Edge Network.
Opcional: Inicialize a configuração de rede da sua zona conectada do Distributed Cloud.
Opcional: Configure a rede do Distributed Cloud.
Crie um cluster conectado do Distributed Cloud.
Opcional: Ative o suporte para chaves de criptografia gerenciadas pelo cliente (CMEK) para armazenamento local se quiser fazer a integração com o 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.
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.
Receba as credenciais de um cluster para testá-lo.
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.
Atribua aos usuários acesso granular baseado em papéis aos recursos do cluster usando RoleBinding e ClusterRoleBinding.
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.
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:

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

Aplique o arquivo YAML ao cluster usando o seguinte comando:
```
kubectl apply -f nginx-deployment.yaml
```

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

Aplique o arquivo YAML ao cluster usando o seguinte comando:
```
kubectl apply -f nginx-deployment.yaml
```

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.

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.

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.

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 imagem 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 é compatível com 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 a exclusão de 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

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) baseado no gVisor. O gVisor é uma solução de sandbox que introduz isolamento forte entre a carga de trabalho e o host.

Configurar a integração do VPC Service Controls

Conclua as etapas nesta seção para configurar a integração da API Distributed Cloud Edge Container com o VPC Service Controls. Para ver mais informações, consulte os seguintes tópicos:

Especificar a prioridade de execução de um pod

Com o Distributed Cloud Connected, é possível especificar uma classe de prioridade para um pod na configuração usando o campo priorityClassName. Esse campo aceita o nome de um recurso PriorityClass que especifica a prioridade de destino. Exemplo:

kind: PriorityClass
metadata:
  name: high-priority-class
value: 5100000
globalDefault: false
description: "High priority class for user workloads."

Especifique o nome da classe de prioridade na configuração do pod, conforme mostrado no exemplo a seguir:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  priorityClassName: high-priority-class
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

Especificar uma classe de prioridade substitui a prioridade padrão do pod, que é 0. Para cargas de trabalho críticas, defina a prioridade como um valor entre 5000001 e 1000000000. O Distributed Cloud conectado remove automaticamente cargas de trabalho de menor prioridade.

Regras de saída obrigatórias

Você precisa configurar as regras de saída descritas nesta seção para integrar a API Distributed Cloud Edge Container com o VPC Service Controls. Para informações sobre a sintaxe das regras de saída, consulte Referência de regras de saída.

Acesso à zona da máquina e ao projeto Google Cloud

Essa regra permite que a identidade de chamada acesse a zona da máquina e o projeto Google Cloud ao fazer chamadas usando a API Distributed Cloud Edge Container. Essa regra se aplica quando a máquina e o cluster não estão no mesmo projetoGoogle Cloud e o projeto Google Cloud da máquina está fora do perímetro. Essa regra é obrigatória se você restringiu a API Distributed Cloud Edge Container dentro do perímetro usando o VPC Service Controls.

Confira a seguir um exemplo de configuração egressFrom para essa regra no formato JSON:

egressFrom:
  identityType: ANY_SERVICE_ACCOUNT
  sources:
    - accessLevel: "*"

Confira a seguir um exemplo de configuração de egressTo para essa regra:

egressTo:
 resources:
 - "projects/280968151686"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Regras de entrada obrigatórias

Você precisa configurar as regras de entrada descritas nesta seção para integrar a API Distributed Cloud Edge Container com o VPC Service Controls. Para informações sobre a sintaxe das regras de entrada, consulte Referência de regras de entrada.

Acesso à API Distributed Cloud Edge Container

Essa regra permite que identidades específicas acessem e interajam com a API Distributed Cloud Edge Container. Configure essa regra se você restringiu a API Distributed Cloud Edge Container dentro do perímetro usando o VPC Service Controls e a identidade que chama a API Distributed Cloud Edge Container está fora do perímetro.

Confira a seguir um exemplo de configuração de ingressFrom para essa regra:

ingressFrom:
   sources:
     - accessLevel: '*'
   identities:
     - serviceAccount:testuser@kubernetesedge-e2e-testing.iam.gserviceaccount.com

Confira a seguir um exemplo de configuração de ingressTo para essa regra:

ingressTo:
 resources:
 - "*"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

Acesso à API Connect e à API Security Token Service

Essa regra permite que as cargas de trabalho acessem a API Connect e a API Security Token Service. Você precisa configurar essa regra se tiver restringido o acesso à API Connect e à API Security Token Service dentro do perímetro usando o VPC Service Controls. Para informações sobre como configurar políticas de acesso no nível do endereço IP, consulte Endereço IP.