Cluster sayısı operasyonu anlatmaya yetmez
Üç Kubernetes cluster’ınız, onlarca node’unuz ve yüzlerce Pod’unuz olabilir. Ancak bir fiziksel sunucu bakımının hangi müşteri hizmetini etkileyebileceğini bu sayılardan çıkaramazsınız. Teknik envanterin amacı yalnızca nesneleri saymak değil; uygulamanın nerede çalıştığını, hangi veriye ve ağ yoluna ihtiyaç duyduğunu açıklamaktır. Burada önerdiğimiz model, kaynak API’lerinden doğrulanabilen ilişkilerle hizmet sahibinin tanımladığı iş bağımlılıklarını bir araya getirir. Üretim ve test ortamları aynı isimleri kullansa bile birbirinden ayrılmalıdır.
Kimlik: cluster kapsamı, namespace ve UID
Kayıt anahtarını yalnızca nesne adına veya IP adresine bağlamayın. Cluster’a kurum içinde kalıcı bir kaynak kimliği verin; nesnenin türünü, namespace’ini, adını ve metadata.uid değerini koruyun. Aynı adla yeniden oluşturulan Pod yeni bir nesnedir. Namespace kapsamı olmayan Node ve PersistentVolume gibi kaynakları da modelleyin. Önerilen kayıtta son görülme zamanı, kaynak erişim durumu ve yaşam döngüsü bulunmalıdır. Bir API sorgusunun başarısız olması, daha önce görülen bütün nesnelerin silindiği anlamına gelmez.
Deployment, ReplicaSet ve Pod ilişkisini doğru okuyun
Deployment tarafından yönetilen tipik bir iş yükünde Deployment, ReplicaSet ve Pod zinciri bulunur. ownerReferences bu sahiplik ilişkisinin kaynağıdır; etiket benzerliği tek başına aynı kanıtı sağlamaz. StatefulSet, DaemonSet ve Job gibi denetleyicilerin yaşam döngüleri farklıdır. Bu nedenle bütün Pod’ları bir Deployment altında toplamaya çalışmayın. Pod’un spec.nodeName alanı atandığı node’u gösterir; henüz atanmamış Pod için fiziksel konum üretmeyin. Uygulamanın kurumsal hizmet sahibi ise Kubernetes sahiplik referansından ayrı bir bilgidir.
Service ile çalışan uçları birbirine karıştırmayın
Service, uygulamaya erişim için bir soyutlamadır; Pod’un sahibi değildir. Seçicili Service’lerde selector ve EndpointSlice bilgisi, hedeflerle ilişki kurmaya yardımcı olur. Selector içermeyen Service’ler de bulunduğundan her Service’i otomatik olarak Pod listesine eşlemeyin. Dış erişimde Ingress veya Gateway, bunları işleten denetleyici ve varsa yük dengeleyici ayrıca değerlendirilir. Envanterde görünen hedef, başarılı bir kullanıcı isteğinin kanıtı değildir. Hazır olma durumu, DNS çözümleme ve uygulama kontrolü farklı gözlemlerdir.
PVC ve PV fiziksel diske kadar ne anlatır?
PersistentVolumeClaim uygulamanın depolama talebini, PersistentVolume ise bağlanan depolama kaynağını temsil eder. Pod’un volume tanımı ile PVC, ardından bağlı PV üzerinden ilişki kurabilirsiniz. StorageClass sağlama yaklaşımını açıklar; fiziksel disk değildir. CSI kullanılan ortamlarda sürücü ve volumeHandle bilgisi, depolama sağlayıcısındaki kaydı eşleştirmek için başlangıç olabilir. Gerçek storage sistemi, havuz ve disk ilişkileri için ek kaynak gerekir. Bu zincir doğrulanmadan bir PVC’nin belirli bir fiziksel diskte bulunduğunu söylemek yanıltıcıdır.
Node’dan sanal makineye ve fiziksel host’a geçiş
Bir node fiziksel sunucu üzerinde veya sanal makine içinde çalışabilir. Sağlayıcı kimliği mevcut ve güvenilir olduğunda VM kaydıyla eşleştirme için kullanılabilir; hostname veya IP benzerliğini kesin kimlik kabul etmeyin. VM’nin güncel hypervisor host’u, host’un fiziksel sunucusu, kabini ve ağ bağlantıları ayrı ilişkiler olarak tutulmalıdır. Taşıma sonrası eski host bağlantısının güncellenmesi gerekir. Yönetilen Kubernetes hizmetlerinde fiziksel katmanın kuruma görünmediği durumlarda sınırı açıkça gösterin; bilinmeyen altyapıyı hayalî kayıtlarla tamamlamayın.
Örnek: üç replika neden tek arızadan etkilenebilir?
Örnek bir ödeme servisinin üç Pod’u üç ayrı node üzerinde çalışsın. Node’ların tamamı aynı fiziksel host üzerindeki VM’lerse, Pod sayısı fiziksel hata alanı çeşitliliğini garanti etmez. Ortak storage veya tek ağ cihazı da benzer bir bağımlılık oluşturabilir. İnceleme sırasında Pod dağılımını, VM yerleşimini ve ortak altyapıyı birlikte karşılaştırın. Bu senaryo bir kesinti tahmini değil, doğrulanacak risk sorusudur. Uygulama replikasyonu, yedekleme ve yeniden başlatma davranışı ayrıca değerlendirilmelidir.
Toplama kapsamı ve kabul testi nasıl tanımlanmalı?
Envanter için gereken kaynak türlerini ve salt okunur yetkileri açıkça belirleyin; Secret içeriklerini veya gereksiz uygulama verilerini toplama kapsamına almayın. Kısa ömürlü Pod’lar periyodik iki gözlem arasında oluşup kaybolabilir; bu nedenle periyodik envanteri eksiksiz olay günlüğü diye sunmayın. Kabul testinde yeniden oluşturulan Pod’u, değişen node yerleşimini ve erişilemeyen cluster’ı ayrı ayrı deneyin. Başarı ölçütü yalnızca nesne sayısı değil, kimliğin ve ilişkinin doğru korunması olmalıdır.
Argamos ile hizmet bağlamını kurun
Argamos’un envanter ve CMDB yaklaşımı, kaynak gözlemlerini yönetilen varlık, sahiplik ve hizmet ilişkileriyle birleştirir. Kubernetes değerlendirmesinde ilk olarak bir kritik hizmeti, onun workload’larını ve altyapı sınırını seçin. Kaynak erişimi atanmış Edge Runtime üzerinden ele alınır; toplama kapsamı ve periyot merkezden yönetilir. Kubernetes sürümü, API izinleri ve nesne kapsamı entegrasyon değerlendirmesinde doğrulanmalıdır. Bu rehberin modelini, her nesnenin ve fiziksel bağlantının hazır bir bağlayıcıyla otomatik keşfedildiği iddiası olarak değerlendirmeyin.
Envanter modeli: hızlı başvuru
| Katman / kayıt | Tutulacak bilgi | Operasyonel anlam |
|---|---|---|
| Nesne kimliği | Cluster kaynak kimliği + kind + UID; namespace ve ad | Aynı adın yeni nesneyle karışmasını önler |
| İş yükü sahipliği | ownerReferences; denetleyici türü | Sahiplik ile trafik bağımlılığını ayırır |
| Çalışma konumu | Pod.spec.nodeName; doğrulanmış node–VM eşlemesi | Fiziksel etki alanını incelemeyi sağlar |
| Depolama | PVC → PV; varsa CSI sürücüsü ve volumeHandle | Sağlayıcı envanteriyle doğrulanacak sınırı gösterir |
Teknik kaynaklar
Platform kavramları için resmî dokümantasyon. Kurulumunuzun sürümü ve erişim kapsamıyla birlikte değerlendirin.