Visão geral dos requisitos do leme

O Helm é um gerenciador de pacotes para o Kubernetes que ajuda a simplificar o gerenciamento do ciclo de vida do aplicativo. Os pacotes Helm são chamados de gráficos e consistem em arquivos de configuração e modelo YAML. Após a execução de uma operação Helm, os gráficos são renderizados em arquivos de manifesto do Kubernetes para acionar a ação apropriada do ciclo de vida do aplicativo. Para uma integração mais eficiente com o Azure Operator Service Manager (AOSM), os editores devem considerar certas considerações de práticas recomendadas ao desenvolver gráficos Helm.

Considerações para registryUrl e imagePullSecrets

Cada gráfico Helm geralmente requer um registryUrl e imagePullSecrets. Mais comumente, um editor expõe esses parâmetros em values.yaml. No início, o AOSM dependia de o editor expor esses valores de maneira estrita, para que eles pudessem ser substituídos pelos valores adequados do Azure durante a implantação. Ao longo do tempo, nem todos os editores poderiam facilmente cumprir com o tratamento rigoroso desses valores exigidos pelo AOSM.

• Alguns gráficos ocultam registryUrl e/ou imagePullSecrets atrás de condicionais ou outras restrições de valores, que nem sempre foram atendidas.
• Alguns gráficos não declaram registryUrl e/ou imagePullSecrets como a cadeia de caracteres nomeada esperada, em vez disso, como uma matriz.

Para reduzir os rigorosos requisitos de conformidade dos editores, o AOSM introduziu mais tarde dois métodos aprimorados de lidar com esses valores. Primeiro injectArtifactStoreDetail e, finalmente, Cluster Registry. Esses dois métodos mais recentes não dependem de registryUrl ou imagePullSecrets válidos que aparecem no pacote Helm. Em vez disso, esses métodos injetam esses valores diretamente em operações de pod, em nome da função de rede.

Resumo do método para registryUrl e imagePullSecrets

Todos os três métodos são suportados e descritos neste artigo. Um editor deve escolher a melhor opção para sua função de rede e caso de uso.

Legado.

• Requer que o editor parametrize em conformidade registryUrl & imagePullSecrets em valores de leme e modelos de implantação para substituição.
• As imagens são hospedadas no Azure Container Registry (ACR) do editor.

InjectArtifactStoreDetail.

• Usa um webhook para injetar registryUrl & imagePullSecrets diretamente em operações de pod, com dependências mínimas no leme.
• As imagens ainda estão hospedadas no ACR da editora.

Registro de cluster.

• Usa um webhook para injetar registryUrl & imagePullSecrets diretamente em operações de pod, sem dependência de helm.
• As imagens são hospedadas no registro de cluster de extensão NFO local.

Requisitos herdados para registryUrl e imagePullSecrets

O Azure Operator Service Manager (AOSM) usa o serviço Network Function Manager (NFM) para implantar CNFs (Containerized Network Functions). Com o método herdado, o NFM substitui os valores registryUrl e imagePullSecrets do contêiner AOSM na operação de leme durante a implantação da Função de Rede (NF).

Usando o método herdado

O modelo de implantação de leme a seguir mostra um exemplo de como um editor deve expor registryPath e imagePullSecrets para compatibilidade com a abordagem herdada do AOSM.

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: nginx-deployment 
  labels: 
    app: nginx 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      app: nginx 
  template: 
    metadata: 
      labels: 
        app: nginx 
    spec: 
      {{- if .Values.global.imagePullSecrets }} 
      imagePullSecrets: {{ toYaml .Values.global.imagePullSecrets | nindent 8 }} 
      {{- end }} 
      containers: 
      - name: contosoapp 
        image:{{ .Values.global.registryPath }}/contosoapp:1.14.2 
        ports: 
        - containerPort: 80 

O arquivo a seguir values.schema.json mostra um exemplo de como um editor pode facilmente definir os requisitos registryPath e imagePullSecretsvalue para compatibilidade com a abordagem herdada do AOSM.

{ 
  "$schema": "http://json-schema.org/draft-07/schema#", 
  "title": "StarterSchema", 
  "type": "object", 
  "required": ["global"], 
  "properties": { 
      "global" : {
          "type": "object",
          "properties": {
              “registryPath”: {“type”: “string”}, 
              “imagePullSecrets”: {“type”: “string”}, 
          }
          "required": [ "registryPath", "imagePullSecrets" ], 
      } 
   } 
} 

A seguir NFDVersion request payload mostra um exemplo de como um editor pode fornecer os valores registryPath e imagePullSecretsvalue para compatibilidade com a abordagem herdada do AOSM.

"registryValuesPaths": [ "global.registryPath" ], 
"imagePullSecretsValuesPaths": [ "global.imagePullSecrets" ], 

A seguir values.yaml mostra um exemplo de como um editor pode fornecer os valores registryPath e imagePullSecretsvalue para compatibilidade com a abordagem herdada do AOSM.

global: 
   imagePullSecrets: [] 
   registryPath: “” 

Outras considerações com o método Legacy

O Publisher deve considerar adicionalmente as seguintes recomendações ao usar o método herdado:

• Evitar referências ao registo externo
• Validações manuais Performa
• Garantir repositório de imagens estáticas e tags

Evitar referências ao registo externo

Os usuários devem evitar usar referências a um registro externo. Por exemplo, se deployment.yaml usar um caminho de registro codificado ou referências de registro externas, ele falhará na validação.

Executar validações manuais

Revise as imagens e as especificações de contêiner criadas para garantir que as imagens tenham prefixo de registryURL e que imagePullSecrets sejam preenchidas com secretName.

 helm template --set "global.imagePullSecrets[0].name=<secretName>" --set "global.registry.url=<registryURL>" <release-name> <chart-name> --dry-run

OU

 helm install --set "global.imagePullSecrets[0].name=<secretName>" --set "global.registry.url=<registryURL>" <release-name> <chart-name> --dry-run
 kubectl create secret <secretName> regcred --docker-server=<registryURL> --dockerusername=<regusername> --docker-password=<regpassword>

Garantir repositório de imagens estáticas e tags

Cada gráfico de leme deve conter imagens estáticas, repositório e tags. Os valores estáticos são definidos da seguinte forma:

• Definindo-os na linha da imagem ou,
• Defini-los em values.yaml e não expor esses valores na Versão de Design de Função de Rede (NFDV).

Uma Versão de Design de Função de Rede (NFDV) deve ser mapeada para um conjunto estático de gráficos e imagens de leme. Os gráficos e imagens só são atualizados através da publicação de uma nova versão de design de função de rede (NFDV).

 image: "{{ .Values.global.registryPath }}/contosoapp:1.14.2“

Ou

 image: "{{ .Values.global.registryPath }}/{{ .Values.image.repository }}:{{ .Values.image.tag}}“
 
YAML values.yaml
image:
  repository: contosoapp
  tag: 1.14.2

 image: http://myURL/{{ .Values.image.repository }}:{{ .Values.image.tag}}

injectArtifactStoreDetails requisitos para registryUrl e imagePullSecrets

Em alguns casos, gráficos de leme de terceiros podem não ser totalmente compatíveis com os requisitos do AOSM para registryURL. Nesse caso, o recurso injectArtifactStoreDetails pode ser usado para evitar fazer alterações de conformidade em pacotes de leme. Com injectArtifactStoreDetails habilitado, um método webhook é usado para injetar o registryUrl e imagePullSecrets adequados dinamicamente durante as operações do pod. Isso substitui os valores configurados no pacote de leme.

Usando o método injectArtifactStoreDetails

Para habilitar injectArtifactStoreDetails, defina o parâmetro installOptions na seção NF resource roleOverrides como true, conforme mostrado no exemplo a seguir.

resource networkFunction 'Microsoft.HybridNetwork/networkFunctions@2023-09-01' = {
  name: nfName
  location: location
  properties: {
    nfviType: 'AzureArcKubernetes'
    networkFunctionDefinitionVersionResourceReference: {
      id: nfdvId
      idType: 'Open'
    }
    allowSoftwareUpdate: true
    nfviId: nfviId
    deploymentValues: deploymentValues
    configurationType: 'Open'
    roleOverrideValues: [
      // Use inject artifact store details feature on test app 1
      '{"name":"testapp1", "deployParametersMappingRuleProfile":{"helmMappingRuleProfile":{"options":{"installOptions":{"atomic":"false","wait":"false","timeout":"60","injectArtifactStoreDetails":"true"},"upgradeOptions": {"atomic": "false", "wait": "true", "timeout": "100", "injectArtifactStoreDetails": "true"}}}}}'
    ]
  }
}

Requisitos do Registro de cluster para registryUrl e imagePullSecrets

Para obter informações sobre como usar o registro de cluster, consulte a documentação de conceito.

Restrições de imutabilidade do gráfico

As restrições de imutabilidade impedem alterações em um arquivo ou diretório. Por exemplo, um arquivo imutável não pode ser alterado ou renomeado. Os usuários devem evitar o uso de tags mutáveis, como mais recente, dev ou estável. Por exemplo, se deployment.yaml usou 'mais recente' para o . Values.image.tag a implantação falharia.

 image: "{{ .Values.global.registryPath }}/{{ .Values.image.repository }}:{{ .Values.image.tag}}“

Declaração CRD do gráfico e divisão de uso

Recomendamos dividir a declaração e o uso das definições de recursos do cliente (CRD) em gráficos de leme separados para oferecer suporte a atualizações. Para obter informações detalhadas, consulte: method-2-separate-charts