Catalog

1. Schedule Pod to Virtual Node
2. Configure CPU and Memory resources
3. Image Pull
4. Storage
5. Network
6. Bind EIP
7. Troubleshooting
8. List of supported annotations
9. BCI Limit

Start Pod on Virtual Node

When there is a normal virtual node in the CCE cluster, the Pod can be scheduled to the virtual node.

The Pod that is scheduled to the virtual node will be started as a BCI instance and does not occupy physical resources in the cluster.

Schedule Pod to virtual node

On the virtual node list page, click the Operation-How to use button.

The pop-up window shows a fragment of a PodSpec yaml file. Configure the nodeSelector and tolerations of the Pod according to this fragment, and schedule the corresponding Pod to the virtual point.

The example is as follows, assuming the virtual node name is bci-virtual-kubelet-0:

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  labels: 
    run: nginx 
  name: nginx 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: nginx 
  template: 
    metadata: 
      labels: 
        run: nginx 
    spec: 
      containers: 
      - image: nginx 
        name: nginx 
    nodeSelector: 
      type: virtual-kubelet 
      kubernetes.io/hostname: bci-virtual-kubelet-0 
    tolertions: 
    - key: virtual-kubelet.io/provider 
      operator: Equal 
      value: baidu 
      effect: NoSchedule 

If there are multiple virtual nodes in the cluster, to just start the Pod in BCI without specifying a specific virtual node to start the Pod, you can remove the selector of kubernetes.io/hostname in nodeSelector.

Configure CPU and Memory Resources

Currently, it supports to configure the specifications of BCI instances by specifying the resource.requests of each container in the Pod. If not specified, the default resource used by a single container is 1vCPU+2GiB Memory.The billing resources corresponding to BCI instance is the sum of all container resources in Pod. The field resources.limits is not supported with its value being ignored during a creation process.

. The BCI resource is the sum of all container resources in the Pod.

The operating cost of a BCI instance is related to the resource configuration of the instance and the sertice time of the instance. For details, please refer to BCI Billing Rules.

In the current BCI Pod, the CPU and Memory specifications that can be configured for each container are as follows:

If invalid CPU and Memory specifications are configured, the BCI instance cannot be successfully created.

Image pull

By default, the BCI Pod uses the internal containerd to pull the container image from the remote after each startup. If the image is an external network image, you need to Use NAT Gateway, or BCI PodBind EIP. It is recommended that you store the container image in the Baidu AI Cloud Image Warehouse, which can shorten the image pull time through private network.

For private image, you can configure imagePullSecrets for the BCI Pod to pull the private image. For an example, please refer to Private Image Practice in CCE Cluster.

Storage

The current BCI Pod supports mounting the following types of volumes:

• ConfigMap
• Secret
• NFS(CFS)
• EmptyDir

The usage is the same as that of native k8s.

Mounting PVC is not currently supported.

Network

BCI Pod does not currently support access to the ClusterIP in the cluster, nor does it support direct access to services through the service name in the cluster.

Other network access methods are the same as native Pod.

Bind EIP

When creating a Pod, you can automatically create an EIP and bind it through the following annotations.

• "bci.virtual-kubelet.io/bci-create-eip": "true"： An EIP is automatically created and bound when an instance is created. The default EIP type created is a post-paid instance billed by traffic.
• "bci.virtual-kubelet.io/bci-create-eip-bandwidth": "100"： The automatically created EIP bandwidth, in Mbps, if not specified, the default EIP bandwidth is 100Mbps.

Configure Log Push

Currently, BCI allows you to push logs in Pod containers to BLS for persistent storage and structured query of logs. You can enable the log push related feature through the following annotations:

• "bci.virtual-kubelet.io/bci-enable-log-push": "true": Enable the log push feature for the Pod. With the feature enabled, the logs of all containers in the pod are pushed to the log set corresponding to the BLS.

• "bci.virtual-kubelet.io/bci-enable-auto-log-push-phases": "Failed": If the final Pod status is a specific status, the container log in the Pod is automatically pushed to the BLS. The supported values are as follows:

  • "bci.virtual-kubelet.io/bci-enable-auto-log-push-phases": "Failed，Only automatically push the container logs in the Pod whose final status is Failed;
  • "bci.virtual-kubelet.io/bci-enable-auto-log-push-phases": "Succeeded，Only automatically push the container logs in the Pod whose final status is Succeeded;
  • "bci.virtual-kubelet.io/bci-enable-auto-log-push-phases": "Succeeded,Failed，Automatically push the container logs in Pod whose final status is Failed or Succeeded

Troubleshooting

If the Pod status changes to ProviderFailed after the BCI Pod is created, it means that the BCI instance creation failed. You can view the specific failure reason through kubectl describe po <pod name> --namespace <namespace>.

If the instance status is in Creating for a long time after the BCI Pod is created, it is usually caused by the BCI order exception. You can check the BCI order ID by viewing the bci.virtual-kubelet.io/order-id field in the pod annotation, and query the reason for the corresponding order failure.

List of supported annotations

Note: The annotation needs to be configured in PodSpec, not DeploymentSpec.

Note: When configuring the network, security group, and availability zone related annotations, you need to ensure the consistency between each other, such as the long and short id need to be consistent, the subnet needs to depend on the corresponding security group, and so on. In case of no special configuration, the configuration of the virtual node itself is used by default.

BCI Limit

Compared with native Pod, BCI Pod does not support the following features.

• DaemonSet Pod running on virtual nodes is not supported.
• HostPath/hostPid is not supported.
• The opening of privileged privileges is not supported.
• The mounting of oversized configmap and secret volume is not supported.
• Liveness/readiness probe is not supported.
• Init container is not supported.