Deployment neyin çalıştığını ve pod olaylarında Kubernetes’in onu başlatırken ne yaptığını, Log uygulamanın ne yazdığını gösterir. İkisini aynı proje, ortam ve pod için birlikte okuyun. Proje başlığındaki Running, bütün route’ların veya iş mesajlarının başarılı olduğu anlamına gelmez.
Henüz çalıştırmadıysanız Run/Reload rehberini izleyin. Log bir runtime varken görünür ve Build açıkken de yerinde kalır. Build sırasında builder çıktısı Build sekmesinde izlenir; build podları Deployment’ta listelenmez. Bu sayfa Kubernetes kurulumlarını anlatır.
Runtime: doğru podu bulun
Önce Runtime tablosunun açıklamasını okuyun: Release <numara> is deployed in <ortam>., An unreleased build is deployed in <ortam>. veya Not deployed in <ortam>.. Ortam kurulumun aktif ortamıdır; burada başka cluster seçerek dağıtım yapılmaz.
| Alan | Okuyacağınız bilgi |
|---|---|
| Pod | Podun adı. Geliştirme runtime’ını paketlenmiş uygulamanın podlarından Version sütunu ayırır. |
| Status | Çalışma durumu; varsa neden ve açıklama. Yalnız renk yerine metni okuyun. |
| Started | Podun başlama zamanı, yerel saatle; ISO değeri ipucundadır. Son commit veya son mesaj zamanı değildir. |
| Version | Podun çalıştırdığı sürüm. Release <numara>: podun imajı o sürümün paketindekiyle aynıdır. Unreleased build: imaj hiçbir sürümde yoktur, örneğin henüz sürüm yapılmamış bir Build. Development: Run ile başlatılan geliştirme runtime’ı. Sürüm listesi okunana kadar — görünür. |
| CPU / Memory | Ölçüm bulunuyorsa kaynak kullanımı. —, sıfır tüketim veya limitsiz çalışma demek değildir. |
Birden fazla paketlenmiş pod satırı, Deployment’ın birden fazla replica’sını veya güncelleme sırasında birlikte bulunan podlarını gösterebilir. Her satırın Version ve Status değerini kontrol edin; yalnız ilk çalışan podu görmek tüm güncellemenin tamamlandığını kanıtlamaz.
No pods, proje dosyalarının olmadığı anlamına gelmez. Kaynakların kaydedilmesi pod başlatmaz. CPU/RAM limitini kullanım sütunundan değiştiremezsiniz; kaynak ayarları ayrı yönetilir.
Run, Delete container ve dağıtım işlemleri
| İşlem | Kapsamı |
|---|---|
| Proje başlığındaki Run | Kaydedilmiş kaynaklardan geliştirme runtime’ını başlatır; gerçek girişler ve dış bağlantılar çalışabilir. |
| Reload | Sunulduğunda kaydedilmiş kaynakları çalışan geliştirme runtime’ına aktarır. |
| Delete container | Geliştirme runtime’ını kaldırır. Proje dosyaları, Git geçmişi ve dış veritabanı kayıtları kalır. |
| Build → Delete build | Builder çalışma kaynağını kaldırır. Registry imajını veya çalışan Deployment’ı geri almaz. |
| Deployment → Releases → Deploy | Seçilen sürümü bu ortama dağıtır; mevcut Deployment’ı silmeden günceller. Başarısız rollout’ta son başarılı paketi geri yükler. |
| Deployment → Restart | Mevcut Deployment podlarını aynı paketle yeniden başlatır. Yeni podlar hazır olup eskiler durana kadar ilerleme gösterir; başarısızlıkta Kubernetes’in nedenini bildirir. Yeni commit’i derlemez veya değiştirilmiş manifesti uygulamaz. |
| Deployment → Undeploy | Yayınlanmış API rotalarını, parça nesneleri dahil paketin tüm nesnelerini ve ortamın sürüm kaydını kaldırır. Sürümler Git’te kalır. Run ve build podlarına, yöneticilerin nesnelerine dokunmaz. |
Yanlış runtime’ı sonlandırmamak için Version sütunu Development olan geliştirme podunu paketlenmiş podlardan önce ayırın. Kubernetes’te sonlandırılan bir packaged pod Deployment tarafından yeniden oluşturulabilir; kalıcı dağıtımın yaşam döngüsünü Deployment üzerinden yönetin. Restart, Undeploy, Create release ve Deploy yalnız platform-developer rolüne görünür; diğer kullanıcılar sekmeyi salt okunur görür. Ayrıntılı prosedür çalıştırma ve dağıtım sayfasındadır.
Pod olayları: başlangıcı okuyun
- Runtime tablosunda araştırdığınız podun satırını genişletin (Events of
<pod>). - Reason, Message ve Time alanlarını birlikte okuyun. Time yerel saattir; ISO değeri ipucundadır.
- Tek bir eski uyarı yerine, daha sonraki olayın sorunu çözüp çözmediğine ve podun güncel Status değerine bakın.
Örneğin bir imaj çekme hatasından sonra başarılı çekme/başlama kaydı görülebilir. Bunun tersine pod ayakta olsa bile runtime bağımlılık veya bağlantı hatası verebilir; o durumda Log’a geçin.
| Belirti / neden | İlk kontrol |
|---|---|
ErrImagePull / ImagePullBackOff | Image adı ve tag, registry erişimi, node’un çekme yetkisi. |
FailedScheduling | CPU/RAM isteği, namespace kotası ve uygun node kapasitesi. |
| Secret/volume bağlama hatası | Message içindeki kaynak ve key adı; doğru namespace’te bulunması. |
CrashLoopBackOff veya sürekli yeniden başlama | Uygulamanın ilk hata nedeni için Log; kapasite ve çalışma ayarları. |
OOMKilled | Bellek limiti, JVM ve mesaj yükü; kaynak rehberi. Bu neden podun Status değerinde görülebilir. |
Kubernetes reports no events for this pod., pod için olay bulunmadığını belirtir; sağlıklı olduğu sonucunu tek başına vermez. Could not load pod events durumunda Retry loading pod events kullanın. Olaylar satır genişletildiğinde yüklenir; yeniden bakmanız gerektiğinde satırı kapatıp yeniden genişletin.
Log: uygulama çıktısını takip edin
- Log sekmesinde doğru container’ı seçin. Geliştirme çıktısını incelemekle packaged runtime’ı incelemek farklıdır.
- Başlangıç tamamlanmış mı, route’lar açılmış mı, bağımlılık veya bağlantı hatası var mı kontrol edin.
- Aramaya en az dört karakter yazın; örneğin
A-100veya bir hata sınıfı. - Enter veya Next match ile eşleşen satırlara ilerleyin.
| Kontrol | Etkisi |
|---|---|
| Search logs | Yüklenmiş satırlarda büyük/küçük harf duyarsız arama yapar; bütün geçmişi sunucuda taramaz. |
| Next match (n) | Eşleşen satırlarda ilerler. Eşleşmeye giderken Autoscroll kapanır. |
| Wrap text | Uzun satırları görünür genişlikte sarar; log içeriğini değiştirmez. |
| Autoscroll | Yeni satır geldikçe en alta ilerler. Eski hata satırını okumak için kapatın. |
| Jump to bottom | Görünen çıktının sonuna gider; tek başına sürekli takip ayarı değildir. |
| Clear log | Ekrandaki tamponu temizler; uygulama dosyalarını veya Message Monitor kayıtlarını silmez. |
Kubernetes log bağlantısı son satırlarla başlar ve yeni çıktıyı izler; sınırsız geçmiş arşivi değildir. Container değiştirildiğinde gösterilen tampon da değişir. Eski podun kapanmadan önceki tüm çıktısı gerekiyorsa işletim ekibinizin merkezi log sistemini veya Kubernetes günlük araçlarını kullanın.
Waiting for log output…, henüz satır gelmediğini gösterir. Önce container seçimini ve podun durumunu, ardından Deployment’taki pod olaylarını kontrol edin. Bir istisnada yalnız son özet satırını değil, ilk hata ve Caused by nedenini birlikte okuyun.
Log level hangi kaydı değiştirir?
Proje başlığındaki Log level, Message Monitor kayıt seviyesini yönetir. Console çıktısındaki bütün Java logger seviyelerini topluca değiştirmez. Normal başarılı mesajların izleme kaydı için Info; süreli ayrıntı için uygun yetkiyle Debug / Trace kullanılır.
Trace süresi, body kaydı, erişim ve saklama kuralları kayıt seviyeleri rehberindedir. Clear log bu kayıtları temizlemez. Logger adımındaki Log Language ise log mesajının ifadesini nasıl değerlendireceğini belirler; iki alanın görevi farklıdır.
Örnek bir sorunu uçtan uca ayırın
“Yeni kod görünmüyor” durumunda önce sürüm dağıtımındaki kaydetme, commit ve sürüm zincirini kontrol edin. Version sütunu beklediğiniz sürümü gösteriyor fakat pod başlamıyorsa pod olaylarına; pod çalışıyor fakat route açılmıyorsa başlangıç Log’una; route çalışıyor fakat bir sipariş hata alıyorsa Message Monitor’daki ilgili run’a geçin.
Sorun kaydına proje/ortamı, pod adını, Version değerini, zamanı ve ilk hata nedenini ekleyin. Böylece kaynak sürümü, başlatma ve iş mesajı sorunları birbirinden ayrılabilir.