作者:之卫
背景
Nacos 提供的最核心能力是动态服务发现与动态配置管理能力,在云原生环境下,借助云产品,如 EDAS(企业级分布式应用服务)平台中,我们可以很轻松地使用 K8s 来托管 Nacos 体系的微服务应用,同时又享有全链路流量治理、可观测、极致弹性等能力。
云原生下的应用由两个主要部分组成:不可变基础设施(代码、运行时)与配置。在这里配置是一个非常广泛的概念,它包含了运维配置(如副本数、发布策略、流量策略等),也包含了运行时配置(如环境变量、文件系统、运行时配置等)。通过 Kubernetes 提供的标准接口,我们可以很方便地修改上述配置。然而令人苦恼的是,Nacos 提供的配置管理能力,在当下却不能融入 Kubernetes 提供的标准接口中。
随之而来的头号问题: 应用交付需要分两步走,1. 发布 Nacos 配置,2. 发布应用。尤其是 Nacos 配置发布过程,依赖于用户编程对接 OpenAPI 或者人工登录控制台进行白屏操作。这里引入一个问题值得我们思考,运维接口不统一、不标准,使得应用生命周期管理有所割裂,进而带来运维效率降低、技术门槛拔高的成本问题。
Nacos 与 Kubernetes 的桥梁
归其根本,我们需要看清问题的本质。Nacos 项目所解决根本问题是微服务技术架构下,实现应用间的动态服务发现能力与应用配置管理能力。Kubernetes 平台所解决的问题是大规模应用集合的管理难题。因此,想要解决前面所述的问题,我们引入 NacosController 项目,它作为链接 Nacos 和 Kubernetes 的桥梁,通过 Kubernetes 运维接口管理 Nacos 能力。
项目地址:github.com/nacos-group…
当前 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 内容包含几个部份:
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 中,只有两处差别。
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 的技术架构图上,可以看出有三条主要变更渠道,可以根据运维偏好选择合适的变更方式。
下一步规划
当前 NacosController 项目已经初步实现了 DynamicConfiguration 概念,解决了 Nacos 核心能力之一的配置管理与 Kubernetes 融合问题。
下一步我们将围绕 Nacos 的另一个核心能力:服务动态发现,将其与 Kubernetes 进行融合,从而解除应用程序对于 Nacos SDK 的依赖,以及降低 Nacos 体系微服务应用与非 Nacos 体系应用间的调用门槛。