مقدمه
در مقالات قبلی یاد گرفتیم چگونه منابع را کنترل کنیم، پادها را بهصورت خودکار مقیاسبندی کنیم، گرهها را مدیریت کنیم و عملکرد خوشه را با ابزارهای پایه مانیتورینگ زیر نظر بگیریم. اما یک سوال مهم باقی میماند:
چگونه تنظیمات، متغیرهای محیطی، اطلاعات حساس (پسورد، کلید API، گواهی) و حتی کل چارتهای پیچیده اپلیکیشن را بهصورت تمیز، امن و قابلتکرار مدیریت کنیم؟
بدون مدیریت صحیح پیکربندی، حتی بهترین خوشه با HPA و Prometheus هم به سرعت به هرجومرج و مشکلاتی که در ادامه ذکر میکنیم تبدیل میشود.
چرا مدیریت صحیح پیکربندی در کوبرنتیز مهم است؟
فرض کنید خوشهای دارید که همه چیز ظاهراً عالی است:
HPA بهدرستی پادها را مقیاس میدهد،
Cluster Autoscaler گرهها را هوشمندانه اضافه و کم میکند،
Prometheus و Grafana تمام معیارها را لحظهبهلحظه نشان میدهند.
اما کافی است یکی از موارد زیر اتفاق بیفتد تا همه چیز به هم بریزد:
با نیاز به تغییر یک متغیر محیطی (مثلاً آدرس جدید message broker یا فعال کردن فیچر فلگ جدید) مجبور میشوید ایمیج را دوباره بسازید، تگ جدید بزنید، push کنید و Deployment را آپدیت کنید.
اطلاعات حساس (database password، API key، certificate private key) داخل Dockerfile یا مستقیماً در کد منبع نوشته شده و در نتیجه امنیت به شدت به خطر میافتد و در هر audit رد میشوید.
برای هر محیط (dev، staging، production) یا هر مشتری، دهها فایل YAML تقریباً یکسان را کپی-پیست میکنید که کوچکترین تفاوت (حتی یک خط فاصله یا غلط املایی) باعث شکست deploy میشود.
اپلیکیشن شما شامل ۱۲–۲۵ میکروسرویس است و فایلهای YAML پراکنده در مخزن پخش شدهاند و هیچکس نمیداند نسخه دقیقاً کدام است، آخرین تغییر کی اعمال شده، چگونه rollback کنیم یا چگونه محیط جدیدی را در کمتر از ۱۰ دقیقه راهاندازی کنیم.
این وضعیت در پروژههای کوچک شاید چند ماه قابل تحمل باشد، اما در محیط واقعی تولیدی (با چندین تیم، چندین محیط، CI/CD فعال، SLA سختگیرانه) خیلی زود به مشکلات زیر منجر میشود:
- downtime مکرر هنگام تغییر تنظیمات
- افزایش ریسک امنیتی
- زمان بسیار زیاد برای deploy و hotfix
- دشواری عیبیابی و تکرارپذیری پایین
- هزینه اضافی (انسانی و زیرساختی)
هدف این مقاله دقیقاً حل همین مشکلات است
در این مطلب میخواهیم ابزارها و الگوهای استاندارد صنعت را بررسی کنیم که به شما کمک میکنند:
-
پیکربندی را از کد و image جدا کنید.
-
اطلاعات حساس را به صورت امن مدیریت کنید.
-
استقرارهای پیچیده را تکرارپذیر، نسخهبندیشده و قابل نگهداری کنید.
فایلهای YAML و Helm را کجا بنویسیم و اجرا کنیم؟
ConfigMap و Secret همچنان با kubectl apply -f اعمال میشوند.
Helm v3 را معمولاً اینگونه نصب میکنند:
# macOS
brew install helm
# Linux
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# نسخه
helm version
ConfigMap جهت جداسازی تنظیمات غیرحساس یعنی برای متغیرهای محیطی، فایلهای تنظیم (application.yaml، logback.xml، nginx.conf و …) استفاده میشود.
مثال ۱ – متغیرهای محیطی
apiVersion: v1
kind: ConfigMap
metadata:
name: app-settings
namespace: prod
data:
SPRING_PROFILES_ACTIVE: prod
LOG_LEVEL: INFO
CACHE_TTL_MINUTES: "15"
FEATURE_PAYMENT_GATEWAY: "true"
استفاده در Deployment:
spec:
containers:
- name: spring-app
image: mycompany/backend:2.1.4
envFrom:
- configMapRef:
name: app-settings
مثال ۲ – تزریق فایل کامل
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
default.conf: |
server {
listen 80;
location /api {
proxy_pass http://backend-service:8080;
}
}
// مونتاژ در پاد
volumeMounts:
- name: nginx-conf
mountPath: /etc/nginx/conf.d
readOnly: true
volumes:
- name: nginx-conf
configMap:
name: nginx-config
Secret: مدیریت امن اطلاعات حساس
Secret معمولی فقط Base64 است (نه رمزنگاری واقعی). امروزه تقریباً هیچ تیم حرفهای فقط از Secret خام استفاده نمیکند.
بهترین روشهای فعلی:
محبوبترین راه در محیطهای ابری و سازمانی بزرگ:
- External Secrets Operator (ESO) + Vault / AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
- Sealed Secrets (Bitnami) یا SOPS (Mozilla) برای ذخیره امن در git
- CSI Driver مخصوص هر ارائهدهنده ابر
روش توصیهشده: External Secrets Operator
نصب با Helm:
helm repo add external-secrets https://charts.external-secrets.io
helm repo update
helm install external-secrets external-secrets/external-secrets \
--namespace external-secrets --create-namespace
Helm: مدیر پکیج کوبرنتیز
Helm مثل npm یا apt برای کوبرنتیز است.
ساختار یک چارت استاندارد:
my-backend-chart/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── configmap.yaml
│ └── _helpers.tpl
└── charts/ # subcharts (مثلاً redis)
values.yaml نمونه (قابل override):
replicaCount: 4
image:
repository: mycompany/api
tag: "2.3.1"
resources:
requests:
cpu: 400m
memory: 768Mi
ingress:
enabled: true
hostname: api.company.ir
config:
logLevel: info
cacheEnabled: true
جمعبندی
با تسلط بر ConfigMap، Secret امن و بهخصوص Helm، از سطح «اجرای پادهای ساده» به سطح «مدیریت حرفهای اپلیکیشنهای بزرگ، چندمحیطی و چندتیمی» میرسید. Helm به شما اجازه میدهد کل استک را مثل یک نرمافزار نسخهبندیشده مدیریت کنید و در عرض چند دقیقه ارتقا دهید یا rollback کنید.
در مقاله بعدی به شبکه پیشرفته میپردازیم: NetworkPolicy، Service Mesh (Istio یا Linkerd)، Ingress Controllerهای مدرن و امنیت لایه شبکه.
سوالات متداول
-
Helm یا Kustomize؟
Helm برای بستهبندی و انتشار، Kustomize برای تنظیمات محیطی است که بسیاری هر دو را ترکیب میکنند.
- Secret معمولی kubernetes امن است؟
خیر — فقط Base64 است. برای امنیت واقعی از ESO + Vault یا Sealed Secrets/SOPS استفاده کنید..
- کوبرنتیز چیست؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
ثبت نظر