search

kubernetes-retired / kubeadm-dind-cluster

[EOL] A Kubernetes multi-node test cluster based on kubeadm
Apache License 2.0
1.11k stars 274 forks source link

Custom image problem with Docker 18.09 #282

Closed vfdev-5 closed 5 years ago

vfdev-5 commented 5 years ago

I experience a problem when I start up the cluster using my custom docker image.

I built a custom docker image with 

FROM mirantis/kubeadm-dind-cluster:v1.13

# Some other commands

and modifed a little dind-cluster-v1.13.sh such that it accepts my image. When I launch the cluster with dind-cluster-v1.13.sh up I have the following error:

* Starting DIND container: kube-master
* Running kubeadm: init --config /etc/kubeadm.conf --ignore-preflight-errors=all
Initializing machine ID from random generator.
Synchronizing state of docker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable docker
Loaded image: mirantis/hypokube:base

real    0m4.626s
user    0m0.336s
sys 0m0.292s
Sending build context to Docker daemon  177.6MB
Step 1/2 : FROM mirantis/hypokube:base
 ---> 6c5c247039c6
Step 2/2 : COPY hyperkube /hyperkube
error creating aufs mount to /var/lib/docker/aufs/mnt/5fd270c3c6e18381f9428c4f7f4809332535a046a19534988ec6fac4e756f8a7: invalid argument
*** kubeadm failed

Docker version: 18.09

However, the cluster is up and working correctly using base image mirantis/kubeadm-dind-cluster:v1.13.

* Making sure DIND image is up to date 
sha256:0fcb655948a1fa20f5a2100983755edc8f0d763248bda217b3454d82d5cd3be4: Pulling from mirantis/kubeadm-dind-cluster
Digest: sha256:0fcb655948a1fa20f5a2100983755edc8f0d763248bda217b3454d82d5cd3be4
Status: Image is up to date for mirantis/kubeadm-dind-cluster@sha256:0fcb655948a1fa20f5a2100983755edc8f0d763248bda217b3454d82d5cd3be4
* Starting DIND container: kube-master
* Running kubeadm: init --config /etc/kubeadm.conf --ignore-preflight-errors=all
Initializing machine ID from random generator.
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service.
Loaded image: mirantis/hypokube:base

real    0m4.742s
user    0m0.320s
sys 0m0.400s
Sending build context to Docker daemon  177.6MB
Step 1/2 : FROM mirantis/hypokube:base
 ---> 6c5c247039c6
Step 2/2 : COPY hyperkube /hyperkube
 ---> 115a0f28f2d8
Successfully built 115a0f28f2d8
Successfully tagged mirantis/hypokube:final
Created symlink /etc/systemd/system/multi-user.target.wants/kubelet.service → /lib/systemd/system/kubelet.service.
[init] Using Kubernetes version: v1.13.0

I remarked that in the original case there is a symlink created

Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service.

but with custom image I have instead

Synchronizing state of docker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable docke

If anyone could help we that, I'd really appreciate. Thanks!

fejta-bot commented 5 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 5 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten