Anyscale Connect, KubeRay’e gözlem ve iş gönderme özellikleri ekliyor

Anyscale, mevcut KubeRay kümelerine iş gözlemi ve gönderme özellikleri ekleyen KubeRay Connect’i özel önizlemeye açtı. Operatörler mevcut KubeRay yapılandırmalarını ve araçlarını koruyarak Ray işlerinin durumunu izleyebiliyor.

Anyscale, 25 Ağustos 2026 tarihli duyurusunda Connect’in mevcut KubeRay kümelerine bağlandığını belirtti. Connect, işleri çalıştırmak için pod’ları doğrudan oluşturup yönetmiyor; KubeRay’in kümeyi yönettiği yapıya Anyscale özellikleri ekliyor. Şirketin belgelerinde de Connect’in Ray kümelerini doğrudan oluşturmadığı veya yönetmediği açıklanıyor.

Duyuru sırasında iş günlükleriyle metriklerini gösteren Observe ve iş gönderme ile durum takibini sağlayan Orchestrate özel önizleme aşamasındaydı. Performans ve maliyet ayarlarına yönelik Optimize ise yakında sunulacak olarak listelendi. Özel önizlemeye erişmek için başvuru gerekiyor.

Connect, mevcut KubeRay yapılandırmasına gözlemleme amaçlı bir sidecar ekliyor. Bileşenler arasında KubeRay özel kaynaklarını (CR) değiştiren ve durumlarını eşitleyen Connector, günlüklerle metrikleri toplayan OpenTelemetry Collector tabanlı Cluster Telemetry Gateway ve gözlem verilerini konsola sunan Observability API bulunuyor. Anyscale, duyuru sırasında Connector’ın tek bir pod olarak çalıştığını belirtti.

Ray’in resmi belgelerine göre günlükler varsayılan olarak her pod’daki /tmp/ray/session_*/logs dizininde saklanıyor ve Ray kendi başına bir günlük saklama hizmeti sunmuyor. Pod veya düğüm beklenmedik biçimde sonlandıktan sonra sorunun nedenini araştırmak için ayrı bir günlük toplama ve saklama çözümü gerekiyor.

Anyscale aynı gün GPU Health Observability’yi de özel önizlemeye açtığını duyurdu. Şirket, GPU’ların XID ve ECC hatalarıyla saat hızı ve bellek durumunu Ray işleri ve düğüm bilgileriyle ilişkilendirerek gösterdiğini açıkladı. Gerçek çalışma ortamlarında arıza teşhis süresinin veya kullanılabilirliğin ne ölçüde değişeceğine dair bir veri paylaşmadı.

Ray’in KubeRay otomatik ölçekleyicisi, işlerin ve aktörlerin kaynak talebine göre Ray pod’larının sayısını ayarlıyor. Bu ölçüt, CPU ve bellek kullanım oranlarını esas alan standart Kubernetes HPA’dan farklı. Ray belgeleri, GPU ve bellek için kaynak istekleriyle limitlerinin mümkün olduğunca aynı ayarlanmasını öneriyor.

Varsayılan ayarlarda head düğümü tek hata noktası oluşturuyor. Ray, küme otomatik ölçekleyicisinin düğüm birleştirme sürecinde head pod’unun tahliye edilmesini önleyecek ayarları açıklıyor; ancak bu ayarın düğüm arızalarını önlemediğini de belirtiyor.

Ray belgelerine göre GCS hata toleransı yapılandırıldığında Serve uygulamaları, head düğümü kurtarılırken de istekleri işleyebiliyor. Ancak kurtarma süresince aktör ve worker arızalarına müdahale ile kümenin güncellenmesi sınırlanabiliyor.