‫دعنا نتحدث عن سبب احتياجك إلى Kubernetes.
‫الآن كمراجعة ، تحقق مرة أخرى
‫مع الأقسام السابقة. القسم الأول لـ Swarm وهناك محاضرة
‫بعنوان Swarm Mode المدمج في Orchestration.
‫يمنحك هذا بعض الأساسيات حول المشكلات
‫التي يحلها التنسيق ولماذا قد تحتاج
‫إليها. سأشدد على أنه في البداية
‫، من المهم بالتأكيد أن تفهم
‫فوائد التنسيق التي ستحتاجها لنشر تطبيقاتك
‫، وما إذا كنت تحتاج حتى إلى التنسيق
‫أم لا.
‫تزداد شعبية التنسيق بالتأكيد ، لكنها ليست
‫الطريقة الوحيدة لتشغيل الحاويات.
‫لقد تحدثنا عن استخدام تشغيل Docker هنا.
‫لقد تحدثنا عن Docker Compose.
‫لقد تحدثنا عن عروض وخدمات النظام الأساسي الأخرى.
‫لدي عملاء لا يزالون يشغلون
‫الحاويات على عقد فردية في AWS بدون
‫تنسيق. يستخدمون ميزات هذا
‫النظام الأساسي لإنشاء تجريد مشابه مثل التنسيق ، حيث ربما
‫يستخدمون مجموعات القياس التلقائي ، وموازنة الحمل المرنة
‫، والكثير من الأشياء الأخرى التي استخدمناها
‫جميعًا لأكثر من عقد من الزمان لإدارة عمليات نشر التطبيقات الخاصة بنا.
‫لديهم مثل هذا النظام المحسن لدرجة أنهم لا
‫يرون الكثير من الفوائد من تغيير كل ذلك تمامًا
‫إلى تنسيق.
‫الآن ، سيستخدم معظمنا في النهاية شكلاً
‫من أشكال تنسيق الحاويات لأن هذه هي الطريقة التي
‫أعتقد أن الصناعة تسير بها حقًا ، وستكون هذه
‫جميعًا طبقات إضافية تعمل أعلى Docker ، أو
‫وقت تشغيل آخر ، وهو ما تعلمت خلال هذه الدورة.
‫إحدى الصيغ البسيطة التي أستخدمها
‫لاستخدام التزامن أم
‫لا ، هي أخذ عدد الخوادم التي
‫سأحتاجها لبيئة معينة ، ثم معدل تغيير
‫تطبيقاتي ، أو البيئة نفسها ، ومضاعفة
‫هذان الاثنان يساويان حقًا الاستفادة
‫من التنسيق.
‫ما أعنيه بذلك هو أن التناغم مصمم لأتمتة التغيير
‫ومراقبة حالة الأشياء
‫والتأكد من أن كل شيء هو الحالة التي تتوقعها.
‫على سبيل المثال ، التطبيقات التي تعمل في حالة صحية.
‫عندما تبدأ ، قد تحتاج فقط إلى
‫خادم واحد ، أو بضعة خوادم فقط ، وإذا
‫كنت لا تغير تطبيقاتك كثيرًا ، فلنفترض أنك
‫تقوم بتغييرها مرة واحدة فقط في الشهر أو أقل ، ثم
‫التنسيق ، وقد يكون الجهد المبذول في نشرها
‫وإدارتها وتأمينها غير ضروري في
‫ولايتك. خاصة إذا كنت مطورًا منفردًا
‫أو مجرد فريق صغير جدًا.
‫هذا هو المكان الذي تبدأ فيه أشياء مثل Elastic
‫Beanstalk ، أو Heroku ، منصة نشر التطبيقات ،
‫حيث يبدأ الكثير من هؤلاء في التألق كبدائل للقيام
‫بالمزامنة الخاصة بك.
‫بالطبع ، السؤال الأكثر شيوعًا الذي
‫يطرحه علي الناس بمجرد أن يكتشفوا أنهم بحاجة
‫إلى تنسيق ، هو أن يقرروا أيهم يريدون.
‫حقًا في هذه المرحلة من عام 2019
‫، هناك ما لا يقل عن منصتين أو ثلاث منصات رئيسية.
‫إذا قمت بتضمين حلول السحابة ، فقد يكون هناك أربعة أو
‫خمسة منصات رئيسية هناك.
‫تلك التي أتحدث عنها في هذه الدورة هي أفضل اثنين
‫يعملان في كل مكان. هذا هو Swarm و Kubernetes.
‫ثم لديك عروض أخرى خاصة بالمنصات السحابية
‫، مثل ECS ، المتوفرة فقط على
‫AWS ، والمزيد من العروض التقليدية التي كانت موجودة
‫منذ فترة أطول قليلاً مثل Cloud Foundry
‫، أو Mesos و Marathon.
‫لكنني أعتقد أنه إذا كنت شخصًا مهتمًا بتشغيل
‫الحاويات في مكان ما ، وفي السحابة ، أو من المحتمل أن
‫تكون متعددة الأوساط السحابية ، فقد لا ترغب في استخدام
‫هذه العروض الخاصة بالسحابة مثل ECS لأن تلك
‫كانت موجودة قبل Kubernetes.
‫لذلك ، كان هذا نوعًا من الحلول القديمة التي لا تزال
‫Amazon تدعمها ولا تزال خيارًا أنيقًا ، ولكن فقط إذا كنت
‫محددًا لـ AWS وهذا هو المكان الوحيد الذي تخطط لنشر
‫الحاويات فيه.
‫بالنسبة لكثير من عملائي ، وبالنسبة للكثير من
‫طلابي ، تكون الخيارات عادة ، أحتاج إلى شيء هجين.
‫مما يعني أنه يمكنني تشغيله في مركز البيانات الخاص بي
‫أو في متعدد الأوساط السحابية. لا يمكن تشغيله في
‫مكان واحد فقط. يعود ذلك عادةً إلى
‫Swarm أو Kubernetes كخيارات كبيرة
‫لأن هذين الحلين هما أشهر منسقي الحاويات.
‫يتم تشغيلها على كل سحابة ، وفي مراكز البيانات ، وحتى البيئات
‫الصغيرة مثل إنترنت الأشياء.
‫إذا قررت على Kubernetes كمنسق لك
‫، فإن القرار الكبير التالي هو التوزيع
‫الذي ستستخدمه.
‫الجزء الأول من ذلك هو معرفة ما إذا كنت تريد
‫حلاً مُدارًا على السحابة ، أو إذا
‫كنت ترغب في طرح الحل الخاص بك مع منتج البائع الذي
‫ستقوم بتثبيته على الخوادم بنفسك.
‫التوزيعات الشائعة التي يدعمها البائعون والتي سمعتني
‫أتحدث عنها ، بما في ذلك Docker Enterprise وهناك
‫توزيعات أخرى مثل Rancher OpenShift من Red
‫Hat. Canonical ، شركة Ubuntu ،
‫لديها نسختها الخاصة.
‫يحتوي برنامج VMware على نسخته الخاصة.
‫PKS كذلك.
‫في الواقع ، هناك العديد من حلول بائعي شركات
‫البرمجيات والبنية التحتية لـ Kubernetes الآن
‫لدرجة أنها مربكة بعض الشيء.
‫سأعطيك رابطًا في الموارد لقائمة توزيعات
‫Kubernetes المعتمدة.
‫تريد استخدام أحدها لأنها تضمن استخدام واجهة
‫برمجة التطبيقات من Kubernetes مباشرةً ، ودعمها
‫بالكامل.
‫لذا فإن الحالة المثالية هي أنه يمكنك أخذ أعباء
‫العمل وملفات YAML التي تصمم البنية التحتية الخاصة
‫بك ، ويمكنك نقلها من بائع Kubernetes
‫إلى آخر ويجب أن تعمل خارج الصندوق لمعظم
‫الأشياء.
‫الآن هناك خيار آخر سأذكره هنا وهو
‫استخدام إصدار GitHub الأولي من Kubernetes.
‫هذا هو ما تقوم عليه جميع التوزيعات.
‫على سبيل المثال ، إذا نظرت في أعلى التيار ورأيت
‫Kubernetes 1. 14 الافراج.
‫بعد ذلك ، عندما تنظر إلى أحد منتجات البائعين
‫، فستكون مهتمًا بإصدارات Kubernetes التي يدعمونها.
‫عادةً ما تكون منتجات البائعين متخلفة عن بعض الإصدارات ، ولكن
‫في الوقت الحاضر ، يتمثل السباق في أنها جميعًا
‫تظل محدثة قدر الإمكان.
‫لذلك ، أميل إلى رؤيتهم نسخة واحدة فقط قديمة في معظم
‫الأوقات.
‫الآن ، الشيء الذي تحصل عليه من حلول
‫البائعين ، إلى جانب خيارات دعم البائع فقط
‫، هو أيضًا تجميع أدوات أخرى معها.
‫من بين الأشياء التي تختلف قليلاً
‫عن Swarm عن Kubernetes أنها تحتاج إلى الكثير
‫من الأشياء المضافة إليها لتسهيل استخدامها خارج
‫الصندوق. لذلك ، من المحتمل ،
‫عندما تحصل على حل البائع ، سترى أشياء مثل حلول المصادقة
‫المخصصة ، وإدارة الويب المخصصة ، والشبكات المخصصة ، على
‫سبيل المثال لا الحصر.
‫سأوصي بشكل عام ، دون معرفة أي من متطلباتك
‫، بأنك ربما لا تحتاج إلى الإصدار
‫المنبع النقي من GitHub's Kubernetes.
‫لا تحتاج إلى استنساخ الريبو الخاص بـ Kubernetes
‫وتشغيله فقط.
‫الآن ، إنه أمر رائع للتعلم.
‫في الواقع ، أوصي بالبدء بذلك كطريقة لتعلم
‫Kubernetes. ولكن بمجرد أن تدخل في حلول
‫البائعين ، ستختلف جميعها قليلاً فيما
‫يتعلق بالأمان والشبكات وأشياء أخرى.
‫لذلك ، سيكون من الصعب عليك أن تتعلم أحدهما ثم
‫تفترض أن الآخر يتصرف بنفس الطريقة.
‫ومع ذلك ، عندما تبدأ في الحديث عن الإنتاج
‫، أتوقع أنك ستحاول استخدام أحد
‫حلول البائعين هذه أولاً لأن إدارتها ستكون
‫أسهل. سيكون لديك خيارات دعم أفضل.
‫بشكل عام ، ستعمل الأشياء بشكل أفضل وأسرع خارج الصندوق.