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

Bu başvuru mimarileri, Azure Kubernetes Service (AKS) için Dağıtılmış bir mikro Hizmetler uygulaması gösterir.This reference architectures 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 gösterir.It shows a basic AKS configuration that can be the starting point for most deployments. Gelişmiş ağ seçenekleri dahil olmak üzere daha gelişmiş seçenekler ayrı başvuru mimarisinde ele alınmaktadır.More advanced options, including advanced networking options, will be covered in a separate reference architecture.

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. Etki alanı Odaklı Tasarım (DDD) açısından mikro hizmetler tasarlama konusunda rehberlik için bkz tasarlama, oluşturma ve azure'da mikro hizmetler çalıştırma.For guidance on how to design microservices from a Domain Driven Design (DDD) perspective, see Designing, building, and operating microservices on Azure.

Not

İçinde erken 2019 yayımlamak için bekliyoruz bir başvuru uygulaması bu makalede, eşlik edecek (RI) üzerinde çalışıyoruz.We are working on a reference implementation (RI) to accompany this article, which we expect to publish in early 2019. Bu makalede, en iyi yöntemleri, RI ek birleştirmek için güncelleştirilir.This article will be updated to incorporate additional best practices from that RI.

AKS başvuru mimarisi

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.

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 kasası.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.

Görüntüleri Azure Marketi'nde bulunan Twistlock ve Açık Deniz Mavisi, gibi tarama bir çözümü kullanarak bilinen güvenlik açıkları için tarayın.Scan images 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 dağıtılan yan yana önceki sürümüne sahip olabilir.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.

  • Üretime dağıtılmadan kapsayıcı görüntülerini güvenebilir.You can trust the container images that are deployed to production.

Ortamların yalıtımIsolation of environments

Hizmetleri, geliştirme, duman testi, tümleştirme testi, yük testi ve son olarak üretim ortamları dahil olmak üzere burada dağıttığınız birden çok ortama sahip olur.You will have multiple environments where you deploy services, including environments for development, smoke testing, integration testing, load testing, and finally production. Bu ortamların yalıtım belirli bir düzeyde gerekir.These environments need some level of isolation. Kubernetes'te, fiziksel yalıtım ve mantıksal yalıtımı arasında vardır.In Kubernetes, you have a choice between physical isolation and logical isolation. Fiziksel yalıtım, ayrı kümeler dağıtmak anlamına gelir.Physical isolation means deploying to separate clusters. Mantıksal yalıtım sağlar, ad alanları ve ilkeleri daha önce açıklanan şekilde kullanın.Logical isolation makes use of namespaces and policies, as described earlier.

Bizim önerimiz, geliştirme ve test ortamları için ayrı bir küme ile birlikte bir adanmış bir üretim kümesi oluşturmaktır.Our recommendation is to create a dedicated production cluster along with a separate cluster for your dev/test environments. Geliştirme ve test kümesi içinde ortamlarınızı ayırmak için mantıksal yalıtım kullanın.Use logical isolation to separate environments within the dev/test cluster. Geliştirme ve test kümeye dağıtılmış hizmetlerin hiçbir zaman iş verilerini kapsayan veri depolarına erişimine sahip olmalıdır.Services deployed to the dev/test cluster should never have access to data stores that hold business data.

HelmHelm

Helm hizmetlerini derleyip dağıtmayı yönetmek için kullanmayı düşünün.Consider using Helm to manage building and deploying services. CI/CD ile yardımcı Helm özelliklerinin bazıları şunlardır:Some of the features of Helm that help with CI/CD include:

  • Tüm Kubernetes nesneleri belirli bir mikro hizmet için tek bir Helm grafiği düzenleme.Organizing all of the Kubernetes objects for a particular microservice into a single Helm chart.
  • Grafik kubectl komutlarını bir dizi yerine bir tek helm komutu olarak dağıtılıyor.Deploying the chart as a single helm command, rather than a series of kubectl commands.
  • İzleme güncelleştirmeleri ve düzeltmeleri, semantik sürüm oluşturma, bir önceki sürüme geri alma olanağı ile birlikte kullanarak.Tracking updates and revisions, using semantic versioning, along with the ability to roll back to a previous version.
  • Etiketleri ve Seçici gibi bilgileri arasında çok sayıda dosya çoğaltılmasını önlemek için şablonlar kullanın.The use of templates to avoid duplicating information, such as labels and selectors, across many files.
  • Grafikler arasındaki bağımlılıkları yönetme.Managing dependencies between charts.
  • Azure Container Registry gibi bir Helm deposu için grafikler yayımlama ve bunları derleme işlem hattı ile tümleştirme.Publishing charts to a Helm repository, such as Azure Container Registry, and integrating them with the build pipeline.

Kapsayıcı kayıt defteri bir Helm deposu olarak kullanma hakkında daha fazla bilgi için bkz. kullanımı Azure Container Registry, uygulama grafikleri için bir Helm deposu olarak.For more information about using Container Registry as a Helm repository, see Use Azure Container Registry as a Helm repository for your application charts.

CI/CD iş akışıCI/CD workflow

Bir CI/CD iş akışı oluşturmadan önce kod tabanının nasıl yapılandırılmış ve yönetilen bilmeniz gerekir.Before creating a CI/CD workflow, you must know how the code base will be structured and managed.

  • Takımlar, ayrı depoları veya bir monorepo (tek depo) çalışıyor mu?Do teams work in separate respositories or in a monorepo (single respository)?
  • Dallanma stratejisi nedir?What is your branching strategy?
  • Üretim için kimlerin kod gönderebilir?Who can push code to production? Yayın Yöneticisi rolü var mı?Is there a release manager role?

Monorepo yaklaşım ayrıcalık elde etme ancak avantajlar ve dezavantajlar her ikisine de vardır.The monorepo approach has been gaining favor but there are advantages and disadvantages to both.

  MonorepoMonorepo Birden çok depoMultiple repos
AvantajlarıAdvantages Kod paylaşmaCode sharing
Kod ve araçları kullanarak daha kolayEasier to standardize code and tooling
Yeniden düzenleme kod daha kolayEasier to refactor code
Bulunabilirlik - kodun tek bir görünümDiscoverability - single view of the code
Takım başına net sahipliğiClear ownership per team
Potansiyel olarak daha az çakışmaları BirleştirPotentially fewer merge conflicts
Mikro ayırma uygulanmasına yardımcı olurHelps to enforce decoupling of microservices
ZorluklarChallenges Paylaşılan kod değişiklikleri birden çok mikro hizmetleri etkileyebilirChanges to shared code can affect multiple microservices
Büyük potansiyeli birleştirme çakışmalarıGreater potential for merge conflicts
Araç, büyük kod tabanına Ölçeklendirmesi gerekirTooling must scale to a large code base
Erişim denetimiAccess control
Daha karmaşık dağıtım işlemiMore complex deployment process
Kod paylaşmak zorHarder to share code
Kodlama standartları zorlamak zorHarder to enforce coding standards
Bağımlılık yönetimiDependency management
Kod temel, zayıf bulunabilirliği yayınıkDiffuse code base, poor discoverability
Paylaşılan altyapı eksikliğiLack of shared infrastructure

Bu bölümde, biz aşağıdaki varsayımları temel alarak bir olası CI/CD iş akışı sunar:In this section, we present a possible CI/CD workflow, based on the following assumptions:

  • Kod, mikro hizmet tarafından düzenlenmiş klasörleri monorepo depodur.The code repository is monorepo, with folders organized by microservice.
  • Takımın dallanma stratejisi dayanır santral tabanlı geliştirme.The team's branching strategy is based on trunk-based development.
  • Takımınızın kullandığı Azure işlem hatları CI/CD işlem çalıştırılacak.The team uses Azure Pipelines to run the CI/CD process.
  • Takımınızın kullandığı ad alanları hala test edilen görüntülerden üretim için onaylanmaktadır görüntüleri yalıtmak için Azure Container Registry'de.The team uses namespaces in Azure Container Registry to isolate images that are approved for production from images that are still being tested.

Bu örnekte, bir geliştirici teslim hizmeti adlı bir mikro hizmet üzerinde çalışmaktadır.In this example, a developer is working on a microservice called Delivery Service. (Adın açıklanan başvuru uygulamadan gelen burada.) Yeni bir özellik geliştirme sırasında Geliştirici kod bir özellik dalı denetler.(The name comes from the reference implementation described here.) While developing a new feature, the developer checks code into a feature branch.

CI/CD iş akışı

Bu dal tiggers mikro hizmet için bir CI derlemesi için işlemeler İletiliyor.Pushing commits to this branch tiggers a CI build for the microservice. Kural gereği, özellik dalları adlandırılır feature/*.By convention, feature branches are named feature/*. Derleme tanım dosyası dal adı ve kaynak yoluna göre filtreleyen bir tetikleyici içerir.The build definition file includes a trigger that filters by the branch name and the source path. Bu yaklaşımı kullanarak, her takımın kendi derleme işlem hattı olabilir.Using this approach, each team can have its own build pipeline.

trigger:
  batch: true
  branches:
    include:
    - master
    - feature/*

    exclude:
    - feature/experimental/*

  paths:
     include:
     - /src/shipping/delivery/

Bu noktada iş akışı içinde CI derleme bazı çok az kod doğrulama çalıştırır:At this point in the workflow, the CI build runs some minimal code verification:

  1. Kod derlemeBuild code
  2. Birim testleri çalıştırmaRun unit tests

Buradaki Geliştirici Hızlı geri bildirim alabilmeniz kısa derleme zamanlarını tutmaktır.The idea here is to keep the build times short so the developer can get quick feedback. Özellik ana dalla birleştirmek hazır olduğunda, geliştirici bir PR açılır.When the feature is ready to merge into master, the developer opens a PR. Bu, bazı ek denetimler gerçekleştiren başka bir CI yapısı tetikleyen:This triggers another CI build that performs some additional checks:

  1. Kod derlemeBuild code
  2. Birim testleri çalıştırmaRun unit tests
  3. Çalışma zamanı kapsayıcı görüntüsünü oluşturmaBuild the runtime container image
  4. Görüntüde güvenlik açığı taramaları çalıştırmaRun vulnerability scans on the image

CI/CD iş akışı

Not

Azure depolarda tanımladığınız ilkeleri dallarını korumak için.In Azure Repos, you can define policies to protect branches. Örneğin, ilke ana dalla birleştirmek için başarılı bir CI derleme artı bir onaylarını approver gelen gerektirebilir.For example, the policy could require a successful CI build plus a sign-off from an approver in order to merge into master.

Belirli bir noktada takımın teslim hizmeti yeni bir sürümünü dağıtmanız hazırdır.At some point, the team is ready to deploy a new version of the Delivery service. Bunu yapmak için bu adlandırma deseni ile ana dala yayın Yöneticisi oluşturur: release/<microservice name>/<semver>.To do so, the release manager creates a branch from master with this naming pattern: release/<microservice name>/<semver>. Örneğin, release/delivery/v1.0.2.For example, release/delivery/v1.0.2. Bu, önceki tüm adımları çalıştıran tam bir CI yapısı tetikler ve:This triggers a full CI build that runs all the previous steps plus:

  1. Docker görüntüsünü Azure Container Registry'ye gönderin.Push the Docker image to Azure Container Registry. Görüntü dal adı geçen sürüm numarası ile etiketlenir.The image is tagged with the version number taken from the branch name.
  2. Çalıştırma helm package Helm grafiği paketlemek içinRun helm package to package the Helm chart
  3. Helm paket çalıştırarak kapsayıcı kayıt defterine itme az acr helm push.Push the Helm package to Container Registry by running az acr helm push.

Bu derleme başarılı olduğu varsayılırsa, bir Azure işlem hatları kullanarak bir dağıtım işlemini tetikler yayın ardışık düzeni.Assuming this build succeeds, it triggers a deployment process using an Azure Pipelines release pipeline. Bu işlem hattıThis pipeline

  1. Çalıştırma helm upgrade Helm grafiği bir QA ortamına dağıtmak için.Run helm upgrade to deploy the Helm chart to a QA environment.
  2. Paket üretime gitmeden önce bir onaylayanın oturumu kapatır.An approver signs off before the package moves to production. Bkz: onayları kullanarak sürüm dağıtımı denetim.See Release deployment control using approvals.
  3. Azure Container Registry'de üretim ad alanı için Docker görüntüsünü yeniden etiketleyin.Re-tag the Docker image for the production namespace in Azure Container Registry. Örneğin, geçerli etiket ise myrepo.azurecr.io/delivery:v1.0.2, üretim etiketi reponame.azurecr.io/prod/delivery:v1.0.2.For example, if the current tag is myrepo.azurecr.io/delivery:v1.0.2, the production tag is reponame.azurecr.io/prod/delivery:v1.0.2.
  4. Çalıştırma helm upgrade Helm grafiği üretim ortamına dağıtmak için.Run helm upgrade to deploy the Helm chart to the production environment.

CI/CD iş akışı

Bir monorepo bile her bir mikro hizmetin için bu görevleri kapsamlandırılabilir ekipleri ile yüksek hızlı dağıtabilirsiniz böylece unutmamak önemlidir.It's important to remember that even in a monorepo, these tasks can be scoped to individual microservices, so that teams can deploy with high velocity. İşlem sırasında bazı el ile yapılacak adımlar şunlardır: Çekme istekleri onaylayan, yayın dallarını oluşturma ve üretim kümesine dağıtımları onaylama.There are some manual steps in the process: Approving PRs, creating release branches, and approving deployments into the production cluster. Bu adımlar, ilke tarafından el ile — kuruluş tercih ediyorsa tamamen otomatik hale.These steps are manual by policy — they could be completely automated if the organization prefers.