expose helm value to disable locality-init init-container

[mila-rodriguez-netapp]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Overview of the Issue

I run Vault in HA mode and use Consul for a storage backend. I do not use the service mesh and have no plans to.

Starting with chart v1.2.0, there is now an initContainer called "locality-init" which does not appear to be configurable and which requires the consul-k8s-control-plane image:

      initContainers:
      - name: locality-init
        image: {{ .Values.global.imageK8S }}
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        command:
          - "/bin/sh"
          - "-ec"
          - |
            consul-k8s-control-plane fetch-server-region -node-name "$NODE_NAME" -output-file /consul/extra-config/locality.json
        volumeMounts:
          - name: extra-config
            mountPath: /consul/extra-config

I should be able to disable this init container if I don't use the Consul service mesh.

The initContainer was added in this PR: https://github.com/hashicorp/consul-k8s/pull/2093

Reproduction Steps

Deploy chart v1.2.0. We're deploying Consul server as a stateful set to back Vault, nothing more.

Extract from my values.yaml including all of the enabled toggles.

global:
  enabled: false

  peering:
    enabled: false
  federation:
    enabled: false
  cloud: 
    enabled: false
  metrics:
    enabled: false

server:
   enabled: true

client:
  enabled: true 

connectInject:
  enabled: false

dns:
  enabled: false

externalServers:
  enabled: false

ui:
  enabled: false

syncCatalog:
  enabled: false

ingress:
  enabled: false

meshGateway:
  enabled: false

ingressGateways:
  enabled: false

terminatingGateways:
  enabled: false

apiGateway:
  enabled: false

prometheus:
  enabled: false

tests:
  enabled: false

telemetryCollector:
  enabled: false

Expected behavior

Since the Consul service mesh is not being used, the initContainer should not be created.

Environment details

Target k8s infrastructure doesn't matter since this initContainer isn't guarded by a helm {{- if ... }} directive.

Additional Context

We don't vet the Consul control plane image, so it's not available in our company's private docker mirror. As a result, the initContainer can't pull its image, and Consul won't start. Since we don't need this functionality anyway, as it's mesh-related (or possibly peering-related), we shouldn't be required to use this image.

[david-yu]

Thanks for reporting this issue, we'll look to address for the next set of patch releases for 1.2.x in a month or so.

[david-yu]

Based on initial review with Eng we do want to enable this by default, so we discussed an option here to disable locality here when server.enabled is set to true. This is applicable also to service discovery only workflows and not service mesh specific.

[mila-rodriguez-netapp]

This is applicable also to service discovery only workflows and not service mesh specific.

If it's not mesh-specific, why is the code/command in the control-plane image? Isn't that one of the service-mesh images?

[david-yu]

Our control plane also does syncing with the Consul catalog from K8s as well as shown here: https://github.com/hashicorp/consul-k8s/tree/main/control-plane/catalog. It is used mostly for mesh but we also use it for service discovery only purposes.