Projelerin CPU ve RAM kaynaklarını ayarlama

Bir projenin kaynak kullanımı, çalıştırıldığı konteyner tarafından belirlenir. Lunex uygulaması, geliştirme runtime’ı, build podu ve paketlenmiş entegrasyon farklı süreçlerdir. Uygulamanın RAM’ini artırmak, çalışan entegrasyonun RAM limitini değiştirmez.

Bu rehber Kubernetes kurulumları içindir. Çalışan kaynakları değiştirmek için cluster/kurulum yetkisi; projeye ait dağıtım dosyasını değiştirip build etmek için platform-developer rolü gerekir.

Request, limit ve JVM heap

Request, node üzerinde planlama için; limit, çalışma sırasındaki sınır için kullanılır. Bellek limitini JVM heap’e eşitlemeyin; heap dışı kullanıma da alan bırakın. Kubernetes kaynak yönetimi bu davranışın ayrıntılarını açıklar.

Hangi ayar hangi çalışmayı etkiler?

Tablodaki request / limit sırası bu iki değeri gösterir. Yerel k3d kurulumunun bazı platform servis bütçeleri müşteri Helm varsayılanından farklı olabilir; geçerli podun değerlerini kontrol edin.

Run için proje başına CPU/RAM formu yoktur. deployment.jkube.yaml içindeki resources alanını değiştirmek geliştirme podunun sabit profilini değiştirmez. Benzer şekilde builder.pod.jkube.yaml içine resources eklemek builder’ın kaynak değerlerini değiştirmez; builder’ın RAM’i aşağıda anlatılan kurulum ayarıdır. Böyle bir ihtiyacı kurulum yöneticisiyle ele alın; paketlenmiş runtime için aşağıdaki desteklenen dosya akışını kullanın.

Paketlenmiş entegrasyonun CPU ve RAM’ini ayarlama

Dosyasında RAM belirtmeyen bir entegrasyon 512Mi istek ve 1Gi limit alır. Bu varsayılan, küçük bir örnek entegrasyonun ölçülen yaklaşık 370 MiB kullanımına göre seçilmiştir; kendi iş yükünüzü ölçmeden yeterli saymayın. RAM’i artırmak için aşağıdaki adımlarla limiti yükseltmeniz yeterlidir. Lunex RAM limiti olan her entegrasyona -XX:MaxRAMPercentage=50 ekler, böylece JVM’in heap’i en fazla limitin yarısı olur: 1Gi limitte 512 MiB, 2Gi limitte 1 GiB. JAVA_TOOL_OPTIONS içindeki kendi seçenekleriniz bu seçenekten sonra gelir, örneğin -Xmx heap’i değiştirir. 1Gi gibi küçük limitlerde JVM Serial çöp toplayıcıyı seçer; başka bir toplayıcı için örneğin -XX:+UseG1GC ekleyin.

1. Projede Source → deployment.jkube.yaml açın.
2. Mevcut metadata ve proje etiketlerini koruyun. Namespace ve serviceAccountName eklemeyin; bunları Deploy eden kurulum belirler.
3. spec.template.spec.containers altındaki entegrasyon konteynerine kaynakları ekleyin. Aşağıdaki değerler örnektir; iş yükünüze göre ölçerek belirleyin:

spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: integration
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              cpu: "2"
              memory: 2Gi

Şablonla oluşturulan dosyada konteyner tanımı yoktur; örnekteki integration adı olduğu gibi kullanılabilir. Dosyanızda zaten bir konteyner varsa onun adını koruyun. Dosyada zaten spec, template veya containers varsa ikinci bir aynı adlı YAML anahtarı eklemeyin; mevcut yapıya birleştirin. Bu parça projenin mevcut dosyasına eklenecek alanları gösterir, tek başına tam Deployment manifesti değildir.

4. Kaydedin; dağıtım dosyasını diğer değişikliklerle birlikte commit edip gönderin.
5. Build çalıştırın. Bu işlem imajı üretip mevcut namespace’e dağıtır.
6. Yeni pod hazır olduğunda gerçek kaynak değerlerini doğrulayın. Kurulum yöneticisi örneğin şu komutları kullanabilir:

kubectl -n lunex get deployment order-intake \
  -o jsonpath='{.spec.template.spec.containers[*].resources}'
kubectl -n lunex get pods -l io.etzel.lunex/projectId=order-intake
kubectl -n lunex top pods -l io.etzel.lunex/projectId=order-intake

Namespace ve proje adını kurulumunuza göre değiştirin. kubectl top için cluster’ın metrik hizmeti gerekir. Deployment sekmesindeki Runtime tablosunun CPU ve Memory sütunları ölçüm sunulursa yardımcı olur; limitin gerçekten uygulandığını pod tanımından kontrol edin.

Kaynak değerleri pakete Build sırasında girer. Başka bir ortamda aynı değerlerle çalıştırmak için yeni build’i dev’de Create release ile sürüm yapıp o ortamda Deployment → Releases → Deploy ile dağıtın. Restart paketi değiştirmez. Güncelleme yapmak için çalışan dağıtımı silmek zorunda değilsiniz.

Builder’ın RAM’ini ve süresini belirleme

Builder, kaynakları derleyen geçici poddur. RAM’i çalışan entegrasyondan bağımsızdır ve kurulumdaki bütün build’ler için tek değerdir: varsayılan 1Gi istek ve limit. Builder’daki her JVM’in heap’i en fazla limitin yarısıdır. Küçük bir örnek projenin build’i ölçümde yaklaşık 400 MiB kullandı; çok bağımlılığı olan bir proje daha fazlasını isteyebilir. Build logunda OutOfMemoryError veya build podunda OOMKilled görünürse değeri artırın. Bir build en fazla 30 dakika sürer; süre dolunca Kubernetes build podunu durdurur ve Build failed DeadlineExceeded nedenini gösterir.

Yönetici iki değeri Helm values dosyasında Lunex uygulamasının ortam değişkenleri olarak verir ve normal yükseltme işlemiyle uygular:

lunex:
  env:
    - {name: LUNEX_BUILDER_MEMORY, value: 2Gi}
    - {name: LUNEX_BUILDER_TIMEOUT, value: 45m}

Builder’ın ve CPU belirtmeyen entegrasyonların CPU’su, kendi kaynaklarını belirtmeyen diğer konteynerlerin değerleriyle birlikte namespace LimitRange’inden gelir. resourceBudget.limitRange altına yazılan değerler bu varsayılanların yalnızca o alanlarını değiştirir; örneğin CPU limiti için:

resourceBudget:
  limitRange:
    default:
      cpu: "4"

Bu ayar Lunex’in belirlediği RAM değerlerini ve açık kaynakları olan geliştirme podunu değiştirmez. Mevcut podların değerleri geriye dönük değişmez; yeni build poduyla kontrol edin.

Namespace kotası ve toplam kapasite

ResourceQuota, namespace’teki toplam talepleri, limitleri veya pod sayısını sınırlar. Kota dolduğunda yeni pod isteği, node üzerinde görünürde boş kaynak bulunsa bile reddedilebilir. Müşteri chart’ında kota varsayılan olarak kapalıdır, yerel k3d kurulumunda açıktır. Açık olduğunda Lunex’in bütçesi, Kubernetes’in kota kapsamlarıyla ayrılmış iki kotadır:

Build, ürettiği paketi dağıtır ve yeni pod hazır olana kadar bekler. Build podu ayrı kotada sayıldığı için çalışan bir projeyi yeniden build ederken builder’ın RAM’i yeni podun yerini almaz. Biten build podu, logu için saklansa da kotada yer tutmaz. Bir build sürerken başka bir projenin Build isteği exceeded quota: lunex-builds ile reddedilir; ilki bitince yeniden deneyin. Kota kapalıyken build’ler aynı anda çalışabilir.

Yönetici kotayı ortam bütçesine göre açar. hard altına yazılan değerler lunex-long-running’in yalnızca o sınırlarını değiştirir; builds, aynı anda çalışabilecek build sayısıdır:

resourceBudget:
  quota:
    enabled: true
    hard:
      limits.memory: 16Gi
    builds: 2

Kapasiteyi şöyle hesaplayın; kota kapalıysa aynı hesap node’ların RAM’i için geçerlidir:

• Uzun süreli podlar: platform servisleri + bütün entegrasyonlar + aynı anda güncellenebilecek her entegrasyon için bir pod daha + Run ve simülasyon podları.
• Build’ler: aynı anda çalışacak build sayısı × builder’ın RAM’i.

Bunlar kapasite garantisi olmayan örnek bütçelerdir. limits.memory: 10Gi, makineye 10 GiB RAM eklemez. Kullanılmayan Run podlarını kaldırmak, kotayı artırmadan önce kapasiteyi boşaltabilir.

Yönetici geçerli durumu inceleyebilir:

kubectl -n lunex get limitrange,resourcequota
kubectl -n lunex describe resourcequota
kubectl -n lunex get events --sort-by=.lastTimestamp

Kaynak sorunlarını teşhis etme

Değerleri temsilî mesaj boyutu ve eşzamanlılıkla ölçün. Bir projenin içinde çok sayıda route olması her route’a ayrı kaynak kotası sağlamaz; birbirinden bağımsız ölçekleme gerektiren işleri ayrı projeler olarak tasarlayın.