- What's New
- Function Overview
- Service Overview
- Billing
- Getting Started
- User Guide
- Best Practices
-
Developer Guide
- Overview
- Using Native kubectl (Recommended)
- Namespace and Network
- Pod
- Label
- Deployment
- EIPPool
- EIP
- Pod Resource Monitoring Metric
- Collecting Pod Logs
- Managing Network Access Through Service and Ingress
- Using PersistentVolumeClaim to Apply for Persistent Storage
- ConfigMap and Secret
- Creating a Workload Using Job and Cron Job
- YAML Syntax
-
API Reference
- Before You Start
- Calling APIs
- Getting Started
- Proprietary APIs
-
Kubernetes APIs
- ConfigMap
- Pod
- StorageClass
- Service
-
Deployment
- Querying All Deployments
- Deleting All Deployments in a Namespace
- Querying Deployments in a Namespace
- Creating a Deployment
- Deleting a Deployment
- Querying a Deployment
- Updating a Deployment
- Replacing a Deployment
- Querying the Scaling Operation of a Specified Deployment
- Updating the Scaling Operation of a Specified Deployment
- Replacing the Scaling Operation of a Specified Deployment
- Querying the Status of a Deployment
- Ingress
- OpenAPIv2
- VolcanoJob
- Namespace
- ClusterRole
- Secret
- Endpoint
- ResourceQuota
- CronJob
-
API groups
- Querying API Versions
- Querying All APIs of v1
- Querying an APIGroupList
- Querying APIGroup (/apis/apps)
- Querying APIs of apps/v1
- Querying an APIGroup (/apis/batch)
- Querying an APIGroup (/apis/batch.volcano.sh)
- Querying All APIs of batch.volcano.sh/v1alpha1
- Querying All APIs of batch/v1
- Querying All APIs of batch/v1beta1
- Querying an APIGroup (/apis/crd.yangtse.cni)
- Querying All APIs of crd.yangtse.cni/v1
- Querying an APIGroup (/apis/extensions)
- Querying All APIs of extensions/v1beta1
- Querying an APIGroup (/apis/metrics.k8s.io)
- Querying All APIs of metrics.k8s.io/v1beta1
- Querying an APIGroup (/apis/networking.cci.io)
- Querying All APIs of networking.cci.io/v1beta1
- Querying an APIGroup (/apis/rbac.authorization.k8s.io)
- Querying All APIs of rbac.authorization.k8s.io/v1
- Event
- PersistentVolumeClaim
- RoleBinding
- StatefulSet
- Job
- ReplicaSet
- Data Structure
- Permissions Policies and Supported Actions
- Appendix
- Out-of-Date APIs
- Change History
-
FAQs
- Product Consulting
-
Basic Concept FAQs
- What Is CCI?
- What Are the Differences Between Cloud Container Instance and Cloud Container Engine?
- What Is an Environment Variable?
- What Is a Service?
- What Is Mcore?
- What Are the Relationships Between Images, Containers, and Workloads?
- What Are Kata Containers?
- Can kubectl Be Used to Manage Container Instances?
- What Are Core-Hours in CCI Resource Packages?
- Workload Abnormalities
-
Container Workload FAQs
- Why Service Performance Does Not Meet the Expectation?
- How Do I Set the Quantity of Instances (Pods)?
- How Do I Check My Resource Quotas?
- How Do I Set Probes for a Workload?
- How Do I Configure an Auto Scaling Policy?
- What Do I Do If the Workload Created from the sample Image Fails to Run?
- How Do I View Pods After I Call the API to Delete a Deployment?
- Why an Error Is Reported When a GPU-Related Operation Is Performed on the Container Entered by Using exec?
- Can I Start a Container in Privileged Mode When Running the systemctl Command in a Container in a CCI Cluster?
- Why Does the Intel oneAPI Toolkit Fail to Run VASP Tasks Occasionally?
- Why Are Pods Evicted?
- Why Is the Workload Web-Terminal Not Displayed on the Console?
- Why Are Fees Continuously Deducted After I Delete a Workload?
-
Image Repository FAQs
- Can I Export Public Images?
- How Do I Create a Container Image?
- How Do I Upload Images?
- Does CCI Provide Base Container Images for Download?
- Does CCI Administrator Have the Permission to Upload Image Packages?
- What Permissions Are Required for Uploading Image Packages for CCI?
- What Do I Do If Authentication Is Required During Image Push?
-
Network Management FAQs
- How Do I View the VPC CIDR Block?
- Does CCI Support Load Balancing?
- How Do I Configure the DNS Service on CCI?
- Does CCI Support InfiniBand (IB) Networks?
- How Do I Access a Container from a Public Network?
- How Do I Access a Public Network from a Container?
- What Do I Do If Access to a Workload from a Public Network Fails?
- What Do I Do If Error 504 Is Reported When I Access a Workload?
- What Do I Do If the Connection Timed Out?
- Storage Management FAQs
- Log Collection
- Account
- SDK Reference
- Videos
- General Reference
Copied.
Notice on Fixing Linux Kernel SACK Vulnerabilities
- Pods that are not associated with an ELB or EIP are not affected by these vulnerabilities because they are not exposed to the public network. Therefore, no action is required.
- Deployments that were created after 00:00 on July 11 are not affected by these vulnerabilities. However, you are advised to recreate pods in the Deployments that were created before 00:00 on July 11, during off-peak hours. For details, see Solution.
- After existing job or CronJobs are completed, pods created by the next job or CronJob will not be affected by these vulnerabilities. Therefore, no action is required.
- The CoreDNS add-on is not affected by these vulnerabilities. Therefore, no action is required.
Vulnerability Details
On June 18, 2019, Red Hat released a security notice, stating that the TCP SACK module of the Linux kernel is exposed to three security vulnerabilities (CVE-2019-11477, CVE-2019-11478, and CVE-2019-11479). These vulnerabilities are related to the maximum segment size (MSS) and TCP Selective Acknowledgment (SACK) packets. Remote attackers can exploit these vulnerabilities to trigger a denial of service (DoS), resulting in server unavailability or breakdown.
Reference links:
https://www.suse.com/support/kb/doc/?id=7023928
https://access.redhat.com/security/vulnerabilities/tcpsack
https://www.debian.org/lts/security/2019/dla-1823
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic?
https://lists.centos.org/pipermail/centos-announce/2019-June/023332.html
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
Vulnerability Type |
CVE-ID |
Published |
Fixed |
---|---|---|---|
Input validation flaw |
2019-06-17 |
2019-07-11 |
|
Resource management flaw |
2019-06-17 |
2019-07-11 |
|
Resource management flaw |
2019-06-17 |
2019-07-11 |
Affected Products
Linux kernel version 2.6.29 and later
Solution
During off-peak hours, delete and recreate pods in the Deployments that were created before 00:00 on July 11.
- Log in to the CCI console. In the navigation pane on the left, choose Workloads > Deployments. On the page displayed, click a Deployment name.
- In the Pod List area on the Deployment details page, click Delete in the row where the pod resides. In the dialog box that is displayed, click Yes.
Figure 1 Deleting a podAfter the pod is deleted, the Deployment automatically creates new pods, as shown in Figure 2.
NOTICE:
If there are multiple pods in a Deployment, delete them individually. That is, delete a pod only after the previous pod is successfully re-created. Otherwise, services will be affected.
Appendix: Introduction to TCP SACKs
TCP is a connection oriented protocol. When two parties wish to communicate over a TCP connection, they establish a connection by exchanging certain information such as requesting to initiate (SYN) a connection, initial sequence number, acknowledgment number, maximum segment size (MSS) to use over this connection, and permission to send and process Selective Acknowledgements (SACKs). This connection establishment process is known as 3-way handshake.
TCP sends and receives user data by a unit called segment. A TCP segment consists of TCP Header, Options and user data. Each TCP segment has a Sequence Number (SEQ) and Acknowledgment Number (ACK).
These SEQ & ACK numbers are used to track which segments are successfully received by the receiver. ACK number indicates the next expected segment by the receiver.
Example:
User A sends 1 kilobyte of data through 13 segments of 100 bytes each. There are 13 segments in total because each segment has a TCP header of 20 bytes. On the receiving end, user B receives segments 1, 2, 4, 6, and 8-13. Segments 3, 5, and 7 are lost, and are not received by user B.
By using ACK numbers, user B will indicate that it is expecting segment 3, which user A understands as none of the segments after 2 were received by user B. Then user A will retransmit all the segments from 3 onwards, even though segments 4, 6, and 8–13 were successfully received by user B. User B has no way to indicate this to user A. This leads to an inefficient usage of the network.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot