Azure Kubernetes Service (AKS) üzerinde mikro hizmetler mimarisiMicroservices architecture on Azure Kubernetes Service (AKS)

Bu başvuru mimarisi, Azure Kubernetes Service (AKS) için Dağıtılmış bir mikro Hizmetler uygulaması gösterir.This reference architecture shows a microservices application deployed to Azure Kubernetes Service (AKS). Bu, çoğu dağıtım için başlangıç noktası olabilir temel bir AKS yapılandırma açıklanmaktadır.It describes a basic AKS configuration that can be the starting point for most deployments. Bu makalede Kubernetes temel bilgiye varsayılır.This article assumes basic knowledge of Kubernetes. Makaleyi ağırlıklı olarak altyapı ve mikro hizmet mimarisi AKS'de çalışan DevOps konuları ele alınmaktadır.The article focuses mainly on the infrastructure and DevOps considerations of running a microservices architecture on AKS. Mikro hizmetler tasarlama konusunda rehberlik için bkz Azure üzerinde mikro hizmetler oluşturma.For guidance on how to design microservices, see Building microservices on Azure.

GitHub logosu Bu mimarinin bir başvuru uygulaması edinilebilir GitHub.GitHub logo A reference implementation of this architecture is available on GitHub.

AKS başvuru mimarisi

İndirme bir Visio dosyasını Bu mimarinin.Download a Visio file of this architecture.

MimariArchitecture

Mimari aşağıdaki bileşenlerden oluşur.The architecture consists of the following components.

Azure Kubernetes hizmeti (AKS).Azure Kubernetes Service (AKS). AKS, yönetilen bir Kubernetes kümesi dağıtır bir Azure hizmetidir.AKS is an Azure service that deploys a managed Kubernetes cluster.

Kubernetes kümesi.Kubernetes cluster. AKS, Kubernetes kümesini dağıtırken ve Kubernetes asıl yönetmek için sorumludur.AKS is responsible for deploying the Kubernetes cluster and for managing the Kubernetes masters. Yalnızca aracı düğümleri yönetin.You only manage the agent nodes.

Sanal ağ.Virtual network. Varsayılan olarak, AKS içinde aracı düğümlerini dağıtmak için sanal ağ oluşturur.By default, AKS creates a virtual network to deploy the agent nodes into. Daha Gelişmiş senaryolar için sanal ağ ilk olarak nasıl yapılandırılan alt ağ, şirket içi bağlantı ve IP adresleme gibi denetlemenize olanak sağlayan oluşturabilirsiniz.For more advanced scenarios, you can create the virtual network first, which lets you control things like how the subnets are configured, on-premises connectivity, and IP addressing. Daha fazla bilgi için Gelişmiş Yapılandırma Azure Kubernetes Service (AKS) ağ.For more information, see Configure advanced networking in Azure Kubernetes Service (AKS).

Giriş.Ingress. Bir giriş, küme içindeki hizmetlerde yolları HTTP (S) gösterir.An ingress exposes HTTP(S) routes to services inside the cluster. Daha fazla bilgi için konudaki API ağ geçidi aşağıda.For more information, see the section API Gateway below.

Azure Load Balancer.Azure Load Balancer. NGINX giriş denetleyicisine dağıtıldığında, bir Azure yük dengeleyici oluşturulur.An Azure Load Balancer is created when the NGINX ingress controller is deployed. Yük Dengeleyici, internet trafiğini girişi yönlendirir.The load balancer routes internet traffic to the ingress.

Dış veri depoları.External data stores. Mikro hizmetler, genellikle durum bilgisiz olduğundan ve Azure SQL veritabanı veya Cosmos DB gibi dış veri depolarına durumu yazma.Microservices are typically stateless and write state to external data stores, such as Azure SQL Database or Cosmos DB.

Azure Active Directory.Azure Active Directory. AKS, Azure yük dengeleyici gibi diğer Azure kaynaklarını oluşturmak ve yönetmek için bir Azure Active Directory (Azure AD) kimliğini kullanır.AKS uses an Azure Active Directory (Azure AD) identity to create and manage other Azure resources such as Azure load balancers. Ayrıca, Azure AD kullanıcı kimlik doğrulaması istemci uygulamaları için tavsiye edilir.Azure AD is also recommended for user authentication in client applications.

Azure kapsayıcı kayıt defteri.Azure Container Registry. Container Registry, kümeye dağıtılan özel Docker görüntülerini depolamak için kullanın.Use Container Registry to store private Docker images, which are deployed to the cluster. AKS, Azure AD kimliğini kullanarak Container Registry ile kimlik doğrulaması yapabilir.AKS can authenticate with Container Registry using its Azure AD identity. Azure Container Registry AKS gerektirmez unutmayın.Note that AKS does not require Azure Container Registry. Docker Hub gibi diğer kapsayıcı kayıt defterleri kullanabilirsiniz.You can use other container registries, such as Docker Hub.

Azure işlem hatları.Azure Pipelines. İşlem hatları Azure DevOps hizmetlerin bir parçası olan ve çalıştırmaları yapıları, testleri ve dağıtımları otomatik.Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments. Jenkins gibi üçüncü taraf CI/CD çözümleri de kullanabilirsiniz.You can also use third-party CI/CD solutions such as Jenkins.

Helm.Helm. Helm, Kubernetes için bir paket yöneticisi olarak — yayımlayabilmek için tek bir birimde Kubernetes nesnelerini paket için bir yol, dağıtma, sürüm ve güncelleştirme.Helm is as a package manager for Kubernetes — a way to bundle Kubernetes objects into a single unit that you can publish, deploy, version, and update.

Azure İzleyici.Azure Monitor. Azure İzleyici toplar ve ölçüm ve günlükleri, çözüm ve uygulama telemetrisini içinde Azure Hizmetleri için platform ölçümleri dahil olmak üzere saklar.Azure Monitor collects and stores metrics and logs, including platform metrics for the Azure services in the solution and application telemetry. Uygulamayı izleme, uyarılar ve panolar ayarlama ve hataların kök neden analizi gerçekleştirmek için bu verileri kullanın.Use this data to monitor the application, set up alerts and dashboards, and perform root cause analysis of failures. Azure İzleyici ölçümleri denetleyicileri, düğümleri ve kapsayıcılar, hem de kapsayıcı günlüklerini ve ana düğüm günlüklerini toplamak için AKS ile tümleştirebilirsiniz.Azure Monitor integrates with AKS to collect metrics from controllers, nodes, and containers, as well as container logs and master node logs.

Tasarım konusunda dikkat edilmesi gerekenlerDesign considerations

Önerilen uygulamalarının AKS'de çalışan iş yüklerine uygulanacak olsa da bu başvuru mimarisinde mikro hizmet mimarileri üzerinde odaklanır.This reference architecture is focused on microservices architectures, although many of the recommended practices will apply to other workloads running on AKS.

Mikro hizmetlerMicroservices

Kubernetes hizmeti, Kubernetes içindeki model mikro hizmetlere doğal bir yol nesnedir.The Kubernetes Service object is a natural way to model microservices in Kubernetes. Bir mikro hizmet kodu gevşek, bağımsız bir şekilde dağıtılabilen birimidir.A microservice is a loosely coupled, independently deployable unit of code. Mikro Hizmetler genellikle iyi tanımlanmış API'ler üzerinden iletişim kurar ve hizmet bulma çeşit bulunabilir.Microservices typically communicate through well-defined APIs, and are discoverable through some form of service discovery. Kubernetes hizmet nesnesi bu gereksinimleri karşılayan özellikleri sunmaktadır:The Kubernetes Service object provides a set of capabilities that match these requirements:

  • IP adresi.IP address. Hizmet nesnesi bir pod'ların (REPLICASET) grubu için statik iç IP adresi sağlar.The Service object provides a static internal IP address for a group of pods (ReplicaSet). Pod'ları oluşturulduğunda veya taşınabilir gibi her zaman bu iç IP adresi erişilebilir bir hizmettir.As pods are created or moved around, the service is always reachable at this internal IP address.

  • Yük dengeleme.Load balancing. Hizmetin IP adrese gönderilen trafik Yük Dengelemesi pod'ların ' dir.Traffic sent to the service's IP address is load balanced to the pods.

  • Hizmet bulma.Service discovery. Hizmetleri iç DNS girişlerini Kubernetes DNS hizmeti tarafından atanır.Services are assigned internal DNS entries by the Kubernetes DNS service. API ağ geçidi DNS adını kullanarak bir arka uç hizmetine çağrı yapabilir anlamına gelir.That means the API gateway can call a backend service using the DNS name. Aynı mekanizmayı hizmetten hizmete iletişimi için kullanılabilir.The same mechanism can be used for service-to-service communication. DNS girişlerini şekilde ad alanı tarafından düzenlenir, ad alanları sınırlanmış Bağlamlar karşılık ardından hizmet için DNS adını uygulama etki alanı için doğal olarak eşler.The DNS entries are organized by namespace, so if your namespaces correspond to bounded contexts, then the DNS name for a service will map naturally to the application domain.

Aşağıdaki diyagramda, hizmetleri ve pod'ları arasındaki kavramsal ilişkiyi gösterir.The following diagram show the conceptual relation between services and pods. Uç nokta IP adresleri ve bağlantı noktalarını eşleme kube-proxy tarafından Kubernetes ağ proxy gerçekleştirilir.The actual mapping to endpoint IP addresses and ports is done by kube-proxy, the Kubernetes network proxy.

Hizmetler ve pod'ları

API GatewayAPI Gateway

Bir API ağ geçidi dış istemcilerle mikro hizmetler arasında yer alan ağ geçidi.An API gateway is a gateway that sits between external clients and the microservices. İstemcilerden gelen yönlendirme isteklerini mikro Hizmetleri için ters proxy görevi görür.It acts as a reverse proxy, routing requests from clients to microservices. Ayrıca, kimlik doğrulaması, SSL sonlandırma ve oran sınırlandırma gibi çeşitli çapraz görevleri de gerçekleştirebilir.It may also perform various cross-cutting tasks such as authentication, SSL termination, and rate limiting.

Bir ağ geçidi tarafından sağlanan işlevselliği aşağıdaki şekilde gruplandırılabilir:Functionality provided by a gateway can be grouped as follows:

  • Ağ geçidi yönlendirme: İstemci isteklerini doğru arka uç hizmetlerine yönlendirme.Gateway Routing: Routing client requests to the right backend services. Bu istemciler için tek bir uç nokta sağlar ve istemcileri hizmetlerden ayırmanıza yardımcı olur.This provides a single endpoint for clients, and helps to decouple clients from services.

  • Ağ geçidi toplama: İstemci ve arka uç arasındaki iletişim yoğunluğunu azaltmak için tek bir istekte birden çok istek toplama.Gateway Aggregation: Aggregation of multiple requests into a single request, to reduce chattiness between the client and the backend.

  • Ağ geçidi boşaltma.Gateway Offloading. Bir ağ geçidi arka uç Hizmetleri, SSL sonlandırma, kimlik doğrulaması, IP beyaz listesi veya istemci hızı sınırlama (azaltma) gibi işlevleri boşaltabilirsiniz.A gateway can offload functionality from the backend services, such as SSL termination, authentication, IP whitelisting, or client rate limiting (throttling).

API ağ geçitleri olan genel mikro hizmet tasarım deseni.API gateways are a general microservices design pattern. Bir dizi farklı teknolojiler kullanılarak uygulanabilir.They can be implemented using a number of different technologies. Bir sınır yönlendiricisi veya küme içinde Ngınx, HAProxy veya Traefik, gibi ters proxy dağıtmak için en yaygın uygulama olabilir.Probably the most common implementation is to deploy an edge router or reverse proxy, such as Nginx, HAProxy, or Traefik, inside the cluster.

Diğer Seçenekler şunlardır:Other options include:

  • Azure Application Gateway ve/veya Azure API-kümesi dışında bulunan iki yönetilen Hizmetler Yönetimi.Azure Application Gateway and/or Azure API-Management, which are both managed services that reside outside of the cluster. Bir uygulama ağ geçidi giriş denetleyicisi şu anda beta sürümünde olan.An Application Gateway Ingress Controller is currently in beta.

  • Azure işlev proxy'leri.Azure Functions Proxies. Proxy'leri istekleri ve yanıtları ve URL'sini temel alarak istekleri değiştirebilirsiniz.Proxies can modify requests and responses and route requests based on URL.

Kubernetes giriş kaynak türü için bir proxy sunucusu için yapılandırma ayarlarını soyutlar.The Kubernetes Ingress resource type abstracts the configuration settings for a proxy server. Temel alınan uygulamasını giriş sağlar ve giriş denetleyicisine, birlikte çalışır.It works in conjunction with an ingress controller, which provides the underlying implementation of the Ingress. Vardır giriş denetleyicileri Ngınx, HAProxy Traefik ve Application Gateway (Önizleme), diğerlerinin yanı sıra.There are ingress controllers for Nginx, HAProxy, Traefik, and Application Gateway (preview), among others.

Proxy sunucusu yapılandırma giriş denetleyicisine işler.The ingress controller handles configuring the proxy server. Genellikle bu giriş denetleyicisine güzel bir soyutlamadır için uzman değilseniz ayarlamak zor olabilir karmaşık yapılandırma dosyaları, gerektirir.Often these require complex configuration files, which can be hard to tune if you aren't an expert, so the ingress controller is a nice abstraction. Ayrıca, yönlendirme hakkında akıllı kararlar ve Yük Dengeleme için giriş denetleyicisini Kubernetes API erişimi vardır.In addition, the Ingress Controller has access to the Kubernetes API, so it can make intelligent decisions about routing and load balancing. Örneğin, Ngınx giriş denetleyicisine kube-proxy ağ proxy atlar.For example, the Nginx ingress controller bypasses the kube-proxy network proxy.

Öte yandan, ayarlar üzerinde denetim tamamlamanız, bu soyutlamayı, atlama ve proxy sunucusunu el ile yapılandırmak isteyebilirsiniz.On the other hand, if you need complete control over the settings, you may want to bypass this abstraction and configure the proxy server manually.

Olası performans sorunu veya tek hata noktası bir ters proxy sunucusudur, böylece her zaman yüksek kullanılabilirlik için en az iki çoğaltma dağıtın.A reverse proxy server is a potential bottleneck or single point of failure, so always deploy at least two replicas for high availability.

Veri depolamaData storage

Bir mikro hizmetler mimarisinde hizmetler, veri depolama paylaşmamalıdır.In a microservices architecture, services should not share data storage. Her hizmet kendi özel veri hizmetleri arasında gizli bağımlılıklar önlemek için ayrı bir mantıksal depolama, kendi.Each service should own its own private data in a separate logical storage, to avoid hidden dependencies among services. Hizmetleri aynı temel alınan veri şemaları paylaşım kurduğunuzda gerçekleşebilir, hizmetler arasında yanlışlıkla eşleştirmeye neden kaçınmaktır.The reason is to avoid unintentional coupling between services, which can happen when services share the same underlying data schemas. Ayrıca, hizmetleri, kendi veri depoları yönetirken, bunlar belirli gereksinimleri için doğru veri deposunu kullanabilirsiniz.Also, when services manage their own data stores, they can use the right data store for their particular requirements. Daha fazla bilgi için mikro hizmetler tasarlama: Veri konuları.For more information, see Designing microservices: Data considerations.

Yerel küme depolamada kalıcı veriyi saklamak kaçının, çünkü, veri düğümü bağlar.Avoid storing persistent data in local cluster storage, because that ties the data to the node. Bunun yerine,Instead,

  • Azure SQL veritabanı veya Cosmos DB gibi bir dış hizmet kullanmak veyaUse an external service such as Azure SQL Database or Cosmos DB, or

  • Azure diskleri veya Azure dosyaları'nı kullanarak bir kalıcı hacim bağlayın.Mount a persistent volume using Azure Disks or Azure Files. Azure dosyaları, aynı birim tarafından birden çok podunuz paylaşılması gerekiyorsa kullanın.Use Azure Files if the same volume needs to be shared by multiple pods.

Ad AlanlarıNamespaces

Ad alanları, küme içindeki Hizmetleri düzenlemek için kullanın.Use namespaces to organize services within the cluster. Kubernetes kümesindeki her nesne bir ad alanına ait.Every object in a Kubernetes cluster belongs to a namespace. Yeni bir nesne oluşturduğunuzda varsayılan olarak, bunu girer default ad alanı.By default, when you create a new object, it goes into the default namespace. Ancak kümedeki kaynaklar düzenlenmesine yardımcı olmak için daha açıklayıcı bir ad alanları oluşturmak için iyi bir uygulamadır.But it's a good practice to create namespaces that are more descriptive to help organize the resources in the cluster.

İlk olarak, ad alanları önlemeye yardımcı adlandırma çakışması.First, namespaces help prevent naming collisions. Birden çok takımı, mikro hizmetler, büyük olasılıkla bir yüzlerce aynı kümede mikro hizmetler dağıttığınızda hepsi aynı ad alanına giderseniz yönetmek zor alır.When multiple teams deploy microservices into the same cluster, with possibly hundreds of microservices, it gets hard to manage if they all go into the same namespace. Ayrıca, ad alanları için izin ver:In addition, namespaces allow you to:

  • Böylece bu ad alanına atanmış pod'ların toplam kümesini ad alanının kaynak kotası aşamaz bir ad alanı kaynak kısıtlamalar uygulanır.Apply resource constraints to a namespace, so that the total set of pods assigned to that namespace cannot exceed the resource quota of the namespace.

  • RBAC ve güvenlik ilkeleriyle de dahil olmak üzere ad alanı düzeyinde ilkeler uygulayın.Apply policies at the namespace level, including RBAC and security policies.

Bir mikro hizmet mimarisi için mikro hizmetler sınırlanmış Bağlamlar düzenleme ve her biri için ad alanları oluşturma dikkate içerik sınırlanmış.For a microservices architecture, considering organizing the microservices into bounded contexts, and creating namespaces for each bounded context. Örneğin, "Siparişi tamamlama" sınırlanmış bağlam için ilgili tüm mikro hizmetler aynı ad alanına gidebilirsiniz.For example, all microservices related to the "Order Fulfillment" bounded context could go into the same namespace. Alternatif olarak, her bir geliştirme ekibi için bir ad alanı oluşturun.Alternatively, create a namespace for each development team.

Yardımcı programı Hizmetleri, kendi ayrı ad alanına yerleştirin.Place utility services into their own separate namespace. Örneğin, küme izleme veya Tiller Helm için Elasticsearch veya Prometheus dağıtabilirsiniz.For example, you might deploy Elasticsearch or Prometheus for cluster monitoring, or Tiller for Helm.

Ölçeklenebilirlik konusunda dikkat edilmesi gerekenlerScalability considerations

Kubernetes destekleyen iki düzeyde ölçeklendirme:Kubernetes supports scale-out at two levels:

  • Bir dağıtım için ayrılan pod'ların sayısını ölçeklendirebilirsiniz.Scale the number of pods allocated to a deployment.
  • Küme için kullanılabilir toplam işlem kaynaklarını artırmak için kümedeki düğümlerin ölçeklendirin.Scale the nodes in the cluster, to increase the total compute resources available to the cluster.

Pod'ların ölçeğini genişletebilir ve düğümleri el ile karşın, otomatik ölçeklendirme, yüksek yük altında starved kaynak Hizmetleri olacak olasılığını en aza indirmek için kullanmanızı öneririz.Although you can scale out pods and nodes manually, we recommend using autoscaling, to minimize the chance that services will become resource starved under high load. Otomatik ölçeklendirme stratejisi pod'ların hem düğümleri dikkate almanız gerekir.An autoscaling strategy must take both pods and nodes into account. Sonunda yalnızca pod'ların ölçeklendirirseniz düğümlerinin kaynak sınırları ulaşacak.If you just scale out the pods, eventually you will reach the resource limits of the nodes.

Otomatik pod ölçeklendirmeyiPod autoscaling

Yatay Pod otomatik Ölçeklendiricinin (HPA) pod'ların gözlemlenen CPU, bellek veya özel ölçümler göre ölçeklendirir.The Horizontal Pod Autoscaler (HPA) scales pods based on observed CPU, memory, or custom metrics. Yatay pod ölçeklendirmeyi yapılandırma için bir hedef ölçü (örneğin, % 70 CPU) ve çoğaltmaları minimum ve maksimum sayısını belirtin.To configure horizontal pod scaling, you specify a target metric (for example, 70% of CPU), and the minimum and maximum number of replicas. Yük bu numaraları türetmek için hizmetlerinizi test edin.You should load test your services to derive these numbers.

Ölçek genişletme ve ölçek, olay oluştuğunda bir yan etkisi otomatik ölçeklendirme, pod'ların oluşturulan veya daha sık çıkarılacak aynıdır.A side-effect of autoscaling is that pods may be created or evicted more frequently, as scale-out and scale-in events happen. Bu etkilerini azaltmak için:To mitigate the effects of this:

  • Yeni bir pod trafiği kabul etmeye hazır olduğunda bilmeniz Kubernetes izin vermek için hazır olma durumu araştırmaları kullanın.Use readiness probes to let Kubernetes know when a new pod is ready to accept traffic.
  • Pod kesintisi bütçelerini kaç pod'ların bir kerede bir hizmetten çıkartılabilir sınırlamak için kullanın.Use pod disruption budgets to limit how many pods can be evicted from a service at a time.

Küme ölçeklendirmeCluster autoscaling

Küme otomatik ölçeklendiricinin düğüm sayısını ölçeklendirir.The cluster autoscaler scales the number of nodes. Küme ölçeklendirici, pod'ları kaynak kısıtlamaları nedeniyle zamanlanamaz, daha fazla düğüm sağlanır.If pods can't be scheduled because of resource constraints, the cluster autoscaler will provision more nodes. (Not: AKS kümesi ölçeklendiriciyi arasındaki tümleştirme şu anda önizlemededir.)(Note: Integration between AKS and the cluster autoscaler is currently in preview.)

Pod'ların çalışmasını HPA tüketilen gerçek kaynaklarının veya diğer ölçümleri görünüyor ancak henüz zamanlanmaz pod'ları için düğüm Küme ölçeklendiriciyi sağlanıyor.Whereas HPA looks at actual resources consumed or other metrics from running pods, the cluster autoscaler is provisioning nodes for pods that aren't scheduled yet. Bu nedenle, bir dağıtım için Kubernetes pod spec belirtildiği gibi istenen kaynaklara bakar.Therefore, it looks at the requested resources, as specified in the Kubernetes pod spec for a deployment. Bu değerleri ince ayar yapmak için yük testi kullanın.Use load testing to fine-tune these values.

Kümeyi oluşturduğunuzda aracı düğümleri için uygun bir VM boyutu seçin amacıyla bazı ilk kapasite planlaması yapmanız gerekenler bu nedenle küme oluşturduktan sonra VM boyutunu değiştiremezsiniz.You can't change the VM size after you create the cluster, so you should do some initial capacity planning to choose an appropriate VM size for the agent nodes when you create the cluster.

Kullanılabilirlik konusunda dikkat edilmesi gerekenlerAvailability considerations

Sistem durumu araştırmalarıHealth probes

Kubernetes, bir pod getirebilir durum araştırması iki tür tanımlar:Kubernetes defines two types of health probe that a pod can expose:

  • Hazır olma durumu araştırması: Kubernetes pod istekleri kabul etmeye hazır olup olmadığını söyler.Readiness probe: Tells Kubernetes whether the pod is ready to accept requests.

  • Canlılık araştırması: Kubernetes, bir pod kaldırıldı ve yeni bir örneğini başlatan söyler.Liveness probe: Tells Kubernetes whether a pod should be removed and a new instance started.

Araştırmalar hakkında düşünürken, bir hizmet Kubernetes'te nasıl çalıştığını geri çekmek kullanışlıdır.When thinking about probes, it's useful to recall how a service works in Kubernetes. Bir hizmeti (sıfır veya daha fazla) pod'ları kümesi ile eşleşen bir etiket seçici içerir.A service has a label selector that matches a set of (zero or more) pods. Kubernetes yük Seçici eşleşen pod'ların trafiği dengeler.Kubernetes load balances traffic to the pods that match the selector. Başarıyla başlatıldı ve iyi durumda olmayan pod trafiği alır.Only pods that started successfully and are healthy receive traffic. Bir kapsayıcı çökerse, Kubernetes pod'u sonlandırır ve yenisini zamanlar.If a container crashes, Kubernetes kills the pod and schedules a replacement.

Bazı durumlarda, pod başarıyla başlatıldı olsa bile bir pod trafiği almak hazır olmayabilir.Sometimes, a pod may not be ready to receive traffic, even though the pod started successfully. Örneğin, burada kapsayıcıda çalışan uygulama şeyler belleğe veya yapılandırma verilerini okuyan başlatma görevleri olabilir.For example, there may be initialization tasks, where the application running in the container loads things into memory or reads configuration data. Bir pod sağlıklı ancak trafiği almaya hazır olduğunu göstermek için hazır olma durumu araştırması tanımlayın.To indicate that a pod is healthy but not ready to receive traffic, define a readiness probe.

Burada bir pod hala çalışıyor, ancak kötü durumda, geri dönüştürülmesi gerekir durum canlılık araştırmaları işleyin.Liveness probes handle the case where a pod is still running, but is unhealthy and should be recycled. Örneğin, bir kapsayıcı HTTP isteklerini askıda kalır ancak bazı nedenlerden dolayı ettiğini düşünün.For example, suppose that a container is serving HTTP requests but hangs for some reason. Kapsayıcı kilitlenme değil, ancak tüm isteklere hizmet durduruldu.The container doesn't crash, but it has stopped serving any requests. Bir HTTP canlılık araştırması tanımlarsanız, araştırma yanıt vermeyi durdurur ve, Kubernetes pod'u yeniden başlatmak için size bildirir.If you define an HTTP liveness probe, the probe will stop responding and that informs Kubernetes to restart the pod.

Araştırmalar tasarlarken bazı noktalar şunlardır:Here are some considerations when designing probes:

  • Kodunuzu uzun başlangıç zamanını varsa, başlatma tamamlanmadan önce canlılık araştırması hata bildirir bir tehlikesi yoktur.If your code has a long startup time, there is a danger that a liveness probe will report failure before the startup completes. Bunu önlemek için başlangıç tarihinden araştırma geciktirir initialDelaySeconds ayarı kullanın.To prevent this, use the initialDelaySeconds setting, which delays the probe from starting.

  • Pod yeniden başlatma sağlıklı bir duruma geri yüklemek büyük olasılıkla olmadığı sürece kapsayıcısında eşdeğerlik araştırması için yardımcı olmaz.A liveness probe doesn't help unless restarting the pod is likely to restore it to a healthy state. Canlılık araştırması, bellek sızıntıları veya beklenmeyen kilitlenmeleri karşı azaltmak için kullanabilirsiniz, ancak yeniden başlatmadan hemen yeniden başarısız olacağı bir pod içinde noktası yok.You can use a liveness probe to mitigate against memory leaks or unexpected deadlocks, but there's no point in restarting a pod that's going to immediately fail again.

  • Bazen hazır olma durumu araştırmaları, bağımlı hizmetleri kontrol etmek için kullanılır.Sometimes readiness probes are used to check dependent services. Örneğin, bir pod bir veritabanı üzerinde bir bağımlılık varsa, veritabanı bağlantısını canlılık araştırması denetleyebilir.For example, if a pod has a dependency on a database, the liveness probe might check the database connection. Ancak, bu yaklaşım, beklenmeyen bir sorun oluşturabilirsiniz.However, this approach can create unexpected problems. Bir dış hizmet çeşitli nedenlerle geçici olarak kullanılamayabilir.An external service might be temporarily unavailable for some reason. Hazır olma durumu araştırması için tüm pod'larını hizmetinizdeki tümünün Yük Dengeleme ve bu nedenle zincirleme hatalara Yukarı Akış oluşturma kaldırılması neden başarısız olmasına neden.That will cause the readiness probe to fail for all the pods in your service, causing all of them to be removed from load balancing, and thus creating cascading failures upstream. Yeniden deneme hizmetinizin içinde işleme hizmetinizin doğru geçici hatalarından kurtarabilmeniz uygulamak daha iyi bir yaklaşımdır.A better approach is to implement retry handling within your service, so that your service can recover correctly from transient failures.

Kaynak sınırlamalarıResource constraints

Kaynak çakışması bir hizmetin kullanılabilirliğini etkileyebilir.Resource contention can affect the availability of a service. Tek bir kapsayıcıya küme kaynakları (bellek ve CPU) doldurmaya olamaz, kapsayıcılar için kaynak kısıtlamaları tanımlayın.Define resource constraints for containers, so that a single container cannot overwhelm the cluster resources (memory and CPU). İş parçacıkları veya ağ bağlantıları gibi kapsayıcı olmayan kaynaklar için düşünün kullanarak bölme perdesi düzeni kaynakları ayırmak için.For non-container resources, such as threads or network connections, consider using the Bulkhead Pattern to isolate resources.

Kullanım kaynak kotaları toplam kaynakları sınırlandırmak için bir ad alanı için izin.Use resource quotas to limit the total resources allowed for a namespace. Bu şekilde, ön uç arka uç Hizmetleri kaynaklar veya pasiften etkine geçirmek için yeterli kaynak kalmamasına neden olamaz.That way, the front end can't starve the backend services for resources or vice-versa.

Güvenlikle ilgili dikkat edilmesi gerekenlerSecurity considerations

Rol tabanlı erişim denetimi (RBAC)Role based access control (RBAC)

Kubernetes ve Azure rol tabanlı erişim denetimi (RBAC) mekanizmalar vardır:Kubernetes and Azure both have mechanisms for role-based access control (RBAC):

  • Azure RBAC, yeni Azure kaynaklarını oluşturma olanağı dahil olmak üzere azure'daki kaynaklara erişimi denetler.Azure RBAC controls access to resources in Azure, including the ability to create new Azure resources. İzinler, kullanıcıları, grupları veya hizmet sorumlularına atanabilir.Permissions can be assigned to users, groups, or service principals. (Hizmet sorumlusu uygulamaları tarafından kullanılan bir güvenlik kimliğidir.)(A service principal is a security identity used by applications.)

  • Kubernetes RBAC Kubernetes API için izinler denetler.Kubernetes RBAC controls permissions to the Kubernetes API. Örneğin, pod'ları oluşturma ve pod'ların listesi yetkili (engellendi veya) bir kullanıcının RBAC üzerinden eylemlerdir.For example, creating pods and listing pods are actions that can be authorized (or denied) to a user through RBAC. Kubernetes izinler kullanıcılara atamak için oluşturduğunuz rolleri ve rol bağlamaları:To assign Kubernetes permissions to users, you create roles and role bindings:

    • Bir ad alanı içinde geçerli bir izin kümesi rolüdür.A Role is a set of permissions that apply within a namespace. İzinleri fiilleri olarak tanımlanır (alma, güncelleştirme, oluşturma ve silme) kaynaklar (pod'ları, dağıtımlar, vb.).Permissions are defined as verbs (get, update, create, delete) on resources (pods, deployments, etc.).

    • Bir RoleBinding kullanıcıları veya grupları Role atar.A RoleBinding assigns users or groups to a Role.

    • Bir rolü gibi ancak tüm küme için tüm ad alanları geneline geçerlidir ClusterRole nesne yok.There is also a ClusterRole object, which is like a Role but applies to the entire cluster, across all namespaces. Kullanıcılar veya gruplar için bir ClusterRole atamak için bir ClusterRoleBinding oluşturun.To assign users or groups to a ClusterRole, create a ClusterRoleBinding.

AKS, bu iki RBAC mekanizmalar tümleştirir.AKS integrates these two RBAC mechanisms. Bir AKS kümesi oluşturduğunuzda, Azure AD kullanıcı kimlik doğrulaması kullanacak şekilde yapılandırabilirsiniz.When you create an AKS cluster, you can configure it to use Azure AD for user authentication. Bu nasıl oluşturulacağı hakkında daha fazla bilgi için bkz: Azure Active Directory Tümleştirme ile Azure Kubernetes hizmeti.For details on how to set this up, see Integrate Azure Active Directory with Azure Kubernetes Service.

Bu yapılandırıldıktan sonra Kubernetes API (örneğin, aracılığıyla kubectl) erişmek isteyen bir kullanıcı kendi Azure AD kimlik bilgilerinizi kullanarak oturum açmanız gerekir.Once this is configured, a user who wants to access the Kubernetes API (for example, through kubectl) must sign in using their Azure AD credentials.

Varsayılan olarak, bir Azure AD kullanıcısı kümeye hiçbir erişebilir.By default, an Azure AD user has no access to the cluster. Erişim vermek için Küme Yöneticisi, Azure AD kullanıcı veya gruplara başvuran RoleBindings oluşturur.To grant access, the cluster administrator creates RoleBindings that refer to Azure AD users or groups. Bir kullanıcı belirli bir işlem için izinlere sahip değilse başarısız olur.If a user doesn't have permissions for a particular operation, it will fail.

Nasıl kullanıcılar varsayılan olarak erişimi varsa, küme yönetim ilk yerinde rol bağlamalar oluşturma izni var?If users have no access by default, how does the cluster admin have permission to create the role bindings in the first place? Bir AKS kümesi aslında Kubernetes API sunucusu çağırmak için kimlik bilgilerini iki tür vardır: küme kullanıcı ile Küme Yöneticisi Küme Yöneticisi kimlik bilgileri, küme için tam erişim verin.An AKS cluster actually has two types of credentials for calling the Kubernetes API server: cluster user and cluster admin. The cluster admin credentials grant full access to the cluster. Azure CLI komutunu az aks get-credentials --admin Küme Yöneticisi kimlik bilgilerini indirir ve bunları kubeconfig'i denetleyin dosyanıza kaydeder.The Azure CLI command az aks get-credentials --admin downloads the cluster admin credentials and saves them into your kubeconfig file. Küme Yöneticisi, bu kubeconfig'i denetleyin, rolleri ve rol bağlamaları oluşturmak için kullanabilirsiniz.The cluster administrator can use this kubeconfig to create roles and role bindings.

Küme Yöneticisi kimlik bilgilerini güçlü olduğundan, Azure RBAC için erişimi kısıtlamak için kullanın:Because the cluster admin credentials are so powerful, use Azure RBAC to restrict access to them:

  • "Azure Kubernetes hizmeti Küme Yöneticisi rolünü" Küme Yöneticisi kimlik bilgilerini indirme izni vardır.The "Azure Kubernetes Service Cluster Admin Role" has permission to download the cluster admin credentials. Yalnızca küme yöneticileri için bu rol atanması gerekir.Only cluster administrators should be assigned to this role.

  • Azure Kubernetes hizmeti küme "kullanıcı rolüne" Küme kullanıcı kimlik bilgilerini indirme izni vardır.The "Azure Kubernetes Service Cluster User Role" has permission to download the cluster user credentials. Yönetici olmayan kullanıcılar için bu rol atanabilir.Non-admin users can be assigned to this role. Bu rol, Kubernetes kaynaklar kümesi içinde herhangi bir izin vermez — yalnızca API sunucusuna açmasına olanak sağlar.This role does not give any particular permissions on Kubernetes resources inside the cluster — it just allows a user to connect to the API server.

RBAC ilkelerini (hem Kubernetes hem de Azure) tanımladığınızda, kuruluşunuzdaki rolleri hakkında dikkate alın:When you define your RBAC policies (both Kubernetes and Azure), think about the roles in your organization:

  • Kimin oluşturabilir veya AKS kümesini silme ve yönetici kimlik bilgilerini indirme?Who can create or delete an AKS cluster and download the admin credentials?
  • Bir küme yönetebilecek?Who can administer a cluster?
  • Kimin oluşturabilir veya bir ad alanındaki kaynakları güncelleştirme?Who can create or update resources within a namespace?

Kapsam Kubernetes RBAC için iyi bir yöntemdir ad alanı, roller ve RoleBindings, yerine ClusterRoles ve ClusterRoleBindings kullanarak izinleri.It's a good practice to scope Kubernetes RBAC permissions by namespace, using Roles and RoleBindings, rather than ClusterRoles and ClusterRoleBindings.

Son olarak, AKS kümesi oluşturma ve yük Dengeleyiciler, ağ veya depolama gibi Azure kaynaklarını yönetmek için hangi izinlerini soru yok.Finally, there is the question of what permissions the AKS cluster has to create and manage Azure resources, such as load balancers, networking, or storage. Azure API'leri ile kendi kimliğini doğrulamak için bir Azure AD hizmet sorumlusu kümesi kullanır.To authenticate itself with Azure APIs, the cluster uses an Azure AD service principal. Kümeyi oluştururken hizmet sorumlusu belirtmezseniz, bir otomatik olarak oluşturulur.If you don't specify a service principal when you create the cluster, one is created automatically. Ancak, ilk hizmet sorumlusu oluşturun ve kendisine en az RBAC izinlerinin atamak için bir güvenlik açısından iyi yöntemdir.However, it's a good security practice to create the service principal first and assign the minimal RBAC permissions to it. Daha fazla bilgi için hizmet sorumluları Azure Kubernetes hizmeti ile.For more information, see Service principals with Azure Kubernetes Service.

Gizli dizileri yönetim ve uygulama kimlik bilgileriSecrets management and application credentials

Uygulamalar ve Hizmetler genellikle Azure depolama veya SQL veritabanı gibi dış hizmetlere bağlanmasına izin vermek kimlik bilgileri gerekir.Applications and services often need credentials that allow them to connect to external services such as Azure Storage or SQL Database. Bu kimlik bilgileri güvende tutun ve bunları sızıntı değil zorluktur.The challenge is to keep these credentials safe and not leak them.

Azure kaynakları için bir seçenek yönetilen kimlikleri kullanmaktır.For Azure resources, one option is to use managed identities. Yönetilen bir kimlik, bir uygulama veya hizmeti Azure AD'de depolanan bir kimliğe sahiptir ve bir Azure hizmeti ile kimlik doğrulaması için bu kimliği kullanır olur.The idea of a managed identity is that an application or service has an identity stored in Azure AD, and uses this identity to authenticate with an Azure service. Uygulama veya hizmet için Azure AD'de oluşturulan hizmet sorumlusuna sahip ve OAuth 2.0 belirteçlerini kullanarak kimliğini doğrular.The application or service has a Service Principal created for it in Azure AD, and authenticates using OAuth 2.0 tokens. Yürütülen işlem belirteci almak için localhost adresi çağırır.The executing process calls a localhost address to get the token. Böylece, herhangi bir parola veya bağlantı dizeleri depolamak gerekmez.That way, you don't need to store any passwords or connection strings. Yönetilen kimlik AKS içinde tek tek pod'ları için kimlikleri atayarak kullanarak kullanabileceğiniz aad pod kimlik proje.You can use managed identities in AKS by assigning identities to individual pods, using the aad-pod-identity project.

Şu anda yönetilen kimlikleri kullanılarak kimlik doğrulaması tüm Azure Hizmetleri destekler.Currently, not all Azure services support authentication using managed identities. Bir liste için bkz. Azure Hizmetleri söz konusu destek Azure AD kimlik doğrulamasını.For a list, see Azure services that support Azure AD authentication.

Yönetilen kimliklerle bile büyük olasılıkla olmadığını yönetilen kimlikleri desteklemeyen Azure Hizmetleri, üçüncü taraf hizmetleri, API anahtarları ve benzeri için bazı kimlik bilgileri veya diğer uygulama parolalarını depolamak gerekir.Even with managed identities, you'll probably need to store some credentials or other application secrets, whether for Azure services that don't support managed identities, third-party services, API keys, and so on. Gizli dizileri güvenli bir şekilde depolamak için bazı seçenekler şunlardır:Here are some options for storing secrets securely:

  • Azure Key Vault.Azure Key Vault. AKS içinde bir veya daha fazla gizli anahtarları Key Vault'tan bir birim olarak bağlayabilir.In AKS, you can mount one or more secrets from Key Vault as a volume. Birim Key Vault'tan gizli dizileri okur.The volume reads the secrets from Key Vault. Pod ardından normal bir birimi olduğu gibi gizli dizileri okuyabilirsiniz.The pod can then read the secrets just like a regular volume. Daha fazla bilgi için Kubernetes KeyVault FlexVolume github'daki proje.For more information, see the Kubernetes-KeyVault-FlexVolume project on GitHub.

    Pod kendisi (yukarıda açıklanmıştır) ya da bir pod kimlik kullanarak veya bir Azure AD hizmet sorumlusu istemci gizli anahtarı ile birlikte kullanarak kimliğini doğrular.The pod authenticates itself by using either a pod identity (described above) or by using an Azure AD Service Principal along with a client secret. Bu durumda istemci gizli anahtarı gerek yoktur çünkü pod kimliklerle önerilir.Using pod identities is recommended because the client secret isn't needed in that case.

  • HashiCorp Vault.HashiCorp Vault. Kubernetes uygulamaları HashiCorp yönetilen Azure AD kimlikleri kullanarak kasa ile kimlik doğrulaması yapabilir.Kubernetes applications can authenticate with HashiCorp Vault using Azure AD managed identities. Bkz: HashiCorp kasası, Azure Active Directory konuşur.See HashiCorp Vault speaks Azure Active Directory. Kubernetes için kasasını dağıtabilirsiniz, ancak sahip öneririz ayrı bir adanmış kümede, uygulama kümenizden çalıştırılacak.You can deploy Vault itself to Kubernetes, but it's recommend to run it in a separate dedicated cluster from your application cluster.

  • Kubernetes gizli dizileri.Kubernetes secrets. Yalnızca başka bir seçenek Kubernetes gizli dizileri kullanmaktır.Another option is simply to use Kubernetes secrets. Bu seçeneği yapılandırmak en kolay yolu, ancak bazı zorluklar vardır.This option is the easiest to configure but has some challenges. Gizli dizileri, dağıtılmış bir anahtar-değer deposudur etcd içinde depolanır.Secrets are stored in etcd, which is a distributed key-value store. AKS bekleyen etcd şifreler.AKS encrypts etcd at rest. Microsoft, şifreleme anahtarları yönetir.Microsoft manages the encryption keys.

HashiCorp kasası veya Azure anahtar kasası gibi bir sistem kullanılması gibi bazı avantajlar sağlar:Using a system like HashiCorp Vault or Azure Key Vault provides several advantages, such as:

  • Gizli dizileri Merkezi Denetim.Centralized control of secrets.
  • Tüm gizli dizilerin bekleme durumundayken şifrelenir sağlama.Ensuring that all secrets are encrypted at rest.
  • Anahtar Yönetim Merkezi.Centralized key management.
  • Gizli dizilerinin erişim denetimi.Access control of secrets.
  • DenetimAuditing

Pod ve kapsayıcı güvenliğiPod and container security

Bu liste tam kapsamlı değildir, ancak pod'ların ve kapsayıcıları güvenli hale getirmek için bazı önerilen yöntemler şunlardır:This list is certainly not exhaustive, but here are some recommended practices for securing your pods and containers:

Kapsayıcılar ayrıcalıklı modda çalışmaz.Don't run containers in privileged mode. Ayrıcalıklı modda bir kapsayıcı konak üzerindeki tüm cihazlara erişmenizi sağlar.Privileged mode gives a container access to all devices on the host. Kapsayıcılar ayrıcalıklı modda çalışmasını engellemek için Pod güvenlik ilkesini ayarlayabilirsiniz.You can set Pod Security Policy to disallow containers from running in privileged mode.

Mümkün olduğunda, kapsayıcıların içinde kök olarak çalışan işlemlerin kaçının.When possible, avoid running processes as root inside containers. Kapsayıcı işlemi bir ayrıcalıklı olmayan kullanıcı olarak çalışacak şekilde daha iyi, bu nedenle güvenlik açısından, tam yalıtım kapsayıcıları sağlamaz.Containers do not provide complete isolation from a security standpoint, so it's better to run a container process as a non-privileged user.

Azure Container Registry veya Docker güvenilen kayıt defteri gibi güvenilir bir özel kayıt defterindeki görüntüleri Store.Store images in a trusted private registry, such as Azure Container Registry or Docker Trusted Registry. Doğrulama giriş Web kancası Kubernetes pod'ların yalnızca güvenilen kayıt defterinden görüntüleri çekmek emin olmak için kullanın.Use a validating admission webhook in Kubernetes to ensure that pods can only pull images from the trusted registry.

Tarama görüntüleri ve kapsayıcılar için Azure Marketi aracılığıyla Twistlock ve Açık Deniz Mavisi, gibi tarama bir çözümü kullanarak bilinen güvenlik açıklarının çalışıyor.Scan images and running containers for known vulnerabilities, using a scanning solution such as Twistlock and Aqua, which are available through the Azure Marketplace.

Görüntüyü ACR görevleri, Azure Container Registry özelliği'ni kullanarak düzeltme eki uygulama otomatikleştirin.Automate image patching using ACR Tasks, a feature of Azure Container Registry. Bir kapsayıcı görüntüsü katmanlardan oluşturulmuştur.A container image is built up from layers. Temel katman işletim sistemi görüntüsü ve ASP.NET Core veya Node.js gibi uygulama çerçevesi görüntüleri içerir.The base layers include the OS image and application framework images, such as ASP.NET Core or Node.js. Temel görüntüler, genellikle uygulama geliştiricilerden Yukarı Akış oluşturulur ve diğer proje maintainers tarafından korunur.The base images are typically created upstream from the application developers, and are maintained by other project maintainers. Bu görüntüleri Yukarı Akış yama, böylece bilinen güvenlik açıkları bırakmayın güncelleştirme, test edin ve kendi görüntülerinizi yeniden önemlidir.When these images are patched upstream, it's important to update, test, and redeploy your own images, so that you don't leave any known security vulnerabilities. ACR görevler, bu işlemi otomatikleştirmek için yardımcı olabilir.ACR Tasks can help to automate this process.

Dağıtım (CI/CD) konularıDeployment (CI/CD) considerations

Bir mikro hizmet mimarisi için sağlam bir CI/CD işlem bazı amaçları şunlardır:Here are some goals of a robust CI/CD process for a microservices architecture:

  • Her takım oluşturabilir ve etkileyen veya diğer ekipler kesintiye bağımsız olarak, sahip olan hizmetleri dağıtın.Each team can build and deploy the services that it owns independently, without affecting or disrupting other teams.
  • Bir hizmetin yeni bir sürümü üretim ortamına dağıtılmadan önce doğrulama için geliştirme/test/QA ortamlara dağıtılır.Before a new version of a service is deployed to production, it gets deployed to dev/test/QA environments for validation. Kalite kapıları her aşamada yerine getirilir.Quality gates are enforced at each stage.
  • Bir hizmetin yeni bir sürümü önceki sürümü yan yana dağıtılabilir.A new version of a service can be deployed side by side with the previous version.
  • Yeterli erişim denetimi ilkeleri gerçekleşmiştir.Sufficient access control policies are in place.
  • Kapsayıcılı iş yükleri için üretime dağıtılmadan kapsayıcı görüntülerini güvenebilir.For containerized workloads, you can trust the container images that are deployed to production.

Sorunları hakkında daha fazla bilgi için bkz: mikro hizmet mimarileri için CI/CD.To learn more about the challenges, see CI/CD for microservices architectures.

Öneriler ve en iyi yöntemler için bkz: Kubernetes üzerinde mikro hizmetler için CI/CD.For specific recommendations and best practices, see CI/CD for microservices on Kubernetes.

Çözümü dağıtmaDeploy the solution

Bu mimari için başvuru uygulaması dağıtmak için adımları izleyin. GitHub deposunu.To deploy the reference implementation for this architecture, follow the steps in the GitHub repo.