Kubeadm: コンテナでkubeadmを実行する方法を文書化し、スクリプトを提供する

_ 2016年10月27日18:14の@luxasから_

cc @errordeveloperと@marunは、コンテナー内でsystemdを実行しているため

@anderslaコンテナ内でsystemdをこのように実行することは、ootbでサポートされていないことに注意してください。ただし、kubeadmをそのようにテストするのに最適なので、自由に試してみてください。

_ 2016年10月28日の@zreigzから7：36_

よろしければ、詳しく調べて修正してみます。

_ 2016年10月28日8:48の@anderslaから_

@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)

_ 2016年10月28日9:10の@zreigzから_

私はそれを再現し、これに取り組んできました

_ 2016年10月31日の@zreigzから7：24_

2つの問題があります。

最初のもの： ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
Ubuntuシステムでは、/ bin / shはbashではなくダッシュであり、ダッシュは二重角かっこキーワードをサポートしていません。 良い点は、この問題がマスターブランチで修正され、まもなく利用可能になることです： https ：

2番目のものはそれほど些細なことではありません。 コンテナでのsystemctlの実行はFailed to get D-Bus connection失敗します。 systemdがコンテナで正しく動作しないようです。 今私はこれに取り組んでいます

_ 2016年10月31日の@anderslaから7：42_

素晴らしい！
kubeadmのインストールにsystemd / systemctlが必要な理由がわかりませんか？

_ 2016年10月31日の@zreigzから7：47_

これらの2行のため： https ：

systemctl daemon-reload
systemctl restart kubelet

最初の行で失敗します

_ 2016年10月31日の@zreigzから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.

_ 2016年10月31日の@zreigzから7：52_

それを機能させるためのいくつかの構成手順がありますが、最初に試してみる必要があります。 何か見つけたらお知らせします。

_ 2016年11月2日の@zreigzから7：19_

朗報です。 私はなんとかすべての問題を解決しました。 最後のテストが必要です。Dockerコンテナでkubeadmを実行する方法のソリューションを投稿します。

_ 2016年11月2日の@anderslaから7：23_

素晴らしい！ 準備ができ次第、テストをお手伝いします。 -今週の残りは休日ですが:)

_ 2016年11月2日の@zreigzから10：13_

Dockerコンテナへのkubeadmのインストールに関して2つの主要な問題があります。 1つ目は、コンテナで実行されているsystemdです。 2つ目は、コンテナー内のインストール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

すべてがローカルマシンと同じように機能します。
幸運を ：）

_ 2016年11月17日の@SuperStevenZから7：21_

@zreigzそれは私の同じ問題を解決しました、ありがとう！

_ 2016年11月17日の@zreigzから7：30_

問題ない ：）

docker-in-dockerのものを使用してCIを設定する必要があります。

@errordeveloper @zreigzこれを
少なくとも、コンテナ内でkubeadmを実行する方法をどこかに文書化する必要があります...

私にはいいですね。 確かに、これらすべてのものをDockerイメージに加えて、マスターとノードを区別するためのいくつかのconfig / startスクリプトを配置する必要があります。 良いスタートは、kubernetes / kubeadm-dockerのようなプロジェクトを作成することです。 Dockerfile、スクリプト、ドキュメントにも適した場所です

最初にzreigz /の下でプライベートプロジェクトとして作成し、最終的にはそのコードをこのリポジトリにマージします。

しかし、最初に、あなた自身のスペースでプロトタイプを作成し、それがどのように行われるかを見ていきます。

実際の担当者は@zreigzです

はい良い点です。 私はします。 来週（月曜日、火曜日）は会議中なので、水曜日から始めます。

@luxaskubeadmおよび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 AGE
kube-systemダミー-2088944543-17sey1 / 1ランニング011m
kube-system etcd-8dd8c92c6c381 / 1ランニング212m
kube-system kube-apiserver-8dd8c92c6c381 / 1ランニング412m
kube-system kube-controller-manager-8dd8c92c6c381 / 1実行中211m
kube-system kube-discovery-1150918428-m506w1 / 1ランニング011m
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-8dd8c92c6c381 / 1ランニング210m

ネットワークポリシーをインストールしてみました
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 AGE
kube-systemダミー-2088944543-17sey1 / 1ランニング046m
kube-system etcd-8dd8c92c6c381 / 1ランニング246m
kube-system kube-apiserver-8dd8c92c6c381 / 1ランニング446m
kube-system kube-controller-manager-8dd8c92c6c381 / 1ランニング245m
kube-system kube-discovery-1150918428-9m6rr0 / 1保留中03m
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-8dd8c92c6c381 / 1ランニング244m
kube-system weave-net-iv0bc 0/2 ContainerCreating 0 49s
情報：1つの完成したオブジェクトがポッドリストに表示されませんでした。 --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

systemdとdockerが起動して実行されるまで、数秒（10〜15）待ちます。

次に、実行中のコンテナー内でkubeadmを開始します。
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

それが開始されると、2番目の「ワーカー」ノードを開始します。

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

現在、kube-proxyが失敗し、CrashLoopBackOffに入るため、Dockerネットワークに問題があります。

上記のdockerを実行するときに代わりに--net=host設定すると、kube-proxyとすべてのポッドが正常に起動します-しかし、IPを使用してdockerネットワークでコンテナーを実行する必要があるため、これはオプションではありません。 NS

以前、ホストと同じプロセスで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について不平を言いますが、それは私がまだ織り始めていないためです。

log.zip

これが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)"

はい、クラッシュループしているようですが、たとえばkubectl -n kube-system logs kube-proxy-w0ng5できますか？
だから私たちは実際に理由を見る_why_：smile：

ねえ、それは素晴らしいです:)
root @ 3551807cba77 ：/＃kubectl -nkube-システムログ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実行すると、代わりにCrashLoop on Weaveが取得されます。以下は、ウィーブポッドからのログ出力です。
/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画像を使用できます。
それが機能するかどうかを知らせてください。他の人がそれを利用できるように、現在行っていること（シェルコマンド、Dockerfile、その他のスクリプトなど）をここに正確にコメントしてください。

weaveworks / weave-kubeの最新画像を使用しました

最新のyamlテンプレートも使用しましたhttps://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml

残念ながら、kube-dnsは機能しませんでした（ContainerCreatingでは問題があります。ウィーブ開始後の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が正常に起動しました

また、docker-experimentではなくVagrantインストールでweave.yamlを最新のweave-kubeでテストしたところ、すべて機能しました。

これは私が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に使用したいと思っています（正直なところ、かなり複雑です）。 CI用にかなりの数のチャートを起動するためのヘルム/ティラー要件があります。 これに遭遇した人はいますか、またはこれを実行するための提案がありますか？ この状況では、耕うん機はそれ自体全体に吠えているようです。

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で試すかもしれません。 L3はハッキーな状況でのトラブルシューティングが少し簡単なので、これまでCalicoを使用してきましたが、Weaveの方が優れている場合（L2であるため）... Tillerの問題を乗り越えるために何でも試してみます。 結局のところ、Tillerは127.0.0.1に関連付けられているように見えるので、Tillerは不幸だと思います...そして、過去に他のことをテストしたときに問題が発生するのを見てきました。 どんな入力でも素晴らしいでしょう。 繰り返しますが、物事をハッキングしている人々にとって本当に素晴らしい小道具です！ ありがとうございました！！

やあ！ これが機能することを望んでいる人が増えたことは素晴らしいことです。 三毛猫の経験はありません。 クラウド上でWeaveを実行しているので、このプロジェクトに取り組みたいと思っていました。 しかし、私は立ち往生していて、上記のようにWeaveを適用したときに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 -

したがって、フランネルを使用している場合は、すべてが機能しています。完全なセットアップは次のとおりです。

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

systemdとdockerが起動して実行されるまで、数秒（10〜15）待ちます。

次に、実行中のコンテナー内でkubeadmを開始します。
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

それが開始されると、2番目の「ワーカー」ノードを開始します。
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が起動するまで）マスターに参加します。
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ブリッジプラグインを使用していますが、これはかなり修正しますすぐ）。
また、ローカルソースからk8sコンポーネントとkubeadmの両方を簡単に構築し、開始したクラスターでバイナリを使用することもできます。 さらに、作業中に発生した明らかでない問題がいくつかありました。たとえば、agettyが100％CPUを消費し、無効にしない限りDockerがクラッシュするなどです。

kubeadm-dind-clusterで間もなく登場する変更の一部：

• k8sマスター用に修正し、kube-proxyが壊れました
• ビルド済みのイメージのサポート（このようなイメージもいくつか公開します）なので、クラスターを開始するには1つのスクリプトで十分です。 これは、k8sを使用するさまざまなプロジェクトのCIに役立つ場合があります
• クラスターの再起動を高速化するためのDockerデータディレクトリのキャッシュ
• ブリッジ以外のCNI実装のサポート

kubeadm-dind-clusterは、e2eテストの自動化も提供します。 もう1つの興味深い特徴は、バイナリをコピーバックせずに（ビルドデータコンテナから直接プルする）、k8のビルドとkubeadm-dind-clusterの実行の両方に同じリモートDockerエンジンを使用できることです。これは、作業している場合に重要になる可能性があります。低速接続でリモートDockerを使用。

...ローカルkubectlを構成することを忘れたため、クラスターにアクセスするためにマスターコンテナーでdocker execを実行する必要はありません。

すでに述べたように、DINDは表面上は簡単に見えるかもしれませんが、予期しない問題が発生する可能性があります。 いくつかの問題は、kubeadm-dind-clusterとそれが使用するベースイメージですでに修正されています。 例えばあなたがする必要があるいくつかのマウントを行うにも、あなたがする必要があり、使用STOPSIGNAL SIGRTMIN+3し、誘惑に抵抗を使用するために/sbin/initとENTRYPOINT 、およびVFSドライバの回で、非常に遅くなることがあります。 だから...ここにドラゴンがいる;）

@ ivan4thkubeadmとdindで行ってきたすべての作業に感謝します:)
kubeadm-dind-clusterをこのリポジトリにマージするために必要なMVPについて話し合うことができる、この問題を参照する新しい問題を開くことができますか？

すばやく調べた後、MVPの前にやりたいことがいくつかあります。

• 理想的にはGoで書く必要があります-私たちは一般的にBashから離れようとしていると思うので、Goは新しいプロジェクトのためにGoする方法だと思います:)
• Debianベースはgcr.io/google-containers/debian-base-$(ARCH):0.1に基づいている必要があります
  
  
  
  • dindのベースイメージは、理想的にはgcr.ioに公開する必要があります
  
  
• kubeadmのような複数のアーチで機能するはずです
• 独自のバイナリを提供できるはずですが、ほとんどの場合、すべてのアーチのバイナリを1時間ごとに公開するCIからダウンロードする必要があります。
• CNIを使用する必要があります-ネットワークプロバイダーは交換可能です
• kubeadmがオプションの入力として構成ファイルを取得できるように、構成ファイルを介して構成オプションを公開する必要があります
• kubeadm v1.6 +のみをサポートする必要があります

どう思いますか？ 素晴らしいスタートをありがとう、私はこれを実際にkubeadmの公式のものに統合するのが待ちきれません：+1：

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

素晴らしいスタートをありがとう、私はこれを実際にkubeadmの公式のものに統合するのが待ちきれません

devel-build、kubeadm-local-up-clusterができれば、それは素晴らしいことです。

@ ivan4th @luxasこれの状況はどうですか？

よくわかりません... @ ivan4th

@jamiehannaford

• 今のところ、他のプロジェクトにも取り組む必要があるため、Goの書き換えが遅れました。
• kdcは、さまざまなCNI impl（Weave、Calico、Flannel、およびデフォルトのプレーンCNIブリッジ）をサポートしています。
• 複数のアーキテクチャをサポートすることはまだここにはありませんが、かなり実行可能です
• イメージで使用されるバイナリは、デフォルトではk8sリリースから取得されますが、独自にビルドすることも、少しの努力で、独自にビルドしたバイナリに基づいてイメージを作成することもできます。
• 設定ファイルをサポートしていますが、現時点では実際にはenv変数のセットです
• ベースイメージはまだubuntuですが、debianに切り替えます
• 1.6をサポートしており、来週初めに1.7のサポートを追加します

全体として、 kdcは現在の形式のIMOで非常に使用可能です。 また、Travisに基づく独自のパブリックCIもあります（ところで、興味があれば、CircleCIでDINDを実行することにも成功しました）

@luxas完全なDINDクラスターの代わりに@anderslaのソリューションを使用できるかもしれませんか？ もしそうなら、Dockerイメージをどこにでもホストする必要がありますか、それともDockerfileがどのように見えるかを文書化する必要がありますか？

1.9でこの問題の修正を取得できれば素晴らしいと思います

これに取り組むサイクルはありません。 他の誰かが、してください！

@jamiehannafordの問題は、「完全な」DINDクラスターの多くが、「単純な」DINDの使用から発生する多数の問題の処理に専念していることです。 これらは時々非常にあいまいな場合があります。たとえば、 https ： ください（これについては、k8sの修正を送信する必要があると思います）。 kubeadm-dind-clusterの時点では、まだかなり使用可能であり、最新の状態に保つようにしています（ @danehansと@pmichaliはk8s IPv6 e2eテストに使用しており、 Virtletは

これについては昨日のSIGミーティングで話し合ったので、問題を解決します。
本格的なDINDソリューションの開発と維持は、予見可能な将来において、コアkubeadmチームの範囲内ではありません。 @ ivan4thのMirantisプロジェクトへの懸命な