Kubeadm: दस्तावेज़ कैसे करें और एक कंटेनर में कुबेदम चलाने के लिए स्क्रिप्ट प्रदान करें

अक्टूबर 27, वर्ष 2016 18 पर _From @luxas: 14_

cc @errordeveloper और @marun जब से वे एक कंटेनर के अंदर systemd चला रहे हैं

@andersla सावधान रहें कि एक कंटेनर के अंदर इस तरह से

_From @zreigz 28 अक्टूबर, 2016 7: 36_

यदि आप बुरा न मानें तो मैं चाहूंगा कि मैं इसे करीब से देखूं और इसे ठीक करने का प्रयास करूं।

_From @andersla 28 अक्टूबर, 2016 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

और यह वह त्रुटि है जो मुझे तब मिलती है जब कुबेदम स्थापित किया जा रहा है:

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)

_28 अक्टूबर 2016 9:10 पर @zreigz से

मैंने इसे दोबारा तैयार किया है और मैं इस पर काम कर रहा हूं

_From @zreigz 31 अक्टूबर को, 2016 7: 24_

दो समस्याएं हैं।

पहला वाला: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
उबंटू सिस्टम पर, /bin/sh डैश है, बैश नहीं है, और डैश डबल ब्रैकेट कीवर्ड का समर्थन नहीं करता है। अच्छी बात यह है कि समस्या मास्टर शाखा पर तय की गई है और जल्द ही उपलब्ध होनी चाहिए: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40

दूसरा इतना तुच्छ नहीं है। कंटेनर में चल रहा systemctl Failed to get D-Bus connection साथ विफल हो जाता है। ऐसा लगता है कि सिस्टमड कंटेनर में ठीक से काम नहीं करता है। अब मैं इस पर काम कर रहा हूं

_From @andersla 31 अक्टूबर को, 2016 7: 42_

महान!
मैं अभी यह नहीं देखता कि कुबेदम की स्थापना के लिए सिस्टमड/सिस्टमक्टल की आवश्यकता क्यों है?

_From @zreigz 31 अक्टूबर को, 2016 7: 47_

उन दो पंक्तियों के कारण: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25

systemctl daemon-reload
systemctl restart kubelet

यह पहली पंक्ति में विफल रहता है

_From @zreigz 31 अक्टूबर को, 2016 7: 48_

यह व्याख्या है:

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

_From @zreigz 31 अक्टूबर को, 2016 7: 52_

इसे काम करने के लिए कुछ कॉन्फ़िगरेशन चरण हैं लेकिन मुझे पहले इसे आज़माना होगा। अगर मुझे कुछ मिलता है तो मैं आपको बता दूंगा।

_From @zreigz 2 नवंबर को, 2016 7: 19_

अच्छी खबर। मैंने सभी मुद्दों को हल करने में कामयाबी हासिल की है। इसे अंतिम परीक्षणों की आवश्यकता है और मैं समाधान पोस्ट करूंगा कि डॉकर कंटेनर में कुबेदम कैसे चलाया जाए

_@ andersla से 2 नवंबर 2016 को 7:23_

उत्तम! जैसे ही यह तैयार होगा मैं परीक्षण में मदद करूंगा! - हालाँकि मैं इस सप्ताह के बाकी दिनों में छुट्टियों पर हूँ :)

_From @zreigz 2 नवंबर को, 2016 10: 13_

डॉकर कंटेनर में कुबेदम की स्थापना के संबंध में दो मुख्य मुद्दे हैं। पहले सिस्टमड कंटेनर में चल रहा है। दूसरा कंटेनर के अंदर इंस्टॉलेशन डॉकटर है। समस्याओं को सफलतापूर्वक ठीक किया गया। यहां डॉकरफाइल है जिसका उपयोग उबंटू छवि तैयार करने के लिए किया जाना चाहिए

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

मैं इस कमांड का उपयोग डॉकरफाइल वाली निर्देशिका में छवि बनाने के लिए करता हूं

docker build -t kubeadm_docker .

अब आप तैयार छवि चला सकते हैं और कुबेदम स्थापना समाप्त कर सकते हैं।
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

चल रहे कंटेनर आईडी का पता लगाएं

$ 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

सब कुछ स्थानीय मशीन की तरह ही काम करता है।
आपको कामयाबी मिले :)

_From @SuperStevenZ 17 नवंबर, 2016 7: 21_

@zreigz जिसने मेरी एक ही समस्या हल की, धन्यवाद!

_From @zreigz 17 नवंबर, 2016 7: 30_

कोई दिक्कत नहीं है :)

हमें डॉकर-इन-डॉकर सामान के साथ एक सीआई स्थापित करना चाहिए।

@errordeveloper @zreigz क्या आप इसे ले सकते हैं?
कम से कम हमें कहीं दस्तावेज तो देना चाहिए कि कंटेनर के अंदर कुबेदम कैसे चलाया जाता है...

मेरे लिए अच्छा लग रहा है। यह सुनिश्चित करने के लिए कि हमें मास्टर और नोड के बीच अंतर करने के लिए इन सभी चीजों को डॉकटर इमेज के साथ-साथ कुछ कॉन्फिग/स्टार्ट स्क्रिप्ट में रखना होगा। इसके लिए Kubernetes/kubeadm-docker जैसे प्रोजेक्ट बनाना अच्छी शुरुआत होगी। यह डॉकरफाइल, स्क्रिप्ट और प्रलेखन के लिए भी सही जगह होगी

इसे पहले zreigz/ के तहत एक निजी प्रोजेक्ट के रूप में बनाएं और अंततः हम उस कोड को इस रेपो में मर्ज कर देंगे।

लेकिन पहले, अपने स्वयं के स्थान में प्रोटोटाइप और हम देखेंगे कि यह कैसे जाता है।

असली असाइनी है @zreigz

हाँ अच्छा बिंदु। मैं यह करूंगा। अगले हफ्ते (सोमवार, मंगलवार) मैं सम्मेलन में हूं इसलिए मैं बुधवार से शुरू करूंगा।

@luxas मैं सोच रहा था कि मुझे कुबेदम और कुबेरनेट्स-सीएनआई पैकेज कैसे प्रदान करना चाहिए। अगर मुझे इसे मौजूदा स्रोतों से बनाना चाहिए (नवीनतम कार्यान्वयन का परीक्षण करने में सक्षम होने के लिए) या केवल भंडार से नवीनतम संस्करण डाउनलोड करें? सीआई उद्देश्य के लिए मुझे लगता है कि हमारे पास परीक्षण करने में सक्षम होने के लिए कोड की वर्तमान स्थिति होनी चाहिए, या बस हमें रिलीज संस्करण का परीक्षण करने की आवश्यकता है?

हाय फिक्स के लिए धन्यवाद, लेकिन फिर भी kubeadm init के बाद एक समस्या हो रही है, मुझे DNS पर 0/3 मिल रहा है, DNS बिल्कुल भी नहीं चल रहा है

प्रत्येक 2.0s: kubectl get pods --all-namespaces शुक्र 16 दिसंबर 17:00:50 2016

नेमस्पेस नाम तैयार स्थिति फिर से शुरू होती है आयु
क्यूब-सिस्टम डमी-2088944543-17sey 1/1 रनिंग 0 11m
क्यूब-सिस्टम etcd-8dd8c92c6c38 1/1 रनिंग 2 12m
क्यूब-सिस्टम क्यूब-एपिसर्वर-8dd8c92c6c38 1/1 रनिंग 4 12m
क्यूब-सिस्टम क्यूब-कंट्रोलर-मैनेजर-8dd8c92c6c38 1/1 रनिंग 2 11m
क्यूब-सिस्टम क्यूब-डिस्कवरी-1150918428-एम506डब्ल्यू 1/1 रनिंग 0 11मी
क्यूब-सिस्टम क्यूब-डीएनएस-654381707-व्युइज्म 0/3 कंटेनर 0 11 मीटर बनाना
क्यूब-सिस्टम क्यूब-प्रॉक्सी-tuw6u 0/1 क्रैशलूपबैकऑफ़ 6 11m
क्यूब-सिस्टम क्यूब-शेड्यूलर-8dd8c92c6c38 1/1 रनिंग 2 10मी

नेटवर्क नीति स्थापित करने की कोशिश की
root@8dd8c92c6c38 :/# kubectl apply -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 apply -f https://git.io/weave-kube
डेमोंसेट "वीव-नेट" बनाया गया
root@8dd8c92c6c38 :/# kubectl पॉड्स प्राप्त करें --ऑल-नेमस्पेस
नेमस्पेस नाम तैयार स्थिति फिर से शुरू होती है आयु
क्यूब-सिस्टम डमी-2088944543-17sey 1/1 रनिंग 0 46m
क्यूब-सिस्टम etcd-8dd8c92c6c38 1/1 रनिंग 2 46m
क्यूब-सिस्टम क्यूब-एपिसर्वर-8dd8c92c6c38 1/1 रनिंग 4 46m
क्यूब-सिस्टम क्यूब-कंट्रोलर-मैनेजर-8dd8c92c6c38 1/1 रनिंग 2 45m
क्यूब-सिस्टम क्यूब-डिस्कवरी-1150918428-9m6rr 0/1 लंबित 0 3m
क्यूब-सिस्टम क्यूब-डीएनएस-654381707-व्युइज्म 0/3 कंटेनर 0 45 मीटर बनाना
क्यूब-सिस्टम क्यूब-प्रॉक्सी-tuw6u 0/1 क्रैशलूपबैकऑफ़ 13 45m
क्यूब-सिस्टम क्यूब-शेड्यूलर-8dd8c92c6c38 1/1 रनिंग 2 44मी
क्यूब-सिस्टम वेव-नेट-iv0bc 0/2 कंटेनर बनाना 0 49s
जानकारी: 1 पूर्ण वस्तु (ओं) को पॉड्स सूची में नहीं दिखाया गया था। सभी वस्तुओं को देखने के लिए पास --शो-ऑल।

हाय फिर से @zreigz
अब मेरे पास इसके साथ आगे बढ़ने और इसका परीक्षण करने का समय है - मैं इसे लगभग बना सकता हूं, लेकिन एक त्रुटि है कि docker vfs स्टोरेज ड्राइवर को चुनता है (शायद इसलिए कि यह aufs के शीर्ष पर aufs का उपयोग नहीं कर सकता है? लेकिन जैसा कि आप वर्कअराउंड का वर्णन करते हैं ऊपर मैं बाहरी डॉकटर .sock को आंतरिक डॉकटर में माउंट कर रहा हूं ताकि औफ्स के साथ लिखना संभव हो?अगर मैं करता हूं
docker info मेरी होस्ट मशीन पर यह कहता है कि यह aufs स्टोरेज ड्राइवर चला रहा है। - जबकि अगर मैं कुबेरनेट्स के साथ डॉकर कंटेनर के अंदर 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>:/# 

थोड़ा और प्रयास करने के बाद कुछ और जानकारी।
मैंने होस्ट पर डॉकटर स्टोरेज ड्राइवर को "ओवरले" में बदल दिया। फिर डॉकटर के अंदर डॉकटर ने ड्राइवर के रूप में औफ्स को चुना और मैंने "प्री-फ्लाइट चेक" पास किया, लेकिन अब मैं अंदर फंस गया हूं
[apiclient] Created API client, waiting for the control plane to become ready

कुछ अन्य परीक्षणों पर मुझे एहसास हुआ कि जब इसे /sbin/init के माध्यम से एक सेवा के रूप में शुरू किया गया था, तो docker उसी स्टोरेज ड्राइवर को नहीं चुन रहा था
अगर मैं इस तरह से डॉकर छवि चलाता हूं तो यह उसी ड्राइवर को होस्ट के रूप में शुरू नहीं करता है (जैसा कि ऊपर बताया गया है):
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 काम नहीं कर रहा था)

कुछ और अपडेट:

अब मैं इस डॉकरफाइल के साथ एक काम कर रहे कुबेदम-इन-डॉकर-कंटेनर का निर्माण कर सकता हूं:

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

कुछ (10-15) सेकंड तक प्रतीक्षा करें जब तक कि systemd और docker ऊपर और चल न जाए

फिर मैं चल रहे कंटेनर के अंदर कुबेदम शुरू करता हूं:
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

वर्तमान में डॉकर नेटवर्क के साथ कुछ समस्या है क्योंकि क्यूब-प्रॉक्सी फ़ैस और क्रैशलूपबैकऑफ़ में प्रवेश करता है।

अगर मैं ऊपर डॉकटर चलाते समय --net=host सेट करता हूं, तो क्यूब-प्रॉक्सी और सभी पॉड ठीक आ रहे हैं - लेकिन यह एक विकल्प नहीं है क्योंकि मुझे अपने आईपी के साथ डॉकटर नेटवर्क पर चलने वाले कंटेनरों की आवश्यकता होगी: एस

मैंने पहले भी होस्ट पर उसी प्रक्रिया के साथ डॉकटर चलाने की कोशिश की थी: -v /var/run/docker.sock:/var/run/docker.sock लेकिन मुझे यह काम कभी नहीं मिला क्योंकि जब कंटेनर के अंदर डॉकटर को सिस्टमड के साथ शुरू किया जाता है तो यह जुर्राब नहीं उठाता (या ऐसा कुछ वह)।

धन्यवाद @andersla!
क्या आप पेस्ट कर सकते हैं किसके साथ क्यूब-प्रॉक्सी विफल रहता है?

आपकी रुचि के लिए धन्यवाद @luxas !

दुर्भाग्य से journalctl -xeu kubelet में कोई विवरण नहीं है

क्यूब-प्रॉक्सी के बारे में मुझे बस इतना ही पता चला (कई बार दोहराया गया) मैं पूर्ण लॉग भी संलग्न करता हूं।

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

पूरा लॉग क्यूब-डीएनएस के बारे में भी शिकायत करता है - लेकिन ऐसा इसलिए है क्योंकि मैंने अभी तक बुनाई शुरू नहीं की है।

लॉग.ज़िप

यहाँ 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)"

हाँ, मैं देख रहा हूँ _that_ यह क्रैशलूपिंग है, लेकिन क्या आप उदाहरण दे सकते हैं kubectl -n kube-system logs kube-proxy-w0ng5 ?
तो हम वास्तव में कारण देखते हैं _why_ :smile:

अरे यह शानदार है :)
root@3551807cba77 :/# kubectl -n kube-system logs kube-proxy-w0ng5

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

मैं इसे वर्कअराउंड के साथ ठीक कर सकता हूं: --conntrack-max-per-core=0 और फिर प्रॉक्सी को पुनरारंभ करना। एक 0-वैल 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 करता हूं, तो बुनाई पॉड से लॉग आउटपुट निम्नलिखित है:
/proc/sys/net/bridge/bridge-nf-call-iptables not found
मैंने क्यूब-प्रॉक्सी पैरामीटर --proxy-mode=userspace शुरू करने का भी प्रयास किया लेकिन एक ही परिणाम।

मुझे लगता है कि इससे बुनाई की समस्या हल हो जाएगी: https://github.com/weaveworks/weave/pull/2659

@andersla हाँ, ऐसा लगता है कि समस्या ठीक हो गई है। क्या आप HEAD से निर्माण करने का प्रयास कर सकते हैं?
उदाहरण के लिए, आप luxas/weave-(kube|npc):v1.9.0-alpha.5 छवियों का उपयोग कर सकते हैं जो HEAD~ish से हैं।
मुझे बताएं कि क्या यह काम करता है, और कृपया यहां टिप्पणी करें कि आप अभी क्या कर रहे हैं (शेल कमांड, डॉकरफाइल, अन्य स्क्रिप्ट, आदि) ताकि अन्य इसका लाभ उठा सकें।

मैंने बुनकर/बुनाई-कुबे से नवीनतम छवि का उपयोग किया

मैंने नवीनतम यम-टेम्पलेट https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml का भी उपयोग किया

दुर्भाग्य से क्यूब-डीएनएस ने काम नहीं किया (यह कंटेनर क्रिएटिंग में स्टच है। बुनाई शुरू करने के बाद क्यूबलेट से त्रुटि संदेश है:

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

अगर मैंने केवल मास्टर नोड शुरू किया है और दूसरे नोड में शामिल नहीं हुआ है, तो जब मैंने बुनाई लागू की तो कुबडन ठीक हो गए। yaml

मैंने एक वैग्रांट इंस्टालेशन पर नवीनतम वेव-क्यूब के साथ वीव.यामल का भी परीक्षण किया, न कि मेरे डॉकटर-प्रयोग में और फिर यह सब काम कर गया।

यह वह बुनाई है। yaml जिसका उपयोग मैंने 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

हे दोस्तों, मैं इस धागे में भाग गया और यह चट्टानों को तोड़ रहा है! महान सामान।

मैं वास्तव में हमारे रेपो के खिलाफ सीआई के लिए इस दृष्टिकोण का उपयोग करना चाहता हूं (जो काफी जटिल है, ईमानदारी से)। सीआई के लिए कुछ चार्ट लॉन्च करने के लिए हमारे पास हेल्म/टिलर की आवश्यकता है। क्या आप में से किसी ने इसमें भाग लिया है, या इसे आगे बढ़ाने के लिए आपके पास सुझाव हैं? इस स्थिति में टिलर अपने आप में बर्फ़बारी करने लगता है:

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# 

मैं अन्य एसडीएन के साथ कोशिश कर सकता हूं। हम अब तक केलिको का उपयोग कर रहे हैं क्योंकि L3 हैकी स्थितियों में समस्या निवारण के लिए थोड़ा अधिक सरल है, लेकिन अगर वीव बेहतर है (क्योंकि यह L2 है) ... मैं कोशिश करूंगा कि जो कुछ भी हमें टिलर मुद्दे से आगे ले जाए। मुझे लगता है कि टिलर नाखुश है क्योंकि दिन के अंत में ऐसा प्रतीत होता है कि यह 127.0.0.1 के साथ जुड़ता है ... और मैंने देखा है कि पिछले परीक्षण में अन्य चीजों में समस्याएं आती हैं। कोई इनपुट अद्भुत होगा। फिर से, चीजों को हैक करने वाले लोगों के लिए वास्तव में बहुत बढ़िया सहारा! धन्यवाद!!

नमस्ते! बढ़िया है कि हम और लोग हैं जो इसे काम करना चाहते हैं। मुझे कैलिको के साथ अनुभव नहीं है। क्लाउड पर हम वीव चला रहे हैं ताकि मैं इस प्रोजेक्ट पर काम करना चाहता हूं। लेकिन मैं फंस गया हूं और मेरे पास आगे खुदाई करने का समय नहीं है, जब मैं ऊपर वर्णित के रूप में बुनाई लागू करता हूं तो क्यूब-डीएनएस क्यों नहीं आता है।

अब नवीनतम स्थिर बुनाई पहले से बेहतर काम कर रही है....

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

..लेकिन दुर्भाग्य से क्यूब-डीएनएस के साथ अभी भी वही समस्या नहीं आ रही है, कंटेनर क्रिएटिंग में फंस गया है:

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

और बुनाई लागू करने के बाद, यह त्रुटि संदेश बंद हो जाता है:
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

अगर मैं इसके बजाय नेटवर्क प्लगइन के रूप में फलालैन का उपयोग करता हूं तो यह काम करता है।

docker exec -it master bash

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

इसलिए यदि आप फलालैन का उपयोग करते हैं, तो सब कुछ काम कर रहा है, यहाँ पूरा सेटअप है:

डॉकरफाइल:

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

कुछ (10-15) सेकंड तक प्रतीक्षा करें जब तक कि systemd और docker ऊपर और चल न जाए

फिर मैं चल रहे कंटेनर के अंदर कुबेदम शुरू करता हूं:
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

और कुछ सेकंड के बाद (सिस्टमड और डॉकर के उठने तक) मास्टर से जुड़ें:
docker exec -it node kubeadm join --skip-preflight-checks --token=acbec6.2852dff7cb569aa0 172.17.0.2

जब वे शामिल हो गए, - मास्टर दर्ज करें और क्यूब-प्रॉक्सी को क्रैश करने के लिए वर्कअराउंड लागू करें:
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 -

मुझे इस सेटिंग में कुबेरनेट्स में हेल्म, ट्रैफिक या ग्लस्टरएफएस स्थापित करने में कोई समस्या नहीं थी :)

kubeadm-dind-cluster मूल रूप से वही करता है जो अंतिम टिप्पणी को रेखांकित करता है, स्वचालन प्रदान करता है ताकि आपको मैन्युअल रूप से कमांड टाइप न करना पड़े (हालाँकि अभी यह फलालैन के बजाय कुछ हैक्स के साथ CNI ब्रिज प्लगइन का उपयोग करता है, लेकिन यह मैं काफी ठीक कर दूंगा जल्द ही)।
यह स्थानीय स्रोत से k8s घटकों और kubeadm दोनों को बनाना आसान बनाता है और आपके द्वारा शुरू किए गए क्लस्टर में बायनेरिज़ का उपयोग करता है। इसके अलावा, इस पर काम करते समय मुझे कुछ गैर-स्पष्ट समस्याओं का सामना करना पड़ा, उदाहरण के लिए, 100% सीपीयू खा रहा है और जब तक आप इसे अक्षम करने का ध्यान नहीं रखते हैं, तब तक डॉकर क्रैश हो जाता है।

कुबेदम-दिंड-क्लस्टर में जल्द ही आने वाले कुछ बदलाव:

• k8s मास्टर के लिए इसे ठीक करें, क्यूब-प्रॉक्सी वहां टूट गया
• पूर्वनिर्मित छवियों के लिए समर्थन (मैं ऐसी कई छवियां भी प्रकाशित करने जा रहा हूं) इसलिए क्लस्टर शुरू करने के लिए केवल एक स्क्रिप्ट पर्याप्त है। यह विभिन्न परियोजनाओं में CI के लिए उपयोगी हो सकता है जो k8s . का उपयोग करते हैं
• तेजी से क्लस्टर पुनरारंभ करने के लिए डॉकर डेटा डीआईआर की कैशिंग
• ब्रिज के अलावा सीएनआई कार्यान्वयन के लिए समर्थन

kubeadm-dind-cluster e2e परीक्षणों के लिए स्वचालन भी प्रदान करता है। इसकी एक और दिलचस्प विशेषता यह है कि आप k8s के निर्माण और kubeadm-dind-cluster दोनों को बायनेरिज़ को कॉपी किए बिना चलाने के लिए एक ही रिमोट डॉकर इंजन का उपयोग कर सकते हैं (यह उन्हें सीधे बिल्ड डेटा कंटेनर से खींचता है), जो कि महत्वपूर्ण हो सकता है यदि आप काम कर रहे हैं धीमे कनेक्शन पर रिमोट डॉकर के साथ।

... यह उल्लेख करना भूल गया कि यह आपके लिए स्थानीय कुबेक्टल को कॉन्फ़िगर करता है, इसलिए आपको अपने क्लस्टर तक पहुंचने के लिए अपने मास्टर कंटेनर पर docker exec करने की आवश्यकता नहीं है।

जैसा कि मैंने पहले ही उल्लेख किया है, जबकि DIND सतह पर आसान लग सकता है, आपको इसके साथ कुछ अप्रत्याशित समस्याएं हो सकती हैं। कुबेदम-डिंड-क्लस्टर और इसके द्वारा उपयोग की जाने वाली आधार छवि में कुछ समस्याएं पहले से ही तय हैं। उदाहरण के लिए आप की जरूरत है कुछ माउंट कर भी आप की जरूरत है, का उपयोग STOPSIGNAL SIGRTMIN+3 और प्रलोभन का विरोध उपयोग करने के लिए /sbin/init के रूप में ENTRYPOINT , और वीएफएस चालक समय काफी धीमी गति से हो सकता है। तो... यहाँ ड्रेगन हो;)

@ ivan4th कुबेदम और डिंड के साथ आप जो भी काम कर रहे हैं, उसके लिए धन्यवाद :)
क्या आप इस मुद्दे के संदर्भ में एक नया मुद्दा खोल सकते हैं जहां हम इस रेपो में कुबेदम-डिंड-क्लस्टर को मर्ज करने के लिए आवश्यक एमवीपी पर चर्चा कर सकते हैं?

जल्दी से देखने के बाद, मुझे कुछ बिंदु मिले जो हम संभावित एमवीपी से पहले करना चाहेंगे:

• इसे आदर्श रूप से गो में लिखा जाना चाहिए - मुझे आम तौर पर लगता है कि हम बैश से दूर जाने की कोशिश कर रहे हैं, इसलिए गो एक नई परियोजना के लिए जाने का तरीका है जो मुझे लगता है :)
• डेबियन बेस gcr.io/google-containers/debian-base-$(ARCH):0.1 पर आधारित होना चाहिए
  
  
  
  • डिंड के लिए मूल छवि आदर्श रूप से gcr.io . पर प्रकाशित की जानी चाहिए
  
  
• इसे कुबेदमो जैसे कई मेहराबों पर काम करना चाहिए
• आपको अपने स्वयं के बायनेरिज़ प्रदान करने में सक्षम होना चाहिए, लेकिन अक्सर इसे सीआई से डाउनलोड करना चाहिए जो हर घंटे सभी मेहराबों के लिए बायनेरिज़ प्रकाशित करता है।
• इसे CNI का उपयोग करना चाहिए -- नेटवर्क प्रदाताओं के साथ अदला-बदली करने योग्य
• इसे कॉन्फ़िगरेशन फ़ाइल के माध्यम से अपने कॉन्फ़िगरेशन विकल्पों को उजागर करना चाहिए जैसे कुबेदम विकल्पों के लिए इनपुट के रूप में कॉन्फ़िगरेशन फ़ाइल ले सकता है
• इसे केवल कुबेदम v1.6+ . का समर्थन करना चाहिए

तुम क्या सोचते हो? भयानक शुरुआत के लिए धन्यवाद, मैं वास्तव में इसे कुछ कुबेदम आधिकारिक में एकीकृत करने के लिए इंतजार नहीं कर सकता: +1:

सीसी @jbeda @lukemarsden @errordeveloper @mikedanese @timothysc @sttts

शानदार शुरुआत के लिए धन्यवाद, मैं वास्तव में इसे कुबेदम आधिकारिक में एकीकृत करने के लिए इंतजार नहीं कर सकता

अगर हम विकास-निर्माण कर सकते हैं, तो कुबेदम-लोकल-अप-क्लस्टर शानदार होगा।

@ivan4th @luxas इसकी क्या स्थिति है?

मैं सच में नहीं जानता... @ivan4th

@jamiehannaford

• अभी तक, मुझे गो रीराइट में देरी हो रही है क्योंकि मुझे अन्य प्रोजेक्ट्स पर भी काम करने की आवश्यकता है
• केडीसी के पास विभिन्न सीएनआई इम्प्लांट्स (वीव, कैलिको, फलालैन और सादा सीएनआई ब्रिज जो डिफ़ॉल्ट है) के लिए समर्थन है।
• कई आर्किटेक्चर का समर्थन अभी यहां नहीं है, लेकिन काफी संभव है
• छवियों में उपयोग किए जाने वाले बायनेरिज़ डिफ़ॉल्ट रूप से k8s रिलीज़ से लिए गए हैं, लेकिन आप अपना खुद का निर्माण कर सकते हैं या, कुछ छोटे प्रयासों के साथ, अपनी अलग से निर्मित बायनेरिज़ के आधार पर एक छवि बना सकते हैं
• यह कॉन्फ़िगरेशन फ़ाइल का समर्थन करता है लेकिन अभी तक यह वास्तव में env vars का एक सेट है
• आधार छवि अभी भी उबंटू है लेकिन हम डेबियन पर स्विच करने जा रहे हैं
• हम 1.6 का समर्थन करते हैं और मैं अगले सप्ताह की शुरुआत में 1.7 के लिए समर्थन जोड़ूंगा

कुल मिलाकर केडीसी अपने वर्तमान स्वरूप आईएमओ में काफी उपयोगी है। ट्रैविस पर आधारित इसका अपना सार्वजनिक सीआई भी है (बीटीडब्ल्यू मैं सर्किलसीआई पर डीआईएनडी चलाने में भी सफल रहा, अगर यह कुछ रुचि का है)

@luxas शायद हम पूर्ण DIND क्लस्टर के बजाय @andersla के समाधान का उपयोग कर सकते हैं? यदि हां, तो क्या हमें डॉकर छवि को कहीं भी होस्ट करने की आवश्यकता होगी, या केवल डॉकरफाइल कैसा दिखता है, इसका दस्तावेजीकरण करना होगा?

यह बहुत अच्छा होगा यदि हम 1.9 . के लिए इस समस्या का समाधान प्राप्त कर सकें

मेरे पास इस पर काम करने के लिए साइकिल नहीं है। अगर कोई और कृपया कर सकता है!

@jamiehannaford समस्या है, "पूर्ण" DIND क्लस्टर का अधिकांश भाग "सरल" DIND उपयोग से उत्पन्न होने वाली कई समस्याओं से निपटने के लिए समर्पित है। ये कभी-कभी काफी अस्पष्ट हो सकते हैं, उदाहरण के लिए देखें https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (मुझे लगता है कि मुझे इसके लिए k8s के लिए एक फिक्स सबमिट करने की आवश्यकता होगी)। kubeadm-dind-cluster के रूप में , यह अभी भी काफी उपयोगी है और मैं इसे अप-टू-डेट रखने की कोशिश करता हूं ( @danehans और @pmichali k8s IPv6 e2e परीक्षण के लिए इसका उपयोग कर रहे हैं और Virtlet इसका उपयोग सर्किलसीआई पर अपने e2e परीक्षण चलाने के लिए करता है), हालांकि मैं अन्य परियोजनाओं पर बहुत समय बिताता हूं इसलिए मैंने इसे अभी तक गो में फिर से लिखने का प्रबंधन नहीं किया।

हमने कल एसआईजी की बैठक में इस बारे में बात की थी और हम इस मुद्दे को बंद कर देंगे।
एक पूर्ण विकसित डीआईएनडी समाधान विकसित करना और बनाए रखना कोर कुबेदम टीम के लिए एक निकट भविष्य के लिए, यदि कभी हो तो गुंजाइश नहीं है। हम बहुत खुश हैं कि समुदाय इन समाधानों को प्रदान करता है, जैसे @ ivan4th की मिरांटिस परियोजना पर कड़ी मेहनत। अगर हमें उस परियोजना का उपयोग करने की संभावना का दस्तावेजीकरण करने के लिए एक अच्छी जगह मिलती है, तो मैं इसे संदर्भित करने के लिए व्यक्तिगत रूप से ठीक हूं। धन्यवाद!