Campos de compatibilidade no nível de pod para Sandboxed-Container - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

O Sandboxed-Container executa cada pod em uma VM isolada com o runtime runV. O runV é compatível com o runC em todos os campos no nível de pod, exceto em um pequeno conjunto que exige acesso ao namespace no nível do host — o que é arquitetonicamente incompatível com o isolamento baseado em VM. As categorias a seguir não têm suporte no nível de pod:

Rede de pods e containers
Rede de serviços, como ClusterIP e NodePort
Gerenciamento de imagens

Seus fluxos de trabalho de desenvolvimento, empacotamento de imagens e outros pipelines existentes funcionam sem modificações.

Campos sem suporte

Os campos abaixo não têm suporte porque o Sandboxed-Container executa cada pod em uma VM isolada. Campos que acessam namespaces no nível do host ou contextos de dispositivos não conseguem atravessar o limite da VM:

Campo	Escopo	Motivo
`hostIPC`	Pod	Requer namespace IPC do host
`hostNetwork`	Pod	Requer namespace de rede do host
`hostPID`	Pod	Requer namespace PID do host
`shareProcessNamespace`	Pod	Exige namespace de processos compartilhado entre containers
`privileged`	Subcampo de `containers`	O isolamento baseado em VM não oferece suporte a repasse direto de dispositivos do host
`windowsOptions`	Subcampo de `containers`	Não há suporte para runtime de container Windows

Avalie o impacto da migração

Se a especificação do seu pod não utilizar nenhum dos campos listados em Campos sem suporte, a migração para o Sandboxed-Container não exige alterações de configuração.

Campos de pod com suporte

Campo	Compatível
`activeDeadlineSeconds`	Sim
`affinity`	Sim
`automountServiceAccountToken`	Sim
`containers`	Parcial — consulte Detalhes do campo containers
`dnsConfig`	Sim
`dnsPolicy`	Sim
`enableServiceLinks`	Sim
`hostAliases`	Sim
`hostIPC`	Não
`hostNetwork`	Não
`hostPID`	Não
`hostname`	Sim
`imagePullSecrets`	Sim
`initContainers`	Sim
`nodeName`	Sim
`nodeSelector`	Sim
`priority`	Sim
`priorityClassName`	Sim
`readinessGates`	Sim
`restartPolicy`	Sim
`runtimeClassName`	Sim
`schedulerName`	Sim
`securityContext`	Sim — há suporte completo para `fsGroup`, `runAsGroup`, `runAsNonRoot`, `runAsUser`, `seLinuxOptions`, `supplementalGroups` e `sysctls`
`serviceAccount`	Sim
`serviceAccountName`	Sim
`shareProcessNamespace`	Não
`subdomain`	Sim
`terminationGracePeriodSeconds`	Sim
`tolerations`	Sim
`volumes`	Sim

Detalhes do campo containers

O campo containers tem suporte parcial.

Subcampos com suporte:

Subcampo	Observações
`args`, `command`, `env`, `envFrom`, `image`, `imagePullPolicy`, `lifecycle`, `livenessProbe`, `name`, `ports`, `readinessProbe`, `resources`, `startupProbe`, `stdin`, `stdinOnce`, `terminationMessagePath`, `terminationMessagePolicy`, `tty`, `volumeDevices`, `volumeMounts`, `workingDir`	Suporte total
`securityContext.allowPrivilegeEscalation`, `securityContext.capabilities`, `securityContext.procMount`, `securityContext.readOnlyRootFilesystem`, `securityContext.runAsGroup`, `securityContext.runAsNonRoot`, `securityContext.runAsUser`, `securityContext.seLinuxOptions`	Suporte total

Subcampos sem suporte:

Subcampo	Motivo
`privileged`	O isolamento baseado em VM não oferece suporte a repasse direto de dispositivos do host
`windowsOptions`	Não há suporte para runtime de container Windows