Nacos 2.3.0 正式版发布、 Nacos Controller 项目开源

新版本发布

Nacos 2.3.0-BETA版本经过1个多月的社区测试,修复了部分的问题并对部分新功能的使用进行了少量优化后,于2023年12月7日正式发布。

Nacos 2.3.0版本基于2.3.0-BETA 版本为基础,主要进行了如下更新:

  • 基于能力协商机制,支持通过Grpc的方式进行持久化服务实例的注册及删除。
  • Console UI中显示更多内容,例如部署模式等。
  • 参数校验功能的实现方式进行优化。
  • TopN指标的实现进行重构,优化准确性和内存消耗。

详细的更新日志请查看:

## 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] Handling 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 fix avoid conflict.
[#11396] Upgrade jackson same with spring boot dependency.
[#11439] Upgrade some UI component to solve security problem.

Nacos Controller 项目开源

在云原生下,应用代码与运行环境可以通过Helm或Kustomize等软件进行交付、维护、CICD,但应用的Nacos配置依然需要手工地迁移、或使用控制台修改发布配置。借助于Nacos Controller项目,我们可以将Nacos配置管理下移到Kubernetes集群中,又或是可以将Kubernetes中ConfigMap配置上移到Nacos控制台中,从而实现统一管理能力。

Nacos配置下移到Kubernetes集群中

工作机制

Nacos Controller监听集群内的DC资源,当DC资源发生变化时,Nacos Controller将其中的配置内容同步到Nacos Server中。

controller1.jpeg

简易Demo

在Nacos Controller中,我们定义了一份CRD:DynamicConfiguration(简称DC),我们将Nacos配置保存在ConfigMap中,对配置的任何修改都通过DC将其中的配置同步到对应的Nacos服务端中。在后续的配置维护中,直接修改对应的ConfigMap即可。以下是一份简易的Demo示例:

apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: dc-demo-cluster2server
spec:
  dataIds:
  - data-id1.properties
  - data-id2.yml
  nacosServer:
    endpoint: <your-nacos-server-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>

Kubernetes配置上移到Nacos控制台

工作机制

首先需要用户创建DC资源指定需要同步哪些DataId,Nacos Controller根据读取到的DC配置,选择性监听Nacos Server中的相关配置并将配置改动同步到Kubernetes集群中。

controller2.jpeg

简易Demo

云原生下,应用除了需要加载Nacos配置外,还可能依赖一些环境变量,比如JVM参数通过环境变量注入。做得比较好的方式是通过ConfigMap等Kubernetes原生方式管理配置,通过引用的方式传递给应用Pod。在Nacos Controller中,我们可以定义一份DC,将Nacos服务端中的某些DataId同步到Kubernetes集群中的ConfigMap中,从而实现配置的统一管理。以下是一份示例Demo:

apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: dc-demo-server2cluster
spec:
  dataIds:
  - APP1_JVM_PARAMS
  - APP2_JVM_PARAMS
  nacosServer:
    endpoint: <your-nacos-server-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>

云原生下的配置管理最佳实践

在使用Kubernetes的场景下,一个微服务应用的配置被分割成两部份,一部分存放管理在Kubernetes集群中的Secret或ConfigMap中,另一部份存放管理与Nacos配置中心。对于运维人员,我们需要知道哪些配置是存放在何处且同时需要对两个平台的配置管理操作均有所了解,一来是增加了运维人员的知识门槛,二来是增加了应用配置运维的操作成本。通过Nacos Controller项目,我们将应用的所有配置集中于一处管理,降低应用配置运维的门槛与复杂性。

controller3.jpeg

面向Kubernetes运维偏好的用户

通过Nacos Controller项目,我们将应用与应用配置的交付和维护集中在Kubernetes集群中。

controller4.jpeg

以下通过一份Helm应用Chart包说明如何集中管理。

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

以上是一份Chart包目录结构,其中conf目录存放的是Nacos配置,文件名即DataId,文件内容即对应的Content。在templates/dc.yaml中,我们定义一份ConfigMap来组装这些配置。templates目录中的consumer.yaml与provider.yaml分别是应用定义。

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 }}

使用上述方式定义好应用与配置后,可以借助git实现应用、配置的版本管理。当需要发布应用或配置时,修改对应文件后,执行helm upgrade命令即可。

面向Nacos运维偏好的用户

Nacos配置管理能力使得应用可以动态调整运行配置,但对于一些特殊的参数,如JVM参数、特殊环境变量、特殊目录文件等内容,Nacos配置管理依然无法涵盖。在Kubernetes集群中,我们一般将环境变量或一些特殊文件配置写入ConfigMap中,通过envFrom能力将内容引用到环境变量中或者volumeMount挂载到文件系统中。这样的配置管理能力与Nacos配置管理能力是散开的,不利于统一管理。借助于Nacos Controller,我们将这些配置上移到Nacos控制台中,进行统一管理。

controller5.jpeg

以下是一份Demo应用,通过Nacos控制台管理JVM启动参数

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: demo-app
        image: openjdk:8 #替换为你的应用镜像
        command: ["/bin/sh", "-c", "java -jar ${JVM_PARAMS} /app.jar"]
        env:
        - name: JVM_PARAMS # 从ConfigMap中载入JVM参数到环境变量中
          valueFrom:
            configMapKeyRef:
              name: nacos-config
              key: APP1_JVM_PARAMS

---
apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: nacos-config
spec:
  dataIds:
  - APP1_JVM_PARAMS
  - APP2_JVM_PARAMS
  nacosServer:
    endpoint: <your-nacos-server-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>

在Nacos控制台中,修改DataId:APP1_JVM_PARAMS后,配置将自动同步到集群的ConfigMap中。只需重启相关应用,则对应的JVM参数将自动变化。成功实现将应用的所有配置集中管理在Nacos上。

Nacos 社区新晋Committer

社区中新增了2位Committer KarsontoDaydreamer-ia 。同时,Nacos社区又迎来了一位来自开源之夏的Committer同学Daydreamer-ia

陶健敏- 人物海报.jpg 陈亿钦-人物海报.jpg

展望

2.X 后续计划

从2021年3月 2.0.0正式版发布至今,2.X版本已经走了接近2年时间,如今2.3.0版本发布,完成了大部分功能的插件化提炼,在之后的2.3.X版本中,会主要对当前版本的问题进行修复,并做出小范围的功能优化。同时对于2.4.0版本,会作为一个Nacos3.0的过度版本,对大量代码进行优化重构,在提升稳定性、健壮性的同时,提升易用性和可观测性,向Nacos3.0版本平稳过度。

3.0 计划

Nacos社区同时也开启了关于Nacos3.0 的畅想和规划,Nacos将会从统一控制面、支持国产化、存储计算分离等方向进一步演进Nacos的功能和架构,欢迎社区积极参与到新版本的建设中。

image.png

image.png

About Nacos

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

最后欢迎大家扫码加入Nacos社区群

image.png