docker-username
diff --git a/docs/cce/umn/cce_10_0010.html b/docs/cce/umn/cce_10_0010.html
index 5612e0138..9e9a39381 100644
--- a/docs/cce/umn/cce_10_0010.html
+++ b/docs/cce/umn/cce_10_0010.html
@@ -19,7 +19,7 @@
- ClusterIP: used to make the Service only reachable from within a cluster.
- NodePort: used for access from outside a cluster. A NodePort Service is accessed through the port on the node.
- LoadBalancer: used for access from outside a cluster. It is an extension of NodePort, to which a load balancer routes, and external systems only need to access the load balancer.
For details about the Service, see Service Overview.
-IngressServices forward requests using TCP and UDP at Layer 4. Ingresses forward requests using HTTP and HTTPS at Layer 7. Domain names and paths can be used for access of finer granularities.
+ IngressServices forward requests using TCP and UDP at Layer 4. Ingresses forward requests using HTTP and HTTPS at Layer 7, and can achieve finer-grained traffic routing through domain names and paths.
Figure 3 An ingress and its associated Services
For details about the ingress, see Ingress Overview.
diff --git a/docs/cce/umn/cce_10_0026.html b/docs/cce/umn/cce_10_0026.html
index 4cedbe8a1..2cebb9901 100644
--- a/docs/cce/umn/cce_10_0026.html
+++ b/docs/cce/umn/cce_10_0026.html
@@ -5,7 +5,7 @@
What Is a Trace?A trace is an operation log for a cloud service resource, tracked and stored by CTS. Traces record operations such as adding, modifying, or deleting cloud service resources. You can view them to identify who performed operations and when for detailed tracking.
Viewing Traces in the Trace List- Log in to the management console, click
 in the upper left corner, and choose Management & Deployment > Cloud Trace Service. - In the navigation pane, choose Trace List.
- In the upper right corner of the page, set a desired query time range: Last 1 hour, Last 1 day, or Last 1 week. You can also click Customize to specify a custom time range within the last seven days.
- Set filters to search for your desired traces, as shown in Figure 1.
Figure 1 Filters
+Viewing Traces in the Trace List- Log in to the management console, click in the upper left corner, and choose Management & Deployment > Cloud Trace Service.
- In the navigation pane, choose Trace List.
- In the upper right corner of the page, select a desired query time range: Last 1 hour, Last 1 day, or Last 1 week. You can also specify a custom time range within the last seven days.
- Set filters to search for your desired traces, as shown in Figure 1.
Figure 1 Filters
Table 1 Trace filtering parametersParameter
|
@@ -59,7 +59,7 @@
- Click
 on the left of a trace to expand its details.
- - Click View Trace in the Operation column. The trace details are displayed.
+ - Click View Trace in the Operation column. The trace details are displayed.
Helpful Links
diff --git a/docs/cce/umn/cce_10_0028.html b/docs/cce/umn/cce_10_0028.html
index 51cb1b387..e02eca61b 100644
--- a/docs/cce/umn/cce_10_0028.html
+++ b/docs/cce/umn/cce_10_0028.html
@@ -176,7 +176,7 @@
Reserved Pod IP Per Node (supported by clusters using the VPC networks)
|
The number of pod IP addresses that can be allocated in the container network (alpha.cce/fixPoolMask). This parameter determines the maximum number of pods that can be created on each node. Pods that use the host networks do not occupy the reserved IP addresses.
-In a container network, each pod is assigned a unique IP address. If the number of pod IP addresses reserved for each node is insufficient, pods cannot be created. For details, see Number of Allocatable Pod IP Addresses on a Node.
+In a container network, each pod is assigned a unique IP address. If the number of pod IP addresses reserved for each node is insufficient, pods cannot be created. For details, see Number of Reserved Pod IP Addresses Per Node.
|
No
|
diff --git a/docs/cce/umn/cce_10_0059.html b/docs/cce/umn/cce_10_0059.html
index 685480d76..8037836f7 100644
--- a/docs/cce/umn/cce_10_0059.html
+++ b/docs/cce/umn/cce_10_0059.html
@@ -225,7 +225,7 @@ kind: NetworkPolicy
metadata:
name: access-ingress3
spec:
- podSelector: # The rule applies only to pods labeled with role=db.
+ podSelector: # The rule applies only to pods labeled with role=db.
matchLabels:
role: db
ingress: # This is an ingress rule.
@@ -302,7 +302,7 @@ spec:
- podSelector: # The rule takes effect for pods with the role=web label.
matchLabels:
role: web
-- Run the following command to create the network policy defined the access-egress2.yaml file:
kubectl apply -f access-egress2.yaml
+ - Run the following command to create the network policy defined in the access-egress2.yaml file:
kubectl apply -f access-egress2.yaml
Expected output:
networkpolicy.networking.k8s.io/access-egress2 created
diff --git a/docs/cce/umn/cce_10_0141.html b/docs/cce/umn/cce_10_0141.html
index dec2fb12e..285db8725 100644
--- a/docs/cce/umn/cce_10_0141.html
+++ b/docs/cce/umn/cce_10_0141.html
@@ -298,7 +298,7 @@
v1.29
v1.30
-- Supported xGPU configuration by node pool.
- Supported GPU rendering.
- Clusters v1.30 are supported.
+ | - Supported xGPU configuration for node pools.
- Supported GPU rendering.
- Clusters v1.30 are supported.
|
2.6.4
diff --git a/docs/cce/umn/cce_10_0154.html b/docs/cce/umn/cce_10_0154.html
index c41ec364e..4ee7e0677 100644
--- a/docs/cce/umn/cce_10_0154.html
+++ b/docs/cce/umn/cce_10_0154.html
@@ -193,7 +193,7 @@
|
v1.30
|
-The scale-down delay and scale-down utilization thresholds can be configured for node pools.
+ | The scale-down delay and utilization thresholds can be configured for node pools.
|
1.30.1
|
@@ -234,7 +234,7 @@
v1.29
|
-The scale-down delay and scale-down utilization thresholds can be configured for node pools.
+ | The scale-down delay and utilization thresholds can be configured for node pools.
|
1.29.1
|
@@ -284,7 +284,7 @@
v1.28
|
-The scale-down delay and scale-down utilization thresholds can be configured for node pools.
+ | The scale-down delay and utilization thresholds can be configured for node pools.
|
1.28.1
|
@@ -370,7 +370,7 @@
v1.27
|
-The scale-down delay and scale-down utilization thresholds can be configured for node pools.
+ | The scale-down delay and utilization thresholds can be configured for node pools.
|
1.27.1
|
@@ -474,7 +474,7 @@
v1.25
|
-The scale-down delay and scale-down utilization thresholds can be configured for node pools.
+ | The scale-down delay and utilization thresholds can be configured for node pools.
|
1.25.0
|
@@ -546,7 +546,7 @@
v1.25
|
-- Fixed the issue where the autoscaler's least-waste is disabled by default.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in another node pool and the add-on had to restart.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
+ | - Fixed the issue where the autoscaler's least-waste is disabled by default.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in any other node pool and the add-on had to be restarted.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
|
1.25.0
|
@@ -641,7 +641,7 @@
v1.23
|
-- Fixed the issue where the autoscaler's least-waste is disabled by default.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in another node pool and the add-on had to restart.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
+ | - Fixed the issue where the autoscaler's least-waste is disabled by default.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in any other node pool and the add-on had to be restarted.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
|
1.23.0
|
@@ -650,7 +650,7 @@
v1.23
|
-- Supported node scaling policies without a step.
- Fixed a bug so that deleted node pools are automatically removed.
- Supported priority-based scheduling.
- Supported the emptyDir scheduling policy.
- Fixed a bug so that scale-in can be triggered on the nodes whose capacity is lower than the scale-in threshold when the node scaling policy is disabled.
- Modified the memory request and limit of a custom flavor.
- Allowed a node pool with auto scaling disabled to report a scaling failure event.
+ | - Supported node scaling policies without steps.
- Fixed a bug so that deleted node pools are automatically removed.
- Supported priority-based scheduling.
- Supported the emptyDir scheduling policy.
- Fixed a bug so that scale-in can be triggered on the nodes whose capacity is lower than the scale-in threshold when the node scaling policy is disabled.
- Modified the memory request and limit of a custom flavor.
- Allowed a node pool with auto scaling disabled to report a scaling failure event.
|
1.23.0
|
@@ -659,7 +659,7 @@
v1.23
|
-- Optimized logging.
- Supported scale-in waiting so that operations such as data dump can be performed before a node is deleted.
+ | - Optimized logging.
- Supported scale-in waiting so that operations, such as data dump, can be performed before a node is deleted.
|
1.23.0
|
@@ -718,7 +718,7 @@
v1.21
|
-- Supported anti-affinity scheduling of add-on pods on nodes in different AZs.
- Added the tolerance time during which the pods with temporary storage volumes can be unscheduled.
- Fixed the issue where the number of node pools cannot be restored when scaling group resources are insufficient.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in another node pool and the add-on had to restart.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
+ | - Supported anti-affinity scheduling of add-on pods on nodes in different AZs.
- Added the tolerance time during which the pods with temporary storage volumes can be unscheduled.
- Fixed the issue where the number of node pools cannot be restored when scaling group resources are insufficient.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in any other node pool and the add-on had to be restarted.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
|
1.21.0
|
@@ -727,7 +727,7 @@
v1.21
|
-- Supported node scaling policies without a step.
- Fixed a bug so that deleted node pools are automatically removed.
- Supported priority-based scheduling.
- Supported the emptyDir scheduling policy.
- Fixed a bug so that scale-in can be triggered on the nodes whose capacity is lower than the scale-in threshold when the node scaling policy is disabled.
- Modified the memory request and limit of a custom flavor.
- Allowed a node pool with auto scaling disabled to report a scaling failure event.
+ | - Supported node scaling policies without steps.
- Fixed a bug so that deleted node pools are automatically removed.
- Supported priority-based scheduling.
- Supported the emptyDir scheduling policy.
- Fixed a bug so that scale-in can be triggered on the nodes whose capacity is lower than the scale-in threshold when the node scaling policy is disabled.
- Modified the memory request and limit of a custom flavor.
- Allowed a node pool with auto scaling disabled to report a scaling failure event.
|
1.21.0
|
@@ -736,7 +736,7 @@
v1.21
|
-- Optimized logging.
- Supported scale-in waiting so that operations such as data dump can be performed before a node is deleted.
+ | - Optimized logging.
- Supported scale-in waiting so that operations, such as data dump, can be performed before a node is deleted.
|
1.21.0
|
@@ -768,7 +768,7 @@
v1.19
|
-- Optimized the method of identifying GPUs.
- Used the remaining node quota of a cluster for the extra nodes that are beyond the cluster scale.
+ | - Optimized the method of identifying GPUs.
- Scaled out only by the remaining number of nodes supported by the cluster when the requested number of nodes for scaling out exceeds the cluster's maximum capacity.
|
1.19.0
|
@@ -786,7 +786,7 @@
v1.19
|
-- Supported anti-affinity scheduling of add-on pods on nodes in different AZs.
- Added the tolerance time during which the pods with temporary storage volumes can be unscheduled.
- Fixed the issue where the number of node pools cannot be restored when scaling group resources are insufficient.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in another node pool and the add-on had to restart.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
+ | - Supported anti-affinity scheduling of add-on pods on nodes in different AZs.
- Added the tolerance time during which the pods with temporary storage volumes can be unscheduled.
- Fixed the issue where the number of node pools cannot be restored when scaling group resources are insufficient.
- Fixed the issue where, if a node scale-out failed in a node pool, the same operation cannot be performed in any other node pool and the add-on had to be restarted.
- The default taint tolerance duration is changed to 60s.
- Fixed the issue where scale-out is still triggered after the scale-out rule is disabled.
|
1.19.0
|
@@ -795,7 +795,7 @@
v1.19
|
-- Supported node scaling policies without a step.
- Fixed a bug so that deleted node pools are automatically removed.
- Supported priority-based scheduling.
- Supported the emptyDir scheduling policy.
- Fixed a bug so that scale-in can be triggered on the nodes whose capacity is lower than the scale-in threshold when the node scaling policy is disabled.
- Modified the memory request and limit of a custom flavor.
- Allowed a node pool with auto scaling disabled to report a scaling failure event.
+ | - Supported node scaling policies without steps.
- Fixed a bug so that deleted node pools are automatically removed.
- Supported priority-based scheduling.
- Supported the emptyDir scheduling policy.
- Fixed a bug so that scale-in can be triggered on the nodes whose capacity is lower than the scale-in threshold when the node scaling policy is disabled.
- Modified the memory request and limit of a custom flavor.
- Allowed a node pool with auto scaling disabled to report a scaling failure event.
|
1.19.0
|
@@ -804,7 +804,7 @@
v1.19
|
-- Optimized logging.
- Supported scale-in waiting so that operations such as data dump can be performed before a node is deleted.
+ | - Optimized logging.
- Supported scale-in waiting so that operations, such as data dump, can be performed before a node is deleted.
|
1.19.0
|
diff --git a/docs/cce/umn/cce_10_0193.html b/docs/cce/umn/cce_10_0193.html
index ec990a466..7ac8cd4c8 100644
--- a/docs/cce/umn/cce_10_0193.html
+++ b/docs/cce/umn/cce_10_0193.html
@@ -383,7 +383,7 @@ workload_balancer_third_party_types: ''
Used to enable cloud native hybrid deployment.
|
This function is disabled by default. Options:
-- true: The function is enabled.
- false or empty: The function is disabled.
+- true: The function is enabled.
- false or empty: The function is disabled.
|
oversubscription_method
@@ -765,7 +765,7 @@ workload_balancer_third_party_types: ''
This section describes how to configure volcano-scheduler.
 Only Volcano of v1.7.1 and later support this function.
Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Settings and click the Scheduling tab. In the Select Cluster Scheduler area, find the expert mode and click Try Now.
+Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane, choose Settings and click the Scheduling tab. In the Default Cluster Scheduler area, find the expert mode and click Try Now.
|
-Supported even scheduling on virtual GPUs.
+ | Supported even scheduling in virtual GPUs.
|
1.15.6
diff --git a/docs/cce/umn/cce_10_0248.html b/docs/cce/umn/cce_10_0248.html
index 09b226037..4b719ac00 100644
--- a/docs/cce/umn/cce_10_0248.html
+++ b/docs/cce/umn/cce_10_0248.html
@@ -6,10 +6,14 @@
diff --git a/docs/cce/umn/cce_10_0281.html b/docs/cce/umn/cce_10_0281.html
index ad147fb24..558b8cb37 100644
--- a/docs/cce/umn/cce_10_0281.html
+++ b/docs/cce/umn/cce_10_0281.html
@@ -80,7 +80,7 @@
The value of the kubelet configuration parameter maxPods is used. For details, see Maximum Number of Pods on a Node.
|
The smaller value between the following two options is used:
-
+
|
The smaller value between the following two options is used:
diff --git a/docs/cce/umn/cce_10_0336.html b/docs/cce/umn/cce_10_0336.html
index 1cdff108b..1e6e12162 100644
--- a/docs/cce/umn/cce_10_0336.html
+++ b/docs/cce/umn/cce_10_0336.html
@@ -4,18 +4,20 @@
CCE Container Storage (Everest) supports custom access keys. In this way, IAM users can use their own custom access keys to mount an OBS volume.
- Constraints- When an OBS volume is mounted using a custom access key (AK/SK), the access key cannot be deleted or disabled. Otherwise, the service container cannot access the mounted OBS volume.
- Custom access keys cannot be configured for secure containers.
+ Notes and Constraints- When an OBS volume is mounted using custom access keys (AK/SK), the access key cannot be deleted or disabled. Otherwise, the service container cannot access the mounted OBS volume.
- Custom access keys cannot be configured for secure containers.
Disabling a Global AKWhen creating an OBS volume on the console of an earlier version, you need to upload the AK/SK (global access key), which is then used by default for mounting the OBS volume. As a result, all IAM users within your account will use the same key to mount the OBS buckets, and they will have identical permissions on the buckets. However, this setting does not allow you to set different permissions for individual IAM users.
- If you have uploaded the AK/SK, disable the automatic mounting of global access keys by enabling the DISABLE_AUTO_MOUNT_SECRET parameter in the CCE Container Storage (Everest) add-on to prevent IAM users from performing unauthorized operations. In this way, the global access keys uploaded on the console will not be used when you use OBS volumes.
- - Before enabling DISABLE_AUTO_MOUNT_SECRET, ensure that there are no OBS volumes in the cluster. Workloads using OBS volumes may fail to remount after scaling or restart due to missing access keys, which are blocked by DISABLE_AUTO_MOUNT_SECRET.
- If DISABLE_AUTO_MOUNT_SECRET is set to true, an access key must be specified when a PV or PVC is created. Otherwise, mounting the OBS volume will fail.
+ If you have uploaded the AK/SK (specifically, if paas.longaksk exists in the kube-system namespace of the cluster), you should disable the global access secret to prevent IAM users from performing unauthorized operations. This ensures that the uploaded global access secret in the console will not be used when OBS volumes are used. If you have not uploaded any AK/SK, skip this section.
+ - Before disabling the global access secret, ensure that there are no OBS volumes in the cluster. Workloads using OBS volumes may fail to remount after scaling or restart due to missing access keys.
- After the global access secret is disabled, you must specify the access keys when creating a PV and PVC. Otherwise, the OBS volume fails to be mounted.
- The following steps apply to CCE Container Storage (Everest) 2.x (2.1.42 or later):
- - Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Add-ons. In the right pane, find the CCE Container Storage (Everest) add-on and click Edit.
- Configure the add-on parameters. Set Prohibit Global Secret from Mounting Object Storage (disable_auto_mount_secret) to Yes.
- Click OK.
- The following steps apply to CCE Container Storage (Everest) 1.x. (The modified settings cannot be retained during the add-on upgrades. You are advised to use the add-on of 2.x.)
- - Use kubectl to access the cluster and run the following command to modify the add-on settings:
kubectl edit ds everest-csi-driver -nkube-system
- - Search for disable-auto-mount-secret and set it to true.
- - Run :wq to save the settings and exit. Wait until the pod is restarted.
+ To disable the global access secret, do as follows:
+ - Disable the automatic mounting of access secrets in the CCE Container Storage (Everest) add-on by setting disable_auto_mount_secret to true.
The following steps apply to CCE Container Storage (Everest) 2.x (2.1.42 or later):
+- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Add-ons. In the right pane, find the CCE Container Storage (Everest) add-on and click Edit.
- Configure the add-on parameters. Set Prohibit Global Secret from Mounting Object Storage (disable_auto_mount_secret) to Yes.
- Click OK.
+The following steps apply to CCE Container Storage (Everest) 1.x. The modified settings cannot be retained during the add-on upgrades. You are advised to use the add-on of 2.x.
+- Use kubectl to access the cluster and run the following command to modify the add-on settings:
kubectl edit ds everest-csi-driver -nkube-system
+ - Search for disable-auto-mount-secret and set it to true.
+ - Run :wq to save the settings and exit. Wait until the pod is restarted.
+ - In the Settings > Cluster Settings area, disable the global access secret of the cluster. The global access secret (paas.longaksk) in the kube-system namespace of the cluster will be deleted.
Obtaining an Access Key- Access the My Credentials page.
- In the navigation pane, choose Access Keys.
- Click Create Access Key. The Create Access Key dialog box is displayed.
- Click OK to download the access key.
diff --git a/docs/cce/umn/cce_10_0337.html b/docs/cce/umn/cce_10_0337.html
index 30192857f..8b39fae61 100644
--- a/docs/cce/umn/cce_10_0337.html
+++ b/docs/cce/umn/cce_10_0337.html
@@ -4,7 +4,7 @@
This section describes how to configure SFS mount options. You can configure mount options in a PV and bind the PV to a PVC. Alternatively, configure mount options in a StorageClass and use the StorageClass to create a PVC. In this way, PVs can be dynamically created and inherit mount options configured in the StorageClass by default.
PrerequisitesThe CCE Container Storage (Everest) version must be 1.2.8 or later. This add-on identifies the mount options and transfers them to the underlying storage resources. The parameter settings take effect only if the underlying storage resources support the specified options.
- Constraints- Mount options cannot be configured for secure containers.
- Due to the restrictions of the NFS protocol, if an SFS volume is mounted to a node for multiple times, link-related mounting parameters (such as timeo) take effect only when the SFS volume is mounted for the first time by default. For example, if the same SFS file system is mounted to multiple pods running on a node, the mounting parameter set later does not overwrite the existing parameter value. If you want to configure different mounting parameters in the preceding scenario, additionally configure the nosharecache parameter.
+ Notes and Constraints- Mount options cannot be configured for secure containers.
- Due to the restrictions of the NFS protocol, if an SFS volume is mounted to a node for multiple times, link-related mounting parameters (such as timeo) take effect only when the SFS volume is mounted for the first time by default. For example, if the same SFS file system is mounted to multiple pods running on a node, the mounting parameter set later does not overwrite the existing parameter value. If you want to configure different mounting parameters in the preceding scenario, additionally configure the nosharecache parameter.
SFS Volume Mount OptionsThe Everest add-on in CCE presets the options described in Table 1 for mounting SFS volumes.
@@ -67,7 +67,7 @@
| |
|---|
You can configure other mount options if needed. For details, see Mounting an NFS File System to ECSs (Linux).
+You can configure other mount options if needed. For details, see Mounting an NFS File System to ECSs (Linux).
Configuring Mount Options in a PVYou can use the mountOptions field to configure mount options in a PV. The options you can configure in mountOptions are listed in SFS Volume Mount Options.
- Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
- Configure mount options in a PV. Example:
apiVersion: v1
@@ -85,12 +85,13 @@ spec:
csi:
driver: nas.csi.everest.io # Dependent storage driver for the mounting
fsType: nfs
- volumeHandle: <your_volume_id> # The ID of the SFS Capacity-Oriented volume
+ volumeHandle: <your_volume_id> # The ID of the SFS Capacity-Oriented volume or the file system name when a general purpose file system (SFS 3.0 Capacity-Oriented) is used
volumeAttributes:
everest.io/share-export-location: <your_location> # Shared path of the SFS volume
storage.kubernetes.io/csiProvisionerIdentity: everest-csi-provisioner
+ everest.io/sfs-version: sfs3.0 # A general purpose file system (SFS 3.0 Capacity-Oriented) is used.
persistentVolumeReclaimPolicy: Retain # Reclaim policy
- storageClassName: csi-nas # StorageClass name.
+ storageClassName: csi-nas # StorageClass name. csi-nas indicates that SFS Capacity-Oriented is used. csi-sfs indicates that a general purpose file system (SFS 3.0 Capacity-Oriented) is used.
mountOptions: # Mount options
- vers=3
- nolock
@@ -116,6 +117,7 @@ parameters:
csi.storage.k8s.io/csi-driver-name: nas.csi.everest.io
csi.storage.k8s.io/fstype: nfs
everest.io/share-access-to: <your_vpc_id> # VPC ID of the cluster
+ everest.io/sfs-version: sfs3.0 # A general purpose file system (SFS 3.0 Capacity-Oriented) is used. This parameter is not required for SFS Capacity-Oriented.
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions: # Mount options
diff --git a/docs/cce/umn/cce_10_0348.html b/docs/cce/umn/cce_10_0348.html
index 6e04a3f71..f21059366 100644
--- a/docs/cce/umn/cce_10_0348.html
+++ b/docs/cce/umn/cce_10_0348.html
@@ -20,9 +20,9 @@
|
Cloud Native Network 2.0 (for CCE Turbo clusters)
@@ -36,7 +36,7 @@
-Number of Allocatable Pod IP Addresses on a NodeThe number of allocatable pod IP addresses on a node is the maximum number of IP addresses that can be allocated to pods on that node. When creating a cluster in the VPC network model, follow the and specify the number of pod IP addresses that each node can allocate using alpha.cce/fixPoolMask.
+ Number of Reserved Pod IP Addresses Per NodeWhen creating a cluster in the VPC network model, follow the and specify the number of pod IP addresses that each node can allocate using alpha.cce/fixPoolMask.
The maximum number of pods that can be created on a node is determined by the number of pod IP addresses available for allocation. In a containerized environment, each pod requires its own unique IP address. If the node runs out of reserved pod IP addresses, new pods cannot be created. If hostNetwork: true is configured in the YAML file, pods will use the host network instead of the reserved pod IP addresses. For details, see Pod IP Address Allocation Differences Between the Container Network and Host Network.
By default, each node in a cluster is assigned a CIDR block from which pod IP addresses are allocated. The usable number of IP addresses for pods within this block is typically the total number of addresses in the CIDR block minus three reserved addresses (including the network address, gateway address, and broadcast address).
diff --git a/docs/cce/umn/cce_10_0365.html b/docs/cce/umn/cce_10_0365.html
index e0b3d9102..11f62b311 100644
--- a/docs/cce/umn/cce_10_0365.html
+++ b/docs/cce/umn/cce_10_0365.html
@@ -11,12 +11,12 @@
For example, the domain name www.***.com has only two dots (smaller than the value of ndots), and therefore the sequence of DNS queries is as follows: www.***.com.default.svc.cluster.local, www.***.com.svc.cluster.local, www.***.com.cluster.local, and www.***.com. This means that at least seven DNS queries will be initiated before the domain name is resolved into an IP address. It is clear that when many unnecessary DNS queries will be initiated to access an external domain name. There is room for improvement in workload's DNS configuration.
For more information about configuration options in the resolver configuration file used by Linux operating systems, visit http://man7.org/linux/man-pages/man5/resolv.conf.5.html.
+
Configuring DNS for a Workload Through the ConsoleKubernetes provides DNS-related configuration options for applications. The use of application's DNS configuration can effectively reduce unnecessary DNS queries in certain scenarios and improve service concurrency. The following procedure uses an Nginx application as an example to describe how to add DNS configurations for a workload on the console.
- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Workloads. In the upper right corner, click Create Workload.
- Configure basic information about the workload. For details, see Creating a Workload.
- In the Advanced Settings area, click the DNS tab and set the following parameters as required:
- DNS Policy: The DNS policies provided on the console correspond to the dnsPolicy field in the YAML file. For details, see Table 1.
- Supplement defaults: corresponds to dnsPolicy=ClusterFirst. Containers can resolve both the cluster-internal domain names registered by a Service and the external domain names exposed to public networks.
- Replace defaults: corresponds to dnsPolicy=None. You must configure IP Address and Search Domain. Containers only use the user-defined IP address and search domain configurations for domain name resolution.
- Inherit defaults: corresponds to dnsPolicy=Default. Containers use the domain name resolution configuration from the node that pods run on and cannot resolve the cluster-internal domain names.
- - Optional Objects: The options parameters in the dnsConfig field. Each object may have a name property (required) and a value property (optional). After setting the properties, click confirm to add.
- timeout: Timeout interval, in seconds.
- ndots: Number of dots (.) that must be present in a domain name. If a domain name has dots fewer than this value, the operating system will look up the name in the search domain. If not, the name is a fully qualified domain name (FQDN) and will be tried first as an absolute name.
+ - Optional Objects: The options parameters in the dnsConfig field. Each object may have a name property (required) and a value property (optional). After setting the properties, click confirm to add.
- timeout: Timeout interval, in seconds.
- ndots: Number of dots (.) that must be present in a domain name. If a domain name has fewer dots than this value, the operating system will look up the name in the search domain. If not, the name is a fully qualified domain name (FQDN) and will be tried first as an absolute name.
- IP Address of DNS Server: nameservers in dnsConfig. You can configure a domain name server for a custom domain name. The value is one or a group of DNS IP addresses.
- Search Domain: searches in the dnsConfig. A list of DNS search domains for hostname lookup in the pod. This property is optional. When specified, the provided list will be merged into the search domain names generated from the chosen DNS policy in dnsPolicy. Duplicate domain names are removed.
- Host Alias: Add the mapping between domain names and IP addresses to the local configuration file /etc/hosts of a pod for simplified local domain name resolution. For details, see Adding entries to Pod /etc/hosts with HostAliases.
- Click Create Workload.
diff --git a/docs/cce/umn/cce_10_0397.html b/docs/cce/umn/cce_10_0397.html
index 383e04dc4..ffe22034a 100644
--- a/docs/cce/umn/cce_10_0397.html
+++ b/docs/cce/umn/cce_10_0397.html
@@ -16,7 +16,7 @@
Max. Unavailable Pods (maxUnavailable)
|
The maximum number or percentage of pods that can be unavailable during a rolling upgrade. This also sets the limit for how many running pods can be below the expected number. The default value is 25%. During an upgrade, the percentage is converted into an absolute number and rounded down.
-For example, if spec.replicas is set to 2, no pods (2 x 0.25 = 0.5, rounded down to 0) can be unavailable. Therefore, during an upgrade, there will always be at least two pods running (2 desired - 0 unavailable). Each old pod is deleted only after a new one is created, ensuring that at least two pods are always running until all pods are updated.
+For example, if spec.replicas is set to 2, no pods (2 × 0.25 = 0.5, rounded down to 0) can be unavailable. Therefore, during an upgrade, there will always be at least two pods running (2 desired – 0 unavailable). Each old pod is deleted only after a new one is created, ensuring that at least two pods are always running until all pods are updated.
|
This parameter is only available for Deployments and DaemonSets.
|
@@ -117,7 +117,7 @@ spec:
maxUnavailable
|
The maximum number or percentage of pods that can be unavailable during a rolling upgrade. This also sets the limit for how many running pods can be below the expected number. The default value is 25%. During an upgrade, the percentage is converted into an absolute number and rounded down.
-For example, if spec.replicas is set to 2, no pods (2 x 0.25 = 0.5, rounded down to 0) can be unavailable. Therefore, during an upgrade, there will always be at least two pods running (2 desired - 0 unavailable). Each old pod is deleted only after a new one is created, ensuring that at least two pods are always running until all pods are updated.
+For example, if spec.replicas is set to 2, no pods (2 × 0.25 = 0.5, rounded down to 0) can be unavailable. Therefore, during an upgrade, there will always be at least two pods running (2 desired – 0 unavailable). Each old pod is deleted only after a new one is created, ensuring that at least two pods are always running until all pods are updated.
|
This parameter is only available for rolling upgrades.
|
diff --git a/docs/cce/umn/cce_10_0405.html b/docs/cce/umn/cce_10_0405.html
index 905fae462..9084c6c89 100644
--- a/docs/cce/umn/cce_10_0405.html
+++ b/docs/cce/umn/cce_10_0405.html
@@ -2,19 +2,30 @@
Patch Version Release Notes
Version 1.33
- Table 1 Release notes for the v1.33 patchCCE Cluster Patch Version
+Table 1 Release notes for the v1.33 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
-Vulnerability Fixing
+ | Vulnerability Fixing
|
|---|
-v1.33.5-r0
+ | v1.33.5-r2
+ |
+v1.33.5
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.33.5-r0
|
v1.33.5
|
@@ -43,19 +54,30 @@
Version 1.32
- Table 2 Release notes for the v1.32 patchCCE Cluster Patch Version
+Table 2 Release notes for the v1.32 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
-Vulnerability Fixing
+ | Vulnerability Fixing
|
|---|
-v1.32.5-r0
+ | v1.32.6-r12
+ |
+v1.32.6
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.32.5-r0
|
v1.32.5
|
@@ -74,7 +96,7 @@
- Service pod scheduling can be deferred until node post-installation scripts complete.
- DataPlane V2 is available for newly created CCE clusters that use the VPC networks. After DataPlane V2 is enabled, you can configure network policies for these clusters.
- AK/SK automatic updates are supported for parallel file systems of OBS.
- During the creation of a LoadBalancer Service, you can configure specific IP addresses for the ELB backend.
- AppArmor can be used to restrict container access to resources.
-- Streaming encoding is supported, significantly reducing memory pressure on control plane nodes caused by LIST requests.
- The cce-pause container image can be protected against accidental deletion.
- The system labels used by the NodeLocal DNSCache add-on can be protected against accidental deletion.
+ | - Streaming encoding is supported, significantly reducing memory pressure on control plane nodes caused by LIST requests.
- The cce-pause container image can be protected against accidental deletion.
- The system labels used by the NodeLocal DNSCache add-on can be protected against accidental deletion.
|
None
|
@@ -85,19 +107,30 @@
Version 1.31
- Table 3 Release notes for the v1.31 patchCCE Cluster Patch Version
+Table 3 Release notes for the v1.31 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
|---|
-v1.31.6-r10
+ | v1.31.10-r12
+ |
+v1.31.10
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.31.6-r10
|
v1.31.6
|
@@ -136,19 +169,30 @@
Version 1.30
- Table 4 Release notes for the v1.30 patchCCE Cluster Patch Version
+Table 4 Release notes for the v1.30 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
-Vulnerability Fixing
+ | Vulnerability Fixing
|
|---|
-v1.30.10-r10
+ | v1.30.14-r12
+ |
+v1.30.14
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.30.10-r10
|
v1.30.10
|
@@ -209,19 +253,30 @@
Version 1.29
- Table 5 Release notes for the v1.29 patchCCE Cluster Patch Version
+Table 5 Release notes for the v1.29 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
|---|
-v1.29.13-r10
+ | v1.29.15-r12
+ |
+v1.29.15
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.29.13-r10
|
v1.29.13
|
@@ -281,19 +336,30 @@
Version 1.28
- Table 6 Release notes for the v1.28 patchCCE Cluster Patch Version
+Table 6 Release notes for the v1.28 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
|---|
-v1.28.15-r30
+ | v1.28.15-r52
+ |
+v1.28.15
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.28.15-r30
|
v1.28.15
|
@@ -388,19 +454,30 @@
Version 1.27
- Table 7 Release notes for the v1.27 patchCCE Cluster Patch Version
+Table 7 Release notes for the v1.27 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
|---|
-v1.27.16-r40
+ | v1.27.16-r62
+ |
+v1.27.16
+ |
+-
+ |
+-
+ |
+Fixed runC container escape vulnerabilities (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881).
+ |
+
+v1.27.16-r40
|
v1.27.16
|
@@ -508,13 +585,13 @@
Version 1.25 In CCE clusters of v1.25, containerd is the default runtime for nodes, except for nodes running EulerOS 2.5. In addition, clusters of v1.25 or later no longer support EulerOS 2.5.
- Table 8 Release notes for the v1.25 patchCCE Cluster Patch Version
+Table 8 Release notes for the v1.25 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
@@ -658,13 +735,13 @@
Version 1.23
- Table 9 Release notes for the v1.23 patchCCE Cluster Patch Version
+Table 9 Release notes for the v1.23 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
@@ -809,13 +886,13 @@
Version 1.21
- Table 10 Release notes for the v1.21 patchCCE Cluster Patch Version
+Table 10 Release notes for the v1.21 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
@@ -926,13 +1003,13 @@
Version 1.19
- Table 11 Release notes for the v1.19 patchCCE Cluster Patch Version
+Table 11 Release notes for the v1.19 patchCCE Cluster Patch Version
|
-Kubernetes Version
+ | Kubernetes Version
|
-Feature Updates
+ | Feature Updates
|
-Optimization
+ | Optimization
|
Vulnerability Fixing
|
diff --git a/docs/cce/umn/cce_10_0406.html b/docs/cce/umn/cce_10_0406.html
index 7de4b05ae..7284bf29a 100644
--- a/docs/cce/umn/cce_10_0406.html
+++ b/docs/cce/umn/cce_10_0406.html
@@ -17,7 +17,7 @@
Installing the Add-on The Cloud Native Cluster Monitoring add-on automatically selects a deployment mode based on Data Storage Configuration. This is supported by Cloud Native Cluster Monitoring 3.7.1 or later.
- Original agent mode: Disable Local Data Storage and enable at least one of Report Monitoring Data to AOM and Report Monitoring Data to a Third-Party Platform.
- - Original server mode: Enable Local data storage and Report Monitoring Data to AOM or Report Monitoring Data to a Third-Party Platform.
+ - Original server mode: Enable Local Data Storage and Report Monitoring Data to AOM or Report Monitoring Data to a Third-Party Platform.
- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Add-ons. Locate Cloud Native Cluster Monitoring on the right and click Install.
- On the Install Add-on page, enable at least one item in the Data Storage Configuration area.
- Report Monitoring Data to AOM: Report Prometheus data to AOM. After this function is enabled, you can select the corresponding AOM instance. The collected basic metrics are free of charge. Custom metrics are charged by AOM. To interconnect with AOM, you must have certain permissions. Only users in the admin user group can perform this operation.
- Reporting Monitoring Data to a Third-Party Monitoring Platform: To report Prometheus data to a third-party monitoring system, you need to enter the address and token of the third-party monitoring system and determine whether to skip certificate authentication.
- Local Data Storage: Select the type and size of a disk for storing monitoring data to store Prometheus data in PVCs in the cluster. Storage volumes are not deleted along with the add-on. If Local Data Storage is enabled, all components will be deployed. For details, see Components.
An available PVC named pvc-prometheus-server-0 exists in namespace monitoring and will be used as the storage source.
diff --git a/docs/cce/umn/cce_10_0601.html b/docs/cce/umn/cce_10_0601.html
index 038de171b..e07e83f7b 100644
--- a/docs/cce/umn/cce_10_0601.html
+++ b/docs/cce/umn/cce_10_0601.html
@@ -4,16 +4,16 @@
As of Kubernetes v1.24, dockershim has been deprecated. To maintain compatibility and ensure continued support for future Kubernetes releases, switch your node's container runtime from Docker to the officially endorsed containerd.
- Precautions- Theoretically, container runtime migration will interrupt services for a short period of time. You should have deployed the services on multiple instances for high availability. In addition, you are advised to test the migration impact in the test environment to minimize potential risks.
- containerd cannot build images. Do not use the docker build command to build images on containerd nodes. For other differences between Docker and containerd, see Container Engines.
+ Precautions- Theoretically, container runtime migration will interrupt services for a short period of time. You should have deployed the services on multiple instances for high availability. In addition, you are advised to test the migration impact in the testing environment to minimize potential risks.
- containerd cannot build images. Do not use the docker build command to build images on containerd nodes. For other differences between Docker and containerd, see Container Engines.
- Procedure for Migrating Nodes in the Default Node Pool- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
- In the node list, select one or more nodes to be reset and choose More > Reset Node.
- Set Container Engine to containerd. You can adjust other parameters as required or retain them as set during creation.
-
- If the node status is Installing, the node is being reset.
When the node status is Running, you can see that the node runtime is switched to containerd. You can log in to the node and run containerd commands such as crictl to view information about the containers running on the node.
+Procedure for Migrating Nodes in the Default Node Pool- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Nodes. On the displayed page, click the Nodes tab.
- In the node list, select one or more nodes to be reset and choose More > Reset Node in the Operation column.
- Set Container Engine to containerd. You can adjust other parameters as required or retain them as set during creation.
+
- If the node status is Installing, the node is being reset.
When the node status is Running, you can see that the node runtime is switched to containerd. You can log in to the node and run containerd commands such as crictl to view information about the containers running on the node.
Procedure for Migrating Nodes in a Custom Node PoolYou can copy a node pool, set the container engine of the new node pool to containerd, and keep other configurations the same as those of the original Docker node pool.
- - Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Nodes. On the Node Pools tab, locate the Docker node pool to be copied and choose More > Copy.
-
- In the Node Configuration area, set Container Engine to containerd and modify other parameter settings as needed to create the node pool.
-
- Scale the number of created containerd node pool to the number of original Docker node pool and delete nodes from the Docker node pool one by one.
Rolling migration is preferred. That is, add some containerd nodes and then delete some Docker nodes until the number of nodes in the new containerd node pool is the same as that in the original Docker node pool.
+- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Nodes. On the Node Pools tab, locate the Docker node pool to be copied and choose More > Copy.
+
- In the Node Configuration area, set Container Engine to containerd and modify other parameter settings as needed to create the node pool.
+
- Scale the created containerd node pool as large as the original Docker node pool and delete nodes from the Docker node pool one by one.
Rolling migration is preferred. That is, add some containerd nodes and then delete some Docker nodes until the number of nodes in the new containerd node pool is the same as that in the original Docker node pool.
If you have configured node affinity for the workloads deployed on the original Docker nodes or node pool, configure affinity policies for the workloads to run on the new containerd nodes or node pool.
- Delete the original Docker node pool.
diff --git a/docs/cce/umn/cce_10_0617.html b/docs/cce/umn/cce_10_0617.html
index f075cae23..e97e1215a 100644
--- a/docs/cce/umn/cce_10_0617.html
+++ b/docs/cce/umn/cce_10_0617.html
@@ -5,32 +5,44 @@
Expandable to petabytes, SFS provides fully hosted shared file storage, highly available and stable to handle data- and bandwidth-intensive applications
- Standard file protocols: You can mount file systems as volumes to servers, the same as using local directories.
- Data sharing: The same file system can be mounted to multiple servers, so that data can be shared.
- Private network: Users can access data only in private networks of data centers.
- Capacity and performance: The capacity of a single file system is high (PB level) and the performance is excellent (ms-level I/O latency).
- Use cases: Deployments/StatefulSets in the ReadWriteMany mode and jobs created for high-performance computing (HPC), media processing, content management, web services, big data analysis, and workload process analysis
PerformanceCCE supports SFS Capacity-Oriented. For more details, see File System Types.
+ PerformanceCCE supports SFS Capacity-Oriented and general-purpose file systems (SFS 3.0 Capacity-Oriented). For more details, see File System Types. - If SFS Capacity-Oriented is used, you can still create PVs through kubectl even if the file system is sold out and cannot be created directly via the CCE console. No new SFS Capacity-Oriented file systems can be created via the console anymore.
- General purpose file systems (SFS 3.0 Capacity-Oriented) are currently being rolled out across different regions. Their availability may vary depending on the region. If you encounter any issues, contact SFS customer support or wait for further updates. If the region where your application is located already has SFS 3.0 available, use it for new applications and migrate existing SFS Capacity-Oriented file systems to SFS 3.0 as soon as possible to prevent any service disruptions caused by insufficient capacity.
+
+
- Table 1 PerformanceParameter
+Table 1 PerformanceParameter
|
-SFS Capacity-Oriented
+ | SFS Capacity-Oriented
+ |
+General Purpose File System (SFS 3.0 Capacity-Oriented)
|
|---|
-Maximum bandwidth
+ | Maximum bandwidth
|
-2 GB/s
+ | 2 GB/s
+ |
+1.25 TB/s
|
-Maximum IOPS
+ | Maximum IOPS
|
-2000
+ | 2000
+ |
+Million
|
-Latency
+ | Latency
|
-3–20 ms
+ | 3–20 ms
+ |
+10 ms
|
-Maximum capacity
+ | Maximum capacity
|
-4 PB
+ | 4 PB
+ |
+EB
|
diff --git a/docs/cce/umn/cce_10_0619.html b/docs/cce/umn/cce_10_0619.html
index 1ee6b1f36..86c080873 100644
--- a/docs/cce/umn/cce_10_0619.html
+++ b/docs/cce/umn/cce_10_0619.html
@@ -2,10 +2,10 @@
Using an Existing SFS File System Through a Static PV
SFS is a type of network-attached storage (NAS) that provides shared, scalable, and high-performance file storage. It applies to large-capacity expansion and cost-sensitive services. This section describes how to use an existing SFS file system to statically create PVs and PVCs for data persistence and sharing in workloads.
- Prerequisites
+ Prerequisites- You have created a cluster and installed the CCE Container Storage (Everest) add-on in the cluster.
- To create a cluster using commands, ensure kubectl is used. For details, see Accessing a Cluster Using kubectl.
- You have created an SFS file system that is in the same VPC as the cluster.
- Before using a general purpose file system (SFS 3.0 Capacity-Oriented) for storage, ensure a VPC endpoint has been created in the VPC where the cluster is located for the cluster to access the file system. For details, see Configuring a VPC Endpoint.
- Constraints- Multiple PVs can use the same SFS or SFS Turbo file system with the following restrictions:
- If a pod mounts an SFS or SFS Turbo volume used by multiple PVCs/PVs, and the PVs have identical volumeHandle values, the pod may fail to start. To avoid this issue, do not mount the same SFS or SFS Turbo file system to the same pod.
- The persistentVolumeReclaimPolicy parameter in the PVs must be set to Retain. Otherwise, when a PV is deleted, the associated underlying volume may be deleted. In this case, other PVs associated with the underlying volume malfunction.
- When the underlying volume is repeatedly used, enable isolation and protection for ReadWriteMany at the application layer to prevent data overwriting and loss.
-
+ Notes and Constraints- Multiple PVs can use the same SFS or SFS Turbo file system with the following restrictions:
- If a pod mounts an SFS or SFS Turbo volume used by multiple PVCs/PVs, and the PVs have identical volumeHandle values, the pod may fail to start. To avoid this issue, do not mount the same SFS or SFS Turbo file system to the same pod.
- The persistentVolumeReclaimPolicy parameter in the PVs must be set to Retain. Otherwise, when a PV is deleted, the associated underlying volume may be deleted. In this case, other PVs associated with the underlying volume malfunction.
- When the underlying volume is repeatedly used, enable isolation and protection for ReadWriteMany at the application layer to prevent data overwriting and loss.
+ - If a general purpose file system (SFS 3.0 Capacity-Oriented) is used, Everest v2.0.9 or later must be installed in the cluster.
- If a general purpose file system (SFS 3.0 Capacity-Oriented) is used, the owner group and permission of the mount point cannot be modified. The default owner of the mount point is user root.
- If a general purpose file system (SFS 3.0 Capacity-Oriented) is used, there may be latency during the creation or deletion of PVCs and PVs. The billing duration is determined by the time when the resource is created or deleted on the SFS console.
Using an Existing SFS File System on the Console- Log in to the CCE console and click the cluster name to access the cluster console.
- Statically create a PVC and PV.
- Choose Storage in the navigation pane. In the right pane, click the PVCs tab. Click Create PVC in the upper right corner. In the dialog box displayed, configure PVC parameters.
Parameter
@@ -39,6 +39,8 @@
|
|---|
SFSb
|
Click Select SFS. On the displayed page, select the SFS file system that meets your requirements and click OK.
+ NOTE: Only general purpose file systems (SFS 3.0 Capacity-Oriented) are supported.
+
|
PV Nameb
@@ -111,16 +113,16 @@
-Using an Existing SFS Capacity-Oriented File System Through kubectl- Use kubectl to access the cluster.
- Create a PV.
- Create the pv-sfs.yaml file.
Example: apiVersion: v1
+Using an Existing SFS Capacity-Oriented File System Through kubectl- Use kubectl to access the cluster.
- Create a PV.
- Create the pv-sfs.yaml file.
Example: apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/provisioned-by: everest-csi-provisioner
everest.io/reclaim-policy: retain-volume-only # (Optional) The underlying volume is retained when the PV is deleted.
- name: pv-sfs # PV name
+ name: pv-sfs # PV name
spec:
accessModes:
- - ReadWriteMany # Access mode. The value must be ReadWriteMany for SFS.
+ - ReadWriteMany # Access mode. The value must be ReadWriteMany for SFS.
capacity:
storage: 1Gi # Storage capacity. This parameter is only for verification. It must not be empty or 0, but the specified size will not take effect.
csi:
@@ -128,7 +130,7 @@ spec:
fsType: nfs
volumeHandle: <your_volume_id> # SFS Capacity-Oriented volume ID
volumeAttributes:
- everest.io/share-export-location: <your_location> # Shared path of the SFS volume
+ everest.io/share-export-location: <your_location> # Shared path of the SFS volume
storage.kubernetes.io/csiProvisionerIdentity: everest-csi-provisioner
persistentVolumeReclaimPolicy: Retain # Reclaim policy
storageClassName: csi-nas # StorageClass name. csi-nas indicates that SFS Capacity-Oriented is used.
@@ -147,8 +149,8 @@ spec:
|
No
|
-Only retain-volume-only is supported.
-This parameter is valid only when the Everest version is 1.2.9 or later and the reclaim policy is Delete. If the reclaim policy is Delete and the current value is retain-volume-only, the associated PV is deleted while the underlying storage volume is retained, when a PVC is deleted.
+ | Only retain-volume-only is supported.
+This parameter is valid only when the Everest version is 1.2.9 or later and the reclaim policy is Delete. If the reclaim policy is Delete and the current value is retain-volume-only, the associated PV is deleted while the underlying storage volume is retained, when a PVC is deleted.
|
volumeHandle
@@ -185,9 +187,9 @@ spec:
| Yes
|
A reclaim policy is supported when the cluster version is or later than 1.19.10 and the Everest version is or later than 1.2.9.
-The Delete and Retain reclaim policies are supported. For details, see PV Reclaim Policy. If multiple PVs use the same SFS volume, use Retain to prevent the underlying volume from being deleted with a PV.
-Retain: When a PVC is deleted, the PV and the associated underlying storage resources are retained. The PV changes to the Released state and cannot be bound to another PVC. If you want to continue using the underlying storage resources, delete the PV first. Then, create a new PV and PVC and associate them with the underlying storage resources.
-Delete: When a PVC is deleted, its associated underlying storage resources are deleted and the PV resources are removed. Exercise caution if you select this option.
+The Delete and Retain reclaim policies are supported. For details, see PV Reclaim Policy. If multiple PVs use the same SFS volume, use Retain to prevent the underlying volume from being deleted with a PV.
+Retain: When a PVC is deleted, the PV and the associated underlying storage resources are retained. The PV changes to the Released state and cannot be bound to another PVC. If you want to continue using the underlying storage resources, delete the PV first. Then, create a new PV and PVC and associate them with the underlying storage resources.
+Delete: When a PVC is deleted, its associated underlying storage resources are deleted and the PV resources are removed. Exercise caution if you select this option.
|
storage
@@ -209,7 +211,7 @@ spec:
- Run the following command to create a PV:
kubectl apply -f pv-sfs.yaml
-- Create a PVC.
- Create the pvc-sfs.yaml file.
apiVersion: v1
+ - Create a PVC.
- Create the pvc-sfs.yaml file.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-sfs
@@ -218,7 +220,7 @@ metadata:
volume.beta.kubernetes.io/storage-provisioner: everest-csi-provisioner
spec:
accessModes:
- - ReadWriteMany # The value must be ReadWriteMany for SFS.
+ - ReadWriteMany # The value must be ReadWriteMany for SFS.
resources:
requests:
storage: 1Gi # SFS volume capacity
@@ -260,7 +262,7 @@ spec:
- Run the following command to create a PVC:
kubectl apply -f pvc-sfs.yaml
- - Create an application.
- Create a file named web-demo.yaml. In this example, the SFS volume is mounted to the /data path.
apiVersion: apps/v1
+ - Create an application.
- Create a file named web-demo.yaml. In this example, the SFS volume is mounted to the /data path.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-demo
@@ -279,14 +281,14 @@ spec:
- name: container-1
image: nginx:latest
volumeMounts:
- - name: pvc-sfs-volume # Volume name, which must be the same as the volume name in the volumes field
+ - name: pvc-sfs-volume # Volume name, which must be the same as the volume name in the volumes field
mountPath: /data # Location where the storage volume is mounted
imagePullSecrets:
- name: default-secret
volumes:
- name: pvc-sfs-volume # Volume name, which can be customized
persistentVolumeClaim:
- claimName: pvc-sfs # Name of the created PVC
+ claimName: pvc-sfs # Name of the created PVC
- Run the following command to create a workload to which the SFS volume is mounted:
kubectl apply -f web-demo.yaml
After the workload is created, the data in the container mount directory will be persistently stored. Verify the storage by referring to Verifying Data Persistence and Sharing.
diff --git a/docs/cce/umn/cce_10_0620.html b/docs/cce/umn/cce_10_0620.html
index ee7acdaff..85f5831e2 100644
--- a/docs/cce/umn/cce_10_0620.html
+++ b/docs/cce/umn/cce_10_0620.html
@@ -2,47 +2,49 @@
Using an SFS File System Through a Dynamic PV
This section describes how to use StorageClasses to dynamically create PVs and PVCs for data persistence and sharing in workloads.
- Prerequisites
+ Prerequisites- You have created a cluster and installed the CCE Container Storage (Everest) add-on in the cluster.
- To create a cluster using commands, ensure kubectl is used. For details, see Accessing a Cluster Using kubectl.
- Before using a general purpose file system (SFS 3.0 Capacity-Oriented) for storage, ensure a VPC endpoint has been created in the VPC where the cluster is located for the cluster to access the file system. For details, see Configure a VPC Endpoint.
+
+ Notes and Constraints- If a general purpose file system (SFS 3.0 Capacity-Oriented) is used, CCE Container Storage (Everest) of v2.0.9 or later must be installed in the cluster.
- If a general purpose file system (SFS 3.0 Capacity-Oriented) is used, the owner group and permission of the mount point cannot be modified. The default owner of the mount point is user root.
- If a general purpose file system (SFS 3.0 Capacity-Oriented) is used, there may be a latency during the creation or deletion of PVCs and PVs. The billing duration is determined by the time when the resource is created or deleted on the SFS console.
Dynamically Creating an SFS file system Using the Console- Log in to the CCE console and click the cluster name to access the cluster console.
- Dynamically create a PVC and PV.
- Choose Storage in the navigation pane. In the right pane, click the PVCs tab. Click Create PVC in the upper right corner. In the dialog box displayed, configure PVC parameters.
-
Parameter
+Parameter
|
-Description
+ | Description
|
|---|
-PVC Type
+ | PVC Type
|
-In this example, select SFS.
+ | In this example, select SFS.
|
-PVC Name
+ | PVC Name
|
-Enter the PVC name, which must be unique in a namespace.
+ | Enter the PVC name, which must be unique in a namespace.
|
-Creation Method
+ | Creation Method
|
-- If no underlying storage is available, select Dynamically provision to create a PVC, PV, and underlying storage on the console in cascading mode.
- If underlying storage is available, create a PV or use an existing PV to statically create a PVC. For details, see Using an Existing SFS File System Through a Static PV.
+ | - If no underlying storage is available, select Dynamically provision to create a PVC, PV, and underlying storage on the console in cascading mode.
- If underlying storage is available, create a PV or use an existing PV to statically create a PVC. For details, see Using an Existing SFS File System Through a Static PV.
In this example, select Dynamically provision.
|
-Storage Classes
+ | Storage Classes
|
-The default StorageClass of SFS volumes is csi-nas.
+ | The default StorageClass of SFS volumes is csi-nas.
You can customize a StorageClass and configure its reclaim policy and binding mode. For details, see Creating a StorageClass Through the Console.
|
-(Optional) Storage Volume Name Prefix
+ | (Optional) Storage Volume Name Prefix
|
-Available only when the cluster version is v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later, and Everest v2.4.15 or later is installed in the cluster.
+ | Available only when the cluster version is v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later, and Everest v2.4.15 or later is installed in the cluster.
This parameter specifies the name of the underlying storage that is automatically created. The actual underlying storage name is in the format of "Storage volume name prefix + PVC UID". If this parameter is left blank, the default prefix pvc will be used.
For example, if the storage volume name prefix is set to test, the actual underlying storage name is test-{UID}.
|
-Access Mode
+ | Access Mode
|
-SFS volumes support only ReadWriteMany, indicating that a storage volume can be mounted to multiple nodes in read/write mode. For details, see Volume Access Modes.
+ | SFS volumes support only ReadWriteMany, indicating that a storage volume can be mounted to multiple nodes in read/write mode. For details, see Volume Access Modes.
|
@@ -51,33 +53,33 @@
- Click Create to create a PVC and a PV.
You can choose Storage in the navigation pane and view the created PVC and PV on the PVCs and PVs tabs, respectively.
- Create an application.
- Choose Workloads in the navigation pane. In the right pane, click the Deployments tab.
- Click Create Workload in the upper right corner. On the displayed page, click Data Storage in the Container Information area under Container Settings and choose Add Volume > PVC.
Mount and use storage volumes. For details about the parameters, see Table 1. For other parameters, see Workloads.
- Table 1 Mounting a storage volumeParameter
+Table 1 Mounting a storage volumeParameter
|
-Description
+ | Description
|
|---|
-PVC
+ | PVC
|
-Select an existing SFS volume.
+ | Select an existing SFS volume.
|
-Mount Path
+ | Mount Path
|
-Enter a mount path, for example, /tmp.
+ | Enter a mount path, for example, /tmp.
This parameter specifies a container path to which a data volume will be mounted. Do not mount the volume to a system directory such as / or /var/run. This may lead to container errors. Mount the volume to an empty directory. If the directory is not empty, ensure that there are no files that affect container startup. Otherwise, the files will be replaced, leading to container startup failures or workload creation failures. NOTICE: 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
+ | Subpath
|
-Enter the subpath of the storage volume and mount a path in the storage volume to the container. In this way, different folders of the same storage volume can be used in a single pod. tmp, for example, indicates that data in the mount path of the container is stored in the tmp folder of the storage volume. If this parameter is left blank, the root path will be used by default.
+ | Enter the subpath of the storage volume and mount a path in the storage volume to the container. In this way, different folders of the same storage volume can be used in a single pod. tmp, for example, indicates that data in the mount path of the container is stored in the tmp folder of the storage volume. If this parameter is left blank, the root path will be used by default.
|
-Permission
+ | Permission
|
-- Read-only: You can only read the data in the mounted volumes.
- Read-write: You can modify the data volumes mounted to the path. Newly written data will not be migrated if the container is migrated, which may cause data loss.
+ | - Read-only: You can only read the data in the mounted volumes.
- Read-write: You can modify the data volumes mounted to the path. Newly written data will not be migrated if the container is migrated, which may cause data loss.
|
@@ -106,54 +108,54 @@ spec:
resources:
requests:
storage: 1Gi # SFS volume capacity
- storageClassName: csi-nas # The StorageClass is SFS.
+ storageClassName: csi-nas # The StorageClass is SFS. csi-sfs indicates that a general purpose file system (SFS 3.0 Capacity-Oriented) is used.
-Table 2 Key parametersParameter
+Table 2 Key parametersParameter
|
-Mandatory
+ | Mandatory
|
-Description
+ | Description
|
|---|
-storage
+ | storage
|
-Yes
+ | Yes
|
-Requested capacity in the PVC, in Gi.
+ | Requested capacity in the PVC, in Gi.
For SFS, this parameter is only for verification. It must not be empty or 0, and its value is fixed at 1. Any value you set will not take effect.
|
-everest.io/crypt-key-id
+ | everest.io/crypt-key-id
|
-No
+ | No
|
-If the StorageClass is csi-nas, you can determine whether to encrypt the underlying storage.
+ | If the StorageClass is csi-nas, you can determine whether to encrypt the underlying storage.
This parameter is mandatory when an SFS system is encrypted. Enter the encryption key ID selected during SFS system creation. You can use a custom key or the default key named sfs/default.
To obtain a key ID, log in to the DEW console, locate the key to be encrypted, and copy the key ID.
|
-everest.io/crypt-alias
+ | everest.io/crypt-alias
|
-No
+ | No
|
-Key name, which is mandatory when you create an encrypted volume.
+ | Key name, which is mandatory when you create an encrypted volume.
To obtain a key name, log in to the DEW console, locate the key to be encrypted, and copy the key name.
|
-everest.io/crypt-domain-id
+ | everest.io/crypt-domain-id
|
-No
+ | No
|
-ID of the tenant to which the encrypted volume belongs. This parameter is mandatory for creating an encrypted volume.
+ | ID of the tenant to which the encrypted volume belongs. This parameter is mandatory for creating an encrypted volume.
To obtain a tenant ID, hover the cursor over the username in the upper right corner of the ECS console, choose My Credentials, and copy the account ID.
|
-everest.io/csi.volume-name-prefix
+ | everest.io/csi.volume-name-prefix
|
-No
+ | No
|
-(Optional) This parameter is available only when the cluster version is v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later, and Everest v2.4.15 or later is installed in the cluster.
+ | (Optional) This parameter is available only when the cluster version is v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later, and Everest v2.4.15 or later is installed in the cluster.
This parameter specifies the name of the underlying storage that is automatically created. The actual underlying storage name is in the format of "Storage volume name prefix + PVC UID". If this parameter is left blank, the default prefix pvc will be used.
Enter 1 to 26 characters that cannot start or end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
For example, if the storage volume name prefix is set to test, the actual underlying storage name is test-{UID}.
@@ -240,40 +242,40 @@ static
Related OperationsYou can also perform the operations listed in Table 3.
- Table 3 Related operationsOperation
+Table 3 Related operationsOperation
|
-Description
+ | Description
|
-Procedure
+ | Procedure
|
|---|
-Viewing events
+ | Viewing events
|
-View event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time of the PVC or PV.
+ | View event names, event types, number of occurrences, Kubernetes events, first occurrence time, and last occurrence time of the PVC or PV.
|
-- Choose Storage in the navigation pane. In the right pane, click the PVCs or PVs tab.
- Click View Events in the Operation column of the target PVC or PV to view events generated within one hour (events are retained for one hour).
+ | - Choose Storage in the navigation pane. In the right pane, click the PVCs or PVs tab.
- Click View Events in the Operation column of the target PVC or PV to view events generated within one hour (events are retained for one hour).
|
-Viewing a YAML file
+ | Viewing a YAML file
|
-View, copy, or download the YAML file of a PVC or PV.
+ | View, copy, or download the YAML file of a PVC or PV.
|
-- Choose Storage in the navigation pane. In the right pane, click the PVCs or PVs tab.
- Click View YAML in the Operation column of the target PVC or PV to view or download the YAML.
+ | - Choose Storage in the navigation pane. In the right pane, click the PVCs or PVs tab.
- Click View YAML in the Operation column of the target PVC or PV to view or download the YAML.
|
-Editing Reclaim Policy
+ | Editing Reclaim Policy
|
-Modify the reclaim policy of a PV.
+ | Modify the reclaim policy of a PV.
|
-- In the navigation pane, choose Storage. Then click the PVs tab.
- Locate the row containing the target PV and choose More > Edit Reclaim Policy.
+ | - In the navigation pane, choose Storage. Then click the PVs tab.
- Locate the row containing the target PV and choose More > Edit Reclaim Policy.
|
-Synchronizing PVC capacity (supported only for PVCs created from non-subdirectories of SFS Capacity-Oriented file systems)
+ | Synchronizing PVC capacity (supported only for PVCs created from non-subdirectories of SFS Capacity-Oriented file systems)
|
-When the underlying storage outgrows the PVC, resize the PVC capacity on the CCE console to match the new size.
+ | When the underlying storage outgrows the PVC, resize the PVC capacity on the CCE console to match the new size.
|
-- In the navigation pane, choose Storage. Then, click the PVCs tab.
- Locate the target PVC and click Synchronize in the Capacity column to make the PVC capacity consistent with the underlying storage capacity.
Synchronize is only displayed when the underlying storage capacity is greater than the PVC capacity.
+- In the navigation pane, choose Storage. Then, click the PVCs tab.
- Locate the target PVC and click Synchronize in the Capacity column to make the PVC capacity consistent with the underlying storage capacity.
Synchronize is only displayed when the underlying storage capacity is greater than the PVC capacity.
|
|
diff --git a/docs/cce/umn/cce_10_0626.html b/docs/cce/umn/cce_10_0626.html
index 172740da3..38941d99f 100644
--- a/docs/cce/umn/cce_10_0626.html
+++ b/docs/cce/umn/cce_10_0626.html
@@ -4,7 +4,7 @@
This section describes how to configure SFS Turbo mount options. For SFS Turbo, you can only set mount options in a PV and bind the PV by creating a PVC.
PrerequisitesThe CCE Container Storage (Everest) version must be 1.2.8 or later. This add-on identifies the mount options and transfers them to the underlying storage resources. The parameter settings take effect only if the underlying storage resources support the specified options.
- Constraints- Mount options cannot be configured for secure containers.
- Due to the restrictions of the NFS protocol, if an SFS volume is mounted to a node for multiple times, link-related mounting parameters (such as timeo) take effect only when the SFS volume is mounted for the first time by default. For example, if the same SFS file system is mounted to multiple pods running on a node, the mounting parameter set later does not overwrite the existing parameter value. If you want to configure different mounting parameters in the preceding scenario, additionally configure the nosharecache parameter.
+ Notes and Constraints- Mount options cannot be configured for secure containers.
- Due to the restrictions of the NFS protocol, if an SFS volume is mounted to a node for multiple times, link-related mounting parameters (such as timeo) take effect only when the SFS volume is mounted for the first time by default. For example, if the same SFS file system is mounted to multiple pods running on a node, the mounting parameter set later does not overwrite the existing parameter value. If you want to configure different mounting parameters in the preceding scenario, additionally configure the nosharecache parameter.
SFS Turbo Mount OptionsThe Everest add-on in CCE presets the options described in Table 1 for mounting SFS Turbo volumes.
diff --git a/docs/cce/umn/cce_10_0651.html b/docs/cce/umn/cce_10_0651.html
index 8ea853944..66fcbef40 100644
--- a/docs/cce/umn/cce_10_0651.html
+++ b/docs/cce/umn/cce_10_0651.html
@@ -180,10 +180,10 @@ spec:
None
|
- Billed by traffic or bandwidth
+ | Bandwidth mode.
You are advised to configure this parameter. If this parameter is left blank, no billing mode is specified. In this case, the default value of the EIP API in the region is used.
|
- - bandwidth: billed by bandwidth
- traffic: billed by traffic
+ | - traffic: billed by traffic
|
yangtse.io/eip-bandwidth-name
@@ -221,7 +221,7 @@ spec:
|
Whether to allocate an EIP with a pod and bind the EIP to the pod
|
-false or true
+ | false or true
|
yangtse.io/eip-network-type
diff --git a/docs/cce/umn/cce_10_0734.html b/docs/cce/umn/cce_10_0734.html
index 810220da3..90ef456ad 100644
--- a/docs/cce/umn/cce_10_0734.html
+++ b/docs/cce/umn/cce_10_0734.html
@@ -54,7 +54,7 @@ spec:
yangtse.io/pod-with-eip: "true" # An EIP will be automatically allocated when the pod is created.
yangtse.io/eip-bandwidth-size: "5" # EIP bandwidth
yangtse.io/eip-network-type: 5_bgp # EIP type
- yangtse.io/eip-charge-mode: bandwidth # EIP billing mode
+ yangtse.io/eip-charge-mode: traffic # EIP billing mode
yangtse.io/eip-bandwidth-name: <eip_bandwidth_name> # EIP bandwidth name
spec:
containers:
@@ -122,10 +122,10 @@ spec:
|
None
|
-Billed by traffic or bandwidth
+ | Bandwidth mode.
You are advised to configure this parameter. If this parameter is left blank, no billing mode is specified. In this case, the default value of the EIP API in the region is used.
|
-- bandwidth: billed by bandwidth
- traffic: billed by traffic
+ | - traffic: billed by traffic
|
yangtse.io/eip-bandwidth-name
@@ -193,7 +193,7 @@ spec:
|
Whether to allocate an EIP with a pod and bind the EIP to the pod
|
-false or true
+ | false or true
|
yangtse.io/eip-network-type
@@ -289,7 +289,7 @@ metadata:
yangtse.io/pod-with-eip: "true"
yangtse.io/eip-bandwidth-size: "5"
yangtse.io/eip-network-type: 5_bgp
- yangtse.io/eip-charge-mode: bandwidth
+ yangtse.io/eip-charge-mode: traffic
yangtse.io/eip-bandwidth-name: "xxx"
spec:
initContainers:
diff --git a/docs/cce/umn/cce_10_0850.html b/docs/cce/umn/cce_10_0850.html
new file mode 100644
index 000000000..91b25b59f
--- /dev/null
+++ b/docs/cce/umn/cce_10_0850.html
@@ -0,0 +1,117 @@
+
+
+Comparison Between LoadBalancer Ingresses and Nginx Ingresses
+In CCE, clusters can use Nginx ingresses and LoadBalancer ingresses to enable Layer 7 network access for applications.
+ - Nginx ingresses, enhanced by CCE using the NGINX Ingress Controller from the community, regularly update community features and bug fixes. Nginx ingresses provide various configuration options, catering to users with advanced gateway customization requirements.
- LoadBalancer ingresses, backed by ELB, offer fully managed and O&M-free services. They can handle tens of millions of concurrent connections and millions of new connections. LoadBalancer ingresses can access both shared and dedicated load balancers.
+ This section describes the differences between Nginx ingresses and LoadBalancer ingresses.
+ Typical Application Scenarios
+ Type
+ |
+Feature
+ |
+
|---|
+
+Nginx ingress
+ |
+- Standard configurations
- Extensive gateway customization
- Canary release and blue-green deployment of cloud native applications
+ |
+
+LoadBalancer ingress
+ |
+- Hosted gateway that is highly available and O&M-free
- Layer 7 high-performance auto scaling of cloud native applications
- Canary release and blue-green deployment of cloud native applications
- Isolated resources for dedicated use. A load balancer deployed in a single AZ can handle up to 20 million concurrent connections, making it ideal for managing a large volume of requests.
+ |
+
+
+
+
+
+ Functions
+ Item
+ |
+Nginx Ingress
+ |
+LoadBalancer Ingress
+ |
+
|---|
+
+Positioning
+ |
+Layer 7 traffic governance offers various advanced routing functions.
+ |
+- Layer 7 traffic governance offers various advanced routing functions. It seamlessly incorporates cloud native technologies to deliver fully managed load balancing services that are O&M-free, highly available, high-performance, ultra-secure, and support multiple protocols.
- Computing resources can be scaled to handle traffic surges.
- LoadBalancer ingresses can handle tens of millions of concurrent connections and millions of new connections.
+ |
+
+Basic routing
+ |
+- Routing can be based on content and source IP addresses.
- HTTP header modification, redirection, rewriting, rate limiting, cross-region routing, and sticky sessions are available.
- Forwarding rules can be configured for both requests and responses, and the rules for responses can be configured using extended Snippet.
- Forwarding rules are matched based on the longest path. If multiple paths are matched, the longest forwarding path is prioritized.
+ |
+- Routing can be based on content and source IP addresses.
- HTTP header modification, redirection, rewriting, rate limiting, cross-region routing, and sticky sessions are available.
- Forwarding rules can be configured for both requests and responses.
- Forwarding rules are prioritized in descending order. If multiple paths are matched, a lower value indicates a higher priority.
+ |
+
+Protocol
+ |
+- HTTP and HTTPS
- WebSocket, WSS, and gRPC
+ |
+
+ |
+
+Configuration modification
+ |
+- Processes must be reloaded for non-backend endpoint changes. This causes loss to persistent connections.
- Lua supports hot updates of endpoint changes.
- Processes must be reloaded for a Lua modification.
+ |
+The declarative OpenAPI between cloud services enables the dynamic loading of modified configurations to ELB.
+ |
+
+Authentication
+ |
+- Basic authentication
- OAuth
+ |
+TLS authentication
+ |
+
+Performance
+ |
+- Both system and Nginx parameters require manual optimization for performance tuning.
- To ensure proper system running, you must configure a proper number of replicas and resource limits. For more information, see Creating an Nginx Ingress on the Console.
+ |
+LoadBalancer ingresses can handle tens of millions of concurrent connections and millions of new connections.
+ |
+
+Observability
+ |
+- Log collection through Access Log
- Monitoring and alarm configuration through Prometheus
+ |
+- Log access for cloud services through interconnected LTS
- Auditing key operations
- Metrics-backed monitoring through interconnected Cloud Eye
- Alarm rules configurable through interconnected Cloud Eye
+ |
+
+O&M
+ |
+- Bring-your-own component maintenance and periodic version synchronization from the community
- Scaling through HPA
- Proactive configuration for optimization
+ |
+- Fully managed and O&M-free
- Configuration-free automatic scaling for ultra-large capacity
- Auto scaling based on service traffic
+ |
+
+Security
+ |
+- HTTPS
- Blocklists and trustlists
+ |
+- SSL-integrated HTTPS for full-link HTTPS, SNI multi-certificate, RSA, ECC dual-certification, TLS 1.3, and TLS algorithm suites
- WAF
- Anti-DDoS
- Blocklists and trustlists
- Custom security policies
+ |
+
+Service governance
+ |
+
+ |
+- Canary release and blue-green deployment
+ |
+
+
+
+
+
+ Redirecting Traffic from an Nginx Ingress to a LoadBalancer Ingress
+ This section contains important information. Ignoring the information may affect your services.
+
+ ContextThe Kubernetes contributor community recently released a blog post Ingress NGINX Retirement: What You Need to Know, in which SIG Network and the Security Response Committee jointly announced the upcoming retirement of Ingress NGINX.
+ Key points of this notice:
+ - The project will be maintained until March 2026. Afterward, there will be no official support.
- There will be no further releases.
- There will be no function bug fixes and no updates to resolve any security vulnerabilities (including high-risk CVEs that may be discovered).
- The GitHub repositories will be made read-only and left available for reference.
- Existing deployments of Ingress NGINX will continue to function, and installation packages will remain available. However, no more updates to security vulnerabilities have caused a strong reaction among community and enterprise users. Although the official recommended that all Ingress NGINX users begin migration to Gateway API or any one of other 20+ active ingress controllers, most enterprises are concerned about the following issues:
- Can the new controller be compatible with the annotations of the Nginx ingress?
- How do I redirect traffic in grayscale mode without service interruptions?
- How do I roll back in seconds if traffic is abnormal?
+
+ CCE LoadBalancer ingresses can help you smoothly redirect traffic from Nginx ingresses. We provide a complete redirection solution that has been verified in production. This solution covers the annotation replacement table, grayscale traffic redirection, monitoring and alarms, and rollback in seconds, which can ensure no service interruptions and hitless rollout.
+
+ LoadBalancer Ingress OverviewAs a hosted ingress solution of CCE, LoadBalancer ingresses have many advantages over the community edition nginx-ingress in enterprise-class application scenarios. The core advantage is the hosted architecture. You do not need to deploy or maintain the controller. CCE is responsible for high-availability deployment, fault self-healing, and version iteration, greatly reducing O&M complexity and labor costs.
+ With the distributed architecture of ELB, this solution provides powerful performance and auto scaling, which can easily handle high-concurrency traffic. You can achieve automatic workload scale-out without manually optimizing configurations. This ensures service stability during peak hours. In addition, this solution is deeply integrated with services such as WAF, certificate hosting, and monitoring and logging. Security and compliance capabilities can be enabled with just one click, without extra development and integration, simplifying the process of implementing enterprise-level functions.
+ Its visualized pages and comprehensive fault diagnosis tools make using the Kubernetes ingress easier, and improve rule synchronization and troubleshooting efficiency. For enterprises' core services running on CCE, LoadBalancer ingresses are the optimal choice with cost-effectiveness, security, and reliability, as well as high performance, stability, and ease of use.
+ For details about the comparison between LoadBalancer ingresses and Nginx ingresses, see Comparison Between LoadBalancer Ingresses and Nginx Ingresses.
+
+ Traffic Redirection ProcessYou can resolve the same domain name to the IP addresses of the load balancers used by an Nginx ingress and a LoadBalancer ingress and adjust the DNS records' weights of the two ingresses to redirect traffic. This redirection is transparent to the clients. The following figure shows the process of DNS-based traffic redirection.
+ DNS-based traffic redirection is not the only way to achieve transparent redirection. The examples in this section are for reference only.
+
+ 
+ As the technology stacks are different, the annotations of Nginx ingresses need to be converted into the LoadBalancer ingress specifications for traffic redirection. For details, see Table 1. For more LoadBalancer ingress configuration specifications, see Configuring Advanced LoadBalancer Ingress Functions Using Annotations.
+ A LoadBalancer ingress supports 80% to 90% of Nginx rules, but does not support Nginx-specific functions, such as nginx.ingress.kubernetes.io/auth-* (authentication required on the ELB console) or nginx.ingress.kubernetes.io/configuration-snippet (no equivalent ELB rule for custom Nginx configuration).
+
+ Table 1 Comparison of common annotationsFunction
+ |
+Example Nginx Annotation
+ |
+Example of Equivalent LoadBalancer Annotation
+ |
+
|---|
+
+Specifying ingress class
+ |
+kubernetes.io/ingress.class: "nginx"
+ |
+spec.ingressClassName: "cce" or kubernetes.io/ingress.class: "cce" (v1.21 and earlier)
+ |
+
+Associating the load balancer ID
+ |
+None (The load balancer is specified when the NGINX Ingress Controller add-on is installed.)
+ |
+kubernetes.io/elb.id: "<elb-uuid>"
+ |
+
+Load balancer type/specifications
+ |
+None
+ |
+kubernetes.io/elb.class: "union" (shared) or kubernetes.io/elb.class: "performance" (dedicated)
+ |
+
+Frontend port
+ |
+None
+ |
+kubernetes.io/elb.port: "80"
+ |
+
+Automatically creating a load balancer
+ |
+None
+ |
+kubernetes.io/elb.autocreate: '{"type":"inner", "name": "A-location-d-test"}'
+ |
+
+Rewriting a URL
+ |
+nginx.ingress.kubernetes.io/rewrite-target: /$2
+ |
+kubernetes.io/elb.rewrite-target: "/$2"
+ |
+
+Redirecting HTTP to HTTPS
+ |
+nginx.ingress.kubernetes.io/ssl-redirect: "true"
+ |
+kubernetes.io/elb.ssl-redirect: "true"
+kubernetes.io/elb.listen-ports: '[{"HTTP":80},{"HTTPS":443}]'
+ |
+
+IP address whitelist
+ |
+nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/16"
+ |
+kubernetes.io/elb.acl-id: '<acl-uid>'
+kubernetes.io/elb.acl-status: 'on'
+kubernetes.io/elb.acl-type: 'black'
+ |
+
+CORS support
+ |
+nginx.ingress.kubernetes.io/enable-cors: "true"
+nginx.ingress.kubernetes.io/cors-allow-origin: "*"
+ |
+kubernetes.io/elb.cors-allow-origin: 'http://example.com'
+kubernetes.io/elb.cors-allow-headers: 'fake-header-1'
+kubernetes.io/elb.cors-expose-headers: 'fake-header-2'
+kubernetes.io/elb.cors-allow-methods: 'GET,POST'
+kubernetes.io/elb.cors-allow-credentials: 'true'
+kubernetes.io/elb.cors-max-age: '3600'
+ |
+
+TLS certificate
+ |
+spec.tls.secretName (TLS secret)
+ |
+kubernetes.io/elb.tls-certificate-id: "<cert-id>" (load balancer certificate) or spec.tls.secretName (TLS secret)
+ |
+
+Grayscale release
+ |
+nginx.ingress.kubernetes.io/canary: "true"
+nginx.ingress.kubernetes.io/canary-weight: "20"
+ |
+kubernetes.io/elb.canary: "true"
+kubernetes.io/elb.canary-weight: "100"
+ |
+
+Slow startup
+ |
+No direct support
+ |
+kubernetes.io/elb.slow-start: "30"
+ |
+
+Tags
+ |
+None
+ |
+kubernetes.io/elb.tags: '{"key1":"value1","key2":"value2"}'
+ |
+
+HTTP/2
+ |
+nginx.ingress.kubernetes.io/ssl-protocols: "TLSv1.2 TLSv1.3"
+ |
+kubernetes.io/elb.http2-enable: "true"
+ |
+
+gRPC support
+ |
+nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
+ |
+kubernetes.io/elb.pool-protocol: "grpc"
+ |
+
+
+
+
+
+ Example ScenarioAssume that your company is using a CCE cluster to run services. You have set up domain-based and URL-based forwarding rules for the ingress using NGINX Ingress Controller. The services are accessible externally through a domain name hosted on DNS. When a client requests access to the domain name example.com, the Nginx ingress forwards the request to the pods associated with the Service based on the forwarding rules created on the ingress.
+ 
+ To develop services, you must transfer data from the Nginx ingress to a LoadBalancer ingress. To maintain service stability, you want to keep the DNS domain name and IP addresses of backend servers unchanged. To meet this requirement, you can configure LoadBalancer ingress rules in the CCE cluster to preserve the previous forwarding rules. Then, adjust the weights of the DNS records to redirect traffic from the Nginx ingress to the LoadBalancer ingress.
+ 
+ After all traffic is redirected to the LoadBalancer ingress, you can delete the DNS record and resources of the Nginx ingress. This process is transparent to the client.
+ 
+ - Redirect traffic during off-peak hours.
- Before redirecting traffic, compare the forwarding rules of the Nginx ingress and LoadBalancer ingress and conduct tests to ensure that the two ingresses have the same access functions. This prevents services from being affected during traffic redirection.
+
+
+ Step 1: Configure the Target LoadBalancer Ingress- Create the target LoadBalancer ingress. This example uses a basic LoadBalancer ingress that directs traffic to the original backend service, with no complex forwarding rules added. In actual services, you need to analyze the original Nginx ingress forwarding rules and add alternatives to the LoadBalancer ingress. For details, see Table 1.
In this example, an existing load balancer is used to create an ingress, and the elbingress.yaml is for reference only. You can also choose to automatically create a load balancer associated with the ingress. For more information, see Creating a LoadBalancer Ingress Using kubectl. apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ name: ingress-test
+ annotations:
+ kubernetes.io/elb.id: <your_elb_id> # Replace it with the ID of your existing load balancer.
+ kubernetes.io/elb.ip: <your_elb_ip> # Replace it with the IP address of your existing load balancer.
+ kubernetes.io/elb.class: performance # Load balancer type. performance indicates a dedicated load balancer.
+ kubernetes.io/elb.port: '80'
+spec:
+ rules:
+ - host: 'example.com' # Replace it with your domain name.
+ http:
+ paths:
+ - path: '/'
+ backend:
+ service:
+ name: <your_service_name> # Replace it with the name of your target Service, which is the same as the Service associated with the original Nginx ingress.
+ port:
+ number: 8080 # Replace 8080 with the port number of your target Service.
+ property:
+ ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
+ pathType: ImplementationSpecific
+ ingressClassName: cce
+ - Run the following command to create the ingress:
kubectl apply -f elbingress.yaml
+ - After the LoadBalancer ingress is created, fully verify this ingress to ensure that its access function is the same as that of the Nginx ingress.
+
+ Step 2: Gradually Redirect Traffic to the LoadBalancer IngressBefore redirecting traffic, ensure you have created an A record to map the domain name to the public IP address of the load balancer used by the Nginx ingress. You can configure weighted DNS records to redirect traffic from the Nginx ingress to the LoadBalancer ingress.
+ To redirect traffic, do as follows:
+ - Go to Public Zones.
- On the Public Zones page, click the domain name (example.com) of the public zone.
- The Record Sets page is displayed. You can find an A record, which contains the public IP address of the load balancer used by the Nginx ingress. Set the weight of this A record to 100.
- Add an A record set. To do so, click Add Record Set, and set Value to the public IP address of the load balancer used by the LoadBalancer ingress and Weight to 0.
+
- Decrease the DNS record weight of the Nginx ingress (for example, to 90) and increase the DNS record weight of the LoadBalancer ingress (for example, to 10) without affecting any services.
- Verify the traffic redirection effect and ensure that some traffic has been forwarded to the LoadBalancer ingress and there is no exception.
- Repeat 5 to 6 to gradually decrease the DNS record weight of the Nginx ingress to 0 and increase the DNS record weight of the LoadBalancer ingress to 100.
+
+ Step 3: Delete Unnecessary ResourcesAfter all persistent connections to the Nginx ingress are released and there is no more traffic being forwarded to it, you can safely release any unnecessary resources after observing for a period of time.
+ - Delete the DNS record of the Nginx ingress.
- Delete the resources of the Nginx ingress from the cluster.
- Uninstall NGINX Ingress Controller.
- Delete the load balancer used by the Nginx ingress.
+
+
+ |
- 2.0.2
+ | 2.1.1
+ |
+Commercial use
+ |
+v1.27
+v1.28
+v1.29
+v1.30
+v1.31
+v1.32
+v1.33
+ |
+- Support for only the CCE standard clusters that use VPC networks
- Upgraded Cilium to v1.17.6.
- Support for CCE standard clusters of v1.33
- Custom Cilium parameters
- Configurable Hubble observability
+ |
+v1.17
+ |
+
+2.0.2
|
OBT
|
@@ -185,6 +202,23 @@ kubectl patch daemonset -nkube-system yangtse-cilium --type='json' -p="[{\"op\":
v1.17
|
+1.0.16
+ |
+Limited OBT
+ |
+v1.27
+v1.28
+v1.29
+v1.30
+v1.31
+v1.32
+v1.33
+ |
+- Support for CCE Turbo clusters of v1.33
+ |
+v1.14
+ |
+
1.0.15
|
Limited OBT
diff --git a/docs/cce/umn/cce_bestpractice_00004.html b/docs/cce/umn/cce_bestpractice_00004.html
index 24fb1a9f2..456bc4b59 100644
--- a/docs/cce/umn/cce_bestpractice_00004.html
+++ b/docs/cce/umn/cce_bestpractice_00004.html
@@ -24,11 +24,11 @@
Single-VPC Multi-Cluster ScenariosVPC network model
- Pod packets are forwarded through VPC routes. CCE automatically configures a routing table on the VPC routes to each container CIDR block. The network scale is limited by the VPC route table. Figure 4 shows the CIDR block planning of the cluster. - VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
- Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
- Container CIDR Block: If multiple VPC network model clusters exist in a single VPC, the container CIDR blocks of all clusters cannot overlap because the clusters use the same routing table. In this case, if the node security group allows container CIDR block from the peer cluster, pods in one cluster can directly access pods in another cluster through the pod IP addresses.
- Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the cluster subnet CIDR block and container subnet CIDR block.
+ Pod packets are forwarded through VPC routes. CCE automatically configures a routing table on the VPC routes to each container CIDR block. The network scale is limited by the VPC route table. Figure 4 shows the CIDR block planning of the cluster. - VPC CIDR block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
- Subnet CIDR block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
- Container CIDR block: If multiple VPC network model clusters exist in a single VPC, the container CIDR blocks of all clusters cannot overlap because the clusters use the same routing table. In this case, if the node security group allows container CIDR block from the peer cluster, pods in one cluster can directly access pods in another cluster through the pod IP addresses.
- Service CIDR block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the cluster CIDR block and container subnet CIDR block.
Figure 4 VPC network - multi-cluster scenario
Tunnel network model
- Though at some cost of performance, the tunnel encapsulation enables higher interoperability and compatibility with advanced features (such as network policy-based isolation), meeting the requirements of most applications. Figure 5 shows the CIDR block planning of the cluster. - VPC CIDR Block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
- Subnet CIDR Block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
- Container CIDR Block: The container CIDR blocks of all clusters can overlap. In this case, pods in different clusters cannot be directly accessed through pod IP addresses. Services are required for accessing pods in different clusters. The LoadBalancer Services are recommended.
- Service CIDR Block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the cluster CIDR block and container subnet CIDR block.
+ Though at some cost of performance, the tunnel encapsulation enables higher interoperability and compatibility with advanced features (such as network policy-based isolation), meeting the requirements of most applications. Figure 5 shows the CIDR block planning of the cluster. - VPC CIDR block: specifies the VPC CIDR block where the cluster resides. The size of this CIDR block affects the maximum number of nodes that can be created in the cluster.
- Subnet CIDR block: The subnet CIDR block in each cluster cannot overlap with the container CIDR block.
- Container CIDR block: The container CIDR blocks of all clusters can overlap. In this case, pods in different clusters cannot be directly accessed through pod IP addresses. Services are required for accessing pods in different clusters. The LoadBalancer Services are recommended.
- Service CIDR block: can be used only in clusters. Therefore, the Service CIDR blocks of different clusters can overlap, but cannot overlap with the cluster CIDR block and container subnet CIDR block.
Figure 5 Tunnel network - multi-cluster scenario
Cloud Native 2.0 network model (CCE Turbo Clusters)
@@ -52,7 +52,7 @@
Pay attention to the following:
- The VPC CIDR blocks of the clusters at the two ends must not overlap.
- The container CIDR blocks of all clusters can overlap, so do the Service CIDR blocks.
- If the request end cluster uses the tunnel network, check whether the node security group in the target cluster allows the VPC CIDR block (including the node subnets) of the request end cluster. If yes, nodes in one cluster can access nodes in another cluster. However, pods in different clusters cannot be directly accessed using pod IP addresses. Access between pods in different clusters requires Services. The LoadBalancer Services are recommended.
- You need to add routes for accessing the peer network CIDR block to the VPC routing tables at both ends. For example, you need to add a route for accessing the CIDR block of VPC 2 to the route table of VPC 1, and add a route for accessing VPC 1 to the route table of VPC 2. After the route of the VPC CIDR block is added, the pod can access a node in another cluster, for example, through the port of a NodePort Service.
Clusters using Cloud Native 2.0 networks (CCE Turbo clusters)
- After creating a VPC peering connection, add routes of the VPC peering connection to both ends so that the two VPCs can communicate with each other. Pay attention to the following: - The VPC CIDR blocks of the clusters at the two ends must not overlap.
- If the request end cluster uses the Cloud Native 2.0 network, check whether the elastic network interface security group (named in the format of {Cluster name}-cce-eni-{Random ID}) of the target cluster allows the VPC CIDR block (including the node subnets and container CIDR block) of the request end cluster. If yes, pods in one cluster can directly access pods in another cluster through the pod IP addresses. Similarly, if nodes in the clusters at the two ends of the VPC peering need to access each other, allow the VPC CIDR block of the peer cluster in the node security group (named in the format of {Cluster name}-cce-node-{Random ID}).
- You need to add routes for accessing the peer network CIDR block to the VPC routing tables at both ends. For example, you need to add a route for accessing the CIDR block of VPC 2 to the route table of VPC 1, and add a route for accessing VPC 1 to the route table of VPC 2. After the route of the VPC CIDR block is added, the pod can access pod IP addresses or nodes in another cluster.
+ After creating a VPC peering connection, add routes of the VPC peering connection to both ends so that the two VPCs can communicate with each other. Pay attention to the following: - The VPC CIDR blocks of the clusters at the two ends must not overlap.
- If the request end cluster uses the Cloud Native 2.0 network, check whether the elastic network interface security group (named in the format of {Cluster name}-cce-eni-{Random ID}) of the target cluster allows the VPC CIDR block (including the node subnets and container CIDR block) of the request end cluster. If yes, pods in one cluster can directly access pods in another cluster through pod IP addresses. Similarly, if nodes in the clusters at the two ends of the VPC peering need to access each other, allow the VPC CIDR block of the peer cluster in the node security group (named in the format of {Cluster name}-cce-node-{Random ID}).
- You need to add routes for accessing the peer network CIDR block to the VPC routing tables at both ends. For example, you need to add a route for accessing the CIDR block of VPC 2 to the route table of VPC 1, and add a route for accessing VPC 1 to the route table of VPC 2. After the route of the VPC CIDR block is added, the pod can access pod IP addresses or nodes in another cluster.
Clusters using different networks
If clusters using different networks need to communicate with each other across VPCs, every one of them may serve as the request end or destination end. Pay attention to the following:
diff --git a/docs/cce/umn/cce_bestpractice_0006.html b/docs/cce/umn/cce_bestpractice_0006.html
index c0bde7a59..89d4761b0 100644
--- a/docs/cce/umn/cce_bestpractice_0006.html
+++ b/docs/cce/umn/cce_bestpractice_0006.html
@@ -21,7 +21,7 @@ API Version:1.35
Download the environment required by the application.
- Download Tomcat, JDK, and MongoDB installation packages of the specific versions.
- Download JDK 1.8.
Download address: https://www.oracle.com/java/technologies/jdk8-downloads.html.
- - Download Tomcat 7.0 from http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.82/bin/apache-tomcat-7.0.82.tar.gz.
- Download MongoDB 3.2 from https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-3.2.9.tgz.
+ - Download Tomcat 7.0 from https://archive.apache.org/dist/tomcat/tomcat-7/v7.0.82/bin/apache-tomcat-7.0.82.tar.gz.
- Download MongoDB 3.2 from https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-3.2.9.tgz.
- Log in as user root to the device running Docker.
- Run the following commands to create the directory where the application is to be stored: For example, set the directory to apptest.
mkdir apptest
cd apptest
- Use Xshell to save the downloaded dependency files to the apptest directory.
- Run the following commands to decompress the dependency files:
tar -zxf apache-tomcat-7.0.82.tar.gz
diff --git a/docs/cce/umn/cce_bestpractice_00198.html b/docs/cce/umn/cce_bestpractice_00198.html
index 2b7318aa4..fc369bc1d 100644
--- a/docs/cce/umn/cce_bestpractice_00198.html
+++ b/docs/cce/umn/cce_bestpractice_00198.html
@@ -128,7 +128,7 @@ tmpfs tmpfs 1.8G 75M 1.8G 5% /tmp
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
└─sda1 8:1 0 50G 0 part /
-sdb 8:16 0 150G 0 disk # The data disk has been expanded to 150 GiB, but 50 GiB space is free.
+sdb 8:16 0 150G 0 disk # The data disk has been expanded to 150 GiB, but 50-GiB space is not allocated.
├─vgpaas-dockersys 253:0 0 90G 0 lvm /var/lib/containerd
└─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet
- Expand the disk capacity.
Add the new disk capacity to the dockersys logical volume used by the container engine.
@@ -228,7 +228,7 @@ vda 8:0 0 50G 0 disk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
└─sda1 8:1 0 50G 0 part /
-sdb 8:16 0 200G 0 disk #The data disk has been expanded to 200 GiB, but 50 GiB space is not allocated.
+sdb 8:16 0 200G 0 disk #The data disk has been expanded to 200 GiB, but 50-GiB space is not allocated.
├─vgpaas-dockersys 253:0 0 140G 0 lvm /var/lib/containerd
└─vgpaas-kubernetes 253:1 0 10G 0 lvm /mnt/paas/kubernetes/kubelet
- Perform the following operations on the node to add the new disk capacity to the kubelet space:
- Expand the PV capacity so that LVM can identify the new EVS capacity. /dev/sdb specifies the physical volume where kubelet is located.
pvresize /dev/sdb
diff --git a/docs/cce/umn/cce_bestpractice_00222.html b/docs/cce/umn/cce_bestpractice_00222.html
index e7f00e6a4..7eecb6ca7 100644
--- a/docs/cce/umn/cce_bestpractice_00222.html
+++ b/docs/cce/umn/cce_bestpractice_00222.html
@@ -96,7 +96,7 @@
|
Specifies the desired region. Regions are geographic areas that are physically isolated from each other. The networks inside different regions are not connected to each other, so resources cannot be shared across different regions. For lower network latency and faster access to your resources, select the region nearest you.
|
-N/A
+ | -
|
Name
@@ -147,7 +147,7 @@
|
Select Enable for IPv6 CIDR Block. An IPv6 CIDR block will be automatically assigned to the subnet. IPv6 cannot be disabled after the subnet is created. Currently, you are not allowed to specify a custom IPv6 CIDR block.
|
-N/A
+ | -
|
Associated Route Table
@@ -210,7 +210,7 @@
|
Specifies the desired region. Regions are geographic areas that are physically isolated from each other. The networks inside different regions are not connected to each other, so resources cannot be shared across different regions. For lower network latency and faster access to your resources, select the region nearest you.
|
-N/A
+ | -
|
Bandwidth
diff --git a/docs/cce/umn/cce_bestpractice_0310.html b/docs/cce/umn/cce_bestpractice_0310.html
index 8c88cfe56..e39f5fea8 100644
--- a/docs/cce/umn/cce_bestpractice_0310.html
+++ b/docs/cce/umn/cce_bestpractice_0310.html
@@ -66,7 +66,7 @@ aws_secret_access_key = {SK}
|
Specify the OBS bucket configurations, including region, s3ForcePathStyle, s3Url, and more.
- region: the region where the OBS bucket is located.
- Configure this parameter based on the actual region, for example, eu-de.
- - s3ForcePathStyle: If this parameter is set to false, a bucket domain name in the virtual-hosted–style is used. The bucket name is directly embedded in the access domain name, for example, {bucket-name}.obs.{region}.{domain}.com.
- s3Url: API access address of the OBS bucket.
- The value is in the format of http://obs.{region}otc.t-systems.com. It is determined by the region where the OBS bucket is located. For example, if the region is eu-de, the parameter value is http://obs.eu-de.otc.t-systems.com.
+ - s3ForcePathStyle: If this parameter is set to false, a bucket domain name in the virtual-hosted–style is used. The bucket name is directly embedded in the access domain name, for example, {bucket-name}.obs.{region}.{domain}.com.
- s3Url: API access address of the OBS bucket.
- The value is in the format of http://obs.{region}otc.t-systems.com. It is determined by the region where the OBS bucket is located. For example, if the region is eu-de, the parameter value is http://obs.eu-de.otc.t-systems.com.
|
diff --git a/docs/cce/umn/cce_bestpractice_0312.html b/docs/cce/umn/cce_bestpractice_0312.html
index 6bbd80fa3..0806edbb6 100644
--- a/docs/cce/umn/cce_bestpractice_0312.html
+++ b/docs/cce/umn/cce_bestpractice_0312.html
@@ -7,7 +7,7 @@
- Run the following command to modify the workload and replace the image field in the YAML file with the image path:
kubectl edit deploy wordpress
- Check the running status of the workload.
-Updating ServicesAfter the cluster is migrated, the Service of the source cluster may fail to take effect. You can perform the following operations to update the Service. If ingresses are configured in the source cluster, connect the new cluster to ELB again after the migration. For details, see Using kubectl to Create a LoadBalancer Ingress.
+ Updating ServicesAfter the cluster is migrated, the Service of the source cluster may fail to take effect. You can perform the following operations to update the Service. If ingresses are configured in the source cluster, connect the new cluster to ELB again after the migration. For details, see Creating a LoadBalancer Ingress Using kubectl.
- Connect to the cluster using kubectl.
- Edit the YAML file of the corresponding Service to change the Service type and port number.
kubectl edit svc wordpress
To update load balancer resources, connect to ELB again. Add the annotations by following the procedure in Creating a LoadBalancer Service. annotations:
kubernetes.io/elb.class: union # Shared load balancer
diff --git a/docs/cce/umn/cce_bestpractice_0315.html b/docs/cce/umn/cce_bestpractice_0315.html
index 8c555f470..9c9a1ad86 100644
--- a/docs/cce/umn/cce_bestpractice_0315.html
+++ b/docs/cce/umn/cce_bestpractice_0315.html
@@ -8,17 +8,17 @@
|
|---|
| |
|---|
|
|---|
|
|---|
|
|
|---|
|---|
|
|---|
|---|
|
|---|
|---|
|
|---|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
