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.

  12. Opcional: conecte o cluster do Distributed Cloud conectado 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 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

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

Criar os componentes de rede do Distributed Cloud

Crie os componentes de rede necessários para sua implantação conectada do Distributed Cloud da seguinte maneira. Para mais informações sobre esses componentes, consulte Recursos de rede conectada 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 conectada 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 pertence a zona de destino do Distributed Cloud Connected.
    • ZONE_NAME: o nome da zona conectada 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 pertence a zona de destino do Distributed Cloud Connected.
    • ZONE_NAME: o nome da zona conectada 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 conectado 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.

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
  • sriov-fec-system
  • sriov-network-operator
  • 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