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.

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:

spec:
 replicas: 5 # Changed from 3

What Happens When You Scale

Scale Up ( 3 → 5 pods)

Kubernetes creates new pods (gnmic-3, gnmic-4).
Operator waits for pods to be ready.
Operator recomputes the distribution plan. Existing target assignments are preserved — only unassigned targets or targets displaced by capacity limits are placed on the new pods.
Configuration is applied to all pods.

Scale Down ( 5 → 3 pods)

Operator recomputes the distribution plan for the reduced replica count. Targets from removed pods flow through rendezvous hashing onto surviving pods, bounded by each pod’s capacity.
Configuration is applied to remaining pods.
Kubernetes terminates pods (gnmic-4, gnmic-3).

Target Redistribution

The operator uses bounded load rendezvous hashing to distribute targets. See Target Distribution for a detailed explanation of the algorithm.

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.

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.