بمجرد أن كتبت هنا بالفعل عن الانتقال من آسيا إلى أوروبا ، والآن أريد أن أكتب ما أفعله في هذه أوروبا. هناك مثل هذه المهنة - DevOps ، أو بالأحرى لا ، ولكن حدث أن هذا بالضبط ما أفعله الآن. الآن من أجل تنسيق كل شيء يجري في عامل الميناء ، نستخدم مربيًا ، والذي كتبت عنه أيضًا. ولكن بعد ذلك حدث شيء فظيع ، خرج رانشر 2.0 وانتقل إلى kubernetes (فيما يلي ببساطة k8s) وبما أن k8s هو الآن المعيار الحقيقي لإدارة المجموعة ، فقد كانت هناك رغبة في بناء البنية التحتية بالكامل مرة أخرى مع لعبة ورق ومكتبي مكتبات. ما يضيف الذوق هو أن الشركة توظف باستمرار متخصصين مختلفين من بلدان مختلفة ومع تقاليد مختلفة ، ويجلب شخص ما puppet ، شخص ما ansible من غير ansible ، ويعتقد شخص ما بشكل عام أن Makefile + bash هو كل شيء لدينا. لذلك ، ليس هناك ببساطة رأي لا لبس فيه حول كيفية عمل كل شيء ، لكني أريد ذلك حقًا.
تم تجميع حديقة الحيوانات للتقنيات والأدوات سابقًا:
إدارة البنية التحتية
- Minikube
- Rke
- Terraform
- Kops
- كوبيسبراي
- Ansible
إدارة التطبيقات
- Kubernetes
- رانشر
- Kubectl
- هيلم
- Confd
- كومبوس
- جنكينز
التسجيل والمراقبة
- بحث
- كيبانا
- بت بطلاقة
- تلغراف
- تدفق
- زبكس
- بروميثيوس
- جرافانا
- كاباسيتور
بعد ذلك ، سأحاول أن أصف بإيجاز كل نقطة من حديقة الحيوانات هذه ، وأشرح لماذا تكون ضرورية ولماذا تم اختيار هذا الحل. في الواقع ، يمكن استبدال أي عنصر تقريبًا بعشرات من نظائرها وما زلنا غير متأكدين تمامًا من الاختيار ، لذلك إذا كان لدى أي شخص رأي أو توصيات ، فسأقرأه في التعليقات بسرور.
ستكون Kubernetes مركز كل شيء لأنه الآن هو بالفعل حل لا يحتوي ببساطة على بدائل ، وهو مدعوم من قبل جميع المزودين من Amazon و Microsoft إلى mail.ru. كيف تم النظر في البدائل
Swarm - التي لم تقلع أبداًNomad - الذي يبدو أنه كتب من قبل الغرباء للحيوانات المفترسةCattle هي المحرك من الحارس 1.x ، الذي نعيش عليه الآن ، من حيث المبدأ ، كل شيء على ما يرام ، لكن المزارع قد تخلى عنه بالفعل لصالح k8s لذلك لن يكون هناك تطور.
بناء البنية التحتية
أولاً ، نحتاج إلى إنشاء البنية التحتية ، ونشر مجموعة k8s عليها. هناك العديد من الخيارات ، جميعها تعمل وبالتالي يصعب اختيار الأفضل.
Minikube هو خيار رائع لبدء كتلة على جهاز المطور ، لأغراض الاختبار.
Rke - محرك Rancher kubernetes ، بسيط مثل الباب ؛ الحد الأدنى من التكوين لإنشاء مظهر الكتلة
nodes: - address: localhost role: [controlplane,worker,etcd]
وهذا كل شيء ، هذا يكفي لبدء المجموعة على الجهاز المحلي ، بينما يسمح لك بإنشاء مجموعات HA جاهزة للإنتاج ، وتغيير التكوين ، وترقية الكتلة ، وتفريغ قاعدة بيانات etcd وأكثر من ذلك بكثير.
Kops - لا يسمح لك فقط بإنشاء مجموعة ، ولكن أيضًا إنشاء مثيلات مسبقًا في aws أو gce. كما يسمح لك بإنشاء تكوين لـ terraform. أداة مثيرة للاهتمام ، لكننا لم نتجذر بعد. يتم استبداله بالكامل بـ terraform + rke بينما يكون أبسط وأكثر مرونة.
Kubespray - في الواقع ، إنه مجرد دور غير مرئي يخلق مجموعة k8s ، قوية للغاية ومرنة وقابلة للتكوين. هذا هو الحل الافتراضي لنشر k8s.
Terraform هي أداة لبناء البنية التحتية في aws أو azure أو مجموعة من الأماكن الأخرى. مرنة ومستقرة - أوصي.
Ansible لا يتعلق حقًا بـ k8s ، لكننا نستخدمه في كل مكان وهنا أيضًا: تعديل الإعدادات ، تثبيت / تحديث البرنامج ، وتوزيع الشهادات. رخيص ومبهج.
إدارة التطبيقات
لذا ، لدينا مجموعة ، الآن نحن بحاجة إلى بدء شيء مفيد عليها ، كل ما تبقى هو السؤال عن كيفية القيام بذلك.
الخيار الأول: استخدام k8s العارية جميعها التي تم نشرها باستخدام kubectl . من حيث المبدأ ، هذا الخيار له الحق في الحياة. Kubectl هي أداة قوية بما يكفي تسمح لنا بالقيام بكل ما نحتاجه ، بما في ذلك النشر والترقية ومراقبة الحالة الحالية وتغيير التكوين بسرعة وعرض السجلات والاتصال بحاويات محددة. لكن في بعض الأحيان أريد أن يكون كل شيء أكثر راحة ، لذلك ننتقل.
في الواقع ، أصبح المزارع الآن كمامة على الويب لإدارة k8s وفي نفس الوقت الكثير من الكعك الصغير الذي يضيف الراحة. هنا يمكنك عرض السجلات والوصول إلى وحدة التحكم وتكوين وترقية التطبيقات والتحكم في الوصول المستند إلى الأدوار وخادم بيانات التعريف المدمج ، والتنبيهات ، وإعادة توجيه السجل ، وإدارة الأسرار والمزيد. لقد تم استخدام الإصدار الأول من rancher منذ عدة سنوات ونحن راضون تمامًا عنه ، على الرغم من أننا يجب أن نعترف أنه عند التبديل إلى k8s ، يطرح السؤال ما إذا كنا بحاجة إليه حقًا. من الجيد أنه يمكنك استيراد أي مجموعة تم إنشاؤها مسبقًا في المزرعة ، ومن أي مزود ، أي يمكنك استيراد مجموعة من EKS من Azure وإنشاءها محليًا ونقلها من مكان واحد إلى خادم واحد. علاوة على ذلك ، إذا شعرت بالملل فجأة ، يمكنك ببساطة هدم الخادم والاستمرار في استخدام الكتلة مباشرة من خلال kubeclt أو أي أداة أخرى.
إن المفهوم الصحيح للغاية لكل شيء ككود شائع الآن. على سبيل المثال ، يتم تنفيذ البنية التحتية terraform باستخدام terraform ، والتجميع terraform يتم تنفيذه من خلال jenkins pipeline . الآن جاء دور التطبيق. يجب أيضًا وصف تثبيت وتكوين التطبيق في بعض البيان وحفظه في git. تستخدم إصدارات Rancher 1.x معيار docker-compose.yml وكان كل شيء على ما يرام ، ولكن عندما انتقلوا إلى k8s ، تحولوا إلى helm charts . Helm ، من وجهة نظري ، مشاركة رهيبة للغاية مع منطق وهندسة غريبة. هذا هو واحد من تلك المشاريع التي يبقى الشعور أنه كتب من قبل الحيوانات المفترسة للغرباء أو العكس. المشكلة الوحيدة هي أنه في عالم k8s helm لا توجد بدائل ببساطة وهذا هو المعيار الفعلي. لذلك ، سوف يتم وخزنا في البكاء ، لكننا نواصل استخدام الدفة. في الإصدار 3.x ، يعد المطورون بإعادة كتابته من الصفر ، وإخراج كل الشذوذ منه وتبسيط البنية. عندها سنشفى ، لكن الآن سنأكل ما هو.
نحتاج أيضًا على الأقل إلى ذكر jenkins هنا ، ولا يتعلق مباشرة بموضوع kubernetis ، ولكن بمساعدتها يتم نشر التطبيقات في المجموعة. إنه يعمل ، وهو موضوع لمقال منفصل.
المراقبة
الآن لدينا مجموعة بل إنها تدور نوعًا ما من التطبيق ، يبدو أنه يمكنك الزفير ، ولكن في الواقع ، كل شيء قد بدأ للتو. ما مدى استقرار تطبيقنا؟ مدى السرعة هل لديه ما يكفي من الموارد؟ ما الذي يحدث بشكل عام في المجموعة؟
نعم ، الموضوع التالي هو المراقبة وتسجيل الدخول. هناك ثلاث إجابات محددة فقط. تخزين السجلات في kibana ، مشاهدتها من خلال kibana رسم الرسومات في grafana . لجميع الأسئلة الأخرى ، هناك عشرات الإجابات الصحيحة.
هنا نبدأ مع grafana من تلقاء نفسها ، فهي لا تفعل شيئًا عمليًا ، ولكن يمكن تثبيتها كوجه جميل لأي من الأنظمة الموضحة أدناه والحصول على رسومات جميلة وأحيانًا واضحة ، بالإضافة إلى ذلك ، يمكنك إعداد المنبهات على الفور ، ولكن من الأفضل استخدام حلول أخرى لهذا ، على سبيل المثال prometheus alertmanager و ElastAlert .
من وجهة نظري ، في الوقت الحالي هذا هو أفضل مجمّع وموجه للسجلات ، بالإضافة إلى ذلك ، خارج الصندوق ، لديه دعم k8s. هناك أيضًا Fluentd ولكنه مكتوب بالروبل ويسحب الكثير من التعليمات البرمجية القديمة ، مما يجعله أقل جاذبية. لذلك إذا كنت بحاجة إلى وحدة نمطية محددة من فلنتد التي لم يتم نقلها بعد إلى فلنت بت ، استخدمها ، في بقية الباقي - بت هو الخيار الأفضل. إنه أسرع وأكثر استقرارًا ويستهلك ذاكرة أقل. يسمح لك بجمع السجلات من كل أو من حاويات محددة ، وتصفيتها ، وإثرائها عن طريق إضافة بيانات خاصة بـ kubernetis وإرسالها كلها إلى elasticsearch أو إلى العديد من المستودعات الأخرى. إذا قارنته بـ logstash + docker-bit + file-bit التقليدية logstash + docker-bit + file-bit هذا الحل هو بالتأكيد أفضل من جميع النواحي. تاريخيا ، ما زلنا نستخدم logspout + logstash ولكن بطلاقة بطلاقة يفوز بالتأكيد.
نظام مراقبة مكتوب خصيصًا لهندسة الخدمات الصغيرة. علاوة على ذلك ، هناك معيار فعلي في الصناعة ، هناك أيضًا مشروع يسمى Prometheus Operator ، كتب خصيصًا لـ k8s. يقرر الجميع ما يختارونه ، ولكن من الأفضل أن تبدأ بروميثيوس العارية ، فقط من أجل فهم منطق عمله ، فهو مختلف تمامًا عن الأنظمة المعتادة. نحتاج أيضًا إلى ذكر node-exporter الذي يسمح لك بجمع المقاييس على مستوى الماكينة والمصدر-بروميثيوس-رانشي الذي يسمح لك بجمع المقاييس من خلال api rancher. بشكل عام ، إذا كان لديك كتلة على kubernetes ، فيجب أن يكون بروميثيوس.
يمكن للمرء أن يتوقف هنا ، لكن تاريخياً ، لدينا العديد من أنظمة المراقبة. أولاً ، من الملائم جدًا لـ zabbix رؤية جميع مشاكل البنية التحتية بأكملها على لوحة واحدة. يتيح لك وجود الاكتشاف التلقائي العثور على شبكات وعقد وخدمات جديدة وإضافتها بسرعة وبشكل عام إلى أي شيء تقريبًا للمراقبة ، مما يجعله أكثر من مجرد أداة مناسبة لمراقبة البنى التحتية الديناميكية. بالإضافة إلى ذلك ، في الإصدار 4.0 ، تمت إضافة مجموعة من المقاييس من مصدري بروميثيوس إلى zabbix وتبين أن كل هذا يمكن دمجه بشكل جميل للغاية في نظام واحد. على الرغم من عدم وجود إجابة محددة حتى الآن عما إذا كان من الضروري سحب zabbix إلى مجموعة k8s ، إلا أنه من المثير للاهتمام بالتأكيد أن تجرب.
كبديل ، يمكنك استخدام TIG (telegraf + influxdb + grafana) السهل تكوينه ، وهو يعمل بثبات ، ويسمح لك بتجميع المقاييس حسب الحاوية ، والتطبيق ، والعقدة ، وما إلى ذلك ، ولكن يكرر بشكل أساسي وظيفة بروميثيوس ، ويجب أن يبقى واحد فقط.
وهكذا اتضح أنه قبل أن تبدأ أي شيء مفيد ، تحتاج إلى تثبيت وتكوين الربط من بضع عشرات من الخدمات والأدوات المساعدة. في الوقت نفسه ، لم تثر المقالة قضايا إدارة البيانات الثابتة والأسرار وأشياء غريبة أخرى ، يمكن سحب كل منها إلى منشور منفصل.
وكيف ترى البنية التحتية المثالية؟
إذا كان لديك رأي ، يرجى الكتابة في التعليقات ، أو ربما الانضمام إلى فريقنا والمساعدة في تجميعها معًا.