notes، وشغّل سير عمل apply وdiff قابلًا للمراجعة من مجلد k8s.","html":"حاليًا، الـ Deployment الخاص بـ notes-api مكتوب فيه PORT، والـ Deployment الخاص بقاعدة البيانات فيه كلمة المرور نصًّا صريحًا، وكل شيء يعيش في الـ namespace default بجوار كل ما يجرّبه الآخرون في هذا الـ cluster. هذه ثلاث طرق لإحداث حادث: غيّر إعدادًا فتضطر إلى تعديل حمل العمل؛ اقرأ المستودع فتحصل على كلمة المرور؛ شغّل kubectl delete متهوّرًا في default فتصيب عمل شخص آخر.
الـ namespace (نطاق الأسماء) نطاق للأسماء. يستطيع فريقان أن يملك كل منهما Deployment اسمه api في namespaces مختلفة. والـ namespaces هي أيضًا حيث تربط الصلاحيات (RBAC) وحصص الموارد، ما يجعلها الوحدة الطبيعية لـ «تطبيق واحد» أو «فريق واحد».
apiVersion: v1\nkind: Namespace\nmetadata:\n name: notesأضف namespace: notes إلى metadata في كل كائن آخر في k8s/، ثم اجعله الافتراضي لهذا الـ context حتى لا تكتب -n notes في كل مرة:
kubectl apply -f k8s/namespace.yaml\nkubectl config set-context --current --namespace=notesما لا تفعله الـ namespaces هو عزل الشبكة. يستطيع Pod في notes الاتصال بـ Service في أي namespace آخر ما لم تقل NetworkPolicy غير ذلك، وتفرضها إضافة الشبكة في الـ cluster لديك. لا تعامل الـ namespace كجدار أمني بمفرده.
الـ ConfigMap يحفظ إعدادات مفتاح-قيمة غير حسّاسة:
\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: notes-api-config\n namespace: notes\ndata:\n PORT: \"3000\"\n LOG_LEVEL: infoالقيم نصوص دائمًا، ولهذا وُضعت "3000" بين علامتَي تنصيص. الآن تستطيع image notes-api نفسها العمل بسجلات info في الإنتاج وdebug في staging، بتطبيق ConfigMap مختلف بدلًا من بناء image مختلفة.
الـ Secret له شكل الـ ConfigMap نفسه، لكنه مخصّص للقيم الحسّاسة. أنشئه من سطر الأوامر (أو من مدير الأسرار لديك) بدلًا من ملف محفوظ في المستودع:
\nkubectl create secret generic notes-db \\\n --from-literal=POSTGRES_PASSWORD='dev-only-change-me' \\\n --from-literal=DATABASE_URL='postgres://notes:dev-only-change-me@notes-db:5432/notes'وهنا الجزء المزعج. انظر إلى ما هو مخزّن:
\nkubectl get secret notes-db -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -dتعود القيمة مباشرة. بيانات الـ Secret مرمّزة بـ base64، لا مشفّرة. ما يجعل الـ Secrets أكثر أمانًا من الـ ConfigMaps هو كل ما يحيط بها: يستطيع RBAC منح صلاحية قراءة الـ ConfigMaps دون الـ Secrets، ويستطيع الـ cluster تشفير الـ Secrets أثناء تخزينها في etcd (والمزوّدون المُدارون يفعلون ذلك عادةً)، ولا تستلم الـ kubelets إلا الـ Secrets الخاصة بالـ Pods المُجدولة على الـ node الخاص بها.
\n\nحدّث الـ container في k8s/deployment.yaml:
containers:\n - name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n ports:\n - name: http\n containerPort: 3000\n envFrom:\n - configMapRef:\n name: notes-api-config\n env:\n - name: DATABASE_URL\n valueFrom:\n secretKeyRef:\n name: notes-db\n key: DATABASE_URLالحقل envFrom يحوّل كل مفتاح في الـ ConfigMap إلى متغيّر بيئة. وsecretKeyRef يسحب مفتاحًا واحدًا من الـ Secret. وفي k8s/db.yaml، استبدل القيمة الحرفية لـ POSTGRES_PASSWORD بـ secretKeyRef إلى الـ Secret نفسه.
إذا لم يكن المفتاح المُشار إليه موجودًا، فلن يبدأ الـ container أبدًا. يُظهر الـ Pod الحالة CreateContainerConfigError، ويسمّي kubectl describe pod المفتاح المفقود.
يمكن أيضًا تركيب الـ Secrets والـ ConfigMaps كملفات عبر volume. الملفات المركّبة تتحدّث في الـ Pods العاملة بعد تأخير قصير؛ أما متغيّرات البيئة فثابتة منذ بدء الـ container. بعد تغيير إعدادات تصل عبر متغيّرات البيئة، أعِد تشغيل الـ Pods تدريجيًا:
\nkubectl rollout restart deployment/notes-apiمجلد k8s/ لديك يحتوي الآن على namespace.yaml وconfigmap.yaml وdb.yaml وdeployment.yaml وservice.yaml. والحلقة لكل تغيير هي نفسها:
kubectl diff -f k8s/\nkubectl apply -f k8s/\nkubectl get all -l app.kubernetes.io/name=notes-apiالأمر diff هو خطوة المراجعة: يُظهر ما سيتغيّر على الـ cluster الحيّ، حقلًا بحقل، قبل أن تغيّره. اجعله عادة وستلتقط التعديل الشارد الذي كان سيعيد ضبط إصلاح طارئ أجراه أحدهم. وحين تحتاج إلى قيم مختلفة لكل بيئة، فإن Kustomize (المدمج في kubectl كـ kubectl apply -k) يضع طبقات صغيرة (overlays) فوق هذه الملفات الأساسية؛ وHelm، في الدرس 5.3، هو الإجابة الشائعة الأخرى.
يعمل notes-api الآن على Kubernetes بشبكة وإعدادات سليمة. لكنه ليس جاهزًا للإنتاج بعد: لا يعرف Kubernetes هل هو سليم، ولا كم يحتاج من المعالج، ولا كيف يحدّثه بأمان. القسم الخامس يغطّي الثلاثة.
\n","toc":[{"id":"sec-1","text":"namespace لـ notes-api","level":2},{"id":"sec-2","text":"الـ ConfigMaps للإعدادات","level":2},{"id":"sec-3","text":"الـ Secrets لبيانات الاعتماد","level":2},{"id":"sec-4","text":"ربطها بـ notes-api","level":2},{"id":"sec-5","text":"سير العمل اليومي","level":2}],"takeaways":["الـ ConfigMaps تحفظ الإعدادات غير الحسّاسة؛ والـ Secrets تحفظ بيانات الاعتماد، وتُحقن كمتغيّرات بيئة أو كملفات مركّبة.","قيم الـ Secret مرمّزة بـ base64 فقط، لا مشفّرة؛ احمِها بـ RBAC، وبالتشفير أثناء التخزين، وبإبقائها خارج Git.","متغيّرات البيئة القادمة من ConfigMap أو Secret تُقرأ مرة واحدة عند بدء الـ container، لذا أعِد تشغيل الـ Deployment بعد تغييرها.","الـ Namespaces تحدّد نطاق الأسماء والصلاحيات والحصص لفريق أو تطبيق، لكنها لا تعزل حركة الشبكة وحدها.","تشغيلkubectl diff -f k8s/ قبل kubectl apply -f k8s/ يُظهر بالضبط ما سيتغيّر، مثل pull request للـ cluster."],"further":[{"title":"ConfigMaps","url":"https://kubernetes.io/docs/concepts/configuration/configmap/"},{"title":"Secrets","url":"https://kubernetes.io/docs/concepts/configuration/secret/"},{"title":"Good practices for Kubernetes Secrets","url":"https://kubernetes.io/docs/concepts/security/secrets-good-practices/"},{"title":"Namespaces","url":"https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/"}],"quiz":[{"q":"يحفظ زميلك في Git ملف manifest لـ Secret قيم data فيه نصوص base64، قائلًا «لا بأس، إنها مرمّزة». ما المشكلة؟
stringData لا في data.","why":"العكس هو الصحيح؛ data يأخذ base64 وstringData يأخذ نصًّا صريحًا. الصيغة ليست المشكلة."},{"text":"الـ base64 ترميز يستطيع أي شخص عكسه بـ base64 -d، فبيانات الاعتماد الآن في سجلّ Git وكأنها نصّ صريح.","why":"صحيح. اعتبر السرّ مسرّبًا، ودوّره، وأبقِ قيم الـ Secrets خارج Git (استخدم مدير أسرار أو أدوات تشفير)."},{"text":"يرفض Kubernetes الـ Secrets المحفوظة في Git.","why":"لا يرى Kubernetes سجلّ Git لديك. سيقبل الـ manifest بكل سرور."},{"text":"الـ base64 يجعل القيم أطول من أن تصلح لمتغيّرات البيئة.","why":"يفكّ Kubernetes ترميز القيم قبل حقنها؛ والطول ليس المشكلة."}],"answer":1},{"q":"تغيّر LOG_LEVEL في الـ ConfigMap notes-api-config وتطبّقه. الـ Pods تستهلكه عبر envFrom. ماذا يحدث؟
kubectl rollout restart deployment/notes-api.","why":"صحيح. متغيّرات البيئة تُضبط عند بدء الـ container. والـ rollout restart يستبدل الـ Pods تدريجيًا بالقيم الجديدة."},{"text":"تنهار الـ Pods لأن بيئتها تغيّرت من تحتها.","why":"العمليات العاملة تحتفظ ببيئتها؛ ولا يُدفع إليها أي شيء."}],"answer":2},{"q":"Pod جديد عالق بحالة CreateContainerConfigError. ما السبب الأرجح؟
kubectl describe pod يسمّي المفتاح المفقود."},{"text":"لا يمكن سحب الـ image من الـ registry.","why":"هذا يظهر كـ ErrImagePull أو ImagePullBackOff."},{"text":"انهار التطبيق عند البدء.","why":"الانهيار بعد البدء يظهر كـ CrashLoopBackOff، مع سجلات يمكن قراءتها."},{"text":"نفدت ذاكرة الـ node.","why":"الـ Pod الذي لا يمكن وضعه لنقص الموارد يبقى Pending مع حدث جدولة."}],"answer":0},{"q":"notes-api وخدمة مدفوعات يعملان في namespaces منفصلة على الـ cluster نفسه. هل يستطيع Pod من notes-api فتح اتصال بالـ Service الخاص بقاعدة بيانات المدفوعات؟
","options":[{"text":"لا، الـ namespaces تحجب كل الحركة بينها.","why":"الـ namespaces تحدّد نطاق الأسماء والصلاحيات. ودون NetworkPolicy تستطيع الـ Pods الوصول إلى الـ Services في أي namespace."},{"text":"فقط إذا كان لكلا الـ namespaces الـ labels نفسها.","why":"الـ labels الخاصة بالـ namespace تهمّ في selectors الـ NetworkPolicy، لكن دون سياسة لا يوجد أي تقييد."},{"text":"فقط عبر Service من نوع LoadBalancer.","why":"الـ Services من نوع ClusterIP يمكن الوصول إليها من كل namespace في الـ cluster افتراضيًا."},{"text":"نعم، افتراضيًا؛ استخدم NetworkPolicy (مع إضافة شبكة تفرضها) لتقييد ذلك.","why":"صحيح. الـ namespaces ليست حدًّا شبكيًا. والـ NetworkPolicies هي طريقة إضافة هذا الحدّ."}],"answer":3}],"exercise":{"kind":"fill","language":"bash","template":"# Create the namespace and make it the default for this context\nkubectl create {{0}} notes\nkubectl config set-context --current --{{1}}=notes\n\n# Store the database password as a Secret\nkubectl create secret {{2}} notes-db --from-literal=POSTGRES_PASSWORD=dev-only-change-me\n\n# Read it back (and see that it isn't encrypted)\nkubectl get secret notes-db -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 {{3}}\n\n# Pick up changed environment variables in running Pods\nkubectl rollout {{4}} deployment/notes-api","blanks":[{"answers":["namespace","ns"]},{"answers":["namespace"]},{"answers":["generic"]},{"answers":["-d","--decode","-D"]},{"answers":["restart"]}],"title":"Namespace، ثم Secret، ثم إعادة تشغيل","prompt":"املأ الفراغات لإنشاء الـ namespace notes وجعله الافتراضي، وتخزين كلمة مرور قاعدة البيانات في Secret، وفكّ ترميزها لإثبات أنها base64 فقط، وإعادة تشغيل notes-api حتى يلتقط متغيّرات البيئة المتغيّرة.
set-context.","نوع الـ Secret المخصّص لأي أزواج مفتاح-قيمة تختارها اسمه بالإنجليزية عكس «specific» (محدّد).","يفكّ base64 الترميز بخيار قصير؛ وkubectl rollout له أمر فرعي يستبدل الـ Pods دون تغيير القالب يدويًا."],"explanation":"kubectl create namespace notes\nkubectl config set-context --current --namespace=notes\nkubectl create secret generic notes-db --from-literal=POSTGRES_PASSWORD=dev-only-change-me\nkubectl get secret notes-db -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d\nkubectl rollout restart deployment/notes-apigeneric هو نوع الـ Secret للمفاتيح التي تختارها بنفسك (ومن الأنواع الأخرى tls وdocker-registry). خطوة فكّ الترميز تُظهر لماذا يجب ألا تُحفظ ملفات الـ Secret في المستودع أبدًا. وrollout restart يستبدل الـ Pods تدريجيًا، والجديدة منها تقرأ القيم الحالية للـ ConfigMap والـ Secret عند البدء.