Question

我正在尝试按https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/行创建单实例有状态应用程序，但我想使用Oracle数据库。

我运行W10并使用Minikube设置群集，Hyper-V作为驱动程序，我还为Minikube创建了一个虚拟交换机。

我相应地编辑了部署YAML以使用Oracle DB映像和端口，并为Docker Hub添加了一个拉秘密（因为Oracle希望您登录以获取inmage）。

最后的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群集有时会停止（？）/拒绝连接，我通常会在此之后重新启动minikube，但是一旦我离开它，它会在一段时间后重新启动（重复拉动过程仍在继续）。 / p>

我无法找到任何人面对这类问题，所以我非常感谢任何关于为什么会发生这种情况的见解。

部分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数据库的自定义图像。现在拉出图像并启动容器而没有任何问题。

此外，Minikube会在一段时间后停止响应的问题通过在Hyper-V中禁用动态内存来解决，如github issue中所述。

Kubernetes反复拉动图像，并坚持在容器创建

1 个答案: