_ Fromandersla في 27 أكتوبر 2016 18: 8 _
تقرير الشوائب
إصدار Kubernetes (استخدم kubectl version
):
الأحدث
البيئة :
Ubuntu 16.04 Docker container
ماذا حدث :
عند محاولة تثبيت Kubeadm داخل حاوية Docker Ubuntu 16.04 ، فإنه يفشل.
كانت فكرتي هي استخدام حاوية عامل إرساء واحدة كـ "عقدة" رئيسية وحاوية ثانية كـ "عقدة" عاملة (kubernetes في عامل الإرساء)
هل هذه مشكلة systemd؟ (شيء صادفته عند "البحث على Google" للحصول على إجابات)
داخل صورة عامل ميناء Ubuntu 16.04 أقوم بتثبيتها باستخدام: apt-get install -y kubeadm
سجل الإعداد:
...
...
...
all: Setting up socat (1.7.3.1-1) ...
all: Setting up kubelet (1.4.3-00) ...
all: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
all: Setting up kubectl (1.4.3-00) ...
all: Setting up kubeadm (1.5.0-alpha.0-1534-gcf7301f-00) ...
all: Failed to connect to bus: No such file or directory
**all: dpkg: error processing package kubeadm (--configure):**
all: subprocess installed post-installation script returned error exit status 1
all: Setting up netcat-traditional (1.10-41) ...
all: update-alternatives: using /bin/nc.traditional to provide /bin/nc (nc) in auto mode
all: Setting up netcat (1.10-41) ...
all: Setting up patch (2.7.5-1) ...
all: Setting up rename (0.20-4) ...
all: update-alternatives: using /usr/bin/file-rename to provide /usr/bin/rename (rename) in auto mode
all: Setting up tcpd (7.6.q-25) ...
all: Setting up ubuntu-fan (0.9.1) ...
all: invoke-rc.d: could not determine current runlevel
all: invoke-rc.d: policy-rc.d denied execution of start.
all: Setting up xz-utils (5.1.1alpha+20120614-2ubuntu2) ...
all: update-alternatives: using /usr/bin/xz to provide /usr/bin/lzma (lzma) in auto mode
all: Setting up python3 (3.5.1-3) ...
all: running python rtupdate hooks for python3.5...
all: running python post-rtupdate hooks for python3.5...
all: Setting up apparmor (2.10.95-0ubuntu2.2) ...
all: update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
all: Setting up dh-python (2.20151103ubuntu1.1) ...
all: Processing triggers for libc-bin (2.23-0ubuntu4) ...
all: Processing triggers for systemd (229-4ubuntu11) ...
all: Processing triggers for initramfs-tools (0.122ubuntu8.5) ...
all: Processing triggers for dbus (1.10.6-1ubuntu3) ...
all: Errors were encountered while processing:
all: kubeadm
all: E: Sub-process /usr/bin/dpkg returned an error code (1)
==> all: Killing the container: 93babb5045461c343a803109ba683a2acf68f1f453447a336b09171a1b190f38
Build 'all' errored: Script exited with non-zero exit status: 100
==> Some builds didn't complete successfully and had errors:
--> all: Script exited with non-zero exit status: 100
_منسوخ من الإصدار الأصلي: kubernetes / kubernetes # 35712_
_ Fromluxas في 27 أكتوبر 2016 18:14 _
ccerrordeveloper و marun لأنهما كانا يشغلان systemd داخل حاوية
andersla كن حذرًا من أن تشغيل systemd بهذه الطريقة داخل حاوية غير مدعوم ootb ، لكن لا تتردد في تجربته / اختراقه لأنه سيكون أمرًا رائعًا لاختبار kubeadm بهذه الطريقة
_ من @ zreigz في 28 أكتوبر 2016 7:36_
إذا كنت لا تمانع ، أود إلقاء نظرة فاحصة ومحاولة إصلاحها.
_ Fromandersla في 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
وهذا هو الخطأ الذي أواجهه عند تثبيت 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)
_ من @ zreigz في 28 أكتوبر 2016 9:10
لقد قمت بإعادة إنتاجه وكنت أعمل عليه
_ من @ zreigz في 31 أكتوبر 2016 7:24
هناك مشكلتان.
الأول: ll: /var/lib/dpkg/info/kubelet.postinst: 38: /var/lib/dpkg/info/kubelet.postinst: [[: not found
في أنظمة Ubuntu ، يمثل / bin / sh شرطة ، وليس bash ، ولا تدعم الشرطة الكلمة الأساسية ذات القوس المزدوج. الشيء الجيد هو أن المشكلة تم إصلاحها في الفرع الرئيسي وستتوفر قريبًا: https://github.com/kubernetes/release/blob/master/debian/xenial/kubelet/debian/postinst#L40
الثانية ليست تافهة جدا. فشل تشغيل systemctl في الحاوية مع Failed to get D-Bus connection
. يبدو أن systemd لا يعمل بشكل صحيح في الحاوية. الآن أنا أعمل على هذا
_ Fromandersla في 31 أكتوبر 2016 07:42
رائعة!
أنا فقط لا أرى لماذا يحتاج تثبيت kubeadm إلى systemd / systemctl على الإطلاق؟
_ من @ zreigz في 31 أكتوبر 2016 7:47 _
بسبب هذين السطرين: https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/debian/postinst#L25
systemctl daemon-reload
systemctl restart kubelet
فشل في السطر الأول
_ من @ 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.
_ من @ zreigz في 31 أكتوبر 2016 7:52 _
هناك بعض خطوات التكوين لجعلها تعمل ولكن لا بد لي من تجربتها أولاً. إذا وجدت شيئًا سأخبرك به.
_ Fromzreigz في 2 نوفمبر 2016 07:19
أخبار جيدة. لقد تمكنت من حل جميع القضايا. يحتاج إلى اختبارات أخيرة وسأقوم بنشر الحل حول كيفية تشغيل kubeadm في حاوية Docker
_ Fromandersla في 2 نوفمبر 2016 7:23_
ممتاز! سأساعد في الاختبار بمجرد أن يصبح جاهزًا! - على الرغم من أنني في إجازات بقية هذا الأسبوع :)
_ من @ zreigz في 2 نوفمبر 2016 10:13_
هناك مشكلتان رئيسيتان تتعلقان بتثبيت kubeadm في حاوية Docker. الأول هو تشغيل systemd في الحاوية. الثاني هو تركيب عامل إرساء داخل الحاوية. تم إصلاح المشاكل بنجاح. هذا هو Dockerfile الذي يجب استخدامه لإعداد صورة 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
أستخدم هذا الأمر لبناء الصورة في الدليل الذي يحتوي على 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
البحث عن معرف الحاوية قيد التشغيل
$ 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
كل شيء يعمل كما هو الحال على الجهاز المحلي.
حظا طيبا وفقك الله :)
_ FromSuperStevenZ في 17 نوفمبر 2016 7:21_
zreigz هذا حل نفس مشكلتي ، شكرًا!
_ من @ zreigz في 17 نوفمبر 2016 7:30_
لا مشكلة :)
يجب علينا إعداد CI مع عناصر عامل الإرساء.
errordeveloperzreigz يمكنك أن تأخذ هذا في؟
على الأقل يجب أن نوثق في مكان ما كيفية تشغيل kubeadm داخل حاوية ...
يبدو جيدا بالنسبة لي. بالتأكيد نحتاج إلى وضع كل هذه الأشياء في صورة عامل ميناء بالإضافة إلى بعض البرامج النصية للتكوين / البدء للتمييز بين العقدة الرئيسية والعقدة. ستكون البداية الجيدة هي إنشاء مشروع لها مثل kubernetes / kubeadm-docker. سيكون أيضًا المكان المناسب لـ Dockerfile والنصوص والتوثيق
قم بإنشاء ذلك كمشروع خاص أولاً تحت zreigz / وفي النهاية سنقوم على الأرجح بدمج هذا الرمز في هذا الريبو.
لكن أولاً ، ضع النموذج الأولي في مساحتك الخاصة وسنرى كيف ستسير الأمور.
المحال إليه الحقيقي هوzreigz
نعم نقطة جيدة. أنا سأفعلها. الأسبوع المقبل (الاثنين ، الثلاثاء) أنا في المؤتمر لذا سأبدأ يوم الأربعاء.
luxas كنت أتساءل كيف يمكنني تقديم حزم kubeadm و kubernetes-cni. إذا كان يجب أن أقوم ببنائه من المصادر الحالية (لأتمكن من اختبار أحدث تطبيق) أو مجرد تنزيل الإصدار الأحدث من المستودع؟ لغرض CI ، يجب أن يكون لدينا الحالة الحالية للشفرة حتى نتمكن من اختبارها ، أم أننا نحتاجها فقط لاختبار نسخة الإصدار؟
مرحبًا ، شكرًا على الإصلاح ولكن ما زلت تواجه مشكلة بعد kubeadm init أنا أحصل على 0/3 على DNS ، لا يبدو أن DNS يعمل على الإطلاق
كل 2.0 ثانية: kubectl get pods - all-namespaces الجمعة 16 ديسمبر 17:00:50 2016
NAMESPACE NAME READY STATUS STARTS AGE العمر
نظام الدمية kube-2088944543-17sey 1/1 الجري 0 11 م
kube-system etcd-8dd8c92c6c38 1/1 الجري 2 12 م
نظام kube-apiserver-8dd8c92c6c38 1/1 الجري 4 12 م
kube-system kube-controller-manager-8dd8c92c6c38 1/1 Running 2 11m
نظام kube-discovery-1150918428-m506w 1/1 الجري 0 11 م
نظام kube-system kube-dns-654381707-vuijm 0/3 حاوية إنشاء 0 11 م
نظام kube-proxy-tuw6u 0/1 CrashLoopBackOff 6 11m
نظام kube kube-Scheduler-8dd8c92c6c38 1/1 الجري 2 10 م
حاول تثبيت سياسة الشبكة
الجذر @ 8dd8c92c6c38 : / # kubectl application -f calico.yaml
المسار "calico.yaml" غير موجود
الجذر @ 8dd8c92c6c38 : / # kubectl create -f calico.yaml
المسار "calico.yaml" غير موجود
الجذر @ 8dd8c92c6c38 : / # kubectl application -f kube-flannel.yml
المسار "kube-flannel.yml" غير موجود
root @ 8dd8c92c6c38 : / # kubectl application -f https://git.io/weave-kube
تم إنشاء daemonset "weave-net"
root @ 8dd8c92c6c38 : / # kubectl get pods - all-namespaces
NAMESPACE NAME READY STATUS STARTS AGE العمر
دمية نظام kube-2088944543-17sey 1/1 الجري 0 46 م
نظام kube etcd-8dd8c92c6c38 1/1 الجري 2 46 م
نظام kube-apiserver-8dd8c92c6c38 1/1 الجري 4 46 م
kube-system kube-controller-manager-8dd8c92c6c38 1/1 الجري 2 45 م
نظام kube-discovery-1150918428-9m6rr 0/1 معلق 0 3 م
نظام kube-system kube-dns-654381707-vuijm 0/3 حاوية إنشاء 0 45 م
نظام kube-proxy-tuw6u 0/1 CrashLoopBackOff 13 45m
نظام kube kube-Scheduler-8dd8c92c6c38 1/1 الجري 2 44 م
kube-system weave-net-iv0bc 0/2 حاوية إنشاء 0 49 ثانية
معلومات: 1 كائن (كائنات) مكتمل (لم يكن) معروضًا في قائمة pods. مرر - اعرض الكل لترى كل الأشياء.
مرحبًا مرة أخرىzreigz
لقد أتيحت لي الآن أخيرًا وقتًا للمضي قدمًا في هذا واختباره - يمكنني تقريبًا فعل ذلك ، ولكن هناك خطأ في أن عامل التحميل يختار برنامج تشغيل تخزين vfs (ربما لأنه لا يمكنه استخدام aufs فوق aufs؟ ولكن كما تصف الحل البديل أعلاه أنا أقوم بتركيب قفص الاتهام الخارجي في وحدة الإرساء الداخلية لذا يجب أن يكون من الممكن الكتابة باستخدام aufs؟ إذا قمت بذلك
يظهر docker info
على الجهاز المضيف الخاص بي أنه يقوم بتشغيل برنامج تشغيل تخزين aufs. - بينما إذا قمت بعمل docker info
داخل حاوية عامل الإرساء باستخدام kubernetes ، فإنها تقول إنها تستخدم برنامج تشغيل تخزين 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 إلى "overlay" على المضيف. ثم اختار عامل الرصيف داخل عامل الميناء 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
لم يكن يعمل)
بعض التحديثات الأخرى:
يمكنني الآن إنشاء حاوية kubeadm-in-docker-عاملة باستخدام ملف 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
أبني باستخدام: 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
ثم أبدأ 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 fais ويدخل CrashLoopBackOff.
إذا قمت بدلاً من ذلك بتعيين --net=host
عند تشغيل docker أعلاه ، فإن kube-proxy وجميع البودات تعمل بشكل جيد - لكن هذا ليس خيارًا لأنني سأحتاج إلى تشغيل الحاويات على شبكة عامل الإرساء باستخدام عنوان IP الخاص بهم: س
لقد حاولت سابقًا تشغيل docker بنفس العملية كما هو الحال في المضيف: -v /var/run/docker.sock:/var/run/docker.sock
لكنني لم أقم بتشغيله مطلقًا لأنه عندما يبدأ عامل الإرساء داخل الحاوية مع systemd ، فإنه لا يلتقط الجورب (أو شيء من هذا القبيل) الذي - التي).
شكراandersla!
هل يمكنك لصق ما فشل kube-proxy به؟
شكرا luxas على اهتمامك!
للأسف لا توجد تفاصيل في 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 - لكن هذا لأنني لم أبدأ بعد في النسج.
هنا سجل من 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
؟
لذلك نحن في الواقع نرى السبب _لماذا_: ابتسم:
يا هذا رائع :)
الجذر @ 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-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'
الآن أحصل على CrashLoop على Weave بدلاً من ذلك عندما أقوم لاحقًا بعمل kubectl apply -f weave.yaml
، ما يلي هو إخراج السجل من جراب النسج:
/proc/sys/net/bridge/bridge-nf-call-iptables not found
حاولت أيضًا البدء بالمعامل kube-proxy --proxy-mode=userspace
لكن نفس النتيجة.
أعتقد أن هذا سيحل مشكلة النسج: https://github.com/weaveworks/weave/pull/2659
andersla نعم ، يبدو أن هذا
على سبيل المثال ، يمكنك استخدام الصور luxas/weave-(kube|npc):v1.9.0-alpha.5
التي تأتي من HEAD ~ ish.
اسمحوا لي أن أعرف ما إذا كان يعمل ، ويرجى التعليق هنا بالضبط على ما تفعله الآن (أوامر shell ، Dockerfile ، نصوص أخرى ، إلخ) حتى يتمكن الآخرون من الاستفادة منه.
لقد استخدمت أحدث صورة من weaveworks / weave-kube
لقد استخدمت أيضًا أحدث قالب yaml https://github.com/weaveworks/weave/blob/master/prog/weave-kube/weave-daemonset.yaml
لسوء الحظ ، لم يعمل kube-dns (إنه شديد في ContainerCreating. رسالة الخطأ من kubelet بعد بدء 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
إذا بدأت العقدة الرئيسية فقط ولم أنضم إلى عقدة أخرى ، فسيظهر kubedns جيدًا عندما قمت بتطبيق weave.
لقد اختبرت أيضًا weave.yaml باستخدام أحدث نسج kube على تثبيت Vagrant وليس في تجربة عامل الإرساء ثم نجح كل شيء.
هذا هو weave.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
مرحبًا يا رفاق ، واجهت هذا الموضوع وهو ينقط الصخور! أشياء عظيمة.
أريد حقًا استخدام هذا النهج لـ CI مقابل الريبو الخاص بنا (وهو أمر معقد إلى حد ما ، بصراحة). لدينا متطلبات Helm / Tiller لإطلاق عدد غير قليل من الرسوم البيانية لـ CI. هل واجه أي منكم هذا ، أو لديه اقتراحات لاستمرار ذلك؟ يبدو أن تيلر يتجول في كل مكان في هذا الموقف:
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's الأخرى. لقد استخدمنا Calico حتى الآن لأن L3 أكثر وضوحًا في استكشاف الأخطاء وإصلاحها في مواقف الاختراق ، ولكن إذا كان Weave أفضل (نظرًا لأنه L2) ... سأحاول كل ما يجعلنا نتجاوز مشكلة Tiller. أعتقد أن Tiller غير سعيد لأنه في نهاية المطاف يبدو أنه يرتبط بـ 127.0.0.1 ... وقد رأيت أن هذا يسبب مشاكل في الماضي باختبار أشياء أخرى. أي إدخال سيكون مذهلاً. مرة أخرى ، دعائم رائعة حقًا للأشخاص الذين يقومون باختراق الأشياء! اشكرك!!
أهلا! رائع أننا المزيد من الناس يريدون هذا أن يعمل. ليس لدي خبرة مع كاليكو. نقوم بتشغيل Weave على السحابة ، وهذا ما أردت أن أعمل عليه في هذا المشروع. لكنني عالق ولم يتح لي الوقت لمزيد من البحث عن سبب عدم ظهور kube-dns عند تطبيق Weave كما هو موضح أعلاه.
الآن أحدث نسج مستقر يعمل بشكل أفضل من ذي قبل ...
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
وبعد تطبيق النسج ، تتوقف رسالة الخطأ هذه:
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 ، فكل شيء يعمل ، إليك الإعداد الكامل:
ملف Docker:
FROM ubuntu:xenial-20161213
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update -qq
RUN apt-get install -y \
apt-transport-https \
apt-utils \
ca-certificates \
curl \
dialog \
python \
daemon \
vim \
jq
# remove unwanted systemd services
RUN for i in /lib/systemd/system/sysinit.target.wants/*; do [ "${i##*/}" = "systemd-tmpfiles-setup.service" ] || rm -f "$i"; done; \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
# install docker (after removing unwanted systemd)
RUN apt-get install -y \
docker.io
RUN echo "Add Kubernetes repo..."
RUN sh -c 'curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -'
RUN sh -c 'echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list'
RUN echo "Installing Kubernetes requirements..."
RUN apt-get update -y && apt-get install -y \
kubelet \
kubernetes-cni \
kubectl
RUN echo "Installing Kubeadm - this will fail at post-install but that doesn't matter"
RUN apt-get install -y \
kubeadm; exit 0
# Create volume for docker
VOLUME /var/lib/docker
قم ببنائه باستخدام:
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
ثم أبدأ 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 -
لم أواجه أي مشكلة في تثبيت Helm أو Traefic أو GlusterFS في Kubernetes في هذا الإعداد :)
تقوم kubeadm-dind-cluster أساسًا بما أوضحه التعليق الأخير ، مما يوفر أتمتة حتى لا تضطر إلى كتابة الأوامر يدويًا (على الرغم من أنه حتى الآن يستخدم المكون الإضافي جسر CNI مع بعض الاختراقات بدلاً من الفانيلا ، لكن هذا سأقوم بإصلاحه تمامًا هكذا).
كما أنه يجعل من السهل إنشاء كل من مكونات k8s و kubeadm من مصدر محلي واستخدام الثنائيات في المجموعة التي تبدأها. إلى جانب ذلك ، كانت هناك بعض المشكلات غير الظاهرة التي واجهتها أثناء العمل عليها ، مثل تناول وحدة المعالجة المركزية بنسبة 100٪ والتسبب في تعطل عامل الإرساء ما لم تحرص على تعطيله.
بعض التغييرات التي ستأتي قريبًا في مجموعة kubeadm-dind:
يوفر kubeadm-dind-cluster أيضًا أتمتة لاختبارات e2e. ميزة أخرى مثيرة للاهتمام هي أنه يمكنك استخدام نفس محرك عامل الإرساء البعيد لكل من بناء k8s وتشغيل مجموعة kubeadm-dind دون نسخ الثنائيات مرة أخرى (فهي تسحبها مباشرة من إنشاء حاوية البيانات) ، والتي قد تكون مهمة إذا كنت تعمل مع عامل إرساء بعيد عبر اتصال بطيء.
... نسيت أن تذكر أنه يقوم بتكوين kubectl المحلي لك ، لذلك لا تحتاج إلى القيام بـ docker exec
على الحاوية الرئيسية للوصول إلى المجموعة الخاصة بك.
كما ذكرت سابقًا ، بينما قد يبدو DIND سهلًا على السطح ، يمكن أن تواجه بعض المشكلات غير المتوقعة معه. تم بالفعل إصلاح بعض المشاكل في kubeadm-dind-cluster والصورة الأساسية التي تستخدمها. على سبيل المثال ، تحتاج إلى القيام ببعض عمليات التثبيت ، كما تحتاج إلى استخدام STOPSIGNAL SIGRTMIN+3
ومقاومة الإغراء لاستخدام /sbin/init
كـ ENTRYPOINT
، ويمكن أن يكون برنامج تشغيل vfs بطيئًا جدًا في بعض الأحيان. لذلك ... هنا تكون التنانين ؛)
@ ivan4th شكرًا على كل العمل الذي كنت تقوم به مع kubeadm and dind :)
هل يمكنك فتح مشكلة جديدة تشير إلى هذه المشكلة حيث يمكننا مناقشة MVP اللازم لدمج مجموعة kubeadm-dind في الريبو هذا؟
بعد البحث السريع ، وجدت بعض النقاط التي قد نرغب في القيام بها قبل أفضل لاعب محتمل:
ماذا تعتقد؟ شكرًا على البداية الرائعة ، لا أطيق الانتظار لدمج هذا فعليًا في شيء مسؤول kubeadm: +1:
سم مكعبjbedalukemarsdenerrordevelopermikedanesetimothyscsttts
شكرًا على البداية الرائعة ، لا أطيق الانتظار لدمج هذا فعليًا في شيء مسؤول kubeadm
إذا استطعنا تطوير kubeadm-local-up-الكتلة ، فسيكون ذلك رائعًا.
@luxas ivan4th ما هو وضع هذا؟
لا اعرف حقا ... @ ivan4th
تضمين التغريدة
يمكن استخدام kdc بشكل عام في شكله الحالي IMO. كما أن لديها CI العام الخاص بها استنادًا إلى ترافيس (راجع للشغل نجحت أيضًا في تشغيل DIND على CircleCI إذا كان الأمر يتعلق ببعض الاهتمام)
luxas ربما يمكننا استخدام حل andersla بدلاً من مجموعة DIND الكاملة؟ إذا كان الأمر كذلك ، فهل نحتاج إلى استضافة صورة Docker في أي مكان ، أو مجرد توثيق شكل Dockerfile؟
سيكون من الرائع أن نتمكن من الحصول على حل لهذه المشكلة لـ 1.9
ليس لدي دورات للعمل على هذا. إذا كان أي شخص آخر ، يمكن أن تفعل من فضلك!
مشكلة jamiehannaford هي أن الكثير من مجموعة DIND "الكاملة" مخصصة للتعامل مع العديد من المشكلات التي تنشأ عن استخدام DIND "البسيط". قد تكون هذه غامضة تمامًا في بعض الأحيان ، راجع على سبيل المثال https://github.com/Mirantis/kubeadm-dind-cluster/commit/405c8bead4fb443582328fd3c7b8f01452872438 (أعتقد أنني سأحتاج إلى إرسال إصلاح لـ k8s لهذا الغرض). اعتبارًا من kubeadm-dind-cluster ، لا يزال قابلاً للاستخدام تمامًا وأحاول تحديثه باستمرار ( pmichali في اختبار k8s IPv6 e2e ويستخدمه Virtlet لتشغيل اختبارات e2e على CircleCI) ، على الرغم من أنني أمضيت الكثير من الوقت في مشاريع أخرى ، لذا لم أتمكن من إعادة كتابتها في Go حتى الآن.
تحدثنا عن هذا الأمر في اجتماع SIG أمس ، وسنغلق المشكلة.
إن تطوير حل DIND الكامل والمحافظة عليه ليس في نطاق فريق kubeadm الأساسي في المستقبل المنظور ، إن وجد. نحن سعداء جدًا لأن المجتمع يوفر هذه الحلول ، على الرغم من ذلك ، مثل العمل الشاق @ ivan4th في مشروع Mirantis. إذا وجدنا مكانًا جيدًا لتوثيق إمكانية استخدام هذا المشروع ، فأنا شخصيًا لا مانع من الإشارة إليه. شكرا!
التعليق الأكثر فائدة
لذلك إذا كنت تستخدم Flannel ، فكل شيء يعمل ، إليك الإعداد الكامل:
ملف 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
ثم أبدأ 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 -
لم أواجه أي مشكلة في تثبيت Helm أو Traefic أو GlusterFS في Kubernetes في هذا الإعداد :)