Advanced Topics on gNMIc Operator

Target Distribution

Mon, 01 Jan 0001 00:00:00 +0000

The gNMIc Operator uses a simple algorithm to distribute targets across pods. More placement/distribution strategies will be implemented in the future.

This page explains the algorithm and its properties.

Algorithm: Bounded Load Rendezvous Hashing

The operator uses bounded load rendezvous hashing, which combines two techniques:

Rendezvous hashing: For stability (targets stay on same pod)
Bounded load: For even distribution (no pod is overloaded)

How It Works

Step 1: Determine Capacity

If the Cluster CR specifies spec.targetDistribution.perPodCapacity, that value is used as a fixed ceiling. Otherwise capacity is calculated automatically:

Scaling

Mon, 01 Jan 0001 00:00:00 +0000

The gNMIc Operator supports horizontal scaling of collector clusters. This page explains how scaling works and best practices for production deployments.

This page is about sizing the gNMIc collector pods. For the operator pod itself — its memory footprint, --watch-namespaces, and Kubernetes API rate limits — see Operator Resources.

Scaling a Cluster

To scale a cluster, update the replicas field:

# Scale to 5 replicas
kubectl patch cluster my-cluster --type merge -p '{"spec":{"replicas":5}}'

Or edit the Cluster resource:

Discovery Buffering

Mon, 01 Jan 0001 00:00:00 +0000

Overview

The target discovery subsystem uses Go channels to communicate between message senders (API server and target loader) and the receiver (message processor). Two parameters control how discovery messages are batched and buffered in the channel, directly affecting throughput, latency, and resource consumption.

Parameters

Discovery Chunk Size

Flag: --discovery-chunk-size
Helm Value: discovery.chunkSize
Type: Integer
Default: 100

What it does: The maximum number of targets/events bundled into a single discovery message before sending to the channel buffer.

Operator Resources

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Scaling covers sizing the gNMIc collector pods. This page is about the operator pod itself — how much memory it needs, why that is not driven by target count alone, and the two settings that matter most as a deployment grows.

The short version: the operator’s memory is dominated by what it caches, not by how many targets it manages. Restricting the cache with --watch-namespaces is the single largest reduction available.

TLS Configuration

Mon, 01 Jan 0001 00:00:00 +0000

The gNMIc Operator supports multiple TLS configurations for different communication paths:

TLS Type	Config Location	Purpose
API TLS	`cluster.spec.api.tls`	Operator ↔ gNMIc pod REST API
Client TLS	`cluster.spec.clientTLS`	gNMIc pod → Network target gNMI
Tunnel TLS	`cluster.spec.grpcTunnel.tls`	Network device → gNMIc pod tunnel

API TLS (Operator ↔ Pods)

This TLS configuration secures the REST API communication between the operator controller and gNMIc collector pods.

Overview

When TLS is enabled:

Server TLS: Each gNMIc pod presents a certificate to the operator
Client TLS (mTLS): The operator presents a certificate to gNMIc pods
Certificate Verification: Both sides verify the other’s certificate

Prerequisites

cert-manager must be installed in your cluster:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml

A CA Issuer must be configured in the gNMIc cluster’s namespace

Quick Start

Assuming the gNMIc cluster will be created in the default namespace. Start by preparing an Issuer to secure the Cluster’s REST API.