Kubeadm: Documentar cómo y proporcionar scripts para ejecutar kubeadm en un contenedor

_De @luxas el 27 de octubre de 2016 18: 14_

cc @errordeveloper y @marun desde que han estado ejecutando systemd dentro de un contenedor

@andersla Tenga cuidado de que ejecutar systemd de esta manera dentro de un contenedor no es compatible con ootb, pero siéntase libre de probarlo nuestro / hackearlo, ya que sería genial para probar kubeadm de esa manera

_De @zreigz el 28 de octubre de 2016 7: 36_

Si no le importa, me gustaría echar un vistazo más de cerca e intentar solucionarlo.

_De @andersla el 28 de octubre de 2016 8:48_

@zreigz ¡ Por favor, hazlo!
Así es como intento instalarlo:

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

Y luego:

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

Y este es el error que obtengo cuando se instala 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 el 28 de octubre de 2016 9: 10_

Lo reproduje y he estado trabajando en esto.

_De @zreigz el 31 de octubre de 2016 7: 24_

Hay dos problemas.

El primero: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
En los sistemas Ubuntu, / bin / sh es guión, no bash, y guión no admite la palabra clave de doble corchete. Lo bueno es que el problema está solucionado en la rama maestra y debería estar disponible pronto: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40

El segundo no es tan trivial. La ejecución de systemctl en el contenedor falla con Failed to get D-Bus connection . Parece que systemd no funciona correctamente en el contenedor. Ahora estoy trabajando en esto

_De @andersla el 31 de octubre de 2016 7:42_

¡Excelente!
Simplemente no veo por qué la instalación de kubeadm necesita systemd / systemctl en absoluto.

_De @zreigz el 31 de octubre de 2016 7: 47_

Debido a esas dos líneas: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25

systemctl daemon-reload
systemctl restart kubelet

Falla en primera línea

_De @zreigz el 31 de octubre de 2016 7:48_

esta es la explicación:

# 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 el 31 de octubre de 2016 7: 52_

Hay algunos pasos de configuración para que funcione, pero primero tengo que probarlo. Si encuentro algo, te lo haré saber.

_De @zreigz el 2 de noviembre de 2016 7: 19_

Buenas noticias. Me las arreglé para resolver todos los problemas. Necesita las últimas pruebas y publicaré una solución sobre cómo ejecutar kubeadm en el contenedor Docker

_De @andersla el 2 de noviembre de 2016 7: 23_

¡Súper! ¡Ayudaré a probar tan pronto como esté listo! - aunque estoy de vacaciones el resto de esta semana :)

_De @zreigz el 2 de noviembre de 2016 10: 13_

Hay dos problemas principales relacionados con la instalación de kubeadm en el contenedor Docker. Primero se ejecuta systemd en un contenedor. El segundo es la ventana acoplable de instalación dentro del contenedor. Con éxito se solucionaron los problemas. Aquí está el Dockerfile que debe usarse para preparar la imagen de 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

Utilizo este comando para construir la imagen en el directorio que contiene el Dockerfile

docker build -t kubeadm_docker .

Ahora puede ejecutar la imagen preparada y finalizar la instalación de kubeadm.
Utilice el siguiente comando para ejecutar kubeadm_docker image:

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

Buscar ID de contenedor en ejecución

$ 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

Ahora puede abrir la consola del contenedor:

docker exec -it 7dd73057620d /bin/bash

Este es su script (con pequeñas modificaciones) para instalar 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

Y finalmente puedes ejecutar

# kubeadm init

Todo funciona igual que en la máquina local.
Buena suerte :)

_De @SuperStevenZ el 17 de noviembre de 2016 7: 21_

@zreigz Eso solucionó el mismo problema mío, ¡gracias!

_De @zreigz el 17 de noviembre de 2016 7: 30_

No hay problema :)

Deberíamos configurar un CI con elementos de Docker-in-Docker.

@errordeveloper @zreigz ¿Puedes asumir esto?
Al menos deberíamos documentar en algún lugar cómo ejecutar kubeadm dentro de un contenedor ...

Suena bien para mi. Seguro que necesitamos poner todo esto en la imagen de la ventana acoplable más algunos scripts de configuración / inicio para distinguir entre maestro y nodo. Un buen comienzo sería crear un proyecto como kubernetes / kubeadm-docker. También sería el lugar adecuado para Dockerfile, scripts y documentación.

Cree eso como un proyecto privado primero en zreigz / y, eventualmente, probablemente fusionaremos ese código en este repositorio.

Pero primero, haz un prototipo en tu propio espacio y veremos cómo te va.

El verdadero cesionario es @zreigz

Sí, buen punto. Lo haré. La semana que viene (lunes, martes) estoy en conferencia, así que empezaré el miércoles.

@luxas Me preguntaba cómo debería proporcionar los paquetes kubeadm y kubernetes-cni. ¿Si debo compilarlo a partir de las fuentes actuales (para poder probar la implementación más reciente) o simplemente descargar la versión más reciente del repositorio? Para el propósito de CI, creo que deberíamos tener el estado actual del código para poder probarlo, ¿o simplemente lo necesitamos para probar la versión de lanzamiento?

Hola, gracias por la solución, pero sigo teniendo un problema después de kubeadm init, obtengo un 0/3 en el DNS, el DNS no parece estar ejecutándose en absoluto.

Cada 2.0s: kubectl get pods --all-namespaces Vie 16 de diciembre 17:00:50 2016

NOMBRE NOMBRE ESTADO LISTO REINICIE EDAD
kube-system dummy-2088944543-17sey 1/1 Corriendo 0 11m
kube-system etcd-8dd8c92c6c38 1/1 En funcionamiento 2 12m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Corriendo 4 12m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 En ejecución 2 11m
kube-system kube-discovery-1150918428-m506w 1/1 En funcionamiento 0 11m
kube-system kube-dns-654381707-vuijm 0/3 ContainerCreating 0 11m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11m
kube-system kube-planificador-8dd8c92c6c38 1/1 En ejecución 2 10m

intenté instalar la política de red
root @ 8dd8c92c6c38 : / # kubectl apply -f calico.yaml
la ruta "calico.yaml" no existe
root @ 8dd8c92c6c38 : / # kubectl create -f calico.yaml
la ruta "calico.yaml" no existe
root @ 8dd8c92c6c38 : / # kubectl apply -f kube-flannel.yml
la ruta "kube-flannel.yml" no existe

root @ 8dd8c92c6c38 : / # kubectl apply -f https://git.io/weave-kube
Se creó el daemonset "weave-net"
root @ 8dd8c92c6c38 : / # kubectl get pods --all-namespaces
NOMBRE NOMBRE ESTADO LISTO REINICIE EDAD
kube-system dummy-2088944543-17sey 1/1 Corriendo 0 46m
kube-system etcd-8dd8c92c6c38 1/1 Corriendo 2 46m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Corriendo 4 46m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 En ejecución 2 45m
kube-system kube-discovery-1150918428-9m6rr 0/1 Pendiente 0 3m
kube-system kube-dns-654381707-vuijm 0/3 ContainerCreating 0 45m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-planificador-8dd8c92c6c38 1/1 En ejecución 2 44m
kube-system weave-net-iv0bc 0/2 ContainerCreating 0 49s
información: 1 objeto (s) completo (s) no se mostró (s) en la lista de grupos. Pase --show-all para ver todos los objetos.

Hola de nuevo @zreigz
Ahora finalmente he tenido tiempo de ir más allá con esto y lo probé; casi puedo hacerlo, pero hay un error que indica que Docker elige el controlador de almacenamiento vfs (probablemente porque no puede usar aufs encima de aufs, pero como usted describe la solución alternativa arriba, estoy montando el .sock de la ventana acoplable externa en la ventana acoplable interna, por lo que debería ser posible escribir con aufs.
docker info en mi máquina host dice que está ejecutando el controlador de almacenamiento aufs. - Mientras que si hago docker info dentro del contenedor de la ventana acoplable con kubernetes, dice que está usando el controlador de almacenamiento vfs.
Alguna idea de por qué tengo el siguiente problema al ejecutar
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>:/# 

Más información después de intentar un poco más.
Cambié el controlador de almacenamiento de la ventana acoplable a "superposición" en el host. Luego, la ventana acoplable dentro de la ventana acoplable eligió a aufs como conductor y pasé las "verificaciones previas al vuelo", pero ahora estoy atascado
[apiclient] Created API client, waiting for the control plane to become ready

En algunas otras pruebas me di cuenta de que Docker no estaba eligiendo el mismo controlador de almacenamiento cuando se inició como un servicio a través de / sbin / init
Si ejecuté la imagen de la ventana acoplable de esta manera, no inició el mismo controlador que el host (como se mencionó anteriormente):
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 lo inicié sin /sbin/init y no como un demonio como este:
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 entonces Docker estaba eligiendo el mismo controlador de almacenamiento que el host (pero ahora systemctrl no funcionaba)

Algunas actualizaciones más:

Ahora puedo construir un kubeadm-in-docker-container que funcione con este 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

Construyo con: docker build -t kubeadm_docker .

Y luego ejecuta:

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

Espere unos (10-15) segundos hasta que systemd y docker estén en funcionamiento

Luego comienzo kubeadm dentro del contenedor en ejecución:
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

Cuando se inicia, comienzo un segundo nodo "trabajador":

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
Y después de unos segundos únete al maestro:

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

Actualmente hay algún problema con la red de Docker porque kube-proxy falla e ingresa un CrashLoopBackOff.

Si, en cambio, configuro --net=host cuando ejecuto la ventana acoplable anterior, entonces kube-proxy y todos los pods están funcionando bien, pero esa no es una opción ya que necesitaré que los contenedores se ejecuten en la red de la ventana acoplable con su IP: s

También intenté anteriormente ejecutar la ventana acoplable con el mismo proceso que en el host: -v /var/run/docker.sock:/var/run/docker.sock pero nunca lo hice funcionar porque cuando la ventana acoplable dentro del contenedor se inicia con systemd, no recoge el calcetín (o algo así como ese).

¡Gracias @andersla!
¿Puedes pegar con qué falla kube-proxy?

¡Gracias @luxas por tu interés!

Desafortunadamente no hay detalles en journalctl -xeu kubelet

Esto es todo lo que encuentro sobre kube-proxy (repetido muchas veces). También adjunto el registro completo.

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

El registro completo también se queja de los kube-dns, pero eso se debe a que aún no he comenzado a tejer.

log.zip

Aquí está el registro 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)"

Sí, veo que se está produciendo un bucle de bloqueo, pero ¿podría dar, por ejemplo, kubectl -n kube-system logs kube-proxy-w0ng5 ?
Entonces, en realidad vemos la razón _por qué_: sonrisa:

Oye, eso es brillante :)
root @ 3551807cba77 : / # kubectl -n registros del sistema kube 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

Puedo solucionarlo con una solución alternativa: configurar --conntrack-max-per-core=0 y luego reiniciar el proxy. Un valor 0 omite la reconfiguración de nf_conntrack_max y sale como está (65536). Inyecto un parámetro de inicio como este:

Primero ingrese el contenedor de la ventana acoplable:
docker exec -it master bash

luego aplique la corrección:

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'

Ahora obtengo el CrashLoop on Weave en su lugar cuando luego hago un kubectl apply -f weave.yaml , lo siguiente es el resultado del registro del pod de tejido:
/proc/sys/net/bridge/bridge-nf-call-iptables not found
También intenté comenzar con el parámetro kube-proxy --proxy-mode=userspace pero el mismo resultado.

Creo que esto resolverá el problema del tejido: https://github.com/weaveworks/weave/pull/2659

@andersla Sí, eso parece solucionar el problema. ¿Puedes probar una compilación de HEAD?
Por ejemplo, podría usar las imágenes luxas/weave-(kube|npc):v1.9.0-alpha.5 que son de HEAD ~ ish.
Avíseme si funciona y, por favor, comente aquí exactamente lo que está haciendo ahora (comandos de shell, Dockerfile, otros scripts, etc.) para que otros puedan aprovecharlo.

Usé la última imagen de weaveworks / weave-kube

También utilicé la última plantilla de yaml https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml

Desafortunadamente, kube-dns no funcionó (está muy bien en ContainerCreating. El mensaje de error de kubelet después de iniciar el tejido es:

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 solo inicié el nodo maestro y no me uní a otro nodo, entonces kubedns salió bien cuando apliqué weave.yaml

También probé weave.yaml con el último weave-kube en una instalación de Vagrant y no en mi docker-experiment y luego todo funcionó.

Este es el archivo weave.yaml que usé para 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

¡Hola, chicos, me encontré con este hilo y me jode! Buena cosa.

Realmente quiero usar este enfoque para CI contra nuestro repositorio (que es bastante complejo, honestamente). tenemos un requisito de Helm / Tiller para lanzar bastantes gráficos para CI. ¿Alguno de ustedes se ha encontrado con esto o tiene alguna sugerencia para hacerlo funcionar? Tiller parece vomitar por sí mismo en esta situación:

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# 

Puedo probar con otras SDN. hemos estado usando Calico hasta ahora porque L3 es un poco más sencillo de solucionar en situaciones de piratería, pero si Weave es mejor (ya que es L2) ... intentaré lo que sea que nos ayude a superar el problema de Tiller. Creo que Tiller no está contento porque al final del día parece que se asocia con 127.0.0.1 ... y he visto que eso causa problemas en el pasado probando otras cosas. cualquier entrada sería asombrosa. de nuevo, ¡accesorios realmente increíbles para la gente que está pirateando cosas! ¡¡gracias!!

¡Hola! Es genial que haya más personas que quieran que esto funcione. No tengo experiencia con el calicó. En la nube, estamos ejecutando Weave, así que eso es lo que quería trabajar en este proyecto. Pero estoy atascado y no he tenido tiempo de investigar más por qué kube-dns no aparece cuando aplico Weave como se describe anteriormente.

Ahora, el último tejido estable funciona mejor que antes ...

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

... pero desafortunadamente sigue siendo el mismo problema con kube-dns que no aparece, atascado en 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

y después de aplicar el tejido, este mensaje de error se detiene:
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"

y en cambio una vez que veo:

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 utilizo Flannel como complemento de red, funciona.

docker exec -it master bash

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

Entonces, si usa Flannel, entonces todo está funcionando, aquí está la configuración completa:

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

Constrúyelo con:
docker build -t kubeadm_docker .

Y luego ejecuta:
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

Espere unos (10-15) segundos hasta que systemd y docker estén en funcionamiento

Luego comienzo kubeadm dentro del contenedor en ejecución:
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

Cuando se inicia, comienzo un segundo nodo "trabajador":
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

Y después de unos segundos (hasta que systemd y docker estén activos) únete al maestro:
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

Cuando se hayan unido, ingrese master y aplique una solución alternativa para bloquear 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'

Finalmente aplique la red de superposición de franela:
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

No tuve ningún problema para instalar Helm, Traefic o GlusterFS en Kubernetes en esta configuración :)

kubeadm-dind-cluster básicamente hace lo que se describe en el último comentario, proporcionando automatización para que no tenga que escribir los comandos manualmente (aunque a partir de ahora usa el complemento de puente CNI con algunos trucos en lugar de franela, pero esto lo arreglaré bastante pronto).
También facilita la compilación de componentes k8s y kubeadm desde una fuente local y usa los binarios en el clúster que inicia. Además, hubo algunos problemas no aparentes que encontré mientras trabajaba en él, por ejemplo, que consumía el 100% de la CPU y causaba bloqueos en la ventana acoplable, a menos que tenga cuidado de deshabilitarlo.

Algunos de los cambios que llegarán pronto en kubeadm-dind-cluster:

• arreglarlo para k8s master, kube-proxy se rompió allí
• soporte para imágenes precompiladas (también voy a publicar varias de estas imágenes), por lo que un solo script es suficiente para iniciar el clúster. Esto puede ser útil para CI en varios proyectos que usan k8s.
• almacenamiento en caché de los directorios de datos de Docker para reinicios más rápidos del clúster
• soporte para implementaciones CNI además del puente

kubeadm-dind-cluster también proporciona automatización para las pruebas e2e. Otro rasgo interesante es que puede usar el mismo motor acoplable remoto para compilar k8s y ejecutar kubeadm-dind-cluster sin copiar los binarios (los extrae directamente del contenedor de datos de compilación), lo que puede ser importante si está trabajando con acoplador remoto a través de una conexión lenta.

... olvidé mencionar que configura kubectl local para usted, por lo que no necesita hacer docker exec en su contenedor maestro para acceder a su clúster.

Como ya mencioné, aunque DIND puede parecer fácil en la superficie, puede tener algunos problemas inesperados con él. Algunos de los problemas ya están resueltos en kubeadm-dind-cluster y en la imagen base que usa. Por ejemplo, necesita hacer algunos montajes , también necesita usar STOPSIGNAL SIGRTMIN+3 y resistir la tentación de usar /sbin/init como ENTRYPOINT , y el controlador vfs puede ser bastante lento a veces. Entonces ... aquí hay dragones;)

@ ivan4th Gracias por todo el trabajo que has estado haciendo con kubeadm y dind :)
¿Puede abrir un nuevo problema que haga referencia a este problema donde podamos discutir el MVP necesario para fusionar kubeadm-dind-cluster en este repositorio?

Después de buscar rápidamente, encontré algunos puntos que podríamos querer hacer antes de un posible MVP:

• Idealmente, debería estar escrito en Go; en general, creo que estamos tratando de alejarnos de Bash, por lo que Go es el camino a seguir para un nuevo proyecto, creo :)
• La base de Debian debe basarse en gcr.io/google-containers/debian-base-$(ARCH):0.1
  
  
  
  • Idealmente, la imagen base para dind debería publicarse en gcr.io
  
  
• Debería funcionar en múltiples arcos como kubeadm
• Debería poder proporcionar sus propios binarios, pero la mayoría de las veces debería descargarlos del CI que publica binarios para todos los arcos cada hora.
• Debe usar CNI, con proveedores de red intercambiables
• Debería exponer sus opciones de configuración a través de un archivo de configuración como kubeadm puede tomar un archivo de configuración como entrada para las opciones
• Solo debería ser compatible con kubeadm v1.6 +

¿Qué piensas? Gracias por el increíble comienzo, no puedo esperar para integrar esto en algo oficial de kubeadm: +1:

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

Gracias por el increíble comienzo, no puedo esperar para integrar esto en algo oficial de kubeadm

si podemos desarrollar-build, kubeadm-local-up-cluster sería fantástico.

@ ivan4th @luxas ¿Cuál es el estado de esto?

No lo sé realmente ... @ ivan4th

@jamiehannaford

• a partir de ahora, me retrasé con Go rewrite porque también necesito trabajar en otros proyectos
• kdc tiene soporte para diferentes CNI impls (Weave, Calico, Flannel y simple CNI bridge que es predeterminado)
• el soporte de múltiples arquitecturas aún no está aquí, pero es bastante factible
• Los binarios que se utilizan en las imágenes se toman de forma predeterminada de la versión k8s, pero puede crear los suyos propios o, con un poco de esfuerzo, hacer una imagen basada en sus propios binarios construidos por separado.
• admite archivos de configuración, pero a partir de ahora es en realidad un conjunto de vars env
• la imagen base sigue siendo ubuntu pero cambiaremos a debian
• apoyamos 1.6 y agregaré soporte para 1.7 a principios de la próxima semana

En general, kdc es bastante utilizable en su forma actual, en mi opinión. También tiene su propio CI público basado en Travis (por cierto, también logré ejecutar DIND en CircleCI si es de algún interés)

@luxas Tal vez podemos usar @andersla 's solución en lugar de un grupo DNID completo? Si es así, ¿tendríamos que alojar la imagen de Docker en cualquier lugar o simplemente documentar cómo se ve el Dockerfile?

Sería genial si pudiéramos solucionar este problema para 1.9

No tengo ciclos para trabajar en esto. Si alguien más, ¡puede hacerlo!

El problema de https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (creo que tendré que enviar una solución para k8s para esto). A partir de kubeadm-dind-cluster , todavía es bastante utilizable y trato de mantenerlo actualizado ( @danehans y @pmichali lo están usando para las pruebas de k8s IPv6 e2e y Virtlet lo usa para ejecutar sus pruebas e2e en CircleCI), aunque dedico mucho tiempo a otros proyectos, así que todavía no pude reescribirlo en Go.

Hablamos de esto en la reunión de SIG ayer y vamos a cerrar el tema.
El desarrollo y el mantenimiento de una solución DIND completa no está dentro del alcance del equipo central de kubeadm en un futuro previsible, si es que llega a ocurrir. Sin embargo, estamos muy contentos de que la comunidad brinde estas soluciones, como el arduo trabajo de @ ivan4th en el proyecto Mirantis. Si encontramos un buen lugar para documentar la posibilidad de usar ese proyecto, personalmente estoy de acuerdo con hacer referencia a él. ¡Gracias!