ألقى بافيل سيليفانوف ، مهندس حلول ساوثبريدج ومحاضر سلور ، محاضرة في DevOpsConf 2019. هذا الحديث هو جزء من Kubernetes Slur Mega ، دورة متعمقة حول Kubernetes.
Slurm Basic: مقدمة عن Kubernetes تجري في موسكو في الفترة 18-20 نوفمبر.
Slurm Mega: نحن ننظر تحت غطاء Kubernetes - موسكو ، 22-24 نوفمبر.
Slurm Online: كلا الدورات Kubernetes متوفرة دائمًا .
تحت قص - نسخة من التقرير.
مساء الخير ، الزملاء والمتعاطفين. اليوم سأتحدث عن الأمن.
أرى أن هناك العديد من حراس الأمن في القاعة اليوم. أعتذر لك مقدمًا إذا لم أستخدم المصطلحات الواردة من عالم الأمان بنفس الطريقة المعتادة بالنسبة لك.
لقد حدث ذلك منذ حوالي ستة أشهر في يد مجموعة عامة واحدة من Kubernetes. عام - يعني أن هناك عددًا نسبيًا من مساحات الأسماء ، في مساحة الاسم هذه يوجد مستخدمون معزولون في مساحة الاسم الخاصة بهم. جميع هؤلاء المستخدمين ينتمون إلى شركات مختلفة. حسنًا ، كان من المفترض أن هذه المجموعة يجب أن تستخدم كنموذج CDN. أي أنها تعطيك مجموعة ، وهي توفر للمستخدم هناك ، وتذهب إلى هناك في مساحة اسمك ، وتنشر جبهاتك.
لقد حاولوا بيع هذه الخدمة لشركتي السابقة. وقد طُلب مني أن أضع مجموعة حول هذا الموضوع - هل هذا الحل مناسب أم لا.
جئت إلى هذه المجموعة. لقد أعطيت حقوقًا محدودة ومساحة محدودة. هناك ، فهم الرجال ما كان الأمن. قرأوا ما هو التحكم في الوصول (RBAC) الذي يعتمد على نظام روبرت ل Kubernetes - وقد قاموا بتحريفه بحيث لا أستطيع تشغيل السنفات بشكل منفصل عن النشر. لا أتذكر المهمة التي كنت أحاول حلها من خلال العمل دون نشر ، لكنني أردت حقًا الترشح. قررت حظًا سعيدًا لمعرفة الحقوق التي أمتلكها في المجموعة ، ما يمكنني ، ما لا أستطيع ، ما الذي قاموا به هناك. في نفس الوقت ، سأخبرك بما قاموا بتكوينه في RBAC بشكل غير صحيح.
لقد حدث في دقيقتين أنني حصلت على مشرف في مجموعتهم ، ونظرت في جميع مساحات الأسماء المجاورة ، وشاهدت جبهات إنتاج الشركات التي اشترت الخدمة بالفعل وتعثرت هناك. بالكاد أوقفت نفسي ، حتى لا أذهب إلى شخص ما في المقدمة ولا أضع أي كلمة فاحشة على الصفحة الرئيسية.
سوف أخبركم بأمثلة كيف فعلت هذا وكيف أحمي نفسي من هذا.
لكن أولاً ، أعرض نفسي. اسمي بافيل سيليفانوف. أنا مهندس معماري في ساوثبريدج. أنا أفهم Kubernetes ، DevOps وجميع أنواع الأشياء الفاخرة. مهندسو ساوثبريدج وأنا نبني كل هذا ، وأنصحك.
بالإضافة إلى أعمالنا الأساسية ، أطلقنا مؤخرًا مشاريع تسمى Slory. نحن نحاول توصيل قدرتنا على العمل مع Kubernetes إلى الجماهير ، لتعليم الآخرين كيفية العمل مع K8s أيضًا.
ما سأتحدث عنه اليوم. موضوع التقرير واضح - حول أمن مجموعة Kubernetes. لكنني أريد أن أقول على الفور أن هذا الموضوع كبير جدًا - وبالتالي أود أن أشير على الفور إلى ما لن أخبر عنه بالتأكيد. لن أتحدث عن المصطلحات التي تم اختراقها والتي أصبحت مائة مرة مفرطة الطحن على الإنترنت. أي RBAC والشهادات.
سأتحدث عن كيف سئمت أنا وزملائي من الأمن في مجموعة Kubernetes. نرى هذه المشاكل مع كل من مقدمي الخدمات الذين يقدمون مجموعات Kubernetes والعملاء الذين يأتون إلينا. وحتى مع العملاء الذين يأتون إلينا من شركات الاستشارات الإدارية الأخرى. وهذا هو ، حجم المأساة كبير جدا في الواقع.
حرفيا ثلاث نقاط ، والتي سأتحدث عنها اليوم:
- حقوق المستخدم مقابل حقوق جراب. حقوق المستخدم وحقوق الموقد ليست هي نفس الشيء.
- جمع معلومات المجموعة. سأظهر أنه من خلال المجموعة ، يمكنك جمع كل المعلومات التي تحتاجها دون أن يكون لها حقوق خاصة في هذه المجموعة.
- دوس الهجوم على الكتلة. إذا لم نتمكن من جمع المعلومات ، يمكننا وضع الكتلة في أي حال. سأتحدث عن هجمات حجب الخدمة على عناصر التحكم في الكتلة.
شيء آخر شائع أذكره هو المكان الذي اختبرت فيه كل شيء ، ما يمكنني قوله بالتأكيد أن كل شيء يعمل.
كأساس ، نأخذ تثبيت كتلة Kubernetes باستخدام Kubespray. إذا كان شخص ما لا يعرف ، فهذه مجموعة من الأدوار لـ Ansible. نحن نستخدمها باستمرار في عملنا. الشيء الجيد هو أنه يمكنك التمرير في أي مكان - يمكنك التمدد على الغدد ، وفي مكان ما في السحابة. طريقة التثبيت واحدة مناسبة من حيث المبدأ لكل شيء.
في هذه المجموعة ، سيكون لدي Kubernetes v1.14.5. يتم تقسيم المجموعة الكاملة لكوبا ، والتي سننظر فيها ، إلى مساحات أسماء ، كل مساحة اسم تنتمي إلى فريق منفصل ، يمكن لأعضاء هذا الفريق الوصول إلى كل مساحة اسم. لا يمكنهم الانتقال إلى مساحات أسماء مختلفة ، فقط إلى مساحاتهم الخاصة. ولكن هناك بعض حساب المسؤول الذي لديه حقوق في المجموعة بأكملها.
لقد وعدت بأن أول شيء سنحصل عليه هو الحصول على حقوق المسؤول في المجموعة. نحن بحاجة إلى جراب معد خصيصًا من شأنه كسر مجموعة Kubernetes. كل ما نحتاج إليه هو تطبيقه على مجموعة Kubernetes.
kubectl apply -f pod.yaml
سيصل هذا الملف إلى أحد سادة نظام Kubernetes. وبعد ذلك سوف تعيد المجموعة بسعادة ملف يسمى admin.conf إلينا. في كوبا ، يتم تخزين جميع شهادات المسؤول في هذا الملف ، وفي الوقت نفسه ، يتم تكوين واجهة برمجة تطبيقات نظام المجموعة. هذه هي الطريقة التي يمكنك من خلالها الوصول إلى المشرف ، كما أعتقد ، إلى 98٪ من مجموعات Kubernetes.
وأكرر ، لقد تم إعداد هذا التطبيق من قِبل مطور واحد في مجموعتك لديه حق الوصول إلى نشر مقترحاته على مساحة اسم واحدة صغيرة ، وقد فرض عليه RBAC جميعًا. لم يكن لديه حقوق. ومع ذلك ، فقد عاد الشهادة.
والآن عن الموقد المعدة خصيصا. تشغيل على أي صورة. على سبيل المثال ، خذ دبيان: جيسي.
لدينا شيء من هذا القبيل:
tolerations: - effect: NoSchedule operator: Exists nodeSelector: node-role.kubernetes.io/master: ""
ما هو التسامح؟ عادةً ما يتم تمييز الأساتذة في مجموعة Kubernetes بشيء يسمى taint ("إصابة" باللغة الإنجليزية). وجوهر هذه "العدوى" - تقول أنه لا يمكن تعيين القرون لإتقان العقد. لكن لا أحد يزعج أن يشير بأي طريقة إلى أنه متسامح مع "العدوى". يقول قسم التسامح فقط إنه إذا كانت NoSchedule على عقدة ما ، فهذا يعني أن الإصابة لدينا تكون متسامحة - ولا توجد مشاكل.
علاوة على ذلك ، فإننا نقول إن لدينا تحت ليس فقط التسامح ، ولكن أيضا يريد أن يقع على وجه التحديد على السيد. لأن الأسياد هم الأكثر لذيذ الذي نحتاجه - كل الشهادات. لذلك ، نقول nodeSelector - ولدينا تسمية قياسية على المعالجات ، مما يسمح لنا بتحديد بالضبط تلك العقد التي هي معالجات من جميع عقد الكتلة.
مع هذا القسمين ، سيأتي بالتأكيد إلى المعلم. وسيسمح له بالعيش هناك.
لكن مجرد المجيء إلى المعلم لا يكفي بالنسبة لنا. لن يعطينا أي شيء. لذلك ، لدينا أيضًا هذين الأمرين:
hostNetwork: true hostPID: true
نشير إلى أن لدينا ، والتي نطلقها ، ستعيش في مساحة اسم kernel ، في مساحة اسم الشبكة وفي مساحة اسم PID. بمجرد بدء تشغيله على المعالج ، سيتمكن من رؤية جميع الواجهات الحقيقية والمباشرة لهذه العقدة ، والاستماع إلى كل حركة المرور ، ومعرفة PID لجميع العمليات.
بعد ذلك ، إنه صغير. خذ وقراءة ما تريد.
الأكثر إثارة للاهتمام هو هذه الميزة Kubernetes ، التي توجد هناك افتراضيا.
volumeMounts: - mountPath: /host name: host volumes: - hostPath: path: / type: Directory name: host
وجوهرها هو أنه يمكننا القول إننا نريد إنشاء وحدة تخزين من نوع hostPath في الحافظة التي نديرها ، حتى بدون حقوق هذه المجموعة. هذا يعني أخذ المسار من المضيف الذي سنبدأ عليه - واعتبره وحدة تخزين. ومن ثم نسميها اسم: المضيف. كل هذا hostPath نصعد داخل الموقد. في هذا المثال ، إلى الدليل / المضيف.
أكرر مرة أخرى. قلنا للقرنة أن تأتي إلى المعلم ، وأن تحصل على hostNetwork و hostPID هناك - وأن نحمل الجذر الرئيسي للماجستير داخل هذا الملف.
أنت تدرك أنه في دبيان لدينا bash run ، وهذا bash يعمل تحت جذرنا. وهذا هو ، لقد حصلنا على الجذر للسيد ، في حين لم يكن لدينا أي حقوق في مجموعة Kubernetes.
ثم المهمة الكاملة هي الذهاب إلى الدليل الفرعي / المضيف / etc / kubernetes / pki ، إذا لم أكن مخطئًا ، فاخذ جميع الشهادات الرئيسية للمجموعة هناك ، وبالتالي ، أصبح مسؤولًا عن المجموعة.
إذا نظرت بهذه الطريقة ، فهذه هي بعض من أخطر الحقوق في القرون - على الرغم من حقوق المستخدم:
إذا كان لديّ حقوق للتشغيل في بعض مساحة أسماء المجموعات ، فإن هذا الفرع الفرعي لديه هذه الحقوق افتراضيًا. يمكنني تشغيل القرون المتميزة ، وهذا عمومًا كل الحقوق ، جذرًا عمليًا على العقدة.
بلدي المفضل هو المستخدم الجذر. ول Kubernetes مثل هذا الخيار Run As Non-Root. هذا هو نوع من الحماية القراصنة. هل تعرف ما هو "فيروس مولدافيا"؟ إذا كنت أحد المتطفلين وأتيت إلى مجموعة Kubernetes الخاصة بي ، فعندئذ ، نحن المسئولين الفقراء ، نسأل: "يرجى الإشارة في قرونك التي ستقوم باختراق مجموعتي بها ، قم بالعمل كجذر. ويحدث ذلك عندما تبدأ العملية في قلبك تحت الجذر ، وسيكون من السهل عليك اختراقك. يرجى حماية نفسك من نفسك. "
حجم مسار المضيف - في رأيي ، أسرع طريقة للحصول على النتيجة المرجوة من مجموعة Kubernetes.
ولكن ماذا تفعل مع كل هذا؟
الأفكار التي يجب أن تأتي إلى أي مسؤول عادي يواجه Kubernetes: "نعم ، قلت لك ، Kubernetes لا يعمل. هناك ثقوب فيه. والمكعب كله هراء. " في الواقع ، يوجد شيء مثل الوثائق ، وإذا نظرت إلى هناك ، فهناك قسم سياسة الأمن في Pod .
هذا كائن yaml - يمكننا إنشاؤه في مجموعة Kubernetes - التي تتحكم في الجوانب الأمنية في وصف الموقد. هذا ، في الواقع ، يتحكم في تلك الحقوق لاستخدام جميع أنواع hostNetwork ، hostPID ، وأنواع معينة من وحدة التخزين ، والتي هي في السنفات عند بدء التشغيل. مع Pod Security Policy ، كل هذا يمكن وصفه.
الشيء الأكثر إثارة للاهتمام في Pod Security Policy هو أنه في نظام Kubernetes ، لا يتم وصف جميع مثبتي PSP ببساطة بأي طريقة ، بل يتم إيقاف تشغيلهم بشكل افتراضي. يتم تمكين سياسة الأمن الجراب باستخدام البرنامج المساعد القبول.
حسنًا ، دعنا ننتهي في مجموعة سياسة أمان Pod ، لنفترض أن لدينا نوعًا من قرون الخدمة في مساحة الاسم ، والتي لا يستطيع الوصول إلا إلى المشرفين. دعنا نقول في جميع القرون الأخرى لديهم حقوق محدودة. لأنه على الأرجح ، لا يحتاج المطورون إلى تشغيل برامج مميزة في نظامك.
ويبدو أن كل شيء على ما يرام معنا. ولا يمكن اختراق مجموعة Kubernetes الخاصة بنا في دقيقتين.
هناك مشكلة. على الأرجح ، إذا كان لديك نظام Kubernetes ، فسيتم تثبيت المراقبة في نظامك. أفترض أن أتوقع أنه إذا كان هناك مراقبة في مجموعتك ، فإن هذا يسمى بروميثيوس.
ما سأخبرك به الآن سيكون صالحًا لكل من مشغل بروميثيوس وبروميثيوس تسليمه بشكله النقي. السؤال هو أنه إذا لم أتمكن من توصيل المشرف بسرعة إلى المجموعة ، فهذا يعني أنني بحاجة إلى مزيد من البحث. ويمكنني البحث باستخدام المراقبة الخاصة بك.
من المحتمل أن يقرأ الجميع المقالات نفسها عن حبري ، والمراقبة هي قيد الرصد. يسمى مخطط هيلم نفسه تقريبا للجميع. أفترض أنك إذا قمت بتثبيت أداة تثبيت / prometheus ثابتة ، فستحصل على نفس الأسماء تقريبًا. وحتى على الأرجح لن أضطر إلى تخمين اسم DNS في مجموعتك. لأنه هو المعيار.
علاوة على ذلك لدينا devs معينة ، فمن الممكن لإطلاق بعض تحت. علاوة على ذلك ، من السهل جدًا القيام بما يلي:
$ curl http://prometheus-kube-state-metrics.monitoring
بروميثيوس-كيوب-الدولة-المقاييس هي واحدة من المصدرين بروميثيوس التي تجمع المقاييس من API Kubernetes. هناك الكثير من البيانات التي يتم تشغيلها في نظامك ، وما هي عليه ، وما هي المشاكل التي تواجهها.
كمثال بسيط:
kube_pod_container_info {namespace = "kube-system"، pod = "kube-apiserver-k8s-1"، container = "kube-apiserver"، image =
"gcr.io/google-containers/kube-apiserver:v1.14.5"
، Image_id = "عامل ميناء pullable: //gcr.io/google-containers/kube- apiserver @ SHA256: e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989"، container_id = "عامل ميناء: // 7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b"} 1
بعد إجراء طلب حليقة بسيط من ملف غير منقطع ، يمكنك الحصول على هذه المعلومات. إذا كنت لا تعرف إصدار Kubernetes الذي تقوم بتشغيله ، فسيخبرك بسهولة.
والأكثر إثارة للاهتمام هو أنه بالإضافة إلى حقيقة أنك تتحول إلى مقاييس الحالة kube ، يمكنك أن تنطبق بنفس القدر مباشرة على Prometheus نفسها. يمكنك جمع المقاييس من هناك. يمكنك حتى بناء المقاييس من هناك. حتى من الناحية النظرية ، يمكنك إنشاء مثل هذا الطلب من كتلة في بروميثيوس ، والتي ببساطة إيقاف تشغيله. والرصد الخاص بك عموما يتوقف عن العمل من الكتلة.
وهنا السؤال الذي يطرح نفسه بالفعل ما إذا كان أي رصد خارجي يراقب الرصد الخاص بك. لقد حصلت على فرصة للعمل في مجموعة Kubernetes دون أي عواقب على نفسي. أنت لا تعرف حتى أنني أتصرف هناك ، لأنه لم يعد هناك مراقبة.
تمامًا كما هو الحال مع PSP ، يبدو أن المشكلة تكمن في أن كل هذه التقنيات العصرية - Kubernetes و Prometheus - لا تعمل تمامًا كما أنها مليئة بالثقوب. ليس حقا
هناك شيء من هذا القبيل - سياسة الشبكة .
إذا كنت مسؤولًا عاديًا ، فمن الأرجح أنك تعرف عن "سياسة الشبكة" أن هذا هو yaml آخر ، والذي في المجموعة بالفعل dofig. وبالتأكيد ليست هناك حاجة لبعض سياسات الشبكة. وحتى إذا قرأت ماهية Network Policy (سياسة الشبكة) ، ما هو جدار الحماية Kubernetes yaml-fire ، فهو يسمح لك بتقييد حقوق الوصول بين مساحات الأسماء ، بين القرون ، ومن المؤكد أنك قررت أن جدار الحماية yaml-type في Kubernetes موجود على التجريدات التالية ... لا ، لا . هذا بالتأكيد ليس ضروريا.
حتى إذا لم يتم إخبار أخصائيي الأمان لديك باستخدام Kubernetes ، فيمكنك إنشاء جدار حماية بسهولة شديدة وبساطة ، وهو محبب للغاية. إذا كانوا لا يزالون لا يعرفون هذا ولا يسحبونك: "حسنًا ، أعط ، أعط ..." في أي حال ، تحتاج إلى "سياسة الشبكة" لمنع الوصول إلى بعض الأماكن الرسمية التي يمكنك سحبها من مجموعتك دون أي إذن.
كما في المثال الذي أشرت إليه ، يمكنك سحب مقاييس حالة kube من أي مساحة اسم في نظام Kubernetes دون أن يكون لديك أي حقوق في ذلك. أغلقت سياسات الشبكة الوصول من جميع مساحات الأسماء الأخرى إلى مراقبة مساحة الاسم ، وكما كان الحال ، كل شيء: لا وصول ، ولا توجد مشاكل. في جميع الرسوم البيانية الموجودة ، كل من prometeus القياسية ، و prometeus الموجودة في المشغل ، هناك ببساطة في قيم القيادة هناك خيار لتمكين سياسات الشبكة ببساطة لهم. تحتاج فقط إلى تشغيله وسيعملون.
هناك حقا مشكلة واحدة هنا. كونك مسؤولًا ملتحيًا عاديًا ، فقد قررت على الأرجح أن سياسات الشبكة غير مطلوبة. وبعد قراءة جميع أنواع المقالات حول الموارد مثل Habr ، قررت أن الفانيلا خاصةً مع وضع بوابة المضيف هو أفضل شيء يمكنك اختياره.
ما يجب القيام به
يمكنك محاولة إعادة نشر حل الشبكة الموجود في مجموعة Kubernetes الخاصة بك ، حاول استبداله بشيء أكثر وظيفية. على نفس كاليكو ، على سبيل المثال. لكن على الفور أريد أن أقول إن مهمة تغيير حل الشبكة في مجموعة عمل Kubernetes غير مهمة تمامًا. لقد قمت بحلها مرتين (في كلتا الحالتين ، من الناحية النظرية) ، ولكن حتى أظهرنا كيفية القيام بذلك على Slurms. لطلابنا ، أظهرنا كيفية تغيير حل الشبكة في مجموعة Kubernetes. من حيث المبدأ ، يمكنك محاولة التأكد من عدم وجود توقف في مجموعة الإنتاج. لكنك لن تنجح على الأرجح.
والمشكلة هي في الواقع حلها بكل بساطة. هناك شهادات في المجموعة ، وأنت تعلم أن شهاداتك سوف تسوء في السنة. حسنًا ، وعادةً ما يكون حلاً عاديًا يحتوي على شهادات في المجموعة - لماذا سنذهب للبخار ، وسنقوم بتكوين مجموعة جديدة بجانبها ، ودعها تتعفن في المجموعة القديمة ، وسنعيد كل شيء. صحيح ، عندما تسوء الأمور ، كل شيء سوف يستلقي في عصرنا ، ولكن بعد ذلك مجموعة جديدة.
عندما ترفع كتلة جديدة ، أدخل كاليكو في نفس الوقت بدلاً من الفانيلا.
ماذا تفعل إذا كان لديك شهادات صدرت لمائة عام وأنت لن تعيد تجميع المجموعة؟ هناك شيء من هذا القبيل Kube-RBAC-Proxy. هذا تطور رائع ، فهو يسمح لك بتضمين نفسك كحاوية جانبية في أي مكان في مجموعة Kubernetes. وهي في الواقع تضيف التفويض من خلال Kubernetes RBAC إلى هذا الملف.
هناك مشكلة واحدة. في السابق ، تم بناء Kube-RBAC-Proxy في بروميثوس المشغل. ولكن بعد ذلك ذهب. الآن ، تعتمد الإصدارات الحديثة على حقيقة أن لديك سياسة شبكة وتغلق في استخدامها. ولذا عليك إعادة كتابة المخطط قليلاً. في الواقع ، إذا ذهبت إلى هذا المستودع ، فهناك أمثلة على كيفية استخدامه كأدوات جانبية ، وسيكون عليك إعادة كتابة المخططات إلى الحد الأدنى.
هناك مشكلة صغيرة أخرى. ليس فقط بروميثيوس تعطي مقاييسها لأي شخص يحصل عليها. لدينا جميع مكونات مجموعة Kubernetes ، أيضًا ، يمكنها إعطاء مقاييسها.
ولكن كما قلت ، إذا لم تتمكن من الوصول إلى المجموعة وجمع المعلومات ، فيمكنك على الأقل إلحاق ضرر.
لذلك سأظهر لك بسرعة طريقتين يمكنك من إفساد مجموعة Kubernetes الخاصة بك.
سوف تضحك عندما أقول لك ، هاتان حالتان من واقع الحياة.
الطريقة الأولى ينفد من الموارد.
نطلق واحدة أكثر خاصة تحت. سيكون لديه مثل هذا القسم.
resources: requests: cpu: 4 memory: 4Gi
كما تعلمون ، فإن الطلبات هي مقدار وحدة المعالجة المركزية والذاكرة المحجوزة على المضيف لأقراص معينة مع الطلبات. إذا كان لدينا مضيف رباعي النواة في مجموعة Kubernetes ، وأربعة وحدات معالجة مركزية تأتي إلى هناك مع الطلبات ، فهذا يعني أنه لا يمكن الوصول إلى المزيد من السنفات مع طلبات هذا المضيف.
إذا قمت بتشغيل هذا ، فسوف أقوم بإجراء أمر:
$ kubectl scale special-pod --replicas=...
عندها لن يتمكن أي شخص آخر من الانتشار إلى مجموعة Kubernetes. لأنه في جميع العقد ستنتهي الطلبات. ولذا فإنني أوقف مجموعة Kubernetes الخاصة بك. إذا قمت بذلك في المساء ، فعندئذ يمكنني إيقاف النشر لبعض الوقت.
إذا نظرنا مرة أخرى إلى وثائق Kubernetes ، فسنرى شيئًا يسمى نطاق الحد. يقوم بتعيين الموارد لكائنات الكتلة. يمكنك كتابة كائن "حدود المدى" في yaml ، وتطبيقه على مساحات أسماء معينة - وعلاوة على ذلك ، في مساحة الاسم هذه ، يمكنك القول أن لديك موارد للقرون الافتراضية والحد الأقصى والحد الأدنى.
بمساعدة شيء من هذا القبيل ، يمكننا تقييد المستخدمين في مساحات أسماء منتجات معينة للفرق في القدرة على الإشارة إلى أي أشياء سيئة على السنفات الخاصة بهم. لكن لسوء الحظ ، حتى لو أخبرت المستخدم أنه من المستحيل تشغيل قرون مع طلبات أكثر من وحدة المعالجة المركزية ، فهناك أمر رائع من حيث الحجم ، أو من خلال لوحة القيادة يمكنهم القيام بالتدريج.
ومن هنا تأتي الطريقة الثانية. نطلق 11 111 111 111 111 الموقد. هذا هو أحد عشر مليار. هذا ليس لأنني توصلت إلى هذا العدد ، ولكن لأنني رأيته بنفسي.
القصة الحقيقية. في وقت متأخر من المساء كنت على وشك مغادرة المكتب. أنا أنظر ، مجموعة من المطورين يجلسون في الزاوية ويقومون بشيء محموم مع أجهزة الكمبيوتر المحمولة. أذهب إلى اللاعبين وأسأل: "ماذا حدث لك؟"
قبل ذلك بقليل ، في التاسعة مساءً ، كان أحد المطورين عائدين إلى المنزل. وقرر: "سأتخطى طلبي حتى الآن." لقد نقرت قليلا ، والإنترنت قليلا ممل. نقر مرة أخرى على الوحدة ، وضغط على الوحدة ، والنقر على Enter. مطعون على كل ما يستطيع. ثم ظهرت الإنترنت - وبدأ كل شيء في التوسع حتى هذا التاريخ.
صحيح ، هذه القصة لم تحدث على Kubernetes ، في ذلك الوقت كان البدو الرحل. لقد انتهى الأمر إلى حقيقة أنه بعد ساعة من محاولاتنا لمنع نوماد من المحاولات العنيدة للالتقاء معًا ، أجاب نوماد أنه لن يتوقف عن الالتصاق ولن يفعل أي شيء آخر. "أنا متعب ، سأرحل". وكرة لولبية.
حاولت بطبيعة الحال أن تفعل الشيء نفسه على Kubernetes. وقال إن القرون الأحد عشر مليار من Kubernetes لم تكن سعيدة ، وقال: "لا أستطيع. يتجاوز واقيات الفم الداخلية ". لكن 1،000،000،000 الموقد يمكن.
استجابة لمليار ، لم يذهب المكعب إلى الداخل. لقد بدأ حقًا في التوسع. كلما طالت العملية ، زاد الوقت الذي استغرقه الأمر لإنشاء قلوب جديدة. ولكن لا تزال العملية مستمرة. المشكلة الوحيدة هي أنه إذا كان بإمكاني تشغيل القرون إلى أجل غير مسمى في مساحة الاسم الخاصة بي ، فإنه حتى بدون الطلبات والحدود ، يمكنني بدء مثل هذا العدد من القرون ببعض المهام التي تبدأ هذه العقد في إضافتها من الذاكرة ، من خلال وحدة المعالجة المركزية هذه. عندما أقوم بتشغيل الكثير من المداخل ، يجب أن تنتقل المعلومات منها إلى المستودع ، أي ، إلخ. وعندما تصل الكثير من المعلومات إلى هناك ، يبدأ المخزن في التخلي عن ببطء شديد - وفي Kubernetes تبدأ الأمور المملة.
ومشكلة أخرى ... كما تعلمون ، فإن عناصر التحكم في Kubernetes ليست مجرد شيء مركزي واحد ، ولكن العديد من المكونات. هناك ، على وجه الخصوص ، هناك مدير وحدة تحكم وجدولة وما إلى ذلك. سيبدأ كل هؤلاء الرجال في القيام بعمل غبي لا لزوم له في نفس الوقت ، والذي مع مرور الوقت سيبدأ في أخذ المزيد والمزيد من الوقت. فإن مدير وحدة تحكم إنشاء قرون جديدة. سيحاول المجدول العثور عليها عقدة جديدة. من المرجح أن تنتهي العقد الجديدة في نظامك قريبًا. ستبدأ مجموعة Kubernetes في العمل ببطء أكثر وبطء.
لكنني قررت أن أذهب أبعد من ذلك. كما تعلمون ، في Kubernetes هناك شيء يسمى الخدمة. حسنًا ، وبشكل افتراضي في مجموعاتك ، على الأرجح ، تعمل الخدمة باستخدام جداول IP.
إذا قمت بتشغيل مليار واحد ، على سبيل المثال ، ثم استخدمت البرنامج النصي لإجبار Kubernetis على إنشاء خدمات جديدة:
for i in {1..1111111}; do kubectl expose deployment test --port 80 \ --overrides="{\"apiVersion\": \"v1\", \"metadata\": {\"name\": \"nginx$i\"}}"; done
على كافة عقد الكتلة ، سيتم إنشاء قواعد iptables جديدة تقريبًا في وقت واحد تقريبًا. علاوة على ذلك ، لكل خدمة ، سيتم إنشاء مليار قاعدة iptables.
راجعت كل هذا على عدة آلاف ، ما يصل إلى عشرات. والمشكلة هي أنه بالفعل في هذا العتبة ssh على العقدة هو إشكالية القيام به. لأن الحزم ، التي تمر بمثل هذا العدد من السلاسل ، تبدأ في الشعور بعدم الارتياح.
ويتم حل كل هذا بمساعدة Kubernetes. يوجد مثل كائن حصة الموارد. يعين عدد الموارد والكائنات المتاحة لمساحة الاسم في كتلة. يمكننا إنشاء كائن yaml في كل مساحة اسم من كتلة Kubernetes. باستخدام هذا الكائن ، يمكننا القول أننا خصصنا عددًا معينًا من الطلبات وحدود مساحة الاسم هذه ، ومن ثم يمكننا القول أنه في مساحة الاسم هذه ، من الممكن إنشاء 10 خدمات و 10 قرون. ويمكن لمطور واحد على الأقل الضغط في المساء. سيقول له Kubernetes: "لا يمكنك التمسك بقرونك لمثل هذا المبلغ لأنه يتجاوز حصة المورد". كل شيء ، يتم حل المشكلة. الوثائق هنا .
نقطة واحدة مشكلة تنشأ في اتصال مع هذا. تشعر بمدى صعوبة إنشاء مساحة اسم في Kubernetes. لإنشائه ، نحن بحاجة إلى التفكير في مجموعة من الأشياء.
حصة المورد + حدود المدى + RBAC
• إنشاء مساحة الاسم
• إنشاء داخل limrange
• إنشاء داخل الموارد
• إنشاء serviceaccount ل CI
• إنشاء تجسيد الأدوار ل CI والمستخدمين
• تشغيل اختياريا قرون الخدمة اللازمة
لذلك ، أغتنم هذه الفرصة ، أود أن أشارك تطوراتي. هناك شيء من هذا القبيل ، ودعا مشغل SDK. هذه طريقة في نظام Kubernetes لكتابة العوامل الخاصة بها. يمكنك كتابة البيانات باستخدام Ansible.
أولاً ، تمت كتابته باللغة Ansible ، ثم نظرت إلى وجود مشغل SDK وإعادة كتابة دور Ansible في المشغل. يتيح لك هذا المشغل إنشاء كائن في نظام Kubernetes يسمى الفريق. yaml . , - .
.
. ?
. Pod Security Policy — . , , - .
Network Policy — - . , .
LimitRange/ResourceQuota — . , , . , .
, , , . .
. , warlocks , .
, , . , ResourceQuota, Pod Security Policy . .
.