Configuring BCIPod
Configure CPU and memory resources
For BCI specification description and creation, see Create a pod with specified vCPU and memory
The running cost of a BCI instance is related to the instance’s resource configuration and running duration. For details, refer to BCI billing rules.
BCI-supported specifications
| CPU/core | Memory interval (GiB) |
| 0.25 | 0.5, 1, 2 |
| 0.5 | 1, 2, 4 |
| 1 | 1, 2, 4, 8 |
| 2 | 4, 8, 16 |
| 4 | 8, 16, 32 |
| 8 | 16, 32 |
| 12 | 24, 48 |
| 16 | 32, 64 |
| 32 | 64, 128 |
Invalid CPU and memory specifications will prevent the successful creation of a BCI instance.
If you need instance specifications not listed above, please submit a ticket.
Image pull
Currently, BCI only supports pulling container images from the following repositories:
- Baidu AI Cloud Container Registry (CCR) (image address:
registry.baidubce.com/<namespace>/<name>:<tag>) - Docker Hub (image address:
[<namespace>/]<name>:<tag>) - Baidu AI Cloud CCE Image Registry (image address:
registry.baidubce.com/<namespace>/<name>:<tag>)
If the image is a private image, you can configure imagePullSecrets for the BCI pod to pull the private image. For examples, refer to [Practice of using private images in CCE clusters](CCE/Typical Practices/Practice of using private images in CCE clusters.md).
Storage
Currently, BCI pods support mounting the following volume types:
- ConfigMap: For detailed description, see the document Mount an EmptyDir volume; for detailed description, see the document Mount CFS file storage
- Secret
- EmptyDir: (Specifying
sizeLimitis not supported temporarily; the available storage space of emptyDir for a single pod is 10 GB) -
PersistentVolumeClaim(PVC): Currently, only CFS/NFS/PFS PVC mounting is supported. Mounting CDS cloud disks is not supported temporarily.
- NFS(CFS): For detailed description, see the document Mount CFS file storage
- PFS: For detailed description, see the document Mount parallel file storage (PFS)
- BOS: For detailed description, see the document Mount a BOS volume
Currently, mounting via subPath/subPathExpr is not supported.
Network
Configure public network access
A BCI pod occupies one elastic network interface resource of the switch in its affiliated VPC, and has one intranet IP address by default. If public network access is required (e.g., to pull public network images). You need to bind an EIP to the BCI pod, or bind a NAT gateway to the affiliated VPC. For more information, see Access the public network
K8S service
To access intra-claster services from a BCI pod, refer to the document Configure BCI pod to access intra-claster services.
The way pods access ClusterIP in a serverless cluster varies depending on the parameters set when the cluster was created. For details, refer to [Use services in serverless clusters](CCE/Operation guide/Serverless Cluster/Using Service in Serverless Cluster.md). If the Cluster Service mode is set to BLB, there is no need to inject the kube-proxy sidecar into the BCI pod.
If you need to expose your BCI service for external access, refer to the document Access BCI services via service
More network configuration
Configure the security group for BCI pods Support for custom DNSConfig
Configure log push
Currently, BCI supports pushing logs from pod containers to BLS for persistent log storage and structured query. For detailed configuration, refer to BLS log collection methods
Configure monitor
View instance monitor metrics Obtain instance monitor metrics via VK
Troubleshooting
If the pod status changes to ProviderFailed after creating the BCI pod, it indicates that the BCI instance creation failed. You can run the command kubectl describe po <pod-name> --namespace <namespace> to view the specific failure cause.
If the instance status remains Creating for a long time, it is generally caused by an abnormal BCI order. You can check the bci.virtual-kubelet.io/order-id field in the pod’s annotations to find the BCI order ID, then query the cause of the order failure.
BCI custom annotations
For the list of annotations supported by BCI, see BCI Pod Annotations
Note: Annotations must be defined within the PodSpec, not the DeploymentSpec.
Note: When setting annotations for network, security groups, and availability zones, ensure their configurations align. For instance, the subnet and security group should belong to the same VPC, and the subnet must correspond to the specified availability zone. If no specific configuration is defined in the pod, the virtual node's default settings will be applied.
Note: If you annotate a subnet parameter, you must also annotate an availability zone parameter. The availability zone parameter's value must correspond to the subnet's respective availability zone.
BCI limitations
Due to public cloud security requirements and restrictions imposed by virtual nodes, BCI currently does not support certain Kubernetes features such as HostPath and DaemonSet. See the table below:
| Unsupported functions | Description | Recommended alternative |
|---|---|---|
| HostPath | Mounting files from the local host to containers | Use emptyDir, cloud disks, or CFS file systems |
| HostNetwork | Mapping ports of the host machine to containers | BCI ignores the HostNetwork field; use a LoadBalancer of type LoadBalancer |
| DaemonSet | Deploying static pods on the host where the container resides | Deploy multiple images in the pod in the form of a sidecar |
| Privileged permissions | Containers having privileged permissions | Remove business logic dependencies on privileged permissions |
| Service of type NodePort | Mapping ports of the host machine to containers | Use a LoadBalancer of type LoadBalancer |
For more documents, see: Connection overview