Aracılığıyla paylaş

Kubernetes'te kendinden yönetilen geçit çalıştırma kılavuzu üretimde

Şunlar için geçerlidir: Geliştirici | Premium

Kendi sunucunuzda 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 makale, üretim iş yükleri için Kubernetes üzerinde kendi ağ geçidini sorunsuz ve güvenilir bir şekilde çalıştırmak için nasıl yönergeler sağlayacağınızı açıklar.

Erişim belirteci

Geçerli bir erişim belirteci olmadan, kendi kendine barındırılan bir ağ geçidi, ilişkili API Yönetim hizmetinin uç noktasından yapılandırma verilerine erişemez ve 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. Azure'da Kubernetes gizli anahtarlarını yönetme hakkında bilgi için Kubernetes web sitesine bakın.

İpucu

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

Otomatik ölçeklendirme

Yerel barındırılan ağ geçidi için asgari replikalar sayısı konusunda rehberlik sağlarken, trafik taleplerinizi daha proaktif bir yaklaşımla karşılamak için yerel barındırılan ağ geçidi için otomatik ölçeklendirmeyi kullanmanızı öneririz.

Kendi kendine 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, kaynak kullanımına göre Yatay Pod Otomatik Ölçeklendiricisi kullanarak şirket içinde barındırılan ağ geçidini otomatik olarak ölçeklendirmenizi sağlar. CPU ve bellek eşiklerini ve ölçeği genişletmek veya daraltmak için kopya 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:

  • Prometheus veya Azure İzleyici'de kullanılabiliyorsa, kullanıma hazır bir ölçeklendirici ile 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

Kendi kendine barındırılan ağ geçidi kapsayıcısı için yerel bir depolama birimi yapılandırın; böylece en son indirilen yapılandırmanın yedek kopyasını kalıcı hale getirebilirsiniz. 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ği 1001 ait olmalıdır. GitHub'da bir örne bakın. Kubernetes'te depolama hakkında bilgi edinmek için Kubernetes web sitesine bakın. Kubernetes web sitesindeki securityContext.fsGroup bakarak bağlı bir yolun sahipliğini değiştirebilirsiniz.

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

Konteyner imaj etiketi

Azure portalında sağlanan YAML dosyası en son etiketi kullanır. Bu etiket her zaman kendiliğinden barındırılan ağ geçidi kapsayıcı imajı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 latest'e bağlı kalmaz.

Kubernetes üzerinde Helm ile bir API Management kendin barındırdığın ağ geçidini nasıl yükleyeceğiniz 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.
  • Varlık 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.yamlconfig.service.endpoint<>güncelleştirmeniz gerekebilir. Kubernetes kümesindeki yerel ağ geçidinin podundan Yönetim uç noktasına 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ının kendinden barındırılan ağ geçidinin podu tarafından güvenildiğinden emin olmanız gerekir.

Not

Öz 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ı, externalTrafficPolicy alanını Service nesnesinde Local olarak ayarlar. 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.

Sağlık Kontrolü

Ağ geçidi dağıtımlarınızda /status-0123456789abcdef hazır olma ve canlılık yoklamalarınız için HTTP yoklamaları uç noktasını kullanın. Bu, yalnızca başarıyla başlatılan ve trafiğe hizmet vermeye hazır olan veya yanıt vermeye devam ettiğini bilinen ağ geçidi dağıtımlarına trafiği yönlendirmenize yardımcı olur.

Sağlık kontrolleri olmadan ağ geçidi kurulumlarınız daha hızlı başlayabilir, ancak yapılandırma henüz tam olarak yüklenmemiş olabilir ve bu da veri düzlemi trafiğinizde 503 hata kodlarına yol açabilir.

İpucu

Helm ile yüklerken sistem durumu yoklamaları sizin için varsayılan olarak etkinleştirilir.

Yüksek kullanılabilirlik

Kendi kendine barındırılan ağ geçidi, altyapıda önemli bir bileşendir ve yüksek erişilebilirliğe sahip 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, highAvailability.enabled yapılandırma seçeneğini açarak yüksek kullanılabilirlikte zamanlamayı kolayca etkinleştirin.

Kubernetes üzerinde Helm ile bir API Management kendin barındırdığın ağ geçidini nasıl yükleyeceğiniz 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ı, kendi kendine barındırılan ağ geçidinin podunu, aşağıdakileri kullanarak, bölgelere yayılmış düğümlerde zamanlamanıza imkan tanır:

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 kesintiye uğrayabilir.

En az sayıda podun herhangi bir zamanda erişilebilir olmasını zorunlu kılmak için Pod Kesintisi Bütçelerini kullanmayı göz önünde bulundurun.

HTTP(S) ara sunucusu

Kendi kendine barındırılan ağ geçidi, geleneksel HTTP_PROXY, HTTPS_PROXY ve NO_PROXY ortam değişkenlerini kullanarak HTTP(S) proxy için destek sağlar.

Yapılandırıldığında, kendi kendine barındırılan ağ geçidi, arka uç hizmetlerine yönelik tüm giden HTTP(S) istekleri için otomatik olarak ara sunucuyu kullanacaktır.

Sürüm 2.1.5 veya üzeri ile başlayarak kendine ait ağ geçidi, istek yönlendirme ile 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ı referansında, ağ geçidini uygun şekilde nasıl yapılandıracağınızı öğrenmek için daha fazla bilgi edinin.

Uyarı

Altyapı gereksinimlerinin karşılandığından ve şirket içinde barındırılan ağ geçidinin bunlara bağlanabildiğinden emin olun; aksi takdirde belirli işlevler düzgün çalışmayacaktır.

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

Kendi kendine barındırılan ağ geçidi, ilişkili API Yönetimi hizmetindeki yapılandırma ayarlarına göre Azure İzleyici ve Azure Uygulama Insights'a telemetri gönderir. 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 Container Insights'ı kullanmayı göz önünde bulundurun.

İsim 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ı, şirket içinde barındırılan ağ geçidi kaynakları oluşturmak için varsayılan ad alanında komutlar sağlar. Bu ad alanı otomatik olarak oluşturulur, her kümede bulunur ve silinemez. Kendi kendine barındırılan bir ağ geçidi oluşturmayı ve bunu üretimde ayrı bir ad alanına dağıtmayı göz önünde bulundurun.

Replica sayısı

Üretim için uygun olan en az çoğaltma sayısı üçtür ve bu sayının, örneklerin yüksek erişilebilirlikte zamanlanması ile birleştirilmesi tercih edilir.

Varsayılan olarak, self-hosted 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. Kendi kendine barındırılan ağ geçidi yapılandırma referansımızda daha fazla bilgi edinin.

İstek sınırlandırma

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

  • UDP 4290 numaralı port, hız sınırlama eşitlemesi için.
  • 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ımları, yerel olarak (küme düğümleri arasındaki ağ geçidi örnekleri arasında) eşitlenecek şekilde yapılandırılabilir; örneğin, Kubernetes için Helm çizelgesi dağıtımı yoluyla veya Azure portalı dağıtım şablonları kullanılarak. 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

Kendi kendine barındırılan ağ geçidi, Kubernetes üzerinde kök haklarına sahip olmadan çalışabilir ve bu da müşterilerin ağ geçidini güvenli bir şekilde çalıştırmasına olanak tanır.

Kendi kendine barındırılan ağ geçidi kapsayıcısı için güvenlik bağlamına bir örnek:

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ı

Kendi kendine barındırılan ağ geçidini salt okunur dosya sistemi (readOnlyRootFilesystem: true) ile çalıştırmak desteklenmemektedir.

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.

İlgili içerik

  • Last updated on