Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Accessing Apache Kafka in Strimzi: Part 5 – Ingress

June 12, 2019
Jakub Scholz
Related topics:
ContainersKubernetes
Related products:
Streams for Apache KafkaRed Hat OpenShift

Share:

    In the fifth and final part of this series, we will look at exposing Apache Kafka in Strimzi using Kubernetes Ingress. This article will explain how to use Ingress controllers on Kubernetes, how Ingress compares with Red Hat OpenShift routes, and how it can be used with Strimzi and Kafka. Off-cluster access using Kubernetes Ingress is available only from Strimzi 0.12.0. (Links to previous articles in the series can be found at the end.)

    Note: Productized and supported versions of the Strimzi and Apache Kafka projects are available as part of the Red Hat AMQ product.

    Kubernetes Ingress

    Ingress is a Kubernetes API for managing external access to HTTP/HTTPS services,  which was added in Kubernetes 1.1. Ingress is the Kubernetes counterpart to Red Hat OpenShift routes, which we discussed previously. It acts as a Layer 7 load balancer for HTTP or HTTPS traffic. The Ingress resources will define the rules for routing the traffic to different services and pods. An Ingress controller takes care of the actual routing. For more information about Ingress, check out the Kubernetes website.

    Ingress is a sort of strange part of the Kubernetes API. The Ingress API itself is part of every Kubernetes cluster, but the Ingress controller that would do the routing is not part of core Kubernetes. So, while you may be able to create the Ingress resources, there may be nothing to actually route the traffic.

    For the Ingress resources to actually do something, you need to make sure an Ingress controller is installed. There are many different Ingress controllers. The Kubernetes project itself has two controllers:

    • NGINX controller
    • GCE controller for Google Cloud

    Many additional controllers are created and maintained by different communities and companies. A list of different controllers can be found on the Kubernetes website.

    Most of the controllers rely on a load balancer or node port service, which will get the external traffic to the controller. Once the traffic reaches the controller, the controller will route it based on rules specified in the Ingress resource to the different services and pods. The controller itself usually also runs as yet another application inside the Kubernetes cluster.

    Some of the controllers are tailored for a specific public cloud. For example, the AWS ALB Ingress Controller provisions the AWS Application Load Balancer to do the routing instead of doing it inside a pod in your Kubernetes cluster.

    Ingress offers a lot of functionality for HTTP applications such as:

    • TLS termination
    • Redirecting from HTTP to HTTPS
    • Routing based on HTTP request path

    Some of the controllers, such as the NGINX controller, also offer TLS passthrough, which is a feature we use in Strimzi.

    Using Ingress in Strimzi

    Ingress support in Strimzi has been added in Strimzi 0.12.0. It uses TLS passthrough and was tested with the NGINX Ingress Controller. Before using it, please make sure that the TLS passthrough is enabled in the controller. Note that Ingress support in Strimzi 0.12.0 is experimental. If you have any feedback or want to help make it work with different Ingress controllers, you can get in touch with us through Slack, our mailing list, or GitHub.

    Although some Ingress controllers also support working directly with TCP connections, TLS passthrough seems to be more widely supported. Therefore, we decided to prefer TLS passthrough in Strimzi. That also means that when using Ingress, TLS encryption will always be enabled.

    One of the main differences of Ingress, as compared with OpenShift routes, is that for Ingress you must specify the host address in your Kafka custom resource. The router in OpenShift will automatically assign a host address based on the route name and the project. In Ingress, however, the host address must be specified in the Ingress resource. You also have to take care that DNS resolves the host address to the Ingress controller. Strimzi cannot generate it for you, because it does not know which DNS addresses are configured for the Ingress controller.

    If you want to try it, for example, on Minikube or in other environments where you don't have any managed DNS service to add the hosts for the Kafka cluster, you can use a wildcard DNS service, such as nip.io or xip.io, and set it to point to the IP address of your Ingress controller. For example, you can do: broker-0.<minikube-ip-address>.nip.io.

    The way Strimzi uses Ingress to expose Apache Kafka should be familiar to you from the previous articles. We create one service as a bootstrap service and additional services for individual access to each of the Kafka brokers in the cluster. For each of these services, we will also create one Ingress resource with the corresponding TLS passthrough rule.

    When configuring Strimzi to use Ingress, you must specify the type of the external listener as ingress and specify the Ingress hosts used for the different brokers, as well as for bootstrap, in the configuration field:

    apiVersion: kafka.strimzi.io/v1beta1
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        listeners:
          # ...
          external:
            type: ingress
            configuration:
              bootstrap:
                host: bootstrap.192.168.64.46.nip.io
              brokers:
              - broker: 0
                host: broker-0.192.168.64.46.nip.io
              - broker: 1
                host: broker-1.192.168.64.46.nip.io
              - broker: 2
                host: broker-2.192.168.64.46.nip.io
        # ...
    

    Using Ingress in your clients is very similar to OpenShift routes. Because it always uses TLS encryption, you have to first download the server certificate (replace my-cluster with the name of your cluster):

    kubectl get secret cluster-name-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
    keytool -import -trustcacerts -alias root -file ca.crt -keystore truststore.jks -storepass password -noprompt
    

    Once you have the TLS certificate, you can use the bootstrap host you specified in the Kafka custom resource and connect to the Kafka cluster. Because Ingress uses TLS passthrough, you always have to connect on port 443. The following example uses the kafka-console-producer.sh utility, which is part of Apache Kafka:

    bin/kafka-console-producer.sh --broker-list :443 --producer-property security.protocol=SSL --producer-property ssl.truststore.password=password --producer-property ssl.truststore.location=./truststore.jks --topic 
    

    For example:

    bin/kafka-console-producer.sh --broker-list bootstrap.192.168.64.46.nip.io:443 --producer-property security.protocol=SSL --producer-property ssl.truststore.password=password --producer-property ssl.truststore.location=./truststore.jks --topic 
    

    For more details, see the Strimzi documentation.

    Customizations

    DNS annotations

    Many users employ additional tools, such as ExternalDNS, to automatically manage DNS records for their load balancers. ExternalDNS uses annotations on Ingress resources to manage their DNS names. It also supports many different DNS services, such as Amazon AWS Route53, Google Cloud DNS, Azure DNS, etc.

    Strimzi lets you assign these annotations through the Kafka custom resource using a field called dnsAnnotations. Using the DNS annotations is simple:

    # ...
    listeners:
      external:
        type: ingress
        configuration:
          bootstrap:
            host: kafka-bootstrap.mydomain.com
          brokers:
          - broker: 0
            host: kafka-broker-0.mydomain.com
          - broker: 1
            host: kafka-broker-1.mydomain.com
          - broker: 2
            host: kafka-broker-2.mydomain.com
        overrides:
          bootstrap:
            dnsAnnotations:
              external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
              external-dns.alpha.kubernetes.io/ttl: "60"
          brokers:
          - broker: 0
            dnsAnnotations:
              external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
              external-dns.alpha.kubernetes.io/ttl: "60"
          - broker: 1
            dnsAnnotations:
              external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
              external-dns.alpha.kubernetes.io/ttl: "60"
          - broker: 2
            dnsAnnotations:
              external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
              external-dns.alpha.kubernetes.io/ttl: "60"
    # ...
    

    Again, Strimzi lets you configure the annotations directly. That gives you more freedom and makes this feature usable even when you use a tool other than ExternalDNS. It also lets you configure other options than just the DNS names, such as the time-to-live of the DNS records, and so on.

    Pros and cons

    Kubernetes Ingress is not always easy to use because you have to install the Ingress controller, and you have to configure the hosts. It is also available only with TLS encryption because of the TLS passthrough functionality that Strimzi uses. However, it can offer an interesting option for clusters where node ports are not an option, for example, for security reasons and cases in which using load balancers would be too expensive.

    When using Strimzi Kafka operator with Ingress, you must also consider performance. The Ingress controller usually runs inside your cluster as yet another deployment and adds an additional step through which your data has to flow between your clients and the brokers. You need to scale it properly to ensure it will not be a bottleneck for your clients.

    Thus, Ingress might not be the best option when most of your applications using Kafka are outside of your Kubernetes cluster and you need to handle tens or hundreds of megabytes of throughput per second. However, especially in situations when most of your applications are inside your cluster and only a minority are outside and when the throughput you need is not so high, Ingress might be a convenient option.

    The Ingress API and the Ingress controllers can usually be installed on OpenShift clusters as well, but they do not offer any advantages over the OpenShift routes. So, on OpenShift, you will likely want to use OpenShift routes instead.

    What's next?

    This was, for now, the last post in this series about accessing Strimzi Kafka clusters. In the five articles, we covered all the supported mechanisms that the Strimzi operator supports for accessing Apach Kafka from both inside and outside of your Kubernetes or Red Hat OpenShift cluster. We will, of course, keep posting articles on other topics and if something about accessing Kafka changes in the future, we will add to this series.

    If you liked this series, star us on GitHub and follow Strimzi on Twitter to stay up to date with the project.

    Read more

    • Accessing Apache Kafka in Strimzi: Part 1 – Introduction
    • Accessing Apache Kafka in Strimzi: Part 2 - Node ports
    • Accessing Apache Kafka in Strimzi: Part 3 - Red Hat OpenShift routes
    • Accessing Apache Kafka in Strimzi: Part 4 - Load balancers
    Last updated: March 18, 2020

    Recent Posts

    • Storage considerations for OpenShift Virtualization

    • Upgrade from OpenShift Service Mesh 2.6 to 3.0 with Kiali

    • EE Builder with Ansible Automation Platform on OpenShift

    • How to debug confidential containers securely

    • Announcing self-service access to Red Hat Enterprise Linux for Business Developers

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue