The NATS Kubernetes Operator lets you manage NATS clusters using Kubernetes custom resources, automating the deployment and lifecycle of NATS servers.
Let’s see it in action. Imagine you have a Kubernetes cluster and want to deploy a simple NATS service.
First, you need to install the operator itself. This typically involves applying a YAML manifest:
apiVersion: operators.coreos.com/v1
kind: Operator
metadata:
name: nats-operator
spec:
selector:
matchLabels:
app: nats-operator
# ... other operator configuration
Once the operator is running, you can define your NATS cluster using a NatsCluster custom resource. Here’s a minimal example for a single NATS server:
apiVersion:nats.io/v1alpha1
kind: NatsCluster
metadata:
name: my-nats-cluster
spec:
size: 1
version: "2.9.19"
clusterTokenSecret: my-cluster-token-secret
auth:
type: token
tokenSecret: my-auth-token-secret
When you apply this NatsCluster manifest, the operator watches for it. It then creates the necessary Kubernetes resources:
- StatefulSet: Manages the NATS server pods, ensuring they have stable network identities and storage.
- Services: Creates Kubernetes Services for clients to connect to the NATS cluster (e.g., a client service and a cluster-internal service).
- Secrets: If configured, it will create or reference secrets for authentication and cluster communication.
The spec.size field dictates how many NATS server pods will be launched. The spec.version specifies the exact NATS server image to use. The clusterTokenSecret is used for NATS internal cluster discovery and security, while auth.tokenSecret provides a token for external clients to authenticate.
The operator continuously monitors the NatsCluster resource and the actual state of the NATS pods. If a pod crashes, the operator restarts it. If you scale the cluster by changing spec.size, the operator will add or remove pods accordingly.
Here’s a more advanced NatsCluster configuration, demonstrating TLS and account-based authorization:
apiVersion:nats.io/v1alpha1
kind: NatsCluster
metadata:
name: my-secure-nats
spec:
size: 3
version: "2.9.19"
tls:
client:
secretName: nats-client-tls
operator:
secretName: nats-operator-tls
jetstream:
enabled: true
maxMemory: 256Mi
maxStore: 1Gi
auth:
type: nkey
nkeySecret: nats-nkey-secret
In this example, spec.tls instructs the operator to configure TLS for both client connections and inter-server communication, referencing Kubernetes secrets containing the necessary certificates. spec.jetstream enables NATS JetStream, the persistence layer for NATS, and sets resource limits. The auth.type: nkey and nkeySecret specify using NKEY authentication, which is a more robust cryptographic authentication mechanism than simple tokens.
The operator handles the complex configuration of NATS server command-line flags based on these spec fields. For instance, enabling TLS with specific secrets automatically adds the correct --tls and --tls_cert/--tls_key flags to the NATS server startup command. Similarly, JetStream configuration translates into flags like --jetstream, --max_memory, and --max_storage.
One subtle but powerful aspect is how the operator manages NATS cluster discovery and configuration updates. When you scale a cluster or change its configuration, the operator doesn’t just restart pods. It intelligently updates the NATS configuration files within the running containers, often allowing for rolling updates with minimal disruption. For example, when adding a new server to a cluster, the operator ensures that existing servers are aware of the new member, and the new member knows how to join the existing cluster, coordinating through the configured clusterTokenSecret or TLS certificates.
The next step after successfully deploying a NATS cluster is understanding how to connect to it from your applications and how to leverage JetStream for durable messaging.