[Enhancement]: Support HostPath as a Volume for KafkaConnect

[lujiajing1126]

Related problem

In the current AdditionalVolume implementation, only Secret, ConfigMap, EmptyDir and PVC are supported. In some cases, for example, spiffe (https://spiffe.io/) needs UDS for communication between DaemonSet pod and application pod, e.g. KafkaConnect pod.

Suggested solution

Add HostPath support to the AdditionalVolume and related utils.

Alternatives

No response

Additional context

No response

[scholzj]

Can you elaborate more on the use case? How it will be used, what will it enable etc.? Also, do you understand that the hostpath will be the same in every single pod?

[scholzj]

Also, can't you already do it through PV and PVC? Create a hostPath PV, PVC to map to the PV and moount the PVC into the Pods? Or does this not work for some reason?

[lujiajing1126]

Can you elaborate more on the use case? How it will be used, what will it enable etc.?

We are using spire agent to generate attestable workload identities for security reasons. So in this case, as illustrated in the figure above, spire-agent is deployed as DaemonSet and exposes API via Unix Domain Socket.

For the Kafka Connect pod, we need UDS mounted from the host path. An example,

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ft-connect-cluster-connect
  namespace: strimzi
spec:
  template:
    spec:
      containers:
        - volumeMounts:
            - mountPath: /run/spire/sockets
              name: ext-conf-spire-volume
      volumes:
        - hostPath:
            path: /run/spire/sockets
            type: ''
          name: ext-conf-spire-volume

Also, do you understand that the hostpath will be the same in every single pod?

Sure. In the case described above, all pods on the same node will call the same UDS deployed on this given node.

[scholzj]

The diagram shows Envoy running in the Pod and consuming it. So how will you get it there? We do not support that. Also, what about using the host path through the PV?

[ppatierno]

Triaged on 17/10/2024: @lujiajing1126 we would like to understand the use case better, if you are facing any additional issues, limitations and why the Jakub's suggestion would not work in your case.