Helm子Chart引用库模板遇值为空错误，求可行实现方案

Let's work through your issue and answer your questions clearly:

First: Fixing the nil pointer evaluating interface {}.name Error #

The root of this error is that when your library chart's template tries to access .Values.application.name, that value isn't present in the context being passed to the template. Here's how to diagnose and fix it:

1. Verify Your Sub-Chart's Values Are Accessible #

First, confirm the sub-chart can actually see its own application.name value. Add a debug check at the top of your sub-chart's service.yaml:

{{- /* Debug: Validate the value exists before calling the library template */ -}}
{{- if not .Values.application.name }}
  {{- fail "FATAL: .Values.application.name is missing from the sub-chart's values" }}
{{- end }}

{{- include "app.connect.common.release.common_libs.servicetemplate" . }}

Run your helm install --dry-run command again. If the fail triggers:

• Double-check your sub-chart's values.yaml is in the correct location (root of the sub-chart directory)
• Ensure your parent chart isn't overriding the sub-chart's application values (check parent values.yaml or Chart.yaml dependency values fields for accidental resets like app.connect.common.release.chtmgr: application: {})

2. Explicitly Pass Parameters to the Library Template (Recommended) #

Instead of relying on implicit value paths in the context, rewrite your library template to accept explicit parameters. This avoids confusion about where values are coming from:

Update the Library Template (_helpers.tpl)

{{- define "app.connect.common.release.common_libs.servicetemplate" -}}
{{- /* Accept parameters passed as a dictionary */ -}}
{{- $appName := .appName -}}
{{- $namespace := .namespace -}}
apiVersion: v1
kind: Service
metadata:
  labels:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
  name: {{ $appName }}-service
  namespace: {{ $namespace }}
spec:
  type: LoadBalancer
  ports:
    - name: https
      port: 443
      targetPort: 8080
    - name: http
      port: 80
      targetPort: 8080
  selector:
    app: {{ $appName }}
status:
  loadBalancer: {}
{{- end }}

Call the Template from Your Sub-Chart

Pass the values directly as a dictionary:

{{- include "app.connect.common.release.common_libs.servicetemplate" (dict 
  "appName" .Values.application.name 
  "namespace" .Values.global.environment.namespace
) }}

3. Use import-values to Sync Sub-Chart Values to the Library #

If you prefer to keep using .Values in the library template, add import-values to your sub-chart's Chart.yaml dependency definition. This syncs specific values from the sub-chart to the library chart's context:

dependencies:
  - name: app.connect.common.release.common_libs
    version: x.x.x
    repository: file://../app.connect.common.release.common_libs
    import-values:
      - parent: application
        child: application
      - parent: global.environment
        child: global.environment

Can You Store Sub-Chart Common Values in a Parent Template? #

Technically yes, but it's not recommended—it creates tight coupling between your parent and sub-charts, making sub-charts harder to reuse independently.

If you still want to try it:

• Define a global template in your parent chart's _helpers.tpl (prefix the template name with global. to make it accessible across charts):

  {{- define "global.subchart.commonValues" -}}
  application:
    name: {{ .Values.application.name }}
    defaultPort: 8080
  {{- end }}
  

• Reference it in your sub-chart:

  {{- include "global.subchart.commonValues" . | fromYaml }}
  

Again, this is not ideal—stick with library charts for shared logic to maintain loose coupling.

内容的提问来源于stack exchange，提问作者DavidGreen55