diff --git a/docs/cce/umn/ALL_META.TXT.json b/docs/cce/umn/ALL_META.TXT.json index bebc082e..250c6c81 100644 --- a/docs/cce/umn/ALL_META.TXT.json +++ b/docs/cce/umn/ALL_META.TXT.json @@ -1,48 +1,168 @@ [ + { + "uri":"en-us_topic_0000001550437509.html", + "product_code":"cce", + "code":"1", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Service Overview", + "title":"Service Overview", + "githuburl":"" + }, { "uri":"cce_01_0091.html", "product_code":"cce", - "code":"1", - "des":"Cloud Container Engine (CCE) provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily dep", + "code":"2", + "des":"Cloud Container Engine (CCE) is a scalable, enterprise-class hosted Kubernetes service. With CCE, you can easily deploy, manage, and scale containerized applications in t", "doc_type":"usermanual2", - "kw":"What Is Cloud Container Engine?,User Guide", + "kw":"What Is Cloud Container Engine?,Service Overview,User Guide", "title":"What Is Cloud Container Engine?", "githuburl":"" }, { - "uri":"cce_qs_0001.html", + "uri":"cce_productdesc_0003.html", "product_code":"cce", - "code":"2", - "des":"This document provides instructions for getting started with the Cloud Container Engine (CCE).Complete the following tasks to get started with CCE.The accounts have the p", + "code":"3", + "des":"CCE is a container service built on Docker and Kubernetes. A wealth of features enable you to run container clusters at scale. CCE eases containerization thanks to its re", "doc_type":"usermanual2", - "kw":"Instruction,User Guide", - "title":"Instruction", + "kw":"Product Advantages,Service Overview,User Guide", + "title":"Product Advantages", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0007.html", + "product_code":"cce", + "code":"4", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Application Scenarios", + "title":"Application Scenarios", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0020.html", + "product_code":"cce", + "code":"5", + "des":"In CCE, you can run clusters with x86 and Arm nodes. Create and manage Kubernetes clusters. Deploy containerized applications in them. All done in CCE.Containerization re", + "doc_type":"usermanual2", + "kw":"Infrastructure and Containerized Application Management,Application Scenarios,User Guide", + "title":"Infrastructure and Containerized Application Management", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0015.html", + "product_code":"cce", + "code":"6", + "des":"Shopping apps and websites, especially during promotions and flash salesLive streaming, where service loads often fluctuateGames, where many players may go online in cert", + "doc_type":"usermanual2", + "kw":"Auto Scaling in Seconds,Application Scenarios,User Guide", + "title":"Auto Scaling in Seconds", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0017.html", + "product_code":"cce", + "code":"7", + "des":"You may receive a lot feedback and requirements for your apps or services. You may want to boost user experience with new features. Continuous integration (CI) and delive", + "doc_type":"usermanual2", + "kw":"DevOps and CI/CD,Application Scenarios,User Guide", + "title":"DevOps and CI/CD", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0018.html", + "product_code":"cce", + "code":"8", + "des":"Multi-cloud deployment and disaster recoveryRunning apps in containers on different clouds can ensure high availability. When a cloud is down, other clouds respond and se", + "doc_type":"usermanual2", + "kw":"Hybrid Cloud Architecture,Application Scenarios,User Guide", + "title":"Hybrid Cloud Architecture", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0005.html", + "product_code":"cce", + "code":"9", + "des":"This section describes the notes and constraints on using CCE.After a cluster is created, the following items cannot be changed:Number of master nodes. For example, you c", + "doc_type":"usermanual2", + "kw":"Volumes,namespace,Notes and Constraints,Service Overview,User Guide", + "title":"Notes and Constraints", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0002.html", + "product_code":"cce", + "code":"10", + "des":"CCE allows you to assign permissions to IAM users and user groups under your tenant accounts. CCE combines the advantages of Identity and Access Management (IAM) and Kube", + "doc_type":"usermanual2", + "kw":"Permissions,Service Overview,User Guide", + "title":"Permissions", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0004.html", + "product_code":"cce", + "code":"11", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Basic Concepts", + "title":"Basic Concepts", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0011.html", + "product_code":"cce", + "code":"12", + "des":"CCE provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale co", + "doc_type":"usermanual2", + "kw":"Cluster,Node,Pod,Workload,image,image repository,job,Basic Concepts,Basic Concepts,User Guide", + "title":"Basic Concepts", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0010.html", + "product_code":"cce", + "code":"13", + "des":"Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of container clusters. It is a container orchestration tool and a leading sol", + "doc_type":"usermanual2", + "kw":"Mappings Between CCE and Kubernetes Terms,Basic Concepts,User Guide", + "title":"Mappings Between CCE and Kubernetes Terms", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0012.html", + "product_code":"cce", + "code":"14", + "des":"A region and availability zone (AZ) identify the location of a data center. You can create resources in a specific region and AZ.Regions are divided based on geographical", + "doc_type":"usermanual2", + "kw":"Regions and AZs,Basic Concepts,User Guide", + "title":"Regions and AZs", + "githuburl":"" + }, + { + "uri":"cce_productdesc_0008.html", + "product_code":"cce", + "code":"15", + "des":"CCE works with the following cloud services and requires permissions to access them.", + "doc_type":"usermanual2", + "kw":"Elastic Cloud Server (ECS),Virtual Private Cloud (VPC),Elastic Load Balance (ELB),cloud storage for ", + "title":"Related Services", "githuburl":"" }, { "uri":"cce_bulletin_0000.html", "product_code":"cce", - "code":"3", + "code":"16", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Product Bulletin", "title":"Product Bulletin", "githuburl":"" }, - { - "uri":"cce_bulletin_0054.html", - "product_code":"cce", - "code":"4", - "des":"When performing operations such as creating, deleting, and scaling clusters, do not change user permission in the Identity and Access Management (IAM) console. Otherwise,", - "doc_type":"usermanual2", - "kw":"the node will become unready,Risky Operations on Cluster Nodes,Product Bulletin,User Guide", - "title":"Risky Operations on Cluster Nodes", - "githuburl":"" - }, { "uri":"cce_bulletin_0003.html", "product_code":"cce", - "code":"5", + "code":"17", "des":"This section explains versioning in CCE, and the policies for Kubernetes version support.Version number: The format is x.y.z, where x.y is the major version and z is the ", "doc_type":"usermanual2", "kw":"Kubernetes Version Support Mechanism,Product Bulletin,User Guide", @@ -52,7 +172,7 @@ { "uri":"cce_bulletin_0068.html", "product_code":"cce", - "code":"6", + "code":"18", "des":"To ensure that stable and reliable Kubernetes versions are available during your use of CCE, CCE provides the Kubernetes version support mechanism. A new supported versio", "doc_type":"usermanual2", "kw":"CCE Cluster Version Release Notes,Product Bulletin,User Guide", @@ -62,8 +182,8 @@ { "uri":"cce_bulletin_0301.html", "product_code":"cce", - "code":"7", - "des":"CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9 and CentOS 7.7. The following table lists the supported patches for these OSs.The OS patches and verifica", + "code":"19", + "des":"CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9, CentOS 7.7 and Ubuntu 22.04. The following table lists the supported patches for these OSs.The OS patche", "doc_type":"usermanual2", "kw":"OS Patch Notes for Cluster Nodes,Product Bulletin,User Guide", "title":"OS Patch Notes for Cluster Nodes", @@ -72,7 +192,7 @@ { "uri":"cce_bulletin_0169.html", "product_code":"cce", - "code":"8", + "code":"20", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Security Vulnerability Responses", @@ -82,7 +202,7 @@ { "uri":"cce_bulletin_0011.html", "product_code":"cce", - "code":"9", + "code":"21", "des":"High-risk vulnerabilities:CCE fixes vulnerabilities as soon as possible after the Kubernetes community detects them and releases fixing solutions. The fixing policies are", "doc_type":"usermanual2", "kw":"Vulnerability Fixing Policies,Security Vulnerability Responses,User Guide", @@ -92,7 +212,7 @@ { "uri":"CVE-2021-4034.html", "product_code":"cce", - "code":"10", + "code":"22", "des":"Recently, a security research team disclosed a privilege escalation vulnerability (CVE-2021-4034, also dubbed PwnKit) in PolKit's pkexec. Unprivileged users can gain full", "doc_type":"usermanual2", "kw":"Linux Polkit Privilege Escalation Vulnerability (CVE-2021-4034),Security Vulnerability Responses,Use", @@ -102,7 +222,7 @@ { "uri":"cce_bulletin_0206.html", "product_code":"cce", - "code":"11", + "code":"23", "des":"The Linux Kernel SACK vulnerabilities have been fixed. This section describes the solution to these vulnerabilities.On June 18, 2019, Red Hat released a security notice, ", "doc_type":"usermanual2", "kw":"Notice on Fixing Linux Kernel SACK Vulnerabilities,Security Vulnerability Responses,User Guide", @@ -110,29 +230,109 @@ "githuburl":"" }, { - "uri":"cce_10_0477.html", + "uri":"cce_qs_0000.html", "product_code":"cce", - "code":"12", - "des":"In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no lo", + "code":"24", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", - "kw":"Service Account Token Security Improvement,Product Bulletin,User Guide", - "title":"Service Account Token Security Improvement", + "kw":"Getting Started", + "title":"Getting Started", "githuburl":"" }, { - "uri":"cce_01_9994.html", + "uri":"cce_qs_0001.html", "product_code":"cce", - "code":"13", - "des":"CCE works closely with multiple cloud services to support computing, storage, networking, and monitoring functions. When you log in to the CCE console for the first time,", + "code":"25", + "des":"This section describes how to use Cloud Container Engine (CCE) and provides frequently asked questions (FAQs) to help you quickly get started with CCE.Complete the follow", "doc_type":"usermanual2", - "kw":"Obtaining Resource Permissions,User Guide", - "title":"Obtaining Resource Permissions", + "kw":"Introduction,Getting Started,User Guide", + "title":"Introduction", + "githuburl":"" + }, + { + "uri":"cce_qs_0006.html", + "product_code":"cce", + "code":"26", + "des":"Before using CCE, you need to make the following preparations:Creating an IAM userObtaining Resource Permissions(Optional) Creating a VPC(Optional) Creating a Key PairIf ", + "doc_type":"usermanual2", + "kw":"VPC,Preparations,Getting Started,User Guide", + "title":"Preparations", + "githuburl":"" + }, + { + "uri":"cce_qs_0008.html", + "product_code":"cce", + "code":"27", + "des":"This section describes how to quickly create a CCE cluster. In this example, the default or simple configurations are in use.If you have not created a cluster, a wizard p", + "doc_type":"usermanual2", + "kw":"Creating a Kubernetes Cluster,Getting Started,User Guide", + "title":"Creating a Kubernetes Cluster", + "githuburl":"" + }, + { + "uri":"cce_qs_0003.html", + "product_code":"cce", + "code":"28", + "des":"You can use images to quickly create a single-pod workload that can be accessed from public networks. This section describes how to use CCE to quickly deploy an Nginx app", + "doc_type":"usermanual2", + "kw":"Creating a Deployment (Nginx) from an Image,Getting Started,User Guide", + "title":"Creating a Deployment (Nginx) from an Image", + "githuburl":"" + }, + { + "uri":"cce_qs_0007.html", + "product_code":"cce", + "code":"29", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Deploying WordPress and MySQL That Depend on Each Other", + "title":"Deploying WordPress and MySQL That Depend on Each Other", + "githuburl":"" + }, + { + "uri":"cce_qs_0009.html", + "product_code":"cce", + "code":"30", + "des":"WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any ser", + "doc_type":"usermanual2", + "kw":"Overview,Deploying WordPress and MySQL That Depend on Each Other,User Guide", + "title":"Overview", + "githuburl":"" + }, + { + "uri":"cce_qs_0004.html", + "product_code":"cce", + "code":"31", + "des":"WordPress must be used together with MySQL. WordPress runs the content management program while MySQL serves as a database to store data.The WordPress and MySQL images ha", + "doc_type":"usermanual2", + "kw":"Step 1: Create a MySQL Workload,Deploying WordPress and MySQL That Depend on Each Other,User Guide", + "title":"Step 1: Create a MySQL Workload", + "githuburl":"" + }, + { + "uri":"cce_qs_0005.html", + "product_code":"cce", + "code":"32", + "des":"WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any ser", + "doc_type":"usermanual2", + "kw":"Step 2: Create a WordPress Workload,Deploying WordPress and MySQL That Depend on Each Other,User Gui", + "title":"Step 2: Create a WordPress Workload", + "githuburl":"" + }, + { + "uri":"cce_10_0054.html", + "product_code":"cce", + "code":"33", + "des":"During service deployment or running, you may trigger high-risk operations at different levels, causing service faults or interruption. To help you better estimate and av", + "doc_type":"usermanual2", + "kw":"High-Risk Operations and Solutions,User Guide", + "title":"High-Risk Operations and Solutions", "githuburl":"" }, { "uri":"cce_10_0091.html", "product_code":"cce", - "code":"14", + "code":"34", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Clusters", @@ -142,7 +342,7 @@ { "uri":"cce_10_0002.html", "product_code":"cce", - "code":"15", + "code":"35", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Cluster Overview", @@ -152,8 +352,8 @@ { "uri":"cce_10_0430.html", "product_code":"cce", - "code":"16", - "des":"Kubernetes allows you to easily deploy and manage containerized application and facilitates container scheduling and orchestration.For developers, Kubernetes is a cluster", + "code":"36", + "des":"Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications.For developers, Kubernetes is", "doc_type":"usermanual2", "kw":"Basic Cluster Information,Cluster Overview,User Guide", "title":"Basic Cluster Information", @@ -162,7 +362,7 @@ { "uri":"cce_10_0342.html", "product_code":"cce", - "code":"17", + "code":"37", "des":"The following table lists the differences between CCE Turbo clusters and CCE clusters:The QingTian architecture consists of data plane (software-hardware synergy) and man", "doc_type":"usermanual2", "kw":"CCE Turbo Clusters and CCE Clusters,Cluster Overview,User Guide", @@ -172,7 +372,7 @@ { "uri":"cce_10_0349.html", "product_code":"cce", - "code":"18", + "code":"38", "des":"kube-proxy is a key component of a Kubernetes cluster. It is responsible for load balancing and forwarding between a Service and its backend pod.CCE supports two forwardi", "doc_type":"usermanual2", "kw":"Comparing iptables and IPVS,Cluster Overview,User Guide", @@ -182,7 +382,7 @@ { "uri":"cce_10_0068.html", "product_code":"cce", - "code":"19", + "code":"39", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Release Notes", @@ -192,7 +392,7 @@ { "uri":"cce_10_0467.html", "product_code":"cce", - "code":"20", + "code":"40", "des":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.25.Kubernetes 1", "doc_type":"usermanual2", "kw":"CCE Kubernetes 1.25 Release Notes,Release Notes,User Guide", @@ -202,7 +402,7 @@ { "uri":"cce_10_0468.html", "product_code":"cce", - "code":"21", + "code":"41", "des":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.23.Changes in C", "doc_type":"usermanual2", "kw":"CCE Kubernetes 1.23 Release Notes,Release Notes,User Guide", @@ -212,7 +412,7 @@ { "uri":"cce_10_0469.html", "product_code":"cce", - "code":"22", + "code":"42", "des":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.21.Kubernetes 1", "doc_type":"usermanual2", "kw":"CCE Kubernetes 1.21 Release Notes,Release Notes,User Guide", @@ -222,7 +422,7 @@ { "uri":"cce_10_0470.html", "product_code":"cce", - "code":"23", + "code":"43", "des":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.19.Kubernetes 1", "doc_type":"usermanual2", "kw":"CCE Kubernetes 1.19 Release Notes,Release Notes,User Guide", @@ -232,7 +432,7 @@ { "uri":"cce_10_0471.html", "product_code":"cce", - "code":"24", + "code":"44", "des":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.17.All resource", "doc_type":"usermanual2", "kw":"CCE Kubernetes 1.17 Release Notes,Release Notes,User Guide", @@ -242,7 +442,7 @@ { "uri":"cce_10_0298.html", "product_code":"cce", - "code":"25", + "code":"45", "des":"CCE Turbo clusters run on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, and inte", "doc_type":"usermanual2", "kw":"Creating a CCE Turbo Cluster,Clusters,User Guide", @@ -252,7 +452,7 @@ { "uri":"cce_10_0028.html", "product_code":"cce", - "code":"26", + "code":"46", "des":"On the CCE console, you can easily create Kubernetes clusters. Kubernetes can manage container clusters at scale. A cluster manages a group of node resources.In CCE, you ", "doc_type":"usermanual2", "kw":"Creating a CCE Cluster,Clusters,User Guide", @@ -262,7 +462,7 @@ { "uri":"cce_10_0140.html", "product_code":"cce", - "code":"27", + "code":"47", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Using kubectl to Run a Cluster", @@ -272,7 +472,7 @@ { "uri":"cce_10_0107.html", "product_code":"cce", - "code":"28", + "code":"48", "des":"This section uses a CCE cluster as an example to describe how to connect to a CCE cluster using kubectl.When you access a cluster using kubectl, CCE uses thekubeconfig.js", "doc_type":"usermanual2", "kw":"Connecting to a Cluster Using kubectl,Using kubectl to Run a Cluster,User Guide", @@ -282,7 +482,7 @@ { "uri":"cce_10_0367.html", "product_code":"cce", - "code":"29", + "code":"49", "des":"A Subject Alternative Name (SAN) can be signed in to a cluster server certificate. A SAN is usually used by the client to verify the server validity in TLS handshakes. Sp", "doc_type":"usermanual2", "kw":"Customizing a Cluster Certificate SAN,Using kubectl to Run a Cluster,User Guide", @@ -292,7 +492,7 @@ { "uri":"cce_10_0139.html", "product_code":"cce", - "code":"30", + "code":"50", "des":"getThe get command displays one or many resources of a cluster.This command prints a table of the most important information about all resources, including cluster nodes,", "doc_type":"usermanual2", "kw":"Common kubectl Commands,Using kubectl to Run a Cluster,User Guide", @@ -302,7 +502,7 @@ { "uri":"cce_10_0215.html", "product_code":"cce", - "code":"31", + "code":"51", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Upgrading a Cluster", @@ -312,7 +512,7 @@ { "uri":"cce_10_0197.html", "product_code":"cce", - "code":"32", + "code":"52", "des":"To enable interoperability from one Kubernetes installation to the next, you must upgrade your Kubernetes clusters before the maintenance period ends.After the latest Kub", "doc_type":"usermanual2", "kw":"Upgrade Overview,Upgrading a Cluster,User Guide", @@ -322,17 +522,97 @@ { "uri":"cce_10_0302.html", "product_code":"cce", - "code":"33", + "code":"53", "des":"Before the upgrade, you can check whether your cluster can be upgraded and which versions are available on the CCE console. For details, see Upgrade Overview.Upgraded clu", "doc_type":"usermanual2", "kw":"Before You Start,Upgrading a Cluster,User Guide", "title":"Before You Start", "githuburl":"" }, + { + "uri":"cce_10_0560.html", + "product_code":"cce", + "code":"54", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Post-Upgrade Verification", + "title":"Post-Upgrade Verification", + "githuburl":"" + }, + { + "uri":"cce_10_0561.html", + "product_code":"cce", + "code":"55", + "des":"After the cluster is upgraded, check whether the services are running normal.Different services have different verification mode. Select a suitable one and verify the ser", + "doc_type":"usermanual2", + "kw":"Service Verification,Post-Upgrade Verification,User Guide", + "title":"Service Verification", + "githuburl":"" + }, + { + "uri":"cce_10_0562.html", + "product_code":"cce", + "code":"56", + "des":"Check whether unexpected pods exist in the cluster.Check whether there are pods restart unexpectedly in the cluster.Go to the CCE console and access the cluster console. ", + "doc_type":"usermanual2", + "kw":"Pod Check,Post-Upgrade Verification,User Guide", + "title":"Pod Check", + "githuburl":"" + }, + { + "uri":"cce_10_0563.html", + "product_code":"cce", + "code":"57", + "des":"Check whether the nodes are running properly.Check whether the node network is normal.Check whether the container network is normal.The node status reflects whether the n", + "doc_type":"usermanual2", + "kw":"Node and Container Network Check,Post-Upgrade Verification,User Guide", + "title":"Node and Container Network Check", + "githuburl":"" + }, + { + "uri":"cce_10_0564.html", + "product_code":"cce", + "code":"58", + "des":"Check whether the label is lost.Check whether there are unexpected taints.Go to the CCE console, access the cluster console, and choose Nodes in the navigation pane. On t", + "doc_type":"usermanual2", + "kw":"Node Label and Taint Check,Post-Upgrade Verification,User Guide", + "title":"Node Label and Taint Check", + "githuburl":"" + }, + { + "uri":"cce_10_0565.html", + "product_code":"cce", + "code":"59", + "des":"Check whether nodes can be created in the cluster.Go to the CCE console and access the cluster console. Choose Nodes in the navigation pane, and click Create Node.If node", + "doc_type":"usermanual2", + "kw":"New Node Check,Post-Upgrade Verification,User Guide", + "title":"New Node Check", + "githuburl":"" + }, + { + "uri":"cce_10_0566.html", + "product_code":"cce", + "code":"60", + "des":"Check whether pods can be created on the existing nodes after the cluster is upgraded.Check whether pods can be created on new nodes after the cluster is upgraded.After c", + "doc_type":"usermanual2", + "kw":"New Pod Check,Post-Upgrade Verification,User Guide", + "title":"New Pod Check", + "githuburl":"" + }, + { + "uri":"cce_10_0567.html", + "product_code":"cce", + "code":"61", + "des":"After the cluster is upgraded, you need to reset the nodes that fail to be upgraded.Go back to the previous step or view the upgrade details on the upgrade history page t", + "doc_type":"usermanual2", + "kw":"Node Skipping Check for Reset,Post-Upgrade Verification,User Guide", + "title":"Node Skipping Check for Reset", + "githuburl":"" + }, { "uri":"cce_10_0120.html", "product_code":"cce", - "code":"34", + "code":"62", "des":"You can upgrade your clusters to a newer Kubernetes version on the CCE console.Before the upgrade, learn about the target version to which each CCE cluster can be upgrade", "doc_type":"usermanual2", "kw":"Performing Replace/Rolling Upgrade,Upgrading a Cluster,User Guide", @@ -342,7 +622,7 @@ { "uri":"cce_10_0301.html", "product_code":"cce", - "code":"35", + "code":"63", "des":"You can upgrade your clusters to a newer version on the CCE console.Before the upgrade, learn about the target version to which each CCE cluster can be upgraded in what w", "doc_type":"usermanual2", "kw":"Performing In-place Upgrade,Upgrading a Cluster,User Guide", @@ -352,17 +632,447 @@ { "uri":"cce_10_0210.html", "product_code":"cce", - "code":"36", + "code":"64", "des":"This section describes how to migrate services from a cluster of an earlier version to a cluster of a later version in CCE.This operation is applicable when a cross-versi", "doc_type":"usermanual2", "kw":"Migrating Services Across Clusters of Different Versions,Upgrading a Cluster,User Guide", "title":"Migrating Services Across Clusters of Different Versions", "githuburl":"" }, + { + "uri":"cce_10_0550.html", + "product_code":"cce", + "code":"65", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Troubleshooting for Pre-upgrade Check Exceptions", + "title":"Troubleshooting for Pre-upgrade Check Exceptions", + "githuburl":"" + }, + { + "uri":"cce_10_0549.html", + "product_code":"cce", + "code":"66", + "des":"The system performs a comprehensive pre-upgrade check before the cluster upgrade. If the cluster does not meet the pre-upgrade check conditions, the upgrade cannot contin", + "doc_type":"usermanual2", + "kw":"Performing Pre-upgrade Check,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Performing Pre-upgrade Check", + "githuburl":"" + }, + { + "uri":"cce_10_0431.html", + "product_code":"cce", + "code":"67", + "des":"Check the following aspects:Check whether the node is available.Check whether the node OS supports the upgrade.Check whether there are unexpected node pool tags in the no", + "doc_type":"usermanual2", + "kw":"Checking the Node,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking the Node", + "githuburl":"" + }, + { + "uri":"cce_10_0432.html", + "product_code":"cce", + "code":"68", + "des":"Check whether the current user is in the upgrade blocklist.CCE temporarily disables the cluster upgrade function due to the following reasons:The cluster is identified as", + "doc_type":"usermanual2", + "kw":"Checking the Blocklist,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking the Blocklist", + "githuburl":"" + }, + { + "uri":"cce_10_0433.html", + "product_code":"cce", + "code":"69", + "des":"Check the following aspects:Check whether the add-on status is normal.Check whether the add-on supports the target version.Scenario 1: The add-on status is abnormal.Log i", + "doc_type":"usermanual2", + "kw":"Checking the Add-on,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking the Add-on", + "githuburl":"" + }, + { + "uri":"cce_10_0434.html", + "product_code":"cce", + "code":"70", + "des":"Check whether the current HelmRelease record contains discarded Kubernetes APIs that are not supported by the target cluster version. If yes, the Helm chart may be unavai", + "doc_type":"usermanual2", + "kw":"Checking the Helm Chart,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking the Helm Chart", + "githuburl":"" + }, + { + "uri":"cce_10_0435.html", + "product_code":"cce", + "code":"71", + "des":"Check whether CCE can connect to your master nodes.Contact technical support.", + "doc_type":"usermanual2", + "kw":"Checking the Master Node SSH Connectivity,Troubleshooting for Pre-upgrade Check Exceptions,User Guid", + "title":"Checking the Master Node SSH Connectivity", + "githuburl":"" + }, + { + "uri":"cce_10_0436.html", + "product_code":"cce", + "code":"72", + "des":"Check the following aspects:Check the node status.Check whether the auto scaling function of the node pool is disabled.Scenario 1: The node pool status is abnormal.Log in", + "doc_type":"usermanual2", + "kw":"Checking the Node Pool,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking the Node Pool", + "githuburl":"" + }, + { + "uri":"cce_10_0437.html", + "product_code":"cce", + "code":"73", + "des":"Check whether the security group allows the master node to access nodes using ICMP.Log in to the VPC console, choose Access Control > Security Groups, and enter the targe", + "doc_type":"usermanual2", + "kw":"Checking the Security Group,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking the Security Group", + "githuburl":"" + }, + { + "uri":"cce_10_0439.html", + "product_code":"cce", + "code":"74", + "des":"Check whether the node needs to be migrated.For the 1.15 cluster that is upgraded from 1.13 in rolling mode, you need to migrate (reset or create and replace) all nodes b", + "doc_type":"usermanual2", + "kw":"To-Be-Migrated Node,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"To-Be-Migrated Node", + "githuburl":"" + }, + { + "uri":"cce_10_0440.html", + "product_code":"cce", + "code":"75", + "des":"Check whether there are discarded resources in the clusters.Scenario 1: The PodSecurityPolicy resource object has been discarded since clusters of v1.25.Run the kubectl g", + "doc_type":"usermanual2", + "kw":"Discarded Kubernetes Resource,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Discarded Kubernetes Resource", + "githuburl":"" + }, + { + "uri":"cce_10_0441.html", + "product_code":"cce", + "code":"76", + "des":"Read the version compatibility differences and ensure that they are not affected.The patch upgrade does not involve version compatibility differences.", + "doc_type":"usermanual2", + "kw":"Compatibility Risk,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Compatibility Risk", + "githuburl":"" + }, + { + "uri":"cce_10_0442.html", + "product_code":"cce", + "code":"77", + "des":"Check whether cce-agent on the current node is of the latest version.If cce-agent is not of the latest version, the automatic update fails. This problem is usually caused", + "doc_type":"usermanual2", + "kw":"Node CCEAgent Version,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node CCEAgent Version", + "githuburl":"" + }, + { + "uri":"cce_10_0443.html", + "product_code":"cce", + "code":"78", + "des":"Check whether the CPU usage of the node exceeds 90%.Upgrade the cluster during off-peak hours.Check whether too many pods are deployed on the node. If yes, reschedule pod", + "doc_type":"usermanual2", + "kw":"Node CPU Usage,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node CPU Usage", + "githuburl":"" + }, + { + "uri":"cce_10_0444.html", + "product_code":"cce", + "code":"79", + "des":"Check the following aspects:Check whether the key CRD packageversions.version.cce.io of the cluster is deleted.Check whether the cluster key CRD network-attachment-defini", + "doc_type":"usermanual2", + "kw":"CRD Check,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"CRD Check", + "githuburl":"" + }, + { + "uri":"cce_10_0445.html", + "product_code":"cce", + "code":"80", + "des":"Check the following aspects:Check whether the key data disks on the node meet the upgrade requirements.Check whether the /tmp directory has 500 MB available space.During ", + "doc_type":"usermanual2", + "kw":"Node Disk,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Disk", + "githuburl":"" + }, + { + "uri":"cce_10_0446.html", + "product_code":"cce", + "code":"81", + "des":"Check the following aspects:Check whether the DNS configuration of the current node can resolve the OBS address.Check whether the current node can access the OBS address ", + "doc_type":"usermanual2", + "kw":"Node DNS,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node DNS", + "githuburl":"" + }, + { + "uri":"cce_10_0447.html", + "product_code":"cce", + "code":"82", + "des":"Check whether the key directory /var/paas on the nodes contain files with abnormal owners or owner groups.CCE uses the /var/paas directory to manage nodes and store file ", + "doc_type":"usermanual2", + "kw":"Node Key Directory File Permissions,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Key Directory File Permissions", + "githuburl":"" + }, + { + "uri":"cce_10_0448.html", + "product_code":"cce", + "code":"83", + "des":"Check whether the kubelet on the node is running properly.Scenario 1: The kubelet status is abnormal.If the kubelet is abnormal, the node is unavailable. Restore the node", + "doc_type":"usermanual2", + "kw":"Kubelet,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Kubelet", + "githuburl":"" + }, + { + "uri":"cce_10_0449.html", + "product_code":"cce", + "code":"84", + "des":"Check whether the memory usage of the node exceeds 90%.Upgrade the cluster during off-peak hours.Check whether too many pods are deployed on the node. If yes, reschedule ", + "doc_type":"usermanual2", + "kw":"Node Memory,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Memory", + "githuburl":"" + }, + { + "uri":"cce_10_0450.html", + "product_code":"cce", + "code":"85", + "des":"Check whether the clock synchronization server ntpd or chronyd of the node is running properly.Scenario 1: ntpd is running abnormally.Log in to the node and run the syste", + "doc_type":"usermanual2", + "kw":"Node Clock Synchronization Server,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Clock Synchronization Server", + "githuburl":"" + }, + { + "uri":"cce_10_0451.html", + "product_code":"cce", + "code":"86", + "des":"Check whether the OS kernel version of the node is supported by CCE.Running nodes depend on the initial standard kernel version when they are created. CCE has performed c", + "doc_type":"usermanual2", + "kw":"Node OS,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node OS", + "githuburl":"" + }, + { + "uri":"cce_10_0452.html", + "product_code":"cce", + "code":"87", + "des":"Check whether the number of CPUs on the master node is greater than 2.If the number of CPUs on the master node is 2, contact technical support to expand the number to 4 o", + "doc_type":"usermanual2", + "kw":"Node CPU Count,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node CPU Count", + "githuburl":"" + }, + { + "uri":"cce_10_0453.html", + "product_code":"cce", + "code":"88", + "des":"Check whether the Python commands are available on a node.If the command output is not 0, the check fails.Install Python before the upgrade.", + "doc_type":"usermanual2", + "kw":"Node Python Command,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Python Command", + "githuburl":"" + }, + { + "uri":"cce_10_0455.html", + "product_code":"cce", + "code":"89", + "des":"Check whether the nodes in the cluster are ready.Scenario 1: The nodes are in the unavailable status.Log in to the CCE console and access the cluster console. Choose Node", + "doc_type":"usermanual2", + "kw":"Node Readiness,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Readiness", + "githuburl":"" + }, + { + "uri":"cce_10_0456.html", + "product_code":"cce", + "code":"90", + "des":"Check whether journald of a node is normal.Log in to the node and run the systemctl is-active systemd-journald command to query the running status of journald. If the com", + "doc_type":"usermanual2", + "kw":"Node journald,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node journald", + "githuburl":"" + }, + { + "uri":"cce_10_0457.html", + "product_code":"cce", + "code":"91", + "des":"Check whether the containerd.sock file exists on the node. This file affects the startup of container runtime in the Euler OS.Scenario: The Docker used by the node is the", + "doc_type":"usermanual2", + "kw":"containerd.sock Check,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"containerd.sock Check", + "githuburl":"" + }, + { + "uri":"cce_10_0458.html", + "product_code":"cce", + "code":"92", + "des":"Before the upgrade, check whether an internal error occurs.If this check fails, contact technical support.", + "doc_type":"usermanual2", + "kw":"Internal Error,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Internal Error", + "githuburl":"" + }, + { + "uri":"cce_10_0459.html", + "product_code":"cce", + "code":"93", + "des":"Check whether inaccessible mount points exist on the node.Scenario: There are inaccessible mount points on the node.If network NFS (such as OBS, SFS, and SFS) is used by ", + "doc_type":"usermanual2", + "kw":"Node Mount Point,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Mount Point", + "githuburl":"" + }, + { + "uri":"cce_10_0460.html", + "product_code":"cce", + "code":"94", + "des":"Check whether the taint, as shown in Table 1, exists on the node.Taint checklistNameImpactnode.kubernetes.io/upgradeNoScheduleScenario 1: The node is skipped during the c", + "doc_type":"usermanual2", + "kw":"Kubernetes Node Taint,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Kubernetes Node Taint", + "githuburl":"" + }, + { + "uri":"cce_10_0478.html", + "product_code":"cce", + "code":"95", + "des":"Check whether the current everest add-on has compatibility restrictions. See Table 1.The current everest add-on has compatibility restrictions and cannot be upgraded with", + "doc_type":"usermanual2", + "kw":"everest Restriction Check,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"everest Restriction Check", + "githuburl":"" + }, + { + "uri":"cce_10_0479.html", + "product_code":"cce", + "code":"96", + "des":"Check whether the current cce-controller-hpa add-on has compatibility restrictions.The current cce-controller-hpa add-on has compatibility restrictions. An add-on that ca", + "doc_type":"usermanual2", + "kw":"cce-hpa-controller Restriction Check,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"cce-hpa-controller Restriction Check", + "githuburl":"" + }, + { + "uri":"cce_10_0480.html", + "product_code":"cce", + "code":"97", + "des":"Check whether the current cluster version and the target version support enhanced CPU policy.Scenario: The current cluster version uses the enhanced CPU management policy", + "doc_type":"usermanual2", + "kw":"Enhanced CPU Management Policy,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Enhanced CPU Management Policy", + "githuburl":"" + }, + { + "uri":"cce_10_0484.html", + "product_code":"cce", + "code":"98", + "des":"Check whether the container runtime and network components on the user node are healthy.If a component is abnormal, log in to the node to check the status of the abnormal", + "doc_type":"usermanual2", + "kw":"User Node Components Health,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"User Node Components Health", + "githuburl":"" + }, + { + "uri":"cce_10_0485.html", + "product_code":"cce", + "code":"99", + "des":"Check whether the Kubernetes, container runtime, and network components of the controller node are healthy.If a component on the controller node is abnormal, contact tech", + "doc_type":"usermanual2", + "kw":"Controller Node Components Health,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Controller Node Components Health", + "githuburl":"" + }, + { + "uri":"cce_10_0486.html", + "product_code":"cce", + "code":"100", + "des":"Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit.Solution 1: Reducing Kubernetes resourcesSolution 2", + "doc_type":"usermanual2", + "kw":"Memory Resource Limit of Kubernetes Components,Troubleshooting for Pre-upgrade Check Exceptions,User", + "title":"Memory Resource Limit of Kubernetes Components", + "githuburl":"" + }, + { + "uri":"cce_10_0487.html", + "product_code":"cce", + "code":"101", + "des":"The system scans the audit logs of the past day to check whether the user calls the deprecated APIs of the target Kubernetes version.Due to the limited time range of audi", + "doc_type":"usermanual2", + "kw":"Checking Deprecated Kubernetes APIs,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Checking Deprecated Kubernetes APIs", + "githuburl":"" + }, + { + "uri":"cce_10_0488.html", + "product_code":"cce", + "code":"102", + "des":"If IPv6 is enabled for a CCE Turbo cluster, check whether the target cluster version supports IPv6.CCE Turbo clusters support IPv6 since v1.23. This feature is available ", + "doc_type":"usermanual2", + "kw":"IPv6 Capability of a CCE Turbo Cluster,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"IPv6 Capability of a CCE Turbo Cluster", + "githuburl":"" + }, + { + "uri":"cce_10_0489.html", + "product_code":"cce", + "code":"103", + "des":"Check whether NetworkManager of a node is normal.Log in to the node and run the systemctl is-active NetworkManager command to query the running status of NetworkManager. ", + "doc_type":"usermanual2", + "kw":"Node NetworkManager,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node NetworkManager", + "githuburl":"" + }, + { + "uri":"cce_10_0490.html", + "product_code":"cce", + "code":"104", + "des":"Check the ID file format.", + "doc_type":"usermanual2", + "kw":"Node ID File,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node ID File", + "githuburl":"" + }, + { + "uri":"cce_10_0491.html", + "product_code":"cce", + "code":"105", + "des":"When you upgrade a CCE cluster to v1.19 or later, the system checks whether the following configuration files have been modified in the background:/opt/cloud/cce/kubernet", + "doc_type":"usermanual2", + "kw":"Node Configuration Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Configuration Consistency", + "githuburl":"" + }, + { + "uri":"cce_10_0492.html", + "product_code":"cce", + "code":"106", + "des":"Check whether the configuration files of key components exist on the node.The following table lists the files to be checked.Contact technical support to restore the confi", + "doc_type":"usermanual2", + "kw":"Node Configuration File,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "title":"Node Configuration File", + "githuburl":"" + }, + { + "uri":"cce_10_0493.html", + "product_code":"cce", + "code":"107", + "des":"Check whether the current CoreDNS key configuration Corefile is different from the Helm Release record. The difference may be overwritten during the add-on upgrade, affec", + "doc_type":"usermanual2", + "kw":"Checking CoreDNS Configuration Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Gui", + "title":"Checking CoreDNS Configuration Consistency", + "githuburl":"" + }, { "uri":"cce_10_0031.html", "product_code":"cce", - "code":"37", + "code":"108", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Managing a Cluster", @@ -372,17 +1082,17 @@ { "uri":"cce_10_0213.html", "product_code":"cce", - "code":"38", + "code":"109", "des":"CCE allows you to manage cluster parameters, through which you can let core components work under your very requirements.This function is supported only in clusters of v1", "doc_type":"usermanual2", - "kw":"Managing Cluster Components,Managing a Cluster,User Guide", - "title":"Managing Cluster Components", + "kw":"Cluster Configuration Management,Managing a Cluster,User Guide", + "title":"Cluster Configuration Management", "githuburl":"" }, { "uri":"cce_10_0212.html", "product_code":"cce", - "code":"39", + "code":"110", "des":"This section describes how to delete a cluster.Deleting a cluster will delete the nodes in the cluster (excluding accepted nodes), data disks attached to the nodes, workl", "doc_type":"usermanual2", "kw":"Deleting a Cluster,Managing a Cluster,User Guide", @@ -392,7 +1102,7 @@ { "uri":"cce_10_0214.html", "product_code":"cce", - "code":"40", + "code":"111", "des":"If you do not need to use a cluster temporarily, you are advised to hibernate the cluster.After a cluster is hibernated, resources such as workloads cannot be created or ", "doc_type":"usermanual2", "kw":"Hibernating and Waking Up a Cluster,Managing a Cluster,User Guide", @@ -402,7 +1112,7 @@ { "uri":"cce_10_0602.html", "product_code":"cce", - "code":"41", + "code":"112", "des":"If overload control is enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available.The c", "doc_type":"usermanual2", "kw":"Cluster Overload Control,Managing a Cluster,User Guide", @@ -412,7 +1122,7 @@ { "uri":"cce_10_0175.html", "product_code":"cce", - "code":"42", + "code":"113", "des":"This section describes how to obtain the cluster certificate from the console and use it to access Kubernetes clusters.The downloaded certificate contains three files: cl", "doc_type":"usermanual2", "kw":"Obtaining a Cluster Certificate,Clusters,User Guide", @@ -422,7 +1132,7 @@ { "uri":"cce_10_0403.html", "product_code":"cce", - "code":"43", + "code":"114", "des":"CCE allows you to change the number of nodes managed in a cluster.This function is supported for clusters of v1.15 and later versions.Starting from v1.15.11, the number o", "doc_type":"usermanual2", "kw":"Changing Cluster Scale,Clusters,User Guide", @@ -432,7 +1142,7 @@ { "uri":"cce_10_0183.html", "product_code":"cce", - "code":"44", + "code":"115", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"node labels", @@ -442,7 +1152,7 @@ { "uri":"cce_10_0180.html", "product_code":"cce", - "code":"45", + "code":"116", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Node Overview", @@ -452,7 +1162,7 @@ { "uri":"cce_10_0461.html", "product_code":"cce", - "code":"46", + "code":"117", "des":"A container cluster consists of a set of worker machines, called nodes, that run containerized applications. A node can be a virtual machine (VM) or a physical machine (P", "doc_type":"usermanual2", "kw":"Precautions for Using a Node,Node Overview,User Guide", @@ -462,7 +1172,7 @@ { "uri":"cce_10_0462.html", "product_code":"cce", - "code":"47", + "code":"118", "des":"Container engines, one of the most important components of Kubernetes, manage the lifecycle of images and containers. The kubelet interacts with a container runtime throu", "doc_type":"usermanual2", "kw":"Container Engine,Node Overview,User Guide", @@ -472,7 +1182,7 @@ { "uri":"cce_10_0463.html", "product_code":"cce", - "code":"48", + "code":"119", "des":"The most significant difference is that each Kata container (pod) runs on an independent micro-VM, has an independent OS kernel, and is securely isolated at the virtualiz", "doc_type":"usermanual2", "kw":"Kata Containers and Common Containers,Node Overview,User Guide", @@ -482,7 +1192,7 @@ { "uri":"cce_10_0348.html", "product_code":"cce", - "code":"49", + "code":"120", "des":"The maximum number of pods that can be created on a node is determined by the following parameters:Number of container IP addresses that can be allocated on a node (alpha", "doc_type":"usermanual2", "kw":"Maximum Number of Pods That Can Be Created on a Node,Node Overview,User Guide", @@ -492,7 +1202,7 @@ { "uri":"cce_10_0178.html", "product_code":"cce", - "code":"50", + "code":"121", "des":"Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total num", "doc_type":"usermanual2", "kw":"node,Kubernetes,Formula for Calculating the Reserved Resources of a Node,Node Overview,User Guide", @@ -502,7 +1212,7 @@ { "uri":"cce_10_0341.html", "product_code":"cce", - "code":"51", + "code":"122", "des":"This section describes how to allocate data disk space.When creating a node, you need to configure a data disk whose capacity is greater than or equal to 100GB for the no", "doc_type":"usermanual2", "kw":"Data Disk Space Allocation,Node Overview,User Guide", @@ -512,7 +1222,7 @@ { "uri":"cce_10_0363.html", "product_code":"cce", - "code":"52", + "code":"123", "des":"At least one cluster has been created.A key pair has been created for identity authentication upon remote node login.The node has 2-core or higher CPU, 4 GB or larger mem", "doc_type":"usermanual2", "kw":"Creating a Node,Nodes,User Guide", @@ -522,7 +1232,7 @@ { "uri":"cce_10_0198.html", "product_code":"cce", - "code":"53", + "code":"124", "des":"In CCE, you can Creating a Node or add existing nodes (ECSs) into your cluster.While an ECS is being accepted into a cluster, the operating system of the ECS will be rese", "doc_type":"usermanual2", "kw":"Adding Nodes for Management,Nodes,User Guide", @@ -532,7 +1242,7 @@ { "uri":"cce_10_0338.html", "product_code":"cce", - "code":"54", + "code":"125", "des":"Removing a node from a cluster will re-install the node OS and clear CCE components on the node.Removing a node will not delete the server corresponding to the node. You ", "doc_type":"usermanual2", "kw":"Removing a Node,Nodes,User Guide", @@ -542,7 +1252,7 @@ { "uri":"cce_10_0003.html", "product_code":"cce", - "code":"55", + "code":"126", "des":"You can reset a node to modify the node configuration, such as the node OS and login mode.Resetting a node will reinstall the node OS and the Kubernetes software on the n", "doc_type":"usermanual2", "kw":"Resetting a Node,Nodes,User Guide", @@ -552,7 +1262,7 @@ { "uri":"cce_10_0185.html", "product_code":"cce", - "code":"56", + "code":"127", "des":"If you use SSH to log in to a node (an ECS), ensure that the ECS already has an EIP (a public IP address).Only login to a running ECS is allowed.Only the user linux can l", "doc_type":"usermanual2", "kw":"Logging In to a Node,Nodes,User Guide", @@ -562,7 +1272,7 @@ { "uri":"cce_10_0004.html", "product_code":"cce", - "code":"57", + "code":"128", "des":"You can add different labels to nodes and define different attributes for labels. By using these node labels, you can quickly understand the characteristics of each node.", "doc_type":"usermanual2", "kw":"node labels,Inherent Label of a Node,Managing Node Labels,Nodes,User Guide", @@ -572,7 +1282,7 @@ { "uri":"cce_10_0352.html", "product_code":"cce", - "code":"58", + "code":"129", "des":"Taints enable a node to repel specific pods to prevent these pods from being scheduled to the node.A taint is a key-value pair associated with an effect. The following ef", "doc_type":"usermanual2", "kw":"Managing Node Taints,Nodes,User Guide", @@ -582,7 +1292,7 @@ { "uri":"cce_10_0184.html", "product_code":"cce", - "code":"59", + "code":"130", "des":"Each node in a cluster is a cloud server or physical machine. After a cluster node is created, you can change the cloud server name or specifications as required.Some inf", "doc_type":"usermanual2", "kw":"Synchronizing Data with Cloud Servers,Nodes,User Guide", @@ -592,8 +1302,8 @@ { "uri":"cce_10_0186.html", "product_code":"cce", - "code":"60", - "des":"When a node in a CCE cluster is deleted, services running on the node will also be deleted. Exercise caution when performing this operation.After a CCE cluster is deleted", + "code":"131", + "des":"When a node in a CCE cluster is deleted, services running on the node will also be deleted. Exercise caution when performing this operation.VM nodes that are being used b", "doc_type":"usermanual2", "kw":"Deleting a Node,Nodes,User Guide", "title":"Deleting a Node", @@ -602,7 +1312,7 @@ { "uri":"cce_10_0036.html", "product_code":"cce", - "code":"61", + "code":"132", "des":"After a node in the cluster is stopped, services on the node are also stopped. Before stopping a node, ensure that discontinuity of the services on the node will not resu", "doc_type":"usermanual2", "kw":"Stopping a Node,Nodes,User Guide", @@ -612,7 +1322,7 @@ { "uri":"cce_10_0276.html", "product_code":"cce", - "code":"62", + "code":"133", "des":"In a rolling upgrade, a new node is created, existing workloads are migrated to the new node, and then the old node is deleted. Figure 1 shows the migration process.The o", "doc_type":"usermanual2", "kw":"Performing Rolling Upgrade for Nodes,Nodes,User Guide", @@ -622,7 +1332,7 @@ { "uri":"cce_10_0035.html", "product_code":"cce", - "code":"63", + "code":"134", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Node Pools", @@ -632,7 +1342,7 @@ { "uri":"cce_10_0081.html", "product_code":"cce", - "code":"64", + "code":"135", "des":"CCE introduces node pools to help you better manage nodes in Kubernetes clusters. A node pool contains one node or a group of nodes with identical configuration in a clus", "doc_type":"usermanual2", "kw":"Deploying a Workload in a Specified Node Pool,Node Pool Overview,Node Pools,User Guide", @@ -642,7 +1352,7 @@ { "uri":"cce_10_0012.html", "product_code":"cce", - "code":"65", + "code":"136", "des":"This section describes how to create a node pool and perform operations on the node pool. For details about how a node pool works, see Node Pool Overview.The autoscaler a", "doc_type":"usermanual2", "kw":"Creating a Node Pool,Node Pools,User Guide", @@ -652,17 +1362,87 @@ { "uri":"cce_10_0222.html", "product_code":"cce", - "code":"66", + "code":"137", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Managing a Node Pool", + "title":"Managing a Node Pool", + "githuburl":"" + }, + { + "uri":"cce_10_0652.html", + "product_code":"cce", + "code":"138", "des":"The default node pool DefaultPool does not support the following management operations.CCE allows you to highly customize Kubernetes parameter settings on core components", "doc_type":"usermanual2", - "kw":"Managing a Node Pool,Node Pools,User Guide", - "title":"Managing a Node Pool", + "kw":"Configuring a Node Pool,Managing a Node Pool,User Guide", + "title":"Configuring a Node Pool", + "githuburl":"" + }, + { + "uri":"cce_10_0653.html", + "product_code":"cce", + "code":"139", + "des":"When editing the resource tags of the node pool. The modified configuration takes effect only for new nodes. To synchronize the configuration to the existing nodes, you n", + "doc_type":"usermanual2", + "kw":"Updating a Node Pool,Managing a Node Pool,User Guide", + "title":"Updating a Node Pool", + "githuburl":"" + }, + { + "uri":"cce_10_0654.html", + "product_code":"cce", + "code":"140", + "des":"After the configuration of a node pool is updated, some configurations cannot be automatically synchronized for existing nodes. You can manually synchronize configuration", + "doc_type":"usermanual2", + "kw":"Synchronizing Node Pools,Managing a Node Pool,User Guide", + "title":"Synchronizing Node Pools", + "githuburl":"" + }, + { + "uri":"cce_10_0660.html", + "product_code":"cce", + "code":"141", + "des":"When CCE releases a new OS image, existing nodes cannot be automatically upgraded. You can manually upgrade them in batches.This operation will upgrade the OS by resettin", + "doc_type":"usermanual2", + "kw":"Upgrading the OS,Managing a Node Pool,User Guide", + "title":"Upgrading the OS", + "githuburl":"" + }, + { + "uri":"cce_10_0655.html", + "product_code":"cce", + "code":"142", + "des":"You can copy the configuration of an existing node pool to create a new node pool on the CCE console.", + "doc_type":"usermanual2", + "kw":"Copying a Node Pool,Managing a Node Pool,User Guide", + "title":"Copying a Node Pool", + "githuburl":"" + }, + { + "uri":"cce_10_0656.html", + "product_code":"cce", + "code":"143", + "des":"Nodes in a node pool can be migrated. Currently, nodes in a node pool can be migrated only to the default node pool (defaultpool) in the same cluster.The migration has no", + "doc_type":"usermanual2", + "kw":"Migrating a Node,Managing a Node Pool,User Guide", + "title":"Migrating a Node", + "githuburl":"" + }, + { + "uri":"cce_10_0657.html", + "product_code":"cce", + "code":"144", + "des":"Deleting a node pool will delete nodes in the pool. Pods on these nodes will be automatically migrated to available nodes in other node pools.Deleting a node pool will de", + "doc_type":"usermanual2", + "kw":"Deleting a Node Pool,Managing a Node Pool,User Guide", + "title":"Deleting a Node Pool", "githuburl":"" }, { "uri":"cce_10_0046.html", "product_code":"cce", - "code":"67", + "code":"145", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Workloads", @@ -672,7 +1452,7 @@ { "uri":"cce_10_0006.html", "product_code":"cce", - "code":"68", + "code":"146", "des":"A workload is an application running on Kubernetes. No matter how many components are there in your workload, you can run it in a group of Kubernetes pods. A workload is ", "doc_type":"usermanual2", "kw":"Overview,Workloads,User Guide", @@ -682,7 +1462,7 @@ { "uri":"cce_10_0047.html", "product_code":"cce", - "code":"69", + "code":"147", "des":"Deployments are workloads (for example, Nginx) that do not store any data or status. You can create Deployments on the CCE console or by running kubectl commands.Before c", "doc_type":"usermanual2", "kw":"create a workload using kubectl,Creating a Deployment,Workloads,User Guide", @@ -692,7 +1472,7 @@ { "uri":"cce_10_0048.html", "product_code":"cce", - "code":"70", + "code":"148", "des":"StatefulSets are a type of workloads whose data or status is stored while they are running. For example, MySQL is a StatefulSet because it needs to store new data.A conta", "doc_type":"usermanual2", "kw":"Using kubectl,Creating a StatefulSet,Workloads,User Guide", @@ -702,7 +1482,7 @@ { "uri":"cce_10_0216.html", "product_code":"cce", - "code":"71", + "code":"149", "des":"CCE provides deployment and management capabilities for multiple types of containers and supports features of container workloads, including creation, configuration, moni", "doc_type":"usermanual2", "kw":"create a workload using kubectl,Creating a DaemonSet,Workloads,User Guide", @@ -712,7 +1492,7 @@ { "uri":"cce_10_0150.html", "product_code":"cce", - "code":"72", + "code":"150", "des":"Jobs are short-lived and run for a certain time to completion. They can be executed immediately after being deployed. It is completed after it exits normally (exit 0).A j", "doc_type":"usermanual2", "kw":"Creating a Job,Workloads,User Guide", @@ -722,7 +1502,7 @@ { "uri":"cce_10_0151.html", "product_code":"cce", - "code":"73", + "code":"151", "des":"A cron job runs on a repeating schedule. You can perform time synchronization for all active nodes at a fixed time point.A cron job runs periodically at the specified tim", "doc_type":"usermanual2", "kw":"time synchronization,Creating a Cron Job,Workloads,User Guide", @@ -732,7 +1512,7 @@ { "uri":"cce_10_0007.html", "product_code":"cce", - "code":"74", + "code":"152", "des":"After a workload is created, you can upgrade, monitor, roll back, or delete the workload, as well as edit its YAML file.Workload/Job managementOperationDescriptionMonitor", "doc_type":"usermanual2", "kw":"Managing Workloads and Jobs,Workloads,User Guide", @@ -742,7 +1522,7 @@ { "uri":"cce_10_0130.html", "product_code":"cce", - "code":"75", + "code":"153", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Configuring a Container", @@ -752,7 +1532,7 @@ { "uri":"cce_10_0396.html", "product_code":"cce", - "code":"76", + "code":"154", "des":"A workload is an abstract model of a group of pods. One pod can encapsulate one or more containers. You can click Add Container in the upper right corner to add multiple ", "doc_type":"usermanual2", "kw":"Setting Basic Container Information,Configuring a Container,User Guide", @@ -762,7 +1542,7 @@ { "uri":"cce_10_0009.html", "product_code":"cce", - "code":"77", + "code":"155", "des":"CCE allows you to create workloads using images pulled from third-party image repositories.Generally, a third-party image repository can be accessed only after authentica", "doc_type":"usermanual2", "kw":"Using a Third-Party Image,Configuring a Container,User Guide", @@ -772,7 +1552,7 @@ { "uri":"cce_10_0163.html", "product_code":"cce", - "code":"78", + "code":"156", "des":"CCE allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in a workload.", "doc_type":"usermanual2", "kw":"Setting Container Specifications,Configuring a Container,User Guide", @@ -782,7 +1562,7 @@ { "uri":"cce_10_0105.html", "product_code":"cce", - "code":"79", + "code":"157", "des":"CCE provides callback functions for the lifecycle management of containerized applications. For example, if you want a container to perform a certain operation before sto", "doc_type":"usermanual2", "kw":"Startup Command,Post-Start,Pre-Stop,Setting Container Lifecycle Parameters,Configuring a Container,U", @@ -792,7 +1572,7 @@ { "uri":"cce_10_0112.html", "product_code":"cce", - "code":"80", + "code":"158", "des":"Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application ex", "doc_type":"usermanual2", "kw":"Health check,HTTP request,TCP port,CLI,Setting Health Check for a Container,Configuring a Container,", @@ -802,7 +1582,7 @@ { "uri":"cce_10_0113.html", "product_code":"cce", - "code":"81", + "code":"159", "des":"An environment variable is a variable whose value can affect the way a running container will behave. You can modify environment variables even after workloads are deploy", "doc_type":"usermanual2", "kw":"Setting an Environment Variable,Configuring a Container,User Guide", @@ -812,7 +1592,7 @@ { "uri":"cce_10_0353.html", "product_code":"cce", - "code":"82", + "code":"160", "des":"When a workload is created, the container image is pulled from the image repository to the node. The image is also pulled when the workload is restarted or upgraded.By de", "doc_type":"usermanual2", "kw":"Configuring an Image Pull Policy,Configuring a Container,User Guide", @@ -822,7 +1602,7 @@ { "uri":"cce_10_0354.html", "product_code":"cce", - "code":"83", + "code":"161", "des":"When creating a workload, you can configure containers to use the same time zone as the node. You can enable time zone synchronization when creating a workload.The time z", "doc_type":"usermanual2", "kw":"Configuring Time Zone Synchronization,Configuring a Container,User Guide", @@ -832,7 +1612,7 @@ { "uri":"cce_10_0397.html", "product_code":"cce", - "code":"84", + "code":"162", "des":"In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.You can set different upgrade polici", "doc_type":"usermanual2", "kw":"Configuring the Workload Upgrade Policy,Configuring a Container,User Guide", @@ -842,7 +1622,7 @@ { "uri":"cce_10_0232.html", "product_code":"cce", - "code":"85", + "code":"163", "des":"A nodeSelector provides a very simple way to constrain pods to nodes with particular labels, as mentioned in Creating a DaemonSet. The affinity and anti-affinity feature ", "doc_type":"usermanual2", "kw":"Scheduling Policy (Affinity/Anti-affinity),Configuring a Container,User Guide", @@ -852,7 +1632,7 @@ { "uri":"cce_10_0345.html", "product_code":"cce", - "code":"86", + "code":"164", "des":"You can use GPUs in CCE containers.A GPU node has been created. For details, see Creating a Node.The gpu-beta add-on has been installed. During the installation, select t", "doc_type":"usermanual2", "kw":"GPU Scheduling,Workloads,User Guide", @@ -862,7 +1642,7 @@ { "uri":"cce_10_0551.html", "product_code":"cce", - "code":"87", + "code":"165", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"CPU Core Binding", @@ -872,17 +1652,27 @@ { "uri":"cce_10_0351.html", "product_code":"cce", - "code":"88", + "code":"166", "des":"By default, kubelet uses CFS quotas to enforce pod CPU limits. When the node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether t", "doc_type":"usermanual2", "kw":"Binding CPU Cores,CPU Core Binding,User Guide", "title":"Binding CPU Cores", "githuburl":"" }, + { + "uri":"cce_10_00356.html", + "product_code":"cce", + "code":"167", + "des":"If you encounter unexpected problems when using a container, you can log in to the container for debugging.The example output is as follows:NAME ", + "doc_type":"usermanual2", + "kw":"Accessing a Container,Workloads,User Guide", + "title":"Accessing a Container", + "githuburl":"" + }, { "uri":"cce_10_0386.html", "product_code":"cce", - "code":"89", + "code":"168", "des":"CCE allows you to add annotations to a YAML file to realize some advanced pod functions. The following table describes the annotations you can add.When you create a workl", "doc_type":"usermanual2", "kw":"Pod Labels and Annotations,Workloads,User Guide", @@ -892,7 +1682,7 @@ { "uri":"cce_10_0423.html", "product_code":"cce", - "code":"90", + "code":"169", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Volcano Scheduling", @@ -902,7 +1692,7 @@ { "uri":"cce_10_0384.html", "product_code":"cce", - "code":"91", + "code":"170", "des":"Jobs can be classified into online jobs and offline jobs based on whether services are always online.Online job: Such jobs run for a long time, with regular traffic surge", "doc_type":"usermanual2", "kw":"Hybrid Deployment of Online and Offline Jobs,Volcano Scheduling,User Guide", @@ -912,7 +1702,7 @@ { "uri":"cce_10_0288.html", "product_code":"cce", - "code":"92", + "code":"171", "des":"When the Cloud Native Network 2.0 model is used, pods use VPC ENIs or sub-ENIs for networking. You can directly bind security groups and EIPs to pods. CCE provides a cust", "doc_type":"usermanual2", "kw":"Security Group Policies,Workloads,User Guide", @@ -922,7 +1712,7 @@ { "uri":"cce_10_0020.html", "product_code":"cce", - "code":"93", + "code":"172", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Networking", @@ -932,7 +1722,7 @@ { "uri":"cce_10_0010.html", "product_code":"cce", - "code":"94", + "code":"173", "des":"You can learn about a cluster network from the following two aspects:What is a cluster network like? A cluster consists of multiple nodes, and pods (or containers) are ru", "doc_type":"usermanual2", "kw":"Overview,Networking,User Guide", @@ -942,7 +1732,7 @@ { "uri":"cce_10_0280.html", "product_code":"cce", - "code":"95", + "code":"174", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Container Network Models", @@ -952,8 +1742,8 @@ { "uri":"cce_10_0281.html", "product_code":"cce", - "code":"96", - "des":"The container network assigns IP addresses to pods in a cluster and provides networking services. In CCE, you can select the following network models for your cluster:Tun", + "code":"175", + "des":"The container network assigns IP addresses to pods in a cluster and provides networking services. In CCE, you can select the following network models for your cluster:Con", "doc_type":"usermanual2", "kw":"Overview,Container Network Models,User Guide", "title":"Overview", @@ -962,7 +1752,7 @@ { "uri":"cce_10_0282.html", "product_code":"cce", - "code":"97", + "code":"176", "des":"The container tunnel network is constructed on but independent of the node network through tunnel encapsulation. This network model uses VXLAN to encapsulate Ethernet pac", "doc_type":"usermanual2", "kw":"Container Tunnel Network,Container Network Models,User Guide", @@ -972,7 +1762,7 @@ { "uri":"cce_10_0283.html", "product_code":"cce", - "code":"98", + "code":"177", "des":"The VPC network uses VPC routing to integrate with the underlying network. This network model is suitable for performance-intensive scenarios. The maximum number of nodes", "doc_type":"usermanual2", "kw":"VPC Network,Container Network Models,User Guide", @@ -982,7 +1772,7 @@ { "uri":"cce_10_0284.html", "product_code":"cce", - "code":"99", + "code":"178", "des":"Developed by CCE, Cloud Native Network 2.0 deeply integrates Elastic Network Interfaces (ENIs) and sub-ENIs of Virtual Private Cloud (VPC). Container IP addresses are all", "doc_type":"usermanual2", "kw":"Cloud Native Network 2.0,Container Network Models,User Guide", @@ -992,7 +1782,7 @@ { "uri":"cce_10_0247.html", "product_code":"cce", - "code":"100", + "code":"179", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Services", @@ -1002,7 +1792,7 @@ { "uri":"cce_10_0249.html", "product_code":"cce", - "code":"101", + "code":"180", "des":"After a pod is created, the following problems may occur if you directly access the pod:The pod can be deleted and recreated at any time by a controller such as a Deploym", "doc_type":"usermanual2", "kw":"Service Overview,Services,User Guide", @@ -1012,7 +1802,7 @@ { "uri":"cce_10_0011.html", "product_code":"cce", - "code":"102", + "code":"181", "des":"ClusterIP Services allow workloads in the same cluster to use their cluster-internal domain names to access each other.The cluster-internal domain name format is Deployments or StatefulSets in the navigation pane ", "doc_type":"usermanual2", "kw":"Fault Locating and Troubleshooting for Abnormal Workloads,Workload Abnormalities,User Guide", @@ -2222,7 +3022,7 @@ { "uri":"cce_faq_00098.html", "product_code":"cce", - "code":"223", + "code":"303", "des":"Viewing K8s Event InformationCheck Item 1: Checking Whether a Node Is Available in the ClusterCheck Item 2: Checking Whether Node Resources (CPU and Memory) Are Sufficien", "doc_type":"usermanual2", "kw":"workload,InstanceSchedulingFailed,Failed to Schedule an Instance,Workload Abnormalities,User Guide", @@ -2232,7 +3032,7 @@ { "uri":"cce_faq_00015.html", "product_code":"cce", - "code":"224", + "code":"304", "des":"If the workload details page displays an event indicating that image pulling fails, perform the following operations to locate the fault:Check Item 1: Checking Whether im", "doc_type":"usermanual2", "kw":"workload,Failed to Pull an Image,Workload Abnormalities,User Guide", @@ -2242,7 +3042,7 @@ { "uri":"cce_faq_00018.html", "product_code":"cce", - "code":"225", + "code":"305", "des":"On the details page of a workload, if an event is displayed indicating that the container fails to be restarted, perform the following operations to locate the fault:Rect", "doc_type":"usermanual2", "kw":"Failed to Restart a Container,Workload Abnormalities,User Guide", @@ -2252,7 +3052,7 @@ { "uri":"cce_faq_00209.html", "product_code":"cce", - "code":"226", + "code":"306", "des":"Pod actions are classified into the following two types:kube-controller-manager periodically checks the status of all nodes. If a node is in the NotReady state for a peri", "doc_type":"usermanual2", "kw":"What Should I Do If An Evicted Pod Exists?,Workload Abnormalities,User Guide", @@ -2262,7 +3062,7 @@ { "uri":"cce_faq_00140.html", "product_code":"cce", - "code":"227", + "code":"307", "des":"When a node is faulty, pods on the node are evicted to ensure workload availability. If the pods are not evicted when the node is faulty, perform the following steps:Use ", "doc_type":"usermanual2", "kw":"Instance Eviction Exception,Workload Abnormalities,User Guide", @@ -2272,7 +3072,7 @@ { "uri":"cce_faq_00210.html", "product_code":"cce", - "code":"228", + "code":"308", "des":"When a node is in the Unavailable state, CCE migrates container pods on the node and sets the pods running on the node to the Terminating state.After the node is restored", "doc_type":"usermanual2", "kw":"What Should I Do If Pods in the Terminating State Cannot Be Deleted?,Workload Abnormalities,User Gui", @@ -2282,7 +3082,7 @@ { "uri":"cce_faq_00012.html", "product_code":"cce", - "code":"229", + "code":"309", "des":"The metadata.enable field in the YAML file of the workload is false. As a result, the pod of the workload is deleted and the workload is in the stopped status.The workloa", "doc_type":"usermanual2", "kw":"What Should I Do If a Workload Is Stopped Caused by Pod Deletion?,Workload Abnormalities,User Guide", @@ -2292,7 +3092,7 @@ { "uri":"cce_faq_00005.html", "product_code":"cce", - "code":"230", + "code":"310", "des":"The pod remains in the creating state for a long time, and the sandbox-related errors are reported.Select a troubleshooting method for your cluster:Clusters of V1.13 or l", "doc_type":"usermanual2", "kw":"What Should I Do If Sandbox-Related Errors Are Reported When the Pod Remains in the Creating State?,", @@ -2302,7 +3102,7 @@ { "uri":"cce_faq_00199.html", "product_code":"cce", - "code":"231", + "code":"311", "des":"Workload pods in the cluster fail and are being redeployed constantly.After the following command is run, the command output shows that many pods are in the evicted state", "doc_type":"usermanual2", "kw":"What Should I Do If a Pod Is in the Evicted State?,Workload Abnormalities,User Guide", @@ -2312,7 +3112,7 @@ { "uri":"cce_faq_00002.html", "product_code":"cce", - "code":"232", + "code":"312", "des":"If a node has sufficient memory resources, a container on this node can use more memory resources than requested, but no more than limited. If the memory allocated to a c", "doc_type":"usermanual2", "kw":"What Should I Do If the OOM Killer Is Triggered When a Container Uses Memory Resources More Than Lim", @@ -2322,7 +3122,7 @@ { "uri":"cce_faq_00202.html", "product_code":"cce", - "code":"233", + "code":"313", "des":"A workload can be accessed from public networks through a load balancer. LoadBalancer provides higher reliability than EIP-based NodePort because an EIP is no longer boun", "doc_type":"usermanual2", "kw":"What Should I Do If a Service Released in a Workload Cannot Be Accessed from Public Networks?,Refere", @@ -2332,7 +3132,7 @@ { "uri":"cce_faq_00266.html", "product_code":"cce", - "code":"234", + "code":"314", "des":"A VPC is similar to a private local area network (LAN) managed by a home gateway whose IP address is 192.168.0.0/16. A VPC is a private network built on the cloud and pro", "doc_type":"usermanual2", "kw":"VPC,cluster,nodes,What Is the Relationship Between Clusters, VPCs, and Subnets?,Reference,User Guide", @@ -2342,7 +3142,7 @@ { "uri":"cce_faq_00265.html", "product_code":"cce", - "code":"235", + "code":"315", "des":"CCE is a universal container platform. Its default security group rules apply to common scenarios. Based on security requirements, you can harden the security group rules", "doc_type":"usermanual2", "kw":"How Do I Harden the VPC Security Group Rules for CCE Cluster Nodes?,Reference,User Guide", @@ -2352,7 +3152,7 @@ { "uri":"cce_bestpractice.html", "product_code":"cce", - "code":"236", + "code":"316", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Best Practice", @@ -2362,17 +3162,137 @@ { "uri":"cce_bestpractice_00006.html", "product_code":"cce", - "code":"237", + "code":"317", "des":"Security, efficiency, stability, and availability are common requirements on all cloud services. To meet these requirements, the system availability, data reliability, an", "doc_type":"usermanual2", "kw":"Checklist for Deploying Containerized Applications in the Cloud,Best Practice,User Guide", "title":"Checklist for Deploying Containerized Applications in the Cloud", "githuburl":"" }, + { + "uri":"cce_bestpractice_0321.html", + "product_code":"cce", + "code":"318", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Containerization", + "title":"Containerization", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0001.html", + "product_code":"cce", + "code":"319", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Containerizing an Enterprise Application (ERP)", + "title":"Containerizing an Enterprise Application (ERP)", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0002.html", + "product_code":"cce", + "code":"320", + "des":"This chapter provides CCE best practices to walk you through the application containerization.A container is a lightweight high-performance resource isolation mechanism i", + "doc_type":"usermanual2", + "kw":"enterprise resource planning (ERP),Solution Overview,Containerizing an Enterprise Application (ERP),", + "title":"Solution Overview", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0340.html", + "product_code":"cce", + "code":"321", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Procedure", + "title":"Procedure", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0003.html", + "product_code":"cce", + "code":"322", + "des":"This tutorial describes how to containerize an ERP system by migrating it from a VM to CCE.No recoding or re-architecting is required. You only need to pack the entire ap", + "doc_type":"usermanual2", + "kw":"Containerizing an Entire Application,Procedure,User Guide", + "title":"Containerizing an Entire Application", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0004.html", + "product_code":"cce", + "code":"323", + "des":"The following figure illustrates the process of containerizing an application.", + "doc_type":"usermanual2", + "kw":"Containerization Process,Procedure,User Guide", + "title":"Containerization Process", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0005.html", + "product_code":"cce", + "code":"324", + "des":"Before containerizing an application, you need to analyze the running environment and dependencies of the application, and get familiar with the application deployment mo", + "doc_type":"usermanual2", + "kw":"containerizing an application,Analyzing the Application,Procedure,User Guide", + "title":"Analyzing the Application", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0006.html", + "product_code":"cce", + "code":"325", + "des":"After application analysis, you have gained the understanding of the OS and runtime required for running the application. You need to make the following preparations:Inst", + "doc_type":"usermanual2", + "kw":"Preparing the Application Runtime,Procedure,User Guide", + "title":"Preparing the Application Runtime", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0007.html", + "product_code":"cce", + "code":"326", + "des":"During application containerization, you need to prepare a startup script. The method of compiling this script is the same as that of compiling a shell script. The startu", + "doc_type":"usermanual2", + "kw":"Compiling a Startup Script,Procedure,User Guide", + "title":"Compiling a Startup Script", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0008.html", + "product_code":"cce", + "code":"327", + "des":"An image is the basis of a container. A container runs based on the content defined in the image. An image has multiple layers. Each layer includes the modifications made", + "doc_type":"usermanual2", + "kw":"Compiling the Dockerfile,Procedure,User Guide", + "title":"Compiling the Dockerfile", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0009.html", + "product_code":"cce", + "code":"328", + "des":"This section describes how to build an entire application into a Docker image. After building an image, you can use the image to deploy and upgrade the application. This ", + "doc_type":"usermanual2", + "kw":"Building and Uploading an Image,Procedure,User Guide", + "title":"Building and Uploading an Image", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_0010.html", + "product_code":"cce", + "code":"329", + "des":"This section describes how to deploy a workload on CCE. When using CCE for the first time, create an initial cluster and add a node into the cluster.Containerized workloa", + "doc_type":"usermanual2", + "kw":"Creating a Container Workload,Procedure,User Guide", + "title":"Creating a Container Workload", + "githuburl":"" + }, { "uri":"cce_bestpractice_00237.html", "product_code":"cce", - "code":"238", + "code":"330", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Migration", @@ -2382,7 +3302,7 @@ { "uri":"cce_bestpractice_0306.html", "product_code":"cce", - "code":"239", + "code":"331", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Migrating On-premises Kubernetes Clusters to CCE", @@ -2392,7 +3312,7 @@ { "uri":"cce_bestpractice_0307.html", "product_code":"cce", - "code":"240", + "code":"332", "des":"Containers are growing in popularity and Kubernetes simplifies containerized deployment. Many companies choose to build their own Kubernetes clusters. However, the O&M wo", "doc_type":"usermanual2", "kw":"Solution Overview,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2402,7 +3322,7 @@ { "uri":"cce_bestpractice_0308.html", "product_code":"cce", - "code":"241", + "code":"333", "des":"CCE allows you to customize cluster resources to meet various service requirements. Table 1 lists the key performance parameters of a cluster and provides the planned val", "doc_type":"usermanual2", "kw":"Planning Resources for the Target Cluster,Migrating On-premises Kubernetes Clusters to CCE,User Guid", @@ -2412,7 +3332,7 @@ { "uri":"cce_bestpractice_0309.html", "product_code":"cce", - "code":"242", + "code":"334", "des":"If your migration does not involve resources outside a cluster listed in Table 1 or you do not need to use other services to update resources after the migration, skip th", "doc_type":"usermanual2", "kw":"Migrating Resources Outside a Cluster,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2422,7 +3342,7 @@ { "uri":"cce_bestpractice_0310.html", "product_code":"cce", - "code":"243", + "code":"335", "des":"Velero is an open-source backup and migration tool for Kubernetes clusters. It integrates the persistent volume (PV) data backup capability of the Restic tool and can be ", "doc_type":"usermanual2", "kw":"Installing the Migration Tool,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2432,7 +3352,7 @@ { "uri":"cce_bestpractice_0311.html", "product_code":"cce", - "code":"244", + "code":"336", "des":"WordPress is used as an example to describe how to migrate an application from an on-premises Kubernetes cluster to a CCE cluster. The WordPress application consists of t", "doc_type":"usermanual2", "kw":"Migrating Resources in a Cluster,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2442,7 +3362,7 @@ { "uri":"cce_bestpractice_0312.html", "product_code":"cce", - "code":"245", + "code":"337", "des":"The WordPress and MySQL images used in this example can be pulled from SWR. Therefore, the image pull failure (ErrImagePull) will not occur. If the application to be migr", "doc_type":"usermanual2", "kw":"Updating Resources Accordingly,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2452,7 +3372,7 @@ { "uri":"cce_bestpractice_0313.html", "product_code":"cce", - "code":"246", + "code":"338", "des":"Cluster migration involves full migration of application data, which may cause intra-application adaptation problems. In this example, after the cluster is migrated, the ", "doc_type":"usermanual2", "kw":"Performing Additional Tasks,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2462,7 +3382,7 @@ { "uri":"cce_bestpractice_0314.html", "product_code":"cce", - "code":"247", + "code":"339", "des":"Both HostPath and Local volumes are local storage volumes. However, the Restic tool integrated in Velero cannot back up the PVs of the HostPath type and supports only the", "doc_type":"usermanual2", "kw":"Troubleshooting,Migrating On-premises Kubernetes Clusters to CCE,User Guide", @@ -2472,7 +3392,7 @@ { "uri":"cce_bestpractice_0322.html", "product_code":"cce", - "code":"248", + "code":"340", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"DevOps", @@ -2482,7 +3402,7 @@ { "uri":"cce_bestpractice_0324.html", "product_code":"cce", - "code":"249", + "code":"341", "des":"GitLab is an open-source version management system developed with Ruby on Rails for Git project repository management. It supports web-based access to public and private ", "doc_type":"usermanual2", "kw":"Interconnecting GitLab with SWR and CCE for CI/CD,DevOps,User Guide", @@ -2492,7 +3412,7 @@ { "uri":"cce_bestpractice_0323.html", "product_code":"cce", - "code":"250", + "code":"342", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Disaster Recovery", @@ -2502,7 +3422,7 @@ { "uri":"cce_bestpractice_00220.html", "product_code":"cce", - "code":"251", + "code":"343", "des":"To achieve high availability for your CCE containers, you can do as follows:Deploy three master nodes for the cluster.When nodes are deployed across AZs, set custom sched", "doc_type":"usermanual2", "kw":"Implementing High Availability for Containers in CCE,Disaster Recovery,User Guide", @@ -2512,7 +3432,7 @@ { "uri":"cce_bestpractice_0315.html", "product_code":"cce", - "code":"252", + "code":"344", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Security", @@ -2522,7 +3442,7 @@ { "uri":"cce_bestpractice_0317.html", "product_code":"cce", - "code":"253", + "code":"345", "des":"For security purposes, you are advised to configure a cluster as follows.Kubernetes releases a major version in about four months. CCE follows the same frequency as Kuber", "doc_type":"usermanual2", "kw":"Cluster Security,Security,User Guide", @@ -2532,7 +3452,7 @@ { "uri":"cce_bestpractice_0318.html", "product_code":"cce", - "code":"254", + "code":"346", "des":"Do not bind an EIP to a node unless necessary to reduce the attack surface.If an EIP must be used, properly configure the firewall or security group rules to restrict acc", "doc_type":"usermanual2", "kw":"Node Security,Security,User Guide", @@ -2542,7 +3462,7 @@ { "uri":"cce_bestpractice_0319.html", "product_code":"cce", - "code":"255", + "code":"347", "des":"The nodeSelector or nodeAffinity is used to limit the range of nodes to which applications can be scheduled, preventing the entire cluster from being threatened due to th", "doc_type":"usermanual2", "kw":"Container Security,Security,User Guide", @@ -2552,7 +3472,7 @@ { "uri":"cce_bestpractice_0320.html", "product_code":"cce", - "code":"256", + "code":"348", "des":"Currently, CCE has configured static encryption for secret resources. The secrets created by users will be encrypted and stored in etcd of the CCE cluster. Secrets can be", "doc_type":"usermanual2", "kw":"Secret Security,Security,User Guide", @@ -2562,7 +3482,7 @@ { "uri":"cce_bestpractice_0090.html", "product_code":"cce", - "code":"257", + "code":"349", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Auto Scaling", @@ -2572,17 +3492,37 @@ { "uri":"cce_bestpractice_00282.html", "product_code":"cce", - "code":"258", + "code":"350", "des":"The best way to handle surging traffic is to automatically adjust the number of machines based on the traffic volume or resource usage, which is called scaling.In CCE, th", "doc_type":"usermanual2", "kw":"Using HPA and CA for Auto Scaling of Workloads and Nodes,Auto Scaling,User Guide", "title":"Using HPA and CA for Auto Scaling of Workloads and Nodes", "githuburl":"" }, + { + "uri":"cce_bestpractice_10008.html", + "product_code":"cce", + "code":"351", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Monitoring", + "title":"Monitoring", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_10009.html", + "product_code":"cce", + "code":"352", + "des":"Generally, a user has different clusters for different purposes, such as production, testing, and development. To monitor, collect, and view metrics of these clusters, yo", + "doc_type":"usermanual2", + "kw":"Using Prometheus for Multi-cluster Monitoring,Monitoring,User Guide", + "title":"Using Prometheus for Multi-cluster Monitoring", + "githuburl":"" + }, { "uri":"cce_bestpractice_0050.html", "product_code":"cce", - "code":"259", + "code":"353", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Cluster", @@ -2592,7 +3532,7 @@ { "uri":"cce_bestpractice_00254.html", "product_code":"cce", - "code":"260", + "code":"354", "des":"When you have multiple CCE clusters, you may find it difficult to efficiently connect to all of them.This section describes how to configure access to multiple clusters b", "doc_type":"usermanual2", "kw":"Connecting to Multiple Clusters Using kubectl,Cluster,User Guide", @@ -2602,17 +3542,27 @@ { "uri":"cce_bestpractice_00190.html", "product_code":"cce", - "code":"261", + "code":"355", "des":"You can use the pre-installation script feature to configure CCE cluster nodes (ECSs).When creating a node in a cluster of v1.13.10 or later, if a data disk is not manage", "doc_type":"usermanual2", "kw":"Adding a Second Data Disk to a Node in a CCE Cluster,Cluster,User Guide", "title":"Adding a Second Data Disk to a Node in a CCE Cluster", "githuburl":"" }, + { + "uri":"cce_bestpractice_10012.html", + "product_code":"cce", + "code":"356", + "des":"When a node is created, a data disk is created by default for container runtime and kubelet components to use. The data disk used by the container runtime and kubelet co", + "doc_type":"usermanual2", + "kw":"Selecting a Data Disk for the Node,Cluster,User Guide", + "title":"Selecting a Data Disk for the Node", + "githuburl":"" + }, { "uri":"cce_bestpractice_0052.html", "product_code":"cce", - "code":"262", + "code":"357", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Networking", @@ -2622,7 +3572,7 @@ { "uri":"cce_bestpractice_00004.html", "product_code":"cce", - "code":"263", + "code":"358", "des":"Before creating a cluster on CCE, determine the number of VPCs, number of subnets, container CIDR blocks, and Services for access based on service requirements.This topic", "doc_type":"usermanual2", "kw":"Planning CIDR Blocks for a Cluster,Networking,User Guide", @@ -2632,8 +3582,8 @@ { "uri":"cce_bestpractice_00162.html", "product_code":"cce", - "code":"264", - "des":"CCE uses self-proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models.After a cluster i", + "code":"359", + "des":"CCE uses proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models.After a cluster is cre", "doc_type":"usermanual2", "kw":"Selecting a Network Model,Networking,User Guide", "title":"Selecting a Network Model", @@ -2642,7 +3592,7 @@ { "uri":"cce_bestpractice_00231.html", "product_code":"cce", - "code":"265", + "code":"360", "des":"Session persistence is one of the most common while complex problems in load balancing.Session persistence is also called sticky sessions. After the sticky session functi", "doc_type":"usermanual2", "kw":"Implementing Sticky Session Through Load Balancing,Networking,User Guide", @@ -2652,7 +3602,7 @@ { "uri":"cce_bestpractice_00035.html", "product_code":"cce", - "code":"266", + "code":"361", "des":"There may be different types of proxy servers between a client and a container server. How can a container obtain the real source IP address of the client? This section d", "doc_type":"usermanual2", "kw":"Obtaining the Client Source IP Address for a Container,Networking,User Guide", @@ -2662,7 +3612,7 @@ { "uri":"cce_bestpractice_0053.html", "product_code":"cce", - "code":"267", + "code":"362", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Storage", @@ -2672,8 +3622,8 @@ { "uri":"cce_bestpractice_00198.html", "product_code":"cce", - "code":"268", - "des":"A data disk is divided depending on the container storage Rootfs:Overlayfs: No independent thin pool is allocated. Image data is stored in the dockersys disk.# lsblk\nNAME", + "code":"363", + "des":"EulerOS 2.9 is used as the sample OS. Originally, system disk /dev/vda has 50 GB and one partition (/dev/vda1), and then 50 GB is added to the disk. In this example, the ", "doc_type":"usermanual2", "kw":"Expanding Node Disk Capacity,Storage,User Guide", "title":"Expanding Node Disk Capacity", @@ -2682,7 +3632,7 @@ { "uri":"cce_bestpractice_00199.html", "product_code":"cce", - "code":"269", + "code":"364", "des":"This section describes how to mount OBS buckets and OBS parallel file systems (preferred) of third-party tenants.The CCE cluster of a SaaS service provider needs to be mo", "doc_type":"usermanual2", "kw":"Mounting an Object Storage Bucket of a Third-Party Tenant,Storage,User Guide", @@ -2690,9 +3640,9 @@ "githuburl":"" }, { - "uri":"cce_bestpractice_00253_0.html", + "uri":"cce_bestpractice_00253.html", "product_code":"cce", - "code":"270", + "code":"365", "des":"The minimum capacity of an SFS Turbo file system is 500 GB, and the SFS Turbo file system cannot be billed by usage. By default, the root directory of an SFS Turbo file s", "doc_type":"usermanual2", "kw":"Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System,Storage,User Guide", @@ -2702,7 +3652,7 @@ { "uri":"cce_bestpractice_0107.html", "product_code":"cce", - "code":"271", + "code":"366", "des":"In clusters later than v1.15.11-r1, CSI (the everest add-on) has taken over all functions of fuxi FlexVolume (the storage-driver add-on) for managing container storage. Y", "doc_type":"usermanual2", "kw":"How Do I Change the Storage Class Used by a Cluster of v1.15 from FlexVolume to CSI Everest?,Storage", @@ -2710,9 +3660,9 @@ "githuburl":"" }, { - "uri":"cce_bestpractice_00281_0.html", + "uri":"cce_bestpractice_00281.html", "product_code":"cce", - "code":"272", + "code":"367", "des":"When using storage resources in CCE, the most common method is to specify storageClassName to define the type of storage resources to be created when creating a PVC. The ", "doc_type":"usermanual2", "kw":"Custom Storage Classes,Storage,User Guide", @@ -2722,7 +3672,7 @@ { "uri":"cce_bestpractice_00284.html", "product_code":"cce", - "code":"273", + "code":"368", "des":"EVS disks cannot be attached across AZs. For example, EVS disks in AZ 1 cannot be attached to nodes in AZ 2.If the storage class csi-disk is used for StatefulSets, when a", "doc_type":"usermanual2", "kw":"Realizing Automatic Topology for EVS Disks When Nodes Are Deployed Across AZs (csi-disk-topology),St", @@ -2732,7 +3682,7 @@ { "uri":"cce_bestpractice_0051.html", "product_code":"cce", - "code":"274", + "code":"369", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Container", @@ -2742,7 +3692,7 @@ { "uri":"cce_bestpractice_00002.html", "product_code":"cce", - "code":"275", + "code":"370", "des":"If a node has sufficient memory resources, a container on this node can use more memory resources than requested, but no more than limited. If the memory allocated to a c", "doc_type":"usermanual2", "kw":"Properly Allocating Container Computing Resources,Container,User Guide", @@ -2752,7 +3702,7 @@ { "uri":"cce_bestpractice_00227.html", "product_code":"cce", - "code":"276", + "code":"371", "des":"To access a Kubernetes cluster from a client, you can use the Kubernetes command line tool kubectl.Create a DaemonSet file.vi daemonSet.yamlAn example YAML file is provid", "doc_type":"usermanual2", "kw":"Modifying Kernel Parameters Using a Privileged Container,Container,User Guide", @@ -2762,7 +3712,7 @@ { "uri":"cce_bestpractice_00228.html", "product_code":"cce", - "code":"277", + "code":"372", "des":"Before containers running applications are started, one or some init containers are started first. If there are multiple init containers, they will be started in the defi", "doc_type":"usermanual2", "kw":"Initializing a Container,Container,User Guide", @@ -2772,7 +3722,7 @@ { "uri":"cce_bestpractice_00226.html", "product_code":"cce", - "code":"278", + "code":"373", "des":"If DNS or other related settings are inappropriate, you can use hostAliases to overwrite the resolution of the host name at the pod level when adding entries to the /etc/", "doc_type":"usermanual2", "kw":"Using hostAliases to Configure /etc/hosts in a Pod,Container,User Guide", @@ -2782,17 +3732,67 @@ { "uri":"cce_bestpractice_0325.html", "product_code":"cce", - "code":"279", + "code":"374", "des":"Linux allows you to create a core dump file if an application crashes, which contains the data the application had in memory at the time of the crash. You can analyze the", "doc_type":"usermanual2", "kw":"Configuring Core Dumps,Container,User Guide", "title":"Configuring Core Dumps", "githuburl":"" }, + { + "uri":"cce_bestpractice_0055.html", + "product_code":"cce", + "code":"375", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Permission", + "title":"Permission", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_00221.html", + "product_code":"cce", + "code":"376", + "des":"By default, the kubeconfig file provided by CCE for users has permissions bound to the cluster-admin role, which are equivalent to the permissions of user root. It is dif", + "doc_type":"usermanual2", + "kw":"Configuring kubeconfig for Fine-Grained Management on Cluster Resources,Permission,User Guide", + "title":"Configuring kubeconfig for Fine-Grained Management on Cluster Resources", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_10000.html", + "product_code":"cce", + "code":"377", + "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "doc_type":"usermanual2", + "kw":"Release", + "title":"Release", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_10001.html", + "product_code":"cce", + "code":"378", + "des":"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 a", + "doc_type":"usermanual2", + "kw":"Overview,Release,User Guide", + "title":"Overview", + "githuburl":"" + }, + { + "uri":"cce_bestpractice_10002.html", + "product_code":"cce", + "code":"379", + "des":"To implement grayscale release for a CCE cluster, you need to deploy other open-source tools, such as Nginx Ingress, to the cluster or deploy services to a service mesh. ", + "doc_type":"usermanual2", + "kw":"Using Services to Implement Simple Grayscale Release and Blue-Green Deployment,Release,User Guide", + "title":"Using Services to Implement Simple Grayscale Release and Blue-Green Deployment", + "githuburl":"" + }, { "uri":"cce_01_9999.html", "product_code":"cce", - "code":"280", + "code":"380", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Migrating Data from CCE 1.0 to CCE 2.0", @@ -2802,7 +3802,7 @@ { "uri":"cce_01_9998.html", "product_code":"cce", - "code":"281", + "code":"381", "des":"CCE 2.0 inherits and modifies the features of CCE 1.0, and release new features.Modified features:Clusters in CCE 1.0 are equivalent to Hybrid clusters in CCE 2.0.CCE 2.0", "doc_type":"usermanual2", "kw":"Differences Between CCE 1.0 and CCE 2.0,Migrating Data from CCE 1.0 to CCE 2.0,User Guide", @@ -2812,7 +3812,7 @@ { "uri":"cce_01_9997.html", "product_code":"cce", - "code":"282", + "code":"382", "des":"Migrate the images stored in the image repository of CCE 1.0 to CCE 2.0.A VM is available. The VM is bound to a public IP address and can access the Internet. Docker (ear", "doc_type":"usermanual2", "kw":"Migrating Images,Migrating Data from CCE 1.0 to CCE 2.0,User Guide", @@ -2822,7 +3822,7 @@ { "uri":"cce_01_9996.html", "product_code":"cce", - "code":"283", + "code":"383", "des":"Create Hybrid clusters on the CCE 2.0 console. These new Hybrid clusters should have the same specifications with those created on CCE 1.0.To create clusters using APIs, ", "doc_type":"usermanual2", "kw":"Migrating Clusters,Migrating Data from CCE 1.0 to CCE 2.0,User Guide", @@ -2832,7 +3832,7 @@ { "uri":"cce_01_9995.html", "product_code":"cce", - "code":"284", + "code":"384", "des":"This section describes how to create a Deployment with the same specifications as that in CCE 1.0 on the CCE 2.0 console.It is advised to delete the applications on CCE 1", "doc_type":"usermanual2", "kw":"Migrating Applications,Migrating Data from CCE 1.0 to CCE 2.0,User Guide", @@ -2842,7 +3842,7 @@ { "uri":"cce_01_0300.html", "product_code":"cce", - "code":"285", + "code":"385", "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "doc_type":"usermanual2", "kw":"Change History,User Guide", diff --git a/docs/cce/umn/CLASS.TXT.json b/docs/cce/umn/CLASS.TXT.json index afd0e381..a7781fa9 100644 --- a/docs/cce/umn/CLASS.TXT.json +++ b/docs/cce/umn/CLASS.TXT.json @@ -1,22 +1,139 @@ [ { - "desc":"Cloud Container Engine (CCE) provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily dep", + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "product_code":"cce", - "title":"What Is Cloud Container Engine?", - "uri":"cce_01_0091.html", + "title":"Service Overview", + "uri":"en-us_topic_0000001550437509.html", "doc_type":"usermanual2", "p_code":"", "code":"1" }, { - "desc":"This document provides instructions for getting started with the Cloud Container Engine (CCE).Complete the following tasks to get started with CCE.The accounts have the p", + "desc":"Cloud Container Engine (CCE) is a scalable, enterprise-class hosted Kubernetes service. With CCE, you can easily deploy, manage, and scale containerized applications in t", "product_code":"cce", - "title":"Instruction", - "uri":"cce_qs_0001.html", + "title":"What Is Cloud Container Engine?", + "uri":"cce_01_0091.html", "doc_type":"usermanual2", - "p_code":"", + "p_code":"1", "code":"2" }, + { + "desc":"CCE is a container service built on Docker and Kubernetes. A wealth of features enable you to run container clusters at scale. CCE eases containerization thanks to its re", + "product_code":"cce", + "title":"Product Advantages", + "uri":"cce_productdesc_0003.html", + "doc_type":"usermanual2", + "p_code":"1", + "code":"3" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Application Scenarios", + "uri":"cce_productdesc_0007.html", + "doc_type":"usermanual2", + "p_code":"1", + "code":"4" + }, + { + "desc":"In CCE, you can run clusters with x86 and Arm nodes. Create and manage Kubernetes clusters. Deploy containerized applications in them. All done in CCE.Containerization re", + "product_code":"cce", + "title":"Infrastructure and Containerized Application Management", + "uri":"cce_productdesc_0020.html", + "doc_type":"usermanual2", + "p_code":"4", + "code":"5" + }, + { + "desc":"Shopping apps and websites, especially during promotions and flash salesLive streaming, where service loads often fluctuateGames, where many players may go online in cert", + "product_code":"cce", + "title":"Auto Scaling in Seconds", + "uri":"cce_productdesc_0015.html", + "doc_type":"usermanual2", + "p_code":"4", + "code":"6" + }, + { + "desc":"You may receive a lot feedback and requirements for your apps or services. You may want to boost user experience with new features. Continuous integration (CI) and delive", + "product_code":"cce", + "title":"DevOps and CI/CD", + "uri":"cce_productdesc_0017.html", + "doc_type":"usermanual2", + "p_code":"4", + "code":"7" + }, + { + "desc":"Multi-cloud deployment and disaster recoveryRunning apps in containers on different clouds can ensure high availability. When a cloud is down, other clouds respond and se", + "product_code":"cce", + "title":"Hybrid Cloud Architecture", + "uri":"cce_productdesc_0018.html", + "doc_type":"usermanual2", + "p_code":"4", + "code":"8" + }, + { + "desc":"This section describes the notes and constraints on using CCE.After a cluster is created, the following items cannot be changed:Number of master nodes. For example, you c", + "product_code":"cce", + "title":"Notes and Constraints", + "uri":"cce_productdesc_0005.html", + "doc_type":"usermanual2", + "p_code":"1", + "code":"9" + }, + { + "desc":"CCE allows you to assign permissions to IAM users and user groups under your tenant accounts. CCE combines the advantages of Identity and Access Management (IAM) and Kube", + "product_code":"cce", + "title":"Permissions", + "uri":"cce_productdesc_0002.html", + "doc_type":"usermanual2", + "p_code":"1", + "code":"10" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Basic Concepts", + "uri":"cce_productdesc_0004.html", + "doc_type":"usermanual2", + "p_code":"1", + "code":"11" + }, + { + "desc":"CCE provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale co", + "product_code":"cce", + "title":"Basic Concepts", + "uri":"cce_productdesc_0011.html", + "doc_type":"usermanual2", + "p_code":"11", + "code":"12" + }, + { + "desc":"Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of container clusters. It is a container orchestration tool and a leading sol", + "product_code":"cce", + "title":"Mappings Between CCE and Kubernetes Terms", + "uri":"cce_productdesc_0010.html", + "doc_type":"usermanual2", + "p_code":"11", + "code":"13" + }, + { + "desc":"A region and availability zone (AZ) identify the location of a data center. You can create resources in a specific region and AZ.Regions are divided based on geographical", + "product_code":"cce", + "title":"Regions and AZs", + "uri":"cce_productdesc_0012.html", + "doc_type":"usermanual2", + "p_code":"11", + "code":"14" + }, + { + "desc":"CCE works with the following cloud services and requires permissions to access them.", + "product_code":"cce", + "title":"Related Services", + "uri":"cce_productdesc_0008.html", + "doc_type":"usermanual2", + "p_code":"1", + "code":"15" + }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "product_code":"cce", @@ -24,16 +141,7 @@ "uri":"cce_bulletin_0000.html", "doc_type":"usermanual2", "p_code":"", - "code":"3" - }, - { - "desc":"When performing operations such as creating, deleting, and scaling clusters, do not change user permission in the Identity and Access Management (IAM) console. Otherwise,", - "product_code":"cce", - "title":"Risky Operations on Cluster Nodes", - "uri":"cce_bulletin_0054.html", - "doc_type":"usermanual2", - "p_code":"3", - "code":"4" + "code":"16" }, { "desc":"This section explains versioning in CCE, and the policies for Kubernetes version support.Version number: The format is x.y.z, where x.y is the major version and z is the ", @@ -41,8 +149,8 @@ "title":"Kubernetes Version Support Mechanism", "uri":"cce_bulletin_0003.html", "doc_type":"usermanual2", - "p_code":"3", - "code":"5" + "p_code":"16", + "code":"17" }, { "desc":"To ensure that stable and reliable Kubernetes versions are available during your use of CCE, CCE provides the Kubernetes version support mechanism. A new supported versio", @@ -50,17 +158,17 @@ "title":"CCE Cluster Version Release Notes", "uri":"cce_bulletin_0068.html", "doc_type":"usermanual2", - "p_code":"3", - "code":"6" + "p_code":"16", + "code":"18" }, { - "desc":"CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9 and CentOS 7.7. The following table lists the supported patches for these OSs.The OS patches and verifica", + "desc":"CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9, CentOS 7.7 and Ubuntu 22.04. The following table lists the supported patches for these OSs.The OS patche", "product_code":"cce", "title":"OS Patch Notes for Cluster Nodes", "uri":"cce_bulletin_0301.html", "doc_type":"usermanual2", - "p_code":"3", - "code":"7" + "p_code":"16", + "code":"19" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -68,8 +176,8 @@ "title":"Security Vulnerability Responses", "uri":"cce_bulletin_0169.html", "doc_type":"usermanual2", - "p_code":"3", - "code":"8" + "p_code":"16", + "code":"20" }, { "desc":"High-risk vulnerabilities:CCE fixes vulnerabilities as soon as possible after the Kubernetes community detects them and releases fixing solutions. The fixing policies are", @@ -77,8 +185,8 @@ "title":"Vulnerability Fixing Policies", "uri":"cce_bulletin_0011.html", "doc_type":"usermanual2", - "p_code":"8", - "code":"9" + "p_code":"20", + "code":"21" }, { "desc":"Recently, a security research team disclosed a privilege escalation vulnerability (CVE-2021-4034, also dubbed PwnKit) in PolKit's pkexec. Unprivileged users can gain full", @@ -86,8 +194,8 @@ "title":"Linux Polkit Privilege Escalation Vulnerability (CVE-2021-4034)", "uri":"CVE-2021-4034.html", "doc_type":"usermanual2", - "p_code":"8", - "code":"10" + "p_code":"20", + "code":"22" }, { "desc":"The Linux Kernel SACK vulnerabilities have been fixed. This section describes the solution to these vulnerabilities.On June 18, 2019, Red Hat released a security notice, ", @@ -95,26 +203,98 @@ "title":"Notice on Fixing Linux Kernel SACK Vulnerabilities", "uri":"cce_bulletin_0206.html", "doc_type":"usermanual2", - "p_code":"8", - "code":"11" + "p_code":"20", + "code":"23" }, { - "desc":"In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no lo", + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "product_code":"cce", - "title":"Service Account Token Security Improvement", - "uri":"cce_10_0477.html", - "doc_type":"usermanual2", - "p_code":"3", - "code":"12" - }, - { - "desc":"CCE works closely with multiple cloud services to support computing, storage, networking, and monitoring functions. When you log in to the CCE console for the first time,", - "product_code":"cce", - "title":"Obtaining Resource Permissions", - "uri":"cce_01_9994.html", + "title":"Getting Started", + "uri":"cce_qs_0000.html", "doc_type":"usermanual2", "p_code":"", - "code":"13" + "code":"24" + }, + { + "desc":"This section describes how to use Cloud Container Engine (CCE) and provides frequently asked questions (FAQs) to help you quickly get started with CCE.Complete the follow", + "product_code":"cce", + "title":"Introduction", + "uri":"cce_qs_0001.html", + "doc_type":"usermanual2", + "p_code":"24", + "code":"25" + }, + { + "desc":"Before using CCE, you need to make the following preparations:Creating an IAM userObtaining Resource Permissions(Optional) Creating a VPC(Optional) Creating a Key PairIf ", + "product_code":"cce", + "title":"Preparations", + "uri":"cce_qs_0006.html", + "doc_type":"usermanual2", + "p_code":"24", + "code":"26" + }, + { + "desc":"This section describes how to quickly create a CCE cluster. In this example, the default or simple configurations are in use.If you have not created a cluster, a wizard p", + "product_code":"cce", + "title":"Creating a Kubernetes Cluster", + "uri":"cce_qs_0008.html", + "doc_type":"usermanual2", + "p_code":"24", + "code":"27" + }, + { + "desc":"You can use images to quickly create a single-pod workload that can be accessed from public networks. This section describes how to use CCE to quickly deploy an Nginx app", + "product_code":"cce", + "title":"Creating a Deployment (Nginx) from an Image", + "uri":"cce_qs_0003.html", + "doc_type":"usermanual2", + "p_code":"24", + "code":"28" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Deploying WordPress and MySQL That Depend on Each Other", + "uri":"cce_qs_0007.html", + "doc_type":"usermanual2", + "p_code":"24", + "code":"29" + }, + { + "desc":"WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any ser", + "product_code":"cce", + "title":"Overview", + "uri":"cce_qs_0009.html", + "doc_type":"usermanual2", + "p_code":"29", + "code":"30" + }, + { + "desc":"WordPress must be used together with MySQL. WordPress runs the content management program while MySQL serves as a database to store data.The WordPress and MySQL images ha", + "product_code":"cce", + "title":"Step 1: Create a MySQL Workload", + "uri":"cce_qs_0004.html", + "doc_type":"usermanual2", + "p_code":"29", + "code":"31" + }, + { + "desc":"WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any ser", + "product_code":"cce", + "title":"Step 2: Create a WordPress Workload", + "uri":"cce_qs_0005.html", + "doc_type":"usermanual2", + "p_code":"29", + "code":"32" + }, + { + "desc":"During service deployment or running, you may trigger high-risk operations at different levels, causing service faults or interruption. To help you better estimate and av", + "product_code":"cce", + "title":"High-Risk Operations and Solutions", + "uri":"cce_10_0054.html", + "doc_type":"usermanual2", + "p_code":"", + "code":"33" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -123,7 +303,7 @@ "uri":"cce_10_0091.html", "doc_type":"usermanual2", "p_code":"", - "code":"14" + "code":"34" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -131,17 +311,17 @@ "title":"Cluster Overview", "uri":"cce_10_0002.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"15" + "p_code":"34", + "code":"35" }, { - "desc":"Kubernetes allows you to easily deploy and manage containerized application and facilitates container scheduling and orchestration.For developers, Kubernetes is a cluster", + "desc":"Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications.For developers, Kubernetes is", "product_code":"cce", "title":"Basic Cluster Information", "uri":"cce_10_0430.html", "doc_type":"usermanual2", - "p_code":"15", - "code":"16" + "p_code":"35", + "code":"36" }, { "desc":"The following table lists the differences between CCE Turbo clusters and CCE clusters:The QingTian architecture consists of data plane (software-hardware synergy) and man", @@ -149,8 +329,8 @@ "title":"CCE Turbo Clusters and CCE Clusters", "uri":"cce_10_0342.html", "doc_type":"usermanual2", - "p_code":"15", - "code":"17" + "p_code":"35", + "code":"37" }, { "desc":"kube-proxy is a key component of a Kubernetes cluster. It is responsible for load balancing and forwarding between a Service and its backend pod.CCE supports two forwardi", @@ -158,8 +338,8 @@ "title":"Comparing iptables and IPVS", "uri":"cce_10_0349.html", "doc_type":"usermanual2", - "p_code":"15", - "code":"18" + "p_code":"35", + "code":"38" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -167,8 +347,8 @@ "title":"Release Notes", "uri":"cce_10_0068.html", "doc_type":"usermanual2", - "p_code":"15", - "code":"19" + "p_code":"35", + "code":"39" }, { "desc":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.25.Kubernetes 1", @@ -176,8 +356,8 @@ "title":"CCE Kubernetes 1.25 Release Notes", "uri":"cce_10_0467.html", "doc_type":"usermanual2", - "p_code":"19", - "code":"20" + "p_code":"39", + "code":"40" }, { "desc":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.23.Changes in C", @@ -185,8 +365,8 @@ "title":"CCE Kubernetes 1.23 Release Notes", "uri":"cce_10_0468.html", "doc_type":"usermanual2", - "p_code":"19", - "code":"21" + "p_code":"39", + "code":"41" }, { "desc":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.21.Kubernetes 1", @@ -194,8 +374,8 @@ "title":"CCE Kubernetes 1.21 Release Notes", "uri":"cce_10_0469.html", "doc_type":"usermanual2", - "p_code":"19", - "code":"22" + "p_code":"39", + "code":"42" }, { "desc":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.19.Kubernetes 1", @@ -203,8 +383,8 @@ "title":"CCE Kubernetes 1.19 Release Notes", "uri":"cce_10_0470.html", "doc_type":"usermanual2", - "p_code":"19", - "code":"23" + "p_code":"39", + "code":"43" }, { "desc":"CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.17.All resource", @@ -212,8 +392,8 @@ "title":"CCE Kubernetes 1.17 Release Notes", "uri":"cce_10_0471.html", "doc_type":"usermanual2", - "p_code":"19", - "code":"24" + "p_code":"39", + "code":"44" }, { "desc":"CCE Turbo clusters run on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, and inte", @@ -221,8 +401,8 @@ "title":"Creating a CCE Turbo Cluster", "uri":"cce_10_0298.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"25" + "p_code":"34", + "code":"45" }, { "desc":"On the CCE console, you can easily create Kubernetes clusters. Kubernetes can manage container clusters at scale. A cluster manages a group of node resources.In CCE, you ", @@ -230,8 +410,8 @@ "title":"Creating a CCE Cluster", "uri":"cce_10_0028.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"26" + "p_code":"34", + "code":"46" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -239,8 +419,8 @@ "title":"Using kubectl to Run a Cluster", "uri":"cce_10_0140.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"27" + "p_code":"34", + "code":"47" }, { "desc":"This section uses a CCE cluster as an example to describe how to connect to a CCE cluster using kubectl.When you access a cluster using kubectl, CCE uses thekubeconfig.js", @@ -248,8 +428,8 @@ "title":"Connecting to a Cluster Using kubectl", "uri":"cce_10_0107.html", "doc_type":"usermanual2", - "p_code":"27", - "code":"28" + "p_code":"47", + "code":"48" }, { "desc":"A Subject Alternative Name (SAN) can be signed in to a cluster server certificate. A SAN is usually used by the client to verify the server validity in TLS handshakes. Sp", @@ -257,8 +437,8 @@ "title":"Customizing a Cluster Certificate SAN", "uri":"cce_10_0367.html", "doc_type":"usermanual2", - "p_code":"27", - "code":"29" + "p_code":"47", + "code":"49" }, { "desc":"getThe get command displays one or many resources of a cluster.This command prints a table of the most important information about all resources, including cluster nodes,", @@ -266,8 +446,8 @@ "title":"Common kubectl Commands", "uri":"cce_10_0139.html", "doc_type":"usermanual2", - "p_code":"27", - "code":"30" + "p_code":"47", + "code":"50" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -275,8 +455,8 @@ "title":"Upgrading a Cluster", "uri":"cce_10_0215.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"31" + "p_code":"34", + "code":"51" }, { "desc":"To enable interoperability from one Kubernetes installation to the next, you must upgrade your Kubernetes clusters before the maintenance period ends.After the latest Kub", @@ -284,8 +464,8 @@ "title":"Upgrade Overview", "uri":"cce_10_0197.html", "doc_type":"usermanual2", - "p_code":"31", - "code":"32" + "p_code":"51", + "code":"52" }, { "desc":"Before the upgrade, you can check whether your cluster can be upgraded and which versions are available on the CCE console. For details, see Upgrade Overview.Upgraded clu", @@ -293,8 +473,80 @@ "title":"Before You Start", "uri":"cce_10_0302.html", "doc_type":"usermanual2", - "p_code":"31", - "code":"33" + "p_code":"51", + "code":"53" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Post-Upgrade Verification", + "uri":"cce_10_0560.html", + "doc_type":"usermanual2", + "p_code":"51", + "code":"54" + }, + { + "desc":"After the cluster is upgraded, check whether the services are running normal.Different services have different verification mode. Select a suitable one and verify the ser", + "product_code":"cce", + "title":"Service Verification", + "uri":"cce_10_0561.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"55" + }, + { + "desc":"Check whether unexpected pods exist in the cluster.Check whether there are pods restart unexpectedly in the cluster.Go to the CCE console and access the cluster console. ", + "product_code":"cce", + "title":"Pod Check", + "uri":"cce_10_0562.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"56" + }, + { + "desc":"Check whether the nodes are running properly.Check whether the node network is normal.Check whether the container network is normal.The node status reflects whether the n", + "product_code":"cce", + "title":"Node and Container Network Check", + "uri":"cce_10_0563.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"57" + }, + { + "desc":"Check whether the label is lost.Check whether there are unexpected taints.Go to the CCE console, access the cluster console, and choose Nodes in the navigation pane. On t", + "product_code":"cce", + "title":"Node Label and Taint Check", + "uri":"cce_10_0564.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"58" + }, + { + "desc":"Check whether nodes can be created in the cluster.Go to the CCE console and access the cluster console. Choose Nodes in the navigation pane, and click Create Node.If node", + "product_code":"cce", + "title":"New Node Check", + "uri":"cce_10_0565.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"59" + }, + { + "desc":"Check whether pods can be created on the existing nodes after the cluster is upgraded.Check whether pods can be created on new nodes after the cluster is upgraded.After c", + "product_code":"cce", + "title":"New Pod Check", + "uri":"cce_10_0566.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"60" + }, + { + "desc":"After the cluster is upgraded, you need to reset the nodes that fail to be upgraded.Go back to the previous step or view the upgrade details on the upgrade history page t", + "product_code":"cce", + "title":"Node Skipping Check for Reset", + "uri":"cce_10_0567.html", + "doc_type":"usermanual2", + "p_code":"54", + "code":"61" }, { "desc":"You can upgrade your clusters to a newer Kubernetes version on the CCE console.Before the upgrade, learn about the target version to which each CCE cluster can be upgrade", @@ -302,8 +554,8 @@ "title":"Performing Replace/Rolling Upgrade", "uri":"cce_10_0120.html", "doc_type":"usermanual2", - "p_code":"31", - "code":"34" + "p_code":"51", + "code":"62" }, { "desc":"You can upgrade your clusters to a newer version on the CCE console.Before the upgrade, learn about the target version to which each CCE cluster can be upgraded in what w", @@ -311,8 +563,8 @@ "title":"Performing In-place Upgrade", "uri":"cce_10_0301.html", "doc_type":"usermanual2", - "p_code":"31", - "code":"35" + "p_code":"51", + "code":"63" }, { "desc":"This section describes how to migrate services from a cluster of an earlier version to a cluster of a later version in CCE.This operation is applicable when a cross-versi", @@ -320,8 +572,395 @@ "title":"Migrating Services Across Clusters of Different Versions", "uri":"cce_10_0210.html", "doc_type":"usermanual2", - "p_code":"31", - "code":"36" + "p_code":"51", + "code":"64" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Troubleshooting for Pre-upgrade Check Exceptions", + "uri":"cce_10_0550.html", + "doc_type":"usermanual2", + "p_code":"51", + "code":"65" + }, + { + "desc":"The system performs a comprehensive pre-upgrade check before the cluster upgrade. If the cluster does not meet the pre-upgrade check conditions, the upgrade cannot contin", + "product_code":"cce", + "title":"Performing Pre-upgrade Check", + "uri":"cce_10_0549.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"66" + }, + { + "desc":"Check the following aspects:Check whether the node is available.Check whether the node OS supports the upgrade.Check whether there are unexpected node pool tags in the no", + "product_code":"cce", + "title":"Checking the Node", + "uri":"cce_10_0431.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"67" + }, + { + "desc":"Check whether the current user is in the upgrade blocklist.CCE temporarily disables the cluster upgrade function due to the following reasons:The cluster is identified as", + "product_code":"cce", + "title":"Checking the Blocklist", + "uri":"cce_10_0432.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"68" + }, + { + "desc":"Check the following aspects:Check whether the add-on status is normal.Check whether the add-on supports the target version.Scenario 1: The add-on status is abnormal.Log i", + "product_code":"cce", + "title":"Checking the Add-on", + "uri":"cce_10_0433.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"69" + }, + { + "desc":"Check whether the current HelmRelease record contains discarded Kubernetes APIs that are not supported by the target cluster version. If yes, the Helm chart may be unavai", + "product_code":"cce", + "title":"Checking the Helm Chart", + "uri":"cce_10_0434.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"70" + }, + { + "desc":"Check whether CCE can connect to your master nodes.Contact technical support.", + "product_code":"cce", + "title":"Checking the Master Node SSH Connectivity", + "uri":"cce_10_0435.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"71" + }, + { + "desc":"Check the following aspects:Check the node status.Check whether the auto scaling function of the node pool is disabled.Scenario 1: The node pool status is abnormal.Log in", + "product_code":"cce", + "title":"Checking the Node Pool", + "uri":"cce_10_0436.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"72" + }, + { + "desc":"Check whether the security group allows the master node to access nodes using ICMP.Log in to the VPC console, choose Access Control > Security Groups, and enter the targe", + "product_code":"cce", + "title":"Checking the Security Group", + "uri":"cce_10_0437.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"73" + }, + { + "desc":"Check whether the node needs to be migrated.For the 1.15 cluster that is upgraded from 1.13 in rolling mode, you need to migrate (reset or create and replace) all nodes b", + "product_code":"cce", + "title":"To-Be-Migrated Node", + "uri":"cce_10_0439.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"74" + }, + { + "desc":"Check whether there are discarded resources in the clusters.Scenario 1: The PodSecurityPolicy resource object has been discarded since clusters of v1.25.Run the kubectl g", + "product_code":"cce", + "title":"Discarded Kubernetes Resource", + "uri":"cce_10_0440.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"75" + }, + { + "desc":"Read the version compatibility differences and ensure that they are not affected.The patch upgrade does not involve version compatibility differences.", + "product_code":"cce", + "title":"Compatibility Risk", + "uri":"cce_10_0441.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"76" + }, + { + "desc":"Check whether cce-agent on the current node is of the latest version.If cce-agent is not of the latest version, the automatic update fails. This problem is usually caused", + "product_code":"cce", + "title":"Node CCEAgent Version", + "uri":"cce_10_0442.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"77" + }, + { + "desc":"Check whether the CPU usage of the node exceeds 90%.Upgrade the cluster during off-peak hours.Check whether too many pods are deployed on the node. If yes, reschedule pod", + "product_code":"cce", + "title":"Node CPU Usage", + "uri":"cce_10_0443.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"78" + }, + { + "desc":"Check the following aspects:Check whether the key CRD packageversions.version.cce.io of the cluster is deleted.Check whether the cluster key CRD network-attachment-defini", + "product_code":"cce", + "title":"CRD Check", + "uri":"cce_10_0444.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"79" + }, + { + "desc":"Check the following aspects:Check whether the key data disks on the node meet the upgrade requirements.Check whether the /tmp directory has 500 MB available space.During ", + "product_code":"cce", + "title":"Node Disk", + "uri":"cce_10_0445.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"80" + }, + { + "desc":"Check the following aspects:Check whether the DNS configuration of the current node can resolve the OBS address.Check whether the current node can access the OBS address ", + "product_code":"cce", + "title":"Node DNS", + "uri":"cce_10_0446.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"81" + }, + { + "desc":"Check whether the key directory /var/paas on the nodes contain files with abnormal owners or owner groups.CCE uses the /var/paas directory to manage nodes and store file ", + "product_code":"cce", + "title":"Node Key Directory File Permissions", + "uri":"cce_10_0447.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"82" + }, + { + "desc":"Check whether the kubelet on the node is running properly.Scenario 1: The kubelet status is abnormal.If the kubelet is abnormal, the node is unavailable. Restore the node", + "product_code":"cce", + "title":"Kubelet", + "uri":"cce_10_0448.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"83" + }, + { + "desc":"Check whether the memory usage of the node exceeds 90%.Upgrade the cluster during off-peak hours.Check whether too many pods are deployed on the node. If yes, reschedule ", + "product_code":"cce", + "title":"Node Memory", + "uri":"cce_10_0449.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"84" + }, + { + "desc":"Check whether the clock synchronization server ntpd or chronyd of the node is running properly.Scenario 1: ntpd is running abnormally.Log in to the node and run the syste", + "product_code":"cce", + "title":"Node Clock Synchronization Server", + "uri":"cce_10_0450.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"85" + }, + { + "desc":"Check whether the OS kernel version of the node is supported by CCE.Running nodes depend on the initial standard kernel version when they are created. CCE has performed c", + "product_code":"cce", + "title":"Node OS", + "uri":"cce_10_0451.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"86" + }, + { + "desc":"Check whether the number of CPUs on the master node is greater than 2.If the number of CPUs on the master node is 2, contact technical support to expand the number to 4 o", + "product_code":"cce", + "title":"Node CPU Count", + "uri":"cce_10_0452.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"87" + }, + { + "desc":"Check whether the Python commands are available on a node.If the command output is not 0, the check fails.Install Python before the upgrade.", + "product_code":"cce", + "title":"Node Python Command", + "uri":"cce_10_0453.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"88" + }, + { + "desc":"Check whether the nodes in the cluster are ready.Scenario 1: The nodes are in the unavailable status.Log in to the CCE console and access the cluster console. Choose Node", + "product_code":"cce", + "title":"Node Readiness", + "uri":"cce_10_0455.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"89" + }, + { + "desc":"Check whether journald of a node is normal.Log in to the node and run the systemctl is-active systemd-journald command to query the running status of journald. If the com", + "product_code":"cce", + "title":"Node journald", + "uri":"cce_10_0456.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"90" + }, + { + "desc":"Check whether the containerd.sock file exists on the node. This file affects the startup of container runtime in the Euler OS.Scenario: The Docker used by the node is the", + "product_code":"cce", + "title":"containerd.sock Check", + "uri":"cce_10_0457.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"91" + }, + { + "desc":"Before the upgrade, check whether an internal error occurs.If this check fails, contact technical support.", + "product_code":"cce", + "title":"Internal Error", + "uri":"cce_10_0458.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"92" + }, + { + "desc":"Check whether inaccessible mount points exist on the node.Scenario: There are inaccessible mount points on the node.If network NFS (such as OBS, SFS, and SFS) is used by ", + "product_code":"cce", + "title":"Node Mount Point", + "uri":"cce_10_0459.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"93" + }, + { + "desc":"Check whether the taint, as shown in Table 1, exists on the node.Taint checklistNameImpactnode.kubernetes.io/upgradeNoScheduleScenario 1: The node is skipped during the c", + "product_code":"cce", + "title":"Kubernetes Node Taint", + "uri":"cce_10_0460.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"94" + }, + { + "desc":"Check whether the current everest add-on has compatibility restrictions. See Table 1.The current everest add-on has compatibility restrictions and cannot be upgraded with", + "product_code":"cce", + "title":"everest Restriction Check", + "uri":"cce_10_0478.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"95" + }, + { + "desc":"Check whether the current cce-controller-hpa add-on has compatibility restrictions.The current cce-controller-hpa add-on has compatibility restrictions. An add-on that ca", + "product_code":"cce", + "title":"cce-hpa-controller Restriction Check", + "uri":"cce_10_0479.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"96" + }, + { + "desc":"Check whether the current cluster version and the target version support enhanced CPU policy.Scenario: The current cluster version uses the enhanced CPU management policy", + "product_code":"cce", + "title":"Enhanced CPU Management Policy", + "uri":"cce_10_0480.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"97" + }, + { + "desc":"Check whether the container runtime and network components on the user node are healthy.If a component is abnormal, log in to the node to check the status of the abnormal", + "product_code":"cce", + "title":"User Node Components Health", + "uri":"cce_10_0484.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"98" + }, + { + "desc":"Check whether the Kubernetes, container runtime, and network components of the controller node are healthy.If a component on the controller node is abnormal, contact tech", + "product_code":"cce", + "title":"Controller Node Components Health", + "uri":"cce_10_0485.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"99" + }, + { + "desc":"Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit.Solution 1: Reducing Kubernetes resourcesSolution 2", + "product_code":"cce", + "title":"Memory Resource Limit of Kubernetes Components", + "uri":"cce_10_0486.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"100" + }, + { + "desc":"The system scans the audit logs of the past day to check whether the user calls the deprecated APIs of the target Kubernetes version.Due to the limited time range of audi", + "product_code":"cce", + "title":"Checking Deprecated Kubernetes APIs", + "uri":"cce_10_0487.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"101" + }, + { + "desc":"If IPv6 is enabled for a CCE Turbo cluster, check whether the target cluster version supports IPv6.CCE Turbo clusters support IPv6 since v1.23. This feature is available ", + "product_code":"cce", + "title":"IPv6 Capability of a CCE Turbo Cluster", + "uri":"cce_10_0488.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"102" + }, + { + "desc":"Check whether NetworkManager of a node is normal.Log in to the node and run the systemctl is-active NetworkManager command to query the running status of NetworkManager. ", + "product_code":"cce", + "title":"Node NetworkManager", + "uri":"cce_10_0489.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"103" + }, + { + "desc":"Check the ID file format.", + "product_code":"cce", + "title":"Node ID File", + "uri":"cce_10_0490.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"104" + }, + { + "desc":"When you upgrade a CCE cluster to v1.19 or later, the system checks whether the following configuration files have been modified in the background:/opt/cloud/cce/kubernet", + "product_code":"cce", + "title":"Node Configuration Consistency", + "uri":"cce_10_0491.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"105" + }, + { + "desc":"Check whether the configuration files of key components exist on the node.The following table lists the files to be checked.Contact technical support to restore the confi", + "product_code":"cce", + "title":"Node Configuration File", + "uri":"cce_10_0492.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"106" + }, + { + "desc":"Check whether the current CoreDNS key configuration Corefile is different from the Helm Release record. The difference may be overwritten during the add-on upgrade, affec", + "product_code":"cce", + "title":"Checking CoreDNS Configuration Consistency", + "uri":"cce_10_0493.html", + "doc_type":"usermanual2", + "p_code":"65", + "code":"107" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -329,17 +968,17 @@ "title":"Managing a Cluster", "uri":"cce_10_0031.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"37" + "p_code":"34", + "code":"108" }, { "desc":"CCE allows you to manage cluster parameters, through which you can let core components work under your very requirements.This function is supported only in clusters of v1", "product_code":"cce", - "title":"Managing Cluster Components", + "title":"Cluster Configuration Management", "uri":"cce_10_0213.html", "doc_type":"usermanual2", - "p_code":"37", - "code":"38" + "p_code":"108", + "code":"109" }, { "desc":"This section describes how to delete a cluster.Deleting a cluster will delete the nodes in the cluster (excluding accepted nodes), data disks attached to the nodes, workl", @@ -347,8 +986,8 @@ "title":"Deleting a Cluster", "uri":"cce_10_0212.html", "doc_type":"usermanual2", - "p_code":"37", - "code":"39" + "p_code":"108", + "code":"110" }, { "desc":"If you do not need to use a cluster temporarily, you are advised to hibernate the cluster.After a cluster is hibernated, resources such as workloads cannot be created or ", @@ -356,8 +995,8 @@ "title":"Hibernating and Waking Up a Cluster", "uri":"cce_10_0214.html", "doc_type":"usermanual2", - "p_code":"37", - "code":"40" + "p_code":"108", + "code":"111" }, { "desc":"If overload control is enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available.The c", @@ -365,8 +1004,8 @@ "title":"Cluster Overload Control", "uri":"cce_10_0602.html", "doc_type":"usermanual2", - "p_code":"37", - "code":"41" + "p_code":"108", + "code":"112" }, { "desc":"This section describes how to obtain the cluster certificate from the console and use it to access Kubernetes clusters.The downloaded certificate contains three files: cl", @@ -374,8 +1013,8 @@ "title":"Obtaining a Cluster Certificate", "uri":"cce_10_0175.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"42" + "p_code":"34", + "code":"113" }, { "desc":"CCE allows you to change the number of nodes managed in a cluster.This function is supported for clusters of v1.15 and later versions.Starting from v1.15.11, the number o", @@ -383,8 +1022,8 @@ "title":"Changing Cluster Scale", "uri":"cce_10_0403.html", "doc_type":"usermanual2", - "p_code":"14", - "code":"43" + "p_code":"34", + "code":"114" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -393,7 +1032,7 @@ "uri":"cce_10_0183.html", "doc_type":"usermanual2", "p_code":"", - "code":"44" + "code":"115" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -401,8 +1040,8 @@ "title":"Node Overview", "uri":"cce_10_0180.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"45" + "p_code":"115", + "code":"116" }, { "desc":"A container cluster consists of a set of worker machines, called nodes, that run containerized applications. A node can be a virtual machine (VM) or a physical machine (P", @@ -410,8 +1049,8 @@ "title":"Precautions for Using a Node", "uri":"cce_10_0461.html", "doc_type":"usermanual2", - "p_code":"45", - "code":"46" + "p_code":"116", + "code":"117" }, { "desc":"Container engines, one of the most important components of Kubernetes, manage the lifecycle of images and containers. The kubelet interacts with a container runtime throu", @@ -419,8 +1058,8 @@ "title":"Container Engine", "uri":"cce_10_0462.html", "doc_type":"usermanual2", - "p_code":"45", - "code":"47" + "p_code":"116", + "code":"118" }, { "desc":"The most significant difference is that each Kata container (pod) runs on an independent micro-VM, has an independent OS kernel, and is securely isolated at the virtualiz", @@ -428,8 +1067,8 @@ "title":"Kata Containers and Common Containers", "uri":"cce_10_0463.html", "doc_type":"usermanual2", - "p_code":"45", - "code":"48" + "p_code":"116", + "code":"119" }, { "desc":"The maximum number of pods that can be created on a node is determined by the following parameters:Number of container IP addresses that can be allocated on a node (alpha", @@ -437,8 +1076,8 @@ "title":"Maximum Number of Pods That Can Be Created on a Node", "uri":"cce_10_0348.html", "doc_type":"usermanual2", - "p_code":"45", - "code":"49" + "p_code":"116", + "code":"120" }, { "desc":"Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total num", @@ -446,8 +1085,8 @@ "title":"Formula for Calculating the Reserved Resources of a Node", "uri":"cce_10_0178.html", "doc_type":"usermanual2", - "p_code":"45", - "code":"50" + "p_code":"116", + "code":"121" }, { "desc":"This section describes how to allocate data disk space.When creating a node, you need to configure a data disk whose capacity is greater than or equal to 100GB for the no", @@ -455,8 +1094,8 @@ "title":"Data Disk Space Allocation", "uri":"cce_10_0341.html", "doc_type":"usermanual2", - "p_code":"45", - "code":"51" + "p_code":"116", + "code":"122" }, { "desc":"At least one cluster has been created.A key pair has been created for identity authentication upon remote node login.The node has 2-core or higher CPU, 4 GB or larger mem", @@ -464,8 +1103,8 @@ "title":"Creating a Node", "uri":"cce_10_0363.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"52" + "p_code":"115", + "code":"123" }, { "desc":"In CCE, you can Creating a Node or add existing nodes (ECSs) into your cluster.While an ECS is being accepted into a cluster, the operating system of the ECS will be rese", @@ -473,8 +1112,8 @@ "title":"Adding Nodes for Management", "uri":"cce_10_0198.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"53" + "p_code":"115", + "code":"124" }, { "desc":"Removing a node from a cluster will re-install the node OS and clear CCE components on the node.Removing a node will not delete the server corresponding to the node. You ", @@ -482,8 +1121,8 @@ "title":"Removing a Node", "uri":"cce_10_0338.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"54" + "p_code":"115", + "code":"125" }, { "desc":"You can reset a node to modify the node configuration, such as the node OS and login mode.Resetting a node will reinstall the node OS and the Kubernetes software on the n", @@ -491,8 +1130,8 @@ "title":"Resetting a Node", "uri":"cce_10_0003.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"55" + "p_code":"115", + "code":"126" }, { "desc":"If you use SSH to log in to a node (an ECS), ensure that the ECS already has an EIP (a public IP address).Only login to a running ECS is allowed.Only the user linux can l", @@ -500,8 +1139,8 @@ "title":"Logging In to a Node", "uri":"cce_10_0185.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"56" + "p_code":"115", + "code":"127" }, { "desc":"You can add different labels to nodes and define different attributes for labels. By using these node labels, you can quickly understand the characteristics of each node.", @@ -509,8 +1148,8 @@ "title":"Managing Node Labels", "uri":"cce_10_0004.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"57" + "p_code":"115", + "code":"128" }, { "desc":"Taints enable a node to repel specific pods to prevent these pods from being scheduled to the node.A taint is a key-value pair associated with an effect. The following ef", @@ -518,8 +1157,8 @@ "title":"Managing Node Taints", "uri":"cce_10_0352.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"58" + "p_code":"115", + "code":"129" }, { "desc":"Each node in a cluster is a cloud server or physical machine. After a cluster node is created, you can change the cloud server name or specifications as required.Some inf", @@ -527,17 +1166,17 @@ "title":"Synchronizing Data with Cloud Servers", "uri":"cce_10_0184.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"59" + "p_code":"115", + "code":"130" }, { - "desc":"When a node in a CCE cluster is deleted, services running on the node will also be deleted. Exercise caution when performing this operation.After a CCE cluster is deleted", + "desc":"When a node in a CCE cluster is deleted, services running on the node will also be deleted. Exercise caution when performing this operation.VM nodes that are being used b", "product_code":"cce", "title":"Deleting a Node", "uri":"cce_10_0186.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"60" + "p_code":"115", + "code":"131" }, { "desc":"After a node in the cluster is stopped, services on the node are also stopped. Before stopping a node, ensure that discontinuity of the services on the node will not resu", @@ -545,8 +1184,8 @@ "title":"Stopping a Node", "uri":"cce_10_0036.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"61" + "p_code":"115", + "code":"132" }, { "desc":"In a rolling upgrade, a new node is created, existing workloads are migrated to the new node, and then the old node is deleted. Figure 1 shows the migration process.The o", @@ -554,8 +1193,8 @@ "title":"Performing Rolling Upgrade for Nodes", "uri":"cce_10_0276.html", "doc_type":"usermanual2", - "p_code":"44", - "code":"62" + "p_code":"115", + "code":"133" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -564,7 +1203,7 @@ "uri":"cce_10_0035.html", "doc_type":"usermanual2", "p_code":"", - "code":"63" + "code":"134" }, { "desc":"CCE introduces node pools to help you better manage nodes in Kubernetes clusters. A node pool contains one node or a group of nodes with identical configuration in a clus", @@ -572,8 +1211,8 @@ "title":"Node Pool Overview", "uri":"cce_10_0081.html", "doc_type":"usermanual2", - "p_code":"63", - "code":"64" + "p_code":"134", + "code":"135" }, { "desc":"This section describes how to create a node pool and perform operations on the node pool. For details about how a node pool works, see Node Pool Overview.The autoscaler a", @@ -581,17 +1220,80 @@ "title":"Creating a Node Pool", "uri":"cce_10_0012.html", "doc_type":"usermanual2", - "p_code":"63", - "code":"65" + "p_code":"134", + "code":"136" }, { - "desc":"The default node pool DefaultPool does not support the following management operations.CCE allows you to highly customize Kubernetes parameter settings on core components", + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", "product_code":"cce", "title":"Managing a Node Pool", "uri":"cce_10_0222.html", "doc_type":"usermanual2", - "p_code":"63", - "code":"66" + "p_code":"134", + "code":"137" + }, + { + "desc":"The default node pool DefaultPool does not support the following management operations.CCE allows you to highly customize Kubernetes parameter settings on core components", + "product_code":"cce", + "title":"Configuring a Node Pool", + "uri":"cce_10_0652.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"138" + }, + { + "desc":"When editing the resource tags of the node pool. The modified configuration takes effect only for new nodes. To synchronize the configuration to the existing nodes, you n", + "product_code":"cce", + "title":"Updating a Node Pool", + "uri":"cce_10_0653.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"139" + }, + { + "desc":"After the configuration of a node pool is updated, some configurations cannot be automatically synchronized for existing nodes. You can manually synchronize configuration", + "product_code":"cce", + "title":"Synchronizing Node Pools", + "uri":"cce_10_0654.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"140" + }, + { + "desc":"When CCE releases a new OS image, existing nodes cannot be automatically upgraded. You can manually upgrade them in batches.This operation will upgrade the OS by resettin", + "product_code":"cce", + "title":"Upgrading the OS", + "uri":"cce_10_0660.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"141" + }, + { + "desc":"You can copy the configuration of an existing node pool to create a new node pool on the CCE console.", + "product_code":"cce", + "title":"Copying a Node Pool", + "uri":"cce_10_0655.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"142" + }, + { + "desc":"Nodes in a node pool can be migrated. Currently, nodes in a node pool can be migrated only to the default node pool (defaultpool) in the same cluster.The migration has no", + "product_code":"cce", + "title":"Migrating a Node", + "uri":"cce_10_0656.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"143" + }, + { + "desc":"Deleting a node pool will delete nodes in the pool. Pods on these nodes will be automatically migrated to available nodes in other node pools.Deleting a node pool will de", + "product_code":"cce", + "title":"Deleting a Node Pool", + "uri":"cce_10_0657.html", + "doc_type":"usermanual2", + "p_code":"137", + "code":"144" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -600,7 +1302,7 @@ "uri":"cce_10_0046.html", "doc_type":"usermanual2", "p_code":"", - "code":"67" + "code":"145" }, { "desc":"A workload is an application running on Kubernetes. No matter how many components are there in your workload, you can run it in a group of Kubernetes pods. A workload is ", @@ -608,8 +1310,8 @@ "title":"Overview", "uri":"cce_10_0006.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"68" + "p_code":"145", + "code":"146" }, { "desc":"Deployments are workloads (for example, Nginx) that do not store any data or status. You can create Deployments on the CCE console or by running kubectl commands.Before c", @@ -617,8 +1319,8 @@ "title":"Creating a Deployment", "uri":"cce_10_0047.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"69" + "p_code":"145", + "code":"147" }, { "desc":"StatefulSets are a type of workloads whose data or status is stored while they are running. For example, MySQL is a StatefulSet because it needs to store new data.A conta", @@ -626,8 +1328,8 @@ "title":"Creating a StatefulSet", "uri":"cce_10_0048.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"70" + "p_code":"145", + "code":"148" }, { "desc":"CCE provides deployment and management capabilities for multiple types of containers and supports features of container workloads, including creation, configuration, moni", @@ -635,8 +1337,8 @@ "title":"Creating a DaemonSet", "uri":"cce_10_0216.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"71" + "p_code":"145", + "code":"149" }, { "desc":"Jobs are short-lived and run for a certain time to completion. They can be executed immediately after being deployed. It is completed after it exits normally (exit 0).A j", @@ -644,8 +1346,8 @@ "title":"Creating a Job", "uri":"cce_10_0150.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"72" + "p_code":"145", + "code":"150" }, { "desc":"A cron job runs on a repeating schedule. You can perform time synchronization for all active nodes at a fixed time point.A cron job runs periodically at the specified tim", @@ -653,8 +1355,8 @@ "title":"Creating a Cron Job", "uri":"cce_10_0151.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"73" + "p_code":"145", + "code":"151" }, { "desc":"After a workload is created, you can upgrade, monitor, roll back, or delete the workload, as well as edit its YAML file.Workload/Job managementOperationDescriptionMonitor", @@ -662,8 +1364,8 @@ "title":"Managing Workloads and Jobs", "uri":"cce_10_0007.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"74" + "p_code":"145", + "code":"152" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -671,8 +1373,8 @@ "title":"Configuring a Container", "uri":"cce_10_0130.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"75" + "p_code":"145", + "code":"153" }, { "desc":"A workload is an abstract model of a group of pods. One pod can encapsulate one or more containers. You can click Add Container in the upper right corner to add multiple ", @@ -680,8 +1382,8 @@ "title":"Setting Basic Container Information", "uri":"cce_10_0396.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"76" + "p_code":"153", + "code":"154" }, { "desc":"CCE allows you to create workloads using images pulled from third-party image repositories.Generally, a third-party image repository can be accessed only after authentica", @@ -689,8 +1391,8 @@ "title":"Using a Third-Party Image", "uri":"cce_10_0009.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"77" + "p_code":"153", + "code":"155" }, { "desc":"CCE allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in a workload.", @@ -698,8 +1400,8 @@ "title":"Setting Container Specifications", "uri":"cce_10_0163.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"78" + "p_code":"153", + "code":"156" }, { "desc":"CCE provides callback functions for the lifecycle management of containerized applications. For example, if you want a container to perform a certain operation before sto", @@ -707,8 +1409,8 @@ "title":"Setting Container Lifecycle Parameters", "uri":"cce_10_0105.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"79" + "p_code":"153", + "code":"157" }, { "desc":"Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application ex", @@ -716,8 +1418,8 @@ "title":"Setting Health Check for a Container", "uri":"cce_10_0112.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"80" + "p_code":"153", + "code":"158" }, { "desc":"An environment variable is a variable whose value can affect the way a running container will behave. You can modify environment variables even after workloads are deploy", @@ -725,8 +1427,8 @@ "title":"Setting an Environment Variable", "uri":"cce_10_0113.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"81" + "p_code":"153", + "code":"159" }, { "desc":"When a workload is created, the container image is pulled from the image repository to the node. The image is also pulled when the workload is restarted or upgraded.By de", @@ -734,8 +1436,8 @@ "title":"Configuring an Image Pull Policy", "uri":"cce_10_0353.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"82" + "p_code":"153", + "code":"160" }, { "desc":"When creating a workload, you can configure containers to use the same time zone as the node. You can enable time zone synchronization when creating a workload.The time z", @@ -743,8 +1445,8 @@ "title":"Configuring Time Zone Synchronization", "uri":"cce_10_0354.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"83" + "p_code":"153", + "code":"161" }, { "desc":"In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.You can set different upgrade polici", @@ -752,8 +1454,8 @@ "title":"Configuring the Workload Upgrade Policy", "uri":"cce_10_0397.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"84" + "p_code":"153", + "code":"162" }, { "desc":"A nodeSelector provides a very simple way to constrain pods to nodes with particular labels, as mentioned in Creating a DaemonSet. The affinity and anti-affinity feature ", @@ -761,8 +1463,8 @@ "title":"Scheduling Policy (Affinity/Anti-affinity)", "uri":"cce_10_0232.html", "doc_type":"usermanual2", - "p_code":"75", - "code":"85" + "p_code":"153", + "code":"163" }, { "desc":"You can use GPUs in CCE containers.A GPU node has been created. For details, see Creating a Node.The gpu-beta add-on has been installed. During the installation, select t", @@ -770,8 +1472,8 @@ "title":"GPU Scheduling", "uri":"cce_10_0345.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"86" + "p_code":"145", + "code":"164" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -779,8 +1481,8 @@ "title":"CPU Core Binding", "uri":"cce_10_0551.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"87" + "p_code":"145", + "code":"165" }, { "desc":"By default, kubelet uses CFS quotas to enforce pod CPU limits. When the node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether t", @@ -788,8 +1490,17 @@ "title":"Binding CPU Cores", "uri":"cce_10_0351.html", "doc_type":"usermanual2", - "p_code":"87", - "code":"88" + "p_code":"165", + "code":"166" + }, + { + "desc":"If you encounter unexpected problems when using a container, you can log in to the container for debugging.The example output is as follows:NAME ", + "product_code":"cce", + "title":"Accessing a Container", + "uri":"cce_10_00356.html", + "doc_type":"usermanual2", + "p_code":"145", + "code":"167" }, { "desc":"CCE allows you to add annotations to a YAML file to realize some advanced pod functions. The following table describes the annotations you can add.When you create a workl", @@ -797,8 +1508,8 @@ "title":"Pod Labels and Annotations", "uri":"cce_10_0386.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"89" + "p_code":"145", + "code":"168" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -806,8 +1517,8 @@ "title":"Volcano Scheduling", "uri":"cce_10_0423.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"90" + "p_code":"145", + "code":"169" }, { "desc":"Jobs can be classified into online jobs and offline jobs based on whether services are always online.Online job: Such jobs run for a long time, with regular traffic surge", @@ -815,8 +1526,8 @@ "title":"Hybrid Deployment of Online and Offline Jobs", "uri":"cce_10_0384.html", "doc_type":"usermanual2", - "p_code":"90", - "code":"91" + "p_code":"169", + "code":"170" }, { "desc":"When the Cloud Native Network 2.0 model is used, pods use VPC ENIs or sub-ENIs for networking. You can directly bind security groups and EIPs to pods. CCE provides a cust", @@ -824,8 +1535,8 @@ "title":"Security Group Policies", "uri":"cce_10_0288.html", "doc_type":"usermanual2", - "p_code":"67", - "code":"92" + "p_code":"145", + "code":"171" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -834,7 +1545,7 @@ "uri":"cce_10_0020.html", "doc_type":"usermanual2", "p_code":"", - "code":"93" + "code":"172" }, { "desc":"You can learn about a cluster network from the following two aspects:What is a cluster network like? A cluster consists of multiple nodes, and pods (or containers) are ru", @@ -842,8 +1553,8 @@ "title":"Overview", "uri":"cce_10_0010.html", "doc_type":"usermanual2", - "p_code":"93", - "code":"94" + "p_code":"172", + "code":"173" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -851,17 +1562,17 @@ "title":"Container Network Models", "uri":"cce_10_0280.html", "doc_type":"usermanual2", - "p_code":"93", - "code":"95" + "p_code":"172", + "code":"174" }, { - "desc":"The container network assigns IP addresses to pods in a cluster and provides networking services. In CCE, you can select the following network models for your cluster:Tun", + "desc":"The container network assigns IP addresses to pods in a cluster and provides networking services. In CCE, you can select the following network models for your cluster:Con", "product_code":"cce", "title":"Overview", "uri":"cce_10_0281.html", "doc_type":"usermanual2", - "p_code":"95", - "code":"96" + "p_code":"174", + "code":"175" }, { "desc":"The container tunnel network is constructed on but independent of the node network through tunnel encapsulation. This network model uses VXLAN to encapsulate Ethernet pac", @@ -869,8 +1580,8 @@ "title":"Container Tunnel Network", "uri":"cce_10_0282.html", "doc_type":"usermanual2", - "p_code":"95", - "code":"97" + "p_code":"174", + "code":"176" }, { "desc":"The VPC network uses VPC routing to integrate with the underlying network. This network model is suitable for performance-intensive scenarios. The maximum number of nodes", @@ -878,8 +1589,8 @@ "title":"VPC Network", "uri":"cce_10_0283.html", "doc_type":"usermanual2", - "p_code":"95", - "code":"98" + "p_code":"174", + "code":"177" }, { "desc":"Developed by CCE, Cloud Native Network 2.0 deeply integrates Elastic Network Interfaces (ENIs) and sub-ENIs of Virtual Private Cloud (VPC). Container IP addresses are all", @@ -887,8 +1598,8 @@ "title":"Cloud Native Network 2.0", "uri":"cce_10_0284.html", "doc_type":"usermanual2", - "p_code":"95", - "code":"99" + "p_code":"174", + "code":"178" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -896,8 +1607,8 @@ "title":"Services", "uri":"cce_10_0247.html", "doc_type":"usermanual2", - "p_code":"93", - "code":"100" + "p_code":"172", + "code":"179" }, { "desc":"After a pod is created, the following problems may occur if you directly access the pod:The pod can be deleted and recreated at any time by a controller such as a Deploym", @@ -905,8 +1616,8 @@ "title":"Service Overview", "uri":"cce_10_0249.html", "doc_type":"usermanual2", - "p_code":"100", - "code":"101" + "p_code":"179", + "code":"180" }, { "desc":"ClusterIP Services allow workloads in the same cluster to use their cluster-internal domain names to access each other.The cluster-internal domain name format is Deployments or StatefulSets in the navigation pane ", @@ -1994,8 +2714,8 @@ "title":"Fault Locating and Troubleshooting for Abnormal Workloads", "uri":"cce_faq_00134.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"222" + "p_code":"301", + "code":"302" }, { "desc":"Viewing K8s Event InformationCheck Item 1: Checking Whether a Node Is Available in the ClusterCheck Item 2: Checking Whether Node Resources (CPU and Memory) Are Sufficien", @@ -2003,8 +2723,8 @@ "title":"Failed to Schedule an Instance", "uri":"cce_faq_00098.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"223" + "p_code":"301", + "code":"303" }, { "desc":"If the workload details page displays an event indicating that image pulling fails, perform the following operations to locate the fault:Check Item 1: Checking Whether im", @@ -2012,8 +2732,8 @@ "title":"Failed to Pull an Image", "uri":"cce_faq_00015.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"224" + "p_code":"301", + "code":"304" }, { "desc":"On the details page of a workload, if an event is displayed indicating that the container fails to be restarted, perform the following operations to locate the fault:Rect", @@ -2021,8 +2741,8 @@ "title":"Failed to Restart a Container", "uri":"cce_faq_00018.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"225" + "p_code":"301", + "code":"305" }, { "desc":"Pod actions are classified into the following two types:kube-controller-manager periodically checks the status of all nodes. If a node is in the NotReady state for a peri", @@ -2030,8 +2750,8 @@ "title":"What Should I Do If An Evicted Pod Exists?", "uri":"cce_faq_00209.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"226" + "p_code":"301", + "code":"306" }, { "desc":"When a node is faulty, pods on the node are evicted to ensure workload availability. If the pods are not evicted when the node is faulty, perform the following steps:Use ", @@ -2039,8 +2759,8 @@ "title":"Instance Eviction Exception", "uri":"cce_faq_00140.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"227" + "p_code":"301", + "code":"307" }, { "desc":"When a node is in the Unavailable state, CCE migrates container pods on the node and sets the pods running on the node to the Terminating state.After the node is restored", @@ -2048,8 +2768,8 @@ "title":"What Should I Do If Pods in the Terminating State Cannot Be Deleted?", "uri":"cce_faq_00210.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"228" + "p_code":"301", + "code":"308" }, { "desc":"The metadata.enable field in the YAML file of the workload is false. As a result, the pod of the workload is deleted and the workload is in the stopped status.The workloa", @@ -2057,8 +2777,8 @@ "title":"What Should I Do If a Workload Is Stopped Caused by Pod Deletion?", "uri":"cce_faq_00012.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"229" + "p_code":"301", + "code":"309" }, { "desc":"The pod remains in the creating state for a long time, and the sandbox-related errors are reported.Select a troubleshooting method for your cluster:Clusters of V1.13 or l", @@ -2066,8 +2786,8 @@ "title":"What Should I Do If Sandbox-Related Errors Are Reported When the Pod Remains in the Creating State?", "uri":"cce_faq_00005.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"230" + "p_code":"301", + "code":"310" }, { "desc":"Workload pods in the cluster fail and are being redeployed constantly.After the following command is run, the command output shows that many pods are in the evicted state", @@ -2075,8 +2795,8 @@ "title":"What Should I Do If a Pod Is in the Evicted State?", "uri":"cce_faq_00199.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"231" + "p_code":"301", + "code":"311" }, { "desc":"If a node has sufficient memory resources, a container on this node can use more memory resources than requested, but no more than limited. If the memory allocated to a c", @@ -2084,8 +2804,8 @@ "title":"What Should I Do If the OOM Killer Is Triggered When a Container Uses Memory Resources More Than Limited?", "uri":"cce_faq_00002.html", "doc_type":"usermanual2", - "p_code":"221", - "code":"232" + "p_code":"301", + "code":"312" }, { "desc":"A workload can be accessed from public networks through a load balancer. LoadBalancer provides higher reliability than EIP-based NodePort because an EIP is no longer boun", @@ -2093,8 +2813,8 @@ "title":"What Should I Do If a Service Released in a Workload Cannot Be Accessed from Public Networks?", "uri":"cce_faq_00202.html", "doc_type":"usermanual2", - "p_code":"212", - "code":"233" + "p_code":"292", + "code":"313" }, { "desc":"A VPC is similar to a private local area network (LAN) managed by a home gateway whose IP address is 192.168.0.0/16. A VPC is a private network built on the cloud and pro", @@ -2102,8 +2822,8 @@ "title":"What Is the Relationship Between Clusters, VPCs, and Subnets?", "uri":"cce_faq_00266.html", "doc_type":"usermanual2", - "p_code":"212", - "code":"234" + "p_code":"292", + "code":"314" }, { "desc":"CCE is a universal container platform. Its default security group rules apply to common scenarios. Based on security requirements, you can harden the security group rules", @@ -2111,8 +2831,8 @@ "title":"How Do I Harden the VPC Security Group Rules for CCE Cluster Nodes?", "uri":"cce_faq_00265.html", "doc_type":"usermanual2", - "p_code":"212", - "code":"235" + "p_code":"292", + "code":"315" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2121,7 +2841,7 @@ "uri":"cce_bestpractice.html", "doc_type":"usermanual2", "p_code":"", - "code":"236" + "code":"316" }, { "desc":"Security, efficiency, stability, and availability are common requirements on all cloud services. To meet these requirements, the system availability, data reliability, an", @@ -2129,8 +2849,116 @@ "title":"Checklist for Deploying Containerized Applications in the Cloud", "uri":"cce_bestpractice_00006.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"237" + "p_code":"316", + "code":"317" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Containerization", + "uri":"cce_bestpractice_0321.html", + "doc_type":"usermanual2", + "p_code":"316", + "code":"318" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Containerizing an Enterprise Application (ERP)", + "uri":"cce_bestpractice_0001.html", + "doc_type":"usermanual2", + "p_code":"318", + "code":"319" + }, + { + "desc":"This chapter provides CCE best practices to walk you through the application containerization.A container is a lightweight high-performance resource isolation mechanism i", + "product_code":"cce", + "title":"Solution Overview", + "uri":"cce_bestpractice_0002.html", + "doc_type":"usermanual2", + "p_code":"319", + "code":"320" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Procedure", + "uri":"cce_bestpractice_0340.html", + "doc_type":"usermanual2", + "p_code":"319", + "code":"321" + }, + { + "desc":"This tutorial describes how to containerize an ERP system by migrating it from a VM to CCE.No recoding or re-architecting is required. You only need to pack the entire ap", + "product_code":"cce", + "title":"Containerizing an Entire Application", + "uri":"cce_bestpractice_0003.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"322" + }, + { + "desc":"The following figure illustrates the process of containerizing an application.", + "product_code":"cce", + "title":"Containerization Process", + "uri":"cce_bestpractice_0004.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"323" + }, + { + "desc":"Before containerizing an application, you need to analyze the running environment and dependencies of the application, and get familiar with the application deployment mo", + "product_code":"cce", + "title":"Analyzing the Application", + "uri":"cce_bestpractice_0005.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"324" + }, + { + "desc":"After application analysis, you have gained the understanding of the OS and runtime required for running the application. You need to make the following preparations:Inst", + "product_code":"cce", + "title":"Preparing the Application Runtime", + "uri":"cce_bestpractice_0006.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"325" + }, + { + "desc":"During application containerization, you need to prepare a startup script. The method of compiling this script is the same as that of compiling a shell script. The startu", + "product_code":"cce", + "title":"Compiling a Startup Script", + "uri":"cce_bestpractice_0007.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"326" + }, + { + "desc":"An image is the basis of a container. A container runs based on the content defined in the image. An image has multiple layers. Each layer includes the modifications made", + "product_code":"cce", + "title":"Compiling the Dockerfile", + "uri":"cce_bestpractice_0008.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"327" + }, + { + "desc":"This section describes how to build an entire application into a Docker image. After building an image, you can use the image to deploy and upgrade the application. This ", + "product_code":"cce", + "title":"Building and Uploading an Image", + "uri":"cce_bestpractice_0009.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"328" + }, + { + "desc":"This section describes how to deploy a workload on CCE. When using CCE for the first time, create an initial cluster and add a node into the cluster.Containerized workloa", + "product_code":"cce", + "title":"Creating a Container Workload", + "uri":"cce_bestpractice_0010.html", + "doc_type":"usermanual2", + "p_code":"321", + "code":"329" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2138,8 +2966,8 @@ "title":"Migration", "uri":"cce_bestpractice_00237.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"238" + "p_code":"316", + "code":"330" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2147,8 +2975,8 @@ "title":"Migrating On-premises Kubernetes Clusters to CCE", "uri":"cce_bestpractice_0306.html", "doc_type":"usermanual2", - "p_code":"238", - "code":"239" + "p_code":"330", + "code":"331" }, { "desc":"Containers are growing in popularity and Kubernetes simplifies containerized deployment. Many companies choose to build their own Kubernetes clusters. However, the O&M wo", @@ -2156,8 +2984,8 @@ "title":"Solution Overview", "uri":"cce_bestpractice_0307.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"240" + "p_code":"331", + "code":"332" }, { "desc":"CCE allows you to customize cluster resources to meet various service requirements. Table 1 lists the key performance parameters of a cluster and provides the planned val", @@ -2165,8 +2993,8 @@ "title":"Planning Resources for the Target Cluster", "uri":"cce_bestpractice_0308.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"241" + "p_code":"331", + "code":"333" }, { "desc":"If your migration does not involve resources outside a cluster listed in Table 1 or you do not need to use other services to update resources after the migration, skip th", @@ -2174,8 +3002,8 @@ "title":"Migrating Resources Outside a Cluster", "uri":"cce_bestpractice_0309.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"242" + "p_code":"331", + "code":"334" }, { "desc":"Velero is an open-source backup and migration tool for Kubernetes clusters. It integrates the persistent volume (PV) data backup capability of the Restic tool and can be ", @@ -2183,8 +3011,8 @@ "title":"Installing the Migration Tool", "uri":"cce_bestpractice_0310.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"243" + "p_code":"331", + "code":"335" }, { "desc":"WordPress is used as an example to describe how to migrate an application from an on-premises Kubernetes cluster to a CCE cluster. The WordPress application consists of t", @@ -2192,8 +3020,8 @@ "title":"Migrating Resources in a Cluster", "uri":"cce_bestpractice_0311.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"244" + "p_code":"331", + "code":"336" }, { "desc":"The WordPress and MySQL images used in this example can be pulled from SWR. Therefore, the image pull failure (ErrImagePull) will not occur. If the application to be migr", @@ -2201,8 +3029,8 @@ "title":"Updating Resources Accordingly", "uri":"cce_bestpractice_0312.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"245" + "p_code":"331", + "code":"337" }, { "desc":"Cluster migration involves full migration of application data, which may cause intra-application adaptation problems. In this example, after the cluster is migrated, the ", @@ -2210,8 +3038,8 @@ "title":"Performing Additional Tasks", "uri":"cce_bestpractice_0313.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"246" + "p_code":"331", + "code":"338" }, { "desc":"Both HostPath and Local volumes are local storage volumes. However, the Restic tool integrated in Velero cannot back up the PVs of the HostPath type and supports only the", @@ -2219,8 +3047,8 @@ "title":"Troubleshooting", "uri":"cce_bestpractice_0314.html", "doc_type":"usermanual2", - "p_code":"239", - "code":"247" + "p_code":"331", + "code":"339" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2228,8 +3056,8 @@ "title":"DevOps", "uri":"cce_bestpractice_0322.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"248" + "p_code":"316", + "code":"340" }, { "desc":"GitLab is an open-source version management system developed with Ruby on Rails for Git project repository management. It supports web-based access to public and private ", @@ -2237,8 +3065,8 @@ "title":"Interconnecting GitLab with SWR and CCE for CI/CD", "uri":"cce_bestpractice_0324.html", "doc_type":"usermanual2", - "p_code":"248", - "code":"249" + "p_code":"340", + "code":"341" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2246,8 +3074,8 @@ "title":"Disaster Recovery", "uri":"cce_bestpractice_0323.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"250" + "p_code":"316", + "code":"342" }, { "desc":"To achieve high availability for your CCE containers, you can do as follows:Deploy three master nodes for the cluster.When nodes are deployed across AZs, set custom sched", @@ -2255,8 +3083,8 @@ "title":"Implementing High Availability for Containers in CCE", "uri":"cce_bestpractice_00220.html", "doc_type":"usermanual2", - "p_code":"250", - "code":"251" + "p_code":"342", + "code":"343" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2264,8 +3092,8 @@ "title":"Security", "uri":"cce_bestpractice_0315.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"252" + "p_code":"316", + "code":"344" }, { "desc":"For security purposes, you are advised to configure a cluster as follows.Kubernetes releases a major version in about four months. CCE follows the same frequency as Kuber", @@ -2273,8 +3101,8 @@ "title":"Cluster Security", "uri":"cce_bestpractice_0317.html", "doc_type":"usermanual2", - "p_code":"252", - "code":"253" + "p_code":"344", + "code":"345" }, { "desc":"Do not bind an EIP to a node unless necessary to reduce the attack surface.If an EIP must be used, properly configure the firewall or security group rules to restrict acc", @@ -2282,8 +3110,8 @@ "title":"Node Security", "uri":"cce_bestpractice_0318.html", "doc_type":"usermanual2", - "p_code":"252", - "code":"254" + "p_code":"344", + "code":"346" }, { "desc":"The nodeSelector or nodeAffinity is used to limit the range of nodes to which applications can be scheduled, preventing the entire cluster from being threatened due to th", @@ -2291,8 +3119,8 @@ "title":"Container Security", "uri":"cce_bestpractice_0319.html", "doc_type":"usermanual2", - "p_code":"252", - "code":"255" + "p_code":"344", + "code":"347" }, { "desc":"Currently, CCE has configured static encryption for secret resources. The secrets created by users will be encrypted and stored in etcd of the CCE cluster. Secrets can be", @@ -2300,8 +3128,8 @@ "title":"Secret Security", "uri":"cce_bestpractice_0320.html", "doc_type":"usermanual2", - "p_code":"252", - "code":"256" + "p_code":"344", + "code":"348" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2309,8 +3137,8 @@ "title":"Auto Scaling", "uri":"cce_bestpractice_0090.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"257" + "p_code":"316", + "code":"349" }, { "desc":"The best way to handle surging traffic is to automatically adjust the number of machines based on the traffic volume or resource usage, which is called scaling.In CCE, th", @@ -2318,8 +3146,26 @@ "title":"Using HPA and CA for Auto Scaling of Workloads and Nodes", "uri":"cce_bestpractice_00282.html", "doc_type":"usermanual2", - "p_code":"257", - "code":"258" + "p_code":"349", + "code":"350" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Monitoring", + "uri":"cce_bestpractice_10008.html", + "doc_type":"usermanual2", + "p_code":"316", + "code":"351" + }, + { + "desc":"Generally, a user has different clusters for different purposes, such as production, testing, and development. To monitor, collect, and view metrics of these clusters, yo", + "product_code":"cce", + "title":"Using Prometheus for Multi-cluster Monitoring", + "uri":"cce_bestpractice_10009.html", + "doc_type":"usermanual2", + "p_code":"351", + "code":"352" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2327,8 +3173,8 @@ "title":"Cluster", "uri":"cce_bestpractice_0050.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"259" + "p_code":"316", + "code":"353" }, { "desc":"When you have multiple CCE clusters, you may find it difficult to efficiently connect to all of them.This section describes how to configure access to multiple clusters b", @@ -2336,8 +3182,8 @@ "title":"Connecting to Multiple Clusters Using kubectl", "uri":"cce_bestpractice_00254.html", "doc_type":"usermanual2", - "p_code":"259", - "code":"260" + "p_code":"353", + "code":"354" }, { "desc":"You can use the pre-installation script feature to configure CCE cluster nodes (ECSs).When creating a node in a cluster of v1.13.10 or later, if a data disk is not manage", @@ -2345,8 +3191,17 @@ "title":"Adding a Second Data Disk to a Node in a CCE Cluster", "uri":"cce_bestpractice_00190.html", "doc_type":"usermanual2", - "p_code":"259", - "code":"261" + "p_code":"353", + "code":"355" + }, + { + "desc":"When a node is created, a data disk is created by default for container runtime and kubelet components to use. The data disk used by the container runtime and kubelet co", + "product_code":"cce", + "title":"Selecting a Data Disk for the Node", + "uri":"cce_bestpractice_10012.html", + "doc_type":"usermanual2", + "p_code":"353", + "code":"356" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2354,8 +3209,8 @@ "title":"Networking", "uri":"cce_bestpractice_0052.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"262" + "p_code":"316", + "code":"357" }, { "desc":"Before creating a cluster on CCE, determine the number of VPCs, number of subnets, container CIDR blocks, and Services for access based on service requirements.This topic", @@ -2363,17 +3218,17 @@ "title":"Planning CIDR Blocks for a Cluster", "uri":"cce_bestpractice_00004.html", "doc_type":"usermanual2", - "p_code":"262", - "code":"263" + "p_code":"357", + "code":"358" }, { - "desc":"CCE uses self-proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models.After a cluster i", + "desc":"CCE uses proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models.After a cluster is cre", "product_code":"cce", "title":"Selecting a Network Model", "uri":"cce_bestpractice_00162.html", "doc_type":"usermanual2", - "p_code":"262", - "code":"264" + "p_code":"357", + "code":"359" }, { "desc":"Session persistence is one of the most common while complex problems in load balancing.Session persistence is also called sticky sessions. After the sticky session functi", @@ -2381,8 +3236,8 @@ "title":"Implementing Sticky Session Through Load Balancing", "uri":"cce_bestpractice_00231.html", "doc_type":"usermanual2", - "p_code":"262", - "code":"265" + "p_code":"357", + "code":"360" }, { "desc":"There may be different types of proxy servers between a client and a container server. How can a container obtain the real source IP address of the client? This section d", @@ -2390,8 +3245,8 @@ "title":"Obtaining the Client Source IP Address for a Container", "uri":"cce_bestpractice_00035.html", "doc_type":"usermanual2", - "p_code":"262", - "code":"266" + "p_code":"357", + "code":"361" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2399,17 +3254,17 @@ "title":"Storage", "uri":"cce_bestpractice_0053.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"267" + "p_code":"316", + "code":"362" }, { - "desc":"A data disk is divided depending on the container storage Rootfs:Overlayfs: No independent thin pool is allocated. Image data is stored in the dockersys disk.# lsblk\nNAME", + "desc":"EulerOS 2.9 is used as the sample OS. Originally, system disk /dev/vda has 50 GB and one partition (/dev/vda1), and then 50 GB is added to the disk. In this example, the ", "product_code":"cce", "title":"Expanding Node Disk Capacity", "uri":"cce_bestpractice_00198.html", "doc_type":"usermanual2", - "p_code":"267", - "code":"268" + "p_code":"362", + "code":"363" }, { "desc":"This section describes how to mount OBS buckets and OBS parallel file systems (preferred) of third-party tenants.The CCE cluster of a SaaS service provider needs to be mo", @@ -2417,17 +3272,17 @@ "title":"Mounting an Object Storage Bucket of a Third-Party Tenant", "uri":"cce_bestpractice_00199.html", "doc_type":"usermanual2", - "p_code":"267", - "code":"269" + "p_code":"362", + "code":"364" }, { "desc":"The minimum capacity of an SFS Turbo file system is 500 GB, and the SFS Turbo file system cannot be billed by usage. By default, the root directory of an SFS Turbo file s", "product_code":"cce", "title":"Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System", - "uri":"cce_bestpractice_00253_0.html", + "uri":"cce_bestpractice_00253.html", "doc_type":"usermanual2", - "p_code":"267", - "code":"270" + "p_code":"362", + "code":"365" }, { "desc":"In clusters later than v1.15.11-r1, CSI (the everest add-on) has taken over all functions of fuxi FlexVolume (the storage-driver add-on) for managing container storage. Y", @@ -2435,17 +3290,17 @@ "title":"How Do I Change the Storage Class Used by a Cluster of v1.15 from FlexVolume to CSI Everest?", "uri":"cce_bestpractice_0107.html", "doc_type":"usermanual2", - "p_code":"267", - "code":"271" + "p_code":"362", + "code":"366" }, { "desc":"When using storage resources in CCE, the most common method is to specify storageClassName to define the type of storage resources to be created when creating a PVC. The ", "product_code":"cce", "title":"Custom Storage Classes", - "uri":"cce_bestpractice_00281_0.html", + "uri":"cce_bestpractice_00281.html", "doc_type":"usermanual2", - "p_code":"267", - "code":"272" + "p_code":"362", + "code":"367" }, { "desc":"EVS disks cannot be attached across AZs. For example, EVS disks in AZ 1 cannot be attached to nodes in AZ 2.If the storage class csi-disk is used for StatefulSets, when a", @@ -2453,8 +3308,8 @@ "title":"Realizing Automatic Topology for EVS Disks When Nodes Are Deployed Across AZs (csi-disk-topology)", "uri":"cce_bestpractice_00284.html", "doc_type":"usermanual2", - "p_code":"267", - "code":"273" + "p_code":"362", + "code":"368" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2462,8 +3317,8 @@ "title":"Container", "uri":"cce_bestpractice_0051.html", "doc_type":"usermanual2", - "p_code":"236", - "code":"274" + "p_code":"316", + "code":"369" }, { "desc":"If a node has sufficient memory resources, a container on this node can use more memory resources than requested, but no more than limited. If the memory allocated to a c", @@ -2471,8 +3326,8 @@ "title":"Properly Allocating Container Computing Resources", "uri":"cce_bestpractice_00002.html", "doc_type":"usermanual2", - "p_code":"274", - "code":"275" + "p_code":"369", + "code":"370" }, { "desc":"To access a Kubernetes cluster from a client, you can use the Kubernetes command line tool kubectl.Create a DaemonSet file.vi daemonSet.yamlAn example YAML file is provid", @@ -2480,8 +3335,8 @@ "title":"Modifying Kernel Parameters Using a Privileged Container", "uri":"cce_bestpractice_00227.html", "doc_type":"usermanual2", - "p_code":"274", - "code":"276" + "p_code":"369", + "code":"371" }, { "desc":"Before containers running applications are started, one or some init containers are started first. If there are multiple init containers, they will be started in the defi", @@ -2489,8 +3344,8 @@ "title":"Initializing a Container", "uri":"cce_bestpractice_00228.html", "doc_type":"usermanual2", - "p_code":"274", - "code":"277" + "p_code":"369", + "code":"372" }, { "desc":"If DNS or other related settings are inappropriate, you can use hostAliases to overwrite the resolution of the host name at the pod level when adding entries to the /etc/", @@ -2498,8 +3353,8 @@ "title":"Using hostAliases to Configure /etc/hosts in a Pod", "uri":"cce_bestpractice_00226.html", "doc_type":"usermanual2", - "p_code":"274", - "code":"278" + "p_code":"369", + "code":"373" }, { "desc":"Linux allows you to create a core dump file if an application crashes, which contains the data the application had in memory at the time of the crash. You can analyze the", @@ -2507,8 +3362,53 @@ "title":"Configuring Core Dumps", "uri":"cce_bestpractice_0325.html", "doc_type":"usermanual2", - "p_code":"274", - "code":"279" + "p_code":"369", + "code":"374" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Permission", + "uri":"cce_bestpractice_0055.html", + "doc_type":"usermanual2", + "p_code":"316", + "code":"375" + }, + { + "desc":"By default, the kubeconfig file provided by CCE for users has permissions bound to the cluster-admin role, which are equivalent to the permissions of user root. It is dif", + "product_code":"cce", + "title":"Configuring kubeconfig for Fine-Grained Management on Cluster Resources", + "uri":"cce_bestpractice_00221.html", + "doc_type":"usermanual2", + "p_code":"375", + "code":"376" + }, + { + "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", + "product_code":"cce", + "title":"Release", + "uri":"cce_bestpractice_10000.html", + "doc_type":"usermanual2", + "p_code":"316", + "code":"377" + }, + { + "desc":"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 a", + "product_code":"cce", + "title":"Overview", + "uri":"cce_bestpractice_10001.html", + "doc_type":"usermanual2", + "p_code":"377", + "code":"378" + }, + { + "desc":"To implement grayscale release for a CCE cluster, you need to deploy other open-source tools, such as Nginx Ingress, to the cluster or deploy services to a service mesh. ", + "product_code":"cce", + "title":"Using Services to Implement Simple Grayscale Release and Blue-Green Deployment", + "uri":"cce_bestpractice_10002.html", + "doc_type":"usermanual2", + "p_code":"377", + "code":"379" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2517,7 +3417,7 @@ "uri":"cce_01_9999.html", "doc_type":"usermanual2", "p_code":"", - "code":"280" + "code":"380" }, { "desc":"CCE 2.0 inherits and modifies the features of CCE 1.0, and release new features.Modified features:Clusters in CCE 1.0 are equivalent to Hybrid clusters in CCE 2.0.CCE 2.0", @@ -2525,8 +3425,8 @@ "title":"Differences Between CCE 1.0 and CCE 2.0", "uri":"cce_01_9998.html", "doc_type":"usermanual2", - "p_code":"280", - "code":"281" + "p_code":"380", + "code":"381" }, { "desc":"Migrate the images stored in the image repository of CCE 1.0 to CCE 2.0.A VM is available. The VM is bound to a public IP address and can access the Internet. Docker (ear", @@ -2534,8 +3434,8 @@ "title":"Migrating Images", "uri":"cce_01_9997.html", "doc_type":"usermanual2", - "p_code":"280", - "code":"282" + "p_code":"380", + "code":"382" }, { "desc":"Create Hybrid clusters on the CCE 2.0 console. These new Hybrid clusters should have the same specifications with those created on CCE 1.0.To create clusters using APIs, ", @@ -2543,8 +3443,8 @@ "title":"Migrating Clusters", "uri":"cce_01_9996.html", "doc_type":"usermanual2", - "p_code":"280", - "code":"283" + "p_code":"380", + "code":"383" }, { "desc":"This section describes how to create a Deployment with the same specifications as that in CCE 1.0 on the CCE 2.0 console.It is advised to delete the applications on CCE 1", @@ -2552,8 +3452,8 @@ "title":"Migrating Applications", "uri":"cce_01_9995.html", "doc_type":"usermanual2", - "p_code":"280", - "code":"284" + "p_code":"380", + "code":"384" }, { "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.", @@ -2562,6 +3462,6 @@ "uri":"cce_01_0300.html", "doc_type":"usermanual2", "p_code":"", - "code":"285" + "code":"385" } ] \ No newline at end of file diff --git a/docs/cce/umn/cce_01_0091.html b/docs/cce/umn/cce_01_0091.html index 8432c28a..df22ad91 100644 --- a/docs/cce/umn/cce_01_0091.html +++ b/docs/cce/umn/cce_01_0091.html @@ -1,9 +1,16 @@

What Is Cloud Container Engine?

-

Cloud Container Engine (CCE) provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale containerized applications on the cloud.

-

CCE is deeply integrated with the public cloud services, including high-performance computing (ECS), network (VPC, EIP, and ELB), and storage (EVS and SFS) services. It supports heterogeneous computing architectures such as GPU, ARM, and FPGA. By using multi-AZ and multi-region disaster recovery, CCE ensures high availability of Kubernetes clusters.

-

You can use CCE through the console, kubectl, and APIs. Before using the CCE service, learn about the concepts related to Kubernetes. For details, see https://kubernetes.io/docs/concepts/.

-
  • Junior users: You are advised to use the console. The console provides an intuitive interface for you to complete operations such as creating clusters or workloads.
  • Advanced users: If you have experience in using kubectl, you are advised to use the kubectl, and APIs to perform operations. For details, see Kubernetes APIs and kubectl CLI.
+

Why CCE?

CCE is a one-stop platform integrating compute, networking, storage, and many other services. Supporting multi-AZ and multi-region disaster recovery, CCE ensures high availability of Kubernetes clusters.

+

For more information, see Product Advantages and Application Scenarios.

+
+

Accessing CCE

You can use CCE via the CCE console, kubectl, or Kubernetes APIs. Figure 1 shows the process.

+
Figure 1 Accessing CCE
+
+
+
+
+
Parent topic: Service Overview
+
diff --git a/docs/cce/umn/cce_01_0300.html b/docs/cce/umn/cce_01_0300.html index a1798429..4515f98e 100644 --- a/docs/cce/umn/cce_01_0300.html +++ b/docs/cce/umn/cce_01_0300.html @@ -8,7 +8,12 @@ -

2023-02-10

+

2023-05-30

+ + + + +

2023-02-10

diff --git a/docs/cce/umn/cce_01_9994.html b/docs/cce/umn/cce_01_9994.html deleted file mode 100644 index 9ccffed9..00000000 --- a/docs/cce/umn/cce_01_9994.html +++ /dev/null @@ -1,15 +0,0 @@ - - -

Obtaining Resource Permissions

-
CCE works closely with multiple cloud services to support computing, storage, networking, and monitoring functions. When you log in to the CCE console for the first time, CCE automatically requests permissions to access those cloud services in the region where you run your applications. Specifically:
  • Compute services

    When you create a node in a cluster, an ECS is created accordingly. The prerequisite is that CCE have obtained the permissions to access Elastic Cloud Service (ECS).

    -
  • Storage services

    CCE allows you to mount storage to nodes and containers in a cluster. The prerequisite is that CCE have obtained the permissions to access services such as Elastic Volume Service (EVS), Scalable File Service (SFS), and Object Storage Service (OBS).

    -
  • Networking services

    CCE allows containers in a cluster to be published as services that can be accessed by external systems. The prerequisite is that CCE have obtained the permissions to access services such as Virtual Private Cloud (VPC) and Elastic Load Balance (ELB).

    -
  • Container and monitoring services

    CCE supports functions such as container image pulling, monitoring, and logging. The prerequisite is that CCE have obtained the permissions to access services such as SoftWare Repository for Container (SWR) and Application Operations Management (AOM).

    -
-
-

After you agree to delegate the permissions, an agency named cce_admin_trust will be created for CCE in Identity and Access Management (IAM). The system account op_svc_cce will be delegated the Tenant Administrator role to perform operations on other cloud service resources. Tenant Administrator has the permissions on all cloud services except IAM, which calls the cloud services on which CCE depends. The delegation takes effect only in the current region. For details, see Delegating Resource Access to Another Account.

-

To use CCE in multiple regions, you need to request cloud resource permissions in each region. You can go to the IAM console, choose Agencies, and click cce_admin_trust to view the delegation records of each region.

-

CCE may fail to run as expected if the Tenant Administrator role is not assigned. Therefore, do not delete or modify the cce_admin_trust agency when using CCE.

-
-
- diff --git a/docs/cce/umn/cce_01_9996.html b/docs/cce/umn/cce_01_9996.html index 56efdeee..e8d3b66f 100644 --- a/docs/cce/umn/cce_01_9996.html +++ b/docs/cce/umn/cce_01_9996.html @@ -93,7 +93,7 @@

This parameter does not exist in CCE 1.0. Set this parameter based on your requirements.

-

By default, RBAC is selected. Read Namespace Permissions (Kubernetes RBAC-based) and select I am aware of the above limitations and read the CCE Role Management Instructions.

+

By default, RBAC is selected. Read Namespace Permissions (Kubernetes RBAC-based) and select I am aware of the above limitations and read the CCE Role Management Instructions.

After RBAC is enabled, users access resources in the cluster according to fine-grained permissions policies.

@@ -101,7 +101,7 @@

This parameter does not exist in CCE 1.0. Set this parameter based on your requirements.

-

The authentication mechanism performs permission control on resources in a cluster. For example, you can grant user A to read and write applications in a namespace, while granting user B to only read resources in a cluster. For details about role-based permission control, see Controlling Cluster Permissions.

+

The authentication mechanism performs permission control on resources in a cluster. For example, you can grant user A to read and write applications in a namespace, while granting user B to only read resources in a cluster. For details about role-based permission control, see Namespace Permissions (Kubernetes RBAC-based).

  • By default, X.509 authentication instead of Enhanced authentication is enabled. X.509 is a standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols.
  • If permission control on a cluster is required, select Enhanced authentication and then Authenticating Proxy.

    Click Upload next to CA Root Certificate to upload a valid certificate. Select the check box to confirm that the uploaded certificate is valid.

    If the certificate is invalid, the cluster cannot be created. The uploaded certificate file must be smaller than 1 MB and in .crt or .cer format.

@@ -159,7 +159,7 @@

OS

Select an operating system for the node.

-

Reinstalling OSs or modifying OS configurations could make nodes unavailable. Exercise caution when performing these operations. For more information, see Risky Operations on Cluster Nodes.

+

Reinstalling OSs or modifying OS configurations could make nodes unavailable. Exercise caution when performing these operations. For more information, see High-Risk Operations and Solutions.

VPC

@@ -290,7 +290,7 @@

  • Click Next to install add-ons.

    System resource add-ons must be installed. Advanced functional add-ons are optional.

    -

    You can also install optional add-ons after the cluster is created. To do so, choose Add-ons in the navigation pane of the CCE console and select the add-on you will install. For details, see Add-ons.

    +

    You can also install optional add-ons after the cluster is created. To do so, choose Add-ons in the navigation pane of the CCE console and select the add-on you will install. For details, see Add-ons.

  • Click Create Now. Check all the configurations, and click Submit.

    It takes 6 to 10 minutes to create a cluster. Information indicating the progress of the creation process will be displayed.

    • diff --git a/docs/cce/umn/cce_10_0003.html b/docs/cce/umn/cce_10_0003.html index 665f5868..727777ad 100644 --- a/docs/cce/umn/cce_10_0003.html +++ b/docs/cce/umn/cce_10_0003.html @@ -10,34 +10,34 @@

    Procedure

    The new console allows you to reset nodes in batches. You can also use private images to reset nodes in batches.

    1. Log in to the CCE console.
    2. Click the cluster name and access the cluster details page, choose Nodes in the navigation pane, and select one or multiple nodes to be reset in the list on the right. Choose More > Reset.
    3. In the displayed dialog box, click Yes.

      • For nodes in the DefaultPool node pool, the parameter setting page is displayed. Set the parameters by referring to 4.
      • For a node you create in a node pool, resetting the node does not support parameter configuration. You can directly use the configuration image of the node pool to reset the node.
      -

    4. Specify node parameters.

      Compute Settings -
      Table 1 Configuration parameters

      Parameter

      +

    5. Specify node parameters.

      Compute Settings +
      - - - - - - - - - @@ -45,74 +45,74 @@
      Table 1 Configuration parameters

      Parameter

      Description

      +

      Description

      Specification

      +

      Specification

      Node specifications cannot be modified when you reset a node.

      +

      Node specifications cannot be modified when you reset a node.

      Container Engine

      +

      Container Engine

      CCE clusters support Docker.

      -

      For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.

      +
      CCE clusters support Docker and containerd in some scenarios.
      • VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd.
      • For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.
      +

      OS

      +

      OS

      Public image: Select an OS for the node.

      -

      Private image: You can use private images.

      +

      Public image: Select an OS for the node.

      +

      Private image: You can use private images.

      Login Mode

      +

      Login Mode

      • Key Pair

        Select the key pair used to log in to the node. You can select a shared key.

        -

        A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.

        +
      • Key Pair

        Select the key pair used to log in to the node. You can select a shared key.

        +

        A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.
      -

      Storage Settings

      -
      Configure storage resources on a node for the containers running on it. -
      Table 2 Configuration parameters

      Parameter

      +

      Storage Settings

      +
      Configure storage resources on a node for the containers running on it. +
      - - - - -
      Table 2 Configuration parameters

      Parameter

      Description

      +

      Description

      System Disk

      +

      System Disk

      Directly use the system disk of the cloud server.

      +

      Directly use the system disk of the cloud server.

      Data Disk

      +

      Data Disk

      At least one data disk is required for the container runtime and kubelet. The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.

      -

      Click Expand and select Allocate Disk Space to define the disk space occupied by the container runtime to store the working directories, container image data, and image metadata. For details about how to allocate data disk space, see Data Disk Space Allocation.

      -

      For other data disks, a raw disk is created without any processing by default. You can also click Expand and select Mount Disk to mount the data disk to a specified directory.

      +

      At least one data disk is required for the container runtime and kubelet. The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.

      +

      Click Expand and select Allocate Disk Space to define the disk space occupied by the container runtime to store the working directories, container image data, and image metadata. For details about how to allocate data disk space, see Data Disk Space Allocation.

      +

      For other data disks, a raw disk is created without any processing by default. You can also click Expand and select Mount Disk to mount the data disk to a specified directory.

      -
      Advanced Settings -
      Table 3 Advanced configuration parameters

      Parameter

      +
      Advanced Settings +
      - - - - - - - - - - - - - diff --git a/docs/cce/umn/cce_10_0006.html b/docs/cce/umn/cce_10_0006.html index 3e407221..361fba7e 100644 --- a/docs/cce/umn/cce_10_0006.html +++ b/docs/cce/umn/cce_10_0006.html @@ -4,12 +4,12 @@

      CCE provides Kubernetes-native container deployment and management and supports lifecycle management of container workloads, including creation, configuration, monitoring, auto scaling, upgrade, uninstall, service discovery, and load balancing.

      Pod

      A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates one or more containers, storage volumes, a unique network IP address, and options that govern how the containers should run.

      Pods can be used in either of the following ways:

      -
      • A container is running in a pod. This is the most common usage of pods in Kubernetes. You can view the pod as a single encapsulated container, but Kubernetes directly manages pods instead of containers.
      • Multiple containers that need to be coupled and share resources run in a pod. In this scenario, an application contains a main container and several sidecar containers, as shown in Figure 1. For example, the main container is a web server that provides file services from a fixed directory, and a sidecar container periodically downloads files to the directory.
        Figure 1 Pod
        +
        • A container is running in a pod. This is the most common usage of pods in Kubernetes. You can view the pod as a single encapsulated container, but Kubernetes directly manages pods instead of containers.
        • Multiple containers that need to be coupled and share resources run in a pod. In this scenario, an application contains a main container and several sidecar containers, as shown in Figure 1. For example, the main container is a web server that provides file services from a fixed directory, and a sidecar container periodically downloads files to the directory.
          Figure 1 Pod

        In Kubernetes, pods are rarely created directly. Instead, controllers such as Deployments and jobs, are used to manage pods. Controllers can create and manage multiple pods, and provide replica management, rolling upgrade, and self-healing capabilities. A controller generally uses a pod template to create corresponding pods.

      Deployment

      A pod is the smallest and simplest unit that you create or deploy in Kubernetes. It is designed to be an ephemeral, one-off entity. A pod can be evicted when node resources are insufficient and disappears along with a cluster node failure. Kubernetes provides controllers to manage pods. Controllers can create and manage pods, and provide replica management, rolling upgrade, and self-healing capabilities. The most commonly used controller is Deployment.

      -
      Figure 2 Relationship between a Deployment and pods
      +
      Figure 2 Relationship between a Deployment and pods

      A Deployment can contain one or more pods. These pods have the same role. Therefore, the system automatically distributes requests to multiple pods of a Deployment.

      A Deployment integrates a lot of functions, including online deployment, rolling upgrade, replica creation, and restoration of online jobs. To some extent, Deployments can be used to realize unattended rollout, which greatly reduces difficulties and operation risks in the rollout process.

      @@ -18,12 +18,12 @@

      With detailed analysis, it is found that each part of distributed stateful applications plays a different role. For example, the database nodes are deployed in active/standby mode, and pods are dependent on each other. In this case, you need to meet the following requirements for the pods:

      • A pod can be recognized by other pods. Therefore, a pod must have a fixed identifier.
      • Each pod has an independent storage device. After a pod is deleted and then restored, the data read from the pod must be the same as the previous one. Otherwise, the pod status is inconsistent.

      To address the preceding requirements, Kubernetes provides StatefulSets.

      -
      1. A StatefulSet provides a fixed name for each pod following a fixed number ranging from 0 to N. After a pod is rescheduled, the pod name and the host name remain unchanged.
      2. A StatefulSet provides a fixed access domain name for each pod through the headless Service (described in following sections).
      3. The StatefulSet creates PersistentVolumeClaims (PVCs) with fixed identifiers to ensure that pods can access the same persistent data after being rescheduled.

        +
        1. A StatefulSet provides a fixed name for each pod following a fixed number ranging from 0 to N. After a pod is rescheduled, the pod name and the host name remain unchanged.
        2. A StatefulSet provides a fixed access domain name for each pod through the headless Service (described in following sections).
        3. The StatefulSet creates PersistentVolumeClaims (PVCs) with fixed identifiers to ensure that pods can access the same persistent data after being rescheduled.

      DaemonSet

      A DaemonSet runs a pod on each node in a cluster and ensures that there is only one pod. This works well for certain system-level applications, such as log collection and resource monitoring, since they must run on each node and need only a few pods. A good example is kube-proxy.

      DaemonSets are closely related to nodes. If a node becomes faulty, the DaemonSet will not create the same pods on other nodes.

      -
      Figure 3 DaemonSet
      +
      Figure 3 DaemonSet

      Job and Cron Job

      Jobs and cron jobs allow you to run short lived, one-off tasks in batch. They ensure the task pods run to completion.

      • A job is a resource object used by Kubernetes to control batch tasks. Jobs are different from long-term servo tasks (such as Deployments and StatefulSets). The former is started and terminated at specific times, while the latter runs unceasingly unless being terminated. The pods managed by a job will be automatically removed after successfully completing tasks based on user configurations.
      • A cron job runs a job periodically on a specified schedule. A cron job object is similar to a line of a crontab file in Linux.
      diff --git a/docs/cce/umn/cce_10_0007.html b/docs/cce/umn/cce_10_0007.html index 3cc1f063..fe2cd9e6 100644 --- a/docs/cce/umn/cce_10_0007.html +++ b/docs/cce/umn/cce_10_0007.html @@ -1,10 +1,10 @@

      Managing Workloads and Jobs

      -

      Scenario

      After a workload is created, you can upgrade, monitor, roll back, or delete the workload, as well as edit its YAML file. -
      Table 3 Advanced configuration parameters

      Parameter

      Description

      +

      Description

      Kubernetes Label

      +

      Kubernetes Label

      Click Add Label to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.

      -

      Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.

      +

      Click Add to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.

      +

      Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.

      Resource Tag

      +

      Resource Tag

      You can add resource tags to classify resources.

      -

      You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency.

      -

      CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag.

      +

      You can add resource tags to classify resources.

      +

      You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency.

      +

      CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag.

      Taint

      +

      Taint

      This field is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
      • Key: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
      • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
      • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
      -
      NOTICE:
      • If taints are used, you must configure tolerations in the YAML files of pods. Otherwise, scale-up may fail or pods cannot be scheduled onto the added nodes.
      • After a node pool is created, you can click Edit to modify its configuration. The modification will be synchronized to all nodes in the node pool.
      +
      This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
      • Key: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
      • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
      • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
      +
      NOTICE:
      • If taints are used, you must configure tolerations in the YAML files of pods. Otherwise, scale-up may fail or pods cannot be scheduled onto the added nodes.
      • After a node pool is created, you can click Edit to modify its configuration. The modification will be synchronized to all nodes in the node pool.

      Max. Pods

      +

      Max. Pods

      Maximum number of pods that can run on the node, including the default system pods.

      -

      This limit prevents the node from being overloaded with pods.

      +

      Maximum number of pods that can run on the node, including the default system pods.

      +

      This limit prevents the node from being overloaded with pods.

      Pre-installation Command

      +

      Pre-installation Command

      Enter commands. A maximum of 1,000 characters are allowed.

      -

      The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed.

      +

      Enter commands. A maximum of 1,000 characters are allowed.

      +

      The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed.

      Post-installation Command

      +

      Post-installation Command

      Enter commands. A maximum of 1,000 characters are allowed.

      -

      The script will be executed after Kubernetes software is installed and will not affect the installation.

      +

      Enter commands. A maximum of 1,000 characters are allowed.

      +

      The script will be executed after Kubernetes software is installed and will not affect the installation.
      Table 1 Workload/Job management

      Operation

      +

      Scenario

      After a workload is created, you can upgrade, monitor, roll back, or delete the workload, as well as edit its YAML file. +
      - @@ -13,49 +13,49 @@ - - - - - - - - - - - - - - - - - - - - - - @@ -98,32 +100,33 @@

      Storage Settings

      Configure storage resources on a node for the containers running on it. Set the disk size according to site requirements. -
      Table 1 Workload/Job management

      Operation

      Description

      +

      Description

      You can view the CPU and memory usage of workloads and pods on the CCE console.

      View Log

      +

      View Log

      You can view the logs of workloads.

      +

      You can view the logs of workloads.

      Upgrade

      +

      Upgrade

      You can replace images or image tags to quickly upgrade Deployments, StatefulSets, and DaemonSets without interrupting services.

      +

      You can replace images or image tags to quickly upgrade Deployments, StatefulSets, and DaemonSets without interrupting services.

      Edit YAML

      +

      Edit YAML

      You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, and pods on the CCE console. YAML files of jobs and cron jobs can only be viewed, copied, and downloaded.

      +

      You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, and pods on the CCE console. YAML files of jobs and cron jobs can only be viewed, copied, and downloaded.

      Roll Back

      +

      Roll Back

      Only Deployments can be rolled back.

      +

      Only Deployments can be rolled back.

      Redeploy

      +

      Redeploy

      You can redeploy a workload. After the workload is redeployed, all pods in the workload will be restarted.

      +

      You can redeploy a workload. After the workload is redeployed, all pods in the workload will be restarted.

      Enabling/Disabling the Upgrade

      +

      Enabling/Disabling the Upgrade

      Only Deployments support this operation.

      +

      Only Deployments support this operation.

      Manage Label

      +

      Manage Label

      Labels are key-value pairs and can be attached to workloads for affinity and anti-affinity scheduling. Jobs and Cron Jobs do not support this operation.

      +

      Labels are key-value pairs and can be attached to workloads for affinity and anti-affinity scheduling. Jobs and Cron Jobs do not support this operation.

      Delete

      +

      Delete

      You can delete a workload or job that is no longer needed. Deleted workloads or jobs cannot be recovered.

      +

      You can delete a workload or job that is no longer needed. Deleted workloads or jobs cannot be recovered.

      View Events

      +

      View Events

      You can view event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time.

      +

      You can view event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time.

      Stop/Start

      @@ -68,55 +68,55 @@ -

      Monitoring a Workload

      You can view the CPU and memory usage of Deployments and pods on the CCE console to determine the resource specifications you may need. This section uses a Deployment as an example to describe how to monitor a workload.

      -
      1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
      2. Click the Deployments tab and click Monitor of the target workload. On the page that is displayed, you can view CPU usage and memory usage of the workload.
      3. Click the workload name. On the Pods tab page, click the Monitor of the target pod to view its CPU and memory usage.
      +

      Monitoring a Workload

      You can view the CPU and memory usage of Deployments and pods on the CCE console to determine the resource specifications you may need. This section uses a Deployment as an example to describe how to monitor a workload.

      +
      1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
      2. Click the Deployments tab and click Monitor of the target workload. On the page that is displayed, you can view CPU usage and memory usage of the workload.
      3. Click the workload name. On the Pods tab page, click the Monitor of the target pod to view its CPU and memory usage.
      -

      Viewing Logs

      You can view logs of Deployments, StatefulSets, DaemonSets, and jobs. This section uses a Deployment as an example to describe how to view logs.

      -
      1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
      2. Click the Deployments tab and click the View Log of the target workload.

        On the displayed View Log window, you can view logs by time.

        +

        Viewing Logs

        You can view logs of Deployments, StatefulSets, DaemonSets, and jobs. This section uses a Deployment as an example to describe how to view logs.

        +
        1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
        2. Click the Deployments tab and click the View Log of the target workload.

          On the displayed View Log window, you can view logs by time.

        -

        Upgrading a Workload

        You quickly upgrade Deployments, StatefulSets, and DaemonSets on the CCE console.

        -

        This section uses a Deployment as an example to describe how to upgrade a workload.

        -

        Before replacing an image or image version, upload the new image to the SWR service.

        -
        1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
        2. Click the Deployments tab and click Upgrade of the target workload.

          • Workloads cannot be upgraded in batches.
          • Before performing an in-place StatefulSet upgrade, you must manually delete old pods. Otherwise, the upgrade status is always displayed as Upgrading.
          +

          Upgrading a Workload

          You quickly upgrade Deployments, StatefulSets, and DaemonSets on the CCE console.

          +

          This section uses a Deployment as an example to describe how to upgrade a workload.

          +

          Before replacing an image or image version, upload the new image to the SWR service.

          +
          1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab and click Upgrade of the target workload.

            • Workloads cannot be upgraded in batches.
            • Before performing an in-place StatefulSet upgrade, you must manually delete old pods. Otherwise, the upgrade status is always displayed as Upgrading.
            -

          3. Upgrade the workload based on service requirements. The method for setting parameter is the same as that for creating a workload.
          4. After the update is complete, click Upgrade Workload, manually confirm the YAML file, and submit the upgrade.
          +

        3. Upgrade the workload based on service requirements. The method for setting parameter is the same as that for creating a workload.
        4. After the update is complete, click Upgrade Workload, manually confirm the YAML file, and submit the upgrade.
        -

        Editing a YAML file

        You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, and pods on the CCE console. YAML files of jobs and cron jobs can only be viewed, copied, and downloaded. This section uses a Deployment as an example to describe how to edit the YAML file.

        -
        1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
        2. Click the Deployments tab and choose More > Edit YAML in the Operation column of the target workload. In the dialog box that is displayed, modify the YAML file.
        3. Click Edit and then OK to save the changes.
        4. (Optional) In the Edit YAML window, click Download to download the YAML file.
        +

        Editing a YAML file

        You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, and pods on the CCE console. YAML files of jobs and cron jobs can only be viewed, copied, and downloaded. This section uses a Deployment as an example to describe how to edit the YAML file.

        +
        1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
        2. Click the Deployments tab and choose More > Edit YAML in the Operation column of the target workload. In the dialog box that is displayed, modify the YAML file.
        3. Click Edit and then OK to save the changes.
        4. (Optional) In the Edit YAML window, click Download to download the YAML file.
        -

        Rolling Back a Workload (Available Only for Deployments)

        CCE records the release history of all Deployments. You can roll back a Deployment to a specified version.

        -
        1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
        2. Click the Deployments tab, choose More > Roll Back in the Operation column of the target workload.
        3. Switch to the Change History tab page, click Roll Back to This Version of the target version, manually confirm the YAML file, and click OK.

          +

          Rolling Back a Workload (Available Only for Deployments)

          CCE records the release history of all Deployments. You can roll back a Deployment to a specified version.

          +
          1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab, choose More > Roll Back in the Operation column of the target workload.
          3. Switch to the Change History tab page, click Roll Back to This Version of the target version, manually confirm the YAML file, and click OK.

          Redeploying a Workload

          After you redeploy a workload, all pods in the workload will be restarted. This section uses Deployments as an example to illustrate how to redeploy a workload.

          1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab and choose More > Redeploy in the Operation column of the target workload.
          3. In the dialog box that is displayed, click Yes to redeploy the workload.
          -

          Disabling/Enabling Upgrade (Available Only for Deployments)

          Only Deployments support this operation.

          +

          Disabling/Enabling Upgrade (Available Only for Deployments)

          Only Deployments support this operation.

          • After the upgrade is disabled, the upgrade command can be delivered but will not be applied to the pods.

            If you are performing a rolling upgrade, the rolling upgrade stops after the disabling upgrade command is delivered. In this case, the new and old pods co-exist.

          • If a Deployment is being upgraded, it can be upgraded or rolled back. Its pods will inherit the latest updates of the Deployment. If they are inconsistent, the pods are upgraded automatically according to the latest information of the Deployment.
          -

          Deployments in the disable upgrade state cannot be rolled back.

          +

          Deployments in the disable upgrade state cannot be rolled back.

          -
          1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab and choose More > Disable/Enable Upgrade in the Operation column of the workload.
          3. In the dialog box that is displayed, click Yes.
          +
          1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab and choose More > Disable/Enable Upgrade in the Operation column of the workload.
          3. In the dialog box that is displayed, click Yes.
          -

          Managing Labels

          Labels are key-value pairs and can be attached to workloads. Workload labels are often used for affinity and anti-affinity scheduling. You can add labels to multiple workloads or a specified workload.

          -

          You can manage the labels of Deployments, StatefulSets, and DaemonSets based on service requirements. This section uses Deployments as an example to describe how to manage labels.

          -

          In the following figure, three labels (release, env, and role) are defined for workload APP 1, APP 2, and APP 3. The values of these labels vary with workload.

          -
          • Label of APP 1: [release:alpha;env:development;role:frontend]
          • Label of APP 2: [release:beta;env:testing;role:frontend]
          • Label of APP 3: [release:alpha;env:production;role:backend]
          -

          If you set key to role and value to frontend when using workload scheduling or another function, APP 1 and APP 2 will be selected.

          -
          Figure 1 Label example
          -
          1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab and choose More > Manage Label in the Operation column of the target workload.
          3. Click Add, enter a key and a value, and click OK.

            A key-value pair must contain 1 to 63 characters starting and ending with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed.

            +

            Managing Labels

            Labels are key-value pairs and can be attached to workloads. Workload labels are often used for affinity and anti-affinity scheduling. You can add labels to multiple workloads or a specified workload.

            +

            You can manage the labels of Deployments, StatefulSets, and DaemonSets based on service requirements. This section uses Deployments as an example to describe how to manage labels.

            +

            In the following figure, three labels (release, env, and role) are defined for workload APP 1, APP 2, and APP 3. The values of these labels vary with workload.

            +
            • Label of APP 1: [release:alpha;env:development;role:frontend]
            • Label of APP 2: [release:beta;env:testing;role:frontend]
            • Label of APP 3: [release:alpha;env:production;role:backend]
            +

            If you set key to role and value to frontend when using workload scheduling or another function, APP 1 and APP 2 will be selected.

            +
            Figure 1 Label example
            +
            1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
            2. Click the Deployments tab and choose More > Manage Label in the Operation column of the target workload.
            3. Click Add, enter a key and a value, and click OK.

              A key-value pair must contain 1 to 63 characters starting and ending with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed.

            -

            Deleting a Workload/Job

            You can delete a workload or job that is no longer needed. Deleted workloads or jobs cannot be recovered. Exercise caution when you perform this operation. This section uses a Deployment as an example to describe how to delete a workload.

            -
            1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
            2. In the same row as the workload you will delete, choose Operation > More > Delete.

              Read the system prompts carefully. A workload cannot be recovered after it is deleted. Exercise caution when performing this operation.

              -

            3. Click Yes.

              • If the node where the pod is located is unavailable or shut down and the workload cannot be deleted, you can forcibly delete the pod from the pod list on the workload details page.
              • Ensure that the storage volumes to be deleted are not used by other workloads. If these volumes are imported or have snapshots, you can only unbind them.
              +

              Deleting a Workload/Job

              You can delete a workload or job that is no longer needed. Deleted workloads or jobs cannot be recovered. Exercise caution when you perform this operation. This section uses a Deployment as an example to describe how to delete a workload.

              +
              1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
              2. In the same row as the workload you will delete, choose Operation > More > Delete.

                Read the system prompts carefully. A workload cannot be recovered after it is deleted. Exercise caution when performing this operation.

                +

              3. Click Yes.

                • If the node where the pod is located is unavailable or shut down and the workload cannot be deleted, you can forcibly delete the pod from the pod list on the workload details page.
                • Ensure that the storage volumes to be deleted are not used by other workloads. If these volumes are imported or have snapshots, you can only unbind them.

              -

              Viewing Events

              This section uses Deployments as an example to illustrate how to view events of a workload. To view the event of a job or cron jon, click View Event in the Operation column of the target workload.

              -
              1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
              2. On the Deployments tab page, click the target workload. In the Pods tab page, click the View Events to view the event name, event type, number of occurrences, Kubernetes event, first occurrence time, and last occurrence time.

                Event data will be retained for one hour and then automatically deleted.

                +

                Viewing Events

                This section uses Deployments as an example to illustrate how to view events of a workload. To view the event of a job or cron jon, click View Event in the Operation column of the target workload.

                +
                1. Log in to the CCE console, go to an existing cluster, and choose Workloads in the navigation pane.
                2. On the Deployments tab page, click the target workload. In the Pods tab page, click the View Events to view the event name, event type, number of occurrences, Kubernetes event, first occurrence time, and last occurrence time.

                  Event data will be retained for one hour and then automatically deleted.

                diff --git a/docs/cce/umn/cce_10_0010.html b/docs/cce/umn/cce_10_0010.html index 6a672493..4ce43b33 100644 --- a/docs/cce/umn/cce_10_0010.html +++ b/docs/cce/umn/cce_10_0010.html @@ -4,7 +4,7 @@

                You can learn about a cluster network from the following two aspects:

                • What is a cluster network like? A cluster consists of multiple nodes, and pods (or containers) are running on the nodes. Nodes and containers need to communicate with each other. For details about the cluster network types and their functions, see Cluster Network Structure.
                • How is pod access implemented in a cluster? Accessing a pod or container is a process of accessing services of a user. Kubernetes provides Service and Ingress to address pod access issues. This section summarizes common network access scenarios. You can select the proper scenario based on site requirements. For details about the network access scenarios, see Access Scenarios.

                Cluster Network Structure

                All nodes in the cluster are located in a VPC and use the VPC network. The container network is managed by dedicated network add-ons.

                -

                +

                • Node Network

                  A node network assigns IP addresses to hosts (nodes in the figure above) in a cluster. You need to select a VPC subnet as the node network of the CCE cluster. The number of available IP addresses in a subnet determines the maximum number of nodes (including master nodes and worker nodes) that can be created in a cluster. This quantity is also affected by the container network. For details, see the container network model.

                • Container Network

                  A container network assigns IP addresses to containers in a cluster. CCE inherits the IP-Per-Pod-Per-Network network model of Kubernetes. That is, each pod has an independent IP address on a network plane and all containers in a pod share the same network namespace. All pods in a cluster exist in a directly connected flat network. They can access each other through their IP addresses without using NAT. Kubernetes only provides a network mechanism for pods, but does not directly configure pod networks. The configuration of pod networks is implemented by specific container network add-ons. The container network add-ons are responsible for configuring networks for pods and managing container IP addresses.

                  Currently, CCE supports the following container network models:

                  @@ -14,20 +14,20 @@

                Service

                A Service is used for pod access. With a fixed IP address, a Service forwards access traffic to pods and performs load balancing for these pods.

                -
                Figure 1 Accessing pods through a Service
                +
                Figure 1 Accessing pods through a Service

                You can configure the following types of Services:

                • ClusterIP: used to make the Service only reachable from within a cluster.
                • NodePort: used for access from outside a cluster. A NodePort Service is accessed through the port on the node.
                • LoadBalancer: used for access from outside a cluster. It is an extension of NodePort, to which a load balancer routes, and external systems only need to access the load balancer.

                For details about the Service, see Service Overview.

                Ingress

                Services forward requests using layer-4 TCP and UDP protocols. Ingresses forward requests using layer-7 HTTP and HTTPS protocols. Domain names and paths can be used to achieve finer granularities.

                -
                Figure 2 Ingress and Service
                +
                Figure 2 Ingress-Service

                For details about the ingress, see Ingress Overview.

                Access Scenarios

                Workload access scenarios can be categorized as follows:

                -
                • Intra-cluster access: A ClusterIP Service is used for workloads in the same cluster to access each other.
                • Access from outside a cluster: A Service (NodePort or LoadBalancer type) or an ingress is recommended for a workload outside a cluster to access workloads in the cluster.
                  • Access through the internet requires an EIP to be bound the node or load balancer.
                  • Access through an intranet uses only the intranet IP address of the node or load balancer. If workloads are located in different VPCs, a peering connection is required to enable communication between different VPCs.
                  -
                • External access initiated by a workload:
                  • Accessing an intranet: The workload accesses the intranet address, but the implementation method varies depending on container network models. Ensure that the peer security group allows the access requests from the container CIDR block.
                  • Accessing a public network: You need to assign an EIP to the node where the workload runs (when the VPC network or tunnel network model is used), bind an EIP to the pod IP address (when the Cloud Native Network 2.0 model is used), or configure SNAT rules through the NAT gateway. For details, see Accessing Public Networks from a Container.
                  +
                  • Intra-cluster access: A ClusterIP Service is used for workloads in the same cluster to access each other.
                  • Access from outside a cluster: A Service (NodePort or LoadBalancer type) or an ingress is recommended for a workload outside a cluster to access workloads in the cluster.
                    • Access through the internet requires an EIP to be bound the node or load balancer.
                    • Access through the intranet requires an internal IP address to be bound the node or load balancer. If workloads are located in different VPCs, a peering connection is required to enable communication between different VPCs.
                    +
                  • The workload accesses the external network.
                    • Accessing an intranet: The workload accesses the intranet address, but the implementation method varies depending on container network models. Ensure that the peer security group allows the access requests from the container CIDR block.
                    • Accessing a public network: You need to assign an EIP to the node where the workload runs (when the VPC network or tunnel network model is used), bind an EIP to the pod IP address (when the Cloud Native Network 2.0 model is used), or configure SNAT rules through the NAT gateway. For details, see Accessing Public Networks from a Container.
                  -
                  Figure 3 Network access diagram
                  +
                  Figure 3 Network access diagram
                diff --git a/docs/cce/umn/cce_10_0011.html b/docs/cce/umn/cce_10_0011.html index 1a08ed51..e0d5cdb4 100644 --- a/docs/cce/umn/cce_10_0011.html +++ b/docs/cce/umn/cce_10_0011.html @@ -4,7 +4,7 @@

                Scenario

                ClusterIP Services allow workloads in the same cluster to use their cluster-internal domain names to access each other.

                The cluster-internal domain name format is <Service name>.<Namespace of the workload>.svc.cluster.local:<Port>, for example, nginx.default.svc.cluster.local:80.

                Figure 1 shows the mapping relationships between access channels, container ports, and access ports.

                -
                Figure 1 Intra-cluster access (ClusterIP)
                +
                Figure 1 Intra-cluster access (ClusterIP)

                Creating a ClusterIP Service

                1. Log in to the CCE console and access the cluster console.
                2. Choose Networking in the navigation pane and click Create Service in the upper right corner.
                3. Set intra-cluster access parameters.

                  • Service Name: Service name, which can be the same as the workload name.
                  • Service Type: Select ClusterIP.
                  • Namespace: Namespace to which the workload belongs.
                  • Selector: Add a label and click Add. A Service selects a pod based on the added label. You can also click Reference Workload Label to reference the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
                  • Port Settings
                    • Protocol: protocol used by the Service.
                    • Service Port: port used by the Service. The port number ranges from 1 to 65535.
                    • Container Port: port on which the workload listens. For example, Nginx uses port 80 by default.
                  diff --git a/docs/cce/umn/cce_10_0012.html b/docs/cce/umn/cce_10_0012.html index 222dec7e..ace9ae5f 100644 --- a/docs/cce/umn/cce_10_0012.html +++ b/docs/cce/umn/cce_10_0012.html @@ -27,7 +27,7 @@

      By default, auto scaling is disabled.

      Install the autoscaler add-on to enable auto scaling.

      -

      After you enable auto scaling by switching on , nodes in the node pool will be automatically created or deleted based on cluster loads.

      +

      After you enable auto scaling by switching on , nodes in the node pool will be automatically created or deleted based on cluster loads.

      • Maximum Nodes and Minimum Nodes: You can set the maximum and minimum number of nodes to ensure that the number of nodes to be scaled is within a proper range.
      • Priority: Set this parameter based on service requirements. A larger value indicates a higher priority. For example, if this parameter is set to 1 and 4 respectively for node pools A and B, B has a higher priority than A. If the priorities of multiple node pools are set to the same value, for example, 2, the node pools are not prioritized and the system performs scaling based on the minimum resource waste principle.
        NOTE:

        CCE selects a node pool for auto scaling based on the following policies:

        1. CCE uses algorithms to determine whether a node pool meets the conditions to allow scheduling of a pod in pending state, including whether the node resources are greater than requested by the pod, and whether the nodeSelect, nodeAffinity, and taints meet the conditions. In addition, the node pools that fail to be scaled (due to insufficient resources or other reasons) and are still in the 15-minute cool-down interval are filtered.
        2. If multiple node pools meet the scaling requirements, the system checks the priority of each node pool and selects the node pool with the highest priority for scaling. The value ranges from 0 to 100 and the default priority is 0. The value 100 indicates the highest priority, and the value 0 indicates the lowest priority.
        3. If multiple node pools have the same priority or no priority is configured for them, the system selects the node pool that will consume the least resources based on the configured VM specification.
        4. If the VM specifications of multiple node pools are the same but the node pools are deployed in different AZs, the system randomly selects a node pool to trigger scaling.
        @@ -63,19 +63,21 @@

      Node Type

      For a CCE cluster, ECS and BMS are supported.

      -

      CCE Turbo clusters support ECSs of the VM and physical types.

      +
      CCE cluster:
      • ECS (VM): Containers run on ECSs.
      +
      +
      CCE Turbo cluster:
      • ECS (VM): Containers run on ECSs. Only Trunkport ECSs (models that can be bound with multiple elastic network interfaces (ENIs)) are supported.
      +

      Container Engine

      CCE clusters support Docker. Starting from CCE 1.23, containerd is supported.

      -

      For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.

      +
      CCE clusters support Docker and containerd in some scenarios.
      • VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd.
      • For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.
      +

      Specifications

      Select node specifications that best fit your business needs.

      +

      Select a node specification based on service requirements. The available node specifications vary depending on regions or AZs. For details, see the CCE console.

      OS

      @@ -87,8 +89,8 @@

      Login Mode

      • Key Pair

        Select the key pair used to log in to the node. You can select a shared key.

        -

        A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.

        +
      • Key Pair

        Select the key pair used to log in to the node. You can select a shared key.

        +

        A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair..
      Table 3 Configuration parameters

      Parameter

      +
      - - - - - @@ -161,64 +164,64 @@

      Advanced Settings

      Configure advanced node capabilities such as labels, taints, and startup command. -
      Table 3 Parameters for storage settings

      Parameter

      Description

      +

      Description

      System Disk

      +

      System Disk

      System disk used by the node OS. The value ranges from 40 GB to 1,024 GB. The default value is 50 GB.

      -
      Encryption: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
      • Encryption is not selected by default.
      • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.
      +

      System disk used by the node OS. The value ranges from 40 GB to 1,024 GB. The default value is 50 GB.

      +
      Encryption: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
      • Encryption is not selected by default.
      • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.

      Data Disk

      +

      Data Disk

      Data disk used by the container runtime and kubelet on the node.

      -

      At least one data disk is required for the container runtime and kubelet. The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.

      -

      Click Expand to set the following parameters:

      -
      • Allocate Disk Space: Select this option to define the disk space occupied by the container runtime to store the working directories, container image data, and image metadata. For details about how to allocate data disk space, see Data Disk Space Allocation.
      • Encryption: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
        • Encryption is not selected by default.
        • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.
        +

      At least one data disk is required for the container runtime and kubelet. The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.

      +
      • First data disk: used for container runtime and kubelet components. The value ranges from 20 GB to 32,768 GB. The default value is 100 GB.
      • Other data disks: You can set the data disk size to a value ranging from 10 GB to 32,768 GB. The default value is 100 GB.
      +

      Advanced Settings

      +

      Click Expand to set the following parameters:

      +
      • Allocate Disk Space: Select this option to define the disk space occupied by the container runtime to store the working directories, container image data, and image metadata. For details about how to allocate data disk space, see Data Disk Space Allocation.
      • Encryption: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
        • Encryption is not selected by default.
        • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.
      -

      Adding Multiple Data Disks

      -

      A maximum of four data disks can be added. By default, raw disks are created without any processing. You can also click Expand and select any of the following options:

      -
      • Default: By default, a raw disk is created without any processing.
      • Mount Disk: The data disk is attached to a specified directory.
      -

      Local Disk Description

      -

      If the node flavor is disk-intensive or ultra-high I/O, one data disk can be a local disk.

      -

      Local disks may break down and do not ensure data reliability. It is recommended that you store service data in EVS disks, which are more reliable than local disks.

      +

      Adding Multiple Data Disks

      +

      A maximum of four data disks can be added. By default, raw disks are created without any processing. You can also click Expand and select any of the following options:

      +
      • Default: By default, a raw disk is created without any processing.
      • Mount Disk: The data disk is attached to a specified directory.
      +

      Local Disk Description

      +

      If the node flavor is disk-intensive or ultra-high I/O, one data disk can be a local disk.

      +

      Local disks may break down and do not ensure data reliability. It is recommended that you store service data in EVS disks, which are more reliable than local disks.
      Table 5 Advanced configuration parameters

      Parameter

      +
      - - - - - - - - - - - - - - - - - diff --git a/docs/cce/umn/cce_10_0014.html b/docs/cce/umn/cce_10_0014.html index 779f5bb1..3f83ff87 100644 --- a/docs/cce/umn/cce_10_0014.html +++ b/docs/cce/umn/cce_10_0014.html @@ -4,20 +4,20 @@

      Scenario

      A workload can be accessed from public networks through a load balancer, which is more secure and reliable than EIP.

      The LoadBalancer access address is in the format of <IP address of public network load balancer>:<access port>, for example, 10.117.117.117:80.

      In this access mode, requests are transmitted through an ELB load balancer to a node and then forwarded to the destination pod through the Service.

      -
      Figure 1 LoadBalancer
      +
      Figure 1 LoadBalancer

      When CCE Turbo clusters and dedicated load balancers are used, passthrough networking is supported to reduce service latency and ensure zero performance loss.

      External access requests are directly forwarded from a load balancer to pods. Internal access requests can be forwarded to a pod through a Service.

      -
      Figure 2 Passthrough networking
      +
      Figure 2 Passthrough networking

      Notes and Constraints

      • LoadBalancer Services allow workloads to be accessed from public networks through ELB. This access mode has the following restrictions:
        • It is recommended that automatically created load balancers not be used by other resources. Otherwise, these load balancers cannot be completely deleted, causing residual resources.
        • Do not change the listener name for the load balancer in clusters of v1.15 and earlier. Otherwise, the load balancer cannot be accessed.
      • After a Service is created, if the affinity setting is switched from the cluster level to the node level, the connection tracing table will not be cleared. You are advised not to modify the Service affinity setting after the Service is created. If you need to modify it, create a Service again.
      • If the service affinity is set to the node level (that is, externalTrafficPolicy is set to Local), the cluster may fail to access the Service by using the ELB address. For details, see Why a Cluster Fails to Access Services by Using the ELB Address.
      • CCE Turbo clusters support only cluster-level service affinity.
      • Dedicated ELB load balancers can be used only in clusters of v1.17 and later.
      • Dedicated load balancers must be the network type (TCP/UDP) supporting private networks (with a private IP). If the Service needs to support HTTP, the specifications of dedicated load balancers must use HTTP/HTTPS (application load balancing) in addition to TCP/UDP (network load balancing).
      • If you create a LoadBalancer Service on the CCE console, a random node port is automatically generated. If you use kubectl to create a LoadBalancer Service, a random node port is generated unless you specify one.
      • In a CCE cluster, if the cluster-level affinity is configured for a LoadBalancer Service, requests are distributed to the node ports of each node using SNAT when entering the cluster. The number of node ports cannot exceed the number of available node ports on the node. If the Service affinity is at the node level (local), there is no such constraint. In a CCE Turbo cluster, this constraint applies to shared ELB load balancers, but not dedicated ones. You are advised to use dedicated ELB load balancers in CCE Turbo clusters.
      • When the cluster service forwarding (proxy) mode is IPVS, the node IP cannot be configured as the external IP of the Service. Otherwise, the node is unavailable.
      • In a cluster using the IPVS proxy mode, if the ingress and Service use the same ELB load balancer, the ingress cannot be accessed from the nodes and containers in the cluster because kube-proxy mounts the LoadBalancer Service address to the ipvs-0 bridge. This bridge intercepts the traffic of the load balancer connected to the ingress. You are advised to use different ELB load balancers for the ingress and Service.

      Creating a LoadBalancer Service

      1. Log in to the CCE console and click the cluster name to access the cluster.
      2. Choose Networking in the navigation pane and click Create Service in the upper right corner.
      3. Set parameters.

        • Service Name: Specify a Service name, which can be the same as the workload name.
        • Access Type: Select LoadBalancer.
        • Namespace: Namespace to which the workload belongs.
        • Service Affinity: For details, see externalTrafficPolicy (Service Affinity).
          • Cluster level: The IP addresses and access ports of all nodes in a cluster can be used to access the workload associated with the Service. Service access will cause performance loss due to route redirection, and the source IP address of the client cannot be obtained.
          • Node level: Only the IP address and access port of the node where the workload is located can access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
        • Selector: Add a label and click Add. A Service selects a pod based on the added label. You can also click Reference Workload Label to reference the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
        • Load Balancer

          Select the load balancer to interconnect. Only load balancers in the same VPC as the cluster are supported. If no load balancer is available, click Create Load Balancer to create one on the ELB console.

          -

          You can click Edit and configure load balancer parameters in the Load Balancer dialog box.

          +

          You can click the edit icon in the row of Set ELB to configure load balancer parameters.

          • Distribution Policy: Three algorithms are available: weighted round robin, weighted least connections algorithm, or source IP hash.
            • Weighted round robin: Requests are forwarded to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests. This algorithm is often used for short connections, such as HTTP services.
            • Weighted least connections: In addition to the weight assigned to each server, the number of connections processed by each backend server is also considered. Requests are forwarded to the server with the lowest connections-to-weight ratio. Building on least connections, the weighted least connections algorithm assigns a weight to each server based on their processing capability. This algorithm is often used for persistent connections, such as database connections.
            • Source IP hash: The source IP address of each request is calculated using the hash algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key allocates the client to a particular server. This enables requests from different clients to be distributed in load balancing mode and ensures that requests from the same client are forwarded to the same server. This algorithm applies to TCP connections without cookies.
            -
          • Type: This function is disabled by default. You can select Source IP address. Listeners ensure session stickiness based on IP addresses. Requests from the same IP address will be forwarded to the same backend server.
          • Health Check: This function is disabled by default. The health check is for the load balancer. When TCP is selected during the port settings, you can choose either TCP or HTTP. When UDP is selected during the port settings, only UDP is supported.. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named cce-healthz will be added for the Service.
          +
        • Type: This function is disabled by default. You can select Source IP address. Listeners ensure session stickiness based on IP addresses. Requests from the same IP address will be forwarded to the same backend server.
        • Health Check: configured for the load balancer. When TCP is selected during the port settings, you can choose either TCP or HTTP. When UDP is selected during the port settings, only UDP is supported.. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named cce-healthz will be added for the Service.
      4. Port Settings
        • Protocol: protocol used by the Service.
        • Service Port: port used by the Service. The port number ranges from 1 to 65535.
        • Container Port: port on which the workload listens. For example, Nginx uses port 80 by default.
      5. Annotation: The LoadBalancer Service has some advanced CCE functions, which are implemented by annotations. For details, see Service Annotations. When you use kubectl to create a container, annotations will be used. For details, see Using kubectl to Create a Service (Using an Existing Load Balancer) and Using kubectl to Create a Service (Automatically Creating a Load Balancer).

      6. Click OK.
      @@ -272,11 +272,11 @@ spec: kubernetes ClusterIP 10.247.0.1 <none> 443/TCP 3d nginx LoadBalancer 10.247.130.196 10.78.42.242 80:31540/TCP 51s

    6. Enter the URL in the address box of the browser, for example, 10.78.42.242:80. 10.78.42.242 indicates the IP address of the load balancer, and 80 indicates the access port displayed on the CCE console.

      The Nginx is accessible.

      -
      Figure 3 Accessing Nginx through the LoadBalancer Service
      +
      Figure 3 Accessing Nginx through the LoadBalancer Service

      7. Using kubectl to Create a Service (Automatically Creating a Load Balancer)

      You can add a Service when creating a workload using kubectl. This section uses an Nginx workload as an example to describe how to add a LoadBalancer Service using kubectl.

      -
      1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
      2. Create and edit the nginx-deployment.yaml and nginx-elb-svc.yaml files.

        The file names are user-defined. nginx-deployment.yaml and nginx-elb-svc.yaml are merely example file names.

        +
        1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
        2. Create and edit the nginx-deployment.yaml and nginx-elb-svc.yaml files.

          The file names are user-defined. nginx-deployment.yaml and nginx-elb-svc.yaml are merely example file names.

          vi nginx-deployment.yaml

          apiVersion: apps/v1
 kind: Deployment
@@ -381,7 +381,7 @@ spec:
      - @@ -455,7 +455,7 @@ spec: - - diff --git a/docs/cce/umn/cce_10_0015.html b/docs/cce/umn/cce_10_0015.html index 416062e7..3b7a8919 100644 --- a/docs/cce/umn/cce_10_0015.html +++ b/docs/cce/umn/cce_10_0015.html @@ -10,104 +10,216 @@ metadata: data: SPECIAL_LEVEL: Hello SPECIAL_TYPE: CCE -

      When a ConfigMap is used in a pod, the pod and ConfigMap must be in the same cluster and namespace.

      +
      • When a ConfigMap is used in a workload, the workload and ConfigMap must be in the same cluster and namespace.
      • When a ConfigMap is mounted as a data volume and is updated, Kubernetes updates the data in the data volume at the same time.

        When a ConfigMap data volume mounted in subPath mode is updated, Kubernetes cannot automatically update the data in the data volume.

        +
      • When a ConfigMap is used as an environment variable, data can not be automatically updated when the ConfigMap is updated. To update the data, you need to restart the pod.
      -

      Setting Workload Environment Variables

      When creating a workload, you can use a ConfigMap to set environment variables. The valueFrom parameter indicates the key-value pair to be referenced.

      -
      apiVersion: v1
-kind: Pod
+
      Setting Workload Environment Variables
      Using the console
      
+
      1. Log in to the CCE console and access the cluster console.
      2. In the navigation pane, choose Workloads. Then, click Create Workload.
        When creating a workload, click Environment Variables in the Container Settings area, and click .
        
+
        • Added from ConfigMap: Select a ConfigMap to import all of its keys as environment variables.
          
+
        • Added from ConfigMap key: Import a key in a ConfigMap as the value of an environment variable.
          • Variable Name: name of an environment variable in the workload. The name can be customized and is set to the key name selected in the ConfigMap by default.
          • Variable Value/Reference: Select a ConfigMap and the key to be imported. The corresponding value is imported as a workload environment variable.
          
+
          For example, after you import the value Hello of SPECIAL_LEVEL in ConfigMap cce-configmap as the value of workload environment variable SPECIAL_LEVEL, an environment variable named SPECIAL_LEVEL with its value Hello exists in the container.
          
+
          
+
        
+
      3. Configure other workload parameters and click Create Workload.
        After the workload runs properly, access the container and run the following command to check whether the ConfigMap has been set as an environment variable of the workload:
        
+
        printenv SPECIAL_LEVEL
        
+
        The example output is as follows:
        
+
        Hello
        
+
      
+
      Using kubectl
      
+
      1. According to Connecting to a Cluster Using kubectl, configure the kubectl command to connect an ECS to the cluster.
      2. Create a file named nginx-configmap.yaml and edit it.
        vi nginx-configmap.yaml
        
+
        Content of the YAML file:
        
+
        • Added from ConfigMap: To add all data in a ConfigMap to environment variables, use the envFrom parameter. The keys in the ConfigMap will become names of environment variables in a pod.
          apiVersion: apps/v1
+kind: Deployment
 metadata:
-  name: configmap-pod-1
+  name: nginx-configmap
 spec:
-  containers:
-    - name: test-container
-      image: busybox
-      command: [ "/bin/sh", "-c", "env" ]
-      env:
-        - name: SPECIAL_LEVEL_KEY
-          valueFrom:                             ## Use valueFrom to specify the value of the env that refers to the ConfigMap.
-            configMapKeyRef:
-              name: cce-configmap                ## Name of the referenced configuration file.
-              key: SPECIAL_LEVEL                 ## Key of the referenced ConfigMap.
-  restartPolicy: Never
          
-
          If you need to define the values of multiple ConfigMaps as the environment variables of the pods, add multiple environment variable parameters to the pods.
          env:
-- name: SPECIAL_LEVEL_KEY
-  valueFrom:
-    configMapKeyRef:
-          name: cce-configmap
-          key: SPECIAL_LEVEL
-- name: SPECIAL_TYPE_KEY
-  valueFrom:
-    configMapKeyRef:
-          name: cce-configmap
-          key: SPECIAL_TYPE
          
-
          
-
          To add all data in a ConfigMap to environment variables, use the envFrom parameter. The keys in the ConfigMap will become names of environment variables in a pod.
          
-
          apiVersion: v1
-kind: Pod
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-configmap
+  template:
+    metadata:
+      labels:
+        app: nginx-configmap
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        envFrom:                      # Use envFrom to specify a ConfigMap to be referenced by environment variables.
+        - configMapRef:
+            name: cce-configmap       # Name of the referenced ConfigMap.
+      imagePullSecrets:
+      - name: default-secret
          
+
        • Added from a ConfigMap key: When creating a workload, you can use a ConfigMap to set environment variables and use the valueFrom parameter to reference the key-value pair in the ConfigMap separately.
          apiVersion: apps/v1
+kind: Deployment
 metadata:
-  name: configmap-pod-2
+  name: nginx-configmap
 spec:
-  containers:
-    - name: test-container
-      image: busybox
-      command: [ "/bin/sh", "-c", "env" ]
-      envFrom:
-      - configMapRef:
-          name: cce-configmap
-  restartPolicy: Never
          
-
      
-
      Setting Command Line Parameters
      You can use a ConfigMap to set commands or parameter values for a container by using the environment variable substitution syntax $(VAR_NAME). The following shows an example.
      
-
      apiVersion: v1
-kind: Pod
-metadata:
-  name: configmap-pod-3
-spec:
-  containers:
-    - name: test-container
-      image: busybox
-      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
-      env:
-        - name: SPECIAL_LEVEL_KEY
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-configmap
+  template:
+    metadata:
+      labels:
+        app: nginx-configmap
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        env:                             # Set environment variables in the workload.
+        - name: SPECIAL_LEVEL           # Name of the environment variable in the workload.
+          valueFrom:                    # Use valueFrom to specify an environment variable to reference a ConfigMap.
+            configMapKeyRef:
+              name: cce-configmap       # Name of the referenced ConfigMap.
+              key: SPECIAL_LEVEL        # Key in the referenced ConfigMap.
+        - name: SPECIAL_TYPE            # Add multiple environment variables. Multiple environment variables can be imported at the same time.
           valueFrom:
             configMapKeyRef:
-              name: cce-configmap
-              key: SPECIAL_LEVEL
-        - name: SPECIAL_TYPE_KEY
-          valueFrom:
-            configMapKeyRef:
-              name: cce-configmap
-              key: SPECIAL_TYPE
-  restartPolicy: Never
      
-
      After the pod runs, the following information is displayed:
      
+              name: cce-configmap
+              key: SPECIAL_TYPE
+      imagePullSecrets:
+      - name: default-secret
      + +

    7. Create a workload.

      kubectl apply -f nginx-configmap.yaml

      +

    8. View the environment variables in the pod.

      1. Run the following command to view the created pod:
        kubectl get pod | grep nginx-configmap
        +
        Expected output:
        nginx-configmap-***   1/1     Running   0              2m18s
        +
        +
      2. Run the following command to view the environment variables in the pod:
        kubectl exec nginx-configmap-*** -- printenv SPECIAL_LEVEL SPECIAL_TYPE
        +

        Expected output:

        +
        Hello
+CCE
        +

        The ConfigMap has been set as an environment variable of the workload.

        +
      +

      9. +
      +

      Setting Command Line Parameters

      You can use a ConfigMap as an environment variable to set commands or parameter values for a container by using the environment variable substitution syntax $VAR_NAME.

      +

      Using the console

      +
      1. Log in to the CCE console and access the cluster console.
      2. In the navigation pane, choose Workloads. Then, click Create Workload.

        When creating a workload, click Environment Variables in the Container Settings area, and click . In this example, select Added from ConfigMap.

        +
        • Added from ConfigMap: Select a ConfigMap to import all of its keys as environment variables.

          +
        +

      3. Click Lifecycle in the Container Settings area, click the Post-Start tab on the right, and set the following parameters:

        • Processing Method: CLI
        • Command: Enter the following three command lines. SPECIAL_LEVEL and SPECIAL_TYPE are the environment variable names in the workload, that is, the key names in the cce-configmap ConfigMap.
          /bin/bash
+-c
+echo $SPECIAL_LEVEL $SPECIAL_TYPE > /usr/share/nginx/html/index.html
          +
        +

        +

      4. Configure other workload parameters and click Create Workload.

        After the workload runs properly, access the container and run the following command to check whether the ConfigMap has been set as an environment variable of the workload:

        +
        cat /usr/share/nginx/html/index.html
        +

        The example output is as follows:

        +
        Hello CCE
        +

      +

      Using kubectl

      +
      1. According to Connecting to a Cluster Using kubectl, configure the kubectl command to connect an ECS to the cluster.
      2. Create a file named nginx-configmap.yaml and edit it.

        vi nginx-configmap.yaml

        +
        As shown in the following example, the cce-configmap ConfigMap is imported to the workload. SPECIAL_LEVEL and SPECIAL_TYPE are environment variable names, that is, key names in the cce-configmap ConfigMap.
        apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-configmap
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-configmap
+  template:
+    metadata:
+      labels:
+        app: nginx-configmap
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        lifecycle:
+          postStart:
+            exec:
+              command: [ "/bin/sh", "-c", "echo $SPECIAL_LEVEL $SPECIAL_TYPE > /usr/share/nginx/html/index.html" ]
+        envFrom:                      # Use envFrom to specify a ConfigMap to be referenced by environment variables.
+        - configMapRef:
+            name: cce-configmap       # Name of the referenced ConfigMap.
+      imagePullSecrets:
+        - name: default-secret
        +
        +

      3. Create a workload.

        kubectl apply -f nginx-configmap.yaml

        +

      4. After the workload runs properly, the following content is entered into the /usr/share/nginx/html/index.html file in the container:

        1. Run the following command to view the created pod:
          kubectl get pod | grep nginx-configmap
          +
          Expected output:
          nginx-configmap-***   1/1     Running   0              2m18s
          +
          +
        2. Run the following command to view the environment variables in the pod:
          kubectl exec nginx-configmap-*** -- cat /usr/share/nginx/html/index.html
          +

          Expected output:

          Hello CCE
          +
        +

      -

      Attaching a ConfigMap to the Workload Data Volume

      A ConfigMap can also be used in the data volume. You only need to attach the ConfigMap to the workload when creating the workload. After the mounting is complete, a configuration file with key as the file name and value as the file content is generated.

      -
      apiVersion: v1
-kind: Pod
+
      Attaching a ConfigMap to the Workload Data Volume
      The data stored in a ConfigMap can be referenced in a volume of type ConfigMap. You can mount such a volume to a specified container path. The platform supports the separation of workload codes and configuration files. ConfigMap volumes are used to store workload configuration parameters. Before that, you need to create ConfigMaps in advance. For details, see Creating a ConfigMap. 
      
+
      Using the console
      
+
      1. Log in to the CCE console and access the cluster console.
      2. In the navigation pane, choose Workloads. Then, click Create Workload.
        When creating a workload, click Data Storage in the Container Settings area. Click Add Volume and select ConfigMap from the drop-down list.
        
+
      3. Set the local volume type to ConfigMap and set parameters for adding a local volume, as shown in Table 1.
        
+
      Table 5 Advanced configuration parameters

      Parameter

      Description

      +

      Description

      Kubernetes Label

      +

      Kubernetes Label

      Click Add Label to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.

      -

      Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.

      +

      Click Add to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.

      +

      Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.

      Resource Tag

      +

      Resource Tag

      You can add resource tags to classify resources.

      -

      You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency.

      -

      CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag.

      +

      You can add resource tags to classify resources.

      +

      You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency.

      +

      CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag.

      Taint

      +

      Taint

      This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
      • Key: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
      • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
      • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
      +
      This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
      • Key: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
      • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
      • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
      -

      For details, see Managing Node Taints.

      -
      NOTE:

      For a cluster of v1.19 or earlier, the workload may have been scheduled to a node before the taint is added. To avoid such a situation, select a cluster of v1.19 or later.

      +

      For details, see Managing Node Taints.

      +
      NOTE:

      For a cluster of v1.19 or earlier, the workload may have been scheduled to a node before the taint is added. To avoid such a situation, select a cluster of v1.19 or later.

      Max. Pods

      +

      Max. Pods

      Maximum number of pods that can run on the node, including the default system pods.

      -

      This limit prevents the node from being overloaded with pods.

      -

      This number is also decided by other factors. For details, see Maximum Number of Pods That Can Be Created on a Node.

      +

      Maximum number of pods that can run on the node, including the default system pods.

      +

      This limit prevents the node from being overloaded with pods.

      +

      This number is also decided by other factors. For details, see Maximum Number of Pods That Can Be Created on a Node.

      ECS Group

      +

      ECS Group

      An ECS group logically groups ECSs. The ECSs in the same ECS group comply with the same policy associated with the ECS group.

      -

      Anti-affinity: ECSs in an ECS group are deployed on different physical hosts to improve service reliability.

      -

      Select an existing ECS group, or click Add ECS Group to create one. After the ECS group is created, click the refresh button.

      +

      An ECS group logically groups ECSs. The ECSs in the same ECS group comply with the same policy associated with the ECS group.

      +

      Anti-affinity: ECSs in an ECS group are deployed on different physical hosts to improve service reliability.

      +

      Select an existing ECS group, or click Add ECS Group to create one. After the ECS group is created, click the refresh button.

      Pre-installation Command

      +

      Pre-installation Command

      Enter commands. A maximum of 1,000 characters are allowed.

      -

      The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed.

      +

      Enter commands. A maximum of 1,000 characters are allowed.

      +

      The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed.

      Post-installation Command

      +

      Post-installation Command

      Enter commands. A maximum of 1,000 characters are allowed.

      -

      The script will be executed after Kubernetes software is installed and will not affect the installation.

      +

      Enter commands. A maximum of 1,000 characters are allowed.

      +

      The script will be executed after Kubernetes software is installed and will not affect the installation.

      Agency

      +

      Agency

      An agency is created by the account administrator on the IAM console. By creating an agency, you can share your cloud server resources with another account, or entrust a more professional person or team to manage your resources.

      -

      If no agency is available, click Create Agency on the right to create one.

      +

      An agency is created by the account administrator on the IAM console. By creating an agency, you can share your cloud server resources with another account, or entrust a more professional person or team to manage your resources.

      +

      If no agency is available, click Create Agency on the right to create one.

      Select a proper load balancer type as required.

      The value can be:

      -
      • union: shared load balancer
      • performance: dedicated load balancer, which can be used only in clusters of v1.17 and later.
      +
      • union: shared load balancer
      • performance: dedicated load balancer, which can be used only in clusters of v1.17 and later.

      kubernetes.io/elb.subnet-id

      @@ -422,10 +422,10 @@ spec:

      String

      This parameter indicates the load balancing algorithm of the backend server group. The default value is ROUND_ROBIN.

      +

      This parameter indicates the load balancing algorithm of the backend server group. The default value is ROUND_ROBIN.

      Options:

      -
      • ROUND_ROBIN: weighted round robin algorithm
      • LEAST_CONNECTIONS: weighted least connections algorithm
      • SOURCE_IP: source IP hash algorithm
      -

      When the value is SOURCE_IP, the weights of backend servers in the server group are invalid.

      +
      • ROUND_ROBIN: weighted round robin algorithm
      • LEAST_CONNECTIONS: weighted least connections algorithm
      • SOURCE_IP: source IP hash algorithm
      +

      When the value is SOURCE_IP, the weights of backend servers in the server group are invalid.

      kubernetes.io/elb.health-check-flag

      @@ -435,7 +435,7 @@ spec:

      String

      Whether to enable the ELB health check.

      -
      • Enabling health check: Leave blank this parameter or set it to on.
      • Disabling health check: Set this parameter to off.
      +
      • Enabling health check: Leave blank this parameter or set it to on.
      • Disabling health check: Set this parameter to off.

      If this parameter is enabled, the kubernetes.io/elb.health-check-option field must also be specified at the same time.

      String

      Listeners ensure session stickiness based on IP addresses. Requests from the same IP address will be forwarded to the same backend server.

      -
      • Disabling sticky session: Do not set this parameter.
      • Enabling sticky session: Set this parameter to SOURCE_IP, indicating that the sticky session is based on the source IP address.
      +
      • Disabling sticky session: Do not set this parameter.
      • Enabling sticky session: Set this parameter to SOURCE_IP, indicating that the sticky session is based on the source IP address.

      kubernetes.io/elb.session-affinity-option

      @@ -633,8 +633,8 @@ spec: 
      NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
 kubernetes   ClusterIP      10.247.0.1       <none>        443/TCP        3d
 nginx        LoadBalancer   10.247.130.196   10.78.42.242   80:31540/TCP   51s
      -

    9. Enter the URL in the address box of the browser, for example, 10.78.42.242:80. 10.78.42.242 indicates the IP address of the load balancer, and 80 indicates the access port displayed on the CCE console.

      The Nginx is accessible.

      -
      Figure 4 Accessing Nginx through the LoadBalancer Service
      +

    10. Enter the URL in the address box of the browser, for example, 10.78.42.242:80. 10.78.42.242 indicates the IP address of the load balancer, and 80 indicates the access port displayed on the CCE console.

      The Nginx is accessible.

      +
      Figure 4 Accessing Nginx through the LoadBalancer Service

      11. ELB Forwarding

      After a Service of the LoadBalancer type is created, you can view the listener forwarding rules of the load balancer on the ELB console.

      @@ -651,11 +651,11 @@ kubernetes ClusterIP 10.247.0.1 <none> 443/TCP

      Client

      Tunnel Network Cluster (IPVS)

      +

      Container Tunnel Network Cluster (IPVS)

      VPC Network Cluster (IPVS)

      Tunnel Network Cluster (iptables)

      +

      Container Tunnel Network Cluster (iptables)

      VPC Network Cluster (iptables)

      + + + + + + + + + + +
      Table 1 Mounting a ConfigMap volume

      Parameter

      +

      Description

      +

      Option

      +

      Select the desired ConfigMap name.

      +

      A ConfigMap must be created in advance. For details, see Creating a ConfigMap.

      +

      Add Container Path

      +
      Configure the following parameters:
      1. Container Path: Enter the path of the container, for example, /tmp.
        This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
        NOTICE:

        When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.

        +
        +
        +
      2. subPath: Enter a subpath, for example, tmp.
        • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
        • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
        • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
        +
      3. Set the permission to Read-only. Data volumes in the path are read-only.
      +
      +

      You can click to add multiple paths and subpaths.

      +
      +
      +

      +

      Using kubectl

      +
      1. According to Connecting to a Cluster Using kubectl, configure the kubectl command to connect an ECS to the cluster.
      2. Create a file named nginx-configmap.yaml and edit it.

        vi nginx-configmap.yaml

        +

        As shown in the following example, after the ConfigMap volume is mounted, a configuration file with the key as the file name and value as the file content is generated in the /etc/config directory of the container.

        +
        apiVersion: apps/v1
+kind: Deployment
 metadata:
-  name: configmap-pod-4
+  name: nginx-configmap
 spec:
-  containers:
-    - name: test-container
-      image: busybox
-      command: [ "/bin/sh", "-c", "ls /etc/config/" ]   ## Lists the file names in the directory.
-      volumeMounts:
-      - name: config-volume
-        mountPath: /etc/config                          ## Attaches to the /etc/config directory.
-  volumes:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-configmap
+  template:
+    metadata:
+      labels:
+        app: nginx-configmap
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        volumeMounts:
+        - name: config-volume
+          mountPath: /etc/config            # Mount to the /etc/config directory.
+          readOnly: true
+    volumes:
     - name: config-volume
       configMap:
-        name: cce-configmap
-  restartPolicy: Never
        -

        After the pod is run, the SPECIAL_LEVEL and SPECIAL_TYPE files are generated in the /etc/config directory. The contents of the files are Hello and CCE, respectively. Also, the following file names will be displayed.

        -
        SPECIAL_TYPE
-SPECIAL_LEVEL
        -

        To mount a ConfigMap to a data volume, you can also perform operations on the CCE console. When creating a workload, set advanced settings for the container, choose Data Storage > Local Volume, click Add Local Volume, and select ConfigMap. For details, see ConfigMap.

        + name: cce-configmap # Name of the referenced ConfigMap. +

      3. Create a workload.

        kubectl apply -f nginx-configmap.yaml

        +

      4. After the workload runs properly, the SPECIAL_LEVEL and SPECIAL_TYPE files are generated in the /etc/config directory. The contents of the files are Hello and CCE, respectively.

        1. Run the following command to view the created pod:
          kubectl get pod | grep nginx-configmap
          +
          Expected output:
          nginx-configmap-***   1/1     Running   0              2m18s
          +
          +
        2. Run the following command to view the SPECIAL_LEVEL or SPECIAL_TYPE file in the pod:
          kubectl exec nginx-configmap-*** -- /etc/config/SPECIAL_LEVEL
          +

          Expected output:

          +
          Hello
          +
        +

      -
      Parent topic: Configuration Center
      +
      Parent topic: ConfigMaps and Secrets
      diff --git a/docs/cce/umn/cce_10_0016.html b/docs/cce/umn/cce_10_0016.html index 7c5c5744..64cbe038 100644 --- a/docs/cce/umn/cce_10_0016.html +++ b/docs/cce/umn/cce_10_0016.html @@ -1,10 +1,10 @@

      Using a Secret

      -

      The following secrets are used by the CCE system. Do not perform any operations on them.

      +

      Do not perform any operation on the following secrets. For details, see Cluster Secrets.

      • Do not operate secrets under kube-system.
      • Do not operate default-secret and paas.elb in any of the namespaces. The default-secret is used to pull the private image of SWR, and the paas.elb is used to connect the service in the namespace to the ELB service.
      - +

      The following example shows how to use a secret.

      apiVersion: v1
 kind: Secret
@@ -12,75 +12,190 @@ metadata:
   name: mysecret
 type: Opaque
 data:
-  username: ****** #The value must be Base64-encoded.
+  username: ******  #The value must be Base64-encoded.
   password: ******  #The value must be encoded using Base64.
      -

      When a secret is used in a pod, the pod and secret must be in the same cluster and namespace.

      +
      • When a secret is used in a pod, the pod and secret must be in the same cluster and namespace.
      • When a secret is updated, Kubernetes updates the data in the data volume at the same time.

        However, when a secret data volume mounted in subPath mode is updated, Kubernetes cannot automatically update the data in the data volume.

        +
      -

      Configuring the Data Volume of a Pod

      A secret can be used as a file in a pod. As shown in the following example, the username and password of the mysecret secret are saved in the /etc/foo directory as files.
      apiVersion: v1
-kind: Pod
+
      Setting Environment Variables of a Workload
      Using the console
      
+
      1. Log in to the CCE console and access the cluster console.
      2. In the navigation pane, choose Workloads. Then, click Create Workload.
        When creating a workload, click Environment Variables in the Container Settings area, and click .
        
+
        • Added from secret: Select a secret and import all keys in the secret as environment variables.
          
+
        • Added from secret key: Import the value of a key in a secret as the value of an environment variable.
          • Variable Name: name of an environment variable in the workload. The name can be customized and is set to the key name selected in the secret by default.
          • Variable Value/Reference: Select a secret and the key to be imported. The corresponding value is imported as a workload environment variable.
          
+
          For example, after you import the value of username in secret mysecret as the value of workload environment variable username, an environment variable named username exists in the container.
          
+
          
+
        
+
      3. Configure other workload parameters and click Create Workload.
        After the workload runs properly, access the container and run the following command to check whether the secret has been set as an environment variable of the workload:
        
+
        printenv username
        
+
        If the output is the same as that in the secret, the secret has been set as an environment variable of the workload.
        
+
      
+
      Using kubectl
      
+
      1. According to Connecting to a Cluster Using kubectl, configure the kubectl command to connect an ECS to the cluster.
      2. Create a file named nginx-secret.yaml and edit it.
        vi nginx-secret.yaml
        
+
        Content of the YAML file:
        
+
        • Added from a secret: To add all data in a secret to environment variables, use the envFrom parameter. The keys in the ConfigMap will become names of environment variables in a workload.
          apiVersion: apps/v1
+kind: Deployment
 metadata:
-  name: mypod
+  name: nginx-secret
 spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-secret
+  template:
+    metadata:
+      labels:
+        app: nginx-secret
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        envFrom:                 # Use envFrom to specify a secret to be referenced by environment variables.
+        - secretRef:
+            name: mysecret       # Name of the referenced secret.
+      imagePullSecrets:
+      - name: default-secret
          
+
        • Added from a secret key: When creating a workload, you can set a secret to set environment variables and use the valueFrom parameter to reference the key-value pair in the secret separately.
          apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-secret
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-secret
+  template:
+    metadata:
+      labels:
+        app: nginx-secret
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        env:                             # Set environment variables in the workload.
+        - name: SECRET_USERNAME           # Name of the environment variable in the workload.
+          valueFrom:                    # Use envFrom to specify a secret to be referenced by environment variables.
+            secretKeyRef:
+              name: mysecret       # Name of the referenced secret.
+              key: username        # Name of the referenced key.
+        - name: SECRET_PASSWORD            # Add multiple environment variables. Multiple environment variables can be imported at the same time.
+          valueFrom:
+            secretKeyRef:
+              name: mysecret
+              key: password
+      imagePullSecrets:
+      - name: default-secret
          
+
        
+
      3. Create a workload.
        kubectl apply -f nginx-secret.yaml
        
+
      4. View the environment variables in the pod.
        1. Run the following command to view the created pod:
          kubectl get pod | grep nginx-secret
          
+
          Expected output:
          nginx-secret-***   1/1     Running   0              2m18s
          
+
          
+
        2. Run the following command to view the environment variables in the pod:
          kubectl exec nginx-secret-*** -- printenv SPECIAL_USERNAME SPECIAL_PASSWORD
          
+
          If the output is the same as that in the secret, the secret has been set as an environment variable of the workload.
          
+
        
+
      
+
      
+
      Configuring the Data Volume of a Workload
      You can mount a secret as a volume to the specified container path. Contents in a secret are user-defined. Before that, you need to create a secret. For details, see Creating a Secret.
      
+
      Using the console
      
+
      1. Log in to the CCE console and access the cluster console.
      2. In the navigation pane on the left, click Workloads. In the right pane, click the Deployments tab. Click Create Workload in the upper right corner.
        When creating a workload, click Data Storage in the Container Settings area. Click Add Volume and select Secret from the drop-down list.
        
+
      3. Set the local volume type to Secret and set parameters for adding a local volume, as shown in Table 1.
        
+
        
+
+
+
+
+
+
+
+
+
+
+
        Table 1 Secret
        Parameter
        
+
        Description
        
+
        Secret
        
+
        Select the desired secret name.
        
+
        A secret must be created in advance. For details, see Creating a Secret.
        
+
        Add Container Path
        
+
        Configure the following parameters:
        
+
        1. Container Path: Enter the path of the container, for example, /tmp.
          This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
           NOTICE: 
          When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
          
+
          
+
          
+
        2. subPath: Enter a subpath, for example, tmp.
          • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
          • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
          • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
          
+
        3. Set the permission to Read-only. Data volumes in the path are read-only.
        
+
        You can click  to add multiple paths and subpaths.
        
+
        
+
        
+
      
+
      Using kubectl
      
+
      1. According to Connecting to a Cluster Using kubectl, configure the kubectl command to connect an ECS to the cluster.
      2. Create a file named nginx-secret.yaml and edit it.
        vi nginx-secret.yaml
        
+
        In the following example, the username and password in the mysecret secret are saved in the /etc/foo directory as files.
        apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-secret
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-secret
+  template:
+    metadata:
+      labels:
+        app: nginx-secret
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        volumeMounts:
+       - name: foo
+         mountPath: /etc/foo          # Mount to the /etc/foo directory.
+         readOnly: true
+    volumes:
     - name: foo
-      mountPath: "/etc/foo"
-      readOnly: true
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
        
+      secret:
+        secretName: mysecret      # Name of the referenced secret.
      -
      In addition, you can specify the directory and permission to access a secret. The username is stored in the /etc/foo/my-group/my-username directory of the container.
      apiVersion: v1
-kind: Pod
+
      You can also use the items field to control the mapping path of the secret key. For example, store the username is stored in the /etc/foo/my-group/my-username directory of the container.
       
      • After the items field is used to specify the mapping path of the secret key, the keys that are not specified will not be created as files. For example, if the password key in the following example is not specified, the file will not be created.
      • If you want to use all keys in a secret, you must list all keys in the items field.
      • All keys listed in the items field must exist in the corresponding secret. Otherwise, the volume is not created.
      
+
      
+
      apiVersion: apps/v1
+kind: Deployment
 metadata:
-  name: mypod
+  name: nginx-secret
 spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: nginx-secret
+  template:
+    metadata:
+      labels:
+        app: nginx-secret
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        volumeMounts:
+       - name: foo
+         mountPath: /etc/foo          # Mount to the /etc/foo directory.
+         readOnly: true
+    volumes:
     - name: foo
-      mountPath: "/etc/foo"
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      items:
-      - key: username
-        path: my-group/my-username
-        mode: 511
      
+      secret:
+        secretName: mysecret      # Name of the referenced secret.
+        items:
+        - key: username      # Name of the referenced key.
+          path: my-group/my-username    # Mapping path of the secret key.
      -

      To mount a secret to a data volume, you can also perform operations on the CCE console. When creating a workload, set advanced settings for the container, choose Data Storage > Local Volume, click Add Local Volume, and select Secret. For details, see Secret.

      -
      -

      Setting Environment Variables of a Pod

      A secret can be used as an environment variable of a pod. As shown in the following example, the username and password of the mysecret secret are defined as an environment variable of the pod.
      apiVersion: v1
-kind: Pod
-metadata:
-  name: secret-env-pod
-spec:
-  containers:
-  - name: mycontainer
-    image: redis
-    env:
-      - name: SECRET_USERNAME
-        valueFrom:
-          secretKeyRef:
-            name: mysecret
-            key: username
-      - name: SECRET_PASSWORD
-        valueFrom:
-          secretKeyRef:
-            name: mysecret
-            key: password
-  restartPolicy: Never
      +

    11. Create a workload.

      kubectl apply -f nginx-secret.yaml

      +

    12. After the workload runs properly, the username and password files are generated in the /etc/foo directory.

      1. Run the following command to view the created pod:
        kubectl get pod | grep nginx-secret
        +
        Expected output:
        nginx-secret-***   1/1     Running   0              2m18s
        +
      2. Run the following command to view the username or password file in the pod:
        kubectl exec nginx-secret-*** -- /etc/foo/username
        +

        The expected output is the same as that in the secret.

        +
      +

      13. -
      Parent topic: Configuration Center
      +
      Parent topic: ConfigMaps and Secrets
      diff --git a/docs/cce/umn/cce_10_0018.html b/docs/cce/umn/cce_10_0018.html index 84e7a111..f2c43131 100644 --- a/docs/cce/umn/cce_10_0018.html +++ b/docs/cce/umn/cce_10_0018.html @@ -4,7 +4,7 @@

      CCE works with AOM to collect workload logs. When creating a node, CCE installs the ICAgent for you (the DaemonSet named icagent in the kube-system namespace of the cluster). After the ICAgent collects workload logs and reports them to AOM, you can view workload logs on the CCE or AOM console.

      Notes and Constraints

      The ICAgent only collects *.log, *.trace, and *.out text log files.

      -

      Using ICAgent to Collect Logs

      1. When creating a workload, set logging for the container.
      2. Click to add a log policy.

        The following uses Nginx as an example. Log policies vary depending on workloads.
        Figure 1 Adding a log policy
        +

        Using ICAgent to Collect Logs

        1. When creating a workload, set logging for the container.
        2. Click to add a log policy.

          The following uses Nginx as an example. Log policies vary depending on workloads.
          Figure 1 Adding a log policy

        3. Set Storage Type to Host Path or Container Path.

          Table 1 Configuring log policies

          Parameter

          @@ -135,7 +135,7 @@ spec:
          - @@ -146,8 +146,8 @@ spec: diff --git a/docs/cce/umn/cce_10_0026.html b/docs/cce/umn/cce_10_0026.html index cbb20eaf..152c4176 100644 --- a/docs/cce/umn/cce_10_0026.html +++ b/docs/cce/umn/cce_10_0026.html @@ -3,13 +3,13 @@

          Querying CTS Logs

          Scenario

          After you enable CTS, the system starts recording operations on CCE resources. Operation records of the last 7 days can be viewed on the CTS management console.

          -

          Procedure

          1. Log in to the management console.
          2. Click in the upper left corner and select a region.
          3. Choose Service List from the main menu. Choose Management & Deployment > Cloud Trace Service.
          4. In the navigation pane of the CTS console, choose Cloud Trace Service > Trace List.
          5. On the Trace List page, query operation records based on the search criteria. Currently, the trace list supports trace query based on the combination of the following search criteria:

            • Trace Source, Resource Type, and Search By

              Select the search criteria from the drop-down lists. Select CCE from the Trace Source drop-down list.

              +

              Procedure

              1. Log in to the management console.
              2. Click in the upper left corner and select a region.
              3. Choose Service List from the main menu. Choose Management & Deployment > Cloud Trace Service.
              4. In the navigation pane of the CTS console, choose Cloud Trace Service > Trace List.
              5. On the Trace List page, query operation records based on the search criteria. Currently, the trace list supports trace query based on the combination of the following search criteria:

                • Trace Source, Resource Type, and Search By

                  Select the search criteria from the drop-down lists. Select CCE from the Trace Source drop-down list.

                  If you select Trace name from the Search By drop-down list, specify the trace name.

                  If you select Resource ID from the Search By drop-down list, select or enter a specific resource ID.

                  If you select Resource name from the Search By drop-down list, select or enter a specific resource name.

                • Operator: Select a specific operator (at user level rather than account level).
                • Trace Status: Set this parameter to any of the following values: All trace statuses, normal, warning, and incident.
                • Time range: You can query traces generated during any time range in the last seven days.
                -

              6. Click on the left of a trace to expand its details, as shown below.

                Figure 1 Expanding trace details
                -

              7. Click View Trace in the Operation column. The trace details are displayed.

                Figure 2 Viewing event details
                +

              8. Click on the left of a trace to expand its details, as shown below.

                Figure 1 Expanding trace details
                +

              9. Click View Trace in the Operation column. The trace details are displayed.

                Figure 2 Viewing event details

          diff --git a/docs/cce/umn/cce_10_0028.html b/docs/cce/umn/cce_10_0028.html index 52c3ac5f..059e0b6b 100644 --- a/docs/cce/umn/cce_10_0028.html +++ b/docs/cce/umn/cce_10_0028.html @@ -3,7 +3,7 @@

          Creating a CCE Cluster

          On the CCE console, you can easily create Kubernetes clusters. Kubernetes can manage container clusters at scale. A cluster manages a group of node resources.

          In CCE, you can create a CCE cluster to manage VMs. By using high-performance network models, hybrid clusters provide a multi-scenario, secure, and stable runtime environment for containers.

          -

          Notes and Constraints

          • During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name.
          • You can create a maximum of 50 clusters in a single region.
          • After a cluster is created, the following items cannot be changed:
            • Cluster type
            • Number of master nodes in the cluster
            • AZ of a master node
            • Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, and kube-proxy (forwarding) settings
            • Network model. For example, change Tunnel network to VPC network.
            +

            Notes and Constraints

            • During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the DNS server address of the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name.
            • You can create a maximum of 50 clusters in a single region.
            • After a cluster is created, the following items cannot be changed:
              • Cluster type
              • Number of master nodes in the cluster
              • AZ of a master node
              • Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, and kube-proxy (forwarding) settings
              • Network model. For example, change Tunnel network to VPC network.

            Procedure

            1. Log in to the CCE console. Choose Clusters. On the displayed page, click Create next to CCE cluster.
            2. Set cluster parameters.

              Basic Settings
              • Cluster Name
              • Cluster Version: Select the Kubernetes version used by the cluster.
              • Cluster Scale: maximum number of nodes that can be managed by the cluster.
              • HA: distribution mode of master nodes. By default, master nodes are randomly distributed in different AZs to improve DR capabilities.
                You can also expand advanced settings and customize the master node distribution mode. The following two modes are supported:
                • Random: Master nodes are created in different AZs for DR.
                • Custom: You can determine the location of each master node.
                  • Host: Master nodes are created on different hosts in the same AZ.
                  • Custom: You can determine the location of each master node.
                  @@ -20,12 +20,14 @@
        4. Description: The value can contain a maximum of 200 English characters.
          5. -

        5. Click Next: Add-on Configuration.

          By default, cordens and everest add-ons are installed.

          -
          Service log
          • ICAgent:

            A log collector provided by Application Operations Management (AOM), reporting logs to AOM and Log Tank Service (LTS) according to the log collection rules you configured.

            -

            You can collect stdout logs as required.

            +

          • Click Next: Add-on Configuration.

            Domain Name Resolution: Uses the coredns add-on, installed by default, to resolve domain names and connect to the cloud DNS server.

            +

            Container Storage: Uses the everest add-on, installed by default, to provide container storage based on CSI and connect to cloud storage services such as EVS.

            +
            Service logs
            • Using ICAgent:

              A log collector provided by Application Operations Management (AOM), reporting logs to AOM and Log Tank Service (LTS) according to the log collection rules you configured.

              +

              You can collect stdout logs as required.

            -

          • After the parameters are specified, click Next: Confirm. The cluster resource list is displayed. Confirm the information and click Submit.

            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.

            +

            Overload Control: If overload control is enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available.

            +

          • After setting the parameters, click Next: Confirm. After confirming that the cluster configuration information is correct, select I have read and understand the preceding instructions and click Submit.

            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.

          Related Operations

          diff --git a/docs/cce/umn/cce_10_0031.html b/docs/cce/umn/cce_10_0031.html index a61780a4..4edbb64b 100644 --- a/docs/cce/umn/cce_10_0031.html +++ b/docs/cce/umn/cce_10_0031.html @@ -4,7 +4,7 @@
            -
          • Managing Cluster Components
            +
          • Cluster Configuration Management
          • Deleting a Cluster
            • diff --git a/docs/cce/umn/cce_10_00356.html b/docs/cce/umn/cce_10_00356.html new file mode 100644 index 00000000..4c80b9eb --- /dev/null +++ b/docs/cce/umn/cce_10_00356.html @@ -0,0 +1,22 @@ + + +

            Accessing a Container

            +

            Scenario

            If you encounter unexpected problems when using a container, you can log in to the container for debugging.

            +
            +

            Logging In to a Container Using kubectl

            1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
            2. Run the following command to view the created pod:

              kubectl get pod
              +
              The example output is as follows:
              NAME                               READY   STATUS    RESTARTS       AGE
+nginx-59d89cb66f-mhljr             1/1     Running   0              11m
              +
              +

            3. Query the name of the container in the pod.

              kubectl get po nginx-59d89cb66f-mhljr -o jsonpath='{range .spec.containers[*]}{.name}{end}{"\n"}'
              +
              The example output is as follows:
              container-1
              +
              +

            4. Run the following command to log in to the container named container-1 in nginx-59d89cb66f-mhljrPod:

              kubectl exec -it nginx-59d89cb66f-mhljr -c container-1 -- /bin/sh
              +

            5. To exit the container, run the exit command.
            +
            +
            +
            +
            +
            Parent topic: Workloads
            +
            +
            + diff --git a/docs/cce/umn/cce_10_0036.html b/docs/cce/umn/cce_10_0036.html index 6c37df45..3b8fed04 100644 --- a/docs/cce/umn/cce_10_0036.html +++ b/docs/cce/umn/cce_10_0036.html @@ -5,7 +5,7 @@

          Notes and Constraints

          • Deleting a node will lead to pod migration, which may affect services. Therefore, delete nodes during off-peak hours.
          • Unexpected risks may occur during node deletion. Back up related data in advance.
          • While the node is being deleted, the backend will set the node to the unschedulable state.
          • Only worker nodes can be stopped.
          -

          Procedure

          1. Log in to the CCE console and click the cluster name to access the cluster.
          2. In the navigation pane, choose Nodes. In the right pane, click the name of the node to be stopped.
          3. In the upper right corner of the ECS details page, click Stop in the instance status area. In the displayed dialog box, click Yes.

            Figure 1 ECS details page
            +

            Procedure

            1. Log in to the CCE console and click the cluster name to access the cluster.
            2. In the navigation pane, choose Nodes. In the right pane, click the name of the node to be stopped.
            3. In the upper right corner of the ECS details page, click Stop in the instance status area. In the displayed dialog box, click Yes.

              Figure 1 ECS details page

          diff --git a/docs/cce/umn/cce_10_0045.html b/docs/cce/umn/cce_10_0045.html index 6ae35260..f1d3a200 100644 --- a/docs/cce/umn/cce_10_0045.html +++ b/docs/cce/umn/cce_10_0045.html @@ -1,6 +1,6 @@ -

          Configuration Center

          +

          ConfigMaps and Secrets

            diff --git a/docs/cce/umn/cce_10_0046.html b/docs/cce/umn/cce_10_0046.html index 72d826dd..2173e6fd 100644 --- a/docs/cce/umn/cce_10_0046.html +++ b/docs/cce/umn/cce_10_0046.html @@ -24,6 +24,8 @@
          • CPU Core Binding
            • +
          • Accessing a Container
            +
          • Pod Labels and Annotations
          • Volcano Scheduling
            diff --git a/docs/cce/umn/cce_10_0047.html b/docs/cce/umn/cce_10_0047.html index 1afbf991..26c84a51 100644 --- a/docs/cce/umn/cce_10_0047.html +++ b/docs/cce/umn/cce_10_0047.html @@ -7,7 +7,7 @@
          6. -

          Using the CCE Console

          1. Log in to the CCE console.
          2. Click the cluster name to access the cluster details page, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
          3. Set basic information about the workload.

            Basic Info
            • Workload Type: Select Deployment. For details about workload types, see Overview.
            • Workload Name: Enter the name of the workload.
            • Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
            • Pods: Enter the number of pods.
            • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
            • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
            +

            Using the CCE Console

            1. Log in to the CCE console.
            2. Click the cluster name to access the cluster details page, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
            3. Set basic information about the workload.

              Basic Info
              • Workload Type: Select Deployment. For details about workload types, see Overview.
              • Workload Name: Enter the name of the workload. Enter 1 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 of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
              • Pods: Enter the number of pods.
              • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
              • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
              Container Settings
            -

            Using the CCE Console

            1. Log in to the CCE console.
            2. Click the cluster name to access the cluster details page, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
            3. Set basic information about the workload.

              Basic Info
              • Workload Type: Select StatefulSet. For details about workload types, see Overview.
              • Workload Name: Enter the name of the workload.
              • Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
              • Pods: Enter the number of pods.
              • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
              • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
              +

              Using the CCE Console

              1. Log in to the CCE console.
              2. Click the cluster name to access the cluster details page, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
              3. Set basic information about the workload.

                Basic Info
                • Workload Type: Select StatefulSet. For details about workload types, see Overview.
                • Workload Name: Enter the name of the workload. Enter 1 to 52 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 of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                • Pods: Enter the number of pods.
                • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
                Container Settings
                • Container Information
                  Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
                  • Basic Info: See Setting Basic Container Information.
                  • Lifecycle: See Setting Container Lifecycle Parameters.
                  • Health Check: See Setting Health Check for a Container.
                  • Environment Variables: See Setting an Environment Variable.
                  • Data Storage: See Overview.
                    • StatefulSets support dynamically provisioned EVS volumes.

                      Dynamic mounting is achieved by using the volumeClaimTemplates field and depends on the dynamic creation capability of StorageClass. A StatefulSet associates each pod with a unique PVC using the volumeClaimTemplates field, and the PVCs are bound to their corresponding PVs. Therefore, after the pod is rescheduled, the original data can still be mounted thanks to the PVC.

                    • After a workload is created, the storage that is dynamically mounted cannot be updated.
                    @@ -26,7 +26,7 @@

                    You can also create a Service after creating a workload. For details about the Service, see Service Overview.

                    Advanced Settings
                    • Upgrade: See Configuring the Workload Upgrade Policy.
                    • Scheduling: See Scheduling Policy (Affinity/Anti-affinity).
                    • Instances Management Policies

                      For some distributed systems, the StatefulSet sequence is unnecessary and/or should not occur. These systems require only uniqueness and identifiers.

                      • OrderedReady: The StatefulSet will deploy, delete, or scale pods in order and one by one. (The StatefulSet continues only after the previous pod is ready or deleted.) This is the default policy.
                      • Parallel: The StatefulSet will create pods in parallel to match the desired scale without waiting, and will delete all pods at once.
                      -
                    • Toleration: Using both taints and tolerations allows (not forcibly) the pod to be scheduled to a node with the matching taints, and controls the pod eviction policies after the node where the pod is located is tainted. For details, see Tolerations.
                    • Labels and Annotations: See Pod Labels and Annotations.
                    • DNS: See DNS Configuration.
                    +
                  • Toleration: Using both taints and tolerations allows (not forcibly) the pod to be scheduled to a node with the matching taints, and controls the pod eviction policies after the node where the pod is located is tainted. For details, see Tolerations.
                  • Labels and Annotations: See Pod Labels and Annotations.
                  • DNS: See DNS Configuration.

                • Click Create Workload in the lower right corner.
              diff --git a/docs/cce/umn/cce_10_0054.html b/docs/cce/umn/cce_10_0054.html new file mode 100644 index 00000000..4bc4d0d1 --- /dev/null +++ b/docs/cce/umn/cce_10_0054.html @@ -0,0 +1,322 @@ + + +

              High-Risk Operations and Solutions

              +

              During service deployment or running, you may trigger high-risk operations at different levels, causing service faults or interruption. To help you better estimate and avoid operation risks, this section introduces the consequences and solutions of high-risk operations from multiple dimensions, such as clusters, nodes, networking, load balancing, logs, and EVS disks.

              +

              Clusters and Nodes

              +
          Table 2 Parameter description

          Parameter

          Explanation

          +

          Description

          Description

          Extended host path

          Extended host paths contain pod IDs or container names to distinguish different containers into which the host path is mounted.

          -

          A level-3 directory is added to the original volume directory/subdirectory. You can easily obtain the files output by a single Pod.

          -
          • None: No extended path is configured.
          • PodUID: ID of a pod.
          • PodName: name of a pod.
          • PodUID/ContainerName: ID of a pod or name of a container.
          • PodName/ContainerName: name of a pod or container.
          +

          A level-3 directory is added to the original volume directory/subdirectory. You can easily obtain the files output by a single Pod.

          +
          • None: No extended path is configured.
          • PodUID: ID of a pod.
          • PodName: name of a pod.
          • PodUID/ContainerName: ID of a pod or name of a container.
          • PodName/ContainerName: name of a pod or container.

          policy.logs.rotate

          @@ -155,7 +155,7 @@ spec:

          Log dump

          Log dump refers to rotating log files on a local host.

          -
          • Enabled: AOM scans log files every minute. When a log file exceeds 50 MB, it is dumped immediately. A new .zip file is generated in the directory where the log file locates. For a log file, AOM stores only the latest 20 .zip files. When the number of .zip files exceeds 20, earlier .zip files will be deleted. After the dump is complete, the log file in AOM will be cleared.
          • Disabled: AOM does not dump log files.
          +
          • Enabled: AOM scans log files every minute. When a log file exceeds 50 MB, it is dumped immediately. A new .zip file is generated in the directory where the log file locates. For a log file, AOM stores only the latest 20 .zip files. When the number of .zip files exceeds 20, earlier .zip files will be deleted. After the dump is complete, the log file in AOM will be cleared.
          • Disabled: AOM does not dump log files.
          NOTE:
          • AOM rotates log files using copytruncate. Before enabling log dumping, ensure that log files are written in the append mode. Otherwise, file holes may occur.
          • Currently, mainstream log components such as Log4j and Logback support log file rotation. If you have set rotation for log files, skip the configuration. Otherwise, conflicts may occur.
          • You are advised to configure log file rotation for your own services to flexibly control the size and number of rolled files.
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          Table 1 High-risk operations and solutions

          Category

          +

          Operation

          +

          Impact

          +

          Solution

          +

          Master node

          +

          Modifying the security group of a node in a cluster

          +

          The master node may be unavailable.

          +
          NOTE:

          Naming rule of a master node: Cluster name-cce-control-Random number

          +
          +

          Restore the security group by referring to the security group of the new cluster and allow traffic from the security group to pass through.

          +

          Letting the node expire or destroying the node

          +

          The master node will be unavailable.

          +

          This operation cannot be undone.

          +

          Reinstalling the OS

          +

          Components on the master node will be deleted.

          +

          This operation cannot be undone.

          +

          Upgrading components on the master or etcd node

          +

          The cluster may be unavailable.

          +

          Roll back to the original version.

          +

          Deleting or formatting core directory data such as /etc/kubernetes on the node

          +

          The master node will be unavailable.

          +

          This operation cannot be undone.

          +

          Changing the node IP address

          +

          The master node will be unavailable.

          +

          Change the IP address back to the original one.

          +

          Modifying parameters of core components (such as etcd, kube-apiserver, and docker)

          +

          The master node may be unavailable.

          +

          Restore the parameter settings to the recommended values. For details, see Cluster Configuration Management.

          +

          Replacing the master or etcd certificate

          +

          The cluster may become unavailable.

          +

          This operation cannot be undone.

          +

          Worker node

          +

          Modifying the security group of a node in a cluster

          +

          The node may be unavailable.

          +
          NOTE:

          Naming rule of a worker node: Cluster name-cce-node-Random number

          +
          +

          Restore the security group by referring to Creating a CCE Cluster and allow traffic from the security group to pass through.

          +

          Deleting the node

          +

          The node will become unavailable.

          +

          This operation cannot be undone.

          +

          Reinstalling the OS

          +

          Node components are deleted, and the node becomes unavailable.

          +

          Reset the node. For details, see Resetting a Node.

          +

          Upgrading the node kernel

          +

          The node may be unavailable or the network may be abnormal.

          +
          NOTE:

          Node running depends on the system kernel version. Do not use the yum update command to update or reinstall the operating system kernel of a node unless necessary. (Reinstalling the operating system kernel using the original image or other images is a risky operation.)

          +
          +

          For details, see Resetting a Node.

          +

          Changing the node IP address

          +

          The node will become unavailable.

          +

          Change the IP address back to the original one.

          +

          Modifying parameters of core components (such as kubelet and kube-proxy)

          +

          The node may become unavailable, and components may be insecure if security-related configurations are modified.

          +

          Restore the parameter settings to the recommended values. For details, see Configuring a Node Pool.

          +

          Modifying OS configuration

          +

          The node may be unavailable.

          +

          Restore the configuration items or reset the node. For details, see Resetting a Node.

          +

          Deleting or modifying the /opt/cloud/cce and /var/paas directories, and delete the data disk.

          +

          The node will become unready.

          +

          You can reset the node. For details, see Resetting a Node.

          +

          Modifying the node directory permission and the container directory permission

          +

          The permissions will be abnormal.

          +

          You are not advised to modify the permissions. Restore the permissions if they are modified.

          +

          Formatting or partitioning system disks, Docker disks, and kubelet disks on nodes.

          +

          The node may be unavailable.

          +

          You can reset the node. For details, see Resetting a Node.

          +

          Installing other software on nodes

          +

          This may cause exceptions on Kubernetes components installed on the node, and make the node unavailable.

          +

          Uninstall the software that has been installed and restore or reset the node. For details, see Resetting a Node.

          +

          Modifying NetworkManager configurations

          +

          The node will become unavailable.

          +

          Reset the node. For details, see Resetting a Node.

          +

          Delete system images such as cfe-pause from the node.

          +

          Containers cannot be created and system images cannot be pulled.

          +

          Copy the image from another normal node for restoration.

          +
          +
          + +

          Networking and Load Balancing

          +
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          Table 2 High-risk operations and solutions

          Operation

          +

          Impact

          +

          How to Avoid/Fix

          +

          Changing the value of the kernel parameter net.ipv4.ip_forward to 0

          +

          The network becomes inaccessible.

          +

          Change the value to 1.

          +

          Changing the value of the kernel parameter net.ipv4.tcp_tw_recycle to 1

          +

          The NAT service becomes abnormal.

          +

          Change the value to 0.

          +

          Changing the value of the kernel parameter net.ipv4.tcp_tw_reuse to 1

          +

          The network becomes abnormal.

          +

          Change the value to 0.

          +

          Not configuring the node security group to allow UDP packets to pass through port 53 of the container CIDR block

          +

          The DNS in the cluster cannot work properly.

          +

          Restore the security group by referring to Creating a CCE Cluster and allow traffic from the security group to pass through.

          +

          Creating a custom listener on the ELB console for the load balancer managed by CCE

          +

          The modified items are reset by CCE or the ingress is faulty.

          +

          Use the YAML file of the Service to automatically create a listener.

          +

          Binding a user-defined backend on the ELB console to the load balancer managed by CCE.

          +

          Do not manually bind any backend.

          +

          Changing the ELB certificate on the ELB console for the load balancer managed by CCE.

          +

          Use the YAML file of the ingress to automatically manage certificates.

          +

          Changing the listener name on the ELB console for the ELB listener managed by CCE.

          +

          Do not change the name of the ELB listener managed by CCE.

          +

          Changing the description of load balancers, listeners, and forwarding policies managed by CCE on the ELB console.

          +

          Do not modify the description of load balancers, listeners, or forwarding policies managed by CCE.

          +

          Delete CRD resources of network-attachment-definitions of default-network.

          +

          The container network is disconnected, or the cluster fails to be deleted.

          +

          If the resources are deleted by mistake, use the correct configurations to create the default-network resources.

          +
          +
          +
          +

          Logs

          +
          + + + + + + + + + + + + + +
          Table 3 High-risk operations and solutions

          Operation

          +

          Impact

          +

          Solution

          +

          Deleting the /tmp/ccs-log-collector/pos directory on the host machine

          +

          Logs are collected repeatedly.

          +

          None

          +

          Deleting the /tmp/ccs-log-collector/buffer directory of the host machine

          +

          Logs are lost.

          +

          None

          +
          +
          +
          +

          EVS Disks

          +
          + + + + + + + + + + + + + + + + + + + + + +
          Table 4 High-risk operations and solutions

          Operation

          +

          Impact

          +

          Solution

          +

          Remarks

          +

          Manually unmounting an EVS disk on the console

          +

          An I/O error is reported when the pod data is being written into the disk.

          +

          Delete the mount path from the node and schedule the pod again.

          +

          The file in the pod records the location where files are to be collected.

          +

          Unmounting the disk mount path on the node

          +

          Pod data is written into a local disk.

          +

          Remount the corresponding path to the pod.

          +

          The buffer contains log cache files to be consumed.

          +

          Operating EVS disks on the node

          +

          Pod data is written into a local disk.

          +

          None

          +

          None

          +
          +
          +
          + + diff --git a/docs/cce/umn/cce_10_0059.html b/docs/cce/umn/cce_10_0059.html index 0b1f95a4..0152de2d 100644 --- a/docs/cce/umn/cce_10_0059.html +++ b/docs/cce/umn/cce_10_0059.html @@ -1,41 +1,70 @@

          Network Policies

          -

          NetworkPolicy is a Kubernetes object used to restrict pod access. In CCE, by setting network policies, you can define ingress rules specifying the addresses to access pods or egress rules specifying the addresses pods can access. This is equivalent to setting up a firewall at the application layer to further ensure network security.

          -

          Network policies depend on the networking add-on of the cluster to which the policies apply.

          +

          Network policies are designed by Kubernetes to restrict pod access. It is equivalent to a firewall at the application layer to enhance network security. The capabilities supported by network policies depend on the capabilities of the network add-ons of the cluster.

          By default, if a namespace does not have any policy, pods in the namespace accept traffic from any source and send traffic to any destination.

          Network policy rules are classified into the following types:

          • namespaceSelector: selects particular namespaces for which all pods should be allowed as ingress sources or egress destinations.
          • podSelector: selects particular pods in the same namespace as the network policy which should be allowed as ingress sources or egress destinations.
          • ipBlock: selects particular IP blocks to allow as ingress sources or egress destinations. (Only egress rules support IP blocks.)
          -

          Notes and Constraints

          • Only clusters that use the tunnel network model support network policies.
          • Network isolation is not supported for IPv6 addresses.
          • Network policies do not support egress rules except for clusters of v1.23 or later.

            Egress rules are supported only in the following operating systems:

            -
            • EulerOS 2.9: kernel version 4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64
            • CentOS 7.7: kernel version 3.10.0-1062.18.1.el7.x86_64
            • EulerOS 2.5: kernel version 3.10.0-862.14.1.5.h591.eulerosv2r7.x86_64
            -
          • If a cluster is upgraded to v1.23 in in-place mode, you cannot use egress rules because the node OS is not upgraded. In this case, reset the node.
          +

          Notes and Constraints

          • Only clusters that use the tunnel network model support network policies. Network policies are classified into the following types:
            • Ingress: All versions support this type.
            • Egress: Only clusters of v1.23 or later support egress rules.

              Egress rules are supported only in the following OSs:

              + +
              + + + + + + + + + + + + + +

              OS

              +

              Verified Kernel Version

              +

              CentOS

              +

              3.10.0-1062.18.1.el7.x86_64

              +

              3.10.0-1127.19.1.el7.x86_64

              +

              3.10.0-1160.25.1.el7.x86_64

              +

              3.10.0-1160.76.1.el7.x86_64

              +

              EulerOS 2.5

              +

              3.10.0-862.14.1.5.h591.eulerosv2r7.x86_64

              +

              3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64

              +

              EulerOS 2.9

              +

              4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64

              +

              4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64

              +
              -

              Using Ingress Rules

              • Using podSelector to specify the access scope
                apiVersion: networking.k8s.io/v1
+
              +
            • Network isolation is not supported for IPv6 addresses.
            • If a cluster is upgraded to v1.23 in in-place mode, you cannot use egress rules because the node OS is not upgraded. In this case, reset the node.
            +
          +

          Using Ingress Rules

          • Using podSelector to specify the access scope
            apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
   name: test-network-policy
   namespace: default
 spec:
-  podSelector:                  # The rule takes effect for pods with the role=db label.
+  podSelector:                  # The rule takes effect for pods with the role=db label.
     matchLabels:
       role: db
   ingress:                      #This is an ingress rule.
   - from:
-    - podSelector:              #Only traffic from the pods with the role=frontend label is allowed.
+    - podSelector:              #Only traffic from the pods with the "role=frontend" label is allowed.
         matchLabels:
           role: frontend
     ports:                      #Only TCP can be used to access port 6379.
     - protocol: TCP
       port: 6379
            -

            Diagram:

            -
            Figure 1 podSelector
            +

            See the following figure.

            +
            Figure 1 podSelector
          -
          • Using namespaceSelector to specify the access scope
            apiVersion: networking.k8s.io/v1
+
            • Using namespaceSelector to specify the access scope
              apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
   name: test-network-policy
 spec:
-  podSelector:                  # The rule takes effect for pods with the role=db label.
+  podSelector:                  # The rule takes effect for pods with the role=db label.
     matchLabels:
       role: db
   ingress:                      #This is an ingress rule.
@@ -46,8 +75,8 @@ spec:
     ports:                      #Only TCP can be used to access port 6379.
     - protocol: TCP
       port: 6379
              
-
              Figure 2 shows how namespaceSelector selects ingress sources.
              
-
              Figure 2 namespaceSelector
              
+
              See the following figure.
              
+
              Figure 2 namespaceSelector

          Using Egress Rules

          Egress supports not only podSelector and namespaceSelector, but also ipBlock.

          @@ -61,7 +90,7 @@ metadata: spec: policyTypes: # Must be specified for an egress rule. - Egress - podSelector: # The rule takes effect for pods with the role=db label. + podSelector: # The rule takes effect for pods with the role=db label. matchLabels: role: db egress: # Egress rule @@ -69,9 +98,9 @@ spec: - ipBlock: cidr: 172.16.0.16/16 # Allow access to this CIDR block. except: - - 172.16.0.40/32 # This CIDR block cannot be accessed. This value must fall within the range specified by cidr. -

          Diagram:

          -
          Figure 3 ipBlock
          + - 172.16.0.40/32 # This CIDR block cannot be accessed. This value must fall within the range specified by cidr. +

          The following figure shows how to use ingress and egress together.

          +
          Figure 3 ipBlock

          You can define ingress and egress in the same rule.

          apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
@@ -82,7 +111,7 @@ spec:
   policyTypes:
   - Ingress
   - Egress
-  podSelector:                  # The rule takes effect for pods with the role=db label.
+  podSelector:                  # The rule takes effect for pods with the role=db label.
     matchLabels:
       role: db
   ingress:                      # Ingress rule
@@ -95,64 +124,64 @@ spec:
       port: 6379
   egress:                       # Egress rule
   - to:
-    - podSelector:              # Only pods with the role=web label can be accessed.
+    - podSelector:              # Only pods with the role=web label can be accessed.
         matchLabels:
           role: web
          -

          Diagram:

          -
          Figure 4 Using both ingress and egress
          +

          The following figure shows how to use ingress and egress together.

          +
          Figure 4 Using both ingress and egress
          -

          Creating a Network Policy on the Console

          1. Log in to the CCE console and access the cluster console.
          2. Choose Networking in the navigation pane, click the Network Policies tab, and click Create Network Policy in the upper right corner.

            • Policy Name: Specify a network policy name.
            • Namespace: Select a namespace in which the network policy is applied.
            • Selector: Enter a label, select the pod to be associated, and click Add. You can also click Reference Workload Label to reference the label of an existing workload.
            • Inbound Rule: Click to add an inbound rule. For details about parameter settings, see Table 1.

              -
              -
              Table 1 Adding an inbound rule

              Parameter

              +

              Creating a Network Policy on the Console

              1. Log in to the CCE console and access the cluster console.
              2. Choose Networking in the navigation pane, click the Network Policies tab, and click Create Network Policy in the upper right corner.

                • Policy Name: Specify a network policy name.
                • Namespace: Select a namespace in which the network policy is applied.
                • Selector: Enter a label, select the pod to be associated, and click Add. You can also click Reference Workload Label to reference the label of an existing workload.
                • Inbound Rule: Click to add an inbound rule. For details about parameter settings, see Table 1.

                  +
                  +
                  - - - - - - -
                  Table 1 Adding an inbound rule

                  Parameter

                  Description

                  +

                  Description

                  Protocol & Port

                  +

                  Protocol & Port

                  Select the protocol type and port. Currently, TCP and UDP are supported.

                  +

                  Select the protocol type and port. Currently, TCP and UDP are supported.

                  Source Namespace

                  +

                  Source Namespace

                  Select a namespace whose objects can be accessed. If this parameter is not specified, the source object belongs to the same namespace as the current policy.

                  +

                  Select a namespace whose objects can be accessed. If this parameter is not specified, the object belongs to the same namespace as the current policy.

                  Source Pod Label

                  +

                  Source Pod Label

                  Allow access to the pods with this label, if not specified, all pods in the namespace can be accessed.

                  +

                  Allow accessing the pods with this label. If this parameter is not specified, all pods in the namespace can be accessed.
                  -
                • Outbound Rule: Click to add an outbound rule. For details about parameter settings, see Table 1.
                  -
                  Table 2 Adding an outbound rule

                  Parameter

                  +
                • Outbound Rule: Click to add an outbound rule. For details about parameter settings, see Table 1.
                  +
                  - - - - - - - - - diff --git a/docs/cce/umn/cce_10_0063.html b/docs/cce/umn/cce_10_0063.html index 606aaad6..cc6e8c60 100644 --- a/docs/cce/umn/cce_10_0063.html +++ b/docs/cce/umn/cce_10_0063.html @@ -4,7 +4,7 @@

                  Scenario

                  After a node scaling policy is created, you can delete, edit, disable, enable, or clone the policy.

                  Viewing a Node Scaling Policy

                  You can view the associated node pool, rules, and scaling history of a node scaling policy and rectify faults according to the error information displayed.

                  -
                  1. Log in to the CCE console and access the cluster console.
                  2. Choose Node Scaling in the navigation pane and click in front of the policy to be viewed.
                  3. In the expanded area, the Associated Node Pools, Rules, and Scaling History tab pages are displayed. If the policy is abnormal, locate and rectify the fault based on the error information.

                    You can also disable or enable auto scaling on the Node Pools page.

                    +
                    1. Log in to the CCE console and access the cluster console.
                    2. Choose Node Scaling in the navigation pane and click in front of the policy to be viewed.
                    3. In the expanded area, the Associated Node Pools, Rules, and Scaling History tab pages are displayed. If the policy is abnormal, locate and rectify the fault based on the error information.

                      You can also disable or enable auto scaling on the Node Pools page.

                      1. Log in to the CCE console and access the cluster console.
                      2. In the navigation pane, choose Nodes and switch to the Node Pools tab page.
                      3. Click Edit of the node pool to be operated. In the Edit Node Pool dialog box that is displayed, set the limits of the number of nodes.

                    diff --git a/docs/cce/umn/cce_10_0066.html b/docs/cce/umn/cce_10_0066.html index 05b49acb..6c31dbac 100644 --- a/docs/cce/umn/cce_10_0066.html +++ b/docs/cce/umn/cce_10_0066.html @@ -14,6 +14,7 @@
                  +

                • Whether to deploy the add-on instance across multiple AZs.

                  • Preferred: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ.
                  • Required: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run.

                • Set related parameters.

                  In everest 1.2.26 or later, the performance of attaching a large number of EVS volumes is optimized. The following three parameters are provided:
                  • csi_attacher_worker_threads: number of workers that can concurrently mount EVS volumes. The default value is 60.
                  • csi_attacher_detach_worker_threads: number of workers that can concurrently unmount EVS volumes. The default value is 60.
                  • volume_attaching_flow_ctrl: maximum number of EVS volumes that can be mounted by the everest add-on within one minute. The default value is 0, indicating that the EVS volume mounting performance is determined by the underlying storage resources.

                  The preceding three parameters are associated with each other and are constrained by the underlying storage resources in the region where the cluster is located. If you want to mount a large number of volumes (more than 500 EVS volumes per minute), you can contact the customer service personnel and configure the parameters under their guidance to prevent the everest add-on from running abnormally due to improper parameter settings.

                  diff --git a/docs/cce/umn/cce_10_0083.html b/docs/cce/umn/cce_10_0083.html index ab9defe2..68cd8616 100644 --- a/docs/cce/umn/cce_10_0083.html +++ b/docs/cce/umn/cce_10_0083.html @@ -4,7 +4,7 @@

                  Scenario

                  After an HPA policy is created, you can update, clone, edit, and delete the policy, as well as edit the YAML file.

                  Checking an HPA Policy

                  You can view the rules, status, and events of an HPA policy and handle exceptions based on the error information displayed.

                  -
                  1. Log in to the CCE console and access the cluster console.
                  2. In the navigation pane, choose Workload Scaling. On the HPA Policies tab page, click next to the target HPA policy.
                  3. In the expanded area, you can view the Rules, Status, and Events tab pages. If the policy is abnormal, locate and rectify the fault based on the error information.

                    You can also view the created HPA policy on the workload details page.

                    +
                    1. Log in to the CCE console and access the cluster console.
                    2. In the navigation pane, choose Workload Scaling. On the HPA Policies tab page, click next to the target HPA policy.
                    3. In the expanded area, you can view the Rules, Status, and Events tab pages. If the policy is abnormal, locate and rectify the fault based on the error information.

                      You can also view the created HPA policy on the workload details page.

                      1. Log in to the CCE console and access the cluster console.
                      2. In the navigation pane, choose Workloads. Click the workload name to view its details.
                      3. On the workload details page, swich to the Auto Scaling tab page to view the HPA policies. You can also view the scaling policies you configured in Workload Scaling.
                      diff --git a/docs/cce/umn/cce_10_0094.html b/docs/cce/umn/cce_10_0094.html index eb548c61..4b033a72 100644 --- a/docs/cce/umn/cce_10_0094.html +++ b/docs/cce/umn/cce_10_0094.html @@ -3,14 +3,14 @@

                      Ingress Overview

                      Why We Need Ingresses

                      A Service is generally used to forward access requests based on TCP and UDP and provide layer-4 load balancing for clusters. However, in actual scenarios, if there is a large number of HTTP/HTTPS access requests on the application layer, the Service cannot meet the forwarding requirements. Therefore, the Kubernetes cluster provides an HTTP-based access mode, that is, ingress.

                      An ingress is an independent resource in the Kubernetes cluster and defines rules for forwarding external access traffic. As shown in Figure 1, you can customize forwarding rules based on domain names and URLs to implement fine-grained distribution of access traffic.

                      -
                      Figure 1 Ingress diagram
                      +
                      Figure 1 Ingress diagram

                      The following describes the ingress-related definitions:

                      • Ingress object: a set of access rules that forward requests to specified Services based on domain names or URLs. It can be added, deleted, modified, and queried by calling APIs.
                      • Ingress Controller: an executor for request forwarding. It monitors the changes of resource objects such as ingresses, Services, endpoints, secrets (mainly TLS certificates and keys), nodes, and ConfigMaps in real time, parses rules defined by ingresses, and forwards requests to the corresponding backend Services.

                      Working Principle of ELB Ingress Controller

                      ELB Ingress Controller developed by CCE implements layer-7 network access for the internet and intranet (in the same VPC) based on ELB and distributes access traffic to the corresponding Services using different URLs.

                      ELB Ingress Controller is deployed on the master node and bound to the load balancer in the VPC where the cluster resides. Different domain names, ports, and forwarding policies can be configured for the same load balancer (with the same IP address). Figure 2 shows the working principle of ELB Ingress Controller.

                      1. A user creates an ingress object and configures a traffic access rule in the ingress, including the load balancer, URL, SSL, and backend service port.
                      2. When Ingress Controller detects that the ingress object changes, it reconfigures the listener and backend server route on the ELB side according to the traffic access rule.
                      3. When a user accesses a workload, the traffic is forwarded to the corresponding backend service port based on the forwarding policy configured on ELB, and then forwarded to each associated workload through the Service.
                      -
                      Figure 2 Working principle of ELB Ingress Controller
                      +
                      Figure 2 Working principle of ELB Ingress Controller
                      diff --git a/docs/cce/umn/cce_10_0107.html b/docs/cce/umn/cce_10_0107.html index c4a99c05..b99f471b 100644 --- a/docs/cce/umn/cce_10_0107.html +++ b/docs/cce/umn/cce_10_0107.html @@ -12,15 +12,18 @@

                    Download kubectl and the configuration file. Copy the file to your client, and configure kubectl. After the configuration is complete, you can access your Kubernetes clusters. Procedure:

                    -
                    1. Download kubectl.

                      On the Kubernetes release page, click the corresponding link based on the cluster version, click Client Binaries, and download the corresponding platform software package. Alternatively, you can install kubectl with curl following the guide in Install Tools.
                      Figure 1 Downloading kubectl
                      -
                      +
                      1. Download kubectl.

                        Prepare a computer that can access the public network and install kubectl in CLI mode. You can run the kubectl version command to check whether kubectl has been installed. If kubectl has been installed, skip this step.

                        +

                        This section uses the Linux environment as an example to describe how to install and configure kubectl. For details, see Installing kubectl.

                        +
                        1. Log in to your client and download kubectl.
                          cd /home
+curl -LO https://dl.k8s.io/release/{v1.25.0}/bin/linux/amd64/kubectl
                          +

                          {v1.25.0} specifies the version number. Replace it as required.

                          +
                        2. Install kubectl.
                          chmod +x kubectl
+mv -f kubectl /usr/local/bin
                          +

                      2. Obtain the kubectl configuration file (kubeconfig).

                        On the Connection Information pane on the cluster details page, click Learn more next to kubectl. On the window displayed, download the configuration file.

                        • The kubectl configuration file kubeconfig.json is used for cluster authentication. If the file is leaked, your clusters may be attacked.
                        • By default, two-way authentication is disabled for domain names in the current cluster. You can run the kubectl config use-context externalTLSVerify command to enable two-way authentication. For details, see Two-Way Authentication for Domain Names. For a cluster that has been bound to an EIP, if the authentication fails (x509: certificate is valid) when two-way authentication is used, you need to bind the EIP again and download kubeconfig.json again.
                        • The Kubernetes permissions assigned by the configuration file downloaded by IAM users are the same as those assigned to the IAM users on the CCE console.
                        • If the KUBECONFIG environment variable is configured in the Linux OS, kubectl preferentially loads the KUBECONFIG environment variable instead of $home/.kube/config.
                        -

                      3. Configure kubectl.

                        Install and configure kubectl (A Linux OS is used as an example).
                        1. Copy the kubectl downloaded in 1 and the configuration file downloaded in 2 to the /home directory on your client.
                        2. Log in to your client and configure kubectl. If you have installed kubectl, skip this step.
                          cd /home
-chmod +x kubectl
-mv -f kubectl /usr/local/bin
                          -
                        3. Log in to your client and configure the kubeconfig file.
                          cd /home
+
                        4. Configure kubectl.

                          Configure kubectl (A Linux OS is used).
                          1. Log in to your client and copy the kubeconfig.json configuration file downloaded in 2 to the /home directory on your client.
                          2. Configure the kubectl authentication file.
                            cd /home
 mkdir -p $HOME/.kube
 mv -f kubeconfig.json $HOME/.kube/config
                          3. Switch the kubectl access mode based on service scenarios.
                            • Run this command to enable intra-VPC access:
                              kubectl config use-context internal
                              @@ -33,12 +36,16 @@ mv -f kubeconfig.json $HOME/.kube/config

                          Two-Way Authentication for Domain Names

                          Currently, CCE supports two-way authentication for domain names.

                          -
                          • Two-way authentication is disabled for domain names by default. You can run the kubectl config use-context externalTLSVerify command to switch to the externalTLSVerify context to enable it.
                          • When an EIP is bound to or unbound from a cluster, or a custom domain name is configured or updated, the cluster server certificate will be added the latest cluster access address (including the EIP bound to the cluster and all custom domain names configured for the cluster).
                          • Asynchronous cluster synchronization takes about 5 to 10 minutes. You can view the synchronization result in Synchronize Certificate in Operation Records.
                          • For a cluster that has been bound to an EIP, if the authentication fails (x509: certificate is valid) when two-way authentication is used, you need to bind the EIP again and download kubeconfig.json again.
                          • If the domain name two-way authentication is not supported, kubeconfig.json contains the "insecure-skip-tls-verify": true field, as shown in Figure 2. To use two-way authentication, you can download the kubeconfig.json file again and enable two-way authentication for the domain names.
                            Figure 2 Two-way authentication disabled for domain names
                            +
                            • Two-way authentication is disabled for domain names by default. You can run the kubectl config use-context externalTLSVerify command to switch to the externalTLSVerify context to enable it.
                            • When an EIP is bound to or unbound from a cluster, or a custom domain name is configured or updated, the cluster server certificate will be added the latest cluster access address (including the EIP bound to the cluster and all custom domain names configured for the cluster).
                            • Asynchronous cluster synchronization takes about 5 to 10 minutes. You can view the synchronization result in Synchronize Certificate in Operation Records.
                            • For a cluster that has been bound to an EIP, if the authentication fails (x509: certificate is valid) when two-way authentication is used, you need to bind the EIP again and download kubeconfig.json again.
                            • If the domain name two-way authentication is not supported, kubeconfig.json contains the "insecure-skip-tls-verify": true field, as shown in Figure 1. To use two-way authentication, you can download the kubeconfig.json file again and enable two-way authentication for the domain names.
                              Figure 1 Two-way authentication disabled for domain names
                          -

                          Common Issue (Error from server Forbidden)

                          When you use kubectl to create or query Kubernetes resources, the following output is returned:

                          -

                          # kubectl get deploy Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default"

                          +

                          Common Issues

                          • Error from server Forbidden

                            When you use kubectl to create or query Kubernetes resources, the following output is returned:

                            +
                            # kubectl get deploy Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default"

                            The cause is that the user does not have the permissions to operate the Kubernetes resources. For details about how to assign permissions, see Namespace Permissions (Kubernetes RBAC-based).

                            +
                          • The connection to the server localhost:8080 was refused

                            When you use kubectl to create or query Kubernetes resources, the following output is returned:

                            +
                            The connection to the server localhost:8080 was refused - did you specify the right host or port?
                            +

                            The cause is that cluster authentication is not configured for the kubectl client. For details, see 3.

                            +
                          diff --git a/docs/cce/umn/cce_10_0112.html b/docs/cce/umn/cce_10_0112.html index 3634d501..ebd4ffe8 100644 --- a/docs/cce/umn/cce_10_0112.html +++ b/docs/cce/umn/cce_10_0112.html @@ -3,7 +3,7 @@

                          Setting Health Check for a Container

                          Scenario

                          Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application exceptions or automatically restart the application to restore it. This will result in a situation where the pod status is normal but the application in the pod is abnormal.

                          Kubernetes provides the following health check probes:

                          -
                          • Liveness probe (livenessProbe): checks whether a container is still alive. It is similar to the ps command that checks whether a process exists. If the liveness check of a container fails, the cluster restarts the container. If the liveness check is successful, no operation is executed.
                          • Readiness probe (readinessProbe): checks whether a container is ready to process user requests. Upon that the container is detected unready, service traffic will not be directed to the container. It may take a long time for some applications to start up before they can provide services. This is because that they need to load disk data or rely on startup of an external module. In this case, the application process is running, but the application cannot provide services. To address this issue, this health check probe is used. If the container readiness check fails, the cluster masks all requests sent to the container. If the container readiness check is successful, the container can be accessed.
                          • Startup probe (startupProbe): checks when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, ensuring that those probes do not interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are started.
                          +
                          • Liveness probe (livenessProbe): checks whether a container is still alive. It is similar to the ps command that checks whether a process exists. If the liveness check of a container fails, the cluster restarts the container. If the liveness check is successful, no operation is executed.
                          • Readiness probe (readinessProbe): checks whether a container is ready to process user requests. Upon that the container is detected unready, service traffic will not be directed to the container. It may take a long time for some applications to start up before they can provide services. This is because that they need to load disk data or rely on startup of an external module. In this case, the application process is running, but the application cannot provide services. To address this issue, this health check probe is used. If the container readiness check fails, the cluster masks all requests sent to the container. If the container readiness check is successful, the container can be accessed.
                          • Startup probe (startupProbe): checks when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, ensuring that those probes do not interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting terminated by the kubelet before they are started.

                          Check Method

                          • HTTP request

                            This health check mode is applicable to containers that provide HTTP/HTTPS services. The cluster periodically initiates an HTTP/HTTPS GET request to such containers. If the return code of the HTTP/HTTPS response is within 200–399, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port and an HTTP/HTTPS request path.

                            For example, for a container that provides HTTP services, the HTTP check path is /health-check, the port is 80, and the host address is optional (which defaults to the container IP address). Here, 172.16.0.186 is used as an example, and we can get such a request: GET http://172.16.0.186:80/health-check. The cluster periodically initiates this request to the container. You can also add one or more headers to an HTTP request. For example, set the request header name to Custom-Header and the corresponding value to example.

                            @@ -11,9 +11,9 @@

                            For example, if you have a Nginx container with service port 80, after you specify TCP port 80 for container listening, the cluster will periodically initiate a TCP connection to port 80 of the container. If the connection is successful, the probe is successful. Otherwise, the probe fails.

                          • CLI

                            CLI is an efficient tool for health check. When using the CLI, you must specify an executable command in a container. The cluster periodically runs the command in the container. If the command output is 0, the health check is successful. Otherwise, the health check fails.

                            The CLI mode can be used to replace the HTTP request-based and TCP port-based health check.

                            -
                            • For a TCP port, you can write a program script to connect to a container port. If the connection is successful, the script returns 0. Otherwise, the script returns –1.
                            • For an HTTP request, you can write a program script to run the wget command for a container.

                              wget http://127.0.0.1:80/health-check

                              +
                              • For a TCP port, you can use a program script to connect to a container port. If the connection is successful, the script returns 0. Otherwise, the script returns –1.
                              • For an HTTP request, you can use the script command to run the wget command to detect the container.

                                wget http://127.0.0.1:80/health-check

                                Check the return code of the response. If the return code is within 200–399, the script returns 0. Otherwise, the script returns –1.

                                -
                                • Put the program to be executed in the container image so that the program can be executed.
                                • If the command to be executed is a shell script, do not directly specify the script as the command, but add a script parser. For example, if the script is /data/scripts/health_check.sh, you must specify sh/data/scripts/health_check.sh for command execution. The reason is that the cluster is not in the terminal environment when executing programs in a container.
                                +
                                • Put the program to be executed in the container image so that the program can be executed.
                                • If the command to be executed is a shell script, do not directly specify the script as the command, but add a script parser. For example, if the script is /data/scripts/health_check.sh, you must specify sh/data/scripts/health_check.sh for command execution. The reason is that the cluster is not in the terminal environment when executing programs in a container.
                            • gRPC Check
                              gRPC checks can configure startup, liveness, and readiness probes for your gRPC application without exposing any HTTP endpoint, nor do you need an executable. Kubernetes can connect to your workload via gRPC and query its status.
                              • The gRPC check is supported only in CCE clusters of v1.25 or later.
                              • To use gRPC for check, your application must support the gRPC health checking protocol.
                              • Similar to HTTP and TCP probes, if the port is incorrect or the application does not support the health checking protocol, the check fails.
                              diff --git a/docs/cce/umn/cce_10_0113.html b/docs/cce/umn/cce_10_0113.html index c8a6d5fe..95bcbc99 100644 --- a/docs/cce/umn/cce_10_0113.html +++ b/docs/cce/umn/cce_10_0113.html @@ -9,7 +9,7 @@

                              Environment variables can be set in the following modes:

                              • Custom
                              • Added from ConfigMap: Import all keys in a ConfigMap as environment variables.
                              • Added from ConfigMap key: Import a key in a ConfigMap as the value of an environment variable. For example, if you import configmap_value of configmap_key in a ConfigMap as the value of environment variable key1, an environment variable named key1 with its value is configmap_value exists in the container.
                              • Added from secret: Import all keys in a secret as environment variables.
                              • Added from secret key: Import the value of a key in a secret as the value of an environment variable. For example, if you import secret_value of secret_key in secret secret-example as the value of environment variable key2, an environment variable named key2 with its value secret_value exists in the container.
                              • Variable value/reference: Use the field defined by a pod as the value of the environment variable, for example, the pod name.
                              • Resource Reference: Use the field defined by a container as the value of the environment variable, for example, the CPU limit of the container.
                              -

                              Adding Environment Variables

                              1. Log in to the CCE console. When creating a workload, select Environment Variables under Container Settings.
                              2. Set environment variables.

                                +

                                Adding Environment Variables

                                1. Log in to the CCE console. When creating a workload, select Environment Variables under Container Settings.
                                2. Set environment variables.

                                YAML Example

                                apiVersion: apps/v1
diff --git a/docs/cce/umn/cce_10_0129.html b/docs/cce/umn/cce_10_0129.html
index 5f1cac2e..f2835375 100644
--- a/docs/cce/umn/cce_10_0129.html
+++ b/docs/cce/umn/cce_10_0129.html
@@ -31,6 +31,11 @@
                  • + + +
                  Table 2 Adding an outbound rule

                  Parameter

                  Description

                  +

                  Description

                  Protocol & Port

                  +

                  Protocol & Port

                  Select the protocol type and port. Currently, TCP and UDP are supported. If this parameter is not specified, the protocol type is not limited.

                  +

                  Select the protocol type and port. Currently, TCP and UDP are supported. If this parameter is not specified, the protocol type is not limited.

                  Destination CIDR Block

                  +

                  Destination CIDR Block

                  Allows requests to be routed to a specified CIDR block (and not to the exception CIDR blocks). Separate the destination and exception CIDR blocks by vertical bars (|), and separate multiple exception CIDR blocks by commas (,). For example, 172.17.0.0/16|172.17.1.0/24,172.17.2.0/24 indicates that 172.17.0.0/16 is accessible, but not for 172.17.1.0/24 or 172.17.2.0/24.

                  +

                  Allows requests to be routed to a specified CIDR block (and not to the exception CIDR blocks). Separate the destination and exception CIDR blocks by vertical bars (|), and separate multiple exception CIDR blocks by commas (,). For example, 172.17.0.0/16|172.17.1.0/24,172.17.2.0/24 indicates that 172.17.0.0/16 is accessible, but not for 172.17.1.0/24 or 172.17.2.0/24.

                  Destination Namespace

                  +

                  Destination Namespace

                  Select a namespace whose objects can be accessed. If this parameter is not specified, the source object belongs to the same namespace as the current policy.

                  +

                  Select a namespace whose objects can be accessed. If this parameter is not specified, the object belongs to the same namespace as the current policy.

                  Destination Pod Label

                  +

                  Destination Pod Label

                  Allow access to the pods with this label, if not specified, all pods in the namespace can be accessed.

                  +

                  Allow accessing the pods with this label. If this parameter is not specified, all pods in the namespace can be accessed.

                  Number of pods that will be created to match the selected add-on specifications.

                  Multi AZ

                  +
                  • Preferred: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ.
                  • Required: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run.
                  +

                  Containers

                  CPU and memory quotas of the container allowed for the selected add-on specifications.

                  @@ -39,7 +44,7 @@

                  Parameters
                  • parameterSyncStrategy: indicates whether to configure consistency check when an add-on is upgraded.
                    • ensureConsistent: indicates that the configuration consistency check is enabled. If the configuration recorded in the cluster is inconsistent with the actual configuration, the add-on cannot be upgraded.
                    • force: indicates that the configuration consistency check is ignored during an upgrade. Ensure that the current effective configuration is the same as the original configuration. After the add-on is upgraded, restore the value of parameterSyncStrategy to ensureConsistent and enable the configuration consistency check again.
                    -
                  • stub_domains: A domain name server for a user-defined domain name. The format is a key-value pair. The key is a suffix of DNS domain name, and the value is one or more DNS IP addresses.
                  • upstream_nameservers: IP address of the upstream DNS server.
                  • servers: The servers configuration is available since coredns 1.23.1. You can customize the servers configuration. For details, see dns-custom-nameservers. plugins indicates the configuration of each component in coredns (https://coredns.io/manual/plugins/). You are advised to retain the default configurations in common scenarios to prevent CoreDNS from being unavailable due to configuration errors. Each plugin component contains name, parameters (optional), and configBlock (optional). The format of the generated Corefile is as follows:

                    $name $parameters {

                    +
                  • stub_domains: A domain name server for a user-defined domain name. The format is a key-value pair. The key is a suffix of DNS domain name, and the value is one or more DNS IP addresses.
                  • upstream_nameservers: IP address of the upstream DNS server.
                  • servers: The servers configuration is available since coredns 1.23.1. You can customize the servers configuration. For details, see dns-custom-nameservers. plugins indicates the configuration of each component in coredns (https://coredns.io/manual/plugins/). You are advised to retain the default configurations in common scenarios to prevent CoreDNS from being unavailable due to configuration errors. Each plugin component contains name, parameters (optional), and configBlock (optional). The format of the generated Corefile is as follows:

                    $name $parameters {

                    $configBlock

                    }

                    Table 2 describes common plugins.

                    @@ -178,7 +183,7 @@
                    1. The query is first sent to the DNS caching layer in coredns.
                    2. From the caching layer, the suffix of the request is examined and then the request is forwarded to the corresponding DNS:
                      • Names with the cluster suffix, for example, .cluster.local: The request is sent to coredns.
                      • Names with the stub domain suffix, for example, .acme.local: The request is sent to the configured custom DNS resolver that listens, for example, on 1.2.3.4.
                      • Names that do not match the suffix (for example, widget.com): The request is forwarded to the upstream DNS.
                    -
                    Figure 1 Routing
                    +
                    Figure 1 Routing
                    diff --git a/docs/cce/umn/cce_10_0132.html b/docs/cce/umn/cce_10_0132.html index 6e6ab49e..4e752a09 100644 --- a/docs/cce/umn/cce_10_0132.html +++ b/docs/cce/umn/cce_10_0132.html @@ -1,330 +1,373 @@

                    npd

                    -

                    Introduction

                    node-problem-detector (npd for short) is an add-on that monitors abnormal events of cluster nodes and connects to a third-party monitoring platform. It is a daemon running on each node. It collects node issues from different daemons and reports them to the API server. The npd add-on can run as a DaemonSet or a daemon.

                    -

                    For more information, see node-problem-detector.

                    +

                    Introduction

                    node-problem-detector (npd for short) is an add-on that monitors abnormal events of cluster nodes and connects to a third-party monitoring platform. It is a daemon running on each node. It collects node issues from different daemons and reports them to the API server. The npd add-on can run as a DaemonSet or a daemon.

                    +

                    For more information, see node-problem-detector.

                    -

                    Notes and Constraints

                    • When using this add-on, do not format or partition node disks.
                    • Each npd process occupies 30 mCPU and 100 MB memory.
                    +

                    Notes and Constraints

                    • When using this add-on, do not format or partition node disks.
                    • Each npd process occupies 30 mCPU and 100 MB memory.
                    -

                    Permission Description

                    To monitor kernel logs, the npd add-on needs to read the host /dev/kmsg. Therefore, the privileged mode must be enabled. For details, see privileged.

                    -

                    In addition, CCE mitigates risks according to the least privilege principle. Only the following privileges are available for npd running:

                    -
                    • cap_dac_read_search: permission to access /run/log/journal.
                    • cap_sys_admin: permission to access /dev/kmsg.
                    +

                    Permission Description

                    To monitor kernel logs, the npd add-on needs to read the host /dev/kmsg. Therefore, the privileged mode must be enabled. For details, see privileged.

                    +

                    In addition, CCE mitigates risks according to the least privilege principle. Only the following privileges are available for npd running:

                    +
                    • cap_dac_read_search: permission to access /run/log/journal.
                    • cap_sys_admin: permission to access /dev/kmsg.
                    -

                    Installing the Add-on

                    1. Log in to the CCE console, click the cluster name, and access the cluster console. Choose Add-ons in the navigation pane, locate npd on the right, and click Install.
                    2. On the Install Add-on page, select the add-on specifications and set related parameters.

                      • Pods: Set the number of pods based on service requirements.
                      • Containers: Select a proper container quota based on service requirements.
                      -

                    3. Set the parameters according to the following table and click Install.

                      Only 1.16.0 and later versions support the configurations.

                      -

                      npc.enable: indicates whether to enable Node-problem-controller.

                      +

                      Installing the Add-on

                      1. Log in to the CCE console and access the cluster console. Choose Add-ons in the navigation pane, locate npd on the right, and click Install.
                      2. On the Install Add-on page, select the add-on specifications and set related parameters.

                        • Pods: Set the number of pods based on service requirements.
                        • Containers: Select a proper container quota based on service requirements.
                        +

                      3. Set the npd parameters and click Install.

                        The parameters are configurable only in 1.16.0 and later versions. For details, see Table 7.

                      -

                      npd Check Items

                      Check items are supported only in 1.16.0 and later versions.

                      +

                      npd Check Items

                      Check items are supported only in 1.16.0 and later versions.

                      -

                      Check items cover events and statuses.

                      -
                      • Event-related

                        For event-related check items, when a problem occurs, npd reports an event to the API server. The event type can be Normal (normal event) or Warning (abnormal event).

                        +

                        Check items cover events and statuses.

                        +
                        • Event-related

                          For event-related check items, when a problem occurs, npd reports an event to the API server. The event type can be Normal (normal event) or Warning (abnormal event).

                          -
                          Table 1 Event-related check items

                          Check Item

                          +
                          - - - - - - - - - - - - - - -
                          Table 1 Event-related check items

                          Check Item

                          Function

                          +

                          Function

                          Description

                          +

                          Description

                          OOMKilling

                          +

                          OOMKilling

                          Check whether OOM events occur and are reported.

                          +

                          Listen to the kernel logs and check whether OOM events occur and are reported.

                          +

                          Typical scenario: When the memory usage of a process in a container exceeds the limit, OOM is triggered and the process is terminated.

                          Warning event

                          +

                          Warning event

                          +

                          Listening object: /dev/kmsg

                          +

                          Matching rule: "Killed process \\d+ (.+) total-vm:\\d+kB, anon-rss:\\d+kB, file-rss:\\d+kB.*"

                          TaskHung

                          +

                          TaskHung

                          Check whether taskHung events occur and are reported.

                          +

                          Listen to the kernel logs and check whether taskHung events occur and are reported.

                          +

                          Typical scenario: Disk I/O suspension causes process suspension.

                          Warning event

                          +

                          Warning event

                          +

                          Listening object: /dev/kmsg

                          +

                          Matching rule: "task \\S+:\\w+ blocked for more than \\w+ seconds\\."

                          KernelOops

                          +

                          ReadonlyFilesystem

                          Check kernel nil pointer panic errors.

                          +

                          Check whether the Remount root filesystem read-only error occurs in the system kernel by listening to the kernel logs.

                          +

                          Typical scenario: A user detaches a data disk from a node by mistake on the ECS, and applications continuously write data to the mount point of the data disk. As a result, an I/O error occurs in the kernel and the disk is remounted as a read-only disk.

                          Warning event

                          -

                          ConntrackFull

                          -

                          Check whether the conntrack table is full.

                          -

                          Warning event

                          -

                          Interval: 30 seconds

                          -

                          Threshold: 80%

                          +

                          Warning event

                          +

                          Listening object: /dev/kmsg

                          +

                          Matching rule: Remounting filesystem read-only
                          -
                        • Status-related

                          For status-related check items, when a problem occurs, npd reports an event to the API server and changes the node status synchronously. This function can be used together with Node-problem-controller fault isolation to isolate nodes.

                          -

                          If the check period is not specified in the following check items, the default period is 30 seconds.

                          +
                        • Status-related

                          For status-related check items, when a problem occurs, npd reports an event to the API server and changes the node status synchronously. This function can be used together with Node-problem-controller fault isolation to isolate nodes.

                          +

                          If the check period is not specified in the following check items, the default period is 30 seconds.

                          -
                          Table 2 Application and OS check items

                          Check Item

                          +
                          - - - - - - - + - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                          Table 2 Checking system components

                          Check Item

                          Function

                          +

                          Function

                          Description

                          +

                          Description

                          FrequentKubeletRestart

                          +

                          Container network component error

                          +

                          CNIProblem

                          Check whether kubelet restarts frequently by listening to journald logs.

                          +

                          Check the status of the CNI components (container network components).

                          • Interval: 5 minutes
                          • Backtracking: 10 minutes
                          • Threshold: 10 times

                            If the system restarts for 10 times within the backtracking period, it indicates that the system restarts frequently and a fault alarm is generated.

                            -
                          • Listening object: logs in the /run/log/journal directory
                          -
                          NOTE:

                          The Ubuntu OS does not support the preceding check items due to incompatible log formats.

                          -
                          +

                          None

                          FrequentDockerRestart

                          +

                          Container runtime component error

                          +

                          CRIProblem

                          Check whether Docker restarts frequently by listening to journald logs.

                          +

                          Check the status of Docker and containerd of the CRI components (container runtime components).

                          +

                          Check object: Docker or containerd

                          FrequentContainerdRestart

                          +

                          Frequent restarts of Kubelet

                          +

                          FrequentKubeletRestart

                          Check whether containerd restarts frequently by listening to journald logs.

                          +

                          Periodically backtrack system logs to check whether the key component Kubelet restarts frequently.

                          +
                          • Default threshold: 10 restarts within 10 minutes

                            If Kubelet restarts for 10 times within 10 minutes, it indicates that the system restarts frequently and a fault alarm is generated.

                            +
                          • Listening object: logs in the /run/log/journal directory

                          CRIProblem

                          +

                          Frequent restarts of Docker

                          +

                          FrequentDockerRestart

                          Check the CRI component status.

                          -

                          Check object: Docker or containerd

                          +

                          Periodically backtrack system logs to check whether the container runtime Docker restarts frequently.

                          KUBELETProblem

                          +

                          Frequent restarts of containerd

                          +

                          FrequentContainerdRestart

                          Check the kubelet status.

                          -

                          None

                          +

                          Periodically backtrack system logs to check whether the container runtime containerd restarts frequently.

                          NTPProblem

                          +

                          kubelet error

                          +

                          KubeletProblem

                          Check the NTP and Chrony service status.

                          -

                          Check whether the node clock offsets.

                          +

                          Check the status of the key component Kubelet.

                          Threshold of the clock offset: 8000 ms

                          +

                          None

                          PIDProblem

                          +

                          kube-proxy error

                          +

                          KubeProxyProblem

                          Check whether PIDs are sufficient.

                          +

                          Check the status of the key component kube-proxy.

                          • Threshold: 90%
                          • Usage: nr_threads in /proc/loadavg
                          • Maximum value: smaller value between /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max.
                          -

                          FDProblem

                          -

                          Check whether file handles are sufficient.

                          -
                          • Threshold: 90%
                          • Usage: the first value in /proc/sys/fs/file-nr
                          • Maximum value: the third value in /proc/sys/fs/file-nr
                          -

                          MemoryProblem

                          -

                          Check whether the overall node memory is sufficient.

                          -
                          • Threshold: 90%
                          • Usage: MemTotal-MemAvailable in /proc/meminfo
                          • Maximum value: MemTotal in /proc/meminfo
                          -

                          ResolvConfFileProblem

                          -

                          Check whether the ResolvConf file is lost.

                          -

                          Check whether the ResolvConf file is normal.

                          -

                          Exception definition: No upstream domain name resolution server (nameserver) is included.

                          -

                          Object: /etc/resolv.conf

                          -

                          ProcessD

                          -

                          Check whether there is a process D on the node.

                          -

                          Source:

                          -
                          • /proc/{PID}/stat
                          • Alternately, you can run ps aux.
                          -

                          Exception scenario: ProcessD ignores the resident processes (heartbeat and update) that are in the D state that the SDI driver on the BMS node depends on.

                          -

                          ProcessZ

                          -

                          Check whether the node has processes in Z state.

                          -

                          ScheduledEvent

                          -

                          Check whether host plan events exist on the node.

                          -

                          Typical scenario: The host is faulty, for example, the fan is damaged or the disk has bad sectors. As a result, cold and live migration is triggered for VMs.

                          -

                          Source:

                          -
                          • http://169.254.169.254/meta-data/latest/events/scheduled
                          -

                          This check item is an Alpha feature and is disabled by default.

                          +

                          None
                          -
                          Table 3 Network connection check items

                          Check Item

                          +
                          - - - - - - - - - - -
                          Table 3 Checking system metrics

                          Check Item

                          Function

                          +

                          Function

                          Description

                          +

                          Description

                          CNIProblem

                          +

                          Conntrack table full

                          +

                          ConntrackFullProblem

                          Check whether the CNI component is running properly.

                          +

                          Check whether the conntrack table is full.

                          None

                          +
                          • Default threshold: 90%
                          +
                          • Usage: nf_conntrack_count
                          • Maximum value: nf_conntrack_max

                          KUBEPROXYProblem

                          +

                          Insufficient disk resources

                          +

                          DiskProblem

                          Check whether kube-proxy is running properly.

                          +

                          Check the usage of the system disk and CCE data disks (including the CRI logical disk and kubelet logical disk) on the node.

                          None

                          -
                          -
                          - -
                          - - - - - - - - - - - - - - - - - - - - + - - - - - - +
                          Table 4 Storage check items

                          Check Item

                          -

                          Function

                          -

                          Description

                          -

                          ReadonlyFilesystem

                          -

                          Check whether the Remount root filesystem read-only error occurs in the system kernel by listening to the kernel logs.

                          -

                          Typical scenario: A user detaches a data disk from a node by mistake on the ECS, and applications continuously write data to the mount point of the data disk. As a result, an I/O error occurs in the kernel and the disk is reattached as a read-only disk.

                          -

                          Listening object: /dev/kmsg

                          -

                          Matching rule: Remounting filesystem read-only

                          -

                          DiskReadonly

                          -

                          Check whether the system disk, Docker disk, and kubelet disk are read-only.

                          -

                          Detection paths:

                          -
                          • /mnt/paas/kubernetes/kubelet/
                          • /var/lib/docker/
                          • /var/lib/containerd/
                          • /var/paas/sys/log/cceaddon-npd/
                          -

                          The temporary file npd-disk-write-ping is generated in the detection path.

                          -

                          Currently, additional data disks are not supported.

                          -

                          DiskProblem

                          -

                          Check the usage of the system disk, Docker disk, and kubelet disk.

                          -

                          -
                          • Threshold: 80%
                          • Source:
                            df -h
                            +
                          • Default threshold: 90%
                          • Source:
                            df -h
                          -

                          Currently, additional data disks are not supported.

                          +

                          Currently, additional data disks are not supported.

                          EmptyDirVolumeGroupStatusError

                          +

                          Insufficient file handles

                          +

                          FDProblem

                          Check whether the ephemeral volume group on the node is normal.

                          -

                          Impact: The pod that depends on the storage pool cannot write data to the temporary volume. The temporary volume is remounted as a read-only file system by the kernel due to an I/O error.

                          -

                          Typical scenario: When creating a node, a user configures two data disks as a temporary volume storage pool. The user deletes some data disks by mistake. As a result, the storage pool becomes abnormal.

                          +

                          Check whether FD file handles are used up.

                          • Detection period: 60s
                          • Source:
                            vgs -o vg_name, vg_attr
                            -
                          • Principle: Check whether the VG (storage pool) is in the P state. If yes, some PVs (data disks) are lost.
                          • Joint scheduling: The scheduler can automatically identify an abnormal node and prevent pods that depend on the storage pool from being scheduled to the node.
                          • Exception scenario: The npd add-on cannot detect the loss of all PVs (data disks), resulting in the loss of VGs (storage pools). In this case, kubelet automatically isolates the node, detects the loss of VGs (storage pools), and updates the corresponding resources in nodestatus.allocatable to 0. This prevents pods that depend on the storage pool from being scheduled to the node. The damage of a single PV cannot be detected. In this case, the ReadonlyFilesystem detection is abnormal.
                          +
                          • Default threshold: 90%
                          • Usage: the first value in /proc/sys/fs/file-nr
                          • Maximum value: the third value in /proc/sys/fs/file-nr

                          LocalPvVolumeGroupStatusError

                          +

                          Insufficient node memory

                          +

                          MemoryProblem

                          Check the PV group on the node.

                          -

                          Impact: Pods that depend on the storage pool cannot write data to the persistent volume. The persistent volume is remounted as a read-only file system by the kernel due to an I/O error.

                          -

                          Typical scenario: When creating a node, a user configures two data disks as a persistent volume storage pool. Some data disks are deleted by mistake.

                          +

                          Check whether memory is used up.

                          +
                          • Default threshold: 80%
                          • Usage: MemTotal-MemAvailable in /proc/meminfo
                          • Maximum value: MemTotal in /proc/meminfo

                          MountPointProblem

                          +

                          Insufficient process resources

                          +

                          PIDProblem

                          Check the mount point on the node.

                          -

                          Exception definition: You cannot access the mount point by running the cd command.

                          -

                          Typical scenario: Network File System (NFS), for example, obsfs and s3fs is mounted to a node. When the connection is abnormal due to network or peer NFS server exceptions, all processes that access the mount point are suspended. For example, during a cluster upgrade, a kubelet is restarted, and all mount points are scanned. If the abnormal mount point is detected, the upgrade fails.

                          +

                          Check whether PID process resources are exhausted.

                          Alternatively, you can run the following command:

                          -
                          for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok"
                          +
                          • Default threshold: 90%
                          • Usage: nr_threads in /proc/loadavg
                          • Maximum value: smaller value between /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max.

                          DiskHung

                          -

                          Check whether I/O faults occur on the disk of the node.

                          -

                          Definition of I/O faults: The system does not respond to disk I/O requests, and some processes are in the D state.

                          -

                          Typical Scenario: Disks cannot respond due to abnormal OS hard disk drivers or severe faults on the underlying network.

                          -
                          • Check object: all data disks
                          • Source:

                            /proc/diskstat

                            -
                            Alternatively, you can run the following command:
                            iostat -xmt 1
                            +
                          -
                        • Threshold:
                          • Average usage. The value of ioutil is greater than or equal to 0.99.
                          • Average I/O queue length. avgqu-sz >=1
                          • Average I/O transfer volume, iops (w/s) + ioth (wMB/s) < = 1
                          -
                          NOTE:

                          In some OSs, no data changes during I/O. In this case, calculate the CPU I/O time usage. The value of iowait is greater than 0.8.

                          + +
                          + + + + + + + + + + + + + + + + + + + + + + + + + + - - -
                          Table 4 Checking the storage

                          Check Item

                          +

                          Function

                          +

                          Description

                          +

                          Disk read-only

                          +

                          DiskReadonly

                          +

                          Periodically perform read and write tests on the system disk and CCE data disks (including the CRI logical disk and Kubelet logical disk) of the node to check the availability of key disks.

                          +

                          Detection paths:

                          +
                          • /mnt/paas/kubernetes/kubelet/
                          • /var/lib/docker/
                          • /var/lib/containerd/
                          • /var/paas/sys/log/cceaddon-npd/
                          +

                          The temporary file npd-disk-write-ping is generated in the detection path.

                          +

                          Currently, additional data disks are not supported.

                          +

                          Insufficient disk resources

                          +

                          DiskProblem

                          +

                          Check the usage of the system disk and CCE data disks (including the CRI logical disk and kubelet logical disk) on the node.

                          +

                          +
                          • Default threshold: 90%
                          • Source:
                            df -h
                            +
                          +

                          Currently, additional data disks are not supported.

                          +

                          emptyDir storage pool error

                          +

                          EmptyDirVolumeGroupStatusError

                          +

                          Check whether the ephemeral volume group on the node is normal.

                          +

                          Impact: The pod that depends on the storage pool cannot write data to the temporary volume. The temporary volume is remounted as a read-only file system by the kernel due to an I/O error.

                          +

                          Typical scenario: When creating a node, a user configures two data disks as a temporary volume storage pool. The user deletes some data disks by mistake. As a result, the storage pool becomes abnormal.

                          +
                          • Detection period: 30s
                          • Source:
                            vgs -o vg_name, vg_attr
                            +
                          • Principle: Check whether the VG (storage pool) is in the P state. If yes, some PVs (data disks) are lost.
                          • Joint scheduling: The scheduler can automatically identify a PV storage pool error and prevent pods that depend on the storage pool from being scheduled to the node.
                          • Exceptional scenario: The npd add-on cannot detect the loss of all PVs (data disks), resulting in the loss of VGs (storage pools). In this case, kubelet automatically isolates the node, detects the loss of VGs (storage pools), and updates the corresponding resources in nodestatus.allocatable to 0. This prevents pods that depend on the storage pool from being scheduled to the node. The damage of a single PV cannot be detected by this check item, but by the ReadonlyFilesystem check item.
                          +

                          PV storage pool error

                          +

                          LocalPvVolumeGroupStatusError

                          +

                          Check the PV group on the node.

                          +

                          Impact: Pods that depend on the storage pool cannot write data to the persistent volume. The persistent volume is remounted as a read-only file system by the kernel due to an I/O error.

                          +

                          Typical scenario: When creating a node, a user configures two data disks as a persistent volume storage pool. Some data disks are deleted by mistake.

                          +

                          Mount point error

                          +

                          MountPointProblem

                          +

                          Check the mount point on the node.

                          +

                          Exceptional definition: You cannot access the mount point by running the cd command.

                          +

                          Typical scenario: Network File System (NFS), for example, obsfs and s3fs is mounted to a node. When the connection is abnormal due to network or peer NFS server exceptions, all processes that access the mount point are suspended. For example, during a cluster upgrade, a kubelet is restarted, and all mount points are scanned. If the abnormal mount point is detected, the upgrade fails.

                          +

                          Alternatively, you can run the following command:

                          +
                          for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok"
                          +

                          Suspended disk I/O

                          +

                          DiskHung

                          +

                          Check whether I/O suspension occurs on all disks on the node, that is, whether I/O read and write operations are not responded.

                          +

                          Definition of I/O suspension: The system does not respond to disk I/O requests, and some processes are in the D state.

                          +

                          Typical scenario: Disks cannot respond due to abnormal OS hard disk drivers or severe faults on the underlying network.

                          +
                          • Check object: all data disks
                          • Source:

                            /proc/diskstat

                            +
                            Alternatively, you can run the following command:
                            iostat -xmt 1
                            +
                            +
                          • Threshold:
                            • Average usage: ioutil >= 0.99
                            • Average I/O queue length: avgqu-sz >= 1
                            • Average I/O transfer volume: iops (w/s) + ioth (wMB/s) <= 1
                            +
                            NOTE:

                            In some OSs, no data changes during I/O. In this case, calculate the CPU I/O time usage. The value of iowait should be greater than 0.8.

                          DiskSlow

                          +

                          Slow disk I/O

                          +

                          DiskSlow

                          Check whether slow I/O occurs on the disk of the node.

                          -

                          Definition of slow I/O: The average response time exceeds the threshold.

                          -

                          Typical scenario: EVS disks have slow I/Os due to network fluctuation.

                          +

                          Check whether all disks on the node have slow I/Os, that is, whether I/Os respond slowly.

                          +

                          Typical scenario: EVS disks have slow I/Os due to network fluctuation.

                          • Check object: all data disks
                          • Source:

                            /proc/diskstat

                            -
                            Alternatively, you can run the following command:
                            iostat -xmt 1
                            +
                          • Check object: all data disks
                          • Source:

                            /proc/diskstat

                            +
                            Alternatively, you can run the following command:
                            iostat -xmt 1
                            -
                          • Threshold:

                            Average I/O latency: await > = 5000 ms

                            +
                          • Default threshold:

                            Average I/O latency: await >= 5000 ms

                          -
                          NOTE:

                          If I/O requests are not responded and the await data is not updated. In this case, this check item is invalid.

                          +
                          NOTE:

                          If I/O requests are not responded and the await data is not updated, this check item is invalid.
                          -

                          The kubelet component has the following default check items, which have bugs or defects. You can fix them by upgrading the cluster or using npd.

                          -
                          Table 5 Default kubelet check items

                          Check Item

                          +
                          - - - - - - - - - - - + + + + + + + + + +
                          Table 5 Other check items

                          Check Item

                          Function

                          +

                          Function

                          Description

                          +

                          Description

                          PIDPressure

                          +

                          Abnormal NTP

                          +

                          NTPProblem

                          Check whether PIDs are sufficient.

                          +

                          Check whether the node clock synchronization service ntpd or chronyd is running properly and whether a system time drift is caused.

                          • Interval: 10 seconds
                          • Threshold: 90%
                          • Defect: In community version 1.23.1 and earlier versions, this check item becomes invalid when over 65535 PIDs are used. For details, see issue 107107. In community version 1.24 and earlier versions, thread-max is not considered in this check item.
                          +

                          Default clock offset threshold: 8000 ms

                          MemoryPressure

                          +

                          Process D error

                          +

                          ProcessD

                          Check whether the allocable memory for the containers is sufficient.

                          +

                          Check whether there is a process D on the node.

                          • Interval: 10 seconds
                          • Threshold: Max. 100 MiB
                          • Allocable = Total memory of a node – Reserved memory of a node
                          • Defect: This check item checks only the memory consumed by containers, and does not consider that consumed by other elements on the node.
                          +

                          Default threshold: 10 abnormal processes detected for three consecutive times

                          +

                          Source:

                          +
                          • /proc/{PID}/stat
                          • Alternately, you can run the ps aux command.
                          +

                          Exceptional scenario: ProcessD ignores the resident D processes (heartbeat and update) on which the SDI driver on the BMS node depends.

                          +

                          DiskPressure

                          +

                          Process Z error

                          +

                          ProcessZ

                          Check the disk usage and inodes usage of the kubelet and Docker disks.

                          +

                          Check whether the node has processes in Z state.

                          Interval: 10 seconds

                          -

                          Threshold: 90%

                          +

                          ResolvConf error

                          +

                          ResolvConfFileProblem

                          +

                          Check whether the ResolvConf file is lost.

                          +

                          Check whether the ResolvConf file is normal.

                          +

                          Exceptional definition: No upstream domain name resolution server (nameserver) is included.

                          +

                          Object: /etc/resolv.conf

                          +

                          Existing scheduled event

                          +

                          ScheduledEvent

                          +

                          Check whether scheduled live migration events exist on the node. A live migration plan event is usually triggered by a hardware fault and is an automatic fault rectification method at the IaaS layer.

                          +

                          Typical scenario: The host is faulty. For example, the fan is damaged or the disk has bad sectors. As a result, live migration is triggered for VMs.

                          +

                          Source:

                          +
                          • http://169.254.169.254/meta-data/latest/events/scheduled
                          +

                          This check item is an Alpha feature and is disabled by default.

                          +
                          +
                          +

                          The kubelet component has the following default check items, which have bugs or defects. You can fix them by upgrading the cluster or using npd.

                          + +
                          + + + + + + + + + + + + + + + @@ -332,177 +375,53 @@ -

                          Node-problem-controller Fault Isolation

                          Fault isolation is supported only by add-ons of 1.16.0 and later versions.

                          -

                          When installing the npd add-on, set npc.enable to true to deploy dual Node-problem-controller (NPC). You can deploy NPC as single-instance but such NPC does not ensure high availability.

                          -

                          By default, if multiple nodes become faulty, NPC adds taints to only one node. You can set npc.maxTaintedNode to increase the threshold. When the fault is rectified, NPC is not running and taints remain. You need to manually clear the taints or start NPC.

                          +

                          Node-problem-controller Fault Isolation

                          Fault isolation is supported only by add-ons of 1.16.0 and later versions.

                          +

                          By default, if multiple nodes become faulty, NPC adds taints to up to 10% of the nodes. You can set npc.maxTaintedNode to increase the threshold.

                          -

                          The open source NPD plug-in provides fault detection but not fault isolation. CCE enhances the node-problem-controller (NPC) based on the open source NPD. This component is implemented based on the Kubernetes node controller. For faults reported by NPD, NPC automatically adds taints to nodes for node fault isolation.

                          -

                          You can modify add-onnpc.customConditionToTaint according to the following table to configure fault isolation rules.

                          +

                          The open source NPD plug-in provides fault detection but not fault isolation. CCE enhances the node-problem-controller (NPC) based on the open source NPD. This component is implemented based on the Kubernetes node controller. For faults reported by NPD, NPC automatically adds taints to nodes for node fault isolation.

                          -
                          Table 6 Default kubelet check items

                          Check Item

                          +

                          Function

                          +

                          Description

                          +

                          Insufficient PID resources

                          +

                          PIDPressure

                          +

                          Check whether PIDs are sufficient.

                          +
                          • Interval: 10 seconds
                          • Threshold: 90%
                          • Defect: In community version 1.23.1 and earlier versions, this check item becomes invalid when over 65535 PIDs are used. For details, see issue 107107. In community version 1.24 and earlier versions, thread-max is not considered in this check item.
                          +

                          Insufficient memory

                          +

                          MemoryPressure

                          +

                          Check whether the allocable memory for the containers is sufficient.

                          +
                          • Interval: 10 seconds
                          • Threshold: max. 100 MiB
                          • Allocable = Total memory of a node – Reserved memory of a node
                          • Defect: This check item checks only the memory consumed by containers, and does not consider that consumed by other elements on the node.
                          +

                          Insufficient disk resources

                          +

                          DiskPressure

                          +

                          Check the disk usage and inodes usage of the kubelet and Docker disks.

                          +
                          • Interval: 10 seconds
                          • Threshold: 90%
                          diff --git a/docs/cce/umn/cce_10_0150.html b/docs/cce/umn/cce_10_0150.html index e9bc8369..2cefd9aa 100644 --- a/docs/cce/umn/cce_10_0150.html +++ b/docs/cce/umn/cce_10_0150.html @@ -8,7 +8,7 @@

                          Prerequisites

                          Resources have been created. For details, see Creating a Node. If clusters and nodes are available, you need not create them again.

                          -

                          Using the CCE Console

                          1. Log in to the CCE console.
                          2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
                          3. Set basic information about the workload.

                            Basic Info
                            • Workload Type: Select Job. For details about workload types, see Overview.
                            • Workload Name: Enter the name of the workload.
                            • Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                            • Pods: Enter the number of pods.
                            • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                            +

                            Using the CCE Console

                            1. Log in to the CCE console.
                            2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
                            3. Set basic information about the workload.

                              Basic Info
                              • Workload Type: Select Job. For details about workload types, see Overview.
                              • Workload Name: Enter the name of the workload. Enter 1 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 of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                              • Pods: Enter the number of pods.
                              • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                              Container Settings
                              • Container Information
                                Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.

                                Prerequisites

                                Resources have been created. For details, see Creating a Node.

                                -

                                Using the CCE Console

                                1. Log in to the CCE console.
                                2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
                                3. Set basic information about the workload.

                                  Basic Info
                                  • Workload Type: Select Cron Job. For details about workload types, see Overview.
                                  • Workload Name: Enter the name of the workload.
                                  • Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                                  • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                                  +

                                  Using the CCE Console

                                  1. Log in to the CCE console.
                                  2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
                                  3. Set basic information about the workload.

                                    Basic Info
                                    • Workload Type: Select Cron Job. For details about workload types, see Overview.
                                    • Workload Name: Enter the name of the workload. Enter 1 to 52 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 of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                                    • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                                    Container Settings
                                    • Container Information
                                      Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
                                      diff --git a/docs/cce/umn/cce_10_0152.html b/docs/cce/umn/cce_10_0152.html index faea51a6..5acf05ce 100644 --- a/docs/cce/umn/cce_10_0152.html +++ b/docs/cce/umn/cce_10_0152.html @@ -6,37 +6,39 @@

                                      Benefits of ConfigMaps:

                                      • Manage configurations of different environments and services.
                                      • Deploy workloads in different environments. Multiple versions are supported for configuration files so that you can update and roll back workloads easily.
                                      • Quickly import configurations in the form of files to containers.
                                    +

                                    Notes and Constraints

                                    • The size of a ConfigMap resource file cannot exceed 2 MB.
                                    • ConfigMaps cannot be used in static pods.
                                    +

                                    Procedure

                                    1. Log in to the CCE console and access the cluster console.
                                    2. Choose ConfigMaps and Secrets in the navigation pane and click Create ConfigMap in the upper right corner.
                                    3. Set parameters.

                                      -

                          Table 6 Parameters

                          Parameter

                          +
                          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                          Table 7 Parameters

                          Parameter

                          Description

                          +

                          Description

                          Default

                          +

                          Default

                          npc.enable

                          +

                          npc.enable

                          Whether to enable NPC

                          +

                          Whether to enable NPC

                          +

                          NPC cannot be disabled in 1.18.0 or later versions.

                          true

                          +

                          true

                          npc.customCondtionToTaint

                          +

                          npc. maxTaintedNode

                          Fault isolation rules

                          +

                          Check how many nodes can npc add taints to for mitigating the impact when a single fault occurs on multiple nodes.

                          +

                          The int format and percentage format are supported.

                          See Table 7.

                          +

                          10%

                          +

                          Value range:

                          +
                          • The value is in int format and ranges from 1 to infinity.
                          • The value ranges from 1% to 100%, in percentage. The minimum value of this parameter multiplied by the number of cluster nodes is 1.

                          npc.customConditionToTaint[i]

                          +

                          npc.affinity

                          Fault isolation rule items

                          +

                          Node affinity of the controller

                          N/A

                          -

                          npc.customConditionToTaint[i].

                          -

                          condition.status

                          -

                          Fault status

                          -

                          true

                          -

                          npc.customConditionToTaint[i].

                          -

                          condition.type

                          -

                          Fault type

                          -

                          N/A

                          -

                          npc.customConditionToTaint[i].

                          -

                          enable

                          -

                          Whether to enable the fault isolation rule.

                          -

                          false

                          -

                          npc.customConditionToTaint[i].

                          -

                          .taint.effect

                          -

                          Fault isolation effect

                          -

                          NoSchedule, PreferNoSchedule, or NoExecute

                          -

                          NoSchedule

                          -

                          Value options: NoSchedule, PreferNoSchedule, and NoExecute

                          -

                          npc. maxTaintedNode

                          -

                          Number of nodes in a cluster that can be tainted by NPC

                          -

                          The int format and percentage format are supported.

                          -

                          1

                          -

                          Values:

                          -
                          • The value is in int format and ranges from 1 to infinity.
                          • The value ranges from 1% to 100%, in percentage. The minimum value of this parameter multiplied by the number of cluster nodes is 1.
                          -

                          Npc.affinity

                          -

                          Node affinity of the controller

                          -

                          N/A

                          -
                          -
                          - -
                          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                          Table 7 Fault isolation rule configuration

                          Fault

                          -

                          Fault Details

                          -

                          Taint

                          -

                          DiskReadonly

                          -

                          Disk read-only

                          -

                          NoSchedule: No new pods allowed.

                          -

                          DiskProblem

                          -

                          The disk space is insufficient, and key logical disks are detached.

                          -

                          NoSchedule: No new pods allowed.

                          -

                          FrequentKubeletRestart

                          -

                          kubelet restarts frequently.

                          -

                          NoSchedule: No new pods allowed.

                          -

                          FrequentDockerRestart

                          -

                          Docker restarts frequently.

                          -

                          NoSchedule: No new pods allowed.

                          -

                          FrequentContainerdRestart

                          -

                          containerd restarts frequently.

                          -

                          NoSchedule: No new pods allowed.

                          -

                          KUBEPROXYProblem

                          -

                          kube-proxy is abnormal.

                          -

                          NoSchedule: No new pods allowed.

                          -

                          PIDProblem

                          -

                          Insufficient PIDs

                          -

                          NoSchedule: No new pods allowed.

                          -

                          FDProblem

                          -

                          Insufficient file handles

                          -

                          NoSchedule: No new pods allowed.

                          -

                          MemoryProblem

                          -

                          Insufficient node memory

                          -

                          NoSchedule: No new pods allowed.

                          +

                          N/A
                          -

                          Collecting Prometheus Metrics

                          The NPD daemon pod exposes Prometheus metric data on port 19901. By default, the NPD pod is added with the annotation metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"prometheus","path":"/metrics","port":"19901","names":""}]'. You can build a Prometheus collector to identify and obtain NPD metrics from http://{{NpdPodIP}}:{{NpdPodPort}}/metrics.

                          -

                          If the npd add-on version is earlier than 1.16.5, the exposed port of Prometheus metrics is 20257.

                          +

                          Collecting Prometheus Metrics

                          The NPD daemon pod exposes Prometheus metric data on port 19901. By default, the NPD pod is added with the annotation metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"prometheus","path":"/metrics","port":"19901","names":""}]'. You can build a Prometheus collector to identify and obtain NPD metrics from http://{{NpdPodIP}}:{{NpdPodPort}}/metrics.

                          +

                          If the npd add-on version is earlier than 1.16.5, the exposed port of Prometheus metrics is 20257.

                          -

                          Currently, the metric data includes problem_counter and problem_gauge, as shown below.

                          -
                          # HELP problem_counter Number of times a specific type of problem have occurred.
+
                          Currently, the metric data includes problem_counter and problem_gauge, as shown below.
                          
+
                          # HELP problem_counter Number of times a specific type of problem have occurred.
 # TYPE problem_counter counter
 problem_counter{reason="DockerHung"} 0
 problem_counter{reason="DockerStart"} 0
diff --git a/docs/cce/umn/cce_10_0139.html b/docs/cce/umn/cce_10_0139.html
index cf5ed78e..df93bcee 100644
--- a/docs/cce/umn/cce_10_0139.html
+++ b/docs/cce/umn/cce_10_0139.html
@@ -146,7 +146,7 @@ kubectl exec -it podname -c containername bash
                          
 
                           
                          Resource names cannot be updated.
                          
 
                          
 
                          apply*
                          
-
                          The apply command provides a more strict control on resource updating than patch and edit commands. The apply command applies a configuration to a resource and maintains a set of configuration files in source control. Whenever there is an update, the configuration file is pushed to the server, and then the kubectl apply command applies the latest configuration to the resource. The Kubernetes compares the new configuration file with the original one and updates only the changed configuration instead of the whole file. The configuration that is not contained in the -f flag will remain unchanged. Unlike the replace command which deletes the resource and creates a new one, the apply command directly updates the original resource. Similar to the git operation, the apply command adds an annotation to the resource to mark the current apply.
                          
+
                          The apply command provides a more strict control on resource updating than patch and edit commands. The apply command applies a configuration to a resource and maintains a set of configuration files in source control. Whenever there is an update, the configuration file is pushed to the server, and then the kubectl apply command applies the latest configuration to the resource. The Kubernetes compares the new configuration file with the original one and updates only the changed configuration instead of the whole file. The configuration that is not contained in the -f flag will remain unchanged. Unlike the replace command which deletes the resource and creates a new one, the apply command directly updates the original resource. Similar to the git operation, the apply command adds an annotation to the resource to mark the current apply.
                          
 
                          kubectl apply -f
                          
 
                          patch
                          
 
                          If you want to modify attributes of a running container without first deleting the container or using the replace command, the patch command is to the rescue. The patch command updates field(s) of a resource using strategic merge patch, a JSON merge patch, or a JSON patch. For example, to change a pod label from app=nginx1 to app=nginx2 while the pod is running, use the following command:
                          
diff --git a/docs/cce/umn/cce_10_0141.html b/docs/cce/umn/cce_10_0141.html
index 71492b27..db6c148b 100644
--- a/docs/cce/umn/cce_10_0141.html
+++ b/docs/cce/umn/cce_10_0141.html
@@ -15,11 +15,11 @@
 
                          Container:
                          
 
                          cd /usr/local/nvidia/bin && ./nvidia-smi
                          
 
                          If GPU information is returned, the device is available and the add-on is successfully installed.
                          
-
                          
+
                          -

                          Obtaining the Driver Link from Public Network

                          1. Log in to the CCE console.
                          2. Click Create Node and select the GPU node to be created in the Specifications area. The GPU card model of the node is displayed in the lower part of the page.
                          1. Visit https://www.nvidia.com/Download/Find.aspx?lang=en.
                          2. Select the driver information on the NVIDIA Driver Downloads page, as shown in Figure 1. Operating System must be Linux 64-bit.

                            Figure 1 Setting parameters
                            -

                          3. After confirming the driver information, click SEARCH. A page is displayed, showing the driver information, as shown in Figure 2. Click DOWNLOAD.

                            Figure 2 Driver information
                            -

                          4. Obtain the driver link in either of the following ways:

                            • Method 1: As shown in Figure 3, find url=/tesla/470.103.01/NVIDIA-Linux-x86_64-470.103.01.run in the browser address box. Then, supplement it to obtain the driver link https://us.download.nvidia.com/tesla/470.103.01/NVIDIA-Linux-x86_64-470.103.01.run. By using this method, you must bind an EIP to each GPU node.
                            • Method 2: As shown in Figure 3, click AGREE & DOWNLOAD to download the driver. Then, upload the driver to OBS and record the OBS URL. By using this method, you do not need to bind an EIP to GPU nodes.
                              Figure 3 Obtaining the link
                              +

                              Obtaining the Driver Link from Public Network

                              1. Log in to the CCE console.
                              2. Click Create Node and select the GPU node to be created in the Specifications area. The GPU card model of the node is displayed in the lower part of the page.
                              1. Visit https://www.nvidia.com/Download/Find.aspx?lang=en.
                              2. Select the driver information on the NVIDIA Driver Downloads page, as shown in Figure 1. Operating System must be Linux 64-bit.

                                Figure 1 Setting parameters
                                +

                              3. After confirming the driver information, click SEARCH. A page is displayed, showing the driver information, as shown in Figure 2. Click DOWNLOAD.

                                Figure 2 Driver information
                                +

                              4. Obtain the driver link in either of the following ways:

                                • Method 1: As shown in Figure 3, find url=/tesla/470.103.01/NVIDIA-Linux-x86_64-470.103.01.run in the browser address box. Then, supplement it to obtain the driver link https://us.download.nvidia.com/tesla/470.103.01/NVIDIA-Linux-x86_64-470.103.01.run. By using this method, you must bind an EIP to each GPU node.
                                • Method 2: As shown in Figure 3, click AGREE & DOWNLOAD to download the driver. Then, upload the driver to OBS and record the OBS URL. By using this method, you do not need to bind an EIP to GPU nodes.
                                  Figure 3 Obtaining the link

                              diff --git a/docs/cce/umn/cce_10_0142.html b/docs/cce/umn/cce_10_0142.html index 988a1f98..3914fdb6 100644 --- a/docs/cce/umn/cce_10_0142.html +++ b/docs/cce/umn/cce_10_0142.html @@ -2,7 +2,7 @@

                              NodePort

                              Scenario

                              A Service is exposed on each node's IP address at a static port (NodePort). A ClusterIP Service, to which the NodePort Service will route, is automatically created. By requesting <NodeIP>:<NodePort>, you can access a NodePort Service from outside the cluster.

                              -
                              Figure 1 NodePort access
                              +
                              Figure 1 NodePort access

                              Notes and Constraints

                              • By default, a NodePort Service is accessed within a VPC. If you need to use an EIP to access a NodePort Service through public networks, bind an EIP to the node in the cluster in advance.
                              • After a Service is created, if the affinity setting is switched from the cluster level to the node level, the connection tracing table will not be cleared. You are advised not to modify the Service affinity setting after the Service is created. If you need to modify it, create a Service again.
                              • CCE Turbo clusters support only cluster-level service affinity.
                              • In VPC network mode, when container A is published through a NodePort service and the service affinity is set to the node level (that is, externalTrafficPolicy is set to local), container B deployed on the same node cannot access container A through the node IP address and NodePort service.
                              • When a NodePort service is created in a cluster of v1.21.7 or later, the port on the node is not displayed using netstat by default. If the cluster forwarding mode is iptables, run the iptables -t nat -L command to view the port. If the cluster forwarding mode is ipvs, run the ipvsadm -nL command to view the port.
                              diff --git a/docs/cce/umn/cce_10_0146.html b/docs/cce/umn/cce_10_0146.html index e18d05cd..9c06932c 100644 --- a/docs/cce/umn/cce_10_0146.html +++ b/docs/cce/umn/cce_10_0146.html @@ -33,7 +33,7 @@

                          Describes configuration parameters required by templates.

                          NOTICE:

                          Make sure that the image address set in the values.yaml file is the same as the image address in the container image repository. Otherwise, an exception occurs when you create a workload, and the system displays a message indicating that the image fails to be pulled.

                          -

                          To obtain the image address, perform the following operations: Log in to the CCE console. In the navigation pane, choose Image Repository to access the SWR console. Choose My Images > Private Images and click the name of the uploaded image. On the Image Tags tab page, obtain the image address from the pull command. You can click to copy the command in the Image Pull Command column.

                          +

                          To obtain the image address, perform the following operations: Log in to the CCE console. In the navigation pane, choose Image Repository to access the SWR console. Choose My Images > Private Images and click the name of the uploaded image. On the Image Tags tab page, obtain the image address from the pull command. You can click to copy the command in the Image Pull Command column.
                          Table 1 Parameters for creating a ConfigMap

                          Parameter

                          +
                          - - - - - - - - - - - @@ -45,16 +47,6 @@

                        • After the configuration is complete, click OK.

                          The new ConfigMap is displayed in the ConfigMap list.

                          • -

                          ConfigMap Requirements

                          A ConfigMap resource file must be in YAML format, and the file size cannot exceed 2 MB.

                          -
                          The file name is configmap.yaml and the following shows a configuration example.
                          apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: test-configmap
-data:
-  data-1: value-1
-  data-2: value-2
                          -
                          -

                          Creating a ConfigMap Using kubectl

                          1. Configure the kubectl command to connect an ECS to the cluster. For details, see Connecting to a Cluster Using kubectl.
                          2. Create and edit the cce-configmap.yaml file.

                            vi cce-configmap.yaml

                            apiVersion: v1
 kind: ConfigMap
@@ -63,15 +55,45 @@ metadata:
 data:
   SPECIAL_LEVEL: Hello
   SPECIAL_TYPE: CCE
                            + +
                          Table 1 Parameters for creating a ConfigMap

                          Parameter

                          Description

                          +

                          Description

                          Name

                          +

                          Name

                          Name of a ConfigMap, which must be unique in a namespace.

                          +

                          Name of a ConfigMap, which must be unique in a namespace.

                          Namespace

                          +

                          Namespace

                          Namespace to which the ConfigMap belongs. If you do not specify this parameter, the value default is used by default.

                          +

                          Namespace to which the ConfigMap belongs. If you do not specify this parameter, the value default is used by default.

                          Description

                          +

                          Description

                          Description of the ConfigMap.

                          +

                          Description of the ConfigMap.

                          Data

                          +

                          Data

                          Data of a ConfigMap, in the key-value pair format.

                          -

                          Click to add data. The value can be in string, JSON, or YAML format.

                          +

                          Data of a ConfigMap, in the key-value pair format.

                          +

                          Click to add data. The value can be in string, JSON, or YAML format.

                          Label

                          +

                          Label

                          Label of the ConfigMap. Enter a key-value pair and click Add.

                          +

                          Label of the ConfigMap. Enter a key-value pair and click Add.
                          + + + + + + + + + + + + + + + + +
                          Table 2 Key parameters

                          Parameter

                          +

                          Description

                          +

                          apiVersion

                          +

                          The value is fixed at v1.

                          +

                          kind

                          +

                          The value is fixed at ConfigMap.

                          +

                          metadata.name

                          +

                          ConfigMap name, which can be customized.

                          +

                          data

                          +

                          ConfigMap data. The value must be key-value pairs.

                          +
                          +

                        • Run the following commands to create a ConfigMap.

                          kubectl create -f cce-configmap.yaml

                          +

                          Run the following commands to view the created ConfigMap:

                          kubectl get cm

                          NAME               DATA            AGE
-cce-configmap      3               3h
-cce-configmap1     3               7m
                          +cce-configmap 3 7m

                          • -

                          Related Operations

                          After creating a configuration item, you can update or delete it as described in Table 2. -
                          Table 2 Related operations

                          Operation

                          +

                          Related Operations

                          After creating a configuration item, you can update or delete it as described in Table 3. +
                          @@ -101,7 +123,7 @@ cce-configmap1 3 7m
                          -
                          Parent topic: Configuration Center
                          +
                          Parent topic: ConfigMaps and Secrets
                          diff --git a/docs/cce/umn/cce_10_0153.html b/docs/cce/umn/cce_10_0153.html index 23205a40..1cd31dab 100644 --- a/docs/cce/umn/cce_10_0153.html +++ b/docs/cce/umn/cce_10_0153.html @@ -3,45 +3,47 @@

                          Creating a Secret

                          Scenario

                          A secret is a type of resource that holds sensitive data, such as authentication and key information. Its content is user-defined. After creating secrets, you can use them as files or environment variables in a containerized workload.

                          +

                          Notes and Constraints

                          Secrets cannot be used in static pods.

                          +

                          Procedure

                          1. Log in to the CCE console and access the cluster console.
                          2. Choose ConfigMaps and Secrets in the navigation pane, click the Secrets tab, and click Create Secret in the upper right corner.
                          3. Set parameters.

                            -

                          Table 3 Related operations

                          Operation

                          Description
                          Table 1 Parameters for creating a secret

                          Parameter

                          +
                          - - - - - - - - - - - - - @@ -50,64 +52,102 @@

                        • After the configuration is complete, click OK.

                          The new secret is displayed in the key list.

                          • -

                          Secret Resource File Configuration

                          This section describes configuration examples of secret resource description files.

                          -

                          For example, you can retrieve the username and password for a workload through a secret.

                          -
                          • YAML format

                            The secret.yaml file is defined as shown below. The value must be based on the Base64 coding method. For details about the method, see Base64 Encoding.

                            +

                            Secret Resource File Configuration

                            This section describes configuration examples of secret resource description files.

                            +
                            • Opaque

                              The secret.yaml file is defined as shown below. The data field is filled in as a key-value pair, and the value field must be encoded using Base64. For details about the Base64 encoding method, see Base64 Encoding.

                              apiVersion: v1
 kind: Secret
 metadata:
   name: mysecret           #Secret name
   namespace: default       #Namespace. The default value is default.
 data:
-  username: ******  #The value must be Base64-encoded.
-  password: ******  #The value must be encoded using Base64.
-type: Opaque     #You are advised not to change this parameter value.
                              + <your_key>: <your_value> # Enter a key-value pair. The value must be encoded using Base64. +type: Opaque +
                            • kubernetes.io/dockerconfigjson

                              The secret.yaml file is defined as shown below. The value of .dockerconfigjson must be encoded using Base64. For details, see Base64 Encoding.

                              +
                              apiVersion: v1
+kind: Secret
+metadata:
+  name: mysecret           #Secret name
+  namespace: default       #Namespace. The default value is default.
+data:
+  .dockerconfigjson: eyJh*****    # Content encoded using Base64.
+type: kubernetes.io/dockerconfigjson
                              +

                              To obtain the .dockerconfigjson content, perform the following steps:

                              +
                              1. Obtain the login information of the image repository.
                                • Image repository address: The section uses address as an example. Replace it with the actual address.
                                • Username: The section uses username as an example. Replace it with the actual username.
                                • Password: The section uses password as an example. Replace it with the actual password.
                                +
                              2. Use Base64 to encode the key-value pair username:password and fill the encoded content in step 3.
                                echo -n "username:password" | base64
                                +

                                Command output:

                                +
                                dXNlcm5hbWU6cGFzc3dvcmQ=
                                +
                              3. Use Base64 to encode the following JSON content:
                                echo -n '{"auths":{"address":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}' | base64
                                +

                                Command output:

                                +
                                eyJhdXRocyI6eyJhZGRyZXNzIjp7InVzZXJuYW1lIjoidXNlcm5hbWUiLCJwYXNzd29yZCI6InBhc3N3b3JkIiwiYXV0aCI6ImRYTmxjbTVoYldVNmNHRnpjM2R2Y21RPSJ9fX0=
                                +

                                The encoded content is the .dockerconfigjson content.

                                +
                              +
                            +
                            • kubernetes.io/tls
                              The value of tls.crt and tls.key must be encoded using Base64. For details, see Base64 Encoding.
                              kind: Secret
+apiVersion: v1
+metadata:
+  name: mysecret           #Secret name
+  namespace: default       #Namespace. The default value is default.
+data:
+  tls.crt: LS0tLS1CRU*****FURS0tLS0t  # Certificate content, which must be encoded using Base64.
+  tls.key: LS0tLS1CRU*****VZLS0tLS0=  # Private key content, which must be encoded using Base64.
+type: kubernetes.io/tls
                              +
                              +
                            • IngressTLS
                              The value of tls.crt and tls.key must be encoded using Base64. For details, see Base64 Encoding.
                              kind: Secret
+apiVersion: v1
+metadata:
+  name: mysecret           #Secret name
+  namespace: default       #Namespace. The default value is default.
+data:
+  tls.crt: LS0tLS1CRU*****FURS0tLS0t  # Certificate content, which must be encoded using Base64.
+  tls.key: LS0tLS1CRU*****VZLS0tLS0=  # Private key content, which must be encoded using Base64.
+type: IngressTLS
                              +

                            Creating a Secret Using kubectl

                            1. According to Connecting to a Cluster Using kubectl, configure the kubectl command to connect an ECS to the cluster.
                            2. Create and edit the Base64-encoded cce-secret.yaml file.

                              # echo -n "content to be encoded" | base64
 ******

                              vi cce-secret.yaml

                              +

                              The following YAML file uses the Opaque type as an example. For details about other types, see Secret Resource File Configuration.

                              apiVersion: v1
 kind: Secret
 metadata:
   name: mysecret
 type: Opaque
 data:
-  username: ******
-  password: ******
                              + <your_key>: <your_value> # Enter a key-value pair. The value must be encoded using Base64.

                            3. Create a secret.

                              kubectl create -f cce-secret.yaml

                              You can query the secret after creation.

                              -

                              kubectl get secret

                              +

                              kubectl get secret -n default

                            Related Operations

                            After creating a secret, you can update or delete it as described in Table 2.

                            The secret list contains system secret resources that can be queried only. The system secret resources cannot be updated or deleted.

                            -
                          Table 1 Parameters for creating a secret

                          Parameter

                          Description

                          +

                          Description

                          Name

                          +

                          Name

                          Name of the secret you create, which must be unique.

                          +

                          Name of the secret you create, which must be unique.

                          Namespace

                          +

                          Namespace

                          Namespace to which the secret belongs. If you do not specify this parameter, the value default is used by default.

                          +

                          Namespace to which the secret belongs. If you do not specify this parameter, the value default is used by default.

                          Description

                          +

                          Description

                          Description of a secret.

                          +

                          Description of a secret.

                          Type

                          +

                          Type

                          Type of the secret you create.

                          -
                          • Opaque: common secret.
                          • kubernetes.io/dockerconfigjson: a secret that stores the authentication information required for pulling images from a private repository.
                          • IngressTLS: a secret that stores the certificate required by ingresses (layer-7 load balancing Services).
                          • Other: another type of secret, which is specified manually.
                          +

                          Type of the secret you create.

                          +
                          • Opaque: common secret.
                          • kubernetes.io/dockerconfigjson: a secret that stores the authentication information required for pulling images from a private repository.
                          • kubernetes.io/tls: Kubernetes TLS secret, which is used to store the certificate required by layer-7 load balancing Services.
                          • IngressTLS: TLS secret provided by CCE to store the certificate required by layer-7 load balancing Services.
                          • Other: another type of secret, which is specified manually.

                          Secret Data

                          +

                          Secret Data

                          Workload secret data can be used in containers.

                          -
                          • If Secret Type is Opaque, click . In the dialog box displayed, enter a key-value pair and select Auto Base64 Encoding.
                          • If the secret type is kubernetes.io/dockerconfigjson, enter the account and password of the private image repository.
                          • If the secret type is IngressTLS, upload the certificate file and private key file.
                            NOTE:
                            • A certificate is a self-signed or CA-signed credential used for identity authentication.
                            • A certificate request is a request for a signature with a private key.
                            +

                          Workload secret data can be used in containers.

                          +
                          • If Secret Type is Opaque, click . In the dialog box displayed, enter a key-value pair and select Auto Base64 Encoding.
                          • If the secret type is kubernetes.io/dockerconfigjson, enter the account and password of the private image repository.
                          • If Secret Type is kubernetes.io/tls or IngressTLS, upload the certificate file and private key file.
                            NOTE:
                            • A certificate is a self-signed or CA-signed credential used for identity authentication.
                            • A certificate request is a request for a signature with a private key.

                          Secret Label

                          +

                          Secret Label

                          Label of the secret. Enter a key-value pair and click Add.

                          +

                          Label of the secret. Enter a key-value pair and click Add.
                          Table 2 Related Operations

                          Operation

                          +
                          - - - - - - - - - @@ -122,7 +162,7 @@ data:
                          -
                          Parent topic: Configuration Center
                          +
                          Parent topic: ConfigMaps and Secrets
                          diff --git a/docs/cce/umn/cce_10_0154.html b/docs/cce/umn/cce_10_0154.html index 81b1e509..48309e14 100644 --- a/docs/cce/umn/cce_10_0154.html +++ b/docs/cce/umn/cce_10_0154.html @@ -34,6 +34,11 @@
                          • Single: The add-on is deployed with only one pod.
                          • HA50: The add-on is deployed with two pods, serving a cluster with 50 nodes and ensuring high availability.
                          • HA200: The add-on is deployed with two pods, serving a cluster with 50 nodes and ensuring high availability. Each pod uses more resources than those of the HA50 specification.
                          • Custom: You can customize the number of pods and specifications as required.
                          + + +
                          Table 2 Related Operations

                          Operation

                          Description

                          +

                          Description

                          Editing a YAML file

                          +

                          Editing a YAML file

                          Click Edit YAML in the row where the target secret resides to edit its YAML file.

                          +

                          Click Edit YAML in the row where the target secret resides to edit its YAML file.

                          Updating a secret

                          +

                          Updating a secret

                          1. Select the name of the secret to be updated and click Update.
                          2. Modify the secret data. For more information, see Table 1.
                          3. Click OK.
                          +
                          1. Select the name of the secret to be updated and click Update.
                          2. Modify the secret data. For more information, see Table 1.
                          3. Click OK.

                          Deleting a secret

                          +

                          Deleting a secret

                          Select the secret you want to delete and click Delete.

                          +

                          Select the secret you want to delete and click Delete.

                          Follow the prompts to delete the secret.

                          Deleting secrets in batches

                          +

                          Deleting secrets in batches

                          1. Select the secrets to be deleted.
                          2. Click Delete above the secret list.
                          3. Follow the prompts to delete the secrets.
                          +
                          1. Select the secrets to be deleted.
                          2. Click Delete above the secret list.
                          3. Follow the prompts to delete the secrets.

                          Multi AZ

                          +
                          • Preferred: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ.
                          • Required: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run.
                          +
                          diff --git a/docs/cce/umn/cce_10_0164.html b/docs/cce/umn/cce_10_0164.html index de65027f..3724fdfb 100644 --- a/docs/cce/umn/cce_10_0164.html +++ b/docs/cce/umn/cce_10_0164.html @@ -16,7 +16,7 @@
                        • Pod Security
                          • -
                        • Service Account Token Security Improvement
                          +
                        • Service Account Token Security Improvement
                          • diff --git a/docs/cce/umn/cce_10_0175.html b/docs/cce/umn/cce_10_0175.html index 08b1c73c..30b0a052 100644 --- a/docs/cce/umn/cce_10_0175.html +++ b/docs/cce/umn/cce_10_0175.html @@ -3,7 +3,7 @@

                          Obtaining a Cluster Certificate

                          Scenario

                          This section describes how to obtain the cluster certificate from the console and use it to access Kubernetes clusters.

                          -

                          Procedure

                          1. Log in to the CCE console and access the cluster console.
                          2. Choose Cluster Information from the navigation pane and click Download next to Authentication Mode in the Connection Information area.
                          3. In the Download X.509 Certificate dialog box displayed, select the certificate expiration time and download the X.509 certificate of the cluster as prompted.

                            Figure 1 Downloading a certificate
                            +

                            Procedure

                            1. Log in to the CCE console and access the cluster console.
                            2. Choose Cluster Information from the navigation pane and click Download next to Authentication Mode in the Connection Information area.
                            3. In the Download X.509 Certificate dialog box displayed, select the certificate expiration time and download the X.509 certificate of the cluster as prompted.

                              Figure 1 Downloading a certificate
                              • The downloaded certificate contains three files: client.key, client.crt, and ca.crt. Keep these files secure.
                              • Certificates are not required for mutual access between containers in a cluster.

                            diff --git a/docs/cce/umn/cce_10_0178.html b/docs/cce/umn/cce_10_0178.html index b3fda086..3a82c057 100644 --- a/docs/cce/umn/cce_10_0178.html +++ b/docs/cce/umn/cce_10_0178.html @@ -1,14 +1,14 @@

                            Formula for Calculating the Reserved Resources of a Node

                            -

                            Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node resources and the number of assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, Kubernetes needs to reserve more resources.

                            +

                            Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node resources and the number of assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, more node resources need to be reserved to run Kubernetes components.

                            To ensure node stability, a certain amount of CCE node resources will be reserved for Kubernetes components (such as kubelet, kube-proxy, and docker) based on the node specifications.

                            CCE calculates the resources that can be allocated to user nodes as follows:

                            Allocatable resources = Total amount - Reserved amount - Eviction threshold

                            The memory eviction threshold is fixed at 100 MB.

                            When the memory consumed by all pods on a node increases, the following behaviors may occur:

                            -
                            1. If the memory is greater than or equal to the allocatable amount on the node, kubelet is triggered to evict pods.
                            2. When the memory approaches the allocatable amount and eviction threshold (total minus reserved), OS OOM is triggered.
                            -

                            Rules for Reserving Node Memory

                            You can use the following formula calculate how much memory you should reserve for running containers on a node:

                            +
                            1. When the available memory on a node is lower than the eviction threshold, kubelet is triggered to evict pods. For details about Kubernetes eviction threshold, see Node-pressure Eviction.
                            2. If a node triggers an OS Out-Of-Memory (OOM) event before kubelet reclaims memory, the system terminates the container. However, kubelet does not evict the pod, but restarts the container based on the RestartPolicy of the pod.
                            +

                            Rules for Reserving Node Memory

                            You can use the following formula calculate how much memory you should reserve for running containers on a node:

                            Total reserved amount = Reserved memory for system components + Reserved memory for kubelet to manage pods

                            Table 1 Reservation rules for system components

                            Total Memory (TM)

                            diff --git a/docs/cce/umn/cce_10_0184.html b/docs/cce/umn/cce_10_0184.html index 03f8377b..14a5a411 100644 --- a/docs/cce/umn/cce_10_0184.html +++ b/docs/cce/umn/cce_10_0184.html @@ -7,7 +7,7 @@

                            Notes and Constraints

                            • Data, including the VM status, ECS names, number of CPUs, size of memory, ECS specifications, and public IP addresses, can be synchronized.

                              If an ECS name is specified as the Kubernetes node name, the change of the ECS name cannot be synchronized to the CCE console.

                            • Data, such as the OS and image ID, cannot be synchronized. (Such parameters cannot be modified on the ECS console.)
                            -

                            Procedure

                            1. Log in to the CCE console.
                            2. Click the cluster name to access the cluster console. Choose Nodes in the navigation pane.
                            3. Choose More > Sync Server Data next to the node.

                              Figure 1 Synchronizing server data
                              +

                              Procedure

                              1. Log in to the CCE console.
                              2. Click the cluster name to access the cluster console. Choose Nodes in the navigation pane.
                              3. Choose More > Sync Server Data next to the node.

                                Figure 1 Synchronizing server data

                                After the synchronization is complete, the ECS data synchronization requested message is displayed in the upper right corner.

                              diff --git a/docs/cce/umn/cce_10_0186.html b/docs/cce/umn/cce_10_0186.html index d7eb7267..e761b993 100644 --- a/docs/cce/umn/cce_10_0186.html +++ b/docs/cce/umn/cce_10_0186.html @@ -3,9 +3,7 @@

                              Deleting a Node

                              Scenario

                              When a node in a CCE cluster is deleted, services running on the node will also be deleted. Exercise caution when performing this operation.

                              -

                              Notes and Constraints

                              • After a CCE cluster is deleted, the ECS nodes in the cluster are also deleted.

                              • For clusters of v1.17.11 or later, after a VM is deleted on the ECS console, the corresponding node in the CCE cluster is automatically deleted.

                                -
                                -
                              +

                              Notes and Constraints

                              • VM nodes that are being used by CCE do not support deletion on the ECS page.

                              Precautions

                              • Deleting a node will lead to pod migration, which may affect services. Perform this operation during off-peak hours.
                              • Unexpected risks may occur during the operation. Back up related data in advance.
                              • During the operation, the backend will set the node to the unschedulable state.
                              • Only worker nodes can be deleted.
                              diff --git a/docs/cce/umn/cce_10_0187.html b/docs/cce/umn/cce_10_0187.html index 7393d70a..d46c4e6c 100644 --- a/docs/cce/umn/cce_10_0187.html +++ b/docs/cce/umn/cce_10_0187.html @@ -10,7 +10,7 @@

                            In general, you configure CCE permissions in two scenarios. The first is creating and managing clusters and related resources, such as nodes. The second is creating and using Kubernetes resources in the cluster, such as workloads and Services.

                            -
                            Figure 1 Illustration on CCE permissions
                            +
                            Figure 1 Illustration on CCE permissions

                            These permissions allow you to manage resource users at a finer granularity.

                            Cluster Permissions (IAM-based) and Namespace Permissions (Kubernetes RBAC-based)

                            Users with different cluster permissions (assigned using IAM) have different namespace permissions (assigned using Kubernetes RBAC). Table 1 lists the namespace permissions of different users.

                            diff --git a/docs/cce/umn/cce_10_0188.html b/docs/cce/umn/cce_10_0188.html index 72c4cb06..be0f7bce 100644 --- a/docs/cce/umn/cce_10_0188.html +++ b/docs/cce/umn/cce_10_0188.html @@ -8,7 +8,7 @@

                            Configuration

                            On the CCE console, when you choose Permissions > Cluster-Level Permissions to create a user group, you will be directed to the IAM console to complete the process. After the user group is created and its permissions are configured, you can view the information on the Cluster-Level Permissions tab page. This section describes the operations in IAM.

                            -

                            Process Flow

                            Figure 1 Process of assigning CCE permissions
                            +

                            Process Flow

                            Figure 1 Process of assigning CCE permissions

                            1. Create a user group and assign permissions to it.

                              Create a user group on the IAM console, and assign CCE permissions, for example, the CCEReadOnlyAccess policy to the group.

                              CCE is deployed by region. On the IAM console, select Region-specific projects when assigning CCE permissions.

                              @@ -82,7 +82,7 @@

                            When RBAC and IAM policies co-exist, the backend authentication logic for open APIs or console operations on CCE is as follows:

                            -

                            +

                            Certain CCE APIs involve namespace-level permissions or key operations and therefore, they require special permissions:

                            Using clusterCert to obtain the cluster kubeconfig: cceadm/teadmin

                            diff --git a/docs/cce/umn/cce_10_0189.html b/docs/cce/umn/cce_10_0189.html index 47eca800..86719700 100644 --- a/docs/cce/umn/cce_10_0189.html +++ b/docs/cce/umn/cce_10_0189.html @@ -4,36 +4,36 @@

                            Namespace Permissions (Kubernetes RBAC-based)

                            You can regulate users' or user groups' access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding, which are described as follows:

                            • Role: defines a set of rules for accessing Kubernetes resources in a namespace.
                            • RoleBinding: defines the relationship between users and roles.
                            • ClusterRole: defines a set of rules for accessing Kubernetes resources in a cluster (including all namespaces).
                            • ClusterRoleBinding: defines the relationship between users and cluster roles.

                            Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts. Illustration:

                            -
                            Figure 1 Role binding
                            +
                            Figure 1 Role binding

                            On the CCE console, you can assign permissions to a user or user group to access resources in one or multiple namespaces. By default, the CCE console provides the following ClusterRoles:

                            -
                            • view (read-only): read-only permission on most resources in all or selected namespaces.
                            • edit (development): read and write permissions on most resources in all or selected namespaces. If this ClusterRole is configured for all namespaces, its capability is the same as the O&M permission.
                            • admin (O&M): read and write permissions on most resources in all namespaces, and read-only permission on nodes, storage volumes, namespaces, and quota management.
                            • cluster-admin (administrator): read and write permissions on all resources in all namespaces.
                            +
                            • view (read-only): read-only permission on most resources in all or selected namespaces.
                            • edit (development): read and write permissions on most resources in all or selected namespaces. If this ClusterRole is configured for all namespaces, its capability is the same as the O&M permission.
                            • admin (O&M): read and write permissions on most resources in all namespaces, and read-only permission on nodes, storage volumes, namespaces, and quota management.
                            • cluster-admin (administrator): read and write permissions on all resources in all namespaces.
                            • drainage-editor: drain a node.
                            • drainage-viewer: view the nodal drainage status but cannot drain a node.
                            -

                            Cluster Permissions (IAM-based) and Namespace Permissions (Kubernetes RBAC-based)

                            Users with different cluster permissions (assigned using IAM) have different namespace permissions (assigned using Kubernetes RBAC). Table 1 lists the namespace permissions of different users.

                            +

                            Cluster Permissions (IAM-based) and Namespace Permissions (Kubernetes RBAC-based)

                            Users with different cluster permissions (assigned using IAM) have different namespace permissions (assigned using Kubernetes RBAC). Table 1 lists the namespace permissions of different users.

                            -
                            Table 1 Differences in namespace permissions

                            User

                            +
                            - - - - - - - - - @@ -80,7 +80,7 @@ subjects: name: 0c97ac3cb280f4d91fa7c0096739e1f8 # User ID of the user-example apiGroup: rbac.authorization.k8s.io

                            The subjects section binds a Role with an IAM user so that the IAM user can obtain the permissions defined in the Role, as shown in the following figure.

                            -
                            Figure 2 A RoleBinding binds the Role to the user.
                            +
                            Figure 2 A RoleBinding binds the Role to the user.

                            You can also specify a user group in the subjects section. In this case, all users in the user group obtain the permissions defined in the Role.

                            subjects:
 - kind: Group
diff --git a/docs/cce/umn/cce_10_0190.html b/docs/cce/umn/cce_10_0190.html
index d73afefd..ba88a18f 100644
--- a/docs/cce/umn/cce_10_0190.html
+++ b/docs/cce/umn/cce_10_0190.html
@@ -67,7 +67,7 @@
                            -
                            Table 1 Differences in namespace permissions

                            User

                            Clusters of v1.13 and Later

                            +

                            Clusters of v1.13 and Later

                            User with the Tenant Administrator permissions

                            +

                            User with the Tenant Administrator permissions

                            All namespace permissions

                            +

                            All namespace permissions

                            IAM user with the CCE Administrator role

                            +

                            IAM user with the CCE Administrator role

                            All namespace permissions

                            +

                            All namespace permissions

                            IAM user with the CCE FullAccess or CCE ReadOnlyAccess role

                            +

                            IAM user with the CCE FullAccess or CCE ReadOnlyAccess role

                            Requires Kubernetes RBAC authorization.

                            +

                            Requires Kubernetes RBAC authorization.

                            IAM user with the Tenant Guest role

                            +

                            IAM user with the Tenant Guest role

                            Requires Kubernetes RBAC authorization.

                            +

                            Requires Kubernetes RBAC authorization.

                            Object Storage Service (OBS)

                            Scalable File Service (SFS)

                            • To use OBS, you must have OBS Administrator globally assigned.
                              NOTE:

                              Because of the cache, it takes about 13 minutes for the RBAC policy to take effect after being granted to users, enterprise projects, and user groups. After an OBS-related system policy is granted, it takes about 5 minutes for the policy to take effect.

                              +
                            • To use OBS, you must have OBS Administrator globally assigned.
                              NOTE:

                              Because of the cache, it takes about 13 minutes for the RBAC policy to take effect after being granted to users, enterprise projects, and user groups. After an OBS-related system policy is granted, it takes about 5 minutes for the policy to take effect.

                            • To use SFS, you must have SFS FullAccess assigned.

                            The CCE Administrator role is required for importing storage devices.

                            diff --git a/docs/cce/umn/cce_10_0191.html b/docs/cce/umn/cce_10_0191.html index 4c033d54..e3f23d0a 100644 --- a/docs/cce/umn/cce_10_0191.html +++ b/docs/cce/umn/cce_10_0191.html @@ -6,7 +6,7 @@

                            The relationship between Helm and Kubernetes is as follows:

                            • Helm <–> Kubernetes
                            • Apt <–> Ubuntu
                            • Yum <–> CentOS
                            • Pip <–> Python

                            The following figure shows the solution architecture:

                            -

                            +

                            Helm can help application orchestration for Kubernetes:

                            • Manages, edits, and updates a large number of Kubernetes configuration files.
                            • Deploys a complex Kubernetes application that contains a large number of configuration files.
                            • Shares and reuses Kubernetes configurations and applications.
                            • Supports multiple environments with parameter-based configuration templates.
                            • Manages the release of applications, including rolling back the application, finding differences (using the diff command), and viewing the release history.
                            • Controls phases in a deployment cycle.
                            • Tests and verifies the released version.
                            diff --git a/docs/cce/umn/cce_10_0193.html b/docs/cce/umn/cce_10_0193.html index b375076e..c294de2d 100644 --- a/docs/cce/umn/cce_10_0193.html +++ b/docs/cce/umn/cce_10_0193.html @@ -80,7 +80,8 @@
                            -

                          4. Parameters of the volcano default scheduler. For details, see Table 2.

                            ca_cert: ''
+
                          5. Select whether to deploy the add-on pods across multiple AZs.

                            • Preferred: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ.
                            • Required: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run.
                            +

                          6. Parameters of the volcano default scheduler. For details, see Table 2.

                            colocation_enable: ''
 default_scheduler_conf:
   actions: 'allocate, backfill'
   tiers:
@@ -100,27 +101,25 @@ default_scheduler_conf:
         - name: 'nodelocalvolume'
         - name: 'nodeemptydirvolume'
         - name: 'nodeCSIscheduling'
-        - name: 'networkresource'
-server_cert: ''
-server_key: ''
                            + - name: 'networkresource' -
                            - - diff --git a/docs/cce/umn/cce_10_0201.html b/docs/cce/umn/cce_10_0201.html index f3e7f52e..d2f00e07 100644 --- a/docs/cce/umn/cce_10_0201.html +++ b/docs/cce/umn/cce_10_0201.html @@ -2,7 +2,7 @@

                            Custom Monitoring

                            CCE allows you to upload custom metrics to AOM. The ICAgent on a node periodically calls the metric monitoring API configured on a workload to read monitoring data and then uploads the data to AOM.

                            -

                            +

                            The custom metric API of a workload can be configured when the workload is created. This section uses an Nginx application as an example to describe how to report custom metrics to AOM.

                            Notes and Constraints

                            • The ICAgent is compatible with the monitoring data specifications of Prometheus. The custom metrics provided by pods can be collected by the ICAgent only when they meet the monitoring data specifications of Prometheus.
                            • The ICAgent supports only Gauge metrics.
                            • The interval for the ICAgent to call the custom metric API is 1 minute, which cannot be changed.
                            @@ -64,7 +64,7 @@ server accepts handled requests Reading: 0 Writing: 1 Waiting: 2

                            Deploying an Application

                            The data format of the monitoring data provided by nginx:exporter does not meet the requirements of Prometheus. You need to convert the data format to the format required by Prometheus. To convert the format of Nginx metrics, use nginx-prometheus-exporter, as shown in the following figure.

                            -

                            +

                            Deploy nginx:exporter and nginx-prometheus-exporter in the same pod.

                            kind: Deployment
 apiVersion: apps/v1
diff --git a/docs/cce/umn/cce_10_0205.html b/docs/cce/umn/cce_10_0205.html
index 6515a048..e6897fad 100644
--- a/docs/cce/umn/cce_10_0205.html
+++ b/docs/cce/umn/cce_10_0205.html
@@ -5,7 +5,9 @@
 
                            metrics-server is an aggregator for monitoring data of core cluster resources. You can quickly install this add-on on the CCE console.
                            
 
                            After metrics-server is installed, you can create an HPA policy on the Workload Scaling tab page of the Auto Scaling page. For details, see Creating an HPA Policy for Workload Auto Scaling.
                            
 
                            The official community project and documentation are available at https://github.com/kubernetes-sigs/metrics-server.
                            
-
                            Installing the Add-on
                            1. Log in to the CCE console and access the cluster console. Choose Add-ons in the navigation pane, locate metrics-server on the right, and click Install.
                            2. Select Single or HA for Add-on Specifications, and click Install.
                            
+
                            Installing the Add-on
                            1. Log in to the CCE console and access the cluster console. Choose Add-ons in the navigation pane, locate metrics-server on the right, and click Install.
                            2. Select Single, Custom, or HA for Add-on Specifications.
                              • Pods: Set the number of pods based on service requirements.
                              • Multi AZ:
                                • Preferred: Deployment pods of the add-on are preferentially scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, the pods are scheduled to a single AZ.
                                • Required: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. If the nodes in the cluster do not meet the requirements of multiple AZs, not all pods can run.
                                
+
                              • Containers: Set a proper container quota based on service requirements.
                              
+
                            3. Click Install.
                            
 
                            
 
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0209.html b/docs/cce/umn/cce_10_0209.html
index 7bac77d6..431a120f 100644
--- a/docs/cce/umn/cce_10_0209.html
+++ b/docs/cce/umn/cce_10_0209.html
@@ -4,16 +4,12 @@
 
                            CCE provides auto scaling through the autoscaler add-on. Nodes with different specifications can be automatically added across AZs on demand.
                            
 
                            If a node scaling policy and the configuration in the autoscaler add-on take effect at the same time, for example, there are pods that cannot be scheduled and the value of a metric reaches the threshold at the same time, scale-out is performed first for the unschedulable pods.
                            
 
                            • If the scale-out succeeds for the unschedulable pods, the system skips the metric-based rule logic and enters the next loop.
                            • If the scale-out fails for the unschedulable pods, the metric-based rule is executed.
                            
-
                            Prerequisites
                            Before using the node scaling function, you must install the autoscaler add-on of v1.13.8 or later.
                            
+
                            Prerequisites
                            Before using the node scaling function, you must install the autoscaler add-on of v1.13.8 or later in the cluster.
                            
 
                            
 
                            Notes and Constraints
                            • Auto scaling policies apply to node pools. When the number of nodes in a node pool is 0 and the scaling policy is based on CPU or memory usage, node scaling is not triggered.
                            
 
                            
 
                            Procedure
                            1. Log in to the CCE console and access the cluster console.
                            2. Choose Node Scaling in the navigation pane.
                              • If Uninstalled is displayed next to the add-on name, click Install, set add-on parameters as required, and click Install to install the add-on.
                              • If Installed is displayed next to the add-on name, the add-on has been installed.
                              
-
                            3. Click Create Node Scaling Policy in the upper right corner and set the parameters as follows:
                              • Policy Name: name of the policy to be created, which can be customized.
                              • Associated Node Pools: Select the node pool to be associated. You can associate multiple node pools to use the same scaling policy.
                                 
                                Priority is now supported for node pools. CCE will select a node pool for auto scaling based on the following policies:
                                
-
                                1. CCE uses algorithms to determine whether a node pool meets the conditions to allow scheduling of a pod in pending state, including whether the node resources are greater than requested by the pod, and whether the nodeSelect, nodeAffinity, and taints meet the conditions. In addition, the node pools that fail to be scaled (due to insufficient resources or other reasons) and are still in the 15-minute cool-down interval are filtered.
                                2. If multiple node pools meet the scaling requirements, the system checks the priority of each node pool and selects the node pool with the highest priority for scaling. The value ranges from 0 to 100 and the default priority is 0. The value 100 indicates the highest priority, and the value 0 indicates the lowest priority.
                                3. If multiple node pools have the same priority or no priority is configured for them, the system selects the node pool that will consume the least resources based on the configured VM specification.
                                4. If the VM specifications of multiple node pools are the same but the node pools are deployed in different AZs, the system randomly selects a node pool to trigger scaling.
                                5. If the resources of the preferred node pool are insufficient, the system automatically selects next node pool based on the priority.
                                
-
                                For details about the node pool priority, see Creating a Node Pool.
                                
-
                                
-
                              • Rules: Click Add Rule. In the dialog box displayed, set the following parameters:
                                Rule Name: Enter a rule name.
                                
+
                              • Click Create Node Scaling Policy in the upper right corner and set the parameters as follows:
                                • Policy Name: name of the policy to be created, which can be customized.
                                • Associated Node Pools: Select the node pool to be associated. You can associate multiple node pools to use the same scaling policy.
                                • Rules: Click Add Rule. In the dialog box displayed, set the following parameters:
                                  Rule Name: Enter a rule name.
                                  
 
                                  Rule Type: You can select Metric-based or Periodic. The differences between the two types are as follows:
                                  
 
                                  • Metric-based:
                                    Condition: Select CPU allocation rate or Memory allocation rate and enter a value. The value must be greater than the scale-in percentage configured in the autoscaler add-on.
                                     
                                    • Resource allocation (%) = Resources requested by pods in the node pool/Resources allocatable to pods in the node pool
                                    • If multiple rules meet the conditions, the rules are executed in either of the following modes:
                                      If rules based on the CPU allocation rate and memory allocation rate are configured and two or more rules meet the scale-out conditions, the rule that will add the most nodes will be executed.
                                      
 
                                      If a rule based on the CPU allocation rate and a periodic rule are configured and they both meet the scale-out conditions, one of them will be executed randomly. The rule executed first (rule A) changes the node pool to the scaling state. As a result, the other rule (rule B) cannot be executed. After rule A is executed and the node pool status becomes normal, rule B will not be executed.
                                      
diff --git a/docs/cce/umn/cce_10_0212.html b/docs/cce/umn/cce_10_0212.html
index a88c3403..bb2be494 100644
--- a/docs/cce/umn/cce_10_0212.html
+++ b/docs/cce/umn/cce_10_0212.html
@@ -7,7 +7,7 @@
 
                                    
 
                                  • A hibernated cluster cannot be deleted. Wake up the cluster and try again.
                                  • If a cluster whose status is Unavailable is deleted, some storage resources of the cluster may need to be manually deleted.
                                  
 
                            
-
                            Procedure
                            1. Log in to the CCE console. In the navigation pane, choose Clusters.
                            2. Click  next to the cluster to be deleted.
                            3. In the displayed Delete Cluster dialog box, select the resources to be released.
                              • Delete cloud storage resources attached to workloads in the cluster.
                                 
                                Before you delete the PVCs and volumes, pay attention to the following rules:
                                
+
                                Procedure
                                1. Log in to the CCE console. In the navigation pane, choose Clusters.
                                2. Click  next to the cluster to be deleted.
                                3. In the displayed Delete Cluster dialog box, select the resources to be released.
                                  • Delete cloud storage resources attached to workloads in the cluster.
                                     
                                    Before you delete the PVCs and volumes, pay attention to the following rules:
                                    
 
                                    • The underlying storage resources are deleted according to the reclaim policy you defined.
                                    • If there are a large number of files (more than 1,000) in the OBS bucket, manually clear the files and then delete the cluster. 
                                    
 
                                    
 
                                  • Delete networking resources, such as load balancers in a cluster. (Only automatically created load balancers can be deleted.)
                                  
diff --git a/docs/cce/umn/cce_10_0213.html b/docs/cce/umn/cce_10_0213.html
index eed9b36b..e4d391ee 100644
--- a/docs/cce/umn/cce_10_0213.html
+++ b/docs/cce/umn/cce_10_0213.html
@@ -1,11 +1,11 @@
 
 
-
                                  Managing Cluster Components
                                  
+
                                  Cluster Configuration Management
                                  
 
                                  Scenario
                                  CCE allows you to manage cluster parameters, through which you can let core components work under your very requirements.
                                  
 
                                  
 
                                  Notes and Constraints
                                  This function is supported only in clusters of v1.15 and later. It is not displayed for versions earlier than v1.15.
                                  
 
                                  
-
                                  Procedure
                                  1. Log in to the CCE console. In the navigation pane, choose Clusters.
                                  2. Click  next to the target cluster.
                                  3. On the Manage Component page on the right, change the values of the following Kubernetes parameters:
                                    
+
                                    Procedure
                                    1. Log in to the CCE console. In the navigation pane, choose Clusters.
                                    2. Click  next to the target cluster.
                                    3. On the Manage Component page on the right, change the values of the following Kubernetes parameters:
                            Table 2 Volcano Plugins

                            Add-on

                            +
                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/cce/umn/cce_10_0197.html b/docs/cce/umn/cce_10_0197.html index 1c7b8d84..f0b34d82 100644 --- a/docs/cce/umn/cce_10_0197.html +++ b/docs/cce/umn/cce_10_0197.html @@ -7,47 +7,56 @@

                            An upgrade flag will be displayed on the cluster card view if there is a new version for the cluster to upgrade.

                            How to check:

                            Log in to the CCE console and check whether the message "New version available" is displayed in the lower left corner of the cluster. If yes, the cluster can be upgraded. If no, the cluster cannot be upgraded.

                            -
                            Figure 1 Cluster with the upgrade flag
                            +
                            Figure 1 Cluster with the upgrade flag

                            Cluster Upgrade

                            The following table describes the target version to which each cluster version can be upgraded, the supported upgrade modes, and upgrade impacts.

                            -
                            Table 2 Volcano Plugins

                            Add-on

                            Function

                            +

                            Function

                            Description

                            +

                            Description

                            Demonstration

                            +

                            Demonstration

                            binpack

                            +

                            binpack

                            The binpack plugin schedules pods to nodes with high resource utilization to reduce resource fragments.

                            +

                            Schedules pods to nodes with high resource utilization to reduce resource fragments.

                            • binpack.weight: Weight of the binpack plugin.
                            • binpack.cpu: Ratio of CPU resources to all resources. Defaults to 1.
                            • binpack.memory: Ratio of memory resources to all resources. Defaults to 1.
                            • binpack.resources:
                            +
                            • binpack.weight: Weight of the binpack plugin.
                            • binpack.cpu: ratio of CPU resources to all resources. Defaults to 1.
                            • binpack.memory: Ratio of memory resources to all resources. Defaults to 1.
                            • binpack.resources: resource type.
                            - plugins:
+
                            - plugins:
   - name: binpack
     arguments:
       binpack.weight: 10
@@ -131,70 +130,70 @@ server_key: ''
                            binpack.resources.example.com/foo: 3

                            conformance

                            +

                            conformance

                            The conformance plugin considers that the tasks in namespace kube-system have a higher priority. These tasks will not be preempted.

                            +

                            The conformance plugin considers that the tasks in namespace kube-system have a higher priority. These tasks will not be preempted.

                            -

                            +

                            -

                            -

                            +

                            -

                            gang

                            +

                            gang

                            The gang plugin considers a group of pods as a whole to allocate resources.

                            +

                            The gang plugin considers a group of pods as a whole to allocate resources.

                            -

                            +

                            -

                            -

                            +

                            -

                            priority

                            +

                            priority

                            The priority plugin schedules pods based on the custom workload priority.

                            +

                            The priority plugin schedules pods based on the custom workload priority.

                            -

                            +

                            -

                            -

                            +

                            -

                            overcommit

                            +

                            overcommit

                            Resources in a cluster are scheduled after being accumulated in a certain multiple to improve the workload enqueuing efficiency. If all workloads are Deployments, remove this plugin or set the raising factor to 2.0.

                            +

                            Resources in a cluster are scheduled after being accumulated in a certain multiple to improve the workload enqueuing efficiency. If all workloads are Deployments, remove this plugin or set the raising factor to 2.0.

                            overcommit-factor: Raising factor. Defaults to 1.2.

                            +

                            overcommit-factor: Raising factor. Defaults to 1.2.

                            - plugins:
+
                            - plugins:
   - name: overcommit
     arguments:
       overcommit-factor: 2.0

                            drf

                            +

                            drf

                            The DRF plugin schedules resources based on the container group Domaint Resource. The smallest Domaint Resource would be selected for priority scheduling.

                            +

                            The DRF plugin schedules resources based on the container group Domaint Resource. The smallest Domaint Resource would be selected for priority scheduling.

                            -

                            +

                            -

                            -

                            +

                            -

                            predicates

                            +

                            predicates

                            Determines whether a task is bound to a node by using a series of evaluation algorithms, such as node/pod affinity, taint tolerance, node port repetition, volume limits, and volume zone matching.

                            +

                            Determines whether a task is bound to a node by using a series of evaluation algorithms, such as node/pod affinity, taint tolerance, node port repetition, volume limits, and volume zone matching.

                            -

                            +

                            -

                            -

                            +

                            -

                            nodeorder

                            +

                            nodeorder

                            The nodeorder plugin scores all nodes for a task by using a series of scoring algorithms.

                            +

                            The nodeorder plugin scores all nodes for a task by using a series of scoring algorithms.

                            • nodeaffinity.weight: Pods are scheduled based on the node affinity. Defaults to 1.
                            • podaffinity.weight: Pods are scheduled based on the pod affinity. Defaults to 1.
                            • leastrequested.weight: Pods are scheduled to the node with the least resources. Defaults to 1.
                            • balancedresource.weight: Pods are scheduled to the node with balanced resource. Defaults to 1.
                            • mostrequested.weight: Pods are scheduled to the node with the most requested resources. Defaults to 0.
                            • tainttoleration.weight: Pods are scheduled to the node with a high taint tolerance. Defaults to 1.
                            • imagelocality.weight: Pods are scheduled to the node where the required images exist. Defaults to 1.
                            • selectorspread.weight: Pods are evenly scheduled to different nodes. Defaults to 0.
                            • volumebinding.weight: Pods are scheduled to the node with the local PV delayed binding policy. Defaults to 1.
                            • podtopologyspread.weight: Pods are scheduled based on the pod topology. Defaults to 2.
                            +
                            • nodeaffinity.weight: Pods are scheduled based on the node affinity. Defaults to 1.
                            • podaffinity.weight: Pods are scheduled based on the pod affinity. Defaults to 1.
                            • leastrequested.weight: Pods are scheduled to the node with the least resources. Defaults to 1.
                            • balancedresource.weight: Pods are scheduled to the node with balanced resource. Defaults to 1.
                            • mostrequested.weight: Pods are scheduled to the node with the most requested resources. Defaults to 0.
                            • tainttoleration.weight: Pods are scheduled to the node with a high taint tolerance. Defaults to 1.
                            • imagelocality.weight: Pods are scheduled to the node where the required images exist. Defaults to 1.
                            • selectorspread.weight: Pods are evenly scheduled to different nodes. Defaults to 0.
                            • volumebinding.weight: Pods are scheduled to the node with the local PV delayed binding policy. Defaults to 1.
                            • podtopologyspread.weight: Pods are scheduled based on the pod topology. Defaults to 2.
                            - plugins:
+
                            - plugins:
   - name: nodeorder
     arguments:
       leastrequested.weight: 1
@@ -208,76 +207,76 @@ server_key: ''
                            podtopologyspread.weight: 2

                            cce-gpu-topology-predicate

                            +

                            cce-gpu-topology-predicate

                            GPU-topology scheduling preselection algorithm

                            +

                            GPU-topology scheduling preselection algorithm

                            -

                            +

                            -

                            -

                            +

                            -

                            cce-gpu-topology-priority

                            +

                            cce-gpu-topology-priority

                            GPU-topology scheduling priority algorithm

                            +

                            GPU-topology scheduling priority algorithm

                            -

                            +

                            -

                            -

                            +

                            -

                            cce-gpu

                            +

                            cce-gpu

                            Works with the gpu add-on of CCE to support GPU resource allocation and decimal GPU configuration.

                            +

                            Works with the gpu add-on of CCE to support GPU resource allocation and decimal GPU configuration.

                            -

                            +

                            -

                            -

                            +

                            -

                            numaaware

                            +

                            numaaware

                            NUMA topology scheduling

                            +

                            NUMA topology scheduling

                            weight: Weight of the numa-aware plugin.

                            +

                            weight: Weight of the numa-aware plugin.

                            -

                            +

                            -

                            networkresource

                            +

                            networkresource

                            The ENI requirement node can be preselected and filtered. The parameters are transferred by CCE and do not need to be manually configured.

                            +

                            The ENI requirement node can be preselected and filtered. The parameters are transferred by CCE and do not need to be manually configured.

                            NetworkType: Network type (eni or vpc-router).

                            +

                            NetworkType: Network type (eni or vpc-router).

                            -

                            +

                            -

                            nodelocalvolume

                            +

                            nodelocalvolume

                            The nodelocalvolume plugin filters out nodes that do not meet local volume requirements can be filtered out.

                            +

                            The nodelocalvolume plugin filters out nodes that do not meet local volume requirements can be filtered out.

                            -

                            +

                            -

                            -

                            +

                            -

                            nodeemptydirvolume

                            +

                            nodeemptydirvolume

                            The nodeemptydirvolume plugin filters out nodes that do not meet the emptyDir requirements.

                            +

                            The nodeemptydirvolume plugin filters out nodes that do not meet the emptyDir requirements.

                            -

                            +

                            -

                            -

                            +

                            -

                            nodeCSIscheduling

                            +

                            nodeCSIscheduling

                            The nodeCSIscheduling plugin filters out nodes that have the everest component exception.

                            +

                            The nodeCSIscheduling plugin filters out nodes that have the everest component exception.

                            -

                            +

                            -

                            -

                            +

                            -
                            Table 1 Cluster upgrade paths and impacts

                            Source Version

                            +
                            - - - - - - - - + + + + + + + + - - - - - - -
                            Table 1 Cluster upgrade paths and impacts

                            Source Version

                            Target Version

                            +

                            Target Version

                            Upgrade Modes

                            -

                            Impacts

                            +

                            Upgrade Modes

                            v1.19

                            +

                            v1.23

                            v1.21

                            +

                            v1.25

                            In-place upgrade

                            -

                            You need to learn about the differences between versions. For details, see Precautions for Major Version Upgrade.

                            +

                            In-place upgrade

                            v1.17

                            +

                            v1.21

                            +

                            v1.25

                            +

                            v1.23

                            +

                            In-place upgrade

                            +

                            v1.19

                            +

                            v1.23

                            +

                            v1.21

                            +

                            +

                            In-place upgrade

                            +

                            v1.17

                            v1.15

                            v1.19

                            +

                            v1.19

                            In-place upgrade

                            -

                            You need to learn about the differences between versions. For details, see Precautions for Major Version Upgrade.

                            +

                            In-place upgrade

                            v1.13

                            +

                            v1.13

                            v1.15

                            +

                            v1.15

                            Rolling upgrade

                            +

                            Rolling upgrade

                            Replace upgrade

                            • proxy in the coredns add-on cannot be configured and needs to be replaced with forward.
                            • The storage add-on is changed from storage-driver to everest.
                            -
                            @@ -99,78 +108,6 @@
                            -

                            Precautions for Major Version Upgrade

                            -
                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

                            Upgrade Path

                            -

                            Difference

                            -

                            Self-Check

                            -

                            v1.19 to v1.21

                            -

                            The bug of exec probe timeouts is fixed in Kubernetes 1.21. Before this bug fix, the exec probe does not consider the timeoutSeconds field. Instead, the probe will run indefinitely, even beyond its configured deadline. It will stop until the result is returned. If this field is not specified, the default value 1 is used. This field takes effect after the upgrade. If the probe runs over 1 second, the application health check may fail and the application may restart frequently.

                            -

                            Before the upgrade, check whether the timeout is properly set for the exec probe.

                            -

                            kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly.

                            -

                            Root cause: X.509 CommonName is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. If your webhook certificate does not have SANs, kube-apiserver does not process the CommonName field of the X.509 certificate as the host name by default. As a result, the authentication fails.

                            -

                            Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server.

                            -
                            • If you do not have your own webhook server, you can skip this check.
                            • If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate.
                            -

                            v1.15 to v1.19

                            -

                            The control plane of CCE 1.19 is incompatible with Kubelet 1.15. If the master node fails to be upgraded or the node to be upgraded restarts after the master node is successfully upgraded, there is a high probability that the node is in the NotReady status.

                            -

                            There is a high probability that kubelet restarts on the node that fails to be upgraded, triggering the node registration process. The default registration labels of kubelet 1.15 (failure-domain.beta.kubernetes.io/is-baremetal and kubernetes.io/availablezone) are regarded as an invalid label by kube-apiserver 1.19.

                            -

                            The valid labels in v1.19 are node.kubernetes.io/baremetal and failure-domain.beta.kubernetes.io/zone.

                            -
                            1. In normal cases, this scenario is not triggered.
                            2. After the master node is upgraded, do not suspend the upgrade. Upgrade the node quickly.
                            3. If a node fails to be upgraded and cannot be restored, evict applications on the node as soon as possible. Contact technical support and skip the node upgrade. After the upgrade is complete, reset the node.
                            -

                            In CCE 1.15 and 1.19 clusters, the Docker storage driver file system is switched from XFS to Ext4. As a result, the import package sequence in the pods of the upgraded Java application may be abnormal, causing pod exceptions.

                            -

                            Before the upgrade, check the Docker configuration file /etc/docker/daemon.json on the node. Check whether the value of dm.fs is xfs.

                            -
                            • If the value is ext4 or the storage driver is Overlay, you can skip the next steps.
                            • If the value is xfs, you are advised to deploy applications in the cluster of the new version in advance to test whether the applications are compatible with the new cluster version.
                            -
                            {
-      "storage-driver": "devicemapper",
-      "storage-opts": [
-      "dm.thinpooldev=/dev/mapper/vgpaas-thinpool",
-      "dm.use_deferred_removal=true",
-      "dm.fs=xfs",
-      "dm.use_deferred_deletion=true"
-      ]
-}
                            -

                            kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly.

                            -

                            Root cause: X.509 CommonName is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. The CommonName field is processed as the host name. As a result, the authentication fails.

                            -

                            Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server.

                            -
                            • If you do not have your own webhook server, you can skip this check.
                            • If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate.
                            -
                            NOTICE:

                            To mitigate the impact of version differences on cluster upgrade, CCE performs special processing during the upgrade from 1.15 to 1.19 and still supports certificates without SANs. However, no special processing is required for subsequent upgrades. You are advised to rectify your certificate as soon as possible.

                            -
                            -

                            In clusters of v1.17.17 and later, CCE automatically creates pod security policies (PSPs) for you, which restrict the creation of pods with unsafe configurations, for example, pods for which net.core.somaxconn under a sysctl is configured in the security context.

                            -

                            After an upgrade, you can allow insecure system configurations as required. For details, see Configuring a Pod Security Policy.

                            -

                            v1.13 to v1.15

                            -

                            After a VPC network cluster is upgraded, the master node occupies an extra CIDR block due to the upgrade of network components. If no container CIDR block is available for the new node, the pod scheduled to the node cannot run.

                            -

                            Generally, this problem occurs when the nodes in the cluster are about to fully occupy the container CIDR block. For example, the container CIDR block is 10.0.0.0/16, the number of available IP addresses is 65,536, and the VPC network is allocated a CIDR block with the fixed size (using the mask to determine the maximum number of container IP addresses allocated to each node). If the upper limit is 128, the cluster supports a maximum of 512 (65536/128) nodes, including the three master nodes. After the cluster is upgraded, each of the three master nodes occupies one CIDR block. As a result, 506 nodes are supported.

                            -
                            -
                            -
                            diff --git a/docs/cce/umn/cce_10_0198.html b/docs/cce/umn/cce_10_0198.html index 711b41f2..7e57d1af 100644 --- a/docs/cce/umn/cce_10_0198.html +++ b/docs/cce/umn/cce_10_0198.html @@ -27,8 +27,8 @@

                            Container Engine

                            CCE clusters support Docker. Starting from CCE 1.23, containerd is supported.

                            -

                            For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.

                            +
                            CCE clusters support Docker and containerd in some scenarios.
                            • VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd.
                            • For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.
                            +

                            OS

                            @@ -39,8 +39,8 @@

                            Login Mode

                            • Key Pair

                              Select the key pair used to log in to the node. You can select a shared key.

                              -

                              A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.

                              +
                            • Key Pair

                              Select the key pair used to log in to the node. You can select a shared key.

                              +

                              A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.
                            - - - + + + + - @@ -285,7 +294,7 @@

                          7. Click OK.
                            8. -

                            References

                            +

                            References

                            diff --git a/docs/cce/umn/cce_10_0214.html b/docs/cce/umn/cce_10_0214.html index 6b4b34c0..c4ae67c3 100644 --- a/docs/cce/umn/cce_10_0214.html +++ b/docs/cce/umn/cce_10_0214.html @@ -7,9 +7,9 @@

                            Notes and Constraints

                            During cluster wakeup, the master node may fail to be started due to insufficient resources. As a result, the cluster fails to be woken up. Wait for a while and wake up the cluster again.

                            -

                            Hibernating a Cluster

                            1. Log in to the CCE console. In the navigation pane, choose Clusters.
                            2. Click next to the cluster to be hibernated.
                            3. In the dialog box displayed, check the precautions and click Yes. Wait until the cluster is hibernated.
                            +

                            Hibernating a Cluster

                            1. Log in to the CCE console. In the navigation pane, choose Clusters.
                            2. Click next to the cluster to be hibernated.
                            3. In the dialog box displayed, check the precautions and click Yes. Wait until the cluster is hibernated.
                            -

                            Waking Up a Cluster

                            1. Log in to the CCE console. In the navigation pane, choose Clusters.
                            2. Click next to the cluster to be woken up.
                            3. When the cluster status changes from Waking to Running, the cluster is woken up. It takes about 3 to 5 minutes to wake up the cluster.
                            +

                            Waking Up a Cluster

                            1. Log in to the CCE console. In the navigation pane, choose Clusters.
                            2. Click next to the cluster to be woken up.
                            3. When the cluster status changes from Waking to Running, the cluster is woken up. It takes about 3 to 5 minutes to wake up the cluster.
                            diff --git a/docs/cce/umn/cce_10_0215.html b/docs/cce/umn/cce_10_0215.html index 9e1c9cbc..213539a7 100644 --- a/docs/cce/umn/cce_10_0215.html +++ b/docs/cce/umn/cce_10_0215.html @@ -8,12 +8,16 @@
                          8. Before You Start
                            9. +
                          9. Post-Upgrade Verification
                            +
                          10. Performing Replace/Rolling Upgrade
                          11. Performing In-place Upgrade
                          12. Migrating Services Across Clusters of Different Versions
                            13. +
                          13. Troubleshooting for Pre-upgrade Check Exceptions
                            +
                            14. diff --git a/docs/cce/umn/cce_10_0216.html b/docs/cce/umn/cce_10_0216.html index c0c4c3ac..242320e7 100644 --- a/docs/cce/umn/cce_10_0216.html +++ b/docs/cce/umn/cce_10_0216.html @@ -9,7 +9,7 @@

                            Prerequisites

                            You must have one cluster available before creating a DaemonSet. For details on how to create a cluster, see Creating a CCE Cluster.

                            -

                            Using the CCE Console

                            1. Log in to the CCE console.
                            2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
                            3. Set basic information about the workload.

                              Basic Info
                              • Workload Type: Select DaemonSet. For details about workload types, see Overview.
                              • Workload Name: Enter the name of the workload.
                              • Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                              • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                              • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
                              +

                              Using the CCE Console

                              1. Log in to the CCE console.
                              2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
                              3. Set basic information about the workload.

                                Basic Info
                                • Workload Type: Select DaemonSet. For details about workload types, see Overview.
                                • Workload Name: Enter the name of the workload. Enter 1 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 of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
                                • Container Runtime: A CCE cluster uses runC by default, whereas a CCE Turbo cluster supports both runC and Kata. For details about the differences between runC and Kata, see Kata Containers and Common Containers.
                                • Time Zone Synchronization: Specify whether to enable time zone synchronization. After time zone synchronization is enabled, the container and node use the same time zone. The time zone synchronization function depends on the local disk mounted to the container. Do not modify or delete the time zone. For details, see Configuring Time Zone Synchronization.
                                Container Settings
                              diff --git a/docs/cce/umn/cce_10_0222.html b/docs/cce/umn/cce_10_0222.html index cbe4ccd7..2d5bab8e 100644 --- a/docs/cce/umn/cce_10_0222.html +++ b/docs/cce/umn/cce_10_0222.html @@ -1,409 +1,25 @@

                              Managing a Node Pool

                              -

                              Notes and Constraints

                              The default node pool DefaultPool does not support the following management operations.

                              -
                              -

                              Configuring Kubernetes Parameters

                              CCE allows you to highly customize Kubernetes parameter settings on core components in a cluster. For more information, see kubelet.

                              -

                              This function is supported only in clusters of v1.15 and later. It is not displayed for clusters earlier than v1.15.

                              -
                              1. Log in to the CCE console.
                              2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                              3. Choose More > Manage next to the node pool name.
                              4. On the Manage Component page on the right, change the values of the following Kubernetes parameters:

                                -

                            Table 1 Extended controller parameters

                            Parameter

                            Description

                            @@ -52,25 +52,23 @@

                            Maximum number of concurrent mutating requests. When the value of this parameter is exceeded, the server rejects requests.

                            The value 0 indicates no limitation.

                            -

                            Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale.

                            -
                            • 200 for clusters with 50 or 200 nodes
                            • 500 for clusters with 1,000 nodes
                            • 1000 for clusters with 2,000 nodes

                            Default: 1000

                            +

                            Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale.

                            +
                            • 200 for clusters with 50 or 200 nodes
                            • 500 for clusters with 1,000 nodes
                            • 1000 for clusters with 2,000 nodes

                            max-requests-inflight

                            Maximum number of concurrent non-mutating requests. When the value of this parameter is exceeded, the server rejects requests.

                            -

                            The value 0 indicates no limitation.

                            -

                            Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale.

                            -
                            • 400 for clusters with 50 or 200 nodes
                            • 1000 for clusters with 1,000 nodes
                            • 2000 for clusters with 2,000 nodes
                            +

                            The value 0 indicates no limitation.

                            Default: 2000

                            +

                            Manual configuration is no longer supported since cluster v1.21. The value is automatically specified based on the cluster scale.

                            +
                            • 400 for clusters with 50 or 200 nodes
                            • 1000 for clusters with 1,000 nodes
                            • 2000 for clusters with 2,000 nodes

                            service-node-port-range

                            Range of node port numbers.

                            +

                            NodePort port range. After changing the value, you need to go to the security group page to change the TCP/UDP port range of node security groups 30000 to 32767. Otherwise, ports other than the default port cannot be accessed externally.

                            Default:

                            30000-32767

                            @@ -172,10 +170,21 @@

                            concurrent_rc_syncs

                            Number of replication controllers that are allowed to synchronize concurrently.

                            +
                            NOTE:

                            This parameter is used only in clusters of v1.19 or earlier.

                            +

                            Default: 5

                            concurrent-rc-syncs

                            +

                            Number of replication controllers that are allowed to synchronize concurrently.

                            +
                            NOTE:

                            This parameter is used only in clusters of v1.21 to v1.23. In clusters of v1.25 and later, this parameter is deprecated (officially deprecated from v1.25.3-r0 on).

                            +
                            +

                            Default: 5

                            +

                            horizontal-pod-autoscaler-sync-period

                            How often HPA audits metrics in a cluster.

                            @@ -273,7 +282,7 @@

                            prebound-subeni-percentage

                            Low threshold of the number of bound ENIs:High threshold of the number of bound ENIs

                            +

                            Low threshold of the number of bound ENIs : High threshold of the number of bound ENIs

                            NOTE:

                            This parameter is discarded. Use the other four dynamic preheating parameters of the ENI.
                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                            Table 1 kubelet

                            Parameter

                            -

                            Description

                            -

                            Default Value

                            -

                            Remarks

                            -

                            cpu-manager-policy

                            -

                            Specifies the CPU core binding configuration. For details, see CPU Core Binding.

                            -
                            • none: disables pods from exclusively occupying CPUs. Select this value if you want a large pool of shareable CPU cores.
                            • static: enables pods to exclusively occupy CPUs. Select this value if your workload is sensitive to latency in CPU cache and scheduling.
                            -

                            none

                            -

                            The values can be modified during the node pool lifecycle.

                            -

                            kube-api-qps

                            -

                            Query per second (QPS) to use while talking with kube-apiserver.

                            -

                            100

                            -

                            kube-api-burst

                            -

                            Burst to use while talking with kube-apiserver.

                            -

                            100

                            -

                            max-pods

                            -

                            Maximum number of pods managed by kubelet.

                            -

                            40

                            -

                            20

                            -

                            pod-pids-limit

                            -

                            PID limit in Kubernetes

                            -

                            -1

                            -

                            with-local-dns

                            -

                            Whether to use the local IP address as the ClusterDNS of the node.

                            -

                            false

                            -

                            event-qps

                            -

                            QPS limit for event creation

                            -

                            5

                            -

                            allowed-unsafe-sysctls

                            -

                            Insecure system configuration allowed.

                            -

                            Starting from v1.17.17, CCE enables pod security policies for kube-apiserver. You need to add corresponding configurations to allowedUnsafeSysctls of a pod security policy to make the policy take effect. (This configuration is not required for clusters earlier than v1.17.17.) For details, see Example of Enabling Unsafe Sysctls in Pod Security Policy.

                            -

                            []

                            -

                            over-subscription-resource

                            -

                            Whether to enable node oversubscription.

                            -

                            If this parameter is set to true, the node oversubscription feature is enabled. For details, see Hybrid Deployment of Online and Offline Jobs.

                            -

                            true

                            -

                            -

                            -

                            colocation

                            -

                            Whether to enable node hybrid deployment.

                            -

                            If this parameter is set to true, the node hybrid deployment feature is enabled. For details, see Hybrid Deployment of Online and Offline Jobs.

                            -

                            true

                            -

                            -

                            -

                            kube-reserved-mem

                            -

                            system-reserved-mem

                            -

                            Reserved node memory.

                            -

                            Depends on node specifications. For details, see Formula for Calculating the Reserved Resources of a Node.

                            -

                            The sum of kube-reserved-mem and system-reserved-mem is less than half of the memory.

                            -

                            topology-manager-policy

                            -

                            Set the topology management policy.

                            -

                            Valid values are as follows:

                            -
                            • restricted: kubelet accepts only pods that achieve optimal NUMA alignment on the requested resources.
                            • best-effort: kubelet preferentially selects pods that implement NUMA alignment on CPU and device resources.
                            • none (default): The topology management policy is disabled.
                            • single-numa-node: kubelet allows only pods that are aligned to the same NUMA node in terms of CPU and device resources.
                            -

                            none

                            -

                            The values can be modified during the node pool lifecycle.

                            -
                            NOTICE:

                            Exercise caution when modifying topology-manager-policy and topology-manager-scope will restart kubelet and recalculate the resource allocation of pods based on the modified policy. As a result, running pods may restart or even fail to receive any resources.

                            -

                            -
                            -

                            topology-manager-scope

                            -

                            Set the resource alignment granularity of the topology management policy. Valid values are as follows:

                            -
                            • container (default)
                            • pod
                            -

                            container

                            -

                            resolv-conf

                            -

                            DNS resolution configuration file specified by the container

                            -

                            The default value is null.

                            -

                            -

                            -
                            -
                            - -
                            - - - - - - - - - - - - - - - -
                            Table 2 kube-proxy

                            Parameter

                            -

                            Description

                            -

                            Default Value

                            -

                            Remarks

                            -

                            conntrack-min

                            -

                            sysctl -w net.nf_conntrack_max

                            -

                            131072

                            -

                            The values can be modified during the node pool lifecycle.

                            -

                            conntrack-tcp-timeout-close-wait

                            -

                            sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait

                            -

                            1h0m0s

                            -
                            -
                            - -
                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                            Table 3 Network components (available only for CCE Turbo clusters)

                            Parameter

                            -

                            Description

                            -

                            Default Value

                            -

                            Remarks

                            -

                            nic-threshold

                            -

                            Low threshold of the number of bound ENIs:High threshold of the number of bound ENIs

                            -
                            NOTE:

                            This parameter is being discarded. Use the dynamic pre-binding parameters of the other four ENIs.

                            -
                            -

                            Default: 0:0

                            -

                            -

                            -

                            nic-minimum-target

                            -

                            Minimum number of ENIs bound to the nodes in the node pool

                            -

                            Default: 10

                            -

                            -

                            -

                            nic-maximum-target

                            -

                            Maximum number of ENIs pre-bound to a node at the node pool level

                            -

                            Default: 0

                            -

                            -

                            -

                            nic-warm-target

                            -

                            Number of ENIs pre-bound to a node at the node pool level

                            -

                            Default: 2

                            -

                            -

                            -

                            nic-max-above-warm-target

                            -

                            Reclaim number of ENIs pre-bound to a node at the node pool level

                            -

                            Default: 2

                            -

                            -

                            -
                            -
                            - -
                            - - - - - - - - - - - -
                            Table 4 Pod security group in a node pool (available only for CCE Turbo clusters)

                            Parameter

                            -

                            Description

                            -

                            Default Value

                            -

                            Remarks

                            -

                            security_groups_for_nodepool

                            -
                            • Default security group used by pods in a node pool. You can enter the security group ID. If this parameter is not set, the default security group of the cluster container network is used. A maximum of five security group IDs can be specified at the same time, separated by semicolons (;).
                            • The priority of the security group is lower than that of the security group configured for the SecurityGroup resource object.
                            -

                            -

                            -

                            -

                            -
                            -
                            - -
                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                            Table 5 Docker (available only for node pools that use Docker)

                            Parameter

                            -

                            Description

                            -

                            Default Value

                            -

                            Remarks

                            -

                            native-umask

                            -

                            `--exec-opt native.umask

                            -

                            normal

                            -

                            Cannot be changed.

                            -

                            docker-base-size

                            -

                            `--storage-opts dm.basesize

                            -

                            0

                            -

                            Cannot be changed.

                            -

                            insecure-registry

                            -

                            Address of an insecure image registry

                            -

                            false

                            -

                            Cannot be changed.

                            -

                            limitcore

                            -

                            Maximum size of a core file in a container. The unit is byte.

                            -

                            5368709120

                            -

                            -

                            -

                            default-ulimit-nofile

                            -

                            Limit on the number of handles in a container

                            -

                            {soft}:{hard}

                            -

                            The value cannot exceed the value of the kernel parameter nr_open and cannot be a negative number.

                            -

                            You can run the following command to obtain the kernel parameter nr_open:

                            -
                            sysctl -a | grep nr_open
                            -
                            -
                            -

                          14. Click OK.
                            15. - -

                            Editing a Node Pool

                            1. Log in to the CCE console.
                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                            3. Click Edit next to the name of the node pool you will edit. In the Edit Node Pool page, edit the following parameters:

                              Basic Settings -
                              - - - - - - - - - - -
                              Table 6 Basic settings

                              Parameter

                              -

                              Description

                              -

                              Node Pool Name

                              -

                              Name of the node pool.

                              -

                              Auto Scaling

                              -

                              By default, this parameter is disabled.

                              -

                              After you enable autoscaler by clicking , nodes in the node pool are automatically created or deleted based on service requirements.

                              -
                              • Maximum Nodes and Minimum Nodes: You can set the maximum and minimum number of nodes to ensure that the number of nodes to be scaled is within a proper range.
                              • Priority: A larger value indicates a higher priority. For example, if this parameter is set to 1 and 4 respectively for node pools A and B, B has a higher priority than A, and auto scaling is first triggered for B. If the priorities of multiple node pools are set to the same value, for example, 2, the node pools are not prioritized and the system performs scaling based on the minimum resource waste principle.
                              • Cooldown Period: Required. The unit is minute. This parameter indicates the interval between the previous scale-out action and the next scale-in action.
                              -

                              If the Autoscaler field is set to on, install the autoscaler add-on to use the autoscaler feature.

                              -
                              -
                              -
                              -
                              Advanced Settings -
                              - - - - - - - - - - - - - - - - -
                              Table 7 Advanced settings

                              Parameter

                              -

                              Description

                              -

                              K8s label

                              -

                              Click Add Label to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.

                              -

                              Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.

                              -
                              NOTE:

                              After a K8s label is modified, the inventory nodes in the node pool are updated synchronously.

                              -
                              -

                              Resource Tag

                              -

                              You can add resource tags to classify resources.

                              -

                              You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency.

                              -

                              CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag.

                              -
                              NOTE:

                              After a resource tag is modified, the modification automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the modification to take effect.

                              -
                              -

                              Taint

                              -
                              This field is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
                              • Key: A key must contain 1 to 63 characters starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
                              • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
                              • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
                              -
                              -

                              For details, see Managing Node Taints.

                              -
                              NOTE:

                              After a taint is modified, the inventory nodes in the node pool are updated synchronously.

                              -
                              -

                              Edit Key pair

                              -

                              Only node pools that use key pairs for login support key pair editing. You can select another key pair.

                              -
                              NOTE:

                              The edited key pair automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the key pair to take effect.

                              -
                              -
                              -
                              -
                              -

                            4. Click OK.

                              In the node pool list, the node pool status becomes Scaling. After the status changes to Completed, the node pool parameters are modified successfully. The modified configuration will be synchronized to all nodes in the node pool.

                              -

                            -
                            -

                            Deleting a Node Pool

                            Deleting a node pool will delete nodes in the pool. Pods on these nodes will be automatically migrated to available nodes in other node pools. If pods in the node pool have a specific node selector and none of the other nodes in the cluster satisfies the node selector, the pods will become unschedulable.

                            -
                            1. Log in to the CCE console.
                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                            3. Choose More > Delete next to a node pool name to delete the node pool.
                            4. Read the precautions in the Delete Node Pool dialog box.
                            5. In the text box, click Yes to confirm that you want to continue the deletion.
                            -
                            -

                            Copying a Node Pool

                            You can copy the configuration of an existing node pool to create a new node pool on the CCE console.

                            -
                            1. Log in to the CCE console.
                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                            3. Choose More > Copy next to a node pool name to copy the node pool.
                            4. The configurations of the selected node pool are replicated to the Clone Node Pool page. You can edit the configurations as required and click Next: Confirm.
                            5. On the Confirm page, confirm the node pool configuration and click Create Now. Then, a new node pool is created based on the edited configuration.
                            -
                            -

                            Migrating a Node

                            Nodes in a node pool can be migrated. Currently, nodes in a node pool can be migrated only to the default node pool (defaultpool) in the same cluster.

                            -
                            1. Log in to the CCE console and click the cluster name to access the cluster.
                            2. In the navigation pane, choose Nodes and switch to the Node Pools tab page.
                            3. Click View Node in the Operation column of the node pool to be migrated.
                            4. Select the nodes to be migrated and choose More > Migrate to migrate the nodes to the default node pool in batches.

                              You can also choose More > Migrate in the Operation column of a single node to migrate the node.

                              -

                              -

                            5. In the displayed Migrate Node window, confirm the information.

                              The migration has no impacts on the original resource tags, Kubernetes labels, and taints of the node.

                              -
                              -

                            -
                            - +
                            + +
                            Parent topic: Node Pools
                            diff --git a/docs/cce/umn/cce_10_0232.html b/docs/cce/umn/cce_10_0232.html index 28cd9a17..00ec365e 100644 --- a/docs/cce/umn/cce_10_0232.html +++ b/docs/cce/umn/cce_10_0232.html @@ -174,7 +174,7 @@ gpu-585455d466-t56cm 1/1 Running 0 2m29s 172.16.0.64 192.16 gpu-585455d466-t5w5x 1/1 Running 0 2m29s 172.16.0.41 192.168.0.212

                            In the preceding example, the node scheduling priority is as follows. Nodes with both SSD and gpu=true labels have the highest priority. Nodes with the SSD label but no gpu=true label have the second priority (weight: 80). Nodes with the gpu=true label but no SSD label have the third priority. Nodes without any of these two labels have the lowest priority.

                            -
                            Figure 1 Scheduling priority
                            +
                            Figure 1 Scheduling priority

                            Workload Affinity (podAffinity)

                            Node affinity rules affect only the affinity between pods and nodes. Kubernetes also supports configuring inter-pod affinity rules. For example, the frontend and backend of an application can be deployed together on one node to reduce access latency. There are also two types of inter-pod affinity rules: requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution.

                            Assume that the backend of an application has been created and has the app=backend label.

                            $ kubectl get po -o wide
@@ -229,7 +229,7 @@ backend-658f6cb858-dlrz8    1/1     Running   0          5m38s   172.16.0.67   1
 frontend-67ff9b7b97-dsqzn   1/1     Running   0          6s      172.16.0.70   192.168.0.100
 frontend-67ff9b7b97-hxm5t   1/1     Running   0          6s      172.16.0.71   192.168.0.100
 frontend-67ff9b7b97-z8pdb   1/1     Running   0          6s      172.16.0.72   192.168.0.100
                            -

                            The topologyKey field specifies the selection range. The scheduler selects nodes within the range based on the affinity rule defined. The effect of topologyKey is not fully demonstrated in the preceding example because all the nodes have the kubernetes.io/hostname label, that is, all the nodes are within the range.

                            +

                            The topologyKey field specifies the selection range. The scheduler selects nodes within the range based on the affinity rule defined. The effect of topologyKey is not fully demonstrated in the preceding example because all the nodes have the kubernetes.io/hostname label, that is, all the nodes are within the range.

                            To see how topologyKey works, assume that the backend of the application has two pods, which are running on different nodes.

                            $ kubectl get po -o wide
 NAME                       READY   STATUS    RESTARTS   AGE     IP            NODE         
@@ -247,7 +247,7 @@ NAME            STATUS   ROLES    AGE   VERSION                            PREFE
 192.168.0.212   Ready    <none>   91m   v1.15.6-r1-20.3.0.2.B001-15.30.2   
 192.168.0.94    Ready    <none>   91m   v1.15.6-r1-20.3.0.2.B001-15.30.2   true
 192.168.0.97    Ready    <none>   91m   v1.15.6-r1-20.3.0.2.B001-15.30.2   true
                            -

                            Define topologyKey in the podAffinity section as prefer.

                            +

                            Define topologyKey in the podAffinity section as prefer. The node topology domains are divided as shown in Figure 2.

                                  affinity:
         podAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
@@ -258,7 +258,8 @@ NAME            STATUS   ROLES    AGE   VERSION                            PREFE
                 operator: In 
                 values: 
                 - backend
                            -

                            The scheduler recognizes the nodes with the prefer label, that is, 192.168.0.97 and 192.168.0.94, and then find the pods with the app=backend label. In this way, all frontend pods are deployed onto 192.168.0.97.

                            +
                            Figure 2 Topology domain example
                            +

                            During scheduling, node topology domains are divided based on the prefer label. In this example, 192.168.0.97 and 192.168.0.94 are divided into the same topology domain. If pods with the app=backend label run in 192.168.0.97, all frontend pods are deployed onto 192.168.0.97 or 192.168.0.94.

                            $ kubectl create -f affinity3.yaml 
 deployment.apps/frontend created
 
@@ -271,7 +272,7 @@ frontend-67ff9b7b97-hxm5t   1/1     Running   0          6s      172.16.0.71   1
 frontend-67ff9b7b97-z8pdb   1/1     Running   0          6s      172.16.0.72   192.168.0.97

                            Workload Anti-Affinity (podAntiAffinity)

                            Unlike the scenarios in which pods are preferred to be scheduled onto the same node, sometimes, it could be the exact opposite. For example, if certain pods are deployed together, they will affect the performance.

                            -

                            The following example defines an inter-pod anti-affinity rule, which specifies that pods must not be scheduled to nodes that already have pods with the app=frontend label, that is, to deploy the pods of the frontend to different nodes with each node has only one replica.

                            +

                            In the following example, an anti-affinity rule is defined. This rule indicates that node topology domains are divided based on the kubernetes.io/hostname label. If a pod with the app=frontend label already exists on a node in the topology domain, pods with the same label cannot be scheduled to other nodes in the topology domain.

                            apiVersion: apps/v1
 kind: Deployment
 metadata:
@@ -303,21 +304,21 @@ spec:
       affinity:
         podAntiAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
-          - topologyKey: kubernetes.io/hostname
-            labelSelector:
+          - topologyKey: kubernetes.io/hostname    # Node topology domain
+            labelSelector:    # Pod label matching rule
               matchExpressions: 
               - key: app
                 operator: In 
                 values: 
                 - frontend
                            -

                            Deploy the frontend and query the deployment results. You can find that each node has only one frontend pod and one pod of the Deployment is Pending. This is because when the scheduler is deploying the fifth pod, all nodes already have one pod with the app=frontend label on them. There is no available node. Therefore, the fifth pod will remain in the Pending status.

                            +

                            Create an anti-affinity rule and view the deployment result. In the example, node topology domains are divided by the kubernetes.io/hostname label. Among nodes with the kubernetes.io/hostname label, the label value of each node is different. Therefore, there is only one node in a topology domain. If a frontend pod already exists in a topology (a node in this example), the same pods will not be scheduled to this topology. In this example, there are only four nodes. Therefore, another pod is pending and cannot be scheduled.

                            $ kubectl create -f affinity4.yaml 
 deployment.apps/frontend created
 
 $ kubectl get po -o wide
 NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE         
 frontend-6f686d8d87-8dlsc   1/1     Running   0          18s   172.16.0.76   192.168.0.100
-frontend-6f686d8d87-d6l8p   0/1     Pending   0          18s   <none>        <none>       
+frontend-6f686d8d87-d6l8p   0/1     Pending   0          18s   <none>        <none>
 frontend-6f686d8d87-hgcq2   1/1     Running   0          18s   172.16.0.54   192.168.0.97 
 frontend-6f686d8d87-q7cfq   1/1     Running   0          18s   172.16.0.47   192.168.0.212
 frontend-6f686d8d87-xl8hx   1/1     Running   0          18s   172.16.0.23   192.168.0.94
                            @@ -342,7 +343,7 @@ frontend-6f686d8d87-xl8hx 1/1 Running 0 18s 172.16.0.23 192
                            -

                          15. Under Node Affinity, Workload Affinity, and Workload Anti-Affinity, click to add scheduling policies. In the dialog box displayed, add a policy directly or by specifying a node or an AZ.

                            Specifying a node or an AZ is essentially implemented through labels. The kubernetes.io/hostname label is used when you specify a node, and the failure-domain.beta.kubernetes.io/zone label is used when you specify an AZ. +

                          16. Under Node Affinity, Workload Affinity, and Workload Anti-Affinity, click to add scheduling policies. In the dialog box displayed, add a policy directly or by specifying a node or an AZ.

                            Specifying a node or an AZ is essentially implemented through labels. The kubernetes.io/hostname label is used when you specify a node, and the failure-domain.beta.kubernetes.io/zone label is used when you specify an AZ.
                            - @@ -281,7 +281,7 @@ spec: @@ -387,7 +387,7 @@ ingress-test * 121.**.**.** 80 10s

                            Creating an Ingress - Interconnecting with an Existing Load Balancer

                            CCE allows you to connect to an existing load balancer when creating an ingress.
                            • Existing dedicated load balancers must be the application type (HTTP/HTTPS) supporting private networks (with a private IP).
                            -
                            If the cluster version is 1.23 or earlier, the YAML file configuration is as follows:
                            apiVersion: networking.k8s.io/v1
+
                            If the cluster version is 1.23 or later, the YAML file configuration is as follows:
                            apiVersion: networking.k8s.io/v1
 kind: Ingress 
 metadata: 
   name: ingress-test
@@ -411,14 +411,14 @@ spec:
         pathType: ImplementationSpecific
   ingressClassName: cce               
                            
 
                            
-
                            If the cluster version is 1.21 or later, the YAML file configuration is as follows:
                            
+
                            If the cluster version is 1.21 or earlier, the YAML file configuration is as follows:
                            
 
                            apiVersion: networking.k8s.io/v1beta1
 kind: Ingress 
 metadata: 
   name: ingress-test
   annotations: 
-    kubernetes.io/elb.id: <your_elb_id>  # Replace it with the ID of your existing load balancer.
-    kubernetes.io/elb.ip: <your_elb_ip>  # Replace it with your existing load balancer IP.
+    kubernetes.io/elb.id: <your_elb_id>  # Replace it with the ID of your existing load balancer.
+    kubernetes.io/elb.ip: <your_elb_ip>  # Replace it with your existing load balancer IP.
     kubernetes.io/elb.port: '80'
     kubernetes.io/ingress.class: cce
 spec:
@@ -685,7 +685,7 @@ spec:
           servicePort: 80                   # Replace it with the port number of your target Service.
         property:
           ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
                            
-
                            For clusters of v1.23 or later:
                            apiVersion: networking.k8s.io/v1
+
                            For clusters of v1.23 or later:
                            apiVersion: networking.k8s.io/v1
 kind: Ingress 
 metadata: 
   name: ingress-test
@@ -782,7 +782,7 @@ spec:
         property:
           ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
                            
 
                            
-
                            For clusters of v1.23 or later:
                            apiVersion: networking.k8s.io/v1
+
                            For clusters of v1.23 or later:
                            apiVersion: networking.k8s.io/v1
 kind: Ingress 
 metadata: 
   name: ingress-test
@@ -803,10 +803,10 @@ spec:
   tls: 
   - secretName: ingress-test-secret
   - hosts:
-      - example.top  # Domain name specified a certificate is issued
+      - example.top  # Domain name specified a certificate is issued
     secretName: sni-test-secret-1  
   - hosts:
-      - example.com  # Domain name specified a certificate is issued
+      - example.com  # Domain name specified a certificate is issued
     secretName: sni-test-secret-2
   rules: 
   - host: ''
@@ -854,6 +854,40 @@ spec:
         property:
           ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
                            
 
                            
+
                            Interconnecting with HTTPS Backend Services
                            Ingress can interconnect with backend services of different protocols. By default, the backend proxy channel of an ingress is an HTTP channel. To create an HTTPS channel, add the following configuration to the annotations field:
                            
+
                            kubernetes.io/elb.pool-protocol: https
                            
+
                             
                            • This feature only applies to clusters of v1.23.8, v1.25.3, and later.
                            • Ingress can interconnect with HTTPS backend services only when dedicated load balancers are used.
                            • When interconnecting with HTTPS backend services, set Client Protocol of ingress to HTTPS.
                            
+
                            
+
                            An ingress configuration example is as follows:
                            
+
                            apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: ingress-test
+  namespace: default
+  annotations:
+    kubernetes.io/elb.port: '443'
+    kubernetes.io/elb.id: <your_elb_id>    # In this example, an existing dedicated load balancer is used. Replace its ID with the ID of your dedicated load balancer.
+    kubernetes.io/elb.class: performance
+    kubernetes.io/elb.pool-protocol: https  # Interconnected HTTPS backend service
+    kubernetes.io/elb.tls-ciphers-policy: tls-1-2
+spec:
+  tls: 
+    - secretName: ingress-test-secret
+  rules:
+    - host: ''
+      http:
+        paths:
+          - path: '/'
+            backend:
+              service:
+                name: <your_service_name>  # Replace it with the name of your target Service.
+                port:
+                  number: 80
+            property:
+              ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
+            pathType: ImplementationSpecific
+  ingressClassName: cce
                            
+
                            
 
                            
 
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0257.html b/docs/cce/umn/cce_10_0257.html
index 9d30d728..91786143 100644
--- a/docs/cce/umn/cce_10_0257.html
+++ b/docs/cce/umn/cce_10_0257.html
@@ -5,7 +5,7 @@
 
                             
                            EVS disks cannot be attached across AZs. Before mounting a volume, you can run the kubectl get pvc command to query the available PVCs in the AZ where the current cluster is located.
                            
 
                            
 
                            
-
                            Prerequisites
                            You have created a CCE cluster and installed the CSI plug-in (everest) in the cluster.
                            
+
                            Prerequisites
                            You have created a cluster and installed the CSI plug-in (everest) in the cluster.
                            
 
                            
 
                            Notes and Constraints
                            The following configuration example applies to clusters of Kubernetes 1.15 or later.
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0262.html b/docs/cce/umn/cce_10_0262.html
index 76210b9c..806b4c6a 100644
--- a/docs/cce/umn/cce_10_0262.html
+++ b/docs/cce/umn/cce_10_0262.html
@@ -3,7 +3,7 @@
 
                            Creating a StatefulSet Mounted with an SFS Volume
                            
 
                            Scenario
                            CCE allows you to use an existing SGS volume to create a StatefulSet (by using a PVC).
                            
 
                            
-
                            Prerequisites
                            You have created a CCE cluster and installed the CSI plug-in (everest) in the cluster.
                            
+
                            Prerequisites
                            You have created a cluster and installed the CSI plug-in (everest) in the cluster.
                            
 
                            
 
                            Notes and Constraints
                            The following configuration example applies to clusters of Kubernetes 1.15 or later.
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0263.html b/docs/cce/umn/cce_10_0263.html
index 5e18dd25..986d92be 100644
--- a/docs/cce/umn/cce_10_0263.html
+++ b/docs/cce/umn/cce_10_0263.html
@@ -3,7 +3,7 @@
 
                            Creating a Deployment Mounted with an SFS Volume
                            
 
                            Scenario
                            After an SFS volume is created or imported to CCE, you can mount the volume to a workload.
                            
 
                            
-
                            Prerequisites
                            You have created a CCE cluster and installed the CSI plug-in (everest) in the cluster.
                            
+
                            Prerequisites
                            You have created a cluster and installed the CSI plug-in (everest) in the cluster.
                            
 
                            
 
                            Notes and Constraints
                            The following configuration example applies to clusters of Kubernetes 1.15 or later.
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0268.html b/docs/cce/umn/cce_10_0268.html
index 1eea4642..eae9c0b8 100644
--- a/docs/cce/umn/cce_10_0268.html
+++ b/docs/cce/umn/cce_10_0268.html
@@ -3,7 +3,7 @@
 
                            Creating a StatefulSet Mounted with an OBS Volume
                            
 
                            Scenario
                            CCE allows you to use an existing OBS volume to create a StatefulSet through a PVC.
                            
 
                            
-
                            Prerequisites
                            You have created a CCE cluster and installed the CSI plug-in (everest) in the cluster.
                            
+
                            Prerequisites
                            You have created a cluster and installed the CSI plug-in (everest) in the cluster.
                            
 
                            
 
                            Notes and Constraints
                            The following configuration example applies to clusters of Kubernetes 1.15 or later.
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0269.html b/docs/cce/umn/cce_10_0269.html
index f4bf2f66..631658da 100644
--- a/docs/cce/umn/cce_10_0269.html
+++ b/docs/cce/umn/cce_10_0269.html
@@ -3,7 +3,7 @@
 
                            Creating a Deployment Mounted with an OBS Volume
                            
 
                            Scenario
                            After an OBS volume is created or imported to CCE, you can mount the volume to a workload.
                            
 
                            
-
                            Prerequisites
                            You have created a CCE cluster and installed the CSI plug-in (everest) in the cluster.
                            
+
                            Prerequisites
                            You have created a cluster and installed the CSI plug-in (everest) in the cluster.
                            
 
                            
 
                            Notes and Constraints
                            The following configuration example applies to clusters of Kubernetes 1.15 or later.
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0275.html b/docs/cce/umn/cce_10_0275.html
index 8e4ab6e0..6f4a1efb 100644
--- a/docs/cce/umn/cce_10_0275.html
+++ b/docs/cce/umn/cce_10_0275.html
@@ -1,7 +1,7 @@
 
 
 
                            Configuring a Pod Security Policy
                            
-
                            A pod security policy (PSP) is a cluster-level resource that controls sensitive security aspects of the pod specification. The PodSecurityPolicy object in Kubernetes defines a group of conditions that a pod must comply with to be accepted by the system, as well as the default values of related fields.
                            
+
                            A pod security policy (PSP) is a cluster-level resource that controls sensitive security aspects of the pod specification. The PodSecurityPolicy object in Kubernetes defines a group of conditions that a pod must comply with to be accepted by the system, as well as the default values of related fields.
                            
 
                            By default, the PSP access control component is enabled for clusters of v1.17.17 and a global default PSP named psp-global is created. You can modify the default policy (but not delete it). You can also create a PSP and bind it to the RBAC configuration.
                            
 
                             
                            • In addition to the global default PSP, the system configures independent PSPs for system components in namespace kube-system. Modifying the psp-global configuration does not affect pod creation in namespace kube-system.
                            • In Kubernetes 1.25, PSP has been removed and replaced by Pod Security Admission. For details, see Configuring Pod Security Admission.
                            
 
                            
diff --git a/docs/cce/umn/cce_10_0276.html b/docs/cce/umn/cce_10_0276.html
index 90f83f0e..06e55d2d 100644
--- a/docs/cce/umn/cce_10_0276.html
+++ b/docs/cce/umn/cce_10_0276.html
@@ -2,7 +2,7 @@
 
 
                            Performing Rolling Upgrade for Nodes
                            
 
                            Scenario
                            In a rolling upgrade, a new node is created, existing workloads are migrated to the new node, and then the old node is deleted. Figure 1 shows the migration process.
                            
-
                            Figure 1 Workload migration
                            
+
                            Figure 1 Workload migration
                            
 
                            
 
                            Notes and Constraints
                            • The original node and the target node to which the workload is to be migrated must be in the same cluster.
                            • The cluster must be of v1.13.10 or later.
                            • The default node pool DefaultPool does not support this configuration.
                            
 
                            
@@ -20,7 +20,7 @@
 
                            1. Delete the original node.
                              After the workload is successfully migrated and runs properly, delete the original node.
                              
 
                            
 
                            
-
                            Scenario 2: The Original Node Is Not in DefaultPool
                            1. Copy the node pool and add nodes to it. For details, see Copying a Node Pool.
                            2. Click View Node in the Operation column of the node pool. The IP address of the new node is displayed in the node list.
                            1. Migrate the workload.
                              1. Click Edit on the right of original node pool and set Taints.
                              2. Enter the key and value of the taint. The options of Effect are NoSchedule, PreferNoSchedule, and NoExecute. Select NoExecute and click confirm to add.
                                • NoSchedule: Pods that do not tolerate this taint are not scheduled on the node; existing pods are not evicted from the node.
                                • PreferNoSchedule: Kubernetes tries to avoid scheduling pods that do not tolerate this taint onto the node.
                                • NoExecute: A pod is evicted from the node if it is already running on the node, and is not scheduled onto the node if it is not yet running on the node.
                                
+
                                Scenario 2: The Original Node Is Not in DefaultPool
                                1. Copy the node pool and add nodes to it. For details, see Copying a Node Pool.
                                2. Click View Node in the Operation column of the node pool. The IP address of the new node is displayed in the node list.
                                1. Migrate the workload.
                                  1. Click Edit on the right of original node pool and set Taints.
                                  2. Enter the key and value of the taint. The options of Effect are NoSchedule, PreferNoSchedule, and NoExecute. Select NoExecute and click confirm to add.
                                    • NoSchedule: Pods that do not tolerate this taint are not scheduled on the node; existing pods are not evicted from the node.
                                    • PreferNoSchedule: Kubernetes tries to avoid scheduling pods that do not tolerate this taint onto the node.
                                    • NoExecute: A pod is evicted from the node if it is already running on the node, and is not scheduled onto the node if it is not yet running on the node.
                                    
 
                                     
                                    If you need to reset the taint, delete the configured taint.
                                    
 
                                    
 
                                  3. Click OK.
                                  4. In the navigation pane of the CCE console, choose Workloads > Deployments. In the workload list, the status of the workload to be migrated changes from Running to Unready. If the workload status changes to Running again, the migration is successful.
                                  
diff --git a/docs/cce/umn/cce_10_0277.html b/docs/cce/umn/cce_10_0277.html
index e2fea603..306e9b72 100644
--- a/docs/cce/umn/cce_10_0277.html
+++ b/docs/cce/umn/cce_10_0277.html
@@ -2,51 +2,53 @@
 
 
                                  Overview
                                  
 
                                  CCE provides multiple types of add-ons to extend cluster functions and meet feature requirements. You can install add-ons as required.
                                  
+
                                   
                                  CCE uses Helm templates to deploy add-ons. To modify or upgrade an add-on, perform operations on the Add-ons page or use open APIs. Do not directly modify resources related to add-ons in the background. Otherwise, add-on exceptions or other unexpected problems may occur.
                                  
+
                                  
 
-
                            Table 2 Scheduling policy configuration

                            Parameter

                            Description

                            diff --git a/docs/cce/umn/cce_10_0245.html b/docs/cce/umn/cce_10_0245.html index 6bffd14f..f89b3667 100644 --- a/docs/cce/umn/cce_10_0245.html +++ b/docs/cce/umn/cce_10_0245.html @@ -9,7 +9,7 @@

                            Permission Design

                            The following uses company X as an example.

                            Generally, a company has multiple departments or projects, and each department has multiple members. Therefore, you need to design how permissions are to be assigned to different groups and projects, and set a user name for each member to facilitate subsequent user group and permissions configuration.

                            The following figure shows the organizational structure of a department in a company and the permissions to be assigned to each member:

                            -

                            +

                            Director: David

                            David is a department director of company X. To assign him all CCE permissions (both cluster and namespace permissions), you need to create the cce-admin user group for David on the IAM console and assign the CCE Administrator role.

                            CCE Administrator: This role has all CCE permissions. You do not need to assign other permissions.

                            @@ -17,11 +17,11 @@

                            O&M Leader: James

                            James is the O&M team leader of the department. He needs the cluster permissions for all projects and the read-only permissions for all namespaces.

                            -

                            To assign the permissions, create a user group named cce-sre on the IAM console and add James to this user group. Then, assign CCE FullAccess to the user group cce-sre to allow it to perform operations on clusters in all projects.

                            +

                            To assign the permissions, create a user group named cce-sre on the IAM console and add James to this user group. Then, assign CCE FullAccess to the user group cce-sre to allow it to perform operations on clusters in all projects.

                            Assigning Read-only Permissions on All Clusters and Namespaces to All Team Leaders and Engineers

                            -

                            You can create a read-only user group named read_only on the IAM console and add users to the user group.

                            -
                            • Although the development engineers Linda and Peter do not require cluster management permissions, they still need to view data on the CCE console. Therefore, the read-only cluster permission is required.
                            • For the O&M engineer William, assign the read-only permission on clusters to him in this step.
                            • The O&M team leader James already has the management permissions on all clusters. You can add him to the read_only user group to assign the read-only permission on clusters to him.
                            -

                            Users James, Robert, William, Linda, and Peter are added to the read_only user group.

                            +

                            You can create a read-only user group named read_only on the IAM console and add users to the user group.

                            +
                            • Although the development engineers Linda and Peter do not require cluster management permissions, they still need to view data on the CCE console. Therefore, the read-only cluster permission is required.
                            • For the O&M engineer William, assign the read-only permission on clusters to him in this step.
                            • The O&M team leader James already has the management permissions on all clusters. You can add him to the read_only user group to assign the read-only permission on clusters to him.
                            +

                            Users James, Robert, William, Linda, and Peter are added to the read_only user group.

                            Assign the read-only permission on clusters to the user group read_only.

                            Return to the CCE console, and add the read-only permission on namespaces to the user group read_only to which the five users belong. Choose Permissions on the CCE console, and assign the read-only policy to the user group read_only for each cluster.

                            After the setting is complete, James has the cluster management permissions for all projects and the read-only permissions on all namespaces, and the Robert, William, Linda, and Peter have the read-only permission on all clusters and namespaces.

                            diff --git a/docs/cce/umn/cce_10_0247.html b/docs/cce/umn/cce_10_0247.html index f1bd7ceb..ecfb0343 100644 --- a/docs/cce/umn/cce_10_0247.html +++ b/docs/cce/umn/cce_10_0247.html @@ -20,6 +20,8 @@
                          17. Service Annotations
                            18. +
                          18. Configuring Health Check for Multiple Ports
                            +
                            19. diff --git a/docs/cce/umn/cce_10_0249.html b/docs/cce/umn/cce_10_0249.html index f4c02e32..91ee12bb 100644 --- a/docs/cce/umn/cce_10_0249.html +++ b/docs/cce/umn/cce_10_0249.html @@ -4,11 +4,11 @@

                            Direct Access to a Pod

                            After a pod is created, the following problems may occur if you directly access the pod:

                            • The pod can be deleted and recreated at any time by a controller such as a Deployment, and the result of accessing the pod becomes unpredictable.
                            • The IP address of the pod is allocated only after the pod is started. Before the pod is started, the IP address of the pod is unknown.
                            • An application is usually composed of multiple pods that run the same image. Accessing pods one by one is not efficient.

                            For example, an application uses Deployments to create the frontend and backend. The frontend calls the backend for computing, as shown in Figure 1. Three pods are running in the backend, which are independent and replaceable. When a backend pod is re-created, the new pod is assigned with a new IP address, of which the frontend pod is unaware.

                            -
                            Figure 1 Inter-pod access
                            +
                            Figure 1 Inter-pod access

                            Using Services for Pod Access

                            Kubernetes Services are used to solve the preceding pod access problems. A Service has a fixed IP address. (When a CCE cluster is created, a Service CIDR block is set, which is used to allocate IP addresses to Services.) A Service forwards requests accessing the Service to pods based on labels, and at the same time, perform load balancing for these pods.

                            In the preceding example, a Service is added for the frontend pod to access the backend pods. In this way, the frontend pod does not need to be aware of the changes on backend pods, as shown in Figure 2.

                            -
                            Figure 2 Accessing pods through a Service
                            +
                            Figure 2 Accessing pods through a Service

                            Service Types

                            Kubernetes allows you to specify a Service of a required type. The values and actions of different types of Services are as follows:

                            • ClusterIP

                              A ClusterIP Service allows workloads in the same cluster to use their cluster-internal domain names to access each other.

                              diff --git a/docs/cce/umn/cce_10_0251.html b/docs/cce/umn/cce_10_0251.html index 82ed2b1b..458b2cc4 100644 --- a/docs/cce/umn/cce_10_0251.html +++ b/docs/cce/umn/cce_10_0251.html @@ -8,7 +8,7 @@

                              Adding an ELB Ingress

                              This section uses an Nginx workload as an example to describe how to add an ELB ingress.

                              1. Log in to the CCE console and access the cluster console.
                              2. Choose Networking in the navigation pane, click the Ingresses tab, and click Create Service in the upper right corner.
                              3. Set ingress parameters.

                                • Name: Specify a name of an ingress, for example, ingress-demo.
                                • Load Balancer

                                  Select the load balancer to interconnect. Only load balancers in the same VPC as the cluster are supported. If no load balancer is available, click Create Load Balancer to create one on the ELB console.

                                  Dedicated load balancers must support HTTP and the network type must support private networks.

                                  -
                                • Listener Configuration: Ingress configures a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. After the configuration is complete, a listener is created on the load balancer. The default listener name is k8s__<Protocol type>_<Port number>, for example, k8s_HTTP_80.
                                  • Front-End Protocol: HTTP and HTTPS are available.
                                  • External Port: Port number that is open to the ELB service address. The port number can be specified randomly.
                                  • Server Certificate: When an HTTPS listener is created for a load balancer, you need to bind a certificate to the load balancer to support encrypted authentication for HTTPS data transmission.

                                    If there is already an HTTPS ingress for the chosen port on the load balancer, the certificate of the new HTTPS ingress must be the same as the certificate of the existing ingress. This means that a listener has only one certificate. If two certificates, each with a different ingress, are added to the same listener of the same load balancer, only the certificate added earliest takes effect on the load balancer.

                                    +
                                  • Listener: Ingress configures a listener for the load balancer, which listens to requests from the load balancer and distributes traffic. After the configuration is complete, a listener is created on the load balancer. The default listener name is k8s__<Protocol type>_<Port number>, for example, k8s_HTTP_80.
                                    • Front-End Protocol: HTTP and HTTPS are available.
                                    • External Port: Port number that is open to the ELB service address. The port number can be specified randomly.
                                    • Server Certificate: When an HTTPS listener is created for a load balancer, you need to bind a certificate to the load balancer to support encrypted authentication for HTTPS data transmission.

                                      If there is already an HTTPS ingress for the chosen port on the load balancer, the certificate of the new HTTPS ingress must be the same as the certificate of the existing ingress. This means that a listener has only one certificate. If two certificates, each with a different ingress, are added to the same listener of the same load balancer, only the certificate added earliest takes effect on the load balancer.

                                    • SNI: Server Name Indication (SNI) is an extended protocol of TLS. It allows multiple TLS-based access domain names to be provided for external systems using the same IP address and port. Different domain names can use different security certificates. After SNI is enabled, the client is allowed to submit the requested domain name when initiating a TLS handshake request. After receiving the TLS request, the load balancer searches for the certificate based on the domain name in the request. If the certificate corresponding to the domain name is found, the load balancer returns the certificate for authorization. Otherwise, the default certificate (server certificate) is returned for authorization.
                                      • The SNI option is available only when HTTPS is selected.
                                      • This function is supported only for clusters of v1.15.11 and later.
                                      • Specify the domain name for the SNI certificate. Only one domain name can be specified for each certificate. Wildcard-domain certificates are supported.
                                      @@ -16,20 +16,22 @@
                                    • Security Policy: combinations of different TLS versions and supported cipher suites available to HTTPS listeners.

                                      For details about security policies, see ELB User Guide.

                                      • Security Policy is available only when HTTPS is selected.
                                      • This function is supported only for clusters of v1.17.9 and later.
                                      +
                                    • Backend protocol

                                      If the listener uses HTTP, only HTTP can be selected.

                                      +

                                      If the listener uses HTTPS, you can select HTTP or HTTPS.

                                    -
                                  • Forwarding Policies: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the corresponding target Service for processing. Click Add Forwarding Policies to add multiple forwarding policies.
                                    • Domain Name: actual domain name. Ensure that the domain name has been registered and archived. Once a domain name rule is configured, you must use the domain name for access.
                                    • URL Matching Rule:
                                      • Prefix match: If the URL is set to /healthz, the URL that meets the prefix can be accessed. For example, /healthz/v1 and /healthz/v2.
                                      • Exact match: The URL can be accessed only when it is fully matched. For example, if the URL is set to /healthz, only /healthz can be accessed.
                                      • Regular expression: The URL is matched based on the regular expression. For example, if the regular expression is /[A-Za-z0-9_.-]+/test, all URLs that comply with this rule can be accessed, for example, /abcA9/test and /v1-Ab/test. Two regular expression standards are supported: POSIX and Perl.
                                      +
                                    • Forwarding Policies: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the corresponding target Service for processing. Click to add multiple forwarding policies.
                                      • Domain Name: actual domain name. Ensure that the domain name has been registered and archived. Once a domain name rule is configured, you must use the domain name for access.
                                      • URL Matching Rule:
                                        • Prefix match: If the URL is set to /healthz, the URL that meets the prefix can be accessed. For example, /healthz/v1 and /healthz/v2.
                                        • Exact match: The URL can be accessed only when it is fully matched. For example, if the URL is set to /healthz, only /healthz can be accessed.
                                        • Regular expression: The URL is matched based on the regular expression. For example, if the regular expression is /[A-Za-z0-9_.-]+/test, all URLs that comply with this rule can be accessed, for example, /abcA9/test and /v1-Ab/test. Two regular expression standards are supported: POSIX and Perl.
                                      • URL: access path to be registered, for example, /healthz.

                                        The URL added here must exist in the backend application. Otherwise, the forwarding fails.

                                        For example, the default access URL of the Nginx application is /usr/share/nginx/html. When adding /test to the ingress forwarding policy, ensure that your Nginx application contains the same URL, that is, /usr/share/nginx/html/test, otherwise, 404 is returned.

                                        -
                                      • Destination Service: Select an existing Service or create a Service. Services that do not meet search criteria are automatically filtered out.
                                      • Destination Service Port: Select the access port of the destination Service.
                                      • Set ELB:
                                        • Distribution Policy: Three algorithms are available: weighted round robin, weighted least connections algorithm, or source IP hash.
                                          • Weighted round robin: Requests are forwarded to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests. This algorithm is often used for short connections, such as HTTP services.
                                          • Weighted least connections: In addition to the weight assigned to each server, the number of connections processed by each backend server is also considered. Requests are forwarded to the server with the lowest connections-to-weight ratio. Building on least connections, the weighted least connections algorithm assigns a weight to each server based on their processing capability. This algorithm is often used for persistent connections, such as database connections.
                                          • Source IP hash: The source IP address of each request is calculated using the hash algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key allocates the client to a particular server. This enables requests from different clients to be distributed in load balancing mode and ensures that requests from the same client are forwarded to the same server. This algorithm applies to TCP connections without cookies.
                                          +
                                        • Destination Service: Select an existing Service or create a Service. Services that do not meet search criteria are automatically filtered out.
                                        • Destination Service Port: Select the access port of the destination Service.
                                        • Set ELB:
                                          • Distribution Policy: Three algorithms are available: weighted round robin, weighted least connections algorithm, or source IP hash.
                                            • Weighted round robin: Requests are forwarded to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests. This algorithm is often used for short connections, such as HTTP services.
                                            • Weighted least connections: In addition to the weight assigned to each server, the number of connections processed by each backend server is also considered. Requests are forwarded to the server with the lowest connections-to-weight ratio. Building on least connections, the weighted least connections algorithm assigns a weight to each server based on their processing performance. This algorithm is often used for persistent connections, such as database connections.
                                            • Source IP hash: The source IP address of each request is calculated using the hash algorithm to obtain a unique hash key, and all backend servers are numbered. The generated key allocates the client to a particular server. This allows requests from different clients to be routed based on source IP addresses and ensures that a client is directed to the same server as always. This algorithm applies to TCP connections without cookies.
                                            -
                                          • Type: This function is disabled by default. You can select Load balancer cookie.
                                          • Health Check: This function is disabled by default. The health check is for the load balancer. When TCP is selected during the port settings, you can choose either TCP or HTTP. Currently, UDP is not supported. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named cce-healthz will be added for the Service.
                                          +
                                        • Type: This function is disabled by default. You can select Load balancer cookie.
                                        • Health Check: configured for the load balancer. When TCP is selected during the port settings, you can choose either TCP or HTTP. Currently, UDP is not supported. By default, the service port (Node Port and container port of the Service) is used for health check. You can also specify another port for health check. After the port is specified, a service port named cce-healthz will be added for the Service.
                                      • Operation: Click Delete to delete the configuration.
                                    • Annotation: Ingresses provide some advanced CCE functions, which are implemented by annotations. When you use kubectl to create a container, annotations will be used. For details, see Creating an Ingress - Automatically Creating a Load Balancer and Creating an Ingress - Interconnecting with an Existing Load Balancer.

                                  • After the configuration is complete, click OK. After the ingress is created, it is displayed in the ingress list.

                                    On the ELB console, you can view the ELB automatically created through CCE. The default name is cce-lb-ingress.UID. Click the ELB name to access its details page. On the Listeners tab page, view the route settings of the ingress, including the URL, listener port, and backend server group port.

                                    After the ingress is created, upgrade and maintain the selected load balancer on the CCE console. Do not maintain the load balancer on the ELB console. Otherwise, the ingress service may be abnormal.

                                    -

                                  • Access the /healthz interface of the workload, for example, workload defaultbackend.

                                    1. Obtain the access address of the /healthz interface of the workload. The access address consists of the load balancer IP address, external port, and mapping URL, for example, 10.**.**.**:80/healthz.
                                    2. Enter the URL of the /healthz interface, for example, http://10.**.**.**:80/healthz, in the address box of the browser to access the workload, as shown in Figure 1.
                                      Figure 1 Accessing the /healthz interface of defaultbackend
                                      +

                                    3. Access the /healthz interface of the workload, for example, workload defaultbackend.

                                      1. Obtain the access address of the /healthz interface of the workload. The access address consists of the load balancer IP address, external port, and mapping URL, for example, 10.**.**.**:80/healthz.
                                      2. Enter the URL of the /healthz interface, for example, http://10.**.**.**:80/healthz, in the address box of the browser to access the workload, as shown in Figure 1.
                                        Figure 1 Accessing the /healthz interface of defaultbackend

                              diff --git a/docs/cce/umn/cce_10_0252.html b/docs/cce/umn/cce_10_0252.html index db0da4fc..c1f6c3be 100644 --- a/docs/cce/umn/cce_10_0252.html +++ b/docs/cce/umn/cce_10_0252.html @@ -10,7 +10,7 @@

                              Compared with v1beta1, v1 has the following differences in parameters:

                              • The ingress type is changed from kubernetes.io/ingress.class in annotations to spec.ingressClassName.
                              • The format of backend is changed.
                              • The pathType parameter must be specified for each path. The options are as follows:
                                • ImplementationSpecific: The matching method depends on Ingress Controller. The matching method defined by ingress.beta.kubernetes.io/url-match-mode is used in CCE, which is the same as v1beta1.
                                • Exact: exact matching of the URL, which is case-sensitive.
                                • Prefix: matching based on the URL prefix separated by a slash (/). The match is case-sensitive, and elements in the path are matched one by one. A path element refers to a list of labels in the path separated by a slash (/).
                              -

                              +

                            Creating an Ingress - Automatically Creating a Load Balancer

                            The following describes how to run the kubectl command to automatically create a load balancer when creating an ingress.

                            1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                            2. Create a YAML file named ingress-test.yaml. The file name can be customized.

                              vi ingress-test.yaml

                              @@ -189,7 +189,7 @@ spec:

                            String

                            cce: The self-developed ELB ingress is used.

                            +

                            cce: The self-developed ELB ingress is used.

                            This parameter is mandatory when an ingress is created by calling the API.

                            String

                            Path type. This field is supported only by clusters of v1.23 or later.

                            -
                            • ImplementationSpecific: The matching method depends on Ingress Controller. The matching method defined by ingress.beta.kubernetes.io/url-match-mode is used in CCE.
                            • Exact: exact matching of the URL, which is case-sensitive.
                            • Prefix: matching based on the URL prefix separated by a slash (/). The match is case-sensitive, and elements in the path are matched one by one. A path element refers to a list of labels in the path separated by a slash (/).
                            +
                            • ImplementationSpecific: The matching method depends on Ingress Controller. The matching method defined by ingress.beta.kubernetes.io/url-match-mode is used in CCE.
                            • Exact: exact matching of the URL, which is case-sensitive.
                            • Prefix: matching based on the URL prefix separated by a slash (/). The match is case-sensitive, and elements in the path are matched one by one. A path element refers to a list of labels in the path separated by a slash (/).
                            Table 1 Add-on list

                            Add-on Name

                            +
                            - - - - - - - - - - - - - - - - - diff --git a/docs/cce/umn/cce_10_0281.html b/docs/cce/umn/cce_10_0281.html index 473f5557..84a4039d 100644 --- a/docs/cce/umn/cce_10_0281.html +++ b/docs/cce/umn/cce_10_0281.html @@ -2,7 +2,7 @@

                            Overview

                            The container network assigns IP addresses to pods in a cluster and provides networking services. In CCE, you can select the following network models for your cluster:

                            - +

                            Network Model Comparison

                            Table 1 describes the differences of network models supported by CCE.

                            After a cluster is created, the network model cannot be changed.

                            @@ -10,7 +10,7 @@
                            Table 1 Add-on list

                            Add-on Name

                            Introduction

                            +

                            Introduction

                            coredns (System Resource Add-On, Mandatory)

                            +

                            coredns (System Resource Add-On, Mandatory)

                            The coredns add-on is a DNS server that provides domain name resolution services for Kubernetes clusters. coredns chains plug-ins to provide additional features.

                            +

                            The coredns add-on is a DNS server that provides domain name resolution services for Kubernetes clusters. coredns chains plug-ins to provide additional features.

                            storage-driver (System Resource Add-On, Discarded)

                            +

                            storage-driver (System Resource Add-On, Discarded)

                            storage-driver is a FlexVolume driver used to support IaaS storage services such as EVS, SFS, and OBS.

                            +

                            storage-driver is a FlexVolume driver used to support IaaS storage services such as EVS, SFS, and OBS.

                            everest (System Resource Add-On, Mandatory)

                            +

                            everest (System Resource Add-On, Mandatory)

                            Everest is a cloud native container storage system. Based on the Container Storage Interface (CSI), clusters of Kubernetes v1.15.6 or later obtain access to cloud storage services.

                            +

                            Everest is a cloud native container storage system. Based on the Container Storage Interface (CSI), clusters of Kubernetes v1.15.6 or later obtain access to cloud storage services.

                            npd

                            +

                            npd

                            node-problem-detector (npd for short) is an add-on that monitors abnormal events of cluster nodes and connects to a third-party monitoring platform. It is a daemon running on each node. It collects node issues from different daemons and reports them to the API server. The npd add-on can run as a DaemonSet or a daemon.

                            +

                            node-problem-detector (npd for short) is an add-on that monitors abnormal events of cluster nodes and connects to a third-party monitoring platform. It is a daemon running on each node. It collects node issues from different daemons and reports them to the API server. The npd add-on can run as a DaemonSet or a daemon.

                            autoscaler

                            +

                            autoscaler

                            The autoscaler add-on resizes a cluster based on pod scheduling status and resource usage.

                            +

                            The autoscaler add-on resizes a cluster based on pod scheduling status and resource usage.

                            metrics-server

                            +

                            metrics-server

                            metrics-server is an aggregator for monitoring data of core cluster resources.

                            +

                            metrics-server is an aggregator for monitoring data of core cluster resources.

                            gpu-beta

                            +

                            gpu-beta

                            gpu-beta is a device management add-on that supports GPUs in containers. It supports only NVIDIA drivers.

                            +

                            gpu-beta is a device management add-on that supports GPUs in containers. It supports only NVIDIA drivers.

                            volcano

                            +

                            volcano

                            Volcano provides general-purpose, high-performance computing capabilities, such as job scheduling, heterogeneous chip management, and job running management, serving end users through computing frameworks for different industries, such as AI, big data, gene sequencing, and rendering.

                            +

                            Volcano provides general-purpose, high-performance computing capabilities, such as job scheduling, heterogeneous chip management, and job running management, serving end users through computing frameworks for different industries, such as AI, big data, gene sequencing, and rendering.
                            - diff --git a/docs/cce/umn/cce_10_0282.html b/docs/cce/umn/cce_10_0282.html index 3ff4cca1..9ad9ebf9 100644 --- a/docs/cce/umn/cce_10_0282.html +++ b/docs/cce/umn/cce_10_0282.html @@ -1,7 +1,7 @@

                            Container Tunnel Network

                            -

                            Container Tunnel Network Model

                            The container tunnel network is constructed on but independent of the node network through tunnel encapsulation. This network model uses VXLAN to encapsulate Ethernet packets into UDP packets and transmits them in tunnels. Open vSwitch serves as the backend virtual switch. Though at some costs of performance, packet encapsulation and tunnel transmission enable higher interoperability and compatibility with advanced features (such as network policy-based isolation) for most common scenarios.
                            Figure 1 Container tunnel network
                            +

                            Container Tunnel Network Model

                            The container tunnel network is constructed on but independent of the node network through tunnel encapsulation. This network model uses VXLAN to encapsulate Ethernet packets into UDP packets and transmits them in tunnels. Open vSwitch serves as the backend virtual switch. Though at some costs of performance, packet encapsulation and tunnel transmission enable higher interoperability and compatibility with advanced features (such as network policy-based isolation) for most common scenarios.
                            Figure 1 Container tunnel network

                            Pod-to-pod communication

                            • On the same node: Packets are directly forwarded via the OVS bridge on the node.
                            • Across nodes: Packets are encapsulated in the OVS bridge and then forwarded to the peer node.
                            @@ -15,7 +15,7 @@

                            Container IP Address Management

                            The container tunnel network allocates container IP addresses according to the following rules:

                            • The container CIDR block is allocated separately, which is irrelevant to the node CIDR block.
                            • IP addresses are allocated by node. One or more CIDR blocks with a fixed size (16 by default) are allocated to each node in a cluster from the container CIDR block.
                            • When the IP addresses on a node are used up, you can apply for a new CIDR block.
                            • The container CIDR block cyclically allocates CIDR blocks to new nodes or existing nodes in sequence.
                            • Pods scheduled to a node are cyclically allocated IP addresses from one or more CIDR blocks allocated to the node.
                            -
                            Figure 2 IP address allocation of the container tunnel network
                            +
                            Figure 2 IP address allocation of the container tunnel network

                            Maximum number of nodes that can be created in the cluster using the container tunnel network = Number of IP addresses in the container CIDR block / Size of the IP CIDR block allocated to the node by the container CIDR block at a time (16 by default)

                            For example, if the container CIDR block is 172.16.0.0/16, the number of IP addresses is 65536. If 16 IP addresses are allocated to a node at a time, a maximum of 4096 (65536/16) nodes can be created in the cluster. This is an extreme case. If 4096 nodes are created, a maximum of 16 pods can be created for each node because only 16 IP CIDR block\s are allocated to each node. In addition, the number of nodes that can be created in a cluster also depends on the node network and cluster scale.

                            diff --git a/docs/cce/umn/cce_10_0283.html b/docs/cce/umn/cce_10_0283.html index 3794d3e5..6b3b6783 100644 --- a/docs/cce/umn/cce_10_0283.html +++ b/docs/cce/umn/cce_10_0283.html @@ -1,7 +1,7 @@

                            VPC Network

                            -

                            Model Definition

                            The VPC network uses VPC routing to integrate with the underlying network. This network model is suitable for performance-intensive scenarios. The maximum number of nodes allowed in a cluster depends on the VPC route quota. Each node is assigned a CIDR block of a fixed size. This networking model is free from tunnel encapsulation overhead and outperforms the container tunnel network model. In addition, as VPC routing includes routes to node IP addresses and the container CIDR block, container pods in a cluster can be directly accessed from outside the cluster.
                            Figure 1 VPC network model
                            +

                            Model Definition

                            The VPC network uses VPC routing to integrate with the underlying network. This network model is suitable for performance-intensive scenarios. The maximum number of nodes allowed in a cluster depends on the VPC route quota. Each node is assigned a CIDR block of a fixed size. This networking model is free from tunnel encapsulation overhead and outperforms the container tunnel network model. In addition, as VPC routing includes routes to node IP addresses and the container CIDR block, container pods in a cluster can be directly accessed from outside the cluster.
                            Figure 1 VPC network model

                            Pod-to-pod communication

                            • On the same node: Packets are directly forwarded through IPVlan.
                            • Across nodes: Packets are forwarded to the default gateway through default routes, and then to the peer node via the VPC routes.
                            @@ -15,7 +15,7 @@

                            Container IP Address Management

                            The VPC network allocates container IP addresses according to the following rules:

                            • The container CIDR block is allocated separately.
                            • IP addresses are allocated by node. One CIDR block with a fixed size (which is configurable) is allocated to each node in a cluster from the container CIDR block.
                            • The container CIDR block cyclically allocates CIDR blocks to new nodes in sequence.
                            • Pods scheduled to a node are cyclically allocated IP addresses from CIDR blocks allocated to the node.
                            -
                            Figure 2 IP address management of the VPC network
                            +
                            Figure 2 IP address management of the VPC network

                            Maximum number of nodes that can be created in the cluster using the VPC network = Number of IP addresses in the container CIDR block /Number of IP addresses in the CIDR block allocated to the node by the container CIDR block

                            For example, if the container CIDR block is 172.16.0.0/16, the number of IP addresses is 65536. The mask of the container CIDR block allocated to the node is 25. That is, the number of container IP addresses on each node is 128. Therefore, a maximum of 512 (65536/128) nodes can be created. In addition, the number of nodes that can be created in a cluster also depends on the node network and cluster scale.

                            diff --git a/docs/cce/umn/cce_10_0284.html b/docs/cce/umn/cce_10_0284.html index cf1b4c20..b36abe20 100644 --- a/docs/cce/umn/cce_10_0284.html +++ b/docs/cce/umn/cce_10_0284.html @@ -2,7 +2,7 @@

                            Cloud Native Network 2.0

                            Model Definition

                            Developed by CCE, Cloud Native Network 2.0 deeply integrates Elastic Network Interfaces (ENIs) and sub-ENIs of Virtual Private Cloud (VPC). Container IP addresses are allocated from the VPC CIDR block. ELB passthrough networking is supported to direct access requests to containers. Security groups and elastic IPs (EIPs) are bound to deliver high performance.

                            -
                            Figure 1 Cloud Native Network 2.0
                            +
                            Figure 1 Cloud Native Network 2.0

                            Pod-to-pod communication

                            • Pods on BMS nodes use ENIs, whereas pods on ECS nodes use Sub-ENIs. Sub-ENIs are attached to ENIs through VLAN sub-interfaces.
                            • On the same node: Packets are forwarded through the VPC ENI or sub-ENI.
                            • Across nodes: Packets are forwarded through the VPC ENI or sub-ENI.
                            @@ -18,7 +18,7 @@

                            In the Cloud Native Network 2.0 model, the container CIDR block and node CIDR block share the network addresses in a VPC. It is recommended that the container subnet and node subnet not use the same subnet. Otherwise, containers or nodes may fail to be created due to insufficient IP resources.

                            In addition, a subnet can be added to the container CIDR block after a cluster is created to increase the number of available IP addresses. In this case, ensure that the added subnet does not conflict with other subnets in the container CIDR block.

                            -
                            Figure 2 Configuring CIDR blocks
                            +
                            Figure 2 Configuring CIDR blocks

                            Example of Cloud Native Network 2.0 Access

                            Create a CCE Turbo cluster, which contains three ECS nodes.

                            Access the details page of one node. You can see that the node has one primary NIC and one extended NIC, and both of them are ENIs. The extended NIC belongs to the container CIDR block and is used to mount a sub-ENI to the pod.

                            diff --git a/docs/cce/umn/cce_10_0285.html b/docs/cce/umn/cce_10_0285.html index b9561a15..6176fe06 100644 --- a/docs/cce/umn/cce_10_0285.html +++ b/docs/cce/umn/cce_10_0285.html @@ -7,10 +7,10 @@
                            • Group them in different clusters for different environments.

                              Resources cannot be shared among different clusters. In addition, services in different environments can access each other only through load balancing.

                            • Group them in different namespaces for different environments.

                              Workloads in the same namespace can be mutually accessed by using the Service name. Cross-namespace access can be implemented by using the Service name or namespace name.

                              The following figure shows namespaces created for the development, joint debugging, and testing environments, respectively.

                              -
                              Figure 1 One namespace for one environment
                              +
                              Figure 1 One namespace for one environment
                          19. Isolating namespaces by application

                            You are advised to use this method if a large number of workloads are deployed in the same environment. For example, in the following figure, different namespaces (APP1 and APP2) are created to logically manage workloads as different groups. Workloads in the same namespace access each other using the Service name, and workloads in different namespaces access each other using the Service name or namespace name.

                            -
                            Figure 2 Grouping workloads into different namespaces
                            +
                            Figure 2 Grouping workloads into different namespaces

                            20. Deleting a Namespace

                            If a namespace is deleted, all resources (such as workloads, jobs, and ConfigMaps) in this namespace will also be deleted. Exercise caution when deleting a namespace.

                            diff --git a/docs/cce/umn/cce_10_0287.html b/docs/cce/umn/cce_10_0287.html index 089f9393..32a9f7c3 100644 --- a/docs/cce/umn/cce_10_0287.html +++ b/docs/cce/umn/cce_10_0287.html @@ -36,7 +36,7 @@
                            Table 1 Network model comparison

                            Dimension

                            Tunnel Network

                            +

                            Container Tunnel Network

                            VPC Network
                            -

                            Starting from clusters of v1.21 and later, the default Resource Quotas are created when a namespace is created if you have enabled enable-resource-quota in Managing Cluster Components. Table 1 lists the resource quotas based on cluster specifications. You can modify them according to your service requirements.

                            +

                            Starting from clusters of v1.21 and later, the default Resource Quotas are created when a namespace is created if you have enabled enable-resource-quota in Cluster Configuration Management. Table 1 lists the resource quotas based on cluster specifications. You can modify them according to your service requirements.

                            diff --git a/docs/cce/umn/cce_10_0288.html b/docs/cce/umn/cce_10_0288.html index 302830b6..5a6ed8d4 100644 --- a/docs/cce/umn/cce_10_0288.html +++ b/docs/cce/umn/cce_10_0288.html @@ -26,7 +26,7 @@
                            Table 1 Default resource quotas

                            Cluster Scale

                            The selected security group will be bound to the ENI or supplementary ENI of the selected workload. A maximum of five security groups can be selected from the drop-down list. You must select one or multiple security groups to create a SecurityGroup.

                            If no security group has not been created, click Create Security Group. After the security group is created, click the refresh button.

                            -
                            NOTICE:
                            • A maximum of 5 security groups can be selected.
                            • Hover the cursor on next to the security group name, and you can view details about the security group.
                            +
                            NOTICE:
                            • A maximum of 5 security groups can be selected.
                            • Hover the cursor on next to the security group name, and you can view details about the security group.

                            64566556-bd6f-48fb-b2c6-df8f44617953

                            diff --git a/docs/cce/umn/cce_10_0296.html b/docs/cce/umn/cce_10_0296.html index 26efeae2..161f6944 100644 --- a/docs/cce/umn/cce_10_0296.html +++ b/docs/cce/umn/cce_10_0296.html @@ -6,13 +6,13 @@

                            Prerequisites

                            Before using the node scaling function, you must install the autoscaler add-on of v1.13.8 or later.

                            How autoscaler Works

                            The cluster autoscaler (CA) goes through two processes.

                            -
                            • Scale-out: The CA checks all unschedulable pods every 10 seconds and selects a node group that meets the requirements for scale-out based on the policy you set.
                            • Scale-in: The CA scans all nodes every 10 seconds. If the number of pod requests on a node is less than the user-defined percentage for scale-in, the CA simulates whether the pods on the node can be migrated to other nodes. If yes, the node will be removed after an idle time window.
                            +
                            • Scale-out: The CA checks all unschedulable pods every 10 seconds and selects a node pool that meets the requirements for scale-out based on the policy you set.
                            • Scale-in: The CA scans all nodes every 10 seconds. If the number of pod requests on a node is less than the user-defined percentage for scale-in, the CA simulates whether the pods on the node can be migrated to other nodes. If yes, the node will be removed after an idle time window.

                            As described above, if a cluster node is idle for a period of time (10 minutes by default), scale-in is triggered, and the idle node is removed.

                            However, a node cannot be removed from a cluster if the following pods exist:

                            -
                            1. Pods that do not meet specific requirements set in PodDisruptionBudget
                            2. Pods that cannot be scheduled to other nodes due to constraints such as affinity and anti-affinity policies
                            3. Pods that have the "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" annotation
                            4. Pods (except those created by kube-system DaemonSet) that exist in the kube-system namespace on the node
                            5. Pods that are not created by the controller (Deployment/ReplicaSet/job/StatefulSet)
                            +
                            1. Pods that do not meet specific requirements set in PodDisruptionBudget
                            2. Pods that cannot be scheduled to other nodes due to constraints such as affinity and anti-affinity policies
                            3. Pods that have the "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" annotation
                            4. Pods (except those created by DaemonSets in the kube-system namespace) that exist in the kube-system namespace on the node
                            5. Pods that are not created by the controller (Deployment/ReplicaSet/job/StatefulSet)

                            autoscaler Architecture

                            Figure 1 shows the autoscaler architecture and its core modules:

                            -
                            Figure 1 autoscaler architecture
                            +
                            Figure 1 autoscaler architecture

                            Description

                            • Estimator: Evaluates the number of nodes to be added to each node pool to host unschedulable pods.
                            • Simulator: Finds the nodes that meet the scale-in conditions in the scale-in scenario.
                            • Expander: Selects an optimal node from the node pool picked out by the Estimator based on the user-defined policy in the scale-out scenario. Currently, the Expander has the following policies:
                              • Random: Selects a node pool randomly. If you have not specified a policy, Random is set by default.
                              • most-Pods: Selects the node pool that can host the largest number of unschedulable pods after the scale-out. If multiple node pools meet the requirement, a random node pool will be selected.
                              • least-waste: Selects the node pool that has the least CPU or memory resource waste after scale-out.
                              • price: Selects the node pool in which the to-be-added nodes cost least for scale-out.
                              • priority: Selects the node pool with the highest weight. The weights are user-defined.
                            diff --git a/docs/cce/umn/cce_10_0298.html b/docs/cce/umn/cce_10_0298.html index 350af8eb..116f4731 100644 --- a/docs/cce/umn/cce_10_0298.html +++ b/docs/cce/umn/cce_10_0298.html @@ -3,7 +3,7 @@

                            Creating a CCE Turbo Cluster

                            CCE Turbo clusters run on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, and intelligent scheduling.

                            CCE Turbo clusters are paired with the Cloud Native Network 2.0 model for large-scale, high-performance container deployment. Containers are assigned IP addresses from the VPC CIDR block. Containers and nodes can belong to different subnets. Access requests from external networks in a VPC can be directly routed to container IP addresses, which greatly improves networking performance. It is recommended that you go through Cloud Native Network 2.0 to understand the features and network planning of each CIDR block of Cloud Native Network 2.0.

                            -

                            Notes and Constraints

                            • During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name.
                            • You can create a maximum of 50 clusters in a single region.
                            • CCE Turbo clusters support only Cloud Native Network 2.0. For details about this network model, see Cloud Native Network 2.0.
                            • After a cluster is created, the following items cannot be changed:
                              • Cluster type
                              • Number of master nodes in the cluster
                              • AZ of a master node
                              • Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, and kube-proxy (forwarding) settings.
                              • Network model. For example, change Tunnel network to VPC network.
                              +

                              Notes and Constraints

                              • During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the DNS server address of the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name.
                              • You can create a maximum of 50 clusters in a single region.
                              • CCE Turbo clusters support only Cloud Native Network 2.0. For details about this network model, see Cloud Native Network 2.0.
                              • After a cluster is created, the following items cannot be changed:
                                • Cluster type
                                • Number of master nodes in the cluster
                                • AZ of a master node
                                • Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, and kube-proxy (forwarding) settings.
                                • Network model. For example, change Tunnel network to VPC network.

                              Procedure

                              1. Log in to the CCE console. Choose Clusters. On the displayed page, click Create next to CCE Turbo cluster.
                              2. Specify cluster parameters.

                                Basic Settings
                                • Cluster Name
                                • Cluster Version: Select the Kubernetes version used by the cluster.
                                • Cluster Scale: Select the maximum number of nodes that can be managed by the cluster. After the creation is complete, only scale-out is supported, but not scale-in.
                                • HA: distribution mode of master nodes. By default, master nodes are randomly distributed in different AZs to improve DR capabilities.
                                  You can also expand advanced settings and customize the master node distribution mode. The following modes are supported:
                                  • Host: Master nodes are created on different hosts in the same AZ.
                                  • Custom: You can determine the location of each master node.
                                  @@ -16,20 +16,22 @@

                                  Advanced Settings

                                  • Request Forwarding: The IPVS and iptables modes are supported. For details, see Comparing iptables and IPVS.
                                  • CPU Manager: For details, see Binding CPU Cores.
                                  • Resource Tag:

                                    You can add resource tags to classify resources.

                                    You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use predefined tags to improve tag creation and resource migration efficiency.

                                    -
                                  • Certificate Authentication:
                                    • Default: The X509-based authentication mode is enabled by default. X509 is a commonly used certificate format.
                                    • Custom: The cluster can identify users based on the header in the request body for authentication.

                                      You need to upload your CA root certificate, client certificate, and private key of the client certificate.

                                      -
                                      • Upload a file smaller than 1 MB. The CA certificate and client certificate can be in .crt or .cer format. The private key of the client certificate can only be uploaded unencrypted.
                                      • The validity period of the client certificate must be longer than five years.
                                      • The uploaded CA certificate is used for both the authentication proxy and the kube-apiserver aggregation layer configuration. If the certificate is invalid, the cluster cannot be created.
                                      • Starting from v1.25, Kubernetes no longer supports certificate authentication generated using the SHA1WithRSA or ECDSAWithSHA1 algorithm. You are advised to use the SHA256 algorithm.
                                      +
                                    • Certificate Authentication:
                                      • Default: The X509-based authentication mode is enabled by default. X509 is a commonly used certificate format.
                                      • Custom: The cluster can identify users based on the header in the request body for authentication.

                                        You need to upload your CA root certificate, client certificate, and private key of the client certificate.

                                        +
                                        • Upload a file smaller than 1 MB. The CA certificate and client certificate can be in .crt or .cer format. The private key of the client certificate can only be uploaded unencrypted.
                                        • The validity period of the client certificate must be longer than five years.
                                        • The uploaded CA certificate is used for both the authentication proxy and the kube-apiserver aggregation layer configuration. If the certificate is invalid, the cluster cannot be created.
                                        • Starting from v1.25, Kubernetes no longer supports certificate authentication generated using the SHA1WithRSA or ECDSAWithSHA1 algorithm. You are advised to use the SHA256 algorithm.
                                    • Description: The value can contain a maximum of 200 English characters.
                                    -

                                  • Click Next: Add-on Configuration.

                                    By default, cordens and everest add-ons are installed.

                                    +

                                  • Click Next: Add-on Configuration.

                                    Domain Name Resolution: Uses the coredns add-on, installed by default, to resolve domain names and connect to the cloud DNS server.

                                    +

                                    Container Storage: The everest add-on is installed by default to provide container storage based on CSI and connect to cloud storage services such as EVS.

                                    Service log
                                    • ICAgent:

                                      A log collector provided by Application Operations Management (AOM), reporting logs to AOM and Log Tank Service (LTS) according to the log collection rules you configured.

                                      You can collect stdout logs as required.

                                    +

                                    Overload Control: If overload control is enabled, concurrent requests are dynamically controlled based on the resource pressure of master nodes to keep them and the cluster available.

                                  • After configuring the parameters, click Next: Confirm.

                                    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.

                              -

                              Related Operations

                              +

                              Related Operations

                              diff --git a/docs/cce/umn/cce_10_0300.html b/docs/cce/umn/cce_10_0300.html index d21f0ee9..bc335bfc 100644 --- a/docs/cce/umn/cce_10_0300.html +++ b/docs/cce/umn/cce_10_0300.html @@ -6,7 +6,7 @@

                              Solution

                              Two major auto scaling policies are HPA (Horizontal Pod Autoscaling) and CA (Cluster AutoScaling). HPA is for workload auto scaling and CA is for node auto scaling.

                              HPA and CA work with each other. HPA requires sufficient cluster resources for successful scaling. When the cluster resources are insufficient, CA is needed to add nodes. If HPA reduces workloads, the cluster will have a large number of idle resources. In this case, CA needs to release nodes to avoid resource waste.

                              -
                              As shown in Figure 1, HPA performs scale-out based on the monitoring metrics. When cluster resources are insufficient, newly created pods are in Pending state. CA then checks these pending pods and selects the most appropriate node pool based on the configured scaling policy to scale out the node pool.
                              Figure 1 HPA and CA working flows
                              +
                              As shown in Figure 1, HPA performs scale-out based on the monitoring metrics. When cluster resources are insufficient, newly created pods are in Pending state. CA then checks these pending pods and selects the most appropriate node pool based on the configured scaling policy to scale out the node pool.
                              Figure 1 HPA and CA working flows

                              Using HPA and CA can easily implement auto scaling in most scenarios. In addition, the scaling process of nodes and pods can be easily observed.

                              This section uses an example to describe the auto scaling process using HPA and CA policies together.

                              @@ -29,7 +29,7 @@ RUN chmod a+rx index.php
                            • Run the following command to build an image named hpa-example with the tag latest.
                              docker build -t hpa-example:latest .
                            • (Optional) Log in to the SWR console, choose Organization Management in the navigation pane, and click Create Organization in the upper right corner to create an organization.

                              Skip this step if you already have an organization.

                              -
                            • In the navigation pane, choose My Images and then click Upload Through Client. On the page displayed, click Generate a temporary login command and click to copy the command.
                            • Run the login command copied in the previous step on the cluster node. If the login is successful, the message "Login Succeeded" is displayed.
                            • Tag the hpa-example image.

                              docker tag [Image name 1:Tag 1] [Image repository address]/[Organization name]/[Image name 2:Tag 2]

                              +
                            • In the navigation pane, choose My Images and then click Upload Through Client. On the page displayed, click Generate a temporary login command and click to copy the command.
                            • Run the login command copied in the previous step on the cluster node. If the login is successful, the message "Login Succeeded" is displayed.
                            • Tag the hpa-example image.

                              docker tag [Image name 1:Tag 1] [Image repository address]/[Organization name]/[Image name 2:Tag 2]

                              • [Image name 1:Tag 1]: name and tag of the local image to be uploaded.
                              • [Image repository address]: The domain name at the end of the login command in 5 is the image repository address, which can be obtained on the SWR console.
                              • [Organization name]: name of the organization created in 4.
                              • [Image name 2:Tag 2]: desired image name and tag to be displayed on the SWR console.

                              Example:

                              docker tag hpa-example:latest swr.eu-de.otc.t-systems.com/group/hpa-example:latest

                              @@ -49,11 +49,11 @@ latest: digest: sha256:eb7e3bbd*** size: **

                              Retain the defaults for other parameters. For details, see Creating a Node Pool.

                            • Click Add-ons on the left of the cluster console, click Edit under the autoscaler add-on, modify the add-on configuration, enable Auto node scale-in, and configure scale-in parameters. For example, trigger scale-in when the node resource utilization is less than 50%.

                              -

                              +

                              After the preceding configurations, scale-out is performed based on the pending status of the pod and scale-in is triggered when the node resource utilization decreases.

                            • Click Node Scaling on the left of the cluster console and click Create Node Scaling Policy in the upper right corner. Node scaling policies added here trigger scale-out based on the CPU/memory allocation rate or periodically.

                              As shown in the following figure, when the cluster CPU allocation rate is greater than 70%, one node will be added. A node scaling policy needs to be associated with a node pool. Multiple node pools can be associated. When you need to scale nodes, node with proper specifications will be added or reduced from the node pool based on the minimum waste principle. For details, see Creating a Node Scaling Policy.

                              -

                              +

                            Creating a Workload

                            Use the hpa-example image to create a Deployment with one replica. The image path is related to the organization uploaded to the SWR repository and needs to be replaced with the actual value.

                            @@ -122,7 +122,7 @@ spec: targetAverageUtilization: 50

                            Set the parameters as follows if you are using the console.

                            -

                            +

                            Observing the Auto Scaling Process

                            1. Check the cluster node status. In the following example, there are two nodes.

                              # kubectl get node
 NAME            STATUS   ROLES    AGE     VERSION
diff --git a/docs/cce/umn/cce_10_0301.html b/docs/cce/umn/cce_10_0301.html
index 4b761d90..2e9c98bd 100644
--- a/docs/cce/umn/cce_10_0301.html
+++ b/docs/cce/umn/cce_10_0301.html
@@ -1,141 +1,35 @@
 
 
 
                              Performing In-place Upgrade
                              
-
                              
-    
                              
-        
                              Scenario
                              
-        
                              You can upgrade your clusters to a newer version on the CCE console.
                              
-        
                              Before the upgrade, learn about the target version to which each CCE
-            cluster can be upgraded in what ways, and the upgrade impacts. For details, see Upgrade Overview and Before You Start.
                              
-    
                              
-    
                              
-        
                              Description
                              
-        
                                
-            
                              • An in-place upgrade updates the Kubernetes components on cluster nodes,
-                without changing their OS version. 
                                • 
-            
                              • Data plane nodes are upgraded in batches. By default, they are
-                prioritized based on their CPU, memory, and PodDisruptionBudgets (PDBs). You can also set the priorities according
-                to your service requirements.
                                • 
-        
                              
-    
                              
-    
                              
-        
                              Precautions
                              
-        
                                
-            
                              • During the cluster upgrade, the system will automatically upgrade
-                add-ons to a version compatible with the target cluster version. Do not uninstall or reinstall add-ons
-                during the cluster upgrade.
                                • 
-            
                              • Before the upgrade, ensure that all add-ons are running. If an add-on
-                fails to be upgraded, rectify the fault and try again.
                                • 
-            
                              • During the upgrade, CCE checks the add-on running status. Some add-ons
-                (such as coredns) require at least two nodes to run normally. In this case, at least two nodes must be
-                available for the upgrade.
                                • 
-        
                              
-        
                              For more information, see Before You Start.
-        
                              
-    
                              
-    
                              
-        
                              Procedure
                              
-        
                              This section describes how to upgrade a CCE cluster of v1.15 or later. For
-            other versions, see Performing Replace/Rolling Upgrade.
                              
-        
                                
-            
                              1. Log in to the CCE console and click the cluster name to access
-                    the cluster.
                                2. 
-            
                              2. In the navigation pane, choose Cluster Upgrade. You can view the new version
-                    available for upgrade on the right.
-                
                                
-                
                                Check the version information, last update/upgrade time, available
-                    upgrade version, and upgrade history of the current cluster.
                                
-                
                                The cluster upgrade goes through pre-upgrade check, add-on
-                    upgrade/uninstallation, master node upgrade, worker node upgrade, and post-upgrade processing.
                                
-                
                                 
-                    
                                
-                        
                                  
-                            
                                • If your cluster version is up-to-date, the Upgrade button is grayed out.
                                  • 
-                            
                                • If your cluster status is abnormal or there are
-                                abnormal add-ons, the Upgrade button is
-                                dimmed. Perform a check by referring to Before You Start.
-                            
                                  • 
-                        
                                
-                    
                                
-                
                                
-                
                                
-            
                                3. 
-            
                              3. Click Upgrade or Install Patch on
-                    the right. Set the upgrade parameters.
-                
                                
-                
                                  
-                    
                                • New
-                            Version: Select the Kubernetes version to which the cluster can be upgraded.
                                  • 
-                    
                                • (Optional) Cluster
-                            Backup: Determine whether to back up the entire master node. This backup mode is
-                        recommended.
                                  A manual confirmation is required for backing up
-                            the entire master node. The backup process uses the Cloud Backup and Recovery (CBR) service
-                            and takes about 20 minutes. If there are many cloud backup tasks at the current site, the
-                            backup time may be prolonged. You are advised to back up the master node.
                                  
-                    
                                  • 
-                    
                                • Add-on Upgrade
-                            Configuration: Add-ons that have been installed in your cluster are listed. During
-                        the cluster upgrade, the system automatically upgrades the add-ons to be compatible with the
-                        target cluster version. You can click Set to
-                        re-define the add-on parameters.
                                   
-                            
                                  
-                                
                                  If a red dot  is displayed on the right of
-                                    an add-on, the add-on is incompatible with the target cluster version. During the
-                                    upgrade, the add-on will be uninstalled and then re-installed. Ensure that the
-                                    add-on parameters are correctly configured.
                                  
-                            
                                  
-                        
                                  
-                    
                                  • 
-                    
                                • Node Upgrade
-                            Configuration: Before setting the node upgrade priority, you need to select a node
-                        pool. Nodes and node pools will be upgraded according to the priorities you specify. You can set
-                        the maximum number of nodes to be upgraded in a batch, or set priorities for nodes to be
-                        upgraded. If you do not set this parameter, the system will determine the nodes to upgrade in
-                        batches based on specific conditions.
                                    
-                            
                                  • Add Upgrade
-                                    Priority: Add upgrade priorities for node pools.
                                    • 
-                            
                                  • Add Node
-                                    Priority: After adding a node pool priority, you can set the upgrade
-                                sequence of nodes in the node pool. The system upgrades nodes in the sequence you
-                                specify. If you skip this setting, the system upgrades nodes based on the default
-                                policy.
                                    • 
-                        
                                  
-                    
                                  • 
-                
                                
-                
                                
-            
                                4. 
-            
                              4. Read the upgrade instructions carefully, and select I have read and agree to Upgrade Precautions. Click
-                    Upgrade.
                                5. 
-            
                              5. After you click Upgrade, the cluster upgrade starts. You can view the
-                    upgrade process in the lower part of the page.
-                
                                
-                
                                During the upgrade, you can click Suspend on the right to suspend the cluster upgrade.
-                    To continue the upgrade, click Continue.
                                
-                
                                If an upgrade failure message is displayed during the cluster upgrade,
-                    rectify the fault as prompted and try again.
                                
-                
                                
-            
                                6. 
-            
                              6. When the upgrade progress reaches 100%, the cluster is upgraded.
-                    The version information will be properly displayed, and no upgrade is required.
                                7. 
-            
                              7. After the upgrade is complete, verify the cluster Kubernetes
-                    version on the Clusters page.
                                8. 
-        
                              
-    
                              
+
                              Scenario
                              You can upgrade your clusters to a newer version on the CCE console.
                              
+
                              Before the upgrade, learn about the target version to which each CCE cluster can be upgraded in what ways, and the upgrade impacts. For details, see Upgrade Overview and Before You Start.
                              
+
                              
+
                              Description
                              • An in-place upgrade updates the Kubernetes components on cluster nodes, without changing their OS version. 
                              • Data plane nodes are upgraded in batches. By default, they are prioritized based on their CPU, memory, and PodDisruptionBudgets (PDBs). You can also set the priorities according to your service requirements.
                              
+
                              
+
                              Precautions
                              • During the cluster upgrade, the system will automatically upgrade add-ons to a version compatible with the target cluster version. Do not uninstall or reinstall add-ons during the cluster upgrade.
                              • Before the upgrade, ensure that all add-ons are running. If an add-on fails to be upgraded, rectify the fault and try again.
                              • During the upgrade, CCE checks the add-on running status. Some add-ons (such as coredns) require at least two nodes to run normally. In this case, at least two nodes must be available for the upgrade.
                              
+
                              For more information, see Before You Start.
                              
+
                              
+
                              Procedure
                              The cluster upgrade goes through check, backup, configuration and upgrade, and verification.
                              
+
                              1. Log in to the CCE console and access the cluster console.
                              2. In the navigation pane, choose Cluster Upgrade. You can view the recommended version on the right.
                              3. Select the cluster version to be upgraded and click Check.
                                 
                                • If your cluster has a new minor version, you do not need to select the cluster version. The latest minor version is used by default.
                                • If your cluster has a new major version, you can select a version as required.
                                • If your cluster is of the latest version, the check entry will be hidden.
                                
+
                                
+
                                
+
                              4. Click Start Check and confirm the check. If there are abnormal or risky items in the cluster, handle the exceptions based on the check results displayed on the page and check again.
                                • Exceptions: View the solution displayed on the page, handle the exceptions and check again.
                                • Risk Items: may affect the cluster upgrade. Check the risk description and see whether you may be impacted. If no risk exists, click OK next to the risk item to manually skip this risk item and check again.
                                
+
                                After the check is passed, click Next: Back Up.
                                
+
                                
+
                              5. (Optional) Manually back up the data. Data is backed up during the upgrade following a default policy. You can click Back Up to manually back up data. If you do not need to manually back up data, click Next: Configure & Upgrade.
                              6. Configure the upgrade parameters.
                                • Add-on Upgrade Configuration: Add-ons that have been installed in your cluster are listed. During the cluster upgrade, the system automatically upgrades the add-ons to be compatible with the target cluster version. You can click Set to re-define the add-on parameters.
                                   
                                  If a red dot  is displayed on the right of an add-on, the add-on is incompatible with the target cluster version. During the upgrade, the add-on will be uninstalled and then re-installed. Ensure that the add-on parameters are correctly configured.
                                  
+
                                  
+
                                • Node Upgrade Configuration: You can set the maximum number of nodes to be upgraded in a batch.
                                • Node Priority: You can set priorities for nodes to be upgraded. If you do not set this parameter, the system will determine the nodes to upgrade in batches based on specific conditions. Before setting the node upgrade priority, you need to select a node pool. Nodes and node pools will be upgraded according to the priorities you specify.
                                  • Add Upgrade Priority: Add upgrade priorities for node pools.
                                  • Add Node Priority: After adding a node pool priority, you can set the upgrade sequence of nodes in the node pool. The system upgrades nodes in the sequence you specify. If you skip this setting, the system upgrades nodes based on the default policy.
                                  
+
                                
+
                              7. After the configuration is complete, click Upgrade and confirm the upgrade. The cluster starts to be upgraded. You can view the process in the lower part of the page.
                                During the upgrade, you can click Suspend on the right to suspend the cluster upgrade. To continue the upgrade, click Continue. When the progress bar reaches 100%, the cluster upgrade is complete.
                                
+
                                 
                                If an upgrade failure message is displayed during the cluster upgrade, rectify the fault as prompted and try again.
                                
+
                                
+
                              8. After the upgrade is complete, click Next: Verify. Verify the upgrade based on the displayed check items. After confirming that all check items are normal, click Complete and confirm that the post-upgrade check is complete.
                                You can verify the cluster Kubernetes version on the Clusters page.
                                
+
                              
+
                              
 
                              
 
                              
-    
                              
-        
                              Parent topic: Upgrading a Cluster
                              
-    
                              
-
                              
\ No newline at end of file
+
                              
+
                              Parent topic: Upgrading a Cluster
                              
+
                              
+
                              
+
diff --git a/docs/cce/umn/cce_10_0302.html b/docs/cce/umn/cce_10_0302.html
index acbcbe16..61529b00 100644
--- a/docs/cce/umn/cce_10_0302.html
+++ b/docs/cce/umn/cce_10_0302.html
@@ -4,97 +4,97 @@
 
                              Before the upgrade, you can check whether your cluster can be upgraded and which versions are available on the CCE console. For details, see Upgrade Overview.
                              
 
                              Precautions
                              • Upgraded clusters cannot be rolled back. Therefore, perform the upgrade during off-peak hours to minimize the impact on your services.
                              • Do not shut down, restart, or delete nodes during cluster upgrade. Otherwise, the upgrade fails.
                              • Before upgrading a cluster, disable auto scaling policies to prevent node scaling during the upgrade. Otherwise, the upgrade fails.
                              • If you locally modify the configuration of a cluster node, the cluster upgrade may fail or the configuration may be lost after the upgrade. Therefore, modify the configurations on the CCE console (cluster or node pool list page) so that they will be automatically inherited during the upgrade.
                              • During the cluster upgrade, the running workload services will not be interrupted, but access to the API server will be temporarily interrupted.
                              • Before upgrading the cluster, check whether the cluster is healthy. 
                              • To ensure data security, you are advised to back up data before upgrading the cluster. During the upgrade, you are not advised to perform any operations on the cluster.
                              • During the cluster upgrade, the node.kubernetes.io/upgrade taint (the effect is NoSchedule) is added to the node. After the cluster upgrade is complete, the taint is removed. Do not add taints with the same key name on the node. Even if the taints have different effects, they may be deleted by the system by mistake after the upgrade.
                              
 
                              
-
                              Notes and Constraints
                              • Currently, only CCE clusters consisting of VM nodes can be upgraded.
                              • After the cluster is upgraded, if the containerd vulnerability of the container engine is fixed in Cluster Version Release Notes, you need to manually restart containerd for the upgrade to take effect. The same applies to the existing pods.
                              • If initContainer or Istio is used in the in-place upgrade of a cluster of v1.15, pay attention to the following restrictions:
                                In kubelet 1.16 and later versions, QoS classes are different from those in earlier versions. In kubelet 1.15 and earlier versions, only containers in spec.containers are counted. In kubelet 1.16 and later versions, containers in both spec.containers and spec.initContainers are counted. The QoS class of a pod will change after the upgrade. As a result, the container in the pod restarts. You are advised to modify the QoS class of the service container before the upgrade to avoid this problem. For details, see Table 1.
                                
+
                                Notes and Constraints
                                • Currently, only CCE clusters consisting of VM nodes and CCE Turbo clusters can be upgraded. 
                                • Currently, clusters using private images cannot be upgraded.
                                • After the cluster is upgraded, if the containerd vulnerability of the container engine is fixed in Cluster Version Release Notes, you need to manually restart containerd for the upgrade to take effect. The same applies to the existing pods.
                                • If initContainer or Istio is used in the in-place upgrade of a cluster of v1.15, pay attention to the following restrictions:
                                  In kubelet 1.16 and later versions, QoS classes are different from those in earlier versions. In kubelet 1.15 and earlier versions, only containers in spec.containers are counted. In kubelet 1.16 and later versions, containers in both spec.containers and spec.initContainers are counted. The QoS class of a pod will change after the upgrade. As a result, the container in the pod restarts. You are advised to modify the QoS class of the service container before the upgrade to avoid this problem. For details, see Table 1.
                                  
 
-
                                  Table 1 QoS class changes before and after the upgrade
                                  Init Container (Calculated Based on spec.initContainers)
                                  
+
                                  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/cce/umn/cce_10_0305.html b/docs/cce/umn/cce_10_0305.html
index d236fb11..1181c559 100644
--- a/docs/cce/umn/cce_10_0305.html
+++ b/docs/cce/umn/cce_10_0305.html
@@ -1,6 +1,6 @@
 
 
-
                                  Storage (FlexVolume)
                                  
+
                                  Storage Management: FlexVolume (Deprecated)
                                  
 
                                  
diff --git a/docs/cce/umn/cce_10_0306.html b/docs/cce/umn/cce_10_0306.html
index c3741037..419beaf9 100644
--- a/docs/cce/umn/cce_10_0306.html
+++ b/docs/cce/umn/cce_10_0306.html
@@ -11,48 +11,48 @@
 
                                  Checking Storage Add-ons
                                  1. Log in to the CCE console.
                                  2. In the navigation tree on the left, click Add-ons.
                                  3. Click the Add-on Instance tab.
                                  4. Select a cluster in the upper right corner. The default storage add-on installed during cluster creation is displayed.
                                  
 
                                  
 
                                  Differences Between CSI and FlexVolume Plug-ins
                                  
-
                                  Table 1 QoS class changes before and after the upgrade
                                  Init Container (Calculated Based on spec.initContainers)
                                  
 
                                  Service Container (Calculated Based on spec.containers)
                                  
+
                                  Service Container (Calculated Based on spec.containers)
                                  
 
                                  Pod (Calculated Based on spec.containers and spec.initContainers)
                                  
+
                                  Pod (Calculated Based on spec.containers and spec.initContainers)
                                  
 
                                  Impacted or Not
                                  
+
                                  Impacted or Not
                                  
                                   		
 
                                  
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Yes
                                  
+
                                  Yes
                                  
                                   		
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  No
                                  
+
                                  No
                                  
                                   		
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  No
                                  
+
                                  No
                                  
                                   		
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  No
                                  
+
                                  No
                                  
                                   		
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  No
                                  
+
                                  No
                                  
                                   		
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Yes
                                  
+
                                  Yes
                                  
                                   		
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Besteffort
                                  
+
                                  Besteffort
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Yes
                                  
+
                                  Yes
                                  
                                   		
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  No
                                  
+
                                  No
                                  
                                   		
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Guaranteed
                                  
+
                                  Guaranteed
                                  
 
                                  Burstable
                                  
+
                                  Burstable
                                  
 
                                  Yes
                                  
+
                                  Yes
                                  
                                   		
 
                                  
                                   
 
 
                                  Table 1 CSI and FlexVolume
                                  Kubernetes Solution
                                  
+
                                  
-
-
-
-
-
-
-
-
-
-
-
                                  Table 1 CSI and FlexVolume
                                  Kubernetes Solution
                                  
 
                                  CCE Add-on
                                  
+
                                  CCE Add-on
                                  
 
                                  Feature
                                  
+
                                  Feature
                                  
 
                                  Recommendation
                                  
+
                                  Recommendation
                                  
                                   		
 
                                  
 
                                  CSI
                                  
+
                                  CSI
                                  
 
                                  Everest
                                  
+
                                  Everest
                                  
 
                                  CSI was developed as a standard for exposing arbitrary block and file storage storage systems to containerized workloads. Using CSI, third-party storage providers can deploy plugins exposing new storage systems in Kubernetes without having to touch the core Kubernetes code. In CCE, the everest add-on is installed by default in clusters of Kubernetes v1.15 and later to connect to storage services (EVS, OBS, SFS, and SFS Turbo).
                                  
-
                                  The everest add-on consists of two parts:
                                  
-
                                  • everest-csi-controller for storage volume creation, deletion, capacity expansion, and cloud disk snapshots
                                  • everest-csi-driver for mounting, unmounting, and formatting storage volumes on nodes
                                  
-
                                  For details, see everest.
                                  
+
                                  CSI was developed as a standard for exposing arbitrary block and file storage storage systems to containerized workloads. Using CSI, third-party storage providers can deploy plugins exposing new storage systems in Kubernetes without having to touch the core Kubernetes code. In CCE, the everest add-on is installed by default in clusters of Kubernetes v1.15 and later to connect to storage services (EVS, OBS, SFS, and SFS Turbo).
                                  
+
                                  The everest add-on consists of two parts:
                                  
+
                                  • everest-csi-controller for storage volume creation, deletion, capacity expansion, and cloud disk snapshots
                                  • everest-csi-driver for mounting, unmounting, and formatting storage volumes on nodes
                                  
+
                                  For details, see everest.
                                  
 
                                  The everest add-on is installed by default in clusters of v1.15 and later. CCE will mirror the Kubernetes community by providing continuous support for updated CSI capabilities.
                                  
+
                                  The everest add-on is installed by default in clusters of v1.15 and later. CCE will mirror the Kubernetes community by providing continuous support for updated CSI capabilities.
                                  
                                   		
 
                                  Flexvolume
                                  
+
                                  Flexvolume
                                  
 
                                  storage-driver
                                  
+
                                  storage-driver
                                  
 
                                  FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes since version 1.2 (before CSI). CCE provided FlexVolume volumes through the storage-driver add-on installed in clusters of Kubernetes v1.13 and earlier versions. This add-on connects clusters to storage services (EVS, OBS, SFS, and SFS Turbo).
                                  
-
                                  For details, see storage-driver.
                                  
+
                                  FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes since version 1.2 (before CSI). CCE provided FlexVolume volumes through the storage-driver add-on installed in clusters of Kubernetes v1.13 and earlier versions. This add-on connects clusters to storage services (EVS, OBS, SFS, and SFS Turbo).
                                  
+
                                  For details, see storage-driver.
                                  
 
                                  For the created clusters of v1.13 or earlier, the installed FlexVolume plug-in (CCE add-on storage-driver) can still be used. CCE stops providing update support for this add-on, and you are advised to upgrade these clusters.
                                  
+
                                  For the created clusters of v1.13 or earlier, the installed FlexVolume plug-in (CCE add-on storage-driver) can still be used. CCE stops providing update support for this add-on, and you are advised to upgrade these clusters.
                                  
                                   		
 
                                  
                                   
 
                                  
 
                                  
-
                                   
                                  • A cluster can use only one type of storage plug-ins.
                                  • The FlexVolume plug-in cannot be replaced by the CSI plug-in in clusters of v1.13 or earlier. You can only upgrade these clusters. For details, see Cluster Upgrade.
                                  
+
                                   
                                  • A cluster can use only one type of storage plug-ins.
                                  • The FlexVolume plug-in cannot be replaced by the CSI plug-in in clusters of v1.13 or earlier. You can only upgrade these clusters. For details, see Cluster Upgrade.
                                  
 
                                  
 
                                  
 
                                  
 
 
diff --git a/docs/cce/umn/cce_10_0307.html b/docs/cce/umn/cce_10_0307.html
index 4acf97a4..259dfcf5 100644
--- a/docs/cce/umn/cce_10_0307.html
+++ b/docs/cce/umn/cce_10_0307.html
@@ -3,7 +3,7 @@
 
                                  Overview
                                  
 
                                  Volume
                                  On-disk files in a container are ephemeral, which will be lost when the container crashes and are difficult to be shared between containers running together in a pod. The Kubernetes volume abstraction solves both of these problems. Volumes cannot be independently created, but defined in the pod spec. All containers in a pod can access its volumes, but the volumes must have been mounted to any directory in a container.
                                  
 
                                  The following figure shows how a storage volume is used between containers in a pod.
                                  
-
                                  
+
                                  
 
                                  A volume will no longer exist if the pod to which it is mounted does not exist. However, files in the volume may outlive the volume, depending on the volume type.
                                  
 
                                  
 
                                  Volume Types
                                  Volumes can be classified into local volumes and cloud volumes.
                                  
@@ -19,7 +19,7 @@
 
                                  PV and PVC
                                  Kubernetes provides PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) to abstract details of how storage is provided from how it is consumed. You can request specific size of storage when needed, just like pods can request specific levels of resources (CPU and memory).
                                  
 
                                  • PV: A PV is a persistent storage volume in a cluster. Same as a node, a PV is a cluster-level resource. 
                                  • PVC: A PVC describes a workload's request for storage resources. This request consumes existing PVs in the cluster. If there is no PV available, underlying storage and PVs are dynamically created. When creating a PVC, you need to describe the attributes of the requested persistent storage, such as the size of the volume and the read/write permissions.
                                  
 
                                  You can bind PVCs to PVs in a pod so that the pod can use storage resources. The following figure shows the relationship between PVs and PVCs.
                                  
-
                                  Figure 1 PVC-to-PV binding
                                  
+
                                  Figure 1 PVC-to-PV binding
                                  
 
                                  PVs describes storage resources in the cluster. PVCs are requests for those resources. The following sections will describe how to use kubectl to connect to storage resources.
                                  
 
                                  If you do not want to create storage resources or PVs manually, you can use StorageClasses.
                                  
 
                                  
@@ -34,7 +34,7 @@ csi-obs             everest-csi-provisioner         17d          # Storage class
 
                                  After a StorageClass is set, PVs can be automatically created and maintained. You only need to specify the StorageClass when creating a PVC, which greatly reduces the workload.
                                  
 
                                  
 
                                  Cloud Services for Container Storage
                                  CCE allows you to mount local and cloud storage volumes listed in Volume Types to your pods. Their features are described below.
                                  
-
                                  Figure 2 Volume types supported by CCE
                                  
+
                                  Figure 2 Volume types supported by CCE
                                  
 
 
                                  
diff --git a/docs/cce/umn/cce_10_0309.html b/docs/cce/umn/cce_10_0309.html
index 162fc2e9..0a3dfac7 100644
--- a/docs/cce/umn/cce_10_0309.html
+++ b/docs/cce/umn/cce_10_0309.html
@@ -15,7 +15,7 @@
 
                                  
-
                                  Parent topic: Storage (FlexVolume)
                                  
+
                                  Parent topic: Storage Management: FlexVolume (Deprecated)
                                  
 
                                  
 
diff --git a/docs/cce/umn/cce_10_0310.html b/docs/cce/umn/cce_10_0310.html
index 4c4ebe24..5d193bf0 100644
--- a/docs/cce/umn/cce_10_0310.html
+++ b/docs/cce/umn/cce_10_0310.html
@@ -2,7 +2,7 @@
 
 
                                  Overview
                                  To achieve persistent storage, CCE allows you to mount the storage volumes created from Elastic Volume Service (EVS) disks to a path of a container. When the container is migrated, the mounted EVS volumes are also migrated. By using EVS volumes, you can mount the remote file directory of storage system into a container so that data in the data volume is permanently preserved even when the container is deleted.
                                  
-
                                  Figure 1 Mounting EVS volumes to CCE
                                  
+
                                  Figure 1 Mounting EVS volumes to CCE
                                  
 
                                  Description
                                  • User-friendly: Similar to formatting disks for on-site servers in traditional layouts, you can format block storage (disks) mounted to cloud servers, and create file systems on them.
                                  • Data isolation: Each server uses an independent block storage device (disk).
                                  • Private network: User can access data only in private networks of data centers.
                                  • Capacity and performance: The capacity of a single volume is limited (TB-level), but the performance is excellent (ms-level read/write I/O latency).
                                  • Restriction: EVS disks that have partitions or have non-ext4 file systems cannot be imported.
                                  • Applications: HPC, enterprise core applications running in clusters, enterprise application systems, and development and testing. These volumes are often used by single-pod Deployments and jobs, or exclusively by each pod in a StatefulSet. EVS disks are non-shared storage and cannot be attached to multiple nodes at the same time. If two pods are configured to use the same EVS disk and the two pods are scheduled to different nodes, one pod cannot be started because the EVS disk cannot be attached to it.
                                  
 
                                  
 
                                  
diff --git a/docs/cce/umn/cce_10_0313.html b/docs/cce/umn/cce_10_0313.html
index 4aca363c..d6217c8b 100644
--- a/docs/cce/umn/cce_10_0313.html
+++ b/docs/cce/umn/cce_10_0313.html
@@ -1,7 +1,7 @@
 
                                  (kubectl) Creating a PV from an Existing EVS Disk
                                  
-
                                  Notes and Constraints
                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                  
+
                                  Notes and Constraints
                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                  
 
                                  
 
                                  Procedure
                                  1. Log in to the EVS console, create an EVS disk, and record the volume ID, capacity, and disk type of the EVS disk.
                                  2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                  3. Create two YAML files for creating the PersistentVolume (PV) and PersistentVolumeClaim (PVC). Assume that the file names are pv-evs-example.yaml and pvc-evs-example.yaml.
                                    touch pv-evs-example.yaml pvc-evs-example.yaml
                                    
 
@@ -240,7 +240,7 @@ spec:
 
                                  
-
-
                                  Table 1 Detailed description of cloud storage services
                                  Dimension
                                  
                                   		
 
 
 
 
 
 
                                  
 
                                  storageClassName
                                  
 
                                  EVS disk type. Supported values: Common I/O (SATA), High I/O (SAS), and Ultra-high I/O (SSD)
                                  
+
                                  EVS disk type. Supported values: Common I/O (SATA), High I/O (SAS), and Ultra-high I/O (SSD)
                                  
                                   		
 
                                  
 
                                  driver
                                  
@@ -372,7 +372,7 @@ spec:
 
                                  
 
                                  storageClassName
                                  
 
                                  EVS disk type. Supported values: Common I/O (SATA), High I/O (SAS), and Ultra-high I/O (SSD)
                                  
+
                                  EVS disk type. Supported values: Common I/O (SATA), High I/O (SAS), and Ultra-high I/O (SSD)
                                  
                                   		
 
                                  
 
                                  driver
                                  
diff --git a/docs/cce/umn/cce_10_0314.html b/docs/cce/umn/cce_10_0314.html
index eb8d01df..a1bec27a 100644
--- a/docs/cce/umn/cce_10_0314.html
+++ b/docs/cce/umn/cce_10_0314.html
@@ -1,11 +1,11 @@
 
 
 
                                  (kubectl) Creating a Pod Mounted with an EVS Volume
                                  
-
                                  Scenario
                                  After an EVS volume is created or imported to CCE, you can mount it to a workload.
                                  
-
                                   
                                  EVS disks cannot be attached across AZs. Before mounting a volume, you can run the kubectl get pvc command to query the available PVCs in the AZ where the current cluster is located.
                                  
+
                                  Scenario
                                  After an EVS volume is created or imported to CCE, you can mount it to a workload.
                                  
+
                                   
                                  EVS disks cannot be attached across AZs. Before mounting a volume, you can run the kubectl get pvc command to query the available PVCs in the AZ where the current cluster is located.
                                  
 
                                  
 
                                  
-
                                  Notes and Constraints
                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                  
+
                                  Notes and Constraints
                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                  
 
                                  
 
                                  Procedure
                                  1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                  2. Run the following commands to configure the evs-deployment-example.yaml file, which is used to create a Deployment.
                                    touch evs-deployment-example.yaml
                                    
 
                                    vi evs-deployment-example.yaml
                                    
diff --git a/docs/cce/umn/cce_10_0315.html b/docs/cce/umn/cce_10_0315.html
index 135337a9..61481623 100644
--- a/docs/cce/umn/cce_10_0315.html
+++ b/docs/cce/umn/cce_10_0315.html
@@ -17,7 +17,7 @@
 
 
 
                                    
-
                                    Parent topic: Storage (FlexVolume)
                                    
+
                                    Parent topic: Storage Management: FlexVolume (Deprecated)
                                    
 
                                    
 
                                  
 
diff --git a/docs/cce/umn/cce_10_0316.html b/docs/cce/umn/cce_10_0316.html
index 7004742a..c4259a8b 100644
--- a/docs/cce/umn/cce_10_0316.html
+++ b/docs/cce/umn/cce_10_0316.html
@@ -2,7 +2,7 @@
 
 
                                  Overview
                                  
 
                                  CCE allows you to mount a volume created from a Scalable File Service (SFS) file system to a container to store data persistently. SFS volumes are commonly used in ReadWriteMany scenarios, such as media processing, content management, big data analysis, and workload process analysis.
                                  
-
                                  Figure 1 Mounting SFS volumes to CCE
                                  
+
                                  Figure 1 Mounting SFS volumes to CCE
                                  
 
                                  Description
                                  • Standard file protocols: You can mount file systems as volumes to servers, the same as using local directories.
                                  • Data sharing: The same file system can be mounted to multiple servers, so that data can be shared.
                                  • Private network: User can access data only in private networks of data centers.
                                  • Capacity and performance: The capacity of a single file system is high (PB level) and the performance is excellent (ms-level read/write I/O latency).
                                  • Use cases: Deployments/StatefulSets in the ReadWriteMany mode and jobs created for high-performance computing (HPC), media processing, content management, web services, big data analysis, and workload process analysis
                                  
 
                                  
 
                                  
diff --git a/docs/cce/umn/cce_10_0318.html b/docs/cce/umn/cce_10_0318.html
index f2957fa0..1a9ba0f3 100644
--- a/docs/cce/umn/cce_10_0318.html
+++ b/docs/cce/umn/cce_10_0318.html
@@ -1,7 +1,7 @@
 
 
 
                                  (kubectl) Automatically Creating an SFS Volume
                                  
-
                                  Notes and Constraints
                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                  
+
                                  Notes and Constraints
                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                  
 
                                  
 
                                  Procedure
                                  1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                  2. Run the following commands to configure the pvc-sfs-auto-example.yaml file, which is used to create a PVC.
                                    touch pvc-sfs-auto-example.yaml
                                    
 
                                    vi pvc-sfs-auto-example.yaml
                                    
diff --git a/docs/cce/umn/cce_10_0319.html b/docs/cce/umn/cce_10_0319.html
index 8069d6cd..b5c75a50 100644
--- a/docs/cce/umn/cce_10_0319.html
+++ b/docs/cce/umn/cce_10_0319.html
@@ -1,7 +1,7 @@
 
 
 
                                    (kubectl) Creating a PV from an Existing SFS File System
                                    
-
                                    Notes and Constraints
                                    The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                    
+
                                    Notes and Constraints
                                    The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                    
 
                                    
 
                                    Procedure
                                    1. Log in to the SFS console, create a file system, and record the file system ID, shared path, and capacity.
                                    2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                    3. Create two YAML files for creating the PV and PVC. Assume that the file names are pv-sfs-example.yaml and pvc-sfs-example.yaml.
                                      touch pv-sfs-example.yaml pvc-sfs-example.yaml
                                      
 
diff --git a/docs/cce/umn/cce_10_0320.html b/docs/cce/umn/cce_10_0320.html
index e8605db3..68063f6e 100644
--- a/docs/cce/umn/cce_10_0320.html
+++ b/docs/cce/umn/cce_10_0320.html
@@ -3,7 +3,7 @@
 
                                      (kubectl) Creating a Deployment Mounted with an SFS Volume
                                      
 
                                      Scenario
                                      After an SFS volume is created or imported to CCE, you can mount the volume to a workload.
                                      
 
                                      
-
                                      Notes and Constraints
                                      The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                      
+
                                      Notes and Constraints
                                      The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                      
 
                                      
 
                                      Procedure
                                      1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                      2. Run the following commands to configure the sfs-deployment-example.yaml file, which is used to create a pod.
                                        touch sfs-deployment-example.yaml
                                        
 
                                        vi sfs-deployment-example.yaml
                                        
diff --git a/docs/cce/umn/cce_10_0321.html b/docs/cce/umn/cce_10_0321.html
index cc566cc8..4ff7dd8c 100644
--- a/docs/cce/umn/cce_10_0321.html
+++ b/docs/cce/umn/cce_10_0321.html
@@ -3,7 +3,7 @@
 
                                        (kubectl) Creating a StatefulSet Mounted with an SFS Volume
                                        
 
                                        Scenario
                                        CCE allows you to use an existing SFS volume to create a StatefulSet through a PersistentVolumeClaim (PVC).
                                        
 
                                        
-
                                        Notes and Constraints
                                        The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                        
+
                                        Notes and Constraints
                                        The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                        
 
                                        
 
                                        Procedure
                                        1. Create an SFS volume by referring to (kubectl) Automatically Creating an SFS Volume and record the volume name.
                                        2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                        3. Create a YAML file for creating the workload. Assume that the file name is sfs-statefulset-example.yaml.
                                          touch sfs-statefulset-example.yaml
                                          
 
                                          vi sfs-statefulset-example.yaml
                                          
diff --git a/docs/cce/umn/cce_10_0322.html b/docs/cce/umn/cce_10_0322.html
index 9b022042..2baca946 100644
--- a/docs/cce/umn/cce_10_0322.html
+++ b/docs/cce/umn/cce_10_0322.html
@@ -17,7 +17,7 @@
 
 
 
                                          
-
                                          Parent topic: Storage (FlexVolume)
                                          
+
                                          Parent topic: Storage Management: FlexVolume (Deprecated)
                                          
 
                                          
 
                                        
 
diff --git a/docs/cce/umn/cce_10_0323.html b/docs/cce/umn/cce_10_0323.html
index ad8c21d3..d5f71ee4 100644
--- a/docs/cce/umn/cce_10_0323.html
+++ b/docs/cce/umn/cce_10_0323.html
@@ -2,7 +2,7 @@
 
 
                                        Overview
                                        
 
                                        CCE allows you to mount a volume created from an Object Storage Service (OBS) bucket to a container to store data persistently. Object storage is commonly used in cloud workloads, data analysis, content analysis, and hotspot objects.
                                        
-
                                        Figure 1 Mounting OBS volumes to CCE
                                        
+
                                        Figure 1 Mounting OBS volumes to CCE
                                        
 
                                        Storage Class
                                        Object storage offers three storage classes, Standard, Infrequent Access, and Archive, to satisfy different requirements for storage performance and costs.
                                        
 
                                        • The Standard storage class features low access latency and high throughput. It is therefore applicable to storing a large number of hot files (frequently accessed every month) or small files (less than 1 MB). The application scenarios include big data analytics, mobile apps, hot videos, and picture processing on social media.
                                        • The Infrequent Access storage class is ideal for storing data that is semi-frequently accessed (less than 12 times a year), with requirements for quick response. The application scenarios include file synchronization or sharing, and enterprise-level backup. It provides the same durability, access latency, and throughput as the Standard storage class but at a lower cost. However, the Infrequent Access storage class has lower availability than the Standard storage class.
                                        • The Archive storage class is suitable for archiving data that is rarely-accessed (averagely once a year). The application scenarios include data archiving and long-term data backup. The Archive storage class is secure and durable at an affordable low cost, which can be used to replace tape libraries. However, it may take hours to restore data from the Archive storage class.
                                        
 
                                        
diff --git a/docs/cce/umn/cce_10_0325.html b/docs/cce/umn/cce_10_0325.html
index c89ffb46..29e2c7b0 100644
--- a/docs/cce/umn/cce_10_0325.html
+++ b/docs/cce/umn/cce_10_0325.html
@@ -3,7 +3,7 @@
 
                                        (kubectl) Automatically Creating an OBS Volume
                                        
 
                                        Scenario
                                        During the use of OBS, expected OBS buckets can be automatically created and mounted as volumes. Currently, standard and infrequent access OBS buckets are supported, which correspond to obs-standard and obs-standard-ia, respectively.
                                        
 
                                        
-
                                        Notes and Constraints
                                        The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                        
+
                                        Notes and Constraints
                                        The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                        
 
                                        
 
                                        Procedure
                                        1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                        2. Run the following commands to configure the pvc-obs-auto-example.yaml file, which is used to create a PVC.
                                          touch pvc-obs-auto-example.yaml
                                          
 
                                          vi pvc-obs-auto-example.yaml
                                          
diff --git a/docs/cce/umn/cce_10_0326.html b/docs/cce/umn/cce_10_0326.html
index cd4f804a..f7f2bb7c 100644
--- a/docs/cce/umn/cce_10_0326.html
+++ b/docs/cce/umn/cce_10_0326.html
@@ -3,7 +3,7 @@
 
                                          (kubectl) Creating a PV from an Existing OBS Bucket
                                          
 
                                          Scenario
                                          CCE allows you to use an existing OBS bucket to create a PersistentVolume (PV). You can create a PersistentVolumeClaim (PVC) and bind it to the PV.
                                          
 
                                          
-
                                          Notes and Constraints
                                          The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                          
+
                                          Notes and Constraints
                                          The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                          
 
                                          
 
                                          Procedure
                                          1. Log in to the OBS console, create an OBS bucket, and record the bucket name and storage class.
                                          2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                          3. Create two YAML files for creating the PV and PVC. Assume that the file names are pv-obs-example.yaml and pvc-obs-example.yaml.
                                            touch pv-obs-example.yaml pvc-obs-example.yaml
                                            
 
diff --git a/docs/cce/umn/cce_10_0327.html b/docs/cce/umn/cce_10_0327.html
index 53ced888..8311cdc8 100644
--- a/docs/cce/umn/cce_10_0327.html
+++ b/docs/cce/umn/cce_10_0327.html
@@ -3,7 +3,7 @@
 
                                            (kubectl) Creating a Deployment Mounted with an OBS Volume
                                            
 
                                            Scenario
                                            After an OBS volume is created or imported to CCE, you can mount the volume to a workload.
                                            
 
                                            
-
                                            Notes and Constraints
                                            The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                            
+
                                            Notes and Constraints
                                            The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                            
 
                                            
 
                                            Procedure
                                            1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                            2. Run the following commands to configure the obs-deployment-example.yaml file, which is used to create a pod.
                                              touch obs-deployment-example.yaml
                                              
 
                                              vi obs-deployment-example.yaml
                                              
diff --git a/docs/cce/umn/cce_10_0328.html b/docs/cce/umn/cce_10_0328.html
index 8dac0ed4..c3472671 100644
--- a/docs/cce/umn/cce_10_0328.html
+++ b/docs/cce/umn/cce_10_0328.html
@@ -3,7 +3,7 @@
 
                                              (kubectl) Creating a StatefulSet Mounted with an OBS Volume
                                              
 
                                              Scenario
                                              CCE allows you to use an existing OBS volume to create a StatefulSet through a PersistentVolumeClaim (PVC).
                                              
 
                                              
-
                                              Notes and Constraints
                                              The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                              
+
                                              Notes and Constraints
                                              The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                              
 
                                              
 
                                              Procedure
                                              1. Create an OBS volume by referring to (kubectl) Automatically Creating an OBS Volume and obtain the PVC name.
                                              2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                              3. Create a YAML file for creating the workload. Assume that the file name is obs-statefulset-example.yaml.
                                                touch obs-statefulset-example.yaml
                                                
 
                                                vi obs-statefulset-example.yaml
                                                
diff --git a/docs/cce/umn/cce_10_0329.html b/docs/cce/umn/cce_10_0329.html
index e5bfba0d..e228da1b 100644
--- a/docs/cce/umn/cce_10_0329.html
+++ b/docs/cce/umn/cce_10_0329.html
@@ -15,7 +15,7 @@
 
 
 
                                                
-
                                                Parent topic: Storage (FlexVolume)
                                                
+
                                                Parent topic: Storage Management: FlexVolume (Deprecated)
                                                
 
                                                
 
                                              
 
diff --git a/docs/cce/umn/cce_10_0330.html b/docs/cce/umn/cce_10_0330.html
index 1a935be8..b4bf1923 100644
--- a/docs/cce/umn/cce_10_0330.html
+++ b/docs/cce/umn/cce_10_0330.html
@@ -2,7 +2,7 @@
 
 
                                              Overview
                                              
 
                                              CCE allows you to mount a volume created from an SFS Turbo file system to a container to store data persistently. Provisioned on demand and fast, SFS Turbo is suitable for DevOps, container microservices, and enterprise OA scenarios.
                                              
-
                                              Figure 1 Mounting SFS Turbo volumes to CCE
                                              
+
                                              Figure 1 Mounting SFS Turbo volumes to CCE
                                              
 
                                              Description
                                              • Standard file protocols: You can mount file systems as volumes to servers, the same as using local directories.
                                              • Data sharing: The same file system can be mounted to multiple servers, so that data can be shared.
                                              • Private network: User can access data only in private networks of data centers.
                                              • Data isolation: The on-cloud storage service provides exclusive cloud file storage, which delivers data isolation and ensures IOPS performance.
                                              • Use cases: Deployments/StatefulSets in the ReadWriteMany mode, DaemonSets, and jobs created for high-traffic websites, log storage, DevOps, and enterprise OA applications
                                              
 
                                              
 
                                              
diff --git a/docs/cce/umn/cce_10_0332.html b/docs/cce/umn/cce_10_0332.html
index 4d37c897..c6f4c8ef 100644
--- a/docs/cce/umn/cce_10_0332.html
+++ b/docs/cce/umn/cce_10_0332.html
@@ -3,7 +3,7 @@
 
                                              (kubectl) Creating a PV from an Existing SFS Turbo File System
                                              
 
                                              Scenario
                                              CCE allows you to use an existing SFS Turbo file system to create a PersistentVolume (PV). After the creation is successful, you can create a PersistentVolumeClaim (PVC) and bind it to the PV.
                                              
 
                                              
-
                                              Notes and Constraints
                                              The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                              
+
                                              Notes and Constraints
                                              The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                              
 
                                              
 
                                              Procedure
                                              1. Log in to the SFS console, create a file system, and record the file system ID, shared path, and capacity.
                                              2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                              3. Create two YAML files for creating the PV and PVC. Assume that the file names are pv-efs-example.yaml and pvc-efs-example.yaml.
                                                touch pv-efs-example.yaml pvc-efs-example.yaml
                                                
 
                                                • Example YAML file for the PV:
                                                  apiVersion: v1 
diff --git a/docs/cce/umn/cce_10_0333.html b/docs/cce/umn/cce_10_0333.html
index 4fd3b8d4..db3135c9 100644
--- a/docs/cce/umn/cce_10_0333.html
+++ b/docs/cce/umn/cce_10_0333.html
@@ -3,7 +3,7 @@
 
                                                  (kubectl) Creating a Deployment Mounted with an SFS Turbo Volume
                                                  
 
                                                  Scenario
                                                  After an SFS Turbo volume is created or imported to CCE, you can mount the volume to a workload.
                                                  
 
                                                  
-
                                                  Notes and Constraints
                                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                                  
+
                                                  Notes and Constraints
                                                  The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                                  
 
                                                  
 
                                                  Procedure
                                                  1. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                                  2. Run the following commands to configure the efs-deployment-example.yaml file, which is used to create a Deployment:
                                                    touch efs-deployment-example.yaml
                                                    
 
                                                    vi efs-deployment-example.yaml
                                                    
diff --git a/docs/cce/umn/cce_10_0334.html b/docs/cce/umn/cce_10_0334.html
index 0e81efd3..a40fd04d 100644
--- a/docs/cce/umn/cce_10_0334.html
+++ b/docs/cce/umn/cce_10_0334.html
@@ -3,7 +3,7 @@
 
                                                    (kubectl) Creating a StatefulSet Mounted with an SFS Turbo Volume
                                                    
 
                                                    Scenario
                                                    CCE allows you to use an existing SFS Turbo volume to create a StatefulSet.
                                                    
 
                                                    
-
                                                    Notes and Constraints
                                                    The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                                    
+
                                                    Notes and Constraints
                                                    The following configuration example applies to clusters of Kubernetes 1.13 or earlier.
                                                    
 
                                                    
 
                                                    Procedure
                                                    1. Create an SFS Turbo volume and record the volume name.
                                                    2. Use kubectl to connect to the cluster. For details, see Connecting to a Cluster Using kubectl.
                                                    3. Create a YAML file for creating the workload. Assume that the file name is efs-statefulset-example.yaml.
                                                      touch efs-statefulset-example.yaml
                                                      
 
                                                      vi efs-statefulset-example.yaml
                                                      
diff --git a/docs/cce/umn/cce_10_0336.html b/docs/cce/umn/cce_10_0336.html
index 5e271acd..57a81e49 100644
--- a/docs/cce/umn/cce_10_0336.html
+++ b/docs/cce/umn/cce_10_0336.html
@@ -13,11 +13,12 @@
 
                                                    
 
                                                    kubectl edit ds everest-csi-driver -nkube-system
                                                    
 
                                                    Search for disable-auto-mount-secret and set it to true.
                                                    
-
                                                    
+
                                                    
 
                                                    Run :wq to save the settings and exit. Wait until the pod is restarted.
                                                    
 
                                                    
-
                                                    Creating a Secret Using an Access Key
                                                    1. Obtain an access key.
                                                      For details, see Creating Access Keys (AK and SK).
                                                      
-
                                                    2. Encode the keys using Base64. (Assume that the AK is xxx and the SK is yyy.)
                                                      echo -n xxx|base64
                                                      
+
                                                      Obtaining an Access Key
                                                      1. Log in to the console.
                                                      2. Hover the cursor over the username in the upper right corner and choose My Credentials from the drop-down list.
                                                      3. In the navigation pane, choose Access Keys.
                                                      4. Click Create Access Key. The Create Access Key dialog box is displayed.
                                                      5. Click OK to download the AK/SK.
                                                      
+
                                                      
+
                                                      Creating a Secret Using an Access Key
                                                      1. Obtain an access key.
                                                      2. Encode the keys using Base64. (Assume that the AK is xxx and the SK is yyy.)
                                                        echo -n xxx|base64
                                                        
 
                                                        echo -n yyy|base64
                                                        
 
                                                        Record the encoded AK and SK.
                                                        
 
                                                      3. Create a YAML file for the secret, for example, test-user.yaml.
                                                        apiVersion: v1
@@ -33,40 +34,40 @@ metadata:
 type: cfe/secure-opaque
                                                        
 
                                                        Specifically:
                                                        
 
-
                                                        Parameter
                                                        
+
                                                        
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -103,26 +104,26 @@ spec:
   persistentVolumeReclaimPolicy: Delete
   storageClassName: csi-obs
 
-
                                                        Parameter
                                                        
 
                                                        Description
                                                        
+
                                                        Description
                                                        
                                                         		
 
                                                        
 
                                                        access.key
                                                        
+
                                                        access.key
                                                        
 
                                                        Base64-encoded AK.
                                                        
+
                                                        Base64-encoded AK.
                                                        
                                                         		
 
                                                        secret.key
                                                        
+
                                                        secret.key
                                                        
 
                                                        Base64-encoded SK.
                                                        
+
                                                        Base64-encoded SK.
                                                        
                                                         		
 
                                                        name
                                                        
+
                                                        name
                                                        
 
                                                        Secret name.
                                                        
+
                                                        Secret name.
                                                        
                                                         		
 
                                                        namespace
                                                        
+
                                                        namespace
                                                        
 
                                                        Namespace of the secret.
                                                        
+
                                                        Namespace of the secret.
                                                        
                                                         		
 
                                                        secret.kubernetes.io/used-by: csi
                                                        
+
                                                        secret.kubernetes.io/used-by: csi
                                                        
 
                                                        You need to add this label in the YAML file if you want to make it available on the CCE console when you create an OBS PV/PVC.
                                                        
+
                                                        You need to add this label in the YAML file if you want to make it available on the CCE console when you create an OBS PV/PVC.
                                                        
                                                         		
 
                                                        type
                                                        
+
                                                        type
                                                        
 
                                                        Secret type. The value must be cfe/secure-opaque.
                                                        
+
                                                        Secret type. The value must be cfe/secure-opaque.
                                                        
 
                                                        When this type is used, the data entered by users is automatically encrypted.
                                                        
                                                         		
 
                                                        Parameter
                                                        
+
                                                        
-
-
-
-
-
-
-
@@ -151,20 +152,20 @@ spec:
   storageClassName: csi-obs
   volumeName: pv-obs-example
 
-
                                                        Parameter
                                                        
 
                                                        Description
                                                        
+
                                                        Description
                                                        
                                                         		
 
                                                        
 
                                                        nodePublishSecretRef
                                                        
+
                                                        nodePublishSecretRef
                                                        
 
                                                        Secret specified during the mounting.
                                                        
+
                                                        Secret specified during the mounting.
                                                        
 
                                                        • name: name of the secret
                                                        • namespace: namespace of the secret
                                                        
                                                         		
 
                                                        fsType
                                                        
+
                                                        fsType
                                                        
 
                                                        File type. The value can be obsfs or s3fs. If the value is s3fs, an OBS bucket is created and mounted using s3fs. If the value is obsfs, an OBS parallel file system is created and mounted using obsfs. You are advised to set this field to obsfs.
                                                        
+
                                                        File type. The value can be obsfs or s3fs. If the value is s3fs, an OBS bucket is created and mounted using s3fs. If the value is obsfs, an OBS parallel file system is created and mounted using obsfs. You are advised to set this field to obsfs.
                                                        
                                                         		
 
                                                        volumeHandle
                                                        
+
                                                        volumeHandle
                                                        
 
                                                        OBS bucket name.
                                                        
+
                                                        OBS bucket name.
                                                        
                                                         		
 
                                                        
 
                                                        Parameter
                                                        
+
                                                        
-
-
-
-
-
@@ -193,20 +194,20 @@ spec:
       storage: 1Gi
   storageClassName: csi-obs
 
-
                                                        Parameter
                                                        
 
                                                        Description
                                                        
+
                                                        Description
                                                        
                                                         		
 
                                                        
 
                                                        csi.storage.k8s.io/node-publish-secret-name
                                                        
+
                                                        csi.storage.k8s.io/node-publish-secret-name
                                                        
 
                                                        Name of the secret
                                                        
+
                                                        Name of the secret
                                                        
                                                         		
 
                                                        csi.storage.k8s.io/node-publish-secret-namespace
                                                        
+
                                                        csi.storage.k8s.io/node-publish-secret-namespace
                                                        
 
                                                        Namespace of the secret
                                                        
+
                                                        Namespace of the secret
                                                        
                                                         		
 
                                                        
 
                                                        
-
@@ -147,7 +147,7 @@ spec:
 
-
@@ -221,7 +221,7 @@ spec:
 
-
@@ -284,7 +284,7 @@ spec:
 
-
@@ -359,7 +359,7 @@ spec:
 
-
@@ -472,7 +472,7 @@ spec:
 
-
-
@@ -69,13 +69,13 @@
 
@@ -83,69 +83,69 @@
 
                                                        ConfigMap
                                                        The data stored in a ConfigMap can be referenced in a volume of type ConfigMap. You can mount such a volume to a specified container path. The platform supports the separation of workload codes and configuration files. ConfigMap volumes are used to store workload configuration parameters. Before that, you need to create ConfigMaps in advance. For details, see Creating a ConfigMap. 
                                                        
-
                                                        1. Log in to the CCE console.
                                                        2. When creating a workload, click Data Storage in the Container Settings. Click Add Volume and choose ConfigMap from the drop-down list.
                                                        3. Set the local volume type to ConfigMap and set parameters for adding a local volume, as shown in Table 3.
                                                          
-
                                                        Parameter
                                                        
+
                                                        
-
-
-
-
-
@@ -224,8 +225,8 @@ spec:
 
                                                        Expected outputs:
                                                        touch: setting times of '/temp/test': No such file or directory
 command terminated with exit code 1
                                                        
-
                                                      4. Set the read/write permissions for the IAM user who mounted the OBS volume by referring to the bucket policy configuration.
                                                        
-
                                                        
+
                                                      5. Set the read/write permissions for the IAM user who mounted the OBS volume by referring to the bucket policy configuration.
                                                        
+
                                                        
 
                                                      6. Write data into the mouth path again. In this example, the write operation succeeded.
                                                        kubectl exec obs-secret-5cd558f76f-vxslv -- touch /temp/test
                                                        
 
                                                      7. Check the mount path in the container to see whether the data is successfully written.
                                                        kubectl exec obs-secret-5cd558f76f-vxslv -- ls -l /temp/
                                                        
 
                                                        Expected outputs:
                                                        
diff --git a/docs/cce/umn/cce_10_0337.html b/docs/cce/umn/cce_10_0337.html
index dada39f1..45ea515a 100644
--- a/docs/cce/umn/cce_10_0337.html
+++ b/docs/cce/umn/cce_10_0337.html
@@ -124,7 +124,7 @@
 
 
                                                        Notes and Constraints
                                                        Mount options cannot be configured for secure containers.
                                                        
 
                                                        
-
                                                        Setting Mount Options in a PV
                                                        You can use the mountOptions field to set mount options in a PV. The options you can configure in mountOptions are listed in SFS Volume Mount Options and OBS Volume Mount Options.
                                                        
+
                                                        Setting Mount Options in a PV
                                                        You can use the mountOptions field to set mount options in a PV. The options you can configure in mountOptions are listed in SFS Volume Mount Options and OBS Volume Mount Options.
                                                        
 
                                                        apiVersion: v1
 kind: PersistentVolume
 metadata:
@@ -157,7 +157,7 @@ spec:
   storageClassName: csi-obs
                                                        
 
                                                        After a PV is created, you can create a PVC and bind it to the PV, and then mount the PV to the container in the workload.
                                                        
 
                                                        
-
                                                        Setting Mount Options in a StorageClass
                                                        You can use the mountOptions field to set mount options in a StorageClass. The options you can configure in mountOptions are listed in SFS Volume Mount Options and OBS Volume Mount Options.
                                                        
+
                                                        Setting Mount Options in a StorageClass
                                                        You can use the mountOptions field to set mount options in a StorageClass. The options you can configure in mountOptions are listed in SFS Volume Mount Options and OBS Volume Mount Options.
                                                        
 
                                                        apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
diff --git a/docs/cce/umn/cce_10_0341.html b/docs/cce/umn/cce_10_0341.html
index 078a4ab0..161a694f 100644
--- a/docs/cce/umn/cce_10_0341.html
+++ b/docs/cce/umn/cce_10_0341.html
@@ -19,10 +19,10 @@ Storage Driver: devicemapper
                                                        
 
                                                        • Rootfs (Device Mapper)
                                                          By default, 90% of the data disk is the container engine and container image space, which can be divided into the following two parts:
                                                          • The /var/lib/docker directory is the Docker working directory and occupies 20% of the container runtime space by default. (Space size of the /var/lib/docker directory = Data disk space x 90% x 20%)
                                                          • The thin pool stores container image data, image metadata, and container data, and occupies 80% of the container runtime space by default. (Thin pool space = Data disk space x 90% x 80%)
                                                            The thin pool is dynamically mounted. You can view it by running the lsblk command on a node, but not the df -h command.
                                                            
 
                                                          
 
                                                          
-
                                                          
+
                                                          
 
                                                        
 
                                                        • Rootfs (OverlayFS)
                                                          No separate thin pool. The entire container engine and container image space (90% of the data disk by default) are in the /var/lib/docker directory.
                                                          
-
                                                          
+
                                                          
 
                                                        
 
                                                        Using rootfs for container storage in CCE
                                                        • CCE cluster: EulerOS 2.5 nodes use Device Mapper and EulerOS 2.9 nodes use OverlayFS. CentOS 7.x nodes in clusters earlier than v1.19.16 use Device Mapper, and use OverlayFS in clusters of v1.19.16 and later. 
                                                        • CCE Turbo cluster: BMSs use Device Mapper. ECSs use OverlayFS.
                                                        
 
                                                        
diff --git a/docs/cce/umn/cce_10_0342.html b/docs/cce/umn/cce_10_0342.html
index 6b620951..710fc178 100644
--- a/docs/cce/umn/cce_10_0342.html
+++ b/docs/cce/umn/cce_10_0342.html
@@ -7,9 +7,9 @@
 
 
                                                        8. 
-
-
@@ -17,30 +17,30 @@
 
-
-
-
-
-
-
-
-
@@ -51,24 +51,24 @@
 
-
-
-
                                                        Parameter
                                                        
 
                                                        Description
                                                        
+
                                                        Description
                                                        
                                                         		
 
                                                        
 
                                                        csi.storage.k8s.io/node-publish-secret-name
                                                        
+
                                                        csi.storage.k8s.io/node-publish-secret-name
                                                        
 
                                                        Name of the secret
                                                        
+
                                                        Name of the secret
                                                        
                                                         		
 
                                                        csi.storage.k8s.io/node-publish-secret-namespace
                                                        
+
                                                        csi.storage.k8s.io/node-publish-secret-namespace
                                                        
 
                                                        Namespace of the secret
                                                        
+
                                                        Namespace of the secret
                                                        
                                                         		
 
                                                        
                                                         
 
                                                        Sub-dimension
                                                        
 
                                                        CCE Turbo Cluster
                                                        
+
                                                        CCE Turbo cluster
                                                        
 
                                                        CCE Cluster
                                                        
+
                                                        CCE cluster
                                                        
                                                         		
 
                                                        
 
 
                                                        Positioning
                                                        
 
                                                        Next-gen container cluster, with accelerated computing, networking, and scheduling. Designed for Cloud Native 2.0
                                                        
+
                                                        Next-gen container cluster, with accelerated computing, networking, and scheduling. Designed for Cloud Native 2.0
                                                        
 
                                                        Standard cluster for common commercial use
                                                        
+
                                                        Standard cluster for common commercial use
                                                        
                                                         		
 
                                                        
 
                                                        Node type
                                                        
 
                                                        Hybrid deployment of VMs and bare-metal servers
                                                        
+
                                                        Deployment of VMs
                                                        
 
                                                        Hybrid deployment of VMs
                                                        
+
                                                        Hybrid deployment of VMs and bare metal servers
                                                        
                                                         		
 
                                                        Networking
                                                        
+
                                                        Network
                                                        
                                                         		
 
                                                        Model
                                                        
 
                                                        Cloud Native Network 2.0: applies to large-scale and high-performance scenarios.
                                                        
+
                                                        Cloud Native Network 2.0: applies to large-scale and high-performance scenarios.
                                                        
 
                                                        Max networking scale: 2,000 nodes
                                                        
 
                                                        Cloud-native network 1.0: applies to common, smaller-scale scenarios.
                                                        
-
                                                        • Tunnel network model
                                                        • VPC network model
                                                        
+
                                                        Cloud-native network 1.0: applies to common, smaller-scale scenarios.
                                                        
+
                                                        • Container tunnel network model
                                                        • VPC network model
                                                        
                                                         		
 
                                                        Performance
                                                        
+
                                                        Network performance
                                                        
                                                         		
 
                                                        Flattens the VPC network and container network into one. No performance loss.
                                                        
                                                         		
 
                                                        Associates pods with security groups. Unifies security isolation in and out the cluster via security groups' network policies.
                                                        
 
                                                        • Tunnel network model: supports network policies for intra-cluster communications.
                                                        • VPC network model: supports no isolation.
                                                        
+
                                                        • Container tunnel network model: supports network policies for intra-cluster communications.
                                                        • VPC network model: supports no isolation.
                                                        
                                                         		
 
                                                        
 
                                                        Security
                                                        
                                                         		
 
                                                        Isolation
                                                        
 
                                                        • Physical machine: runs Kata containers, allowing VM-level isolation.
                                                        • VM: runs common containers.
                                                        
+
                                                        • VM: runs common containers, isolated by cgroups.
                                                        
 
                                                        Runs common containers, isolated by cgroups.
                                                        
+
                                                        Common containers are deployed and isolated by cgroups.
                                                        
                                                         		
 
                                                        
                                                         
 
                                                        
 
                                                        
 
-
                                                        QingTian Architecture
                                                        
-
                                                        The QingTian architecture consists of data plane (software-hardware synergy) and management plane (Alkaid Smart Cloud Brain). The data plane innovates in five dimensions: simplified data center, diversified computing power, QingTian cards, ultra-fast engines, and simplified virtualization, to fully offload and accelerate compute, storage, networking, and security components. VMs, bare metal servers, and containers can run together. As a distributed operating system, the Alkaid Smart Cloud Brain focuses on the cloud, AI, and 5G, and provide all-domain scheduling to achieve cloud-edge-device collaboration and governance.
                                                        
+
                                                        QingTian Architecture
                                                        
+
                                                        The QingTian architecture consists of data plane (software-hardware synergy) and management plane (Alkaid Smart Cloud Brain). The data plane innovates in five dimensions: simplified data center, diversified computing power, QingTian cards, ultra-fast engines, and simplified virtualization, to fully offload and accelerate compute, storage, networking, and security components. VMs, bare metal servers, and containers can run together. As a distributed operating system, the Alkaid Smart Cloud Brain focuses on the cloud, AI, and 5G, and provide all-domain scheduling to achieve cloud-edge-device collaboration and governance.
                                                        
 
                                                        
 
                                                        
 
                                                        
diff --git a/docs/cce/umn/cce_10_0343.html b/docs/cce/umn/cce_10_0343.html
index 21b20726..583409be 100644
--- a/docs/cce/umn/cce_10_0343.html
+++ b/docs/cce/umn/cce_10_0343.html
@@ -84,7 +84,7 @@ spec:
 
                                                        
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class associated with the storage volume. Set this field to csi-disk for EVS disks.
                                                        
+
                                                        Name of the Kubernetes storage class associated with the storage volume. Set this field to csi-disk for EVS disks.
                                                        
                                                         		
 
                                                        
 
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class. Set this field to csi-nas.
                                                        
+
                                                        Name of the Kubernetes storage class. Set this field to csi-nas.
                                                        
                                                         		
 
                                                        
 
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class. Set this field to csi-obs.
                                                        
+
                                                        Name of the Kubernetes storage class. Set this field to csi-obs.
                                                        
                                                         		
 
                                                        
 
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class. Set this field to csi-sfsturbo for SFS Turbo volumes.
                                                        
+
                                                        Name of the Kubernetes storage class. Set this field to csi-sfsturbo for SFS Turbo volumes.
                                                        
                                                         		
 
                                                        
 
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class. Set this field to csi-disk for EVS disks.
                                                        
+
                                                        Name of the Kubernetes storage class. Set this field to csi-disk for EVS disks.
                                                        
                                                         		
 
                                                        
 
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class. Set this field to csi-obs.
                                                        
+
                                                        Name of the Kubernetes storage class. Set this field to csi-obs.
                                                        
                                                         		
 
                                                        
 
                                                        volumeName
                                                        
@@ -520,7 +520,7 @@ spec:
 
                                                        
 
                                                        storageClassName
                                                        
 
                                                        Name of the Kubernetes storage class. Set this field to csi-sfsturbo.
                                                        
+
                                                        Name of the Kubernetes storage class. Set this field to csi-sfsturbo.
                                                        
                                                         		
 
                                                        
 
                                                        storage
                                                        
@@ -549,7 +549,7 @@ spec:
 
                                                         
                                                        Replace the example file name pvc-example.yaml in the preceding commands with the names of the YAML files configured in 2 and 3.
                                                        
 
                                                        
 
                                                      8. Run the kubectl edit command to edit the StatefulSet and use the newly created PVC.
                                                        kubectl edit sts sts-example -n xxx
                                                        
-
                                                        
+
                                                        
 
                                                         
                                                        Replace sts-example in the preceding command with the actual name of the StatefulSet to upgrade. xxx indicates the namespace to which the StatefulSet belongs.
                                                        
 
                                                        
 
                                                      9. Wait until the pods are running.
                                                        10. 
@@ -563,7 +563,7 @@ spec:
 
                                                         
                                                        Replace the example file name pvc-example.yaml in the preceding commands with the names of the YAML files configured in 2 and 3.
                                                        
 
                                                        
 
                                                      10. Change the number of pods back to the original value and wait until the pods are running.
                                                        11. 
-
                                                         
                                                        The dynamic allocation of storage for StatefulSets is achieved by using volumeClaimTemplates. This field cannot be modified by Kubernetes. Therefore, data cannot be migrated by using a new PVC.
                                                        
+
                                                         
                                                        The dynamic allocation of storage for StatefulSets is achieved by using volumeClaimTemplates. This field cannot be modified by Kubernetes. Therefore, data cannot be migrated by using a new PVC.
                                                        
 
                                                        The PVC naming rule of the volumeClaimTemplates is fixed. When a PVC that meets the naming rule exists, this PVC is used.
                                                        
 
                                                        Therefore, disassociate the original PVC first, and then create a PVC with the same name in the CSI format.
                                                        
 
                                                        
@@ -639,7 +639,7 @@ spec:
 
                                                        
 
 
diff --git a/docs/cce/umn/cce_10_0345.html b/docs/cce/umn/cce_10_0345.html
index ec10e4c0..e8dca82e 100644
--- a/docs/cce/umn/cce_10_0345.html
+++ b/docs/cce/umn/cce_10_0345.html
@@ -45,7 +45,7 @@ spec:
 
                                                        After nvidia.com/gpu is specified, workloads will not be scheduled to nodes without GPUs. If the node is GPU-starved, Kubernetes events similar to the following are reported:
                                                        
 
                                                        • 0/2 nodes are available: 2 Insufficient nvidia.com/gpu.
                                                        • 0/4 nodes are available: 1 InsufficientResourceOnSingleGPU, 3 Insufficient nvidia.com/gpu.
                                                        
 
                                                        To use GPUs on the CCE console, select the GPU quota and specify the percentage of GPUs reserved for the container when creating a workload.
                                                        
-
                                                        Figure 1 Using GPUs
                                                        
+
                                                        Figure 1 Using GPUs
                                                        
 
                                                        
 
                                                        GPU Node Labels
                                                        CCE will label GPU-enabled nodes after they are created. Different types of GPU-enabled nodes have different labels.
                                                        
 
                                                        $ kubectl get node -L accelerator
diff --git a/docs/cce/umn/cce_10_0348.html b/docs/cce/umn/cce_10_0348.html
index 798d9c12..387f20b0 100644
--- a/docs/cce/umn/cce_10_0348.html
+++ b/docs/cce/umn/cce_10_0348.html
@@ -6,10 +6,10 @@
 
                                                        The maximum number of pods that can be created on a node depends on the minimum value of these parameters.
                                                        
 
 
                                                        Container Network vs. Host Network
                                                        When creating a pod, you can select the container network or host network for the pod.
                                                        
-
                                                        • Container network (default): Each pod is assigned an IP address by the cluster networking add-ons, which occupies the IP addresses of the container network.
                                                        • Host network: The pod uses the host network (hostNetwork: true needs to be configured for the pod) and occupies the host port. The pod IP address is the host IP address. The pod does not occupy the IP addresses of the container network. To use the host network, you must confirm whether the container ports conflict with the host ports. Do not use the host network unless you know exactly which host port is used by which container.
                                                        
+
                                                        • Container network (default): Each pod is assigned an IP address by the cluster networking add-ons, which occupies the IP addresses of the container network.
                                                        • Host network: The pod uses the host network (hostNetwork: true needs to be configured for the pod) and occupies the host port. The pod IP address is the host IP address. The pod does not occupy the IP addresses of the container network. To use the host network, you must confirm whether the container ports conflict with the host ports. Do not use the host network unless you know exactly which host port is used by which container.
                                                        
 
                                                        
 
                                                        Number of Container IP Addresses That Can Be Allocated on a Node
                                                        If you select VPC network for Network Model when creating a CCE cluster, you also need to set the number of container IP addresses that can be allocated to each node.
                                                        
-
                                                        This parameter affects the maximum number of pods that can be created on a node. Each pod occupies an IP address (when the container network is used). If the number of available IP addresses is insufficient, pods cannot be created.
                                                        
+
                                                        This parameter affects the maximum number of pods that can be created on a node. Each pod occupies an IP address (when the container network is used). If the number of available IP addresses is insufficient, pods cannot be created.
                                                        
 
                                                        
 
                                                        By default, a node occupies three container IP addresses (network address, gateway address, and broadcast address). Therefore, the number of container IP addresses that can be allocated to a node equals the number of selected container IP addresses minus 3. For example, in the preceding figure, the number of container IP addresses that can be allocated to a node is 125 (128 – 3).
                                                        
 
                                                        
diff --git a/docs/cce/umn/cce_10_0351.html b/docs/cce/umn/cce_10_0351.html
index 185ae921..99ebd9ea 100644
--- a/docs/cce/umn/cce_10_0351.html
+++ b/docs/cce/umn/cce_10_0351.html
@@ -5,13 +5,13 @@
 
                                                        • CPU throttling
                                                        • Context switching
                                                        • Processor cache misses
                                                        • Cross-socket memory access
                                                        • Hyperthreads that are expected to run on the same physical CPU card
                                                        
 
                                                        If your workloads are sensitive to any of these items and CPU cache affinity and scheduling latency significantly affect workload performance, kubelet allows alternative CPU management policies to determine some placement preferences on the node. The CPU manager preferentially allocates resources on a socket and full physical cores to avoid interference.
                                                        
 
                                                        Binding CPU Cores to a Pod
                                                        Prerequisites:
                                                        
-
                                                        • The static core binding policy is enabled on the node. For details, see Enabling the CPU Management Policy.
                                                        • Both requests and limits must be set in the pod definition and their values must be the same.
                                                        • The value of requests must be an integer for the container.
                                                        • For an init container, it is recommended that you set its requests to the same as that of the service container. Otherwise, the service container does not inherit the CPU allocation result of the init container, and the CPU manager reserves more CPU resources than supposed. For more information, see App Containers can't inherit Init Containers CPUs - CPU Manager Static Policy.
                                                        
+
                                                        • The static core binding policy is enabled on the node. For details, see Enabling the CPU Management Policy.
                                                        • Both requests and limits must be set in the pod definition and their values must be the same.
                                                        • The value of requests must be an integer for the container.
                                                        • For an init container, it is recommended that you set its requests to the same as that of the service container. Otherwise, the service container does not inherit the CPU allocation result of the init container, and the CPU manager reserves more CPU resources than supposed. For more information, see App Containers can't inherit Init Containers CPUs - CPU Manager Static Policy.
                                                        
 
                                                        You can use Scheduling Policy (Affinity/Anti-affinity) to schedule the configured pods to the nodes where the static CPU policy is enabled. In this way, cores can be bound.
                                                        
 
                                                        
 
                                                        Enabling the CPU Management Policy
                                                        A CPU management policy is specified by the kubelet flag --cpu-manager-policy. The following policies are supported:
                                                        
 
                                                        • Disabled (none): the default policy. The none policy explicitly enables the existing default CPU affinity scheme, providing no affinity beyond what the OS scheduler does automatically.
                                                        • Enabled (static): The static policy allows containers in Guaranteed pods with integer CPU requests to be granted increased CPU affinity and exclusivity on the node.
                                                        
 
                                                        When creating a cluster, you can configure the CPU management policy in Advanced Settings, as shown in the following figure.
                                                        
-
                                                        
+
                                                        
 
                                                        You can also configure the policy in a node pool. The configuration will change the kubelet flag --cpu-manager-policy on the node. Log in to the CCE console, click the cluster name, access the cluster details page, and choose Nodes in the navigation pane. On the page displayed, click the Node Pools tab. Choose More > Manage in the Operation column of the target node pool, and change the value of cpu-manager-policy to static.
                                                        
 
                                                        
 
                                                        Pod Configuration
                                                        For CPU, both requests and limits must be set to the same, and requests must be an integer.
                                                        
diff --git a/docs/cce/umn/cce_10_0360.html b/docs/cce/umn/cce_10_0360.html
index 918f84d1..60b05f9f 100644
--- a/docs/cce/umn/cce_10_0360.html
+++ b/docs/cce/umn/cce_10_0360.html
@@ -21,7 +21,7 @@ nameserver 10.247.3.10
 search default.svc.cluster.local svc.cluster.local cluster.local
 options ndots:5 timeout single-request-reopen
                                                        
 
                                                        When a user accesses the Service name:Port of the Nginx pod, the IP address of the Nginx Service is resolved from CoreDNS, and then the IP address of the Nginx Service is accessed. In this way, the user can access the backend Nginx pod.
                                                        
-
                                                        Figure 1 Example of domain name resolution in a cluster
                                                        
+
                                                        Figure 1 Example of domain name resolution in a cluster
                                                        
 
                                                        
 
                                                        Related Operations
                                                        You can also configure DNS in a workload. For details, see DNS Configuration.
                                                        
 
                                                        You can also use coredns to implement user-defined domain name resolution. For details, see Using CoreDNS for Custom Domain Name Resolution.
                                                        
diff --git a/docs/cce/umn/cce_10_0361.html b/docs/cce/umn/cce_10_0361.html
index de760df9..5fa44037 100644
--- a/docs/cce/umn/cce_10_0361.html
+++ b/docs/cce/umn/cce_10_0361.html
@@ -13,8 +13,8 @@
 
                                                        Assume that a cluster administrator has a Consul DNS server located at 10.150.0.1 and all Consul domain names have the suffix .consul.local.
                                                        
 
                                                        1. Log in to the CCE console and access the cluster console.
                                                        2. In the navigation pane, choose Add-ons. On the displayed page, click Edit under CoreDNS.
                                                        3. Add a stub domain in the Parameters area.
                                                          Modify the stub_domains parameter in the format of a key-value pair. The key is a DNS suffix domain name, and the value is a DNS IP address or a group of DNS IP addresses.
                                                          {
 	"stub_domains": {
-                "consul.local": [
-			"10.150.0.1"
+                "consul.local": [
+			"10.150.0.1"
 		]
 	},
 	"upstream_nameservers": []
@@ -22,6 +22,8 @@
 
                                                          
 
                                                        4. Click OK.
                                                        
 
                                                        You can also modify the ConfigMap as follows:
                                                        
+
                                                         
                                                        The parameter values in red in the example can only be modified and cannot be deleted.
                                                        
+
                                                        
 
                                                        $ kubectl edit configmap coredns -n kube-system
 apiVersion: v1
 data:
@@ -43,11 +45,11 @@ data:
         reload
     }
 
-    consul.local:5353 {
+    consul.local:5353 {
         bind {$POD_IP}
         errors
         cache 30
-        forward . 10.150.0.1
+        forward . 10.150.0.1
     }
 kind: ConfigMap
 metadata:
diff --git a/docs/cce/umn/cce_10_0363.html b/docs/cce/umn/cce_10_0363.html
index 44f8d147..afef62b0 100644
--- a/docs/cce/umn/cce_10_0363.html
+++ b/docs/cce/umn/cce_10_0363.html
@@ -3,10 +3,10 @@
 
                                                        Creating a Node
                                                        
 
                                                        Prerequisites
                                                        • At least one cluster has been created.
                                                        • A key pair has been created for identity authentication upon remote node login.
                                                        
 
                                                        
-
                                                        Notes and Constraints
                                                        • The node has 2-core or higher CPU, 4 GB or larger memory.
                                                        • To ensure node stability, a certain amount of CCE node resources will be reserved for Kubernetes components (such as kubelet, kube-proxy, and docker) based on the node specifications. Therefore, the total number of node resources and assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, more node resources need to be reserved to run Kubernetes components. For details, see Formula for Calculating the Reserved Resources of a Node.
                                                        • The node networking (such as the VM networking and container networking) is taken over by CCE. You are not allowed to add and delete NICs or change routes. If you modify the networking configuration, the availability of CCE may be affected. For example, the NIC named gw_11cbf51a@eth0 on the node is the container network gateway and cannot be modified.
                                                        • During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name.
                                                        • Once a node is created, its AZ cannot be changed.
                                                        
+
                                                        Notes and Constraints
                                                        • The node has 2-core or higher CPU, 4 GB or larger memory.
                                                        • To ensure node stability, a certain amount of CCE node resources will be reserved for Kubernetes components (such as kubelet, kube-proxy, and docker) based on the node specifications. Therefore, the total number of node resources and assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, more node resources need to be reserved to run Kubernetes components. For details, see Formula for Calculating the Reserved Resources of a Node.
                                                        • The node networking (such as the VM networking and container networking) is taken over by CCE. You are not allowed to add and delete NICs or change routes. If you modify the networking configuration, the availability of CCE may be affected. For example, the NIC named gw_11cbf51a@eth0 on the node is the container network gateway and cannot be modified.
                                                        • During the node creation, software packages are downloaded from OBS using the domain name. You need to use a private DNS server to resolve the OBS domain name, and configure the DNS server address of the subnet where the node resides with a private DNS server address. When you create a subnet, the private DNS server is used by default. If you change the subnet DNS, ensure that the DNS server in use can resolve the OBS domain name.
                                                        • Once a node is created, its AZ cannot be changed.
                                                        
 
                                                        
-
                                                        Procedure
                                                        After a cluster is created, you can create nodes for the cluster.
                                                        
-
                                                        1. Log in to the CCE console. In the navigation pane, choose Clusters. Click the target cluster name to access its details page.
                                                        2. In the navigation pane on the left, choose Nodes. On the page displayed, click Create Node. In the Node Settings step, set node parameters by referring to the following table.
                                                          Compute Settings
                                                          
+
                                                          Procedure
                                                          After a cluster is created, you can create nodes for the cluster.
                                                          
+
                                                          1. Log in to the CCE console. In the navigation pane, choose Clusters. Click the target cluster name to access its details page.
                                                          2. In the navigation pane on the left, choose Nodes. On the page displayed, click Create Node. In the Node Settings step, set node parameters by referring to the following table.
                                                            Compute Settings
                                                            
 
                                                            You can configure the specifications and OS of a cloud server, on which your containerized applications run.
 
                                                            
@@ -17,20 +17,22 @@
 
-
-
@@ -55,7 +57,7 @@
 
@@ -74,14 +76,15 @@
 
-
+
+
+
                                                            Table 1 Configuration parameters
                                                            Parameter
                                                            
 
                                                            AZ
                                                            
                                                             		
 
                                                            AZ where the node is located. Nodes in a cluster can be created in different AZs for higher reliability. The value cannot be changed after the node is created.
                                                            
-
                                                            You are advised to select Random to deploy your node in a random AZ based on the selected node flavor.
                                                            
+
                                                            You are advised to select Random to deploy your node in a random AZ based on the selected node flavor.
                                                            
 
                                                            An AZ is a physical region where resources use independent power supply and networks. AZs are physically isolated but interconnected through an internal network. To enhance workload availability, create nodes in different AZs.
                                                            
                                                             		
 
                                                            
 
                                                            Node Type
                                                            
 
                                                            CCE clusters support Elastic Cloud Servers (ECSs).
                                                            
-
                                                            CCE Turbo clusters support Elastic Cloud Servers (ECSs) and bare metal servers (BMSs).
                                                            
+
                                                            CCE cluster:
                                                            • ECS (VM): Containers run on ECSs.
                                                            
+
                                                            
+
                                                            CCE Turbo cluster:
                                                            • ECS (VM): Containers run on ECSs. Only Trunkport ECSs (models that can be bound with multiple elastic network interfaces) are supported.
                                                            
+
                                                            
                                                             		
 
                                                            
 
                                                            Container Engine
                                                            
 
                                                            CCE clusters support Docker and containerd in some scenarios.
                                                            
-
                                                            • VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd.
                                                            • For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines. 
                                                            
+
                                                            CCE clusters support Docker and containerd in some scenarios.
                                                            • VPC network clusters of v1.23 and later versions support containerd. Container tunnel network clusters of v1.23.2-r0 and later versions support containerd.
                                                            • For a CCE Turbo cluster, both Docker and containerd are supported. For details, see Mapping between Node OSs and Container Engines.
                                                            
+
                                                            
                                                             		
 
                                                            
 
                                                            Specifications
                                                            
@@ -41,7 +43,7 @@
 
                                                            OS
                                                            
                                                             		
 
                                                            Select an OS type. Different types of nodes support different OSs.
                                                            
-
                                                            Public image: Select an OS for the node.
                                                            
+
                                                            Public image: Select an OS for the node.
                                                            
 
                                                            Private image: You can use private images. 
                                                            
                                                             		
 
                                                            Login Mode
                                                            
                                                             		
 
                                                            • Key Pair
                                                              Select the key pair used to log in to the node. You can select a shared key.
                                                              
-
                                                              A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.
                                                              
+
                                                              A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.
                                                              
 
                                                            
                                                             		
 
                                                            System Disk
                                                            
                                                             		
 
                                                            System disk used by the node OS. The value ranges from 40 GB to 1,024 GB. The default value is 50 GB.
                                                            
-
                                                            Encryption: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
                                                            • Encryption is not selected by default.
                                                            • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.
                                                            
+
                                                            Encryption: System disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
                                                            • Encryption is not selected by default.
                                                            • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.
                                                            
 
                                                            
 
                                                            		
 
                                                            
 
                                                            Data Disk
                                                            
 
                                                            Data disk used by the container runtime and kubelet on the node.  
                                                            
-
                                                            At least one data disk is required for the container runtime and kubelet. The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.
                                                            
+
                                                            At least one data disk is required for the container runtime and kubelet. The data disk cannot be deleted or uninstalled. Otherwise, the node will be unavailable.
                                                            
+
                                                            • First data disk: used for container runtime and kubelet components. The value ranges from 20 GB to 32,768 GB. The default value is 100 GB.
                                                            • Other data disks: You can set the data disk size to a value ranging from 10 GB to 32,768 GB. The default value is 100 GB.
                                                            
+
                                                            Advanced Settings
                                                            
 
                                                            Click Expand to set the following parameters:
                                                            
 
                                                            • Allocate Disk Space: Select this option to define the disk space occupied by the container runtime to store the working directories, container image data, and image metadata. For details about how to allocate data disk space, see Data Disk Space Allocation.
                                                            • Encryption: Data disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption function. This function is available only in certain regions.
                                                              • Encryption is not selected by default.
                                                              • After you select Encryption, you can select an existing key in the displayed dialog box. If no key is available, click View Key List to create a key. After the key is created, click the refresh icon.
                                                              
 
                                                            
@@ -115,11 +118,17 @@
 
                                                            IP address of the specified node. By default, the value is randomly allocated.
                                                            
                                                             		
 
                                                            EIP
                                                            
+
                                                            A cloud server without an EIP cannot access public networks or be accessed by public networks.
                                                            
+
                                                            The default value is Do not use. Use existing and Auto create are supported.
                                                            
+
                                                            
                                                             
 
                                                            
 
                                                            
 
                                                            
-
                                                            Advanced Settings
                                                            
+
                                                            Advanced Settings
                                                            
 
                                                            Configure advanced node capabilities such as labels, taints, and startup command.
 
                                                            
@@ -129,7 +138,7 @@
 
-
@@ -142,7 +151,7 @@
 
-
                                                            Table 4 Advanced configuration parameters
                                                            Parameter
                                                            
 
                                                            
 
                                                            Kubernetes Label
                                                            
 
                                                            Click Add Label to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.
                                                            
+
                                                            Click Add Label to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.
                                                            
 
                                                            Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.
                                                            
                                                             		
 
                                                            
 
                                                            Taint
                                                            
 
                                                            This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
                                                            • Key: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
                                                            • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
                                                            • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
                                                            
+
                                                            This parameter is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
                                                            • Key: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
                                                            • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
                                                            • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
                                                            
 
                                                            
 
                                                            For details, see Managing Node Taints.
                                                            
 
                                                             NOTE: 
                                                            For a cluster of v1.19 or earlier, the workload may have been scheduled to a node before the taint is added. To avoid such a situation, select a cluster of v1.19 or later.
                                                            
@@ -159,8 +168,8 @@
 
                                                            ECS Group
                                                            
                                                             		
 
                                                            An ECS group logically groups ECSs. The ECSs in the same ECS group comply with the same policy associated with the ECS group.
                                                            
-
                                                            Anti-affinity: ECSs in an ECS group are deployed on different physical hosts to improve service reliability.
                                                            
-
                                                            Select an existing ECS group, or click Add ECS Group to create one. After the ECS group is created, click the refresh button.
                                                            
+
                                                            Anti-affinity: ECSs in an ECS group are deployed on different physical hosts to improve service reliability.
                                                            
+
                                                            Select an existing ECS group, or click Add ECS Group to create one. After the ECS group is created, click the refresh button.
                                                            
                                                             		
 
                                                            
 
                                                            Pre-installation Command
                                                            
@@ -185,7 +194,7 @@
 
                                                            
 
                                                            
 
                                                            
-
                                                          3. Click Next: Confirm. Confirm the configured parameters, specifications. 
                                                          4. Click Submit.
                                                            The node list page is displayed. If the node status is Running, the node is created successfully. It takes about 6 to 10 minutes to create a node.
                                                            
+
                                                          5. Click Next: Confirm. Confirm the configured parameters, specifications. 
                                                          6. Click Submit.
                                                            The node list page is displayed. If the node status is Running, the node is created successfully. It takes about 6 to 10 minutes to create a node.
                                                            
 
                                                          7. Click Back to Node List. The node is created successfully if it changes to the Running state.
                                                          
 
                                                          
 
                                                        
diff --git a/docs/cce/umn/cce_10_0367.html b/docs/cce/umn/cce_10_0367.html
index 843f653e..3f1fd956 100644
--- a/docs/cce/umn/cce_10_0367.html
+++ b/docs/cce/umn/cce_10_0367.html
@@ -6,8 +6,8 @@
 
                                                        
 
                                                        Notes and Constraints
                                                        This feature is available only to clusters of v1.19 and later.
                                                        
 
                                                        
-
                                                        Customizing a SAN
                                                        1. Log in to the CCE console.
                                                        2. Click the target cluster in the cluster list to go to the cluster details page.
                                                        3. In the Connection Information area, click  next to Custom SAN. In the dialog box displayed, add the IP address or domain name and click Save.
                                                          
-
                                                           
                                                          1. This operation will restart kube-apiserver and update the kubeconfig.json file for a short period of time. Do not perform operations on the cluster during this period.
                                                          
+
                                                          Customizing a SAN
                                                          1. Log in to the CCE console.
                                                          2. Click the target cluster in the cluster list to go to the cluster details page.
                                                          3. In the Connection Information area, click  next to Custom SAN. In the dialog box displayed, add the IP address or domain name and click Save.
                                                            
+
                                                             
                                                            1. This operation will restart kube-apiserver and update the kubeconfig.json file for a short period of time. Do not perform operations on the cluster during this period.
                                                            
 
                                                            2. A maximum of 128 domain names or IP addresses, separated by commas (,), are allowed.
                                                            
 
                                                            3. If a custom domain name needs to be bound to an EIP, ensure that an EIP has been configured.
                                                            
 
                                                            
diff --git a/docs/cce/umn/cce_10_0377.html b/docs/cce/umn/cce_10_0377.html
index 6c3b3b9b..5d35c3e4 100644
--- a/docs/cce/umn/cce_10_0377.html
+++ b/docs/cce/umn/cce_10_0377.html
@@ -38,7 +38,7 @@
 
                                                          
 
                                                        4. Permission
                                                          • Read-only: You can only read the data volumes mounted to the path.
                                                          • Read/Write: You can modify the data volumes mounted to the path. Newly written data is not migrated if the container is migrated, which may cause a data loss.
                                                          
 
                                                        
-
                                                        You can click  to add multiple paths and subpaths.
                                                        
+
                                                        You can click  to add multiple paths and subpaths.
                                                        
 
                                                        		
 
                                                        
 
                                                        Add Container Path
                                                        
                                                         		
 
                                                        Configure the following parameters:
                                                        
-
                                                        1. subPath: Enter a subpath, for example, tmp.
                                                          A subpath is used to mount a local disk so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used by default.
                                                          
-
                                                        2. Container Path: Enter the path of the container, for example, /tmp.
                                                          This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
                                                           NOTICE: 
                                                          When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
                                                          
+
                                                          1. subPath: Enter a subpath, for example, tmp.
                                                            A subpath is used to mount a local disk so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used by default.
                                                            
+
                                                          2. Container Path: Enter the path of the container, for example, /tmp.
                                                            This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
                                                             NOTICE: 
                                                            When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
                                                            
 
                                                            
 
                                                            
-
                                                          3. Permission
                                                            • Read-only: You can only read the data volumes mounted to the path.
                                                            • Read/Write: You can modify the data volumes mounted to the path. Newly written data is not migrated if the container is migrated, which may cause a data loss.
                                                            
+
                                                          4. Permission
                                                            • Read-only: You can only read the data volumes mounted to the path.
                                                            • Read/Write: You can modify the data volumes mounted to the path. Newly written data is not migrated if the container is migrated, which may cause a data loss.
                                                            
 
                                                          
-
                                                          You can click  to add multiple paths and subpaths.
                                                          
+
                                                          You can click  to add multiple paths and subpaths.
                                                          
 
                                                        		
 
                                                        
 
 
 
 
                                                        Table 3 Setting parameters for mounting a ConfigMap volume
                                                        Parameter
                                                        
+
                                                        
-
-
-
-
-
-
-
                                                        Table 3 Setting parameters for mounting a ConfigMap volume
                                                        Parameter
                                                        
 
                                                        Description
                                                        
+
                                                        Description
                                                        
                                                         		
 
                                                        
 
                                                        Storage Type
                                                        
+
                                                        Storage Type
                                                        
 
                                                        Select ConfigMap.
                                                        
+
                                                        Select ConfigMap.
                                                        
                                                         		
 
                                                        Option
                                                        
+
                                                        Option
                                                        
 
                                                        Select the desired ConfigMap name.
                                                        
+
                                                        Select the desired ConfigMap name.
                                                        
 
                                                        A ConfigMap must be created in advance. For details, see Creating a ConfigMap.
                                                        
                                                         		
 
                                                        Add Container Path
                                                        
+
                                                        Add Container Path
                                                        
 
                                                        Configure the following parameters:
                                                        
+
                                                        Configure the following parameters:
                                                        
 
                                                        1. subPath: Enter a subpath, for example, tmp.
                                                          • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
                                                          • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
                                                          • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
                                                          
-
                                                        2. Container Path: Enter the path of the container, for example, /tmp.
                                                          This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
                                                           NOTICE: 
                                                          When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
                                                          
+
                                                        3. Container Path: Enter the path of the container, for example, /tmp.
                                                          This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
                                                           NOTICE: 
                                                          When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
                                                          
 
                                                          
 
                                                          
 
                                                        4. Set the permission to Read-only. Data volumes in the path are read-only.
                                                        
-
                                                        You can click  to add multiple paths and subpaths.
                                                        
+
                                                        You can click  to add multiple paths and subpaths.
                                                        
                                                         		
 
                                                        
                                                         
 
                                                        
 
                                                        
 
                                                        
+
 
                                                        Secret
                                                        You can mount a secret as a volume to the specified container path. Contents in a secret are user-defined. Before that, you need to create a secret. For details, see Creating a Secret.
                                                        
 
                                                        
 
                                                        1. Log in to the CCE console.
                                                        2. When creating a workload, click Data Storage in the Container Settings. Click Add Volume and choose Secret from the drop-down list.
                                                        3. Set the local volume type to Secret and set parameters for adding a local volume, as shown in Table 4.
                                                          
-
                                                          
-
@@ -147,7 +147,7 @@ spec:
 
-
@@ -221,7 +221,7 @@ spec:
 
-
@@ -284,7 +284,7 @@ spec:
 
-
@@ -359,7 +359,7 @@ spec:
 
-
@@ -472,7 +472,7 @@ spec:
 
-
-
-
diff --git a/docs/cce/umn/cce_bestpractice_0310.html b/docs/cce/umn/cce_bestpractice_0310.html
index 6ed4b549..5e51485f 100644
--- a/docs/cce/umn/cce_bestpractice_0310.html
+++ b/docs/cce/umn/cce_bestpractice_0310.html
@@ -3,7 +3,7 @@
 
                                                          Installing the Migration Tool
                                                          Velero is an open-source backup and migration tool for Kubernetes clusters. It integrates the persistent volume (PV) data backup capability of the Restic tool and can be used to back up Kubernetes resource objects (such as Deployments, jobs, Services, and ConfigMaps) in the source cluster. Data in the PV mounted to the pod is backed up and uploaded to the object storage. When a disaster occurs or migration is required, the target cluster can use Velero to obtain the corresponding backup data from OBS and restore cluster resources as required.
                                                          
 
                                                          According to Migration Solution, you need to prepare temporary object storage to store backup files before the migration. Velero supports OSB or MinIO as the object storage. OBS requires sufficient storage space for storing backup files. You can estimate the storage space based on your cluster scale and data volume. You are advised to use OBS for backup. For details about how to deploy Velero, see Installing Velero.
                                                          
-
                                                          Prerequisites
                                                          • The Kubernetes version of the source on-premises cluster must be 1.10 or later, and the cluster can use DNS and Internet services properly.
                                                          • If you use OBS to store backup files, you need to obtain the AK/SK of a user who has the right to operate OBS. For details about how to obtain the AK/SK, see Access Keys.
                                                          • If you use MinIO to store backup files, bind an EIP to the server where MinIO is installed and enable the API and console port of MinIO in the security group.
                                                          • The target CCE cluster has been created.
                                                          • The source cluster and target cluster must each have at least one idle node. It is recommended that the node specifications be 4 vCPUs and 8 GB memory or higher.
                                                          
+
                                                          Prerequisites
                                                          • The Kubernetes version of the source on-premises cluster must be 1.10 or later, and the cluster can use DNS and Internet services properly.
                                                          • If you use OBS to store backup files, you need to obtain the AK/SK of a user who has the right to operate OBS. For details, see Obtaining Access Keys (AK/SK).
                                                          • If you use MinIO to store backup files, bind an EIP to the server where MinIO is installed and enable the API and console port of MinIO in the security group.
                                                          • The target CCE cluster has been created.
                                                          • The source cluster and target cluster must each have at least one idle node. It is recommended that the node specifications be 4 vCPUs and 8 GB memory or higher.
                                                          
 
                                                          
 
                                                          Installing MinIO
                                                          MinIO is an open-source, high-performance object storage tool compatible with the S3 API protocol. If MinIO is used to store backup files for cluster migration, you need a temporary server to deploy MinIO and provide services for external systems. If you use OBS to store backup files, skip this section and go to Installing Velero.
                                                          
 
                                                          MinIO can be installed in any of the following locations:
                                                          
@@ -37,7 +37,7 @@ export MINIO_ROOT_PASSWORD=minio123
 
                                                        4. Install the Velero client.
                                                          tar -xvf velero-v1.7.0-linux-amd64.tar.gz
 cp ./velero-v1.7.0-linux-amd64/velero /usr/local/bin
                                                          
 
                                                        5. Create the access key file credentials-velero for the backup object storage.
                                                          vim credentials-velero
                                                          
-
                                                          Replace the AK/SK in the file based on the site requirements. If OBS is used, obtain the AK/SK by referring to . If MinIO is used, the AK and SK are the username and password created in 2.
                                                          [default]
+
                                                          Replace the AK/SK in the file based on the site requirements. If MinIO is used, the AK/SK are the username and password created in 2.
                                                          [default]
 aws_access_key_id = {AK}
 aws_secret_access_key = {SK}
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_0312.html b/docs/cce/umn/cce_bestpractice_0312.html
index c5971c38..514835ab 100644
--- a/docs/cce/umn/cce_bestpractice_0312.html
+++ b/docs/cce/umn/cce_bestpractice_0312.html
@@ -7,9 +7,9 @@
 
                                                        6. Run the following command to modify the workload and replace the image field in the YAML file with the image path:
                                                          kubectl edit deploy wordpress
                                                          
 
                                                        7. Check the running status of the workload.
                                                          8. 
 
                                                          
-
                                                          Updating Services
                                                          After the cluster is migrated, the Service of the source cluster may fail to take effect. You can perform the following steps to update the Service. If ingresses are configured in the source cluster, you need to connect the new cluster to ELB again after the migration. For details, see Using kubectl to Create an ELB Ingress.
                                                          
+
                                                          Updating Services
                                                          After the cluster is migrated, the Service of the source cluster may fail to take effect. You can perform the following steps to update the Service. If ingresses are configured in the source cluster, you need to connect the new cluster to ELB again after the migration. For details, see Using kubectl to Create an ELB Ingress.
                                                          
 
                                                          1. Connect to the cluster using kubectl.
                                                          2. Edit the YAML file of the corresponding Service to change the Service type and port number.
                                                            kubectl edit svc wordpress
                                                            
-
                                                            To update load balancer resources, you need to connect to ELB again. Add the annotations by following the procedure described in LoadBalancer.
                                                            annotations: 
+
                                                            To update load balancer resources, you need to connect to ELB again. Add the following annotations. For details, see LoadBalancer.
                                                            annotations: 
   kubernetes.io/elb.class: union # Shared load balancer
   kubernetes.io/elb.id: 9d06a39d-xxxx-xxxx-xxxx-c204397498a3    # Load balancer ID, which can be queried on the ELB console.
   kubernetes.io/elb.subnet-id: f86ba71c-xxxx-xxxx-xxxx-39c8a7d4bb36    # ID of the cluster where the subnet resides
diff --git a/docs/cce/umn/cce_bestpractice_0317.html b/docs/cce/umn/cce_bestpractice_0317.html
index 80c9b6ac..76eb1ea0 100644
--- a/docs/cce/umn/cce_bestpractice_0317.html
+++ b/docs/cce/umn/cce_bestpractice_0317.html
@@ -7,13 +7,13 @@
 
                                                            
 
                                                            Disabling the Automatic Token Mounting Function of the Default Service Account
                                                            By default, Kubernetes associates the default service account with every pod. That is, the token is mounted to a container. The container can use this token to pass the authentication by the kube-apiserver and kubelet components. In a cluster with RBAC disabled, the service account who owns the token has the control permissions for the entire cluster. In a cluster with RBAC enabled, the permissions of the service account who owns the token depends on the roles associated by the administrator. The service account's token is generally used by workloads that need to access kube-apiserver, such as coredns, autoscaler, and prometheus. For workloads that do not need to access kube-apiserver, you are advised to disable the automatic association between the service account and token.
                                                            
 
                                                            Two methods are available:
                                                            
-
                                                            • Method 1: Set the automountServiceAccountToken field of the service account to false. After the configuration is complete, newly created workloads will not be associated with the default service account by default. Set this field for each namespace as required.
                                                              apiVersion: v1 
+
                                                              • Method 1: Set the automountServiceAccountToken field of the service account to false. After the configuration is complete, newly created workloads will not be associated with the default service account by default. Set this field for each namespace as required.
                                                                apiVersion: v1 
 kind: ServiceAccount 
 metadata: 
   name: default 
 automountServiceAccountToken: false 
 ...
                                                                
-
                                                                When a workload needs to be associated with a service account, explicitly set the automountServiceAccountToken field to true in the YAML file of the workload.
                                                                
+
                                                                When a workload needs to be associated with a service account, explicitly set the automountServiceAccountToken field to true in the YAML file of the workload.
                                                                
 
                                                                ... 
  spec: 
    template: 
@@ -78,7 +78,7 @@ spec:
 
                                                              
 
                                                            
 
                                                            Configuring Network Isolation in a Cluster
                                                            • Container tunnel network
                                                              If networks need to be isolated between namespaces in a cluster or between workloads in the same namespace, you can configure network policies to isolate the networks. 
                                                              
-
                                                            • Cloud Native Network 2.0
                                                              In the Cloud Native Network 2.0 model, you can configure security groups to isolate networks between pods. For details, see SecurityGroups.
                                                              
+
                                                            • Cloud Native Network 2.0
                                                              In the Cloud Native Network 2.0 model, you can configure security groups to isolate networks between pods. For details, see SecurityGroup.
                                                              
 
                                                            • VPC network
                                                              Network isolation is not supported.
                                                              
 
                                                            
 
                                                            
diff --git a/docs/cce/umn/cce_bestpractice_0319.html b/docs/cce/umn/cce_bestpractice_0319.html
index 19ae5aa3..5d3b4d9b 100644
--- a/docs/cce/umn/cce_bestpractice_0319.html
+++ b/docs/cce/umn/cce_bestpractice_0319.html
@@ -68,7 +68,7 @@ spec:
 
                                                          3. Log in to each node in the CCE cluster as user root and run the following command:
                                                            • VPC network:
                                                              iptables -I OUTPUT -s {container_cidr} -d {Private API server IP} -j REJECT
                                                              
 
                                                            • Container tunnel network:
                                                              iptables -I FORWARD -s {container_cidr} -d {Private API server IP} -j REJECT
                                                              
 
                                                            
-
                                                            {container_cidr} indicates the container network of the cluster, for example, 10.0.0.0/16, and {master_ip} indicates the IP address of the master node.
                                                            
+
                                                            {container_cidr} indicates the container CIDR of the cluster, for example, 10.0.0.0/16.
                                                            
 
                                                            To ensure configuration persistence, you are advised to write the command to the /etc/rc.local script.
                                                            
 
                                                          4. Run the following command in the container to access kube-apiserver and check whether the request is intercepted:
                                                            curl -k https://{Private API server IP}:5443
                                                            
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_0321.html b/docs/cce/umn/cce_bestpractice_0321.html
new file mode 100644
index 00000000..737858fe
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0321.html
@@ -0,0 +1,19 @@
+
+
+
+  
                                                          Containerization
                                                          
+
+  
                                                          
+
                                                          
+
+
+
diff --git a/docs/cce/umn/cce_bestpractice_0324.html b/docs/cce/umn/cce_bestpractice_0324.html
index 2bbfa67a..ab18d269 100644
--- a/docs/cce/umn/cce_bestpractice_0324.html
+++ b/docs/cce/umn/cce_bestpractice_0324.html
@@ -54,7 +54,7 @@ stages:
   - package  
   - build
   - deploy
-# If no image is specified in each stage, the default image docker:latest is used.
+# If no image is specified in each stage, the default image docker:latest is used.
 image: docker:latest
 # In the package stage, only printing is performed.
 package:
@@ -86,6 +86,8 @@ deploy:
   stage: deploy
   script:
     # Configure the kubeconfig file.
+    - mkdir -p $HOME/.kube
+    - export KUBECONFIG=$HOME/.kube/config
     - echo $kube_config |base64 -d > $KUBECONFIG
     # Replace the image in the k8s.yaml file.
     - sed -i "s/<IMAGE_NAME>/swr.eu-de.otc.t-systems.com\/k8s-dev\/nginx:$CI_PIPELINE_ID/g" k8s.yaml
@@ -100,6 +102,27 @@ deploy:
 Hello Gitlab!
 
                                                          If the preceding information is displayed, the deployment is correct.
                                                          
 
                                                          
+
                                                          FAQs
                                                          If the following problems occur during the deployment:
                                                          
+
                                                          
+
                                                          or
                                                          
+
                                                          
+
                                                          Check whether the following commands are missing in the .gitlab-ci.yml file. If yes, add them to the .gitlab-ci.yml file.
                                                          
+
                                                          ...
+deploy:
+  # Use the kubectl image.
+  image: 
+    name: bitnami/kubectl:latest
+    entrypoint: [""]
+  stage: deploy
+  script:
+    # Configure the kubeconfig file.
+    - mkdir -p $HOME/.kube
+    - export KUBECONFIG=$HOME/.kube/config
+    - echo $kube_config |base64 -d > $KUBECONFIG
+    # Replace the image in the k8s.yaml file.
+...
                                                          
+
                                                          
+
                                                          
 
                                                          
 
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_0325.html b/docs/cce/umn/cce_bestpractice_0325.html
index 506ca265..7dbfe27c 100644
--- a/docs/cce/umn/cce_bestpractice_0325.html
+++ b/docs/cce/umn/cce_bestpractice_0325.html
@@ -4,10 +4,13 @@
 
                                                          Challenges
                                                          Linux allows you to create a core dump file if an application crashes, which contains the data the application had in memory at the time of the crash. You can analyze the file to locate the fault.
                                                          
 
                                                          Generally, when a service application crashes, its container exits and is reclaimed and destroyed. Therefore, container core files need to be permanently stored on the host or cloud storage. This topic describes how to configure container core dumps.
                                                          
 
                                                          
+
                                                          Notes and Constraints
                                                          When a container core dump is persistently stored to OBS (parallel file system or object bucket), the default mount option umask=0 is used. As a result, although the core dump file is generated, the core dump information cannot be written to the core file. 
                                                          
+
                                                          
 
                                                          Enabling Core Dump on a Node
                                                          Log in to the node, run the following command to enable core dump, and set the path and format for storing core files:
                                                          
 
                                                          echo "/tmp/cores/core.%h.%e.%p.%t" > /proc/sys/kernel/core_pattern
                                                          
-
                                                          Parameters:
                                                          
+
                                                          %h, %e, %p, and %t are placeholders, which are described as follows:
                                                          
 
                                                          • %h: host name (or pod name). You are advised to configure this parameter.
                                                          • %e: program file name. You are advised to configure this parameter.
                                                          • %p: (optional) process ID.
                                                          • %t: (optional) time of the core dump.
                                                          
+
                                                          After the core dump function is enabled by running the preceding command, the generated core file is named in the format of core.{Host name}.{Program file name}.{Process ID}.{Time}.
                                                          
 
                                                          You can also configure a pre-installation or post-installation script to automatically run this command when creating a node.
                                                          
 
                                                          
 
                                                          Permanently Storing Core Dumps
                                                          A core file can be stored in your host (using a hostPath volume) or cloud storage (using a PVC). The following is an example YAML file for using a hostPath volume.
                                                          apiVersion: v1
diff --git a/docs/cce/umn/cce_bestpractice_0340.html b/docs/cce/umn/cce_bestpractice_0340.html
new file mode 100644
index 00000000..bf0eca10
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0340.html
@@ -0,0 +1,33 @@
+
+
+
+  
                                                          Procedure
                                                          
+
+  
                                                          
+
                                                          
+
+
+
diff --git a/docs/cce/umn/cce_bestpractice_10000.html b/docs/cce/umn/cce_bestpractice_10000.html
new file mode 100644
index 00000000..1d7f2a2f
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_10000.html
@@ -0,0 +1,17 @@
+
+
+
                                                          Release
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_bestpractice_10001.html b/docs/cce/umn/cce_bestpractice_10001.html
new file mode 100644
index 00000000..e8a94203
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_10001.html
@@ -0,0 +1,21 @@
+
+
+
                                                          Overview
                                                          
+
                                                          Challenges
                                                          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.
                                                          
+
                                                          
+
                                                          Solutions
                                                          Several release policies are developed for service upgrade: grayscale 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.
                                                          
+
                                                          This document describes the principles and practices of grayscale release and blue-green deployment.
                                                          
+
                                                          • Grayscale release, also called canary 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. 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.
                                                            The following figure shows the general process of grayscale release. First, divide 20% of all service traffic to the new version. If the service version runs normally, gradually increase the traffic proportion and continue to test the performance of the new version. If the new version is stable, switch all traffic to it and bring the old version offline.
                                                            
+
                                                            
+
                                                            If an exception occurs in the new version when 20% of the traffic goes to the new version, you can quickly switch back to the old version.
                                                            
+
                                                            
+
                                                          • 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.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Release
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_bestpractice_10002.html b/docs/cce/umn/cce_bestpractice_10002.html
new file mode 100644
index 00000000..6820913f
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_10002.html
@@ -0,0 +1,177 @@
+
+
+
                                                          Using Services to Implement Simple Grayscale Release and Blue-Green Deployment
                                                          
+
                                                          To implement grayscale release for a CCE cluster, you need to deploy other open-source tools, such as Nginx Ingress, to the cluster or deploy services to a service mesh. These solutions are difficult to implement. If your grayscale release requirements are simple and you do not want to introduce too many plug-ins or complex configurations, you can refer to this section to implement simple grayscale release and blue-green deployment based on native Kubernetes features.
                                                          
+
                                                          Principles
                                                          Users usually use Kubernetes objects such as Deployments and StatefulSets to deploy services. Each workload manages a group of pods. The following figure uses Deployment as an example.
                                                          
+
                                                          
+
                                                          Generally, a Service is created for each workload. The Service uses the selector to match the backend pod. Other Services or objects outside the cluster can access the pods backing the Service. If a pod needs to be exposed, set the Service type to LoadBalancer. The ELB load balancer functions as the traffic entrance.
                                                          
+
                                                          • Grayscale release principles
                                                            Take a Deployment as an example. A Service, in most cases, will be created for each Deployment. However, Kubernetes does not require that Services and Deployments correspond to each other. A Service uses a selector to match backend pods. If pods of different Deployments are selected by the same selector, a Service corresponds to multiple versions of Deployments. You can adjust the number of replicas of Deployments of different versions to adjust the weights of services of different versions to achieve grayscale release. The following figure shows the process:
                                                            
+
                                                            
+
                                                          • Blue-green deployment principles
                                                            Take a Deployment as an example. Two Deployments of different versions have been deployed in the cluster, and their pods are labeled with the same key but different values to distinguish versions. A Service uses the selector to select the pod of a Deployment of a version. In this case, you can change the value of the label that determines the version in the Service selector to change the pod backing the Service. In this way, you can directly switch the service traffic from one version to another. The following figure shows the process:
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          Prerequisites
                                                          The Nginx image has been uploaded to SWR. The Nginx images have two versions: v1 and v2. The welcome pages are Nginx-v1 and Nginx-v2.
                                                          
+
                                                          
+
                                                          Resource Creation
                                                          You can use YAML to deploy Deployments and Services in either of the following ways:
                                                          
+
                                                          • On the Create Deployment page, click Create YAML on the right and edit the YAML file in the window.
                                                          • Save the sample YAML file in this section as a file and use kubectl to specify the YAML file. For example, run the kubectl create -f xxx.yaml command.
                                                          
+
                                                          
+
                                                          Step 1: Deploy Services of Two Versions
                                                          Two versions of Nginx services are deployed in the cluster to provide external access through ELB.
                                                          
+
                                                          1. Create a Deployment of the first version. The following uses nginx-v1 as an example. Example YAML:
                                                            apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-v1
+spec:
+  replicas: 2               # Number of replicas of the Deployment, that is, the number of pods
+  selector:                 # Label selector
+    matchLabels:
+      app: nginx
+      version: v1
+  template:
+    metadata:
+      labels:               # Pod label
+        app: nginx
+        version: v1
+    spec:
+      containers:
+      - image: {your_repository}/nginx:v1 # The image used by the container is nginx:v1.
+        name: container-0
+        resources:
+          limits:
+            cpu: 100m
+            memory: 200Mi
+          requests:
+            cpu: 100m
+            memory: 200Mi
+      imagePullSecrets:
+      - name: default-secret
                                                            
+
                                                          2. Create a Deployment of the second version. The following uses nginx-v2 as an example. Example YAML:
                                                            apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-v2
+spec:
+  replicas: 2               # Number of replicas of the Deployment, that is, the number of pods
+  selector:                 # Label selector
+    matchLabels:
+      app: nginx
+      version: v2
+  template:
+    metadata:
+      labels:               # Pod label
+        app: nginx
+        version: v2
+    spec:
+      containers:
+      - image: {your_repository}/nginx:v2   # The image used by the container is nginx:v2.
+        name: container-0
+        resources:
+          limits:
+            cpu: 100m
+            memory: 200Mi
+          requests:
+            cpu: 100m
+            memory: 200Mi
+      imagePullSecrets:
+      - name: default-secret
                                                            
+
                                                            You can log in to the CCE console to view the deployment status.
                                                            
+
                                                          
+
                                                          
+
                                                          Step 2: Implement Grayscale Release
                                                          1. Create a LoadBalancer Service for the Deployment. Do not specify the version in the selector. Enable the Service to select the pods of the Deployments of two versions. Example YAML:
                                                            apiVersion: v1
+kind: Service
+metadata:
+  annotations:
+    kubernetes.io/elb.id: 586c97da-a47c-467c-a615-bd25a20de39c    # ID of the ELB load balancer. Replace it with the actual value.
+  name: nginx
+spec: 
+  ports:
+  - name: service0
+    port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:             # The selector does not contain version information.
+    app: nginx
+   type: LoadBalancer   # Service type (LoadBalancer)
                                                            
+
                                                          2. Run the following command to test the access:
                                                            for i in {1..10}; do curl <EXTERNAL_IP>; done;
                                                            
+
                                                            <EXTERNAL_IP> indicates the IP address of the ELB load balancer.
                                                            
+
                                                            The command output is as follows. Half of the responses are from the Deployment of version v1, and the other half are from version v2.
                                                            
+
                                                            Nginx-v2
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v2
+Nginx-v1
+Nginx-v2
+Nginx-v1
+Nginx-v2
+Nginx-v2
                                                            
+
                                                          3. Use the console or kubectl to adjust the number of replicas of the Deployments. Change the number of replicas to 4 for v1 and 1 for v2.
                                                            kubectl scale deployment/nginx-v1 --replicas=4
                                                            
+
                                                            kubectl scale deployment/nginx-v2 --replicas=1
                                                            
+
                                                          4. Run the following command to test the access again:
                                                            for i in {1..10}; do curl <EXTERNAL_IP>; done;
                                                            
+
                                                            <EXTERNAL_IP> indicates the IP address of the ELB load balancer.
                                                            
+
                                                            In the command output, among the 10 access requests, only two responses are from the v2 version. The response ratio of the v1 and v2 versions is the same as the ratio of the number of replicas of the v1 and v2 versions, that is, 4:1. Grayscale release is implemented by controlling the number of replicas of services of different versions.
                                                            
+
                                                            Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v2
+Nginx-v1
+Nginx-v2
+Nginx-v1
+Nginx-v1
+Nginx-v1
                                                            
+
                                                             
                                                            If the ratio of v1 to v2 is not 4:1, you can set the number of access times to a larger value, for example, 20. Theoretically, the more the times, the closer the response ratio between v1 and v2 is to 4:1.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          Step 3: Implement Blue-Green Deployment
                                                          1. Create a LoadBalancer Service for a deployed Deployment and specify that the v1 version is used. Example YAML:
                                                            apiVersion: v1
+kind: Service
+metadata:
+  annotations:
+    kubernetes.io/elb.id: 586c97da-a47c-467c-a615-bd25a20de39c    # ID of the ELB load balancer. Replace it with the actual value.
+  name: nginx
+spec:
+  ports:
+  - name: service0
+    port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:             # Set the version to v1 in the selector.
+    app: nginx
+    version: v1
+  type: LoadBalancer    # Service type (LoadBalancer)
                                                            
+
                                                          2. Run the following command to test the access:
                                                            for i in {1..10}; do curl <EXTERNAL_IP>; done;
                                                            
+
                                                            <EXTERNAL_IP> indicates the IP address of the ELB load balancer.
                                                            
+
                                                            The command output is as follows (all responses are from the v1 version):
                                                            
+
                                                            Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
+Nginx-v1
                                                            
+
                                                          3. Use the console or kubectl to modify the selector of the Service so that the v2 version is selected.
                                                            kubectl patch service nginx -p '{"spec":{"selector":{"version":"v2"}}}'
                                                            
+
                                                          4. Run the following command to test the access again:
                                                            for i in {1..10}; do curl <EXTERNAL_IP>; done;
                                                            
+
                                                            <EXTERNAL_IP> indicates the IP address of the ELB load balancer.
                                                            
+
                                                            The returned results show that are all responses are from the v2 version. The blue-green deployment is successfully implemented.
                                                            
+
                                                            Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
+Nginx-v2
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Release
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_bestpractice_10008.html b/docs/cce/umn/cce_bestpractice_10008.html
new file mode 100644
index 00000000..c6c44888
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_10008.html
@@ -0,0 +1,16 @@
+
+
+
                                                          Monitoring
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_bestpractice_10009.html b/docs/cce/umn/cce_bestpractice_10009.html
new file mode 100644
index 00000000..79fde1f9
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_10009.html
@@ -0,0 +1,143 @@
+
+
+
                                                          Using Prometheus for Multi-cluster Monitoring
                                                          
+
                                                          Scenario
                                                          Generally, a user has different clusters for different purposes, such as production, testing, and development. To monitor, collect, and view metrics of these clusters, you can deploy a set of Prometheus.
                                                          
+
                                                          
+
                                                          Solution Architecture
                                                          Multiple clusters are connected to the same Prometheus monitoring system, as shown in the following figure. This reduces maintenance and resource costs and facilitates monitoring information aggregation.
                                                          
+
                                                          
+
                                                          
+
                                                          Prerequisites
                                                          • The target cluster has been created.
                                                          • Prometheus is properly connected to the target cluster.
                                                          • Prometheus has been installed on a Linux host using a binary file. For details, see Installation.
                                                          
+
                                                          
+
                                                          Procedure
                                                          1. Obtain the bear_token information of the target cluster.
                                                            1. Create the RBAC permission in the target cluster.
                                                              Log in to the background node of the target cluster and create the prometheus_rbac.yaml file.
                                                              apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: prometheus-test
+  namespace: kube-system
+
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: prometheus-test
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - nodes
+  - services
+  - endpoints
+  - pods
+  - nodes/proxy
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - "extensions"
+  resources:
+    - ingresses
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - ""
+  resources:
+  - configmaps
+  - nodes/metrics
+  verbs:
+  - get
+- nonResourceURLs:
+  - /metrics
+  verbs:
+  - get
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: prometheus-test
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: prometheus-test
+subjects:
+- kind: ServiceAccount
+  name: prometheus-test
+  namespace: kube-system
                                                              
+
                                                              
+
                                                              Run the following command to create the RBAC permission:
                                                              
+
                                                              kubectl apply -f prometheus_rbac.yaml
                                                              
+
                                                            2. Obtain the bearer_token information of the target cluster.
                                                               
                                                              • In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25.
                                                                In clusters of version 1.21 or later, you can use the TokenRequest API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period. When the mounting pod is deleted, the token automatically becomes invalid. .
                                                                
+
                                                              • If you need a token that never expires, you can also manually manage secrets for service accounts. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the TokenRequest API for higher security.
                                                              
+
                                                              
+
                                                              Obtain the serviceaccount information.
                                                              
+
                                                              kubectl describe sa prometheus-test -n kube-system
                                                              
+
                                                              
+
                                                              kubectl describe secret prometheus-test-token-hdhkg -n kube-system
                                                              
+
                                                              
+
                                                              Record the token value, which is the bearer_token information to be collected.
                                                              
+
                                                            
+
                                                          2. Configure bearer_token information.
                                                            Log in to the host where Prometheus is located, go to the Prometheus installation directory, and save the token information of the target cluster in a file.
                                                            
+
                                                            
+
                                                          3. Configure Prometheus to monitor jobs.
                                                            The example job monitors container metrics. If you need to monitor other metrics, you can add jobs and compile capture rules.
                                                            
+
                                                              - job_name: k8s_cAdvisor
+    scheme: https
+    bearer_token_file: k8s_token # Token file in the previous step.
+    tls_config:
+      insecure_skip_verify: true
+    kubernetes_sd_configs:  # kubernetes automatic discovery configuration
+    - role: node    # Automatic discovery of the node type
+      bearer_token_file: k8s_token # Token file in the previous step
+      api_server: https://192.168.0.153:5443  # The API server address of the Kubernetes cluster
+      tls_config:
+        insecure_skip_verify: true   # Skip the authentication on the server.
+    relabel_configs:  ## Modify the existing label of the target cluster before capturing metrics.
+    - target_label: __address__
+      replacement: 192.168.0.153:5443
+      action: replace
+      ## Convert metrics_path to /api/v1/nodes/${1}/proxy/metrics/cadvisor.
+      # Obtain data from kubelet using the API Server proxy.
+    - source_labels: [__meta_kubernetes_node_name]   # Specifies the source label to be processed.
+      regex: (.+)    # Match the value of the source label. (.+) indicates that any value of the source label can be matched.
+      target_label: __metrics_path__     # specifies the label to be replaced.
+      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor  # indicates the new label, that is, the value of __metrics_path__. ${1} indicates the value that matches the regular expression, that is, node name.
+    - target_label: cluster
+      replacement: xxxxx   ## (Optional) Enter the cluster information based on the actual situation.
+
+### The following job monitors another cluster.
+  - job_name: k8s02_cAdvisor
+    scheme: https
+    bearer_token_file: k8s02_token # Token file in the previous step
+    tls_config:
+      insecure_skip_verify: true
+    kubernetes_sd_configs: 
+    - role: node    
+      bearer_token_file: k8s02_token # Token file in the previous step
+      api_server: https://192.168.0.147:5443  # API Server address of the Kubernetes cluster
+      tls_config:
+        insecure_skip_verify: true   # Skip the authentication on the server.
+    relabel_configs:  ## Modify the existing label of the target cluster before capturing metrics.
+    - target_label: __address__
+      replacement: 192.168.0.147:5443
+      action: replace
+
+    - source_labels: [__meta_kubernetes_node_name]
+      regex: (.+)
+      target_label: __metrics_path__
+      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
+
+    - target_label: cluster
+      replacement: xxxx    ## (Optional) Enter the cluster information based on the actual situation.
                                                            
+
                                                          4. Enable Prometheus.
                                                            After the configuration, enable Prometheus.
                                                            
+
                                                            ./prometheus --config.file=prometheus.yml
                                                            
+
                                                          5. Log in to Prometheus and view the monitoring information.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Monitoring
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_bestpractice_10012.html b/docs/cce/umn/cce_bestpractice_10012.html
new file mode 100644
index 00000000..b8c887c9
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_10012.html
@@ -0,0 +1,83 @@
+
+
+
                                                          Selecting a Data Disk for the Node
                                                          
+
                                                          When a node is created, a data disk is created by default for container runtime and kubelet components to use.  The data disk used by the container runtime and kubelet components cannot be detached, and the default size is 100 GB. To reduce costs, the size of a common data disk attached to a node can be reduced to 10 GB.
                                                          
+
                                                           
                                                          Adjusting the size of the data disk used by the container and Kubelet component may cause risks. You are advised to adjust the size after comprehensive evaluation based on the estimation method provided in this section.
                                                          
+
                                                          • If the data disk capacity is too small, the disk space may be insufficient. As a result, the image fails to be pulled. If different images need to be frequently pulled on the node, you are not advised to reduce the data disk capacity.
                                                          • During the cluster upgrade pre-check, the system checks whether the data disk usage exceeds 95%. If the disk pressure is high, the cluster upgrade may be affected.
                                                          • If Device Mapper is used, the disk space may be insufficient. You are advised to use the OverlayFS or select a large-capacity data disk.
                                                          • For dumping logs, application logs must be stored in a separate disk to prevent insufficient space of the dockersys partition from affecting service running.
                                                          
+
+
                                                          
+
                                                          Notes and Constraints
                                                          • Only clusters of v1.19 or later support reducing the data disk capacity used by running containers and kubelet components.
                                                          • Only the EVS disk capacity can be adjusted. (Local disks are available only when the node specification is disk-intensive or Ultra-high I/O.)
                                                          
+
                                                          
+
                                                          Selecting a Data Disk
                                                          When selecting a proper data disk, consider the following factors:
                                                          
+
                                                          • During image pulling, the system downloads the image .tar package from the image repository, decompresses the package, and deletes the TAR package to retain the image file. During the decompression of the .tar package, the .tar package and the decompressed image file coexist, occupying extra storage space. Pay attention to this when calculating the required data disk capacity.
                                                          • During cluster creation, mandatory add-ons (such as everest and coredns add-ons) may be deployed on nodes, occupying certain space. When calculating the data disk size, reserve about 2 GB space for them.
                                                          • Logs are generated during application running and occupy certain space. To ensure normal service running, reserve about 1 GB space for each pod.
                                                          
+
                                                          For details about the calculation formulas, see OverlayFS and Device Mapper.
                                                          
+
                                                          
+
                                                          OverlayFS
                                                          By default, the container engine and container image space on OverlayFS nodes occupy 90% of the data disk space (you are advised to retain this value). All the space is used for the dockersys partition. The calculation formula is as follows:
                                                          
+
                                                          • Container engine and container image space: Defaults to 90%. Space size = Data disk space x 90%
                                                            • dockersys partition (/var/lib/docker path): The entire container engine and container image space (90% of the data disk by default) are in the /var/lib/docker directory. Space size = Data disk space x 90%
                                                            
+
                                                          • kubelet components and emptyDir volumes space: 10% of the data disk space. Space size = Data disk space x 10%
                                                          
+
                                                          On an OverlayFS node, when an image is pulled, the .tar package is decompressed after being downloaded. During this process, the .tar package and the decompressed image file are stored in the dockersys space at the same time, occupying about twice the actual image capacity, after the decompression is complete, the .tar package is deleted. Therefore, in the actual image pulling process, after deducting the space occupied by the system add-on image, ensure that the remaining space of the dockersys partition is greater than twice the actual image capacity. To ensure that the container can run properly, you need to reserve pod space in the dockersys partition for container logs and other related files.
                                                          
+
                                                          A proper data disk should meet the following formula:
                                                          
+
                                                          dockersys partition capacity > 2 x Actual total image capacity + Total system add-on image capacity (about 2 GB) + Number of containers x Available space for a single container (about 1 GB log space)
                                                          
+
                                                           
                                                          If container logs are output in the json.log format, the dockersys partition is occupied. If persistent storage is configured for container logs, the dockersys partition is not occupied. Estimate the space of a single container as required.
                                                          
+
                                                          
+
                                                          Example:
                                                          
+
                                                          Assume that the storage type of the node is OverlayFS and the data disk size of the node is 20 GB. According to the preceding formula, the default ratio of the container engine and image space is 90%. Therefore, the dockersys partition disk usage is 18 GB (20 GB x 90%). In addition, mandatory add-ons may occupy about 2 GB space during cluster creation. If you deploy a .tar image package of 10 GB, 20 GB dockersys space is occupied by the decompressed package. In addition, the space occupied by mandatory add-ons exceeds the remaining space of dockersys. As a result, the image may fail to be pulled.
                                                          
+
                                                          
+
                                                          Device Mapper
                                                          By default, the container engine and image space on Device Mapper nodes occupy 90% of the data disk space (recommended). This 90% capacity is divided into the dockersys partition and thinpool space. The calculation formula is as follows:
                                                          
+
                                                          • Container engine and image space: 90% of the data disk space by default. Space size = Data disk space x 90%
                                                            • dockersys partition (/var/lib/docker path): Defaults to 20%. Space size = Data disk space x 90% x 20%
                                                            • thinpool space: Defaults to 80%. Space size = Data disk space x 90% x 80%
                                                            
+
                                                          • kubelet and emptyDir space: occupy 10%. Space size = Data disk space x 10%
                                                          
+
                                                          On a Device Mapper node, when an image is pulled, the TAR package is temporarily stored in the dockersys partition. After the TAR package is decompressed, the image file is stored in the thinpool space. Finally, the TAR package in the dockersys space is deleted. Therefore, during image pulling, ensure that the dockersys partition space and thinpool space are sufficient. The dockersys space is smaller than the thinpool space. Pay attention to this when calculating the data disk space. To ensure that a container can run properly, reserve pod space in the dockersys partition to store container logs and other related files.
                                                          
+
                                                          A proper data disk should meet the following formula:
                                                          • dockersys partition capacity > temporary storage space of the TAR package (approximately equal to the actual total image capacity) + Number of containers x Space of a single container (about 1 GB log space must be reserved for each container)
                                                          • thinpool space > Actual total image capacity + Total add-on image capacity (about 2 GB)
                                                          
+
                                                          
+
                                                           
                                                          If container logs are output in the json.log format, the dockersys partition is occupied. If persistent storage is configured for container logs, the dockersys partition is not occupied. Estimate the space of a single container as required.
                                                          
+
                                                          
+
                                                          Example:
                                                          
+
                                                          Assume that the storage type of the node is Device Mapper and the data disk size of the node is 20 GB. According to the preceding formula, the default ratio of the container engine and image space is 90%. Therefore, the dockersys partition disk usage is: 20 GB x 90% x 20% = 3.6 GB. In addition, mandatory add-ons may occupy about 2 GB dockersys space during cluster creation. Therefore, the remaining space is about 1.6 GB. If you deploy a .tar image package larger than 1.6 GB, the dockersys partition space is insufficient when the package is decompressed. As a result, the image may fail to be pulled.
                                                          
+
                                                          
+
                                                          What Do I Do If the Data Disk Space Is Insufficient?
                                                          Solution 1: Clearing Images
                                                          
+
                                                          You can run the following command to clear unused Docker images:
                                                          
+
                                                          docker system prune -a
                                                          
+
                                                           
                                                          This command will delete all Docker images that are not used. Exercise caution when running this command.
                                                          
+
                                                          
+
                                                          Solution 2: Expanding the Disk Capacity
                                                          
+
                                                          1. Expand the capacity of the data disk on the EVS console.
                                                          2. Log in to the CCE console and click the cluster. In the navigation pane, choose Nodes. Click More > Sync Server Data at the row containing the target node.
                                                          3. Log in to the target node.
                                                          4. Run the lsblk command to check the block device information of the node.
                                                            A data disk is divided depending on the container storage Rootfs:
                                                            
+
                                                            • Overlayfs: No independent thin pool is allocated. Image data is stored in the dockersys disk.
                                                              # lsblk
+NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
+sda                   8:0    0   50G  0 disk 
+└─sda1                8:1    0   50G  0 part /
+sdb                   8:16   0  200G  0 disk 
+├─vgpaas-dockersys  253:0    0   90G  0 lvm  /var/lib/docker               # Space used by Docker.
+└─vgpaas-kubernetes 253:1    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet  # Space used by Kubernetes.
                                                              
+
                                                              Run the following commands on the node to add the new disk capacity to the dockersys disk:
                                                              
+
                                                              pvresize /dev/sdb 
+lvextend -l+100%FREE -n vgpaas/dockersys
+resize2fs /dev/vgpaas/dockersys
                                                              
+
                                                            • Devicemapper: A thin pool is allocated to store image data.
                                                              # lsblk
+NAME                                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
+sda                                   8:0    0   50G  0 disk 
+└─sda1                                8:1    0   50G  0 part /
+sdb                                   8:16   0  200G  0 disk 
+├─vgpaas-dockersys                  253:0    0   18G  0 lvm  /var/lib/docker    
+├─vgpaas-thinpool_tmeta             253:1    0    3G  0 lvm                   
+│ └─vgpaas-thinpool                 253:3    0   67G  0 lvm                   # Thin pool space.
+│   ...
+├─vgpaas-thinpool_tdata             253:2    0   67G  0 lvm  
+│ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
+│   ...
+└─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet
                                                              
+
                                                              • Run the following commands on the node to add the new disk capacity to the thinpool disk:
                                                                pvresize /dev/sdb 
+lvextend -l+100%FREE -n vgpaas/thinpool
                                                                
+
                                                              • Run the following commands on the node to add the new disk capacity to the dockersys disk:
                                                                pvresize /dev/sdb 
+lvextend -l+100%FREE -n vgpaas/dockersys
+resize2fs /dev/vgpaas/dockersys
                                                                
+
                                                              
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Cluster
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_bulletin_0000.html b/docs/cce/umn/cce_bulletin_0000.html
index 003398f0..0cbf0885 100644
--- a/docs/cce/umn/cce_bulletin_0000.html
+++ b/docs/cce/umn/cce_bulletin_0000.html
@@ -4,8 +4,6 @@
 
                                                          
 
 
diff --git a/docs/cce/umn/cce_bulletin_0054.html b/docs/cce/umn/cce_bulletin_0054.html
deleted file mode 100644
index bff99bbd..00000000
--- a/docs/cce/umn/cce_bulletin_0054.html
+++ /dev/null
@@ -1,78 +0,0 @@
-
-
-
                                                          Risky Operations on Cluster Nodes
                                                          
-
                                                          Precautions for Using a Cluster
                                                          • When performing operations such as creating, deleting, and scaling clusters, do not change user permission in the Identity and Access Management (IAM) console. Otherwise, these operations may fail.
                                                          • The containerized network canal of CCE nodes uses a CIDR block as the CIDR block of the container network. This CIDR block can be configured during cluster creation and defaults to 172.16.0.0/16. The Docker service creates a docker0 bridge by default. The default docker0 address is 172.17.0.1. When creating a cluster, ensure that the CIDR block of the VPC in the cluster is different from the CIDR blocks of the container network docker0 bridge. If VPC peering connections are used, also ensure that the CIDR block of the peer VPC is different from the CIDR blocks of the container network docker0 bridge.
                                                          • For a cluster of Kubernetes v1.15, the DNS server of nodes in the cluster uses the DNS address in the VPC subnet, not the CoreDNS address of Kubernetes. Ensure that the DNS address in the subnet exists and is configurable.
                                                          • For a cluster of Kubernetes v1.17, a single-plane network is used for nodes. When a multi-plane network is used, if you bind a NIC to an ECS, you need to configure the NIC information on the node and restart the NIC.
                                                          • Do not modify the security groups, Elastic Volume Service (EVS) disks, and other resources created by CCE. Otherwise, clusters may not function properly. The resources created by CCE are labeled cce, for example, cce-evs-jwh9pcl7-****.
                                                          • When adding a node, ensure that the DNS server in the subnet can resolve the domain name of the corresponding service. Otherwise, the node cannot be installed properly.
                                                          
-
                                                          
-
                                                          Precautions for Using a Node
                                                          Some of the resources on the node need to run some necessary Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node resources and the number of assignable node resources in Kubernetes are different. The larger the node specifications, the more the containers deployed on the node. Therefore, Kubernetes needs to reserve more resources.
                                                          
-
                                                          To ensure node stability, CCE cluster nodes reserve some resources for Kubernetes components (such as kubelet, kube-proxy, and docker) based on node specifications.
                                                          
-
                                                           
                                                          You are advised not to install software or modify the operating system (OS) configuration on a cluster node. This may cause exceptions on Kubernetes components installed on the node, and make the node unavailable.
                                                          
-
                                                          
-
                                                          
-
                                                          Risky Operations on Nodes
                                                          After logging in to a node created by CCE, do not perform the following operations. Otherwise, the node will become unready.
                                                          
-
                                                          
-
-
                                                          Table 4 Setting parameters for mounting a secret volume
                                                          Parameter
                                                          
+
                                                          
-
-
-
-
-
-
-
@@ -185,20 +185,20 @@ spec:
         hostPath: 
           path: /tmp/test
 
-
                                                          Table 4 Setting parameters for mounting a secret volume
                                                          Parameter
                                                          
 
                                                          Description
                                                          
+
                                                          Description
                                                          
                                                           		
 
                                                          
 
                                                          Storage Type
                                                          
+
                                                          Storage Type
                                                          
 
                                                          Select Secret.
                                                          
+
                                                          Select Secret.
                                                          
                                                           		
 
                                                          Secret
                                                          
+
                                                          Secret
                                                          
 
                                                          Select the desired secret name.
                                                          
+
                                                          Select the desired secret name.
                                                          
 
                                                          A secret must be created in advance. For details, see Creating a Secret.
                                                          
                                                           		
 
                                                          Add Container Path
                                                          
+
                                                          Add Container Path
                                                          
 
                                                          Configure the following parameters:
                                                          
-
                                                          1. subPath: Enter a subpath, for example, tmp.
                                                            • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
                                                            • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
                                                            • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
                                                            
-
                                                          2. Container Path: Enter the path of the container, for example, /tmp.
                                                            This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
                                                             NOTICE: 
                                                            When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
                                                            
+
                                                          Configure the following parameters:
                                                          
+
                                                          1. subPath: Enter a subpath, for example, tmp.
                                                            • A subpath is used to mount a local volume so that the same data volume is used in a single pod.
                                                            • The subpath can be the key and value of a ConfigMap or secret. If the subpath is a key-value pair that does not exist, the data import does not take effect.
                                                            • The data imported by specifying a subpath will not be updated along with the ConfigMap/secret updates.
                                                            
+
                                                          2. Container Path: Enter the path of the container, for example, /tmp.
                                                            This parameter indicates the container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run; this action may cause container errors. You are advised to mount the container to an empty directory. If the directory is not empty, ensure that there are no files affecting container startup in the directory. Otherwise, such files will be replaced, resulting in failures to start the container and create the workload.
                                                             NOTICE: 
                                                            When the container is mounted to a high-risk directory, you are advised to use an account with minimum permissions to start the container; otherwise, high-risk files on the host machine may be damaged.
                                                            
 
                                                            
 
                                                            
 
                                                          3. Set the permission to Read-only. Data volumes in the path are read-only.
                                                          
-
                                                          You can click  to add multiple paths and subpaths.
                                                          
+
                                                          You can click  to add multiple paths and subpaths.
                                                          
                                                           		
 
                                                          
 
                                                          
@@ -149,127 +149,127 @@
 
                                                          Table 5 Local disk storage dependency parameters
                                                          Parameter
                                                          
+
                                                          
-
-
-
-
-
diff --git a/docs/cce/umn/cce_10_0378.html b/docs/cce/umn/cce_10_0378.html
index b15c9794..29138377 100644
--- a/docs/cce/umn/cce_10_0378.html
+++ b/docs/cce/umn/cce_10_0378.html
@@ -118,7 +118,7 @@
 
                                                          Using a Storage Class to Create a PVC
                                                          StorageClass describes the storage class used in the cluster. You need to specify StorageClass to dynamically create PVs and underlying storage resources when creating a PVC.
                                                          
 
                                                          Using the CCE Console
                                                          
 
                                                          1. Log in to the CCE console.
                                                          2. Click the cluster name and go to the cluster console. Choose Storage from the navigation pane, and click the PersistentVolumeClaims (PVCs) tab.
                                                          3. Click Create PVC in the upper right corner. In the dialog box displayed, set the PVC parameters.
                                                            • Storage Volume Claim Type: Select a storage type as required.
                                                            • PVC Name: Enter a PVC name.
                                                            • Creation Method: Select Dynamic creation.
                                                            • Storage Classes: Select the required storage class. The following storage resources can be dynamically provisioned:
                                                              • csi-disk: EVS disk.
                                                              • csi-nas: SFS Capacity-Oriented file storage.
                                                              • csi-obs: OBS bucket.
                                                              
-
                                                            • AZ (supported only by EVS): Select the AZ where the EVS disk is located.
                                                            • Disk Type (supported only by EVS disks): Select an EVS disk type as required. EVS disk types vary in different regions.
                                                              • Common I/O
                                                              • High I/O
                                                              • Ultra-high I/O
                                                              
+
                                                            • AZ (supported only by EVS): Select the AZ where the EVS disk is located.
                                                            • Disk Type (supported only by EVS disks): Select an EVS disk type as required. EVS disk types vary in different regions.
                                                              • Common I/O
                                                              • High I/O
                                                              • Ultra-high I/O
                                                              
 
                                                            • Access Mode: ReadWriteOnce and ReadWriteMany are supported. For details, see Volume Access Modes.
                                                            • Capacity (GiB) (only EVS and SFS are supported): storage capacity. This parameter is not available for OBS.
                                                            • Encryption (supported only for EVS and SFS): Select Encryption. After selecting this option, you need to select a key.
                                                            • Secret (supported only for OBS): Select an access key for OBS. For details, see Using a Custom AK/SK to Mount an OBS Volume.
                                                            
 
                                                          4. Click Create.
                                                          
 
                                                          Using YAML
                                                          
@@ -184,10 +184,10 @@ spec:
 
                                                          Using the CCE Console
                                                          
 
                                                          1. Log in to the CCE console.
                                                          2. Click the cluster name and go to the cluster console. Choose Storage from the navigation pane, and click the PersistentVolumeClaims (PVCs) tab.
                                                          3. Click Create PVC in the upper right corner. In the dialog box displayed, set the PVC parameters.
                                                            • Storage Volume Claim Type: Select a storage type as required.
                                                            • PVC Name: name of a PVC.
                                                            • Creation Method: Select Existing storage volume.
                                                            • PV: Select the volume to be associated, that is, the PV.
                                                            
 
                                                          4. Click Create.
                                                          
-
                                                          Using YAML
                                                          
+
                                                          Using YAML
                                                          
 
                                                          Example YAML for EVS
                                                          
-
                                                          • failure-domain.beta.kubernetes.io/region: region where the cluster is located.
                                                            For details about the value of region, see Regions and Endpoints.
                                                            
-
                                                          • failure-domain.beta.kubernetes.io/zone: AZ where the EVS volume is created. It must be the same as the AZ planned for the workload. 
                                                            For details about the value of zone, see Regions and Endpoints.
                                                            
+
                                                            • failure-domain.beta.kubernetes.io/region: region where the cluster is located.
                                                              For details about the value of region, see Regions and Endpoints.
                                                              
+
                                                            • failure-domain.beta.kubernetes.io/zone: AZ where the EVS volume is created. It must be the same as the AZ planned for the workload. 
                                                              For details about the value of zone, see Regions and Endpoints.
                                                              
 
                                                            
 
                                                            apiVersion: v1
 kind: PersistentVolumeClaim
@@ -264,11 +264,11 @@ spec:
   volumeName: pv-sfsturbo-test         # PV name.
                                                            
 
                                                          
-
                                                          Using a Snapshot to Creating a PVC
                                                          The disk type, encryption setting, and disk mode of the created EVS PVC are consistent with those of the snapshot's source EVS disk.
                                                          
-
                                                          Using the CCE Console
                                                          
-
                                                          1. Log in to the CCE console.
                                                          2. Click the cluster name and go to the cluster console. Choose Storage from the navigation pane, and click the Snapshots and Backups tab.
                                                          3. Locate the snapshot for which you want to create a PVC, click Create PVC, and specify the PVC name in the displayed dialog box.
                                                          4. Click Create.
                                                          
-
                                                          Creating from YAML
                                                          
-
                                                          apiVersion: v1
+
                                                          Using a Snapshot to Creating a PVC
                                                          The disk type, encryption setting, and disk mode of the created EVS PVC are consistent with those of the snapshot's source EVS disk.
                                                          
+
                                                          Using the CCE Console
                                                          
+
                                                          1. Log in to the CCE console.
                                                          2. Click the cluster name and go to the cluster console. Choose Storage from the navigation pane, and click the Snapshots and Backups tab.
                                                          3. Locate the snapshot that you want to use for creating a PVC, click Create PVC, and specify the PVC name in the displayed dialog box.
                                                          4. Click Create.
                                                          
+
                                                          Creating from YAML
                                                          
+
                                                          apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: pvc-test
@@ -276,7 +276,7 @@ metadata:
   annotations:
     everest.io/disk-volume-type: SSD     # EVS disk type, which must be the same as that of the source EVS disk of the snapshot.
   labels:
-    failure-domain.beta.kubernetes.io/region: eu-de
+    failure-domain.beta.kubernetes.io/region: eu-de
     failure-domain.beta.kubernetes.io/zone: 
 spec:
   accessModes:
diff --git a/docs/cce/umn/cce_10_0379.html b/docs/cce/umn/cce_10_0379.html
index 6da88d0d..47858f2c 100644
--- a/docs/cce/umn/cce_10_0379.html
+++ b/docs/cce/umn/cce_10_0379.html
@@ -133,7 +133,7 @@ spec:
 
                                                          
@@ -217,7 +217,7 @@ spec:
 
@@ -292,7 +292,7 @@ spec:
 
@@ -380,7 +380,7 @@ spec:
 
diff --git a/docs/cce/umn/cce_10_0380.html b/docs/cce/umn/cce_10_0380.html
index 857d6b61..c368928f 100644
--- a/docs/cce/umn/cce_10_0380.html
+++ b/docs/cce/umn/cce_10_0380.html
@@ -10,8 +10,8 @@ csi-nas             everest-csi-provisioner         17d          # Storage class
 csi-obs             everest-csi-provisioner         17d          # Storage class for OBS buckets
                                                          After a StorageClass is set, PVs can be automatically created and maintained. You only need to specify the StorageClass when creating a PVC, which greatly reduces the workload.
                                                          In addition to the predefined storage classes provided by CCE, you can also customize storage classes. The following sections describe the application status, solutions, and methods of customizing storage classes.
                                                          
-
                                                          Challenges
                                                          When using storage resources in CCE, the most common method is to specify storageClassName to define the type of storage resources to be created when creating a PVC. The following configuration shows how to use a PVC to apply for an SAS (high I/O) EVS disk (block storage).
                                                          
-
                                                          apiVersion: v1
+
                                                          Challenges
                                                          When using storage resources in CCE, the most common method is to specify storageClassName to define the type of storage resources to be created when creating a PVC. The following configuration shows how to use a PVC to apply for an SAS (high I/O) EVS disk (block storage).
                                                          
+
                                                          apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: pvc-evs-example
@@ -25,13 +25,13 @@ spec:
     requests:
       storage: 10Gi
   storageClassName: csi-disk
                                                          
-
                                                          If you need to specify the EVS disk type, you can set the everest.io/disk-volume-type field. The value SAS is used as an example here, indicating the high I/O EVS disk type. Or you can choose SATA (common I/O) and SSD (ultra-high I/O).
                                                          
-
                                                          This configuration method may not work if you want to:
                                                          
-
                                                          • Set storageClassName only, which is simpler than specifying the EVS disk type by using everest.io/disk-volume-type.
                                                          • Avoid modifying YAML files or Helm charts. Some users switch from self-built or other Kubernetes services to CCE and have written YAML files of many applications. In these YAML files, different types of storage resources are specified by different StorageClassNames. When using CCE, they need to modify a large number of YAML files or Helm charts to use storage resources, which is labor-consuming and error-prone.
                                                          • Set the default storageClassName for all applications to use the default storage class. In this way, you can create storage resources of the default type without needing to specify storageClassName in the YAML file.
                                                          
+
                                                          If you need to specify the EVS disk type, you can set the everest.io/disk-volume-type field. The value SAS is used as an example here, indicating the high I/O EVS disk type. Or you can choose SATA (common I/O) and SSD (ultra-high I/O).
                                                          
+
                                                          This configuration method may not work if you want to:
                                                          
+
                                                          • Set storageClassName only, which is simpler than specifying the EVS disk type by using everest.io/disk-volume-type.
                                                          • Avoid modifying YAML files or Helm charts. Some users switch from self-built or other Kubernetes services to CCE and have written YAML files of many applications. In these YAML files, different types of storage resources are specified by different StorageClassNames. When using CCE, they need to modify a large number of YAML files or Helm charts to use storage resources, which is labor-consuming and error-prone.
                                                          • Set the default storageClassName for all applications to use the default storage class. In this way, you can create storage resources of the default type without needing to specify storageClassName in the YAML file.
                                                          
 
                                                          
-
                                                          Solution
                                                          This section describes how to set a custom storage class in CCE and how to set the default storage class. You can specify different types of storage resources by setting storageClassName.
                                                          
-
                                                          • For the first scenario, you can define custom storageClassNames for SAS and SSD EVS disks. For example, define a storage class named csi-disk-sas for creating SAS disks. The following figure shows the differences before and after you use a custom storage class.
                                                            
-
                                                          • For the second scenario, you can define a storage class with the same name as that in the existing YAML file without needing to modify storageClassName in the YAML file.
                                                          • For the third scenario, you can set the default storage class as described below to create storage resources without specifying storageClassName in YAML files.
                                                            apiVersion: v1
+
                                                            Solution
                                                            This section describes how to set a custom storage class in CCE and how to set the default storage class. You can specify different types of storage resources by setting storageClassName.
                                                            
+
                                                            • For the first scenario, you can define custom storageClassNames for SAS and SSD EVS disks. For example, define a storage class named csi-disk-sas for creating SAS disks. The following figure shows the differences before and after you use a custom storage class.
                                                              
+
                                                            • For the second scenario, you can define a storage class with the same name as that in the existing YAML file without needing to modify storageClassName in the YAML file.
                                                            • For the third scenario, you can set the default storage class as described below to create storage resources without specifying storageClassName in YAML files.
                                                              apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: pvc-evs-example
@@ -44,8 +44,8 @@ spec:
       storage: 10Gi
                                                              
 
                                                            
 
                                                            
-
                                                            Custom Storage Classes
                                                            You can customize a high I/O storage class in a YAML file. For example, the name csi-disk-sas indicates that the disk type is SAS (high I/O).
                                                            
-
                                                            apiVersion: storage.k8s.io/v1
+
                                                            Custom Storage Class
                                                            You can customize a high I/O storage class in a YAML file. For example, the name csi-disk-sas indicates that the disk type is SAS (high I/O).
                                                            
+
                                                            apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
   name: csi-disk-sas                          # Name of the high I/O storage class, which can be customized.
@@ -57,9 +57,9 @@ parameters:
 provisioner: everest-csi-provisioner
 reclaimPolicy: Delete
 volumeBindingMode: Immediate
-allowVolumeExpansion: true                    # true indicates that capacity expansion is allowed.
                                                            
-
                                                            For an ultra-high I/O storage class, you can set the class name to csi-disk-ssd to create SSD EVS disk (ultra-high I/O).
                                                            
-
                                                            apiVersion: storage.k8s.io/v1
+allowVolumeExpansion: true                    # true indicates that capacity expansion is allowed.
                                                            
+
                                                            For an ultra-high I/O storage class, you can set the class name to csi-disk-ssd to create SSD EVS disk (ultra-high I/O).
                                                            
+
                                                            apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
   name: csi-disk-ssd                       # Name of the ultra-high I/O storage class, which can be customized.
@@ -72,18 +72,18 @@ provisioner: everest-csi-provisioner
 reclaimPolicy: Delete
 volumeBindingMode: Immediate
 allowVolumeExpansion: true
                                                            
-
                                                            reclaimPolicy: indicates the recycling policies of the underlying cloud storage. The value can be Delete or Retain.
                                                            
-
                                                            • Delete: When a PVC is deleted, both the PV and the EVS disk are deleted.
                                                            • Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                            
-
                                                             
                                                            The reclamation policy set here has no impact on the SFS Turbo storage. Therefore, the yearly/monthly SFS Turbo resources will not be reclaimed when the cluster or PVC is deleted.
                                                            
+
                                                            reclaimPolicy: indicates the reclaim policies of the underlying cloud storage. The value can be Delete or Retain.
                                                            
+
                                                            • Delete: When a PVC is deleted, both the PV and the EVS disk are deleted.
                                                            • Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After a PVC is deleted, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                            
+
                                                             
                                                            The reclamation policy set here has no impact on the SFS Turbo storage.
                                                            
 
                                                            
-
                                                            If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                            
-
                                                            After the definition is complete, run the kubectl create commands to create storage resources.
                                                            
-
                                                            # kubectl create -f sas.yaml
+
                                                            If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                            
+
                                                            After the definition is complete, run the kubectl create commands to create storage resources.
                                                            
+
                                                            # kubectl create -f sas.yaml
 storageclass.storage.k8s.io/csi-disk-sas created
 # kubectl create -f ssd.yaml
 storageclass.storage.k8s.io/csi-disk-ssd created
                                                            
-
                                                            Query the storage class again. Two more types of storage classes are displayed in the command output, as shown below.
                                                            
-
                                                            # kubectl get sc
+
                                                            Query the storage class again. Two more types of storage classes are displayed in the command output, as shown below.
                                                            
+
                                                            # kubectl get sc
 NAME                PROVISIONER                     AGE
 csi-disk            everest-csi-provisioner         17d
 csi-disk-sas        everest-csi-provisioner         2m28s
@@ -92,8 +92,8 @@ csi-disk-topology   everest-csi-provisioner         17d
 csi-nas             everest-csi-provisioner         17d
 csi-obs             everest-csi-provisioner         17d
 csi-sfsturbo        everest-csi-provisioner         17d
                                                            
-
                                                            Other types of storage resources can be defined in the similar way. You can use kubectl to obtain the YAML file and modify it as required.
                                                            
-
                                                            • File storage
                                                              # kubectl get sc csi-nas -oyaml
+
                                                              Other types of storage resources can be defined in the similar way. You can use kubectl to obtain the YAML file and modify it as required.
                                                              
+
                                                              • File Storage
                                                                # kubectl get sc csi-nas -oyaml
 kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
@@ -109,7 +109,7 @@ parameters:
 reclaimPolicy: Delete
 allowVolumeExpansion: true
 volumeBindingMode: Immediate
                                                                
-
                                                              • Object storage
                                                                # kubectl get sc csi-obs -oyaml
+
                                                              • Object storage
                                                                # kubectl get sc csi-obs -oyaml
 kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
@@ -117,15 +117,15 @@ metadata:
 provisioner: everest-csi-provisioner
 parameters:
   csi.storage.k8s.io/csi-driver-name: obs.csi.everest.io
-  csi.storage.k8s.io/fstype: s3fs           # Object storage type. s3fs indicates an object bucket, and obsfs indicates a parallel file system.
+  csi.storage.k8s.io/fstype: s3fs           # Object storage type. s3fs indicates an object bucket, and obsfs indicates a parallel file system.
   everest.io/obs-volume-type: STANDARD      # Storage class of the OBS bucket
 reclaimPolicy: Delete
 volumeBindingMode: Immediate
                                                                
 
                                                              
 
                                                            
-
                                                            Setting a Default Storage Class
                                                            You can specify a storage class as the default class. In this way, if you do not specify storageClassName when creating a PVC, the PVC is created using the default storage class.
                                                            
-
                                                            For example, to specify csi-disk-ssd as the default storage class, edit your YAML file as follows:
                                                            
-
                                                            apiVersion: storage.k8s.io/v1
+
                                                            Setting a Default Storage Class
                                                            You can specify a storage class as the default class. In this way, if you do not specify storageClassName when creating a PVC, the PVC is created using the default storage class.
                                                            
+
                                                            For example, to specify csi-disk-ssd as the default storage class, edit your YAML file as follows:
                                                            
+
                                                            apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
   name: csi-disk-ssd
@@ -140,8 +140,8 @@ provisioner: everest-csi-provisioner
 reclaimPolicy: Delete
 volumeBindingMode: Immediate
 allowVolumeExpansion: true
                                                            
-
                                                            Delete the created csi-disk-ssd disk, run the kubectl create command to create a csi-disk-ssd disk again, and then query the storage class. The following information is displayed.
                                                            
-
                                                            # kubectl delete sc csi-disk-ssd
+
                                                            Delete the created csi-disk-ssd disk, run the kubectl create command to create a csi-disk-ssd disk again, and then query the storage class. The following information is displayed.
                                                            
+
                                                            # kubectl delete sc csi-disk-ssd
 storageclass.storage.k8s.io "csi-disk-ssd" deleted
 # kubectl create -f ssd.yaml
 storageclass.storage.k8s.io/csi-disk-ssd created
@@ -155,7 +155,7 @@ csi-nas                  everest-csi-provisioner         17d
 csi-obs                  everest-csi-provisioner         17d
 csi-sfsturbo             everest-csi-provisioner         17d
                                                            
 
                                                            
-
                                                            Verification
                                                            • Use csi-disk-sas to create a PVC.
                                                              apiVersion: v1
+
                                                              Verification
                                                              • Use csi-disk-sas to create a PVC.
                                                                apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name:  sas-disk
@@ -166,8 +166,8 @@ spec:
     requests:
       storage: 10Gi
   storageClassName: csi-disk-sas
                                                                
-
                                                                Create a storage class and view its details. As shown below, the object can be created and the value of STORAGECLASS is csi-disk-sas.
                                                                
-
                                                                # kubectl create -f sas-disk.yaml 
+
                                                                Create a storage class and view its details. As shown below, the object can be created and the value of STORAGECLASS is csi-disk-sas.
                                                                
+
                                                                # kubectl create -f sas-disk.yaml 
 persistentvolumeclaim/sas-disk created
 # kubectl get pvc
 NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
@@ -175,9 +175,9 @@ sas-disk   Bound    pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO
 # kubectl get pv
 NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
 pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            Delete           Bound       default/sas-disk          csi-disk-sas            30s
                                                                
-
                                                                View the PVC details on the CCE console. On the PV details page, you can see that the disk type is high I/O.
                                                                
-
                                                                
-
                                                              • If storageClassName is not specified, the default configuration is used, as shown below.
                                                                apiVersion: v1
+
                                                                View the PVC details on the CCE console. On the PV details page, you can see that the disk type is high I/O.
                                                                
+
                                                                
+
                                                              • If storageClassName is not specified, the default configuration is used, as shown below.
                                                                apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name:  ssd-disk
@@ -187,8 +187,8 @@ spec:
   resources:
     requests:
       storage: 10Gi
                                                                
-
                                                                Create and view the storage resource. You can see that the storage class of PVC ssd-disk is csi-disk-ssd, indicating that csi-disk-ssd is used by default.
                                                                
-
                                                                # kubectl create -f ssd-disk.yaml 
+
                                                                Create and view the storage resource. You can see that the storage class of PVC ssd-disk is csi-disk-ssd, indicating that csi-disk-ssd is used by default.
                                                                
+
                                                                # kubectl create -f ssd-disk.yaml 
 persistentvolumeclaim/ssd-disk created
 # kubectl get pvc
 NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
@@ -198,8 +198,8 @@ ssd-disk   Bound    pvc-4d2b059c-0d6c-44af-9994-f74d01c78731   10Gi       RWO
 NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
 pvc-4d2b059c-0d6c-44af-9994-f74d01c78731   10Gi       RWO            Delete           Bound       default/ssd-disk          csi-disk-ssd            15s
 pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            Delete           Bound       default/sas-disk          csi-disk-sas            17m
                                                                
-
                                                                View the PVC details on the CCE console. On the PV details page, you can see that the disk type is ultra-high I/O.
                                                                
-
                                                                
+
                                                                View the PVC details on the CCE console. On the PV details page, you can see that the disk type is ultra-high I/O.
                                                                
+
                                                                
 
                                                              
 
                                                              
 
                                                            
diff --git a/docs/cce/umn/cce_10_0384.html b/docs/cce/umn/cce_10_0384.html
index cacb3a4c..f2a8c26a 100644
--- a/docs/cce/umn/cce_10_0384.html
+++ b/docs/cce/umn/cce_10_0384.html
@@ -1,321 +1,129 @@
 
 
 
                                                            Hybrid Deployment of Online and Offline Jobs
                                                            
-
                                                            
-  
                                                            
-    
                                                            Online and Offline Jobs
                                                            
-    
                                                            Jobs can be classified into online jobs and offline jobs based on whether
-      services are always online.
                                                            
-    
                                                              
-      
                                                            • Online job: Such jobs run
-        for a long time, with regular traffic surges, tidal resource requests, and high requirements on SLA, such as
-        advertising and e-commerce services.
                                                              • 
-      
                                                            • Offline jobs: Such jobs run
-        for a short time, have high computing requirements, and can tolerate high latency, such as AI and big data
-        services.
                                                              • 
-    
                                                            
-  
                                                            
-  
                                                            
-    
                                                            Resource Oversubscription and Hybrid Deployment
                                                            
-    
                                                            Many services see surges in traffic. To ensure performance and stability,
-      resources are often requested at the maximum needed. However, the surges may ebb very shortly and resources, if
-      not released, are wasted in non-peak hours. Especially for online jobs that request a large quantity of resources
-      to ensure SLA, resource utilization can be as low as it gets.
                                                            
-    
                                                            Resource oversubscription is the process of making use of idle requested
-      resources. Oversubscribed resources are suitable for deploying offline jobs, which focus on throughput but have
-      low SLA requirements and can tolerate certain failures.
                                                            
-    
                                                            Hybrid deployment of online and offline jobs in a cluster can better utilize
-      cluster resources.
                                                            
-    
                                                            Figure 1 Resource
-        oversubscription
                                                            
-  
                                                            
-  
                                                            
-    
                                                            Oversubscription for Hybrid Deployment
                                                            
-    
                                                            Hybrid deployment is supported, and CPU and memory resources can be
-      oversubscribed. The key features are as follows:
                                                            
-    
                                                              
-      
                                                            • Offline jobs preferentially run on oversubscribed nodes.
                                                              If
-          both oversubscribed and non-oversubscribed nodes exist, the former will score higher than the latter and
-          offline jobs are preferentially scheduled to oversubscribed nodes.
                                                              
-      
                                                              • 
-    
                                                            
-    
                                                              
-      
                                                            • Online jobs can use only non-oversubscribed resources if scheduled to an
-        oversubscribed node.
                                                              Offline jobs can use both oversubscribed and non-oversubscribed resources of an
-          oversubscribed node.
                                                              
-      
                                                              • 
-    
                                                            
-    
                                                              
-      
                                                            • In the same scheduling period, online jobs take precedence over offline
-        jobs.
                                                              If both online and offline jobs exist, online jobs are scheduled first. When the
-          node resource usage exceeds the upper limit and the node requests exceed 100%, offline jobs will be evicted.
-        
                                                              
-      
                                                              • 
-      
                                                            • CPU/memory isolation is provided by kernels.
                                                              CPU
-          isolation: Online jobs can quickly preempt CPU resources of offline jobs and suppress the CPU usage of the
-          offline jobs.
                                                              
-        
                                                              Memory isolation: When system memory resources are used up and OOM Kill is
-          triggered, the kernel evicts offline jobs first.
                                                              
-      
                                                              • 
-      
                                                            • kubelet offline jobs admission rules:
                                                              After the the pod is scheduled to a
-          node, kubelet starts the pod only when the node resources can meet the pod request
-          (predicateAdmitHandler.Admit). kubelet starts the pod when both of the following conditions are met:
                                                              
-        
                                                                
-          
                                                              • The total request of pods to be started and online running jobs <
-            allocatable nodes
                                                                • 
-          
                                                              • The total request of pods to be started and online/offline running job
-            < allocatable nodes+oversubscribed nodes
                                                                • 
-        
                                                              
-      
                                                              • 
-      
                                                            • Resource oversubscription and hybrid deployment:
                                                              If only hybrid deployment is used, you need to configure the label volcano.sh/colocation=true for the node and delete the node label
-          volcano.sh/oversubscription or set its value to false.
                                                              
-        
                                                              If the label volcano.sh/colocation=true is configured for a node, hybrid
-          deployment is enabled. If the label volcano.sh/oversubscription=true is configured, resource
-          oversubscription is enabled. The following table lists the available feature combinations after hybrid
-          deployment or resource oversubscription is enabled.
-          
                                                              
-            
                                                          Table 5 Local disk storage dependency parameters
                                                          Parameter
                                                          
 
                                                          Description
                                                          
+
                                                          Description
                                                          
                                                           		
 
                                                          
 
                                                          mountPath
                                                          
+
                                                          mountPath
                                                          
 
                                                          Mount path of the container. In this example, the volume is mounted to the /tmp directory.
                                                          
+
                                                          Mount path of the container. In this example, the volume is mounted to the /tmp directory.
                                                          
                                                           		
 
                                                          hostPath
                                                          
+
                                                          hostPath
                                                          
 
                                                          Host path. In this example, the host path is /tmp/test.
                                                          
+
                                                          Host path. In this example, the host path is /tmp/test.
                                                          
                                                           		
 
                                                          
                                                           
 
                                                          A reclaim policy is supported when the cluster version is equal to or later than 1.19.10 and the everest version is equal to or later than 1.2.9.
                                                          
 
                                                          The Delete and Retain policies are supported.
                                                          
 
                                                          Delete:
                                                          
-
                                                          • If everest.io/reclaim-policy is not specified, both the PV and EVS disk are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only set, when a PVC is deleted, the PV is deleted but the EVS resources are retained.
                                                          
+
                                                          • If everest.io/reclaim-policy is not specified, both the PV and EVS disk are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only, when a PVC is deleted, the PV is deleted but the EVS resources are retained.
                                                          
 
                                                          Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                          
 
                                                          If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                          
 
                                                          A reclaim policy is supported when the cluster version is equal to or later than 1.19.10 and the everest version is equal to or later than 1.2.9.
                                                          
 
                                                          The options are as follows:
                                                          
 
                                                          Delete:
                                                          
-
                                                          • If everest.io/reclaim-policy is not specified, both the PV and SFS volume are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only set, when a PVC is deleted, the PV is deleted but the file storage resources are retained.
                                                          
+
                                                          • If everest.io/reclaim-policy is not specified, both the PV and SFS volume are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only, when a PVC is deleted, the PV is deleted but the file storage resources are retained.
                                                          
 
                                                          Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                          
 
                                                          If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                          
 
                                                          everest.io/region
                                                          
                                                           		
 
                                                          Region where the OBS bucket is deployed.
                                                          
-
                                                          For details about the value of region, see Regions and Endpoints.
                                                          
+
                                                          For details about the value of region, see Regions and Endpoints.
                                                          
                                                           		
 
                                                          
 
                                                          nodePublishSecretRef
                                                          
@@ -310,7 +310,7 @@ spec:
 
                                                          A reclaim policy is supported when the cluster version is equal to or later than 1.19.10 and the everest version is equal to or later than 1.2.9.
                                                          
 
                                                          The Delete and Retain policies are supported.
                                                          
 
                                                          Delete:
                                                          
-
                                                          • If everest.io/reclaim-policy is not specified, both the PV and OBS volume are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only set, when a PVC is deleted, the PV is deleted but the object storage resources are retained.
                                                          
+
                                                          • If everest.io/reclaim-policy is not specified, both the PV and OBS volume are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only, when a PVC is deleted, the PV is deleted but the object storage resources are retained.
                                                          
 
                                                          Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                          
 
                                                          If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                          
 
                                                          A reclaim policy is supported when the cluster version is equal to or later than 1.19.10 and the everest version is equal to or later than 1.2.9.
                                                          
 
                                                          The Delete and Retain policies are supported.
                                                          
 
                                                          Delete:
                                                          
-
                                                          • If everest.io/reclaim-policy is not specified, both the PV and SFS Turbo volume are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only set, when a PVC is deleted, the PV is deleted but the SFF Turbo resources are retained.
                                                          
+
                                                          • If everest.io/reclaim-policy is not specified, both the PV and SFS Turbo volume are deleted when a PVC is deleted.
                                                          • If everest.io/reclaim-policy is set to retain-volume-only, when a PVC is deleted, the PV is deleted but the SFF Turbo resources are retained.
                                                          
 
                                                          Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                          
 
                                                          If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                          
                                                           		
 
 
                                                          
-              
-                
-                  
-                  
-                  
-                  
-                
-              
-              
-                
-                  
-                  
-                  
-                  
-                
-                
-                  
-                  
-                  
-                  
-                
-                
-                  
-                  
-                  
-                  
-                
-                
-                  
-                  
-                  
-                  
-                
-              
-            
                                                          
-                    
                                                          Hybrid Deployment Enabled (volcano.sh/colocation=true)
                                                          
-                                                                            		
-                    
                                                          Resource oversubscription Enabled (volcano.sh/oversubscription=true)
                                                          
-                                                                            		
-                    
                                                          Use Oversubscribed Resources?
                                                          
-                                                                            		
-                    
                                                          Conditions for Evicting Offline Pods
                                                          
-                  
                                                          
-                    
                                                          No
                                                          
-                                                                            		
-                    
                                                          No
                                                          
-                                                                            		
-                    
                                                          No
                                                          
-                                                                            		
-                    
                                                          None
                                                          
-                  
                                                          
-                    
                                                          Yes
                                                          
-                                                                            		
-                    
                                                          No
                                                          
-                                                                            		
-                    
                                                          No
                                                          
-                                                                            		
-                    
                                                          The node resource usage exceeds the high threshold.
                                                          
-                  
                                                          
-                    
                                                          No
                                                          
-                                                                            		
-                    
                                                          Yes
                                                          
-                                                                            		
-                    
                                                          Yes
                                                          
-                                                                            		
-                    
                                                          The node resource usage exceeds the high threshold, and the node
-                      request exceeds 100%.
                                                          
-                  
                                                          
-                    
                                                          Yes
                                                          
-                                                                            		
-                    
                                                          Yes
                                                          
-                                                                            		
-                    
                                                          Yes
                                                          
-                                                                            		
-                    
                                                          The node resource usage exceeds the high threshold.
                                                          
-                  
                                                          
-          
                                                          
-        
-      
-    
-  
-  
                                                          
-    
                                                          Notes and Constraints
                                                          
-    
                                                          Specifications
-      
                                                            
-        
                                                          • Kubernetes version:
                                                              
-            
                                                            • 1.19: 1.19.16-r4 or later
                                                              • 
-            
                                                            • 1.21: 1.21.7-r0 or later
                                                              • 
-            
                                                            • 1.23: 1.23.5-r0 or later
                                                              • 
-          
                                                            
-        
                                                            • 
-        
                                                          • Cluster Type: CCE or CCE Turbo
                                                            • 
-        
                                                          • Node OS: EulerOS 2.9 (kernel-4.18.0-147.5.1.6.h729.6.eulerosv2r9.x86_64)
                                                            • 
-        
                                                          • Node Type: ECS
                                                            • 
-        
                                                          • The volcano add-on version: 1.7.0 or later
                                                            • 
-      
                                                          
-    
                                                          
-    
                                                          Constraints
-      
                                                            
-        
                                                          • Before enabling the volcano oversubscription plug-in, ensure that the
-          overcommit plug-in is not enabled.
                                                            • 
-        
                                                          • Modifying the label of an oversubscribed node does not affect the running
-          pods.
                                                            • 
-        
                                                          • Running pods cannot be converted between online and offline services. To
-          convert services, you need to rebuild pods.
                                                            • 
-        
                                                          • If the label volcano.sh/oversubscription=true is configured for a node in the
-          cluster, the oversubscription configuration must be added to
-          the volcano add-on. Otherwise, the scheduling of oversubscribed nodes will be abnormal. Ensure that you have
-          correctly configure labels because the scheduler does not check the add-on and node configurations. For
-          details about the labels, see Configuring Oversubscription Labels
-            for Scheduling.
                                                            • 
-        
                                                          • To disable oversubscription, perform the following operations:
                                                              
-            
                                                            • Remove the volcano.sh/oversubscription label from the oversubscribed
-              node.
                                                              • 
-            
                                                            • Set over-subscription-resource to false.
                                                              • 
-            
                                                            • Modify the configmap of the volcano scheduler named volcano-scheduler-configmap and remove the oversubscription
-              add-on.
                                                              • 
-          
                                                            
-        
                                                            • 
-        
                                                          • If cpu-manager-policy is
-          set to static core binding on a node, do not assign the QoS class of Guaranteed to offline pods. If core
-          binding is required, change the pods to online pods. Otherwise, offline pods may occupy the CPUs of online
-          pods, causing online pod startup failures, and offline pods fail to be started although they are successfully
-          scheduled.
                                                            • 
-        
                                                          • If cpu-manager-policy is
-          set to static core binding on a node, do not bind cores to all online pods. Otherwise, online pods occupy all
-          CPU or memory resources, leaving a small number of oversubscribed resources.
                                                            • 
-      
                                                          
-    
                                                          
-  
                                                          
-  
                                                          
-    
                                                          Configuring Oversubscription Labels for Scheduling
                                                          
-    
                                                          If the label volcano.sh/oversubscription=true is configured for a node in the
-      cluster, the oversubscription configuration must be added to the
-      volcano add-on. Otherwise, the scheduling of oversubscribed nodes will be abnormal. For details about the related
-      configuration, see Table 1.
                                                          
-    
                                                          Ensure that you have correctly configure labels because the scheduler
-      does not check the add-on and node configurations.
-      
                                                          
-        
-          
-          
-            
-              
-              
-              
-            
-          
-          
-            
-              
-              
-              
-            
-            
-              
-              
-              
-            
-            
-              
-              
-              
-            
-            
-              
-              
-              
-            
-          
-        
                                                          Table 1 Configuring oversubscription labels for scheduling
                                                          
-                
                                                          Oversubscription in Add-on
                                                          
-                                                                        		
-                
                                                          Oversubscription Label on Node
                                                          
-                                                                        		
-                
                                                          Scheduling
                                                          
-              
                                                          
-                
                                                          Yes
                                                          
-                                                                        		
-                
                                                          Yes
                                                          
-                                                                        		
-                
                                                          Triggered by oversubscription
                                                          
-              
                                                          
-                
                                                          Yes
                                                          
-                                                                        		
-                
                                                          No
                                                          
-                                                                        		
-                
                                                          Triggered
                                                          
-              
                                                          
-                
                                                          No
                                                          
-                                                                        		
-                
                                                          No
                                                          
-                                                                        		
-                
                                                          Triggered
                                                          
-              
                                                          
-                
                                                          No
                                                          
-                                                                        		
-                
                                                          Yes
                                                          
-                                                                        		
-                
                                                          Not triggered or failed. Avoid this configuration.
                                                          
-              
                                                          
-      
                                                          
-    
                                                          
-  
                                                          
-  
                                                          
-    
                                                          Using Hybrid Deployment
                                                          
-    
                                                            
-      
                                                          1. Configure the volcano add-on.
-        
                                                            
-        
                                                              
-          
                                                            1. Use kubectl to connect to the cluster.
                                                              2. 
-          
                                                            2. Install the volcano plug-in and add the oversubscription plug-in to volcano-scheduler-configmap. Ensure that the plug-in
-            configuration does not contain the overcommit plug-in. If
-            - name: overcommit exists, delete this configuration.
-            
                                                              # kubectl edit cm volcano-scheduler-configmap -n kube-system
+
                                                              Online and Offline Jobs
                                                              Jobs can be classified into online jobs and offline jobs based on whether services are always online.
                                                              
+
                                                              • Online job: Such jobs run for a long time, with regular traffic surges, tidal resource requests, and high requirements on SLA, such as advertising and e-commerce services.
                                                              • Offline jobs: Such jobs run for a short time, have high computing requirements, and can tolerate high latency, such as AI and big data services.
                                                              
+
                                                              
+
                                                              Resource Oversubscription and Hybrid Deployment
                                                              Many services see surges in traffic. To ensure performance and stability, resources are often requested at the maximum needed. However, the surges may ebb very shortly and resources, if not released, are wasted in non-peak hours. Especially for online jobs that request a large quantity of resources to ensure SLA, resource utilization can be as low as it gets.
                                                              
+
                                                              Resource oversubscription is the process of making use of idle requested resources. Oversubscribed resources are suitable for deploying offline jobs, which focus on throughput but have low SLA requirements and can tolerate certain failures.
                                                              
+
                                                              Hybrid deployment of online and offline jobs in a cluster can better utilize cluster resources.
                                                              
+
                                                              Figure 1 Resource oversubscription
                                                              
+
                                                              
+
                                                              Oversubscription for Hybrid Deployment
                                                              Hybrid deployment is supported, and CPU and memory resources can be oversubscribed. The key features are as follows:
                                                              
+
                                                              • Offline jobs preferentially run on oversubscribed nodes.
                                                                If both oversubscribed and non-oversubscribed nodes exist, the former will score higher than the latter and offline jobs are preferentially scheduled to oversubscribed nodes.
                                                                
+
                                                              
+
                                                              • Online jobs can use only non-oversubscribed resources if scheduled to an oversubscribed node.
                                                                Offline jobs can use both oversubscribed and non-oversubscribed resources of an oversubscribed node.
                                                                
+
                                                              
+
                                                              • In the same scheduling period, online jobs take precedence over offline jobs.
                                                                If both online and offline jobs exist, online jobs are scheduled first. When the node resource usage exceeds the upper limit and the node requests exceed 100%, offline jobs will be evicted.
                                                                
+
                                                              • CPU/memory isolation is provided by kernels.
                                                                CPU isolation: Online jobs can quickly preempt CPU resources of offline jobs and suppress the CPU usage of the offline jobs.
                                                                
+
                                                                Memory isolation: When system memory resources are used up and OOM Kill is triggered, the kernel evicts offline jobs first.
                                                                
+
                                                              • kubelet offline jobs admission rules:
                                                                After the the pod is scheduled to a node, kubelet starts the pod only when the node resources can meet the pod request (predicateAdmitHandler.Admit). kubelet starts the pod when both of the following conditions are met:
                                                                
+
                                                                • The total request of pods to be started and online running jobs < allocatable nodes
                                                                • The total request of pods to be started and online/offline running job < allocatable nodes+oversubscribed nodes
                                                                
+
                                                              • Resource oversubscription and hybrid deployment:
                                                                If only hybrid deployment is used, you need to configure the label volcano.sh/colocation=true for the node and delete the node label volcano.sh/oversubscription or set its value to false.
                                                                
+
                                                                If the label volcano.sh/colocation=true is configured for a node, hybrid deployment is enabled. If the label volcano.sh/oversubscription=true is configured, resource oversubscription is enabled. The following table lists the available feature combinations after hybrid deployment or resource oversubscription is enabled.
+
                                                                
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                                Hybrid Deployment Enabled (volcano.sh/colocation=true)
                                                                
+
                                                                Resource oversubscription Enabled (volcano.sh/oversubscription=true)
                                                                
+
                                                                Use Oversubscribed Resources?
                                                                
+
                                                                Conditions for Evicting Offline Pods
                                                                
+
                                                                No
                                                                
+
                                                                No
                                                                
+
                                                                No
                                                                
+
                                                                None
                                                                
+
                                                                Yes
                                                                
+
                                                                No
                                                                
+
                                                                No
                                                                
+
                                                                The node resource usage exceeds the high threshold.
                                                                
+
                                                                No
                                                                
+
                                                                Yes
                                                                
+
                                                                Yes
                                                                
+
                                                                The node resource usage exceeds the high threshold, and the node request exceeds 100%.
                                                                
+
                                                                Yes
                                                                
+
                                                                Yes
                                                                
+
                                                                Yes
                                                                
+
                                                                The node resource usage exceeds the high threshold.
                                                                
+
                                                                
+
                                                                
+
                                                                
+
                                                              
+
                                                              
+
                                                              Notes and Constraints
                                                              Specifications
                                                              • Kubernetes version:
                                                                • v1.19: v1.19.16-r4 or later
                                                                • v1.21: v1.21.7-r0 or later
                                                                • v1.23: v1.23.5-r0 or later
                                                                • v1.25 or later
                                                                
+
                                                              • Cluster type: CCE or CCE Turbo
                                                              • Node OS: EulerOS 2.9 (kernel-4.18.0-147.5.1.6.h729.6.eulerosv2r9.x86_64)
                                                              • Node type: ECS
                                                              • volcano add-on version: 1.7.0 or later
                                                              
+
                                                              
+
                                                              Constraints
                                                              • Before enabling the volcano oversubscription plug-in, ensure that the overcommit plug-in is not enabled.
                                                              • Modifying the label of an oversubscribed node does not affect the running pods.
                                                              • Running pods cannot be converted between online and offline services. To convert services, you need to rebuild pods.
                                                              • If the label volcano.sh/oversubscription=true is configured for a node in the cluster, the oversubscription configuration must be added to the volcano add-on. Otherwise, the scheduling of oversubscribed nodes will be abnormal. Ensure that you have correctly configure labels because the scheduler does not check the add-on and node configurations. For details about the labels, see Configuring Oversubscription Labels for Scheduling.
                                                              • To disable oversubscription, perform the following operations:
                                                                • Remove the volcano.sh/oversubscription label from the oversubscribed node.
                                                                • Set over-subscription-resource to false.
                                                                • Modify the configmap of the volcano scheduler named volcano-scheduler-configmap and remove the oversubscription add-on.
                                                                
+
                                                              • If cpu-manager-policy is set to static core binding on a node, do not assign the QoS class of Guaranteed to offline pods. If core binding is required, change the pods to online pods. Otherwise, offline pods may occupy the CPUs of online pods, causing online pod startup failures, and offline pods fail to be started although they are successfully scheduled.
                                                              • If cpu-manager-policy is set to static core binding on a node, do not bind cores to all online pods. Otherwise, online pods occupy all CPU or memory resources, leaving a small number of oversubscribed resources.
                                                              
+
                                                              
+
                                                              
+
                                                              Configuring Oversubscription Labels for Scheduling
                                                              If the label volcano.sh/oversubscription=true is configured for a node in the cluster, the oversubscription configuration must be added to the volcano add-on. Otherwise, the scheduling of oversubscribed nodes will be abnormal. For details about the related configuration, see Table 1.
                                                              
+
                                                              Ensure that you have correctly configure labels because the scheduler does not check the add-on and node configurations.
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 1 Configuring oversubscription labels for scheduling
                                                              Oversubscription in Add-on
                                                              
+
                                                              Oversubscription Label on Node
                                                              
+
                                                              Scheduling
                                                              
+
                                                              Yes
                                                              
+
                                                              Yes
                                                              
+
                                                              Triggered by oversubscription
                                                              
+
                                                              Yes
                                                              
+
                                                              No
                                                              
+
                                                              Triggered
                                                              
+
                                                              No
                                                              
+
                                                              No
                                                              
+
                                                              Triggered
                                                              
+
                                                              No
                                                              
+
                                                              Yes
                                                              
+
                                                              Not triggered or failed. Avoid this configuration.
                                                              
+
                                                              
+
                                                              
+
                                                              
+
                                                              
+
                                                              Using Hybrid Deployment
                                                              1. Configure the volcano add-on.
                                                                1. Use kubectl to connect to the cluster.
                                                                2. Install the volcano plug-in and add the oversubscription plug-in to volcano-scheduler-configmap. Ensure that the plug-in configuration does not contain the overcommit plug-in. If - name: overcommit exists, delete this configuration.
                                                                  # kubectl edit cm volcano-scheduler-configmap -n kube-system
 apiVersion: v1
 data:
   volcano-scheduler.conf: |
@@ -335,45 +143,16 @@ data:
       - name: cce-gpu-topology-predicate
       - name: cce-gpu-topology-priority
       - name: cce-gpu
                                                                  
-          
                                                                  3. 
-        
                                                                
-        
                                                                
-      
                                                                2. 
-      
                                                              2. Enable the node oversubscription feature.
-        
                                                                
-        
                                                                A label can be configured to use oversubscribed resources only after the
-          oversubscription feature is enabled for a node. Related nodes can be created only in a node pool. To enable
-          the oversubscription feature, perform the following steps:
                                                                
-        
                                                                  
-          
                                                                1. Create a node pool.
                                                                  2. 
-          
                                                                2. Choose More > Manage in the Operation column of the created node pool.
                                                                  3. 
-          
                                                                3. In the Manage
-              Component window that is displayed, set over-subscription-resource under kubelet to true
-            and click OK.
                                                                  4. 
-        
                                                                
-        
                                                                
-        
                                                                
-      
                                                                3. 
-      
                                                              3. Set the node oversubscription label.
-        
                                                                
-        
                                                                The volcano.sh/oversubscription label needs to be configured for an
-          oversubscribed node. If this label is set for a node and the value is true, the node is an oversubscribed node. Otherwise, the node is not
-          an oversubscribed node.
                                                                
-        
                                                                kubectl label node 192.168.0.0 volcano.sh/oversubscription=true
                                                                
-        
                                                                An oversubscribed node also supports the oversubscription thresholds, as
-          listed in Table 2. For example:
                                                                
-        
                                                                kubectl annotate node 192.168.0.0 volcano.sh/evicting-cpu-high-watermark=70
                                                                
-        
                                                                Querying the node information
                                                                
-        
                                                                # kubectl describe node 192.168.0.0
+
                                                              
+
                                                            3. Enable the node oversubscription feature.
                                                              A label can be configured to use oversubscribed resources only after the oversubscription feature is enabled for a node. Related nodes can be created only in a node pool. To enable the oversubscription feature, perform the following steps:
                                                              
+
                                                              1. Create a node pool.
                                                              2. Choose More > Manage in the Operation column of the created node pool.
                                                              3. In the Manage Component window that is displayed, set over-subscription-resource under kubelet to true and click OK.
                                                              
+
                                                              
+
                                                            4. Set the node oversubscription label.
                                                              The volcano.sh/oversubscription label needs to be configured for an oversubscribed node. If this label is set for a node and the value is true, the node is an oversubscribed node. Otherwise, the node is not an oversubscribed node.
                                                              
+
                                                              kubectl label node 192.168.0.0 volcano.sh/oversubscription=true
                                                              
+
                                                              An oversubscribed node also supports the oversubscription thresholds, as listed in Table 2. For example:
                                                              
+
                                                              kubectl annotate node 192.168.0.0 volcano.sh/evicting-cpu-high-watermark=70
                                                              
+
                                                              Querying the node information
                                                              
+
                                                              # kubectl describe node 192.168.0.0
 Name:             192.168.0.0
 Roles:              <none>
 Labels:           ...
@@ -381,108 +160,51 @@ Labels:           ...
 Annotations:      ...
                   volcano.sh/evicting-cpu-high-watermark: 70
                                                              
 
-        
                                                              
-          
-            
-            
-              
-                
-                
-              
-            
-            
-              
-                
-                
-              
-              
-                
-                
-              
-              
-                
-                
-              
-              
-                
-                
-              
-              
-                
-                
-              
-            
-          
                                                              Table 2 Node oversubscription annotations
                                                              
-                  
                                                              Name
                                                              
-                                                                              		
-                  
                                                              Description
                                                              
-                
                                                              
-                  
                                                              volcano.sh/evicting-cpu-high-watermark
                                                              
-                                                                              		
-                  
                                                              When the CPU usage of a node exceeds the specified value, offline
-                    job eviction is triggered and the node becomes unschedulable.
                                                              
-                  
                                                              The default value is 80, indicating that offline job eviction is triggered when
-                    the CPU usage of a node exceeds 80%.
                                                              
-                
                                                              
-                  
                                                              volcano.sh/evicting-cpu-low-watermark
                                                              
-                                                                              		
-                  
                                                              After eviction is triggered, the scheduling starts again when the
-                    CPU usage of a node is lower than the specified value.
                                                              
-                  
                                                              The default value is 30, indicating that scheduling starts again when the CPU
-                    usage of a node is lower than 30%.
                                                              
-                
                                                              
-                  
                                                              volcano.sh/evicting-memory-high-watermark
                                                              
-                                                                              		
-                  
                                                              When the memory usage of a node exceeds the specified value, offline
-                    job eviction is triggered and the node becomes unschedulable.
                                                              
-                  
                                                              The default value is 60, indicating that offline job eviction is triggered
-                    when the memory usage of a node exceeds 60%.
                                                              
-                
                                                              
-                  
                                                              volcano.sh/evicting-memory-low-watermark
                                                              
-                                                                              		
-                  
                                                              After eviction is triggered, the scheduling starts again when the
-                    memory usage of a node is lower than the specified value.
                                                              
-                  
                                                              The default value is 30, indicating that the scheduling starts again when
-                    the memory usage of a node is less than 30%.
                                                              
-                
                                                              
-                  
                                                              volcano.sh/oversubscription-types
                                                              
-                                                                              		
-                  
                                                              Oversubscribed resource type. The options are as follows:
                                                              
-                  
                                                                
-                    
                                                              • CPU (oversubscribed CPU)
                                                                • 
-                    
                                                              • memory (oversubscribed memory)
                                                                • 
-                    
                                                              • cpu,memory (oversubscribed CPU and memory)
                                                                • 
-                  
                                                              
-                  
                                                              The default value is cpu,memory.
                                                              
-                
                                                              
-        
                                                              
-        
                                                              
-      
                                                              5. 
-      
                                                            5. Deploy online and offline jobs.
-        
                                                              
-        
                                                              The volcano.sh/qos-level
-          label needs to be added to annotation to distinguish offline jobs. The value is an integer ranging from -7 to
-          7. If the value is less than 0, the job is an offline job. If the value is greater than or equal to 0, the job
-          is a high-priority job, that is, online job. You do not need to set this label for online jobs. For both
-          online and offline jobs, set schedulerName to volcano to enable the Volcano scheduler.
                                                              
-        
                                                               
-          
                                                              
-            
                                                              The priorities of online/online and offline/offline jobs are not
-              differentiated, and the value validity is not verified. If the value of volcano.sh/qos-level of an offline job is not a negative
-              integer ranging from -7 to 0, the job is processed as an online job.
                                                              
-          
                                                              
-        
                                                              
-        
                                                              For an offline job:
                                                              
-        
                                                              kind: Deployment
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 2 Node oversubscription annotations
                                                              Name
                                                              
+
                                                              Description
                                                              
+
                                                              volcano.sh/evicting-cpu-high-watermark
                                                              
+
                                                              When the CPU usage of a node exceeds the specified value, offline job eviction is triggered and the node becomes unschedulable.
                                                              
+
                                                              The default value is 80, indicating that offline job eviction is triggered when the CPU usage of a node exceeds 80%.
                                                              
+
                                                              volcano.sh/evicting-cpu-low-watermark
                                                              
+
                                                              After eviction is triggered, the scheduling starts again when the CPU usage of a node is lower than the specified value.
                                                              
+
                                                              The default value is 30, indicating that scheduling starts again when the CPU usage of a node is lower than 30%.
                                                              
+
                                                              volcano.sh/evicting-memory-high-watermark
                                                              
+
                                                              When the memory usage of a node exceeds the specified value, offline job eviction is triggered and the node becomes unschedulable.
                                                              
+
                                                              The default value is 60, indicating that offline job eviction is triggered when the memory usage of a node exceeds 60%.
                                                              
+
                                                              volcano.sh/evicting-memory-low-watermark
                                                              
+
                                                              After eviction is triggered, the scheduling starts again when the memory usage of a node is lower than the specified value.
                                                              
+
                                                              The default value is 30, indicating that the scheduling starts again when the memory usage of a node is less than 30%.
                                                              
+
                                                              volcano.sh/oversubscription-types
                                                              
+
                                                              Oversubscribed resource type. The options are as follows:
                                                              
+
                                                              • CPU (oversubscribed CPU)
                                                              • memory (oversubscribed memory)
                                                              • cpu,memory (oversubscribed CPU and memory)
                                                              
+
                                                              The default value is cpu,memory.
                                                              
+
                                                              
+
                                                              
+
                                                            6. Deploy online and offline jobs.
                                                              The volcano.sh/qos-level label needs to be added to annotation to distinguish offline jobs. The value is an integer ranging from -7 to 7. If the value is less than 0, the job is an offline job. If the value is greater than or equal to 0, the job is a high-priority job, that is, online job. You do not need to set this label for online jobs. For both online and offline jobs, set schedulerName to volcano to enable the Volcano scheduler.
                                                              
+
                                                               
                                                              The priorities of online/online and offline/offline jobs are not differentiated, and the value validity is not verified. If the value of volcano.sh/qos-level of an offline job is not a negative integer ranging from -7 to 0, the job is processed as an online job.
                                                              
+
                                                              
+
                                                              For an offline job:
                                                              
+
                                                              kind: Deployment
 apiVersion: apps/v1
 spec:
   replicas: 4
@@ -494,8 +216,8 @@ spec:
     spec:
       schedulerName: volcano             # The Volcano scheduler is used.
       ...
                                                              
-        
                                                              For an online job:
                                                              
-        
                                                              kind: Deployment
+
                                                              For an online job:
                                                              
+
                                                              kind: Deployment
 apiVersion: apps/v1
 spec:
   replicas: 4
@@ -506,14 +228,8 @@ spec:
     spec:
       schedulerName: volcano          # The Volcano scheduler is used.
       ...
                                                              
-        
                                                              
-      
                                                              7. 
-      
                                                            7. Run the following command to check the number of oversubscribed
-          resources and the resource usage:
-        
                                                              
-        
                                                              kubectl describe node <nodeIP>
-        
                                                              
-        
                                                              # kubectl describe node 192.168.0.0
+
                                                            8. Run the following command to check the number of oversubscribed resources and the resource usage:
                                                              kubectl describe node <nodeIP>
                                                              
+
                                                              # kubectl describe node 192.168.0.0
 Name:             192.168.0.0
 Roles:              <none>
 Labels:           ...
@@ -530,41 +246,21 @@ Allocated resources:
   --------           --------      ------
   cpu                 4950m (126%)  4950m (126%)
   memory             1712Mi (27%)  1712Mi (27%)
                                                              
-        
                                                              
-      
                                                              9. 
-    
                                                            
-  
                                                          
-  
                                                          
-    
                                                          Hybrid Deployment Example
                                                          
-    
                                                          The following uses an example to describe how to deploy online and offline jobs
-      in hybrid mode.
                                                          
-    
                                                            
-      
                                                          1. Assume that a cluster has two nodes: one oversubscribed node and one
-          non-oversubscribed node.
-        
                                                            
-        
                                                            # kubectl get node
+
                                                          
+
                                                          
+
                                                          Hybrid Deployment Example
                                                          The following uses an example to describe how to deploy online and offline jobs in hybrid mode.
                                                          
+
                                                          1. Assume that a cluster has two nodes: one oversubscribed node and one non-oversubscribed node.
                                                            # kubectl get node
 NAME           STATUS   ROLES    AGE    VERSION
 192.168.0.173   Ready    <none>   4h58m   v1.19.16-r2-CCE22.5.1
 192.168.0.3     Ready    <none>   148m    v1.19.16-r2-CCE22.5.1
                                                            
-        
                                                              
-          
                                                            • 192.168.0.173 is an oversubscribed node (with the volcano.sh/oversubscirption=true label).
                                                              • 
-          
                                                            • 192.168.0.3 is a non-oversubscribed node (without the volcano.sh/oversubscirption=true label).
                                                              • 
-        
                                                            
-        
                                                            # kubectl describe node 192.168.0.173
+
                                                            • 192.168.0.173 is an oversubscribed node (with the volcano.sh/oversubscirption=true label).
                                                            • 192.168.0.3 is a non-oversubscribed node (without the volcano.sh/oversubscirption=true label).
                                                            
+
                                                            # kubectl describe node 192.168.0.173
 Name:               192.168.0.173
 Roles:              <none>
 Labels:             beta.kubernetes.io/arch=amd64
                     ...
                     volcano.sh/oversubscription=true
                                                            
-        
                                                            
-      
                                                            2. 
-      
                                                          2. Submit offline job creation requests. If resources are sufficient, all
-          offline jobs will be scheduled to the oversubscribed node.
-        
                                                            
-        
                                                            The offline job template is as follows:
-          
                                                            apiVersion: apps/v1
+
                                                          3. Submit offline job creation requests. If resources are sufficient, all offline jobs will be scheduled to the oversubscribed node.
                                                            The offline job template is as follows:
                                                            apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: offline
@@ -595,20 +291,13 @@ spec:
               memory: 512Mi
       imagePullSecrets:
         - name: default-secret
                                                            
-        
                                                            
-        
                                                            Offline jobs are scheduled to the oversubscribed node.
-          
                                                            # kubectl get pod -o wide
+
                                                            
+
                                                            Offline jobs are scheduled to the oversubscribed node.
                                                            # kubectl get pod -o wide
 NAME                      READY   STATUS   RESTARTS  AGE     IP             NODE 
 offline-69cdd49bf4-pmjp8   1/1    Running   0         5s    192.168.10.178   192.168.0.173
 offline-69cdd49bf4-z8kxh   1/1    Running   0         5s    192.168.10.131   192.168.0.173
                                                            
-        
                                                            
-        
                                                            
-      
                                                            4. 
-      
                                                          4. Submit online job creation requests. If resources are sufficient, the
-          online jobs will be scheduled to the non-oversubscribed node.
-        
                                                            
-        
                                                            The online job template is as follows:
-          
                                                            apiVersion: apps/v1
+
                                                            
+
                                                          5. Submit online job creation requests. If resources are sufficient, the online jobs will be scheduled to the non-oversubscribed node.
                                                            The online job template is as follows:
                                                            apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: online
@@ -637,20 +326,13 @@ spec:
               memory: 512Mi
       imagePullSecrets:
         - name: default-secret
                                                            
-        
                                                            
-        
                                                            Online jobs are scheduled to the non-oversubscribed node.
-          
                                                            # kubectl get pod -o wide
+
                                                            
+
                                                            Online jobs are scheduled to the non-oversubscribed node.
                                                            # kubectl get pod -o wide
 NAME                   READY   STATUS   RESTARTS  AGE     IP             NODE 
 online-ffb46f656-4mwr6  1/1    Running   0         5s    192.168.10.146   192.168.0.3
 online-ffb46f656-dqdv2   1/1    Running   0         5s    192.168.10.67   192.168.0.3
                                                            
-        
                                                            
-        
                                                            
-      
                                                            6. 
-      
                                                          6. Improve the resource usage of the oversubscribed node and observe whether
-          offline job eviction is triggered.
-        
                                                            
-        
                                                            Deploy online jobs to the oversubscribed node (192.168.0.173).
-          
                                                            apiVersion: apps/v1
+
                                                            
+
                                                          7. Improve the resource usage of the oversubscribed node and observe whether offline job eviction is triggered.
                                                            Deploy online jobs to the oversubscribed node (192.168.0.173).
                                                            apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: online
@@ -688,19 +370,15 @@ spec:
               memory: 512Mi
       imagePullSecrets:
         - name: default-secret
                                                            
-        
                                                            
-        
                                                            Submit the online or offline jobs to the oversubscribed node
-          (192.168.0.173) at the same time.
-          
                                                            # kubectl get pod -o wide
+
                                                            
+
                                                            Submit the online or offline jobs to the oversubscribed node (192.168.0.173) at the same time.
                                                            # kubectl get pod -o wide
 NAME                     READY   STATUS   RESTARTS  AGE     IP             NODE 
 offline-69cdd49bf4-pmjp8  1/1     Running    0      13m   192.168.10.178   192.168.0.173 
 offline-69cdd49bf4-z8kxh  1/1     Running     0      13m   192.168.10.131   192.168.0.173 
 online-6f44bb68bd-b8z9p  1/1     Running     0     3m4s   192.168.10.18   192.168.0.173 
 online-6f44bb68bd-g6xk8  1/1     Running     0     3m12s   192.168.10.69   192.168.0.173
                                                            
-        
                                                            
-        
                                                            Observe the oversubscribed node (192.168.0.173). You can find
-          that oversubscribed resources exist and the CPU allocation rate exceeds 100%.
-          
                                                            # kubectl describe node 192.168.0.173
+
                                                            
+
                                                            Observe the oversubscribed node (192.168.0.173). You can find that oversubscribed resources exist and the CPU allocation rate exceeds 100%.
                                                            # kubectl describe node 192.168.0.173
 Name:              192.168.0.173
 Roles:              <none>
 Labels:              …
@@ -716,10 +394,8 @@ Allocated resources:
   cpu                    4750m (121%)  7350m (187%)
   memory                 3760Mi (61%)  4660Mi (76%)
                          …
                                                            
-        
                                                            
-        
                                                            Increase the CPU usage of online jobs on the node. Offline job
-          eviction is triggered.
-          
                                                            # kubectl get pod -o wide
+
                                                            
+
                                                            Increase the CPU usage of online jobs on the node. Offline job eviction is triggered.
                                                            # kubectl get pod -o wide
 NAME                     READY   STATUS   RESTARTS  AGE     IP             NODE 
 offline-69cdd49bf4-bwdm7  1/1    Running   0       11m   192.168.10.208  192.168.0.3 
 offline-69cdd49bf4-pmjp8   0/1    Evicted    0       26m   <none>         192.168.0.173
@@ -727,34 +403,160 @@ offline-69cdd49bf4-qpdss   1/1     Running   0       11m   192.168.10.174  192.1
 offline-69cdd49bf4-z8kxh   0/1     Evicted    0       26m   <none>        192.168.0.173
 online-6f44bb68bd-b8z9p   1/1     Running   0       24m   192.168.10.18  192.168.0.173
 online-6f44bb68bd-g6xk8   1/1     Running   0       24m   192.168.10.69  192.168.0.173
                                                            
-        
                                                            
-        
                                                            
-      
                                                            8. 
-    
                                                          
-  
                                                          
-  
                                                          
-    
                                                          Handling Suggestions
                                                          
-    
                                                            
-      
                                                          • After kubelet of the oversubscribed node is restarted, the resource view of
-        the Volcano scheduler is not synchronized with that of kubelet. As a result, OutOfCPU occurs in some newly
-        scheduled jobs, which is normal. After a period of time, the Volcano scheduler can properly schedule online and
-        offline jobs.
                                                            • 
-      
                                                          • After online and offline jobs are submitted, you are not advised to
-        dynamically change the job type (adding or deleting annotation volcano.sh/qos-level: "-1") because the current
-        kernel does not support the change of an offline job to an online job.
                                                            • 
-      
                                                          • CCE collects the resource usage (CPU/memory) of all pods running on a node
-        based on the status information in the cgroups system. The resource usage may be different from the monitored
-        resource usage, for example, the resource statistics displayed by running the top command.
                                                            • 
-      
                                                          • You can add oversubscribed resources (such as CPU and memory) at any time.
                                                            You
-          can reduce the oversubscribed resource types only when the resource allocation rate does not exceed 100%.
                                                            
-      
                                                            • 
-    
                                                          
-  
                                                          
+
+
                                                          
+
+
                                                          1. Log in to the CCE console and access the cluster console.
                                                          2. In the navigation pane on the left, choose Nodes. Click the Node Pools tab. When creating or updating a node pool, enable hybrid deployment of online and offline services in Advanced Settings.
                                                            
+
                                                          3. In the navigation pane on the left, choose Add-ons. Click Install under volcano. In the Advanced Settings area, set colocation_enable to true to enable hybrid deployment of online and offline services. For details about the installation, see volcano.
                                                            If the volcano add-on has been installed, click Edit to view or modify the parameter colocation_enable.
                                                            
+
                                                            
+
                                                          4. Enable CPU Burst.
                                                            After confirming that the volcano add-on is working, run the following command to edit the parameter configmap of volcano-agent-configuration in the namespace kube-system. If enable is set to true, CPU Burst is enabled. If enable is set to false, CPU Burst is disabled.
                                                            kubectl edit configmap -nkube-system volcano-agent-configuration
                                                            
+
                                                            
+
                                                            Example:
                                                            
+
                                                            cpuBurstConfig: 
+  enable: true
                                                            
+
                                                          5. Deploy a workload in a node pool where hybrid deployment has been enabled. Take Nginx as an example. Set cpu under requests to 2 and cpu under limits to 4, and create a Service that can be accessed in the cluster for the workload.
                                                            apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx
+  namespace: default
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+      annotations: 
+        volcano.sh/enable-quota-burst=true
+        volcano.sh/quota-burst-time=200000
+    spec:
+      containers:
+      - name: container-1
+        image: nginx:latest
+        resources:
+          limits:
+            cpu: "4"
+          requests:
+            cpu: "2"
+      imagePullSecrets:
+        - name: default-secret
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  namespace: default
+  labels:
+    app: nginx
+spec:
+  selector:
+    app: nginx
+  ports:
+    - name: cce-service-0
+      targetPort: 80
+      nodePort: 0
+      port: 80
+      protocol: TCP
+  type: ClusterIP
                                                            
+
                                                            
+
                                                            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                            Annotation
                                                            
+
                                                            Mandatory
                                                            
+
                                                            Description
                                                            
+
                                                            volcano.sh/enable-quota-burst=true
                                                            
+
                                                            Yes
                                                            
+
                                                            CPU Burst is enabled for the workload.
                                                            
+
                                                            volcano.sh/quota-burst-time=200000
                                                            
+
                                                            No
                                                            
+
                                                            To ensure CPU scheduling stability and reduce contention when multiple containers encounter CPU bursts at the same time, the default CPU Burst value is the same as the CPU Quota value. That is, a container can use a maximum of twice the CPU Limit value. By default, CPU Burst is set for all service containers in a pod.
                                                            
+
                                                            In this example, the CPU Limit of the container is 4, that is, the default value is 400,000 (1 core = 100,000), indicating that a maximum of four additional cores can be used after the CPU Limit value is reached.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                          6. Verify CPU Burst.
                                                            You can use the wrk tool to increase load of the workload and observe the service latency, traffic limiting, and CPU limit exceeding when CPU Burst is enabled and disabled, respectively.
                                                            
+
                                                            1. Run the following command to increase load of the pod. $service_ip indicates the service IP address associated with the pod.
                                                              # You need to download and install the wrk tool on the node.
+# The Gzip compression module is enabled in the Apache configuration to simulate the computing logic for the server to process requests.
+# Run the following command to increase the load. Note that you need to change the IP address of the target application.
+wrk -H "Accept-Encoding: deflate, gzip" -t 4 -c 28 -d 120  --latency --timeout 2s http://$service_ip
                                                              
+
                                                            2. Obtain the pod ID.
                                                              kubectl get pods -n <namespace> <pod-name> -o jsonpath='{.metadata.uid}'
                                                              
+
                                                            3. You can run the following command on the node to view the traffic limiting status and CPU limit exceeding status. In the command, $PodID indicates the pod ID.
                                                              $cat /sys/fs/cgroup/cpuacct/kubepods/$PodID/cpu.stat
+nr_periods 0  # Number of scheduling periods
+nr_throttled 0  # Traffic limiting times
+throttled_time 0  # Traffic limiting duration (ns)
+nr_bursts 0 # CPU Limit exceeding times
+burst_time 0 # Total Limit exceeding duration
                                                              
+
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 3 Result summary in this example
                                                              CPU Burst
                                                              
+
                                                              P99 Latency
                                                              
+
                                                              nr_throttled
                                                              
+
                                                              Traffic Limiting Times
                                                              
+
                                                              throttled_time
                                                              
+
                                                              Traffic Limiting Duration
                                                              
+
                                                              nr_bursts
                                                              
+
                                                              Limit Exceeding Times
                                                              
+
                                                              bursts_time
                                                              
+
                                                              Total Limit Exceeding Duration
                                                              
+
                                                              CPU Burst not enabled
                                                              
+
                                                              2.96 ms
                                                              
+
                                                              986
                                                              
+
                                                              14.3s
                                                              
+
                                                              0
                                                              
+
                                                              0
                                                              
+
                                                              CPU Burst enabled
                                                              
+
                                                              456 µs
                                                              
+
                                                              0
                                                              
+
                                                              0
                                                              
+
                                                              469
                                                              
+
                                                              3.7s
                                                              
+
                                                              
+
                                                              
+
                                                            
+
                                                          
+
                                                          Handling Suggestions
                                                          • After kubelet of the oversubscribed node is restarted, the resource view of the Volcano scheduler is not synchronized with that of kubelet. As a result, OutOfCPU occurs in some newly scheduled jobs, which is normal. After a period of time, the Volcano scheduler can properly schedule online and offline jobs.
                                                          • After online and offline jobs are submitted, you are not advised to dynamically change the job type (adding or deleting annotation volcano.sh/qos-level: "-1") because the current kernel does not support the change of an offline job to an online job.
                                                          • CCE collects the resource usage (CPU/memory) of all pods running on a node based on the status information in the cgroups system. The resource usage may be different from the monitored resource usage, for example, the resource statistics displayed by running the top command.
                                                          • You can add oversubscribed resources (such as CPU and memory) at any time.
                                                            You can reduce the oversubscribed resource types only when the resource allocation rate does not exceed 100%.
                                                            
+
                                                          
+
                                                          
 
 
                                                          
-  
                                                          
-    
                                                          Parent topic: Volcano Scheduling
                                                          
-  
                                                          
-
                                                          
\ No newline at end of file
+
                                                          
+
                                                          Parent topic: Volcano Scheduling
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0385.html b/docs/cce/umn/cce_10_0385.html
index 5754de66..b4520445 100644
--- a/docs/cce/umn/cce_10_0385.html
+++ b/docs/cce/umn/cce_10_0385.html
@@ -22,7 +22,7 @@
 
 
                                                          Select a proper load balancer type.
                                                          
 
                                                          The value can be:
                                                          
-
                                                          • union: shared load balancer
                                                          • performance: dedicated load balancer, which can be used only in clusters of v1.17 and later.
                                                          
+
                                                          • union: shared load balancer
                                                          • performance: dedicated load balancer, which can be used only in clusters of v1.17 and later.
                                                          
                                                           		
 
                                                          performance
                                                          
 
                                                          
 
                                                          
 
-
                                                          Table 2 Data structure of the elb.autocreate field
                                                          Parameter
                                                          
+
                                                          
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -278,90 +278,90 @@
 
                                                          Table 2 Data structure of the elb.autocreate field
                                                          Parameter
                                                          
 
                                                          Mandatory
                                                          
+
                                                          Mandatory
                                                          
 
                                                          Type
                                                          
+
                                                          Type
                                                          
 
                                                          Description
                                                          
+
                                                          Description
                                                          
                                                           		
 
                                                          
 
                                                          name
                                                          
+
                                                          name
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Name of the load balancer that is automatically created.
                                                          
-
                                                          Value range: 1 to 64 characters, including lowercase letters, digits, and underscores (_). The value must start with a lowercase letter and end with a lowercase letter or digit.
                                                          
-
                                                          Default: cce-lb+service.UID
                                                          
+
                                                          Name of the load balancer that is automatically created.
                                                          
+
                                                          Value range: 1 to 64 characters, including lowercase letters, digits, and underscores (_). The value must start with a lowercase letter and end with a lowercase letter or digit.
                                                          
+
                                                          Default: cce-lb+service.UID
                                                          
                                                           		
 
                                                          type
                                                          
+
                                                          type
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Network type of the load balancer.
                                                          
-
                                                          • public: public network load balancer
                                                          • inner: private network load balancer
                                                          
-
                                                          Default: inner
                                                          
+
                                                          Network type of the load balancer.
                                                          
+
                                                          • public: public network load balancer
                                                          • inner: private network load balancer
                                                          
+
                                                          Default: inner
                                                          
                                                           		
 
                                                          bandwidth_name
                                                          
+
                                                          bandwidth_name
                                                          
 
                                                          Yes for public network load balancers
                                                          
+
                                                          Yes for public network load balancers
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Bandwidth name. The default value is cce-bandwidth-******.
                                                          
-
                                                          Value range: 1 to 64 characters, including lowercase letters, digits, and underscores (_). The value must start with a lowercase letter and end with a lowercase letter or digit.
                                                          
+
                                                          Bandwidth name. The default value is cce-bandwidth-******.
                                                          
+
                                                          Value range: 1 to 64 characters, including lowercase letters, digits, and underscores (_). The value must start with a lowercase letter and end with a lowercase letter or digit.
                                                          
                                                           		
 
                                                          bandwidth_chargemode
                                                          
+
                                                          bandwidth_chargemode
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Bandwidth mode.
                                                          
+
                                                          Bandwidth mode.
                                                          
 
                                                           		
 
                                                          bandwidth_size
                                                          
+
                                                          bandwidth_size
                                                          
 
                                                          Yes for public network load balancers
                                                          
+
                                                          Yes for public network load balancers
                                                          
 
                                                          Integer
                                                          
+
                                                          Integer
                                                          
 
                                                          Bandwidth size. The default value is 1 to 2000 Mbit/s. Set this parameter based on the bandwidth range allowed in your region.
                                                          
+
                                                          Bandwidth size. The default value is 1 to 2000 Mbit/s. Set this parameter based on the bandwidth range allowed in your region.
                                                          
                                                           		
 
                                                          bandwidth_sharetype
                                                          
+
                                                          bandwidth_sharetype
                                                          
 
                                                          Yes for public network load balancers
                                                          
+
                                                          Yes for public network load balancers
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Bandwidth sharing mode.
                                                          
-
                                                          • PER: dedicated bandwidth
                                                          
+
                                                          Bandwidth sharing mode.
                                                          
+
                                                          • PER: dedicated bandwidth
                                                          
                                                           		
 
                                                          eip_type
                                                          
+
                                                          eip_type
                                                          
 
                                                          Yes for public network load balancers
                                                          
+
                                                          Yes for public network load balancers
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          EIP type.
                                                          
-
                                                          • 5_bgp: dynamic BGP
                                                          • 5_sbgp: static BGP
                                                          
+
                                                          EIP type.
                                                          
+
                                                          • 5_bgp: dynamic BGP
                                                          • 5_sbgp: static BGP
                                                          
                                                           		
 
                                                          available_zone
                                                          
+
                                                          available_zone
                                                          
 
                                                          Yes
                                                          
+
                                                          Yes
                                                          
 
                                                          Array of strings
                                                          
+
                                                          Array of strings
                                                          
 
                                                          AZ where the load balancer is located.
                                                          
-
                                                          This parameter is available only for dedicated load balancers.
                                                          
+
                                                          AZ where the load balancer is located.
                                                          
+
                                                          This parameter is available only for dedicated load balancers.
                                                          
                                                           		
 
                                                          l4_flavor_name
                                                          
+
                                                          l4_flavor_name
                                                          
 
                                                          Yes
                                                          
+
                                                          Yes
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Flavor name of the layer-4 load balancer.
                                                          
-
                                                          This parameter is available only for dedicated load balancers.
                                                          
+
                                                          Flavor name of the layer-4 load balancer.
                                                          
+
                                                          This parameter is available only for dedicated load balancers.
                                                          
                                                           		
 
                                                          l7_flavor_name
                                                          
+
                                                          l7_flavor_name
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Flavor name of the layer-7 load balancer.
                                                          
-
                                                          This parameter is available only for dedicated load balancers.
                                                          
+
                                                          Flavor name of the layer-7 load balancer.
                                                          
+
                                                          This parameter is available only for dedicated load balancers.
                                                          
                                                           		
 
                                                          elb_virsubnet_ids
                                                          
+
                                                          elb_virsubnet_ids
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          Array of strings
                                                          
+
                                                          Array of strings
                                                          
 
                                                          Subnet where the backend server of the load balancer is located. If this parameter is left blank, the default cluster subnet is used. Load balancers occupy different number of subnet IP addresses based on their specifications. Therefore, you are not advised to use the subnet CIDR blocks of other resources (such as clusters and nodes) as the load balancer CIDR block.
                                                          
-
                                                          This parameter is available only for dedicated load balancers.
                                                          
-
                                                          Example:
                                                          
-
                                                          "elb_virsubnet_ids": [
+
                                                          Subnet where the backend server of the load balancer is located. If this parameter is left blank, the default cluster subnet is used. Load balancers occupy different number of subnet IP addresses based on their specifications. Therefore, you are not advised to use the subnet CIDR blocks of other resources (such as clusters and nodes) as the load balancer CIDR block.
                                                          
+
                                                          This parameter is available only for dedicated load balancers.
                                                          
+
                                                          Example:
                                                          
+
                                                          "elb_virsubnet_ids": [
    "14567f27-8ae4-42b8-ae47-9f847a4690dd"
  ]
                                                          
 
                                                          
 
                                                          
 
-
                                                          
-
@@ -84,17 +98,39 @@
 
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
@@ -107,8 +143,10 @@
 
                                                          Although Docker has added functions such as swarm cluster, docker build, and Docker APIs, it also introduces bugs. Compared with containerd, Docker has one more layer of calling. Therefore, containerd is more resource-saving and secure.
                                                          
-
                                                          Container Engine Version Description
                                                          • Docker
                                                            • EulerOS/CentOS: docker-engine 18.9.0, a Docker version customized for CCE. Security vulnerabilities will be fixed in a timely manner.
                                                            
-
                                                          • containerd: 1.4.1
                                                          
+
                                                          Container Engine Version Description
                                                          • Docker
                                                            • EulerOS/CentOS: docker 18.9.0, a Docker version customized for CCE. Security vulnerabilities will be fixed in a timely manner.
                                                            • Ubuntu 22.04: docker-ce 20.10.21 (community version).
                                                            
+
                                                             
                                                            • You are advised to use the containerd engine for Ubuntu nodes.
                                                            • The open source docker-ce of the Ubuntu 18.04 node may trigger bugs when concurrent exec operations are performed (for example, multiple exec probes are configured). You are advised to use HTTP/TCP probes.
                                                            
+
                                                            
+
                                                          • containerd: 1.6.14
                                                          
 
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_10_0468.html b/docs/cce/umn/cce_10_0468.html
index f2fd49d2..2c2092a6 100644
--- a/docs/cce/umn/cce_10_0468.html
+++ b/docs/cce/umn/cce_10_0468.html
@@ -2,12 +2,12 @@
 
 
                                                          CCE Kubernetes 1.23 Release Notes
                                                          
 
                                                          CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.23.
                                                          
-
                                                          Resource Changes and Deprecations
                                                          Changes in CCE 1.23
                                                          
-
                                                          • The web-terminal add-on is no longer supported. Use CloudShell or kubectl instead.
                                                          
-
                                                          Kubernetes 1.23 Release Notes
                                                          
+
                                                          Resource Changes and Deprecations
                                                          Changes in CCE 1.23
                                                          
+
                                                          • The web-terminal add-on is no longer supported. Use kubectl instead.
                                                          
+
                                                          Kubernetes 1.23 Release Notes
                                                          
 
                                                          • FlexVolume is deprecated. Use CSI.
                                                          • HorizontalPodAutoscaler v2 is promoted to GA, and HorizontalPodAutoscaler API v2 is gradually stable in version 1.23. The HorizontalPodAutoscaler v2beta2 API is not recommended. Use the v2 API.
                                                          • PodSecurity moves to beta, replacing the deprecated PodSecurityPolicy. PodSecurity is an admission controller that enforces pod security standards on pods in the namespace based on specific namespace labels that set the enforcement level. PodSecurity is enabled by default in version 1.23.
                                                          
-
                                                          Kubernetes 1.22 Release Notes
                                                          
-
                                                          • Ingresses no longer support networking.k8s.io/v1beta1 and extensions/v1beta1 APIs. If you use the API of an earlier version to manage ingresses, an application cannot be exposed to external services. Use networking.k8s.io/v1.
                                                          • CustomResourceDefinitions no longer support the apiextensions.k8s.io/v1beta1 API. If you use the API of an earlier version to create a CRD, the creation will fail, which affects the controller that reconciles this CRD. Use apiextensions.k8s.io/v1.
                                                          • ClusterRoles, ClusterRoleBindings, Roles, and RoleBindings no longer support the rbac.authorization.k8s.io/v1beta1 API. If you use the API of an earlier version to manage RBAC resources, application permissions control is affected and even cannot work in the cluster. Use rbac.authorization.k8s.io/v1.
                                                          • The Kubernetes release cycle is changed from four releases a year to three releases a year.
                                                          • StatefulSets support minReadySeconds.
                                                          • During scale-in, pods are randomly selected and deleted based on the pod UID by default (LogarithmicScaleDown). This feature enhances the randomness of the pods to be deleted and alleviates the problems caused by pod topology spread constraints. For more information, see KEP-2185 and issue 96748.
                                                          • The BoundServiceAccountTokenVolume feature is stable. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default.
                                                            
+
                                                            Kubernetes 1.22 Release Notes
                                                            
+
                                                            • Ingresses no longer support networking.k8s.io/v1beta1 and extensions/v1beta1 APIs. If you use the API of an earlier version to manage ingresses, an application cannot be exposed to external services. Use networking.k8s.io/v1.
                                                            • CustomResourceDefinitions no longer support the apiextensions.k8s.io/v1beta1 API. If you use the API of an earlier version to create a CRD, the creation will fail, which affects the controller that reconciles this CRD. Use apiextensions.k8s.io/v1.
                                                            • ClusterRoles, ClusterRoleBindings, Roles, and RoleBindings no longer support the rbac.authorization.k8s.io/v1beta1 API. If you use the API of an earlier version to manage RBAC resources, application permissions control is affected and even cannot work in the cluster. Use rbac.authorization.k8s.io/v1.
                                                            • The Kubernetes release cycle is changed from four releases a year to three releases a year.
                                                            • StatefulSets support minReadySeconds.
                                                            • During scale-in, pods are randomly selected and deleted based on the pod UID by default (LogarithmicScaleDown). This feature enhances the randomness of the pods to be deleted and alleviates the problems caused by pod topology spread constraints. For more information, see KEP-2185 and issue 96748.
                                                            • The BoundServiceAccountTokenVolume feature is stable. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default.
                                                              
 
                                                            
 
                                                          
 
                                                          References
                                                          For more details about the performance comparison and function evolution between Kubernetes 1.23 and other versions, see the following documents:
                                                          
diff --git a/docs/cce/umn/cce_10_0469.html b/docs/cce/umn/cce_10_0469.html
index 5e120710..6ec5816a 100644
--- a/docs/cce/umn/cce_10_0469.html
+++ b/docs/cce/umn/cce_10_0469.html
@@ -3,7 +3,7 @@
 
                                                          CCE Kubernetes 1.21 Release Notes
                                                          
 
                                                          CCE has passed the Certified Kubernetes Conformance Program and is a certified Kubernetes offering. This section describes the updates in CCE Kubernetes 1.21.
                                                          
 
                                                          Resource Changes and Deprecations
                                                          Kubernetes 1.21 Release Notes
                                                          
-
                                                          • CronJob is now in the stable state, and the version number changes to batch/v1.
                                                          • The immutable Secret and ConfigMap have now been upgraded to the stable state. A new immutable field is added to these objects to reject changes. The rejection protects clusters from accidental updates that may cause application outages. As these resources are immutable, kubelet does not monitor or poll for changes. This reduces the load of kube-apiserver and improves scalability and performance of your clusters. For more information, see Immutable ConfigMaps.
                                                          • Graceful node shutdown has been upgraded to the test state. With this update, kubelet can detect that a node is shut down and gracefully terminate the pods on the node. Prior to this update, when the node was shut down, its pod did not follow the expected termination lifecycle, which caused workload problems. Now kubelet can use systemd to detect the systems that are about to be shut down and notify the running pods to terminate them gracefully.
                                                          • For a pod with multiple containers, you can use kubectl.kubernetes.io/ to pre-select containers.
                                                          • PodSecurityPolicy is deprecated. For details, see https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/.
                                                          • The BoundServiceAccountTokenVolume feature has entered the beta test. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default.
                                                          
+
                                                          • CronJob is now in the stable state, and the version number changes to batch/v1.
                                                          • The immutable Secret and ConfigMap have now been upgraded to the stable state. A new immutable field is added to these objects to reject changes. The rejection protects clusters from accidental updates that may cause application outages. As these resources are immutable, kubelet does not monitor or poll for changes. This reduces the load of kube-apiserver and improves scalability and performance of your clusters. For more information, see Immutable ConfigMaps.
                                                          • Graceful node shutdown has been upgraded to the test state. With this update, kubelet can detect that a node is shut down and gracefully terminate the pods on the node. Prior to this update, when the node was shut down, its pod did not follow the expected termination lifecycle, which caused workload problems. Now kubelet can use systemd to detect the systems that are about to be shut down and notify the running pods to terminate them gracefully.
                                                          • For a pod with multiple containers, you can use kubectl.kubernetes.io/ to pre-select containers.
                                                          • PodSecurityPolicy is deprecated. For details, see https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/.
                                                          • The BoundServiceAccountTokenVolume feature has entered the beta test. This feature improves the token security of the service account and changes the method of mounting tokens to pods. Kubernetes clusters of v1.21 and later enable this approach by default.
                                                          
 
                                                          Kubernetes 1.20 Release Notes
                                                          
 
                                                          • The API priority and fairness have reached the test state and are enabled by default. This allows kube-apiserver to classify incoming requests by priority. For more information, see API Priority and Fairness.
                                                          • The bug of exec probe timeouts is fixed. Before this bug is fixed, the exec probe does not consider the timeoutSeconds field. Instead, the probe will run indefinitely, even beyond its configured deadline. It will stop until the result is returned. Now, if no value is specified, the default value is used, that is, one second. If the detection time exceeds one second, the application health check may fail. Update the timeoutSeconds field for the applications that use this feature during the upgrade. The repair provided by the newly introduced ExecProbeTimeout feature gating enables the cluster operator to restore the previous behavior, but this behavior will be locked and removed in later versions.
                                                          • RuntimeClass enters the stable state. RuntimeClass provides a mechanism to support multiple runtimes in a cluster and expose information about the container runtime to the control plane.
                                                          • kubectl debugging has reached the test state. kubectl debugging provides support for common debugging workflows.
                                                          • Dockershim was marked as deprecated in Kubernetes 1.20. Currently, you can continue to use Docker in the cluster. This change is irrelevant to the container image used by clusters. You can still use Docker to build your images. For more information, see Dockershim Deprecation FAQ.
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_10_0477.html b/docs/cce/umn/cce_10_0477.html
index e2153637..1c833e3c 100644
--- a/docs/cce/umn/cce_10_0477.html
+++ b/docs/cce/umn/cce_10_0477.html
@@ -1,23 +1,23 @@
 
 
 
                                                          Service Account Token Security Improvement
                                                          
-
                                                          In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25.
                                                          
-
                                                          In clusters of version 1.21 or later, you can use the TokenRequest API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period (one hour by default). Before expiration, Kubelet refreshes the token to ensure that the pod always uses a valid token. When the mounting pod is deleted, the token automatically becomes invalid. This approach is implemented by the BoundServiceAccountTokenVolume feature to improve the token security of the service account. Kubernetes clusters of v1.21 and later enables this approach by default.
                                                          
-
                                                          For smooth transition, the community extends the token validity period to one year by default. After one year, the token becomes invalid, and clients that do not support certificate reloading cannot access the API server. It is recommended that clients of earlier versions be upgraded as soon as possible. Otherwise, service faults may occur.
                                                          
-
                                                          If you use a Kubernetes client of a to-be-outdated version, the certificate reloading may fail. Versions of officially supported Kubernetes client libraries able to reload tokens are as follows:
                                                          
-
                                                          • Go: >= v0.15.7
                                                          • Python: >= v12.0.0
                                                          • Java: >= v9.0.0
                                                          • Javascript: >= v0.10.3
                                                          • Ruby: master branch
                                                          • Haskell: v0.3.0.0
                                                          • C#: >= 7.0.5
                                                          
-
                                                          For details, visit https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens.
                                                          
-
                                                           
                                                          If you need a token that never expires, you can also manually manage secrets for service accounts. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the TokenRequest API for higher security.
                                                          
+
                                                          In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25.
                                                          
+
                                                          In clusters of version 1.21 or later, you can use the TokenRequest API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period (one hour by default). Before expiration, Kubelet refreshes the token to ensure that the pod always uses a valid token. When the mounting pod is deleted, the token automatically becomes invalid. This approach is implemented by the BoundServiceAccountTokenVolume feature to improve the token security of the service account. Kubernetes clusters of v1.21 and later enables this approach by default.
                                                          
+
                                                          For smooth transition, the community extends the token validity period to one year by default. After one year, the token becomes invalid, and clients that do not support certificate reloading cannot access the API server. It is recommended that clients of earlier versions be upgraded as soon as possible. Otherwise, service faults may occur.
                                                          
+
                                                          If you use a Kubernetes client of a to-be-outdated version, the certificate reloading may fail. Versions of officially supported Kubernetes client libraries able to reload tokens are as follows:
                                                          
+
                                                          • Go: >= v0.15.7
                                                          • Python: >= v12.0.0
                                                          • Java: >= v9.0.0
                                                          • Javascript: >= v0.10.3
                                                          • Ruby: master branch
                                                          • Haskell: v0.3.0.0
                                                          • C#: >= 7.0.5
                                                          
+
                                                          For details, visit https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens.
                                                          
+
                                                           
                                                          If you need a token that never expires, you can also manually manage secrets for service accounts. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the TokenRequest API for higher security.
                                                          
 
                                                          
-
                                                          Diagnosis
                                                          Run the following steps to check your CCE clusters of v1.21 and later:
                                                          
-
                                                          1. Use kubectl to connect to the cluster and run the kubectl get --raw "/metrics" | grep stale command to query the metrics. Check the metric named serviceaccount_stale_tokens_total.
                                                            If the value is greater than 0, some workloads in the cluster may be using an earlier client-go version. In this case, check whether this problem occurs in your deployed applications. If yes, upgrade client-go to the version specified by the community as soon as possible. The version must be at least two major versions of the CCE cluster. For example, if your cluster version is 1.23, the Kubernetes dependency library version must be at least 1.19.
                                                            
-
                                                            
+
                                                            Diagnosis
                                                            Run the following steps to check your CCE clusters of v1.21 and later:
                                                            
+
                                                            1. Use kubectl to connect to the cluster and run the kubectl get --raw "/metrics" | grep stale command to query the metrics. Check the metric named serviceaccount_stale_tokens_total.
                                                              If the value is greater than 0, some workloads in the cluster may be using an earlier client-go version. In this case, check whether this problem occurs in your deployed applications. If yes, upgrade client-go to the version specified by the community as soon as possible. The version must be at least two major versions of the CCE cluster. For example, if your cluster version is 1.23, the Kubernetes dependency library version must be at least 1.19.
                                                              
+
                                                              
 
                                                            
 
                                                            
 
                                                          
 
                                                          
 
                                                          
-
                                                          Parent topic: Product Bulletin
                                                          
+
                                                          Parent topic: Permissions Management
                                                          
 
                                                          
 
                                                          
 
diff --git a/docs/cce/umn/cce_10_0477_0.html b/docs/cce/umn/cce_10_0477_0.html
deleted file mode 100644
index 53c90ce8..00000000
--- a/docs/cce/umn/cce_10_0477_0.html
+++ /dev/null
@@ -1,23 +0,0 @@
-
-
-
                                                          Service Account Token Security Improvement
                                                          
-
                                                          In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25.
                                                          
-
                                                          In clusters of version 1.21 or later, you can use the TokenRequest API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period (one hour by default). Before expiration, Kubelet refreshes the token to ensure that the pod always uses a valid token. When the mounting pod is deleted, the token automatically becomes invalid. This approach is implemented by the BoundServiceAccountTokenVolume feature to improve the token security of the service account. Kubernetes clusters of v1.21 and later enables this approach by default.
                                                          
-
                                                          For smooth transition, the community extends the token validity period to one year by default. After one year, the token becomes invalid, and clients that do not support certificate reloading cannot access the API server. It is recommended that clients of earlier versions be upgraded as soon as possible. Otherwise, service faults may occur.
                                                          
-
                                                          If you use a Kubernetes client of a to-be-outdated version, the certificate reloading may fail. Versions of officially supported Kubernetes client libraries able to reload tokens are as follows:
                                                          
-
                                                          • Go: >= v0.15.7
                                                          • Python: >= v12.0.0
                                                          • Java: >= v9.0.0
                                                          • Javascript: >= v0.10.3
                                                          • Ruby: master branch
                                                          • Haskell: v0.3.0.0
                                                          • C#: >= 7.0.5
                                                          
-
                                                          For details, visit https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens.
                                                          
-
                                                           
                                                          If you need a token that never expires, you can also manually manage secrets for service accounts. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the TokenRequest API for higher security.
                                                          
-
                                                          
-
                                                          Diagnosis
                                                          Run the following steps to check your CCE clusters of v1.21 and later:
                                                          
-
                                                          1. Use kubectl to connect to the cluster and run the kubectl get --raw "/metrics" | grep stale command to query the metrics. Check the metric named serviceaccount_stale_tokens_total.
                                                            If the value is greater than 0, some workloads in the cluster may be using an earlier client-go version. In this case, check whether this problem occurs in your deployed applications. If yes, upgrade client-go to the version specified by the community as soon as possible. The version must be at least two major versions of the CCE cluster. For example, if your cluster version is 1.23, the Kubernetes dependency library version must be at least 1.19.
                                                            
-
                                                            
-
                                                          
-
                                                          
-
                                                          
-
                                                          
-
                                                          
-
                                                          Parent topic: Permissions Management
                                                          
-
                                                          
-
                                                          
-
diff --git a/docs/cce/umn/cce_10_0478.html b/docs/cce/umn/cce_10_0478.html
new file mode 100644
index 00000000..9cc6e37c
--- /dev/null
+++ b/docs/cce/umn/cce_10_0478.html
@@ -0,0 +1,30 @@
+
+
+
                                                          everest Restriction Check
                                                          
+
                                                          Check Item
                                                          Check whether the current everest add-on has compatibility restrictions. See Table 1.
                                                          
+
+
                                                          Table 3 Data structure description of the elb.health-check-option field
                                                          Parameter
                                                          
+
                                                          
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
                                                          Table 3 Data structure description of the elb.health-check-option field
                                                          Parameter
                                                          
 
                                                          Mandatory
                                                          
+
                                                          Mandatory
                                                          
 
                                                          Type
                                                          
+
                                                          Type
                                                          
 
                                                          Description
                                                          
+
                                                          Description
                                                          
                                                           		
 
                                                          
 
                                                          delay
                                                          
+
                                                          delay
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Initial waiting time (in seconds) for starting the health check.
                                                          
-
                                                          Value range: 1 to 50. Default value: 5
                                                          
+
                                                          Initial waiting time (in seconds) for starting the health check.
                                                          
+
                                                          Value range: 1 to 50. Default value: 5
                                                          
                                                           		
 
                                                          timeout
                                                          
+
                                                          timeout
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Health check timeout, in seconds.
                                                          
-
                                                          Value range: 1 to 50. Default value: 10
                                                          
+
                                                          Health check timeout, in seconds.
                                                          
+
                                                          Value range: 1 to 50. Default value: 10
                                                          
                                                           		
 
                                                          max_retries
                                                          
+
                                                          max_retries
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Maximum number of health check retries.
                                                          
-
                                                          Value range: 1 to 10. Default value: 3
                                                          
+
                                                          Maximum number of health check retries.
                                                          
+
                                                          Value range: 1 to 10. Default value: 3
                                                          
                                                           		
 
                                                          protocol
                                                          
+
                                                          protocol
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Health check protocol.
                                                          
-
                                                          Default value: protocol of the associated Service
                                                          
-
                                                          Value options: TCP, UDP, or HTTP
                                                          
+
                                                          Health check protocol.
                                                          
+
                                                          Default value: protocol of the associated Service
                                                          
+
                                                          Value options: TCP, UDP, or HTTP
                                                          
                                                           		
 
                                                          path
                                                          
+
                                                          path
                                                          
 
                                                          No
                                                          
+
                                                          No
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Health check URL. This parameter needs to be configured when the protocol is HTTP.
                                                          
-
                                                          Default value: /
                                                          
-
                                                          The value can contain 1 to 10,000 characters.
                                                          
+
                                                          Health check URL. This parameter needs to be configured when the protocol is HTTP.
                                                          
+
                                                          Default value: /
                                                          
+
                                                          The value can contain 1 to 10,000 characters.
                                                          
                                                           		
 
                                                          
                                                           
 
                                                          
 
                                                          
 
-
                                                          
+
+
+
+
+
+
                                                          Table 4 Data structure of the elb.session-affinity-option field
                                                          Parameter
                                                          
+
                                                          
-
-
-
-
-
-
-
diff --git a/docs/cce/umn/cce_10_0388.html b/docs/cce/umn/cce_10_0388.html
index cd534ae4..42e2def0 100644
--- a/docs/cce/umn/cce_10_0388.html
+++ b/docs/cce/umn/cce_10_0388.html
@@ -57,7 +57,7 @@ Events:              <none>
                                                          
 
                                                          
-
                                                          Parent topic: Configuration Center
                                                          
+
                                                          Parent topic: ConfigMaps and Secrets
                                                          
 
                                                          
 
                                                          
 
diff --git a/docs/cce/umn/cce_10_0400.html b/docs/cce/umn/cce_10_0400.html
index 69b75ac7..3b74e67f 100644
--- a/docs/cce/umn/cce_10_0400.html
+++ b/docs/cce/umn/cce_10_0400.html
@@ -1,23 +1,23 @@
 
                                                          Accessing Public Networks from a Container
                                                          
-
                                                          Containers can access public networks in either of the following ways:
                                                          
-
                                                          • Bind a public IP address to the node where the container is located if the network model is VPC network or tunnel network.
                                                          • Bind a public IP address to the pod. (When the Cloud Native Network 2.0 model is used, manually bind an EIP to the ENI or sub-ENI of the pod on the VPC console. This method is not recommended because the IP address of a pod changes after the pod is rescheduled. As a result, the new pod cannot access the public network.)
                                                          • Configure SNAT rules through NAT Gateway.
                                                          
-
                                                          You can use NAT Gateway to enable container pods in a VPC to access public networks. NAT Gateway provides source network address translation (SNAT), which translates private IP addresses to a public IP address by binding an elastic IP address (EIP) to the gateway, providing secure and efficient access to the Internet. Figure 1 shows the SNAT architecture. The SNAT function allows the container pods in a VPC to access the Internet without being bound to an EIP. SNAT supports a large number of concurrent connections, which makes it suitable for applications involving a large number of requests and connections.
                                                          
-
                                                          Figure 1 SNAT
                                                          
-
                                                          To enable a container pod to access the Internet, perform the following steps:
                                                          
-
                                                          1. Assign an EIP.
                                                            1. Log in to the management console.
                                                            2. Click  in the upper left corner of the management console and select a region and a project.
                                                            3. Click  at the upper left corner and choose Networking > Elastic IP in the expanded list.
                                                            4. On the EIPs page, click Create EIP.
                                                            5. Set parameters as required.
                                                               
                                                              Set Region to the region where container pods are located.
                                                              
+
                                                              Containers can access public networks in either of the following ways:
                                                              
+
                                                              • Bind a public IP address to the node where the container is located if the network model is VPC network or tunnel network.
                                                              • Bind a public IP address to the pod. (When the Cloud Native Network 2.0 model is used, manually bind an EIP to the ENI or sub-ENI of the pod on the VPC console. This method is not recommended because the IP address of a pod changes after the pod is rescheduled. As a result, the new pod cannot access the public network.)
                                                              • Configure SNAT rules through NAT Gateway.
                                                              
+
                                                              You can use NAT Gateway to enable container pods in a VPC to access public networks. NAT Gateway provides source network address translation (SNAT), which translates private IP addresses to a public IP address by binding an elastic IP address (EIP) to the gateway, providing secure and efficient access to the Internet. Figure 1 shows the SNAT architecture. The SNAT function allows the container pods in a VPC to access the Internet without being bound to an EIP. SNAT supports a large number of concurrent connections, which makes it suitable for applications involving a large number of requests and connections.
                                                              
+
                                                              Figure 1 SNAT
                                                              
+
                                                              To enable a container pod to access the Internet, perform the following steps:
                                                              
+
                                                              1. Assign an EIP.
                                                                1. Log in to the management console.
                                                                2. Click  in the upper left corner of the management console and select a region and a project.
                                                                3. Click  at the upper left corner and choose Networking > Elastic IP in the expanded list.
                                                                4. On the EIPs page, click Create EIP.
                                                                5. Set parameters as required.
                                                                   
                                                                  Set Region to the region where container pods are located.
                                                                  
 
                                                                  
 
                                                                
-
                                                              2. Create a NAT gateway.
                                                                1. Log in to the management console.
                                                                2. Click  in the upper left corner of the management console and select a region and a project.
                                                                3. Click  at the upper left corner and choose Networking > NAT Gateway in the expanded list.
                                                                4. On the displayed page, click Create Public NAT Gateway in the upper right corner.
                                                                5. Set parameters as required.
                                                                   
                                                                  Select the same VPC.
                                                                  
+
                                                                6. Create a NAT gateway.
                                                                  1. Log in to the management console.
                                                                  2. Click  in the upper left corner of the management console and select a region and a project.
                                                                  3. Click  at the upper left corner and choose Networking > NAT Gateway in the expanded list.
                                                                  4. On the displayed page, click Create Public NAT Gateway in the upper right corner.
                                                                  5. Set parameters as required.
                                                                     
                                                                    Select the same VPC.
                                                                    
 
                                                                    
 
                                                                  
-
                                                                7. Configure an SNAT rule and bind the EIP to the subnet.
                                                                  1. Log in to the management console.
                                                                  2. Click  in the upper left corner of the management console and select a region and a project.
                                                                  3. Click  at the upper left corner and choose Networking > NAT Gateway in the expanded list.
                                                                  4. On the page displayed, click the name of the NAT gateway for which you want to add the SNAT rule.
                                                                  5. On the SNAT Rules tab page, click Add SNAT Rule.
                                                                  6. Set parameters as required.
                                                                  
-
                                                                   
                                                                  SNAT rules take effect by CIDR block. As different container network models use different communication modes, the subnet needs to be selected according to the following rules:
                                                                  
-
                                                                  • Tunnel network and VPC network: Select the subnet where the node is located, that is, the subnet selected during node creation.
                                                                  
-
                                                                  If there are multiple CIDR blocks, you can create multiple SNAT rules or customize a CIDR block as long as the CIDR block contains the node subnet.
                                                                  
+
                                                                8. Configure an SNAT rule and bind the EIP to the subnet.
                                                                  1. Log in to the management console.
                                                                  2. Click  in the upper left corner of the management console and select a region and a project.
                                                                  3. Click  at the upper left corner and choose Networking > NAT Gateway in the expanded list.
                                                                  4. On the page displayed, click the name of the NAT gateway for which you want to add the SNAT rule.
                                                                  5. On the SNAT Rules tab page, click Add SNAT Rule.
                                                                  6. Set parameters as required.
                                                                  
+
                                                                   
                                                                  SNAT rules take effect by CIDR block. As different container network models use different communication modes, the subnet needs to be selected according to the following rules:
                                                                  
+
                                                                  • Tunnel network and VPC network: Select the subnet where the node is located, that is, the subnet selected during node creation.
                                                                  
+
                                                                  If there are multiple CIDR blocks, you can create multiple SNAT rules or customize a CIDR block as long as the CIDR block contains the node subnet.
                                                                  
 
                                                                  
-
                                                                  After the SNAT rule is configured, workloads can access public networks from the container. Public networks can be pinged from the container.
                                                                  
+
                                                                  After the SNAT rule is configured, workloads can access public networks from the container. Public networks can be pinged from the container.
                                                                  
 
                                                                
 
                                                              
 
                                                              
diff --git a/docs/cce/umn/cce_10_0403.html b/docs/cce/umn/cce_10_0403.html
index 51c352b8..48a5d546 100644
--- a/docs/cce/umn/cce_10_0403.html
+++ b/docs/cce/umn/cce_10_0403.html
@@ -5,7 +5,7 @@
 
                                                              
 
                                                              Notes and Constraints
                                                              • This function is supported for clusters of v1.15 and later versions.
                                                              • Starting from v1.15.11, the number of nodes in a cluster can be changed to 2000. The number of nodes in a single master node cannot be changed to 1000 or more.
                                                              • Currently, a cluster can only be scaled out to a larger specification, but cannot be scaled in.
                                                              • During the specifications change, master nodes will be powered off and on, and the cluster cannot run properly. Perform the change during off-peak hours.
                                                              • Changing the cluster scale does not affect the services running in the cluster. However, the control plane (master nodes) will be interrupted for a short period of time. You are advised not to perform any other operations (such as creating workloads) during the change.
                                                              • Change failures will trigger a cluster rollback to the normal state. If the rollback fails, submit a service ticket.
                                                              
 
                                                              
-
                                                              Procedure
                                                              1. Log in to the CCE console. In the navigation pane, choose Clusters.
                                                              2. Click  next to the cluster whose specifications need to be changed.
                                                              3. On the page displayed, select a new flavor for Target Flavor as required.
                                                              4. Click OK.
                                                                You can click Operation Records in the upper left corner to view the cluster change history. The status changes from Executing to Successful, indicating that the cluster specifications are successfully changed.
                                                                
+
                                                                Procedure
                                                                1. Log in to the CCE console. In the navigation pane, choose Clusters.
                                                                2. Click  next to the cluster whose specifications need to be changed.
                                                                3. On the page displayed, select a new flavor for Target Flavor as required.
                                                                4. Click OK.
                                                                  You can click Operation Records in the upper left corner to view the cluster change history. The status changes from Executing to Successful, indicating that the cluster specifications are successfully changed.
                                                                  
 
                                                                
 
                                                                
 
                                                              
diff --git a/docs/cce/umn/cce_10_0430.html b/docs/cce/umn/cce_10_0430.html
index 15d8d07a..94c0ce34 100644
--- a/docs/cce/umn/cce_10_0430.html
+++ b/docs/cce/umn/cce_10_0430.html
@@ -1,17 +1,19 @@
 
 
 
                                                              Basic Cluster Information
                                                              
-
                                                              Kubernetes allows you to easily deploy and manage containerized application and facilitates container scheduling and orchestration.
                                                              
+
                                                              Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications.
                                                              
 
                                                              For developers, Kubernetes is a cluster operating system. Kubernetes provides service discovery, scaling, load balancing, self-healing, and even leader election, freeing developers from infrastructure-related configurations.
                                                              
 
                                                              When using Kubernetes, it is like you run a large number of servers as one and the method for deploying applications in Kubernetes is always the same.
                                                              
-
                                                              Kubernetes Cluster Architecture
                                                              A Kubernetes cluster consists of master nodes (Masters) and worker nodes (Nodes). Applications are deployed on worker nodes, and you can specify the nodes for deployment.
                                                              
+
                                                              Kubernetes Cluster Architecture
                                                              A Kubernetes cluster consists of master nodes (Masters) and worker nodes (Nodes). Applications are deployed on worker nodes, and you can specify the nodes for deployment.
                                                              
+
                                                               
                                                              For a cluster created on CCE, the master node is hosted by CCE. You only need to create a node.
                                                              
+
                                                              
 
                                                              The following figure shows the architecture of a Kubernetes cluster.
                                                              
-
                                                              Figure 1 Kubernetes cluster architecture
                                                              
-
                                                              Master node
                                                              
+
                                                              Figure 1 Kubernetes cluster architecture
                                                              
+
                                                              Master node
                                                              
 
                                                              A master node is the machine where the control plane components run, including API server, Scheduler, Controller manager, and etcd.
                                                              
 
                                                              • API server: functions as a transit station for components to communicate with each other, receives external requests, and writes information to etcd.
                                                              • Controller manager: performs cluster-level functions, such as component replication, node tracing, and node fault fixing.
                                                              • Scheduler: schedules containers to nodes based on various conditions (such as available resources and node affinity).
                                                              • etcd: serves as a distributed data storage component that stores cluster configuration information.
                                                              
 
                                                              In a production environment, multiple master nodes are deployed to ensure high cluster availability. For example, you can deploy three master nodes for your CCE cluster.
                                                              
-
                                                              Worker node
                                                              
+
                                                              Worker node
                                                              
 
                                                              A worker node is a compute node in a cluster, that is, a node running containerized applications. A worker node has the following components:
                                                              
 
                                                              • kubelet: communicates with the container runtime, interacts with the API server, and manages containers on the node.
                                                              • kube-proxy: serves as an access proxy between application components.
                                                              • Container runtime: functions as the software for running containers. You can download images to build your container runtime, such as Docker.
                                                              
 
                                                              
diff --git a/docs/cce/umn/cce_10_0431.html b/docs/cce/umn/cce_10_0431.html
new file mode 100644
index 00000000..ca22ece5
--- /dev/null
+++ b/docs/cce/umn/cce_10_0431.html
@@ -0,0 +1,49 @@
+
+
+
                                                              Checking the Node
                                                              
+
                                                              Check Item
                                                              Check the following aspects:
                                                              
+
                                                              • Check whether the node is available. 
                                                              • Check whether the node OS supports the upgrade.
                                                              • Check whether there are unexpected node pool tags in the node.
                                                              • Check whether the Kubernetes node name is consistent with the ECS name.
                                                              
+
                                                              
+
                                                              Solution
                                                              • Scenario 1: The node is unavailable.
                                                                Log in to the CCE console and access the cluster console. Choose Nodes in the navigation pane and check the node status. Ensure that the node is in the Running status. A node in the Installing or Deleting status cannot be upgraded.
                                                                
+
                                                                If the node status is abnormal, restore the node by referring to  and retry the check task.
                                                                
+
                                                                
+
                                                              • Scenario 2: The node OS does not support the upgrade.
                                                                The following table lists the node OSs that support the upgrade. You can reset the node OS to an available OS in the list.
                                                                
+
+
                                                          Table 4 Data structure of the elb.session-affinity-option field
                                                          Parameter
                                                          
 
                                                          Mandatory
                                                          
+
                                                          Mandatory
                                                          
 
                                                          Type
                                                          
+
                                                          Type
                                                          
 
                                                          Description
                                                          
+
                                                          Description
                                                          
                                                           		
 
                                                          
 
                                                          persistence_timeout
                                                          
+
                                                          persistence_timeout
                                                          
 
                                                          Yes
                                                          
+
                                                          Yes
                                                          
 
                                                          String
                                                          
+
                                                          String
                                                          
 
                                                          Sticky session timeout, in minutes. This parameter is valid only when elb.session-affinity-mode is set to SOURCE_IP.
                                                          
-
                                                          Value range: 1 to 60. Default value: 60
                                                          
+
                                                          Sticky session timeout, in minutes. This parameter is valid only when elb.session-affinity-mode is set to SOURCE_IP.
                                                          
+
                                                          Value range: 1 to 60. Default value: 60
                                                          
                                                           		
 
                                                          
                                                           
 
 
 
 
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 OSs that support the upgrade
                                                          OS
                                                          
+
                                                          Restriction
                                                          
+
                                                          EulerOS 2.5/2.9
                                                          
+
                                                          None
                                                          
+
                                                          CentOS 7.7
                                                          
+
                                                          None
                                                          
+
                                                          Ubuntu 22.04
                                                          
+
                                                          Some sites cannot perform upgrade. If the check result shows the upgrade is not supported, contact technical support.
                                                          
+
                                                          
+
                                                          
+
                                                        8. Scenario 3: There are unexpected node pool tags in the node.
                                                          If a node is migrated from a node pool to the default node pool, the node pool label cce.cloud.com/cce-nodepool is retained, affecting cluster upgrade. Check whether the load scheduling on the node depends on the label.
                                                          
+
                                                          • If there is no dependency, delete the tag.
                                                          • If yes, modify the load balancing policy, remove the dependency, and then delete the tag.
                                                          
+
                                                        9. Scenario 4: The Kubernetes node name is consistent with the ECS name.
                                                          Kubernetes node name, which defaults to the node's private IP. If you select a cloud server name as the node name, the cluster cannot be upgraded.
                                                          
+
                                                          Log in to the CCE console and access the cluster console. Choose Nodes in the navigation pane, view the node label, and check whether the value of kubernetes.io/hostname is consistent with the ECS name. If they are the same, remove the node before the cluster upgrade.
                                                          
+
                                                          
+
                                                          10. 
+
+
+
+
diff --git a/docs/cce/umn/cce_10_0432.html b/docs/cce/umn/cce_10_0432.html
new file mode 100644
index 00000000..d5ad977e
--- /dev/null
+++ b/docs/cce/umn/cce_10_0432.html
@@ -0,0 +1,16 @@
+
+
+
                                                          Checking the Blocklist
                                                          
+
                                                          Check Item
                                                          Check whether the current user is in the upgrade blocklist.
                                                          
+
                                                          
+
                                                          Solution
                                                          CCE temporarily disables the cluster upgrade function due to the following reasons:
                                                          
+
                                                          • The cluster is identified as the core production cluster.
                                                          • Other O&M tasks are being or will be performed to improve cluster stability, for example, 3AZ reconstruction of the master node.
                                                          
+
                                                          You can contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0433.html b/docs/cce/umn/cce_10_0433.html
new file mode 100644
index 00000000..32c05e93
--- /dev/null
+++ b/docs/cce/umn/cce_10_0433.html
@@ -0,0 +1,21 @@
+
+
+
                                                          Checking the Add-on
                                                          
+
                                                          Check Item
                                                          Check the following aspects:
                                                          
+
                                                          • Check whether the add-on status is normal.
                                                          • Check whether the add-on supports the target version.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Scenario 1: The add-on status is abnormal.
                                                            Log in to the CCE console and go to the target cluster. Choose O&M > Add-ons to view and handle the abnormal add-on.
                                                            
+
                                                            
+
                                                          • Scenario 2: The target version does not support the current add-on.
                                                            The add-on cannot be automatically upgraded with the cluster. Log in to the CCE console and go to the target cluster. Choose O&M > Add-ons to manually upgrade the add-on.
                                                            
+
                                                            
+
                                                          • Scenario 3: The add-on does not support the target cluster even if the add-on is upgraded to the latest version. In this case, go to the cluster console and choose Cluster Information > O&M > Add-ons in the navigation pane to manually uninstall the add-on.
                                                            For details about the supported add-on versions and replacement solutions, see the help document.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0434.html b/docs/cce/umn/cce_10_0434.html
new file mode 100644
index 00000000..4f6f5053
--- /dev/null
+++ b/docs/cce/umn/cce_10_0434.html
@@ -0,0 +1,16 @@
+
+
+
                                                          Checking the Helm Chart
                                                          
+
                                                          Check Item
                                                          Check whether the current HelmRelease record contains discarded Kubernetes APIs that are not supported by the target cluster version. If yes, the Helm chart may be unavailable after the upgrade.
                                                          
+
                                                          
+
                                                          Solution
                                                          Convert the discarded Kubernetes APIs to APIs that are compatible with both the source and target versions.
                                                          
+
                                                           
                                                          This item has been automatically processed in the upgrade process. You can ignore this item.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0435.html b/docs/cce/umn/cce_10_0435.html
new file mode 100644
index 00000000..75196496
--- /dev/null
+++ b/docs/cce/umn/cce_10_0435.html
@@ -0,0 +1,14 @@
+
+
+
                                                          Checking the Master Node SSH Connectivity
                                                          
+
                                                          Check Item
                                                          Check whether CCE can connect to your master nodes.
                                                          
+
                                                          
+
                                                          Solution
                                                          Contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0436.html b/docs/cce/umn/cce_10_0436.html
new file mode 100644
index 00000000..c5c31218
--- /dev/null
+++ b/docs/cce/umn/cce_10_0436.html
@@ -0,0 +1,30 @@
+
+
+
                                                          Checking the Node Pool
                                                          
+
                                                          Check Item
                                                          Check the following aspects:
                                                          
+
                                                          • Check the node status.
                                                          • Check whether the auto scaling function of the node pool is disabled.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Scenario 1: The node pool status is abnormal.
                                                            Log in to the CCE console, go to the target cluster and choose Nodes. On the displayed page, click Node Pools tab and check the node pool status. If the node pool is being scaled, wait until the scaling is complete, and disable the auto scaling function by referring to Scenario 2.
                                                            
+
                                                            
+
                                                          • Scenario 2: The auto scaling function of the node pool is enabled.
                                                            Solution 1 (Recommended)
                                                            
+
                                                            Log in to the CCE console and go to the target cluster. Choose O&M > Add-ons and uninstall the autoscaler add-on.
                                                            
+
                                                            
+
                                                             
                                                            Before uninstalling the autoscaler add-on, click Upgrade to back up the configuration so that the add-on configuration can be restored during reinstallation.
                                                            
+
                                                            Before uninstalling the autoscaler add-on, choose O&M > Node Scaling and back up the current scaling policies so that they can be restored during reinstallation. These policies will be deleted when the autoscaler add-on is uninstalled.
                                                            
+
                                                            
+
                                                            Obtain and back up the node scaling policy by clicking Edit.
                                                            
+
                                                            
+
                                                            Solution 2
                                                            
+
                                                            If you do not want to uninstall the autoscaler add-on, log in to the CCE console and access the cluster detail page. Choose Nodes in the navigation pane. On the displayed page, click the Node Pools tab and click Edit of the corresponding node pool to disable the auto scaling function.
                                                            
+
                                                            
+
                                                             
                                                            Before disabling the auto scaling function, back up the autoscaling configuration so that the configuration can be restored when the function is enabled.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0437.html b/docs/cce/umn/cce_10_0437.html
new file mode 100644
index 00000000..f1615be9
--- /dev/null
+++ b/docs/cce/umn/cce_10_0437.html
@@ -0,0 +1,22 @@
+
+
+
                                                          Checking the Security Group
                                                          
+
                                                          Check Item
                                                          Check whether the security group allows the master node to access nodes using ICMP.
                                                          
+
                                                          
+
                                                          Solution
                                                          Log in to the VPC console, choose Access Control > Security Groups, and enter the target cluster name in the search box. Two security groups are displayed:
                                                          
+
                                                          • The security group name is cluster name-node-xxx. This security group is associated with the user nodes.
                                                          • The security group name is cluster name-control-xxx. This security group is associated with the master nodes.
                                                          
+
                                                          
+
                                                          
+
                                                          Click the security group of the node user and ensure that the following rules are configured to allow the master node to access the node using ICMP.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Otherwise, add a rule to the node security group. Set Source to Security group.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0439.html b/docs/cce/umn/cce_10_0439.html
new file mode 100644
index 00000000..744f8516
--- /dev/null
+++ b/docs/cce/umn/cce_10_0439.html
@@ -0,0 +1,21 @@
+
+
+
                                                          To-Be-Migrated Node
                                                          
+
                                                          Check Item
                                                          Check whether the node needs to be migrated.
                                                          
+
                                                          
+
                                                          Solution
                                                          For the 1.15 cluster that is upgraded from 1.13 in rolling mode, you need to migrate (reset or create and replace) all nodes before performing the upgrade again.
                                                          
+
                                                          Solution 1
                                                          
+
                                                          Go the CCE console and access the cluster console. Choose Nodes in the navigation pane and click More > Reset Node in the Operation column of the corresponding node. For details, see Resetting a Node. After the node is reset, retry the check task.
                                                          
+
                                                          
+
                                                           
                                                          Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node.
                                                          
+
                                                          
+
                                                          Solution 2
                                                          
+
                                                          After creating a node, delete the faulty node.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0440.html b/docs/cce/umn/cce_10_0440.html
new file mode 100644
index 00000000..f9c0d4d0
--- /dev/null
+++ b/docs/cce/umn/cce_10_0440.html
@@ -0,0 +1,21 @@
+
+
+
                                                          Discarded Kubernetes Resource
                                                          
+
                                                          Check Item
                                                          Check whether there are discarded resources in the clusters.
                                                          
+
                                                          
+
                                                          Solution
                                                          Scenario 1: The PodSecurityPolicy resource object has been discarded since clusters of v1.25.
                                                          
+
                                                          
+
                                                          
+
                                                          Run the kubectl get psp -A command in the cluster to obtain the existing PSP object.
                                                          
+
                                                          If these two objects are not used, skip the check. Otherwise, upgrade the corresponding functions to PodSecurity by referring to Pod Security.
                                                          
+
                                                          Scenario 2: The discarded annotation (tolerate-unready-endpoints) exists in Services in clusters of 1.25 or later.
                                                          
+
                                                          
+
                                                          Check whether the Service in the log information contains the annotation tolerate-unready-endpoints. If yes, delete the annotation and add the following field to the spec of the corresponding Service to replace the annotation:
                                                          
+
                                                          publishNotReadyAddresses: true
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0441.html b/docs/cce/umn/cce_10_0441.html
new file mode 100644
index 00000000..fecf4a91
--- /dev/null
+++ b/docs/cce/umn/cce_10_0441.html
@@ -0,0 +1,90 @@
+
+
+
                                                          Compatibility Risk
                                                          
+
                                                          Check Item
                                                          Read the version compatibility differences and ensure that they are not affected.
                                                          
+
                                                          The patch upgrade does not involve version compatibility differences.
                                                          
+
                                                          
+
                                                          Version compatibility
                                                          
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Major Version Upgrade Path
                                                          
+
                                                          Precaution
                                                          
+
                                                          Self-Check
                                                          
+
                                                          Upgrade from v1.19 to v1.21 or v1.23
                                                          
+
                                                          The bug of exec probe timeouts is fixed in Kubernetes 1.21. Before this bug fix, the exec probe does not consider the timeoutSeconds field. Instead, the probe will run indefinitely, even beyond its configured deadline. It will stop until the result is returned. If this field is not specified, the default value 1 is used. This field takes effect after the upgrade. If the probe runs over 1 second, the application health check may fail and the application may restart frequently.
                                                          
+
                                                          Before the upgrade, check whether the timeout is properly set for the exec probe.
                                                          
+
                                                          kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly.
                                                          
+
                                                          Root cause: X.509 CommonName is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. If your webhook certificate does not have SANs, kube-apiserver does not process the CommonName field of the X.509 certificate as the host name by default. As a result, the authentication fails.
                                                          
+
                                                          Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server.
                                                          
+
                                                          • If you do not have your own webhook server, you can skip this check.
                                                          • If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate.
                                                          
+
                                                          Arm nodes are not supported in clusters of v1.21 and later.
                                                          
+
                                                          Check whether your services will be affected if Arm nodes cannot be used.
                                                          
+
                                                          Upgrade from v1.15 to v1.19
                                                          
+
                                                          The control plane of in the clusters v1.19 is incompatible with kubelet v1.15. If a node fails to be upgraded or the node to be upgraded restarts after the master node is successfully upgraded, there is a high probability that the node is in the NotReady status.
                                                          
+
                                                          This is because the node failed to be upgraded restarts the kubelet and trigger the node registration. In clusters of v1.15, the default registration tags (failure-domain.beta.kubernetes.io/is-baremetal and kubernetes.io/availablezone) are regarded as invalid tags by the clusters of v1.19.
                                                          
+
                                                          The valid tags in the clusters of v1.19 are node.kubernetes.io/baremetal and failure-domain.beta.kubernetes.io/zone.
                                                          
+
                                                          1. In normal cases, this scenario is not triggered.
                                                          2. After the master node is upgraded, do not suspend the upgrade so the node can be quickly upgraded.
                                                          3. If a node fails to be upgraded and cannot be restored, evict applications on the node as soon as possible. Contact technical support and skip the node upgrade. After the upgrade is complete, reset the node.
                                                          
+
                                                          In CCE 1.15 and 1.19 clusters, the Docker storage driver file system is switched from XFS to Ext4. As a result, the import package sequence in the pods of the upgraded Java application may be abnormal, causing pod exceptions.
                                                          
+
                                                          Before the upgrade, check the Docker configuration file /etc/docker/daemon.json on the node. Check whether the value of dm.fs is xfs.
                                                          
+
                                                          • If the value is ext4 or the storage driver is Overlay, you can skip the next steps.
                                                          • If the value is xfs, you are advised to deploy applications in the cluster of the new version in advance to test whether the applications are compatible with the new cluster version.
                                                          
+
                                                          {
+      "storage-driver": "devicemapper",
+      "storage-opts": [
+      "dm.thinpooldev=/dev/mapper/vgpaas-thinpool",
+      "dm.use_deferred_removal=true",
+      "dm.fs=xfs",
+      "dm.use_deferred_deletion=true"
+      ]
+}
                                                          
+
                                                          kube-apiserver of CCE 1.19 or later requires that the Subject Alternative Names (SANs) field be configured for the certificate of your webhook server. Otherwise, kube-apiserver fails to call the webhook server after the upgrade, and containers cannot be started properly.
                                                          
+
                                                          Root cause: X.509 CommonName is discarded in Go 1.15. kube-apiserver of CCE 1.19 is compiled using Go 1.15. The CommonName field is processed as the host name. As a result, the authentication fails.
                                                          
+
                                                          Before the upgrade, check whether the SAN field is configured in the certificate of your webhook server.
                                                          
+
                                                          • If you do not have your own webhook server, you can skip this check.
                                                          • If the field is not set, you are advised to use the SAN field to specify the IP address and domain name supported by the certificate.
                                                          
+
                                                           NOTICE: 
                                                          To mitigate the impact of version differences on cluster upgrade, CCE performs special processing during the upgrade from 1.15 to 1.19 and still supports certificates without SANs. However, no special processing is required for subsequent upgrades. You are advised to rectify your certificate as soon as possible.
                                                          
+
                                                          
+
                                                          In clusters of v1.17.17 and later, CCE automatically creates pod security policies (PSPs) for you, which restrict the creation of pods with unsafe configurations, for example, pods for which net.core.somaxconn under a sysctl is configured in the security context.
                                                          
+
                                                          After an upgrade, you can allow insecure system configurations as required. For details, see Configuring a Pod Security Policy.
                                                          
+
                                                          Upgrade from v1.13 to v1.15
                                                          
+
                                                          After a VPC network cluster is upgraded, the master node occupies an extra CIDR block due to the upgrade of network components. If no container CIDR block is available for the new node, the pod scheduled to the node cannot run.
                                                          
+
                                                          This problem occurs when almost all CIDR blocks are occupied. For example, the container CIDR block is 10.0.0.0/16, the number of available IP addresses is 65,536, and the VPC network is allocated a CIDR block with the fixed size (using the mask to determine the maximum number of container IP addresses allocated to each node). If the upper limit is 128, the cluster supports a maximum of 512 (65536/128) nodes, including the three master nodes. After the cluster is upgraded, each of the three master nodes occupies one CIDR block. As a result, 506 nodes are supported.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0442.html b/docs/cce/umn/cce_10_0442.html
new file mode 100644
index 00000000..f76b8dfe
--- /dev/null
+++ b/docs/cce/umn/cce_10_0442.html
@@ -0,0 +1,26 @@
+
+
+
                                                          Node CCEAgent Version
                                                          
+
                                                          Check Item
                                                          Check whether cce-agent on the current node is of the latest version.
                                                          
+
                                                          
+
                                                          Solution
                                                          If cce-agent is not of the latest version, the automatic update fails. This problem is usually caused by invalid OBS address or the version of the component is outdated.
                                                          
+
                                                          1. Log in to a normal node that passes the check, obtain the path of the cce-agent configuration file, and check the OBS address.
                                                            cat `ps aux | grep cce-agent | grep -v grep | awk -F '-f ''{print $2}'`
                                                            
+
                                                            The OBS configuration address field in the configuration file is packageFrom.addr.
                                                            
+
                                                            
+
                                                          2. Log in to an abnormal node where the check fails, obtain the OBS address again by referring to the previous step, and check whether the OBS address is consistent. If they are different, change the OBS address of the abnormal node to the correct address.
                                                          3. Run the following commands to download the latest binary file:
                                                            • ARM
                                                              curl -k "https://{OBS address you have obtained}/cluster-versions/base/cce-agent-arm" > /tmp/cce-agent-arm
                                                              
+
                                                            
+
                                                          4. Replace the original cce-agent binary file.
                                                            • ARM
                                                              mv -f /tmp/cce-agent-arm /usr/local/bin/cce-agent-arm
+chmod 750 /usr/local/bin/cce-agent-arm
+chown root:root /usr/local/bin/cce-agent-arm
                                                              
+
                                                            
+
                                                          5. Restart cce-agent.
                                                            systemctl restart cce-agent
                                                            
+
                                                            If you have any questions about the preceding operations, contact technical support.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0443.html b/docs/cce/umn/cce_10_0443.html
new file mode 100644
index 00000000..25de7bab
--- /dev/null
+++ b/docs/cce/umn/cce_10_0443.html
@@ -0,0 +1,14 @@
+
+
+
                                                          Node CPU Usage
                                                          
+
                                                          Check Item
                                                          Check whether the CPU usage of the node exceeds 90%.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Upgrade the cluster during off-peak hours.
                                                          • Check whether too many pods are deployed on the node. If yes, reschedule pods to other idle nodes.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0444.html b/docs/cce/umn/cce_10_0444.html
new file mode 100644
index 00000000..8bba4c72
--- /dev/null
+++ b/docs/cce/umn/cce_10_0444.html
@@ -0,0 +1,15 @@
+
+
+
                                                          CRD Check
                                                          
+
                                                          Check Item
                                                          Check the following aspects:
                                                          
+
                                                          • Check whether the key CRD packageversions.version.cce.io of the cluster is deleted.
                                                          • Check whether the cluster key CRD network-attachment-definitions.k8s.cni.cncf.io is deleted.
                                                          
+
                                                          
+
                                                          Solution
                                                          If check results are abnormal, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0445.html b/docs/cce/umn/cce_10_0445.html
new file mode 100644
index 00000000..c4d17ce3
--- /dev/null
+++ b/docs/cce/umn/cce_10_0445.html
@@ -0,0 +1,24 @@
+
+
+
                                                          Node Disk
                                                          
+
                                                          Check Item
                                                          Check the following aspects:
                                                          
+
                                                          • Check whether the key data disks on the node meet the upgrade requirements.
                                                          • Check whether the /tmp directory has 500 MB available space.
                                                          
+
                                                          
+
                                                          Solution
                                                          During the node upgrade, the key disks store the upgrade component package, and the /tmp directory stores temporary files.
                                                          
+
                                                          
+
                                                          • Scenario 1: Check whether the disk meets the upgrade requirements.
                                                            Run the following command to check the usage of each key disk. After ensuring that the available space meets the requirements and check again. If the space of the master node is insufficient, contact technical support.
                                                            
+
                                                            • Disk partition of Docker: 2 GB for master nodes and 1 GB for worker nodes
                                                              df -h /var/lib/docker
                                                              
+
                                                            • Disk partition of containerd: 2 GB for master nodes and 1 GB for worker nodes
                                                              df -h /var/lib/containerd
                                                              
+
                                                            • Disk partition of kubelet: 2 GB for master nodes and 1 GB for worker nodes
                                                              df -h /var/lib/docker
                                                              
+
                                                            • System disk: 10 GB for master nodes and 2 GB for worker nodes
                                                              df -h /
                                                              
+
                                                            
+
                                                          • Scenario 2: The /tmp directory space is insufficient.
                                                            Run the following command to check the space usage of the file system where the /tmp directory is located. Ensure that the space is greater than 500 MB and check again.
                                                            
+
                                                            df -h /tmp
                                                            
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0446.html b/docs/cce/umn/cce_10_0446.html
new file mode 100644
index 00000000..048fb378
--- /dev/null
+++ b/docs/cce/umn/cce_10_0446.html
@@ -0,0 +1,15 @@
+
+
+
                                                          Node DNS
                                                          
+
                                                          Check Item
                                                          Check the following aspects:
                                                          
+
                                                          • Check whether the DNS configuration of the current node can resolve the OBS address.
                                                          • Check whether the current node can access the OBS address of the storage upgrade component package.
                                                          
+
                                                          
+
                                                          Solution
                                                          During the node upgrade, you need to obtain the upgrade component package from OBS. If this check fails, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0447.html b/docs/cce/umn/cce_10_0447.html
new file mode 100644
index 00000000..a9a81d05
--- /dev/null
+++ b/docs/cce/umn/cce_10_0447.html
@@ -0,0 +1,16 @@
+
+
+
                                                          Node Key Directory File Permissions
                                                          
+
                                                          Check Item
                                                          Check whether the key directory /var/paas on the nodes contain files with abnormal owners or owner groups.
                                                          
+
                                                          
+
                                                          Solution
                                                          CCE uses the /var/paas directory to manage nodes and store file data whose owner and owner group are both paas.
                                                          
+
                                                          During the current cluster upgrade, the owner and owner group of the files in the /var/paas directory are reset to paas.
                                                          
+
                                                          Check whether file data is stored in the /var/paas directory. If yes, do not use this directory, remove abnormal files from this directory, and check again. Otherwise, the upgrade is prohibited.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0448.html b/docs/cce/umn/cce_10_0448.html
new file mode 100644
index 00000000..33ab136d
--- /dev/null
+++ b/docs/cce/umn/cce_10_0448.html
@@ -0,0 +1,16 @@
+
+
+
                                                          Kubelet
                                                          
+
                                                          Check Item
                                                          Check whether the kubelet on the node is running properly.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Scenario 1: The kubelet status is abnormal.
                                                            If the kubelet is abnormal, the node is unavailable. Restore the node by following the instructions provided in  and check again.
                                                            
+
                                                          • Scenario 2: The cce-pause version is abnormal.
                                                            The version of the pause container image on which kubelet depends is not cce-pause:3.1. If you continue the upgrade, pods will restart in batches. Currently, the upgrade is not supported. Contact technical support.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0449.html b/docs/cce/umn/cce_10_0449.html
new file mode 100644
index 00000000..c7a63119
--- /dev/null
+++ b/docs/cce/umn/cce_10_0449.html
@@ -0,0 +1,14 @@
+
+
+
                                                          Node Memory
                                                          
+
                                                          Check Item
                                                          Check whether the memory usage of the node exceeds 90%.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Upgrade the cluster during off-peak hours.
                                                          • Check whether too many pods are deployed on the node. If yes, reschedule pods to other idle nodes.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0450.html b/docs/cce/umn/cce_10_0450.html
new file mode 100644
index 00000000..8bf36073
--- /dev/null
+++ b/docs/cce/umn/cce_10_0450.html
@@ -0,0 +1,22 @@
+
+
+
                                                          Node Clock Synchronization Server
                                                          
+
                                                          Check Item
                                                          Check whether the clock synchronization server ntpd or chronyd of the node is running properly.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Scenario 1: ntpd is running abnormally.
                                                            Log in to the node and run the systemctl status ntpd command to query the running status of ntpd. If the command output is abnormal, run the systemctl restart ntpd command and query the status again.
                                                            
+
                                                            The normal command output is as follows:
                                                            
+
                                                            
+
                                                            If the problem persists after ntpd is restarted, contact technical support.
                                                            
+
                                                          • Scenario 2: chronyd is running abnormally.
                                                            Log in to the node and run the systemctl status chronyd command to query the running status of chronyd. If the command output is abnormal, run the systemctl restart chronyd command and query the status again.
                                                            
+
                                                            The normal command output is as follows:
                                                            
+
                                                            
+
                                                            If the problem persists after chronyd is restarted, contact technical support.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0451.html b/docs/cce/umn/cce_10_0451.html
new file mode 100644
index 00000000..5085fc9b
--- /dev/null
+++ b/docs/cce/umn/cce_10_0451.html
@@ -0,0 +1,15 @@
+
+
+
                                                          Node OS
                                                          
+
                                                          Check Item
                                                          Check whether the OS kernel version of the node is supported by CCE.
                                                          
+
                                                          
+
                                                          Solution
                                                          Running nodes depend on the initial standard kernel version when they are created. CCE has performed comprehensive compatibility tests based on this kernel version. A non-standard kernel version may cause unexpected compatibility issues during node upgrade and the node upgrade may fail. For details, see High-Risk Operations and Solutions.
                                                          
+
                                                          Currently, this type of nodes should not be upgraded. You are advised to reset the node to the standard kernel version before the upgrade by following the instructions in Resetting a Node.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0452.html b/docs/cce/umn/cce_10_0452.html
new file mode 100644
index 00000000..13004fc2
--- /dev/null
+++ b/docs/cce/umn/cce_10_0452.html
@@ -0,0 +1,14 @@
+
+
+
                                                          Node CPU Count
                                                          
+
                                                          Check Item
                                                          Check whether the number of CPUs on the master node is greater than 2.
                                                          
+
                                                          
+
                                                          Solution
                                                          If the number of CPUs on the master node is 2, contact technical support to expand the number to 4 or more.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0453.html b/docs/cce/umn/cce_10_0453.html
new file mode 100644
index 00000000..d7a9670e
--- /dev/null
+++ b/docs/cce/umn/cce_10_0453.html
@@ -0,0 +1,18 @@
+
+
+
                                                          Node Python Command
                                                          
+
                                                          Check Item
                                                          Check whether the Python commands are available on a node.
                                                          
+
                                                          
+
                                                          Check Method
                                                          /usr/bin/python --version
+echo $?
                                                          
+
                                                          If the command output is not 0, the check fails.
                                                          
+
                                                          
+
                                                          Solution
                                                          Install Python before the upgrade.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0455.html b/docs/cce/umn/cce_10_0455.html
new file mode 100644
index 00000000..2c4b9f43
--- /dev/null
+++ b/docs/cce/umn/cce_10_0455.html
@@ -0,0 +1,18 @@
+
+
+
                                                          Node Readiness
                                                          
+
                                                          Check Item
                                                          Check whether the nodes in the cluster are ready.
                                                          
+
                                                          
+
                                                          Solution
                                                          • Scenario 1: The nodes are in the unavailable status.
                                                            Log in to the CCE console and access the cluster console. Choose Nodes in the navigation pane and filter out unavailable nodes, rectify the faulty nodes by referring to the suggestions provided by the console, and check again.
                                                            
+
                                                          
+
                                                          • Scenario 2: The displayed node status is inconsistent with the actual status.
                                                            The possible causes are as follows:
                                                            
+
                                                            1. The node status is normal on the nodes page, but the check result shows that the node is not ready. Check again.
                                                            2. The node is not found on the nodes page, but the check result shows that the node is in the cluster. Contact technical support.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0456.html b/docs/cce/umn/cce_10_0456.html
new file mode 100644
index 00000000..1e36983f
--- /dev/null
+++ b/docs/cce/umn/cce_10_0456.html
@@ -0,0 +1,17 @@
+
+
+
                                                          Node journald
                                                          
+
                                                          Check Item
                                                          Check whether journald of a node is normal.
                                                          
+
                                                          
+
                                                          Solution
                                                          Log in to the node and run the systemctl is-active systemd-journald command to query the running status of journald. If the command output is abnormal, run the systemctl restart systemd-journald command and query the status again.
                                                          
+
                                                          The normal command output is as follows:
                                                          
+
                                                          
+
                                                          If the problem persists after journald is restarted, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0457.html b/docs/cce/umn/cce_10_0457.html
new file mode 100644
index 00000000..7c86849c
--- /dev/null
+++ b/docs/cce/umn/cce_10_0457.html
@@ -0,0 +1,15 @@
+
+
+
                                                          containerd.sock Check
                                                          
+
                                                          Check Item
                                                          Check whether the containerd.sock file exists on the node. This file affects the startup of container runtime in the Euler OS.
                                                          
+
                                                          
+
                                                          Solution
                                                          Scenario: The Docker used by the node is the customized Euler-docker.
                                                          
+
                                                          1. Log in to the node.
                                                          2. Run the rpm -qa | grep docker | grep euleros command. If the command output is not empty, the Docker used on the node is Euler-docker.
                                                          3. Run the ls /run/containerd/containerd.sock command. If the file exists, Docker fails to be started.
                                                          4. Run the rm -rf /run/containerd/containerd.sock command and perform the cluster upgrade check again.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0458.html b/docs/cce/umn/cce_10_0458.html
new file mode 100644
index 00000000..6ab0018a
--- /dev/null
+++ b/docs/cce/umn/cce_10_0458.html
@@ -0,0 +1,14 @@
+
+
+
                                                          Internal Error
                                                          
+
                                                          Check Item
                                                          Before the upgrade, check whether an internal error occurs.
                                                          
+
                                                          
+
                                                          Solution
                                                          If this check fails, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0459.html b/docs/cce/umn/cce_10_0459.html
new file mode 100644
index 00000000..8d59f255
--- /dev/null
+++ b/docs/cce/umn/cce_10_0459.html
@@ -0,0 +1,22 @@
+
+
+
                                                          Node Mount Point
                                                          
+
                                                          Check Item
                                                          Check whether inaccessible mount points exist on the node.
                                                          
+
                                                          
+
                                                          Solution
                                                          Scenario: There are inaccessible mount points on the node.
                                                          
+
                                                          If network NFS (such as OBS, SFS, and SFS) is used by the node and the node is disconnected with the NFS server, the mount point would be inaccessible and all processes that access this mount point are suspended.
                                                          
+
                                                          1. Log in to the node.
                                                          2. Run the following commands on the node in sequence:
                                                            - df -h
+- for dir in `df -h | grep -v "Mounted on" | awk "{print \\$NF}"`;do cd $dir; done && echo "ok"
                                                            
+
                                                          3. If ok is returned, no problem occurs.
                                                            Otherwise, start another terminal and run the following command to check whether the previous command is in the D state:
                                                            - ps aux | grep "D "
                                                            
+
                                                            
+
                                                          4. If a process is in the D state, the problem occurs.You can only reset the node to solve the problem. Reset the node and upgrade the cluster again. For details about how to reset a node, see Resetting a Node.
                                                             
                                                            Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0460.html b/docs/cce/umn/cce_10_0460.html
new file mode 100644
index 00000000..c3851634
--- /dev/null
+++ b/docs/cce/umn/cce_10_0460.html
@@ -0,0 +1,34 @@
+
+
+
                                                          Kubernetes Node Taint
                                                          
+
                                                          Check Item
                                                          Check whether the taint, as shown in Table 1, exists on the node.
+
                                                          
+
+
+
+
+
+
+
+
                                                          Table 1 Taint checklist
                                                          Name
                                                          
+
                                                          Impact
                                                          
+
                                                          node.kubernetes.io/upgrade
                                                          
+
                                                          NoSchedule
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          Scenario 1: The node is skipped during the cluster upgrade.
                                                          
+
                                                          1. For details about how to configure kubectl, see Connecting to a Cluster Using kubectl.
                                                          2. Check the kubelet version of the corresponding node. If the following information is expected:
                                                            
+
                                                            If the version of the node is different from that of other nodes, the node is skipped during the upgrade. Reset the node and upgrade the cluster again. For details about how to reset a node, see Resetting a Node.
                                                            
+
                                                             
                                                            Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0462.html b/docs/cce/umn/cce_10_0462.html
index a91b6cda..dab6fa72 100644
--- a/docs/cce/umn/cce_10_0462.html
+++ b/docs/cce/umn/cce_10_0462.html
@@ -52,6 +52,18 @@
 
                                                          runC
                                                          
                                                           		
 
                                                          Ubuntu 22.04
                                                          
+
                                                          4.x
                                                          
+
                                                          Docker
                                                          
+
                                                          containerd
                                                          
+
                                                          OverlayFS
                                                          
+
                                                          runC
                                                          
+
                                                          
 
 
                                                          
 
                                                          
@@ -70,10 +82,12 @@
                                                           		
 
                                                          
 
                                                          Elastic Cloud Server (VM)
                                                          
+
                                                          Elastic Cloud Server (VM)
                                                          
+
                                                          
+
                                                          
+
                                                          
                                                           		
 
                                                          CentOS 7.x
                                                          
-
                                                          EulerOS 2.9
                                                          
                                                           		
 
                                                          3.x
                                                          
 
                                                          runC
                                                          
                                                           		
 
                                                          Elastic Cloud Server (physical machine)
                                                          
+
                                                          EulerOS 2.5
                                                          
 
                                                          EulerOS 2.9
                                                          
+
                                                          3.x
                                                          
 
                                                          4.x
                                                          
+
                                                          Docker
                                                          
 
                                                          containerd
                                                          
+
                                                          OverlayFS
                                                          
 
                                                          Device Mapper
                                                          
+
                                                          runC
                                                          
 
                                                          Kata
                                                          
+
                                                          EulerOS 2.9
                                                          
+
                                                          4.x
                                                          
+
                                                          Docker
                                                          
+
                                                          Clusters of v1.23 and later support containerd.
                                                          
+
                                                          OverlayFS
                                                          
+
                                                          runC
                                                          
+
                                                          Ubuntu 22.04
                                                          
+
                                                          4.x
                                                          
+
                                                          Docker
                                                          
+
                                                          containerd
                                                          
+
                                                          OverlayFS
                                                          
+
                                                          runC
                                                          
                                                           		
 
                                                          
                                                           
 
 
 
                                                          
+
+
+
+
+
+
+
+
                                                          Table 1 List of everest add-on versions that have compatibility restrictions
                                                          Add-on Name
                                                          
+
                                                          Versions Involved
                                                          
+
                                                          everest
                                                          
+
                                                          v1.0.2-v1.0.7
                                                          
+
                                                          v1.1.1-v1.1.5
                                                          
+
                                                          
+
                                                          
+
+
                                                          Solution
                                                          The current everest add-on has compatibility restrictions and cannot be upgraded with the cluster upgrade. Contact technical support.
                                                          
+
                                                          
+
+
+
diff --git a/docs/cce/umn/cce_10_0479.html b/docs/cce/umn/cce_10_0479.html
new file mode 100644
index 00000000..d44a8267
--- /dev/null
+++ b/docs/cce/umn/cce_10_0479.html
@@ -0,0 +1,14 @@
+
+
+
                                                          cce-hpa-controller Restriction Check
                                                          
+
                                                          Check Item
                                                          Check whether the current cce-controller-hpa add-on has compatibility restrictions.
                                                          
+
                                                          
+
                                                          Solution
                                                          The current cce-controller-hpa add-on has compatibility restrictions. An add-on that can provide metric APIs, for example, metric-server, must be installed in the cluster.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0480.html b/docs/cce/umn/cce_10_0480.html
new file mode 100644
index 00000000..cbdd9ea3
--- /dev/null
+++ b/docs/cce/umn/cce_10_0480.html
@@ -0,0 +1,45 @@
+
+
+
                                                          Enhanced CPU Management Policy
                                                          
+
                                                          Check Item
                                                          Check whether the current cluster version and the target version support enhanced CPU policy.
                                                          
+
                                                          
+
                                                          Solution
                                                          Scenario: The current cluster version uses the enhanced CPU management policy, but the target cluster version does not support the enhanced CPU management policy.
                                                          
+
                                                          Upgrade the cluster to a version that supports the enhanced CPU management policy. The following table lists the cluster versions that support the enhanced CPU management policy.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 Cluster versions that support the enhanced CPU policy
                                                          Cluster Version
                                                          
+
                                                          Enhanced CPU Policy Supported
                                                          
+
                                                          v1.17 or earlier
                                                          
+
                                                          No
                                                          
+
                                                          v1.19
                                                          
+
                                                          No
                                                          
+
                                                          v1.21
                                                          
+
                                                          No
                                                          
+
                                                          v1.23 or later
                                                          
+
                                                          Yes
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0484.html b/docs/cce/umn/cce_10_0484.html
new file mode 100644
index 00000000..569832c6
--- /dev/null
+++ b/docs/cce/umn/cce_10_0484.html
@@ -0,0 +1,14 @@
+
+
+
                                                          User Node Components Health
                                                          
+
                                                          Check Item
                                                          Check whether the container runtime and network components on the user node are healthy.
                                                          
+
                                                          
+
                                                          Solution
                                                          If a component is abnormal, log in to the node to check the status of the abnormal component and rectify the fault.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0485.html b/docs/cce/umn/cce_10_0485.html
new file mode 100644
index 00000000..1eaa0fba
--- /dev/null
+++ b/docs/cce/umn/cce_10_0485.html
@@ -0,0 +1,14 @@
+
+
+
                                                          Controller Node Components Health
                                                          
+
                                                          Check Item
                                                          Check whether the Kubernetes, container runtime, and network components of the controller node are healthy.
                                                          
+
                                                          
+
                                                          Solution
                                                          If a component on the controller node is abnormal, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0486.html b/docs/cce/umn/cce_10_0486.html
new file mode 100644
index 00000000..ddf59ece
--- /dev/null
+++ b/docs/cce/umn/cce_10_0486.html
@@ -0,0 +1,16 @@
+
+
+
                                                          Memory Resource Limit of Kubernetes Components
                                                          
+
                                                          Check Item
                                                          Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit.
                                                          
+
                                                          
+
                                                          Solution
                                                          Solution 1: Reducing Kubernetes resources
                                                          
+
                                                          Solution 2: Expanding cluster scale
                                                          
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0487.html b/docs/cce/umn/cce_10_0487.html
new file mode 100644
index 00000000..a5ec31af
--- /dev/null
+++ b/docs/cce/umn/cce_10_0487.html
@@ -0,0 +1,20 @@
+
+
+
                                                          Checking Deprecated Kubernetes APIs
                                                          
+
                                                          Check Item
                                                          The system scans the audit logs of the past day to check whether the user calls the deprecated APIs of the target Kubernetes version.
                                                           
                                                          Due to the limited time range of audit logs, this check item is only an auxiliary method. APIs to be deprecated may have been used in the cluster, but their usage is not included in the audit logs of the past day. Check the API usage carefully.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          Description
                                                          
+
                                                          The check result shows that your cluster calls a deprecated API of the target cluster version through kubectl or other applications. You can rectify the fault before the upgrade. Otherwise, the API will be intercepted by kube-apiserver after the upgrade. For details about each deprecated API, see Deprecated API Migration Guide.
                                                          
+
                                                          Cases
                                                          
+
                                                          Ingresses of extensions/v1beta1 and networking.k8s.io/v1beta1 API are deprecated in clusters of v1.22. If you upgrade a CCE cluster from v1.19 or v1.21 to v1.23, existing resources are not affected, but the v1beta1 API version may be intercepted in the creation and editing scenarios.
                                                          
+
                                                          For details about the YAML configuration structure changes, see Using kubectl to Create an ELB Ingress.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0488.html b/docs/cce/umn/cce_10_0488.html
new file mode 100644
index 00000000..28a4c8db
--- /dev/null
+++ b/docs/cce/umn/cce_10_0488.html
@@ -0,0 +1,16 @@
+
+
+
                                                          IPv6 Capability of a CCE Turbo Cluster
                                                          
+
                                                          Check Item
                                                          If IPv6 is enabled for a CCE Turbo cluster, check whether the target cluster version supports IPv6.
                                                          
+
                                                          
+
                                                          Solution
                                                          CCE Turbo clusters support IPv6 since v1.23. This feature is available in the following versions:
                                                          • v1.23: 1.23.8-r0 or later
                                                          • v1.25: 1.25.3-r0 or later
                                                          • v1.25 or later
                                                          
+
                                                          
+
                                                          If IPv6 has been enabled in the cluster before the upgrade, the target cluster version must also support IPv6. Select a proper cluster version.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0489.html b/docs/cce/umn/cce_10_0489.html
new file mode 100644
index 00000000..f079e3f0
--- /dev/null
+++ b/docs/cce/umn/cce_10_0489.html
@@ -0,0 +1,15 @@
+
+
+
                                                          Node NetworkManager
                                                          
+
                                                          Check Item
                                                          Check whether NetworkManager of a node is normal.
                                                          
+
                                                          
+
                                                          Solution
                                                          Log in to the node and run the systemctl is-active NetworkManager command to query the running status of NetworkManager. If the command output is abnormal, run the systemctl restart NetworkManager command and query the status again.
                                                          
+
                                                          If the problem persists after NetworkManager is restarted, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0490.html b/docs/cce/umn/cce_10_0490.html
new file mode 100644
index 00000000..d7d0f8f9
--- /dev/null
+++ b/docs/cce/umn/cce_10_0490.html
@@ -0,0 +1,20 @@
+
+
+
                                                          Node ID File
                                                          
+
                                                          Check Item
                                                          Check the ID file format.
                                                          
+
                                                          
+
                                                          Solution
                                                          1. On the Nodes page of the CCE console, click the name of the abnormal node to go to the ECS page.
                                                            
+
                                                          2. Copy the node ID and save it to the local host.
                                                            
+
                                                          3. Log in to the abnormal node and back up files.
                                                            cp /var/lib/cloud/data/instance-id /tmp/instance-id
+cp /var/paas/conf/server.conf /tmp/server.conf
                                                            
+
                                                          4. Log in to the abnormal node and write the obtained node ID to the file.
                                                            echo "Node ID" >> /var/lib/cloud/data/instance-id
+echo "Node ID" >> /var/paas/conf/server.conf
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0491.html b/docs/cce/umn/cce_10_0491.html
new file mode 100644
index 00000000..e615c8f9
--- /dev/null
+++ b/docs/cce/umn/cce_10_0491.html
@@ -0,0 +1,132 @@
+
+
+
                                                          Node Configuration Consistency
                                                          
+
                                                          Check Item
                                                          When you upgrade a CCE cluster to v1.19 or later, the system checks whether the following configuration files have been modified in the background:
                                                          
+
                                                          • /opt/cloud/cce/kubernetes/kubelet/kubelet
                                                          • /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          • /opt/cloud/cce/kubernetes/kube-proxy/kube-proxy
                                                          • /etc/containerd/default_runtime_spec.json
                                                          • /etc/sysconfig/docker
                                                          • /etc/default/docker
                                                          • /etc/docker/daemon.json
                                                          
+
                                                          If you modify some parameters in these files, the cluster upgrade may fail or services may be abnormal after the upgrade. If you confirm that the modification does not affect services, continue the upgrade.
                                                          
+
                                                           
                                                          CCE uses the standard image script to check node configuration consistency. If you use other custom images, the check may fail.
                                                          
+
                                                          
+
                                                          The expected modification will not be intercepted. The following table lists the parameters that can be modified.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 Parameters that can be modified
                                                          Component
                                                          
+
                                                          Configuration File
                                                          
+
                                                          Parameter
                                                          
+
                                                          Upgrade Version
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          cpuManagerPolicy
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          maxPods
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          kubeAPIQPS
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          kubeAPIBurst
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          podPidsLimit
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          topologyManagerPolicy
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          resolvConf
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          eventRecordQPS
                                                          
+
                                                          Later than v1.21
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          topologyManagerScope
                                                          
+
                                                          Later than v1.21
                                                          
+
                                                          kubelet
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          allowedUnsafeSysctls
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          Docker
                                                          
+
                                                          /etc/docker/daemon.json
                                                          
+
                                                          dm.basesize
                                                          
+
                                                          Later than v1.19
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          If you modify some parameters in these files, exceptions may occur after the upgrade. If you are not sure whether the modified parameters will affect the upgrade, contact technical support.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0492.html b/docs/cce/umn/cce_10_0492.html
new file mode 100644
index 00000000..ee9be906
--- /dev/null
+++ b/docs/cce/umn/cce_10_0492.html
@@ -0,0 +1,62 @@
+
+
+
                                                          Node Configuration File
                                                          
+
                                                          Check Item
                                                          Check whether the configuration files of key components exist on the node.
                                                          
+
                                                          The following table lists the files to be checked.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          File Name
                                                          
+
                                                          File Content
                                                          
+
                                                          Remarks
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet
                                                          
+
                                                          kubelet command line startup parameters
                                                          
+
                                                          -
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml
                                                          
+
                                                          kubelet startup parameters
                                                          
+
                                                          -
                                                          
+
                                                          /opt/cloud/cce/kubernetes/kube-proxy/kube-proxy
                                                          
+
                                                          kube-proxy command line startup parameters
                                                          
+
                                                          -
                                                          
+
                                                          /etc/sysconfig/docker
                                                          
+
                                                          Docker configuration file
                                                          
+
                                                          Not checked when containerd or the Debain-Group machine is used.
                                                          
+
                                                          /etc/default/docker
                                                          
+
                                                          Docker configuration file
                                                          
+
                                                          Not checked when containerd or the Centos-Group machine is used.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          Contact technical support to restore the configuration file and then perform the upgrade.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0493.html b/docs/cce/umn/cce_10_0493.html
new file mode 100644
index 00000000..3c591a76
--- /dev/null
+++ b/docs/cce/umn/cce_10_0493.html
@@ -0,0 +1,39 @@
+
+
+
                                                          Checking CoreDNS Configuration Consistency
                                                          
+
                                                          Check Item
                                                          Check whether the current CoreDNS key configuration Corefile is different from the Helm Release record. The difference may be overwritten during the add-on upgrade, affecting domain name resolution in the cluster.
                                                          
+
                                                          
+
                                                          Solution
                                                          You can upgrade the coredns add-on separately after confirming the configuration differences.
                                                          
+
                                                          1. For details about how to configure kubectl, see Connecting to a Cluster Using kubectl.
                                                          2. Obtain the Corefile that takes effect currently.
                                                            kubectl get cm -nkube-system coredns -o jsonpath='{.data.Corefile}' > corefile_now.txt
+cat corefile_now.txt
                                                            
+
                                                          3. Obtain the Corefile in the Helm Release record (depending on Python 3).
                                                            latest_release=`kubectl get secret -nkube-system -l owner=helm -l name=cceaddon-coredns --sort-by=.metadata.creationTimestamp | awk 'END{print $1}'`
+kubectl get secret -nkube-system $latest_release -o jsonpath='{.data.release}' | base64 -d | base64 -d | gzip -d | python -m json.tool | python -c "
+import json,sys,re,yaml;
+manifests = json.load(sys.stdin)['manifest']
+files = re.split('(?:^|\s*\n)---\s*',manifests)
+for file in files:
+    if 'coredns/templates/configmap.yaml' in file and 'Corefile' in file:
+      corefile = yaml.safe_load(file)['data']['Corefile']
+      print(corefile,end='')
+      exit(0);
+print('error')
+exit(1);
+" > corefile_record.txt
+cat corefile_record.txt
+
                                                            
+
                                                          4. Compare the output information of 2 and 3.
                                                            diff corefile_now.txt corefile_record.txt -y;
                                                            
+
                                                            
+
                                                          5. Return to the CCE console and click the cluster name to go to the cluster console. On the Add-ons page, select the coredns add-on and click Upgrade.
                                                            To retain the differentiated configurations, use either of the following methods:
                                                            • Set parameterSyncStrategy to force. You need to manually enter the differentiated configurations. For details, see coredns (System Resource Add-On, Mandatory).
                                                            • If parameterSyncStrategy is set to inherit, differentiated configurations are automatically inherited. The system automatically parses, identifies, and inherits differentiated parameters.
                                                            
+
                                                            
+
                                                            
+
                                                          6. Click OK. After the add-on upgrade is complete, check whether all CoreDNS instances are available and whether the Corefile meets the expectation.
                                                            kubectl get cm -nkube-system coredns -o jsonpath='{.data.Corefile}'
                                                            
+
                                                          7. Change the value of parameterSyncStrategy to ensureConsistent to enable configuration consistency verification.
                                                            Use the parameter configuration function of CCE add-on management to modify the Corefile configuration to avoid differences.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0549.html b/docs/cce/umn/cce_10_0549.html
new file mode 100644
index 00000000..efbfe901
--- /dev/null
+++ b/docs/cce/umn/cce_10_0549.html
@@ -0,0 +1,226 @@
+
+
+
                                                          Performing Pre-upgrade Check
                                                          
+
                                                          The system performs a comprehensive pre-upgrade check before the cluster upgrade. If the cluster does not meet the pre-upgrade check conditions, the upgrade cannot continue. To prevent upgrade risks, you can perform pre-upgrade check according to the check items provided by this section.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 Check items
                                                          Check Item
                                                          
+
                                                          Description
                                                          
+
                                                          Checking the Node
                                                          
+
                                                          • Check whether the node is available. 
                                                          • Check whether the node OS supports the upgrade.
                                                          • Check whether there are unexpected node pool tags in the node.
                                                          • Check whether the Kubernetes node name is consistent with the ECS name.
                                                          
+
                                                          Checking the Blocklist
                                                          
+
                                                          Check whether the current user is in the upgrade blocklist.
                                                          
+
                                                          Checking the Add-on
                                                          
+
                                                          • Check whether the add-on status is normal.
                                                          • Check whether the add-on support the target version.
                                                          
+
                                                          Checking the Helm Chart
                                                          
+
                                                          Check whether the current HelmRelease record contains discarded Kubernetes APIs that are not supported by the target cluster version. If yes, the Helm chart may be unavailable after the upgrade.
                                                          
+
                                                          Checking the Master Node SSH Connectivity
                                                          
+
                                                          Check whether CCE can connect to your master nodes.
                                                          
+
                                                          Checking the Node Pool
                                                          
+
                                                          • Check the node status.
                                                          • Check whether the auto scaling function of the node pool is disabled.
                                                          
+
                                                          Checking the Security Group
                                                          
+
                                                          Check whether the security group allows the master node to access nodes using ICMP.
                                                          
+
                                                          To-Be-Migrated Node
                                                          
+
                                                          Check whether the node needs to be migrated.
                                                          
+
                                                          Discarded Kubernetes Resource
                                                          
+
                                                          Check whether there are discarded resources in the clusters.
                                                          
+
                                                          Compatibility Risk
                                                          
+
                                                          Read the version compatibility differences and ensure that they are not affected.
                                                          
+
                                                          Node CCEAgent Version
                                                          
+
                                                          Check whether cce-agent on the current node is of the latest version.
                                                          
+
                                                          Node CPU Usage
                                                          
+
                                                          Check whether the CPU usage of the node exceeds 90%.
                                                          
+
                                                          CRD Check
                                                          
+
                                                          • Check whether the key CRD packageversions.version.cce.io of the cluster is deleted.
                                                          • Check whether the cluster key CRD network-attachment-definitions.k8s.cni.cncf.io is deleted.
                                                          
+
                                                          Node Disk
                                                          
+
                                                          • Check whether the key data disks on the node meet the upgrade requirements.
                                                          • Check whether the /tmp directory has 500 MB available space.
                                                          
+
                                                          Node DNS
                                                          
+
                                                          • Check whether the DNS configuration of the current node can resolve the OBS address.
                                                          • Check whether the current node can access the OBS address of the storage upgrade component package.
                                                          
+
                                                          Node Key Directory File Permissions
                                                          
+
                                                          Check whether the key directory /var/paas on the nodes contain files with abnormal owners or owner groups.
                                                          
+
                                                          Kubelet
                                                          
+
                                                          Check whether the kubelet on the node is running properly.
                                                          
+
                                                          Node Memory
                                                          
+
                                                          Check whether the memory usage of the node exceeds 90%.
                                                          
+
                                                          Node Clock Synchronization Server
                                                          
+
                                                          Check whether the clock synchronization server ntpd or chronyd of the node is running properly.
                                                          
+
                                                          Node OS
                                                          
+
                                                          Check whether the OS kernel version of the node is supported by CCE.
                                                          
+
                                                          Node CPU Count
                                                          
+
                                                          Check whether the number of CPUs on the master node is greater than 2.
                                                          
+
                                                          Node Python Command
                                                          
+
                                                          Check whether the Python commands are available on a node.
                                                          
+
                                                          Node Readiness
                                                          
+
                                                          Check whether the nodes in the cluster are ready.
                                                          
+
                                                          Node journald
                                                          
+
                                                          Check whether journald of a node is normal.
                                                          
+
                                                          containerd.sock Check
                                                          
+
                                                          Check whether the containerd.sock file exists on the node. This file affects the startup of container runtime in the Euler OS.
                                                          
+
                                                          Internal Error
                                                          
+
                                                          Before the upgrade, check whether an internal error occurs.
                                                          
+
                                                          Node Mount Point
                                                          
+
                                                          Check whether inaccessible mount points exist on the node.
                                                          
+
                                                          Kubernetes Node Taint
                                                          
+
                                                          Check whether the taint needed for cluster upgrade exists on the node.
                                                          
+
                                                          everest Restriction Check
                                                          
+
                                                          Check whether the current everest add-on has compatibility restrictions.
                                                          
+
                                                          cce-hpa-controller Restriction Check
                                                          
+
                                                          Check whether the current cce-controller-hpa add-on has compatibility restrictions.
                                                          
+
                                                          Enhanced CPU Management Policy
                                                          
+
                                                          Check whether the current cluster version and the target version support enhanced CPU policy.
                                                          
+
                                                          User Node Components Health
                                                          
+
                                                          Check whether the container runtime and network components on the user node are healthy.
                                                          
+
                                                          Controller Node Components Health
                                                          
+
                                                          Check whether the Kubernetes, container runtime, and network components of the controller node are healthy.
                                                          
+
                                                          Memory Resource Limit of Kubernetes Components
                                                          
+
                                                          Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit.
                                                          
+
                                                          Checking Deprecated Kubernetes APIs
                                                          
+
                                                          Check whether the called API has been discarded in the target Kubernetes version.
                                                          
+
                                                          IPv6 Capability of a CCE Turbo Cluster
                                                          
+
                                                          If IPv6 is enabled for a CCE Turbo cluster, check whether the target cluster version supports IPv6.
                                                          
+
                                                          Node NetworkManager
                                                          
+
                                                          Check whether NetworkManager of a node is normal.
                                                          
+
                                                          Node ID File
                                                          
+
                                                          Check the ID file format.
                                                          
+
                                                          Node Configuration Consistency
                                                          
+
                                                          When you upgrade a CCE cluster to v1.19 or later, the system checks whether the following configuration files have been modified in the background:
                                                          
+
                                                          Node Configuration File
                                                          
+
                                                          Check whether the configuration files of key components exist on the node.
                                                          
+
                                                          Checking CoreDNS Configuration Consistency
                                                          
+
                                                          Check whether the current CoreDNS key configuration Corefile is different from the Helm release record. The difference may be overwritten during the add-on upgrade, affecting domain name resolution in the cluster.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0550.html b/docs/cce/umn/cce_10_0550.html
new file mode 100644
index 00000000..961e2919
--- /dev/null
+++ b/docs/cce/umn/cce_10_0550.html
@@ -0,0 +1,98 @@
+
+
+
                                                          Troubleshooting for Pre-upgrade Check Exceptions
                                                          
+
                                                          
+
                                                          
+
                                                          
+
+
+
                                                          
+
                                                          Parent topic: Upgrading a Cluster
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0560.html b/docs/cce/umn/cce_10_0560.html
new file mode 100644
index 00000000..4f0fab10
--- /dev/null
+++ b/docs/cce/umn/cce_10_0560.html
@@ -0,0 +1,28 @@
+
+
+
                                                          Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_10_0561.html b/docs/cce/umn/cce_10_0561.html
new file mode 100644
index 00000000..f2717379
--- /dev/null
+++ b/docs/cce/umn/cce_10_0561.html
@@ -0,0 +1,18 @@
+
+
+
                                                          Service Verification
                                                          
+
                                                          Check Item
                                                          After the cluster is upgraded, check whether the services are running normal.
                                                          
+
                                                          
+
                                                          Procedure
                                                          Different services have different verification mode. Select a suitable one and verify the service before and after the upgrade.
                                                          
+
                                                          You can verify the service from the following aspects:
                                                          
+
                                                          • The service page is available.
                                                          • No alarm or event is generated on the normal platform.
                                                          • No error log is generated for key processes.
                                                          • The API dialing test is normal.
                                                          
+
                                                          
+
                                                          Solution
                                                          If your online services are abnormal after the cluster upgrade, contact technical support.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0562.html b/docs/cce/umn/cce_10_0562.html
new file mode 100644
index 00000000..bcd613dd
--- /dev/null
+++ b/docs/cce/umn/cce_10_0562.html
@@ -0,0 +1,19 @@
+
+
+
                                                          Pod Check
                                                          
+
                                                          Check Item
                                                          • Check whether unexpected pods exist in the cluster.
                                                          • Check whether there are pods restart unexpectedly in the cluster.
                                                          
+
                                                          
+
                                                          Procedure
                                                          Go to the CCE console and access the cluster console. Choose Workloads in the navigation pane. On the displayed page, switch to the Pods tab page. Select All namespaces, click Status, and check whether abnormal pods exist.
                                                          
+
                                                          
+
                                                          View the Restarts column to check whether there are pods that are restarted abnormally.
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          If there are abnormal pods in your cluster after the cluster upgrade, contact technical support.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0563.html b/docs/cce/umn/cce_10_0563.html
new file mode 100644
index 00000000..f8787dce
--- /dev/null
+++ b/docs/cce/umn/cce_10_0563.html
@@ -0,0 +1,135 @@
+
+
+
                                                          Node and Container Network Check
                                                          
+
                                                          Check Item
                                                          • Check whether the nodes are running properly.
                                                          • Check whether the node network is normal.
                                                          • Check whether the container network is normal.
                                                          
+
                                                          
+
                                                          Procedure
                                                          The node status reflects whether the node component or network is normal.
                                                          
+
                                                          Go to the CCE console and access the cluster console. Choose Nodes in the navigation pane. You can filter node status by status to check whether there are abnormal nodes.
                                                          
+
                                                          
+
                                                          The container network affects services. Check whether your services are available.
                                                          
+
                                                          
+
                                                          Solution
                                                          If the node status is abnormal, contact technical support.
                                                          
+
                                                          If the container network is abnormal and your services are affected, contact technical support and confirm the abnormal network access path.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Source
                                                          
+
                                                          Destination
                                                          
+
                                                          Destination Type
                                                          
+
                                                          Possible Fault
                                                          
+
                                                          • Pods (inside a cluster)
                                                          • Nodes (inside a cluster)
                                                          • Nodes in the same VPC (outside a cluster)
                                                          • Third-party clouds
                                                          
+
                                                          
+
                                                          Public IP address of Service ELB
                                                          
+
                                                          Cluster traffic load balancing entry
                                                          
+
                                                          No record.
                                                          
+
                                                          Private IP address of Service ELB
                                                          
+
                                                          Cluster traffic load balancing entry
                                                          
+
                                                          No record.
                                                          
+
                                                          Public IP address of ingress ELB
                                                          
+
                                                          Cluster traffic load balancing entry
                                                          
+
                                                          No record.
                                                          
+
                                                          Private IP address of ingress ELB
                                                          
+
                                                          Cluster traffic load balancing entry
                                                          
+
                                                          No record.
                                                          
+
                                                          Public IP address of NodePort Service
                                                          
+
                                                          Cluster traffic entry
                                                          
+
                                                          The kube proxy configuration is overwritten. This fault has been rectified in the upgrade process.
                                                          
+
                                                          Private IP address of NodePort Service
                                                          
+
                                                          Cluster traffic entry
                                                          
+
                                                          No record.
                                                          
+
                                                          ClusterIP Service
                                                          
+
                                                          Service network plane
                                                          
+
                                                          No record.
                                                          
+
                                                          Non NodePort Service port
                                                          
+
                                                          Container network
                                                          
+
                                                          No record.
                                                          
+
                                                          Cross-node pods
                                                          
+
                                                          Container network plane
                                                          
+
                                                          No record.
                                                          
+
                                                          Pods on the same node
                                                          
+
                                                          Container network plane
                                                          
+
                                                          No record.
                                                          
+
                                                          Service and pod domain names are resolved by CoreDNS.
                                                          
+
                                                          Domain name resolution
                                                          
+
                                                          No record.
                                                          
+
                                                          External domain names are resolved based on the CoreDNS hosts configuration.
                                                          
+
                                                          Domain name resolution
                                                          
+
                                                          After the coredns add-on is upgraded, the configuration is overwritten. This fault has been rectified in the add-on upgrade process.
                                                          
+
                                                          External domain names are resolved based on the CoreDNS upstream server.
                                                          
+
                                                          Domain name resolution
                                                          
+
                                                          After the coredns add-on is upgraded, the configuration is overwritten. This fault has been rectified in the add-on upgrade process.
                                                          
+
                                                          External domain names are not resolved by CoreDNS.
                                                          
+
                                                          Domain name resolution
                                                          
+
                                                          No record.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0564.html b/docs/cce/umn/cce_10_0564.html
new file mode 100644
index 00000000..15c8e73f
--- /dev/null
+++ b/docs/cce/umn/cce_10_0564.html
@@ -0,0 +1,20 @@
+
+
+
                                                          Node Label and Taint Check
                                                          
+
                                                          Check Item
                                                          • Check whether the label is lost.
                                                          • Check whether there are unexpected taints.
                                                          
+
                                                          
+
                                                          Procedure
                                                          Go to the CCE console, access the cluster console, and choose Nodes in the navigation pane. On the displayed page, click the Nodes tab, select all nodes, and click Manage Labels and Taints to view the labels and taints of the current node.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          User labels are not changed during the cluster upgrade. If you find that labels are lost or added abnormally, contact technical support.
                                                          
+
                                                          If you find a new taint (node.kubernetes.io/upgrade) on a node, the node may be skipped during the upgrade. For details, see Node Skipping Check for Reset.
                                                          
+
                                                          If you find that other taints are added to the node, contact technical support.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0565.html b/docs/cce/umn/cce_10_0565.html
new file mode 100644
index 00000000..4e41622a
--- /dev/null
+++ b/docs/cce/umn/cce_10_0565.html
@@ -0,0 +1,17 @@
+
+
+
                                                          New Node Check
                                                          
+
                                                          Check Item
                                                          Check whether nodes can be created in the cluster.
                                                          
+
                                                          
+
                                                          Procedure
                                                          Go to the CCE console and access the cluster console. Choose Nodes in the navigation pane, and click Create Node.
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          If nodes cannot be created in your cluster after the cluster is upgraded, contact technical support.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0566.html b/docs/cce/umn/cce_10_0566.html
new file mode 100644
index 00000000..49d8c00e
--- /dev/null
+++ b/docs/cce/umn/cce_10_0566.html
@@ -0,0 +1,51 @@
+
+
+
                                                          New Pod Check
                                                          
+
                                                          Check Item
                                                          • Check whether pods can be created on the existing nodes after the cluster is upgraded.
                                                          • Check whether pods can be created on new nodes after the cluster is upgraded.
                                                          
+
                                                          
+
                                                          Procedure
                                                          After creating a node based on New Node Check, create a DaemonSet workload to create pods on each node.
                                                          
+
                                                          Go to the CCE console, access the cluster console, and choose Workloads in the navigation pane. On the displayed page, switch to the DaemonSets tab page and click Create Workload or Create from YAML in the upper right corner.
                                                          
+
                                                          
+
                                                          You are advised to use the image for routine tests as the base image. You can deploy a pod by referring to the following YAML file.
                                                          
+
                                                           
                                                          In this test, YAML deploys DaemonSet in the default namespace, uses ngxin:perl as the base image, requests 10 MB CPU and 10 Mi memory, and limits 100 MB CPU and 50 Mi memory.
                                                          
+
                                                          
+
                                                          apiVersion: apps/v1
+kind: DaemonSet
+metadata:
+  name: post-upgrade-check
+  namespace: default
+spec:
+  selector:
+    matchLabels:
+      app: post-upgrade-check
+      version: v1
+  template:
+    metadata:
+      labels:
+        app: post-upgrade-check
+        version: v1
+    spec:
+      containers:
+        - name: container-1
+          image: nginx:perl
+          imagePullPolicy: IfNotPresent
+          resources:
+            requests:
+              cpu: 10m
+              memory: 10Mi
+            limits:
+              cpu: 100m
+              memory: 50Mi
                                                          
+
                                                          After the workload is created, check whether the pod status of the workload is normal.
                                                          
+
                                                          After the check is complete, go to the CCE console and access the cluster console. Choose Workloads in the navigation pane. On the displayed page, switch to the DaemonSets tab page, choose More > Delete in the Operation column of the post-upgrade-check workload to delete the test workload.
                                                          
+
                                                          
+
                                                          
+
                                                          Solution
                                                          If the pod cannot be created or the pod status is abnormal, contact technical support and specify whether the exception occurs on new nodes or existing nodes.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0567.html b/docs/cce/umn/cce_10_0567.html
new file mode 100644
index 00000000..7097d0fe
--- /dev/null
+++ b/docs/cce/umn/cce_10_0567.html
@@ -0,0 +1,20 @@
+
+
+
                                                          Node Skipping Check for Reset
                                                          
+
                                                          Check Item
                                                          After the cluster is upgraded, you need to reset the nodes that fail to be upgraded.
                                                          
+
                                                          
+
                                                          Procedure
                                                          Go back to the previous step or view the upgrade details on the upgrade history page to view the nodes that are skipped during the upgrade.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          The skipped nodes are displayed on the upgrade details page. Reset the skipped nodes after the upgrade is complete. For details about how to reset a node, see Resetting a Node.
                                                          
+
                                                          
+
                                                           
                                                          Resetting a node will reset all node labels, which may affect workload scheduling. Before resetting a node, check and retain the labels that you have manually added to the node.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Post-Upgrade Verification
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_10_0602.html b/docs/cce/umn/cce_10_0602.html
index 4e68567a..efd78f0d 100644
--- a/docs/cce/umn/cce_10_0602.html
+++ b/docs/cce/umn/cce_10_0602.html
@@ -9,7 +9,7 @@
 
                                                          When creating a cluster of v1.23 or later, you can enable overload control during the cluster creation.
                                                          
 
                                                          
 
                                                          Method 2: Enabling it in an existing cluster
                                                          
-
                                                          1. Log in to the CCE console and go to an existing cluster whose version is v1.23 or later.
                                                          2. On the cluster information page, view the master node information. If overload control is not enabled, a message is displayed. You can click Enable to enable the function.
                                                            
+
                                                            1. Log in to the CCE console and go to an existing cluster whose version is v1.23 or later.
                                                            2. On the cluster information page, view the master node information. If overload control is not enabled, a message is displayed. You can click Enable to enable the function.
                                                              
 
                                                            
 
 
                                                            Disabling Cluster Overload Control
                                                            1. Log in to the CCE console and go to an existing cluster whose version is v1.23 or later.
                                                            2. On the Cluster Information page, click Manage in the upper right corner.
                                                            3. Set support-overload to false under kube-apiserver.
                                                            4. Click OK.
                                                            
diff --git a/docs/cce/umn/cce_10_0652.html b/docs/cce/umn/cce_10_0652.html
new file mode 100644
index 00000000..6bbfa8d6
--- /dev/null
+++ b/docs/cce/umn/cce_10_0652.html
@@ -0,0 +1,359 @@
+
+
+
                                                            Configuring a Node Pool
                                                            
+
                                                            Notes and Constraints
                                                            The default node pool DefaultPool does not support the following management operations.
                                                            
+
                                                            
+
                                                            Configuring Kubernetes Parameters
                                                            CCE allows you to highly customize Kubernetes parameter settings on core components in a cluster. For more information, see kubelet.
                                                            
+
                                                            This function is supported only in clusters of v1.15 and later. It is not displayed for clusters earlier than v1.15.
                                                            
+
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Choose More > Manage next to the node pool name.
                                                            4. On the Manage Component page on the right, change the values of the following Kubernetes parameters:
                                                              
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 1 kubelet
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Default Value
                                                              
+
                                                              Remarks
                                                              
+
                                                              cpu-manager-policy
                                                              
+
                                                              CPU management policy configuration. For details, see CPU Core Binding.
                                                              
+
                                                              • none: disables pods from exclusively occupying CPUs. Select this value if you want a large pool of shareable CPU cores.
                                                              • static: enables pods to exclusively occupy CPUs. Select this value if your workload is sensitive to latency in CPU cache and scheduling.
                                                              
+
                                                              none
                                                              
+
                                                              -
                                                              
+
                                                              kube-api-qps
                                                              
+
                                                              Query per second (QPS) to use while talking with kube-apiserver.
                                                              
+
                                                              100
                                                              
+
                                                              -
                                                              
+
                                                              kube-api-burst
                                                              
+
                                                              Burst to use while talking with kube-apiserver.
                                                              
+
                                                              100
                                                              
+
                                                              -
                                                              
+
                                                              max-pods
                                                              
+
                                                              Maximum number of pods managed by kubelet.
                                                              
+
                                                              40
                                                              
+
                                                              20
                                                              
+
                                                              -
                                                              
+
                                                              pod-pids-limit
                                                              
+
                                                              PID limit in Kubernetes
                                                              
+
                                                              -1
                                                              
+
                                                              -
                                                              
+
                                                              with-local-dns
                                                              
+
                                                              Whether to use the local IP address as the ClusterDNS of the node.
                                                              
+
                                                              false
                                                              
+
                                                              -
                                                              
+
                                                              event-qps
                                                              
+
                                                              QPS limit for event creation
                                                              
+
                                                              5
                                                              
+
                                                              -
                                                              
+
                                                              allowed-unsafe-sysctls
                                                              
+
                                                              Insecure system configuration allowed.
                                                              
+
                                                              Starting from v1.17.17, CCE enables pod security policies for kube-apiserver. You need to add corresponding configurations to allowedUnsafeSysctls of a pod security policy to make the policy take effect. (This configuration is not required for clusters earlier than v1.17.17.) For details, see Example of Enabling Unsafe Sysctls in Pod Security Policy.
                                                              
+
                                                              []
                                                              
+
                                                              -
                                                              
+
                                                              kube-reserved-mem
                                                              
+
                                                              system-reserved-mem
                                                              
+
                                                              Reserved node memory.
                                                              
+
                                                              Depends on node specifications. For details, see Formula for Calculating the Reserved Resources of a Node.
                                                              
+
                                                              The sum of kube-reserved-mem and system-reserved-mem is less than half of the memory.
                                                              
+
                                                              topology-manager-policy
                                                              
+
                                                              Set the topology management policy.
                                                              
+
                                                              Valid values are as follows:
                                                              
+
                                                              • restricted: kubelet accepts only pods that achieve optimal NUMA alignment on the requested resources.
                                                              • best-effort: kubelet preferentially selects pods that implement NUMA alignment on CPU and device resources.
                                                              • none (default): The topology management policy is disabled.
                                                              • single-numa-node: kubelet allows only pods that are aligned to the same NUMA node in terms of CPU and device resources.
                                                              
+
                                                              none
                                                              
+
                                                              The values can be modified during the node pool lifecycle.
                                                              
+
                                                               NOTICE: 
                                                              Exercise caution when modifying topology-manager-policy and topology-manager-scope will restart kubelet and recalculate the resource allocation of pods based on the modified policy. As a result, running pods may restart or even fail to receive any resources.
                                                              
+
                                                              
+
                                                              topology-manager-scope
                                                              
+
                                                              Set the resource alignment granularity of the topology management policy. Valid values are as follows:
                                                              
+
                                                              • container (default)
                                                              • pod
                                                              
+
                                                              Container
                                                              
+
                                                              resolv-conf
                                                              
+
                                                              DNS resolution configuration file specified by a container
                                                              
+
                                                              The default value is null.
                                                              
+
                                                              -
                                                              
+
                                                              runtime-request-timeout
                                                              
+
                                                              Timeout interval of all runtime requests except long-running requests (pull, logs, exec, and attach).
                                                              
+
                                                              The default value is 2m0s.
                                                              
+
                                                              -
                                                              
+
                                                              registry-pull-qps
                                                              
+
                                                              Maximum number of image pulls per second.
                                                              
+
                                                              The default value is 5.
                                                              
+
                                                              The value ranges from 1 to 50.
                                                              
+
                                                              registry-burst
                                                              
+
                                                              Maximum number of burst image pulls.
                                                              
+
                                                              The default value is 10.
                                                              
+
                                                              The value ranges from 1 to 100 and must be greater than or equal to the value of registry-pull-qps.
                                                              
+
                                                              serialize-image-pulls
                                                              
+
                                                              When this function is enabled, kubelet is notified to pull only one image at a time.
                                                              
+
                                                              The default value is true.
                                                              
+
                                                              -
                                                              
+
                                                              
+
                                                              
+
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 2 kube-proxy
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Default Value
                                                              
+
                                                              Remarks
                                                              
+
                                                              conntrack-min
                                                              
+
                                                              sysctl -w net.nf_conntrack_max
                                                              
+
                                                              131072
                                                              
+
                                                              -
                                                              
+
                                                              conntrack-tcp-timeout-close-wait
                                                              
+
                                                              sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait
                                                              
+
                                                              1h0m0s
                                                              
+
                                                              -
                                                              
+
                                                              
+
                                                              
+
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 3 Network components (available only for CCE Turbo clusters)
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Default Value
                                                              
+
                                                              Remarks
                                                              
+
                                                              nic-threshold
                                                              
+
                                                              Low threshold of the number of bound ENIs:High threshold of the number of bound ENIs
                                                              
+
                                                               NOTE: 
                                                              This parameter is being discarded. Use the dynamic pre-binding parameters of the other four ENIs.
                                                              
+
                                                              
+
                                                              Default: 0:0
                                                              
+
                                                              -
                                                              
+
                                                              nic-minimum-target
                                                              
+
                                                              Minimum number of ENIs bound to a node at the node pool level
                                                              
+
                                                              Default: 10
                                                              
+
                                                              -
                                                              
+
                                                              nic-maximum-target
                                                              
+
                                                              Maximum number of ENIs pre-bound to a node at the node pool level
                                                              
+
                                                              Default: 0
                                                              
+
                                                              -
                                                              
+
                                                              nic-warm-target
                                                              
+
                                                              Number of ENIs pre-bound to a node at the node pool level
                                                              
+
                                                              Default: 2
                                                              
+
                                                              -
                                                              
+
                                                              nic-max-above-warm-target
                                                              
+
                                                              Reclaim number of ENIs pre-bound to a node at the node pool level
                                                              
+
                                                              Default: 2
                                                              
+
                                                              -
                                                              
+
                                                              
+
                                                              
+
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 4 Pod security group in a node pool (available only for CCE Turbo clusters)
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Default Value
                                                              
+
                                                              Remarks
                                                              
+
                                                              security_groups_for_nodepool
                                                              
+
                                                              • Default security group used by pods in a node pool. You can enter the security group ID. If this parameter is not set, the default security group of the cluster container network is used. A maximum of five security group IDs can be specified at the same time, separated by semicolons (;).
                                                              • The priority of the security group is lower than that of the security group configured for Security Groups.
                                                              
+
                                                              -
                                                              
+
                                                              -
                                                              
+
                                                              
+
                                                              
+
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 5 Docker (available only for node pools that use Docker)
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Default Value
                                                              
+
                                                              Remarks
                                                              
+
                                                              native-umask
                                                              
+
                                                              `--exec-opt native.umask
                                                              
+
                                                              normal
                                                              
+
                                                              Cannot be changed.
                                                              
+
                                                              docker-base-size
                                                              
+
                                                              `--storage-opts dm.basesize
                                                              
+
                                                              0
                                                              
+
                                                              Cannot be changed.
                                                              
+
                                                              insecure-registry
                                                              
+
                                                              Address of an insecure image registry
                                                              
+
                                                              false
                                                              
+
                                                              Cannot be changed.
                                                              
+
                                                              limitcore
                                                              
+
                                                              Maximum size of a core file in a container. The unit is byte.
                                                              
+
                                                              If not specified, the value is infinity.
                                                              
+
                                                              5368709120
                                                              
+
                                                              -
                                                              
+
                                                              default-ulimit-nofile
                                                              
+
                                                              Limit on the number of handles in a container
                                                              
+
                                                              {soft}:{hard}
                                                              
+
                                                              The value cannot exceed the value of the kernel parameter nr_open and cannot be a negative number.
                                                              
+
                                                              You can run the following command to obtain the kernel parameter nr_open:
                                                              
+
                                                              sysctl -a | grep nr_open
                                                              
+
                                                              
+
                                                              
+
                                                            5. Click OK.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0653.html b/docs/cce/umn/cce_10_0653.html
new file mode 100644
index 00000000..60434d07
--- /dev/null
+++ b/docs/cce/umn/cce_10_0653.html
@@ -0,0 +1,89 @@
+
+
+
                                                            Updating a Node Pool
                                                            
+
                                                            Constraints
                                                            • When editing the resource tags of the node pool. The modified configuration takes effect only for new nodes. To synchronize the configuration to the existing nodes, you need to manually reset the existing nodes.
                                                            • Updates of kubernetes labels and taints are automatically synchronized to existing nodes. You do not need to reset nodes.
                                                            
+
                                                            
+
                                                            Updating a Node Pool
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Click Update next to the name of the node pool you will edit. Configure the parameters in the displayed Update Node Pool page.
                                                              Basic Settings
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 1 Basic settings
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Node Pool Name
                                                              
+
                                                              Name of the node pool.
                                                              
+
                                                              Nodes
                                                              
+
                                                              Modify the number of nodes based on service requirements.
                                                              
+
                                                              Auto Scaling
                                                              
+
                                                              By default, this parameter is disabled.
                                                              
+
                                                              After you enable autoscaler by clicking , nodes in the node pool are automatically created or deleted based on service requirements.
                                                              
+
                                                              • Maximum Nodes and Minimum Nodes: You can set the maximum and minimum number of nodes to ensure that the number of nodes to be scaled is within a proper range.
                                                              • Priority: A larger value indicates a higher priority. For example, if this parameter is set to 1 and 4 respectively for node pools A and B, B has a higher priority than A, and auto scaling is first triggered for B. If the priorities of multiple node pools are set to the same value, for example, 2, the node pools are not prioritized and the system performs scaling based on the minimum resource waste principle.
                                                                After the priority is updated, the configuration takes effect within 1 minute.
                                                                
+
                                                              • Cooldown Period: Enter a period, in minutes. This field indicates the period during which the nodes added in the current node pool cannot be scaled in.
                                                              
+
                                                              If the Autoscaler field is set to on, install the autoscaler add-on to use the autoscaler feature.
                                                              
+
                                                              
+
                                                              
+
                                                              
+
                                                              Advanced Settings
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 2 Advanced settings
                                                              Parameter
                                                              
+
                                                              Description
                                                              
+
                                                              Kubernetes Label
                                                              
+
                                                              Click Add Label to set the key-value pair attached to the Kubernetes objects (such as pods). A maximum of 20 labels can be added.
                                                              
+
                                                              Labels can be used to distinguish nodes. With workload affinity settings, container pods can be scheduled to a specified node. For more information, see Labels and Selectors.
                                                              
+
                                                               NOTE: 
                                                              After a Kubernetes label is modified, the inventory nodes in the node pool are updated synchronously.
                                                              
+
                                                              
+
                                                              Resource Tag
                                                              
+
                                                              You can add resource tags to classify resources.
                                                              
+
                                                              You can create predefined tags in Tag Management Service (TMS). Predefined tags are visible to all service resources that support the tagging function. You can use these tags to improve tagging and resource migration efficiency. 
                                                              
+
                                                              CCE will automatically create the "CCE-Dynamic-Provisioning-Node=node id" tag.
                                                              
+
                                                               NOTE: 
                                                              After a resource tag is modified, the modification automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the modification to take effect.
                                                              
+
                                                              
+
                                                              Taint
                                                              
+
                                                              This field is left blank by default. You can add taints to set anti-affinity for the node. A maximum of 10 taints are allowed for each node. Each taint contains the following parameters:
                                                              • Key: A key must contain 1 to 63 characters, starting with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed. A DNS subdomain name can be used as the prefix of a key.
                                                              • Value: A value must start with a letter or digit and can contain a maximum of 63 characters, including letters, digits, hyphens (-), underscores (_), and periods (.).
                                                              • Effect: Available options are NoSchedule, PreferNoSchedule, and NoExecute.
                                                              
+
                                                              
+
                                                              For details, see Managing Node Taints.
                                                              
+
                                                               NOTE: 
                                                              After a taint is modified, the inventory nodes in the node pool are updated synchronously.
                                                              
+
                                                              
+
                                                              Edit Key pair
                                                              
+
                                                              Only node pools that use key pairs for login support key pair editing. You can select another key pair.
                                                              
+
                                                               NOTE: 
                                                              The edited key pair automatically takes effect when a node is added. For existing nodes, you need to manually reset the nodes for the key pair to take effect.
                                                              
+
                                                              
+
                                                              
+
                                                              
+
                                                              
+
                                                            4. When the configuration is complete, click OK.
                                                              After the node pool parameters are updated, go to the Nodes page to check whether the node to which the node pool belongs is updated. You can reset the node to synchronize the configuration updates for the node pool.
                                                              
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0654.html b/docs/cce/umn/cce_10_0654.html
new file mode 100644
index 00000000..9c8a6730
--- /dev/null
+++ b/docs/cce/umn/cce_10_0654.html
@@ -0,0 +1,19 @@
+
+
+
                                                            Synchronizing Node Pools
                                                            
+
                                                            After the configuration of a node pool is updated, some configurations cannot be automatically synchronized for existing nodes. You can manually synchronize configurations for these nodes.
                                                            
+
                                                             
                                                            • Do not delete or reset nodes during batch synchronization. Otherwise, the synchronization of node pool configuration may fail.
                                                            • This operation involves resetting nodes. Workload services running on the nodes may be interrupted due to single-instance deployment or insufficient schedulable resources. Evaluate the upgrade risks and perform the upgrade during off-peak hours. You can also specify a disruption budget for your application) to ensure the availability of key services during the upgrade.
                                                            • During configuration synchronization for existing nodes, the system disk and data disk will be cleared. Back up important data before the synchronization.
                                                            • Only some node pool parameters can be synchronized by resetting nodes. The constraints are as follows:
                                                              • When editing the resource tags of the node pool. The modified configuration takes effect only for new nodes. To synchronize the configuration to the existing nodes, you need to manually reset the existing nodes.
                                                              • Updates of kubernetes labels and taints are automatically synchronized to existing nodes. You do not need to reset nodes.
                                                              
+
                                                            
+
                                                            
+
                                                            Synchronizing a Single Node
                                                            1. Log in to the CCE console.
                                                            2. Access the cluster console, choose Nodes in the navigation pane, and click the Node Pools tab on the right.
                                                            3. upgrade is displayed in the Node Pool column of the existing nodes in the node pool.
                                                            4. Click update. In the dialog box that is displayed, confirm whether to reset the node immediately.
                                                            
+
                                                            
+
                                                            Batch Synchronization
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Choose More > Synchronize in the Operation column of the target node pool.
                                                            4. In the Batch Synchronization window, set the synchronization parameters.
                                                              • Synchronization Policy: Node Reset is supported.
                                                              • Max. Nodes for Batch Synchronize: Nodes will be unavailable during synchronization in Node Reset mode. Set this parameter properly to prevent pod scheduling failures caused by too many unavailable nodes in the cluster.
                                                              
+
                                                            5. In the node list, select the nodes to be synchronized and click OK to start the synchronization.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0655.html b/docs/cce/umn/cce_10_0655.html
new file mode 100644
index 00000000..a70a8950
--- /dev/null
+++ b/docs/cce/umn/cce_10_0655.html
@@ -0,0 +1,12 @@
+
+
+
                                                            Copying a Node Pool
                                                            
+
                                                            You can copy the configuration of an existing node pool to create a new node pool on the CCE console.
                                                            
+
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Choose More > Copy next to a node pool name to copy the node pool.
                                                            4. The configurations of the selected node pool are replicated to the Clone Node Pool page. You can edit the configurations as required. For details about configuration items, see Creating a Node Pool. After confirming the configuration, click Next: Confirm.
                                                            5. On the Confirm page, confirm the node pool configuration and click Submit. Then, a new node pool is created based on the edited configuration.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0656.html b/docs/cce/umn/cce_10_0656.html
new file mode 100644
index 00000000..2a284daf
--- /dev/null
+++ b/docs/cce/umn/cce_10_0656.html
@@ -0,0 +1,14 @@
+
+
+
                                                            Migrating a Node
                                                            
+
                                                            Nodes in a node pool can be migrated. Currently, nodes in a node pool can be migrated only to the default node pool (defaultpool) in the same cluster.
                                                            
+
                                                            1. Log in to the CCE console and access the cluster console.
                                                            2. In the navigation pane, choose Nodes and switch to the Node Pools tab page.
                                                            3. Click View Node in the Operation column of the node pool to be migrated.
                                                            4. Click More > Migrate in the Operation column of the target node to migrate the node.
                                                            5. In the displayed Migrate Node window, confirm the information.
                                                               
                                                              The migration has no impacts on the original resource tags, Kubernetes labels, and taints of the node.
                                                              
+
                                                              
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0657.html b/docs/cce/umn/cce_10_0657.html
new file mode 100644
index 00000000..ed54344a
--- /dev/null
+++ b/docs/cce/umn/cce_10_0657.html
@@ -0,0 +1,15 @@
+
+
+
                                                            Deleting a Node Pool
                                                            
+
                                                            Deleting a node pool will delete nodes in the pool. Pods on these nodes will be automatically migrated to available nodes in other node pools.
                                                            
+
                                                            Precautions
                                                            • Deleting a node pool will delete all nodes in the node pool. Back up data in a timely manner to prevent data loss.
                                                            • Deleting a node will lead to pod migration, which may affect services. Perform this operation during off-peak hours. If pods in the node pool have a specific node selector and none of the other nodes in the cluster satisfies the node selector, the pods will become unschedulable.
                                                            • When deleting a node pool, the system sets all nodes in the current node pool to the unschedulable state.
                                                            
+
                                                            
+
                                                            Procedure
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Choose More > Delete next to a node pool name to delete the node pool.
                                                            4. Read the precautions in the Delete Node Pool dialog box.
                                                            5. In the text box, click Yes to confirm that you want to continue the deletion.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0660.html b/docs/cce/umn/cce_10_0660.html
new file mode 100644
index 00000000..9a5544b4
--- /dev/null
+++ b/docs/cce/umn/cce_10_0660.html
@@ -0,0 +1,25 @@
+
+
+
                                                            Upgrading the OS
                                                            
+
                                                            When CCE releases a new OS image, existing nodes cannot be automatically upgraded. You can manually upgrade them in batches.
                                                            
+
                                                             
                                                            • This operation will upgrade the OS by resetting the node. Workloads running on the node may be interrupted due to single-instance deployment or insufficient schedulable resources. Evaluate the upgrade risks and upgrade the OS during off-peak hours, you can also set the Pod Disruption Budget (PDB, that is disruption budget) policy for important applications to ensure their availability.
                                                            • Nodes that use private images cannot be upgraded.
                                                            
+
                                                            
+
                                                            Procedure
                                                            Default node pool
                                                            
+
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Click Upgrade next to the default node pool
                                                            4. In the displayed Operating system upgrade window, set upgrade parameters.
                                                              • Max. Unavailable Nodes: specifies the maximum number of unavailable nodes during node synchronization.
                                                              • Target Operating System: You do not need to set this parameter. It is used to display the image information of the target version.
                                                              • Node List: Select the nodes to be upgraded.
                                                              • Login Mode:
                                                                • Key Pair
                                                                  Select the key pair used to log in to the node. You can select a shared key.
                                                                  
+
                                                                  A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair.
                                                                  
+
                                                                
+
                                                              • Pre-installation Command: Enter a maximum of 1,000 characters.
                                                                The script will be executed before Kubernetes software is installed. Note that if the script is incorrect, Kubernetes software may fail to be installed.
                                                                
+
                                                              • Post-installation Command: Enter a maximum of 1,000 characters.
                                                                The script will be executed after Kubernetes software is installed and will not affect the installation.
                                                                
+
                                                              
+
                                                            5. Click OK.
                                                            
+
                                                            Non-default node pool
                                                            
+
                                                            1. Log in to the CCE console.
                                                            2. Click the cluster name and access the cluster console. Choose Nodes in the navigation pane and click the Node Pools tab on the right.
                                                            3. Choose More > Synchronize next to a node pool name.
                                                            4. In the displayed Batch synchronization dialog box, set upgrade parameters.
                                                              • Max. Unavailable Nodes: specifies the maximum number of unavailable nodes during node synchronization.
                                                              • Node List: This parameter cannot be set. By default, nodes that can be upgraded are selected.
                                                              
+
                                                            5. Click OK.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Managing a Node Pool
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_10_0684.html b/docs/cce/umn/cce_10_0684.html
new file mode 100644
index 00000000..fdd323a3
--- /dev/null
+++ b/docs/cce/umn/cce_10_0684.html
@@ -0,0 +1,133 @@
+
+
+
                                                            Configuring Health Check for Multiple Ports
                                                            
+
                                                            The annotation field related to the health check of the LoadBalancer Service is upgraded from Kubernetes.io/elb.health-check-option to Kubernetes.io/elb.health-check-options. Each Service port can be configured separately, and you can configure only some ports. If the port protocol does not need to be configured separately, the original annotation field is still available and does not need to be modified.
                                                            
+
                                                            Constraints
                                                            • This feature takes effect only in the following versions:
                                                              • v1.19: v1.19.16-r5 or later
                                                              • v1.21: v1.21.8-r0 or later
                                                              • v1.23: v1.23.6-r0 or later
                                                              • v1.25: v1.25.2-r0 or later
                                                              
+
                                                            • kubernetes.io/elb.health-check-option and kubernetes.io/elb.health-check-options cannot be configured at the same time.
                                                            • The target_service_port field is mandatory and must be unique.
                                                            • For a TCP port, the health check protocol can only be TCP or HTTP. For a UDP port, the health check protocol must be UDP.
                                                            
+
                                                            
+
                                                            Procedure
                                                            The following is an example of using the kubernetes.io/elb.health-check-options annotation:
                                                            apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  namespace: default
+  labels: {}
+  annotations:
+    kubernetes.io/elb.class: union
+    kubernetes.io/elb.id: 038ffbda-bd3a-48bb-8b8c-a8582601fd97
+    kubernetes.io/elb.lb-algorithm: ROUND_ROBIN
+    kubernetes.io/elb.health-check-flag: 'on'
+    kubernetes.io/elb.health-check-options: '{
+    "target_service_port": "TCP:80", // (Mandatory) Port for health check specified by spec.ports. The value consists of the protocol and port number, for example, TCP:80.
+    "monitor_port": "",        // (Optional) Re-specified port for health check. If this parameter is not specified, the service port is used by default. Ensure that the port is in the listening state on the node where the pod is located. Otherwise, the health check result will be affected.
+    "protocol":"TCP",
+    "delay":"5",
+    "timeout":"10",
+    "max_retries":"3",
+    "path":"/"
+    }'
+spec:
+  selector: {}
+  externalTrafficPolicy: Cluster
+  ports:
+    - name: cce-service-0
+      targetPort: 80
+      nodePort: 0
+      port: 80
+      protocol: TCP
+  type: LoadBalancer
+  loadBalancerIP: **.**.**.**
                                                            
+
+
                                                            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                            Table 1 Data structure description of the elb.health-check-options field
                                                            Parameter
                                                            
+
                                                            Mandatory
                                                            
+
                                                            Type
                                                            
+
                                                            Description
                                                            
+
                                                            target_service_port
                                                            
+
                                                            Yes
                                                            
+
                                                            String
                                                            
+
                                                            Port for health check specified by spec.ports. The value consists of the protocol and port number, for example, TCP:80.
                                                            
+
                                                            monitor_port
                                                            
+
                                                            No
                                                            
+
                                                            String
                                                            
+
                                                            Re-specified port for health check. If this parameter is not specified, the service port is used by default.
                                                            
+
                                                             NOTE: 
                                                            Ensure that the port is in the listening state on the node where the pod is located. Otherwise, the health check result will be affected.
                                                            
+
                                                            
+
                                                            delay
                                                            
+
                                                            No
                                                            
+
                                                            String
                                                            
+
                                                            Initial waiting time (in seconds) for starting the health check.
                                                            
+
                                                            Value range: 1 to 50. Default value: 5
                                                            
+
                                                            timeout
                                                            
+
                                                            No
                                                            
+
                                                            String
                                                            
+
                                                            Health check timeout, in seconds.
                                                            
+
                                                            Value range: 1 to 50. Default value: 10
                                                            
+
                                                            max_retries
                                                            
+
                                                            No
                                                            
+
                                                            String
                                                            
+
                                                            Maximum number of health check retries.
                                                            
+
                                                            Value range: 1 to 10. Default value: 3
                                                            
+
                                                            protocol
                                                            
+
                                                            No
                                                            
+
                                                            String
                                                            
+
                                                            Health check protocol.
                                                            
+
                                                            Default value: protocol of the associated Service
                                                            
+
                                                            Value options: TCP, UDP, or HTTP
                                                            
+
                                                            path
                                                            
+
                                                            No
                                                            
+
                                                            String
                                                            
+
                                                            Health check URL. This parameter needs to be configured when the protocol is HTTP.
                                                            
+
                                                            Default value: /
                                                            
+
                                                            The value can contain 1 to 10,000 characters.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Services
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice.html b/docs/cce/umn/cce_bestpractice.html
index 73105f9e..86035399 100644
--- a/docs/cce/umn/cce_bestpractice.html
+++ b/docs/cce/umn/cce_bestpractice.html
@@ -10,6 +10,8 @@
 
 
                                                            
 
diff --git a/docs/cce/umn/cce_bestpractice_00004.html b/docs/cce/umn/cce_bestpractice_00004.html
index 9780e5bb..2449c71c 100644
--- a/docs/cce/umn/cce_bestpractice_00004.html
+++ b/docs/cce/umn/cce_bestpractice_00004.html
@@ -17,40 +17,40 @@
 
                                                            3. 
 
 
                                                            Single-VPC Single-Cluster Scenarios
                                                            CCE Clusters: include clusters in VPC network model and container tunnel network model. Figure 2 shows the CIDR block planning of a cluster.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: specifies the subnet CIDR block where the node in the cluster resides. The subnet CIDR block is included in the VPC CIDR block. Different nodes in the same cluster can be allocated to different subnet CIDR blocks.
                                                            • Container CIDR Block: cannot overlap with the subnet CIDR block.
                                                            • Service CIDR Block: cannot overlap with the subnet CIDR block or the container CIDR block.
                                                            
-
                                                            Figure 2 Network CIDR block planning in the single-VPC single-cluster scenario (CCE cluster)
                                                            
+
                                                            Figure 2 Network CIDR block planning in single-VPC single-cluster scenarios (CCE cluster)
                                                            
 
                                                            
-
                                                            Figure 3 shows the CIDR block planning for a CCE Turbo cluster (cloud native network 2.0).
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: specifies the subnet CIDR block where the node in the cluster resides. The subnet CIDR block is included in the VPC CIDR block. Different nodes in the same cluster can be allocated to different subnet CIDR blocks.
                                                            • Container Subnet CIDR Block: The container subnet is included in the VPC CIDR block and can overlap with the subnet CIDR block or even be the same as the subnet CIDR block. Note that the container subnet size determines the maximum number of containers in the cluster because IP addresses in the VPC are directly allocated to containers. After a cluster is created, you can only add container subnets but cannot delete them. You are advised to set a larger IP address segment for the container subnet to prevent insufficient container IP addresses.
                                                            • Service CIDR Block: cannot overlap with the subnet CIDR block or the container CIDR block.
                                                            
-
                                                            Figure 3 CIDR block planning in the single-VPC single-cluster scenario (CCE Turbo cluster)
                                                            
+
                                                            Figure 3 shows the CIDR block planning for a CCE Turbo cluster (Cloud Native Network 2.0).
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: specifies the subnet CIDR block where the node in the cluster resides. The subnet CIDR block is included in the VPC CIDR block. Different nodes in the same cluster can be allocated to different subnet CIDR blocks.
                                                            • Container Subnet CIDR Block: The container subnet is included in the VPC CIDR block and can overlap with the subnet CIDR block or even be the same as the subnet CIDR block. Note that the container subnet size determines the maximum number of containers in the cluster because IP addresses in the VPC are directly allocated to containers. After a cluster is created, you can only add container subnets but cannot delete them. You are advised to set a larger IP address segment for the container subnet to prevent insufficient container IP addresses.
                                                            • Service CIDR Block: cannot overlap with the subnet CIDR block or the container CIDR block.
                                                            
+
                                                            Figure 3 Network CIDR block planning in single-VPC single-cluster scenarios (CCE Turbo cluster)
                                                            
 
                                                            
 
                                                            
-
                                                            Single-VPC Multi-Cluster Scenarios
                                                            VPC network model
                                                            
-
                                                            Pod packets are forwarded through VPC routes. CCE automatically configures a routing table on the VPC routes to each container CIDR block. The network scale is limited by the VPC route table. Figure 4 shows the CIDR block planning of the cluster.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
                                                            • Container CIDR Block: If multiple VPC network model clusters exist in a single VPC, the container CIDR blocks of all clusters cannot overlap because the clusters use the same routing table. In this case, CCE clusters are partially interconnected. A pod of a cluster can directly access the pods of another cluster, but cannot access the Services of the cluster.
                                                            • Service CIDR Block: can be used only in clusters. Therefore, the service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster to which the clusters belong.
                                                            
+
                                                            Single-VPC Multi-Cluster Scenarios
                                                            VPC network model
                                                            
+
                                                            Pod packets are forwarded through VPC routes. CCE automatically configures a routing table on the VPC routes to each container CIDR block. The network scale is limited by the VPC route table. Figure 4 shows the CIDR block planning of the cluster.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
                                                            • Container CIDR Block: If multiple VPC network model clusters exist in a single VPC, the container CIDR blocks of all clusters cannot overlap because the clusters use the same routing table. In this case, CCE clusters are partially interconnected. A pod of a cluster can directly access the pods of another cluster, but cannot access the Services of the cluster.
                                                            • Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster.
                                                            
 
                                                            Figure 4 VPC network - multi-cluster scenario
                                                            
 
                                                            
 
                                                            Tunnel Network
                                                            
-
                                                            Though at some cost of performance, the tunnel encapsulation enables higher interoperability and compatibility with advanced features (such as network policy-based isolation), meeting the requirements of most applications. Figure 5 shows the CIDR block planning of the cluster.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
                                                            • Container CIDR Block: The container CIDR blocks of all clusters can overlap. In this case, pods in different clusters cannot be directly accessed using IP addresses. It is recommended that ELB be used for the cross-cluster access between containers.
                                                            • Service CIDR Block: can be used only in clusters. Therefore, the service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster to which the clusters belong.
                                                            
+
                                                            Though at some cost of performance, the tunnel encapsulation enables higher interoperability and compatibility with advanced features (such as network policy-based isolation), meeting the requirements of most applications. Figure 5 shows the CIDR block planning of the cluster.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
                                                            • Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
                                                            • Container CIDR Block: The container CIDR blocks of all clusters can overlap. In this case, pods in different clusters cannot be directly accessed using IP addresses. It is recommended that ELB be used for the cross-cluster access between containers.
                                                            • Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster.
                                                            
 
                                                            Figure 5 Tunnel network - multi-cluster scenario
                                                            
 
                                                            
-
                                                            Cloud native network 2.0 network model (CCE Turbo cluster)
                                                            
-
                                                            In this mode, container IP addresses are allocated from the VPC CIDR block. ELB passthrough networking is supported to direct access requests to containers. Security groups and multiple types of VPC networks can be bound to deliver high performance.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. In a CCE Turbo cluster, the CIDR block size affects the total number of nodes and containers that can be created in the cluster.
                                                            • Subnet CIDR Block: There is no special restriction on the subnet CIDR blocks in CCE Turbo clusters.
                                                            • Container Subnet: The CIDR block of the container subnet is included in the VPC CIDR block. Container subnets in different clusters can overlap with each other or overlap with the subnet CIDR block. However, you are advised to stagger the container CIDR blocks of different clusters and ensure that the container subnet CIDR blocks have sufficient IP addresses. In this case, pods in different clusters can directly access each other through IP addresses.
                                                            • Service CIDR Block: can be used only in clusters. Therefore, the service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block or container CIDR block.
                                                            
-
                                                            Figure 6 Cloud native network 2.0 network model - multi-cluster scenario
                                                            
+
                                                            Cloud Native Network 2.0 Model (CCE Turbo cluster)
                                                            
+
                                                            In this mode, container IP addresses are allocated from the VPC CIDR block. ELB passthrough networking is supported to direct access requests to containers. Security groups and multiple types of VPC networks can be bound to deliver high performance.
                                                            • VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. In a CCE Turbo cluster, the CIDR block size affects the total number of nodes and containers that can be created in the cluster.
                                                            • Subnet CIDR Block: There is no special restriction on the subnet CIDR blocks in CCE Turbo clusters.
                                                            • Container Subnet: The CIDR block of the container subnet is included in the VPC CIDR block. Container subnets in different clusters can overlap with each other or overlap with the subnet CIDR block. However, you are advised to stagger the container CIDR blocks of different clusters and ensure that the container subnet CIDR blocks have sufficient IP addresses. In this case, pods in different clusters can directly access each other through IP addresses.
                                                            • Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the subnet CIDR block and container subnet CIDR block of the cluster.
                                                            
+
                                                            Figure 6 Cloud Native Network 2.0 - multi-cluster scenario
                                                            
 
                                                            
 
                                                            Coexistence of Clusters in Multi-Network
                                                            
 
                                                            When a VPC contains clusters created with different network models, comply with the following rules when creating a cluster:
                                                            
-
                                                            • VPC CIDR Block: In this scenario, all clusters are located in the same VPC CIDR block. Ensure that there are sufficient available IP addresses in the VPC.
                                                            • Subnet CIDR Block: Ensure that the subnet CIDR block does not overlap with the container CIDR block. Even in some scenarios (for example, coexistence with CCE Turbo clusters), the subnet CIDR block can overlap with the container (subnet) CIDR block. However, this is not recommended.
                                                            • Container CIDR Block: Ensure that the container CIDR blocks of clusters in VPC network model do not overlap.
                                                            • Service CIDR Block: The service CIDR blocks of all clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster.
                                                            
+
                                                            • VPC CIDR Block: In this scenario, all clusters are located in the same VPC CIDR block. Ensure that there are sufficient available IP addresses in the VPC.
                                                            • Subnet CIDR Block: Ensure that the subnet CIDR block does not overlap with the container CIDR block. Even in some scenarios (for example, coexistence with CCE Turbo clusters), the subnet CIDR block can overlap with the container (subnet) CIDR block. However, this is not recommended.
                                                            • Container CIDR Block: Ensure that the container CIDR blocks of clusters in VPC network model do not overlap.
                                                            • Service CIDR Block: The Service CIDR blocks of all clusters can overlap, but cannot overlap with the subnet CIDR block and container CIDR block of the cluster.
                                                            
 
                                                            
 
                                                            Cross-VPC Cluster Interconnection
                                                            When two VPC networks are interconnected, you can configure the packets to be sent to the peer VPC in the route table.
                                                            
 
                                                            In the VPC network model, after creating a peering connection, you need to add routes for the peering connection to enable communication between the two VPCs.
                                                            
-
                                                            Figure 7 VPC Network - VPC interconnection scenario
                                                            
+
                                                            Figure 7 VPC network - VPC interconnection scenario
                                                            
 
                                                            When creating a VPC peering connection between containers across VPCs, pay attention to the following points:
                                                            
-
                                                            • The VPC to which the clusters belong must not overlap. In each cluster, the subnet CIDR block cannot overlap with the container CIDR block.
                                                            • The container CIDR blocks of clusters cannot overlap, but the Service CIDR blocks can.
                                                            • You need to add not only the peer VPC CIDR block but also the peer container CIDR block to the VPC routing tables at both ends. Note that this operation must be performed in the VPC route tables of the clusters.
                                                            
+
                                                            • The VPC to which the clusters belong must not overlap. In each cluster, the subnet CIDR block cannot overlap with the container CIDR block.
                                                            • The container CIDR blocks of clusters at both ends cannot overlap, but the Service CIDR blocks can.
                                                            • You need to add not only the peer VPC CIDR block but also the peer container CIDR block to the VPC routing tables at both ends. Note that this operation must be performed in the VPC route tables of the clusters.
                                                            
 
                                                            In the tunnel network model, after creating a peering connection, you need to add routes for the peering connection to enable communication between the two VPCs.
                                                            
 
                                                            Figure 8 Tunnel network - VPC interconnection scenario
                                                            
 
                                                            Pay attention to the following:
                                                            
-
                                                            • The VPC of the clusters must not overlap.
                                                            • The container CIDR blocks of all clusters can overlap, so do the Service CIDR blocks.
                                                            • Add the peer subnet CIDR block to the route table of the VPC peering connection.
                                                            
-
                                                            In Cloud Native Network 2.0 mode, after creating a VPC peering connection, you only need to add routes for the VPC peering connection to enable communication between the two VPCs. Ensure that the VPC of the clusters does not overlap.
                                                            
+
                                                            • The VPCs of the clusters must not overlap.
                                                            • The container CIDR blocks of all clusters can overlap, so do the Service CIDR blocks.
                                                            • Add the peer subnet CIDR block to the route table of the VPC peering connection.
                                                            
+
                                                            In Cloud Native Network 2.0 mode, after creating a VPC peering connection, you only need to add routes for the VPC peering connection to enable communication between the two VPCs. Ensure that the VPCs of the clusters do not overlap.
                                                            
 
                                                            
-
                                                            VPC-IDC Scenarios
                                                            Similar to the VPC interconnection scenario, some CIDR blocks in the VPC are routed to the IDC. The pod IP addresses of CCE clusters cannot overlap with the addresses within these CIDR blocks. To access the pod IP addresses in the cluster in the IDC, you need to configure the route table to the private line VBR on the IDC.
                                                            
+
                                                            VPC-IDC Scenarios
                                                            Similar to the VPC interconnection scenario, some CIDR blocks in the VPC are routed to the IDC. The pod IP addresses of CCE clusters cannot overlap with the addresses within these CIDR blocks. To access the pod IP addresses in the cluster in the IDC, you need to configure the route table to the private line VBR on the IDC.
                                                            
 
                                                            
 
                                                            
 
                                                            
diff --git a/docs/cce/umn/cce_bestpractice_00006.html b/docs/cce/umn/cce_bestpractice_00006.html
index 171079eb..bc521340 100644
--- a/docs/cce/umn/cce_bestpractice_00006.html
+++ b/docs/cce/umn/cce_bestpractice_00006.html
@@ -1,7 +1,7 @@
 
 
 
                                                            Checklist for Deploying Containerized Applications in the Cloud
                                                            
-
                                                            Overview
                                                            Security, efficiency, stability, and availability are common requirements on all cloud services. To meet these requirements, the system availability, data reliability, and O&M stability must be perfectly coordinated. This checklist describes the check items for deploying containerized applications on the cloud to help you efficiently migrate services to CCE, reducing potential cluster or application exceptions caused by improper use.
                                                            
+
                                                            Overview
                                                            Security, efficiency, stability, and availability are common requirements on all cloud services. To meet these requirements, the system availability, data reliability, and O&M stability must be coordinated. This checklist describes the check items for deploying containerized applications on the cloud to help you efficiently migrate services to CCE, reducing potential cluster or application exceptions caused by improper use.
                                                            
 
                                                            
 
                                                            Check Items
                                                            
 
                                                            
-
diff --git a/docs/cce/umn/cce_bestpractice_0001.html b/docs/cce/umn/cce_bestpractice_0001.html
new file mode 100644
index 00000000..8efcb8ac
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0001.html
@@ -0,0 +1,17 @@
+
+
+
                                                            Containerizing an Enterprise Application (ERP)
                                                            
+
                                                            
+
                                                            
+
+
+
                                                            
+
                                                            Parent topic: Containerization
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0002.html b/docs/cce/umn/cce_bestpractice_0002.html
new file mode 100644
index 00000000..a5942f13
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0002.html
@@ -0,0 +1,61 @@
+
+
+
                                                            Solution Overview
                                                            
+
                                                            This chapter provides CCE best practices to walk you through the application containerization.
                                                            
+
                                                            What Is a Container?
                                                            A container is a lightweight high-performance resource isolation mechanism implemented based on the Linux kernel. It is a built-in capability of the operating system (OS) kernel. 
                                                            
+
                                                            CCE is an enterprise-class container service based on open-source Kubernetes. It is a high-performance and 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 in the cloud.
                                                            
+
                                                            
+
                                                            Why Is a Container Preferred?
                                                            • More efficient use of system resources
                                                              A container does not require extra costs such as fees for hardware virtualization and those for running a complete OS. Therefore, a container has higher resource usage. Compared with a VM with the same configurations, a container can run more applications. 
                                                              
+
                                                            • Faster startup
                                                              A container directly runs on the host kernel and does not need to start a complete OS. Therefore, a container can be started within seconds or even milliseconds, greatly saving the development, testing, and deployment time. 
                                                              
+
                                                            • Consistent runtime environment
                                                              A container image provides a complete runtime environment to ensure environment consistency. In this case, problems (for example, some code runs properly on machine A but fails to run on machine B) will not occur.
                                                              
+
                                                            • Easier application migration, maintenance, and scaling
                                                              A consistent runtime environment makes application migration easier. In addition, the in-use storage and image technologies facilitate the reuse of repeated applications and simplifies the expansion of images based on base images.
                                                              
+
                                                            
+
                                                            
+
                                                            Containerization Modes
                                                            The following modes are available for containerizing applications:
                                                            
+
                                                            
+
                                                            • Mode 1: Containerize a single application as a whole. Application code and architecture remain unchanged.
                                                            • Mode 2: Separate the components that are frequently upgraded or have high requirements on auto scaling from an application, and then containerize these components.
                                                            • Mode 3: Transform an application to microservices and then containerize the microservices one by one.
                                                            
+
                                                            Table 1 lists the advantages and disadvantages of the three modes.
                                                            
+
+
                                                            Table 1 System availability
                                                            Category
                                                            
@@ -166,7 +166,8 @@
 
                                                            
 
                                                            Proactive O&M
                                                            
 
                                                            CCE provides multi-dimensional monitoring and alarm reporting functions, and supports basic resource monitoring based on fine-grained metrics by interconnecting with Application Operations Management (AOM). Alarms allow users to locate and rectify faults as soon as possible.
                                                            
+
                                                            CCE provides multi-dimensional monitoring and alarm reporting functions, allowing users to locate and rectify faults as soon as possible.
                                                            
+
                                                            • Application Operations Management (AOM): The default basic resource monitoring of CCE covers detailed container-related metrics and provides alarm reporting functions.
                                                            • Open source Prometheus: A monitoring tool for cloud native applications. It integrates an independent alarm system to provide more flexible monitoring and alarm reporting functions.
                                                            
                                                             		
 
                                                            Monitoring
                                                            
 
                                                            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                            Table 1 Containerization modes
                                                            Containerization Mode
                                                            
+
                                                            Advantage
                                                            
+
                                                            Disadvantage
                                                            
+
                                                            Method 1:
                                                            
+
                                                            Containerize a single application as a whole.
                                                            
+
                                                            • Zero modification on services: The application architecture and code require no change. 
                                                            • The deployment and upgrade efficiency is improved. Applications can be packed as container images to ensure application environment consistency and improve deployment efficiency.
                                                            • Reduce resource costs: Containers use system resources more efficiently. Compared with a VM with the same configurations, a container can run more applications. 
                                                            
+
                                                            • Difficult to expand the entire architecture of an application. As the code size increases, code update and maintenance would be complicated.
                                                            • Difficult to launch new functions, languages, frameworks, and technologies.
                                                            
+
                                                            Method 2:
                                                            
+
                                                            Containerize first the application components that are frequently updated or have high requirements on auto scaling.
                                                            
+
                                                            • Progressive transformation: Reconstructing the entire architecture involves a heavy workload. This mode containerizes only a part of components, which is easy to accept for customers.
                                                            • Flexible scaling: Application components that have high requirements on auto scaling are containerized. When the application needs to be scaled, you only need to scale the containers, which is flexible and reduces the required system resources.
                                                            • Faster rollout of new features: Application components that are frequently upgraded are containerized. In subsequent upgrades, only these containers need to be upgraded. This shortens the time to market (TTM) of new features.
                                                            
+
                                                            Need to decouple some services.
                                                            
+
                                                            Method 3:
                                                            
+
                                                            Transform an application to microservices and then containerize the microservices one by one.
                                                            
+
                                                            • Independent scaling: After an application is split into microservices, you can independently increase or decrease the number of instances for each microservice.
                                                            • Increased development speed: Microservices are decoupled from one another. Code development of a microservice does not affect other microservices.
                                                            • Security assurance through isolation: For an overall application, if a security vulnerability exists, attackers can use this vulnerability to obtain the permission to all functions of the application. However, in a microservice architecture, if a service is attacked, attackers can only obtain the access permission to this service, but cannot intrude other services.
                                                            • Breakdown isolation: If one microservice breaks down, other microservices can still run properly.
                                                            
+
                                                            Need to transform the application to microservices, which involves a large number of changes.
                                                            
+
                                                            
+
                                                            
+
                                                            Mode 1 is used as an example in this tutorial to illustrate how to containerize an enterprise resource planning (ERP) system.
                                                            
+
                                                            
+
+
diff --git a/docs/cce/umn/cce_bestpractice_0003.html b/docs/cce/umn/cce_bestpractice_0003.html
new file mode 100644
index 00000000..5785e5f6
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0003.html
@@ -0,0 +1,60 @@
+
+
+
                                                            Containerizing an Entire Application
                                                            
+
                                                            This tutorial describes how to containerize an ERP system by migrating it from a VM to CCE.
                                                            
+
                                                            No recoding or re-architecting is required. You only need to pack the entire application into a container image and deploy the container image on CCE.
                                                            
+
                                                            Introduction
                                                            In this example, the enterprise management application is developed by enterprise A. This application is provided for third-party enterprises for use, and enterprise A is responsible for application maintenance.
                                                            
+
                                                            When a third-party enterprise needs to use this application, a suit of Tomcat application and MongoDB database must be deployed for the third-party enterprise. The MySQL database, used to store data of third-party enterprises, is provided by enterprise A.
                                                            
+
                                                            Figure 1 Application architecture
                                                            
+
                                                            As shown in Figure 1, the application is a standard Tomcat application, and its backend interconnects with MongoDB and MySQL databases. For this type of applications, there is no need to split the architecture. The entire application is built as an image, and the MongoDB database is deployed in the same image as the Tomcat application. In this way, the application can be deployed or upgraded through the image.
                                                            
+
                                                            • Interconnecting with the MongoDB database for storing user files.
                                                            • Interconnecting with the MySQL database for storing third-party enterprise data. The MySQL database is an external cloud database.
                                                            
+
                                                            
+
                                                            Benefits
                                                            In this example, the application was deployed on a VM. During application deployment and upgrade, a series of problems is encountered, but application containerization has solved these problems.
                                                            
+
                                                            By using containers, you can easily pack application code, configurations, and dependencies and convert them into easy-to-use building blocks. This achieves the environmental consistency and version management, as well as improves the development and operation efficiency. Containers ensure quick, reliable, and consistent deployment of applications and prevent applications from being affected by deployment environment.
                                                            
+
+
                                                            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                            Table 1 Comparison between the two deployment modes
                                                            Item
                                                            
+
                                                            Before: Application Deployment on VM
                                                            
+
                                                            After: Application Deployment Using Containers
                                                            
+
                                                            Deployment
                                                            
+
                                                            High deployment cost.
                                                            
+
                                                            A VM is required for deploying a system for a customer.
                                                            
+
                                                            More than 50% cost reduced.
                                                            
+
                                                            Container services achieve multi-tenant isolation, which allows you to deploy systems for different enterprises on the same VM.
                                                            
+
                                                            Upgrade
                                                            
+
                                                            Low upgrade efficiency.
                                                            
+
                                                            During version upgrades, you need to log in to VMs one by one and manually configure the upgrades, which is inefficient and error-prone.
                                                            
+
                                                            Per-second level upgrade.
                                                            
+
                                                            Version upgrades can be completed within seconds by replacing the image tag. In addition, CCE provides rolling updates, ensuring zero service downtime during upgrades.
                                                            
+
                                                            Operation and maintenance (O&M)
                                                            
+
                                                            High O&M cost.
                                                            
+
                                                            As the number of applications deployed for customer grows, the number of VMs that need to be maintained increases accordingly, which requires a large sum of maintenance cost.
                                                            
+
                                                            Automatic O&M
                                                            
+
                                                            Enterprises can focus on service development without paying attention to VM maintenance.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_00035.html b/docs/cce/umn/cce_bestpractice_00035.html
index 6446f86d..d8f06177 100644
--- a/docs/cce/umn/cce_bestpractice_00035.html
+++ b/docs/cce/umn/cce_bestpractice_00035.html
@@ -22,7 +22,8 @@
 
                                                            VPC and Container Tunnel Network Models
                                                            
 
                                                            To obtain source IP addresses, perform the following steps:
                                                            
 
                                                            1. When creating a LoadBalancer Service on the CCE console, set Service Affinity to Node level instead of Cluster level.
                                                              
-
                                                            2. Go to the ELB console and enable the function of obtaining the client IP address of the listener corresponding to the load balancer. Transparent transmission of source IP addresses is enabled for dedicated load balancers by default. You do not need to manually enable this function.
                                                              1. Log in to the ELB console.
                                                              2. Click  in the upper left corner to select the desired region and project.
                                                              3. Click Service List. Under Networking, click Elastic Load Balance.
                                                              4. On the Load Balancers page, click the name of the load balancer.
                                                              5. Click Listeners.
                                                              6. To add a listener, click Add Listener.
                                                              7. To modify a listener, locate the listener and click  on the right of its name.
                                                              8. Enable Obtain Client IP Address.
                                                              
+
                                                            3. Go to the ELB console and enable the function of obtaining the client IP address of the listener corresponding to the load balancer. Transparent transmission of source IP addresses is enabled for dedicated load balancers by default. You do not need to manually enable this function.
                                                              1. Log in to the ELB console.
                                                              2. Click  in the upper left corner to select the desired region and project.
                                                              3. Click Service List. Under Networking, click Elastic Load Balance.
                                                              4. On the Load Balancers page, click the name of the load balancer.
                                                              5. Click Listeners.
                                                                • To add a listener, click Add Listener.
                                                                • To modify a listener, locate the listener and click the edit button on the right of its name.
                                                                
+
                                                              6. Enable Obtain Client IP Address.
                                                              
 
                                                            
 
                                                            
 
                                                            
diff --git a/docs/cce/umn/cce_bestpractice_0004.html b/docs/cce/umn/cce_bestpractice_0004.html
new file mode 100644
index 00000000..4f79707f
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0004.html
@@ -0,0 +1,12 @@
+
+
+
                                                            Containerization Process
                                                            
+
                                                            The following figure illustrates the process of containerizing an application.
                                                            
+
                                                            Figure 1 Process of containerizing an application
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0005.html b/docs/cce/umn/cce_bestpractice_0005.html
new file mode 100644
index 00000000..99806a54
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0005.html
@@ -0,0 +1,67 @@
+
+
+
                                                            Analyzing the Application
                                                            
+
                                                            Before containerizing an application, you need to analyze the running environment and dependencies of the application, and get familiar with the application deployment mode. For details, see Table 1.
                                                            
+
+
                                                            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                            Table 1 Application environment
                                                            Item
                                                            
+
                                                            Sub-category
                                                            
+
                                                            Description
                                                            
+
                                                            Runtime environment
                                                            
+
                                                            OS
                                                            
+
                                                            OS that the application runs on, such as CentOS or Ubuntu.
                                                            
+
                                                            In this example, the application runs on CentOS 7.1.
                                                            
+
                                                            Runtime environment
                                                            
+
                                                            The Java application requires Java Development Kit (JDK), the Go language requires GoLang, the web application requires Tomcat environment, and the corresponding version number needs to be confirmed.
                                                            
+
                                                            In this example, the web application of the Tomcat type is used. This application requires the runtime environment of Tomcat 7.0, and Tomcat requires JDK 1.8.
                                                            
+
                                                            Dependency package
                                                            
+
                                                            Understand required dependency packages, such as OpenSSL and other system software, and their version numbers.
                                                            
+
                                                            In this example, no dependency package is required.
                                                            
+
                                                            Deployment mode
                                                            
+
                                                            Peripheral configurations
                                                            
+
                                                            MongoDB database: In this example, the MongoDB database and Tomcat application are deployed on the same server. Therefore, their configurations can be fixed and there is no need to extract their configurations.
                                                            
+
                                                            External services with which the application needs to interconnect, such as databases and file systems.
                                                            
+
                                                            These configurations need to be manually configured each time you deploy an application on a VM. However, through containerized deployment, environment variables can be injected into a container, facilitating deployment.
                                                            
+
                                                            In this example, the application needs to interconnect with the MySQL database. You need to obtain the database configuration file. The server address, database name, database login username, and database login password are injected through environment variables.
                                                            
+
                                                            url=jdbc:mysql://Server address/Database name        #Database connection URL
+username=****                         #Username for logging in to the database
+password=****                         #Password for logging in to the database
                                                            
+
                                                            Application configurations
                                                            
+
                                                            You need to sort out the configuration parameters, such as configurations that need to be modified frequently and those remain unchanged during the running of the application.
                                                            
+
                                                            In this example, no application configurations need to be extracted.
                                                            
+
                                                             NOTE: 
                                                            To avoid frequent image replacement, you are advised to classify configurations of the application.
                                                            
+
                                                            • For the configurations (such as peripheral interconnection information and log levels) that are frequently changed, you are advised to configure them as environment variables.
                                                            • For the configurations that remain unchanged, directly write them into images.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0006.html b/docs/cce/umn/cce_bestpractice_0006.html
new file mode 100644
index 00000000..460892e0
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0006.html
@@ -0,0 +1,51 @@
+
+
+
                                                            Preparing the Application Runtime
                                                            
+
                                                            After application analysis, you have gained the understanding of the OS and runtime required for running the application. You need to make the following preparations:
                                                            
+
                                                            • Installing Docker: During application containerization, you need to build a container image. To do so, you have to prepare a PC and install Docker on it.
                                                            • Obtaining the base image tag: Determine the base image based on the OS on which the application runs. In this example, the application runs on CentOS 7.1 and the base image can be obtained from an open-source image repository.
                                                            • Obtaining the runtime: Obtain the runtime of the application and the MongoDB database with which the application interconnects.
                                                            
+
                                                            Installing Docker
                                                            Docker is compatible with almost all operating systems. Select a Docker version that best suits your needs.
                                                            
+
                                                             
                                                            SWR uses Docker 1.11.2 or later to upload images. 
                                                            
+
                                                            You are advised to install Docker and build images as user root. Obtain the password of user root of the host where Docker is to be installed in advance.
                                                            
+
                                                            
+
                                                            1. Log in as user root to the device on which Docker is about to be installed.
                                                            2. Run the following commands to quickly install Docker on the device running Linux: 
                                                              curl -fsSL get.docker.com -o get-docker.sh
                                                              
+
                                                              sh get-docker.sh
                                                              
+
                                                            3. Run the following command to query the Docker version:
                                                              docker version
                                                              Client:
+Version: 17.12.0-ce
+API Version:1.35
+...
                                                              
+
                                                              
+
                                                              Version indicates the version number. 
                                                              
+
                                                            
+
                                                            
+
                                                            Obtaining the Base Image Tag
                                                            Determine the base image based on the OS on which the application runs. In this example, the application runs on CentOS 7.1 and the base image can be obtained from an open-source image repository.
                                                            
+
                                                             
                                                            Search for the image tag based on the OS on which the application runs.
                                                            
+
                                                            
+
                                                            1. Visit the Docker website.
                                                            2. Search for CentOS. The image corresponding to CentOS 7.1 is centos7.1.1503. You need to use this image name when compiling the Dockerfile.
                                                              Figure 1 Obtaining the CentOS version
                                                              
+
                                                            
+
                                                            
+
                                                            Obtaining the Runtime
                                                            In this example, the web application of the Tomcat type is used. This application requires the runtime of Tomcat 7.0, and Tomcat requires JDK 1.8. In addition, the application must interconnect with the MongoDB database in advance.
                                                            
+
                                                             
                                                            Download the environment required by the application.
                                                            
+
                                                            
+
                                                            1. Download Tomcat, JDK, and MongoDB installation packages of the specific versions.
                                                              1. Download JDK 1.8.
                                                                Download address: https://www.oracle.com/java/technologies/jdk8-downloads.html.
                                                                
+
                                                              2. Download Tomcat 7.0 from http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.82/bin/apache-tomcat-7.0.82.tar.gz.
                                                              3. Download MongoDB 3.2 from https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-3.2.9.tgz.
                                                              
+
                                                            2. Log in as user root to the device running Docker.
                                                            3. Run the following commands to create the directory where the application is to be stored: For example, set the directory to apptest.
                                                              mkdir apptest
                                                              
+
                                                              cd apptest
                                                              
+
                                                            4. Use Xshell to save the downloaded dependency files to the apptest directory.
                                                            5. Run the following commands to decompress the dependency files:
                                                              tar -zxf apache-tomcat-7.0.82.tar.gz
                                                              
+
                                                              tar -zxf jdk-8u151-linux-x64.tar.gz
                                                              
+
                                                              tar -zxf mongodb-linux-x86_64-rhel70-3.2.9.tgz
                                                              
+
                                                            6. Save the enterprise application (for example, apptest.war) in the webapps/apptest directory of the Tomcat runtime environment.
                                                               
                                                              apptest.war is used as an example only. Use your own application for actual configuration.
                                                              
+
                                                              
+
                                                              mkdir -p apache-tomcat-7.0.82/webapps/apptest
                                                              
+
                                                              cp apptest.war apache-tomcat-7.0.82/webapps/apptest
                                                              
+
                                                              cd apache-tomcat-7.0.82/webapps/apptest
                                                              
+
                                                              ./../../../jdk1.8.0_151/bin/jar -xf apptest.war
                                                              
+
                                                              rm -rf apptest.war
                                                              
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0007.html b/docs/cce/umn/cce_bestpractice_0007.html
new file mode 100644
index 00000000..59cf1e3c
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0007.html
@@ -0,0 +1,30 @@
+
+
+
                                                            Compiling a Startup Script
                                                            
+
                                                            During application containerization, you need to prepare a startup script. The method of compiling this script is the same as that of compiling a shell script. The startup script is used to:
                                                            
+
                                                            • Start up the software on which the application depends.
                                                            • Set the configurations that need to be changed as the environment variables.
                                                            
+
                                                             
                                                            Startup scripts vary according to applications. You need to compile the script based on your service requirements.
                                                            
+
                                                            
+
                                                            Procedure
                                                            1. Log in as user root to the device running Docker.
                                                            2. Run the following commands to create the directory where the application is to be stored:
                                                              mkdir apptest
                                                              
+
                                                              cd apptest
                                                              
+
                                                            3. Compile a script file. The name and content of the script file vary according to applications. You need to compile the script file based on your application. The following example is only for your reference. 
                                                              vi start_tomcat_and_mongo.sh
                                                              #!/bin/bash
+# Load system environment variables.
+source  /etc/profile
+# Start MongoDB. The data is stored in /usr/local/mongodb/data.
+./usr/local/mongodb/bin/mongod --dbpath=/usr/local/mongodb/data --logpath=/usr/local/mongodb/logs --port=27017 –fork
+# These three script commands indicate that the contents related to the MySQL database in the environment variables are written into the configuration file when Docker is started.
+sed -i "s|mysql://.*/awcp_crmtile|mysql://$MYSQL_URL/$MYSQL_DB|g" /root/apache-tomcat-7.0.82/webapps/awcp/WEB-INF/classes/conf/jdbc.properties
+sed -i "s|username=.*|username=$MYSQL_USER|g" /root/apache-tomcat-7.0.82/webapps/awcp/WEB-INF/classes/conf/jdbc.properties
+sed -i "s|password=.*|password=$MYSQL_PASSWORD|g" /root/apache-tomcat-7.0.82/webapps/awcp/WEB-INF/classes/conf/jdbc.properties
+# Start Tomcat.
+bash /root/apache-tomcat-7.0.82/bin/catalina.sh run
                                                              
+
                                                              
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0008.html b/docs/cce/umn/cce_bestpractice_0008.html
new file mode 100644
index 00000000..2e998828
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0008.html
@@ -0,0 +1,48 @@
+
+
+
                                                            Compiling the Dockerfile
                                                            
+
                                                            An image is the basis of a container. A container runs based on the content defined in the image. An image has multiple layers. Each layer includes the modifications made based on the previous layer.
                                                            
+
                                                            Generally, Dockerfiles are used to customize images. Dockerfile is a text file and contains various instructions. Each instruction is used to build an image layer. That is, each instruction describes how to build an image layer.
                                                            
+
                                                            This section describes how to compile a Dockerfile file.
                                                            
+
                                                             
                                                            Dockerfiles vary according to applications. Dockerfiles need to be compiled based on actual service requirements.
                                                            
+
                                                            
+
                                                            Procedure
                                                            1. Log in as the root user to the device running Docker.
                                                            2. Write a Dockerfile.
                                                              vi Dockerfile
                                                              
+
                                                              The following provides an example Dockerfile:
                                                              
+
                                                              # Centos:7.1.1503 is used as the base image.
+FROM centos:7.1.1503                     
+# Create a folder to store data and dependency files. You are advised to write multiple commands into one line to reduce the image size.
+RUN mkdir -p /usr/local/mongodb/data \   
+ && mkdir -p /usr/local/mongodb/bin \ 
+ && mkdir -p /root/apache-tomcat-7.0.82 \ 
+ && mkdir -p /root/jdk1.8.0_151
+
+# Copy the files in the apache-tomcat-7.0.82 directory to the container path.
+COPY ./apache-tomcat-7.0.82 /root/apache-tomcat-7.0.82
+# Copy the files in the jdk1.8.0_151 directory to the container path.
+COPY ./jdk1.8.0_151 /root/jdk1.8.0_151                 
+# Copy the files in the mongodb-linux-x86_64-rhel70-3.2.9 directory to the container path.
+COPY ./mongodb-linux-x86_64-rhel70-3.2.9/bin /usr/local/mongodb/bin 
+# Copy start_tomcat_and_mongo.sh to the /root directory of the container.
+COPY ./start_tomcat_and_mongo.sh /root/                
+
+# Enter Java environment variables.
+RUN chown root:root -R /root \                    
+ && echo "JAVA_HOME=/root/jdk1.8.0_151 " >> /etc/profile  \     
+ && echo "PATH=\$JAVA_HOME/bin:$PATH " >> /etc/profile  \ 
+ && echo "CLASSPATH=.:\$JAVA_HOME/lib/dt.jar:\$JAVA_HOME/lib/tools.jar" >> /etc/profile  \ 
+ && chmod +x /root \ 
+ && chmod +x /root/start_tomcat_and_mongo.sh
+
+# When the container is started, commands in start_tomcat_and_mongo.sh are automatically run. The file can be one or more commands, or a script.
+ENTRYPOINT ["/root/start_tomcat_and_mongo.sh"]    
                                                              
+
                                                              In the preceding information:
                                                              
+
                                                              • FROM statement: indicates that centos:7.1.1503 is used as the base image.
                                                              • Run statement: indicates that a shell command is executed in the container.
                                                              • Copy statement: indicates that files in the local computer are copied to the container.
                                                              • ENTRYPOINT statement: indicates the commands that are run after the container is started.
                                                              
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0009.html b/docs/cce/umn/cce_bestpractice_0009.html
new file mode 100644
index 00000000..bc25d004
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0009.html
@@ -0,0 +1,24 @@
+
+
+
                                                            Building and Uploading an Image
                                                            
+
                                                            This section describes how to build an entire application into a Docker image. After building an image, you can use the image to deploy and upgrade the application. This reduces manual configuration and improves efficiency.
                                                            
+
                                                             
                                                            When building an image, ensure that files used to build the image are stored in the same directory.
                                                            
+
                                                            
+
                                                            Required Cloud Services
                                                            SoftWare Repository for Container (SWR) provides easy, secure, and reliable management over container images throughout their lifecycle, facilitating the deployment of containerized services.
                                                            
+
                                                            
+
                                                            Basic Concepts
                                                            • Image: A Docker image is a special file system that includes everything needed to run containers: programs, libraries, resources, settings, and so on. It also includes corresponding configuration parameters (such as anonymous volumes, environment variables, and users) required within a container runtime. An image does not contain any dynamic data, and its content remains unchanged after being built.
                                                            • Container: Images become containers at runtime, that is, containers are created from images. A container can be created, started, stopped, deleted, or suspended.
                                                            
+
                                                            
+
                                                            Procedure
                                                            1. Log in as the root user to the device running Docker.
                                                            2. Enter the apptest directory.
                                                              cd apptest
                                                              
+
                                                              ll
                                                              
+
                                                              Ensure that files used to build the image are stored in the same directory.
                                                              
+
                                                              
+
                                                            3. Build an image.
                                                              docker build -t apptest .
                                                              
+
                                                            4. Upload the image to the SWR service. For details, see Uploading an Image Through the Client.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_0010.html b/docs/cce/umn/cce_bestpractice_0010.html
new file mode 100644
index 00000000..06aecdbe
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0010.html
@@ -0,0 +1,99 @@
+
+
+
                                                            Creating a Container Workload
                                                            
+
                                                            This section describes how to deploy a workload on CCE. When using CCE for the first time, create an initial cluster and add a node into the cluster.
                                                            
+
                                                             
                                                            Containerized workloads are deployed in a similar way. The difference lies in:
                                                            
+
                                                            • Whether environment variables need to be set.
                                                            • Whether cloud storage is used.
                                                            
+
                                                            
+
                                                            Required Cloud Services
                                                            • Cloud Container Engine (CCE): a highly reliable and high-performance service that allows enterprises to manage containerized applications. With support for Kubernetes-native applications and tools, CCE makes it simple to set up an environment for running containers in the cloud.
                                                            • Elastic Cloud Server (ECS): a scalable and on-demand cloud server. It helps you to efficiently set up reliable, secure, and flexible application environments, ensuring stable service running and improving O&M efficiency.
                                                            • Virtual Private Cloud (VPC): an isolated and private virtual network environment that users apply for in the cloud. You can configure the IP address ranges, subnets, and security groups, as well as assign elastic IP addresses and allocate bandwidth in a VPC.
                                                            
+
                                                            
+
                                                            Basic Concepts
                                                            • A cluster is a collection of computing resources, including a group of node resources. A container runs on a node. Before creating a containerized application, you must have an available cluster.
                                                            • A node is a virtual or physical machine that provides computing resources. You must have sufficient node resources to ensure successful operations such as creating applications. 
                                                            • A workload indicates a group of container pods running on CCE. CCE supports third-party application hosting and provides the full lifecycle (from deployment to O&M) management for applications. This section describes how to use a container image to create a workload.
                                                            
+
                                                            
+
                                                            Procedure
                                                            1. Prepare the environment as described in Table 1.
                                                              
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              Table 1 Preparing the environment
                                                              No.
                                                              
+
                                                              Item
                                                              
+
                                                              Procedure
                                                              
+
                                                              1
                                                              
+
                                                              Creating a VPC
                                                              
+
                                                              Create a VPC before you create a cluster. A VPC provides an isolated, configurable, and manageable virtual network environment for CCE clusters.
                                                              
+
                                                              If you have a VPC already, skip to the next task.
                                                              
+
                                                              1. Log in to the management console.
                                                              2. In the service list, choose Networking > Virtual Private Cloud.
                                                              3. On the Dashboard page, click Create VPC.
                                                              4. Follow the instructions to create a VPC. Retain default settings for parameters unless otherwise specified.
                                                              
+
                                                              2
                                                              
+
                                                              Creating a key pair
                                                              
+
                                                              Create a key pair before you create a containerized application. Key pairs are used for identity authentication during remote login to a node. If you have a key pair already, skip this task. 
                                                              
+
                                                              1. Log in to the management console.
                                                              2. In the service list, choose Data Encryption Workshop under Security & Compliance.
                                                              3. In the navigation pane, choose Key Pair Service. On the Private Key Pairs tab page, click Create Key Pair.
                                                              4. Enter a key pair name, select I agree to have the private key managed on the cloud and I have read and agree to the Key Pair Service Disclaimer, and click OK.
                                                              5. In the dialog box displayed, click OK.
                                                                View and save the key pair. For security purposes, a key pair can be downloaded only once. Keep it secure to ensure successful login. 
                                                                
+
                                                              
+
                                                              
+
                                                              
+
                                                            2. Create a cluster and a node.
                                                              1. Log in to the CCE console. Choose Clusters. On the displayed page, select the type of the cluster to be created and click Create.
                                                                Configure cluster parameters and select the VPC created in 1. 
                                                                
+
                                                              2. Buy a node and select the key pair created in 1 as the login mode. 
                                                              
+
                                                            3. Deploy a workload on CCE.
                                                              1. Log in to the CCE console, click the created cluster, choose Workloads in the navigation pane, and click Create Workload in the upper right corner.
                                                              2. Set the following parameters, and retain the default settings for other parameters:
                                                                • Workload Name: Set it to apptest.
                                                                • Pods: Set it to 1.
                                                                
+
                                                              3. In the Container Settings area, select the image uploaded in Building and Uploading an Image.
                                                              4. In the Container Settings area, choose Environment Variables and add environment variables for interconnecting with the MySQL database. The environment variables are set in the startup script.
                                                                 
                                                                In this example, interconnection with the MySQL database is implemented through configuring the environment variables. Determine whether to use environment variables based on your service requirements.
                                                                
+
                                                                
+
+
                                                                
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                                Table 2 Configuring environment variables
                                                                Variable Name
                                                                
+
                                                                Variable Value/Variable Reference
                                                                
+
                                                                MYSQL_DB
                                                                
+
                                                                Database name.
                                                                
+
                                                                MYSQL_URL
                                                                
+
                                                                IP address and port number of the database.
                                                                
+
                                                                MYSQL_USER
                                                                
+
                                                                Database username.
                                                                
+
                                                                MYSQL_PASSWORD
                                                                
+
                                                                Database user password.
                                                                
+
                                                                
+
                                                                
+
                                                              5. In the Container Settings area, choose Data Storage and configure cloud storage for persistent data storage.
                                                                 
                                                                In this example, the MongoDB database is used and persistent data storage is also needed, so you need to configure cloud storage. Determine whether to use cloud storage based on your service requirements.
                                                                
+
                                                                
+
                                                                The mounted path must be the same as the MongoDB storage path in the Docker startup script. For details, see the startup script. In this example, the path is /usr/local/mongodb/data.
                                                                
+
                                                              6. In the Service Settings area, click  to add a service, configure workload access parameters, and click OK.
                                                                 
                                                                In this example, the application will be accessible from public networks by using an elastic IP address.
                                                                
+
                                                                
+
                                                                • Service Name: name of the application that can be accessed externally. In this example, this parameter is set to apptest.
                                                                • Service Type: In this example, select NodePort.
                                                                • Service Affinity
                                                                  • Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workload associated with the Service. Service access will cause performance loss due to route redirection, and the source IP address of the client cannot be obtained.
                                                                  • Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
                                                                  
+
                                                                • Port
                                                                  • Protocol: Set it to TCP.
                                                                  • Service Port: port for accessing the Service.
                                                                  • Container Port: port that the application will listen on the container. In this example, this parameter is set to 8080.
                                                                  • Node Port: Set it to Auto. The system automatically opens a real port on all nodes in the current cluster and then maps the port number to the container port.
                                                                  
+
                                                                
+
                                                              7. Click Create Workload.
                                                                After the workload is created, you can view the running workload in the workload list.
                                                                
+
                                                              
+
                                                            
+
                                                            
+
                                                            Verifying a Workload
                                                            After a workload is created, you can access the workload to check whether the deployment is successful.
                                                            
+
                                                            In the preceding configuration, the NodePort mode is selected to access the workload by using IP address:Port number. If the access is successful, the workload is successfully deployed.
                                                            
+
                                                            You can obtain the access mode from the Access Mode tab page on the workload details page.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Procedure
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_00162.html b/docs/cce/umn/cce_bestpractice_00162.html
index e29f7a89..218d2f77 100644
--- a/docs/cce/umn/cce_bestpractice_00162.html
+++ b/docs/cce/umn/cce_bestpractice_00162.html
@@ -1,12 +1,12 @@
 
 
 
                                                            Selecting a Network Model
                                                            
-
                                                            CCE uses self-proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models.
                                                            
+
                                                            CCE uses proprietary, high-performance container networking add-ons to support the tunnel network, Cloud Native Network 2.0, and VPC network models.
                                                            
 
                                                             
                                                            After a cluster is created, the network model cannot be changed. Exercise caution when selecting a network model.
                                                            
 
                                                            
-
                                                            • Tunnel network: The container network is an overlay tunnel network on top of a VPC network and uses the VXLAN technology. This network model is applicable when there is no high requirements on performance. VXLAN encapsulates Ethernet packets as UDP packets for tunnel transmission. Though at some cost of performance, the tunnel encapsulation enables higher interoperability and compatibility with advanced features (such as network policy-based isolation), meeting the requirements of most applications.
                                                              Figure 1 Container tunnel network
                                                              
+
                                                              • Tunnel network: The container network is an overlay tunnel network on top of a VPC network and uses the VXLAN technology. This network model is applicable when there is no high requirements on performance. VXLAN encapsulates Ethernet packets as UDP packets for tunnel transmission. Though at some cost of performance, the tunnel encapsulation enables higher interoperability and compatibility with advanced features (such as network policy-based isolation), meeting the requirements of most applications.
                                                                Figure 1 Container tunnel network
                                                                
 
                                                              • VPC network: The container network uses VPC routing to integrate with the underlying network. This network model is applicable to performance-intensive scenarios. The maximum number of nodes allowed in a cluster depends on the route quota in a VPC network. Each node is assigned a CIDR block of a fixed size. VPC networks are free from tunnel encapsulation overhead and outperform container tunnel networks. In addition, as VPC routing includes routes to node IP addresses and container network segment, container pods in the cluster can be directly accessed from outside the cluster.
                                                                Figure 2 VPC network
                                                                
-
                                                              • Cloud Native Network 2.0: The container network deeply integrates the elastic network interface (ENI) capability of VPC, uses the VPC CIDR block to allocate container addresses, and supports passthrough networking to containers through a load balancer.
                                                                Figure 3 Cloud Native Network 2.0
                                                                
+
                                                              • Cloud Native Network 2.0: The container network deeply integrates the elastic network interface (ENI) capability of VPC, uses the VPC CIDR block to allocate container addresses, and supports passthrough networking to containers through a load balancer.
                                                                Figure 3 Cloud Native Network 2.0
                                                                
 
                                                              
 
                                                              The following table lists the differences between the network models.
                                                              
 
@@ -96,7 +96,7 @@
 
 
                                                          
 
                                                          
-
                                                           
                                                          1. The scale of a cluster that uses the VPC network model is limited by the custom routes of the VPC. Therefore, you need to estimate the number of required nodes before creating a cluster.
                                                          2. The scale of a cluster that uses the Cloud Native Network 2.0 model depends on the size of the VPC subnet CIDR block selected for the network attachment definition. Before creating a cluster, evaluate the scale of your cluster.
                                                          3. By default, VPC routing network supports direct communication between containers and hosts in the same VPC. If a peering connection policy is configured between the VPC and another VPC, the containers can directly communicate with hosts on the peer VPC. In addition, in hybrid networking scenarios such as Direct Connect and VPN, communication between containers and hosts on the peer end can also be achieved with proper planning.
                                                          
+
                                                           
                                                          1. The scale of a cluster that uses the VPC network model is limited by the custom routes of the VPC. Therefore, you need to estimate the number of required nodes before creating a cluster.
                                                          2. The scale of a cluster that uses the Cloud Native Network 2.0 model depends on the size of the VPC subnet CIDR block selected for the network attachment definition. Before creating a cluster, evaluate the scale of your cluster.
                                                          3. By default, VPC routing network supports direct communication between containers and hosts in the same VPC. If a peering connection policy is configured between the VPC and another VPC, the containers can directly communicate with hosts on the peer VPC. In addition, in hybrid networking scenarios such as Direct Connect and VPN, communication between containers and hosts on the peer end can also be achieved with proper planning.
                                                          
 
                                                          
 
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_00190.html b/docs/cce/umn/cce_bestpractice_00190.html
index 68748bbb..583c1c89 100644
--- a/docs/cce/umn/cce_bestpractice_00190.html
+++ b/docs/cce/umn/cce_bestpractice_00190.html
@@ -1,16 +1,16 @@
 
 
 
                                                          Adding a Second Data Disk to a Node in a CCE Cluster
                                                          
-
                                                          You can use the pre-installation script feature to configure CCE cluster nodes (ECSs). 
                                                          
-
                                                           
                                                          • When creating a node in a cluster of v1.13.10 or later, if a data disk is not managed by LVM, follow instructions in this section to format the data disk before adding the disk. Otherwise, the data disk will still be managed by LVM.
                                                          • When creating a node in a cluster earlier than v1.13.10, you must format the data disks that are not managed by LVM. Otherwise, either these data disks or the first data disk will be managed by LVM.
                                                          
+
                                                          You can use the pre-installation script feature to configure CCE cluster nodes (ECSs). 
                                                          
+
                                                           
                                                          • When creating a node in a cluster of v1.13.10 or later, if a data disk is not managed by LVM, follow instructions in this section to format the data disk before adding the disk. Otherwise, the data disk will still be managed by LVM.
                                                          • When creating a node in a cluster earlier than v1.13.10, you must format the data disks that are not managed by LVM. Otherwise, either these data disks or the first data disk will be managed by LVM.
                                                          
 
                                                          
-
                                                          Before using this feature, write a script that can format data disks and save it to your OBS bucket. This script must be executed by user root.
                                                          
-
                                                          Input Parameters
                                                          
-
                                                          1. Set the script name to formatdisk.sh, save the script to your OBS bucket, and obtain the address of the script in OBS.
                                                          2. You need to specify the size of the Docker data disk (the data disk managed by LVM is called the Docker data disk). The size of the Docker disk must be different from that of the second disk. For example, the Docker data disk is 100 GB and the new disk is 110 GB.
                                                          3. Set the mount path of the second data disk, for example, /data/code.
                                                          
-
                                                          Run the following command in the pre-installation script to format the disk:
                                                          
-
                                                          cd /tmp;curl -k -X GET OBS bucket address /formatdisk.sh -1 -O;fdisk -l;sleep 30;bash -x formatdisk.sh 100 /data/code;fdisk -l
                                                          
-
                                                          Example script (formatdisk.sh):
                                                          
-
                                                          dockerdisksize=$1
+
                                                          Before using this feature, write a script that can format data disks and save it to your OBS bucket. This script must be executed by user root.
                                                          
+
                                                          Input Parameters
                                                          
+
                                                          1. Set the script name to formatdisk.sh, save the script to your OBS bucket, and obtain the address of the script in OBS.
                                                          2. You need to specify the size of the Docker data disk (the data disk managed by LVM is called the Docker data disk). The size of the Docker disk must be different from that of the second disk. For example, the Docker data disk is 100 GB and the new disk is 110 GB.
                                                          3. Set the mount path of the second data disk, for example, /data/code.
                                                          
+
                                                          Run the following command in the pre-installation script to format the disk:
                                                          
+
                                                          cd /tmp;curl -k -X GET OBS bucket address /formatdisk.sh -1 -O;fdisk -l;sleep 30;bash -x formatdisk.sh 100 /data/code;fdisk -l
                                                          
+
                                                          Example script (formatdisk.sh):
                                                          
+
                                                          dockerdisksize=$1
 mountdir=$2
 systemdisksize=40
 i=0
@@ -77,7 +77,7 @@ w
         mount $mountdir
     fi
 done
                                                          
-
                                                           
                                                          If the preceding example cannot be executed, use the dos2unix tool to convert the format.
                                                          
+
                                                           
                                                          If the preceding example cannot be executed, use the dos2unix tool to convert the format.
                                                          
 
                                                          
 
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_00198.html b/docs/cce/umn/cce_bestpractice_00198.html
index b4384058..f4932c5f 100644
--- a/docs/cce/umn/cce_bestpractice_00198.html
+++ b/docs/cce/umn/cce_bestpractice_00198.html
@@ -1,7 +1,76 @@
 
 
 
                                                          Expanding Node Disk Capacity
                                                          
-
                                                          System Disk
                                                          1. Expand the capacity of the system disk on the EVS console.
                                                          2. Restart the node on the ECS console.
                                                          3. Log in to the CCE console and click the cluster. In the navigation pane, choose Nodes. Click More > Sync Server Data at the row containing the target node.
                                                          
+
                                                          System Disk
                                                          EulerOS 2.9 is used as the sample OS. Originally, system disk /dev/vda has 50 GB and one partition (/dev/vda1), and then 50 GB is added to the disk. In this example, the additional 50 GB is allocated to the existing /dev/vda1 partition.
                                                          
+
                                                          1. Expand the capacity of the system disk on the EVS console.
                                                          2. Log in to the node and run the growpart command to check whether growpart has been installed.
                                                            If the tool operation guide is displayed, the tool has been installed. Otherwise, run the following command to install it:
                                                            
+
                                                            yum install cloud-utils-growpart
                                                            
+
                                                          3. Run the following command to view the total capacity of the system disk /dev/vda:
                                                            fdisk -l
                                                            
+
                                                            The following information is displayed, indicating that the total capacity of system disk /dev/vda is 100 GiB:
                                                            
+
                                                            [root@test-48162 ~]# fdisk -l
+Disk /dev/vda: 100 GiB, 107374182400 bytes, 209715200 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+Disklabel type: dos
+Disk identifier: 0x78d88f0b
+
+Device     Boot Start       End   Sectors Size Id Type
+/dev/vda1  *     2048 104857566 104855519  50G 83 Linux
+
+Disk /dev/vdb: 100 GiB, 107374182400 bytes, 209715200 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+
+Disk /dev/mapper/vgpaas-dockersys: 90 GiB, 96632569856 bytes, 188735488 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+
+Disk /dev/mapper/vgpaas-kubernetes: 10 GiB, 10733223936 bytes, 20963328 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
                                                            
+
                                                          4. Run the following command to check the capacity of the system disk partition /dev/vda1:
                                                            df -TH
                                                            
+
                                                            The command output is as follows:
                                                            
+
                                                            [root@test-48162 ~]# df -TH
+Filesystem                    Type      Size  Used Avail Use% Mounted on
+devtmpfs                      devtmpfs  1.8G     0  1.8G   0% /dev
+tmpfs                         tmpfs     1.8G     0  1.8G   0% /dev/shm
+tmpfs                         tmpfs     1.8G   13M  1.8G   1% /run
+tmpfs                         tmpfs     1.8G     0  1.8G   0% /sys/fs/cgroup
+/dev/vda1                     ext4      53G  3.3G   47G   7% /
+tmpfs                         tmpfs     1.8G   75M  1.8G   5% /tmp
+/dev/mapper/vgpaas-dockersys  ext4       95G  1.3G   89G   2% /var/lib/docker
+/dev/mapper/vgpaas-kubernetes ext4       11G   39M   10G   1% /mnt/paas/kubernetes/kubelet
+...
                                                            
+
                                                          5. Run the following command to extend the partition using growpart:
                                                            growpart System disk Partition number
                                                            
+
                                                            Command example: (The system disk has only one partition /dev/vda1. Therefore, the partition number is 1.)
                                                            
+
                                                            growpart /dev/vda 1
                                                            
+
                                                            The command output is as follows:
                                                            
+
                                                            CHANGED: partition=1 start=2048 old: size=104855519 end=104857567 new: size=209713119 end=209715167
                                                            
+
                                                          6. Run the following command to extend the file system:
                                                            resize2fs Disk partition
                                                            
+
                                                            Example command:
                                                            
+
                                                            resize2fs /dev/vda1
                                                            
+
                                                            The command output is as follows:
                                                            
+
                                                            resize2fs 1.45.6 (20-Mar-2020)
+Filesystem at /dev/vda1 is mounted on /; on-line resizing required
+old_desc_blocks = 7, new_desc_blocks = 13
+The filesystem on /dev/vda1 is now 26214139 (4k) blocks long.
                                                            
+
                                                          7. Run the following command to view the new capacity of the /dev/vda1 partition:
                                                            df -TH
                                                            
+
                                                            Information similar to the following is displayed:
                                                            
+
                                                            [root@test-48162 ~]# df -TH
+Filesystem                    Type      Size  Used Avail Use% Mounted on
+devtmpfs                      devtmpfs  1.8G     0  1.8G   0% /dev
+tmpfs                         tmpfs     1.8G     0  1.8G   0% /dev/shm
+tmpfs                         tmpfs     1.8G   13M  1.8G   1% /run
+tmpfs                         tmpfs     1.8G     0  1.8G   0% /sys/fs/cgroup
+/dev/vda1                     ext4     106G  3.3G   98G   4% /
+tmpfs                         tmpfs     1.8G   75M  1.8G   5% /tmp
+/dev/mapper/vgpaas-dockersys  ext4       95G  1.3G   89G   2% /var/lib/docker
+/dev/mapper/vgpaas-kubernetes ext4       11G   39M   10G   1% /mnt/paas/kubernetes/kubelet
+...
                                                            
+
                                                          8. Log in to the CCE console and click the cluster. In the navigation pane, choose Nodes. Click More > Sync Server Data at the row containing the target node.
                                                          
 
                                                          
 
                                                          Node Data Disk (Dedicated for Docker)
                                                          1. Expand the capacity of the data disk on the EVS console.
                                                          2. Log in to the CCE console and click the cluster. In the navigation pane, choose Nodes. Click More > Sync Server Data at the row containing the target node.
                                                          3. Log in to the target node.
                                                          4. Run the lsblk command to check the block device information of the node.
                                                            A data disk is divided depending on the container storage Rootfs:
                                                            
 
                                                            • Overlayfs: No independent thin pool is allocated. Image data is stored in the dockersys disk.
                                                              # lsblk
@@ -28,9 +97,12 @@ sdb                                   8:16   0  200G  0 disk
 │ └─vgpaas-thinpool                 253:3    0   67G  0 lvm  
 │   ...
 └─vgpaas-kubernetes                 253:4    0   10G  0 lvm  /mnt/paas/kubernetes/kubelet
                                                              
-
                                                              Run the following commands on the node to add the new disk capacity to the thinpool disk:
                                                              
-
                                                              pvresize /dev/sdb 
+
                                                              • Run the following commands on the node to add the new disk capacity to the thinpool disk:
                                                                pvresize /dev/sdb 
 lvextend -l+100%FREE -n vgpaas/thinpool
                                                                
+
                                                              • Run the following commands on the node to add the new disk capacity to the dockersys disk:
                                                                pvresize /dev/sdb 
+lvextend -l+100%FREE -n vgpaas/dockersys
+resize2fs /dev/vgpaas/dockersys
                                                                
+
                                                              
 
                                                            
 
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_00199.html b/docs/cce/umn/cce_bestpractice_00199.html
index 2f6e241f..a26ddc3b 100644
--- a/docs/cce/umn/cce_bestpractice_00199.html
+++ b/docs/cce/umn/cce_bestpractice_00199.html
@@ -10,7 +10,7 @@
 
                                                          
 
                                                          Authorizing the SaaS Service Provider to Access the OBS Buckets
                                                          The following uses an OBS bucket as an example to describe how to set a bucket policy and bucket ACL to authorize the SaaS service provider. The configuration for an OBS parallel file system is the same.
                                                          
 
                                                          1. Log in to the OBS console. In the navigation pane, choose Buckets.
                                                          2. In the bucket list, click a bucket name to access the Overview page.
                                                          1. In the navigation pane, choose Permissions > Bucket Policy. On the displayed page, click Create to create a bucket policy.
                                                            Set the parameters as shown in the following figure.
                                                            Figure 2 Creating a bucket policy
                                                            
-
                                                            • Policy Mode: Select Customized.
                                                            • Effect: Select Allow.
                                                            • Principal: Select Other account, and enter the account ID and user ID. The bucket policy takes effect for the specified users.
                                                            • Resources: Select the resources that can be operated.
                                                            • Actions: Select the actions that can be operated.
                                                            
+
                                                            • Policy Mode: Select Customized.
                                                            • Effect: Select Allow.
                                                            • Principal: Select Other account, and enter the account ID and user ID. The bucket policy takes effect for the specified users.
                                                            • Resources: Select the resources that can be operated.
                                                            • Actions: Select the actions that can be operated.
                                                            
 
                                                            
 
                                                          2. In the navigation pane, choose Permissions > Bucket ACLs. In the right pane, click Add.Enter the account ID or account name of the authorized user, select Read and Write for Access to Bucket, select Read and Write for Access to ACL, and click OK.
                                                          
 
                                                          
@@ -32,12 +32,12 @@ spec:
     fsType: obsfs
     volumeAttributes:
       everest.io/obs-volume-type: STANDARD
-      everest.io/region:   eu-de     #Set it to the ID of the current region.
+      everest.io/region:    eu-de     #Set it to the ID of the current region.
       storage.kubernetes.io/csiProvisionerIdentity: everest-csi-provisioner
     volumeHandle: objbucket             #Replace the name with the actual bucket name of the third-party tenant.
   persistentVolumeReclaimPolicy: Retain    #This parameter must be set to Retain to ensure that the bucket will not be deleted when a PV is deleted.
   storageClassName: csi-obs-mountoption    #You can associate a new custom OBS storage class or the built-in csi-obs of the cluster.
                                                          
-
                                                          • mountOptions: This field contains the new OBS mounting parameters that allow the bucket owner to have full access to the data in the bucket. This field solves the problem that the bucket owner cannot read the data written into a mounted third-party bucket. If the object storage of a third-party tenant is mounted, default_acl must be set to bucket-owner-full-control. For details about other values of default_acl, see Bucket ACLs and Object ACLs.
                                                          • persistentVolumeReclaimPolicy: When the object storage of a third-party tenant is mounted, this field must be set to Retain. In this way, the OBS bucket will not be deleted when a PV is deleted. The service platform of the SaaS service provider needs to manage the lifecycle of the third-party bucket PVs. When a PVC is deleted separately, the PV is not deleted. Instead, it will be retained. To do so, you need to call the native Kubernetes APIs to create and delete static PVs.
                                                          • storageClassName: You can associate a new custom OBS storage class (click here) or the built-in csi-obs of the cluster.
                                                          
+
                                                          • mountOptions: This field contains the new OBS mounting parameters that allow the bucket owner to have full access to the data in the bucket. This field solves the problem that the bucket owner cannot read the data written into a mounted third-party bucket. If the object storage of a third-party tenant is mounted, default_acl must be set to bucket-owner-full-control. For details about other values of default_acl, see Bucket ACLs and Object ACLs.
                                                          • persistentVolumeReclaimPolicy: When the object storage of a third-party tenant is mounted, this field must be set to Retain. In this way, the OBS bucket will not be deleted when a PV is deleted. The service platform of the SaaS service provider needs to manage the lifecycle of the third-party bucket PVs. When a PVC is deleted separately, the PV is not deleted. Instead, it will be retained. To do so, you need to call the native Kubernetes APIs to create and delete static PVs.
                                                          • storageClassName: You can associate a new custom OBS storage class (click here) or the built-in csi-obs of the cluster.
                                                          
 
                                                          PVC of a bound OBS bucket:
                                                          apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
@@ -79,7 +79,7 @@ spec:
     volumeHandle: obsfscheck               #Replace the name with the actual name of the parallel file system of the third-party tenant.
   persistentVolumeReclaimPolicy: Retain        #This parameter must be set to Retain to ensure that the bucket will not be deleted when a PV is deleted.
   storageClassName: csi-obs-mountoption       #You can associate a new custom OBS storage class or the built-in csi-obs of the cluster.
                                                          
-
                                                          • mountOptions: This field contains the new OBS mounting parameters that allow the bucket owner to have full access to the data in the bucket. This field solves the problem that the bucket owner cannot read the data written into a mounted third-party bucket. If the object storage of a third-party tenant is mounted, default_acl must be set to bucket-owner-full-control. For details about other values of default_acl, see Bucket ACLs and Object ACLs.
                                                          • persistentVolumeReclaimPolicy: When the object storage of a third-party tenant is mounted, this field must be set to Retain. In this way, the OBS bucket will not be deleted when a PV is deleted. The service platform of the SaaS service provider needs to manage the lifecycle of the third-party bucket PVs. When a PVC is deleted separately, the PV is not deleted. Instead, it will be retained. To do so, you need to call the native Kubernetes APIs to create and delete static PVs.
                                                          • storageClassName: You can associate a new custom OBS storage class (click here) or the built-in csi-obs of the cluster.
                                                          
+
                                                          • mountOptions: This field contains the new OBS mounting parameters that allow the bucket owner to have full access to the data in the bucket. This field solves the problem that the bucket owner cannot read the data written into a mounted third-party bucket. If the object storage of a third-party tenant is mounted, default_acl must be set to bucket-owner-full-control. For details about other values of default_acl, see Bucket ACLs and Object ACLs.
                                                          • persistentVolumeReclaimPolicy: When the object storage of a third-party tenant is mounted, this field must be set to Retain. In this way, the OBS bucket will not be deleted when a PV is deleted. The service platform of the SaaS service provider needs to manage the lifecycle of the third-party bucket PVs. When a PVC is deleted separately, the PV is not deleted. Instead, it will be retained. To do so, you need to call the native Kubernetes APIs to create and delete static PVs.
                                                          • storageClassName: You can associate a new custom OBS storage class (click here) or the built-in csi-obs of the cluster.
                                                          
 
                                                          PVC of a bound OBS parallel file system:
                                                          apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
diff --git a/docs/cce/umn/cce_bestpractice_00220.html b/docs/cce/umn/cce_bestpractice_00220.html
index 921efc41..cf89c178 100644
--- a/docs/cce/umn/cce_bestpractice_00220.html
+++ b/docs/cce/umn/cce_bestpractice_00220.html
@@ -5,12 +5,12 @@
 
                                                          1. Deploy three master nodes for the cluster.
                                                          2. When nodes are deployed across AZs, set custom scheduling policies based on site requirements to maximize resource utilization.
                                                          3. Create multiple node pools in different AZs and use them for node scaling.
                                                          4. Set the number of pods to be greater than 2 when creating a workload.
                                                          5. Set pod affinity rules to distribute pods to different AZs and nodes.
                                                          
 
                                                          
 
                                                          Procedure
                                                          Assume that there are four nodes in a cluster distributed in the following AZs:
                                                          
-
                                                          $ kubectl get node -L topology.kubernetes.io/zone,kubernetes.io/hostname
-NAME            STATUS   ROLES    AGE   VERSION                      ZONE       HOSTNAME
-192.168.5.112   Ready    <none>   42m   v1.21.7-r0-CCE21.11.1.B007   eu-de-01   192.168.5.112
-192.168.5.179   Ready    <none>   42m   v1.21.7-r0-CCE21.11.1.B007   eu-de-01   192.168.5.179
-192.168.5.252   Ready    <none>   37m   v1.21.7-r0-CCE21.11.1.B007   eu-de-02   192.168.5.252
-192.168.5.8     Ready    <none>   33h   v1.21.7-r0-CCE21.11.1.B007   eu-de-03   192.168.5.8
                                                          
+
                                                          $ kubectl get node -L topology.kubernetes.io/zone,kubernetes.io/hostname
+NAME            STATUS   ROLES    AGE   VERSION                      ZONE     HOSTNAME
+192.168.5.112   Ready    <none>   42m   v1.21.7-r0-CCE21.11.1.B007   zone01   192.168.5.112
+192.168.5.179   Ready    <none>   42m   v1.21.7-r0-CCE21.11.1.B007   zone01   192.168.5.179
+192.168.5.252   Ready    <none>   37m   v1.21.7-r0-CCE21.11.1.B007   zone02   192.168.5.252
+192.168.5.8     Ready    <none>   33h   v1.21.7-r0-CCE21.11.1.B007   zone03   192.168.5.8
                                                          
 
                                                          Create workloads according to the following two podAntiAffinity rules:
                                                          
 
                                                          • The first one is the pod anti-affinity in an AZ. Set the parameters as follows:
                                                            • weight: A larger weight value indicates a higher priority. In this example, set it to 50.
                                                            • topologyKey: a default or custom key for the node label that the system uses to denote a topology domain. A topology key determines the scope where the pod should be scheduled to. In this example, set this parameter to topology.kubernetes.io/zone, which is the label for identifying the AZ where the node is located.
                                                            • labelSelector: Select the label of the workload to realize the anti-affinity between this container and the workload.
                                                            
 
                                                          • The second one is the pod anti-affinity in the node host name. Set the parameters as follows:
                                                            • weight: Set it to 50.
                                                            • topologyKey: Set it to kubernetes.io/hostname.
                                                            • labelSelector: Select the label of the pod, which is anti-affinity with the pod.
                                                            
diff --git a/docs/cce/umn/cce_bestpractice_00221.html b/docs/cce/umn/cce_bestpractice_00221.html
new file mode 100644
index 00000000..de168969
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_00221.html
@@ -0,0 +1,105 @@
+
+
+
                                                            Configuring kubeconfig for Fine-Grained Management on Cluster Resources
                                                            
+
                                                            Scenario
                                                            By default, the kubeconfig file provided by CCE for users has permissions bound to the cluster-admin role, which are equivalent to the permissions of user root. It is difficult to implement refined management on users with such permissions.
                                                            
+
                                                            
+
                                                            Purpose
                                                            Cluster resources are managed in a refined manner so that specific users have only certain permissions (such as adding, querying, and modifying resources).
                                                            
+
                                                            
+
                                                            Note
                                                            Ensure that kubectl is available on your host. If not, download it from here (corresponding to the cluster version or the latest version).
                                                            
+
                                                            
+
                                                            Configuration Method
                                                             
                                                            In the following example, only pods and Deployments in the test space can be viewed and added, and they cannot be deleted.
                                                            
+
                                                            
+
                                                            1. Set the service account name to my-sa and namespace to test.
                                                              kubectl create sa my-sa -n test
                                                              
+
                                                              
+
                                                            2. Configure the role table and assign operation permissions to different resources.
                                                              vi role-test.yaml
                                                              
+
                                                              The content is as follows:
                                                              apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+  annotations:
+    rbac.authorization.kubernetes.io/autoupdate: "true"
+  labels:
+    kubernetes.io/bootstrapping: rbac-defaults
+  name: myrole
+  namespace: test
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - pods
+  verbs:
+  - get
+  - list
+  - watch
+- apiGroups:
+  - apps
+  resources:
+  - pods
+  - deployments
+  verbs:
+  - get
+  - list
+  - watch
+  - create
                                                              
+
                                                              
+
                                                              Create a Role.
                                                              
+
                                                              kubectl create -f role-test.yaml
                                                              
+
                                                              
+
                                                            3. Create a RoleBinding and bind the service account to the role so that the user can obtain the corresponding permissions.
                                                              vi myrolebinding.yaml
                                                              
+
                                                              The content is as follows:
                                                              apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: myrolebinding
+  namespace: test
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: myrole
+subjects:
+- kind: ServiceAccount
+  name: my-sa
+  namespace: test
                                                              
+
                                                              
+
                                                              Create a RoleBinding.
                                                              
+
                                                              kubectl create -f myrolebinding.yaml
                                                              
+
                                                              
+
                                                              The user information is configured. Now perform 4 to 6 to write the user information to the configuration file.
                                                              
+
                                                            4. Configure the cluster information.
                                                              1. Use the sa name my-sa to obtain the secret corresponding to the sa. In the following example, my-sa-token-z4967 in the first column is the secret name.
                                                              
+
                                                              kubectl get secret -n test |grep my-sa
                                                              
+
                                                              
+
                                                              1. Decrypt the ca.crt file in the secret and export it.
                                                              
+
                                                              kubectl get secret my-sa-token-5gpl4 -n test -oyaml |grep ca.crt: | awk '{print $2}' |base64 -d > /home/ca.crt
                                                              
+
                                                              1. Set the cluster access mode. test-arm indicates the cluster to be accessed, 10.0.1.100 indicates the IP address of the API server in the cluster and /home/test.config indicates the path for storing the configuration file.
                                                                • If the internal API server address is used, run the following command:
                                                                  kubectl config set-cluster test-arm --server=https://10.0.1.100:5443  --certificate-authority=/home/ca.crt  --embed-certs=true --kubeconfig=/home/test.config
                                                                  
+
                                                                • If the public API server address is used, run the following command:
                                                                  kubectl config set-cluster test-arm --server=https://10.0.1.100:5443 --kubeconfig=/home/test.config --insecure-skip-tls-verify=true
                                                                  
+
                                                                
+
                                                                
+
                                                              
+
                                                               
                                                              If you perform operations on a node in the cluster or the node that uses the configuration is a cluster node, do not set the path of kubeconfig to /root/.kube/config.
                                                              
+
                                                              
+
                                                              The cluster API server address is an intranet API server address. After an EIP is bound to the cluster, the cluster API server address can also be a public API server address.
                                                              
+
                                                            5. Configure the cluster authentication information.
                                                              1. Obtain the cluster token. (If the token is obtained in GET mode, you need to run based64 -d to decode the token.)
                                                              
+
                                                              token=$(kubectl describe secret my-sa-token-5gpl4 -n test | awk '/token:/{print $2}')
                                                              
+
                                                              1. Set the cluster user ui-admin.
                                                              
+
                                                              kubectl config set-credentials ui-admin --token=$token --kubeconfig=/home/test.config
                                                              
+
                                                              
+
                                                            6. Configure the context information for cluster authentication. ui-admin@test is the context name.
                                                              kubectl config set-context ui-admin@test --cluster=test-arm --user=ui-admin --kubeconfig=/home/test.config
                                                              
+
                                                              
+
                                                            7. Set the context. For details about how to use the context, see Permissions Verification.
                                                              kubectl config use-context ui-admin@test --kubeconfig=/home/test.config
                                                              
+
                                                              
+
                                                               
                                                              If you want to assign other users the above permissions to perform operations on the cluster, provide the generated configuration file /home/test.config to the user after performing step 6. The user must ensure that the host can access the API server address of the cluster. When performing step 7 on the host and using kubectl, the user must set the kubeconfig parameter to the path of the configuration file.
                                                              
+
                                                              
+
                                                            
+
                                                            
+
                                                            Permissions Verification
                                                            1. Pods in the test namespace cannot access pods in other namespaces.
                                                              kubectl get pod -n test --kubeconfig=/home/test.config
                                                              
+
                                                              
+
                                                            2. Pods in the test namespace cannot be deleted.
                                                              
+
                                                            
+
                                                            
+
                                                            Further Readings
                                                            For more information about users and identity authentication in Kubernetes, see Authenticating.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                            Parent topic: Permission
                                                            
+
                                                            
+
                                                            
+
diff --git a/docs/cce/umn/cce_bestpractice_00227.html b/docs/cce/umn/cce_bestpractice_00227.html
index 040ae3fc..2936b8da 100644
--- a/docs/cce/umn/cce_bestpractice_00227.html
+++ b/docs/cce/umn/cce_bestpractice_00227.html
@@ -45,7 +45,7 @@ spec:
       - name: default-secret
 
                                                          • Create a DaemonSet.
                                                            kubectl create –f daemonSet.yaml
                                                            
 
                                                            • 
-
                                                          • Check whether the DaemonSet is successfully created.
                                                            kubectl get daemonset  DaemonSet name
                                                            
+
                                                          • Check whether the DaemonSet is successfully created.
                                                            kubectl get daemonset  DaemonSet name
                                                            
 
                                                            In this example, run the following command:
                                                            
 
                                                            kubectl get daemonset daemonset-test
                                                            
 
                                                            Information similar to the following is displayed:
                                                            
diff --git a/docs/cce/umn/cce_bestpractice_00231.html b/docs/cce/umn/cce_bestpractice_00231.html
index 2eb46737..5a8c13af 100644
--- a/docs/cce/umn/cce_bestpractice_00231.html
+++ b/docs/cce/umn/cce_bestpractice_00231.html
@@ -5,10 +5,12 @@
 
                                                            Session persistence is also called sticky sessions. After the sticky session function is enabled, requests from the same client are distributed to the same backend ECS by the load balancer for better continuity.
                                                            
 
                                                            In load balancing and sticky session, connection and session are two key concepts. When only load balancing is concerned, session and connection refer to the same thing.
                                                            
 
                                                            Simply put, if a user needs to log in, it can be regarded as a session; otherwise, a connection.
                                                            
-
                                                            The sticky session mechanism fundamentally conflicts with the basic functions of load balancing. A load balancer forwards requests from clients to multiple backend servers to avoid overload on a single server. However, sticky session requires that some requests be forwarded to the same server for processing. Therefore, you need to select a proper sticky session mechanism based on the application environment.
                                                            
+
                                                            The sticky session mechanism fundamentally conflicts with the basic functions of load balancing. A load balancer forwards requests from clients to multiple backend servers to avoid overload on a single server. However, sticky session requires that some requests be forwarded to the same server for processing. Therefore, select a proper sticky session mechanism based on the application environment.
                                                            
 
                                                          
 
                                                          Layer-4 Load Balancing (Service)
                                                          In layer-4 load balancing, source IP address-based sticky session (Hash routing based on the client IP address) can be enabled. To enable source IP address-based sticky session on Services, the following conditions must be met:
                                                          
-
                                                          1. Service Affinity of the Service is set to Node level (that is, the value of the externalTrafficPolicy field of the Service is Local).
                                                          2. Enable the source IP address-based sticky session in the load balancing configuration of the Service.
                                                            apiVersion: v1
+
                                                            CCE cluster
                                                            1. Service Affinity of the Service is set to Node level (that is, the value of the externalTrafficPolicy field of the Service is Local).
                                                               
                                                              You do not need to set this parameter for CCE Turbo clusters.
                                                              
+
                                                              
+
                                                            2. Enable the source IP address-based sticky session in the load balancing configuration of the Service.
                                                              apiVersion: v1
 kind: Service
 metadata:
   name: svc-example
@@ -21,7 +23,7 @@ metadata:
 spec:
   selector: 
     app: nginx
-  externalTrafficPolicy: Local
+  externalTrafficPolicy: Local   # You do not need to set this parameter for CCE Turbo clusters.
   ports:
     - name: cce-service-0
       targetPort: 80
@@ -31,6 +33,7 @@ spec:
   type: LoadBalancer
                                                              
 
                                                            3. Anti-affinity is enabled for the backend application corresponding to the Service.
                                                            
 
                                                            
+
                                                          
 
                                                          Layer-7 Load Balancing (Ingress)
                                                          In layer-7 load balancing, sticky session based on HTTP cookies and app cookies can be enabled. To enable such sticky session, the following conditions must be met:
                                                          
 
                                                          1. The application (workload) corresponding to the ingress is enabled with workload anti-affinity.
                                                          2. Node affinity is enabled for the Service corresponding to the ingress.
                                                          
 
                                                          Procedure
                                                          
@@ -104,7 +107,7 @@ metadata:
     kubernetes.io/elb.session-affinity-mode: APP_COOKIE     # Select APP_COOKIE.
     kubernetes.io/elb.session-affinity-option: '{"app_cookie_name":"test"}'  # Application cookie name.
 ...
-
                                                        10. Create an ingress and associate it with a Service. The following example describes how to automatically create a shared load balancer. For details about how to specify other types of load balancers, see Using kubectl to Create an ELB Ingress.
                                                          apiVersion: networking.k8s.io/v1
+
                                                        11. Create an ingress and associate it with a Service. The following example describes how to automatically create a shared load balancer. For details about how to specify other types of load balancers, see Using kubectl to Create an ELB Ingress.
                                                          apiVersion: networking.k8s.io/v1
 kind: Ingress 
 metadata: 
   name: ingress-test
diff --git a/docs/cce/umn/cce_bestpractice_00253.html b/docs/cce/umn/cce_bestpractice_00253.html
new file mode 100644
index 00000000..711f2d04
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_00253.html
@@ -0,0 +1,171 @@
+
+
+
                                                          Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System
                                                          
+
                                                          Background
                                                          The minimum capacity of an SFS Turbo file system is 500 GB, and the SFS Turbo file system cannot be billed by usage. By default, the root directory of an SFS Turbo file system is mounted to a container which, in most case, does not require such a large capacity.
                                                          
+
                                                          The everest add-on allows you to dynamically create subdirectories in an SFS Turbo file system and mount these subdirectories to containers. In this way, an SFS Turbo file system can be shared by multiple containers to increase storage efficiency.
                                                          
+
                                                          
+
                                                          Notes and Constraints
                                                          • Only clusters of v1.15 and later are supported.
                                                          • The cluster must use the everest add-on of version 1.1.13 or later.
                                                          • Kata containers are not supported.
                                                          • When the everest add-on earlier than 1.2.69 or 2.1.11 is used, a maximum of 10 PVCs can be created concurrently at a time by using the subdirectory function. Everest 1.2.69 or later or 2.1.11 or later is recommended.
                                                          
+
                                                          
+
                                                          Creating an SFS Turbo Volume of the subpath Type
                                                           
                                                          Do not expand, disassociate, or delete subPath volumes.
                                                          
+
                                                          
+
                                                          1. Import an SFS Turbo file system that is located in the same VPC and subnet as the cluster.
                                                          2. Create a StorageClass YAML file, for example, sfsturbo-sc-test.yaml.
                                                            Configuration example:
                                                            
+
                                                            apiVersion: storage.k8s.io/v1
+allowVolumeExpansion: true
+kind: StorageClass
+metadata:
+  name: sfsturbo-sc-test
+mountOptions:
+- lock
+parameters:
+  csi.storage.k8s.io/csi-driver-name: sfsturbo.csi.everest.io
+  csi.storage.k8s.io/fstype: nfs
+  everest.io/archive-on-delete: "true"
+  everest.io/share-access-to: 7ca2dba2-1234-1234-1234-626371a8fb3a
+  everest.io/share-expand-type: bandwidth
+  everest.io/share-export-location: 192.168.1.1:/sfsturbo/
+  everest.io/share-source: sfs-turbo
+  everest.io/share-volume-type: STANDARD
+  everest.io/volume-as: subpath
+  everest.io/volume-id: 0d773f2e-1234-1234-1234-de6a35074696
+provisioner: everest-csi-provisioner
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
                                                            
+
                                                            In this example:
                                                            
+
                                                            • name: name of the StorageClass.
                                                            • mountOptions: mount options. This field is optional.
                                                              • In versions later than everest 1.1.13 and earlier than everest 1.2.8, only the nolock parameter can be configured. By default, the nolock parameter is used for the mount operation and does not need to be configured. If nolock is set to false, the lock field is used.
                                                              • Starting from everest 1.2.8, more mount options are supported. For details, see Setting Mount Options. Do not set nolock to true. Otherwise, the mount operation fails.
                                                                mountOptions:
+- vers=3
+- timeo=600
+- nolock
+- hard
                                                                
+
                                                              
+
                                                            • everest.io/volume-as: Set this parameter to subpath.
                                                            • everest.io/share-access-to: This parameter is optional. In subpath mode, set this parameter to the ID of the VPC where the SFS Turbo file system is located.
                                                            • everest.io/share-expand-type: This parameter is optional. If the type of the SFS Turbo file system is SFS Turbo Standard – Enhanced or SFS Turbo Performance – Enhanced, set this parameter to bandwidth.
                                                            • everest.io/share-export-location: root directory to be mounted. It consists of the SFS Turbo shared path and sub-directory. The shared path can be queried on the SFS Turbo console. The sub-directory is user-defined. The PVCs created by the StorageClass are located in the sub-directory.
                                                            • everest.io/share-volume-type: This parameter is optional. It specifies the SFS Turbo file system type. The value can be STANDARD or PERFORMANCE. For enhanced types, this parameter must be used together with everest.io/share-expand-type (whose value should be bandwidth).
                                                            • everest.io/zone: This parameter is optional. Set it to the AZ where the SFS Turbo file system is located.
                                                            • everest.io/volume-id: ID of the SFS Turbo volume. You can query the volume ID on the SFS Turbo page.
                                                            • everest.io/archive-on-delete: If this parameter is set to true and the recycling policy is set to Delete, the original PV file will be archived when the PVC is deleted. The archive directory is named in the format of archived-$PV name.timestamp. If this parameter is set to false, the SFS Turbo sub-directory corresponding to the PV will be deleted. The default value is true.
                                                            
+
                                                          1. Run the kubectl create -f sfsturbo-sc-test.yaml command to create a StorageClass.
                                                          2. Create a PVC YAML file named sfs-turbo-test.yaml.
                                                            Configuration example:
                                                            
+
                                                            apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: sfs-turbo-test
+  namespace: default
+spec:
+  accessModes:
+  - ReadWriteMany
+  resources:
+    requests:
+      storage: 50Gi
+  storageClassName: sfsturbo-sc-test
+  volumeMode: Filesystem
                                                            
+
                                                            In this example:
                                                            
+
                                                            • name: name of the PVC.
                                                            • storageClassName: name of the StorageClass created in the previous step.
                                                            • storage: In the subpath mode, this parameter is invalid. The storage capacity is limited by the total capacity of the SFS Turbo file system. If the total capacity of the SFS Turbo file system is insufficient, expand the capacity on the SFS Turbo page in a timely manner.
                                                            
+
                                                          1. Run the kubectl create -f sfs-turbo-test.yaml command to create a PVC.
                                                          
+
                                                           
                                                          It is meaningless to conduct capacity expansion on an SFS Turbo volume created in the subpath mode. This operation does not expand the capacity of the SFS Turbo file system. You need to ensure that the total capacity of the SFS Turbo file system is not used up.
                                                          
+
                                                          
+
                                                          
+
                                                          Creating a Deployment and Mounting an Existing Volume
                                                          1. Create a Deployment YAML file named deployment-test.yaml.
                                                            Configuration example:
                                                            apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: test-turbo-subpath-example
+  namespace: default
+  generation: 1
+  labels:
+    appgroup: ''
+spec: 
+  replicas: 1 
+  selector: 
+    matchLabels: 
+      app: test-turbo-subpath-example 
+  template: 
+    metadata: 
+      labels: 
+        app: test-turbo-subpath-example 
+    spec: 
+      containers: 
+      - image: nginx:latest 
+        name: container-0 
+        volumeMounts: 
+        - mountPath: /tmp
+          name: pvc-sfs-turbo-example 
+      restartPolicy: Always 
+      imagePullSecrets:
+      - name: default-secret
+      volumes: 
+      - name: pvc-sfs-turbo-example 
+        persistentVolumeClaim: 
+          claimName: sfs-turbo-test
                                                            
+
                                                            
+
                                                            In this example:
                                                            
+
                                                            • name: name of the Deployment.
                                                            • image: image used by the Deployment.
                                                            • mountPath: mount path of the container. In this example, the volume is mounted to the /tmp directory.
                                                            • claimName: name of an existing PVC.
                                                            
+
                                                          1. Run the kubectl create -f deployment-test.yaml command to create a Deployment.
                                                          
+
                                                          
+
                                                          Creating a StatefulSet That Uses a Volume Dynamically Created in subpath Mode
                                                          1. Create a StatefulSet YAML file named statefulset-test.yaml.
                                                            Configuration example:
                                                            
+
                                                            apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  name: test-turbo-subpath
+  namespace: default
+  generation: 1
+  labels:
+    appgroup: ''
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: test-turbo-subpath
+  template:
+    metadata:
+      labels:
+        app: test-turbo-subpath
+      annotations:
+        metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"","path":"","port":"","names":""}]'
+        pod.alpha.kubernetes.io/initialized: 'true'
+    spec:
+      containers:
+        - name: container-0
+          image: 'nginx:latest'
+          env:
+            - name: PAAS_APP_NAME
+              value: deploy-sfs-nfs-rw-in
+            - name: PAAS_NAMESPACE
+              value: default
+            - name: PAAS_PROJECT_ID
+              value: 8190a2a1692c46f284585c56fc0e2fb9
+          resources: {}
+          volumeMounts:
+            - name: sfs-turbo-160024548582479676
+              mountPath: /tmp
+          terminationMessagePath: /dev/termination-log
+          terminationMessagePolicy: File
+          imagePullPolicy: IfNotPresent
+      restartPolicy: Always
+      terminationGracePeriodSeconds: 30
+      dnsPolicy: ClusterFirst
+      securityContext: {}
+      imagePullSecrets:
+        - name: default-secret
+      affinity: {}
+      schedulerName: default-scheduler
+  volumeClaimTemplates:
+    - metadata:
+        name: sfs-turbo-160024548582479676
+        namespace: default
+        annotations: {}
+      spec:
+        accessModes:
+          - ReadWriteOnce
+        resources:
+          requests:
+            storage: 10Gi
+        storageClassName: sfsturbo-sc-test
+  serviceName: wwww
+  podManagementPolicy: OrderedReady
+  updateStrategy:
+    type: RollingUpdate
+  revisionHistoryLimit: 10
                                                            
+
                                                            In this example:
                                                            
+
                                                            • name: name of the StatefulSet.
                                                            • image: image used by the StatefulSet.
                                                            • mountPath: mount path of the container. In this example, the volume is mounted to the /tmp directory.
                                                            • spec.template.spec.containers.volumeMounts.name and spec.volumeClaimTemplates.metadata.name must be consistent because they have a mapping relationship.
                                                            • storageClassName: name of the created StorageClass.
                                                            
+
                                                          1. Run the kubectl create -f statefulset-test.yaml command to create a StatefulSet.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Storage
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_bestpractice_00253_0.html b/docs/cce/umn/cce_bestpractice_00253_0.html
deleted file mode 100644
index 77ab416c..00000000
--- a/docs/cce/umn/cce_bestpractice_00253_0.html
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
                                                          Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System
                                                          
-
                                                          Background
                                                          The minimum capacity of an SFS Turbo file system is 500 GB, and the SFS Turbo file system cannot be billed by usage. By default, the root directory of an SFS Turbo file system is mounted to a container which, in most case, does not require such a large capacity.
                                                          
-
                                                          The everest add-on allows you to dynamically create subdirectories in an SFS Turbo file system and mount these subdirectories to containers. In this way, an SFS Turbo file system can be shared by multiple containers to increase storage efficiency.
                                                          
-
                                                          
-
                                                          Notes and Constraints
                                                          • Only clusters of v1.15 and later are supported.
                                                          • The cluster must use the everest add-on of version 1.1.13 or later.
                                                          • Kata containers are not supported.
                                                          • A maximum of 10 PVCs can be created concurrently at a time by using the subdirectory function.
                                                          
-
                                                          
-
                                                          Creating an SFS Turbo Volume of the subpath Type
                                                           
                                                          The CCE console has not yet supported the operations related to this feature, such as expanding, disassociating, and deleting subPath volumes.
                                                          
-
                                                          
-
                                                          1. Import an SFS Turbo file system that is located in the same VPC and subnet as the cluster.
                                                          2. Create a StorageClass YAML file, for example, sfsturbo-sc-test.yaml.
                                                            Configuration example:
                                                            
-
                                                            apiVersion: storage.k8s.io/v1
-allowVolumeExpansion: true
-kind: StorageClass
-metadata:
-  name: sfsturbo-sc-test
-mountOptions:
-- lock
-parameters:
-  csi.storage.k8s.io/csi-driver-name: sfsturbo.csi.everest.io
-  csi.storage.k8s.io/fstype: nfs
-  everest.io/archive-on-delete: "true"
-  everest.io/share-access-to: 7ca2dba2-1234-1234-1234-626371a8fb3a
-  everest.io/share-expand-type: bandwidth
-  everest.io/share-export-location: 192.168.1.1:/sfsturbo/
-  everest.io/share-source: sfs-turbo
-  everest.io/share-volume-type: STANDARD
-  everest.io/volume-as: subpath
-  everest.io/volume-id: 0d773f2e-1234-1234-1234-de6a35074696
-provisioner: everest-csi-provisioner
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
                                                            
-
                                                            In this example:
                                                            
-
                                                            • name: name of the StorageClass.
                                                            • mountOptions: mount options. This field is optional.
                                                              • In versions later than everest 1.1.13 and earlier than everest 1.2.8, only the nolock parameter can be configured. By default, the nolock parameter is used for the mount operation and does not need to be configured. If nolock is set to false, the lock field is used.
                                                              • Starting from everest 1.2.8, more parameters are supported. The default parameter configurations are shown below. For details, see Setting Mount Options. Do not set nolock to true. Otherwise, the mount operation fails.
                                                                mountOptions:
-- vers=3
-- timeo=600
-- nolock
-- hard
                                                                
-
                                                              
-
                                                            • everest.io/volume-as: Set this parameter to subpath.
                                                            • everest.io/share-access-to: This parameter is optional. In subpath mode, set this parameter to the ID of the VPC where the SFS Turbo file system is located.
                                                            • everest.io/share-expand-type: This parameter is optional. If the type of the SFS Turbo file system is SFS Turbo Standard – Enhanced or SFS Turbo Performance – Enhanced, set this parameter to bandwidth.
                                                            • everest.io/share-export-location: root directory to be mounted. It consists of the SFS Turbo shared path and sub-directory. The shared path can be queried on the SFS Turbo console. The sub-directory is user-defined. The PVCs created by the StorageClass are located in the sub-directory.
                                                            • everest.io/share-volume-type: This parameter is optional. It specifies the SFS Turbo file system type. The value can be STANDARD or PERFORMANCE. For enhanced types, this parameter must be used together with everest.io/share-expand-type (whose value should be bandwidth).
                                                            • everest.io/zone: This parameter is optional. Set it to the AZ where the SFS Turbo file system is located.
                                                            • everest.io/volume-id: ID of the SFS Turbo volume. You can query the volume ID on the SFS Turbo page.
                                                            • everest.io/archive-on-delete: If this parameter is set to true and the recycling policy is set to Delete, the original PV file will be archived when the PVC is deleted. The archive directory is named in the format of archived-$PV name.timestamp. If this parameter is set to false, the SFS Turbo sub-directory corresponding to the PV will be deleted. The default value is true.
                                                            
-
                                                          1. Run the kubectl create -f sfsturbo-sc-test.yaml command to create a StorageClass.
                                                          2. Create a PVC YAML file named sfs-turbo-test.yaml.
                                                            Configuration example:
                                                            
-
                                                            apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: sfs-turbo-test
-  namespace: default
-spec:
-  accessModes:
-  - ReadWriteMany
-  resources:
-    requests:
-      storage: 50Gi
-  storageClassName: sfsturbo-sc-test
-  volumeMode: Filesystem
                                                            
-
                                                            In this example:
                                                            
-
                                                            • name: name of the PVC.
                                                            • storageClassName: name of the StorageClass created in the previous step.
                                                            • storage: In the subpath mode, this parameter is invalid. The storage capacity is limited by the total capacity of the SFS Turbo file system. If the total capacity of the SFS Turbo file system is insufficient, expand the capacity on the SFS Turbo page in a timely manner.
                                                            
-
                                                          1. Run the kubectl create -f sfs-turbo-test.yaml command to create a PVC.
                                                          
-
                                                           
                                                          It is meaningless to conduct capacity expansion on an SFS Turbo volume created in the subpath mode. This operation does not expand the capacity of the SFS Turbo file system. You need to ensure that the total capacity of the SFS Turbo file system is not used up.
                                                          
-
                                                          
-
                                                          
-
                                                          Creating a Deployment and Mounting an Existing Volume
                                                          1. Create a Deployment YAML file named deployment-test.yaml.
                                                            Configuration example:
                                                            apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: test-turbo-subpath-example
-  namespace: default
-  generation: 1
-  labels:
-    appgroup: ''
-spec: 
-  replicas: 1 
-  selector: 
-    matchLabels: 
-      app: test-turbo-subpath-example 
-  template: 
-    metadata: 
-      labels: 
-        app: test-turbo-subpath-example 
-    spec: 
-      containers: 
-      - image: nginx:latest 
-        name: container-0 
-        volumeMounts: 
-        - mountPath: /tmp
-          name: pvc-sfs-turbo-example 
-      restartPolicy: Always 
-      imagePullSecrets:
-      - name: default-secret
-      volumes: 
-      - name: pvc-sfs-turbo-example 
-        persistentVolumeClaim: 
-          claimName: sfs-turbo-test
                                                            
-
                                                            
-
                                                            In this example:
                                                            
-
                                                            • name: name of the Deployment.
                                                            • image: image used by the Deployment.
                                                            • mountPath: mount path of the container. In this example, the volume is mounted to the /tmp directory.
                                                            • claimName: name of an existing PVC.
                                                            
-
                                                          1. Run the kubectl create -f deployment-test.yaml command to create a Deployment.
                                                          
-
                                                          
-
                                                          Creating a StatefulSet That Uses a Volume Dynamically Created in subpath Mode
                                                          1. Create a StatefulSet YAML file named statefulset-test.yaml.
                                                            Configuration example:
                                                            
-
                                                            apiVersion: apps/v1
-kind: StatefulSet
-metadata:
-  name: test-turbo-subpath
-  namespace: default
-  generation: 1
-  labels:
-    appgroup: ''
-spec:
-  replicas: 2
-  selector:
-    matchLabels:
-      app: test-turbo-subpath
-  template:
-    metadata:
-      labels:
-        app: test-turbo-subpath
-      annotations:
-        metrics.alpha.kubernetes.io/custom-endpoints: '[{"api":"","path":"","port":"","names":""}]'
-        pod.alpha.kubernetes.io/initialized: 'true'
-    spec:
-      containers:
-        - name: container-0
-          image: 'nginx:latest'
-          env:
-            - name: PAAS_APP_NAME
-              value: deploy-sfs-nfs-rw-in
-            - name: PAAS_NAMESPACE
-              value: default
-            - name: PAAS_PROJECT_ID
-              value: 8190a2a1692c46f284585c56fc0e2fb9
-          resources: {}
-          volumeMounts:
-            - name: sfs-turbo-160024548582479676
-              mountPath: /tmp
-          terminationMessagePath: /dev/termination-log
-          terminationMessagePolicy: File
-          imagePullPolicy: IfNotPresent
-      restartPolicy: Always
-      terminationGracePeriodSeconds: 30
-      dnsPolicy: ClusterFirst
-      securityContext: {}
-      imagePullSecrets:
-        - name: default-secret
-      affinity: {}
-      schedulerName: default-scheduler
-  volumeClaimTemplates:
-    - metadata:
-        name: sfs-turbo-160024548582479676
-        namespace: default
-        annotations: {}
-      spec:
-        accessModes:
-          - ReadWriteOnce
-        resources:
-          requests:
-            storage: 10Gi
-        storageClassName: sfsturbo-sc-test
-  serviceName: wwww
-  podManagementPolicy: OrderedReady
-  updateStrategy:
-    type: RollingUpdate
-  revisionHistoryLimit: 10
                                                            
-
                                                            In this example:
                                                            
-
                                                            • name: name of the StatefulSet.
                                                            • image: image used by the StatefulSet.
                                                            • mountPath: mount path of the container. In this example, the volume is mounted to the /tmp directory.
                                                            • spec.template.spec.containers.volumeMounts.name and spec.volumeClaimTemplates.metadata.name must be consistent because they have a mapping relationship.
                                                            • storageClassName: name of the created StorageClass.
                                                            
-
                                                          1. Run the kubectl create -f statefulset-test.yaml command to create a StatefulSet.
                                                          
-
                                                          
-
                                                          
-
                                                          
-
                                                          
-
                                                          Parent topic: Storage
                                                          
-
                                                          
-
                                                          
-
diff --git a/docs/cce/umn/cce_bestpractice_00281.html b/docs/cce/umn/cce_bestpractice_00281.html
new file mode 100644
index 00000000..14021273
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_00281.html
@@ -0,0 +1,230 @@
+
+
+
                                                          Custom Storage Classes
                                                          
+
                                                          Challenges
                                                          When using storage resources in CCE, the most common method is to specify storageClassName to define the type of storage resources to be created when creating a PVC. The following configuration shows how to use a PVC to apply for an SAS (high I/O) EVS disk (block storage).
                                                          
+
                                                          apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: pvc-evs-example
+  namespace: default
+  annotations:
+    everest.io/disk-volume-type: SAS
+spec:
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+  storageClassName: csi-disk
                                                          
+
                                                          If you need to specify the EVS disk type, you can set the everest.io/disk-volume-type field. The value SAS is used as an example here, indicating the high I/O EVS disk type. Or you can choose SATA (common I/O) and SSD (ultra-high I/O).
                                                          
+
                                                          This configuration method may not work if you want to:
                                                          
+
                                                          • Set storageClassName only, which is simpler than specifying the EVS disk type by using everest.io/disk-volume-type.
                                                          • Avoid modifying YAML files or Helm charts. Some users switch from self-built or other Kubernetes services to CCE and have written YAML files of many applications. In these YAML files, different types of storage resources are specified by different StorageClassNames. When using CCE, they need to modify a large number of YAML files or Helm charts to use storage resources, which is labor-consuming and error-prone.
                                                          • Set the default storageClassName for all applications to use the default storage class. In this way, you can create storage resources of the default type without needing to specify storageClassName in the YAML file.
                                                          
+
                                                          
+
                                                          Solution
                                                          This section describes how to set a custom storage class in CCE and how to set the default storage class. You can specify different types of storage resources by setting storageClassName.
                                                          
+
                                                          • For the first scenario, you can define custom storageClassNames for SAS and SSD EVS disks. For example, define a storage class named csi-disk-sas for creating SAS disks. The following figure shows the differences before and after you use a custom storage class.
                                                            
+
                                                          • For the second scenario, you can define a storage class with the same name as that in the existing YAML file without needing to modify storageClassName in the YAML file.
                                                          • For the third scenario, you can set the default storage class as described below to create storage resources without specifying storageClassName in YAML files.
                                                            apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name: pvc-evs-example
+  namespace: default
+spec:
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
                                                            
+
                                                          
+
                                                          
+
                                                          Storage Classes in CCE
                                                          Run the following command to query the supported storage classes.
                                                          
+
                                                          # kubectl get sc
+NAME                PROVISIONER                     AGE
+csi-disk            everest-csi-provisioner         17d          # Storage class for EVS disks
+csi-disk-topology   everest-csi-provisioner         17d          # Storage class for EVS disks with delayed association
+csi-nas             everest-csi-provisioner         17d          # Storage class for SFS file systems
+csi-obs             everest-csi-provisioner         17d          # Storage Class for OBS buckets
+csi-sfsturbo        everest-csi-provisioner         17d          # Storage class for SFS Turbo file systems
                                                          
+
                                                          Check the details of csi-disk. You can see that the type of the disk created by csi-disk is SAS by default.
                                                          
+
                                                          # kubectl get sc csi-disk -oyaml
+allowVolumeExpansion: true
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  creationTimestamp: "2021-03-17T02:10:32Z"
+  name: csi-disk
+  resourceVersion: "760"
+  selfLink: /apis/storage.k8s.io/v1/storageclasses/csi-disk
+  uid: 4db97b6c-853b-443d-b0dc-41cdcb8140f2
+parameters:
+  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
+  csi.storage.k8s.io/fstype: ext4
+  everest.io/disk-volume-type: SAS
+  everest.io/passthrough: "true"
+provisioner: everest-csi-provisioner
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
                                                          
+
                                                          
+
                                                          Custom Storage Classes
                                                          You can customize a high I/O storage class in a YAML file. For example, the name csi-disk-sas indicates that the disk type is SAS (high I/O).
                                                          
+
                                                          apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: csi-disk-sas                          # Name of the high I/O storage class, which can be customized.
+parameters:
+  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
+  csi.storage.k8s.io/fstype: ext4
+  everest.io/disk-volume-type: SAS            # High I/O EVS disk type, which cannot be customized.
+  everest.io/passthrough: "true"
+provisioner: everest-csi-provisioner
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
+allowVolumeExpansion: true                    # true indicates that capacity expansion is allowed.
                                                          
+
                                                          For an ultra-high I/O storage class, you can set the class name to csi-disk-ssd to create SSD EVS disk (ultra-high I/O).
                                                          
+
                                                          apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: csi-disk-ssd                       # Name of the ultra-high I/O storage class, which can be customized.
+parameters:
+  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
+  csi.storage.k8s.io/fstype: ext4
+  everest.io/disk-volume-type: SSD         # Ultra-high I/O EVS disk type, which cannot be customized.
+  everest.io/passthrough: "true"
+provisioner: everest-csi-provisioner
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
+allowVolumeExpansion: true
                                                          
+
                                                          reclaimPolicy: indicates the recycling policies of the underlying cloud storage. The value can be Delete or Retain.
                                                          
+
                                                          • Delete: When a PVC is deleted, both the PV and the EVS disk are deleted.
                                                          • Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                          
+
                                                           
                                                          The reclamation policy set here has no impact on the SFS Turbo storage.
                                                          
+
                                                          
+
                                                          If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                          
+
                                                          After the definition is complete, run the kubectl create commands to create storage resources.
                                                          
+
                                                          # kubectl create -f sas.yaml
+storageclass.storage.k8s.io/csi-disk-sas created
+# kubectl create -f ssd.yaml
+storageclass.storage.k8s.io/csi-disk-ssd created
                                                          
+
                                                          Query the storage class again. Two more types of storage classes are displayed in the command output, as shown below.
                                                          
+
                                                          # kubectl get sc
+NAME                PROVISIONER                     AGE
+csi-disk            everest-csi-provisioner         17d
+csi-disk-sas        everest-csi-provisioner         2m28s
+csi-disk-ssd        everest-csi-provisioner         16s
+csi-disk-topology   everest-csi-provisioner         17d
+csi-nas             everest-csi-provisioner         17d
+csi-obs             everest-csi-provisioner         17d
+csi-sfsturbo        everest-csi-provisioner         17d
                                                          
+
                                                          Other types of storage resources can be defined in the similar way. You can use kubectl to obtain the YAML file and modify it as required.
                                                          
+
                                                          • File storage
                                                            # kubectl get sc csi-nas -oyaml
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: csi-nas
+provisioner: everest-csi-provisioner
+parameters:
+  csi.storage.k8s.io/csi-driver-name: nas.csi.everest.io
+  csi.storage.k8s.io/fstype: nfs
+  everest.io/share-access-level: rw
+  everest.io/share-access-to: 5e3864c6-e78d-4d00-b6fd-de09d432c632   # ID of the VPC to which the cluster belongs
+  everest.io/share-is-public: 'false'
+  everest.io/zone: xxxxx          # AZ
+reclaimPolicy: Delete
+allowVolumeExpansion: true
+volumeBindingMode: Immediate
                                                            
+
                                                          • Object storage
                                                            # kubectl get sc csi-obs -oyaml
+kind: StorageClass
+apiVersion: storage.k8s.io/v1
+metadata:
+  name: csi-obs
+provisioner: everest-csi-provisioner
+parameters:
+  csi.storage.k8s.io/csi-driver-name: obs.csi.everest.io
+  csi.storage.k8s.io/fstype: s3fs           # Object storage type. s3fs indicates an object bucket, and obsfs indicates a parallel file system.
+  everest.io/obs-volume-type: STANDARD      # Storage class of the OBS bucket
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
                                                            
+
                                                          
+
                                                          
+
                                                          Setting a Default Storage Class
                                                          You can specify a storage class as the default class. In this way, if you do not specify storageClassName when creating a PVC, the PVC is created using the default storage class.
                                                          
+
                                                          For example, to specify csi-disk-ssd as the default storage class, edit your YAML file as follows:
                                                          
+
                                                          apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: csi-disk-ssd
+  annotations:
+    storageclass.kubernetes.io/is-default-class: "true"   # Specifies the default storage class in a cluster. A cluster can have only one default storage class.
+parameters:
+  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
+  csi.storage.k8s.io/fstype: ext4
+  everest.io/disk-volume-type: SSD
+  everest.io/passthrough: "true"
+provisioner: everest-csi-provisioner
+reclaimPolicy: Delete
+volumeBindingMode: Immediate
+allowVolumeExpansion: true
                                                          
+
                                                          Delete the created csi-disk-ssd disk, run the kubectl create command to create a csi-disk-ssd disk again, and then query the storage class. The following information is displayed.
                                                          
+
                                                          # kubectl delete sc csi-disk-ssd
+storageclass.storage.k8s.io "csi-disk-ssd" deleted
+# kubectl create -f ssd.yaml
+storageclass.storage.k8s.io/csi-disk-ssd created
+# kubectl get sc
+NAME                     PROVISIONER                     AGE
+csi-disk                 everest-csi-provisioner         17d
+csi-disk-sas             everest-csi-provisioner         114m
+csi-disk-ssd (default)   everest-csi-provisioner         9s
+csi-disk-topology        everest-csi-provisioner         17d
+csi-nas                  everest-csi-provisioner         17d
+csi-obs                  everest-csi-provisioner         17d
+csi-sfsturbo             everest-csi-provisioner         17d
                                                          
+
                                                          
+
                                                          Verification
                                                          • Use csi-disk-sas to create a PVC.
                                                            apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name:  sas-disk
+spec:
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
+  storageClassName: csi-disk-sas
                                                            
+
                                                            Create a storage class and view its details. As shown below, the object can be created and the value of STORAGECLASS is csi-disk-sas.
                                                            
+
                                                            # kubectl create -f sas-disk.yaml 
+persistentvolumeclaim/sas-disk created
+# kubectl get pvc
+NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
+sas-disk   Bound    pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            csi-disk-sas   24s
+# kubectl get pv
+NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
+pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            Delete           Bound       default/sas-disk          csi-disk-sas            30s
                                                            
+
                                                            View the PVC details on the CCE console. On the PV details page, you can see that the disk type is high I/O.
                                                            
+
                                                            
+
                                                          • If storageClassName is not specified, the default configuration is used, as shown below.
                                                            apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+  name:  ssd-disk
+spec:
+  accessModes:
+  - ReadWriteOnce
+  resources:
+    requests:
+      storage: 10Gi
                                                            
+
                                                            Create and view the storage resource. You can see that the storage class of PVC ssd-disk is csi-disk-ssd, indicating that csi-disk-ssd is used by default.
                                                            
+
                                                            # kubectl create -f ssd-disk.yaml 
+persistentvolumeclaim/ssd-disk created
+# kubectl get pvc
+NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
+sas-disk   Bound    pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            csi-disk-sas   16m
+ssd-disk   Bound    pvc-4d2b059c-0d6c-44af-9994-f74d01c78731   10Gi       RWO            csi-disk-ssd   10s
+# kubectl get pv
+NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
+pvc-4d2b059c-0d6c-44af-9994-f74d01c78731   10Gi       RWO            Delete           Bound       default/ssd-disk          csi-disk-ssd            15s
+pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            Delete           Bound       default/sas-disk          csi-disk-sas            17m
                                                            
+
                                                            View the PVC details on the CCE console. On the PV details page, you can see that the disk type is ultra-high I/O.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Storage
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_bestpractice_00281_0.html b/docs/cce/umn/cce_bestpractice_00281_0.html
deleted file mode 100644
index 7bf0c936..00000000
--- a/docs/cce/umn/cce_bestpractice_00281_0.html
+++ /dev/null
@@ -1,230 +0,0 @@
-
-
-
                                                          Custom Storage Classes
                                                          
-
                                                          Challenges
                                                          When using storage resources in CCE, the most common method is to specify storageClassName to define the type of storage resources to be created when creating a PVC. The following configuration shows how to use a PVC to apply for an SAS (high I/O) EVS disk (block storage).
                                                          
-
                                                          apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: pvc-evs-example
-  namespace: default
-  annotations:
-    everest.io/disk-volume-type: SAS
-spec:
-  accessModes:
-  - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi
-  storageClassName: csi-disk
                                                          
-
                                                          If you need to specify the EVS disk type, you can set the everest.io/disk-volume-type field. The value SAS is used as an example here, indicating the high I/O EVS disk type. Or you can choose SATA (common I/O) and SSD (ultra-high I/O).
                                                          
-
                                                          This configuration method may not work if you want to:
                                                          
-
                                                          • Set storageClassName only, which is simpler than specifying the EVS disk type by using everest.io/disk-volume-type.
                                                          • Avoid modifying YAML files or Helm charts. Some users switch from self-built or other Kubernetes services to CCE and have written YAML files of many applications. In these YAML files, different types of storage resources are specified by different StorageClassNames. When using CCE, they need to modify a large number of YAML files or Helm charts to use storage resources, which is labor-consuming and error-prone.
                                                          • Set the default storageClassName for all applications to use the default storage class. In this way, you can create storage resources of the default type without needing to specify storageClassName in the YAML file.
                                                          
-
                                                          
-
                                                          Solution
                                                          This section describes how to set a custom storage class in CCE and how to set the default storage class. You can specify different types of storage resources by setting storageClassName.
                                                          
-
                                                          • For the first scenario, you can define custom storageClassNames for SAS and SSD EVS disks. For example, define a storage class named csi-disk-sas for creating SAS disks. The following figure shows the differences before and after you use a custom storage class.
                                                            
-
                                                          • For the second scenario, you can define a storage class with the same name as that in the existing YAML file without needing to modify storageClassName in the YAML file.
                                                          • For the third scenario, you can set the default storage class as described below to create storage resources without specifying storageClassName in YAML files.
                                                            apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: pvc-evs-example
-  namespace: default
-spec:
-  accessModes:
-  - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi
                                                            
-
                                                          
-
                                                          
-
                                                          Storage Classes in CCE
                                                          Run the following command to query the supported storage classes.
                                                          
-
                                                          # kubectl get sc
-NAME                PROVISIONER                     AGE
-csi-disk            everest-csi-provisioner         17d          # Storage class for EVS disks
-csi-disk-topology   everest-csi-provisioner         17d          # Storage class for EVS disks with delayed association
-csi-nas             everest-csi-provisioner         17d          # Storage class for SFS file systems
-csi-obs             everest-csi-provisioner         17d          # Storage Class for OBS buckets
-csi-sfsturbo        everest-csi-provisioner         17d          # Storage class for SFS Turbo file systems
                                                          
-
                                                          Check the details of csi-disk. You can see that the type of the disk created by csi-disk is SAS by default.
                                                          
-
                                                          # kubectl get sc csi-disk -oyaml
-allowVolumeExpansion: true
-apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  creationTimestamp: "2021-03-17T02:10:32Z"
-  name: csi-disk
-  resourceVersion: "760"
-  selfLink: /apis/storage.k8s.io/v1/storageclasses/csi-disk
-  uid: 4db97b6c-853b-443d-b0dc-41cdcb8140f2
-parameters:
-  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
-  csi.storage.k8s.io/fstype: ext4
-  everest.io/disk-volume-type: SAS
-  everest.io/passthrough: "true"
-provisioner: everest-csi-provisioner
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
                                                          
-
                                                          
-
                                                          Custom Storage Classes
                                                          You can customize a high I/O storage class in a YAML file. For example, the name csi-disk-sas indicates that the disk type is SAS (high I/O).
                                                          
-
                                                          apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  name: csi-disk-sas                          # Name of the high I/O storage class, which can be customized.
-parameters:
-  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
-  csi.storage.k8s.io/fstype: ext4
-  everest.io/disk-volume-type: SAS            # High I/O EVS disk type, which cannot be customized.
-  everest.io/passthrough: "true"
-provisioner: everest-csi-provisioner
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
-allowVolumeExpansion: true                    # true indicates that capacity expansion is allowed.
                                                          
-
                                                          For an ultra-high I/O storage class, you can set the class name to csi-disk-ssd to create SSD EVS disk (ultra-high I/O).
                                                          
-
                                                          apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  name: csi-disk-ssd                       # Name of the ultra-high I/O storage class, which can be customized.
-parameters:
-  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
-  csi.storage.k8s.io/fstype: ext4
-  everest.io/disk-volume-type: SSD         # Ultra-high I/O EVS disk type, which cannot be customized.
-  everest.io/passthrough: "true"
-provisioner: everest-csi-provisioner
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
-allowVolumeExpansion: true
                                                          
-
                                                          reclaimPolicy: indicates the recycling policies of the underlying cloud storage. The value can be Delete or Retain.
                                                          
-
                                                          • Delete: When a PVC is deleted, both the PV and the EVS disk are deleted.
                                                          • Retain: When a PVC is deleted, the PV and underlying storage resources are not deleted. Instead, you must manually delete these resources. After that, the PV resource is in the Released state and cannot be bound to the PVC again.
                                                          
-
                                                           
                                                          The reclamation policy set here has no impact on the SFS Turbo storage. Therefore, the yearly/monthly SFS Turbo resources will not be reclaimed when the cluster or PVC is deleted.
                                                          
-
                                                          
-
                                                          If high data security is required, you are advised to select Retain to prevent data from being deleted by mistake.
                                                          
-
                                                          After the definition is complete, run the kubectl create commands to create storage resources.
                                                          
-
                                                          # kubectl create -f sas.yaml
-storageclass.storage.k8s.io/csi-disk-sas created
-# kubectl create -f ssd.yaml
-storageclass.storage.k8s.io/csi-disk-ssd created
                                                          
-
                                                          Query the storage class again. Two more types of storage classes are displayed in the command output, as shown below.
                                                          
-
                                                          # kubectl get sc
-NAME                PROVISIONER                     AGE
-csi-disk            everest-csi-provisioner         17d
-csi-disk-sas        everest-csi-provisioner         2m28s
-csi-disk-ssd        everest-csi-provisioner         16s
-csi-disk-topology   everest-csi-provisioner         17d
-csi-nas             everest-csi-provisioner         17d
-csi-obs             everest-csi-provisioner         17d
-csi-sfsturbo        everest-csi-provisioner         17d
                                                          
-
                                                          Other types of storage resources can be defined in the similar way. You can use kubectl to obtain the YAML file and modify it as required.
                                                          
-
                                                          • File storage
                                                            # kubectl get sc csi-nas -oyaml
-kind: StorageClass
-apiVersion: storage.k8s.io/v1
-metadata:
-  name: csi-nas
-provisioner: everest-csi-provisioner
-parameters:
-  csi.storage.k8s.io/csi-driver-name: nas.csi.everest.io
-  csi.storage.k8s.io/fstype: nfs
-  everest.io/share-access-level: rw
-  everest.io/share-access-to: 5e3864c6-e78d-4d00-b6fd-de09d432c632   # ID of the VPC to which the cluster belongs
-  everest.io/share-is-public: 'false'
-  everest.io/zone: xxxxx          # AZ
-reclaimPolicy: Delete
-allowVolumeExpansion: true
-volumeBindingMode: Immediate
                                                            
-
                                                          • Object storage
                                                            # kubectl get sc csi-obs -oyaml
-kind: StorageClass
-apiVersion: storage.k8s.io/v1
-metadata:
-  name: csi-obs
-provisioner: everest-csi-provisioner
-parameters:
-  csi.storage.k8s.io/csi-driver-name: obs.csi.everest.io
-  csi.storage.k8s.io/fstype: s3fs           # Object storage type. s3fs indicates an object bucket, and obsfs indicates a parallel file system.
-  everest.io/obs-volume-type: STANDARD      # Storage class of the OBS bucket
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
                                                            
-
                                                          
-
                                                          
-
                                                          Setting a Default Storage Class
                                                          You can specify a storage class as the default class. In this way, if you do not specify storageClassName when creating a PVC, the PVC is created using the default storage class.
                                                          
-
                                                          For example, to specify csi-disk-ssd as the default storage class, edit your YAML file as follows:
                                                          
-
                                                          apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  name: csi-disk-ssd
-  annotations:
-    storageclass.kubernetes.io/is-default-class: "true"   # Specifies the default storage class in a cluster. A cluster can have only one default storage class.
-parameters:
-  csi.storage.k8s.io/csi-driver-name: disk.csi.everest.io
-  csi.storage.k8s.io/fstype: ext4
-  everest.io/disk-volume-type: SSD
-  everest.io/passthrough: "true"
-provisioner: everest-csi-provisioner
-reclaimPolicy: Delete
-volumeBindingMode: Immediate
-allowVolumeExpansion: true
                                                          
-
                                                          Delete the created csi-disk-ssd disk, run the kubectl create command to create a csi-disk-ssd disk again, and then query the storage class. The following information is displayed.
                                                          
-
                                                          # kubectl delete sc csi-disk-ssd
-storageclass.storage.k8s.io "csi-disk-ssd" deleted
-# kubectl create -f ssd.yaml
-storageclass.storage.k8s.io/csi-disk-ssd created
-# kubectl get sc
-NAME                     PROVISIONER                     AGE
-csi-disk                 everest-csi-provisioner         17d
-csi-disk-sas             everest-csi-provisioner         114m
-csi-disk-ssd (default)   everest-csi-provisioner         9s
-csi-disk-topology        everest-csi-provisioner         17d
-csi-nas                  everest-csi-provisioner         17d
-csi-obs                  everest-csi-provisioner         17d
-csi-sfsturbo             everest-csi-provisioner         17d
                                                          
-
                                                          
-
                                                          Verification
                                                          • Use csi-disk-sas to create a PVC.
                                                            apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name:  sas-disk
-spec:
-  accessModes:
-  - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi
-  storageClassName: csi-disk-sas
                                                            
-
                                                            Create a storage class and view its details. As shown below, the object can be created and the value of STORAGECLASS is csi-disk-sas.
                                                            
-
                                                            # kubectl create -f sas-disk.yaml 
-persistentvolumeclaim/sas-disk created
-# kubectl get pvc
-NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
-sas-disk   Bound    pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            csi-disk-sas   24s
-# kubectl get pv
-NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
-pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            Delete           Bound       default/sas-disk          csi-disk-sas            30s
                                                            
-
                                                            View the PVC details on the CCE console. On the PV details page, you can see that the disk type is high I/O.
                                                            
-
                                                            
-
                                                          • If storageClassName is not specified, the default configuration is used, as shown below.
                                                            apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name:  ssd-disk
-spec:
-  accessModes:
-  - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Gi
                                                            
-
                                                            Create and view the storage resource. You can see that the storage class of PVC ssd-disk is csi-disk-ssd, indicating that csi-disk-ssd is used by default.
                                                            
-
                                                            # kubectl create -f ssd-disk.yaml 
-persistentvolumeclaim/ssd-disk created
-# kubectl get pvc
-NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
-sas-disk   Bound    pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            csi-disk-sas   16m
-ssd-disk   Bound    pvc-4d2b059c-0d6c-44af-9994-f74d01c78731   10Gi       RWO            csi-disk-ssd   10s
-# kubectl get pv
-NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
-pvc-4d2b059c-0d6c-44af-9994-f74d01c78731   10Gi       RWO            Delete           Bound       default/ssd-disk          csi-disk-ssd            15s
-pvc-6e2f37f9-7346-4419-82f7-b42e79f7964c   10Gi       RWO            Delete           Bound       default/sas-disk          csi-disk-sas            17m
                                                            
-
                                                            View the PVC details on the CCE console. On the PV details page, you can see that the disk type is ultra-high I/O.
                                                            
-
                                                            
-
                                                          
-
                                                          
-
                                                          
-
                                                          
-
                                                          
-
                                                          Parent topic: Storage
                                                          
-
                                                          
-
                                                          
-
diff --git a/docs/cce/umn/cce_bestpractice_0050.html b/docs/cce/umn/cce_bestpractice_0050.html
index 60c3536d..123ced02 100644
--- a/docs/cce/umn/cce_bestpractice_0050.html
+++ b/docs/cce/umn/cce_bestpractice_0050.html
@@ -9,6 +9,8 @@
 
                                                          12. 
 
                                                        12. Adding a Second Data Disk to a Node in a CCE Cluster
                                                          
 
                                                          13. 
+
                                                        13. Selecting a Data Disk for the Node
                                                          
+
                                                          14. 
 
 
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_0053.html b/docs/cce/umn/cce_bestpractice_0053.html
index aed39b6d..4e38f74f 100644
--- a/docs/cce/umn/cce_bestpractice_0053.html
+++ b/docs/cce/umn/cce_bestpractice_0053.html
@@ -8,11 +8,11 @@
 
 
                                                        14. Mounting an Object Storage Bucket of a Third-Party Tenant
                                                          
 
                                                          15. 
-
                                                        15. Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System
                                                          
+
                                                        16. Dynamically Creating and Mounting Subdirectories of an SFS Turbo File System
                                                          
 
                                                          17. 
 
                                                        17. How Do I Change the Storage Class Used by a Cluster of v1.15 from FlexVolume to CSI Everest?
                                                          
 
                                                          18. 
-
                                                        18. Custom Storage Classes
                                                          
+
                                                        19. Custom Storage Classes
                                                          
 
                                                          20. 
 
                                                        20. Realizing Automatic Topology for EVS Disks When Nodes Are Deployed Across AZs (csi-disk-topology)
                                                          
 
                                                          21. 
diff --git a/docs/cce/umn/cce_bestpractice_0055.html b/docs/cce/umn/cce_bestpractice_0055.html
new file mode 100644
index 00000000..71fac532
--- /dev/null
+++ b/docs/cce/umn/cce_bestpractice_0055.html
@@ -0,0 +1,15 @@
+
+
+
                                                          Permission
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_bestpractice_0107.html b/docs/cce/umn/cce_bestpractice_0107.html
index e3bbc32a..61766e7e 100644
--- a/docs/cce/umn/cce_bestpractice_0107.html
+++ b/docs/cce/umn/cce_bestpractice_0107.html
@@ -84,7 +84,7 @@ spec:
 
                                                          
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class associated with the storage volume. Set this field to csi-disk for EVS disks.
                                                          
+
                                                          Name of the Kubernetes storage class associated with the storage volume. Set this field to csi-disk for EVS disks.
                                                          
                                                           		
 
                                                          
 
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class. Set this field to csi-nas.
                                                          
+
                                                          Name of the Kubernetes storage class. Set this field to csi-nas.
                                                          
                                                           		
 
                                                          
 
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class. Set this field to csi-obs.
                                                          
+
                                                          Name of the Kubernetes storage class. Set this field to csi-obs.
                                                          
                                                           		
 
                                                          
 
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class. Set this field to csi-sfsturbo for SFS Turbo volumes.
                                                          
+
                                                          Name of the Kubernetes storage class. Set this field to csi-sfsturbo for SFS Turbo volumes.
                                                          
                                                           		
 
                                                          
 
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class. Set this field to csi-disk for EVS disks.
                                                          
+
                                                          Name of the Kubernetes storage class. Set this field to csi-disk for EVS disks.
                                                          
                                                           		
 
                                                          
 
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class. Set this field to csi-obs.
                                                          
+
                                                          Name of the Kubernetes storage class. Set this field to csi-obs.
                                                          
                                                           		
 
                                                          
 
                                                          volumeName
                                                          
@@ -520,7 +520,7 @@ spec:
 
                                                          
 
                                                          storageClassName
                                                          
 
                                                          Name of the Kubernetes storage class. Set this field to csi-sfsturbo.
                                                          
+
                                                          Name of the Kubernetes storage class. Set this field to csi-sfsturbo.
                                                          
                                                           		
 
                                                          
 
                                                          storage
                                                          
@@ -563,7 +563,7 @@ spec:
 
                                                           
                                                          Replace the example file name pvc-example.yaml in the preceding commands with the names of the YAML files configured in 2 and 3.
                                                          
 
                                                          
 
                                                        21. Change the number of pods back to the original value and wait until the pods are running.
                                                          22. 
-
                                                           
                                                          The dynamic allocation of storage for StatefulSets is achieved by using volumeClaimTemplates. This field cannot be modified by Kubernetes. Therefore, data cannot be migrated by using a new PVC.
                                                          
+
                                                           
                                                          The dynamic allocation of storage for StatefulSets is achieved by using volumeClaimTemplates. This field cannot be modified by Kubernetes. Therefore, data cannot be migrated by using a new PVC.
                                                          
 
                                                          The PVC naming rule of the volumeClaimTemplates is fixed. When a PVC that meets the naming rule exists, this PVC is used.
                                                          
 
                                                          Therefore, disassociate the original PVC first, and then create a PVC with the same name in the CSI format.
                                                          
 
                                                          
diff --git a/docs/cce/umn/cce_bestpractice_0308.html b/docs/cce/umn/cce_bestpractice_0308.html
index d3b2be7f..e2c13f10 100644
--- a/docs/cce/umn/cce_bestpractice_0308.html
+++ b/docs/cce/umn/cce_bestpractice_0308.html
@@ -19,7 +19,7 @@
 
                                                          		
 
                                                          *Cluster Type
                                                          
 
                                                          • CCE cluster: supports VM nodes. You can run your containers in a secure and stable container runtime environment based on a high-performance network model.
                                                          • CCE Turbo cluster: runs on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, intelligent scheduling, and BMS nodes.
                                                          
+
                                                          • CCE cluster: supports VM nodes. You can run your containers in a secure and stable container runtime environment based on a high-performance network model.
                                                          • CCE Turbo cluster: runs on a cloud native infrastructure that features software-hardware synergy to support passthrough networking, high security and reliability, and intelligent scheduling, and BMS nodes.
                                                          
                                                           		
 
                                                          CCE cluster
                                                          
                                                           		
 
                                                          
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
                                                          Table 1 Operations that will cause nodes to become unready
                                                          SN
                                                          
-
                                                          Risky Operation
                                                          
-
                                                          Impact
                                                          
-
                                                          Solution
                                                          
-
                                                          1
                                                          
-
                                                          Reinstall the operating system using the original image or another image
                                                          
-
                                                          The node will become unready.
                                                          
-
                                                          Delete the node and buy a new node.
                                                          
-
                                                          2
                                                          
-
                                                          Modify OS configuration
                                                          
-
                                                          The node will become unready.
                                                          
-
                                                          Restore the original configuration or buy the node again.
                                                          
-
                                                          3
                                                          
-
                                                          Delete the opt directory, /var/paas directory, or a data disk
                                                          
-
                                                          The node will become unready.
                                                          
-
                                                          Delete the node and buy a new node.
                                                          
-
                                                          4
                                                          
-
                                                          Format and partition a node disk
                                                          
-
                                                          The node will become unready.
                                                          
-
                                                          Delete the node and buy a new node.
                                                          
-
                                                          5
                                                          
-
                                                          Modify a security group
                                                          
-
                                                          The node will become unready or the cluster will exhibit unexpected behavior.
                                                          
-
                                                          Correct the security group settings based on security group settings of normal clusters.
                                                          
-
                                                          
-
                                                          
-
-
                                                          
-
                                                          
-
                                                          Parent topic: Product Bulletin
                                                          
-
                                                          
-
                                                          
-
diff --git a/docs/cce/umn/cce_bulletin_0301.html b/docs/cce/umn/cce_bulletin_0301.html
index 28021127..1c13941e 100644
--- a/docs/cce/umn/cce_bulletin_0301.html
+++ b/docs/cce/umn/cce_bulletin_0301.html
@@ -1,32 +1,276 @@
 
 
 
                                                          OS Patch Notes for Cluster Nodes
                                                          
-
                                                          Nodes in Hybrid Clusters
                                                          CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9 and CentOS 7.7. The following table lists the supported patches for these OSs.
                                                          
+
                                                          Nodes in Hybrid Clusters
                                                          CCE nodes in Hybrid clusters can run on EulerOS 2.5, EulerOS 2.9, CentOS 7.7 and Ubuntu 22.04. The following table lists the supported patches for these OSs.
                                                          
 
-
                                                          Table 1 Node OS patches
                                                          OS
                                                          
+
                                                          
-
+
-
-
+
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 Node OS patches
                                                          OS
                                                          
 
                                                          Patch
                                                          
+
                                                          Cluster Version
                                                          
+
                                                          Latest Kernel
                                                          
                                                           		
 
                                                          
 
                                                          EulerOS release 2.0 (SP5)
                                                          
+
                                                          EulerOS release 2.5
                                                          
+
                                                          
+
                                                          
+
                                                          
 
                                                          3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64
                                                          
+
                                                          v1.25
                                                          
+
                                                          3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64
                                                          
                                                           		
 
                                                          EulerOS release 2.0 (SP9)
                                                          
+
                                                          v1.23
                                                          
 
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64
                                                          
                                                           		
 
                                                          CentOS Linux release 7.7
                                                          
+
                                                          v1.21
                                                          
 
                                                          3.10.0-1160.76.1.el7.x86_64
                                                          
+
                                                          3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64
                                                          
+
                                                          v1.19
                                                          
+
                                                          3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64
                                                          
+
                                                          EulerOS release 2.9
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          v1.23
                                                          
+
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          v1.21
                                                          
+
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          v1.19
                                                          
+
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          CentOS Linux release 7.7
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          3.10.0-1160.76.1.el7.x86_64
                                                          
+
                                                          v1.23
                                                          
+
                                                          3.10.0-1160.76.1.el7.x86_64
                                                          
+
                                                          v1.21
                                                          
+
                                                          3.10.0-1160.76.1.el7.x86_64
                                                          
+
                                                          v1.19
                                                          
+
                                                          3.10.0-1160.76.1.el7.x86_64
                                                          
+
                                                          Ubuntu 22.04
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          5.15.0-53-generic
                                                          
                                                           		
 
                                                          
                                                           
 
                                                          
 
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 2 Mappings between BMS node OS versions and cluster versions
                                                          OS Version
                                                          
+
                                                          Cluster Version
                                                          
+
                                                          Latest Kernel
                                                          
+
                                                          EulerOS release 2.9 (bare metal server)
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          v1.23
                                                          
+
                                                          4.18.0-147.5.1.6.h766.eulerosv2r9.x86_64
                                                          
+
                                                          
+
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 3 Mappings between OS versions and network model
                                                          OS Version
                                                          
+
                                                          Cluster Version
                                                          
+
                                                          VPC Network
                                                          
+
                                                          Tunnel Network
                                                          
+
                                                          Cloud Native Network 2.0
                                                          
+
                                                          Ubuntu 22.04
                                                          
+
                                                          v1.25
                                                          
+
                                                          √
                                                          
+
                                                          ×
                                                          
+
                                                          √
                                                          
+
                                                          CentOS Linux release 7.7
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.23
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.21
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.19
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          EulerOS release 2.9
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.23
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.21
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.19
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          EulerOS release 2.5
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          v1.25
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.23
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.21
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          v1.19
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          
+
                                                          
+
                                                          
 
 
                                                          The OS patches and verification results will be updated from time to time. You can update the operating system based on your needs.
                                                          
 
diff --git a/docs/cce/umn/cce_productdesc_0002.html b/docs/cce/umn/cce_productdesc_0002.html
new file mode 100644
index 00000000..8f25e71d
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0002.html
@@ -0,0 +1,409 @@
+
+
+
                                                          Permissions
                                                          
+
                                                          CCE allows you to assign permissions to IAM users and user groups under your tenant accounts. CCE combines the advantages of Identity and Access Management (IAM) and Kubernetes Role-based Access Control (RBAC) to provide a variety of authorization methods, including IAM fine-grained/token authorization and cluster-/namespace-scoped authorization.
                                                          
+
                                                          CCE permissions are described as follows:
                                                          • Cluster-level permissions: Cluster-level permissions management evolves out of the system policy authorization feature of IAM. IAM users in the same user group have the same permissions. On IAM, you can configure system policies to describe which IAM user groups can perform which operations on cluster resources. For example, you can grant user group A to create and delete cluster X, add a node, or install an add-on, while granting user group B to view information about cluster X. 
                                                            Cluster-level permissions involve CCE non-Kubernetes APIs and support fine-grained IAM policies and enterprise project management capabilities.
                                                            
+
                                                          • Namespace-level permissions: You can regulate users' or user groups' access to Kubernetes resources, such as workloads, jobs, and Services, in a single namespace based on their Kubernetes RBAC roles. CCE has also been enhanced based on open-source capabilities. It supports RBAC authorization based on IAM user or user group, and RBAC authentication on access to APIs using IAM tokens.
                                                            Namespace-level permissions involve CCE Kubernetes APIs and are enhanced based on the Kubernetes RBAC capabilities. Namespace-level permissions can be granted to IAM users or user groups for authentication and authorization, but are independent of fine-grained IAM policies. For details, see Using RBAC Authorization.
                                                            
+
                                                          
+
                                                          
+
                                                           
                                                          • Cluster-level permissions are configured only for cluster-related resources (such as clusters and nodes). You must also configure namespace permissions to operate Kubernetes resources (such as workloads, jobs, and Services).
                                                          • After you create a cluster of v1.11.7-r2 or later, CCE automatically assigns the cluster-admin permissions of all namespaces in the cluster to you, which means you have full control on the cluster and all resources in all namespaces.
                                                          
+
                                                          
+
                                                          Cluster-level Permissions (Assigned by Using IAM System Policies)
                                                          By default, new IAM users do not have permissions assigned. You need to add a user to one or more groups, and attach permissions policies or roles to these groups. Users inherit permissions from the groups to which they are added and can perform specified operations on cloud services based on the permissions.
                                                          
+
                                                          CCE is a project-level service deployed and accessed in specific physical regions. To assign AOM permissions to a user group, specify the scope as region-specific projects and select projects for the permissions to take effect. If All projects is selected, the permissions will take effect for the user group in all region-specific projects. When accessing CCE, the users need to switch to a region where they have been authorized to use the CCE service.
                                                          
+
                                                          You can grant users permissions by using roles and policies.
                                                          • Roles: A type of coarse-grained authorization mechanism that defines permissions related to user responsibilities. This mechanism provides only a limited number of service-level roles for authorization. When using roles to assign permissions, you need to also assign other roles on which the permissions depend to take effect. However, roles are not an ideal choice for fine-grained authorization and secure access control.
                                                          • Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization, meeting requirements for secure access control. For example, you can assign users only the permissions for managing a certain type of clusters and nodes. 
                                                          
+
                                                          
+
                                                          Table 1 lists all the system permissions supported by CCE.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 System permissions supported by CCE
                                                          Role/Policy Name
                                                          
+
                                                          Description
                                                          
+
                                                          Type
                                                          
+
                                                          Dependencies
                                                          
+
                                                          CCE Administrator
                                                          
+
                                                          Read and write permissions for CCE clusters and all resources (including workloads, nodes, jobs, and Services) in the clusters
                                                          
+
                                                          Role
                                                          
+
                                                          Users granted permissions of this policy must also be granted permissions of the following policies:
                                                          
+
                                                          Global service project: OBS Buckets Viewer and OBS Administrator
                                                          
+
                                                          Region-specific projects: Tenant Guest, Server Administrator, ELB Administrator, SFS Administrator, SWR Admin, and APM FullAccess
                                                          
+
                                                           NOTE: 
                                                          Users with both CCE Administrator and NAT Gateway Administrator policies can use NAT Gateway functions for clusters.
                                                          
+
                                                          
+
                                                          CCE FullAccess
                                                          
+
                                                          Common operation permissions on CCE cluster resources, excluding the namespace-level permissions for the clusters (with Kubernetes RBAC enabled) and the privileged administrator operations, such as agency configuration and cluster certificate generation
                                                          
+
                                                          Policy
                                                          
+
                                                          None.
                                                          
+
                                                          CCE ReadOnlyAccess
                                                          
+
                                                          Permissions to view CCE cluster resources, excluding the namespace-level permissions of the clusters (with Kubernetes RBAC enabled)
                                                          
+
                                                          Policy
                                                          
+
                                                          None.
                                                          
+
                                                          
+
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 2 Common operations supported by CCE system policies
                                                          Operation
                                                          
+
                                                          CCE ReadOnlyAccess
                                                          
+
                                                          CCE FullAccess
                                                          
+
                                                          CCE Administrator
                                                          
+
                                                          Creating a cluster
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Deleting a cluster
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Updating a cluster, for example, updating cluster node scheduling parameters and providing RBAC support to clusters
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Upgrading a cluster
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Waking up a cluster
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Hibernating a cluster
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all clusters
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Querying cluster details
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Adding a node
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Deleting one or more nodes
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Updating a cluster node, for example, updating the node name
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Querying node details
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all nodes
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all jobs
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Deleting one or more cluster jobs
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Querying job details
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Creating a storage volume
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Deleting a storage volume
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Performing operations on all Kubernetes resources
                                                          
+
                                                          √ (Kubernetes RBAC required)
                                                          
+
                                                          √ (Kubernetes RBAC required)
                                                          
+
                                                          √
                                                          
+
                                                          Performing all operations on an Elastic Cloud Server (ECS)
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Performing all operations on Elastic Volume Service (EVS) disks
                                                          
+
                                                          EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed.
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Performing all operations on VPC
                                                          
+
                                                          A cluster must run in a VPC. When creating a namespace, you need to create or associate a VPC for the namespace so that all containers in the namespace will run in the VPC.
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Viewing details of all resources on an ECS
                                                          
+
                                                          In CCE, a node is an ECS with multiple EVS disks.
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all resources on an ECS
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Viewing details about all EVS disk resources EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed.
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all EVS resources
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Viewing details about all VPC resources
                                                          
+
                                                          A cluster must run in a VPC. When creating a namespace, you need to create or associate a VPC for the namespace so that all containers in the namespace will run in the VPC.
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all VPC resources
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Viewing details about all Elastic Load Balance (ELB) resources
                                                          
+
                                                          x
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          Listing all ELB resources
                                                          
+
                                                          x
                                                          
+
                                                          x
                                                          
+
                                                          √
                                                          
+
                                                          Viewing Scalable File Service (SFS) resource details
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing all SFS resources
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Viewing Application Operations Management (AOM) resource details
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Listing AOM resources
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          Performing all operations on AOM auto scaling rules
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          √
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Namespace-level Permissions (Assigned by Using Kubernetes RBAC)
                                                          You can regulate users' or user groups' access to Kubernetes resources in a single namespace based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding, which are described as follows:
                                                          
+
                                                          • Role: defines a set of rules for accessing Kubernetes resources in a namespace.
                                                          • RoleBinding: defines the relationship between users and roles.
                                                          • ClusterRole: defines a set of rules for accessing Kubernetes resources in a cluster (including all namespaces).
                                                          • ClusterRoleBinding: defines the relationship between users and cluster roles.
                                                          
+
                                                          Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts. See the following figure.
                                                          
+
                                                          Figure 1 Role binding
                                                          
+
                                                          On the CCE console, you can assign permissions to a user or user group to access resources in one or all namespaces. By default, the CCE console provides the following ClusterRoles:
                                                          
+
                                                          • view (read-only): read-only permission on most resources in all or selected namespaces.
                                                          • edit (development): read and write permissions on most resources in all or selected namespaces. If this ClusterRole is configured for all namespaces, its capability is the same as the O&M permission.
                                                          • admin (O&M): read and write permissions on most resources in all namespaces, and read-only permission on nodes, storage volumes, namespaces, and quota management.
                                                          • cluster-admin (administrator): read and write permissions on all resources in all namespaces.
                                                          • drainage-editor: drain a node.
                                                          • drainage-viewer: view the nodal drainage status but cannot drain a node.
                                                          
+
                                                          
+
                                                          In addition to cluster-admin, admin, edit, and view, you can define Roles and RoleBindings to configure the permissions to add, delete, modify, and query resources, such as pods, Deployments, and Services, in the namespace.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Service Overview
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0003.html b/docs/cce/umn/cce_productdesc_0003.html
new file mode 100644
index 00000000..17963c18
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0003.html
@@ -0,0 +1,136 @@
+
+
+
                                                          Product Advantages
                                                          
+
                                                          Why CCE?
                                                          CCE is a container service built on Docker and Kubernetes. A wealth of features enable you to run container clusters at scale. CCE eases containerization thanks to its reliability, performance, and open source engagement.
                                                          
+
                                                          Easy to Use
                                                          
+
                                                          • Creating a Kubernetes cluster is as easy as a few clicks on the web console. You can deploy and manage VMs and BMSs together.
                                                          • CCE automates deployment and O&M of containerized applications throughout their lifecycle.
                                                          • You can resize clusters and workloads by setting auto scaling policies. In-the-moment load spikes are no longer headaches.
                                                          • The console walks you through the steps to upgrade Kubernetes clusters.
                                                          • CCE supports turnkey Helm charts.
                                                          
+
                                                          High Performance
                                                          
+
                                                          • CCE runs on mature IaaS services and heterogeneous compute resources. You can launch containers at scale.
                                                          • AI computing is 3x to 5x better with NUMA BMSs and high-speed InfiniBand network cards.
                                                          
+
                                                          Highly Available and Secure
                                                          
+
                                                          • HA: Three master nodes in different AZs for your cluster control plane. Multi-active DR for your nodes and workloads. All these ensure service continuity when one of the nodes is down or an AZ gets hit by natural disasters.
                                                            Figure 1 High-availability setup of clusters
                                                            
+
                                                          • Secure: Integrating IAM and Kubernetes RBAC, CCE clusters are under your full control. You can set different RBAC permissions for IAM users on the console.
                                                          
+
                                                          Open and Compatible
                                                          
+
                                                          • CCE runs on Docker that automates container deployment, discovery, scheduling, and scaling.
                                                          • CCE is compatible with native Kubernetes APIs and kubectl. Updates from Kubernetes and Docker communities are regularly incorporated into CCE.
                                                          
+
                                                          
+
                                                          Comparative Analysis of CCE and On-Premises Kubernetes Cluster Management Systems
                                                          
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 CCE clusters versus on-premises Kubernetes clusters
                                                          Area of Focus
                                                          
+
                                                          On-Premises Cluster
                                                          
+
                                                          CCE
                                                          
+
                                                          Ease of use
                                                          
+
                                                          You have to handle all the complexity in deploying and managing Kubernetes clusters. Cluster upgrades are often a heavy burden to O&M personnel.
                                                          
+
                                                          Easy to manage and use clusters
                                                          
+
                                                          You can create a Kubernetes container cluster in a few clicks. No need to set up Docker or Kubernetes environments. CCE automates deployment and O&M of containerized applications throughout their lifecycle.
                                                          
+
                                                          CCE supports turnkey Helm charts.
                                                          
+
                                                          Using CCE is as simple as choosing a cluster and the workloads that you want to run in the cluster. CCE takes care of cluster management and you focus on app development.
                                                          
+
                                                          Scalability
                                                          
+
                                                          You have to assess service loads and cluster health before resizing a cluster.
                                                          
+
                                                          Managed scaling service
                                                          
+
                                                          CCE auto scales clusters and workloads according to resource metrics and scaling policies.
                                                          
+
                                                          Reliability
                                                          
+
                                                          Only one master node is available in a cluster. Once this node is down, the entire cluster is down, as well as all the applications in it.
                                                          
+
                                                          High availability
                                                          
+
                                                          Enabling HA when creating a cluster will create three master nodes for the control plane. Single points of failure (SPOFs) will not shut down your cluster.
                                                          
+
                                                          Efficiency
                                                          
+
                                                          You have to either build an image repository or turn to a third-party one. Images are pulled in serial.
                                                          
+
                                                          Rapid deployment with images
                                                          
+
                                                          CCE connects to SWR to pull images in parallel. Faster pulls, faster container build.
                                                          
+
                                                          Cost
                                                          
+
                                                          Heavy upfront investment in installing, managing, and scaling cluster management infrastructure
                                                          
+
                                                          Cost effective
                                                          
+
                                                          You only pay for master nodes and the resources used to run and manage applications.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Why Containers?
                                                          Docker is written in the Go language designed by Google. It provides operating-system-level virtualization. Linux Control Groups (cgroups), namespaces, and UnionFS (for example, AUFS) isolate each software process. A Docker container packages everything needed to run a software process. Containers are independent from each other and from the host.
                                                          
+
                                                          Docker has moved forward to enhance container isolation. Containers have their own file systems. They cannot see each other's processes or network interfaces. This simplifies container creation and management.
                                                          
+
                                                          VMs use a hypervisor to virtualize and allocate hardware resources (such as memory, CPU, network, and disk) of a host machine. A complete operating system runs on a VM. Each VM needs to run its own system processes. On the contrary, a container does not require hardware resource virtualization. It runs an application process directly in the the host machine OS kernel. No resource overheads are incurred by running system processes. Therefore, Docker is lighter and faster than VMs.
                                                          
+
                                                          Figure 2 Comparison between Docker containers and VMs
                                                          
+
                                                          To sum up, Docker containers have many advantages over VMs.
                                                          
+
                                                          Resource use
                                                          
+
                                                          Containers have no overheads for virtualizing hardware and running a complete OS. They are faster than VMs in execution and file storage, while having no memory loss.
                                                          
+
                                                          Start speed
                                                          
+
                                                          It takes several minutes to start an application on a VM. Docker containers run on the host kernel without needing an independent OS. Apps in containers can start in seconds or even milliseconds. Development, testing, and deployment can be much faster.
                                                          
+
                                                          Consistent environment
                                                          
+
                                                          Different development, testing, and production environments sometimes prevent bug discovery before rollout. A Docker container image includes everything needed to run an application. You can deploy the same copy of configurations in different environments.
                                                          
+
                                                          Continuous delivery and deployment
                                                          
+
                                                          "Deploy once, run everywhere" would be great for DevOps personnel.
                                                          
+
                                                          Docker supports CI/CD by allowing you to customize container images. You compile Dockerfiles to build container images and use CI systems for testing. The Ops team can deploy images into production environments and use CD systems for auto deployment.
                                                          
+
                                                          The use of Dockerfiles makes the DevOps process visible to everyone in a DevOps team. Developers can better understand both user needs and the O&M headaches faced by the Ops team. The Ops team can also have some knowledge of the must-met conditions to run the application. The knowledge is helpful when the Ops personnel deploy container images in production.
                                                          
+
                                                          Portability
                                                          
+
                                                          Docker ensures environmental consistency across development, testing, and production. Portable Docker containers work the same, regardless of their running environments. Physical machines, VMs, public clouds, private clouds, or even laptops, you name it. Apps are now free to migrate and run anywhere.
                                                          
+
                                                          Application update
                                                          
+
                                                          Docker images consist of layers. Each layer is only stored once and different images can contain the exact same layers. When transferring such images, those same layers get transferred only once. This makes distribution efficient. Updating a containerized application is also simple. Either edit the top-most writable layer in the final image or add layers to the base image. Docker joins hands with many open source projects to maintain a variety of high-quality official images. You can directly use them in the production environment or easily build new images based on them.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 2 Containers versus traditional VMs
                                                          Feature
                                                          
+
                                                          Containers
                                                          
+
                                                          VMs
                                                          
+
                                                          Start speed
                                                          
+
                                                          In seconds
                                                          
+
                                                          In minutes
                                                          
+
                                                          Disk capacity
                                                          
+
                                                          MB
                                                          
+
                                                          GB
                                                          
+
                                                          Performance
                                                          
+
                                                          Near-native performance
                                                          
+
                                                          Weak
                                                          
+
                                                          Per-machine capacity
                                                          
+
                                                          Thousands of containers
                                                          
+
                                                          Tens of VMs
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Service Overview
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0004.html b/docs/cce/umn/cce_productdesc_0004.html
new file mode 100644
index 00000000..81186d4b
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0004.html
@@ -0,0 +1,19 @@
+
+
+
                                                          Basic Concepts
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_productdesc_0005.html b/docs/cce/umn/cce_productdesc_0005.html
new file mode 100644
index 00000000..f87961ff
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0005.html
@@ -0,0 +1,193 @@
+
+
+
                                                          Notes and Constraints
                                                          
+
                                                          This section describes the notes and constraints on using CCE.
                                                          
+
                                                          Clusters and Nodes
                                                          • After a cluster is created, the following items cannot be changed:
                                                            • Number of master nodes. For example, you cannot change a non-HA cluster (with one master node) to an HA cluster (with three master nodes).
                                                            • AZ of a master node.
                                                            • Network configuration of the cluster, such as the VPC, subnet, container CIDR block, Service CIDR block, IPv6 settings, and kube-proxy (forwarding) settings.
                                                            • Network model. For example, change the tunnel network to the VPC network.
                                                            
+
                                                          • Applications cannot be migrated between different namespaces.
                                                          • Underlying resources, such as ECSs (nodes), are limited by quotas and their inventory. Therefore, only some nodes may be successfully created during cluster creation, cluster scaling, or auto scaling.
                                                          • The ECS (node) specifications must be higher than 2 cores and 4 GB memory.
                                                          • To access a CCE cluster through a VPN, ensure that the VPN CIDR block does not conflict with the VPC CIDR block where the cluster resides and the container CIDR block.
                                                          • Ubuntu 22.04 does not support the tunnel network model.
                                                          
+
                                                          
+
                                                          Networking
                                                          • By default, a NodePort Service is accessed within a VPC. If you need to use an EIP to access a NodePort Service through public networks, bind an EIP to the node in the cluster in advance.
                                                          • LoadBalancer Services allow workloads to be accessed from public networks through ELB. This access mode has the following restrictions:
                                                            • It is recommended that automatically created load balancers not be used by other resources. Otherwise, these load balancers cannot be completely deleted, causing residual resources.
                                                            • Do not change the listener name for the load balancer in clusters of v1.15 and earlier. Otherwise, the load balancer cannot be accessed.
                                                            
+
                                                          • Constraints on network policies:
                                                            • Only clusters that use the tunnel network model support network policies.
                                                            • Network isolation is not supported for IPv6 addresses.
                                                            • Network policies do not support egress rules except for clusters of v1.23 or later.
                                                              Egress rules are supported only in the following operating systems:
                                                              
+
+
                                                              
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                              OS
                                                              
+
                                                              Kernel Version
                                                              
+
                                                              CentOS
                                                              
+
                                                              3.10.0-1062.18.1.el7.x86_64
                                                              
+
                                                              3.10.0-1127.19.1.el7.x86_64
                                                              
+
                                                              3.10.0-1160.25.1.el7.x86_64
                                                              
+
                                                              EulerOS 2.5
                                                              
+
                                                              3.10.0-862.14.1.5.h591.eulerosv2r7.x86_64
                                                              
+
                                                              EulerOS 2.9
                                                              
+
                                                              4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64
                                                              
+
                                                              
+
                                                              
+
                                                            • If a cluster is upgraded to v1.23 in in-place mode, you cannot use egress rules because the node OS is not upgraded. In this case, reset the node.
                                                            
+
                                                          
+
                                                          
+
                                                          Volumes
                                                          • Constraints on EVS volumes:
                                                            • EVS disks cannot be attached across AZs and cannot be used by multiple workloads, multiple pods of the same workload, or multiple jobs.
                                                            • Data in a shared disk cannot be shared between nodes in a CCE cluster. If the same EVS disk is attached to multiple nodes, read and write conflicts and data cache conflicts may occur. When creating a Deployment, you are advised to create only one pod if you want to use EVS disks.
                                                            • For clusters earlier than v1.19.10, if an HPA policy is used to scale out a workload with EVS volumes mounted, the existing pods cannot be read or written when a new pod is scheduled to another node.
                                                              For clusters of v1.19.10 and later, if an HPA policy is used to scale out a workload with EVS volume mounted, a new pod cannot be started because EVS disks cannot be attached.
                                                              
+
                                                            • When you create a StatefulSet and add a cloud storage volume, existing EVS volumes cannot be used.
                                                            • EVS disks that have partitions or have non-ext4 file systems cannot be imported.
                                                            • Container storage in CCE clusters of Kubernetes 1.13 or later version supports encryption. Currently, E2E encryption is supported only in certain regions.
                                                            • EVS volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported.
                                                            
+
                                                          • Constraints on SFS volumes:
                                                            • SFS volumes are available only in certain regions.
                                                            • Container storage in CCE clusters of Kubernetes 1.13 or later version supports encryption. Currently, E2E encryption is supported only in certain regions.
                                                            • Volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported.
                                                            
+
                                                          • Constraints on OBS volumes:
                                                            • CCE clusters of v1.7.3-r8 and earlier do not support OBS volumes. You need to upgrade these clusters or create clusters of a later version that supports OBS.
                                                            • Volumes cannot be created in specified enterprise projects. Only the default enterprise project is supported.
                                                            
+
                                                          • Constraints on snapshots and backups:
                                                            • The snapshot function is available only for clusters of v1.15 or later and requires the CSI-based everest add-on.
                                                            • The subtype (common I/O, high I/O, or ultra-high I/O), disk mode (SCSI or VBD), data encryption, sharing status, and capacity of an EVS disk created from a snapshot must be the same as those of the disk associated with the snapshot. These attributes cannot be modified after being queried or set.
                                                            
+
                                                          
+
                                                          
+
                                                          Services
                                                          A Service is a Kubernetes resource object that defines a logical set of pods and a policy by which to access them.
                                                          
+
                                                          A maximum of 6,000 Services can be created in each namespace.
                                                          
+
                                                          
+
                                                          CCE Cluster Resources
                                                          There are resource quotas for your CCE clusters in each region.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Item
                                                          
+
                                                          Constraints on Common Users
                                                          
+
                                                          Total number of clusters in a region
                                                          
+
                                                          50
                                                          
+
                                                          Number of nodes in a cluster (cluster management scale)
                                                          
+
                                                          You can select 50, 200, 1,000, or 2,000 nodes.
                                                          
+
                                                          Maximum number of container pods created on each worker node
                                                          
+
                                                          This number can be set on the console when you are creating a cluster.
                                                          
+
                                                          In the VPC network model, a maximum of 256 pods can be created.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Dependent Underlying Cloud Resources
                                                          
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Category
                                                          
+
                                                          Item
                                                          
+
                                                          Constraints on Common Users
                                                          
+
                                                          Compute
                                                          
+
                                                          Pods
                                                          
+
                                                          1,000
                                                          
+
                                                          Cores
                                                          
+
                                                          8,000
                                                          
+
                                                          RAM capacity (MB)
                                                          
+
                                                          16384000
                                                          
+
                                                          Networking
                                                          
+
                                                          VPCs per account
                                                          
+
                                                          5
                                                          
+
                                                          Subnets per account
                                                          
+
                                                          100
                                                          
+
                                                          Security groups per account
                                                          
+
                                                          100
                                                          
+
                                                          Security group rules per account
                                                          
+
                                                          5000
                                                          
+
                                                          Routes per route table
                                                          
+
                                                          100
                                                          
+
                                                          Routes per VPC
                                                          
+
                                                          100
                                                          
+
                                                          VPC peering connections per region
                                                          
+
                                                          50
                                                          
+
                                                          Network ACLs per account
                                                          
+
                                                          200
                                                          
+
                                                          Layer 2 connection gateways per account
                                                          
+
                                                          5
                                                          
+
                                                          Load balancing
                                                          
+
                                                          Elastic load balancers
                                                          
+
                                                          50
                                                          
+
                                                          Load balancer listeners
                                                          
+
                                                          100
                                                          
+
                                                          Load balancer certificates
                                                          
+
                                                          120
                                                          
+
                                                          Load balancer forwarding policies
                                                          
+
                                                          500
                                                          
+
                                                          Load balancer backend host group
                                                          
+
                                                          500
                                                          
+
                                                          Load balancer backend server
                                                          
+
                                                          500
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Service Overview
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0007.html b/docs/cce/umn/cce_productdesc_0007.html
new file mode 100644
index 00000000..7a246b17
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0007.html
@@ -0,0 +1,21 @@
+
+
+
                                                          Application Scenarios
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_productdesc_0008.html b/docs/cce/umn/cce_productdesc_0008.html
new file mode 100644
index 00000000..40cf84a4
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0008.html
@@ -0,0 +1,75 @@
+
+
+
                                                          Related Services
                                                          
+
                                                          Figure 1 Relationships between CCE and other services
                                                          
+
                                                          Relationships Between CCE and Other Services
                                                          
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 Relationships between CCE and other services
                                                          Service
                                                          
+
                                                          Relationship
                                                          
+
                                                          Elastic Cloud Server (ECS)
                                                          
+
                                                          An ECS with multiple EVS disks is a node in CCE. You can choose ECS specifications during node creation.
                                                          
+
                                                          Virtual Private Cloud (VPC)
                                                          
+
                                                          For security reasons, all clusters created by CCE must run in VPCs. When creating a namespace, you need to create a VPC or bind an existing VPC to the namespace so all containers in the namespace will run in this VPC.
                                                          
+
                                                          Elastic Load Balance (ELB)
                                                          
+
                                                          CCE works with ELB to load balance a workload's access requests across multiple pods.
                                                          
+
                                                          NAT Gateway
                                                          
+
                                                          The NAT Gateway service provides source network address translation (SNAT) for container instances in a VPC. The SNAT feature translates private IP addresses of these container instances to the same EIP, which is a public IP address reachable on Internet.
                                                          
+
                                                          Software Repository for Container (SWR)
                                                          
+
                                                          An image repository is used to store and manage Docker images.
                                                          
+
                                                          Elastic Volume Service (EVS)
                                                          
+
                                                          EVS disks can be attached to cloud servers and scaled to a higher capacity whenever needed.
                                                          
+
                                                          An ECS with multiple EVS disks is a node in CCE. You can choose ECS specifications during node creation.
                                                          
+
                                                          Object Storage Service (OBS)
                                                          
+
                                                          OBS provides stable, secure, cost-efficient, and object-based cloud storage for data of any size. With OBS, you can create, modify, and delete buckets, as well as uploading, downloading, and deleting objects.
                                                          
+
                                                          CCE allows you to create an OBS volume and attach it to a path inside a container.
                                                          
+
                                                          Scalable File Service (SFS)
                                                          
+
                                                          SFS is a shared, fully managed file storage service. Compatible with the Network File System protocol, SFS file systems can elastically scale up to petabytes, thereby ensuring top performance of data-intensive and bandwidth-intensive applications.
                                                          
+
                                                          You can use SFS file systems as persistent storage for containers and attach the file systems to containers when creating a workload.
                                                          
+
                                                          Application Operations Management (AOM)
                                                          
+
                                                          AOM collects container log files in formats like .log from CCE and dumps them to AOM. On the AOM console, you can easily query and view log files. In addition, AOM monitors CCE resource usage. You can define metric thresholds for CCE resource usage to trigger auto scaling.
                                                          
+
                                                          Cloud Trace Service (CTS)
                                                          
+
                                                          CTS records operations on your cloud resources, allowing you to query, audit, and backtrack resource operation requests initiated from the management console or open APIs as well as responses to these requests.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Service Overview
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0010.html b/docs/cce/umn/cce_productdesc_0010.html
new file mode 100644
index 00000000..fac5003b
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0010.html
@@ -0,0 +1,197 @@
+
+
+
                                                          Mappings Between CCE and Kubernetes Terms
                                                          
+
                                                          Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of container clusters. It is a container orchestration tool and a leading solution based on the distributed architecture of the container technology. Kubernetes is built on the open-source Docker technology that automates deployment, resource scheduling, service discovery, and dynamic scaling of containerized applications.
                                                          
+
                                                          This topic describes the mappings between CCE and Kubernetes terms.
                                                          
+
+
                                                          
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                          Table 1 Mappings between CCE and Kubernetes terms
                                                          CCE
                                                          
+
                                                          Kubernetes
                                                          
+
                                                          Cluster
                                                          
+
                                                          Cluster
                                                          
+
                                                          Node
                                                          
+
                                                          Node
                                                          
+
                                                          Node pool
                                                          
+
                                                          NodePool
                                                          
+
                                                          Container
                                                          
+
                                                          Container
                                                          
+
                                                          Image
                                                          
+
                                                          Image
                                                          
+
                                                          Namespace
                                                          
+
                                                          Namespace
                                                          
+
                                                          Deployment
                                                          
+
                                                          Deployment
                                                          
+
                                                          StatefulSet
                                                          
+
                                                          StatefulSet
                                                          
+
                                                          DaemonSet
                                                          
+
                                                          DaemonSet
                                                          
+
                                                          Job
                                                          
+
                                                          Job
                                                          
+
                                                          Cron job
                                                          
+
                                                          CronJob
                                                          
+
                                                          Pod
                                                          
+
                                                          Pod
                                                          
+
                                                          Service
                                                          
+
                                                          Service
                                                          
+
                                                          ClusterIP
                                                          
+
                                                          Cluster IP
                                                          
+
                                                          NodePort
                                                          
+
                                                          NodePort
                                                          
+
                                                          LoadBalancer
                                                          
+
                                                          LoadBalancer
                                                          
+
                                                          Layer-7 load balancing (ingress)
                                                          
+
                                                          Ingress
                                                          
+
                                                          Network policy
                                                          
+
                                                          NetworkPolicy
                                                          
+
                                                          Chart
                                                          
+
                                                          Template
                                                          
+
                                                          ConfigMap
                                                          
+
                                                          ConfigMap
                                                          
+
                                                          Secret
                                                          
+
                                                          Secret
                                                          
+
                                                          Label
                                                          
+
                                                          Label
                                                          
+
                                                          Label selector
                                                          
+
                                                          LabelSelector
                                                          
+
                                                          Annotation
                                                          
+
                                                          Annotation
                                                          
+
                                                          Volume
                                                          
+
                                                          PersistentVolume
                                                          
+
                                                          PersistentVolumeClaim
                                                          
+
                                                          PersistentVolumeClaim
                                                          
+
                                                          Auto scaling
                                                          
+
                                                          HPA
                                                          
+
                                                          Node affinity
                                                          
+
                                                          NodeAffinity
                                                          
+
                                                          Node anti-affinity
                                                          
+
                                                          NodeAntiAffinity
                                                          
+
                                                          Pod affinity
                                                          
+
                                                          PodAffinity
                                                          
+
                                                          Pod anti-affinity
                                                          
+
                                                          PodAntiAffinity
                                                          
+
                                                          Webhook
                                                          
+
                                                          Webhook
                                                          
+
                                                          Endpoint
                                                          
+
                                                          Endpoint
                                                          
+
                                                          Quota
                                                          
+
                                                          Resource Quota
                                                          
+
                                                          Resource limit
                                                          
+
                                                          Limit Range
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Basic Concepts
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0011.html b/docs/cce/umn/cce_productdesc_0011.html
new file mode 100644
index 00000000..f9d7f890
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0011.html
@@ -0,0 +1,93 @@
+
+
+
                                                          Basic Concepts
                                                          
+
                                                          CCE provides highly scalable, high-performance, enterprise-class Kubernetes clusters and supports Docker containers. With CCE, you can easily deploy, manage, and scale containerized applications in the cloud.
                                                          
+
                                                          The graphical CCE console enables E2E user experiences. In addition, CCE supports native Kubernetes APIs and kubectl. Before using CCE, you are advised to understand related basic concepts.
                                                          
+
                                                          Cluster
                                                          A cluster is a group of one or more cloud servers (also known as nodes) in the same subnet. It has all the cloud resources (including VPCs and compute resources) required for running containers.
                                                          
+
                                                          
+
                                                          Node
                                                          A node is a cloud server (virtual or physical machine) running an instance of the Docker Engine. Containers are deployed, run, and managed on nodes. The node agent (kubelet) runs on each node to manage container instances on the node. The number of nodes in a cluster can be scaled.
                                                          
+
                                                          
+
                                                          Node Pool
                                                          A node pool contains one node or a group of nodes with identical configuration in a cluster.
                                                          
+
                                                          
+
                                                          Virtual Private Cloud (VPC)
                                                          A VPC is a logically isolated virtual network that facilitates secure internal network management and configurations. Resources in the same VPC can communicate with each other, but those in different VPCs cannot communicate with each other by default. VPCs provide the same network functions as physical networks and also advanced network services, such as elastic IP addresses and security groups.
                                                          
+
                                                          
+
                                                          Security Group
                                                          A security group is a collection of access control rules for ECSs that have the same security protection requirements and are mutually trusted in a VPC. After a security group is created, you can create different access rules for the security group to protect the ECSs that are added to this security group.
                                                          
+
                                                          
+
                                                          Relationship Between Clusters, VPCs, Security Groups, and Nodes
                                                          
+
                                                          As shown in Figure 1, a region may comprise multiple VPCs. A VPC consists of one or more subnets. The subnets communicate with each other through a subnet gateway. A cluster is created in a subnet. There are three scenarios:
                                                          • Different clusters are created in different VPCs.
                                                          • Different clusters are created in the same subnet.
                                                          • Different clusters are created in different subnets.
                                                          
+
                                                          
+
                                                          Figure 1 Relationship between clusters, VPCs, security groups, and nodes
                                                          
+
                                                          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 (or, in some cases, multiple containers), storage resources, a unique network IP address, and options that govern how the containers should run.
                                                          
+
                                                          Figure 2 Pod
                                                          
+
                                                          
+
                                                          Container
                                                          A container is a running instance of a Docker image. Multiple containers can run on one node. Containers are actually software processes. Unlike traditional software processes, containers have separate namespace and do not run directly on a host.
                                                          
+
                                                          Figure 3 Relationships between pods, containers, and nodes
                                                          
+
                                                          
+
                                                          Workload
                                                          A workload is an application running on Kubernetes. No matter how many components are there in your workload, you can run it in a group of Kubernetes pods. A workload is an abstract model of a group of pods in Kubernetes. Workloads classified in Kubernetes include Deployments, StatefulSets, DaemonSets, jobs, and cron jobs.
                                                          
+
                                                          • Deployment: Pods are completely independent of each other and functionally identical. They feature auto scaling and rolling upgrade. Typical examples include Nginx and WordPress.
                                                          • StatefulSet: Pods are not completely independent of each other. They have stable persistent storage, and feature orderly deployment and deletion. Typical examples include MySQL-HA and etcd.
                                                          • DaemonSet: A DaemonSet ensures that all or some nodes run a pod. It is applicable to pods running on every node. Typical examples include Ceph, Fluentd, and Prometheus Node Exporter.
                                                          • Job: It is a one-time task that runs to completion. It can be executed immediately after being created. Before creating a workload, you can execute a job to upload an image to the image repository.
                                                          • Cron job: It runs a job periodically on a given schedule. You can perform time synchronization for all active nodes at a fixed time point.
                                                          
+
                                                          Figure 4 Relationship between workloads and pods
                                                          
+
                                                          
+
                                                          Image
                                                          Docker creates an industry standard for packaging containerized applications. Docker images are like templates that include everything needed to run containers, and are used to create Docker containers. In other words, Docker image is a special file system that includes everything needed to run containers: programs, libraries, resources, and configuration files. It also contains configuration parameters (such as anonymous volumes, environment variables, and users) required within a container runtime. An image does not contain any dynamic data. Its content remains unchanged after being built. When deploying containerized applications, you can use images from Docker Hub, SoftWare Repository for Container (SWR), and your private image registries. For example, a Docker image can contain a complete Ubuntu operating system, in which only the required programs and dependencies are installed.
                                                          
+
                                                          Images become containers at runtime, that is, containers are created from images. Containers can be created, started, stopped, deleted, and suspended.
                                                          
+
                                                          Figure 5 Relationship between images, containers, and workloads
                                                          
+
                                                          
+
                                                          Namespace
                                                          A namespace is an abstract collection of resources and objects. It enables resources to be organized into non-overlapping groups. Multiple namespaces can be created inside a cluster and isolated from each other. This enables namespaces to share the same cluster services without affecting each other. Examples:
                                                          
+
                                                          • You can deploy workloads in a development environment into one namespace, and deploy workloads in a test environment into another namespace.
                                                          • Pods, Services, ReplicationControllers, and Deployments belong to a namespace (named default, by default), whereas nodes and PersistentVolumes do not belong to any namespace.
                                                          
+
                                                          
+
                                                          Service
                                                          A Service is an abstract method that exposes a group of applications running on a pod as network services.
                                                          
+
                                                          Kubernetes provides you with a service discovery mechanism without modifying applications. In this mechanism, Kubernetes provides pods with their own IP addresses and a single DNS for a group of pods, and balances load between them.
                                                          
+
                                                          Kubernetes allows you to specify a Service of a required type. The values and actions of different types of Services are as follows:
                                                          
+
                                                          • ClusterIP: ClusterIP Service, as the default Service type, is exposed through the internal IP address of the cluster. If this mode is selected, Services can be accessed only within the cluster.
                                                          • NodePort: NodePort Services are exposed through the IP address and static port of each node. A ClusterIP Service, to which a NodePort Service will route, is automatically created. By sending a request to <NodeIP>:<NodePort>, you can access a NodePort Service from outside of a cluster.
                                                          • LoadBalancer (ELB): LoadBalancer (ELB) Services are exposed by using load balancers of the cloud provider. External load balancers can route to NodePort and ClusterIP Services.
                                                          
+
                                                          
+
                                                          Layer-7 Load Balancing (Ingress)
                                                          An ingress is a set of routing rules for requests entering a cluster. It provides Services with URLs, load balancing, SSL termination, and HTTP routing for external access to the cluster.
                                                          
+
                                                          
+
                                                          Network Policy
                                                          Network policies provide policy-based network control to isolate applications and reduce the attack surface. A network policy uses label selectors to simulate traditional segmented networks and controls traffic between them and traffic from outside.
                                                          
+
                                                          
+
                                                          ConfigMap
                                                          A ConfigMap is used to store configuration data or configuration files as key-value pairs. ConfigMaps are similar to secrets, but provide a means of working with strings that do not contain sensitive information.
                                                          
+
                                                          
+
                                                          Secret
                                                          Secrets resolve the configuration problem of sensitive data such as passwords, tokens, and keys, and will not expose the sensitive data in images or pod specs. A secret can be used as a volume or an environment variable.
                                                          
+
                                                          
+
                                                          Label
                                                          A label is a key-value pair and is associated with an object, for example, a pod. Labels are used to identify special features of objects and are meaningful to users. However, labels have no direct meaning to the kernel system.
                                                          
+
                                                          
+
                                                          Label Selector
                                                          Label selector is the core grouping mechanism of Kubernetes. It identifies a group of resource objects with the same characteristics or attributes through the label selector client or user.
                                                          
+
                                                          
+
                                                          Annotation
                                                          Annotations are defined in key-value pairs as labels are.
                                                          
+
                                                          Labels have strict naming rules. They define the metadata of Kubernetes objects and are used by label selectors.
                                                          
+
                                                          Annotations are additional user-defined information for external tools to search for a resource object.
                                                          
+
                                                          
+
                                                          PersistentVolume
                                                          A PersistentVolume (PV) is a network storage in a cluster. Similar to a node, it is also a cluster resource.
                                                          
+
                                                          
+
                                                          PersistentVolumeClaim
                                                          A PV is a storage resource, and a PersistentVolumeClaim (PVC) is a request for a PV. PVC is similar to pod. Pods consume node resources, and PVCs consume PV resources. Pods request CPU and memory resources, and PVCs request data volumes of a specific size and access mode.
                                                          
+
                                                          
+
                                                          Auto Scaling - HPA
                                                          Horizontal Pod Autoscaling (HPA) is a function that implements horizontal scaling of pods in Kubernetes. The scaling mechanism of ReplicationController can be used to scale your Kubernetes clusters.
                                                          
+
                                                          
+
                                                          Affinity and Anti-Affinity
                                                          If an application is not containerized, multiple components of the application may run on the same virtual machine and processes communicate with each other. However, in the case of containerization, software processes are packed into different containers and each container has its own lifecycle. For example, the transaction process is packed into a container while the monitoring/logging process and local storage process are packed into other containers. If closely related container processes run on distant nodes, routing between them will be costly and slow.
                                                          
+
                                                          • Affinity: Containers are scheduled onto the nearest node. For example, if application A and application B frequently interact with each other, it is necessary to use the affinity feature to keep the two applications as close as possible or even let them run on the same node. In this way, no performance loss will occur due to slow routing.
                                                          • Anti-affinity: Instances of the same application spread across different nodes to achieve higher availability. Once a node is down, instances on other nodes are not affected. For example, if an application has multiple replicas, it is necessary to use the anti-affinity feature to deploy the replicas on different nodes. In this way, no single point of failure will occur.
                                                          
+
                                                          
+
                                                          Node Affinity
                                                          By selecting labels, you can schedule pods to specific nodes.
                                                          
+
                                                          
+
                                                          Node Anti-Affinity
                                                          By selecting labels, you can prevent pods from being scheduled to specific nodes.
                                                          
+
                                                          
+
                                                          Pod Affinity
                                                          You can deploy pods onto the same node to reduce consumption of network resources.
                                                          
+
                                                          
+
                                                          Pod Anti-Affinity
                                                          You can deploy pods onto different nodes to reduce the impact of system breakdowns. Anti-affinity deployment is also recommended for workloads that may interfere with each other.
                                                          
+
                                                          
+
                                                          Resource Quota
                                                          Resource quotas are used to limit the resource usage of users.
                                                          
+
                                                          
+
                                                          Resource Limit (LimitRange)
                                                          By default, all containers in Kubernetes have no CPU or memory limit. LimitRange (limits for short) is used to add a resource limit to a namespace, including the minimum, maximum, and default amounts of resources. When a pod is created, resources are allocated according to the limits parameters.
                                                          
+
                                                          
+
                                                          Environment Variable
                                                          An environment variable is a variable whose value can affect the way a running container will behave. A maximum of 30 environment variables can be defined at container creation time. You can modify environment variables even after workloads are deployed, increasing flexibility in workload configuration.
                                                          
+
                                                          The function of setting environment variables on CCE is the same as that of specifying ENV in a Dockerfile.
                                                          
+
                                                          
+
                                                          Chart
                                                          For your Kubernetes clusters, you can use Helm to manage software packages, which are called charts. Helm is to Kubernetes what the apt command is to Ubuntu or what the yum command is to CentOS. Helm can quickly search for, download, and install charts.
                                                          
+
                                                          Charts are a Helm packaging format. It describes only a group of related cluster resource definitions, not a real container image package. A Helm chart contains only a series of YAML files used to deploy Kubernetes applications. You can customize some parameter settings in a Helm chart. When installing a chart, Helm deploys resources in the cluster based on the YAML files defined in the chart. Related container images are not included in the chart but are pulled from the image repository defined in the YAML files.
                                                          
+
                                                          Application developers need to push container image packages to the image repository, use Helm charts to package dependencies, and preset some key parameters to simplify application deployment.
                                                          
+
                                                          Helm directly installs applications and their dependencies in the cluster based on the YAML files in a chart. Application users can search for, install, upgrade, roll back, and uninstall applications without defining complex deployment files.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Basic Concepts
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0012.html b/docs/cce/umn/cce_productdesc_0012.html
new file mode 100644
index 00000000..abe7667c
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0012.html
@@ -0,0 +1,23 @@
+
+
+
                                                          Regions and AZs
                                                          
+
                                                          Definition
                                                          A region and availability zone (AZ) identify the location of a data center. You can create resources in a specific region and AZ.
                                                          
+
                                                          • Regions are divided based on geographical location and network latency. Public services, such as Elastic Cloud Server (ECS), Elastic Volume Service (EVS), Object Storage Service (OBS), Virtual Private Cloud (VPC), Elastic IP (EIP), and Image Management Service (IMS), are shared within the same region. Regions are classified as universal regions and dedicated regions. A universal region provides universal cloud services for common domains. A dedicated region provides services of the same type only or for specific domains.
                                                          • An AZ contains one or more physical data centers. Each AZ has independent cooling, fire extinguishing, moisture-proof, and electricity facilities. Within an AZ, computing, network, storage, and other resources are logically divided into multiple clusters. AZs in a region are interconnected through high-speed optic fibers. This is helpful if you will deploy systems across AZs to achieve higher availability.
                                                          
+
                                                          Cloud services are available in many regions around the world. You can select a region and AZ as needed.
                                                          
+
                                                          
+
                                                          How to Select a Region?
                                                          When selecting a region, consider the following factors:
                                                          • Location
                                                            Select a region close to you or your target users to reduce network latency and improve access rate.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          Selecting an AZ
                                                          When deploying resources, consider your applications' requirements on disaster recovery (DR) and network latency.
                                                          
+
                                                          • For high DR capability, deploy resources in different AZs within the same region.
                                                          • For lower network latency, deploy resources in the same AZ.
                                                          
+
                                                          
+
                                                          Regions and Endpoints
                                                          When using an API to access resources, you must specify a region and endpoint. For more information about regions and endpoints, see Regions and Endpoints.
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Basic Concepts
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0015.html b/docs/cce/umn/cce_productdesc_0015.html
new file mode 100644
index 00000000..d1644135
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0015.html
@@ -0,0 +1,22 @@
+
+
+
                                                          Auto Scaling in Seconds
                                                          
+
                                                          Application Scenarios
                                                          • Shopping apps and websites, especially during promotions and flash sales
                                                          • Live streaming, where service loads often fluctuate
                                                          • Games, where many players may go online in certain time periods
                                                          
+
                                                          
+
                                                          Benefits
                                                          CCE auto adjusts capacity to cope with service surges according to the policies you set. CCE adds or reduces cloud servers and containers to scale your cluster and workloads. Your applications will always have the right resources at the right time.
                                                          
+
                                                          
+
                                                          Advantages
                                                          • Flexible
                                                            Allows diverse types of scaling policies and scales containers within seconds once triggered.
                                                            
+
                                                          • Highly available
                                                            Monitors pod running and replaces unhealthy pods with new ones.
                                                            
+
                                                          • Lower costs
                                                            Bills you only for the scaled cloud servers as you use.
                                                            
+
                                                          
+
                                                          
+
                                                          Related Services
                                                          HPA (Horizontal Pod Autoscaling) + CA (Cluster AutoScaling)
                                                          
+
                                                          Figure 1 How auto scaling works
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Application Scenarios
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0017.html b/docs/cce/umn/cce_productdesc_0017.html
new file mode 100644
index 00000000..99ef3003
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0017.html
@@ -0,0 +1,22 @@
+
+
+
                                                          DevOps and CI/CD
                                                          
+
                                                          Application Scenario
                                                          You may receive a lot feedback and requirements for your apps or services. You may want to boost user experience with new features. Continuous integration (CI) and delivery (CD) can help. CI/CD automates builds, tests, and merges, making app delivery faster.
                                                          
+
                                                          
+
                                                          Benefits
                                                          CCE works with SWR to support DevOps and CI/CD. A pipeline automates coding, image build, grayscale release, and deployment based on code sources. Existing CI/CD systems can connect to CCE to containerize legacy applications.
                                                          
+
                                                          
+
                                                          Advantages
                                                          • Efficient process
                                                            Reduces scripting workload by more than 80% through streamlined processes.
                                                            
+
                                                          • Flexible integration
                                                            Provides various APIs to integrate with existing CI/CD systems for in-depth customization.
                                                            
+
                                                          • High performance
                                                            Enables flexible scheduling with a containerized architecture.
                                                            
+
                                                          
+
                                                          
+
                                                          Related Services
                                                          Software Repository for Container (SWR), Object Storage Service (OBS), Virtual Private Network (VPN)
                                                          
+
                                                          Figure 1 How DevOps works
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Application Scenarios
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0018.html b/docs/cce/umn/cce_productdesc_0018.html
new file mode 100644
index 00000000..d83785b6
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0018.html
@@ -0,0 +1,27 @@
+
+
+
                                                          Hybrid Cloud Architecture
                                                          
+
                                                          Application Scenarios
                                                          • Multi-cloud deployment and disaster recovery
                                                            Running apps in containers on different clouds can ensure high availability. When a cloud is down, other clouds respond and serve.
                                                            
+
                                                          • Traffic distribution and auto scaling
                                                            Large organizations often span cloud facilities in different regions. They need to communicate and auto scale — start small and then scale as system load grows. CCE takes care of these for you, cutting the costs of maintaining facilities.
                                                            
+
                                                          • Migration to the cloud and database hosting
                                                            Industries like finance and security have a top concern on data protection. They want to run critical systems in local IDCs while moving others to the cloud. They also expect one unified dashboard to manage all systems.
                                                            
+
                                                          • Environment decoupling
                                                            To ensure IP security, you can decouple development from production. Set up one on the public cloud and the other in the local IDC.
                                                            
+
                                                          
+
                                                          
+
                                                          Benefits
                                                          Your apps and data can flow free on and off the cloud. Resource scheduling and DR are much easier, thanks to environment-independent containers. CCE connects private and public clouds for you to run containers on them.
                                                          
+
                                                          
+
                                                          Advantages
                                                          • On-cloud DR
                                                            Multicloud prevents systems from outages. When a cloud is faulty, CCE auto diverts traffic to other clouds to ensure service continuity.
                                                            
+
                                                          • Automatic traffic distribution
                                                            CCE reduces access latency by processing user requests on the nodes nearest to the users. Overloaded apps in local IDCs can be burst to the cloud backed by auto scaling.
                                                            
+
                                                          • Decoupling and sharing
                                                            CCE decouples data, environments, and compute capacity. Sensitive data vs general data. Development vs production. Compute-intensive services vs general services. Apps running on-premises can burst to the cloud. Your resources on and off the cloud can be better used.
                                                            
+
                                                          • Lower costs
                                                            Public cloud resource pools, backed by auto scaling, can respond to load spikes in time. Manual operations are no longer needed and you can save big.
                                                            
+
                                                          
+
                                                          
+
                                                          Related Services
                                                          Elastic Cloud Server (ECS), Direct Connect (DC), Virtual Private Network (VPN), SoftWare Repository for Container (SWR)
                                                          
+
                                                          Figure 1 How hybrid cloud works
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Application Scenarios
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_productdesc_0020.html b/docs/cce/umn/cce_productdesc_0020.html
new file mode 100644
index 00000000..501da97a
--- /dev/null
+++ b/docs/cce/umn/cce_productdesc_0020.html
@@ -0,0 +1,21 @@
+
+
+
                                                          Infrastructure and Containerized Application Management
                                                          
+
                                                          Application Scenario
                                                          In CCE, you can run clusters with x86 and Arm nodes. Create and manage Kubernetes clusters. Deploy containerized applications in them. All done in CCE.
                                                          
+
                                                          Figure 1 CCE cluster
                                                          
+
                                                          
+
                                                          Benefits
                                                          Containerization requires less resources to deploy application. Services are not uninterrupted during upgrades.
                                                          
+
                                                          
+
                                                          Advantages
                                                          • Multiple types of workloads
                                                            Runs Deployments, StatefulSets, DaemonSets, jobs, and cron jobs to meet different needs.
                                                            
+
                                                          • Application upgrade
                                                            Upgrades your apps in replace or rolling mode (by proportion or by number of pods), or rolls back the upgrades.
                                                            
+
                                                          • Auto scaling
                                                            Auto scales your nodes and workloads according to the policies you set.
                                                            
+
                                                          
+
                                                          Figure 2 Workload
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Application Scenarios
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_qs_0000.html b/docs/cce/umn/cce_qs_0000.html
new file mode 100644
index 00000000..0f4bc672
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0000.html
@@ -0,0 +1,19 @@
+
+
+
                                                          Getting Started
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_qs_0001.html b/docs/cce/umn/cce_qs_0001.html
index 9cd4c9ee..8695526e 100644
--- a/docs/cce/umn/cce_qs_0001.html
+++ b/docs/cce/umn/cce_qs_0001.html
@@ -1,26 +1,26 @@
 
 
-
                                                          Instruction
                                                          
-
                                                          This document provides instructions for getting started with the Cloud Container Engine (CCE).
                                                          
-
                                                          Procedure
                                                          Complete the following tasks to get started with CCE.
                                                          
-
                                                          Figure 1 Procedure for getting started with CCE
                                                          
-
                                                          1. Charts (Helm)Authorize an IAM user to use CCE.
                                                            The accounts have the permission to use CCE. However, IAM users created by the accounts do not have the permission. You need to manually assign the permission to IAM users.
                                                            
-
                                                          2. Create a cluster.
                                                            For details on how to create a regular Kubernetes cluster, see Creating a CCE Cluster.
                                                            
-
                                                          3. Create a workload from images or a chart.
                                                            Select existing images/chart, or create new images/chart.
                                                            
-
                                                            • For details on how to create a workload from images, see Workloads.
                                                            • For details on how to create a workload from a chart, see Charts (Helm).
                                                            
-
                                                          4. View workload status and logs. Upgrade, scale, and monitor the workload.
                                                            For details, see Managing Workloads and Jobs.
                                                            
-
                                                          
+
                                                          Introduction
                                                          
+
                                                          This section describes how to use Cloud Container Engine (CCE) and provides frequently asked questions (FAQs) to help you quickly get started with CCE.
                                                          
+
                                                          Procedure
                                                          Complete the following tasks to get started with CCE.
                                                          
+
                                                          Figure 1 Procedure for getting started with CCE
                                                          
+
                                                          1. Register an account and grant permissions to IAM users.
                                                            An account has the permissions to use CCE. However, IAM users created by an account do not have the permission. You need to manually grant the permission to IAM users. For details, see .
                                                            
+
                                                          2. Create a cluster.
                                                            For details on how to create a regular Kubernetes cluster, see Creating a Kubernetes Cluster.
                                                            
+
                                                          3. Create a workload from an image or chart.
                                                            
+
                                                          4. View workload status and logs. Upgrade, scale, and monitor the workload.
                                                          
 
                                                          
-
                                                          FAQs
                                                          1. Is CCE suitable for users who are not familiar with Kubernetes?
                                                            Yes. The CCE console is easy-to-use.
                                                            
-
                                                          2. Is CCE suitable for users who have little experience in building images?
                                                            Yes. You can select images from Third-party Images, and Shared Images pages on the CCE console. The My Images page displays only the images created by you. For details, see Workloads.
                                                            
-
                                                          3. How do I create a workload using CCE?
                                                            Create a cluster and then create a workload in the cluster.
                                                            
-
                                                          4. How do I create a workload accessible to public networks?
                                                            CCE provides different types of Services for workload access in diverse scenarios. Currently, CCE provides two access types to expose a workload to public networks: NodePort and LoadBalancer. For details, see Networking.
                                                            
-
                                                          5. How can I allow multiple workloads in the same cluster to access each other?
                                                            Select the access type ClusterIP, which allows workloads in the same cluster to use their cluster-internal domain names to access each other.
                                                            
-
                                                            Cluster-internal domain names are in the format of <self-defined service name>.<workload's namespace>.svc.cluster.local:<port number>. For example, nginx.default.svc.cluster.local:80.
                                                            
-
                                                            Example:
                                                            
-
                                                            Assume that workload A needs to access workload B in the same cluster. Then, you can create a ClusterIP Service for workload B. After the ClusterIP Service is created, workload B is reachable at <self-defined service name>.<workload B's namespace>.svc.cluster.local:<port number>.
                                                            
+
                                                            FAQs
                                                            1. Is CCE suitable for users who are not familiar with Kubernetes?
                                                              Yes. The CCE console is easy-to-use, and the Getting Started guide helps you quickly understand and use CCE.
                                                              
+
                                                            2. Is CCE suitable for users who have little experience in building images?
                                                              In addition to storing images created by yourself in My Images, CCE allows you to create containerized applications using open source images. For details, see Creating a Deployment (Nginx) from an Image.
                                                              
+
                                                            3. How do I create a workload using CCE?
                                                              Create a cluster and then create a workload in the cluster. For details, see Creating a Deployment (Nginx) from an Image.
                                                              
+
                                                            4. How do I create a workload accessible to public networks?
                                                              CCE provides different workload access types to address diverse scenarios. 
                                                              
+
                                                            5. How can I allow multiple workloads in the same cluster to access each other?
                                                              Set Service Type to ClusterIP, which allows workloads in the same cluster to use their cluster-internal domain names to access each other.
                                                              
+
                                                              Cluster-internal domain names are in the format of <self-defined service name>.<workload's namespace>.svc.cluster.local:<port number>. For example, nginx.default.svc.cluster.local:80.
                                                              
 
                                                            
 
                                                            
 
                                                          
-
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Getting Started
                                                          
+
                                                          
+
                                                          
 
diff --git a/docs/cce/umn/cce_qs_0003.html b/docs/cce/umn/cce_qs_0003.html
new file mode 100644
index 00000000..dd25ccba
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0003.html
@@ -0,0 +1,36 @@
+
+
+
                                                          Creating a Deployment (Nginx) from an Image
                                                          
+
                                                          You can use images to quickly create a single-pod workload that can be accessed from public networks. This section describes how to use CCE to quickly deploy an Nginx application and manage its life cycle.
                                                          
+
                                                          Prerequisites
                                                          • The Nginx image has been pushed to SWR.
                                                          • You have created a CCE cluster that contains a node with 4 vCPUs and 8 GB memory. The node has an elastic IP address (EIP).
                                                          
+
                                                          • A cluster is a logical group of cloud servers that run workloads. Each cloud server is a node in the cluster.
                                                          • For details on how to create a cluster, see Creating a Kubernetes Cluster.
                                                          
+
                                                          
+
                                                          Nginx Overview
                                                          Nginx is a lightweight web server. On CCE, you can quickly set up a Nginx web server. 
                                                          
+
                                                          
+
                                                          This section uses the Nginx application as an example to describe how to create a workload. The creation takes about 5 minutes.
                                                          
+
                                                          After Nginx is created successfully, you can access the Nginx web page.
                                                          
+
                                                          Figure 1 Nginx web page
                                                          
+
                                                          Procedure
                                                          The following is the procedure for creating a containerized workload from a container image.
                                                          
+
                                                          1. Log in to the CCE console.
                                                          2. Choose the target cluster.
                                                          3. In the navigation pane, choose Workloads. Then, click Create Workload.
                                                          4. Configure the following parameters and retain the default value for other parameters:
                                                            Basic Info
                                                            
+
                                                            • Workload Type: Select Deployment.
                                                            • Workload Name: Set it to nginx.
                                                            • Namespace: Select default.
                                                            • Pods: Set the quantity of pods to 1.
                                                            
+
                                                            Container Settings
                                                            
+
                                                            Enter nginx:latest in the Image Name text box.
                                                            
+
                                                            Service Settings
                                                            
+
                                                            Click the plus sign (+) to create a Service for accessing the workload from an external network. In this example, create a LoadBalancer Service. Set the following parameters:
                                                            
+
                                                            • Service Name: name of the Service exposed to external networks. In this example, the Service name is nginx.
                                                            • Service Type: Select LoadBalancer.
                                                            • Service Affinity: Retain the default value.
                                                            • Load Balancer: If a load balancer is available, select an existing load balancer. If not, choose Auto create to create one on the ELB console.
                                                            • Port:
                                                              • Protocol: Select TCP.
                                                              • Service Port: Set this parameter to 8080, which is mapped to the container port.
                                                              • Container Port: port on which the application listens. For containers created using the Nginx image, set this parameter to 80. For other applications, set this parameter to the port of the application.
                                                              
+
                                                            
+
                                                          5. Click Create Workload.
                                                            Wait until the workload is created.
                                                            
+
                                                            The created Deployment will be displayed on the Deployments page.
                                                            
+
                                                          
+
                                                          
+
                                                          Accessing Nginx
                                                          1. Obtain the external access address of Nginx.
                                                            Click the Nginx workload to enter its details page. On the Access Mode tab page, you can view the IP address of Nginx. The public IP address is the external access address.
                                                            
+
                                                          2. Enter the external access address in the address box of a browser. The following shows the welcome page if you successfully access the workload.
                                                            Figure 2 Accessing Nginx
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Getting Started
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_qs_0004.html b/docs/cce/umn/cce_qs_0004.html
new file mode 100644
index 00000000..131a29ce
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0004.html
@@ -0,0 +1,28 @@
+
+
+
                                                          Step 1: Create a MySQL Workload
                                                          
+
                                                          WordPress must be used together with MySQL. WordPress runs the content management program while MySQL serves as a database to store data.
                                                          
+
                                                          Prerequisites
                                                          • The WordPress and MySQL images have been pushed to SWR.
                                                          • You have created a CCE cluster that contains a node with 4 vCPUs and 8 GB memory. For details on how to create a cluster, see Creating a Kubernetes Cluster.
                                                          
+
                                                          
+
                                                          Creating a MySQL Workload
                                                          1. Log in to the CCE console.
                                                          2. Choose the target cluster.
                                                          3. In the navigation pane, choose Workloads. Then, click Create Workload.
                                                          4. Set workload parameters.
                                                            Basic Info
                                                            • Workload Type: Select Deployment.
                                                            • Workload Name: Set it to mysql.
                                                            • Namespace: Select default.
                                                            • Pods: Change the value to 1 in this example.
                                                            
+
                                                            
+
                                                            Container Settings
                                                            
+
                                                            Enter mysql:5.7 in the Image Name text box.
                                                            
+
                                                            Add the following four environment variables (details available in MySQL):
                                                            
+
                                                            • MYSQL_ROOT_PASSWORD: password of the root user of MySQL.
                                                            • MYSQL_DATABASE: name of the database created during image startup.
                                                            • MYSQL_USER: name of the database user.
                                                            • MYSQL_PASSWORD: password of the database user.
                                                            
+
                                                            Service Settings
                                                            
+
                                                            Click the plus sign (+) to create a Service for accessing MySQL from WordPress.
                                                            
+
                                                            Select ClusterIP for Service Type, set Service Name to mysql, set both the Container Port and Service Port to 3306, and click OK.
                                                            
+
                                                            The default access port in the MySQL image is 3306. In this example, both the container port and Service port are set to 3306 for convenience. The access port can be changed to another port.
                                                            
+
                                                            In this way, the MySQL workload can be accessed through Service name:Access port (mysql:3306 in this example) from within the cluster.
                                                            
+
                                                          5. Click Create Workload.
                                                            Wait until the workload is created.
                                                            
+
                                                            The created Deployment will be displayed on the Deployments page.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_qs_0005.html b/docs/cce/umn/cce_qs_0005.html
new file mode 100644
index 00000000..c0823502
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0005.html
@@ -0,0 +1,38 @@
+
+
+
                                                          Step 2: Create a WordPress Workload
                                                          
+
                                                          WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any server that supports PHP and MySQL.  Thousands of plug-ins and countless theme templates are available for WordPress and easy to install.
                                                          
+
                                                          This section describes how to create a public WordPress website from images.
                                                          
+
                                                          Prerequisites
                                                          • The WordPress and MySQL images have been pushed to SWR.
                                                          • You have created a CCE cluster that contains a node with 4 vCPUs and 8 GB memory. For details on how to create a cluster, see Creating a Kubernetes Cluster.
                                                          • The MySQL database has been created by following the instructions in Step 1: Create a MySQL Workload. In this example, WordPress data is stored in the MySQL database.
                                                          
+
                                                          
+
                                                          Creating a WordPress Blog Website
                                                          1. Log in to the CCE console.
                                                          2. Choose the target cluster.
                                                          3. In the navigation pane, choose Workloads. Then, click Create Workload.
                                                          4. Set workload parameters.
                                                            Basic Info
                                                            • Workload Type: Select Deployment.
                                                            • Workload Name: Set it to wordpress.
                                                            • Namespace: Select default.
                                                            • Pods: Set this parameter to 2 in this example.
                                                            
+
                                                            
+
                                                            Container Settings
                                                            
+
                                                            Enter wordpress:php7.3 in the Image Name text box.
                                                            
+
                                                            Add the following environment variables:
                                                            
+
                                                            (These variables let WordPress know the information about the MySQL database.)
                                                            
+
                                                            • WORDPRESS_DB_HOST: address for accessing the database, which can be found in the Service (on the Services tab page) of the MySQL workload. You can use the internal domain name mysql.default.svc.cluster.local:3306 to access the database, or use only mysql:3306 omitting .default.svc.cluster.local.
                                                            • WORDPRESS_DB_USER: username for accessing the database. The value must be the same as that of MYSQL_USER in Step 1: Create a MySQL Workload, which is used to connect to MySQL.
                                                            • WORDPRESS_DB_PASSWORD: password for accessing the database. The value must be the same as that of MYSQL_PASSWORD in Step 1: Create a MySQL Workload.
                                                            • WORDPRESS_DB_NAME: name of the database to be accessed. The value must be the same as that of MYSQL_DATABASE in Step 1: Create a MySQL Workload.
                                                            
+
                                                            Service Settings
                                                            
+
                                                            Click the plus sign (+) to create a Service for accessing the workload from an external network. In this example, create a LoadBalancer Service. Set the following parameters:
                                                            
+
                                                            • Service Name: name of the Service exposed to external networks. In this example, the Service name is wordpress.
                                                            • Service Type: Select LoadBalancer.
                                                            • Service Affinity: Retain the default value.
                                                            • Load Balancer: If a load balancer is available, select an existing load balancer. If not, choose Auto create to create one on the ELB console.
                                                            • Port:
                                                              • Protocol: Select TCP.
                                                              • Service Port: Set this parameter to 80, which is mapped to the container port.
                                                              • Container Port: port on which the application listens. For containers created using the wordpress image, set this parameter to 80. For other applications, set this parameter to the port of the application.
                                                              
+
                                                            
+
                                                          5. Click Create Workload.
                                                            Wait until the workload is created.
                                                            
+
                                                            The created Deployment will be displayed on the Deployments page.
                                                            
+
                                                          
+
                                                          
+
                                                          Accessing WordPress
                                                          1. Obtain the external access address of WordPress.
                                                            Click the wordpress workload to enter its details page. On the Access Mode tab page, you can view the IP address of WordPress. The load balancer IP address is the external access address.
                                                            
+
                                                          2. Enter the external access address in the address box of a browser to connect to the workload.
                                                            The following figure shows the accessed WordPress page.
                                                            
+
                                                            Figure 1 WordPress workload
                                                            
+
                                                            Figure 2 WordPress
                                                            
+
                                                          
+
                                                          
+
                                                          Deleting Resources
                                                          Until now, you have completed all the Getting Started walkthroughs and have understood how to use CCE. Fees are incurred while nodes are running. If the clusters used in the Getting Started walkthroughs are no longer in use, perform the following steps to delete them. If you will continue the CCE walkthroughs, retain the clusters.
                                                          
+
                                                          1. Log in to the CCE console.
                                                          2. In the navigation pane on the left, choose Clusters.
                                                          3. Click  next to a cluster and delete the cluster as prompted.
                                                          
+
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_qs_0006.html b/docs/cce/umn/cce_qs_0006.html
new file mode 100644
index 00000000..a0f2266e
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0006.html
@@ -0,0 +1,42 @@
+
+
+
                                                          Preparations
                                                          
+
                                                          Before using CCE, you need to make the following preparations:
                                                          
+
+
                                                          Creating an IAM user
                                                          If you want to allow multiple users to manage your resources without sharing your password or keys, you can create users using IAM and grant permissions to the users. These users can use specified links and their own accounts to access the cloud and manage resources efficiently. You can also configure account security policies to ensure the security of these accounts.
                                                          
+
                                                          Your accounts have the permissions to use CCE. However, IAM users created by your accounts do not have the permissions. You need to manually assign the permissions to IAM users. 
                                                          
+
                                                          
+
                                                          Obtaining Resource Permissions
                                                          CCE works closely with multiple cloud services to support computing, storage, networking, and monitoring functions. When you log in to the CCE console for the first time, CCE automatically requests permissions to access those cloud services in the region where you run your applications. Specifically:
                                                          • Compute services
                                                            When you create a node in a cluster, a cloud server is created accordingly. The prerequisite is that CCE has obtained the permissions to access Elastic Cloud Service (ECS) and Bare Metal Server (BMS).
                                                            
+
                                                          • Storage services
                                                            CCE allows you to mount storage to nodes and containers in a cluster. The prerequisite is that CCE has obtained the permissions to access services such as Elastic Volume Service (EVS), Scalable File Service (SFS), and Object Storage Service (OBS).
                                                            
+
                                                          • Networking services
                                                            CCE allows containers in a cluster to be published as services that can be accessed by external systems. The prerequisite is that CCE has obtained the permissions to access services such as Virtual Private Cloud (VPC) and Elastic Load Balance (ELB).
                                                            
+
                                                          • Container and monitoring services
                                                            CCE supports functions such as container image pull, monitoring, and logging. The prerequisite is that CCE has obtained the permissions to access services such as SoftWare Repository for Container (SWR) and Application Operations Management (AOM).
                                                            
+
                                                          
+
                                                          
+
                                                          After you agree to delegate the permissions, an agency named cce_admin_trust will be created for CCE in Identity and Access Management (IAM). The system account op_svc_cce will be delegated the Tenant Administrator role to perform operations on other cloud service resources. Tenant Administrator has the permissions on all cloud services except IAM, which calls the cloud services on which CCE depends. The delegation takes effect only in the current region. For details, see Delegating Resource Access to Another Account.
                                                          
+
                                                          To use CCE in multiple regions, you need to request cloud resource permissions in each region. You can go to the IAM console, choose Agencies, and click cce_admin_trust to view the delegation records of each region.
                                                          
+
                                                           
                                                          CCE may fail to run as expected if the Tenant Administrator role is not assigned. Therefore, do not delete or modify the cce_admin_trust agency when using CCE.
                                                          
+
                                                          
+
                                                          
+
                                                          (Optional) Creating a VPC
                                                          A VPC provides an isolated, configurable, and manageable virtual network for CCE clusters.
                                                          
+
                                                          Before creating the first cluster, ensure that a VPC has been created. 
                                                          
+
                                                          If you already have a VPC available, skip this step.
                                                          
+
                                                          1. Log in to the management console.
                                                          2. Click  in the upper left corner and select a region and a project.
                                                          3. Under Networking, click Virtual Private Cloud.
                                                          4. Click Create VPC.
                                                          5. On the Create VPC page, configure parameters as prompted.
                                                            A default subnet will be created together with a VPC. You can click Add Subnet to create more subnets for the VPC.
                                                            
+
                                                          6. Click Create Now.
                                                          
+
                                                          
+
                                                          (Optional) Creating a Key Pair
                                                          The cloud platform uses public key cryptography to protect the login information of your CCE nodes. Passwords or key pairs are used for identity authentication during remote login to nodes.
                                                          
+
                                                          • You need to specify the key pair name and provide the private key when logging to CCE nodes using SSH if you choose the key pair login mode. 
                                                          • If you choose the password login mode, skip this task.
                                                          
+
                                                           
                                                          If you want to create pods in multiple regions, you need to create a key pair in each region. 
                                                          
+
                                                          
+
                                                          Creating a Key Pair on the Management Console
                                                          
+
                                                          If you have no key pair, create one on the management console. The procedure is as follows:
                                                          
+
                                                          1. Log in to the management console.
                                                          2. Click  in the upper left corner and select a region and a project.
                                                          3. Under Computing, click Elastic Cloud Server.
                                                          4. In the navigation pane on the left, choose Key Pair.
                                                          5. On the right pane, click Create Key Pair.
                                                          6. Enter the key name and click OK.
                                                          7. A key pair name consists of two parts: KeyPair and four random digits. You can enter an easy-to-remember name, for example, KeyPair-xxxx_ecs.
                                                          8. Manually or automatically download the private key file. The file name is a specified key pair name with a suffix of .pem. Securely store the private key file. In the dialog box displayed, click OK.
                                                             
                                                            The private key file can be downloaded only once. Keep it secure. When creating an ECS, provide the name of your desired key pair. Each time you log in to the ECS using SSH, provide the private key.
                                                            
+
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Getting Started
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_qs_0007.html b/docs/cce/umn/cce_qs_0007.html
new file mode 100644
index 00000000..d7048aa9
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0007.html
@@ -0,0 +1,19 @@
+
+
+
                                                          Deploying WordPress and MySQL That Depend on Each Other
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/cce_qs_0008.html b/docs/cce/umn/cce_qs_0008.html
new file mode 100644
index 00000000..b9111622
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0008.html
@@ -0,0 +1,99 @@
+
+
+
                                                          Creating a Kubernetes Cluster
                                                          
+
                                                          Context
                                                          This section describes how to quickly create a CCE cluster. In this example, the default or simple configurations are in use.
                                                          
+
                                                          
+
                                                          Creating a Cluster
                                                          1. Log in to the CCE console.
                                                            • If you have not created a cluster, a wizard page is displayed. Click Create under CCE cluster.
                                                            • If you have created a cluster, choose Clusters from the navigation pane on the left and click Create next to CCE cluster.
                                                            
+
                                                          2. On the Configure Cluster page, configure cluster parameters.
                                                            In this example, a majority of parameters retain default values. Only mandatory parameters are described. For details, see Table 1.
+
                                                            
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
                                                            Table 1 Parameters for creating a cluster
                                                            Parameter
                                                            
+
                                                            Description
                                                            
+
                                                            Basic Settings
                                                            
+
                                                            *Cluster Name
                                                            
+
                                                            Name of the cluster to be created. A cluster name contains 4 to 128 characters starting with a lowercase letter and not ending with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
                                                            
+
                                                            * Enterprise Project
                                                            
+
                                                            This parameter is displayed only for enterprise users who have enabled Enterprise Project Management.
                                                            
+
                                                            * Cluster Version
                                                            
+
                                                            Choose the latest version.
                                                            
+
                                                            * Cluster Scale
                                                            
+
                                                            Maximum number of worker nodes that can be managed by the cluster. If you select 50 nodes, the cluster can manage a maximum of 50 worker nodes.
                                                            
+
                                                            *High Availability
                                                            
+
                                                            The default value is Yes.
                                                            
+
                                                            Network Settings
                                                            
+
                                                            * Network Model
                                                            
+
                                                            Retain the default settings.
                                                            
+
                                                            *VPC
                                                            
+
                                                            VPC where the cluster will be located.
                                                            
+
                                                            If no VPC is available, click Create VPC to create one. After the VPC is created, click refresh.
                                                            
+
                                                            * Master Node Subnet
                                                            
+
                                                            Subnet where master nodes of the cluster are located.
                                                            
+
                                                            * Container CIDR Block
                                                            
+
                                                            Retain the default value.
                                                            
+
                                                            * IPv4 Service CIDR Block
                                                            
+
                                                            CIDR block for Services used by containers in the same cluster to access each other. The value determines the maximum number of Services you can create. The value cannot be changed after creation.
                                                            
+
                                                            
+
                                                            
+
                                                            
+
                                                          3. Click Next: Add-on Configuration. Retain the default settings.
                                                          4. Click Next: Confirm. After confirming that the cluster configuration information is correct, select I have read and understand the preceding instructions and click Submit.
                                                            It takes about 6 to 10 minutes to create a cluster.
                                                            
+
                                                            The created cluster will be displayed on the Clusters page, and the number of nodes in the cluster is 0.
                                                            
+
                                                          
+
                                                          
+
                                                          Creating a Node
                                                          After a cluster is created, you need to create nodes in the cluster to run workloads.
                                                          
+
                                                          1. Log in to the CCE console.
                                                          2. Click the created cluster.
                                                          3. In the navigation pane, choose Nodes. Click Create Node in the upper right corner and set node parameters.
                                                            The following describes only important parameters. For other parameters, retain the defaults.
                                                            
+
                                                            Compute Settings
                                                            
+
                                                            • AZ: Retain the default value.
                                                            • Node Type: Select Elastic Cloud Server (VM).
                                                            • Specifications: Select node specifications that fit your business needs.
                                                            • Container Engine: Select a container engine as required.
                                                            • OS: Select the operating system (OS) of the nodes to be created.
                                                            • Node Name: Enter a node name.
                                                            • Login Mode:
                                                              • If the login mode is Key pair, select a key pair for logging to the node and select the check box to acknowledge that you have obtained the key file and without this file you will not be able to log in to the node.
                                                                A key pair is used for identity authentication when you remotely log in to a node. If no key pair is available, click Create Key Pair..
                                                                
+
                                                              
+
                                                            
+
                                                            Storage Settings
                                                            
+
                                                            • System Disk: Set disk type and capacity based on site requirements. The default disk capacity is 50 GB.
                                                            • Data Disk: Set disk type and capacity based on site requirements. The default disk capacity is 100 GB.
                                                            
+
                                                            Network Settings
                                                            
+
                                                            • VPC: Use the default value, that is, the subnet selected during cluster creation.
                                                            • Node Subnet: Select a subnet in which the node runs.
                                                            • Node IP: IP address of the specified node.
                                                            • EIP: The default value is Do not use. You can select Use existing and Auto create.
                                                            
+
                                                          4. At the bottom of the page, select the node quantity, and click Next: Confirm.
                                                          5. Review the node specifications, read the instructions, select I have read and understand the preceding instructions, and click Submit.
                                                            It takes about 6 to 10 minutes to add a node.
                                                            
+
                                                            The created node will be displayed on the Nodes page.
                                                            
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          
+
                                                          Parent topic: Getting Started
                                                          
+
                                                          
+
                                                          
+
diff --git a/docs/cce/umn/cce_qs_0009.html b/docs/cce/umn/cce_qs_0009.html
new file mode 100644
index 00000000..f946b27a
--- /dev/null
+++ b/docs/cce/umn/cce_qs_0009.html
@@ -0,0 +1,17 @@
+
+
+
                                                          Overview
                                                          
+
                                                          WordPress was originally a blog platform based on PHP and MySQL. It is gradually evolved into a content management system. You can set up your own blog website on any server that supports PHP and MySQL.  Thousands of plug-ins and countless theme templates are available for WordPress and easy to install.
                                                          
+
                                                          WordPress is a blog platform developed in hypertext preprocessor (PHP). You can set up your websites on the services that support PHP and MySQL databases, or use WordPress as a content management system. For more information about WordPress, visit https://wordpress.org/.
                                                          
+
                                                          WordPress must be used together with MySQL. WordPress runs the content management program while MySQL serves as a database to store data. Generally, WordPress and MySQL run in different containers, as shown in the following figure.
                                                          
+
                                                          Figure 1 WordPress
                                                          
+
                                                          In this example, two container images are involved.
                                                          
+
                                                          • WordPress: Select wordpress:php7.3 in this example.
                                                          • MySQL: Select mysql:5.7 in this example.
                                                          
+
                                                          When WordPress accesses MySQL in a cluster, Kubernetes provides a resource object called Service for the workload access. In this example, a Service is created for MySQL and WordPress, respectively. For details about how to create and configure a Service, see the following sections.
                                                          
+
                                                          
+
+
diff --git a/docs/cce/umn/en-us_image_0000001168997466.png b/docs/cce/umn/en-us_image_0000001168997466.png
new file mode 100644
index 00000000..8d3ac2a8
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001168997466.png differ
diff --git a/docs/cce/umn/en-us_image_0000001169315996.gif b/docs/cce/umn/en-us_image_0000001169315996.gif
new file mode 100644
index 00000000..3ced28eb
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001169315996.gif differ
diff --git a/docs/cce/umn/en-us_image_0000001169475948.png b/docs/cce/umn/en-us_image_0000001169475948.png
new file mode 100644
index 00000000..1a7c01e7
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001169475948.png differ
diff --git a/docs/cce/umn/en-us_image_0000001178352608.png b/docs/cce/umn/en-us_image_0000001178352608.png
deleted file mode 100644
index 505b8207..00000000
Binary files a/docs/cce/umn/en-us_image_0000001178352608.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0000001214475863.gif b/docs/cce/umn/en-us_image_0000001214475863.gif
new file mode 100644
index 00000000..7086a096
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001214475863.gif differ
diff --git a/docs/cce/umn/en-us_image_0000001214635805.png b/docs/cce/umn/en-us_image_0000001214635805.png
new file mode 100644
index 00000000..00ccbf1a
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001214635805.png differ
diff --git a/docs/cce/umn/en-us_image_0000001214717329.gif b/docs/cce/umn/en-us_image_0000001214717329.gif
new file mode 100644
index 00000000..c8fba921
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001214717329.gif differ
diff --git a/docs/cce/umn/en-us_image_0000001221820189.png b/docs/cce/umn/en-us_image_0000001221820189.png
deleted file mode 100644
index 2af028bd..00000000
Binary files a/docs/cce/umn/en-us_image_0000001221820189.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0000001244128658.png b/docs/cce/umn/en-us_image_0000001244128658.png
new file mode 100644
index 00000000..e456965b
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001244128658.png differ
diff --git a/docs/cce/umn/en-us_image_0000001287883210.png b/docs/cce/umn/en-us_image_0000001287883210.png
deleted file mode 100644
index 2b5990a2..00000000
Binary files a/docs/cce/umn/en-us_image_0000001287883210.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0000001336475537.png b/docs/cce/umn/en-us_image_0000001336475537.png
deleted file mode 100644
index 21a8c0aa..00000000
Binary files a/docs/cce/umn/en-us_image_0000001336475537.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0000001340138373.png b/docs/cce/umn/en-us_image_0000001340138373.png
deleted file mode 100644
index 3b8d9e34..00000000
Binary files a/docs/cce/umn/en-us_image_0000001340138373.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0000001352090724.png b/docs/cce/umn/en-us_image_0000001352090724.png
new file mode 100644
index 00000000..5333b491
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001352090724.png differ
diff --git a/docs/cce/umn/en-us_image_0000001352253356.png b/docs/cce/umn/en-us_image_0000001352253356.png
new file mode 100644
index 00000000..424c2262
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001352253356.png differ
diff --git a/docs/cce/umn/en-us_image_0000001352413288.png b/docs/cce/umn/en-us_image_0000001352413288.png
new file mode 100644
index 00000000..76689687
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001352413288.png differ
diff --git a/docs/cce/umn/en-us_image_0000001352573116.png b/docs/cce/umn/en-us_image_0000001352573116.png
new file mode 100644
index 00000000..bc44aa3f
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001352573116.png differ
diff --git a/docs/cce/umn/en-us_image_0000001402893085.png b/docs/cce/umn/en-us_image_0000001402893085.png
new file mode 100644
index 00000000..8133e723
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001402893085.png differ
diff --git a/docs/cce/umn/en-us_image_0000001403252957.png b/docs/cce/umn/en-us_image_0000001403252957.png
new file mode 100644
index 00000000..191dafd1
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001403252957.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499246158.png b/docs/cce/umn/en-us_image_0000001499246158.png
new file mode 100644
index 00000000..36d4cf8b
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499246158.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499406022.png b/docs/cce/umn/en-us_image_0000001499406022.png
new file mode 100644
index 00000000..49d22c1d
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499406022.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499406030.png b/docs/cce/umn/en-us_image_0000001499406030.png
new file mode 100644
index 00000000..c3b27f99
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499406030.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499565914.png b/docs/cce/umn/en-us_image_0000001499565914.png
new file mode 100644
index 00000000..ce0d9e1b
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499565914.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499565934.png b/docs/cce/umn/en-us_image_0000001499565934.png
new file mode 100644
index 00000000..3acce983
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499565934.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499598344.png b/docs/cce/umn/en-us_image_0000001499598344.png
new file mode 100644
index 00000000..1b65f721
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499598344.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499725850.png b/docs/cce/umn/en-us_image_0000001499725850.png
new file mode 100644
index 00000000..4b7cdafe
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499725850.png differ
diff --git a/docs/cce/umn/en-us_image_0000001499758236.png b/docs/cce/umn/en-us_image_0000001499758236.png
new file mode 100644
index 00000000..1b65f721
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499758236.png differ
diff --git a/docs/cce/umn/en-us_image_0000001244997085.png b/docs/cce/umn/en-us_image_0000001499758244.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244997085.png
rename to docs/cce/umn/en-us_image_0000001499758244.png
diff --git a/docs/cce/umn/en-us_image_0000001499760912.png b/docs/cce/umn/en-us_image_0000001499760912.png
new file mode 100644
index 00000000..7428f0ef
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001499760912.png differ
diff --git a/docs/cce/umn/en-us_image_0000001504661902.png b/docs/cce/umn/en-us_image_0000001504661902.png
new file mode 100644
index 00000000..f1ae6312
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001504661902.png differ
diff --git a/docs/cce/umn/en-us_image_0000001504821802.png b/docs/cce/umn/en-us_image_0000001504821802.png
new file mode 100644
index 00000000..4c012a58
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001504821802.png differ
diff --git a/docs/cce/umn/en-us_image_0000001244101121.png b/docs/cce/umn/en-us_image_0000001517743364.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244101121.png
rename to docs/cce/umn/en-us_image_0000001517743364.png
diff --git a/docs/cce/umn/en-us_image_0000001244141139.png b/docs/cce/umn/en-us_image_0000001517743372.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244141139.png
rename to docs/cce/umn/en-us_image_0000001517743372.png
diff --git a/docs/cce/umn/en-us_image_0000001199501230.png b/docs/cce/umn/en-us_image_0000001517743380.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199501230.png
rename to docs/cce/umn/en-us_image_0000001517743380.png
diff --git a/docs/cce/umn/en-us_image_0000001199501262.png b/docs/cce/umn/en-us_image_0000001517743384.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199501262.png
rename to docs/cce/umn/en-us_image_0000001517743384.png
diff --git a/docs/cce/umn/en-us_image_0258889981.png b/docs/cce/umn/en-us_image_0000001517743432.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258889981.png
rename to docs/cce/umn/en-us_image_0000001517743432.png
diff --git a/docs/cce/umn/en-us_image_0000001212924318.png b/docs/cce/umn/en-us_image_0000001517743452.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001212924318.png
rename to docs/cce/umn/en-us_image_0000001517743452.png
diff --git a/docs/cce/umn/en-us_image_0000001206959574.png b/docs/cce/umn/en-us_image_0000001517743456.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001206959574.png
rename to docs/cce/umn/en-us_image_0000001517743456.png
diff --git a/docs/cce/umn/en-us_image_0000001236562704.png b/docs/cce/umn/en-us_image_0000001517743460.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001236562704.png
rename to docs/cce/umn/en-us_image_0000001517743460.png
diff --git a/docs/cce/umn/en-us_image_0000001244261103.png b/docs/cce/umn/en-us_image_0000001517743464.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261103.png
rename to docs/cce/umn/en-us_image_0000001517743464.png
diff --git a/docs/cce/umn/en-us_image_0000001517743496.png b/docs/cce/umn/en-us_image_0000001517743496.png
new file mode 100644
index 00000000..8d6c69b3
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001517743496.png differ
diff --git a/docs/cce/umn/en-us_image_0000001243981203.png b/docs/cce/umn/en-us_image_0000001517743520.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981203.png
rename to docs/cce/umn/en-us_image_0000001517743520.png
diff --git a/docs/cce/umn/en-us_image_0000001249023453.png b/docs/cce/umn/en-us_image_0000001517743540.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001249023453.png
rename to docs/cce/umn/en-us_image_0000001517743540.png
diff --git a/docs/cce/umn/en-us_image_0000001244261073.png b/docs/cce/umn/en-us_image_0000001517743544.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261073.png
rename to docs/cce/umn/en-us_image_0000001517743544.png
diff --git a/docs/cce/umn/en-us_image_0000001199021334.png b/docs/cce/umn/en-us_image_0000001517743552.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199021334.png
rename to docs/cce/umn/en-us_image_0000001517743552.png
diff --git a/docs/cce/umn/en-us_image_0000001464878016.png b/docs/cce/umn/en-us_image_0000001517743600.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001464878016.png
rename to docs/cce/umn/en-us_image_0000001517743600.png
diff --git a/docs/cce/umn/en-us_image_0258894622.png b/docs/cce/umn/en-us_image_0000001517743624.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258894622.png
rename to docs/cce/umn/en-us_image_0000001517743624.png
diff --git a/docs/cce/umn/en-us_image_0258203193.png b/docs/cce/umn/en-us_image_0000001517743628.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258203193.png
rename to docs/cce/umn/en-us_image_0000001517743628.png
diff --git a/docs/cce/umn/en-us_image_0000001244261071.png b/docs/cce/umn/en-us_image_0000001517743636.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261071.png
rename to docs/cce/umn/en-us_image_0000001517743636.png
diff --git a/docs/cce/umn/en-us_image_0000001199341268.png b/docs/cce/umn/en-us_image_0000001517743644.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199341268.png
rename to docs/cce/umn/en-us_image_0000001517743644.png
diff --git a/docs/cce/umn/en-us_image_0275445543.png b/docs/cce/umn/en-us_image_0000001517743652.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0275445543.png
rename to docs/cce/umn/en-us_image_0000001517743652.png
diff --git a/docs/cce/umn/en-us_image_0000001531373685.png b/docs/cce/umn/en-us_image_0000001517743660.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001531373685.png
rename to docs/cce/umn/en-us_image_0000001517743660.png
diff --git a/docs/cce/umn/en-us_image_0000001244101223.png b/docs/cce/umn/en-us_image_0000001517743672.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244101223.png
rename to docs/cce/umn/en-us_image_0000001517743672.png
diff --git a/docs/cce/umn/en-us_image_0000001199021278.png b/docs/cce/umn/en-us_image_0000001517902940.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199021278.png
rename to docs/cce/umn/en-us_image_0000001517902940.png
diff --git a/docs/cce/umn/en-us_image_0258961458.png b/docs/cce/umn/en-us_image_0000001517903016.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258961458.png
rename to docs/cce/umn/en-us_image_0000001517903016.png
diff --git a/docs/cce/umn/en-us_image_0000001517903020.png b/docs/cce/umn/en-us_image_0000001517903020.png
new file mode 100644
index 00000000..68876838
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001517903020.png differ
diff --git a/docs/cce/umn/en-us_image_0000001408895746.png b/docs/cce/umn/en-us_image_0000001517903028.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001408895746.png
rename to docs/cce/umn/en-us_image_0000001517903028.png
diff --git a/docs/cce/umn/en-us_image_0000001517903036.png b/docs/cce/umn/en-us_image_0000001517903036.png
new file mode 100644
index 00000000..0bb483b2
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001517903036.png differ
diff --git a/docs/cce/umn/en-us_image_0000001199757520.png b/docs/cce/umn/en-us_image_0000001517903048.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199757520.png
rename to docs/cce/umn/en-us_image_0000001517903048.png
diff --git a/docs/cce/umn/en-us_image_0000001517903056.png b/docs/cce/umn/en-us_image_0000001517903056.png
new file mode 100644
index 00000000..c301af90
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001517903056.png differ
diff --git a/docs/cce/umn/en-us_image_0000001248663503.png b/docs/cce/umn/en-us_image_0000001517903060.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001248663503.png
rename to docs/cce/umn/en-us_image_0000001517903060.png
diff --git a/docs/cce/umn/en-us_image_0000001251716033.png b/docs/cce/umn/en-us_image_0000001517903064.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001251716033.png
rename to docs/cce/umn/en-us_image_0000001517903064.png
diff --git a/docs/cce/umn/en-us_image_0000001482546084.png b/docs/cce/umn/en-us_image_0000001517903068.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001482546084.png
rename to docs/cce/umn/en-us_image_0000001517903068.png
diff --git a/docs/cce/umn/en-us_image_0000001199501276.png b/docs/cce/umn/en-us_image_0000001517903088.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199501276.png
rename to docs/cce/umn/en-us_image_0000001517903088.png
diff --git a/docs/cce/umn/en-us_image_0000001249073211.png b/docs/cce/umn/en-us_image_0000001517903124.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001249073211.png
rename to docs/cce/umn/en-us_image_0000001517903124.png
diff --git a/docs/cce/umn/en-us_image_0000001517903128.png b/docs/cce/umn/en-us_image_0000001517903128.png
new file mode 100644
index 00000000..60b60d53
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001517903128.png differ
diff --git a/docs/cce/umn/en-us_image_0000001465197524.png b/docs/cce/umn/en-us_image_0000001517903168.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001465197524.png
rename to docs/cce/umn/en-us_image_0000001517903168.png
diff --git a/docs/cce/umn/en-us_image_0000001243981115.png b/docs/cce/umn/en-us_image_0000001517903200.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981115.png
rename to docs/cce/umn/en-us_image_0000001517903200.png
diff --git a/docs/cce/umn/en-us_image_0000001531533045.png b/docs/cce/umn/en-us_image_0000001517903240.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001531533045.png
rename to docs/cce/umn/en-us_image_0000001517903240.png
diff --git a/docs/cce/umn/en-us_image_0000001517903252.png b/docs/cce/umn/en-us_image_0000001517903252.png
new file mode 100644
index 00000000..2da6ba35
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001517903252.png differ
diff --git a/docs/cce/umn/en-us_image_0000001325364477.png b/docs/cce/umn/en-us_image_0000001518062492.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001325364477.png
rename to docs/cce/umn/en-us_image_0000001518062492.png
diff --git a/docs/cce/umn/en-us_image_0000001518062524.png b/docs/cce/umn/en-us_image_0000001518062524.png
new file mode 100644
index 00000000..65e1184f
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518062524.png differ
diff --git a/docs/cce/umn/en-us_image_0000001518062540.png b/docs/cce/umn/en-us_image_0000001518062540.png
new file mode 100644
index 00000000..4cff8a73
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518062540.png differ
diff --git a/docs/cce/umn/en-us_image_0000001207511384.png b/docs/cce/umn/en-us_image_0000001518062608.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001207511384.png
rename to docs/cce/umn/en-us_image_0000001518062608.png
diff --git a/docs/cce/umn/en-us_image_0000001203031716.png b/docs/cce/umn/en-us_image_0000001518062612.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001203031716.png
rename to docs/cce/umn/en-us_image_0000001518062612.png
diff --git a/docs/cce/umn/en-us_image_0000001518062624.png b/docs/cce/umn/en-us_image_0000001518062624.png
new file mode 100644
index 00000000..e970982c
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518062624.png differ
diff --git a/docs/cce/umn/en-us_image_0000001518062636.png b/docs/cce/umn/en-us_image_0000001518062636.png
new file mode 100644
index 00000000..33068815
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518062636.png differ
diff --git a/docs/cce/umn/en-us_image_0000001515838557.png b/docs/cce/umn/en-us_image_0000001518062644.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001515838557.png
rename to docs/cce/umn/en-us_image_0000001518062644.png
diff --git a/docs/cce/umn/en-us_image_0000001236723668.png b/docs/cce/umn/en-us_image_0000001518062664.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001236723668.png
rename to docs/cce/umn/en-us_image_0000001518062664.png
diff --git a/docs/cce/umn/en-us_image_0000001199181230.png b/docs/cce/umn/en-us_image_0000001518062672.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181230.png
rename to docs/cce/umn/en-us_image_0000001518062672.png
diff --git a/docs/cce/umn/en-us_image_0000001244101107.png b/docs/cce/umn/en-us_image_0000001518062684.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244101107.png
rename to docs/cce/umn/en-us_image_0000001518062684.png
diff --git a/docs/cce/umn/en-us_image_0000001244261119.png b/docs/cce/umn/en-us_image_0000001518062704.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261119.png
rename to docs/cce/umn/en-us_image_0000001518062704.png
diff --git a/docs/cce/umn/en-us_image_0000001518062756.png b/docs/cce/umn/en-us_image_0000001518062756.png
new file mode 100644
index 00000000..5bfbc6ca
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518062756.png differ
diff --git a/docs/cce/umn/en-us_image_0258871213.png b/docs/cce/umn/en-us_image_0000001518062772.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258871213.png
rename to docs/cce/umn/en-us_image_0000001518062772.png
diff --git a/docs/cce/umn/en-us_image_0261818893.png b/docs/cce/umn/en-us_image_0000001518062796.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0261818893.png
rename to docs/cce/umn/en-us_image_0000001518062796.png
diff --git a/docs/cce/umn/en-us_image_0000001531533921.png b/docs/cce/umn/en-us_image_0000001518062808.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001531533921.png
rename to docs/cce/umn/en-us_image_0000001518062808.png
diff --git a/docs/cce/umn/en-us_image_0000001238225460.png b/docs/cce/umn/en-us_image_0000001518062812.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001238225460.png
rename to docs/cce/umn/en-us_image_0000001518062812.png
diff --git a/docs/cce/umn/en-us_image_0000001402494682.png b/docs/cce/umn/en-us_image_0000001518062816.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001402494682.png
rename to docs/cce/umn/en-us_image_0000001518062816.png
diff --git a/docs/cce/umn/en-us_image_0000001518222492.png b/docs/cce/umn/en-us_image_0000001518222492.png
new file mode 100644
index 00000000..d09e52ed
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518222492.png differ
diff --git a/docs/cce/umn/en-us_image_0000001199181334.png b/docs/cce/umn/en-us_image_0000001518222536.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181334.png
rename to docs/cce/umn/en-us_image_0000001518222536.png
diff --git a/docs/cce/umn/en-us_image_0000001518222592.png b/docs/cce/umn/en-us_image_0000001518222592.png
new file mode 100644
index 00000000..f9d93b4e
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518222592.png differ
diff --git a/docs/cce/umn/en-us_image_0000001201381906.png b/docs/cce/umn/en-us_image_0000001518222604.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001201381906.png
rename to docs/cce/umn/en-us_image_0000001518222604.png
diff --git a/docs/cce/umn/en-us_image_0000001244141191.png b/docs/cce/umn/en-us_image_0000001518222608.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244141191.png
rename to docs/cce/umn/en-us_image_0000001518222608.png
diff --git a/docs/cce/umn/en-us_image_0000001205757902.png b/docs/cce/umn/en-us_image_0000001518222636.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001205757902.png
rename to docs/cce/umn/en-us_image_0000001518222636.png
diff --git a/docs/cce/umn/en-us_image_0000001518222700.png b/docs/cce/umn/en-us_image_0000001518222700.png
new file mode 100644
index 00000000..603c9468
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518222700.png differ
diff --git a/docs/cce/umn/en-us_image_0000001518222708.png b/docs/cce/umn/en-us_image_0000001518222708.png
new file mode 100644
index 00000000..226fcf76
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001518222708.png differ
diff --git a/docs/cce/umn/en-us_image_0258392378.png b/docs/cce/umn/en-us_image_0000001518222716.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258392378.png
rename to docs/cce/umn/en-us_image_0000001518222716.png
diff --git a/docs/cce/umn/en-us_image_0262051194.png b/docs/cce/umn/en-us_image_0000001518222732.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0262051194.png
rename to docs/cce/umn/en-us_image_0000001518222732.png
diff --git a/docs/cce/umn/en-us_image_0000001199341330.png b/docs/cce/umn/en-us_image_0000001518222740.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199341330.png
rename to docs/cce/umn/en-us_image_0000001518222740.png
diff --git a/docs/cce/umn/en-us_image_0000001520115845.png b/docs/cce/umn/en-us_image_0000001520115845.png
new file mode 100644
index 00000000..13582d7b
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001520115845.png differ
diff --git a/docs/cce/umn/en-us_image_0000001520396937.png b/docs/cce/umn/en-us_image_0000001520396937.png
new file mode 100644
index 00000000..48e6fbe5
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001520396937.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550125865.png b/docs/cce/umn/en-us_image_0000001550125865.png
new file mode 100644
index 00000000..dab58aa9
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550125865.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550125873.png b/docs/cce/umn/en-us_image_0000001550125873.png
new file mode 100644
index 00000000..086f270b
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550125873.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550245853.png b/docs/cce/umn/en-us_image_0000001550245853.png
new file mode 100644
index 00000000..0420d05a
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550245853.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550245869.png b/docs/cce/umn/en-us_image_0000001550245869.png
new file mode 100644
index 00000000..80fd8a48
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550245869.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550365685.png b/docs/cce/umn/en-us_image_0000001550365685.png
new file mode 100644
index 00000000..87c98e36
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550365685.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550365705.png b/docs/cce/umn/en-us_image_0000001550365705.png
new file mode 100644
index 00000000..821c26f4
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550365705.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550445737.png b/docs/cce/umn/en-us_image_0000001550445737.png
new file mode 100644
index 00000000..4d7de178
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550445737.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550558281.png b/docs/cce/umn/en-us_image_0000001550558281.png
new file mode 100644
index 00000000..7578b2a1
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550558281.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550558289.png b/docs/cce/umn/en-us_image_0000001550558289.png
new file mode 100644
index 00000000..c9086642
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550558289.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550678257.png b/docs/cce/umn/en-us_image_0000001550678257.png
new file mode 100644
index 00000000..89c31a80
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550678257.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550678265.png b/docs/cce/umn/en-us_image_0000001550678265.png
new file mode 100644
index 00000000..c483b45d
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550678265.png differ
diff --git a/docs/cce/umn/en-us_image_0000001550838141.png b/docs/cce/umn/en-us_image_0000001550838141.png
new file mode 100644
index 00000000..3153ed6c
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001550838141.png differ
diff --git a/docs/cce/umn/en-us_image_0000001199181228.png b/docs/cce/umn/en-us_image_0000001568822637.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181228.png
rename to docs/cce/umn/en-us_image_0000001568822637.png
diff --git a/docs/cce/umn/en-us_image_0000001243981177.png b/docs/cce/umn/en-us_image_0000001568822693.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981177.png
rename to docs/cce/umn/en-us_image_0000001568822693.png
diff --git a/docs/cce/umn/en-us_image_0000001201823500.png b/docs/cce/umn/en-us_image_0000001568822709.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001201823500.png
rename to docs/cce/umn/en-us_image_0000001568822709.png
diff --git a/docs/cce/umn/en-us_image_0000001199181336.png b/docs/cce/umn/en-us_image_0000001568822717.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181336.png
rename to docs/cce/umn/en-us_image_0000001568822717.png
diff --git a/docs/cce/umn/en-us_image_0000001199181340.png b/docs/cce/umn/en-us_image_0000001568822733.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181340.png
rename to docs/cce/umn/en-us_image_0000001568822733.png
diff --git a/docs/cce/umn/en-us_image_0000001244261169.png b/docs/cce/umn/en-us_image_0000001568822741.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261169.png
rename to docs/cce/umn/en-us_image_0000001568822741.png
diff --git a/docs/cce/umn/en-us_image_0000001199181338.png b/docs/cce/umn/en-us_image_0000001568822773.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181338.png
rename to docs/cce/umn/en-us_image_0000001568822773.png
diff --git a/docs/cce/umn/en-us_image_0000001533586881.png b/docs/cce/umn/en-us_image_0000001568822793.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001533586881.png
rename to docs/cce/umn/en-us_image_0000001568822793.png
diff --git a/docs/cce/umn/en-us_image_0000001244141105.png b/docs/cce/umn/en-us_image_0000001568822821.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244141105.png
rename to docs/cce/umn/en-us_image_0000001568822821.png
diff --git a/docs/cce/umn/en-us_image_0000001568822825.png b/docs/cce/umn/en-us_image_0000001568822825.png
new file mode 100644
index 00000000..d5254673
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568822825.png differ
diff --git a/docs/cce/umn/en-us_image_0267028603.png b/docs/cce/umn/en-us_image_0000001568822869.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0267028603.png
rename to docs/cce/umn/en-us_image_0000001568822869.png
diff --git a/docs/cce/umn/en-us_image_0000001244261167.png b/docs/cce/umn/en-us_image_0000001568822905.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261167.png
rename to docs/cce/umn/en-us_image_0000001568822905.png
diff --git a/docs/cce/umn/en-us_image_0000001515917789.png b/docs/cce/umn/en-us_image_0000001568822917.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001515917789.png
rename to docs/cce/umn/en-us_image_0000001568822917.png
diff --git a/docs/cce/umn/en-us_image_0000001199501200.png b/docs/cce/umn/en-us_image_0000001568822925.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199501200.png
rename to docs/cce/umn/en-us_image_0000001568822925.png
diff --git a/docs/cce/umn/en-us_image_0261818896.png b/docs/cce/umn/en-us_image_0000001568822957.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0261818896.png
rename to docs/cce/umn/en-us_image_0000001568822957.png
diff --git a/docs/cce/umn/en-us_image_0275445566.png b/docs/cce/umn/en-us_image_0000001568822961.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0275445566.png
rename to docs/cce/umn/en-us_image_0000001568822961.png
diff --git a/docs/cce/umn/en-us_image_0000001199021320.png b/docs/cce/umn/en-us_image_0000001568822965.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199021320.png
rename to docs/cce/umn/en-us_image_0000001568822965.png
diff --git a/docs/cce/umn/en-us_image_0000001378942548.png b/docs/cce/umn/en-us_image_0000001568902489.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001378942548.png
rename to docs/cce/umn/en-us_image_0000001568902489.png
diff --git a/docs/cce/umn/en-us_image_0000001568902509.png b/docs/cce/umn/en-us_image_0000001568902509.png
new file mode 100644
index 00000000..30a7eb21
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568902509.png differ
diff --git a/docs/cce/umn/en-us_image_0000001244261161.png b/docs/cce/umn/en-us_image_0000001568902521.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261161.png
rename to docs/cce/umn/en-us_image_0000001568902521.png
diff --git a/docs/cce/umn/en-us_image_0000001568902533.png b/docs/cce/umn/en-us_image_0000001568902533.png
new file mode 100644
index 00000000..b52a62db
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568902533.png differ
diff --git a/docs/cce/umn/en-us_image_0000001249958645.png b/docs/cce/umn/en-us_image_0000001568902541.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001249958645.png
rename to docs/cce/umn/en-us_image_0000001568902541.png
diff --git a/docs/cce/umn/en-us_image_0000001203385342.png b/docs/cce/umn/en-us_image_0000001568902557.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001203385342.png
rename to docs/cce/umn/en-us_image_0000001568902557.png
diff --git a/docs/cce/umn/en-us_image_0000001199021308.png b/docs/cce/umn/en-us_image_0000001568902577.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199021308.png
rename to docs/cce/umn/en-us_image_0000001568902577.png
diff --git a/docs/cce/umn/en-us_image_0000001568902601.png b/docs/cce/umn/en-us_image_0000001568902601.png
new file mode 100644
index 00000000..0e6fa614
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568902601.png differ
diff --git a/docs/cce/umn/en-us_image_0000001568902637.png b/docs/cce/umn/en-us_image_0000001568902637.png
new file mode 100644
index 00000000..ebc69763
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568902637.png differ
diff --git a/docs/cce/umn/en-us_image_0000001568902649.png b/docs/cce/umn/en-us_image_0000001568902649.png
new file mode 100644
index 00000000..ebc69763
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568902649.png differ
diff --git a/docs/cce/umn/en-us_image_0000001482796460.png b/docs/cce/umn/en-us_image_0000001568902653.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001482796460.png
rename to docs/cce/umn/en-us_image_0000001568902653.png
diff --git a/docs/cce/umn/en-us_image_0000001568902661.png b/docs/cce/umn/en-us_image_0000001568902661.png
new file mode 100644
index 00000000..47324ea0
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001568902661.png differ
diff --git a/docs/cce/umn/en-us_image_0000001202103502.png b/docs/cce/umn/en-us_image_0000001568902669.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001202103502.png
rename to docs/cce/umn/en-us_image_0000001568902669.png
diff --git a/docs/cce/umn/en-us_image_0261818899.png b/docs/cce/umn/en-us_image_0000001568902689.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0261818899.png
rename to docs/cce/umn/en-us_image_0000001568902689.png
diff --git a/docs/cce/umn/en-us_image_0000001243981141.png b/docs/cce/umn/en-us_image_0000001569022781.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981141.png
rename to docs/cce/umn/en-us_image_0000001569022781.png
diff --git a/docs/cce/umn/en-us_image_0000001243981147.png b/docs/cce/umn/en-us_image_0000001569022797.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981147.png
rename to docs/cce/umn/en-us_image_0000001569022797.png
diff --git a/docs/cce/umn/en-us_image_0000001244261055.png b/docs/cce/umn/en-us_image_0000001569022837.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261055.png
rename to docs/cce/umn/en-us_image_0000001569022837.png
diff --git a/docs/cce/umn/en-us_image_0000001202101148.png b/docs/cce/umn/en-us_image_0000001569022881.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001202101148.png
rename to docs/cce/umn/en-us_image_0000001569022881.png
diff --git a/docs/cce/umn/en-us_image_0000001244261173.png b/docs/cce/umn/en-us_image_0000001569022889.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261173.png
rename to docs/cce/umn/en-us_image_0000001569022889.png
diff --git a/docs/cce/umn/en-us_image_0000001569022901.png b/docs/cce/umn/en-us_image_0000001569022901.png
new file mode 100644
index 00000000..827836e1
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569022901.png differ
diff --git a/docs/cce/umn/en-us_image_0000001533585325.png b/docs/cce/umn/en-us_image_0000001569022905.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001533585325.png
rename to docs/cce/umn/en-us_image_0000001569022905.png
diff --git a/docs/cce/umn/en-us_image_0000001247802971.png b/docs/cce/umn/en-us_image_0000001569022913.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001247802971.png
rename to docs/cce/umn/en-us_image_0000001569022913.png
diff --git a/docs/cce/umn/en-us_image_0000001397733101.png b/docs/cce/umn/en-us_image_0000001569022929.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001397733101.png
rename to docs/cce/umn/en-us_image_0000001569022929.png
diff --git a/docs/cce/umn/en-us_image_0000001244261069.png b/docs/cce/umn/en-us_image_0000001569022933.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261069.png
rename to docs/cce/umn/en-us_image_0000001569022933.png
diff --git a/docs/cce/umn/en-us_image_0000001199181298.png b/docs/cce/umn/en-us_image_0000001569022957.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181298.png
rename to docs/cce/umn/en-us_image_0000001569022957.png
diff --git a/docs/cce/umn/en-us_image_0000001244141181.png b/docs/cce/umn/en-us_image_0000001569022961.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244141181.png
rename to docs/cce/umn/en-us_image_0000001569022961.png
diff --git a/docs/cce/umn/en-us_image_0000001276433425.png b/docs/cce/umn/en-us_image_0000001569022977.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001276433425.png
rename to docs/cce/umn/en-us_image_0000001569022977.png
diff --git a/docs/cce/umn/en-us_image_0000001569023013.png b/docs/cce/umn/en-us_image_0000001569023013.png
new file mode 100644
index 00000000..ebc69763
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569023013.png differ
diff --git a/docs/cce/umn/en-us_image_0000001569023025.png b/docs/cce/umn/en-us_image_0000001569023025.png
new file mode 100644
index 00000000..ebc69763
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569023025.png differ
diff --git a/docs/cce/umn/en-us_image_0000001569023029.png b/docs/cce/umn/en-us_image_0000001569023029.png
new file mode 100644
index 00000000..9b7e01f2
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569023029.png differ
diff --git a/docs/cce/umn/en-us_image_0258095884.png b/docs/cce/umn/en-us_image_0000001569023033.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0258095884.png
rename to docs/cce/umn/en-us_image_0000001569023033.png
diff --git a/docs/cce/umn/en-us_image_0000001243981117.png b/docs/cce/umn/en-us_image_0000001569023045.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981117.png
rename to docs/cce/umn/en-us_image_0000001569023045.png
diff --git a/docs/cce/umn/en-us_image_0275452681.png b/docs/cce/umn/en-us_image_0000001569023069.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0275452681.png
rename to docs/cce/umn/en-us_image_0000001569023069.png
diff --git a/docs/cce/umn/en-us_image_0000001569023085.png b/docs/cce/umn/en-us_image_0000001569023085.png
new file mode 100644
index 00000000..ff8087ba
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569023085.png differ
diff --git a/docs/cce/umn/en-us_image_0000001244141141.gif b/docs/cce/umn/en-us_image_0000001569182497.gif
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244141141.gif
rename to docs/cce/umn/en-us_image_0000001569182497.gif
diff --git a/docs/cce/umn/en-us_image_0000001199341250.png b/docs/cce/umn/en-us_image_0000001569182505.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199341250.png
rename to docs/cce/umn/en-us_image_0000001569182505.png
diff --git a/docs/cce/umn/en-us_image_0000001199021298.png b/docs/cce/umn/en-us_image_0000001569182513.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199021298.png
rename to docs/cce/umn/en-us_image_0000001569182513.png
diff --git a/docs/cce/umn/en-us_image_0000001244261171.png b/docs/cce/umn/en-us_image_0000001569182549.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244261171.png
rename to docs/cce/umn/en-us_image_0000001569182549.png
diff --git a/docs/cce/umn/en-us_image_0000001199501290.png b/docs/cce/umn/en-us_image_0000001569182553.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199501290.png
rename to docs/cce/umn/en-us_image_0000001569182553.png
diff --git a/docs/cce/umn/en-us_image_0000001256348238.jpg b/docs/cce/umn/en-us_image_0000001569182569.jpg
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001256348238.jpg
rename to docs/cce/umn/en-us_image_0000001569182569.jpg
diff --git a/docs/cce/umn/en-us_image_0000001225747980.png b/docs/cce/umn/en-us_image_0000001569182589.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001225747980.png
rename to docs/cce/umn/en-us_image_0000001569182589.png
diff --git a/docs/cce/umn/en-us_image_0000001199181266.png b/docs/cce/umn/en-us_image_0000001569182621.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181266.png
rename to docs/cce/umn/en-us_image_0000001569182621.png
diff --git a/docs/cce/umn/en-us_image_0000001569182625.png b/docs/cce/umn/en-us_image_0000001569182625.png
new file mode 100644
index 00000000..ebc69763
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569182625.png differ
diff --git a/docs/cce/umn/en-us_image_0000001199181232.png b/docs/cce/umn/en-us_image_0000001569182645.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001199181232.png
rename to docs/cce/umn/en-us_image_0000001569182645.png
diff --git a/docs/cce/umn/en-us_image_0000001414561076.png b/docs/cce/umn/en-us_image_0000001569182661.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001414561076.png
rename to docs/cce/umn/en-us_image_0000001569182661.png
diff --git a/docs/cce/umn/en-us_image_0000001206876656.png b/docs/cce/umn/en-us_image_0000001569182673.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001206876656.png
rename to docs/cce/umn/en-us_image_0000001569182673.png
diff --git a/docs/cce/umn/en-us_image_0000001243981181.png b/docs/cce/umn/en-us_image_0000001569182677.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001243981181.png
rename to docs/cce/umn/en-us_image_0000001569182677.png
diff --git a/docs/cce/umn/en-us_image_0000001569182741.png b/docs/cce/umn/en-us_image_0000001569182741.png
new file mode 100644
index 00000000..ca9934b1
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001569182741.png differ
diff --git a/docs/cce/umn/en-us_image_0000001244141217.png b/docs/cce/umn/en-us_image_0000001569182773.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001244141217.png
rename to docs/cce/umn/en-us_image_0000001569182773.png
diff --git a/docs/cce/umn/en-us_image_0000001192028618.png b/docs/cce/umn/en-us_image_0000001569182781.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001192028618.png
rename to docs/cce/umn/en-us_image_0000001569182781.png
diff --git a/docs/cce/umn/en-us_image_0000001578443828.png b/docs/cce/umn/en-us_image_0000001578443828.png
new file mode 100644
index 00000000..0819970d
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001578443828.png differ
diff --git a/docs/cce/umn/en-us_image_0000001579008782.png b/docs/cce/umn/en-us_image_0000001579008782.png
new file mode 100644
index 00000000..bbd7fce0
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001579008782.png differ
diff --git a/docs/cce/umn/en-us_image_0000001626725269.png b/docs/cce/umn/en-us_image_0000001626725269.png
new file mode 100644
index 00000000..6dd1e58d
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001626725269.png differ
diff --git a/docs/cce/umn/en-us_image_0000001628843805.png b/docs/cce/umn/en-us_image_0000001628843805.png
new file mode 100644
index 00000000..6bc88c9b
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001628843805.png differ
diff --git a/docs/cce/umn/en-us_image_0000001629186693.png b/docs/cce/umn/en-us_image_0000001629186693.png
new file mode 100644
index 00000000..59c35f26
Binary files /dev/null and b/docs/cce/umn/en-us_image_0000001629186693.png differ
diff --git a/docs/cce/umn/en-us_image_0000001528627005.png b/docs/cce/umn/en-us_image_0000001629926113.png
similarity index 100%
rename from docs/cce/umn/en-us_image_0000001528627005.png
rename to docs/cce/umn/en-us_image_0000001629926113.png
diff --git a/docs/cce/umn/en-us_image_0091280734.png b/docs/cce/umn/en-us_image_0091280734.png
new file mode 100644
index 00000000..9f288ee7
Binary files /dev/null and b/docs/cce/umn/en-us_image_0091280734.png differ
diff --git a/docs/cce/umn/en-us_image_0091292713.png b/docs/cce/umn/en-us_image_0091292713.png
new file mode 100644
index 00000000..e76121b0
Binary files /dev/null and b/docs/cce/umn/en-us_image_0091292713.png differ
diff --git a/docs/cce/umn/en-us_image_0166039537.png b/docs/cce/umn/en-us_image_0166039537.png
new file mode 100644
index 00000000..29757269
Binary files /dev/null and b/docs/cce/umn/en-us_image_0166039537.png differ
diff --git a/docs/cce/umn/en-us_image_0259557735.png b/docs/cce/umn/en-us_image_0259557735.png
deleted file mode 100644
index f8724134..00000000
Binary files a/docs/cce/umn/en-us_image_0259557735.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0259558489.png b/docs/cce/umn/en-us_image_0259558489.png
deleted file mode 100644
index b3c70325..00000000
Binary files a/docs/cce/umn/en-us_image_0259558489.png and /dev/null differ
diff --git a/docs/cce/umn/en-us_image_0261301557.png b/docs/cce/umn/en-us_image_0261301557.png
new file mode 100644
index 00000000..35845e12
Binary files /dev/null and b/docs/cce/umn/en-us_image_0261301557.png differ
diff --git a/docs/cce/umn/en-us_image_0264626618.png b/docs/cce/umn/en-us_image_0264626618.png
new file mode 100644
index 00000000..3aa8ffe4
Binary files /dev/null and b/docs/cce/umn/en-us_image_0264626618.png differ
diff --git a/docs/cce/umn/en-us_image_0271457115.png b/docs/cce/umn/en-us_image_0271457115.png
new file mode 100644
index 00000000..0385dfad
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271457115.png differ
diff --git a/docs/cce/umn/en-us_image_0271463079.png b/docs/cce/umn/en-us_image_0271463079.png
new file mode 100644
index 00000000..ed2fe21a
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271463079.png differ
diff --git a/docs/cce/umn/en-us_image_0271466158.png b/docs/cce/umn/en-us_image_0271466158.png
new file mode 100644
index 00000000..82576d0e
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271466158.png differ
diff --git a/docs/cce/umn/en-us_image_0271466198.png b/docs/cce/umn/en-us_image_0271466198.png
new file mode 100644
index 00000000..b5d2ca2d
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271466198.png differ
diff --git a/docs/cce/umn/en-us_image_0271466320.png b/docs/cce/umn/en-us_image_0271466320.png
new file mode 100644
index 00000000..d9b35cdd
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271466320.png differ
diff --git a/docs/cce/umn/en-us_image_0271466336.png b/docs/cce/umn/en-us_image_0271466336.png
new file mode 100644
index 00000000..a84cdae8
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271466336.png differ
diff --git a/docs/cce/umn/en-us_image_0271466402.png b/docs/cce/umn/en-us_image_0271466402.png
new file mode 100644
index 00000000..5ca5f9a0
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271466402.png differ
diff --git a/docs/cce/umn/en-us_image_0271466430.png b/docs/cce/umn/en-us_image_0271466430.png
new file mode 100644
index 00000000..88ea1be7
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271466430.png differ
diff --git a/docs/cce/umn/en-us_image_0271467350.png b/docs/cce/umn/en-us_image_0271467350.png
new file mode 100644
index 00000000..245b77a5
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271467350.png differ
diff --git a/docs/cce/umn/en-us_image_0271467469.png b/docs/cce/umn/en-us_image_0271467469.png
new file mode 100644
index 00000000..4d46baa0
Binary files /dev/null and b/docs/cce/umn/en-us_image_0271467469.png differ
diff --git a/docs/cce/umn/en-us_topic_0000001550437509.html b/docs/cce/umn/en-us_topic_0000001550437509.html
new file mode 100644
index 00000000..a49ae903
--- /dev/null
+++ b/docs/cce/umn/en-us_topic_0000001550437509.html
@@ -0,0 +1,27 @@
+
+
+
+  
                                                          Service Overview
                                                          
+
+  
                                                          
+
                                                          
+
+
+