diff --git a/docs/cce/umn/ALL_META.TXT.json b/docs/cce/umn/ALL_META.TXT.json index a55f31336..076f195d6 100644 --- a/docs/cce/umn/ALL_META.TXT.json +++ b/docs/cce/umn/ALL_META.TXT.json @@ -45,9 +45,9 @@ "node_id":"cce_productdesc_0003.xml", "product_code":"cce", "code":"3", - "des":"CCE is a container service developed on Docker and Kubernetes. It offers a wide range of features that allow you to run containers on a large scale. CCE containers are hi", + "des":"CCE is a container service developed on Docker and Kubernetes. It offers a wide range of features that allow you to run containers in large clusters. CCE containers are h", "doc_type":"usermanual2", - "kw":"Product Advantages,Service Overview,User Guide", + "kw":"Docker,CCE Advantages,Service Overview,User Guide", "search_title":"", "metedata":[ { @@ -55,7 +55,7 @@ "documenttype":"usermanual" } ], - "title":"Product Advantages", + "title":"CCE Advantages", "githuburl":"" }, { @@ -135,9 +135,9 @@ "node_id":"cce_productdesc_0018.xml", "product_code":"cce", "code":"8", - "des":"Multi-cloud deployment and disaster recoveryTo ensure high service availability, services need to be deployed on container services of multiple clouds. When a cloud is fa", + "des":"Multi-cloud deployment, DR, and backupTo ensure high service availability, services need to be deployed on container services of multiple clouds. When a cloud is faulty, ", "doc_type":"usermanual2", - "kw":"Hybrid Cloud,Application Scenarios,User Guide", + "kw":"Hybrid Clouds,Application Scenarios,User Guide", "search_title":"", "metedata":[ { @@ -145,7 +145,7 @@ "documenttype":"usermanual" } ], - "title":"Hybrid Cloud", + "title":"Hybrid Clouds", "githuburl":"" }, { @@ -191,7 +191,7 @@ "code":"11", "des":"CCE needs to be interconnected with the following cloud services. It requires permissions to access these cloud services.", "doc_type":"usermanual2", - "kw":"ECS,VPC,ELB,SWR,EVS,OBS,cloud storage for data of any size,SFS,AOM,Related Services,Service Overview", + "kw":"VPC,ELB,SWR,EVS,OBS,cloud storage for data of any size,SFS,AOM,Related Services,Service Overview,Use", "search_title":"", "metedata":[ { @@ -608,11 +608,29 @@ "title":"Kubernetes Version Release Notes", "githuburl":"" }, + { + "uri":"cce_bulletin_0104.html", + "node_id":"cce_bulletin_0104.xml", + "product_code":"cce", + "code":"34", + "des":"CCE allows you to create Kubernetes 1.32 clusters. This section describes the changes made in Kubernetes 1.32.New and Enhanced FeaturesAPI Changes and RemovalsEnhanced Ku", + "doc_type":"usermanual2", + "kw":"Kubernetes 1.32 Release Notes,Kubernetes Version Release Notes,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Kubernetes 1.32 Release Notes", + "githuburl":"" + }, { "uri":"cce_bulletin_0099.html", "node_id":"cce_bulletin_0099.xml", "product_code":"cce", - "code":"34", + "code":"35", "des":"CCE allows you to create Kubernetes 1.31 clusters. This section describes the changes made in Kubernetes 1.31.New and Enhanced FeaturesAPI Changes and RemovalsEnhanced Ku", "doc_type":"usermanual2", "kw":"Kubernetes 1.31 Release Notes,Kubernetes Version Release Notes,User Guide", @@ -630,7 +648,7 @@ "uri":"cce_bulletin_0095.html", "node_id":"cce_bulletin_0095.xml", "product_code":"cce", - "code":"35", + "code":"36", "des":"CCE allows you to create Kubernetes 1.30 clusters. This section describes the changes made in Kubernetes 1.30.New and Enhanced FeaturesAPI Changes and RemovalsEnhanced Ku", "doc_type":"usermanual2", "kw":"Kubernetes 1.30 Release Notes,Kubernetes Version Release Notes,User Guide", @@ -648,7 +666,7 @@ "uri":"cce_bulletin_0089.html", "node_id":"cce_bulletin_0089.xml", "product_code":"cce", - "code":"36", + "code":"37", "des":"CCE allows you to create Kubernetes 1.29 clusters. This section describes the changes made in Kubernetes 1.29.New and Enhanced FeaturesAPI Changes and RemovalsIncompatibl", "doc_type":"usermanual2", "kw":"Kubernetes 1.29 Release Notes,Kubernetes Version Release Notes,User Guide", @@ -666,7 +684,7 @@ "uri":"cce_bulletin_0068.html", "node_id":"cce_bulletin_0068.xml", "product_code":"cce", - "code":"37", + "code":"38", "des":"CCE allows you to create Kubernetes 1.28 clusters. This section describes the changes made in Kubernetes 1.28.Important NotesNew and Enhanced FeaturesAPI Changes and Remo", "doc_type":"usermanual2", "kw":"Kubernetes 1.28 Release Notes,Kubernetes Version Release Notes,User Guide", @@ -684,7 +702,7 @@ "uri":"cce_bulletin_0059.html", "node_id":"cce_bulletin_0059.xml", "product_code":"cce", - "code":"38", + "code":"39", "des":"CCE allows you to create Kubernetes 1.27 clusters. This section describes the changes made in Kubernetes 1.27 compared with Kubernetes 1.25.New FeaturesDeprecations and R", "doc_type":"usermanual2", "kw":"Kubernetes 1.27 Release Notes,Kubernetes Version Release Notes,User Guide", @@ -702,10 +720,10 @@ "uri":"cce_bulletin_0058.html", "node_id":"cce_bulletin_0058.xml", "product_code":"cce", - "code":"39", + "code":"40", "des":"This section describes the changes made in Kubernetes 1.25 compared with Kubernetes 1.23.New FeaturesDeprecations and RemovalsEnhanced Kubernetes 1.25 on CCEReferencesKub", "doc_type":"usermanual2", - "kw":"Kubernetes 1.25 (EOM) Release Notes,Kubernetes Version Release Notes,User Guide", + "kw":"Kubernetes 1.25 Release Notes,Kubernetes Version Release Notes,User Guide", "search_title":"", "metedata":[ { @@ -713,14 +731,14 @@ "documenttype":"usermanual" } ], - "title":"Kubernetes 1.25 (EOM) Release Notes", + "title":"Kubernetes 1.25 Release Notes", "githuburl":"" }, { "uri":"cce_bulletin_0027.html", "node_id":"cce_bulletin_0027.xml", "product_code":"cce", - "code":"40", + "code":"41", "des":"This section describes the updates in CCE Kubernetes 1.23.Kubernetes v1.23 Release NotesFlexVolume is deprecated. Use CSI.HorizontalPodAutoscaler v2 is promoted to GA, an", "doc_type":"usermanual2", "kw":"Kubernetes 1.23 (EOM) Release Notes,Kubernetes Version Release Notes,User Guide", @@ -738,7 +756,7 @@ "uri":"cce_bulletin_0026.html", "node_id":"cce_bulletin_0026.xml", "product_code":"cce", - "code":"41", + "code":"42", "des":"This section describes the updates in CCE Kubernetes 1.21.Kubernetes v1.21 Release NotesCronJob is now in the stable state, and the version number changes to batch/v1.The", "doc_type":"usermanual2", "kw":"Kubernetes 1.21 (EOM) Release Notes,Kubernetes Version Release Notes,User Guide", @@ -756,7 +774,7 @@ "uri":"cce_whsnew_0010.html", "node_id":"cce_whsnew_0010.xml", "product_code":"cce", - "code":"42", + "code":"43", "des":"This section describes the updates in CCE Kubernetes 1.19.Kubernetes v1.19 Release NotesvSphere in-tree volumes can be migrated to vSphere CSI drivers. The in-tree vSpher", "doc_type":"usermanual2", "kw":"Kubernetes 1.19 (EOM) Release Notes,Kubernetes Version Release Notes,User Guide", @@ -774,7 +792,7 @@ "uri":"cce_whsnew_0007.html", "node_id":"cce_whsnew_0007.xml", "product_code":"cce", - "code":"43", + "code":"44", "des":"This section describes the updates in CCE Kubernetes 1.17.All resources in the apps/v1beta1 and apps/v1beta2 API versions are no longer served. Migrate to use the apps/v1", "doc_type":"usermanual2", "kw":"Kubernetes 1.17 (EOM) Release Notes,Kubernetes Version Release Notes,User Guide", @@ -792,7 +810,7 @@ "uri":"cce_10_0405.html", "node_id":"cce_10_0405.xml", "product_code":"cce", - "code":"44", + "code":"45", "des":"In CCE clusters of v1.25, containerd is the default runtime for nodes, except for nodes running EulerOS 2.5. In addition, clusters of v1.25 or later no longer support Eul", "doc_type":"usermanual2", "kw":"Patch Version Release Notes,Cluster Version Release Notes,User Guide", @@ -810,7 +828,7 @@ "uri":"cce_10_0298.html", "node_id":"cce_10_0298.xml", "product_code":"cce", - "code":"45", + "code":"46", "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":"Creating a Cluster", @@ -828,7 +846,7 @@ "uri":"cce_10_0342.html", "node_id":"cce_10_0342.xml", "product_code":"cce", - "code":"46", + "code":"47", "des":"CCE provides different types of clusters for you to select. The following table lists the differences between them.", "doc_type":"usermanual2", "kw":"Comparison Between Cluster Types,Creating a Cluster,User Guide", @@ -846,8 +864,8 @@ "uri":"cce_10_0028.html", "node_id":"cce_10_0028.xml", "product_code":"cce", - "code":"47", - "des":"On the CCE console, you can easily create Kubernetes clusters. After a cluster is created, the master node is hosted by CCE. You only need to create worker nodes. In this", + "code":"48", + "des":"CCE standard and Turbo clusters provide enterprise-class Kubernetes cluster hosting service that supports full lifecycle management of containerized applications. They of", "doc_type":"usermanual2", "kw":"Creating a CCE Standard/Turbo Cluster,Creating a Cluster,User Guide", "search_title":"", @@ -864,7 +882,7 @@ "uri":"cce_10_0349.html", "node_id":"cce_10_0349.xml", "product_code":"cce", - "code":"48", + "code":"49", "des":"kube-proxy is a key component of a Kubernetes cluster. It is used for load balancing and forwarding data between a Service and its backend pods.CCE supports the iptables ", "doc_type":"usermanual2", "kw":"kube-proxy,iptables,IP Virtual Server (IPVS),forwarding modes,Comparing iptables and IPVS,Creating a", @@ -882,10 +900,10 @@ "uri":"cce_10_0140.html", "node_id":"cce_10_0140.xml", "product_code":"cce", - "code":"49", + "code":"50", "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":"Connecting to a Cluster", + "kw":"Accessing a Cluster", "search_title":"", "metedata":[ { @@ -893,17 +911,35 @@ "documenttype":"usermanual" } ], - "title":"Connecting to a Cluster", + "title":"Accessing a Cluster", + "githuburl":"" + }, + { + "uri":"cce_10_0961.html", + "node_id":"cce_10_0961.xml", + "product_code":"cce", + "code":"51", + "des":"Accessing a cluster involves establishing communication with it and executing cluster management tasks. A CCE cluster is a distributed system consisting of multiple nodes", + "doc_type":"usermanual2", + "kw":"Cluster Access Overview,Accessing a Cluster,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Cluster Access Overview", "githuburl":"" }, { "uri":"cce_10_0107.html", "node_id":"cce_10_0107.xml", "product_code":"cce", - "code":"50", + "code":"52", "des":"kubectl is a command-line tool provided by Kubernetes, enabling you to manage cluster resources, view cluster status, deploy applications, and debug issues through the CL", "doc_type":"usermanual2", - "kw":"Intranet access,Internet access,kubectl,intranet access,Internet access,Two-Way Authentication for D", + "kw":"Intranet access,Internet access,kubectl,intranet access,Internet access,Two-Way Domain Name Trust,Er", "search_title":"", "metedata":[ { @@ -918,10 +954,10 @@ "uri":"cce_10_0175.html", "node_id":"cce_10_0175.xml", "product_code":"cce", - "code":"51", + "code":"53", "des":"X.509 certificates are essential for verifying identities and encrypting communication within CCE clusters. These certificates enable authorized clients to access target ", "doc_type":"usermanual2", - "kw":"X.509 certificate,Accessing a Cluster Using an X.509 Certificate,Connecting to a Cluster,User Guide", + "kw":"X.509 certificate,Accessing a Cluster Using an X.509 Certificate,Accessing a Cluster,User Guide", "search_title":"", "metedata":[ { @@ -936,10 +972,10 @@ "uri":"cce_10_0367.html", "node_id":"cce_10_0367.xml", "product_code":"cce", - "code":"52", + "code":"54", "des":"Subject Alternative Name (SAN) enables certificates to be associated with multiple values, including IP addresses and domain names. A SAN is usually used by the client to", "doc_type":"usermanual2", - "kw":"SAN,X.509 certificate,Accessing a Cluster Using a Custom Domain Name,Connecting to a Cluster,User Gu", + "kw":"SAN,X.509 certificate,Accessing a Cluster Using a Custom Domain Name,Accessing a Cluster,User Guide", "search_title":"", "metedata":[ { @@ -954,10 +990,10 @@ "uri":"cce_10_0864.html", "node_id":"cce_10_0864.xml", "product_code":"cce", - "code":"53", + "code":"55", "des":"You can bind an EIP to an API server of a Kubernetes cluster so that the API server can access the Internet.Binding an EIP to an API server for Internet access can pose a", "doc_type":"usermanual2", - "kw":"Configuring a Cluster's API Server for Internet Access,Connecting to a Cluster,User Guide", + "kw":"Configuring a Cluster's API Server for Internet Access,Accessing a Cluster,User Guide", "search_title":"", "metedata":[ { @@ -972,10 +1008,10 @@ "uri":"cce_10_0744.html", "node_id":"cce_10_0744.xml", "product_code":"cce", - "code":"54", + "code":"56", "des":"In multi-tenant scenarios, CCE generates a unique credential (such as a kubeconfig file or an X.509 certificate) for each user to access their designated cluster. These c", "doc_type":"usermanual2", - "kw":"Revoking a Cluster Access Credential,Connecting to a Cluster,User Guide", + "kw":"Revoking a Cluster Access Credential,Accessing a Cluster,User Guide", "search_title":"", "metedata":[ { @@ -990,10 +1026,10 @@ "uri":"cce_10_0031.html", "node_id":"cce_10_0031.xml", "product_code":"cce", - "code":"55", + "code":"57", "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", + "kw":"Managing Clusters", "search_title":"", "metedata":[ { @@ -1001,17 +1037,35 @@ "documenttype":"usermanual" } ], - "title":"Managing a Cluster", + "title":"Managing Clusters", + "githuburl":"" + }, + { + "uri":"cce_10_0962.html", + "node_id":"cce_10_0962.xml", + "product_code":"cce", + "code":"58", + "des":"Efficient, stable operation of containerized applications relies on proper management of CCE standard or Turbo clusters. CCE standard and Turbo clusters offer comprehensi", + "doc_type":"usermanual2", + "kw":"Cluster configuration parameters,change,Cluster Management Overview,Managing Clusters,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Cluster Management Overview", "githuburl":"" }, { "uri":"cce_10_0213.html", "node_id":"cce_10_0213.xml", "product_code":"cce", - "code":"56", + "code":"59", "des":"Cluster configuration parameters are underlying rules that define node behavior, resource allocation, communication rules, and scaling policies in a distributed system. T", "doc_type":"usermanual2", - "kw":"Cluster configuration parameters,cluster configuration parameters,Cluster configuration parameters,C", + "kw":"Cluster configuration parameters,cluster configuration parameters,Cluster configuration parameters,k", "search_title":"", "metedata":[ { @@ -1026,10 +1080,10 @@ "uri":"cce_10_0602.html", "node_id":"cce_10_0602.xml", "product_code":"cce", - "code":"57", + "code":"60", "des":"Cluster overload occurs when system load such as request volume or resource usage exceeds the system's processing capacity, leading to degraded performance or system fail", "doc_type":"usermanual2", - "kw":"Enabling Overload Control for a Cluster,Managing a Cluster,User Guide", + "kw":"Enabling Overload Control for a Cluster,Managing Clusters,User Guide", "search_title":"", "metedata":[ { @@ -1044,10 +1098,10 @@ "uri":"cce_10_0403.html", "node_id":"cce_10_0403.xml", "product_code":"cce", - "code":"58", + "code":"61", "des":"A cluster scale specifies the maximum number of nodes a cluster can manage. If the current cluster scale cannot meet your requirements, you can scale it out.A cluster tha", "doc_type":"usermanual2", - "kw":"scale it out,Changing a Cluster Scale,Managing a Cluster,User Guide", + "kw":"scale it out,Changing a Cluster Scale,Managing Clusters,User Guide", "search_title":"", "metedata":[ { @@ -1062,10 +1116,10 @@ "uri":"cce_10_0426.html", "node_id":"cce_10_0426.xml", "product_code":"cce", - "code":"59", + "code":"62", "des":"When creating a cluster, you can customize a node security group to centrally manage network security policies. For a created cluster, you can change its default node sec", "doc_type":"usermanual2", - "kw":"Changing the Default Security Group of a Node,Managing a Cluster,User Guide", + "kw":"Changing the Default Security Group of a Node,Managing Clusters,User Guide", "search_title":"", "metedata":[ { @@ -1080,10 +1134,10 @@ "uri":"cce_10_0212.html", "node_id":"cce_10_0212.xml", "product_code":"cce", - "code":"60", + "code":"63", "des":"Deleting a cluster will delete the workloads and Services in the cluster, and the deleted data cannot be recovered. Before performing this operation, ensure that related ", "doc_type":"usermanual2", - "kw":"Deleting a Cluster,Managing a Cluster,User Guide", + "kw":"Deleting a Cluster,Managing Clusters,User Guide", "search_title":"", "metedata":[ { @@ -1098,10 +1152,10 @@ "uri":"cce_10_0927.html", "node_id":"cce_10_0927.xml", "product_code":"cce", - "code":"61", + "code":"64", "des":"Unexpected deletion of clusters can occur in practice, especially when multiple users share an account and accidentally delete clusters that do not belong to them. To pre", "doc_type":"usermanual2", - "kw":"Preventing Cluster Deletion,Managing a Cluster,User Guide", + "kw":"Preventing Cluster Deletion,Managing Clusters,User Guide", "search_title":"", "metedata":[ { @@ -1116,10 +1170,10 @@ "uri":"cce_10_0214.html", "node_id":"cce_10_0214.xml", "product_code":"cce", - "code":"62", + "code":"65", "des":"If a cluster is not needed temporarily, hibernate it to reduce costs.After a cluster is hibernated, resources such as workloads cannot be created or managed in the cluste", "doc_type":"usermanual2", - "kw":"Hibernating or Waking Up a Cluster,Managing a Cluster,User Guide", + "kw":"Hibernating or Waking Up a Cluster,Managing Clusters,User Guide", "search_title":"", "metedata":[ { @@ -1134,7 +1188,7 @@ "uri":"cce_10_0215.html", "node_id":"cce_10_0215.xml", "product_code":"cce", - "code":"63", + "code":"66", "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", @@ -1152,7 +1206,7 @@ "uri":"cce_10_0197.html", "node_id":"cce_10_0197.xml", "product_code":"cce", - "code":"64", + "code":"67", "des":"CCE strictly complies with community consistency authentication. It releases three Kubernetes versions each year and offers a maintenance period of at least 24 months aft", "doc_type":"usermanual2", "kw":"cluster upgrade process,Node Priority,In-place upgrade,Cluster Upgrade Overview,Upgrading a Cluster,", @@ -1170,7 +1224,7 @@ "uri":"cce_10_0302.html", "node_id":"cce_10_0302.xml", "product_code":"cce", - "code":"65", + "code":"68", "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 Cluster Upgrade Overview.Befo", "doc_type":"usermanual2", "kw":"Deprecated APIs,Before You Start,Upgrading a Cluster,User Guide", @@ -1188,7 +1242,7 @@ "uri":"cce_10_0560.html", "node_id":"cce_10_0560.xml", "product_code":"cce", - "code":"66", + "code":"69", "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":"Performing Post-Upgrade Verification", @@ -1206,7 +1260,7 @@ "uri":"cce_10_0568.html", "node_id":"cce_10_0568.xml", "product_code":"cce", - "code":"67", + "code":"70", "des":"After a cluster is upgraded, check whether the cluster is in the Running state.CCE automatically checks your cluster status. Go to the cluster list page and confirm the c", "doc_type":"usermanual2", "kw":"Cluster Status Check,Performing Post-Upgrade Verification,User Guide", @@ -1224,7 +1278,7 @@ "uri":"cce_10_0569.html", "node_id":"cce_10_0569.xml", "product_code":"cce", - "code":"68", + "code":"71", "des":"After a cluster is upgraded, check whether nodes in the cluster are in the Running state.CCE automatically checks your node statuses. Go to the node list page and confirm", "doc_type":"usermanual2", "kw":"Node Status Check,Performing Post-Upgrade Verification,User Guide", @@ -1242,7 +1296,7 @@ "uri":"cce_10_0567.html", "node_id":"cce_10_0567.xml", "product_code":"cce", - "code":"69", + "code":"72", "des":"After a cluster is upgraded, check whether there are any nodes that skip the upgrade in the cluster. These nodes may affect the proper running of the cluster.CCE automati", "doc_type":"usermanual2", "kw":"Node Skipping Check,Performing Post-Upgrade Verification,User Guide", @@ -1260,7 +1314,7 @@ "uri":"cce_10_0561.html", "node_id":"cce_10_0561.xml", "product_code":"cce", - "code":"70", + "code":"73", "des":"After a cluster is upgraded, check whether its services are running properly.Different services have different verification mode. Select a suitable one and verify the ser", "doc_type":"usermanual2", "kw":"Service Check,Performing Post-Upgrade Verification,User Guide", @@ -1278,7 +1332,7 @@ "uri":"cce_10_0565.html", "node_id":"cce_10_0565.xml", "product_code":"cce", - "code":"71", + "code":"74", "des":"Check whether nodes can be created in the cluster.If nodes cannot be created in your cluster after the cluster is upgraded, contact technical support.", "doc_type":"usermanual2", "kw":"New Node Check,Performing Post-Upgrade Verification,User Guide", @@ -1296,7 +1350,7 @@ "uri":"cce_10_0566.html", "node_id":"cce_10_0566.xml", "product_code":"cce", - "code":"72", + "code":"75", "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,Performing Post-Upgrade Verification,User Guide", @@ -1314,7 +1368,7 @@ "uri":"cce_10_0210.html", "node_id":"cce_10_0210.xml", "product_code":"cce", - "code":"73", + "code":"76", "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", @@ -1332,7 +1386,7 @@ "uri":"cce_10_0550.html", "node_id":"cce_10_0550.xml", "product_code":"cce", - "code":"74", + "code":"77", "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", @@ -1350,7 +1404,7 @@ "uri":"cce_10_0549.html", "node_id":"cce_10_0549.xml", "product_code":"cce", - "code":"75", + "code":"78", "des":"The system automatically checks a cluster before its upgrade. If the cluster does not meet the pre-upgrade check conditions, the upgrade cannot continue. To avoid risks, ", "doc_type":"usermanual2", "kw":"Pre-upgrade Check,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1368,7 +1422,7 @@ "uri":"cce_10_0431.html", "node_id":"cce_10_0431.xml", "product_code":"cce", - "code":"76", + "code":"79", "des":"Check the following items:Check whether the node is available.Check whether the node OS supports the upgrade.Check whether the node is marked with unexpected node pool la", "doc_type":"usermanual2", "kw":"Node Restrictions,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1386,7 +1440,7 @@ "uri":"cce_10_0432.html", "node_id":"cce_10_0432.xml", "product_code":"cce", - "code":"77", + "code":"80", "des":"Check whether the target cluster is under upgrade management.CCE may temporarily restrict the cluster upgrade due to the following reasons:The cluster is identified as th", "doc_type":"usermanual2", "kw":"Upgrade Management,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1404,7 +1458,7 @@ "uri":"cce_10_0433.html", "node_id":"cce_10_0433.xml", "product_code":"cce", - "code":"78", + "code":"81", "des":"Check the following items:Check whether the add-on status is normal.Check whether the add-on supports the target version.Scenario 1: The add-on malfunctions.Log in to the", "doc_type":"usermanual2", "kw":"Add-ons,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1422,7 +1476,7 @@ "uri":"cce_10_0434.html", "node_id":"cce_10_0434.xml", "product_code":"cce", - "code":"79", + "code":"82", "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":"Helm Charts,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1440,7 +1494,7 @@ "uri":"cce_10_0435.html", "node_id":"cce_10_0435.xml", "product_code":"cce", - "code":"80", + "code":"83", "des":"Check whether your master nodes can be accessed using SSH.There is a low probability that the SSH connectivity check fails due to network fluctuations. Perform the pre-up", "doc_type":"usermanual2", "kw":"SSH Connectivity of Master Nodes,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1458,7 +1512,7 @@ "uri":"cce_10_0436.html", "node_id":"cce_10_0436.xml", "product_code":"cce", - "code":"81", + "code":"84", "des":"Check the node pool status.Check whether the node pool OS or container runtime is supported after the upgrade.Scenario: The node pool malfunctions.Log in to the CCE conso", "doc_type":"usermanual2", "kw":"Node Pools,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1476,7 +1530,7 @@ "uri":"cce_10_0437.html", "node_id":"cce_10_0437.xml", "product_code":"cce", - "code":"82", + "code":"85", "des":"Check whether the Protocol & Port of the worker node security groups is set to ICMP: All and whether the security group rule with the source IP address set to the master ", "doc_type":"usermanual2", "kw":"Security Groups,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1494,7 +1548,7 @@ "uri":"cce_10_0439.html", "node_id":"cce_10_0439.xml", "product_code":"cce", - "code":"83", + "code":"86", "des":"Check whether nodes need to be migrated.This issue is caused by either an error in the node's package pull component or the absence of key system components on the node, ", "doc_type":"usermanual2", "kw":"Residual Nodes,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1512,8 +1566,8 @@ "uri":"cce_10_0440.html", "node_id":"cce_10_0440.xml", "product_code":"cce", - "code":"84", - "des":"Check whether there are discarded resources in the clusters.Scenario 1: The Service in the clusters of v1.25 or later has discarded annotation tolerate-unready-endpoints.", + "code":"87", + "des":"Check whether there are discarded resources in the clusters.Scenario 1: The Service in the clusters of v1.25 or later has deprecated annotation tolerate-unready-endpoints", "doc_type":"usermanual2", "kw":"Discarded Kubernetes Resources,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -1530,7 +1584,7 @@ "uri":"cce_10_0441.html", "node_id":"cce_10_0441.xml", "product_code":"cce", - "code":"85", + "code":"88", "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 Risks,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1548,7 +1602,7 @@ "uri":"cce_10_0442.html", "node_id":"cce_10_0442.xml", "product_code":"cce", - "code":"86", + "code":"89", "des":"Check whether cce-agent on the current node is of the latest version.Scenario 1: The error message \"you cce-agent no update, please restart it\" is displayed.This issue oc", "doc_type":"usermanual2", "kw":"CCE Agent Versions,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1566,7 +1620,7 @@ "uri":"cce_10_0443.html", "node_id":"cce_10_0443.xml", "product_code":"cce", - "code":"87", + "code":"90", "des":"Check whether the node's CPU usage is above 90%.Upgrade the cluster during off-peak hours.Check whether too many pods are deployed on the node. If yes, reschedule pods to", "doc_type":"usermanual2", "kw":"Node CPU Usage,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1584,7 +1638,7 @@ "uri":"cce_10_0444.html", "node_id":"cce_10_0444.xml", "product_code":"cce", - "code":"88", + "code":"91", "des":"Check the following items:Check whether the key CRD packageversions.version.cce.io of the cluster is deleted.Check whether the cluster key CRD network-attachment-definiti", "doc_type":"usermanual2", "kw":"CRDs,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1602,8 +1656,8 @@ "uri":"cce_10_0445.html", "node_id":"cce_10_0445.xml", "product_code":"cce", - "code":"89", - "des":"Check the following items:Check whether the key data disks on the node meet the upgrade requirements.Check whether the /tmp directory has 500 MB available space.During th", + "code":"92", + "des":"Check the following items:Check whether the key data disks on the node meet the upgrade requirements.Check whether the /tmp directory has 500 MB of available space.During", "doc_type":"usermanual2", "kw":"Node Disks,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -1620,7 +1674,7 @@ "uri":"cce_10_0446.html", "node_id":"cce_10_0446.xml", "product_code":"cce", - "code":"90", + "code":"93", "des":"Check the following items: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", "doc_type":"usermanual2", "kw":"Node DNS,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1638,8 +1692,8 @@ "uri":"cce_10_0447.html", "node_id":"cce_10_0447.xml", "product_code":"cce", - "code":"91", - "des":"Check whether the owner and owner group of the files in the /var/paas directory used by the CCE are both paas.Scenario 1: The error message \"xx file permission has been c", + "code":"94", + "des":"Check whether the root directory permissions are properly assigned.Scenario 1: The error message \"user paas must have at least read and execute permissions on the root di", "doc_type":"usermanual2", "kw":"Node Key Directory File Permissions,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -1656,8 +1710,8 @@ "uri":"cce_10_0448.html", "node_id":"cce_10_0448.xml", "product_code":"cce", - "code":"92", - "des":"Check whether the kubelet on the node is running properly.Scenario 1: The kubelet status is abnormal.If the kubelet malfunctions, the node will be unavailable. Restore th", + "code":"95", + "des":"Check whether the kubelet on the node is running properly.Scenario: The kubelet status is abnormal.If the kubelet malfunctions, the node will be unavailable. Restore the ", "doc_type":"usermanual2", "kw":"kubelet,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -1674,8 +1728,8 @@ "uri":"cce_10_0449.html", "node_id":"cce_10_0449.xml", "product_code":"cce", - "code":"93", - "des":"Check whether the node's memory usage is above 90%.Upgrade the cluster during off-peak hours.Check whether too many pods are deployed on the node. If yes, reschedule pods", + "code":"96", + "des":"Check whether the node's memory usage is above 90%.Upgrade the cluster during off-peak hours.Log in to the node, run the top command to obtain the memory usage of the pro", "doc_type":"usermanual2", "kw":"Node Memory,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -1692,7 +1746,7 @@ "uri":"cce_10_0450.html", "node_id":"cce_10_0450.xml", "product_code":"cce", - "code":"94", + "code":"97", "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", @@ -1710,7 +1764,7 @@ "uri":"cce_10_0451.html", "node_id":"cce_10_0451.xml", "product_code":"cce", - "code":"95", + "code":"98", "des":"Check whether the OS kernel version of the node is supported by CCE.Case 1: The node image is not a standard CCE image.CCE nodes run depending on the initial standard ker", "doc_type":"usermanual2", "kw":"Node OS,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1728,7 +1782,7 @@ "uri":"cce_10_0452.html", "node_id":"cce_10_0452.xml", "product_code":"cce", - "code":"96", + "code":"99", "des":"Verify that the master nodes in your cluster have more than 2 CPU cores.The master nodes have only 2 CPU cores, which may lead to a cluster upgrade failure.Contact techni", "doc_type":"usermanual2", "kw":"Node CPU Cores,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1746,7 +1800,7 @@ "uri":"cce_10_0453.html", "node_id":"cce_10_0453.xml", "product_code":"cce", - "code":"97", + "code":"100", "des":"Check whether the Python commands are available on a node.If the command output is not 0, the check fails.Reset the node or manually install Python before attempting the ", "doc_type":"usermanual2", "kw":"Node Python Commands,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1764,7 +1818,7 @@ "uri":"cce_10_0455.html", "node_id":"cce_10_0455.xml", "product_code":"cce", - "code":"98", + "code":"101", "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 click the cluster name to access the cl", "doc_type":"usermanual2", "kw":"Node Readiness,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1782,7 +1836,7 @@ "uri":"cce_10_0456.html", "node_id":"cce_10_0456.xml", "product_code":"cce", - "code":"99", + "code":"102", "des":"Check whether journald of a node is normal.Log in to the node and run the systemctl is-active systemd-journald command to obtain the running status of journald. If the co", "doc_type":"usermanual2", "kw":"Node journald,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1800,7 +1854,7 @@ "uri":"cce_10_0457.html", "node_id":"cce_10_0457.xml", "product_code":"cce", - "code":"100", + "code":"103", "des":"Check whether the containerd.sock file is on the node. This file affects the startup of container runtime in the Euler OS.Scenario: The Docker used by the node is the cus", "doc_type":"usermanual2", "kw":"containerd.sock,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1818,7 +1872,7 @@ "uri":"cce_10_0458.html", "node_id":"cce_10_0458.xml", "product_code":"cce", - "code":"101", + "code":"104", "des":"This check item is not typical and implies that an internal error was found during the pre-upgrade check.Perform the pre-upgrade check again.If it fails again, submit a s", "doc_type":"usermanual2", "kw":"Internal Error,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1836,7 +1890,7 @@ "uri":"cce_10_0459.html", "node_id":"cce_10_0459.xml", "product_code":"cce", - "code":"102", + "code":"105", "des":"Check whether there are inaccessible mount points on the node.Scenario: There are inaccessible mount points on the node.If NFS (such as obsfs or SFS) is used by the node ", "doc_type":"usermanual2", "kw":"Node Mount Points,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1854,7 +1908,7 @@ "uri":"cce_10_0460.html", "node_id":"cce_10_0460.xml", "product_code":"cce", - "code":"103", + "code":"106", "des":"Check whether the taint needed for cluster upgrade exists on the node.Scenario 1: The node is skipped during the cluster upgrade.If the version of the node is different f", "doc_type":"usermanual2", "kw":"Kubernetes Node Taints,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1872,7 +1926,7 @@ "uri":"cce_10_0478.html", "node_id":"cce_10_0478.xml", "product_code":"cce", - "code":"104", + "code":"107", "des":"Check whether there are any compatibility restrictions on the current Everest add-on.There are compatibility restrictions on the current Everest add-on and it cannot be u", "doc_type":"usermanual2", "kw":"Everest Restrictions,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1890,7 +1944,7 @@ "uri":"cce_10_0479.html", "node_id":"cce_10_0479.xml", "product_code":"cce", - "code":"105", + "code":"108", "des":"Check whether there are compatibility limitations between the current and target cce-controller-hpa add-on versions.There are compatibility limitations between the curren", "doc_type":"usermanual2", "kw":"cce-hpa-controller Limitations,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1908,7 +1962,7 @@ "uri":"cce_10_0480.html", "node_id":"cce_10_0480.xml", "product_code":"cce", - "code":"106", + "code":"109", "des":"Check whether the current cluster version and the target version support enhanced CPU policy.Scenario: Only the current cluster version supports the enhanced CPU policy f", "doc_type":"usermanual2", "kw":"Enhanced CPU Policies,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1926,7 +1980,7 @@ "uri":"cce_10_0484.html", "node_id":"cce_10_0484.xml", "product_code":"cce", - "code":"107", + "code":"110", "des":"Check whether the container runtime and network components on the worker nodes are healthy.Issue 1: CNI Agent is not active.If your cluster version is earlier than v1.17.", "doc_type":"usermanual2", "kw":"Health of Worker Node Components,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1944,7 +1998,7 @@ "uri":"cce_10_0485.html", "node_id":"cce_10_0485.xml", "product_code":"cce", - "code":"108", + "code":"111", "des":"Check whether cluster components such as the Kubernetes component, container runtime component, and network component are running properly before the upgrade.Perform the ", "doc_type":"usermanual2", "kw":"Health of Master Node Components,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1962,7 +2016,7 @@ "uri":"cce_10_0486.html", "node_id":"cce_10_0486.xml", "product_code":"cce", - "code":"109", + "code":"112", "des":"Check whether the resources of Kubernetes components, such as etcd and kube-controller-manager, exceed the upper limit.Solution 1: Reduce Kubernetes resources that are ne", "doc_type":"usermanual2", "kw":"Memory Resource Limit of Kubernetes Components,Troubleshooting for Pre-upgrade Check Exceptions,User", @@ -1980,7 +2034,7 @@ "uri":"cce_10_0487.html", "node_id":"cce_10_0487.xml", "product_code":"cce", - "code":"110", + "code":"113", "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":"Discarded Kubernetes APIs,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -1998,7 +2052,7 @@ "uri":"cce_10_0488.html", "node_id":"cce_10_0488.xml", "product_code":"cce", - "code":"111", + "code":"114", "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 Support in CCE Turbo Clusters,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2016,7 +2070,7 @@ "uri":"cce_10_0489.html", "node_id":"cce_10_0489.xml", "product_code":"cce", - "code":"112", + "code":"115", "des":"Check whether NetworkManager of a node is normal.Log in to the node and run the systemctl is-active NetworkManager command to obtain the running status of NetworkManager.", "doc_type":"usermanual2", "kw":"NetworkManager,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2034,7 +2088,7 @@ "uri":"cce_10_0490.html", "node_id":"cce_10_0490.xml", "product_code":"cce", - "code":"113", + "code":"116", "des":"Check the ID file format.", "doc_type":"usermanual2", "kw":"Node ID File,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2052,8 +2106,8 @@ "uri":"cce_10_0491.html", "node_id":"cce_10_0491.xml", "product_code":"cce", - "code":"114", - "des":"When you upgrade a cluster to v1.19 or later, the system checks whether the following configuration files have been modified on the backend:/opt/cloud/cce/kubernetes/kube", + "code":"117", + "des":"When you upgrade a cluster to v1.19 or later, CCE checks whether the following configuration files have been modified on the backend:/opt/cloud/cce/kubernetes/kubelet/kub", "doc_type":"usermanual2", "kw":"Node Configuration Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -2070,7 +2124,7 @@ "uri":"cce_10_0492.html", "node_id":"cce_10_0492.xml", "product_code":"cce", - "code":"115", + "code":"118", "des":"Check whether the configuration files of key components exist on the node.The following table lists the files to be checked.Reset the node. For details, see Resetting a N", "doc_type":"usermanual2", "kw":"Node Configuration File,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2088,7 +2142,7 @@ "uri":"cce_10_0493.html", "node_id":"cce_10_0493.xml", "product_code":"cce", - "code":"116", + "code":"119", "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":"CoreDNS Configuration Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2106,7 +2160,7 @@ "uri":"cce_10_0494.html", "node_id":"cce_10_0494.xml", "product_code":"cce", - "code":"117", + "code":"120", "des":"Check whether the sudo commands and sudo-related files of the node are working.Scenario 1: The sudo command fails to be executed.During the in-place cluster upgrade, the ", "doc_type":"usermanual2", "kw":"sudo,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2124,8 +2178,8 @@ "uri":"cce_10_0495.html", "node_id":"cce_10_0495.xml", "product_code":"cce", - "code":"118", - "des":"Whether some key commands that the node upgrade depends on are workingScenario 1: Executing the package manager command failed.Executing the rpm or dpkg command failed. I", + "code":"121", + "des":"Whether some key commands that the node upgrade depends on are workingScenario 1: The RPM package manager command fails to be executed.The rpm command fails to be execute", "doc_type":"usermanual2", "kw":"Key Node Commands,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -2142,7 +2196,7 @@ "uri":"cce_10_0496.html", "node_id":"cce_10_0496.xml", "product_code":"cce", - "code":"119", + "code":"122", "des":"Check whether the docker/containerd.sock file is directly mounted to the pods on a node. During an upgrade, Docker or containerd restarts and the sock file on the host ch", "doc_type":"usermanual2", "kw":"Mounting of a Sock File on a Node,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2160,7 +2214,7 @@ "uri":"cce_10_0497.html", "node_id":"cce_10_0497.xml", "product_code":"cce", - "code":"120", + "code":"123", "des":"Check whether the certificate used by an HTTPS load balancer has been modified on ELB.The certificate referenced by an HTTPS ingress created on CCE is modified on the ELB", "doc_type":"usermanual2", "kw":"HTTPS Load Balancer Certificate Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Gu", @@ -2178,8 +2232,8 @@ "uri":"cce_10_0498.html", "node_id":"cce_10_0498.xml", "product_code":"cce", - "code":"121", - "des":"Check whether the default mount directory and soft link on the node have been manually mounted or modified.Non-shared diskBy default, /var/lib/docker, containerd, or /mnt", + "code":"124", + "des":"This section describes how to diagnose and fix node-mount failures caused by CCE storage misconfigurations.Check item 1: mount point conflictsCheck ContentVerify that all", "doc_type":"usermanual2", "kw":"Node Mounting,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -2196,7 +2250,7 @@ "uri":"cce_10_0499.html", "node_id":"cce_10_0499.xml", "product_code":"cce", - "code":"122", + "code":"125", "des":"Check whether user paas is allowed to log in to a node.Run the following command to check whether user paas is allowed to log in to a node:If the permissions assigned to ", "doc_type":"usermanual2", "kw":"Login Permissions of User paas on a Node,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2214,7 +2268,7 @@ "uri":"cce_10_0500.html", "node_id":"cce_10_0500.xml", "product_code":"cce", - "code":"123", + "code":"126", "des":"Check whether the load balancer associated with a Service is allocated with a private IPv4 address.Solution 1: Delete the Service that is associated with a load balancer ", "doc_type":"usermanual2", "kw":"Private IPv4 Addresses of Load Balancers,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2232,7 +2286,7 @@ "uri":"cce_10_0501.html", "node_id":"cce_10_0501.xml", "product_code":"cce", - "code":"124", + "code":"127", "des":"Check the historical upgrade records of the cluster and confirm that the current version of the cluster meets the requirements for upgrading to the target version.Upgradi", "doc_type":"usermanual2", "kw":"Historical Upgrade Records,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2250,7 +2304,7 @@ "uri":"cce_10_0502.html", "node_id":"cce_10_0502.xml", "product_code":"cce", - "code":"125", + "code":"128", "des":"Check whether the CIDR block of the cluster management plane is the same as that configured on the backbone network.The CIDR block of the management plane has been modifi", "doc_type":"usermanual2", "kw":"CIDR Block of the Cluster Management Plane,Troubleshooting for Pre-upgrade Check Exceptions,User Gui", @@ -2268,10 +2322,10 @@ "uri":"cce_10_0503.html", "node_id":"cce_10_0503.xml", "product_code":"cce", - "code":"126", - "des":"CCE AI Suite (NVIDIA GPU) is involved in the upgrade, which may affect the GPU driver installation during the creation of a GPU node.The driver of CCE AI Suite (NVIDIA GP", + "code":"129", + "des":"Check whether CCE AI Suite (NVIDIA GPU) involved in the upgrade affects the GPU driver installation when creating a GPU node.The driver of CCE AI Suite (NVIDIA GPU) needs", "doc_type":"usermanual2", - "kw":"CCE AI Suite (NVIDIA GPU),Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "kw":"CCE AI Suite (NVIDIA GPU) Exceptions,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", "metedata":[ { @@ -2279,14 +2333,14 @@ "documenttype":"usermanual" } ], - "title":"CCE AI Suite (NVIDIA GPU)", + "title":"CCE AI Suite (NVIDIA GPU) Exceptions", "githuburl":"" }, { "uri":"cce_10_0504.html", "node_id":"cce_10_0504.xml", "product_code":"cce", - "code":"127", + "code":"130", "des":"Check whether the default system parameter settings on your nodes are modified.If the MTU value of the bond0 network on your BMS node is not the default value 1500, this ", "doc_type":"usermanual2", "kw":"Nodes' System Parameters,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2304,8 +2358,8 @@ "uri":"cce_10_0505.html", "node_id":"cce_10_0505.xml", "product_code":"cce", - "code":"128", - "des":"Check whether there are residual package version data in the current cluster.A message is displayed indicating that there are residual 10.12.1.109 CRD resources in your c", + "code":"131", + "des":"Check whether there is residual package version data in the current cluster.A message is displayed indicating that there are residual 10.12.1.109 CRD resources in your cl", "doc_type":"usermanual2", "kw":"Residual Package Version Data,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -2322,7 +2376,7 @@ "uri":"cce_10_0506.html", "node_id":"cce_10_0506.xml", "product_code":"cce", - "code":"129", + "code":"132", "des":"Check whether the commands required for the upgrade are available on the node.The cluster upgrade failure is typically caused by the lack of key node commands that are re", "doc_type":"usermanual2", "kw":"Node Commands,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2340,7 +2394,7 @@ "uri":"cce_10_0507.html", "node_id":"cce_10_0507.xml", "product_code":"cce", - "code":"130", + "code":"133", "des":"Check whether swap has been enabled on CCE nodes.By default, swap is disabled on CCE nodes. Check the necessity of enabling swap manually and determine the impact of disa", "doc_type":"usermanual2", "kw":"Node Swap,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2358,7 +2412,7 @@ "uri":"cce_10_0508.html", "node_id":"cce_10_0508.xml", "product_code":"cce", - "code":"131", + "code":"134", "des":"Check item 1: Check whether there is an Nginx Ingress route whose ingress type is not specified (kubernetes.io/ingress.class: nginx is not added to annotations) in the cl", "doc_type":"usermanual2", "kw":"NGINX Ingress Controller,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2376,7 +2430,7 @@ "uri":"cce_10_0510.html", "node_id":"cce_10_0510.xml", "product_code":"cce", - "code":"132", + "code":"135", "des":"Check whether the service pods running on a containerd node are restarted when containerd is upgraded.containerd on your node may need to be restarted. To minimize the im", "doc_type":"usermanual2", "kw":"containerd Pod Restart Risks,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2394,7 +2448,7 @@ "uri":"cce_10_0511.html", "node_id":"cce_10_0511.xml", "product_code":"cce", - "code":"133", + "code":"136", "des":"Check whether the configuration of CCE AI Suite (NVIDIA GPU) in a cluster has been intrusively modified. If so, upgrading the cluster may fail.", "doc_type":"usermanual2", "kw":"Key CCE AI Suite (NVIDIA GPU) Parameters,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2412,7 +2466,7 @@ "uri":"cce_10_0512.html", "node_id":"cce_10_0512.xml", "product_code":"cce", - "code":"134", + "code":"137", "des":"Check whether GPU service pods are rebuilt in a cluster when kubelet is restarted during the upgrade of the cluster.Upgrade the cluster when the impact on services is con", "doc_type":"usermanual2", "kw":"GPU Pod Rebuild Risks,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2430,7 +2484,7 @@ "uri":"cce_10_0513.html", "node_id":"cce_10_0513.xml", "product_code":"cce", - "code":"135", + "code":"138", "des":"Check whether ELB listener access control has been configured using annotations for the Services in the current cluster.If so, check whether their configurations are corr", "doc_type":"usermanual2", "kw":"ELB Listener Access Control,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2448,7 +2502,7 @@ "uri":"cce_10_0514.html", "node_id":"cce_10_0514.xml", "product_code":"cce", - "code":"136", + "code":"139", "des":"Check whether the flavor of the master nodes in the cluster is the same as the actual flavor of these nodes.This issue is typically caused by modifications made to the ma", "doc_type":"usermanual2", "kw":"Master Node Flavor,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2466,7 +2520,7 @@ "uri":"cce_10_0515.html", "node_id":"cce_10_0515.xml", "product_code":"cce", - "code":"137", + "code":"140", "des":"Check whether the number of available IP addresses in the cluster subnet supports rolling upgrade.Rolling upgrade is not supported if there are not enough IP addresses in", "doc_type":"usermanual2", "kw":"Subnet Quota of Master Nodes,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2484,7 +2538,7 @@ "uri":"cce_10_0516.html", "node_id":"cce_10_0516.xml", "product_code":"cce", - "code":"138", + "code":"141", "des":"Check whether an alarm is generated when a cluster is upgraded to v1.27 or later. Do not use Docker in clusters of versions later than 1.27.If your node's runtime is not ", "doc_type":"usermanual2", "kw":"Node Runtime,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2502,7 +2556,7 @@ "uri":"cce_10_0517.html", "node_id":"cce_10_0517.xml", "product_code":"cce", - "code":"139", + "code":"142", "des":"Check whether an alarm is generated when a cluster is upgraded to v1.27 or later. Do not use Docker in clusters of versions later than 1.27.If your node pool's runtime is", "doc_type":"usermanual2", "kw":"Node Pool Runtime,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2520,7 +2574,7 @@ "uri":"cce_10_0518.html", "node_id":"cce_10_0518.xml", "product_code":"cce", - "code":"140", + "code":"143", "des":"Check the number of images on your node. If there are more than 1000 images, it takes a long time for Docker to start, affecting the standard Docker output and functions ", "doc_type":"usermanual2", "kw":"Number of Node Images,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2538,10 +2592,10 @@ "uri":"cce_10_0520.html", "node_id":"cce_10_0520.xml", "product_code":"cce", - "code":"141", - "des":"Check whether the target version supports secret encryption. If it does not, clusters that have this feature enabled cannot be upgraded to the target version.Secret encry", + "code":"144", + "des":"Check whether the target version supports at-rest encryption for secrets. If it does not, clusters that have this feature enabled cannot be upgraded to the target version", "doc_type":"usermanual2", - "kw":"Compatibility Check of Secret Encryption,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", + "kw":"Compatibility Check of At-Rest Encryption for Secrets,Troubleshooting for Pre-upgrade Check Exceptio", "search_title":"", "metedata":[ { @@ -2549,14 +2603,14 @@ "documenttype":"usermanual" } ], - "title":"Compatibility Check of Secret Encryption", + "title":"Compatibility Check of At-Rest Encryption for Secrets", "githuburl":"" }, { "uri":"cce_10_0521.html", "node_id":"cce_10_0521.xml", "product_code":"cce", - "code":"142", + "code":"145", "des":"Make sure that CCE AI Suite (NVIDIA GPU) and Ubuntu nodes are compatible before using them in a cluster. If the Ubuntu kernel is 5.15.0-113-generic, the driver of the GPU", "doc_type":"usermanual2", "kw":"Compatibility Between the Ubuntu Kernel and GPU Driver,Troubleshooting for Pre-upgrade Check Excepti", @@ -2574,7 +2628,7 @@ "uri":"cce_10_0522.html", "node_id":"cce_10_0522.xml", "product_code":"cce", - "code":"143", + "code":"146", "des":"An unfinished drainage task is detected in the cluster, which may resume after the upgrade. If this happens, running pods will be evicted, which could impact your service", "doc_type":"usermanual2", "kw":"Drainage Tasks,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2592,7 +2646,7 @@ "uri":"cce_10_0523.html", "node_id":"cce_10_0523.xml", "product_code":"cce", - "code":"144", + "code":"147", "des":"Check the number of image layers on your node. If there are more than 5000 layers, it will take a long time for Docker or containerd to start, affecting the stdout of Doc", "doc_type":"usermanual2", "kw":"Image Layers on a Node,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2610,7 +2664,7 @@ "uri":"cce_10_0524.html", "node_id":"cce_10_0524.xml", "product_code":"cce", - "code":"145", + "code":"148", "des":"Check whether your cluster is eligible for a rolling upgrade. The result shows that the rolling upgrade is not supported.Rolling upgrades cannot be performed if the tenan", "doc_type":"usermanual2", "kw":"Cluster Rolling Upgrade,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2628,7 +2682,7 @@ "uri":"cce_10_0525.html", "node_id":"cce_10_0525.xml", "product_code":"cce", - "code":"146", + "code":"149", "des":"Check whether the number of certificates on your node is greater than 1000. During an upgrade, certificate files will be processed in batches. An excessive number of cert", "doc_type":"usermanual2", "kw":"Rotation Certificates,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2646,7 +2700,7 @@ "uri":"cce_10_0526.html", "node_id":"cce_10_0526.xml", "product_code":"cce", - "code":"147", + "code":"150", "des":"Check whether any modifications have been made to the listener, forwarding policy, forwarding rule, backend cloud server group, backend cloud server, or certificate confi", "doc_type":"usermanual2", "kw":"Ingress and ELB Configuration Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Guid", @@ -2664,7 +2718,7 @@ "uri":"cce_10_0527.html", "node_id":"cce_10_0527.xml", "product_code":"cce", - "code":"148", + "code":"151", "des":"Check the network policy settings on the master nodes in your cluster. If any manual modifications have been made, they will be reset during the upgrade.Check whether net", "doc_type":"usermanual2", "kw":"Network Policies of Cluster Network Components,Troubleshooting for Pre-upgrade Check Exceptions,User", @@ -2682,7 +2736,7 @@ "uri":"cce_10_0528.html", "node_id":"cce_10_0528.xml", "product_code":"cce", - "code":"149", + "code":"152", "des":"Check whether the nic-max-above-warm-target value configured for the network component of the current cluster exceeds the maximum value allowed.Determine the scope of imp", "doc_type":"usermanual2", "kw":"Cluster and Node Pool Configurations,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2700,7 +2754,7 @@ "uri":"cce_10_0529.html", "node_id":"cce_10_0529.xml", "product_code":"cce", - "code":"150", + "code":"153", "des":"Check whether the time zone of the master nodes matches the cluster's time zone. If they are different, the master nodes will be updated to match the cluster's time zone ", "doc_type":"usermanual2", "kw":"Time Zone of Master Nodes,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2718,7 +2772,7 @@ "uri":"cce_10_0530.html", "node_id":"cce_10_0530.xml", "product_code":"cce", - "code":"151", + "code":"154", "des":"Check whether the SNATIPRanges value has changed after the upgrade. This check is available only for CCE Turbo clusters.In a CCE Turbo cluster, the CIDR blocks in SNATIPR", "doc_type":"usermanual2", "kw":"SNATIPRanges,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", @@ -2736,8 +2790,8 @@ "uri":"cce_10_0531.html", "node_id":"cce_10_0531.xml", "product_code":"cce", - "code":"152", - "des":"Manual modifications to add-on configuration parameters (typically ConfigMaps), instead of modifications through the CCE console or APIs, may be overwritten after an upgr", + "code":"155", + "des":"Manual modifications to add-on configuration parameters (typically ConfigMaps), instead of modifications through the CCE console or add-on API updates, may be overwritten", "doc_type":"usermanual2", "kw":"Add-on Configuration Consistency,Troubleshooting for Pre-upgrade Check Exceptions,User Guide", "search_title":"", @@ -2754,7 +2808,7 @@ "uri":"cce_10_0183.html", "node_id":"cce_10_0183.xml", "product_code":"cce", - "code":"153", + "code":"156", "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":"Nodes", @@ -2772,7 +2826,7 @@ "uri":"cce_10_0180.html", "node_id":"cce_10_0180.xml", "product_code":"cce", - "code":"154", + "code":"157", "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":"paas,user group,Node Overview,Nodes,User Guide", @@ -2790,7 +2844,7 @@ "uri":"cce_10_0462.html", "node_id":"cce_10_0462.xml", "product_code":"cce", - "code":"155", + "code":"158", "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 Engines,Nodes,User Guide", @@ -2808,7 +2862,7 @@ "uri":"cce_10_0476.html", "node_id":"cce_10_0476.xml", "product_code":"cce", - "code":"156", + "code":"159", "des":"This section describes the mappings between released cluster versions and OS versions.", "doc_type":"usermanual2", "kw":"Node OSs,Nodes,User Guide", @@ -2826,8 +2880,8 @@ "uri":"cce_10_0363.html", "node_id":"cce_10_0363.xml", "product_code":"cce", - "code":"157", - "des":"At least one cluster has been created.A key pair has been created for identity authentication upon remote node login.The DNS configuration of a subnet where a node is loc", + "code":"160", + "des":"At least one cluster is available.A key pair is available for remote node login using key-pair authentication. If you use a password for login, skip this step.If you use ", "doc_type":"usermanual2", "kw":"Creating a Node,Nodes,User Guide", "search_title":"", @@ -2844,8 +2898,8 @@ "uri":"cce_10_0198.html", "node_id":"cce_10_0198.xml", "product_code":"cce", - "code":"158", - "des":"In CCE, you can create a node (Creating a Node) or add existing nodes (ECSs) to your cluster for management.When accepting an ECS, you can reset the ECS OS to a standard ", + "code":"161", + "des":"In CCE, you can create a node (Creating a Node) or add existing nodes (ECSs) to your cluster for management.When accepting an ECS, you can reset its OS to a standard publ", "doc_type":"usermanual2", "kw":"Accepting Nodes for Management,Nodes,User Guide", "search_title":"", @@ -2862,8 +2916,8 @@ "uri":"cce_10_0185.html", "node_id":"cce_10_0185.xml", "product_code":"cce", - "code":"159", - "des":"Before you log in to a node using SSH, ensure that the SSH port (22 by default) is enabled in the security group of the node.Before you log in to a node (an ECS) using SS", + "code":"162", + "des":"Before you log in to a node using SSH, ensure the SSH port (22 by default) is enabled in the security group of the node.Before you log in to a node (an ECS) via SSH over ", "doc_type":"usermanual2", "kw":"Logging In to a Node,Nodes,User Guide", "search_title":"", @@ -2880,7 +2934,7 @@ "uri":"cce_10_0672.html", "node_id":"cce_10_0672.xml", "product_code":"cce", - "code":"160", + "code":"163", "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", @@ -2898,7 +2952,7 @@ "uri":"cce_10_0004.html", "node_id":"cce_10_0004.xml", "product_code":"cce", - "code":"161", + "code":"164", "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,Management Nodes,User Guide", @@ -2916,7 +2970,7 @@ "uri":"cce_10_0352.html", "node_id":"cce_10_0352.xml", "product_code":"cce", - "code":"162", + "code":"165", "des":"Taints enable a node to repel specific pods to prevent these pods from being scheduled to the node.On the CCE console, you can also batch manage nodes' taints.Enter the k", "doc_type":"usermanual2", "kw":"NoSchedule,PreferNoSchedule,NoExecute,System Taints,Managing Node Taints,Management Nodes,User Guide", @@ -2934,7 +2988,7 @@ "uri":"cce_10_0003.html", "node_id":"cce_10_0003.xml", "product_code":"cce", - "code":"163", + "code":"166", "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":"reset a node,Resetting a Node,Management Nodes,User Guide", @@ -2952,7 +3006,7 @@ "uri":"cce_10_0338.html", "node_id":"cce_10_0338.xml", "product_code":"cce", - "code":"164", + "code":"167", "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,Management Nodes,User Guide", @@ -2970,10 +3024,10 @@ "uri":"cce_10_0184.html", "node_id":"cce_10_0184.xml", "product_code":"cce", - "code":"165", + "code":"168", "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. Modifyi", "doc_type":"usermanual2", - "kw":"synchronize the ECS,Synchronizing the Data of Cloud Servers,Management Nodes,User Guide", + "kw":"synchronize it,Synchronizing the Data of Cloud Servers,Management Nodes,User Guide", "search_title":"", "metedata":[ { @@ -2988,7 +3042,7 @@ "uri":"cce_10_0605.html", "node_id":"cce_10_0605.xml", "product_code":"cce", - "code":"166", + "code":"169", "des":"After you enable nodal drainage on the console, CCE configures the node to be non-schedulable and securely evicts all pods that comply with Rules for Draining Nodes on th", "doc_type":"usermanual2", "kw":"nodal drainage,nodal drainage,Draining a Node,Management Nodes,User Guide", @@ -3006,8 +3060,8 @@ "uri":"cce_10_0186.html", "node_id":"cce_10_0186.xml", "product_code":"cce", - "code":"167", - "des":"If a node is no longer needed, delete it from the node list on the CCE console if the node is billed on a pay-per-use basis. Do not manually remove nodes using kubectl de", + "code":"170", + "des":"If a node is no longer needed, delete it on the CCE console if the node is billed on a pay-per-use basis. Do not manually remove nodes using kubectl delete node, as this ", "doc_type":"usermanual2", "kw":"Deleting a Node,Management Nodes,User Guide", "search_title":"", @@ -3024,7 +3078,7 @@ "uri":"cce_10_0036.html", "node_id":"cce_10_0036.xml", "product_code":"cce", - "code":"168", + "code":"171", "des":"When a node in the cluster is stopped, all services on that node will also be stopped, and the node will no longer be available for scheduling. Check if your services wil", "doc_type":"usermanual2", "kw":"Stopping a Node,Management Nodes,User Guide", @@ -3042,7 +3096,7 @@ "uri":"cce_10_0276.html", "node_id":"cce_10_0276.xml", "product_code":"cce", - "code":"169", + "code":"172", "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,Management Nodes,User Guide", @@ -3060,7 +3114,7 @@ "uri":"cce_10_0704.html", "node_id":"cce_10_0704.xml", "product_code":"cce", - "code":"170", + "code":"173", "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 O&M", @@ -3078,10 +3132,10 @@ "uri":"cce_10_0178.html", "node_id":"cce_10_0178.xml", "product_code":"cce", - "code":"171", + "code":"174", "des":"Some node resources are used to run mandatory Kubernetes system components and resources to make the node as part of your cluster. Therefore, the total number of node res", "doc_type":"usermanual2", - "kw":"total number of node resources,Node Resource Reservation Policy,Node O&M,User Guide", + "kw":"total number of node resources,Node Resource Reservation Rules,Node O&M,User Guide", "search_title":"", "metedata":[ { @@ -3089,14 +3143,14 @@ "documenttype":"usermanual" } ], - "title":"Node Resource Reservation Policy", + "title":"Node Resource Reservation Rules", "githuburl":"" }, { "uri":"cce_10_0341.html", "node_id":"cce_10_0341.xml", "product_code":"cce", - "code":"172", + "code":"175", "des":"This section describes how to allocate data disk space to nodes so that you can configure the data disk space accordingly.In clusters of a version earlier than v1.23.18-r", "doc_type":"usermanual2", "kw":"Data Disk Space Allocation,Container engine and container image space,container engine and container", @@ -3114,8 +3168,8 @@ "uri":"cce_10_0348.html", "node_id":"cce_10_0348.xml", "product_code":"cce", - "code":"173", - "des":"The maximum number of pods that can be created on a node is calculated based on the cluster type:When creating a cluster in the VPC network model, follow the and specify", + "code":"176", + "des":"The maximum number of pods that can be created on a node is calculated based on the cluster type:The number of allocatable pod IP addresses on a node is the maximum numbe", "doc_type":"usermanual2", "kw":"Maximum Number of Pods on a Node,alpha.cce/fixPoolMask,maximum number of pods,Maximum Number of Pods", "search_title":"", @@ -3132,7 +3186,7 @@ "uri":"cce_10_0883.html", "node_id":"cce_10_0883.xml", "product_code":"cce", - "code":"174", + "code":"177", "des":"To maintain the stability of nodes, CCE stores Kubernetes and container runtime components on separate data disks. Kubernetes uses the /mnt/paas/kubernetes directory, and", "doc_type":"usermanual2", "kw":"Differences in kubelet and Runtime Component Configurations Between CCE and the Native Community,Nod", @@ -3150,7 +3204,7 @@ "uri":"cce_10_0601.html", "node_id":"cce_10_0601.xml", "product_code":"cce", - "code":"175", + "code":"178", "des":"As of Kubernetes v1.24, dockershim has been deprecated. To maintain compatibility and ensure continued support for future Kubernetes releases, switch your node's containe", "doc_type":"usermanual2", "kw":"Migrating Nodes from Docker to containerd,Node O&M,User Guide", @@ -3168,8 +3222,8 @@ "uri":"cce_10_0659.html", "node_id":"cce_10_0659.xml", "product_code":"cce", - "code":"176", - "des":"The node fault detection function depends on the NPD add-on. The add-on instances run on nodes and monitor nodes. This section describes how to enable node fault detectio", + "code":"179", + "des":"Node fault detection depends on the CCE Node Problem Detector add-on (CCE Node Problem Detector). The add-on instance runs on each node to monitor node faults. This secti", "doc_type":"usermanual2", "kw":"Node Fault Detection,Check Items,Configuring Node Fault Detection Policies,Node O&M,User Guide", "search_title":"", @@ -3183,10 +3237,10 @@ "githuburl":"" }, { - "uri":"cce_bestpractice_10020.html", - "node_id":"cce_bestpractice_10020.xml", + "uri":"cce_bestpractice_10020_0.html", + "node_id":"cce_bestpractice_10020_0.xml", "product_code":"cce", - "code":"177", + "code":"180", "des":"When creating a node, use the pre- or -installation commands to install tools or perform security hardening on the node. This section provides guidance for you to correct", "doc_type":"usermanual2", "kw":"Executing the Pre- or Post-installation Commands During Node Creation,Node O&M,User Guide", @@ -3204,7 +3258,7 @@ "uri":"cce_10_0035.html", "node_id":"cce_10_0035.xml", "product_code":"cce", - "code":"178", + "code":"181", "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", @@ -3222,7 +3276,7 @@ "uri":"cce_10_0081.html", "node_id":"cce_10_0081.xml", "product_code":"cce", - "code":"179", + "code":"182", "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":"DefaultPool,DefaultPool,Deploying a Workload in a Specified Node Pool,Node Pool Overview,Node Pools,", @@ -3240,7 +3294,7 @@ "uri":"cce_10_0012.html", "node_id":"cce_10_0012.xml", "product_code":"cce", - "code":"180", + "code":"183", "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.Basic SettingsNo", "doc_type":"usermanual2", "kw":"Creating a Node Pool,Node Pools,User Guide", @@ -3258,7 +3312,7 @@ "uri":"cce_10_0658.html", "node_id":"cce_10_0658.xml", "product_code":"cce", - "code":"181", + "code":"184", "des":"You can specify a specification in a node pool for scaling.The default node pool does not support scaling. Use Creating a Node to add a node.Resize: Add or reduce nodes f", "doc_type":"usermanual2", "kw":"Scaling a Node Pool,Node Pools,User Guide", @@ -3276,10 +3330,10 @@ "uri":"cce_10_0222.html", "node_id":"cce_10_0222.xml", "product_code":"cce", - "code":"182", + "code":"185", "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", + "kw":"Managing Node Pools", "search_title":"", "metedata":[ { @@ -3287,17 +3341,17 @@ "documenttype":"usermanual" } ], - "title":"Managing a Node Pool", + "title":"Managing Node Pools", "githuburl":"" }, { "uri":"cce_10_0653.html", "node_id":"cce_10_0653.xml", "product_code":"cce", - "code":"183", + "code":"186", "des":"Changes to the container engine, OS, or pre-/post-installation script in a node pool take effect only on new nodes. To synchronize the modification onto existing nodes, m", "doc_type":"usermanual2", - "kw":"base size,Updating a Node Pool,Managing a Node Pool,User Guide", + "kw":"base size,Updating a Node Pool,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3312,10 +3366,10 @@ "uri":"cce_10_0727.html", "node_id":"cce_10_0727.xml", "product_code":"cce", - "code":"184", + "code":"187", "des":"Auto Scaling (AS) enables elastic scaling of nodes in a node pool based on scaling policies. Without this function, you have to manually adjust the number of nodes in a n", "doc_type":"usermanual2", - "kw":"Updating an AS Configuration,Managing a Node Pool,User Guide", + "kw":"Updating an AS Configuration,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3330,10 +3384,10 @@ "uri":"cce_10_0652.html", "node_id":"cce_10_0652.xml", "product_code":"cce", - "code":"185", - "des":"The default node pool does not support the management operations described in this section.CCE allows you to highly customize Kubernetes parameter settings on core compon", + "code":"188", + "des":"If the default node configurations of in cluster do not meet service requirements, you can customize parameters for core components, such as kubelet, kube-proxy, and the ", "doc_type":"usermanual2", - "kw":"Modifying Node Pool Configurations,Managing a Node Pool,User Guide", + "kw":"Modifying Node Pool Configurations,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3348,10 +3402,10 @@ "uri":"cce_10_0886.html", "node_id":"cce_10_0886.xml", "product_code":"cce", - "code":"186", + "code":"189", "des":"If you want to add a newly created ECS to a node pool in a cluster, or remove a node from a node pool and add it to the node pool again, accept the node.When an ECS is ac", "doc_type":"usermanual2", - "kw":"Accepting Nodes in a Node Pool,Managing a Node Pool,User Guide", + "kw":"Accepting Nodes in a Node Pool,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3366,10 +3420,10 @@ "uri":"cce_10_0655.html", "node_id":"cce_10_0655.xml", "product_code":"cce", - "code":"187", + "code":"190", "des":"You can copy the configuration of an existing node pool on the CCE console to create new node pools.", "doc_type":"usermanual2", - "kw":"Copying a Node Pool,Managing a Node Pool,User Guide", + "kw":"Copying a Node Pool,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3384,10 +3438,10 @@ "uri":"cce_10_0654.html", "node_id":"cce_10_0654.xml", "product_code":"cce", - "code":"188", + "code":"191", "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", + "kw":"Synchronizing Node Pools,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3402,10 +3456,10 @@ "uri":"cce_10_0660.html", "node_id":"cce_10_0660.xml", "product_code":"cce", - "code":"189", + "code":"192", "des":"After CCE releases a new OS image, if existing nodes cannot be automatically upgraded, you can manually upgrade them in batches.This section describes how to upgrade an O", "doc_type":"usermanual2", - "kw":"Upgrading an OS,Managing a Node Pool,User Guide", + "kw":"Upgrading an OS,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3420,10 +3474,10 @@ "uri":"cce_10_0656.html", "node_id":"cce_10_0656.xml", "product_code":"cce", - "code":"190", + "code":"193", "des":"You can migrate nodes between node pools within a cluster. Table 1 lists migration scenarios.Migration scenariosMigration ScenarioMigrationOperationSource Node PoolTarget", "doc_type":"usermanual2", - "kw":"Migrating a Node,Managing a Node Pool,User Guide", + "kw":"Migrating a Node,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3438,10 +3492,10 @@ "uri":"cce_10_0657.html", "node_id":"cce_10_0657.xml", "product_code":"cce", - "code":"191", - "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", + "code":"194", + "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 will cause P", "doc_type":"usermanual2", - "kw":"Deleting a Node Pool,Managing a Node Pool,User Guide", + "kw":"Deleting a Node Pool,Managing Node Pools,User Guide", "search_title":"", "metedata":[ { @@ -3456,7 +3510,7 @@ "uri":"cce_10_0046.html", "node_id":"cce_10_0046.xml", "product_code":"cce", - "code":"192", + "code":"195", "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", @@ -3474,10 +3528,10 @@ "uri":"cce_10_0006.html", "node_id":"cce_10_0006.xml", "product_code":"cce", - "code":"193", + "code":"196", "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":"Deployments,StatefulSets,DaemonSets,jobs,cron jobs,Overview,Workloads,User Guide", + "kw":"Deployments,StatefulSets,DaemonSets,jobs,cron jobs,Workload Overview,Workloads,User Guide", "search_title":"", "metedata":[ { @@ -3485,14 +3539,14 @@ "documenttype":"usermanual" } ], - "title":"Overview", + "title":"Workload Overview", "githuburl":"" }, { "uri":"cce_10_0673.html", "node_id":"cce_10_0673.xml", "product_code":"cce", - "code":"194", + "code":"197", "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":"Creating a Workload", @@ -3510,8 +3564,8 @@ "uri":"cce_10_0047.html", "node_id":"cce_10_0047.xml", "product_code":"cce", - "code":"195", - "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", + "code":"198", + "des":"A Deployment is a Kubernetes application that does not retain data or state while running. Each pod of the same Deployment is identical, allowing for seamless creation, d", "doc_type":"usermanual2", "kw":"create a workload using kubectl,Creating a Deployment,Creating a Workload,User Guide", "search_title":"", @@ -3528,8 +3582,8 @@ "uri":"cce_10_0048.html", "node_id":"cce_10_0048.xml", "product_code":"cce", - "code":"196", - "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", + "code":"199", + "des":"A StatefulSet is an application that needs to retain data or state while running. StatefulSets are ideal for stateful applications, such as databases, cache services, and", "doc_type":"usermanual2", "kw":"Using kubectl,Creating a StatefulSet,Creating a Workload,User Guide", "search_title":"", @@ -3546,8 +3600,8 @@ "uri":"cce_10_0216.html", "node_id":"cce_10_0216.xml", "product_code":"cce", - "code":"197", - "des":"CCE provides deployment and management capabilities for multiple types of containers and supports features of container workloads, including creation, configuration, moni", + "code":"200", + "des":"A DaemonSet is a Kubernetes workload type that ensures a pod runs on all or selected nodes in a cluster. When a new node is added to the cluster, the DaemonSet controller", "doc_type":"usermanual2", "kw":"create a workload using kubectl,Creating a DaemonSet,Creating a Workload,User Guide", "search_title":"", @@ -3564,8 +3618,8 @@ "uri":"cce_10_0150.html", "node_id":"cce_10_0150.xml", "product_code":"cce", - "code":"198", - "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", + "code":"201", + "des":"A job is a Kubernetes workload designed for managing batch processing tasks, handling one-time or short-lived tasks. Unlike long-running services managed by Deployments o", "doc_type":"usermanual2", "kw":"Creating a Job,Creating a Workload,User Guide", "search_title":"", @@ -3582,10 +3636,10 @@ "uri":"cce_10_0151.html", "node_id":"cce_10_0151.xml", "product_code":"cce", - "code":"199", - "des":"A CronJob runs on a repeating schedule. You can perform time synchronization for all active nodes at a fixed time point.A CronJob runs periodically at the specified time.", + "code":"202", + "des":"A CronJob is a Kubernetes workload designed to run periodic tasks, similar to crontab in Linux. CronJobs follow a Cron format. They periodically execute jobs at predefine", "doc_type":"usermanual2", - "kw":"time synchronization,Creating a CronJob,Creating a Workload,User Guide", + "kw":"Creating a CronJob,Creating a Workload,User Guide", "search_title":"", "metedata":[ { @@ -3600,7 +3654,7 @@ "uri":"cce_10_0130.html", "node_id":"cce_10_0130.xml", "product_code":"cce", - "code":"200", + "code":"203", "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 Workload", @@ -3618,7 +3672,7 @@ "uri":"cce_10_0463.html", "node_id":"cce_10_0463.xml", "product_code":"cce", - "code":"201", + "code":"204", "des":"Compared with a common runtime, a secure runtime allows each container (pod) to run on its own micro-VM with a separate OS kernel. This ensures secure isolation at the vi", "doc_type":"usermanual2", "kw":"Secure Runtime and Common Runtime,Configuring a Workload,User Guide", @@ -3636,8 +3690,8 @@ "uri":"cce_10_0354.html", "node_id":"cce_10_0354.xml", "product_code":"cce", - "code":"202", - "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", + "code":"205", + "des":"When creating a workload, you can enable time zone synchronization, so that the container can use the same time zone as the node.Configure the following parameters:hostPa", "doc_type":"usermanual2", "kw":"Configuring Time Zone Synchronization,Configuring a Workload,User Guide", "search_title":"", @@ -3654,7 +3708,7 @@ "uri":"cce_10_0353.html", "node_id":"cce_10_0353.xml", "product_code":"cce", - "code":"203", + "code":"206", "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 Workload,User Guide", @@ -3672,8 +3726,8 @@ "uri":"cce_10_0009.html", "node_id":"cce_10_0009.xml", "product_code":"cce", - "code":"204", - "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", + "code":"207", + "des":"Third-party images are container images provided by organizations or individuals other than the official image repository and SWR image repository. These images typically", "doc_type":"usermanual2", "kw":"Using Third-Party Images,Configuring a Workload,User Guide", "search_title":"", @@ -3690,7 +3744,7 @@ "uri":"cce_10_0163.html", "node_id":"cce_10_0163.xml", "product_code":"cce", - "code":"205", + "code":"208", "des":"CCE allows you to set resource requirements and limits, such as CPU and RAM, for added containers during workload creation. Kubernetes also allows using YAML to set requi", "doc_type":"usermanual2", "kw":"ephemeral storage,Configuring Container Specifications,Configuring a Workload,User Guide", @@ -3708,10 +3762,10 @@ "uri":"cce_10_0105.html", "node_id":"cce_10_0105.xml", "product_code":"cce", - "code":"206", - "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", + "code":"209", + "des":"Container lifecycle hooks are core mechanisms provided by Kubernetes that enable you to insert custom logic at key phases throughout the container lifecycle. These hooks ", "doc_type":"usermanual2", - "kw":"Startup Command,Post-Start,Pre-Stop,Configuring Container Lifecycle Parameters,Configuring a Workloa", + "kw":"Configuring the Container Lifecycle,Configuring a Workload,User Guide", "search_title":"", "metedata":[ { @@ -3719,17 +3773,17 @@ "documenttype":"usermanual" } ], - "title":"Configuring Container Lifecycle Parameters", + "title":"Configuring the Container Lifecycle", "githuburl":"" }, { "uri":"cce_10_0112.html", "node_id":"cce_10_0112.xml", "product_code":"cce", - "code":"207", - "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", + "code":"210", + "des":"Health check regularly checks the health of containers when the containers are running. If health check is not configured, a pod cannot detect application exceptions or a", "doc_type":"usermanual2", - "kw":"Health check,HTTP request,TCP port,CLI,Configuring Container Health Check,Configuring a Workload,Use", + "kw":"Health check,Liveness probe,Readiness probe,Startup probe,HTTP,TCP,Command,Configuring Container Hea", "search_title":"", "metedata":[ { @@ -3744,8 +3798,8 @@ "uri":"cce_10_0113.html", "node_id":"cce_10_0113.xml", "product_code":"cce", - "code":"208", - "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", + "code":"211", + "des":"Container environment variables (for example, DB_HOST=db.example.com) are configuration parameters dynamically transferred when a container is running. They allow you to ", "doc_type":"usermanual2", "kw":"Configuring Environment Variables,Configuring a Workload,User Guide", "search_title":"", @@ -3762,10 +3816,10 @@ "uri":"cce_10_0397.html", "node_id":"cce_10_0397.xml", "product_code":"cce", - "code":"209", - "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", + "code":"212", + "des":"After a workload is created, you can upgrade it and roll it back. The flexible upgrade and rollback mechanism enables smooth version transitions without interrupting serv", "doc_type":"usermanual2", - "kw":"Configuring Workload Upgrade Policies,Configuring a Workload,User Guide", + "kw":"Upgrading and Rolling Back a Workload,Configuring a Workload,User Guide", "search_title":"", "metedata":[ { @@ -3773,14 +3827,14 @@ "documenttype":"usermanual" } ], - "title":"Configuring Workload Upgrade Policies", + "title":"Upgrading and Rolling Back a Workload", "githuburl":"" }, { "uri":"cce_10_0728.html", "node_id":"cce_10_0728.xml", "product_code":"cce", - "code":"210", + "code":"213", "des":"Tolerations allow the scheduler to schedule pods to nodes with target taints. Tolerances work with node taints. Each node allows one or more taints. If no tolerance is co", "doc_type":"usermanual2", "kw":"Configuring Tolerance Policies,Configuring a Workload,User Guide", @@ -3798,8 +3852,8 @@ "uri":"cce_10_0386.html", "node_id":"cce_10_0386.xml", "product_code":"cce", - "code":"211", - "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", + "code":"214", + "des":"To support multi-dimensional metadata management, Kubernetes offers labels and annotations. They both attach metadata to resources in the format of key-value pairs, but t", "doc_type":"usermanual2", "kw":"Configuring Labels and Annotations,Configuring a Workload,User Guide", "search_title":"", @@ -3816,7 +3870,7 @@ "uri":"cce_10_0889.html", "node_id":"cce_10_0889.xml", "product_code":"cce", - "code":"212", + "code":"215", "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":"Scheduling a Workload", @@ -3834,7 +3888,7 @@ "uri":"cce_10_0232.html", "node_id":"cce_10_0232.xml", "product_code":"cce", - "code":"213", + "code":"216", "des":"Kubernetes schedules workloads based on pods. After you create a workload, the scheduler automatically assigns pods. For example, the scheduler distributes pods to nodes ", "doc_type":"usermanual2", "kw":"Overview,Scheduling a Workload,User Guide", @@ -3852,8 +3906,8 @@ "uri":"cce_10_0891.html", "node_id":"cce_10_0891.xml", "product_code":"cce", - "code":"214", - "des":"To select a node for scheduling in Kubernetes, simply configure the nodeSelector field in the workload. This field allows you to configure the label of the desired node t", + "code":"217", + "des":"In Kubernetes, to schedule a workload to a specified node, simply configure the nodeSelector field in the workload. By setting the target node label in this field, Kubern", "doc_type":"usermanual2", "kw":"Configuring Specified Node Scheduling (nodeSelector),Scheduling a Workload,User Guide", "search_title":"", @@ -3870,7 +3924,7 @@ "uri":"cce_10_0892.html", "node_id":"cce_10_0892.xml", "product_code":"cce", - "code":"215", + "code":"218", "des":"Kubernetes can schedule workload pods to affinity nodes based on their labels and label values. For example, some nodes support GPU computing, and node affinity schedulin", "doc_type":"usermanual2", "kw":"Specify node,Specify node pool,Configuring Node Affinity Scheduling (nodeAffinity),Scheduling a Work", @@ -3888,7 +3942,7 @@ "uri":"cce_10_0893.html", "node_id":"cce_10_0893.xml", "product_code":"cce", - "code":"216", + "code":"219", "des":"Kubernetes offers workload affinity and anti-affinity scheduling, which allows for flexible scheduling of new workloads on either related or unrelated nodes. This results", "doc_type":"usermanual2", "kw":"Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity),Schedulin", @@ -3906,7 +3960,7 @@ "uri":"cce_10_00356.html", "node_id":"cce_10_00356.xml", "product_code":"cce", - "code":"217", + "code":"220", "des":"If you encounter unexpected problems when using a container, you can log in to the container to debug it.The example output is as follows:NAME ", "doc_type":"usermanual2", "kw":"Logging In to a Container,Workloads,User Guide", @@ -3924,10 +3978,10 @@ "uri":"cce_10_0007.html", "node_id":"cce_10_0007.xml", "product_code":"cce", - "code":"218", - "des":"After a workload is created, you can upgrade, log, monitor, roll back, or delete the workload, as well as edit its YAML file.Workload/Job managementOperationDescriptionMo", + "code":"221", + "des":"After a workload is created, you can upgrade it, edit its YAML file, view logs and monitoring data, roll it back, and delete it.Workload/Job managementOperationDescriptio", "doc_type":"usermanual2", - "kw":"Managing Workloads,Workloads,User Guide", + "kw":"Managing Labels,Managing Workloads,Workloads,User Guide", "search_title":"", "metedata":[ { @@ -3942,7 +3996,7 @@ "uri":"cce_10_0833.html", "node_id":"cce_10_0833.xml", "product_code":"cce", - "code":"219", + "code":"222", "des":"Custom Resource Definition (CRD) is an extension of Kubernetes APIs. When default Kubernetes resources cannot meet service requirements, you can use CRDs to define new re", "doc_type":"usermanual2", "kw":"Managing Custom Resources,Workloads,User Guide", @@ -3960,7 +4014,7 @@ "uri":"cce_10_0465.html", "node_id":"cce_10_0465.xml", "product_code":"cce", - "code":"220", + "code":"223", "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":"Pod Security", @@ -3978,7 +4032,7 @@ "uri":"cce_10_0275.html", "node_id":"cce_10_0275.xml", "product_code":"cce", - "code":"221", + "code":"224", "des":"A pod security policy (PSP) is a cluster-level resource that controls sensitive security aspects of the pod specification. The PodSecurityPolicy object in Kubernetes defi", "doc_type":"usermanual2", "kw":"Configuring a Pod Security Policy,Pod Security,User Guide", @@ -3996,7 +4050,7 @@ "uri":"cce_10_0466.html", "node_id":"cce_10_0466.xml", "product_code":"cce", - "code":"222", + "code":"225", "des":"Before using pod security admission, understand Kubernetes Pod Security Standards. These standards define different isolation levels for pods. They let you define how you", "doc_type":"usermanual2", "kw":"Configuring Pod Security Admission,Pod Security,User Guide", @@ -4010,11 +4064,29 @@ "title":"Configuring Pod Security Admission", "githuburl":"" }, + { + "uri":"cce_10_1006.html", + "node_id":"cce_10_1006.xml", + "product_code":"cce", + "code":"226", + "des":"Application Armor (AppArmor) is a security module of the Linux kernel, which is usually used in OSs such as Ubuntu. AppArmor allows system administrators to associate eac", + "doc_type":"usermanual2", + "kw":"Using AppArmor to Confine Container Access to Resources,Pod Security,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Using AppArmor to Confine Container Access to Resources", + "githuburl":"" + }, { "uri":"cce_10_0674.html", "node_id":"cce_10_0674.xml", "product_code":"cce", - "code":"223", + "code":"227", "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":"Scheduling", @@ -4032,10 +4104,10 @@ "uri":"cce_10_0702.html", "node_id":"cce_10_0702.xml", "product_code":"cce", - "code":"224", - "des":"CCE supports different types of resource scheduling and task scheduling, improving application performance and overall cluster resource utilization. This section describe", + "code":"228", + "des":"CCE supports multiple resource and task scheduling policies to enhance application performance and overall cluster resource utilization. This section describes the main f", "doc_type":"usermanual2", - "kw":"Overview,Scheduling,User Guide", + "kw":"Scheduling Overview,Scheduling,User Guide", "search_title":"", "metedata":[ { @@ -4043,14 +4115,14 @@ "documenttype":"usermanual" } ], - "title":"Overview", + "title":"Scheduling Overview", "githuburl":"" }, { "uri":"cce_10_0551.html", "node_id":"cce_10_0551.xml", "product_code":"cce", - "code":"225", + "code":"229", "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 Scheduling", @@ -4068,7 +4140,7 @@ "uri":"cce_10_0351.html", "node_id":"cce_10_0351.xml", "product_code":"cce", - "code":"226", + "code":"230", "des":"By default, kubelet uses CFS quotas to enforce pod CPU limits. When a node runs many CPU-bound pods, the workload can move to different CPU cores depending on whether the", "doc_type":"usermanual2", "kw":"CPU Policy,CPU Scheduling,User Guide", @@ -4086,8 +4158,8 @@ "uri":"cce_10_0552.html", "node_id":"cce_10_0552.xml", "product_code":"cce", - "code":"227", - "des":"Kubernetes provides two CPU policies: none and static.none: The CPU policy is disabled by default, indicating the existing scheduling behavior.static: The static CPU core", + "code":"231", + "des":"Kubernetes provides two CPU policies: none and static.none: The CPU policy is disabled by default, indicating the existing scheduling behavior.static: The static CPU pinn", "doc_type":"usermanual2", "kw":"Enhanced CPU Policy,CPU Scheduling,User Guide", "search_title":"", @@ -4104,7 +4176,7 @@ "uri":"cce_10_0720.html", "node_id":"cce_10_0720.xml", "product_code":"cce", - "code":"228", + "code":"232", "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":"GPU Scheduling", @@ -4118,12 +4190,102 @@ "title":"GPU Scheduling", "githuburl":"" }, + { + "uri":"cce_10_0845.html", + "node_id":"cce_10_0845.xml", + "product_code":"cce", + "code":"233", + "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":"GPU Driver Version", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"GPU Driver Version", + "githuburl":"" + }, + { + "uri":"cce_10_0846.html", + "node_id":"cce_10_0846.xml", + "product_code":"cce", + "code":"234", + "des":"Before using GPU-accelerated ECSs, install the necessary NVIDIA infrastructure software to enable accelerated GPU computing. To use GPUs, select and install the appropria", + "doc_type":"usermanual2", + "kw":"Selecting a GPU Driver Version for Nodes,GPU Driver Version,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Selecting a GPU Driver Version for Nodes", + "githuburl":"" + }, + { + "uri":"cce_10_0847.html", + "node_id":"cce_10_0847.xml", + "product_code":"cce", + "code":"235", + "des":"This section describes the recommended driver versions for CCE clusters. If you use a non-recommended GPU driver version, make sure to check its compatibility with the mo", + "doc_type":"usermanual2", + "kw":"Recommended GPU Driver Versions for CCE,GPU Driver Version,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Recommended GPU Driver Versions for CCE", + "githuburl":"" + }, + { + "uri":"cce_10_0848.html", + "node_id":"cce_10_0848.xml", + "product_code":"cce", + "code":"236", + "des":"You can use the CCE AI Suite (NVIDIA GPU) add-on to configure the driver file path for a node. After the node is restarted, the driver will be installed automatically. Al", + "doc_type":"usermanual2", + "kw":"Manually Upgrading the Driver Version of a GPU Node,GPU Driver Version,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Manually Upgrading the Driver Version of a GPU Node", + "githuburl":"" + }, + { + "uri":"cce_10_0849.html", + "node_id":"cce_10_0849.xml", + "product_code":"cce", + "code":"237", + "des":"To ensure proper functioning of GPU nodes, upgrade the NVIDIA driver version if it does not match the CUDA library you use. It is recommended that you use node pools to e", + "doc_type":"usermanual2", + "kw":"Upgrading the Driver Version of a GPU Node Using a Node Pool,GPU Driver Version,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Upgrading the Driver Version of a GPU Node Using a Node Pool", + "githuburl":"" + }, { "uri":"cce_10_0345.html", "node_id":"cce_10_0345.xml", "product_code":"cce", - "code":"229", - "des":"You can use GPUs in CCE containers.A GPU node has been created. For details, see Creating a Node.The CCE AI Suite (NVIDIA GPU) add-on has been installed, with the selecte", + "code":"238", + "des":"CCE standard and Turbo clusters support Kubernetes' default GPU scheduling mode. This mode uses a device plugin to manage GPUs as a standard resource type. After the CCE ", "doc_type":"usermanual2", "kw":"Default GPU Scheduling in Kubernetes,GPU Scheduling,User Guide", "search_title":"", @@ -4136,14 +4298,140 @@ "title":"Default GPU Scheduling in Kubernetes", "githuburl":"" }, + { + "uri":"cce_10_0643.html", + "node_id":"cce_10_0643.xml", + "product_code":"cce", + "code":"239", + "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":"GPU Virtualization", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"GPU Virtualization", + "githuburl":"" + }, + { + "uri":"cce_10_0644.html", + "node_id":"cce_10_0644.xml", + "product_code":"cce", + "code":"240", + "des":"CCE uses xGPU virtualization technologies to dynamically divide the GPU memory and computing power. A single GPU can be virtualized into a maximum of 20 virtual GPU devic", + "doc_type":"usermanual2", + "kw":"Overview,GPU Virtualization,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Overview", + "githuburl":"" + }, + { + "uri":"cce_10_0645.html", + "node_id":"cce_10_0645.xml", + "product_code":"cce", + "code":"241", + "des":"CCE uses xGPU virtualization technologies to dynamically divide the GPU memory and computing power. A single GPU can be virtualized into a maximum of 20 virtual GPU devic", + "doc_type":"usermanual2", + "kw":"Preparing Virtualized GPU Resources,GPU Virtualization,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Preparing Virtualized GPU Resources", + "githuburl":"" + }, + { + "uri":"cce_10_0646.html", + "node_id":"cce_10_0646.xml", + "product_code":"cce", + "code":"242", + "des":"This section describes how to use the GPU virtualization capability to isolate the computing power from the GPU memory and efficiently use GPU device resources.You have p", + "doc_type":"usermanual2", + "kw":"Using GPU Virtualization,GPU Virtualization,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Using GPU Virtualization", + "githuburl":"" + }, + { + "uri":"cce_10_0742.html", + "node_id":"cce_10_0742.xml", + "product_code":"cce", + "code":"243", + "des":"With GPU virtualization enabled, workloads can still use nvidia.com/gpu (Kubernetes' default GPU scheduling) while optionally adding fine-grained isolation via volcano.sh", + "doc_type":"usermanual2", + "kw":"Enabling Kubernetes' Default GPU Scheduling in GPU Virtualization,GPU Virtualization,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Enabling Kubernetes' Default GPU Scheduling in GPU Virtualization", + "githuburl":"" + }, + { + "uri":"cce_10_0965.html", + "node_id":"cce_10_0965.xml", + "product_code":"cce", + "code":"244", + "des":"In AI training, inference, and scientific computing, a single GPU often falls short due to limited compute power or memory. Multiple GPUs are therefore needed to work tog", + "doc_type":"usermanual2", + "kw":"Equal Distribution Scheduling on Virtual GPUs,GPU Virtualization,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Equal Distribution Scheduling on Virtual GPUs", + "githuburl":"" + }, + { + "uri":"cce_10_1016.html", + "node_id":"cce_10_1016.xml", + "product_code":"cce", + "code":"245", + "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":"GPU Monitoring", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"GPU Monitoring", + "githuburl":"" + }, { "uri":"cce_10_0955.html", "node_id":"cce_10_0955.xml", "product_code":"cce", - "code":"230", + "code":"246", "des":"The CCE AI Suite (NVIDIA GPU) add-on provides GPU monitoring metrics. This add-on offers additional GPU observability options. This section describes the metrics provided", "doc_type":"usermanual2", - "kw":"GPU Metrics,GPU Scheduling,User Guide", + "kw":"GPU Metrics,GPU Monitoring,User Guide", "search_title":"", "metedata":[ { @@ -4154,11 +4442,83 @@ "title":"GPU Metrics", "githuburl":"" }, + { + "uri":"cce_10_0741.html", + "node_id":"cce_10_0741.xml", + "product_code":"cce", + "code":"247", + "des":"Monitoring GPU metrics optimizes performance, identifies faults quickly, and allocates resources efficiently. It improves GPU utilization and lowers O&M costs. Using Prom", + "doc_type":"usermanual2", + "kw":"Comprehensive Monitoring of GPU, Virtualization, and Pod Resource Metrics,GPU Monitoring,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Comprehensive Monitoring of GPU, Virtualization, and Pod Resource Metrics", + "githuburl":"" + }, + { + "uri":"cce_10_1017.html", + "node_id":"cce_10_1017.xml", + "product_code":"cce", + "code":"248", + "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":"GPU Auto Scaling", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"GPU Auto Scaling", + "githuburl":"" + }, + { + "uri":"cce_10_0844.html", + "node_id":"cce_10_0844.xml", + "product_code":"cce", + "code":"249", + "des":"In a standard or Turbo cluster, you can configure HPA policies for workloads that use GPU resources based on GPU monitoring metrics. This enables applications to automati", + "doc_type":"usermanual2", + "kw":"Configuring Workload Scaling Based on GPU Monitoring Metrics,GPU Auto Scaling,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Configuring Workload Scaling Based on GPU Monitoring Metrics", + "githuburl":"" + }, + { + "uri":"cce_10_0779.html", + "node_id":"cce_10_0779.xml", + "product_code":"cce", + "code":"250", + "des":"In a Kubernetes environment, managing GPU resources is complex, and diagnosing and recovering from faults can be challenging and costly. When a GPU becomes faulty, the CC", + "doc_type":"usermanual2", + "kw":"GPU Fault Handling,GPU Scheduling,User Guide", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"GPU Fault Handling", + "githuburl":"" + }, { "uri":"cce_10_0423.html", "node_id":"cce_10_0423.xml", "product_code":"cce", - "code":"231", + "code":"251", "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", @@ -4176,10 +4536,10 @@ "uri":"cce_10_0721.html", "node_id":"cce_10_0721.xml", "product_code":"cce", - "code":"232", + "code":"252", "des":"Volcano is a batch processing platform that runs on Kubernetes for machine learning, deep learning, bioinformatics, genomics, and other big data applications. It provides", "doc_type":"usermanual2", - "kw":"Overview,Volcano Scheduling,User Guide", + "kw":"Volcano Scheduling Overview,Volcano Scheduling,User Guide", "search_title":"", "metedata":[ { @@ -4187,14 +4547,14 @@ "documenttype":"usermanual" } ], - "title":"Overview", + "title":"Volcano Scheduling Overview", "githuburl":"" }, { "uri":"cce_10_0722.html", "node_id":"cce_10_0722.xml", "product_code":"cce", - "code":"233", + "code":"253", "des":"Volcano is a Kubernetes-based batch processing platform with high-performance general computing capabilities like task scheduling engine, heterogeneous chip management, a", "doc_type":"usermanual2", "kw":"Scheduling Workloads,Volcano Scheduling,User Guide", @@ -4212,7 +4572,7 @@ "uri":"cce_10_0768.html", "node_id":"cce_10_0768.xml", "product_code":"cce", - "code":"234", + "code":"254", "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":"Resource Usage-based Scheduling", @@ -4230,8 +4590,8 @@ "uri":"cce_10_0773.html", "node_id":"cce_10_0773.xml", "product_code":"cce", - "code":"235", - "des":"Bin packing is an optimization algorithm that aims to properly allocate resources to each job and get the jobs done using the minimum amount of resources. After bin packi", + "code":"255", + "des":"Bin packing is an optimization algorithm that aims to properly allocate resources to each job and get the jobs done using the minimum number of resources. After bin packi", "doc_type":"usermanual2", "kw":"Bin Packing,Resource Usage-based Scheduling,User Guide", "search_title":"", @@ -4248,7 +4608,7 @@ "uri":"cce_10_0766.html", "node_id":"cce_10_0766.xml", "product_code":"cce", - "code":"236", + "code":"256", "des":"Scheduling in a cluster is the process of binding pending pods to nodes, and is performed by a component called kube-scheduler or Volcano Scheduler. The scheduler uses a ", "doc_type":"usermanual2", "kw":"Descheduling,Resource Usage-based Scheduling,User Guide", @@ -4266,7 +4626,7 @@ "uri":"cce_10_0767.html", "node_id":"cce_10_0767.xml", "product_code":"cce", - "code":"237", + "code":"257", "des":"In scenarios such as node pool replacement and rolling node upgrade, an old resource pool needs to be replaced with a new one. To prevent the node pool replacement from a", "doc_type":"usermanual2", "kw":"Node Pool Affinity,Resource Usage-based Scheduling,User Guide", @@ -4284,7 +4644,7 @@ "uri":"cce_10_0789.html", "node_id":"cce_10_0789.xml", "product_code":"cce", - "code":"238", + "code":"258", "des":"Volcano Scheduler offers CPU and memory load-aware scheduling for pods and preferentially schedules pods to the node with the lightest load to balance node loads. This pr", "doc_type":"usermanual2", "kw":"Load-aware Scheduling,Resource Usage-based Scheduling,User Guide", @@ -4302,7 +4662,7 @@ "uri":"cce_10_0813.html", "node_id":"cce_10_0813.xml", "product_code":"cce", - "code":"239", + "code":"259", "des":"Volcano scheduling involves node filtering and scoring, which is used to filter the nodes meeting scheduling conditions and score the filtered nodes to find the one with ", "doc_type":"usermanual2", "kw":"Configuration Cases for Resource Usage-based Scheduling,Resource Usage-based Scheduling,User Guide", @@ -4320,7 +4680,7 @@ "uri":"cce_10_0774.html", "node_id":"cce_10_0774.xml", "product_code":"cce", - "code":"240", + "code":"260", "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":"Priority-based Scheduling", @@ -4338,7 +4698,7 @@ "uri":"cce_10_0775.html", "node_id":"cce_10_0775.xml", "product_code":"cce", - "code":"241", + "code":"261", "des":"A pod priority indicates the importance of a pod relative to other pods. Volcano supports pod PriorityClasses in Kubernetes. After PriorityClasses are configured, the sch", "doc_type":"usermanual2", "kw":"Priority-based Scheduling,Priority-based Scheduling,User Guide", @@ -4356,7 +4716,7 @@ "uri":"cce_10_0776.html", "node_id":"cce_10_0776.xml", "product_code":"cce", - "code":"242", + "code":"262", "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":"AI Performance-based Scheduling", @@ -4374,7 +4734,7 @@ "uri":"cce_10_0777.html", "node_id":"cce_10_0777.xml", "product_code":"cce", - "code":"243", + "code":"263", "des":"Dominant Resource Fairness (DRF) is a scheduling algorithm based on the dominant resource of a container group. DRF scheduling can be used to enhance the service throughp", "doc_type":"usermanual2", "kw":"DRF,AI Performance-based Scheduling,User Guide", @@ -4392,7 +4752,7 @@ "uri":"cce_10_0778.html", "node_id":"cce_10_0778.xml", "product_code":"cce", - "code":"244", + "code":"264", "des":"Gang scheduling is a scheduling algorithm that schedules correlated processes or threads to run simultaneously on different processors. It meets the scheduling requiremen", "doc_type":"usermanual2", "kw":"Gang,AI Performance-based Scheduling,User Guide", @@ -4410,7 +4770,7 @@ "uri":"cce_10_0425.html", "node_id":"cce_10_0425.xml", "product_code":"cce", - "code":"245", + "code":"265", "des":"In non-uniform memory access (NUMA) architecture, a NUMA node is a fundamental component that includes a processor and local memory. These nodes are physically separate b", "doc_type":"usermanual2", "kw":"NUMA Affinity Scheduling,Volcano Scheduling,User Guide", @@ -4428,7 +4788,7 @@ "uri":"cce_10_0709.html", "node_id":"cce_10_0709.xml", "product_code":"cce", - "code":"246", + "code":"266", "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":"Cloud Native Hybrid Deployment", @@ -4446,7 +4806,7 @@ "uri":"cce_10_0384.html", "node_id":"cce_10_0384.xml", "product_code":"cce", - "code":"247", + "code":"267", "des":"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 an", "doc_type":"usermanual2", "kw":"Dynamic Resource Oversubscription,Cloud Native Hybrid Deployment,User Guide", @@ -4464,10 +4824,10 @@ "uri":"cce_10_0020.html", "node_id":"cce_10_0020.xml", "product_code":"cce", - "code":"248", + "code":"268", "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":"Network", + "kw":"Networking", "search_title":"", "metedata":[ { @@ -4475,17 +4835,17 @@ "documenttype":"usermanual" } ], - "title":"Network", + "title":"Networking", "githuburl":"" }, { "uri":"cce_10_0010.html", "node_id":"cce_10_0010.xml", "product_code":"cce", - "code":"249", - "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", + "code":"269", + "des":"The CCE cluster network architecture is based on the Kubernetes native network model. Combined with the cloud infrastructure capabilities, the architecture builds a three", "doc_type":"usermanual2", - "kw":"Overview,Network,User Guide", + "kw":"Networking Overview,Networking,User Guide", "search_title":"", "metedata":[ { @@ -4493,17 +4853,17 @@ "documenttype":"usermanual" } ], - "title":"Overview", + "title":"Networking Overview", "githuburl":"" }, { "uri":"cce_10_0280.html", "node_id":"cce_10_0280.xml", "product_code":"cce", - "code":"250", + "code":"270", "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", + "kw":"Container Networks", "search_title":"", "metedata":[ { @@ -4511,17 +4871,17 @@ "documenttype":"usermanual" } ], - "title":"Container Network", + "title":"Container Networks", "githuburl":"" }, { "uri":"cce_10_0281.html", "node_id":"cce_10_0281.xml", "product_code":"cce", - "code":"251", - "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:Clo", + "code":"271", + "des":"A 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:Cloud", "doc_type":"usermanual2", - "kw":"Overview,Container Network,User Guide", + "kw":"Overview,Container Networks,User Guide", "search_title":"", "metedata":[ { @@ -4536,7 +4896,7 @@ "uri":"cce_10_0678.html", "node_id":"cce_10_0678.xml", "product_code":"cce", - "code":"252", + "code":"272", "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":"Cloud Native Network 2.0 Settings", @@ -4554,8 +4914,8 @@ "uri":"cce_10_0284.html", "node_id":"cce_10_0284.xml", "product_code":"cce", - "code":"253", - "des":"Cloud Native Network 2.0 is a proprietary, next-generation container network model that combines the elastic network interfaces (ENIs) and supplementary network interface", + "code":"273", + "des":"The proprietary, next-generation Cloud Native Network 2.0 combines the network interfaces and supplementary network interfaces of VPC. This allows you to bind network int", "doc_type":"usermanual2", "kw":"Cloud Native Network 2.0,Cloud Native Network 2.0 Settings,User Guide", "search_title":"", @@ -4572,10 +4932,10 @@ "uri":"cce_10_0906.html", "node_id":"cce_10_0906.xml", "product_code":"cce", - "code":"254", - "des":"If the pod subnet configured during CCE Turbo cluster creation cannot meet service expansion requirements, you can add a pod subnet for the cluster.This function is avail", + "code":"274", + "des":"If the pod subnet configured during CCE Turbo cluster creation cannot meet service expansion requirements, you can add a pod subnet for the cluster.This function is only ", "doc_type":"usermanual2", - "kw":"Configuring a Default Container Subnet for a CCE Turbo Cluster,Cloud Native Network 2.0 Settings,Use", + "kw":"Adding or Deleting the Default Pod Subnet of a CCE Turbo Cluster,Cloud Native Network 2.0 Settings,U", "search_title":"", "metedata":[ { @@ -4583,69 +4943,15 @@ "documenttype":"usermanual" } ], - "title":"Configuring a Default Container Subnet for a CCE Turbo Cluster", - "githuburl":"" - }, - { - "uri":"cce_10_0897.html", - "node_id":"cce_10_0897.xml", - "product_code":"cce", - "code":"255", - "des":"In Cloud Native Network 2.0, pods use ENIs or sub-ENIs of the VPC. You can configure a security group for a pod using a pod's annotation.Configure a security group in eit", - "doc_type":"usermanual2", - "kw":"Binding a Security Group to a Pod Using an Annotation,Cloud Native Network 2.0 Settings,User Guide", - "search_title":"", - "metedata":[ - { - "prodname":"cce", - "documenttype":"usermanual" - } - ], - "title":"Binding a Security Group to a Pod Using an Annotation", - "githuburl":"" - }, - { - "uri":"cce_10_0288.html", - "node_id":"cce_10_0288.xml", - "product_code":"cce", - "code":"256", - "des":"In Cloud Native Network 2.0, pods use VPC ENIs or sub-ENIs for networking. You can directly bind security groups and EIPs to pods. To bind CCE pods with security groups, ", - "doc_type":"usermanual2", - "kw":"Binding a Security Group to a Workload Using a Security Group Policy,Cloud Native Network 2.0 Settin", - "search_title":"", - "metedata":[ - { - "prodname":"cce", - "documenttype":"usermanual" - } - ], - "title":"Binding a Security Group to a Workload Using a Security Group Policy", - "githuburl":"" - }, - { - "uri":"cce_10_0196.html", - "node_id":"cce_10_0196.xml", - "product_code":"cce", - "code":"257", - "des":"In a CCE Turbo cluster, you can configure subnets and security groups for containers by namespace or workload using NetworkAttachmentDefinition CRDs. To configure a parti", - "doc_type":"usermanual2", - "kw":"Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configurati", - "search_title":"", - "metedata":[ - { - "prodname":"cce", - "documenttype":"usermanual" - } - ], - "title":"Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration", + "title":"Adding or Deleting the Default Pod Subnet of a CCE Turbo Cluster", "githuburl":"" }, { "uri":"cce_10_0603.html", "node_id":"cce_10_0603.xml", "product_code":"cce", - "code":"258", - "des":"In Cloud Native Network 2.0, each pod is associated with an ENI, providing a static IP address to the StatefulSet pods (container ENI). This is a common practice in acces", + "code":"275", + "des":"In Cloud Native Network 2.0, each pod is assigned a VPC network interface with a static IP address. This is particularly applicable to StatefulSet pods. This practice is ", "doc_type":"usermanual2", "kw":"Configuring a Static IP Address for a Pod,Cloud Native Network 2.0 Settings,User Guide", "search_title":"", @@ -4662,8 +4968,8 @@ "uri":"cce_10_0734.html", "node_id":"cce_10_0734.xml", "product_code":"cce", - "code":"259", - "des":"In Cloud Native Network 2.0, pods use VPC ENIs or sub-ENIs for networking. You can directly bind EIPs to pods.To associate an EIP with a pod, simply set the value of the ", + "code":"276", + "des":"In Cloud Native Network 2.0, pods use VPC elastic network interfaces or supplementary network interfaces for networking. You can directly bind and EIPs to pods.To associa", "doc_type":"usermanual2", "kw":"Configuring an EIP for a Pod,Cloud Native Network 2.0 Settings,User Guide", "search_title":"", @@ -4680,7 +4986,7 @@ "uri":"cce_10_0651.html", "node_id":"cce_10_0651.xml", "product_code":"cce", - "code":"260", + "code":"277", "des":"In Cloud Native Network 2.0, static public IP addresses (EIPs) can be assigned to StatefulSets or pods created directly.You can configure a static EIP for a pod only in C", "doc_type":"usermanual2", "kw":"static EIPs,Configuring a Static EIP for a Pod,Cloud Native Network 2.0 Settings,User Guide", @@ -4698,10 +5004,10 @@ "uri":"cce_10_0604.html", "node_id":"cce_10_0604.xml", "product_code":"cce", - "code":"261", - "des":"By default, pods with IPv6 dual-stack ENIs can access only the IPv6 private network. To access the public network, configure shared bandwidth for such pods.Only CCE Turbo", + "code":"278", + "des":"By default, pods with IPv6 dual-stack network interfaces can access only the IPv6 private network. To access the public network, configure shared bandwidth for such pods.", "doc_type":"usermanual2", - "kw":"Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack ENIs,Cloud Native Network 2.0 Settings,U", + "kw":"Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack Network Interfaces,Cloud Native Network ", "search_title":"", "metedata":[ { @@ -4709,14 +5015,119 @@ "documenttype":"usermanual" } ], - "title":"Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack ENIs", + "title":"Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack Network Interfaces", + "githuburl":"" + }, + { + "uri":"cce_10_1077.html", + "node_id":"cce_10_1077.xml", + "product_code":"cce", + "code":"279", + "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 Security Group for a Workload in a CCE Turbo Cluster", + "search_title":"", + "metedata":[ + { + + } + ], + "title":"Configuring a Security Group for a Workload in a CCE Turbo Cluster", + "githuburl":"" + }, + { + "uri":"cce_10_1078.html", + "node_id":"cce_10_1078.xml", + "product_code":"cce", + "code":"280", + "des":"In CCE Turbo clusters, pods can be directly bound to security groups using VPC network interfaces or supplementary network interfaces. CCE Turbo provides multi-dimensiona", + "doc_type":"usermanual2", + "kw":"Comparison of Workload Security Group Configuration Methods,Configuring a Security Group for a Workl", + "search_title":"", + "metedata":[ + { + + } + ], + "title":"Comparison of Workload Security Group Configuration Methods", + "githuburl":"" + }, + { + "uri":"cce_10_0897.html", + "node_id":"cce_10_0897.xml", + "product_code":"cce", + "code":"281", + "des":"In cloud native network 2.0, pods use VPC network interfaces or supplementary network interfaces for networking, which allow you to configure security groups. You can bin", + "doc_type":"usermanual2", + "kw":"Binding a Security Group to a Pod Using an Annotation,Configuring a Security Group for a Workload in", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Binding a Security Group to a Pod Using an Annotation", + "githuburl":"" + }, + { + "uri":"cce_10_0288.html", + "node_id":"cce_10_0288.xml", + "product_code":"cce", + "code":"282", + "des":"In Cloud Native Network 2.0, pods use VPC elastic network interfaces or supplementary network interfaces for networking. You can directly bind security groups and EIPs to", + "doc_type":"usermanual2", + "kw":"Binding a Security Group to a Workload Using a Security Group Policy,Configuring a Security Group fo", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Binding a Security Group to a Workload Using a Security Group Policy", + "githuburl":"" + }, + { + "uri":"cce_10_1079.html", + "node_id":"cce_10_1079.xml", + "product_code":"cce", + "code":"283", + "des":"In Cloud Native Network 2.0, pods can be directly bound to security groups using VPC network interfaces or supplementary network interfaces. CCE Turbo allows you to confi", + "doc_type":"usermanual2", + "kw":"Using Node Pool Settings to Bind the Default Security Group to Pods in the Node Pool,Configuring a S", + "search_title":"", + "metedata":[ + { + + } + ], + "title":"Using Node Pool Settings to Bind the Default Security Group to Pods in the Node Pool", + "githuburl":"" + }, + { + "uri":"cce_10_0196.html", + "node_id":"cce_10_0196.xml", + "product_code":"cce", + "code":"284", + "des":"In a CCE Turbo cluster, you can configure subnets and security groups for containers by namespace or workload using NetworkAttachmentDefinition CRDs. To configure a parti", + "doc_type":"usermanual2", + "kw":"Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configurati", + "search_title":"", + "metedata":[ + { + "prodname":"cce", + "documenttype":"usermanual" + } + ], + "title":"Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration", "githuburl":"" }, { "uri":"cce_10_0904.html", "node_id":"cce_10_0904.xml", "product_code":"cce", - "code":"262", + "code":"285", "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":"VPC Network Settings", @@ -4734,7 +5145,7 @@ "uri":"cce_10_0283.html", "node_id":"cce_10_0283.xml", "product_code":"cce", - "code":"263", + "code":"286", "des":"The VPC network model seamlessly combines VPC routing with the underlying network, making it ideal for high-performance scenarios. However, the maximum number of nodes al", "doc_type":"usermanual2", "kw":"VPC Network Model,VPC Network Settings,User Guide", @@ -4752,10 +5163,10 @@ "uri":"cce_10_0680.html", "node_id":"cce_10_0680.xml", "product_code":"cce", - "code":"264", + "code":"287", "des":"If the container CIDR block configured during CCE cluster creation cannot meet service expansion requirements, you can add a container CIDR block for the cluster.This fun", "doc_type":"usermanual2", - "kw":"Adding a Container CIDR Block for a Cluster,VPC Network Settings,User Guide", + "kw":"Expanding the Container CIDR Block of a Cluster That Uses a VPC Network,VPC Network Settings,User Gu", "search_title":"", "metedata":[ { @@ -4763,14 +5174,14 @@ "documenttype":"usermanual" } ], - "title":"Adding a Container CIDR Block for a Cluster", + "title":"Expanding the Container CIDR Block of a Cluster That Uses a VPC Network", "githuburl":"" }, { "uri":"cce_10_0677.html", "node_id":"cce_10_0677.xml", "product_code":"cce", - "code":"265", + "code":"288", "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":"Tunnel Network Settings", @@ -4788,8 +5199,8 @@ "uri":"cce_10_0282.html", "node_id":"cce_10_0282.xml", "product_code":"cce", - "code":"266", - "des":"A container tunnel network creates a separate network plane for containers by using tunnel encapsulation on the host network plane. The container tunnel network of a CCE ", + "code":"289", + "des":"A container tunnel network creates a separate network plane for containers by using tunnel encapsulation on the host network plane. This network model uses VXLAN for tunn", "doc_type":"usermanual2", "kw":"Tunnel Network Model,Tunnel Network Settings,User Guide", "search_title":"", @@ -4806,7 +5217,7 @@ "uri":"cce_10_0675.html", "node_id":"cce_10_0675.xml", "product_code":"cce", - "code":"267", + "code":"290", "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":"Pod Network Settings", @@ -4824,8 +5235,8 @@ "uri":"cce_10_0402.html", "node_id":"cce_10_0402.xml", "product_code":"cce", - "code":"268", - "des":"Kubernetes allows pods to directly use the host/node network. When a pod is configured with hostNetwork: true, applications running in the pod can directly view the netwo", + "code":"291", + "des":"Generally, containers in a pod use the network set up using Kubernetes network plugins. These plugins ensure network communications between pods. However, you may need to", "doc_type":"usermanual2", "kw":"Configuring hostNetwork for Pods,Pod Network Settings,User Guide", "search_title":"", @@ -4842,7 +5253,7 @@ "uri":"cce_10_0382.html", "node_id":"cce_10_0382.xml", "product_code":"cce", - "code":"269", + "code":"292", "des":"Bandwidth preemption occurs between different containers deployed on the same node, which may cause service jitter. You can configure bandwidth limitation for the pod to ", "doc_type":"usermanual2", "kw":"Configuring QoS for a Pod,Pod Network Settings,User Guide", @@ -4860,8 +5271,8 @@ "uri":"cce_10_0059.html", "node_id":"cce_10_0059.xml", "product_code":"cce", - "code":"270", - "des":"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 ", + "code":"293", + "des":"Network policies are designed by Kubernetes to restrict pod access. Like a firewall at the application layer, network policies enhance network security. The capabilities ", "doc_type":"usermanual2", "kw":"Configuring Network Policies to Restrict Pod Access,Pod Network Settings,User Guide", "search_title":"", @@ -4878,8 +5289,8 @@ "uri":"cce_10_0945.html", "node_id":"cce_10_0945.xml", "product_code":"cce", - "code":"271", - "des":"DataPlane V2 can be enabled for clusters that use Cloud Native 2.0 networks. After this function is enabled, eBPF redirection will be enabled for the capability of networ", + "code":"294", + "des":"DataPlane V2 can be enabled for clusters that use VPC networks or Cloud Native 2.0 networks. Once enabled, eBPF redirection is supported, which allows the use of network ", "doc_type":"usermanual2", "kw":"DataPlane V2 Network Acceleration,Pod Network Settings,User Guide", "search_title":"", @@ -4896,10 +5307,10 @@ "uri":"cce_10_0247.html", "node_id":"cce_10_0247.xml", "product_code":"cce", - "code":"272", + "code":"295", "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", + "kw":"Services", "search_title":"", "metedata":[ { @@ -4907,17 +5318,17 @@ "documenttype":"usermanual" } ], - "title":"Service", + "title":"Services", "githuburl":"" }, { "uri":"cce_10_0249.html", "node_id":"cce_10_0249.xml", "product_code":"cce", - "code":"273", - "des":"After a pod is created, accessing it directly can result in certain problems:The pod can be deleted and recreated at any time by a controller such as a Deployment. If the", + "code":"296", + "des":"In Kubernetes, a Service makes an application running on a set of pods network-accessible. It provides a consistent DNS name for these pods and distributes traffic across", "doc_type":"usermanual2", - "kw":"Overview,Service,User Guide", + "kw":"kube-proxy,iptables,IPVS,Service Overview,Services,User Guide", "search_title":"", "metedata":[ { @@ -4925,17 +5336,17 @@ "documenttype":"usermanual" } ], - "title":"Overview", + "title":"Service Overview", "githuburl":"" }, { "uri":"cce_10_0011.html", "node_id":"cce_10_0011.xml", "product_code":"cce", - "code":"274", - "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

Solution

Do not run an untrusted container image in the cluster before the vulnerabilities are fixed.

-

CCE will release a new version of the add-on to fix these vulnerabilities. For details, see CCE AI Suite (NVIDIA GPU) Release History.

+

CCE has released a new version of the CCE AI Suite (NVIDIA GPU) add-on to fix these vulnerabilities. Upgrade the add-on to the fixed version. For details, see CCE AI Suite (NVIDIA GPU) Release History.

Helpful Links

NVIDIA Container Toolkit Security Bulletin: https://nvidia.custhelp.com/app/answers/detail/a_id/5659

diff --git a/docs/cce/umn/cce_01_0300.html b/docs/cce/umn/cce_01_0300.html index 64e8fb822..182de047c 100644 --- a/docs/cce/umn/cce_01_0300.html +++ b/docs/cce/umn/cce_01_0300.html @@ -8,7 +8,16 @@ -

2025-07-25

+

2025-09-12

+ +

Add:

+ +

Update:

+ + + +

2025-07-25

Added Notice of the NVIDIA Container Toolkit Container Escape Vulnerabilities (CVE-2025-23266 and CVE-2025-23267).

@@ -48,7 +57,7 @@

2025-03-31

Update:

- +

2025-03-10

diff --git a/docs/cce/umn/cce_10_0003.html b/docs/cce/umn/cce_10_0003.html index 918af2b25..1663fcf25 100644 --- a/docs/cce/umn/cce_10_0003.html +++ b/docs/cce/umn/cce_10_0003.html @@ -4,11 +4,11 @@

Scenario

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 node. If a node is unavailable because you modify the node configuration, you can reset the node to rectify the fault.

-

Notes and Constraints

  • To enable node resetting in CCE standard clusters or CCE Turbo clusters, the version must be v1.13 or later.
+

Notes and Constraints

  • Node resetting in CCE standard clusters or CCE Turbo clusters is supported for cluster versions v1.13 and later.
-

Precautions

  • Only worker nodes can be reset. If the node is still unavailable after the resetting, delete the node and create a new one.
  • After a node is reset, the node OS will be reinstalled. Before resetting a node, drain the node to gracefully evict the pods running on the node to other available nodes. Perform this operation during off-peak hours.
  • After a node is reset, its system disk and data disks will be cleared. Back up important data before resetting a node.
  • If you reset a worker node that has an additional data disk attached on the ECS console, the attachment will be removed. To keep the data, you need to reattach the disk.
  • The IP addresses of the workload pods on the node will change, but the container network access is not affected.
  • There is remaining EVS disk quota.
  • When a node is reset, the backend will make it unschedulable.
  • Resetting a node will clear the Kubernetes labels and taints you added (those added by editing a node pool will not be lost). As a result, node-specific resources (such as local storage and workloads scheduled to this node) may be unavailable.
  • Resetting a node will cause PVC/PV data loss for the local PV associated with the node. These PVCs and PVs cannot be restored or used again. In this scenario, the pod that uses the local PV is evicted from the node. A new pod is created and stays in the pending state. This is because the PVC used by the pod has a node label, due to which the pod cannot be scheduled. After the node is reset, the pod may be scheduled to the reset node. In this case, the pod remains in the creating state because the underlying logical volume corresponding to the PVC does not exist.
+

Precautions

  • Only worker nodes can be reset. If the node is still unavailable after the resetting, delete the node and create a new one.
  • After a node is reset, its OS will be reinstalled. Before resetting a node, drain it to gracefully evict the pods running on the node to other available nodes. Perform this operation during off-peak hours. If pods remain when the node is reset, CCE will evict them. If a Pod Disruption Budget (PDB) policy is configured for your pods, they may fail to be evicted. In this case, the node will be forcibly reset after a period of time.
  • After a node is reset, its system disk and data disks will be cleared. Back up important data before resetting a node.
  • If an ECS node has a raw data disk attached (not using LVM), detach it before resetting the node. After resetting, the original attachment information will be cleared. Re-attach the disk to the ECS node to retain the data.
  • The IP addresses of the workload pods on the node will change, but the container network access is not affected.
  • There is remaining EVS disk quota.
  • When a node is reset, the backend will make it unschedulable.
  • Resetting a node will clear the Kubernetes labels and taints you added (those added by editing a node pool will not be lost). As a result, node-specific resources (such as local storage and workloads scheduled to this node) may be unavailable.
  • Resetting a node will cause PVC/PV data loss for the local PV associated with the node. These PVCs and PVs cannot be restored or used again. In this scenario, the pod that uses the local PV is evicted from the node. A new pod is created and stays in the pending state. This is because the PVC used by the pod has a node label, due to which the pod cannot be scheduled. After the node is reset, the pod may be scheduled to the reset node. In this case, the pod remains in the creating state because the underlying logical volume corresponding to the PVC does not exist.
-

Resetting Nodes in the Default Pool

  1. Log in to the CCE console and click the cluster name to access the cluster console.
  2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
  3. In the node list of the default pool, select one or more nodes to be reset and choose More > Reset Node in the Operation column.
  4. In the displayed dialog box, click Next.
  5. Specify node parameters.

    Compute Settings +

    Resetting Nodes in the Default Pool

    1. Log in to the CCE console and click the cluster name to access the cluster console.
    2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
    3. In the node list of the default pool, select one or more nodes to be reset and choose More > Reset Node in the Operation column.
    4. In the displayed dialog box, click Next.
    5. Specify node parameters.

      Compute Settings
      - @@ -112,14 +112,16 @@ - - @@ -130,7 +132,7 @@

      Resetting Nodes in a Node Pool

      • When resetting a node in a node pool, you can only change its storage configuration. All other configurations will follow the settings of the node pool.
      • Resetting a node will execute the pre- and post-installation scripts in the current node pool and update the security group configurations to those of the node pool.
      -
      1. Log in to the CCE console and click the cluster name to access the cluster console.
      2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
      3. In the node list of the target node pool, select a node to be reset and choose More > Reset Node in the Operation column.
      4. Modify the node storage parameters.

        +

        1. Log in to the CCE console and click the cluster name to access the cluster console.
        2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
        3. In the node list of the target node pool, select a node to be reset and choose More > Reset Node in the Operation column.
        4. Modify the node storage parameters.

      Table 1 Configuration parameters

      Parameter

      Description

      @@ -67,9 +67,9 @@

      Data Disk

      • At least one default data disk must be added for storing container runtime and kubelet components if System Component Storage is set to Data Disk. This data disk cannot be deleted or detached. Otherwise, the node will be unavailable. This function is available for clusters of a version earlier than v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, or v1.29.4-r0.
      • If System Component Storage is set to System Disk, you do not need to add a default data disk. In this case, all data disks are common ones: You can set the data disk size to a value ranging from 10 GiB to 32768 GiB. The default value is 100 GiB. This function is available for clusters of v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0, or later versions.
      +
      • At least one default data disk must be added for storing container runtime and kubelet components if System Component Storage is set to Data Disk. This data disk cannot be deleted or detached. Otherwise, the node will be unavailable.
      • If System Component Storage is set to System Disk, you do not need to add a default data disk. In this case, all data disks are common ones: You can set the data disk size to a value ranging from 10 GiB to 32768 GiB. The default value is 100 GiB. This function is available for clusters of v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0, or later versions.

      Click Expand to configure Data Disk Space Allocation. This allocates space for container engines, images, and ephemeral storage to ensure their proper running. For details about how to allocate data disk space, see Space Allocation of a Data Disk.

      -

      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. Data disks can also be used as local PVs or local EVs.

      +

      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.

      Pre-installation Command

      Installation script command, in which Chinese characters are not allowed. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

      +

      Installation script command. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

      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

      Installation script command, in which Chinese characters are not allowed. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

      -

      The script will be executed after Kubernetes software is installed, which does not affect the installation.

      +

      Installation script command. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

      +
      The script will be executed after Kubernetes software is installed, which does not affect the installation. During post-installation script execution, pods can be scheduled normally. However, if the script execution times out, node installation will fail. To prevent pods from being scheduled to nodes with incomplete script execution, enable the option to schedule pods only after the post-installation script execution completes.
      CAUTION:

      Do not use the reboot command in the post-installation script to restart the system immediately. Instead, use the shutdown -r 1 command to restart the system with a one-minute delay.

      +
      +
      - @@ -94,7 +94,7 @@
      Table 4 Configuration parameters

      Parameter

      Description

      diff --git a/docs/cce/umn/cce_10_0004.html b/docs/cce/umn/cce_10_0004.html index d0603b5f5..a95557391 100644 --- a/docs/cce/umn/cce_10_0004.html +++ b/docs/cce/umn/cce_10_0004.html @@ -29,7 +29,7 @@

      New: node.kubernetes.io/baremetal

      Old: failure-domain.beta.kubernetes.io/is-baremetal

      Whether the node is a bare metal node

      +

      Whether it is a bare metal node

      false indicates that the node is not a bare metal node.

      -

      Adding or Deleting a Node Label

      1. Log in to the CCE console and click the cluster name to access the cluster console.
      2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab, select the target node and click Labels and Taints in the upper left corner.
      3. In the displayed dialog box, click Add operation under Batch Operation, and then choose Add/Update or Delete.

        Enter the key and value of the label to be added or deleted, and click OK.

        +

        Adding or Deleting a Node Label

        1. Log in to the CCE console and click the cluster name to access the cluster console.
        2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab, select the target node and click Labels and Taints in the upper left corner.
        3. In the displayed dialog box, click Add operation under Batch Operation, and then choose Add/Update or Delete.

          Enter the key and value of the label to be added or deleted, and click OK.

          For example, the key is deploy_qa and the value is true, indicating that the node is used to deploy the QA (test) environment.

        4. After the label is added, check the added label in node data.
        diff --git a/docs/cce/umn/cce_10_0006.html b/docs/cce/umn/cce_10_0006.html index 428e6f516..9c0e119a6 100644 --- a/docs/cce/umn/cce_10_0006.html +++ b/docs/cce/umn/cce_10_0006.html @@ -1,6 +1,6 @@ -

        Overview

        +

        Workload Overview

        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 in Kubernetes are classified as Deployments, StatefulSets, DaemonSets, jobs, and cron jobs.

        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.

        Overview of Pods

        Pods are the smallest unit that you can create or deploy in Kubernetes. Each pod comprises one or more containers, shared storage (volumes), a unique IP address, and container runtime policies.

        diff --git a/docs/cce/umn/cce_10_0007.html b/docs/cce/umn/cce_10_0007.html index 58a09e8bc..f07fbe6c8 100644 --- a/docs/cce/umn/cce_10_0007.html +++ b/docs/cce/umn/cce_10_0007.html @@ -1,7 +1,7 @@

        Managing Workloads

        -

        Scenario

        After a workload is created, you can upgrade, log, monitor, roll back, or delete the workload, as well as edit its YAML file. +

        Scenario

        After a workload is created, you can upgrade it, edit its YAML file, view logs and monitoring data, roll it back, and delete it.
        -
        Table 1 Workload/Job management

        Operation

        Description

        @@ -10,7 +10,7 @@

        Monitor

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

        +

        You can view the CPU and memory usage of workloads and pods on the CCE console to determine the resource specifications you may need.

        View Log

        @@ -71,52 +71,52 @@

        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.
        +
        1. Log in to the CCE console, go to the console of 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.

        Before viewing logs, ensure that the time of the browser is the same as that on the backend server.

        -
        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 View Log of the target workload.

          In the displayed View Log window, you can view logs.

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

            In the displayed View Log window, you can view logs.

            The displayed logs are standard output logs of containers and do not have persistence and advanced O&M capabilities. To use more comprehensive log capabilities, see Logs. If the function of collecting standard output is enabled for the workload (enabled by default), you can go to AOM to view more workload logs. For details, see Collecting Container Logs Using ICAgent.

        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 Processing.
          +

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

          +
          1. Log in to the CCE console,go to the console of 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 Processing.

          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 YAML files of Deployments, StatefulSets, DaemonSets, CronJobs, and pods on the CCE console. YAML files of 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 OK.
          4. (Optional) In the Edit YAML window, click Download to download the YAML file.
          +
          1. Log in to the CCE console, go to the console of 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 OK.
          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 and 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.
          +
          1. Log in to the CCE console, go to the console of an existing cluster, and choose Workloads in the navigation pane.
          2. Click the Deployments tab and 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.
          +
          1. Log in to the CCE console, go to the console of 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.

          • 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.

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

          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 the console of 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. You can manage and select workloads by labels. You can add labels to multiple workloads or a specified 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 > Manage Label in the Operation column of the target workload.
          3. Click , 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. You can manage and select workloads by labels. You can add labels to multiple workloads or a specified workload.

            +
            1. Log in to the CCE console, go to the console of 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 , 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. 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.

              +
              1. Log in to the CCE console, go to the console of 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.

            Events

            This section uses a Deployment as an example to describe how to view events of a workload. To view the event of a job or CronJob, 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.

              +
              1. Log in to the CCE console, go to the console of 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_0009.html b/docs/cce/umn/cce_10_0009.html index a6e865329..16668e56c 100644 --- a/docs/cce/umn/cce_10_0009.html +++ b/docs/cce/umn/cce_10_0009.html @@ -1,30 +1,145 @@

              Using Third-Party Images

              -

              Scenario

              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 authentication (using your account and password). CCE uses the secret-based authentication to pull images. Therefore, create a secret for an image repository before pulling images from the repository.

              +

              Third-party images are container images provided by organizations or individuals other than the official image repository and SWR image repository. These images typically contain custom applications, tools, or specific versions of OSs to meet particular service requirements. In a CCE standard or Turbo cluster, you can create workloads using third-party images pulled through secret authentication. For more information, see Images | Kubernetes.

              +

              Prerequisites

              If third-party images are used, the CCE standard or Turbo cluster must be able to access the network environment where the third-party image repository is deployed. The network access types include:

              +
              • Intranet: If the third-party image repository supports intranet access, consider the following scenarios:
                • If the third-party image repository is in the same VPC as the cluster, pods can directly pull images over the intranet without additional configurations.
                • If the third-party image repository and the cluster are in different VPCs in the same region, you can use a VPC peering connection to enable network connectivity between the two VPCs. Pods can then directly pull images over the intranet.
                +
              • Internet: If the third-party image repository is accessible over the Internet, pods can pull images directly. In this case, ensure the pods can access the Internet using one of the following methods:

                Ensure sufficient bandwidth when pulling images over the Internet. Insufficient bandwidth may cause slow or failed image pulls.

                +
                +
                • In a standard or Turbo cluster, configure an SNAT rule to enable all pods in the cluster to access the Internet. After the configuration, pods can pull images directly over the Internet. For details, see Accessing the Internet from a Container.
                • In a standard cluster, bind an EIP to the node running the workload. This allows all workloads on that node to access the Internet.
                +
              • Direct Connect or VPN: To use images from an on-premises image repository, use Direct Connect or VPN to connect the on-premises network to the cluster's VPC. Once the network environment is connected to the VPC, no additional configuration is needed.
              -

              Prerequisites

              The node where the workload is running is accessible from public networks.

              +

              Using the Console

              To create a secret on the console and pull a third-party image to create a workload, follow these steps.

              +
              1. Create a cluster secret to authenticate and pull images from a third-party repository if authentication is required.

                1. Log in to the CCE console.
                2. Click the name of the target cluster to access the cluster.
                3. In the navigation pane, choose ConfigMaps and Secrets. On the Secrets tab, click Create Secret.
                4. In the Create Secret dialog box, configure parameters based on Table 1. For more details, see Creating a Secret.
                +

                + +
                + + + + + + + + + + + + + + + + + +
                Table 1 Parameters for creating a secret

                Parameter

                +

                Example Value

                +

                Description

                +

                Name

                +

                test

                +

                Name for the secret.

                +

                Enter up to 253 characters, starting and ending with a lowercase letter or digit. Only lowercase letters, digits, hyphens (-), and periods (.) are allowed.

                +

                Secret Type

                +

                kubernetes.io/dockerconfigjson

                +

                Type of the secret.

                +

                The value is fixed at kubernetes.io/dockerconfigjson, indicating that the secret is used for authentication when third-party images are pulled.

                +

                Data

                +

                Image Repository Address: www.example.com

                +

                Username: ssl

                +

                Password: xxx

                +
                • Image Repository Address: Enter the address of the third-party image repository.
                • Username: Enter the username for accessing the third-party image repository.
                • Password: Enter the password for accessing the third-party image repository.
                +
                -

                Using the Console

                1. Create a secret for accessing a third-party image repository.

                  Click the cluster name to access the cluster console. In the navigation pane, choose ConfigMaps and Secrets. On the Secrets tab page, click Create Secret in the upper right corner. Set Secret Type to kubernetes.io/dockerconfigjson. For details, see Creating a Secret.

                  -

                  Enter the username and password used to access the third-party image repository.

                  -

                2. When creating a workload, enter a private image path in the format of domainname/namespace/imagename:tag in Image Name and select the key created in 1.
                3. Set other parameters and click Create Workload.
                +

              2. In the navigation pane, choose Workloads. In the upper right corner of the displayed page, click Create Workload. On the Create Workload page, set Image Name (Container Settings > Container Information > Basic Info) to the third-party image path. Select the secret created in 1 for Image Access Credential.

                If you do not specify a domain name when entering a third-party image address, for example, nginx:latest, the image will be pulled from docker.io by default. To specify the default image pull address, configure the Modify Image Repository Configuration parameter in the container engine configuration of the node pool.

                +
                +

                +

              3. Configure other parameters and click Create Workload. If the workload status is Running, the third-party image has been pulled.
              -

              Using kubectl

              1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
              2. Use kubectl to create a secret of the kubernetes.io/dockerconfigjson.

                kubectl create secret docker-registry myregistrykey  -n default --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
                -

                In the preceding command, myregistrykey indicates the key name, default indicates the namespace where the key is located, and other parameters are as follows:

                -
                • DOCKER_REGISTRY_SERVER: address of a third-party image repository, for example, www.3rdregistry.com or 10.10.10.10:443
                • DOCKER_USER: account used for logging in to a third-party image repository
                • DOCKER_PASSWORD: password used for logging in to a third-party image repository
                • DOCKER_EMAIL: email of a third-party image repository
                -

              3. Use a third-party image to create a workload.

                A kubernetes.io/dockerconfigjson secret is used for authentication when you obtain a private image. The following is an example of using the myregistrykey for authentication.
                apiVersion: v1
                -kind: Pod
                +

                Using kubectl

                1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
                2. If the third-party image repository has an account and password, you need to create a secret in the cluster as the identity credential for pulling images.

                  1. Create a secret. The secret type is kubernetes.io/dockerconfigjson by default, which indicates that the secret is used for authentication when third-party images are pulled.
                    kubectl create secret docker-registry test  -n default --docker-server=www.example.com --docker-username=ssl --docker-password=xxx --docker-email=example@123.com
                    +

                    In the command, test indicates the secret name, default indicates the namespace where the secret is located, and other parameters are described in the following table.

                    + +
                    + + + + + + + + + + + + + + + + + + + + + +
                    Table 2 Secret parameters

                    Parameter

                    +

                    Example Value

                    +

                    Description

                    +

                    docker-server

                    +

                    www.example.com

                    +

                    Enter the address of the third image repository.

                    +

                    docker-username

                    +

                    ssl

                    +

                    Enter the username for accessing the third-party image repository.

                    +

                    docker-password

                    +

                    xxx

                    +

                    Enter the password for accessing the third-party image repository.

                    +

                    docker-email

                    +

                    example@123.com

                    +

                    Email address of the third-party image repository. This parameter is optional.

                    +
                    +
                    +

                    Information similar to the following is displayed:

                    +
                    secret/test created
                    +
                  2. Check whether the secret has been created.
                    kubectl get secret
                    +

                    If the following information is displayed, the secret has been created:

                    +
                    NAME             TYPE                             DATA   AGE
                    +default-secret   kubernetes.io/dockerconfigjson   1      41h
                    +paas.elb         cfe/secure-opaque                1      41h
                    +test             kubernetes.io/dockerconfigjson   1      16s
                    +
                  +

                3. Create a workload using a third-party image.

                  1. Create a YAML file for creating a workload. In this example, the file name is deployment.yaml. You can change it as needed.
                    vim deployment.yaml
                    +
                    The file content is as follows:
                    apiVersion: apps/v1
                    +kind: Deployment
                     metadata:
                    -  name: foo
                    -  namespace: default
                    +  name: foo
                    +  namespace: default
                     spec:
                    -  containers:
                    -    - name: foo
                    -      image: www.3rdregistry.com/janedoe/awesomeapp:v1
                    -  imagePullSecrets:
                    -    - name: myregistrykey              # Use the created secret.
                    + replicas: 1 + selector: + matchLabels: + app: foo + strategy: + type: RollingUpdate + template: + metadata: + labels: + app: foo + spec: + containers: + - image: www.example.com/janedoe/awesomeapp:v1 # Third-party image path + imagePullPolicy: Always + name: foo + imagePullSecrets: + - name: test # Use the created secret for identity authentication when images are pulled.
                +

                If you do not specify a domain name when entering a third-party image address, for example, nginx:latest, the image will be pulled from docker.io by default. To specify the default image pull address, configure the Modify Image Repository Configuration parameter in the container engine configuration of the node pool.

                +
                +
              4. Create the workload.
                kubectl create -f deployment.yaml
                +

                If information similar to the following is displayed, the workload is being created:

                +
                deployment.apps/foo created
                +
              5. Check the workload status.
                kubectl get deployment
                +

                If all the pods of the workload are available, the workload has been created.

                +
                NAME     READY   UP-TO-DATE   AVAILABLE   AGE
                +foo      1/1     1            1           4m59s
                +

            diff --git a/docs/cce/umn/cce_10_0010.html b/docs/cce/umn/cce_10_0010.html index a99833169..23d0965f6 100644 --- a/docs/cce/umn/cce_10_0010.html +++ b/docs/cce/umn/cce_10_0010.html @@ -1,38 +1,41 @@ -

            Overview

            -

            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. 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 number is also affected by the container network. For details, see the container network model.

              -
            • Container Network

              A container network assigns IP addresses to pods 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:

              -
              • Container tunnel network: 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.
              • VPC network: The VPC network model seamlessly combines VPC routing with the underlying network, making it ideal for high-performance scenarios. However, the maximum number of nodes allowed in a cluster is determined by the VPC route quota. Each node is assigned a CIDR block of a fixed size. The VPC network model outperforms the container tunnel network model in terms of performance because it does not have tunnel encapsulation overhead. 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.
              • Developed by CCE, Cloud Native Network 2.0 deeply integrates Elastic Network Interfaces (ENIs) and Sub Network Interfaces (sub-ENIs) of 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 EIPs are bound to deliver high performance.
              -

              The performance, networking scale, and application scenarios of a container network vary according to the container network model. For details about the functions and features of different container network models, see Overview.

              -
            • Service Network

              Service is also a Kubernetes object. Each Service has a static IP address. When creating a cluster on CCE, you can specify the Service CIDR block. The Service CIDR block cannot overlap with the node or container CIDR block. The Service CIDR block can be used only within a cluster.

              -
            +

            Networking Overview

            +

            The CCE cluster network architecture is based on the Kubernetes native network model. Combined with the cloud infrastructure capabilities, the architecture builds a three-layer communication system covering nodes, containers, and services. It is built to efficiently forward intra-cluster and inter-cluster traffic, discover services, and isolate networks. It meets the requirements of all scenarios that cover small- and medium-sized applications and large-scale microservice architectures.

            +

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

            +
            • Cluster network structure (Cluster Network Structure): A cluster consists of multiple nodes, and each node runs multiple pods (containers). To ensure the communications between nodes, between nodes and pods, and between pods, a cluster requires:
              • A node network: enables all nodes in a cluster to communicate with each other.
              • A container network: enables all pods in a cluster to communicate with each other using IP addresses without NAT.
              • A Service network: ensures Services in a cluster can be accessed by other pods or Services in that cluster through stable virtual IP addresses.
              +
            • Pod access in a cluster: Kubernetes provides Services (Service) and ingresses (Ingress) for pod access. This section summarizes common network access scenarios. You can select the appropriate scenario based on site requirements. For details about the network access scenarios, see Access Scenarios.
            +

            Cluster Network Structure

            Cluster networks are the core of Kubernetes. They ensure that containers in a cluster can communicate with each other and with external systems. There are:

            +
            • Node network: CCE uses VPC subnets as the node network of a cluster. The available IP addresses of a subnet limit the maximum number of nodes that can be created in a cluster. For example, a subnet with a mask of /24 can allocate a maximum of 254 node IP addresses. The number of nodes that can be created in a cluster is also affected by the container network. For details, see container network models.
            • Container network: Pods in a cluster are allocated independent IP addresses. All pods in a cluster are on a flat network and can be accessed using their IP addresses without NAT. Kubernetes uses Container Network Interface (CNI) to standardize the network between containers. Network model plugins are used to allocate independent IP addresses to pods for flat network communications in a cluster. Different network models have different allocation principles.
              Figure 1 Container network
              +

              Currently, CCE supports the following container network models:

              +
              • Container tunnel network: This network model is constructed based on the node network through tunnel encapsulation, but it is independent of the node network. It uses VXLAN to encapsulate Ethernet packets into UDP packets and transmits them in tunnels. Open vSwitch serves as the backend virtual switch.
              • VPC network: This network model seamlessly combines VPC routing with the underlying network, making it ideal for high-performance scenarios. However, the maximum number of nodes allowed in a cluster is determined by the VPC route quota. Each node in a cluster that uses a VPC network is running in a subnet with a fixed number of IP addresses. The VPC network model outperforms the container tunnel network model in terms of performance because it does not have tunnel encapsulation overhead. In addition, as the routes destined for nodes and containers are added to a VPC route table, containers can be directly accessed from outside the cluster.
              • Cloud Native Network 2.0 is a next-generation model developed by CCE and combines the network interfaces and supplementary network interfaces of VPC. Pod IP addresses are allocated from the VPC CIDR block. ELB passthrough networking is supported to forward requests to containers. Security groups and EIPs are associated to deliver high performance.
              +

              The performance, networking scale, and application scenarios of a container network vary depending on the container network model. For details about the functions and features of different container network models, see Overview.

              +
            • Service network: Services are a kind of Kubernetes resource object. Each Service has a fixed IP address. Kubernetes provides stable access entries for pods through Services. When creating a cluster on CCE, you can specify the Service CIDR block. Service CIDR blocks cannot overlap with the node CIDR blocks or container CIDR blocks. They can be used only in a cluster.
            -

            Service

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

            -
            Figure 1 Accessing pods through a Service
            +

            Service

            In Kubernetes, pods are considered ephemeral and can be replaced at any time. When a pod is destroyed or replaced, its network resources also change. You need to provide a stable access method for pods. Kubernetes uses a Service to provide a fixed access entry for a group of pods with the same functions and balances the load among these pods.

            +

            As shown in the following figure, a Service is associated with a group of pods through a selector. When the IP address and port of the Service are accessed, traffic is distributed to these pods. When pods change, the Service automatically updates the backend forwarding rules to ensure that the latest pods can be accessed through the Service.

            +
            Figure 2 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 Overview.

            +

            For details about the Service, see Service Overview.

            Ingress

            Services forward requests using TCP and UDP at Layer 4. Ingresses forward requests using HTTP and HTTPS at Layer 7. Domain names and paths can be used for access of finer granularities.

            -
            Figure 2 An ingress and associated Services
            -

            For details about the ingress, see Overview.

            +
            Figure 3 An ingress and associated Services
            +

            For details about the ingress, see Ingress Overview.

            +
            +

            DNS

            CCE uses CoreDNS to implement service discovery in a cluster. For example, a client can access backend pods through a ClusterIP Service whose name is mapped to a cluster-scoped virtual IP address. This approach decouples the invoking between applications in a cluster from specific IP addresses and deployment environments. For details about the cluster DNS settings, see DNS Overview.

            +
            Figure 4 Example of domain name resolution in a cluster

            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 public network: An EIP should be bound to the node or load balancer.
              • Access through the private network: The workload can be accessed through the internal 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.
              -
            • The workload can access the external network as follows:
              • 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: Assign an EIP to the node where the workload runs (when a VPC network or tunnel network is used), bind an EIP to the pod IP address (when Cloud Native Network 2.0 is used), or configure SNAT rules through the NAT gateway. For details, see Accessing the Internet from a Container.
              +
            • The workload can access the external network as follows:
              • Accessing a private network: The workload accesses the private network address, but the implementation method varies depending on container network models. Ensure that the peer security group allows access from the container CIDR block.
              • Accessing a public network: Assign an EIP to the node where the workload runs (when a VPC network or tunnel network is used), bind an EIP to the pod IP address (when Cloud Native Network 2.0 is used), or configure an SNAT rule on the NAT gateway. For details, see Accessing the Internet from a Container.
            -
            Figure 3 Network access diagram
            +
            Figure 5 Network access diagram
            diff --git a/docs/cce/umn/cce_10_0011.html b/docs/cce/umn/cce_10_0011.html index ec6803eb6..30aa54ec9 100644 --- a/docs/cce/umn/cce_10_0011.html +++ b/docs/cce/umn/cce_10_0011.html @@ -1,16 +1,57 @@

            ClusterIP

            -

            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)
            +

            ClusterIP is the default Service type of Kubernetes and provides stable intra-cluster access. Kubernetes assigns a virtual IP address (cluster-scoped IP address) that can only be accessed within the cluster from the Service CIDR block of the cluster. CoreDNS maps the cluster-internal domain name to the assigned cluster IP address. The domain name format is <Service-name>.<namespace-of-the-workload>.svc.cluster.local:<port>, for example, nginx.default.svc.cluster.local:80.

            +

            If pods need to communicate with each other within a cluster, you can create a ClusterIP Service. For example, if a frontend pod in a cluster needs to access a backend database in the same cluster, you can create a ClusterIP Service.

            +

            Figure 1 shows how ClusterIP works. You can learn about the access channel, container port, and access port mapping rules of this type of Service.

            +
            Figure 1 Intra-cluster access (ClusterIP)
            +

            Using the CCE Console

            1. Log in to the CCE console and click the cluster name to access the cluster console.
            2. In the navigation pane, choose Services & Ingresses. In the upper right corner, click Create Service.
            3. Configure intra-cluster access parameters.

              +

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

              Parameter

              +

              Description

              +

              Service Name

              +

              Enter a name, which can be the same as the workload name.

              +

              Service Type

              +

              Select ClusterIP.

              +

              Namespace

              +

              Select the namespace that the workload belongs to.

              +

              Selector

              +

              The Service will be associated with the workload pods based on the label and direct traffic to the pods with this label.

              +

              You can add a key and value for the pod label and click Confirm.

              +

              You can also click Reference Workload Label to use the label of an existing workload. In the dialog box displayed, select a workload and click OK.

              +

              Protocol Version

              +

              Select the IP address of different versions based on service requirements. This function is displayed only when IPv6 is enabled during the creation of clusters of v1.15 or later.

              +

              Port

              +
              • Protocol: the protocol supported by the Service.
              • Container Port: the listening port of the service containers. The port ranges from 1 to 65535. You need to determine the port based on the container image. For example, the default port of Nginx is 80, and the default port of MySQL is 3306.
              • Service Port: the port used to access the ClusterIP Service. You can customize the port as required. The port ranges from 1 to 65535.
              +
              -

              Creating a ClusterIP Service

              1. Log in to the CCE console and click the cluster name to access the cluster console.
              2. In the navigation pane, choose Services & Ingresses. In the upper right corner, click Create Service.
              3. Configure intra-cluster access parameters.

                • Service Name: Specify a Service name, which can be the same as the workload name.
                • Service Type: Select ClusterIP.
                • Namespace: namespace that the workload belongs to.
                • Selector: Add a label and click Confirm. The Service will use this label to select pods. You can also click Reference Workload Label to use the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
                • Protocol Version: Select the IP address of different versions based on service requirements. This parameter is available only in clusters of v1.15 or later with IPv6 enabled (set during cluster creation).
                • Ports
                  • Protocol: protocol used by the Service.
                  • Service Port: port used by the Service. The port number ranges from 1 to 65535.
                  • Container Port: listener port of the workload. For example, Nginx uses port 80 by default.
                  -
                -

              4. Click OK.
              +

            4. Click OK. Then, access the Service through <ClusterIP>:<Service-port>.

              +

              +

            -

            Setting the Access Type Using kubectl

            You can configure Service access using kubectl. This section uses an Nginx workload as an example to describe how to implement intra-cluster access using kubectl.

            +

            Using kubectl

            You can configure Service access using kubectl. This section uses an Nginx workload as an example to describe how to implement intra-cluster access using kubectl.

            1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
            2. Create and edit the nginx-deployment.yaml file to configure the sample workload. For details, see Creating a Deployment. nginx-deployment.yaml is an example file name. You can rename it as needed.

              vi nginx-deployment.yaml
              File content:
              apiVersion: apps/v1
               kind: Deployment
              @@ -63,13 +104,12 @@ spec:
               

              Check the created Service.

              kubectl get svc

              If information similar to the following is displayed, the Service has been created, and a cluster-internal IP address has been assigned to the Service.

              -
              # kubectl get svc
              -NAME              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
              +
              NAME              TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
               kubernetes        ClusterIP   10.247.0.1     <none>        443/TCP    4d6h
               nginx-clusterip   ClusterIP   10.247.74.52   <none>        8080/TCP   14m

            3. Access the Service from a container or node in the cluster.

              1. Create a pod and access its container.
                kubectl run -i --tty --image nginx:alpine test --rm /bin/sh
              2. Run the curl command to access the Service.
                • Access through IP:Port:
                  curl 10.247.74.52:8080
                  -
                • Access through Domain-name:Port:
                  curl nginx-clusterip.default.svc.cluster.local:8080
                  +
                • Access using Domain name:Port (not supported on nodes):
                  curl nginx-clusterip.default.svc.cluster.local:8080

                  nginx-clusterip is the Service name, default is the namespace where the Service is located, and svc.cluster.local is the DNS domain for the ClusterIP Service.

                  You can simplify the domain name based on your requirements. For example, if the Service and the accessing pod are in the same namespace, you can use nginx-clusterip:8080 to access it. If they are in different namespaces, you can use nginx-clusterip.default:8080 to access it.

                @@ -105,7 +145,7 @@ Commercial support is available at
            diff --git a/docs/cce/umn/cce_10_0012.html b/docs/cce/umn/cce_10_0012.html index 05a16c4cf..4079efcf4 100644 --- a/docs/cce/umn/cce_10_0012.html +++ b/docs/cce/umn/cce_10_0012.html @@ -3,7 +3,7 @@

            Creating a Node Pool

            Scenario

            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.

            -

            Procedure

            1. Log in to the CCE console.
            2. Click the cluster name to access the cluster console. Choose Nodes in the navigation pane. In the right pane, click the Node Pools tab.
            3. In the upper right corner of the page, click Create Node Pool.

              Basic Settings

              +

              Procedure

              1. Log in to the CCE console.
              2. Click the cluster name to access the cluster console. Choose Nodes in the navigation pane. In the right pane, click the Node Pools tab.
              3. In the upper right corner of the page, click Create Node Pool.

                Basic Settings

                @@ -30,15 +30,15 @@ - @@ -78,7 +78,7 @@ @@ -92,7 +92,7 @@ - - - -
                Table 1 Basic settings

                Parameter

                Node Type

                Select a node type based on service requirements. Then, you can select a proper flavor from the node flavor list.

                -
                CCE standard clusters support the following node types:
                • ECS (VM): A virtualized ECS is used as a cluster node.
                +
                CCE standard clusters support the following node types:
                • ECS (VM): A VM ECS is used as a cluster node.
                -
                CCE Turbo clusters support the following node types:
                • ECS (VM): A VM ECS is used as a cluster node. A CCE Turbo cluster supports only the cloud servers that allow multiple ENIs. Select a server type displayed on the CCE console.
                +
                CCE Turbo clusters support the following node types:
                • ECS (VM): A VM ECS is used as a cluster node. A CCE Turbo cluster supports only the cloud servers that allow multiple network interfaces. Select a server type displayed on the CCE console.

                Specifications

                Select a node flavor based on service requirements. The available node flavors vary depending on regions. For details, see the CCE console. For the supported node flavors, see Node Flavor Description.
                NOTE:
                • If a node pool is configured with multiple node flavors, only the flavors (which can be located in different AZs) of the same node type are supported. For example, a node pool consisting of general computing-plus nodes supports only general computing-plus node flavors, but not the flavors of general computing nodes.
                • A maximum of 10 node flavors can be added to a node pool (the flavors in different AZs are counted separately). When adding a node flavor, you can choose multiple AZs, but you need to specify them.
                • Nodes in a newly created node pool are created using the default flavor. If the resources for the default flavor are insufficient, node creation will fail.
                • After a node pool is created, the flavors of existing nodes cannot be deleted.
                +
                Select a node flavor based on service requirements. The available node flavors vary depending on regions. For details, see the CCE console. For the supported node flavors, see Node Flavor Description.
                NOTE:
                • If a node pool is configured with multiple node flavors, only the flavors (which can be located in different AZs) of the same node type are supported. For example, a node pool consisting of general computing-plus nodes supports only general computing-plus node flavors, but not the flavors of general computing nodes.
                • Nodes added to a single node pool must have the same GPU type. For example, if you select the nvidia-v100 flavor, you are not allowed to select the nvidia-t4 flavor.
                • A maximum of 10 node flavors can be added to a node pool (the flavors in different AZs are counted separately). When adding a node flavor, you can choose multiple AZs, but you need to specify them.
                • Nodes in a newly created node pool are created using the default flavor. If the resources for the default flavor are insufficient, node creation will fail.
                • After a node pool is created, the flavors of existing nodes cannot be deleted.

                System Disk

                System disk used by the node OS. The value ranges from 40 GiB to 1024 GiB. The default value is 50 GiB.

                -
                System Disk Encryption: System disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption setting. Only the nodes of the Elastic Cloud Server (VM) type in certain regions support system disk encryption. For details, see the console.
                • Not encrypted is selected by default.
                • If you select Enabled (key) for System Disk Encryption, choose an existing key. If no key is available, click View Key List and create a key. After the key is created, click the refresh icon next to the text box.
                • If you select Enabled (KMS key ID) for System Disk Encryption, enter a KMS key (which can be shared by others) in the current region.
                +
                System Disk Encryption: System disk encryption safeguards your data. Snapshots generated from encrypted disks and disks created using these snapshots automatically inherit the encryption setting. Only the nodes of the Elastic Cloud Server (VM) type in certain regions support system disk encryption. For details, see the console.
                • Not encrypted is selected by default.
                • If you select Enabled (key) for System Disk Encryption, choose an existing key. If no key is available, click View Key List and create a key. After the key is created, click the refresh icon next to the text box.
                • If you select Enabled (KMS key ID) for System Disk Encryption, enter a KMS key (which can be shared by others) in the current region.

                Data Disk

                • At least one default data disk must be added for storing container runtime and kubelet components if System Component Storage is set to Data Disk. This data disk cannot be deleted or detached. Otherwise, the node will be unavailable. This function is available for clusters of a version earlier than v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, or v1.29.4-r0.
                  • Default data disk: used for container runtime and kubelet components. The disk size ranges from 20 GiB to 32768 GiB. The default value is 100 GiB.
                  • Other common data disks: You can set the data disk size to a value ranging from 10 GiB to 32768 GiB. The default value is 100 GiB.
                  +
                • At least one default data disk must be added for storing container runtime and kubelet components if System Component Storage is set to Data Disk. This data disk cannot be deleted or detached. Otherwise, the node will be unavailable. This function is available for clusters of a version earlier than v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, or v1.29.4-r0.
                  • Default data disk: used for container runtime and kubelet components. The disk size ranges from 20 GiB to 32768 GiB. The default value is 100 GiB.
                  • Other common data disks: You can set the data disk size to a value ranging from 10 GiB to 32768 GiB. The default value is 100 GiB.
                • If System Component Storage is set to System Disk, you do not need to add a default data disk. In this case, all data disks are common ones: You can set the data disk size to a value ranging from 10 GiB to 32768 GiB. The default value is 100 GiB. This function is available for clusters of v1.23.18-r0, v1.25.13-r0, v1.27.10-r0, v1.28.8-r0, v1.29.4-r0, or later versions.
                NOTE:
                • 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. Store your service data in EVS disks, which are more reliable than local disks.
                @@ -162,7 +162,7 @@

                You can add resource tags to classify resources.

                You can create predefined tags on the TMS console. These tags are available to all resources that support tags. You can use these tags to improve the tag creation and resource migration efficiency.

                -

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

                +

                CCE will automatically create the CCE-Dynamic-Provisioning-Node=Node ID tag.

                Kubernetes Label

                @@ -210,22 +210,22 @@

                Pre-installation Command

                Installation script command, in which Chinese characters are not allowed. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

                +

                Installation script command. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

                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

                Installation script command, in which Chinese characters are not allowed. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

                -

                The script will be executed after Kubernetes software is installed, which does not affect the installation.

                -
                NOTE:

                Do not run the reboot command in the post-installation script to restart the system immediately. To restart the system, run the shutdown -r 1 command to restart with a delay of one minute.

                +

                Installation script command. The script command will be Base64-transcoded. The characters of both the pre-installation and post-installation scripts are centrally calculated, and the total number of characters after transcoding cannot exceed 10240.

                +
                The script will be executed after Kubernetes software is installed, which does not affect the installation. During post-installation script execution, pods can be scheduled normally. However, if the script execution times out, node installation will fail. To prevent pods from being scheduled to nodes with incomplete script execution, enable the option to schedule pods only after the post-installation script execution completes.
                CAUTION:

                Do not use the reboot command in the post-installation script to restart the system immediately. Instead, use the shutdown -r 1 command to restart the system with a one-minute delay.

                +

                Agency

                An agency is created by the tenant administrator on the IAM console. Using 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.

                +

                If you need to share ECS resources with other accounts or delegate a more professional person or team to manage the resources, you can create an agency on IAM and grant the agency the permissions to manage ECS resources. The delegated account can log in to the cloud system and switch to your account to manage resources. You do not need to share security credentials (such as passwords) with other accounts, ensuring the security of your account.

                +

                If you have created an agency, select the agency from the drop-down list. If no agency is available, click Create Agency on the right to create one.

                Custom Prefix and Suffix

                diff --git a/docs/cce/umn/cce_10_0014.html b/docs/cce/umn/cce_10_0014.html index 9166892a1..03d71d585 100644 --- a/docs/cce/umn/cce_10_0014.html +++ b/docs/cce/umn/cce_10_0014.html @@ -6,7 +6,7 @@ diff --git a/docs/cce/umn/cce_10_0015.html b/docs/cce/umn/cce_10_0015.html index 9bb53d52f..63ae8f0d5 100644 --- a/docs/cce/umn/cce_10_0015.html +++ b/docs/cce/umn/cce_10_0015.html @@ -15,7 +15,7 @@ data:
              4. When a ConfigMap is used as an environment variable, data is not automatically updated when the ConfigMap is updated. To update the data, restart the pod.
              5. Configuring Environment Variables of a Workload

                Using the CCE console

                -
                1. Log in to the CCE console and click the cluster name to access the cluster console.
                2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

                  When creating a workload, click Environment Variables in the Container Settings area, and click Add Variable.

                  +
                  1. Log in to the CCE console and click the cluster name to access the cluster console.
                  2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

                    When creating a workload, click Environment Variables in the Container Settings area, and click Add Variable.

                    • 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.

                    @@ -94,9 +94,9 @@ CCE

                Configuring 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 CCE console

                -
                1. Log in to the CCE console and click the cluster name to access the cluster console.
                2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

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

                  +
                  1. Log in to the CCE console and click the cluster name to access the cluster console.
                  2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

                    When creating a workload, click Environment Variables in the Container Settings area, and click Add Variable. 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, which are key names in the cce-configmap ConfigMap.
                      /bin/bash
                      +

                    • Click Lifecycle in the Container Settings area, click the Post-Start tab on the right, and configure parameters.

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

                Mounting a ConfigMap to a 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, create ConfigMaps in advance. For details, see Creating a ConfigMap.

                Using the CCE console

                -
                1. Log in to the CCE console and click the cluster name to access the cluster console.
                2. In the navigation pane, choose Workloads. In the dialog box displayed, 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 ConfigMap from the drop-down list.

                  +
                  1. Log in to the CCE console and click the cluster name to access the cluster console.
                  2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

                    When creating a workload, click Data Storage in the Container Settings area. Click Add Volume and choose ConfigMap from the drop-down list.

                  3. Select parameters for mounting a ConfigMap volume, as shown in Table 1.

                    diff --git a/docs/cce/umn/cce_10_0016.html b/docs/cce/umn/cce_10_0016.html index a3e802071..076c6609c 100644 --- a/docs/cce/umn/cce_10_0016.html +++ b/docs/cce/umn/cce_10_0016.html @@ -19,7 +19,7 @@ data:

                    Configuring Environment Variables of a Workload

                    Using the CCE console

                    -
                    1. Log in to the CCE console and click the cluster name to access the cluster console.
                    2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

                      When creating a workload, click Environment Variables in the Container Settings area, and click Add Variable.

                      +
                      1. Log in to the CCE console and click the cluster name to access the cluster console.
                      2. In the navigation pane, choose Workloads. In the dialog box displayed, click Create Workload in the upper right corner.

                        When creating a workload, click Environment Variables in the Container Settings area, and click Add Variable.

                        • 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.

                        @@ -94,7 +94,7 @@ spec:

                    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, create a secret. For details, see Creating a Secret.

                    Using the CCE console

                    -
                    1. Log in to the CCE console and click the cluster name to access the cluster console.
                    2. Choose Workloads in the navigation pane. 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.

                      +
                      1. Log in to the CCE console and click the cluster name to access the cluster console.
                      2. Choose Workloads in the navigation pane. 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 choose Secret from the drop-down list.

                      3. Select parameters for mounting a secret volume, as shown in Table 1.

                    Table 1 Mounting a ConfigMap volume

                    Parameter

                    diff --git a/docs/cce/umn/cce_10_0018.html b/docs/cce/umn/cce_10_0018.html index f517d110b..8403ff0c1 100644 --- a/docs/cce/umn/cce_10_0018.html +++ b/docs/cce/umn/cce_10_0018.html @@ -1,12 +1,12 @@

                    Collecting Container Logs Using ICAgent

                    -

                    CCE can collect workload logs and report them to AOM 1.0. When a node is created, ICAgent (a DaemonSet named icagent in the kube-system namespace of a cluster) is installed by default. ICAgent collects workload logs and reports them to AOM 1.0. You can view workload logs on the CCE or AOM 1.0 console.

                    -

                    Constraints

                    ICAgent only collects text logs in .log, .trace, and .out formats.

                    +

                    CCE works with AOM 1.0 to collect workload logs. When a node is created, ICAgent (a DaemonSet named icagent in the kube-system namespace of a cluster) is installed by default. ICAgent collects workload logs and reports them to AOM 1.0. You can view workload logs on the CCE or AOM 1.0 console.

                    +

                    Constraints

                    ICAgent only collects text log files in .log, .trace, and .out formats.

                    -

                    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.

                      +

                      Using ICAgent to Collect Logs

                      1. When creating a workload, choose Logging in Container Information.
                      2. Click to add a log policy.

                        The following uses Nginx as an example. Log policies vary depending on workloads.

                      3. Set Volume Type to hostPath or emptyDir.

                        -

                    Table 1 Mounting a secret volume

                    Parameter

                    Table 1 Configuring log policies

                    Parameter

                    +
                    @@ -14,7 +14,7 @@ - - @@ -34,22 +34,22 @@ @@ -59,8 +59,8 @@

                  4. Click OK.
                  5. -

                    YAML Example

                    You can set the container log storage path by defining a YAML file.

                    -

                    As shown in the following figure, an emptyDir volume is mounted a temporary path to /var/log/nginx. In this way, the ICAgent collects logs in /var/log/nginx. The policy field is customized by CCE and allows the ICAgent to identify and collect logs.

                    +

                    Example YAML

                    You can set the container log storage path by defining a YAML file.

                    +

                    As shown below, an emptyDir volume is mounted to /var/log/nginx. In this way, the ICAgent collects logs in /var/log/nginx. policy is a custom field of CCE and allows the ICAgent to identify and collect logs.

                    apiVersion: apps/v1
                     kind: Deployment
                     metadata:
                    @@ -97,7 +97,7 @@ spec:
                               name: vol-log
                           imagePullSecrets:
                             - name: default-secret
                    -

                    The following shows how to use a hostPath volume. Compared with emptyDir, the type of volumes is changed to hostPath, and the path on the host needs to be configured for this hostPath volume. In the following example, /tmp/log on the host is mounted to /var/log/nginx. In this way, the ICAgent can collects logs in /var/log/nginx, without deleting the logs from /tmp/log.

                    +

                    The following shows how to use a hostPath volume. Compared with emptyDir, the type of volumes is changed to hostPath, and the path on the host needs to be configured for this hostPath volume. In the following example, /tmp/log on the host is mounted to /var/log/nginx. In this way, the ICAgent can collect logs in /var/log/nginx, without deleting the logs from /tmp/log.

                    apiVersion: apps/v1
                     kind: Deployment
                     metadata:
                    @@ -145,7 +145,7 @@ spec:
                     
                     
                    - @@ -154,8 +154,8 @@ spec: @@ -173,9 +173,9 @@ spec: @@ -202,10 +202,10 @@ spec:

                    Viewing Logs

                    After a log collection path is configured and the workload is created, the ICAgent collects log files from the configured path. The collection takes about 1 minute.

                    After the log collection is complete, go to the workload details page and click Logs in the upper right corner to view logs.

                    You can also view logs on the AOM console.

                    -

                    You can also run the kubectl logs command to view the container stdout.

                    +

                    You can also run the kubectl logs command to view the container stdout.

                    • View the logs of a specified pod.
                      kubectl logs <pod_name> -n <namespace>
                    • View the logs of a specified pod in real time.
                      kubectl logs -f <pod_name> -n <namespace>
                      -
                    • View logs of a specified container in a specified pod.
                      kubectl logs <pod_name> -c <container_name> -n <namespace>
                      +
                    • View the logs of a specified container in a specified pod.
                      kubectl logs <pod_name> -c <container_name> -n <namespace>
                    • View the logs of a specified container in a specified pod in real time.
                      kubectl logs -f <pod_name> -c <container_name> -n <namespace>
                    diff --git a/docs/cce/umn/cce_10_0019.html b/docs/cce/umn/cce_10_0019.html index 39e8c15d9..d0b08afbb 100644 --- a/docs/cce/umn/cce_10_0019.html +++ b/docs/cce/umn/cce_10_0019.html @@ -1,10 +1,10 @@ -

                    Helm Chart

                    +

                    Helm Charts

                    Table 1 Parameters for configuring a log policy

                    Parameter

                    Description

                    Volume Type

                    • hostPath: A host path is mounted to the specified container path (mount path). In the node host path, you can view the container logs output into the mount path.
                    • emptyDir: A temporary path of the node is mounted to the specified path (mount path). Log data that exists in the temporary path but is not reported by the collector to AOM will disappear after the pod is deleted.
                    +
                    • hostPath: A host path is mounted to the specified container path (mount path). After it is mounted, you can view the container logs that have been saved there.
                    • emptyDir: A temporary path of the node is mounted to the specified path (mount path). After it is mounted, any logs in the temporary path that are not reported to AOM by the collector will be lost if the pod is deleted.

                    hostPath

                    @@ -24,7 +24,7 @@

                    Mount Path

                    Container path (for example, /tmp) to which the storage resources will be mounted.
                    NOTICE:
                    • Do not mount storage to a system directory such as / or /var/run; this action may cause a container error to occur. 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.
                    • If 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 may be damaged.
                    • AOM collects only the first 20 logs that have been modified recently. It collects logs from 2 levels of subdirectories by default.
                    • AOM only collects .log, .trace, and .out text logs in mounting paths.
                    • For details about how to set permissions for mount points in a container, see Configure a Security Context for a Pod or Container.
                    +
                    Container path (for example, /tmp) that the storage resources will be mounted to.
                    NOTICE:
                    • Do not mount a volume to a system directory such as / or /var/run, or an exception occurs. Mount the volume to an empty directory. If the directory is not empty, ensure that there are no files that affect container startup. If there are such files, they will be replaced, which will lead to a container startup or workload creation failure.
                    • If the container is mounted to a high-risk directory, use an account with minimum permissions to start the container. Otherwise, high-risk files on the host may be damaged.
                    • AOM collects only the first 20 logs that have been modified recently. It collects logs from 2 levels of subdirectories by default.
                    • AOM only collects text log files in .log, .trace, and .out formats in the mount paths.
                    • For details about how to set permissions for mount points in a container, see Configure a Security Context for a Pod or Container.

                    This parameter is mandatory only if Volume Type is set to hostPath.

                    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.
                    +
                    • 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.

                    Collection Path

                    A collection path narrows down the scope of collection to specified logs.

                    -
                    • If no collection path is specified, log files in .log, .trace, and .out formats will be collected from the specified path.
                    • /Path/**/ indicates that all log files in .log, .trace, and .out formats will be recursively collected from the specified path and all subdirectories at 5 levels deep.
                    • * in log file names indicates a fuzzy match.
                    -

                    Example: The collection path /tmp/**/test*.log indicates that all .log files prefixed with test will be collected from /tmp and subdirectories at 5 levels deep.

                    -
                    CAUTION:

                    Ensure that ICAgent is of version 5.12.22 or later.

                    +
                    • If no collection path is specified, log files in .log, .trace, and .out formats will be collected from the current path.
                    • Entering ** indicates that all log files in .log, .trace, and .out formats will be recursively collected from the specified path and all subdirectories of five levels deep.
                    • Entering * indicates fuzzy matching.
                    +

                    Example: The collection path /tmp/**/test*.log indicates that all .log files prefixed with test will be collected from /tmp and subdirectories of five levels deep.

                    +
                    CAUTION:

                    Ensure that the version of ICAgent is 5.12.22 or later.

                    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. 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.
                    • Disabled: AOM does not dump log files.
                    +
                    • Enable: 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 resides. 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.
                    • Disable: 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 already 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.

                    Description

                    Description

                    +

                    Remarks

                    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

                    @@ -163,7 +163,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.
                    +
                    • Enable: 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 resides. 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.
                    • Disable: 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 already 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.

                    Collection path

                    A collection path narrows down the scope of collection to specified logs.

                    -
                    • If no collection path is specified, log files in .log, .trace, and .out formats will be collected from the specified path.
                    • /Path/**/ indicates that all log files in .log, .trace, and .out formats will be recursively collected from the specified path and all subdirectories at 5 levels deep.
                    • * in log file names indicates a fuzzy match.
                    -

                    Example: The collection path /tmp/**/test*.log indicates that all .log files prefixed with test will be collected from /tmp and subdirectories at 5 levels deep.

                    -
                    CAUTION:

                    Ensure that ICAgent is of version 5.12.22 or later.

                    +
                    • If no collection path is specified, log files in .log, .trace, and .out formats will be collected from the current path.
                    • Entering ** indicates that all log files in .log, .trace, and .out formats will be recursively collected from the specified path and all subdirectories of five levels deep.
                    • Entering * indicates fuzzy matching.
                    +

                    Example: The collection path /tmp/**/test*.log indicates that all .log files prefixed with test will be collected from /tmp and subdirectories of five levels deep.

                    +
                    CAUTION:

                    Ensure that the version of ICAgent is 5.12.22 or later.

                    Table 1 CCE Operations Supported by CTS

                    Operation

                    +
                    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/cce/umn/cce_10_0026.html b/docs/cce/umn/cce_10_0026.html index 4ce73e548..b8162e570 100644 --- a/docs/cce/umn/cce_10_0026.html +++ b/docs/cce/umn/cce_10_0026.html @@ -1,20 +1,68 @@

                    Viewing CTS Traces in the Trace List

                    -

                    Scenarios

                    After you enable Cloud Trace Service (CTS) and the management tracker is created, CTS starts recording operations on cloud resources. CTS stores operation records (traces) generated in the last seven days.

                    +

                    Scenarios

                    Cloud Trace Service (CTS) records operations performed on cloud service resources. A record contains information such as the user who performed the operation, IP address, operation content, and returned response message. These records facilitate security auditing, issue tracking, and resource locating. They also help you plan and use resources, and identify high-risk or non-compliant operations.

                    -

                    Viewing Real-Time Traces in the Trace List

                    1. Log in to the management console.
                    2. Click in the upper left corner and choose Management & Deployment > Cloud Trace Service. The CTS console is displayed.
                    3. Choose Trace List in the navigation pane on the left.
                    4. Set filters to search for your desired traces, as shown in Figure 1. The following filters are available.
                      Figure 1 Filters
                      -
                      • Trace Type, Trace Source, Resource Type, and Search By: Select a filter from the drop-down list.
                        • If you select Resource ID for Search By, specify a resource ID.
                        • If you select Trace name for Search By, specify a trace name.
                        • If you select Resource name for Search By, specify a resource name.
                        -
                      • Operator: Select a user.
                      • Trace Status: Select All trace statuses, Normal, Warning, or Incident.
                      • Time range: Select Last 1 hour, Last 1 day, or Last 1 week, or specify a custom time range within the last seven days.
                      +

                      What Is a Trace?

                      A trace is an operation log for a cloud service resource, tracked and stored by CTS. Traces record operations such as adding, modifying, or deleting cloud service resources. You can view them to identify who performed operations and when for detailed tracking.

                      -
                    5. Click Query.
                    6. On the Trace List page, you can also export and refresh the trace list.
                      • Click Export to export all traces in the query result as a CSV file. The file can contain up to 5,000 records.
                      • Click to view the latest information about traces.
                      -
                    7. Click on the left of a trace to expand its details.

                      +

                      Viewing Traces in the Trace List

                      1. Log in to the management console, click in the upper left corner, and choose Management & Deployment > Cloud Trace Service.
                      2. In the navigation pane, choose Trace List.
                      3. In the upper right corner of the page, set a desired query time range: Last 1 hour, Last 1 day, or Last 1 week. You can also click Customize to specify a custom time range within the last seven days.
                      4. Set filters to search for your desired traces, as shown in Figure 1.

                        Figure 1 Filters
                        + +
                    Table 1 CCE operations supported by CTS

                    Operation

                    Resource Type

                    +

                    Resource

                    Event Name

                    +

                    Trace Name

                    Creating an agency

                    +

                    Creating an agency

                    Cluster

                    +

                    Cluster

                    createUserAgencies

                    +

                    createUserAgencies

                    Creating a cluster

                    +

                    Querying an agency

                    Cluster

                    +

                    Cluster

                    createCluster

                    +

                    getUserAgencies

                    Updating the description of a cluster

                    +

                    Obtaining an access policy

                    Cluster

                    +

                    Cluster

                    updateCluster

                    +

                    getAccessPolicy

                    Upgrading a cluster

                    +

                    Creating an access policy

                    Cluster

                    +

                    Cluster

                    clusterUpgrade

                    +

                    createAccessPolicy

                    Deleting a cluster

                    +

                    Deleting an access policy

                    Cluster

                    +

                    Cluster

                    claimCluster/deleteCluster

                    +

                    deleteAccessPolicy

                    Downloading a cluster certificate

                    +

                    Obtaining the access policy list

                    Cluster

                    +

                    Cluster

                    getClusterCertByUID

                    +

                    listAccessPolicy

                    Binding and unbinding an EIP

                    +

                    Updating an access policy

                    Cluster

                    +

                    Cluster

                    operateMasterEIP

                    +

                    updateAccessPolicy

                    Waking up a cluster and resetting node management (V2)

                    +

                    Creating a cluster

                    Cluster

                    +

                    Cluster

                    operateCluster

                    +

                    createCluster

                    Hibernating a cluster (V3)

                    +

                    Updating the description of a cluster

                    Cluster

                    +

                    Cluster

                    hibernateCluster

                    +

                    updateCluster

                    Waking up a cluster (V3)

                    +

                    Upgrading a cluster

                    Cluster

                    +

                    Cluster

                    awakeCluster

                    +

                    clusterUpgrade

                    Changing the specifications of a cluster

                    +

                    Deleting a cluster

                    Cluster

                    +

                    Cluster

                    resizeCluster

                    +

                    claimCluster/deleteCluster

                    Modifying configurations of a cluster

                    +

                    Obtaining the cluster list

                    Cluster

                    +

                    Cluster

                    updateConfiguration

                    +

                    listCluster

                    Creating a node pool

                    +

                    Obtaining the cluster list in a project

                    Node pool

                    +

                    Cluster

                    createNodePool

                    +

                    getClustersByProjectID

                    Updating a node pool

                    +

                    Obtaining the number of clusters

                    Node pool

                    +

                    Cluster

                    updateNodePool

                    +

                    getClusterInstances

                    Deleting a node pool

                    +

                    Obtaining a cluster

                    Node pool

                    +

                    Cluster

                    claimNodePool

                    +

                    getClusterByUID

                    Migrating a node pool

                    +

                    Obtaining the cluster package list

                    Node pool

                    +

                    Cluster

                    migrateNodepool

                    +

                    getPackageLists

                    Modifying node pool configurations

                    +

                    Obtaining the package configuration of a cluster

                    Node pool

                    +

                    Cluster

                    updateConfiguration

                    +

                    getPackageConfigs

                    Creating a node

                    +

                    Downloading a cluster certificate

                    Node

                    +

                    Cluster

                    createNode

                    +

                    getClusterCertByUID

                    Deleting all the nodes from a specified cluster

                    +

                    Revoking a cluster certificate

                    Node

                    +

                    Cluster

                    deleteAllHosts

                    +

                    revokeClusterCert

                    Deleting a single node

                    +

                    Binding and unbinding an EIP

                    Node

                    +

                    Cluster

                    deleteOneHost/claimOneHost

                    +

                    operateMasterEIP

                    Updating the description of a node

                    +

                    Waking up a cluster and resetting node management (V2)

                    Node

                    +

                    Cluster

                    updateNode

                    +

                    operateCluster

                    Creating an add-on instance

                    +

                    Hibernating a cluster (V3)

                    Add-on instance

                    +

                    Cluster

                    createAddonInstance

                    +

                    hibernateCluster

                    Deleting an add-on instance

                    +

                    Waking up a cluster (V3)

                    Add-on instance

                    +

                    Cluster

                    deleteAddonInstance

                    +

                    awakeCluster

                    Uploading a chart

                    +

                    Changing the specifications of a cluster

                    Chart

                    +

                    Cluster

                    uploadChart

                    +

                    resizeCluster

                    Updating a chart

                    +

                    Modifying configurations of a cluster

                    Chart

                    +

                    Cluster

                    updateChart

                    +

                    updateConfiguration

                    Deleting a chart

                    +

                    Obtaining cluster configuration

                    Chart

                    +

                    Cluster

                    deleteChart

                    +

                    getClusterConfiguration

                    Creating a release

                    +

                    Obtaining all configurations of the current cluster version

                    Release

                    +

                    Cluster

                    createRelease

                    +

                    getClusterConfigurationDetail

                    Upgrading a release

                    +

                    Querying the detailed configuration items of a cluster by cluster version or type

                    Release

                    +

                    Cluster

                    updateRelease

                    +

                    getClusterSupportConfiguration

                    Deleting a release

                    +

                    Obtaining cluster quotas

                    Release

                    +

                    Cluster

                    deleteRelease

                    +

                    getQuotas

                    Creating a ConfigMap

                    +

                    Obtaining the global OBS access secret configuration of a cluster

                    Kubernetes resource

                    +

                    Cluster

                    createConfigmaps

                    +

                    getClusterLongAKSKConfig

                    Creating a DaemonSet

                    +

                    Updating the global OBS access secret configuration of a cluster

                    Kubernetes resource

                    +

                    Cluster

                    createDaemonsets

                    +

                    updateClusterLongAKSKConfig

                    Creating a Deployment

                    +

                    Updating the global OBS access secret configuration in a project

                    Kubernetes resource

                    +

                    Cluster

                    createDeployments

                    +

                    UpdateAKSKConfig

                    Creating an event

                    +

                    Obtaining the global OBS access secret configuration in a project

                    Kubernetes resource

                    +

                    Cluster

                    createEvents

                    +

                    GetAKSKConfig

                    Creating an Ingress

                    +

                    Obtaining the IP address of a master node

                    Kubernetes resource

                    +

                    Cluster

                    createIngresses

                    +

                    GetOpenAPIInfo

                    Creating a job

                    +

                    Obtaining the cluster access address

                    Kubernetes resource

                    +

                    Cluster

                    createJobs

                    +

                    GetEndpoints

                    Creating a namespace

                    +

                    Retrying a cluster upgrade

                    Kubernetes resource

                    +

                    Cluster

                    createNamespaces

                    +

                    ClusterUpgradeRetry

                    Creating a node

                    +

                    Pausing a cluster upgrade

                    Kubernetes resource

                    +

                    Cluster

                    createNodes

                    +

                    ClusterUpgradePause

                    Creating a PersistentVolumeClaim

                    +

                    Continuing a cluster upgrade

                    Kubernetes resource

                    +

                    Cluster

                    createPersistentvolumeclaims

                    +

                    ClusterUpgradeContinue

                    Creating a pod

                    +

                    Rolling back a cluster upon an upgrade failure

                    Kubernetes resource

                    +

                    Cluster

                    createPods

                    +

                    Rollback

                    Creating a replica set

                    +

                    Rolling back a cluster upon an upgrade retry failure

                    Kubernetes resource

                    +

                    Cluster

                    createReplicasets

                    +

                    ClusterRollbackRetry

                    Creating a resource quota

                    +

                    Pausing a cluster upgrade rollback

                    Kubernetes resource

                    +

                    Cluster

                    createResourcequotas

                    +

                    ClusterRollbackPause

                    Creating a secret

                    +

                    Continuing a cluster upgrade rollback

                    Kubernetes resource

                    +

                    Cluster

                    createSecrets

                    +

                    ClusterRollbackContinue

                    Creating a service

                    +

                    Querying the cluster rollback history

                    Kubernetes resource

                    +

                    Cluster

                    createServices

                    +

                    GetRollbackTasks

                    Creating a StatefulSet

                    +

                    Querying the cluster upgrade history

                    Kubernetes resource

                    +

                    Cluster

                    createStatefulsets

                    +

                    GetUpgradeTasks

                    Creating a volume

                    +

                    Querying the records of a cluster upgrade

                    Kubernetes resource

                    +

                    Cluster

                    createVolumes

                    +

                    GetUpgradeTask

                    Deleting a ConfigMap

                    +

                    Querying cluster labels

                    Kubernetes resource

                    +

                    Cluster

                    deleteConfigmaps

                    +

                    GetLabels

                    Deleting a DaemonSet

                    +

                    Querying the configuration of a cluster

                    Kubernetes resource

                    +

                    Cluster

                    deleteDaemonsets

                    +

                    GetUpgradeInfo

                    Deleting a Deployment

                    +

                    Obtaining the certificate rotation state

                    Kubernetes resource

                    +

                    Cluster

                    deleteDeployments

                    +

                    GetRotationState

                    Deleting an event

                    +

                    Rotating certificates

                    Kubernetes resource

                    +

                    Cluster

                    deleteEvents

                    +

                    RotateCredentials

                    Deleting an Ingress

                    +

                    Downloading certificates

                    Kubernetes resource

                    +

                    Cluster

                    deleteIngresses

                    +

                    DownloadNodeCredentials

                    Deleting a job

                    +

                    Rolling back certificates

                    Kubernetes resource

                    +

                    Cluster

                    deleteJobs

                    +

                    RollbackCredentials

                    Deleting a namespace

                    +

                    Completing certificate rotation

                    Kubernetes resource

                    +

                    Cluster

                    deleteNamespaces

                    +

                    FinishEncryptionKeyRotation

                    Deleting a node

                    +

                    Supplementing the component certificates of a master node

                    Kubernetes resource

                    +

                    Cluster

                    deleteNodes

                    +

                    CompleteComponentCredential

                    Deleting a Pod

                    +

                    Updating cluster certificates

                    Kubernetes resource

                    +

                    Cluster

                    deletePods

                    +

                    RotateClusterCredentials

                    Deleting a replica set

                    +

                    Enabling the cluster upgrade workflow booting task

                    Kubernetes resource

                    +

                    Cluster

                    deleteReplicasets

                    +

                    UpgradeWorkFlow

                    Deleting a resource quota

                    +

                    Querying cluster upgrade workflows

                    Kubernetes resource

                    +

                    Cluster

                    deleteResourcequotas

                    +

                    GetUpgradeWorkFlows

                    Deleting a secret

                    +

                    Querying details about a cluster upgrade task

                    Kubernetes resource

                    +

                    Cluster

                    deleteSecrets

                    +

                    UpgradeWorkFlowUpdate

                    Deleting a service

                    +

                    Performing a pre-upgrade check for a cluster

                    Kubernetes resource

                    +

                    Cluster

                    deleteServices

                    +

                    PreCheck

                    Deleting a StatefulSet

                    +

                    Obtaining the list of historical check records

                    Kubernetes resource

                    +

                    Cluster

                    deleteStatefulsets

                    +

                    GetPreCheckList

                    Deleting volumes

                    +

                    Obtaining a specific check record

                    Kubernetes resource

                    +

                    Cluster

                    deleteVolumes

                    +

                    GetPreCheck

                    Replacing a specified ConfigMap

                    +

                    Performing a post-upgrade check

                    Kubernetes resource

                    +

                    Cluster

                    updateConfigmaps

                    +

                    PostCheck

                    Replacing a specified DaemonSet

                    +

                    Performing a rolling upgrade on the cluster control plane

                    Kubernetes resource

                    +

                    Cluster

                    updateDaemonsets

                    +

                    RollingUpdateControlPlane

                    Replacing a specified Deployment

                    +

                    Retrying a rolling upgrade on the cluster control plane

                    Kubernetes resource

                    +

                    Cluster

                    updateDeployments

                    +

                    RetryRollingUpdateControlPlane

                    Replacing a specified event

                    +

                    Creating a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateEvents

                    +

                    createNodePool

                    Replacing a specified ingress

                    +

                    Updating a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateIngresses

                    +

                    updateNodePool

                    Replacing a specified job

                    +

                    Deleting a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateJobs

                    +

                    claimNodePool

                    Replacing a specified namespace

                    +

                    Migrating a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateNamespaces

                    +

                    migrateNodepool

                    Replacing a specified node

                    +

                    Updating the node pool configuration

                    Kubernetes resource

                    +

                    Node pool

                    updateNodes

                    +

                    updateConfiguration

                    Replacing a specified PersistentVolumeClaim

                    +

                    Obtaining the node pool configuration

                    Kubernetes resource

                    +

                    Node pool

                    updatePersistentvolumeclaims

                    +

                    getConfiguration

                    Replacing a specified pod

                    +

                    Obtaining node pool details

                    Kubernetes resource

                    +

                    Node pool

                    updatePods

                    +

                    getConfigurationDetail

                    Replacing a specified replica set

                    +

                    Querying a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateReplicasets

                    +

                    getNodePool

                    Replacing a specified resource quota

                    +

                    Querying the node pool quota

                    Kubernetes resource

                    +

                    Node pool

                    updateResourcequotas

                    +

                    getNodePoolQuota

                    Replacing a specified secret

                    +

                    Querying all node pools in a cluster

                    Kubernetes resource

                    +

                    Node pool

                    updateSecrets

                    +

                    listNodePools

                    Replacing a specified service

                    +

                    Scaling down a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateServices

                    +

                    scaleNodePool

                    Replacing a specified StatefulSet

                    +

                    Upgrading a node pool

                    Kubernetes resource

                    +

                    Node pool

                    updateStatefulsets

                    +

                    upgradeNodePool

                    Replacing the specified status

                    +

                    Adding nodes

                    Kubernetes resource

                    +

                    Node

                    updateStatus

                    +

                    addNodes

                    Uploading a chart

                    +

                    Creating a node

                    Kubernetes resource

                    +

                    Node

                    uploadChart

                    +

                    createNode

                    Updating a component template

                    +

                    Deleting all nodes from a cluster

                    Kubernetes resource

                    +

                    Node

                    updateChart

                    +

                    deleteAllHosts

                    Deleting a chart

                    +

                    Deleting a node

                    Kubernetes resource

                    +

                    Node

                    deleteChart

                    +

                    deleteOneHost/claimOneHost

                    Creating a template application

                    +

                    Updating the description of a node

                    Kubernetes resource

                    +

                    Node

                    createRelease

                    +

                    updateNode

                    Updating a template application

                    +

                    Obtaining the list of nodes in a cluster

                    Kubernetes resource

                    +

                    Node

                    updateRelease

                    +

                    getHostsList

                    Deleting a template application

                    +

                    Obtaining a node

                    Kubernetes resource

                    +

                    Node

                    deleteRelease

                    +

                    getOneHost

                    +

                    Removing nodes

                    +

                    Node

                    +

                    removeNodesTask

                    +

                    Resetting nodes

                    +

                    Node

                    +

                    resetNodes

                    +

                    Migrating nodes to the node pool

                    +

                    Node

                    +

                    MigrateNodes

                    +

                    Synchronizing nodes in a batch

                    +

                    Node

                    +

                    SyncNodes

                    +

                    Migrating nodes

                    +

                    Node

                    +

                    MigrateNodesTask

                    +

                    Locking a node pool so that it will not be scaled down

                    +

                    Node

                    +

                    LockNodepoolNodeScaleDown

                    +

                    Unlocking a node pool so that it can be scaled down

                    +

                    Node

                    +

                    UnLockNodepoolNodeScaleDown

                    +

                    Deleting all jobs

                    +

                    Job

                    +

                    deleteJobs

                    +

                    Deleting a job

                    +

                    Job

                    +

                    deleteOneJob

                    +

                    Obtaining jobs in a project

                    +

                    Job

                    +

                    getJobsByProjectID

                    +

                    Obtaining a job

                    +

                    Job

                    +

                    getJobByUID

                    +

                    Creating an add-on instance

                    +

                    Add-on instance

                    +

                    createAddonInstance

                    +

                    Querying an add-on instance

                    +

                    Add-on instance

                    +

                    getAddonInstance

                    +

                    Deleting an add-on instance

                    +

                    Add-on instance

                    +

                    deleteAddonInstance

                    +

                    Obtaining the add-on list

                    +

                    Add-on instance

                    +

                    getAddonsList

                    +

                    Updating an add-on instance

                    +

                    Add-on instance

                    +

                    updateAddonInstance

                    +

                    Rolling back an add-on instance

                    +

                    Add-on instance

                    +

                    rollbackAddonInstance

                    +

                    Obtaining add-on details by add-on ID

                    +

                    Add-on instance

                    +

                    GetAddonTemplate

                    +

                    Obtaining the add-on template list

                    +

                    Add-on instance

                    +

                    GetAddonTemplateList

                    +

                    Uploading a chart

                    +

                    Chart

                    +

                    uploadChart

                    +

                    Updating a chart

                    +

                    Chart

                    +

                    updateChart

                    +

                    Deleting a chart

                    +

                    Chart

                    +

                    deleteChart

                    +

                    Downloading a chart

                    +

                    Chart

                    +

                    downloadChart

                    +

                    Querying a chart

                    +

                    Chart

                    +

                    getChart

                    +

                    Obtaining chart details

                    +

                    Chart

                    +

                    getChartValues

                    +

                    Obtaining the chart list

                    +

                    Chart

                    +

                    listCharts

                    +

                    Obtaining the chart quota

                    +

                    Chart

                    +

                    getUserChartsQuotas

                    +

                    Creating a release

                    +

                    Release

                    +

                    createRelease

                    +

                    Upgrading a release

                    +

                    Release

                    +

                    updateRelease

                    +

                    Deleting a release

                    +

                    Release

                    +

                    deleteRelease

                    +

                    Querying a release

                    +

                    Release

                    +

                    getRelease

                    +

                    Querying the release history

                    +

                    Release

                    +

                    getReleaseHistory

                    +

                    Querying the release list

                    +

                    Release

                    +

                    listReleases

                    +

                    Creating a ConfigMap

                    +

                    Kubernetes resource

                    +

                    createConfigmaps

                    +

                    Querying a ConfigMap

                    +

                    Kubernetes resource

                    +

                    getConfigmaps

                    +

                    Creating a DaemonSet

                    +

                    Kubernetes resource

                    +

                    createDaemonsets

                    +

                    Querying a DaemonSet

                    +

                    Kubernetes resource

                    +

                    getDaemonsets

                    +

                    Creating a Deployment

                    +

                    Kubernetes resource

                    +

                    createDeployments

                    +

                    Querying a Deployment

                    +

                    Kubernetes resource

                    +

                    getDeployments

                    +

                    Creating an event

                    +

                    Kubernetes resource

                    +

                    createEvents

                    +

                    Querying an event

                    +

                    Kubernetes resource

                    +

                    getEvents

                    +

                    Creating an ingress

                    +

                    Kubernetes resource

                    +

                    createIngresses

                    +

                    Querying an ingress

                    +

                    Kubernetes resource

                    +

                    getIngresses

                    +

                    Creating a job

                    +

                    Kubernetes resource

                    +

                    createJobs

                    +

                    Querying a job

                    +

                    Kubernetes resource

                    +

                    getJobs

                    +

                    Creating a namespace

                    +

                    Kubernetes resource

                    +

                    createNamespaces

                    +

                    Querying a namespace

                    +

                    Kubernetes resource

                    +

                    getNamespaces

                    +

                    Creating a node

                    +

                    Kubernetes resource

                    +

                    createNodes

                    +

                    Querying a node

                    +

                    Kubernetes resource

                    +

                    getNodes

                    +

                    Creating a PersistentVolumeClaim

                    +

                    Kubernetes resource

                    +

                    createPersistentvolumeclaims

                    +

                    Querying a PersistentVolumeClaim

                    +

                    Kubernetes resource

                    +

                    getPersistentvolumeclaims

                    +

                    Creating a pod

                    +

                    Kubernetes resource

                    +

                    createPods

                    +

                    Querying a pod

                    +

                    Kubernetes resource

                    +

                    getPods

                    +

                    Creating a ReplicaSet

                    +

                    Kubernetes resource

                    +

                    createReplicasets

                    +

                    Querying a ReplicaSet

                    +

                    Kubernetes resource

                    +

                    getReplicasets

                    +

                    Creating a resource quota

                    +

                    Kubernetes resource

                    +

                    createResourcequotas

                    +

                    Creating a secret

                    +

                    Kubernetes resource

                    +

                    createSecrets

                    +

                    Querying a secret

                    +

                    Kubernetes resource

                    +

                    getSecrets

                    +

                    Creating a Service

                    +

                    Kubernetes resource

                    +

                    createServices

                    +

                    Querying a Service

                    +

                    Kubernetes resource

                    +

                    getServices

                    +

                    Creating a StatefulSet

                    +

                    Kubernetes resource

                    +

                    createStatefulsets

                    +

                    Querying a StatefulSet

                    +

                    Kubernetes resource

                    +

                    getStatefulsets

                    +

                    Creating a volume

                    +

                    Kubernetes resource

                    +

                    createVolumes

                    +

                    Querying a volume

                    +

                    Kubernetes resource

                    +

                    getVolumes

                    +

                    Deleting a ConfigMap

                    +

                    Kubernetes resource

                    +

                    deleteConfigmaps

                    +

                    Deleting a DaemonSet

                    +

                    Kubernetes resource

                    +

                    deleteDaemonsets

                    +

                    Deleting a Deployment

                    +

                    Kubernetes resource

                    +

                    deleteDeployments

                    +

                    Deleting an event

                    +

                    Kubernetes resource

                    +

                    deleteEvents

                    +

                    Deleting an ingress

                    +

                    Kubernetes resource

                    +

                    deleteIngresses

                    +

                    Deleting a job

                    +

                    Kubernetes resource

                    +

                    deleteJobs

                    +

                    Deleting a namespace

                    +

                    Kubernetes resource

                    +

                    deleteNamespaces

                    +

                    Deleting a node

                    +

                    Kubernetes resource

                    +

                    deleteNodes

                    +

                    Deleting a Pod

                    +

                    Kubernetes resource

                    +

                    deletePods

                    +

                    Deleting a ReplicaSet

                    +

                    Kubernetes resource

                    +

                    deleteReplicasets

                    +

                    Deleting a resource quota

                    +

                    Kubernetes resource

                    +

                    deleteResourcequotas

                    +

                    Deleting a secret

                    +

                    Kubernetes resource

                    +

                    deleteSecrets

                    +

                    Deleting a Service

                    +

                    Kubernetes resource

                    +

                    deleteServices

                    +

                    Deleting a StatefulSet

                    +

                    Kubernetes resource

                    +

                    deleteStatefulsets

                    +

                    Deleting a volume

                    +

                    Kubernetes resource

                    +

                    deleteVolumes

                    +

                    Replacing a ConfigMap

                    +

                    Kubernetes resource

                    +

                    updateConfigmaps

                    +

                    Replacing a DaemonSet

                    +

                    Kubernetes resource

                    +

                    updateDaemonsets

                    +

                    Replacing a Deployment

                    +

                    Kubernetes resource

                    +

                    updateDeployments

                    +

                    Replacing an event

                    +

                    Kubernetes resource

                    +

                    updateEvents

                    +

                    Replacing an ingress

                    +

                    Kubernetes resource

                    +

                    updateIngresses

                    +

                    Replacing a job

                    +

                    Kubernetes resource

                    +

                    updateJobs

                    +

                    Replacing a namespace

                    +

                    Kubernetes resource

                    +

                    updateNamespaces

                    +

                    Replacing a node

                    +

                    Kubernetes resource

                    +

                    updateNodes

                    +

                    Replacing a PersistentVolumeClaim

                    +

                    Kubernetes resource

                    +

                    updatePersistentvolumeclaims

                    +

                    Replacing a pod

                    +

                    Kubernetes resource

                    +

                    updatePods

                    +

                    Replacing a ReplicaSet

                    +

                    Kubernetes resource

                    +

                    updateReplicasets

                    +

                    Replacing a resource quota

                    +

                    Kubernetes resource

                    +

                    updateResourcequotas

                    +

                    Replacing a secret

                    +

                    Kubernetes resource

                    +

                    updateSecrets

                    +

                    Replacing a Service

                    +

                    Kubernetes resource

                    +

                    updateServices

                    +

                    Replacing a StatefulSet

                    +

                    Kubernetes resource

                    +

                    updateStatefulsets

                    +

                    Replacing a status

                    +

                    Kubernetes resource

                    +

                    updateStatus

                    +

                    Uploading a component chart

                    +

                    Kubernetes resource

                    +

                    uploadChart

                    +

                    Updating a component chart

                    +

                    Kubernetes resource

                    +

                    updateChart

                    +

                    Deleting a component chart

                    +

                    Kubernetes resource

                    +

                    deleteChart

                    +

                    Querying a component chart

                    +

                    Kubernetes resource

                    +

                    getChart

                    +

                    Creating a release

                    +

                    Kubernetes resource

                    +

                    createRelease

                    +

                    Updating a release

                    +

                    Kubernetes resource

                    +

                    updateRelease

                    +

                    Deleting a release

                    +

                    Kubernetes resource

                    +

                    deleteRelease

                    +

                    Querying a release

                    +

                    Kubernetes resource

                    +

                    getRelease

                    +

                    Backing up a cluster

                    +

                    Cluster

                    +

                    Snapshot

                    +

                    Querying the snapshot task list of a cluster

                    +

                    Cluster

                    +

                    GetSnapshotTasks

                    +

                    Synchronizing the node pool configuration to existing nodes

                    +

                    Cluster

                    +

                    SyncNodePool

                    +

                    Obtaining tenant permission application records

                    +

                    Cluster

                    +

                    ListPermissionApplyOrders

                    +

                    Applying for tenant permissions

                    +

                    Cluster

                    +

                    CreatePermissionApplyOrder

                    +

                    Adding resource tags to a cluster in a batch

                    +

                    Cluster

                    +

                    BatchCreateDeleteResourceTags

                    +

                    Deleting tags from a cluster in a batch

                    +

                    Cluster

                    +

                    BatchCreateDeleteResourceTags

                    +

                    Creating a partition

                    +

                    Cluster

                    +

                    CreatePartition

                    +

                    Querying a partition

                    +

                    Cluster

                    +

                    GetOnePartition

                    +

                    Querying the partition list of a cluster

                    +

                    Cluster

                    +

                    GetPartitionList

                    +

                    Updating a partition

                    +

                    Cluster

                    +

                    UpdatePartition

                    +

                    Querying a warm-up pool

                    +

                    Cluster

                    +

                    GetWarmUpPool

                    +

                    Querying the warm-up pool list

                    +

                    Cluster

                    +

                    ListWarmUpPool

                    +

                    Updating a warm-up pool

                    +

                    Cluster

                    +

                    UpdateWarmUpPool

                    +

                    Creating a warm-up pool

                    +

                    Cluster

                    +

                    CreateWarmUpPool

                    +

                    Deleting a warm-up pool

                    +

                    Cluster

                    +

                    DeleteWarmUpPool

                    +

                    Querying an upgrade path

                    +

                    Cluster

                    +

                    GetClusterUpgradePaths

                    +

                    Querying upgrade feature gates

                    +

                    Cluster

                    +

                    GetUpgradeFeatureGates

                    +

                    Obtaining an automatic upgrade plan

                    +

                    Cluster

                    +

                    GetUpgradePlans

                    +

                    Deleting an automatic upgrade plan

                    +

                    Cluster

                    +

                    DeleteUpgradePlan

                    +

                    Obtaining a cluster maintenance window

                    +

                    Cluster

                    +

                    GetMaintenanceWindow

                    +

                    Updating a cluster maintenance window

                    +

                    Cluster

                    +

                    UpdateMaintenanceWindow

                    +

                    Creating a cluster maintenance window

                    +

                    Cluster

                    +

                    CreateMaintenanceWindow

                    +

                    Deleting a cluster maintenance window

                    +

                    Cluster

                    +

                    DeleteMaintenanceWindow

                    + + + + + + + + + + + + + + + + + + + + + + +
                    Table 1 Trace filtering parameters

                    Parameter

                    +

                    Description

                    +

                    Trace Type

                    +

                    Select Management or Data.

                    +
                    • Management traces record operations performed by users on cloud service resources, including creation, modification, and deletion.
                    • Data traces are reported by OBS and record operations performed on data in OBS buckets, including uploads and downloads.
                    +

                    Trace Source

                    +

                    Select the name of the cloud service that triggers a trace from the drop-down list.

                    +

                    Resource type

                    +

                    Select the type of the resource involved in a trace from the drop-down list.

                    +

                    For details about the resource types of each cloud service, see section "Supported Services and Operations" in the Cloud Trace Service User Guide.

                    +

                    Search By

                    +

                    Select one of the following options:

                    +
                    • Resource ID: ID of the cloud resource involved in a trace.

                      Leave this field empty if the resource has no resource ID or if resource creation failed.

                      +
                    • Trace name: name of a trace.

                      For details about the operations that can be audited for each cloud service, see section "Supported Services and Operations" in the Cloud Trace Service User Guide.

                      +
                    • Resource name: name of the cloud resource involved in a trace.

                      If the cloud resource involved in the trace does not have a resource name or the corresponding API operation does not involve the resource name parameter, leave this field empty.

                      +
                    +

                    Operator

                    +

                    User who triggers a trace.

                    +

                    Select one or more operators from the drop-down list.

                    +

                    If the value of trace_type in a trace is SystemAction, the operation is triggered by the service and the trace's operator may be empty.

                    +

                    Trace Status

                    +

                    Select one of the following options:

                    +
                    • Normal: The operation succeeded.
                    • Warning: The operation failed.
                    • Incident: The operation caused a fault that is more serious than a normal failure, for example, causing other faults.
                    +
                    +
                    +

                  6. Click Query.
                  7. On the Trace List page, you can also export and refresh the trace list.

                    • Click Export to export all traces in the query result as a CSV file. The file can contain up to 5,000 records.
                    • Click to view the latest information about traces.
                    +

                  8. Click on the left of a trace to expand its details.

                    -

                    -

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

                    -
                  10. For details about key fields in the trace structure, see Trace Structure and Example Traces in the CTS User Guide.
                  11. +

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

                    +

                  13. + +

                    Helpful Links

                    diff --git a/docs/cce/umn/cce_10_0028.html b/docs/cce/umn/cce_10_0028.html index 668a4b988..19ae29c09 100644 --- a/docs/cce/umn/cce_10_0028.html +++ b/docs/cce/umn/cce_10_0028.html @@ -1,360 +1,545 @@

                    Creating a CCE Standard/Turbo Cluster

                    -

                    On the CCE console, you can easily create Kubernetes clusters. After a cluster is created, the master node is hosted by CCE. You only need to create worker nodes. In this way, you can implement cost-effective O&M and efficient service deployment.

                    -

                    Precautions

                    • 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 configurations of the cluster, such as the VPC, subnet, Service CIDR block, IPv6 settings, and kube-proxy settings
                      • Network model. For example, change Tunnel network to VPC network.
                      -
                    -
                    -

                    Step 1: Log In to the CCE Console

                    1. Log in to the CCE console.
                    2. On the Clusters page, click Create Cluster.
                    -
                    -

                    Step 2: Configure the Cluster

                    On the Create Cluster page, configure the parameters.

                    -

                    Basic Settings

                    -

                    +

                    CCE standard and Turbo clusters provide enterprise-class Kubernetes cluster hosting service that supports full lifecycle management of containerized applications. They offer a highly scalable, high-performance solution for deploying and managing cloud native applications. On the CCE console, you can easily create CCE standard and Turbo clusters. After a cluster is created, CCE hosts the master nodes. You only need to create worker nodes. In this way, you can implement cost-effective O&M and efficient service deployment.

                    +

                    Before creating a CCE standard or Turbo cluster, you are advised to learn about What Is CCE? Networking Overview, and Planning CIDR Blocks for a Cluster.

                    +

                    Step 1: Configure Basic Settings

                    Basic settings define the core architecture and underlying resource rules of a cluster, providing a framework for cluster running and resource allocation.

                    +
                    1. Log in to the CCE console. In the upper left corner of the page, click and select a region for your cluster. The closer the selected region is to the region where resources are deployed, the lower the network latency and the faster the access.

                      After confirming the region, click Create Cluster. If you use CCE for the first time, you need to create an agency following instructions.

                      +

                    2. Configure the basic settings of the cluster. For details, see Table 1.

                      -

                      Parameter

                      +
                      - + - - + - - + - - + - - + - - - - -
                      Table 1 Basic settings of a cluster (applicable to standard and Turbo clusters)

                      Parameter

                      Description

                      +

                      Description

                      +

                      Modifiable After Cluster Creation

                      Type

                      +

                      Type

                      Select CCE Standard Cluster or CCE Turbo Cluster as required.

                      -
                      • CCE standard clusters provide highly reliable and secure containers for commercial use.
                      • CCE Turbo clusters use the high-performance cloud native network. Such clusters provide cloud native hybrid scheduling, achieving higher resource utilization and wider scenario coverage.
                      -

                      For more details, see cluster types.

                      +

                      Select CCE Standard Cluster or CCE Turbo Cluster as required.

                      +
                      • CCE standard clusters provide highly reliable and secure containers for commercial use.
                      • CCE Turbo clusters use the high-performance cloud native network. Such clusters provide cloud native hybrid scheduling, achieving higher resource utilization and wider scenario coverage.
                      +

                      For details, see cluster types.

                      +

                      No

                      Cluster Name

                      +

                      Cluster Name

                      Enter a cluster name. Cluster names under the same account must be unique.

                      +

                      Enter a cluster name. Cluster names under the same account must be unique.

                      +

                      Enter 4 to 128 characters. Start with a lowercase letter and do not end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.

                      +

                      Yes

                      Cluster Version

                      +

                      Cluster Version

                      Select the Kubernetes version used by the cluster.

                      +

                      Select a Kubernetes version. The latest commercial version is recommended, and it provides you with more stable, reliable features.

                      +

                      Yes

                      Cluster Scale

                      +

                      Cluster Scale

                      Select a cluster scale for your cluster as required. These values specify the maximum number of nodes that can be managed by the cluster.

                      +

                      Select a cluster scale as required. This parameter controls the maximum number of worker nodes that a cluster can manage.

                      +

                      Yes

                      +

                      The cluster that has been created can only be scaled out. For details, see Changing a Cluster Scale.

                      Master Nodes

                      +

                      Master Nodes

                      Select the number of master nodes. The master nodes are automatically hosted by CCE and deployed with Kubernetes cluster management components such as kube-apiserver, kube-controller-manager, and kube-scheduler.

                      -
                      • 3 Masters: Three master nodes will be created for high cluster availability.
                      • Single: Only one master node will be created in your cluster.
                        NOTE:
                        • If more than half of the master nodes in a CCE cluster are faulty, the cluster cannot function properly.
                        +

                      Select the number of master nodes. The master nodes are automatically hosted by CCE and deployed with Kubernetes cluster management components such as kube-apiserver, kube-controller-manager, and kube-scheduler.

                      +
                      • 3 Masters: Three master nodes will be created for high cluster availability.
                      • Single: Only one master node will be created in your cluster.
                        NOTE:

                        If more than half of the master nodes in a CCE cluster are faulty, the cluster cannot function properly.

                      -
                      You can also select AZs for deploying the master nodes of a specific cluster. By default, AZs are allocated automatically for the master nodes.
                      • Automatic: Master nodes are randomly distributed in different AZs for cluster DR. If the number of available AZs is less than the number of nodes to be created, CCE will create the nodes in the AZs with sufficient resources to preferentially ensure cluster creation. In this case, AZ-level DR may not be ensured.
                      • Custom: Master nodes are deployed in specific AZs.
                        If there is one master node in your cluster, you can select one AZ for the master node. If there are multiple master nodes in your cluster, you can select multiple AZs for the master nodes.
                        • AZ: Master nodes are deployed in different AZs for cluster DR.
                        • Host: Master nodes are deployed on different hosts in the same AZ for cluster DR.
                        • Custom: Master nodes are deployed in the AZs you specified.
                        +
                        You can also select AZs for deploying the master nodes of a specific cluster. By default, AZs are allocated automatically for the master nodes.
                        • Automatic: Master nodes are randomly distributed in different AZs for cluster DR. If there are not enough AZs available, CCE will prioritize assigning nodes in AZs with enough resources to ensure cluster creation. However, this may result in AZ-level DR not being guaranteed.
                        • Custom: Master nodes are deployed in specific AZs.
                          If there is one master node in a cluster, you can select one AZ for the master node. If there are multiple master nodes in a cluster, you can select multiple AZs for the master nodes.
                          • AZ: Master nodes are deployed in different AZs for cluster DR.
                          • Host: Master nodes are deployed on different hosts in the same AZ for cluster DR.
                          • Custom: Master nodes are deployed in the AZs you specified.
                      -
                      -

                      Network Settings

                      -

                      The network settings cover nodes, containers, and Services. For details about the cluster networking and container network models, see Overview.

                      -

                      - -
                      - - - - - - - - - - - - - -
                      Table 1 Cluster network settings

                      Parameter

                      -

                      Description

                      -

                      VPC

                      -

                      Select the VPC to which the cluster belongs. If no VPC is available, click Create VPC to create one. The value cannot be changed after the cluster is created.

                      -

                      Node Subnet

                      -

                      Select the subnet to which the master nodes belong. If no subnet is available, click Create Subnet to create one. The value cannot be changed after the cluster is created.

                      -

                      Default Node Security Group

                      -
                      Select the security group automatically generated by CCE or use the existing one as the default security group of the node.
                      NOTICE:

                      The default security group must allow traffic from certain ports to ensure normal communication. Otherwise, the node cannot be created. For details, see Configuring Cluster Security Group Rules.

                      -
                      -
                      -

                      IPv6

                      -

                      If enabled, cluster resources, including nodes and workloads, can be accessed through IPv6 CIDR blocks.

                      -
                      • IPv4/IPv6 dual stack is not supported by clusters using the VPC networks.
                      +

                      No

                      +

                      After the cluster is created, the number of master nodes and the AZs where they are deployed cannot be changed.

                      -

                      +

                      + +

                      Step 2: Configure Network Settings

                      Network configuration follows a hierarchical management system. It ensures end-to-end network connectivity and security assurance for containerized applications through collaborative configuration of the cluster networks, container networks, and Service networks.

                      +
                      • Cluster network: handles communication between nodes, transmitting pod and Service traffic while ensuring cluster infrastructure connectivity and security.
                      • Container network: assigns each pod an independent IP address, enabling direct container communication and cross-node communication.
                      • Service network: establishes a stable access entry, supports load balancing, and optimizes traffic management for Services within a cluster.
                      +

                      Before configuring the network settings, you are advised to learn the concepts and relationships of the three types of networks. For details, see Networking Overview.

                      +
                      +

                      Configuring Network Settings for a CCE Standard Cluster

                      1. Configure cluster network settings. For details, see Table 2.

                        -
                        Table 2 Container network settings

                        Parameter

                        +
                        - + - - + - - + + + + + + + + + + + +
                        Table 2 Cluster network settings

                        Parameter

                        Description

                        +

                        Description

                        +

                        Modifiable After Cluster Creation

                        Network Model

                        +

                        VPC

                        Select VPC network or Tunnel network for your CCE standard cluster.

                        -

                        Select Cloud Native Network 2.0 for your CCE Turbo cluster.

                        -

                        For more information about their differences, see Overview.

                        +

                        Select a VPC for a cluster.

                        +

                        If no VPC is available, click Create VPC to create one. After the VPC is created, click the refresh icon.

                        +

                        No

                        DataPlane V2 (supported by CCE Turbo clusters)

                        +

                        Default Node Subnet

                        DataPlane V2 uses eBPF to enable features like Service ClusterIP, NetworkPolicy, and egress bandwidth. For details, see DataPlane V2 Network Acceleration.

                        -

                        This function is available for new clusters of v1.27 or later. After this function is enabled, CCE will automatically deploy the cilium-agent on every node in the cluster. Each cilium-agent will use 80 MiB of memory, and the memory usage will increase by 10 KiB whenever a new pod is added. After the cluster is created, you cannot disable this function. Additionally, the nodes can run only HCE OS 2.0. Therefore, enable this function only when you fully understand the constraints in DataPlane V2 Network Acceleration.

                        -
                        NOTE:

                        CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.

                        +

                        Select a subnet. Once selected, all nodes in the cluster will automatically use the IP addresses assigned within that subnet. However, during node or node pool creation, the subnet settings can be reconfigured.

                        +

                        No

                        +

                        Default Node Security Group

                        +

                        Select the security group automatically generated by CCE or select an existing one.

                        +

                        The default node security group must allow traffic from certain ports to ensure normal communication. Otherwise, the node cannot be created. For details, see Configuring Cluster Security Group Rules.

                        +

                        Yes

                        +

                        IPv6

                        +

                        After this function is enabled, the cluster supports the IPv4/IPv6 dual-stack, meaning each worker node can have both an IPv4 and IPv6 address. Both IP addresses support private and public network access. Before enabling this function, ensure that Default Node Subnet includes an IPv6 CIDR block.

                        +
                        • CCE standard clusters (using VPC networks): IPv6 is not supported.
                        +

                        No

                        +
                        +
                        +

                      2. Configure container network parameters. For details, see Table 3.

                        + +
                        + + + + + + + + + + - - - - - + - - - - - - - - - - -
                        Table 3 Container network settings

                        Parameter

                        +

                        Description

                        +

                        Modifiable After Cluster Creation

                        +

                        Network Model

                        +
                        The network model used by the container network in a cluster.
                        • Tunnel network: applies to large clusters (with up to 2000 nodes) and scenarios that do not demand high performance such as web applications and data middle- and back-end services with low access traffic.
                        • VPC network: applies to small clusters (with 1000 nodes or fewer) and scenarios that demand high performance such as AI and big data computing.
                        +
                        +

                        For more details about their differences, see Overview.

                        +

                        No

                        +

                        DataPlane V2 (supported by clusters using the VPC networks)

                        +

                        eBPF is used at the kernel layer for Kubernetes network acceleration, enhancing high-performance service communication through ClusterIP Services, precise traffic control via network policies, and intelligent bandwidth management with egress bandwidth. For details, see DataPlane V2 Network Acceleration.

                        +

                        This function has the restrictions below. For details, see the restrictions in DataPlane V2 Network Acceleration.

                        +
                        • Restrictions on clusters: This function can be enabled only for clusters of v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, or later that use VPC networks.
                        • Restrictions on memory: After this function is enabled, CCE will automatically deploy the cilium-agent on every node in a cluster. Each cilium-agent will use 80 MiB of memory, and the memory usage will increase by 10 KiB whenever a new pod is added.
                        • Restrictions on OSs: After a node is created, it can only use HCE OS 2.0.
                        +
                        NOTE:

                        CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.

                        Network Policies (supported by CCE standard clusters using a tunnel network)

                        -

                        Policy-based network control for clusters. For details, see Configuring Network Policies to Restrict Pod Access.

                        -

                        After this function is enabled, if the CIDR blocks of a customer's service conflict with the on-premises CIDR blocks, the link to a newly added gateway may not be established.

                        -

                        For example, when a cluster accesses an external address through a Direct Connect connection, the external switch does not support ip-option. If the network policy is enabled, the network access may fail.

                        +

                        No

                        Container CIDR Block

                        +

                        Network Policies (supported by clusters using the tunnel networks)

                        Specify the CIDR block for containers, which determines the maximum number of containers allowed in the cluster. This parameter is available only for CCE standard clusters. CCE standard clusters allow both manual and automatic CIDR block settings.

                        -
                        • Manually set: You can customize the container CIDR blocks as needed. For cross-VPC passthrough networking, make sure the container CIDR block does not overlap with the VPC CIDR block to be accessed to prevent conflicts. For details, see Planning CIDR Blocks for a Cluster. The VPC network model allows you to configure multiple CIDR blocks, and container CIDR blocks can be added even after the cluster is created. For details, see Adding a Container CIDR Block for a Cluster.
                        • Auto select: CCE will randomly allocate a non-conflicting CIDR block from the ranges 172.16.0.0/16 to 172.31.0.0/16, or from 10.0.0.0/12, 10.16.0.0/12, 10.32.0.0/12, 10.48.0.0/12, 10.64.0.0/12, 10.80.0.0/12, 10.96.0.0/12, and 10.112.0.0/12. Since the allocated CIDR block cannot be modified after the cluster is created, you are advised to manually configure the CIDR blocks, especially in commercial scenarios.
                        +

                        Policy-based network control for a cluster. For details, see Configuring Network Policies to Restrict Pod Access.

                        +

                        After this function is enabled, if the CIDR blocks of a customer's service conflict with the on-premises CIDR blocks, the link to a newly added gateway may not be established.

                        +

                        For example, if a cluster uses a Direct Connect connection to access an external address, the external switch does not support ip-option. Enabling network policies in this scenario could result in network access failure.

                        +

                        Yes

                        Pod IP Addresses Reserved for Each Node (supported by CCE standard clusters using a VPC network)

                        +

                        Container CIDR Block

                        Specify the number of container IP addresses that can be allocated to each node (alpha.cce/fixPoolMask) when creating a cluster. This parameter determines the maximum number of pods that can be created on each node and cannot be changed after the cluster is created.

                        -

                        When a container network is used, each pod occupies one IP address. If a node's reserved container IP addresses are insufficient, pods cannot be created. For details, see Number of Allocatable Container IP Addresses on a Node.

                        -

                        Pod Subnet

                        -

                        Select the subnet to which the pod belongs. If no subnet is available, click Create Subnet to create one. This parameter is available only for CCE Turbo clusters. The pod subnet determines the maximum number of containers in a cluster. You can add pod subnets after a cluster is created.

                        -

                        Default Security Group

                        -
                        Select the security group automatically generated by CCE or use the existing one as the default security group of the containers.
                        NOTICE:

                        The default security group of containers must allow access from specified ports to ensure proper communication between containers in the cluster. For details about how to configure security group ports, see How Do I Harden the Automatically Created Security Group Rules for CCE Cluster Nodes?

                        -
                        -
                        -
                        -
                        -

                        - -
                        - - - - - - - - - - - - - -
                        Table 3 Service network settings

                        Parameter

                        -

                        Description

                        -

                        Service CIDR Block

                        -

                        Configure the Service CIDR blocks for 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 the cluster is created.

                        -

                        Request Forwarding

                        -

                        Select IPVS or iptables for your cluster. For details, see Comparing iptables and IPVS.

                        -
                        • iptables is the traditional kube-proxy mode. This mode applies to the scenario where the number of Services is small or a large number of short connections are concurrently sent on the client. IPv6 clusters do not support iptables.
                        • IPVS allows higher throughput and faster forwarding. This mode is suitable for large cluster scales or when there are a large number of Services.
                        -

                        IPv6 Service CIDR Block

                        -

                        Configure this parameter only when IPv6 dual stack is enabled for a CCE Turbo cluster. This configuration cannot be modified after the cluster is created.

                        -
                        -
                        -

                        (Optional) Advanced Settings

                        -

                        - -
                        - - - - - - - - - - - - - - - - - - - - - - - - - - - -

                        Parameter

                        -

                        Description

                        -

                        IAM Authentication

                        -

                        CCE clusters support IAM authentication. You can call IAM authenticated APIs to access CCE clusters.

                        -

                        Certificate Authentication

                        -
                        • If Automatically generated is selected, the X.509-based authentication mode will be enabled by default. X.509 is a commonly used certificate format.
                        • If Bring your own is selected, the cluster can identify users based on the header in the request body for authentication.

                          Upload your CA root certificate, client certificate, and private key.

                          -
                          CAUTION:
                          • 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 root certificate is used by the authentication proxy and for configuring the kube-apiserver aggregation layer. If any of the uploaded certificates is invalid, the cluster cannot be created.
                          • Starting from v1.25, Kubernetes no longer supports certificate authentication generated using the SHA1WithRSA or ECDSAWithSHA1 algorithm. The certificate authentication generated using the SHA256 algorithm is supported instead.
                          +

                        CIDR block used by containers. This parameter determines the maximum number of containers in the cluster. CCE standard clusters support:

                        +
                        • Manually set: You can customize the container CIDR blocks as needed. For cross-VPC passthrough networking, make sure the container CIDR block does not overlap with the VPC CIDR block to be accessed to prevent conflicts. For details, see Planning CIDR Blocks for a Cluster. The VPC network model allows you to configure multiple CIDR blocks, and container CIDR blocks can be added even after the cluster is created. For details, see Expanding the Container CIDR Block of a Cluster That Uses a VPC Network.
                        • Auto select: CCE will randomly allocate a non-conflicting CIDR block from the ranges 172.16.0.0/16 to 172.31.0.0/16, or from 10.0.0.0/12, 10.16.0.0/12, 10.32.0.0/12, 10.48.0.0/12, 10.64.0.0/12, 10.80.0.0/12, 10.96.0.0/12, and 10.112.0.0/12. Since the allocated CIDR block cannot be modified after the cluster is created, you are advised to manually configure the CIDR blocks, especially in commercial scenarios.
                          NOTE:

                          After a cluster using a container tunnel network is created, the container CIDR block cannot be expanded later. To prevent IP address exhaustion, it is advised to set the container CIDR block with a maximum mask length of 19 bits.

                        CPU Management

                        -

                        If enabled, exclusive CPU cores can be allocated to workload pods. For details, see CPU Policy.

                        +

                        No

                        +

                        After a cluster using a VPC network is created, you can add container CIDR blocks to the cluster but cannot modify or delete the existing ones.

                        Disk Encryption for Master Nodes

                        +

                        Pod IP Addresses Reserved for Each Node (supported by clusters using the VPC networks)

                        If enabled, dynamic data and static data on disks can be encrypted, providing powerful security protection for your data.

                        -

                        After encryption, the disk read/write performance deteriorates, and the configuration cannot be modified after the cluster is created.

                        -

                        This function is available only for clusters of v1.25 or later.

                        +

                        The number of pod IP addresses that can be allocated on each node (alpha.cce/fixPoolMask). This parameter determines the maximum number of pods that can be created on each node.

                        +

                        In a container network, each pod is assigned a unique IP address. If the number of pod IP addresses reserved for each node is insufficient, pods cannot be created. For details, see Number of Allocatable Pod IP Addresses on a Node.

                        Overload Control

                        -

                        After this function is enabled, concurrent requests will be dynamically controlled based on the resource demands received by master nodes to ensure the stable running of the master nodes and the cluster. For details, see Enabling Overload Control for a Cluster.

                        -

                        Cluster Deletion Protection

                        -

                        A measure taken to prevent accidental deletion of clusters through the console or APIs. After this function is enabled, you will not be able to delete or unsubscribe from clusters on CCE. You can modify the function status in the cluster Settings after creating it.

                        -

                        Time Zone

                        -

                        The cluster's scheduled tasks and nodes are subject to the chosen time zone.

                        -

                        Resource Tag

                        -

                        You can add resource tags to classify resources. A maximum of 20 resource tags can be added.

                        -

                        You can create predefined tags on the TMS console. These tags are available to all resources that support tags. You can use these tags to improve the tag creation and resource migration efficiency.

                        -

                        Description

                        -

                        You can enter description for the cluster. A maximum of 200 characters are allowed.

                        +

                        No

                        - -

                        Step 3: Select Add-ons

                        Click Next: Select Add-on. On the page displayed, select the add-ons to be installed during cluster creation.

                        -

                        -

                        Basic capabilities

                        +

                      3. Configure Service network parameters. For details, see Table 4.

                        -

                        Add-on Name

                        +
                        - + - - + - - - - -
                        Table 4 Service network settings

                        Parameter

                        Description

                        +

                        Description

                        +

                        Modifiable After Cluster Creation

                        CCE Container Network (Yangtse CNI)

                        +

                        Service CIDR Block

                        This is the basic cluster add-on. It provides network connectivity, Internet access, and security isolation for pods in your cluster.

                        +

                        Configure an IP address range for the ClusterIP Services in a cluster. This parameter controls the maximum number of ClusterIP Services in a cluster. ClusterIP Services enable communication between containers in a cluster. The Service CIDR block cannot overlap with the node subnet or container CIDR block.

                        +

                        No

                        CCE Container Storage (Everest)

                        +

                        Request Forwarding

                        This add-on (CCE Container Storage (Everest)) is installed by default. It is a cloud native container storage system based on CSI and supports cloud storage services such as EVS.

                        +

                        Configure load balancing and route forwarding of Service traffic in a cluster. IPVS and iptables are supported. For details, see Comparing iptables and IPVS.

                        +
                        • iptables: the traditional kube-proxy mode. It applies to the scenario where the number of Services is small or a large number of short connections are concurrently sent on the client. IPv6 clusters do not support iptables.
                        • IPVS: allows higher throughput and faster forwarding. It is suitable for large clusters or when there are a large number of Services.

                        CoreDNS

                        -

                        This add-on (CoreDNS) is installed by default. It provides DNS resolution for your cluster and can be used to access the in-cloud DNS server.

                        +

                        No

                        -
                        Observability -
                        - - - - - - - - - - - - - -

                        Add-on Name

                        -

                        Description

                        -

                        Cloud Native Cluster Monitoring

                        -

                        (Optional) If selected, this add-on (Cloud Native Cluster Monitoring) will be automatically installed. Cloud Native Cluster Monitoring collects monitoring metrics for your cluster and reports the metrics to AOM. The agent mode does not support HPA based on custom Prometheus statements. If related functions are required, install this add-on manually after the cluster is created.

                        -

                        Cloud Native Logging

                        -

                        (Optional) If selected, this add-on (Cloud Native Log Collection) will be automatically installed. Cloud Native Logging helps report logs to LTS. After the cluster is created, you are allowed to obtain and manage collection rules on the Logging page of the CCE cluster console.

                        -

                        CCE Node Problem Detector

                        -

                        (Optional) If selected, this add-on (CCE Node Problem Detector) will be automatically installed to detect faults and isolate nodes for prompt cluster troubleshooting.

                        -
                        +

                        -
                        - -

                        Step 4: Configure Add-ons

                        Click Next: Add-on Configuration.

                        -

                        Basic capabilities

                        +

                        Configuring Network Settings for a CCE Turbo Cluster

                        1. Configure cluster network settings. For details, see Table 5.

                          -

                          Add-on Name

                          +
                          - + - - + - - + - - + + + + +
                          Table 5 Cluster network settings

                          Parameter

                          Description

                          +

                          Description

                          +

                          Modifiable After Cluster Creation

                          CCE Container Network (Yangtse CNI)

                          +

                          VPC

                          This add-on is unconfigurable.

                          +

                          Select a VPC for a cluster.

                          +

                          If no VPC is available, click Create VPC to create one. After the VPC is created, click the refresh icon.

                          +

                          No

                          CCE Container Storage (Everest)

                          +

                          Default Node Subnet

                          This add-on is unconfigurable. After the cluster is created, choose Add-ons in the navigation pane of the cluster console and modify the configuration.

                          +

                          Select a subnet. Once selected, all nodes in the cluster will automatically use the IP addresses assigned within that subnet. However, during node or node pool creation, the subnet settings can be reconfigured.

                          +

                          No

                          CoreDNS

                          +

                          Default Node Security Group

                          This add-on is unconfigurable. After the cluster is created, choose Add-ons in the navigation pane of the cluster console and modify the configuration.

                          +

                          Select the security group automatically generated by CCE or select an existing one.

                          +

                          The default node security group must allow traffic from certain ports to ensure normal communication. Otherwise, the node cannot be created. For details, see Configuring Cluster Security Group Rules.

                          +

                          Yes

                          +

                          IPv6

                          +

                          After this function is enabled, the cluster supports the IPv4/IPv6 dual-stack, meaning each worker node can have both an IPv4 and IPv6 address. Both IP addresses support private and public network access. Before enabling this function, ensure that Default Node Subnet includes an IPv6 CIDR block.

                          +
                          • CCE standard clusters (using VPC networks): IPv6 is not supported.
                          +

                          No

                          -

                          Observability

                          -

                          -
                          -

                          Add-on Name

                          +

                        2. Configure container network parameters. For details, see Table 6.

                          + +
                          - + - - + - - + - - + + + + + + + +
                          Table 6 Container network settings

                          Parameter

                          Description

                          +

                          Description

                          +

                          Modifiable After Cluster Creation

                          Cloud Native Cluster Monitoring

                          +

                          Network Model

                          Select an AOM instance for Cloud Native Cluster Monitoring to report metrics. If no AOM instance is available, click Creating Instance to create one.

                          +

                          The network model used by the container network in a cluster. Only Cloud Native Network 2.0 is supported.

                          +

                          For more details about this network model, see Overview.

                          +

                          No

                          Cloud Native Logging

                          +

                          DataPlane V2

                          Select the logs to be collected. If enabled, a log group named k8s-log-{clusterId} will be automatically created, and a log stream will be created for each selected log type.

                          -
                          • Container log: Standard output logs of containers are collected. The corresponding log stream is named in the format of stdout-{Cluster ID}.
                          • Kubernetes Events: Kubernetes logs are collected. The corresponding log stream is named in the format of event-{Cluster ID}.
                          • Kubernetes Audit Logs: Audit logs of the master nodes are collected. The log streams are named in the format of audit-{Cluster ID}.
                          • Control Plane Logs: Logs from critical components such as kube-apiserver, kube-controller-manage, and kube-scheduler that run on the master nodes are collected. The log streams are named in the format of kube-apiserver-{Cluster ID}, kube-controller-manage-{Cluster ID}, and kube-scheduler-{Cluster ID}, respectively.
                          -

                          If log collection is disabled, choose Logging in the navigation pane of the cluster console after the cluster is created and enable this function.

                          +

                          eBPF is used at the kernel layer for Kubernetes network acceleration, enhancing high-performance service communication through ClusterIP Services, precise traffic control via network policies, and intelligent bandwidth management with egress bandwidth. For details, see DataPlane V2 Network Acceleration.

                          +

                          This function has the restrictions below. For details, see the restrictions in DataPlane V2 Network Acceleration.

                          +
                          • Restrictions on clusters: The cluster version must be v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later.
                          • Restrictions on memory: After this function is enabled, CCE will automatically deploy the cilium-agent on every node in a cluster. Each cilium-agent will use 80 MiB of memory, and the memory usage will increase by 10 KiB whenever a new pod is added.
                          • Restrictions on OSs: After a node is created, it can only use HCE OS 2.0.
                          +
                          NOTE:

                          CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.

                          +
                          +

                          No

                          CCE Node Problem Detector

                          +

                          Pod Subnet

                          This add-on is unconfigurable. After the cluster is created, choose Add-ons in the navigation pane of the cluster console and modify the configuration.

                          +

                          Select the subnet to which the pod belongs. If no subnet is available, click Create Subnet to create one. The pod subnet determines the maximum number of containers in a cluster. You can add pod subnets after a cluster is created.

                          +

                          Yes

                          +

                          Default Security Group

                          +

                          Select the security group automatically generated by CCE or select an existing one. This parameter controls inbound and outbound traffic to prevent unauthorized access.

                          +

                          The default security group of containers must allow access from specified ports to ensure proper communication between containers in the cluster. For details about how to configure security group ports, see How Do I Harden the Automatically Created Security Group Rules for CCE Cluster Nodes?

                          +

                          Yes

                          +
                          +
                          +

                        3. Configure Service network parameters. For details, see Table 7.

                          + +
                          + + + + + + + + + + + + + + + + + +
                          Table 7 Service network settings

                          Parameter

                          +

                          Description

                          +

                          Modifiable After Cluster Creation

                          +

                          Service CIDR Block

                          +

                          Configure an IP address range for the ClusterIP Services in a cluster. This parameter controls the maximum number of ClusterIP Services in a cluster. ClusterIP Services enable communication between containers in a cluster. The Service CIDR block cannot overlap with the node subnet or container CIDR block.

                          +

                          No

                          +

                          Request Forwarding

                          +

                          Configure load balancing and route forwarding of Service traffic in a cluster. IPVS and iptables are supported. For details, see Comparing iptables and IPVS.

                          +
                          • iptables: the traditional kube-proxy mode. It applies to the scenario where the number of Services is small or a large number of short connections are concurrently sent on the client. IPv6 clusters do not support iptables.
                          • IPVS: allows higher throughput and faster forwarding. It is suitable for large clusters or when there are a large number of Services.
                          +

                          No

                          +

                          IPv6 Service CIDR Block

                          +

                          Configure IPv6 addresses for Services. This parameter is only available after IPv6 is enabled.

                          +

                          No

                          +
                          +
                          +

                        4. + +

                          (Optional) Step 3: Configure Advanced Settings

                          Advanced settings extend and strengthen previous settings, enhancing security, stability, and compliance within clusters. This is achieved through capabilities like improved authentication, resource management, and security mechanisms.

                          +

                          + +
                          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
                          Table 8 Advanced settings

                          Parameter

                          +

                          Description

                          +

                          Modifiable After Cluster Creation

                          +

                          IAM Authentication

                          +

                          CCE clusters support IAM authentication. You can call IAM authenticated APIs to access CCE clusters.

                          +

                          No

                          +

                          Certificate Authentication

                          +

                          Certificate authentication is used for identity authentication and access control. It ensures that only authorized users or services can access specific cluster.

                          +
                          • Automatically generated: CCE automatically creates and hosts X.509 certificates for your clusters. It automatically maintains and rotates cluster certificates.
                          • Bring your own: You can add a custom certificate to your cluster and use this certificate for authentication. In this case, you need to upload CA root certificate, client certificate, and client certificate private key.
                            CAUTION:
                            • Upload a file smaller than 1 MiB. 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 root certificate is used by the authentication proxy and for configuring the kube-apiserver aggregation layer. If any of the uploaded certificates is invalid, the cluster cannot be created.
                            • In clusters of v1.25 and later, Kubernetes no longer supports certificate authentication generated using the SHA1WithRSA or ECDSAWithSHA1 algorithms. You are advised to use the certificates generated using the SHA-256 algorithm for authentication.
                            +
                            +
                          +

                          No

                          +

                          CPU Management

                          +

                          CPU management policies allow precise control over CPU allocation for pods. For details, see CPU Policy.

                          +
                          • Disabled: The default CPU affinity policy is used. Affinity policies other than the default behavior of the OS scheduler are not provided. While many CPUs remain available in the shared pool, workloads cannot exclusively use any of them.
                          • Enabled: Workload pods can exclusively use CPUs. If a pod with a QoS class of Guaranteed requests an integer number of CPUs, the containers within the pod are pinned to physical CPUs on the host node. This mode benefits workloads sensitive to CPU cache hit ratio and scheduling latency.
                          +

                          Yes

                          +

                          Disk Encryption for Master Nodes

                          +

                          After this function is enabled, dynamic and static data on disks can be encrypted, providing strong security protection for your data.

                          +

                          After encryption, the disk read/write performance deteriorates. This function is available only for clusters of v1.25 or later.

                          +

                          No

                          +

                          Overload Control

                          +

                          After this function is enabled, concurrent requests will be dynamically controlled based on the resource demands received by master nodes, ensuring stable running of the master nodes and the cluster. For details, see Enabling Overload Control for a Cluster.

                          +

                          Yes

                          +

                          Cluster Deletion Protection

                          +

                          After this function is enabled, you will not be able to delete or unsubscribe from clusters on CCE. This option is a measure to prevent accidental deletion of clusters through the console or APIs. You can modify the function status in Settings after creating it.

                          +

                          Yes

                          +

                          Time Zone

                          +

                          The cluster's scheduled tasks and nodes are subject to the chosen time zone.

                          +

                          ×

                          +

                          Resource Tag

                          +

                          Adding tags to resources allows for customized classification and organization. A maximum of 20 resource tags can be added.

                          +

                          You can create predefined tags on the TMS console. These tags are available to all resources that support tags. You can use these tags to improve the tag creation and resource migration efficiency.

                          +

                          Yes

                          +

                          Description

                          +

                          Cluster description helps users and administrators quickly understand the basic settings, status, and usage of a cluster. The description can contain a maximum of 200 characters.

                          +

                          Yes

                          +

                          Step 4: Select Add-ons

                          CCE provides a variety of add-ons to extend cluster functions and enhance the functionality and flexibility of containerized applications. You can select add-ons as required. Some basic add-ons are set as mandatory by default. If non-basic add-ons are not installed during cluster creation, they can still be added later on the Add-ons page after the cluster is created.

                          +
                          1. Click Next: Select Add-on. On the page displayed, select the add-ons to be installed during cluster creation.
                          2. Select basic add-ons to ensure the proper running of the cluster. For details, see Table 9.

                            + +
                            + + + + + + + + + + + + + + + + +
                            Table 9 Basic add-ons

                            Add-on

                            +

                            Description

                            +

                            CCE Container Network (Yangtse CNI)

                            +

                            This add-on provides network connectivity, Internet access, and security isolation for pods in a cluster. It is the basic cluster add-on.

                            +

                            CCE Container Storage (Everest)

                            +

                            This add-on (CCE Container Storage (Everest)) is installed by default. It is a cloud native container storage system based on CSI and supports cloud storage services such as EVS.

                            +

                            CoreDNS

                            +

                            This add-on (CoreDNS) is installed by default. It provides DNS resolution for your cluster and can be used to access the in-cloud DNS server.

                            +

                            NodeLocal DNSCache

                            +

                            (Optional) After you select this option, CCE will automatically install NodeLocal DNSCache. NodeLocal DNSCache improves cluster DNS performance by running a DNS cache proxy on cluster nodes.

                            +
                            -

                            Step 5: Confirm the Configuration

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

                            -

                            It takes about 5 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.

                            +

                          3. Select the observability add-ons to experience the full observability function. For details, see Table 9.

                            +
                            + + + + + + + + + + + + + +
                            Table 10 Observability add-ons

                            Add-on

                            +

                            Description

                            +

                            Cloud Native Cluster Monitoring

                            +

                            (Optional) After you select this option, CCE will automatically install Cloud Native Cluster Monitoring. Cloud Native Cluster Monitoring collects monitoring metrics for your cluster and reports the metrics to AOM. The agent mode does not support HPA based on custom Prometheus statements. If related functions are required, install this add-on manually after the cluster is created.

                            +

                            Cloud Native Log Collection

                            +

                            (Optional) After you select this option, CCE will automatically install Cloud Native Log Collection. Cloud Native Log Collection helps report logs to LTS. After the cluster is created, you are allowed to obtain and manage collection rules on the Logging page of the CCE cluster console.

                            +

                            CCE Node Problem Detector

                            +

                            (Optional) After you select this option, CCE will automatically install CCE Node Problem Detector to detect faults and isolate nodes for prompt cluster troubleshooting.

                            +
                            -

                            Related Operations

                            +
                            +

                          +
                          +

                          Step 5: Configure Add-ons

                          Configure the selected add-ons to ensure they operate stably and accurately and meet service requirements.

                          +
                          1. Click Next: Configure Add-on.
                          2. Configure the basic add-ons. For details, see Table 11.

                            +

                            + + + + + + + + + + + + + + + + +
                            Table 11 Basic add-on settings

                            Add-on

                            +

                            Description

                            +

                            CCE Container Network (Yangtse CNI)

                            +

                            This add-on is unconfigurable.

                            +

                            CCE Container Storage (Everest)

                            +

                            This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.

                            +

                            CoreDNS

                            +

                            This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.

                            +

                            NodeLocal DNSCache

                            +

                            This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.

                            +
                            +
                            +

                          3. Configure the observability add-ons. For details, see Table 12.

                            +
                            + + + + + + + + + + + + + +
                            Table 12 Observability add-on settings

                            Add-on

                            +

                            Description

                            +

                            Cloud Native Cluster Monitoring

                            +

                            Select an AOM instance for Cloud Native Cluster Monitoring to report metrics. If no AOM instance is available, click Creating Instance to create one.

                            +

                            Cloud Native Log Collection

                            +

                            Select the logs to be collected. If enabled, a log group named k8s-log-{clusterId} will be automatically created, and a log stream will be created for each selected log type.

                            +
                            • Container log: Standard output logs of containers are collected. The corresponding log stream is named in the format of stdout-{Cluster ID}.
                            • Kubernetes Events: Kubernetes logs are collected. The corresponding log stream is named in the format of event-{Cluster ID}.
                            • Kubernetes Audit Logs: Audit logs of the master nodes are collected. The log streams are named in the format of audit-{Cluster ID}.
                            • Control Plane Logs: Logs from critical components such as kube-apiserver, kube-controller-manage, and kube-scheduler that run on the master nodes are collected. The log streams are named in the format of kube-apiserver-{Cluster ID}, kube-controller-manage-{Cluster ID}, and kube-scheduler-{Cluster ID}, respectively.
                            +

                            If log collection is disabled, choose Logging in the navigation pane of the cluster console after the cluster is created and enable this option.

                            +

                            CCE Node Problem Detector

                            +

                            This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.

                            +
                            +
                            +
                            +

                          +
                          +

                          Helpful Links

                          diff --git a/docs/cce/umn/cce_10_0031.html b/docs/cce/umn/cce_10_0031.html index 4e83e4dc2..12e59de3f 100644 --- a/docs/cce/umn/cce_10_0031.html +++ b/docs/cce/umn/cce_10_0031.html @@ -1,9 +1,11 @@ -

                          Managing a Cluster

                          +

                          Managing Clusters

                          How the Add-on Works

                          An Nginx ingress consists of the ingress object, ingress controller, and Nginx. The ingress controller assembles ingresses into the Nginx configuration file (nginx.conf) and reloads Nginx to make the configuration changes apply. When it detects that the pod in a Service changes, it dynamically changes the upstream server group configuration of Nginx. In this case, the Nginx process does not need to be reloaded. Figure 1 shows how this add-on works.

                          • An ingress is a group of access rules that forward requests to specified Services based on domain names or URLs. Ingresses are stored in the object storage service etcd and are added, deleted, modified, and queried through APIs.
                          • The ingress controller monitors the changes of resource objects such as ingresses, Services, endpoints, secrets (mainly TLS certificates and keys), nodes, and ConfigMaps in real time and automatically performs operations on Nginx.
                          • Nginx implements load balancing and access control at the application layer.
                          -
                          Figure 1 Working principles of NGINX Ingress Controller
                          +
                          Figure 1 Working principles of NGINX Ingress Controller

                          Precautions

                          • For clusters earlier than v1.23, kubernetes.io/ingress.class: "nginx" must be added to the annotation of the ingress created through the API.
                          • A dedicated load balancer must be of the network type (TCP/UDP) and support private networks (with a private IP address).
                          • If the node where NGINX Ingress Controller runs and containers on this node cannot access Nginx ingress, you need to configure anti-affinity for the workload pods and Nginx Ingress Controller. For details, see Configuring Anti-Affinity Between a Workload and Nginx Ingress Controller.
                          • During the NGINX Ingress Controller pod upgrade, 10s are reserved for deleting the NGINX Ingress Controller at the ELB backend.
                          • The timeout duration for the graceful exit of the NGINX Ingress Controller is 300s. If the timeout duration is longer than 300s during the upgrade of the NGINX Ingress Controller, persistent connections will be disconnected, and connectivity will be interrupted for a short period of time.

                          Prerequisites

                          Before installing this add-on, you have one available cluster and there is a node running properly. If no cluster is available, create one according to Creating a CCE Standard/Turbo Cluster.

                          -

                          Installing the Add-on

                          1. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Add-ons, locate NGINX Ingress Controller on the right, and click Install.
                          2. On the Install Add-on page, configure the specifications as needed.

                            You can adjust the number of add-on pods and resource quotas as required. High availability is not possible with a single pod. If an error occurs on the node where the add-on instance runs, the add-on will fail.

                            +

                            Installing the Add-on

                            1. Log in to the CCE console and click the cluster name to access the cluster console.
                            2. In the navigation pane, choose Add-ons. Locate NGINX Ingress Controller on the right and click Install.
                            3. On the Install Add-on page, configure the specifications as needed.

                              You can adjust the number of add-on pods and resource quotas as required. High availability is not possible with a single pod. If an error occurs on the node where the add-on instance runs, the add-on will fail.

                            4. Configure the add-on parameters.

                              • Ingress Class: Enter a controller name. The name of each controller in the same cluster must be unique and cannot be set to cce (which is the unique identifier of the LoadBalancer ingress controller.) When creating an ingress, you can specify the controller name to declare which controller should manage this ingress.
                              • Add-on Namespace: Select a namespace for the ingress controller.
                              • Load Balancer: Select a shared or dedicated load balancer. If no load balancer is available, create one. The load balancer has at least two listeners, and ports 80 and 443 are not occupied by listeners.
                              • Admission Check: Admission control is performed on Ingresses to ensure that the controller can generate valid configurations. Admission verification is performed on the configuration of Nginx Ingresses. If the verification fails, the request will be intercepted. For details about admission verification, see Access Control.
                                • Admission check slows down the responses to Ingress requests.
                                • Only add-ons of version 2.4.1 or later support admission verification.
                                -
                              • Nginx Parameters: You can configure the nginx.conf file, which will affect all managed ingresses. You can select GUI or YAML. GUI is supported by the NGINX Ingress Controller of version 2.2.75, 2.6.26, 3.0.1, or later.

                                To configure custom parameters supported by the Kubernetes community, choose YAML and find the related parameters in ConfigMaps. For example, you can use the keep-alive-requests parameter to describe how to set the maximum number of requests for keeping active connections to 100.

                                +
                              • Nginx Parameters: You can configure the nginx.conf file, which will affect all managed ingresses. You can select GUI or YAML. GUI is supported by the NGINX Ingress Controller of version 2.2.75, 2.6.26, 3.0.1, or later.

                                To configure custom parameters supported by the Kubernetes community, choose YAML and find the related parameters in ConfigMaps. For example, you can use the keep-alive-requests parameter to describe how to set the maximum number of requests for keeping active connections to 100.

                                {
                                     "keep-alive-requests": "100"
                                 }
                                • If the configured parameters are not listed in ConfigMaps, the configurations will not take effect.
                                • The parameter value must be a string. Otherwise, the installation fails.
                                The table below shows parameters can be configured on the GUI of the NGINX Ingress Controller add-on of version 2.2.75, 2.6.26, 3.0.1, and later. -

                                Nginx Parameter

                                +
                                - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -139,33 +139,33 @@
                              • Enabling Indicator Collection: If the add-on version is 2.4.12 or later, Prometheus monitoring metrics can be collected.
                              • Default certificate of the server: Select an IngressTLS or kubernetes.io/tls key to configure the default certificate when the NGINX Ingress Controller is started. If no secret is available, click Create TLS Secret. For details, see Creating a Secret. For details about the default server certificate, see Default SSL Certificate.
                              • 404 Service: By default, the 404 service provided by the add-on is used. To customize the 404 service, enter the namespace/service name. If the service does not exist, the add-on installation will fail.
                              • Adding a TCP/UDP Service: By default, NGINX Ingress Controller can forward only external HTTP and HTTPS traffic. You can add TCP/UDP port mapping to forward external TCP/UDP traffic to services in the cluster. For more information about adding TCP/UDP services, see Exposing TCP and UDP services.
                                • Protocol: Select TCP or UDP.
                                • Service Port: specifies the port used by the ELB listener. The port number ranges from 1 to 65535.
                                • Target Service Namespace: Select the namespace where the Service is in.
                                • Destination Service: Select an existing Service. Any Services that do not match the search criteria will be filtered out automatically.
                                • Destination Service Port: Select the access port of the destination Service.
                                • If the cluster version is v1.19.16-r5, v1.21.8-r0, v1.23.6-r0, or later, the TCP/UDP hybrid protocols can be configured.
                                • If the cluster version is v1.19.16-r5, v1.21.8-r0, v1.23.6-r0, v1.25.2-r0, or later, you can configure the TCP/UDP hybrid protocols to use the same external port.
                                -
                              • (Optional) Extended Parameter Settings: additional extended parameters of the add-on If the extended parameter settings conflict with the default settings, the extended parameter settings will be prioritized.
                                • extraArgs: additional configurable startup parameters of the nginx-ingress-controller component. For details about the startup parameters supported by the community, see the documentation.
                                • extraInitContainers: initial container configuration of nginx-ingress-controller. This parameter is supported by add-on 2.2.82, 2.6.32, 3.0.8 and later, with optimized kernel settings by default.
                                • maxmindLicenseKey: Maxmind license key, which can be used to download GeoLite2 databases. This parameter is supported by add-on 2.2.82, 2.6.32, 3.0.8, and later. It is mandatory for NGINX Ingress Controller to configure the use-geoip2 capability.
                                • service: allows services for nginx-ingress-controller. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later. You can use this parameter to configure ELB certificates for NGINX Ingress Controller. For details, see Configuring an ELB Certificate for NGINX Ingress Controller.
                                • extraContainers: other containers added to the nginx-ingress-controller pod. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later.
                                • extraVolumeMounts: allows for mounting additional volumes to the nginx-ingress-controller pod. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later.
                                • extraVolumes: additional volumes mounted to the nginx-ingress-controller pod. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later.
                                +
                              • (Optional) Extended Parameter Settings: additional extended parameters of the add-on. If the extended parameter settings conflict with the default settings, the extended parameter settings will be prioritized.
                                • extraArgs: additional configurable startup parameters of the nginx-ingress-controller component. For details about the startup parameters supported by the community, see the documentation.
                                • extraInitContainers: initial container configuration of nginx-ingress-controller. This parameter is supported by add-on 2.2.82, 2.6.32, 3.0.8 and later, with optimized kernel settings by default.
                                • maxmindLicenseKey: Maxmind license key, which can be used to download GeoLite2 databases. This parameter is supported by add-on 2.2.82, 2.6.32, 3.0.8, and later. It is mandatory for NGINX Ingress Controller to configure the use-geoip2 capability.
                                • service: allows services for nginx-ingress-controller. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later. You can use this parameter to configure ELB certificates for NGINX Ingress Controller. For details, see Configuring an ELB Certificate for NGINX Ingress Controller.
                                • extraContainers: other containers added to the nginx-ingress-controller pod. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later.
                                • extraVolumeMounts: allows for mounting additional volumes to the nginx-ingress-controller pod. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later.
                                • extraVolumes: additional volumes mounted to the nginx-ingress-controller pod. For details, see parameter examples in GitHub. It is supported in add-on versions 2.2.104, 2.6.53, 3.0.31, and later.
                              • Configure deployment policies for the add-on pods.

                                • Scheduling policies do not take effect on add-on pods of the DaemonSet type.
                                • When configuring multi-AZ deployment or node affinity, ensure that there are nodes meeting the scheduling policy and that resources are sufficient in the cluster. Otherwise, the add-on cannot run.
                                -
                              • Nginx Parameter

                                Description

                                +

                                Description

                                Default Value

                                +

                                Default Value

                                Maximum Worker Connections

                                +

                                Maximum Worker Connections

                                Specifies the maximum number of connections that can be concurrently processed by each NGINX worker process. This parameter is used to control the load of worker processes. In a high-concurrency environment, you are advised to set this parameter to a large value to ensure system stability. Such connections include client connections and connections to backend servers.

                                +

                                Specifies the maximum number of connections that can be concurrently processed by each NGINX worker process. This parameter is used to control the load of worker processes. In a high-concurrency environment, you are advised to set this parameter to a large value to ensure system stability. Such connections include client connections and connections to backend servers.

                                65536

                                +

                                65536

                                Maximum Keepalive Requests

                                +

                                Maximum Keepalive Requests

                                Controls how many requests can be processed by a keepalive connection. If requests exhaust the limit, the connection is closed.

                                +

                                Controls how many requests can be processed by a keepalive connection. If requests exhaust the limit, the connection is closed.

                                100

                                +

                                100

                                Maximum Keepalive Connections to the Upstream Server

                                +

                                Maximum Keepalive Connections to the Upstream Server

                                Activates the cache for connections to upstream servers. This parameter sets how many idle keepalive connections can be stored in the cache of each worker process. If the idle connections stored in a process exhaust the limit, the connections that are not used for the longest time will be closed.

                                +

                                Activates the cache for connections to upstream servers. This parameter sets how many idle keepalive connections can be stored in the cache of each worker process. If the idle connections stored in a process exhaust the limit, the connections that are not used for the longest time will be closed.

                                320

                                +

                                320

                                Maximum Keepalive Timeout of the Upstream Server

                                +

                                Maximum Keepalive Timeout of the Upstream Server

                                Specifies the timeout for a keepalive connection between an upstream server and a backend server, in seconds. During this period, NGINX Ingress Controller can maintain connections for reuse. This reduces the overhead required for establishing new connections and significantly improves performance in high QPS scenarios.

                                +

                                Specifies the timeout for a keepalive connection between an upstream server and a backend server, in seconds. During this period, NGINX Ingress Controller can maintain connections for reuse. This reduces the overhead required for establishing new connections and significantly improves performance in high QPS scenarios.

                                900

                                +

                                900

                                Request Timeout

                                +

                                Request Timeout

                                Specifies the timeout for connecting the client to the proxy server, in seconds. If the client cannot access the backend server within 10 seconds, NGINX Ingress Controller will return a 502 Bad Gateway error. It applies to scenarios where the connection speed is high.

                                +

                                Specifies the timeout for connecting the client to the proxy server, in seconds. If the client cannot access the backend server within 10 seconds, NGINX Ingress Controller will return a 502 Bad Gateway error. It applies to scenarios where the connection speed is high.

                                10

                                +

                                10

                                Maximum Request Body Size

                                +

                                Maximum Request Body Size

                                Specifies the maximum size of the request body that Nginx can send to the backend server through the proxy. This applies to file uploads and large data form submissions. If the size of any request body exceeds the limit, a 413 Payload Too Large error will be returned.

                                +

                                Specifies the maximum size of the request body that Nginx can send to the backend server through the proxy. This applies to file uploads and large data form submissions. If the size of any request body exceeds the limit, a 413 Payload Too Large error will be returned.

                                20m

                                +

                                20m

                                Allow the Backend to Return Server Headers

                                +

                                Allow the Backend to Return Server Headers

                                Typically, NGINX Ingress Controller eliminates the server header information sent by a backend server to a client, which identifies the server. However, if this parameter is set to true, the NGINX Ingress Controller will transmit the server header information directly from the backend server to the client. To prevent revealing the server type and version, it is recommended that you disable this feature.

                                +

                                Typically, NGINX Ingress Controller eliminates the server header information sent by a backend server to a client, which identifies the server. However, if this parameter is set to true, the NGINX Ingress Controller will transmit the server header information directly from the backend server to the client. To prevent revealing the server type and version, it is recommended that you disable this feature.

                                Disable

                                +

                                Disable

                                Allow Underscores in Headers

                                +

                                Allow Underscores in Headers

                                Some HTTP headers may contain underscores (_), such as X_Custom-Header, but this is not recommended according to Request For Comments (RFC) standards. So underscores are not allowed by many servers by default. You can activate this parameter if you require underscores in certain headers, such as when third-party services or clients use underscores in their header information.

                                +

                                Some HTTP headers may contain underscores (_), such as X_Custom-Header, but this is not recommended according to Request For Comments (RFC) standards. So underscores are not allowed by many servers by default. You can activate this parameter if you require underscores in certain headers, such as when third-party services or clients use underscores in their header information.

                                Disable

                                +

                                Disable

                                Generate a Request ID

                                +

                                Generate a Request ID

                                After a request is received, NGINX Ingress Controller generates a unique request ID. This ID is usually recorded in logs or transferred to a backend server through header information. This is useful for tracing and debugging requests, especially for locating problems in distributed systems.

                                +

                                After a request is received, NGINX Ingress Controller generates a unique request ID. This ID is usually recorded in logs or transferred to a backend server through header information. This is useful for tracing and debugging requests, especially for locating problems in distributed systems.

                                Enable

                                +

                                Enable

                                Ignore Invalid Headers

                                +

                                Ignore Invalid Headers

                                By default, NGINX Ingress Controller rejects HTTP requests that contain an invalid header. With this setting enabled, NGINX Ingress Controller will ignore invalid headers and keep on processing requests. It is useful for clients that do not fully comply with the HTTP standard.

                                +

                                By default, NGINX Ingress Controller rejects HTTP requests that contain an invalid header. With this setting enabled, NGINX Ingress Controller will ignore invalid headers and keep on processing requests. It is useful for clients that do not fully comply with the HTTP standard.

                                Enable

                                +

                                Enable

                                Reuse Ports

                                +

                                Reuse Ports

                                Enabling SO_REUSEPORT allows multiple processes or threads to be bound to the same {IP}:{Port}. This can effectively improve the concurrent performance of servers, especially for those with multi-core CPUs. With this function enabled, a port can accept more new connections.

                                +

                                Enabling SO_REUSEPORT allows multiple processes or threads to be bound to the same {IP}:{Port}. This can effectively improve the concurrent performance of servers, especially for those with multi-core CPUs. With this function enabled, a port can accept more new connections.

                                Enable

                                +

                                Enable

                                Allow Server Information in Request Body

                                +

                                Allow Server Information in Request Body

                                Disables the server information added to a response header by NGINX Ingress Controller by default. The information usually contains the NGINX version. Disabling this option helps hide server information, enhancing security and preventing attackers from using the version information to attack the system.

                                +

                                Disables the server information added to a response header by NGINX Ingress Controller by default. The information usually contains the NGINX version. Disabling this option helps hide server information, enhancing security and preventing attackers from using the version information to attack the system.

                                Disable

                                +

                                Disable

                                Automatically Redirect HTTP to HTTPS

                                +

                                Automatically Redirect HTTP to HTTPS

                                Disables automatic redirection from HTTP to HTTPS. For example, if you want to use HTTPS only for specific pages, such as the login page, and HTTP for other pages, you can disable the default redirection using this option.

                                +

                                Disables automatic redirection from HTTP to HTTPS. For example, if you want to use HTTPS only for specific pages, such as the login page, and HTTP for other pages, you can disable the default redirection using this option.

                                Disable

                                +

                                Disable

                                CPU Affinity of Worker Threads

                                +

                                CPU Affinity of Worker Threads

                                Automatically allocates worker processes to specific CPU cores to improve the performance of multi-core systems. For example, on a multi-core server, some worker processes can be bound on a specific CPU core. This reduces context switching and improves processing efficiency.

                                +

                                Automatically allocates worker processes to specific CPU cores to improve the performance of multi-core systems. For example, on a multi-core server, some worker processes can be bound on a specific CPU core. This reduces context switching and improves processing efficiency.

                                Auto

                                +

                                Auto

                                Table 1 Configurations for add-on scheduling

                                Parameter

                                +
                                - - - - - - - @@ -175,7 +175,7 @@

                              • Click Install.
                              • -

                                Installing Multiple NGINX Ingress Controllers

                                1. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Add-ons, locate the installed NGINX Ingress Controller, and click New.
                                2. On the page displayed, reconfigure the add-on parameters. For details, see Installing the Add-on.
                                3. Click Install.
                                4. Wait until the installation instruction is delivered. Go back to Add-ons, click Manage, and view the installed add-on instance on the add-on details page.
                                +

                                Installing Multiple NGINX Ingress Controllers

                                1. Log in to the CCE console and click the cluster name to access the cluster console.
                                2. In the navigation pane, choose Add-ons. Locate NGINX Ingress Controller on the right and click New.
                                3. On the page displayed, reconfigure the add-on parameters. For details, see Installing the Add-on.
                                4. Click Install.
                                5. Wait until the installation instruction is delivered. Go back to Add-ons, click Manage, and view the installed add-on instance on the add-on details page.

                                Components

                                Table 1 Configurations for add-on scheduling

                                Parameter

                                Description

                                +

                                Description

                                Multi-AZ Deployment

                                +

                                Multi-AZ Deployment

                                • Preferred: Deployment pods of the add-on will be preferentially scheduled to nodes in different AZs. If all the nodes in the cluster are deployed in the same AZ, the pods will be scheduled to different nodes in that AZ.
                                • Equivalent mode: Deployment pods of the add-on are evenly scheduled to the nodes in the cluster in each AZ. If a new AZ is added, you are advised to increase add-on pods for cross-AZ HA deployment. With the Equivalent multi-AZ deployment, the difference between the number of add-on pods in different AZs will be less than or equal to 1. If resources in one of the AZs are insufficient, pods cannot be scheduled to that AZ.
                                  NOTE:

                                  The equivalent mode supports only the pods in the kube-system and monitoring namespaces.

                                  +
                                • Preferred: Deployment pods of the add-on will be preferentially scheduled to nodes in different AZs. If all the nodes in the cluster are deployed in the same AZ, the pods will be scheduled to different nodes in that AZ.
                                • Equivalent mode: Deployment pods of the add-on are evenly scheduled to the nodes in the cluster in each AZ. If a new AZ is added, you are advised to increase add-on pods for cross-AZ HA deployment. With the Equivalent multi-AZ deployment, the difference between the number of add-on pods in different AZs will be less than or equal to 1. If resources in one of the AZs are insufficient, pods cannot be scheduled to that AZ.
                                  NOTE:

                                  The equivalent mode supports only the pods in the kube-system and monitoring namespaces.

                                • Forcible: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. There can be at most one pod in each AZ. If nodes in a cluster are not in different AZs, some add-on pods cannot run properly. If a node is faulty, add-on pods on it may fail to be migrated.

                                Node Affinity

                                +

                                Node Affinity

                                • Not configured: Node affinity is disabled for the add-on.
                                • Specify node: Specify the nodes where the add-on is deployed. If you do not specify the nodes, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                • Specify node pool: Specify the node pool where the add-on is deployed. If you do not specify the node pools, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                • Customize affinity: Enter the labels of the nodes where the add-on is to be deployed for more flexible scheduling policies. If you do not specify node labels, the add-on will be randomly scheduled based on the default cluster scheduling policy.

                                  If multiple custom affinity policies are configured, ensure that there are nodes that meet all the affinity policies in the cluster. Otherwise, the add-on cannot run.

                                  +
                                • Not configured: Node affinity is disabled for the add-on.
                                • Specify node: Specify the nodes where the add-on is deployed. If you do not specify the nodes, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                • Specify node pool: Specify the node pool where the add-on is deployed. If you do not specify the node pools, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                • Customize affinity: Enter the labels of the nodes where the add-on is to be deployed for more flexible scheduling policies. If you do not specify node labels, the add-on will be randomly scheduled based on the default cluster scheduling policy.

                                  If multiple custom affinity policies are configured, ensure that there are nodes that meet all the affinity policies in the cluster. Otherwise, the add-on cannot run.

                                Toleration

                                +

                                Toleration

                                Using both taints and tolerations allows (not forcibly) the add-on Deployment to be scheduled to a node with the matching taints, and controls the Deployment eviction policies after the node where the Deployment is located is tainted.

                                +

                                Using both taints and tolerations allows (not forcibly) the add-on Deployment to be scheduled to a node with the matching taints, and controls the Deployment eviction policies after the node where the Deployment is located is tainted.

                                The add-on adds the default tolerance policy for the node.kubernetes.io/not-ready and node.kubernetes.io/unreachable taints, respectively. The tolerance time window is 60s.

                                For details, see Configuring Tolerance Policies.

                                Table 2 Add-on components

                                Component

                                @@ -246,79 +246,120 @@ spec: - kube-system topologyKey: kubernetes.io/hostname -

                                Change History

                                -
                                Table 3 Release history for NGINX Ingress Controller 3.0.x

                                Add-on Version

                                +

                                Release History

                                +
                                - - - - - - - - - - - -
                                Table 3 NGINX Ingress Controller add-on 4.0.x

                                Add-on Version

                                Supported Cluster Version

                                +

                                Supported Cluster Version

                                New Feature

                                +

                                New Feature

                                Community Version

                                +

                                Community Version

                                3.0.34

                                +

                                4.0.4

                                v1.25

                                -

                                v1.27

                                -

                                v1.28

                                -

                                v1.29

                                -

                                v1.30

                                -

                                v1.31

                                +

                                v1.28

                                +

                                v1.29

                                +

                                v1.30

                                +

                                v1.31

                                +

                                v1.32

                                • Updated the add-on to its community version v1.11.5.
                                • Fixed the CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, CVE-2025-24513, and CVE-2025-24514 vulnerabilities.
                                +
                                • CCE clusters v1.32 are supported.
                                • Updated the add-on to its community version v1.12.1.

                                1.11.5

                                -

                                3.0.8

                                -

                                v1.27

                                -

                                v1.28

                                -

                                v1.29

                                -

                                v1.30

                                -
                                • Updated the add-on to its community version v1.11.2.
                                • Fixed the CVE-2024-7646 vulnerability.
                                -

                                1.11.2

                                +

                                1.12.1

                                -
                                Table 4 Release history for NGINX Ingress Controller 2.6.x

                                Add-on Version

                                +
                                - - - - - + + + + + + + + + + + + + + +
                                Table 4 NGINX Ingress Controller add-on 3.0.x

                                Add-on Version

                                Supported Cluster Version

                                +

                                Supported Cluster Version

                                New Feature

                                +

                                New Feature

                                Community Version

                                +

                                Community Version

                                2.6.32

                                +

                                3.0.45

                                v1.25

                                +

                                v1.25

                                +

                                v1.27

                                +

                                v1.28

                                +

                                v1.29

                                +

                                v1.30

                                +

                                v1.31

                                +

                                Fixed some issues.

                                +

                                1.11.5

                                +

                                3.0.34

                                +

                                v1.25

                                +

                                v1.27

                                +

                                v1.28

                                +

                                v1.29

                                +

                                v1.30

                                +

                                v1.31

                                +
                                • Updated the add-on to its community version v1.11.5.
                                • Fixed the CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, CVE-2025-24513, and CVE-2025-24514 vulnerabilities.
                                +

                                1.11.5

                                +

                                3.0.8

                                +

                                v1.27

                                +

                                v1.28

                                +

                                v1.29

                                +

                                v1.30

                                +
                                • Updated the add-on to its community version v1.11.2.
                                • Fixed the CVE-2024-7646 vulnerability.
                                +

                                1.11.2

                                +
                                +
                                + +
                                + + + + + + + - - - - - - diff --git a/docs/cce/umn/cce_10_0035.html b/docs/cce/umn/cce_10_0035.html index 6bbd136d4..81b8191a6 100644 --- a/docs/cce/umn/cce_10_0035.html +++ b/docs/cce/umn/cce_10_0035.html @@ -10,7 +10,7 @@ - diff --git a/docs/cce/umn/cce_10_0036.html b/docs/cce/umn/cce_10_0036.html index d2c3a7ac8..e9fc55458 100644 --- a/docs/cce/umn/cce_10_0036.html +++ b/docs/cce/umn/cce_10_0036.html @@ -5,7 +5,7 @@

                                Precautions

                                • Stopping 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 data beforehand.
                                -

                                Procedure

                                1. Log in to the CCE console and click the cluster name to access the cluster console.
                                2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
                                3. Locate the target node and click its name.
                                4. In the upper right corner of the ECS details page, click Stop. In the displayed dialog box, click OK.
                                +

                                Procedure

                                1. Log in to the CCE console and click the cluster name to access the cluster console.
                                2. In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
                                3. Locate the target node and click its name.
                                4. In the upper right corner of the ECS details page, click Stop. In the displayed dialog box, click OK.
                                diff --git a/docs/cce/umn/cce_10_0044.html b/docs/cce/umn/cce_10_0044.html index b6c77e471..a9eeaa2a2 100644 --- a/docs/cce/umn/cce_10_0044.html +++ b/docs/cce/umn/cce_10_0044.html @@ -1,10 +1,10 @@ -

                                Elastic Volume Service

                                +

                                EVS

                                Table 5 NGINX Ingress Controller add-on 2.6.x

                                Add-on Version

                                +

                                Supported Cluster Version

                                +

                                New Feature

                                +

                                Community Version

                                +

                                2.6.32

                                +

                                v1.25

                                v1.27

                                v1.28

                                v1.29

                                Fixed some issues.

                                +

                                Fixed some issues.

                                1.9.6

                                +

                                1.9.6

                                2.6.5

                                +

                                2.6.5

                                v1.25

                                +

                                v1.25

                                v1.27

                                v1.28

                                v1.29

                                Metric collection can be disabled in the startup command.

                                +

                                Metric collection can be disabled in the startup command.

                                1.9.6

                                +

                                1.9.6

                                Parameter

                                +

                                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 Create Workload in the upper right corner.
                                3. Configure basic information about the workload.

                                  +

                                  - - - - - - - + + + + + + + + + + + +

                                  Parameter

                                  Description

                                  +

                                  Description

                                  Container Name

                                  +

                                  Workload Type

                                  Name the container.

                                  +

                                  Select Deployment. For details about different workload types, see Workload Overview.

                                  Pull Policy

                                  +

                                  Workload Name

                                  Image update or pull policy. If you select Always, the image is pulled from the image repository each time. If you do not select Always, the existing image of the node is preferentially used. If the image does not exist, the image is pulled from the image repository.

                                  +

                                  Enter a name for the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a lowercase letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed.

                                  Image Name

                                  +

                                  Namespace

                                  Click Select Image and select the image used by the container.

                                  +

                                  Select a namespace for 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 workload pods.

                                  +

                                  Container Runtime

                                  +

                                  A CCE standard cluster uses a common runtime by default, whereas a CCE Turbo cluster supports both common and secure runtimes. For details about their differences, see Secure Runtime and Common Runtime.

                                  +

                                  Time Zone Synchronization

                                  +

                                  Configure whether to enable time zone synchronization. After this function is enabled, the container and node will share the same time zone. Time zone synchronization relies on the local disk mounted to the container. Do not modify or delete the local disk. For details, see Configuring Time Zone Synchronization.

                                  +
                                  +
                                  +

                                4. Configure container settings for the workload.

                                  • Container Information: Click Add Container on the right to configure multiple containers for the pod.

                                    If you configured multiple containers for a pod, ensure that the ports used by each container do not conflict with each other, or the workload cannot be deployed.

                                    +
                                    +
                                    • Basic Info: Configure basic information about the container. +
                                      + + + + + + + + + + + - - - - - - - - - - - - - - @@ -78,172 +115,101 @@

                                      Parameter

                                      +

                                      Description

                                      +

                                      Container Name

                                      +

                                      Enter a name for the container.

                                      +

                                      Pull Policy

                                      +

                                      Image update or pull policy. If you select Always, the image is pulled from the image repository each time. If you do not select Always, the existing image of the node is preferentially used. If the image does not exist, the image is pulled from the image repository.

                                      +

                                      Image Name

                                      +

                                      Click Select Image and select the image used by the container.

                                      To use a third-party image, directly enter image path. Ensure that the image access credential can be used to access the image repository. For details, see Using Third-Party Images.

                                      Image Tag

                                      +

                                      Image Tag

                                      Select the image tag to be deployed.

                                      +

                                      Select the image tag to be deployed.

                                      CPU Quota

                                      +

                                      CPU Quota

                                      • Request: minimum number of CPU cores required by a container. The default value is 0.25 cores.
                                      • Limit: maximum number of CPU cores that can be used by a container. This prevents containers from using excessive resources.
                                      +
                                      • Request: minimum number of CPU cores required by a container. The default value is 0.25 cores.
                                      • Limit: maximum number of CPU cores that can be used by a container. This prevents containers from using excessive resources.

                                      If Request and Limit are not specified, the quota is not limited. For more information and suggestions about Request and Limit, see Configuring Container Specifications.

                                      Memory Quota

                                      +

                                      Memory Quota

                                      • Request: minimum amount of memory required by a container. The default value is 512 MiB.
                                      • Limit: maximum amount of memory available for a container. When memory usage exceeds the specified memory limit, the container will be terminated.
                                      +
                                      • Request: minimum amount of memory required by a container. The default value is 512 MiB.
                                      • Limit: maximum amount of memory available for a container. When memory usage exceeds the specified memory limit, the container will be terminated.

                                      If Request and Limit are not specified, the quota is not limited. For more information and suggestions about Request and Limit, see Configuring Container Specifications.

                                      (Optional) GPU Quota

                                      +

                                      (Optional) GPU Quota

                                      Configurable only when the cluster contains GPU nodes and the CCE AI Suite (NVIDIA GPU) add-on has been installed.

                                      +

                                      Configurable only when the cluster contains GPU nodes and the CCE AI Suite (NVIDIA GPU) add-on has been installed.

                                      • Do not use: No GPU will be used.
                                      • GPU card: The GPU is dedicated for the container.
                                      • GPU Virtualization: percentage of GPU resources used by the container. For example, if this parameter is set to 10%, the container will use 10% of GPU resources.
                                      -

                                      For details about how to use GPUs in the cluster, see Default GPU Scheduling in Kubernetes.

                                      +

                                      For details about how to use GPUs in a cluster, see Default GPU Scheduling in Kubernetes.

                                      (Optional) Privileged Container

                                      +

                                      (Optional) Privileged Container

                                      Programs in a privileged container have certain privileges.

                                      -

                                      If Privileged Container is enabled, the container is assigned privileges. For example, privileged containers can manipulate network devices on the host machine and modify kernel parameters.

                                      +

                                      Programs in a privileged container have certain privileges. If this option is enabled, the container will be assigned privileges. For example, privileged containers can manipulate network devices on the host machine, modify kernel parameters, access all devices on the node.

                                      +

                                      For more information, see Pod Security Standards.

                                      (Optional) Init Container

                                      +

                                      (Optional) Init Container

                                      Whether to use the container as an init container. An init container does not support health check.

                                      +

                                      Whether to use the container as an init container. An init container does not support health check.

                                      An init container is a special container that runs before other app containers in a pod are started. Each pod can contain multiple containers. In addition, a pod can contain one or more init containers. Application containers in a pod are started and run only after the running of all init containers completes. For details, see Init Containers.

                                      (Optional) Run Option

                                      +

                                      (Optional) Run Option

                                      Add run options for the container. For details, see Pod. CCE supports the following run options:

                                      +

                                      Add run options for the container. For details, see Pod. CCE supports the following run options:

                                      • stdin: allows containers to receive input from external sources, such as terminals or other input streams.
                                      • tty: allocates a pseudo terminal to containers, allowing you to send commands to them as if you were using a local terminal.

                                        In most cases, tty is enabled along with stdin, indicating that the terminal (tty) is associated with the standard input (stdin) of the container. This allows for interactive operations, similar to the kubectl exec -i -t command. The difference is that this parameter has been configured when the pod is launched.

                                      -
                                    • (Optional) Lifecycle: Configure operations to be performed in a specific phase of the container lifecycle, such as Startup Command, Post-Start, and Pre-Stop. For details, see Configuring Container Lifecycle Parameters.
                                    • (Optional) Health Check: Set the liveness probe, ready probe, and startup probe as required. For details, see Configuring Container Health Check.
                                    • (Optional) Environment Variables: Configure variables for the container running environment using key-value pairs. These variables transfer external information to containers running in pods and can be flexibly modified after application deployment. For details, see Configuring Environment Variables.
                                    • (Optional) Data Storage: Mount local storage or cloud storage to the container. The application scenarios and mounting modes vary with the storage type. For details, see Storage.

                                      If the workload contains more than one pod, EVS volumes cannot be mounted.

                                      +
                                    • (Optional) Lifecycle: Configure operations to be performed in a specific phase of the container lifecycle, such as Startup Command, Post-Start, and Pre-Stop. For details, see Configuring the Container Lifecycle.
                                    • (Optional) Health Check: Set the liveness probe, ready probe, and startup probe as required. For details, see Configuring Container Health Check.
                                    • (Optional) Environment Variables: Configure variables for the container running environment using key-value pairs. These variables transfer external information to containers running in pods and can be flexibly modified after application deployment. For details, see Configuring Environment Variables.
                                    • (Optional) Data Storage: Mount local storage or cloud storage to the container. The application scenarios and mounting modes vary with the StorageClass. For details, see Storage.

                                      If the workload contains more than one pod, EVS volumes cannot be mounted.

                                      -
                                    • (Optional) Security Context: Assign container permissions to protect the system and other containers from being affected. Enter the user ID to assign container permissions and prevent systems and other containers from being affected.
                                    • (Optional) Logging: Report standard container output logs to AOM by default, without requiring manual settings. You can manually configure the log collection path. For details, see Collecting Container Logs Using ICAgent.

                                      To disable the standard output of the current workload, add the annotation kubernetes.AOM.log.stdout: [] in Labels and Annotations. For details about how to use this annotation, see Table 1.

                                      +
                                    • (Optional) Security Context: Assign container permissions to protect the system and other containers from being affected. Enter the user ID to assign container permissions and prevent systems and other containers from being affected.
                                    • (Optional) Logging: Report standard container output logs to AOM by default, without requiring manual settings. You can manually configure the log collection path. For details, see Collecting Container Logs Using ICAgent.

                                      To disable the collection of the standard output logs of the current workload, add the annotation kubernetes.AOM.log.stdout: [] in Labels and Annotations in the Advanced Settings area. For details about how to use this annotation, see Table 1.

                                    -
                              • Image Access Credential: Select the credential used for accessing the image repository. The default value is default-secret. You can use default-secret to access images in SWR Shared Edition. For details about default-secret, see default-secret.
                              • (Optional) GPU: All is selected by default. The workload instance will be scheduled to the node of the specified GPU type.
                              • - -

                                (Optional) Service Settings

                                -

                                A Service provides external access for pods. With a static IP address, a Service forwards access traffic to pods and automatically balances load for these pods.

                                -

                                You can also create a Service after creating a workload. For details about Services of different types, see Overview.

                                -
                                (Optional) Advanced Settings
                                • Upgrade: Specify the upgrade mode and parameters of the workload. Rolling upgrade and Replace upgrade are available. For details, see Configuring Workload Upgrade Policies.
                                • Scheduling: Configure affinity and anti-affinity policies for flexible workload scheduling. Load affinity and node affinity are provided.
                                  • Load Affinity: Common load affinity policies are offered for quick load affinity deployment.
                                    • Not configured: No load affinity policy is configured.
                                    • Multi-AZ deployment preferred: Workload pods are preferentially scheduled to nodes in different AZs through pod anti-affinity.
                                    • Forcible multi-AZ deployment: Workload pods are forcibly scheduled to nodes in different AZs through pod anti-affinity (podAntiAffinity). If there are fewer AZs than pods, the extra pods will fail to run.
                                    • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
                                    -
                                  • Node Affinity: Common node affinity policies are offered for quick load affinity deployment.
                                    • Not configured: No node affinity policy is configured.
                                    • Specify node: Workload pods can be deployed on specified nodes through node affinity (nodeAffinity). If no node is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                    • Specify node pool: Workload pods can be deployed in a specified node pool through node affinity (nodeAffinity). If no node pool is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                    • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Node Affinity Scheduling (nodeAffinity).
                                    -
                                  -
                                • 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 Configuring Tolerance Policies.
                                • Labels and Annotations: Add labels or annotations for pods using key-value pairs. After entering the key and value, click Confirm. For details about how to use and configure labels and annotations, see Configuring Labels and Annotations.
                                • DNS: Configure a separate DNS policy for the workload. For details, see DNS Configuration.
                                • Network Configuration
                                  • Pod ingress/egress bandwidth limitation: You can set ingress/egress bandwidth limitation for pods. For details, see Configuring QoS for a Pod.
                                  • Whether to enable a specified container network configuration: available only for clusters that support this function. After you enable a specified container network configuration, the workload will be created using the container subnet and security group in the configuration. For details, see Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration.
                                  • Specify the container network configuration name: Only the custom container network configuration whose associated resource type is workload can be selected.
                                  • IPv6 shared bandwidth: available only for clusters that support this function. After this function is enabled, you can configure a shared bandwidth for a pod with IPv6 dual-stack ENIs. For details, see Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack ENIs.
                                  -
                                -
                                -

                              • Click Create Workload in the lower right corner. After a period of time, the workload enters the Running state.

                                -

                                -

                              • - -

                                Using kubectl

                                The following procedure uses Nginx as an example to describe how to create a workload using kubectl.

                                -
                                1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
                                2. Create and edit the nginx-deployment.yaml file. nginx-deployment.yaml is an example file name, and you can rename it as required.

                                  vi nginx-deployment.yaml
                                  -

                                  The following is an example YAML file. For more information about Deployments, see Kubernetes documentation.

                                  -
                                  apiVersion: apps/v1
                                  -kind: Deployment
                                  -metadata:
                                  -  name: nginx
                                  -spec:
                                  -  replicas: 1
                                  -  selector:
                                  -    matchLabels:
                                  -      app: nginx
                                  -  strategy:
                                  -    type: RollingUpdate
                                  -  template:
                                  -    metadata:
                                  -      labels:
                                  -        app: nginx
                                  -    spec:
                                  -      containers:
                                  -      - image: nginx    # If you use an image in My Images, obtain the image path from SWR.
                                  -        imagePullPolicy: Always
                                  -        name: nginx
                                  -      imagePullSecrets:
                                  -      - name: default-secret
                                  -

                                  For details about the parameters, see Table 1.

                                  - -
                                  Table 1 Deployment YAML parameters

                                  Parameter

                                  +

                                3. (Optional) Configure the settings of the Service associated with the workload.

                                  A Service provides external access for pods. With a static IP address, a Service forwards access traffic to pods and automatically balances load for these pods.

                                  +

                                  You can also create a Service after creating a workload. For details about Services of different types, see Service Overview.

                                  +

                                4. (Optional) Configure advanced settings for the workload.

                                  +

                                  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

                                  Parameter

                                  Description

                                  -

                                  Mandatory/Optional

                                  +

                                  Description

                                  apiVersion

                                  +

                                  Upgrade

                                  API version.

                                  -
                                  NOTE:

                                  Set this parameter based on the cluster version.

                                  -
                                  • For clusters of v1.17 or later, the apiVersion format of Deployments is apps/v1.
                                  • For clusters of v1.15 or earlier, the apiVersion format of Deployments is extensions/v1beta1.
                                  -
                                  -

                                  Mandatory

                                  +

                                  Specify the upgrade mode and parameters of the workload. Rolling upgrade and Replace upgrade are available. For details, see Upgrading and Rolling Back a Workload.

                                  kind

                                  +

                                  Scheduling

                                  Type of a created object.

                                  -

                                  Mandatory

                                  +

                                  Configure affinity and anti-affinity policies for flexible workload scheduling. Load affinity and node affinity are provided.

                                  +
                                  • Load Affinity: Common load affinity policies are offered for quick load affinity deployment.
                                    • Not configured: No load affinity policy is configured.
                                    • Multi-AZ deployment preferred: Workload pods are preferentially scheduled to nodes in different AZs through pod anti-affinity.
                                    • Forcible multi-AZ deployment: Workload pods are forcibly scheduled to nodes in different AZs through pod anti-affinity (podAntiAffinity). If there are fewer AZs than pods, the extra pods will fail to run.
                                    • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
                                    +
                                  • Node Affinity: Common node affinity policies are offered for quick load affinity deployment.
                                    • Not configured: No node affinity policy is configured.
                                    • Specify node: Workload pods can be deployed on specified nodes through node affinity (nodeAffinity). If no node is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                    • Specify node pool: Workload pods can be deployed in a specified node pool through node affinity (nodeAffinity). If no node pool is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                    • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Node Affinity Scheduling (nodeAffinity).
                                    +

                                  metadata

                                  +

                                  Toleration

                                  Metadata of a resource object.

                                  -

                                  Mandatory

                                  +

                                  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 Configuring Tolerance Policies.

                                  name

                                  +

                                  Labels and Annotations

                                  Name of the Deployment.

                                  -

                                  Mandatory

                                  +

                                  Add labels or annotations for pods using key-value pairs. After the setting, click Confirm. For details about labels and annotations, see Configuring Labels and Annotations.

                                  spec

                                  +

                                  DNS

                                  Detailed description of the Deployment.

                                  -

                                  Mandatory

                                  +

                                  Configure a separate DNS policy for the workload. For details, see DNS Configuration.

                                  replicas

                                  +

                                  Network Configuration

                                  Number of pods.

                                  -

                                  Mandatory

                                  -

                                  selector

                                  -

                                  Determines container pods that can be managed by the Deployment.

                                  -

                                  Mandatory

                                  -

                                  strategy

                                  -

                                  Upgrade mode. Possible values:

                                  -
                                  • RollingUpdate
                                  • ReplaceUpdate
                                  -

                                  By default, rolling update is used.

                                  -

                                  Optional

                                  -

                                  template

                                  -

                                  Detailed description of a created container pod.

                                  -

                                  Mandatory

                                  -

                                  metadata

                                  -

                                  Metadata.

                                  -

                                  Mandatory

                                  -

                                  labels

                                  -

                                  metadata.labels: Container labels.

                                  -

                                  Optional

                                  -

                                  spec:

                                  -

                                  containers

                                  -
                                  • image (mandatory): Name of a container image.
                                  • imagePullPolicy (optional): Policy for obtaining an image. The options include Always (attempting to download images each time), Never (only using local images), and IfNotPresent (using local images if they are available; downloading images if local images are unavailable). The default value is Always.
                                  • name (mandatory): Container name.
                                  -

                                  Mandatory

                                  -

                                  imagePullSecrets

                                  -

                                  Name of the secret used during image pulling. If a private image is used, this parameter is mandatory.

                                  -
                                  • To pull an image from the Software Repository for Container (SWR), set this parameter to default-secret.
                                  • To pull an image from a third-party image repository, set this parameter to the name of the created secret.
                                  -

                                  Optional

                                  +
                                  -

                                5. Create a Deployment.

                                  kubectl create -f nginx-deployment.yaml
                                  -

                                  If the following information is displayed, the Deployment is being created.

                                  +

                                6. Click Create Workload in the lower right corner. After a period of time, the workload enters the Running state.

                                  +

                                  +

                                7. + +

                                  Using kubectl

                                  Nginx is used as an example to describe how to create a workload using kubectl.

                                  +
                                  1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
                                  2. Create a file named nginx-deployment.yaml. nginx-deployment.yaml is an example file name, and you can rename it as needed.

                                    vi nginx-deployment.yaml
                                    +

                                    Below is example of the file. For details about the Deployment configuration, see the Kubernetes official documentation.

                                    +
                                    apiVersion: apps/v1
                                    +kind: Deployment  # Workload type
                                    +metadata:
                                    +  name: nginx  # Workload name
                                    +  namespace: default  # Namespace where the workload is located
                                    +spec:
                                    +  replicas: 1   # Number of pods in the specified workload
                                    +  selector:
                                    +    matchLabels:   # The workload manages pods based on the pod labels in the label selector.
                                    +      app: nginx
                                    +  template:  # Pod configuration
                                    +    metadata:
                                    +      labels:  # Pod labels
                                    +        app: nginx
                                    +    spec:
                                    +      containers:
                                    +      - image: nginx:latest    # Specify a container image. If you use an image in My Images, obtain the image path from SWR.
                                    +        imagePullPolicy: Always  # Image pull policy
                                    +        name: nginx  # Container name
                                    +        resources:  # Node resources allocated to the container
                                    +          requests:  # Requested resources
                                    +            cpu: 250m
                                    +            memory: 512Mi
                                    +          limits:  # Resource limit
                                    +            cpu: 250m
                                    +            memory: 512Mi
                                    +      imagePullSecrets:  # Secret for image pull
                                    +      - name: default-secret  
                                    +

                                  3. Create the Deployment.

                                    kubectl create -f nginx-deployment.yaml
                                    +

                                    If information similar to the following is displayed, the Deployment is being created:

                                    deployment.apps/nginx created
                                    -

                                  4. Obtain the Deployment status.

                                    kubectl get deployment
                                    -

                                    If the following information is displayed, the Deployment is running.

                                    +

                                  5. Check the Deployment status.

                                    kubectl get deployment
                                    +

                                    If the Deployment is in the Running, it means that the Deployment has been created.

                                    NAME           READY     UP-TO-DATE   AVAILABLE   AGE 
                                     nginx          1/1       1            1           4m5s
                                    -

                                    Parameters

                                    +

                                    Parameters

                                    • NAME: Name of the application running in the pod.
                                    • READY: indicates the number of available workloads. The value is displayed as "the number of available pods/the number of expected pods".
                                    • UP-TO-DATE: indicates the number of replicas that have been updated.
                                    • AVAILABLE: indicates the number of available pods.
                                    • AGE: period the Deployment keeps running
                                    -

                                  6. If the Deployment will be accessed through a ClusterIP or NodePort Service, configure the access mode. For details, see Network.
                                  +

                                8. If the Deployment will be accessed through a ClusterIP or NodePort Service, create such a Service. For details, see Networking.
                                9. diff --git a/docs/cce/umn/cce_10_0048.html b/docs/cce/umn/cce_10_0048.html index 185ebc1fd..59a5fa6f1 100644 --- a/docs/cce/umn/cce_10_0048.html +++ b/docs/cce/umn/cce_10_0048.html @@ -1,79 +1,116 @@

                                  Creating a StatefulSet

                                  -

                                  Scenario

                                  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 container can be migrated between different hosts, but data is not stored on the hosts. To store StatefulSet data persistently, attach HA storage volumes provided by CCE to the container.

                                  +

                                  A StatefulSet is an application that needs to retain data or state while running. StatefulSets are ideal for stateful applications, such as databases, cache services, and message queues. Unlike Deployments, StatefulSets have the following features:

                                  +
                                  • Fixed identifier: Each pod in a StatefulSet has a fixed identifier, which is associated with the pod name. The identifier is typically in the format of <StatefulSet name>-<Ordinal>. For example, in a StatefulSet named web, the pods would have the names like web-0 and web-1. This naming rule enables each pod to maintain its identity and persistent data even after restart or migration.
                                  • Ordered deployment and scaling: Pods in a StatefulSet are created, scaled, or deleted sequentially. For example, pods with higher ordinals are prioritized for scale-out and removed first during scale-in, which is critical to stateful applications that need to be started or stopped in sequence and ideal for scenarios like primary-secondary replication of databases.
                                  • Persistent storage: To ensure data persistence, you can assign stable persistent storage volumes to each StatefulSet pod by using VolumeClaimTemplate. If a pod is scheduled to other nodes, its original data volume remains intact via the PVC, preventing data loss.
                                  +

                                  Notes and Constraints

                                  • When you delete or scale a StatefulSet, the system does not delete the storage volumes associated with the StatefulSet to ensure data security.
                                  • When you delete a StatefulSet, reduce the number of replicas to 0 before deleting the StatefulSet so that pods in the StatefulSet can be stopped in order.
                                  • When you create a StatefulSet, a headless Service is required for pod access. For details, see Headless Service.
                                  • When a node is unavailable, pods become Unready. In this case, manually delete the pods of the StatefulSet so that the pods can be migrated to a normal node.
                                  -

                                  Notes and Constraints

                                  • When you delete or scale a StatefulSet, the system does not delete the storage volumes associated with the StatefulSet to ensure data security.
                                  • When you delete a StatefulSet, reduce the number of replicas to 0 before deleting the StatefulSet so that pods in the StatefulSet can be stopped in order.
                                  • When you create a StatefulSet, a headless Service is required for pod access. For details, see Headless Services.
                                  • When a node is unavailable, pods become Unready. In this case, manually delete the pods of the StatefulSet so that the pods can be migrated to a normal node.
                                  +

                                  Prerequisites

                                  -

                                  Prerequisites

                                  • Before creating a workload, you must have an available cluster. For details on how to create a cluster, see Creating a CCE Standard/Turbo Cluster.
                                  • To enable public access to a workload, ensure that an EIP or load balancer has been bound to at least one node in the cluster.

                                    If a pod has multiple containers, ensure that the ports used by the containers do not conflict with each other. Otherwise, creating the StatefulSet will fail.

                                    -
                                    -
                                  -
                                  -

                                  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 StatefulSet. 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 lowercase 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 of the workload.
                                    • Container Runtime: A CCE standard cluster uses a common runtime by default, whereas a CCE Turbo cluster supports both common and secure runtimes. For details about the differences, see Secure Runtime and Common Runtime.
                                    • 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: Configure basic information about the container. -
                                        - - @@ -55,21 +55,21 @@ - - - @@ -86,17 +86,17 @@ - - @@ -120,13 +120,13 @@ - @@ -147,14 +147,14 @@ - - - @@ -186,9 +186,9 @@ - - - - - - - @@ -295,7 +295,7 @@

                                        Load Balancing

                                        -

                                        Parameter

                                        +

                                        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. Configure basic information about the workload.

                                          +

                                          - - - - - - - + + + + + + + + + + + +

                                          Parameter

                                          Description

                                          +

                                          Description

                                          Container Name

                                          +

                                          Workload Type

                                          Name the container.

                                          +

                                          Select StatefulSet. For details about different workload types, see Workload Overview.

                                          Pull Policy

                                          +

                                          Workload Name

                                          Image update or pull policy. If you select Always, the image is pulled from the image repository each time. If you do not select Always, the existing image of the node is preferentially used. If the image does not exist, the image is pulled from the image repository.

                                          +

                                          Enter a name for the workload. Enter 1 to 63 characters starting with a lowercase letter and ending with a lowercase letter or digit. Only lowercase letters, digits, and hyphens (-) are allowed.

                                          Image Name

                                          +

                                          Namespace

                                          Click Select Image and select the image used by the container.

                                          +

                                          Select a namespace for 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 workload pods.

                                          +

                                          Container Runtime

                                          +

                                          A CCE standard cluster uses a common runtime by default, whereas a CCE Turbo cluster supports both common and secure runtimes. For details about their differences, see Secure Runtime and Common Runtime.

                                          +

                                          Time Zone Synchronization

                                          +

                                          Configure whether to enable time zone synchronization. After this function is enabled, the container and node will share the same time zone. Time zone synchronization relies on the local disk mounted to the container. Do not modify or delete the local disk. For details, see Configuring Time Zone Synchronization.

                                          +
                                          +
                                          +

                                        4. Configure container settings for the workload.

                                          • Container Information: Click Add Container on the right to configure multiple containers for the pod.

                                            If you configured multiple containers for a pod, ensure that the ports used by each container do not conflict with each other, or the workload cannot be deployed.

                                            +
                                            +
                                            • Basic Info: Configure basic information about the container. +
                                              + + + + + + + + + + + - - - - - - - - - - - - - - @@ -81,35 +118,72 @@

                                              Parameter

                                              +

                                              Description

                                              +

                                              Container Name

                                              +

                                              Enter a name for the container.

                                              +

                                              Pull Policy

                                              +

                                              Image update or pull policy. If you select Always, the image is pulled from the image repository each time. If you do not select Always, the existing image of the node is preferentially used. If the image does not exist, the image is pulled from the image repository.

                                              +

                                              Image Name

                                              +

                                              Click Select Image and select the image used by the container.

                                              To use a third-party image, directly enter image path. Ensure that the image access credential can be used to access the image repository. For details, see Using Third-Party Images.

                                              Image Tag

                                              +

                                              Image Tag

                                              Select the image tag to be deployed.

                                              +

                                              Select the image tag to be deployed.

                                              CPU Quota

                                              +

                                              CPU Quota

                                              • Request: minimum number of CPU cores required by a container. The default value is 0.25 cores.
                                              • Limit: maximum number of CPU cores that can be used by a container. This prevents containers from using excessive resources.
                                              +
                                              • Request: minimum number of CPU cores required by a container. The default value is 0.25 cores.
                                              • Limit: maximum number of CPU cores that can be used by a container. This prevents containers from using excessive resources.

                                              If Request and Limit are not specified, the quota is not limited. For more information and suggestions about Request and Limit, see Configuring Container Specifications.

                                              Memory Quota

                                              +

                                              Memory Quota

                                              • Request: minimum amount of memory required by a container. The default value is 512 MiB.
                                              • Limit: maximum amount of memory available for a container. When memory usage exceeds the specified memory limit, the container will be terminated.
                                              +
                                              • Request: minimum amount of memory required by a container. The default value is 512 MiB.
                                              • Limit: maximum amount of memory available for a container. When memory usage exceeds the specified memory limit, the container will be terminated.

                                              If Request and Limit are not specified, the quota is not limited. For more information and suggestions about Request and Limit, see Configuring Container Specifications.

                                              (Optional) GPU Quota

                                              +

                                              (Optional) GPU Quota

                                              Configurable only when the cluster contains GPU nodes and the CCE AI Suite (NVIDIA GPU) add-on has been installed.

                                              +

                                              Configurable only when the cluster contains GPU nodes and the CCE AI Suite (NVIDIA GPU) add-on has been installed.

                                              • Do not use: No GPU will be used.
                                              • GPU card: The GPU is dedicated for the container.
                                              • GPU Virtualization: percentage of GPU resources used by the container. For example, if this parameter is set to 10%, the container will use 10% of GPU resources.
                                              -

                                              For details about how to use GPUs in the cluster, see Default GPU Scheduling in Kubernetes.

                                              +

                                              For details about how to use GPUs in a cluster, see Default GPU Scheduling in Kubernetes.

                                              (Optional) Privileged Container

                                              +

                                              (Optional) Privileged Container

                                              Programs in a privileged container have certain privileges.

                                              -

                                              If Privileged Container is enabled, the container is assigned privileges. For example, privileged containers can manipulate network devices on the host machine and modify kernel parameters.

                                              +

                                              Programs in a privileged container have certain privileges. If this option is enabled, the container will be assigned privileges. For example, privileged containers can manipulate network devices on the host machine, modify kernel parameters, access all devices on the node.

                                              +

                                              For more information, see Pod Security Standards.

                                              (Optional) Init Container

                                              +

                                              (Optional) Init Container

                                              Whether to use the container as an init container. An init container does not support health check.

                                              +

                                              Whether to use the container as an init container. An init container does not support health check.

                                              An init container is a special container that runs before other app containers in a pod are started. Each pod can contain multiple containers. In addition, a pod can contain one or more init containers. Application containers in a pod are started and run only after the running of all init containers completes. For details, see Init Containers.

                                              (Optional) Run Option

                                              +

                                              (Optional) Run Option

                                              Add run options for the container. For details, see Pod. CCE supports the following run options:

                                              +

                                              Add run options for the container. For details, see Pod. CCE supports the following run options:

                                              • stdin: allows containers to receive input from external sources, such as terminals or other input streams.
                                              • tty: allocates a pseudo terminal to containers, allowing you to send commands to them as if you were using a local terminal.

                                                In most cases, tty is enabled along with stdin, indicating that the terminal (tty) is associated with the standard input (stdin) of the container. This allows for interactive operations, similar to the kubectl exec -i -t command. The difference is that this parameter has been configured when the pod is launched.

                                              -
                                            • (Optional) Lifecycle: Configure operations to be performed in a specific phase of the container lifecycle, such as Startup Command, Post-Start, and Pre-Stop. For details, see Configuring Container Lifecycle Parameters.
                                            • (Optional) Health Check: Set the liveness probe, ready probe, and startup probe as required. For details, see Configuring Container Health Check.
                                            • (Optional) Environment Variables: Configure variables for the container running environment using key-value pairs. These variables transfer external information to containers running in pods and can be flexibly modified after application deployment. For details, see Configuring Environment Variables.
                                            • (Optional) Data Storage: Mount local storage or cloud storage to the container. The application scenarios and mounting modes vary with the storage type. For details, see Storage.
                                              • StatefulSets support dynamic attachment of EVS disks. For details, see Dynamically Mounting an EVS Disk to a StatefulSet or Dynamically Mounting a Local PV to a StatefulSet.

                                                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 PVC using the volumeClaimTemplates field, and the PVC is bound to the corresponding PV. Therefore, after the pod is rescheduled, the original data can still be mounted based on the PVC name.

                                                -
                                              • After a workload is created, the storage that is dynamically mounted cannot be updated.
                                              +
                                            • (Optional) Lifecycle: Configure operations to be performed in a specific phase of the container lifecycle, such as Startup Command, Post-Start, and Pre-Stop. For details, see Configuring the Container Lifecycle.
                                            • (Optional) Health Check: Set the liveness probe, ready probe, and startup probe as required. For details, see Configuring Container Health Check.
                                            • (Optional) Environment Variables: Configure variables for the container running environment using key-value pairs. These variables transfer external information to containers running in pods and can be flexibly modified after application deployment. For details, see Configuring Environment Variables.
                                            • (Optional) Data Storage: Mount local storage or cloud storage to the container. The application scenarios and mounting modes vary with the StorageClass. For details, see Storage.
                                              • StatefulSets support dynamic attachment of EVS disks. For details, see Dynamically Mounting an EVS Disk to a StatefulSet or Dynamically Mounting a Local PV to a StatefulSet.

                                                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 PVC using the volumeClaimTemplates field, and the PVC is bound to the corresponding PV. Therefore, after the pod is rescheduled, the original data can still be mounted based on the PVC name.

                                                +
                                              • After a workload is created, the dynamically mounted storage cannot be updated.
                                              -
                                            • (Optional) Security Context: Assign container permissions to protect the system and other containers from being affected. Enter the user ID to assign container permissions and prevent systems and other containers from being affected.
                                            • (Optional) Logging: Report standard container output logs to AOM by default, without requiring manual settings. You can manually configure the log collection path. For details, see Collecting Container Logs Using ICAgent.

                                              To disable the standard output of the current workload, add the annotation kubernetes.AOM.log.stdout: [] in Labels and Annotations. For details about how to use this annotation, see Table 1.

                                              +
                                            • (Optional) Security Context: Assign container permissions to protect the system and other containers from being affected. Enter the user ID to assign container permissions and prevent systems and other containers from being affected.
                                            • (Optional) Logging: Report standard container output logs to AOM by default, without requiring manual settings. You can manually configure the log collection path. For details, see Collecting Container Logs Using ICAgent.

                                              To disable the collection of the standard output logs of the current workload, add the annotation kubernetes.AOM.log.stdout: [] in Labels and Annotations in the Advanced Settings area. For details about how to use this annotation, see Table 1.

                                            -
                                        -
                                      • Image Access Credential: Select the credential used for accessing the image repository. The default value is default-secret. You can use default-secret to access images in SWR Shared Edition. For details about default-secret, see default-secret.
                                      • (Optional) GPU: All is selected by default. The workload instance will be scheduled to the node of the specified GPU type.
                                      • - -

                                        Headless Service Parameters

                                        -

                                        A headless Service is used to solve the problem of mutual access between pods in a StatefulSet. The headless Service provides a fixed access domain name for each pod. For details, see Headless Services.

                                        -

                                        (Optional) Service Settings

                                        -

                                        A Service provides external access for pods. With a static IP address, a Service forwards access traffic to pods and automatically balances load for these pods.

                                        -

                                        You can also create a Service after creating a workload. For details about Services of different types, see Overview.

                                        -
                                        (Optional) Advanced Settings
                                        • Upgrade: Specify the upgrade mode and parameters of the workload. Rolling upgrade and Replace upgrade are available. For details, see Configuring Workload Upgrade Policies.
                                        • Pod Management Policies

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

                                          -
                                          • OrderedReady: This is the default policy. The StatefulSet will deploy, delete, or scale pods in order and one by one. It continues only after the previous pod is ready or deleted.
                                          • Parallel: The StatefulSet will create pods in parallel to match the desired scale without waiting, and will delete all pods at once.
                                          -
                                        • Scheduling: Configure affinity and anti-affinity policies for flexible workload scheduling. Load affinity and node affinity are provided.
                                          • Load Affinity: Common load affinity policies are offered for quick load affinity deployment.
                                            • Not configured: No load affinity policy is configured.
                                            • Multi-AZ deployment preferred: Workload pods are preferentially scheduled to nodes in different AZs through pod anti-affinity.
                                            • Forcible multi-AZ deployment: Workload pods are forcibly scheduled to nodes in different AZs through pod anti-affinity (podAntiAffinity). If there are fewer AZs than pods, the extra pods will fail to run.
                                            • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
                                            -
                                          • Node Affinity: Common node affinity policies are offered for quick load affinity deployment.
                                            • Not configured: No node affinity policy is configured.
                                            • Specify node: Workload pods can be deployed on specified nodes through node affinity (nodeAffinity). If no node is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                            • Specify node pool: Workload pods can be deployed in a specified node pool through node affinity (nodeAffinity). If no node pool is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                            • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Node Affinity Scheduling (nodeAffinity).
                                            -
                                          -
                                        • 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 Configuring Tolerance Policies.
                                        • Labels and Annotations: Add labels or annotations for pods using key-value pairs. After entering the key and value, click Confirm. For details about how to use and configure labels and annotations, see Configuring Labels and Annotations.
                                        • DNS: Configure a separate DNS policy for the workload. For details, see DNS Configuration.
                                        • Network Configuration
                                          • Pod ingress/egress bandwidth limitation: You can set ingress/egress bandwidth limitation for pods. For details, see Configuring QoS for a Pod.
                                          • Whether to enable the static IP address: available only for clusters that support this function. After this function is enabled, you can set the interval for reclaiming expired pod IP addresses. For details, see Configuring a Static IP Address for a Pod.
                                          • Whether to enable a specified container network configuration: available only for clusters that support this function. After you enable a specified container network configuration, the workload will be created using the container subnet and security group in the configuration. For details, see Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration.
                                          • Specify the container network configuration name: Only the custom container network configuration whose associated resource type is workload can be selected.
                                          • IPv6 shared bandwidth: available only for clusters that support this function. After this function is enabled, you can configure a shared bandwidth for a pod with IPv6 dual-stack ENIs. For details, see Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack ENIs.
                                          +
                                        • Image Access Credential: Select the credential used for accessing the image repository. The default value is default-secret. You can use default-secret to access images in SWR Shared Edition. For details about default-secret, see default-secret.
                                        • (Optional) GPU: All is selected by default. The workload instance will be scheduled to the node of the specified GPU type.
                                        +

                                      • Configure the settings of the headless Service associated with the workload.

                                        A headless Service provides a fixed access domain name for every pod within a StatefulSet for mutual pod access. For details, see Headless Service.

                                        +

                                      • (Optional) Configure the settings of the Service associated with the workload.

                                        A Service provides external access for pods. With a static IP address, a Service forwards access traffic to pods and automatically balances load for these pods.

                                        +

                                        You can also create a Service after creating a workload. For details about Services of different types, see Service Overview.

                                        +

                                      • (Optional) Configure advanced settings for the workload.

                                        +

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

                                        Parameter

                                        +

                                        Description

                                        +

                                        Upgrade

                                        +

                                        Specify the upgrade mode and parameters of the workload. Rolling upgrade and Replace upgrade are available. For details, see Upgrading and Rolling Back a Workload.

                                        +

                                        Pod Management Policies

                                        +

                                        For some distributed systems, the StatefulSet ordering guarantees are unnecessary and/or undesirable. These systems require only uniqueness and identifiers.

                                        +
                                        • OrderedReady: This is the default policy. The StatefulSet will deploy, delete, or scale pods in order and one by one. It continues only after the previous pod is ready or deleted.
                                        • Parallel: The StatefulSet will create pods in parallel or delete all pods at once. Changes to the StatefulSets apply immediately on the pods.
                                        +

                                        Scheduling

                                        +

                                        Configure affinity and anti-affinity policies for flexible workload scheduling. Load affinity and node affinity are provided.

                                        +
                                        • Load Affinity: Common load affinity policies are offered for quick load affinity deployment.
                                          • Not configured: No load affinity policy is configured.
                                          • Multi-AZ deployment preferred: Workload pods are preferentially scheduled to nodes in different AZs through pod anti-affinity.
                                          • Forcible multi-AZ deployment: Workload pods are forcibly scheduled to nodes in different AZs through pod anti-affinity (podAntiAffinity). If there are fewer AZs than pods, the extra pods will fail to run.
                                          • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
                                          +
                                        • Node Affinity: Common node affinity policies are offered for quick load affinity deployment.
                                          • Not configured: No node affinity policy is configured.
                                          • Specify node: Workload pods can be deployed on specified nodes through node affinity (nodeAffinity). If no node is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                          • Specify node pool: Workload pods can be deployed in a specified node pool through node affinity (nodeAffinity). If no node pool is specified, the pods will be randomly scheduled based on the default scheduling policy of the cluster.
                                          • Customize affinity: Affinity and anti-affinity policies can be customized. For details, see Configuring Node Affinity Scheduling (nodeAffinity).
                                        +

                                        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 Configuring Tolerance Policies.

                                        +

                                        Labels and Annotations

                                        +

                                        Add labels or annotations for pods using key-value pairs. After the setting, click Confirm. For details about labels and annotations, see Configuring Labels and Annotations.

                                        +

                                        DNS

                                        +

                                        Configure a separate DNS policy for the workload. For details, see DNS Configuration.

                                        +

                                        Network Configuration

                                        +
                                        • Pod ingress/egress bandwidth limit: You can set ingress and egress bandwidth limits for pods. For details, see Configuring QoS for a Pod.
                                        • Whether to enable the static IP address: available only for clusters that support this function. After this function is enabled, you can set the interval for reclaiming expired pod IP addresses. For details, see Configuring a Static IP Address for a Pod.
                                        • Whether to enable a specified container network configuration: available only for clusters that support this function. After you enable a specified container network configuration, the workload will be created using the container subnet and security group in the configuration. For details, see Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration.
                                        • Specify the container network configuration name: Only the custom container network configuration whose associated resource type is workload can be selected.
                                        • IPv6 shared bandwidth: available only for clusters that support this function. After this function is enabled, you can configure a shared bandwidth for a pod with IPv6 dual-stack network interfaces. For details, see Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack Network Interfaces.
                                        +
                                        -

                                      • Click Create Workload in the lower right corner. After a period of time, the workload enters the Running state.

                                        +

                                      • Click Create Workload in the lower right corner. After a period of time, the workload enters the Running state.

                                      • Using kubectl

                                        In this example, a Nginx workload is used and the EVS volume is dynamically mounted to it using the volumeClaimTemplates field.

                                        1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
                                        2. Create and edit the nginx-statefulset.yaml file.

                                          nginx-statefulset.yaml is an example file name, and you can change it as required.

                                          vi nginx-statefulset.yaml
                                          -

                                          The following provides an example of the file contents. For more information on StatefulSet, see the Kubernetes documentation.

                                          +

                                          The below content shows only an example. For details about StatefulSets, see the Kubernetes official documentation.

                                          apiVersion: apps/v1
                                           kind: StatefulSet
                                           metadata:
                                          @@ -165,9 +239,9 @@ spec:
                                                   storageClassName: csi-disk # StorageClass name. The value is csi-disk for the EVS volume.
                                             updateStrategy:
                                               type: RollingUpdate
                                          -

                                          Create and edit the nginx-headless.yaml file.

                                          +

                                          Create the nginx-headless.yaml file.

                                          vi nginx-headless.yaml
                                          -

                                          The content is as follows:

                                          +

                                          File content:

                                          apiVersion: v1
                                           kind: Service
                                           metadata:
                                          @@ -187,14 +261,14 @@ spec:
                                                 port: 80
                                                 protocol: TCP
                                             type: ClusterIP
                                          -

                                        3. Create the workload.

                                          kubectl create -f nginx-statefulset.yaml
                                          -

                                          If the following information is displayed, the StatefulSet has been successfully created.

                                          +

                                        4. Create a workload.

                                          kubectl create -f nginx-statefulset.yaml
                                          +

                                          If information similar to the following is displayed, the StatefulSet has been created:

                                          statefulset.apps/nginx created

                                          Create a headless Service.

                                          kubectl create -f nginx-headless.yaml

                                          If the following information is displayed, the headless service has been successfully created.

                                          service/nginx-svc created
                                          -

                                        5. If the workload will be accessed through a ClusterIP or NodePort Service, configure the access mode. For details, see Network.
                                        +

                                      • If the workload will be accessed through a ClusterIP or NodePort Service, configure the access mode. For details, see Networking.
                                      • diff --git a/docs/cce/umn/cce_10_0054.html b/docs/cce/umn/cce_10_0054.html index 4a913e918..d5125ff5b 100644 --- a/docs/cce/umn/cce_10_0054.html +++ b/docs/cce/umn/cce_10_0054.html @@ -20,21 +20,21 @@

                                        The master node's memory is overloaded, affecting system stability.

                                        Stop executing a large number of queries.

                                        -

                                        To improve a cluster's anti-overload capability, scale up the cluster. For details, see Changing a Cluster Scale.

                                        +

                                        To prevent a cluster from being overloaded, scale up the cluster. For details, see Changing a Cluster Scale.

                                        Master node

                                        Modifying the security group of master nodes in a cluster

                                        -
                                        NOTE:

                                        Naming rule of a master node's security group: Cluster name-cce-control-Random digits

                                        +
                                        NOTE:

                                        Naming rule of a master node's security group: Cluster name-cce-control-{Random ID}

                                        The master nodes may be unavailable.

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

                                        +

                                        Restore the security group by referring to "Creating a Cluster" and allow traffic from and to the master nodes.

                                        Letting the node expire or destroying the node

                                        +

                                        Letting a master node expire or destroying a master node

                                        The master node will be unavailable.

                                        Roll back to the original version.

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

                                        +

                                        Deleting or formatting core directories such as /etc/kubernetes on a node

                                        The master node will be unavailable.

                                        This operation cannot be undone.

                                        Changing the node IP address

                                        +

                                        Changing the IP address of a master node

                                        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)

                                        +

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

                                        The master node may be unavailable.

                                        Worker node

                                        Modifying the security group of worker nodes in a cluster

                                        -
                                        NOTE:

                                        Naming rule of a worker node's security group: Cluster name-cce-node-Random digits

                                        +
                                        NOTE:

                                        Naming rule of a worker node's security group: Cluster name-cce-node-{Random ID}

                                        The node may be unavailable.

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

                                        +

                                        Restore the security group by referring to "Creating a Cluster" and allow traffic from and to the worker nodes.

                                        Modifying the DNS configuration (/etc/resolv.conf) of a node

                                        Internal domain names cannot be accessed, which may lead to errors in functions such as add-on errors or errors in in-place node upgrade.

                                        +

                                        Internal domain names cannot be accessed, and some functions such as add-ons and in-place node upgrades become abnormal.

                                        NOTE:

                                        If your service needs to use an on-premises DNS, configure the DNS in the workload. Do not change node's DNS address. For details, see DNS Configuration.

                                        Upgrading the kernel or components on which the container platform depends (such as Open vSwitch, IPVLAN, Docker, and containerd)

                                        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.)

                                        +
                                        NOTE:

                                        Node running depends on the system kernel version. Do not use the yum update command to update or reinstall the 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

                                        +

                                        Changing the IP address of a node

                                        The node will become 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 deleting the data disk

                                        +

                                        Deleting or modifying the /opt/cloud/cce and /var/paas directories, and deleting a data disk

                                        The node will become unavailable.

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

                                        Modifying the node directory permission and the container directory permission, which involves the following directories:

                                        +

                                        Modifying the node directory permission and the container directory permission. The following directories are involved:

                                        /usr/lib/systemd/system/kubelet.service
                                         /usr/lib/systemd/system/containerd-monit.service
                                         /usr/lib/systemd/system/docker-monit.service
                                        @@ -177,7 +177,7 @@
                                         

                                        Do not modify the permissions. Restore the permissions if they have been modified.

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

                                        +

                                        Formatting or partitioning system disks, Docker disks, and kubelet disks on a node

                                        The node may be unavailable.

                                        Installing other software on nodes

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

                                        +

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

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

                                        +

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

                                        Modifying NetworkManager configurations

                                        @@ -198,11 +198,11 @@

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

                                        Deleting system images such as cce-pause from the node

                                        +

                                        Deleting system images such as cce-pause from a node

                                        Containers cannot be created and system images cannot be pulled.

                                        Copy the image from a functional node for restoration.

                                        +

                                        Copy the image from a node that functions normally.

                                        Changing the flavor of a node in a node pool on the ECS console

                                        @@ -246,11 +246,11 @@

                                        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

                                        +

                                        Not configuring the node security group to allow UDP traffic to the container CIDR blocks over port 53

                                        The DNS in the cluster cannot work properly.

                                        Restore the security group by referring to the operations provided for a newly created cluster and allow traffic from the security group to pass through.

                                        +

                                        Restore the security group by referring to the operations provided for a newly created cluster and allow traffic to the container CIDR blocks.

                                        Deleting network-attachment-definitions CRD resources of default-network

                                        @@ -282,8 +282,8 @@

                                        Configuring privileged containers for a workload and directly operating the host hardware, which are prone to misoperations on the system files of the node

                                        -

                                        For example, if you set the startup command to /usr/sbin/init and run systemctl in containers, the system files located in the /lib directory of the node may be damaged.

                                        +

                                        Configuring privileged containers for a workload and directly operating the host hardware. There may be misoperations on the system files of the node.

                                        +

                                        For example, if you set the startup command to /usr/sbin/init and run systemctl in containers, the system files in the /lib directory of the node may be damaged.

                                        All mount points of the node will be unmounted. As a result, the node will be malfunctional, resulting in failed pods and affected storage add-on functions.

                                        Table 4 Service ELB

                                        Operation

                                        +
                                        @@ -303,80 +303,80 @@ - - - - - - - - - - - - - - - - - - - - @@ -421,7 +421,7 @@ - @@ -493,9 +493,9 @@ - - diff --git a/docs/cce/umn/cce_10_0059.html b/docs/cce/umn/cce_10_0059.html index 6b421a3cb..9888db721 100644 --- a/docs/cce/umn/cce_10_0059.html +++ b/docs/cce/umn/cce_10_0059.html @@ -1,141 +1,173 @@

                                        Configuring Network Policies to Restrict Pod Access

                                        -

                                        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.

                                        +

                                        Network policies are designed by Kubernetes to restrict pod access. Like a firewall at the application layer, network policies 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.

                                        The following selectors are available for network policies:

                                        -
                                        • 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.
                                        +
                                        • 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 CIDR blocks to allow as ingress sources or egress destinations.

                                        Relationships Between Network Policies and Cluster Types

                                        -
                                        Table 4 Load balancing (operations on the ELB console)

                                        Operation

                                        Impact

                                        Deleting a load balancer that has been bound to a CCE cluster on the ELB console

                                        +

                                        Deleting a load balancer that has been associated with a CCE cluster

                                        Accessing the target Service or ingress will fail.

                                        Do not delete such a load balancer.

                                        +

                                        Do not delete such load balancer.

                                        Disabling a load balancer that has been bound to a CCE cluster on the ELB console

                                        +

                                        Disabling a load balancer that has been associated with a CCE cluster

                                        Accessing the target Service or ingress will fail.

                                        Do not disable such a load balancer. If a load balancer has been disabled, enable it.

                                        Changing the private IPv4 address of a load balancer on the ELB console

                                        +

                                        Changing the private IPv4 address of a load balancer

                                        • The network traffic forwarded using the private IPv4 addresses will be interrupted.
                                        • The IP addresses in the status field of Service or ingress YAML files will be changed.

                                        Do not change private IPv4 addresses of load balancers. Change them back if they have been changed.

                                        Unbinding the IPv4 EIP from a load balancer on the ELB console

                                        +

                                        Unbinding the IPv4 EIP from a load balancer

                                        After the EIP is unbound from the load balancer, the load balancer will not be able to forward Internet traffic.

                                        Restore the EIP binding.

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

                                        +

                                        Adding a listener to a load balancer that has been associated with a CCE cluster

                                        If a load balancer is automatically created when a Service or an ingress is created, the custom listener of the load balancer cannot be deleted when the Service or ingress is deleted. In this case, the load balancer cannot be automatically deleted.

                                        +

                                        If a load balancer is automatically created when a Service or an ingress is created, any listener added to the load balancer on the ELB console cannot be deleted when the Service or ingress is deleted. In this case, the load balancer cannot be automatically deleted.

                                        Use the listener automatically created when a Service or an ingress is created. If a custom listener is used, manually delete the target load balancer.

                                        +

                                        Use the listener automatically created when a Service or an ingress is created. If a listener added on the ELB console is used, manually delete this load balancer.

                                        Deleting a listener automatically created by CCE on the ELB console

                                        +

                                        Deleting a listener automatically added by CCE

                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted, for example, due to a cluster upgrade, all your modifications will be reset by CCE.
                                        +
                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE.

                                        Re-create or update the Service or ingress.

                                        Modifying the basic configurations such as the name, access control, timeout, or description of a listener created by CCE on the ELB console

                                        +

                                        Modifying the basic configurations such as the name, access control, timeout, or description of a listener added by CCE

                                        After master nodes are restarted, for example, due to a cluster upgrade, all your modifications will be reset by CCE if the listener is deleted.

                                        +

                                        After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE if the listener is deleted.

                                        Do not modify the basic configurations of the listener created by CCE. Restore the configurations if they have been modified.

                                        Modifying the backend server group of a listener created by CCE on the ELB console, including adding or deleting backend servers to or from the server group

                                        +

                                        Modifying the backend server group of a listener added by CCE, including adding or deleting backend servers to or from the server group

                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted, for example, due to a cluster upgrade, all your modifications will be reset by CCE.
                                          • Deleted backend servers will be restored.
                                          • Added backend servers will be removed.
                                          +
                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE.
                                          • Deleted backend servers will be restored.
                                          • Added backend servers will be removed.

                                        Re-create or update the Service or ingress.

                                        Replacing the backend server group of a listener created by CCE on the ELB console

                                        +

                                        Replacing the backend server group of a listener added by CCE

                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted, for example, due to a cluster upgrade, all servers in the backend server group will be reset by CCE.
                                        +
                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted due to reasons such as a cluster upgrade, all servers in the backend server group will be reset by CCE.

                                        Re-create or update the Service or ingress.

                                        Modifying the forwarding policy of a listener created by CCE on the ELB console, including adding or deleting forwarding rules

                                        +

                                        Modifying the forwarding policy of a listener added by CCE, including adding or deleting forwarding rules

                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted, for example, due to a cluster upgrade, all your modifications will be reset by CCE if the forwarding rules are added using an ingress.
                                        +
                                        • Accessing the target Service or ingress will fail.
                                        • After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE if the forwarding rules are added using an ingress.

                                        Do not modify the forwarding policy of such a listener. Restore the configurations if they have been modified.

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

                                        +

                                        Changing the certificate for a load balancer managed by CCE

                                        After master nodes are restarted, for example, due to a cluster upgrade, all servers in the backend server group will be reset by CCE.

                                        +

                                        After master nodes are restarted due to reasons such as a cluster upgrade, all servers in the backend server group will be reset by CCE.

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

                                        The number of collection shards configured in Cloud Native Cluster Monitoring exceeded the recommended value (It is recommended to configure one collection shard per 50 nodes.)

                                        +

                                        Configuring a larger number of collection shards in Cloud Native Cluster Monitoring than the recommended value (one collection shards per 50 nodes)

                                        Excessive shards may overload the master node's memory, affecting system stability.

                                        Modifying add-on resources on the backend

                                        +

                                        Modifying add-on resources in the backend

                                        The add-on becomes malfunctional or other unexpected issues occur.

                                        +

                                        Add-on exceptions or other unexpected issues may occur. For example, parameter settings are overwritten after an upgrade.

                                        Perform operations on the add-on configuration page or using open add-on management APIs.

                                        Cluster Type

                                        +
                                        - - + - - - + - - - + - - - + - - - + - - - - - + - - - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - +

                                        Cluster Type

                                        CCE Standard Cluster

                                        +

                                        CCE Standard Cluster

                                        CCE Turbo Cluster

                                        +

                                        CCE Standard Cluster

                                        +

                                        CCE Turbo Cluster

                                        Network Model

                                        +

                                        Network Model

                                        Tunnel

                                        +

                                        Tunnel

                                        Cloud Native Network 2.0

                                        +

                                        VPC

                                        +

                                        Cloud Native Network 2.0

                                        NetworkPolicy

                                        +

                                        NetworkPolicy

                                        Enabled by default

                                        +

                                        Enabled by default

                                        Disabled by default (To use network policies, enable DataPlane V2 when creating a cluster.)

                                        +

                                        Disabled by default (To use network policies, enable DataPlane V2 when creating a cluster.)

                                        +

                                        Disabled by default (To use network policies, enable DataPlane V2 when creating a cluster.)

                                        Data plane implementation

                                        +

                                        Data plane implementation

                                        OpenvSwitch

                                        +

                                        OpenvSwitch

                                        eBPF

                                        +

                                        eBPF

                                        +

                                        eBPF

                                        Cluster version for inbound rules

                                        +

                                        Cluster version for ingress rules

                                        All versions

                                        +

                                        All versions

                                        v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later

                                        +

                                        Cluster version: v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, or later

                                        +

                                        Cluster version: v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later

                                        Cluster version for outbound rules

                                        +

                                        Cluster version for egress rules

                                        v1.23 and later

                                        +

                                        v1.23 and later

                                        Selector for inbound rules

                                        +

                                        Selector for ingress rules

                                        namespaceSelector

                                        +

                                        namespaceSelector

                                        podSelector

                                        namespaceSelector

                                        +

                                        namespaceSelector

                                        +

                                        podSelector

                                        +

                                        IPBlock

                                        +

                                        namespaceSelector

                                        podSelector

                                        IPBlock

                                        Selector for outbound rules

                                        +

                                        Selector for egress rules

                                        namespaceSelector

                                        +

                                        namespaceSelector

                                        podSelector

                                        IPBlock

                                        Supported OS

                                        +

                                        Supported OS

                                        EulerOS

                                        -

                                        HCE OS 2.0

                                        +

                                        EulerOS

                                        +

                                        HCE OS 2.0

                                        HCE OS 2.0

                                        +

                                        HCE OS 2.0

                                        +

                                        HCE OS 2.0

                                        IPv6 network policies

                                        +

                                        IPv6 network policies

                                        Not supported

                                        +

                                        Not supported

                                        Supported

                                        +

                                        Not supported

                                        +

                                        Supported

                                        Secure containers

                                        +

                                        Secure containers

                                        Not supported

                                        +

                                        Not supported

                                        Not supported

                                        +

                                        Not supported

                                        +

                                        Not supported

                                        IPBlock scope

                                        +

                                        IPBlock scope

                                        Not limited

                                        +

                                        Not limited

                                        The CIDR blocks and node IP addresses in the container CIDR block cannot be configured.

                                        +

                                        Subnets within the pod CIDR block, Service CIDR block, and node IP addresses

                                        +

                                        Subnets within the pod CIDR block, Service CIDR block, and node IP addresses

                                        Limit ClusterIP access through workload labels

                                        +

                                        Limit ClusterIP access through workload labels

                                        Not supported

                                        +

                                        Not supported

                                        Supported

                                        +

                                        Supported

                                        +

                                        Supported

                                        Limit the internal cloud server CIDR block of 100.125.0.0/16

                                        +

                                        Limit the internal cloud server CIDR block of 100.125.0.0/16

                                        Supported

                                        +

                                        Supported

                                        Not supported

                                        +

                                        Supported

                                        +

                                        Not supported

                                        SCTP

                                        +

                                        SCTP

                                        Not supported

                                        +

                                        Not supported

                                        Not supported

                                        +

                                        Supported

                                        +

                                        Not supported

                                        Always allow access to pods on a node from other nodes

                                        +

                                        Always allow access to pods on a node from other nodes

                                        Supported

                                        +

                                        Supported

                                        Supported

                                        +

                                        Supported

                                        +

                                        Supported

                                        Configure EndPort in network policies

                                        +

                                        Configure EndPort in network policies

                                        Not supported

                                        +

                                        Not supported

                                        Not supported

                                        +

                                        Supported

                                        +

                                        Not supported

                                        -
                                        • CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.
                                        • Secure containers (such as Kata as the container runtime) are not supported by network policies.
                                        • If you upgrade a CCE standard cluster with a tunnel network to a version that supports egress rules in in-place mode, the rules will not work because the node OS is not upgraded. In this case, reset the node.
                                        • When a network policy is enabled for a cluster that uses a tunnel network, the source IP address of a pod accessing the CIDR block of a Service will be recorded in the optional field of the reported IP address data. This enables the configuration of network policy rules on the destination pod, taking into account the source IP address of the pod.
                                        +
                                        • CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.
                                        • Secure containers (such as Kata as the container runtime) are not supported by network policies.
                                        • If you upgrade a CCE standard cluster with a tunnel network to a version that supports egress rules in in-place mode, the rules will not work because the node OS is not upgraded. In this case, reset the node.
                                        • When a network policy is enabled for a cluster with a tunnel network, a pod's source IP address is embedded in the optional field of packets it sends to any Service CIDR block. This enables the configuration of network policy rules on the destination pod, taking into account the source IP address of the pod.
                                        -

                                        Using Ingress Rules Through YAML

                                        • Scenario 1: Use a network policy to limit access to a pod to only pods with specific labels.
                                          Figure 1 podSelector
                                          -

                                          The pod labeled with role=db only permits access to its port 6379 from pods labeled with role=frontend. To do so, perform the following operations:

                                          +

                                          Using Ingress Rules Through YAML

                                          • Scenario 1: Controlled by a preset network policy, a pod can only be accessed by pods with specific labels.
                                            Figure 1 podSelector
                                            +

                                            The pod labeled with role=db only permits access to its port 6379 from pods labeled with role=frontend. To achieve this, take the following steps:

                                            1. Create the access-demo1.yaml file.
                                              vim access-demo1.yaml

                                              File content:

                                              apiVersion: networking.k8s.io/v1
                                              @@ -149,19 +181,19 @@ spec:
                                                     role: db
                                                 ingress:                      # This is an ingress rule.
                                                 - from:
                                              -    - podSelector:              # Only allow the access of the pods labeled with role=frontend.
                                              +    - podSelector:              # Only allows the access of the pods labeled with role=frontend.
                                                       matchLabels:
                                                         role: frontend
                                                   ports:                      # Only TCP can be used to access port 6379.
                                                   - protocol: TCP
                                                     port: 6379
                                              -
                                            2. Run the following command to create the network policy based on the access-demo1.yaml file:
                                              kubectl apply -f access-demo1.yaml
                                              +
                                            3. Run the following command to create the network policy defined in the access-demo1.yaml file:
                                              kubectl apply -f access-demo1.yaml

                                              Expected output:

                                              networkpolicy.networking.k8s.io/access-demo1 created
                                          -
                                          • Scenario 2: Use a network policy to limit access to a pod to only pods in a specific namespace.
                                            Figure 2 namespaceSelector
                                            -

                                            The pod labeled with role=db only permits access to its port 6379 from pods in the namespace labeled with project=myproject. To do so, perform the following operations:

                                            +
                                            • Scenario 2: Controlled by a preset network policy, a pod can only be accessed by pods in a specific namespace.
                                              Figure 2 namespaceSelector
                                              +

                                              The pod labeled with role=db only permits access to its port 6379 from pods in the namespace labeled with project=myproject. To achieve this, take the following steps:

                                              1. Create the access-demo2.yaml file.
                                                vim access-demo2.yaml

                                                File content:

                                                apiVersion: networking.k8s.io/v1
                                                @@ -174,23 +206,23 @@ spec:
                                                       role: db
                                                   ingress:                      # This is an ingress rule.
                                                   - from:
                                                -    - namespaceSelector:        # Only allow the access of the pods in the namespace labeled with project=myproject.
                                                +    - namespaceSelector:        # Only allows the access of the pods in the namespace labeled with project=myproject.
                                                         matchLabels:
                                                           project: myproject
                                                     ports:                      # Only TCP can be used to access port 6379.
                                                     - protocol: TCP
                                                       port: 6379
                                                -
                                              2. Run the following command to create the network policy based on the access-demo2.yaml file:
                                                kubectl apply -f access-demo2.yaml
                                                +
                                              3. Run the following command to create the network policy defined in the access-demo2.yaml file:
                                                kubectl apply -f access-demo2.yaml

                                                Expected output:

                                                networkpolicy.networking.k8s.io/access-demo2 created

                                          Using Egress Rules Through YAML

                                          The clusters of v1.23 or later using a tunnel network support egress rules. Only nodes running EulerOS 2.9 or HCE OS 2.0 are supported.

                                          -

                                          Egress rules are only supported by CCE Turbo clusters of v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later with DataPlane V2 enabled. Additionally, nodes in these clusters must only run HCE OS 2.0.

                                          +

                                          Egress rules are only available for CCE Turbo clusters or other CCE clusters using a VPC network. The cluster version must be v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0 or later, and DataPlane V2 must be enabled. Additionally, nodes in these clusters must run HCE OS 2.0.

                                          -
                                          • Scenario 1: Use a network policy to limit a pod's access to specific addresses.
                                            Figure 3 IPBlock
                                            -

                                            The pod labeled with role=db only permits access to the 172.16.0.0/16 CIDR block, excluding 172.16.0.40/32 within it. To do so, perform the following operations:

                                            +
                                            • Scenario 1: Controlled by a preset network policy, pods can only access specific addresses.
                                              Figure 3 IPBlock
                                              +

                                              The pods labeled role=db only allow access to 172.16.0.0/16, excluding 172.16.0.40/32. To achieve this, take the following steps:

                                              1. Create the access-demo3.yaml file.
                                                vim access-demo3.yaml

                                                File content:

                                                apiVersion: networking.k8s.io/v1
                                                @@ -199,23 +231,23 @@ metadata:
                                                   name: access-demo3
                                                   namespace: default
                                                 spec:
                                                -  policyTypes:                  # Must be specified for an egress rule.
                                                +  policyTypes:                  # This policy type must be specified for egress rules.
                                                     - Egress
                                                   podSelector:                  # The rule takes effect for pods with the role=db label.
                                                     matchLabels:
                                                       role: db
                                                -  egress:                       # Egress rule
                                                +  egress:                       # This is an egress rule.
                                                   - to:
                                                     - ipBlock:
                                                -        cidr:172.16.0.0/16    # Allow access to this CIDR block in the outbound direction.
                                                +        cidr: 172.16.0.0/16    # Allows access to this CIDR block in the outbound direction.
                                                         except:
                                                -        - 172.16.0.40/32        # Block access to this address in the CIDR block.
                                                -
                                              2. Run the following command to create the network policy based on the access-demo3.yaml file:
                                                kubectl apply -f access-demo3.yaml
                                                + - 172.16.0.40/32 # Blocks access to this CIDR block. This CIDR block is in the allowed CIDR block. +
                                              3. Run the following command to create the network policy defined in the access-demo3.yaml file:
                                                kubectl apply -f access-demo3.yaml

                                                Expected output:

                                                networkpolicy.networking.k8s.io/access-demo3 created
                                              -
                                            • Scenario 2: Use a network policy to limit access to a pod to only pods with specific labels and this pod can only access specific pods.
                                              Figure 4 Using both ingress and egress
                                              -

                                              The pod labeled with role=db only permits access to its port 6379 from pods labeled with role=frontend, and this pod can only access the pods labeled with role=web. You can use the same rule to configure both ingress and egress in a network policy. To do so, perform the following operations:

                                              +
                                            • Scenario 2: Controlled by a preset network policy, a pod can only be accessed by pods with specific labels, while this pod itself can only access specific pods.
                                              Figure 4 Using both ingress and egress
                                              +

                                              The pod labeled with role=db only permits access to its port 6379 from pods labeled with role=frontend, and this pod can only access the pods labeled with role=web. You can use the same rule to configure both ingress and egress in a network policy. To achieve this, take the following steps:

                                              1. Create the access-demo4.yaml file.
                                                vim access-demo4.yaml

                                                File content:

                                                apiVersion: networking.k8s.io/v1
                                                @@ -232,25 +264,25 @@ spec:
                                                       role: db
                                                   ingress:                      # This is an ingress rule.
                                                   - from:
                                                -    - podSelector:              # Only allow the access of the pods labeled with role=frontend.
                                                +    - podSelector:              # Only allows the access of the pods labeled with role=frontend.
                                                         matchLabels:
                                                           role: frontend
                                                     ports:                      # Only TCP can be used to access port 6379.
                                                     - protocol: TCP
                                                       port: 6379
                                                -  egress:                       # Egress rule
                                                +  egress:                       # This is an egress rule.
                                                   - to:
                                                -    - podSelector:              # Only pods with the role=web label can be accessed.
                                                +    - podSelector:              # The rule takes effect for pods with the role=web label.
                                                         matchLabels:
                                                           role: web
                                                -
                                              2. Run the following command to create the network policy based on the access-demo4.yaml file:
                                                kubectl apply -f access-demo4.yaml
                                                +
                                              3. Run the following command to create the network policy defined the access-demo4.yaml file:
                                                kubectl apply -f access-demo4.yaml

                                                Expected output:

                                                networkpolicy.networking.k8s.io/access-demo4 created
                                          -

                                          Creating a Network Policy on the Console

                                          1. Log in to the CCE console and click the cluster name to access the cluster console.
                                          2. Choose Policies 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 use the label of an existing workload.
                                            • Inbound Rule: Click to add an inbound rule. For details about parameter settings, see Table 1.

                                              -

                                              +

                                              Creating a Network Policy on the Console

                                              1. Log in to the CCE console and click the cluster name to access the cluster console.
                                              2. Choose Policies 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 use the label of an existing workload.
                                                • Inbound Rule: Click to add an inbound rule. For details about parameter settings, see Table 1.

                                                  +

                                                  @@ -266,7 +298,7 @@ spec:
                                                  Table 1 Adding an inbound rule

                                                  Parameter

                                                  Source CIDR Block

                                                  For clusters of v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later versions with DataPlane V2 enabled, you can configure the source CIDR block.

                                                  -

                                                  The specified source CIDR block allows traffic from a destination CIDR block (multiple exception CIDR blocks can be specified). Separate the destination and exception CIDR blocks using a vertical bar (|). If there are multiple exception CIDR blocks, separate them using 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 and 172.17.2.0/24.

                                                  +

                                                  The specified source CIDR block allows traffic from a destination CIDR block (multiple exception CIDR blocks can be specified). Separate the destination and exception CIDR blocks using a vertical bar (|). If there are multiple exception CIDR blocks, separate them using 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 172.17.1.0/24 and 172.17.2.0/24 are inaccessible.

                                                  Source Namespace

                                                  @@ -283,8 +315,8 @@ spec:
                                                  -
                                                • Outbound Rule: Click to add an outbound rule. For details about parameter settings, see Table 2.

                                                  -

                                                  +
                                                • Outbound Rule: Click to add an outbound rule. For details about parameter settings, see Table 2.

                                                  +

                                                  @@ -299,7 +331,7 @@ spec: -
                                                  Table 2 Adding an outbound rule

                                                  Parameter

                                                  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 using a vertical bar (|). If there are multiple exception CIDR blocks, separate them using 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 and 172.17.2.0/24.

                                                  +

                                                  Allow requests to be routed to a specified CIDR block (and not to the exception CIDR blocks). Separate the destination and exception CIDR blocks using a vertical bar (|). If there are multiple exception CIDR blocks, separate them using 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 172.17.1.0/24 and 172.17.2.0/24 are inaccessible.

                                                  Destination Namespace

                                                  diff --git a/docs/cce/umn/cce_10_0063.html b/docs/cce/umn/cce_10_0063.html index 3fc3dd49b..b5239f518 100644 --- a/docs/cce/umn/cce_10_0063.html +++ b/docs/cce/umn/cce_10_0063.html @@ -4,8 +4,8 @@

                                                  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 click the cluster name to access the cluster console.
                                                  2. In the navigation pane, choose Nodes. On the page displayed, click the Node Pools tab and then the name of the node pool for which an auto scaling policy has been created to view the node pool details.
                                                  3. On the node pool details page, click the Auto Scaling tab to view the auto scaling configuration and scaling records.

                                                    You can obtain created auto scaling policies on the Policies page.

                                                    -
                                                    1. Log in to the CCE console and click the cluster name to access the cluster console.
                                                    2. In the navigation pane, choose Policies. On the page displayed, click the Node Scaling Policies tab.
                                                    3. Check the configuration of the auto scaling policies. Choose More > Scaling History for the target policy to check the scaling records of the policy.
                                                    +
                                                    1. Log in to the CCE console and click the cluster name to access the cluster console.
                                                    2. In the navigation pane, choose Nodes.On the page displayed, click the Node Pools tab and then the name of the node pool for which an auto scaling policy has been created to view the node pool details.
                                                    3. On the node pool details page, click the Auto Scaling tab to view the auto scaling configuration and scaling records.

                                                      You can obtain created auto scaling policies on the Policies page.

                                                      +
                                                      1. Log in to the CCE console and click the cluster name to access the cluster console.
                                                      2. In the navigation pane, choose Policies. On the page displayed, click the Node Scaling Policies tab.
                                                      3. Check the configuration of the auto scaling policies. Choose More > Scaling History for the target policy to check the scaling records of the policy.

                                                    @@ -20,7 +20,7 @@
                                                    diff --git a/docs/cce/umn/cce_10_0064.html b/docs/cce/umn/cce_10_0064.html index b6aa1fe38..e5745f530 100644 --- a/docs/cce/umn/cce_10_0064.html +++ b/docs/cce/umn/cce_10_0064.html @@ -10,7 +10,7 @@
                                                  4. - diff --git a/docs/cce/umn/cce_10_0066.html b/docs/cce/umn/cce_10_0066.html index 28213b8de..957f991cb 100644 --- a/docs/cce/umn/cce_10_0066.html +++ b/docs/cce/umn/cce_10_0066.html @@ -1,129 +1,130 @@

                                                    CCE Container Storage (Everest)

                                                    -

                                                    Introduction

                                                    Everest is a cloud native container storage system, which enables clusters of Kubernetes v1.15.6 or later to access cloud storage services through the CSI.

                                                    +

                                                    Introduction

                                                    Container Storage Interface (CSI) is a storage add-on standard recommended by the Kubernetes community. It is used for unified interconnection between the container orchestration platform and various storage systems. Based on the CSI standard, CCE provides CCE Container Storage (Everest), a self-developed storage add-on. This add-on can seamlessly interconnect with multiple IaaS storage services, including EVS (block storage), SFS, OBS, and SFS Turbo, to provide multiple types of persistent storage capabilities for containers.

                                                    +

                                                    CCE Container Storage (Everest) provides diverse persistent storage capabilities for clusters. It can adapt to storage requirements in various service scenarios, such as databases, high-performance computing, shared file access, and large file archiving. This add-on provides a unified storage interface, supports multiple types of storage media, and works closely with CCE scheduling policies, auto scaling strategies, and security systems. It can significantly improve the storage performance and service continuity of cloud native workloads.

                                                    Everest is a system resource add-on. It is installed by default when a cluster of Kubernetes v1.15 or later is created.

                                                    Notes and Constraints

                                                    • In version 1.2.0 of the Everest add-on, key authentication is optimized when OBS is used. After the Everest add-on is upgraded from a version earlier than 1.2.0, restart all workloads that use OBS in the cluster. Otherwise, workloads may not be able to use OBS.

                                                    Installing the Add-on

                                                    This add-on has been installed by default. If it is uninstalled due to some reasons, you can reinstall it by performing the following steps:

                                                    -
                                                    1. Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Add-ons, locate CCE Container Storage (Everest) on the right, and click Install.
                                                    2. On the Install Add-on page, configure the specifications as needed.

                                                      • If you selected Preset, you can choose between Small, Medium, or Large as needed. The system will automatically set the number of add-on pods and resource quotas according to the preset specifications. You can see the configurations on the console.

                                                        The small specification is best for clusters with up to 50 nodes and 500 PVCs. The medium specification works well for clusters with up to 200 nodes and 2000 PVCs. The large specification is perfect for clusters with up to 1000 nodes and 10,000 PVCs.

                                                        +
                                                        1. Log in to the CCE console and click the cluster name to access the cluster console.
                                                        2. In the navigation pane, choose Add-ons. Locate CCE Container Storage (Everest) and click Edit.
                                                        3. On the Install Add-on page, configure the specifications as needed.

                                                          • If you selected Preset, you can choose between Small, Medium, or Large as needed. The system will automatically set the number of add-on pods and resource quotas according to the preset specifications. You can see the configurations on the console.

                                                            The small specification is best for clusters with up to 50 nodes and 500 PVCs. The medium specification works well for clusters with up to 200 nodes and 2000 PVCs. The large specification is perfect for clusters with up to 1000 nodes and 10,000 PVCs.

                                                          • If you selected Custom, you can adjust the number of pods and resource quotas as needed. The requested CPUs and memory can be adjusted based on the number of nodes and PVCs. For details, see Table 1.

                                                            In non-typical scenarios, the formulas for estimating the limits are as follows:

                                                            • everest-csi-controller
                                                              • CPU limit: 250m for 200 or fewer nodes, 350m for 1000 nodes, and 500m for 2000 nodes
                                                              • Memory limit = (200 MiB + Number of nodes x 1 MiB + Number of PVCs x 0.2 MiB) x 1.2
                                                            • everest-csi-driver
                                                              • CPU limit: 300m for 200 or fewer nodes, 500m for 1000 nodes, and 800m for 2000 nodes
                                                              • Memory limit: 300 MiB for 200 or fewer nodes, 600 MiB for 1000 nodes, and 900 MiB for 2000 nodes
                                                            -
                                                            Table 1 Recommended configuration limits in typical scenarios

                                                            Configuration Scenario

                                                            +
                                                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -131,99 +132,108 @@

                                                          • Configure the add-on parameters.

                                                            -

                                                          • Table 1 Recommended configuration limits in typical scenarios

                                                            Configuration Scenario

                                                            everest-csi-controller

                                                            +

                                                            everest-csi-controller

                                                            everest-csi-driver

                                                            +

                                                            everest-csi-driver

                                                            Nodes

                                                            +

                                                            Nodes

                                                            PVs/PVCs

                                                            +

                                                            PVs/PVCs

                                                            Add-on Pods

                                                            +

                                                            Add-on Pods

                                                            CPU Cores (Limit = Request)

                                                            +

                                                            CPU Cores (Limit = Request)

                                                            Memory (Limit = Request)

                                                            +

                                                            Memory (Limit = Request)

                                                            CPU Cores (Limit = Request)

                                                            +

                                                            CPU Cores (Limit = Request)

                                                            Memory (Limit = Request)

                                                            +

                                                            Memory (Limit = Request)

                                                            50

                                                            +

                                                            50

                                                            1000

                                                            +

                                                            1000

                                                            2

                                                            +

                                                            2

                                                            250m

                                                            +

                                                            250m

                                                            600 MiB

                                                            +

                                                            600 MiB

                                                            300m

                                                            +

                                                            300m

                                                            300 MiB

                                                            +

                                                            300 MiB

                                                            200

                                                            +

                                                            200

                                                            1000

                                                            +

                                                            1000

                                                            2

                                                            +

                                                            2

                                                            250m

                                                            +

                                                            250m

                                                            1 GiB

                                                            +

                                                            1 GiB

                                                            300m

                                                            +

                                                            300m

                                                            300 MiB

                                                            +

                                                            300 MiB

                                                            1000

                                                            +

                                                            1000

                                                            1000

                                                            +

                                                            1000

                                                            2

                                                            +

                                                            2

                                                            350m

                                                            +

                                                            350m

                                                            2 GiB

                                                            +

                                                            2 GiB

                                                            500m

                                                            +

                                                            500m

                                                            600 MiB

                                                            +

                                                            600 MiB

                                                            1000

                                                            +

                                                            1000

                                                            5000

                                                            +

                                                            5000

                                                            2

                                                            +

                                                            2

                                                            450m

                                                            +

                                                            450m

                                                            3 GiB

                                                            +

                                                            3 GiB

                                                            500m

                                                            +

                                                            500m

                                                            600 MiB

                                                            +

                                                            600 MiB

                                                            2000

                                                            +

                                                            2000

                                                            5000

                                                            +

                                                            5000

                                                            2

                                                            +

                                                            2

                                                            550m

                                                            +

                                                            550m

                                                            4 GiB

                                                            +

                                                            4 GiB

                                                            800m

                                                            +

                                                            800m

                                                            900 MiB

                                                            +

                                                            900 MiB

                                                            2000

                                                            +

                                                            2000

                                                            10000

                                                            +

                                                            10000

                                                            2

                                                            +

                                                            2

                                                            650m

                                                            +

                                                            650m

                                                            5 GiB

                                                            +

                                                            5 GiB

                                                            800m

                                                            +

                                                            800m

                                                            900 MiB

                                                            +

                                                            900 MiB

                                                            Table 2 Add-on parameters

                                                            Item

                                                            +
                                                            - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + @@ -234,26 +244,26 @@

                                                          • Configure deployment policies for the add-on pods.

                                                            • Scheduling policies do not take effect on add-on pods of the DaemonSet type.
                                                            • When configuring multi-AZ deployment or node affinity, ensure that there are nodes meeting the scheduling policy and that resources are sufficient in the cluster. Otherwise, the add-on cannot run.
                                                            -
                                                          • Table 2 Add-on parameters

                                                            Item

                                                            Configuration Method

                                                            +

                                                            Configuration Method

                                                            Description

                                                            +

                                                            Description

                                                            Reserved EVS Disks for Non-Container Workloads

                                                            +

                                                            Reserved EVS Disks for Non-Container Workloads

                                                            Visualized GUI configuration

                                                            +

                                                            Visualized GUI configuration

                                                            Number of disks on the node reserved for custom use. This parameter is supported when the add-on version is 2.3.11 or later.

                                                            -

                                                            Assume that a maximum of 20 EVS disks can be attached to a node, and the value of this parameter is set to 6. Then 14 (20-6) disks can be attached to this node when the system schedules the EVS disk attachment workloads. The reserved six disks include one system disk and one data disk that have been attached to the node. You can attach four EVS disks to this node as additional data disks or raw disks for a local storage pool.

                                                            +

                                                            Number of disks on the node reserved for custom use. This parameter is supported when the add-on version is 2.3.11 or later.

                                                            +

                                                            Assume that a maximum of 20 EVS disks can be attached to a node, and the value of this parameter is set to 6. Then 14 (20-6) disks can be attached to this node when the system schedules the EVS disk attachment workloads. The reserved six disks include one system disk and one data disk that are already attached to the node. You can attach four EVS disks to this node as additional data disks or raw disks for a local storage pool.

                                                            Prohibit Global Secret from Mounting Object Storage

                                                            +

                                                            Prohibit Global Secret from Mounting Object Storage

                                                            Visualized GUI configuration

                                                            +

                                                            Visualized GUI configuration

                                                            Whether the default AK/SK can be used when an object bucket or parallel file system is mounted.

                                                            +

                                                            Whether the default AK/SK can be used when an object bucket or parallel file system is mounted.

                                                            • is: If you do not specify a custom secret for mounting OBS storage, the global secret you uploaded will be used.
                                                            • No: If you do not specify a custom secret for mounting OBS storage, only the global secret you uploaded can be used. Otherwise, the mounting will fail.

                                                            Concurrent EVS Disk Attaching Tasks

                                                            +

                                                            Concurrent EVS Disk Attaching Tasks

                                                            Visualized GUI configuration

                                                            +

                                                            Visualized GUI configuration

                                                            Number of workers that can be concurrently processed by Everest for attaching EVS volumes. The default value is 60.

                                                            +

                                                            Number of workers that can be concurrently processed by Everest for attaching EVS volumes. The default value is 60.

                                                            Concurrent EVS Disk Detaching Tasks

                                                            +

                                                            Concurrent EVS Disk Detaching Tasks

                                                            Visualized GUI configuration

                                                            +

                                                            Visualized GUI configuration

                                                            Number of workers that can be concurrently processed by Everest for detaching EVS volumes. The default value is 60.

                                                            +

                                                            Number of workers that can be concurrently processed by Everest for detaching EVS volumes. The default value is 60.

                                                            Distributed Volume Mounting

                                                            +

                                                            Distributed Volume Mounting

                                                            Visualized GUI configuration

                                                            +

                                                            Visualized GUI configuration

                                                            When enabled, the everest-csi-driver component on each node is responsible for attaching or detaching EVS disks.

                                                            +

                                                            When enabled, the everest-csi-driver component on each node is responsible for attaching or detaching EVS disks.

                                                            If disabled, the everest-csi-controller component takes on this responsibility.

                                                            flow_control

                                                            +

                                                            flow_control

                                                            Extended Parameter Settings

                                                            +

                                                            Extended parameter settings

                                                            The default configuration is used. After installing the CCE Container Storage (Everest) add-on, you can refer to ConfigMap everest-driver-th-config in the kube-system namespace for more details.

                                                            +

                                                            The default configuration is used. After installing the CCE Container Storage (Everest) add-on, you can refer to ConfigMap everest-driver-th-config in the kube-system namespace for more details.

                                                            over_subscription

                                                            +

                                                            over_subscription

                                                            Extended parameter settings

                                                            +

                                                            Extended parameter settings

                                                            Overcommitment ratio of the local storage pool (local_storage). The default value for the local storage pool size is set to 80. If the pool size is 100 GiB, it can be overcommitted up to 180 GiB. (Total capacity after overcommitment = (1 + Overcommitment ratio) x Actual capacity)

                                                            +

                                                            Overcommitment ratio of the local storage pool (local_storage). The default value for the local storage pool size is set to 80. If the pool size is 100 GiB, it can be overcommitted up to 180 GiB. (Total capacity after overcommitment = (1 + Overcommitment ratio) x Actual capacity)

                                                            enable_local_autoexpander

                                                            +

                                                            enable_local_autoexpander

                                                            Extended parameter settings

                                                            +

                                                            Extended parameter settings

                                                            Whether to enable automatic scale-out for the local storage pool of thin volumes. If this function is enabled, automatic scale-out is triggered based on the scale-out threshold and scale-out step of the local storage pool.

                                                            +

                                                            Whether to enable automatic scale-out for the local storage pool of thin volumes. If this function is enabled, automatic scale-out is triggered based on the scale-out threshold and scale-out step of the local storage pool.

                                                            expansion_threshold

                                                            +

                                                            expansion_threshold

                                                            Extended parameter settings

                                                            +

                                                            Extended parameter settings

                                                            Capacity expansion threshold of the local storage pool of the thin volume. When the usage of the local storage pool of the thin volume exceeds the threshold, the local storage pool is automatically expanded.

                                                            +

                                                            Capacity expansion threshold of the local storage pool of the thin volume. When the usage of the local storage pool of the thin volume exceeds the threshold, the local storage pool is automatically expanded.

                                                            expansion_step

                                                            +

                                                            expansion_step

                                                            Extended parameter settings

                                                            +

                                                            Extended parameter settings

                                                            Capacity expansion step of a single EVS disk in the local storage pool of thin provisioning volumes (unit: Gi)

                                                            +

                                                            Capacity expansion step of a single EVS disk in the local storage pool of thin provisioning volumes (unit: Gi)

                                                            expansion_max_evs_size

                                                            +

                                                            expansion_max_evs_size

                                                            Extended parameter settings

                                                            +

                                                            Extended parameter settings

                                                            Maximum capacity of a single EVS disk in the local storage pool of thin provisioning volumes (unit: Gi)

                                                            +

                                                            Maximum capacity of a single EVS disk in the local storage pool of thin provisioning volumes (unit: Gi)

                                                            volume_attaching_flow_ctrl

                                                            +

                                                            volume_attaching_flow_ctrl

                                                            Extended parameter settings

                                                            +

                                                            Extended parameter settings

                                                            Maximum number of EVS volumes that can be attached by the Everest add-on within 1 minute. The default value is 0, indicating that the performance of attaching EVS volumes is determined by the underlying storage resources.

                                                            +

                                                            Maximum number of EVS volumes that can be attached by the Everest add-on within 1 minute. The default value is 0, indicating that the performance of attaching EVS volumes is determined by the underlying storage resources.

                                                            +

                                                            enable_aksk_refresh

                                                            +

                                                            Extended parameter settings

                                                            +

                                                            Whether to enable the function of dynamically updating custom access keys (AK/SK) using parallel file systems. This parameter is supported when the add-on version is 2.4.150 or later. For details, see Automatically Applying Updated Access Keys (AK/SK) for an OBS Volume. The default value is false, indicating that the function is disabled. The value true indicates that the function is enabled.

                                                            +

                                                            Whether to enable the function of dynamically updating custom access keys (AK/SK) using object storage. This parameter is supported when the add-on version is 2.4.150 or later. For details, see Automatically Applying Updated Access Keys (AK/SK) for an OBS Volume. The default value is false, indicating that the function is disabled. The value true indicates that the function is enabled.

                                                            +

                                                            If the add-on version is between 2.4.150 (inclusive) and 2.4.165 (exclusive), only parallel file systems are supported. Starting from version 2.4.165 and onward, both parallel file systems and OBS buckets are supported.

                                                            Table 3 Configurations for add-on scheduling

                                                            Parameter

                                                            +
                                                            - - - - - - - @@ -312,8 +322,8 @@ - @@ -324,7 +334,7 @@ - @@ -335,7 +345,7 @@ - @@ -346,7 +356,7 @@ - @@ -401,8 +411,8 @@
                                                            Table 3 Configurations for add-on scheduling

                                                            Parameter

                                                            Description

                                                            +

                                                            Description

                                                            Multi-AZ Deployment

                                                            +

                                                            Multi-AZ Deployment

                                                            • Preferred: Deployment pods of the add-on will be preferentially scheduled to nodes in different AZs. If all the nodes in the cluster are deployed in the same AZ, the pods will be scheduled to different nodes in that AZ.
                                                            • Equivalent mode: Deployment pods of the add-on are evenly scheduled to the nodes in the cluster in each AZ. If a new AZ is added, you are advised to increase add-on pods for cross-AZ HA deployment. With the Equivalent multi-AZ deployment, the difference between the number of add-on pods in different AZs will be less than or equal to 1. If resources in one of the AZs are insufficient, pods cannot be scheduled to that AZ.
                                                            • Forcible: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. There can be at most one pod in each AZ. If nodes in a cluster are not in different AZs, some add-on pods cannot run properly. If a node is faulty, add-on pods on it may fail to be migrated.
                                                            +
                                                            • Preferred: Deployment pods of the add-on will be preferentially scheduled to nodes in different AZs. If all the nodes in the cluster are deployed in the same AZ, the pods will be scheduled to different nodes in that AZ.
                                                            • Equivalent mode: Deployment pods of the add-on are evenly scheduled to the nodes in the cluster in each AZ. If a new AZ is added, you are advised to increase add-on pods for cross-AZ HA deployment. With the Equivalent multi-AZ deployment, the difference between the number of add-on pods in different AZs will be less than or equal to 1. If resources in one of the AZs are insufficient, pods cannot be scheduled to that AZ.
                                                            • Forcible: Deployment pods of the add-on are forcibly scheduled to nodes in different AZs. There can be at most one pod in each AZ. If nodes in a cluster are not in different AZs, some add-on pods cannot run properly. If a node is faulty, add-on pods on it may fail to be migrated.

                                                            Node Affinity

                                                            +

                                                            Node Affinity

                                                            • Not configured: Node affinity is disabled for the add-on.
                                                            • Specify node: Specify the nodes where the add-on is deployed. If you do not specify the nodes, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                                            • Specify node pool: Specify the node pool where the add-on is deployed. If you do not specify the node pools, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                                            • Customize affinity: Enter the labels of the nodes where the add-on is to be deployed for more flexible scheduling policies. If you do not specify node labels, the add-on will be randomly scheduled based on the default cluster scheduling policy.

                                                              If multiple custom affinity policies are configured, ensure that there are nodes that meet all the affinity policies in the cluster. Otherwise, the add-on cannot run.

                                                              +
                                                            • Not configured: Node affinity is disabled for the add-on.
                                                            • Specify node: Specify the nodes where the add-on is deployed. If you do not specify the nodes, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                                            • Specify node pool: Specify the node pool where the add-on is deployed. If you do not specify the node pools, the add-on will be randomly scheduled based on the default cluster scheduling policy.
                                                            • Customize affinity: Enter the labels of the nodes where the add-on is to be deployed for more flexible scheduling policies. If you do not specify node labels, the add-on will be randomly scheduled based on the default cluster scheduling policy.

                                                              If multiple custom affinity policies are configured, ensure that there are nodes that meet all the affinity policies in the cluster. Otherwise, the add-on cannot run.

                                                            Toleration

                                                            +

                                                            Toleration

                                                            Using both taints and tolerations allows (not forcibly) the add-on Deployment to be scheduled to a node with the matching taints, and controls the Deployment eviction policies after the node where the Deployment is located is tainted.

                                                            +

                                                            Using both taints and tolerations allows (not forcibly) the add-on Deployment to be scheduled to a node with the matching taints, and controls the Deployment eviction policies after the node where the Deployment is located is tainted.

                                                            The add-on adds the default tolerance policy for the node.kubernetes.io/not-ready and node.kubernetes.io/unreachable taints, respectively. The tolerance time window is 60s.

                                                            For details, see Configuring Tolerance Policies.

                                                            Invoking of different functions

                                                            action: indicates different functions. For details, see Table 6.

                                                            -

                                                            result: indicates that the invoking is successful or fails.

                                                            +

                                                            action: indicates different functions. For details, see Table 6.

                                                            +

                                                            result: indicates that the invoking is successful or fails.

                                                            everest_action_result_total{action="create_snapshot:disk.csi.everest.io",result="success"} 2

                                                            Number of times that different functions are executed at different time

                                                            function: indicates different functions. For details, see Table 6.

                                                            +

                                                            function: indicates different functions. For details, see Table 6.

                                                            everest_function_duration_seconds_bucket{function="create_snapshot:disk.csi.everest.io",le="10"} 2

                                                            Total invoking time of different functions

                                                            function: indicates different functions. For details, see Table 6.

                                                            +

                                                            function: indicates different functions. For details, see Table 6.

                                                            everest_function_duration_seconds_sum{function="create:disk.csi.everest.io"} 24.381399053

                                                            Number of invoking times of different functions

                                                            function: indicates different functions. For details, see Table 6.

                                                            +

                                                            function: indicates different functions. For details, see Table 6.

                                                            everest_function_duration_seconds_count{function="attach:disk.csi.everest.io"} 4

                                                            -

                                                            Change History

                                                            -
                                                            Table 7 Release history

                                                            Add-on Version

                                                            +

                                                            Release History

                                                            +
                                                            @@ -410,7 +420,20 @@ - + + + + - - - - - - diff --git a/docs/cce/umn/cce_10_0068.html b/docs/cce/umn/cce_10_0068.html index 7ec7e0bae..7ee927308 100644 --- a/docs/cce/umn/cce_10_0068.html +++ b/docs/cce/umn/cce_10_0068.html @@ -4,6 +4,8 @@

                                                            Description of DefaultPool

                                                            DefaultPool is not a real node pool. It only classifies nodes that are not in the custom node pools. These nodes are directly created on the console or by calling APIs. DefaultPool does not support any user-created node pool functions, including scaling and parameter configuration. DefaultPool cannot be edited, deleted, expanded, or auto scaled, and nodes in it cannot be migrated.

                                                            -

                                                            Applicable Scenarios

                                                            When a large-scale cluster is required, you are advised to use node pools to manage nodes.

                                                            +

                                                            Application Scenarios

                                                            When a large-scale cluster is required, you are advised to use node pools to manage nodes.

                                                            The following table describes multiple scenarios of large-scale cluster management and the functions of node pools in each scenario.

                                                            Table 7 CCE Container Storage (Everest) add-on

                                                            Add-on Version

                                                            Supported Cluster Version

                                                            2.4.134

                                                            +

                                                            2.4.161

                                                            +

                                                            v1.25

                                                            +

                                                            v1.27

                                                            +

                                                            v1.28

                                                            +

                                                            v1.29

                                                            +

                                                            v1.30

                                                            +

                                                            v1.31

                                                            +

                                                            v1.32

                                                            +

                                                            CCE clusters v1.32 are supported.

                                                            +

                                                            2.4.134

                                                            v1.25

                                                            v1.27

                                                            @@ -431,7 +454,7 @@

                                                            v1.29

                                                            v1.30

                                                            On HCE OS 2.0 nodes, you can configure the EVS PVC's fstype to xfs.

                                                            +

                                                            On HCE OS 2.0 nodes, you can configure the EVS PVC's fstype to xfs.

                                                            2.4.28

                                                            @@ -486,7 +509,7 @@

                                                            v1.25

                                                            v1.27

                                                            Supported HCE OS 2.0.

                                                            +

                                                            Supported HCE OS 2.0.

                                                            2.1.30

                                                            @@ -496,7 +519,7 @@

                                                            v1.23

                                                            v1.25

                                                            • Supported anti-affinity scheduling of add-on pods on nodes in different AZs.
                                                            • Adapts the obsfs package to Ubuntu 22.04.
                                                            +
                                                            • Supported anti-affinity scheduling of add-on pods on nodes in different AZs.
                                                            • Adapted the obsfs package to Ubuntu 22.04.

                                                            2.1.13

                                                            @@ -506,7 +529,7 @@

                                                            v1.23

                                                            v1.25

                                                            Optimized the performance of creating subpath PVCs in batches for SFS Turbo volumes.

                                                            +

                                                            Optimized the performance of creating subPath PVCs in batches for SFS Turbo volumes.

                                                            1.3.28

                                                            @@ -535,7 +558,7 @@

                                                            v1.19

                                                            v1.21

                                                            Optimized the performance of creating subpath PVCs in batches for SFS Turbo volumes.

                                                            +

                                                            Optimized the performance of creating subPath PVCs in batches for SFS Turbo volumes.

                                                            1.2.44

                                                            @@ -572,7 +595,7 @@

                                                            v1.15

                                                            v1.17

                                                            • Supported security hardening.
                                                            • Supported third-party OBS storage.
                                                            • Switched to the EVS query API with better performance.
                                                            • Used snapshots to create disks in clone mode by default.
                                                            • Optimized and enhanced disk status detection and log output for attaching and detaching operations.
                                                            • Improved the reliability of determining authentication expiration.
                                                            +
                                                            • Supported security hardening.
                                                            • Supported third-party OBS storage.
                                                            • Switched to the EVS query API with better performance.
                                                            • Disks can be created from snapshots using clone by default.
                                                            • Optimized and enhanced disk status detection and log output for attaching and detaching operations.
                                                            • Improved the reliability of determining authentication expiration.
                                                            Table 1 Using node pools for different management scenarios

                                                            Scenario

                                                            @@ -122,8 +122,8 @@

                                                            For example, you can use container's resource request as a nodeSelector so that workloads will run only on the nodes that meet the resource request.

                                                            If the workload definition file defines a container that requires four CPUs, the scheduler will not choose the nodes with two CPUs to run workloads.

                                                            -

                                                            Related Operations

                                                            You can log in to the CCE console and refer to the following sections to perform operations on node pools:

                                                            - +

                                                            Helpful Links

                                                            You can log in to the CCE console and refer to the following sections to perform operations on node pools:

                                                            +
                                                            diff --git a/docs/cce/umn/cce_10_0083.html b/docs/cce/umn/cce_10_0083.html index 91e679ea9..78dbddaa7 100644 --- a/docs/cce/umn/cce_10_0083.html +++ b/docs/cce/umn/cce_10_0083.html @@ -4,24 +4,24 @@

                                                            Scenario

                                                            After a workload scaling policy is created, you can update and delete the policy, as well as edit the YAML file.

                                                            Procedure

                                                            You can view the rules, latest status, and events of a workload scaling policy and handle exceptions based on the error information displayed.

                                                            -
                                                            1. Log in to the CCE console and click the cluster name to access the cluster console.
                                                            2. In the navigation pane, choose Policies. On the Scaling Policies tab page, click the HPA Policies/CronHPA Policies tab based on the scaling policy type.
                                                            3. Check the latest status, rules, and associated workloads of a scaling policy.

                                                              You can also check a created scaling policy on the workload details page.

                                                              -
                                                              1. Log in to the CCE console and click the cluster name to 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, switch to the Auto Scaling tab page to obtain the scaling policies. You can also obtain the scaling policies you configured on the Policies page.
                                                              +
                                                              1. Log in to the CCE console and click the cluster name to access the cluster console.
                                                              2. In the navigation pane, choose Policies. On the Scaling Policies tab, click the HPA Policies/CronHPA Policies tab based on the scaling policy type.
                                                              3. Check the latest status, rules, and associated workloads of a scaling policy.

                                                                You can also check a created scaling policy on the workload details page.

                                                                +
                                                                1. Log in to the CCE console and click the cluster name to 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, switch to the Auto Scaling tab to obtain the scaling policies. You can also obtain the scaling policies you configured on the Policies page.

                                                              4. Manage scaling policies.

                                                                -

                                                                Scaling Policy Type

                                                                +
                                                                - - - - - @@ -32,7 +32,7 @@
                                                                diff --git a/docs/cce/umn/cce_10_0084.html b/docs/cce/umn/cce_10_0084.html index 9f133d33d..f92ced2fb 100644 --- a/docs/cce/umn/cce_10_0084.html +++ b/docs/cce/umn/cce_10_0084.html @@ -3,7 +3,7 @@

                                                                Enabling ICMP Security Group Rules

                                                                Scenario

                                                                If a workload uses UDP for both load balancing and health check, enable ICMP security group rules for the backend servers.

                                                                -

                                                                Procedure

                                                                1. Log in to the CCE console and choose Networking > Virtual Private Cloud in the service list. In the navigation pane, choose Access Control > Security Groups.
                                                                2. In the security group list, locate the security group of the cluster. Click the Inbound Rules tab page and then Add Rule. In the Add Inbound Rule dialog box, configure inbound parameters.

                                                                  +

                                                                  Procedure

                                                                  1. Log in to the VPC console and choose Access Control > Security Groups.
                                                                  2. In the security group list, locate the security group of the cluster. Click the Inbound Rules tab page and then Add Rule. In the Add Inbound Rule dialog box, configure inbound parameters.

                                                                Scaling Policy Type

                                                                Operation

                                                                +

                                                                Operation

                                                                HPA

                                                                +

                                                                HPA

                                                                • View Events: Check HPA policy events. If an error occurred, locate and rectify the fault based on the error message displayed on the page.
                                                                • Edit YAML: In the dialog box displayed, edit, copy, or download the YAML file.
                                                                • Edit: On the Edit HPA Policy page, configure policy parameters listed in Table 1.
                                                                • Clone: Duplicate an existing auto scaling policy and modify the parameter settings as required.
                                                                • Delete: In the dialog box displayed, click Yes.
                                                                +
                                                                • View Events: Check HPA policy events. If an error occurred, locate and rectify the fault based on the error message displayed on the page.
                                                                • Edit YAML: In the dialog box displayed, edit, copy, or download the YAML file.
                                                                • Edit: On the Edit HPA Policy page, configure policy parameters listed in Table 1.
                                                                • Clone: Duplicate an existing auto scaling policy and modify the parameter settings as required.
                                                                • Delete: In the dialog box displayed, click Yes.

                                                                CronHPA

                                                                +

                                                                CronHPA

                                                                • View YAML: In the dialog box displayed, copy or download the YAML file but you are not allowed to modify it.
                                                                • Delete: In the dialog box displayed, click Yes.
                                                                +
                                                                • View YAML: In the dialog box displayed, copy or download the YAML file but you are not allowed to modify it.
                                                                • Delete: In the dialog box displayed, click Yes.

                                                                Cluster Type

                                                                ELB Type

                                                                diff --git a/docs/cce/umn/cce_10_0091.html b/docs/cce/umn/cce_10_0091.html index eaeea38d6..76660cbee 100644 --- a/docs/cce/umn/cce_10_0091.html +++ b/docs/cce/umn/cce_10_0091.html @@ -10,9 +10,9 @@ - - diff --git a/docs/cce/umn/cce_10_0094.html b/docs/cce/umn/cce_10_0094.html index 81c2a04ac..9424cba94 100644 --- a/docs/cce/umn/cce_10_0094.html +++ b/docs/cce/umn/cce_10_0094.html @@ -1,9 +1,9 @@ -

                                                                Overview

                                                                +

                                                                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, 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

                                                                Ingress Overview

                                                                Kubernetes uses ingress resources to define how incoming traffic should be handled, while the Ingress Controller is responsible for processing the actual traffic.

                                                                • Ingress object: a set of access rules that forward requests to specified Services based on domain names or paths. It can be added, deleted, modified, and queried by calling APIs.
                                                                • Ingress Controller: an executor for forwarding requests. 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 target backend Services.
                                                                  The way of implementing Ingress Controllers varies depending on their vendors. CCE supports LoadBalancer Ingress Controllers and NGINX Ingress Controllers.
                                                                  • LoadBalancer Ingress Controllers are deployed on master nodes and forward traffic based on the ELB. All policy configurations and forwarding behaviors are managed on the ELB.
                                                                  • NGINX Ingress Controllers are deployed in clusters using charts and images maintained by the Kubernetes community. They provide external access through NodePort and forward external traffic to other services in the cluster through Nginx. All traffic forwarding behaviors and forwarding objects are within the cluster.
                                                                  @@ -83,19 +83,19 @@

                                                                  LoadBalancer Ingress Controllers are deployed on master nodes and bound to load balancers in the cluster's VPC. You can configure different domain names, ports, and forwarding policies for the same load balancer (with the same IP address). The working rules of LoadBalancer Ingress Controllers are as follows:

                                                                  1. A user creates an ingress and configures a traffic access rule in the ingress, including the load balancer, access path, SSL, and backend Service port.
                                                                  2. When Ingress Controller detects that the ingress changes, it reconfigures the listener and backend server route on the ELB according to the traffic access rule.
                                                                  3. When a user attempts to access a workload, the ELB forwards the traffic to the target workload according to the configured forwarding rule.
                                                                  -

                                                                  CCE Standard Clusters

                                                                  Figure 2 Working flow of a LoadBalancer ingress in a CCE standard cluster
                                                                  +

                                                                  CCE Standard Clusters

                                                                  Figure 2 Working flow of a LoadBalancer ingress in a CCE standard cluster
                                                                  -

                                                                  CCE Turbo Clusters Where a Shared Load Balancer Is Used

                                                                  Figure 3 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a shared load balancer is used
                                                                  +

                                                                  CCE Turbo Clusters Where a Shared Load Balancer Is Used

                                                                  Figure 3 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a shared load balancer is used

                                                                  CCE Turbo Clusters Where a Dedicated Load Balancer Is Used

                                                                  When a CCE Turbo cluster is used, pod IP addresses are directly allocated from the VPC. Dedicated load balancers enable passthrough networking to pods. When creating an ingress for external cluster access, you can use ELB to access a ClusterIP Service and use pods as the backend server of the ELB listener. In this way, external traffic can directly access the pods in the cluster without being forwarded by node ports.

                                                                  -
                                                                  Figure 4 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a dedicated load balancer is used
                                                                  +
                                                                  Figure 4 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a dedicated load balancer is used

                                                                  Working Rules of NGINX Ingress Controller

                                                                  Nginx Ingress uses ELB as the traffic ingress. The NGINX Ingress Controller add-on is deployed in a cluster to balance traffic and control access.

                                                                  NGINX Ingress Controller uses the charts and images provided by the open-source community, and issues may occur during usage. CCE periodically synchronizes the community version to fix known vulnerabilities. Check whether your service requirements can be met.

                                                                  NGINX Ingress Controller is deployed on worker nodes through pods, which will result in O&M costs and Nginx component running overheads. Figure 5 shows the working rules of NGINX Ingress Controller.

                                                                  1. After you update ingress resources, NGINX Ingress Controller writes a forwarding rule defined in the ingress resources into the nginx.conf configuration file of Nginx.
                                                                  2. The built-in Nginx component reloads the updated configuration file to modify and update the Nginx forwarding rule.
                                                                  3. When traffic accesses a cluster, the traffic is first forwarded by the created load balancer to the Nginx component in the cluster. Then, the Nginx component forwards the traffic to each workload based on the forwarding rule.
                                                                  -
                                                                  Figure 5 Working rules of NGINX Ingress Controller
                                                                  +
                                                                  Figure 5 Working rules of NGINX Ingress Controller

                                                                  Services Supported by LoadBalancer Ingresses

                                                                  - diff --git a/docs/cce/umn/cce_10_0105.html b/docs/cce/umn/cce_10_0105.html index 903565d12..8620f2b72 100644 --- a/docs/cce/umn/cce_10_0105.html +++ b/docs/cce/umn/cce_10_0105.html @@ -1,160 +1,227 @@ -

                                                                  Configuring Container Lifecycle Parameters

                                                                  -

                                                                  Scenario

                                                                  CCE provides callback functions for the lifecycle management of containerized applications. For example, if you want a container to perform a certain operation before stopping, you can register a hook function.

                                                                  -

                                                                  CCE provides the following lifecycle callback functions:

                                                                  -
                                                                  • Startup Command: executed to start a container. For details, see Startup Commands.
                                                                  • Post-Start: executed immediately after a container is started. For details, see Post-Start Processing.
                                                                  • Pre-Stop: executed before a container is stopped. The pre-stop processing function helps you ensure that the services running on the pods can be completed in advance in the case of pod upgrade or deletion. For details, see Pre-Stop Processing.
                                                                  -
                                                                  -

                                                                  Startup Commands

                                                                  By default, the default command is executed during image start. To run a specific command or rewrite the default image setting, you must perform specific operations.

                                                                  -

                                                                  A Docker image has metadata that stores image information. If lifecycle commands and arguments are not set, CCE runs the default commands and arguments, that is, Docker instructions ENTRYPOINT and CMD, provided during image creation.

                                                                  -

                                                                  If the commands and arguments used to run a container are set during application creation, the default commands ENTRYPOINT and CMD are overwritten during image build. The rules are as follows:

                                                                  +

                                                                  Configuring the Container Lifecycle

                                                                  +

                                                                  Container lifecycle hooks are core mechanisms provided by Kubernetes that enable you to insert custom logic at key phases throughout the container lifecycle. These hooks provide refined process controls over containerized applications, enabling applications to better adapt to the dynamic characteristics of the cloud native environment. CCE provides the following container lifecycle hooks. For more information, see Container Lifecycle Hooks.

                                                                  +
                                                                  • Startup Command: the command executed when a container starts. It is used to define the main process of a container. The main process is the default entry after the container starts, and its status determines the container lifecycle. This kind of hook is applicable to initialization scenarios where the application entry, environment variables, mount points, or port mapping needs to be specified.
                                                                  • PostStart Hook: used to execute initialization tasks, such as service registration and dynamic configuration generation, immediately after the main process of a container starts. Such a hook is asynchronously triggered by kubelet and runs in parallel with the main process, preventing the container startup process from being blocked and accelerating the container readiness. This kind of hook is applicable to the scenario where the environment needs to be configured or the initialization logic needs to be executed immediately after the application process starts.
                                                                  • PreStop Hook: used to execute predefined cleanup logic before a container is terminated. When a pod is deleted or updated, kubelet triggers this hook to perform operations (such as deregistering services and refreshing status), and then sends the SIGTERM signal to the main process of a container for the application to shut down gracefully. This kind of hook is applicable to the scenario where safe shutdown is required to avoid data loss or there are service exceptions.
                                                                  +

                                                                  Startup Command

                                                                  A startup command is executed when a container starts. It is used to define the main process of a container. The main process status determines the container lifecycle. If the command fails to be executed and no restart policy is configured, the container will be terminated.

                                                                  +

                                                                  By default, the default command is executed during image start. To run a specific command or rewrite the default image setting, you must perform specific operations. By default, the container executes the startup command preset in the image. Docker images contain a set of metadata fields for defining the startup behavior, including ENTRYPOINT and CMD. If the commands and arguments (specified by Command and Args) are not configured in the container specifications, the default values during image build are used.

                                                                  +

                                                                  If the commands and arguments used to run a container are configured during workload creation, the default commands ENTRYPOINT and CMD are overwritten during image build. The rules are as follows:

                                                                  -
                                                                  Table 2 Services supported by LoadBalancer ingresses

                                                                  Cluster Type

                                                                  @@ -137,9 +137,7 @@

                                                                  Supported

                                                                  Not supported

                                                                  -
                                                                  NOTE:

                                                                  ENIs are separately bound to pods in a CCE Turbo cluster, and ELB directly connects to pods. Therefore, NodePort access is not available.

                                                                  -
                                                                  +

                                                                  Supported

                                                                  Table 1 Commands and arguments used to run a container

                                                                  Image ENTRYPOINT

                                                                  +
                                                                  - - - - - - - - - - - - - - - - - - - - - - - -
                                                                  Table 1 Commands and arguments used to run a container

                                                                  Image ENTRYPOINT

                                                                  Image CMD

                                                                  +

                                                                  Image CMD

                                                                  Command to Run a Container

                                                                  +

                                                                  Command to Run a Container

                                                                  Parameters to Run a Container

                                                                  +

                                                                  Argument to Run a Container

                                                                  Command Executed

                                                                  +

                                                                  Command Executed

                                                                  [touch]

                                                                  +

                                                                  [touch]

                                                                  [/root/test]

                                                                  +

                                                                  [/root/test]

                                                                  Not set

                                                                  +

                                                                  Not set

                                                                  Not set

                                                                  +

                                                                  Not set

                                                                  [touch /root/test]

                                                                  +

                                                                  [touch /root/test]

                                                                  [touch]

                                                                  +

                                                                  [touch]

                                                                  [/root/test]

                                                                  +

                                                                  [/root/test]

                                                                  [mkdir]

                                                                  +

                                                                  [mkdir]

                                                                  Not set

                                                                  +

                                                                  Not set

                                                                  [mkdir]

                                                                  +

                                                                  [mkdir]

                                                                  [touch]

                                                                  +

                                                                  [touch]

                                                                  [/root/test]

                                                                  +

                                                                  [/root/test]

                                                                  Not set

                                                                  +

                                                                  Not set

                                                                  [/opt/test]

                                                                  +

                                                                  [/opt/test]

                                                                  [touch /opt/test]

                                                                  +

                                                                  [touch /opt/test]

                                                                  [touch]

                                                                  +

                                                                  [touch]

                                                                  [/root/test]

                                                                  +

                                                                  [/root/test]

                                                                  [mkdir]

                                                                  +

                                                                  [mkdir]

                                                                  [/opt/test]

                                                                  +

                                                                  [/opt/test]

                                                                  [mkdir /opt/test]

                                                                  +

                                                                  [mkdir /opt/test]

                                                                  -
                                                                  1. Log in to the CCE console. When creating a workload, configure container information and select Lifecycle.
                                                                  2. Enter a command and arguments on the Startup Command tab page.

                                                                    -

                                                                    Table 2 Container startup command

                                                                    Configuration Item

                                                                    +
                                                                    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 Create Workload in the upper right corner.
                                                                    3. In Container Settings, choose Container Information > Lifecycle > Startup Command and enter the command and arguments.

                                                                      + +
                                                                      - + + - - + - - - + + +
                                                                      Table 2 Container startup command

                                                                      Parameter

                                                                      Procedure

                                                                      +

                                                                      Example Value

                                                                      +

                                                                      Description

                                                                      +

                                                                      Example YAML

                                                                      Command

                                                                      +

                                                                      Command

                                                                      Enter an executable command, for example, /run/server.

                                                                      -

                                                                      If there are multiple executable commands, write them in different lines.

                                                                      +

                                                                      /run/server

                                                                      +

                                                                      Enter one or more executable commands. If you need multiple commands, separate them on different lines.

                                                                      NOTE:

                                                                      In the case of multiple commands, you are advised to run /bin/sh or other shell commands. Other commands are used as parameters.

                                                                      Args

                                                                      +
                                                                      ...
                                                                      +spec:
                                                                      +  containers:
                                                                      +  - image: nginx:latest 
                                                                      +    command:
                                                                      +      - /run/server
                                                                      +     args:
                                                                      +       - '--port=8080' 
                                                                      +...

                                                                      Enter the argument that controls the container running command, for example, --port=8080.

                                                                      -

                                                                      If there are multiple arguments, separate them in different lines.

                                                                      +

                                                                      Args

                                                                      +

                                                                      --port=8080

                                                                      +

                                                                      Enter one or more arguments. If you need multiple arguments, separate them on different lines.

                                                                      -

                                                                    +

                                                                  3. Configure other parameters and click Create Workload in the lower right corner. If the workload is in the Running state, the startup command is successfully executed.
                                                                  4. -

                                                                    Post-Start Processing

                                                                    1. Log in to the CCE console. When creating a workload, configure container information and select Lifecycle.
                                                                    2. Set the post-start processing parameters on the Post-Start tab page.

                                                                      -

                                                                      Table 3 Post-start processing parameters

                                                                      Parameter

                                                                      +

                                                                      PostStart Hook

                                                                      A PostStart hook, a container lifecycle hook provided by Kubernetes, is used to execute initialization tasks, such as service registration and dynamic configuration generation, immediately after the main process of a container starts. This hook is asynchronously triggered by kubelet and runs in parallel with the main process. Although the PostStart hook is executed asynchronously with the main process of the container, if the PostStart hook takes too long or is suspended, the container may not change to the Running state. If the PostStart hook fails to be executed, the container may fail to start and be terminated.

                                                                      +
                                                                      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 Create Workload in the upper right corner.
                                                                      3. In Container Settings, choose Container Information > Lifecycle > Post-Start and configure parameters. based on the service requirements. For example:

                                                                        • If initialization logic (such as running scripts and configuring the environment) needs to be executed in the container, select CLI.
                                                                        • If external systems or services needs to be notified (for example, when service registration is needed and a configuration center API is called), select HTTP request.
                                                                        +

                                                                        + +
                                                                        - + + - - + + - - + +
                                                                        Table 3 Post-start processing

                                                                        Processing Method

                                                                        Description

                                                                        +

                                                                        Example Value

                                                                        +

                                                                        Description

                                                                        +

                                                                        Example YAML

                                                                        CLI

                                                                        +

                                                                        CLI

                                                                        Set commands to be executed in the container for post-start processing. The command format is Command Args[1] Args[2].... Command is a system command or a user-defined executable program. If no path is specified, an executable program in the default path will be selected. If multiple commands need to be executed, write the commands into a script for execution. Commands that are executed in the background or asynchronously are not supported.

                                                                        -

                                                                        Example command:

                                                                        -
                                                                        exec: 
                                                                        -  command: 
                                                                        -  - /install.sh 
                                                                        -  - install_agent
                                                                        -

                                                                        Enter /install install_agent in the script. This command indicates that install.sh will be executed after the container is created successfully.

                                                                        +

                                                                        /install.sh

                                                                        +

                                                                        install_agent

                                                                        +

                                                                        Used for running the commands in the container. You need to configure Command.

                                                                        +

                                                                        The command format is Command Arg[1] Arg[2]..., where Command indicates a system command or a user-defined executable program. If no path is specified, the system searches for the command in the default path. If multiple commands needed to be executed, write them into a script in the container image in advance and invoke the script using this command. The executable command must be executed synchronously or in the frontend. If it is executed asynchronously or in the backend, the lifecycle hook may fail to be executed.

                                                                        +
                                                                        ...
                                                                        +lifecycle:
                                                                        +  postStart:
                                                                        +    exec:
                                                                        +      command:
                                                                        +      - /install.sh
                                                                        +      - install_agent   
                                                                        +...

                                                                        HTTP request

                                                                        +

                                                                        HTTP request

                                                                        Send an HTTP request for post-start processing. The related parameters are described as follows:

                                                                        -
                                                                        • Path: (optional) request URL.
                                                                        • Port: (mandatory) request port.
                                                                        • Host: (optional) requested host IP address. The default value is the IP address of the pod.
                                                                        +

                                                                        Path: /nginx

                                                                        +

                                                                        Port: 80

                                                                        +

                                                                        Host: 127.0.0.1

                                                                        +

                                                                        Used for initiating an HTTP request. The related parameters are described as follows:

                                                                        +
                                                                        • Path: (optional) request URL.
                                                                        • Port: (mandatory) requested port.
                                                                        • Host: (optional) requested host IP address. The default value is the IP address of the pod.
                                                                        +
                                                                        lifecycle:
                                                                        +  postStart:
                                                                        +    httpGet:
                                                                        +      path: /nginx
                                                                        +      port: 80
                                                                        +      host: 127.0.0.1
                                                                        +      scheme: HTTP
                                                                        +...
                                                                        -

                                                                      +

                                                                    3. Configure other parameters and click Create Workload in the lower right corner. After a period of time, the workload status changes to Running.
                                                                    4. -

                                                                      Pre-Stop Processing

                                                                      1. Log in to the CCE console. When creating a workload, configure container information and select Lifecycle.
                                                                      2. Set the pre-start processing parameters on the Pre-Stop tab page.

                                                                        -

                                                                        Table 4 Pre-stop processing parameters

                                                                        Parameter

                                                                        +

                                                                        PreStop Hook

                                                                        If a container crashes or exits abnormally, the PreStop hook will not be triggered. The pod's termination grace period starts to count down before the PreStop hook is executed. Regardless of the outcome of the hook handler, the container will be terminated within the pod's termination grace period unless the finalizer delays the termination process. Other management operations on the container are blocked until the PreStop hook is complete or the termination grace period is reached.

                                                                        +
                                                                        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 Create Workload in the upper right corner.
                                                                        3. In Container Settings, choose Container Information > Lifecycle > Pre-Stop and configure parameters.

                                                                          + +
                                                                          - + + - - + + - - + +
                                                                          Table 4 Pre-stop processing parameters

                                                                          Parameter

                                                                          Description

                                                                          +

                                                                          Example Value

                                                                          +

                                                                          Description

                                                                          +

                                                                          Example YAML

                                                                          CLI

                                                                          +

                                                                          CLI

                                                                          Set commands to be executed in the container for pre-stop processing. The command format is Command Args[1] Args[2].... Command is a system command or a user-defined executable program. If no path is specified, an executable program in the default path will be selected. If multiple commands need to be executed, write the commands into a script for execution.

                                                                          -

                                                                          Example command:

                                                                          -
                                                                          exec: 
                                                                          -  command: 
                                                                          -  - /uninstall.sh 
                                                                          -  - uninstall_agent
                                                                          -

                                                                          Enter /uninstall uninstall_agent in the script. This command indicates that uninstall.sh will be executed before the container completes its execution and stops running.

                                                                          +

                                                                          /uninstall.sh

                                                                          +

                                                                          uninstall_agent

                                                                          +

                                                                          Used for running the commands in the container. You need to configure Command.

                                                                          +

                                                                          The command format is Command Arg[1] Arg[2]..., where Command indicates a system command or a user-defined executable program. If no path is specified, the system searches for the command in the default path. If multiple commands needed to be executed, write them into a script in the container image in advance and invoke the script using this command.

                                                                          +
                                                                          ...
                                                                          +lifecycle:
                                                                          +  preStop:
                                                                          +    exec:
                                                                          +      command:
                                                                          +      - /uninstall.sh
                                                                          +      - uninstall_agent   
                                                                          +...

                                                                          HTTP request

                                                                          +

                                                                          HTTP request

                                                                          Send an HTTP request for pre-stop processing. The related parameters are described as follows:

                                                                          -
                                                                          • Path: (optional) request URL.
                                                                          • Port: (mandatory) request port.
                                                                          • Host: (optional) requested host IP address. The default value is the IP address of the pod.
                                                                          +

                                                                          Path: /nginx

                                                                          +

                                                                          Port: 80

                                                                          +

                                                                          Host: 127.0.0.1

                                                                          +

                                                                          Used for initiating an HTTP request. The related parameters are described as follows:

                                                                          +
                                                                          • Path: (optional) request URL.
                                                                          • Port: (mandatory) requested port.
                                                                          • Host: (optional) requested host IP address. The default value is the IP address of the pod.
                                                                          +
                                                                          lifecycle:
                                                                          +  preStop:
                                                                          +    httpGet:
                                                                          +      path: /nginx
                                                                          +      port: 80
                                                                          +      host: 127.0.0.1
                                                                          +      scheme: HTTP
                                                                          +...
                                                                          -

                                                                        +

                                                                      3. Configure other parameters and click Create Workload in the lower right corner. After a period of time, the workload status changes to Running.
                                                                      4. -

                                                                        YAML Example

                                                                        This section uses Nginx as an example to describe how to set the container lifecycle.

                                                                        -

                                                                        In the following configuration file, the postStart command is defined to run the install.sh command in the /bin/bash directory. preStop is defined to run the uninstall.sh command.

                                                                        -
                                                                        apiVersion: apps/v1
                                                                        +

                                                                        Example YAML

                                                                        1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
                                                                        2. Create a YAML file for configuring a workload. In this example, the file name is lifecycle.yaml. You can change it as needed.

                                                                          vim lifecycle.yaml
                                                                          +
                                                                          The file content is as follows:
                                                                          apiVersion: apps/v1
                                                                           kind: Deployment
                                                                           metadata:
                                                                             name: nginx
                                                                          @@ -170,24 +237,33 @@ spec:
                                                                               spec:
                                                                                 containers:
                                                                                 - image: nginx 
                                                                          -        command:
                                                                          -        - sleep 3600                        # Startup command
                                                                          +        command:
                                                                          +        - sleep 3600                        #Startup command: suspends the current process for 3,600s.
                                                                                   imagePullPolicy: Always
                                                                                   lifecycle:
                                                                          -          postStart:
                                                                          -            exec:
                                                                          -              command:
                                                                          -              - /bin/bash
                                                                          -              - install.sh                  # Post-start command
                                                                          -          preStop:
                                                                          -            exec:
                                                                          -              command:
                                                                          -              - /bin/bash
                                                                          -              - uninstall.sh                 # Pre-stop command
                                                                          +         postStart:
                                                                          +           exec:
                                                                          +              command:
                                                                          +              - /bin/bash
                                                                          +              - install.sh                  #Post-start command: Run the install.sh command in /bin/bash.
                                                                          +         preStop:
                                                                          +            exec:
                                                                          +              command:
                                                                          +              - /bin/bash
                                                                          +              - uninstall.sh                 #Pre-stop command: Run the uninstall.sh command in /bin/bash.
                                                                                   name: nginx
                                                                                 imagePullSecrets:
                                                                                 - name: default-secret
                                                                          +

                                                                        3. Create the workload.

                                                                          kubectl create -f lifecycle.yaml
                                                                          +

                                                                          If information similar to the following is displayed, the workload is being created:

                                                                          +
                                                                          deployment.apps/nginx created
                                                                          +

                                                                        4. Check the workload status.

                                                                          kubectl get deployment
                                                                          +

                                                                          If all the pods of the workload are available, the workload has been created.

                                                                          +
                                                                          NAME     READY   UP-TO-DATE   AVAILABLE   AGE
                                                                          +nginx      1/1     1            1           4m59s
                                                                          +

                                                                        +