سنتحدث اليوم عن Kubernetes وعن أشعل النار التي يمكن جمعها في الاستخدام العملي وعن التطورات التي ساعدت المؤلف والتي ستساعدك أيضًا. سنحاول أن نثبت أنه بدون k8s في العالم الحديث في أي مكان. بالنسبة إلى معارضي k8s ، نقدم أيضًا أسبابًا ممتازة لعدم ضرورة التبديل إليها. أي أننا في القصة لن ندافع عن Kubernetes فحسب ، بل سنوبخه أيضًا. من هنا جاء الاسم
[لا] .
تستند هذه المقالة إلى
عرض تقديمي قدمه إيفان جلوشكوف (
gli ) في مؤتمر DevOops 2017.كان آخر مكانين عمل إيفان مرتبطين بطريقة أو بأخرى مع Kubernetes: لقد عمل في أوامر تحتية في كل من Postmates و Machine Zone ، ويؤثران على Kubernetes بإحكام شديد. بالإضافة إلى ذلك ، يقود إيفان البودكاست
DevZen . مزيد من العرض سيكون نيابة عن إيفان.
أولاً ، سأستعرض بإيجاز المنطقة التي تعتبر مفيدة ومهمة للكثيرين ، ولماذا تنشأ هذه الضجة. ثم سأخبرك عن تجربتنا في استخدام التكنولوجيا. حسنا ، ثم الاستنتاجات.
في هذه المقالة ، يتم إدراج جميع الشرائح كصور ، ولكن في بعض الأحيان تريد نسخ شيء ما. على سبيل المثال ، ستكون هناك أمثلة مع التكوينات. يمكن تنزيل شرائح PDF
هنا .
لن أقول للجميع بدقة: تأكد من استخدام Kubernetes. هناك إيجابيات وسلبيات ، لذلك إذا جئت للبحث عن سلبيات ، ستجدها. لديك خيار ، وانظر فقط إلى الإيجابيات ، وسلبيات فقط ، وعموما ننظر إلى كل شيء معا. سوف يساعدني
Simon Cat في المحترفين ، وسوف يعبر القط الأسود الطريق عندما يكون هناك ناقص.
لذا ، لماذا حدث هذا الضجيج على الإطلاق ، لماذا تقنية X أفضل من Y. Kubernetes هي نفس النظام بالضبط ، وهناك أكثر من واحد. هناك العرائس ، الشيف ، Ansible ، Bash + SSH ، Terraform. SSH المفضلة هي مساعدتي الآن ، لماذا يجب أن أذهب إلى مكان ما. أعتقد أن هناك العديد من المعايير ، لكنني أبرزت أهمها.
الوقت من الالتزام إلى الإصدار هو علامة جيدة جدًا ، والرجال من Express 42 هم خبراء رائعون في هذا الشأن. أتمتة التجميع ، أتمتة خط الأنابيب بأكمله أمر جيد جدًا ، لا يمكنك الثناء عليه ، إنه يساعد في الواقع. التكامل المستمر ، النشر المستمر. وبالطبع ، كم الجهد الذي ستقضيه في فعل كل شيء. يمكن كتابة كل شيء في Assembler ، كما أقول ، نظام نشر أيضًا ، ولكنه لن يضيف الراحة.
لن أخبركم بمقدمة قصيرة عن Kubernetes ، أنت تعرف ما هو. سوف أتطرق إلى هذه المجالات أكثر قليلاً.
لماذا كل هذا مهم جدا للمطورين؟ التكرار مهم بالنسبة لهم ، أي إذا كتبوا نوعًا من التطبيق ، وأجروا اختبارًا ، فإنه سيعمل من أجلك ومن أجل جارك ومن أجل الإنتاج.
والثاني هو بيئة موحدة: إذا كنت قد درست Kubernetes وانتقلت إلى شركة مجاورة حيث Kubernetes ، فسيكون كل شيء كما هو. إن تبسيط إجراء الاختبار والتكامل المستمر ليس نتيجة مباشرة لاستخدام Kubernetes ، ولكنه لا يزال يبسط المهمة ، لذلك يصبح كل شيء أكثر ملاءمة.
لمطوري الإصدار ، هناك العديد من المزايا. أولاً ، إنها بنية تحتية غير قابلة للتغيير.
ثانيًا ، البنية التحتية تشبه التعليمات البرمجية المخزنة في مكان ما. ثالثا ، idempotency ، والقدرة على إضافة إصدار مع زر واحد. تحدث التراجع عن الإطلاق بسرعة كبيرة ، واستبطان النظام مريح للغاية. بالطبع ، كل هذا يمكن القيام به على نظامك ، مكتوبًا على الركبة ، ولكن لا يمكنك دائمًا القيام بذلك بشكل صحيح ، وقد قامت Kubernetes بتطبيقه بالفعل.
ما هو Kubernetes ليس ، وما الذي لا يسمح به؟ هناك العديد من المفاهيم الخاطئة في هذا الصدد. لنبدأ بالحاويات. Kubernetes يعمل فوقها. الحاويات ليست آلات افتراضية خفيفة الوزن ، ولكنها كيان مختلف تمامًا. من السهل شرحها بمساعدة هذا المفهوم ، ولكن في الواقع هذا خطأ. المفهوم مختلف تمامًا ، يجب فهمه وقبوله.
ثانيًا ، لا تجعل Kubernetes التطبيق أكثر أمانًا. لا يجعلها قابلة للتحجيم تلقائيًا.
أنت بحاجة إلى المحاولة الجادة لبدء Kubernetes ، فلن يكون ذلك "بالضغط على زر ، وعمل كل شيء تلقائيًا". سوف يؤلم.
تجربتنا. نحن نريد من الجميع عدم كسر أي شيء. للقيام بذلك ، تحتاج إلى إلقاء نظرة أكثر حول - وهنا جانبنا.
أولا ، Kubernetes لا تذهب وحدها. عندما تقوم ببناء هيكل من شأنه إدارة الإصدارات وعمليات النشر بشكل كامل ، يجب أن تفهم أن Kubernetes هو نرد واحد ، ويجب أن يكون هناك 100 نرد. لبناء كل هذا ، تحتاج إلى دراسته بكل صعوبة. المبتدئين الذين سيأتون إلى نظامك سيدرسون أيضًا هذه الحزمة ، كمية هائلة من المعلومات.
Kubernetes ليست الكتلة المهمة الوحيدة ، فهناك العديد من الكتل المهمة الأخرى حولها ، والتي بدونها لن يعمل النظام. أي ، عليك أن تقلق كثيرًا بشأن تحمل الخطأ.
وبسبب هذا ، Kubernetes هو ناقص. النظام معقد ، تحتاج إلى رعاية الكثير.
ولكن هناك إيجابيات. إذا درس شخص Kubernetes في شركة واحدة ، فلن يقف شعره في شركة أخرى في نظام الإفراج. بمرور الوقت ، عندما تستحوذ Kubernetes على مساحة أكبر ، سيكون انتقال الأشخاص والتدريب أسهل. ولهذا - زائد.
نستخدم هيلم. يشبه هذا النظام ، المبني على Kubernetes ، مدير الحزم. يمكنك النقر على الزر ، لنفترض أنك تريد تثبيت * Wine * على نظامك. يمكن تثبيته في Kubernetes. يعمل ، يتم تنزيله تلقائيًا ، يبدأ ، وسيعمل كل شيء. يسمح لك بالعمل مع المكونات الإضافية ، وبنية خادم العميل. إذا كنت تعمل معه ، نوصي بتشغيل Tiller واحد على مساحة الاسم. يؤدي هذا إلى عزل مساحة الاسم عن بعضها البعض ، ولا يؤدي كسر أحدهما إلى كسر الآخر.
في الواقع ، النظام معقد للغاية. إن النظام ، الذي يجب أن يكون تجريدًا لمستوى أعلى وأبسط وأكثر قابلية للفهم ، لا يجعله أسهل في الفهم. لهذا الطرح.
دعنا نقارن التكوينات. على الأرجح ، لديك أيضًا بعض التكوينات إذا قمت بتشغيل نظامك في الإنتاج. لدينا نظامنا الخاص يسمى BOOMer. لا أعرف لماذا اتصلنا بها. يتكون من Puppet ، Chef ، Ansible ، Terraform وكل شيء آخر ، هناك زجاجة كبيرة.
دعونا نرى كيف يعمل. فيما يلي مثال على تكوين حقيقي يعمل حاليًا في الإنتاج. ماذا نرى هنا؟
أولاً ، نرى أين يتم تشغيل التطبيق ، وثانيًا ، ما الذي يجب إطلاقه ، وثالثًا ، كيف يجب إعداده للإطلاق. في زجاجة واحدة تكون المفاهيم مختلطة بالفعل.
إذا نظرنا إلى أبعد من ذلك ، لأننا أضفنا الميراث لعمل تكوينات أكثر تعقيدًا ، يجب أن ننظر إلى ما هو موجود في التكوين المشترك الذي نشير إليه. بالإضافة إلى ذلك ، نضيف تكوين الشبكة وحقوق الوصول وتخطيط الحمل. كل هذا في تكوين واحد نحتاجه لتشغيل تطبيق حقيقي في الإنتاج ، نمزج مجموعة من المفاهيم في مكان واحد.
هذا صعب للغاية ، إنه خاطئ للغاية ، وهذه إضافة كبيرة لـ Kubernetes ، لأنه ببساطة يمكنك تحديد ما يجب تشغيله. تم تنفيذ إعداد الشبكة أثناء تثبيت Kubernetes ، وتم حل التزويد بالكامل باستخدام عامل الميناء - كان لديك تغليف ، وتم فصل جميع المشكلات بطريقة أو بأخرى ، وفي هذه الحالة ، يحتوي التكوين على تطبيقك فقط ، وهناك ميزة إضافية لذلك.
دعونا نلقي نظرة فاحصة. هنا لدينا تطبيق واحد فقط. من أجل نشر العمل ، تحتاج إلى مجموعة كاملة للعمل. أولاً ، تحتاج إلى تحديد الخدمات. كيف تأتي إلينا الأسرار ، ConfigMap ، الوصول إلى Load Balancer.
لا تنس أن لديك العديد من البيئات. هناك مرحلة / همز / ديف. كل هذا معًا ليس قطعة صغيرة عرضتها ، بل مجموعة ضخمة من التكوينات ، وهو أمر صعب حقًا. لهذا الطرح.
قالب هيلم للمقارنة. يكرر تمامًا قوالب Kubernetes ، إذا كان هناك أي ملف في Kubernetes مع تعريف النشر ، فسيكون نفس الشيء في Helm. بدلاً من القيم المحددة للبيئة ، لديك قوالب مستبدلة من القيم.
لديك قالب منفصل ، قيم منفصلة يجب استبدالها في هذا القالب.
بالطبع ، تحتاج إلى تحديد البنية التحتية المختلفة لـ Helm نفسها ، على الرغم من حقيقة أن لديك الكثير من ملفات التكوين في Kubernetes التي تحتاج إلى سحبها وإسقاطها في Helm. هذا كله صعب للغاية ، وهو ناقص.
إن النظام الذي يجب أن يبسط في الواقع معقد. بالنسبة لي ، هذا ناقص واضح. إما تحتاج إلى إضافة شيء آخر ، أو لا تستخدم
دعنا نتعمق ، نحن لسنا عميقين بما فيه الكفاية.
أولاً ، كيف نعمل مع المجموعات. قرأت مقالة Google
"Borg و Omega و Kubernetes" ، التي تنادي بشدة بالمفهوم الذي تحتاجه
لوجود مجموعة كبيرة واحدة. كنت مع هذه الفكرة أيضًا ، ولكن في النهاية تركناها. نتيجة لخلافاتنا ، نستخدم أربع مجموعات مختلفة.
أول مجموعة e2e لاختبار Kubernetes نفسها واختبار البرامج النصية التي تنشر البيئة والمكونات الإضافية وما إلى ذلك. الثانية ، بالطبع ، همز ومرحلة. هذه مفاهيم قياسية. ثالثًا ، هذا هو المسؤول ، حيث يتم تحميل كل شيء آخر - على وجه الخصوص ، لدينا CI هناك ، ويبدو أنه بسبب ذلك ستكون هذه المجموعة دائمًا أكبر.
هناك الكثير من الاختبارات: من خلال الالتزام ، عن طريق الدمج ، يقوم الجميع بمجموعة من الالتزامات ، وبالتالي فإن المجموعات ضخمة للغاية.
حاولنا أن ننظر إلى CoreOS ، لكننا لم نستخدمه. لديهم TF أو CloudFormation بالداخل ، وكلاهما بشكل سيء للغاية يسمح لنا بفهم ما هو داخل الدولة. وبسبب هذا ، هناك مشاكل أثناء الترقية. عندما تريد تحديث إعدادات Kubernetes الخاصة بك ، على سبيل المثال ، إصدارها ، قد تواجه حقيقة أن التحديث لا يعمل بهذه الطريقة ، في تسلسل خاطئ. هذه قضية استقرار كبيرة. هذا ناقص.
ثانيًا ، عند استخدام Kubernetes ، تحتاج إلى تنزيل الصور من مكان ما. يمكن أن يكون مصدرًا داخليًا أو مستودعًا أو خارجيًا. إذا كانت داخلية ، فهناك مشاكل. أوصي باستخدام Docker Distribution لأنه مستقر ، تم إجراؤه بواسطة Docker. لكن سعر الدعم لا يزال مرتفعا. لكي تعمل ، تحتاج إلى جعلها تتحمل الأخطاء ، لأن هذا هو المكان الوحيد الذي تحصل فيه تطبيقاتك على بيانات للعمل من خلالها.
تخيل أنه في اللحظة الحاسمة ، عندما وجدت خطأ في الإنتاج ، سقط المستودع الخاص بك - لا يمكنك تحديث التطبيق. يجب أن تجعلها متسامحة مع الخطأ ، ومن جميع المشاكل المحتملة التي يمكن أن تكون فقط.
ثانيًا ، إذا كانت كتلة الفرق ، لكل منها صورتها الخاصة ، فإنها تتراكم كثيرًا وبسرعة كبيرة. يمكنك قتل Docker Distribution الخاص بك. من الضروري القيام بالتنظيف وحذف الصور وتقديم المعلومات للمستخدمين ومتى وما الذي ستقوم بتنظيفه.
ثالثًا ، مع الصور الكبيرة ، دعنا نقول ، إذا كان لديك كتلة متجانسة ، فسيكون حجم الصورة كبيرًا جدًا. تخيل أنك بحاجة إلى تحرير 30 عقدة. 2 غيغابايت لكل 30 عقدة - احسب الدفق ، ومدى سرعة تنزيله على جميع العقد. أود أن تضغط على زر ، ويصبح لونه أخضر على الفور. ولكن لا ، يجب أن تنتظر أولاً حتى يتم تنزيله. من الضروري تسريع هذا التنزيل بطريقة أو بأخرى ، وكل ذلك يعمل من نقطة واحدة.
مع المستودعات الخارجية ، هناك نفس المشاكل مع جامع القمامة ، ولكن في أغلب الأحيان يتم ذلك تلقائيًا. نستخدم رصيف. في حالة المستودعات الخارجية ، فهذه خدمات تابعة لجهات خارجية تكون فيها معظم الصور عامة. لعدم وجود صور عامة ، فمن الضروري توفير الوصول. نحتاج إلى أسرار ، حقوق الوصول إلى الصور ، كل هذا تم تكوينه خصيصًا. بالطبع ، يمكن أتمتة هذا ، ولكن في حالة الإطلاق المحلي لكوبا على نظامك ، لا يزال عليك تكوينها.
لتثبيت Kubernetes نستخدم kops. هذا نظام جيد جدًا ، فنحن مستخدمون مبكرون من الوقت الذي لم يكتبوا فيه بعد إلى المدونة. لا يدعم CoreOS بشكل كامل ، ويعمل بشكل جيد مع دبيان ، ويعرف كيفية تكوين العقد الرئيسية Kubernetes تلقائيًا ، ويعمل مع الوظائف الإضافية ، ولديه القدرة على عدم التوقف عن العمل أثناء تحديثات Kubernetes.
كل هذه الميزات خارج الصندوق ، والتي تعتبر إضافة كبيرة وجريئة. نظام عظيم!
من الروابط ، يمكنك العثور على العديد من الخيارات لإنشاء شبكة في Kubernetes. هناك بالفعل الكثير منها ، لكل شخص مزاياه وعيوبه. تدعم Kops جزءًا فقط من هذه الخيارات. يمكنك بالطبع تكوينها للعمل من خلال CNI ، ولكن من الأفضل استخدام الأكثر شيوعًا والمعياري. يتم اختبارها من قبل المجتمع ، وعلى الأرجح مستقرة.
قررنا استخدام كاليكو. عملت بشكل جيد من الصفر ، دون الكثير من المشاكل ، تستخدم BGP ، وتغليف أسرع ، وتدعم IP-in-IP ، وتسمح لك بالعمل مع السحب المتعددة ، وهذا بالنسبة لنا هو إضافة كبيرة.
التكامل الجيد مع Kubernetes ، باستخدام العلامات يحدد حركة المرور. لهذا زائد.
لم أكن أتوقع وصول كاليكو إلى الدولة عندما كانت تعمل ، وكل شيء يعمل بدون مشاكل.
توفر كبير ، كما قلت ، نقوم من خلال kops ، يمكنك استخدام 5-7-9 عقد ، نستخدم ثلاث. نحن نجلس على etcd v2 ، نظرًا لوجود خطأ لم يتم تحديثه على v3. من الناحية النظرية ، سيؤدي هذا إلى تسريع بعض العمليات. لا أعلم ، أشك في ذلك.
في لحظة صعبة ، لدينا مجموعة خاصة للتجربة مع النصوص البرمجية ، والتدوير التلقائي عبر CI. نعتقد أن لدينا حماية ضد الإجراءات الخاطئة تمامًا ، ولكن بالنسبة لبعض الإصدارات الخاصة والمعقدة ، فقط في حالة إجراء لقطات من جميع الأقراص ، فإننا لا نقوم بعمل نسخ احتياطية كل يوم.
التفويض سؤال أبدي. نحن في Kubernetes نستخدم الوصول القائم على الدور RBAC. إنه أفضل بكثير من ABAC ، وإذا قمت بتكوينه ، فأنت تفهم ما أعنيه. نظرة على تكوينات - فاجأ.
نستخدم Dex ، مزود OpenID الذي يضخ جميع المعلومات من بعض مصادر البيانات.
وللتسجيل الدخول إلى Kubernetes ، هناك طريقتان. من الضروري التسجيل بطريقة أو بأخرى في .kube / config إلى أين تذهب وما يمكن أن تفعله. فمن الضروري الحصول على هذا التكوين بطريقة أو بأخرى. أو يذهب المستخدم إلى واجهة المستخدم ، حيث يقوم بتسجيل الدخول ، ويتلقى التكوينات ، وينسخها إلى / config ويعمل. هذه ليست مريحة للغاية. انتقلنا تدريجيًا إلى حقيقة أن الشخص يدخل إلى وحدة التحكم ، وينقر على الزر ، ويسجل الدخول ، ويتم إنشاء التكوينات تلقائيًا منه ويتم تكديسها في المكان الصحيح. قررنا أن نعمل بهذه الطريقة أكثر راحة بكثير.
كمصدر بيانات ، نستخدم Active Directory. يسمح لك Kubernetes بدفع معلومات حول المجموعة من خلال هيكل التفويض بالكامل ، والذي يترجم إلى مساحة الاسم والأدوار. وبالتالي ، فإننا نميز على الفور بين المكان الذي يمكن أن يذهب إليه الشخص ، وحيث لا يحق له الذهاب ، وما يمكن أن يطلقه.
غالبًا ما يحتاج الأشخاص إلى الوصول إلى AWS. إذا لم يكن لديك Kubernetes ، فهناك جهاز يقوم بتشغيل التطبيق. يبدو أن كل ما تحتاجه هو الحصول على السجلات ، رؤيتها وهذا كل شيء. هذا مناسب عندما يمكن للشخص الذهاب إلى سيارته ومعرفة كيفية عمل التطبيق. من وجهة نظر Kubernetes ، يعمل كل شيء في حاويات. هناك أمر `kubectl exec` - ادخل إلى الحاوية في التطبيق وشاهد ما يحدث هناك. لذلك ، ليست هناك حاجة للذهاب إلى حالات AWS. لقد حرمنا من الوصول إلى الجميع باستثناء الأمر تحت الأرض.
علاوة على ذلك ، قمنا بمنع مفاتيح المشرف التي تعمل لفترة طويلة ، من خلال الأدوار. إذا كان من الممكن استخدام دور المسؤول - فأنا المسؤول. بالإضافة إلى أننا أضفنا دوران المفتاح. من الملائم تكوينه من خلال أمر awsudo ، هذا مشروع على github ، أوصي به بشدة ، فهو يسمح لك بالعمل كما هو الحال مع فريق sudo.
الحصص. شيء جيد جدًا في Kubernetes ، يعمل فور إخراجه من العلبة. يمكنك تحديد أي مساحة اسم ، على سبيل المثال ، بعدد الكائنات أو الذاكرة أو وحدة المعالجة المركزية التي يمكنك استهلاكها. أعتقد أن هذا مهم ومفيد للجميع. لم نصل بعد إلى الذاكرة ووحدة المعالجة المركزية ، نستخدم فقط عدد الكائنات ، لكننا سنضيف كل هذا.
يسمح لك الحجم الكبير والدهون بالقيام بالعديد من الأشياء الصعبة.
تحجيم. لا يمكنك خلط القياس داخل Kubernetes وخارج Kubernetes. داخل Kubernetes يفعل التحجيم نفسه. يمكن أن يزيد القرون تلقائيًا عند وجود حمولة كبيرة.
أنا أتحدث هنا عن قياس حالات Kubernetes نفسها. يمكن القيام بذلك باستخدام AWS Autoscaler ، هذا مشروع جيثب. عندما تضيف بودًا جديدًا ولا يمكن أن تبدأ لأنه يفتقر إلى الموارد في جميع الحالات ، يمكن لـ AWS Autoscaler إضافة العقد تلقائيًا. يسمح لك بالعمل في حالات Spot ، ولم نقم بإضافتها بعد ، ولكننا سنسمح لنا بتوفير الكثير.
عندما يكون لديك الكثير من المستخدمين وتطبيقات المستخدمين ، فأنت بحاجة إلى مراقبتها بطريقة أو بأخرى. عادة ما يكون هذا هو القياس عن بعد والسجلات وبعض الرسومات الجميلة.
لأسباب تاريخية ، كان لدينا Sensu ، لم يكن مناسبًا جدًا لـ Kubernetes. هناك حاجة إلى مشروع أكثر توجهاً نحو القياس. نظرنا إلى مكدس TICK بأكمله ، وخاصة InfluxDB. واجهة مستخدم جيدة ، لغة شبيهة بـ SQL ، ولكن ليس ميزات كافية. لقد تحولنا إلى بروميثيوس.
إنه جيد. لغة استعلام جيدة ، تنبيهات جيدة ، وكل شيء خارج الصندوق.
لإرسال القياس عن بعد ، استخدمنا سيرنان. هذا هو مشروعنا المكتوب بلغة Rust. هذا هو المشروع الوحيد عن الصدأ الذي يعمل في إنتاجنا لمدة عام الآن. لديها العديد من المفاهيم: هناك مفهوم مصدر البيانات ، يمكنك تكوين عدة مصادر. يمكنك تكوين مكان دمج البيانات. لدينا تكوين الفلاتر ، أي أنه يمكن معالجة البيانات المتدفقة بطريقة ما. يمكنك تحويل السجلات إلى المقاييس ، المقاييس إلى السجلات ، أي شيء تريده.
على الرغم من حقيقة أن لديك العديد من المدخلات ، والعديد من الاستنتاجات ، وتوضح أنه حيثما يذهب ، هناك شيء مثل نظام الرسم البياني الكبير ، فإنه يتضح بشكل ملائم.
نحن الآن ننتقل بسلاسة من المكدس الحالي Statsd / Cernan / Wavefront إلى Kubernetes. من الناحية النظرية ، يريد Prometheus أخذ البيانات من التطبيقات بمفرده ، لذلك تحتاج إلى إضافة نقطة نهاية إلى جميع التطبيقات ، والتي ستأخذ منها المقاييس. سيرنان هو رابط الإرسال ، يجب أن يعمل في كل مكان. هناك احتمالان: يمكنك تشغيل Kubernetes في كل حالة ، باستخدام مفهوم Sidecar ، عندما تعمل حاوية أخرى في حقل البيانات الذي يرسل البيانات. نفعل هذا وذاك.
في الوقت الحالي ، يتم إرسال جميع السجلات إلى stdout / stderr. تم تصميم جميع التطبيقات لهذا ، لذا فإن أحد المتطلبات الحاسمة هو أننا لا نترك هذا النظام. يرسل Cernan البيانات إلى ElasticSearch ، ويتم إرسال أحداث نظام Kubernetes بالكامل باستخدام Heapster. هذا نظام جيد للغاية ، أوصي.
بعد ذلك ، يمكنك رؤية جميع السجلات في مكان واحد ، على سبيل المثال ، في وحدة التحكم. نستخدم كيبانا. هناك منتج Stern رائع ، فقط للسجلات. يسمح لك بالمشاهدة ، ويرسم جرابًا مختلفًا بألوان مختلفة ، ويعرف كيف يرى متى مات أحدهم وأعيد تشغيل الآخر. يلتقط جميع السجلات تلقائيًا. مشروع مثالي ، أوصي به بشدة ، إنه سمين بالإضافة إلى Kubernetes ، كل شيء على ما يرام هنا.
أسرار نستخدم S3 و KMS. نحن نفكر في التحول إلى Vault أو الأسرار في Kubernetes نفسها. كانت 1.7 في حالة ألفا ، ولكن هناك شيء يجب القيام به مع هذا.
وصلنا إلى الجزء المثير للاهتمام. بشكل عام ، لا يعتبر تطوير Kubernetes كثيرًا. : «Kubernetes — , , , ».
, Kubernetes — .
, , , - . Kubernetes : , , . , , — .
, , . -, Docker Way. , . , , SSH, : « - , ».
, Kubernetes , read only . , , , , , , , . Kubernetes , , , , -, .
: , - , , - , pipeline , : «, », . - , , , . , CI , - , CI . .
, , , , . , - . , . - Kubernetes. , , — , .
.
Kubernetes, , , - . , , Deis, . , , , Deis. , Deis .
, Helm Charts. , — . - How-to, - FAQ, , , , , . , . , , .
Minikube — , , , , , . Kubernetes , , SSH .
MacOS, Mac, , , . . virtualbox, xhyve. , , . xhyve, VirtualBox, , .
, , , - , . , , - , .
CI Kubernetes, , , Kubernetes, , . Concourse CI, , , , , , . Concourse . , . , , , - , .
CI, , , , Concourse. Drone.io — , , , , . , — , . , , .
pipeline -, Kubernetes. , , , CI, -, Kubernetes .
admin/stage-, - . .
Drone-. , pipeline, - : , . , Drone, , .
, : . , , - , Kubernetes. Google , , , - .
Google , Kubernetes. , , . , , . , . Service Mesh.
, , , Geodesic. , , . , . , , , .
, Kubernetes .
, . , , , . Kubernetes. , , .
.
, , — , , . : , , . — Kubernetes .
Kubernetes . , Kubernetes, . , , .
Kubernetes — . , Kubernetes . — .
, , .
Kubernetes, — . , , , .
, Minikube, , , . , , , Kubernetes . — , .
— . , , , , 1-2 , , , . Kubernetes .
-, Kubernetes , , . CI, CI , , , . .
— . , , , . Kubernetes , .
, , . , , , . , , .
, , Kubernetes , . . , .
. Kubernetes . -. , Kubernetes, , ( — , ) , .
, , pod, . , . , , , . , , Kubernetes, , .
Error Budget. : , . , , - . , , . — , . — . SLA «» — , , , . , , , , .
, . « », . , , . .
:
@gliush .
, :
- Container-Native Networking — Comparison
- Continuous Delivery by Jez Humble, David Farley.
- Containers are not VMs
- Docker Distribution (image registry)
- Quay — Image Registry as a Service
- etcd-operator — Manager of etcd cluster atop Kubernetes
- Dex - OpenID Connect Identity (OIDC) and OAuth 2.0 Provider with Pluggable Connectors
- awsudo - sudo-like utility to manage AWS credentials
- Autoscaling-related components for Kubernetes
- Simon's cat
- Helm: Kubernetes package manager
- Geodesic: framework to create your own cloud platform
- Calico: Configuring IP-in-IP
- Sensu: Open-core monitoring system
- InfluxDB: Scalable datastore for metrics, events, and real-time analytics
- Cernan: Telemetry and logging aggregation server
- Prometheus: Open Source monitoring solution
- Heapster: Compute Resource Usage Analysis and Monitoring of Container Clusters
- Stern: Multi pod and container log tailing for Kubernetes
- Minikube: tool to run Kubernetes locally
- Docker machine driver fox xhyve native OS X Hypervisor
- Drone: Continuous Delivery platform built on Docker, written in Go
- Borg, Omega and Kubernetes
- Container-Native Networking — Comparison
- Bug in minikube when working with xhyve driver.
دقيقة من الدعاية. إذا أعجبك هذا التقرير من مؤتمر DevOops - لاحظ أنه في 14 أكتوبر سيعقد DevOops 2018 الجديد في سان بطرسبرغ ، سيكون هناك الكثير من الأشياء المثيرة للاهتمام في برنامجها. يحتوي الموقع بالفعل على أول المتحدثين والتقارير.