Kubernetesがイメージを繰り返しプルバックして滞留しています

Question

私は、Oracleデータベースを使用したい場合を除いて、https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/の行に沿ってシングルインスタンスステートフルアプリケーションを作成しようとしています。

私はW10を実行し、Minikubeを使用してクラスタを設定し、Hyper-Vをドライバとして設定し、Minikube用の仮想スイッチも作成しました。

Oracle DBイメージとポートを使用するようにデプロイされたYAMLを編集し、Docker Hubのプルシークレットを追加しました（Oracleはログインするためにログインする必要があります）。

最終YAML：

apiVersion: v1 
kind: Service 
metadata: 
    name: orcldb 
spec: 
    ports: 
    - port: 1521 
    name: sqlnet 
    - port: 5500 
    name: oraclexml 
    selector: 
    app: orcldb 
    clusterIP: None 
--- 
apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: orcldb-pv-claim 
spec: 
    accessModes: 
    - ReadWriteOnce 
    resources: 
    requests: 
     storage: 5Gi 
--- 
apiVersion: apps/v1beta2 
kind: Deployment 
metadata: 
    name: orcldb 
spec: 
    selector: 
    matchLabels: 
     app: orcldb 
    strategy: 
    type: Recreate 
    template: 
    metadata: 
     labels: 
     app: orcldb 
    spec: 
     containers: 
     - image: store/oracle/database-enterprise:12.2.0.1 
     name: orcldb 
     ports: 
     - containerPort: 1521 
      name: sqlnet 
     - containerPort: 5500 
      name: oraclexml 
     volumeMounts: 
     - name: orcldb-persistent-storage 
      mountPath: /var/lib/orcldb 
     imagePullSecrets: 
     - name: dockerhubkey 
     volumes: 
     - name: orcldb-persistent-storage 
     persistentVolumeClaim: 
      claimName: orcldb-pv-claim 

だから私はkubectl create -f deployment.yamlを実行した後に、すべてのものがそれに応じて作成されます。

service "orcldb" created 
persistentvolumeclaim "orcldb-pv-claim" created 
deployment "orcldb" created 

しかし、私はkubectl describe pods orcldbを実行した場合、その後、私はイベントでこれを参照してください。

Type  Reason     Age    From    Message 
    ----  ------     ----    ----    ------- 
    Warning FailedScheduling  1h (x2 over 1h) default-scheduler PersistentVolumeClaim is not bound: "orcldb-pv-claim" 
    Normal Scheduled    1h    default-scheduler Successfully assigned orcldb-7d96df68c8-bjwql to minikube 
    Normal SuccessfulMountVolume 1h    kubelet, minikube MountVolume.SetUp succeeded for volume "pvc-c91fd4a0-c3da-11e7-9300-00155d050c0a" 
    Normal SuccessfulMountVolume 1h    kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-rszmg" 
    Normal Pulling    1h    kubelet, minikube pulling image "store/oracle/database-enterprise:12.2.0.1" 
    Normal SuccessfulMountVolume 1h    kubelet, minikube MountVolume.SetUp succeeded for volume "pvc-c91fd4a0-c3da-11e7-9300-00155d050c0a" 
    Normal SuccessfulMountVolume 1h    kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-rszmg" 
    Normal Pulling    1h    kubelet, minikube pulling image "store/oracle/database-enterprise:12.2.0.1" 
    Normal SuccessfulMountVolume 43m    kubelet, minikube MountVolume.SetUp succeeded for volume "pvc-c91fd4a0-c3da-11e7-9300-00155d050c0a" 
    Normal SuccessfulMountVolume 43m    kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-rszmg" 
    Normal Pulling    43m    kubelet, minikube pulling image "store/oracle/database-enterprise:12.2.0.1" 
    Normal SuccessfulMountVolume 32m    kubelet, minikube MountVolume.SetUp succeeded for volume "pvc-c91fd4a0-c3da-11e7-9300-00155d050c0a" 
    Normal SuccessfulMountVolume 32m    kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-rszmg" 
    Normal Pulling    32m    kubelet, minikube pulling image "store/oracle/database-enterprise:12.2.0.1" 

また、minikubeクラスタが停止することがあります（？）/拒否するconnectio n、私は通常その後にminikubeを再起動しますが、一度それを残しておけば、それはしばらく前に戻ってきます（繰り返されるプルプロセスはまだ進行中です）。

私はこの種の問題に直面している誰かを見つけることができませんでした。なぜこのようなことが起こったのか、私は非常に感謝しています。ディスクに関するエラーとminikubeログの

パート：

Nov 07 18:37:22 minikube localkube[16252]: E1107 18:37:22.727122 16252 fsHandler.go:121] failed to collect filesystem stats - rootDiskErr: du command failed on /var/lib/docker/overlay2/611dbda511b2771528eff890891445fe89fdd171e6e1e944596b82b5a031d4c6 with output stdout: , stderr: du: cannot access '/var/lib/docker/overlay2/611dbda511b2771528eff890891445fe89fdd171e6e1e944596b82b5a031d4c6': No such file or directory 
Nov 07 18:37:22 minikube localkube[16252]: - exit status 1, rootInodeErr: cmd [find /var/lib/docker/overlay2/611dbda511b2771528eff890891445fe89fdd171e6e1e944596b82b5a031d4c6 -xdev -printf .] failed. stderr: find: '/var/lib/docker/overlay2/611dbda511b2771528eff890891445fe89fdd171e6e1e944596b82b5a031d4c6': No such file or directory 
Nov 07 18:37:22 minikube localkube[16252]: ; err: exit status 1, extraDiskErr: du command failed on /var/lib/docker/containers/97fc2e9f49de23415fe6494bf3684672aeb1213930de02314b1f2ce411f4dc6a with output stdout: , stderr: du: cannot access '/var/lib/docker/containers/97fc2e9f49de23415fe6494bf3684672aeb1213930de02314b1f2ce411f4dc6a': No such file or directory 

Answer 1

私は、Oracleが離れて巨大な公式の画像から移動し、Oracle Expressの11gデータベースのカスタムメイドの画像を使用していました。イメージが引き出され、コンテナが問題なく開始されました。

また、このgithub issueに記載されているように、Minikubeがしばらくして応答を停止する問題は、Hyper-Vのダイナミックメモリを無効にすることで解決されました。