Görev açısından kritik iş yükleri için sistem durumu modellemesi

Uygulamaların ve altyapının izlenmesi, tüm altyapı dağıtımlarının önemli bir parçasıdır. Görev açısından kritik bir iş yükü için izleme, dağıtımın kritik bir parçasıdır. Azure kaynaklarının uygulama durumunu ve önemli ölçümlerini izlemek, ortamın beklendiği gibi çalışıp çalışmadiğini anlamanıza yardımcı olur.

Bu ölçümleri tam olarak anlamak ve bir iş yükünün genel durumunu değerlendirmek için izlenen tüm verilerin bütünsel olarak anlaşılması gerekir. Sistem durumu modeli, ham ölçümler yerine iş yükünün durumunun net bir göstergesini görüntüleyerek genel sistem durumunun değerlendirilmesi konusunda yardımcı olabilir. Durum genellikle kırmızı, yeşil veya sarı gibi "trafik ışığı" göstergeleri olarak sunulur. Açık göstergelere sahip bir sistem durumu modelinin temsili, operatörün iş yükünün genel durumunu anlamasını ve ortaya çıkan sorunlara hızlı bir şekilde yanıt vermesini sezgisel hale getirir.

Sistem durumu modellemesi, görev açısından kritik dağıtım için aşağıdaki operasyonel görevlere genişletilebilir:

  • Uygulama Sistem Sağlığı Hizmeti - Bir damganın durumunu belirlemek için bir API sağlayan işlem kümesindeki uygulama bileşeni.

  • İzleme - Uygulama ve altyapının sistem durumunu ve performansını değerlendiren performans ve uygulama sayaçlarının toplanması.

  • Uyarı - Altyapı ve uygulamadaki sorunlar veya kesintiler için eyleme dönüştürülebilir uyarılar.

  • Hata analizi - Kök neden belgeleri de dahil olmak üzere tüm hataların dökümü ve analizi.

Bu görevler, görev açısından kritik altyapı için kapsamlı bir sağlık modeli oluşturur. Sistem durumu modelinin geliştirilmesi, görev açısından kritik herhangi bir dağıtımın kapsamlı ve ayrılmaz bir parçası olabilir ve olmalıdır.

Daha fazla bilgi için bkz . Azure'da görev açısından kritik iş yüklerinin sistem durumu modellemesi ve gözlemlenebilirliği.

Uygulama Sistem Sağlığı Hizmeti

Application Sistem Sağlığı Hizmeti (HealthService), işlem kümesindeki Katalog Hizmeti (CatalogService) ve Arka Plan İşlemcisi (BackgroundProcessor) ile birlikte bulunan bir uygulama bileşenidir. HealthService, damganın durumunu belirlemek üzere çağrı yapmak üzere Azure Front Door için bir REST API sağlar. HealthService, kendi bağımlılıklarına ek olarak bağımlılıkların durumunu yansıtan karmaşık bir bileşendir.

İşlem kümesi kapalı olduğunda sistem durumu hizmeti yanıt vermez. Hizmetler çalışır durumdayken altyapıda aşağıdaki bileşenlere yönelik düzenli denetimler gerçekleştirir:

  • Azure Cosmos DB'ye yönelik bir sorgu gerçekleştirmeye çalışır.

  • Event Hubs'a ileti göndermeye çalışır. İleti, arka plan çalışanı tarafından filtrelenmiş.

  • Depolama hesabında bir durum dosyası arar. Bu dosya, diğer denetimler düzgün çalışmaya devam ederken bile bir bölgeyi kapatmak için kullanılabilir. Bu dosya diğer işlemlerle iletişim kurmak için kullanılabilir. Örneğin damga, bakım amacıyla boşaltılacaksa, iyi durumda olmayan bir duruma zorlamak ve trafiği yeniden yönlendirmek için dosya silinebilir.

  • Tüm işletimsel ölçümlerin önceden belirlenmiş eşikler içinde olup olmadığını belirlemek için sistem durumu modelini sorgular. Sistem durumu modeli damganın iyi durumda olmadığını gösterdiğinde, HealthService'in gerçekleştirdiği diğer testler başarıyla döndürülse bile trafik damgaya yönlendirilmemelidir. Sistem Durumu Modeli, sistem durumunun daha eksiksiz bir görünümünü dikkate alır.

Tüm sistem durumu denetimi sonuçları, varsayılan olarak 10 saniye yapılandırılabilir bir süre için bellekte önbelleğe alınır. Bu işlem olası olarak kesintileri algılamada küçük bir gecikme süresi ekler, ancak her HealthService sorgusunun arka uç çağrıları gerektirmediğinden, küme ve aşağı akış hizmetlerindeki yükü azaltır.

Azure Front Door gibi genel bir yönlendirici kullanılırken HealthService sorgularının sayısı önemli ölçüde arttığı için bu önbelleğe alma düzeni önemlidir: İsteklere hizmet veren her Azure veri merkezindeki her kenar düğümü, işlevsel bir arka uç bağlantısı olup olmadığını belirlemek için Sistem Sağlığı Hizmeti çağırır. sonuçların Önbelleğe Alma sistem durumu denetimleri tarafından oluşturulan ek küme yükünü azaltır.

Yapılandırma

HealthService ve CatalogService, yalnızca HealthService tarafından kullanılan aşağıdaki ayarlar dışında bileşenler arasında ortak olan yapılandırma ayarlarına sahiptir:

Ayar Değer
HealthServiceCacheDurationSeconds Bellek önbelleğinin süre sonu süresini saniye cinsinden denetler.
HealthServiceStorageConnectionString Durum dosyasının mevcut olması gereken Depolama Hesabı için Bağlan ion dizesi.
HealthServiceBlobContainerName Durum dosyasının mevcut olması gereken kapsayıcıyı Depolama.
HealthServiceBlobName Durum dosyasının adı - sistem durumu denetimi bu dosyayı arar.
HealthServiceOverallTimeoutSeconds Denetimin tamamı için zaman aşımı - varsayılan olarak 3 saniyedir. Denetim bu aralıkta tamamlanmazsa hizmet iyi durumda olmadığını bildirir.

Uygulama

Tüm denetimler zaman uyumsuz ve paralel olarak gerçekleştirilir. Bunlardan biri başarısız olursa, damga damgasının tamamı kullanılamaz olarak kabul edilir.

Standart, dağıtılmamış ASP.NET Core MemoryCachekullanılarak sonuçların bellekte önbelleğe alınarak denetlenir. Önbellek süre sonu tarafından SysConfig.HealthServiceCacheDurationSeconds denetlenır ve varsayılan olarak 10 saniye olarak ayarlanır.

Dekont

Her SysConfig.HealthServiceCacheDurationSeconds istek bağımlı hizmetlere aşağı akış çağrısına neden olmadığından, yapılandırma ayarı sistem durumu denetimleri tarafından oluşturulan ek yükü azaltır.

Aşağıdaki tabloda altyapıdaki bileşenler için sistem durumu denetimleri ayrıntılı olarak yer alır:

Bileşen Durum denetimi
Depolama hesabı Blobu Blob denetimi şu anda iki amaca hizmet eder:
1. Blob Depolama ulaşmanın mümkün olup olmadığını test edin. Depolama hesabı damgadaki diğer bileşenler tarafından kullanılır ve kritik bir kaynak olarak kabul edilir.
2. Durum dosyasını silerek bölgeyi el ile "kapatın".
Denetimin yalnızca belirtilen blob kapsayıcısında durum dosyasının varlığını arayacağı bir tasarım kararı alındı. Dosyanın içeriği işlenmez. Dosyanın içeriğini okuyan ve dosyanın içeriğine göre farklı durum döndüren daha gelişmiş bir sistem kurma olasılığı vardır.
İçerik örnekleri: HEALTHY, UNHEALTHY ve MAINTENANCE.
Durum dosyasının kaldırılması damgayı devre dışı bırakır. Uygulamayı dağıttığınızda sistem durumu dosyasının mevcut olduğundan emin olun. Sistem durumu dosyasının olmaması, hizmetin her zaman UNHEALTHY ile yanıt vermesine neden olur. Front Door arka ucu kullanılabilir durumda tanımaz.
Dosya Terraform tarafından oluşturulur ve altyapı dağıtımından sonra mevcut olmalıdır.
Olay Hub’ı Event Hubs sistem durumu raporlaması tarafından EventHubProducerServiceişlenir. Bu hizmet, Event Hubs'a yeni bir ileti gönderebiliyorsa iyi durumda olduğunu bildirir. Filtreleme için, bu iletiye bir tanımlayıcı özelliği eklenir:
HEALTHCHECK=TRUE
Bu ileti alıcı uçta yoksayılır. Yapılandırma AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() ayarı özelliği denetler HEALTHCHECK .
Azure Cosmos DB Azure Cosmos DB sistem durumu raporlaması tarafından CosmosDbServiceişlenir ve durum şuysa iyi durumda olduğunu bildirir:
1. Azure Cosmos DB veritabanına bağlanıp sorgu gerçekleştirebilir.
2. Veritabanına test belgesi yazabilme.
Test belgesi kısa bir Yaşam Süresi kümesine sahiptir ve Azure Cosmos DB belgeyi otomatik olarak kaldırır.
HealthService iki ayrı yoklama gerçekleştirir. Azure Cosmos DB, okumanın çalıştığı ve yazmanın olmadığı bir durumdaysa, iki yoklama bir uyarının tetiklendiğinden emin olur.

Azure Cosmos DB sorguları

Salt okunur sorgu için, hiçbir veri getirmeyen ve genel yük üzerinde büyük bir etkisi olmayan aşağıdaki sorgu kullanılır:

SELECT GetCurrentDateTime ()

Yazma sorgusu, en düşük içerikle bir kukla ItemRating oluşturur:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

İzleme

Azure Log Analytics, tüm uygulama ve altyapı bileşenleri için merkezi depo günlükleri ve ölçümleri olarak kullanılır. Azure Uygulaması Analizler tüm uygulama izleme verileri için kullanılır. Altyapıdaki her damganın ayrılmış bir Log Analytics çalışma alanı ve Application Analizler örneği vardır. Front Door ve Azure Cosmos DB gibi genel olarak paylaşılan kaynaklar için ayrı bir Log Analytics çalışma alanı kullanılır.

Tüm damga pulları kısa ömürlü ve sürekli olarak her yeni sürümle değiştirilir. Damga başına Log Analytics çalışma alanları, Log Analytics kaynaklarını damgalama olarak ayrı bir izleme kaynak grubunda genel kaynak olarak dağıtılır. Bu kaynaklar damganın yaşam döngüsünü paylaşmaz.

Daha fazla bilgi için bkz . Bağıntılı analiz için birleşik veri havuzu.

İzleme: Veri kaynakları

  • Tanılama ayarları: Azure Görev Açısından Kritik için kullanılan tüm Azure hizmetleri, günlükler ve ölçümler de dahil olmak üzere tüm Tanılama verilerini dağıtıma özgü (genel veya damgalı) Log Analytics Çalışma Alanına gönderecek şekilde yapılandırılır. Bu işlem Terraform dağıtımının bir parçası olarak otomatik olarak gerçekleşir. Yeni seçenekler otomatik olarak tanımlanır ve öğesinin terraform applybir parçası olarak eklenir.

  • Kubernetes izleme: Tanılama ayarları, AKS günlüklerini ve ölçümlerini Log Analytics'e göndermek için kullanılır. AKS, Container Analizler kullanacak şekilde yapılandırılmıştır. Container Analizler, AKS kümelerindeki her düğümde Kubernetes DaemonSet aracılığıyla OMSAgentForLinus'u dağıtır. OMSAgentForLinux, Kubernetes kümesi içinden ek günlükler ve ölçümler toplayabilir ve bunları ilgili Log Analytics çalışma alanına gönderir. Bu ek günlükler ve ölçümler podlar, dağıtımlar, hizmetler ve genel küme durumu hakkında daha ayrıntılı veriler içerir. Görev açısından kritik iş yükünün yanında Kubernetes'e dağıtılan ing-nginx, cert-manager ve diğer bileşenlerden daha fazla içgörü elde etmek için Prometheus kazıma özelliğini kullanmak mümkündür. Prometheus kazıma, küme içindeki çeşitli uç noktalardan Prometheus ölçümlerini kazımak için OMSAgentForLinux'u yapılandırıyor.

  • Uygulama Analizler telemetrisi: Uygulama Analizler, uygulamadan telemetri verilerini toplamak için kullanılır. Kod, Uygulama Analizler SDK'sı ile uygulamanın performansı hakkında veri toplamak için izlendi. Elde edilen durum kodu ve işlenmeyen özel durumlar için bağımlılık çağrılarının ve sayaçlarının süresi gibi kritik bilgiler toplanır. Bu bilgiler Sistem Durumu Modeli'nde kullanılır ve uyarı ve sorun giderme için kullanılabilir.

İzleme: Uygulama Analizler kullanılabilirlik testleri

Tek tek damgaların ve genel çözümün kullanılabilirliğini dışarıdan izlemek için Uygulama Analizler Kullanılabilirlik Testleri iki yerde ayarlanır:

  • Bölgesel kullanılabilirlik testleri: Bu testler bölgesel Uygulama Analizler örneklerinde ayarlanır ve damgaların kullanılabilirliğini izlemek için kullanılır. Bu testler, damgaların kümelerini ve statik depolama hesaplarını doğrudan hedefler. Kümelerin giriş noktalarını doğrudan çağırmak için isteklerin doğru Front Door Kimliği üst bilgisini taşıması gerekir, aksi takdirde giriş denetleyicisi tarafından reddedilir.

  • Genel kullanılabilirlik testi: Bu testler genel Uygulama Analizler örneğinde ayarlanır ve Front Door'a ping atarak genel çözümün kullanılabilirliğini izlemek için kullanılır. İki test kullanılır: Biri CatalogService'te api çağrısını test etmek için, diğeri de web sitesinin giriş sayfasını test etmek için.

İzleme: Sorgular

Azure Görev Açısından Kritik, Log Analytics'ten veri almak için işlev olarak özel sorgular uygulamak için farklı Kusto Sorgu Dili (KQL) sorguları kullanır. Bu sorgular, genel ve damga dağıtımları için ayrılmış olarak kod depomuzda tek tek dosyalar olarak depolanır. Bunlar, her altyapı işlem hattı çalıştırmasının bir parçası olarak Terraform aracılığıyla içeri aktarılır ve otomatik olarak uygulanır.

Bu yaklaşım, sorgu mantığını görselleştirme katmanından ayırır. Log Analytics sorguları doğrudan koddan, örneğin HealthService API'sinden çağrılır. Bir diğer örnek de Azure Panoları, Çalışma Kitaplarını İzleme veya Grafana gibi bir görselleştirme aracıdır.

İzleme: Görselleştirme

Log Analytics sistem durumu sorgularımızın sonuçlarını görselleştirmek için başvuru uygulamamızda Grafana'yı kullandık. Grafana, Log Analytics sorgularının sonuçlarını göstermek için kullanılır ve herhangi bir mantık içermez. Grafana yığını çözümün dağıtım yaşam döngüsünün bir parçası değildir, ancak ayrı olarak yayınlanacaktır.

Daha fazla bilgi için bkz . Görselleştirme.

Uyarı

Uyarılar, genel operasyon stratejisinin önemli bir parçasıdır. Pano kullanımı gibi proaktif izleme, sorunlara anında dikkat çeken uyarılarla kullanılmalıdır.

Bu uyarılar, işleci durum durumundaki bir değişikliğe, düzeyi düşürülmüş/sarı duruma veya iyi durumda olmayan/kırmızı durumuna uyararak sistem durumu modelinin bir uzantısını oluşturur. Uyarıyı Sistem Durumu Modeli'nin kök düğümüne ayarlayarak, operatör çözümün durumuna etki eden herhangi bir iş düzeyini hemen fark eder: Sonuçta, temel alınan kullanıcı akışlarından veya kaynaklarından biri sarı veya kırmızı ölçümler bildiriyorsa bu kök düğüm sarı veya kırmızıya dönüşür. Operatör, sorun giderme için dikkatini Sistem Durumu Modeli görselleştirmesine yönlendirebilir.

Daha fazla bilgi için bkz . Otomatik olay yanıtı.

Hata analizi

Hata analizini oluşturmak çoğunlukla teorik bir planlama alıştırmasıdır. Bu teorik alıştırma, sürekli doğrulama sürecinin bir parçası olan otomatik hata eklemeleri için giriş olarak kullanılmalıdır. Burada tanımlanan hata modlarının benzetimini yaparak, kesintilere neden olmayacağından emin olmak için çözümün bu hatalara karşı dayanıklılığını doğrulayabiliriz.

Aşağıdaki tabloda, Azure Görev Açısından Kritik başvuru uygulamasının çeşitli bileşenleriyle ilgili hata örnekleri listelenmiştir.

Service Risk Etki/Azaltma/Açıklama Kesinti
Microsoft Entra ID Microsoft Entra Id kullanılamaz duruma gelir. Şu anda olası bir risk azaltma yok. Çok bölgeli bir yaklaşım, genel bir hizmet olduğundan kesintileri azaltmaz. Bu hizmet zor bir bağımlılıktır. Microsoft Entra Id, yeni AKS düğümleri oluşturma, ACR'den kapsayıcı görüntülerini çekme veya pod başlatma sırasında Key Vault'a erişme gibi denetim düzlemi işlemleri için kullanılır. Microsoft Entra ID sorunlarla karşılaştığında mevcut, çalışan bileşenlerin çalışmaya devam edebilmesi beklenir. Yeni podların veya AKS düğümlerinin ortaya çıkma olasılığı yüksektir. Bu süre boyunca ölçeklendirme işlemleri gereklidir, bu durum kullanıcı deneyiminin azalmasına ve kesintilere yol açabilir. Partial
Azure DNS Azure DNS kullanılamaz duruma gelir ve DNS çözümlemesi başarısız olur. Azure DNS kullanılamaz duruma gelirse, kullanıcı istekleri ve uygulamanın farklı bileşenleri arasındaki DNS çözümlemesi büyük olasılıkla başarısız olur. Şu anda bu senaryo için olası bir azaltma yoktur. Çok bölgeli bir yaklaşım, genel bir hizmet olduğundan kesintileri azaltmaz. Azure DNS, sabit bir bağımlılıktır. Kullanılan tüm PaaS bileşenleri Azure DNS'ye bağlı olduğundan, yedekleme olarak dış DNS hizmetleri yardımcı olmaz. IP'ye geçiş yaparak DNS'yi atlamak bir seçenek değildir. Azure hizmetlerinin statik, garantili IP adresleri yoktur. Tam
Front Door Genel Front Door kesintisi. Front Door tamamen çökerse, hafifletme olmaz. Bu hizmet zor bir bağımlılıktır. Evet
Front Door Yönlendirme/ön uç/arka uç yapılandırma hataları. Dağıtım sırasında yapılandırmadaki uyuşmazlık nedeniyle oluşabilir. Test aşamalarında yakalanması gerekir. DNS ile ön uç yapılandırması her ortama özgüdür. Azaltma: Önceki yapılandırmaya geri dönmek çoğu sorunu çözmelidir... Front Door'da değişikliklerin dağıtılması birkaç dakika sürerse kesintiye neden olur. Tam
Front Door Yönetilen TLS/SSL sertifikası silinir. Dağıtım sırasında yapılandırmadaki uyuşmazlık nedeniyle oluşabilir. Test aşamalarında yakalanması gerekir. Teknik olarak site çalışmaya devam eder, ancak TLS/SSL sertifikası hataları kullanıcıların siteye erişmesini engeller. Azaltma: Sertifikanın yeniden verilmesi yaklaşık 20 dakika sürebilir, ayrıca işlem hattının düzeltilmesi ve yeniden çalıştırılması... Tam
Azure Cosmos DB Veritabanı/koleksiyon yeniden adlandırıldı. Dağıtım sırasında yapılandırmadaki uyuşmazlık nedeniyle oluşabilir– Terraform veritabanının tamamının üzerine yazabilir ve bu da veri kaybına neden olabilir. Veritabanı/koleksiyon düzeyi kilitleri kullanılarak veri kaybı önlenebilir. Uygulama hiçbir veriye erişemez. Uygulama yapılandırmasının güncelleştirilmesi ve podların yeniden başlatılması gerekir. Evet
Azure Cosmos DB Bölgesel kesinti Azure Görev Açısından Kritik'in çok bölgeli yazmaları etkindir. Okuma veya yazmada bir hata varsa, istemci geçerli işlemi yeniden dener. Gelecekteki tüm işlemler tercih sırasına göre kalıcı olarak bir sonraki bölgeye yönlendirilir. Tercih listesinde bir giriş olması (veya boş olması) ancak hesabın kullanılabilir başka bölgeleri olması durumunda, hesap listesinde bir sonraki bölgeye yönlendirilir. Hayır
Azure Cosmos DB RU'ların olmaması nedeniyle geniş kapsamlı azaltma. Ru sayısına ve Front Door düzeyinde kullanılan yük dengelemeye bağlı olarak, bazı damgalar Azure Cosmos DB kullanımı üzerinde çalışırken çalışırken diğer damga damgaları daha fazla istekte bulunabilir. Azaltma: Daha iyi yük dağıtımı veya daha fazla RU. Hayır
Azure Cosmos DB Bölüm dolu Azure Cosmos DB mantıksal bölüm boyutu sınırı 20 GB'tır. Kapsayıcı içindeki bir bölüm anahtarının verileri bu boyuta ulaşırsa, ek yazma istekleri "Bölüm anahtarı boyut üst sınırına ulaştı" hatasıyla başarısız olur. Kısmi (VERITABANı yazma devre dışı)
Azure Container Registry Bölgesel kesinti Kapsayıcı kayıt defteri, çoğaltma bölgeleri arasında yük devretme yapmak için Traffic Manager'ı kullanır. Tüm istekler otomatik olarak başka bir bölgeye yönlendirilmelidir. En kötü ihtimalle DNS yük devretme gerçekleşirken Docker görüntüleri AKS düğümleri tarafından birkaç dakika boyunca çekilemiyor. Hayır
Azure Container Registry Silinen görüntüler Hiçbir görüntü çekilemiyor. Bu kesinti yalnızca yeni oluşturulan/yeniden başlatılmış düğümleri etkilemelidir. Mevcut düğümlerde görüntülerin önbelleğe alınması gerekir. **Azaltma: En son derleme işlem hatlarının hızla yeniden çalıştırılması algılanırsa görüntüleri kayıt defterine geri getirmesi gerekir. Hayır
Azure Container Registry Azaltma Azaltma, ölçeği genişletme işlemlerini geciktirebilir ve bu da performansın geçici olarak düşmesine neden olabilir. Azaltma: Azure Görev Açısından Kritik, dakikada 10.000 okuma işlemi sağlayan Premium SKU'yu kullanır. Kapsayıcı görüntüleri iyileştirilir ve yalnızca az sayıda katmana sahiptir. ImagePullPolicy, önce yerel olarak önbelleğe alınmış sürümleri kullanmak için IfNotPresent olarak ayarlanır. Açıklama: Kapsayıcı görüntüsünün çekilmesi, katman sayısına bağlı olarak birden çok okuma işleminden oluşur. Dakika başına okuma işlemlerinin sayısı sınırlıdır ve ACR SKU boyutuna bağlıdır. Hayır
Azure Kubernetes Service Küme yükseltmesi başarısız oluyor AKS Düğümü yükseltmeleri, damga pulları arasında farklı zamanlarda gerçekleşmelidir. bir yükseltme başarısız olursa, diğer küme etkilenmemelidir. Tüm düğümlerin kullanılamaz duruma gelmesini önlemek için küme yükseltmeleri düğümler arasında sıralı bir şekilde dağıtılmalıdır. Hayır
Azure Kubernetes Service İstek servis edilirken uygulama pod'u öldürülür. Bu, son kullanıcının hatalara ve kötü kullanıcı deneyimine neden olabilir. Azaltma: Kubernetes, podları varsayılan olarak düzgün bir şekilde kaldırır. Podlar önce hizmetlerden kaldırılır ve iş yükü, açık istekleri tamamlamak ve sonlandırmadan önce veri yazmak için yetkisiz kullanım süresine sahip bir SIGTERM alır. Uygulama kodunun SIGTERM'yi anlaması gerekir ve iş yükünün kapatılması daha uzun sürerse yetkisiz kullanım süresinin ayarlanması gerekebilir. Hayır
Azure Kubernetes Service Daha fazla düğüm eklemek için bölgede işlem kapasitesi kullanılamıyor. Ölçeği artırma/genişletme işlemleri başarısız olur, ancak mevcut düğümleri ve bunların işlemlerini etkilememelidir. İdeal olan trafiğin yük dengeleme için otomatik olarak diğer bölgelere kaymasıdır. Hayır
Azure Kubernetes Service Abonelik, yeni düğümler eklemek için CPU çekirdek kotasına ulaşır. Ölçeği artırma/genişletme işlemleri başarısız olur, ancak mevcut düğümleri ve bunların işlemlerini etkilememelidir. İdeal olan trafiğin yük dengeleme için otomatik olarak diğer bölgelere kaymasıdır. Hayır
Azure Kubernetes Service TlS'i Şifreleyelim/SSL sertifikaları verilemiyor/yenilenemiyor. KümeNin Front Door'a karşı iyi durumda olmadığını bildirmesi ve trafiğin diğer damgalara kayması gerekir. Azaltma: Sorunun/yenileme hatasının kök nedenini araştırın. Hayır
Azure Kubernetes Service Kaynak istekleri/sınırları yanlış yapılandırıldığında podlar %100 CPU kullanımına ve başarısız isteklere ulaşabilir. Uygulama yeniden deneme mekanizması başarısız istekleri kurtarabilmelidir. Yeniden denemeler, hatayı istemciye eklemeden daha uzun bir istek süresine neden olabilir. Aşırı yük sonunda hataya neden olur. Hayır (yük aşırı değilse)
Azure Kubernetes Service Üçüncü taraf kapsayıcı görüntüleri / kayıt defteri kullanılamıyor cert-manager ve ingress-nginx gibi bazı bileşenler, dış kapsayıcı kayıt defterlerinden (giden trafik) kapsayıcı görüntülerini ve helm grafiklerini indirmeyi gerektirir. Bu depolardan veya görüntülerden birinin veya daha fazlasının kullanılamaması durumunda, yeni düğümlerdeki yeni örnekler (görüntünün henüz önbelleğe alınmadığı) başlatılamayabilir. Olası risk azaltma: Bazı senaryolarda üçüncü taraf kapsayıcı görüntülerinin çözüm başına kapsayıcı kayıt defterine aktarılması mantıklı olabilir. Bu ek karmaşıklık ekler ve dikkatli bir şekilde planlanmalı ve kullanıma hazır hale getirilmelidir. Kısmen (ölçeklendirme ve güncelleştirme/yükseltme işlemleri sırasında)
Olay Hub’ı İletiler Event Hubs'a gönderilemiyor Damga, yazma işlemleri için kullanılamaz hale gelir. Sistem sağlığı hizmeti bunu otomatik olarak algılamalı ve damgayı döndürmeden çıkarmalıdır. Hayır
Olay Hub’ı İletiler BackgroundProcessor tarafından okunamıyor İletiler kuyruğa alınacaktır. İletiler kalıcı hale getirildiğinden kaybolmamalıdır. Şu anda bu hata Sistem Sağlığı Hizmeti kapsamında değildir. İleti okuma hatalarını algılamak için çalışanda izleme/uyarı olmalıdır. Azaltma: Sorun giderilinceye kadar damga damgası el ile devre dışı bırakılmalıdır. Hayır
Depolama hesabı Depolama hesabı event hubs denetimi için çalışan tarafından kullanılamaz duruma gelir Stamp, Event Hubs'dan gelen iletileri işlemez. Depolama hesabı, HealthService tarafından da kullanılır. Depolamayla ilgili beklenen sorunlar HealthService tarafından algılanmalı ve damganın rotasyondan alınması gerekir. Damga pulundaki diğer hizmetlerin eşzamanlı olarak etkilenmesi beklenebilir. Hayır
Depolama hesabı Statik web sitesi sorunlarla karşılaşır. Statik web sitesinin sunulması sorunlarla karşılaşırsa, bu hata Front Door tarafından algılanmalıdır. Trafik bu depolama hesabına gönderilmez. Front Door'daki Önbelleğe Alma de bu sorunu hafifletebilir. Hayır
Anahtar Kasası Key Vault işlemler için GetSecret kullanılamıyor. Yeni podların başlangıcında AKS CSI sürücüsü Tüm gizli dizileri Key Vault'tan getirir ve başarısız olur. Podlar başlatılamıyor. Şu anda her 5 dakikada bir otomatik güncelleştirme vardır. Güncelleştirme başarısız olur. içinde hatalar görünmelidir kubectl describe pod , ancak pod çalışmaya devam eder. Hayır
Anahtar Kasası Key Vault veya işlemleri için GetSecretSetSecret kullanılamıyor. Yeni dağıtımlar yürütülemez. Şu anda bu hata, yalnızca bir bölge etkilenmiş olsa bile tüm dağıtım işlem hattının durmasına neden olabilir. Hayır
Anahtar Kasası Key Vault azaltma Key Vault'un 10 saniyede 1000 işlem sınırı vardır. Gizli dizilerin otomatik olarak güncelleştirildiğinden, bir damga pulunda çok sayıda (binlerce) pod varsa teoride bu sınıra gelebilirsiniz. Olası risk azaltma: Güncelleştirme sıklığını daha da azaltın veya tamamen kapatın. Hayır
Uygulama Yanlış yapılandırma Uygulamaya eklenen yanlış bağlantı dizesi veya gizli diziler. Otomatik dağıtım (işlem hattı yapılandırmayı otomatik olarak işler) ve güncelleştirmelerin mavi-yeşil kullanıma alınmasıyla azaltılmalıdır. Hayır
Uygulama Süresi dolmuş kimlik bilgileri (damga kaynağı) Örneğin, olay hub'ı SAS belirteci veya depolama hesabı anahtarı, podların bunları kullanabilmesi için Key Vault'ta düzgün bir şekilde güncelleştirilmeden değiştirildiyse, ilgili uygulama bileşeni başarısız olur. Bu hata daha sonra Sistem Sağlığı Hizmeti etkilemeli ve damga otomatik olarak döndürmeden çıkarılmalıdır. Risk azaltma: Microsoft Entra ID tabanlı kimlik doğrulamasını destekleyen tüm hizmetler için kullanın. AKS, Microsoft Entra İş Yükü Kimliği (önizleme) kullanarak kimlik doğrulaması yapmak için pod gerektirir. Başvuru uygulamasında Pod Kimliği kullanımı dikkate alınmıştı. Pod Kimliği'nin şu anda yeterince kararlı olmadığı ve geçerli başvuru mimarisi için kullanılmasına karşı karar alındığı bulundu. Pod kimliği gelecekte bir çözüm olabilir. Hayır
Uygulama Süresi dolmuş kimlik bilgileri (genel olarak paylaşılan kaynak) Örneğin Azure Cosmos DB API anahtarı, podların bunları kullanabilmesi için tüm damga Key Vault'larında düzgün bir şekilde güncelleştirilmeden değiştirildiyse ilgili uygulama bileşenleri başarısız olur. Bu hata tüm damgaları aynı anda düşürüp iş yükü genelinde kesintiye neden olur. Microsoft Entra kimlik doğrulamasını kullanarak anahtar ve gizli dizi ihtiyacını geçici olarak belirlemenin olası bir yolu için önceki öğeye bakın. Tam
Sanal ağ Alt ağ IP adresi alanı tükendi Bir alt ağdaki IP adresi alanı tükenirse, yeni AKS düğümleri veya podları oluşturma gibi ölçek genişletme işlemleri gerçekleşemez. Kesintiye neden olmaz, ancak performansı düşürebilir ve kullanıcı deneyimini etkileyebilir. Azaltma: IP alanını artırın (mümkünse). Bu bir seçenek değilse, düğüm başına kaynakları (daha büyük VM SKU'ları) veya pod başına (daha fazla CPU/bellek) artırmaya yardımcı olabilir; böylece her pod daha fazla trafiği işleyebilir ve böylece ölçeği genişletme gereksinimi azalır. Hayır

Sonraki adımlar

Bu mimaride kullanılan kaynakları ve yapılandırmalarını tam olarak anlamak için başvuru uygulamasını dağıtın.