diff --git a/docs/ucs/umn/ALL_META.TXT.json b/docs/ucs/umn/ALL_META.TXT.json
new file mode 100644
index 000000000..abed8f081
--- /dev/null
+++ b/docs/ucs/umn/ALL_META.TXT.json
@@ -0,0 +1,1645 @@
+[
+ {
+ "dockw":"User Guide"
+ },
+ {
+ "uri":"ucs_01_0201.html",
+ "node_id":"ucs_01_0201.xml",
+ "product_code":"ucs",
+ "code":"1",
+ "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "doc_type":"usermanual",
+ "kw":"UCS Clusters",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"UCS Clusters",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0200.html",
+ "node_id":"ucs_01_0200.xml",
+ "product_code":"ucs",
+ "code":"2",
+ "des":"UCS supports unified management of clusters across clouds and regions. The following types of clusters are supported:OTC clusters: CCE standard and CCE Turbo clustersAtta",
+ "doc_type":"usermanual",
+ "kw":"Overview,UCS Clusters,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0282.html",
+ "node_id":"ucs_01_0282.xml",
+ "product_code":"ucs",
+ "code":"3",
+ "des":"You can register OTC clusters (CCE standard clusters and CCE Turbo clusters) with UCS with just a few clicks. After the registration is complete, clusters can be managed ",
+ "doc_type":"usermanual",
+ "kw":"OTC Clusters,UCS Clusters,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"OTC Clusters",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0002.html",
+ "node_id":"ucs_01_0002.xml",
+ "product_code":"ucs",
+ "code":"4",
+ "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "doc_type":"usermanual",
+ "kw":"Attached Clusters",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Attached Clusters",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0162.html",
+ "node_id":"ucs_01_0162.xml",
+ "product_code":"ucs",
+ "code":"5",
+ "des":"Attached clusters refer to third-party Kubernetes clusters that comply with the Cloud Native Computing Foundation (CNCF) standard, such as AWS EKS clusters, Google Cloud ",
+ "doc_type":"usermanual",
+ "kw":"Overview,Attached Clusters,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0005.html",
+ "node_id":"ucs_01_0005.xml",
+ "product_code":"ucs",
+ "code":"6",
+ "des":"This section describes how to register an attached cluster and connect it to UCS over a public network.The OTCaccount must have the UCS FullAccess and VPCEndpoint Adminis",
+ "doc_type":"usermanual",
+ "kw":"Registering an Attached Cluster (Public Network Access),Attached Clusters,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Registering an Attached Cluster (Public Network Access)",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0006.html",
+ "node_id":"ucs_01_0006.xml",
+ "product_code":"ucs",
+ "code":"7",
+ "des":"Connecting attached clusters located in on-premises data centers or third-party clouds to UCS over public networks may cause security risks. To ensure stability and secur",
+ "doc_type":"usermanual",
+ "kw":"Registering an Attached Cluster (Private Network Access),Attached Clusters,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Registering an Attached Cluster (Private Network Access)",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0007.html",
+ "node_id":"ucs_01_0007.xml",
+ "product_code":"ucs",
+ "code":"8",
+ "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":"usermanual",
+ "kw":"Single-Cluster Management",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Single-Cluster Management",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0099.html",
+ "node_id":"ucs_01_0099.xml",
+ "product_code":"ucs",
+ "code":"9",
+ "des":"The UCS console allows you to manage each cluster on each cluster console.For OTC clusters (CCE standard and Turbo clusters), the operations on the cluster console of UCS",
+ "doc_type":"usermanual",
+ "kw":"Overview,Single-Cluster Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0102.html",
+ "node_id":"ucs_01_0102.xml",
+ "product_code":"ucs",
+ "code":"10",
+ "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":"usermanual",
+ "kw":"Nodes",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Nodes",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0103.html",
+ "node_id":"ucs_01_0103.xml",
+ "product_code":"ucs",
+ "code":"11",
+ "des":"After a cluster is connected to UCS, you can access the cluster console from UCS to view the nodes in a cluster.",
+ "doc_type":"usermanual",
+ "kw":"Viewing Nodes in a Cluster,Nodes,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Viewing Nodes in a Cluster",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0104.html",
+ "node_id":"ucs_01_0104.xml",
+ "product_code":"ucs",
+ "code":"12",
+ "des":"UCS allows you to add different labels to nodes to define different node attributes. By using these labels, you can quickly understand the characteristics of each node.Ta",
+ "doc_type":"usermanual",
+ "kw":"Adding Labels/Taints to Nodes,Nodes,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Adding Labels/Taints to Nodes",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0105.html",
+ "node_id":"ucs_01_0105.xml",
+ "product_code":"ucs",
+ "code":"13",
+ "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":"usermanual",
+ "kw":"Workload Management",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Workload Management",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0106.html",
+ "node_id":"ucs_01_0106.xml",
+ "product_code":"ucs",
+ "code":"14",
+ "des":"A workload is an abstract model of a group of pods in Kubernetes. Workloads defined in Kubernetes include Deployments, StatefulSets, jobs, and DaemonSets.Deployments: Pod",
+ "doc_type":"usermanual",
+ "kw":"startup,post-start,pre-stop,Deployments,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Deployments",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0136.html",
+ "node_id":"ucs_01_0136.xml",
+ "product_code":"ucs",
+ "code":"15",
+ "des":"Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.Container Information: Click Add Con",
+ "doc_type":"usermanual",
+ "kw":"startup,post-start,pre-stop,StatefulSets,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"StatefulSets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0137.html",
+ "node_id":"ucs_01_0137.xml",
+ "product_code":"ucs",
+ "code":"16",
+ "des":"Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.Container Information: Click Add Con",
+ "doc_type":"usermanual",
+ "kw":"startup,post-start,pre-stop,DaemonSets,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"DaemonSets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0107.html",
+ "node_id":"ucs_01_0107.xml",
+ "product_code":"ucs",
+ "code":"17",
+ "des":"In Kubernetes, there are two types of jobs: one-off jobs and cron jobs.A job (one-off job) is a resource object that Kubernetes uses to control batch tasks. Jobs are diff",
+ "doc_type":"usermanual",
+ "kw":"database backup,private container image,startup,post-start,pre-stop,private container image,startup,",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Jobs and Cron Jobs",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0108.html",
+ "node_id":"ucs_01_0108.xml",
+ "product_code":"ucs",
+ "code":"18",
+ "des":"A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates an application's container (or, in some cases, multip",
+ "doc_type":"usermanual",
+ "kw":"Pod,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Pod",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0147.html",
+ "node_id":"ucs_01_0147.xml",
+ "product_code":"ucs",
+ "code":"19",
+ "des":"UCS allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in the workloa",
+ "doc_type":"usermanual",
+ "kw":"CPU,memory,Setting Container Specifications,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Container Specifications",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0148.html",
+ "node_id":"ucs_01_0148.xml",
+ "product_code":"ucs",
+ "code":"20",
+ "des":"UCS provides callback functions (hooks) for the lifecycle management of containerized applications. For example, if you want a container to perform a certain operation be",
+ "doc_type":"usermanual",
+ "kw":"Startup Command,Post-Start,Pre-Stop,Setting Container Lifecycle Parameters,Workload Management,User ",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Container Lifecycle Parameters",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0149.html",
+ "node_id":"ucs_01_0149.xml",
+ "product_code":"ucs",
+ "code":"21",
+ "des":"Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application ex",
+ "doc_type":"usermanual",
+ "kw":"Health check,Liveness probe,(livenessProbe),HTTP request,TCP port,CLI,Setting Health Check for a Con",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Health Check for a Container",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0150.html",
+ "node_id":"ucs_01_0150.xml",
+ "product_code":"ucs",
+ "code":"22",
+ "des":"An environment variable is a variable whose value can affect the way a running container will behave. You can modify environment variables even after workloads are deploy",
+ "doc_type":"usermanual",
+ "kw":"Setting Environment Variables,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Environment Variables",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0151.html",
+ "node_id":"ucs_01_0151.xml",
+ "product_code":"ucs",
+ "code":"23",
+ "des":"In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.Rollback is to roll an application b",
+ "doc_type":"usermanual",
+ "kw":"Configuring a Workload Upgrade Policy,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Configuring a Workload Upgrade Policy",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0152.html",
+ "node_id":"ucs_01_0152.xml",
+ "product_code":"ucs",
+ "code":"24",
+ "des":"When creating a workload, you can use a nodeSelector to constrain pods to nodes with particular labels. The affinity and anti-affinity features greatly increase the types",
+ "doc_type":"usermanual",
+ "kw":"Scheduling Policy (Affinity/Anti-affinity),Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Scheduling Policy (Affinity/Anti-affinity)",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0399.html",
+ "node_id":"ucs_01_0399.xml",
+ "product_code":"ucs",
+ "code":"25",
+ "des":"A tolerance policy allows the scheduler to schedule pods to nodes with corresponding taints. This policy must be used together with node taints. One or more taints can be",
+ "doc_type":"usermanual",
+ "kw":"Tolerance Policies,Workload Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Tolerance Policies",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0109.html",
+ "node_id":"ucs_01_0109.xml",
+ "product_code":"ucs",
+ "code":"26",
+ "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":"usermanual",
+ "kw":"Networking",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Networking",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0110.html",
+ "node_id":"ucs_01_0110.xml",
+ "product_code":"ucs",
+ "code":"27",
+ "des":"Services provide fixed modes for accessing workloads in a cluster. You can create the following Services on the cluster console:ClusterIPA workload can be accessed from o",
+ "doc_type":"usermanual",
+ "kw":"cluster-internal domain name,Services,Networking,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Services",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0111.html",
+ "node_id":"ucs_01_0111.xml",
+ "product_code":"ucs",
+ "code":"28",
+ "des":"An ingress uses load balancers as the entry for external traffic. Compared with Layer-4 load balancing, it supports Uniform Resource Identifier (URI) configurations and d",
+ "doc_type":"usermanual",
+ "kw":"Ingresses,Networking,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Ingresses",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0112.html",
+ "node_id":"ucs_01_0112.xml",
+ "product_code":"ucs",
+ "code":"29",
+ "des":"To mount a PVC to a cluster, the cluster provider must support the StorageClass resource to dynamically create storage volumes. You can choose Storage on the cluster cons",
+ "doc_type":"usermanual",
+ "kw":"Container Storage,Single-Cluster Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Container Storage",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0113.html",
+ "node_id":"ucs_01_0113.xml",
+ "product_code":"ucs",
+ "code":"30",
+ "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":"usermanual",
+ "kw":"ConfigMaps and Secrets",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"ConfigMaps and Secrets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0114.html",
+ "node_id":"ucs_01_0114.xml",
+ "product_code":"ucs",
+ "code":"31",
+ "des":"A ConfigMap is a type of resource that stores configuration information required by a workload. Its content is user-defined. After creating ConfigMaps, you can use them a",
+ "doc_type":"usermanual",
+ "kw":"ConfigMap,container images,container,Creating a ConfigMap,ConfigMaps and Secrets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Creating a ConfigMap",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0115.html",
+ "node_id":"ucs_01_0115.xml",
+ "product_code":"ucs",
+ "code":"32",
+ "des":"A secret is a type of resource that holds sensitive data, such as authentication and key information, required by a workload. Its content is user-defined. After creating ",
+ "doc_type":"usermanual",
+ "kw":"secret,Creating a Secret,ConfigMaps and Secrets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Creating a Secret",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0116.html",
+ "node_id":"ucs_01_0116.xml",
+ "product_code":"ucs",
+ "code":"33",
+ "des":"Custom Resource Definitions (CRDs) are custom resource objects similar to Deployments or Services. You can run the kubectl commands to create and access CRDs for modular ",
+ "doc_type":"usermanual",
+ "kw":"Custom Resource Definitions,Single-Cluster Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Custom Resource Definitions",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0117.html",
+ "node_id":"ucs_01_0117.xml",
+ "product_code":"ucs",
+ "code":"34",
+ "des":"Namespaces that you create on the cluster console apply only to the current cluster. You can create Kubernetes objects and manage resource quotas in such namespaces, or d",
+ "doc_type":"usermanual",
+ "kw":"Namespaces,Single-Cluster Management,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Namespaces",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0003.html",
+ "node_id":"ucs_01_0003.xml",
+ "product_code":"ucs",
+ "code":"35",
+ "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "doc_type":"usermanual",
+ "kw":"Fleets",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Fleets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0008.html",
+ "node_id":"ucs_01_0008.xml",
+ "product_code":"ucs",
+ "code":"36",
+ "des":"A fleet contains multiple clusters. You can use fleets to classify associated clusters. You can also use a fleet for the unified management of multiple clusters, includin",
+ "doc_type":"usermanual",
+ "kw":"Overview,Fleets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0004.html",
+ "node_id":"ucs_01_0004.xml",
+ "product_code":"ucs",
+ "code":"37",
+ "des":"This section describes how to create a fleet, add clusters to the fleet, adding a permission policy for the fleet, remove clusters from the fleet, unregister clusters fro",
+ "doc_type":"usermanual",
+ "kw":"Managing Fleets,Fleets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Managing Fleets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0155.html",
+ "node_id":"ucs_01_0155.xml",
+ "product_code":"ucs",
+ "code":"38",
+ "des":"Clusters for which a fleet is not selected during registration or clusters removed from a fleet will be displayed on the Clusters Not in Fleet tab. This section describes",
+ "doc_type":"usermanual",
+ "kw":"Managing Clusters Not in the Fleet,Fleets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Managing Clusters Not in the Fleet",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0199.html",
+ "node_id":"ucs_01_0199.xml",
+ "product_code":"ucs",
+ "code":"39",
+ "des":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "doc_type":"usermanual",
+ "kw":"Cluster Federation",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Cluster Federation",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0017.html",
+ "node_id":"ucs_01_0017.xml",
+ "product_code":"ucs",
+ "code":"40",
+ "des":"Cluster federation is a multi-cloud container orchestration capability provided by Karmada. Cluster federation aims to manage multi-cluster applications in cross-cloud an",
+ "doc_type":"usermanual",
+ "kw":"Overview,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0018.html",
+ "node_id":"ucs_01_0018.xml",
+ "product_code":"ucs",
+ "code":"41",
+ "des":"You can enable cluster federation for a fleet with just a few clicks.Enabling cluster federation involves two phases: enabling cluster federation and adding clusters to t",
+ "doc_type":"usermanual",
+ "kw":"Enabling Cluster Federation,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Enabling Cluster Federation",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0320.html",
+ "node_id":"ucs_01_0320.xml",
+ "product_code":"ucs",
+ "code":"42",
+ "des":"This section describes how you can use kubectl to connect to a federation.When you use kubectl to connect to a federation, UCS uses kubeconfig.json generated on the feder",
+ "doc_type":"usermanual",
+ "kw":"Using kubectl to Connect to a Federation,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Using kubectl to Connect to a Federation",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0254.html",
+ "node_id":"ucs_01_0254.xml",
+ "product_code":"ucs",
+ "code":"43",
+ "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":"usermanual",
+ "kw":"Workloads",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Workloads",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0406.html",
+ "node_id":"ucs_01_0406.xml",
+ "product_code":"ucs",
+ "code":"44",
+ "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":"usermanual",
+ "kw":"Workload Creation",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Workload Creation",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0255.html",
+ "node_id":"ucs_01_0255.xml",
+ "product_code":"ucs",
+ "code":"45",
+ "des":"The federation function of UCS allows you to manage Kubernetes clusters in different regions or clouds, deploy applications globally in a unified manner, and deploy diffe",
+ "doc_type":"usermanual",
+ "kw":"Deployments,StatefulSets,DaemonSets,startup,post-start,pre-stop,Deployments,Workload Creation,User G",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Deployments",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0256.html",
+ "node_id":"ucs_01_0256.xml",
+ "product_code":"ucs",
+ "code":"46",
+ "des":"StatefulSets are a type of workloads that store data or status while running. Each pod in a StatefulSet is given a persistent identifier that remains even if the pod is m",
+ "doc_type":"usermanual",
+ "kw":"startup,post-start,pre-stop,StatefulSets,Workload Creation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"StatefulSets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0257.html",
+ "node_id":"ucs_01_0257.xml",
+ "product_code":"ucs",
+ "code":"47",
+ "des":"A DaemonSet ensures that a pod runs on all (or some) nodes in a cluster. When a new node is added to the cluster, a pod will be automatically deployed on it. When a node ",
+ "doc_type":"usermanual",
+ "kw":"startup,post-start,pre-stop,DaemonSets,Workload Creation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"DaemonSets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0258.html",
+ "node_id":"ucs_01_0258.xml",
+ "product_code":"ucs",
+ "code":"48",
+ "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":"usermanual",
+ "kw":"Container Settings",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Container Settings",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0259.html",
+ "node_id":"ucs_01_0259.xml",
+ "product_code":"ucs",
+ "code":"49",
+ "des":"A workload is an abstract model of a group of pods. One pod can encapsulate one or more containers. You can click Add Container in the upper right corner to add multiple ",
+ "doc_type":"usermanual",
+ "kw":"Setting Basic Container Information,Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Basic Container Information",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0260.html",
+ "node_id":"ucs_01_0260.xml",
+ "product_code":"ucs",
+ "code":"50",
+ "des":"UCS allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in the workloa",
+ "doc_type":"usermanual",
+ "kw":"Setting Container Specifications,Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Container Specifications",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0261.html",
+ "node_id":"ucs_01_0261.xml",
+ "product_code":"ucs",
+ "code":"51",
+ "des":"The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping,",
+ "doc_type":"usermanual",
+ "kw":"Startup Command,Post-Start,Pre-Stop,Setting Container Lifecycle Parameters,Container Settings,User G",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Container Lifecycle Parameters",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0262.html",
+ "node_id":"ucs_01_0262.xml",
+ "product_code":"ucs",
+ "code":"52",
+ "des":"Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application ex",
+ "doc_type":"usermanual",
+ "kw":"Health check,(livenessProbe),Setting Health Check for a Container,Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Health Check for a Container",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0263.html",
+ "node_id":"ucs_01_0263.xml",
+ "product_code":"ucs",
+ "code":"53",
+ "des":"An environment variable is a variable whose value can affect the way a running container will behave. You can modify environment variables even after workloads are deploy",
+ "doc_type":"usermanual",
+ "kw":"Setting Environment Variables,Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Setting Environment Variables",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0264.html",
+ "node_id":"ucs_01_0264.xml",
+ "product_code":"ucs",
+ "code":"54",
+ "des":"In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.You can set different upgrade polici",
+ "doc_type":"usermanual",
+ "kw":"Configuring a Workload Upgrade Policy,Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Configuring a Workload Upgrade Policy",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0265.html",
+ "node_id":"ucs_01_0265.xml",
+ "product_code":"ucs",
+ "code":"55",
+ "des":"Kubernetes supports affinity and anti-affinity scheduling at the node and pod levels. You can configure custom rules to achieve affinity and anti-affinity scheduling. For",
+ "doc_type":"usermanual",
+ "kw":"Configuring a Scheduling Policy (Affinity/Anti-affinity),Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Configuring a Scheduling Policy (Affinity/Anti-affinity)",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0037.html",
+ "node_id":"ucs_01_0037.xml",
+ "product_code":"ucs",
+ "code":"56",
+ "des":"Currently, there are two scheduling policies: cluster weights and automatic balancing.Configuring a Scheduling Policy on the ConsoleCalculation MethodAfter you set the we",
+ "doc_type":"usermanual",
+ "kw":"Configuring Scheduling and Differentiation,Container Settings,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Configuring Scheduling and Differentiation",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0317.html",
+ "node_id":"ucs_01_0317.xml",
+ "product_code":"ucs",
+ "code":"57",
+ "des":"After a workload is created, you can view its details, upgrade it, edit YAML, redeploy it, reschedule it, and delete it.Workload managementOperationDescriptionViewing Wor",
+ "doc_type":"usermanual",
+ "kw":"Managing a Workload,Workloads,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Managing a Workload",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0266.html",
+ "node_id":"ucs_01_0266.xml",
+ "product_code":"ucs",
+ "code":"58",
+ "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":"usermanual",
+ "kw":"ConfigMaps and Secrets",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"ConfigMaps and Secrets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0267.html",
+ "node_id":"ucs_01_0267.xml",
+ "product_code":"ucs",
+ "code":"59",
+ "des":"ConfigMaps allow you to decouple configuration files from container images to enhance the portability of workloads.ConfigMaps provide the following benefits:Manage config",
+ "doc_type":"usermanual",
+ "kw":"container images,container,Label,ConfigMaps,ConfigMaps and Secrets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"ConfigMaps",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0268.html",
+ "node_id":"ucs_01_0268.xml",
+ "product_code":"ucs",
+ "code":"60",
+ "des":"A secret is a type of resource that holds sensitive data, such as authentication and key information. Its content is user-defined.After a secret is created on the UCS con",
+ "doc_type":"usermanual",
+ "kw":"Opaque,kubernetes.io/dockerconfigjson,IngressTLS,Secrets,ConfigMaps and Secrets,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Secrets",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0269.html",
+ "node_id":"ucs_01_0269.xml",
+ "product_code":"ucs",
+ "code":"61",
+ "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":"usermanual",
+ "kw":"Services and Ingresses",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Services and Ingresses",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0270.html",
+ "node_id":"ucs_01_0270.xml",
+ "product_code":"ucs",
+ "code":"62",
+ "des":"UCS clusters allow workload access in different scenarios via Services and ingresses.After a Service or ingress is created on the UCS console, a Service or ingress with t",
+ "doc_type":"usermanual",
+ "kw":"cluster-internal domain name,Overview,Services and Ingresses,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0300.html",
+ "node_id":"ucs_01_0300.xml",
+ "product_code":"ucs",
+ "code":"63",
+ "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":"usermanual",
+ "kw":"Services",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Services",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0271.html",
+ "node_id":"ucs_01_0271.xml",
+ "product_code":"ucs",
+ "code":"64",
+ "des":"A ClusterIP Service allows workloads in the same cluster to use their cluster-internal domain names to access each other. A cluster-internal domain name is in the format ",
+ "doc_type":"usermanual",
+ "kw":"ClusterIP,Services,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"ClusterIP",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0272.html",
+ "node_id":"ucs_01_0272.xml",
+ "product_code":"ucs",
+ "code":"65",
+ "des":"A NodePort Service is exposed on a node at a static port, allowing access from outside the cluster to the workloads on the node. A ClusterIP Service, to which the NodePor",
+ "doc_type":"usermanual",
+ "kw":"NodePort,Services,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"NodePort",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0273.html",
+ "node_id":"ucs_01_0273.xml",
+ "product_code":"ucs",
+ "code":"66",
+ "des":"A workload can be accessed from a public network through a load balancer. This access type is applicable to Services that need to be exposed to a public network in the sy",
+ "doc_type":"usermanual",
+ "kw":"LoadBalancer,Services,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"LoadBalancer",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0274.html",
+ "node_id":"ucs_01_0274.xml",
+ "product_code":"ucs",
+ "code":"67",
+ "des":"An ingress uses load balancers as the entry for external traffic. Compared with Layer-4 load balancing, it supports Uniform Resource Identifier (URI) configurations and d",
+ "doc_type":"usermanual",
+ "kw":"Ingresses,Services and Ingresses,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Ingresses",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0275.html",
+ "node_id":"ucs_01_0275.xml",
+ "product_code":"ucs",
+ "code":"68",
+ "des":"Applications deployed in different clusters can be accessed using a unified public domain name. After you configure a public domain name, UCS can use it as a root domain ",
+ "doc_type":"usermanual",
+ "kw":"DNS Policies,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"DNS Policies",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0276.html",
+ "node_id":"ucs_01_0276.xml",
+ "product_code":"ucs",
+ "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":"usermanual",
+ "kw":"Storage",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Storage",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0277.html",
+ "node_id":"ucs_01_0277.xml",
+ "product_code":"ucs",
+ "code":"70",
+ "des":"You can configure a storage class in the Add Container step of creating a workload.You can mount the file directory of the host where a container is located to a specifie",
+ "doc_type":"usermanual",
+ "kw":"ConfigMap,secret,Overview,Storage,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Overview",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0278.html",
+ "node_id":"ucs_01_0278.xml",
+ "product_code":"ucs",
+ "code":"71",
+ "des":"There are four types of local volumes:hostPath: mounts a file directory of the host where the container is located to the specified mount point of the container. For exam",
+ "doc_type":"usermanual",
+ "kw":"Mounting a Local Volume,Storage,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Mounting a Local Volume",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0279.html",
+ "node_id":"ucs_01_0279.xml",
+ "product_code":"ucs",
+ "code":"72",
+ "des":"A PVC provides persistent storage management for containers in multiple clouds. The cloud storage can be mounted to containers based on actual requirements, ensuring high",
+ "doc_type":"usermanual",
+ "kw":"Mounting a PV,Storage,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Mounting a PV",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0280.html",
+ "node_id":"ucs_01_0280.xml",
+ "product_code":"ucs",
+ "code":"73",
+ "des":"After a PVC is created on the UCS console, a PVC with the same name is automatically created in your cluster. Also a PersistentVolume (PV) is created and bound with the P",
+ "doc_type":"usermanual",
+ "kw":"Creating a PVC,Storage,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Creating a PVC",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0281.html",
+ "node_id":"ucs_01_0281.xml",
+ "product_code":"ucs",
+ "code":"74",
+ "des":"A namespace is an abstract integration of a group of resources and objects in a cluster. Namespace-level resource quotas limit the amount of resources available to teams ",
+ "doc_type":"usermanual",
+ "kw":"Namespaces,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Namespaces",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0170.html",
+ "node_id":"ucs_01_0170.xml",
+ "product_code":"ucs",
+ "code":"75",
+ "des":"Horizontal Pod Autoscaling (HPA) is a Kubernetes function that implements horizontal auto scaling of pods. It dynamically adjusts the number of workload pods based on the",
+ "doc_type":"usermanual",
+ "kw":"HPA Policies,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"HPA Policies",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0318.html",
+ "node_id":"ucs_01_0318.xml",
+ "product_code":"ucs",
+ "code":"76",
+ "des":"UCS allows you to add different labels to clusters to define different attributes. By using these cluster labels, you can quickly understand the characteristics of each c",
+ "doc_type":"usermanual",
+ "kw":"Adding Labels and Taints to a Cluster,Cluster Federation,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Adding Labels and Taints to a Cluster",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0016.html",
+ "node_id":"ucs_01_0016.xml",
+ "product_code":"ucs",
+ "code":"77",
+ "des":"UCS integrates OTC SoftWare Repository for Containers (SWR), which provides easy, secure, and reliable management over container images throughout their lifecycles, facil",
+ "doc_type":"usermanual",
+ "kw":"Image Repositories,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Image Repositories",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0009.html",
+ "node_id":"ucs_01_0009.xml",
+ "product_code":"ucs",
+ "code":"78",
+ "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":"usermanual",
+ "kw":"Permissions",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Permissions",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0010.html",
+ "node_id":"ucs_01_0010.xml",
+ "product_code":"ucs",
+ "code":"79",
+ "des":"UCS permissions management allows you to grant permissions to IAM users and user groups under your tenant accounts. UCS combines the advantages of IAM and Kubernetes RBAC",
+ "doc_type":"usermanual",
+ "kw":"UCS Permissions,Permissions,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"UCS Permissions",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0156.html",
+ "node_id":"ucs_01_0156.xml",
+ "product_code":"ucs",
+ "code":"80",
+ "des":"UCS cluster- and fleet-level permissions are assigned based on IAM system-defined policies and custom policies. You can use user groups to assign permissions to IAM users",
+ "doc_type":"usermanual",
+ "kw":"UCS Resource Permissions (IAM-based),Permissions,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"UCS Resource Permissions (IAM-based)",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0011.html",
+ "node_id":"ucs_01_0011.xml",
+ "product_code":"ucs",
+ "code":"81",
+ "des":"You can regulate users' or user groups' access to Kubernetes resources based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role,",
+ "doc_type":"usermanual",
+ "kw":"Kubernetes Resource Permissions in a Cluster (Kubernetes RBAC-based),Permissions,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Kubernetes Resource Permissions in a Cluster (Kubernetes RBAC-based)",
+ "githuburl":""
+ },
+ {
+ "uri":"ucs_01_0013.html",
+ "node_id":"ucs_01_0013.xml",
+ "product_code":"ucs",
+ "code":"82",
+ "des":"By their application scope, Kubernetes resource objects can be categorized into namespace objects or cluster objects.Namespace is an isolation mechanism of Kubernetes and",
+ "doc_type":"usermanual",
+ "kw":"Kubernetes Resource Objects,Permissions,User Guide",
+ "search_title":"",
+ "metedata":[
+ {
+ "IsBot":"No",
+ "opensource":"true",
+ "prodname":"ucs",
+ "documenttype":"usermanual"
+ }
+ ],
+ "title":"Kubernetes Resource Objects",
+ "githuburl":""
+ }
+]
\ No newline at end of file
diff --git a/docs/ucs/umn/CLASS.TXT.json b/docs/ucs/umn/CLASS.TXT.json
new file mode 100644
index 000000000..aa76cded9
--- /dev/null
+++ b/docs/ucs/umn/CLASS.TXT.json
@@ -0,0 +1,740 @@
+[
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"UCS Clusters",
+ "uri":"ucs_01_0201.html",
+ "doc_type":"usermanual",
+ "p_code":"",
+ "code":"1"
+ },
+ {
+ "desc":"UCS supports unified management of clusters across clouds and regions. The following types of clusters are supported:OTC clusters: CCE standard and CCE Turbo clustersAtta",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0200.html",
+ "doc_type":"usermanual",
+ "p_code":"1",
+ "code":"2"
+ },
+ {
+ "desc":"You can register OTC clusters (CCE standard clusters and CCE Turbo clusters) with UCS with just a few clicks. After the registration is complete, clusters can be managed ",
+ "product_code":"ucs",
+ "title":"OTC Clusters",
+ "uri":"ucs_01_0282.html",
+ "doc_type":"usermanual",
+ "p_code":"1",
+ "code":"3"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Attached Clusters",
+ "uri":"ucs_01_0002.html",
+ "doc_type":"usermanual",
+ "p_code":"1",
+ "code":"4"
+ },
+ {
+ "desc":"Attached clusters refer to third-party Kubernetes clusters that comply with the Cloud Native Computing Foundation (CNCF) standard, such as AWS EKS clusters, Google Cloud ",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0162.html",
+ "doc_type":"usermanual",
+ "p_code":"4",
+ "code":"5"
+ },
+ {
+ "desc":"This section describes how to register an attached cluster and connect it to UCS over a public network.The OTCaccount must have the UCS FullAccess and VPCEndpoint Adminis",
+ "product_code":"ucs",
+ "title":"Registering an Attached Cluster (Public Network Access)",
+ "uri":"ucs_01_0005.html",
+ "doc_type":"usermanual",
+ "p_code":"4",
+ "code":"6"
+ },
+ {
+ "desc":"Connecting attached clusters located in on-premises data centers or third-party clouds to UCS over public networks may cause security risks. To ensure stability and secur",
+ "product_code":"ucs",
+ "title":"Registering an Attached Cluster (Private Network Access)",
+ "uri":"ucs_01_0006.html",
+ "doc_type":"usermanual",
+ "p_code":"4",
+ "code":"7"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Single-Cluster Management",
+ "uri":"ucs_01_0007.html",
+ "doc_type":"usermanual",
+ "p_code":"1",
+ "code":"8"
+ },
+ {
+ "desc":"The UCS console allows you to manage each cluster on each cluster console.For OTC clusters (CCE standard and Turbo clusters), the operations on the cluster console of UCS",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0099.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"9"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Nodes",
+ "uri":"ucs_01_0102.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"10"
+ },
+ {
+ "desc":"After a cluster is connected to UCS, you can access the cluster console from UCS to view the nodes in a cluster.",
+ "product_code":"ucs",
+ "title":"Viewing Nodes in a Cluster",
+ "uri":"ucs_01_0103.html",
+ "doc_type":"usermanual",
+ "p_code":"10",
+ "code":"11"
+ },
+ {
+ "desc":"UCS allows you to add different labels to nodes to define different node attributes. By using these labels, you can quickly understand the characteristics of each node.Ta",
+ "product_code":"ucs",
+ "title":"Adding Labels/Taints to Nodes",
+ "uri":"ucs_01_0104.html",
+ "doc_type":"usermanual",
+ "p_code":"10",
+ "code":"12"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Workload Management",
+ "uri":"ucs_01_0105.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"13"
+ },
+ {
+ "desc":"A workload is an abstract model of a group of pods in Kubernetes. Workloads defined in Kubernetes include Deployments, StatefulSets, jobs, and DaemonSets.Deployments: Pod",
+ "product_code":"ucs",
+ "title":"Deployments",
+ "uri":"ucs_01_0106.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"14"
+ },
+ {
+ "desc":"Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.Container Information: Click Add Con",
+ "product_code":"ucs",
+ "title":"StatefulSets",
+ "uri":"ucs_01_0136.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"15"
+ },
+ {
+ "desc":"Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.Container Information: Click Add Con",
+ "product_code":"ucs",
+ "title":"DaemonSets",
+ "uri":"ucs_01_0137.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"16"
+ },
+ {
+ "desc":"In Kubernetes, there are two types of jobs: one-off jobs and cron jobs.A job (one-off job) is a resource object that Kubernetes uses to control batch tasks. Jobs are diff",
+ "product_code":"ucs",
+ "title":"Jobs and Cron Jobs",
+ "uri":"ucs_01_0107.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"17"
+ },
+ {
+ "desc":"A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates an application's container (or, in some cases, multip",
+ "product_code":"ucs",
+ "title":"Pod",
+ "uri":"ucs_01_0108.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"18"
+ },
+ {
+ "desc":"UCS allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in the workloa",
+ "product_code":"ucs",
+ "title":"Setting Container Specifications",
+ "uri":"ucs_01_0147.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"19"
+ },
+ {
+ "desc":"UCS provides callback functions (hooks) for the lifecycle management of containerized applications. For example, if you want a container to perform a certain operation be",
+ "product_code":"ucs",
+ "title":"Setting Container Lifecycle Parameters",
+ "uri":"ucs_01_0148.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"20"
+ },
+ {
+ "desc":"Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application ex",
+ "product_code":"ucs",
+ "title":"Setting Health Check for a Container",
+ "uri":"ucs_01_0149.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"21"
+ },
+ {
+ "desc":"An environment variable is a variable whose value can affect the way a running container will behave. You can modify environment variables even after workloads are deploy",
+ "product_code":"ucs",
+ "title":"Setting Environment Variables",
+ "uri":"ucs_01_0150.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"22"
+ },
+ {
+ "desc":"In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.Rollback is to roll an application b",
+ "product_code":"ucs",
+ "title":"Configuring a Workload Upgrade Policy",
+ "uri":"ucs_01_0151.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"23"
+ },
+ {
+ "desc":"When creating a workload, you can use a nodeSelector to constrain pods to nodes with particular labels. The affinity and anti-affinity features greatly increase the types",
+ "product_code":"ucs",
+ "title":"Scheduling Policy (Affinity/Anti-affinity)",
+ "uri":"ucs_01_0152.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"24"
+ },
+ {
+ "desc":"A tolerance policy allows the scheduler to schedule pods to nodes with corresponding taints. This policy must be used together with node taints. One or more taints can be",
+ "product_code":"ucs",
+ "title":"Tolerance Policies",
+ "uri":"ucs_01_0399.html",
+ "doc_type":"usermanual",
+ "p_code":"13",
+ "code":"25"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Networking",
+ "uri":"ucs_01_0109.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"26"
+ },
+ {
+ "desc":"Services provide fixed modes for accessing workloads in a cluster. You can create the following Services on the cluster console:ClusterIPA workload can be accessed from o",
+ "product_code":"ucs",
+ "title":"Services",
+ "uri":"ucs_01_0110.html",
+ "doc_type":"usermanual",
+ "p_code":"26",
+ "code":"27"
+ },
+ {
+ "desc":"An ingress uses load balancers as the entry for external traffic. Compared with Layer-4 load balancing, it supports Uniform Resource Identifier (URI) configurations and d",
+ "product_code":"ucs",
+ "title":"Ingresses",
+ "uri":"ucs_01_0111.html",
+ "doc_type":"usermanual",
+ "p_code":"26",
+ "code":"28"
+ },
+ {
+ "desc":"To mount a PVC to a cluster, the cluster provider must support the StorageClass resource to dynamically create storage volumes. You can choose Storage on the cluster cons",
+ "product_code":"ucs",
+ "title":"Container Storage",
+ "uri":"ucs_01_0112.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"29"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"ConfigMaps and Secrets",
+ "uri":"ucs_01_0113.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"30"
+ },
+ {
+ "desc":"A ConfigMap is a type of resource that stores configuration information required by a workload. Its content is user-defined. After creating ConfigMaps, you can use them a",
+ "product_code":"ucs",
+ "title":"Creating a ConfigMap",
+ "uri":"ucs_01_0114.html",
+ "doc_type":"usermanual",
+ "p_code":"30",
+ "code":"31"
+ },
+ {
+ "desc":"A secret is a type of resource that holds sensitive data, such as authentication and key information, required by a workload. Its content is user-defined. After creating ",
+ "product_code":"ucs",
+ "title":"Creating a Secret",
+ "uri":"ucs_01_0115.html",
+ "doc_type":"usermanual",
+ "p_code":"30",
+ "code":"32"
+ },
+ {
+ "desc":"Custom Resource Definitions (CRDs) are custom resource objects similar to Deployments or Services. You can run the kubectl commands to create and access CRDs for modular ",
+ "product_code":"ucs",
+ "title":"Custom Resource Definitions",
+ "uri":"ucs_01_0116.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"33"
+ },
+ {
+ "desc":"Namespaces that you create on the cluster console apply only to the current cluster. You can create Kubernetes objects and manage resource quotas in such namespaces, or d",
+ "product_code":"ucs",
+ "title":"Namespaces",
+ "uri":"ucs_01_0117.html",
+ "doc_type":"usermanual",
+ "p_code":"8",
+ "code":"34"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Fleets",
+ "uri":"ucs_01_0003.html",
+ "doc_type":"usermanual",
+ "p_code":"",
+ "code":"35"
+ },
+ {
+ "desc":"A fleet contains multiple clusters. You can use fleets to classify associated clusters. You can also use a fleet for the unified management of multiple clusters, includin",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0008.html",
+ "doc_type":"usermanual",
+ "p_code":"35",
+ "code":"36"
+ },
+ {
+ "desc":"This section describes how to create a fleet, add clusters to the fleet, adding a permission policy for the fleet, remove clusters from the fleet, unregister clusters fro",
+ "product_code":"ucs",
+ "title":"Managing Fleets",
+ "uri":"ucs_01_0004.html",
+ "doc_type":"usermanual",
+ "p_code":"35",
+ "code":"37"
+ },
+ {
+ "desc":"Clusters for which a fleet is not selected during registration or clusters removed from a fleet will be displayed on the Clusters Not in Fleet tab. This section describes",
+ "product_code":"ucs",
+ "title":"Managing Clusters Not in the Fleet",
+ "uri":"ucs_01_0155.html",
+ "doc_type":"usermanual",
+ "p_code":"35",
+ "code":"38"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Cluster Federation",
+ "uri":"ucs_01_0199.html",
+ "doc_type":"usermanual",
+ "p_code":"",
+ "code":"39"
+ },
+ {
+ "desc":"Cluster federation is a multi-cloud container orchestration capability provided by Karmada. Cluster federation aims to manage multi-cluster applications in cross-cloud an",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0017.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"40"
+ },
+ {
+ "desc":"You can enable cluster federation for a fleet with just a few clicks.Enabling cluster federation involves two phases: enabling cluster federation and adding clusters to t",
+ "product_code":"ucs",
+ "title":"Enabling Cluster Federation",
+ "uri":"ucs_01_0018.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"41"
+ },
+ {
+ "desc":"This section describes how you can use kubectl to connect to a federation.When you use kubectl to connect to a federation, UCS uses kubeconfig.json generated on the feder",
+ "product_code":"ucs",
+ "title":"Using kubectl to Connect to a Federation",
+ "uri":"ucs_01_0320.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"42"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Workloads",
+ "uri":"ucs_01_0254.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"43"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Workload Creation",
+ "uri":"ucs_01_0406.html",
+ "doc_type":"usermanual",
+ "p_code":"43",
+ "code":"44"
+ },
+ {
+ "desc":"The federation function of UCS allows you to manage Kubernetes clusters in different regions or clouds, deploy applications globally in a unified manner, and deploy diffe",
+ "product_code":"ucs",
+ "title":"Deployments",
+ "uri":"ucs_01_0255.html",
+ "doc_type":"usermanual",
+ "p_code":"44",
+ "code":"45"
+ },
+ {
+ "desc":"StatefulSets are a type of workloads that store data or status while running. Each pod in a StatefulSet is given a persistent identifier that remains even if the pod is m",
+ "product_code":"ucs",
+ "title":"StatefulSets",
+ "uri":"ucs_01_0256.html",
+ "doc_type":"usermanual",
+ "p_code":"44",
+ "code":"46"
+ },
+ {
+ "desc":"A DaemonSet ensures that a pod runs on all (or some) nodes in a cluster. When a new node is added to the cluster, a pod will be automatically deployed on it. When a node ",
+ "product_code":"ucs",
+ "title":"DaemonSets",
+ "uri":"ucs_01_0257.html",
+ "doc_type":"usermanual",
+ "p_code":"44",
+ "code":"47"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Container Settings",
+ "uri":"ucs_01_0258.html",
+ "doc_type":"usermanual",
+ "p_code":"43",
+ "code":"48"
+ },
+ {
+ "desc":"A workload is an abstract model of a group of pods. One pod can encapsulate one or more containers. You can click Add Container in the upper right corner to add multiple ",
+ "product_code":"ucs",
+ "title":"Setting Basic Container Information",
+ "uri":"ucs_01_0259.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"49"
+ },
+ {
+ "desc":"UCS allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in the workloa",
+ "product_code":"ucs",
+ "title":"Setting Container Specifications",
+ "uri":"ucs_01_0260.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"50"
+ },
+ {
+ "desc":"The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping,",
+ "product_code":"ucs",
+ "title":"Setting Container Lifecycle Parameters",
+ "uri":"ucs_01_0261.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"51"
+ },
+ {
+ "desc":"Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application ex",
+ "product_code":"ucs",
+ "title":"Setting Health Check for a Container",
+ "uri":"ucs_01_0262.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"52"
+ },
+ {
+ "desc":"An environment variable is a variable whose value can affect the way a running container will behave. You can modify environment variables even after workloads are deploy",
+ "product_code":"ucs",
+ "title":"Setting Environment Variables",
+ "uri":"ucs_01_0263.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"53"
+ },
+ {
+ "desc":"In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.You can set different upgrade polici",
+ "product_code":"ucs",
+ "title":"Configuring a Workload Upgrade Policy",
+ "uri":"ucs_01_0264.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"54"
+ },
+ {
+ "desc":"Kubernetes supports affinity and anti-affinity scheduling at the node and pod levels. You can configure custom rules to achieve affinity and anti-affinity scheduling. For",
+ "product_code":"ucs",
+ "title":"Configuring a Scheduling Policy (Affinity/Anti-affinity)",
+ "uri":"ucs_01_0265.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"55"
+ },
+ {
+ "desc":"Currently, there are two scheduling policies: cluster weights and automatic balancing.Configuring a Scheduling Policy on the ConsoleCalculation MethodAfter you set the we",
+ "product_code":"ucs",
+ "title":"Configuring Scheduling and Differentiation",
+ "uri":"ucs_01_0037.html",
+ "doc_type":"usermanual",
+ "p_code":"48",
+ "code":"56"
+ },
+ {
+ "desc":"After a workload is created, you can view its details, upgrade it, edit YAML, redeploy it, reschedule it, and delete it.Workload managementOperationDescriptionViewing Wor",
+ "product_code":"ucs",
+ "title":"Managing a Workload",
+ "uri":"ucs_01_0317.html",
+ "doc_type":"usermanual",
+ "p_code":"43",
+ "code":"57"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"ConfigMaps and Secrets",
+ "uri":"ucs_01_0266.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"58"
+ },
+ {
+ "desc":"ConfigMaps allow you to decouple configuration files from container images to enhance the portability of workloads.ConfigMaps provide the following benefits:Manage config",
+ "product_code":"ucs",
+ "title":"ConfigMaps",
+ "uri":"ucs_01_0267.html",
+ "doc_type":"usermanual",
+ "p_code":"58",
+ "code":"59"
+ },
+ {
+ "desc":"A secret is a type of resource that holds sensitive data, such as authentication and key information. Its content is user-defined.After a secret is created on the UCS con",
+ "product_code":"ucs",
+ "title":"Secrets",
+ "uri":"ucs_01_0268.html",
+ "doc_type":"usermanual",
+ "p_code":"58",
+ "code":"60"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Services and Ingresses",
+ "uri":"ucs_01_0269.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"61"
+ },
+ {
+ "desc":"UCS clusters allow workload access in different scenarios via Services and ingresses.After a Service or ingress is created on the UCS console, a Service or ingress with t",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0270.html",
+ "doc_type":"usermanual",
+ "p_code":"61",
+ "code":"62"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Services",
+ "uri":"ucs_01_0300.html",
+ "doc_type":"usermanual",
+ "p_code":"61",
+ "code":"63"
+ },
+ {
+ "desc":"A ClusterIP Service allows workloads in the same cluster to use their cluster-internal domain names to access each other. A cluster-internal domain name is in the format ",
+ "product_code":"ucs",
+ "title":"ClusterIP",
+ "uri":"ucs_01_0271.html",
+ "doc_type":"usermanual",
+ "p_code":"63",
+ "code":"64"
+ },
+ {
+ "desc":"A NodePort Service is exposed on a node at a static port, allowing access from outside the cluster to the workloads on the node. A ClusterIP Service, to which the NodePor",
+ "product_code":"ucs",
+ "title":"NodePort",
+ "uri":"ucs_01_0272.html",
+ "doc_type":"usermanual",
+ "p_code":"63",
+ "code":"65"
+ },
+ {
+ "desc":"A workload can be accessed from a public network through a load balancer. This access type is applicable to Services that need to be exposed to a public network in the sy",
+ "product_code":"ucs",
+ "title":"LoadBalancer",
+ "uri":"ucs_01_0273.html",
+ "doc_type":"usermanual",
+ "p_code":"63",
+ "code":"66"
+ },
+ {
+ "desc":"An ingress uses load balancers as the entry for external traffic. Compared with Layer-4 load balancing, it supports Uniform Resource Identifier (URI) configurations and d",
+ "product_code":"ucs",
+ "title":"Ingresses",
+ "uri":"ucs_01_0274.html",
+ "doc_type":"usermanual",
+ "p_code":"61",
+ "code":"67"
+ },
+ {
+ "desc":"Applications deployed in different clusters can be accessed using a unified public domain name. After you configure a public domain name, UCS can use it as a root domain ",
+ "product_code":"ucs",
+ "title":"DNS Policies",
+ "uri":"ucs_01_0275.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"68"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Storage",
+ "uri":"ucs_01_0276.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"69"
+ },
+ {
+ "desc":"You can configure a storage class in the Add Container step of creating a workload.You can mount the file directory of the host where a container is located to a specifie",
+ "product_code":"ucs",
+ "title":"Overview",
+ "uri":"ucs_01_0277.html",
+ "doc_type":"usermanual",
+ "p_code":"69",
+ "code":"70"
+ },
+ {
+ "desc":"There are four types of local volumes:hostPath: mounts a file directory of the host where the container is located to the specified mount point of the container. For exam",
+ "product_code":"ucs",
+ "title":"Mounting a Local Volume",
+ "uri":"ucs_01_0278.html",
+ "doc_type":"usermanual",
+ "p_code":"69",
+ "code":"71"
+ },
+ {
+ "desc":"A PVC provides persistent storage management for containers in multiple clouds. The cloud storage can be mounted to containers based on actual requirements, ensuring high",
+ "product_code":"ucs",
+ "title":"Mounting a PV",
+ "uri":"ucs_01_0279.html",
+ "doc_type":"usermanual",
+ "p_code":"69",
+ "code":"72"
+ },
+ {
+ "desc":"After a PVC is created on the UCS console, a PVC with the same name is automatically created in your cluster. Also a PersistentVolume (PV) is created and bound with the P",
+ "product_code":"ucs",
+ "title":"Creating a PVC",
+ "uri":"ucs_01_0280.html",
+ "doc_type":"usermanual",
+ "p_code":"69",
+ "code":"73"
+ },
+ {
+ "desc":"A namespace is an abstract integration of a group of resources and objects in a cluster. Namespace-level resource quotas limit the amount of resources available to teams ",
+ "product_code":"ucs",
+ "title":"Namespaces",
+ "uri":"ucs_01_0281.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"74"
+ },
+ {
+ "desc":"Horizontal Pod Autoscaling (HPA) is a Kubernetes function that implements horizontal auto scaling of pods. It dynamically adjusts the number of workload pods based on the",
+ "product_code":"ucs",
+ "title":"HPA Policies",
+ "uri":"ucs_01_0170.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"75"
+ },
+ {
+ "desc":"UCS allows you to add different labels to clusters to define different attributes. By using these cluster labels, you can quickly understand the characteristics of each c",
+ "product_code":"ucs",
+ "title":"Adding Labels and Taints to a Cluster",
+ "uri":"ucs_01_0318.html",
+ "doc_type":"usermanual",
+ "p_code":"39",
+ "code":"76"
+ },
+ {
+ "desc":"UCS integrates OTC SoftWare Repository for Containers (SWR), which provides easy, secure, and reliable management over container images throughout their lifecycles, facil",
+ "product_code":"ucs",
+ "title":"Image Repositories",
+ "uri":"ucs_01_0016.html",
+ "doc_type":"usermanual",
+ "p_code":"",
+ "code":"77"
+ },
+ {
+ "desc":"HUAWEI CLOUD Help Center presents technical documents to help you quickly get started with HUAWEI CLOUD services. The technical documents include Service Overview, Price Details, Purchase Guide, User Guide, API Reference, Best Practices, FAQs, and Videos.",
+ "product_code":"ucs",
+ "title":"Permissions",
+ "uri":"ucs_01_0009.html",
+ "doc_type":"usermanual",
+ "p_code":"",
+ "code":"78"
+ },
+ {
+ "desc":"UCS permissions management allows you to grant permissions to IAM users and user groups under your tenant accounts. UCS combines the advantages of IAM and Kubernetes RBAC",
+ "product_code":"ucs",
+ "title":"UCS Permissions",
+ "uri":"ucs_01_0010.html",
+ "doc_type":"usermanual",
+ "p_code":"78",
+ "code":"79"
+ },
+ {
+ "desc":"UCS cluster- and fleet-level permissions are assigned based on IAM system-defined policies and custom policies. You can use user groups to assign permissions to IAM users",
+ "product_code":"ucs",
+ "title":"UCS Resource Permissions (IAM-based)",
+ "uri":"ucs_01_0156.html",
+ "doc_type":"usermanual",
+ "p_code":"78",
+ "code":"80"
+ },
+ {
+ "desc":"You can regulate users' or user groups' access to Kubernetes resources based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role,",
+ "product_code":"ucs",
+ "title":"Kubernetes Resource Permissions in a Cluster (Kubernetes RBAC-based)",
+ "uri":"ucs_01_0011.html",
+ "doc_type":"usermanual",
+ "p_code":"78",
+ "code":"81"
+ },
+ {
+ "desc":"By their application scope, Kubernetes resource objects can be categorized into namespace objects or cluster objects.Namespace is an isolation mechanism of Kubernetes and",
+ "product_code":"ucs",
+ "title":"Kubernetes Resource Objects",
+ "uri":"ucs_01_0013.html",
+ "doc_type":"usermanual",
+ "p_code":"78",
+ "code":"82"
+ }
+]
\ No newline at end of file
diff --git a/docs/ucs/umn/PARAMETERS.txt b/docs/ucs/umn/PARAMETERS.txt
new file mode 100644
index 000000000..6da8d5f07
--- /dev/null
+++ b/docs/ucs/umn/PARAMETERS.txt
@@ -0,0 +1,3 @@
+version=""
+language="en-us"
+type=""
\ No newline at end of file
diff --git a/docs/ucs/umn/en-us_image_0000001277812325.png b/docs/ucs/umn/en-us_image_0000001277812325.png
new file mode 100644
index 000000000..f1d574c2e
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001277812325.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001293009114.png b/docs/ucs/umn/en-us_image_0000001293009114.png
new file mode 100644
index 000000000..34f778a0e
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001293009114.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001317877889.png b/docs/ucs/umn/en-us_image_0000001317877889.png
new file mode 100644
index 000000000..9d8b45996
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001317877889.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001317957925.png b/docs/ucs/umn/en-us_image_0000001317957925.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001317957925.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001322267590.png b/docs/ucs/umn/en-us_image_0000001322267590.png
new file mode 100644
index 000000000..7cdfc47db
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001322267590.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001322427538.png b/docs/ucs/umn/en-us_image_0000001322427538.png
new file mode 100644
index 000000000..42fccb7bf
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001322427538.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001345751013.png b/docs/ucs/umn/en-us_image_0000001345751013.png
new file mode 100644
index 000000000..7114ee7e7
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001345751013.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001377241982.png b/docs/ucs/umn/en-us_image_0000001377241982.png
new file mode 100644
index 000000000..79e25a4a5
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001377241982.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001411282188.png b/docs/ucs/umn/en-us_image_0000001411282188.png
new file mode 100644
index 000000000..2bc017c15
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001411282188.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001416896654.png b/docs/ucs/umn/en-us_image_0000001416896654.png
new file mode 100644
index 000000000..f1d574c2e
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001416896654.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001433849600.png b/docs/ucs/umn/en-us_image_0000001433849600.png
new file mode 100644
index 000000000..0a9f4a081
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001433849600.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001461556069.png b/docs/ucs/umn/en-us_image_0000001461556069.png
new file mode 100644
index 000000000..1acb5a8d7
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001461556069.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001503446844.png b/docs/ucs/umn/en-us_image_0000001503446844.png
new file mode 100644
index 000000000..1a8f98034
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001503446844.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001503659388.png b/docs/ucs/umn/en-us_image_0000001503659388.png
new file mode 100644
index 000000000..63057bbd7
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001503659388.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001503680580.png b/docs/ucs/umn/en-us_image_0000001503680580.png
new file mode 100644
index 000000000..6b34cadc3
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001503680580.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001503820864.png b/docs/ucs/umn/en-us_image_0000001503820864.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001503820864.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001503824204.png b/docs/ucs/umn/en-us_image_0000001503824204.png
new file mode 100644
index 000000000..1381b2316
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001503824204.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001503984840.png b/docs/ucs/umn/en-us_image_0000001503984840.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001503984840.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001504004280.png b/docs/ucs/umn/en-us_image_0000001504004280.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001504004280.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001504164728.png b/docs/ucs/umn/en-us_image_0000001504164728.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001504164728.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001554286565.png b/docs/ucs/umn/en-us_image_0000001554286565.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001554286565.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001554793633.png b/docs/ucs/umn/en-us_image_0000001554793633.png
new file mode 100644
index 000000000..a0f161aef
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001554793633.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001554800229.png b/docs/ucs/umn/en-us_image_0000001554800229.png
new file mode 100644
index 000000000..800fda348
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001554800229.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001554898973.png b/docs/ucs/umn/en-us_image_0000001554898973.png
new file mode 100644
index 000000000..7cdfc47db
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001554898973.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001554906629.png b/docs/ucs/umn/en-us_image_0000001554906629.png
new file mode 100644
index 000000000..e6be98901
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001554906629.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001568318244.png b/docs/ucs/umn/en-us_image_0000001568318244.png
new file mode 100644
index 000000000..4710eb16e
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001568318244.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001568637180.png b/docs/ucs/umn/en-us_image_0000001568637180.png
new file mode 100644
index 000000000..79e25a4a5
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001568637180.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001620130045.png b/docs/ucs/umn/en-us_image_0000001620130045.png
new file mode 100644
index 000000000..1f6c19232
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001620130045.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001645555145.png b/docs/ucs/umn/en-us_image_0000001645555145.png
new file mode 100644
index 000000000..5a96fbe9d
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001645555145.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001682205542.png b/docs/ucs/umn/en-us_image_0000001682205542.png
new file mode 100644
index 000000000..2dae5b2df
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001682205542.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001804415254.png b/docs/ucs/umn/en-us_image_0000001804415254.png
new file mode 100644
index 000000000..1f6c19232
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001804415254.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001834789605.png b/docs/ucs/umn/en-us_image_0000001834789605.png
new file mode 100644
index 000000000..adb0a608f
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001834789605.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001851134021.png b/docs/ucs/umn/en-us_image_0000001851134021.png
new file mode 100644
index 000000000..1f6c19232
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001851134021.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001853742645.png b/docs/ucs/umn/en-us_image_0000001853742645.png
new file mode 100644
index 000000000..043e49b8b
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001853742645.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001875805610.png b/docs/ucs/umn/en-us_image_0000001875805610.png
new file mode 100644
index 000000000..c14ce16a9
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001875805610.png differ
diff --git a/docs/ucs/umn/en-us_image_0000001875972418.png b/docs/ucs/umn/en-us_image_0000001875972418.png
new file mode 100644
index 000000000..800c87ff6
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000001875972418.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002069472218.png b/docs/ucs/umn/en-us_image_0000002069472218.png
new file mode 100644
index 000000000..1381b2316
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002069472218.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002202216004.png b/docs/ucs/umn/en-us_image_0000002202216004.png
new file mode 100644
index 000000000..c6555a20c
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002202216004.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002216023866.png b/docs/ucs/umn/en-us_image_0000002216023866.png
new file mode 100644
index 000000000..dc140c40b
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002216023866.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002216024982.png b/docs/ucs/umn/en-us_image_0000002216024982.png
new file mode 100644
index 000000000..71da0c98e
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002216024982.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002225124869.png b/docs/ucs/umn/en-us_image_0000002225124869.png
new file mode 100644
index 000000000..8cd94cead
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002225124869.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002228613109.png b/docs/ucs/umn/en-us_image_0000002228613109.png
new file mode 100644
index 000000000..35845e128
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002228613109.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002237255937.png b/docs/ucs/umn/en-us_image_0000002237255937.png
new file mode 100644
index 000000000..5c02d495c
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002237255937.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002240667777.png b/docs/ucs/umn/en-us_image_0000002240667777.png
new file mode 100644
index 000000000..8a2e5222d
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002240667777.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002250985213.png b/docs/ucs/umn/en-us_image_0000002250985213.png
new file mode 100644
index 000000000..9de0411a4
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002250985213.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002251004289.png b/docs/ucs/umn/en-us_image_0000002251004289.png
new file mode 100644
index 000000000..9907df0a3
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002251004289.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002251008065.png b/docs/ucs/umn/en-us_image_0000002251008065.png
new file mode 100644
index 000000000..7731229d9
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002251008065.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002251339337.png b/docs/ucs/umn/en-us_image_0000002251339337.png
new file mode 100644
index 000000000..f495d0c3f
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002251339337.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002269702534.png b/docs/ucs/umn/en-us_image_0000002269702534.png
new file mode 100644
index 000000000..4775ef3af
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002269702534.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002304425873.png b/docs/ucs/umn/en-us_image_0000002304425873.png
new file mode 100644
index 000000000..d05af6832
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002304425873.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002304604953.png b/docs/ucs/umn/en-us_image_0000002304604953.png
new file mode 100644
index 000000000..e7eeda14d
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002304604953.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002306426742.png b/docs/ucs/umn/en-us_image_0000002306426742.png
new file mode 100644
index 000000000..dcf765184
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002306426742.png differ
diff --git a/docs/ucs/umn/en-us_image_0000002471229772.png b/docs/ucs/umn/en-us_image_0000002471229772.png
new file mode 100644
index 000000000..595d308a8
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0000002471229772.png differ
diff --git a/docs/ucs/umn/en-us_image_0262051194.png b/docs/ucs/umn/en-us_image_0262051194.png
new file mode 100644
index 000000000..5eb51260f
Binary files /dev/null and b/docs/ucs/umn/en-us_image_0262051194.png differ
diff --git a/docs/ucs/umn/public_sys-resources/caution_3.0-en-us.png b/docs/ucs/umn/public_sys-resources/caution_3.0-en-us.png
new file mode 100644
index 000000000..60f607621
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/caution_3.0-en-us.png differ
diff --git a/docs/ucs/umn/public_sys-resources/danger_3.0-en-us.png b/docs/ucs/umn/public_sys-resources/danger_3.0-en-us.png
new file mode 100644
index 000000000..47a9c7235
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/danger_3.0-en-us.png differ
diff --git a/docs/ucs/umn/public_sys-resources/delta.gif b/docs/ucs/umn/public_sys-resources/delta.gif
new file mode 100644
index 000000000..0d1b1f674
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/delta.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/deltaend.gif b/docs/ucs/umn/public_sys-resources/deltaend.gif
new file mode 100644
index 000000000..cc7da0fc8
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/deltaend.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-arrowdn.gif b/docs/ucs/umn/public_sys-resources/icon-arrowdn.gif
new file mode 100644
index 000000000..379428032
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-arrowdn.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-arrowrt.gif b/docs/ucs/umn/public_sys-resources/icon-arrowrt.gif
new file mode 100644
index 000000000..6aaaa11c2
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-arrowrt.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-caution.gif b/docs/ucs/umn/public_sys-resources/icon-caution.gif
new file mode 100644
index 000000000..079c79b26
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-caution.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-danger.gif b/docs/ucs/umn/public_sys-resources/icon-danger.gif
new file mode 100644
index 000000000..079c79b26
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-danger.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-huawei.gif b/docs/ucs/umn/public_sys-resources/icon-huawei.gif
new file mode 100644
index 000000000..a31d60f89
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-huawei.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-note.gif b/docs/ucs/umn/public_sys-resources/icon-note.gif
new file mode 100644
index 000000000..31be2b039
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-note.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-notice.gif b/docs/ucs/umn/public_sys-resources/icon-notice.gif
new file mode 100644
index 000000000..409070650
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-notice.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-tip.gif b/docs/ucs/umn/public_sys-resources/icon-tip.gif
new file mode 100644
index 000000000..c47bae05c
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-tip.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/icon-warning.gif b/docs/ucs/umn/public_sys-resources/icon-warning.gif
new file mode 100644
index 000000000..079c79b26
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/icon-warning.gif differ
diff --git a/docs/ucs/umn/public_sys-resources/note_3.0-en-us.png b/docs/ucs/umn/public_sys-resources/note_3.0-en-us.png
new file mode 100644
index 000000000..57a0e1f53
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/note_3.0-en-us.png differ
diff --git a/docs/ucs/umn/public_sys-resources/notice_3.0-en-us.png b/docs/ucs/umn/public_sys-resources/notice_3.0-en-us.png
new file mode 100644
index 000000000..fa4b64990
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/notice_3.0-en-us.png differ
diff --git a/docs/ucs/umn/public_sys-resources/warning_3.0-en-us.png b/docs/ucs/umn/public_sys-resources/warning_3.0-en-us.png
new file mode 100644
index 000000000..def5c3565
Binary files /dev/null and b/docs/ucs/umn/public_sys-resources/warning_3.0-en-us.png differ
diff --git a/docs/ucs/umn/ucs_01_0002.html b/docs/ucs/umn/ucs_01_0002.html
new file mode 100644
index 000000000..e16a8683d
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0002.html
@@ -0,0 +1,19 @@
+
+
+Attached Clusters
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0003.html b/docs/ucs/umn/ucs_01_0003.html
new file mode 100644
index 000000000..8c03b6565
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0003.html
@@ -0,0 +1,15 @@
+
+
+Fleets
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0004.html b/docs/ucs/umn/ucs_01_0004.html
new file mode 100644
index 000000000..da96d5f1b
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0004.html
@@ -0,0 +1,35 @@
+
+
+Managing Fleets
+This section describes how to create a fleet, add clusters to the fleet, adding a permission policy for the fleet, remove clusters from the fleet, unregister clusters from the fleet, and delete the fleet.
+
Creating a Fleet
- Log in to the UCS console. In the navigation pane, choose Fleets. On the Fleets tab, click Create Fleet.
- Enter the fleet information.
- Fleet Name: Enter a name, starting with a lowercase letter and not ending with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
- Add Cluster: Clusters not in the fleet are displayed in the list. You can add clusters when creating a fleet or after the fleet is created. If you do not select any cluster, an empty fleet will be created. After the fleet is created, see Adding a Cluster.
- Description: description of the fleet to which the cluster is added
+
A registered cluster will follow the fleet permissions policies, not its own ones.
+
- Click OK.
+
+
Adding a Cluster
- Log in to the UCS console. In the navigation pane, choose Fleets.
- In the card view of the target fleet, click Add Cluster, or click
in the upper right corner.You can also click the fleet name to access the fleet console. In the navigation pane, choose Container Clusters. On the displayed page, click Add Cluster in the upper right corner.
+ - Select one or more existing clusters. A cluster can only be added to one fleet. The clusters displayed in the list are those that do not been added to any fleet.
- Only clusters not added to a fleet can be added. To add a cluster from another fleet, remove the cluster from that fleet first.
- After a cluster is added to a fleet, the cluster will follow the fleet permission policies, not its own ones.
+
+ - Click OK.
+
+
Adding Permissions
- Log in to the UCS console. In the navigation pane, choose Permissions.
- Select a cluster or fleet for which you want to add permissions from the drop-down list on the right.
- Click Add Permission in the upper right corner.
- In the window that slides from the right, confirm the cluster or fleet name, set Namespace (for example, select All namespaces), select the target user or user group, and set Permission Type.
- User/User Group: A user group can contain multiple users, and a user can be added to multiple user groups. A user has all the permissions of the user group that the user belongs to.
- Namespace: You can select All namespaces or other namespaces. All namespaces includes the existing namespace of the fleet and the namespace to be added to the fleet. If you select this option, you cannot select other namespaces. If you do not select this option, UCS provides several common namespaces, such as default, kube-system, and kube-public. You can also add a namespace, which should exist in the cluster.
+ - Click OK.
Figure 1 Adding permissions for a fleet
+
+
+
+
Removing a Cluster from a Fleet
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the fleet name to access the fleet console.
- In the navigation pane, choose Container Clusters. In the card view of the target cluster, click
in the upper right corner. - Read the precautions carefully and confirm the risks. Then click OK.
After a cluster is removed from a fleet, it is displayed on the Clusters Not in Fleet tab. You can add the cluster to the fleet again. For details, see Managing Clusters Not in the Fleet.
+
+
+
Unregistering a Cluster from a Fleet
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the fleet name to access the fleet console.
- In the navigation pane, choose Container Clusters. In the card view of the target cluster, click
in the upper right corner. - In the Unregister Cluster dialog box, read the precautions carefully, confirm the risks, and click OK.
- (Optional) After an attached cluster is unregistered, run the following command to uninstall the agent component from the destination cluster:
kubectl -n kube-system delete deployments/proxy-agent secret/proxy-agent-cert
+
+
+
Deleting a Fleet
If a fleet is no longer used, you can delete it. There are two restrictions on deletion: there is no cluster in the fleet and cluster federation has been disabled for the fleet. If there are clusters in the fleet, you can remove the clusters from the fleet and then add them to another fleet. If cluster federation has been enabled for the fleet, disable it following Disabling Cluster Federation.
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, locate the target fleet and click
in the upper right corner. - In the dialog box displayed, click OK.
+
+
Registering an Attached Cluster (Public Network Access)
+This section describes how to register an attached cluster and connect it to UCS over a public network.
+
Constraints
- The OTC account must have the UCS FullAccess and VPCEndpoint Administrator permissions.
+
- If you are connecting a foreign cluster to UCS, ensure that this connection and the subsequent actions you will take comply with the local laws and regulations.
- Ensure that your Kubernetes cluster has passed the CNCF Certified Kubernetes Conformance Program and the cluster version is 1.19 or later.
+
+
Prerequisites
- A cluster has been created and is running normally.
- The node where the proxy-agent component is deployed must be accessible from the public network through an EIP or a NAT gateway.
- You have obtained the kubeconfig file of the cluster to be added. The procedure varies depending on the vendor. For details about the kubeconfig file, see Organizing Cluster Access Using kubeconfig Files.
+
+
Registering a Cluster
- Log in to the UCS console.
- In the navigation pane, choose Fleets. In the card view of Attached clusters, click Register Cluster.
- Configure the cluster parameters listed in Table 1. The parameters marked with an asterisk (*) are mandatory.
+
Table 1 Basic information for registering a clusterParameter
+ |
+Description
+ |
+
|---|
+
+* Cluster Name
+ |
+Enter a name, starting with a lowercase letter and not ending with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
+ |
+
+* Service Provider
+ |
+Select a cluster service provider.
+ |
+
+* Region
+ |
+Select a region where the cluster is deployed.
+ |
+
+Cluster Label
+ |
+Optional. You can add labels in the form of key-value pairs to classify clusters. A key or value can contain a maximum of 63 characters starting and ending with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed.
+ |
+
+* kubeconfig
+ |
+Upload the kubectl configuration file to complete cluster authentication. The file can be in JSON or YAML format. The procedure for obtaining the kubeconfig file varies depending on the vendor.
+ |
+
+* Context
+ |
+Select the corresponding context. After the kubeconfig file is uploaded, the option list automatically obtains the contexts field from the file.
+The default value is the context specified by the current-context field in the kubeconfig file. If the file does not contain this field, you need to manually select a context from the list.
+ |
+
+Fleets
+ |
+Select the fleet that the cluster belongs to.
+A cluster can be added to only one fleet. Fleets are used for fine-grained access management. If you do not select a fleet, the cluster will be displayed on the Clusters Not in Fleet tab upon registration. You can add it to a fleet later.
+When registering a cluster, you cannot select a fleet with cluster federation enabled. To add your cluster to the fleet with cluster federation enabled, register your cluster with UCS first. For details about cluster federation, see Enabling Cluster Federation.
+For details about how to create a fleet, see Managing Fleets.
+ |
+
+
+
+
- Click OK. Connect the cluster to the network within 30 minutes. You can choose either the public or the private network access mode. For details about the network connection process, click
in the upper right corner.If the cluster is not connected to UCS within 30 minutes, it will fail to be registered. In this case, click 
in the upper right corner to register it again. If the cluster has been connected to UCS but no data is displayed, wait for 2 minutes and refresh the cluster.
+
+
+
Connecting the Cluster to UCS
After the cluster is registered with UCS, its status is Pending connection. In this case, the network connection between UCS and the cluster is not established. You need to configure a network agent in the cluster.
+
- Log in to the UCS console.
- Click Public access in the row of the target cluster to download the configuration file of the cluster agent.
The configuration file contains private keys and can be downloaded only once. Keep the file secure.
+
+ - Use kubectl to connect to the cluster, run the following command to create a YAML file named agent.yaml (which can be changed as needed) in the cluster, and copy the agent configuration in 2 and paste it to the YAML file:
vim agent.yaml
+ - Run the following command in the cluster to deploy the agent:
kubectl apply -f agent.yaml
+ - Check the deployment of the cluster agent.
kubectl -n kube-system get pod | grep proxy-agent
+If the deployment is successful, the expected output is:
+proxy-agent-5f7d568f6-6fc4k 1/1 Running 0 9s
+ - Check the status of the cluster agent.
kubectl -n kube-system logs <Agent Pod Name> | grep "Start serving"
+If the cluster agent is running normally, the expected log output is:
+Start serving
+ - Go to the UCS console and refresh the cluster status. The cluster is in the Running state.
+
+
Registering an Attached Cluster (Private Network Access)
+Connecting attached clusters located in on-premises data centers or third-party clouds to UCS over public networks may cause security risks. To ensure stability and security, you can use private networks to connect the clusters to UCS for management.
+
The private network features high speed, low latency, and security. After you connect the on-premises network or the private network of a third-party cloud to the cloud network over Direct Connect or VPN, you can use a VPC endpoint to access UCS over the private network.
+
+
Prerequisites
- A cluster has been created and is running normally.
- A VPC has been created in the region where UCS is available. For details, see Creating a VPC.
The subnet CIDR block of the VPC cannot overlap with the subnet CIDR block of the on-premises data center or third-party cloud. If the CIDR blocks overlap, the cluster cannot be connected to UCS. For example, if the subnet CIDR block of an on-premises data center is 192.168.1.0/24, the subnet CIDR block of the OTC VPC cannot be 192.168.1.0/24.
+
+ - You have obtained the kubeconfig file of the cluster to be added. The procedure varies depending on the vendor. For details about the kubeconfig file, see Organizing Cluster Access Using kubeconfig Files.
+
+
Preparing the Network Environment
After the on-premises network or the private network of the third-party cloud and the cloud network are connected, you are advised to ping the private IP address of a OTC server in the target VPC from an on-premises server or a server of the third-party cloud to check network connectivity.
+
+
Connect the on-premises data center or the third-party cloud to the OTC VPC.
+
+
+
Registering a Cluster
- Log in to the UCS console.
- In the navigation pane, choose Fleets. In the card view of Attached clusters, click Register Cluster.
- Configure the cluster parameters listed in Table 1. The parameters marked with an asterisk (*) are mandatory.
+
Table 1 Basic information for registering a clusterParameter
+ |
+Description
+ |
+
|---|
+
+* Cluster Name
+ |
+Enter a name, starting with a lowercase letter and not ending with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
+ |
+
+* Service Provider
+ |
+Select a cluster service provider.
+ |
+
+* Region
+ |
+Select a region where the cluster is deployed.
+ |
+
+Cluster Label
+ |
+Optional. You can add labels in the form of key-value pairs to classify clusters. A key or value can contain a maximum of 63 characters starting and ending with a letter or digit. Only letters, digits, hyphens (-), underscores (_), and periods (.) are allowed.
+ |
+
+* kubeconfig
+ |
+Upload the kubectl configuration file to complete cluster authentication. The file can be in JSON or YAML format. The procedure for obtaining the kubeconfig file varies depending on the vendor.
+ |
+
+* Context
+ |
+Select the corresponding context. After the kubeconfig file is uploaded, the option list automatically obtains the contexts field from the file.
+The default value is the context specified by the current-context field in the kubeconfig file. If the file does not contain this field, you need to manually select a context from the list.
+ |
+
+Fleets
+ |
+Select the fleet that the cluster belongs to.
+A cluster can be added to only one fleet. Fleets are used for fine-grained access management. If you do not select a fleet, the cluster will be displayed on the Clusters Not in Fleet tab upon registration. You can add it to a fleet later.
+When registering a cluster, you cannot select a fleet with cluster federation enabled. To add your cluster to the fleet with cluster federation enabled, register your cluster with UCS first. For details about cluster federation, see Enabling Cluster Federation.
+For details about how to create a fleet, see Managing Fleets.
+ |
+
+
+
+
- Click OK. Connect the cluster to the network within 30 minutes. You can choose either the public or the private network access mode. For details about the network connection process, click in the upper right corner.
If the cluster is not connected to UCS within 30 minutes, it will fail to be registered. In this case, click in the upper right corner to register it again. If the cluster has been connected to UCS but no data is displayed, wait for 2 minutes and refresh the cluster.
+
+
+
Buying a VPC Endpoint
- Log in to the UCS console and click Click to connect in the card view of the cluster. In the window that slides out from the right, select Private access.
- In Create a VPC endpoint, click
to record the service name. - Log in to the VPC Endpoint console and click VPC Endpoint to create a VPC endpoint for each service.
- Select the region that the VPC endpoint belongs to.
- Select Find a service by name, enter the service name recorded in 2, and click Verify.
- Select the VPC and subnet connected to the cluster network in Preparing the Network Environment.
- Select Automatically assign IP address or Manually specify IP address for assigning the private IP address of the VPC endpoint.
- Configure other parameters, click Create Now, and confirm the specifications.
- If the configuration is correct, click Submit.
- If any of the configurations is incorrect, click Previous to modify the parameters as needed, and click Next > Submit.
+
+
+
Connecting to a Cluster
- Log in to the UCS console. In the card view of the target cluster in the Pending connection status, click Private access.
- Select the VPC endpoint created in Buying a VPC Endpoint.
- Upload the agent configuration file in 2 to the node.
- Click Configure Cluster Access and run commands in the cluster. You can click
on the right to copy each command.
+ - For clusters that are connected to UCS over a private network, images cannot be downloaded from SWR. Ensure that your nodes where your workloads run can access the public network.
- To pull the proxy-agent container image, the cluster must be able to access the public network, or the image can be uploaded to an image repository that can be accessed by the cluster. Otherwise, the image will fail to be deployed.
+
+ - Go to the UCS console and refresh the cluster status. The cluster is in the Running state.
+
+
Single-Cluster Management
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0008.html b/docs/ucs/umn/ucs_01_0008.html
new file mode 100644
index 000000000..ecb27ca2f
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0008.html
@@ -0,0 +1,14 @@
+
+
+Overview
+Fleets
A fleet contains multiple clusters. You can use fleets to classify associated clusters. You can also use a fleet for the unified management of multiple clusters, including permissions management, security policy configuration, configuration management, and multi-cluster orchestration.
+
+
Constraints
- Only and users with the UCS FullAccess permissions can create and delete fleets.
- A cluster can be added to only one fleet.
+
+
Permissions
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0010.html b/docs/ucs/umn/ucs_01_0010.html
new file mode 100644
index 000000000..44569e796
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0010.html
@@ -0,0 +1,86 @@
+
+
+UCS Permissions
+UCS permissions management allows you to grant permissions to IAM users and user groups under your tenant accounts. UCS combines the advantages of IAM and Kubernetes RBAC to provide a variety of authorization methods, including IAM fine-grained and token authorization and cluster-, fleet-, cluster namespace–, and fleet namespace–level authorization.
+
UCS allows you to manage permissions on related resources at a finer granularity, for example, to control the access of employees in different departments to cloud resources.
+
This section describes the UCS permissions management mechanism and related concepts. If your account has met your service requirements, you can skip the configurations in this section.
+
+
Figure 1 Permissions design
+
UCS Permissions Management
UCS permissions management involves UCS resource permissions and Kubernetes resource permissions in a cluster.
+
- UCS resource permissions are based on IAM system-defined policies and include cluster-level permissions and fleet-level permissions.
- Kubernetes resource permissions in a cluster are based on Kubernetes RBAC and include cluster namespace-level permissions and fleet namespace-level permissions.
+
UCS permissions are described as follows:
+
- Cluster-level permissions: You can grant cluster-level permissions to allow some user groups to perform operations on clusters (such as registering and deregistering clusters and managing cluster add-ons) and allow some user groups to only view clusters.
+
- Fleet-level permissions: You can grant fleet-level permissions to allow some user groups to perform operations on fleets (such as creating and deleting fleets, adding clusters to fleets, and deleting clusters from fleets) and allow some user groups to only view fleets.
UCS resource permissions involve UCS non-fleet APIs and Kubernetes APIs and support fine-grained IAM policies and enterprise project management. Fleet-level permissions are configured for flee-related resources (such as fleets and federations), and cluster-level permissions are configured for cluster-related resources (such as clusters and nodes). You must also configure namespace-level permissions to perform operations on fleet resources and Kubernetes resources (such as workloads, Services, and routes). Fleet-level permissions and cluster-level permissions are independent of each other.
+
+
- Cluster namespace-level permissions: You can regulate users' or user groups' access to Kubernetes resources (such as workloads, jobs, Services, and other native Kubernetes resources) based on their Kubernetes RBAC roles.
+
- Fleet namespace-level permissions: You can regulate users' or user groups' access to fleet resources (such as workloads, Services, MCI, distribution policies, and other native fleet resources) based on their fleet RBAC roles.
Kubernetes resource permissions in a cluster involve UCS Kubernetes APIs and are enhanced based on the Kubernetes RBAC capabilities. These permissions can be granted to IAM users or user groups for authentication and authorization, but are independent of fine-grained IAM policies.
+In general, you can configure UCS permissions in two scenarios. The first is creating and managing clusters and fleets, as well as their related resources, such as nodes. The second is using Kubernetes resources in a cluster and fleet resources, such as workloads and Services.
+Figure 2 Illustration on UCS permissions
+
+
+
UCS Resource Permissions (IAM-based) and Kubernetes Resource Permissions in a Cluster (Kubernetes RBAC-based)
Users with different UCS resource permissions have different Kubernetes resource permissions in a cluster. Table 1 describes the Kubernetes resource permissions in a cluster for different users.
+
+
Table 1 Kubernetes resource permissions in a cluster for different usersUser Type
+ |
+UCS Resource Permissions
+ |
+Kubernetes Resource Permissions in a Cluster
+ |
+
|---|
+
+Users with the Tenant Administrator or UCS FullAccess permissions
+ |
+Operation permissions for Clusters, Fleets, Add-ons, Policy Center, Configuration Management, Traffic Distribution, and Container Intelligent Analysis
+ |
+All namespace permissions
+ NOTE: UCS FullAccess does not have the RBAC permissions of CCE clusters. You need to go to the Permissions page to grant permissions for CCE clusters.
+
+ |
+
+Users with the UCS CommonOperations permissions
+ |
+Read-only permissions for Clusters, Fleets, Traffic Distribution, Add-ons, Policy Center, and Configuration Management
+ |
+RBAC authorization
+ |
+
+IAM users with the UCS ReadOnlyAccess permissions
+ |
+Read-only permissions on UCS resources
+ |
+RBAC authorization
+ |
+
+IAM users with the UCS CIAOperations permissions
+ |
+Operation permissions for Container Intelligent Analysis instances on UCS
+ |
+RBAC authorization
+ |
+
+IAM users with the Tenant Guest permissions
+ |
+Read-only permissions on UCS resources
+ |
+RBAC authorization
+ |
+
+
+
+
+
+
Permissions management flow
The following figure shows the permissions management flow of a new IAM user.
+
Figure 3 Permissions management flow
+
+
Basic Concepts
Figure 4 shows the relationships between the following basic concepts:
+
- User: You can use your administrator account to create IAM users and grant permissions on specific resources. Each IAM user has their own identity credentials (password and access keys) and uses cloud resources based on granted permissions.
- User group: You can use user groups to grant permissions to IAM users. IAM users added to a user group automatically obtain the permissions granted to the group. For example, after the administrator grants the UCS FullAccess permissions to a user group, users in the user group have the administrator permissions of UCS. If a user is added to multiple user groups, the user inherits the permissions granted to all these groups.
- Namespace: A namespace is a collection of resources and objects. You can create multiple namespaces in the same cluster. Data is isolated by namespace so that multiple namespaces can share the services of the same cluster without any interference with each other. For example, you can deploy workloads in a development environment into one namespace, and deploy workloads in a testing environment into another namespace.
- Permission types: The UCS administrator defines the scope of operations performed by one or more users on Kubernetes resources in a cluster. There are several common permission types on UCS, including Administrator, O&M, Developer, and Viewer. You can also create custom permissions. For details, see .
- Fleet: A fleet contains multiple clusters. An administrator can use fleets to classify associated clusters. An administrator can also use a fleet for the unified management of multiple clusters, including permissions management, security policy configuration, configuration management, and multi-cluster orchestration.
+
Figure 4 Permission relationships
+
+
Kubernetes Resource Permissions in a Cluster (Kubernetes RBAC-based)
+You can regulate users' or user groups' access to Kubernetes resources based on their Kubernetes RBAC roles. The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding, which are described as follows:
+
- Role: defines a set of rules for accessing Kubernetes resources in a namespace.
- RoleBinding: defines the relationship between users and roles.
- ClusterRole: defines a set of rules for accessing Kubernetes resources in a cluster (including all namespaces).
- ClusterRoleBinding: defines the relationship between users and cluster roles.
+
Role and ClusterRole specify actions that can be performed on specific resources. RoleBinding and ClusterRoleBinding bind roles to specific users, user groups, or ServiceAccounts, as shown in the following figure.
+
Figure 1 Role binding
+
On the UCS console, you can grant permissions to a user or user group to access resources in one or multiple namespaces. By default, the UCS console provides the following ClusterRoles:
- view (viewer): RBAC read-only permissions on most Kubernetes resources in all or selected namespaces.
- edit (developer): RBAC read and write permissions on most Kubernetes resources in all or selected namespaces.
- admin (O&M): RBAC read and write permissions on most Kubernetes resources in all namespaces, and read-only permissions on nodes, PVs, namespaces, and resource quotas.
- cluster-admin (administrator): RBAC read and write permissions on Kubernetes resources in all namespaces, as well as read and write permissions on nodes, PVs, namespaces, and resource quotas.
+
+
In addition to the preceding typical ClusterRoles, you can define Role and RoleBinding to grant the permissions to add, delete, modify, and obtain global resources (such as nodes, PVs, and CustomResourceDefinitions) and different resources (such as pods, Deployments, and Services) in namespaces for refined permission control.
+
Precautions
- After you create a cluster or fleet, UCS automatically assigns the cluster-admin permissions to you, which means you have full control on all resources and all namespaces in this cluster or fleet. The ID of a federated user changes upon each login and logout. Therefore, the user with the permissions is displayed as deleted. In this case, do not delete the permissions. Otherwise, the authentication fails. You are advised to grant the cluster-admin permissions to a user group on UCS and add federated users to the user group.
- Users with the Security Administrator role have all IAM permissions except role switching. For example, an account in the admin user group has this role by default. Only these users can grant permissions on the Permissions page on the UCS console.
+
+
Adding Resource Permissions (on the Console)
The cluster for which the permissions will be added must be in the running state, and the cluster federation must be enabled for the fleet.
+
+
You can regulate users' or user groups' access to Kubernetes resources based on their Kubernetes RBAC roles.
+
- Log in to the UCS console. In the navigation pane, choose Permissions.
- Select a cluster or fleet for which you want to add permissions from the drop-down list on the right.
- In the upper right corner, click Add Permission.
- In the window that slides from the right, confirm the cluster or fleet name, set Namespace (for example, select All namespaces), select the target user or user group, and set Permission Type.
If you do not have IAM permissions, you cannot select users or user groups when configuring permissions for other users or user groups. In this case, you can enter a user ID or user group ID.
+
+
+
+Table 1 Permission typesPermission Type
+ |
+Permissions
+ |
+
|---|
+
+Administrator
+ |
+RBAC read and write permissions on Kubernetes resources in all namespaces, as well as read and write permissions on nodes, PVs, namespaces, and resource quotas.
+ NOTICE: UCS FullAccess does not have the RBAC permissions of CCE clusters. You need to go to the Permissions page to grant permissions for CCE clusters.
+
+ |
+
+O&M
+ |
+RBAC read and write permissions on most Kubernetes resources in all namespaces, and read-only permissions on nodes, PVs, namespaces, and resource quotas.
+ |
+
+Developer
+ |
+RBAC read and write permissions on most Kubernetes resources in all or selected namespaces.
+ |
+
+Viewer
+ |
+RBAC read-only permissions on most Kubernetes resources in all or selected namespaces.
+ |
+
+Custom
+ |
+The permissions are determined by the selected ClusterRole or Role. Before granting these permissions, ensure that the selected ClusterRole or Role has the required permissions on the resources.
+ |
+
+
+
+
You can create custom permissions as required. After selecting Custom for Permission Type, click Add Custom Role on the right of the Custom parameter. In the window that slides from the right, enter a name and select a rule. After the custom rule is created, you can select a value from the Custom drop-down list.
+Custom permissions are classified into ClusterRoles and Roles. Each ClusterRole or Role contains a group of rules that represent related permissions. For details, see Using RBAC Authorization.
+- ClusterRole: a cluster-level resource that can be used to configure cluster access permissions.
- Role: used to configure access permissions in a namespace. When creating a Role, specify the namespace that the Role belongs to.
+
+ - Click OK.
+
+
Configuring Kubernetes Resource Permissions in a Cluster (Using kubectl)
+
In addition to cluster-admin, admin, edit, and view, you can define Roles and RoleBindings to configure the permissions to add, delete, modify, and obtain resources, such as pods, Deployments, and Services, in the namespace.
+
The definition of a Role is simple. You just specify a namespace and some rules. For example, the following rules allow you to perform GET and LIST operations on pods in the default namespace.
+
kind: Role
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+ namespace: default # Namespace
+ name: role-example
+rules:
+- apiGroups: [""]
+ resources: ["pods"] # The pod can be accessed.
+ verbs: ["get", "list"] # The GET and LIST operations can be performed.
+
- apiGroups indicates the API group that the resource belongs to.
- resources indicates the resources that can be operated. Pods, Deployments, ConfigMaps, and other Kubernetes resources are supported.
- verbs indicates the operations that can be performed. get indicates querying a specific object, and list indicates listing all objects of a certain type. You can also select other value options such as create, update, and delete.
+
For details, see Using RBAC Authorization.
+
After creating a Role, you can bind the Role to a specific user. This is called RoleBinding. The following shows an example:
+
kind: RoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+ name: RoleBinding-example
+ namespace: default
+ annotations:
+ CCE.com/IAM: 'true' # This annotation is required only for CCE clusters.
+roleRef:
+ kind: Role
+ name: role-example
+ apiGroup: rbac.authorization.k8s.io
+subjects:
+- kind: User
+ name: 0c97ac3cb280f4d91fa7c0096739e1f8 # User ID of user-example
+ apiGroup: rbac.authorization.k8s.io
+
The subjects section binds a Role with an IAM user so that the IAM user can obtain the permissions defined in the Role, like in the following figure.
+
Figure 2 Binding a Role to a user
+
You can also specify a user group in the subjects section. In this case, all users in the user group obtain the permissions defined in the Role.
+
subjects:
+- kind: Group
+ name: 0c96fad22880f32a3f84c009862af6f7 # User group ID
+ apiGroup: rbac.authorization.k8s.io
+
Use the IAM user user-example to connect to the cluster and obtain the pod information. The following is an example of the returned pod information.
+
# kubectl get pod
+NAME READY STATUS RESTARTS AGE
+deployment-389584-2-6f6bd4c574-2n9rk 1/1 Running 0 4d7h
+deployment-389584-2-6f6bd4c574-7s5qw 1/1 Running 0 4d7h
+deployment-3895841-746b97b455-86g77 1/1 Running 0 4d7h
+deployment-3895841-746b97b455-twvpn 1/1 Running 0 4d7h
+nginx-658dff48ff-7rkph 1/1 Running 0 4d9h
+nginx-658dff48ff-njdhj 1/1 Running 0 4d9h
+# kubectl get pod nginx-658dff48ff-7rkph
+NAME READY STATUS RESTARTS AGE
+nginx-658dff48ff-7rkph 1/1 Running 0 4d9h
+
Try querying Deployments and Services in the namespace. The output shows that user-example does not have the required permissions. Try querying the pods in the kube-system namespace. The output shows that user-example does not have the required permissions. This indicates that the IAM user user-example has only the GET and LIST Pod permissions in the default namespace, which is the same as expected.
+
# kubectl get deploy
+Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default"
+# kubectl get svc
+Error from server (Forbidden): services is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "services" in API group "" in the namespace "default"
+# kubectl get pod --namespace=kube-system
+Error from server (Forbidden): pods is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "pods" in API group "" in the namespace "kube-system"
+
+
Example: Granting Service Resource Administrator Permissions (cluster-admin)
The cluster-admin role has read and write permissions on all resources in all namespaces.
+
Figure 3 Granting cluster administrator permissions (cluster-admin)
+
+
+
Figure 4 Granting fleet administrator permissions (cluster-admin)
+
+
+
+
Example: Granting Namespace O&M Permissions (admin)
The admin role has the read and write permissions on most namespace resources. You can grant the admin permissions on all namespaces to a user or user group.
+
Figure 5 Granting O&M permissions (admin) on all namespaces of a cluster
+
+
+
Figure 6 Granting O&M permissions (admin) on all namespaces of a fleet
+
+
+
+
Example: Granting Namespace Developer Permissions (edit)
The edit role has the read and write permissions on most namespace resources. You can grant the edit permissions on all namespaces to a user or user group.
+
+
Figure 7 Granting developer permissions (edit) on the default namespace of a fleet
+
+
+
Example: Granting Read-Only Namespace Permissions (view)
The view role has the read-only namespace permissions. You can grant permissions to users to view one, multiple, or all namespaces.
+
Figure 8 Granting read-only permissions (view) on multiple namespaces of a cluster
+
+
+
+
When adding permissions, you can select multiple namespaces. However, if you select all namespaces, you cannot select other namespaces.
+
+
+
+
+
+
Kubernetes Resource Objects
+By their application scope, Kubernetes resource objects can be categorized into namespace objects or cluster objects.
+
Namespace Level
Namespace is an isolation mechanism of Kubernetes and is used to categorize, filter, and manage any resource object in a cluster.
+
If different resource objects are placed in different namespaces, they are isolated from each other. For example, run the following command to obtain all pods:
+
kubectl get pod
+
The pod has a namespace, which defaults to default. To specify a namespace, run the following command:
+
kubectl get pod -n default
+
To obtain pods in all namespaces, run the following command:
+
kubectl get pod --all-namespaces
+
In this way, you can view all pods in the cluster.
+
$ kubectl get pod --all-namespaces
+NAMESPACE NAME READY STATUS RESTARTS AGE
+default nginx-dd9796d66-5chbr 1/1 Running 0 3d1h
+default nginx-dd9796d66-xl69p 1/1 Running 0 15d
+default sa-example 1/1 Running 0 10d
+kube-system coredns-6fcd88c4c-k8rtf 1/1 Running 0 48d
+kube-system coredns-6fcd88c4c-z46p4 1/1 Running 0 48d
+kube-system everest-csi-controller-856f8bb679-42rgw 1/1 Running 1 48d
+kube-system everest-csi-controller-856f8bb679-xs6dz 1/1 Running 0 48d
+kube-system everest-csi-driver-mkpbv 2/2 Running 0 48d
+kube-system everest-csi-driver-v754w 2/2 Running 0 48d
+kube-system icagent-5p44q 1/1 Running 0 48d
+kube-system icagent-jrlbl 1/1 Running 0 48d
+monitoring alertmanager-alertmanager-0 2/2 Running 0 29d
+monitoring cluster-problem-detector-7788f94f64-thp6s 1/1 Running 0 29d
+monitoring custom-metrics-apiserver-5f7dcf6d9-n5nrr 1/1 Running 0 19d
+monitoring event-exporter-6844c5c685-khf5t 1/1 Running 1 3d1h
+monitoring kube-state-metrics-8566d5f5c5-7kx7b 1/1 Running 0 29d
+monitoring node-exporter-7l4ml 1/1 Running 0 29d
+monitoring node-exporter-gpxvl 1/1 Running 0 29d
+
Pods are namespace objects. Most workload resources, Service resources, and config and storage are also namespace objects.
+
- Workload resources
Pod: the smallest and simplest unit in the Kubernetes object model that you create or deploy.
+ReplicaSet: a backup controller in Kubernetes. It is used to control the managed pods so that the number of pod replicas remains the preset one.
+Deployment: declares the pod template and controls the pod running policy. It is applicable to the deployment of stateless applications.
+StatefulSet: manages stateful applications. Created pods have persistent identifiers created based on specifications.
+DaemonSet: used to deploy background programs in the resident cluster, for example, node log collection.
+Job: The job controller creates one or more pods. These pods run according to the running rules until the running is complete.
+CronJob: periodically runs a job based on a specified schedule.
+ - Service resources
Service: Containers deployed in Kubernetes provide Layer-7 network services using HTTP and HTTPS, and Layer-4 network services using TCP and UDP. Services in Kubernetes are used to manage Layer-4 network access in a cluster. Based on the Layer-4 network, Service exposes the container services in a cluster.
+Ingress: provides Layer-7 network services using HTTP and HTTPS and common Layer-7 network capabilities. An ingress is a set of rules that allow accessing Services in a cluster. You can configure forwarding rules to enable different URLs to access different Services in a cluster.
+ - Config and storage resources
ConfigMap: key-value pair, which is used to decouple configurations from running images so that applications more portable.
+Secret: key-value pair, which is used to store sensitive information such as passwords, tokens, and keys to reduce the risk of direct exposure.
+Volume: A volume is essentially a directory that may contain some data. Containers in a pod can access the directory. A volume will no longer exist if the pod to which it is mounted does not exist. However, files in the volume may outlive the volume, depending on the volume type.
+
+
+
Cluster Level
A cluster resource has a much larger application scope than a namespace resource. It is visible to the entire cluster and can be invoked. It does not belong to a certain namespace. Therefore, the name of a resource object must be globally unique.
+
Cluster resources are visible in any namespaces. You do not need to specify a namespace when defining cluster resources.
+
Cluster resources include Namespace, Node, Role, RoleBinding, ClusterRole, and ClusterRoleBinding.
+
+
+
Image Repositories
+UCS integrates OTC SoftWare Repository for Containers (SWR), which provides easy, secure, and reliable management over container images throughout their lifecycles, facilitating the deployment of containerized applications.
+
SWR allows you to securely host and efficiently distribute images on the cloud to smoothly run your services in containers. You do not need to build or maintain image repositories.
+
Features
- Full lifecycle management of images
SWR manages the full lifecycle of your container images, including push, pull, and deletion.
+ - Private image repository
Images can be stored in an SWR private image repository. With the SWR fine-grained permission system, users can be granted with different permissions (read, write, and manage) to access the images.
+ - Automatic deployment update through triggers
Application deployment can be triggered automatically upon image tag update. You only need to set a trigger for the desired image. Every time the image tag is updated, the application deployed with this image will be automatically updated.
+
+
+
Constraints
Attached clusters connected to UCS through a private network cannot download images from SWR. Ensure your clusters can access the public network.
+
+
Pushing the Image
- Log in to the UCS console. In the navigation pane, choose Image Repositories.
- View the basic information about the image repository and click the image repository name to access SWR.
- Push an image to SWR by referring to Uploading an Image Through the Client.
+
+
Using an Image
Clusters and federations managed by UCS allow you to create a workload by pulling an image from the image repository. The following uses the CCE cluster taken over by UCS as an example to shown you how to pull and use an image to create a workload:
+
- Access the cluster console.
- In the navigation pane, choose Workloads and click Create from Image in the upper right corner.
- In the Basic Info area, set workload parameters. Deployment is used as an example.
- Workload Type: Select Deployment.
- Workload Name: The value can be customized.
- Pods: Set this parameter based on service requirements.
- Description: Enter the description of the workload.
- Time Zone Synchronization: Specify whether to enable this function. 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.
+ - In the Container Settings area, click Select Image.
On the My Images tab, select the target image and click OK.
+
+ - Click Create Workload. For details about how to create a workload, see Deployments.
+
+
Creating an Image Secret
When a cluster is created, a secret named default-secret is generated by default, which contains an access credential of SWR. You do not need to create an image secret again.
+
When an attached cluster uses SWR private images, you need to create an image secret to pull SWR images. The procedure is as follows:
+
- Access the cluster console.
- In the navigation pane, choose ConfigMaps and Secrets. Then, click the Secrets tab.
- Click Create Secret and set parameters.
+
Table 1 Parameter descriptionParameter
+ |
+Description
+ |
+
|---|
+
+Name
+ |
+Name of the secret you create, which must be unique.
+ |
+
+Namespace
+ |
+Namespace to which the secret belongs. If you do not specify this parameter, the value default is used by default.
+ |
+
+Description
+ |
+Description of a secret.
+ |
+
+Secret Type
+ |
+Type of the new secret. kubernetes.io/dockerconfigjson stores the authentication information required for pulling images from a private repository.
+ |
+
+Data
+ |
+Enter the username and password of the private image repository. Workload secret data can be used in containers.
+To obtain the username and password when using SWR, perform the following steps:
+- Click the username in the upper right corner, choose My Credentials > Access Keys, and click Create Access Key. You can obtain the AK and SK information from the credentials.csv file downloaded.
The AK/SK file can be downloaded only once. Keep it secure.
+ - Log in to a Linux computer and run the following command to obtain the login key ($AK and $SK are the AK/SK obtained in the previous step.):
printf "$AK" | openssl dgst -binary -sha256 -hmac "$SK" | od -An -vtx1 | sed 's/[ \n]//g' | sed 'N;s/\n//'
+ - The username is Regional project name@AK.
The password is the login key obtained in 2.
+
+ |
+
+Label
+ |
+Label of the secret. Enter a key-value pair and click Add.
+ |
+
+
+
+
+
+
Overview
+Introduction
Cluster federation is a multi-cloud container orchestration capability provided by Karmada. Cluster federation aims to manage multi-cluster applications in cross-cloud and cross-region scenarios, with features such as unified multi-cluster management, application deployment, service discovery, and auto scaling.
+
+
Constraints
Only OTC accounts or users with the UCS FullAccess permissions can enable or disable cluster federation.
+
+
Usage
Figure 1 shows how to use cluster federation.
+
Figure 1 Process of using cluster federation
+
Cluster federation is bound to fleets. To use cluster federation for multi-cluster management, perform the following operations:
+
+
+
Enabling Cluster Federation
+Enabling Cluster Federation
You can enable cluster federation for a fleet with just a few clicks.
+
Enabling cluster federation involves two phases: enabling cluster federation and adding clusters to the federation. Enabling cluster federation for a fleet will federate the registered clusters in the fleet.
+
There is a quota limit for enabling cluster federation, and there are constraints on clusters in a fleet. Before enabling cluster federation, read the following constraints to avoid failures.
+
+
Table 1 Cluster constraintsItem
+ |
+Constraint
+ |
+
|---|
+
+Cluster version
+ |
+The versions of all clusters in the fleet must be 1.19 or later.
+ |
+
+Cluster status
+ |
+All clusters in the fleet must be in the Running status.
+ |
+
+Cluster network
+ |
+- OTC cluster: An EIP must be associated with the cluster.
- Other types of clusters: Ensure that the clusters connect to UCS.
+ |
+
+Quota
+ |
+The cluster federation quota is 1. This means cluster federation can be enabled only for one fleet.
+ |
+
+
+
+
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, locate the target fleet displayed with Federation not enabled. Click Enable.
- In the displayed dialog box, click OK. Then, wait until cluster federation is enabled.
If the clusters in the fleet do not meet the constraints, an error message will be displayed. Modify the clusters as prompted and enable cluster federation again.
+It takes about 10 minutes to enable cluster federation. You can click the federation status to view the detailed enabling progress. After cluster federation is enabled, a message will be displayed.
+
+
+
Adding Clusters
After cluster federation is enabled for a fleet, you can continue to add clusters to the fleet. The new clusters are automatically connected to the federation of the fleet. A federation can have up to 20 clusters.
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- In the card view of the target fleet, click Add Cluster, or click
in the upper right corner.You can also click the fleet name to access the fleet console. In the navigation pane, choose Container Clusters. On the displayed page, click Add Cluster in the upper right corner.
+ - Select one or more existing clusters. A cluster can only be added to one fleet. The clusters displayed in the list are those that do not been added to any fleets.
- Click OK.
+
+
Managing Federation
After cluster federation is enabled for a fleet, the Federation module on the fleet console is automatically unlocked.
+
Next, you can create federated resources such as federated workloads, Services, and storage for deploying your service. You can also perform advanced operations such as multi-active DR and auto scaling for multi-cluster applications.
+
+
Disabling Cluster Federation
If you do not need to use cluster federation, you can disable it. After cluster federation is disabled, services running on the workloads are not affected.
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, locate the target fleet and click Disable Federation in the upper right corner.
- In the displayed dialog box, click OK.
+
+
Configuring Scheduling and Differentiation
+Scheduling Policies
Currently, there are two scheduling policies: cluster weights and automatic balancing.
+
Configuring a Scheduling Policy on the Console
+
- Log in to the UCS console.
- When creating a workload, click Next: Scheduling and Differentiation.
- Add a scheduling policy.
+
Table 1 Scheduling policiesPolicy
+ |
+Description
+ |
+
|---|
+
+Cluster weights
+ |
+You need to select clusters and configure their weights. Pods are allocated to clusters based on the cluster weights.
+ |
+
+Auto balancing
+ |
+The system automatically selects clusters to allocate pods based on the number of remaining pods. No extra configuration is required.
+ |
+
+
+
+
+
+
Calculation Method Based on Cluster Weights
Calculation Method
+
After you set the weight of each cluster, the number of pods allocated to each cluster is calculated as follows:
+
- Formula for calculating the number of pods allocated to each cluster by cluster weight (The calculation result is rounded down.)
Number of pods allocated to each cluster = (Total number of pods × Weight of a cluster)/Total weight of clusters
+ - Formula for calculating the number of remaining pods
Number of remaining pods = Total number of pods - Total number of pods allocated to each cluster
+ - If there are any pods remaining, they will continue to be allocated by cluster weight in ascending order (one pod allocated at a time). If any clusters have the same weight, a cluster will be selected at random.
+
Example
+
There are seven pods that are assigned to three clusters named member1, member2, and member3. The clusters have weights of 2, 1, and 1, respectively.
+
- The number of pods allocated to each cluster is calculated as follows:
Number of pods allocated to member1 = 7 × 2/4 (rounded down to 3)
+Number of pods allocated to member2 = 7 × 1/4 (rounded down to 1)
+Number of pods allocated to member3 = 7 × 1/4 (rounded down to 1)
+In this initial allocation, three pods are allocated to member1, one pod to member2, and one pod to member3.
+ - The number of remaining pods is calculated as follows:
Number of remaining pods = 7 - 3 - 1 - 1 = 2
+ - The remaining pods are allocated by cluster weight in ascending order.
One pod is first allocated to member1 and the remaining pod to member2 or member3 at random.
+
+
+
Tolerance Policies
A tolerance policy allows the scheduler to schedule pods to clusters with corresponding taints. This policy must be used together with cluster taints.
+
+
Using the Default Tolerance Policy
+
When you create a workload, UCS configures a default tolerance policy for your workload. The default tolerance policy adds taints listed in Table 2 to a faulty cluster. If the tolerance duration is exceeded, all pods in the cluster will be automatically evicted.
+
+
Table 2 Taints for faulty clustersTaint Key
+ |
+Tolerance Policy
+ |
+
|---|
+
+cluster.karmada.io/not-ready
+ |
+When the cluster is not ready, this taint is automatically added. If the tolerance duration is exceeded, all pods in the cluster will be automatically evicted.
+ |
+
+cluster.karmada.io/unreachable
+ |
+When the cluster is unavailable, this taint is automatically added. If the tolerance duration is exceeded, all pods in the cluster will be automatically evicted.
+ |
+
+
+
+
+
Configuring a Tolerance Policy on the Console
+
- Log in to the UCS console.
- When creating a workload, click Next: Scheduling and Differentiation.
- Add a tolerance policy.
+
Parameter
+ |
+Description
+ |
+
|---|
+
+Taint Key
+ |
+Taint key of the cluster.
+ |
+
+Operator
+ |
+- Equal: matches the nodes with the specified taint key (mandatory) and value. If the taint value is left blank, all taints with the key the same as the specified taint key will be matched.
- Exists: matches the nodes with the specified taint key. In this case, the taint value cannot be specified. If the taint key is left blank, all taints will be tolerated.
+ |
+
+Taint Value
+ |
+- If the value of Operator is Exists, the value attribute can be omitted.
- If the value of Operator is Equal, the relationship between the key and value is Equal.
- If Operator is not specified, the default value is Equal.
+ |
+
+Taint Policy
+ |
+- All: All taint policies are matched.
- NoSchedule: Only the NoSchedule taint is matched.
+ |
+
+
+
+
+
Overview
+The UCS console allows you to manage each cluster on each cluster console.
+
- For OTC clusters (CCE standard and Turbo clusters), the operations on the cluster console of UCS are the same as those on the cluster console of CCE. For details about CCE cluster management, see CCE User Guide.
- For attached clusters, the cluster console allows you to manage basic Kubernetes resources, such as nodes, workloads, Services and ingresses, container storage, ConfigMaps and secrets, and namespaces.
For attached clusters, you need to log in to the UCS console with a OTC account or as a user who has the UCS FullAccess permissions to add permissions on the Permissions page.
+
+
+
Accessing the Cluster Console
The method for accessing the cluster console varies according to whether a cluster has been added to a fleet. The details are as follows:
+
- Cluster in fleet: On the Fleets page, click the Fleets tab and click the name of the target fleet. In the navigation pane, choose Container Clusters. Then, click the cluster name to access the cluster console.
- Clusters not in fleet: Switch to the Clusters Not in Fleet tab, locate the cluster that is not added to the fleet, and click the cluster name to access the cluster console.
+
+
Nodes
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0103.html b/docs/ucs/umn/ucs_01_0103.html
new file mode 100644
index 000000000..47765e006
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0103.html
@@ -0,0 +1,13 @@
+
+
+Viewing Nodes in a Cluster
+After a cluster is connected to UCS, you can access the cluster console from UCS to view the nodes in a cluster.
+
Procedure
- Access the cluster console.
- In the navigation pane, choose Nodes to view the nodes in a cluster.
- Choose More > View Pods in the Operation column of the target node to view pods running on the current node.
- Click View Events to view node events.
- Choose More > Disable Scheduling in the Operation column of the target node to set the node as non-schedulable so that new pods cannot be scheduled to this node. For details about node taints, see Adding Labels/Taints to Nodes.
+
+
Adding Labels/Taints to Nodes
+UCS allows you to add different labels to nodes to define different node attributes. By using these labels, you can quickly understand the characteristics of each node.
+
Taints enable a node to repel specific pods to prevent these pods from being scheduled to the node, achieving reasonable allocation of workloads on nodes.
+
Node Label Usage Scenarios
Node labels are mainly used in the following scenarios:
+
- Node classification: Node labels are used to classify nodes.
- Affinity and anti-affinity:
- If a workload consumes too much CPU, memory, or I/O on a node, other workloads on the node may not run normally. You can add labels to nodes. This way, when you deploy workloads, you can configure workload affinity and anti-affinity based on the node labels.
- An application may contain multiple modules, each with multiple microservices. To make O&M efficient, you can add a module label to each node so that microservices of the same module can be deployed on the same node. This way, modules do not interfere with each other and microservices can be easily maintained.
+
+
+
Inherent Node Labels
After a node is created, UCS adds labels to the node. These inherent labels cannot be edited or deleted. Table 1 lists the inherent labels of a node.
+
+
Table 1 Inherent labels of a nodeKey
+ |
+Value
+ |
+
|---|
+
+failure-domain.beta.kubernetes.io/region
+ |
+Indicates the region where the node is located.
+ |
+
+failure-domain.beta.kubernetes.io/zone
+ |
+Indicates the AZ where the node is located.
+ |
+
+beta.kubernetes.io/arch
+ |
+Indicates the processor architecture of the node.
+For example, amd64 indicates a AMD64-bit processor.
+ |
+
+beta.kubernetes.io/os
+ |
+Indicates the operating system of the node.
+For example, linux indicates that the node uses Linux as its operating system.
+ |
+
+kubernetes.io/availablezone
+ |
+Indicates the AZ where the node is located.
+ |
+
+kubernetes.io/hostname
+ |
+Indicates the host name of the node.
+ |
+
+os.architecture
+ |
+Indicates the processor architecture of the node.
+For example, amd64 indicates a AMD64-bit processor.
+ |
+
+os.name
+ |
+Indicates the operating system name of the node.
+For example, EulerOS_2.0_SP2 indicates that the node uses EulerOS 2.2 as its operating system.
+ |
+
+os.version
+ |
+Indicates the kernel version of the node.
+ |
+
+
+
+
+
+
Taint
Taints are in the format of
Key=Value:Effect.
Key and
Value are the labels of a taint.
Value can be empty.
Effect is used to describe the effect of taints. The following options are supported for
Effect:
- NoSchedule: No pod will be able to schedule onto the node unless it has a matching toleration, but existing pods will not be evicted from the node.
- NoExecute: Pods that cannot tolerate this taint cannot be scheduled onto the node, and existing pods will be evicted from the node.
+
+
+
Toleration
Tolerations are applied to pods, and allow (not forcibly) the pods to schedule onto nodes with matching taints.
+
Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node. This marks that the node should not accept any pods that do not tolerate the taints.
+
Example:
+
apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+ labels:
+ env: test
+spec:
+ containers:
+ - name: nginx
+ image: nginx
+ imagePullPolicy: IfNotPresent
+ tolerations:
+ - key: "key1"
+ operator: "Equal"
+ value: "value1"
+ effect: "NoSchedule"
+
In the preceding toleration label, key is key1, value is value1, and effect is NoSchedule. Therefore, the pod can be scheduled to the corresponding node.
+
The tolerance can also be set as follows, indicating that when a taint whose key is key1 and effect is NoSchedule exists on a node, the pod can also be scheduled to the corresponding node.
+
tolerations:
+- key: "key1"
+ operator: "Exists"
+ effect: "NoSchedule"
+
+
Managing Node Labels/Taints
- Access the cluster console.
- In the navigation pane, choose Nodes, select the target node, and click Manage Labels and Taints.
- Click
to add a node label or taint. You can add a maximum of 10 operations at a time.- Choose Add/Update or Delete.
- Set the operation object to Kubernetes Label or Taint.
- Specify Key and Value.
- If you choose Taint, select a taint effect. For details, see Taint.
+ - Click OK.
+
+
+
Workload Management
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0106.html b/docs/ucs/umn/ucs_01_0106.html
new file mode 100644
index 000000000..d7f98977c
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0106.html
@@ -0,0 +1,224 @@
+
+
+Deployments
+A workload is an abstract model of a group of pods in Kubernetes. Workloads defined in Kubernetes include Deployments, StatefulSets, jobs, and DaemonSets.
+
Basic Concepts
- Deployments: Pods are completely independent of each other and functionally identical. They feature auto scaling and rolling upgrade. Typical examples include Nginx and WordPress. For details on how to create a Deployment, see Creating a Deployment.
- StatefulSets: Pods are not completely independent of each other. They have stable persistent storage and network identifiers, and feature orderly deployment, scale-in, and deletion. For example, MySQL-HA and etcd. For details on how to create a StatefulSet, see Creating a StatefulSet.
- DaemonSets: A DaemonSet runs a pod on each node in a cluster and ensures that there is only one pod. This works well for certain system-level applications, such as log collection and resource monitoring. For details on how to create a DaemonSet, see Creating a DaemonSet.
+
+
Relationship Between Workloads and Containers
As shown in Figure 1, a workload controls one or more pods. A pod consists of one or more containers. Each container is created from a container image. Pods running Deployments are the same.
+
Figure 1 Relationship between workloads and containers
+
+
Workload Lifecycle
+
Table 1 Status descriptionStatus
+ |
+Description
+ |
+
|---|
+
+Running
+ |
+All pods are running.
+ |
+
+Unready
+ |
+All pods are in the pending state.
+ |
+
+Upgrading
+ |
+After the upgrade operation is triggered, the workload is being upgraded.
+ |
+
+Available
+ |
+For a multi-pod Deployment, some pods are abnormal but at least one pod is available.
+ |
+
+Deleting
+ |
+After the delete operation is triggered, the workload is being deleted.
+ |
+
+
+
+
+
+
Creating a Deployment
- (Optional) If you create a workload using the image pulled from SWR, push your image to SWR first. For details about how to push an image, see Image Management. If you create a workload using an open source image, you do not need to push the image to SWR.
- On the cluster console, choose Workloads > Deployments and click Create from Image.
- Configure basic information as described in Table 2. The parameters marked with an asterisk (*) are mandatory.
+
Table 2 Basic workload parametersParameter
+ |
+Description
+ |
+
|---|
+
+*Workload Name
+ |
+Name of a workload, which must be unique.
+ |
+
+Cluster Name
+ |
+Cluster to which the workload belongs. You do not need to set this parameter.
+ |
+
+*Namespace
+ |
+In a single cluster, data in different namespaces is isolated from each other. This enables applications to share the Services of the same cluster without interfering each other. If no namespace is set, the default namespace is used.
+ |
+
+*Pods
+ |
+Number of pods in the workload. A workload can have one or more pods. You can set the number of pods. The default value is 2 and can be set to 1.
+Each workload pod consists of the same containers. Configuring multiple pods for a workload ensures that the workload can still run properly even if a pod is faulty. If only one pod is used, a node or pod exception may cause service exceptions.
+ |
+
+Description
+ |
+Description of the workload.
+ |
+
+Time Zone Synchronization
+ |
+If this parameter is enabled, the containers and the node use the same time zone, and disks of the hostPath type will be automatically added and listed in the Data Storage > Local Volumes area. Do not modify or delete the disks.
+ |
+
+
+
+
- Configure the container settings for the workload.
Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
+- Container Information: Click Add Container on the right to configure multiple containers for the pod.
- Basic Info: See Table 3.
+
Table 3 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container.
+- My Images: images in the image repository of the current region. If no image is available, click Upload Image to upload an image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account. For details, see Sharing Private Images.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+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.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Container Storage.
- Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.
+
+
- Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+
- (Optional) Click
in the Service Settings area to configure a Service for the workload.If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services.
+You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.
+- Service Name: name of the Service to be added. It is customizable and must be unique.
- Service Type
- ClusterIP: The Service is only reachable from within the cluster.
- NodePort: The Service can be accessed from any node in the cluster.
- LoadBalancer: The workload is accessed from the public network using a load balancer.
+ - Service Affinity (for NodePort and LoadBalancer only)
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number range is 30000–32767. Ensure that the port is unique in a cluster.
+
+ - Annotation: The key-value pair format is supported. Configure annotations based on your service and vendor requirements and then click Add.
+ - (Optional) Click Expand to set advanced settings for the workload.
- Upgrade: upgrade mode of the Deployment, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
- Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
- Replace upgrade: Old pods are deleted before new pods are created. Services will be interrupted during a replace upgrade.
+ - Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Scheduling Policy (Affinity/Anti-affinity).
- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
- Toleration: When the node where the workload pods are located is unavailable for the specified amount of time, the pods will be rescheduled to other available nodes. By default, the toleration time window is 300s.
- 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 Example Tutorial.
- Click
under Taints and Tolerations to add a policy. For details about related parameters, see Tolerance Policies.
+
+ - After the configuration is complete, click Create Workload. You can view the Deployment status in the Deployment list.
If the Deployment is in the Running status, the Deployment is successfully created.
+
+
+
Related Operations
On the cluster console, you can also perform the operations described in
Table 4.
+
Table 4 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a workload from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a workload from an existing YAML file.
+ |
+
+Viewing pod details
+ |
+Click the name of a workload. You can view pod details on the Pods tab. - View Events: You can set search criteria, such as the time segment during which an event is generated or the event name, to view related events.
- View Container: You can view the container name, status, image, and restarts of the pod.
- View YAML: You can view the YAML file of the pod.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target workload resides to edit its YAML file.
+ |
+
+Upgrade
+ |
+- Click Upgrade in the row where the target workload resides.
- Modify information about the workload.
- Click Upgrade Workload to submit the modified information.
+ |
+
+Rollback
+ |
+Choose More > Roll Back in the row where the target workload resides, and select the target version for rollback.
+ |
+
+Redeploy
+ |
+Choose More > Redeploy in the row where the target workload resides, and click Yes in the dialog box displayed. Redeployment will restart all pods in the workload.
+ |
+
+Disabling upgrade
+ |
+Choose More > Disable Upgrade in the row where the workload resides, and click Yes in the dialog box displayed.
+- After a workload is marked "Upgrade disabled", its upgrade will not be applied to the pods.
- Any ongoing rolling upgrade will be suspended.
+ |
+
+Delete
+ |
+Choose More > Delete in the row where the workload resides, and click Yes in the dialog box displayed.
+ |
+
+Deleting workloads in batches
+ |
+- Select the target workloads to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Jobs and Cron Jobs
+Overview
In Kubernetes, there are two types of jobs: one-off jobs and cron jobs.
+
A job (one-off job) is a resource object that Kubernetes uses to control batch tasks. Jobs are different from long-term servo tasks (such as Deployments and StatefulSets). The former are started and terminated at specific times, while the latter run unceasingly unless being terminated. The pods managed by a job automatically exit after successfully completing the job based on user configurations. The success flag varies depending on the spec.completions policy. A single-pod job is considered successful if one pod completes successfully. A job with a fixed success count is considered successful if N pods complete successfully. A queue job is considered successful based on the global success confirmed by the application.
+
Similar to a crontab in Linux OS, a cron job can:
+
- Run a scheduled job once at the specified time.
- Run a scheduled job periodically at the specified time.
+
The typical usage of a cron job is as follows:
+
- Schedules jobs at the specified time.
- Creates jobs to run periodically, for example, database backup and email sending.
+
+
Creating a Job
A job runs pods that perform a completable task. The pods automatically exit after successfully completing the task. Before creating a workload, you can run a job to upload an image to the image repository.
+
- (Optional) If you use a private container image to create your job, upload the container image to the image repository.
- Access the cluster console. In the navigation pane, choose Workloads. On the displayed page, click the Jobs tab. In the upper right corner, click Create from Image.
- Set basic workload parameters.
Basic Info- Workload Type: Select Job.
- Workload Name: Enter a workload name.
- Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
- Pods: Enter the number of pods.
+
+Container Settings- Container Information: Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
- Basic Info: See Table 1.
+
Table 1 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container.
+- My Images: images in the image repository of the current region. If no image is available, click Upload Image to upload an image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+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.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Container Storage.
+ - Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+
+Advanced Settings- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
- Job Settings
- Parallel Pods: Maximum number of pods that can run in parallel during job execution. The value cannot be greater than the total number of pods in the job.
- Timeout (s): Once a job reaches this time, the job status becomes failed and all pods in this job will be deleted. If you leave this parameter blank, the job will never time out.
+
+
+ - After the job is created, you can view the job in the job list.
If the status of the job is Processing, the job has been created successfully.
+
+
+
Creating a Cron Job
A cron job can run a scheduled job once or periodically at the specified time. The job automatically exits after successfully completing the task. For example, you can perform time synchronization for all active nodes at the specified time.
+
- (Optional) If you use a private container image to create your cron job, upload the container image to the image repository.
- Access the cluster console. In the navigation pane, choose Workloads. On the displayed page, click the Cron Jobs tab. In the upper right corner, click Create Workload.
- Configure workload parameters.
Basic Info- Workload Type: Select Cron Job.
- Workload Name: Enter a workload name.
- Namespace: Select the namespace of the workload. The default value is default. You can also click Create Namespace to create one. For details, see Creating a Namespace.
+
+Container Settings- Container Information: Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
- Basic Info: See Table 2.
+
Table 2 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container.
+- My Images: images in the image repository of the current region. If no image is available, click Upload Image to upload an image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+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.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
+ - Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+
+Execution Settings
+- Concurrency Policy: The following three modes are supported:
- Forbid: A new job cannot be created before the previous job is completed.
- Allow: The cron job allows concurrently running jobs, which preempt cluster resources.
- Replace: If it is time for a new job run and the previous job run has not finished yet, the cron job replaces the currently running job run with a new job run.
+ - Policy Settings: Time when a new cron job is executed. Scheduled rules in YAML are implemented using the cron expression.
- A cron job is executed at a fixed interval. The unit can be minute, hour, day, or month. For example, if a cron job is executed every 30 minutes and the corresponding cron expression is */30 * * * *, the execution time starts from 0 in the unit range, for example, 00:00:00, 00:30:00, 01:00:00, and ....
- The cron job is executed by month. For example, if a cron job is executed at 00:00 on the first day of each month, the corresponding cron expression is 0 0 1 */1 *, and the execution time is ****-01-01 00:00:00, ****-02-01 00:00:00, and ....
- The cron job is executed by week. For example, if a cron job is executed at 00:00 every Monday, the corresponding cron expression is 0 0 * * 1, and the execution time is ****-**-01 00:00:00 on Monday, ****-**-08 00:00:00 on Monday, and ....
- Custom Cron Expression: For details about how to use cron expressions, see cron.
+ - If a cron job is executed at a fixed time (by month) and the number of days in a month does not exist, the job will not be executed that month. For example, if a cron job is set to run on the 30th day of every month, but a month like February only has 28 or 29 days, the cron job will not run during that month and will instead resume on the 30th day of the following month.
- The cron expression defines a fixed period, but it is not always strict. The time unit range starts at 0 and is divided by the period. For example, if the unit is minute, the range is from 0 to 59. If the value cannot be evenly divided, the last period is reset. This means that an accurate period can only be represented when it can evenly divide its time unit range.
Take a cron job that is executed by hour as an example. As /2, /3, /4, /6, /8, and /12 can exactly divide 24 hours, an accurate period can be represented. If another period is used, the last period will be reset at the beginning of a new day. For example, if the cron expression is * */12 * * *, the execution time is 00:00:00 and 12:00:00 every day. If the cron expression is * */13 * * *, the execution time is 00:00:00 and 13:00:00 every day. At 00:00 on the next day, the execution time is updated even if the period does not reach 13 hours.
+
+
+ - Job Records: You can set the number of jobs that are successfully executed or fail. Setting a limit to 0 corresponds to keeping none of the jobs after they are completed.
+Advanced Settings- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
+
+ - After the cron job is created, you can view the cron job in the cron job list.
If the status is Started, the cron job has been created successfully.
+
+
+
Related Operations
- View Events: You can set search criteria, such as the time segment during which an event is generated or the event name, to view related events.
- Pods/Jobs: View the information about the target pod/job.
- View Events: Event information generated by the pod, which is stored for one hour.
- Pods: View the pod name, status, and restart times.
- View YAML: View the YAML file of the pod.
- Delete: Delete the pod.
+ - View/Edit YAML: View or edit the YAML file of the workload.
- Delete: Delete the workload.
- Stop (for cron jobs only): Stop a cron job.
+
+
Pod
+A pod is the smallest and simplest unit in the Kubernetes object model that you create or deploy. A pod encapsulates an application's container (or, in some cases, multiple containers), storage resources, a unique network identity (IP address), as well as options that govern how the container(s) should run. A pod represents a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources.
+
Creating a Pod from a YAML File
- Log in to the cluster console. Choose Workloads > Pods, and click Create from YAML.
- On the displayed Create from YAML page, edit the YAML file.
- Click OK.
+
+
Related Operations
- View Events: You can set search criteria, such as the time segment during which an event is generated or the event name, to view related events.
- View Container: You can view the container name, status, image, and restarts of the pod.
- View YAML: You can view the YAML file of the pod.
+
+
Networking
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0110.html b/docs/ucs/umn/ucs_01_0110.html
new file mode 100644
index 000000000..288584408
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0110.html
@@ -0,0 +1,30 @@
+
+
+Services
+Services provide fixed modes for accessing workloads in a cluster. You can create the following Services on the cluster console:
+
- ClusterIP
A workload can be accessed from other workloads in the same cluster through a cluster-internal domain name. A cluster-internal domain name is in the format of <User-defined Service name>.<Namespace of the workload>.svc.cluster.local, for example, nginx.default.svc.cluster.local.
+ - NodePort
A workload can be accessed from outside the cluster. A NodePort Service is exposed on each node's IP address at a static port. If a node in the cluster is bound to an elastic IP address (EIP), you can use <EIP>:<NodePort> to access the workload from a public network.
+ - LoadBalancer
A workload can be accessed from a public network through a load balancer. This access type is applicable to Services that need to be exposed to a public network in the system. The access address is in the format of <IP address of public network load balancer>:<access port>, for example, 10.117.117.117:80.
+
+
ClusterIP
- Access the cluster console.
- In the navigation pane, choose Services & Ingresses. On the displayed page, click the Services tab and select the namespace that the Service belongs to. For details about how to create a namespace, see Creating a Namespace.
- Click Create Service in the upper right corner and configure the parameters.
- Service Name: Can be the same as the workload name.
- Service Type: Select ClusterIP.
- Namespace: Set it to the namespace that the workload belongs to.
- Selector: Add a label and click Add. A Service selects a pod based on the added label. You can also click Reference Workload Label to reference the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
- Port
- Protocol: Select a protocol used by the Service.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The workload can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens. For example, the Nginx application listens on port 80 (container port).
+
+ - Click OK.
+
+
NodePort
- Access the cluster console.
- In the navigation pane, choose Services & Ingresses. On the displayed page, click the Services tab and select the namespace that the Service belongs to. For details about how to create a namespace, see Creating a Namespace.
- Click Create Service in the upper right corner and configure the parameters.
- Service Name: Can be the same as the workload name.
- Service Type: Select NodePort.
- Service Affinity
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Namespace: Set it to the namespace that the workload belongs to.
- Selector: Add a label and click Add. A Service selects a pod based on the added label. You can also click Reference Workload Label to reference the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
- Port
- Protocol: Select a protocol used by the Service.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port: Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number range is 30000–32767. Ensure that the port is unique in a cluster.
+
+
+ - Click OK.
+
+
LoadBalancer
- Access the cluster console.
- In the navigation pane, choose Services & Ingresses. On the displayed page, click the Services tab and select the namespace that the Service belongs to. For details about how to create a namespace, see Creating a Namespace.
- Click Create Service in the upper right corner and configure the parameters.
- Service Name: Can be the same as the workload name.
- Service Type: Select LoadBalancer.
- Service Affinity
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Namespace: Set it to the namespace that the workload belongs to.
- Selector: Add a label and click Add. A Service selects a pod based on the added label. You can also click Reference Workload Label to reference the label of an existing workload. In the dialog box that is displayed, select a workload and click OK.
- Port
- Protocol: Select a protocol used by the Service.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
+ - Annotation: The key-value pair format is supported. Configure annotations based on your service and vendor requirements and then click Add.
+ - Click OK.
+
+
Ingresses
+An ingress uses load balancers as the entry for external traffic. Compared with Layer-4 load balancing, it supports Uniform Resource Identifier (URI) configurations and distributes access traffic to the corresponding services based on the URIs. You can customize forwarding rules based on domain names and URLs to implement fine-grained distribution of access traffic. The access address is in the format of <IP address of public network load balancer>:<access port><defined URI>, for example, 10.117.117.117:80/helloworld.
+
Procedure
- Access the cluster console.
- In the navigation pane, choose Services & Ingresses. On the displayed page, click the Ingresses tab and select the namespace that the ingress belongs to. For details about how to create a namespace, see Creating a Namespace.
- Click Create Ingress in the upper right corner and configure the parameters.
- Name: name of the ingress to be created, which can be self-defined.
- Namespace: namespace that the ingress belongs to.
- TLS:
- Server Certificate: Select the IngressTLS server certificate. If no desired certificates are available, click Create IngressTLS Secret. For details, see Creating a Secret. For details about how to obtain a TLS certificate, see
- SNI: Enter the domain name and select the corresponding certificate. Server Name Indication (SNI) is an extended protocol of TLS. It allows multiple TLS-based access domain names to be provided for external systems using the same IP address and port number. Different domain names can use different security certificates.
+ - Forwarding Policy: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the corresponding target Service for processing. You can add multiple forwarding policies.
- Domain Name: (Optional) actual domain name. Ensure that the domain name has been registered and licensed. Once a forwarding policy is configured with a domain name specified, you must use the domain name for access.
- URL: access path to be registered, for example, /healthz. The access path must be the same as the URL exposed by the backend application. Otherwise, a 404 error will be returned.
- Destination Service: Select a Service name. You need to create the NodePort Service first. For details, see NodePort.
- Destination Service Port: After you select the destination Service, the corresponding container port is automatically filled in.
+ - Ingress Class: You can select an existing ingress class or manually enter an ingress class name.
- Annotation: The key-value pair format is supported. Configure annotations based on your service and vendor requirements and then click Add.
+ - Click OK.
+
+
Container Storage
+To mount a PVC to a cluster, the cluster provider must support the StorageClass resource to dynamically create storage volumes. You can choose Storage on the cluster console and click the Storage Classes tab to view the storage classes supported by the cluster. For more information about StorageClass, see Storage Classes.
+
Creating a PVC
- Access the cluster console.
- In the navigation pane, choose Storage. On the displayed page, click the PVCs tab. Then click Create from YAML in the upper right corner.
- Write a YAML file for the PVC.
- Click OK.
+
+
ConfigMaps and Secrets
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0114.html b/docs/ucs/umn/ucs_01_0114.html
new file mode 100644
index 000000000..41c02261e
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0114.html
@@ -0,0 +1,125 @@
+
+
+Creating a ConfigMap
+A ConfigMap is a type of resource that stores configuration information required by a workload. Its content is user-defined. After creating ConfigMaps, you can use them as files or environment variables in a workload.
+
ConfigMaps allow you to decouple configuration files from container images to enhance the portability of workloads.
+
ConfigMaps provide the following benefits:
+
- Manage configurations for different environments and services.
- Deploy workloads in different environments. Multiple versions are supported for configuration files so that you can update and roll back workloads easily.
- Quickly import configurations in the form of files to containers.
+
Creating a ConfigMap
- Access the cluster console. In the navigation pane, choose ConfigMaps and Secrets. Then, click the ConfigMaps tab. You can create a ConfigMap directly or using YAML. If you want to create a ConfigMap using YAML, go to 4.
- Select the namespace that the ConfigMap will belong to.
- Create a ConfigMap directly by clicking Create ConfigMap.
Configure the parameters as described in Table 1.
+
+Table 1 Parameters for creating a ConfigMapParameter
+ |
+Description
+ |
+
|---|
+
+Name
+ |
+Name of the ConfigMap you create, which must be unique in a namespace.
+ |
+
+Namespace
+ |
+Namespace that the ConfigMap belongs to. The current namespace is used by default.
+ |
+
+Description
+ |
+Description of the ConfigMap.
+ |
+
+ConfigMap Data
+ |
+The workload configuration data can be used in a container or used to store the configuration data.
+Click  and enter the key and value. Key indicates the configuration name, and Value indicates the configuration content.
+ NOTE: ConfigMaps can be used to create workload storage volumes and configure workload environment variables. When configuring workload environment variables, ensure that the ConfigMap data is not empty.
+
+ |
+
+Label
+ |
+Labels are attached to objects such as workloads, nodes, and Services in key-value pairs.
+Labels define the identifiable attributes of these objects and are used to manage and select the objects.
+- Enter the key and value.
- Click Confirm.
+ |
+
+
+
+
- Create a ConfigMap from a YAML file by clicking Create from YAML.
To create a resource by uploading a file, ensure that the resource description file has been created. UCS supports files in JSON or YAML format. For details, see ConfigMap Resource File Configuration.
+
+You can import or directly write the file content in YAML or JSON format.
- Method 1: Import an orchestration file.
Click Import to import a YAML or JSON file. The content of the YAML or JSON file is displayed in the orchestration content area.
+ - Method 2: Directly orchestrate the content.
In the orchestration content area, enter the content of the YAML or JSON file.
+
+
- When the configuration is complete, click OK.
The new ConfigMap is displayed in the ConfigMap list.
+
+
+
ConfigMap Resource File Configuration
A ConfigMap resource file can be in JSON or YAML format, and the file size cannot exceed 2 MB.
+
- JSON format
The file name is configmap.json and the configuration example is as follows:
+{
+ "kind": "ConfigMap",
+ "apiVersion": "v1",
+ "metadata": {
+ "name": "paas-broker-app-017",
+ "namespace": "test"
+ },
+ "data": {
+ "context": "{\"applicationComponent\":{\"properties\":{\"custom_spec\":{}},\"node_name\":\"paas-broker-app\",\"stack_id\":\"0177eae1-89d3-cb8a-1f94-c0feb7e91d7b\"},\"softwareComponents\":[{\"properties\":{\"custom_spec\":{}},\"node_name\":\"paas-broker\",\"stack_id\":\"0177eae1-89d3-cb8a-1f94-c0feb7e91d7b\"}]}"
+ }
+}
+ - YAML format
The file name is
configmap.yaml and the configuration example is as follows:
apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: test-configmap
+ namespace: default
+data:
+ data-1: "value-1"
+ data-2: "value-2"
+
+
+
Related Operations
On the cluster console, you can also perform the operations described in
Table 2.
+
Table 2 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Viewing details
+ |
+Click the ConfigMap name to view its details.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target ConfigMap resides to edit its YAML file.
+ |
+
+Updating a ConfigMap
+ |
+- Click Update in the row where the target ConfigMap resides.
- Modify the ConfigMap data according to Table 1.
- Click OK to submit the modified information.
+ |
+
+Deleting a ConfigMap
+ |
+Click Delete in the row where the target ConfigMap resides, and click Yes.
+ |
+
+Deleting ConfigMaps in batches
+ |
+- Select the ConfigMap to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Creating a Secret
+A secret is a type of resource that holds sensitive data, such as authentication and key information, required by a workload. Its content is user-defined. After creating secrets, you can use them as files or environment variables in a containerized workload.
+
Creating a Secret
- Access the cluster console. In the navigation pane, choose ConfigMaps and Secrets. Then, click the Secrets tab. You can create a secret directly or using YAML. If you want to create a secret using YAML, go to 4.
- Select the namespace that the secret will belong to.
- Click Create Secret.
Configure the parameters as described in
Table 1.
+
Table 1 Parameters for creating a secretParameter
+ |
+Description
+ |
+
|---|
+
+Name
+ |
+Name of the secret you create, which must be unique in a namespace.
+ |
+
+Namespace
+ |
+Namespace that the secret belongs to. The current namespace is used by default.
+ |
+
+Description
+ |
+Description of the secret.
+ |
+
+Secret Type
+ |
+Type of the secret.
+- Opaque: general secret type. In high-sensitive scenarios, you are advised to encrypt sensitive data using data encryption services and then store the encrypted data in secrets.
- kubernetes.io/dockerconfigjson: a secret that stores the authentication information required for pulling images from a private repository. If you select this secret type, enter the image repository address.
- IngressTLS: a secret that stores the certificate required for Layer 7 load balancing. If you select this secret type, upload the certificate file and private key file.
- Other: another type of secret, which is specified manually.
+ |
+
+Secret Data
+ |
+Workload secret data can be used in containers.
+- If the secret type is Opaque, enter the key and value. The value must be a Base64-encoded value. You can select Auto Base64 Encoding to Base64-encode the entered value. For details about manual Base64 encoding, see Base64 Encoding.
- If the secret type is kubernetes.io/dockerconfigjson, enter the username and password of the private image repository.
NOTE: Secrets can be used to create workload storage volumes and configure workload environment variables. When configuring workload environment variables, ensure that the secret data is not empty.
+
+
+ |
+
+Label
+ |
+Labels are attached to objects such as workloads, nodes, and Services in key-value pairs.
+Labels define the identifiable attributes of these objects and are used to manage and select the objects.
+- Enter the key and value.
- Click Confirm.
+ |
+
+
+
+
+
- Create a secret from a YAML file by clicking Create from YAML.
To create a resource by uploading a file, ensure that the resource description file has been created. UCS supports files in JSON or YAML format. For details, see Secret Resource File Configuration.
+
+You can import or directly write the file content in YAML or JSON format.
- Method 1: Import an orchestration file.
Click Import to import a YAML or JSON file. The content of the YAML or JSON file is displayed in the orchestration content area.
+ - Method 2: Directly orchestrate the content.
In the orchestration content area, enter the content of the YAML or JSON file.
+
+
- When the configuration is complete, click OK.
The new secret is displayed in the secret list.
+
+
+
Secret Resource File Configuration
This section provides a configuration example of a secret resource file.
+
For example, you can retrieve the username and password for a workload through a secret.
+
- YAML format
The content in the secret file secret.yaml is as follows. The value must be encoded using Base64. For details, see Base64 Encoding.
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret #Secret name
+ namespace: default #Namespace. The default value is default.
+data:
+ username: bXktdXNlcm5hbWUK #Username, which must be encoded using Base64.
+ password: ****** #The value must be encoded using Base64.
+type: Opaque #You are advised not to change this parameter value.
+ - JSON format
The content in the secret file secret.json is as follows:
+{
+ "apiVersion": "v1",
+ "kind": "Secret",
+ "metadata": {
+ "name": "mysecret",
+ "namespace": "default"
+ },
+ "data": {
+ "username": "bXktdXNlcm5hbWUK",
+ "password": "******"
+ },
+ "type": "Opaque"
+}
+
+
+
Related Operations
After a secret is created, you can perform the operations described in
Table 2.
The secrets in the kube-system namespace can only be viewed.
+
+
+
Table 2 Other operationsOperation
+ |
+Description
+ |
+
|---|
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target secret resides to edit its YAML file.
+ |
+
+Updating a secret
+ |
+- Click Update in the row where the target secret resides.
- Modify the secret data according to Table 1.
- Click OK.
+ |
+
+Deleting a secret
+ |
+Click Delete in the row where the target secret resides.
+Delete the secret as prompted.
+ |
+
+Deleting secrets in batches
+ |
+- Select the secrets to be deleted.
- Click Delete in the upper left corner.
- Delete the secret as prompted.
+ |
+
+
+
+
+
+
+
Base64 Encoding
To encode a character string using Base64, run the echo -n Content to be encoded | base64 command. The following is an example:
+
root@ubuntu:~# echo -n "Content to be encoded" | base64
+******
+
+
Custom Resource Definitions
+Custom Resource Definitions (CRDs) are custom resource objects similar to Deployments or Services. You can run the kubectl commands to create and access CRDs for modular Kubernetes extension. For details, see Extend the Kubernetes API with CustomResourceDefinitions.
+
Procedure
- Access the cluster details page.
- In the navigation pane, choose Custom Resources. Then, click Create from YAML in the upper right corner.
- Edit the YAML file online or import one, and click OK.
- Other operations:
- Click View YAML in the Operation column of the target CRD to view its YAML file.
- Click View Details in the Operation column of the target CRD to view its instances in the cluster.
+
+
+
Namespaces
+Namespaces that you create on the cluster console apply only to the current cluster. You can create Kubernetes objects and manage resource quotas in such namespaces, or delete these namespaces.
+
- The default namespace created by the system supports quota management but cannot be deleted.
- Namespaces created by a cluster, such as kube-public and kube-system, do not support quota management and cannot be deleted.
+
Creating a Namespace
- Access the cluster details page.
- Choose Namespaces in the navigation pane, click Create Namespace in the upper right corner, and configure parameters.
- Namespace Name: Name of the namespace, which must be unique in a cluster.
- Description: Description of the namespace.
- Quota Management: If this function is enabled, you can configure resource quotas. Resource quotas can limit the amount of resources available in namespaces, achieving resource allocation by namespace.
If you do not enable this function, you can click Manage Quota in the namespace list to configure resource quotas after the namespace is created. For details, see Configuring Resource Quotas in a Namespace.
+
+ - Click OK.
+
+
Deleting a Namespace
Deleting a namespace will delete all data resources related to the namespace. Exercise caution when performing this operation.
+
+
- Access the cluster details page.
- In the navigation pane, choose Namespaces, select the target namespace, and choose More > Delete.
+
+
Configuring Resource Quotas in a Namespace
Resource quotas can limit the amount of resources available in namespaces, achieving resource allocation by namespace.
+
Namespace-level resource quotas limit the amount of resources available to teams or users when these teams or users use the same cluster. The quotas include the total number of a type of objects and the total amount of compute resources (CPU and memory) consumed by the objects.
+
The kube-public and kube-system namespaces do not support resource quota settings.
+
+
- Access the cluster details page.
- In the navigation pane, choose Namespaces, locate the target namespace, and click Manage Quota in the Operation column.
- Configure resource quotas.
- There is no limit on quotas by default. To specify a resource quota, enter an integer greater than or equal to 1. If you want to limit the CPU or memory quota, you must specify the CPU or memory request when creating a workload.
- Accumulated quota usage includes the default resources created by the system, such as the Kubernetes Service (view this Service using the kubectl tool) created in the default namespace. Therefore, you are advised to set a resource quota greater than what you expect.
+
+- CPU (cores): maximum number of CPU cores that can be allocated to workload pods in the namespace.
- Memory (MiB): maximum amount of memory that can be allocated to workload pods in the namespace.
- StatefulSet: Maximum number of StatefulSets that can be created in the namespace.
- Deployment: Maximum number of Deployments that can be created in the namespace.
- Job: Maximum number of jobs that can be created in the namespace.
- Cron Job: Maximum number of cron jobs that can be created in the namespace.
- Pods: maximum number of pods, including those in terminated state, that can be created in the namespace.
- Pods (excluding terminated pods): maximum number of pods in a non-terminated state that can be created in the namespace.
- Services: maximum number of Services, including those in terminated state, that can be created in the namespace.
- Services (excluding terminated Services): maximum number of Services in a non-terminated state that can be created in the namespace.
- PersistentVolumeClaims (PVCs): maximum number of PVCs that can be created in the namespace.
- ConfigMaps: maximum number of ConfigMaps that can be created in the namespace.
- Secrets: maximum number of secrets that can be created in the namespace.
+ - Click OK.
+
+
StatefulSets
+Creating a StatefulSet
- (Optional) If you create a workload using the image pulled from SWR, push your image to SWR first. For details about how to push an image, see Image Management. If you create a workload using an open source image, you do not need to push the image to SWR.
- On the cluster details page, choose Workloads > StatefulSets and click Create from Image.
- Set basic workload parameters as described in Table 1. The parameters marked with an asterisk (*) are mandatory.
+
Table 1 Basic workload parametersParameter
+ |
+Description
+ |
+
|---|
+
+*Workload Name
+ |
+Name of a workload, which must be unique.
+ |
+
+Cluster Name
+ |
+Cluster to which the workload belongs. You do not need to set this parameter.
+ |
+
+*Namespace
+ |
+In a single cluster, data in different namespaces is isolated from each other. This enables applications to share the Services of the same cluster without interfering each other. If no namespace is set, the default namespace is used.
+ |
+
+*Pods
+ |
+Number of pods in the workload. A workload can have one or more pods. You can set the number of pods. The default value is 2 and can be set to 1.
+Each workload pod consists of the same containers. Configuring multiple pods for a workload ensures that the workload can still run properly even if a pod is faulty. If only one pod is used, a node or pod exception may cause service exceptions.
+ |
+
+Description
+ |
+Description of the workload.
+ |
+
+Time Zone Synchronization
+ |
+If this parameter is enabled, the containers and the node use the same time zone, and disks of the hostPath type will be automatically added and listed in the Data Storage > Local Volumes area. Do not modify or delete the disks.
+ |
+
+
+
+
- Configure the container settings for the workload.
Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
+- Container Information: Click Add Container on the right to configure multiple containers for the pod.
- Basic Info: See Table 2.
+
Table 2 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container.
+- My Images: images in the image repository of the current region. If no image is available, click Upload Image to upload an image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account. For details, see Sharing Private Images.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+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.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Container Storage.
- Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.
+
+
- Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+
- Configure the headless Service parameters for the workload.
StatefulSet pods discover each other through headless Services. No cluster IP is allocated for a headless Service, and the DNS records of all pods are returned during query. In this way, the IP addresses of all pods can be queried.
+- Service Name: Name of the Service corresponding to the workload for mutual access between workloads in the same cluster. This Service is used for internal discovery of pods, and does not require an independent IP address or load balancing.
- Port
- Port: Name of the container port. You are advised to enter a name that indicates the function of the port.
- Service Port: Port of the Service.
- Container Port: Listening port of the container.
+
+ - (Optional) Click in the Service Settings area to configure a Service for the workload.
If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services.
+You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.
+- Service Name: name of the Service to be added. It is customizable and must be unique.
- Service Type
- ClusterIP: The Service is only reachable from within the cluster.
- NodePort: The Service can be accessed from any node in the cluster.
- LoadBalancer: The workload is accessed from the public network using a load balancer.
+ - Service Affinity (for NodePort and LoadBalancer only)
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number range is 30000–32767. Ensure that the port is unique in a cluster.
+
+ - Annotation: The key-value pair format is supported. Configure annotations based on your service and vendor requirements and then click Add.
+ - (Optional) Click Expand to set advanced settings for the workload.
- Upgrade: Upgrade mode of the StatefulSet, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
- Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
- Replace upgrade: You need to delete old pods manually before new pods are created. Services will be interrupted during a replace upgrade.
+ - Pod Management Policies
- OrderedReady: The StatefulSet will launch, terminate, or scale pods sequentially. It will wait for the state of the pods to change to Running and Ready or completely terminated before it launches or terminates another pod.
- Parallel: The StatefulSet will launch or terminate all pods in parallel. It will not wait for the state of the pods to change to Running and Ready or completely terminated before it launches or terminates another pod.
+ - Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Scheduling Policy (Affinity/Anti-affinity).
- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
- Toleration: When the node where the workload pods are located is unavailable for the specified amount of time, the pods will be rescheduled to other available nodes. By default, the toleration time window is 300s.
- 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 Example Tutorial.
- Click
to add a policy. For details about related parameters, see Tolerance Policies.
+
+ - After the configuration is complete, click Create Workload. You can view the StatefulSet status in the StatefulSet List.
If the StatefulSet is in the Running status, the StatefulSet is successfully created.
+
+
+
Related Operations
On the cluster console, you can also perform the operations described in
Table 3.
+
Table 3 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a workload from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a workload from an existing YAML file.
+ |
+
+Viewing pod details
+ |
+Click the name of a workload. You can view pod details on the Pods tab. - View Events: You can set search criteria, such as the time segment during which an event is generated or the event name, to view related events.
- View Container: You can view the container name, status, image, and restarts of the pod.
- View YAML: You can view the YAML file of the pod.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target workload resides to edit its YAML file.
+ |
+
+Upgrade
+ |
+- Click Upgrade in the row where the target workload resides.
- Modify information about the workload.
- Click Upgrade Workload to submit the modified information.
+ |
+
+Rollback
+ |
+Choose More > Roll Back in the row where the target workload resides, and select the target version for rollback.
+ |
+
+Redeploy
+ |
+Choose More > Redeploy in the row where the target workload resides, and click Yes in the dialog box displayed. Redeployment will restart all pods in the workload.
+ |
+
+Disabling upgrade
+ |
+Choose More > Disable Upgrade in the row where the workload resides, and click Yes in the dialog box displayed.
+- After a workload is marked "Upgrade disabled", its upgrade will not be applied to the pods.
- Any ongoing rolling upgrade will be suspended.
+ |
+
+Delete
+ |
+Choose More > Delete in the row where the workload resides, and click Yes in the dialog box displayed.
+ |
+
+Deleting workloads in batches
+ |
+- Select the target workloads to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
DaemonSets
+Creating a DaemonSet
- (Optional) If you create a workload using the image pulled from SWR, push your image to SWR first. For details about how to push an image, see Image Management. If you create a workload using an open source image, you do not need to push the image to SWR.
- On the cluster details page, choose Workloads > DaemonSets and click Create from Image.
- Set basic workload parameters as described in Table 1. The parameters marked with an asterisk (*) are mandatory.
+
Table 1 Basic workload parametersParameter
+ |
+Description
+ |
+
|---|
+
+*Workload Name
+ |
+Name of a workload, which must be unique.
+ |
+
+Cluster Name
+ |
+Cluster to which the workload belongs. You do not need to set this parameter.
+ |
+
+*Namespace
+ |
+In a single cluster, data in different namespaces is isolated from each other. This enables applications to share the Services of the same cluster without interfering each other. If no namespace is set, the default namespace is used.
+ |
+
+Description
+ |
+Description of the workload.
+ |
+
+Time Zone Synchronization
+ |
+If this parameter is enabled, the containers and the node use the same time zone, and disks of the hostPath type will be automatically added and listed in the Data Storage > Local Volumes area. Do not modify or delete the disks.
+ |
+
+
+
+
- Configure the container settings for the workload.
Multiple containers can be configured in a pod. You can click Add Container on the right to configure multiple containers for the pod.
+- Container Information: Click Add Container on the right to configure multiple containers for the pod.
- Basic Info: See Table 2.
+
Table 2 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container.
+- My Images: images in the image repository of the current region. If no image is available, click Upload Image to upload an image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account. For details, see Sharing Private Images.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+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.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Container Storage.
- Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.
+
+
- Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+
- (Optional) Click in the Service Settings area to configure a Service for the workload.
If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services.
+You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.
+- Service Name: name of the Service to be added. It is customizable and must be unique.
- Service Type
- ClusterIP: The Service is only reachable from within the cluster.
- NodePort: The Service can be accessed from any node in the cluster.
- LoadBalancer: The workload is accessed from the public network using a load balancer.
+ - Service Affinity (for NodePort and LoadBalancer only)
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number range is 30000–32767. Ensure that the port is unique in a cluster.
+
+ - Annotation: The key-value pair format is supported. Configure annotations based on your service and vendor requirements and then click Add.
+ - (Optional) Click Expand to set advanced settings for the workload.
- Upgrade: upgrade mode of the DaemonSet, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
- Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
- Replace upgrade: You need to delete old pods manually before new pods are created. Services will be interrupted during a replace upgrade.
+ - Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Scheduling Policy (Affinity/Anti-affinity).
- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
- Toleration: When the node where the workload pods are located is unavailable for the specified amount of time, the pods will be rescheduled to other available nodes. By default, the toleration time window is 300s.
- 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 Example Tutorial.
- Click
to add a policy. For details about related parameters, see Tolerance Policies.
+
+ - After the configuration is complete, click Create Workload. You can view the DaemonSet status in the DaemonSet List.
If the DaemonSet is in the Running status, the DaemonSet is successfully created.
+
+
+
Related Operations
On the cluster console, you can also perform the operations described in
Table 3.
+
Table 3 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a workload from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a workload from an existing YAML file.
+ |
+
+Viewing pod details
+ |
+Click the name of a workload. You can view pod details on the Pods tab. - View Events: You can set search criteria, such as the time segment during which an event is generated or the event name, to view related events.
- View Container: You can view the container name, status, image, and restarts of the pod.
- View YAML: You can view the YAML file of the pod.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target workload resides to edit its YAML file.
+ |
+
+Upgrade
+ |
+- Click Upgrade in the row where the target workload resides.
- Modify information about the workload.
- Click Upgrade Workload to submit the modified information.
+ |
+
+Rollback
+ |
+Choose More > Roll Back in the row where the target workload resides, and select the target version for rollback.
+ |
+
+Redeploy
+ |
+Choose More > Redeploy in the row where the target workload resides, and click Yes in the dialog box displayed. Redeployment will restart all pods in the workload.
+ |
+
+Disabling upgrade
+ |
+Choose More > Disable Upgrade in the row where the workload resides, and click Yes in the dialog box displayed.
+- After a workload is marked "Upgrade disabled", its upgrade will not be applied to the pods.
- Any ongoing rolling upgrade will be suspended.
+ |
+
+Delete
+ |
+Choose More > Delete in the row where the workload resides, and click Yes in the dialog box displayed.
+ |
+
+Deleting workloads in batches
+ |
+- Select the target workloads to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Setting Container Specifications
+Scenario
UCS allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in the workload.
+
+
Meanings
The meanings of requests and limits for CPU and memory are as follows:
+
- Requests are the minimum guaranteed amount of a resource that is reserved for containers in a pod. If the node where the pod is running does not have enough of that resource, the containers fail to be created.
- Limits are the maximum amount of a resource to be used by containers. You can specify the resource limit for a container to prevent the container from using more of that resource than the limit you set or being evicted due to node resource exhaustion.
+
When creating a workload, you are advised to set the upper and lower limits of CPU and memory resources. If the upper and lower resource limits are not set for a workload, a resource leak of this workload will make resources unavailable for other workloads deployed on the same node. In addition, workloads that do not have upper and lower resource limits cannot be accurately monitored.
+
+
+
Configuration Description
- CPU quotas:
+
Table 1 Description of CPU quotasParameter
+ |
+Description
+ |
+
|---|
+
+CPU request
+ |
+Minimum number of CPU cores required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to this node only when the total available CPU on the node is greater than or equal to the number of containerized CPU applications.
+ |
+
+CPU limit
+ |
+Maximum number of CPU cores available for a container.
+ |
+
+
+
+
Recommended configuration
+Actual available CPU of a node ≥ Sum of CPU limits of all containers on the current node ≥ Sum of CPU requests of all containers on the current node. You can view the actual available CPUs of a node on the CCE console (Resource Management > Nodes > Allocatable).
+ - Memory quotas:
+
Table 2 Description of memory quotasParameter
+ |
+Description
+ |
+
|---|
+
+Memory request
+ |
+Minimum amount of memory required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to this node only when the total available memory on the node is greater than or equal to the number of containerized memory applications.
+ |
+
+Memory Limit
+ |
+Maximum amount of memory available for a container. When the memory usage exceeds the configured memory limit, the instance may be restarted, which affects the normal use of the workload.
+ |
+
+
+
+
Recommended configuration
+Actual available memory of a node ≥ Sum of memory limits of all containers on the current node ≥ Sum of memory requests of all containers on the current node. You can view the actual available memory of a node on the CCE console (Resource Management > Nodes > Allocatable).
+
+
The allocatable resources are calculated based on the resource request value (Request), which indicates the upper limit of resources that can be requested by pods on this node, but does not indicate the actual available resources of the node. The calculation formula is as follows:
+
- Allocatable CPU = Total CPU – Requested CPU of all pods – Reserved CPU for other resources
- Allocatable memory = Total memory – Requested memory of all pods – Reserved memory for other resources
+
+
+
Example
Assume that a cluster contains a node with 4 cores and 8 GB. A workload containing two pods has been deployed on the cluster. The resources of the two pods (pods 1 and 2) are as follows: {CPU request, CPU limit, memory request, memory limit} = {1 core, 2 cores, 2 GB, 2 GB}.
+
The CPU and memory usage of the node is as follows:
+
- Allocatable CPU = 4 cores - (1 core requested by pod 1 + 1 core requested by pod 2) = 2 cores
- Allocatable memory = 8 GB - (2 GB requested by pod 1 + 2 GB requested by pod 2) = 4 GB
+
Therefore, the remaining 2 cores and 4 GB can be used by the next new pod.
+
+
Setting Container Lifecycle Parameters
+Scenario
UCS provides callback functions (hooks) 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.
+
UCS 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 during image start. To run a specific command or rewrite the default image value, you must perform specific settings:
+
A Docker image has metadata that stores image information. If lifecycle commands and arguments are not set, UCS runs the default commands and arguments (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:
+
+
Table 1 Commands and arguments used to run a containerImage ENTRYPOINT
+ |
+Image CMD
+ |
+Command to Run a Container
+ |
+Parameters to Run a Container
+ |
+Command Executed
+ |
+
|---|
+
+[touch]
+ |
+[/root/test]
+ |
+Not set
+ |
+Not set
+ |
+[touch /root/test]
+ |
+
+[touch]
+ |
+[/root/test]
+ |
+[mkdir]
+ |
+Not set
+ |
+[mkdir]
+ |
+
+[touch]
+ |
+[/root/test]
+ |
+Not set
+ |
+[/opt/test]
+ |
+[touch /opt/test]
+ |
+
+[touch]
+ |
+[/root/test]
+ |
+[mkdir]
+ |
+[/opt/test]
+ |
+[mkdir /opt/test]
+ |
+
+
+
+
+
- When creating a workload, select Lifecycle under Container Settings.
- Enter a command and arguments on the Startup Command tab page.
+
Table 2 Container startup commandsConfiguration Item
+ |
+Procedure
+ |
+
|---|
+
+Command
+ |
+Run a specified command in the container using either the bash or binary mode. You can configure the command by referring to the example.
+If there are multiple commands, separate them with spaces. If the command contains a space, you need to add a quotation mark ("").
+ 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
+ |
+Enter the argument that controls the container running command, for example, --port=8080.
+If there are multiple arguments, separate them in different lines.
+ |
+
+
+
+
+
+
Post-Start Processing
- When creating a workload, select Lifecycle under Container Settings.
- Set the post-start processing parameters on the Post-Start tab page.
+
Table 3 Post-start processing parametersParameter
+ |
+Description
+ |
+
|---|
+
+CLI
+ |
+Run a specified command in the container using either the bash or binary mode. You can configure the command by referring to the example.
+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.
+ |
+
+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) IP address of the request. The default value is the IP address of the node where the container resides.
+ |
+
+
+
+
+
+
Pre-Stop Processing
- When creating a workload, select Lifecycle under Container Settings.
- Set the pre-start processing parameters on the Pre-Stop tab page.
+
Table 4 Pre-stop processing parametersParameter
+ |
+Description
+ |
+
|---|
+
+CLI
+ |
+Run a specified command in the container using either the bash or binary mode. You can configure the command by referring to the example.
+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 the uninstall.sh script will be executed before the container completes its execution and stops running.
+ |
+
+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) IP address of the request. The default value is the IP address of the node where the container resides.
+ |
+
+
+
+
+
+
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
+kind: Deployment
+metadata:
+ name: nginx
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: nginx
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx
+ command:
+ - sleep 3600 #Startup command
+ imagePullPolicy: Always
+ lifecycle:
+ postStart:
+ exec:
+ command:
+ - /bin/bash
+ - install.sh #Post-start command
+ preStop:
+ exec:
+ command:
+ - /bin/bash
+ - uninstall.sh #Pre-stop command
+ name: nginx
+ imagePullSecrets:
+ - name: default-secret
+
+
Setting Health Check for a Container
+Scenarios
Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application exceptions or automatically restart the application to restore it. This will result in a situation where the pod status is normal but the application in the pod is abnormal.
+
Kubernetes provides the following health check probes:
+
- Liveness probe (livenessProbe): checks whether a container is still alive. It is similar to the ps command that checks whether a process exists. If the liveness check of a container fails, the cluster restarts the container. If the liveness check is successful, no operation is executed.
- Readiness probe (readinessProbe): checks whether a container is ready to process user requests. Upon that the container is detected unready, service traffic will not be directed to the container. It may take a long time for some applications to start up before they can provide services. This is because that they need to load disk data or rely on startup of an external module. In this case, the application process is running, but the application cannot provide services. To address this issue, this health check probe is used. If the container readiness check fails, the cluster masks all requests sent to the container. If the container readiness check is successful, the container can be accessed.
- Startup probe (startupProbe): checks when a containerized application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, ensuring that those probes do not interfere with the application startup. This can be used to perform liveness checks on slow starting containers to prevent them from getting terminated by the kubelet before they are started.
+
+
Check Methods
- HTTP request
This health check mode can be used for containers that provide HTTP/HTTPS services. The cluster periodically initiates an HTTP/HTTPS GET request to such containers. If the return code of the HTTP/HTTPS response is within 200–399, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port and an HTTP/HTTPS request path.
+For example, for a container that provides HTTP services, the HTTP check path is /health-check, the port is 80, and the host address is optional (which defaults to the container IP address). Here, 172.16.0.186 is used as an example, and we can get such a request: GET http://172.16.0.186:80/health-check. The cluster periodically initiates this request to the container.
+ - TCP port
For a container that provides TCP communication services, the cluster periodically establishes a TCP connection to the container. If the connection is successful, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port.
+For example, if you have a Nginx container with service port 80, after you specify TCP port 80 for container listening, the cluster will periodically initiate a TCP connection to port 80 of the container. If the connection is successful, the probe is successful. Otherwise, the probe fails.
+ - CLI
CLI is an efficient tool for health check. When using the CLI, you must specify an executable command in a container. The cluster periodically runs the command in the container. If the command output is 0, the health check is successful. Otherwise, the health check fails.
+The CLI mode can be used to replace the HTTP request-based and TCP port-based health check.
+- For a TCP port, you can use a script to connect to a container port. If the connection is successful, the script returns 0. Otherwise, the script returns –1.
- For an HTTP request, you can use a script to run the wget command for a container.
wget http://127.0.0.1:80/health-check
+Check the return code of the response. If the return code is within 200–399, the script returns 0. Otherwise, the script returns –1.
+
+
+
+
+
- gRPC check
This health check mode allows you to configure startup, liveness, and readiness probes for your gRPC application without exposing any HTTP endpoint or using an executable. Kubernetes can connect to your workload via gRPC and obtain its status.
+ - To use the gRPC check, your application must support the gRPC health checking protocol.
- Similar to HTTP and TCP probes, if the port is incorrect, the application does not support the health checking protocol, or there are another configuration error, the check will fail.
+
+
+
Common Parameters
+
Table 1 Common parameter descriptionParameter
+ |
+Description
+ |
+
|---|
+
+Period (periodSeconds)
+ |
+Indicates the probe detection period, in seconds.
+For example, if this parameter is set to 30, the detection is performed every 30 seconds.
+ |
+
+Delay (initialDelaySeconds)
+ |
+Check delay time in seconds. Set this parameter according to the normal startup time of services.
+For example, if this parameter is set to 30, the health check will be started 30 seconds after the container is started. The time is reserved for containerized services to start.
+ |
+
+Timeout (timeoutSeconds)
+ |
+Number of seconds after which the probe times out. Unit: second.
+For example, if this parameter is set to 10, the timeout wait time for performing a health check is 10s. If the wait time elapses, the health check is regarded as a failure. If the parameter is left blank or set to 0, the default timeout time is 1s.
+ |
+
+Success Threshold (successThreshold)
+ |
+Minimum consecutive successes for the probe to be considered successful after having failed.
+The default value is 1, which is also the minimum value.
+The value of this parameter is fixed to 1 in Liveness Probe and Startup Probe.
+ |
+
+Failure Threshold (failureThreshold)
+ |
+Number of retry times when the detection fails.
+Giving up in case of liveness probe means to restart the container. In case of readiness probe the pod will be marked Unready.
+The default value is 3, and the minimum value is 1.
+ |
+
+
+
+
+
+
YAML Example
apiVersion: v1
+kind: Pod
+metadata:
+ labels:
+ test: liveness
+ name: liveness-http
+spec:
+ containers:
+ - name: liveness
+ image: nginx:alpine
+ args:
+ - /server
+ livenessProbe:
+ httpGet:
+ path: /healthz
+ port: 80
+ httpHeaders:
+ - name: Custom-Header
+ value: Awesome
+ initialDelaySeconds: 3
+ periodSeconds: 3
+ readinessProbe:
+ exec:
+ command:
+ - cat
+ - /tmp/healthy
+ initialDelaySeconds: 5
+ periodSeconds: 5
+ startupProbe:
+ httpGet:
+ path: /healthz
+ port: 80
+ failureThreshold: 30
+ periodSeconds: 10
+
+
Setting Environment Variables
+Scenario
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 deployed, increasing flexibility in workload configuration.
+
The function of setting environment variables on UCS is the same as that of specifying ENV in a Dockerfile.
+
After a container is started, do not modify configurations in the container. If configurations in the container are modified (for example, passwords, certificates, and environment variables of a containerized application are added to the container), the configurations will be lost after the container restarts and container services will become abnormal. An example scenario of container restart is pod rescheduling due to node anomalies.
+
Configurations must be imported to a container as arguments. Otherwise, configurations will be lost after the container restarts.
+
+
Environment variables can be set in the following modes:
+
- Custom: Enter a variable name and value.
- Added from ConfigMap: Import all keys in a ConfigMap as environment variables.
- Added from ConfigMap key: Import a key in a ConfigMap as the value of an environment variable. For example, if you import configmap_value of configmap_key in ConfigMap configmap-example as the value of environment variable key1, an environment variable named key1 with its value is configmap_value exists in the container.
- Added from secret: Import all keys in a secret as environment variables.
- Added from secret key: Import the value of a key in a secret as the value of an environment variable. For example, if you import secret_value of secret_key in secret secret-example as the value of environment variable key2, an environment variable named key2 with its value secret_value exists in the container.
- Variable Value/Reference: Use the field defined by a pod as the value of the environment variable, for example, the pod name.
- Resource Reference: Use the field defined by a container as the value of the environment variable, for example, the CPU limit of the container.
+
+
Adding Environment Variables
- When creating a workload, select Environment Variables under Container Settings.
- Set environment variables.
+
+
YAML Example
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: env-example
+ namespace: default
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: env-example
+ template:
+ metadata:
+ labels:
+ app: env-example
+ spec:
+ containers:
+ - name: container-1
+ image: nginx:alpine
+ imagePullPolicy: Always
+ resources:
+ requests:
+ cpu: 250m
+ memory: 512Mi
+ limits:
+ cpu: 250m
+ memory: 512Mi
+ env:
+ - name: key # Custom
+ value: value
+ - name: key1 # Added from ConfigMap key
+ valueFrom:
+ configMapKeyRef:
+ name: configmap-example
+ key: key1
+ - name: key2 # Added from secret key
+ valueFrom:
+ secretKeyRef:
+ name: secret-example
+ key: key2
+ - name: key3 # Variable reference, which uses the field defined by a pod as the value of the environment variable.
+ valueFrom:
+ fieldRef:
+ apiVersion: v1
+ fieldPath: metadata.name
+ - name: key4 # Resource reference, which uses the field defined by a container as the value of the environment variable.
+ valueFrom:
+ resourceFieldRef:
+ containerName: container1
+ resource: limits.cpu
+ divisor: 1
+ envFrom:
+ - configMapRef: # Added from ConfigMap
+ name: configmap-example
+ - secretRef: # Added from secret
+ name: secret-example
+ imagePullSecrets:
+ - name: default-secret
+
+
Viewing Environment Variables
If the contents of configmap-example and secret-example are as follows:
+
$ kubectl get configmap configmap-example -oyaml
+apiVersion: v1
+data:
+ configmap_key: configmap_value
+kind: ConfigMap
+...
+
+$ kubectl get secret secret-example -oyaml
+apiVersion: v1
+data:
+ secret_key: c2VjcmV0X3ZhbHVl # c2VjcmV0X3ZhbHVl is the value of secret_value in Base64 mode.
+kind: Secret
+...
+
The environment variables in the pod are as follows:
+
$ kubectl get pod
+NAME READY STATUS RESTARTS AGE
+env-example-695b759569-lx9jp 1/1 Running 0 17m
+
+$ kubectl exec env-example-695b759569-lx9jp -- printenv
+/ # env
+key=value # Custom environment variable
+key1=configmap_value # Added from ConfigMap key
+key2=secret_value # Added from secret key
+key3=env-example-695b759569-lx9jp # metadata.name defined by the pod
+key4=1 # limits.cpu defined by container1. The value is rounded up, in unit of cores.
+configmap_key=configmap_value # Added from ConfigMap. The key value in the original ConfigMap key is directly imported.
+secret_key=secret_value # Added from key. The key value in the original secret is directly imported.
+
+
Configuring a Workload Upgrade Policy
+In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.
+
Configuring the Workload Upgrade Policy on the Console
- When creating a workload, click Expand.
- Configure the workload upgrade policy based on Table 1.
+
Table 1 Parameters for configuring the workload upgrade policyParameter
+ |
+Description
+ |
+
|---|
+
+Upgrade Mode
+ |
+You can set different upgrade policies:
+- Rolling upgrade: New pods are created gradually and then old pods are deleted. This is the default policy.
- Replace upgrade: The current pods are deleted and then new pods are created.
+ |
+
+Max. Unavailable Pods (maxUnavailable)
+ |
+Specifies the maximum number of pods that can be unavailable during the upgrade process. The default value is 25%. For example, if spec.replicas is set to 4, at least 3 pods exist during the upgrade process. The deletion step is 1. The value can also be set to an absolute number.
+This parameter is only available for Deployments.
+ |
+
+Max. Surge (maxSurge)
+ |
+Specifies the maximum number of pods that can exist over spec.replicas. The default value is 25%. For example, if spec.replicas is set to 4, no more than 5 pods can exist during the upgrade process, that is, the upgrade step is 1. The absolute number is calculated from the percentage by rounding up. The value can also be set to an absolute number.
+This parameter is only available for Deployments.
+ |
+
+Min. Ready Seconds (minReadySeconds)
+ |
+A pod is considered available only when the minimum readiness time is exceeded without any of its containers crashing. The default value is 0 (the pod is considered available immediately after it is ready).
+ |
+
+Revision History Limit (revisionHistoryLimit)
+ |
+Specifies the number of old ReplicaSets to retain to allow rollback. These old ReplicaSets consume resources in etcd and crowd the output of kubectl get rs. The configuration of each Deployment revision is stored in its ReplicaSets. Therefore, once the old ReplicaSet is deleted, you lose the ability to roll back to that revision of the Deployment. By default, 10 old ReplicaSets will be kept, but the ideal value depends on the frequency and stability of the new Deployments.
+ |
+
+Max. Upgrade Duration (progressDeadlineSeconds)
+ |
+Specifies the number of seconds that the system waits for a Deployment to make progress before reporting a Deployment progress failure. It is surfaced as a condition with Type=Progressing, Status=False, and Reason=ProgressDeadlineExceeded in the status of the resource. The Deployment controller will keep retrying the Deployment. In the future, once automatic rollback will be implemented, the Deployment controller will roll back a Deployment as soon as it observes such a condition.
+If this parameter is specified, the value of this parameter must be greater than that of .spec.minReadySeconds.
+ |
+
+Scale-In Time Window (terminationGracePeriodSeconds)
+ |
+Graceful deletion time. The default value is 30 seconds. When a pod is deleted, a SIGTERM signal is sent and the system waits for the applications in the container to terminate. If the application is not terminated within the time specified by terminationGracePeriodSeconds, a SIGKILL signal is sent to forcibly terminate the pod.
+ |
+
+
+
+
+
+
Rolling Back the Workload Version on the Console
Rollback is to roll an application back to the source version when a fault occurs during the upgrade. A Deployment can be easily rolled back to the source version.
+
- On the cluster details page, choose Workloads and click the name of the workload to be rolled back.
- Click the Change History tab, locate the target version, click Roll Back to This Version, and click OK. Wait until the workload version is rolled back.
+
+
Configuring the Workload Upgrade Policy Using the CLI
The Deployment can be upgraded in a declarative mode. That is, you only need to modify the YAML definition of the Deployment. For example, you can run the kubectl edit command to change the Deployment image to nginx:alpine. After the modification, query the ReplicaSet and pod. The query result shows that a new ReplicaSet is created and the pod is re-created.
+
$ kubectl edit deploy nginx
+
+$ kubectl get rs
+NAME DESIRED CURRENT READY AGE
+nginx-6f9f58dffd 2 2 2 1m
+nginx-7f98958cdf 0 0 0 48m
+
+$ kubectl get pods
+NAME READY STATUS RESTARTS AGE
+nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m
+nginx-6f9f58dffd-tesqr 1/1 Running 0 1m
+
The Deployment can use the maxSurge and maxUnavailable parameters to control the proportion of pods to be re-created during the upgrade, which is useful in many scenarios. The configuration is as follows:
+
spec:
+ strategy:
+ rollingUpdate:
+ maxSurge: 1
+ maxUnavailable: 0
+ type: RollingUpdate
+
In the preceding example, the value of spec.replicas is 2. If both maxSurge and maxUnavailable are the default value 25%, maxSurge allows a maximum of three pods to exist (2 × 1.25 = 2.5, rounded up to 3), and maxUnavailable does not allow a maximum of two pods to be unavailable (2 × 0.75 = 1.5, rounded up to 2). During the upgrade process, there will always be two pods running. Each time a new pod is created, an old pod is deleted, until all pods are new.
+
+
Rolling Back the Workload Version Using the CLI
For example, if the upgraded image is faulty, you can run the kubectl rollout undo command to roll back the Deployment.
+
$ kubectl rollout undo deployment nginx
+deployment.apps/nginx rolled back
+
A Deployment can be easily rolled back because it uses a ReplicaSet to control a pod. After the upgrade, the previous ReplicaSet still exists. The Deployment is rolled back by using the previous ReplicaSet to re-create the pod. The number of ReplicaSets stored in a Deployment can be restricted by the revisionHistoryLimit parameter. The default value is 10.
+
+
Scheduling Policy (Affinity/Anti-affinity)
+When creating a workload, you can use a nodeSelector to constrain pods to nodes with particular labels. The affinity and anti-affinity features greatly increase the types of constraints you can express.
+
Kubernetes supports node-level and pod-level affinity and anti-affinity. You can configure custom rules to achieve affinity and anti-affinity scheduling. For example, you can deploy frontend pods and backend pods together, deploy the same type of applications on a specific node, or deploy different applications on different nodes.
+
Node Affinity (nodeAffinity)
You can use a nodeSelector to constrain pods to nodes with specific labels. The following example shows how to use a nodeSelector to deploy pods only on the nodes with the gpu=true label.
+
apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+spec:
+ nodeSelector: # Node selection. A pod is deployed on a node only when the node has the gpu=true label.
+ gpu: true
+...
+
Node affinity rules can achieve the same results, as shown in the following example.
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: gpu
+ labels:
+ app: gpu
+spec:
+ selector:
+ matchLabels:
+ app: gpu
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: gpu
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: gpu
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: gpu
+ operator: In
+ values:
+ - "true"
+
+
Even though the node affinity rule requires more lines, it is more expressive, which will be further described later.
+
requiredDuringSchedulingIgnoredDuringExecution seems to be complex, but it can be easily understood as a combination of two parts.
+
- requiredDuringScheduling indicates that pods can be scheduled to the node only when all the defined rules are met (required).
- IgnoredDuringExecution indicates that pods already running on the node do not need to meet the defined rules. That is, a label on the node is ignored, and pods that require the node to contain that label will not be re-scheduled.
+
In addition, the value of operator is In, indicating that the label value must be in the values list. Other available operator values are as follows:
+
- NotIn: The label value is not in a list.
- Exists: A specific label exists.
- DoesNotExist: A specific label does not exist.
- Gt: The label value is greater than a specified value (string comparison).
- Lt: The label value is less than a specified value (string comparison).
+
Note that there is no such thing as nodeAntiAffinity because operators NotIn and DoesNotExist provide the same function.
+
The following describes how to check whether the rule takes effect. Assume that a cluster has three nodes.
+
$ kubectl get node
+NAME STATUS ROLES AGE VERSION
+192.168.0.212 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.94 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.97 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+
Add the gpu=true label to the 192.168.0.212 node.
+
$ kubectl label node 192.168.0.212 gpu=true
+node/192.168.0.212 labeled
+
+$ kubectl get node -L gpu
+NAME STATUS ROLES AGE VERSION GPU
+192.168.0.212 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
+192.168.0.94 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.97 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+
Create the Deployment. You can find that all pods are deployed on the 192.168.0.212 node.
+
$ kubectl create -f affinity.yaml
+deployment.apps/gpu created
+
+$ kubectl get pod -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+gpu-6df65c44cf-42xw4 1/1 Running 0 15s 172.16.0.37 192.168.0.212
+gpu-6df65c44cf-jzjvs 1/1 Running 0 15s 172.16.0.36 192.168.0.212
+gpu-6df65c44cf-zv5cl 1/1 Running 0 15s 172.16.0.38 192.168.0.212
+
+
Node Preference Rule
The preceding requiredDuringSchedulingIgnoredDuringExecution rule is a hard selection rule. There is another type of selection rule, that is, preferredDuringSchedulingIgnoredDuringExecution. It is used to specify which nodes are preferred during scheduling.
+
To achieve this effect, add a node attached with SAS disks to the cluster, add the DISK=SAS label to the node, and add the DISK=SSD label to the other three nodes.
+
$ kubectl get node -L DISK,gpu
+NAME STATUS ROLES AGE VERSION DISK GPU
+192.168.0.100 Ready <none> 7h23m v1.15.6-r1-20.3.0.2.B001-15.30.2 SAS
+192.168.0.212 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD true
+192.168.0.94 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD
+192.168.0.97 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD
+
Define a Deployment. Use the preferredDuringSchedulingIgnoredDuringExecution rule to set the weight of nodes attached with the SAS disk to 80 and nodes with the gpu=true label to 20. In this way, pods are preferentially deployed on the nodes attached with the SAS disk.
+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: gpu
+ labels:
+ app: gpu
+spec:
+ selector:
+ matchLabels:
+ app: gpu
+ replicas: 10
+ template:
+ metadata:
+ labels:
+ app: gpu
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: gpu
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ nodeAffinity:
+ preferredDuringSchedulingIgnoredDuringExecution:
+ - weight: 80
+ preference:
+ matchExpressions:
+ - key: DISK
+ operator: In
+ values:
+ - SSD
+ - weight: 20
+ preference:
+ matchExpressions:
+ - key: gpu
+ operator: In
+ values:
+ - "true"
+
After the deployment, you can find that five pods are deployed on the 192.168.0.212 node, and two pods are deployed on the 192.168.0.100 node.
+
$ kubectl create -f affinity2.yaml
+deployment.apps/gpu created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+gpu-585455d466-5bmcz 1/1 Running 0 2m29s 172.16.0.44 192.168.0.212
+gpu-585455d466-cg2l6 1/1 Running 0 2m29s 172.16.0.63 192.168.0.97
+gpu-585455d466-f2bt2 1/1 Running 0 2m29s 172.16.0.79 192.168.0.100
+gpu-585455d466-hdb5n 1/1 Running 0 2m29s 172.16.0.42 192.168.0.212
+gpu-585455d466-hkgvz 1/1 Running 0 2m29s 172.16.0.43 192.168.0.212
+gpu-585455d466-mngvn 1/1 Running 0 2m29s 172.16.0.48 192.168.0.97
+gpu-585455d466-s26qs 1/1 Running 0 2m29s 172.16.0.62 192.168.0.97
+gpu-585455d466-sxtzm 1/1 Running 0 2m29s 172.16.0.45 192.168.0.212
+gpu-585455d466-t56cm 1/1 Running 0 2m29s 172.16.0.64 192.168.0.100
+gpu-585455d466-t5w5x 1/1 Running 0 2m29s 172.16.0.41 192.168.0.212
+
+
In the preceding example, the node scheduling priority is as follows. Nodes with both SSD and gpu=true labels have the highest priority. Nodes with the SSD label but no gpu=true label have the second priority (weight: 80). Nodes with the gpu=true label but no SSD label have the third priority. Nodes without any of these two labels have the lowest priority.
+
Figure 1 Scheduling priority
+
From the preceding output, you can find that no pods of the Deployment are scheduled to node 192.168.0.94. This is because the node already has many pods on it and its resource usage is high. This also indicates that the preferredDuringSchedulingIgnoredDuringExecution rule defines a preference rather than a hard requirement.
+
Workload Affinity (podAffinity)
Node affinity rules affect only the affinity between pods and nodes. Kubernetes also supports configuring inter-pod affinity rules. For example, the frontend and backend of an application can be deployed together on one node to reduce access latency. There are also two types of inter-pod affinity rules: requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution.
+
Assume that the backend of an application has been created and has the app=backend label.
+
$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-dlrz8 1/1 Running 0 2m36s 172.16.0.67 192.168.0.100
+
You can configure the following pod affinity rule to deploy the frontend pods of the application to the same node as the backend pods.
+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: frontend
+ labels:
+ app: frontend
+spec:
+ selector:
+ matchLabels:
+ app: frontend
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: frontend
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: frontend
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ podAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - topologyKey: kubernetes.io/hostname
+ labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - backend
+
Deploy the frontend and you can find that the frontend is deployed on the same node as the backend.
+
$ kubectl create -f affinity3.yaml
+deployment.apps/frontend created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-dlrz8 1/1 Running 0 5m38s 172.16.0.67 192.168.0.100
+frontend-67ff9b7b97-dsqzn 1/1 Running 0 6s 172.16.0.70 192.168.0.100
+frontend-67ff9b7b97-hxm5t 1/1 Running 0 6s 172.16.0.71 192.168.0.100
+frontend-67ff9b7b97-z8pdb 1/1 Running 0 6s 172.16.0.72 192.168.0.100
+
The topologyKey field specifies the selection range. The scheduler selects nodes within the range based on the affinity rule defined. The effect of topologyKey is not fully demonstrated in the preceding example because all the nodes have the kubernetes.io/hostname label, that is, all the nodes are within the range.
+
To see how topologyKey works, assume that the backend of the application has two pods, which are running on different nodes.
+
$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-5bpd6 1/1 Running 0 23m 172.16.0.40 192.168.0.97
+backend-658f6cb858-dlrz8 1/1 Running 0 2m36s 172.16.0.67 192.168.0.100
+
Add the prefer=true label to nodes 192.168.0.97 and 192.168.0.94.
+
$ kubectl label node 192.168.0.97 prefer=true
+node/192.168.0.97 labeled
+$ kubectl label node 192.168.0.94 prefer=true
+node/192.168.0.94 labeled
+
+$ kubectl get node -L prefer
+NAME STATUS ROLES AGE VERSION PREFER
+192.168.0.100 Ready <none> 44m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.212 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.94 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
+192.168.0.97 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
+
Define topologyKey in the podAffinity section as prefer.
+
affinity:
+ podAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - topologyKey: prefer
+ labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - backend
+
The scheduler recognizes the nodes with the prefer label, that is, 192.168.0.97 and 192.168.0.94, and then finds the pods with the app=backend label. In this way, all frontend pods are deployed onto 192.168.0.97.
+
$ kubectl create -f affinity3.yaml
+deployment.apps/frontend created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-5bpd6 1/1 Running 0 26m 172.16.0.40 192.168.0.97
+backend-658f6cb858-dlrz8 1/1 Running 0 5m38s 172.16.0.67 192.168.0.100
+frontend-67ff9b7b97-dsqzn 1/1 Running 0 6s 172.16.0.70 192.168.0.97
+frontend-67ff9b7b97-hxm5t 1/1 Running 0 6s 172.16.0.71 192.168.0.97
+frontend-67ff9b7b97-z8pdb 1/1 Running 0 6s 172.16.0.72 192.168.0.97
+
+
Workload Anti-Affinity (podAntiAffinity)
Unlike the scenarios in which pods are preferred to be scheduled onto the same node, sometimes, it could be the exact opposite. For example, if certain pods are deployed together, they will affect the performance.
+
The following example defines an inter-pod anti-affinity rule, which specifies that pods must not be scheduled to nodes that already have pods with the app=frontend label, that is, to deploy the pods of the frontend to different nodes with each node has only one replica.
+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: frontend
+ labels:
+ app: frontend
+spec:
+ selector:
+ matchLabels:
+ app: frontend
+ replicas: 5
+ template:
+ metadata:
+ labels:
+ app: frontend
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: frontend
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ podAntiAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - topologyKey: kubernetes.io/hostname
+ labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - frontend
+
Deploy the frontend and query the deployment results. You can find that each node has only one frontend pod and one pod of the Deployment is Pending. This is because when the scheduler is deploying the fifth pod, all nodes already have one pod with the app=frontend label on them. There is no available node. Therefore, the fifth pod will remain in the Pending status.
+
$ kubectl create -f affinity4.yaml
+deployment.apps/frontend created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+frontend-6f686d8d87-8dlsc 1/1 Running 0 18s 172.16.0.76 192.168.0.100
+frontend-6f686d8d87-d6l8p 0/1 Pending 0 18s <none> <none>
+frontend-6f686d8d87-hgcq2 1/1 Running 0 18s 172.16.0.54 192.168.0.97
+frontend-6f686d8d87-q7cfq 1/1 Running 0 18s 172.16.0.47 192.168.0.212
+frontend-6f686d8d87-xl8hx 1/1 Running 0 18s 172.16.0.23 192.168.0.94
+
+
Configuring Scheduling Policies
- When creating a workload, click Scheduling in the Advanced Settings area.
+
Table 1 Node affinity settingsParameter
+ |
+Description
+ |
+
|---|
+
+Required
+ |
+This is a hard rule that must be met for scheduling. It corresponds to requiredDuringSchedulingIgnoredDuringExecution in Kubernetes. Multiple required rules can be set, and scheduling will be performed if only one of them is met.
+ |
+
+Preferred
+ |
+This is a soft rule specifying preferences that the scheduler will try to enforce but will not guarantee. It corresponds to preferredDuringSchedulingIgnoredDuringExecution in Kubernetes. Scheduling is performed when one rule is met or none of the rules are met.
+ |
+
+
+
+
- Under Node Affinity, Workload Affinity, and Workload Anti-Affinity, click
to add scheduling policies. In the dialog box displayed, add a policy directly or by specifying a node or an AZ.Specifying a node or an AZ is essentially implemented through labels. The
kubernetes.io/hostname label is used when you specify a node, and the
failure-domain.beta.kubernetes.io/zone label is used when you specify an AZ.
+
Table 2 Scheduling policy configurationParameter
+ |
+Description
+ |
+
|---|
+
+Label
+ |
+Node label. You can use the default label or customize a label.
+ |
+
+Operator
+ |
+The following relations are supported: In, NotIn, Exists, DoesNotExist, Gt, and Lt
+- In: A label exists in the label list.
- NotIn: A label does not exist in the label list.
- Exists: A specific label exists.
- DoesNotExist: A specific label does not exist.
- Gt: The label value is greater than a specified value (string comparison).
- Lt: The label value is less than a specified value (string comparison).
+ |
+
+Label Value
+ |
+Label value.
+ |
+
+Namespace
+ |
+This parameter is available only in a workload affinity or anti-affinity scheduling policy.
+Namespace for which the scheduling policy takes effect.
+ |
+
+Topology Key
+ |
+This parameter can be used only in a workload affinity or anti-affinity scheduling policy.
+Select the scope specified by topologyKey and then select the content defined by the policy.
+ |
+
+Weight
+ |
+This parameter can be set only in a Preferred scheduling policy.
+ |
+
+
+
+
+
+
+
Managing Clusters Not in the Fleet
+Clusters for which a fleet is not selected during registration or clusters removed from a fleet will be displayed on the Clusters Not in Fleet tab. This section describes how you can manage clusters that are not added to a fleet, including adding clusters to a fleet and add a permission policy for the fleet.
+
Registering Clusters to a Fleet
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Clusters Not in Fleet tab, click
in the upper right corner of the card view of the target cluster. - Select a fleet. A registered cluster will follow the fleet permissions policies, not its own ones.
- After you select a fleet, the current permission and adjusted permission are displayed. Confirm the information and click OK.
After the cluster is registered to a fleet, the cluster is displayed in the fleet and will be centrally managed by the fleet.
+
+
+
Adding Permissions
- Log in to the UCS console. In the navigation pane, choose Permissions.
- Select a cluster for which you want to add permissions from the drop-down list on the right.
+
+
+
- Click Add Permission in the upper right corner.
- In the window that slides from the right, confirm the cluster name, set Namespace (for example, select All namespaces), select the target user or user group, and set Permission Type.
- A user group can contain multiple users, and a user can be added to multiple user groups. A user has all the permissions of the user group that the user belongs to.
- Namespace: Select All namespaces or a specific namespace. All namespaces includes the existing namespace of the fleet and the namespace to be added to the fleet. If you select this option, you cannot select other namespaces. If you do not select this option, UCS provides several common namespaces, such as default, kube-system, and kube-public. You can also add a namespace, which should exist in the cluster.
+ - Click OK.
+
+
Unregistering a Cluster
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Clusters Not in Fleet tab, click
in the upper right corner of the card view of the target cluster. - In the Unregister Cluster dialog box, read the precautions carefully, confirm the risks, and click OK.
- (Optional) After an attached cluster is unregistered, run the following command to uninstall the agent component from the destination cluster:
kubectl -n kube-system delete deployments/proxy-agent secret/proxy-agent-cert
+
+
+
UCS Resource Permissions (IAM-based)
+UCS cluster- and fleet-level permissions are assigned based on IAM system-defined policies and custom policies. You can use user groups to assign permissions to IAM users.
+
- Cluster- and fleet-level permissions are configured only for cluster- and fleet-related resources (such as resources for the cluster management, fleet management, add-on management, policy center, configuration management, traffic distribution, container intelligent analysis, and other functions). You must also configure Kubernetes resource permissions to perform operations on Kubernetes resources (such as workloads and Services in a cluster).
- When you view a cluster or fleet on the UCS console, the information displayed depends on the Kubernetes resource permissions. If the Kubernetes resource permissions are not configured, you cannot view the resources in the cluster or fleet.
+
+
Prerequisites
- A user with the Security Administrator role (for example, your account) has all IAM permissions except role switching. Only these users can view user groups and their permissions on the Permissions page on the UCS console.
+
+
Configuration Description
On the UCS console, when you choose Permissions > Add Permission to create a user or user group, you will be directed to the IAM console to complete the process. After the user or user group is created and its permissions are configured, you can view the information on the Permissions page. This section describes the operations on IAM.
+
+
Process Flow
Figure 1 Process for assigning UCS permissions
+
- Create a user group and assign permissions.
On the IAM console, create a user group and grant it UCS permissions (UCS ReadOnlyAccess as an example).
+ UCS is a global service deployed in all physical regions. When granting permissions, set the authorization scope to All resources.
+
+ - Create a user and add it to the user group.
Create a user on the IAM console and add it to the user group created in 1.
+ - Log in and verify permissions.
Log in to the console as the created user and verify the permissions. (Assume that the user has only the UCS ReadOnlyAccess permissions.)
+- Choose Ubiquitous Cloud Native Service from the service list. In the navigation pane, choose Infrastructure > Fleets. If a message indicating that you do not have the access permissions is displayed when you create a fleet or register a cluster, the UCS ReadOnlyAccess permissions have taken effect.
- Choose another service (such as Elastic Cloud Server) from the service list. If a message indicating insufficient permissions is displayed, the UCS ReadOnlyAccess permissions have taken effect.
+
+
+
System-defined Roles
Roles are a type of coarse-grained authorization mechanism that defines service-level permissions based on user responsibilities. Only a limited number of service-level roles are available for authorization. However, roles are not an ideal choice for fine-grained authorization and secure access control.
+
The preset system role for UCS in IAM is UCS Administrator. When assigning this role to a user group, you must also select other roles and policies on which this role depends, such as Tenant Guest, Server Administrator, ELB Administrator, OBS Administrator, SFS Administrator, APM FullAccess, and SWR Admin.
+
+
System-defined Policies
The system-defined policies preset for UCS in IAM include UCS FullAccess, UCS CommonOperations, and UCS ReadOnlyAccess.
+
- UCS FullAccess: UCS administrator with full permissions, including creating permission policies and security policies
UCS FullAccess does not have the RBAC permissions of CCE clusters. You need to go to the Permissions page to grant permissions for CCE clusters.
+
+ - UCS CommonOperations: common operation permissions for UCS. Users with these permissions can create workloads and perform other operations.
- UCS ReadOnlyAccess: read-only permissions for UCS services
+
You can check the content of a system-defined policy to learn about its supported actions. An action is in the format of {service-name}:{resource-type}:{action}. The wildcard (*) is allowed, indicating all actions.
+
The following is an example of the UCS FullAccess policy. This policy contains all permissions for UCS, Cloud Container Engine (CCE), and SoftWare Repository for Container (SWR), and operation permissions on some resources of Application Operations Management (AOM), Simple Message Notification (SMN), Domain Name Service (DNS), and other services.
+
{
+ "Version": "1.1",
+ "Statement": [
+ {
+ "Action": [
+ "ucs:*:*",
+ "cce:*:*",
+ "swr:*:*",
+ "aom:*:get",
+ "aom:*:list",
+ "smn:*:list",
+ "dns:*:get*",
+ "dns:*:list*",
+ "dns:*:get",
+ "dns:*:list",
+ "dns:recordset:create",
+ "dns:recordset:delete",
+ "dns:recordset:update",
+ "dns:tag:get",
+ "lts:*:get",
+ "lts:*:list",
+ "apm:*:get",
+ "apm:*:list",
+ "vpcep:epservices:*",
+ "vpcep:connections:*",
+ "vpcep:endpoints:*",
+ "elb:*:get",
+ "elb:*:list",
+ "vpc:*:get",
+ "vpc:*:list",
+ "ief:*:get",
+ "ief:*:list",
+ "cgs:images:operate",
+ "cgs:*:get",
+ "cgs:*:list"
+ ],
+ "Effect": "Allow"
+ }
+ ]
+}
+
+
Least-Privilege Permissions Required by Each UCS Function
Services on OTC are interdependent, so UCS depends on other cloud services to implement some functions (such as image repository and domain name resolution). The preceding four system-defined policies are often used together with the roles or policies of other cloud services for refined authorization. When granting permissions to IAM users, the administrator must comply with the principle of least privilege. Table 1 lists the least-privilege permissions required by the Administrator, Operator, and Viewer roles to use each UCS function.
+
- If your OTC account is used to log in to the UCS console for the first time, you need to grant permissions to the account. Then, UCS will create an agency named ucs_admin_trust for you in IAM. Do not delete or modify the agency.
- If the user group that an IAM user belongs to is not granted any permissions, you cannot access the UCS console. Grant permissions by referring to Table 1.
- UCS FullAccess does not have the RBAC permissions of CCE clusters. You need to go to the Permissions page to grant permissions for CCE clusters as described in the following table.
+
+
+
Table 1 Least-privilege permissions required by each UCS functionFunction
+ |
+Permission Type
+ |
+Permissions
+ |
+Least-Privilege Permissions
+ |
+
|---|
+
+Fleets
+ |
+Administrator
+ |
+- Creating and deleting a fleet
- Registering an OTC cluster (CCE standard cluster or CCE Turbo cluster) or an attached cluster
- Unregistering a cluster
- Adding a cluster to or removing a cluster from a fleet
- Adding permissions for a cluster or fleet
- Enabling cluster federation and performing federation management operations (such as creating a workload and creating a DNS policy)
+ |
+UCS FullAccess
+ |
+
+Viewer
+ |
+Querying the list or details of clusters or fleets
+ |
+UCS ReadOnlyAccess
+ |
+
+OTC clusters
+ |
+Administrator
+ |
+Read-write permissions on OTC clusters and all Kubernetes resource objects (including nodes, workloads, jobs, and Services)
+ |
+UCS FullAccess + CCE Administrator
+
+ |
+
+Developer
+ |
+Read-write permissions on OTC clusters and most Kubernetes resource objects and read-only permissions on Kubernetes resource objects such as namespaces and resource quotas
+ |
+UCS CommonOperations + CCE Administrator
+ |
+
+Viewer
+ |
+Read-only permissions on OTC clusters and all Kubernetes resource objects (including nodes, workloads, jobs, and Services)
+ |
+UCS ReadOnlyAccess + CCE Administrator
+
+ |
+
+Attached clusters
+
+
+ |
+Administrator
+ |
+Read-write permissions on attached clusters and all Kubernetes resource objects (such as nodes, workloads, jobs, and Services)
+ |
+UCS FullAccess
+ |
+
+Developer
+ |
+Read-write permissions on attached clusters and most Kubernetes resource objects and read-only permissions on Kubernetes resource objects such as namespaces and resource quotas
+ |
+UCS CommonOperations + UCS RBAC permissions (The list permission for namespaces is required.)
+ |
+
+Viewer
+ |
+Read-only permissions on attached clusters and all Kubernetes resource objects (such as nodes, workloads, jobs, and Services)
+ |
+UCS ReadOnlyAccess + UCS RBAC permissions (The list permission for namespaces is required.)
+ |
+
+Image Repositories
+ |
+Administrator
+ |
+All permissions on SWR, including creating organizations, pushing images, viewing the image list or details, and pulling images
+ |
+SWR Administrator
+ |
+
+Permissions
+ |
+Administrator
+ |
+- Creating and deleting permissions
- Viewing the permission list or details
+ NOTE: When creating permissions, you need to grant the IAM ReadOnlyAccess permissions (read-only permissions on IAM) to IAM users to obtain the IAM user list.
+
+ |
+UCS FullAccess + IAM ReadOnlyAccess
+ |
+
+Viewer
+ |
+Viewing the permission list or details
+ |
+UCS ReadOnlyAccess + IAM ReadOnlyAccess
+ |
+
+
+
+
+
+
Custom Policies
Custom policies can be created as a supplement to the system-defined policies of UCS.
+
You can create custom policies in either of the following ways:
+
- Visual editor: Select cloud services, actions, resources, and request conditions without the need to know policy syntax.
- JSON: Create a JSON policy or edit an existing one.
+
The following lists examples of common UCS custom policies.
+
Examples
+
- Example 1: Creating a cluster
{
+ "Version": "1.1",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Action": [
+ "ucs:clusters:create"
+ ]
+ }
+ ]
+}
+ - Example 2: Denying cluster deletion
A policy with only "Deny" permissions must be used with other policies. If the permissions assigned to a user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.
+If you want to grant the UCSFullAccess permissions to a user but prevent the user from deleting clusters (ucs:clusters:delete), you can create a custom policy that denies cluster deletion. Then, attach this policy with the UCSFullAccess policy to the user. Since an explicit denial in any policy takes precedence over any allowances, the user will have permissions to perform all operations on clusters except for deleting them. The following is an example policy that denies cluster deletion:
+{
+ "Version": "1.1",
+ "Statement": [
+ {
+ "Effect": "Deny",
+ "Action": [
+ "ucs:clusters:delete"
+ ]
+ }
+ ]
+}
+ Example 3: Creating a custom policy containing multiple actions
+A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:
+{
+ "Version": "1.1",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Action": [
+ "ucs:clustergroups:create",
+ "ucs:ciaEvents:update",
+ "ucs:addonTemplates:delete"
+ ]
+ },
+ {
+ "Effect": "Allow",
+ "Action": [
+ "obs:bucket:GetBucketInventoryConfiguration",
+ "obs:bucket:CreateBucket"
+ ]
+ }
+ ]
+}
+
+
+
Overview
+Attached clusters refer to third-party Kubernetes clusters that comply with the Cloud Native Computing Foundation (CNCF) standard, such as AWS EKS clusters, Google Cloud GKE clusters, and Kubernetes clusters that are deployed and run by third parties.
+
Figure 1 shows the attached cluster management process.
Figure 1 Attached cluster management process
+
+
Access Mode
Cluster providers or on-premises data centers have different inbound port rules for attached clusters to prevent inbound traffic from ports other than the specific ones. UCS uses the cluster network agent to connect to clusters. You do not need to enable any inbound port on the firewall. Instead, only the cluster agent program is required to establish sessions with UCS in the outbound direction.
+
There are two methods with different advantages for attached clusters to connect to UCS:
+
+
+
HPA Policies
+Horizontal Pod Autoscaling (HPA) is a Kubernetes function that implements horizontal auto scaling of pods. It dynamically adjusts the number of workload pods based on the usage of workload resources. HPA supports system metrics (CPU and memory, depending on the metrics API) or custom metrics (depending on the custom metrics API).
+
For details about HPA working principles, see CCE User Guide.
+
Constraints
- At least one pod is available in the cluster for which an auto scaling policy is to be created. If no pod is available, the system automatically performs pod scale-out.
- A maximum of min(max(4, 2 x Number of current replicas), MaxReplicas) pods can be added to a cluster at a time.
- To use HPA, add-ons such as metrics-server or prometheus that can provide metrics APIs must be installed in the cluster. If Prometheus is used, you need to register Prometheus as the service that provides the metrics API. For details, see Providing Resource Metrics.
+
+
Procedure
- Log in to the UCS console. In the navigation pane, choose Fleets.
- Click the name of the fleet with federation enabled.
- Choose HPA Policies in the navigation pane, select the namespace to which the HPA policy belongs, and click Create HPA Policy in the upper right corner.
- Configure the parameters.
+
+Table 1 HPA policy parametersParameter
+ |
+Description
+ |
+
|---|
+
+Pod Range
+ |
+Enter the minimum and maximum numbers of pods. When the policy is triggered, the pods will be scaled within this range.
+- Min.: Enter an integer from 1 to 299.
- Max.: Enter an integer from 1 to 1500. The value must be greater than the minimum value.
+ |
+
+Stabilization Window
+ |
+The scaling operation is initiated only when the metric continuously reaches the desired value within stabilization window. By default, the stabilization window is 0 seconds for scale-out and 300 seconds for scale-in.
+- Scale-out: Enter an integer from 0 to 3600, in seconds.
- Scale-in: Enter an integer from 0 to 3600, in seconds.
+ |
+
+System rule
+ |
+If you want to scale pods for a workload based on system metrics, you need to configure this rule.
+- Metric Name: Select CPU usage or Memory usage.
- Expected Value: The scaling operation is triggered when the metric reaches the desired value.
+ |
+
+Custom rule
+ |
+If you want to scale pods for a workload based on custom metrics, you need to configure this rule.
+- Metric Name: Select a name from the drop-down list.
- Source: Select the object type described by the custom metric from the drop-down list. Currently, only Pod is supported.
- Expected Value: The scaling operation is triggered when the metric reaches the desired value.
+ CAUTION: - Custom rules can be created only for clusters 1.19 or later.
- Before using a custom rule, install the add-on that supports custom metric collection for the cluster. Ensure that the add-on can collect and report the custom metrics of the workloads.
+
+ |
+
+
+
+
If the message Metric server not installed is displayed, install the metrics-server add-on in the target cluster. For details, see Installing metrics-server.
+
+ - Click OK. After the policy is created, you can view it in the HPA policy list.
+
+
Related Operations
You can also perform operations described in
Table 2.
+
Table 2 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Viewing details
+ |
+- Select the namespace to which the HPA policy belongs.
- (Optional) Search for an HPA policy by its name.
- Click the name of an HPA policy to view its details, including basic information and policy information of each cluster.
+ |
+
+Viewing the YAML file
+ |
+Click View YAML in the row where the target HPA policy resides to view the YAML file of the HPA policy.
+ |
+
+Viewing events
+ |
+You can click View Event in the row where the target HPA policy resides to view the current Kubernetes events of the policy. Events are retained for one hour and then automatically deleted.
+ |
+
+Updating an HPA policy
+ |
+- Choose More > Update in the row where the target HPA policy resides.
- Modify information based on HPA policy parameters.
- Click OK to submit the modified information.
+ |
+
+Deleting an HPA policy
+ |
+Choose More > Delete in the row where the target HPA policy resides, and click Yes.
+ |
+
+Deleting HPA policies in batches
+ |
+- Select the HPA policies to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Installing metrics-server
The metrics-server add-on is an aggregator for monitoring data of core cluster resources. It can be easily installed in your clusters.
+
- Run the following command to install metrics-server:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
+ - Run the following command to check whether metrics-server is successfully installed:
kubectl get deployment metrics-server -n kube-system
+If information similar to the following is displayed, the installation is successful:
+NAME READY UP-TO-DATE AVAILABLE AGE
+metrics-server 1/1 1 1 6m
+
+
+
Cluster Federation
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0200.html b/docs/ucs/umn/ucs_01_0200.html
new file mode 100644
index 000000000..37b659fa7
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0200.html
@@ -0,0 +1,12 @@
+
+
+Overview
+UCS supports unified management of clusters across clouds and regions. The following types of clusters are supported:
+
- OTC clusters: CCE standard and CCE Turbo clusters
- Attached clusters: Third-party Kubernetes clusters that comply with Cloud Native Computing Foundation (CNCF) standards, such as AWS EKS clusters, Google Cloud GKE clusters, and self-managed Kubernetes clusters
+
UCS Clusters
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0254.html b/docs/ucs/umn/ucs_01_0254.html
new file mode 100644
index 000000000..6207ad1a3
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0254.html
@@ -0,0 +1,19 @@
+
+
+Workloads
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0255.html b/docs/ucs/umn/ucs_01_0255.html
new file mode 100644
index 000000000..4d899b398
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0255.html
@@ -0,0 +1,84 @@
+
+
+Deployments
+The federation function of UCS allows you to manage Kubernetes clusters in different regions or clouds, deploy applications globally in a unified manner, and deploy different workloads, such as Deployments, StatefulSets, and DaemonSets, to clusters in a federation.
+
Deployments are a type of workloads that do not store any data or status while running. An example of this is Nginx. You can create a Deployment using the console or kubectl.
+
Creating a Deployment
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Workloads. On the displayed page, click the Deployments tab. Then, click Create from Image.
To use an existing YAML file to create a Deployment, click Create from YAML in the upper right corner.
+
+ - Configure basic information about the workload.
- Type: Select Deployment.
- Name: name of the workload, which must be unique.
- Namespace: namespace that the workload belongs to. For details about how to create a namespace, see Creating a Namespace.
- Description: description of the workload.
- Pods: number of pods in each cluster of the multi-cluster workload. The default value is 2. Each workload pod consists of the same containers. On UCS, you can set an auto scaling policy to dynamically adjust the number of workload pods based on the workload resource usage.
+ - Configure the container settings for the workload.
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
+
Table 1 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container. - My Images: images in the image repository of the current region. If no images are available, click Upload Image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account. For details, see Sharing Private Images.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Storage.
- Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.
+- Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+ - (Optional) Click
in the Service Settings area to configure a Service for the workload.If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services and Ingresses.
+You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.
+- Name: name of the Service to be added. It is customizable and must be unique.
- Type
- ClusterIP: The Service is only reachable from within the cluster.
- NodePort: The Service can be accessed from any node in the cluster.
+ - Affinity (for node access only)
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number ranges from 30000 to 32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number ranges from 30000 to 32767. Ensure that the port is unique in a cluster.
+
+
+ - (Optional) Click Expand to set advanced settings for the workload.
- Upgrade: upgrade mode of the Deployment, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
- Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
- Replace upgrade: Old pods are deleted before new pods are created. Services will be interrupted during a replace upgrade.
+ - Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Configuring a Scheduling Policy (Affinity/Anti-affinity).
- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
- Toleration: When the node where the workload pods are located is unavailable for the specified amount of time, the pods will be rescheduled to other available nodes. By default, the toleration time window is 300s.
+ - Click Next: Scheduling and Differentiation. After selecting clusters to which the workload can be scheduled, configure the differentiated settings for the containers.
- Scheduling Policy
- Scheduling Mode
- Weight: Manually set the weight of each cluster. The number of pods in each cluster is allocated based on the configured weight.
- Auto balancing: The workload is automatically deployed in the selected clusters based on available resources.
+ - Cluster: Select clusters to which the workload can be scheduled. The number of clusters depends on your service requirements.
- If you use cluster weighted scheduling, you need to manually set the weight of each cluster. If you set the weight of a cluster to a value other than 0, the cluster is automatically selected as a cluster to which the workload can be scheduled. If you set it to 0, the workload will not be scheduled to the cluster. Weights cannot be set for clusters in abnormal state.
- If you use auto scaling, you can click a cluster to select it as a cluster to which the workload can be scheduled.
+
+ - Differentiated Settings
When deploying a workload in multiple clusters, you can configure differentiated settings for these clusters. Click 
in the upper right corner of a target cluster to configure differentiated settings. The configured differentiated container settings take effect only for this cluster.
+For parameter description, see Container Settings.
+
+ - After completing the settings, click Create Workload, then you can click Back to Workload List to view the created workload.
+
+
StatefulSets
+StatefulSets are a type of workloads that store data or status while running. Each pod in a StatefulSet is given a persistent identifier that remains even if the pod is migrated, destroyed, or restarted. StatefulSets do not support auto scaling and apply to scenarios that require persistent storage, such as etcd.
+
Creating a StatefulSet
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Workloads. On the displayed page, click the StatefulSets tab. Then, click Create from Image in the upper right corner.
To use an existing YAML file to create a StatefulSet, click Create from YAML in the upper right corner.
+
+ - Configure basic information about the workload.
- Type: Select StatefulSet.
- Name: name of the workload, which must be unique.
- Namespace: namespace that the workload belongs to. For details about how to create a namespace, see Creating a Namespace.
- Description: description of the workload.
- Pods: number of pods in each cluster of the multi-cluster workload. The default value is 2. Each workload pod consists of the same containers. On UCS, you can set an auto scaling policy to dynamically adjust the number of workload pods based on the workload resource usage.
+ - Configure the container settings for the workload.
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
+
Table 1 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container. - My Images: images in the image repository of the current region. If no images are available, click Upload Image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account. For details, see Sharing Private Images.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Storage.
- Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.
+- Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+ - Configure the headless Service parameters for the workload.
StatefulSet pods discover each other through headless Services. No cluster IP is allocated for a headless Service, and the DNS records of all pods are returned during query. In this way, the IP addresses of all pods can be queried.
+- Name: name of the Service corresponding to the workload for mutual access between workloads in the same cluster. This Service is used for internal discovery of pods, and does not require an independent IP address or load balancing.
- Port
- Port Name: name of the container port. You are advised to enter a name that indicates the function of the port.
- Service Port: port of the Service.
- Container Port: listening port of the container.
+
+ - (Optional) Click in the Service Settings area to configure a Service for the workload.
If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services and Ingresses.
+You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.
+- Name: name of the Service to be added. It is customizable and must be unique.
- Type
- ClusterIP: The Service is only reachable from within the cluster.
- NodePort: The Service can be accessed from any node in the cluster.
+ - Affinity (for node access only)
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number ranges from 30000 to 32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number ranges from 30000 to 32767. Ensure that the port is unique in a cluster.
+
+
+ - (Optional) Click Expand to set advanced settings for the workload.
- Upgrade Policy: upgrade mode of the StatefulSet, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
- Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
- Replace upgrade: You need to delete old pods manually before new pods are created. Services will be interrupted during a replace upgrade.
+ - Pod Management
- OrderedReady: The StatefulSet will launch, terminate, or scale pods sequentially. It will wait for the state of the pods to change to Running and Ready or completely terminated before it launches or terminates another pod.
- Parallel: The StatefulSet will launch or terminate all pods in parallel. It will not wait for the state of the pods to change to Running and Ready or completely terminated before it launches or terminates another pod.
+ - Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Configuring a Scheduling Policy (Affinity/Anti-affinity).
- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
+ - Click Next to configure the scheduling and differentiated settings for the selected clusters. After selecting clusters to which the workload can be scheduled, configure the differentiated settings for the containers.
- Scheduling Policy
- Scheduling Mode
- Replication: The workload will be deployed in all clusters selected below.
+ - Cluster: Click to select clusters to which the workload can be scheduled. The number of clusters depends on your service requirements.
+ - Differentiated Settings
When deploying a workload in multiple clusters, you can configure differentiated settings for these clusters. Click in the upper right corner of a target cluster to configure differentiated settings. The configured differentiated container settings take effect only for this cluster.
+For parameter description, see Container Settings.
+
+ - After completing the settings, click Create Workload.
+
+
DaemonSets
+A DaemonSet ensures that a pod runs on all (or some) nodes in a cluster. When a new node is added to the cluster, a pod will be automatically deployed on it. When a node is removed from the cluster, the pod on the node is also reclaimed. A typical use of a DaemonSet is running a log collection daemon on every node in the cluster. If a DaemonSet is deleted, all pods created by it will be deleted.
+
Creating a DaemonSet
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Workloads. On the displayed page, click the DaemonSets tab. Then, click Create from Image in the upper right corner.
To use an existing YAML file to create a DaemonSet, click Create from YAML in the upper right corner.
+
+ - Configure basic information about the workload.
- Type: Select DaemonSet.
- Name: name of the workload, which must be unique.
- Namespace: namespace that the workload belongs to. For details about how to create a namespace, see Creating a Namespace.
- Description: description of the workload.
+ - Configure the container settings for the workload.
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
+
Table 1 Basic information parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container. - My Images: images in the image repository of the current region. If no images are available, click Upload Image.
- Open Source Images: official images in the open source image repository.
- Shared Images: private images shared by another account. For details, see Sharing Private Images.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit of CPU or memory, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+
+
+
- Lifecycle: The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function. Currently, lifecycle callback functions, such as startup, post-start, and pre-stop are provided. For details, see Setting Container Lifecycle Parameters.
- Health Check: Set health check parameters to periodically check the health status of the container during container running. For details, see Setting Health Check for a Container.
- Environment Variable: Environment variables affect the way a running container will behave. Configuration items set by environment variables will not change if the pod lifecycle ends. For details, see Setting Environment Variables.
- Data Storage: Store container data using Local Volumes and PersistentVolumeClaims (PVCs). You are advised to use PVCs to store workload pod data on a cloud volume. If you store pod data on a local volume and a fault occurs on the node, the data cannot be restored. For details about container storage, see Storage.
- Security Context: Set container permissions to protect the system and other containers from being affected. Enter a user ID and the container will run with the user permissions you specify.
+- Image Access Credential: Select the credential for accessing the image repository. This credential is used only for accessing a private image repository. If the selected image is a public image, you do not need to select a secret. For details on how to create a secret, see Creating a Secret.
+ - (Optional) Click in the Service Settings area to configure a Service for the workload.
If your workload will be reachable to other workloads or public networks, add a Service to define the workload access type. The workload access type determines the network attributes of the workload. Workloads with different access types can provide different network capabilities. For details, see Services and Ingresses.
+You can also create a Service after creating a workload. For details, see ClusterIP and NodePort.
+- Name: name of the Service to be added. It is customizable and must be unique.
- Type
- ClusterIP: The Service is only reachable from within the cluster.
- NodePort: The Service can be accessed from any node in the cluster.
+ - Affinity (for node access only)
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port (for NodePort only): Port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number ranges from 30000 to 32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number ranges from 30000 to 32767. Ensure that the port is unique in a cluster.
+
+
+ - (Optional) Click Expand to set advanced settings for the workload.
- Upgrade: upgrade mode of the DaemonSet, including Replace upgrade and Rolling upgrade. For details, see Configuring a Workload Upgrade Policy.
- Rolling upgrade: An old pod is gradually replaced with a new pod. During the upgrade, service traffic is evenly distributed to the old and new pods to ensure service continuity.
- Replace upgrade: You need to delete old pods manually before new pods are created. Services will be interrupted during a replace upgrade.
+ - Scheduling: You can set affinity and anti-affinity to implement planned scheduling for pods. For details, see Configuring a Scheduling Policy (Affinity/Anti-affinity).
- Labels and Annotations: You can click Confirm to add a label or annotation for the pod. The key of the new label or annotation cannot be the same as that of an existing one.
+ - Click Next: Scheduling and Differentiation. After selecting clusters to which the workload can be scheduled, configure the differentiated settings for the containers.
- Scheduling Policy
- Scheduling Mode
- Replication: The workload will be deployed in all clusters selected below.
+ - Cluster: Click to select clusters to which the workload can be scheduled. The number of clusters depends on your service requirements.
+ - Differentiated Settings
When deploying a workload in multiple clusters, you can configure differentiated settings for these clusters. Click in the upper right corner of a target cluster to configure differentiated settings. The configured differentiated container settings take effect only for this cluster.
+For parameter description, see Container Settings.
+
+ - Click Create Workload.
+
+
Container Settings
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0259.html b/docs/ucs/umn/ucs_01_0259.html
new file mode 100644
index 000000000..e3a8fd3b3
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0259.html
@@ -0,0 +1,58 @@
+
+
+Setting Basic Container Information
+A workload is an abstract model of a group of pods. One pod can encapsulate one or more containers. You can click Add Container in the upper right corner to add multiple container images and set them separately.
+
+
Table 1 Image parametersParameter
+ |
+Description
+ |
+
|---|
+
+Container Name
+ |
+Name the container.
+ |
+
+Image Name
+ |
+Click Select Image and select the image used by the container.
+ |
+
+Image Tag
+ |
+Select the image tag to be deployed.
+ |
+
+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 in the node, it is pulled from the image repository.
+ |
+
+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 available for a container. Do not leave Limit unspecified. Otherwise, intensive use of container resources will occur and your workload may exhibit unexpected behavior.
+ |
+
+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.
+For details about Request and Limit, see Setting Container Specifications.
+ |
+
+Init Container
+ |
+Select whether to use the container as an init container.
+An init container is a special container that runs before app containers in a pod. For details, see Init Containers.
+ |
+
+
+
+
+
Setting Container Specifications
+Scenario
UCS allows you to set resource limits for added containers during workload creation. You can apply for and limit the CPU and memory quotas used by each pod in the workload.
+
+
Configuration Description
- CPU quotas:
+
Table 1 Description of CPU quotasParameter
+ |
+Description
+ |
+
|---|
+
+CPU request
+ |
+Minimum number of CPU cores required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to this node only when the total available CPU on the node is greater than or equal to the number of containerized CPU applications.
+ |
+
+CPU limit
+ |
+Maximum number of CPU cores available for a container.
+ |
+
+
+
+
Recommended configuration
+Actual available CPU of a node ≥ Sum of CPU limits of all containers of the current pod ≥ Sum of CPU requests of all containers on the current pod. You can view the actual available CPUs of a node by choosing Clusters in the navigation pane, clicking the name of the target cluster, and choosing Nodes on the displayed page.
+ - Memory quotas:
+
Table 2 Description of memory quotasParameter
+ |
+Description
+ |
+
|---|
+
+Memory request
+ |
+Minimum amount of memory required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to this node only when the total available memory on the node is greater than or equal to the number of containerized memory applications.
+ |
+
+Memory Limit
+ |
+Maximum amount of memory available for a container. When the memory usage exceeds the specified memory limit, the pod may be restarted, which affects the normal use of the workload.
+ |
+
+
+
+
Recommended configuration
+Actual available memory of a node ≥ Sum of memory limits of all containers on the current pod ≥ Sum of memory requests of all containers on the current pod. You can view the actual available memory of a node by choosing Clusters in the navigation pane, clicking the name of the target cluster, and choosing Nodes on the displayed page.
+
+
The allocatable resources are calculated based on the resource request value (Request), which indicates the upper limit of resources that can be requested by pods on this node, but does not indicate the actual available resources of the node. The calculation formula is as follows:
+
- Allocatable CPU = Total CPU – Requested CPU of all pods – Reserved CPU for other resources
- Allocatable memory = Total memory – Requested memory of all pods – Reserved memory for other resources
+
+
+
Example
Assume that a cluster contains a node with 4 cores and 8 GB. A workload containing two pods has been deployed on the cluster. The resources of the two pods (pods 1 and 2) are as follows: {CPU request, CPU limit, memory request, memory limit} = {1 core, 2 cores, 2 GB, 2 GB}.
+
The CPU and memory usage of the node is as follows:
+
- Allocatable CPU = 4 cores - (1 core requested by pod 1 + 1 core requested by pod 2) = 2 cores
- Allocatable memory = 8 GB - (2 GB requested by pod 1 + 2 GB requested by pod 2) = 4 GB
+
The remaining 2 cores and 4 GB can be used by the next new pod.
+
+
Setting Container Lifecycle Parameters
+Scenario
The lifecycle callback functions can be called in specific phases of the container. For example, if you want the container to perform a certain operation before stopping, set the corresponding function.
+
UCS 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 during image start. To run a specific command or rewrite the default image value, you must perform specific settings:
+
A Docker image has metadata that stores image information. If lifecycle commands and arguments are not set, UCS 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:
+
+
Table 1 Commands and arguments used to run a containerImage ENTRYPOINT
+ |
+Image CMD
+ |
+Command to Run a Container
+ |
+Parameters to Run a Container
+ |
+Command Executed
+ |
+
|---|
+
+[touch]
+ |
+[/root/test]
+ |
+Not set
+ |
+Not set
+ |
+[touch /root/test]
+ |
+
+[touch]
+ |
+[/root/test]
+ |
+[mkdir]
+ |
+Not set
+ |
+[mkdir]
+ |
+
+[touch]
+ |
+[/root/test]
+ |
+Not set
+ |
+[/opt/test]
+ |
+[touch /opt/test]
+ |
+
+[touch]
+ |
+[/root/test]
+ |
+[mkdir]
+ |
+[/opt/test]
+ |
+[mkdir /opt/test]
+ |
+
+
+
+
+
- Log in to the UCS console and access the Federation page. When creating a workload, configure container information and select Lifecycle.
- Enter a command and arguments on the Startup Command tab page.
+
Table 2 Container startup commandConfiguration Item
+ |
+Procedure
+ |
+
|---|
+
+Command
+ |
+Enter an executable command, for example, /run/server.
+If there are multiple commands, separate them with spaces. If the command contains a space, you need to add a quotation mark ("").
+ 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
+ |
+Enter the argument that controls the container running command, for example, --port=8080.
+You can add multiple arguments.
+ |
+
+
+
+
+
+
Post-Start Processing
- Log in to the UCS console and access the Federation page. When creating a workload, configure container information and select Lifecycle.
- Set the post-start processing parameters on the Post-Start tab page.
+
Table 3 Post-start processing parametersParameter
+ |
+Description
+ |
+
|---|
+
+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.
+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.
+ |
+
+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.
+ |
+
+
+
+
+
+
Pre-Stop Processing
- Log in to the UCS console and access the Federation page. When creating a workload, configure container information and select Lifecycle.
- Set the pre-start processing parameters on the Pre-Stop tab page.
+
Table 4 Pre-stop processing parametersParameter
+ |
+Description
+ |
+
|---|
+
+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 the uninstall.sh script will be executed before the container completes its execution and stops running.
+ |
+
+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.
+ |
+
+
+
+
+
+
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
+kind: Deployment
+metadata:
+ name: nginx
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: nginx
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ containers:
+ - image: nginx
+ command:
+ - sleep 3600 #Startup command
+ imagePullPolicy: Always
+ lifecycle:
+ postStart:
+ exec:
+ command:
+ - /bin/bash
+ - install.sh #Post-start command
+ preStop:
+ exec:
+ command:
+ - /bin/bash
+ - uninstall.sh #Pre-stop command
+ name: nginx
+ imagePullSecrets:
+ - name: default-secret
+
+
Setting Health Check for a Container
+Scenarios
Health check regularly checks the health status of containers during container running. If the health check function is not configured, a pod cannot detect application exceptions or automatically restart the application to restore it. This will result in a situation where the pod status is normal but the application in the pod is abnormal.
+
Kubernetes provides the following health check probes:
+
- Liveness probe (livenessProbe): checks whether a container is still alive. It is similar to the ps command that checks whether a process exists. If the liveness check of a container fails, the cluster restarts the container. If the liveness check is successful, no operation is executed.
- Readiness probe (readinessProbe): checks whether a container is ready to process user requests. Upon that the container is detected unready, service traffic will not be directed to the container. It may take a long time for some applications to start up before they can provide services. This is because that they need to load disk data or rely on startup of an external module. In this case, the application process is running, but the application cannot provide services. To address this issue, this health check probe is used. If the container readiness check fails, the cluster masks all requests sent to the container. If the container readiness check is successful, the container can be accessed.
+
+
Check Methods
- HTTP request
This health check mode can be used for containers that provide HTTP/HTTPS services. The cluster periodically initiates an HTTP/HTTPS GET request to such containers. If the return code of the HTTP/HTTPS response is within 200–399, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port and an HTTP/HTTPS request path.
+ - TCP
For a container that provides TCP communication services, the cluster periodically establishes a TCP connection to the container. If the connection is successful, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify a container listening port.
+For example, if you have a Nginx container with service port 80, after you specify TCP port 80 for container listening, the cluster will periodically initiate a TCP connection to port 80 of the container. If the connection is successful, the probe is successful. Otherwise, the probe fails.
+ - Command
CLI is an efficient tool for health check. When using the CLI, you must specify an executable command in a container. The cluster periodically runs the command in the container. If the command output is 0, the health check is successful. Otherwise, the health check fails.
+The CLI mode can be used to replace the HTTP request-based and TCP port-based health check.
+- For a TCP port, you can use a script to connect to a container port. If the connection is successful, the script returns 0. Otherwise, the script returns –1.
- For an HTTP request, you can use a script to run the wget command for a container.
wget http://127.0.0.1:80/health-check
+Check the return code of the response. If the return code is within 200–399, the script returns 0. Otherwise, the script returns –1.
+ - Put the program to be executed in the container image so that the program can be executed.
- If the command to be executed is a shell script, do not directly specify the script as the command, but add a script parser. For example, if the script is /data/scripts/health_check.sh, the program is sh/data/scripts/health_check.sh. The reason is that the cluster is not in the terminal environment when executing programs in a container.
+
+
+
+
+
Common Parameters
+
Table 1 Common parametersParameter
+ |
+Description
+ |
+
|---|
+
+Period (periodSeconds)
+ |
+Probe detection period, in seconds.
+For example, if this parameter is set to 30, the detection is performed every 30 seconds.
+ |
+
+Delay (initialDelaySeconds)
+ |
+Check delay time in seconds. Set this parameter according to the normal startup time of services.
+For example, if this parameter is set to 30, the health check will be started 30 seconds after the container is started. The time is reserved for containerized services to start.
+ |
+
+Timeout (timeoutSeconds)
+ |
+Timeout duration. Unit: second.
+For example, if this parameter is set to 10, the timeout wait time for performing a health check is 10s. If the wait time elapses, the health check is regarded as a failure. If the parameter is left blank or set to 0, the default timeout time is 1s.
+ |
+
+Success Threshold (successThreshold)
+ |
+Minimum consecutive successes for the probe to be considered successful after having failed.
+The default value is 1, which is also the minimum value.
+The value of this parameter is fixed to 1 in Liveness Probe.
+ |
+
+Failure Threshold (failureThreshold)
+ |
+Number of retry times when the detection fails.
+Giving up in case of liveness probe means to restart the container. In case of readiness probe the pod will be marked Unready.
+The default value is 3, and the minimum value is 1.
+ |
+
+
+
+
+
+
YAML Example
apiVersion: v1
+kind: Pod
+metadata:
+ labels:
+ test: liveness
+ name: liveness-http
+spec:
+ containers:
+ - name: liveness
+ image: nginx:alpine
+ args:
+ - /server
+ livenessProbe:
+ httpGet:
+ path: /healthz
+ port: 80
+ httpHeaders:
+ - name: Custom-Header
+ value: Awesome
+ initialDelaySeconds: 3
+ periodSeconds: 3
+ readinessProbe:
+ exec:
+ command:
+ - cat
+ - /tmp/healthy
+ initialDelaySeconds: 5
+ periodSeconds: 5
+
+
Setting Environment Variables
+Scenario
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 deployed, increasing flexibility in workload configuration.
+
The function of setting environment variables on UCS is the same as that of specifying ENV in a Dockerfile.
+
After a container is started, do not modify configurations in the container. If configurations in the container are modified (for example, passwords, certificates, and environment variables of a containerized application are added to the container), the configurations will be lost after the container restarts and container services will become abnormal. An example scenario of container restart is pod rescheduling due to node anomalies.
+
Configurations must be imported to a container as arguments. Otherwise, configurations will be lost after the container restarts.
+
+
Environment variables can be set in the following modes:
+
- Custom
- ConfigMap: Import all keys in a ConfigMap as environment variables.
- ConfigMap Key: Import a key in a ConfigMap as the value of an environment variable. For example, if you import configmap_value of configmap_key in ConfigMap configmap-example as the value of environment variable key1, an environment variable named key1 with its value is configmap_value exists in the container.
- Secret: Import all keys in a secret as environment variables.
- Secret Key: Import the value of a key in a secret as the value of an environment variable. For example, if you import secret_value of secret_key in secret secret-example as the value of environment variable key2, an environment variable named key2 with its value secret_value exists in the container.
- Variable/Variable Reference: Use the field defined by a pod as the value of the environment variable, for example, the pod name.
- Resource Reference: Use the field defined by a container as the value of the environment variable, for example, the CPU limit of the container.
+
+
Environment Variables
- Log in to the UCS console and access the Federation page. When creating a workload, configure container information and select Environment Variable.
- Configure environment variables.
+
+
YAML Example
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: env-example
+ namespace: default
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: env-example
+ template:
+ metadata:
+ labels:
+ app: env-example
+ spec:
+ containers:
+ - name: container-1
+ image: nginx:alpine
+ imagePullPolicy: Always
+ resources:
+ requests:
+ cpu: 250m
+ memory: 512Mi
+ limits:
+ cpu: 250m
+ memory: 512Mi
+ env:
+ - name: key # Custom name.
+ value: value
+ - name: key1 # Added from ConfigMap key.
+ valueFrom:
+ configMapKeyRef:
+ name: configmap-example
+ key: key1
+ - name: key2 # Added from secret key.
+ valueFrom:
+ secretKeyRef:
+ name: secret-example
+ key: key2
+ - name: key3 # Variable reference, which uses the field defined by a pod as the value of the environment variable.
+ valueFrom:
+ fieldRef:
+ apiVersion: v1
+ fieldPath: metadata.name
+ - name: key4 # Resource reference, which uses the field defined by a container as the value of the environment variable.
+ valueFrom:
+ resourceFieldRef:
+ containerName: container1
+ resource: limits.cpu
+ divisor: 1
+ envFrom:
+ - configMapRef: # Added from ConfigMap.
+ name: configmap-example
+ - secretRef: # Added from secret.
+ name: secret-example
+ imagePullSecrets:
+ - name: default-secret
+
+
Viewing Environment Variables
If the contents of configmap-example and secret-example are as follows:
+
$ kubectl get configmap configmap-example -oyaml
+apiVersion: v1
+data:
+ configmap_key: configmap_value
+kind: ConfigMap
+...
+
+$ kubectl get secret secret-example -oyaml
+apiVersion: v1
+data:
+ secret_key: c2VjcmV0X3ZhbHVl # c2VjcmV0X3ZhbHVl is the value of secret_value in Base64 mode.
+kind: Secret
+...
+
The environment variables in the pod are as follows:
+
$ kubectl get pod
+NAME READY STATUS RESTARTS AGE
+env-example-695b759569-lx9jp 1/1 Running 0 17m
+
+$ kubectl exec env-example-695b759569-lx9jp -- printenv
+/ # env
+key=value # Custom environment variable.
+key1=configmap_value # Added from ConfigMap key.
+key2=secret_value # Added from secret key.
+key3=env-example-695b759569-lx9jp # metadata.name defined by the pod.
+key4=1 # limits.cpu defined by container1. The value is rounded up, in unit of cores.
+configmap_key=configmap_value # Added from ConfigMap. The key value in the original ConfigMap key is directly imported.
+secret_key=secret_value # Added from key. The key value in the original secret is directly imported.
+
+
Configuring a Workload Upgrade Policy
+In actual applications, upgrade is a common operation. A Deployment, StatefulSet, or DaemonSet can easily support application upgrade.
+
You can set different upgrade policies:
+
- Rolling (RollingUpdate): New pods are created gradually and then old pods are deleted. This is the default policy.
- Replace (Recreate): The current pods are deleted and then new pods are created.
+
Upgrade Parameters
- Max. Surge (maxSurge)
Specifies the maximum number of pods that can exist over spec.replicas. The default value is 25%. For example, if spec.replicas is set to 4, no more than 5 pods can exist during the upgrade process, that is, the upgrade step is 1. The absolute number is calculated from the percentage by rounding up. The value can also be set to an absolute number.
+This parameter is available only when Rolling is selected for Deployments.
+ - Max. Unavailable Pods (maxUnavailable)
Specifies the maximum number of pods that can be unavailable during the upgrade process. The default value is 25%. For example, if spec.replicas is set to 4, at least 3 pods exist during the upgrade process. The deletion step is 1. The value can also be set to an absolute number.
+This parameter is available only when Rolling is selected for Deployments or DaemonSets.
+ - Min. Ready Seconds (minReadySeconds)
A pod is considered available only when the minimum readiness time is exceeded without any of its containers crashing. The default value is 0 (the pod is considered available immediately after it is ready).
+This parameter is available only to Deployments and DaemonSets.
+ - Revision History Limit (revisionHistoryLimit)
Specifies the number of old ReplicaSets to retain to allow rollback. These old ReplicaSets consume resources in etcd and crowd the output of kubectl get rs. The configuration of each workload revision is stored in its ReplicaSets. Therefore, once the old ReplicaSet is deleted, you lose the ability to roll back to that revision of the workload. By default, 10 old ReplicaSets will be kept, but the ideal value depends on the frequency and stability of the new workloads.
+ - Max. Upgrade Duration (progressDeadlineSeconds)
Specifies the number of seconds that the system waits for a Deployment to make progress before reporting a Deployment progress failure. It is surfaced as a condition with Type=Progressing, Status=False, and Reason=ProgressDeadlineExceeded in the status of the resource. The Deployment controller will keep retrying the Deployment. In the future, once automatic rollback will be implemented, the Deployment controller will roll back a Deployment as soon as it observes such a condition.
+If this parameter is specified, the value of this parameter must be greater than that of .spec.minReadySeconds.
+This parameter is only available for Deployments.
+ - Scale-In Time Window (terminationGracePeriodSeconds)
Graceful deletion time. The default value is 30 seconds. When a pod is deleted, a SIGTERM signal is sent and the system waits for the applications in the container to terminate. If the application is not terminated within the time specified by terminationGracePeriodSeconds, a SIGKILL signal is sent to forcibly terminate the pod.
+
+
+
Upgrade Example
The Deployment can be upgraded in a declarative mode. That is, you only need to modify the YAML definition of the Deployment. For example, you can run the kubectl edit command to change the Deployment image to nginx:alpine. After the modification, query the ReplicaSet and pod. The query result shows that a new ReplicaSet is created and the pod is re-created.
+
$ kubectl edit deploy nginx
+
+$ kubectl get rs
+NAME DESIRED CURRENT READY AGE
+nginx-6f9f58dffd 2 2 2 1m
+nginx-7f98958cdf 0 0 0 48m
+
+$ kubectl get pods
+NAME READY STATUS RESTARTS AGE
+nginx-6f9f58dffd-tdmqk 1/1 Running 0 1m
+nginx-6f9f58dffd-tesqr 1/1 Running 0 1m
+
The Deployment can use the maxSurge and maxUnavailable parameters to control the proportion of pods to be re-created during the upgrade, which is useful in many scenarios. The configuration is as follows:
+
spec:
+ strategy:
+ rollingUpdate:
+ maxSurge: 1
+ maxUnavailable: 0
+ type: RollingUpdate
+
In the preceding example, the value of spec.replicas is 2. If both maxSurge and maxUnavailable are the default value 25%, maxSurge allows a maximum of three pods to exist (2 × 1.25 = 2.5, rounded up to 3), and maxUnavailable does not allow a maximum of two pods to be unavailable (2 × 0.75 = 1.5, rounded up to 2). During the upgrade process, there will always be two pods running. Each time a new pod is created, an old pod is deleted, until all pods are new.
+
+
Rollback
Rollback is to roll an application back to the source version when a fault occurs during the upgrade. A Deployment can be easily rolled back to the source version.
+
For example, if the upgraded image is faulty, you can run the kubectl rollout undo command to roll back the Deployment.
+
$ kubectl rollout undo deployment nginx
+deployment.apps/nginx rolled back
+
A Deployment can be easily rolled back because it uses a ReplicaSet to control a pod. After the upgrade, the previous ReplicaSet still exists. The Deployment is rolled back by using the previous ReplicaSet to re-create the pod. The number of ReplicaSets stored in a Deployment can be restricted by the revisionHistoryLimit parameter. The default value is 10.
+
+
Configuring a Scheduling Policy (Affinity/Anti-affinity)
+Kubernetes supports affinity and anti-affinity scheduling at the node and pod levels. You can configure custom rules to achieve affinity and anti-affinity scheduling. For example, you can deploy frontend pods and backend pods together, deploy the same type of applications on a specific node, or deploy different applications on different nodes.
+
Configuring Scheduling Policies
- Log in to the UCS console and go to the Federation page.
- When creating a workload, click Scheduling in the Advanced Settings area.
+
Table 1 Node affinity settingsParameter
+ |
+Description
+ |
+
|---|
+
+Required
+ |
+A hard rule that must be met for scheduling. It corresponds to requiredDuringSchedulingIgnoredDuringExecution in Kubernetes. You can add multiple required rules, and scheduling will be performed if any of them is met.
+ |
+
+Preferred
+ |
+A soft rule specifying preferences that the scheduler will try to enforce but will not guarantee. It corresponds to preferredDuringSchedulingIgnoredDuringExecution in Kubernetes. You can add multiple preferred rules, and scheduling will be performed if any or none of them is met.
+ |
+
+
+
+
- Under Node affinity, Workload affinity, and Workload anti-affinity, click
to add scheduling policies.
+
Table 2 Scheduling policy configurationParameter
+ |
+Description
+ |
+
|---|
+
+Label Key
+ |
+Node label. You can use the default label or customize a label.
+ |
+
+Operator
+ |
+The following relations are supported: In, NotIn, Exists, DoesNotExist, Gt, and Lt
+- In: A label exists in the label list.
- NotIn: A label does not exist in the label list.
- Exists: A specific label exists.
- DoesNotExist: A specific label does not exist.
- Gt: The label value is greater than a specified value (string comparison).
- Lt: The label value is less than a specified value (string comparison).
+ |
+
+Label Value
+ |
+Label value.
+ |
+
+Namespace
+ |
+This parameter is available only in a workload affinity or anti-affinity scheduling policy.
+Namespace for which the scheduling policy takes effect.
+ |
+
+Topology Key
+ |
+This parameter is available only in a workload affinity or anti-affinity scheduling policy.
+Select the scope specified by topologyKey and then select the content defined by the policy.
+ |
+
+Weight
+ |
+This parameter can be set only in a Preferred scheduling policy.
+ |
+
+
+
+
+
+
Node Affinity (nodeAffinity)
In the pod template, you can configure nodeSelector to create a pod on a node with a specified label. The following example shows how to use a nodeSelector to deploy pods only on the nodes with the gpu=true label.
+
apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+spec:
+ nodeSelector: # Node selection. A pod is deployed only on the node with the gpu=true label.
+ gpu: true
+...
+
You can also use node affinity to do so.
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: gpu
+ labels:
+ app: gpu
+spec:
+ selector:
+ matchLabels:
+ app: gpu
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: gpu
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: gpu
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: gpu
+ operator: In
+ values:
+ - "true"
+
+
A node affinity rule contains more lines, but it is more expressive.
+
requiredDuringSchedulingIgnoredDuringExecution seems to be complex, but it can be easily understood as a combination of two parts.
+
- requiredDuringScheduling indicates that pods can be scheduled to the node only when all the defined selector rules are met.
- IgnoredDuringExecution means that if the node labels change after Kubernetes schedules the pod, the pod continues to run.
+
In addition, the operator In indicates that the label value must fall in the range specified by values. Other available operator values are as follows:
+
- NotIn: The label value is not in the specified list.
- Exists: A specific label exists.
- DoesNotExist: A specific label does not exist.
- Gt: The label value is greater than a specified value (string comparison).
- Lt: The label value is less than a specified value (string comparison).
+
Note that there is no such thing as nodeAntiAffinity because operators NotIn and DoesNotExist provide the same function.
+
The following describes how to check whether the rule takes effect. Assume that a cluster has three nodes.
+
$ kubectl get node
+NAME STATUS ROLES AGE VERSION
+192.168.0.212 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.94 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.97 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+
Add the gpu=true label to the 192.168.0.212 node.
+
$ kubectl label node 192.168.0.212 gpu=true
+node/192.168.0.212 labeled
+
+$ kubectl get node -L gpu
+NAME STATUS ROLES AGE VERSION GPU
+192.168.0.212 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
+192.168.0.94 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.97 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
+
Create the Deployment. You can find that all pods are deployed on the 192.168.0.212 node.
+
$ kubectl create -f affinity.yaml
+deployment.apps/gpu created
+
+$ kubectl get pod -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+gpu-6df65c44cf-42xw4 1/1 Running 0 15s 172.16.0.37 192.168.0.212
+gpu-6df65c44cf-jzjvs 1/1 Running 0 15s 172.16.0.36 192.168.0.212
+gpu-6df65c44cf-zv5cl 1/1 Running 0 15s 172.16.0.38 192.168.0.212
+
+
Node Preference Rule
The preceding requiredDuringSchedulingIgnoredDuringExecution rule is a hard rule. The other type, or a soft rule, is preferredDuringSchedulingIgnoredDuringExecution, which specifies which nodes are preferred during scheduling.
+
To achieve this effect, add a node with SSD disks installed to the cluster, add the DISK=SSD label to the node, and add the DISK=SAS label to another three nodes.
+
$ kubectl get node -L DISK,gpu
+NAME STATUS ROLES AGE VERSION DISK GPU
+192.168.0.100 Ready <none> 7h23m v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD
+192.168.0.212 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SAS true
+192.168.0.94 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SAS
+192.168.0.97 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SAS
+
Define a Deployment. Use the preferredDuringSchedulingIgnoredDuringExecution rule to set the weight of nodes with the SSD disk installed as 80 and nodes with the gpu=true label as 20. In this way, pods are preferentially deployed on the nodes with the SSD disk installed.
+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: gpu
+ labels:
+ app: gpu
+spec:
+ selector:
+ matchLabels:
+ app: gpu
+ replicas: 10
+ template:
+ metadata:
+ labels:
+ app: gpu
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: gpu
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ nodeAffinity:
+ preferredDuringSchedulingIgnoredDuringExecution:
+ - weight: 80
+ preference:
+ matchExpressions:
+ - key: DISK
+ operator: In
+ values:
+ - SSD
+ - weight: 20
+ preference:
+ matchExpressions:
+ - key: gpu
+ operator: In
+ values:
+ - "true"
+
After the deployment, you can find that five pods are deployed on the 192.168.0.212 node, and two pods are deployed on the 192.168.0.100 node.
+
$ kubectl create -f affinity2.yaml
+deployment.apps/gpu created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+gpu-585455d466-5bmcz 1/1 Running 0 2m29s 172.16.0.44 192.168.0.212
+gpu-585455d466-cg2l6 1/1 Running 0 2m29s 172.16.0.63 192.168.0.97
+gpu-585455d466-f2bt2 1/1 Running 0 2m29s 172.16.0.79 192.168.0.100
+gpu-585455d466-hdb5n 1/1 Running 0 2m29s 172.16.0.42 192.168.0.212
+gpu-585455d466-hkgvz 1/1 Running 0 2m29s 172.16.0.43 192.168.0.212
+gpu-585455d466-mngvn 1/1 Running 0 2m29s 172.16.0.48 192.168.0.97
+gpu-585455d466-s26qs 1/1 Running 0 2m29s 172.16.0.62 192.168.0.97
+gpu-585455d466-sxtzm 1/1 Running 0 2m29s 172.16.0.45 192.168.0.212
+gpu-585455d466-t56cm 1/1 Running 0 2m29s 172.16.0.64 192.168.0.100
+gpu-585455d466-t5w5x 1/1 Running 0 2m29s 172.16.0.41 192.168.0.212
+
+
In the preceding example, the node scheduling priority is as follows. Nodes with both SSD and gpu=true labels have the highest priority. Nodes with the SSD label but no gpu=true label have the second priority (weight: 80). Nodes with the gpu=true label but no SSD label have the third priority. Nodes without any of these two labels have the lowest priority.
+
Figure 1 Scheduling priority
+
From the preceding output, you can find that no pods of the Deployment are scheduled to node 192.168.0.94. This is because the node already has many pods on it and its resource usage is high. This also indicates that the preferredDuringSchedulingIgnoredDuringExecution rule defines a preference rather than a hard requirement.
+
Workload Affinity (podAffinity)
Node affinity rules affect only the affinity between pods and nodes. Kubernetes also supports configuring inter-pod affinity rules. For example, the frontend and backend of an application can be deployed together on one node to reduce access latency. There are also two types of inter-pod affinity rules: requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution.
+
Assume that the backend of an application has been created and has the app=backend label.
+
$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-dlrz8 1/1 Running 0 2m36s 172.16.0.67 192.168.0.100
+
You can configure the following pod affinity rule to deploy the frontend pods of the application to the same node as the backend pods.
+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: frontend
+ labels:
+ app: frontend
+spec:
+ selector:
+ matchLabels:
+ app: frontend
+ replicas: 3
+ template:
+ metadata:
+ labels:
+ app: frontend
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: frontend
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ podAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - topologyKey: kubernetes.io/hostname
+ labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - backend
+
Deploy the frontend and you can find that the frontend is deployed on the same node as the backend.
+
$ kubectl create -f affinity3.yaml
+deployment.apps/frontend created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-dlrz8 1/1 Running 0 5m38s 172.16.0.67 192.168.0.100
+frontend-67ff9b7b97-dsqzn 1/1 Running 0 6s 172.16.0.70 192.168.0.100
+frontend-67ff9b7b97-hxm5t 1/1 Running 0 6s 172.16.0.71 192.168.0.100
+frontend-67ff9b7b97-z8pdb 1/1 Running 0 6s 172.16.0.72 192.168.0.100
+
The topologyKey field specifies the selection range. The scheduler selects nodes within the range based on the affinity rule defined. The effect of topologyKey is not fully demonstrated in the preceding example because all the nodes have the kubernetes.io/hostname label, that is, all the nodes are within the range.
+
To see how topologyKey works, assume that the backend of the application has two pods, which are running on different nodes.
+
$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-5bpd6 1/1 Running 0 23m 172.16.0.40 192.168.0.97
+backend-658f6cb858-dlrz8 1/1 Running 0 2m36s 172.16.0.67 192.168.0.100
+
Add the prefer=true label to nodes 192.168.0.97 and 192.168.0.94.
+
$ kubectl label node 192.168.0.97 prefer=true
+node/192.168.0.97 labeled
+$ kubectl label node 192.168.0.94 prefer=true
+node/192.168.0.94 labeled
+
+$ kubectl get node -L prefer
+NAME STATUS ROLES AGE VERSION PREFER
+192.168.0.100 Ready <none> 44m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.212 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2
+192.168.0.94 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
+192.168.0.97 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
+
Define topologyKey in the podAffinity section as prefer.
+
affinity:
+ podAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - topologyKey: prefer
+ labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - backend
+
The scheduler recognizes the nodes with the prefer label, that is, 192.168.0.97 and 192.168.0.94, and then finds the pods with the app=backend label. In this way, all frontend pods are deployed onto 192.168.0.97.
+
$ kubectl create -f affinity3.yaml
+deployment.apps/frontend created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+backend-658f6cb858-5bpd6 1/1 Running 0 26m 172.16.0.40 192.168.0.97
+backend-658f6cb858-dlrz8 1/1 Running 0 5m38s 172.16.0.67 192.168.0.100
+frontend-67ff9b7b97-dsqzn 1/1 Running 0 6s 172.16.0.70 192.168.0.97
+frontend-67ff9b7b97-hxm5t 1/1 Running 0 6s 172.16.0.71 192.168.0.97
+frontend-67ff9b7b97-z8pdb 1/1 Running 0 6s 172.16.0.72 192.168.0.97
+
+
Workload Anti-Affinity (podAntiAffinity)
Unlike the scenarios in which pods are preferred to be scheduled onto the same node, sometimes, it could be the exact opposite. For example, if certain pods are deployed together, they will affect the performance.
+
The following example defines an inter-pod anti-affinity rule, which specifies that pods must not be scheduled to nodes that already have pods with the app=frontend label, that is, to deploy the pods of the frontend to different nodes with each node has only one replica.
+
apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: frontend
+ labels:
+ app: frontend
+spec:
+ selector:
+ matchLabels:
+ app: frontend
+ replicas: 5
+ template:
+ metadata:
+ labels:
+ app: frontend
+ spec:
+ containers:
+ - image: nginx:alpine
+ name: frontend
+ resources:
+ requests:
+ cpu: 100m
+ memory: 200Mi
+ limits:
+ cpu: 100m
+ memory: 200Mi
+ imagePullSecrets:
+ - name: default-secret
+ affinity:
+ podAntiAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ - topologyKey: kubernetes.io/hostname
+ labelSelector:
+ matchExpressions:
+ - key: app
+ operator: In
+ values:
+ - frontend
+
Deploy the frontend and query the deployment results. You can find that each node has only one frontend pod and one pod of the Deployment is Pending. This is because when the scheduler is deploying the fifth pod, all nodes already have one pod with the app=frontend label on them. There is no available node. Therefore, the fifth pod will remain in the Pending status.
+
$ kubectl create -f affinity4.yaml
+deployment.apps/frontend created
+
+$ kubectl get po -o wide
+NAME READY STATUS RESTARTS AGE IP NODE
+frontend-6f686d8d87-8dlsc 1/1 Running 0 18s 172.16.0.76 192.168.0.100
+frontend-6f686d8d87-d6l8p 0/1 Pending 0 18s <none> <none>
+frontend-6f686d8d87-hgcq2 1/1 Running 0 18s 172.16.0.54 192.168.0.97
+frontend-6f686d8d87-q7cfq 1/1 Running 0 18s 172.16.0.47 192.168.0.212
+frontend-6f686d8d87-xl8hx 1/1 Running 0 18s 172.16.0.23 192.168.0.94
+
+
ConfigMaps and Secrets
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0267.html b/docs/ucs/umn/ucs_01_0267.html
new file mode 100644
index 000000000..160ad287e
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0267.html
@@ -0,0 +1,99 @@
+
+
+ConfigMaps
+ConfigMaps allow you to decouple configuration files from container images to enhance the portability of workloads.
+
ConfigMaps provide the following benefits:
+
- Manage configurations for different environments and services.
- Deploy workloads in different environments. Multiple versions are supported for configuration files so that you can update and roll back workloads easily.
- Quickly import configurations in the form of files to containers.
+
- After a ConfigMap is created on the UCS console, it is in the undeployed state by default. You need to mount the ConfigMap when creating or updating a workload. For details, see ConfigMap.
- After a ConfigMap is mounted to a workload, a ConfigMap with the same name is created in each cluster to which the workload belongs.
+
+
Creating a ConfigMap
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose ConfigMaps and Secrets in the navigation pane and click the ConfigMaps tab.
- Select the namespace for which you want to create a ConfigMap and click Create ConfigMap in the upper right corner.
- Set the parameters listed in Table 1.
+
Table 1 Parameters for creating a ConfigMapParameter
+ |
+Description
+ |
+
|---|
+
+Name
+ |
+Name of a ConfigMap, which must be unique in a namespace.
+ |
+
+Namespace
+ |
+Namespace that the ConfigMap belongs to. The current namespace is used by default.
+ |
+
+Description
+ |
+Description of the ConfigMap.
+ |
+
+Data
+ |
+The workload configuration data can be used in a container or used to store the configuration data.
+Click  and enter the key and value. Key indicates the configuration name, and Value indicates the configuration content.
+ |
+
+Label
+ |
+Labels are attached to objects such as workloads, nodes, and Services in key-value pairs.
+Labels define identified attributes of these objects and can be used to manage and select objects.
+- Enter the label key and value.
- Click Confirm.
+ |
+
+
+
+
- Click OK.
+
+
Using a ConfigMap
After a ConfigMap is created, you can mount the ConfigMap to a container for storage during workload creation. Then, you can read the ConfigMap data from the mount path of the container. For details, see ConfigMap.
+
+
Related Operations
You can also perform operations described in
Table 2.
+
Table 2 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a ConfigMap from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a ConfigMap from an existing YAML file.
+ |
+
+Viewing details
+ |
+Click the ConfigMap name to view its details.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target ConfigMap resides to edit its YAML file.
+ |
+
+Updating a ConfigMap
+ |
+- Choose More > Update in the Operation column of the target ConfigMap.
- Modify the ConfigMap information according to Table 1.
- Click OK to submit the modified information.
+ |
+
+Deleting a ConfigMap
+ |
+Choose More > Delete in the row where the target ConfigMap resides, and click Yes.
+ |
+
+Deleting ConfigMaps in batches
+ |
+- Select the ConfigMaps to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Secrets
+A secret is a type of resource that holds sensitive data, such as authentication and key information. Its content is user-defined.
+
- After a secret is created on the UCS console, it is in the undeployed state by default. You need to mount the secret when creating or updating a workload. For details, see Secret.
- After a secret is mounted to a workload, a secret with the same name is created in each cluster to which the workload belongs.
+
+
Creating a Secret
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose ConfigMaps and Secrets in the navigation pane and click the Secrets tab.
- Select the namespace for which you want to create a secret and click Create Secret in the upper right corner.
- Set the parameters listed in Table 1.
+
Table 1 Parameters for creating a secretParameter
+ |
+Description
+ |
+
|---|
+
+Name
+ |
+Name of a secret, which must be unique in the same namespace.
+ |
+
+Namespace
+ |
+Namespace to which the secret belongs. The current namespace is used by default.
+ |
+
+Description
+ |
+Description of the secret.
+ |
+
+Type
+ |
+Type of the secret.
+- Opaque: common secret. In high-sensitive scenarios, you are advised to encrypt sensitive data using data encryption services and then store the encrypted data in secrets.
- kubernetes.io/dockerconfigjson: a secret that stores the authentication information required for pulling images from a private repository. If you select this secret type, enter the image repository address.
- IngressTLS: a secret that stores the certificate required by an ingress. If you select this secret type, upload the certificate file and private key file.
- Other: another type of secret, which is specified manually.
+ |
+
+Data
+ |
+Workload secret data can be used in containers.
+- If the secret type is Opaque, enter the key and value. The value must be a Base64-encoded value. You can select Auto Base64-encoded to Base64-encode the entered value. For details about manual Base64 encoding, see Base64 Encoding.
- If the secret type is kubernetes.io/dockerconfigjson, enter the username and password of the private image repository.
+ |
+
+Label
+ |
+Labels are attached to objects such as workloads, nodes, and Services in key-value pairs.
+Labels define identified attributes of these objects and can be used to manage and select objects.
+- Click Confirm.
- Enter the key and value.
+ |
+
+
+
+
- Click OK.
The new secret is displayed in the secret list.
+
+
+
Using a Secret
After a secret is created, you can mount the secret to a container for storage during workload creation. Then, you can read the secret data from the mount path of the container. For details, see Secret.
+
+
Base64 Encoding
To Base64-encode a string, run the echo -n Content to be encoded | base64 command. The following is an example:
+
echo -n "Content to be encoded" | base64
+
+
Related Operations
You can also perform operations described in
Table 2.
+
Table 2 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a secret from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a secret from an existing YAML file.
+ |
+
+Viewing details
+ |
+Click the secret name to view its details.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target secret resides to edit its YAML file.
+ |
+
+Updating a secret
+ |
+- Choose More > Update in the row where the target secret resides.
- Modify the secret information according to Table 1.
- Click OK to submit the modified information.
+ |
+
+Deleting a secret
+ |
+Choose More > Delete in the row where the target secret resides, and click Yes.
+ |
+
+Deleting secrets in batches
+ |
+- Select the secrets to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Services and Ingresses
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0270.html b/docs/ucs/umn/ucs_01_0270.html
new file mode 100644
index 000000000..d43dab348
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0270.html
@@ -0,0 +1,18 @@
+
+
+Overview
+UCS clusters allow workload access in different scenarios via Services and ingresses.
+
- After a Service or ingress is created on the UCS console, a Service or ingress with the same name will be created in the cluster that each associated workload belongs to.
- You can modify or delete the Services and ingresses automatically created by UCS on the cluster console. However, if the Service or ingress settings on the UCS console are not modified accordingly, the modified or deleted Services or ingresses will be re-created by UCS. Therefore, you are advised to change the settings on the UCS console, not the cluster console.
- When there is an exception in your cluster, Services in the cluster will be migrated to a healthy cluster. When your cluster recovers, you need to manually modify the Service template to deploy the Services again.
- When creating a LoadBalancer Service and ingress for a non-CCE cluster, you need to specify the annotations based on the load balancer connected to the cluster. Configure the annotations based on your service requirements and vendor requirements. For details, see Internal Load Balancer.
+
+
- ClusterIP
A workload can be accessed from other workloads in the same cluster through a cluster-internal domain name. A cluster-internal domain name is in the format of <User-defined Service name>.<Namespace of the workload>.svc.cluster.local, for example, nginx.default.svc.cluster.local.
+ - NodePort
A workload can be accessed from outside the cluster. A NodePort Service is exposed on each node's IP address at a static port. If a node in the cluster is bound to an EIP, workloads on the node can be accessed from public networks by requesting <EIP>:<NodePort>.
+ - LoadBalancer
A workload can be accessed from a public network through a load balancer. LoadBalancer provides higher reliability than EIP-based NodePort because the former needs no EIP. The access address is in the format of <IP address of public network load balancer>:<access port>, for example, 10.117.117.117:80.
+ - Ingress
Enhanced load balancer is used for an ingress. Compared with Layer-4 load balancing, Layer-7 load balancing supports Uniform Resource Identifier (URI) configurations and distributes access traffic to services based on URIs. In addition, different functions are implemented based on URIs. The access address is in the format of <IP address of public network load balancer>:<access port><defined URI>, for example, 10.117.117.117:80/helloworld.
+
+
ClusterIP
+A ClusterIP Service allows workloads in the same cluster to use their cluster-internal domain names to access each other. A cluster-internal domain name is in the format of <User-defined Service name>.<Namespace of the workload>.svc.cluster.local, for example, nginx.default.svc.cluster.local.
+
Creating a Service
You can create a Service in either of the following ways:
+
+
+
During Workload Creation
The procedure of creating a Service is the same for different types of workloads, such as Deployments, StatefulSets, and DaemonSets.
+
- In the Service Settings step of Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet, click
to configure the Service.- Name: Enter a Service name consisting of 1 to 50 characters.
- Type: Select ClusterIP.
- Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80.
+
+ - Click OK.
- Click Next: Set Scheduling and Differentiation to configure the scheduling and differentiated settings for the selected clusters. After completing the settings, click Create Workload.
- Obtain the access address.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, click the name of the added Service to go to its details page. Then, obtain the access address of the cluster.
+
+
+
After Workload Creation
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, select the namespace that the Service will belong to and click Create Service in the upper right corner. For details about how to create a namespace, see Creating a Namespace.
- Configure access parameters.
+
- Name: Can be the same as the workload name.
- Type: Select ClusterIP.
- Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
+ - Namespace: namespace that the Service belongs to.
- Selector: Services are associated with workloads (labels) through selectors. Click Reference Workload Label to reference the labels of an existing workload.
- Type: Select the desired workload type.
- Workload: Select an existing workload. If your workload is not displayed in the list, click
to refresh it. - Label: After a workload is selected, its labels are displayed and cannot be modified.
+
+
+
+
- Click OK. After the Service is created, you can view it in the list on the Services tab page.
+
+
Related Operations
You can also perform operations described in
Table 1.
+
Table 1 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a Service from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a Service from an existing YAML file.
+ |
+
+Viewing details
+ |
+- Select the namespace to which the Service belongs.
- (Optional) Search for a Service by its name.
- Click the Service name to view its details, including the basic information and cluster deployment information.
- On the Service Details page, click View YAML in the Cluster area to view or download YAML files of Service instances deployed in each cluster.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target Service resides to view and edit the YAML file of the Service.
+ |
+
+Updating a Service
+ |
+- Choose More > Update in the row where the target Service resides.
- Modify the information by referring to 5.
- Click OK to submit the modified information.
+ |
+
+Deleting a Service
+ |
+Choose More > Delete in the row where the target Service resides, and click Yes.
+ |
+
+Deleting Services in batches
+ |
+- Select the Services to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
NodePort
+A NodePort Service is exposed on a node at a static port, allowing access from outside the cluster to the workloads on the node. A ClusterIP Service, to which the NodePort Service routes, is automatically created, and it transfers access requests to the backing containers. If a node in the cluster is bound to an EIP, you can also request <EIP>:<NodePort> to access the workloads from public networks.
+
Creating a Service
You can create a Service in either of the following ways:
+
+
+
During Workload Creation
The procedure of creating a Service is the same for different types of workloads, such as Deployments, StatefulSets, and DaemonSets.
+
- In the Service Settings step of Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet, click
to configure the Service.- Name: Enter a Service name consisting of 1 to 50 characters.
- Type: Select NodePort.
- Affinity
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port: Specify a port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number range is 30000–32767. Ensure that the port is unique in a cluster.
+
+
+ - Click OK.
- Click Next: Set Scheduling and Differentiation to configure the scheduling and differentiated settings for the selected clusters. After completing the settings, click Create Workload.
- Obtain the access address.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, click the name of the added Service to go to its details page. Then, obtain the access address of the cluster. If a node in the cluster is bound to an EIP, you can access the backend workload through the EIP and node port of the node where the workload is deployed.
+
+
+
After Workload Creation
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, select the namespace that the Service will belong to and click Create Service in the upper right corner. For details about how to create a namespace, see Creating a Namespace.
- On the Services tab, click Create Service. Then, configure the parameters.
+
- Name: Can be the same as the workload name.
- Type: Select NodePort.
- Affinity
- Cluster-level: The IP addresses and access ports of all nodes in a cluster can be used to access the workloads associated with the Service. However, performance loss is introduced due to hops, and source IP addresses cannot be obtained.
- Node-level: Only the IP address and access port of the node where the workload is located can be used to access the workload associated with the Service. Service access will not cause performance loss due to route redirection, and the source IP address of the client can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Port mapped to the container port at the cluster-internal IP address. The application can be accessed at <cluster-internal IP address>:<access port>. The port number range is 1–65535.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
- Node Port: Specify a port to which the container port will be mapped when the node private IP address is used for accessing the application. The port number range is 30000–32767. You are advised to select Auto.
- Auto: The system automatically assigns a port number.
- Custom: Specify a fixed node port. The port number ranges from 30000 to 32767. Ensure that the port is unique in a cluster.
+
+ - Namespace: namespace that the Service belongs to.
- Selector: Services are associated with workloads (labels) through selectors. Click Reference Workload Label to reference the labels of an existing workload.
- Type: Select the desired workload type.
- Workload: Select an existing workload. If your workload is not displayed in the list, click to refresh it.
- Label: After a workload is selected, its labels are displayed and cannot be modified.
+
+
+
+
- Click OK. After the Service is created, you can view it in the list on the Services tab page.
- Obtain the access address.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, click the name of the added Service to go to its details page. Then, obtain the access address of the cluster. If a node in the cluster is bound to an EIP, you can access the backend workload through the EIP and node port of the node where the workload is deployed.
+
+
+
Related Operations
You can also perform operations described in
Table 1.
+
Table 1 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a Service from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a Service from an existing YAML file.
+ |
+
+Viewing details
+ |
+- Select the namespace to which the Service belongs.
- (Optional) Search for a Service by its name.
- Click the Service name to view its details, including the basic information and cluster deployment information.
- On the Service Details page, click View YAML in the Cluster area to view or download YAML files of Service instances deployed in each cluster.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target Service resides to view and edit the YAML file of the Service.
+ |
+
+Updating a Service
+ |
+- Choose More > Update in the row where the target Service resides.
- Modify the information by referring to 5.
- Click OK to submit the modified information.
+ |
+
+Deleting a Service
+ |
+Choose More > Delete in the row where the target Service resides, and click Yes.
+ |
+
+Deleting Services in batches
+ |
+- Select the Services to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
LoadBalancer
+A workload can be accessed from a public network through a load balancer. This access type is applicable to Services that need to be exposed to a public network in the system. The access address is in the format of <IP address of public network load balancer>:<access port>, for example, 10.117.117.117:80.
+
Prerequisites
A workload is available. If no workload is available, create one by following the procedure described in Workloads.
+
+
Creating a Service
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, select the namespace that the Service will belong to and click Create Service in the upper right corner. For details about how to create a namespace, see Creating a Namespace.
- On the Services tab, click Create Service. Then, configure the parameters.
+
- Name: Enter a Service name consisting of 1 to 50 characters.
- Type: Select LoadBalancer.
- Affinity
- Cluster-level: The IP addresses and ports of all nodes in a cluster can access the workload associated with the Service. However, accessing the Service may result in a performance decrease due to route redirection, and the client's source IP address may not be obtainable.
- Node-level: Only the IP address and port of the node where the workload is located can access the workload associated with the Service. Accessing the Service will not result in a performance decrease due to route redirection, and client's source IP address can be obtained.
+ - Port
- Protocol: Select TCP or UDP.
- Service Port: Specify a port to map a container port to the load balancer. The port range is 1–65535. The port will be used when the application is accessed through the load balancer.
- Container Port: Port on which the workload listens, defined in the container image. For example, the Nginx application listens on port 80 (container port).
+ - Cluster: Add a cluster where load balancers are to be deployed and complete differentiated load balancer settings.
- CCE cluster:
- Load Balancer: Only load balancers in the VPC where the cluster resides are supported.
- Algorithm
Weighted round robin: Distributes requests to backend servers based on weights.
+Weighted least connections: Distributes requests to backend servers with the smallest ratio (current connections divided by weight).
+Source IP hash: Allocates requests from the client IP address to a fixed server, allowing the entire session to be processed by the same server.
+ - Sticky Session: This function is disabled by default. You can select Source IP. Listeners ensure session stickiness based on IP addresses. Requests from the same IP address will be routed to the same backend server.
- Health Check: This function is disabled by default. You can select either HTTP or TCP to enable health checks for your load balancer. For details about the parameters, see Table 1.
+
Table 1 Health check parametersParameter
+ |
+Description
+ |
+Example
+ |
+
|---|
+
+Check Path
+ |
+This parameter is available if you have selected HTTP for Health Check. Specify the URL for health checks. The check path must start with a slash (/) and contain 1 to 80 characters.
+ |
+/
+ |
+
+Port
+ |
+Health check port. The port number ranges from 1 to 65535.
+By default, the Service ports (node port and container port of the NodePort Service) are used.
+ |
+80
+ |
+
+Check Interval (s)
+ |
+Maximum time between health checks, in seconds.
+The value ranges from 1 to 50.
+ |
+5
+ |
+
+Timeout (s)
+ |
+Maximum time required for waiting for a response from the health check, in seconds.
+The value ranges from 1 to 50.
+ |
+10
+ |
+
+Max. Retries
+ |
+Maximum number of health check retries. The value ranges from 1 to 10.
+ |
+5
+ |
+
+
+
+
+
+
+ - Other clouds
- Ingress Class: You can select an existing ingress class or manually enter an ingress class name. For details, see Ingress.
- Annotation: Enter an annotation in a key-value pair based on your service and vendor requirements.
+ - To create an internal load balancer, add the annotation based on the cloud service provider of your cluster. For details, see Internal load balancer.
+ - Namespace: namespace that the Service belongs to.
- Selector: Services are associated with workloads (labels) through selectors. Click Reference Workload Label to reference the labels of an existing workload.
- Type: Select the desired workload type.
- Workload: Select an existing workload. If your workload is not displayed in the list, click to refresh it.
- Label: After a workload is selected, its labels are displayed and cannot be modified.
+
+
+
+
- Click OK.
- Obtain the access address.
- In the navigation pane, choose Services and Ingresses.
- On the Services tab, click the name of the added Service to go to its details page. Then, obtain the access address of the cluster. You can access a backend pod using the EIP and port number of the load balancer.
+
+
+
Related Operations
You can also perform operations described in
Table 2.
+
Table 2 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a Service from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a Service from an existing YAML file.
+ |
+
+Viewing details
+ |
+- Select the namespace that the Service belongs to.
- (Optional) Search for a Service by its name.
- Click the Service name to view its details, including the basic information and cluster deployment information.
- On the Service Details page, click View YAML in the Cluster area to view or download YAML files of Service instances deployed in each cluster.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target Service resides to view and edit the YAML file of the Service.
+ |
+
+Updating a Service
+ |
+- Choose More > Update in the row where the target Service resides.
- Modify the information by referring to 5.
- Click OK to submit the modified information.
+ |
+
+Deleting a Service
+ |
+Choose More > Delete in the row where the target Service resides, and click Yes.
+ |
+
+Deleting Services in batches
+ |
+- Select the Services to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Ingresses
+An ingress uses load balancers as the entry for external traffic. Compared with Layer-4 load balancing, it supports Uniform Resource Identifier (URI) configurations and distributes access traffic to services based on URIs. You can create custom forwarding rules based on domain names and URLs for the fine-grained distribution of access traffic. The access address is in the format of <IP address of public network load balancer>:<access port><defined URI>, for example, 10.117.117.117:80/helloworld.
+
Prerequisites
A workload is available. If no workload is available, create one by following the procedure described in Workloads.
+
+
Creating an Ingress
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Services and Ingresses. Then, click the Ingresses tab.
- Select the namespace that the ingress will belong to and click Create Ingress in the upper right corner. For details about how to create a namespace, see Creating a Namespace.
- Configure ingress parameters.
- Ingress Name: name of the ingress to be created.
- Namespace: namespace that the ingress belongs to.
- Interconnect with Nginx: There are ELB Ingress Controller and Nginx Ingress Controller. Both of them are supported in UCS. ELB Ingress Controller forwards traffic through ELB. Nginx Ingress Controller uses the templates and images maintained by the Kubernetes community to forward traffic through the Nginx component.
- ELB Ingress: Do not enable Interconnect with Nginx.
- Nginx Ingress: Click
to enable Interconnect with Nginx.
+ - Listener: Select an external protocol. HTTP and HTTPS are supported. If you select HTTPS, select an IngressTLS server certificate. If no desired certificate is available, click Create IngressTLS Secret to create an IngressTLS secret. For details, see Secrets.
- SNI: Server Name Indication (SNI) is an extended protocol of TLS. It allows multiple TLS-based access domain names to be provided for external systems using the same IP address and port number. Different domain names can use different security certificates.
+ - Forwarding Policy: When the access address of a request matches the forwarding policy (a forwarding policy consists of a domain name and URL, for example, 10.117.117.117:80/helloworld), the request is forwarded to the corresponding target Service for processing. You can add multiple forwarding policies.
- Domain Name: (Optional) actual domain name. Ensure that the domain name has been registered and licensed. Once a forwarding policy is configured with a domain name specified, you must use the domain name for access.
- URL: access path to be registered, for example, /healthz. The access path must be the same as the URL exposed by the backend application. Otherwise, a 404 error will be returned.
- Backend Service: Select a Service name. You need to create the NodePort Service first. For details, see NodePort.
- Backend Service Port: After you select the backend Service, the corresponding container port is automatically filled in.
+ - Cluster: Select the cluster where the ingress is to be deployed.
- CCE cluster:
- Exposed Port: port opened on the load balancer, which can be specified randomly.
- Load Balancer: Only load balancers in the VPC where the cluster resides are supported. If no load balancer is available, click Create Load Balancer. After the load balancer is created, click the refresh button.
When creating an Nginx Ingress, you do not need to manually select a load balancer because a load balancer has been associated during add-on installation.
+
+
+ - Other clouds
- Ingress Class: You can select an existing ingress class or manually enter an ingress class name. For details, see Ingress.
- Annotation: Enter an annotation in a key-value pair based on your service and vendor requirements.
+ - To create an internal load balancer, add the annotation based on the cloud service provider of your cluster. For details, see Internal load balancer.
+
+
- Click OK. After the ingress is created, you can view it in the list on the Ingresses tab.
- Obtain the access address.
- In the navigation pane, choose Services and Ingresses. Then, click the Ingresses tab.
- Click the name of the created ingress. On the Ingress Details page displayed, view the load balancer and listener port configurations. You can access a backend pod using the EIP of the load balancer, listener port, and URL, for example, 10.117.117.117:8088/helloworld.
+
+
+
Related Operations
You can also perform operations described in
Table 1.
+
Table 1 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating an ingress from a YAML file
+ |
+Click Create from YAML in the upper right corner to create an ingress from an existing YAML file.
+ |
+
+Viewing details
+ |
+- Select the namespace that the ingress belongs to.
- (Optional) Search for an ingress by its name.
- Click the ingress name to view its details, including the basic information and cluster deployment information.
- On the Ingress Details page, click View YAML in the Cluster area to view or download YAML files of ingress instances deployed in each cluster.
+ |
+
+Editing a YAML file
+ |
+Click Edit YAML in the row where the target ingress resides to view and edit the YAML file of the ingress.
+ |
+
+Updating an ingress
+ |
+- Choose More > Update in the row where the target ingress resides.
- Modify the information by referring to 5.
- Click OK to submit the modified information.
+ |
+
+Deleting an ingress
+ |
+Choose More > Delete in the row where the target ingress resides. Then, click Yes.
+ |
+
+Deleting ingresses in batches
+ |
+- Select the ingresses to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
DNS Policies
+Applications deployed in different clusters can be accessed using a unified public domain name. After you configure a public domain name, UCS can use it as a root domain name to generate a complete domain name for applications. You can configure a DNS policy to interconnect a Service and ingress with DNS so that applications deployed across clusters can be accessed through the unified public domain name. In addition, you can create custom traffic distribution ratio to suit your needs.
+
Configuring a Domain Name
Before configuring domain name access for an application, ensure that the domain name has been registered with the domain name service provider and licensed. Otherwise, the domain name cannot be accessed.
+
If you have a registered and licensed domain name, go to 3 to add record sets.
+
If you do not register a domain name, create a public zone and complete the ICP filing, resolution, and configuration of the domain name as prompted. The procedure for domain name registration and licensing is as follows:
+
- Create a public zone. for example, ucsclub.cn.
- If you do not create a public zone, create one.
- If you have created a public zone, go to 2.
+ - Complete the ICP filing.
- If your domain name does not been licensed, apply for ICP filing using ICP License Service.
- If your domain name has been licensed, go to 3.
+ - Add record sets.
- If you do not add record sets, add ones.
- If you have added record sets, go to 4.
+ - Configure the domain name.
Select the domain name and configure it.
+
+
+
Creating a DNS Policy
After a Deployment is created, you can click Create Service to create a Service of the LoadBalancer type so that the Deployment can provide services for external systems. On the page indicating that the LoadBalancer Service is created, click Create DNS Policy.
+
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose DNS Policies in the navigation pane, and click Create DNS Policy.
- Set parameters of the associated Service.
- Namespace: Select a namespace.
- Target Service: Select a target Service. If no LoadBalancer Service is available, create one first. For details about how to create a Service, see LoadBalancer.
+ - Click Next and set the access mode.
- Active/Standby: The traffic will be distributed only to the selected active cluster. You can change the traffic ratio to change the role of active and standby clusters.
- Adaptive: The traffic is automatically distributed based on the number of pods in each cluster. In addition, you can enable region affinity to allow users in a specific region to access a specific cluster.
- Custom: You can create custom traffic distribution ratio for each cluster. In addition, you can enable region affinity to allow users in a specific region to access a specific cluster.
+ - Click Create DNS Policy. The creation task will take a period of time. You can click Back to DNS Policies or View DNS Policy Details to view the created DNS policy.
+
Modifying an Alias
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose DNS Policies in the navigation pane and click the name of a policy to access its details page.
- Click
, enter an alias, and click 
.
+
+
Modifying the Traffic Distribution Ratio
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose DNS Policies in the navigation pane and click the name of a policy to access its details page.
- On the topology tab, click Edit.
- Modify parameters and click OK.
+
+
Viewing the DNS Policy Address
After a DNS policy is created, you can view its address in the DNS policy list.
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose DNS Policies in the navigation pane. In the DNS policy list, view the value in the Domain Name column.
+
+
Deleting a DNS Policy
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Click Delete in the Operation column of the target DNS policy.
- In the Delete DNS Policy dialog box, click Yes.
+
+
Storage
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0277.html b/docs/ucs/umn/ucs_01_0277.html
new file mode 100644
index 000000000..54ccacf4a
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0277.html
@@ -0,0 +1,17 @@
+
+
+Overview
+You can configure a storage class in the Add Container step of creating a workload.
+
Local Storage
You can mount the file directory of the host where a container is located to a specified container path (corresponding to hostPath in Kubernetes). Alternatively, you can leave the source path empty (corresponding to emptyDir in Kubernetes). If the source path is left empty, a temporary directory of the host will be mounted to the mount point of the container. A specified source path is used when data needs to be persistently stored on the host, while emptyDir is used when temporary storage is needed. A ConfigMap is a type of resource that stores configuration information required by a workload. Its content is user-defined. A secret is a type of resource that holds sensitive data, such as authentication and key information, required by a workload. Its content is user-defined. For details, see Mounting a Local Volume.
+
+
PVCs
You can create PVs and mount them to a container path. When containers are migrated, cloud storage volumes are mounted to new containers to ensure data reliability. For details, see Mounting a PV. You are advised to select PVCs when creating a workload and store pod data in corresponding cloud storage volumes. If you store pod data in a local volume, the data cannot be restored when the node becomes faulty.
+
- UCS can automatically create EVS, OBS, and SFS volumes and mount them to the container path of a OTC cluster.
- EVS offers scalable block storage with high reliability, high performance, and extensive specifications for containers. EVS stores binary data and cannot store files directly. This storage class is applicable when data needs to be stored permanently.
- SFS provides high-performance file storage (NAS) that can be expanded on demand. It provides shared file access for containers and is used for persistent storage in ReadWriteMany scenarios, including media processing, content management and web services, and big data and application analysis.
- OBS provides unlimited storage capacity for objects/files in any format. It is mainly designed for scenarios involving storage and analysis of massive data, query of historical data details, analysis on a large number of behavior logs, and statistical analysis on public transactions.
+ - For a non-OTC cluster, when PVCs are used to mount cloud storage volumes, the cluster provider must support storage classes. For details, see Storage Classes.
+
+
Mounting a Local Volume
+Scenarios
There are four types of local volumes:
+
+
- hostPath: mounts a file directory of the host where the container is located to the specified mount point of the container. For example, if the container needs to access /etc/hosts, you can use hostPath volume to map /etc/hosts.
- emptyDir: applies to temporary data storage, disaster recovery, and runtime data sharing. It will be deleted upon deletion or transfer of workload pods. The lifecycle is the same as that of the container pod. When the pod is deleted, the emptyDir volume is deleted and its data is lost.
- ConfigMap: After you mount a ConfigMap to a container, you can read the ConfigMap data from the mount path of the container.
- Secret: After you mount a secret to a container, you can read the secret data from the mount path of the container.
+
hostPath
A hostPath volume mounts a file or directory from a host node's file system into a pod. Such a volume is usually used to store containerized application logs that need to be stored permanently or containerized applications that need to access internal data structure of the Docker engine on the host.
+
- Set the basic container information by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet. After setting the basic container information, click Data Storage. On the Local Volumes tab page, click
.
+ - Set parameters for adding a local volume, as listed in Table 1.
+
Table 1 hostPath parametersParameter
+ |
+Description
+ |
+
|---|
+
+Volume Type
+ |
+Select hostPath.
+ |
+
+hostPath
+ |
+Path on the host, for example, /etc/hosts.
+ |
+
+Mount Path
+ |
+Container path to which the data volume will be mounted.
+ NOTICE: - The container path cannot be a system directory, such as / or /var/run. Otherwise, the container may not function normally. Select an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, and the container cannot start normally. As a result, the application may not be created.
- If a volume 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.
+
+ |
+
+Subpath
+ |
+A subpath is used to mount a local volume so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used.
+ |
+
+Permissions
+ |
+- Read-only: You can only read the data in the mounted volume.
- Read-write: You can modify the volume mounted to the path. Newly written data will not be migrated if the container is migrated, which may cause data loss.
+ |
+
+
+
+
- You can add multiple settings. Click OK to complete the configuration.
+
+
emptyDir
emptyDir applies to temporary data storage, disaster recovery, and runtime data sharing. It will be deleted upon deletion or transfer of workload pods.
+
- Set the basic container information by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet. After setting the basic container information, click Data Storage. On the Local Volumes tab page, click .
+
- Set parameters for adding a local volume, as listed in Table 2.
+
Table 2 emptyDir parametersParameter
+ |
+Description
+ |
+
|---|
+
+Volume Type
+ |
+Select emptyDir.
+ |
+
+Medium
+ |
+- Default: Data is stored in disks. This approach is used when there is a large amount of data, with low requirements on reading and writing efficiency.
- Memory: You can select this option to improve the running speed, but the storage capacity is subject to the memory size. This mode applies to a small amount of data with high requirements on reading and writing efficiency.
+ |
+
+Mount Path
+ |
+Container path to which the data volume will be mounted.
+ NOTICE: - The container path cannot be a system directory, such as / or /var/run. Otherwise, the container may not function normally. Select an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, and the container cannot start normally. As a result, the application may not be created.
- If a volume 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.
+
+ |
+
+Subpath
+ |
+A subpath is used to mount a local volume so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used.
+ |
+
+Permissions
+ |
+- Read-only: You can only read the data in the mounted volume.
- Read-write: You can modify the volume mounted to the path. Newly written data will not be migrated if the container is migrated, which may cause data loss.
+ |
+
+
+
+
- You can add multiple settings. Click OK to complete the configuration.
+
+
ConfigMap
ConfigMap is used to process workload configuration parameters. Before that, you need to create ConfigMaps. For details, see ConfigMaps.
+
- Set the basic container information by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet. After setting the basic container information, click Data Storage. On the Local Volumes tab page, click .
+
- Set parameters for adding a local volume, as listed in Table 3.
+
Table 3 ConfigMap parametersParameter
+ |
+Description
+ |
+
|---|
+
+Storage Type
+ |
+Select ConfigMap.
+ |
+
+ConfigMap
+ |
+Select the desired ConfigMap name. NOTE: A ConfigMap must be created in advance. For details, see ConfigMaps.
+
+ |
+
+Mount Path
+ |
+Container path to which the data volume will be mounted.
+ NOTICE: - The container path cannot be a system directory, such as / or /var/run. Otherwise, the container may not function normally. Select an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, and the container cannot start normally. As a result, the application may not be created.
- If a volume 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.
+
+ |
+
+Subpath
+ |
+A subpath is used to mount a local volume so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used.
+ |
+
+Permissions
+ |
+Only Read-only is supported. You can only read the file system in the container path.
+ |
+
+
+
+
- You can add multiple settings. Click OK to complete the configuration.
+
+
Secret
Mount the data in the secret to the specified container. The content of the secret is user-defined. Before that, you need to create a secret. For details, see Secrets.
+
+
- Set the basic container information by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet. After setting the basic container information, click Data Storage. On the Local Volumes tab page, click .
+
- Set parameters for adding a local volume, as listed in Table 4.
+
Table 4 Secret parametersParameter
+ |
+Description
+ |
+
|---|
+
+Volume Type
+ |
+Select Secret.
+ |
+
+Secrets
+ |
+Select the desired secret name. NOTE: A secret must be created in advance. For details, see Secrets.
+
+ |
+
+Mount Path
+ |
+Container path to which the data volume will be mounted.
+ NOTICE: - The container path cannot be a system directory, such as / or /var/run. Otherwise, the container may not function normally. Select an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, and the container cannot start normally. As a result, the application may not be created.
- If a volume 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.
+
+ |
+
+Subpath
+ |
+A subpath is used to mount a local volume so that the same data volume is used in a single pod. If this parameter is left blank, the root path is used.
+ |
+
+Permissions
+ |
+Only Read-only is supported. You can only read the file system in the container path.
+ |
+
+
+
+
- You can add multiple settings. Click OK to complete the configuration.
+
Mounting a PV
+A PVC provides persistent storage management for containers in multiple clouds. The cloud storage can be mounted to containers based on actual requirements, ensuring high reliability of applications.
+
- After a PVC is created on the UCS console, a PVC with the same name is automatically created in your cluster. Also a PersistentVolume (PV) is created and bound with the PVC.
- You can modify or delete the PVCs automatically created by UCS on the cluster console. However, if the PVC settings on the UCS console are not modified accordingly, the modified or deleted PVCs will be re-created by UCS. You are advised to change the settings on the UCS console.
- For a non-OTC cluster, when PVCs are used to mount cloud storage volumes, the cluster provider must support storage classes for dynamically creating PVs. Run the following command to query the storage class configuration and the interconnected backend storage resources of the cluster. For more information about storage classes, see Storage Classes.
kubectl get storageclass
+
+
+
Using a PVC to Mount a Cloud Storage Volume
- Set the basic container information by referring to Creating a Deployment, Creating a StatefulSet, or Creating a DaemonSet. After setting the basic container information, click Data Storage. On the PersistentVolumeClaims (PVCs) tab, click
.
+ - Select the target PVC. If no PVC is available, click Create PVC. For details about related parameters, see Creating a PVC. Click OK.
- Set the container mount options.
- Set Mount Path to a path to which the data volume is mounted.
- The container path cannot be a system directory, such as / or /var/run. Otherwise, the container may not function normally. Select an empty directory. If the directory is not empty, ensure that the directory does not contain any files that affect container startup. Otherwise, the files will be replaced, and the container cannot start normally. As a result, the workload may not be deployed.
- If a volume 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.
+
+ - Set Subpath to a path of the data volume in the Kubernetes. It is the subpath of the volume instead of the root path. If this parameter is left blank, the root path is used.
- Set permissions.
- Read-only: You can only read the data in the mounted volume.
- Read-write: You can modify the volume mounted to the path. Newly written data will not be migrated if the container is migrated, which may cause data loss.
+
+ - You can add multiple PVCs.
+
+
Creating a PVC
+ - After a PVC is created on the UCS console, a PVC with the same name is automatically created in your cluster. Also a PersistentVolume (PV) is created and bound with the PVC.
- You can modify or delete the PVCs automatically created by UCS on the cluster console. However, if the PVC settings on the UCS console are not modified accordingly, the modified or deleted PVCs will be re-created by UCS. You are advised to change the settings on the UCS console.
- For a non-OTC cluster, when PVCs are used to mount cloud storage volumes, the cluster provider must support storage classes for dynamically creating PVs. Run the following command to query the storage class configuration and the interconnected backend storage resources of the cluster. For more information about storage classes, see Storage Classes.
kubectl get storageclass
+
+
+
Creating a PVC
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Storage. On the PersistentVolumeClaims (PVCs) tab, click Create PVC in the upper right corner.
- Specify basic information.
- Name: Enter a unique name of a PVC to be added.
- Namespace: namespace that the PVC will belong to. If this parameter is not specified, the default namespace is used.
- Cluster: Click
to select the cluster where the PVC is to be deployed.- For details about the parameters for adding an OTC cluster, see Table 1.
- For details about the parameters for adding a non-OTC cluster, see Table 2.
When creating a PVC for an attached cluster, you need to specify the corresponding annotations based on the actually interconnected with the cluster for the PVC to take effect. For more information, see Annotations and kubectl annotate.
+
+
+
+
+Table 1 Parameters for adding an OTC clusterParameter
+ |
+Description
+ |
+
|---|
+
+Cluster
+ |
+Select an OTC cluster.
+ |
+
+Storage Class
+ |
+- csi-disk: EVS disk. Specify the AZ and disk type.
- AZ: Specify the AZ where the EVS disk is located. The supported EVS disk types may vary in different AZs.
- EVS Disk Type: Available disk types are common I/O, high I/O, and ultra-high I/O, and the storage pools corresponding to the disk types are SATA, SAS, and SSD.
+ - csi-nas: indicates SFS.
+ |
+
+Access Mode
+ |
+- If csi-disk is selected, Access Mode must be set to ReadWriteOnce, that is, the volume can be mounted as read-write by only a single node.
- If csi-nas (file storage) is selected, Access Mode must be set to ReadWriteMany. This means the volume can be mounted as read-write by multiple nodes.
+ |
+
+Capacity (GiB)
+ |
+The capacity of the created PVC cannot be less than 10 GiB.
+Set this parameter only when csi-disk (EVS disk) or csi-nas (file storage) is selected.
+ |
+
+
+
+
Table 2 Parameters for adding a non-OTC clusterParameter
+ |
+Description
+ |
+
|---|
+
+Cluster
+ |
+Select a non-OTC cluster.
+ |
+
+Storage Class
+ |
+The storage classes supported by a cluster depend on the actual environment of the registered cluster. For details, see Storage Classes.
+ |
+
+Access Mode
+ |
+- ReadWriteOnce (RWO): The PVC can be mounted as read-write only by a single node.
- ReadWriteMany (RWX): The PVC can be mounted as read-write by multiple nodes.
+ |
+
+Capacity (GiB)
+ |
+The capacity of the created PVC cannot be less than 10 GiB.
+ |
+
+Annotation
+ |
+Set key and value and click Confirm. Annotations are attached to PVCs in the form of key-value pairs.
+ |
+
+
+
+
- The key and value can be added repeatedly to configure differentiated settings for each cluster.
- Click OK. After the PVC is successfully created, you can click the PVC name to view the details.
+
+
Related Operations
You can also perform operations described in
Table 3.
+
Table 3 Related operationsOperation
+ |
+Description
+ |
+
|---|
+
+Creating a PVC from a YAML file
+ |
+Click Create from YAML in the upper right corner to create a PVC from an existing YAML file.
+ |
+
+Viewing details
+ |
+- Select the namespace that the PVC will belong to.
- (Optional) Search for a PVC by its name.
- Click the PVC name to view its details, including the basic information and deployment information of each cluster.
- On the PVC Details page, click View YAML in the Cluster area to view or download YAML files of PVCs deployed in each cluster.
+ |
+
+Viewing the YAML file
+ |
+Click View YAML next to the PVC name to view the YAML file of the current PVC.
+ |
+
+Update (Expanding a PVC)
+ |
+- Choose More > Update in the row where the target PVC resides.
- Modify the cluster deployment parameters based on the PVC parameters, or click Expand to expand the PVC.
- Click OK to submit the modified information.
+ |
+
+Deleting a PVC
+ |
+Choose More > Delete in the row where the target PVC resides, and click Yes.
+ |
+
+Deleting PVCs in batches
+ |
+- Select PVCs to be deleted.
- Click Delete in the upper left corner.
- Click Yes.
+ |
+
+
+
+
+
+
+
Namespaces
+A namespace is an abstract integration of a group of resources and objects in a cluster. Namespace-level resource quotas limit the amount of resources available to teams or projects that use the same cluster.
+
Creating a Namespace
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose Namespaces in the navigation pane and click Create Namespace in the upper right corner.
- Set namespace parameters based on Table 1.
+
Table 1 Parameters for creating a namespaceParameter
+ |
+Description
+ |
+
|---|
+
+Name
+ |
+Name of a namespace, which must be unique in a cluster.
+ |
+
+Label
+ |
+Add labels to namespaces and define different attributes in the key-value pair format. You can learn the characteristics of each namespace through these labels.
+ |
+
+Annotation
+ |
+Add customized annotations to the namespace in the key-value pair format.
+ |
+
+Description
+ |
+Description of the namespace.
+ |
+
+
+
+
- When the configuration is complete, click OK.
After the creation is complete, you can click View YAML to view and download the YAML file.
+
+
+
Using Namespaces
Namespaces can be used when creating Services, ingresses, and PVCs. The following uses workload creation as an example to describe how a namespace is used.
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- In the navigation pane, choose Workloads. On the Deployments tab, click Create from Image in the upper right corner.
- Configure the basic information about the workload and select the namespace where the workload is located.
- Complete the configuration.
+
+
Deleting a Namespace
- Deleting a namespace on the UCS console will delete the namespace with the same name in each cluster as well as all data resources related to the namespace. Exercise caution when performing this operation.
- To ensure that UCS runs properly, namespaces whose source is System or Default cannot be deleted.
+
+
- Log in to the UCS console. In the navigation pane, choose Fleets.
- On the Fleets tab, click the name of the federation-enabled fleet to access its details page.
- Choose Namespaces in the navigation pane. In the namespace list, click Delete in the row of the target namespace.
To delete multiple namespaces at a time, select the namespaces and click Delete in the upper left corner.
+ - Click Yes as prompted.
+
+
OTC Clusters
+You can register OTC clusters (CCE standard clusters and CCE Turbo clusters) with UCS with just a few clicks. After the registration is complete, clusters can be managed automatically.
+
Constraints
- Only OTC accounts or users with the UCS FullAccess permissions can register clusters.
- If you are connecting a foreign cluster to UCS, ensure that this connection and the subsequent actions you will take comply with the local laws and regulations.
- Ensure that your Kubernetes cluster version is 1.19 or later.
+
+
Prerequisites
You have created a CCE standard cluster or CCE Turbo cluster to be connected to UCS, and the cluster is in the Running state.
+
+
Procedure
- Log in to the UCS console. In the navigation pane, choose Fleets.
- In the card view of OTC clusters, click Register Cluster.
- Select the CCE standard cluster or CCE Turbo cluster to be registered. Select a fleet and click OK.
If you do not select a fleet when registering a cluster, the cluster will be displayed on the Clusters Not in Fleet tab after registration. You can add it to a fleet later. For details, see Managing Clusters Not in the Fleet.
+ When registering a cluster, you cannot select a fleet with cluster federation enabled. To add your cluster to the fleet with cluster federation enabled, register your cluster with UCS first. For details about cluster federation, see Enabling Cluster Federation.
+
+
+
+
Services
+
+
+
diff --git a/docs/ucs/umn/ucs_01_0317.html b/docs/ucs/umn/ucs_01_0317.html
new file mode 100644
index 000000000..f2b8a5a57
--- /dev/null
+++ b/docs/ucs/umn/ucs_01_0317.html
@@ -0,0 +1,61 @@
+
+
+Managing a Workload
+Scenarios
After a workload is created, you can view its details, upgrade it, edit YAML, redeploy it, reschedule it, and delete it.
+
Table 1 Workload managementOperation
+ |
+Description
+ |
+
|---|
+
+Viewing Workload Details
+ |
+You can view the basic information, events, and status of pods and workloads, and modify workload settings.
+ |
+
+Editing a YAML File
+ |
+You can modify and download the YAML file of a workload online. YAML files of common jobs can only be viewed, copied, and downloaded.
+ |
+
+Upgrading a Workload
+ |
+You can quickly upgrade a workload by replacing its image or image version without interrupting services.
+ |
+
+Redeploying a Workload
+ |
+You can redeploy a workload. After the workload is redeployed, all pods in the workload will be restarted. Only Deployments can be redeployed.
+ |
+
+Deleting a Workload
+ |
+If a workload is no longer used, you can delete it. Deleted workloads or tasks cannot be restored.
+ |
+
+
+
+
+
+
+
Viewing Workload Details
Click the name of a created workload to go to its details page. On this page, you can view the basic information, events, and status of pods and workloads, and modify workload settings.
+
+
Editing a YAML File
You can modify and download the YAML files of Deployments, StatefulSets, DaemonSets, CronJobs, and pods. 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.
+
- Log in to the UCS console, access an existing fleet, and choose Workloads in the navigation pane.
- Click the Deployments tab, locate your Deployment, and click Edit YAML in the Operation column. In the dialog box displayed, modify the YAML file.
- Click OK.
- (Optional) In the Edit YAML window, click Download to download the YAML file.
+
+
Upgrading a Workload
You can quickly upgrade a workload on the UCS console. This section uses a Deployment as an example to describe how to upgrade a workload.
+
- Log in to the UCS console, access an existing fleet, and choose Workloads in the navigation pane.
- Click the Deployments tab, locate your workload, and click Upgrade in the Operation column.
- Upgrade the workload based on service requirements. The method for setting parameters is the same as that for creating a workload.
- After the update is complete, click Upgrade Workload, manually confirm the YAML file, and submit the upgrade.
+
+
Redeploying a Workload (Available Only for Deployments)
After you redeploy a workload, all pods in the workload will be restarted. This section uses a Deployment as an example to describe how to redeploy a workload.
+
- Log in to the UCS console, access an existing fleet, and choose Workloads in the navigation pane.
- Click the Deployments tab, locate your workload, and choose More > Redeploy in the Operation column.
- In the displayed dialog box, click Yes.
+
+
Deleting a Workload
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.
+
- Log in to the UCS console, access an existing fleet, and choose Workloads in the navigation pane.
- Click the Deployments tab, locate your workload, and choose More > Delete in the Operation column.
- In the displayed dialog box, click Yes.
+
+
Adding Labels and Taints to a Cluster
+UCS allows you to add different labels to clusters to define different attributes. By using these cluster labels, you can quickly understand the characteristics of each cluster. Taints enable a cluster to repel specific pods to prevent these pods from being scheduled to the cluster, achieving reasonable allocation of workloads on clusters.
+
Labels
You can add different labels to clusters to classify and manage clusters.
+
+
Taints
Taints are in the format of
Key=Value:Effect.
Key and
Value are the labels of a taint.
Value can be empty.
Effect is used to describe the effect of taints. The following option is supported for
Effect:
- NoSchedule: No pod will be able to schedule onto the cluster unless it has a matching toleration, but existing pods will not be evicted from the cluster.
+
+
Currently, UCS does not support pod eviction using the NoExecute taint policy.
+
+
+
Managing Cluster Labels and Taints
- Log in to the UCS console.
- Click the name of the fleet where the target cluster is located. In the navigation pane, choose Container Clusters, locate the target cluster, and click
in the upper right corner to go to the Manage Labels and Taints page. - Click
to add a node label or taint. You can add a maximum of 10 operations at a time.- Choose Add or Delete.
- Set the operation object to Kubernetes Label or Taint.
- Specify Key and Value.
- If you choose Taint, select a taint effect. For details, see Taints.
+ - Click OK.
+
+
Using kubectl to Connect to a Federation
+This section describes how you can use kubectl to connect to a federation.
+
Permissions
When you use kubectl to connect to a federation, UCS uses kubeconfig.json generated on the federation for authentication. This file contains user information, based on which UCS determines which Kubernetes resources can be accessed by kubectl. The permissions recorded in a kubeconfig.json file vary from user to user.
+
+
Constraints
- For security purposes, the federation API server does not have a public IP address. UCS creates an endpoint in your VPC and subnet and connects the endpoint to the federation API server for the access to the federation. For each federation, only one endpoint is created in the same VPC. If a VPC already has an endpoint for connecting to the federation API server, the endpoint will be reused.
+
+
Prerequisites
- Before using kubectl to connect to a federation, ensure that the federation has been enabled (Enabling Cluster Federation) and is running normally.
- Only the client in a VPC can connect to a federation using kubectl. If there is no client in the VPC, create one.
- kubectl has been downloaded and uploaded to the client. For details about how to download kubectl, see Kubernetes releases.
- At least the custom policy iam:clustergroups:get has been created.
+
+
Using kubectl to Connect to a Federation
- Log in to the UCS console and click the fleet name to access the fleet console. Then, click kubectl in Fleet Info.
- Select a project, VPC, master node subnet, and validity period as prompted and click Download to download the kubectl configuration file.
The name of the downloaded file is {Fleet name}_kubeconfig.json.
+ - Install and configure kubectl on the executor.
- Copy kubectl and its configuration file to the /home directory on the executor in the selected VPC and subnet.
- Log in to your executor and configure kubectl.
cd /home
+chmod +x kubectl
+mv -f kubectl /usr/local/bin
+mkdir -p $HOME/.kube
+mv -f <fleet-name>_kubeconfig.json $HOME/.kube/config --Change the fleet name in the command to the actual fleet name.
+
+
+
+
Tolerance Policies
+A tolerance policy allows the scheduler to schedule pods to nodes with corresponding taints. This policy must be used together with node taints. One or more taints can be added to each node. For pods without node tolerance policy, the scheduler performs selective scheduling based on the taint effect to prevent pods from being allocated to inappropriate nodes.
+
In the current UCS version, the NoExecute taint policy is not supported during tolerance configuration when you create a workload.
+
+
Configuring a Tolerance Policy on the Console
+
- Log in to the UCS console.
- When creating a workload, click Next: Scheduling and Differentiation.
- Add a tolerance policy.
+
Parameter
+ |
+Description
+ |
+
|---|
+
+Taint Key
+ |
+Key of a node taint.
+ |
+
+Operator
+ |
+- Equal: matches the nodes with the specified taint key (mandatory) and value. If the taint value is left blank, all taints with the key the same as the specified taint key will be matched.
- Exists: matches the nodes with the specified taint key. In this case, the taint value cannot be specified. If the taint key is left blank, all taints will be tolerated.
+ |
+
+Taint Value
+ |
+- If the value of Operator is Exists, the value attribute can be omitted.
- If the value of Operator is Equal, the relationship between the key and value is Equal.
- If Operator is not specified, the default value is Equal.
+ |
+
+Taint Policy
+ |
+- All: All taint policies are matched.
- NoSchedule: Only the NoSchedule taint is matched.
+ |
+
+
+
+
+
Workload Creation
+
+
+
+
+