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.

Field	Description
name	The name of a source connector.
classname	The class name of a source connector.
tenant	The tenant of a source connector.
namespace	The Pulsar namespace of a source connector.
clusterName	The Pulsar cluster of a source connector.
replicas	The number of instances that you want to run this source connector.
maxReplicas	The 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.
sourceConfig	The source connector configurations in YAML format.
processingGuarantee	The processing guarantees (delivery semantics) applied to the source connector. Available values: atleast_once, atmost_once, effectively_once.
forwardSourceMessageProperty	Configure whether to pass message properties to a target topic.

Annotations

In Kubernetes, an annotation defines an unstructured Key Value Map (KVM) that can be set by external tools to store and retrieve metadata. annotations must be a map of string keys and string values. Annotation values must pass Kubernetes annotations validation. For details, see Kubernetes documentation on Annotations.

This example shows how to use an annotation to make an object unmanaged. Therefore, the Controller will skip reconciling unmanaged objects in reconciliation loop.

apiVersion: compute.functionmesh.io/v1alpha1
kind: Source
metadata:
  annotations:
    compute.functionmesh.io/managed: "false"

Images

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.

Image pull policies

When the Function Mesh Operator creates a container, it uses the imagePullPolicy option to determine whether the image should be pulled prior to starting the container. There are three possible values for the imagePullPolicy option:

Field	Description
Always	Always pull the image.
Never	Never pull the image.
IfNotPresent	Only pull the image if the image does not already exist locally.

Output

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

Name	Description
topics	The output topic of a Pulsar Function (If none is specified, no output is written).
sinkSerdeClassName	The map of output topics to SerDe class names (as a JSON string).
sinkSchemaType	The built-in schema type or custom schema class name to be used for messages sent by the function.
producerConf	The 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.
customSchemaSinks	The map of output topics to Schema class names (as a JSON string).

Resources

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.

Secrets

Function Mesh provides the secretsMap field for Function, Source, and Sink in the CRD definition. You can refer to the created secrets under the same namespace and the controller can include those referred secrets. The secrets are provide by EnvironmentBasedSecretsProvider, which can be used by context.getSecret() in Pulsar functions and connectors.

The secretsMap field is defined as a Map struct with String keys and SecretReference values. The key indicates the environment value in the container, and the SecretReference is defined as below.

Field	Description
path	The name of the secret in the Pod's namespace to select from.
key	The key of the secret to select from. It must be a valid secret key.

Suppose that there is a Kubernetes Secret named credential-secret defined as below:

apiVersion: v1
data:
  username: foo
  password: bar
kind: Secret
metadata:
  name: credential-secret
type: Opaque

To use it in Pulsar Functions in a secure way, you can define the secretsMap in the Custom Resource:

secretsMap:
  username:
    path: credential-secret
    key: username
  password:
    path: credential-secret
    key: password

Then, in the Pulsar Functions and Connectors, you can call context.getSecret("username") to get the secret value (foo).

Authentication

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

  Field	Description
  tlsAllowInsecureConnection	Allow insecure TLS connection.
  tlsHostnameVerificationEnable	Enable hostname verification.
  tlsTrustCertsFilePath	The path of the TLS trust certificate file.

• Authentication Secret

  Field	Description
  clientAuthenticationPlugin	The client authentication plugin.
  clientAuthenticationParameters	The client authentication parameters.

Packages

Function Mesh supports running Pulsar connectors in Java.

Field	Description
jarLocation	Path to the JAR file for the connector.
extraDependenciesDir	It 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.

Field	Description
webServiceURL	The Web service URL of the Pulsar cluster.
brokerServiceURL	The 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.

Field	Description
labels	Specify labels attached to a Pod.
nodeSelector	Specify 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.
affinity	Specify the scheduling constraints of a Pod.
tolerations	Specify the tolerations of a Pod.
annotations	Specify the annotations attached to a Pod.
securityContext	Specify the security context for a Pod.
terminationGracePeriodSeconds	It is the amount of time that Kubernetes gives for a Pod before terminating it.
volumes	It is a list of volumes that can be mounted by containers belonging to a Pod.
imagePullSecrets	It is an optional list of references to secrets in the same namespace for pulling any of the images used by a Pod.
serviceAccountName	Specify the name of the service account which is used to run Pulsar Functions or connectors.
initContainers	Initialization containers belonging to a Pod. A typical use case could be using an Initialization container to download a remote JAR to a local path.
sidecars	Sidecar containers run together with the main function container in a Pod.
builtinAutoscaler	Specify the built-in autoscaling rules. - CPU-based autoscaling: auto-scale the number of Pods based on the CPU usage (80%, 50%, or 20%). - Memory-based autoscaling: auto-scale the number of Pods based on the memory usage (80%, 50%, or 20%). If you configure the builtinAutoscaler field, you do not need to configure the autoScalingMetrics and autoScalingBehavior options and vice versa.
autoScalingMetrics	Specify how to scale based on customized metrics defined in connectors. For details, see MetricSpec v2 autoscaling.
autoScalingBehavior	Configure the scaling behavior of the target in both up and down directions (scaleUp and scaleDown fields respectively). If not specified, the default Kubernetes scaling behaviors are adopted. For details, see HorizontalPodAutoscalerBehavior v2 autoscaling.