Minikube空间不足并且尽管--disk-size标志仍失败

时间：2018-08-08 21:11:29

标签： kubernetes minikube

我正在尝试在Minikube中运行docker容器注册表以测试正在编写的CSI驱动程序。

我在Mac上运行minikube，并尝试使用以下minikube start命令：minikube start --vm-driver=hyperkit --disk-size=40g。我已经尝试使用kubeadm和localkube引导程序以及virtualbox vm-driver。

这是我用于注册表Pod部署的资源定义。 

---
apiVersion: v1
kind: Pod
metadata:
  name: registry
  labels:
    app: registry
  namespace: docker-registry
spec:
  containers:
  - name: registry
    image: registry:2
    imagePullPolicy: Always
    ports:
      - containerPort: 5000
    volumeMounts:
      - mountPath: /var/lib/registry
        name: registry-data
  volumes:
  - hostPath:
      path: /var/lib/kubelet/plugins/csi-registry
      type: DirectoryOrCreate
    name: registry-data

我尝试使用kubectl apply -f registry-setup.yaml创建它。在运行此程序之前，我的minikube集群报告其自身已经准备就绪，并且所有正常的minikube容器都在运行。

但是，这无法运行，并且在运行kubectl describe pod时，我看到以下消息：

    Name:         registry
    Namespace:    docker-registry
    Node:         minikube/192.168.64.43
    Start Time:   Wed, 08 Aug 2018 12:24:27 -0700
    Labels:       app=registry
    Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"app":"registry"},"name":"registry","namespace":"docker-registry"},"spec":{"cont...
    Status:       Running
    IP:           172.17.0.2
    Containers:
    registry:
        Container ID:   docker://42e5193ac563c2b2e2a2b381c91350d30f7e7c5009a30a5977d33b403a374e7f
        Image:          registry:2
    ...
    TRUNCATED FOR SPACE
    ...
    Events:
    Type    Reason                 Age   From               Message
    ----    ------                 ----  ----               -------
    Normal  Scheduled              1m    default-scheduler  Successfully assigned registry to minikube
    Normal  SuccessfulMountVolume  1m    kubelet, minikube  MountVolume.SetUp succeeded for volume "registry-data"
    Normal  SuccessfulMountVolume  1m    kubelet, minikube  MountVolume.SetUp succeeded for volume "default-token-kq5mq"
    Normal  Pulling                1m    kubelet, minikube  pulling image "registry:2"
    Normal  Pulled                 1m    kubelet, minikube  Successfully pulled image "registry:2"
    Normal  Created                1m    kubelet, minikube  Created container
    Normal  Started                1m    kubelet, minikube  Started container
    ...
    TRUNCATED
    ...
    Name:         storage-provisioner
    Namespace:    kube-system
    Node:         minikube/192.168.64.43
    Start Time:   Wed, 08 Aug 2018 12:24:38 -0700
    Labels:       addonmanager.kubernetes.io/mode=Reconcile
                integration-test=storage-provisioner
    Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","integration-test":"storage-provis...
    Status:       Pending
    IP:           192.168.64.43
    Containers:
    storage-provisioner:
        Container ID:  
        Image:         gcr.io/k8s-minikube/storage-provisioner:v1.8.1
        Image ID:      
        Port:          <none>
        Host Port:     <none>
        Command:
        /storage-provisioner
        State:          Waiting
        Reason:       ErrImagePull
        Ready:          False
        Restart Count:  0
        Environment:    <none>
        Mounts:
        /tmp from tmp (rw)
        /var/run/secrets/kubernetes.io/serviceaccount from storage-provisioner-token-sb5hz (ro)
    Conditions:
    Type           Status
    Initialized    True 
    Ready          False 
    PodScheduled   True 
    Volumes:
    tmp:
        Type:          HostPath (bare host directory volume)
        Path:          /tmp
        HostPathType:  Directory
    storage-provisioner-token-sb5hz:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  storage-provisioner-token-sb5hz
        Optional:    false
    QoS Class:       BestEffort
    Node-Selectors:  <none>
    Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                    node.kubernetes.io/unreachable:NoExecute for 300s
    Events:
    Type     Reason                 Age               From               Message
    ----     ------                 ----              ----               -------
    Normal   Scheduled              1m                default-scheduler  Successfully assigned storage-provisioner to minikube
    Normal   SuccessfulMountVolume  1m                kubelet, minikube  MountVolume.SetUp succeeded for volume "tmp"
    Normal   SuccessfulMountVolume  1m                kubelet, minikube  MountVolume.SetUp succeeded for volume "storage-provisioner-token-sb5hz"
    Normal   Pulling                23s (x3 over 1m)  kubelet, minikube  pulling image "gcr.io/k8s-minikube/storage-provisioner:v1.8.1"
    Warning  Failed                 21s (x3 over 1m)  kubelet, minikube  Failed to pull image "gcr.io/k8s-minikube/storage-provisioner:v1.8.1": rpc error: code = Unknown desc = failed to register layer: Error processing tar file(exit status 1): write /storage-provisioner: no space left on device
    Warning  Failed                 21s (x3 over 1m)  kubelet, minikube  Error: ErrImagePull
    Normal   BackOff                7s (x3 over 1m)   kubelet, minikube  Back-off pulling image "gcr.io/k8s-minikube/storage-provisioner:v1.8.1"
    Warning  Failed                 7s (x3 over 1m)   kubelet, minikube  Error: ImagePullBackOff
    ------------------------------------------------------------
    ...

因此，在注册表容器正确启动的同时，其他一些minikube服务（包括dns，http入口服务等）由于以下原因而开始失败：write /storage-provisioner: no space left on device。尽管为minikube分配了40GB的磁盘大小，但似乎minikube试图写入只有1GB空间的rootfs或devtempfs（取决于vm-driver）。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          919M  713M  206M  78% /
devtmpfs        919M     0  919M   0% /dev
tmpfs           996M     0  996M   0% /dev/shm
tmpfs           996M  8.9M  987M   1% /run
tmpfs           996M     0  996M   0% /sys/fs/cgroup
tmpfs           996M  8.0K  996M   1% /tmp
/dev/sda1        34G  1.3G   30G   4% /mnt/sda1

在提取图像和创建容器时，是否有办法使minikube实际使用分配给/ mnt / sda1的34GB空间而不是rootfs？

在此先感谢您的帮助！

2 个答案:

答案 0 :(得分：1)

您需要将Minikube虚拟机配置为使用for ( char ch : string.tocharArray() ) { sum += intArr[(int)ch - 65 ]; } 而非Docker的/dev/sda1。要登录，请使用/命令。

有两种选择：

  1. 将minikube ssh固定到/dev/sda1，但不要忘记在此之前将内容从原始var/lib/docker复制到var/lib/docker。

  2. 重新配置Docker以使用/mnt/sda1代替/mnt/sda1来存储图像。浏览此link，以获取有关它的更多信息。

答案 1 :(得分：0)

您还可以使用minikube --docker-opt选项设置minikube中运行的--data-root守护程序的dockerd option。 --docker-opt可以用作dockerd的任何参数的传递。

例如，在您上面描述的情况下，它看起来像：

minikube start --vm-driver=hyperkit --disk-size=40g --docker-opt="--data-root /mnt/sda1"

请记住，如果您尝试修改现有的迷你库集群，则必须在重新启动或删除并重建集群之前将var/lib/docker复制到/mnt/sda1（正如前面的回答所示）。

更新： 经过试验，我注意到上述解决方案在您第一次运行minikube start时第一次不起作用，因为它以某种方式干扰了minikube自己的核心系统构建和启动过程。 实际上，这意味着您需要在没有minikube start的情况下至少运行一次--docker-opt来构建核心系统，然后使用--docker-opt重新运行它。

相关问题
最新问题