İş yükünüzü Service Fabric'ten AKS'ye geçirme

Birçok kuruluş modern uygulama geliştirme, bakım en iyi yöntemleri ve bulutta yerel mimarileri benimsemeye yönelik bir gönderim kapsamında kapsayıcılı uygulamalara geçmiştir. Teknolojiler gelişmeye devam ettikçe kuruluşlar genel bulutta kullanılabilen birçok kapsayıcılı uygulama platformunu değerlendirmektedir.

Uygulamalar için tek bir boyuta uyan çözüm yoktur, ancak kuruluşlar genellikle Azure Kubernetes Service'in (AKS) kapsayıcılı uygulamalarının çoğu için gereksinimleri karşıladığını fark eder. AKS, uygulama iş yükleri için temel hizmetler sağlamak üzere denetim düzlemini yöneterek Kubernetes aracılığıyla uygulama dağıtımlarını basitleştiren yönetilen bir Kubernetes hizmetidir. Birçok kuruluş birincil altyapı platformu olarak AKS'yi kullanıyor ve diğer platformlarda barındırılan iş yüklerini AKS'ye geçirmektedir.

Bu makalede, kapsayıcılı uygulamaların Azure Service Fabric'ten AKS'ye nasıl geçirildiği açıklanmaktadır. Makalede, Service Fabric hakkında bilgi sahibi olduğunuz ancak özelliklerini ve işlevselliğini AKS ile karşılaştırmak istediğinizi varsayar. Makalede ayrıca geçiş sırasında göz önünde bulundurmanız gereken en iyi yöntemler sağlanır.

AKS ile Service Fabric karşılaştırması

Başlamak için, diğer Azure işlem hizmetleriyle birlikte iki platformu karşılaştıran bu makaleyi gözden geçirin. Bu bölümde geçişle ilgili önemli benzerlikler ve farklılıklar vurgulanır.

Hem Service Fabric hem de AKS kapsayıcı düzenleyicileridir. Service Fabric çeşitli programlama modelleri için destek sağlarken AKS yalnızca kapsayıcıları destekler.

• Programlama modelleri: Service Fabric; Linux ve Windows kapsayıcıları, Reliable Services, Reliable Actors, ASP.NET Core ve konuk yürütülebilir dosyaları dahil olmak üzere hizmetlerinizi yazmanın ve yönetmenin birden çok yolunu destekler.
• AKS'deki kapsayıcılar: AKS yalnızca kapsayıcılı kapsayıcı çalışma zamanı üzerinde çalışan Windows ve Linux kapsayıcıları ile kapsayıcı oluşturmayı destekler ve bu kapsayıcı otomatik olarak yönetilir.

Hem Service Fabric hem de AKS, Azure Pipelines, Azure İzleyici, Azure Key Vault ve Microsoft Entra Id gibi diğer Azure hizmetleriyle tümleştirmeler sunar.

Temel farklılıklar

Yönetilen küme yerine geleneksel bir Service Fabric kümesi dağıttığınızda, Azure Resource Manager şablonlarınızda (ARM şablonları) veya Bicep modüllerinizde bir dizi destekleyici kaynakla birlikte bir küme kaynağını açıkça tanımlamanız gerekir. Bu kaynaklar her küme düğümü türü, ağ güvenlik grupları ve yük dengeleyiciler için bir sanal makine ölçek kümesi içerir. Bu kaynakların doğru yapılandırıldığından emin olmak sizin sorumluluğunuzdadır. Buna karşılık, Service Fabric yönetilen kümeleri için kapsülleme modeli tek bir yönetilen küme kaynağından oluşur. Küme için temel alınan tüm kaynaklar soyutlanır ve Azure tarafından yönetilir.

AKS , işletimsel ek yükü Azure'a boşaltarak Azure'da yönetilen bir Kubernetes kümesini dağıtmayı basitleştirir. AKS barındırılan bir Kubernetes hizmeti olduğundan Azure, altyapı durumu izleme ve bakım gibi kritik görevleri üstlenir. Azure, Kubernetes ana düğümlerini yönetir, bu nedenle yalnızca aracı düğümlerini yönetir ve korursunuz.

İş yükünüzü Service Fabric'ten AKS'ye taşımak için kapsayıcılı uygulamalarınızı güvenle geçirebilmeniz için temel altyapıdaki farkları anlamanız gerekir. Aşağıdaki tablo, iki barındırma platformunun özelliklerini ve özelliklerini karşılaştırır.

Geçiş adımları

Genel olarak, Azure Service Fabric'ten Azure Kubernetes Service'e geçiş adımları aşağıdaki gibidir.

1. Dağıtım mimarisi oluşturun ve AKS kümesini oluşturun. AKS size küme erişimini, düğüm ve pod ölçeklenebilirliğini, ağ erişimini ve yapılandırmasını vb. yapılandırmak için çeşitli seçenekler sunar. Tipik bir dağıtım mimarisi için örnek mimari bölümüne bakın. AKS temel mimarisi, küme dağıtım ve izleme yönergelerini de sağlar. AKS yapısı , IŞ ve teknik gereksinimlere göre AKS kümenizi dağıtmak için hızlı başlangıç şablonları sağlar.

2. Service Fabric uygulamasının mimarisini yeniden oluşturun. Reliable Services veya Reliable Actors gibi programlama modelleri kullanıyorsanız veya Service Fabric'e özgü diğer yapıları kullanıyorsanız, uygulamanızı yeniden tasarlamanız gerekebilir. Dapr , Reliable Services'ten geçiş yaparken durum yönetimi uygulamanın önerilen yoludur. Kubernetes, Reliable Actors'tan geçiş için desenler ve örnekler sunar.

3. Uygulamayı kapsayıcı olarak paketleyin. Visual Studio, Dockerfile oluşturmak ve uygulamayı kapsayıcı olarak paketlemek için size seçenekler sağlar. Oluşturduğunuz kapsayıcı görüntülerini Azure Container Registry'ye gönderin.

4. Service Fabric yapılandırma XML dosyalarını Kubernetes YAML dosyaları olarak yeniden yazın. Uygulamayı YAML dosyalarını kullanarak AKS'ye veya Helm grafiklerini kullanarak paket olarak dağıtacaksınız. Ayrıntılar için lütfen Uygulama ve hizmet bildirimi bölümüne bakın.

5. Uygulamayı AKS kümesine dağıtın.

6. Dağıtım stratejilerinize göre trafiği AKS kümesine geçirin ve uygulamanın davranışını, kullanılabilirliğini, performansını izleyin.

Örnek mimari

AKS ve Azure, ortamınızı iş gereksinimlerinize uyacak şekilde yapılandırma esnekliği sağlar. AKS, diğer Azure hizmetleriyle iyi tümleştirilmiştir. Aşağıda örnek bir mimari, AKS temel mimarisi verilmiştir.

Başlangıç noktası olarak, bazı temel Kubernetes kavramlarını tanımanızı ve ardından bazı örnek mimarileri gözden geçirmenizi öneririz:

• AKS için Kubernetes temel bilgileri
• AKS kümesi için temel mimari

Uygulama ve hizmet bildirimi

Service Fabric ve AKS farklı uygulama ve hizmet bildirimi dosya türlerine ve yapılarına sahiptir. Service Fabric, uygulama ve hizmet tanımı için XML dosyalarını kullanır. AKS, Kubernetes nesnelerini tanımlamak için Kubernetes YAML dosya bildirimini kullanır. Service Fabric XML dosyasını Kubernetes YAML dosyasına geçirmek için özel olarak tasarlanmış hiçbir araç yoktur. Ancak aşağıdaki kaynakları gözden geçirerek YAML dosyalarının Kubernetes'te nasıl çalıştığı hakkında bilgi edinebilirsiniz.

• Kubernetes belgeleri: Kubernetes Nesnelerini Anlama.
• Windows düğümleri/uygulamaları için AKS belgeleri: Azure CLI kullanarak AKS kümesinde Windows Server kapsayıcısı oluşturma.

Helm'i kullanarak parametreli YAML bildirimleri tanımlayabilir ve statik, sabit kodlanmış değerleri dağıtım zamanında sağlanan özel değerlerle değiştirilebilen yer tutucularla değiştirerek genel şablonlar oluşturabilirsiniz. Özel değerleri içeren sonuçta elde edilen şablonlar Kubernetes için geçerli bildirimler olarak işlenir.

Kustomize , kullanıma açık uygulamaların kullanımını basitleştiren uygulama yapılandırmasını özelleştirmek için şablon içermeyen bir yol sunar. Kustomize'yi Helm ile birlikte veya Helm'e alternatif olarak kullanabilirsiniz.

Helm ve Kustomize hakkında daha fazla bilgi için şu kaynaklara bakın:

• Helm belgeleri
• Yapıt Hub'ı
• Kustomize belgeleri
• Kustomizasyon dosyasına genel bakış
• Kustomize Kullanarak Kubernetes Nesnelerinin Bildirim temelli Yönetimi

Ağ

AKS, temel alınan ağ için iki seçenek sağlar:

• Kendi sanal ağınızı getirin: Kendi Azure sanal ağınızı getirmek, AKS küme düğümlerini sizin sağladığınız bir sanal ağdan bir alt ağa sağlar.
• AKS kaynak sağlayıcısının, kümenin kullandığı tüm Azure kaynaklarını içeren düğüm kaynak grubunda sizin için yeni bir Azure sanal ağı oluşturmasına izin vekleyebilirsiniz.

İkinci seçeneği belirlerseniz, sanal ağı Azure yönetir.

Service Fabric, bir ağ eklentisi seçeneği sağlamaz. AKS kullanıyorsanız birini seçmeniz gerekir:

• kubenet. kubenet kullanıyorsanız düğümler Azure sanal ağ alt ağından bir IP adresi alır. Podlar, düğümlerin Azure sanal ağ alt ağından mantıksal olarak farklı bir adres alanından BIR IP adresi alır. Ardından podların Azure sanal ağındaki kaynaklara erişebilmesi için ağ adresi çevirisi (NAT) yapılandırması gerçekleştirilir. Trafiğin kaynak IP adresi NAT aracılığıyla düğümün birincil IP adresine çevrilir. Bu yaklaşım, podların kullanması için ağ alanınızda ayırmanız gereken IP adresi sayısını önemli ölçüde azaltır.
• Azure CNI. Azure Container Networking Interface (CNI) kullanıyorsanız, her pod alt ağdan bir IP adresi alır ve doğrudan erişilebilir. Bu IP adreslerinin ağ alanınız genelinde benzersiz olması ve önceden planlanması gerekir. Her düğümün desteklediği en fazla pod sayısı için bir yapılandırma parametresi vardır. Ardından her düğüm için eşdeğer SAYıDA IP adresi ayırırsınız. Bu yaklaşım daha fazla planlama gerektirir ve genellikle IP adresi tükenmesine veya uygulamanızın talebi arttıkça daha büyük bir alt ağda kümeleri yeniden oluşturma gereksinimine yol açar. Kümeyi oluştururken veya yeni düğüm havuzları oluştururken düğüme dağıtılabilen en fazla pod sayısını yapılandırabilirsiniz.
• Azure CNI Katman ağı. Azure CNI Yer Paylaşımı'nı kullanırsanız, küme düğümleri bir Azure Sanal Ağ alt aya dağıtılır. Podlara, düğümleri barındıran sanal ağın adresinden mantıksal olarak farklı olan özel bir CIDR'den IP adresleri atanır. Küme içindeki pod ve düğüm trafiği bir katman ağı kullanır. NAT (düğümün IP adresi kullanılarak) küme dışındaki kaynaklara ulaşmak için kullanılır. Bu çözüm çok sayıda sanal ağ IP adresini kaydeder ve kümenizi çok büyük boyutlara sorunsuz bir şekilde ölçeklendirmenizi sağlar. Bunun bir avantajı da özel CIDR'yi farklı AKS kümelerinde yeniden kullanabilmenizdir ve bu da AKS'deki kapsayıcılı uygulamalar için kullanılabilen IP alanını genişletir.
• Cilium tarafından desteklenen Azure CNI. Cilium tarafından desteklenen Azure CNI, yüksek performanslı ağ ve gelişmiş güvenlik sağlamak için Azure CNI'nin güçlü denetim düzlemini Cilium'un veri düzlemiyle birleştirir.
• Kendi CNI eklentinizi getirin. Kubernetes varsayılan olarak bir ağ arabirimi sistemi sağlamaz. Bu işlev ağ eklentileri tarafından sağlanır. AKS, desteklenen birkaç CNI eklentisi sağlar. Desteklenen eklentiler hakkında bilgi için bkz. AKS'deki uygulamalar için ağ kavramları.

Windows kapsayıcıları şu anda yalnızca Azure CNI eklentisini destekler. Ağ ilkeleri ve giriş denetleyicileri için çeşitli seçenekler mevcuttur.

AKS'de Kubernetes ağ ilkelerini kullanarak hangi bileşenlerin birbiriyle iletişim kurabileceğini denetleyerek hizmet içi iletişimleri ayırabilir ve güvenli bir şekilde sağlamaya yardımcı olabilirsiniz. Varsayılan olarak, Kubernetes kümesindeki tüm podlar sınırlama olmadan trafik gönderebilir ve alabilir. Güvenliği geliştirmek için Azure ağ ilkelerini veya Calico ağ ilkelerini kullanarak mikro hizmetler arasındaki trafik akışını denetleyan kurallar tanımlayabilirsiniz.

Azure Ağ İlkesi Yöneticisi'ni kullanmak istiyorsanız Azure CNI eklentisini kullanmanız gerekir. Calico ağ ilkelerini Azure CNI eklentisi veya kubenet CNI eklentisiyle kullanabilirsiniz. Windows düğümleri için Azure Ağ İlkesi Yöneticisi'nin kullanımı yalnızca Windows Server 2022'de desteklenir. Daha fazla bilgi için bkz . AKS'de ağ ilkelerini kullanarak podlar arasındaki trafiğin güvenliğini sağlama. AKS ağı hakkında daha fazla bilgi için bkz . AKS'de ağ oluşturma.

Kubernetes'te bir giriş denetleyicisi, bir hizmet ile dış dünya arasında hizmet ara sunucusu ve aracı işlevi görerek dış trafiğin hizmete erişmesine olanak sağlar. Hizmet proxy'si genellikle TLS sonlandırma, yol tabanlı istek yönlendirme, yük dengeleme ve kimlik doğrulaması ve yetkilendirme gibi güvenlik özellikleri gibi çeşitli işlevler sağlar. Giriş denetleyicileri ayrıca http/HTTPS kurallarına göre dış trafiği Kubernetes hizmetlerine yönlendirmek için başka bir soyutlama ve denetim katmanı sağlar ve bu da trafik akışı ve trafik yönetimi üzerinde daha ayrıntılı denetim sağlar.

AKS'de giriş denetleyicisini dağıtmak, çalıştırmak ve çalıştırmak için birden çok seçenek vardır. Seçeneklerden biri, Azure Uygulaması Lication Gateway'i TLS sonlandırma, yol tabanlı yönlendirme ve web erişim güvenlik duvarı olarak giriş denetleyicisi olarak kullanmanızı sağlayan Application Gateway Giriş Denetleyicisi'dir. Bir diğer seçenek de yaygın olarak kullanılan NGINX giriş denetleyicisi için Azure yönetilen seçeneğini sağlayan yönetilen NGINX giriş denetleyicisidir. Son olarak, Traefik giriş denetleyicisi Kubernetes için bir diğer popüler giriş denetleyicisidir.

Bu giriş denetleyicilerinin her birinin güçlü ve zayıf yönleri vardır. Hangisini kullanacağınıza karar vermek için uygulamanın ve ortamın gereksinimlerini dikkate alın. Helm'in en son sürümünü kullandığınızdan ve yönetilmeyen bir giriş denetleyicisi yüklediğinizde uygun Helm deposuna erişebildiğinizden emin olun.

Kalıcı depolama

Hem Service Fabric hem de AKS, kapsayıcılı uygulamalara kalıcı depolama sağlamak için mekanizmalara sahiptir. Azure Dosyalar birim sürücüsü olan Docker birim eklentisi Service Fabric'te Linux ve Windows kapsayıcıları için Azure Dosyalar birimleri sağlar. Küme içindeki diğer Service Fabric kapsayıcılı uygulamaları için birimler sağlamak üzere bir Service Fabric kümesine dağıtabileceğiniz bir Service Fabric uygulaması olarak paketlenmiştir. Daha fazla bilgi için bkz. Service Fabric için birim sürücüsü Azure Dosyalar.

AKS'de çalışan uygulamaların kalıcı bir dosya depolama sisteminden veri depolaması ve alması gerekebilir. AKS, Azure yönetilen diskler, Azure Dosyalar, Azure Blob Depolama ve Azure NetApp Storage (ANF) gibi Azure depolama hizmetleriyle tümleştirilir. Ayrıca Kapsayıcı Depolama Arabirimi (CSI) sürücüleri aracılığıyla Rook ve GlusterFS gibi üçüncü taraf depolama sistemleriyle tümleşir.

CSI , blok ve dosya depolama sistemlerini Kubernetes'te kapsayıcılı iş yüklerine kullanıma sunar. CSI kullanan üçüncü taraf depolama sağlayıcıları, çekirdek Kubernetes kodunu değiştirmeye ve yayın döngülerini beklemeye gerek kalmadan Kubernetes'te yeni depolama sistemlerini kullanıma sunabilmek veya mevcut olanları iyileştirmek için eklentiler yazabilir, dağıtabilir ve güncelleştirebilir.

AKS'de CSI depolama sürücüsü desteği, şu Azure depolama hizmetlerini yerel olarak kullanmanıza olanak tanır:

• Azure Diskler. Kubernetes DataDisk kaynağı oluşturmak için Azure Diskleri'ni kullanabilirsiniz. Diskler, yüksek performanslı SSD'ler tarafından yedeklenen Azure premium depolamayı veya standart HDD'ler veya SSD'ler tarafından yedeklenen Azure standart depolamayı kullanabilir. Çoğu üretim ve geliştirme iş yükü için premium depolamayı kullanın. Azure Diskleri ReadWriteOnce olarak bağlanır ve AKS'de yalnızca bir düğümde kullanılabilir. Birden çok pod'un aynı anda erişebildiği depolama birimleri için Azure Dosyalar kullanın.

  Buna karşılık, Service Fabric yönetilen diskler kullanan bir küme veya düğüm türü oluşturmayı destekler, ancak bildirim temelli bir yaklaşımla dinamik olarak bağlı yönetilen diskler oluşturan uygulamaları desteklemez. Daha fazla bilgi için bkz . Yönetilen veri diskleriyle Service Fabric küme düğümü türünü dağıtma.

• Azure Dosyalar. Azure depolama hesabı tarafından yedeklenen bir SMB 3.0 veya 3.1 paylaşımını podlara bağlamak için Azure Dosyalar kullanabilirsiniz. Azure Dosyalar ile verileri birden çok düğüm ve pod arasında paylaşabilirsiniz. Azure Dosyalar, standart HDD'ler tarafından yedeklenen Azure standart depolamayı veya yüksek performanslı SSD'ler tarafından yedeklenen Azure premium depolamayı kullanabilir.

  Bu bölümde daha önce açıklandığı gibi Service Fabric, Docker kapsayıcıları için Azure Dosyalar birimleri sağlayan bir Docker birim eklentisi olarak Azure Dosyalar birim sürücüsü sağlar. Service Fabric, Windows kümeleri için bir sürücü ve Linux kümeleri için bir sürüm sağlar.

• Azure Blob Depolama. Blob Depolama'yı kullanarak blob depolamayı (veya nesne depolamasını) bir kapsayıcıya veya poda dosya sistemi olarak bağlayabilirsiniz. Blob depolama, AKS kümesinin günlük dosyası verileri, görüntüler veya belgeler ve HPC iş yükleri gibi yapılandırılmamış büyük veri kümeleriyle çalışan uygulamaları desteklemesini sağlar. Azure Data Lake Storage'a veri alırsanız, depolamayı doğrudan bağlayabilir ve başka bir geçici dosya sistemi yapılandırmadan AKS'de kullanabilirsiniz. Service Fabric, blob depolamayı bildirim temelli modda bağlamak için herhangi bir mekanizmayı desteklemez.

Depolama seçenekleri hakkında daha fazla bilgi için bkz . AKS'de depolama.

Uygulama ve küme izleme

Hem Service Fabric hem de AKS, Azure İzleyici ve Log Analytics gibi hizmetleriyle yerel tümleştirme sağlar. İzleme ve tanılama, iş yüklerini herhangi bir bulut ortamında geliştirme, test etme ve dağıtma açısından kritik öneme sahiptir. İzleme, altyapı ve uygulama izlemeyi içerir.

Örneğin, uygulamalarınızın nasıl kullanıldığını, Service Fabric platformunun yaptığı eylemleri, performans sayaçları aracılığıyla kaynak kullanımınızı ve kümenizin genel durumunu izleyebilirsiniz. Sorunları tanılamak ve düzeltmek ve gelecekte ortaya çıkmasını önlemek için bu bilgileri kullanabilirsiniz. Daha fazla bilgi için bkz . Service Fabric için izleme ve tanılama. Service Fabric kümesinde kapsayıcılı uygulamaları barındırıp çalıştırırken, kapsayıcı olaylarını ve günlüklerini görüntülemek için kapsayıcı izleme çözümünü ayarlamanız gerekir.

Öte yandan AKS, buluta dağıtılan kapsayıcılı iş yüklerinin performansını izlemek için tasarlanan Azure İzleyici ve Container Insights ile yerleşik tümleştirmeye sahiptir. Container Insights, Ölçümler API'sini kullanarak Kubernetes'te kullanılabilen denetleyicilerden, düğümlerden ve kapsayıcılardan bellek ve işlemci ölçümlerini toplayarak performans görünürlüğü sağlar.

Kubernetes kümelerinden izlemeyi etkinleştirdikten sonra, ölçümler ve kapsayıcı günlükleri Linux için Log Analytics aracısının kapsayıcılı bir sürümü aracılığıyla otomatik olarak toplanır. Ölçümler Azure İzleyici'deki ölçüm veritabanına gönderilir. Günlük verileri Log Analytics çalışma alanınıza gönderilir. Bu, hem AKS kümesi hem de üzerinde çalışan kapsayıcılı uygulamalar için izleme ve telemetri verilerini almanıza olanak tanır. Daha fazla bilgi için bkz . Azure İzleyici ile AKS'yi izleme.

Container Insights'a alternatif veya yardımcı bir çözüm olarak, AKS kümenizi Prometheus için Azure İzleyici yönetilen hizmetinde ölçümleri toplayacak şekilde yapılandırabilirsiniz. Bu yapılandırma, Prometheus projesini temel alan Prometheus uyumlu bir izleme çözümü kullanarak ölçümleri büyük ölçekte toplamanızı ve analiz etmenizi sağlar. Tam olarak yönetilen hizmet, izlenen altyapının ve iş yüklerinin performansını analiz etmek ve temel altyapıyı çalıştırmaya gerek kalmadan uyarılar almak için Prometheus sorgu dilini (PromQL) kullanmanıza olanak tanır.

Prometheus için Azure İzleyici yönetilen hizmeti, Azure İzleyici Ölçümleri'nin bir bileşenidir. Azure İzleyici'yi kullanarak toplayabileceğiniz ve çözümleyebileceğiniz ölçüm verisi türlerinde daha fazla esneklik sağlar. Prometheus ölçümleri bazı özellikleri platform ve özel ölçümlerle paylaşır, ancak PromQL ve Grafana gibi açık kaynak araçları daha iyi desteklemek için bazı ek özelliklere sahiptir.

Prometheus için Azure İzleyici yönetilen hizmetini hem Azure Yönetilen Grafana hem de azure sanal makinesinde çalıştırılabilen şirket içinde barındırılan Grafana için bir veri kaynağı olarak yapılandırabilirsiniz. Daha fazla bilgi için bkz . Yönetilen sistem kimliğini kullanarak Grafana için veri kaynağı olarak Prometheus için Azure İzleyici yönetilen hizmetini kullanma.

AKS eklentileri

Service Fabric'ten AKS'ye geçiş yaparken eklentileri ve uzantıları kullanmayı düşünmelisiniz. AKS, Kubernetes Event-driven Autoscaling (KEDA) ve GitOps Flux v2 gibi eklentiler ve uzantılar aracılığıyla kümeleriniz için desteklenen ek işlevler sağlar. Açık kaynak projeler ve üçüncü taraflar tarafından sağlanan daha birçok tümleştirme AKS ile yaygın olarak kullanılır. AKS destek ilkesi açık kaynak ve üçüncü taraf tümleştirmelerini kapsamaz. Daha fazla bilgi için bkz . AKS ile eklentiler, uzantılar ve diğer tümleştirmeler.

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:

• Ally Ford | Product Manager II
• Paolo Salvatori | Baş Müşteri Mühendisi
• Brandon Smith | Program Yöneticisi II

Diğer katkıda bulunanlar:

• Mick Alberts | Teknik Yazar
• Ayobami Ayodeji | Üst Düzey Program Yöneticisi
• Moumita Dey Verma | Kıdemli Bulut Çözümleri Mimarı
• Francis Simy Nazareth | Kıdemli Teknoloji Uzmanı

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

Sonraki adımlar

• AKS haberleri: AKS sürüm notları, AKS Yol Haritası ve Azure güncelleştirmeleri
• Mevcut uygulamaları kapsayıcıya almak için Windows kapsayıcılarını kullanma
• AKS hakkında sık sorulan sorular

İlgili makaleler

• Service Fabric'ten AKS'ye örnek geçiş
• AKS kümesi için temel mimari
• AKS mimarisi tasarımı