Helm Chart中多Ingress配置的实现方案问询

核心思路：结构化配置+条件遍历 #

别用正则匹配这种绕弯子的方式，直接把Ingress配置做成结构化列表或者键值对集合，既清晰又符合Helm的模板语法习惯，还能轻松处理空值场景。

1. 优化values.yaml结构 #

把每个应用的Ingress配置单独归类，用apps[app.refName].ingresses存储该应用的所有Ingress规则，每个Ingress条目包含必要字段（name、annotations、hosts、tls等）：

# values.yaml
app:
  refName: "app1"

apps:
  app1:
    ingresses:
      - name: "ingress-internal"
        annotations:
          nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/16"
        hosts:
          - host: "internal-app1.example.com"
            paths:
              - path: "/"
                pathType: Prefix
        tls: false
      - name: "ingress-public"
        annotations:
          cert-manager.io/cluster-issuer: "letsencrypt-prod"
        hosts:
          - host: "app1.example.com"
            paths:
              - path: "/"
                pathType: Prefix
        tls: true
  app2:
    ingresses: [] # 无Ingress的应用直接设为空数组

2. 模板文件中遍历生成Ingress Manifest #

在templates/ingress.yaml里，用Helm的range循环结合条件判断，只处理当前指定应用的Ingress条目，空数组时自动跳过：

{{- $currentApp := index .Values.apps .Values.app.refName -}}
{{- if $currentApp.ingresses }}
{{- range $ingress := $currentApp.ingresses }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ $.Release.Name }}-{{ $ingress.name }}
  annotations:
    {{- toYaml $ingress.annotations | nindent 4 }}
spec:
  {{- if $ingress.tls }}
  tls:
    - hosts:
        {{- range $ingress.hosts }}
        - {{ .host }}
        {{- end }}
      secretName: {{ $.Release.Name }}-{{ $ingress.name }}-tls
  {{- end }}
  rules:
    {{- range $ingress.hosts }}
    - host: {{ .host }}
      http:
        paths:
          {{- range .paths }}
          - path: {{ .path }}
            pathType: {{ .pathType }}
            backend:
              service:
                name: {{ $.Release.Name }}-service
                port:
                  number: 80
          {{- end }}
    {{- end }}
---
{{- end }}
{{- end }}

3. 关键优势说明 #

• 可读性强：结构化配置比零散的ingress-*键值对更直观，团队维护成本低
• 兼容空场景：如果当前应用的ingresses是空数组，模板会直接跳过生成Ingress资源，无需额外处理
• 扩展性高：后续要加Ingress的其他字段（比如ingressClassName），直接在values里补充即可，模板无需大改
• 避免正则陷阱：regexMatch在处理复杂键名时容易出错，结构化配置完全规避这类问题

备用方案：保留原有键值对结构（如果无法修改values） #

如果因为团队限制不能改现有values结构，可用range $key, $val := .Values.apps.app1结合hasPrefix筛选ingress-开头的键：

{{- $currentApp := index .Values.apps .Values.app.refName -}}
{{- range $key, $val := $currentApp }}
{{- if hasPrefix "ingress-" $key }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ $.Release.Name }}-{{ $key }}
  annotations:
    {{- toYaml $val.annotations | nindent 4 }}
spec:
  # 这里根据$val的结构填充对应的hosts、tls等字段，逻辑同结构化方案
---
{{- end }}
{{- end }}

这种方案虽能实现需求，但不如结构化配置清晰，后续维护难度更大，优先推荐第一种方案。

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