• با کانتینرها و Kubernetes از اصول اولیه شروع کنید: برای یادگیری موضوع به تجربه خاصی نیاز نیست. • خوشه های خود را اجرا کنید یا یک سرویس Kubernetes مدیریت شده از آمازون، گوگل و غیره را انتخاب کنید. • از Kubernetes برای مدیریت چرخه عمر کانتینر و مصرف منابع استفاده کنید. • خوشه ها را بر اساس هزینه، عملکرد، انعطاف پذیری، قدرت و مقیاس پذیری بهینه کنید. • بهترین ابزارها را برای توسعه، آزمایش و استقرار برنامه های کاربردی خود بیاموزید. • از شیوه های فعلی صنعت برای اطمینان از امنیت و کنترل استفاده کنید. • اصول DevOps را در سراسر شرکت خود اجرا کنید تا تیم های توسعه بتوانند انعطاف پذیرتر، سریع تر و کارآمدتر عمل کنند.
کتاب برای چه کسی است؟
این کتاب برای کارمندان بخشهای مدیریتی که مسئول سرورها، برنامهها و خدمات هستند، و همچنین برای توسعهدهندگانی که در ساخت سرویسهای ابری جدید یا مهاجرت برنامههای کاربردی موجود به Kubernetes و ابر مرتبط هستند، مرتبط است. نگران نباشید، لازم نیست بدانید چگونه با Kubernetes یا کانتینرها کار کنید - ما همه چیز را به شما آموزش خواهیم داد.
کاربران باتجربه Kubernetes نیز با پوشش عمیق موضوعاتی مانند RBAC، استقرار مداوم، مدیریت داده های حساس و قابلیت مشاهده، ارزش زیادی پیدا خواهند کرد. امیدواریم که صفحات کتاب بدون توجه به مهارت و تجربه شما، قطعاً حاوی مطالب جالبی برای شما باشد.
کتاب به چه سوالاتی پاسخ می دهد؟
در حین برنامه ریزی و نوشتن کتاب، با صدها نفر درباره فناوری ابری و Kubernetes بحث کردیم و با رهبران و کارشناسان صنعت و همچنین افراد تازه کار صحبت کردیم. در زیر سؤالاتی انتخاب شده است که می خواهند در این نشریه پاسخ داده شوند.
- "من علاقه مندم که چرا باید برای این فناوری وقت بگذاری. چه مشکلاتی به من و تیمم کمک می کند تا حل کنیم؟»
- Kubernetes جالب به نظر می رسد، اما مانع ورود نسبتاً بالایی دارد. تهیه یک مثال ساده دشوار نیست، اما مدیریت بیشتر و اشکال زدایی دلهره آور است. ما میخواهیم در مورد اینکه چگونه افراد خوشههای Kubernetes را در دنیای واقعی مدیریت میکنند و احتمالاً با چه مشکلاتی مواجه میشویم، توصیههای قابل اعتمادی دریافت کنیم."
- «توصیه ذهنی مفید خواهد بود. اکوسیستم Kubernetes به تیم های جدید گزینه های زیادی برای انتخاب می دهد. هنگامی که چندین راه برای انجام یک کار وجود دارد، چگونه می دانید کدام یک بهترین است؟ چگونه انتخاب کنیم؟
و شاید مهمترین سوال:
- "چگونه می توانم از Kubernetes بدون ایجاد اختلال در شرکت خود استفاده کنم؟"
گزیده. پیکربندی و اشیاء مخفی
توانایی جدا کردن منطق یک برنامه Kubernetes از پیکربندی آن (یعنی از هر مقدار یا تنظیماتی که ممکن است در طول زمان تغییر کند) بسیار مفید است. مقادیر پیکربندی معمولاً شامل تنظیمات محیطی خاص، آدرسهای DNS سرویس شخص ثالث و اعتبارنامههای احراز هویت است.
البته، همه اینها را می توان مستقیماً در کد قرار داد، اما این رویکرد به اندازه کافی انعطاف پذیر نیست. به عنوان مثال، تغییر یک مقدار پیکربندی از شما میخواهد تا دوباره کد خود را بسازید و اجرا کنید. راه حل بسیار بهتر این است که پیکربندی را از کد جدا کنید و آن را از روی یک فایل یا متغیرهای محیطی بخوانید.
Kubernetes چندین راه مختلف برای مدیریت پیکربندی ارائه می دهد. ابتدا، می توانید مقادیر را از طریق متغیرهای محیطی مشخص شده در مشخصات پوشش غلاف به برنامه منتقل کنید (به «متغیرهای محیطی» در صفحه 192 مراجعه کنید). دوم، داده های پیکربندی را می توان مستقیماً با استفاده از ConfigMap و اشیاء Secret در Kubernetes ذخیره کرد.
در این فصل، این اشیاء را با جزئیات بررسی می کنیم و به برخی از رویکردهای عملی برای مدیریت پیکربندی و داده های حساس با استفاده از یک برنامه آزمایشی نگاه می کنیم.
بهروزرسانی پوستههای غلاف هنگام تغییر پیکربندی
تصور کنید که یک استقرار در کلاستر خود دارید و می خواهید مقادیری را در ConfigMap آن تغییر دهید. اگر از نمودار Helm استفاده میکنید (به «Helm: Package Manager for Kubernetes» در صفحه 102 مراجعه کنید)، میتوانید بهطور خودکار تغییر پیکربندی را تشخیص دهید و پوستههای غلاف خود را با یک ترفند منظم بارگیری مجدد کنید. حاشیه نویسی زیر را به مشخصات استقرار خود اضافه کنید:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}
الگوی استقرار اکنون حاوی یک جمع کنترلی از پارامترهای پیکربندی است: اگر پارامترها تغییر کنند، مجموع بهروزرسانی میشود. اگر ارتقای فرمان را اجرا کنید، Helm تشخیص می دهد که مشخصات استقرار تغییر کرده است و همه پوسته های غلاف را مجددا راه اندازی می کند.
داده های حساس در Kubernetes
ما قبلاً می دانیم که شی ConfigMap مکانیزم انعطاف پذیری برای ذخیره و دسترسی به داده های پیکربندی در یک خوشه فراهم می کند. با این حال، اکثر برنامه ها دارای اطلاعات حساس و حساس هستند، مانند رمزهای عبور یا کلیدهای API. همچنین می توان آن را در ConfigMap ذخیره کرد، اما این راه حل ایده آل نیست.
در عوض، Kubernetes نوع خاصی از شی را ارائه می دهد که برای ذخیره داده های حساس طراحی شده است: Secret. در مرحله بعد، بیایید به مثالی از نحوه استفاده از این شی در برنامه آزمایشی خود نگاه کنیم.
برای شروع، نگاهی به مانیفست Kubernetes برای شی Secret بیندازید (به 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، می توانید چندین کلید و مقادیر را در یک شی Secret ذخیره کنید. در اینجا، برای سادگی، ما فقط از یک جفت کلید-مقدار استفاده می کنیم.
استفاده از اشیاء مخفی به عنوان متغیرهای محیطی
مانند ConfigMap، شی Secret را می توان در کانتینر به عنوان متغیرهای محیطی یا به عنوان یک فایل روی دیسک آن در دسترس قرار داد. در مثال زیر، یک متغیر محیطی به مقدار 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
هنگام باز کردن آدرس
The magic word is "xyzzy"
نوشتن اشیاء مخفی در فایل ها
در این مثال، شی Secret را به عنوان فایل به کانتینر متصل می کنیم. کد در پوشه hello-secret-file مخزن نمایشی قرار دارد.
برای اتصال 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، یک ولوم (در این مورد demo-secret-volume) ایجاد می کنیم و آن را در قسمت volumeMounts مشخصات روی ظرف نصب می کنیم. فیلد mountPath /secrets است، بنابراین Kubernetes یک فایل در این پوشه برای هر جفت کلید/مقدار تعریف شده در شی Secret ایجاد می کند.
در مثال خود، ما فقط یک جفت کلید-مقدار به نام magicWord تعریف کردیم، بنابراین مانیفست یک فایل تنها خواندنی /secrets/magicWord با دادههای حساس در ظرف ایجاد میکند.
اگر این مانیفست را مانند مثال قبلی اعمال کنید، باید همان نتیجه را دریافت کنید:
The magic word is "xyzzy"
خواندن اشیاء مخفی
در قسمت قبل از دستور kubectl describe برای نمایش محتویات یک ConfigMap استفاده کردیم. آیا می توان همین کار را با Secret انجام داد؟
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytes
لطفاً توجه داشته باشید که خود داده ها نمایش داده نمی شوند. اشیاء مخفی در Kubernetes از نوع Opaque هستند، به این معنی که محتویات آنها در خروجی توصیفی kubectl، ورودیهای گزارش یا ترمینال نشان داده نمیشود، و این باعث میشود که اطلاعات حساس به طور تصادفی آشکار نشود.
برای مشاهده یک نسخه کدگذاری شده YAML از داده های حساس، از دستور kubectl get استفاده کنید:
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque
base64
eHl6enk= چیست، کاملاً با مقدار اصلی ما متفاوت است؟ این در واقع یک شی Secret است که در کدگذاری base64 نشان داده شده است. Base64 طرحی برای رمزگذاری داده های باینری دلخواه به عنوان رشته ای از کاراکترها است.
از آنجا که اطلاعات حساس ممکن است باینری باشند و خروجی نباشند (همانطور که در مورد کلید رمزگذاری TLS وجود دارد)، اشیاء مخفی همیشه در قالب base64 ذخیره می شوند.
متن beHl6enk= نسخه کدگذاری شده پایه ۶۴ کلمه مخفی xyzzy ما است. می توانید با اجرای دستور base64 —decode در ترمینال این موضوع را تأیید کنید:
echo "eHl6enk=" | base64 --decode
xyzzy
بنابراین، در حالی که Kubernetes شما را از خروج تصادفی دادههای حساس در ترمینال یا فایلهای گزارش محافظت میکند، اگر مجوزهای خواندن اشیاء Secret را در یک فضای نام خاص داشته باشید، آن دادهها میتوانند base64 شده و متعاقبا رمزگشایی شوند.
اگر نیاز به کدگذاری متنی در base64 دارید (مثلاً برای قرار دادن آن در یک Secret)، از دستور base64 بدون آرگومان استفاده کنید:
echo xyzzy | base64
eHl6enkK
دسترسی به اشیاء مخفی
چه کسی می تواند اشیاء مخفی را بخواند و ویرایش کند؟ این مورد توسط RBAC، یک مکانیسم کنترل دسترسی تعیین می شود (ما در بخش فرعی «مقدمه ای بر کنترل دسترسی مبتنی بر نقش» در صفحه 258 به تفصیل درباره آن بحث خواهیم کرد). اگر خوشهای را اجرا میکنید که RBAC ندارد یا فعال نیست، همه اشیاء Secret شما برای هر کاربر و کانتینری در دسترس است (بعدا توضیح خواهیم داد که نباید هیچ خوشه تولیدی بدون RBAC داشته باشید).
رمزگذاری غیرفعال داده ها
در مورد کسانی که به پایگاه داده etcd دسترسی دارند، جایی که Kubernetes تمام اطلاعات خود را در آن ذخیره می کند، چطور؟ آیا آنها می توانند داده های حساس را بدون داشتن مجوز خواندن اشیاء Secret از طریق API بخوانند؟
از نسخه 1.7، Kubernetes از رمزگذاری غیرفعال داده پشتیبانی می کند. این بدان معنی است که اطلاعات حساس داخل etcd به صورت رمزگذاری شده روی دیسک ذخیره می شود و حتی برای کسانی که دسترسی مستقیم به پایگاه داده دارند قابل خواندن نیستند. برای رمزگشایی آن، به کلیدی نیاز دارید که فقط سرور Kubernetes API آن را داشته باشد. در یک خوشه با پیکربندی مناسب، رمزگذاری غیرفعال باید فعال شود.
می توانید بررسی کنید که آیا رمزگذاری غیرفعال در خوشه شما کار می کند یا خیر:
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...
اگر پرچم Experimental-encryption- Provider-config را نمی بینید، رمزگذاری غیرفعال فعال نمی شود. هنگام استفاده از Google Kubernetes Engine یا سایر خدمات مدیریت Kubernetes، داده های شما با استفاده از مکانیزم دیگری رمزگذاری می شوند، بنابراین پرچم وجود نخواهد داشت. با فروشنده Kubernetes خود تماس بگیرید تا ببینید آیا محتوای etcd رمزگذاری شده است یا خیر.
ذخیره سازی داده های محرمانه
برخی منابع Kubernetes هستند که هرگز نباید از خوشه حذف شوند، مانند اشیاء Secret بسیار حساس. می توانید با استفاده از حاشیه نویسی ارائه شده توسط مدیر Helm از یک منبع در برابر حذف محافظت کنید:
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keep
استراتژی های مخفی مدیریت اشیاء
در مثال از بخش قبل، داده های حساس بلافاصله پس از ذخیره شدن در خوشه از دسترسی غیرمجاز محافظت شدند. اما در فایل های مانیفست آنها به صورت متن ساده ذخیره می شدند.
هرگز نباید اطلاعات محرمانه را در فایل هایی که در کنترل نسخه هستند قرار دهید. چگونه می توانید این اطلاعات را قبل از اعمال آن در خوشه Kubernetes خود به طور ایمن مدیریت و ذخیره کنید؟
شما می توانید هر ابزار یا استراتژی را برای مدیریت داده های حساس در برنامه های خود انتخاب کنید، اما همچنان باید حداقل به سوالات زیر پاسخ دهید.
- داده های حساس در کجا باید ذخیره شوند تا دسترسی بالایی داشته باشند؟
- چگونه داده های حساس را برای برنامه های فعال خود در دسترس قرار دهیم؟
- هنگام جایگزینی یا ویرایش داده های حساس چه اتفاقی باید برای برنامه های شما بیفتد؟
درباره نویسندگان
جان آروندل مشاور با 30 سال سابقه در صنعت کامپیوتر است. او چندین کتاب نوشته و با شرکتهای زیادی از کشورهای مختلف همکاری میکند و به آنها در مورد زیرساختهای ابری بومی و Kubernetes مشاوره میدهد. در اوقات فراغت از موج سواری لذت می برد، تیرانداز خوبی با تپانچه است و به صورت آماتور پیانو می نوازد. در یک کلبه افسانه ای در کورنوال انگلستان زندگی می کند.
جاستین دومینگوس - مهندس مدیریت سیستم که در محیط DevOps با Kubernetes و فناوری های ابری کار می کند. او از گذراندن وقت در فضای باز، نوشیدن قهوه، خرچنگ زدن و نشستن پشت کامپیوتر لذت می برد. در سیاتل، واشنگتن، با یک گربه شگفت انگیز و همسر و دوست صمیمی تر، آدرین، زندگی می کند.
» جزئیات بیشتر در مورد کتاب را می توانید در اینجا بیابید
»
»
برای Khabrozhiteley 25% تخفیف با استفاده از کوپن - کوبرنیتس
پس از پرداخت نسخه کاغذی کتاب، کتاب الکترونیکی از طریق ایمیل ارسال می شود.
منبع: www.habr.com