背景

Nacos 提供的最核心能力是动态服务发现与动态配置管理能力，在云原生环境下，借助云产品，如 EDAS（企业级分布式应用服务）平台中，我们可以很轻松地使用 K8s 来托管 Nacos 体系的微服务应用，同时又享有全链路流量治理、可观测、极致弹性等能力。

云原生下的应用由两个主要部分组成：不可变基础设施（代码、运行时）与配置。在这里配置是一个非常广泛的概念，它包含了运维配置（如副本数、发布策略、流量策略等），也包含了运行时配置（如环境变量、文件系统、运行时配置等）。通过 Kubernetes 提供的标准接口，我们可以很方便地修改上述配置。然而令人苦恼的是，Nacos 提供的配置管理能力，在当下却不能融入 Kubernetes 提供的标准接口中。

随之而来的头号问题：应用交付需要分两步走，1. 发布 Nacos 配置，2. 发布应用。尤其是 Nacos 配置发布过程，依赖于用户编程对接 OpenAPI 或者人工登录控制台进行白屏操作。这里引入一个问题值得我们思考，运维接口不统一、不标准，使得应用生命周期管理有所割裂，进而带来运维效率降低、技术门槛拔高的成本问题。

Nacos 与 Kubernetes 的桥梁

归其根本，我们需要看清问题的本质。Nacos 项目所解决根本问题是微服务技术架构下，实现应用间的动态服务发现能力与应用配置管理能力。Kubernetes 平台所解决的问题是大规模应用集合的管理难题。因此，想要解决前面所述的问题，我们引入 NacosController 项目，它作为链接 Nacos 和 Kubernetes 的桥梁，通过 Kubernetes 运维接口管理 Nacos 能力。

项目地址： https://github.com/nacos-group/nacos-controller

当前 NacosController 项目已经实现了 DynamicConfiguration 概念（后文简称 DC）。通过这个概念，我们可以定义 Nacos 配置与 K8s 配置的同步策略，进而使用 Kubernetes 标准运维接口管理 Nacos 配置。当然，打开一下“脑洞”，我们也可以通过这个概念使用 Nacos 管理应用的常见运行时配置（如环境变量、文件系统）。

应用配置在桥梁中通行载体

通过 NacosController 项目，我们建立起了 NacosServer 与 Kubernetes 的桥梁，我们再引入 DynamicConfiguration 的概念用来解决配置管理的问题。DC 概念承载了从哪里找到配置以及内容，并将其同步到哪里去的信息，有了这样一份简洁明了的 DC 资源，我们可以很轻松地定义一些同步行为，如将 Kubernetes 中的配置同步到 NacosServer 中，又或是将 NacosServer 中的配置同步到 Kubernete 中。基于 DC 概念，我们凝练出两种主要使用场景。

将配置同步到 NacosServer 中

我们先看一份 DC 的定义，以下这份 DC 定义了将配置从 Kubernetes 集群中同步到 Nacos Server 去。这份 DC 内容包含几个部份：

1. dataIds：哪些 DataId 是我们关心的。
2. nacosServer：这些配置将被同步到 NacosServer 的哪个命名空间、分组，并且提供了 Nacos Server 的访问必要信息。
3. strategy：同步配置时的偏好策略。
4. objectRef：配置的数据载体。

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>

通过这样一份简单清晰的 DC 资源，我们将 Kubernetes 中的 ConfigMap 与 Nacos 中的配置管理建立了关系，当然设计之中并不局限于 ConfigMap，可以是任意的 Kubernetes 资源作为数据载体。不同的数据载体在 Kubernetes 侧有着不同的使用场景，如 ConfigMap 载体可以作为环境变量或文件系统挂在到 Pod 中，hashicorp vault 载体实现了配置安全加密等等。

在这样的场景下，我们成功将微服务应用的主要配置维护动作统一到了 Kubernetes 侧。借助一些三方工具，我们可以很轻易的搭建一些功能特性。比如基于 git、kubectl、jenkins，可以很方便的搭建一套带有版本控制、权限控制、自动化更新的配置变更流水线。又或是借助 helm、customize 等软件，我们可以将应用定义与应用配置真正打包在一起，实现一件交付。

将配置同步到 Kubernetes 中

既然 Nacos 配置的管理行为可以通过 DC 概念集成到 Kubernetes 接口中，那么反过来也是可以做到的。下面这份 DC 资源，定义了将 Nacos 中的配置同步到 Kubernetes 中。与上面定义将配置从 Kubernetes 同步到 Nacos 中，只有两处差别。

1. spec.strategy.syncDirection：这个配置表明了配置的同步方向。
2. spec.objectRef：从 Nacos 中将配置同步到 Kuberntes 中时，我们可以不指定数据载体，那么会默认使用一个同名的 ConfigMap 作为数据载体。

apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: dc-demo-server2cluster
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: server2cluster
    syncDeletion: true
---
apiVersion: v1
kind: Secret
metadata:
    name: nacos-auth
data:
    ak: <base64 ak>
    sk: <base64 sk>

如此一来，我们将 Kubernetes 中配置的管理行为统一到了 Nacos Server 侧。借助 Nacos 的特性能力，如丰富的权限控制、历史版本追溯等能力，对于 Kubernetes 中的配置也能享受到这些特性。当然本质上解决的还是将配置管理的集中在一处的问题。

云原生下高效运维微服务应用

阿里云的企业级分布式应用服务（EDAS）中，根据多年云上微服务应用托管经验，将服务治理、可观测、弹性等能力融合集成在一起，沉淀出 CloudApp 概念。当前 CloudApp 已经集成了 DynamicConfiguration 概念，并针对其中 nacosServer 访问配置做了简化。在 EDAS 环境中，只需要对 Kubernetes 原生 Workload（如 Deployment/StatefulSet）增加一个 label，即可自动启用服务治理、可观测等能力。以下是一份简单的 helm demo，对于用户而言，没有繁琐的各种概念入侵，只需要专注于应用本身。借助于 CloudApp 概念，极大地降低了微服务应用最佳实践的技术门槛，同时又极大地提升了微服务应用的运维效率。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app-1
  labels:
    edas.alibabacloud.com/app: demo-app-1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app-1
  template:
    metadata:
      labels:
        app: demo-app-1
    spec:
      containers:
      - name: main
        image: registry.cn-hangzhou.aliyuncs.com/edas-demo-project/consumer:1.0
---
apiVersion: nacos.io/v1
kind: DynamicConfiguration
metadata:
    name: for-app1
spec:
  dataIds:
  - data-id1.properties
  - data-id2.yml
  nacosServer:
    namespace: <EDAS 微服务空间ID>
    group: <配置分组>
  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

从 CloudApp 的技术架构图上，可以看出有三条主要变更渠道，可以根据运维偏好选择合适的变更方式。

1. 白屏变更：通过云产品权限控制变更，同时享受完整应用运维能力。
2. 黑屏变更途径 1：通过 Kubernetes RBAC 权限体系控制变更，同时享受完整应用运维能力。
3. 黑屏变更途径 2：只关心应用本身和应用运行时配置，在不引入其他认知概念的情况下，享有默认的应用运维能力（如可观测、无损发布等）。

下一步规划

当前 NacosController 项目已经初步实现了 DynamicConfiguration 概念，解决了 Nacos 核心能力之一的配置管理与 Kubernetes 融合问题。

下一步我们将围绕 Nacos 的另一个核心能力：服务动态发现，将其与 Kubernetes 进行融合，从而解除应用程序对于 Nacos SDK 的依赖，以及降低 Nacos 体系微服务应用与非 Nacos 体系应用间的调用门槛。

作者：之卫

原文链接

本文为阿里云原创内容，未经允许不得转载。