حجز "Kubernetes for DevOps"

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

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

لمن الكتاب؟

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

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

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

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

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

ولعل الأهم من كل الأسئلة:

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

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

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

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

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

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

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

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

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

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

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

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

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

للبدء، ألق نظرة على بيان 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"

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

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

لتوصيل 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 هو /secrets، لذلك سيقوم Kubernetes بإنشاء ملف واحد في هذا المجلد لكل زوج من المفاتيح/القيمة المحددة في الكائن السري.

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

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

The magic word is "xyzzy"

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

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

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

base64

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

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

النص beHl6enk= هو النسخة المشفرة base64 من كلمتنا السرية xyzzy. يمكنك التحقق من ذلك عن طريق تشغيل الأمر base64 —decode في الوحدة الطرفية:

echo "eHl6enk=" | base64 --decode
xyzzy

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

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

echo xyzzy | base64
eHl6enkK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عن المؤلفين

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

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

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

ل Khabrozhiteli خصم 25٪ على الكوبون - Kubernetes

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

المصدر: www.habr.com