TLSStress.Art — Deploy Multi-Nó (4 servidores UCS dedicados)¶

Última verificação contra o código de produção: v3.7.0 (2026-05-12) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA + a postura ZTP-prem 12/12 camadas contra operador insider (25 reivindicações de patente, partição Tier A/B, Confidential Computing, audit log selado em hash-chain, webhook de admission K8s, TPM 2.0 measured-boot, monitor DLP de egress, detector comportamental de anomalias). ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Autoria: André Luiz Gallon | Versão: v3.7.0 | Uso interno

Contexto: este guia cobre o cenário onde cada camada da plataforma roda em um servidor físico dedicado (UCS). Para o deploy single-node, consulte UBUNTU_K3S_SINGLENODE_QUICKSTART_DEPLOY.pt-BR.md.

Instalação automatizada (recomendada)¶

Use o script de instalação automatizada para configurar cada servidor. O script instala k3s, configura as VLANs e instala as dependências do Kubernetes — sem precisar de experiência prévia em Kubernetes.

Execute uma vez por servidor, na ordem indicada:

# Clone o repositório em cada servidor
git clone https://github.com/nollagluiz/AI_forSE.git && cd AI_forSE

# UCS-1 — servidor k3s + webservers persona (VLANs 101–120)
sudo ./scripts/k8s-install.sh --mode=multi-server --role=ngfw-dut --data-iface=eth1
# ↑ Imprime JOIN_TOKEN e SERVER_IP ao final — salve esses valores.

# UCS-2 — agentes browser-engine (VLAN 20)
sudo ./scripts/k8s-install.sh --mode=multi-agent --role=playwright \
     --server-ip=<IP-UCS-1> --token=<JOIN_TOKEN> --data-iface=eth1

# UCS-3 — agentes synthetic-load (VLAN 30)
sudo ./scripts/k8s-install.sh --mode=multi-agent --role=k6 \
     --server-ip=<IP-UCS-1> --token=<JOIN_TOKEN> --data-iface=eth1

# UCS-4 — Dashboard, Postgres, Grafana (somente eth0, sem interface de dados)
sudo ./scripts/k8s-install.sh --mode=multi-agent --role=infra \
     --server-ip=<IP-UCS-1> --token=<JOIN_TOKEN>

# De volta ao UCS-1 — aplicar todos os manifests Kubernetes
sudo ./scripts/k8s-install.sh --mode=multi-apply

Dry run: adicione --dry-run a qualquer comando para visualizar o que seria executado sem fazer alterações no sistema.

O restante deste guia explica cada etapa em detalhes, útil para personalizar a instalação ou depurar problemas.

Visão geral da arquitetura¶

                  ┌──────── OOBI (eth0) — 10.0.0.0/24 ────────────────────┐
                  │  K8s control plane · kubelet · Prometheus · DNS        │
                  │                                                          │
         ┌────────┴────────┐  ┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
         │    UCS-1        │  │    UCS-2          │  │    UCS-3          │  │    UCS-4          │
         │  role=ngfw-dut  │  │  role=playwright  │  │  role=k6          │  │  role=infra       │
         │                 │  │                  │  │                  │  │                  │
         │ 20 Personas     │  │ browser-engine agents │  │ synthetic-load agents        │  │ Dashboard        │
         │ (Caddy HTTPS)   │  │ (1–300 instâncias)│  │ (1–1000 instâncias)│  │ Postgres         │
         │                 │  │                  │  │                  │  │ Grafana          │
         │ eth1 → VLANs    │  │ eth1 → VLAN 20   │  │ eth1 → VLAN 30   │  │ cert-manager     │
         │   101–120       │  │  172.16.0.0/16   │  │  172.17.0.0/16   │  │ (eth0 apenas)    │
         └────────┬────────┘  └────────┬─────────┘  └────────┬─────────┘  └──────────────────┘
                  │                    │                       │
                  └────────────────────┴──────────────────────┘
                                       │
                              ┌────────┴────────┐
                              │  NGFW (DUT)     │
                              │  Inspeciona TLS │
                              │  em todas VLANs │
                              └────────┬────────┘
                                       │
                              ┌────────┴────────┐
                              │  Nexus 9000     │
                              │  Trunk 802.1q   │
                              └─────────────────┘

Mapa de nós¶

Servidor	Label K8s	Workloads	NICs necessárias	VLANs de dados
UCS-1	`role=ngfw-dut` + `dut-data-plane=true`	20 Synthetic + 10 Cloned slots (Caddy)	eth0 (OOBI) + eth1 (trunk)	VLANs 101–120 (10.1.x.0/27)
UCS-2	`role=playwright` + `dut-data-plane=true`	browser-engine agents (Deployment)	eth0 (OOBI) + eth1 (trunk)	VLAN 20 (172.16.0.0/16)
UCS-3	`role=k6` + `dut-data-plane=true`	synthetic-load agents (Deployment)	eth0 (OOBI) + eth1 (trunk)	VLAN 30 (172.17.0.0/16)
UCS-4	`role=infra`	Dashboard, Postgres, PgBouncer, Grafana, cert-manager	eth0 apenas	Nenhuma

A rede OOBI (Out-Of-Band Infrastructure)¶

O que é¶

OOBI é o nome dado ao plano de gerência/controle da plataforma. Na prática, é a eth0 em todos os quatro servidores — a interface de rede padrão do sistema operacional Ubuntu.

O que trafega pela OOBI¶

Protocolo / Serviço	Porta	Direção
k3s API Server (kubectl)	6443/TCP	UCS-2/3/4 → UCS-1
kubelet (health/exec/logs)	10250/TCP	Bidirecional
Flannel overlay (VXLAN)	8472/UDP	Bidirecional
Prometheus scrape (Caddy metrics)	9091/TCP	UCS-4 → UCS-1/2/3
Dashboard → Postgres	5432/TCP	UCS-4 interno
cert-manager → API Server	6443/TCP	UCS-4 → UCS-1
CoreDNS	53/UDP	Intra-cluster

O que NÃO trafega pela OOBI¶

O tráfego HTTPS de teste entre agentes, NGFW e webservers não passa pela OOBI. Esse tráfego usa a eth1 (VLAN trunk Nexus 9000) — completamente separado do plano K8s.

Requisitos de rede OOBI¶

Todos os quatro servidores UCS devem estar no mesmo segmento L2 (ou L3 com roteamento adequado) pela eth0:

UCS-1  eth0: 10.0.0.11/24   (k3s server — API server)
UCS-2  eth0: 10.0.0.12/24   (k3s agent)
UCS-3  eth0: 10.0.0.13/24   (k3s agent)
UCS-4  eth0: 10.0.0.14/24   (k3s agent)
Gateway:      10.0.0.1/24

Atenção: a subnet OOBI é somente para gerência. Nunca use o mesmo range de IPs da OOBI para VLANs de dados (eth1).

Parte 1 — Pré-requisitos¶

1.1 Sistema operacional¶

Ubuntu Server 22.04 LTS em todos os quatro servidores. Cada servidor deve ter: - Conectividade OOBI (eth0) entre todos os outros - Acesso SSH a partir da estação de trabalho do operador - curl, git instalados

1.2 Verificar conectividade OOBI¶

Do UCS-1 (que será o server k3s), testar alcance aos demais:

# Em UCS-1
ping -c2 10.0.0.12   # UCS-2
ping -c2 10.0.0.13   # UCS-3
ping -c2 10.0.0.14   # UCS-4

1.3 Sincronizar relógio (NTP)¶

# Em todos os servidores
sudo timedatectl set-ntp true
timedatectl status   # confirmar "synchronized: yes"

Parte 2 — Instalar k3s em modo multi-nó¶

2.1 UCS-1 — servidor k3s (control plane)¶

# Instalar k3s server com flannel na eth0 e labels do nó
curl -sfL https://get.k3s.io | sh -s - server \
  --flannel-iface=eth0 \
  --node-label=role=ngfw-dut \
  --node-label=dut-data-plane=true \
  --write-kubeconfig-mode 644

# Aguardar o node ficar Ready
sudo kubectl get nodes -w

Recuperar o token de join:

sudo cat /var/lib/rancher/k3s/server/node-token
# Guarda o valor — será usado pelos agentes k3s

Verificar o IP do API server:

echo "K3S_URL=https://10.0.0.11:6443"

2.2 UCS-2 — agente browser engine¶

# Substituir K3S_TOKEN pelo token obtido em UCS-1
export K3S_URL="https://10.0.0.11:6443"
export K3S_TOKEN="SEU_TOKEN_AQUI"

curl -sfL https://get.k3s.io | sh -s - agent \
  --server "$K3S_URL" \
  --token  "$K3S_TOKEN" \
  --flannel-iface=eth0 \
  --node-label=role=playwright \
  --node-label=dut-data-plane=true

2.3 UCS-3 — agente synthetic-load engine¶

export K3S_URL="https://10.0.0.11:6443"
export K3S_TOKEN="SEU_TOKEN_AQUI"

curl -sfL https://get.k3s.io | sh -s - agent \
  --server "$K3S_URL" \
  --token  "$K3S_TOKEN" \
  --flannel-iface=eth0 \
  --node-label=role=k6 \
  --node-label=dut-data-plane=true

2.4 UCS-4 — agente Infra¶

export K3S_URL="https://10.0.0.11:6443"
export K3S_TOKEN="SEU_TOKEN_AQUI"

curl -sfL https://get.k3s.io | sh -s - agent \
  --server "$K3S_URL" \
  --token  "$K3S_TOKEN" \
  --flannel-iface=eth0 \
  --node-label=role=infra

UCS-4 não recebe dut-data-plane=true pois não conecta ao NGFW.

2.5 Verificar todos os nós¶

# Em UCS-1
kubectl get nodes -o wide

Saída esperada:

NAME    STATUS   ROLES                  AGE   VERSION        INTERNAL-IP
ucs-1   Ready    control-plane,master   5m    v1.29.x+k3s1   10.0.0.11
ucs-2   Ready    <none>                 3m    v1.29.x+k3s1   10.0.0.12
ucs-3   Ready    <none>                 2m    v1.29.x+k3s1   10.0.0.13
ucs-4   Ready    <none>                 1m    v1.29.x+k3s1   10.0.0.14

Verificar os labels:

kubectl get nodes --show-labels | grep -E "role=|dut-data"

Parte 3 — Configurar VLANs nas interfaces de dados (eth1)¶

O tráfego de teste usa eth1 com 802.1q. Cada servidor precisa das sub-interfaces correspondentes ao seu papel.

3.1 UCS-1 — VLANs das personas (101–120)¶

# Habilitar 802.1q
sudo modprobe 8021q
echo "8021q" | sudo tee -a /etc/modules

# Script de configuração (exemplo para as 20 personas)
for vlan in $(seq 101 120); do
  i=$((vlan - 100))
  sudo ip link add link eth1 name "eth1.${vlan}" type vlan id "${vlan}"
  sudo ip addr add "10.1.${i}.1/27" dev "eth1.${vlan}"
  sudo ip link set "eth1.${vlan}" up
done

# Persistir via netplan (ajustar conforme seu ambiente)

3.2 UCS-2 — VLAN 20 (browser engine)¶

sudo modprobe 8021q
sudo ip link add link eth1 name eth1.20 type vlan id 20
sudo ip addr add 172.16.0.1/16 dev eth1.20
sudo ip link set eth1.20 up

3.3 UCS-3 — VLAN 30 (synthetic-load engine)¶

sudo modprobe 8021q
sudo ip link add link eth1 name eth1.30 type vlan id 30
sudo ip addr add 172.17.0.1/16 dev eth1.30
sudo ip link set eth1.30 up

3.4 UCS-4 — Nenhuma VLAN de dados¶

UCS-4 (infra) não tem eth1 de dados. Apenas eth0 (OOBI) é necessária.

Parte 4 — Instalar pré-requisitos do cluster¶

4.1 Multus CNI¶

kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
kubectl -n kube-system rollout status daemonset/kube-multus-ds

4.2 cert-manager¶

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
kubectl -n cert-manager rollout status deployment/cert-manager
kubectl -n cert-manager rollout status deployment/cert-manager-webhook

4.3 Prometheus stack (Grafana + AlertManager)¶

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm upgrade --install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword=admin \
  --wait

Parte 5 — Clonar o repositório¶

# Em UCS-1 (ou na estação de trabalho do operador com kubectl configurado)
git clone https://github.com/nollagluiz/AI_forSE.git
cd AI_forSE

Parte 6 — Deploy com Kustomize overlay multi-nó¶

O overlay k8s/overlays/multi-node/ adiciona nodeSelector a cada Deployment/StatefulSet, fixando cada carga de trabalho no servidor correto.

k8s/overlays/multi-node/
├── kustomization.yaml              # overlay principal
├── patch-playwright-nodesel.yaml   # web-agent → role=playwright (UCS-2)
├── patch-k6-nodesel.yaml           # k6-agent → role=k6 (UCS-3)
└── patch-infra-nodesel.yaml        # dashboard/postgres/pgbouncer → role=infra (UCS-4)

As personas (Caddy DUT) ficam em UCS-1 via o DUT overlay (Passo 7).

6.1 Aplicar o overlay¶

kubectl apply -k k8s/overlays/multi-node/

Verificar que os pods foram agendados nos nós corretos:

kubectl get pods -n web-agents -o wide

Saída esperada:

NAME                         NODE    ...
web-agent-xxx                ucs-2   (role=playwright)
k6-agent-xxx                 ucs-3   (role=k6)
dashboard-xxx                ucs-4   (role=infra)
postgres-0                   ucs-4   (role=infra)
pgbouncer-xxx                ucs-4   (role=infra)

Parte 7 — Deploy DUT overlay (personas + PKI + NGFW)¶

# 4 fases automáticas
bash scripts/k8s-dut-up.sh up

As fases são:

Fase	O que faz
1 — Base	namespace, quotas, ConfigMaps, Deployments (usam nodeSelector do overlay)
2 — DUT overlay	PSA labels, Stakater Reloader, NetworkPolicy DUT, patch macvlan nos agentes
3 — Platform	CoreDNS personas, cert-manager PKI, SNMP exporter, Prometheus rules
4 — Personas	20 namespaces de personas com webservers Caddy

Parte 8 — Tuning do host (OBRIGATÓRIO para personas)¶

As stacks de Synthetic Personas e Cloned Personas exigem este tuning para entregar throughput de teste alvo. Sem ele, os buffers UDP do kernel limitam QUIC a ~30 Mbps por réplica, e o cwnd do TCP é resetado a cada janela idle de HTTP/2 (~1 ms RTT extra por cycle).

O DaemonSet node-tuning aplica os mesmos sysctls em runtime, mas não sobrevive a reboot até o pod voltar a subir. O script scripts/host-tuning.sh grava os valores em /etc/sysctl.d/, instala um systemd unit pro CPU governor e (opcionalmente) liga cpuManagerPolicy: static pra alocação exclusiva de cores — transformando o DaemonSet em rede de segurança e não única linha de defesa após reboot.

Rodar em CADA host UCS que escala uma Synthetic Persona, slot Cloned-Persona ou o Cloner. Em deploy de 4 nós isso é UCS-1 (personas + slots) e UCS-4 (Cloner + NFS server):

# UCS-1 (role=ngfw-dut) — 20 personas + 10 slots cloned-persona
sudo scripts/host-tuning.sh apply --enable-cpu-pinning

# UCS-4 (role=infra) — Cloner + NFS server
sudo scripts/host-tuning.sh apply --enable-cpu-pinning

# Verificar
sudo scripts/host-tuning.sh status

--enable-cpu-pinning ativa cpuManagerPolicy: static no kubelet (k3s e vanilla auto-detectados) e reinicia o kubelet — planejar janela. Sem a flag o script ainda aplica sysctls, módulos, governor e THP — pinning é o único passo que toca workloads em execução.

UCS-2 (browser engine) e UCS-3 (synthetic-load engine) rodam só pods de agente. Beneficiam dos sysctls mas não precisam de pinning. Rodar lá também, sem --enable-cpu-pinning:

sudo scripts/host-tuning.sh apply   # só sysctls + módulos + governor

8.1 Expandir o DaemonSet node-tuning para nós data-plane¶

O DaemonSet node-tuning usa por padrão role=ngfw-dut (somente UCS-1). No cenário multi-nó, os agentes em UCS-2 e UCS-3 também precisam de tuning de kernel em runtime:

kubectl patch daemonset node-tuning -n web-agents \
  --type=strategic-merge-patch \
  -p '{"spec":{"template":{"spec":{"nodeSelector":{"dut-data-plane":"true"}}}}}'

Verificar que o DaemonSet roda em UCS-1, 2 e 3 (mas não UCS-4):

kubectl get pods -n web-agents -l app=node-tuning -o wide

Parte 9 — Verificação completa¶

9.1 Pods por nó¶

kubectl get pods -A -o wide | awk 'NR==1 || /web-agents|persona/'

9.2 Agentes alcançam os sites via NGFW¶

# Verificar que o web-agent consegue resolver e abrir as personas
kubectl exec -n web-agents deploy/web-agent -- \
  curl -sk https://shop.persona.internal | head -5

9.3 Métricas disponíveis¶

# Prometheus recebe dados de todos os nós
kubectl port-forward svc/kube-prometheus-stack-prometheus -n monitoring 9090:9090 &
# Abrir http://localhost:9090 e buscar: caddy_http_requests_total

9.4 Grafana¶

kubectl port-forward svc/kube-prometheus-stack-grafana -n monitoring 3000:80 &
# http://localhost:3000  admin/admin

Parte 10 — StorageClass para Postgres em multi-nó¶

No cenário single-node, o Postgres usa local-path (provisionador padrão k3s). No multi-nó, o PVC continua sendo provisionado em UCS-4 graças ao nodeSelector: role=infra.

Não é necessário Longhorn ou outro provisionador distribuído — o local-path funciona corretamente quando o pod está fixado ao nó via nodeSelector.

Para confirmar:

kubectl get pvc -n web-agents
# STORAGECLASS deve ser "local-path"
# O pod postgres-0 deve estar em ucs-4

Parte 11 — Opções de escalabilidade¶

Adicionar um segundo nó browser engine¶

# Instalar k3s agent no novo servidor UCS-2b
curl -sfL https://get.k3s.io | sh -s - agent \
  --server "https://10.0.0.11:6443" \
  --token  "$K3S_TOKEN" \
  --flannel-iface=eth0 \
  --node-label=role=playwright \
  --node-label=dut-data-plane=true

# O Deployment web-agent usa HPA — os pods serão distribuídos automaticamente

Separar personas em UCS dedicados¶

Se desejar distribuir as 20 personas entre múltiplos servidores, ajuste os labels das personas e adicione nodeSelector no DUT overlay conforme necessário.

Troubleshooting¶

Pod não agendado — evento "0/4 nodes are available"¶

kubectl describe pod <nome-do-pod> -n web-agents
# Verificar seção "Events" — "didn't match nodeSelector"

Verificar labels dos nós:

kubectl get nodes --show-labels | grep role

Personas não respondem via NGFW¶

Verificar que as sub-interfaces VLAN estão up em UCS-1:
```
ip link show | grep eth1
```
Verificar que o NGFW tem rota de retorno para as VLANs 101–120.
Verificar NetworkPolicy:
```
kubectl get networkpolicy -A
```

node-tuning não roda em UCS-2 ou UCS-3¶

kubectl get ds node-tuning -n web-agents -o jsonpath='{.spec.template.spec.nodeSelector}'
# Deve retornar: {"dut-data-plane":"true"}
# Se retornar {"role":"ngfw-dut"}, reaplicar o patch da Parte 8

Prometheus não coleta métricas das personas¶

O Prometheus scrape usa eth0 (OOBI). Confirmar que o Caddy exporta métricas na porta 9091 via eth0:

kubectl exec -n persona-shop deploy/caddy-shop -- \
  wget -qO- http://$(hostname -I | awk '{print $1}'):9091/metrics | head -5

Referência rápida — comandos mais usados¶

# Verificar nós e labels
kubectl get nodes --show-labels

# Ver distribuição de pods por nó
kubectl get pods -n web-agents -o wide

# Escalar agentes browser-engine (ex: 50 réplicas)
kubectl scale deployment web-agent -n web-agents --replicas=50

# Escalar agentes k6 (ex: 200 réplicas)
kubectl scale deployment k6-agent -n web-agents --replicas=200

# Verificar DaemonSet de tuning
kubectl get pods -n web-agents -l app=node-tuning -o wide

# Logs do Caddy em UCS-1
kubectl logs -n persona-shop deploy/caddy-shop --tail=50 -f

# Status geral
bash scripts/k8s-dut-up.sh status

Cloner de sites públicos + storage cross-node (multi-node)¶

Em um cluster multi-node de 4 servidores, o cloner roda em UCS-4 (role=infra), co-localizado com o Dashboard. Os 10 slots de cloned-persona rodam em UCS-1 (role=ngfw-dut), junto com as personas sintéticas. Esses dois tiers vivem em máquinas físicas diferentes, então o conteúdo clonado precisa atravessar uma rede real entre o escritor e os leitores.

Arquitetura de storage (leia antes de instalar multi-node)¶

O volume compartilhado cloned-sites é apoiado por um NFS server in-cluster (k8s/dut/35-nfs-server.yaml) agendado em role=infra (UCS-4) — mesmo nó do cloner. Onze pares estáticos PV/PVC (k8s/dut/36-cloned-sites-pvs.yaml) — um writer read-write em web-agents, dez leitores read-only em clone-persona-1..10 — apontam todos para o mesmo export NFS.

UCS-4 (role=infra):    [cloner pod]   [nfs-server pod]
                            │              │
                            │ escreve      │ /var/lib/agent-cluster/cloned-sites
                            │ via PVC      │ (hostPath, persistente)
                            ▼              ▼
                       NFSv4 sobre OOBI (eth0, ClusterIP Service:2049)
                            ▲
                            │ leitura via PVC read-only
                            │
UCS-1 (role=ngfw-dut): [clone-persona-1..10]

Pontos críticos:

Todo tráfego NFS usa o plano OOBI (eth0 / pod network → ClusterIP nfs-server.web-agents.svc.cluster.local). O plano de dados (net1 macvlan VLAN 40 ISP e VLANs 200–209 das subnets de slot) nunca carrega I/O de storage — fica reservado pra tráfego agente ↔ NGFW ↔ persona, mantendo as medições de timing limpas.
O disco subjacente do NFS server é o hostPath em UCS-4. A capacidade depende do disco do UCS-4, não do que os PVCs pedem (50 GiB por convenção).
O nodeAffinity do cloner (role=infra) e o preferredAffinity do NFS server (role=infra) DEVEM coincidir. Se mover o cloner pra outro nó, mova também o NFS server.
O DaemonSet CNI DHCP (k8s/dut/30-cni-dhcp-daemon.yaml) roda em todos os nós — necessário em UCS-4 (onde o cloner está) pra que o IPAM da VLAN 40 chame o helper dhcp via /run/cni/dhcp.sock.

Objetivo¶

O cloner baixa sites públicos reais via VLAN 40 (acesso direto à internet, sem NGFW no caminho) e escreve no NFS. Os 10 slot pods em UCS-1 montam o mesmo export NFS read-only e servem o conteúdo via Caddy. A frota de agentes acessa esses slots através do NGFW, exercitando inspeção TLS real com conteúdo de sites conhecidos.

Verificação rápida¶

# Cloner em UCS-4
kubectl get pod -n web-agents -l app.kubernetes.io/name=cloner -o wide

# NFS server em UCS-4 (mesmo nó)
kubectl get pod -n web-agents -l app.kubernetes.io/name=nfs-server -o wide

# DHCP daemon em todos os nós
kubectl get ds cni-dhcp-daemon -n web-agents

# IP da VLAN 40 e internet
kubectl exec -n web-agents deploy/cloner -- ip addr show net1
kubectl exec -n web-agents deploy/cloner -- ping -c 3 8.8.8.8

# Slots montando o NFS
kubectl get pvc -A | grep cloned-sites

Troubleshooting¶

Sintoma	Verificação
Cloner em outro nó	`kubectl get pod -o wide` → NODE deve ser UCS-4
`net1` sem IP	VLAN 40 no trunk Nexus; `eth1.40` no UCS-4; DHCP daemon Ready
Sem internet	`kubectl exec deploy/cloner -- ping -c 3 -I net1 8.8.8.8`
Slots com `MountVolume.SetUp failed`	NFS server pronto e no MESMO nó do cloner
Slots Ready mas servindo vazio	Cloner gravou em outro nó antes do NFS subir; reinicie NFS depois cloner
`cloned-sites` PVC `Pending`	`kubectl describe pv` — verifica binding estático

Ver também¶

docs/CLONER.md — referência completa de arquitetura
docs/CLONER_OPERATIONS.md — playbook operacional
k8s/dut/35-nfs-server.yaml + 36-cloned-sites-pvs.yaml — storage cross-node
overlays/multi-node/kustomization.yaml — fixa o cloner em role=infra

Próximos passos¶

Consulte UBUNTU_K3S_SINGLENODE_QUICKSTART_DEPLOY.pt-BR.md para o quickstart single-node
Consulte DUT_TESTBED.md para configuração do NGFW físico
Consulte PERFORMANCE_TUNING.md para ajustes finos de performance
Consulte K6_FLEET.md para operar a frota k6

TLSStress.Art v3.7.0 — Autoria: André Luiz Gallon