By Zhiwei
The core capabilities of Nacos are dynamic service discovery and dynamic configuration management. In cloud-native environments, we can easily use Kubernetes to host Nacos microservices applications with the help of cloud products such as Enterprise Distributed Application Service (EDAS). Nacos also provides end-to-end traffic governance, observability, and excellent elasticity.
Cloud-native applications consist of two main parts: immutable infrastructure (code and runtimes) and configuration. Configuration is a broad concept, encompassing O&M configurations (such as the number of replicas, release of policies, and traffic policies) as well as runtime configurations (such as environment variables, file systems, and runtime configurations). Through the standard interfaces provided by Kubernetes, we can easily modify these configurations. However, the configuration management capabilities provided by Nacos cannot be integrated with the standard interfaces provided by Kubernetes.
The initial problem is that application delivery requires two steps: 1) Publishing Nacos configurations, and 2) Publishing the application. In particular, the publishing of Nacos configurations requires users to program to connect to OpenAPI or log on to the console to perform GUI-based operations. This raises a significant issue: non-uniform and non-standardized O&M interfaces create a disjointed application lifecycle management, leading to lower O&M efficiency and higher technology requirements.
The Nacos project addresses the fundamental challenge of dynamic service discovery and application configuration management in a microservices architecture. Meanwhile, the Kubernetes platform solves the issue of centralized management for large-scale applications. To address the problem above, we introduce the Nacos Controller project as a bridge that connects Nacos and Kubernetes, allowing us to manage Nacos capabilities through Kubernetes O&M interfaces.
Project address: https://github.com/nacos-group/nacos-controller
At present, the Nacos Controller project has implemented the concept of Dynamic Configuration (DC). This enables us to define synchronization policies between Nacos configurations and Kubernetes configurations, and then use Kubernetes' standard O&M interfaces to manage Nacos configurations. Additionally, we can leverage this concept to use Nacos for managing common runtime configurations of applications, such as environment variables and file systems.
Through the Nacos Controller project, we have established a bridge connecting Nacos Server and Kubernetes, and have introduced the concept of Dynamic Configuration to address configuration management challenges. The DC concept encapsulates information about the location and content of the configuration, as well as where to synchronize it. With this concise DC resource, we can easily define various synchronization operations, such as syncing configurations from Kubernetes to Nacos Server or from Nacos Server to Kubernetes. Building on the DC concept, we have identified two main usage scenarios.
Let's first look at the definition of a DC. The following DC defines the synchronization of configurations from a Kubernetes cluster to Nacos Server. This DC resource contains several parts:
1) dataIds: Identifies the relevant DataIds.
2) nacosServer: Specifies the namespace and group of Nacos Server to which these configurations are synchronized, along with the essential information for accessing Nacos Server.
3) strategy: Outlines the preferred strategy for configuration synchronization.
4) objectRef: Serves as the data carrier for configurations.
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>
Through this simple and clear DC resource, we have established a connection between the ConfigMap in Kubernetes and the configuration management in Nacos. However, it is not limited to ConfigMap, as any Kubernetes resource can be used as a data carrier. Different data carriers have different usage scenarios within Kubernetes. For example, ConfigMap can be used as an environment variable or file system mounted to a Pod, while HashiCorp Vault enables configuration security encryption.
In this scenario, we have centralized the main configuration maintenance actions of microservices applications within Kubernetes. With the support of third-party tools, we can easily implement various features. For instance, by utilizing git, kubectl, and Jenkins, we can establish a configuration change pipeline with version control, permission control, and automatic update capabilities. Similarly, software like Helm and Kustomize can be leveraged to package application definitions and configurations for seamless delivery.
The configuration management actions of Nacos can be integrated with the Kubernetes interface through the DC concept, and the reverse operation is also realizable. The following DC resource defines the synchronization of configurations from Nacos to Kubernetes. Compared with synchronizing configurations from Kubernetes to Nacos, it has two different parameters.
1) spec.strategy.syncDirection: It indicates the synchronization direction of configurations.
2) spec.objectRef: When synchronizing configurations from Nacos to Kubernetes, if you do not specify a data carrier, a ConfigMap with the same name is used as the data carrier by default.
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>
In this way, we have unified the configuration management actions in Kubernetes to the Nacos Server side. Configurations in Kubernetes can also enjoy the features of Nacos, such as rich permission control and historical version tracing. But essentially, we have solved the problem of centralizing configuration management.
Alibaba Cloud EDAS, based on years of experience in cloud-based microservices application hosting, integrates service governance, observability, and elasticity capabilities to develop the concept of CloudApp. Currently, CloudApp has integrated the Dynamic Configuration concept and simplified the Nacos Server access configuration. Within the EDAS environment, all that is required to enable capabilities such as service governance and observability is to add a label to a Kubernetes native workload, such as a Deployment or a StatefulSet. The following is a simple Helm demo that requires no complicated concepts, allowing users to focus solely on the application. By leveraging the CloudApp concept, the technical barriers to implementing best practices for microservices applications are greatly reduced, and the O&M efficiency of microservices applications is significantly improved.
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: <ID of the EDAS microservices namespace>
group: <The configuration 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: tes
The technical architecture diagram of CloudApp shows three change methods. You can choose an appropriate one according to O&M preferences.
1) Method for white screen changes: Uses cloud product permissions to control changes and enjoys full application O&M capabilities.
2) Method 1 for black screen changes: Uses the Kubernetes RBAC permission system to control changes and enjoys full application O&M capabilities.
3) Method 2 for black screen changes: Focuses on the application and application runtime configuration and enjoys default application O&M capabilities (such as observability and graceful release) without introducing other concepts.
The current Nacos Controller project has made initial strides in implementing the Dynamic Configuration concept, resolving the integration challenge between the core capability of configuration management in Nacos and Kubernetes.
Our next step will revolve around another core capability of Nacos: dynamic service discovery, and integrate it with Kubernetes to eliminate the dependency of applications on the Nacos SDK and reduce the call threshold between Nacos microservices applications and non-Nacos applications.
Accelerating Image Generation in Stable Diffusion with TensorRT and Alibaba Cloud ACK
Best Practice for Gaming Gateway of Higress × OpenKruiseGame
495 posts | 48 followers
FollowAlibaba Cloud Native Community - September 12, 2023
Aliware - February 5, 2021
Alibaba Cloud Native Community - July 20, 2021
Alibaba Developer - February 4, 2021
Aliware - March 30, 2022
Alibaba Cloud Native Community - December 6, 2022
495 posts | 48 followers
FollowA unified, efficient, and secure platform that provides cloud-based O&M, access control, and operation audit.
Learn MoreManaged Service for Grafana displays a large amount of data in real time to provide an overview of business and O&M monitoring.
Learn MoreMSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn MoreA PaaS platform for a variety of application deployment options and microservices solutions to help you monitor, diagnose, operate and maintain your applications
Learn MoreMore Posts by Alibaba Cloud Native Community