نحن نعمل على تطوير بيئة للعمل مع microservices. الجزء 1 من تثبيت Kubernetes HA على المعدن العاري (دبيان)

مرحباً عزيزي القراء من هبر!

مع هذا المنشور ، أريد أن أبدأ سلسلة من المقالات حول نشر بيئة تزامن كاملة مع حاويات Kubernetes ، والتي ستكون جاهزة للتشغيل وإطلاق التطبيقات.
لا أريد أن أخبر فقط عن كيفية نشر كتلة Kubernetes ، ولكن أيضًا حول كيفية تكوين كتلة بعد التثبيت ، وكيفية إضافة أدوات ملائمة ووظائف إضافية إليها لاستخدام بنية microservice.

ستتألف هذه الدورة من أربع مقالات على الأقل:

1. في أولها ، سأخبرك عن كيفية تثبيت مجموعة kubernet آمنة من الفشل على الحديد العاري ، وكيفية تثبيت لوحة معلومات قياسية وتكوين الوصول إليها ، وكيفية تثبيت جهاز التحكم في الدخول.
2. في مقالة ثانية ، سأوضح لك كيفية نشر مجموعة تجاوز فشل Ceph وكيفية البدء في استخدام وحدات تخزين RBD في نظام Kubernetes الخاص بنا. سوف أتطرق أيضًا إلى أنواع التخزين الأخرى قليلاً (المستودعات) وسأنظر في التخزين المحلي بمزيد من التفاصيل. بالإضافة إلى ذلك ، سأخبرك بكيفية تنظيم تخزين S3 المتسامح مع الأخطاء استنادًا إلى مجموعة CEPH التي تم إنشاؤها
3. في المقالة الثالثة ، سأشرح كيفية نشر نظام مجموعة تجاوز الفشل MySql في مجموعة Kubernetes الخاصة بنا ، وهي Percona XtraDB Cluster على Kubernetes. وكذلك سوف أصف كل المشكلات التي واجهناها عندما قررنا نقل قاعدة البيانات إلى kubernetes.
4. في المقالة الرابعة ، سأحاول أن أجمع كل شيء وأخبرك بكيفية نشر وتشغيل تطبيق يستخدم قاعدة البيانات ومجلدات ceph. سوف أخبرك بكيفية تكوين جهاز التحكم في الوصول للوصول إلى تطبيقنا من الخارج وخدمة طلب الشهادة التلقائية من Let's Encrypt. آخر هو كيفية الحفاظ على هذه الشهادات تلقائيا حتى الآن. سنتطرق أيضًا إلى RBAC في سياق الوصول إلى لوحة التحكم. سأخبرك باختصار عن هيلم وتثبيته.
   إذا كنت مهتمًا بالمعلومات الواردة في هذه المنشورات ، فمرحباً بك!

دخول:

من هي هذه المقالات؟ بادئ ذي بدء ، لأولئك الذين بدأوا للتو رحلتهم في دراسة Kubernetes. أيضًا ، ستكون هذه الدورة مفيدة للمهندسين الذين يفكرون في الانتقال من متراصة إلى الخدمات الصغيرة. كل ما تم وصفه هو تجربتي ، بما في ذلك التجربة التي تم الحصول عليها عند ترجمة العديد من المشاريع من متراصة إلى Kubernetes. من الممكن أن تكون بعض أجزاء المنشورات ذات أهمية للمهندسين ذوي الخبرة.

ما لن أفكر فيه بالتفصيل في هذه السلسلة من المنشورات:

• اشرح بالتفصيل ماهية بدايات kubernetes ، مثل: جراب ، نشر ، خدمة ، إدخال ، إلخ.
• سوف أعتبر CNI (واجهة شبكة الحاوية) سطحية للغاية ، ونحن نستخدم callico وبالتالي حلول أخرى ، وسأدرج فقط.
• عامل بناء صورة عملية بناء.
• عمليات CI \ CD. (ربما منشور منفصل ، ولكن بعد الدورة بأكملها)
• رأس. لقد كتب الكثير عنه ، سوف أتطرق فقط إلى عملية تثبيته في المجموعة وإعداد العميل.

ما أريد أن أفكر فيه بالتفصيل:

• عملية نشر نظام Kubernet خطوة بخطوة. سأستخدم kubeadm. ولكن في الوقت نفسه ، سوف ألقي نظرة تفصيلية تفصيلية على عملية تثبيت كتلة على المعدن العاري ، وأنواع مختلفة من تثبيت ETCD ، وتكوين ملفات kube admina. سأحاول توضيح جميع خيارات الموازنة لوحدة التحكم في Ingress والفرق في أنظمة الوصول المختلفة لأنظمة العمل إلى api الخاص بالخادم.
  أعلم أن هناك اليوم العديد من الأدوات الرائعة لنشر kubernetes ، على سبيل المثال ، kubespray أو نفس رعاة البقر. ربما سيكون أكثر ملاءمة لشخص ما لاستخدامها. ولكن ، أعتقد ، أن هناك العديد من المهندسين الذين يرغبون في النظر في القضية بمزيد من التفصيل.
• مصطلحات CEPH وتثبيت مجموعة CEPH خطوة بخطوة ، بالإضافة إلى إرشادات خطوة بخطوة حول توصيل تخزين ceph بالمجموعة التي أنشأتها Kubernetes.
• المخازن المحلية ، والاتصال بمجموعة kubernetes ، وكذلك الاختلافات من الاتصالات مثل hostpath ، إلخ.
• مشغلي kubernetes ونشر Percona XtraDB Cluster بمساعدة المشغل ، وكذلك محاولة التحدث عن إيجابيات وسلبيات مثل هذا الحل بعد ستة أشهر من الخبرة في الإنتاج. وسأشارك أيضًا بعض الخطط لوضع اللمسات الأخيرة على المشغل من بيركونا.

جدول المحتويات:

1. قائمة المضيفين ، موارد المضيف ، إصدارات نظام التشغيل والبرامج
2. Kubernetes العنقودية مخطط HA
3. قبل أن تبدأ أو قبل أن تبدأ
4. املأ ملف create-config.sh
5. تحديث نواة نظام التشغيل
6. إعداد العقد تثبيت Kubelet و Kubectl و Kubeadm و Docker
7. تثبيت ETCD (خيارات مختلفة)
8. إطلاق أول معالج kubernetes
9. CNI كاليكو التثبيت
10. إطلاق معالجات kubernetes الثانية والثالثة
11. إضافة عقدة عامل إلى الكتلة
12. تثبيت haproxy على العقد العامل ل HA
13. تثبيت جهاز التحكم في الدخول
14. تثبيت Web UI (لوحة المعلومات)

قائمة ووجهة المضيفين

سيتم وضع جميع العقد الخاصة بمجموعتي على أجهزة افتراضية مع نظام امتداد دبيان 9 المثبت مسبقًا مع kernel 4.19.0-0.bpo.5-amd64. للمحاكاة الافتراضية ، أستخدم Proxmox VE.

الجدول VM وخصائص أدائها:

ليس من الضروري أن يكون لديك مثل هذا التكوين من الأجهزة ، لكن لا زلت أنصحك بالالتزام بتوصيات الوثائق الرسمية ، وبالنسبة للاساتذة ، يجب زيادة مقدار ذاكرة الوصول العشوائي إلى 4 غيغابايت على الأقل. واستشرافًا للمستقبل ، سأقول أنه بعدد أقل ، اكتشفت مواطن الخلل في عمل CNI Callico
Ceph هو أيضا شره جدا من حيث الذاكرة وأداء القرص.
تعمل منشآت الإنتاج لدينا دون محاكاة افتراضية للمعادن ، لكنني أعرف العديد من الأمثلة حيث كانت الأجهزة الافتراضية ذات الموارد المتواضعة كافية. كل هذا يتوقف على احتياجاتك وأعباء العمل.

قائمة وإصدارات البرامج

بدءًا من الإصدار 1.14 ، توقف Kubeadm عن دعم إصدار API v1alpha3 وانتقل بالكامل إلى إصدار API v1beta1 ، والذي سيدعمه في المستقبل القريب ، لذلك في هذه المقالة سأتحدث فقط عن v1beta1.
لذلك ، نعتقد أنك قد أعددت آلات مجموعة kubernetes. يمكن الوصول إليهم جميعًا عبر الشبكة ، ولديهم "اتصال إنترنت" بالإنترنت ويتم تثبيت نظام تشغيل "نظيف" عليهم.
بالنسبة لكل خطوة من خطوات التثبيت ، سأوضح الآلات التي يتم تنفيذ أمر أو مجموعة الأوامر عليها. تنفيذ جميع الأوامر كجذر ، ما لم ينص على خلاف ذلك.
تتوفر جميع ملفات التكوين ، بالإضافة إلى برنامج نصي لإعدادها ، للتنزيل في جيثب الخاص بي
لذلك دعونا نبدأ.

Kubernetes العنقودية مخطط HA

رسم تخطيطي تقريبي لمجموعة HA. إن فناني صادق تمامًا ، لكنني سأحاول شرح ذلك باختصار وبساطة شديدة ، دون الخوض في النظرية بشكل خاص.
لذلك ، سوف تتألف المجموعة الخاصة بنا من ثلاث نقاط رئيسية وثلاثة عقد عاملة. في كل عقدة رئيسية لـ kubernetes ، وما إلى ذلك (الأسهم الخضراء في الرسم التخطيطي) وستعمل أجزاء خدمة kubernetes لنا ؛ دعونا ندعو لهم بشكل عام - kubeapi.
من خلال الكتلة الرئيسية etcd ، تتبادل العقد حالة الكتلة kubernetes. سأشير إلى نفس عناوين نقاط إدخال وحدة التحكم في الدخول لحركة المرور الخارجية (الأسهم الحمراء في الرسم التخطيطي)
على العقد العاملة ، يعمل kubelet بالنسبة لنا ، والذي يتصل بخادم api kubernetes عبر haproxy المثبت محليًا على كل عقدة عامل. بما أن عنوان api الخاص بالملقم لـ kubelet ، فسوف أستخدم المضيف المحلي 127.0.0.1:6443 ، وسيقوم haproxy على roundrobin بتوزيع الطلبات على العقد الرئيسية الثلاثة ، كما سيتحقق من توفر العقد الرئيسية. سيسمح لنا هذا المخطط بإنشاء HA ، وفي حالة فشل إحدى العقد الرئيسية ، سترسل العقد المنفصلة طلبات بهدوء إلى العقدتين الرئيسيتين المتبقيتين.

قبل أن تبدأ

قبل البدء في العمل على كل عقدة من الكتلة ، سنزود الحزم التي سنحتاجها للعمل:

apt-get update && apt-get install -y curl apt-transport-https git 

على العقد الرئيسية ، انسخ مستودع التخزين باستخدام قوالب التكوين

 sudo -i git clone https://github.com/rjeka/kubernetes-ceph-percona.git 

تحقق من تطابق عنوان IP للمضيفين على المعالجات مع العنوان الذي سيستمع إليه خادم kubernetes

 hostname && hostname -i master01 10.73.71.25 

وهكذا لجميع العقد الرئيسية.

تأكد من تعطيل SWAP ، وإلا فإن kubeadm سيلقي خطأ

 [ERROR Swap]: running with swap on is not supported. Please disable swap 

يمكنك تعطيل الأمر

 swapoff -a 

تذكر أن تعلق في / etc / fstab

املأ ملف create-config.sh

لملء التكوينات اللازمة لتثبيت نظام kubernetes تلقائيًا ، قمت بتحميل برنامج نصي صغير create-config.sh. تحتاج إلى ملء فيه حرفيا 8 خطوط. أشر إلى عناوين IP واسم مضيف أسيادك. وكذلك تحديد الرمز المميز ، لا يمكنك تغييره. سأقدم أدناه هذا الجزء من البرنامج النصي الذي تحتاج إلى إجراء تغييرات عليه.

 #!/bin/bash ####################################### # all masters settings below must be same ####################################### # master01 ip address export K8SHA_IP1=10.73.71.25 # master02 ip address export K8SHA_IP2=10.73.71.26 # master03 ip address export K8SHA_IP3=10.73.71.27 # master01 hostname export K8SHA_HOSTNAME1=master01 # master02 hostname export K8SHA_HOSTNAME2=master02 # master03 hostname export K8SHA_HOSTNAME3=master03 #etcd tocken: export ETCD_TOKEN=9489bf67bdfe1b3ae077d6fd9e7efefd #etcd version export ETCD_VERSION="v3.3.10" 

تحديث نواة نظام التشغيل

هذه الخطوة اختيارية ، نظرًا لأن النواة سوف تحتاج إلى تحديث من المنافذ الخلفية ، ويمكنك القيام بذلك على مسؤوليتك الخاصة ومخاطرك. ربما لن تواجه هذه المشكلة أبدًا ، وإذا حدث ذلك ، يمكنك تحديث النواة حتى بعد نشر الكوبرنيت. بشكل عام ، عليك أن تقرر.
مطلوب تحديث kernel لإصلاح خلل عامل الرصيف القديم ، والذي تم إصلاحه فقط في إصدار linux kernel 4.18. يمكنك قراءة المزيد حول هذا الخطأ هنا . تم التعبير عن خطأ في الأعطال الدورية لواجهة الشبكة على عقد kubernetes بسبب الخطأ:

 waiting for eth0 to become free. Usage count = 1 

بعد تثبيت نظام التشغيل ، حصلت على إصدار kernel 4.9

 uname -a Linux master01 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13) x86_64 GNU/Linux 

على كل آلة ل kubernetes ننفذ
الخطوة رقم 1
إضافة منافذ العودة إلى قائمة المصدر

 echo deb http://ftp.debian.org/debian stretch-backports main > /etc/apt/sources.list apt-get update apt-cache policy linux-compiler-gcc-6-x86 

الخطوة رقم 2
حزمة التثبيت

 apt install -y -t stretch-backports linux-image-amd64 linux-headers-amd64 

الخطوة رقم 3
تمهيد

 reboot 

تأكد من أن كل شيء على ما يرام

 uname -a Linux master01 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 (2019-06-19) x86_64 GNU/Linux 

إعداد العقد تثبيت Kubelet و Kubectl و Kubeadm و Docker

تثبيت Kubelet ، Kubectl ، Kubeadm

نضع على جميع العقد من الكتلة ، وفقا لوثائق kubernetes

 apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 

تثبيت عامل الميناء

تثبيت عامل ميناء وفقا للتعليمات الواردة في الوثائق

 apt-get remove docker docker-engine docker.io containerd runc apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common 

 curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - apt-key fingerprint 0EBFCD88 

 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable" 

 apt-get update apt-get install docker-ce docker-ce-cli containerd.io 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini kubelet.yaml -K ansible-playbook -i hosts.ini docker.yaml -K # sudo  ansible-playbook -i hosts.ini kubelet.yaml ansible-playbook -i hosts.ini docker.yaml 

إذا كنت لا ترغب في استخدام عامل ميناء لسبب ما ، يمكنك استخدام أي CRI. يمكنك أن تقرأ عنها ، على سبيل المثال هنا ، ولكن هذا الموضوع خارج عن نطاق هذه المقالة.

ETCD التثبيت

لن أتعمق في النظرية ، باختصار: etcd هو تخزين قيمة موزعة مفتوح المصدر. etcd مكتوب في GO ويستخدم في kubernetes في الواقع ، كقاعدة بيانات لتخزين حالة الكتلة. للحصول على مراجعة أكثر تفصيلاً ، راجع وثائق kubernetes .
يمكن تثبيت etcd بعدة طرق. يمكنك تثبيته محليًا وتشغيله على أنه برنامج خفي ، ويمكنك تشغيله في حاويات الإرساء ، ويمكنك تثبيته حتى كقرنة kubernetes. يمكنك تثبيته باليد ، أو يمكنك تثبيته باستخدام kubeadm (لم أجرب هذه الطريقة). يمكن تثبيتها على أجهزة الكتلة أو الخوادم الفردية.
سوف أقوم بتثبيت الخ على المستوى المحلي على العقد الرئيسية وأعمل بمثابة برنامج خفي من خلال systemd ، بالإضافة إلى النظر في التثبيت في عامل ميناء. يمكنني استخدام etcd بدون TLS ، إذا كنت بحاجة إلى TLS ، فراجع وثائق etcd أو kubernetes نفسها
أيضا في بلدي github سيكون anbook - playbook لتثبيت etcd مع إطلاق من خلال systemd.

الخيار رقم 1
تثبيت محليا ، من خلال تشغيل systemd

على جميع الأساتذة: (على عقد عمل الكتلة ، هذه الخطوة ليست ضرورية)
الخطوة رقم 1
قم بتنزيل وفك الأرشيف مع etcd:

 mkdir archives cd archives export etcdVersion=v3.3.10 wget https://github.com/coreos/etcd/releases/download/$etcdVersion/etcd-$etcdVersion-linux-amd64.tar.gz tar -xvf etcd-$etcdVersion-linux-amd64.tar.gz -C /usr/local/bin/ --strip-components=1 

الخطوة رقم 2
إنشاء ملف التكوين ل ETCD

 cd .. ./create-config.sh etcd 

يقبل البرنامج النصي القيمة etcd كمدخلات ، ويقوم بإنشاء ملف تهيئة في دليل etcd. بعد تشغيل البرنامج النصي ، سيتم وضع ملف التكوين النهائي في دليل etcd.
بالنسبة لجميع التكوينات الأخرى ، يعمل البرنامج النصي على نفس المبدأ. يستغرق بعض المدخلات ويخلق التكوين في دليل معين.

الخطوة رقم 3
نبدأ المجموعة etcd والتحقق من أدائها

 systemctl start etcd 

التحقق من أداء الخفي

 systemctl status etcd ● etcd.service - etcd Loaded: loaded (/etc/systemd/system/etcd.service; disabled; vendor preset: enabled) Active: active (running) since Sun 2019-07-07 02:34:28 MSK; 4min 46s ago Docs: https://github.com/coreos/etcd Main PID: 7471 (etcd) Tasks: 14 (limit: 4915) CGroup: /system.slice/etcd.service └─7471 /usr/local/bin/etcd --name master01 --data-dir /var/lib/etcd --listen-client-urls http://0.0.0.0:2379,http://0.0.0.0:4001 --advertise-client-urls http://10.73.71.25:2379,http://10.73.71. Jul 07 02:34:28 master01 etcd[7471]: b11e73358a31b109 [logterm: 1, index: 3, vote: 0] cast MsgVote for f67dd9aaa8a44ab9 [logterm: 2, index: 5] at term 554 Jul 07 02:34:28 master01 etcd[7471]: raft.node: b11e73358a31b109 elected leader f67dd9aaa8a44ab9 at term 554 Jul 07 02:34:28 master01 etcd[7471]: published {Name:master01 ClientURLs:[http://10.73.71.25:2379 http://10.73.71.25:4001]} to cluster d0979b2e7159c1e6 Jul 07 02:34:28 master01 etcd[7471]: ready to serve client requests Jul 07 02:34:28 master01 etcd[7471]: serving insecure client requests on [::]:4001, this is strongly discouraged! Jul 07 02:34:28 master01 systemd[1]: Started etcd. Jul 07 02:34:28 master01 etcd[7471]: ready to serve client requests Jul 07 02:34:28 master01 etcd[7471]: serving insecure client requests on [::]:2379, this is strongly discouraged! Jul 07 02:34:28 master01 etcd[7471]: set the initial cluster version to 3.3 Jul 07 02:34:28 master01 etcd[7471]: enabled capabilities for version 3.3 lines 1-19 

وصحة الكتلة نفسها:

 etcdctl cluster-health member 61db137992290fc is healthy: got healthy result from http://10.73.71.27:2379 member b11e73358a31b109 is healthy: got healthy result from http://10.73.71.25:2379 member f67dd9aaa8a44ab9 is healthy: got healthy result from http://10.73.71.26:2379 cluster is healthy etcdctl member list 61db137992290fc: name=master03 peerURLs=http://10.73.71.27:2380 clientURLs=http://10.73.71.27:2379,http://10.73.71.27:4001 isLeader=false b11e73358a31b109: name=master01 peerURLs=http://10.73.71.25:2380 clientURLs=http://10.73.71.25:2379,http://10.73.71.25:4001 isLeader=false f67dd9aaa8a44ab9: name=master02 peerURLs=http://10.73.71.26:2380 clientURLs=http://10.73.71.26:2379,http://10.73.71.26:4001 isLeader=true 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini -l masters etcd.yaml -K BECOME password: <sudo > # sudo  ansible-playbook -i hosts.ini -l masters etcd.yaml 

إذا كنت تريد تشغيل etcd في عامل ميناء ، فهناك تعليمات تحت المفسد.

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona 

 apt-get install -y docker-compose 

 ./create-config.sh docker 

 docker-compose --file etcd-docker/docker-compose.yaml up -d 

 docker ps 

 root@master01:~/kubernetes-ceph-percona# docker exec -ti etcd etcdctl cluster-health member 61db137992290fc is healthy: got healthy result from http://10.73.71.27:2379 member b11e73358a31b109 is healthy: got healthy result from http://10.73.71.25:2379 member f67dd9aaa8a44ab9 is healthy: got healthy result from http://10.73.71.26:2379 cluster is healthy root@master01:~/kubernetes-ceph-percona# docker exec -ti etcd etcdctl member list 61db137992290fc: name=etcd3 peerURLs=http://10.73.71.27:2380 clientURLs=http://10.73.71.27:2379,http://10.73.71.27:4001 isLeader=false b11e73358a31b109: name=etcd1 peerURLs=http://10.73.71.25:2380 clientURLs=http://10.73.71.25:2379,http://10.73.71.25:4001 isLeader=true f67dd9aaa8a44ab9: name=etcd2 peerURLs=http://10.73.71.26:2380 clientURLs=http://10.73.71.26:2379,http://10.73.71.26:4001 isLeader=false 

 docker logs etcd 

إطلاق أول معالج kubernetes

بادئ ذي بدء ، نحن بحاجة إلى إنشاء التكوين ل kubeadmin

 ./create-config.sh kubeadm 

 apiVersion: kubeadm.k8s.io/v1beta1 kind: InitConfiguration localAPIEndpoint: advertiseAddress: 10.73.71.25 #    API- --- apiVersion: kubeadm.k8s.io/v1beta1 kind: ClusterConfiguration kubernetesVersion: stable #      apiServer: #    kubeadm   certSANs: - 127.0.0.1 - 10.73.71.25 - 10.73.71.26 - 10.73.71.27 controlPlaneEndpoint: 10.73.71.25 #     etcd: #  etc external: endpoints: - http://10.73.71.25:2379 - http://10.73.71.26:2379 - http://10.73.71.27:2379 networking: podSubnet: 192.168.0.0/16 #   ,   CNI  . 

نبدأ السيد الأول

 kubeadm init --config=kubeadmin/kubeadm-init.yaml 

إذا كان kubeadm يعمل دون أخطاء ، فعندئذٍ في الناتج نحصل على الناتج التالي تقريبًا:

 You can now join any number of control-plane nodes by copying certificate authorities and service account keys on each node and then running the following as root: kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 \ --control-plane Then you can join any number of worker nodes by running the following on each as root: kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 

CNI كاليكو التثبيت

لقد حان الوقت لإنشاء شبكة تعمل فيها السنفات الخاصة بنا. يمكنني استخدام كاليكو ، وسوف نضعها.
بالنسبة للمبتدئين ، قم بتكوين الوصول لـ kubelet. نحن ننفذ جميع الأوامر على master01
إذا كنت تقوم بتشغيل الجذر

 export KUBECONFIG=/etc/kubernetes/admin.conf 

إذا من تحت المستخدم البسيط

 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config 

يمكنك أيضًا إدارة الكتلة من الكمبيوتر المحمول أو أي جهاز محلي. للقيام بذلك ، انسخ ملف /etc/kubernetes/admin.conf إلى الكمبيوتر المحمول أو أي جهاز آخر في $ HOME / .kube / config

نضع CNI وفقا لوثائق Kubernetes

 kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml 

ننتظر حتى ترتفع جميع القرون

 watch -n1 kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-59f54d6bbc-psr2z 1/1 Running 0 96s kube-system calico-node-hm49z 1/1 Running 0 96s kube-system coredns-5c98db65d4-svcx9 1/1 Running 0 77m kube-system coredns-5c98db65d4-zdlb8 1/1 Running 0 77m kube-system kube-apiserver-master01 1/1 Running 0 76m kube-system kube-controller-manager-master01 1/1 Running 0 77m kube-system kube-proxy-nkdqn 1/1 Running 0 77m kube-system kube-scheduler-master01 1/1 Running 0 77m 

إطلاق معالجات kubernetes الثانية والثالثة

قبل بدء master02 و master03 ، تحتاج إلى نسخ الشهادات باستخدام master01 التي تم إنشاؤها kubeadm عند إنشاء الكتلة. سأنسخ عبر scp
على master01

 export master02=10.73.71.26 export master03=10.73.71.27 scp -r /etc/kubernetes/pki $master02:/etc/kubernetes/ scp -r /etc/kubernetes/pki $master03:/etc/kubernetes/ 

على master02 و master03
إنشاء التكوين ل kubeadm

 ./create-config.sh kubeadm 

وإضافة master02 و master03 إلى الكتلة

 kubeadm init --config=kubeadmin/kubeadm-init.yaml 

 root@master01:~/kubernetes-ceph-percona# kubectl get pods -A -w NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-658558ddf8-t6gfs 0/1 ContainerCreating 0 11s kube-system calico-node-7td8g 1/1 Running 0 11s kube-system calico-node-dthg5 0/1 CrashLoopBackOff 1 11s kube-system calico-node-tvhkq 0/1 CrashLoopBackOff 1 11s 

 kubectl edit -n kube-system ds calico-node 

 - name: IP_AUTODETECTION_METHOD value: ens19 

 # kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 28m v1.15.1 master02 Ready master 26m v1.15.1 master03 Ready master 18m v1.15.1 

 # kubectl get pods -A -o wide | grep calico kube-system calico-kube-controllers-59f54d6bbc-5lxgn 1/1 Running 0 27m kube-system calico-node-fngpz 1/1 Running 1 24m kube-system calico-node-gk7rh 1/1 Running 0 8m55s kube-system calico-node-w4xtt 1/1 Running 0 25m 

إضافة العقد عامل إلى الكتلة

في الوقت الحالي ، لدينا مجموعة تعمل فيها ثلاث نقاط رئيسية. لكن العقد الرئيسية هي آلات تقوم بتشغيل api ، وجدولة ، وخدمات أخرى من نظام kubernetes. حتى نتمكن من تشغيل القرون لدينا ، نحتاج إلى عقد العمال المزعومة.
إذا كنت محدودة الموارد ، فيمكنك تشغيل القرون على العقد الرئيسية ، لكنني شخصياً لا أنصح بذلك.

 kubectl taint nodes --all node-role.kubernetes.io/master- 

تثبيت العقد kubelet ، kubeadm ، kubectl ورسو السفن على العامل كما هو الحال في العقد الرئيسية

 apt-get update && apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat <<EOF >/etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF apt-get update apt-get install -y kubelet kubeadm kubectl apt-mark hold kubelet kubeadm kubectl 

 apt-get remove docker docker-engine docker.io containerd runc apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common 

 curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - apt-key fingerprint 0EBFCD88 

 add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/debian \ $(lsb_release -cs) \ stable" 

 apt-get update apt-get install docker-ce docker-ce-cli containerd.io 

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/playbooks vim masters.ini 

 # sudo c  ansible-playbook -i hosts.ini kubelet.yaml -K ansible-playbook -i hosts.ini docker.yaml -K # sudo  ansible-playbook -i hosts.ini kubelet.yaml ansible-playbook -i hosts.ini docker.yaml 

حان الوقت الآن للعودة إلى السطر الذي أنشأه kubeadm عندما قمنا بتثبيت العقدة الرئيسية.
انها تبدو مثل هذا بالنسبة لي.

 kubeadm join 10.73.71.25:6443 --token ivwoap.259retezqf34amx8 \ --discovery-token-ca-cert-hash sha256:b5c93e32457c8e6478782ff62e8ef77acf72738dda59cd603cdf4821abe12ca3 

من الضروري تنفيذ هذا الأمر على كل عقدة عامل.
إذا لم تكن قد كتبت رمزًا مميزًا ، فيمكنك إنشاء رمز جديد

 kubeadm token create --print-join-command --ttl=0 

بعد عمل kubeadm ، يتم إدخال العقدة الجديدة في الكتلة وتكون جاهزة للعمل

 This node has joined the cluster: * Certificate signing request was sent to apiserver and a response was received. * The Kubelet was informed of the new secure connection details. Run 'kubectl get nodes' on the control-plane to see this node join the cluster. 

الآن دعونا نلقي نظرة على النتيجة

 root@master01:~# kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 10d v1.15.1 master02 Ready master 10d v1.15.1 master03 Ready master 10d v1.15.1 worknode01 Ready <none> 5m44s v1.15.1 worknode02 Ready <none> 59s v1.15.1 worknode03 Ready <none> 51s v1.15.1 

تثبيت haproxy على worknodes

الآن لدينا مجموعة عمل مع ثلاثة عقد رئيسية وثلاثة عقد عامل.
المشكلة هي أنه الآن ليس لدينا عقد العامل وضع HA.
إذا نظرت إلى ملف تكوين kubelet ، فسنرى أن عقدنا العاملة لا تصل إلا إلى واحدة من العقد الرئيسية الثلاثة.

 root@worknode01:~# cat /etc/kubernetes/kubelet.conf | grep server: server: https://10.73.71.27:6443 

في حالتي ، هذا هو master03. مع هذا التكوين ، في حالة تعطل master03 ، ستفقد عقدة العامل الاتصال مع خادم API الكتلة. لجعل مجموعتنا HA بالكامل ، سنقوم بتثبيت Load Balancer (Haproxy) على كل من العمال ، والتي ، وفقًا لجولة روبن ، ستتبعثر طلبات العقد الثلاث الرئيسية ، وفي تكوين kubelet على عقد العامل ، سنقوم بتغيير عنوان الخادم إلى 127.0.0.1:6443
أولاً ، قم بتثبيت HAProxy على كل عقدة عامل.
هناك ورقة الغش جيدة للتثبيت

 curl https://haproxy.debian.net/bernat.debian.org.gpg | \ apt-key add - echo deb http://haproxy.debian.net stretch-backports-2.0 main | \ tee /etc/apt/sources.list.d/haproxy.list apt-get update apt-get install haproxy=2.0.\* 

بعد تثبيت HAproxy ، نحتاج إلى إنشاء تهيئة له.
إذا لم يكن هناك دليل على العقد المنفّذة يحتوي على ملفات التكوين ، فسنقوم باستنساخها

 git clone https://github.com/rjeka/kubernetes-ceph-percona.git cd kubernetes-ceph-percona/ 

وتشغيل البرنامج النصي التكوين مع العلم haproxy

 ./create-config.sh haproxy 

سيقوم البرنامج النصي بتكوين وإعادة تشغيل haproxy.
تحقق من أن haproxy بدأ الاستماع إلى المنفذ 6443.

 root@worknode01:~/kubernetes-ceph-percona# netstat -alpn | grep 6443 tcp 0 0 127.0.0.1:6443 0.0.0.0:* LISTEN 30675/haproxy tcp 0 0 10.73.75.241:6443 0.0.0.0:* LISTEN 30675/haproxy 

نحن الآن بحاجة إلى إخبار kubelet للوصول إلى مضيف محلي بدلاً من العقدة الرئيسية. للقيام بذلك ، قم بتحرير قيمة الخادم في ملفات /etc/kubernetes/kubelet.conf و /etc/kubernetes/bootstrap-kubelet.conf على جميع العقد المنفذة.

 vim /etc/kubernetes/kubelet.conf vim nano /etc/kubernetes/bootstrap-kubelet.conf 

يجب أن تأخذ قيمة الخادم في هذا النموذج:

 server: https://127.0.0.1:6443 

بعد إجراء التغييرات ، قم بإعادة تشغيل خدمات kubelet ورسو السفن

 systemctl restart kubelet && systemctl restart docker 

تحقق من أن جميع العقد تعمل بشكل صحيح.

 kubectl get nodes NAME STATUS ROLES AGE VERSION master01 Ready master 29m v1.15.1 master02 Ready master 27m v1.15.1 master03 Ready master 26m v1.15.1 worknode01 Ready <none> 25m v1.15.1 worknode02 Ready <none> 3m15s v1.15.1 worknode03 Ready <none> 3m16s v1.15.1 

حتى الآن ، ليس لدينا تطبيقات في المجموعة لاختبار HA. ولكن يمكننا إيقاف تشغيل kubelet على العقدة الرئيسية الأولى والتأكد من أن نظامنا العنقودي قد بقي قيد التشغيل.

 systemctl stop kubelet && systemctl stop docker 

تحقق من العقدة الرئيسية الثانية

 root@master02:~# kubectl get nodes NAME STATUS ROLES AGE VERSION master01 NotReady master 15h v1.15.1 master02 Ready master 15h v1.15.1 master03 Ready master 15h v1.15.1 worknode01 Ready <none> 15h v1.15.1 worknode02 Ready <none> 15h v1.15.1 worknode03 Ready <none> 15h v1.15.1 

تعمل جميع العقد بشكل طبيعي باستثناء تلك التي أوقفنا فيها الخدمات.
لا تنسى إعادة تشغيل خدمات kubernetes على العقدة الرئيسية الأولى

 systemctl start kubelet && systemctl start docker 

تثبيت جهاز التحكم في الدخول

تعد أداة التحكم في الدخول هي وظيفة Kubernetes الإضافية ، والتي يمكننا من خلالها الوصول إلى تطبيقاتنا من الخارج. يوجد وصف مفصل في وثائق Kuberbnetes . هناك الكثير جدا من وحدات التحكم الدخول ، وأنا استخدم وحدة تحكم من Nginx. سأتحدث عن التثبيت. يمكن قراءة الوثائق المتعلقة بتشغيل وتهيئة وتركيب جهاز التحكم في الدخول من Nginx على الموقع الرسمي

لنبدأ التثبيت ، يمكن تنفيذ جميع الأوامر باستخدام master01.
تثبيت وحدة تحكم نفسها

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml 

والآن - خدمة من خلالها ستتوفر الدخول
للقيام بذلك ، قم بإعداد التكوين

 ./create-config.sh ingress 

وأرسلها إلى مجموعتنا

 kubectl apply -f ingress/service-nodeport.yaml 

تحقق من أن Ingress يعمل على العناوين الصحيحة ويستمع إلى المنافذ الصحيحة.

 # kubectl get svc -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx NodePort 10.99.35.95 10.73.71.25,10.73.71.26,10.73.71.27 80:31669/TCP,443:31604/TCP 10m 

  kubectl describe svc -n ingress-nginx ingress-nginx Name: ingress-nginx Namespace: ingress-nginx Labels: app.kubernetes.io/name=ingress-nginx app.kubernetes.io/part-of=ingress-nginx Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/par... Selector: app.kubernetes.io/name=ingress-nginx,app.kubernetes.io/part-of=ingress-nginx Type: NodePort IP: 10.99.35.95 External IPs: 10.73.71.25,10.73.71.26,10.73.71.27 Port: http 80/TCP TargetPort: 80/TCP NodePort: http 31669/TCP Endpoints: 192.168.142.129:80 Port: https 443/TCP TargetPort: 443/TCP NodePort: https 31604/TCP Endpoints: 192.168.142.129:443 Session Affinity: None External Traffic Policy: Cluster Events: <none> 

تثبيت Web UI (لوحة المعلومات)

Kubernetes لديه واجهة مستخدم ويب قياسية ، والتي من خلالها يكون من المناسب في بعض الأحيان أن ننظر بسرعة إلى حالة الكتلة أو أجزائها الفردية. في عملي ، غالبًا ما أستخدم لوحة القيادة للتشخيص المبدئي لعمليات النشر أو لحالة أجزاء الكتلة.
رابط الوثائق موجود على موقع kubernetes
التثبيت. أنا أستخدم الإصدار المستقر ، لم أحاول الإصدار 2.0 بعد.

 #  kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml # 2.0 kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml 

بعد أن قمنا بتثبيت اللوحة في مجموعتنا ، أصبحت اللوحة متاحة في

 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/. 

ولكن من أجل الوصول إليها ، نحتاج إلى إعادة توجيه المنافذ من الجهاز المحلي باستخدام وكيل kubectl. بالنسبة لي ، هذا المخطط ليست مريحة للغاية. لذلك ، سوف أقوم بتغيير خدمة لوحة التحكم بحيث تصبح لوحة القيادة متاحة على عنوان أي عقدة كتلة على المنفذ 30443. هناك طرق أخرى للوصول إلى لوحة القيادة ، على سبيل المثال ، من خلال الدخول. ربما سأنظر في هذه الطريقة في المنشورات التالية.
لتغيير الخدمة ، قم بتشغيل نشر الخدمة التي تم تغييرها

 kubectl apply -f dashboard/service-nodeport.yaml 

يبقى لإنشاء المستخدم المسؤول والرمز المميز للوصول إلى الكتلة من خلال لوحة القيادة

 kubectl apply -f dashboard/rbac.yaml kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}') 

بعد ذلك ، يمكنك تسجيل الدخول إلى لوحة التحكم على https://10.73.71.25:30443

الشاشة الرئيسية للوحة القيادة

تهانينا! إذا كنت قد وصلت إلى هذه الخطوة ، فأنت لديك مجموعة HA من kubernetes تعمل ، وهي جاهزة لنشر تطبيقاتك.
Kubernetes , . .
, GitHub, , .
C , .