[Enhancement] Shared Volume Mount Changes

[rao2100]

Type of change

• Enhancement

Description

This PR introduces enhancements to the Strimzi Kafka Operator for managing shared volume mounts, improving task resiliency across nodes. Key changes include:

1. mountPath: A string property to specify the container directory for mounting the storage volume. While the default is /var/lib/kafka/data, this allows for custom path specification. By default, it will try to mount read write many storage if accessMode is not specified.

2. accessMode: An optional string property defining the storage access mode, determining permissions like read-only or read-write.

These changes, tested successfully with Read-Write-Many on Ceph-block storage and NFS, provide greater control over volume configuration and usage, improving operator performance in distributed environments.

Sample Test

• This test case is to test the strimzi operator customization that allows mounting of shared volume across kafka-connect pods
• Ensure that files created in shared volume in one pod are visible to the other pods

kafkaConnect.yaml

    storage:
      type: persistent-claim
      size: 1Gi
      class: rook-cephfs
      deleteClaim: false
      mountPath: /mnt/shared
    template:
      pod:
        securityContext:
          runAsNonRoot: false
          fsGroup: 1001

Outcome

• After deploying all the necessary charts and kafka-connect with the above yaml, ensure only one pvc data-odf-connect-cluster-connect is created, mounted and shared by all the connect pods

    $ kubectl get pvc
    NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    data-odf-cluster-kafka-0           Bound    pvc-7a09ed64-2216-48fa-b040-65ecec708472   2Gi        RWO            local-path     143m
    data-odf-cluster-kafka-1           Bound    pvc-4385d70e-da6a-4ed5-b52b-527ae2ea4feb   2Gi        RWO            local-path     143m
    data-odf-cluster-kafka-2           Bound    pvc-5b6cc835-529a-4265-9a42-b46403fbe795   2Gi        RWO            local-path     143m
    data-odf-cluster-zookeeper-0       Bound    pvc-5f505af1-077b-438b-a9fb-3974a7dae9d7   2Gi        RWO            local-path     143m
    data-odf-cluster-zookeeper-1       Bound    pvc-5177af7e-6cc9-4993-bcad-42ce5a422fdc   2Gi        RWO            local-path     143m
    data-odf-cluster-zookeeper-2       Bound    pvc-27e9587f-0ead-4e08-85a9-1177076be843   2Gi        RWO            local-path     143m
    data-odf-connect-cluster-connect   Bound    pvc-1f2eadb0-e2be-4277-9bb4-b2f5dfb8dcdf   3Gi        RWX            rook-cephfs    143m
    sftp-output-file-odf-sftp-0        Bound    pvc-c11a68fa-5865-4310-9194-624a3942b872   100Gi      RWO            rook-cephfs    20h

• Get a terminal to one of the kafka-connect pod and create a file at /mnt/shared as below

    $ kubectl exec -it odf-connect-cluster-connect-7fbd9589c-d4tx6 -- bash
        [kafka@odf-connect-cluster-connect-7fbd9589c-d4tx6 kafka]$ cd /mnt/shared/
        [kafka@odf-connect-cluster-connect-7fbd9589c-d4tx6 shared]$ ls -lah
        total 0
        drwxrwsr-x 2 root  1001  1 Aug 23 09:27 .
        drwxr-xr-x 1 root  root 20 Aug 23 09:22 ..
        -rw-r--r-- 1 kafka 1001  0 Aug 23 09:27 testFile

• Get a terminal to another one of the kafka-connect pod and ensure the created file is visible

    $ kubectl exec -it odf-connect-cluster-connect-7fbd9589c-d4tx6 -- bash
        [kafka@odf-connect-cluster-connect-7fbd9589c-d4tx6 kafka]$ cd /mnt/shared/
        [kafka@odf-connect-cluster-connect-7fbd9589c-d4tx6 shared]$ ls -lah
        total 0
        drwxrwsr-x 2 root  1001  1 Aug 23 09:27 .
        drwxr-xr-x 1 root  root 20 Aug 23 09:22 ..
        -rw-r--r-- 1 kafka 1001  0 Aug 23 09:27 testFile

[scholzj]

I'm sorry, but this should go through a proposal as described in #3693 ... so if ou want to contribute this, that is great, but it has to start by writing a proposal of how it will be done and how it will work: https://github.com/strimzi/proposals

Also, I doubt having a single volume configured like this will cover all use-cases. So you need to think it through properly. We would also definitely not support configurable mount paths etc. as that would collide with how the API is used for Kafka brokers.

You should also properly explain the use-case. I - at least personally - do not think using connectors relying on storage is the right use case for distributed connect. It much better fits standalone connect run for example as sidecar.