- Product Overview
- Purchase Guide
- Quick Start
- Operation Guide
- Fault Action Library
- Compute
- JVM Process CPU at Full Load
- Cross-AZ Experiment in CVM
- CVM DNS Unavailability Experiment
- CVM Domain Name Parsing Tampering Experiment
- CVM System Time Skew
- CVM Disk IO Hang Fault Experiment
- CVM Memory OOM and Disk IO Load
- Experiments on CVM Intra-host Network Disorder
- CVM Kernel Faults
- Experiments on CVM Intra-host Network Latency
- High Utilization of CVM Resources (CPU, Memory, and Disk)
- Experiments on CVM Intra-host Network Corruption
- Experiments on CVM Intra-host Network Duplication
- Experiments on CVM Intra-host Network Occupation
- CVM Network Interruption
- CVM Ping Unreachable
- Cloud API Ban in CVM
- Database
- Primary-secondary Switch in TencentDB for PostgreSQL
- MySQL Instance Overall Unavailable
- Primary-secondary Switch in MySQL
- Setting Maximum Number of Connections in MySQL
- Primary Node Fault Experiment on TencentDB for MySQL
- TencentDB for MySQL Read-only Instance Group Unavailable
- Primary-secondary Switch in TDSQL for MySQM
- Primary-secondary Switch in MariaDB
- Primary-secondary Switch in TDSQL-C
- Practice of TencentDB for Redis Proxy Node Faults
- TencentDB for Redis Primary Node Fault
- Primary-secondary Nodes in TencentDB for Redis Instance Unavailable
- Simulating Primary-secondary Switch in Redis
- Simulating MongoDB Storage Node Fault
- Simulating Self-Built MySQL Crash Through Network Blocking
- Restarting TencentDB for MySQL
- Primary-secondary Switch in SQL Server
- Network
- Container
- Simulating Container Resource Network Faults
- Experiment on Container Resource Pod Operation Faults
- Experiment on Container Resource Node Faults
- Experiment on Container Resource Application Process Faults
- Standard Cluster and Serverless Cluster Super Node Faults
- Serverless Pod Fault Experiment Case
- Cluster Node Resource (CPU, Memory, Disk) Stress Test Faults
- Serverless Pod Virtual Node Shutdown Faults
- Simulating Serverless Cluster Pod Network Faults
- High Cluster Pod Resource (CPU, Memory, and Disk) Utilization Rate
- Cluster Pod TencentCloud API Ban
- Big Data
- Cloud Load Balancer
- Message Queue
- Direct Connect
- Custom Actions
- Cloud Streaming Services (CSS)
- Compute
- Permission Management Guide
- API Documentation
- FAQs
- Related Protocol
- Contact Us
- Product Overview
- Purchase Guide
- Quick Start
- Operation Guide
- Fault Action Library
- Compute
- JVM Process CPU at Full Load
- Cross-AZ Experiment in CVM
- CVM DNS Unavailability Experiment
- CVM Domain Name Parsing Tampering Experiment
- CVM System Time Skew
- CVM Disk IO Hang Fault Experiment
- CVM Memory OOM and Disk IO Load
- Experiments on CVM Intra-host Network Disorder
- CVM Kernel Faults
- Experiments on CVM Intra-host Network Latency
- High Utilization of CVM Resources (CPU, Memory, and Disk)
- Experiments on CVM Intra-host Network Corruption
- Experiments on CVM Intra-host Network Duplication
- Experiments on CVM Intra-host Network Occupation
- CVM Network Interruption
- CVM Ping Unreachable
- Cloud API Ban in CVM
- Database
- Primary-secondary Switch in TencentDB for PostgreSQL
- MySQL Instance Overall Unavailable
- Primary-secondary Switch in MySQL
- Setting Maximum Number of Connections in MySQL
- Primary Node Fault Experiment on TencentDB for MySQL
- TencentDB for MySQL Read-only Instance Group Unavailable
- Primary-secondary Switch in TDSQL for MySQM
- Primary-secondary Switch in MariaDB
- Primary-secondary Switch in TDSQL-C
- Practice of TencentDB for Redis Proxy Node Faults
- TencentDB for Redis Primary Node Fault
- Primary-secondary Nodes in TencentDB for Redis Instance Unavailable
- Simulating Primary-secondary Switch in Redis
- Simulating MongoDB Storage Node Fault
- Simulating Self-Built MySQL Crash Through Network Blocking
- Restarting TencentDB for MySQL
- Primary-secondary Switch in SQL Server
- Network
- Container
- Simulating Container Resource Network Faults
- Experiment on Container Resource Pod Operation Faults
- Experiment on Container Resource Node Faults
- Experiment on Container Resource Application Process Faults
- Standard Cluster and Serverless Cluster Super Node Faults
- Serverless Pod Fault Experiment Case
- Cluster Node Resource (CPU, Memory, Disk) Stress Test Faults
- Serverless Pod Virtual Node Shutdown Faults
- Simulating Serverless Cluster Pod Network Faults
- High Cluster Pod Resource (CPU, Memory, and Disk) Utilization Rate
- Cluster Pod TencentCloud API Ban
- Big Data
- Cloud Load Balancer
- Message Queue
- Direct Connect
- Custom Actions
- Cloud Streaming Services (CSS)
- Compute
- Permission Management Guide
- API Documentation
- FAQs
- Related Protocol
- Contact Us
Simulating Serverless Cluster Pod Network Faults
Last updated: 2024-09-26 15:47:38
Background
The CFG offers simulations of five types of network faults for Serverless clusters: network disorder, network duplication, network package loss, network delay, and network DNS anomalies. In a Kubernetes cluster, the stability of network performance is crucial for service response speed and user experience, as Pod lifecycles are closely linked to requests. Simulating these network faults helps you better understand your service's performance under different network conditions, allowing you to optimize your application and enhance its fault tolerance.
Experiment Execution
Experiment Preparation
Purchase Serverless cluster container instances and deploy test services.
Enter Agent Management page and install the agents.
Experiment Steps
Step 1: Create an Experiment
1. Log in to Tencent Smart Advisor > Chaotic Fault Generator, enter the Experiment Management page, click Create a New Experiment.
2. Click Skip and create a blank experiment, and fill in the experiment details.
Step 2: Add Experiment Instances and Actions
Adding Node Type Fault for Regular Node in Standard Cluster
1. In the experiment object configuration step, select Container — Serverless Cluster Pod.
2. Select Add Instance, and select the required Cluster ID and Namespace, which will automatically fetch all Pods in that namespace.
3. Add experiment actions. Select network fault actions under Network Resources.
Network disorder: Simulates scenarios where network data packages arrive at the destination in an order different from the sending order.
Network duplication: Simulates scenarios where network data packages are repeatedly sent during transmission.
Network packet loss: Simulates scenarios where network data packages are lost during transmission.
Network latency: Simulates scenarios where network data packages are delayed in reaching the destination.
DNS tampering: Simulates scenarios with DNS parsing anomalies.
4. Configuring Fault Action Parameters
Network Card: The network interface name must exist in the selected instances; otherwise, fault injection may fail. Use a semicolon (;) to separate multiple network interfaces.
Whitelist Port: Ports that are not affected. Use a semicolon (;) to separate multiple ports.
Local Port: Packages sent from the local machine on specified ports will be affected. Use a semicolon (;) to separate multiple ports.
Remote Port: Packages sent to specified ports will be affected. Use a semicolon (;) to separate multiple ports.
Remote IP: Packages sent to specified IPs will be affected. Use a semicolon (;) to separate multiple IPs.
5. After action parameter configuration, click Next. Configure guardrail policy and monitoring metrics considering actual situations, and click Submit to complete experiment creation.
Step 3: Execute the Experiment
Click Execute Experiment. Since network actions are high-risk, authentication must be completed before executing the action.
Yes
No
Was this page helpful?