Help Center/ Cloud Container Instance/ User Guide/ Bursting to CCI/ CCE Cloud Bursting Engine for CCI/ Networking
Updated on 2024-10-29 GMT+08:00
View PDF
Share

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

  1. Log in to a CCE cluster node and edit the YAML file. 
    kubectl edit deploy cceaddon-virtual-kubelet-virtual-kubelet -nkube-system
  1. Add --cluster-dns=x.x.x.x to the startup parameters and replace x.x.x.x with the DNS server address.
  2. Save the modification and wait for the virtual-kubelet workload to restart.

  3. 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

  1. 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.

  2. Create a pod in CCI and configure a Service to expose the pod.
    • To facilitate verification, select the Nginx image that uses port 80.
    • When you create a Service, use the load balancer that is automatically created to avoid conflicts with the load balancer created by the bursting add-on.

  3. Obtain the access mode of the pod on the CCE cluster console.

  4. 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.

  5. 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 CCI
    Figure 2 Service for accessing the pod in CCE
  6. 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.