كتاب Kubernetes لـ DevOps

صورةمرحبا ، هابروجيتلي! Kubernetes هي أحد العناصر الرئيسية للنظام البيئي السحابي الحديث. توفر هذه التقنية الموثوقية والقابلية للتطوير والمرونة للمحاكاة الافتراضية للحاويات. يتحدث جون أروندل وجوستين دومينغوس عن النظام البيئي Kubernetes ويقدمان حلولًا مثبتة للمشاكل اليومية. خطوة بخطوة ، ستقوم بإنشاء تطبيقك المستند إلى السحابة الخاصة بك وإنشاء البنية التحتية لدعمه ، وتكوين بيئة التطوير وخط أنابيب النشر المستمر ، والذي سيكون مفيدًا لك عند العمل على التطبيقات التالية.

• ابدأ بالحاويات و Kubernetes من البداية: لا يلزم خبرة خاصة لتعلم الموضوع. • ابدأ مجموعاتك الخاصة أو اختر خدمة Kubernetes مُدارة من Amazon و Google وغيرها. • استخدم Kubernetes لإدارة دورة حياة الحاوية واستهلاك الموارد. • تحسين المجموعات من حيث التكلفة والأداء والمرونة والقوة وقابلية التوسع. • تعرف على أفضل الأدوات لتطوير تطبيقاتك واختبارها ونشرها. • الاستفادة من ممارسات الصناعة الحالية للسلامة والسيطرة. • تنفيذ مبادئ DevOps في شركتك بحيث تصبح فرق التطوير أكثر مرونة وسرعة وكفاءة.

لمن هذا الكتاب؟


الكتاب أكثر صلة لموظفي الإدارات المسؤولة عن الخوادم والتطبيقات والخدمات ، وكذلك للمطورين المشاركين في بناء خدمات سحابية جديدة أو ترحيل التطبيقات الحالية إلى Kubernetes والسحابة. لا تقلق ، فلا داعي لمعرفة كيفية العمل مع Kubernetes والحاويات - سنعلمك كل شيء.

سيجد مستخدمو Kubernetes ذوو الخبرة أيضًا الكثير ليكتشفوه: موضوعات مثل RBAC ، والنشر المستمر ، وإدارة البيانات الحساسة ، وقابلية الملاحظة مغطاة بعمق. نأمل أن تحتوي صفحات الكتاب بالتأكيد على شيء مثير للاهتمام بالنسبة لك ، بغض النظر عن مهاراتك وخبرتك.

ما الأسئلة التي يجيب عليها الكتاب


خلال تخطيط وكتابة الكتاب ، ناقشنا تقنيات السحابة و Kubernetes مع مئات الأشخاص ، وتحدثنا مع القادة والخبراء في الصناعة ، وكذلك مع المبتدئين المطلقين. فيما يلي أسئلة فردية يرغبون في الاطلاع على إجابات لها في هذا المنشور.

  • "أنا مهتم بالسبب في قضاء الوقت على هذه التقنية. ما المشكلات التي ستساعدني وفريقي في حلها؟ "
  • "يبدو Kubernetes مثيرًا للاهتمام ، ولكن لديه حد دخول مرتفع جدًا. إعداد مثال بسيط ليس بالأمر الصعب ، ولكن المزيد من الإدارة وتصحيح الأخطاء أمر مخيف. نود الحصول على نصيحة موثوقة حول كيفية إدارة الأشخاص لمجموعات Kubernetes في الحياة الواقعية وما هي المشاكل التي من المحتمل أن نواجهها ".
  • "نصيحة ذاتية ستكون مفيدة. يقدم النظام البيئي Kubernetes فرق مبتدئة العديد من الخيارات للاختيار من بينها. عندما يمكن القيام بنفس الشيء بعدة طرق ، كيف نفهم أيهما أفضل؟ كيف تختار؟ "

وربما أهم الأسئلة:

  • "كيف أستخدم Kubernetes دون تعطيل شركتي؟"

مقتطفات. التكوين والأشياء السرية


القدرة على فصل منطق تطبيق Kubernetes عن تكوينه (أي من أي قيم أو إعدادات قد تتغير بمرور الوقت) مفيدة جدًا. تتضمن قيم التكوين عادةً إعدادات لبيئة معينة ، وعناوين DNS لخدمات الجهات الخارجية ، وبيانات الاعتماد للمصادقة.

بالطبع ، كل هذا يمكن وضعه مباشرة في الكود ، لكن هذا النهج غير مرن بما فيه الكفاية. على سبيل المثال ، لتغيير قيمة التكوين ، سيتعين عليك إعادة تجميع التعليمات البرمجية ونشرها. سيكون الحل الأفضل بكثير هو فصل التكوين عن الكود وقراءته من متغيرات الملف أو البيئة.

يوفر Kubernetes عدة طرق مختلفة لإدارة التكوين الخاص بك. أولاً ، يمكنك تمرير القيم إلى التطبيق من خلال متغيرات البيئة المحددة في مواصفات غلاف البودرة (انظر قسم "متغيرات البيئة" في الصفحة 192). ثانيًا ، يمكن تخزين بيانات التكوين مباشرة في Kubernetes باستخدام ConfigMap والكائنات السرية.

في هذا الفصل ، سوف نفحص هذه الكائنات بالتفصيل ونأخذ في الاعتبار بعض الأساليب العملية لإدارة التكوين والبيانات الحساسة باستخدام تطبيق تجريبي كمثال.

تحديث أغلفة الجراب عند تغيير التكوينات


تخيل أن نظام المجموعة لديه عملية نشر وتريد تغيير بعض القيم في ConfigMap الخاصة به. إذا كنت تستخدم مخطط Helm (انظر قسم "Helm: Package Manager for Kubernetes" في الصفحة 102) ، يمكنك اكتشاف تغيير في التكوين وإعادة تشغيل الأصداف الخاصة بك تلقائيًا باستخدام حيلة واحدة أنيقة. أضف التعليق التوضيحي التالي إلى مواصفات النشر الخاصة بك:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

الآن يحتوي قالب النشر على المجموع الاختباري لمعلمات التكوين: عندما يتم تغيير المعلمات ، يتم تحديث المجموع. إذا قمت بتشغيل أمر ترقية helm ، فسيجد Helm أن مواصفات النشر قد تغيرت وإعادة تشغيل جميع الأصداف.

البيانات السرية في Kubernetes


نحن نعلم بالفعل أن كائن ConfigMap يوفر آلية مرنة لتخزين بيانات التكوين والوصول إليها في مجموعة. ومع ذلك ، تحتوي معظم التطبيقات على معلومات سرية وسرية: على سبيل المثال ، كلمات المرور أو مفاتيح واجهة برمجة التطبيقات. يمكن أيضًا تخزينه في ConfigMap ، ولكن هذا الحل ليس مثاليًا.

بدلاً من ذلك ، يقدم Kubernetes نوعًا خاصًا من الكائنات المصممة لتخزين البيانات الحساسة: Secret. بعد ذلك ، نعتبر مثالًا لكيفية تطبيق هذا الكائن في تطبيقنا التجريبي.

للبدء ، ألق نظرة على بيان Kubernetes للعنصر السري (انظر hello-secret-env / k8s / secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

في هذا المثال ، المفتاح الخاص magicWord هو xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). تعد كلمة xyzzy مفيدة جدًا بشكل عام في عالم أجهزة الكمبيوتر. على غرار ConfigMap ، يمكنك وضع العديد من المفاتيح والقيم في كائن سري. هنا ، من أجل البساطة ، نستخدم زوجًا واحدًا فقط من قيمة المفتاح.

استخدام الأشياء السرية كمتغيرات بيئة


مثل ConfigMap ، يمكن إتاحة الكائن السري في الحاوية كمتغيرات بيئة أو ملف على القرص الخاص به. في المثال التالي ، سنقوم بتعيين قيمة متغير البيئة من Secret:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord


قم بتشغيل الأمر التالي في مستودع العرض التوضيحي لتطبيق البيانات:

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

كما كان من قبل ، أعد توجيه المنفذ المحلي للنشر لرؤية النتيجة في متصفحك:

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

عند فتح عنوان المضيف المحلي : 9999 / سترى ما يلي:

The magic word is "xyzzy"

كتابة كائنات سرية للملفات


في هذا المثال ، سنقوم بإرفاق الكائن السري بالحاوية كملف. الرمز موجود في مجلد ملف hello-secret في المستودع التجريبي.

لتوصيل Secret كملف ، سنستخدم النشر التالي:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-file
          ports:
              - containerPort: 8888
          volumeMounts:
              - name: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumes:
      - name: demo-secret-volume
        secret:
           secretName: demo-secret

كما في القسم الفرعي "إنشاء ملفات التكوين من كائنات ConfigMap" على الصفحة. 240 ، نقوم بإنشاء وحدة تخزين (في هذه الحالة ، حجم تجريبي - سرّي) ونوصلها بالحاوية في قسم مواصفات volumeMounts. MountPath هو / أسرار ، لذلك سيقوم Kubernetes بإنشاء ملف واحد لكل زوج قيمة مفتاح محدد في الكائن السري في هذا المجلد.

في مثالنا ، حددنا زوجًا واحدًا فقط من القيمة الرئيسية يسمى magicWord ، لذا سينشئ البيان ملفًا واحدًا / secrets / magicWord يحتوي على بيانات سرية في الحاوية للقراءة فقط.

إذا قمت بتطبيق هذا البيان بنفس الطريقة كما في المثال السابق ، يجب أن تحصل على نفس النتيجة:

The magic word is "xyzzy"

قراءة الأشياء السرية


في القسم السابق ، استخدمنا الأمر kubectl description لعرض محتويات ConfigMap. هل يمكنك أن تفعل نفس الشيء مع السر؟

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

يرجى ملاحظة أن البيانات نفسها لا يتم عرضها. الأشياء السرية في Kubernetes هي من نوع معتم: وهذا يعني أن محتوياتها لا تظهر في إخراج kubectl الذي يصف ، وإدخالات دفتر اليومية والمطراف ، مما يجعل من المستحيل الكشف عن معلومات حساسة عن طريق الخطأ.

لعرض النسخة المشفرة من البيانات الحساسة بتنسيق YAML ، استخدم الأمر kubectl get:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

قاعدة 64


ما هو eHl6enk = ، الذي يختلف تمامًا عن قيمتنا الأصلية؟ هذا في الواقع كائن سري ، ممثلة في ترميز base64. Base64 هو نظام ترميز للبيانات الثنائية العشوائية كسلسلة من الأحرف.

نظرًا لأن المعلومات السرية قد تكون ثنائية ولا يمكن الوصول إليها للإخراج (على سبيل المثال ، في حالة مفتاح تشفير TLS) ، يتم تخزين الكائنات السرية دائمًا بتنسيق base64.

النص beHl6enk = هو إصدار base64 المرمّز لكلمتنا السرية xyzzy. يمكنك التحقق من ذلك إذا قمت بتنفيذ الأمر base64 --decode في النهاية الطرفية:

echo "eHl6enk=" | base64 --decode
xyzzy

وبالتالي ، على الرغم من حقيقة أن Kubernetes تحميك من عرض البيانات السرية بطريق الخطأ في ملفات المحطة الطرفية أو ملفات السجل ، إذا كان لديك أذونات لقراءة كائنات سرية في مساحة اسم محددة ، فيمكن تلقي هذه البيانات بتنسيق base64 وفك تشفيرها لاحقًا.

إذا كنت بحاجة إلى ترميز بعض النص في base64 (على سبيل المثال ، لوضعه في السر) ، فاستخدم الأمر base64 بدون وسائط:

echo xyzzy | base64
eHl6enkK

الوصول إلى الأشياء السرية


من يستطيع قراءة وتحرير الأشياء السرية؟ يتم تحديد ذلك بواسطة RBAC ، آلية التحكم في الوصول (سنناقشها بالتفصيل في قسم "مقدمة إلى التحكم في الوصول المستند إلى الدور" في الصفحة 258). إذا كنت تستخدم مجموعة يكون فيها نظام RBAC غائبًا أو غير ممكن ، فإن جميع الكائنات السرية الخاصة بك يمكن الوصول إليها من قبل أي مستخدمين وحاويات (سنوضح لاحقًا أنه لا يجب أن يكون لديك أي مجموعة صناعية بدون RBAC).

تشفير البيانات السلبية


ماذا عن أولئك الذين لديهم حق الوصول إلى قاعدة بيانات etcd ، التي تخزن فيها Kubernetes جميع معلوماتها؟ هل يمكنهم قراءة البيانات الحساسة دون الحق في قراءة الكائنات السرية من خلال واجهة برمجة التطبيقات؟

بدءًا من الإصدار 1.7 ، يدعم Kubernetes تشفير البيانات السلبية. وهذا يعني أن المعلومات السرية داخل etcd يتم تخزينها على القرص في شكل مشفر ولا يمكن قراءتها حتى من قبل أولئك الذين لديهم وصول مباشر إلى قاعدة البيانات. لفك تشفيرها ، تحتاج إلى مفتاح يمتلكه خادم Kubernetes API فقط. في نظام تم تكوينه بشكل صحيح ، يجب تمكين التشفير السلبي.

تحقق مما إذا كان التشفير السلبي يعمل في مجموعتك من خلال القيام بذلك:

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

إذا كنت لا ترى علامة التجريبية التجريبية للتشفير-الموفر ، فلن يتم تمكين التشفير السلبي. عند استخدام Google Kubernetes Engine أو خدمات إدارة Kubernetes الأخرى ، يتم تشفير بياناتك باستخدام آلية مختلفة ، وبالتالي فإن العلم سيكون غائبًا. تحقق مع مزود Kubernetes الخاص بك لمعرفة ما إذا كانت محتويات etcd مشفرة.

تخزين البيانات السرية


هناك موارد Kubernetes التي لا يجب إزالتها مطلقًا من مجموعة: على سبيل المثال ، الكائنات السرية المهمة بشكل خاص. يمكنك حماية المورد من الحذف باستخدام التعليق التوضيحي المقدم من Helm Manager:

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

استراتيجيات إدارة الكائن السري


في المثال من القسم السابق ، تمت حماية البيانات الحساسة من الوصول غير المصرح به فورًا بعد تخزينها في المجموعة. ولكن في ملفات البيان ، تم تخزينها في نص عادي.

يجب ألا تضع معلومات سرية مطلقًا في الملفات الموجودة في نظام التحكم في الإصدار. كيفية إدارة هذه المعلومات وتخزينها بأمان قبل تطبيقها على مجموعة Kubernetes؟

يمكنك اختيار أي أدوات أو إستراتيجيات للعمل مع البيانات الحساسة في تطبيقاتك ، ولكنك ما زلت بحاجة للإجابة على الأسئلة التالية على الأقل.

  • أين يتم تخزين البيانات الحساسة بحيث يسهل الوصول إليها؟
  • كيف تجعل البيانات الحساسة متاحة لتطبيقاتك النشطة؟
  • , ?


جون أرونديل استشاري يتمتع بخبرة 30 عامًا في صناعة الكمبيوتر. وقد كتب العديد من الكتب ويعمل مع العديد من الشركات من دول مختلفة ، وتقديم المشورة لهم بشأن البنية التحتية القائمة على السحابة و Kubernetes. في وقت فراغه يستمتع بركوب الأمواج ، ويطلق النار على مسدس جيد ويلعب البيانو بشكل هواة. يعيش في كوخ رائع في كورنوال ، إنجلترا.

جوستين دومينجوس هو مهندس إدارة نظام يعمل في بيئة DevOps مع Kubernetes وتقنيات السحابة. يحب قضاء الوقت في الهواء الطلق ، وشرب القهوة ، والتقاط السرطان ، والجلوس على الكمبيوتر. يعيش في سياتل ، واشنطن ، إلى جانب قطة رائعة وزوجة أكثر روعة وأفضل صديق بدوام جزئي أدريان.

»يمكن العثور على مزيد من المعلومات حول الكتاب على موقع الناشر على الويب
» المحتويات
» مقتطفات

لـ Khabrozhiteley خصم 25 ٪ على القسيمة - Kubernetes

عند دفع النسخة الورقية من الكتاب ، يتم إرسال كتاب إلكتروني عبر البريد الإلكتروني.

All Articles