Kubeadm: Dokumentieren Sie die Vorgehensweise und stellen Sie Skripte für die Ausführung von kubeadm in einem Container bereit

_Von @luxas am 27. Oktober 2016 18:14_

cc @errordeveloper und @marun, da sie systemd in einem Container ausgeführt haben

@andersla Passen Sie auf, dass das Ausführen von systemd auf diese Weise in einem Container nicht von ootb unterstützt wird, aber Sie können es gerne ausprobieren oder hacken, da es großartig wäre, um kubeadm auf diese Weise zu testen

_Von @zreigz am 28. Oktober 2016 7:36_

Wenn es Ihnen nichts ausmacht, würde ich gerne genauer hinschauen und versuchen, das Problem zu beheben.

_Von @andersla am 28. Oktober 2016 8:48_

@zreigz Bitte tun!
So versuche ich es zu installieren:

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

Und dann:

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

Und dies ist der Fehler, den ich bekomme, wenn kubeadm installiert wird:

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)

_Von @zreigz am 28. Oktober 2016 9:10_

Ich habe es reproduziert und habe daran gearbeitet

_Von @zreigz am 31. Oktober 2016 7:24_

Es gibt zwei Probleme.

Der erste: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
Auf Ubuntu-Systemen ist /bin/sh dash, nicht bash, und dash unterstützt nicht das Schlüsselwort double Klammer. Das Gute ist, dass das Problem im Master-Zweig behoben ist und bald verfügbar sein sollte: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40

Der zweite ist nicht so trivial. Das Ausführen von systemctl im Container schlägt mit Failed to get D-Bus connection fehl. Es scheint, als ob systemd im Container nicht richtig funktioniert. Jetzt arbeite ich daran

_Von @andersla am 31. Oktober 2016 7:42_

Groß!
Ich verstehe einfach nicht, warum die Installation von kubeadm überhaupt systemd/systemctl benötigt?

_Von @zreigz am 31. Oktober 2016 7:47_

Wegen dieser beiden Zeilen: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25

systemctl daemon-reload
systemctl restart kubelet

Es schlägt in der ersten Zeile fehl

_Von @zreigz am 31. Oktober 2016 7:48_

das ist die erklärung:

# 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.

_Von @zreigz am 31. Oktober 2016 7:52_

Es gibt einige Konfigurationsschritte, damit es funktioniert, aber ich muss es zuerst versuchen. Wenn ich etwas finde melde ich mich.

_Von @zreigz am 2. November 2016 7:19_

Gute Nachrichten. Ich habe es geschafft, alle Probleme zu lösen. Es braucht letzte Tests und ich werde eine Lösung posten, wie man kubeadm im Docker-Container ausführt

_Von @andersla am 2. November 2016 7:23_

Super! Ich werde beim Testen helfen, sobald es fertig ist! - obwohl ich den Rest der Woche im Urlaub bin :)

_Von @zreigz am 2. November 2016 10:13_

Bei der Installation von kubeadm im Docker-Container gibt es zwei Hauptprobleme. Zuerst wird systemd im Container ausgeführt. Zweitens ist die Installation Docker im Container. Erfolgreich wurden die Probleme behoben. Hier ist das Dockerfile, das verwendet werden muss, um das Ubuntu-Image vorzubereiten

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

Ich verwende diesen Befehl, um das Image in dem Verzeichnis zu erstellen, das das Dockerfile enthält

docker build -t kubeadm_docker .

Jetzt können Sie das vorbereitete Image ausführen und die kubeadm-Installation abschließen.
Verwenden Sie den folgenden Befehl, um das Image kubeadm_docker auszuführen:

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

Laufende Container-ID finden

$ 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

Jetzt können Sie die Container-Konsole öffnen:

docker exec -it 7dd73057620d /bin/bash

Dies ist Ihr Skript (mit kleinen Modifikationen), um kubeadm zu installieren

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

Und endlich kannst du ausführen

# kubeadm init

Alles funktioniert genauso wie auf dem lokalen Computer.
Viel Glück :)

_Von @SuperStevenZ am 17. November 2016 7:21_

@zreigz Das hat das gleiche Problem von mir gelöst, danke!

_Von @zreigz am 17. November 2016 7:30_

Kein Problem :)

Wir sollten eine CI mit Docker-in-Docker-Sachen einrichten.

@errordeveloper @zreigz Können Sie das übernehmen?
Zumindest sollten wir irgendwo dokumentieren, wie man kubeadm in einem Container ausführt...

Klingt gut für mich. Natürlich müssen wir all diese Dinge in das Docker-Image sowie einige Konfigurations- / Startskripte einfügen, um zwischen Master und Node zu unterscheiden. Ein guter Anfang wäre, ein Projekt wie kubernetes/kubeadm-docker dafür zu erstellen. Es wäre auch der richtige Ort für Dockerfile, Skripte und Dokumentation

Erstellen Sie das zuerst als privates Projekt unter zreigz/ und schließlich werden wir diesen Code wahrscheinlich in dieses Repository einbinden.

Aber zuerst Prototypen in Ihrem eigenen Raum und wir werden sehen, wie es läuft.

Echter Rechtsnachfolger ist @zreigz

Ja guter Punkt. Ich werde es tun. Nächste Woche (Montag, Dienstag) bin ich auf Konferenz, also fange ich am Mittwoch an.

@luxas Ich habe mich gefragt, wie ich kubeadm- und kubernetes-cni-Pakete bereitstellen soll. Soll ich es aus den aktuellen Quellen bauen (um die neueste Implementierung testen zu können) oder einfach die neueste Version aus dem Repository herunterladen? Für CI-Zwecke sollten wir den aktuellen Status des Codes haben, um ihn testen zu können, oder brauchen wir ihn nur, um die Release-Version zu testen?

Hallo, danke für den Fix, aber nach kubeadm init bekomme ich immer noch ein Problem. Ich erhalte 0/3 auf DNS, DNS scheint überhaupt nicht zu laufen

Alle 2.0s: kubectl get pods --all-namespaces Fr Dec 16 17:00:50 2016

NAMESPACE NAME BEREIT STATUS NEUSTART ALTER
kube-system dummy-2088944543-17sey 1/1 Laufend 0 11m
kube-system etcd-8dd8c92c6c38 1/1 Laufend 2 12m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Läuft 4 12m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Läuft 2 11m
kube-system kube-discovery-1150918428-m506w 1/1 Läuft 0 11m
kube-system kube-dns-654381707-vuijm 0/3 ContainerErstellen 0 11m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Laufen 2 10m

versucht, Netzwerkrichtlinie zu installieren
root@8dd8c92c6c38 :/# kubectl apply -f calico.yaml
der Pfad "calico.yaml" existiert nicht
root@8dd8c92c6c38 :/# kubectl create -f calico.yaml
der Pfad "calico.yaml" existiert nicht
root@8dd8c92c6c38 :/# kubectl apply -f kube-flannel.yml
der Pfad "kube-flannel.yml" existiert nicht

root@8dd8c92c6c38 :/# kubectl apply -f https://git.io/weave-kube
daemonset "weave-net" erstellt
root@8dd8c92c6c38 :/# kubectl get pods --all-namespaces
NAMESPACE NAME BEREIT STATUS NEUSTART ALTER
kube-system dummy-2088944543-17sey 1/1 Laufen 0 46m
kube-system etcd-8dd8c92c6c38 1/1 Laufen 2 46m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Läuft 4 46m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Läuft 2 45m
kube-system kube-discovery-1150918428-9m6rr 0/1 Ausstehend 0 3m
kube-system kube-dns-654381707-vuijm 0/3 ContainerErstellen 0 45m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Laufen 2 44m
kube-system weave-net-iv0bc 0/2 ContainerErstellen 0 49s
Info: 1 abgeschlossene(s) Objekt(e) wurde(n) nicht in der Pod-Liste angezeigt. Übergeben Sie --show-all, um alle Objekte anzuzeigen.

Hallo nochmal @zreigz
Jetzt hatte ich endlich Zeit, damit weiterzumachen und es zu testen - ich schaffe es fast, aber es gibt einen Fehler, dass Docker den vfs-Speichertreiber auswählt (wahrscheinlich, weil er aufs nicht zusätzlich zu aufs verwenden kann? Aber wie du den Workaround beschreibst oben montiere ich die äußere docker .sock in die innere docker damit es möglich sein sollte mit aufs zu schreiben?
docker info Auf meinem Host-Rechner heißt es, dass der Speichertreiber ausgeführt wird. - Wenn ich jedoch docker info im Docker-Container mit Kubernetes mache, heißt es, dass er den vfs-Speichertreiber verwendet.
Irgendwelche Ideen, warum ich beim Laufen das folgende Problem bekomme
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>:/# 

Noch ein paar Infos, nachdem ich ein bisschen mehr probiert habe.
Ich habe den Docker-Speichertreiber auf dem Host in "Overlay" geändert. Dann hat docker inside docker aufs als Fahrer gewählt und ich habe die "Pre-Flight Checks" bestanden, aber jetzt stecke ich fest
[apiclient] Created API client, waiting for the control plane to become ready

Bei einigen anderen Tests stellte ich fest, dass Docker nicht denselben Speichertreiber auswählte, als es als Dienst über /sbin/init gestartet wurde
Wenn ich das Docker-Image auf diese Weise ausgeführt habe, wurde nicht derselbe Treiber wie der Host gestartet (wie oben erwähnt):
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

Wenn ich es ohne /sbin/init und nicht als Daemon gestartet habe:
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 dann hat Docker den gleichen Speichertreiber wie der Host ausgewählt (aber jetzt hat systemctrl nicht funktioniert)

Einige weitere Aktualisierungen:

Ich kann jetzt mit diesem Dockerfile einen funktionierenden kubeadm-in-docker-container erstellen:

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

Ich baue mit: docker build -t kubeadm_docker .

Und dann lauf:

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

Warten Sie einige (10-15) Sekunden, bis systemd und Docker hochgefahren sind

Dann starte ich kubeadm im laufenden Container:
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

Wenn es initiiert wird, starte ich einen zweiten "Worker" -Knoten:

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
Und nach ein paar Sekunden treten Sie dem Master bei:

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

Derzeit gibt es ein Problem mit dem Docker-Netzwerk, da kube-proxy fehlschlägt und einen CrashLoopBackOff eingibt.

Wenn ich stattdessen --net=host setze, wenn ich Docker oben ausführe, dann kommen kube-proxy und alle Pods in Ordnung - aber das ist keine Option, da ich die Container mit ihrer IP im Docker-Netzwerk laufen lassen muss: S

Ich habe zuvor auch versucht, Docker mit dem gleichen Prozess wie auf dem Host auszuführen: -v /var/run/docker.sock:/var/run/docker.sock aber ich habe es nie zum Laufen gebracht, weil, wenn der Docker im Container mit systemd gestartet wird, die Socke nicht abgeholt wird (oder so ähnlich) das).

Danke @andersla!
Können Sie einfügen, womit kube-proxy fehlschlägt?

Danke @luxas für dein Interesse!

Leider keine Details in journalctl -xeu kubelet

Dies ist alles, was ich über Kube-Proxy finde (viele Male wiederholt). Ich hänge auch das vollständige Protokoll an.

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

Das vollständige Protokoll beschwert sich auch über die kube-dns - aber das liegt daran, dass ich noch nicht mit dem Weben begonnen habe.

log.zip

Hier ist das Protokoll von 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)"

Ja, ich sehe _dass_ es ein Crashlooping ist, aber könnten Sie zB kubectl -n kube-system logs kube-proxy-w0ng5 ?
Wir sehen also tatsächlich den Grund _warum_ :smile:

Hey das ist genial :)
root@3551807cba77 :/# kubectl -n kube-system logs 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

Ich kann es mit einem Workaround beheben: Setzen von --conntrack-max-per-core=0 und dann Neustart des Proxys. Ein 0-Wert überspringt die Neukonfiguration von nf_conntrack_max und bleibt unverändert (65536). Ich füge den Startparameter wie folgt ein:

Geben Sie zuerst den Docker-Container ein:
docker exec -it master bash

dann Fix anwenden:

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'

Jetzt bekomme ich stattdessen den CrashLoop auf Weave, wenn ich später ein kubectl apply -f weave.yaml mache. Das Folgende ist die Protokollausgabe des Weave-Pods:
/proc/sys/net/bridge/bridge-nf-call-iptables not found
Ich habe auch versucht, mit dem kube-proxy-Parameter --proxy-mode=userspace aber das gleiche Ergebnis.

Ich denke, das wird das Webproblem lösen: https://github.com/weaveworks/weave/pull/2659

@andersla Ja, das scheint das Problem zu beheben. Kannst du einen Build von HEAD ausprobieren?
Sie könnten beispielsweise die luxas/weave-(kube|npc):v1.9.0-alpha.5 Bilder verwenden, die von HEAD~ish stammen.
Lassen Sie mich wissen, ob es funktioniert, und kommentieren Sie hier bitte genau, was Sie wann gerade tun (Shell-Befehle, Dockerfile, andere Skripte usw.), damit andere davon profitieren können.

Ich habe das neueste Bild von weaveworks/weave-kube verwendet

Ich habe auch das neueste Yaml-Template verwendet https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml

Leider hat kube-dns nicht funktioniert (es ist stuch in ContainerCreating. Die Fehlermeldung von kubelet nach dem Starten von Weave lautet:

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

Wenn ich nur den Master-Knoten gestartet habe und keinem anderen Knoten beigetreten bin, wurde kubedns OK angezeigt, als ich weave.yaml anwendete

Ich habe die weave.yaml auch mit dem neuesten weave-kube auf einer Vagrant-Installation und nicht in meinem Docker-Experiment getestet und dann hat alles funktioniert.

Dies ist die weave.yaml, die ich für kubectl apply -f 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

Hey Leute, ich bin auf diesen Thread gestoßen und er rockt! tolles Zeug.

Ich möchte diesen Ansatz wirklich für CI gegen unser Repo verwenden (das ehrlich gesagt ziemlich komplex ist). Wir haben eine Helm/Tiller-Anforderung, um einige Charts für CI zu starten. ist jemand von euch darauf gestoßen oder hat Vorschläge, um das in Gang zu bringen? Tiller scheint in dieser Situation über sich selbst zu kotzen:

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# 

Ich kann es mit anderen SDNs versuchen. Wir haben Calico bisher verwendet, weil L3 in hackigen Situationen etwas einfacher zu beheben ist, aber wenn Weave besser ist (da es L2) ist ... werde ich versuchen, was uns am Tiller-Problem vorbeibringt. Ich denke, Tiller ist unglücklich, weil es am Ende des Tages so aussieht, als ob es mit 127.0.0.1 verbunden ist ... und ich habe gesehen, dass dies in der Vergangenheit beim Testen anderer Dinge Probleme verursacht hat. jede Eingabe wäre erstaunlich. Nochmals, wirklich tolle Requisiten an die Leute, die die Dinge hacken! Danke schön!!

Hi! Schön, dass wir mehr Leute sind, die wollen, dass das funktioniert. Ich habe keine Erfahrung mit Kaliko. In der Cloud führen wir Weave aus, also wollte ich an diesem Projekt arbeiten. Aber ich stecke fest und hatte keine Zeit, weiter zu graben, warum kube-dns nicht auftaucht, wenn ich Weave wie oben beschrieben anwende.

Jetzt funktioniert das neueste stabile Gewebe besser als zuvor....

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

..aber leider immer noch das gleiche Problem mit kube-dns kommt nicht, steckt in 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

und nach dem Anwenden von Webart hört diese Fehlermeldung auf:
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"

und stattdessen sehe ich einmal:

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

Wenn ich Flannel stattdessen als Netzwerk-Plugin verwende, funktioniert es.

docker exec -it master bash

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

Wenn Sie also Flannel verwenden, funktioniert alles, hier ist das komplette Setup:

Docker-Datei:

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

Bauen Sie es mit:
docker build -t kubeadm_docker .

Und dann lauf:
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

Warten Sie einige (10-15) Sekunden, bis systemd und Docker hochgefahren sind

Dann starte ich kubeadm im laufenden Container:
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

Wenn es initiiert wird, starte ich einen zweiten "Worker" -Knoten:
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

Und nach ein paar Sekunden (bis systemd und Docker hochgefahren sind) treten Sie dem Master bei:
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

Wenn sie beigetreten sind, - geben Sie master ein und wenden Sie die Problemumgehung für den Absturz von kube-proxy an:
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'

Wenden Sie schließlich das Flanell-Overlay-Netzwerk an:
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

Ich hatte kein Problem damit, Helm, Traefic oder GlusterFS in Kubernetes in dieser Einstellung zu installieren :)

kubeadm-dind-cluster macht im Grunde das, was im letzten Kommentar beschrieben wurde, und bietet Automatisierung, so dass Sie die Befehle nicht manuell eingeben müssen (obwohl es ab sofort das CNI-Bridge-Plugin mit einigen Hacks anstelle von Flanell verwendet, aber das werde ich ganz beheben demnächst).
Es macht es auch einfach, sowohl k8s-Komponenten als auch kubeadm aus lokalen Quellen zu erstellen und die Binärdateien in dem von Ihnen gestarteten Cluster zu verwenden. Außerdem gab es einige nicht offensichtliche Probleme, auf die ich während der Arbeit gestoßen bin, z. B. verbrauchen 100% CPU und verursachen Docker-Abstürze, wenn Sie es nicht deaktivieren.

Einige der Änderungen, die bald in kubeadm-dind-cluster kommen:

• korrigiere es für k8s master, kube-proxy ist dort kaputt gegangen
• Unterstützung für vorgefertigte Images (ich werde auch mehrere solcher Images veröffentlichen), sodass nur ein einziges Skript ausreicht, um den Cluster zu starten. Dies kann für CI in verschiedenen Projekten nützlich sein, die k8s verwenden
• Caching von Docker-Datenverzeichnissen für schnellere Cluster-Neustarts
• Unterstützung für CNI-Implementierungen neben Bridge

kubeadm-dind-cluster bietet auch Automatisierung für e2e-Tests. Eine weitere interessante Eigenschaft ist, dass Sie dieselbe Remote-Docker-Engine sowohl zum Erstellen von k8s als auch zum Ausführen von kubeadm-dind-cluster verwenden können, ohne die Binärdateien zurückzukopieren (sie werden direkt aus dem Build-Datencontainer gezogen), was wichtig sein kann, wenn Sie arbeiten mit Remote Docker über langsame Verbindung.

... vergessen zu erwähnen, dass es lokales kubectl für Sie konfiguriert, sodass Sie nicht docker exec auf Ihrem Master-Container ausführen müssen, um auf Ihren Cluster zuzugreifen.

Wie ich bereits erwähnt habe, kann DIND zwar auf den ersten Blick einfach erscheinen, aber Sie können einige unerwartete Probleme damit haben. Einige der Probleme sind bereits in kubeadm-dind-cluster und dem verwendeten Basis-Image behoben. Zum Beispiel müssen Sie einige Halterungen tun , auch Sie müssen verwenden STOPSIGNAL SIGRTMIN+3 und die Versuchung widerstehen verwenden /sbin/init als ENTRYPOINT ziemlich langsam manchmal kann, und VFS - Treiber sein. Also... hier sind Drachen ;)

@ivan4th Danke für all die Arbeit, die du mit kubeadm und dind gemacht hast :)
Können Sie ein neues Issue eröffnen, das auf dieses Issue verweist, in dem wir das MVP besprechen können, das zum Zusammenführen von kubeadm-dind-cluster in dieses Repository erforderlich ist?

Nachdem ich schnell nachgesehen hatte, fand ich einige Punkte, die wir vielleicht vor einem möglichen MVP tun sollten:

• Es sollte idealerweise in Go geschrieben sein -- ich denke im Allgemeinen, dass wir versuchen, uns von Bash zu entfernen, also ist Go der Weg zu Go für ein neues Projekt, denke ich :)
• Die Debian-Basis sollte auf gcr.io/google-containers/debian-base-$(ARCH):0.1 basieren
  
  
  
  • Das Basis-Image für dind sollte idealerweise auf gcr.io veröffentlicht werden
  
  
• Es sollte auf mehreren Bögen wie kubeadm . funktionieren
• Sie sollten in der Lage sein, Ihre eigenen Binärdateien bereitzustellen, aber meistens sollte es von dem CI heruntergeladen werden, das stündlich Binärdateien für alle Arches veröffentlicht
• Es sollte CNI verwenden – mit austauschbaren Netzwerkanbietern
• Es sollte seine Konfigurationsoptionen über eine Konfigurationsdatei bereitstellen, wie kubeadm eine Konfigurationsdatei als Eingabe für Optionen verwenden kann
• Es sollte nur kubeadm v1.6+ unterstützen

Was denken Sie? Danke für den tollen Start, ich kann es kaum erwarten, dies tatsächlich in etwas von kubeadm offiziell zu integrieren :+1:

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

Danke für den tollen Start, ich kann es kaum erwarten, dies tatsächlich in etwas kubeadm-offizielles zu integrieren

Wenn wir kubeadm-local-up-cluster entwickeln und bauen können, wäre das fantastisch.

@ivan4th @luxas Wie ist der Status davon?

Ich weiß es nicht wirklich... @ivan4th

@jamiehannaford

• ab sofort habe ich mich mit Go rewrite verzögert, weil ich auch an anderen Projekten arbeiten muss
• kdc unterstützt verschiedene CNI-Impls (Weave, Calico, Flannel und einfache CNI-Bridge, die Standard ist)
• die Unterstützung mehrerer Architekturen ist noch nicht da, aber durchaus machbar
• Die in den Images verwendeten Binärdateien stammen standardmäßig aus der k8s-Version, aber Sie können Ihre eigenen erstellen oder mit etwas Aufwand ein Image basierend auf Ihren eigenen, separat erstellten Binärdateien erstellen
• Es unterstützt die Konfigurationsdatei, aber ab sofort ist es tatsächlich eine Reihe von env vars
• Das Basis-Image ist immer noch Ubuntu, aber wir werden zu Debian wechseln
• Wir unterstützen 1.6 und ich werde Anfang nächster Woche Unterstützung für 1.7 hinzufügen

Insgesamt ist kdc in seiner aktuellen Form IMO durchaus brauchbar. Es hat auch ein eigenes öffentliches CI basierend auf Travis (Übrigens ist es mir auch gelungen, DIND auf CircleCI zu betreiben, wenn es von Interesse ist)

@luxas Vielleicht können wir verwenden @andersla ‚s Lösung anstelle eines vollständigen Dind Cluster? Wenn ja, müssten wir das Docker-Image irgendwo hosten oder einfach nur dokumentieren, wie das Dockerfile aussieht?

Es wäre großartig, wenn wir dieses Problem für 1.9 . beheben könnten

Ich habe keine Zyklen, um daran zu arbeiten. Wenn jemand anderes, kann es bitte tun!

@jamiehannaford Das Problem ist, dass ein Großteil des "vollen" DIND-Clusters der Behandlung zahlreicher Probleme gewidmet ist, die sich aus der "einfachen" DIND-Nutzung ergeben. Diese können manchmal ziemlich undurchsichtig sein, siehe zB https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (ich denke, ich muss dafür einen Fix für k8s einreichen). Ab kubeadm-dind-cluster ist es immer noch recht brauchbar und ich versuche, es auf dem neuesten Stand zu halten ( @pmichali verwenden es für k8s IPv6 e2e-Tests und Virtlet verwendet es, um seine e2e-Tests auf CircleCI auszuführen). Obwohl ich viel Zeit mit anderen Projekten verbringe, habe ich es noch nicht geschafft, es in Go neu zu schreiben.

Wir haben gestern im SIG-Meeting darüber gesprochen, und wir werden das Thema schließen.
Die Entwicklung und Wartung einer ausgewachsenen DIND-Lösung ist für das Kernteam von kubeadm auf absehbare Zeit, wenn überhaupt, nicht vorgesehen. Wir freuen uns jedoch sehr, dass die Community diese Lösungen bereitstellt, wie die harte Arbeit von @ivan4th am Mirantis-Projekt. Wenn wir einen guten Ort finden, um die Möglichkeit zu dokumentieren, dieses Projekt zu nutzen, kann ich persönlich darauf verweisen. Vielen Dank!