‫انا سوف اكون صادق.
‫عندما رأيت Kubernetes YAML لأول مرة ، شعرت
‫بالخوف حقًا.
‫بدا الأمر أكثر تعقيدًا من تنسيق التأليف.
‫هذا لسبب وجيه.
‫إنها تضيف قدرًا كبيرًا من المرونة ، والعديد من الأشياء
‫التي يمكنك فعلها بها. لكن هذا له ثمن.
‫هذا هو التغلب على سنام تعلم الأساسيات وكيفية إنشاء
‫هذه الملفات. عندما بدأت في النظر إلى
‫هذه الملفات لأول مرة ، كان هناك الكثير من الأشياء التي لم أكن متأكدًا
‫منها حتى ما كان يحدث عندما احتفظت بهذه الملفات لأول مرة.
‫افهم تمامًا ما إذا كنت تشعر ببعض
‫الارتباك حيال هذا الأمر أثناء استعراضنا
‫له ، فقط حاول إعادة مشاهدة مقاطع الفيديو هذه لأنني
‫سأحاول تفصيل ذلك بطريقة أعتقد أنها أفضل لتعلم
‫Kubernetes YAML.
‫أولاً ، يمكننا كتابة هذا تقنيًا بلغة JSON
‫، لكن YAML يميل إلى أن يكون أسهل على البشر
‫في التلاعب والقراءة ، وأفضل JSON
‫لأجهزة الكمبيوتر.
‫ما يحدث في الخلفية هو المعيار بالنسبة
‫لنا كبشر هو كتابة YAML ثم تحويله
‫إلى JSON. من الناحية الفنية ، يمكنك كتابة
‫JSON ، لكن المعيار مع Kubernetes للكتابة
‫للبشر هو YAML.
‫كما قلت من قبل ، يمكنك مزج هذه الملفات
‫أو مطابقتها. يمكن أن يكون لديك العديد من الموارد المختلفة
‫في ملف واحد ثم القيام بعكس ذلك حيث يكون لديك
‫ملف واحد لكل مورد.
‫لا يهم حقًا. الأمر متروك لك.
‫تعمل الأوامر بنفس الطريقة.
‫نحن نطلق على هذه البيانات.
‫الوصف الكامل للمورد هو بيان
‫، وهذا البيان له متطلبات.
‫سترى هذه المتطلبات بالنسبة لمفاتيح الجذر داخل
‫ملف YAML.
‫الجذر يعني أنهم في بداية السطر.
‫يبدأ ذلك بإصدار API.
‫هناك نوع.
‫هناك بيانات وصفية. وهناك المواصفات.
‫لذا ، عليك أن ترى هؤلاء الموجودين في كل ملف حتى
‫تعمل هذه الموارد. ودعنا نلقي نظرة على بعض الأمثلة
‫السريعة من سطر الأوامر.
‫إذا كنت في مستودع Docker Mastery الخاص بك ، فسترى
‫دليل k8s-yaml حيث أضع بعض هذه
‫الأمثلة هنا.
‫إذا كنت لا ترى هذا الدليل ، فقد تحتاج إلى إجراء
‫git-pull للحصول على آخر التحديثات
‫إلى الريبو. إذا أجريت بعض التغييرات في الريبو من خلال هذه
‫الدورة التدريبية ، فلا بأس بذلك.
‫يمكنك إما استخدام git-stash لإخفاء تلك التغييرات مؤقتًا
‫ثم القيام بعملية git-pull.
‫أو يمكنك فقط نسخه إلى دليل
‫مختلف. ما عليك سوى استنساخها
‫في موقع مختلف لهذا الجزء من الدورة التدريبية ، لأن عناصر
‫Kubernetes هذه أحدث من العناصر الأصلية.
‫لذلك ، قد يعود البعض منكم في وقت لاحق وليس
‫لديهم آخر التحديثات.
‫المثال الأول هنا هو مجرد جراب بسيط.
‫ربما يكون هذا هو أبسط YAML يمكننا إنشاؤه.
‫كما قلت سابقًا في هذه الدورة ، لن تصنع هذا العدد الكبير
‫من البودات لأن هذا مجرد إنشاء مثل تشغيل عامل
‫الإرساء.
‫هذا ليس شيئًا حقًا تريد القيام به.
‫ليس لديها تحديثات مستمرة. إنها ليست عملية
‫نشر ، أليس كذلك. إذا احتجت في أي وقت إلى استكشاف الأخطاء وإصلاحها
‫، أو كنت بحاجة فقط إلى تشغيل شيء بسيط محليًا ، فيمكنك القيام بذلك.
‫ستلاحظ أن لها نفس المتطلبات الأربعة.
‫إصدار API والنوع والبيانات الوصفية
‫والمواصفات.
‫سنتحدث عن هؤلاء في المحاضرة القادمة.
‫في الوقت الحالي ، أريدك فقط أن ترى كيف
‫يتشكل هذا النوع من البودات. ثم البيانات الوصفية
‫لها سمة الاسم.
‫هذا المفتاح هو المفتاح المطلوب لجميع
‫كائنات YAML.
‫يجب أن يكون لديهم جميعًا هذا الاسم ، تمامًا مثل اسم
‫عامل الميناء. يجب أن يكون لجميع كائنات Docker اسم.
‫نفس الشيء مع Kubernetes. المواصفات هنا هي اللحم.
‫سنصل إلى ذلك في لحظة. دعنا نلقي نظرة أخرى على
‫عملية النشر.
‫فيما يلي عملية نشر واحدة مع نسختين
‫متماثلتين من نفس الحاوية. ربما يكون حجمها ضعف الحجم
‫ولكن لسبب وجيه.
‫لأنه إذا فكرت في الأمر ، فأنت تقوم
‫بإنشاء مورد النشر هذا ، ومن ثم يتم إنشاء
‫ReplicaSet. ثم هذا يخلق القرون.
‫تصبح منطقة المواصفات أكثر
‫تعقيدًا قليلاً لأنها تفعل المزيد من الأشياء
‫التي يتعين علينا تحديدها. ستلاحظ أيضًا أن إصدار API
‫الخاص بنا مختلف قليلاً
‫لأن ذلك مرتبط بالنوع ، والنوع في هذه الحالة
‫هو النشر. إنه نوع من هذا يعني الموارد.
‫وإصدار API هو إصدار API
‫لهذا النوع. الباقي هنا يبدو منطقيًا قليلاً
‫بالنسبة لك.
‫يبدو مشابهًا إلى حد ما لملفات الإنشاء ولكن
‫من الواضح أن التنسيق مختلف.
‫لذلك ، أتفهم أن الأمر قد يكون محيرًا ، خاصة إذا كنت تعمل
‫ذهابًا وإيابًا بين Compose و Kubernetes.
‫في هذا المثال ، قمت بدمج الخدمة
‫والنشر ، لنفس النوع
‫من النشر ، في ملف واحد.
‫هذه هي الطريقة التي سيكون لديك بها العديد من البيانات في ملف واحد حيث تستخدم
‫الشرط الثلاثة لفصل هذين الشرطين
‫عن بعضهما البعض. هذا نوع من YAML
‫الذي سيخبر Kubernetes ، هذا الكائن فريد
‫من نوعه. ثم الجزء التالي
‫هو كائن جديد. يمكنك الحصول على العدد
‫الذي تريده هنا حتى يصبح جامحًا لدرجة أنه عليك فقط كسره.
‫سترى مع هذا الجزء الأول ، إصدار API
‫هو V1 من نوع مورد الخدمة.
‫ربما تكون كلمة "نوع" هنا مجرد مورد ، لكنهم أطلقوا
‫عليها اسم "نوع".
‫البيانات الوصفية هنا مرة أخرى. يجب أن يكون لها اسم.
‫ستكون المواصفات مختلفة تمامًا بناءً على
‫المورد الذي تقوم بإنشائه.
‫ثم نشر مشابه لما كان لدينا سابقًا ، وهو في هذه
‫الحالة لدي ثلاث نسخ متماثلة ولديها اسم مختلف
‫قليلاً ، لكن بخلاف ذلك ، إنه نفس
‫Nginx.
‫بمجرد النظر إلى ذلك ، فأنت تفكر ، واو. يجب أن أحتاج إلى
‫قوالب سأخزنها حتى أعرف كيف أبدأ لأن هذا
‫يبدو معقدًا للغاية.
‫لا توجد صفحة مستندات واحدة توضح كل هذا
‫لجميع العشرات والعشرات من أنواع الموارد
‫المختلفة ، وكيف يجب إعداد كل منها.
‫هذا للأسف شيء حصلنا عليه مع Compose حيث
‫كانت أغنية رائعة ، رغم أنها طويلة.
‫صفحة ويب على Docker docs لتنسيق Compose
‫بالكامل. في هذه الحالة ، لا نحصل على
‫ذلك مع Kubernetes لمجرد وجود الكثير من التعقيد
‫، وليس كل شيء في مكان واحد.
‫إنه ليس تطبيقًا واحدًا. يمكنك بالفعل إضافة المزيد من أنواع
‫الموارد عن طريق إضافة المزيد من الأشياء المسماة CRDs والتي
‫سنتحدث عنها لاحقًا.
‫يمكننا الدخول في ذلك. هذا يعني في الأساس أنه يمكنك توسيع
‫Kubernetes بمزيد من أنواع الموارد.
‫المزيد من عناصر الطرف الثالث ، والتي من شأنها أن تضيف المزيد
‫من الخيارات إلى YAML. هذا فريد من نوعه لـ Kubernetes.
‫Swarm and Docker لا يسمحان بذلك.
‫يتم تعيين تنسيقها حيث يكون هذا الشكل قابلاً للتوسيع
‫تمامًا ، اعتمادًا على ما تم تثبيته في مجموعتك.