Visão geral dos requisitos do Helm

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

Considerações sobre registryUrl e imagePullSecrets

Cada gráfico do 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 do editor expor esses valores de maneira estrita, para que pudessem ser substituídos pelos valores adequados do Azure durante a implantação. Com o tempo, nem todos os editores poderiam cumprir facilmente o tratamento estrito desses valores exigidos pelo AOSM.

• Alguns gráficos ocultam registryUrl e/ou imagePullSecrets por trás de condições 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 requisitos de conformidade rigorosos para editores, o AOSM introduziu posteriormente dois métodos aprimorados de tratamento desses valores. Primeiro injectArtifactStoreDetail e, por fim, o Registro de Cluster. Esses dois métodos mais recentes não dependem de registryUrl ou imagePullSecrets válido que aparecem no pacote do Helm. Em vez disso, esses métodos injetam esses valores diretamente em operações do pod em nome da função de rede.

Resumo do método para registryUrl e imagePullSecrets

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

Herdada.

• Editor necessário para parametrizar registryUrl e imagePullSecrets em conformidade em valores do Helm e modelos de implantação para substituição.
• Imagens são hospedadas no ACR (Registro de Contêiner do Azure) do editor.

InjectArtifactStoreDetail.

• Usa um webhook para injetar registryUrl e imagePullSecrets diretamente em operações do pod, com dependências mínimas no Helm.
• Imagens ainda são hospedadas no ACR do editor.

Registro do cluster.

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

Requisitos herdados para registryUrl e imagePullSecrets

O AOSM (Gerenciador de Serviço do Operador do Microsoft Azure) usa o serviço NFM (Gerenciador de Funções de Rede) para implantar as CNFs (Funções de Rede em Contêineres). Com o método herdado, o NFM substitui os valores registryUrl e imagePullSecrets de contêiner do AOSM na operação do Helm durante a implantação da NF (Função de Rede).

Usar o método herdado

O modelo de implantação do Helm a seguir mostra um exemplo de como um editor deve expor o 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 values.schema.json a seguir mostra um exemplo de como um editor pode definir facilmente os requisitos de 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 Herdado

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

• Evitar referências ao registro externo
• Realizar validações manuais
• Garantir marcas e repositório de imagens estáticas

Evitar referências ao registro externo

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

Realizar validações manuais

Examine as imagens e as especificações de contêiner criadas para garantir que as imagens tenham o prefixo de registryURL e que os imagePullSecrets sejam preenchidos com secretName.

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

OR

 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 marcas e repositório de imagens estáticas

Cada gráfico do Helm deve conter o repositório de imagens estáticas e marcas. Os valores estáticos são definidos da seguinte maneira:

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

Uma NFDV (Versão de Design de Função de Rede) deve ser mapeada para um conjunto estático de gráficos e imagens do Helm. Os gráficos e as imagens são atualizados apenas publicando uma nova NFDV (Versão de Design de Função de Rede).

 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}}

Requisitos de injectArtifactStoreDetails para registryUrl e imagePullSecrets

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

Usar o método injectArtifactStoreDetails

Para habilitar injectArtifactStoreDetails, defina o parâmetro installOptions na seção roleOverrides do recurso de NF 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 de registro de cluster para registryUrl e imagePullSecrets

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

Restrições de imutabilidade do gráfico

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 marcas mutáveis, como mais recente, desenvolvimento ou estável. Por exemplo, se deployment.yaml usou 'latest' para o . Values.image.tag a implantação falhará.

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

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

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