Kafka on Kubernetes, the Strimzi way! (Part 2)
Tags: kafka, kubernetes, tutorial
Published: 2020-06-17 13:00:55

We kicked off the the [first part of the series](https://dev.to/azure/kafka-on-kubernetes-the-strimzi-way-part-1-57g7) by setting up a single node Kafka cluster which was accessible to only internal clients within the same Kubernetes cluster, had no encryption, authentication or authorization and used temporary persistence. We will keep iterating/improving on this during the course of this blog series.

This part will cover these topics:

- Expose Kafka cluster to external applications
- Apply `TLS` encryption
- Explore Kubernetes resources behind the scenes
- Use Kafka CLI and Go client applications to test our cluster setup

> The code is available on GitHub - https://github.com/abhirockzz/kafka-kubernetes-strimzi/

![](https://media.giphy.com/media/CjmvTCZf2U3p09Cn0h/giphy-downsized.gif)

## What do I need to try this out?

`kubectl` - https://kubernetes.io/docs/tasks/tools/install-kubectl/

I will be using [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/azure/aks/intro-kubernetes?WT.mc_id=devto-blog-abhishgu) to demonstrate the concepts, but by and large it is independent of the Kubernetes provider (e.g. feel free to use a local setup such as `minikube`). If you want to use `AKS`, all you need is a [Microsoft Azure account](https://docs.microsoft.com/azure/?WT.mc_id=devto-blog-abhishgu) which you can [get for FREE](https://azure.microsoft.com/free/?WT.mc_id=devto-blog-abhishgu) if you don't have one already.

> I will not be repeating some of the common sections (such as Installation/Setup for Helm, Strimzi, Azure Kubernetes Service as well as Strimzi overview) in this or subsequent part of this series and would request you to [refer to part one](https://dev.to/azure/kafka-on-kubernetes-the-strimzi-way-part-1-57g7) for those details

## Let's create an externally accessible Kafka cluster

To achieve this, we just need to tweak the Strimzi `Kafka` resource a little bit. I am highlighting the key part below - [here is the original manifest from part 1](https://github.com/abhirockzz/kafka-kubernetes-strimzi/raw/master/part-1/kafka.yaml)

```yaml
spec:
  kafka:
    version: 2.4.0
    replicas: 1
    listeners:
      plain: {}
      external:
        type: loadbalancer
        tls: true
```

**What changed?**

To make Kafka accessible to external client applications, we added an `external` listener of type `loadbalancer`. Since we will exposing our application to the public Internet, we need additional layers of protection such as transport level (`TLS/SSL` encryption) and application level security (authentication and authorization). In this part, we will just configure encryption and explore the other aspects in another blog. To configure end-to-end TLS encryption, we add `tls: true`

> `tls: true` config is actually used as a default, but I have added it explicitly for sake of clarity

To create the cluster:

```bash
kubectl apply -f https://github.com/abhirockzz/kafka-kubernetes-strimzi/raw/master/part-2/kafka.yaml
```

### Kubernetes magic!

The Strimzi Operator kicks into action and does all the heavy lifting for us:

- It creates a Kubernetes [`LoadBalancer`](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) Service..
- .. and seeding the appropriate Kafka server configuration in a `ConfigMap`
 

![](https://media.giphy.com/media/12NUbkX6p4xOO4/giphy.gif)


I will be highlighting the resources created corresponding to the external listener and TLS encryption. For a walk through of ALL the resources which are created as part of the Kafka cluster, [please refer to part 1](https://dev.to/azure/kafka-on-kubernetes-the-strimzi-way-part-1-57g7)

If you look for the `Service`s, you will see something similar to this:

```bash
kubectl get svc

my-kafka-cluster-kafka-0                    LoadBalancer   10.0.162.98    40.119.233.2    9094:31860/TCP               60s
my-kafka-cluster-kafka-bootstrap            ClusterIP      10.0.200.20    <none>          9091/TCP,9092/TCP            60s
my-kafka-cluster-kafka-brokers              ClusterIP      None           <none>          9091/TCP,9092/TCP            60s
my-kafka-cluster-kafka-external-bootstrap   LoadBalancer   10.0.122.211   20.44.239.202   9094:32267/TCP               60s
my-kafka-cluster-zookeeper-client           ClusterIP      10.0.137.33    <none>          2181/TCP                     82s
my-kafka-cluster-zookeeper-nodes            ClusterIP      None           <none>          2181/TCP,2888/TCP,3888/TCP   82s
```

Notice the `my-kafka-cluster-kafka-external-bootstrap` `Service` of the type `LoadBalancer`? Since I am using Azure Kubernetes Service, this is powered by an [Azure Load Balancer](https://docs.microsoft.com/azure/load-balancer/load-balancer-overview?WT.mc_id=devto-blog-abhishgu) which has a public IP (`20.44.239.202` in this example) and exposes Kafka to external clients over port `9094`. You should be able to locate it using the Azure CLI (or the Azure portal if you prefer) by using the [`az network lb list`](https://docs.microsoft.com/cli/azure/network/lb?view=azure-cli-latest&WT.mc_id=devto-blog-abhishgu#az-network-lb-list) command

```bash
export AKS_RESOURCE_GROUP=[replace with resource group name]
export AKS_CLUSTER_NAME=[replace with AKS cluster name]
export AKS_LOCATION=[replace with region e.g. southeastasia]

az network lb list -g MC_${AKS_RESOURCE_GROUP}_${AKS_CLUSTER_NAME}_${AKS_LOCATION}
```

**What about the encryption part?**

To figure that out, let's introspect the Kafka server configuration:

> As explained in the [previous blog](https://dev.to/azure/kafka-on-kubernetes-the-strimzi-way-part-1-57g7), this is stored in a `ConfigMap`

```bash
export CLUSTER_NAME=my-kafka-cluster
kubectl get configmap/${CLUSTER_NAME}-kafka-config -o yaml
```

This is what the `Common listener configuration` in `server.config` reveals:

```bash
listeners=REPLICATION-9091://0.0.0.0:9091,PLAIN-9092://0.0.0.0:9092,EXTERNAL-9094://0.0.0.0:9094
advertised.listeners=REPLICATION-9091://my-kafka-cluster-kafka-${STRIMZI_BROKER_ID}.my-kafka-cluster-kafka-brokers.default.svc:9091,PLAIN-9092://my-kafka-cluster-kafka-${STRIMZI_BROKER_ID}.my-kafka-cluster-kafka-brokers.default.svc:9092,EXTERNAL-9094://${STRIMZI_EXTERNAL_9094_ADVERTISED_HOSTNAME}:${STRIMZI_EXTERNAL_9094_ADVERTISED_PORT}
listener.security.protocol.map=REPLICATION-9091:SSL,PLAIN-9092:PLAINTEXT,EXTERNAL-9094:SSL
```

Notice that in addition to inter-broker replication (over port `9091`) and un-encrypted internal (within Kubernetes cluster) client access over non `TLS` port `9092`, appropriate listener config has been added for TLS encrypted access over port `9094`

## The moment of truth....

To confirm, let's try out a couple of client applications which will communicate with our freshly minted Kafka cluster on Kubernetes! We will produce and consume messages using the following:

- Kafka CLI (console) producer and consumer
- Go application (using the [Confluent Kafka Go client](https://github.com/confluentinc/confluent-kafka-go))

Communication to our Kafka cluster has to be encrypted (non TLS client connections will be rejected). `TLS/SSL` implicitly implies one way authentication, where the client validates the Kafka broker identity. In order to do this, client applications need to trust the cluster CA certificate. Remember that the cluster CA certificate is stored in a Kubernetes `Secret` (refer to [details in part 1](https://dev.to/azure/kafka-on-kubernetes-the-strimzi-way-part-1-57g7)). By default, these are auto-generated by Strimzi, but you can provide your own certificates as well (refer https://strimzi.io/docs/operators/master/using.html#kafka-listener-certificates-str)

Start by extracting the cluster CA certificate and password:

```bash
export CLUSTER_NAME=my-kafka-cluster

kubectl get secret $CLUSTER_NAME-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 --decode > ca.crt
kubectl get secret $CLUSTER_NAME-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 --decode > ca.password
```

> You should have two files: `ca.crt` and `ca.password`. Feel free to check out their contents

While some Kafka clients (e.g. Confluent Go client) use the CA certificate directly, others (e.g. Java client, Kafka CLI etc.) require access to the CA certificate via a `truststore`. I am using the built-in `truststore` which comes in with a JDK (Java) installation - but this is just for convenience and you're free to use other options (such as creating your own)

```bash
export CERT_FILE_PATH=ca.crt
export CERT_PASSWORD_FILE_PATH=ca.password

# replace this with the path to your truststore

export KEYSTORE_LOCATION=/Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/jre/lib/security/cacerts
export PASSWORD=`cat $CERT_PASSWORD_FILE_PATH`
export CA_CERT_ALIAS=strimzi-kafka-cert

# you will prompted for the truststore password. for JDK truststore, the default password is "changeit"
# Type yes in response to the 'Trust this certificate? [no]:' prompt

sudo keytool -importcert -alias $CA_CERT_ALIAS -file $CERT_FILE_PATH -keystore $KEYSTORE_LOCATION -keypass $PASSWORD

sudo keytool -list -alias $CA_CERT_ALIAS -keystore $KEYSTORE_LOCATION
```

That's it for the base setup - you are ready to try out the Kafka CLI client!

> Please note that the configuration steps for the Kafka CLI as detailed below will also work for the Java clients as well - give it a try!

Extract the `LoadBalancer` public IP for Kafka cluster

```bash
export KAFKA_CLUSTER_NAME=my-kafka-cluster

kubectl get service/${KAFKA_CLUSTER_NAME}-kafka-external-bootstrap --output=jsonpath={.status.loadBalancer.ingress[0].ip}
```

Create a file called `client-ssl.properties` with the following contents:

```bash
bootstrap.servers=[LOADBALANCER_PUBLIC_IP]:9094
security.protocol=SSL
ssl.truststore.location=[TRUSTSTORE_LOCATION]
//for JDK truststore, the default password is "changeit"
ssl.truststore.password=changeit
```

To use the Kafka CLI, download `Kafka` if you don't have it already - https://kafka.apache.org/downloads

All you need to do is use the `kafka-console-producer` and `kafka-console-consumer` by pointing it to the `client-ssl.properties` file you just created

```bash
export KAFKA_HOME=[replace with Kafka installation path] e.g. /Users/foobar/kafka_2.12-2.3.0
export LOADBALANCER_PUBLIC_IP=[replace with public IP of Load Balancer]
export TOPIC_NAME=test-strimzi-topic

# on a terminal, start producer and send a few messages
$KAFKA_HOME/bin/kafka-console-producer.sh --broker-list $LOADBALANCER_PUBLIC_IP:9094 --topic $TOPIC_NAME --producer.config client-ssl.properties

# on another terminal, start consumer
$KAFKA_HOME/bin/kafka-console-consumer.sh --bootstrap-server $LOADBALANCER_PUBLIC_IP:9094 --topic $TOPIC_NAME --consumer.config client-ssl.properties --from-beginning
```

You should see producer and consumer working in tandem. Great! 

> If you face SSL Handshake errors, please check whether the CA cert has been correctly imported along with its correct password. If the Kafka cluster is not reachable, ensure you are using the right value for the public IP

Now, let's try a programmatic client. Since the Java client behavior (required config properties) are same as the CLI, I am using a Go client to try something different. Don't worry, if you are not a Go programmer, it should be easy to follow along - I will not walk through the entire program, just the part where we create the connection related configuration. 

Here is the snippet:

```go
    bootstrapServers = os.Getenv("KAFKA_BOOTSTRAP_SERVERS")
    caLocation = os.Getenv("CA_CERT_LOCATION")
    topic = os.Getenv("KAFKA_TOPIC")

    config := &kafka.ConfigMap{"bootstrap.servers": bootstrapServers, "security.protocol": "SSL", "ssl.ca.location": caLocation}
```

Notice that the `bootstrap.servers` and `security.protocol` are the same as ones you used in the Kafka CLI client (same for Java as well). The only difference is that `ssl.ca.location` is used to point to the CA certificate directly as opposed to a `truststore`

If you have `Go` installed, you can try it out. Clone the Git repo...

```bash
git clone https://github.com/abhirockzz/kafka-kubernetes-strimzi
cd part-2/go-client-app
```

.. and run the program:

```go
export KAFKA_BOOTSTRAP_SERVERS=[replace with loadbalancer_ip:9094] e.g. 42.42.424.424:9094
export CA_CERT_LOCATION=[replace with path to ca.crt file which you downloaded]
export KAFKA_TOPIC=test-strimzi-topic

go run kafka-client.go
```

You should see logs similar to this and confirm that messages are being produced and consumed

> press `ctrl+c` to exit the app

```bash
started consumer
started producer delivery goroutine
started producer goroutine
delivered messaged test-strimzi-topic[0]@122
delivered messaged test-strimzi-topic[0]@123
delivered messaged test-strimzi-topic[0]@124
received message from test-strimzi-topic[0]@122: value-2020-06-08 16:23:05.913303 +0530 IST m=+0.020529419
received message from test-strimzi-topic[0]@123: value-2020-06-08 16:23:07.915252 +0530 IST m=+2.022455867
received message from test-strimzi-topic[0]@124: value-2020-06-08 16:23:09.915875 +0530 IST m=+4.023055601
received message from test-strimzi-topic[0]@125: value-2020-06-08 16:23:11.915977 +0530 IST m=+6.023134961
....
```

## That's all for now, but there is more to come!

![](https://media.giphy.com/media/26u4lOMA8JKSnL9Uk/giphy.gif)

So we made some progress! We now have a Kafka cluster on Kubernetes which is publicly accessible but is (partially) secure thanks to TLS encryption. We also did some sanity testing using not one, but two (different) client applications. In the next part, we'll improve this further... stay tuned!