Como faço para que o `ctr image pull` sempre use um `--hosts-dir` personalizado sem especificá-lo na linha de comando?

Eu tenho um arquivo personalizado com /etc/containerd/certs.d/registry.at.my.company/hosts.tomlalgumas configurações definidas para um contêiner de registro local em execução em meus servidores. Isso está funcionando bem quando eu o configuro para um CRI para Kubernetes, mas eu e meus colegas achamos frustrante termos que adicionar --hosts-dir /etc/containerd/certs.dtodos os nossos ctr image pullcomandos ao executar ctrmanualmente (fora das coisas do K8). foi muito fácil: apenas definimos a opção correta no arquivo de configuração JSON do daemon do docker ( "insecure-registry": "127.0.0.1") e funcionou bem. Mas estou tendo problemas para encontrar uma configuração equivalente para ctrse comportar de maneira semelhante. Claro, o plugin CRI está usando ohosts.tomlarquivo que configurei perfeitamente, mas gostaria de poder extrair imagens manualmente sem precisar adicionar um sinalizador extra ao comando. Existe uma maneira de configurar o containerd para que ctr image pullnão precise --hosts-dirser passado todas as vezes?

Esta é a hosts.tomlaparência desse arquivo:

server = "http://registry.at.my.company"

[host."http://registry.at.my.company"]
  skip_verify = true
  plain-http = true

E no /etc/containerd/config.tomlarquivo, tenho o CRI apontando para ele assim:

[plugins."io.containerd.grpc.v1.cri".registry]
config_path = "/etc/containerd/certs.d"

Mas, como supus e disse acima, isso parece afetar apenas a forma como o kubelet interage com o containerd, e não como ctro faz.

Algum contexto de fundo:

Temos esse registro local em execução com uma /etc/hostsentrada como esta: 127.0.1.1 registry.at.my.company. Junto com algumas regras de firewall, isso faz com que todos que usam nossos clusters Kubernetes tenham que enviar suas imagens registry.at.my.companye configurar seus pods para usar imagens de lá, porque nossos kubelets não serão capazes de extrair de qualquer lugar além desse domínio; e para fazer com que nosso registro não seja um SPoF, executamos esses contêineres de registro locais como espelhos somente leitura (e o próprio servidor do contêiner de registro aceita apenas conexões locais, evitando que a falta de certificados SSL seja um problema). não tenho certeza se isso é relevante para o meu problema, mas deve ajudar a explicar por que eu estava falando sobre a insecure-registryopção antiga no docker e por que eu hosts.tomluso httpem vez dehttps, para que não preocupe ninguém.

Além disso, esta é a versão 1.6.19 do containerd com a qual estou trabalhando.