policy.logs.rotate
diff --git a/docs/cce/umn/cce_10_0020.html b/docs/cce/umn/cce_10_0020.html
index 1dcd64036..ae99deacf 100644
--- a/docs/cce/umn/cce_10_0020.html
+++ b/docs/cce/umn/cce_10_0020.html
@@ -14,6 +14,8 @@
DNS
+Cluster Network Settings
+
Configuring Intra-VPC Access
Accessing the Internet from a Container
diff --git a/docs/cce/umn/cce_10_0025.html b/docs/cce/umn/cce_10_0025.html
index 1c6ce67b5..8efdc0b1f 100644
--- a/docs/cce/umn/cce_10_0025.html
+++ b/docs/cce/umn/cce_10_0025.html
@@ -2,7 +2,7 @@
CCE Operations Supported by CTS
Cloud Trace Service (CTS) records operations on cloud service resources, allowing you to query, audit, and backtrack the resource operation requests initiated from the CCE console or open APIs as well as responses to the requests.
-  To collect the query events (Get and List) listed in the table below, enable read-only event reporting of CCE in CTS. Because query operations occur far more frequently than addition, deletion, or modification operations, enabling this function may generate a large volume of events. Assess the potential impact before enabling it.
+ To collect the query events (Get and List) listed in the table below, enable read-only event reporting of CCE in CTS. Because query operations occur far more frequently than addition, deletion, or modification operations, enabling this function may generate a large number of events. Assess the potential impacts before enabling it.
Table 1 CCE operations supported by CTSOperation
diff --git a/docs/cce/umn/cce_10_0026.html b/docs/cce/umn/cce_10_0026.html
index b8162e570..4cedbe8a1 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, 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
Table 1 Trace filtering parametersParameter
|
@@ -27,14 +27,14 @@
|---|
Resource type
|
Select the type of the resource involved in a trace from the drop-down list.
-For details about the resource types of each cloud service, see section "Supported Services and Operations" in the Cloud Trace Service User Guide.
+For details about the resource types of each cloud service, see section "Supported Services and Operations" in the Cloud Trace Service User Guide.
|
Search By
|
Select one of the following options:
- Resource ID: ID of the cloud resource involved in a trace.
Leave this field empty if the resource has no resource ID or if resource creation failed.
- - Trace name: name of a trace.
For details about the operations that can be audited for each cloud service, see section "Supported Services and Operations" in the Cloud Trace Service User Guide.
+ - Trace name: name of a trace.
For details about the operations that can be audited for each cloud service, see section "Supported Services and Operations" in the Cloud Trace Service User Guide.
- Resource name: name of the cloud resource involved in a trace.
If the cloud resource involved in the trace does not have a resource name or the corresponding API operation does not involve the resource name parameter, leave this field empty.
|
@@ -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 19ae29c09..51cb1b387 100644
--- a/docs/cce/umn/cce_10_0028.html
+++ b/docs/cce/umn/cce_10_0028.html
@@ -2,63 +2,71 @@
Creating a CCE Standard/Turbo Cluster
CCE standard and Turbo clusters provide enterprise-class Kubernetes cluster hosting service that supports full lifecycle management of containerized applications. They offer a highly scalable, high-performance solution for deploying and managing cloud native applications. On the CCE console, you can easily create CCE standard and Turbo clusters. After a cluster is created, CCE hosts the master nodes. You only need to create worker nodes. In this way, you can implement cost-effective O&M and efficient service deployment.
- Before creating a CCE standard or Turbo cluster, you are advised to learn about What Is CCE? Networking Overview, and Planning CIDR Blocks for a Cluster.
+ Before creating a CCE standard or Turbo cluster, you are advised to learn about What Is CCE, Networking Overview, and Planning CIDR Blocks for a Cluster.
Step 1: Configure Basic SettingsBasic settings define the core architecture and underlying resource rules of a cluster, providing a framework for cluster running and resource allocation.
- - Log in to the CCE console. In the upper left corner of the page, click
 and select a region for your cluster. The closer the selected region is to the region where resources are deployed, the lower the network latency and the faster the access.After confirming the region, click Create Cluster. If you use CCE for the first time, you need to create an agency following instructions.
+- Log in to the CCE console. In the upper left corner of the page, click
 and select a region for your cluster. The closer the selected region is to the region where resources are deployed, the lower the network latency and the faster the access.Then click Create Cluster. If you use CCE for the first time, you need to create an agency following instructions.
- Configure the basic settings of the cluster. For details, see Table 1.
-
Table 1 Basic settings of a cluster (applicable to standard and Turbo clusters)Parameter
+Table 1 Basic settings of a cluster (applicable to standard and Turbo clusters)Parameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-Type
+ | Type
|
-Select CCE Standard Cluster or CCE Turbo Cluster as required.
+ | Select CCE Turbo Cluster or CCE Standard Cluster as required.
- CCE standard clusters provide highly reliable and secure containers for commercial use.
- CCE Turbo clusters use the high-performance cloud native network. Such clusters provide cloud native hybrid scheduling, achieving higher resource utilization and wider scenario coverage.
-For details, see cluster types.
+For details, see Comparison Between Cluster Types.
|
-No
+ | No
|
-Cluster Name
+ | Cluster Name
|
-Enter a cluster name. Cluster names under the same account must be unique.
+ | Enter a cluster name. Each cluster name in the same account must be unique.
Enter 4 to 128 characters. Start with a lowercase letter and do not end with a hyphen (-). Only lowercase letters, digits, and hyphens (-) are allowed.
|
-Yes
+ | Yes
|
-Cluster Version
+ | Enterprise Project
|
-Select a Kubernetes version. The latest commercial version is recommended, and it provides you with more stable, reliable features.
+ | This parameter is available only for enterprise users who have enabled enterprise projects.
+After an enterprise project is selected, clusters and their security groups will be created in that project. To manage clusters and other resources like nodes, load balancers, and node security groups, you can use the Enterprise Project Management Service (EPS).
|
-Yes
+ | Yes
|
-Cluster Scale
+ | Cluster Version
|
-Select a cluster scale as required. This parameter controls the maximum number of worker nodes that a cluster can manage.
+ | Select a Kubernetes version. The latest commercial version provides you with more stable, reliable features and is recommended.
|
-Yes
+ | Yes
+ |
+
+Cluster Scale
+ |
+Select a cluster scale as required. This parameter controls the maximum number of worker nodes that a cluster can manage.
+ |
+Yes
The cluster that has been created can only be scaled out. For details, see Changing a Cluster Scale.
|
-Master Nodes
+ | Master Nodes
|
-Select the number of master nodes. The master nodes are automatically hosted by CCE and deployed with Kubernetes cluster management components such as kube-apiserver, kube-controller-manager, and kube-scheduler.
-- 3 Masters: Three master nodes will be created for high cluster availability.
- Single: Only one master node will be created in your cluster.
NOTE: If more than half of the master nodes in a CCE cluster are faulty, the cluster cannot function properly.
+ Select the number of master nodes. The master nodes are automatically hosted by CCE and deployed with Kubernetes cluster management components such as kube-apiserver, kube-controller-manager, and kube-scheduler.
+- 3 (HA): Three master nodes will be created for high cluster availability.
- Single: Only one master node will be created in your cluster.
NOTE: If there are multiple master nodes and more than half of the master nodes in a CCE cluster are faulty, the cluster cannot function properly.
-You can also select AZs for deploying the master nodes of a specific cluster. By default, AZs are allocated automatically for the master nodes. - Automatic: Master nodes are randomly distributed in different AZs for cluster DR. If there are not enough AZs available, CCE will prioritize assigning nodes in AZs with enough resources to ensure cluster creation. However, this may result in AZ-level DR not being guaranteed.
- Custom: Master nodes are deployed in specific AZs.
If there is one master node in a cluster, you can select one AZ for the master node. If there are multiple master nodes in a cluster, you can select multiple AZs for the master nodes. - AZ: Master nodes are deployed in different AZs for cluster DR.
- Host: Master nodes are deployed on different hosts in the same AZ for cluster DR.
- Custom: Master nodes are deployed in the AZs you specified.
+ You can also select AZs for deploying the master nodes of a specific cluster. By default, AZs are allocated automatically for the master nodes. - Automatic: Master nodes are randomly distributed in different AZs for cluster DR. If there are not enough AZs available, CCE will prioritize assigning nodes in AZs with enough resources to ensure cluster creation. However, this may affect AZ-level DR.
- Custom: Master nodes are deployed in specific AZs.
If there is one master node in a cluster, select an AZ for the master node as needed. If there are multiple master nodes in a cluster, you can select multiple AZs. - AZ: Master nodes are deployed in different AZs for cluster DR.
- Host: Master nodes are deployed on different hosts in the same AZ for cluster DR.
- Custom: Master nodes are deployed in the AZs you specified.
|
- No
+ | No
After the cluster is created, the number of master nodes and the AZs where they are deployed cannot be changed.
|
|
@@ -71,45 +79,45 @@
- Cluster network: handles communication between nodes, transmitting pod and Service traffic while ensuring cluster infrastructure connectivity and security.
- Container network: assigns each pod an independent IP address, enabling direct container communication and cross-node communication.
- Service network: establishes a stable access entry, supports load balancing, and optimizes traffic management for Services within a cluster.
Before configuring the network settings, you are advised to learn the concepts and relationships of the three types of networks. For details, see Networking Overview.
-Configuring Network Settings for a CCE Standard Cluster- Configure cluster network settings. For details, see Table 2.
+
Configuring Network Settings for a CCE Standard Cluster- Configure cluster network parameters. For details, see Table 2.
-
Table 2 Cluster network settingsParameter
+Table 2 Cluster network settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-VPC
+ | VPC
|
-Select a VPC for a cluster.
+ | Select a VPC for the cluster.
If no VPC is available, click Create VPC to create one. After the VPC is created, click the refresh icon.
|
-No
+ | No
|
-Default Node Subnet
+ | Default Node Subnet
|
-Select a subnet. Once selected, all nodes in the cluster will automatically use the IP addresses assigned within that subnet. However, during node or node pool creation, the subnet settings can be reconfigured.
+ | Select a subnet. Once selected, all nodes in the cluster will automatically use the IP addresses assigned within that subnet. During node or node pool creation, the subnet settings can be reconfigured.
|
-No
+ | No
|
-Default Node Security Group
+ | Default Node Security Group
|
-Select the security group automatically generated by CCE or select an existing one.
-The default node security group must allow traffic from certain ports to ensure normal communication. Otherwise, the node cannot be created. For details, see Configuring Cluster Security Group Rules.
+ | Select Auto generate. CCE will automatically create a security group for the cluster. You can also select an existing security group.
+The security group must allow traffic over certain ports to ensure normal communication. Otherwise, the nodes cannot be created. For details, see Configuring Cluster Security Group Rules.
|
-Yes
+ | Yes
|
-IPv6
+ | IPv6
|
-After this function is enabled, the cluster supports the IPv4/IPv6 dual-stack, meaning each worker node can have both an IPv4 and IPv6 address. Both IP addresses support private and public network access. Before enabling this function, ensure that Default Node Subnet includes an IPv6 CIDR block.
+ | After this function is enabled, the cluster supports the IPv4/IPv6 dual-stack, meaning each worker node can have both an IPv4 address and an IPv6 address. Both IP addresses support private and public network access. Before enabling this function, ensure that Default Node Subnet includes an IPv6 CIDR block.
- CCE standard clusters (using VPC networks): IPv6 is not supported.
|
-No
+ | No
|
@@ -117,60 +125,60 @@
- Configure container network parameters. For details, see Table 3.
-
Table 3 Container network settingsParameter
+Table 3 Container network settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-Network Model
+ | Network Model
|
-The network model used by the container network in a cluster. - Tunnel network: applies to large clusters (with up to 2000 nodes) and scenarios that do not demand high performance such as web applications and data middle- and back-end services with low access traffic.
- VPC network: applies to small clusters (with 1000 nodes or fewer) and scenarios that demand high performance such as AI and big data computing.
+ The network model used by the container network in a cluster. - Tunnel network: applies to large clusters (with up to 2,000 nodes) and scenarios that do not demand high performance such as web applications and data middle- and back-end services with low access traffic.
- VPC network: applies to small clusters (with 1,000 nodes or fewer) and scenarios that demand high performance such as AI and big data computing.
For more details about their differences, see Overview.
|
- No
+ | No
|
|
-DataPlane V2 (supported by clusters using the VPC networks)
+ | DataPlane V2 (supported by clusters using the VPC networks)
|
-eBPF is used at the kernel layer for Kubernetes network acceleration, enhancing high-performance service communication through ClusterIP Services, precise traffic control via network policies, and intelligent bandwidth management with egress bandwidth. For details, see DataPlane V2 Network Acceleration.
-This function has the restrictions below. For details, see the restrictions in DataPlane V2 Network Acceleration.
-- Restrictions on clusters: This function can be enabled only for clusters of v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, or later that use VPC networks.
- Restrictions on memory: After this function is enabled, CCE will automatically deploy the cilium-agent on every node in a cluster. Each cilium-agent will use 80 MiB of memory, and the memory usage will increase by 10 KiB whenever a new pod is added.
- Restrictions on OSs: After a node is created, it can only use HCE OS 2.0.
+ | eBPF is used at the kernel layer for Kubernetes network acceleration, enhancing high-performance service communication through ClusterIP Services, precise traffic control via network policies, and intelligent bandwidth management with egress bandwidth. For details, see DataPlane V2 Network Acceleration.
+This function has the restrictions below. You can also view the restrictions in DataPlane V2 Network Acceleration.
+- Restrictions on clusters: This function can be enabled only for clusters v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, or later that use VPC networks.
- Restrictions on memory: After this function is enabled, CCE will automatically deploy the cilium-agent on every node in a cluster. Each cilium-agent will use 80 MiB of memory, and the memory usage will increase by 10 KiB whenever a new pod is added.
- Restrictions on OSs: After a node is created, it can only use HCE OS 2.0.
NOTE: CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.
|
-No
+ | No
|
-Network Policies (supported by clusters using the tunnel networks)
+ | Network Policies (supported by clusters using the tunnel networks)
|
-Policy-based network control for a cluster. For details, see Configuring Network Policies to Restrict Pod Access.
+ | Policy-based network control for a cluster. For details, see Configuring Network Policies to Restrict Pod Access.
After this function is enabled, if the CIDR blocks of a customer's service conflict with the on-premises CIDR blocks, the link to a newly added gateway may not be established.
For example, if a cluster uses a Direct Connect connection to access an external address, the external switch does not support ip-option. Enabling network policies in this scenario could result in network access failure.
|
-Yes
+ | Yes
|
-Container CIDR Block
+ | Container CIDR Block
|
-CIDR block used by containers. This parameter determines the maximum number of containers in the cluster. CCE standard clusters support:
-- Manually set: You can customize the container CIDR blocks as needed. For cross-VPC passthrough networking, make sure the container CIDR block does not overlap with the VPC CIDR block to be accessed to prevent conflicts. For details, see Planning CIDR Blocks for a Cluster. The VPC network model allows you to configure multiple CIDR blocks, and container CIDR blocks can be added even after the cluster is created. For details, see Expanding the Container CIDR Block of a Cluster That Uses a VPC Network.
- Auto select: CCE will randomly allocate a non-conflicting CIDR block from the ranges 172.16.0.0/16 to 172.31.0.0/16, or from 10.0.0.0/12, 10.16.0.0/12, 10.32.0.0/12, 10.48.0.0/12, 10.64.0.0/12, 10.80.0.0/12, 10.96.0.0/12, and 10.112.0.0/12. Since the allocated CIDR block cannot be modified after the cluster is created, you are advised to manually configure the CIDR blocks, especially in commercial scenarios.
NOTE: After a cluster using a container tunnel network is created, the container CIDR block cannot be expanded later. To prevent IP address exhaustion, it is advised to set the container CIDR block with a maximum mask length of 19 bits.
+ CIDR block used by containers. This parameter determines the maximum number of containers in the cluster. CCE standard clusters support:
+- Manually set: You can customize the container CIDR blocks as needed. For cross-VPC passthrough networking, make sure the container CIDR block does not overlap with the VPC CIDR block to be accessed to prevent conflicts. For details, see Planning CIDR Blocks for a Cluster. The VPC network model allows you to configure multiple CIDR blocks, and container CIDR blocks can be added even after the cluster is created. For details, see Expanding the Container CIDR Block of a Cluster That Uses a VPC Network.
- Auto select: CCE will randomly allocate a non-conflicting CIDR block from the ranges 172.16.0.0/16 to 172.31.0.0/16, or from 10.0.0.0/12, 10.16.0.0/12, 10.32.0.0/12, 10.48.0.0/12, 10.64.0.0/12, 10.80.0.0/12, 10.96.0.0/12, and 10.112.0.0/12. Since the allocated CIDR block cannot be modified after the cluster is created, you are advised to manually configure the CIDR blocks, especially in commercial scenarios.
NOTE: After a cluster using a container tunnel network is created, the container CIDR block cannot be expanded later. To prevent IP address exhaustion, it is advised to set the container CIDR block with a maximum mask length of 19 bits.
|
- No
+ | No
After a cluster using a VPC network is created, you can add container CIDR blocks to the cluster but cannot modify or delete the existing ones.
|
|
-Pod IP Addresses Reserved for Each Node (supported by clusters using the VPC networks)
+ | Reserved Pod IP Per Node (supported by clusters using the VPC networks)
|
-The number of pod IP addresses that can be allocated on each node (alpha.cce/fixPoolMask). This parameter determines the maximum number of pods that can be created on each node.
-In a container network, each pod is assigned a unique IP address. If the number of pod IP addresses reserved for each node is insufficient, pods cannot be created. For details, see Number of Allocatable Pod IP Addresses on a Node.
+ | 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.
|
-No
+ | No
|
@@ -178,27 +186,27 @@
- Configure Service network parameters. For details, see Table 4.
-
Table 4 Service network settingsParameter
+Table 4 Service network settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-Service CIDR Block
+ | Service CIDR Block
|
-Configure an IP address range for the ClusterIP Services in a cluster. This parameter controls the maximum number of ClusterIP Services in a cluster. ClusterIP Services enable communication between containers in a cluster. The Service CIDR block cannot overlap with the node subnet or container CIDR block.
+ | Configure an IP address range for ClusterIP Services in a cluster. This parameter controls the maximum number of ClusterIP Services in a cluster. ClusterIP Services enable communication between containers in a cluster. The Service CIDR block cannot overlap with the node subnet or container CIDR block.
|
-No
+ | No
|
-Request Forwarding
+ | Request Forwarding
|
-Configure load balancing and route forwarding of Service traffic in a cluster. IPVS and iptables are supported. For details, see Comparing iptables and IPVS.
-- iptables: the traditional kube-proxy mode. It applies to the scenario where the number of Services is small or a large number of short connections are concurrently sent on the client. IPv6 clusters do not support iptables.
- IPVS: allows higher throughput and faster forwarding. It is suitable for large clusters or when there are a large number of Services.
+ | Configure load balancing and route forwarding of Service traffic in a cluster. iptables and IPVS are supported. For details, see Comparing iptables and IPVS.
+- iptables: the traditional kube-proxy mode. It applies to the scenario where the number of Services is small or a large number of short connections are concurrently established with the client. IPv6 clusters do not support iptables.
- IPVS: allows higher throughput and faster forwarding. It is suitable for large clusters or when there are a large number of Services.
|
-No
+ | No
|
@@ -206,45 +214,45 @@
-Configuring Network Settings for a CCE Turbo Cluster- Configure cluster network settings. For details, see Table 5.
+
Configuring Network Settings for a CCE Turbo Cluster- Configure cluster network parameters. For details, see Table 5.
-
Table 5 Cluster network settingsParameter
+Table 5 Cluster network settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-VPC
+ | VPC
|
-Select a VPC for a cluster.
+ | Select a VPC for the cluster.
If no VPC is available, click Create VPC to create one. After the VPC is created, click the refresh icon.
|
-No
+ | No
|
-Default Node Subnet
+ | Default Node Subnet
|
-Select a subnet. Once selected, all nodes in the cluster will automatically use the IP addresses assigned within that subnet. However, during node or node pool creation, the subnet settings can be reconfigured.
+ | Select a subnet. Once selected, all nodes in the cluster will automatically use the IP addresses assigned within that subnet. During node or node pool creation, the subnet settings can be reconfigured.
|
-No
+ | No
|
-Default Node Security Group
+ | Default Node Security Group
|
-Select the security group automatically generated by CCE or select an existing one.
-The default node security group must allow traffic from certain ports to ensure normal communication. Otherwise, the node cannot be created. For details, see Configuring Cluster Security Group Rules.
+ | Select Auto generate. CCE will automatically create a security group for the cluster. You can also select an existing security group.
+The security group must allow traffic over certain ports to ensure normal communication. Otherwise, the nodes cannot be created. For details, see Configuring Cluster Security Group Rules.
|
-Yes
+ | Yes
|
-IPv6
+ | IPv6
|
-After this function is enabled, the cluster supports the IPv4/IPv6 dual-stack, meaning each worker node can have both an IPv4 and IPv6 address. Both IP addresses support private and public network access. Before enabling this function, ensure that Default Node Subnet includes an IPv6 CIDR block.
+ | After this function is enabled, the cluster supports the IPv4/IPv6 dual-stack, meaning each worker node can have both an IPv4 address and an IPv6 address. Both IP addresses support private and public network access. Before enabling this function, ensure that Default Node Subnet includes an IPv6 CIDR block.
- CCE standard clusters (using VPC networks): IPv6 is not supported.
|
-No
+ | No
|
@@ -252,46 +260,46 @@
- Configure container network parameters. For details, see Table 6.
-
Table 6 Container network settingsParameter
+Table 6 Container network settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-Network Model
+ | Network Model
|
-The network model used by the container network in a cluster. Only Cloud Native Network 2.0 is supported.
+ | The network model used by the container network in a cluster. Only Cloud Native Network 2.0 is supported.
For more details about this network model, see Overview.
|
-No
+ | No
|
-DataPlane V2
+ | DataPlane V2
|
-eBPF is used at the kernel layer for Kubernetes network acceleration, enhancing high-performance service communication through ClusterIP Services, precise traffic control via network policies, and intelligent bandwidth management with egress bandwidth. For details, see DataPlane V2 Network Acceleration.
-This function has the restrictions below. For details, see the restrictions in DataPlane V2 Network Acceleration.
+ | eBPF is used at the kernel layer for Kubernetes network acceleration, enhancing high-performance service communication through ClusterIP Services, precise traffic control via network policies, and intelligent bandwidth management with egress bandwidth. For details, see DataPlane V2 Network Acceleration.
+This function has the restrictions below. You can also view the restrictions in DataPlane V2 Network Acceleration.
- Restrictions on clusters: The cluster version must be v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later.
- Restrictions on memory: After this function is enabled, CCE will automatically deploy the cilium-agent on every node in a cluster. Each cilium-agent will use 80 MiB of memory, and the memory usage will increase by 10 KiB whenever a new pod is added.
- Restrictions on OSs: After a node is created, it can only use HCE OS 2.0.
NOTE: CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.
|
-No
+ | No
|
-Pod Subnet
+ | Pod Subnet
|
-Select the subnet to which the pod belongs. If no subnet is available, click Create Subnet to create one. The pod subnet determines the maximum number of containers in a cluster. You can add pod subnets after a cluster is created.
+ | Select the subnet to which the pod belongs. If no subnet is available, click Create Subnet to create one. The pod subnet determines the maximum number of containers in a cluster. You can add pod subnets after a cluster is created.
|
-Yes
+ | Yes
|
-Default Security Group
+ | Default Security Group
|
-Select the security group automatically generated by CCE or select an existing one. This parameter controls inbound and outbound traffic to prevent unauthorized access.
-The default security group of containers must allow access from specified ports to ensure proper communication between containers in the cluster. For details about how to configure security group ports, see How Do I Harden the Automatically Created Security Group Rules for CCE Cluster Nodes?
+ | Select the security group automatically generated by CCE or select an existing one. This parameter controls inbound and outbound traffic to prevent unauthorized access.
+The security group of containers must allow access over specified ports to ensure normal communication between containers in the cluster. For details about how to configure ports in the security group rules, see How Do I Harden the Automatically Created Security Group Rules for CCE Cluster Nodes?
|
-Yes
+ | Yes
|
@@ -299,34 +307,34 @@
- Configure Service network parameters. For details, see Table 7.
-
Table 7 Service network settingsParameter
+Table 7 Service network settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-Service CIDR Block
+ | Service CIDR Block
|
-Configure an IP address range for the ClusterIP Services in a cluster. This parameter controls the maximum number of ClusterIP Services in a cluster. ClusterIP Services enable communication between containers in a cluster. The Service CIDR block cannot overlap with the node subnet or container CIDR block.
+ | Configure an IP address range for ClusterIP Services in a cluster. This parameter controls the maximum number of ClusterIP Services in a cluster. ClusterIP Services enable communication between containers in a cluster. The Service CIDR block cannot overlap with the node subnet or container CIDR block.
|
-No
+ | No
|
-Request Forwarding
+ | Request Forwarding
|
-Configure load balancing and route forwarding of Service traffic in a cluster. IPVS and iptables are supported. For details, see Comparing iptables and IPVS.
-- iptables: the traditional kube-proxy mode. It applies to the scenario where the number of Services is small or a large number of short connections are concurrently sent on the client. IPv6 clusters do not support iptables.
- IPVS: allows higher throughput and faster forwarding. It is suitable for large clusters or when there are a large number of Services.
+ | Configure load balancing and route forwarding of Service traffic in a cluster. iptables and IPVS are supported. For details, see Comparing iptables and IPVS.
+- iptables: the traditional kube-proxy mode. It applies to the scenario where the number of Services is small or a large number of short connections are concurrently established with the client. IPv6 clusters do not support iptables.
- IPVS: allows higher throughput and faster forwarding. It is suitable for large clusters or when there are a large number of Services.
|
-No
+ | No
|
-IPv6 Service CIDR Block
+ | IPv6 Service CIDR Block
|
-Configure IPv6 addresses for Services. This parameter is only available after IPv6 is enabled.
+ | Configure IPv6 addresses for Services. This parameter is only available after IPv6 is enabled.
|
-No
+ | No
|
@@ -334,84 +342,84 @@
-(Optional) Step 3: Configure Advanced SettingsAdvanced settings extend and strengthen previous settings, enhancing security, stability, and compliance within clusters. This is achieved through capabilities like improved authentication, resource management, and security mechanisms.
+ (Optional) Step 3: Configure Advanced SettingsAdvanced settings extend and strengthen previous settings, enhancing security, stability, and compliance within clusters. This is achieved through capabilities like improved authentication, resource management, and security mechanisms.
- Table 8 Advanced settingsParameter
+Table 8 Advanced settingsParameter
|
-Description
+ | Description
|
-Modifiable After Cluster Creation
+ | Modifiable After Cluster Creation
|
|---|
-IAM Authentication
+ | IAM Authentication
|
-CCE clusters support IAM authentication. You can call IAM authenticated APIs to access CCE clusters.
+ | CCE clusters support IAM authentication. You can call IAM authenticated APIs to access CCE clusters.
|
-No
+ | No
|
-Certificate Authentication
+ | Certificate Authentication
|
-Certificate authentication is used for identity authentication and access control. It ensures that only authorized users or services can access specific cluster.
-- Automatically generated: CCE automatically creates and hosts X.509 certificates for your clusters. It automatically maintains and rotates cluster certificates.
- Bring your own: You can add a custom certificate to your cluster and use this certificate for authentication. In this case, you need to upload CA root certificate, client certificate, and client certificate private key.
CAUTION: - Upload a file smaller than 1 MiB. The CA certificate and client certificate can be in .crt or .cer format. The private key of the client certificate can only be uploaded unencrypted.
- The validity period of the client certificate must be longer than five years.
- The uploaded CA root certificate is used by the authentication proxy and for configuring the kube-apiserver aggregation layer. If any of the uploaded certificates is invalid, the cluster cannot be created.
- In clusters of v1.25 and later, Kubernetes no longer supports certificate authentication generated using the SHA1WithRSA or ECDSAWithSHA1 algorithms. You are advised to use the certificates generated using the SHA-256 algorithm for authentication.
+ Certificate authentication is used for identity authentication and access control. It ensures that only authorized users or services can access specific cluster.
+- Automatically generated: CCE automatically creates and hosts X.509 certificates for your clusters. It automatically maintains and rotates cluster certificates.
- Bring your own: You can add a custom certificate to your cluster and use this certificate for authentication. In this case, you need to upload the CA root certificate, client certificate, and client certificate private key.
CAUTION: - Upload a file smaller than 1 MB. The CA certificate and client certificate can be in .crt or .cer format. The private key of the client certificate can only be uploaded unencrypted.
- The validity period of the client certificate must be longer than five years.
- The uploaded CA root certificate is used by the authentication proxy and for configuring the kube-apiserver aggregation layer. If any of the uploaded certificates is invalid, the cluster cannot be created.
- In clusters v1.25 and later, Kubernetes no longer supports certificate authentication generated using the SHA1WithRSA or ECDSAWithSHA1 algorithms. You are advised to use the certificates generated using the SHA-256 algorithm for authentication.
|
- No
+ | No
|
|
-CPU Management
+ | CPU Management
|
-CPU management policies allow precise control over CPU allocation for pods. For details, see CPU Policy.
+ | CPU management policies allow precise control over CPU allocation for pods. For details, see CPU Policy.
- Disabled: The default CPU affinity policy is used. Affinity policies other than the default behavior of the OS scheduler are not provided. While many CPUs remain available in the shared pool, workloads cannot exclusively use any of them.
- Enabled: Workload pods can exclusively use CPUs. If a pod with a QoS class of Guaranteed requests an integer number of CPUs, the containers within the pod are pinned to physical CPUs on the host node. This mode benefits workloads sensitive to CPU cache hit ratio and scheduling latency.
|
-Yes
+ | Yes
|
-Disk Encryption for Master Nodes
+ | Disk Encryption for Master Nodes
|
-After this function is enabled, dynamic and static data on disks can be encrypted, providing strong security protection for your data.
-After encryption, the disk read/write performance deteriorates. This function is available only for clusters of v1.25 or later.
+ | If enabled, dynamic data and static data on disks can be encrypted, providing powerful security protection for your data.
+After encryption, the disk read/write performance deteriorates. This function is available only for clusters v1.25 or later.
|
-No
+ | No
|
-Overload Control
+ | Overload Control
|
-After this function is enabled, concurrent requests will be dynamically controlled based on the resource demands received by master nodes, ensuring stable running of the master nodes and the cluster. For details, see Enabling Overload Control for a Cluster.
+ | After this function is enabled, concurrent requests will be dynamically controlled based on the resource demands received by master nodes, ensuring stable running of the master nodes and the cluster. For details, see Enabling Overload Control for a Cluster.
|
-Yes
+ | Yes
|
-Cluster Deletion Protection
+ | Cluster Deletion Protection
|
-After this function is enabled, you will not be able to delete or unsubscribe from clusters on CCE. This option is a measure to prevent accidental deletion of clusters through the console or APIs. You can modify the function status in Settings after creating it.
+ | A measure taken to prevent accidental deletion of clusters through the console or APIs. After this function is enabled, you will not be able to delete or unsubscribe from clusters on CCE. You can modify the function status in Settings after creating the clusters.
|
-Yes
+ | Yes
|
-Time Zone
+ | Time Zone
|
-The cluster's scheduled tasks and nodes are subject to the chosen time zone.
+ | The cluster's scheduled tasks and nodes are subject to the chosen time zone.
|
-×
+ | No
|
-Resource Tag
+ | Resource Tag
|
-Adding tags to resources allows for customized classification and organization. A maximum of 20 resource tags can be added.
+ | Adding tags to resources allows for custom classification and organization. A maximum of 20 resource tags can be added.
You can create predefined tags on the TMS console. These tags are available to all resources that support tags. You can use these tags to improve the tag creation and resource migration efficiency.
|
-Yes
+ | Yes
|
-Description
+ | Description
|
-Cluster description helps users and administrators quickly understand the basic settings, status, and usage of a cluster. The description can contain a maximum of 200 characters.
+ | Cluster description helps users and administrators quickly understand the basic settings, status, and usage of a cluster. The description can contain a maximum of 200 characters.
|
-Yes
+ | Yes
|
@@ -419,32 +427,32 @@
Step 4: Select Add-onsCCE provides a variety of add-ons to extend cluster functions and enhance the functionality and flexibility of containerized applications. You can select add-ons as required. Some basic add-ons are set as mandatory by default. If non-basic add-ons are not installed during cluster creation, they can still be added later on the Add-ons page after the cluster is created.
- - Click Next: Select Add-on. On the page displayed, select the add-ons to be installed during cluster creation.
- Select basic add-ons to ensure the proper running of the cluster. For details, see Table 9.
+
- Click Next: Select Add-on. On the page displayed, select the add-ons to be installed during cluster creation.
- Select basic add-ons to ensure the cluster can run normally. For details, see Table 9.
-
Table 9 Basic add-onsAdd-on
+Table 9 Basic add-onsAdd-on
|
-Description
+ | Description
|
|---|
-CCE Container Network (Yangtse CNI)
+ | CCE Container Network (Yangtse CNI)
|
-This add-on provides network connectivity, Internet access, and security isolation for pods in a cluster. It is the basic cluster add-on.
+ | This is a basic cluster add-on. It provides network connectivity, public access, and security isolation for pods in your cluster.
|
-CCE Container Storage (Everest)
+ | CCE Container Storage (Everest)
|
-This add-on (CCE Container Storage (Everest)) is installed by default. It is a cloud native container storage system based on CSI and supports cloud storage services such as EVS.
+ | This add-on is installed by default. It is a cloud native container storage system based on CSI and supports cloud storage services such as EVS.
|
-CoreDNS
+ | CoreDNS
|
-This add-on (CoreDNS) is installed by default. It provides DNS resolution for your cluster and can be used to access the in-cloud DNS server.
+ | This add-on is installed by default. It provides DNS resolution for your cluster and can be used to access the in-cloud DNS server.
|
-NodeLocal DNSCache
+ | NodeLocal DNSCache
|
-(Optional) After you select this option, CCE will automatically install NodeLocal DNSCache. NodeLocal DNSCache improves cluster DNS performance by running a DNS cache proxy on cluster nodes.
+ | (Optional) After you select this add-on, CCE will automatically install it. NodeLocal DNSCache improves cluster DNS performance by running a DNS cache proxy on cluster nodes.
|
@@ -459,17 +467,17 @@
Cloud Native Cluster Monitoring
|
-(Optional) After you select this option, CCE will automatically install Cloud Native Cluster Monitoring. Cloud Native Cluster Monitoring collects monitoring metrics for your cluster and reports the metrics to AOM. The agent mode does not support HPA based on custom Prometheus statements. If related functions are required, install this add-on manually after the cluster is created.
+ | (Optional) After you select this add-on, CCE will automatically install it. This add-on collects monitoring metrics for your cluster and reports the metrics to AOM. The agent mode does not support HPA based on custom Prometheus statements. If related functions are required, install this add-on manually after the cluster is created.
|
Cloud Native Log Collection
|
-(Optional) After you select this option, CCE will automatically install Cloud Native Log Collection. Cloud Native Log Collection helps report logs to LTS. After the cluster is created, you are allowed to obtain and manage collection rules on the Logging page of the CCE cluster console.
+ | (Optional) After you select this add-on, CCE will automatically install it. This add-on helps report logs to LTS. After the cluster is created, you are allowed to obtain and manage collection rules on the Logging page of the CCE cluster console.
|
CCE Node Problem Detector
|
-(Optional) After you select this option, CCE will automatically install CCE Node Problem Detector to detect faults and isolate nodes for prompt cluster troubleshooting.
+ | (Optional) After you select this add-on, CCE will automatically install it to detect faults and isolate nodes for prompt cluster troubleshooting.
|
@@ -493,17 +501,17 @@
CCE Container Storage (Everest)
|
-This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.
+ | This add-on is configurable. You can click Modify on the right of the add-on.
|
CoreDNS
|
-This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.
+ | This add-on is configurable. You can click Modify on the right of the add-on.
|
NodeLocal DNSCache
|
-This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.
+ | This add-on is configurable. You can click Modify on the right of the add-on.
|
@@ -518,19 +526,19 @@
Cloud Native Cluster Monitoring
|
-Select an AOM instance for Cloud Native Cluster Monitoring to report metrics. If no AOM instance is available, click Creating Instance to create one.
+ | Select an AOM instance for Cloud Native Cluster Monitoring to report metrics. If no AOM instance is available, click Create Instance to create one.
|
Cloud Native Log Collection
|
-Select the logs to be collected. If enabled, a log group named k8s-log-{clusterId} will be automatically created, and a log stream will be created for each selected log type.
-- Container log: Standard output logs of containers are collected. The corresponding log stream is named in the format of stdout-{Cluster ID}.
- Kubernetes Events: Kubernetes logs are collected. The corresponding log stream is named in the format of event-{Cluster ID}.
- Kubernetes Audit Logs: Audit logs of the master nodes are collected. The log streams are named in the format of audit-{Cluster ID}.
- Control Plane Logs: Logs from critical components such as kube-apiserver, kube-controller-manage, and kube-scheduler that run on the master nodes are collected. The log streams are named in the format of kube-apiserver-{Cluster ID}, kube-controller-manage-{Cluster ID}, and kube-scheduler-{Cluster ID}, respectively.
+ | Select the logs to be collected. If enabled, a log group named k8s-log-{Cluster ID} will be automatically created, and a log stream will be created for each selected log type.
+- Container log: Standard output logs of containers are collected. The corresponding log stream is named in the format of stdout-{Cluster ID}.
- Kubernetes Events: Kubernetes logs are collected. The corresponding log stream is named in the format of event-{Cluster ID}.
- Kubernetes Audit Logs: Audit logs of the master nodes are collected. The log streams are named in the format of audit-{Cluster ID}.
- Control Plane Logs: Logs from critical components such as kube-apiserver, kube-controller-manage, and kube-scheduler that run on the master nodes are collected. The log streams are named in the format of kube-apiserver-{Cluster ID}, kube-controller-manage-{Cluster ID}, and kube-scheduler-{Cluster ID}, respectively.
If log collection is disabled, choose Logging in the navigation pane of the cluster console after the cluster is created and enable this option.
|
CCE Node Problem Detector
|
-This add-on is unconfigurable. After the cluster is created, you can go to Add-ons to modify the settings.
+ | -
|
@@ -539,7 +547,10 @@
-Helpful Links
+ Step 6: Confirm SettingsClick Next: Confirm Settings. The cluster resource list is displayed. Confirm the information and click Submit.
+ It takes about 5 to 10 minutes to create a cluster. You can click Back to Cluster Management to perform other operations on the cluster or click Go to Cluster Events to view the cluster details.
+
+
How the Add-on WorksAn Nginx ingress consists of the ingress object, ingress controller, and Nginx. The ingress controller assembles ingresses into the Nginx configuration file (nginx.conf) and reloads Nginx to make the configuration changes apply. When it detects that the pod in a Service changes, it dynamically changes the upstream server group configuration of Nginx. In this case, the Nginx process does not need to be reloaded. Figure 1 shows how this add-on works.
- An ingress is a group of access rules that forward requests to specified Services based on domain names or URLs. Ingresses are stored in the object storage service etcd and are added, deleted, modified, and queried through APIs.
- The ingress controller monitors the changes of resource objects such as ingresses, Services, endpoints, secrets (mainly TLS certificates and keys), nodes, and ConfigMaps in real time and automatically performs operations on Nginx.
- Nginx implements load balancing and access control at the application layer.
- Figure 1 Working principles of NGINX Ingress Controller
+ Figure 1 Working principles of NGINX Ingress Controller
Precautions- For clusters earlier than v1.23, kubernetes.io/ingress.class: "nginx" must be added to the annotation of the ingress created through the API.
- A dedicated load balancer must be of the network type (TCP/UDP) and support private networks (with a private IP address).
- If the node where NGINX Ingress Controller runs and containers on this node cannot access Nginx ingress, you need to configure anti-affinity for the workload pods and Nginx Ingress Controller. For details, see Configuring Anti-Affinity Between a Workload and Nginx Ingress Controller.
- During the NGINX Ingress Controller pod upgrade, 10s are reserved for deleting the NGINX Ingress Controller at the ELB backend.
- The timeout duration for the graceful exit of the NGINX Ingress Controller is 300s. If the timeout duration is longer than 300s during the upgrade of the NGINX Ingress Controller, persistent connections will be disconnected, and connectivity will be interrupted for a short period of time.
PrerequisitesBefore installing this add-on, you have one available cluster and there is a node running properly. If no cluster is available, create one according to Creating a CCE Standard/Turbo Cluster.
+ PrerequisitesBefore installing this add-on, you have one available cluster with a node running properly. If no cluster is available, create one according to Creating a CCE Standard/Turbo Cluster.
Installing the Add-on- Log in to the CCE console and click the cluster name to access the cluster console.
- In the navigation pane, choose Add-ons. Locate NGINX Ingress Controller on the right and click Install.
- On the Install Add-on page, configure the specifications as needed.
You can adjust the number of add-on pods and resource quotas as required. High availability is not possible with a single pod. If an error occurs on the node where the add-on instance runs, the add-on will fail.
- - Configure the add-on parameters.
- Ingress Class: Enter a controller name. The name of each controller in the same cluster must be unique and cannot be set to cce (which is the unique identifier of the LoadBalancer ingress controller.) When creating an ingress, you can specify the controller name to declare which controller should manage this ingress.
- Add-on Namespace: Select a namespace for the ingress controller.
- Load Balancer: Select a shared or dedicated load balancer. If no load balancer is available, create one. The load balancer has at least two listeners, and ports 80 and 443 are not occupied by listeners.
- Admission Check: Admission control is performed on Ingresses to ensure that the controller can generate valid configurations. Admission verification is performed on the configuration of Nginx Ingresses. If the verification fails, the request will be intercepted. For details about admission verification, see Access Control.
- Admission check slows down the responses to Ingress requests.
- Only add-ons of version 2.4.1 or later support admission verification.
+ - Configure the add-on parameters.
- Ingress Class: Enter a controller name. The name of each controller in the same cluster must be unique and cannot be set to cce (which is the unique identifier of the LoadBalancer ingress controller). When creating an ingress, you can specify the controller name to declare which controller should manage this ingress.
- Add-on Namespace: Select a namespace for the ingress controller.
- Load Balancer: Select a shared or dedicated load balancer. If no load balancer is available, create one. The load balancer has at least two listeners, and ports 80 and 443 are not occupied by listeners.
- Admission Check: Admission control is performed on Ingresses to ensure that the controller can generate valid configurations. Admission verification is performed on the configuration of Nginx Ingresses. If the verification fails, the request will be intercepted. For details about admission verification, see Access Control.
- Admission check slows down the responses to Ingress requests.
- Only add-ons of version 2.4.1 or later support admission verification.
- - Nginx Parameters: You can configure the nginx.conf file, which will affect all managed ingresses. You can select GUI or YAML. GUI is supported by the NGINX Ingress Controller of version 2.2.75, 2.6.26, 3.0.1, or later.
To configure custom parameters supported by the Kubernetes community, choose YAML and find the related parameters in ConfigMaps. For example, you can use the keep-alive-requests parameter to describe how to set the maximum number of requests for keeping active connections to 100.
+ - Nginx Parameters: You can configure the nginx.conf file, which will affect all managed ingresses. You can select GUI or YAML. GUI is supported by the NGINX Ingress Controller of version 2.2.75, 2.6.26, 3.0.1, or later.
To configure custom parameters supported by the Kubernetes community, choose YAML and find the related parameters in ConfigMaps. For example, you can use the keep-alive-requests parameter to describe how to set the maximum number of requests for keeping active connections to 100.
{
"keep-alive-requests": "100"
}
@@ -224,7 +224,7 @@ spec:
app: nginx
spec:
containers:
- - image: nginx:aplpine
+ - image: nginx:alpine
imagePullPolicy: IfNotPresent
name: nginx
imagePullSecrets:
diff --git a/docs/cce/umn/cce_10_0047.html b/docs/cce/umn/cce_10_0047.html
index 59893b49e..ed444825a 100644
--- a/docs/cce/umn/cce_10_0047.html
+++ b/docs/cce/umn/cce_10_0047.html
@@ -159,7 +159,7 @@
Network Configuration
|
-
+ |
|
diff --git a/docs/cce/umn/cce_10_0048.html b/docs/cce/umn/cce_10_0048.html
index 59a5fa6f1..03df56a5c 100644
--- a/docs/cce/umn/cce_10_0048.html
+++ b/docs/cce/umn/cce_10_0048.html
@@ -3,11 +3,11 @@
Creating a StatefulSet
A StatefulSet is an application that needs to retain data or state while running. StatefulSets are ideal for stateful applications, such as databases, cache services, and message queues. Unlike Deployments, StatefulSets have the following features:
- Fixed identifier: Each pod in a StatefulSet has a fixed identifier, which is associated with the pod name. The identifier is typically in the format of <StatefulSet name>-<Ordinal>. For example, in a StatefulSet named web, the pods would have the names like web-0 and web-1. This naming rule enables each pod to maintain its identity and persistent data even after restart or migration.
- Ordered deployment and scaling: Pods in a StatefulSet are created, scaled, or deleted sequentially. For example, pods with higher ordinals are prioritized for scale-out and removed first during scale-in, which is critical to stateful applications that need to be started or stopped in sequence and ideal for scenarios like primary-secondary replication of databases.
- Persistent storage: To ensure data persistence, you can assign stable persistent storage volumes to each StatefulSet pod by using VolumeClaimTemplate. If a pod is scheduled to other nodes, its original data volume remains intact via the PVC, preventing data loss.
- Notes and Constraints- When you delete or scale a StatefulSet, the system does not delete the storage volumes associated with the StatefulSet to ensure data security.
- When you delete a StatefulSet, reduce the number of replicas to 0 before deleting the StatefulSet so that pods in the StatefulSet can be stopped in order.
- When you create a StatefulSet, a headless Service is required for pod access. For details, see Headless Service.
- When a node is unavailable, pods become Unready. In this case, manually delete the pods of the StatefulSet so that the pods can be migrated to a normal node.
+ Constraints- When you delete or scale a StatefulSet, the system does not delete the storage volumes associated with the StatefulSet to ensure data security.
- When you delete a StatefulSet, reduce the number of replicas to 0 before deleting the StatefulSet so that pods in the StatefulSet can be stopped in order.
- When you create a StatefulSet, a headless Service is required for pod access. For details, see Headless Service.
- When a node is unavailable, pods become Unready. In this case, manually delete the pods of the StatefulSet so that the pods can be migrated to a normal node.
- Using the CCE Console- Log in to the CCE console.
- Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click the Create Workload in the upper right corner.
- Configure basic information about the workload.
+ Using the CCE Console- Log in to the CCE console.
- Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click Create Workload in the upper right corner.
- Configure basic information about the workload.
Parameter
|
Description
@@ -170,7 +170,7 @@
|
|---|
Network Configuration
|
-- Pod ingress/egress bandwidth limit: You can set ingress and egress bandwidth limits for pods. For details, see Configuring QoS for a Pod.
- Whether to enable the static IP address: available only for clusters that support this function. After this function is enabled, you can set the interval for reclaiming expired pod IP addresses. For details, see Configuring a Static IP Address for a Pod.
- Whether to enable a specified container network configuration: available only for clusters that support this function. After you enable a specified container network configuration, the workload will be created using the container subnet and security group in the configuration. For details, see Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration.
- Specify the container network configuration name: Only the custom container network configuration whose associated resource type is workload can be selected.
- IPv6 shared bandwidth: available only for clusters that support this function. After this function is enabled, you can configure a shared bandwidth for a pod with IPv6 dual-stack network interfaces. For details, see Configuring Shared Bandwidth for a Pod with IPv6 Dual-Stack Network Interfaces.
+ |
|
diff --git a/docs/cce/umn/cce_10_0054.html b/docs/cce/umn/cce_10_0054.html
index d5125ff5b..9186175c3 100644
--- a/docs/cce/umn/cce_10_0054.html
+++ b/docs/cce/umn/cce_10_0054.html
@@ -83,7 +83,7 @@
This operation cannot be undone.
|
-Worker node
+ | Worker node
|
Modifying the security group of worker nodes in a cluster
NOTE: Naming rule of a worker node's security group: Cluster name-cce-node-{Random ID}
@@ -110,6 +110,13 @@
This operation cannot be undone.
|
|
+Deleting the elastic network interface used by the node
+ |
+The container network on the node is unavailable.
+ |
+This operation cannot be undone.
+ |
+
Reinstalling the OS
|
Node components are deleted, and the node becomes unavailable.
@@ -123,7 +130,7 @@
NOTE: Node running depends on the system kernel version. Do not use the yum update command to update or reinstall the kernel of a node unless necessary. (Reinstalling the operating system kernel using the original image or other images is a risky operation.)
|
-For details, see Resetting a Node.
+ | Reset the node. For details, see Resetting a Node.
|
Changing the IP address of a node
@@ -137,7 +144,7 @@
|
The node may become unavailable, and components may be insecure if security-related configurations are modified.
|
-Restore the parameter settings to the recommended values. For details, see Modifying Node Pool Configurations.
+ | Restore the parameter settings to the recommended values. For details, see Managing Node Pool Configurations.
|
Modifying OS configuration
@@ -295,7 +302,7 @@
Load Balancing
- Table 4 Load balancing (operations on the ELB console)Operation
+Table 4 Load balancingOperation
|
Impact
|
@@ -347,9 +354,9 @@
|---|
Modifying the basic configurations such as the name, access control, timeout, or description of a listener added by CCE
|
-After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE if the listener is deleted.
+ | After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE.
|
-Do not modify the basic configurations of the listener created by CCE. Restore the configurations if they have been modified.
+ | Do not modify the permissions. Restore the permissions if they have been modified.
|
Modifying the backend server group of a listener added by CCE, including adding or deleting backend servers to or from the server group
@@ -371,14 +378,14 @@
|
- Accessing the target Service or ingress will fail.
- After master nodes are restarted due to reasons such as a cluster upgrade, all your modifications will be reset by CCE if the forwarding rules are added using an ingress.
|
-Do not modify the forwarding policy of such a listener. Restore the configurations if they have been modified.
+ | Do not modify the permissions. Restore the permissions if they have been modified.
|
-Changing the certificate for a load balancer managed by CCE
+ | Replacing the certificate of the listener created by CCE on the ELB console or modifying the server certificate created by CCE using a TLS key on the Certificates page of ELB
|
-After master nodes are restarted due to reasons such as a cluster upgrade, all servers in the backend server group will be reset by CCE.
+ | In scenarios where a master node needs to be restarted, such as during a cluster upgrade, the modification will be reset by CCE. As a result, the Service or ingress may become inaccessible.
|
-Use the YAML file of the ingress to automatically manage certificates.
+ | Use the CCE console or YAML to update the certificate associated with the Service or ingress, or update the TLS key resources associated with the Service or ingress.
|
@@ -421,7 +428,7 @@
-Configuring a larger number of collection shards in Cloud Native Cluster Monitoring than the recommended value (one collection shards per 50 nodes)
+ | Configuring a larger number of collection shards in Cloud Native Cluster Monitoring than the recommended value (one collection shard per 50 nodes)
|
Excessive shards may overload the master node's memory, affecting system stability.
|
diff --git a/docs/cce/umn/cce_10_0059.html b/docs/cce/umn/cce_10_0059.html
index 9888db721..685480d76 100644
--- a/docs/cce/umn/cce_10_0059.html
+++ b/docs/cce/umn/cce_10_0059.html
@@ -166,14 +166,14 @@
- CCE DataPlane V2 is released with restrictions. To use this feature, submit a service ticket to CCE.
- Secure containers (such as Kata as the container runtime) are not supported by network policies.
- If you upgrade a CCE standard cluster with a tunnel network to a version that supports egress rules in in-place mode, the rules will not work because the node OS is not upgraded. In this case, reset the node.
- When a network policy is enabled for a cluster with a tunnel network, a pod's source IP address is embedded in the optional field of packets it sends to any Service CIDR block. This enables the configuration of network policy rules on the destination pod, taking into account the source IP address of the pod.
-Using Ingress Rules Through YAML- Scenario 1: Controlled by a preset network policy, a pod can only be accessed by pods with specific labels.
Figure 1 podSelector
+Using Ingress Rules Through YAML
- - Scenario 2: Controlled by a preset network policy, a pod can only be accessed by pods in a specific namespace.
Figure 2 namespaceSelector
+
Using Egress Rules Through YAML The clusters of v1.23 or later using a tunnel network support egress rules. Only nodes running EulerOS 2.9 or HCE OS 2.0 are supported.
- Egress rules are only available for CCE Turbo clusters or other CCE clusters using a VPC network. The cluster version must be v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0 or later, and DataPlane V2 must be enabled. Additionally, nodes in these clusters must run HCE OS 2.0.
+ Using Egress Rules Through YAML Clusters of v1.23 or later that use a tunnel network support egress rules. The node OS can only be EulerOS 2.9 or HCE OS 2.0.
+ Egress rules are only available in CCE Turbo clusters or other CCE clusters using VPC networks. The cluster version must be v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later, and DataPlane V2 must be enabled. Additionally, nodes in these clusters must run HCE OS 2.0.
- - Scenario 1: Controlled by a preset network policy, pods can only access specific addresses.
Figure 3 IPBlock
+
- Creating a Network Policy on the Console- Log in to the CCE console and click the cluster name to access the cluster console.
- Choose Policies in the navigation pane, click the Network Policies tab, and click Create Network Policy in the upper right corner.
- Policy Name: Specify a network policy name.
- Namespace: Select a namespace in which the network policy is applied.
- Selector: Enter a label, select the pod to be associated, and click Add. You can also click Reference Workload Label to use the label of an existing workload.
- Inbound Rule: Click
 to add an inbound rule. For details about parameter settings, see Table 1.
-
+Creating a Network Policy on the Console- Log in to the CCE console and click the cluster name to access the cluster console.
- Choose Policies in the navigation pane, click the Network Policies tab, and click Create Network Policy in the upper right corner.
- Policy Name: Specify a network policy name.
- Namespace: Select a namespace in which the network policy is applied.
- Selector: Enter a label, select the pod to be associated, and click Add. You can also click Reference Workload Label to use the label of an existing workload.
- Inbound Rule: Click
 to add an inbound rule. For details about parameter settings, see Table 1.
+
Table 1 Adding an inbound ruleParameter
|
@@ -315,8 +342,8 @@ spec:
|---|
- - Outbound Rule: Click
 to add an outbound rule. For details about parameter settings, see Table 2.
-
+ - Outbound Rule: Click
 to add an outbound rule. For details about parameter settings, see Table 2.
+
Table 2 Adding an outbound ruleParameter
|
diff --git a/docs/cce/umn/cce_10_0064.html b/docs/cce/umn/cce_10_0064.html
index e5745f530..69556ecad 100644
--- a/docs/cce/umn/cce_10_0064.html
+++ b/docs/cce/umn/cce_10_0064.html
@@ -16,6 +16,8 @@
- Container Storage Add-ons
+- Add-on Upgrade Checks
+
diff --git a/docs/cce/umn/cce_10_0066.html b/docs/cce/umn/cce_10_0066.html
index 957f991cb..71f75c77b 100644
--- a/docs/cce/umn/cce_10_0066.html
+++ b/docs/cce/umn/cce_10_0066.html
@@ -320,10 +320,10 @@
Counter
|
-Invoking of different functions
+ | Invocation of different functions
|
action: indicates different functions. For details, see Table 6.
-result: indicates that the invoking is successful or fails.
+result: indicates that the invocation is successful or fails.
|
everest_action_result_total{action="create_snapshot:disk.csi.everest.io",result="success"} 2
|
@@ -332,7 +332,7 @@
Histogram
|
-Number of times that different functions are executed at different time
+ | Number of times that different functions are executed at different times
|
function: indicates different functions. For details, see Table 6.
|
@@ -343,7 +343,7 @@
Histogram
|
-Total invoking time of different functions
+ | Total invocation time of different functions
|
function: indicates different functions. For details, see Table 6.
|
@@ -354,7 +354,7 @@
Histogram
|
-Number of invoking times of different functions
+ | Number of invocation times of different functions
|
function: indicates different functions. For details, see Table 6.
|
@@ -595,7 +595,7 @@
v1.15
v1.17
|
-- Supported security hardening.
- Supported third-party OBS storage.
- Switched to the EVS query API with better performance.
- Disks can be created from snapshots using clone by default.
- Optimized and enhanced disk status detection and log output for attaching and detaching operations.
- Improved the reliability of determining authentication expiration.
+ | - Supported security hardening.
- Supported third-party OBS storage.
- Switched to the EVS query API with better performance.
- Disks can be created from snapshots using cloning by default.
- Optimized and enhanced disk status detection and log output for attaching and detaching operations.
- Improved the reliability of determining authentication expiration.
|
|---|
diff --git a/docs/cce/umn/cce_10_0068.html b/docs/cce/umn/cce_10_0068.html
index 7ee927308..c79c24026 100644
--- a/docs/cce/umn/cce_10_0068.html
+++ b/docs/cce/umn/cce_10_0068.html
@@ -4,6 +4,8 @@
+- Kubernetes 1.33 Release Notes
+
- Kubernetes 1.32 Release Notes
- Kubernetes 1.31 Release Notes
diff --git a/docs/cce/umn/cce_10_0081.html b/docs/cce/umn/cce_10_0081.html
index 9453d83da..edf87118d 100644
--- a/docs/cce/umn/cce_10_0081.html
+++ b/docs/cce/umn/cce_10_0081.html
@@ -1,13 +1,13 @@
Node Pool Overview
-IntroductionCCE introduces node pools to help you better manage nodes in Kubernetes clusters. A node pool contains one node or a group of nodes with identical configuration in a cluster.
- You can create custom node pools on the CCE console. With node pools, you can quickly create, manage, and destroy nodes without affecting the cluster. All nodes in a custom node pool have identical parameters and node type. You cannot configure a single node in a node pool; any configuration changes affect all nodes in the node pool.
+ IntroductionCCE introduces node pools to help you better manage nodes in Kubernetes clusters. A node pool contains one node or a group of nodes with identical configurations in a cluster.
+ You can create custom node pools on the CCE console. With node pools, you can quickly create, manage, and destroy nodes without affecting the cluster. All nodes in a custom node pool share the same type and configurations. You cannot configure a single node in a node pool. Any change applies to every node in the node pool.
You can also use node pools for auto scaling.
- When a pod in a cluster cannot be scheduled due to insufficient resources, scale-out can be automatically triggered.
- When there is an idle node or a monitoring metric threshold is met, scale-in can be automatically triggered.
This section describes how node pools work in CCE and how to create and manage node pools.
- Node Pool ArchitectureGenerally, all nodes in a node pool have the following same attributes:
+ Node Pool ArchitectureAll nodes in a pool typically share:
- Node OS
- Node login mode
- Node container runtime
- Startup parameters of Kubernetes components on a node
- Custom startup script of a node
- Kubernetes labels and taints
CCE provides the following extended attributes for node pools:
- Node pool OS
- Maximum number of pods on each node in a node pool
@@ -118,9 +118,31 @@
-Deploying a Workload in a Specified Node PoolWhen configuring a workload, you can set the workload affinity and node affinity on the Scheduling tab to forcibly deploy the workload to a specific node pool. This way, the workload runs only on nodes in that node pool. To better control where the workload is to be scheduled, you can use affinity or anti-affinity policies between workloads and nodes described in Configuring Node Affinity Scheduling (nodeAffinity).
- For example, you can use container's resource request as a nodeSelector so that workloads will run only on the nodes that meet the resource request.
- If the workload definition file defines a container that requires four CPUs, the scheduler will not choose the nodes with two CPUs to run workloads.
+ Deploying a Workload in a Specified Node PoolAll nodes within a node pool carry the cce.cloud.com/cce-nodepool label. To ensure that a workload is scheduled onto nodes from a specific node pool, you can use the nodeSelector field in the workload settings. An example is as follows:
+ apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: nginx
+spec:
+ replicas: 3
+ selector:
+ matchLabels:
+ app: nginx
+ template:
+ metadata:
+ labels:
+ app: nginx
+ spec:
+ nodeSelector:
+ cce.cloud.com/cce-nodepool: "nodepool_name" # The label value is the node pool name.
+ containers:
+ - image: nginx:latest
+ imagePullPolicy: IfNotPresent
+ name: nginx
+ imagePullSecrets:
+ - name: default-secret
+ For more complex scheduling, you can define custom affinity rules, such as hard constraints, where scheduling occurs only if all specified conditions are met, and soft constraints, where scheduling may proceed even if some conditions are not met. For details, see Configuring Node Affinity Scheduling (nodeAffinity).
+ Additionally, you can specify resource requests for containers to ensure workloads are scheduled only on nodes that meet the required resource criteria. For details, see Resource Management for Pods and Containers. For example, if a workload pod requests four CPU cores, it will not be scheduled on a node that offers only two.
Helpful LinksYou can log in to the CCE console and refer to the following sections to perform operations on node pools:
diff --git a/docs/cce/umn/cce_10_0094.html b/docs/cce/umn/cce_10_0094.html
index 9424cba94..e4ae2f019 100644
--- a/docs/cce/umn/cce_10_0094.html
+++ b/docs/cce/umn/cce_10_0094.html
@@ -3,7 +3,7 @@
Ingress Overview
Why We Need Ingresses?A Service is generally used to forward access requests based on TCP and UDP and provide layer-4 load balancing for clusters. However, in actual scenarios, if there is a large number of HTTP/HTTPS access requests on the application layer, the Service cannot meet the forwarding requirements. Therefore, the Kubernetes cluster provides an HTTP-based access mode, ingress.
An ingress is an independent resource in the Kubernetes cluster and defines rules for forwarding external access traffic. As shown in Figure 1, you can customize forwarding rules based on domain names and URLs to implement fine-grained distribution of access traffic.
- Figure 1 Ingress diagram
+ Figure 1 Ingress diagram
Ingress OverviewKubernetes uses ingress resources to define how incoming traffic should be handled, while the Ingress Controller is responsible for processing the actual traffic.
- Ingress object: a set of access rules that forward requests to specified Services based on domain names or paths. It can be added, deleted, modified, and queried by calling APIs.
- Ingress Controller: an executor for forwarding requests. It monitors the changes of resource objects such as ingresses, Services, endpoints, secrets (mainly TLS certificates and keys), nodes, and ConfigMaps in real time, parses rules defined by ingresses, and forwards requests to the target backend Services.
The way of implementing Ingress Controllers varies depending on their vendors. CCE supports LoadBalancer Ingress Controllers and NGINX Ingress Controllers. - LoadBalancer Ingress Controllers are deployed on master nodes and forward traffic based on the ELB. All policy configurations and forwarding behaviors are managed on the ELB.
- NGINX Ingress Controllers are deployed in clusters using charts and images maintained by the Kubernetes community. They provide external access through NodePort and forward external traffic to other services in the cluster through Nginx. All traffic forwarding behaviors and forwarding objects are within the cluster.
@@ -83,19 +83,19 @@
LoadBalancer Ingress Controllers are deployed on master nodes and bound to load balancers in the cluster's VPC. You can configure different domain names, ports, and forwarding policies for the same load balancer (with the same IP address). The working rules of LoadBalancer Ingress Controllers are as follows:
- A user creates an ingress and configures a traffic access rule in the ingress, including the load balancer, access path, SSL, and backend Service port.
- When Ingress Controller detects that the ingress changes, it reconfigures the listener and backend server route on the ELB according to the traffic access rule.
- When a user attempts to access a workload, the ELB forwards the traffic to the target workload according to the configured forwarding rule.
CCE Standard ClustersFigure 2 Working flow of a LoadBalancer ingress in a CCE standard cluster
+ CCE Standard ClustersFigure 2 Working flow of a LoadBalancer ingress in a CCE standard cluster
- CCE Turbo Clusters Where a Shared Load Balancer Is UsedFigure 3 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a shared load balancer is used
+ CCE Turbo Clusters Where a Shared Load Balancer Is UsedFigure 3 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a shared load balancer is used
CCE Turbo Clusters Where a Dedicated Load Balancer Is UsedWhen a CCE Turbo cluster is used, pod IP addresses are directly allocated from the VPC. Dedicated load balancers enable passthrough networking to pods. When creating an ingress for external cluster access, you can use ELB to access a ClusterIP Service and use pods as the backend server of the ELB listener. In this way, external traffic can directly access the pods in the cluster without being forwarded by node ports.
- Figure 4 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a dedicated load balancer is used
+ Figure 4 Working flow of a LoadBalancer ingress in a CCE Turbo cluster where a dedicated load balancer is used
Working Rules of NGINX Ingress ControllerNginx Ingress uses ELB as the traffic ingress. The NGINX Ingress Controller add-on is deployed in a cluster to balance traffic and control access.
NGINX Ingress Controller uses the charts and images provided by the open-source community, and issues may occur during usage. CCE periodically synchronizes the community version to fix known vulnerabilities. Check whether your service requirements can be met.
NGINX Ingress Controller is deployed on worker nodes through pods, which will result in O&M costs and Nginx component running overheads. Figure 5 shows the working rules of NGINX Ingress Controller.
- After you update ingress resources, NGINX Ingress Controller writes a forwarding rule defined in the ingress resources into the nginx.conf configuration file of Nginx.
- The built-in Nginx component reloads the updated configuration file to modify and update the Nginx forwarding rule.
- When traffic accesses a cluster, the traffic is first forwarded by the created load balancer to the Nginx component in the cluster. Then, the Nginx component forwards the traffic to each workload based on the forwarding rule.
- Figure 5 Working rules of NGINX Ingress Controller
+ Figure 5 Working rules of NGINX Ingress Controller
Services Supported by LoadBalancer Ingresses
Table 2 Services supported by LoadBalancer ingressesCluster Type
diff --git a/docs/cce/umn/cce_10_0105.html b/docs/cce/umn/cce_10_0105.html
index 8620f2b72..ede63690c 100644
--- a/docs/cce/umn/cce_10_0105.html
+++ b/docs/cce/umn/cce_10_0105.html
@@ -1,7 +1,7 @@
Configuring the Container Lifecycle
-Container lifecycle hooks are core mechanisms provided by Kubernetes that enable you to insert custom logic at key phases throughout the container lifecycle. These hooks provide refined process controls over containerized applications, enabling applications to better adapt to the dynamic characteristics of the cloud native environment. CCE provides the following container lifecycle hooks. For more information, see Container Lifecycle Hooks.
+ Container lifecycle hooks are core mechanisms provided by Kubernetes. They enable you to insert custom logic at key phases throughout the container lifecycle. These hooks provide refined process controls over containerized applications, enabling applications to better adapt to the dynamic characteristics of the cloud native environment. CCE provides the following container lifecycle hooks. For more information, see Container Lifecycle Hooks.
- Startup Command: the command executed when a container starts. It is used to define the main process of a container. The main process is the default entry after the container starts, and its status determines the container lifecycle. This kind of hook is applicable to initialization scenarios where the application entry, environment variables, mount points, or port mapping needs to be specified.
- PostStart Hook: used to execute initialization tasks, such as service registration and dynamic configuration generation, immediately after the main process of a container starts. Such a hook is asynchronously triggered by kubelet and runs in parallel with the main process, preventing the container startup process from being blocked and accelerating the container readiness. This kind of hook is applicable to the scenario where the environment needs to be configured or the initialization logic needs to be executed immediately after the application process starts.
- PreStop Hook: used to execute predefined cleanup logic before a container is terminated. When a pod is deleted or updated, kubelet triggers this hook to perform operations (such as deregistering services and refreshing status), and then sends the SIGTERM signal to the main process of a container for the application to shut down gracefully. This kind of hook is applicable to the scenario where safe shutdown is required to avoid data loss or there are service exceptions.
Startup CommandA startup command is executed when a container starts. It is used to define the main process of a container. The main process status determines the container lifecycle. If the command fails to be executed and no restart policy is configured, the container will be terminated.
By default, the default command is executed during image start. To run a specific command or rewrite the default image setting, you must perform specific operations. By default, the container executes the startup command preset in the image. Docker images contain a set of metadata fields for defining the startup behavior, including ENTRYPOINT and CMD. If the commands and arguments (specified by Command and Args) are not configured in the container specifications, the default values during image build are used.
diff --git a/docs/cce/umn/cce_10_0107.html b/docs/cce/umn/cce_10_0107.html
index 7d99378d2..85f32ae58 100644
--- a/docs/cce/umn/cce_10_0107.html
+++ b/docs/cce/umn/cce_10_0107.html
@@ -1,22 +1,22 @@
Accessing a Cluster Using kubectl
- kubectl is a command-line tool provided by Kubernetes, enabling you to manage cluster resources, view cluster status, deploy applications, and debug issues through the CLI. To access a CCE cluster using kubectl, you can use either of the following methods: - Intranet access: Clients access the cluster's API server via an intranet IP address, keeping data traffic internal and enhancing security.
- Internet access: The cluster's API server exposes a public API, allowing clients to access the Kubernetes cluster over the Internet. When using Internet access, you can choose whether to enable two-way domain name trust.
- If two-way domain name trust is disabled, kubectl and the API server use one-way certificate authentication, which is less secure. In this mode, only kubectl verifies the API server's certificate, while the API server does not verify kubectl's certificate.
- If two-way domain name trust is enabled, kubectl and the API server use mutual certificate authentication, which is more secure. In this mode, kubectl verifies the API server's certificate, and the API server verifies kubectl's certificate (specified in the client-certificate-data field in the kubeconfig file). For more details, see Two-Way Domain Name Trust.
+kubectl is a command-line tool provided by Kubernetes, enabling you to manage cluster resources, view cluster status, deploy applications, and debug issues through the CLI. To access a CCE cluster using kubectl, you can use either of the following methods: - Private access: Clients access the cluster's API server via an intranet IP address, keeping data traffic internal and enhancing security.
- Public access: The cluster's API server exposes a public API, allowing clients to access the Kubernetes cluster over the Internet. When using the Internet for access, you can choose whether to enable
|
|---|
|
|---|
|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
