Helm ile production kurulumu

Kurulum topolojisi ve ön koşullar

Chart, Smart Kubaba'yı stateless ve yatay ölçeklenebilir bir uygulama katmanı olarak dağıtır. Kalıcı doğruluk durumu cluster dışındaki veya paylaşılan servislerde tutulur.

• Kubernetes 1.24+ uyumlu cluster, Helm 3 ve kubectl erişimi; HPA etkinse Metrics Server.
• Uygulama pod'larından erişilebilen harici PostgreSQL ve yeterli max_connections bütçesi.
• Production için S3-compatible shared object storage veya tüm replica'ların gerçekten aynı içeriği gördüğü ReadWriteMany filesystem.
• Önceden oluşturulmuş application Secret, imagePullSecret, ingress controller, DNS kaydı ve TLS Secret.
• Hostname spread DoNotSchedule kullanılırken en az üç uygun worker node; zone label yoksa zone spread davranışı ayrıca doğrulanmalıdır.

Chart hangi kaynakları oluşturur?

Chart template'leri application credential üretmez; deployment kaynaklarını mevcut platform servislerine bağlar.

• Deployment: non-root UID/GID 999, RollingUpdate maxUnavailable=0/maxSurge=1, 10 saniye minReady ve 600 saniye progress deadline.
• Service: sessionAffinity=None kullanan ClusterIP ve varsayılan 8080 portu.
• Ingress: tek host, / Prefix route, seçilebilir ingressClass ve TLS Secret referansı.
• HPA: CPU utilization, 30 saniye scale-up ve 300 saniye scale-down stabilization; PDB varsayılan minAvailable=2.
• Startup/readiness/liveness probe'ları; readiness PostgreSQL ve shared storage durumunu, liveness yalnız process sağlığını kapsar.
• Persistence açıksa mevcut veya chart-created PVC; kapalıysa geçici /data/smart-kubaba emptyDir.

Eksiksiz production values.yaml

Aşağıdaki örnek chart'taki bütün value alanlarını içerir ve S3-backed HA production profiline göre güvenli placeholder'larla hazırlanmıştır. image.tag mutlaka immutable release ile değiştirilmelidir.

• ingress annotation anahtarları kaynak production profilindeki F5 NGINX Controller içindir; ingress-nginx veya başka controller kullanıyorsanız kendi eşdeğerlerinizi girin.
• autoscaling.enabled=true iken Deployment replicaCount kullanmaz; başlangıç replica sayısını HPA minReplicas belirler.
• 20 GiB ingress sınırı backend upload limitleriyle eşleşmeli; limitsiz body-size kullanılmamalıdır.

replicaCount: 3
revisionHistoryLimit: 10
fullnameOverride: smart-kubaba

image:
  repository: kubaba.s3t.co/smart-kubaba
  tag: "REPLACE_WITH_IMMUTABLE_RELEASE"
  pullPolicy: Always
  pullSecrets:
    - kubaba-s3t-co-docker-config

# This Secret must already exist. The chart never creates credentials.
existingSecret: smart-kubaba-secrets

service:
  type: ClusterIP
  port: 8080

ingress:
  enabled: true
  className: nginx
  annotations:
    # F5 NGINX Ingress annotations used by the source production profile.
    # Replace these keys when the cluster uses ingress-nginx or another controller.
    nginx.org/client-max-body-size: "20g"
    nginx.org/proxy-read-timeout: "3600s"
    nginx.org/proxy-send-timeout: "3600s"
  host: kubaba.example.com
  tls:
    enabled: true
    secretName: kubaba-tls

# Recommended production profile: shared S3-compatible object storage.
# Bucket, region, endpoint and optional credentials come from existingSecret.
storage:
  type: S3
  rootDirectory: /data/smart-kubaba/storage
  archiveDirectory: /data/smart-kubaba/archive

# S3 keeps durable application objects outside the pod. The chart still mounts
# an emptyDir at /data/smart-kubaba for bounded temporary OSV work files.
persistence:
  enabled: false
  existingClaim: ""
  storageClass: ""
  accessModes:
    - ReadWriteMany
  size: 100Gi

autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 4
  targetCPUUtilizationPercentage: 70

podDisruptionBudget:
  enabled: true
  minAvailable: 2

resources:
  requests:
    cpu: 500m
    memory: 768Mi
    ephemeral-storage: 1Gi
  limits:
    cpu: "2"
    memory: 2Gi
    ephemeral-storage: 10Gi

javaToolOptions: "-Xms256m -Xmx1280m -XX:+ExitOnOutOfMemoryError"
terminationGracePeriodSeconds: 60
preStopDelaySeconds: 10

# Pool sizes are per pod. Reserve PostgreSQL headroom for migrations,
# administration, monitoring and non-application clients.
databasePool:
  maximumSize: 10
  minimumIdle: 2
  connectionTimeoutMillis: 10000
  validationTimeoutMillis: 5000
  idleTimeoutMillis: 600000
  maxLifetimeMillis: 1800000
  leakDetectionThresholdMillis: 0

probes:
  startup:
    failureThreshold: 24
    periodSeconds: 5
  readiness:
    failureThreshold: 6
    periodSeconds: 10
  liveness:
    failureThreshold: 3
    periodSeconds: 20

nodeSelector: {}
tolerations: []
affinity: {}

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway

Filesystem/RWX alternatifi

S3 yerine filesystem kullanılacaksa aynı PVC bütün replica'larda aynı anda mount edilmelidir. Node-local disk veya ReadWriteOnce volume, çok replica'lı production için uygun değildir.

• existingClaim boş bırakılırsa chart accessModes ve size ile PVC üretir; production'da önceden test edilmiş mevcut claim tercih edilir.
• Longhorn için standart non-migratable RWX StorageClass kullanılmalıdır; migratable=true block-mode live migration içindir ve NFS share-manager sağlamaz.

# Use this override only with storage shared by every replica.
storage:
  type: FILESYSTEM
  rootDirectory: /data/smart-kubaba/storage
  archiveDirectory: /data/smart-kubaba/archive

persistence:
  enabled: true
  # Prefer a pre-created, tested RWX claim for production.
  existingClaim: smart-kubaba-data-rwx
  storageClass: ""
  accessModes:
    - ReadWriteMany
  size: 100Gi

Secret ve image pull yapısı

existingSecret ile gösterilen Kubernetes Secret bütün application environment anahtarlarını envFrom üzerinden sağlar. Chart Secret oluşturmaz ve gerçek değerler values.yaml içine yazılmaz.

• PostgreSQL URL, kullanıcı ve parola ile bootstrap admin kullanıcı/parolası ilk kurulumdan önce secret manager'da oluşturulmalıdır.
• S3 access key'leri verilmezse backend AWS default credential provider chain kullanabilir; workload identity/instance role tercih edilebilir.
• image.pullSecrets ayrı kubernetes.io/dockerconfigjson Secret referansıdır; application Secret içine Docker config konmaz.
• Bootstrap admin initial password yalnız kullanıcı henüz yokken kullanılır; kurulum sonrasında secret rotation ve yönetici parola politikası ayrıca işletilmelidir.

Required for first installation:
SMART_KUBABA_DB_URL
SMART_KUBABA_DB_USERNAME
SMART_KUBABA_DB_PASSWORD
SMART_KUBABA_ADMIN_USERNAME
SMART_KUBABA_ADMIN_INITIAL_PASSWORD

Required when storage.type is S3:
SMART_KUBABA_STORAGE_S3_BUCKET
SMART_KUBABA_STORAGE_S3_REGION

Provider-dependent S3 keys:
SMART_KUBABA_STORAGE_S3_ENDPOINT_URL
SMART_KUBABA_STORAGE_S3_PATH_STYLE_ACCESS
SMART_KUBABA_STORAGE_S3_ACCESS_KEY_ID
SMART_KUBABA_STORAGE_S3_SECRET_ACCESS_KEY

Optional OIDC redirect keys:
SMART_KUBABA_OIDC_SUCCESS_REDIRECT
SMART_KUBABA_OIDC_FAILURE_REDIRECT

The image pull credential is a separate kubernetes.io/dockerconfigjson
Secret named by image.pullSecrets.

Kurulum adımları

Komutlar D:/workspace/smart-kubaba repository kökünden çalıştırılacak şekilde hazırlanmıştır.

1. values-production.yaml içindeki image tag, host, TLS Secret, ingress class, storage ve kapasite değerlerini hedef ortama göre güncelleyin.
2. kubaba namespace, smart-kubaba-secrets ve registry pull Secret'ını platform secret manager üzerinden oluşturun.
3. helm lint ile schema/template hatalarını, helm template ile render edilmiş manifest ve secret referanslarını inceleyin.
4. İlk kurulumda immutable image tag ile helm upgrade --install çalıştırın ve wait/timeout sınırını koruyun.
5. Deployment rollout, pod readiness, Service/Ingress, HPA/PDB ve readiness endpoint sonucunu doğrulayın.

# Run from the Smart Kubaba source repository.
kubectl create namespace kubaba --dry-run=client -o yaml | kubectl apply -f -

# Create smart-kubaba-secrets and the registry pull Secret through the
# platform secret manager before continuing. Do not commit plaintext values.

helm lint ./helm/smart-kubaba   -f values-production.yaml

helm template smart-kubaba ./helm/smart-kubaba   --namespace kubaba   -f values-production.yaml   --set-string image.tag="<release>"   > rendered-smart-kubaba.yaml

helm upgrade --install smart-kubaba ./helm/smart-kubaba   --namespace kubaba   --create-namespace   -f values-production.yaml   --set-string image.tag="<release>"   --wait   --timeout 15m

Kurulum doğrulaması

Helm başarılı sonucu tek başına kabul değildir. Uygulama, veritabanı, storage, package trafiği ve operasyon kayıtları birlikte doğrulanmalıdır.

• Bütün pod'lar Ready, Deployment Available, HPA/PDB beklenen durumda ve Ingress TLS sertifikası geçerli olmalıdır.
• Readiness UP; PostgreSQL/Flyway ve global shared storage sağlıklı olmalıdır. Liveness external dependency kesintisinde process'i gereksiz yeniden başlatmamalıdır.
• Yönetim login'i, Hosted publish/download, Proxy fetch/cache, Group resolution ve Package Usage/Audit/Outbound kayıtları kabul senaryosuyla çalıştırılmalıdır.
• S3 veya RWX storage birden fazla replica üzerinden aynı artifact checksum'ını sunmalıdır.

kubectl -n kubaba get deployment,service,ingress,pods,hpa,pdb,pvc
kubectl -n kubaba rollout status deployment/smart-kubaba --timeout=10m
kubectl -n kubaba wait --for=condition=Ready pod -l app=smart-kubaba --timeout=10m

helm -n kubaba status smart-kubaba
helm -n kubaba get values smart-kubaba --all
helm -n kubaba get manifest smart-kubaba > installed-smart-kubaba.yaml

# Readiness includes PostgreSQL and shared-storage availability.
kubectl -n kubaba port-forward service/smart-kubaba 8080:8080
curl --fail --silent --show-error http://127.0.0.1:8080/actuator/health/readiness

Upgrade, rollback ve kaldırma

Kurulu release'lerde sonraki upgrade'ler --atomic ile başarısız rollout'u otomatik geri alabilir. İlk kez mevcut raw-manifest kaynaklarını Helm'e alıyorsanız otomatik cleanup/atomic kullanmadan waited adoption yapılmalıdır.

• Her upgrade öncesinde PostgreSQL migration zinciri, chart appVersion/image tag ve önceki Helm revision kaydedilmelidir.
• Rollback yalnız pod/image durumunu geri almak değildir; Flyway history ile mevcut kod migration seti ayrıca karşılaştırılmalıdır.
• helm uninstall PostgreSQL, S3 bucket veya external PVC backup'ını silmez; veri saklama ve recovery ayrı operatör kararıdır.

# Later upgrades: pin an immutable chart/image release and enable atomic rollback.
helm upgrade smart-kubaba ./helm/smart-kubaba   --namespace kubaba   -f values-production.yaml   --set-string image.tag="<new-release>"   --atomic   --wait   --timeout 15m

helm -n kubaba history smart-kubaba

# Select a known-good revision from helm history.
helm -n kubaba rollback smart-kubaba <revision> --wait --timeout 15m

# Removal does not replace PostgreSQL/object-storage recovery planning.
helm -n kubaba uninstall smart-kubaba

Kapasite ve güvenlik sınırları

• databasePool.maximumSize pod başınadır. autoscaling.maxReplicas × maximumSize değerine migration, admin, monitoring ve diğer client headroom'u eklenerek PostgreSQL max_connections altında kalınmalıdır.
• javaToolOptions ve resource limits birlikte ölçülmelidir; heap limitini container memory limitine eşitlemek native/direct buffer ve JVM overhead için alan bırakmaz.
• SMART_KUBABA_COOKIE_SECURE=true chart tarafından zorunlu verilir; production yönetim trafiği TLS dışında yayımlanmamalıdır.
• Secret değerleri Helm command line, values file, rendered manifest, Git veya CI loglarına yazılmamalıdır.
• Bu chart backup/restore, RTO/RPO, certificate issuance, PostgreSQL HA veya object-storage durability garantisi sağlamaz; bunlar platform runbook'larıyla tamamlanmalıdır.