Düğüm ve pod durumunu inceleme

Bu makale, bir serinin bir parçasıdır. Genel bakış ile başlayın.

Küme, önceki adımda gerçekleştirdiğiniz işlemlerin temiz olup olmadığını denetlerse Azure Kubernetes Service (AKS) çalışan düğümlerinin durumunu denetleyin. Düğümlerin durumunu denetlemek, iyi durumda olmayan bir düğümün nedenini belirlemek ve sorunu çözmek için bu makaledeki altı adımı izleyin.

1. Adım: Çalışan düğümlerinin durumunu denetleme

Aks kümesindeki iyi durumda olmayan düğümlere çeşitli faktörler katkıda bulunabilir. Yaygın nedenlerden biri, kontrol düzlemi ile düğümler arasındaki iletişimin dökümüdür. Bu yanlış iletişim genellikle yönlendirme ve güvenlik duvarı kurallarındaki yanlış yapılandırmalardan kaynaklanır.

AKS kümenizi kullanıcı tanımlı yönlendirme için yapılandırırken, çıkış yollarını bir ağ sanal gereci (NVA) veya Azure güvenlik duvarı gibi bir güvenlik duvarı aracılığıyla yapılandırmanız gerekir. Yanlış yapılandırma sorununu gidermek için güvenlik duvarını AKS çıkış trafiği kılavuzuna uygun olarak gerekli bağlantı noktalarına ve tam etki alanı adlarına (FQDN) izin verecek şekilde yapılandırmanızı öneririz.

İyi durumda olmayan düğümlerin bir diğer nedeni de kubelet baskıları oluşturan yetersiz işlem, bellek veya depolama kaynakları olabilir. Bu gibi durumlarda, kaynakların ölçeğini artırmak sorunu etkili bir şekilde çözebilir.

Özel aks kümesinde Etki Alanı Adı Sistemi (DNS) çözümleme sorunları, denetim düzlemi ile düğümler arasında iletişim sorunlarına neden olabilir. Kubernetes API sunucusu DNS adının API sunucusunun özel IP adresine çözümlendiğini doğrulamanız gerekir. Özel DNS sunucusunun yanlış yapılandırılması, DNS çözümleme hatalarının yaygın bir nedenidir. Özel DNS sunucuları kullanıyorsanız, bunları düğümlerin sağlandığı sanal ağda DNS sunucuları olarak doğru belirttiğinizden emin olun. Ayrıca AKS özel API sunucusunun özel DNS sunucusu aracılığıyla çözümlenebileceğini onaylayın.

Denetim düzlemi iletişimi ve DNS çözümlemesi ile ilgili bu olası sorunları giderdikten sonra AKS kümenizdeki düğüm durumu sorunlarını etkili bir şekilde ele alabilir ve çözebilirsiniz.

Aşağıdaki yöntemlerden birini kullanarak düğümlerinizin durumunu değerlendirebilirsiniz.

Azure İzleyici kapsayıcılarının sistem durumu görünümü

AKS kümenizdeki düğümlerin, kullanıcı podlarının ve sistem podlarının durumunu görüntülemek için şu adımları izleyin:

1. Azure portalında Azure İzleyici'ye gidin.
2. Gezinti bölmesinin Analizler bölümünde Kapsayıcılar'ı seçin.
3. İzlenen AKS kümelerinin listesi için İzlenen kümeler'i seçin.
4. Düğümlerin, kullanıcı podlarının ve sistem podlarının durumunu görüntülemek için listeden bir AKS kümesi seçin.

AKS düğümleri görünümü

AKS kümenizdeki tüm düğümlerin hazır durumda olduğundan emin olmak için şu adımları izleyin:

1. Azure portalında AKS kümenize gidin.
2. Gezinti bölmesinin Ayarlar bölümünde Düğüm havuzları'nı seçin.
3. Düğümler'i seçin.
4. Tüm düğümlerin hazır durumda olduğunu doğrulayın.

Prometheus ve Grafana ile küme içi izleme

AKS kümenizde Prometheus ve Grafana'yı dağıttıysanız içgörüler elde etmek için K8 Küme Ayrıntı Panosu'nu kullanabilirsiniz. Bu pano Prometheus kümesi ölçümlerini gösterir ve CPU kullanımı, bellek kullanımı, ağ etkinliği ve dosya sistemi kullanımı gibi önemli bilgileri sunar. Ayrıca tek tek podlar, kapsayıcılar ve sistemli hizmetler için ayrıntılı istatistikler gösterir.

Kümenizin sistem durumu ve performansı hakkındaki ölçümleri görmek için panoda Düğüm koşulları'nı seçin. Zamanlamasıyla ilgili sorunlar, ağ, disk baskısı, bellek baskısı, orantılı integral türevi (PID) baskısı veya disk alanı gibi sorunları olabilecek düğümleri izleyebilirsiniz. AKS kümenizin kullanılabilirliğini ve performansını etkileyen olası sorunları önceden belirleyip çözebilmeniz için bu ölçümleri izleyin.

Prometheus ve Azure Yönetilen Grafana için yönetilen hizmeti izleme

Prometheus ölçümlerini görselleştirmek ve analiz etmek için önceden oluşturulmuş panoları kullanabilirsiniz. Bunu yapmak için AKS kümenizi Prometheus için yönetilen hizmeti izleme bölümünde Prometheus ölçümlerini toplayacak şekilde ayarlamanız ve İzleyici çalışma alanınızı Azure Yönetilen Grafana çalışma alanına bağlamanız gerekir. Bu panolar Kubernetes kümenizin performansına ve durumuna yönelik kapsamlı bir görünüm sağlar.

Panolar, Yönetilen Prometheus klasöründe belirtilen Azure Yönetilen Grafana örneğinde sağlanır. Bazı panolar şunlardır:

• Kubernetes / İşlem Kaynakları / Küme
• Kubernetes / İşlem Kaynakları / Ad Alanı (Podlar)
• Kubernetes / İşlem Kaynakları / Düğüm (Podlar)
• Kubernetes / İşlem Kaynakları / Pod
• Kubernetes / İşlem Kaynakları / Ad Alanı (İş Yükleri)
• Kubernetes / İşlem Kaynakları / İş Yükü
• Kubernetes / Kubelet
• Düğüm Verme / USE Yöntemi / Düğüm
• Düğüm Verme / Düğümler
• Kubernetes / İşlem Kaynakları / Küme (Windows)
• Kubernetes / İşlem Kaynakları / Ad Alanı (Windows)
• Kubernetes / İşlem Kaynakları / Pod (Windows)
• Kubernetes / USE Yöntemi / Küme (Windows)
• Kubernetes / USE Yöntemi / Node (Windows)

Bu yerleşik panolar, Prometheus ve Grafana ile Kubernetes kümelerini izlemek için açık kaynak topluluğunda yaygın olarak kullanılır. Kaynak kullanımı, pod durumu ve ağ etkinliği gibi ölçümleri görmek için bu panoları kullanın. ayrıca izleme gereksinimlerinize göre uyarlanmış özel panolar da oluşturabilirsiniz. Panolar AKS kümenizdeki Prometheus ölçümlerini etkili bir şekilde izlemenize ve çözümlemenize yardımcı olur. Bu sayede performansı iyileştirebilir, sorunları giderebilir ve Kubernetes iş yüklerinizin sorunsuz çalışmasını sağlayabilirsiniz.

Linux aracı düğümlerinizin ölçümlerini görmek için Kubernetes / İşlem Kaynakları / Düğüm (Podlar) panosunu kullanabilirsiniz. Her pod için CPU kullanımını, CPU kotasını, bellek kullanımını ve bellek kotasını görselleştirebilirsiniz.

Kümeniz Windows aracı düğümleri içeriyorsa, bu düğümlerden toplanan Prometheus ölçümlerini görselleştirmek için Kubernetes / USE Yöntemi / Düğüm (Windows) panosunu kullanabilirsiniz. Bu pano, kümenizdeki Windows düğümleri için kaynak tüketiminin ve performansının kapsamlı bir görünümünü sağlar.

Hem Linux hem de Windows aracı düğümlerindeki CPU, bellek ve diğer kaynaklarla ilgili önemli ölçümleri kolayca izleyebilmek ve analiz etmek için bu ayrılmış panolardan yararlanın. Bu görünürlük olası performans sorunlarını belirlemenize, kaynak ayırmayı iyileştirmenize ve AKS kümeniz genelinde verimli bir işlem gerçekleştirmenize olanak tanır.

2. Adım: Denetim düzlemi ve çalışan düğümü bağlantısını doğrulama

Çalışan düğümleri iyi durumdaysa, yönetilen AKS denetim düzlemi ile küme çalışan düğümleri arasındaki bağlantıyı incelemeniz gerekir. AKS, güvenli bir tünel iletişim yöntemi aracılığıyla Kubernetes API sunucusu ile tek düğüm kubelet'leri arasında iletişim sağlar. Bu bileşenler farklı sanal ağlarda olsalar bile iletişim kurabilir. Tünel, Karşılıklı Aktarım Katmanı Güvenliği (mTLS) şifrelemesi ile korunur. AKS'nin kullandığı birincil tünel Konnectivity (eski adıyla apiserver-network-proxy) olarak adlandırılır. Tüm ağ kurallarının ve FQDN'lerin gerekli Azure ağ kurallarına uygun olduğundan emin olun.

Yönetilen AKS denetim düzlemi ile AKS kümesinin küme çalışan düğümleri arasındaki bağlantıyı doğrulamak için kubectl komut satırı aracını kullanabilirsiniz.

Konnectivity aracı podlarının düzgün çalıştığından emin olmak için aşağıdaki komutu çalıştırın:

kubectl get deploy konnectivity-agent -n kube-system

Podların hazır durumda olduğundan emin olun.

Denetim düzlemi ile çalışan düğümleri arasındaki bağlantıyla ilgili bir sorun varsa, gerekli AKS çıkış trafiği kurallarına izin verildiğinden emin olduktan sonra bağlantıyı kurun.

Podları yeniden başlatmak konnectivity-agent için aşağıdaki komutu çalıştırın:

kubectl rollout restart deploy konnectivity-agent -n kube-system

Podların yeniden başlatılması bağlantıyı düzeltmezse anomali olup olmadığını kontrol edin. Podların günlüklerini konnectivity-agent görüntülemek için aşağıdaki komutu çalıştırın:

kubectl logs -l app=konnectivity-agent -n kube-system --tail=50

Günlükler aşağıdaki çıkışı göstermelidir:

I1012 12:27:43.521795       1 options.go:102] AgentCert set to "/certs/client.crt".
I1012 12:27:43.521831       1 options.go:103] AgentKey set to "/certs/client.key".
I1012 12:27:43.521834       1 options.go:104] CACert set to "/certs/ca.crt".
I1012 12:27:43.521837       1 options.go:105] ProxyServerHost set to "sethaks-47983508.hcp.switzerlandnorth.azmk8s.io".
I1012 12:27:43.521841       1 options.go:106] ProxyServerPort set to 443.
I1012 12:27:43.521844       1 options.go:107] ALPNProtos set to [konnectivity].
I1012 12:27:43.521851       1 options.go:108] HealthServerHost set to
I1012 12:27:43.521948       1 options.go:109] HealthServerPort set to 8082.
I1012 12:27:43.521956       1 options.go:110] AdminServerPort set to 8094.
I1012 12:27:43.521959       1 options.go:111] EnableProfiling set to false.
I1012 12:27:43.521962       1 options.go:112] EnableContentionProfiling set to false.
I1012 12:27:43.521965       1 options.go:113] AgentID set to b7f3182c-995e-4364-aa0a-d569084244e4.
I1012 12:27:43.521967       1 options.go:114] SyncInterval set to 1s.
I1012 12:27:43.521972       1 options.go:115] ProbeInterval set to 1s.
I1012 12:27:43.521980       1 options.go:116] SyncIntervalCap set to 10s.
I1012 12:27:43.522020       1 options.go:117] Keepalive time set to 30s.
I1012 12:27:43.522042       1 options.go:118] ServiceAccountTokenPath set to "".
I1012 12:27:43.522059       1 options.go:119] AgentIdentifiers set to .
I1012 12:27:43.522083       1 options.go:120] WarnOnChannelLimit set to false.
I1012 12:27:43.522104       1 options.go:121] SyncForever set to false.
I1012 12:27:43.567902       1 client.go:255] "Connect to" server="e9df3653-9bd4-4b09-b1a7-261f6104f5d0"

Not

AKS kümesi api sunucusu sanal ağ tümleştirmesi ve Azure kapsayıcı ağ arabirimi (CNI) veya dinamik pod IP ataması olan bir Azure CNI ile ayarlandığında Konnectivity aracılarının dağıtılmasına gerek yoktur. Tümleşik API sunucu podları, özel ağ aracılığıyla küme çalışan düğümleriyle doğrudan iletişim kurabilir.

Ancak, Azure CNI Katmanı ile API sunucusu sanal ağ tümleştirmesi kullandığınızda veya kendi CNI'nizi (BYOCNI) getirdiğinizde, API sunucuları ile pod IP'leri arasındaki iletişimi kolaylaştırmak için Konnectivity dağıtılır. API sunucuları ve çalışan düğümleri arasındaki iletişim doğrudan kalır.

Günlükleri almak için günlük ve izleme hizmetindeki kapsayıcı günlüklerinde de arama yapabilirsiniz. Aks-link bağlantı hatalarını arayan bir örnek için bkz. Kapsayıcı içgörülerinden günlükleri sorgulama.

Günlükleri almak için aşağıdaki sorguyu çalıştırın:

ContainerLogV2 
| where _ResourceId =~ "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedClusters/<cluster-ID>" // Use the IDs and names of your resources for these values.
| where ContainerName has "aks-link"
| project LogSource,LogMessage, TimeGenerated, Computer, PodName, ContainerName, ContainerId
| order by TimeGenerated desc
| limit 200

Belirli bir ad alanında başarısız olan podlar için kapsayıcı günlüklerinde arama yapmak için aşağıdaki sorguyu çalıştırın:

let KubePodInv = KubePodInventory
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where _ResourceId =~ "<cluster-resource-ID>" // Use your resource ID for this value.
    | where Namespace == "<pod-namespace>" // Use your target namespace for this value.
    | where PodStatus == "Failed"
    | extend ContainerId = ContainerID
    | summarize arg_max(TimeGenerated, *)  by  ContainerId, PodStatus, ContainerStatus
    | project ContainerId, PodStatus, ContainerStatus;

    KubePodInv
    | join
    (
        ContainerLogV2
    | where TimeGenerated >= startTime and TimeGenerated < endTime
    | where PodNamespace == "<pod-namespace>" //update with target namespace
    ) on ContainerId
    | project TimeGenerated, PodName, PodStatus, ContainerName, ContainerId, ContainerStatus, LogMessage, LogSource

Sorguları veya kubectl aracını kullanarak günlükleri alamıyorsanız Secure Shell (SSH) kimlik doğrulamasını kullanın. Bu örnek, düğüme SSH aracılığıyla bağlandıktan sonra tunnelfront podunu bulur.

kubectl pods -n kube-system -o wide | grep tunnelfront
ssh azureuser@<agent node pod is on, output from step above>
docker ps | grep tunnelfront
docker logs …
nslookup <ssh-server_fqdn>
ssh -vv azureuser@<ssh-server_fqdn> -p 9000
docker exec -it <tunnelfront_container_id> /bin/bash -c "ping bing.com"
kubectl get pods -n kube-system -o wide | grep <agent_node_where_tunnelfront_is_running>
kubectl delete po <kube_proxy_pod> -n kube-system

3. Adım: Çıkışı kısıtlarken DNS çözümlemesini doğrulama

DNS çözümlemesi, AKS kümenizin önemli bir yönüdür. DNS çözümlemesi düzgün çalışmıyorsa, denetim düzlemi hatalarına veya kapsayıcı görüntüsü çekme hatalarına neden olabilir. Kubernetes API sunucusu için DNS çözümlemesinin düzgün çalıştığından emin olmak için şu adımları izleyin:

1. Kubectl exec komutunu çalıştırarak podda çalışan kapsayıcıda bir komut kabuğu açın.

   kubectl exec --stdin --tty your-pod --namespace <namespace-name> -- /bin/bash
   

2. Kapsayıcıda nslookup veya dig araçlarının yüklü olup olmadığını denetleyin.

3. Pod'da iki araç da yüklü değilse, aynı ad alanında bir yardımcı program pod'u oluşturmak için aşağıdaki komutu çalıştırın.

   kubectl run -i --tty busybox --image=busybox --namespace <namespace-name> --rm=true -- sh
   

4. API sunucusu adresini Azure portalındaki AKS kümenizin genel bakış sayfasından alabilir veya aşağıdaki komutu çalıştırabilirsiniz.

   az aks show --name <aks-name> --resource-group <resource-group-name> --query fqdn --output tsv
   

5. AKS API sunucusunu çözümlemeye çalışmak için aşağıdaki komutu çalıştırın. Daha fazla bilgi için bkz . Çalışan düğümünden değil, pod içinden DNS çözümleme hatalarını giderme.

   nslookup myaks-47983508.hcp.westeurope.azmk8s.io
   

6. DNS çözümlemesinin doğru çalışıp çalışmadığını belirlemek için poddan yukarı akış DNS sunucusunu denetleyin. Örneğin, Azure DNS için komutunu çalıştırın nslookup .

   nslookup microsoft.com 168.63.129.16
   

7. Önceki adımlar içgörü sağlamıyorsa, çalışan düğümlerinden birine bağlanın ve düğümden DNS çözümlemeyi deneme. Bu adım, sorunun AKS ile mi yoksa ağ yapılandırmasıyla mı ilgili olduğunu belirlemeye yardımcı olur.

8. DNS çözümlemesi düğümden başarılıysa ancak poddan değilse, sorun Kubernetes DNS ile ilgili olabilir. Poddan DNS çözümlemesinde hata ayıklama adımları için bkz . DNS çözümleme hatalarını giderme.

   DNS çözümlemesi düğümden başarısız olursa, DNS çözümlemesini kolaylaştırmak için uygun yönlendirme yollarının ve bağlantı noktalarının açık olduğundan emin olmak için ağ kurulumunu gözden geçirin.

4. Adım: Kubelet hatalarını denetleme

Her çalışan düğümünde çalışan kubelet işleminin koşulunu doğrulayın ve herhangi bir baskı altında olmadığından emin olun. Olası basınç CPU, bellek veya depolamayla ilgili olabilir. Tek düğüm kubelet'lerinin durumunu doğrulamak için aşağıdaki yöntemlerden birini kullanabilirsiniz.

AKS kubelet çalışma kitabı

Aracı düğümü kubelet'lerinin düzgün çalıştığından emin olmak için şu adımları izleyin:

1. Azure portalında AKS kümenize gidin.

2. Gezinti bölmesinin İzleme bölümünde Çalışma Kitapları'nı seçin.

3. Kubelet çalışma kitabını seçin.

   

4. İşlemler'i seçin ve tüm çalışan düğümleri için işlemlerin tamamlandığından emin olun.

   

Prometheus ve Grafana ile küme içi izleme

AKS kümenizde Prometheus ve Grafana'yı dağıttıysanız, tek düğüm kubelet'lerinin sistem durumu ve performansı hakkında içgörüler almak için Kubernetes / Kubelet panosunu kullanabilirsiniz.

Prometheus ve Azure Yönetilen Grafana için yönetilen hizmeti izleme

Çalışan düğümü kubelet'leri için Prometheus ölçümlerini görselleştirmek ve analiz etmek için Kubernetes / Kubelet önceden oluşturulmuş panosunu kullanabilirsiniz. Bunu yapmak için AKS kümenizi Prometheus için yönetilen hizmeti izleme bölümünde Prometheus ölçümlerini toplayacak şekilde ayarlamanız ve İzleyici çalışma alanınızı Azure Yönetilen Grafana çalışma alanına bağlamanız gerekir.

Bir kubelet yeniden başlatıldığında ve düzensiz, öngörülemeyen davranışlara neden olduğunda basınç artar. Hata sayısının sürekli olarak artmadığından emin olun. Ara sıra bir hata kabul edilebilir, ancak sürekli büyüme, araştırmanız ve çözmeniz gereken temel bir sorunu gösterir.

5. Adım: Düğüm durumunu denetlemek için düğüm sorun algılayıcısı (NPD) aracını kullanın

NPD , düğümle ilgili sorunları tanımlamak ve bildirmek için kullanabileceğiniz bir Kubernetes aracıdır. Küme içindeki her düğümde sistemli bir hizmet olarak çalışır. CPU kullanımı, disk kullanımı ve ağ bağlantısı durumu gibi ölçümleri ve sistem bilgilerini toplar. Bir sorun algılandığında, NPD aracı olaylar ve düğüm koşulu hakkında bir rapor oluşturur. AKS'de NPD aracı, Azure bulutunda barındırılan bir Kubernetes kümesindeki düğümleri izlemek ve yönetmek için kullanılır. Daha fazla bilgi için bkz . AKS düğümlerinde NPD.

6. Adım: Azaltma için disk G/Ç işlemlerini saniye başına denetleme (IOPS)

IOPS'nin kısıtlanmadığından ve AKS kümenizdeki hizmetleri ve iş yüklerini etkilemediğinden emin olmak için aşağıdaki yöntemlerden birini kullanabilirsiniz.

AKS düğüm diski G/Ç çalışma kitabı

AKS kümenizdeki çalışan düğümlerinin disk G/Ç ile ilgili ölçümlerini izlemek için düğüm diski G/Ç çalışma kitabını kullanabilirsiniz. Çalışma kitabına erişmek için şu adımları izleyin:

1. Azure portalında AKS kümenize gidin.

2. Gezinti bölmesinin İzleme bölümünde Çalışma Kitapları'nı seçin.

3. Düğüm Diski GÇ çalışma kitabını seçin.

   

4. G/Ç ile ilgili ölçümleri gözden geçirin.

   

Prometheus ve Grafana ile küme içi izleme

AKS kümenizde Prometheus ve Grafana'yı dağıttıysanız, küme çalışan düğümleri için disk G/Ç hakkında içgörüler elde etmek için USE Yöntemi /Düğüm panosunu kullanabilirsiniz.

Prometheus ve Azure Yönetilen Grafana için yönetilen hizmeti izleme

Çalışan düğümlerinden disk G/Ç ile ilgili ölçümleri görselleştirmek ve analiz etmek için Node Exporter / Nodes önceden oluşturulmuş panosunu kullanabilirsiniz. Bunu yapmak için AKS kümenizi Prometheus için yönetilen hizmeti izleme bölümünde Prometheus ölçümlerini toplayacak şekilde ayarlamanız ve İzleyici çalışma alanınızı Azure Yönetilen Grafana çalışma alanına bağlamanız gerekir.

IOPS ve Azure diskleri

Fiziksel depolama cihazlarının bant genişliği ve işleyebileceği en fazla dosya işlemi sayısı bakımından doğal sınırlamaları vardır. Azure diskleri AKS düğümlerinde çalışan işletim sistemini depolamak için kullanılır. Diskler, işletim sistemiyle aynı fiziksel depolama kısıtlamalarına tabidir.

Aktarım hızı kavramını göz önünde bulundurun. Saniyede megabayt (MB/sn) cinsinden aktarım hızını belirlemek için ortalama G/Ç boyutunu IOPS ile çarpabilirsiniz. Büyük G/Ç boyutları, diskin sabit aktarım hızı nedeniyle daha düşük IOPS'ye çevrilir.

Bir iş yükü Azure disklerine atanan en yüksek IOPS hizmet sınırlarını aştığında, küme yanıt vermemeye başlar ve G/Ç bekleme durumuna geçebilir. Linux tabanlı sistemlerde ağ yuvaları, CNI, Docker ve ağ G/Ç'sini kullanan diğer hizmetler gibi birçok bileşen dosya olarak ele alınmaktadır. Sonuç olarak, disk okunamıyorsa, hata tüm bu dosyalara genişletir.

Aşağıdakiler dahil olmak üzere çeşitli olaylar ve senaryolar IOPS azaltmasını tetikleyebilir:

• Docker G/Ç işletim sistemi diskini paylaştığından, düğümlerde çalışan çok sayıda kapsayıcı.

• İşletim sistemi diskinde ek G/Ç işlemleri oluşturabilen güvenlik, izleme ve günlüğe kaydetme için kullanılan özel veya üçüncü taraf araçlar.

• İş yükünü yoğunlaştıran veya pod sayısını ölçeklendirin düğüm yük devretme olayları ve düzenli işler. Bu artan yük, azaltma oluşumları olasılığını artırarak G/Ç işlemleri sonuçlanana kadar tüm düğümlerin hazır olmayan bir duruma geçmesine neden olabilir.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

• Paolo Salvatori | Baş Müşteri Mühendisi
• Francis Simy Nazareth | Üst Düzey Teknik Uzman

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

• Sanal makine disk sınırları
• Sanal makineler ve disk performansı

İlgili kaynaklar

İş yükü dağıtımlarını izleme