Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Evolution of Nacos in the Cloud-native Architecture

Evolution of Nacos in the Cloud-native Architecture

The article describes the evolution of Nacos and introduces Nacos Controller project as a bridge between Nacos and Kubernetes.

By Zhiwei

Background

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.

1

Bridging Nacos and Kubernetes

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.

2

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.

The Application Configuration Carrier for Crossing the Bridge

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.

3

Synchronize Configurations to Nacos Server

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.

4

Synchronize Configurations to Kubernetes

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.

5

Efficient O&M of Microservices Applications in Cloud-native Scenarios

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.

6

Future Planning

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.

7

EDAS Architecture Microservices O&M Open Source Kubernetes Enterprise Distributed Application Service cloud native Nacos
0 1 0
Share on

Read previous post:

Accelerating Image Generation in Stable Diffusion with TensorRT and Alibaba Cloud ACK

Read next post:

Best Practice for Gaming Gateway of Higress × OpenKruiseGame

Alibaba Cloud Native Community

481 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

481 posts | 48 followers

Related Products

  • Bastionhost

    A unified, efficient, and secure platform that provides cloud-based O&M, access control, and operation audit.

    Learn More

  • Managed Service for Grafana

    Managed Service for Grafana displays a large amount of data in real time to provide an overview of business and O&M monitoring.

    Learn More

  • Microservices Engine (MSE)

    MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.

    Learn More

  • EDAS

    A PaaS platform for a variety of application deployment options and microservices solutions to help you monitor, diagnose, operate and maintain your applications

    Learn More

More Posts by Alibaba Cloud Native Community

See All