Aracılığıyla paylaş

Kubernetes üzerinde üretimde kendi barındırdığınız ağ geçidini çalıştırma kılavuzu

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

Kendi barındırmalı bir ağ geçidini üretimde çalıştırmak için dikkate almanız gereken çeşitli faktörler bulunmaktadır. Örneğin, yüksek oranda kullanılabilir bir şekilde dağıtılmalıdır, geçici bağlantı kesilmelerini işlemek için yapılandırma yedeklemeleri ve daha fazlası olmalıdır.

Bu makalede, sorunsuz ve güvenilir bir şekilde çalıştığından emin olmak amacıyla üretim iş yükleri için Kubernetes'te şirket içinde barındırılan bir ağ geçidi çalıştırma hakkında yönergeler sağlanır.

Authentication

Varsayılan olarak, kendi kendine barındırılan ağ geçidi tarafından, API Management örneğiyle kimlik doğrulaması yapmak için bir erişim belirteci (kimlik doğrulama anahtarı olarak da adlandırılır) kullanılır.

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 Ağ Geçidi - Belirteç Oluştur işlemini kullanın. Kubernetes gizli dizilerini yönetme hakkında bilgi için bkz. Kubernetes Gizli Dizileri.

Kendi kendine 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. Daha fazla bilgi ve önemli noktalar için bkz. Kendi barındırdığınız ağ geçidi kimlik doğrulama seçenekleri.

Otomatik ölçeklendirme

Self-hosted ağ geçidi için minimum replik sayısı hakkında rehberlik sağlasak da, trafik talebini daha proaktif bir şekilde karşılamak adına self-hosted 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

Yerel Kubernetes işlevselliğini veya Kubernetes Olay Odaklı Otomatik Ölçeklendirme 'yi (KEDA) kullanarak otomatik ölçeklendirme yapabilirsiniz. KEDA, uygulama otomatik ölçeklendirmesini basitleştirmeye çalışan bir Cloud Native Computing Foundation (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, IŞ yüklerini CPU ve bellek gibi çeşitli ölçekleyicilere göre ölçeklendirmenizi sağlayan KEDA'yı kullanabilirsiniz.

İpucu

KeDA'yı diğer iş yüklerini ölçeklendirmek için zaten 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ğini kullanmanızı kesinlikle öneririz.

Trafik tabanlı otomatik ölçeklendirme

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

KEDA, trafik tabanlı otomatik ölçeklendirmeye yardımcı olabilecek birkaç yol sağlar:

  • Kullanıma hazır bir ölçeklendirici kullanarak, Kubernetes girişine ait ölçümler Prometheus veya Azure İzleyici içinde mevcutsa, bu ö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. Daha fazla bilgi edinmek için bu GitHub örneğine bakın.

Kubernetes'te depolama hakkında bilgi edinmek için bkz. Kubernetes birimleri. Bir bağlı yolun sahipliğini değiştirmek için ayarasecurityContext.fsGroup bakın.

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 güvenmez.

Daha fazla bilgi edinmek için bkz. Helm ile Kubernetes'e özyönetimli ağ geçidi dağıtımı.

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
  • Sanallaştırmanın varlığı ve 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ı
  • Veri yükü boyutu ve veri yüklerinin arabelleğe alınıp alınmadığı veya akış olarak gönderilip gönderilmediği
  • 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 bkz. Hizmetler ve Podlar için DNS. 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 olmayan sayıda ağ geçidi podu içeren dağıtımlarda trafiğin asimetrik dağıtımına neden olabileceğini unutmayın.

Sağlık yoklaması

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, trafiği yalnızca başarıyla başlatılan ve trafiğe hizmet vermeye hazır olan veya yanıt vermeye devam eden ağ geçidi dağıtımlarına yönlendirmenize yardımcı olur.

Sağlık denetimleri olmadan, ağ geçidi dağıtımlarınız daha hızlı başlatılabilir, ancak yapılandırma henüz tam olarak yüklenmemiş olabilir ve bu da veri düzlemi trafiğinizde 503 hataları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şabilir 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.

Daha fazla bilgi edinmek için bkz. Helm ile Kubernetes'e kendi kendine barındırılan ağ geçidi dağıtma.

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 bkz. Azure Kubernetes Service'te kullanılabilirlik alanlarını yapılandırma.

Pod kesintilerine karşı koruma

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

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) ara sunucusu için destek sağlar.

Yapılandırıldıktan sonra, kendi kendine barındırılan ağ geçidi, arka uç hizmetlerine yönelik tüm giden HTTP(S) istekleri için otomatik olarak proxy kullanı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. Uygun şekilde yapılandırmayı öğrenmek için bkz. Kendi Kendine Barındırılan Ağ Geçidi Ayarları Başvurusu.

Uyarı

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

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 veri akışı kesilir ve kesinti sırasında veriler kaybolur.

Azure bağlantı kesintileri sırasında API trafiğini gözlemleyebilme ve veri 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, kendinden yönetilen bir ağ geçidi, RollingUpdatedağıtım stratejisi ile 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.

  • Hız sınırlandırma senkronizasyonu için UDP bağlantı noktası 4290
  • Diğer örneklere kalp atışları göndermek için 4291 (UDP) bağlantı noktası

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 root yetkisi olmadan çalışabilir ve bu sayede müşteriler ağ geçidini güvenli bir şekilde çalıştırabilir.

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