Kubeadm: 记录如何在容器中运行 kubeadm 并提供脚本

_来自@luxas 2016 年 10 月 27 日 18:14_

cc @errordeveloper和@marun因为他们一直在容器内运行 systemd

@andersla请注意，ootb 不支持在容器内以这种方式运行 systemd，但请随意尝试我们的/hack，因为它非常适合以这种方式测试 kubeadm

_来自@zreigz于 2016 年 10 月 28 日 7:36_

如果你不介意，我想仔细看看并尝试修复它。

_来自@

@zreigz请做！
这是我尝试安装它的方式：

docker run -it --privileged ubuntu /bin/bash

进而：

echo "Updating Ubuntu..."
apt-get update -y
apt-get upgrade -y

echo "Install os requirements"
apt-get install -y \
  curl \
  apt-transport-https \
  dialog \
  python \
  daemon

echo "Add Kubernetes repo..."
sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
apt-get update -y

echo "Installing Kubernetes requirements..."
apt-get install -y \
  docker.io \
  kubelet \
  kubernetes-cni \
  kubectl \
  kubeadm

这是我在安装 kubeadm 时遇到的错误：

root<strong i="16">@82f5321d45cb</strong>:/# apt-get install kubeadm
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  kubeadm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 7981 kB of archives.
After this operation, 59.2 MB of additional disk space will be used.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubeadm amd64 1.5.0-alpha.0-1534-gcf7301f-00 [7981 kB]
Fetched 7981 kB in 0s (8532 kB/s)
Selecting previously unselected package kubeadm.
(Reading database ... 14222 files and directories currently installed.)
Preparing to unpack .../kubeadm_1.5.0-alpha.0-1534-gcf7301f-00_amd64.deb ...
Unpacking kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
Setting up kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
Failed to connect to bus: No such file or directory
dpkg: error processing package kubeadm (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 kubeadm
E: Sub-process /usr/bin/dpkg returned an error code (1)

_来自@zreigz于 2016 年 10 月 28 日 9:10_

我复制了它，我一直在研究这个

_来自@zreigz于 2016 年 10 月 31 日 7:24_

有两个问题。

第一个： ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
在 Ubuntu 系统上，/bin/sh 是 dash，而不是 bash，dash 不支持双括号关键字。 好消息是该问题已在 master 分支上修复，应该很快可用： https :

第二个不是那么简单。 在容器中运行 systemctl 失败并显示Failed to get D-Bus connection 。 似乎 systemd 在容器中无法正常工作。 现在我正在研究这个

_来自@

伟大的！
我只是不明白为什么安装 kubeadm 需要 systemd/systemctl？

_来自@zreigz于 2016 年 10 月 31 日 7:47_

由于这两行： https :

systemctl daemon-reload
systemctl restart kubelet

它在第一行失败

_来自@zreigz于 2016 年 10 月 31 日 7:48_

这是解释：

# because kubeadm package adds kubelet drop-ins, we must daemon-reload
# and restart kubelet now. restarting kubelet is ok because kubelet
# postinst configure step auto-starts it.

_来自@zreigz于 2016 年 10 月 31 日 7:52_

有一些配置步骤可以使其工作，但我必须先尝试一下。 如果我找到了什么，我会告诉你的。

_来自@zreigz于 2016 年 11 月 2 日 7:19_

好消息。 我已经设法解决了所有问题。 它需要最后的测试，我将发布如何在 Docker 容器中运行 kubeadm 的解决方案

_来自@andersla于 2016 年 11 月 2 日 7:23_

极好的！ 我会在准备好后尽快帮助测试！ - 虽然这周剩下的时间我都在假期:)

_来自@zreigz于 2016 年 11 月 2 日 10:13_

在 Docker 容器中安装 kubeadm 有两个主要问题。 首先是在容器中运行的 systemd。 其次是在容器内安装docker。 成功地解决了问题。 这是必须用于准备 Ubuntu 映像的 Dockerfile

FROM ubuntu
ENV container docker
RUN apt-get -y update

RUN apt-get update -qq && apt-get install -qqy \
    apt-transport-https \
    ca-certificates \
    curl \
    lxc \
    vim \
    iptables

RUN curl -sSL https://get.docker.com/ | sh

RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;

VOLUME /sys/fs/cgroup
VOLUME /var/run/docker.sock
CMD /sbin/init

我使用此命令在包含 Dockerfile 的目录中构建映像

docker build -t kubeadm_docker .

现在您可以运行准备好的映像并完成 kubeadm 安装。
使用以下命令运行kubeadm_docker图像：

docker run -it -e "container=docker" --privileged=true -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock  kubeadm_docker /sbin/init

查找正在运行的容器 ID

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
7dd73057620d        kubeadm_docker      "/sbin/init"        About an hour ago   Up About an hour                        furious_fermi

现在您可以打开容器控制台：

docker exec -it 7dd73057620d /bin/bash

这是您安装 kubeadm 的脚本（稍作修改）

echo "Updating Ubuntu..."
apt-get update -y
apt-get upgrade -y

systemctl start docker

echo "Install os requirements"
apt-get install -y \
  curl \
  apt-transport-https \
  dialog \
  python \
  daemon

echo "Add Kubernetes repo..."
sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
apt-get update -y

echo "Installing Kubernetes requirements..."
apt-get install -y \
  kubelet

# This is temporary fix until new version will be released
sed -i 38,40d /var/lib/dpkg/info/kubelet.postinst

apt-get install -y \
  kubernetes-cni \
  kubectl \
  kubeadm

最后你可以执行

# kubeadm init

一切都像在本地机器上一样。
祝你好运 ：）

_来自@SuperStevenZ 2016 年 11 月 17 日 7:21_

@zreigz解决了我同样的问题，谢谢！

_来自@zreigz于 2016 年 11 月 17 日 7:30_

没问题 ：）

我们应该用 docker-in-docker 的东西建立一个 CI。

@errordeveloper @zreigz你能接受这个吗？
至少我们应该在某处记录如何在容器内运行 kubeadm ......

对我来说听起来不错。 当然，我们需要将所有这些东西放在 docker 镜像中，加上一些配置/启动脚本来区分 master 和 node。 好的开始是为它创建项目，如 kubernetes/kubeadm-docker。 它也是 Dockerfile、脚本和文档的正确位置

首先在 zreigz/ 下创建一个私有项目，最终我们可能会将该代码合并到这个 repo 中。

但首先，在您自己的空间中制作原型，我们将看到它是如何进行的。

真正的受让人是@zreigz

是的好点。 我会做的。 下周（周一、周二）我在开会，所以我将从周三开始。

@luxas我想知道我应该如何提供 kubeadm 和 kubernetes-cni 包。 如果我应该从当前来源构建它（以便能够测试最新的实现）或者只是从存储库下载最新版本？ 出于 CI 目的，我认为我们应该拥有代码的当前状态才能对其进行测试，还是仅需要它来测试发布版本？

嗨，感谢您的修复，但在 kubeadm init 后仍然出现问题，我在 DNS 上得到 0/3，DNS 似乎根本没有运行

每 2.0 秒：kubectl get pods --all-namespaces Fri Dec 16 17:00:50 2016

NAMESPACE NAME READY STATUS RESTARTS 年龄
kube-system dummy-2088944543-17sey 1/1 运行 0 11m
kube-system etcd-8dd8c92c6c38 1/1 运行 2 12m
kube-system kube-apiserver-8dd8c92c6c38 1/1 运行 4 12m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 运行 2 11m
kube-system kube-discovery-1150918428-m506w 1/1 运行 0 11m
kube-system kube-dns-654381707-vuijm 0/3 ContainerCreating 0 11m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11m
kube-system kube-scheduler-8dd8c92c6c38 1/1 运行 2 10m

尝试安装网络策略
root@8dd8c92c6c38 :/# kubectl apply -f calico.yaml
路径“calico.yaml”不存在
root@8dd8c92c6c38 :/# kubectl create -f calico.yaml
路径“calico.yaml”不存在
root@8dd8c92c6c38 :/# kubectl apply -f kube-flannel.yml
路径“kube-flannel.yml”不存在

root@8dd8c92c6c38 :/# kubectl apply -f https://git.io/weave-kube
守护进程“weave-net”已创建
root@8dd8c92c6c38 :/# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS 年龄
kube-system dummy-2088944543-17sey 1/1 运行 0 46m
kube-system etcd-8dd8c92c6c38 1/1 运行 2 46m
kube-system kube-apiserver-8dd8c92c6c38 1/1 运行 4 46m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 运行 2 45m
kube-system kube-discovery-1150918428-9m6rr 0/1 待定 0 3m
kube-system kube-dns-654381707-vuijm 0/3 ContainerCreating 0 45m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-scheduler-8dd8c92c6c38 1/1 运行 2 44m
kube-system weave-net-iv0bc 0/2 ContainerCreating 0 49s
信息：1 个已完成的对象未显示在 pod 列表中。 通过 --show-all 查看所有对象。

再次嗨@zreigz
现在我终于有时间更进一步并测试它 - 我几乎可以做到，但是 docker 选择 vfs 存储驱动程序有一个错误（可能是因为它不能在 aufs 之上使用 aufs？但是正如你描述的解决方法上面我将外部 docker .sock 安装在内部 docker 中，所以应该可以用 aufs 编写？如果我这样做
docker info在我的主机上，它说它正在运行 aufs 存储驱动程序。 - 而如果我在带有 kubernetes 的 docker 容器中执行docker info ，它说它使用的是 vfs 存储驱动程序。
为什么我在运行时遇到以下问题的任何想法
kubeadm init

root<strong i="13">@f50f087baa83</strong>:/# kubeadm init
[kubeadm] WARNING: kubeadm is in alpha, please do not use it for production clusters.
[preflight] Running pre-flight checks
[preflight] The system verification failed. Printing the output from the verification:
OS: Linux
KERNEL_VERSION: 4.4.0-43-generic
CONFIG_NAMESPACES: enabled
CONFIG_NET_NS: enabled
CONFIG_PID_NS: enabled
CONFIG_IPC_NS: enabled
CONFIG_UTS_NS: enabled
CONFIG_CGROUPS: enabled
CONFIG_CGROUP_CPUACCT: enabled
CONFIG_CGROUP_DEVICE: enabled
CONFIG_CGROUP_FREEZER: enabled
CONFIG_CGROUP_SCHED: enabled
CONFIG_CPUSETS: enabled
CONFIG_MEMCG: enabled
CONFIG_INET: enabled
CONFIG_EXT4_FS: enabled
CONFIG_PROC_FS: enabled
CONFIG_NETFILTER_XT_TARGET_REDIRECT: enabled (as module)
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled (as module)
CONFIG_OVERLAY_FS: enabled (as module)
CONFIG_AUFS_FS: enabled (as module)
CONFIG_BLK_DEV_DM: enabled
CGROUPS_CPU: enabled
CGROUPS_CPUACCT: enabled
CGROUPS_CPUSET: enabled
CGROUPS_DEVICES: enabled
CGROUPS_FREEZER: enabled
CGROUPS_MEMORY: enabled
DOCKER_VERSION: 1.12.1
DOCKER_GRAPH_DRIVER: vfs
[preflight] Some fatal errors occurred:
    unsupported graph driver: vfs
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
root<strong i="14">@f50f087baa83</strong>:/# 

尝试更多信息后，可以获得更多信息。
我在主机上将 docker 存储驱动程序更改为“覆盖”。 然后 docker 里面的 docker 选择 aufs 作为驱动程序，我通过了“飞行前检查”，但现在我被困在了
[apiclient] Created API client, waiting for the control plane to become ready

在其他一些测试中，我意识到 docker 在通过 /sbin/init 作为服务启动时没有选择相同的存储驱动程序
如果我以这种方式运行 docker 映像，它不会启动与主机相同的驱动程序（如上所述）：
sudo docker run -it --privileged=true -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /sbin/init

如果我在没有/sbin/init情况下启动它，而不是像这样的守护进程：
sudo docker run -it --privileged=true --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /bin/bash然后 docker 选择与主机相同的存储驱动程序（但现在systemctrl不起作用）

更多更新：

我现在可以使用这个 Dockerfile 构建一个可用的 kubeadm-in-docker-container：

FROM ubuntu:xenial-20161213

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -qq

RUN apt-get install -y \
    apt-transport-https \
    apt-utils \
    ca-certificates \
    curl \
    dialog \
    python \
    daemon \
    vim \
    jq \
    linux-image-$(uname -r)

# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
  rm -f /lib/systemd/system/multi-user.target.wants/*;\
  rm -f /etc/systemd/system/*.wants/*;\
  rm -f /lib/systemd/system/local-fs.target.wants/*; \
  rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
  rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
  rm -f /lib/systemd/system/basic.target.wants/*;\
  rm -f /lib/systemd/system/anaconda.target.wants/*;

# install docker (after removing unwanted systemd)
RUN apt-get install -y \
    docker.io

RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'

RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
  kubelet \
  kubernetes-cni \
  kubectl

RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
  kubeadm; exit 0

# Create volume for docker
VOLUME /var/lib/docker

我用： docker build -t kubeadm_docker .

然后运行：

docker run -it --privileged=true --name=master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init

等待几 (10-15) 秒，直到 systemd 和 docker 启动并运行

然后我在正在运行的容器中启动 kubeadm：
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

当它启动时，我启动第二个“工人”节点：

docker run -it --privileged=true --name=node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
几秒钟后加入主人：

docker exec -it edge kubeadm join --token=acbec6.2852dff7cb569aa0 172.17.0.2

当前 docker 网络存在一些问题，因为 kube-proxy fais 并进入 CrashLoopBackOff。

如果我在上面运行 docker 时改为设置--net=host ，那么 kube-proxy 和所有 pod 都可以正常运行 - 但这不是一个选项，因为我需要使用它们的 IP 在 docker 网络上运行容器：秒

我之前也尝试使用与主机上相同的进程运行 docker： -v /var/run/docker.sock:/var/run/docker.sock但我从来没有让它工作，因为当容器内的 docker 用 systemd 启动时，它不会拿起袜子（或类似的东西）那）。

谢谢@andersla！
你能粘贴 kube-proxy 失败的地方吗？

感谢@luxas的关注！

不幸的是， journalctl -xeu kubelet没有详细信息

这就是我找到的关于 kube-proxy 的所有信息（重复了很多次）我还附上了完整的日志。

Jan 09 14:40:02 1355b98bf8c7 kubelet[244]: I0109 14:40:02.690862     244 docker_manager.go:2524] checking backoff for container "kube-proxy" in pod "kube-proxy-7886l"
Jan 09 14:40:03 1355b98bf8c7 kubelet[244]: I0109 14:40:03.984818     244 docker_manager.go:2538] Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-7886l_kube-system(71a1e950-d679-11e6-a9f7-02429d4c0f01)
Jan 09 14:40:03 1355b98bf8c7 kubelet[244]: E0109 14:40:03.984833     244 pod_workers.go:184] Error syncing pod 71a1e950-d679-11e6-a9f7-02429d4c0f01, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-7886l_kube-system(71a1e950-d679-11e6-a9f7-02429d4c0f01)"

完整日志还抱怨 kube-dns - 但那是因为我还没有开始编织。

日志文件

这是kubectl describe pod -n kube-system kube-proxy-w0ng5日志

Name:       kube-proxy-w0ng5
Namespace:  kube-system
Node:       3551807cba77/172.17.0.2
Start Time: Tue, 10 Jan 2017 18:03:06 +0000
Labels:     component=kube-proxy
        k8s-app=kube-proxy
        kubernetes.io/cluster-service=true
        name=kube-proxy
        tier=node
Status:     Running
IP:     172.17.0.2
Controllers:    DaemonSet/kube-proxy
Containers:
  kube-proxy:
    Container ID:   docker://dcc2bc0b50a2477b72d451b776f35e327f1faf09e3cddb25d5609569c6f2a242
    Image:      gcr.io/google_containers/kube-proxy-amd64:v1.5.1
    Image ID:       docker-pullable://gcr.io/google_containers/kube-proxy-amd64<strong i="7">@sha256</strong>:3b82b2e0862b3c0ece915de29a5a53634c9b0a73140340f232533c645decbd4b
    Port:       
    Command:
      kube-proxy
      --kubeconfig=/run/kubeconfig
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 10 Jan 2017 18:08:48 +0000
      Finished:     Tue, 10 Jan 2017 18:08:48 +0000
    Ready:      False
    Restart Count:  6
    Volume Mounts:
      /run/kubeconfig from kubeconfig (rw)
      /var/run/dbus from dbus (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-g0ft5 (ro)
    Environment Variables:  <none>
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  kubeconfig:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/kubernetes/kubelet.conf
  dbus:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/dbus
  default-token-g0ft5:
    Type:   Secret (a volume populated by a Secret)
    SecretName: default-token-g0ft5
QoS Class:  BestEffort
Tolerations:    dedicated=master:NoSchedule
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath           Type        Reason  Message
  --------- --------    -----   ----            -------------           --------    ------  -------
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      Pullingpulling image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1"
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      CreatedCreated container with docker id ecf446de342a; Security:[seccomp=unconfined]
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      StartedStarted container with docker id ecf446de342a
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      Pulled  Successfully pulled image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1"
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      CreatedCreated container with docker id f562fb667a64; Security:[seccomp=unconfined]
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      StartedStarted container with docker id f562fb667a64
  9m        9m      2   {kubelet 3551807cba77}                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 10s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  9m    9m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id 1a7d7d4f682b
  9m    9m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id 1a7d7d4f682b; Security:[seccomp=unconfined]
  9m    9m  2   {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id 89bdf4ba7e0b
  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id 89bdf4ba7e0b; Security:[seccomp=unconfined]
  8m    8m  3   {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 40s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id f2b7a2b5078d; Security:[seccomp=unconfined]
  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id f2b7a2b5078d
  8m    7m  6   {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  6m    6m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id 28deaf41d920; Security:[seccomp=unconfined]
  6m    6m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id 28deaf41d920
  6m    4m  12  {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  9m    4m  6   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Pulled      Container image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1" already present on machine
  4m    4m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id dcc2bc0b50a2; Security:[seccomp=unconfined]
  4m    4m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id dcc2bc0b50a2
  9m    10s 43  {kubelet 3551807cba77}  spec.containers{kube-proxy} Warning BackOff     Back-off restarting failed docker container
  4m    10s 18  {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

是的，我看到_that_它是崩溃循环，但是你能给出例如kubectl -n kube-system logs kube-proxy-w0ng5吗？
所以我们实际上看到了原因_why_ :smile:

嘿，那太棒了:)
root@3551807cba77 :/# kubectl -n kube-system 日志 kube-proxy-w0ng5

I0110 18:29:01.705993       1 server.go:215] Using iptables Proxier.
W0110 18:29:01.706933       1 proxier.go:254] clusterCIDR not specified, unable to distinguish between internal and external traffic
I0110 18:29:01.706947       1 server.go:227] Tearing down userspace rules.
I0110 18:29:01.712693       1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_max' to 262144
I0110 18:29:01.712927       1 conntrack.go:66] Setting conntrack hashsize to 65536
write /sys/module/nf_conntrack/parameters/hashsize: operation not supported

我可以通过一种解决方法来修复它：设置--conntrack-max-per-core=0然后重新启动代理。 0-val 跳过重新配置 nf_conntrack_max 并保持原样 (65536)。 我像这样注入启动参数：

首先进入docker容器：
docker exec -it master bash

然后应用修复：

kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'

现在，当我稍后执行kubectl apply -f weave.yaml时，我在 Weave 上获得了 CrashLoop，以下是 weave pod 的日志输出：
/proc/sys/net/bridge/bridge-nf-call-iptables not found
我也尝试从 kube-proxy 参数--proxy-mode=userspace但结果相同。

我认为这将解决编织问题： https :

@andersla是的，这似乎解决了问题。 您可以尝试从 HEAD 构建吗？
例如，您可以使用来自 HEAD~ish 的luxas/weave-(kube|npc):v1.9.0-alpha.5图像。
让我知道它是否有效，请在此处准确评论您现在正在做什么（shell 命令、Dockerfile、其他脚本等），以便其他人可以利用它。

我使用了来自 weaveworks/weave-kube 的最新图像

我还使用了最新的 yaml-template https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml

不幸的是 kube-dns 不起作用（它在 ContainerCreating 中很常见。启动 weave 后来自 kubelet 的错误消息是：

an 15 16:14:30 7c12205804da kubelet[540]: I0115 16:14:30.443327     540 operation_executor.go:917] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/c23fb73d-db39-11e6-b84d-0242b1ac1840-default-token-142vd" (spec.Name: "default-token-142vd") pod "c23fb73d-db39-11e6-b84d-0242b1ac1840" (UID: "c23fb73d-db39-11e6-b84d-0242b1ac1840").
Jan 15 16:14:31 7c12205804da kubelet[540]: E0115 16:14:31.381741     540 docker_manager.go:373] NetworkPlugin cni failed on the status hook for pod 'kube-dns-2924299975-9gjcg' - Unexpected command output Device "eth0" does not exist.
Jan 15 16:14:31 7c12205804da kubelet[540]:  with error: exit status 1

如果我只启动主节点而不加入另一个节点，那么当我应用 weave.yaml 时 kubedns 就可以了

我还在 Vagrant 安装上使用最新的 weave-kube 测试了 weave.yaml，而不是在我的 docker-experiment 中，然后一切正常。

这是我用于kubectl apply -f weave.yaml的 weave.yaml

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: weave-net
  namespace: kube-system
spec:
  template:
    metadata:
      labels:
        name: weave-net
      annotations:
        scheduler.alpha.kubernetes.io/tolerations: |
          [
            {
              "key": "dedicated",
              "operator": "Equal",
              "value": "master",
              "effect": "NoSchedule"
            }
          ]
    spec:
      hostNetwork: true
      hostPID: true
      containers:
        - name: weave
          image: weaveworks/weave-kube:latest
          imagePullPolicy: Always
          command:
            - /home/weave/launch.sh
          livenessProbe:
            initialDelaySeconds: 30
            httpGet:
              host: 127.0.0.1
              path: /status
              port: 6784
          securityContext:
            privileged: true
          volumeMounts:
            - name: weavedb
              mountPath: /weavedb
            - name: cni-bin
              mountPath: /host/opt
            - name: cni-bin2
              mountPath: /host/home
            - name: cni-conf
              mountPath: /host/etc
            - name: dbus
              mountPath: /host/var/lib/dbus
          resources:
            requests:
              cpu: 10m
        - name: weave-npc
          image: weaveworks/weave-npc:latest
          imagePullPolicy: Always
          resources:
            requests:
              cpu: 10m
          securityContext:
            privileged: true
      restartPolicy: Always
      volumes:
        - name: weavedb
          emptyDir: {}
        - name: cni-bin
          hostPath:
            path: /opt
        - name: cni-bin2
          hostPath:
            path: /home
        - name: cni-conf
          hostPath:
            path: /etc
        - name: dbus
          hostPath:
            path: /var/lib/dbus

嘿伙计们，我遇到了这个线程，它吓坏了！ 好东西。

我真的很想将这种方法用于 CI 来对抗我们的 repo（老实说，这相当复杂）。 我们有一个 Helm/Tiller 要求来启动相当多的 CI 图表。 你们中有没有人遇到过这个问题，或者有什么建议可以让它继续下去？ 在这种情况下，Tiller 似乎在呕吐：

root<strong i="7">@JINKITNIX05</strong>:~/openstack-helm# kubectl logs tiller-deploy-3299276078-6kdzw -n kube-system
Error from server (BadRequest): the server rejected our request for an unknown reason (get pods tiller-deploy-3299276078-6kdzw)
root<strong i="8">@JINKITNIX05</strong>:~/openstack-helm# 

我可能会尝试使用其他 SDN。 到目前为止，我们一直在使用 Calico，因为 L3 在 hacky 情况下更容易解决问题，但是如果 Weave 更好（因为它是 L2）......我会尝试任何让我们通过 Tiller 问题的方法。 我认为 Tiller 不高兴，因为在一天结束时，它似乎与 127.0.0.1 相关联……而且我在过去测试其他东西时已经看到这会导致问题。 任何输入都会很棒。 再一次，对于那些搞事情的人来说真的很棒！ 谢谢你！！

你好！ 太好了，我们有更多的人希望它起作用。 我没有使用印花布的经验。 在云上，我们运行 Weave，这就是我想要在这个项目上工作的原因。 但是我被卡住了，没有时间进一步挖掘为什么当我如上所述应用 Wea​​ve 时 kube-dns 没有出现。

现在最新的稳定编织比以前工作得更好......

kubectl apply -f https://git.io/weave-kube

..但不幸的是，kube-dns 仍然没有出现同样的问题，卡在 ContainerCreating 中：

root<strong i="9">@18a7d1ec5124</strong>:/# kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY     STATUS              RESTARTS   AGE
kube-system   dummy-2088944543-pvvdx                 1/1       Running             0          5m
kube-system   etcd-18a7d1ec5124                      1/1       Running             0          4m
kube-system   kube-apiserver-18a7d1ec5124            1/1       Running             2          5m
kube-system   kube-controller-manager-18a7d1ec5124   1/1       Running             0          4m
kube-system   kube-discovery-1769846148-6tv4l        1/1       Running             0          5m
kube-system   kube-dns-2924299975-4608d              0/4       ContainerCreating   0          5m
kube-system   kube-proxy-k0stq                       1/1       Running             0          4m
kube-system   kube-proxy-tnm8h                       1/1       Running             0          4m
kube-system   kube-scheduler-18a7d1ec5124            1/1       Running             0          4m
kube-system   weave-net-mff6t                        2/2       Running             0          3m
kube-system   weave-net-t7zcl                        2/2       Running             0          3m

应用编织后，此错误消息停止：
Feb 04 18:06:57 18a7d1ec5124 kubelet[252]: E0204 18:06:57.125434 252 pod_workers.go:184] Error syncing pod 7dc68091-eb04-11e6-a321-02425e578ba1, skipping: failed to "SetupNetwork" for "kube-dns-2924299975-4608d_kube-system" with SetupNetworkError: "Failed to setup network for pod \"kube-dns-2924299975-4608d_kube-system(7dc68091-eb04-11e6-a321-02425e578ba1)\" using network plugins \"cni\": cni config unintialized; Skipping pod"

相反，一旦我看到：

Feb 04 18:06:59 18a7d1ec5124 kubelet[252]: E0204 18:06:59.615375 252 docker_manager.go:373] NetworkPlugin cni failed on the status hook for pod 'kube-dns-2924299975-4608d' - Unexpected command output Device "eth0" does not exist. Feb 04 18:06:59 18a7d1ec5124 kubelet[252]: with error: exit status 1

如果我使用 Flannel 作为网络插件，它会起作用。

docker exec -it master bash

curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

因此，如果您使用 Flannel，则一切正常，这是完整的设置：

Dockerfile：

FROM ubuntu:xenial-20161213

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -qq

RUN apt-get install -y \
    apt-transport-https \
    apt-utils \
    ca-certificates \
    curl \
    dialog \
    python \
    daemon \
    vim \
    jq

# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
  rm -f /lib/systemd/system/multi-user.target.wants/*;\
  rm -f /etc/systemd/system/*.wants/*;\
  rm -f /lib/systemd/system/local-fs.target.wants/*; \
  rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
  rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
  rm -f /lib/systemd/system/basic.target.wants/*;\
  rm -f /lib/systemd/system/anaconda.target.wants/*;

# install docker (after removing unwanted systemd)
RUN apt-get install -y \
    docker.io

RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'

RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
  kubelet \
  kubernetes-cni \
  kubectl

RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
  kubeadm; exit 0

# Create volume for docker
VOLUME /var/lib/docker

使用以下命令构建它：
docker build -t kubeadm_docker .

然后运行：
docker run -it --privileged=true --name=master -h master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init

等待几 (10-15) 秒，直到 systemd 和 docker 启动并运行

然后我在正在运行的容器中启动 kubeadm：
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

当它启动时，我启动第二个“工人”节点：
docker run -it --privileged=true --name=node -h node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init

几秒钟后（直到 systemd 和 docker 启动）加入 master：
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

当他们加入后， - 输入 master 并应用解决 kube-proxy 崩溃的方法：
docker exec -it master bash

kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'

最后应用法兰绒覆盖网络：
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

在此设置中，我在 Kubernetes 中安装 Helm、Traefic 或 GlusterFS 没有问题:)

kubeadm-dind-cluster基本上完成了上一条评论中概述的内容，提供了自动化，因此您不必手动键入命令（尽管到目前为止它使用 CNI 桥接插件和一些 hacks 而不是 flannel，但我会解决这个问题很快）。
它还可以轻松地从本地源构建 k8s 组件和 kubeadm，并在您启动的集群中使用二进制文件。 此外，我在处理它时遇到了一些不明显的问题，例如 agetty 占用 100% CPU 并导致 docker 崩溃，除非您小心禁用它。

kubeadm-dind-cluster 中的一些变化很快就会到来：

• 为 k8s master 修复它，kube-proxy 在那里坏了
• 支持预构建图像（我还将发布多个此类图像），因此只需一个脚本即可启动集群。 这可能对使用 k8s 的各种项目中的 CI 有用
• 缓存 Docker 数据目录以加快集群重启
• 除了桥接之外，还支持 CNI 实现

kubeadm-dind-cluster 还为 e2e 测试提供自动化。 它的另一个有趣特征是您可以使用相同的远程 docker 引擎来构建 k8s 和运行 kubeadm-dind-cluster，而无需复制二进制文件（它直接从构建数据容器中提取它们），如果您正在工作，这可能很重要通过慢速连接使用远程 docker。

...忘记提及它为您配置本地 kubectl，因此您无需在主容器上执行docker exec即可访问您的集群。

正如我已经提到的，虽然 DIND 表面上看起来很容易，但您可能会遇到一些意想不到的问题。 一些问题已经在 kubeadm-dind-cluster 和它使用的基础镜像中得到解决。 例如，您需要进行一些挂载，还需要使用STOPSIGNAL SIGRTMIN+3并抵制将/sbin/init用作ENTRYPOINT的诱惑，而 vfs 驱动程序有时会很慢。 所以......这里是龙;）

@ivan4th感谢您使用 kubeadm 和 dind 所做的所有工作:)
你能打开一个新的 issue 来引用这个 issue，我们可以讨论将 kubeadm-dind-cluster 合并到这个 repo 中所需的 MVP 吗？

在快速查看之后，我发现了一些我们可能想要在可能的 MVP 之前做的点：

• 理想情况下，它应该用 Go 编写——我通常认为我们正试图摆脱 Bash，所以 Go 是我认为 Go 的新项目的方式:)
• debian 基础应该基于 gcr.io/google-containers/debian-base-$(ARCH):0.1
  
  
  
  • 最好将 dind 的基本映像发布到 gcr.io
  
  
• 它应该适用于像 kubeadm 这样的多个拱门
• 您应该能够提供自己的二进制文件，但通常应该从 CI 下载，该 CI 每小时发布所有拱门的二进制文件
• 它应该使用 CNI——网络提供商可以交换
• 它应该通过配置文件公开它的配置选项，比如 kubeadm 可以将配置文件作为选项的输入
• 它应该只支持 kubeadm v1.6+

你怎么认为？ 感谢您的出色开始，我迫不及待地想将其集成到 kubeadm 官方的内容中：+1：

cc @jbeda @lukemarsden @errordeveloper @mikedanese @timothysc @sttts

感谢您的精彩开始，我迫不及待地想将它集成到 kubeadm 官方的东西中

如果我们可以开发构建，kubeadm-local-up-cluster 那就太棒了。

@ivan4th @luxas这是什么情况？

我真的不知道... @ivan4th

@杰米汉纳福德

• 到目前为止，我的 Go 重写被推迟了，因为我还需要处理其他项目
• kdc 支持不同的 CNI 实现（Weave、Calico、Flannel 和默认的普通 CNI 桥）
• 支持多种架构尚不存在，但完全可行
• 图像中使用的二进制文件默认取自 k8s 版本，但您可以构建自己的，或者稍作努力，基于您自己单独构建的二进制文件制作图像
• 它确实支持配置文件，但截至目前它实际上是一组环境变量
• 基本映像仍然是 ubuntu 但我们将切换到 debian
• 我们支持 1.6，我将在下周初添加对 1.7 的支持

总体而言， kdc在 IMO 的当前形式中非常有用。 它还有自己的基于 Travis 的公共 CI（顺便说一句，如果有兴趣的话，我也成功地在 CircleCI 上运行了 DIND）

@luxas也许我们可以使用@andersla的解决方案而不是完整的 DIND 集群？ 如果是这样，我们是否需要在任何地方托管 Docker 镜像，或者只是记录 Dockerfile 的样子？

如果我们能在 1.9 版中解决此问题，那就太好了

我没有周期来解决这个问题。 如果还有其他人，可以请做！

@jamiehannaford 的问题是，大部分“完整”的 DIND 集群都致力于处理由“简单”的 DIND 使用引起的众多问题。 这些有时可能很模糊，例如参见https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 （我想我需要为此提交 k8s 的修复程序）。 从kubeadm-dind-cluster 开始，它仍然非常有用，我尝试使其保持最新状态（ @danehans和@pmichali将它用于 k8s IPv6 e2e 测试， Virtlet使用它在 CircleCI 上运行它的 e2e 测试），虽然我花了很多时间在其他项目上，所以我还没有设法用 Go 重写它。

我们昨天在 SIG 会议上讨论了这个问题，我们将关闭这个问题。
在可预见的未来，核心 kubeadm 团队不会开发和维护成熟的 DIND 解决方案。 我们非常高兴社区提供了这些解决方案，就像@ivan4th在 Mirantis 项目上的辛勤工作一样。 如果我们找到一个很好的地方来记录使用该项目的可能性，我个人认为可以引用它。 谢谢！