Kubernetes'teki Ingress ve Load Balancer'ın rolleri hakkında oldukça kafam karıştı.
Anladığım kadarıyla, Ingress gelen trafiği internetten kümede çalışan hizmetlere eşlemek için kullanılır.
Yük dengeleyicinin rolü, trafiği bir ana bilgisayara iletmektir. Bu bakımdan giriş yük dengeleyiciden nasıl farklıdır? Ayrıca Amazon ELB ve ALB ile karşılaştırıldığında kubernet içindeki yük dengeleyici kavramı nedir?
Yanıtlar:
Yük Dengeleyici: Bir kubernetes LoadBalancer hizmeti, kübernet kümenizde DEĞİL, ancak başka bir yerde var olan harici yük dengeleyicilerini gösteren bir hizmettir. Bölmelerinizin harici olarak yönlendirilebilir olduğunu varsayarak bölmelerinizle çalışabilirler. Google ve AWS bu özelliği yerel olarak sağlar. Amazon açısından, AWS'de çalışırken bu doğrudan ELB ve kubernet'lerle eşlenir, dağıtılan her LoadBalancer hizmeti için otomatik olarak bir ELB örneği sağlayabilir ve yapılandırabilir.
Giriş: Giriş , onları dinleyen bir denetleyiciye geçmek için gerçekten sadece bir dizi kuraldır. Bir sürü giriş kuralı dağıtabilirsiniz, ancak bunları işleyebilecek bir denetleyiciniz olmadığı sürece hiçbir şey olmaz. Bir LoadBalancer hizmeti, yapılandırılmışsa, giriş kurallarını dinleyebilir.
Kümenin dışında harici olarak yönlendirilebilen bir IP'ye sahip olan ancak kümenizde bulunan bir kapsüle işaret eden bir NodePort hizmeti de oluşturabilirsiniz . Bu bir Giriş Kontrolörü olabilir.
Giriş denetleyicisi, giriş kurallarını yorumlamak için yapılandırılmış bir bölmedir. Kubernetes tarafından desteklenen en popüler giriş denetleyicilerinden biri nginx. Amazon açısından, ALB bir giriş kontrolörü olarak kullanılabilir .
Örneğin, bu nginx denetleyicisi tanımladığınız giriş kurallarını alabilir ve bunları yüklediği ve bölmesinde başladığı bir nginx.conf dosyasına çevirebilir.
Diyelim ki aşağıdaki gibi bir giriş tanımladınız:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
Daha sonra nginx denetleyici bölmenizi incelerseniz, aşağıdaki kuralın tanımlandığını görürsünüz /etc/nginx.conf:
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginx, kümenizdeki http://kubernetes.foo.bar/apphizmete yönlendirmek için bir kural oluşturdu appsvc.
Aşağıda, nginx giriş denetleyicisine sahip bir kubernetes kümesinin nasıl uygulanacağına ilişkin bir örnek verilmiştir. Bu yardımcı olur umarım!
NodePort, LoadBalancer ve Ingress arasındaki farkları açıklayan bu çok ilginç makaleyi buldum .
Makalede bulunan içerikten:
Yük dengeleyici:
LoadBalancer servisi, bir servisi internete açığa çıkarmanın standart yoludur. GKE'de bu, tüm trafiği hizmetinize yönlendirecek tek bir IP adresi verecek bir Ağ Yük Dengeleyicisini döndürecektir.
Bir hizmeti doğrudan göstermek istiyorsanız, bu varsayılan yöntemdir. Belirttiğiniz bağlantı noktasındaki tüm trafik hizmete yönlendirilir. Filtreleme, yönlendirme vb. Yoktur. Bu, HTTP, TCP, UDP, Web Soketleri, gRPC veya benzeri gibi neredeyse her türlü trafiği gönderebileceğiniz anlamına gelir.
Büyük dezavantajı, bir LoadBalancer ile ortaya koyduğunuz her hizmetin kendi IP adresini alması ve maruz kalan hizmet başına pahalı olabilen bir LoadBalancer için ödeme yapmanız gerektiğidir!
Ingress:
Ingress aslında bir tür hizmet değil. Bunun yerine, birden çok hizmetin önünde yer alır ve kümenize "akıllı yönlendirici" veya giriş noktası görevi görür.
Bir Ingress ile birçok farklı şey yapabilirsiniz ve farklı yeteneklere sahip birçok Ingress denetleyicisi türü vardır.
Varsayılan GKE giriş denetleyicisi sizin için bir HTTP (S) Yük Dengeleyicisini döndürür. Bu, arka uç hizmetlerine hem yol tabanlı hem de alt alan tabanlı yönlendirme yapmanıza olanak tanır. Örneğin, foo.alanadiniz.com.tr üzerindeki her şeyi foo hizmetine ve alanadiniz.com.tr/bar/ bar hizmetine giden yolun altındaki her şeyi gönderebilirsiniz.
Ingress, hizmetlerinizi ifşa etmenin en güçlü yoludur, ancak aynı zamanda en karmaşık olabilir. Google Cloud Load Balancer, Nginx, Contour, Istio ve diğerlerinden pek çok Giriş denetleyicisi türü vardır. Sertifika yöneticisi gibi Ingress denetleyicileri için hizmetleriniz için otomatik olarak SSL sertifikaları sağlayabilen eklentiler de vardır.
Ingress, aynı IP adresi altında birden çok hizmeti göstermek istiyorsanız en yararlı olanıdır ve bu hizmetlerin tümü aynı L7 protokolünü (genellikle HTTP) kullanır. Yerel GCP entegrasyonunu kullanıyorsanız yalnızca bir yük dengeleyici için ödeme yaparsınız ve Ingress “akıllı” olduğu için kutudan çok fazla özellik alabilirsiniz (SSL, Auth, Routing vb.)
TP: DR
Pratik kullanım örneğiyle başlayalım: Tek bir etki alanı adı altında dağıtmak için hizmet uygulama paketleri (açıklık ve kısalık için ASIP) tarafından desteklenen birden çok Apiniz var. Son teknoloji ürünü bir geliştirici olduğunuzdan, her bir ASIP için ayrı dağıtımlar gerektiren bir mikro hizmetler mimarisi uyguladınız, böylece bunlar ayrı ayrı yükseltilebilir veya ölçeklendirilebilir. Tabii ki, bu ASIP'ler ayrı ayrı docker konteynerinde kapsüllenir ve konteyner deposundan Kubernetes (K8) tarafından kullanılabilir.
Şimdi bunu Google'ın GKE K8'lerine dağıtmak istediğinizi varsayalım. Sürekli kullanılabilirliği uygulamak için, her ASIP örneği (çoğaltma), her VM'nin kendi bulut dahili IP adresine sahip olduğu farklı düğümlere (VM) dağıtılır. Her ASIP dağıtımı, diğer şeylerin yanı sıra, verilen ASIP K8'lerin dağıtılması gereken çoğaltma sayısını belirtebileceğiniz, uygun bir şekilde "deployment.yaml" dosyasında yapılandırılır.
Bir sonraki adım API'yı ouside dünyasına ve huni isteklerini konuşlandırılmış ASIP örneğinden birine göstermektir. Aynı ASIP'in farklı düğümlerde çalışan birçok kopyasına sahip olduğumuzdan, isteği bu kopyalar arasında dağıtacak bir şeye ihtiyacımız var. Bu sorunu çözmek için, bir IP adresi aracılığıyla dışarıdan açılacak ve erişilebilir olacak bir K8s hizmetini (KServ) yapılandıracak bir "service.yaml" dosyası oluşturabilir ve uygulayabiliriz. Bu KServ, yapılandırılmış ASIP'leri arasında API'nın istek dağıtımından sorumlu olacaktır. ASIP düğümü başarısız olduğunda ve yeniden başlatıldığında, KServ'in K8s master tarafından otomatik olarak yeniden yapılandırılacağını unutmayın. Bu durumda dahili IP adresi asla yeniden kullanılmaz ve KServ'e yeni ASIP'nin dağıtım konumu hakkında bilgi verilmelidir.
Ancak aynı alan adında gösterilecek başka Api hizmet paketlerimiz var. Yeni bir KServ döndürmek yeni bir harici IP adresi oluşturur ve bu adresi aynı alan adında gösteremeyiz. Ingress burada devreye giriyor.
Ingress oturumu İnternet ile dış dünyaya açıkladığımız tüm KS hizmetleri arasındadır. Ingress yük dengeleme, SSL sonlandırma ve isme dayalı sanal barındırma sağlayabilir. İkinci kapasite, URL'sini analiz ederek gelen bir talebi doğru hizmete yönlendirebilir. Tabii ki, Ingress doğru KServ'e bir istek göndermek için gerekli olan yeniden yazma ve yolları belirleyecek bir ... "ingress.yaml" dosyasıyla yapılandırılmalı ve uygulanmalıdır.
İnternet -> Ingress -> K8s Servisleri -> Kopyalar
Bu nedenle, doğru giriş, KServices ve ASIPs yapılandırmasıyla, birçok alan adını aynı alan adını kullanarak güvenli bir şekilde gösterebiliriz.
Kümenizdeki bölmelerin dış trafik almasına izin vermenin 4 yolu vardır:
1.) HostNetworking kullanarak bölme: doğru ve (Düğüm başına doğrudan bölme düğümündeki bağlantı noktalarını dinlemek için 1 bölmeye izin verir. Minikube, çıplak metal ve rasberry pi'ler bazen gider ana bilgisayar düğümünün 80/443 numaralı bağlantı noktasında dinlemesine izin verebilen bu yol, bir yük dengeleyici veya gelişmiş bulut yük dengeleyici yapılandırmaları kullanılmasına izin vermez, aynı zamanda SNAT'ı önlemek / harici dışta benzer etki elde etmek için yararlı olabilecek Kubernetes Hizmetlerini atlar.
AWS'de olduğu gibi desteklenmez.)
2.) NodePort Hizmeti
3.) LoadBalancer Hizmeti (NodePort Hizmetini temel alır)
4.) Ingress Controller + Ingress Nesneleri (Yukarıdakileri temel alır)
Diyelim ki kümenizde barındırılan 10 web siteniz var ve bunların tümünü harici trafiğe göstermek istiyorsunuz.
* Type LoadBalancer Service kullanıyorsanız, 10 HA Cloud yük dengeleyici üreteceksiniz (her biri maliyetlidir)
* Type Ingress Controller kullanıyorsanız 1 HA Cloud yük dengeleyici üreteceksiniz (para tasarrufu sağlar) ve bir Ingress'i gösterecektir. Kümenizde çalışan denetleyici.
Giriş denetleyicisi:
Kümenizdeki L7 LB / Ingress Denetleyici, Kümenizdeki Küme IP Hizmetlerine giden Denge / ters proxy trafiğini yükler, ayrıca TLS sertifikası türünde bir Kubernetes Secret'a ve ona başvuran Ingress nesnesine sahipseniz HTTPS'yi de sonlandırabilir.)
Giriş: Giriş Nesnesi + Giriş Denetleyici
Giriş Nesnesi:
Tıpkı bir Hizmet Nesnesi gibi, tek başına hiçbir şey yapmaz. Bir Giriş Nesnesi, istek yolu, istek etki alanı ve hedef kubernetes hizmeti gibi şeyleri belirterek Katman 7 trafiğini kümenize yönlendirmenin bir yolunu açıklarken, bir hizmet nesnesi aslında hizmetler oluşturur
Giriş Kontrolörü:
Bir Hizmet:
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Objects
3. Creates internal L7 routing rules based on these Ingress Objects
Örneğin, Nginx Giriş denetleyicisi, 80 ve 443 numaralı bağlantı noktasını dinlemek ve sonra yeni Giriş Nesneleri'ni okumak ve bunları dinamik olarak nginx.conf içine yerleştirdiği yeni sunucu {} bölümlerine ayrıştırmak için bir hizmet kullanabilir.
LoadBalancer: Harici Yük Dengeleyici Sağlayıcısı + Hizmet Türü
Harici Yük Dengeleyici Sağlayıcısı:
Harici Yük Dengeleyici Sağlayıcıları genellikle AWS ve GKE gibi bulutlarda yapılandırılır ve harici yük dengeleyicileri oluşturarak harici IP'ler atamak için bir yol sağlar. Bu işlevsellik "LoadBalancer" türü olarak bir hizmet atanarak kullanılabilir.
Servis tipi:
Hizmet türü LoadBalancer olarak ayarlandığında Kubernetes, Kubernetes bölmeleri için girişler içeren harici bir yük dengeleyici oluşturmaya ve programlamaya çalışır, böylece bunlara harici IP'ler atar.
Kubernetes servis kontrolörü, harici yük dengeleyicisinin oluşturulmasını, gerekirse sağlık kontrollerini (gerekirse), güvenlik duvarı kurallarını (gerekirse) otomatik hale getirir ve bulut sağlayıcısı tarafından tahsis edilen ve bulut sunucusu tarafından atanan yeni oluşturulan veya yapılandırılan LoadBalancer'ın harici IP'sini alır hizmet nesnesi.
İlişkiler:
Giriş denetleyicisi hizmetleri genellikle LoadBalancer türü olarak sağlanır, böylece http ve https istekleri harici bir IP üzerinden belirli iç hizmetlere proxy / yönlendirilebilir.
Ancak bunun için bir LoadBalancer kesinlikle gerekli değildir. Bu nedenle, hostNetwork veya hostPort kullanarak ana bilgisayardaki bir bağlantı noktasını bir hizmete teknik olarak bağlayabilirsiniz (ana bilgisayar harici ip: bağlantı noktası üzerinden ziyaret etmenize izin verir). Ancak resmi olarak bu, gerçek düğümdeki bağlantı noktalarını kullandığından önerilmez.
Referanslar:
https://kubernetes.io/docs/concepts/configuration/overview/#services
https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/
https://kubernetes.io/docs/concepts/services-networking/ingress/
Basit bir deyişle, yük dengeleyici, istekleri birden fazla arka uç hizmeti (aynı türden) arasında dağıtırken, giriş, isteği örneğin URL'ye dayalı olarak belirli bir arka uç hizmetine yönlendiren bir API ağ geçidi (ters proxy) gibidir.