Üretimde Kubernetes'te şirket içinde barındırılan ağ geçidi çalıştırma kılavuzu

  • Makale

ŞUNLAR IÇIN GEÇERLIDIR: Geliştirici | Premium

Şirket içinde barındırılan ağ geçidini üretim ortamında çalıştırmak için göz önünde bulundurulması gereken çeşitli yönler vardır. Örneğin, yüksek oranda kullanılabilir bir şekilde dağıtılmalıdır, geçici bağlantı kesilmelerini ve daha fazlasını işlemek için yapılandırma yedeklerini kullanın.

Bu makalede, üretim iş yükleri için Kubernetes'te şirket içinde barındırılan ağ geçidinin sorunsuz ve güvenilir bir şekilde çalıştığından emin olmak için nasıl çalıştırılacağına ilişkin yönergeler sağlanır.

Önemli

Azure API Management şirket içinde barındırılan ağ geçidi sürüm 0 ve sürüm 1 kapsayıcı görüntüleri desteği, ilgili Yapılandırma API'si v1 ile birlikte 1 Ekim 2023'te sona eriyor. Configuration API v2 ile şirket içinde barındırılan ağ geçidi v2.0.0 veya üzerini kullanmak için geçiş kılavuzumuzu kullanın. Kullanımdan kaldırma belgelerimizden daha fazla bilgi edinin

Erişim belirteci

Geçerli bir erişim belirteci olmadan, şirket içinde barındırılan bir ağ geçidi ilişkili API Management hizmetinin uç noktasından yapılandırma verilerine erişemez ve bu verileri indiremez. Erişim belirteci en fazla 30 gün geçerli olabilir. Yeniden oluşturulmalıdır ve küme, süresi dolmadan önce el ile veya otomasyon aracılığıyla yeni bir belirteçle yapılandırılmalıdır.

Belirteç yenilemeyi otomatikleştirdiğinizde, yeni bir belirteç oluşturmak için bu yönetim API'sini kullanın. Kubernetes gizli dizilerini yönetme hakkında bilgi için Bkz . Kubernetes web sitesi.

İpucu

Ayrıca Şirket içinde barındırılan ağ geçidini Kubernetes'e dağıtabilir ve Microsoft Entra Id kullanarak API Management örneğinde kimlik doğrulamasını etkinleştirebilirsiniz.

Otomatik ölçeklendirme

Şirket içinde barındırılan ağ geçidi için en düşük çoğaltma sayısı konusunda rehberlik sağlarken, trafiğinizin talebini daha proaktif bir şekilde karşılamak için şirket içinde barındırılan ağ geçidi için otomatik ölçeklendirmeyi kullanmanızı öneririz.

Şirket içinde barındırılan ağ geçidini yatay olarak otomatik ölçeklendirmenin iki yolu vardır:

  • Kaynak kullanımına (CPU ve bellek) göre otomatik ölçeklendirme
  • Saniyedeki istek sayısına göre otomatik ölçeklendirme

Bu, yerel Kubernetes işlevselliği aracılığıyla veya Kubernetes Olay Odaklı Otomatik Ölçeklendirme (KEDA) kullanılarak mümkündür. KEDA, uygulama otomatik ölçeklendirmesini basitleştirmeye çalışan bir CNCF Kuluçka projesidir.

Not

KEDA, Azure desteği tarafından desteklenmeyen ve müşteriler tarafından çalıştırılması gereken açık kaynaklı bir teknolojidir.

Kaynak tabanlı otomatik ölçeklendirme

Kubernetes, Yatay Pod Otomatik Ölçeklendiricisi kullanarak kaynak kullanımına göre şirket içinde barındırılan ağ geçidini otomatik ölçeklendirmenizi sağlar. CPU ve bellek eşiklerini ve ölçeği genişletecek veya daraltacak çoğaltma sayısını tanımlamanızı sağlar.

Alternatif olarak Kubernetes Event-driven Autoscaling (KEDA) kullanarak iş yüklerini CPU ve bellek gibi çeşitli ölçekleyicilere göre ölçeklendirin.

İpucu

Diğer iş yüklerini ölçeklendirmek için ZATEN KEDA kullanıyorsanız, KEDA'yı birleşik bir uygulama otomatik ölçeklendiricisi olarak kullanmanızı öneririz. Böyle bir durum söz konusu değilse, Yatay Pod Otomatik Ölçeklendiricisi aracılığıyla yerel Kubernetes işlevselliğine güvenmenizi kesinlikle öneririz.

Trafik tabanlı otomatik ölçeklendirme

Kubernetes, trafik tabanlı otomatik ölçeklendirme için kullanıma hazır bir mekanizma sağlamaz.

Kubernetes Olay Odaklı Otomatik Ölçeklendirme (KEDA), trafik tabanlı otomatik ölçeklendirmeye yardımcı olabilecek birkaç yol sağlar:

  • Kullanıma hazır bir ölçeklendirici kullanarak Prometheus veya Azure İzleyici'de kullanılabiliyorsa Kubernetes girişindeki ölçümlere göre ölçeklendirme yapabilirsiniz
  • Beta sürümünde kullanılabilen HTTP eklentisini yükleyebilir ve saniyedeki istek sayısına göre ölçeklendirin.

Yapılandırma yedeklemesi

Şirket içinde barındırılan ağ geçidi kapsayıcısı için yerel bir depolama birimi yapılandırın; böylece indirilen en son yapılandırmanın yedek kopyasını kalıcı hale gelebilir. Bağlantı kesilirse, depolama birimi yeniden başlatıldıktan sonra yedek kopyayı kullanabilir. Birim bağlama yolu /apim/config olmalıdır ve grup kimliğine 1001sahip olmalıdır. GitHub'da bir örne bakın. Kubernetes'te depolama hakkında bilgi edinmek için Kubernetes web sitesine bakın. Bağlı bir yolun sahipliğini değiştirmek için Kubernetes web sitesindeki ayara bakınsecurityContext.fsGroup.

Not

Geçici bir Azure bağlantı kesintisi varlığında şirket içinde barındırılan ağ geçidi davranışı hakkında bilgi edinmek için bkz . Şirket içinde barındırılan ağ geçidine genel bakış.

Kapsayıcı görüntüsü etiketi

Azure portalında sağlanan YAML dosyası en son etiketi kullanır. Bu etiket her zaman şirket içinde barındırılan ağ geçidi kapsayıcı görüntüsünün en son sürümüne başvurur.

Daha yeni bir sürüme yanlışlıkla yükseltmeyi önlemek için üretimde belirli bir sürüm etiketi kullanmayı göz önünde bulundurun.

Kullanılabilir etiketlerin tam listesini indirebilirsiniz.

İpucu

Helm ile yükleme yaparken görüntü etiketleme sizin için iyileştirilmiştir. Helm grafiğinin uygulama sürümü, ağ geçidini belirli bir sürüme sabitler ve kullanmaz latest.

Helm ile Kubernetes'e API Management şirket içinde barındırılan ağ geçidi yükleme hakkında daha fazla bilgi edinin.

Kapsayıcı kaynakları

Varsayılan olarak, Azure portalında sağlanan YAML dosyası kapsayıcı kaynak isteklerini belirtmez.

Kapsayıcı başına CPU ve bellek kaynaklarının miktarını ve belirli bir iş yükünü desteklemek için gereken çoğaltma sayısını güvenilir bir şekilde tahmin etmek ve önermek mümkün değildir. Aşağıdakiler gibi birçok faktör devreye alınır:

  • Kümenin üzerinde çalıştığı belirli donanım.
  • İletişim durumu ve sanallaştırma türü.
  • Eşzamanlı istemci bağlantılarının sayısı ve oranı.
  • İstek oranı.
  • Yapılandırılmış ilkelerin türü ve sayısı.
  • Yük boyutu ve yüklerin arabelleğe alınıp alınmadığı veya akışa alınıp alınmadığı.
  • Arka uç hizmeti gecikme süresi.

Başlangıç noktası olarak kaynak isteklerini iki çekirdeğe ve 2 GiB'ye ayarlamanızı öneririz. Bir yük testi gerçekleştirin ve sonuçlara göre ölçeği artırma/genişletme veya azaltma/daraltma.

Özel etki alanı adları ve SSL sertifikaları

API Management uç noktaları için özel etki alanı adları kullanıyorsanız, özellikle de Yönetim uç noktası için özel bir etki alanı adı kullanıyorsanız, varsayılan etki alanı adını özel etki alanı adıyla değiştirmek için gateway-name.yaml> dosyasındaki değerini config.service.endpoint<güncelleştirmeniz gerekebilir. Yönetim uç noktasına Kubernetes kümesindeki şirket içinde barındırılan ağ geçidinin podundan erişilebildiğinden emin olun.

Bu senaryoda, Yönetim uç noktası tarafından kullanılan SSL sertifikası iyi bilinen bir CA sertifikası tarafından imzalanmazsa, CA sertifikasına şirket içinde barındırılan ağ geçidinin podu tarafından güvenildiğinden emin olmanız gerekir.

Not

Şirket içinde barındırılan ağ geçidi v2 ile API Management yeni bir yapılandırma uç noktası sağlar: <apim-service-name>.configuration.azure-api.net. Özel konak adları bu uç nokta için desteklenir ve varsayılan konak adı yerine kullanılabilir.

DNS ilkesi

DNS ad çözümlemesi, şirket içinde barındırılan ağ geçidinin Azure'daki bağımlılıklara bağlanma ve arka uç hizmetlerine API çağrıları gönderme özelliğinde kritik bir rol oynar.

Azure portalında sağlanan YAML dosyası varsayılan ClusterFirst ilkesini uygular. Bu ilke, küme DNS'sinin çözümlemediği ad çözümleme isteklerinin düğümden devralınan yukarı akış DNS sunucusuna iletilmesine neden olur.

Kubernetes'te ad çözümleme hakkında bilgi edinmek için Kubernetes web sitesine bakın. DNS ilkesini veya DNS yapılandırmasını kurulumunuz için uygun şekilde özelleştirmeyi göz önünde bulundurun.

Dış trafik ilkesi

Azure portalında sağlanan YAML dosyası, Service nesnesindeki alanını olarak LocalayarlarexternalTrafficPolicy. Bu, çağıranın IP adresini (istek bağlamında erişilebilir) korur ve düğümler arası yük dengelemeyi devre dışı bırakır ve bunun neden olduğu ağ atlamalarını ortadan kaldırır. Bu ayarın düğüm başına eşit sayıda ağ geçidi podu olmayan dağıtımlarda trafiğin asimetrik dağıtımına neden olabileceğini unutmayın.

Yüksek kullanılabilirlik

Şirket içinde barındırılan ağ geçidi, altyapıda önemli bir bileşendir ve yüksek oranda kullanılabilir olması gerekir. Ancak hata oluşur ve gerçekleşebilir.

Şirket içinde barındırılan ağ geçidini kesintilere karşı korumayı göz önünde bulundurun.

İpucu

Helm ile yükleme yaparken, yapılandırma seçeneğini etkinleştirerek highAvailability.enabled yüksek kullanılabilir zamanlamayı kolayca etkinleştirin.

Helm ile Kubernetes'e API Management şirket içinde barındırılan ağ geçidi yükleme hakkında daha fazla bilgi edinin.

Düğüm hatasına karşı koruma

Veri merkezi veya düğüm hataları nedeniyle etkilenmeyi önlemek için, düğüm düzeyinde yüksek kullanılabilirlik elde etmek için kullanılabilirlik alanlarını kullanan bir Kubernetes kümesi kullanmayı göz önünde bulundurun.

Kullanılabilirlik alanları, aşağıdakileri kullanarak bölgelere yayılmış düğümlerde şirket içinde barındırılan ağ geçidinin podunu zamanlamanıza olanak sağlar:

Not

Azure Kubernetes Service kullanıyorsanız, bu makalede kullanılabilirlik alanlarını kullanmayı öğrenin.

Pod kesintilerine karşı koruma

Podlar el ile pod silme, düğüm bakımı gibi çeşitli nedenlerle kesinti yaşayabilir.

Herhangi bir zamanda kullanılabilir olacak en az sayıda podu zorunlu kılmak için Pod Kesintisi Bütçelerini kullanmayı göz önünde bulundurun.

HTTP(S) ara sunucusu

Şirket içinde barındırılan ağ geçidi, geleneksel HTTP_PROXYve HTTPS_PROXYNO_PROXY ortam değişkenlerini kullanarak HTTP(S) ara sunucusu için destek sağlar.

Yapılandırıldıktan sonra, şirket içinde barındırılan ağ geçidi otomatik olarak arka uç hizmetlerine yönelik tüm giden HTTP(S) istekleri için ara sunucuyu kullanır.

Sürüm 2.1.5 veya üzeri ile başlayarak şirket içinde barındırılan ağ geçidi, istek ara sunucusu oluşturmayla ilgili gözlemlenebilirlik sağlar:

  • API Denetçisi , HTTP(S) ara sunucusu kullanılırken ve ilgili etkileşimlerinde ek adımlar gösterir.
  • İstek ara sunucusu davranışının göstergesini sağlamak için ayrıntılı günlükler sağlanır.

Not

Temel kimlik doğrulaması kullanan HTTP proxy'leriyle ilgili bilinen bir sorun nedeniyle, sertifika iptal listesi (CRL) doğrulamasının kullanılması desteklenmez. Şirket İçinde Barındırılan Ağ Geçidi ayarlarımızda daha fazla bilgi edinmek için uygun şekilde nasıl yapılandıracağınızı öğrenin.

Uyarı

Altyapı gereksinimlerinin karşılandığından ve şirket içinde barındırılan ağ geçidinin bunlara bağlanaabildiğinden veya belirli işlevlerin düzgün çalışmadığından emin olun.

Yerel günlükler ve ölçümler

Şirket içinde barındırılan ağ geçidi telemetriyi Azure İzleyici'ye gönderir ve ilişkili API Management hizmetindeki yapılandırma ayarlarına göre Azure Uygulaması Analizler. Azure bağlantısı geçici olarak kesildiğinde, Azure'a telemetri akışı kesilir ve kesinti süresi boyunca veriler kaybolur.

Azure bağlantı kesintileri sırasında API trafiğini gözlemleyebilmek ve telemetri kaybını önlemek için kapsayıcılarınızı izlemek veya yerel izleme ayarlamak için Azure İzleyici Kapsayıcı Analizler kullanmayı göz önünde bulundurun.

Ad Alanı

Kubernetes ad alanları , tek bir kümeyi birden çok ekip, proje veya uygulamaya bölmeye yardımcı olur. Ad alanları, kaynaklar ve adlar için bir kapsam sağlar. Bunlar bir kaynak kotası ve erişim denetimi ilkeleriyle ilişkilendirilebilir.

Azure portalı, varsayılan ad alanında şirket içinde barındırılan ağ geçidi kaynakları oluşturmaya yönelik komutlar sağlar. Bu ad alanı otomatik olarak oluşturulur, her kümede bulunur ve silinemez. Şirket içinde barındırılan bir ağ geçidi oluşturup üretimde ayrı bir ad alanına dağıtmayı göz önünde bulundurun.

Çoğaltma sayısı

Üretim için uygun en az çoğaltma sayısı üç,tercihen örneklerin yüksek kullanılabilir zamanlaması ile birleştirilir.

Varsayılan olarak, şirket içinde barındırılan bir ağ geçidi RollingUpdate dağıtım stratejisiyle dağıtılır. Varsayılan değerleri gözden geçirin ve özellikle yüksek çoğaltma sayısı kullanırken maxUnavailable ve maxSurge alanlarını açıkça ayarlamayı göz önünde bulundurun.

Performans

Performansı artırmak için kapsayıcı günlüklerini uyarılara (warn) azaltmanızı öneririz. Şirket içinde barındırılan ağ geçidi yapılandırma başvurumuzdan daha fazla bilgi edinin.

İstek azaltma

Şirket içinde barındırılan bir ağ geçidinde istek azaltma, API Management hız sınırı veya anahtara göre hız sınırı ilkesi kullanılarak etkinleştirilebilir. Örnek bulma için Kubernetes dağıtımında aşağıdaki bağlantı noktalarını kullanıma sunarak küme düğümleri arasında ağ geçidi örnekleri arasında eşitlenecek hız sınırı sayılarını yapılandırın:

  • Hız sınırlama eşitlemesi için bağlantı noktası 4290 (UDP)
  • Diğer örneklere sinyal göndermek için bağlantı noktası 4291 (UDP)

Not

Şirket içinde barındırılan bir ağ geçidindeki hız sınırı sayısı, yerel olarak (küme düğümleri arasındaki ağ geçidi örnekleri arasında), örneğin Kubernetes için Helm grafiği dağıtımı veya Azure portalı dağıtım şablonları kullanılarak eşitlenecek şekilde yapılandırılabilir. Ancak hız sınırı sayıları, buluttaki yönetilen ağ geçidi de dahil olmak üzere API Management örneğinde yapılandırılan diğer ağ geçidi kaynaklarıyla eşitlenmez.

Güvenlik

Şirket içinde barındırılan ağ geçidi Kubernetes'te kök olmayan olarak çalışabilir ve müşterilerin ağ geçidini güvenli bir şekilde çalıştırmasına olanak sağlar.

Şirket içinde barındırılan ağ geçidi kapsayıcısı için güvenlik bağlamının bir örneği aşağıda verilmişti:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Uyarı

Şirket içinde barındırılan ağ geçidini salt okunur dosya sistemi (readOnlyRootFilesystem: true) ile çalıştırmak desteklenmez.

Uyarı

Yerel CA sertifikalarını kullanırken, CA sertifikalarını yönetmek için şirket içinde barındırılan ağ geçidinin kullanıcı kimliği (UID) 1001 ile çalışması gerekir, aksi takdirde ağ geçidi başlatılmaz.

Sonraki adımlar