Co-author: @Apoorva Sahu

In our earlier blog Red Hat OpenShift Serverless with Apache Kafka, we introduced you to Red Hat OpenShift Serverless on IBM Power. We have learned how an event-based serverless application can be deployed using OpenShift Serverless and OpenShift Streams for Apache Kafka. However, this is not the only way to deploy a serverless application. In this blog, let us see how to deploy another sample application with OpenShift Serverless and OpenShift GitOps.

With Git repository serving as a single source of truth for application configuration, you can deploy OpenShift Serverless, OpenShift Stream for Apache Kafka, and an event-based serverless application instance on an OpenShift cluster. This is enabled through simplifying application deployment with OpenShift GitOps on IBM Power.

This blog explains a sample demo application that is deployed on Red Hat OpenShift Container Platform 4.19.19 on IBM Power Architecture with OpenShift Serverless 1.37.1, Streams for Apache Kafka 2.9.1-0, and OpenShift GitOps 1.19.1 operators installed on it.

The GitOps application configurations are stored in the Git repository. For this sample demo, all the configurations are present at https://github.com/kabhiibm/serverless-gitops-demo.git. In case, you want to use your own Git repository, then copy the YAML configuration in different files and push it to your repository. We have provided the contents of each of the files used in this deployment in the corresponding steps.

Refer to the file structure (in the following screenshot) of the GitHub repository used for the deployment explained in this blog.

Although GitOps command-line interface (CLI), which is Argo CD, can be used to deploy the applications, the sample GitOps application in this blog has been deployed using the application’s user interface (UI). It is easier for a new user or developer to visualize the application from the dashboard.

In this walkthrough, we use the above GitHub repository as our source of truth and deploy the applications using the Argo CD UI.

Refer to the following steps to deploy the instances in the form of GitOps application.

Step 1. Install the operators.

Install the following operators on the OpenShift cluster:

• Red Hat OpenShift Serverless
• Red Hat OpenShift Streams for Apache Kafka
• Red Hat OpenShift GitOps

For more information on installing operators, see Red Hat OpenShift Serverless with Apache Kafka and Simplifying application deployment with OpenShift GitOps on IBM Power .

Step 2. Create a namespace.

Create a new namespace for the sample demo application.

oc apply -f - << EOD  
apiVersion: v1  
kind: Namespace  
metadata:  
  name: serverless-demo  
EOD  

Step 3. Update admin policy to controller.

Apply cluster-admin to the openshift-gitops-argocd-application-controller service account to successfully reconcile cluster-wide and cross-namespace resources without encountering role-based access control (RBAC) error with GitOps (Argo CD).

$ oc adm policy add-cluster-role-to-user cluster-admin -z openshift-gitops-argocd-application-controller -n openshift-gitops  
clusterrole.rbac.authorization.k8s.io/cluster-admin added: "openshift-gitops-argocd-application-controller"  

Step 4. Login to the GitOps UI.

Login to the GitOps (Argo CD) UI using the admin password. For more information on how to get the admin password, refer to the blog, Simplifying application deployment with OpenShift GitOps on IBM Power.

Step 5. Create a sample GitOps application.

To deploy the Kafka instance in the serverless-demonamespace, create a sample GitOps application (sfak in this case) from the UI.

The setup contents of a Kafka cluster are shown in the following kafka-cluster.yaml file:

kind: Kafka  
apiVersion: kafka.strimzi.io/v1beta2  
metadata:  
  name: my-cluster  
  namespace: serverless-demo  
spec:  
  kafka:  
    version: 3.9.0  
    replicas: 3  
    listeners:  
      - name: plain  
        port: 9092  
        type: internal  
        tls: false  
      - name: tls  
        port: 9093  
        type: internal  
        tls: true  
    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.9'  
    storage:  
      type: ephemeral  
  zookeeper:  
    replicas: 3  
    storage:  
      type: ephemeral  
  entityOperator:  
    topicOperator: {}  
    userOperator: {}  

The setup contents of Kafka topic is shown in the following kafka-topic.yaml file:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: my-topic
  generation: 1
  namespace: serverless-demo
  labels:
    strimzi.io/cluster: my-cluster
spec:
  config:
    retention.ms: 604800000
    segment.bytes: 1073741824
  partitions: 10
  replicas: 1

The setup contents of Kafka bridge is shown in the following kafka-bridge.yaml file.

apiVersion: kafka.strimzi.io/v1beta2
metadata:
  name: my-bridge
  namespace: serverless-demo
spec:
  replicas: 1
  bootstrapServers: 'my-cluster-kafka-bootstrap:9092'
  http:
    port: 8080

Step 6. Create an OpenShift serverless (Knative) application.

To deploy the Knative instances in the serverless-demo namespace, create the knative-instance application from the UI.

The setup contents of KnativeServing, KnativeEventing,and KnativeKafka are shown in the following knative-instances.yaml file:

apiVersion: operator.knative.dev/v1beta1  
kind: KnativeServing  
metadata:  
  name: knative-serving  
  namespace: knative-serving  
---  
apiVersion: operator.knative.dev/v1beta1  
kind: KnativeEventing  
metadata:  
  name: knative-eventing  
  namespace: knative-eventing  
---  
apiVersion: operator.serverless.openshift.io/v1alpha1  
kind: KnativeKafka  
metadata:  
  name: knative-kafka  
  namespace: knative-eventing  
spec:  
  broker:  
    defaultConfig:  
      authSecretName: ''  
      bootstrapServers: 'my-cluster-kafka-bootstrap.serverless-demo.svc:9092'  
      numPartitions: 10  
      replicationFactor: 3  
    enabled: true  
  channel:  
    authSecretName: ''  
    authSecretNamespace: ''  
    bootstrapServers: 'my-cluster-kafka-bootstrap.serverless-demo.svc:9092'  
    enabled: true  
  high-availability:  
    replicas: 1  
  logging:  
    level: INFO  
  sink:  
    enabled: true  
  source:  
    enabled: true  

The setup contents of a Knative source is shown in the following knative-source.yaml file:

apiVersion: sources.knative.dev/v1beta1
kind: KafkaSource
metadata:
  name: kafka-source
  namespace: serverless-demo
  labels:
    app: kafka-source
    app.kubernetes.io/instance: kafka-source
    app.kubernetes.io/component: kafka-source
    app.kubernetes.io/name: kafka-source
    app.kubernetes.io/part-of: strimzi-my-bridge
  annotations:
    openshift.io/generated-by: OpenShiftWebConsole
spec:
  bootstrapServers: 
    - my-cluster-kafka-bootstrap.serverless-demo.svc:9092
  topics:
    - my-topic
  consumerGroup: my-kafka-group
  net:
    sasl:
      user: {}
      password: {}
    tls:
      caCert: {}
      cert: {}
      key: {}
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display
    uri: ''

Step 7. Create an OpenShift Serverless demo application.

Finally, to deploy the Knative service in the serverless-demo namespace, create a sample-demo application from the OpenShift UI.

Refer to the setup contents of a Knative sample application in the following event-display.yaml file:

apiVersion: serving.knative.dev/v1  
kind: Service  
metadata:  
  name: event-display  
  namespace: serverless-demo  
spec:  
  template:  
    metadata:  
      annotations:  
        autoscaling.knative.dev/target: "1"  
        autoscaling.knative.dev/minScale: "0"  
        autoscaling.knative.dev/maxScale: "10"  
    spec:  
      containers:  
        - image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display  

Step 8. Send a message to the Knative service/application.

Use the following command to send a message to expose the my-bridge-bridge-service Kafka Bridge service on the terminal.

oc expose svc my-bridge-bridge-service -n serverless-demo  

Extract the Kafka Bridge route to send a message. Initialize the route variable for the producer script. The producer script uses this route to send the Hello World!! message every 0.5 seconds across the Kafka cluster to the consumer application in the Kafka Serving instance.

ROUTE=$(oc get route my-bridge-bridge-service -n serverless-demo -ojson | jq '"\(.spec.host)"' | tr -d '"')  
while :;   
curl -X POST $ROUTE/topics/my-topic -H 'content-type: application/vnd.kafka.json.v2+json' -d '{"records": [{"value": "'"$i"' Hello World!!"}]}';   
echo $i;  
do sleep 0.5;  
((i=i+1));   
done  

Monitor the logs generated by the producer script and observe one of the pods processing a CloudEvents message.

Conclusion

By using OpenShift GitOps along with OpenShift Serverless and Apache Kafka, developers can achieve a fully automated, declarative, and consistent deployment workflow for event-driven serverless applications on IBM Power Architecture. Using Git as the single source of truth ensures version-controlled configurations, simplified rollbacks, and improved collaboration across teams. The integration of Knative components with Kafka enables scalable, real-time event processing without manual intervention. This approach not only streamlines application lifecycle management but also enhances reliability and observability through the GitOps dashboard. Ultimately, adopting GitOps for serverless deployments empowers organizations to deliver cloud-native applications faster, with greater confidence and operational efficiency.