‫بعض الأوامر التي كنت تستخدمها ، حتى الآن
‫، لديها القليل من الأتمتة وراءها المعروفة
‫باسم المولدات. المولدات التي يمكنك التفكير فيها مثل القوالب.
‫يقومون بشكل أساسي بإنشاء المواصفات ، أو المواصفات
‫، لتطبيقها على مجموعة Kubernetes بناءً على خيارات
‫سطر الأوامر.
‫تفكر في أوامر مثل التشغيل والكشف
‫والإنشاء. غالبًا ما يكون لديهم مولدات
‫خلفهم توفر القالب اللازم مع جميع
‫الحقول والافتراضيات التي لا تحددها بالضرورة
‫في سطر الأوامر.
‫الهدف الأساسي من هذه المولدات هو
‫تسهيل استخدام أوامر من سطر واحد ، كما اعتدت على Docker
‫و Docker Compose و Swarm.
‫لاستخدام هذه الأوامر المكونة من سطر واحد في Kubernetes مع
‫ترك بعض الإعدادات الأكثر تقدمًا حتى الإعدادات الافتراضية.
‫حقًا ، يقوم Swarm بهذا أيضًا.
‫لدى Swarm الكثير من الإعدادات الافتراضية عندما تقوم بإنشاء
‫خدمات ومجموعات تحدث جميعها في الخلفية.
‫أنت فقط لا تعرف ذلك. هذه المولدات من هذا القبيل.
‫فيما يلي مثال حيث نقوم بإنشاء نشر باستخدام
‫أمر الإنشاء ، ونمنحه خيارين لتلبية
‫الحد الأدنى من المتطلبات.
‫سيملأ باقي المواصفات
‫بمولد.
‫تختلف هذه المولدات باختلاف نوع الأشياء
‫التي تقوم بإنشائها. سواء كانت خدمة ، أو نشر ،
‫أو وظيفة ، أو وظيفة كرون.
‫أشياء أخرى سنتحدث عنها لاحقًا.
‫يمكن أن تتغير هذه المولدات بمرور
‫الوقت مع ظهور كل إصدار من Kubernetes.
‫قد يقومون بتغيير واحدة أو اثنتين من خصائص
‫تلك المواصفات.
‫لذلك ، هذه لها إصدارات.
‫في بعض الأحيان ، إذا رأيت في الوثائق ، فقد ترى بعض
‫YAML لـ Kubernetes ، وهي تقول شيئًا عن الإصدار التجريبي.
‫هذا غالبًا عندما يتم إنشاء المولد لأول مرة ، قد يكون
‫له إصدار تجريبي وبعد ذلك عندما يتخرج إلى
‫مولد ناضج ، سيكون لديه V1.
‫لا يمكننا حقًا الحصول على قائمة بالمولدات في
‫سطر الأوامر لأنها تمتد عبر أوامر مختلفة وخيارات
‫مختلفة قد تستخدمها المولدات.
‫أسهل طريقة هنا عبر كل هذه الأوامر المختلفة
‫لمعرفة ما سيتم إنشاؤه إذا قمت بكتابة هذا
‫الأمر مقابل مجموعة ، هي استخدام خيارين.
‫التشغيل الجاف ، وهي طريقة رائعة حقًا
‫لإظهار ناتج ما كتبته ، وسنرى
‫ذلك في ثانية. ثم -o ، مما يعني
‫الإخراج. نقول إننا نريد مخرجات في YAML.
‫نحن نقول أساسًا تشغيل هذا الأمر ولكن لا تفعل
‫ذلك تقنيًا على الكتلة.
‫فقط جربها لترى ماذا سيحدث إذا فعلت ذلك.
‫ثم في نفس الوقت ، أرني ناتج YAML لما سيتم
‫إنشاؤه إذا أنهيت هذا الأمر.
‫ستحصل على قوالب صغيرة لطيفة بشكل أساسي.
‫يمكنك حتى استخدام ذلك لبدء إنشاء YAML الخاص بك والذي سنستخدمه
‫في المحاضرات اللاحقة.
‫أخيرًا ، المولدات هنا.
‫قد تعتبرهم أيضًا افتراضات معبرة عن آرائهم.
‫هم حقا ليسوا آرائهم.
‫إنها صغيرة جدًا.
‫عادة ما تكون من 10 إلى 15 سطرًا من YAML.
‫مجرد الحد الأدنى لبدء شيء ما.
‫ومع ذلك ، لديهم آراء ، ولهذا السبب لديهم
‫إصدارات. قد ترى نسخة تجريبية
‫تخرج وما إلى ذلك. أنا أعتبرهم عاقدين لكنهم
‫بخير ، صحيح. سيعملون في معظم حالات الاستخدام
‫عندما تقوم فقط بتجربة الأشياء من أجل التطوير والاختبار.
‫دعنا نذهب من خلال بعض الأمثلة لرؤية هذه المولدات
‫في سطر الأوامر.
‫أول واحد هنا هو نشر كما استخدمناه من قبل.
‫إنشاء النشر.
‫ستلاحظ أنني وضعت -Dry-run في النهاية.
‫إذا قمت فقط بالتشغيل الجاف ، فلن يقوم إلا
‫بإخراج نوع المورد الذي سينشئه.
‫هذا مشابه لاسم المورد الذي نراه عندما
‫نقوم بإدراجه بأمر kubectl get.
‫إذا قمت بضرب السهم لأعلى هناك واكتب -o yaml
‫في النهاية ، فسوف يظهر لي
‫إخراج YAML الذي تم إنشاؤه بهذا الأمر.
‫سنستعرض مواصفات
‫YAML لاحقًا. في الوقت الحالي ، يمكنك رؤية
‫الأجزاء الرئيسية لما تم القيام به في الخلفية عندما قمنا
‫بإنشاء أمر النشر.
‫أولاً ، يعرض إصدار API ، إصدار هذا النوع
‫من الموارد.
‫لذلك ، نحن نستخدم إصدار تطبيقات
‫/ v1 هنا. النوع هو النشر ، وذلك
‫لأننا ننشئ عملية نشر.
‫إذا كانت وظيفة ، فقد كانت وظيفة.
‫إذا كانت خدمة ، فستقول الخدمة.
‫هذا النوع من الأشياء. ستكون البيانات الوصفية
‫موجودة دائمًا لأي مورد تقوم بإنشائه.
‫سيحتوي على الطابع الزمني ، وهو اختياري ، لأنه
‫سينشئ ذلك تلقائيًا عندما تنشئ
‫هذا الشيء حقًا. ثم سيكون لديك تسميات
‫ثم سمة اسم هنا يمكنك تحديدها.
‫في هذه الحالة ، ترى أنه ملأ الكثير من
‫هذا بما أعطيته في سطر الأوامر.
‫أخبرتها أنني أريد أن أسميها اختبار.
‫لذا ، فهو يمنحها اسمًا للاختبار.
‫إنه يعين له تطبيقًا نظرًا لأننا نستخدم النشر
‫هنا ، فهو يعتبره تطبيقًا ، وليس خدمة أو أي
‫شيء آخر. إنه استدعاء اختبار التسمية هذا.
‫هذه مجرد إعدادات افتراضية خارج الصندوق.
‫ثم تكون مواصفات النشر نسخًا متماثلة
‫لواحد.
‫المحدد الذي سنصل إليه لاحقًا ، ولكن هذا هو الأساس
‫الذي يحدده هذا الشيء لتحديد الكبسولات داخل هذا
‫النشر. إنه في الأساس ما يطابق
‫هذا النشر مع كبسولاته.
‫ثم الإستراتيجية. الذي نتركه فارغًا.
‫القالب هنا خاص بـ ReplicaSet.
‫ثم سترى ضمن هذه المواصفات الحاويات
‫التي ستنشئها. لذا ، هناك القليل من طبقة متداخلة
‫من المواصفات التي تحدث هنا. هذا بسبب تعقيد هذه
‫الطبقات ، صحيح. لدينا البودات ، ثم مجموعات النسخ المتماثلة
‫، ثم عمليات النشر فوق ذلك.
‫يمكنك أن ترى أنه ينشئ كل ذلك بسرعة ، وسنطبق
‫ذلك على واجهة برمجة التطبيقات عندما نضغط على
‫هذا الأمر.
‫لنقم بإنشاء المزيد هنا. الطريقة الثانية هي استخدام الوظائف
‫بدلاً من عمليات النشر. عادة ما يتم تصميمه عندما
‫تريد إنشاء مجموعة من البودات تعمل مرة واحدة.
‫يميل إلى تعيينهم افتراضيًا لعدم إعادة التشغيل.
‫في هذه الحالة ، سنستخدم نفس الصورة
‫، نفس الاسم. سنقوم بتجفيفه باستخدام
‫yaml -output. سترى كم هو مختلف.
‫في هذه الحالة ، نظرًا لعدم وجود مستويات متعددة من النشر
‫مع ReplicaSet متداخلة بداخله ، فإننا لا نحتاج
‫إلى مستويات متعددة من المواصفات.
‫سترى ، أولاً ، أن هذا أقصر بكثير.
‫هذا يرجع إلى حد كبير إلى حقيقة أنه مع عمليات النشر
‫، فإنه ينشئ مجموعة متماثلة متداخلة تقوم بعد
‫ذلك بإنشاء الكبسولة. لذا ، هناك مستويات متعددة هناك.
‫أين هنا ، لدينا حقًا هذه الوظيفة المجمعة التي تخلق
‫قرونًا مباشرة لنا.
‫يمكنك أن ترى في الجزء العلوي أن كلا من إصدار API والنوع
‫قد تغيرا.
‫البيانات الوصفية متشابهة جدًا ، على الرغم من أنها
‫في هذه الحالة لم تنشئ تصنيفًا للتطبيق.
‫المواصفات مخصصة للوظائف فقط ، ثم أسفلها ، المواصفات الموجودة
‫بداخله ، داخل هذا القالب ، هي المواصفات
‫الخاصة بكل حاوية حاوية
‫، صحيح.
‫سيتم إنشاء هذه المواصفات الواحدة على الرغم من أنني طلبت
‫إنشاء العديد منها.
‫لقد أنشأنا واحدًا بشكل افتراضي.
‫لذلك ، سيكون لها حاوية واحدة تقوم بتشغيل Nginx
‫مع اختبار الاسم. ستلاحظ أن سياسة إعادة التشغيل
‫ليست أبدًا. هذا هو التغيير ، حقًا ،
‫مع معظم هذه الطرق الأخرى لإنشاء الحاويات
‫في Kubernetes. سيحاولون تلقائيًا إعادة الإنشاء أو
‫إعادة التشغيل. مع وظيفة ، أو
‫لاحقًا بوظيفة cron ، سترى أن سياسة إعادة التشغيل
‫مضبوطة على عدم. لأنه بمجرد انتهاء المهمة
‫، فإنها تنتهي للتو ، ولا تريد أن تعيد هذه
‫الحاوية إنشائها. أخيرًا ، لنقم بأمر كشف.
‫على الرغم من وجود تشغيل جاف هنا ، عند تشغيل نشر
‫الكشف ، فإنه سيتحقق من هذا النشر ويدرك
‫أنه غير موجود ، لذلك لا يمكنه إعطائك عينة
‫الإخراج لأنه لا يحتوي بالفعل على المدخلات
‫الصالحة .
‫في هذه الحالة ، نحتاج تقنيًا إلى إنشاء نشر.
‫في هذا ، لا نحتاج أن يكون التشغيل الجاف
‫والإخراج. نحن فقط نريده لإنشائه.
‫لذا ، دعنا نفعل ذلك فقط.
‫بعد ذلك ، دعنا نعود إلى أمر الكشف هذا ونحاول
‫مرة أخرى. ثم ستعمل هذه
‫المرة الجافة. سيكون لدينا نسخة API من V1.
‫ستلاحظ أن الخدمة هي النوع الآن بدلاً من
‫النشر أو الوظيفة.
‫ثم ، لدينا تسميات أخرى مماثلة.
‫سترى أن المواصفات تدور حول المنافذ والبروتوكولات
‫لأن هذا هو حقًا ما هي الخدمة.
‫إنه مزيج من مسارات الشبكة وشبكات IP
‫الفرعية ومنافذ TCP أو UDP وأشياء من
‫هذا القبيل. المولدات ليست بالضرورة
‫صفقة ضخمة. لست بحاجة إلى حفظها أو معرفة
‫الاختلافات بينها جميعًا. لأنك ستجد الكثير
‫منهم مع أمر kubectl run سيختفي ، كما ستكتشف
‫في غضون دقيقة. بعد ذلك ، في محاضرة لاحقة
‫، سنتحدث أكثر عن أنواع الطرق التي تنشئ بها الحاويات
‫وربما لماذا لا تستخدم الكثير من عمليات التشغيل والإنشاءات
‫في أعباء العمل الإنتاجية الخاصة بك.
‫تذكر حذف نشر الاختبار إذا قمت بإنشائه
‫لأمرنا الأخير حيث اختبرنا العرض.