IPV6 Only Access

[safaci2000]

I have looked over https://github.com/orgs/strimzi/discussions/7148 and tried to implement the suggested solution. I wanted to spawn a new thread to avoid hijacking the conversation.

My Operator is installed with the following configuration:

USER-SUPPLIED VALUES:
extraEnvs:
- name: KUBERNETES_DISABLE_HOSTNAME_VERIFICATION
  value: "true"
- name: KUBERNETES_MASTER
  value: https://34.46.76.68

I don't have a master node/ control plane V6 address, so I'm stuck with the V4 address shown above.

when I connect the cluster from a V6 only network, I get the following errors:

%3|1719444266.764|FAIL|rdkafka#consumer-1| [thrd:GroupCoordinator]: GroupCoordinator: 34.136.35.18:9094: Failed to connect to broker at 18.35.136.34.bc.googleusercontent.com:9094: Network is unreachable (after 3ms in state CONNECT)
% Error: Local: Broker transport failure: GroupCoordinator: 34.136.35.18:9094: Failed to connect to broker at 18.35.136.34.bc.googleusercontent.com:9094: Network is unreachable (after 3ms in state CONNECT). If I enable V4 addresses everything works fine.

This is my current configuration for my cluster. I've also tried setting V6 for the plain and tls listeners but that causes issues.

Listener configuration is not valid: [listener tls cannot configure ipFamilies because it is internal listener, listener tls cannot configure ipFamilyPolicy because it is internal listener, listener plain cannot configure ipFamilies because it is internal listener, listener plain cannot configure ipFamilyPolicy because it is internal listener]

Any help would be appreciated.

I've attached my cluster configuration as well if that's helpful.

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: testing
  labels:
    app: kafka
spec:
  kafka:
    version: 3.7.0
    replicas: 6
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: tls
        configuration:
          ipFamilyPolicy: PreferDualStack
          ipFamilies:
              - IPv4
              - IPv6
    authorization:
      type: simple
      superUsers:
        - CN=kafka-stardust-admin
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      default.replication.factor: 3
      min.insync.replicas: 2
      inter.broker.protocol.version: "3.7"
    template:
      bootstrapService:
        ipFamilyPolicy: PreferDualStack
        ipFamilies:
          - IPv4
          - IPv6
      brokersService:
        ipFamilyPolicy: PreferDualStack
        ipFamilies:
          - IPv4
          - IPv6

      pod:
        topologySpreadConstraints:
          - maxSkew: 1
            topologyKey: zone
            whenUnsatisfiable: ScheduleAnyway
            labelSelector:
              matchLabels:
                app: kafka
            matchLabelKeys:
              - strimzi.io/component-type
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: strimzi.io/name
                      operator: In
                      values:
                        - testing-kafka
                topologyKey: "kubernetes.io/hostname"
    resources:
      limits: 
        cpu: "4"
        memory: 34Gi
      requests: 
        cpu: "2"
        memory: 32Gi
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 2048Gi
        deleteClaim: false
  zookeeper:
    replicas: 3
    storage:
      type: persistent-claim
      size: 100Gi
      deleteClaim: false
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
    template:
      clientService:
          ipFamilyPolicy: PreferDualStack
          ipFamilies:
              - IPv4
              - IPv6
      nodesService:
          ipFamilyPolicy: PreferDualStack
          ipFamilies:
              - IPv4
              - IPv6
      pod:
        topologySpreadConstraints:
          - maxSkew: 1
            topologyKey: zone
            whenUnsatisfiable: ScheduleAnyway
            labelSelector:
              matchLabels:
                app: kafka
            matchLabelKeys:
              - strimzi.io/component-type
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                    - key: strimzi.io/name
                      operator: In
                      values:
                        - testing-zookeeper
                topologyKey: "kubernetes.io/hostname"
    resources:
      limits: 
        cpu: "2"
        memory: 3Gi
      requests: 
        cpu: "1"
        memory: 2Gi

[scholzj]

I don' think your problem has nothing to do with #7148 => that one is about the operator talking over IPv6 to the Kubernetes API. It has nothing to do with Kafka (plus it is old so it might not be needed anymore anyway). So you should not expect that to solve your issue.

It is hard to know for sure without understanding your environment. But it seems to me like your brokers advertise the IPv4 addresses wich your network cannot route. So to fix that, you might need to:

• Have a listener that uses IPv6 as its primary network and not IPv4
• Override the advertised listeners to advertise IPv6 addresses (but than you will likely have the same issue from IPv4-only network)
• If you want to use a single listener for both IPv4 and IPv6, you might need to:
  • Use a custom DNS names as advertised hostnames
  • Make sure the DNS names resolves to IPv4 address in the IPv4 network
  • Make sure the DNS names resolves to IPv6 address in the IPv6 network

(Again, it is a bit speculative what the problem is without detailed knowledge of your environment)

[safaci2000]

Fair enough but as far as the yaml I'm applying assuming v6 functionality is available the strimzi operator config looks correct?

[scholzj]

Yeah, it looks as I would expect it.

[safaci2000]

Thank you. One last question, if using zookeeper, there's also,

kafkas.spec.zookeeper.template where clientService and nodesService both have IPV6 configuration for ipFamilies and ipFamilyPolicy. If I was to use ZK instead of Kraft, would you suggest enabling both of those entities? Or how do they interact with the boostrap service (assuming I have a v4 only and v6 only version) as configured above?

[scholzj]

The ZooKeeper services are internal only. So your clients should not need to worry whether they use IPv6 or IPv4. They are used only by the operator and the Kafka brokers. But if you have dual stack cluster, I do not have any recommendation whether it is better to use IPv6 or IPv4 to be honest.

[safaci2000]

Thank you, well that clarifies all my questions about Strimzi. I'll see what I can figure out with GKE and report back if I find a solution.