Nacos 2.3.0 Boosts Cloud‑Native Config Management via gRPC and Kubernetes

Release Highlights of Nacos 2.3.0

Nacos 2.3.0 was released on 2023‑12‑07. The update builds on the 2.3.0‑BETA baseline and adds functional and performance improvements:

Persistent service‑instance registration and deregistration via gRPC using the capability‑negotiation mechanism.

Console UI now shows additional information such as deployment mode.

Refined parameter‑validation implementation.

Rewritten TopN metric logic to improve accuracy and reduce memory consumption.

## Feature
[#11393] Support register or deregister persistent instance by gRPC.

## Enhancement & Refactor
[#11275] Enhance console UI deploy, show more information like `mode`.
[#11298] Strip groupNamePrefix of instance serviceName at register or deregister.
[#11310] Simplify the validate method for serviceInfo.
[#11342] Simplify BatchDeregister instances conditions to ip and port.
[#11343] Simplified parameters checker control logic.
[#11352] Refactor TopN logic to enhance memory usage and accuracy.

## BugFix
[#10353] Handle DataIntegrityViolationException and DuplicateKeyException together.
[#11299] Fix console UI auth pagination failure.
[#11382] Fix console UI listening query pagination failure.
[#11384] Fix console UI comparing configuration failure.
[#11390] Fix Config EncryptionPluginService order problem.
[#11442] Fix listen configuration check failed without namespace.

## Dependency
[#11216] Declare httpcore as direct dependency to avoid conflict.
[#11396] Upgrade Jackson to match Spring Boot dependency.
[#11439] Upgrade UI components to resolve security issues.

Nacos Controller: Bridging Nacos and Kubernetes

The Nacos Controller is an open‑source Kubernetes controller that synchronizes Nacos configuration with Kubernetes resources. It watches custom resources of kind DynamicConfiguration (DC) and propagates changes either from Kubernetes ConfigMaps to Nacos or from Nacos to ConfigMaps, enabling unified configuration management.

Sync Nacos → Kubernetes

A DC resource lists the DataIds that should be stored in a ConfigMap. When the ConfigMap is edited, the controller pushes the changes to the Nacos server.

apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
  name: dc-demo-cluster2server
spec:
  dataIds:
  - data-id1.properties
  - data-id2.yml
  nacosServer:
    endpoint: YOUR_NACOS_ENDPOINT
    namespace: YOUR_NACOS_NAMESPACE_ID
    group: YOUR_NACOS_GROUP
    authRef:
      apiVersion: v1
      kind: Secret
      name: nacos-auth
  strategy:
    syncPolicy: Always
    syncDirection: cluster2server
    syncDeletion: true
  objectRef:
    apiVersion: v1
    kind: ConfigMap
    name: nacos-config-cm
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: nacos-config-cm
  namespace: default
data:
  data-id1.properties: |
    key=value
    key2=value2
  data-id2.yml: |
    app:
      name: test
---
apiVersion: v1
kind: Secret
metadata:
  name: nacos-auth
data:
  ak: BASE64_AK
  sk: BASE64_SK

Sync Kubernetes → Nacos

Conversely, a DC can pull DataIds from Nacos and write them into a ConfigMap, allowing Kubernetes workloads to consume Nacos‑managed configuration.

apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
  name: dc-demo-server2cluster
spec:
  dataIds:
  - APP1_JVM_PARAMS
  - APP2_JVM_PARAMS
  nacosServer:
    endpoint: YOUR_NACOS_ENDPOINT
    namespace: YOUR_NACOS_NAMESPACE_ID
    group: YOUR_NACOS_GROUP
    authRef:
      apiVersion: v1
      kind: Secret
      name: nacos-auth
  strategy:
    syncPolicy: Always
    syncDirection: server2cluster
    syncDeletion: true
---
apiVersion: v1
kind: Secret
metadata:
  name: nacos-auth
data:
  ak: BASE64_AK
  sk: BASE64_SK

Helm Chart Integration for Centralized Management

A sample Helm chart can package Nacos configuration files (DataIds) under conf/ and generate a ConfigMap that the controller consumes.

.
├── Chart.yaml
├── charts
├── conf
│   ├── application-dev.properties
│   ├── application.properties
│   ├── consumer-app.properties
│   └── provider-app.yaml
├── templates
│   ├── consumer.yaml
│   ├── dc.yaml
│   └── provider.yaml
└── values.yaml

The templates/dc.yaml creates a ConfigMap aggregating all files in conf/:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nacos-config
  namespace: {{ .Release.Namespace }}
data:
  {{- range $path, $_ := .Files.Glob "conf/**" }}
  {{ $path | base }}: |-
{{ $.Files.Get $path | indent 4}}
  {{- end }}

After committing the chart, a simple helm upgrade updates both application code and configuration.

Future Roadmap

Following the 2.3.0 release, the 2.3.X line will focus on bug fixes and minor enhancements. Version 2.4.0 is planned as a transitional release toward Nacos 3.0, featuring extensive code refactoring, stability improvements, better observability, and a smoother migration path. Long‑term plans for Nacos 3.0 include a unified control plane, support for domestic hardware ecosystems, and separation of storage and compute.

References

https://github.com/nacos-group/nacos-controller

https://github.com/karsonto

https://github.com/Daydreamer-ia