بهترین شیوه‌ها

• 1: ملاحظات مربوط به کلاستر‌های بزرگ
• 2: اجرا در چندین منطقه
• 3: اعتبارسنجی تنظیمات گره(Node)
• 4: اجرای استانداردهای امنیتی pod
• 5: گواهینامه‌ها و الزامات PKI

1 - ملاحظات مربوط به کلاستر‌های بزرگ

یک کلاستر مجموعه‌ای از گره‌ها (ماشین‌های فیزیکی یا مجازی) است که عامل‌های کوبرنتیز را اجرا می‌کنند و توسط control plane مدیریت می‌شوند.

کوبرنتیز v1.37 از کلاستر‌هایی با حداکثر ۵,۰۰۰ گره(Node) پشتیبانی می‌کند. به طور خاص‌تر، کوبرنتیز به گونه‌ای طراحی شده است که پیکربندی‌هایی را که همه معیارهای زیر را برآورده می‌کنند، در خود جای دهد:

• حداکثر ۱۱۰ پاد در هر گره
• حداکثر ۵,۰۰۰ گره
• حداکثر ۱۵۰,۰۰۰ پاد در کل
• حداکثر ۳۰۰,۰۰۰ کانتینر در کل

شما می‌توانید با اضافه کردن یا حذف گره‌ها، کلاستر خود را مقیاس‌بندی کنید. روش انجام این کار به نحوه‌ی استقرار کلاستر شما بستگی دارد.

سهمیه منابع ارائه دهنده ابر

برای جلوگیری از مواجهه با مشکلات سهمیه ارائه دهنده ابر، هنگام ایجاد یک کلاستر با گره‌های زیاد، موارد زیر را در نظر بگیرید:

• درخواست افزایش سهمیه برای منابع ابری مانند:
  • نمونه‌های رایانه‌ای
  • پردازنده‌ها
  • حجم‌های ذخیره‌سازی
  • آدرس‌های IP در حال استفاده
  • مجموعه قوانین فیلتر بسته
  • تعداد متعادل‌کننده‌های بار
  • زیرشبکه‌های شبکه
  • جریان‌های گزارش
• محدود کردن اقدامات مقیاس‌بندی کلاستر برای ایجاد گره‌های جدید در دسته‌ها، با یک مکث بین دسته‌ها، زیرا برخی از ارائه دهندگان ابر، ایجاد نمونه‌های جدید را محدود می‌کنند.

اجزای Control plane

برای یک کلاستر بزرگ، به یک control plane با منابع محاسباتی و سایر منابع کافی نیاز دارید.

معمولاً شما یک یا دو نمونه control plane را در هر منطقه خرابی اجرا می‌کنید، ابتدا آن نمونه‌ها را به صورت عمودی مقیاس‌بندی می‌کنید و سپس پس از رسیدن به نقطه بازگشت نزولی به مقیاس (عمودی)، به صورت افقی مقیاس‌بندی می‌کنید.

شما باید حداقل یک نمونه را در هر منطقه خرابی اجرا کنید تا تحمل خطا فراهم شود. گره‌های Kubernetes به طور خودکار ترافیک را به سمت نقاط انتهایی control plane که در همان منطقه خرابی هستند هدایت نمی‌کنند. با این حال، ارائه دهنده ابر شما ممکن است مکانیسم‌های خاص خود را برای انجام این کار داشته باشد.

به عنوان مثال، با استفاده از یک متعادل کننده بار مدیریت شده، متعادل کننده بار را طوری پیکربندی می‌کنید که ترافیکی را که از kubelet و Pods در منطقه خرابی A سرچشمه می‌گیرد، ارسال کند و آن ترافیک را فقط به میزبان‌های control plane که در منطقه A نیز هستند، هدایت کند. اگر یک میزبان control plane یا منطقه خرابی نقطه انتهایی A آفلاین شود، به این معنی است که تمام ترافیک control plane برای گره‌های موجود در منطقه A اکنون بین مناطق ارسال می‌شود. اجرای چندین میزبان control plane در هر منطقه، احتمال وقوع چنین نتیجه‌ای را کاهش می‌دهد.

مخزن etcd

برای بهبود عملکرد کلاستر‌های بزرگ، می‌توانید اشیاء رویداد را در یک نمونه etcd اختصاصی جداگانه ذخیره کنید.

هنگام ایجاد یک کلاستر، می‌توانید (با استفاده از ابزارهای سفارشی):

• شروع و پیکربندی نمونه etcd اضافی
• پیکربندی API server برای استفاده از آن برای ذخیره رویدادها

برای جزئیات بیشتر در مورد پیکربندی و مدیریت etcd برای یک کلاستر بزرگ، به مدیریت کلاستر‌های etcd برای کوبرنتیز و راه‌اندازی یک کلاستر etcd با قابلیت دسترسی بالا با kubeadm مراجعه کنید.

منابع افزونه

کوبرنتیز محدودیت منابع به حداقل رساندن تأثیر نشت حافظه و سایر روش‌هایی که podها و containerها می‌توانند بر سایر اجزا تأثیر بگذارند، کمک می‌کند. این محدودیت‌های منابع، همانطور که برای بارهای کاری برنامه اعمال می‌شوند، برای منابع افزونه نیز اعمال می‌شوند.

به عنوان مثال، می‌توانید محدودیت‌های CPU و حافظه را برای یک جزء ثبت وقایع تنظیم کنید:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

محدودیت‌های پیش‌فرض افزونه‌ها معمولاً بر اساس داده‌های جمع‌آوری‌شده از تجربه اجرای هر افزونه روی کلاستر‌های کوچک یا متوسط کوبرنتیز است. هنگام اجرا روی کلاستر‌های بزرگ، افزونه‌ها اغلب منابع بیشتری نسبت به محدودیت‌های پیش‌فرض خود مصرف می‌کنند. اگر یک کلاستر بزرگ بدون تنظیم این مقادیر مستقر شود، افزونه(ها) ممکن است به دلیل رسیدن به حد مجاز حافظه، به‌طور مداوم از کار بیفتند. از طرف دیگر، افزونه ممکن است اجرا شود اما به دلیل محدودیت‌های برش زمانی CPU، عملکرد ضعیفی داشته باشد.

برای جلوگیری از بروز مشکلات مربوط به منابع افزونه کلاستر، هنگام ایجاد کلاستر با گره‌های زیاد، موارد زیر را در نظر بگیرید:

• برخی افزونه‌ها به صورت عمودی مقیاس‌پذیر هستند - یک کپی از افزونه برای کلاستر وجود دارد یا به کل یک منطقه خرابی سرویس می‌دهد. برای این افزونه‌ها، درخواست‌ها و محدودیت‌ها را همزمان با مقیاس‌پذیری کلاستر خود افزایش دهید.

• بسیاری از افزونه‌ها به صورت افقی مقیاس‌پذیر هستند - شما با اجرای پادهای بیشتر ظرفیت را افزایش می‌دهید - اما با یک کلاستر بسیار بزرگ، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.

مقیاس پذیر خودکار عمودی می‌تواند در حالت recommender اجرا شود تا ارقام پیشنهادی برای درخواست‌ها و محدودیت‌ها را ارائه دهد.

• برخی افزونه‌ها به صورت یک رونوشت در هر گره اجرا می‌شوند که توسط DaemonSet کنترل می‌شوند: به عنوان مثال، یک تجمیع‌کننده لاگ در سطح گره. مشابه مورد افزونه‌های مقیاس‌پذیر افقی، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.

گام‌های بعدی

• VerticalPodAutoscaler یک منبع سفارشی است که می‌توانید در کلاستر خود مستقر کنید تا به شما در مدیریت درخواست‌های منابع و محدودیت‌های podها کمک کند. درباره مقیاس پذیر خودکار عمودی و نحوه استفاده از آن برای مقیاس‌بندی اجزای کلاستر، از جمله افزونه‌های حیاتی کلاستر، بیشتر بدانید.

• درباره مقیاس‌بندی خودکار گره بخوانید

• تغییر اندازه افزونه به شما کمک می‌کند تا با تغییر مقیاس کلاستر، اندازه افزونه‌ها را به طور خودکار تغییر دهید.

2 - اجرا در چندین منطقه

این صفحه اجرای کوبرنتیز را در چندین منطقه توضیح می‌دهد..

پیشینه

کوبرنتیز به گونه‌ای طراحی شده است که یک کلاستر کوبرنتیز می‌تواند در چندین منطقه خرابی اجرا شود، که معمولاً این مناطق در یک گروه‌بندی منطقی به نام region قرار می‌گیرند. ارائه دهندگان اصلی ابر، یک منطقه را به عنوان مجموعه‌ای از مناطق خرابی (که به آن availability zones نیز می‌گویند) تعریف می‌کنند که مجموعه‌ای از ویژگی‌ها را ارائه می‌دهند: در یک منطقه، هر منطقه APIها و خدمات یکسانی را ارائه می‌دهد.

معماری‌های ابری معمول با هدف به حداقل رساندن احتمال اینکه خرابی در یک منطقه، خدمات در منطقه دیگر را نیز مختل کند، طراحی شده‌اند.

رفتار Control Plane

همه اجزای control plane از اجرا به عنوان مجموعه‌ای از منابع قابل تعویض، که برای هر جزء تکرار می‌شوند، پشتیبانی می‌کنند.

هنگامی که یک control plane کلاستر‌ی را مستقر می‌کنید، کپی‌هایی از اجزای control plane را در چندین منطقه خرابی قرار دهید. اگر در دسترس بودن یک نگرانی مهم است، حداقل سه منطقه خرابی را انتخاب کنید و هر جزء control plane (API server, scheduler, etcd, cluster controller manager) را در حداقل سه منطقه خرابی تکرار کنید.

اگر یک مدیر کنترل‌کننده ابری را اجرا می‌کنید، باید این را در تمام مناطق خرابی که انتخاب کرده‌اید نیز تکرار کنید.

رفتار گره(Node)

کوبرنتیز به‌طور خودکار پادهای منابع بارکاری (مانند Deployment یا StatefulSet) را روی گره‌های مختلف یک کلاستر توزیع می‌کند. این توزیع، اثر خرابی‌ها را کاهش می‌دهد.

وقتی گره‌ها راه‌اندازی می‌شوند، kubelet روی هر گره به‌طور خودکار labels را به شیء Node که نماینده همان kubelet در API کوبرنتیز است، اضافه می‌کند. این برچسب‌ها می‌توانند شامل اطلاعات ناحیه باشند.

اگر کلاستر شما چندین ناحیه یا منطقه را پوشش می‌دهد، می‌توانید برچسب‌های گره را به‌همراه محدودیت‌های گسترش توپولوژی پاد به‌کار بگیرید تا کنترل کنید پادها در میان دامنه‌های خطا—ناحیه‌ها، مناطق و حتی گره‌های خاص— چطور در کلاستر پخش شوند. این راهنماها به scheduler کمک می‌کنند تا پادها را طوری جای دهد که دسترسی مورد انتظار بهبود یابد و خطر تأثیر یک خرابی همبسته بر کل بارکاری کاهش پیدا کند.

برای نمونه، می‌توانید محدودیتی تعیین کنید تا اطمینان حاصل شود سه تکرار یک StatefulSet، هر یک در ناحیه‌ای متفاوت اجرا شوند، هر زمان که امکان‌پذیر باشد. شما می‌توانید این را به‌صورت اعلامی تعریف کنید بی‌آن‌که صراحتاً مشخص کنید کدام ناحیه‌های در دسترس برای هر بارکاری استفاده می‌شوند.

توزیع گره‌ها در مناطق مختلف

هسته کوبرنتیز خودش برای شما گره ایجاد نمی‌کند؛ باید این کار را خودتان انجام دهید یا از ابزاری مانند Cluster API برای مدیریت گره‌ها به نمایندگی از شما استفاده کنید.

با بهره‌گیری از ابزارهایی مثل Cluster API می‌توانید مجموعه‌ای از ماشین‌ها را تعریف کنید تا به‌عنوان گره‌های worker کلاستر در چندین دامنه خطا اجرا شوند، و همچنین قوانینی برای ترمیم خودکار کلاستر در صورت اختلال کامل یک ناحیه وضع کنید.

تخصیص دستی منطقه برای Podها

می‌توانید محدودیت‌های انتخاب‌گر گره را به پادهایی که ایجاد می‌کنید، و نیز به قالب‌های پاد در منابع بارکاری مانند Deployment، StatefulSet یا Job اعمال کنید.

دسترسی به فضای ذخیره‌سازی برای مناطق

هنگامی که حجم‌های پایدار ایجاد می‌شوند، کوبرنتیز به‌طور خودکار برچسب‌های ناحیه را
به هر PersistentVolume که به یک ناحیه خاص متصل است اضافه می‌کند.
scheduler سپس از طریق گزاره NoVolumeZoneConflict اطمینان حاصل می‌کند که پادهایی که یک PersistentVolume مشخص را درخواست می‌کنند، تنها در همان ناحیه آن حجم قرار گیرند.

توجه داشته باشید که روش افزودن برچسب‌های ناحیه می‌تواند به ارائه‌دهنده ابر شما و فراهم‌کننده ذخیره‌سازی‌ای که استفاده می‌کنید وابسته باشد.
همیشه به مستندات اختصاصی محیط خود مراجعه کنید تا پیکربندی صحیح را تضمین کنید.

می‌توانید یک StorageClass را برای PersistentVolumeClaimها مشخص کنید که دامنه‌های خطا (ناحیه‌ها) را که ذخیره‌سازی در آن کلاس می‌تواند از آن‌ها استفاده کند تعریف می‌کند.
برای یادگیری پیکربندی یک StorageClass که از دامنه‌های خطا یا ناحیه‌ها آگاه است، به توپولوژی‌های مجاز مراجعه کنید.

شبکه‌سازی

به‌خودیِ‌خود، کوبرنتیز شبکه آگاه از ناحیه در اختیار ندارد. می‌توانید با استفاده از افزونه شبکه شبکه کلاستر را پیکربندی کنید؛ این راهکار شبکه ممکن است اجزای مخصوص به ناحیه داشته باشد. برای نمونه، اگر ارائه‌دهنده ابر شما از Serviceهایی با type=LoadBalancer پشتیبانی کند، توازن‌بار احتمالاً ترافیک را تنها به پادهایی می‌فرستد که در همان ناحیه‌ای اجرا می‌شوند که مؤلفه توازن‌بار در آن اتصال را پردازش می‌کند. برای جزئیات بیشتر، به مستندات ارائه‌دهنده ابری خود مراجعه کنید.

برای استقرارهای سفارشی یا درون‌سازمانی نیز ملاحظات مشابهی وجود دارد. رفتار Service و Ingress—از جمله نحوه رسیدگی به نواحی خطای مختلف—بسته به چگونگی پیکربندی کلاستر شما متفاوت است.

بازیابی خطا

هنگامی که کلاستر خود را راه‌اندازی می‌کنید، ممکن است لازم باشد بررسی کنید که آیا و چگونه پیاده‌سازی شما می‌تواند سرویس را بازیابی کند اگر همه نواحی خطا در یک منطقه به‌طور هم‌زمان از دسترس خارج شوند. برای نمونه، آیا به این وابسته هستید که دست‌کم یک گره در یک ناحیه بتواند پادها را اجرا کند؟
اطمینان حاصل کنید که هر کار تعمیر حیاتی کلاستر به وجود دست‌کم یک گره سالم وابسته نباشد. برای مثال، اگر تمام گره‌ها ناسالم شوند، شاید لازم باشد یک Job تعمیر با toleration ویژه اجرا کنید تا تعمیر به‌اندازه‌ای پیش برود که دست‌کم یک گره دوباره به سرویس بازگردد.

کوبرنتیز پاسخی از پیش آماده برای این چالش ارائه نمی‌دهد؛ بااین‌حال، موضوعی است که باید در نظر داشته باشید.

گام‌های بعدی

برای آشنایی با نحوه قرار دادن پادها در کلاستر توسط scheduler با رعایت محدودیت‌های پیکربندی‌شده، به صفحه زمانبندی(Scheduling) و تخلیه(Eviction) مراجعه کنید.

3 - اعتبارسنجی تنظیمات گره(Node)

تست انطباق گره

آزمون انطباق گره یک چارچوب آزمون کانتینری‌شده است که برای یک گره، راستی‌آزمایی سامانه و آزمون کارکرد فراهم می‌کند. این آزمون بررسی می‌کند آیا گره حداقل نیازمندی‌های کوبرنتیز را برآورده می‌کند یا نه؛ گره‌ای که این آزمون را با موفقیت پشت سر بگذارد، صلاحیت پیوستن به یک کلاستر کوبرنتیز را دارد.

پیش‌نیاز گره

هشدارها برای اجرای تست انطباق گره، یک گره باید همان پیش‌نیازهای یک گره استاندارد کوبرنتیز را داشته باشد. حداقل، گره باید سرویس‌های زیر را نصب کرده باشد:

• زمان‌های اجرای کانتینر سازگار با CRI مانند Docker، containerd و CRI-O
• kubelet

اجرای تست انطباق گره

برای اجرای آزمون انطباق گره، مراحل زیر را انجام دهید:

۱. مقدار گزینه --kubeconfig را برای kubelet تعیین کنید؛ برای مثال: --kubeconfig=/var/lib/kubelet/config.yaml. از آنجا که چارچوب آزمون برای بررسی kubelet یک کنترل‌پلین محلی راه‌اندازی می‌کند، از http://localhost:8080 به‌عنوان نشانی سرور API استفاده کنید. چند پارامتر خط فرمان دیگر برای kubelet وجود دارد که ممکن است بخواهید به کار ببرید:

• --cloud-provider: اگر از --cloud-provider=gce استفاده می‌کنید، این پرچم را برای اجرای آزمون حذف کنید.

۲. آزمون انطباق گره را با فرمان زیر اجرا کنید:

# $CONFIG_DIR is the pod manifest path of your kubelet.
# $LOG_DIR is the test output path.
sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  registry.k8s.io/node-test:0.2

اجرای تست انطباق گره برای سایر معماری‌ها

کوبرنتیز همچنین imageهای داکر تست انطباق گره را برای معماری‌های دیگر ارائه می‌دهد:

اجرای آزمون انتخاب شده

برای اجرای تست‌های خاص، متغیر محیطی FOCUS را با عبارت منظم تست‌هایی که می‌خواهید اجرا کنید، بازنویسی کنید.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Only run MirrorPod test
  registry.k8s.io/node-test:0.2

برای رد کردن تست‌های خاص، متغیر محیطی SKIP را با عبارت منظم تست‌هایی که می‌خواهید رد کنید، بازنویسی کنید.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test
  registry.k8s.io/node-test:0.2

آزمون انطباق گره نسخه کانتینری‌شده آزمون گره e2e است و به‌طور پیش‌فرض همه آزمون‌های انطباق را اجرا می‌کند.

از نظر تئوری، اگر کانتینر را به‌درستی پیکربندی کرده و حجم‌های موردنیاز را مناسب مانت کنید، می‌توانید هر آزمون e2e گره را اجرا کنید. اما به‌شدت توصیه می‌شود فقط آزمون انطباق را اجرا کنید، زیرا اجرای آزمون‌های غیرانطباق به پیکربندی بسیار پیچیده‌تری نیاز دارد.

هشدارها

• آزمون تعدادی image داکر را روی گره باقی می‌گذارد؛ از جمله image آزمون انطباق گره و image کانتینرهایی که در آزمون کارکرد استفاده شدند.
• آزمون چند کانتینر مرده را روی گره باقی می‌گذارد. این کانتینرها در طول آزمون کارکرد ایجاد می‌شوند.

4 - اجرای استانداردهای امنیتی pod

این صفحه مروری بر بهترین شیوه‌ها در مورد اجرای استانداردهای امنیتی پاد ارائه می‌دهد.

استفاده از کنترل‌کننده پذیرش امنیتی داخلی pod

کنترل‌کننده‌ی پذیرش امنیت پاد Pod Security Admission Controller قصد دارد جایگزین سیاست‌های امنیتی منسوخ‌شده‌ی پاد (PodSecurityPolicies) شود.

پیکربندی تمام Namespace های کلاستر

namespace یی که فاقد هرگونه پیکربندی هستند، باید به عنوان شکاف‌های قابل توجه در مدل امنیتی کلاستر شما در نظر گرفته شوند. توصیه می‌کنیم برای تجزیه و تحلیل انواع Workloads موجود در هر namespace، وقت بگذارید و با مراجعه به استانداردهای امنیتی پاد، سطح مناسبی را برای هر یک از آنها تعیین کنید. فضاهای نام بدون برچسب فقط باید نشان دهند که هنوز ارزیابی نشده‌اند.

در سناریویی که همه Workloads در همه namespace ها الزامات امنیتی یکسانی دارند، ما یک مثال ارائه می‌دهیم که نحوه اعمال برچسب‌های PodSecurity را به صورت انبوه نشان می‌دهد.

اصل حداقل امتیاز را بپذیرید

در یک دنیای ایده‌آل، هر پاد در هر فضای نامی الزامات سیاست محدود را برآورده می‌کند. با این حال، این امر نه ممکن است و نه عملی، زیرا برخی از Workloads به دلایل موجه به امتیازات بالاتری نیاز دارند.

• namespace هایی که به Workloads «ممتاز» اجازه می‌دهند، باید کنترل‌های دسترسی مناسبی را ایجاد و اجرا کنند.
• برای Workloads که در آن namespace های مجاز اجرا می‌شوند، مستندات مربوط به الزامات امنیتی منحصر به فرد آنها را نگهداری کنید. در صورت امکان، در نظر بگیرید که چگونه می‌توان این الزامات را بیشتر محدود کرد.

اتخاذ یک استراتژی چند حالته

حالت‌های audit و warn کنترل‌کننده پذیرش استانداردهای امنیتی پاد ، جمع‌آوری بینش‌های امنیتی مهم در مورد پادهای شما را بدون ایجاد اختلال در حجم کار موجود، آسان می‌کند.

فعال کردن این حالت‌ها برای همه namespace ها، و تنظیم آنها روی سطح و نسخه مورد نظر شما که در نهایت می‌خواهید enforce کنید، یک تمرین خوب است. هشدارها و حاشیه‌نویسی‌های حسابرسی ایجاد شده در این مرحله می‌توانند شما را به سمت آن وضعیت هدایت کنند. اگر انتظار دارید نویسندگان بار کاری تغییراتی را برای مطابقت با سطح مورد نظر ایجاد کنند، حالت warn را فعال کنید. اگر انتظار دارید از گزارش‌های حسابرسی برای نظارت/هدایت تغییرات برای مطابقت با سطح مورد نظر استفاده کنید، حالت audit را فعال کنید.

وقتی حالت enforce را روی مقدار دلخواه خود تنظیم کرده‌اید، این حالت‌ها همچنان می‌توانند به چند روش مختلف مفید باشند:

• با تنظیم warn در همان سطح enforce، کلاینت‌ها هنگام تلاش برای ایجاد Podها (یا منابعی که قالب‌های Pod دارند) که اعتبارسنجی را پشت سر نمی‌گذارند، هشدارهایی دریافت می‌کنند. این به آنها کمک می‌کند تا آن منابع را برای مطابقت به‌روزرسانی کنند.
• در namespaceهایی که enforce را به یک نسخه غیرجدید خاص پین می‌کنند، تنظیم حالت‌های audit و warn در همان سطح enforce، اما به نسخه latest، امکان مشاهده تنظیماتی را فراهم می‌کند که در نسخه‌های قبلی مجاز بودند اما طبق بهترین شیوه‌های فعلی مجاز نیستند.

جایگزین‌های شخص ثالث

گزینه‌های دیگری برای اجرای پروفایل‌های امنیتی در اکوسیستم کوبرنتیز در حال توسعه هستند:

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

تصمیم برای استفاده از یک راهکار داخلی (مثلاً کنترل‌کننده پذیرش PodSecurity) در مقابل یک ابزار شخص ثالث، کاملاً به شرایط شما بستگی دارد. هنگام ارزیابی هر راهکاری، اعتماد به زنجیره تأمین شما بسیار مهم است. در نهایت، استفاده از هر یک از رویکردهای فوق‌الذکر بهتر از انجام ندادن هیچ کاری خواهد بود.

5 - گواهینامه‌ها و الزامات PKI

کوبرنتیز برای احراز هویت از طریق TLS به گواهینامه‌های PKI نیاز دارد. اگر کوبرنتیز را با kubeadm نصب کنید، گواهینامه‌هایی که کلاستر شما نیاز دارد به طور خودکار تولید می‌شوند. همچنین می‌توانید گواهینامه‌های خودتان را تولید کنید -- به عنوان مثال، برای ایمن‌تر نگه داشتن کلیدهای خصوصی خود با ذخیره نکردن آنها در سرور API. این صفحه گواهینامه‌هایی را که کلاستر شما نیاز دارد توضیح می‌دهد.

نحوه استفاده از گواهی‌ها توسط کلاستر شما

کوبرنتیز برای عملیات‌های زیر به PKI نیاز دارد:

گواهینامه‌های سرور

• گواهینامه سرور برای نقطه پایانی (endpoint) سرور API
• گواهینامه سرور برای سرور etcd
• گواهینامه‌های سرور برای هر kubelet (هر گره یک kubelet اجرا می‌کند)
• گواهینامه سرور اختیاری برای front-proxy

گواهینامه‌های Client

• گواهی‌های کلاینت برای هر kubelet، برای احراز هویت به سرور API به عنوان یک کلاینت از API کوبرنتیز
• گواهی کلاینت برای هر سرور API، برای احراز هویت به etcd
• گواهی کلاینت برای مدیر کنترل کننده (controller manager) برای ارتباط امن با سرور API
• گواهی کلاینت برای زمان‌بند (scheduler) برای ارتباط امن با سرور API
• گواهی‌های کلاینت، یکی برای هر گره، برای kube-proxy جهت احراز هویت به سرور API
• گواهی‌های کلاینت اختیاری برای مدیران کلاستر جهت احراز هویت به سرور API
• گواهی کلاینت اختیاری برای front-proxy

گواهینامه‌های سرور و کلاینت Kubelet

برای ایجاد یک اتصال امن و احراز هویت خود به kubelet، سرور API به یک گواهی کلاینت و جفت کلید نیاز دارد.

در این سناریو، دو رویکرد برای استفاده از گواهی وجود دارد:

• گواهی‌های مشترک: kube-apiserver می‌تواند از همان گواهی و جفت کلید مورد استفاده خود برای احراز هویت کلاینت‌های خود استفاده کند. این بدان معناست که گواهی‌های موجود، مانند apiserver.crt و apiserver.key، می‌توانند برای ارتباط با سرورهای kubelet استفاده شوند.

• گواهی‌های جداگانه: به عنوان یک جایگزین، kube-apiserver می‌تواند یک گواهی کلاینت و جفت کلید جدید برای احراز هویت ارتباط خود با سرورهای kubelet ایجاد کند. در این حالت، یک گواهی مجزا به نام kubelet-client.crt و کلید خصوصی مربوطه آن، kubelet-client.key ایجاد می‌شوند.

etcd همچنین TLS متقابل را برای احراز هویت کلاینت‌ها و نظیرها پیاده‌سازی می‌کند.

محل نگهداری گواهینامه‌ها

اگر کوبرنتیز را با kubeadm نصب کنید، بیشتر گواهینامه‌ها در /etc/kubernetes/pki ذخیره می‌شوند. تمام مسیرهای موجود در این مستندات به آن پوشه مربوط می‌شوند، به استثنای گواهینامه‌های حساب کاربری که kubeadm آنها را در /etc/kubernetes قرار می‌دهد.

پیکربندی دستی گواهینامه‌ها

اگر نمی‌خواهید kubeadm گواهی‌های مورد نیاز را تولید کند، می‌توانید آنها را با استفاده از یک CA ریشه واحد یا با ارائه همه گواهی‌ها ایجاد کنید. برای جزئیات بیشتر در مورد ایجاد مرجع صدور گواهی خود، به گواهینامه‌ها مراجعه کنید. برای اطلاعات بیشتر در مورد مدیریت گواهی‌ها، به مدیریت گواهینامه با kubeadm مراجعه کنید.

CA تک ریشه

شما می‌توانید یک root CA واحد ایجاد کنید که توسط یک مدیر کنترل می‌شود. این root CA می‌تواند چندین CA میانی ایجاد کند و تمام مراحل ایجاد بیشتر را به خود کوبرنتیز واگذار کند.

CA های مورد نیاز:

علاوه بر CA های فوق، دریافت یک جفت کلید عمومی/خصوصی برای مدیریت حساب سرویس، sa.key و sa.pub نیز ضروری است.

مثال زیر کلید CA و فایل‌های گواهی نشان داده شده در جدول قبلی را نشان می‌دهد:

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

همه گواهینامه‌ها

اگر نمی‌خواهید کلیدهای خصوصی CA را در کلاستر خود کپی کنید، می‌توانید خودتان تمام گواهینامه‌ها را تولید کنید.

گواهینامه‌های مورد نیاز:

مسیرهای گواهینامه

گواهی‌ها باید در یک مسیر پیشنهادی قرار گیرند (مطابق با مسیری که kubeadm استفاده می‌کند). مسیرها باید با استفاده از آرگومان داده شده، صرف نظر از مکان، مشخص شوند.

ملاحظات مشابهی برای جفت کلید service account اعمال می‌شود:

مثال زیر مسیرهای فایل از جداول قبلی را نشان می‌دهد که در صورت تولید تمام کلیدها و گواهی‌های خودتان، باید ارائه دهید:

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

پیکربندی گواهینامه‌ها برای حساب‌های کاربری

شما باید این حساب‌های کاربری مدیر و حساب‌های کاربری سرویس را به صورت دستی پیکربندی کنید:

1. برای هر پیکربندی، یک جفت گواهی/کلید x509 با نام مشترک (CN) و سازمان (O) داده شده ایجاد کنید.

2. برای هر پیکربندی، kubectl را به صورت زیر اجرا کنید:

   KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
   KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
   KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
   KUBECONFIG=<filename> kubectl config use-context default-system
   

این فایل‌ها به صورت زیر استفاده می‌شوند:

فایل‌های زیر مسیرهای کامل فایل‌های فهرست‌شده در جدول قبلی را نشان می‌دهند:

/etc/kubernetes/admin.conf
/etc/kubernetes/super-admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf