Kubeadm: Documente como e forneça scripts para executar kubeadm em um contêiner

_De @luxas em 27 de outubro de 2016 18: 14_

cc @errordeveloper e @marun desde que estão executando o systemd dentro de um contêiner

@andersla Esteja ciente de que a execução do systemd desta forma dentro de um contêiner não é suportada ootb, mas sinta-se à vontade para tentar nosso / hack nele, pois seria ótimo para testar o kubeadm dessa forma

_De @zreigz em 28 de outubro de 2016 7: 36_

Se você não se importa, gostaria de dar uma olhada mais de perto e tentar consertar.

_De @andersla em 28 de outubro de 2016 8: 48_

@zreigz Por favor, faça!
É assim que tento instalá-lo:

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

E então:

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

E este é o erro que recebo quando o kubeadm está sendo instalado:

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 em 28 de outubro de 2016 9: 10_

Eu reproduzi e tenho trabalhado nisso

_De @zreigz em 31 de outubro de 2016 7: 24_

Existem dois problemas.

O primeiro: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
Em sistemas Ubuntu, / bin / sh é traço, não bash, e traço não suporta a palavra-chave colchete duplo. Ainda bem que o problema foi corrigido no branch master e deve estar disponível em breve: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40

O segundo não é tão trivial. A execução de systemctl no contêiner falha com Failed to get D-Bus connection . Parece que o systemd não funciona corretamente no contêiner. Agora estou trabalhando nisso

_De @andersla em 31 de outubro de 2016 7: 42_

Excelente!
Eu simplesmente não vejo por que a instalação do kubeadm precisa do systemd / systemctl?

_De @zreigz em 31 de outubro de 2016 7: 47_

Por causa dessas duas linhas: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25

systemctl daemon-reload
systemctl restart kubelet

Falha na primeira linha

_De @zreigz em 31 de outubro de 2016 7: 48_

esta é a explicação:

# 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 em 31 de outubro de 2016 7: 52_

Existem algumas etapas de configuração para fazer funcionar, mas tenho que tentar primeiro. Se eu encontrar algo, avisarei você.

_De @zreigz em 2 de novembro de 2016 7: 19_

Boas notícias. Consegui resolver todos os problemas. Ele precisa dos últimos testes e postarei uma solução de como executar o kubeadm no contêiner do Docker

_De @andersla em 2 de novembro de 2016 7: 23_

Super! Ajudarei no teste assim que estiver pronto! - embora eu esteja de férias o resto desta semana :)

_De @zreigz em 2 de novembro de 2016 10: 13_

Existem dois problemas principais relacionados à instalação do kubeadm no contêiner do Docker. O primeiro é o systemd em execução no contêiner. Em segundo lugar, está a janela de encaixe de instalação dentro do contêiner. Os problemas foram corrigidos com sucesso. Aqui está o Dockerfile que deve ser usado para preparar a imagem do 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

Eu uso este comando para construir a imagem no diretório que contém o Dockerfile

docker build -t kubeadm_docker .

Agora você pode executar a imagem preparada e concluir a instalação do kubeadm.
Use o seguinte comando para executar a imagem 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

Encontre o ID do contêiner em execução

$ 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

Agora você pode abrir o console do contêiner:

docker exec -it 7dd73057620d /bin/bash

Este é o seu script (com pequenas modificações) para instalar o 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

E finalmente você pode executar

# kubeadm init

Tudo funciona da mesma forma que na máquina local.
Boa sorte :)

_De @SuperStevenZ em 17 de novembro de 2016 7: 21_

@zreigz Isso resolveu o mesmo problema meu, obrigado!

_De @zreigz em 17 de novembro de 2016 7h30_

Sem problemas :)

Devemos configurar um CI com o material docker-in-docker.

@errordeveloper @zreigz Você pode assumir isso?
Devemos, pelo menos, documentar em algum lugar como executar o kubeadm dentro de um contêiner ...

Parece bom para mim. Com certeza, precisamos colocar tudo isso na imagem docker mais alguns scripts de configuração / inicialização para distinguir entre mestre e nó. Um bom começo seria criar um projeto para ele como kubernetes / kubeadm-docker. Seria também o lugar certo para Dockerfile, scripts e documentação

Crie isso como um projeto privado primeiro em zreigz / e, eventualmente, provavelmente iremos mesclar esse código neste repositório.

Mas primeiro, faça um protótipo em seu próprio espaço e veremos como funciona.

O verdadeiro cessionário é @zreigz

Sim, bom ponto. Eu farei. Na próxima semana (segunda, terça) estou em conferência, então começarei na quarta.

@luxas Eu queria saber como devo fornecer os pacotes kubeadm e kubernetes-cni. Se eu deveria compilá-lo a partir das fontes atuais (para poder testar a implementação mais recente) ou apenas baixar a versão mais recente do repositório? Para fins de CI, acho que devemos ter o estado atual do código para poder testá-lo, ou apenas precisamos dele para testar a versão de lançamento?

Olá, obrigado pela correção, mas ainda estou tendo um problema após o init do kubeadm, estou recebendo um 0/3 no DNS, o DNS não parece estar em execução

A cada 2.0s: kubectl get pods --all-namespaces Sex, 16 de dezembro, 17:00:50 2016

NOME ESPACIAL NOME PRONTO STATUS REINICIA IDADE
kube-system dummy-2088944543-17sey 1/1 Running 0 11m
kube-system etcd-8dd8c92c6c38 1/1 Executando 2 12m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Executando 4 12m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Executando 2 11m
kube-system kube-discovery-1150918428-m506w 1/1 Executando 0 11m
kube-system kube-dns-654381707-vuijm 0/3 ContainerCreating 0 11m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Executando 2 10m

tentei instalar política de rede
root @ 8dd8c92c6c38 : / # kubectl apply -f calico.yaml
o caminho "calico.yaml" não existe
root @ 8dd8c92c6c38 : / # kubectl create -f calico.yaml
o caminho "calico.yaml" não existe
root @ 8dd8c92c6c38 : / # kubectl apply -f kube-flannel.yml
o caminho "kube-flannel.yml" não existe

root @ 8dd8c92c6c38 : / # kubectl apply -f https://git.io/weave-kube
daemonset "weave-net" criado
root @ 8dd8c92c6c38 : / # kubectl get pods --all-namespaces
NOME ESPACIAL NOME PRONTO STATUS REINICIA IDADE
kube-system dummy-2088944543-17sey 1/1 Running 0 46m
kube-system etcd-8dd8c92c6c38 1/1 Executando 2 46m
kube-system kube-apiserver-8dd8c92c6c38 1/1 Executando 4 46m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Executando 2 45m
kube-system kube-discovery-1150918428-9m6rr 0/1 Pendente 0 3m
kube-system kube-dns-654381707-vuijm 0/3 ContainerCreating 0 45m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-scheduler-8dd8c92c6c38 1/1 Executando 2 44m
kube-system weave-net-iv0bc 0/2 ContainerCreating 0 49s
info: 1 objeto (s) concluído (s) não foi (foram) mostrado (s) na lista de pods. Passe --show-all para ver todos os objetos.

Oi de novo @zreigz
Agora finalmente tive tempo de ir mais longe com isso e testá-lo - quase posso fazer isso, mas há um erro que o docker escolhe o driver de armazenamento vfs (provavelmente porque ele não pode usar aufs em cima de aufs? Mas conforme você descreve a solução alternativa acima, estou montando a janela de encaixe externa .sock na janela de encaixe interna, então deve ser possível escrever com aufs?
docker info na minha máquina host diz que está executando o driver de armazenamento aufs. - Considerando que se eu fizer docker info dentro do contêiner do docker com kubernetes, ele diz que está usando o driver de armazenamento vfs.
Qualquer idéas de porque eu recebo o seguinte problema ao executar
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>:/# 

Mais algumas informações depois de tentar um pouco mais.
Mudei o driver de armazenamento do docker para "overlay" no host. Então o docker dentro do docker escolheu aufs como motorista e passei nas "verificações pré-voo", mas agora estou preso
[apiclient] Created API client, waiting for the control plane to become ready

Em alguns outros testes, percebi que o docker não estava escolhendo o mesmo driver de armazenamento quando foi iniciado como um serviço por meio do / sbin / init
Se eu executei a imagem do docker dessa forma, ela não iniciou o mesmo driver do host (conforme mencionado acima):
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

Se eu iniciasse sem /sbin/init e não como um daemon 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 então o docker estava escolhendo o mesmo driver de armazenamento que o host (mas agora systemctrl não estava funcionando)

Mais algumas atualizações:

Agora posso construir um kubeadm-in-docker-container funcional com 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

Eu construo com: docker build -t kubeadm_docker .

E então execute:

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

Aguarde alguns (10-15) segundos até que o systemd e o docker estejam funcionando

Então eu inicio o kubeadm dentro do contêiner em execução:
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

Quando é iniciado, eu inicio um segundo nó "trabalhador":

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
E depois de alguns segundos, junte-se ao mestre:

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

Atualmente, há algum problema com a rede docker porque kube-proxy fais e insere um CrashLoopBackOff.

Se eu, em vez disso, definir --net=host ao executar o docker acima, o kube-proxy e todos os pods estarão funcionando corretamente - mas isso não é uma opção, pois precisarei ter os contêineres em execução na rede do docker com seus ip: s

Eu também tentei anteriormente executar o docker com o mesmo processo do host: -v /var/run/docker.sock:/var/run/docker.sock mas nunca o fiz funcionar porque quando o docker dentro do contêiner é iniciado com o systemd, ele não pega a meia (ou algo como naquela).

Obrigado @andersla!
Você pode colar o que o Kube-proxy falha com?

Obrigado @luxas pelo seu interesse!

Infelizmente, não há detalhes em journalctl -xeu kubelet

Isso é tudo que encontro sobre kube-proxy (repetido várias vezes). Também anexei o log 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)"

O log completo também reclama dos kube-dns - mas isso é porque eu ainda não comecei a tecer.

log.zip

Aqui está o 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)"

Sim, eu vejo _que_ é crashlooping, mas você poderia dar, por exemplo, kubectl -n kube-system logs kube-proxy-w0ng5 ?
Então, nós realmente vemos a razão _why_: smile:

Ei, isso é brilhante :)
root @ 3551807cba77 : / # kubectl -n registros do 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

Posso consertar com uma solução alternativa: definir --conntrack-max-per-core=0 e reiniciar o proxy. Um 0-val ignora a reconfiguração de nf_conntrack_max e deixa como está (65536). Eu injeto o parâmetro de início como este:

Primeiro, insira o contêiner do docker:
docker exec -it master bash

em seguida, aplique a correção:

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'

Agora eu obtenho o CrashLoop no Weave, quando mais tarde faço um kubectl apply -f weave.yaml , o seguinte é a saída de log do pod de tecelagem:
/proc/sys/net/bridge/bridge-nf-call-iptables not found
Também tentei começar com o parâmetro kube-proxy --proxy-mode=userspace mas o mesmo resultado.

Acho que isso resolverá o problema de tecer: https://github.com/weaveworks/weave/pull/2659

@andersla Sim, isso parece resolver o problema. Você pode tentar uma versão do HEAD?
Por exemplo, você pode usar as imagens luxas/weave-(kube|npc):v1.9.0-alpha.5 do HEAD ~ ish.
Deixe-me saber se funciona e comente aqui exatamente o que você está fazendo agora (comandos do shell, Dockerfile, outros scripts, etc.) para que outros possam tirar proveito disso.

Eu usei a imagem mais recente da weaveworks / weave-kube

Eu também usei o modelo yaml mais recente https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml

Infelizmente, o kube-dns não funcionou (é muito útil em ContainerCreating. A mensagem de erro do kubelet após iniciar o weave é:

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

Se eu apenas iniciei o nó mestre e não me juntei a outro nó, então kubedns apareceu OK quando apliquei weave.yaml

Eu também testei o weave.yaml com o último weave-kube em uma instalação do Vagrant e não em meu docker-experiment e então tudo funcionou.

Este é o weave.yaml que usei 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

Ei pessoal, encontrei este tópico e ele é incrível! coisas boas.

Eu realmente quero usar essa abordagem para CI em nosso repo (que é bastante complexo, honestamente). temos um requisito de Helm / Tiller para lançar alguns gráficos para CI. Algum de vocês já se deparou com isso ou tem sugestões para fazer isso funcionar? O leme parece vomitar sozinho nesta situação:

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# 

posso tentar com outros SDNs. temos usado Calico até agora porque L3 é um pouco mais direto para solucionar problemas em situações de hacky, mas se Weave for melhor (já que é L2) ... Vou tentar o que quer que nos faça superar o problema do Tiller. Acho que Tiller está infeliz porque, no final do dia, parece que ele está associado a 127.0.0.1 ... e já vi isso causar problemas no passado ao testar outras coisas. qualquer entrada seria incrível. de novo, adereços realmente incríveis para as pessoas que estão hackeando as coisas! obrigada!!

Oi! Que bom que somos mais pessoas querendo que isso funcione. Não tenho experiência com chita. Na nuvem, estamos executando o Weave, então era isso que eu queria trabalhar neste projeto. Mas estou preso e não tive tempo para cavar mais fundo porque kube-dns não aparece quando eu aplico Weave conforme descrito acima.

Agora, a última trama estável está funcionando melhor do que antes ....

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

..mas infelizmente ainda é o mesmo problema com kube-dns não aparecendo, preso em 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

e depois de aplicar a tecelagem, esta mensagem de erro para:
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"

e em vez disso, quando vejo:

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

Se eu usar o Flannel como plugin de rede, ele funcionará.

docker exec -it master bash

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

Então, se você usa flanela, tudo está funcionando, aqui está a configuração 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

Construa com:
docker build -t kubeadm_docker .

E então execute:
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

Aguarde alguns (10-15) segundos até que o systemd e o docker estejam funcionando

Então eu inicio o kubeadm dentro do contêiner em execução:
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

Quando é iniciado, eu inicio um segundo nó "trabalhador":
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

E depois de alguns segundos (até que o systemd e o docker estejam ativados), junte-se ao mestre:
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

Quando eles estiverem unidos, - insira o mestre e aplique a solução alternativa para travar o 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 a rede de sobreposição de flanela:
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

Não tive problemas ao instalar Helm, Traefic ou GlusterFS no Kubernetes nesta configuração :)

kubeadm-dind-cluster basicamente faz o que o último comentário descreveu, fornecendo automação para que você não precise digitar os comandos manualmente (embora a partir de agora ele use o plug-in de ponte CNI com alguns hacks em vez de flanela, mas isso irei consertar bastante em breve).
Também facilita a construção de componentes k8s e kubeadm a partir de uma fonte local e o uso de binários no cluster que você inicia. Além disso, encontrei alguns problemas não aparentes ao trabalhar nele, por exemplo, agetty comendo 100% da CPU e causando travamentos do docker, a menos que você tenha o cuidado de desativá-lo.

Algumas das mudanças em breve no kubeadm-dind-cluster:

• consertar para mestre k8s, kube-proxy quebrou lá
• suporte para imagens pré-construídas (também publicarei várias dessas imagens), portanto, apenas um único script é o suficiente para iniciar o cluster. Isso pode ser útil para CI em vários projetos que usam k8s
• armazenamento em cache de diretórios de dados do Docker para reinicializações mais rápidas do cluster
• suporte para implementações CNI além de bridge

kubeadm-dind-cluster também fornece automação para testes e2e. Outra característica interessante disso é que você pode usar o mesmo mecanismo docker remoto para construir k8s e executar kubeadm-dind-cluster sem copiar de volta os binários (ele os extrai diretamente do contêiner de dados de compilação), o que pode ser importante se você estiver trabalhando com docker remoto em conexão lenta.

... esqueci de mencionar que configura o kubectl local para você, então você não precisa fazer docker exec em seu contêiner mestre para acessar seu cluster.

Como já mencionei, embora DIND possa parecer fácil na superfície, você pode ter alguns problemas inesperados com ele. Alguns dos problemas já foram corrigidos no kubeadm-dind-cluster e na imagem base que ele usa. Por exemplo, você precisa fazer algumas montagens , também precisa usar STOPSIGNAL SIGRTMIN+3 e resistir à tentação de usar /sbin/init como ENTRYPOINT , e o driver vfs pode ser muito lento às vezes. Então ... aqui estão os dragões;)

@ ivan4th Obrigado por todo o trabalho que você tem feito com kubeadm e dind :)
Você pode abrir um novo problema referenciando este problema, onde podemos discutir o MVP necessário para mesclar kubeadm-dind-cluster a este repo?

Depois de olhar rapidamente, encontrei alguns pontos que podemos querer fazer antes de um possível MVP:

• Idealmente, deveria ser escrito em Go - geralmente acho que estamos tentando nos afastar do Bash, então Go é a melhor maneira de ir para um novo projeto, eu acho :)
• A base debian deve ser baseada em gcr.io/google-containers/debian-base-$(ARCH):0.1
  
  
  
  • Idealmente, a imagem base do dind deve ser publicada no gcr.io
  
  
• Deve funcionar em vários arcos como o kubeadm
• Você deve ser capaz de fornecer seus próprios binários, mas na maioria das vezes ele deve baixar do CI que publica binários para todos os arcos a cada hora
• Deve usar CNI - com provedores de rede trocáveis
• Ele deve expor suas opções de configuração por meio de um arquivo de configuração como o kubeadm pode receber um arquivo de configuração como entrada para as opções
• Deve ser compatível apenas com kubeadm v1.6 +

O que você acha? Obrigado pelo início incrível, mal posso esperar para realmente integrar isso em algo oficial do kubeadm: +1:

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

Obrigado pelo início incrível, mal posso esperar para realmente integrar isso em algo oficial do kubeadm

se pudermos devel-build, kubeadm-local-up-cluster, isso seria fantástico.

@ ivan4th @luxas Qual é a situação disso?

Na verdade não sei ... @ ivan4th

@jamiehannaford

• a partir de agora, demorei para reescrever Go porque também preciso trabalhar em outros projetos
• O kdc tem suporte para diferentes impls CNI (Weave, Calico, Flannel e ponte CNI simples que é o padrão)
• o suporte a múltiplas arquiteturas ainda não está aqui, mas é bastante factível
• os binários que são usados ​​nas imagens são, por padrão, retirados da versão k8s, mas você pode construir o seu próprio ou, com algum pequeno esforço, fazer uma imagem baseada em seus próprios binários construídos separadamente
• ele suporta arquivo de configuração, mas a partir de agora é na verdade um conjunto de env vars
• a imagem base ainda é ubuntu, mas vamos mudar para debian
• oferecemos suporte a 1.6 e adicionarei suporte a 1.7 no início da semana que vem

No geral, o kdc é bastante utilizável em sua forma atual, IMO. Ele também tem seu próprio CI público baseado no Travis (aliás, eu também consegui executar DIND no CircleCI se for de algum interesse)

@luxas Talvez possamos usar @andersla 's solução , em vez de um cluster DNID cheia? Em caso afirmativo, precisaríamos hospedar a imagem Docker em qualquer lugar ou apenas documentar a aparência do Dockerfile?

Seria ótimo se pudéssemos corrigir esse problema para 1.9

Não tenho ciclos para trabalhar nisso. Se alguém mais, por favor, faça!

O problema de https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (acho que vou precisar enviar uma correção para k8s para isso). A partir do kubeadm-dind-cluster , ainda é bastante utilizável e tento mantê-lo atualizado ( @danehans e @pmichali estão usando para testes k8s IPv6 e2e e Virtlet usa para executar seus testes e2e no CircleCI), embora eu passe muito tempo em outros projetos, então ainda não consegui reescrevê-lo no Go.

Falamos sobre isso na reunião da SIG ontem e vamos encerrar o problema.
O desenvolvimento e a manutenção de uma solução DIND completa não estão no escopo da equipe principal do kubeadm em um futuro previsível, ou nunca. No entanto, estamos muito felizes que a comunidade forneça essas soluções, como o trabalho árduo de @ ivan4th no projeto Mirantis. Se encontrarmos um bom lugar para documentar a possibilidade de usar esse projeto, estou pessoalmente bem em fazer referência a ele. Obrigado!