Azure Kubernetes Service'te mikro hizmetler mimarisi

Bu başvuru mimarisi, Azure Kubernetes Service'e (AKS) dağıtılan bir mikro hizmet uygulamasını gösterir. Çoğu dağıtım için başlangıç noktası olabilecek temel bir AKS yapılandırmasını açıklar. Bu makalede Kubernetes hakkında temel bilgiler varsayılmaktadır. Makale temel olarak AKS üzerinde mikro hizmet mimarisi çalıştırmaya yönelik altyapı ve DevOps konularına odaklanır. Mikro hizmetler tasarlama hakkında yönergeler için bkz . Azure'da mikro hizmetler oluşturma.

Bu mimarinin başvuru uygulaması GitHub'da kullanılabilir.

Mimari

Bu mimarinin bir Visio dosyasını indirin.

AKS Temel mimarisi üzerine oluşturulmuş daha gelişmiş bir mikro hizmetler örneği görmek isterseniz bkz. Gelişmiş Azure Kubernetes Service (AKS) mikro hizmetler mimarisi

Workflow

Mimari aşağıdaki bileşenlerden oluşur.

Azure Kubernetes Service (AKS). AKS, Azure bulutunda barındırılan yönetilen bir Kubernetes kümesidir. Azure, Kubernetes API hizmetini yönetir ve yalnızca aracı düğümlerini yönetmeniz gerekir.

Sanal ağ. Varsayılan olarak AKS, aracı düğümlerinin bağlı olduğu bir sanal ağ oluşturur. Alt ağ yapılandırması, şirket içi bağlantı ve IP adresleme gibi öğeleri denetlemenize olanak tanıyan daha gelişmiş senaryolar için önce sanal ağı oluşturabilirsiniz. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) gelişmiş ağ yapılandırma.

Giriş. Giriş sunucusu, küme içindeki hizmetlere HTTP(S) yollarını kullanıma sunar. Daha fazla bilgi için aşağıdaki API Gateway bölümüne bakın.

Azure Load Balancer. AKS kümesi oluşturduktan sonra, küme yük dengeleyiciyi kullanmaya hazırdır. Ardından, NGINX hizmeti dağıtıldıktan sonra yük dengeleyici giriş denetleyicinizi önleyecek yeni bir genel IP ile yapılandırılır. Bu şekilde yük dengeleyici İnternet trafiğini girişe yönlendirir.

Dış veri depoları. Mikro hizmetler genellikle durum bilgisi olmayan ve Azure SQL Veritabanı veya Azure Cosmos DB gibi dış veri depolarına yazma durumu sağlar.

Microsoft Entra Id. AKS, Azure yük dengeleyicileri gibi diğer Azure kaynaklarını oluşturmak ve yönetmek için Bir Microsoft Entra kimliği kullanır. Microsoft Entra Id, istemci uygulamalarında kullanıcı kimlik doğrulaması için de önerilir.

Azure Container Registry. Kümeye dağıtılan özel Docker görüntülerini depolamak için Container Registry'yi kullanın. AKS, Microsoft Entra kimliğini kullanarak Container Registry ile kimlik doğrulaması yapabilir. AKS, Azure Container Registry gerektirmez. Docker Hub gibi diğer kapsayıcı kayıt defterlerini kullanabilirsiniz. Kapsayıcı kayıt defterinizin iş yükünüz için hizmet düzeyi sözleşmesiyle (SLA) eşleştiğinden veya aştığından emin olun.

Azure Pipelines. Azure Pipelines, Azure DevOps Services'ın bir parçasıdır ve otomatik derlemeler, testler ve dağıtımlar çalıştırır. Jenkins gibi üçüncü taraf CI/CD çözümlerini de kullanabilirsiniz.

Helm' i seçin. Helm, Kubernetes nesnelerini yayımlanabilen, dağıtılan, sürümlenebilen ve güncelleştirilebilen tek bir ünitede paketlemenin ve genelleştirmenin bir yolu olan Kubernetes için bir paket yöneticisidir.

Azure İzleyici. Azure İzleyici, Azure hizmetleri için ölçümleri ve günlükleri, uygulama telemetrisini ve platform ölçümlerini toplar ve depolar. Uygulamayı izlemek, uyarıları, panoları ayarlamak ve hataların kök neden analizini gerçekleştirmek için bu verileri kullanın. Azure İzleyici, denetleyicilerden, düğümlerden ve kapsayıcılardan ölçüm toplamak için AKS ile tümleşir.

Dikkat edilmesi gerekenler

Tasarla

Bu başvuru mimarisi mikro hizmet mimarilerine odaklanmıştır, ancak önerilen uygulamaların çoğu AKS üzerinde çalışan diğer iş yükleri için geçerlidir.

Mikro Hizmetler

Mikro hizmet, gevşek bir şekilde bağlanmış, bağımsız olarak dağıtılabilir bir kod birimidir. Mikro hizmetler genellikle iyi tanımlanmış API'ler aracılığıyla iletişim kurar ve bir tür hizmet bulma yoluyla bulunabilir. Podlar hareket ettiğinde bile hizmete her zaman ulaşılabilir olmalıdır. Kubernetes Service nesnesi, Kubernetes'te mikro hizmetleri modellemenin doğal bir yoludur.

API ağ geçidi

API ağ geçitleri genel bir mikro hizmet tasarım desenidir. Api ağ geçidi , dış istemcilerle mikro hizmetler arasında yer alır. İstemcilerden gelen istekleri mikro hizmetlere yönlendiren ters ara sunucu işlevi görür. Ayrıca kimlik doğrulaması, SSL sonlandırma ve hız sınırlama gibi çeşitli çapraz kesme görevleri de gerçekleştirebilir. Daha fazla bilgi için bkz.

• Mikro hizmetlerde API ağ geçitlerini kullanma
• Ağ geçidi teknolojisi seçme

Kubernetes'te API ağ geçidinin işlevselliği öncelikli olarak bir Giriş denetleyicisi tarafından işlenir. Dikkat edilmesi gerekenler Giriş bölümünde açıklanmıştır.

Veri depolama

Mikro hizmetler mimarisinde hizmetler veri depolama çözümlerini paylaşmamalıdır. Hizmetler arasında gizli bağımlılıkları önlemek için her hizmetin kendi veri kümesini yönetmesi gerekir. Veri ayrımı, hizmetler arasında yanlışlıkla bağlantı oluşmasını önlemeye yardımcı olur. Bu durum hizmetler aynı temel veri şemalarını paylaştığında gerçekleşebilir. Ayrıca, hizmetler kendi veri depolarını yönettiğinde, kendi gereksinimleri için doğru veri depolarını kullanabilir.

Daha fazla bilgi için bkz . Mikro hizmetler tasarlama: Verilerle ilgili dikkat edilmesi gerekenler.

Verileri düğüme bağladığı için kalıcı verileri yerel küme depolama alanında depolamaktan kaçının. Bunun yerine Azure SQL Veritabanı veya Azure Cosmos DB gibi bir dış hizmet kullanın. Bir diğer seçenek de Azure Diskleri veya Azure Dosyalar kullanarak bir çözüme kalıcı veri birimi bağlamaktır.

Daha fazla bilgi için bkz. Azure Kubernetes Service'te uygulama seçenekleri Depolama.

Servis nesnesi

Kubernetes Service nesnesi, hizmet bulunabilirliği için mikro hizmet gereksinimleriyle eşleşen bir dizi özellik sağlar:

• IP adresi. Service nesnesi, bir pod grubu (ReplicaSet) için statik bir iç IP adresi sağlar. Podlar oluşturulurken veya taşınırken hizmete her zaman bu iç IP adresinden erişilebilir.

• Yük dengeleme. Hizmetin IP adresine gönderilen trafik, podlara yük dengelemesi yapılır.

• Hizmet bulma. Hizmetlere Kubernetes DNS hizmeti tarafından iç DNS girişleri atanır. Bu, API ağ geçidinin DNS adını kullanarak bir arka uç hizmetini çağırabileceği anlamına gelir. Hizmet-hizmet iletişimi için aynı mekanizma kullanılabilir. DNS girişleri ad alanına göre düzenlenir, dolayısıyla ad alanlarınız sınırlanmış bağlamlara karşılık geliyorsa, bir hizmetin DNS adı doğal olarak uygulama etki alanına eşlenir.

Aşağıdaki diyagramda hizmetler ve podlar arasındaki kavramsal ilişki gösterilmektedir. Uç nokta IP adreslerine ve bağlantı noktalarına gerçek eşleme Kubernetes ağ proxy'si kube-proxy tarafından yapılır.

Giriş

Kubernetes'te Giriş denetleyicisi API ağ geçidi desenini uygulayabilir. Bu durumda, Giriş ve Giriş denetleyicisi şu özellikleri sağlamak için birlikte çalışır:

• İstemci isteklerini sağ arka uç hizmetlerine yönlendirin. Bu yönlendirme, istemciler için tek bir uç nokta sağlar ve istemcileri hizmetlerden ayırmaya yardımcı olur.

• İstemci ile arka uç arasındaki sohbeti azaltmak için birden çok isteği tek bir istekte toplama.

• SSL sonlandırma, kimlik doğrulaması, IP kısıtlamaları veya istemci hızı sınırlama (azaltma) gibi arka uç hizmetlerinden işlevselliği boşaltın.

Giriş, bir ara sunucunun yapılandırma ayarlarını soyutlar. Girişin temel uygulamasını sağlayan bir Giriş denetleyicisine de ihtiyacınız vardır. Nginx, HAProxy, Traefik ve Azure Uygulaması lication Gateway için giriş denetleyicileri de vardır.

Giriş kaynağı farklı teknolojiler tarafından yerine getirilebilir. Birlikte çalışmak için kümenin içindeki Giriş denetleyicisi olarak dağıtılması gerekir. Kenar yönlendiricisi veya ters ara sunucu olarak çalışır. Ters ara sunucu olası bir performans sorunu veya tek hata noktası olduğundan, yüksek kullanılabilirlik için her zaman en az iki çoğaltma dağıtın.

Çoğu zaman, proxy sunucusunu yapılandırmak için karmaşık dosyalar gerekir. Bu, uzman değilseniz ayarlamak zor olabilir. Bu nedenle, Giriş denetleyicisi güzel bir soyutlama sağlar. Giriş denetleyicisinin Kubernetes API'sine de erişimi olduğundan yönlendirme ve yük dengeleme hakkında akıllı kararlar alabilir. Örneğin, Nginx giriş denetleyicisi kube-proxy ağ ara sunucusunu atlar.

Öte yandan, ayarlar üzerinde tam denetime ihtiyacınız varsa, bu soyutlamayı atlayıp proxy sunucusunu el ile yapılandırmak isteyebilirsiniz. Daha fazla bilgi için bkz . Nginx veya HAProxy'yi Kubernetes'e dağıtma.

Azure'daki yük dengeleme hizmetleri hakkında bilgi için bkz . Azure'da yük dengeleme seçeneklerine genel bakış.

TLS/SSL şifrelemesi

Yaygın uygulamalarda, GIRIŞ denetleyicisi SSL sonlandırması için kullanılır. Bu nedenle, Giriş denetleyicisini dağıtmanın bir parçası olarak bir TLS sertifikası oluşturmanız gerekir. Otomatik olarak imzalanan sertifikaları yalnızca geliştirme/test amacıyla kullanın. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) HTTPS giriş denetleyicisi oluşturma ve kendi TLS sertifikalarınızı kullanma.

Üretim iş yükleri için, güvenilen sertifika yetkililerinden (CA) imzalı sertifikalar alın. Let's Encrypt sertifikalarını oluşturma ve yapılandırma hakkında bilgi için bkz. Azure Kubernetes Service'te (AKS) statik genel IP adresiyle giriş denetleyicisi oluşturma.

Sertifikalarınızı kuruluşun ilkelerine göre de döndürmeniz gerekebilir. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) sertifikaları döndürme.

Ad Alanları

Küme içindeki hizmetleri düzenlemek için ad alanlarını kullanın. Kubernetes kümesindeki her nesne bir ad alanına aittir. Varsayılan olarak, yeni bir nesne oluşturduğunuzda bu nesne ad alanına default gider. Ancak, kümedeki kaynakları düzenlemeye yardımcı olmak için daha açıklayıcı ad alanları oluşturmak iyi bir uygulamadır.

İlk olarak, ad alanları adlandırma çakışmalarını önlemeye yardımcı olur. Aynı kümeye yüzlerce mikro hizmet içeren birden çok ekip mikro hizmet dağıttığında, hepsinin aynı ad alanına girip girmediğini yönetmek zorlaşır. Ayrıca, ad alanları şunları yapmanızı sağlar:

• Ad alanına atanan toplam pod kümesinin ad alanının kaynak kotasını aşmaması için ad alanına kaynak kısıtlamaları uygulayın.

• RBAC ve güvenlik ilkeleri dahil olmak üzere ad alanı düzeyinde ilkeler uygulayın.

Mikro hizmetler mimarisi için, mikro hizmetleri sınırlanmış bağlamlar halinde düzenlemeyi ve her sınırlanmış bağlam için ad alanları oluşturmayı göz önünde bulundurun. Örneğin, "Sipariş Karşılama" sınırlanmış bağlamı ile ilgili tüm mikro hizmetler aynı ad alanına gidebilir. Alternatif olarak, her geliştirme ekibi için bir ad alanı oluşturun.

Yardımcı program hizmetlerini kendi ayrı ad alanlarına yerleştirin. Örneğin, küme izleme için Elasticsearch veya Prometheus veya Helm için Tiller dağıtabilirsiniz.

Durum araştırmaları

Kubernetes, bir podun kullanıma çıkarabileceği iki tür sistem durumu araştırması tanımlar:

• Hazırlık yoklaması: Kubernetes'e podun istekleri kabul etmeye hazır olup olmadığını bildirir.

• Canlılık araştırması: Kubernetes'e bir podun kaldırılıp kaldırılmayacağını ve yeni bir örneğin başlatılıp başlatılmayacağını bildirir.

Yoklamaları düşünürken Kubernetes'te bir hizmetin nasıl çalıştığını anımsamak yararlı olur. Bir hizmetin bir dizi (sıfır veya daha fazla) podla eşleşen bir etiket seçicisi vardır. Kubernetes, seçiciyle eşleşen podlara gelen trafiği dengeler. Yalnızca başarıyla başlatılan ve iyi durumda olan podlar trafik alır. Bir kapsayıcı kilitlenirse Kubernetes podu öldürür ve bir değişiklik zamanlar.

Bazen, pod başarıyla başlatılsa bile bir pod trafik almaya hazır olmayabilir. Örneğin, kapsayıcıda çalışan uygulamanın öğeleri belleğe yüklediği veya yapılandırma verilerini okuduğu başlatma görevleri olabilir. Podun iyi durumda olduğunu ancak trafiği almaya hazır olmadığını belirtmek için bir hazırlık yoklaması tanımlayın.

Canlılık yoklamaları, podun çalışmaya devam ettiği, ancak iyi durumda olmadığı ve geri dönüştürülmesi gereken durumu ele alır. Örneğin, bir kapsayıcının HTTP isteklerine hizmet ettiğini ancak bir nedenden dolayı yanıt vermiyor olduğunu varsayalım. Kapsayıcı kilitlenmez, ancak herhangi bir isteğin sunulmasını durdurdu. BIR HTTP canlılık yoklaması tanımlarsanız, yoklama yanıt vermeyi durdurur ve kubernetes'e podu yeniden başlatmasını bildirir.

Araştırma tasarlarken dikkat edilmesi gereken bazı noktalar şunlardır:

• Kodunuzun başlangıç süresi uzunsa, başlatma tamamlanmadan önce canlılık yoklaması hata bildirecektir. Bu yoklama hatasını önlemek için, yoklamanın başlatılmasını initialDelaySeconds geciktiren ayarı kullanın.

• Canlılık yoklaması, podun yeniden başlatılmasının durumu iyi duruma getirilmediği sürece işe yaramaz. Bellek sızıntılarına veya beklenmeyen kilitlenmelere karşı hafifletmek için canlılık araştırması kullanabilirsiniz, ancak hemen yeniden başarısız olacak bir podu yeniden başlatmanın bir anlamı yoktur.

• Bazen bağımlı hizmetleri denetlemek için hazır olma yoklamaları kullanılır. Örneğin, bir podun veritabanına bağımlılığı varsa, yoklama veritabanı bağlantısını denetleyebilir. Ancak bu yaklaşım beklenmeyen sorunlar oluşturabilir. Dış hizmet bazı nedenlerden dolayı geçici olarak kullanılamıyor olabilir. Bu, hazır olma yoklamasının hizmetinizdeki tüm podlar için başarısız olmasına neden olur ve bunların tümünün yük dengelemeden kaldırılmasına ve böylece yukarı akışta basamaklı hatalar oluşturmasına neden olur. Hizmetinizin geçici hatalardan doğru şekilde kurtarabilmesi için hizmetinizde yeniden deneme işlemeyi uygulamak daha iyi bir yaklaşımdır.

Kaynak kısıtlamaları

Kaynak çekişmesi bir hizmetin kullanılabilirliğini etkileyebilir. Tek bir kapsayıcının küme kaynaklarını (bellek ve CPU) bunaltmaması için kapsayıcılar için kaynak kısıtlamaları tanımlayın. İş parçacıkları veya ağ bağlantıları gibi kapsayıcı dışı kaynaklar için kaynakları yalıtmak için Bulkhead Desenini kullanmayı göz önünde bulundurun.

Bir ad alanı için izin verilen toplam kaynağı sınırlamak için kaynak kotalarını kullanın. Bu şekilde, ön uç kaynaklar için arka uç hizmetlerini aç bırakamaz veya tam tersi de geçerlidir.

Güvenlik

Rol tabanlı erişim denetimi (RBAC)

Kubernetes ve Azure rol tabanlı erişim denetimi (RBAC) için mekanizmalara sahiptir:

• Azure RBAC, yeni Azure kaynakları oluşturma özelliği de dahil olmak üzere Azure'daki kaynaklara erişimi denetler. İzinler kullanıcılara, gruplara veya hizmet sorumlularına atanabilir. (Hizmet sorumlusu, uygulamalar tarafından kullanılan bir güvenlik kimliğidir.)

• Kubernetes RBAC, Kubernetes API'sine yönelik izinleri denetler. Örneğin, pod oluşturma ve podları listeleme, Kubernetes RBAC aracılığıyla kullanıcıya yetkilendirilebilen (veya reddedilebilen) eylemlerdir. Kullanıcılara Kubernetes izinleri atamak için roller ve rol bağlamaları oluşturursunuz:

  • Rol, bir ad alanı içinde geçerli olan bir izin kümesidir. İzinler kaynaklar (podlar, dağıtımlar vb.) üzerinde fiiller (alma, güncelleştirme, oluşturma, silme) olarak tanımlanır.

  • RoleBinding, bir Role kullanıcı veya grup atar.

  • Ayrıca rol gibi olan ancak tüm ad alanları genelinde kümenin tamamı için geçerli olan bir ClusterRole nesnesi de vardır. ClusterRole'a kullanıcı veya grup atamak için bir ClusterRoleBinding oluşturun.

AKS bu iki RBAC mekanizmasını tümleştirir. AKS kümesi oluşturduğunuzda, bunu kullanıcı kimlik doğrulaması için Microsoft Entra Id kullanacak şekilde yapılandırabilirsiniz. Bunun nasıl ayarlanacağı hakkında ayrıntılı bilgi için bkz . Microsoft Entra ID'yi Azure Kubernetes Service ile tümleştirme.

Bu yapılandırıldıktan sonra, Kubernetes API'sine erişmek isteyen bir kullanıcının (örneğin, kubectl aracılığıyla) Microsoft Entra kimlik bilgilerini kullanarak oturum açması gerekir.

Varsayılan olarak, bir Microsoft Entra kullanıcısının kümeye erişimi yoktur. Erişim vermek için, küme yöneticisi Microsoft Entra kullanıcılarına veya gruplarına başvuran RoleBinding'ler oluşturur. Kullanıcının belirli bir işlem için izinleri yoksa başarısız olur.

Kullanıcıların varsayılan olarak erişimi yoksa, küme yöneticisinin rol bağlamalarını oluşturma izni ilk etapta nasıl olur? Aks kümesinin kubernetes API sunucusunu çağırmak için iki tür kimlik bilgisi vardır: küme kullanıcısı ve küme yöneticisi. Küme yöneticisi kimlik bilgileri kümeye tam erişim verir. Azure CLI komutu az aks get-credentials --admin , küme yöneticisi kimlik bilgilerini indirir ve bunları kubeconfig dosyanıza kaydeder. Küme yöneticisi, rolleri ve rol bağlamalarını oluşturmak için bu kubeconfig'i kullanabilir.

Kubernetes kümesi Rolü ve RoleBinding nesnelerini Kubernetes'te yerel olarak yönetmek yerine, Kubernetes Yetkilendirmesi için Azure RBAC kullanmak tercih edilir. Bu, Azure Kaynakları, AKS ve Kubernetes kaynakları arasında birleşik yönetim ve erişim denetimi sağlar. Bu Azure RBAC rol atamaları, daha ayrıntılı erişim denetimi için kümeyi veya küme içindeki ad alanlarını hedefleyebilir. Azure RBAC sınırlı bir varsayılan izin kümesini destekler ve bunu, gelişmiş veya daha ayrıntılı erişim desenlerini desteklemek için Rol ve Rol Bağlamalarını yönetmeye yönelik yerel Kubernetes mekanizmasıyla birleştirebilirsiniz. Etkinleştirildiğinde, Normal Kubernetes kullanıcıları ve hizmet hesapları özel olarak Kubernetes RBAC tarafından doğrulanırken, Microsoft Entra sorumluları yalnızca Azure RBAC tarafından doğrulanır.

Küme yöneticisi kimlik bilgileri çok güçlü olduğundan, bunlara erişimi kısıtlamak için Azure RBAC kullanın:

• "Azure Kubernetes Service Cluster Yönetici Rolü" küme yöneticisi kimlik bilgilerini indirme iznine sahiptir. Bu role yalnızca küme yöneticileri atanmalıdır.

• "Azure Kubernetes Hizmet Kümesi Kullanıcı Rolü", küme kullanıcı kimlik bilgilerini indirme iznine sahiptir. Yönetici olmayan kullanıcılar bu role atanabilir. Bu rol, küme içindeki Kubernetes kaynakları üzerinde belirli izinler vermez; yalnızca kullanıcının API sunucusuna bağlanmasına izin verir.

RBAC ilkelerinizi tanımlarken (hem Kubernetes hem de Azure), kuruluşunuzdaki rolleri düşünün:

• Kimler AKS kümesi oluşturup silebilir ve yönetici kimlik bilgilerini indirebilir?
• Kümeyi kim yönetebilir?
• Ad alanı içinde kimler kaynak oluşturabilir veya güncelleştirebilir?

Kubernetes RBAC izinlerini ClusterRoles ve ClusterRoleBindings yerine Roles ve RoleBindings kullanarak ad alanına göre kapsamlandırmak iyi bir uygulamadır.

Son olarak AKS kümesinin yük dengeleyiciler, ağ veya depolama gibi Azure kaynaklarını oluşturması ve yönetmesi için hangi izinlere sahip olduğu sorusu vardır. Azure API'leri ile kimliğini doğrulamak için küme bir Microsoft Entra hizmet sorumlusu kullanır. Kümeyi oluştururken bir hizmet sorumlusu belirtmezseniz, otomatik olarak bir hizmet sorumlusu oluşturulur. Ancak, önce hizmet sorumlusunu oluşturmak ve en düşük RBAC izinlerini atamak iyi bir güvenlik uygulamasıdır. Daha fazla bilgi için bkz . Azure Kubernetes Service ile hizmet sorumluları.

Gizli dizi yönetimi ve uygulama kimlik bilgileri

Uygulamalar ve hizmetler genellikle Azure Depolama veya SQL Veritabanı gibi dış hizmetlere bağlanmalarına olanak sağlayan kimlik bilgilerine ihtiyaç duyar. Zorluk, bu kimlik bilgilerini güvende tutmak ve sızdırmamaktır.

Azure kaynakları için bir seçenek yönetilen kimlikleri kullanmaktır. Yönetilen kimlik fikri, bir uygulama veya hizmetin Microsoft Entra Id'de depolanan bir kimliği olması ve azure hizmetiyle kimlik doğrulaması yapmak için bu kimliği kullanmasıdır. Uygulama veya hizmet, Microsoft Entra Kimliği'nde bunun için oluşturulmuş bir Hizmet Sorumlusuna sahiptir ve OAuth 2.0 belirteçlerini kullanarak kimlik doğrulaması yapar. Yürütülen işlem kodu, kullanılacak belirteci saydam bir şekilde alabilir. Bu şekilde, herhangi bir parola veya bağlantı dizesi depolamanız gerekmez. Microsoft Entra İş Yükü Kimliği (önizleme) kullanarak tek tek podlara Microsoft Entra kimlikleri atayarak AKS'de yönetilen kimlikleri kullanabilirsiniz.

Şu anda tüm Azure hizmetleri yönetilen kimlikleri kullanarak kimlik doğrulamayı desteklemez. Liste için bkz . Microsoft Entra kimlik doğrulamasını destekleyen Azure hizmetleri.

Yönetilen kimliklerle bile, yönetilen kimlikleri, üçüncü taraf hizmetleri, API anahtarlarını vb. desteklemeyen Azure hizmetleri için bazı kimlik bilgilerini veya diğer uygulama gizli dizilerini depolamanız gerekebilir. Gizli dizileri güvenli bir şekilde depolamak için bazı seçenekler şunlardır:

• Azure Key Vault. AKS'de, Key Vault'tan bir veya daha fazla gizli diziyi birim olarak bağlayabilirsiniz. Birim, Key Vault'tan gizli dizileri okur. Pod daha sonra gizli dizileri normal bir birim gibi okuyabilir. Daha fazla bilgi için bkz. AKS kümesinde Gizli Dizi Deposu CSI Sürücüsü için Azure Key Vault Sağlayıcısı'nı kullanma.

  Pod, bir iş yükü kimliği veya kullanıcı ya da sistem tarafından atanan yönetilen kimlik kullanarak kimliğini doğrular. Daha fazla dikkat edilmesi gerekenler için bkz . Gizli Dizi Deposu CSI Sürücüsü için Azure Key Vault Sağlayıcısı'na erişmek için kimlik sağlama.

• HashiCorp Kasası. Kubernetes uygulamaları, Microsoft Entra ile yönetilen kimlikleri kullanarak HashiCorp Vault ile kimlik doğrulaması yapabilir. Bkz . HashiCorp Vault Microsoft Entra Id konuşuyor. Kasayı Kubernetes'e dağıtabilir, uygulama kümenizden ayrı bir ayrılmış kümede çalıştırmayı düşünebilirsiniz.

• Kubernetes gizli dizileri. Bir diğer seçenek de Kubernetes gizli dizilerini kullanmaktır. Bu seçenek, yapılandırılması en kolay seçenektir ancak bazı zorluklara sahiptir. Gizli diziler, dağıtılmış bir anahtar-değer deposu olan etcd'de depolanır. AKS bekleyen vb.'yi şifreler. Şifreleme anahtarlarını Microsoft yönetir.

HashiCorp Vault veya Azure Key Vault gibi bir sistem kullanmak aşağıdakiler gibi çeşitli avantajlar sağlar:

• Gizli dizilerin merkezi kontrolü.
• Tüm gizli dizilerin beklemede şifrelenmesini sağlama.
• Merkezi anahtar yönetimi.
• Gizli dizilerin denetimine erişin.
• Denetim

Kapsayıcı ve Orchestrator güvenliği

Podlarınızın ve kapsayıcılarınızın güvenliğini sağlamaya yönelik önerilen yöntemler şunlardır:

• Tehdit izleme: Kapsayıcılar için Microsoft Defender'ı (veya üçüncü taraf özelliklerini) kullanarak tehditleri izleyin. Kapsayıcıları bir VM'de barındıriyorsanız, sunucular için Microsoft Defender'ı veya üçüncü taraf bir özelliği kullanın. Ayrıca Azure İzleyici'deki Kapsayıcı İzleme çözümündeki günlükleri Microsoft Sentinel veya mevcut bir SIEM çözümüyle tümleştirebilirsiniz.

• Güvenlik açığı izleme: Azure Market aracılığıyla sağlanan Bulut için Microsoft Defender veya üçüncü taraf çözümü kullanarak bilinen güvenlik açıklarına yönelik görüntüleri ve çalışan kapsayıcıları sürekli izleyin.

• Azure Container Registry'nin bir özelliği olan ACR Görevlerini kullanarak görüntü düzeltme eki uygulama işlemini otomatikleştirin. Kapsayıcı görüntüsü katmanlardan oluşturulur. Temel katmanlar, ASP.NET Core veya Node.js gibi işletim sistemi görüntüsünü ve uygulama çerçevesi görüntülerini içerir. Temel görüntüler genellikle uygulama geliştiricilerinden yukarı akış oluşturulur ve diğer proje bakımcıları tarafından korunur. Bu görüntüler yukarı akışa düzeltme eki eklendiğinde, bilinen güvenlik açıklarını bırakmamak için kendi görüntülerinizi güncelleştirmeniz, test etmek ve yeniden dağıtmanız önemlidir. ACR Görevleri bu işlemi otomatikleştirmeye yardımcı olabilir.

• Görüntüleri Azure Container Registry veya Docker Trusted Registry gibi güvenilir bir özel kayıt defterinde depolayın. Podların yalnızca güvenilen kayıt defterinden görüntü çekebilmesini sağlamak için Kubernetes'te doğrulayıcı bir erişim web kancası kullanın.

• En Az Ayrıcalık Uygula ilkesi

  • Kapsayıcıları ayrıcalıklı modda çalıştırmayın. Ayrıcalıklı mod, konak üzerindeki tüm cihazlara kapsayıcı erişimi sağlar.
  • Mümkün olduğunda, işlemleri kapsayıcıların içinde kök olarak çalıştırmaktan kaçının. Kapsayıcılar güvenlik açısından tam yalıtım sağlamaz, bu nedenle kapsayıcı işlemini ayrıcalıklı olmayan bir kullanıcı olarak çalıştırmak daha iyidir.

DevOps

Bu başvuru mimarisi, bulut kaynaklarını ve bağımlılıklarını sağlamaya yönelik bir Azure Resource Manager şablonu sağlar. [Azure Resource Manager şablonları][arm-template] kullanımıyla, üretim senaryolarını çoğaltmak gibi farklı ortamları dakikalar içinde sağlamak için Azure DevOps Services'i kullanabilirsiniz. Bu, maliyet tasarrufu yapmanızı ve yük testi ortamını yalnızca gerektiğinde sağlamanızı sağlar.

ARM şablonunuzu yapılandırmak için iş yükü yalıtım ölçütlerini takip etmeyi göz önünde bulundurun; bir iş yükü genellikle rastgele bir işlev birimi olarak tanımlanır; örneğin, küme için ayrı bir şablona ve bağımlı hizmetler için başka bir şablona sahip olabilirsiniz. İş yükü yalıtımı, her iş yükü ilgili DevOps ekibi tarafından ilişkilendirildiğinden ve yönetildiğinden DevOps'un sürekli tümleştirme ve sürekli teslim (CI/CD) gerçekleştirmesini sağlar.

Dağıtım (CI/CD) ile ilgili dikkat edilmesi gerekenler

Mikro hizmet mimarisi için sağlam bir CI/CD işleminin bazı hedefleri şunlardır:

• Her ekip, sahip olduğu hizmetleri diğer ekipleri etkilemeden veya kesintiye uğratmadan bağımsız olarak derleyebilir ve dağıtabilir.
• Hizmetin yeni bir sürümü üretime dağıtılmadan önce doğrulama için geliştirme/test/Soru-Cevap ortamlarına dağıtılır. Kalite kapıları her aşamada uygulanır.
• Hizmetin yeni bir sürümü, önceki sürümle yan yana dağıtılabilir.
• Yeterli erişim denetimi ilkeleri var.
• Kapsayıcılı iş yükleri için üretime dağıtılan kapsayıcı görüntülerine güvenebilirsiniz.

Zorluklar hakkında daha fazla bilgi edinmek için bkz . Mikro hizmet mimarileri için CI/CD.

Belirli öneriler ve en iyi yöntemler için bkz . Kubernetes'te mikro hizmetler için CI/CD.

Maliyet iyileştirme

Maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer önemli noktalar, Microsoft Azure İyi Tasarlanmış Çerçeve'nin Maliyet bölümünde açıklanmıştır.

Bu mimaride kullanılan bazı hizmetler için göz önünde bulundurmanız gereken bazı noktalar aşağıdadır.

Azure Kubernetes Service (AKS)

Kubernetes kümesinin dağıtım, yönetim ve işlemlerinde AKS için ilişkili maliyet yoktur. Yalnızca Kubernetes kümeniz tarafından kullanılan sanal makine örnekleri, depolama ve ağ kaynakları için ödeme gerçekleştirirsiniz.

Gerekli kaynakların maliyetini tahmin etmek için lütfen Kapsayıcı Hizmetleri hesaplayıcıya başvurun.

Azure Load Balancer

Yalnızca yapılandırılmış yük dengeleme ve giden kuralları için ücretlendirilirsiniz. Gelen NAT kuralları ücretsizdir. Kural yapılandırılmadığında Standart Load Balancer için saatlik ücret alınmaz.

Daha fazla bilgi için bkz . Azure Load Balancer Fiyatlandırması.

Azure Pipelines

Bu başvuru mimarisinde yalnızca Azure Pipelines kullanılır. Azure, Azure İşlem Hattı'nı tek bir Hizmet olarak sunar. CI/CD için ayda 1.800 dakika ve aylık sınırsız dakikası olan şirket içinde barındırılan bir iş ile Microsoft tarafından barındırılan ücretsiz bir işe izin verilir. Ek işlerde ücret uygulanır. Daha fazla bilgi için bkz. Azure DevOps Services Fiyatlandırması.

Azure İzleyici

Azure İzleyici Log Analytics için veri alımı ve saklama için ücretlendirilirsiniz. Daha fazla bilgi için bkz . Azure İzleyici Fiyatlandırması.

Bu senaryoyu dağıtın

Bu mimariye yönelik başvuru uygulamasını dağıtmak için GitHub deposundaki adımları izleyin.

Sonraki adımlar

• Azure Kubernetes Service ile hizmet sorumluları
• Kapsayıcılar için Microsoft Defender
• Sunucular için Microsoft Defender
• Azure İzleyici'de Kapsayıcı İzleme çözümü
• Microsoft Sentinel veya mevcut bir SIEM çözümü.
• Bulut için Microsoft Defender veya Azure Market aracılığıyla kullanılabilen üçüncü taraf bir çözüm.
• ACR Görevleri

İlgili kaynaklar

• Daha gelişmiş bir mikro hizmetler örneğiyle çalışmak için bkz . Gelişmiş Azure Kubernetes Service (AKS) mikro hizmetler mimarisi
• Bu mimariyi izleme hakkında bilgi edinmek için bkz . Azure Kubernetes Service'te (AKS) mikro hizmet mimarisini izleme.
• Bu uygulamanın performansını nasıl ölçtük öğrenmek için bkz . Performans ayarlama senaryosu: Dağıtılmış iş işlemleri.
• Mikro hizmetler mimarileri için CI/CD
• Kubernetes'te mikro hizmetler için CI/CD