Changes to asm_umn from docs/doc-exports#1347 (ASM UMN update 20241012

ASM UMN

Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com>
Co-authored-by: proposalbot <proposalbot@otc-service.com>
Co-committed-by: proposalbot <proposalbot@otc-service.com>

umn/source/best_practices/how_do_i_create_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled.rst

@@ -2,8 +2,8 @@
 
 .. _asm_bestpractice_1009:
 
-Creating a Service Mesh with IPv4/IPv6 Dual Stack Enabled
+How Do I Create a Service Mesh with IPv4/IPv6 Dual Stack Enabled
-=========================================================
+================================================================
 
 You can create a CCE cluster with IPv4/IPv6 dual stack enabled and enable IPv4/IPv6 dual stack for the service mesh that the cluster is added to. IPv4/IPv6 dual stack allows services in the service mesh to use both IPv4 and IPv6 addresses for service-to-service interactions. After an IPv4/IPv6 dual-stack gateway is added for the service mesh, you can provide services for users using an IPv6 client. This section describes how you can create a service mesh with IPv4/IPv6 dual stack, so that services in the service mesh can communicate with each other using IPv6 addresses.
 
@@ -16,7 +16,7 @@ Application Scenarios
 Constraints
 -----------
 
--  Constraints on enabling IPv4/IPv6 dual stack for a service mesh
+-  Conditions for enabling IPv4/IPv6 dual stack for a service mesh
 
 +----------------------+---------------+--------------------+--------------------------+--------------------------------------------+
 | Service Mesh Edition | Istio Version | Cluster Type       | Cluster Network Type     | Remarks                                    |
@@ -24,7 +24,7 @@ Constraints
 | Basic                | 1.18 or later | CCE Turbo clusters | Cloud native network 2.0 | IPv6 needs to be enabled for the clusters. |
 +----------------------+---------------+--------------------+--------------------------+--------------------------------------------+
 
--  Constraints on creating an IPv4/IPv6 dual-stack gateway
+-  Conditions for creating an IPv4/IPv6 dual-stack gateway
 
 +----------------------+---------------+--------------------+----------------------------------+----------------------------------------+
 | Service Mesh Edition | Istio Version | Load Balancer Type | Load Balancer Specification      | Remarks                                |
@@ -32,8 +32,10 @@ Constraints
 | Basic                | 1.18 or later | Dedicated          | Network load balancing (Layer 4) | The load balancer has an IPv6 address. |
 +----------------------+---------------+--------------------+----------------------------------+----------------------------------------+
 
+-  **Enable IPv6** is only available in Basic service meshes based on Istio 1.18 or later.
+
 -  IPv4/IPv6 dual stack cannot be disabled once it is enabled for a service mesh. IPv4/IPv6 dual stack cannot be enabled for an existing service mesh.
--  IPv4/IPv6 dual stack is only available for service meshes of v1.18 or later, but it cannot be enabled for a service mesh that is upgraded to v1.18 or later.
+-  IPv4/IPv6 dual stack cannot be enabled for a service mesh whose Istio version is upgraded to 1.18 or later.
 
 Creating a Service Mesh with IPv6 Addresses
 -------------------------------------------

umn/source/best_practices/index.rst

@@ -7,7 +7,7 @@ Best Practices
 
 -  :ref:`Upgrading Data Plane Sidecars Without Service Interruption <asm_bestpractice_0003>`
 -  :ref:`Service Governance for Dubbo-based Applications <asm_bestpractice_3001>`
--  :ref:`Creating a Service Mesh with IPv4/IPv6 Dual Stack Enabled <asm_bestpractice_1009>`
+-  :ref:`How Do I Create a Service Mesh with IPv4/IPv6 Dual Stack Enabled <asm_bestpractice_1009>`
 
 .. toctree::
    :maxdepth: 1
@@ -15,4 +15,4 @@ Best Practices
 
    upgrading_data_plane_sidecars_without_service_interruption
    service_governance_for_dubbo-based_applications/index
-   creating_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled
+   how_do_i_create_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled

umn/source/change_history.rst

@@ -0,0 +1,24 @@
+:original_name: asm_his_0001.html
+
+.. _asm_his_0001:
+
+Change History
+==============
+
+.. table:: **Table 1** Change history
+
+   +-----------------------------------+--------------------------------------------------------------+
+   | Released On                       | Description                                                  |
+   +===================================+==============================================================+
+   | 2024-10-12                        | -  The following are modifications based on review comments: |
+   |                                   |                                                              |
+   |                                   |    - Added the "Upgrades" chapter.                           |
+   |                                   |                                                              |
+   |                                   |    - Updated the infographic of ASM.                         |
+   |                                   |                                                              |
+   |                                   |    - Optimized other problems.                               |
+   |                                   |                                                              |
+   |                                   |    - Added the change history.                               |
+   +-----------------------------------+--------------------------------------------------------------+
+   | 2024-04-25                        | -  First release.                                            |
+   +-----------------------------------+--------------------------------------------------------------+

umn/source/faqs/index.rst

@@ -9,6 +9,7 @@ FAQs
 -  :ref:`Mesh Management <asm_faq_0019>`
 -  :ref:`Adding a Service <asm_faq_0001>`
 -  :ref:`Performing Grayscale Release <asm_faq_0006>`
+-  :ref:`Monitoring Traffic <asm_faq_0014>`
 
 .. toctree::
    :maxdepth: 1
@@ -18,3 +19,4 @@ FAQs
    mesh_management/index
    adding_a_service/index
    performing_grayscale_release/index
+   monitoring_traffic/index

umn/source/faqs/mesh_management/how_do_i_disable_sidecar_injection_for_workloads.rst

@@ -5,13 +5,17 @@
 How Do I Disable Sidecar Injection for Workloads?
 =================================================
 
-After sidecar injection is enabled for a namespace of a cluster, sidecars are automatically injected for pods of all workloads in the namespace. You can configure sidecars not to be injected into some workloads:
+If sidecar injection is enabled for a namespace of a cluster, sidecars are automatically injected for the pods of all workloads in the namespace. To prevent sidecars from being injected for some workloads, perform the following operations:
 
-#. Log in to the CCE console and click the cluster name to go to the cluster console. Then, choose **Workloads** > **Deployments**.
+#. Log in to the CCE console and click the cluster name to go to the cluster console. In the navigation pane, choose **Workloads**. Then, click the **Deployments** tab.
 
 #. Locate the workload and click **Edit YAML** in the **Operation** column.
 
-#. Find the **spec.template.metadata.annotations** field and add **sidecar.istio.io/inject: 'false'**.
+#. Locate the target field based on the service mesh version and add **sidecar.istio.io/inject: 'false'**.
+
+   -  For service meshes earlier than 1.13
+
+      Locate the **spec.template.metadata.annotations** field and add **sidecar.istio.io/inject: 'false'**.
 
       .. code-block::
 
@@ -20,6 +24,18 @@ After sidecar injection is enabled for a namespace of a cluster, sidecars are au
 
       |image1|
 
+   -  For service meshes 1.13 or later:
+
+      Locate the **spec.template.metadata.label** field and add **sidecar.istio.io/inject: 'false'**.
+
+      .. code-block::
+
+               label:
+                 sidecar.istio.io/inject: 'false'
+
+      |image2|
+
    For more details about sidecar injection, see `Automatic Sidecar Injection <https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#controlling-the-injection-policy>`__.
 
 .. |image1| image:: /_static/images/en-us_image_0000001223579300.png
+.. |image2| image:: /_static/images/en-us_image_0000001997321585.png

umn/source/faqs/mesh_management/how_do_i_handle_a_canary_upgrade_failure.rst

@@ -9,7 +9,7 @@ There are many reasons for a canary upgrade failure. In case of a canary upgrade
 
 #. Failed to check custom resource definitions (CRDs) before the upgrade.
 
-   **Solution**: New Istio version does not support some CRDs, including clusterrbacconfigs, serviceroles, servicerolebindings, and policies. If there are resources to be discarded in the current version, delete them before the upgrade.
+   **Solution**: New Istio version does not support some CRDs, including ClusterRbacConfigs, ServiceRoles, ServiceRoleBindings, and Policies. If there are resources to be discarded in the current version, delete them before the upgrade.
 
 #. Failed to check Istio gateway labels before the upgrade.
 
@@ -31,11 +31,11 @@ There are many reasons for a canary upgrade failure. In case of a canary upgrade
 
    **Solution**: Use the cluster version listed in the following table.
 
-   ============ =========================
+   ==================== ==========================
-   Mesh Version Supported Cluster Version
+   Service Mesh Version Supported Cluster Version
-   1.15         1.21,1.23,1.25,1.27
+   1.15                 1.21, 1.23, 1.25, and 1.27
-   1.18         1.25,1.27,1.28,1.29
+   1.18                 1.25,1.27, and 1.28
-   ============ =========================
+   ==================== ==========================
 
 #. Failed to check the component affinity before the upgrade.
 
@@ -64,4 +64,4 @@ There are many reasons for a canary upgrade failure. In case of a canary upgrade
 
 #. Failed to check the automatic namespace injection before the upgrade.
 
-   **Solution:** If there are pods in the namespace when you migrate mesh data from the Dedicated edition to the Basic edition, enable automatic injection for the namespace.
+   **Solution:** If there are pods in the namespace when you migrate service mesh data from the Dedicated edition to the Basic edition, enable automatic injection for the namespace.

umn/source/faqs/mesh_management/index.rst

@@ -5,7 +5,7 @@
 Mesh Management
 ===============
 
--  :ref:`Why Cannot I Create a Mesh for My Cluster? <asm_faq_0020>`
+-  :ref:`Why Cannot I Create a Service Mesh for My Cluster? <asm_faq_0020>`
 -  :ref:`Why Are Exclusive Nodes Still Exist After Istio Is Uninstalled? <asm_faq_0022>`
 -  :ref:`How Do I Enable Namespace Injection for a Cluster? <asm_faq_0036>`
 -  :ref:`How Do I Disable Sidecar Injection for Workloads? <asm_faq_0037>`
@@ -16,7 +16,7 @@ Mesh Management
    :maxdepth: 1
    :hidden: 
 
-   why_cannot_i_create_a_mesh_for_my_cluster
+   why_cannot_i_create_a_service_mesh_for_my_cluster
    why_are_exclusive_nodes_still_exist_after_istio_is_uninstalled
    how_do_i_enable_namespace_injection_for_a_cluster
    how_do_i_disable_sidecar_injection_for_workloads

umn/source/faqs/mesh_management/why_cannot_i_create_a_mesh_for_my_cluster.rst

@@ -1,22 +0,0 @@
-:original_name: asm_faq_0020.html
-
-.. _asm_faq_0020:
-
-Why Cannot I Create a Mesh for My Cluster?
-==========================================
-
-Symptom
--------
-
-I cannot create a mesh for my cluster.
-
-Analysis
---------
-
-Currently, clusters of versions earlier than 1.15 cannot be managed by meshes.
-
-Solution
---------
-
-#. Check the cluster version. Currently, only clusters of v1.15, v1.17, or v1.19 can be managed by meshes.
-#. Check your browser. Chrome is recommended. The button for mesh creation may be unavailable when you are using other browsers, such as Firefox, due to adaptation problems.

umn/source/faqs/mesh_management/why_cannot_i_create_a_service_mesh_for_my_cluster.rst

@@ -0,0 +1,22 @@
+:original_name: asm_faq_0020.html
+
+.. _asm_faq_0020:
+
+Why Cannot I Create a Service Mesh for My Cluster?
+==================================================
+
+Symptom
+-------
+
+I cannot create a service mesh for my cluster.
+
+Analysis
+--------
+
+Currently, clusters earlier than v1.21 cannot be managed by service meshes.
+
+Solution
+--------
+
+#. Check the cluster version. Currently, only clusters v1.21 or later can be managed by service meshes.
+#. Check your browser. Chrome is recommended. The button for service mesh creation may be unavailable when you are using other browsers, such as Firefox, due to adaptation problems.

umn/source/faqs/monitoring_traffic/index.rst

@@ -0,0 +1,24 @@
+:original_name: asm_faq_0014.html
+
+.. _asm_faq_0014:
+
+Monitoring Traffic
+==================
+
+-  :ref:`Why Cannot I View Traffic Monitoring Data Immediately After a Pod Is Started? <asm_faq_0015>`
+-  :ref:`Why Are the Latency Statistics on the Dashboard Page Inaccurate? <asm_faq_0016>`
+-  :ref:`Why Is the Traffic Ratio Inconsistent with That in the Traffic Monitoring Chart? <asm_faq_0017>`
+-  :ref:`Why Can't I Find Certain Error Requests in Tracing? <asm_faq_0018>`
+-  :ref:`Why Cannot I Find My Service in the Traffic Monitoring Topology? <asm_faq_0023>`
+-  :ref:`How Do I Connect a Service Mesh to Jaeger or Zipkin for Viewing Traces? <asm_faq_0049>`
+
+.. toctree::
+   :maxdepth: 1
+   :hidden: 
+
+   why_cannot_i_view_traffic_monitoring_data_immediately_after_a_pod_is_started
+   why_are_the_latency_statistics_on_the_dashboard_page_inaccurate
+   why_is_the_traffic_ratio_inconsistent_with_that_in_the_traffic_monitoring_chart
+   why_cant_i_find_certain_error_requests_in_tracing
+   why_cannot_i_find_my_service_in_the_traffic_monitoring_topology
+   how_do_i_connect_a_service_mesh_to_jaeger_or_zipkin_for_viewing_traces

umn/source/faqs/monitoring_traffic/why_are_the_latency_statistics_on_the_dashboard_page_inaccurate.rst

@@ -0,0 +1,8 @@
+:original_name: asm_faq_0016.html
+
+.. _asm_faq_0016:
+
+Why Are the Latency Statistics on the Dashboard Page Inaccurate?
+================================================================
+
+The latency statistics displayed on the **Dashboard** page are data of the services that have the highest latency among all the services in all the clusters of your account within the last one minute. Therefore, ensure that the service has been accessed within the last one minute.

umn/source/faqs/monitoring_traffic/why_cannot_i_find_my_service_in_the_traffic_monitoring_topology.rst

@@ -0,0 +1,10 @@
+:original_name: asm_faq_0023.html
+
+.. _asm_faq_0023:
+
+Why Cannot I Find My Service in the Traffic Monitoring Topology?
+================================================================
+
+#. Select a mesh, cluster, and namespace to monitor service traffic.
+#. Check whether the ICAgent collector is correctly installed in the cluster.
+#. Check whether the service has been added to the service mesh.

umn/source/faqs/monitoring_traffic/why_cannot_i_view_traffic_monitoring_data_immediately_after_a_pod_is_started.rst

@@ -0,0 +1,9 @@
+:original_name: asm_faq_0015.html
+
+.. _asm_faq_0015:
+
+Why Cannot I View Traffic Monitoring Data Immediately After a Pod Is Started?
+=============================================================================
+
+#. Check whether APM has been enabled for the cluster.
+#. Traffic monitoring aggregates the collected data. Please wait for a minute for the data to be displayed on the **Traffic Monitoring** page.

umn/source/faqs/monitoring_traffic/why_cant_i_find_certain_error_requests_in_tracing.rst

@@ -0,0 +1,8 @@
+:original_name: asm_faq_0018.html
+
+.. _asm_faq_0018:
+
+Why Can't I Find Certain Error Requests in Tracing?
+===================================================
+
+For performance purposes, the sampling rate of tracing is 10%. That is, 10 of your 100 requests are recorded and displayed on the page.

umn/source/faqs/monitoring_traffic/why_is_the_traffic_ratio_inconsistent_with_that_in_the_traffic_monitoring_chart.rst

@@ -0,0 +1,8 @@
+:original_name: asm_faq_0017.html
+
+.. _asm_faq_0017:
+
+Why Is the Traffic Ratio Inconsistent with That in the Traffic Monitoring Chart?
+================================================================================
+
+The traffic ratio data is polled every 10 seconds, while the traffic monitoring data shows the traffic situation of the last 10 seconds.

umn/source/faqs/service_mesh_cluster/index.rst

@@ -5,12 +5,12 @@
 Service Mesh Cluster
 ====================
 
--  :ref:`Why Does a Service Mesh Remain in the Installing Status for a Long Time After I Enable It for a Cluster? <asm_faq_0030>`
+-  :ref:`Why Does a Service Mesh Remain in the Installing State for a Long Time After I Enable It for a Cluster? <asm_faq_0030>`
--  :ref:`Why Does a Service Mesh Remain in the Unready Status for a Long Time After I Uninstall It? <asm_faq_0031>`
+-  :ref:`Why Does a Service Mesh Remain in the Unready State for a Long Time After I Uninstall It? <asm_faq_0031>`
 
 .. toctree::
    :maxdepth: 1
    :hidden: 
 
-   why_does_a_service_mesh_remain_in_the_installing_status_for_a_long_time_after_i_enable_it_for_a_cluster
+   why_does_a_service_mesh_remain_in_the_installing_state_for_a_long_time_after_i_enable_it_for_a_cluster
-   why_does_a_service_mesh_remain_in_the_unready_status_for_a_long_time_after_i_uninstall_it
+   why_does_a_service_mesh_remain_in_the_unready_state_for_a_long_time_after_i_uninstall_it

umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_installing_state_for_a_long_time_after_i_enable_it_for_a_cluster.rst

@@ -2,13 +2,13 @@
 
 .. _asm_faq_0030:
 
-Why Does a Service Mesh Remain in the Installing Status for a Long Time After I Enable It for a Cluster?
+Why Does a Service Mesh Remain in the Installing State for a Long Time After I Enable It for a Cluster?
-========================================================================================================
+=======================================================================================================
 
 Symptom
 -------
 
-After I create a service mesh (that is, create a Dedicated mesh) for a CCE cluster, the mesh remains in the installing status for a long time and a message is displayed, indicating that the user security group rules are successfully enabled.
+After I create a service mesh (that is, create a Dedicated service mesh) for a CCE cluster, it remains in the installing state for a long time and a message is displayed indicating that the user security group rules are successfully enabled.
 
 Fault Diagnosis
 ---------------
@@ -23,4 +23,4 @@ Residual **istio-system** namespaces exist.
 Solution
 --------
 
-Delete the residual **istio-system** namespaces and install the mesh again.
+Delete the residual **istio-system** namespaces and install the service mesh again.

umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_unready_state_for_a_long_time_after_i_uninstall_it.rst

@@ -2,18 +2,18 @@
 
 .. _asm_faq_0031:
 
-Why Does a Service Mesh Remain in the Unready Status for a Long Time After I Uninstall It?
+Why Does a Service Mesh Remain in the Unready State for a Long Time After I Uninstall It?
-==========================================================================================
+=========================================================================================
 
 Symptom
 -------
 
-On the ASM console, after I uninstall a service mesh, the mesh remains in the unready status for a long time.
+On the ASM console, after I uninstall a service mesh, it remains in the unready state for a long time.
 
 Fault Diagnosis
 ---------------
 
-#. Log in to the CCE console. Click the cluster name to go to the cluster console. In the navigation pane on the left, choose **App Templates**.
+#. Log in to the CCE console. Click the cluster name to go to the cluster console. In the navigation pane, choose **App Templates**.
 
 #. Click **Releases** and select the target cluster from the drop-down list. Check the releases and the latest events about uninstallation failure.
 
@@ -44,4 +44,4 @@ Solution
       kubectl delete crd -n istio-system `kubectl get crd -n istio-system | grep istio | awk '{print $1}'`
       kubectl delete mutatingwebhookconfigurations -n istio-system `kubectl get mutatingwebhookconfigurations -n istio-system | grep istio | awk '{print $1}'`
 
-#. Log in to the ASM console and uninstall the mesh again.
+#. Log in to the ASM console and uninstall the service mesh again.

umn/source/index.rst

@@ -10,3 +10,4 @@ Application Service Mesh - User Guide
    user_guide/index
    best_practices/index
    faqs/index
+   change_history

umn/source/service_overview/infographic_for_asm.rst

@@ -7,4 +7,4 @@ Infographic for ASM
 
 |image1|
 
-.. |image1| image:: /_static/images/en-us_image_0000001918938240.png
+.. |image1| image:: /_static/images/en-us_image_0000002043652974.png

umn/source/user_guide/creating_a_service_mesh/index.rst

@@ -5,7 +5,7 @@
 Creating a Service Mesh
 =======================
 
--  :ref:`Creating a Service Mesh <asm_01_0020>`
+-  :ref:`Creating a Service Mesh <asm_01_0084>`
 
 .. toctree::
    :maxdepth: 1

umn/source/user_guide/gateway_management/adding_a_gateway.rst

@@ -33,9 +33,9 @@ Procedure
 
    -  **Load Balancer**
 
-      -  Gateways use shared load balancers of ELB for the access over both public and private IPv4 networks.
+      -  Gateways use shared and dedicated load balancers of ELB for the access over both public and private IPv4 networks.
 
-   -  **Listener**
+   -  **Access Entry**
 
       Gateways configure a listener for the load balancer, which listens to requests from the load balancer and distributes traffic.
 

umn/source/user_guide/gateway_management/adding_a_route.rst

@@ -5,8 +5,8 @@
 Adding a Route
 ==============
 
-Scenario
+Scenarios
---------
+---------
 
 You can add multiple routes and configure multiple forwarding policies for a created gateway.
 

umn/source/user_guide/mesh_configuration/index.rst

@@ -8,7 +8,7 @@ Mesh Configuration
 -  :ref:`Overview <asm_01_0039>`
 -  :ref:`Sidecar Management <asm_01_0041>`
 -  :ref:`Istio Resource Management <asm_01_0091>`
--  :ref:`Service Mesh Extension <asm_01_0123>`
+-  :ref:`Upgrades <asm_01_0082>`
 
 .. toctree::
    :maxdepth: 1
@@ -17,4 +17,4 @@ Mesh Configuration
    overview
    sidecar_management
    istio_resource_management/index
-   service_mesh_extension
+   upgrades/index

umn/source/user_guide/mesh_configuration/overview.rst

@@ -15,4 +15,4 @@ The functions of each tab page in **Mesh Configuration** are as follows:
 -  **Sidecar Management**: You can view information about all workloads injected with sidecars, perform sidecar injection, and configure sidecar resource limits. For details, see :ref:`Sidecar Management <asm_01_0041>`.
 -  **Istio Resource Management**: You can view all Istio resources (such as VirtualService and DestinationRule), create Istio resources in YAML or JSON format, and modify existing Istio resources. For details, see :ref:`Istio Resource Management <asm_01_0091>`.
 -  **Upgrade**: You can upgrade the version of a service mesh.
--  Mesh extension: provides the observability configuration. For details, see :ref:`Service Mesh Extension <asm_01_0123>`.
+-  **Extensions**: provides the observability configuration.

umn/source/user_guide/mesh_configuration/service_mesh_extension.rst

@@ -1,33 +0,0 @@
-:original_name: asm_01_0123.html
-
-.. _asm_01_0123:
-
-Service Mesh Extension
-======================
-
-Observability configuration includes access logs, application metrics, and traces of the current service mesh. You can enable application metric collection and access logging.
-
-.. note::
-
-   Tracing can be enabled only when a service mesh is created.
-
-Constraints
------------
-
-Only Istio 1.18 or later can work with LTS to collect and store access logs. To enable access logging, install CCE Log-Agent on the **Add-ons** page in advance.
-
-Enabling Application Metrics
-----------------------------
-
-#. Log in to the ASM console.
-#. Click the name of the service mesh to go to its details page.
-#. In the navigation pane, choose **Mesh Configuration**. Then click the tab for displaying service mesh extension.
-#. Enable application metrics, select an AOM instance, and click **OK**.
-
-Enabling Access Logging
------------------------
-
-#. Log in to the ASM console.
-#. Click the name of the service mesh to go to its details page.
-#. In the navigation pane, choose **Mesh Configuration**. Then click the tab for displaying service mesh extension.
-#. Enable access logging, select the log group and log stream, and click **OK**.

umn/source/user_guide/mesh_configuration/upgrades/features_in_v1.15.rst

@@ -0,0 +1,13 @@
+:original_name: asm_01_0095.html
+
+.. _asm_01_0095:
+
+Features in v1.15
+=================
+
+-  Istio 1.15.7 is supported.
+-  CCE Turbo clusters v1.21, v1.23, v1.25, and v1.27 are supported.
+-  CCE clusters v1.21, v1.23, v1.25, and v1.27 are supported.
+-  Security vulnerabilities such as CVE-2023-44487, CVE-2023-39325 and CVE-2023-27487 are fixed.
+
+For details, visit https://istio.io/latest/news/releases/1.15.x/announcing-1.15.7/.

umn/source/user_guide/mesh_configuration/upgrades/features_in_v1.18.rst

@@ -0,0 +1,13 @@
+:original_name: asm_01_0124.html
+
+.. _asm_01_0124:
+
+Features in v1.18
+=================
+
+-  Istio 1.18 is supported.
+-  CCE Turbo clusters v1.25, v1.27, and v1.28 are supported.
+-  CCE clusters v1.25, v1.27, and v1.28 are supported.
+-  Kubernetes Gateway API is supported.
+
+For details, visit https://istio.io/latest/news/releases/1.18.x/.

umn/source/user_guide/mesh_configuration/upgrades/index.rst

@@ -0,0 +1,16 @@
+:original_name: asm_01_0082.html
+
+.. _asm_01_0082:
+
+Upgrades
+========
+
+-  :ref:`Features in v1.15 <asm_01_0095>`
+-  :ref:`Features in v1.18 <asm_01_0124>`
+
+.. toctree::
+   :maxdepth: 1
+   :hidden: 
+
+   features_in_v1.15
+   features_in_v1.18

umn/source/user_guide/mesh_management/index.rst

@@ -5,12 +5,12 @@
 Mesh Management
 ===============
 
--  :ref:`Mesh Events <asm_01_0133>`
+-  :ref:`Service Mesh Events <asm_01_0133>`
--  :ref:`Uninstalling a Mesh <asm_01_0086>`
+-  :ref:`Uninstalling a Service Mesh <asm_01_0086>`
 
 .. toctree::
    :maxdepth: 1
    :hidden: 
 
-   mesh_events
+   service_mesh_events
-   uninstalling_a_mesh
+   uninstalling_a_service_mesh

umn/source/user_guide/mesh_management/mesh_events.rst

@@ -1,23 +0,0 @@
-:original_name: asm_01_0133.html
-
-.. _asm_01_0133:
-
-Mesh Events
-===========
-
-Scenario
---------
-
-ASM supports the event center, which allows you to query details about important operations such as mesh creation and deletion and gateway creation and deletion.
-
-.. note::
-
-   You can view events in a mesh of the Basic edition (1.15 or later).
-
-Procedure
----------
-
-#. Log in to the ASM console and search for the mesh of the Basic edition by edition.
-#. Click |image1| in the upper right corner. In the window that slides out from the right, view mesh events.
-
-.. |image1| image:: /_static/images/en-us_image_0000001698197390.png

umn/source/user_guide/mesh_management/service_mesh_events.rst

@@ -0,0 +1,23 @@
+:original_name: asm_01_0133.html
+
+.. _asm_01_0133:
+
+Service Mesh Events
+===================
+
+Scenarios
+---------
+
+ASM supports the event center, which allows you to query details about important operations such as service mesh creation and deletion and gateway creation and deletion.
+
+.. note::
+
+   You can view events in a Basic service mesh (based on Istio 1.15 or later).
+
+Procedure
+---------
+
+#. Log in to the ASM console and search for the Basic service mesh by edition.
+#. Click |image1| in the upper right corner. In the window that slides out from the right, view service mesh events.
+
+.. |image1| image:: /_static/images/en-us_image_0000001698197390.png

umn/source/user_guide/mesh_management/uninstalling_a_service_mesh.rst

@@ -2,18 +2,18 @@
 
 .. _asm_01_0086:
 
-Uninstalling a Mesh
+Uninstalling a Service Mesh
-===================
+===========================
 
-Scenario
+Scenarios
---------
+---------
 
-When a mesh is no longer needed, you can uninstall it.
+If you no longer need a service mesh, you can uninstall it.
 
 Constraints
 -----------
 
--  To uninstall a mesh in which a grayscale release task is running, you need to complete the grayscale release first.
+-  To uninstall a service mesh in which a grayscale release task is running, you need to complete the grayscale release first.
 -  You need to ensure available nodes exist in the clusters for running the cleanup task to avoid uninstallation failure.
 
 Procedure
@@ -21,7 +21,7 @@ Procedure
 
 #. Log in to the ASM console.
 
-#. Click |image1| in the target mesh.
+#. Click |image1| in the service mesh.
 
 #. On the dialogue box displayed, select whether to restart existing services and read the precautions.
 
@@ -31,13 +31,13 @@ Procedure
 
       You are advised to restart existing services to avoid the following exceptions: If the cluster enables the current mesh again after it is uninstalled, gateway access failed.
 
-   -  Uninstalling a mesh will uninstall its control plane components and data plane sidecars.
+   -  Uninstalling a service mesh will uninstall its control plane components and data plane sidecars.
 
    -  After the uninstallation, service gateways of applications cannot be used. Configure Services for external access to applications.
 
       To update the external access mode, log in to the CCE console and click the cluster name to go to the cluster console. Then, choose **Services & Ingresses** > **Services**.
 
-   -  Uninstalling a mesh will delete the labels of the mesh exclusive nodes, but the Istio-master node will not be automatically deleted. You can delete it on the CCE console.
+   -  Uninstalling a service mesh will delete the labels of the Istio exclusive nodes, but the Istio-master node will not be automatically deleted. You can delete it on the CCE console.
 
       To view node information, log in to the CCE console and click the cluster name to go to the cluster console. In the navigation pane on the left, choose **Nodes** > **Nodes**.
 

umn/source/user_guide/security/authenticating_jwt_requests_on_the_ingress_gateway_using_asm.rst

@@ -10,7 +10,7 @@ This section describes how to authenticate JWT requests on the ingress gateway u
 Preparations
 ------------
 
-#. A mesh of version 1.15 or 1.18 has been created.
+#. A service mesh of version 1.15 or 1.18 has been created.
 #. The **httpbin** service that passes the diagnosis exists in the mesh. The image is **httpbin**, the port protocol is **HTTP**, and the port number is **80**.
 #. An accessible gateway has been created for the **httpbin** service in the mesh.
 
@@ -143,4 +143,4 @@ Checking Whether JWT Authentication Takes Effect
          server: istio-envoy
          x-envoy-upstream-service-time: 6
 
-   According to the preceding outputs, the request with the correct JWT token can access the service, and the request with an incorrect JWT token or without a JWT token cannot access the service, which indicate that the request identity authentication takes effect.
+   According to the preceding outputs, the request with the correct JWT token can access the service, and the request with an incorrect JWT token or without a JWT token cannot access the service. This means the request identity authentication takes effect.

umn/source/user_guide/service_management/auto_fixing_items/the_service_port_name_complies_with_the_istio_specifications.rst

@@ -21,9 +21,9 @@ If the Service port name is invalid, this item is abnormal.
 Rectification Guide
 -------------------
 
-#. Log in to the CCE console.
+#. Log in to the CCE console and click the cluster name to go to the cluster console.
 
-#. Click the cluster name to go to the cluster console. In the navigation pane on the left, choose **Services & Ingresses**. On the **Services** tab, search for the Service by cluster name and namespace and click **Edit YAML**. Then, view the Service protocol and add a protocol type before the service name.
+#. In the navigation pane, choose **Services & Ingresses**. Click the **Service** tab, search for the Service by cluster name and namespace, and click **Edit YAML**. Then, view the Service protocol and add a protocol type before the Service name.
 
    |image1|
 

umn/source/user_guide/service_management/auto_fixing_items/the_service_selector_cannot_contain_version_labels.rst

@@ -13,9 +13,9 @@ The **spec.selector** of a Service cannot be labeled with **version**. Otherwise
 Rectification Guide
 -------------------
 
-#. Log in to the CCE console.
+#. Log in to the CCE console and click the cluster name to go to the cluster console.
 
-#. Click the cluster name to go to the cluster console. In the navigation pane on the left, choose **Services & Ingresses**. On the **Services** tab, search for the Service by cluster name and namespace and click **Edit YAML**. Then, view the selector (specified by **spec.selector**) of the Service and delete the **version** label.
+#. In the navigation pane, choose **Services & Ingresses**. Click the **Service** tab, search for the Service by cluster name and namespace, click **Edit YAML**. Then, view **spec.selector** and delete the **version** label.
 
    |image1|
 

umn/source/user_guide/traffic_management/changing_a_traffic_policy.rst

@@ -5,8 +5,8 @@
 Changing a Traffic Policy
 =========================
 
-Scenario
+Scenarios
---------
+---------
 
 You can change the settings of a configured traffic policy. For example, you can change the load balancing algorithm from **Round robin** to **Random**.
 

umn/source/user_guide/traffic_management/configuring_a_traffic_policy.rst

@@ -22,7 +22,7 @@ Configuring a Traffic Policy
       +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Parameter         | Description                                                                                                                                                                                                                                                                                                                 | Value Range   |
       +===================+=============================================================================================================================================================================================================================================================================================================================+===============+
-      | Retries           | Maximum number of retries allowed for a single request. The default retry interval is 25 ms. The actual number of retries depends on the configured timeout period and retry timeout period.                                                                                                                                | 1-2147483647  |
+      | Retries           | Maximum number of retries allowed for a single request. The default retry interval is 25 ms. The actual number of retries depends on the configured timeout period and retry timeout period.                                                                                                                                | 1-4294967295  |
       +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Retry Timeout (s) | Timeout period of an initial or retry request. The default value is the same as the timeout period configured in the **Timeout** area below.                                                                                                                                                                                | 0.001-2592000 |
       +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
@@ -54,9 +54,9 @@ Configuring a Traffic Policy
       +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Parameter                       | Description                                                                                                                                                                               | Value Range   |
       +=================================+===========================================================================================================================================================================================+===============+
-      | Maximum Number of Connections   | Maximum number of HTTP/TCP connections to the target service. The default value is **4294967295**.                                                                                        | 1-2147483647  |
+      | Maximum Number of Connections   | Maximum number of HTTP/TCP connections to the target service. The default value is **4294967295**.                                                                                        | 1-4294967295  |
       +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
-      | Maximum Number of Non-responses | Maximum number of keepalive probes to be sent before the connection is determined to be invalid. By default, the OS-level configuration is used. (The default value is **9** for Linux.)  | 1-2147483647  |
+      | Maximum Number of Non-responses | Maximum number of keepalive probes to be sent before the connection is determined to be invalid. By default, the OS-level configuration is used. (The default value is **9** for Linux.)  | 1-4294967295  |
       +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Health Check Interval (s)       | Time interval between two keepalive probes. By default, the OS-level configuration is used. (The default value is **75** for Linux.)                                                      | 0.001-2592000 |
       +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
@@ -70,13 +70,13 @@ Configuring a Traffic Policy
       +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Parameter                                 | Description                                                                                                                                                                                                                | Value Range   |
       +===========================================+============================================================================================================================================================================================================================+===============+
-      | Maximum Number of Requests                | Maximum number of requests that can be forwarded to a single service pod. The default value is **4294967295**.                                                                                                             | 1-2147483647  |
+      | Maximum Number of Requests                | Maximum number of requests that can be forwarded to a single service pod. The default value is **4294967295**.                                                                                                             | 1-4294967295  |
       +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
-      | Maximum Number of Pending Requests        | Maximum number of HTTP requests that can be forwarded to the target service for processing. The default value is **4294967295**.                                                                                           | 1-2147483647  |
+      | Maximum Number of Pending Requests        | Maximum number of HTTP requests that can be forwarded to the target service for processing. The default value is **4294967295**.                                                                                           | 1-4294967295  |
       +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Maximum Connection Idle Period (s)        | Timeout period of an idle upstream service connection. If there is no active request within this time period, the connection will be closed. The default value is **3600** (1 hour).                                       | 0.001-2592000 |
       +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
-      | Maximum Retries                           | Maximum number of retries of all service pods within a specified period. The default value is **4294967295**.                                                                                                              | 1-2147483647  |
+      | Maximum Retries                           | Maximum number of retries of all service pods within a specified period. The default value is **4294967295**.                                                                                                              | 1-4294967295  |
       +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Maximum Number of Requests Per Connection | Maximum number of requests for each connection to the backend. If this parameter is set to **1**, the keepalive function is disabled. The default value is **0**, indicating infinite. The maximum value is **536870912**. | 1-536870912   |
       +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
@@ -94,7 +94,7 @@ Configuring a Traffic Policy
       +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Parameter                              | Description                                                                                                                                                                                                                                                 | Value Range   |
       +========================================+=============================================================================================================================================================================================================================================================+===============+
-      | Consecutive Errors                     | Number of consecutive errors in a specified time period. If the number of consecutive errors exceeds the parameter value, the pod will be ejected. The default value is **5**.                                                                              | 1-2147483647  |
+      | Consecutive Errors                     | Number of consecutive errors in a specified time period. If the number of consecutive errors exceeds the parameter value, the pod will be ejected. The default value is **5**.                                                                              | 1-4294967295  |
       +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+
       | Base Ejection Time (s)                 | Base ejection time of a service pod that meets the outlier detection conditions. The actual ejection time of a service pod = Base ejection time x Number of ejection times. The value must be greater than or equal to 0.001s. The default value is **30**. | 0.001-2592000 |
       +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+

umn/source/user_guide/traffic_management/index.rst

@@ -7,7 +7,6 @@ Traffic Management
 
 -  :ref:`Overview <asm_01_0049>`
 -  :ref:`Configuring a Traffic Policy <asm_01_0050>`
--  :ref:`Viewing Traffic Monitoring <asm_01_0051>`
 -  :ref:`Changing a Traffic Policy <asm_01_0052>`
 
 .. toctree::
@@ -16,5 +15,4 @@ Traffic Management
 
    overview
    configuring_a_traffic_policy
-   viewing_traffic_monitoring
    changing_a_traffic_policy

umn/source/user_guide/traffic_management/viewing_traffic_monitoring.rst

@@ -1,28 +0,0 @@
-:original_name: asm_01_0051.html
-
-.. _asm_01_0051:
-
-Viewing Traffic Monitoring
-==========================
-
-Scenario
---------
-
-In the traffic management window, you can view the traffic monitoring data of the last hour, including RPS, success rate, and request latency.
-
-Procedure
----------
-
-#. Log in to the ASM console and click the name of the target service mesh to go to its details page.
-
-#. In the navigation pane, choose **Service Management**. In the upper right corner of the list, select the namespace that your services belong to.
-
-#. Locate the target service and click **Manage Traffic** in the **Operation** column. In the window that slides out from the right, view the traffic monitoring data of the last hour.
-
-
-   .. figure:: /_static/images/en-us_image_0000001280416429.png
-      :alt: **Figure 1** Traffic monitoring
-
-      **Figure 1** Traffic monitoring
-
-#. After real-time monitoring is enabled, data is dynamically refreshed every minute.