Kubeadm: 컨테이너에서 kubeadm을 실행하기 위한 스크립트 제공 및 방법 문서화

_2016년 10월 27일 18시 14 분 에 @luxas에서

cc @errordeveloper 및 @marun 은 컨테이너 내부에서 시스템을 실행하고

@andersla 컨테이너 내에서 이런 식으로 systemd를 실행하는 것은 ootb를 지원하지 않는다는 점에 유의하십시오.

_2016년 10월 28일 7:36 @zreigz 에서_

실례가 되지 않는다면 좀 더 자세히 살펴보고 수정하도록 하겠습니다.

_@ andersla 에서 2016년 10월 28일 8:48_

@zreigz 해주세요!
이것이 내가 설치하려고하는 방법입니다.

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

그리고:

echo "Updating Ubuntu..."
apt-get update -y
apt-get upgrade -y

echo "Install os requirements"
apt-get install -y \
  curl \
  apt-transport-https \
  dialog \
  python \
  daemon

echo "Add Kubernetes repo..."
sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
apt-get update -y

echo "Installing Kubernetes requirements..."
apt-get install -y \
  docker.io \
  kubelet \
  kubernetes-cni \
  kubectl \
  kubeadm

그리고 이것은 kubeadm을 설치할 때 발생하는 오류입니다.

root<strong i="16">@82f5321d45cb</strong>:/# apt-get install kubeadm
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  kubeadm
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 7981 kB of archives.
After this operation, 59.2 MB of additional disk space will be used.
Get:1 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 kubeadm amd64 1.5.0-alpha.0-1534-gcf7301f-00 [7981 kB]
Fetched 7981 kB in 0s (8532 kB/s)
Selecting previously unselected package kubeadm.
(Reading database ... 14222 files and directories currently installed.)
Preparing to unpack .../kubeadm_1.5.0-alpha.0-1534-gcf7301f-00_amd64.deb ...
Unpacking kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
Setting up kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
Failed to connect to bus: No such file or directory
dpkg: error processing package kubeadm (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 kubeadm
E: Sub-process /usr/bin/dpkg returned an error code (1)

_2016년 10월 28일 9시 10분 @zreigz 에서_

나는 그것을 재현하고 나는 이것을 작업하고있다

_2016년 10월 31일 7:24 @zreigz 에서_

두 가지 문제가 있습니다.

첫 번째: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
Ubuntu 시스템에서 /bin/sh는 bash가 아니라 dash이며 dash는 이중 괄호 키워드를 지원하지 않습니다. 좋은 점은 문제가 마스터 브랜치에서 수정되었으며 곧 사용할 수 있다는 것입니다: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40

두 번째는 그렇게 사소하지 않습니다. 컨테이너에서 systemctl을 실행하면 Failed to get D-Bus connection 실패합니다. systemd가 컨테이너에서 제대로 작동하지 않는 것 같습니다. 이제 나는 이것을 위해 일하고있다.

_2016년 10월 31일 7:42 @andersla 에서_

엄청난!
kubeadm 설치에 왜 systemd/systemctl이 필요한지 모르겠습니다.

_2016년 10월 31일 7:47 @zreigz 에서_

이 두 줄 때문에: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25

systemctl daemon-reload
systemctl restart kubelet

첫 번째 줄에서 실패합니다.

_2016년 10월 31일 7:48 @zreigz 에서_

이것은 설명입니다:

# because kubeadm package adds kubelet drop-ins, we must daemon-reload
# and restart kubelet now. restarting kubelet is ok because kubelet
# postinst configure step auto-starts it.

_2016년 10월 31일 7:52 @zreigz 에서_

작동하게 하는 몇 가지 구성 단계가 있지만 먼저 시도해야 합니다. 뭔가 찾으면 알려드리겠습니다.

_2016년 11월 2일 7:19 @zreigz 에서_

좋은 소식. 모든 문제를 해결했습니다. 마지막 테스트가 필요하며 Docker 컨테이너에서 kubeadm을 실행하는 방법을 게시할 것입니다.

_@ andersla 에서 2016년 11월 2일 7:23_

감독자! 테스트가 준비되는 대로 도와드리겠습니다! - 비록 이번 주 나머지는 공휴일이지만:)

_From @zreigz 년 11 월 2 일 2016 년 10 : 13_

Docker 컨테이너에 kubeadm을 설치하는 것과 관련하여 두 가지 주요 문제가 있습니다. 첫 번째는 컨테이너에서 실행되는 systemd입니다. 두 번째는 컨테이너 내부에 도커를 설치하는 것입니다. 문제가 성공적으로 수정되었습니다. Ubuntu 이미지를 준비하는 데 사용해야 하는 Dockerfile은 다음과 같습니다.

FROM ubuntu
ENV container docker
RUN apt-get -y update

RUN apt-get update -qq && apt-get install -qqy \
    apt-transport-https \
    ca-certificates \
    curl \
    lxc \
    vim \
    iptables

RUN curl -sSL https://get.docker.com/ | sh

RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;

VOLUME /sys/fs/cgroup
VOLUME /var/run/docker.sock
CMD /sbin/init

이 명령을 사용하여 Dockerfile이 포함된 디렉토리에 이미지를 빌드합니다.

docker build -t kubeadm_docker .

이제 준비된 이미지를 실행하고 kubeadm 설치를 마칠 수 있습니다.
다음 명령을 사용하여 kubeadm_docker 이미지를 실행합니다.

docker run -it -e "container=docker" --privileged=true -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock  kubeadm_docker /sbin/init

실행 중인 컨테이너 ID 찾기

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
7dd73057620d        kubeadm_docker      "/sbin/init"        About an hour ago   Up About an hour                        furious_fermi

이제 컨테이너 콘솔을 열 수 있습니다.

docker exec -it 7dd73057620d /bin/bash

이것은 kubeadm을 설치하기 위한 스크립트(약간의 수정 포함)입니다.

echo "Updating Ubuntu..."
apt-get update -y
apt-get upgrade -y

systemctl start docker

echo "Install os requirements"
apt-get install -y \
  curl \
  apt-transport-https \
  dialog \
  python \
  daemon

echo "Add Kubernetes repo..."
sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
apt-get update -y

echo "Installing Kubernetes requirements..."
apt-get install -y \
  kubelet

# This is temporary fix until new version will be released
sed -i 38,40d /var/lib/dpkg/info/kubelet.postinst

apt-get install -y \
  kubernetes-cni \
  kubectl \
  kubeadm

그리고 마지막으로 실행할 수 있습니다

# kubeadm init

모든 것이 로컬 컴퓨터와 동일하게 작동합니다.
행운을 빕니다 :)

_2016년 11월 17일 7시 21 분 에

@zreigz 저와 같은 문제를 해결했습니다. 감사합니다!

_2016년 11월 17일 7시 30분 @zreigz 에서_

괜찮아요 :)

docker-in-docker로 CI를 설정해야 합니다.

@errordeveloper @zreigz 이 작업을 수행할 수 있습니까?
적어도 컨테이너 내부에서 kubeadm을 실행하는 방법을 어딘가에 문서화해야 합니다...

나에게 좋은 소리. 확실히 우리는 이 모든 것을 도커 이미지에 추가하고 마스터와 노드를 구별하기 위해 일부 구성/시작 스크립트를 넣어야 합니다. 좋은 시작은 kubernetes/kubeadm-docker와 같은 프로젝트를 만드는 것입니다. Dockerfile, 스크립트 및 문서를 위한 올바른 장소이기도 합니다.

먼저 zreigz/ 아래에 개인 프로젝트로 생성하고 결국에는 해당 코드를 이 리포지토리에 병합할 것입니다.

하지만 먼저 자신의 공간에서 프로토타입을 만들고 어떻게 진행되는지 살펴보겠습니다.

실제 양수인은 @zreigz입니다.

네 좋은 지적입니다. 나는 그것을 할 것이다. 다음주(월요일,화요일) 회의중이라 수요일부터 시작하겠습니다.

@luxas kubeadm 및 kubernetes-cni 패키지를 어떻게 제공해야 하는지 궁금합니다. 현재 소스에서 빌드해야 하거나(최신 구현을 테스트할 수 있도록) 저장소에서 최신 버전을 다운로드해야 합니까? CI 목적을 위해 테스트할 수 있는 코드의 현재 상태가 있어야 합니까, 아니면 릴리스 버전을 테스트하는 데 필요한 것입니까?

안녕하세요 수정해 주셔서 감사합니다. 하지만 kubeadm init 후에도 여전히 문제가 발생합니다. DNS에서 0/3이 표시되고, DNS가 전혀 실행되지 않는 것 같습니다.

2.0초마다: kubectl get pods --all-namespaces Fri Dec 16 17:00:50 2016

네임스페이스 이름 준비 상태 다시 시작 나이
kube-system dummy-2088944543-17sey 1/1 실행 0 11m
kube-system etcd-8dd8c92c6c38 1/1 러닝 2 12m
kube-system kube-apiserver-8dd8c92c6c38 1/1 실행 4 12m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 러닝 2 11m
kube-system kube-discovery-1150918428-m506w 1/1 실행 중 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 러닝 2 10m

네트워크 정책 설치 시도
root@8dd8c92c6c38 :/# kubectl 적용 -f calico.yaml
"calico.yaml" 경로가 존재하지 않습니다
root@8dd8c92c6c38 :/# kubectl create -f calico.yaml
"calico.yaml" 경로가 존재하지 않습니다
root@8dd8c92c6c38 :/# kubectl 적용 -f kube-flannel.yml
"kube-flannel.yml" 경로가 존재하지 않습니다

root@8dd8c92c6c38 :/# kubectl 적용 -f https://git.io/weave-kube
데몬셋 "weave-net" 생성
root@8dd8c92c6c38 :/# kubectl get pods --all-namespaces
네임스페이스 이름 준비 상태 다시 시작 나이
kube-system dummy-2088944543-17sey 1/1 러닝 0 46m
kube-system etcd-8dd8c92c6c38 1/1 러닝 2 46m
kube-system kube-apiserver-8dd8c92c6c38 1/1 실행 4 46m
kube-system kube-controller-manager-8dd8c92c6c38 1/1 러닝 2 45m
kube-system kube-discovery-1150918428-9m6rr 0/1 보류 중 0 3m
kube-system kube-dns-654381707-vuijm 0/3 컨테이너 생성 0 45m
kube-system kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
kube-system kube-scheduler-8dd8c92c6c38 1/1 러닝 2 44m
kube-system weave-net-iv0bc 0/2 ContainerCreating 0 49s
정보: 1개의 완료된 개체가 포드 목록에 표시되지 않았습니다. 모든 객체를 보려면 --show-all을 전달하십시오.

안녕하세요 @zreigz
이제 마침내 이것으로 더 나아가 테스트 할 시간이 생겼습니다. 거의 만들 수 있지만 docker가 vfs 스토리지 드라이버를 선택하는 오류가 있습니다 (아마도 aufs 위에 aufs를 사용할 수 없기 때문일 것입니다. 그러나 해결 방법을 설명하는 것처럼 위의 외부 도커 .sock을 내부 도커에 장착하고 있으므로 aufs로 쓸 수 있어야 합니까?
내 호스트 컴퓨터에서 docker info aufs 스토리지 드라이버를 실행 중이라고 표시됩니다. - 반면 kubernetes를 사용하여 도커 컨테이너 내부에서 docker info 를 수행하면 vfs 스토리지 드라이버를 사용하고 있다고 표시됩니다.
실행할 때 다음 문제가 발생하는 이유에 대한 아이디어
kubeadm init

root<strong i="13">@f50f087baa83</strong>:/# kubeadm init
[kubeadm] WARNING: kubeadm is in alpha, please do not use it for production clusters.
[preflight] Running pre-flight checks
[preflight] The system verification failed. Printing the output from the verification:
OS: Linux
KERNEL_VERSION: 4.4.0-43-generic
CONFIG_NAMESPACES: enabled
CONFIG_NET_NS: enabled
CONFIG_PID_NS: enabled
CONFIG_IPC_NS: enabled
CONFIG_UTS_NS: enabled
CONFIG_CGROUPS: enabled
CONFIG_CGROUP_CPUACCT: enabled
CONFIG_CGROUP_DEVICE: enabled
CONFIG_CGROUP_FREEZER: enabled
CONFIG_CGROUP_SCHED: enabled
CONFIG_CPUSETS: enabled
CONFIG_MEMCG: enabled
CONFIG_INET: enabled
CONFIG_EXT4_FS: enabled
CONFIG_PROC_FS: enabled
CONFIG_NETFILTER_XT_TARGET_REDIRECT: enabled (as module)
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled (as module)
CONFIG_OVERLAY_FS: enabled (as module)
CONFIG_AUFS_FS: enabled (as module)
CONFIG_BLK_DEV_DM: enabled
CGROUPS_CPU: enabled
CGROUPS_CPUACCT: enabled
CGROUPS_CPUSET: enabled
CGROUPS_DEVICES: enabled
CGROUPS_FREEZER: enabled
CGROUPS_MEMORY: enabled
DOCKER_VERSION: 1.12.1
DOCKER_GRAPH_DRIVER: vfs
[preflight] Some fatal errors occurred:
    unsupported graph driver: vfs
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
root<strong i="14">@f50f087baa83</strong>:/# 

조금 더 시도한 후 추가 정보.
호스트에서 도커 스토리지 드라이버를 "오버레이"로 변경했습니다. 그런 다음 docker 내부의 docker는 aufs를 드라이버로 선택했습니다. "사전 비행 검사"를 통과했지만 지금은
[apiclient] Created API client, waiting for the control plane to become ready

다른 테스트에서 도커가 /sbin/init를 통해 서비스로 시작되었을 때 동일한 스토리지 드라이버를 선택하지 않는다는 것을 깨달았습니다.
도커 이미지를 이런 식으로 실행하면 호스트와 동일한 드라이버가 시작되지 않습니다(위에서 언급한 대로).
sudo docker run -it --privileged=true -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /sbin/init

/sbin/init 없이 시작하고 다음과 같은 데몬이 아닌 경우:
sudo docker run -it --privileged=true --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /var/run/docker.sock:/var/run/docker.sock kubeadm_docker /bin/bash 그러면 도커가 호스트와 동일한 스토리지 드라이버를 선택했습니다(그러나 지금은 systemctrl 가 작동하지 않음).

추가 업데이트:

이제 이 Dockerfile을 사용하여 작동하는 kubeadm-in-docker-container를 빌드할 수 있습니다.

FROM ubuntu:xenial-20161213

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -qq

RUN apt-get install -y \
    apt-transport-https \
    apt-utils \
    ca-certificates \
    curl \
    dialog \
    python \
    daemon \
    vim \
    jq \
    linux-image-$(uname -r)

# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
  rm -f /lib/systemd/system/multi-user.target.wants/*;\
  rm -f /etc/systemd/system/*.wants/*;\
  rm -f /lib/systemd/system/local-fs.target.wants/*; \
  rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
  rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
  rm -f /lib/systemd/system/basic.target.wants/*;\
  rm -f /lib/systemd/system/anaconda.target.wants/*;

# install docker (after removing unwanted systemd)
RUN apt-get install -y \
    docker.io

RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'

RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
  kubelet \
  kubernetes-cni \
  kubectl

RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
  kubeadm; exit 0

# Create volume for docker
VOLUME /var/lib/docker

다음으로 빌드: docker build -t kubeadm_docker .

그런 다음 다음을 실행합니다.

docker run -it --privileged=true --name=master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init

systemd 및 docker가 실행될 때까지 몇 초(10-15초) 기다립니다.

그런 다음 실행 중인 컨테이너 내에서 kubeadm을 시작합니다.
docker exec -it master kubeadm init --token=acbec6.2852dff7cb569aa0

시작될 때 두 번째 "작업자" 노드를 시작합니다.

docker run -it --privileged=true --name=node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init
그리고 몇 초 후에 마스터에 합류하십시오.

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

현재 kube-proxy가 실패하고 CrashLoopBackOff에 들어가기 때문에 도커 네트워크에 몇 가지 문제가 있습니다.

위의 도커를 실행할 때 대신 --net=host 하면 kube-proxy와 모든 포드가 정상적으로 작동합니다. 하지만 컨테이너가 ip를 사용하여 도커 네트워크에서 실행되어야 하므로 옵션이 아닙니다. NS

나는 또한 이전에 호스트에서와 동일한 프로세스로 도커를 실행하려고 시도했지만: -v /var/run/docker.sock:/var/run/docker.sock 컨테이너 내부의 도커가 systemd로 시작될 때 양말을 선택하지 않기 때문에 작동하지 않습니다. 저것).

@andersla 감사합니다!
kube-proxy가 실패하는 것을 붙여넣을 수 있습니까?

관심을 가져 주셔서 감사합니다

불행히도 journalctl -xeu kubelet 세부정보가 없습니다.

이것이 내가 kube-proxy에 대해 찾은 전부입니다(여러 번 반복됨) 전체 로그도 첨부합니다.

Jan 09 14:40:02 1355b98bf8c7 kubelet[244]: I0109 14:40:02.690862     244 docker_manager.go:2524] checking backoff for container "kube-proxy" in pod "kube-proxy-7886l"
Jan 09 14:40:03 1355b98bf8c7 kubelet[244]: I0109 14:40:03.984818     244 docker_manager.go:2538] Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-7886l_kube-system(71a1e950-d679-11e6-a9f7-02429d4c0f01)
Jan 09 14:40:03 1355b98bf8c7 kubelet[244]: E0109 14:40:03.984833     244 pod_workers.go:184] Error syncing pod 71a1e950-d679-11e6-a9f7-02429d4c0f01, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-7886l_kube-system(71a1e950-d679-11e6-a9f7-02429d4c0f01)"

전체 로그도 kube-dns에 대해 불평합니다. 하지만 그건 제가 아직 weve를 시작하지 않았기 때문입니다.

log.zip

kubectl describe pod -n kube-system kube-proxy-w0ng5 로그입니다.

Name:       kube-proxy-w0ng5
Namespace:  kube-system
Node:       3551807cba77/172.17.0.2
Start Time: Tue, 10 Jan 2017 18:03:06 +0000
Labels:     component=kube-proxy
        k8s-app=kube-proxy
        kubernetes.io/cluster-service=true
        name=kube-proxy
        tier=node
Status:     Running
IP:     172.17.0.2
Controllers:    DaemonSet/kube-proxy
Containers:
  kube-proxy:
    Container ID:   docker://dcc2bc0b50a2477b72d451b776f35e327f1faf09e3cddb25d5609569c6f2a242
    Image:      gcr.io/google_containers/kube-proxy-amd64:v1.5.1
    Image ID:       docker-pullable://gcr.io/google_containers/kube-proxy-amd64<strong i="7">@sha256</strong>:3b82b2e0862b3c0ece915de29a5a53634c9b0a73140340f232533c645decbd4b
    Port:       
    Command:
      kube-proxy
      --kubeconfig=/run/kubeconfig
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 10 Jan 2017 18:08:48 +0000
      Finished:     Tue, 10 Jan 2017 18:08:48 +0000
    Ready:      False
    Restart Count:  6
    Volume Mounts:
      /run/kubeconfig from kubeconfig (rw)
      /var/run/dbus from dbus (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-g0ft5 (ro)
    Environment Variables:  <none>
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  kubeconfig:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/kubernetes/kubelet.conf
  dbus:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/dbus
  default-token-g0ft5:
    Type:   Secret (a volume populated by a Secret)
    SecretName: default-token-g0ft5
QoS Class:  BestEffort
Tolerations:    dedicated=master:NoSchedule
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath           Type        Reason  Message
  --------- --------    -----   ----            -------------           --------    ------  -------
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      Pullingpulling image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1"
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      CreatedCreated container with docker id ecf446de342a; Security:[seccomp=unconfined]
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      StartedStarted container with docker id ecf446de342a
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      Pulled  Successfully pulled image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1"
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      CreatedCreated container with docker id f562fb667a64; Security:[seccomp=unconfined]
  9m        9m      1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal      StartedStarted container with docker id f562fb667a64
  9m        9m      2   {kubelet 3551807cba77}                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 10s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  9m    9m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id 1a7d7d4f682b
  9m    9m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id 1a7d7d4f682b; Security:[seccomp=unconfined]
  9m    9m  2   {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id 89bdf4ba7e0b
  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id 89bdf4ba7e0b; Security:[seccomp=unconfined]
  8m    8m  3   {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 40s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id f2b7a2b5078d; Security:[seccomp=unconfined]
  8m    8m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id f2b7a2b5078d
  8m    7m  6   {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  6m    6m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id 28deaf41d920; Security:[seccomp=unconfined]
  6m    6m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id 28deaf41d920
  6m    4m  12  {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

  9m    4m  6   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Pulled      Container image "gcr.io/google_containers/kube-proxy-amd64:v1.5.1" already present on machine
  4m    4m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Created     Created container with docker id dcc2bc0b50a2; Security:[seccomp=unconfined]
  4m    4m  1   {kubelet 3551807cba77}  spec.containers{kube-proxy} Normal  Started     Started container with docker id dcc2bc0b50a2
  9m    10s 43  {kubelet 3551807cba77}  spec.containers{kube-proxy} Warning BackOff     Back-off restarting failed docker container
  4m    10s 18  {kubelet 3551807cba77}                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "kube-proxy" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=kube-proxy pod=kube-proxy-w0ng5_kube-system(09c4f65d-d75f-11e6-814c-0242255c9a68)"

예, _그_는 크래시루핑인 것을 알지만 kubectl -n kube-system logs kube-proxy-w0ng5 를 줄 수 있습니까?
그래서 우리는 실제로 그 이유를 _why_ :smile:

이야 멋지네요 :)
root@3551807cba77 :/# kubectl -n kube-system 로그 kube-proxy-w0ng5

I0110 18:29:01.705993       1 server.go:215] Using iptables Proxier.
W0110 18:29:01.706933       1 proxier.go:254] clusterCIDR not specified, unable to distinguish between internal and external traffic
I0110 18:29:01.706947       1 server.go:227] Tearing down userspace rules.
I0110 18:29:01.712693       1 conntrack.go:81] Set sysctl 'net/netfilter/nf_conntrack_max' to 262144
I0110 18:29:01.712927       1 conntrack.go:66] Setting conntrack hashsize to 65536
write /sys/module/nf_conntrack/parameters/hashsize: operation not supported

해결 방법으로 해결할 수 있습니다. --conntrack-max-per-core=0 를 설정한 다음 프록시를 다시 시작합니다. 0-val은 nf_conntrack_max 재구성을 건너뛰고 그대로 둡니다(65536). 다음과 같이 시작 매개변수를 주입합니다.

먼저 도커 컨테이너를 입력하십시오.
docker exec -it master bash

그런 다음 수정 사항을 적용하십시오.

kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'

이제 나중에 kubectl apply -f weave.yaml 수행할 때 대신 Weave에서 CrashLoop를 얻습니다. 다음은 weave 포드의 로그 출력입니다.
/proc/sys/net/bridge/bridge-nf-call-iptables not found
또한 kube-proxy 매개변수 --proxy-mode=userspace 했지만 결과는 동일했습니다.

나는 이것이 직조 문제를 해결할 것이라고 생각합니다: https://github.com/weaveworks/weave/pull/2659

@andersla 예, 문제를 해결하는 것 같습니다. HEAD에서 빌드를 시도할 수 있습니까?
예를 들어 HEAD~ish에서 가져온 luxas/weave-(kube|npc):v1.9.0-alpha.5 이미지를 사용할 수 있습니다.
작동하는지 알려주고 다른 사람들이 이를 활용할 수 있도록 지금 하고 있는 작업(셸 명령, Dockerfile, 기타 스크립트 등)을 여기에 정확히 설명하세요.

weaveworks/weave-kube의 최신 이미지를 사용했습니다.

나는 또한 최신 yaml-template https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml을 사용했습니다.

불행히도 kube-dns가 작동하지 않았습니다(ContainerCreating에 그대로 있습니다. weave를 시작한 후 kubelet의 오류 메시지는 다음과 같습니다.

an 15 16:14:30 7c12205804da kubelet[540]: I0115 16:14:30.443327     540 operation_executor.go:917] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/c23fb73d-db39-11e6-b84d-0242b1ac1840-default-token-142vd" (spec.Name: "default-token-142vd") pod "c23fb73d-db39-11e6-b84d-0242b1ac1840" (UID: "c23fb73d-db39-11e6-b84d-0242b1ac1840").
Jan 15 16:14:31 7c12205804da kubelet[540]: E0115 16:14:31.381741     540 docker_manager.go:373] NetworkPlugin cni failed on the status hook for pod 'kube-dns-2924299975-9gjcg' - Unexpected command output Device "eth0" does not exist.
Jan 15 16:14:31 7c12205804da kubelet[540]:  with error: exit status 1

마스터 노드만 시작하고 다른 노드에 합류하지 않으면 weave.yaml을 적용했을 때 kubedns가 정상적으로 나타납니다.

또한 도커 실험이 아닌 Vagrant 설치에서 최신 weave-kube로 weave.yaml을 테스트한 다음 모두 작동했습니다.

kubectl apply -f weave.yaml 사용한 weave.yaml입니다.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: weave-net
  namespace: kube-system
spec:
  template:
    metadata:
      labels:
        name: weave-net
      annotations:
        scheduler.alpha.kubernetes.io/tolerations: |
          [
            {
              "key": "dedicated",
              "operator": "Equal",
              "value": "master",
              "effect": "NoSchedule"
            }
          ]
    spec:
      hostNetwork: true
      hostPID: true
      containers:
        - name: weave
          image: weaveworks/weave-kube:latest
          imagePullPolicy: Always
          command:
            - /home/weave/launch.sh
          livenessProbe:
            initialDelaySeconds: 30
            httpGet:
              host: 127.0.0.1
              path: /status
              port: 6784
          securityContext:
            privileged: true
          volumeMounts:
            - name: weavedb
              mountPath: /weavedb
            - name: cni-bin
              mountPath: /host/opt
            - name: cni-bin2
              mountPath: /host/home
            - name: cni-conf
              mountPath: /host/etc
            - name: dbus
              mountPath: /host/var/lib/dbus
          resources:
            requests:
              cpu: 10m
        - name: weave-npc
          image: weaveworks/weave-npc:latest
          imagePullPolicy: Always
          resources:
            requests:
              cpu: 10m
          securityContext:
            privileged: true
      restartPolicy: Always
      volumes:
        - name: weavedb
          emptyDir: {}
        - name: cni-bin
          hostPath:
            path: /opt
        - name: cni-bin2
          hostPath:
            path: /home
        - name: cni-conf
          hostPath:
            path: /etc
        - name: dbus
          hostPath:
            path: /var/lib/dbus

안녕 얘들아, 나는이 스레드에 부딪쳤고 그것은 바위를 망쳐 놓았다! 좋은 물건.

나는 우리 repo에 대해 CI에 이 접근 방식을 사용하고 싶습니다(솔직히 상당히 복잡합니다). 우리는 CI용 차트를 몇 개 시작하기 위한 Helm/Tiller 요구 사항이 있습니다. 이 문제가 발생했거나 이 작업을 수행하기 위한 제안 사항이 있습니까? Tiller는 이 상황에서 스스로를 헐뜯는 것 같습니다.

root<strong i="7">@JINKITNIX05</strong>:~/openstack-helm# kubectl logs tiller-deploy-3299276078-6kdzw -n kube-system
Error from server (BadRequest): the server rejected our request for an unknown reason (get pods tiller-deploy-3299276078-6kdzw)
root<strong i="8">@JINKITNIX05</strong>:~/openstack-helm# 

다른 SDN으로 시도할 수 있습니다. L3가 해킹된 상황에서 문제를 해결하기가 조금 더 간단하기 때문에 지금까지 Calico를 사용해 왔지만 Weave가 더 낫다면(L2이기 때문에)... Tiller 문제를 극복할 수 있는 모든 것을 시도할 것입니다. Tiller는 결국 127.0.0.1과 관련이 있는 것처럼 보이기 때문에 불행하다고 생각합니다. 과거에 다른 테스트에서 문제가 발생하는 것을 보았기 때문입니다. 어떤 입력도 놀랍습니다. 다시 말하지만, 물건을 해킹하는 사람들에게 정말 멋진 소품입니다! 감사 해요!!

안녕하세요! 더 많은 사람들이 이 기능을 사용하기를 원하는 것이 좋습니다. 저는 옥양목에 대한 경험이 없습니다. 클라우드에서 Weave를 실행하고 있으므로 이 프로젝트에서 작업하고 싶었습니다. 그러나 나는 막혔고 위에서 설명한 대로 We 적용할 때 kube-dns가 나타나지 않는 이유를 더 파고들 시간이 없었습니다.

이제 최신 안정적인 직조가 이전보다 더 잘 작동합니다....

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

..하지만 불행히도 kube-dns가 나타나지 않는 동일한 문제가 ContainerCreating에서 멈췄습니다.

root<strong i="9">@18a7d1ec5124</strong>:/# kubectl get pods --all-namespaces
NAMESPACE     NAME                                   READY     STATUS              RESTARTS   AGE
kube-system   dummy-2088944543-pvvdx                 1/1       Running             0          5m
kube-system   etcd-18a7d1ec5124                      1/1       Running             0          4m
kube-system   kube-apiserver-18a7d1ec5124            1/1       Running             2          5m
kube-system   kube-controller-manager-18a7d1ec5124   1/1       Running             0          4m
kube-system   kube-discovery-1769846148-6tv4l        1/1       Running             0          5m
kube-system   kube-dns-2924299975-4608d              0/4       ContainerCreating   0          5m
kube-system   kube-proxy-k0stq                       1/1       Running             0          4m
kube-system   kube-proxy-tnm8h                       1/1       Running             0          4m
kube-system   kube-scheduler-18a7d1ec5124            1/1       Running             0          4m
kube-system   weave-net-mff6t                        2/2       Running             0          3m
kube-system   weave-net-t7zcl                        2/2       Running             0          3m

weave를 적용한 후 이 오류 메시지가 중지됩니다.
Feb 04 18:06:57 18a7d1ec5124 kubelet[252]: E0204 18:06:57.125434 252 pod_workers.go:184] Error syncing pod 7dc68091-eb04-11e6-a321-02425e578ba1, skipping: failed to "SetupNetwork" for "kube-dns-2924299975-4608d_kube-system" with SetupNetworkError: "Failed to setup network for pod \"kube-dns-2924299975-4608d_kube-system(7dc68091-eb04-11e6-a321-02425e578ba1)\" using network plugins \"cni\": cni config unintialized; Skipping pod"

대신 일단 내가 볼 때 :

Feb 04 18:06:59 18a7d1ec5124 kubelet[252]: E0204 18:06:59.615375 252 docker_manager.go:373] NetworkPlugin cni failed on the status hook for pod 'kube-dns-2924299975-4608d' - Unexpected command output Device "eth0" does not exist. Feb 04 18:06:59 18a7d1ec5124 kubelet[252]: with error: exit status 1

Flannel을 네트워크 플러그인으로 대신 사용하면 작동합니다.

docker exec -it master bash

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

따라서 Flannel을 사용하는 경우 모든 것이 작동하며 다음은 전체 설정입니다.

도커 파일:

FROM ubuntu:xenial-20161213

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -qq

RUN apt-get install -y \
    apt-transport-https \
    apt-utils \
    ca-certificates \
    curl \
    dialog \
    python \
    daemon \
    vim \
    jq

# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
  rm -f /lib/systemd/system/multi-user.target.wants/*;\
  rm -f /etc/systemd/system/*.wants/*;\
  rm -f /lib/systemd/system/local-fs.target.wants/*; \
  rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
  rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
  rm -f /lib/systemd/system/basic.target.wants/*;\
  rm -f /lib/systemd/system/anaconda.target.wants/*;

# install docker (after removing unwanted systemd)
RUN apt-get install -y \
    docker.io

RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'

RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
  kubelet \
  kubernetes-cni \
  kubectl

RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
  kubeadm; exit 0

# Create volume for docker
VOLUME /var/lib/docker

다음을 사용하여 빌드하십시오.
docker build -t kubeadm_docker .

그런 다음 다음을 실행합니다.
docker run -it --privileged=true --name=master -h master -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init

systemd 및 docker가 실행될 때까지 몇 초(10-15초) 기다립니다.

그런 다음 실행 중인 컨테이너 내에서 kubeadm을 시작합니다.
docker exec -it master kubeadm init --skip-preflight-checks --token=acbec6.2852dff7cb569aa0

시작될 때 두 번째 "작업자" 노드를 시작합니다.
docker run -it --privileged=true --name=node -h node -d --security-opt seccomp:unconfined --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro kubeadm_docker /sbin/init

그리고 몇 초 후(systemd 및 docker가 작동할 때까지) 마스터에 참여합니다.
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

그들이 합류하면 - 마스터를 입력하고 kube-proxy 충돌에 대한 해결 방법을 적용하십시오.
docker exec -it master bash

kubectl -n kube-system get ds -l 'component=kube-proxy' -o json | jq '.items[0].spec.template.spec.containers[0].command |= .+ ["--conntrack-max-per-core=0"]' | kubectl apply -f - && kubectl -n kube-system delete pods -l 'component=kube-proxy'

마지막으로 플란넬 오버레이 네트워크를 적용합니다.
curl -sSL "https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml?raw=true" | kubectl create -f -

이 설정에서 Kubernetes에 Helm, Traefic 또는 GlusterFS를 설치하는 데 문제가 없었습니다. :)

kubeadm-dind-cluster는 기본적으로 마지막 설명에서 설명한 대로 자동화를 제공하므로 수동으로 명령을 입력할 필요가 없습니다. 곧).
또한 로컬 소스에서 k8s 구성 요소와 kubeadm을 모두 쉽게 빌드하고 시작하는 클러스터의 바이너리를 사용할 수 있습니다. 게다가, 작업하는 동안 내가 마주쳤던 겉보기에 보이지 않는 문제가 있었습니다. 예를 들어, agetty가 100% CPU를 먹고, 비활성화에 주의하지 않는 한 도커 충돌을 일으키는 등의 문제가 있었습니다.

kubeadm-dind-cluster에 곧 적용될 몇 가지 변경 사항:

• k8s 마스터용으로 수정, kube-proxy가 고장났습니다.
• 미리 빌드된 이미지에 대한 지원(이러한 여러 이미지도 게시할 예정임)이므로 단일 스크립트만으로도 클러스터를 시작하기에 충분합니다. k8s를 사용하는 다양한 프로젝트의 CI에 유용할 수 있습니다.
• 더 빠른 클러스터 다시 시작을 위한 Docker 데이터 디렉토리 캐싱
• 브리지 이외의 CNI 구현 지원

kubeadm-dind-cluster는 e2e 테스트를 위한 자동화도 제공합니다. 그것의 또 다른 흥미로운 특성은 바이너리를 다시 복사하지 않고(빌드 데이터 컨테이너에서 직접 가져옴) k8을 빌드하고 kubeadm-dind-cluster를 실행하는 데 동일한 원격 도커 엔진을 사용할 수 있다는 것입니다. 이는 작업 중인 경우 중요할 수 있습니다. 느린 연결을 통한 원격 도커 사용.

... 클러스터에 액세스하기 위해 마스터 컨테이너에서 docker exec 를 수행할 필요가 없도록 로컬 kubectl을 구성한다는 사실을 잊어버렸습니다.

이미 언급했듯이 DIND는 표면적으로는 쉬워 보이지만 예기치 않은 문제가 발생할 수 있습니다. 일부 문제는 kubeadm-dind-cluster 및 사용하는 기본 이미지 에서 이미 수정되었습니다. 예 : 당신이해야 할 몇 가지 마운트를 할 또한 필요, 사용 STOPSIGNAL SIGRTMIN+3 하고 유혹에 저항 사용하기 /sbin/init 로 ENTRYPOINT 하고 VFS 드라이버 시간에 매우 느릴 수 있습니다. 자... 여기 드래곤이 있습니다 ;)

@ivan4th kubeadm과 dind로 작업해 주셔서 감사합니다 :)
kubeadm-dind-cluster를 이 저장소에 병합하는 데 필요한 MVP에 대해 논의할 수 있는 이 문제를 참조하는 새 문제를 열 ​​수 있습니까?

빠르게 살펴본 결과 MVP가 되기 전에 하고 싶은 몇 가지 사항을 찾았습니다.

• 이상적으로는 Go로 작성해야 합니다. 일반적으로 우리는 Bash에서 벗어나려고 한다고 생각합니다. 그래서 Go는 새로운 프로젝트를 위한 Go의 방법이라고 생각합니다. :)
• 데비안 기반은 gcr.io/google-containers/debian-base-$(ARCH):0.1을 기반으로 해야 합니다.
  
  
  
  • dind의 기본 이미지는 이상적으로는 gcr.io에 게시되어야 합니다.
  
  
• kubeadm과 같은 여러 아치에서 작동해야 합니다.
• 고유한 바이너리를 제공할 수 있어야 하지만 대부분 매시간 모든 아치에 대한 바이너리를 게시하는 CI에서 다운로드해야 합니다.
• CNI를 사용해야 합니다. 네트워크 공급자를 교환할 수 있습니다.
• kubeadm과 같은 구성 파일을 통해 구성 옵션을 노출해야 합니다. 구성 파일을 옵션에 대한 입력으로 사용할 수 있습니다.
• kubeadm v1.6+만 지원해야 합니다.

어떻게 생각하나요? 멋진 시작에 감사드립니다. 실제로 이것을 kubeadm 공식에 통합하고 싶습니다. +1:

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

멋진 시작에 감사드립니다. 실제로 이것을 kubeadm 공식에 통합하고 싶습니다.

우리가 kubeadm-local-up-cluster를 개발하고 구축할 수 있다면 환상적일 것입니다.

@ivan4th @luxas 이 상태가 어떤가요?

잘 모르겠어... @ivan4th

@jamiehannaford

• 지금은 다른 프로젝트도 해야 해서 Go rewrite가 늦어졌습니다.
• kdc는 다양한 CNI impls(기본값인 Weave, Calico, Flannel 및 일반 CNI 브리지)를 지원합니다.
• 여러 아키텍처를 지원하는 것은 아직 여기에 없지만 충분히 가능합니다.
• 이미지에 사용된 바이너리는 기본적으로 k8s 릴리스에서 가져오지만 자신을 빌드하거나 약간의 노력으로 별도로 빌드된 바이너리를 기반으로 이미지를 만들 수 있습니다.
• 그것은 구성 파일을 지원하지만 지금은 실제로 env vars 세트입니다.
• 기본 이미지는 여전히 우분투이지만 데비안으로 전환하겠습니다.
• 우리는 1.6을 지원하고 나는 다음 주 초에 1.7에 대한 지원을 추가할 것입니다

전체 kdc 는 현재 형태의 IMO에서 상당히 유용합니다. 또한 Travis를 기반으로 하는 자체 공개 CI가 있습니다(BTW 또한 관심이 있는 경우 CircleCI에서 DIND를 실행하는 데 성공했습니다)

@luxas 전체 DIND 클러스터 대신 @andersla 의 솔루션을 사용할 수 있습니까? 그렇다면 Docker 이미지를 어디에서나 호스팅해야 합니까, 아니면 Dockerfile이 어떻게 보이는지 문서화해야 합니까?

1.9에서 이 문제를 해결할 수 있다면 좋을 것입니다.

이 작업을 수행할 주기가 없습니다. 다른 사람이 있다면 할 수 있습니다!

@jamiehannaford 문제는 "전체" DIND 클러스터의 대부분이 "단순한" DIND 사용에서 발생하는 수많은 문제를 처리하는 데 전념한다는 것입니다. 이것은 때때로 매우 모호할 수 있습니다. 예를 들어 https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438을 참조 kubeadm-dind-cluster 현재 , 그것은 여전히 ​​사용 가능하며 최신 상태로 유지하려고합니다 ( @danehans 및 @pmichali 는 k8s IPv6 e2e 테스트에 사용하고 Virtlet 은

우리는 어제 SIG 회의에서 이에 대해 이야기했으며 이 문제를 마무리하겠습니다.
완전한 DIND 솔루션을 개발하고 유지 관리하는 것은 가까운 미래에 핵심 kubeadm 팀의 범위에 포함되지 않습니다. Mirantis 프로젝트에 대한 @ivan4th 의 노력과 같이 커뮤니티에서 이러한 솔루션을 제공하게 되어 매우 기쁩니다. 해당 프로젝트를 사용할 가능성을 문서화할 수 있는 좋은 장소를 찾으면 개인적으로 참조하는 것이 좋습니다. 감사 해요!