- 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.
Networking
Overview
This section describes how you can:
- Specify a default DNS server for the pods scheduled to CCI.
- Use a Service to enable communications between the pods in a CCE cluster and the pods in CCI.
- Use a Service to expose pods in CCI.
Constraints
- Networking cannot be enabled for CCE clusters that use a shared VPC.
- If the bursting add-on is to scale the pods to CCI 2.0, dedicated load balancers can be configured for ingresses and Services of the LoadBalancer type. The bursting add-on of a version earlier than 1.5.5 does not support Services of the LoadBalancer type.
- Currently, the network communication depends on sidecar containers and is not supported for init containers. If service containers use preStart or postStart to block the startup of subsequent containers, the network communication will be abnormal.
- Pods deployed across CCE and CCI can only communicate through ClusterIP Services. CCE ClusterIP Services cannot be accessed init containers.
- When you interconnect pods deployed across CCE and CCI with a LoadBalancer Service or ingress:
- Do not specify the health check port. In a CCE cluster, CCI containers and CCE containers use different backend ports registered with ELB. If you specify a health check port, some backend health checks will be abnormal.
- Ensure that the health check method will not impact service access if different clusters use a Service to connect to the listener of the same ELB load balancer.
- Allow traffic from the container port for 100.125.0.0/16 in the node security group when you interconnect pods deployed across CCE and CCI with a shared LoadBalancer Service or ingress.
Specifying a Default DNS Server
Scenario
In some scenarios, you need to specify a default DNS server for the pods scheduled to CCI. The bursting add-on allows you to specify a DNS server address without the need to configure the dnsConfig field for each pod, reducing network O&M costs.
Procedure
- Log in to a CCE cluster node and edit the YAML file.
kubectl edit deploy cceaddon-virtual-kubelet-virtual-kubelet -nkube-system
- Add --cluster-dns=x.x.x.x to the startup parameters and replace x.x.x.x with the DNS server address.
- Save the modification and wait for the virtual-kubelet workload to restart.
- Verify the DNS server address.
Run the exec command to access a container running in CCI and check whether the IP address following nameserver in the first line is the address configured for cluster-dns in the /etc/resolv.conf file.
Table 1 Constraints in different application scenarios Application Scenario
Constraints
There are pods running in CCI before the DNS server address is specified.
- The DNS server address is only available for new pods that are scheduled to CCI.
- To make the DNS server address available for the pods that are running before the modification, these pods need to be redeployed.
There is a limit for cluster-dns
- You can specify a maximum of three name servers in dnsConfig.
- Ensure that the sum of the nameserver value in cluster-dns and the nameservers value in Pod dnsConfig does not exceed 3.
How to Use a Service to Enable Communications Between Pods in a CCE Cluster and Pods in CCI
- Install the bursting add-on and enable Networking.
After the installation is successful, a load balancer is automatically created in your account. You can view the load balancer on the networking console.
- Create a pod in CCI and configure a Service to expose the pod.
- Obtain the access mode of the pod on the CCE cluster console.
-
Create a pod in CCE and configure a Service to expose the pod. For details, see 2.
Do not select the label for pods scheduled to CCI.
- Verify network connectivity.
Create a pod in CCI and select an image that contains the curl command, for example, centos.
Access the container on the CCI console and check whether CCI can access CCE through the Service.
Figure 1 Service for accessing the pod in CCIFigure 2 Service for accessing the pod in CCE - Create a pod in CCE and select an image (for example, CentOS) that allows the curl command. Then, check whether CCE can access CCI through the Service.
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