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

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 essas etapas, você deve atender aos requisitos de instalação do Distributed Cloud conectado e pedir o hardware do Distributed Cloud.

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

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

Depois que o hardware é conectado à rede local, ele se comunica com Google Cloud para baixar atualizações de software e se conectar ao Google Cloud projeto. Em seguida, você está pronto para provisionar pools de nós e implantar cargas de trabalho no Distributed Cloud conectado.

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 zona conectada do Distributed Cloud.
Opcional: configure a rede do Distributed Cloud.
Crie um cluster conectado do Distributed Cloud.
Opcional: ative o suporte a 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 carga de trabalho. Para informações sobre como o Distributed Cloud conectado 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 credenciais para 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 ao ambiente de execução de VMs no Google Distributed Cloud para executar cargas de trabalho em máquinas virtuais no Distributed Cloud conectado.
Opcional: ative o suporte a GPU para executar cargas de trabalho baseadas em GPU no Distributed Cloud conectado.

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

Receba o endereço IP externo atribuído ao serviço pelo balanceador de carga do MetalLB usando o seguinte comando:

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. 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 recurso 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 node-system-config-update-NODE_SHORT_NAME.yaml.

Aplique cada um dos arquivos de recurso 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ó faz a transição de not-ready para ready à medida que as reinicializações são concluídas.

Configurar um pod para armazenamento em cache de imagens

É possível configurar um pod em execução em um cluster conectado do Distributed Cloud para armazenar a imagem em cache. 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 as 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 armazenada em cache da imagem de destino seja sempre usada. Se uma cópia armazenada 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 armazenamento em 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 armazenamento em 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 do Distributed Cloud

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

Limitações de carga de trabalho do Linux

O Distributed Cloud conectado oferece suporte apenas aos 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 conectado não oferece suporte aos seguintes namespaces:

hostPID
hostIPC
hostNetwork

Restrições de tipo de recurso

O Distributed Cloud conectado não oferece suporte ao 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 conectado não oferece suporte ao contexto de segurança do modo privilegiado.

Restrições de vinculação de pods

O Distributed Cloud conectado não oferece suporte à vinculação de pods a portas de host no namespace HostNetwork. Além disso, o namespace HostNetwork não está disponível.

Restrições de volume `hostPath`

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

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

Restrições de tipo de recurso `PersistentVolumeClaim`

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

csi
nfs
local

Restrições de tipo de volume

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

configMap
csi
downwardAPI
emptyDir
hostPath
nfs
persistentVolumeClaim
projected
secret

Restrições de tolerância de pods

O Distributed Cloud conectado não permite pods criados pelo usuário em nós do plano de controle. Especificamente, o Distributed Cloud conectado não permite o agendamento de pods que tenham 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 conectado não oferece suporte à representação de usuários ou grupos.

Restrições de namespace de gerenciamento

O Distributed Cloud conectado não permite 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, com exceção da exclusão de ippools.whereabouts.cni.cncf.io
metallb-system , com exceção da edição de recursos configMap para 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 de destino Google Cloud .

Evite o uso de qualquer namespace com o prefixo g- no nome. Esses namespaces são normalmente um namespace reservado usado pelo Distributed Cloud conectado.

Restrições de webhook

O Distributed Cloud conectado restringe os webhooks da seguinte maneira:

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

Restrições de prioridade de pods

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

O Distributed Cloud conectado permite especificar a classe de ambiente de execução de um pod na configuração usando o campo runtimeClassName. Isso substitui a classe de ambiente de execução 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 usará a classe especificada no nível do cluster. A classe de ambiente de execução padrão 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 ambiente de execução no nível do pod ou do cluster, será necessário reiniciar os pods afetados para que a mudança entre em vigor.

Classe de ambiente de execução `gvisor`

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

Configurar a integração do VPC Service Controls

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

Regras de saída necessá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 da regra de saída, consulte Referência de regras de saída.

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

Essa regra permite que a identidade de chamada acesse a zona da máquina e o Google Cloud projeto 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 Google Cloud projeto e o projeto da máquina está fora do perímetro. Google Cloud Essa regra é necessá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 egressTo para essa regra:

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

Regras de entrada necessá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 da regra 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. Você precisa configurar essa regra se 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 ingressFrom para essa regra:

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

Confira a seguir um exemplo de configuração 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 restringiu 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.