Linux/K8s新手搭建BDC本地POC遇AZDATA BDC CREATE卡住及NFS PVC调度错误

Hey there, since you're new to Linux, Docker, and Kubernetes while building out a local BDC proof-of-concept, let's walk through how to debug that pod/PVC scheduling error you're facing—even though your NFS PV and PVC are successfully bound. Here are targeted steps to narrow down the issue:

• Check Node Taints, Tolerations, and Affinity Rules
  Kubernetes pods can get stuck scheduling if your worker nodes have taints that the BDC pods don't tolerate, or if there are required node affinity rules that aren't satisfied.

  • Run kubectl describe nodes to inspect taints on each node.
  • Grab the name of your stuck pod with kubectl get pods -n <your-bdc-namespace>, then run kubectl describe pod <stuck-pod-name> to check the Events section for messages like "node(s) had untolerated taint(s)" or "node(s) didn't match node affinity/selector".

• Validate Node Resource Availability
  BDC components have specific CPU and memory requirements. If your Kubernetes nodes don't have enough free resources, pods won't be scheduled.

  • Use kubectl describe pod <stuck-pod-name> to look for events like "Insufficient cpu" or "Insufficient memory".
  • Check overall node resource usage with kubectl top nodes to see if any node is maxed out. If resources are tight, you can adjust the resource requests in your BDC deployment config (look for the resources section in your bdc.json or tweak parameters when running azdata bdc create).

• Confirm NFS Share Accessibility from Worker Nodes
  A successful PV/PVC binding doesn't guarantee the NFS share is actually accessible from your Kubernetes nodes.

  • Log into one of your worker nodes and try mounting the NFS share manually:

    mount -t nfs <nfs-server-ip>:/<nfs-share-path> /tmp/test-mount
    

  • If the mount fails, check:
    • NFS server firewall rules (ensure port 2049 is open to your worker nodes)
    • Export permissions in /etc/exports on the NFS server (make sure your node IP ranges have read-write access)
    • DNS resolution for the NFS server from your worker nodes

• Double-Check Storage Class and PV Configuration
  Ensure your storage class and PV align with what the BDC expects:

  • Run kubectl describe storageclass <your-storage-class-name> to confirm the provisioner is set correctly (e.g., nfs or a dedicated NFS provisioner like nfs-subdir-external-provisioner).
  • Use kubectl describe pv <your-pv-name> to verify the accessModes match what the BDC requires—most shared BDC components need ReadWriteMany. Also confirm the PV's capacity is at least as large as what the PVC requests.

• Review Your BDC Deployment Config
  Make sure your bdc.json (or the parameters you passed to azdata bdc create) references the correct storage class and volume sizes:

  • Look for the storage section in your config, ensure the className matches your NFS storage class name exactly.
  • Verify the requested volume sizes don't exceed the capacity of your provisioned PVs.

• Dig Into Kubernetes Events
  The most detailed error clues are often in the namespace-wide events. Run this command to see all recent events sorted by time:

  kubectl get events -n <your-bdc-namespace> --sort-by='.metadata.creationTimestamp'
  

  Look for errors like FailedMount, FailedScheduling, or VolumeBindingFailed—these will point you directly to the root cause.

内容的提问来源于stack exchange，提问作者OomBoom