Skip to main content

Kubernetes Küme’lerinde Gelişmiş Load Balancer Ayarlarını Yapılandırma

Kubernetes, tam yönetilen kontrol düzlemi, yüksek erişilebilirlik ve otomatik ölçeklendirme içerir.
Standart Kubernetes araç zincirleri (kubectl, API ve CLI) ile entegredir. Ayrıca CPU ve GPU node havuzlarını, load balancer’ları ve volume’leri destekler.

Kubernetes Cloud Controller Manager, load balancer’lar için gelişmiş ayarların yapılmasına olanak tanır.
Bu ayarlar, servis yapılandırma dosyasındaki metadata kısmında anotasyonlar (annotations) aracılığıyla eklenir.
Yanlış bir anotasyon değeri girilirse, config dosyası uygulanmaya çalışıldığında hata alınır.

⚠️ Uyarı 
Kümenin **Resources** sekmesine ek olarak; worker node’lar, load balancer’lar ve volume’lar, 
Kubernetes sayfası dışında da listelenir.  

Bu kaynakları kontrol panelinde yeniden adlandırır veya değiştirirseniz:  
- Küme tarafından kullanılamaz hale gelebilirler,  
- Veya reconciler yeni kaynaklar oluşturabilir.  

Bunu önlemek için küme kaynaklarını yalnızca **kubectl** komutları 
veya kontrol panelinin **Kubernetes sayfası** üzerinden yönetin.

Name​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu ayar, özel bir isim belirlemenizi ya da var olan bir yük dengeleyiciyi yeniden adlandırmanızı sağlar. İsim şu kurallara uymalıdır:

  • 255 karakterden uzun olmamalı.
  • Alfanumerik karakter ile başlamalı.
  • Alfanumerik karakterler, . (nokta) veya - (tırnak işareti) içerebilir, ancak final karakter - olamaz.

Eğer özel bir isim verilmezse, load balancer varsayılan olarak Service UID’si ile başlayan bir ada sahip olur.

Örnek kullanım:

metadata:
  name: my-example-service

Protocol (Protokol)​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu ayar, LoadBalancer servisi için kullanılacak protokolü belirtir.

Kullanılabilir seçenekler: TCP veya UDP.

SSL/HTTPS gibi özellikler için genellikle Ingress + cert-manager kullanılır.

Ayrıca düzgün çalışabilmesi için TCP, HTTP veya HTTPS kullanan bir health check (sağlık kontrolü) portu ayarlamanız gerekir.

Aşağıdaki örnek, load balancer protokolü olarak https kullanımını göstermektedir:

. . .
metadata:
  name: https-protocol-snippet
. . .

Bir Load Balancer ile UDP protokolünü kullanmak için, load balancer servis yapılandırma dosyasındaki ports bölümünü aşağıdaki gibi kullanın:

spec:
  type: LoadBalancer
  selector:
    app: nginx-example
  ports:
    - name: udp
      protocol: UDP
      port: 53
      targetPort: 53

Kubernetes’teki bir hata nedeniyle, bir load balancer portu TCP ve UDP arasında paylaşılamaz.

Network Load Balancer​

Kullanılabilir sürüm: 1.29.x ve sonras

Bu ayar, TCP ve UDP trafiğini ağ katmanında yönlendiren bölgesel (regional) bir load balancer oluşturur.
Özellik şu anda public preview aşamasındadır ve IPv6 desteği bulunmamaktadır.

Aşağıdaki örnek, bir network load balancer oluşturmayı gösterir:

metadata:
  name: example-nlb

Yapılandırmanızdaki ports bölümünde protokol olarak UDP veya TCP belirtilmeli ve port ile targetPort değerleri aynı olmalıdır.

Internal Load Balancer (Dahili Load Balancer)​

Kullanılabilir sürüm: 1.28.x ve sonrası

Bu ayar, herhangi bir public IP adresi olmayan bir load balancer oluşturur.
Dahili load balancer’a erişmek için kaynakların aynı VPC içinde olması gerekir.

Bir load balancer oluşturulduktan sonra, onu normal (public IP’li) ve internal (dahili) arasında değiştirmek mümkün değildir.

Aşağıdaki örnek, bir internal load balancer oluşturmayı gösterir:

metadata:
  name: example-ilb

Health Checks (Sağlık Kontrolleri)​

Kullanılabilir sürüm: 1.27.x ve sonrası (temel işlevsellik)

Health check’ler, node’larınızın çevrim içi olduğunu ve tanımladığınız özel sağlık kriterlerini karşıladığını doğrular.
Load balancer, yalnızca sağlık kontrolünden geçen node’lara istek yönlendirir.

Eğer load balancer’ın yönlendirme kurallarında UDP kullanılıyorsa, düzgün çalışabilmesi için TCP, HTTP veya HTTPS kullanan bir health check portu ayarlamanız gerekir.

Cloud Controller Manager, pod ve node kullanılabilirliğini belirlemek, workload ve node değişimlerinde sorunsuz geçiş sağlamak için uygun bir health check yapılandırmasını otomatik olarak ayarlar.
Belirlenen spesifik değerler ise external traffic policy ayarına bağlıdır.

Not:
Genel olarak, port, path ve protocol için health check anotasyonlarını manuel olarak değiştirmemeniz önerilir.

Port​

Load balancer, servisinize ait bir port üzerinden sağlık kontrolü yapar. Varsayılan değer, serviste tanımlanan worker node’lardaki ilk NodePort’tur.
Kendi değerinizle değiştirmek için:

  • Açık bir port belirtmelisiniz (NodePort değil),
  • Ayrıca service.beta.kubernetes.io/loadbalancer-override-health-check anotasyonunu eklemelisiniz.

Path​

Load balancer, backend node’un sağlıklı olup olmadığını doğrulamak için belirlenen path değerini kullanır. Varsayılan değer /’tir.
Kendi değerinizle değiştirmek için service.beta.kubernetes.io/loadbalancer-override-health-check anotasyonunu ayarlamanız gerekir.

Protocol​

Load balancer, backend node’un sağlıklı olup olmadığını doğrulamak için bir protocol kullanır. Varsayılan değer tcp’dir. Diğer seçenekler http ve https’tir.
Kendi değerinizle değiştirmek için service.beta.kubernetes.io/loadbalancer-override-health-check anotasyonunu ayarlamanız gerekir.

UDP, sağlık kontrolü protokolü olarak desteklenmez. Ancak load balancer’ınız UDP servis portlarına sahipse, load balancer’ın düzgün çalışabilmesi için sağlık kontrolü amacıyla bir TCP servisi yapılandırmanız gerekir.

Override Health Check​

Varsayılan health check port, path ve protocol değerlerini kendi değerlerinizle değiştirmek için, ek olarak service.beta.kubernetes.io/loadbalancer-override-health-check anotasyonunu true olarak ayarlamanız gerekir.

Interval​

İki ardışık health check arasında geçen saniye süresi.

  • Değer 3 ile 300 arasında olmalıdır.
  • Varsayılan değer: 3 saniye.

Timeout​

Load balancer instance’ının bir yanıt almak için beklediği süre. Bu süre dolarsa sağlık kontrolü başarısız sayılır.

  • Değer 3 ile 300 arasında olmalıdır.
  • Varsayılan değer: 5 saniye.

Threshold​

Bir backend Droplet’in sağlıksız (unhealthy) olarak işaretlenmesi ve ilgili servisin havuzundan çıkarılması için, sağlık kontrolünün kaç kez başarısız olması gerektiğini belirtir.

  • Değer 2 ile 10 arasında olmalıdır.
  • Varsayılan değer: 3.

Aşağıdaki örnek, bir load balancer için health check yapılandırmasını göstermektedir:

metadata:
  name: health-check-snippet
  annotations:
    service.beta.kubernetes.io/loadbalancer-healthcheck-port: "80"
    service.beta.kubernetes.io/loadbalancer-healthcheck-protocol: "http"
    service.beta.kubernetes.io/loadbalancer-healthcheck-path: "/health"

External Traffic Policies ve Health Checks​

Cloud provider tarafından yönetilen load balancer’lar, kendilerini sağlayan LoadBalancer servisi için endpoint’lerin sağlık durumunu değerlendirir.

Bir health check’in davranışı, servisin externalTrafficPolicy ayarına bağlıdır.

  • Local veya Cluster olarak ayarlanabilir.

  • Local policy: Yalnızca hedef pod yerel node üzerinde çalışıyorsa health check kabul edilir.

  • Cluster policy: Node’ların, kümeye bağlı diğer node’lardaki pod’lara istekleri dağıtmasına izin verir.

Local Policy​

  • Local policy kullanan servisler, o servise ait herhangi bir yerel endpoint bulunmayan node’ları sağlıksız (unhealthy) olarak işaretler.
  • Kubernetes tarafından özel olarak oluşturulan ayrı health check node port üzerindeki kube-proxy /healthz endpoint’i, node üzerinde aktif pod olup olmadığını belirtir.

Cluster Policy​

  • Cluster policy kullanan servisler, o servisi barındıran pod’lara sahip olmasa bile node’ları sağlıklı (healthy) sayabilir.
  • Her worker node üzerinde bulunan kube-proxy /healthz endpoint’i, node’un sağlıklı olup olmadığını gösterir.

Not​

  • Local external traffic policy, worker node’ların kaldırılmadan önce güvenli şekilde boşaltılmasını (drain) garanti eder.
  • Health check parametrelerini (ör. sıklık ve threshold değerleri), node üzerindeki son hedef pod istek kabul etmeyi durdurmadan önce node’un unhealthy olarak işaretleneceği şekilde seçmelisiniz.

Ayarı Değiştirme​

Bir servis için bu ayarı değiştirmek için aşağıdaki komutu çalıştırabilirsiniz, istediğiniz policy değerini ekleyerek:

kubectl patch svc <service-adı> -p '{"spec":{"externalTrafficPolicy":"Local"}}'

Not:
externalTrafficPolicy=Local kullanmak, node’lar boşaltılmadan önce trafiğin güvenli şekilde yönlendirilmesini sağlar.
Orijinal istemci IP’sini koruma hakkında daha fazla bilgi için Kubernetes resmi belgelerine bakabilirsiniz.

Ports​

Load balancer’ın hangi portlarının HTTP, HTTP/2 veya TLS protokolü için kullanılacağını belirtebilirsiniz.

Not:
Port’lar, HTTP, TLS ve HTTP/2 port anotasyonları arasında paylaştırılamaz.

HTTP Ports​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu anotasyon, load balancer’ın hangi portlarının HTTP protokolünü kullanacağını belirtmek için kullanılır.

  • Değerler, virgülle ayrılmış port listesi şeklinde olmalıdır (örneğin: 80, 8080).

Aşağıdaki örnek, bir HTTP portunun nasıl belirtileceğini gösterir:

. . .
metadata:
  name: http-ports-snippet
annotations:
  service.beta.kubernetes.io/loadbalancer-http-ports: "80"
. . .

HTTP/2 Ports​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu anotasyon, load balancer’ın hangi portlarının HTTP/2 protokolünü kullanacağını belirtmek için kullanılır.

  • Değerler, virgülle ayrılmış port listesi şeklinde olmalıdır (örneğin: 443, 6443, 7443).
  • Eğer belirtilirse, ayrıca şu anotasyonlardan birini de tanımlamanız gerekir:
    • service.beta.kubernetes.io/loadbalancer-tls-passthrough
    • service.beta.kubernetes.io/loadbalancer-certificate-id
    • service.beta.kubernetes.io/loadbalancer-certificate-name

Eğer service.beta.kubernetes.io/loadbalancer-protocol değeri http2 olarak ayarlanmazsa, HTTP/2’yi dolaylı olarak (implicit usage) kullanabilmek için bu anotasyon zorunludur.

HTTP/2 için, service.beta.kubernetes.io/loadbalancer-tls-ports’un aksine, varsayılan bir port atanmaz.

Aşağıdaki örnek, bir HTTP/2 portunun nasıl belirtileceğini gösterir:

. . .
metadata:
  name: http2-ports-snippet
  annotations:
    service.beta.kubernetes.io/loadbalancer-http2-ports: "443,80"
. . .

HTTP/3 Ports​

Kullanılabilir sürüm: 1.25.4, 1.24.8, 1.23.14

Bu anotasyon, load balancer’ın hangi portunun HTTP/3 protokolünü kullanacağını belirtmek için kullanılır.

  • Diğer anotasyonların aksine, birden fazla port belirtilemez; yalnızca tek bir port için HTTP/3 tanımlanabilir.
  • HTTP/3 için varsayılan bir port atanmaz, bu nedenle mutlaka bir port numarası sağlamalısınız.

HTTP/3 protokolünü kullanmak için:

  • service.beta.kubernetes.io/loadbalancer-certificate-id veya
  • service.beta.kubernetes.io/loadbalancer-certificate-name
    anotasyonlarından birini eklemeniz gerekir.

Load balancer yalnızca HTTP/3 trafiği alabileceğinden, ayrıca gönderim trafiği için de bir protokol tanımlamanız gerekir. Bunun için şu anotasyonlardan birini eklemelisiniz:

  • service.beta.kubernetes.io/loadbalancer-tls-ports veya
  • service.beta.kubernetes.io/loadbalancer-http2-ports

TLS Ports​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu anotasyon, load balancer’ın hangi portlarının HTTPS protokolünü kullanacağını belirtmek için kullanılır:

Değerler, virgülle ayrılmış port listesi şeklinde olmalıdır (örneğin: 443, 6443, 7443).
Eğer belirtilirse, aşağıdakilerden birini de ayrıca tanımlamanız gerekir:

  • service.beta.kubernetes.io/loadbalancer-tls-passthrough: Load balancer’ın şifrelenmiş veriyi backend Droplet’lere iletip iletmeyeceğini belirtir. Seçenekler true veya false’tur. Varsayılan değer false’tur.

  • service.beta.kubernetes.io/loadbalancer-certificate-id: HTTPS protokolü için kullanılacak sertifika ID’sini belirtir. Mevcut sertifikaları görmek için kubectl describe certificate <cert-adı></cert-adı> (ör. cert-manager ile) komutunu kullanabilirsiniz.

  • service.beta.kubernetes.io/loadbalancer-certificate-name (1.26 ve sonrası): HTTPS protokolü için kullanılacak sertifika adını belirtir. Bu anotasyonu kullanmanız önerilir çünkü Let’s Encrypt sertifikasının adı değişmez, ancak ID’si her yenilemede değişir. Sertifika adı hesap içinde benzersiz olmalıdır. Mevcut sertifikaları görmek için kubectl describe certificate <cert-adı></cert-adı> (ör. cert-manager ile) komutunu kullanabilirsiniz.

Eğer bir HTTPS portu belirtmez ancak service.beta.kubernetes.io/loadbalancer-tls-passthrough, service.beta.kubernetes.io/loadbalancer-certificate-id veya service.beta.kubernetes.io/loadbalancer-certificate-name anotasyonlarından birini tanımlarsanız, load balancer HTTPS için varsayılan olarak 443 portunu kullanır. Ancak service.beta.kubernetes.io/loadbalancer-http2-ports anotasyonu zaten 443 portunu içeriyorsa bu kural uygulanmaz.

Aşağıdaki örnek, passthrough ile bir TLS portunun nasıl belirtileceğini göstermektedir:

. . .
metadata:
  name: tls-ports-snippet
  annotations:
    service.beta.kubernetes.io/loadbalancer-tls-ports: "443"
. . .

HTTP Idle Timeout​

Kullanılabilir sürüm: 1.27.x ve sonrası

HTTP idle timeout süresini saniye cinsinden belirtir. Varsayılan değer 60 saniyedir.

Aşağıdaki örnek, timeout değerini 65 saniye olarak belirtir:

. . .
metadata:
  name: http-idle-timeout
  annotations:
    service.beta.kubernetes.io/loadbalancer-http-idle-timeout-seconds: "65"
. . .

Accessing by Hostname​

Kullanılabilir sürüm: 1.27.x ve sonrası

Upstream Kubernetes’teki mevcut bir kısıtlama nedeniyle, pod’lar LoadBalancer tipindeki bir servis aracılığıyla ayarlanmış harici bir load balancer’ın IP adresi üzerinden diğer pod’larla iletişim kuramaz.

Bunu aşmak için:

  • Tercih ettiğiniz bir sağlayıcıda özel bir DNS kaydı oluşturup, load balancer’ın harici IP adresine yönlendirebilirsiniz.
  • Ardından servisi, service.beta.kubernetes.io/loadbalancer-hostname anotasyonuna hostname ekleyerek özel hostname’i döndürecek şekilde yapılandırın.
  • Daha sonra servisin status.Hostname alanını kullanarak hostname bilgisini alabilirsiniz.

service.beta.kubernetes.io/loadbalancer-hostname anotasyonunu ayarlama iş akışı genellikle şu şekildedir:

  1. Servisinizi içeren manifest’i deploy edin (aşağıdaki örnekte olduğu gibi).
  2. Servisin harici IP adresinin atanmasını bekleyin.
  3. Hostname’iniz için, harici IP’ye yönlendiren bir A veya AAAA DNS kaydı ekleyin.
  4. Manifest dosyanıza hostname anotasyonunu ekleyin (aşağıdaki örnekte olduğu gibi) ve yeniden deploy edin.
kind: Service
apiVersion: v1
metadata:
  name: hello
  annotations:
    service.beta.kubernetes.io/loadbalancer-certificate-id: "1234-5678-9012-3456"
    service.beta.kubernetes.io/loadbalancer-protocol: "https"
    service.beta.kubernetes.io/loadbalancer-hostname: "hello.example.com"
spec:
  type: LoadBalancer
  selector:
    app: my-app-example
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 80
. . .

SSL Sertifikaları​

Kullanılabilir sürüm: 1.27.x ve sonrası

Kubernetes kümenize gelen trafiği, load balancer ile birlikte bir SSL sertifikası kullanarak şifreleyebilirsiniz.
Öncelikle bir SSL sertifikası oluşturmanız veya yüklemeniz gerekir, ardından sertifikayı load balancer’ın yapılandırma dosyasında referans vermek için aşağıdaki anotasyonlardan birini kullanabilirsiniz:

  • service.beta.kubernetes.io/loadbalancer-certificate-id → Sertifika ID’sini belirtmek için.
  • service.beta.kubernetes.io/loadbalancer-certificate-name (1.26.x ve sonrası) → Sertifika adını belirtmek için.

Bu anotasyonu kullanmanız önerilir çünkü Let’s Encrypt sertifikasının adı değişmez, ancak ID’si her yenilemede değişir. Sertifika adı, hesap içinde benzersiz olmalıdır.

Eğer hem sertifika ID’si hem de sertifika adı belirtirseniz, sertifika ID’si önceliklidir.

Yüklenmiş SSL sertifikalarının ID’lerini almak için şu komutu kullanabilirsiniz:

kubectl describe certificate <certificate-adı>

Sertifikayı kullanabilmek için, load balancer protokolünü HTTPS olarak belirtmeniz gerekir.
Bunu yapmak için aşağıdaki anotasyonlardan birini kullanabilirsiniz:

service.beta.kubernetes.io/loadbalancer-protocol
service.beta.kubernetes.io/loadbalancer-tls-ports

Ek olarak, load balancer oluşturulurken sertifika için otomatik DNS kaydı oluşturulup oluşturulmayacağını belirtebilirsiniz.
Bunun için şu anotasyonu kullanın:

loadbalancer-disable-lets-encrypt-dns-records

Eğer true olarak ayarlanırsa, SSL sertifikasını desteklemek için alan adınızın kök (apex) kısmında otomatik olarak DNS A kaydı oluşturulmaz.

Bu ayar 1.21.5, 1.20.11 ve 1.19.15 sürümlerinden itibaren kullanılabilir.

Aşağıdaki örnek, bir SSL sertifikası kullanarak load balancer oluşturmayı gösterir:

---
kind: Service
apiVersion: v1
metadata:
  name: https-with-cert
  annotations:
    service.beta.kubernetes.io/loadbalancer-protocol: "https"
    service.beta.kubernetes.io/loadbalancer-certificate-id: "your-certificate-id"
spec:
  type: LoadBalancer
  selector:
    app: nginx-example
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 80
. . .

Not:
Bir Let’s Encrypt sertifikasını yenilediğinizde, cert-manager veya kullandığınız Ingress Controller bu yenilemeyi otomatik olarak günceller.
Ancak, UUID’yi referans alan harici yapılandırma dosyalarını ve araçları manuel olarak güncellemeniz gerekir.

Daha fazla sorun giderme için, cert-manager veya kullandığınız ingress controller dokümantasyonuna bakabilirsiniz.

Zorunlu SSL Bağlantıları​

Kullanılabilir sürüm: 1.27.x ve sonrası

SSL seçeneği, 80 numaralı porttaki HTTP isteklerini, 443 numaralı porttaki HTTPS’e yönlendirir.
Bu seçenek etkinleştirildiğinde, HTTP URL’leri 307 redirect ile HTTPS’e yönlendirilir.

Aşağıdaki örnek, yönlendirmenin çalışması için true olarak ayarlanması gereken yapılandırma ayarlarını göstermektedir:

. . .
  name: https-with-redirect-snippet
  annotations:
    service.beta.kubernetes.io/loadbalancer-protocol: "http"
    service.beta.kubernetes.io/loadbalancer-tls-ports: "443"
    service.beta.kubernetes.io/loadbalancer-certificate-id: "your-certificate-id"
    service.beta.kubernetes.io/loadbalancer-redirect-http-to-https: "true"
  spec:
    type: LoadBalancer
    selector:
      app: nginx-example
    ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 80
      - name: https
        protocol: TCP
        port: 443
        targetPort: 80
. . .

Boyut Birimi (Size Unit)​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu ayar, load balancer’ın kaç node (düğüm) ile oluşturulacağını belirtmenizi sağlar.

  • Daha fazla node, load balancer’ın aynı anda daha fazla bağlantıyı yönetebilmesi anlamına gelir.

Değer, 1 ile 200 arasında bir tam sayı olabilir ve varsayılan değer 1’dir.
Gerçek load balancer node limitiniz hesabınıza tanımlı limitlerle belirlenir. Limit artırımı talep etmek için destek ekibi ile iletişime geçebilirsiniz.

Load balancer oluşturulduktan sonra, dakikada bir kez yeniden boyutlandırma yapılabilir.

Aşağıdaki örnek, bir load balancer’ın sahip olacağı node sayısının nasıl belirtileceğini göstermektedir:

. . .
metadata:
  name: nginx
  annotations:
    service.beta.kubernetes.io/loadbalancer-size-unit: "3"
. . .

Yapışkan Oturumlar (Sticky Sessions)​

Kullanılabilir sürüm: 1.27.x ve sonrası

Sticky sessions, aynı istemciden gelen ardışık istekleri aynı node’a yönlendirir.
Bunu yapmak için yapılandırılabilir bir cookie adı ve TTL (Time-To-Live) süresi belirlenir.

  • TTL parametresi, cookie’nin istemci tarayıcısında ne kadar süreyle geçerli kalacağını tanımlar.
  • Bu özellik, her istekte aynı node’a bağlanması gereken uygulama oturumları için faydalıdır.

Önemli noktalar:

  • Sticky sessions, pod’lara değil node’lara tutarlı yönlendirme yapar. Bu yüzden aynı node üzerinde birden fazla pod’u istekleri karşılamak için çalıştırmaktan kaçınmalısınız.
  • Sticky sessions kullanabilmek için, servisinizi externalTrafficPolicy: Local ile yapılandırmanız gerekir. Bu, gelen trafik diğer node’lara iletilirken istemci kaynak IP adreslerinin korunmasını sağlar.

Sticky sessions’ı etkinleştirmek veya devre dışı bırakmak için loadbalancer-sticky-sessions-type anotasyonu kullanılır:

  • cookies → Sticky sessions’ı etkinleştirir.
  • none → Sticky sessions’ı devre dışı bırakır (varsayılan davranış).
metadata:
  name: sticky-session-snippet
  annotations:
    service.beta.kubernetes.io/loadbalancer-sticky-sessions-type: "cookies"
    service.beta.kubernetes.io/loadbalancer-sticky-sessions-cookie-name: "example"
    service.beta.kubernetes.io/loadbalancer-sticky-sessions-cookie-ttl: "60"

PROXY Protokolü​

Kullanılabilir sürüm: 1.27.x ve sonrası

PROXY protokolünü etkinleştirmek, load balancer’ın istemci bağlantı bilgilerini (örneğin istemci IP adresleri) node’larınıza iletmesine olanak tanır.
Node’lar üzerinde çalışan yazılımın, load balancer’dan gelen bu bağlantı bilgilerini kabul edecek şekilde doğru yapılandırılması gerekir.

Seçenekler: true veya false
Varsayılan değer: false

---
. . .
metadata:
  name: proxy-protocol
  annotations:
    service.beta.kubernetes.io/loadbalancer-enable-proxy-protocol: "true"
. . .

İstemci Kaynak IP Adresini Koruma​

Çoğu cloud load balancer, istekleri yönlendirirken istemcinin kaynak IP adresini otomatik olarak korumaz. Kaynak IP adresini korumak için aşağıdaki yöntemlerden birini kullanabilirsiniz:

  • PROXY protokolünü etkinleştirin → Bunun için, isteği alan uygulamanın veya ingress sağlayıcısının PROXY protokolü başlığını (header) ayrıştırabilmesi gerekir.

  • X-Forwarded-For HTTP header’ını kullanın → Çoğu cloud load balancer bu header’ı otomatik olarak ekler.
    Bu yöntem yalnızca giriş (entry) ve hedef (target) protokollerinin HTTP veya HTTP/2 olduğu durumlarda çalışır (TLS passthrough hariç).

Daha fazla bilgi için Kubernetes dokümantasyonundaki Cross-platform support bölümüne bakabilirsiniz.

Backend Keepalive (Arka Uç Kalıcı Bağlantı)​

Kullanılabilir sürüm: 1.27.x ve sonrası

Varsayılan olarak, bazı cloud provider Load Balancer’ları backend node’lardan gelen HTTP yanıtlarındaki,
Connection: keep-alive header’ını yok sayar ve işlem tamamlandığında bağlantıyı kapatır.

Backend keepalive etkinleştirildiğinde, load balancer bu header’ı dikkate alır ve bağlantıyı yeniden kullanım için açık tutar.
Bu sayede load balancer, hedef node’larla HTTP isteklerini göndermek ve almak için daha az sayıda aktif TCP bağlantısı kullanabilir.

Bu seçeneğin etkinleştirilmesi genellikle performansı artırır (saniye başına istek sayısı ve gecikme süresi) ve kaynak kullanımını daha verimli hale getirir.
Web siteleri ve API’ler gibi birçok kullanım durumunda, istemcinin deneyimlediği performansı iyileştirebilir.
Ancak, her durumda performansı artıracağı garanti edilmez ve bazı senaryolarda gecikmeyi artırabilir.

Bu seçenek, hedef protokolün HTTP veya HTTPS olduğu tüm yönlendirme kuralları için geçerlidir.
TCP, HTTPS veya HTTP/2 passthrough kullanan yönlendirme kuralları için geçerli değildir.

Load balancer ile her sunucu arasındaki bağlantı sayısı için katı bir limit yoktur.
Ancak, hedef sunucular düşük donanım kaynaklarına sahipse gelen trafiği işleyemeyebilir ve paket kayıpları yaşanabilir.
Daha fazla bilgi için Kubernetes Ingress Controller performans ayarları bölümüne bakabilirsiniz.

Seçenekler: true veya false
Varsayılan değer: false

---
. . .
metadata:
  name: backend-keepalive
  annotations:
    service.beta.kubernetes.io/loadbalancer-enable-backend-keepalive: "true"
. . .

Sahiplikten Çıkarma (Disown)​

Kullanılabilir sürüm: 1.27.x ve sonrası

Bu ayar, yönetilen bir load balancer’ın sahipliğini bırakıp bırakmayacağınızı belirtmenizi sağlar.
Sahiplikten çıkarılan load balancer’lar üzerinde artık değişiklik yapılamaz; buna oluşturma, güncelleme ve silme işlemleri de dahildir.

Bu ayarı kullanarak bir load balancer’ın sahipliğini başka bir Servis’e, hatta başka bir kümedeki Servis’e devredebilirsiniz.
Daha fazla bilgi için Load Balancer’ın Sahipliğini Değiştirme bölümüne bakabilirsiniz.

Seçenekler: true veya false
Varsayılan değer: false

Değeri string olarak sağlamanız gerekir, aksi takdirde Kubernetes’teki bir hata nedeniyle Servis kaynağınızdaki tüm anotasyonlar kaybolabilir.

⚠️ Uyarı

Sahiplikten çıkarılmış load balancer’lar, bu durumda doğru çalışmayabilir.
Bunun nedeni, hedef node’lar veya yapılandırma anotasyonları gibi gerekli güncellemelerin load balancer’a artık aktarılmamasıdır.
Benzer şekilde, Service status alanı da load balancer’ın mevcut durumunu yansıtmayabilir.
Bu nedenle, sahiplikten çıkarılmış load balancer’ları en kısa sürede yeni bir Servis’e atamanız gerekir.

Aşağıdaki örnek, bir load balancer’ın sahiplikten nasıl çıkarılacağını göstermektedir:

. . .
metadata:
  name: disown-snippet
  annotations:
    service.kubernetes.io/loadbalancer-disown: "true"
. . .

Güvenlik Duvarı Kuralları (Firewall Rules)​

Kullanılabilir sürüm: 1.27.x ve sonrası

Reddetme Kuralları (Deny Rules)​

Trafiğin geçişini engelleyen güvenlik duvarı kurallarını belirtir.
Kurallar şu formatta olmalıdır: {type}:{source}

Aşağıdaki örnek, 198.51.100.0/16 IP bloğundan gelen bağlantıları engellemek için güvenlik duvarı kurallarının nasıl ekleneceğini göstermektedir:

. . .
metadata:
  name: firewall-rules
  annotations:
    service.beta.kubernetes.io/loadbalancer-deny-rules: "cidr:198.51.100.0/16"
. . .

İzin Verme Kuralları (Allow Rules)​

Not:
service.beta.kubernetes.io/loadbalancer-allow-rules anotasyonu artık kullanımdan kaldırılmıştır. Bunun yerine, servis yapılandırma dosyasındaki LoadBalancerSourceRanges alanını kullanın.
Bu alanda belirtilen değerler, ilgili anotasyona göre önceliklidir.

Trafiğin geçişine izin veren güvenlik duvarı kurallarını belirtir.
Kurallar şu formatta olmalıdır: {type}:{source}