Kubeadm: Documenter comment et fournir des scripts pour exécuter kubeadm dans un conteneur

_De @luxas le 27 octobre 2016 18:14_

cc @errordeveloper et @marun puisqu'ils exécutent systemd dans un conteneur

@andersla Attention, l'exécution de systemd de cette façon dans un conteneur n'est pas prise en charge par ootb, mais n'hésitez pas à l'essayer ou à le pirater car ce serait formidable pour tester kubeadm de cette façon

_De @zreigz le 28 octobre 2016 7:36_

Si cela ne vous dérange pas, j'aimerais regarder de plus près et essayer de le réparer.

_De @andersla le 28 octobre 2016 8:48_

@zreigz S'il vous plaît, faites-le !
Voici comment j'essaye de l'installer :

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

Puis:

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

Et voici l'erreur que j'obtiens lors de l'installation de 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)

_De @zreigz le 28 octobre 2016 9:10_

Je l'ai reproduit et j'ai travaillé dessus

_De @zreigz le 31 octobre 2016 7:24_

Il y a deux problèmes.

Le premier : ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
Sur les systèmes Ubuntu, /bin/sh est un tiret, pas un bash, et dash ne prend pas en charge le mot-clé double crochet. Heureusement que le problème est résolu sur la branche master et devrait être disponible bientôt : https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40

Le second n'est pas si anodin. L'exécution de systemctl dans le conteneur échoue avec Failed to get D-Bus connection . Il semble que systemd ne fonctionne pas correctement dans le conteneur. Maintenant je travaille dessus

_De @andersla le 31 octobre 2016 7:42_

Super!
Je ne vois tout simplement pas pourquoi l'installation de kubeadm a besoin de systemd/systemctl?

_De @zreigz le 31 octobre 2016 7:47_

À cause de ces deux lignes : https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25

systemctl daemon-reload
systemctl restart kubelet

Il échoue en première ligne

_De @zreigz le 31 octobre 2016 7:48_

voici l'explication :

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

_De @zreigz le 31 octobre 2016 7:52_

Il y a quelques étapes de configuration pour le faire fonctionner, mais je dois d'abord l'essayer. Si je trouve quelque chose, je vous le ferai savoir.

_De @zreigz le 2 novembre 2016 7:19_

Bonnes nouvelles. J'ai réussi à résoudre tous les problèmes. Il a besoin de derniers tests et je publierai une solution sur la façon d'exécuter kubeadm dans le conteneur Docker

_De @andersla le 2 novembre 2016 7:23_

Super! J'aiderai à tester dès qu'il sera prêt ! - bien que je sois en vacances le reste de la semaine :)

_De @zreigz le 2 novembre 2016 10:13_

Il y a deux problèmes principaux concernant l'installation de kubeadm dans le conteneur Docker. Tout d'abord, systemd s'exécute dans un conteneur. Le deuxième est le docker d'installation à l'intérieur du conteneur. Les problèmes ont été résolus avec succès. Voici le Dockerfile qui doit être utilisé pour préparer l'image Ubuntu

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

J'utilise cette commande pour construire l'image dans le répertoire contenant le Dockerfile

docker build -t kubeadm_docker .

Vous pouvez maintenant exécuter l'image préparée et terminer l'installation de kubeadm.
Utilisez la commande suivante pour exécuter l'image 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

Trouver l'ID de conteneur en cours d'exécution

$ 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

Vous pouvez maintenant ouvrir la console de conteneur :

docker exec -it 7dd73057620d /bin/bash

Ceci est votre script (avec de petites modifications) pour installer 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

Et enfin vous pouvez exécuter

# kubeadm init

Tout fonctionne de la même manière que sur la machine locale.
Bonne chance :)

_De @SuperStevenZ le 17 novembre 2016 7:21_

@zreigz Cela a résolu le même problème que le mien, merci!

_De @zreigz le 17 novembre 2016 7:30_

Aucun problème :)

Nous devrions mettre en place un CI avec des trucs docker-in-docker.

@errordeveloper @zreigz Pouvez-vous assumer cela ?
Au moins, nous devrions documenter quelque part comment exécuter kubeadm dans un conteneur ...

Cela me semble bien. Bien sûr, nous devons mettre tout cela dans l'image docker ainsi que des scripts de configuration/démarrage pour faire la distinction entre le maître et le nœud. Un bon début serait de créer un projet comme kubernetes/kubeadm-docker. Ce serait également le bon endroit pour Dockerfile, les scripts et la documentation

Créez-le d'abord en tant que projet privé sous zreigz/ et éventuellement, nous fusionnerons probablement ce code dans ce référentiel.

Mais d'abord, prototypez dans votre propre espace et nous verrons comment cela se passe.

Le véritable cessionnaire est @zreigz

Oui bon point. Je le ferai. La semaine prochaine (lundi, mardi) je suis en conférence donc je commencerai mercredi.

@luxas Je me demandais comment je devrais fournir les packages kubeadm et kubernetes-cni. Si je devais le construire à partir des sources actuelles (pour pouvoir tester la dernière implémentation) ou simplement télécharger la dernière version à partir du référentiel ? À des fins de CI, je pense que nous devrions avoir l'état actuel du code pour pouvoir le tester, ou nous en avons juste besoin pour tester la version finale ?

Salut merci pour le correctif mais toujours un problème après kubeadm init j'obtiens un 0/3 sur DNS, DNS ne semble pas fonctionner du tout

Toutes les 2.0s : kubectl get pods --all-namespaces Ven 16 décembre 17:00:50 2016

NOM DE L'ESPACE DE NOM ÉTAT PRÊT REDÉMARRAGE ÂGE
kube-system mannequin-2088944543-17sey 1/1 Running 0 11m
kube-system etcd-8dd8c92c6c38 1/1 Running 2 12m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Exécution 4 12m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Running 2 11m
kube-system kube-discovery-1150918428-m506w 1/1 Running 0 11m
kube-system kube-dns-654381707-vuijm 0/3 Création de conteneur 0 11m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Course 2 10m

essayé d'installer la politique réseau
root@8dd8c92c6c38 :/# kubectl applique -f calico.yaml
le chemin "calico.yaml" n'existe pas
root@8dd8c92c6c38 :/# kubectl create -f calico.yaml
le chemin "calico.yaml" n'existe pas
root@8dd8c92c6c38 :/# kubectl applique -f kube-flanel.yml
le chemin "kube-flanel.yml" n'existe pas

root@8dd8c92c6c38 :/# kubectl applique -f https://git.io/weave-kube
ensemble de démons "weave-net" créé
root@8dd8c92c6c38 :/# kubectl get pods --all-namespaces
NOM DE L'ESPACE DE NOM ÉTAT PRÊT REDÉMARRAGE ÂGE
kube-system mannequin-2088944543-17sey 1/1 Running 0 46m
kube-system etcd-8dd8c92c6c38 1/1 Course 2 46m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Exécution 4 46m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Course 2 45m
kube-system kube-discovery-1150918428-9m6rr 0/1 En attente 0 3m
kube-system kube-dns-654381707-vuijm 0/3 Création de conteneur 0 45m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Course 2 44m
kube-system weave-net-iv0bc 0/2 Création de conteneur 0 49s
info : 1 objet(s) terminé(s) n'était (n'étaient) pas affiché(s) dans la liste des pods. Passez --show-all pour voir tous les objets.

Re-bonjour @zreigz
Maintenant, j'ai enfin eu le temps d'aller plus loin et de le tester - je peux presque y arriver, mais il y a une erreur que docker choisit le pilote de stockage vfs (probablement parce qu'il ne peut pas utiliser aufs au-dessus de aufs? Mais comme vous décrivez la solution de contournement ci-dessus, je monte le docker externe .sock dans le docker interne, il devrait donc être possible d'écrire avec aufs?
docker info sur ma machine hôte, il indique qu'il exécute le pilote de stockage aufs. - Alors que si je fais docker info dans le conteneur docker avec kubernetes, cela indique qu'il utilise le pilote de stockage vfs.
Toutes les idées de pourquoi je reçois le problème suivant lors de l'exécution
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>:/# 

Quelques informations supplémentaires après avoir essayé un peu plus.
J'ai changé le pilote de stockage Docker en "superposition" sur l'hôte. Ensuite, docker inside docker a choisi aufs comme pilote et j'ai passé les "contrôles avant vol", mais maintenant je suis coincé dans
[apiclient] Created API client, waiting for the control plane to become ready

Lors d'autres tests, j'ai réalisé que docker ne sélectionnait pas le même pilote de stockage lorsqu'il a été démarré en tant que service via le /sbin/init
Si j'ai exécuté l'image docker de cette façon, cela n'a pas démarré le même pilote que l'hôte (comme mentionné ci-dessus):
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

Si je l'ai démarré sans /sbin/init et pas en tant que démon comme celui-ci :
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 puis docker choisissait le même pilote de stockage que l'hôte (mais maintenant systemctrl ne fonctionnait pas)

Quelques mises à jour supplémentaires :

Je peux maintenant créer un kubeadm-in-docker-container fonctionnel avec ce 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 \
    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

Je construis avec : docker build -t kubeadm_docker .

Et puis lancez :

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

Attendez quelques (10-15) secondes jusqu'à ce que systemd et docker soient opérationnels

Ensuite, je lance kubeadm dans le conteneur en cours d'exécution :
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

Lorsqu'il est lancé, je démarre un deuxième nœud "worker":

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
Et au bout de quelques secondes rejoignez le maître :

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

Actuellement, il y a un problème avec le réseau docker car kube-proxy fait et entre dans un CrashLoopBackOff.

Si je définis plutôt --net=host lors de l'exécution de docker ci-dessus, alors kube-proxy et tous les pods s'affichent correctement - mais ce n'est pas une option car j'aurai besoin que les conteneurs s'exécutent sur le réseau docker avec leur ip : s

J'ai également déjà essayé d'exécuter docker avec le même processus que sur l'hôte : -v /var/run/docker.sock:/var/run/docker.sock mais je ne l'ai jamais fait fonctionner car lorsque le docker à l'intérieur du conteneur est démarré avec systemd, il ne récupère pas la chaussette (ou quelque chose comme cette).

Merci @andersla !
Pouvez-vous coller avec quoi kube-proxy échoue ?

Merci @luxas pour votre intérêt !

Malheureusement pas de détails dans journalctl -xeu kubelet

C'est tout ce que je trouve à propos de kube-proxy (répété plusieurs fois), je joins également un journal complet.

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

Le journal complet se plaint également du kube-dns - mais c'est parce que je n'ai pas encore commencé à tisser.

log.zip

Voici le journal de 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)"

Oui, je vois _que_ c'est un crashloop, mais pourriez-vous donner par exemple kubectl -n kube-system logs kube-proxy-w0ng5 ?
Nous voyons donc en fait la raison _pourquoi_ :smile:

Hé c'est génial :)
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

Je peux le résoudre avec une solution de contournement : en définissant --conntrack-max-per-core=0 , puis en redémarrant le proxy. Un 0-val ignore la reconfiguration du nf_conntrack_max et laisse tel quel (65536). J'injecte le paramètre de démarrage comme ceci :

Entrez d'abord dans le conteneur Docker :
docker exec -it master bash

puis appliquez le correctif :

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'

Maintenant, j'obtiens le CrashLoop sur Weave à la place lorsque je fais plus tard un kubectl apply -f weave.yaml , ce qui suit est la sortie du journal du pod de tissage :
/proc/sys/net/bridge/bridge-nf-call-iptables not found
J'ai également essayé de commencer avec le paramètre kube-proxy --proxy-mode=userspace mais le même résultat.

Je pense que cela résoudra le problème de tissage : https://github.com/weaveworks/weave/pull/2659

@andersla Oui, cela semble résoudre le problème. Pouvez-vous essayer une version de HEAD ?
Par exemple, vous pouvez utiliser les images luxas/weave-(kube|npc):v1.9.0-alpha.5 provenant de HEAD~ish.
Faites-moi savoir si cela fonctionne et commentez ici exactement ce que vous faites maintenant (commandes shell, Dockerfile, autres scripts, etc.) afin que d'autres puissent en profiter.

J'ai utilisé la dernière image de weaveworks/weave-kube

J'ai également utilisé le dernier yaml-template https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml

Malheureusement, kube-dns n'a pas fonctionné (il est bloqué dans ContainerCreating. Le message d'erreur de kubelet après le démarrage du tissage est :

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

Si je n'ai démarré que le nœud maître et que je n'ai pas rejoint un autre nœud, alors kubedns est apparu correctement lorsque j'ai appliqué weave.yaml

J'ai également testé le weave.yaml avec le dernier weave-kube sur une installation Vagrant et non dans mon expérience docker, puis tout a fonctionné.

C'est le weave.yaml que j'ai utilisé pour 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

Hé les gars, je suis tombé sur ce fil et ça flippe! super trucs.

Je veux vraiment utiliser cette approche pour CI contre notre repo (ce qui est assez complexe, honnêtement). nous avons une exigence Helm/Tiller pour lancer un certain nombre de cartes pour CI. L'un d'entre vous a-t-il rencontré ce problème ou a-t-il des suggestions pour le faire fonctionner ? Tiller semble vomir sur lui-même dans cette situation :

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# 

Je peux essayer avec d'autres SDN. nous avons utilisé Calico jusqu'à présent parce que L3 est un peu plus simple à dépanner dans les situations difficiles, mais si Weave est meilleur (puisque c'est L2)... J'essaierai tout ce qui nous permettra de surmonter le problème de Tiller. Je pense que Tiller est mécontent parce qu'à la fin de la journée, il semble qu'il s'associe à 127.0.0.1... et j'ai vu que cela posait des problèmes dans le passé en testant d'autres choses. toute entrée serait incroyable. encore une fois, des accessoires vraiment géniaux pour les gens qui piratent les choses ! Merci!!

Salut! Génial que nous soyons plus nombreux à vouloir que cela fonctionne. Je n'ai pas d'expérience avec le calicot. Sur le cloud, nous exécutons Weave, c'est donc ce que je voulais travailler sur ce projet. Mais je suis bloqué et je n'ai pas eu le temps de creuser davantage pourquoi kube-dns ne s'affiche pas lorsque j'applique Weave comme décrit ci-dessus.

Maintenant, le dernier tissage stable fonctionne mieux qu'avant....

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

..mais malheureusement toujours le même problème avec kube-dns qui ne s'affiche pas, bloqué dans 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

et après avoir appliqué le tissage, ce message d'erreur s'arrête :
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"

et à la place une fois que je vois:

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

Si j'utilise Flannel comme plugin réseau à la place, cela fonctionne.

docker exec -it master bash

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

Donc si vous utilisez Flannel, alors tout fonctionne, voici la configuration complète :

Fichier Docker :

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

Construisez-le avec :
docker build -t kubeadm_docker .

Et puis lancez :
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

Attendez quelques (10-15) secondes jusqu'à ce que systemd et docker soient opérationnels

Ensuite, je lance kubeadm dans le conteneur en cours d'exécution :
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

Lorsqu'il est lancé, je démarre un deuxième nœud "worker":
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

Et après quelques secondes (jusqu'à ce que systemd et docker soient opérationnels), rejoignez le maître :
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

Quand ils ont rejoint, - entrez master et appliquez la solution de contournement pour le plantage de 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'

Enfin, appliquez le réseau de superposition de flanelle :
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

Je n'ai eu aucun problème à installer Helm, Traefic ou GlusterFS dans Kubernetes dans ce cadre :)

kubeadm-dind-cluster fait essentiellement ce que le dernier commentaire a décrit, fournissant une automatisation afin que vous n'ayez pas à taper les commandes manuellement (bien qu'à partir de maintenant, il utilise le plug-in de pont CNI avec quelques hacks au lieu de flanelle, mais je vais corriger tout à fait bientôt).
Cela facilite également la création de composants k8s et de kubeadm à partir d'une source locale et d'utilisation des binaires du cluster que vous démarrez. En outre, j'ai rencontré des problèmes non apparents en travaillant dessus, par exemple agetty mangeant 100% du processeur et provoquant des plantages de docker à moins que vous ne preniez soin de le désactiver.

Certains des changements à venir très bientôt dans kubeadm-dind-cluster :

• corrigez-le pour le maître k8s, kube-proxy s'est cassé là-bas
• prise en charge des images prédéfinies (je vais également publier plusieurs de ces images) donc un seul script suffit pour démarrer le cluster. Cela peut être utile pour CI dans divers projets utilisant des k8
• mise en cache des répertoires de données Docker pour des redémarrages de cluster plus rapides
• prise en charge des implémentations CNI en plus du bridge

kubeadm-dind-cluster fournit également une automatisation pour les tests e2e. Un autre trait intéressant est que vous pouvez utiliser le même moteur docker distant pour la construction de k8 et l'exécution de kubeadm-dind-cluster sans recopier les binaires (il les extrait directement du conteneur de données de construction), ce qui peut être important si vous travaillez avec docker distant sur une connexion lente.

... j'ai oublié de mentionner qu'il configure kubectl local pour vous afin que vous n'ayez pas besoin de faire docker exec sur votre conteneur maître pour accéder à votre cluster.

Comme je l'ai déjà mentionné, bien que DIND puisse sembler facile en surface, vous pouvez avoir des problèmes inattendus avec lui. Certains des problèmes sont déjà résolus dans kubeadm-dind-cluster et l' image de base qu'il utilise. Par exemple, vous devez faire quelques montages , vous devez également utiliser STOPSIGNAL SIGRTMIN+3 et résister à la tentation d'utiliser /sbin/init comme ENTRYPOINT , et le pilote vfs peut parfois être assez lent. Alors... voici des dragons ;)

@ivan4th Merci pour tout le travail que vous avez fait avec kubeadm et dind :)
Pouvez-vous ouvrir un nouveau problème faisant référence à ce problème où nous pouvons discuter du MVP nécessaire pour fusionner kubeadm-dind-cluster dans ce référentiel ?

Après avoir regardé rapidement, j'ai trouvé quelques points que nous pourrions vouloir faire avant un éventuel MVP :

• Il devrait idéalement être écrit en Go -- je pense généralement que nous essayons de nous éloigner de Bash, donc Go est la voie à suivre pour un nouveau projet, je pense :)
• La base debian doit être basée sur gcr.io/google-containers/debian-base-$(ARCH):0.1
  
  
  
  • L'image de base pour dind devrait idéalement être publiée sur gcr.io
  
  
• Cela devrait fonctionner sur plusieurs arches comme kubeadm
• Vous devriez être en mesure de fournir vos propres binaires, mais le plus souvent, il devrait être téléchargé à partir du CI qui publie les binaires pour toutes les arches toutes les heures
• Il devrait utiliser CNI - avec des fournisseurs de réseau échangeables
• Il devrait exposer ses options de configuration via un fichier de configuration comme kubeadm peut prendre un fichier de configuration comme entrée pour les options
• Il ne devrait prendre en charge que kubeadm v1.6+

Qu'est-ce que tu penses? Merci pour le bon début, j'ai hâte d'intégrer cela dans quelque chose d'officiel de kubeadm :+1:

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

Merci pour le bon début, j'ai hâte d'intégrer cela dans quelque chose d'officiel de kubeadm

si nous pouvons développer, kubeadm-local-up-cluster, ce serait fantastique.

@ivan4th @luxas Quel est le statut de ceci?

Je ne sais pas vraiment... @ivan4th

@jamiehannaford

• à partir de maintenant, j'ai pris du retard avec Go rewrite car j'ai aussi besoin de travailler sur d'autres projets
• kdc prend en charge différents impls CNI (Weave, Calico, Flannel et plain CNI bridge qui est par défaut)
• la prise en charge de plusieurs architectures n'est pas encore là mais tout à fait faisable
• les binaires qui sont utilisés dans les images sont par défaut tirés de la version k8s mais vous pouvez créer les vôtres ou, avec un petit effort, créer une image basée sur vos propres binaires construits séparément
• il prend en charge le fichier de configuration mais pour l'instant c'est en fait un ensemble de vars env
• l'image de base est toujours ubuntu mais nous allons passer à debian
• nous prenons en charge la 1.6 et j'ajouterai la prise en charge de la 1.7 au début de la semaine prochaine

Globalement, kdc est tout à fait utilisable dans sa forme actuelle IMO. Il a également son propre CI public basé sur Travis (BTW j'ai également réussi à exécuter DIND sur CircleCI si cela présente un certain intérêt)

@luxas Peut - être que nous pouvons utiliser la solution de @andersla au lieu d'un groupe complet DIND? Si tel est le cas, aurions-nous besoin d'héberger l'image Docker n'importe où, ou simplement de documenter à quoi ressemble le Dockerfile ?

Ce serait formidable si nous pouvions résoudre ce problème pour la version 1.9

Je n'ai pas de cycles pour travailler là-dessus. Si quelqu'un d'autre peut le faire !

Le problème de https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (je pense que je devrai soumettre un correctif pour k8s pour cela). À partir de kubeadm-dind-cluster , il est toujours tout à fait utilisable et j'essaie de le maintenir à jour( @danehans et @pmichali l' utilisent pour les tests e2e IPv6 de k8s et Virtlet l' utilise pour exécuter ses tests e2e sur CircleCI), bien que je passe beaucoup de temps sur d'autres projets donc je n'ai pas encore réussi à le réécrire en Go.

Nous en avons parlé hier lors de la réunion du SIG, et nous allons clore le sujet.
Développer et maintenir une solution DIND complète n'est pas à la portée de l'équipe principale de kubeadm dans un avenir prévisible, voire jamais. Nous sommes très heureux que la communauté fournisse ces solutions, comme le travail acharné de @ivan4th sur le projet Mirantis. Si nous trouvons un bon endroit pour documenter la possibilité d'utiliser ce projet, je suis personnellement d'accord pour le référencer. Merci!