Documentação do Oracle Cloud Infrastructure

Ir para o conteúdo principal

Operador de Rede NVIDIA

Ao ativar o complemento de cluster do Operador de Rede NVIDIA, você pode passar os seguintes pares de chave/valor como argumentos.

Argumentos de Configuração Comuns à maioria dos Complementos de Cluster


Chave (API e CLI)	Nome para Exibição da Chave (Console)	Descrição	Obrigatório/Opcional	Valor Padrão	Valor de Exemplo
`affinity`	afinidade	Um grupo de regras de programação de afinidade. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Operador de GPU Nvidia Possíveis equivalentes: Descoberta de Recursos do Nó, use `master.affinity` Operador de Rede NVIDIA, use `operator.affinity` Driver SMB CSI, use `contoller.affinity` Operador de GPU AMD, use `controllerManager.affinity`	Opcional	null	null
`nodeSelectors`	seletores de nó	Você pode usar seletores de nó e labels de nó para controlar os nós de trabalho nos quais os pods complementares são executados. Para que um pod seja executado em um nó, o seletor de nós do pod deve ter a mesma chave/valor do label do nó. Defina `nodeSelectors` como um par de chave/valor que corresponda ao seletor de nós do pod e ao label do nó de trabalho. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Operador de GPU NVIDIA SMB do Driver CSI Possíveis equivalentes: Descoberta de Recursos do Nó, use `worker.nodeSelector` Operador de Rede NVIDIA, use `operator.nodeSelectors` Operador de GPU AMD, use `selector` ou `controllerManager.nodeSelector`	Opcional	null	`{"foo":"bar", "foo2": "bar2"}` O pod só será executado em nós que tenham o label `foo=bar` ou `foo2=bar2`.
`numOfReplicas`	numOfReplications	O número de réplicas da implantação do complemento. Não utilizado por: Plug-in de GPU AMD Operador de GPU NVIDIA Operador de Rede NVIDIA SMB do Driver CSI Possíveis equivalentes: CoreDNS, use `nodesPerReplica` Descoberta de Recursos do Nó, use `master.replicaCount` Operador de GPU AMD, use `controllerManager.replicas`	Obrigatório	`1` Cria uma réplica da implantação do complemento por cluster.	`2` Cria duas réplicas da implantação do complemento por cluster.
`rollingUpdate`	Atualização incremental	Controla o comportamento desejado de atualização incremental por maxSurge e maxUnavailable. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Descoberta de Recurso do Nó Operador de Rede NVIDIA SMB do Driver CSI Possíveis equivalentes: Operador de GPU NVIDIA, use `daemonsets.rollingUpdate.maxUnavailable` Operador de GPU AMD, use `upgradePolicy` em `devicePlugin`, `metricsExporter`, `testRunner`, `configManager` ou `draDriver`	Opcional	null	null
`tolerations`	tolerâncias	Você pode usar taints e tolerations para controlar os nós de trabalho nos quais os pods complementares são executados. Para que um pod seja executado em um nó que tenha uma taint, o pod deve ter uma tolerância correspondente. Defina `tolerations` como um par de chave/valor que corresponda à tolerância do pod e à mancha do nó de trabalho. Formato JSON em texto simples ou codificado em Base64. Possíveis equivalentes: Descoberta de Recursos do Nó, use `master.tolerations` e/ou `worker.tolerations` Operador de GPU NVIDIA, use `daemonsets.tolerations` Operador de Rede NVIDIA, use `operator.tolerations` Driver SMB CSI, use `controller.tolerations` Operador de GPU AMD, usar tolerações em `devicePlugin`, `metricsExporter`, `testRunner`, `configManager`, `draDriver` ou `controllerManager`	Opcional	null	`[{"key":"tolerationKeyFoo", "value":"tolerationValBar", "effect":"noSchedule", "operator":"exists"}]` Somente pods que têm essa tolerância podem ser executados em nós de trabalho que têm a mancha `tolerationKeyFoo=tolerationValBar:noSchedule`.
`topologySpreadConstraints`	topologiaSpreadConstraints	Como distribuir pods correspondentes entre a topologia fornecida. Formato JSON em texto simples ou codificado em Base64. Não utilizado por: Descoberta de Recurso do Nó Operador de GPU NVIDIA Operador de Rede NVIDIA SMB do Driver CSI AMD GPU Operator	Opcional	null	null

Argumentos de Configuração Específicos para esta Extensão de Cluster


Chave (API e CLI)	Nome para Exibição da Chave (Console)	Descrição	Obrigatório/Opcional	Valor Padrão	Valor de Exemplo
`operator.nodeSelectors`	nvidia-rede-operador nodeSelectors	Seletores de nó nos pods Operador de Rede NVIDIA.	Opcional	`null`
`operator.tolerations`	nvidia-network-operator tolerâncias	Tolerâncias nos pods NVIDIA Network Operator.	Opcional	`null`
`nicClusterPolicy.tolerations`	tolerâncias nicClusterPolicy	Tolerâncias para DaemonSets gerenciados por NicClusterPolicy.	Opcional	`null`
`nicClusterPolicy.deploymentTolerations`	nicClusterPolicy deploymentTolerâncias	Tolerâncias para Implantações gerenciadas por NicClusterPolicy.	Opcional	`null`
`operator.affinity`	afinidade nvidia-rede-operador	Regras de programação de afinidade para o Operador de Rede NVIDIA. Formato JSON em texto sem formatação.	Opcional	`null`
`operator.resources`	recursos de contêiner nvidia-network-operator	Os recursos do Operador de Rede NVIDIA controlam os limites de recursos e as solicitações do contêiner `nvidia-network-operator`. Formato JSON em texto sem formatação.	Opcional	`{"limits": {"cpu": "500m", "memory": "128Mi"}, "requests": {"cpu": "5m", "memory": "64Mi"}}`
`operator.cniBinDirectory`	cniBinDiretório	Diretório binário CNI para Operador de Rede NVIDIA.	Opcional	`/opt/cni/bin`
`operator.cniNetworkDirectory`	cniNetworkDirectory	Diretório de rede CNI para Operador de Rede NVIDIA.	Opcional	`/etc/cni/net.d`
`operator.admissionControllers.enabled`	operator.admissionControllers.ativado	Ative controladores de admissão para o Operador de Rede NVIDIA.	Opcional	`false`
`sriovNetworkOperator.enabled`	sriovNetworkOperator.ativado	Ative o Operador de Rede NVIDIA SR-IOV.	Opcional	`false`
`sriov-network-operator.operator.resourcePrefix`	sriov-network-operator.operator.resourcePrefix	Prefixo de recurso para recursos criados pelo Operador de Rede SR-IOV.	Opcional	`nvidia.com`
`sriov-network-operator.operator.admissionControllers.enabled`	sriov-network-operator.operator.admissionControllers.ativado	Ative controladores de admissão para o Operador de Rede SR-IOV.	Opcional	`false`
`sriov-network-operator.operator.sriovOperatorConfig.configDaemonNodeSelectors`	sriov-network-operator.operator.sriovOperatorConfig.configDaemonNodeSelectors	Configure `configDaemonNodeSelector` para `sriovOperatorConfig`.	Opcional	`{"beta.kubernetes.io/os": "linux", "network.nvidia.com/operator.mofed.wait": "false"}`
`vfCreationMode`	vfModeCriação	Modo para criação de VF. Os valores válidos são `sriovNetworkOperator` e `custom`.	Opcional	`custom`
`customizeVfCreationConfigMap`	customVfCreationConfigMap	Especifique se deseja ignorar a criação do ConfigMap `vf-shape-config`.	Opcional	`false`
`skipNodeFeatureDiscoveryDependencyCheck`	skipNFDDependencyCheck	Ignore a verificação de dependência de Descoberta de Recurso de Nó.	Opcional	`false`

Considerações sobre Clusters Grandes

A tabela a seguir descreve considerações para configurar este complemento de cluster em clusters grandes.


Nome do Argumento	Número wrt de Atribuições dos Nós	Descrição	À medida que o tamanho do cluster aumenta	Riscos	Recomendação
`operator.nodeSelectors`	S	Controla onde os pods do Operador de Rede NVIDIA estão programados.	Mantém o operador em nós estáveis de infraestrutura ou de plano de controle. Impede que o operador concorra com cargas de trabalho em nós de trabalho ocupados. Ajuda a manter o loop de controle de rede previsível quando o cluster tem muitos nós e alterações frequentes no estado do nó.	Se este argumento estiver configurado incorretamente: O operador pode ser executado em nós de trabalho sobrecarregados. O pod do operador poderá permanecer no estado `Pending` se o seletor for muito restritivo ou incorreto. A reconciliação relacionada à rede pode se tornar lenta ou inconsistente se o operador for instável.	Programe o operador em nós de infraestrutura dedicados. Use um seletor simples e confiável. Mantenha o operador longe dos pools de colaboradores com alterações frequentes na carga de trabalho.
`operator.tolerations`	S	Controla tolerâncias para os pods de Operador de Rede NVIDIA e DaemonSets relacionados.	Permite que o operador e seus DaemonSets sejam executados em nós de infraestrutura contaminados. Impede falhas de posicionamento no plano de controle ou nos nós de rede dedicados. Suporta isolamento quando GPU ou nós de rede estão contaminados.	Se este argumento estiver configurado incorretamente: O operador ou seus DaemonSets podem permanecer no estado `Pending` em nós contaminados. Os componentes SR-IOV, driver ou CNI podem não ser executados nos nós necessários. Alguns nós podem nunca receber os recursos de rede necessários.	Corresponder tolerâncias às manchas usadas nos pools de nós. Use tolerâncias consistentes em DaemonSets gerenciados pelo operador. Teste novamente a configuração após alterar as políticas de manutenção de nó.
`operator.affinity`	S	Controla as regras de afinidade do nó para os pods do Operador de Rede NVIDIA.	Mantém o operador na classe apropriada de nós. Reduz a probabilidade de o operador ser afetado pela rotatividade de nó de trabalho. Permite que o operador execute uma infraestrutura de rede próxima à estável.	Se este argumento estiver configurado incorretamente: O operador pode ser programado em nós inapropriados. Se a regra for muito restritiva, o operador poderá permanecer no estado `Pending` . Se a regra for muito ampla, o posicionamento pode não fornecer a resiliência pretendida.	Use regras de afinidade para preferir nós estáveis. Mantenha as regras simples, a menos que sejam necessárias restrições de várias zonas ou vários pools. Combine regras de afinidade com tolerâncias quando necessário.
`operator.resources`	S	Define solicitações e limites de CPU e memória para o contêiner do Operador de Rede NVIDIA.	O operador coordena recursos de rede no cluster. À medida que o número de nós aumenta, ele deve processar mais objetos, alterações de estado de nó e operações de reconciliação. O operador também conta com labels de Descoberta de Recurso de Nó para determinar quais nós exigem componentes de rede.	Se os recursos forem subdimensionados: A reconciliação pode ser lenta. Os rollouts de software de rede podem estar atrasados. O operador pode se tornar instável durante alterações frequentes de nó ou atualizações de configuração.	Aumente os recursos de CPU e memória para clusters com alterações frequentes de nós ou muitos recursos personalizados de rede. Monitore o uso da CPU do operador, o uso da memória e a latência de reconciliação. Trate esse argumento como uma configuração de dimensionamento do plano de controle.
`operator.cniBinDirectory`	N	Controla o diretório nos nós onde os binários CNI são implantados.	Os binários CNI devem ser implantados no diretório usado pelo runtime do contêiner. Um caminho incorreto pode afetar muitos nós ao mesmo tempo.	Se este argumento estiver configurado incorretamente: Pods podem ser criados, mas a rede pode não estar disponível. Binários CNI podem ser implantados no caminho de host errado. O cluster pode aparecer configurado mesmo que a rede não esteja funcionando.	Mantenha o valor alinhado com o padrão de runtime do nó. Altere o valor somente quando o tempo de execução do contêiner usar um diretório binário CNI diferente. Valide o caminho em um único pool de nós antes de aplicá-lo amplamente.
`operator.cniNetworkDirectory`	N	Controla o diretório de host onde os arquivos de configuração CNI são implantados.	Os arquivos de configuração CNI devem ser colocados no diretório lido pelo runtime do kubelet ou contêiner. Um diretório incorreto pode afetar todos os nós que usam a configuração.	Se este argumento estiver configurado incorretamente: Os arquivos de configuração CNI podem ser implantados em um diretório que o runtime do kubelet ou do contêiner não lê. Os nós podem aparecer configurados mesmo que a rede secundária não funcione. A solução de problemas pode ser difícil porque o operador pode parecer íntegro, apesar da incompatibilidade de caminho.	Alinhe o valor com o diretório de configuração CNI usado pelo runtime do nó. Trate o argumento como uma definição de host-runtime em vez de uma definição de política de cluster. Valide o posicionamento do arquivo em uma única GPU ou nó de rede antes de aplicá-lo amplamente.
`operator.admissionControllers.enabled`	N	Controla se o Operador de Rede NVIDIA implanta seu controlador de admissão.	O controlador de admissão ajuda a impedir a entrada de configuração inválida no cluster. Isso se torna mais importante quando muitos usuários ou sistemas de automação criam recursos personalizados de rede.	Se o controlador de admissão estiver desativado: Configuração SR-IOV, network-policy ou NIC inválida pode ser aceita. Configurações inválidas podem ser aplicadas a muitos nós antes que o problema seja detectado. O risco operacional aumenta em grandes clusters.	Ative o controlador de admissão em ambientes de produção. Certifique-se de que o Gerenciador de Certificados permaneça íntegro se o webhook usar certificados gerados.
`sriovNetworkOperator.enabled`	N	Controla se o Operador de Rede SR-IOV está implantado.	O Operador de Rede SR-IOV fornece os componentes SR-IOV necessários para a rede de alto desempenho baseada em função virtual, incluindo algumas configurações RDMA e GPUDirect RDMA.	Se o Operador de Rede SR-IOV estiver desativado quando necessário: Os recursos SR-IOV não estão implantados. Os nós podem não fornecer os recursos de rede exigidos pelas cargas de trabalho. Os caminhos de rede de GPU e RDMA podem permanecer incompletos.	Ative o Operador de Rede SR-IOV somente quando o cluster exigir SR-IOV. Deixe-o desativado em clusters que não usam rede baseada em função virtual. Quando ativado, trate-o como um componente básico de rede.
`sriov-network-operator.operator.resourcePrefix`	N	Define o prefixo usado para recursos criados pelo Operador de Rede SR-IOV.	O prefixo determina os nomes de recursos estendidos que o Kubernetes e as cargas de trabalho usam. A alteração do prefixo requer que todos os manifestos da carga de trabalho usem os novos nomes de recursos.	Se este argumento estiver configurado incorretamente: As cargas de trabalho podem solicitar um nome de recurso estendido incorreto. Os pods podem permanecer no estado `Pending` porque o scheduler não pode corresponder ao recurso solicitado. As convenções antigas e novas de nomeação de recursos podem ser usadas inconsistentemente.	Mantenha o valor padrão, a menos que uma política de nomeação alternativa seja necessária. Não altere o prefixo casualmente em um cluster em execução. Certifique-se de que os manifestos da carga de trabalho usem o mesmo prefixo.
`sriov-network-operator.operator.admissionControllers.enabled`	S	Controla os controladores de admissão do Operador de Rede SR-IOV.	Os controladores de admissão detectam a configuração SR-IOV inválida antes de atingir os nós e ajudam a manter as configurações de função virtual e NIC consistentes à medida que o número de grupos de nós e políticas aumenta.	Se os controladores de admissão estiverem desativados: Configuração SR-IOV inválida pode ser aplicada. A configuração incorreta pode se espalhar por muitos nós. A recuperação de erros de configuração pode ser mais difícil.	Ative os controladores de admissão em ambientes de produção. Certifique-se de que o gerenciador de certificados e o tratamento de certificados do webhook permaneçam íntegros. Desative os controladores de internação somente quando houver um motivo específico para evitar webhooks de internação.
`sriov-network-operator.operator.sriovOperatorConfig.configDaemonNodeSelectors`	S	Seleciona os nós que o daemon de configuração SR-IOV configura.	O seletor determina quais nós recebem a configuração SR-IOV. Em um cluster grande, um seletor incorreto pode afetar centenas ou milhares de nós.	Se este argumento estiver configurado incorretamente: A configuração SR-IOV pode ser aplicada aos nós errados. Os nós pretendidos podem não receber a configuração. Os recursos de rede podem se tornar inconsistentes entre os pools de nós.	Alinhe o seletor com os labels de nó produzidos pela Descoberta de Recursos de Nó. Teste o seletor em um pequeno grupo de nós antes de aplicá-lo amplamente.
`vfCreationMode`	N	Determina se a criação da função virtual é gerenciada automaticamente pelo operador ou pela lógica personalizada.	Um processo de criação de função virtual automatizado e consistente reduz as diferenças de configuração entre os nós. A lógica de criação personalizada fornece mais flexibilidade, mas aumenta a probabilidade de configuração de nó inconsistente.	Se este argumento estiver configurado incorretamente: Não é possível criar funções virtuais nos nós esperados. Os pools de nós podem se comportar de maneira diferente. A configuração de rede pode variar com o tempo.	Use a criação de função virtual gerenciada pelo operador, a menos que a lógica personalizada seja necessária. Evite misturar modos de criação dentro do mesmo domínio operacional. Valide a criação de função virtual em um único pool de nós antes de aplicá-la amplamente.
`skipNodeFeatureDiscoveryDependencyCheck`	S	Determina se o operador ignora a verificação de dependência de Descoberta de Recurso de Nó.	Ignorar a verificação evita a validação de dependência redundante quando a Descoberta de Recursos de Nó é gerenciada separadamente. No entanto, o administrador do cluster se torna responsável por garantir que os labels de nó necessários estejam disponíveis e permaneçam corretos.	Se este argumento estiver configurado incorretamente: O operador pode depender da Descoberta de Recursos de Nó mesmo que não esteja instalado ou íntegro. Rótulos obrigatórios podem estar ausentes. Direcionamento de nó incorreto para SR-IOV e componentes relacionados pode afetar muitos nós.	Ignore a verificação de dependência somente quando a Descoberta de Recursos de Nó já estiver implantada e verificada. Confirme se os labels necessários existem nos nós pretendidos antes de ativar o Operador de Rede NVIDIA.