Skip to main content
Version: 0.1.6

Source CRD configurations

This document lists CRD configurations available for Pulsar source connectors. The source CRD configurations consist of source connector configurations and the common CRD configurations.

Source configurations

This table lists source configurations.

nameThe name of a source connector.
classnameThe class name of a source connector.
tenantThe tenant of a source connector.
clusterNameThe Pulsar cluster of a source connector.
replicasThe number of instances that you want to run this source connector.
maxReplicasThe maximum number of Pulsar instances that you want to run for this source connector. When the value of the maxReplicas parameter is greater than the value of replicas, it indicates that the source controller automatically scales the source connector based on the CPU usage. By default, maxReplicas is set to 0, which indicates that auto-scaling is disabled.
sourceConfigThe map to a ConfigMap specifying the configuration of a source connector.
processingGuaranteeThe processing guarantees (delivery semantics) applied to the source connector. Available values: atleast_once, atmost_once, effectively_once.


This section describes image options available for Pulsar source CRDs.

Base runner

The base runner is an image base for other runners. The base runner is located at ./pulsar-functions-base-runner. The base runner image contains basic tool-chains like /pulsar/bin, /pulsar/conf and /pulsar/lib to ensure that the pulsar-admin CLI tool works properly to support Apache Pulsar Packages.

Runner images

Function Mesh uses runner images as images of Pulsar connectors. Each runner image only contains necessary tool-chains and libraries for specified runtime.

Pulsar connectors support using the Java runner images as their images. The Java runner is based on the base runner and contains the Java function instance to run Java functions or connectors. The streamnative/pulsar-functions-java-runner Java runner is stored at the Docker Hub and is automatically updated to align with Apache Pulsar release.


The output topics of a Pulsar Function. This table lists options available for the Output.

topicsThe output topic of a Pulsar Function (If none is specified, no output is written).
sinkSerdeClassNameThe map of output topics to SerDe class names (as a JSON string).
sinkSchemaTypeThe built-in schema type or custom schema class name to be used for messages sent by the function.
producerConfThe producer specifications. Available options:
- maxPendingMessages: the maximum number of pending messages.
- maxPendingMessagesAcrossPartitions: the maximum number of pending messages across partitions.
- useThreadLocalProducers: configure whether the producer uses a thread.
- cryptoConfig: cryptography configurations of the producer.
- batchBuilder: support key-based batcher.
customSchemaSinksThe map of output topics to Schema class names (as a JSON string).


When you specify a function or connector, you can optionally specify how much of each resource they need. The resources available to specify are CPU and memory (RAM).

If the node where a Pod is running has enough of a resource available, it's possible (and allowed) for a Pod to use more resources than its request for that resource. However, a Pod is not allowed to use more than its resource limit.


Function Mesh provides the tlsSecret and authSecret fields for Function, Source and Sink in the CRD definition. You can configure TLS encryption and/or TLS authentication using the following configurations.

  • TLS Secret

    tlsAllowInsecureConnectionAllow insecure TLS connection.
    tlsHostnameVerificationEnableEnable hostname verification.
    tlsTrustCertsFilePathThe path of the TLS trust certificate file.
  • Authentication Secret

    clientAuthenticationPluginThe client authentication plugin.
    clientAuthenticationParametersThe client authentication parameters.


Function Mesh supports running Pulsar connectors in Java.

jarLocationPath to the JAR file for the connector.
extraDependenciesDirIt specifies the dependent directory for the JAR package.

Cluster location

In Function Mesh, the Pulsar cluster is defined through a ConfigMap. Pods can consume ConfigMaps as environment variables in a volume. The Pulsar cluster ConfigMap defines the Pulsar cluster URLs.

webServiceURLThe Web service URL of the Pulsar cluster.
brokerServiceURLThe broker service URL of the Pulsar cluster.

Pod specifications

Function Mesh supports customizing the Pod running connectors. This table lists sub-fields available for the pod field.

labelsSpecify labels attached to a Pod.
nodeSelectorSpecify a map of key-value pairs. For a Pod running on a node, the node must have each of the indicated key-value pairs as labels.
affinitySpecify the scheduling constraints of a Pod.
tolerationsSpecify the tolerations of a Pod.
annotationsSpecify the annotations attached to a Pod.
securityContextSpecify the security context for a Pod.
terminationGracePeriodSecondsIt is the amount of time that Kubernetes gives for a Pod before terminating it.
volumesIt is a list of volumes that can be mounted by containers belonging to a Pod.
imagePullSecretsIt is an optional list of references to secrets in the same namespace for pulling any of the images used by a Pod.
serviceAccountNameSpecify the name of the service account which is used to run Pulsar Functions or connectors.
initContainersInitialization containers belonging to a Pod. A typical use case could be using an Initialization container to download a remote JAR to a local path.
sidecarsSidecar containers run together with the main function container in a Pod.