diff --git a/umn/source/_static/images/en-us_image_0000001145684268.png b/umn/source/_static/images/en-us_image_0000001145684268.png new file mode 100644 index 0000000..f55564b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001145684268.png differ diff --git a/umn/source/_static/images/en-us_image_0000001181759886.png b/umn/source/_static/images/en-us_image_0000001181759886.png new file mode 100644 index 0000000..66d324e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001181759886.png differ diff --git a/umn/source/_static/images/en-us_image_0000001181766534.png b/umn/source/_static/images/en-us_image_0000001181766534.png new file mode 100644 index 0000000..957f2cd Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001181766534.png differ diff --git a/umn/source/_static/images/en-us_image_0000001191764069.png b/umn/source/_static/images/en-us_image_0000001191764069.png new file mode 100644 index 0000000..fa897f4 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001191764069.png differ diff --git a/umn/source/_static/images/en-us_image_0000001191923929.png b/umn/source/_static/images/en-us_image_0000001191923929.png new file mode 100644 index 0000000..fee3069 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001191923929.png differ diff --git a/umn/source/_static/images/en-us_image_0000001191923931.png b/umn/source/_static/images/en-us_image_0000001191923931.png new file mode 100644 index 0000000..c95fd47 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001191923931.png differ diff --git a/umn/source/_static/images/en-us_image_0000001200574170.png b/umn/source/_static/images/en-us_image_0000001200574170.png new file mode 100644 index 0000000..851bcbd Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001200574170.png differ diff --git a/umn/source/_static/images/en-us_image_0000001201276836.png b/umn/source/_static/images/en-us_image_0000001201276836.png new file mode 100644 index 0000000..0486a3d Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001201276836.png differ diff --git a/umn/source/_static/images/en-us_image_0000001201436796.png b/umn/source/_static/images/en-us_image_0000001201436796.png new file mode 100644 index 0000000..9bca8d2 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001201436796.png differ diff --git a/umn/source/_static/images/en-us_image_0000001202040720.png b/umn/source/_static/images/en-us_image_0000001202040720.png new file mode 100644 index 0000000..b2d63f1 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001202040720.png differ diff --git a/umn/source/_static/images/en-us_image_0000001202041610.png b/umn/source/_static/images/en-us_image_0000001202041610.png new file mode 100644 index 0000000..d57b988 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001202041610.png differ diff --git a/umn/source/_static/images/en-us_image_0000001202053160.png b/umn/source/_static/images/en-us_image_0000001202053160.png new file mode 100644 index 0000000..3107672 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001202053160.png differ diff --git a/umn/source/_static/images/en-us_image_0000001203040696.png b/umn/source/_static/images/en-us_image_0000001203040696.png new file mode 100644 index 0000000..81111ac Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001203040696.png differ diff --git a/umn/source/_static/images/en-us_image_0000001203053124.png b/umn/source/_static/images/en-us_image_0000001203053124.png new file mode 100644 index 0000000..81111ac Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001203053124.png differ diff --git a/umn/source/_static/images/en-us_image_0000001203333110.png b/umn/source/_static/images/en-us_image_0000001203333110.png new file mode 100644 index 0000000..66a0e82 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001203333110.png differ diff --git a/umn/source/_static/images/en-us_image_0000001209954130.png b/umn/source/_static/images/en-us_image_0000001209954130.png new file mode 100644 index 0000000..b0297df Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001209954130.png differ diff --git a/umn/source/_static/images/en-us_image_0000001209978068.png b/umn/source/_static/images/en-us_image_0000001209978068.png new file mode 100644 index 0000000..9471a92 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001209978068.png differ diff --git a/umn/source/_static/images/en-us_image_0000001210119300.png b/umn/source/_static/images/en-us_image_0000001210119300.png new file mode 100644 index 0000000..7aef441 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001210119300.png differ diff --git a/umn/source/_static/images/en-us_image_0000001210274518.png b/umn/source/_static/images/en-us_image_0000001210274518.png new file mode 100644 index 0000000..64d7d02 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001210274518.png differ diff --git a/umn/source/_static/images/en-us_image_0000001210438852.png b/umn/source/_static/images/en-us_image_0000001210438852.png new file mode 100644 index 0000000..09f5bbd Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001210438852.png differ diff --git a/umn/source/_static/images/en-us_image_0000001223579300.png b/umn/source/_static/images/en-us_image_0000001223579300.png new file mode 100644 index 0000000..73db337 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001223579300.png differ diff --git a/umn/source/_static/images/en-us_image_0000001227360319.png b/umn/source/_static/images/en-us_image_0000001227360319.png new file mode 100644 index 0000000..6a61f0b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001227360319.png differ diff --git a/umn/source/_static/images/en-us_image_0000001234294620.png b/umn/source/_static/images/en-us_image_0000001234294620.png new file mode 100644 index 0000000..3fb3f71 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001234294620.png differ diff --git a/umn/source/_static/images/en-us_image_0000001234454572.png b/umn/source/_static/images/en-us_image_0000001234454572.png new file mode 100644 index 0000000..3fb3f71 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001234454572.png differ diff --git a/umn/source/_static/images/en-us_image_0000001234614480.png b/umn/source/_static/images/en-us_image_0000001234614480.png new file mode 100644 index 0000000..3fb3f71 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001234614480.png differ diff --git a/umn/source/_static/images/en-us_image_0000001234773776.png b/umn/source/_static/images/en-us_image_0000001234773776.png new file mode 100644 index 0000000..3fb3f71 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001234773776.png differ diff --git a/umn/source/_static/images/en-us_image_0000001246196675.png b/umn/source/_static/images/en-us_image_0000001246196675.png new file mode 100644 index 0000000..ffa39d2 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001246196675.png differ diff --git a/umn/source/_static/images/en-us_image_0000001247200741.png b/umn/source/_static/images/en-us_image_0000001247200741.png new file mode 100644 index 0000000..4f3c0d6 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001247200741.png differ diff --git a/umn/source/_static/images/en-us_image_0000001247893125.png b/umn/source/_static/images/en-us_image_0000001247893125.png new file mode 100644 index 0000000..47bced6 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001247893125.png differ diff --git a/umn/source/_static/images/en-us_image_0000001254992703.png b/umn/source/_static/images/en-us_image_0000001254992703.png new file mode 100644 index 0000000..c5738f2 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001254992703.png differ diff --git a/umn/source/_static/images/en-us_image_0000001254992865.png b/umn/source/_static/images/en-us_image_0000001254992865.png new file mode 100644 index 0000000..128e3da Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001254992865.png differ diff --git a/umn/source/_static/images/en-us_image_0000001254994475.png b/umn/source/_static/images/en-us_image_0000001254994475.png new file mode 100644 index 0000000..bb49d5b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001254994475.png differ diff --git a/umn/source/_static/images/en-us_image_0000001254994843.png b/umn/source/_static/images/en-us_image_0000001254994843.png new file mode 100644 index 0000000..18e531d Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001254994843.png differ diff --git a/umn/source/_static/images/en-us_image_0000001255111219.png b/umn/source/_static/images/en-us_image_0000001255111219.png new file mode 100644 index 0000000..3d7f39b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001255111219.png differ diff --git a/umn/source/_static/images/en-us_image_0000001255345827.png b/umn/source/_static/images/en-us_image_0000001255345827.png new file mode 100644 index 0000000..5de8e4d Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001255345827.png differ diff --git a/umn/source/_static/images/en-us_image_0000001256463368.png b/umn/source/_static/images/en-us_image_0000001256463368.png new file mode 100644 index 0000000..31d0f6f Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001256463368.png differ diff --git a/umn/source/_static/images/en-us_image_0000001270399104.png b/umn/source/_static/images/en-us_image_0000001270399104.png new file mode 100644 index 0000000..da72036 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001270399104.png differ diff --git a/umn/source/_static/images/en-us_image_0000001278854949.png b/umn/source/_static/images/en-us_image_0000001278854949.png new file mode 100644 index 0000000..3fb3f71 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001278854949.png differ diff --git a/umn/source/_static/images/en-us_image_0000001279134173.png b/umn/source/_static/images/en-us_image_0000001279134173.png new file mode 100644 index 0000000..3fb3f71 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001279134173.png differ diff --git a/umn/source/_static/images/en-us_image_0000001280416429.png b/umn/source/_static/images/en-us_image_0000001280416429.png new file mode 100644 index 0000000..72f8c58 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001280416429.png differ diff --git a/umn/source/_static/images/en-us_image_0000001303344393.png b/umn/source/_static/images/en-us_image_0000001303344393.png new file mode 100644 index 0000000..7c92f92 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001303344393.png differ diff --git a/umn/source/_static/images/en-us_image_0000001321081541.png b/umn/source/_static/images/en-us_image_0000001321081541.png new file mode 100644 index 0000000..a4e5ace Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001321081541.png differ diff --git a/umn/source/_static/images/en-us_image_0000001344069664.png b/umn/source/_static/images/en-us_image_0000001344069664.png new file mode 100644 index 0000000..9933a9b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001344069664.png differ diff --git a/umn/source/_static/images/en-us_image_0000001374968509.png b/umn/source/_static/images/en-us_image_0000001374968509.png new file mode 100644 index 0000000..fd733dc Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001374968509.png differ diff --git a/umn/source/_static/images/en-us_image_0000001389665636.png b/umn/source/_static/images/en-us_image_0000001389665636.png new file mode 100644 index 0000000..ffb663f Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001389665636.png differ diff --git a/umn/source/_static/images/en-us_image_0000001394586873.png b/umn/source/_static/images/en-us_image_0000001394586873.png new file mode 100644 index 0000000..fa1353c Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001394586873.png differ diff --git a/umn/source/_static/images/en-us_image_0000001416062808.png b/umn/source/_static/images/en-us_image_0000001416062808.png new file mode 100644 index 0000000..7e78985 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001416062808.png differ diff --git a/umn/source/_static/images/en-us_image_0000001416065480.png b/umn/source/_static/images/en-us_image_0000001416065480.png new file mode 100644 index 0000000..0a7cb82 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001416065480.png differ diff --git a/umn/source/_static/images/en-us_image_0000001416224808.png b/umn/source/_static/images/en-us_image_0000001416224808.png new file mode 100644 index 0000000..873cc13 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001416224808.png differ diff --git a/umn/source/_static/images/en-us_image_0000001416387696.png b/umn/source/_static/images/en-us_image_0000001416387696.png new file mode 100644 index 0000000..bba3107 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001416387696.png differ diff --git a/umn/source/_static/images/en-us_image_0000001440024745.png b/umn/source/_static/images/en-us_image_0000001440024745.png new file mode 100644 index 0000000..e067a68 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001440024745.png differ diff --git a/umn/source/_static/images/en-us_image_0000001466625829.png b/umn/source/_static/images/en-us_image_0000001466625829.png new file mode 100644 index 0000000..2a8920c Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001466625829.png differ diff --git a/umn/source/_static/images/en-us_image_0000001476967692.png b/umn/source/_static/images/en-us_image_0000001476967692.png new file mode 100644 index 0000000..13e26ee Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001476967692.png differ diff --git a/umn/source/_static/images/en-us_image_0000001477127516.png b/umn/source/_static/images/en-us_image_0000001477127516.png new file mode 100644 index 0000000..13ea885 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001477127516.png differ diff --git a/umn/source/_static/images/en-us_image_0000001477287480.png b/umn/source/_static/images/en-us_image_0000001477287480.png new file mode 100644 index 0000000..54e103f Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001477287480.png differ diff --git a/umn/source/_static/images/en-us_image_0000001493677652.png b/umn/source/_static/images/en-us_image_0000001493677652.png new file mode 100644 index 0000000..d3c7dfa Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001493677652.png differ diff --git a/umn/source/_static/images/en-us_image_0000001494249996.png b/umn/source/_static/images/en-us_image_0000001494249996.png new file mode 100644 index 0000000..31d0f6f Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001494249996.png differ diff --git a/umn/source/_static/images/en-us_image_0000001527927469.png b/umn/source/_static/images/en-us_image_0000001527927469.png new file mode 100644 index 0000000..26904ec Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001527927469.png differ diff --git a/umn/source/_static/images/en-us_image_0000001528087425.png b/umn/source/_static/images/en-us_image_0000001528087425.png new file mode 100644 index 0000000..185d62d Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001528087425.png differ diff --git a/umn/source/_static/images/en-us_image_0000001698197390.png b/umn/source/_static/images/en-us_image_0000001698197390.png new file mode 100644 index 0000000..47c211b Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001698197390.png differ diff --git a/umn/source/_static/images/en-us_image_0000001741270036.png b/umn/source/_static/images/en-us_image_0000001741270036.png new file mode 100644 index 0000000..c156131 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001741270036.png differ diff --git a/umn/source/_static/images/en-us_image_0000001786644069.png b/umn/source/_static/images/en-us_image_0000001786644069.png new file mode 100644 index 0000000..55b6dce Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001786644069.png differ diff --git a/umn/source/_static/images/en-us_image_0000001918938240.png b/umn/source/_static/images/en-us_image_0000001918938240.png new file mode 100644 index 0000000..7a6220d Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001918938240.png differ diff --git a/umn/source/_static/images/en-us_image_0000001920032153.png b/umn/source/_static/images/en-us_image_0000001920032153.png new file mode 100644 index 0000000..dc18450 Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001920032153.png differ diff --git a/umn/source/_static/images/en-us_image_0000001930216052.png b/umn/source/_static/images/en-us_image_0000001930216052.png new file mode 100644 index 0000000..6fcac5e Binary files /dev/null and b/umn/source/_static/images/en-us_image_0000001930216052.png differ diff --git a/umn/source/best_practices/creating_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled.rst b/umn/source/best_practices/creating_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled.rst new file mode 100644 index 0000000..c084572 --- /dev/null +++ b/umn/source/best_practices/creating_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled.rst @@ -0,0 +1,80 @@ +:original_name: asm_bestpractice_1009.html + +.. _asm_bestpractice_1009: + +Creating 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. + +Application Scenarios +--------------------- + +- If an IPv6 address is required for service access and traffic management, you can enable IPv4/IPv6 dual stack. +- If you provide services for users who use IPv6 clients, you can create a gateway for a service mesh with IPv4/IPv6 dual stack enabled. + +Constraints +----------- + +- Constraints on enabling IPv4/IPv6 dual stack for a service mesh + ++----------------------+---------------+--------------------+--------------------------+--------------------------------------------+ +| Service Mesh Edition | Istio Version | Cluster Type | Cluster Network Type | Remarks | ++======================+===============+====================+==========================+============================================+ +| 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 + ++----------------------+---------------+--------------------+----------------------------------+----------------------------------------+ +| Service Mesh Edition | Istio Version | Load Balancer Type | Load Balancer Specification | Remarks | ++======================+===============+====================+==================================+========================================+ +| Basic | 1.18 or later | Dedicated | Network load balancing (Layer 4) | The load balancer has an IPv6 address. | ++----------------------+---------------+--------------------+----------------------------------+----------------------------------------+ + +- 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. + +Creating a Service Mesh with IPv6 Addresses +------------------------------------------- + +#. Log in to the ASM console, a service mesh, and configure the parameters as follows: + + - **Mesh Edition**: Select **Basic edition**. + - **Mesh Name**: Enter a service mesh name. + - **Istio Version**: Select 1.18 or later. + - **Enable IPv6**: If this option is enabled, CCE clusters that meet the conditions will be displayed. + + Configure other parameters based on site requirements. + +#. Click the service mesh name to access the details page. + + On the **Mesh Configuration** > **Basic Information** tab, you can see that IPv4/IPv6 dual stack has been enabled. + +Adding an IPv4/IPv6 Dual-Stack Gateway +-------------------------------------- + +#. Log in to the ASM console. On the service mesh list page, click the name of the service mesh with IPv4/IPv6 dual stack enabled. In the navigation pane, choose **Gateway Management**. Click **Add Gateway** and configure the parameters as follows: + + - **Access Mode**: Select IPv4/IPv6 dual stack. + - **Load Balancer**: Select **Dedicated**. The dedicated load balancer must have an IPv6 address. + + Configure other parameters based on site requirements. + + .. note:: + + If IPv4/IPv6 dual stack is enabled, only domain names are allowed to access the gateway. + +Verification +------------ + +#. Configure domain name resolution for the client, so that the domain name is mapped to the IPv6 address of the gateway. This way, the client can access the gateway using the domain name. + +|image1| + +2. View the IPv6 request information in the ingressgateway log. + +|image2| + +.. |image1| image:: /_static/images/en-us_image_0000001741270036.png +.. |image2| image:: /_static/images/en-us_image_0000001786644069.png diff --git a/umn/source/best_practices/index.rst b/umn/source/best_practices/index.rst new file mode 100644 index 0000000..78574df --- /dev/null +++ b/umn/source/best_practices/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_bp_0001.html + +.. _asm_bp_0001: + +Best Practices +============== + +- :ref:`Upgrading Data Plane Sidecars Without Service Interruption ` +- :ref:`Service Governance for Dubbo-based Applications ` +- :ref:`Creating a Service Mesh with IPv4/IPv6 Dual Stack Enabled ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + upgrading_data_plane_sidecars_without_service_interruption + service_governance_for_dubbo-based_applications/index + creating_a_service_mesh_with_ipv4_ipv6_dual_stack_enabled diff --git a/umn/source/best_practices/service_governance_for_dubbo-based_applications/index.rst b/umn/source/best_practices/service_governance_for_dubbo-based_applications/index.rst new file mode 100644 index 0000000..c1eb219 --- /dev/null +++ b/umn/source/best_practices/service_governance_for_dubbo-based_applications/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_bestpractice_3001.html + +.. _asm_bestpractice_3001: + +Service Governance for Dubbo-based Applications +=============================================== + +- :ref:`Introduction ` +- :ref:`Service Discovery Model ` +- :ref:`SDK Adaptation Mode ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + introduction + service_discovery_model + sdk_adaptation_mode/index diff --git a/umn/source/best_practices/service_governance_for_dubbo-based_applications/introduction.rst b/umn/source/best_practices/service_governance_for_dubbo-based_applications/introduction.rst new file mode 100644 index 0000000..2255aa9 --- /dev/null +++ b/umn/source/best_practices/service_governance_for_dubbo-based_applications/introduction.rst @@ -0,0 +1,13 @@ +:original_name: asm_bestpractice_3002.html + +.. _asm_bestpractice_3002: + +Introduction +============ + +Dubbo is a special protocol which needs the following supports: + +- Envoy on the service mesh data plane supports the parsing and traffic management of the Dubbo protocol. +- The mesh control plane supports the configuration of Dubbo governance rules to manage services such as grayscale release, load balancing, and access authorization. + +In addition, the service discovery model of Dubbo is different from that of Kubernetes and Spring Cloud. Therefore, additional processing is required. diff --git a/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/index.rst b/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/index.rst new file mode 100644 index 0000000..4939b62 --- /dev/null +++ b/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/index.rst @@ -0,0 +1,16 @@ +:original_name: asm_bestpractice_3003.html + +.. _asm_bestpractice_3003: + +SDK Adaptation Mode +=================== + +- :ref:`PASSTHROUGH Solution ` +- :ref:`Static Target Service ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + passthrough_solution + static_target_service diff --git a/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/passthrough_solution.rst b/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/passthrough_solution.rst new file mode 100644 index 0000000..58da56b --- /dev/null +++ b/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/passthrough_solution.rst @@ -0,0 +1,29 @@ +:original_name: asm_bestpractice_3004.html + +.. _asm_bestpractice_3004: + +PASSTHROUGH Solution +==================== + +Introduction +------------ + +When the client in the SDK calls the target service by an interface, the client accesses the service name, instead of the service instance. + +|image1| + +Description +----------- + +Cases are different based on the Dubbo protocol versions: + +- 2.7.4 and later versions: Cloud Native 2.7.4 and later versions have reconstructed the service discovery model which is consistent with that of Kubernetes. Service information can be directly obtained via interfaces. +- 2.7.3 and earlier versions: The Dubbo community versions do not provide the level-2 relationship between interfaces and services. The SDK needs to maintain the mapping from interfaces to services based on the actual usage mode. For example, information such as a service name may be provided in extended information during service registration. + +You can select a processing mode based on your SDK. The SDK of an earlier version can perform the following operations in the existing service registration and discovery processes: + +#. Extend the definition of **Service** in the registration information. During service deployment, service metadata can be injected into the SDK as environment variables, including **appname** and **namespace**, which indicate the name and namespace of the deployed service, respectively. +#. When the service is started, the relationship between the Dubbo interface and Kubernetes service name and namespace is registered in the Registry. +#. When a client initiates an access request, the service metadata is queried by the interface according to the original service discovery process, and the corresponding service information is used to assemble an RPC request. The extended field **Attachment** is advised to be used to store the **appname** and **namespace** information in the Dubbo request. + +.. |image1| image:: /_static/images/en-us_image_0000001181766534.png diff --git a/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/static_target_service.rst b/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/static_target_service.rst new file mode 100644 index 0000000..6d699ba --- /dev/null +++ b/umn/source/best_practices/service_governance_for_dubbo-based_applications/sdk_adaptation_mode/static_target_service.rst @@ -0,0 +1,31 @@ +:original_name: asm_bestpractice_3005.html + +.. _asm_bestpractice_3005: + +Static Target Service +===================== + +Introduction +------------ + +Use `dubbo:reference `__ to configure the referenced service provider in the service consumer of the Dubbo service. Use the **url** option to define the address of the point-to-point direct connection service provider to bypass the Registry and directly call the target service. + +Description +----------- + +If the original Dubbo service uses the **.xml** configuration file, only the configuration file needs to be modified. + +.. code-block:: + + + + + + + +If an annotation is used to define the referenced target service, only the annotation of the target service in the code needs to be modified. + +.. code-block:: + + @Reference(url = "dubbo://helloService:20880") + HelloService helloService; diff --git a/umn/source/best_practices/service_governance_for_dubbo-based_applications/service_discovery_model.rst b/umn/source/best_practices/service_governance_for_dubbo-based_applications/service_discovery_model.rst new file mode 100644 index 0000000..c8fce55 --- /dev/null +++ b/umn/source/best_practices/service_governance_for_dubbo-based_applications/service_discovery_model.rst @@ -0,0 +1,22 @@ +:original_name: asm_bestpractice_3008.html + +.. _asm_bestpractice_3008: + +Service Discovery Model +======================= + +Problems in the existing Dubbo model (summarized from the Dubbo community version 2.7.4): + +- In the microservice architecture, the Registry manages applications (services) instead of external service interfaces. However, the Dubbo Registry manages Dubbo service interfaces, contrary to the Spring Cloud or Cloud Native registration mode. +- A Dubbo application (service) allows N Dubbo service interfaces to be registered. The more interfaces, the heavier the load of the Registry. + +The existing Dubbo service model searches for service instances based on the Dubbo interface. + +|image1| + +The Dubbo Cloud Native service discovery model adds an app layer to search for instances. + +|image2| + +.. |image1| image:: /_static/images/en-us_image_0000001181759886.png +.. |image2| image:: /_static/images/en-us_image_0000001227360319.png diff --git a/umn/source/best_practices/upgrading_data_plane_sidecars_without_service_interruption.rst b/umn/source/best_practices/upgrading_data_plane_sidecars_without_service_interruption.rst new file mode 100644 index 0000000..756bb66 --- /dev/null +++ b/umn/source/best_practices/upgrading_data_plane_sidecars_without_service_interruption.rst @@ -0,0 +1,93 @@ +:original_name: asm_bestpractice_0003.html + +.. _asm_bestpractice_0003: + +Upgrading Data Plane Sidecars Without Service Interruption +========================================================== + +ASM enables you to manage the traffic of services added into a service mesh. Sidecars are important components in ASM data plane. The upgrade of sidecars involves the re-injection of sidecars into data plane service pods, which requires the pods to be updated. + +This section describes how to avoid service interruption during sidecar upgrade. + +Configuring the Number of Service Pods +-------------------------------------- + +Ensure that the number of service pods is greater than or equal to **2** and the upgrade policy is set to **RollingUpdate**. + +Sample configurations: + +**kubectl get deploy nginx -n** *namespace_name* **-oyaml \| grep strategy -a10** + +|image1| + +**Configuration description:** + +- Number of service pods: deployment.spec.replicas >= 2 +- Upgrade policy: deployment.spec.strategy.type == RollingUpdate +- Minimum number of alive pods in rolling upgrade: deployment.spec.replicas - deployment.spec.strategy.maxUnavailable > 0 + +Adding a Readiness Probe +------------------------ + +Readiness probes help you ensure that new service pods take over traffic only when they are ready. This prevents access failures caused by unready new pods. + +The configurations are as follows: + +**kubectl get deploy nginx -n** *namespace_name* **-oyaml \| grep readinessProbe -a10** + +|image2| + +**Configuration description:** + +Configuring a readiness probe: deployment.spec.template.spec.containers[i].readinessProbe + +The configuration includes the initial check time, check interval, and timeout duration. + +Setting the Service Ready Time +------------------------------ + +**minReadySeconds** is used to specify the minimum number of seconds for which a newly created pod should be ready without any of its containers crashing, for it to be considered available. + +The configurations are as follows: + +**kubectl get deploy nginx -n** *namespace_name* **-oyaml \| grep minReadySeconds -a1** + +|image3| + +**Configuration description:** + +The service ready time: deployment.spec.minReadySeconds. Configure this parameter based on the live environment. + +Configuring a Graceful Shutdown Time +------------------------------------ + +**terminationGracePeriodSeconds** is used to configure a graceful shutdown time. During a rolling upgrade, the endpoint of an old service pod is removed and the pod status is set to **Terminating**. A SIGTERM signal is then sent to the pod. After the graceful shutdown time you configured, the pod will be forcibly terminated. The graceful deletion time allows the pod to keep processing unfinished requests, if any, to avoid hard termination. + +**kubectl get deploy nginx -n** *namespace_name* **-oyaml \| grep terminationGracePeriodSeconds -a1** + +|image4| + +**Configuration description:** + +The graceful shutdown time: deployment.spec.template.spec.terminationGracePeriodSeconds. The default value is 30s. Configure this parameter based on the live environment. + +Configuring the preStop +----------------------- + +**preStop** enabled you to perform certain execution before a service pod is stopped. In this way, it helps you gracefully shut down a service pod. Configure this parameter based on service requirements. Nginx is used as an example here. + +**kubectl get deploy nginx -n** *namespace_name* **-oyaml \| grep lifec -a10** + +|image5| + +In the **lifecycle.preStop** field, the **nginx -s quit; sleep 10** command is defined. This command first sends a graceful shutdown signal to the Nginx process and then the pod termination pauses for 10 seconds. In this way, Nginx has enough time to complete the ongoing requests and gracefully close the pod before it terminates. + +**10** in **sleep 10** is an example value. You can change it based on the actual requirements and application performance. The key should be a proper value so that Nginx has enough time to gracefully shut down the process. + +Alternatively, you can run custom commands or scripts to gracefully shut down your service process. + +.. |image1| image:: /_static/images/en-us_image_0000001145684268.png +.. |image2| image:: /_static/images/en-us_image_0000001191764069.png +.. |image3| image:: /_static/images/en-us_image_0000001191923931.png +.. |image4| image:: /_static/images/en-us_image_0000001191923929.png +.. |image5| image:: /_static/images/en-us_image_0000001493677652.png diff --git a/umn/source/conf.py b/umn/source/conf.py old mode 100755 new mode 100644 index 98dbfbe..6a0f7ad --- a/umn/source/conf.py +++ b/umn/source/conf.py @@ -122,4 +122,5 @@ latex_documents = [ repo = Repo(search_parent_directories=True) commit = repo.head.commit current_commit_hash = commit.hexsha -current_commit_time = commit.committed_datetime.strftime('%Y-%m-%d %H:%M') \ No newline at end of file +current_commit_time = commit.committed_datetime.strftime('%Y-%m-%d %H:%M') + diff --git a/umn/source/docutils.conf b/umn/source/docutils.conf new file mode 100644 index 0000000..7cbe4c1 --- /dev/null +++ b/umn/source/docutils.conf @@ -0,0 +1,2 @@ +[html writers] +table-style: table, caption-top \ No newline at end of file diff --git a/umn/source/faqs/adding_a_service/index.rst b/umn/source/faqs/adding_a_service/index.rst new file mode 100644 index 0000000..79e0709 --- /dev/null +++ b/umn/source/faqs/adding_a_service/index.rst @@ -0,0 +1,20 @@ +:original_name: asm_faq_0001.html + +.. _asm_faq_0001: + +Adding a Service +================ + +- :ref:`What Do I Do If an Added Gateway Does Not Take Effect? ` +- :ref:`Why Does It Take a Long Time to Start the Demo Application in Experiencing Service Mesh in One Click? ` +- :ref:`Why Cannot I Access the page of the Demo Application After It Is Successfully Deployed? ` +- :ref:`Why Cannot I Select the Corresponding Service When Adding a Route? ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + what_do_i_do_if_an_added_gateway_does_not_take_effect + why_does_it_take_a_long_time_to_start_the_demo_application_in_experiencing_service_mesh_in_one_click + why_cannot_i_access_the_page_of_the_demo_application_after_it_is_successfully_deployed + why_cannot_i_select_the_corresponding_service_when_adding_a_route diff --git a/umn/source/faqs/adding_a_service/what_do_i_do_if_an_added_gateway_does_not_take_effect.rst b/umn/source/faqs/adding_a_service/what_do_i_do_if_an_added_gateway_does_not_take_effect.rst new file mode 100644 index 0000000..c37e590 --- /dev/null +++ b/umn/source/faqs/adding_a_service/what_do_i_do_if_an_added_gateway_does_not_take_effect.rst @@ -0,0 +1,13 @@ +:original_name: asm_faq_0003.html + +.. _asm_faq_0003: + +What Do I Do If an Added Gateway Does Not Take Effect? +====================================================== + +The possible cause is that the Gateway-related resource configurations are missing or incorrect. Do as follows to locate the fault: + +- Log in to the Elastic Load Balance console, check whether the external port and ECSs are successfully listened by the load balancer. +- Log in to the cluster and run the **kubectl get gateway -n istio-system** command to check whether the IP address, domain name, and port number are configured for the Gateway. Run the **kubectl get svc -n istio-system** command to check whether the ingress Gateway has the corresponding IP address and port and is not in the pending status. +- Check whether the internal access protocol of the service added to the service mesh is consistent with the external access protocol configured for the service's Gateway. +- If the **ERR_UNSAFE_PORT** error is displayed when you use a browser to access the service, that is because the port is identified as a dangerous port by the browser. In this case, you need to use another external port. diff --git a/umn/source/faqs/adding_a_service/why_cannot_i_access_the_page_of_the_demo_application_after_it_is_successfully_deployed.rst b/umn/source/faqs/adding_a_service/why_cannot_i_access_the_page_of_the_demo_application_after_it_is_successfully_deployed.rst new file mode 100644 index 0000000..7e5bd77 --- /dev/null +++ b/umn/source/faqs/adding_a_service/why_cannot_i_access_the_page_of_the_demo_application_after_it_is_successfully_deployed.rst @@ -0,0 +1,21 @@ +:original_name: asm_faq_0005.html + +.. _asm_faq_0005: + +Why Cannot I Access the page of the Demo Application After It Is Successfully Deployed? +======================================================================================= + +Symptom +------- + +The page of the demo application cannot be accessed after the application is successfully deployed. + +Analysis +-------- + +The load balancer configured for the application does not listen to the port. + +Solution +-------- + +Log in to the Elastic Load Balance console. Check whether the port listener has been created and whether the health status of the backend server is normal. diff --git a/umn/source/faqs/adding_a_service/why_cannot_i_select_the_corresponding_service_when_adding_a_route.rst b/umn/source/faqs/adding_a_service/why_cannot_i_select_the_corresponding_service_when_adding_a_route.rst new file mode 100644 index 0000000..3acb074 --- /dev/null +++ b/umn/source/faqs/adding_a_service/why_cannot_i_select_the_corresponding_service_when_adding_a_route.rst @@ -0,0 +1,14 @@ +:original_name: asm_faq_0035.html + +.. _asm_faq_0035: + +Why Cannot I Select the Corresponding Service When Adding a Route? +================================================================== + +During adding a route, the target service is filtered based on the corresponding gateway protocol. The filtering rules are as follows: + +- For an HTTP gateway, select an HTTP service. +- For a TCP gateway, select a TCP service. +- For a gRPC gateway, select a gRPC service. +- For an HTTPS gateway, select either an HTTP or a gRPC service. +- For a TLS gateway which TLS termination is enabled, select a TCP service. If TLS termination for a TLS gateway is disabled, select a TLS service. diff --git a/umn/source/faqs/adding_a_service/why_does_it_take_a_long_time_to_start_the_demo_application_in_experiencing_service_mesh_in_one_click.rst b/umn/source/faqs/adding_a_service/why_does_it_take_a_long_time_to_start_the_demo_application_in_experiencing_service_mesh_in_one_click.rst new file mode 100644 index 0000000..c27a8ae --- /dev/null +++ b/umn/source/faqs/adding_a_service/why_does_it_take_a_long_time_to_start_the_demo_application_in_experiencing_service_mesh_in_one_click.rst @@ -0,0 +1,8 @@ +:original_name: asm_faq_0004.html + +.. _asm_faq_0004: + +Why Does It Take a Long Time to Start the Demo Application in Experiencing Service Mesh in One Click? +===================================================================================================== + +The demo application contains the productpage, details, ratings, and reviews services. All related workloads and Istio resources including DestinationRule, VirtualService, and Gateway need to be created. Therefore, the creation takes a comparatively long time. diff --git a/umn/source/faqs/index.rst b/umn/source/faqs/index.rst new file mode 100644 index 0000000..0bd6be6 --- /dev/null +++ b/umn/source/faqs/index.rst @@ -0,0 +1,20 @@ +:original_name: asm_faq_0001_0.html + +.. _asm_faq_0001_0: + +FAQs +==== + +- :ref:`Service Mesh Cluster ` +- :ref:`Mesh Management ` +- :ref:`Adding a Service ` +- :ref:`Performing Grayscale Release ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + service_mesh_cluster/index + mesh_management/index + adding_a_service/index + performing_grayscale_release/index diff --git a/umn/source/faqs/mesh_management/how_do_i_disable_sidecar_injection_for_workloads.rst b/umn/source/faqs/mesh_management/how_do_i_disable_sidecar_injection_for_workloads.rst new file mode 100644 index 0000000..3e58573 --- /dev/null +++ b/umn/source/faqs/mesh_management/how_do_i_disable_sidecar_injection_for_workloads.rst @@ -0,0 +1,25 @@ +:original_name: asm_faq_0037.html + +.. _asm_faq_0037: + +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: + +#. Log in to the CCE console and click the cluster name to go to the cluster console. Then, choose **Workloads** > **Deployments**. + +#. 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'**. + + .. code-block:: + + annotations: + sidecar.istio.io/inject: 'false' + + |image1| + + For more details about sidecar injection, see `Automatic Sidecar Injection `__. + +.. |image1| image:: /_static/images/en-us_image_0000001223579300.png diff --git a/umn/source/faqs/mesh_management/how_do_i_enable_namespace_injection_for_a_cluster.rst b/umn/source/faqs/mesh_management/how_do_i_enable_namespace_injection_for_a_cluster.rst new file mode 100644 index 0000000..10f733b --- /dev/null +++ b/umn/source/faqs/mesh_management/how_do_i_enable_namespace_injection_for_a_cluster.rst @@ -0,0 +1,54 @@ +:original_name: asm_faq_0036.html + +.. _asm_faq_0036: + +How Do I Enable Namespace Injection for a Cluster? +================================================== + +When injecting a sidecar to the namespace of a cluster, if the namespace injection is not enabled in the cluster, perform the following steps: + +#. Connect to the cluster using kubectl. + +#. Run the **kubectl get iop -nistio-system** command to query iop resources. + + - If the following information is displayed, the iop resource exists. Go to :ref:`3 `. + + |image1| + + - If the following information is displayed, no iop resources exist. Go to :ref:`4 `. + + |image2| + +#. .. _asm_faq_0036__li202171822811: + + Run the **kubectl edit iop -nistio-system** *data-plane* command to modify the **autoInject** configuration item. In the preceding command, *data-plane* indicates the name of the iop resource queried in the previous step. Replace it with the actual value. + + .. code-block:: + + global: + defaultPodDisruptionBudget: + enabled: true + hub: *.*.*.*:20202/asm + logging: + level: default:info + meshID: test-payment + multiCluster: + clusterName: test-yy + network: test-yy-network + proxy: + autoInject: enabled + remotePilotAddress: *.*.*.* + tag: 1.8.6-r1-20220512225026 + +#. .. _asm_faq_0036__li797012579155: + + Run the **kubectl edit cm -nistio-system istio-sidecar-injector** command to modify the **istio-sidecar-injector** configuration item. + + .. code-block:: + + data: + config: |- + policy: enabled + +.. |image1| image:: /_static/images/en-us_image_0000001270399104.png +.. |image2| image:: /_static/images/en-us_image_0000001321081541.png diff --git a/umn/source/faqs/mesh_management/how_do_i_handle_a_canary_upgrade_failure.rst b/umn/source/faqs/mesh_management/how_do_i_handle_a_canary_upgrade_failure.rst new file mode 100644 index 0000000..9ed56af --- /dev/null +++ b/umn/source/faqs/mesh_management/how_do_i_handle_a_canary_upgrade_failure.rst @@ -0,0 +1,67 @@ +:original_name: asm_faq_0044.html + +.. _asm_faq_0044: + +How Do I Handle a Canary Upgrade Failure? +========================================= + +There are many reasons for a canary upgrade failure. In case of a canary upgrade failure, you can use the following solutions to handle it. + +#. 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. + +#. Failed to check Istio gateway labels before the upgrade. + + **Solution:** Configure Istio gateway labels (specified by **matchLabels**) in *{app: istio-ingressgateway, istio: ingressgateway}* format. + +#. Failed to check add-ons before the upgrade. + + **Solution:** ASM 1.8 and later versions do not support the tracing, kiali, grafana, and prometheus add-ons. Uninstall the add-ons before the upgrade. You can install open-source add-ons or use APM. + +#. Failed to check the cluster status before the upgrade. + + **Solution:** If the cluster is unavailable before the upgrade, do not perform the upgrade. + +#. Failed to query resources before the upgrade. + + **Solution:** Prepare the required resources for the canary upgrade. + +#. Failed to check the cluster version before the upgrade. + + **Solution**: Use the cluster version listed in the following table. + + ============ ========================= + Mesh Version Supported Cluster Version + 1.15 1.21,1.23,1.25,1.27 + 1.18 1.25,1.27,1.28,1.29 + ============ ========================= + +#. Failed to check the component affinity before the upgrade. + + **Solutions**: If you upgrade Istio from a non-canary version to a canary version, ensure that there are at least twice as many nodes labeled with **istio:master** as there are istiod instances, and at least twice as many schedulable nodes as there are istio-ingressgateway or istio-egressgateway instances (depending on which one is larger). If such conditions are not met, add nodes to meet the scheduling requirements or set the anti-affinity of istiod, istio-ingressgateway, and istio-egressgateway to **Preferred**. + + - Method 1: Add nodes labeled with **istio:master** on the CCE console. + + - **Solution 2**: Edit the YAML file to modify the anti-affinity policy on the CCE console. + + .. code-block:: + + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + podAffinityTerm: + labelSelector: + matchExpressions: + - key: app + operator: In + values: + - istiod (For the anti-affinity policy of istio-ingressgateway, replace the value of values with istio-ingressgateway. For the anti-affinity policy of istio-egressgateway, replace the value of values with istio-egressgateway.) + namespaces: + - istio-system + topologyKey: kubernetes.io/hostname + + Alternatively, change the anti-affinity from **Required** to **Preferred** on the CCE console. + +#. 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. diff --git a/umn/source/faqs/mesh_management/index.rst b/umn/source/faqs/mesh_management/index.rst new file mode 100644 index 0000000..e900405 --- /dev/null +++ b/umn/source/faqs/mesh_management/index.rst @@ -0,0 +1,24 @@ +:original_name: asm_faq_0019.html + +.. _asm_faq_0019: + +Mesh Management +=============== + +- :ref:`Why Cannot I Create a Mesh for My Cluster? ` +- :ref:`Why Are Exclusive Nodes Still Exist After Istio Is Uninstalled? ` +- :ref:`How Do I Enable Namespace Injection for a Cluster? ` +- :ref:`How Do I Disable Sidecar Injection for Workloads? ` +- :ref:`What Can I Do If A Pod Cannot Be Started Due to Unready Sidecar ` +- :ref:`How Do I Handle a Canary Upgrade Failure? ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + why_cannot_i_create_a_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 + what_can_i_do_if_a_pod_cannot_be_started_due_to_unready_sidecar + how_do_i_handle_a_canary_upgrade_failure diff --git a/umn/source/faqs/mesh_management/what_can_i_do_if_a_pod_cannot_be_started_due_to_unready_sidecar.rst b/umn/source/faqs/mesh_management/what_can_i_do_if_a_pod_cannot_be_started_due_to_unready_sidecar.rst new file mode 100644 index 0000000..d3188cf --- /dev/null +++ b/umn/source/faqs/mesh_management/what_can_i_do_if_a_pod_cannot_be_started_due_to_unready_sidecar.rst @@ -0,0 +1,87 @@ +:original_name: asm_faq_0039.html + +.. _asm_faq_0039: + +What Can I Do If A Pod Cannot Be Started Due to Unready Sidecar +=============================================================== + +Description +----------- + +Pods of services managed by a mesh may fail to be started and keep restarting. When the service container communicates with external systems, the traffic passes through the **istio-proxy** container. However, the service container is started earlier than the **istio-proxy** container. As a result, the communication with external systems fails and the pod keeps restarting. + +Solution +-------- + +In Istio 1.7 and later versions, the community adds a switch named **HoldApplicationUntilProxyStarts** to the **istio-injector** injection logic. After the switch is enabled, the proxy is injected to the first container and the **istio-proxy** container is started earlier than the service container. + +The switch can be configured globally or locally. The following describes two ways to enable the switch. + +.. important:: + + After this switch is enabled, the service container cannot be started until the sidecar is fully ready, which slows down pod startup and reduces scalability for burst traffic. You are advised to evaluate service scenarios and enable this switch only for required services. + +- **Global Configuration** + + #. Run the following command to edit the IOP CR resource: + + **kubectl edit iop private-data-plane -n istio-system** + + Add the following command to the **spec.values.global.proxy** field: + + .. code-block:: + + holdApplicationUntilProxyStarts: true + + |image1| + + #. Run the following command to check whether the latest logs contain no error information: + + **kubectl logs -n istio-operator $(kubectl get po -n istio-operator \| awk '{print $1}' \| grep -v NAME)** + + #. Run the following command to check whether the IOP CR is normal: + + **kubectl get iop -n istio-system** + + |image2| + + #. Run the following command to upgrade the services in the mesh in a rolling manner: + + **kubectl rollout restart deployment** *nginx* **-n** *default* + + where, **nginx** is an example service, and **default** is the namespace. Replace them with the actual values. + + #. Run the following command to check whether the pod is restarted: + + **kubectl get pod -n** *default* **\| grep** *nginx* + + |image3| + + #. Run the following command to check whether **postStart lifecycle** is added to the pod and whether the **istio-proxy** container is placed in the first position: + + **kubectl edit pod** *nginx-7bc96f87b9-l4dbl* + + |image4| + +- **Local Configuration** + + For Istio 1.8 or later versions, you can label the pods for which this function needs to be enabled with **proxy.istio.io/config** and set **holdApplicationUntilProxyStarts** to true. + + The following uses the **nginx** service in the **default** namespace as an example. The operations for other services are similar. + + **kubectl edit deploy** *nginx* **-n** *default* + + Add the following commands to the **spec.template.metadata.annotations** field: + + .. code-block:: + + proxy.istio.io/config: | + holdApplicationUntilProxyStarts: true + + |image5| + +.. |image1| image:: /_static/images/en-us_image_0000001416062808.png +.. |image2| image:: /_static/images/en-us_image_0000001416224808.png +.. |image3| image:: /_static/images/en-us_image_0000001416065480.png +.. |image4| image:: /_static/images/en-us_image_0000001466625829.png +.. |image5| image:: /_static/images/en-us_image_0000001416387696.png diff --git a/umn/source/faqs/mesh_management/why_are_exclusive_nodes_still_exist_after_istio_is_uninstalled.rst b/umn/source/faqs/mesh_management/why_are_exclusive_nodes_still_exist_after_istio_is_uninstalled.rst new file mode 100644 index 0000000..94ae17a --- /dev/null +++ b/umn/source/faqs/mesh_management/why_are_exclusive_nodes_still_exist_after_istio_is_uninstalled.rst @@ -0,0 +1,21 @@ +:original_name: asm_faq_0022.html + +.. _asm_faq_0022: + +Why Are Exclusive Nodes Still Exist After Istio Is Uninstalled? +=============================================================== + +Symptom +------- + +After Istio is uninstalled, exclusive nodes still exist. + +Analysis +-------- + +Only Istio control plane workloads will be deleted when you uninstall Istio for a cluster. Node resources will not be deleted automatically. + +Solution +-------- + +Nodes from which Istio are uninstalled can be used as common nodes. If these nodes are no longer required, log in to the CCE console and click the cluster name to go to the cluster console. Then, choose **Nodes** > **Nodes** to delete the nodes. diff --git a/umn/source/faqs/mesh_management/why_cannot_i_create_a_mesh_for_my_cluster.rst b/umn/source/faqs/mesh_management/why_cannot_i_create_a_mesh_for_my_cluster.rst new file mode 100644 index 0000000..bc98d4f --- /dev/null +++ b/umn/source/faqs/mesh_management/why_cannot_i_create_a_mesh_for_my_cluster.rst @@ -0,0 +1,22 @@ +: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. diff --git a/umn/source/faqs/performing_grayscale_release/index.rst b/umn/source/faqs/performing_grayscale_release/index.rst new file mode 100644 index 0000000..f93538f --- /dev/null +++ b/umn/source/faqs/performing_grayscale_release/index.rst @@ -0,0 +1,16 @@ +:original_name: asm_faq_0006.html + +.. _asm_faq_0006: + +Performing Grayscale Release +============================ + +- :ref:`Why Can't I Change the Image Used for the Grayscale Version When Performing Grayscale Release? ` +- :ref:`Why Does Not a Grayscale Policy that Based on Request Content Take Effect for Some Services? ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + why_cant_i_change_the_image_used_for_the_grayscale_version_when_performing_grayscale_release + why_does_not_a_grayscale_policy_that_based_on_request_content_take_effect_for_some_services diff --git a/umn/source/faqs/performing_grayscale_release/why_cant_i_change_the_image_used_for_the_grayscale_version_when_performing_grayscale_release.rst b/umn/source/faqs/performing_grayscale_release/why_cant_i_change_the_image_used_for_the_grayscale_version_when_performing_grayscale_release.rst new file mode 100644 index 0000000..5af7729 --- /dev/null +++ b/umn/source/faqs/performing_grayscale_release/why_cant_i_change_the_image_used_for_the_grayscale_version_when_performing_grayscale_release.rst @@ -0,0 +1,21 @@ +:original_name: asm_faq_0007.html + +.. _asm_faq_0007: + +Why Can't I Change the Image Used for the Grayscale Version When Performing Grayscale Release? +============================================================================================== + +Description +----------- + +When I perform grayscale release, the image used for the grayscale version cannot be changed. + +Analysis +-------- + +When performing grayscale release on a service, you create a new version of the same service. Therefore, the image used by the service cannot be changed. Only image tags can be changed. + +Solution +-------- + +Pack the required image into a different tag of the same image and push it to the image repository. Then, select the newly pushed image tag when you perform grayscale release on the service. diff --git a/umn/source/faqs/performing_grayscale_release/why_does_not_a_grayscale_policy_that_based_on_request_content_take_effect_for_some_services.rst b/umn/source/faqs/performing_grayscale_release/why_does_not_a_grayscale_policy_that_based_on_request_content_take_effect_for_some_services.rst new file mode 100644 index 0000000..f6f732f --- /dev/null +++ b/umn/source/faqs/performing_grayscale_release/why_does_not_a_grayscale_policy_that_based_on_request_content_take_effect_for_some_services.rst @@ -0,0 +1,21 @@ +:original_name: asm_faq_0008.html + +.. _asm_faq_0008: + +Why Does Not a Grayscale Policy that Based on Request Content Take Effect for Some Services? +============================================================================================ + +Symptom +------- + +A grayscale policy that based on request content does not take effect on some services. + +Analysis +-------- + +A grayscale policy based on request content is valid only for the entry service that is directly accessed. + +Solution +-------- + +If you want a grayscale policy to be applied to all services in an application, the header information of the HTTP request needs to be transferred in the service code. diff --git a/umn/source/faqs/service_mesh_cluster/index.rst b/umn/source/faqs/service_mesh_cluster/index.rst new file mode 100644 index 0000000..ad99e60 --- /dev/null +++ b/umn/source/faqs/service_mesh_cluster/index.rst @@ -0,0 +1,16 @@ +:original_name: asm_faq_0029.html + +.. _asm_faq_0029: + +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? ` +- :ref:`Why Does a Service Mesh Remain in the Unready Status for a Long Time After I Uninstall It? ` + +.. 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_unready_status_for_a_long_time_after_i_uninstall_it diff --git a/umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_installing_status_for_a_long_time_after_i_enable_it_for_a_cluster.rst b/umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_installing_status_for_a_long_time_after_i_enable_it_for_a_cluster.rst new file mode 100644 index 0000000..a26f0e8 --- /dev/null +++ b/umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_installing_status_for_a_long_time_after_i_enable_it_for_a_cluster.rst @@ -0,0 +1,26 @@ +:original_name: asm_faq_0030.html + +.. _asm_faq_0030: + +Why Does a Service Mesh Remain in the Installing Status 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. + +Fault Diagnosis +--------------- + +Log in to the CCE console and click the cluster name to go to the cluster console. In the navigation pane, choose **Namespaces**. Then, check whether the **istio-system** namespace exists. + +Analysis +-------- + +Residual **istio-system** namespaces exist. + +Solution +-------- + +Delete the residual **istio-system** namespaces and install the mesh again. diff --git a/umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_unready_status_for_a_long_time_after_i_uninstall_it.rst b/umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_unready_status_for_a_long_time_after_i_uninstall_it.rst new file mode 100644 index 0000000..35c4297 --- /dev/null +++ b/umn/source/faqs/service_mesh_cluster/why_does_a_service_mesh_remain_in_the_unready_status_for_a_long_time_after_i_uninstall_it.rst @@ -0,0 +1,47 @@ +:original_name: asm_faq_0031.html + +.. _asm_faq_0031: + +Why Does a Service Mesh Remain in the Unready Status 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. + +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**. + +#. Click **Releases** and select the target cluster from the drop-down list. Check the releases and the latest events about uninstallation failure. + + The **Status** of **istio-master** is **Uninstallation Failed**, and the following message is displayed. + + .. code-block:: + + deletion failed with 1 error(s): clusterroles:rbac.authorization.k8s.io "istio-cleanup-secrets-istio-system" already exists + +Analysis +-------- + +Abnormal operations cause the Helm chart of Istio stuck during uninstallation. Residual resources lead to an uninstallation failure. + +Solution +-------- + +#. Connect to the CCE cluster using kubectl. + +#. Run the following commands to clear Istio resources: + + .. code-block:: + + kubectl delete ServiceAccount -n istio-system `kubectl get ServiceAccount -n istio-system | grep istio | awk '{print $1}'` + kubectl delete ClusterRole -n istio-system `kubectl get ClusterRole -n istio-system | grep istio | awk '{print $1}'` + kubectl delete ClusterRoleBinding -n istio-system `kubectl get ClusterRoleBinding -n istio-system | grep istio | awk '{print $1}'` + kubectl delete job -n istio-system `kubectl get job -n istio-system | grep istio | awk '{print $1}'` + 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. diff --git a/umn/source/getting_started/configurable_grayscale_release/grayscale_release.rst b/umn/source/getting_started/configurable_grayscale_release/grayscale_release.rst new file mode 100644 index 0000000..f7f1d73 --- /dev/null +++ b/umn/source/getting_started/configurable_grayscale_release/grayscale_release.rst @@ -0,0 +1,47 @@ +:original_name: asm_qs_0009.html + +.. _asm_qs_0009: + +Grayscale Release +================= + +Creating a Grayscale Release Task +--------------------------------- + +#. Log in to the ASM console and click |image1| in the **asmtest** mesh. + +#. Set **Task Name** to **test** and select **servicetest** created in :ref:`Creating a Workload and a Service ` for **Service**. (**Workload** is automatically set to **deptest**.) Configure other basic information and grayscale version information and click **Release**. + + .. note:: + + If you cannot select **servicetest**, check whether the service is normal. If the service is abnormal, fix the issues and try again. + +#. Click **Configure Traffic Policy**, set the policy type to **Based on traffic ratio**, and set the **traffic ratio** of v2 to 80%. + +#. Click **Deliver Policy**. + + It takes several seconds for the traffic policy to take effect. You can view the running of the grayscale version on the **View Status** page. + +Switching All Traffic to the Grayscale Version +---------------------------------------------- + +Check whether the number of resources in v2 matches that in v1. After confirming that v2 is able to serve all the traffic of v1, switch all the traffic from v1 to v2. + +#. On the **Grayscale Release** page, click **test** and then click **Monitor and Manage Traffic**. +#. Click **Take Over All Traffic** next to v2. +#. Click **OK**. A message is displayed in the upper right corner, indicating that the traffic is taken over successfully. + +Bringing the Original Version Offline +------------------------------------- + +After v2 takes over all the traffic from v1, bring v1 offline to release its resources. + +#. On the **Grayscale Release** page, click **test** and then click **Monitor and Manage Traffic**. + +#. On the displayed page, when the traffic percentage of v2 is **100%**, v2 has taken over all traffic of v1. Click **Terminate Task**. + +#. Click **OK**. + + The v1 version is brought offline and the test grayscale task is deleted. + +.. |image1| image:: /_static/images/en-us_image_0000001247200741.png diff --git a/umn/source/getting_started/configurable_grayscale_release/index.rst b/umn/source/getting_started/configurable_grayscale_release/index.rst new file mode 100644 index 0000000..78b9ad5 --- /dev/null +++ b/umn/source/getting_started/configurable_grayscale_release/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_qs_0006.html + +.. _asm_qs_0006: + +Configurable Grayscale Release +============================== + +- :ref:`Overview ` +- :ref:`Preparations ` +- :ref:`Grayscale Release ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + overview + preparations + grayscale_release diff --git a/umn/source/getting_started/configurable_grayscale_release/overview.rst b/umn/source/getting_started/configurable_grayscale_release/overview.rst new file mode 100644 index 0000000..24d0cdf --- /dev/null +++ b/umn/source/getting_started/configurable_grayscale_release/overview.rst @@ -0,0 +1,21 @@ +:original_name: asm_qs_0007.html + +.. _asm_qs_0007: + +Overview +======== + +A grayscale release is a smooth iteration mode for version upgrade. During the upgrade, some users use the new version, while other users continue to use the old version. After the new version is stable and ready, it gradually takes over all the live traffic. + +This section describes how to create a VPC and a grayscale version to complete a grayscale release. + +Process Description +------------------- + +The following figure shows the grayscale release process. + + +.. figure:: /_static/images/en-us_image_0000001202040720.png + :alt: **Figure 1** Process of creating a grayscale release task + + **Figure 1** Process of creating a grayscale release task diff --git a/umn/source/getting_started/configurable_grayscale_release/preparations.rst b/umn/source/getting_started/configurable_grayscale_release/preparations.rst new file mode 100644 index 0000000..3f6b0aa --- /dev/null +++ b/umn/source/getting_started/configurable_grayscale_release/preparations.rst @@ -0,0 +1,94 @@ +:original_name: asm_qs_0008.html + +.. _asm_qs_0008: + +Preparations +============ + +Before creating a grayscale release task, perform the following operations. + +Creating a VPC +-------------- + +Virtual Private Cloud (VPC) provides a logically isolated, configurable, and manageable virtual network environment, improving resource security and simplifying network deployment. + +#. Log in to the VPC console. +#. Click **Create VPC** in the upper right corner. +#. Configure the parameters as prompted and click Create Now. + +Creating a Key Pair +------------------- + +Create a key pair for identity authentication upon remote node login. + +#. Log in to the Elastic Cloud Server (ECS) console. +#. In the navigation pane, choose **Key Pair**. On the page displayed, click **Create Key Pair** in the upper right corner. +#. Enter a key pair name and click **OK**. +#. Manually or automatically download the private key file. The file name is the specified key pair name with a suffix of **.pem**. Securely store the private key file. In the dialog box displayed, click **OK**. + + .. note:: + + For security purposes, a key pair can be downloaded only once. Keep it secure to ensure successful login. + +Creating a Load Balancer +------------------------ + +A load balancer will be used as the external access entry of a service mesh, which will route the traffic to backend services. + +#. Log in to the Elastic Load Balance (ELB) console. +#. Click Create Elastic Load Balancer in the upper right corner. +#. **VPC** and **Subnet**: Select the VPC and subnet created in :ref:`Creating a VPC `, configure other parameters as prompted, and click Create Now. + +.. _asm_qs_0008__section4238161922215: + +Creating a Cluster +------------------ + +#. Log in to the CCE console. + +#. Then, click **Create CCE Cluster** in the upper right corner. + +#. Configure the following parameters: + + - **Cluster Name**: Enter a cluster name, for example, **cluster-test**. + - **VPC** and **Subnet**: Select the VPC and subnet created in :ref:`Creating a VPC `. + + Retain the default settings of other parameters. + +#. Click **Next: Select Add-on**. + +#. Click **Next: Confirm**. Read the product constraints and select **I am aware of the above limitations**. Review the configured parameters and specifications. + +#. **Submit** the order. + + It takes about 6 to 10 minutes to create a cluster. You can click **Back to Cluster List** to perform other operations on the cluster or click **Go to Cluster Events** to view the cluster details. + +.. _asm_qs_0008__section496120305565: + +Creating a Workload and a Service +--------------------------------- + +#. Log in to the CCE console and click the cluster name to access the cluster console. +#. Choose **Workloads** > **Deployments**. In the the upper right corner, click **Create Workload**. +#. Create a workload and a Service by referring to *CCE User Guide*. + +Creating a Service Mesh +----------------------- + +#. Log in to the ASM console and click **Create Mesh**. +#. Select the cluster named **cluster-test** created in :ref:`Creating a Cluster ` and select nodes on which the Istio control plane is installed. Two or more nodes in different AZs are recommended. +#. Configure observability parameters as required. +#. Click **Show Advanced Settings**. In **Namespace Injection Settings**, select the namespace named **default** and enable **Restart Existing Services**. Configure other parameters as required. + +5. Review the service mesh configuration in **Configuration List** on the right of the page and click **Submit**. + + It takes about 1 to 3 minutes to create a service mesh. If the service mesh status changes from **Installing** to **Running**, the service mesh is successfully created. + +Diagnosing Configurations +------------------------- + +ASM diagnoses all services in a managed cluster. Grayscale release can be performed only for services that are diagnosed as normal. + +#. Log in to the ASM console, click the service mesh named **asmtest** to access its details page. +#. In the navigation pane, choose **Service Management**, select **Namespace: default**, and view the configuration diagnosis result of **servicetest**. +#. If **Abnormal** is displayed, click **Fix** to fix the issue. diff --git a/umn/source/getting_started/enabling_istio_for_a_cluster/creating_a_service_mesh.rst b/umn/source/getting_started/enabling_istio_for_a_cluster/creating_a_service_mesh.rst new file mode 100644 index 0000000..3a1320c --- /dev/null +++ b/umn/source/getting_started/enabling_istio_for_a_cluster/creating_a_service_mesh.rst @@ -0,0 +1,39 @@ +:original_name: asm_qs_0010.html + +.. _asm_qs_0010: + +Creating a Service Mesh +======================= + +ASM allows you to create a service mesh of the Basic edition, which is a standard service mesh available for commercial use. + +Procedure +--------- + +#. Log in to the ASM console and click **Create Mesh**. + +#. Configure the following parameters and retain the default values for other parameters. + + - **Mesh Edition** + + The default value is **Basic edition**. + + - **Mesh Name** + + Enter the service mesh name. + + - **Istio Version** + + Select the Istio version supported by the service mesh. + + - **Cluster** + + Select the cluster created in :ref:`Creating a Cluster `. + + - **Mesh Control Plane Node** + + To achieve HA, select two or more nodes from different AZs. + +#. Review the service mesh configuration in **Configuration List** on the right of the page and click **Submit**. + + It takes about 1 to 3 minutes to create a service mesh. If the service mesh status changes from **Installing** to **Running**, the service mesh is successfully created. diff --git a/umn/source/getting_started/enabling_istio_for_a_cluster/index.rst b/umn/source/getting_started/enabling_istio_for_a_cluster/index.rst new file mode 100644 index 0000000..9e577a8 --- /dev/null +++ b/umn/source/getting_started/enabling_istio_for_a_cluster/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_qs_0002.html + +.. _asm_qs_0002: + +Enabling Istio for a Cluster +============================ + +- :ref:`Overview ` +- :ref:`Preparations ` +- :ref:`Creating a Service Mesh ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + overview + preparations + creating_a_service_mesh diff --git a/umn/source/getting_started/enabling_istio_for_a_cluster/overview.rst b/umn/source/getting_started/enabling_istio_for_a_cluster/overview.rst new file mode 100644 index 0000000..05bd279 --- /dev/null +++ b/umn/source/getting_started/enabling_istio_for_a_cluster/overview.rst @@ -0,0 +1,19 @@ +:original_name: asm_qs_0003.html + +.. _asm_qs_0003: + +Overview +======== + +Providing a non-intrusive microservice governance solution, ASM supports full-lifecycle management and traffic management and is compatible with the Kubernetes and Istio ecosystems. It hosts functions such as load balancing, outlier detection, and rate limiting. + +Process Description +------------------- + +The process of enabling Istio for a cluster is shown in the following figure. + + +.. figure:: /_static/images/en-us_image_0000001255345827.png + :alt: **Figure 1** Process of enabling Istio for a cluster + + **Figure 1** Process of enabling Istio for a cluster diff --git a/umn/source/getting_started/enabling_istio_for_a_cluster/preparations.rst b/umn/source/getting_started/enabling_istio_for_a_cluster/preparations.rst new file mode 100644 index 0000000..b55c974 --- /dev/null +++ b/umn/source/getting_started/enabling_istio_for_a_cluster/preparations.rst @@ -0,0 +1,80 @@ +:original_name: asm_qs_0004.html + +.. _asm_qs_0004: + +Preparations +============ + +Before enabling Istio for a cluster, perform the following operations. + +.. _asm_qs_0004__section1956152937: + +Creating a VPC +-------------- + +Virtual Private Cloud (VPC) provides a logically isolated, configurable, and manageable virtual network environment, improving resource security and simplifying network deployment. + +#. Log in to the VPC console. +#. Click **Create VPC** in the upper right corner. +#. Configure the parameters as prompted and click Create Now. + +Creating a Key Pair +------------------- + +Create a key pair for identity authentication upon remote node login. + +#. Log in to the Elastic Cloud Server (ECS) console. +#. In the navigation pane, choose **Key Pair**. On the page displayed, click **Create Key Pair** in the upper right corner. +#. Enter a key pair name and click **OK**. +#. Manually or automatically download the private key file. The file name is the specified key pair name with a suffix of **.pem**. Securely store the private key file. In the dialog box displayed, click **OK**. + + .. note:: + + For security purposes, a key pair can be downloaded only once. Keep it secure to ensure successful login. + +Creating a Load Balancer +------------------------ + +A load balancer will be used as the external access entry of a service mesh, which will route the traffic to backend services. + +#. Log in to the Elastic Load Balance (ELB) console. +#. Click Create Elastic Load Balancer in the upper right corner. +#. **VPC** and **Subnet**: Select the VPC and subnet created in :ref:`Creating a VPC `, configure other parameters as prompted, and click Create Now. + +.. _asm_qs_0004__section19395823191819: + +Creating a Cluster +------------------ + +#. Log in to the CCE console. + +#. Then, click **Create CCE Cluster** in the upper right corner. + +#. Configure the following parameters: + + - **Cluster Name**: Enter a cluster name, for example, **cluster-test**. + - **VPC** and **Subnet**: Select the VPC and subnet created in :ref:`Creating a VPC `. + + Retain the default settings of other parameters. + +#. Click **Next: Select Add-on**. + +#. Click **Next: Confirm**. Read the product constraints and select **I am aware of the above limitations**. Review the configured parameters and specifications. + +#. **Submit** the order. + + It takes about 6 to 10 minutes to create a cluster. You can click **Back to Cluster List** to perform other operations on the cluster or click **Go to Cluster Events** to view the cluster details. + +(Optional) Creating a Namespace +------------------------------- + +#. Log in to the CCE console and click the cluster name to access the cluster console. +#. In the navigation pane on the left, choose **Namespaces**. In the upper right corner, click **Create Namespace**. +#. Enter a namespace name and click **OK**. + +Creating a Workload and a Service +--------------------------------- + +#. Log in to the CCE console and click the cluster name to access the cluster console. +#. Choose **Workloads** > **Deployments**. In the the upper right corner, click **Create Workload**. +#. Create a workload and a Service by referring to *CCE User Guide*. diff --git a/umn/source/getting_started/grayscale_release_practices_of_bookinfo.rst b/umn/source/getting_started/grayscale_release_practices_of_bookinfo.rst new file mode 100644 index 0000000..e97299e --- /dev/null +++ b/umn/source/getting_started/grayscale_release_practices_of_bookinfo.rst @@ -0,0 +1,360 @@ +:original_name: asm_qs_0001_0.html + +.. _asm_qs_0001_0: + +Grayscale Release Practices of Bookinfo +======================================= + +Application Service Mesh (ASM) is a service mesh platform developed based on Istio and seamlessly interconnects with Cloud Container Engine (CCE). With better usability, reliability, and visualization, ASM provides you with out-of-the-box features and enhanced user experience. + +Introduction +------------ + +Grayscale releases enable smooth iteration of software products in production environments. This section takes Bookinfo as an example to illustrate Istio-based service governance using ASM. + +The grayscale release process of Bookinfo is as follows. + + +.. figure:: /_static/images/en-us_image_0000001202041610.png + :alt: **Figure 1** Grayscale release process of Bookinfo + + **Figure 1** Grayscale release process of Bookinfo + +Architecture Analysis of Bookinfo +--------------------------------- + +Bookinfo is an application that functions as an online bookstore that displays each book with its description, details (such as pages), and reviews. + +Bookinfo consists of four independent services developed in different languages. These services demonstrate the features of a typical service mesh. They are described as follows: + +- productpage: calls the details and reviews services to generate a page. +- details: contains book information. +- reviews: contains book reviews and calls the ratings service. +- ratings: contains book rating information based on reviews. + +The reviews service has three versions: + +- The v1 (1.5.0) version does not call the ratings service. +- The v2 (1.5.1) version calls the ratings service and uses one to five black stars to show ratings. +- The v3 (1.5.2) version calls the ratings service and uses one to five red stars to show ratings. + +.. note:: + + To demonstrate traffic switching between versions, this section takes 1.5.1 (rating with black stars) and 1.5.2 (rating with red stars) of the reviews service as examples. + + +.. figure:: /_static/images/en-us_image_0000001440024745.png + :alt: **Figure 2** End-to-end architecture of Bookinfo + + **Figure 2** End-to-end architecture of Bookinfo + +Running Bookinfo with ASM does not require any changes on the application itself. Simply configure and run the services in the ASM environment, that is, inject an Envoy sidecar into each service. :ref:`Figure 3 ` shows the final deployment. + +.. _asm_qs_0001_0__fig1239019461376: + +.. figure:: /_static/images/en-us_image_0000001389665636.png + :alt: **Figure 3** Bookinfo with Envoy sidecars injected + + **Figure 3** Bookinfo with Envoy sidecars injected + +All services are integrated with Envoy sidecars. All inbound and outbound traffic of the integrated services is intercepted by sidecars. In this way, ASM can provide service routing, telemetry data collection, and policy implementation for Bookinfo. + +Preparations +------------ + +Perform the following operations: + +#. .. _asm_qs_0001_0__li14222135210592: + + Create a VPC and subnet. + + Virtual Private Cloud (VPC) provides a logically isolated, configurable, and manageable virtual network environment, improving resource security and simplifying network deployment. + + a. Log in to the VPC console. + b. Click Create VPC in the upper right corner. + c. Configure the parameters as prompted and click Create Now. + +#. .. _asm_qs_0001_0__li8805135016420: + + (Optional) Create a key pair. + + To log in to a cluster node using a key pair, create a key pair in advance. + + a. Log in to the Elastic Cloud Server (ECS) console. + b. In the navigation pane, choose **Key Pair**. On the page displayed, click **Create Key Pair** in the upper right corner. + c. Enter a key pair name and click **OK**. + d. Manually or automatically download the private key file. The file name is the specified key pair name with a suffix of **.pem**. Securely store the private key file. In the dialog box displayed, click **OK**. + + .. note:: + + For security purposes, a key pair can be downloaded only once. Keep it secure to ensure successful login. + +#. Create a load balancer. + + A load balancer will be used as the external access entry of a service mesh, which will route the traffic to backend services. + + a. Log in to the Elastic Load Balance (ELB) console. + b. Click Create Elastic Load Balancer in the upper right corner. + c. **VPC** and **Subnet**: Select the VPC and subnet created in :ref:`1 `, configure other parameters as prompted, and click Create Now. + +#. .. _asm_qs_0001_0__li1024821518115: + + Create a cluster. + + a. Log in to the Cloud Container Engine (CCE) console. + + b. In the navigation pane, choose **Resource Management** > **Clusters**. Then, click **Create CCE Cluster** in the upper right corner. + + c. On the **Configure** page, configure the following parameters and retain the default values for other parameters. + + - **Cluster Name**: Enter a cluster name, for example, **cce-asm**. + - **VPC** and **Subnet**: Select the VPC and subnet created in :ref:`1 `. + + d. Click **Next: Create Node**, configure the following parameters, and retain the default values for other parameters. + + - **Specifications**: 4 vCPUs and 8 GiB of memory. + + .. note:: + + This is the minimum specifications for deploying Bookinfo. + + - **Login Mode**: Select the key pair created in :ref:`2 ` for identity authentication upon remote node login. + + e. Click **Next: Install Add-on** and select the add-ons to be installed in the **Install Add-on** step. + + **System resource add-on** must be installed. **Advanced functional add-on** is optional. + + f. Click **Next: Confirm**. Read the product constraints and select **I am aware of the above limitations**. Review the configured parameters and specifications. + + g. Submit the order. + + It takes about 6 to 10 minutes to create a cluster. You can click **Back to Cluster List** to perform other operations on the cluster or click **Go to Cluster Events** to view the cluster details. + +#. Prepare the images required by Bookinfo (as shown in :ref:`Table 1 `), push them to SWR and set their **Type** to **Public**. + + .. caution:: + + The image name and tag of each service must be the same as those in :ref:`Table 1 `. Otherwise, the experience task may fail. + + .. _asm_qs_0001_0__table428162913363: + + .. table:: **Table 1** Image list + + =========== ================================ ========== + Service Image Name Image Tag + =========== ================================ ========== + productpage examples-bookinfo-productpage-v1 1.5.0 + details examples-bookinfo-details-v1 1.5.01.5.0 + ratings examples-bookinfo-ratings-v1 1.5.01.5.0 + reviews examples-bookinfo-reviews-v1 1.5.1 + \ examples-bookinfo-reviews-v1 1.5.2 + =========== ================================ ========== + + The following uses Bookinfo images as an example: + + a. Prepare a computer that can access the Internet and has Docker 1.11.2 or later installed. + + b. .. _asm_qs_0001_0__li15857121914118: + + Run the following commands in sequence to download the images required by Bookinfo: + + **docker pull docker.io/istio/examples-bookinfo-productpage-v1:1.5.0** + + **docker pull docker.io/istio/examples-bookinfo-details-v1:1.5.0** + + **docker pull docker.io/istio/examples-bookinfo-ratings-v1:1.5.0** + + **docker pull docker.io/istio/examples-bookinfo-reviews-v2:1.5.0** + + **docker pull docker.io/istio/examples-bookinfo-reviews-v3:1.5.0** + + c. Connect to SWR. + + d. Label the images pulled in :ref:`5.b `. Ensure that the image names and tags are the same as those in :ref:`Table 1 `. + + **docker tag docker.io/istio/examples-bookinfo-productpage-v1:1.5.0** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-productpage-v1:1.5.0** + + **docker tag docker.io/istio/examples-bookinfo-details-v1:1.5.0** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-details-v1:1.5.0** + + **docker tag docker.io/istio/examples-bookinfo-ratings-v1:1.5.0** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-ratings-v1:1.5.0** + + **docker tag docker.io/istio/examples-bookinfo-reviews-v2:1.5.0** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-reviews-v1:1.5.1** + + **docker tag docker.io/istio/examples-bookinfo-reviews-v3:1.5.0** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-reviews-v1:1.5.2** + + *swr.xxxxxxxxx.* indicates the image repository address, and *group* indicates the organization name. Replace them with the actual values. + + e. Push the images to the SWR. + + **docker push** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-productpage-v1:1.5.0** + + **docker push** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-details-v1:1.5.0** + + **docker push** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-ratings-v1:1.5.0** + + **docker push** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-reviews-v1:1.5.1** + + **docker push** *swr.xxxxxxxxx.*\ **/**\ *group*\ **/examples-bookinfo-reviews-v1:1..5.2** + + f. Change the image type to **Public**. + +Creating a Mesh +--------------- + +#. Log in to the ASM console. + +#. Click **Create Mesh** in the upper right corner. + +#. Configure the following parameters and retain the default values for other parameters. + + - **Mesh Edition** + + The default value is **Basic edition**. + + - **Mesh Name** + + Enter the mesh name. + + - **Istio Version** + + Select the Istio version supported by the mesh. + + - **Cluster** + + Select the cluster created in :ref:`4 `. + + - **Mesh Control Plane Node** + + To achieve HA, select two or more nodes from different AZs. + +#. Review the service mesh configuration in **Configuration List** on the right of the page and click **Submit**. + + It takes about 1 to 3 minutes to create a service mesh. If the service mesh status changes from **Installing** to **Running**, the service mesh is successfully created. + +Deploying Bookinfo in One Click +------------------------------- + +After the service mesh is enabled for the cluster, you can quickly create a Bookinfo demo. + +#. Log in to the ASM console. +#. Click the name of the service mesh to access its details page. +#. In the navigation pane, choose **Experience Tasks** and click **Try Now** in the Bookinfo task. +#. On the right of the page, set **Cluster** to the cluster where Bookinfo resides, set **Load Balancer** to a load balancer that is in the same VPC and subnet as the selected cluster, set an external port, and click **Install**. +#. Wait until Bookinfo is created. Click **Service Management** and ensure that the value in the **Configuration Diagnosis Result** column is **Normal**. The Bookinfo contains the productpage, details, reviews, and ratings services. + +Creating a Grayscale Release Task +--------------------------------- + +A new grayscale version of the **reviews** service of Bookinfo will be created. A grayscale policy will be configured to divert traffic of the default version to the new version. + +The following steps will guide you to create a new version (v3) of the **reviews** service and divert 30% traffic of Bookinfo to this version. + +**Deploying a grayscale version** + +#. In the navigation pane, choose **Grayscale Release**. On the **Canary Release** area of the displayed page, click **Create Release Task**. +#. Configure basic information. + + - **Task Name**: Enter a task name, for example, **reviews-v3**. + - **Namespace**: Select the namespace that the service belongs to. + - **Service**: Select **reviews** from the drop-down list box. + - **Workload**: Select the workload that the service belongs to. + +#. Configure version information. + + - **Cluster**: Select the cluster that the service belongs to. + - **Version**: Set this parameter to **v3**. + - **Pods**: Retain the default value. + - **Pod Configuration**: Set the image tag to **1.17.2** and retain the default values for other parameters. + +#. Click **Release**. If the progress reaches 100%, the grayscale version is successfully released. + +**Configuring a traffic policy** + +Configure a grayscale policy for the grayscale version. A specified percentage of traffic will be diverted from the original version to the grayscale version. + +#. After the grayscale version is deployed, click **Configure Traffic Policy**. + +#. Configure a traffic policy. + + **Policy Type**: The value can be **Based on traffic ratio** or **Based on request content**. + + - **Based on traffic ratio**: A specified percentage of traffic will be directed to the grayscale version. For example, 80% of the traffic is directed to the original version, and 20% is directed to the grayscale version. + - **Based on request content**: Only the traffic that meets specific conditions will be directed to the grayscale version. For example, only users on the Windows operating system can access the grayscale version. + + In this example, configure a traffic policy **Based on traffic ratio** and set the traffic percentage of v3 to **20%**. + + + .. figure:: /_static/images/en-us_image_0000001202053160.png + :alt: **Figure 4** Traffic policy + + **Figure 4** Traffic policy + +#. Click **Deliver Policy**. + + It takes several seconds for the traffic policy to take effect. You need to enable APM to view the traffic monitoring data of the original version and grayscale version. + +#. On the **Service List** page, click the **Access Address** of the productpage service. Frequently refresh the book information page. You can find that the **Book Reviews** area is switching between black stars (v1) and red stars (v3) and the ratio is nearly 4 to 1. + + + .. figure:: /_static/images/en-us_image_0000001247893125.png + :alt: **Figure 5** v1 page + + **Figure 5** v1 page + + + .. figure:: /_static/images/en-us_image_0000001203053124.png + :alt: **Figure 6** v3 page + + **Figure 6** v3 page + +#. Run the following command on a server that has been connected to the public network to continuously access the productpage service: + + **while true;do wget -q -O- http://**\ *ip:port*\ **/productpage; done** + + Return to the **Monitor and Manage Traffic** page on the console and view the real-time traffic monitoring data of v1 and v3. + + + .. figure:: /_static/images/en-us_image_0000001203333110.png + :alt: **Figure 7** Traffic monitoring data + + **Figure 7** Traffic monitoring data + +Switching All Traffic to the Grayscale Version +---------------------------------------------- + +Check whether the number of resources in v3 matches that in v1. After confirming that v3 is able to serve all the traffic of v1, switch all the traffic from v1 to v3. + +#. On the **Monitor and Manage Traffic** page, click **Take Over All Traffic** next to v3. + +#. Click **OK**. + + A message indicating that the traffic is successfully switched is displayed in the upper right corner. Frequently refresh the Bookinfo page. You can find that only red stars (v3) are used in the **Book Reviews** area. + + + .. figure:: /_static/images/en-us_image_0000001203040696.png + :alt: **Figure 8** v3 page + + **Figure 8** v3 page + +Ending the Grayscale Release Task +--------------------------------- + +After v3 takes over all the traffic from v1, bring v1 offline to release its resources. + +#. On the **Monitor and Manage Traffic** page, click **End Task**. + +#. Click **OK** to end the task, bring the original version offline, and delete the task. + + Bringing a version offline will delete all its workloads and Istio configuration resources. + +Clearing Resources +------------------ + +This is the end of the demo of performing the grayscale release using ASM. Delete applications and nodes in time to avoid unnecessary fees. + +#. In the navigation pane, choose **Experience Tasks** and click **Uninstall** in the Bookinfo task. +#. Click **OK**. After the Bookinfo experience task is uninstalled, the productpage, details, reviews, and ratings services and related resources are automatically deleted. + + .. note:: + + After an experience task is uninstalled, go to the CCE console and manually delete the workloads corresponding to the grayscale version of the service for which grayscale release has been completed. diff --git a/umn/source/getting_started/index.rst b/umn/source/getting_started/index.rst new file mode 100644 index 0000000..fb93988 --- /dev/null +++ b/umn/source/getting_started/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_qs_0001.html + +.. _asm_qs_0001: + +Getting Started +=============== + +- :ref:`Grayscale Release Practices of Bookinfo ` +- :ref:`Enabling Istio for a Cluster ` +- :ref:`Configurable Grayscale Release ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + grayscale_release_practices_of_bookinfo + enabling_istio_for_a_cluster/index + configurable_grayscale_release/index diff --git a/umn/source/index.rst b/umn/source/index.rst index 5069b16..680a870 100644 --- a/umn/source/index.rst +++ b/umn/source/index.rst @@ -1,3 +1,12 @@ -======================================================== -Welcome to the documentation of application-service-mesh -======================================================== +===================================== +Application Service Mesh - User Guide +===================================== + +.. toctree:: + :maxdepth: 1 + + service_overview/index + getting_started/index + user_guide/index + best_practices/index + faqs/index diff --git a/umn/source/service_overview/advantages.rst b/umn/source/service_overview/advantages.rst new file mode 100644 index 0000000..0cf546c --- /dev/null +++ b/umn/source/service_overview/advantages.rst @@ -0,0 +1,49 @@ +:original_name: asm_productdesc_0002.html + +.. _asm_productdesc_0002: + +Advantages +========== + +Ease of Use +----------- + +The out-of-the-box usability allows you to use a service mesh without code rewrite or manual installation. + +Built-in Canary Release and Blue-Green Deployment +------------------------------------------------- + +- Deployment of the grayscale version and traffic switchover with a few clicks +- Configurable grayscale policy that can be set based on traffic ratio and request content (cookies, OSs, and browsers) +- One-stop health, performance, and traffic monitoring, achieving quantified, intelligent, and visualized grayscale release + +Policy-based Intelligent Routing and Flexible Traffic Management +---------------------------------------------------------------- + +Load balancing, service routing, fault injection, and outlier detection policies can be intuitively configured. Microservice traffic management can be real-time, visualized, intelligent, and automated, requiring no modifications on your applications. + +- Routing rules can be set based on weight and content to implement flexible grayscale release of applications. +- Load balancing achieves high availability for service processing. +- Outlier detection ensures stable and reliable links between services. +- Network persistent connection management saves resources and improves network throughput. +- Service security certification, authentication, and audit lay a solid foundation for service security assurance. + +Enhanced Performance and Reliability +------------------------------------ + +The performance and reliability of the control plane and data plane are enhanced based on the community version. + +Multi-infrastructure +-------------------- + +An O&M-free hosting control plane is provided. Unified service governance, grayscale release, security, and service running monitoring capabilities are supported. Unified service discovery and management of multiple infrastructure resources such as containers and VMs are provided. + +Protocol Extension +------------------ + +The HTTP, gRPC, TCP, TLS, and Dubbo protocols are supported. + +Traditional SDK Integration +--------------------------- + +Integration solutions for traditional microservice SDKs such as Spring Cloud and Dubbo are provided. Services developed using traditional microservice SDKs can be migrated to cloud-native containers and mesh running environments without major code modification. diff --git a/umn/source/service_overview/application_scenarios/end-to-end_transparency_and_security.rst b/umn/source/service_overview/application_scenarios/end-to-end_transparency_and_security.rst new file mode 100644 index 0000000..922b1aa --- /dev/null +++ b/umn/source/service_overview/application_scenarios/end-to-end_transparency_and_security.rst @@ -0,0 +1,30 @@ +:original_name: asm_productdesc_0013.html + +.. _asm_productdesc_0013: + +End-to-End Transparency and Security +==================================== + +Application Scenarios +--------------------- + +Splitting traditional monolithic applications into microservices brings various benefits, including better flexibility, scalability, and reusability. The new security requirements microservices have are as follows: + +- Traffic encryption is required to defend against man-in-the-middle attacks. +- TLS and fine-grained access control policies are required for flexible service access control. +- Audit tools are needed to determine who can do what at what time. + +ASM provides a comprehensive security solution, including authentication policies, transparent TLS encryption, and authorization and audit tools, to address these requirements. + +Product Benefits +---------------- + +- **Default security**: No modification is required on application code and architecture to ensure security. +- **In-depth defense**: ASM can integrate with existing security systems to provide comprehensive defense. +- **Zero-trust network**: The security solution is built assuming that all the network is untrusted. + +Product Advantages +------------------ + +- **Non-intrusive security**: ASM provides service meshes as infrastructure with built-in security capabilities. It allows you to focus more on the development and O&M of your services. No code refactoring is required to ensure service access security. ASM provides a transparent, distributed security layer and underlying secure communication channels, which manage authentication, authorization, and encryption for service communication. ASM provides communication security between pods and services. Developers only need to focus on application-level security based on this security infrastructure layer. +- **Fine-grained authorization**: After authentication, access authorization between services can be managed. Authorization management can be performed on a specific service or a specific API of a service. For example, you can authorize all services in a specific namespace or only a specific service. The source service and destination service can be in different clusters. Pods of the source service can be in different clusters. Pods of the destination service can be in different clusters. diff --git a/umn/source/service_overview/application_scenarios/grayscale_release.rst b/umn/source/service_overview/application_scenarios/grayscale_release.rst new file mode 100644 index 0000000..f715bc2 --- /dev/null +++ b/umn/source/service_overview/application_scenarios/grayscale_release.rst @@ -0,0 +1,24 @@ +:original_name: asm_productdesc_0011.html + +.. _asm_productdesc_0011: + +Grayscale Release +================= + +Application Scenarios +--------------------- + +In traditional iterations, a new service version is directly released to all users at a time. This is risky, because once an online accident or bug occurs, the impact on users is great. It could take a long time to fix the issue. Sometimes, the version has to be rolled back, which severely affects user experience. + +Grayscale release is a smooth iteration mode for version upgrade. During the upgrade, some users use the new version, while other users continue to use the old version. After the new version is stable and ready, it gradually takes over all the live traffic. + +Product Benefits +---------------- + +ASM provides multiple grayscale release functions for application governance. It allows you to detect and fix issues at the early stage and ensure that the iteration goes smoothly and efficiently. + +Product Advantages +------------------ + +- **Built-in grayscale release process**: Multiple typical grayscale release processes are provided based on fine-grained distribution rules. A grayscale release wizard is provided for you to conveniently perform grayscale release practices. When a service version processes traffic, you can create a grayscale version. After the grayscale version is rolled out successfully, you can configure grayscale policies and diverge live traffic to the grayscale version. +- **Flexible grayscale policies**: You can set grayscale policies based on traffic ratio or request content, such as the OS, browser, cookie, and header information in an HTTP request. After configuring grayscale policies, you can view the running status and access information on multiple online versions in real time. You can select a stable version and switch all live traffic to this version in one click. diff --git a/umn/source/service_overview/application_scenarios/index.rst b/umn/source/service_overview/application_scenarios/index.rst new file mode 100644 index 0000000..3e1cbb2 --- /dev/null +++ b/umn/source/service_overview/application_scenarios/index.rst @@ -0,0 +1,22 @@ +:original_name: asm_productdesc_0003.html + +.. _asm_productdesc_0003: + +Application Scenarios +===================== + +- :ref:`Grayscale Release ` +- :ref:`Service Traffic Management ` +- :ref:`End-to-End Transparency and Security ` +- :ref:`Service Running Monitoring ` +- :ref:`Integration with Traditional Microservice SDKs ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + grayscale_release + service_traffic_management + end-to-end_transparency_and_security + service_running_monitoring + integration_with_traditional_microservice_sdks diff --git a/umn/source/service_overview/application_scenarios/integration_with_traditional_microservice_sdks.rst b/umn/source/service_overview/application_scenarios/integration_with_traditional_microservice_sdks.rst new file mode 100644 index 0000000..cfd7009 --- /dev/null +++ b/umn/source/service_overview/application_scenarios/integration_with_traditional_microservice_sdks.rst @@ -0,0 +1,24 @@ +:original_name: asm_productdesc_0015.html + +.. _asm_productdesc_0015: + +Integration with Traditional Microservice SDKs +============================================== + +Application Scenarios +--------------------- + +- Using service meshes to manage services developed using traditional SDKs. +- Integrating Istio with microservice platforms and building a microservice management and control center based on Istio. + +Product Benefits +---------------- + +Integration solutions for traditional microservice SDKs, such as Spring Cloud and Dubbo are provided. Services developed using traditional microservice SDKs can be migrated to cloud-native containers and meshes without major code modification. + +Product Advantages +------------------ + +- **Non-intrusive migration solution**: ASM provides a non-intrusive solution to help you migrate services developed using traditional SDKs to service meshes. The service invoker diverts outbound traffic to the mesh data plane. That is, the service discovery and load balancer in the original SDK are short-circuited. The Kubernetes service name is used for access, and the service discovery in the Kubernetes is used. The governance logic in the SDK can be gradually replaced by the mesh. In this way, the service running and governance capabilities are provided directly by the infrastructure based on Kubernetes and service meshes. +- **Unified policy management**: The unified ASM control plane is used to discover services and manage governance rules. No independent registration center or configuration center is required. Service discovery, load balancing, and governance on the data plane are all performed using the data plane Envoy. SDKs only function as a lightweight application development framework. +- **Multiple infrastructure resources**: In the solution, the data plane can be deployed on containers or VMs. Services can be developed in various languages. There is no restriction on the development framework. Traffic rules are delivered through the mesh control plane and all forms of data planes are managed in a unified manner. diff --git a/umn/source/service_overview/application_scenarios/service_running_monitoring.rst b/umn/source/service_overview/application_scenarios/service_running_monitoring.rst new file mode 100644 index 0000000..c33702b --- /dev/null +++ b/umn/source/service_overview/application_scenarios/service_running_monitoring.rst @@ -0,0 +1,22 @@ +:original_name: asm_productdesc_0014.html + +.. _asm_productdesc_0014: + +Service Running Monitoring +========================== + +Application Scenarios +--------------------- + +Container-based infrastructure brings a series of new challenges. It is necessary to evaluate and enhance the performance of API endpoints and identify potential risks of infrastructure. Istio service mesh enables you to enhance API performance with no code refactoring and service delay. + +Product Benefits +---------------- + +ASM generates detailed telemetry for all service communications within the mesh. It provides observability of service behaviors and allows operators to easily troubleshoot, maintain, and optimize their applications. With ASM, operators can better understand how services interact with other services and their components. + +Product Advantages +------------------ + +- **Non-intrusive collection of monitoring data**: To manage and troubleshoot a complex application, it is important to obtain its access topology between services and monitoring data. ASM collects the monitoring data in a non-intrusive way. It allows you to focus on service development rather than the generation of monitoring data. +- **Flexible service running management**: You can view the health status and dependencies between services using the access data in a topology. The topology allows you to unfold a service and observe the running status of each version of the service and each pod of a version. This pod-level topology enables you to observe how outlier detection policies work, for example, how a pod is isolated and how it recovers. When the pod is isolated, no requests are distributed to it. After it runs normally, requests are automatically distributed to it again. diff --git a/umn/source/service_overview/application_scenarios/service_traffic_management.rst b/umn/source/service_overview/application_scenarios/service_traffic_management.rst new file mode 100644 index 0000000..8ac3b22 --- /dev/null +++ b/umn/source/service_overview/application_scenarios/service_traffic_management.rst @@ -0,0 +1,34 @@ +:original_name: asm_productdesc_0012.html + +.. _asm_productdesc_0012: + +Service Traffic Management +========================== + +Application Scenarios +--------------------- + +Traffic management entails a wide range of operations, including: + +- Dynamically modifying load balancing policies for cross-service access, such as configuring consistent hashing to send traffic to specific service pods +- Distributing a certain proportion of traffic to a specific version of a service when the service has two online versions +- Protecting services, for example, limiting the number of concurrent connections and requests, and isolating faulty service pods +- Dynamically modifying the content of a service or simulating a service running fault + +Product Benefits +---------------- + +No code refactoring is required when you use ASM to manage traffic. + +Non-intrusive traffic management capabilities are provided based on Istio. Policy- and scenario-based network connection management is provided to suit different service protocols. Different management rules can be configured for different service APIs on the topology to meet your service requirements. + +Product Advantages +------------------ + +- **Retry:** Auto retries upon service access failures improve the access quality and success rate. You can set the number of HTTP retry times, retry timeout duration, and retry condition. +- **Timeout:** Auto processing and quickly failure return upon service access timeout eliminate resource locking and request freezing. You can set the HTTP request timeout duration. +- **Connection pool management**: You can configure the maximum TCP connections, connection timeout duration, maximum non-responses, minimum idle period, and health check interval for layer-4 protocols, and configure the maximum number of HTTP requests, maximum number of retry times, maximum number of pending requests, maximum number of requests for each connection, and maximum connection idle period for layer-7 protocols. In this way, the failure of a service will not cascade and affect the entire application. +- **Outlier detection**: You can configure the number of consecutive errors allowed before pod eviction, eviction interval, minimum eviction time, and maximum eviction ratio as outlier detection. In this way, you can check the running status of service pods on a regular basis. If access exceptions occur frequently, the pod is marked as abnormal and isolated accordingly. No traffic will be distributed to it in a specific period of time. After the isolation time, requests will be distributed to the pod. If the pod still runs abnormally, it will be isolated for a longer time. This is how pod isolation and automatic fault recovery work. +- **Load balancing**: Diverse load balancing policies, such as random, round robin, and least connection, are provided. You can configure consistent hashing to send traffic to specific service pods. +- **HTTP header:** You can flexibly add, edit, and remove HTTP headers, including the operations on the HTTP headers before the request is forwarded to the destination service and before the response is returned to the client. +- **Fault injection**: Abort and delay faults can be injected to specified services to test their resilience. No code refactoring is required. diff --git a/umn/source/service_overview/basic_concepts.rst b/umn/source/service_overview/basic_concepts.rst new file mode 100644 index 0000000..4ac1d82 --- /dev/null +++ b/umn/source/service_overview/basic_concepts.rst @@ -0,0 +1,44 @@ +:original_name: asm_productdesc_0005.html + +.. _asm_productdesc_0005: + +Basic Concepts +============== + +Workload +-------- + +A workload is an abstract model of a group of pods in Kubernetes. Workloads defined in Kubernetes include Deployments, StatefulSets, jobs, and DaemonSets. + +- **Deployment**: Pods of a Deployment are completely independent of each other and deliver the same functions. Deployments support auto scaling and rolling updates. Typical examples include Nginx and WordPress. +- **StatefulSet**: Pods in a StatefulSet are not completely independent of each other. StatefulSets have stable persistent storage and unique network identifiers. They support ordered, graceful deployment, scaling, and deletion. Typical examples include MySQL-HA and etcd. + +Pod +--- + +A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates an application container (in some cases, multiple containers), storage resources, a unique network IP address, and options that govern how the container should run. + +Canary Release +-------------- + +Grayscale release is essential for smooth rollout of iterative software products in production environments. A certain proportion of production traffic on the live network is distributed to a new version of the application to test the version's performance and detect faults while ensuring stable running of the system. + +Blue-Green Deployment +--------------------- + +Blue-green deployment is a zero-downtime deployment mode. A new version of an application is deployed and tested in a production environment while the live environment continues to serve all production traffic. When you confirm that the new version is functioning properly, traffic is then distributed to the new version. At the same time, the old version is upgraded to the new version. Blue-green deployment allows you to quickly switch between the two versions to effectively prevent service disruption during the upgrade. + +Traffic Management +------------------ + +Traffic management provides you with visualized network statuses of cloud native applications and allows you to manage and configure network connections and security policies online. Currently, it supports connection pool, outlier detection, load balancing, HTTP header, fault injection, etc. + +Connection Pool Management +-------------------------- + +Thresholds for TCP and HTTP connections and request pools to prevent a service from overloading. + +Outlier Detection +----------------- + +Quick response and service access fault isolation are configured to prevent a cascade of network and service calling faults. In this way, the fault impact is curbed. The overall system performance deterioration or avalanche is prevented. diff --git a/umn/source/service_overview/constraints.rst b/umn/source/service_overview/constraints.rst new file mode 100644 index 0000000..12cd989 --- /dev/null +++ b/umn/source/service_overview/constraints.rst @@ -0,0 +1,31 @@ +:original_name: asm_productdesc_0004.html + +.. _asm_productdesc_0004: + +Constraints +=========== + +Constraints on Clusters +----------------------- + +Before creating a service mesh, ensure that you have an available cluster. Cluster versions and mesh versions must meet the adaptation rules listed in :ref:`Table 1 `. + +.. _asm_productdesc_0004__table1495413335343: + +.. table:: **Table 1** Adaptation rules between ASM and cluster versions + + =========== ============================= + ASM Version Cluster Version + =========== ============================= + 1.15 v1.21, v1.23, v1.25, or v1.27 + 1.18 v1.25, v1.27, or v1.28 + =========== ============================= + +Containers on the node running Ubuntu 22.04 in a CCE Turbo cluster cannot be added to a service mesh earlier than v1.18. + +- Ubuntu 22.04 + +Constraints on Service Meshes +----------------------------- + +When you use service meshes for service governance, a Deployment can only match with one service to avoid abnormal grayscale release, gateway access, or other functions. diff --git a/umn/source/service_overview/index.rst b/umn/source/service_overview/index.rst new file mode 100644 index 0000000..e6da59a --- /dev/null +++ b/umn/source/service_overview/index.rst @@ -0,0 +1,28 @@ +:original_name: asm_pd_0001.html + +.. _asm_pd_0001: + +Service Overview +================ + +- :ref:`Infographic for ASM ` +- :ref:`Introduction ` +- :ref:`Advantages ` +- :ref:`Application Scenarios ` +- :ref:`Constraints ` +- :ref:`Basic Concepts ` +- :ref:`Recommended Node Specifications ` +- :ref:`Related Services ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + infographic_for_asm + introduction + advantages + application_scenarios/index + constraints + basic_concepts + recommended_node_specifications + related_services diff --git a/umn/source/service_overview/infographic_for_asm.rst b/umn/source/service_overview/infographic_for_asm.rst new file mode 100644 index 0000000..b634706 --- /dev/null +++ b/umn/source/service_overview/infographic_for_asm.rst @@ -0,0 +1,10 @@ +:original_name: asm_productdesc_0017.html + +.. _asm_productdesc_0017: + +Infographic for ASM +=================== + +|image1| + +.. |image1| image:: /_static/images/en-us_image_0000001918938240.png diff --git a/umn/source/service_overview/introduction.rst b/umn/source/service_overview/introduction.rst new file mode 100644 index 0000000..a20c2ce --- /dev/null +++ b/umn/source/service_overview/introduction.rst @@ -0,0 +1,82 @@ +:original_name: asm_productdesc_0001.html + +.. _asm_productdesc_0001: + +Introduction +============ + +What Is Application Service Mesh? +--------------------------------- + +Application Service Mesh (ASM) is a non-intrusive solution for you to manage microservice lifecycle and traffic. It is compatible with the Kubernetes and Istio ecosystems and hosts a wide range of features such as load balancing, outlier detection, and fault injection. It also provides diversified built-in grayscale releases, including canary release and blue-green deployment, for one-stop, automated release. + +What Is Istio? +-------------- + +Istio is an open platform that provides connection, protection, control, and observation functions. By providing a complete non-intrusive microservice governance solution, Istio can well resolve service network governance issues such as cloud-native service management, network connection, and security management. + +With the popularization of microservices, greater challenges emerge in the basic operations and advanced O&M of the distributed microservice architecture. + +At a high level, Istio helps reduce the complexity of application deployments, and eases the strain on your development teams. It is a fully open-source service mesh that can be transparently layered onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, or telemetry or policy system. Istio's diverse feature set lets you successfully and efficiently run a distributed microservice architecture, and provides a unified way to secure, connect, and monitor microservices. + +**Service Mesh** + +The term service mesh is used to describe the network of microservices that make up applications and the interactions between applications. As a service mesh grows in size and complexity, it can become harder to understand and manage. You need to take care of basic operations, such as service discovery, load balancing, failure recovery, metrics, and monitoring. Advanced O&M includes blue-green deployment, canary release, rate limiting, access control, and end-to-end authentication. + +Why Use Istio? +-------------- + +Istio provides behavioral insights and operational control over the service mesh as a whole, offering a complete solution to satisfy the diverse requirements of microservice applications. + +Kubernetes allows you to deploy and upgrade applications, and manage running traffic. However, capabilities such as outlier detection and rate limiting are not supported. Istio, as an open platform built based on Kubernetes, provides complementary capabilities to Kubernetes in microservice governance. + +You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all networking requests between microservices, then configure and manage Istio using its control plane functionality, which includes: + +- Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic. +- Fine-grained control of traffic behavior with rich routing rules, retries, and fault injection. +- Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress. +- Secure service-to-service communication in a cluster with strong identity-based authentication and authorization. + +Istio aims to achieve scalability and meet various deployment requirements. + +Features +-------- + +**Grayscale release** + +- Grayscale policies based on request content: You can set criteria based on request content, such as header and cookie. Only requests meeting the criteria will be distributed to the grayscale version. +- Grayscale policies based on traffic ratio: You can set specific ratio for the traffic to be distributed to the grayscale version. +- Canary release: Guidance will be provided to help you perform canary release on a service, including rolling out a grayscale version, observing the running and traffic of the grayscale version, configuring grayscale release policies, and diverging the traffic. +- Blue-green deployment: Guidance will be provided to help you perform blue-green deployment on a service, including rolling out a grayscale version, observing the running of the grayscale version, observing the traffic, and switching the traffic. + +**Traffic management** + +- Layer-7 connection pool management: You can set the maximum number of HTTP requests, maximum number of retry times, maximum number of pending requests, maximum number of requests for each connection, and maximum connection idle period. +- Layer-4 connection pool management: You can set the maximum TCP connections, connection timeout duration, maximum non-responses, minimum idle period, and health check interval. +- Outlier detection: You can configure outlier detection rules, such as the number of consecutive errors allowed before a pod is evicted, check period, base ejection time, and maximum percentage of ejected pods. +- Retry: You can configure the number of HTTP retry times, retry timeout duration, and retry condition. +- Timeout: You can configure the HTTP request timeout duration. +- Load balancing: You can configure multiple load balancing policies, such as random, round robin, least connections, and consistent hashing. +- HTTP header: You can flexibly add, edit, and remove HTTP headers, including the operations on the HTTP headers before the request is forwarded to the destination service and before the response is returned to the client. +- Fault injection: You can configure delay and abort faults. + +**Security** + +- Peer authentication: Peer authentication defines how traffic reaches the current service pod through the tunnel (or not through the tunnel). Currently, three authentication policies are supported: **UNSET**, **PERMISSIVE**, and **STRICT**. +- Access authorization: Access authorization controls the access to services in the mesh and determines whether a request can be sent to the current service. + +**Observability** + +- Application access topology: An application access topology shows the dependencies between services. +- Service running monitoring: Service access information, including service information, different versions of the service, QPS, and latency can be monitored. +- Access logs: Service access logs can be collected and searched. + +**Framework of the mesh data plane** + +- Spring Cloud: supports unified management of services developed using Spring Cloud SDK. +- Dubbo: supports unified management of services developed using Dubbo SDK. + +**Compatibility and extension** + +- Community compatibility: ASM APIs are fully compatible with the Istio community. +- Support for community add-ons: Tracing, Prometheus, Kiali, and Grafana are supported. diff --git a/umn/source/service_overview/recommended_node_specifications.rst b/umn/source/service_overview/recommended_node_specifications.rst new file mode 100644 index 0000000..bafbc9b --- /dev/null +++ b/umn/source/service_overview/recommended_node_specifications.rst @@ -0,0 +1,49 @@ +:original_name: asm_productdesc_0006.html + +.. _asm_productdesc_0006: + +Recommended Node Specifications +=============================== + +Recommended Specifications for Exclusive Nodes: +----------------------------------------------- + +The performance of ASM is closely related to the cluster control plane (master nodes). Select appropriate node specifications based on your service requirements. + ++---------------------------------+--------------------------+---------------------------+ +| Total QPS (requests per second) | 0-20,000 | 20,000-60,000 | ++---------------------------------+--------------------------+---------------------------+ +| Specifications | 8 vCPUs and 16 GB memory | 16 vCPUs and 32 GB memory | ++---------------------------------+--------------------------+---------------------------+ + +.. note:: + + - The total QPS is the sum of requests of all services in all applications per second in a cluster. + - The function of recommending a proper amount of memory resources on the control plane based on the number of application service instances is coming soon. + +ingressgateway Resource Consumption Reference +--------------------------------------------- + +The resource consumed by each ingressgateway pod is affected by the connection type, number of connections, and QPS. For details, see the following tables: + +.. table:: **Table 1** Memory consumption of persistent connections + + =========== ================= + Connections Memory Usage (MB) + =========== ================= + 1 0.055 + 1,000 55 + 10,000 550 + =========== ================= + +.. table:: **Table 2** CPU and memory usage of short connections + + ====== ============= ================= + QPS CPU Usage (m) Memory Usage (MB) + ====== ============= ================= + 100 30 100 + 1,000 300 100 + 10,000 3,000 150 + ====== ============= ================= + +The preceding data is for reference only. The actual resource consumption depends on the actual service model. diff --git a/umn/source/service_overview/related_services.rst b/umn/source/service_overview/related_services.rst new file mode 100644 index 0000000..834636f --- /dev/null +++ b/umn/source/service_overview/related_services.rst @@ -0,0 +1,36 @@ +:original_name: asm_productdesc_0007.html + +.. _asm_productdesc_0007: + +Related Services +================ + +:ref:`Figure 1 ` shows the dependencies between ASM and other services. + +.. _asm_productdesc_0007__fig531125816123: + +.. figure:: /_static/images/en-us_image_0000001303344393.png + :alt: **Figure 1** Dependencies between ASM and other services + + **Figure 1** Dependencies between ASM and other services + +Cloud Container Engine (CCE) +---------------------------- + +Cloud Container Engine (CCE) is a high-performance, high-reliability service through which enterprises can manage containerized applications. CCE supports native Kubernetes applications and tools, allowing you to easily set up a container runtime environment on the cloud. + +You can enable the service mesh function for CCE clusters to manage the services in the clusters. + +Elastic Load Balance (ELB) +-------------------------- + +ELB automatically distributes access traffic to multiple cloud servers to balance the loads. It enhances an application's fault tolerance and service continuity. + +You can use ELB to access ASM from outside. + +Application Performance Management (APM) +---------------------------------------- + +Application Performance Management (APM) monitors and manages the performance of cloud applications in real time. APM provides performance analysis of distributed applications, helping O&M personnel quickly locate and resolve faults and performance bottlenecks. + +You can use APM to manage trace topologies of all the services in service meshes and traces in distributed systems. It can help you quickly locate faults and analyze root causes. diff --git a/umn/source/user_guide/application_service_mesh.rst b/umn/source/user_guide/application_service_mesh.rst new file mode 100644 index 0000000..c606287 --- /dev/null +++ b/umn/source/user_guide/application_service_mesh.rst @@ -0,0 +1,12 @@ +:original_name: asm_01_0016.html + +.. _asm_01_0016: + +Application Service Mesh +======================== + +Application Service Mesh (ASM) is a service mesh platform developed based on Istio. It seamlessly interconnects with Cloud Container Engine (CCE), an enterprise-level Kubernetes cluster service. With better usability, reliability, and visualization, ASM provides you with out-of-the-box features and enhanced user experience. + +ASM is a non-intrusive microservice governance solution that provides full-lifecycle management and traffic management. It is compatible with the Kubernetes and Istio ecosystems and provides a wide range of features such as load balancing, outlier detection, and rate limiting. ASM provides diversified built-in grayscale releases, including canary release and blue-green deployment, enabling one-stop automatic release management. + +For more about ASM, see :ref:`Introduction `. diff --git a/umn/source/user_guide/creating_a_service_mesh/creating_a_service_mesh.rst b/umn/source/user_guide/creating_a_service_mesh/creating_a_service_mesh.rst new file mode 100644 index 0000000..77ba7ea --- /dev/null +++ b/umn/source/user_guide/creating_a_service_mesh/creating_a_service_mesh.rst @@ -0,0 +1,137 @@ +:original_name: asm_01_0020.html + +.. _asm_01_0020: + +Creating a Service Mesh +======================= + +ASM allows you to create a service mesh of the Basic edition, which is a standard service mesh available for commercial use. + +Prerequisites +------------- + +A CCE cluster is available. + +Constraints +----------- + +- ASM depends on the domain name resolution of CoreDNS. Before creating a service mesh for a cluster, ensure that the cluster has required resources and CoreDNS is running normally. +- Istio components v1.13 and v1.15 cannot run on nodes running CentOS or EulerOS 2.5. When creating a service mesh, do not specify these types of nodes as master nodes. + +Procedure +--------- + +#. Log in to the ASM console. + +#. Click Create Mesh in the upper right corner. + +#. Configure the following parameters. + + - **Mesh Edition** + + Only service meshes of the Basic edition are supported. + + - **Mesh Name** + + Enter a service mesh name, which consists of 4 to 64 characters. It must start with a lowercase letter and cannot end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed. + + Service mesh names under the same account must be unique and cannot be modified after creation. + + - **Istio Version** + + Select the Istio version supported by the service mesh. + + - **Enable IPv6** + + Determine whether to enable IPv6. This option is supported only in Istio 1.18 or later. + + - **Cluster** + + Select the target cluster from the cluster list or enter the target cluster name in the upper right corner of the list to search for it. You can select only the clusters which versions are supported by the current mesh version. + + - **Mesh Control Plane Node** + + To install the control plane components for the service mesh of the Basic edition in your cluster, you need to select a node for installation. If HA is required, you can select two or more nodes from different AZs. + + The selected node is labeled with **istio:master**, and the components are scheduled to this node. + + - **Observability Configuration** + + - **Application Metrics** + + If this option is enabled, you can build service access metrics, application topologies, and service health and SLO definitions in the service mesh. + + - **Access Logging** + + If this option is enabled, you can query inter-service access records in the service mesh to locate exceptions. After enabling this option, you need to select the Log Tank Service (LTS) log group and log stream. Access logs will be transmitted to the log stream. You can view the access logs on the **Monitoring Center** > **Access Logs** page. + + .. note:: + + - Only Istio 1.18 or later can work with LTS to collect and store access logs. To ensure logs are reported to LTS, install CCE Log-Agent on the **Add-ons** page in advance. + + - Tracing + + - **Sampling Rate**: Number of requests generated by the tracing/Total number of requests + + - **Version**: the tracing service. If you select **Third-party Jaeger/Zipkin service**, you need to set **Service Address** and **Service Port**, which indicate the address and port number used by the third-party tracing service to receive requests. + + .. note:: + + - Only Istio 1.15 or later support the third-party tracing service. + - If you want to use the third-party Jaeger or Zipkin service, install Jaeger or Zipkin first. Alternatively, you can obtain the service address after installing Jaeger or Zipkin by referring to section "Installing Jaeger/Zipkin" in the *FAQs*. + - The default service ports of Jaeger and Zipkin are both 9411. If you customize the service port during Jaeger or Zipkin installation, replace **Service Port** with the actual value. + +#. (Optional) Configure advanced settings. + + - **Sidecar Configuration** + + Select a namespace and label it with **istio-injection=enabled**. All pods in the namespace will be injected with an istio-proxy sidecar. + + You can inject a sidecar in **Mesh Configuration** > **Sidecar Management** after the mesh is created. For details, see :ref:`Injecting a Sidecar `. + + - **Restart Existing Services** + + |image1|: Pods of the existing services in the namespace will be restarted, which will temporarily interrupt your services. The **istio-proxy** sidecar is automatically injected into the pods of the existing services. + + |image2|: The **istio-proxy** sidecar cannot be automatically injected into the pods of the existing services. You need to manually restart the workloads on the CCE console to inject the sidecar. + + - **Traffic Interception Settings** + + .. note:: + + By default, sidecars intercept all inbound and outbound traffic of pods. You can modify the default traffic rules in **Traffic Interception Settings**. + + **Inbound Ports**: Inbound ports separated by commas (,). You can use this field to specify the ports that will be included or excluded for inbound traffic redirection. + + - **Include only specified ports** means that the traffic to services in a service mesh over specified ports will be redirected to the sidecar. + + - **Exclude only specified ports** means that the traffic to services in a service mesh over the ports except the specified ports will be redirected to the sidecar. + + **Outbound Ports**: Outbound ports separated by commas (,). You can use this field to specify the ports that will be included or excluded for outbound traffic redirection. + + - **Include only specified ports** means that the traffic from services in a service mesh over specified ports will be redirected to the sidecar. + + - **Exclude only specified ports** means that the traffic from services in a service mesh over the ports except the specified ports will be redirected to the sidecar. + + **Outbound IP Ranges**: IP address ranges separated by commas (,) in CIDR format. You can use this field to specify the IP ranges that will be excluded from redirection to the sidecar. + + - **Include only specified IP ranges** means that the traffic from specified IP ranges will be redirected to the sidecar. + + - **Exclude only specified IP ranges** means that the traffic from IP ranges except the specified IP ranges will be redirected to the sidecar. + + - **Resource Tags** + + Enter the tag key and tag value. A maximum of 20 tags can be added. + +#. Review the service mesh configuration in the **Configuration List** on the right of the page and click **Submit**. + + It takes about 1 to 3 minutes to create a service mesh. If the service mesh status changes from **Installing** to **Running**, the service mesh is successfully created. + + .. note:: + + When the service mesh is enabled, the following operations are performed: + + - Helm orchestrates the application into a Release as the resource of the service mesh control plane. + +.. |image1| image:: /_static/images/en-us_image_0000001920032153.png +.. |image2| image:: /_static/images/en-us_image_0000001494249996.png diff --git a/umn/source/user_guide/creating_a_service_mesh/index.rst b/umn/source/user_guide/creating_a_service_mesh/index.rst new file mode 100644 index 0000000..54496ad --- /dev/null +++ b/umn/source/user_guide/creating_a_service_mesh/index.rst @@ -0,0 +1,14 @@ +:original_name: asm_01_0017.html + +.. _asm_01_0017: + +Creating a Service Mesh +======================= + +- :ref:`Creating a Service Mesh ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + creating_a_service_mesh diff --git a/umn/source/user_guide/gateway_management/adding_a_gateway.rst b/umn/source/user_guide/gateway_management/adding_a_gateway.rst new file mode 100644 index 0000000..dfd55cf --- /dev/null +++ b/umn/source/user_guide/gateway_management/adding_a_gateway.rst @@ -0,0 +1,109 @@ +:original_name: asm_01_0056.html + +.. _asm_01_0056: + +Adding a Gateway +================ + +A gateway enables unified entry, traffic management, security, and service isolation. + +Prerequisites +------------- + +Gateways use load balancers of ELB to provide network access. Before adding a gateway, you need to create a load balancer. + +When creating a load balancer, you need to ensure that it belongs to the same VPC as the cluster. + +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 on the left, choose **Gateway Management** and click **Add Gateway**. + +#. Configure the following parameters. + + - **Gateway Name** + + Enter a gateway name. Enter 4 to 59 characters starting with a lowercase letter and ending with a lowercase letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. + + - **Cluster** + + Select the cluster to which the gateway belongs. + + - **Load Balancer** + + - Gateways use shared load balancers of ELB for the access over both public and private IPv4 networks. + + - **Listener** + + Gateways configure a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. + + - **External Protocol** + + Select one to match the protocol type of your service. **HTTP**, **gRPC**, **TCP**, **TLS**, and **HTTPS** are supported. + + - **External Port** + + Enter the port number exposed in the Load Balancer Service address. The port number can be specified randomly. + + - **TLS Termination** + + If **External Protocol** is **HTTPS**, **TLS Termination** is enabled and cannot be disabled. + + If **External Protocol** is **TLS**, you can enable or disable **TLS Termination**. If you enable TLS termination, bind a certificate to support TLS-based data transmission encryption and authentication. If you disable TLS termination, encrypted TLS data will be directly forwarded. + + - **Secret Certificate** + + - When configuring a TLS protocol with TLS termination enabled, you need to bind a certificate to support TLS-based data transmission encryption and authentication. + - When configuring the HTTPS protocol, you need to bind a secret certificate. + + - **Earliest TLS Version Supported/Latest TLS Version Supported** + + When configuring a TLS protocol with TLS termination enabled or an HTTPS protocol, you can select the earliest and latest TLS versions. + +#. (Optional) Configure routing parameters. + + When the access address of a request matches the forwarding policy (which consists of a domain name and URL. If the domain name is left empty, the ELB IP address is used by default), the request is forwarded to the corresponding target Service for processing. Click |image1|. The **Add Route** dialog box is displayed. + + - **Domain Name** + + Enter the external domain name of the service. If this parameter is left blank, the IP address of the load balancer is used by default. If you enable TLS termination, enter a domain name configured in the certificate for SNI domain name verification. + + - **URL Matching Rule** + + - **Prefix**: A URL can be accessed if its prefix is the same as that you configure. For example, **/healthz/v1** and **/healthz/v2**. + - **Exact**: Only the URL that fully matches the values you set can be accessed. For example, if the URL is set to **/healthz**, only **/healthz** can be accessed. + + - **URL** + + Mapping URL supported by the service, for example, **/example**. + + - **Namespace** + + Select the namespace to which the gateway belongs. + + - **Target Service** + + Service of the gateway. Select a value from the drop-down list box. The target service is filtered based on the corresponding gateway protocol. For details about the filtering rules, see :ref:`Why Cannot I Select the Corresponding Service When Adding a Route? ` + + The service which configuration diagnosis fails cannot be selected. You need to fix the issues first. For details, see :ref:`Manual Fixing Items ` or :ref:`Auto Fixing Items `. + + - **Access Port** + + Only ports that match external protocols are displayed. + + - **Rewrite** + + (This parameter is configurable when the external protocol is HTTP.) + + Rewrite the HTTP URI and host/authority header before forwarding. Disabled by default. To enable it, configure the following parameters: + + - URI: This value is used to rewrite the URI or prefix. + - Host/Authority Header: This value is used to rewrite the HTTP host/authority header. + +#. Click **OK**. + + You can obtain the external network access address of the service in the **Service Management** page. + +.. |image1| image:: /_static/images/en-us_image_0000001209954130.png diff --git a/umn/source/user_guide/gateway_management/adding_a_route.rst b/umn/source/user_guide/gateway_management/adding_a_route.rst new file mode 100644 index 0000000..b7847d3 --- /dev/null +++ b/umn/source/user_guide/gateway_management/adding_a_route.rst @@ -0,0 +1,59 @@ +:original_name: asm_01_0057.html + +.. _asm_01_0057: + +Adding a Route +============== + +Scenario +-------- + +You can add multiple routes and configure multiple forwarding policies for a created gateway. + +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 on the left, choose **Gateway Management**, select the target gateway, click **Add Route** in the **Operation** column, and configure the following parameters: + + - **Domain Name** + + Enter the external domain name of the service. If this parameter is left blank, the IP address of the load balancer is used by default. If you enable TLS termination, enter a domain name configured in the certificate for SNI domain name verification. + + - **URL Matching Rule** + + - **Prefix**: A URL can be accessed if its prefix is the same as that you configure. For example, **/healthz/v1** and **/healthz/v2**. + - **Exact**: Only the URL that fully matches the values you set can be accessed. For example, if the URL is set to **/healthz**, only **/healthz** can be accessed. + + - **URL** + + Mapping URL supported by the service, for example, **/example**. + + .. note:: + + The URLs of the same gateway must be unique. + + - **Namespace** + + Select the namespace to which the gateway belongs. + + - **Target Service** + + Service of the gateway. Select a value from the drop-down list box. The target service is filtered based on the corresponding gateway protocol. For details about the filtering rules, see :ref:`Why Cannot I Select the Corresponding Service When Adding a Route? `. + + The service which configuration diagnosis fails cannot be selected. You need to fix the issues first. For details, see :ref:`Manual Fixing Items ` or :ref:`Auto Fixing Items `. + + - **Access Port** + + Only ports that match external protocols are displayed. + + - **Rewrite** + + (This parameter is configurable when the external protocol is HTTP.) + + Rewrite the HTTP URI and host/authority header before forwarding. Disabled by default. To enable it, configure the following parameters: + + - URI: This value is used to rewrite the URI or prefix. + - Host/Authority Header: This value is used to rewrite the HTTP host/authority header. + +#. Click **OK**. diff --git a/umn/source/user_guide/gateway_management/index.rst b/umn/source/user_guide/gateway_management/index.rst new file mode 100644 index 0000000..1876983 --- /dev/null +++ b/umn/source/user_guide/gateway_management/index.rst @@ -0,0 +1,16 @@ +:original_name: asm_01_0033.html + +.. _asm_01_0033: + +Gateway Management +================== + +- :ref:`Adding a Gateway ` +- :ref:`Adding a Route ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + adding_a_gateway + adding_a_route diff --git a/umn/source/user_guide/grayscale_release/basic_operations_on_a_grayscale_task.rst b/umn/source/user_guide/grayscale_release/basic_operations_on_a_grayscale_task.rst new file mode 100644 index 0000000..ee4a194 --- /dev/null +++ b/umn/source/user_guide/grayscale_release/basic_operations_on_a_grayscale_task.rst @@ -0,0 +1,108 @@ +:original_name: asm_01_0037.html + +.. _asm_01_0037: + +Basic Operations on a Grayscale Task +==================================== + +Description +----------- + +Basic operations on a grayscale version are performed by modifying the configuration of the DestinationRule and VirtualService resources of Istio. After the modification is complete, wait for about 10 seconds for the new policy to take effect. + +Modifying the Traffic Policy of a Grayscale Version +--------------------------------------------------- + +**Modifying a grayscale policy that is based on traffic ratio** + +For such a grayscale policy that is based on traffic ratio, you can gradually increase the traffic ratio of the grayscale version to avoid service risks caused by direct traffic switchover. To change the traffic ratio, perform the following steps: + +#. 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 **Grayscale Release**. Then click the target canary release task. + +#. On the **Configure Traffic Policy** page, set the traffic ratio of the grayscale version. + + If the traffic ratio of the grayscale version is set to **x**, the traffic ratio of the original version is automatically adjusted to **100-x**. + +#. Click **Deliver Policy**. + +**Modifying a grayscale policy that is based on request content** + +With such a policy, a grayscale version can be accessed only when the traffic meets the rules based on Cookies, Headers, Queries, Allowed Operating Systems, and Allowed Browsers. In real-world use cases, rules may be modified for multiple times to fully verify the performance of the grayscale version. + +#. 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 on the left, choose **Grayscale Release** and click the target canary release task. +#. On the **Configure Traffic Policy** page, reconfigure **Cookie**, **Header**, **Query**, **Allowed OS**, and **Allowed Browser**. +#. Click **Deliver Policy**. + +Switching the Grayscale Policy Type +----------------------------------- + +You can change the type of a grayscale policy from **based on request content** to **based on traffic ratio** and vice versa. After this operation is complete, all configured rules become invalid and all traffic is redistributed based on the new policy. + +.. important:: + + Grayscale policies can be changed only for running tasks. After a grayscale version is released (that is, the new version completely takes over the traffic and the old version has been brought offline), its grayscale policy cannot be reconfigured. + +#. 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 on the left, choose **Grayscale Release** and click the target canary release task. +#. On the **Configure Traffic Policy** page, change the policy type. +#. Click **Deliver Policy**. + +Taking Over All Traffic +----------------------- + +After you click **Take Over All Traffic**, the original version or grayscale version takes over all traffic. + +#. 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 on the left, choose **Grayscale Release** and click the target grayscale release task. +#. On the **Monitor and Manage Traffic** page, click **Take Over All Traffic** next to the target version. +#. In the displayed dialog box, click **OK**. + +Terminating a Grayscale Release Task +------------------------------------ + +After the grayscale version takes over all traffic, you can terminate the grayscale task. After the grayscale task is canceled, the original version will be brought offline, and all workloads and Istio configuration resources will be deleted. + +#. 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 on the left, choose **Grayscale Release** and click the target grayscale release task. + +#. On the **Monitor and Manage Traffic** page, click **Take Over All Traffic** next to the grayscale version. + +#. Click **Terminate Task** in the lower right corner. + +#. In the displayed dialog box, click **OK**. + + You can go to the **Terminated Tasks** tab page to view the finished grayscale task. The **Release Result** is **Released successfully**. + +Canceling a Grayscale Release Task +---------------------------------- + +After the original version takes over all traffic, you can cancel the grayscale task. + +#. 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 on the left, choose **Grayscale Release** and click the target grayscale release task. + +#. On the **Monitor and Manage Traffic** page, click **Take Over All Traffic** next to the original version. + +#. Click **Cancel Task** in the lower right corner. You can also click |image1| in the upper right corner of a task in the grayscale task list. + +#. In the displayed dialog box, click **OK**. + + You can go to the **Terminated Tasks** tab page to view the finished grayscale task. The **Release Result** is **Released canceled**. + +Viewing Terminated Grayscale Release Tasks +------------------------------------------ + +You can view canceled and finished grayscale tasks on the **Terminated Tasks** tab page. + +#. 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 on the left, choose **Grayscale Release** and click the **Terminated Tasks** tab page. + + You can view the release task name, release result, service, and release time, and delete a terminated task. + +.. |image1| image:: /_static/images/en-us_image_0000001209978068.png diff --git a/umn/source/user_guide/grayscale_release/creating_a_grayscale_release_task.rst b/umn/source/user_guide/grayscale_release/creating_a_grayscale_release_task.rst new file mode 100644 index 0000000..d364c29 --- /dev/null +++ b/umn/source/user_guide/grayscale_release/creating_a_grayscale_release_task.rst @@ -0,0 +1,148 @@ +:original_name: asm_01_0036.html + +.. _asm_01_0036: + +Creating a Grayscale Release Task +================================= + +Basic Concepts +-------------- + +- Grayscale version + + Only one grayscale version can be released for a service. You can configure grayscale policies for the version. + +- Grayscale policy + + Before releasing a new service version in the production environment and letting it serve all the live traffic, you can add a grayscale version and configure grayscale policies to serve just a proportion of the traffic. After the grayscale version has run stably for a period, it can serve as the default version to take over all traffic in place of the original version in the production environment. + + +Creating a Grayscale Release Task +--------------------------------- + +#. Log in to the ASM console and go to the **Create a grayscale release task** page by one of the following ways: + + - (Shortcut) In the upper right corner of an Enterprise mesh, click |image1|. + - (Shortcut) In the center of the target mesh, click **Create a grayscale release task**. + - Create a grayscale release task on the mesh details page. + + a. Click the target mesh and go to its details page, click **Grayscale Release** in the navigation pane on the left. + b. If no grayscale task is running, click **Create Release Task** in the **Canary Release** or **Blue-Green Deployment** area. If there is an ongoing grayscale task, click **Grayscale Release** in the upper right corner. + +#. Configure basic information of the grayscale release task. + + - **Grayscale Release Form** + + Select **Canary Release** or **Blue-Green Deployment** as required. For details about the differences between the two forms, see :ref:`Grayscale Release Overview `. + + - **Task Name** + + Customize a grayscale release task name. Enter 4 to 63 characters, starting with a lowercase letter and ending with a letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed. + + - **Namespace** + + Select the namespace to which the service belongs. + + - **Service** + + Select the service to be released from the drop-down list box. Services that are running grayscale tasks cannot be selected. They are automatically filtered out from the list. + + - **Workload** + + Select the workload to which the service belongs. + + - **Version** + + Current service version number, which cannot be changed. + +#. Configure grayscale version information. + + - **Cluster** + + Select the cluster on which the grayscale version of the service will be deployed. + + - **Version** + + Enter the grayscale version number of the service. + + - **Pods** + + Number of pods of the grayscale version. You can modify the number as required. Each pod of the grayscale version consists of containers deployed with the same image. + + - **Image Name** + + The image of the service is selected by default. + + - **Image Tag** + + Select the image tag of the grayscale version. + +#. Click **Release**. Wait for the grayscale version to be created. + + Ensure that all pods of the grayscale version are running normally and configure the traffic policy when the startup progress reaches 100%. You can view the pod monitoring information, including **Start Logs** and **Performance Monitoring** on the **View Status** page. + +#. (For canary release only) Click **Configure Traffic Policy** to configure a traffic policy. + + **Policy Type**: The value can be **Based on traffic ratio** or **Based on request content**. + + - **Based on traffic ratio** + + A specified ratio of traffic will be directed to the grayscale version. For example, 75% of the traffic is directed to the original version, and 25% is directed to the grayscale version. In actual applications, you can gradually increase the traffic ratio of the grayscale version and deliver policies to monitor the performance of the grayscale version. + + + .. figure:: /_static/images/en-us_image_0000001210438852.png + :alt: **Figure 1** Based on traffic ratio + + **Figure 1** Based on traffic ratio + + **Traffic** **ratio**: You can set the traffic ratio for the original version and grayscale version. The system distributes traffic to the two versions based on the specific traffic ratio. + + - **Based on request content** + + The grayscale version can be accessed only when the traffic meets the rules based on the cookies, custom headers, queries, operating systems, and browsers. For example, only HTTP requests whose cookies meet **User=Internal** can be forwarded to the grayscale version. Other requests are still received by the original version. + + + .. figure:: /_static/images/en-us_image_0000001210119300.png + :alt: **Figure 2** Based on request content + + **Figure 2** Based on request content + + - **Cookie** + + **Regular expression**: When the cookie of a request matches the configured regular expression, the request will be distributed to the grayscale version. + + - **Header** + + - **Full match**: Only the URL that fully matches the values you set can be accessed. For example, if **Key** is set to **User** and **Value** is set to **Internal**, only requests whose headers contain **User** with the value **Internal** are responded by the service of the grayscale version. + + - **Regular expression**: When the header of a request matches the configured regular expression, the request will be distributed to the grayscale version. + + You can customize the key and value for filtering. The value supports the full match and regular expression. + + - **Query** + + - **Full match**: Only the URL that fully matches the values you set can be accessed. For example, if **Key** is set to **User** and **Value** is set to **Internal**, only requests whose queries contain **User** with the value **Internal** are responded by the service of the grayscale version. + + - **Regular expression**: When the query of a request matches the configured regular expression, the request will be distributed to the grayscale version. + + You can customize the key and value for filtering. The value supports the full match and regular expression. + + - **Allowed OS**: Select OSs that can access the grayscale version, including iOS, Android, Windows, and macOS. + + - **Allowed Browser**: Select browsers that can access the grayscale version, including Chrome and Internet Explorer. + + - **Traffic management YAML**: The rule YAML is automatically generated based on the configured parameters. + + .. note:: + + A traffic policy based on request content is valid only for the entry service that is directly accessed. If you want the traffic policy to be applied to all services, the header information of HTTP requests needs to be transferred in the service code. + + For example, if you configured a grayscale policy based on the request content for service **reviews** and did not transfer the HTTP request header information in the service code, the grayscale policy will not take effect when you send requests to service **productpage**. + + The reason is that when the **productpage** service calls the **reviews** service, the header information of the HTTP request you sent to **productpage** will be lost. As a result, the **reviews** service receives a request without the header information. The grayscale policy will not take effect. + +#. Click **Deliver Policy**. + + It takes several seconds for a grayscale policy to take effect. You can view the traffic monitoring of the service and the health monitoring of the original version and grayscale version. + +.. |image1| image:: /_static/images/en-us_image_0000001254994843.png diff --git a/umn/source/user_guide/grayscale_release/grayscale_release_overview.rst b/umn/source/user_guide/grayscale_release/grayscale_release_overview.rst new file mode 100644 index 0000000..4b168ef --- /dev/null +++ b/umn/source/user_guide/grayscale_release/grayscale_release_overview.rst @@ -0,0 +1,32 @@ +:original_name: asm_01_0035.html + +.. _asm_01_0035: + +Grayscale Release Overview +========================== + +When switching between old and new services, you may be challenged in ensuring the system service continuity. If a new service version is directly released to all users at a time, it can be risky because once an online accident or bug occurs, the impact on users is great. It could take a long time to fix the issue. Sometimes, the version has to be rolled back, which severely affects user experience. + +Several release policies are developed for service upgrade: canary release, blue-green deployment, A/B testing, rolling upgrade, and batch suspension of release. Traffic loss or service unavailability caused by releases can be avoided as much as possible. Currently, ASM supports canary release and blue-green deployment. + +Canary Release +-------------- + +Canary release is also called grayscale release. It is a smooth iteration mode for version upgrade. During the upgrade, some users use the new version, while other users continue to use the old version. After the new version is stable and ready, it gradually takes over all the live traffic. In this way, service risks brought by the release of the new version can be minimized, the impact of faults can be reduced, and quick rollback is supported. + + +.. figure:: /_static/images/en-us_image_0000001254994475.png + :alt: **Figure 1** Canary release process + + **Figure 1** Canary release process + +Blue-Green Deployment +--------------------- + +Blue-green deployment provides a zero-downtime, predictable manner for releasing applications to reduce service interruption during the release. A new version is deployed while the old version is retained. The two versions are online at the same time. The new and old versions work in hot backup mode. The route weight is switched (0 or 100) to enable different versions to go online or offline. If a problem occurs, the version can be quickly rolled back. + + +.. figure:: /_static/images/en-us_image_0000001210274518.png + :alt: **Figure 2** Blue-green deployment process + + **Figure 2** Blue-green deployment process diff --git a/umn/source/user_guide/grayscale_release/index.rst b/umn/source/user_guide/grayscale_release/index.rst new file mode 100644 index 0000000..9cd7547 --- /dev/null +++ b/umn/source/user_guide/grayscale_release/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_01_0034.html + +.. _asm_01_0034: + +Grayscale Release +================= + +- :ref:`Grayscale Release Overview ` +- :ref:`Creating a Grayscale Release Task ` +- :ref:`Basic Operations on a Grayscale Task ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + grayscale_release_overview + creating_a_grayscale_release_task + basic_operations_on_a_grayscale_task diff --git a/umn/source/user_guide/index.rst b/umn/source/user_guide/index.rst new file mode 100644 index 0000000..9329603 --- /dev/null +++ b/umn/source/user_guide/index.rst @@ -0,0 +1,30 @@ +:original_name: en-us_topic_0000001627845328.html + +.. _en-us_topic_0000001627845328: + +User Guide +========== + +- :ref:`Application Service Mesh ` +- :ref:`Creating a Service Mesh ` +- :ref:`Mesh Management ` +- :ref:`Service Management ` +- :ref:`Gateway Management ` +- :ref:`Grayscale Release ` +- :ref:`Mesh Configuration ` +- :ref:`Traffic Management ` +- :ref:`Security ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + application_service_mesh + creating_a_service_mesh/index + mesh_management/index + service_management/index + gateway_management/index + grayscale_release/index + mesh_configuration/index + traffic_management/index + security/index diff --git a/umn/source/user_guide/mesh_configuration/index.rst b/umn/source/user_guide/mesh_configuration/index.rst new file mode 100644 index 0000000..43d7589 --- /dev/null +++ b/umn/source/user_guide/mesh_configuration/index.rst @@ -0,0 +1,20 @@ +:original_name: asm_01_0038.html + +.. _asm_01_0038: + +Mesh Configuration +================== + +- :ref:`Overview ` +- :ref:`Sidecar Management ` +- :ref:`Istio Resource Management ` +- :ref:`Service Mesh Extension ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + overview + sidecar_management + istio_resource_management/index + service_mesh_extension diff --git a/umn/source/user_guide/mesh_configuration/istio_resource_management/configuring_istio_resources_using_yaml.rst b/umn/source/user_guide/mesh_configuration/istio_resource_management/configuring_istio_resources_using_yaml.rst new file mode 100644 index 0000000..b84d4cd --- /dev/null +++ b/umn/source/user_guide/mesh_configuration/istio_resource_management/configuring_istio_resources_using_yaml.rst @@ -0,0 +1,30 @@ +:original_name: asm_01_0048.html + +.. _asm_01_0048: + +Configuring Istio Resources Using YAML +====================================== + +You can modify all Istio resources (such as VirtualService and DestinationRule) of a service in YAML or JSON format on the **Istio Resource Management** page. You can also create new Istio resources. + +Modifying an Existing Istio Resource +------------------------------------ + +#. 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 **Mesh Configuration**. Then click the **Istio Resource Management** tab. + +#. In the drop-down list, select the Istio resource type (for example, Istio Resources: virtualservices) and the namespace to which the resource belongs. + +#. Click **Edit** in the **Operation** column. In the right pane, modify related configurations and click **OK**. + + The configuration file can be displayed in YAML or JSON format and can be downloaded to the local PC. + +Creating an Istio Resource +-------------------------- + +#. 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 **Mesh Configuration**. Then click the **Istio Resource Management** tab. +#. Click **Create** in the upper left corner of the list. +#. Edit the file in the right pane, or click **Import File** to upload the edited YAML or JSON file. +#. Confirm the file content and click **OK**. diff --git a/umn/source/user_guide/mesh_configuration/istio_resource_management/index.rst b/umn/source/user_guide/mesh_configuration/istio_resource_management/index.rst new file mode 100644 index 0000000..3c94b44 --- /dev/null +++ b/umn/source/user_guide/mesh_configuration/istio_resource_management/index.rst @@ -0,0 +1,14 @@ +:original_name: asm_01_0091.html + +.. _asm_01_0091: + +Istio Resource Management +========================= + +- :ref:`Configuring Istio Resources Using YAML ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + configuring_istio_resources_using_yaml diff --git a/umn/source/user_guide/mesh_configuration/overview.rst b/umn/source/user_guide/mesh_configuration/overview.rst new file mode 100644 index 0000000..f7fa8ca --- /dev/null +++ b/umn/source/user_guide/mesh_configuration/overview.rst @@ -0,0 +1,18 @@ +:original_name: asm_01_0039.html + +.. _asm_01_0039: + +Overview +======== + +Mesh configuration provides cluster management, sidecar management, Istio resource management, and upgrade capabilities. + +The mesh control plane workloads inject and manage sidecars of data plane pods, deliver policies and configurations, and collect monitoring data. Sidecars work with service containers in data plane pods, and they are in charge of routing and forwarding, traffic policy configuration, and monitoring data collection. + +The functions of each tab page in **Mesh Configuration** are as follows: + +- **Basic Information**: You can view the mesh name, ID, status, edition, version, observability, creation time, and clusters with the mesh enabled. +- **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 `. +- **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 `. +- **Upgrade**: You can upgrade the version of a service mesh. +- Mesh extension: provides the observability configuration. For details, see :ref:`Service Mesh Extension `. diff --git a/umn/source/user_guide/mesh_configuration/service_mesh_extension.rst b/umn/source/user_guide/mesh_configuration/service_mesh_extension.rst new file mode 100644 index 0000000..b61a94a --- /dev/null +++ b/umn/source/user_guide/mesh_configuration/service_mesh_extension.rst @@ -0,0 +1,33 @@ +: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**. diff --git a/umn/source/user_guide/mesh_configuration/sidecar_management.rst b/umn/source/user_guide/mesh_configuration/sidecar_management.rst new file mode 100644 index 0000000..0b5ab02 --- /dev/null +++ b/umn/source/user_guide/mesh_configuration/sidecar_management.rst @@ -0,0 +1,90 @@ +:original_name: asm_01_0041.html + +.. _asm_01_0041: + +Sidecar Management +================== + +On the **Sidecar Management** page, you can view information about all workloads injected with sidecars, perform sidecar injection, and configure sidecar resource limits. + +.. _asm_01_0041__section65931513505: + +Injecting a Sidecar +------------------- + +You can view the namespace and cluster to which the injected sidecar belongs. If no sidecar has been injected or you need to inject sidecar for more namespaces, perform the following operations: + +#. 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 **Mesh Configuration**. Then click the **Sidecar Management** tab. +#. Click **Sidecar Management**, select a namespace, determine whether to restart the existing services, and click **OK**. + + - **Namespace**: Select one or more namespaces. The system labels the namespaces with **istio-injection=enabled**. + + - **Restart Existing Services** + + |image1|: Pods of the existing services in the namespace will be restarted, which will temporarily interrupt your services. The **istio-proxy** sidecar is automatically injected into the pods of the existing services. + + |image2|: The **istio-proxy** sidecar cannot be automatically injected into the pods of the existing services. You need to manually restart the workloads on the CCE console to inject the sidecar. Whether to restart existing services affects only existing services. If the namespaces are labeled with **istio-injection=enabled**, sidecars will be automatically injected into new pods. + + - **Traffic Interception Settings** + + .. note:: + + By default, sidecars intercept all inbound and outbound traffic of pods. You can modify the default traffic rules in **Traffic Interception Settings**. + + **Inbound Ports**: Inbound ports separated by commas (,). You can use this field to specify the ports that will be included or excluded for inbound traffic redirection. + + - **Include only specified ports** means that the traffic to services in a service mesh over specified ports will be redirected to the sidecar. + + - **Exclude only specified ports** means that the traffic to services in a service mesh over the ports except the specified ports will be redirected to the sidecar. + + **Outbound Ports**: Outbound ports separated by commas (,). You can use this field to specify the ports that will be included or excluded for outbound traffic redirection. + + - **Include only specified ports** means that the traffic from services in a service mesh over specified ports will be redirected to the sidecar. + + - **Exclude only specified ports** means that the traffic from services in a service mesh over the ports except the specified ports will be redirected to the sidecar. + + **Outbound IP Ranges**: IP address ranges separated by commas (,) in CIDR format. You can use this field to specify the IP ranges that will be excluded from redirection to the sidecar. + + - **Include only specified IP ranges** means that the traffic from specified IP ranges will be redirected to the sidecar. + + - **Exclude only specified IP ranges** means that the traffic from IP ranges except the specified IP ranges will be redirected to the sidecar. + + .. note:: + + - If the system displays a message indicating that modification of namespace injection is not enabled in the following clusters, you need to run the **kubectl** command to enable namespace injection. For details, see :ref:`How Do I Enable Namespace Injection for a Cluster? `. + - After sidecar injection is enabled for a namespace of a cluster, sidecars are automatically injected for pods of all workloads in the namespace. If you do not want to inject sidecars for some workloads, see :ref:`How Do I Disable Sidecar Injection for Workloads? `. + +Viewing Workload Details +------------------------ + +The list displays all workloads created in the clusters managed by a mesh. You can view the workload name, cluster to which the workload belongs, service, and sidecar information of the workload, including the sidecar name, version, status, CPU usage, and memory usage. The procedure is as follows: + +#. In the drop-down list and search box in the upper right corner of the workload list, select a cluster and namespace, and enter the target workload name. + +#. Click |image3| in front of the workload to view the sidecar information of the workload. + + If the system displays a message indicating that there is no sidecar in the workload, no sidecar has been injected into the namespace to which the workload belongs. In this case, you can inject one into the namespace. For details, see :ref:`Injecting a Sidecar `. + +Configuring Sidecar Resource Limits +----------------------------------- + +You can configure the upper and lower limits of CPU and memory resources for sidecars (istio-proxy container). If the upper and lower resource limits are not set for a workload, a resource leak of this workload will make resources unavailable for other workloads deployed on the same node. In addition, workloads that do not have upper and lower resource limits cannot be accurately monitored. + +The default upper and lower limits of sidecar resources are as follows: + +- CPU (core): 0.1 to 2 (included) +- MEM (MiB): 128 to 1,024 (included) + +To change the value, perform the following operations: + +#. Click **Set Resource Limit** in the **Operation** column of the target workload. You can also select multiple workloads and click **Set Resource Limit** in the upper left corner of the workload list to configure sidecar resource limits in batches. + + - Minimum CPU: CPU request, the minimum number of CPU cores required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to a node only when the total available CPU on the node is greater than or equal to the number of CPU cores applied for the container. + - Maximum CPU: CPU limit, the maximum number of CPU cores required by a container. + - Minimum memory: memory request, the minimum amount of memory required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to this node only when the total available memory on the node is greater than or equal to the requested container memory. + - Maximum memory: memory limit, the maximum amount of memory required by a container. When the memory usage exceeds the specified memory limit, the pod may be restarted, which affects the normal use of the workload. + +.. |image1| image:: /_static/images/en-us_image_0000001930216052.png +.. |image2| image:: /_static/images/en-us_image_0000001256463368.png +.. |image3| image:: /_static/images/en-us_image_0000001200574170.png diff --git a/umn/source/user_guide/mesh_management/index.rst b/umn/source/user_guide/mesh_management/index.rst new file mode 100644 index 0000000..716a450 --- /dev/null +++ b/umn/source/user_guide/mesh_management/index.rst @@ -0,0 +1,16 @@ +:original_name: asm_01_0023.html + +.. _asm_01_0023: + +Mesh Management +=============== + +- :ref:`Mesh Events ` +- :ref:`Uninstalling a Mesh ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + mesh_events + uninstalling_a_mesh diff --git a/umn/source/user_guide/mesh_management/mesh_events.rst b/umn/source/user_guide/mesh_management/mesh_events.rst new file mode 100644 index 0000000..0b30079 --- /dev/null +++ b/umn/source/user_guide/mesh_management/mesh_events.rst @@ -0,0 +1,23 @@ +: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 diff --git a/umn/source/user_guide/mesh_management/uninstalling_a_mesh.rst b/umn/source/user_guide/mesh_management/uninstalling_a_mesh.rst new file mode 100644 index 0000000..0432b10 --- /dev/null +++ b/umn/source/user_guide/mesh_management/uninstalling_a_mesh.rst @@ -0,0 +1,44 @@ +:original_name: asm_01_0086.html + +.. _asm_01_0086: + +Uninstalling a Mesh +=================== + +Scenario +-------- + +When a mesh is no longer needed, 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. +- You need to ensure available nodes exist in the clusters for running the cleanup task to avoid uninstallation failure. + +Procedure +--------- + +#. Log in to the ASM console. + +#. Click |image1| in the target mesh. + +#. On the dialogue box displayed, select whether to restart existing services and read the precautions. + + By default, existing services are not restarted during the uninstallation. The injected istio-poxy sidecar is removed only after the existing services are restarted. If you want to restart the services, select **Yes**. Restarting the services will interrupt your services temporarily. + + .. note:: + + 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. + + - 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. + + 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**. + +.. |image1| image:: /_static/images/en-us_image_0000001255111219.png diff --git a/umn/source/user_guide/security/authenticating_jwt_requests_on_the_ingress_gateway_using_asm.rst b/umn/source/user_guide/security/authenticating_jwt_requests_on_the_ingress_gateway_using_asm.rst new file mode 100644 index 0000000..87ab099 --- /dev/null +++ b/umn/source/user_guide/security/authenticating_jwt_requests_on_the_ingress_gateway_using_asm.rst @@ -0,0 +1,146 @@ +:original_name: asm_01_0097.html + +.. _asm_01_0097: + +Authenticating JWT Requests on the Ingress Gateway Using ASM +============================================================ + +This section describes how to authenticate JWT requests on the ingress gateway using ASM to ensure that users access services through the ingress gateway with a reliable access token. + +Preparations +------------ + +#. A 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. + +Creating JWT Authentication +--------------------------- + +#. .. _asm_01_0097__li116016915174: + + Create a JWK. + + a. .. _asm_01_0097__li10148154317206: + + Visit `JWT tool website `__, set **Algorithm** to **RS512**, and obtain the public key (PUBLIC KEY). + + + .. figure:: /_static/images/en-us_image_0000001476967692.png + :alt: **Figure 1** Generating a public key + + **Figure 1** Generating a public key + + b. Select **PEM-to-JWK (RSA Only)** in the `JWK to PEM Convertor online `__ tool, enter the public key obtained in the previous step, and click **submit** to convert the public key into a JWK. + + + .. figure:: /_static/images/en-us_image_0000001477287480.png + :alt: **Figure 2** Converting the public key to a JWK + + **Figure 2** Converting the public key to a JWK + + .. code-block:: + + {"kty":"RSA","e":"AQAB","kid":"a78641b9-d81e-4241-b35a-71726c3fa053","n":"u1SU1LfVLPHCozMxH2Mo4lgOEePzNm0tRgeLezV6ffAt0gunVTLw7onLRnrq0_IzW7yWR7QkrmBL7jTKEn5u-qKhbwKfBstIs-bMY2Zkp18gnTxKLxoS2tFczGkPLPgizskuemMghRniWaoLcyehkd3qqGElvW_VDL5AaWTg0nLVkjRo9z-40RQzuVaE8AkAFmxZzow3x-VJYKdjykkJ0iT9wCS0DRTXu269V264Vf_3jvredZiKRkgwlL9xNAwxXFg0x_XFw005UWVRIkdgcKWTjpBP2dPwVZ4WWC-9aGVd-Gyn1o0CLelf4rEjGoXbAAEgAqeGUxrcIlbjXfbcmw"} + +#. .. _asm_01_0097__li20211184081913: + + Create JWT authentication. + + a. Log in to the ASM console and click the name of the target service mesh to go to its details page. + + b. In the navigation pane, choose **Service Management**. In the upper right corner of the list, select the namespace that your services belong to. + + c. Locate the **httpbin** service and click **Security** in the **Operation** column. In the window that slides out from the right, click **JWT Authentication** and then **Configure now**. In the displayed dialog box, set the following parameters: + + - **Issuer**: issuer of the JWT. Set this parameter to **test**. + - **Audience**: JWT audiences who use the JWT token to access the target service. Set this parameter to **ASM**. + - **JWKS**: JWT information. Set this parameter to {"keys": [*JWK created in* *:ref:`1 `*]}. For example, if the JWK created in :ref:`1 ` is **{"kty":"RSA","e":"AQAB","kid":"a78641b9-d81e-4241-b35a-71726c3****"}**, the value of **JWKS** is **{"keys": [{"kty":"RSA","e":"AQAB","kid":"a78641b9-d81e-4241-b35a-71726c3****"}]}**. + + + .. figure:: /_static/images/en-us_image_0000001528087425.png + :alt: **Figure 3** Creating JWT authentication + + **Figure 3** Creating JWT authentication + + d. Click **OK**. + +Checking Whether JWT Authentication Takes Effect +------------------------------------------------ + +#. .. _asm_01_0097__li174941250183818: + + Use `JWT tool `__ to encode the JWT request information into a JWT token. + + Enter the following JWT request information in the **Decoded** area. The automatically converted JWT token is displayed in the **Encode** area. + + - **HEADER**: Set **alg** to **RS512**, enter **kid** in the JWK created in :ref:`1 `, and set **typ** to **JWT**. + - **PAYLOAD**: Set **iss** to **test** and **aud** to **ASM**. Ensure that the values are the same as the issuer and token audience configured in :ref:`2 `. + - **VERIFY SIGNATURE**: The value must be the same as the public key in :ref:`1.a `. + + + .. figure:: /_static/images/en-us_image_0000001527927469.png + :alt: **Figure 4** Creating a JWT token + + **Figure 4** Creating a JWT token + +#. Access the **httpbin** service through the ingress gateway. + + a. Run the following commands to access the service with the JWT token created in :ref:`1 `: + + **TOKEN**\ =\ *JWT token created by the :ref:`1 `*. + + **curl -I -H "Authorization: Bearer $TOKEN" http://** {*External access address of the* **httpbin** *service*}/ + + Expected outputs: + + .. code-block:: + + HTTP/1.1 200 OK + server: istio-envoy + date: Wed, 21 Sep 2022 03:11:48 GMT + + b. Run the following command to access the service with an invalid JWT token: + + **curl -I -H "Authorization: Bearer invalidToken" http://** {*External access address of the* **httpbin** *service*}/ + + Expected outputs: + + .. code-block:: + + HTTP/1.1 401 Unauthorized + www-authenticate: Bearer realm="http://***.***.***.***:***/", error="invalid_token" + content-length: 145 + content-type: text/plain + date: Wed, 21 Sep 2022 03:12:54 GMT + server: istio-envoy + x-envoy-upstream-service-time: 19 + + c. Modify the JWT authentication created in :ref:`2 `, leave the **aud** empty (indicating that the service can be accessed by any services), and run the following command to access the service with the JWT token created in :ref:`1 `: + + **curl -I -H "Authorization: Bearer $TOKEN" http://** {*External access address of the* **httpbin** *service*}/ + + Expected outputs: + + .. code-block:: + + HTTP/1.1 200 OK + server: istio-envoy + date: Wed, 21 Sep 2022 03:20:07 GMT + + d. Run the following command to access the service without the JWT token: + + **curl -I http://** {*External access address of the* **httpbin** *service*}/ + + Expected outputs: + + .. code-block:: + + HTTP/1.1 403 Forbidden + content-length: 85 + content-type: text/plain + date: Wed, 21 Sep 2022 03:29:31 GMT + 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. diff --git a/umn/source/user_guide/security/configuring_a_security_policy.rst b/umn/source/user_guide/security/configuring_a_security_policy.rst new file mode 100644 index 0000000..4c1b248 --- /dev/null +++ b/umn/source/user_guide/security/configuring_a_security_policy.rst @@ -0,0 +1,59 @@ +:original_name: asm_01_0088.html + +.. _asm_01_0088: + +Configuring a Security Policy +============================= + +ASM security functions include **Access Authorization**, **Peer Authentication**, **JWT Authentication** to ensure the reliable service communication. + +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 **Security** in the **Operation** column. In the window that slides out from the right, configure access authorization and peer authentication. + + **Access Authorization** + + Access authorization controls the access to services in the mesh and determines whether a request can be sent to the current service. + + On the **Access Authorization** tab, click **Configure now**. In the displayed dialog box, click |image1| to select one or more services in a specified namespace. + + **Peer Authentication** + + Istio enables communication between service pods using the Policy Enforcement Point (PEP) tunnel between clients and servers. Peer authentication defines how traffic reaches the current service pod through the tunnel (or not through the tunnel). By default, service pods that have sidecars injected communicate with each other through tunnels. Traffic is automatically encrypted using TLS. + + On the **Peer Authentication** tab, click **Configure now**. In the displayed dialog box, select an authentication policy. + + .. table:: **Table 1** Authentication policies + + +------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +============+==================================================================================================================================================================================================================+ + | UNSET | If a peer authentication policy is configured for the parent scope, the service inherits the policy. | + +------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | PERMISSIVE | Traffic can be transmitted without passing through the tunnel. Workloads accept both mutual TLS and plain text traffic. By default, the mesh is configured with a peer authentication policy in PERMISSIVE mode. | + +------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + | STRICT | Traffic is transmitted only through the tunnel because the request must be encrypted using TLS and must contain the client certificate. | + +------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + + **JWT Authentication** + + You can configure JWT authentication on ASM. With JWT, ASM authenticates whether the access token in a request header is trusted and authorize the valid user requests. + + .. note:: + + JWT authentication can be configured only for HTTP services. + + On the **JWT Authentication** tab, click **Configure now**. In the displayed dialog box, set the following parameters: + + - **Issuer**: issuer of the JWT + - **Audiences**: audiences who use the JWT token to access the service. Separate audiences by commas (,). A null value indicates that the service can be accessed by any audiences. + - **JWKS**: JWT rule set + + For details about the principles and application examples of JWT authentication, see :ref:`JWT Authentication Principles ` and :ref:`Authenticating JWT Requests on the Ingress Gateway Using ASM `. + +.. |image1| image:: /_static/images/en-us_image_0000001374968509.png diff --git a/umn/source/user_guide/security/index.rst b/umn/source/user_guide/security/index.rst new file mode 100644 index 0000000..2040f80 --- /dev/null +++ b/umn/source/user_guide/security/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_01_0087.html + +.. _asm_01_0087: + +Security +======== + +- :ref:`Configuring a Security Policy ` +- :ref:`JWT Authentication Principles ` +- :ref:`Authenticating JWT Requests on the Ingress Gateway Using ASM ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + configuring_a_security_policy + jwt_authentication_principles + authenticating_jwt_requests_on_the_ingress_gateway_using_asm diff --git a/umn/source/user_guide/security/jwt_authentication_principles.rst b/umn/source/user_guide/security/jwt_authentication_principles.rst new file mode 100644 index 0000000..854b7da --- /dev/null +++ b/umn/source/user_guide/security/jwt_authentication_principles.rst @@ -0,0 +1,102 @@ +:original_name: asm_01_0096.html + +.. _asm_01_0096: + +JWT Authentication Principles +============================= + + +JWT Authentication Principles +----------------------------- + +JWT is an authentication mode in which the server issues tokens to the client. When a user logs in to the client using the username and password, the server generates and returns a token to the client. The client only needs to carry the token when sending a request to the server. The server verifies the token to determine whether the request is from a valid client and determines whether to return a response to the client. This method, which connects authenticated clients based on tokens in requests, solves various stateful problems of storing sessions on a server at an early stage. + +In Istio, the JWT token is generated by a specific authentication service and verified by meshes, completely decoupling the authentication logic in user services and enabling applications to focus on their own services. :ref:`Figure 1 ` shows the complete Istio-based JWT mechanism. + +.. _asm_01_0096__fig184171654514: + +.. figure:: /_static/images/en-us_image_0000001477127516.png + :alt: **Figure 1** Istio JWT authentication process + + **Figure 1** Istio JWT authentication process + +1. The client connects the authentication service by logging with the user name and password. + +2. The authentication service verifies the username and password, generates a JWT token (including the user ID and expiration time), and signs the token with the private key of the authentication service. + +3. The authentication service returns the JWT token to the client. + +4. The client stores the JWT token locally for subsequent requests. + +5. When requesting to another service, the client carries the JWT token and does not need to provide information such as the username and password. + +6. The mesh data plane proxy intercepts the traffic and verifies the JWT token using the configured public key. + +7. Once the JWT token is verified, the mesh proxy forwards the request to the server. + +8. The server processes the request. + +9. The server returns the response data to the mesh proxy. + +10. The mesh data plane proxy forwards the response data to the caller. + +The step 6 is important because the JWT authentication function is migrated from the server to the mesh proxy. The mesh data plane obtains, from the authentication policy configured by the control plane, the public key for verifying the JWT token. The public key may be one configured on the JWKS (JSON Web Key Set) or one obtained from a public key address configured by jwksUri. After obtaining the public key, the mesh proxy uses it to verify the token signed by the private key of the authentication service, decrypts the **iss** in the token, and verifies whether the issuer information in the authentication policy is matched. If the verification is successful, the request is sent to the application. If not, the request is rejected. + +JWT Structure +------------- + +JWT is of the JSON structure that contains specific declarations. Step 6 of the JWT authentication process shows the request identity can be confirmed by verifying the JSON structure. Querying the backend service is not needed. The following shows how the authentication information is carried by parsing the JWT structure. + +A JWT token consists of three parts: header, payload, and signature. + +- Header + + Describes the JWT metadata, including the algorithm **alg** and type **typ**. **alg** describes the signature algorithm so that the receiver can verify the signature based on the corresponding algorithm. The default algorithm is **HS256** (as follows), indicating **HMAC-SHA256**. **typ** indicates the token type. If **typ** is **JWT**, indicating that the token is of the JWT type. + + .. code-block:: + + { + "alg": "HS256", + "typ": "JWT" + } + +- Payload + + Stores the main content of the token. The authentication service AuthN generates related information and places the information in the token payload. The attributes of **payload** include: + + - **iss**: token issuer + - **aud**: token audience + + During JWT verification, the **iss** and **aud** will be verified to check whether they are matched with the token issuer and audience. The JWT content is not encrypted. All services that obtain the token can view the content in the token payload. You are advised not to store private information in the payload. + +- Signature + + Signature of the header and payload, ensuring that only the specific legitimate authentication services can issue tokens. Generally, the header and payload are converted into strings using Base64, and then the private key of the authentication service is used to sign the strings. The signature algorithm is the **alg** defined in the header. + +The following is a complete JWT example. Signature is obtained by signing the header and payload. + +.. code-block:: + + # Header: + { + "alg": "RS512", + "typ": "JWT" + } + + # Payload + { + "iss": "weather@cloudnative-istio", + "audience": "weather@cloudnative-istio" + } + + # Signature + RSASHA512( + base64UrlEncode(header) + "." + + base64UrlEncode(payload) + ) + +The token output of the preceding structure is as follows. The three strings separated by periods (.) correspond to the header, payload, and signature of the JWT structure, respectively. + +.. code-block:: + + eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjQ2ODU5ODk3MDAsInZlciI6IjIuMCIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoid2VhdGhlckBjbG91ZG5hdGl2ZS1pc3Rpby5ib29rIiwic3ViIjoid2VhdGhlckBjbG91ZG5hdGl2ZS1pc3Rpby5ib29rIn0.SEp-8qiMwI45BuBgQPH-wTHvOYxcE_jPI0wqOxEpauw diff --git a/umn/source/user_guide/service_management/auto_fixing_items/index.rst b/umn/source/user_guide/service_management/auto_fixing_items/index.rst new file mode 100644 index 0000000..412ffad --- /dev/null +++ b/umn/source/user_guide/service_management/auto_fixing_items/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_01_0065.html + +.. _asm_01_0065: + +Auto Fixing Items +================= + +- :ref:`The Service Port Name Complies with the Istio Specifications ` +- :ref:`The Service Selector Cannot Contain version Labels ` +- :ref:`The Service Is Configured with a Default-version Route and The Route Configuration Is Correct ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + the_service_port_name_complies_with_the_istio_specifications + the_service_selector_cannot_contain_version_labels + the_service_is_configured_with_a_default-version_route_and_the_route_configuration_is_correct diff --git a/umn/source/user_guide/service_management/auto_fixing_items/the_service_is_configured_with_a_default-version_route_and_the_route_configuration_is_correct.rst b/umn/source/user_guide/service_management/auto_fixing_items/the_service_is_configured_with_a_default-version_route_and_the_route_configuration_is_correct.rst new file mode 100644 index 0000000..bae3c2f --- /dev/null +++ b/umn/source/user_guide/service_management/auto_fixing_items/the_service_is_configured_with_a_default-version_route_and_the_route_configuration_is_correct.rst @@ -0,0 +1,44 @@ +:original_name: asm_01_0069.html + +.. _asm_01_0069: + +The Service Is Configured with a Default-version Route and The Route Configuration Is Correct +============================================================================================= + +Description +----------- + +Istio defines service traffic routing rules in **VirtualService** and **DestinationRule**. Therefore, you need to configure **VirtualService** and **DestinationRule** for each service. The following rules must be met: + +- All ports of a Service must be configured in **VirtualService**. +- The protocol type in **VirtualService** must be the same as that of the ports of a Service. +- The default service version must be configured in **VirtualService** and **DestinationRule**. + +.. note:: + + If the check result changes, the port number or port name of a Service may be changed. + +Rectification Guide +------------------- + +#. Log in to the ASM console. Select the mesh where the service is located. In the navigation pane on the left, choose **Mesh Configuration**, click **Istio Resource Management**, and select **Istio resources: virtualservices** and the namespace to which the service belongs. + +#. Ensure that all ports of the Service are configured in **VirtualService**. + + |image1| + +#. Ensure that the protocol type in **VirtualService** is the same as that of the ports of the Service. + + + .. figure:: /_static/images/en-us_image_0000001201436796.png + :alt: **Figure 1** Protocol type in VirtualService + + **Figure 1** Protocol type in VirtualService + + + .. figure:: /_static/images/en-us_image_0000001246196675.png + :alt: **Figure 2** Port protocol type of the Service + + **Figure 2** Port protocol type of the Service + +.. |image1| image:: /_static/images/en-us_image_0000001201276836.png diff --git a/umn/source/user_guide/service_management/auto_fixing_items/the_service_port_name_complies_with_the_istio_specifications.rst b/umn/source/user_guide/service_management/auto_fixing_items/the_service_port_name_complies_with_the_istio_specifications.rst new file mode 100644 index 0000000..431720d --- /dev/null +++ b/umn/source/user_guide/service_management/auto_fixing_items/the_service_port_name_complies_with_the_istio_specifications.rst @@ -0,0 +1,32 @@ +:original_name: asm_01_0066.html + +.. _asm_01_0066: + +The Service Port Name Complies with the Istio Specifications +============================================================ + +Description +----------- + +The Service port name must contain the specified protocol and prefix and must be in the following format: + +.. code-block:: + + name: [-] + +**** can be **http**, **tcp**, or **grpc**. Istio provides routing capabilities based on protocols defined on ports. For example, **name: http-service0** and **name: tcp** are valid port names, while **name: httpforecast** is not. + +If the Service port name is invalid, this item is abnormal. + +Rectification Guide +------------------- + +#. Log in to the CCE 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. + + |image1| + +#. Click **OK**. + +.. |image1| image:: /_static/images/en-us_image_0000001254992703.png diff --git a/umn/source/user_guide/service_management/auto_fixing_items/the_service_selector_cannot_contain_version_labels.rst b/umn/source/user_guide/service_management/auto_fixing_items/the_service_selector_cannot_contain_version_labels.rst new file mode 100644 index 0000000..1fdec0e --- /dev/null +++ b/umn/source/user_guide/service_management/auto_fixing_items/the_service_selector_cannot_contain_version_labels.rst @@ -0,0 +1,22 @@ +:original_name: asm_01_0067.html + +.. _asm_01_0067: + +The Service Selector Cannot Contain version Labels +================================================== + +Description +----------- + +The **spec.selector** of a Service cannot be labeled with **version**. Otherwise, this item is abnormal. + +Rectification Guide +------------------- + +#. Log in to the CCE 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. + + |image1| + +.. |image1| image:: /_static/images/en-us_image_0000001254992865.png diff --git a/umn/source/user_guide/service_management/configuration_diagnosis.rst b/umn/source/user_guide/service_management/configuration_diagnosis.rst new file mode 100644 index 0000000..f6483ae --- /dev/null +++ b/umn/source/user_guide/service_management/configuration_diagnosis.rst @@ -0,0 +1,41 @@ +:original_name: asm_01_0031.html + +.. _asm_01_0031: + +Configuration Diagnosis +======================= + +ASM diagnoses all services in a managed cluster. Traffic management and grayscale release are available only for normal services. + +Constraints +----------- + +- If multiple services correspond to one deployment, these services cannot be added to the mesh. Otherwise, functions such as grayscale release or gateway access may fail. +- If the workload of a service uses the host network mode (**hostNetwork: true** is configured for the pod), sidecars cannot be injected for the service. + +Service Diagnosis +----------------- + +#. 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**. The diagnosis results of services are displayed in the **Configuration Diagnosis Result** column. + + If a service is abnormal, click **Fix** to fix the issues. For details, see :ref:`Service Issue Fixing `. + +#. After the issues are fixed, you can click **Diagnose Again** to diagnose the service again. + +.. _asm_01_0031__section104191546916: + +Service Issue Fixing +-------------------- + +If a service is abnormal, you need to manually fix the abnormal items and then perform auto fix for left issues. + +#. Click **Fix** in the row of the abnormal service. If there are issues to be fixed manually, click **View Solution** to see how to fix them. +#. Click **Next** to go to the auto fix page, and click **Auto Fix** to automatically fix left issues. + + .. note:: + + - If left issues cannot be fix automatically, click **View Solution** and fix them manually. + - Auto fix does not support Services which have configured gateways or have created grayscale release tasks. + - If the service is not displayed in the service list, check whether the corresponding workload exists. diff --git a/umn/source/user_guide/service_management/index.rst b/umn/source/user_guide/service_management/index.rst new file mode 100644 index 0000000..1b6c681 --- /dev/null +++ b/umn/source/user_guide/service_management/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_01_0029.html + +.. _asm_01_0029: + +Service Management +================== + +- :ref:`Configuration Diagnosis ` +- :ref:`Manual Fixing Items ` +- :ref:`Auto Fixing Items ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + configuration_diagnosis + manual_fixing_items/index + auto_fixing_items/index diff --git a/umn/source/user_guide/service_management/manual_fixing_items/all_pods_have_sidecars_injected.rst b/umn/source/user_guide/service_management/manual_fixing_items/all_pods_have_sidecars_injected.rst new file mode 100644 index 0000000..9a7d8f8 --- /dev/null +++ b/umn/source/user_guide/service_management/manual_fixing_items/all_pods_have_sidecars_injected.rst @@ -0,0 +1,59 @@ +:original_name: asm_01_0063.html + +.. _asm_01_0063: + +All Pods Have Sidecars Injected +=============================== + +Description +----------- + +An **istio-proxy** container must exist in all pods of a Service. Otherwise, this item is abnormal. + +Rectification Guide +------------------- + +#. Log in to the ASM console and click the name of the service mesh that the Service is added to. Choose **Mesh Configuration** in the navigation pane, click the **Sidecar Management** tab, and check whether a sidecar is injected into the namespace that the Service belongs to. + + - If no, go to :ref:`2 `. + - If yes, go to :ref:`3 `. + +#. .. _asm_01_0063__li1665121115612: + + Inject a sidecar. + + You can inject sidecars for pods of all workloads in the namespace. For details, see :ref:`Injecting a Sidecar `. You can also inject sidecars for a workload as follows: + + a. Label the namespace where the workload is located with **istio-injection=enabled**. + + **kubectl label ns** **istio-injection=enabled** + + b. Add the **annotations** field for the workload on the CCE console. + + .. code-block:: + + annotations: + sidecar.istio.io/inject: 'true' + + |image1| + + For more details about sidecar injection, see `Installing the Sidecar `__. + +#. .. _asm_01_0063__li127525055610: + + If namespace injection is enabled for the cluster but no sidecar is injected into the pod, you need to manually restart the pod on the CCE console as follows: + + On the CCE console, choose **More** > **Redeploy** in the **Operation** column of the target workload. + +#. Check whether the host network mode is configured for the workload as follows: + + On the CCE console, choose **More** > **Edit YAML** in the **Operation** column of the target workload, and check whether **spec.template.spec.hostNetwork: true** is configured. If yes, check whether this field can be deleted or set to **false**. Otherwise, sidecars cannot be injected. + + |image2| + +#. Check whether the number of pods exceeds the service mesh scale. + + If the number exceeds , the excess pods cannot be injected with sidecars. + +.. |image1| image:: /_static/images/en-us_image_0000001394586873.png +.. |image2| image:: /_static/images/en-us_image_0000001344069664.png diff --git a/umn/source/user_guide/service_management/manual_fixing_items/all_pods_have_the_app_and_version_labels.rst b/umn/source/user_guide/service_management/manual_fixing_items/all_pods_have_the_app_and_version_labels.rst new file mode 100644 index 0000000..e284369 --- /dev/null +++ b/umn/source/user_guide/service_management/manual_fixing_items/all_pods_have_the_app_and_version_labels.rst @@ -0,0 +1,60 @@ +:original_name: asm_01_0061.html + +.. _asm_01_0061: + +All Pods Have the app and version Labels +======================================== + +Description +----------- + +All pods of a Service must be labeled with **app** and **version**. **app** traces traffic in traffic monitoring, and **version** distinguishes different versions in grayscale release. If a pod is not labeled with **app** or **version**, this item is abnormal. + +.. _asm_01_0061__section551915418912: + +Rectification Guide +------------------- + +The labels of pods are configured in **spec.template.metadata.labels** of the Deployment. The recommended configuration is as follows: + +.. code-block:: + + labels: + app: {serviceName} + version: v1 + +.. caution:: + + Modifying or deleting the Deployment will trigger pod rolling upgrade, which may cause temporary service interruption. Therefore, perform the operation at a proper time. + +#. Copy the original workload configuration and save it as a YAML file. + + **kubectl get deployment** {deploymentName} **-n** {namespace} **-o yaml >** {deploymentName}\ **-deployment.yaml** + + For example: + + **kubectl get deployment productpage -n default -o yaml > productpage-deployment.yaml** + +#. Modify the **productpage-deployment.yaml** file. If the file does not contain **app** and **version**, add them. You are advised to set **app** to the Service name and the **version** to **v1**. + +#. Delete the original workload. + + **kubectl delete deployment** {oldDeploymentName} **-n** {namespace} + +#. Apply the new workload configuration. + + **kubectl apply -f productpage-deployment.yaml** + +.. note:: + + For clusters of v1.15 or earlier, you can modify pod labels on the CCE console, but residual ReplicaSets may exist. + + To check whether there are residual ReplicaSets, perform the following steps: + + #. Query the ReplicaSets of the Deployment. + + **kubectl get replicaset \| grep** {deploymentName} + + #. Find the ReplicaSets containing more than one pod. These ReplicaSets may be residual after label modification. You need to delete the old ReplicaSets. + + **kubectl delete replicaset** {replicaSetName} **-n** {namespace} diff --git a/umn/source/user_guide/service_management/manual_fixing_items/all_pods_share_the_same_app_and_version_labels.rst b/umn/source/user_guide/service_management/manual_fixing_items/all_pods_share_the_same_app_and_version_labels.rst new file mode 100644 index 0000000..f4a7821 --- /dev/null +++ b/umn/source/user_guide/service_management/manual_fixing_items/all_pods_share_the_same_app_and_version_labels.rst @@ -0,0 +1,60 @@ +:original_name: asm_01_0062.html + +.. _asm_01_0062: + +All Pods Share the Same app and version Labels +============================================== + +Description +----------- + +All pods of a Service must share the same **app** and **version** labels. **app** traces traffic in traffic monitoring, and **version** distinguishes different versions in grayscale release. If pods with different **app** or **version** labels exist, this item is abnormal. + +Rectification Guide +------------------- + +The labels of pods are configured in **spec.template.metadata.labels** of the Deployment. The recommended configuration is as follows: + +.. code-block:: + + labels: + app: {serviceName} + version: v1 + +To modify the labels of multiple pods to the same value, perform the following steps: + +#. View the labels configured for **spec.selector**. + + **kubectl get svc** {serviceName} **-o yaml** + + For example, the labels are **app: ratings** and **release: istio-bookinfo**. + +#. Search for the pods of a Service by label. + + **kubectl get pod -n** {namespace} **-l app=ratings,release=istio-bookinfo** + + .. note:: + + **{namespace}** is the same as the namespace of the Service. + +#. Find the workload of a pod by the pod name. + + **kubectl get deployment** {deploymentName} **-n** {namespace} + + .. note:: + + - Generally, the pod name is in the format of **{deploymentName}-{random character string}-{random character string}**. + + - If no workload of a pod is found by the pod name, you need to delete residual ReplicaSets. + + To check whether there are residual ReplicaSets, perform the following steps: + + a. Query the ReplicaSets of the Deployment. + + **kubectl get replicaset \| grep** {deploymentName} + + b. Find the ReplicaSets containing more than one pod. These ReplicaSets may be residual after label modification. You need to delete the old ReplicaSets. + + **kubectl delete replicaset** {replicaSetName} **-n** {namespace} + +#. For details about how to modify the **app** and **version** labels of a pod, see :ref:`Rectification Guide `. diff --git a/umn/source/user_guide/service_management/manual_fixing_items/index.rst b/umn/source/user_guide/service_management/manual_fixing_items/index.rst new file mode 100644 index 0000000..ff5d007 --- /dev/null +++ b/umn/source/user_guide/service_management/manual_fixing_items/index.rst @@ -0,0 +1,18 @@ +:original_name: asm_01_0060.html + +.. _asm_01_0060: + +Manual Fixing Items +=================== + +- :ref:`All Pods Have the app and version Labels ` +- :ref:`All Pods Share the Same app and version Labels ` +- :ref:`All Pods Have Sidecars Injected ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + all_pods_have_the_app_and_version_labels + all_pods_share_the_same_app_and_version_labels + all_pods_have_sidecars_injected diff --git a/umn/source/user_guide/traffic_management/changing_a_traffic_policy.rst b/umn/source/user_guide/traffic_management/changing_a_traffic_policy.rst new file mode 100644 index 0000000..dd7fd2f --- /dev/null +++ b/umn/source/user_guide/traffic_management/changing_a_traffic_policy.rst @@ -0,0 +1,17 @@ +:original_name: asm_01_0052.html + +.. _asm_01_0052: + +Changing a Traffic Policy +========================= + +Scenario +-------- + +You can change the settings of a configured traffic policy. For example, you can change the load balancing algorithm from **Round robin** to **Random**. + +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**. Locate the service whose traffic policy needs to be modified and click **Manage Traffic** in the **Operation** column. In the window that slides out from the right, modify traffic policies. diff --git a/umn/source/user_guide/traffic_management/configuring_a_traffic_policy.rst b/umn/source/user_guide/traffic_management/configuring_a_traffic_policy.rst new file mode 100644 index 0000000..ea80405 --- /dev/null +++ b/umn/source/user_guide/traffic_management/configuring_a_traffic_policy.rst @@ -0,0 +1,204 @@ +:original_name: asm_01_0050.html + +.. _asm_01_0050: + +Configuring a Traffic Policy +============================ + +#. 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, configure retry, timeout, connection pool, outlier detection, load balancing, HTTP header, and fault injection policies. + + **Retry** + + Auto retries upon service access failures improve the access quality and success rate. + + On the **Retry** tab, click **Configure now**. In the displayed dialog box, set the parameters listed in the table below. + + .. table:: **Table 1** Retry parameters + + +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 | + +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 | + +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | Retry Condition | Configure retry conditions. For details, see `Retry Policies `__ and `gRPC Retry Policies `__. | ``-`` | + +-------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + + **Timeout** + + Auto processing and quickly failure return upon service access timeout eliminate resource locking and request freezing. + + On the **Timeout** tab, click **Configure now**. In the displayed dialog box, set the parameters listed in the table below. + + .. table:: **Table 2** Timeout parameters + + =========== ================================ ============= + Parameter Description Value Range + =========== ================================ ============= + Timeout (s) Timeout period for HTTP requests 0.001-2592000 + =========== ================================ ============= + + **Connection Pool** + + Connections and requests that exceed the thresholds are cut off to protect target services. Connection pool settings are applied to each pod of the upstream service at the TCP and HTTP levels. For details, see `Circuit Breaker `__. + + On the **Connection Pool** tab, click **Configure now**. In the displayed dialog box, set the parameters listed in the tables below. + + .. table:: **Table 3** Parameters under TCP Settings + + +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 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 | + +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 | + +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | Connection Timeout (s) | TCP connection timeout period. The default value is **10**. | 0.001-2592000 | + +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | Minimum Idle Period (s) | Duration in which a connection remains idle before a keepalive probe is sent. By default, the OS-level configuration is used. (The default value is **7200** for Linux, namely, 2 hours.) | 0.001-2592000 | + +---------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + + .. table:: **Table 4** Parameters under HTTP Settings + + +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 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 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 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 | + +-------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + + **Outlier Detection** + + Unhealthy pods are automatically isolated to improve the overall access success rate. + + The traffic status of service pods is traced to determine whether the pods are healthy. Unhealthy pods will be ejected from the connection pool to improve the overall access success rate. Outlier detection can be configured for HTTP and TCP services. For HTTP services, pods that continuously return 5xx errors are considered unhealthy. For TCP services, pods whose connections time out or fail are considered unhealthy. For details, see `Outlier Detection `__. + + On the **Outlier Detection** tab, click **Configure now**. In the displayed dialog box, set the parameters listed in the table below. + + .. table:: **Table 5** Outlier detection parameters + + +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 | + +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | 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 | + +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | Inspection Interval (s) | If the number of errors reaches the threshold within this time period, the pod will be ejected. The value must be greater than or equal to 0.001s. The default value is **10**. | 0.001-2592000 | + +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + | Maximum Percentage of Ejected Pods (%) | Maximum percentage of ejected service pods. The default value is **10**. | 1-100 | + +----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------+ + + **Load Balancing** + + You can customize a load balancing policy to target backend service pods. + + On the **Load Balancing** tab, click **Configure now**. In the displayed dialog box, select one of the following load balancing algorithms as required: + + - **Round robin**: The default load balancing algorithm. Each service pod in the pool gets a request in turn. + + - **Least connection**: Requests are forwarded to the pod with fewer connections among two randomly selected healthy pods. + + - **Random**: Requests are forwarded to a randomly selected healthy pod. + + - **Consistent hashing**: There are four types, as described in :ref:`Table 6 `. + + .. _asm_01_0050__table1878918125557: + + .. table:: **Table 6** Consistent hashing algorithm types + + +--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Type | Description | + +==========================+=======================================================================================================================================================+ + | Based on HTTP header | The hash value is calculated using the header of the HTTP request. Requests with the same hash value are forwarded to the same pod. | + +--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Based on cookie | The hash value is calculated using the cookie key name of the HTTP request. Requests with the same hash value are forwarded to the same pod. | + +--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Based on source IP | The hash value is calculated using the IP address of the HTTP request. Requests with the same hash value are forwarded to the same pod. | + +--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + | Based on query parameter | The hash value is calculated using the query parameter key name of the HTTP request. Requests with the same hash value are forwarded to the same pod. | + +--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------+ + + **HTTP Header** + + You can flexibly add, modify, and delete specified HTTP headers to manage request contents in non-intrusive mode. + + On the **HTTP Header** tab, click **Configure now**. In the displayed dialog box, set the parameters listed in the tables below. + + .. table:: **Table 7** Operations on the HTTP headers before the request is forwarded to the destination service + + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +=========================+======================================================================================================================================+ + | Add request headers. | To add a request header, you need to set **key** and **value**. You can also click |image4| to add more request headers. | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ + | Edit request headers. | To edit an existing request header, you need to set **key** and **value**. You can also click |image5| to edit more request headers. | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ + | Remove request headers. | To remove an existing request header, you need to set **key**. You can also click |image6| to remove more request headers. | + +-------------------------+--------------------------------------------------------------------------------------------------------------------------------------+ + + .. table:: **Table 8** Operations on the HTTP headers before the response is returned to the client + + +--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Parameter | Description | + +==========================+=========================================================================================================================================+ + | Add response headers. | To add a response header, you need to set **key** and **value**. You can also click |image10| to add more response headers. | + +--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Edit response headers. | To edit an existing response header, you need to set **key** and **value**. You can also click |image11| to edit more response headers. | + +--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + | Remove response headers. | To remove an existing response header, you need to set **key**. You can also click |image12| to remove more response headers. | + +--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ + + **Fault Injection** + + You can inject faults into the system to check whether it can tolerate and recover from faults. + + On the **Fault Injection** tab, click **Configure now**. In the displayed dialog box, set the parameters listed in the table below. + + .. table:: **Table 9** Fault injection parameters + + +-----------------------+-------------------------------------------------------------------------------------+-------------------------+ + | Parameter | Description | Value Range | + +=======================+=====================================================================================+=========================+ + | Fault Type | The options are **Delay** and **Abort**. | **Delay** and **Abort** | + | | | | + | | - **Delay**: Service requests are delayed. | | + | | - **Abort**: A service is aborted and the preset status code is returned. | | + +-----------------------+-------------------------------------------------------------------------------------+-------------------------+ + | Delay (s) | This parameter needs to be set when **Fault Type** is set to **Delay**. | 0.001-2592000 | + | | | | + | | A request will be delayed for this period of time before it is forwarded. | | + +-----------------------+-------------------------------------------------------------------------------------+-------------------------+ + | HTTP Status Code | This parameter needs to be set when **Fault Type** is set to **Abort**. | 200-599 | + | | | | + | | HTTP status code returned when an abort fault occurs. The default value is **500**. | | + +-----------------------+-------------------------------------------------------------------------------------+-------------------------+ + | Fault Percentage (%) | Percentage of requests for which the delay or abort fault is injected. | 1-100 | + +-----------------------+-------------------------------------------------------------------------------------+-------------------------+ + +.. |image1| image:: /_static/images/en-us_image_0000001234454572.png +.. |image2| image:: /_static/images/en-us_image_0000001234773776.png +.. |image3| image:: /_static/images/en-us_image_0000001278854949.png +.. |image4| image:: /_static/images/en-us_image_0000001234454572.png +.. |image5| image:: /_static/images/en-us_image_0000001234773776.png +.. |image6| image:: /_static/images/en-us_image_0000001278854949.png +.. |image7| image:: /_static/images/en-us_image_0000001279134173.png +.. |image8| image:: /_static/images/en-us_image_0000001234614480.png +.. |image9| image:: /_static/images/en-us_image_0000001234294620.png +.. |image10| image:: /_static/images/en-us_image_0000001279134173.png +.. |image11| image:: /_static/images/en-us_image_0000001234614480.png +.. |image12| image:: /_static/images/en-us_image_0000001234294620.png diff --git a/umn/source/user_guide/traffic_management/index.rst b/umn/source/user_guide/traffic_management/index.rst new file mode 100644 index 0000000..bc0167b --- /dev/null +++ b/umn/source/user_guide/traffic_management/index.rst @@ -0,0 +1,20 @@ +:original_name: asm_01_0085.html + +.. _asm_01_0085: + +Traffic Management +================== + +- :ref:`Overview ` +- :ref:`Configuring a Traffic Policy ` +- :ref:`Viewing Traffic Monitoring ` +- :ref:`Changing a Traffic Policy ` + +.. toctree:: + :maxdepth: 1 + :hidden: + + overview + configuring_a_traffic_policy + viewing_traffic_monitoring + changing_a_traffic_policy diff --git a/umn/source/user_guide/traffic_management/overview.rst b/umn/source/user_guide/traffic_management/overview.rst new file mode 100644 index 0000000..5ee8ce9 --- /dev/null +++ b/umn/source/user_guide/traffic_management/overview.rst @@ -0,0 +1,41 @@ +:original_name: asm_01_0049.html + +.. _asm_01_0049: + +Overview +======== + +Non-intrusive traffic management is a core function of Istio. With traffic management, you only need to focus on your own service logic rather than service access management. Traffic management enables you to: + +- Dynamically modify load balancing policies for cross-service access, such as configuring consistent hashing to forward traffic to specific service pods. +- Distribute a certain proportion of traffic to a specific version of a service when the service has two online versions. +- Protect services, for example, limiting the number of concurrent connections and requests, and isolating faulty service pods. +- Dynamically modify the content of a service or simulate a service running fault. + +ASM provides retry, timeout, connection pool, outlier detection, load balancing, HTTP header, and fault injection functions to meet traffic management requirements in most service scenarios. + +.. table:: **Table 1** Common mesh functions and management roles + + ====================== ================= ================ + Mesh Function Management Role + \ Service Initiator Service Provider + Route management Y N + Load balancing Y N + Tracing analysis Y Y + Service authentication Y Y + Observability data Y Y + Retry Y N + Rewrite Y N + Redirection Y N + Authorization N Y + Fault injection Y N + Timeout Y N + Connection pool Y N + Outlier detection Y N + HTTP header Y N + ====================== ================= ================ + +Constraints +----------- + +Traffic management cannot be performed for the service whose configuration diagnosis fails. For details about rectifying faults, see :ref:`Manual Fixing Items ` or :ref:`Auto Fixing Items `. diff --git a/umn/source/user_guide/traffic_management/viewing_traffic_monitoring.rst b/umn/source/user_guide/traffic_management/viewing_traffic_monitoring.rst new file mode 100644 index 0000000..250e05e --- /dev/null +++ b/umn/source/user_guide/traffic_management/viewing_traffic_monitoring.rst @@ -0,0 +1,28 @@ +: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.