Kubernetes’te Servisler Neden Vazgeçilmez? Kapsamlı Rehber

Modern uygulama geliştirme dünyasında, özellikle mikroservis mimarileri ve konteynerleşmenin yükselişiyle birlikte, uygulamaların birbirleriyle ve dış dünyayla tutarlı bir şekilde iletişim kurabilmesi büyük bir zorluk haline geldi. İşte tam da bu noktada, Kubernetes servisleri devreye girerek pod’ların geçici doğasına rağmen kararlı ve güvenilir bir ağ katmanı sunar. Bu kapsamlı rehberde, Kubernetes servislerinin neden vazgeçilmez olduğunu, farklı türlerini, gerçek dünya senaryolarını ve ileri düzey kullanım ipuçlarını keşfedeceğiz. Gelin, bu karmaşık görünen konuyu adım adım basitleştirelim ve Kubernetes’in gücünü tam olarak anlamanıza yardımcı olalım.

Konteyner teknolojisi, uygulamaları izole edilmiş, taşınabilir ve ölçeklenebilir birimler halinde çalıştırma konusunda devrim yarattı. Kubernetes ise bu konteynerleri (özellikle Docker konteynerlerini) yönetmek için bir orkestrasyon platformu olarak öne çıkıyor. Kubernetes’te, uygulamalarımızın en küçük dağıtılabilir birimi Pod’lardır. Bir Pod, bir veya daha fazla konteyneri barındırır ve kendine ait bir IP adresine sahiptir. Ancak, bu Pod’ların IP adresleri ve hatta kendileri bile son derece dinamik ve geçicidir; bu durum, geleneksel uygulama ağ yaklaşımlarından önemli ölçüde farklıdır.

Öncelikle, Pod’ların doğası gereği geçici olduğunu anlamak önemlidir. Bir Pod, bir düğüm üzerinde çalışır ve yaşam döngüsü boyunca çeşitli nedenlerle yok olabilir veya yeniden oluşturulabilir. Örneğin, bir Pod’un çalıştığı düğüm çökerse, Kubernetes bu Pod’u otomatik olarak başka bir sağlıklı düğümde yeniden başlatır. Uygulamanızın yeni bir sürümünü dağıttığınızda veya ölçeklendirme gereksinimleri değiştiğinde de Pod’lar oluşturulur, güncellenir ve silinir. Her yeni Pod oluştuğunda, ona yeni bir IP adresi atanır. Bu, uygulamanızın farklı bileşenlerinin veya dış dünyanın, sürekli değişen IP adresleriyle Pod’lara doğrudan erişmeye çalışmasının son derece pratik olmadığını gösterir. Bir kullanıcı bir web sitesine bağlanmaya çalıştığında veya bir mikroservis başka bir mikroservisten veri istediğinde, hedef Pod’un IP adresinin birkaç saniye önce değişmiş olma ihtimali vardır. Bu sürekli değişim, servis keşfi ve yük dengeleme gibi temel ağ işlevlerini imkansız hale getirir.

Dahası, Kubernetes’in sağladığı otomatik ölçekleme yetenekleri de Pod’ların dinamikliğini artırır. Yoğun trafik durumlarında uygulamanızın daha fazla Pod’a ihtiyaç duyması, Kubernetes’in yeni Pod’lar oluşturmasına neden olur. Trafik azaldığında ise bu Pod’lar otomatik olarak sonlandırılır. Her bir ölçeklenme işleminde yeni IP adresleri ortaya çıkar veya mevcutlar kaybolur. Bu esnek yapı, Kubernetes’in temel faydalarından biri olsa da, Pod’lara doğrudan IP adresleriyle erişimi güvenilmez kılar. Geleneksel sistemlerde, bir sunucunun IP adresi genellikle sabittir ve bu IP üzerinden uygulamalara erişim sağlanır. Ancak Kubernetes, konteynerlerin soyutlama katmanını bir adım daha ileri götürerek Pod’ları birer hizmet olarak sunma ihtiyacını doğurur. İşte bu noktada, Kubernetes Servisleri, Pod’ların geçiciliği sorununa kalıcı bir çözüm sunarak, dinamik Pod kümelerine stabil ve güvenilir bir erişim noktası sağlama misyonunu üstlenir. Bu sayede, uygulamalar ve kullanıcılar, altta yatan Pod’ların IP adreslerinden ve yaşam döngüsünden izole edilmiş olur.

Kubernetes Servisleri Ne İşe Yarar ve Temel Türleri Nelerdir?

Kubernetes Servisleri, temelde bir grup Pod’a kararlı bir erişim noktası sağlayan soyut bir katmandır. Pod’ların geçiciliği ve IP adreslerinin dinamikliği sorununu çözerek, uygulamaların birbirini bulmasını ve dış dünyaya açılmasını mümkün kılar. Bir Servis, kendisiyle eşleşen Pod’lar arasında trafiği dengeleyebilir, bu sayede uygulamanızın yüksek erişilebilirliğini ve ölçeklenebilirliğini garanti altına alır. Aynı zamanda, Service Discovery (Servis Keşfi) mekanizması aracılığıyla, diğer uygulamalar veya servisler bu Servis’i adıyla çağırabilir ve altta yatan Pod’ların nerede çalıştığıyla ilgilenmek zorunda kalmazlar. Bu, mikroservis mimarilerinin karmaşıklığını önemli ölçüde azaltır.

Kubernetes, farklı erişim ihtiyaçlarını karşılamak üzere çeşitli Servis türleri sunar. Her tür, belirli bir senaryo için optimize edilmiştir ve uygulamanızın ne kadar erişilebilir olması gerektiğine, kimlerin erişeceğine ve hangi ortamda çalıştığına bağlı olarak seçilir. Gelin, bu temel Servis türlerini ve kullanım alanlarını daha yakından inceleyelim:

ClusterIP: Küme İçi İletişim İçin Sabit Nokta

ClusterIP, Kubernetes kümesi içinde çalışan diğer Pod’ların Servis’e erişmesi için kullanılan varsayılan Servis türüdür. Bu tür bir Servis oluşturduğunuzda, Kubernetes küme içinde sadece o Servis’e özgü kalıcı bir sanal IP adresi atar. Bu IP adresi ve port, küme içindeki diğer Pod’lar tarafından uygulamanıza erişmek için kullanılır. ClusterIP Servisleri, dış dünyadan erişilebilir değildir; yalnızca aynı Kubernetes kümesi içinde yer alan bileşenler (örneğin, bir ön uç mikroservisinin bir arka uç mikroservisine erişmesi) için idealdir. Bu sayede iç iletişim tamamen izole edilmiş ve güvenli bir şekilde gerçekleşir. Özellikle mikroservis mimarilerinde, farklı servislerin birbirleriyle güvenli ve tutarlı bir şekilde iletişim kurmasını sağlamak için ClusterIP vazgeçilmezdir.

apiVersion: v1
kind: Service
metadata:
  name: my-backend-service
spec:
  selector:
    app: backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Yukarıdaki örnekte, my-backend-service adlı bir ClusterIP Servisi oluşturuluyor. Bu servis, app: backend etiketine sahip tüm Pod'lara (selector) gelen trafiği, Pod'ların 8080 portuna yönlendiriyor. Servisin küme içindeki erişim portu ise 80 olarak belirlenmiş. Diğer Pod'lar, bu servise my-backend-service:80 üzerinden erişebilirler.

NodePort: Servisleri Küme Dışına Nasıl Açarsınız?

NodePort Servisi, ClusterIP'nin yeteneklerini genişleterek Servis'i Kubernetes kümesi dışına açmanın en basit yollarından biridir. Bu tür bir Servis oluşturduğunuzda, Kubernetes her bir düğümde (Node) belirli bir portu (NodePort) açar ve bu port üzerinden gelen trafiği Servis'e yönlendirir. NodePort, 30000-32767 aralığındaki dinamik olarak atanan bir port numarasını kullanır (ancak manuel olarak da belirleyebilirsiniz). Bu sayede, küme dışından herhangi bir istemci, herhangi bir düğümün IP adresi ve NodePort numarası kombinasyonuyla uygulamanıza erişebilir. Örneğin, uygulamanız node1_ip:nodeport veya node2_ip:nodeport üzerinden erişilebilir hale gelir. NodePort, genellikle geliştirme ortamlarında veya küçük ölçekli, basit dış erişim gerektiren durumlar için kullanılır, çünkü her düğümde belirli bir portun açılması güvenlik ve yönetim açısından bazı kısıtlamalar getirebilir.

apiVersion: v1
kind: Service
metadata:
  name: my-frontend-service
spec:
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30007 # Opsiyonel: Kendi NodePort'unuzu belirleyebilirsiniz
  type: NodePort

Bu örnekte, my-frontend-service adlı bir NodePort Servisi tanımlanıyor. Bu servis, app: frontend etiketine sahip Pod'lara trafiği yönlendirir. Kümedeki her düğümde 30007 numaralı port açılacak ve bu port üzerinden gelen trafik servisin 80 portuna, oradan da Pod'ların 80 portuna iletilecektir.

LoadBalancer: Bulut Ortamlarında Servisleri Dışa Açmanın En İyi Yolu

LoadBalancer Servisi, özellikle bulut sağlayıcılar (AWS, GCP, Azure vb.) üzerinde çalışan Kubernetes kümeleri için tasarlanmış bir Servis türüdür. Bu tür bir Servis oluşturduğunuzda, Kubernetes altyapınızın bulut sağlayıcısıyla entegre olur ve otomatik olarak harici bir yük dengeleyici (Load Balancer) oluşturur. Bu harici yük dengeleyici, uygulamanıza sabit bir harici IP adresi atar ve tüm dış trafiği bu IP adresi üzerinden Servis'e yönlendirir, ardından Servis de trafiği arkasındaki Pod'lar arasında dengeler. LoadBalancer Servisleri, yüksek trafiğe sahip web uygulamaları veya API'ler gibi dış dünyaya sürekli ve kararlı bir erişim sağlaması gereken durumlar için en uygun çözümdür. Bulut sağlayıcının yük dengeleyici yeteneklerinden tam olarak faydalanır; bu da ölçeklenebilirlik, yüksek erişilebilirlik ve genellikle SSL sonlandırma gibi gelişmiş özellikler anlamına gelir.

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Bu örnek, my-web-app adlı bir LoadBalancer Servisi tanımlar. Bu servis, app: web etiketine sahip Pod'lara trafiği yönlendirir ve bulut sağlayıcınızda otomatik olarak harici bir yük dengeleyici oluşturarak uygulamanızın dış dünyaya sabit bir IP üzerinden erişmesini sağlar. Bu, en yaygın ve güvenilir dış erişim yöntemlerinden biridir.

ExternalName: Harici Servisleri Kubernetes İçine Entegre Etme

ExternalName Servisi, diğer Servis türlerinden biraz farklıdır. Bu tür bir Servis, bir etiket seçicisi (selector) kullanarak Pod'lara trafik yönlendirmek yerine, küme içindeki bir Servis adını harici bir DNS adına (CNAME kaydı gibi) eşler. Yani, Kubernetes içinde tanımladığınız bir Servis adı (örneğin, my-external-db), gerçekte küme dışında bulunan bir veritabanı veya başka bir API servisinin DNS adını işaret eder. Bu, küme içinde çalışan uygulamaların, harici servislerle sanki küme içindeymiş gibi tutarlı bir şekilde iletişim kurmasını sağlar. Özellikle, küme dışında yönetilen veritabanları, SaaS çözümleri veya üçüncü taraf API'leri gibi durumlar için ExternalName Servisi, Kubernetes uygulamalarınızın bu harici kaynaklara erişimini basitleştirir ve tek tip bir Servis keşif mekanizması sunar.

apiVersion: v1
kind: Service
metadata:
  name: my-external-db
spec:
  type: ExternalName
  externalName: my-database.example.com

Yukarıdaki YAML, my-external-db adlı bir ExternalName Servisi oluşturur. Küme içinde bu servise yapılan tüm istekler, my-database.example.com adresine yönlendirilir. Uygulamalarınız bu servisi my-external-db adıyla çağırabilir ve harici veritabanına erişim sağlayabilirler, böylece veritabanının gerçek adresini bilmelerine gerek kalmaz. Bu, özellikle hibrit bulut senaryolarında veya mevcut dış altyapıyı Kubernetes'e entegre ederken oldukça kullanışlıdır.

Gerçek Dünya Senaryosu: Mikroservis Uygulaması ve Servis Türleri

Şimdi, öğrendiğimiz Servis türlerini gerçek bir senaryo üzerinde uygulayarak pekiştirelim. Bir e-ticaret uygulamasının temel bileşenlerini ele alalım: bir web arayüzü (frontend), bir ürün katalog servisi (product-catalog), bir sepet servisi (shopping-cart) ve bir ödeme geçidi entegrasyonu. Bu mikroservisler, farklı işlevleri yerine getiriyor ve birbirleriyle veya dış dünyayla farklı şekillerde iletişim kurmaları gerekiyor.

1. Web Arayüzü (Frontend): Kullanıcıların doğrudan erişeceği ana arayüzdür. Bu servisin dış dünyaya sabit bir IP adresi üzerinden açılması ve yük dengelemeye tabi tutulması gerekir.
2. Ürün Katalog Servisi (Product-Catalog): Ürün bilgilerini yönetir ve ön uç tarafından çağrılır. Küme içinde çalıştığı için dışarıdan doğrudan erişime ihtiyacı yoktur.
3. Sepet Servisi (Shopping-Cart): Kullanıcıların sepetindeki ürünleri yönetir ve ön uç ile ürün katalog servisinden bilgi alır. Yine küme içi bir iletişim söz konusudur.
4. Ödeme Geçidi (Payment Gateway): Bu, dışarıda barındırılan, üçüncü taraf bir servis sağlayıcısıdır. Uygulamamızın bu geçide güvenli bir şekilde bağlanması gerekir.

Bu senaryoyu Kubernetes Servisleri ile nasıl hayata geçirebiliriz?

• Web Arayüzü (Frontend) İçin LoadBalancer Servisi:

  Kullanıcıların web arayüzüne internet üzerinden erişebilmesi için en uygun çözüm bir LoadBalancer Servisi'dir. Bulut sağlayıcınız, bu servise sabit bir harici IP adresi atayacak ve gelen trafiği web arayüzü Pod'ları arasında dengeleyecektir. Bu, uygulamanızın yüksek trafik durumlarında bile hızlı ve erişilebilir kalmasını sağlar.

  
  apiVersion: v1
  kind: Service
  metadata:
    name: ecom-frontend
  spec:
    selector:
      app: frontend
    ports:
      - protocol: TCP
        port: 80
        targetPort: 80
    type: LoadBalancer
  

• Ürün Katalog Servisi ve Sepet Servisi İçin ClusterIP Servisleri:

  Ürün Katalog ve Sepet Servisleri, sadece Kubernetes kümesi içindeki diğer servisler (örneğin web arayüzü) tarafından çağrılacaktır. Bu nedenle, dış erişime ihtiyaçları yoktur ve ClusterIP Servisleri onlar için idealdir. Bu sayede, servisler arası iletişim güvenli ve verimli bir şekilde, küme içi sanal IP adresleri üzerinden gerçekleşir. Ön uç, bu servislere ecom-product-catalog ve ecom-shopping-cart adlarıyla erişebilir.

  
  apiVersion: v1
  kind: Service
  metadata:
    name: ecom-product-catalog
  spec:
    selector:
      app: product-catalog
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8080
    type: ClusterIP
  ---
  apiVersion: v1
  kind: Service
  metadata:
    name: ecom-shopping-cart
  spec:
    selector:
      app: shopping-cart
    ports:
      - protocol: TCP
        port: 80
        targetPort: 8081
    type: ClusterIP
  

• Ödeme Geçidi (Payment Gateway) Entegrasyonu İçin ExternalName Servisi:

  Uygulamamızın dışarıdaki bir ödeme geçidine bağlanması gerektiğinde, ExternalName Servisi kullanışlıdır. Bu, ödeme geçidinin DNS adını, Kubernetes içinde bir servis adıyla soyutlamamızı sağlar. Böylece, sepet servisimiz veya ödeme işlemcimiz, ödeme geçidine sanki küme içindeki bir servismiş gibi ecom-payment-gateway adıyla bağlanabilir, gerçek URL'yi doğrudan kullanmak zorunda kalmaz.

  
  apiVersion: v1
  kind: Service
  metadata:
    name: ecom-payment-gateway
  spec:
    type: ExternalName
    externalName: api.paymentgateway.com
  

Bu mimari, her mikroservisin kendine özgü iletişim gereksinimlerini en uygun Servis türüyle karşıladığını gösterir. Web arayüzü LoadBalancer ile dış dünyaya açılırken, iç servisler ClusterIP ile güvenli bir şekilde iletişim kurar ve harici bir entegrasyon ExternalName ile kolayca yönetilir. Bu yaklaşım, karmaşık dağıtılmış sistemlerde ağ yönetimini basitleştirir ve uygulamaların esnekliğini artırır.

Servislerin Ötesinde: Gelişmiş Ağ ve Yük Dengeleme Çözümleri

Kubernetes Servisleri, uygulamalarınız için temel ağ katmanını sağlarken, daha karmaşık trafik yönetimi ve gelişmiş özellikler için ek araçlara ihtiyaç duyabilirsiniz. Özellikle HTTP/S trafiğini daha akıllıca yönlendirme, birden fazla uygulamayı tek bir IP üzerinden sunma veya mikroservisler arası iletişimi daha derinlemesine kontrol etme gibi senaryolarda bu gelişmiş çözümler devreye girer. Kubernetes Servisleri bu yapıların temelini oluşturur, ancak üzerine inşa edilen Ingress ve Servis Mesh gibi kavramlar, modern bulut yerel uygulamalarının ağ altyapısını bir üst seviyeye taşır.

Ingress: HTTP/S Yönlendirmesini Daha Akıllıca Yönetmek

LoadBalancer Servisleri her bir dışa açık uygulama için ayrı bir harici IP ve yük dengeleyici sağlarken, bu durum özellikle çok sayıda HTTP/S tabanlı uygulamanız olduğunda maliyetli ve yönetilmesi zor hale gelebilir. İşte bu noktada Ingress devreye girer. Ingress, HTTP ve HTTPS trafiği için kümenize harici erişim sağlayan bir API nesnesidir ve URL tabanlı yönlendirme, host tabanlı yönlendirme ve SSL sonlandırma gibi gelişmiş yetenekler sunar. Ingress'i kullanmak için bir Ingress Controller'a (örneğin Nginx Ingress Controller, Traefik, HAProxy) ihtiyacınız vardır. Ingress Controller, Ingress kaynaklarını dinler ve gelen trafiği ilgili Kubernetes Servislerine yönlendirmek için kendi yük dengeleyici yapılandırmasını günceller.

Örneğin, my-app.example.com/api adresini bir API servisine, my-app.example.com/web adresini ise bir web servisine yönlendirebilirsiniz. Veya blog.example.com'u blog servisine, shop.example.com'u ise alışveriş servisine yönlendirebilirsiniz. Tüm bunlar tek bir LoadBalancer IP'si üzerinden, maliyetten tasarruf ederek ve yönetimi kolaylaştırarak yapılabilir. Ingress, genellikle üretim ortamlarında, çok sayıda web tabanlı servisin dış dünyaya açılması gerektiğinde tercih edilen yöntemdir.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false" # Nginx Ingress Controller için örnek anotasyon
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: ecom-product-catalog # ClusterIP servisine yönlendirme
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: ecom-frontend # LoadBalancer veya ClusterIP servisine yönlendirme
                port:
                  number: 80

Bu Ingress tanımı, myapp.example.com/api yolundan gelen trafiği ecom-product-catalog servisine, geri kalan tüm trafiği ise ecom-frontend servisine yönlendirir. Bu sayede tek bir dış IP üzerinden birden fazla servis sunulabilir.

Headless Servisler ve Servis Mesh Kavramları

Bazen, Kubernetes'in sağladığı yük dengeleme ve sanal IP adresini istemeyebilirsiniz. Özellikle kendi başına servis keşfi yapması gereken durumlar veya doğrudan Pod IP'lerine erişimin gerektiği senaryolar (örneğin, StatefulSet'lerde çalışan veritabanı kümeleri veya özel ağ proxy'leri) için Headless Servisler kullanılır. Headless Servisler, bir ClusterIP Servisi gibi davranır ancak ona bir küme IP adresi atamaz. Bunun yerine, Servis adı sorgulandığında, Kubernetes DNS sunucusu doğrudan Servis seçicisiyle eşleşen Pod'ların IP adreslerini döndürür. Bu, uygulamanızın kendi yük dengeleme veya servis keşif mantığını uygulamasını sağlar.

apiVersion: v1
kind: Service
metadata:
  name: my-stateful-db
spec:
  selector:
    app: stateful-db
  clusterIP: None # Headless Servis yapar
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306

Öte yandan, mikroservis mimarileri büyüdükçe, servisler arası iletişimde güvenlik, gözlemlenebilirlik (izleme, loglama, metrikler) ve trafik yönetimi (A/B testleri, kanarya dağıtımları) gibi konular daha karmaşık hale gelir. İşte bu noktada Servis Mesh'ler (Istio, Linkerd gibi) devreye girer. Bir Servis Mesh, uygulamanızın kodunda herhangi bir değişiklik yapmadan bu tür ağ yeteneklerini uygulama katmanına taşır. Her Pod'a bir "sidecar" proxy (örneğin Envoy) enjekte eder ve tüm servisler arası trafiği bu proxy'ler üzerinden yönlendirir. Kubernetes Servisleri, Servis Mesh'in temelini oluşturur; mesh, Pod'ların ve Servislerin kimliklerini ve adreslerini kullanarak gelişmiş politikaları uygulayabilir. Bu, mikroservis uygulamalarını daha sağlam, yönetilebilir ve güvenli hale getirir.

Bu gelişmiş çözümler, Kubernetes Servislerinin sağladığı temel ağ katmanını tamamlayarak, modern bulut yerel uygulamaları için güçlü ve esnek bir altyapı sunar. Her biri, belirli bir ihtiyaca yönelik olarak tasarlanmıştır ve birlikte kullanıldığında, karmaşık dağıtılmış sistemlerin ağ yönetimini önemli ölçüde basitleştirir.

Mobil Uyumluluk ve Performans İpuçları

Kubernetes Servisleri genellikle arka plandaki altyapı bileşenleri olsa da, Kubernetes'i yönetmek için kullanılan arayüzler (örneğin Kubernetes Dashboard veya özel CLI araçlarının web tabanlı sürümleri) ve hatta uygulamanızın kendisi mobil uyumlu olmalıdır. Günümüzde kullanıcıların büyük bir kısmı mobil cihazlar üzerinden erişim sağladığından, responsive tasarım ve performans optimizasyonları vazgeçilmezdir. Ayrıca, Servislerin kendileri için de performans ve verimlilik artırıcı bazı ipuçları bulunmaktadır.

# Mobil Uyumluluk İçin CSS Yaklaşımı

Eğer uygulamanızın veya yönetim panelinizin bir web arayüzü varsa, mobil cihazlarda iyi görünmesini sağlamak için CSS medya sorgularını kullanmak önemlidir. Bu, farklı ekran boyutlarına ve çözünürlüklerine göre stil kurallarını uygulamanıza olanak tanır. Aşağıda basit bir medya sorgusu örneği verilmiştir:

/* Genel stiller - masaüstü için optimize edilmiştir */
body {
  font-size: 16px;
  margin: 20px;
}

.container {
  width: 960px;
  margin: 0 auto;
}

/* 768px'den küçük ekranlar (tablet ve mobil) için stiller */
@media (max-width: 768px) {
  body {
    font-size: 14px;
    margin: 10px;
  }

  .container {
    width: 100%; /* Konteyneri tam genişliğe getir */
    padding: 0 15px; /* Yanlardan boşluk bırak */
  }

  /* Örneğin, bir tabloyu mobil cihazlarda kaydırılabilir yapmak */
  table {
    display: block;
    overflow-x: auto;
    white-space: nowrap;
  }
}

/* 480px'den küçük ekranlar (sadece mobil) için daha spesifik stiller */
@media (max-width: 480px) {
  h2 {
    font-size: 1.5em;
  }
  img {
    max-width: 100%;
    height: auto;
  }
}

Bu CSS kod bloğu, ekran boyutu küçüldükçe sayfanın düzenini, yazı tipi boyutlarını ve diğer görsel elementleri otomatik olarak ayarlar. Özellikle veri tabloları gibi geniş içeriği olan bileşenler için overflow-x: auto; kullanımı, mobil cihazlarda kullanıcı deneyimini önemli ölçüde iyileştirebilir.

# Servis Performansı ve Optimizasyon İpuçları

Kubernetes Servislerinizin performansını ve verimliliğini artırmak için dikkate almanız gereken bazı noktalar bulunmaktadır:

1. Doğru Servis Türünü Seçmek: Her Servis türü belirli bir senaryo için optimize edilmiştir. İç iletişim için ClusterIP, dışarıya açılan ancak HTTP/S yönlendirme gerektirmeyen basit uygulamalar için NodePort, bulut ortamında dış erişim için LoadBalancer ve gelişmiş HTTP/S yönlendirme için Ingress'i tercih etmek, gereksiz kaynak kullanımını önler ve performansı artırır.
2. Servis Seçicilerini (Selectors) Optimize Etmek: Servis seçicilerinizin (selector) doğru ve spesifik olduğundan emin olun. Yanlış veya çok geniş seçiciler, trafiği istenmeyen Pod'lara yönlendirebilir veya Servis'in doğru Pod'ları bulmasını yavaşlatabilir. Etiketlerinizi tutarlı ve anlamlı bir şekilde kullanın.
3. sessionAffinity Kullanımı: Eğer uygulamanızın bir kullanıcının tüm isteklerinin aynı Pod'a gitmesini gerektiren oturum bağımlılığı varsa, Servis tanımınızda sessionAffinity: ClientIP ayarını kullanabilirsiniz. Bu, aynı kaynak IP adresinden gelen tüm bağlantıların aynı Pod'a yönlendirilmesini sağlar. Ancak, bu durum Pod'lar arasında yük dağılımını dengesizleştirebilir, bu yüzden yalnızca ihtiyaç duyulduğunda kullanılmalıdır.

spec:
  selector:
    app: my-sticky-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800 # 3 saat (varsayılan 10800 saniye)

4. externalTrafficPolicy: Local Kullanımı (NodePort/LoadBalancer): NodePort ve LoadBalancer Servislerinde varsayılan externalTrafficPolicy değeri Cluster'dır, bu da gelen trafiğin herhangi bir Pod'a yönlendirilebileceği anlamına gelir, hatta farklı bir düğümdeki Pod'a bile. Bu, ek bir ağ hop'u (atlama) ve dolayısıyla gecikme yaratabilir. externalTrafficPolicy: Local ayarı, trafiğin yalnızca isteğin geldiği düğümdeki Pod'lara yönlendirilmesini sağlar. Bu, kaynak IP'nin korunmasına yardımcı olur ve ağ gecikmesini azaltır, ancak yük dengelemenin bazı durumlarda dengesiz olmasına neden olabilir.

spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer
  externalTrafficPolicy: Local

5. Gereksiz Yere LoadBalancer Kullanmaktan Kaçınmak: Her LoadBalancer Servisi, bulut sağlayıcınızda ek bir kaynak ve maliyet demektir. HTTP/S trafiği için birden fazla servisi dışarıya açmanız gerekiyorsa, her biri için ayrı bir LoadBalancer yerine, tek bir Ingress Controller (LoadBalancer tipi bir Servis olarak) arkasında birden fazla Ingress kaynağı kullanmak daha verimlidir.
6. DNS Çözümleme Optimizasyonu: Uygulamanızın Servis adlarını hızlı bir şekilde çözümleyebildiğinden emin olun. Kubernetes'in yerel DNS (CoreDNS) çözümlemesi oldukça hızlıdır, ancak ağ gecikmeleri veya yoğun DNS sorguları gibi durumlarda, Servis IP'lerinin önbelleğe alınması gibi ek optimizasyonlar düşünebilirsiniz.

Bu ipuçları, Kubernetes servislerinizin sadece işlevsel değil, aynı zamanda yüksek performanslı ve maliyet etkin olmasını sağlamanıza yardımcı olacaktır. Ağ yapılandırmanızı düzenli olarak gözden geçirmek ve uygulamanızın gerçek dünya performansını izlemek de büyük önem taşır.

Sonuç: Kubernetes Servislerinin Temel Taşı Olarak Rolü

Kubernetes servisleri, modern bulut yerel uygulama mimarilerinin temel taşlarından biridir. Pod'ların dinamik ve geçici doğasına rağmen, uygulamaların birbirini güvenilir bir şekilde bulmasını ve dış dünyaya kararlı bir şekilde açılmasını sağlayarak Kubernetes'in gücünü ve esnekliğini ortaya koyar. ClusterIP ile küme içi mikroservisler arası güvenli ve etkili iletişimi mümkün kılarken, NodePort ve LoadBalancer ile dış dünyaya erişim kapılarını aralar. ExternalName, harici sistemlerle entegrasyonu basitleştirirken, Ingress gibi daha gelişmiş çözümler HTTP/S tabanlı trafiği akıllıca yönetme ve maliyetleri optimize etme imkanı sunar. Ayrıca, Headless servisler ve servis mesh kavramları, daha özel ve karmaşık ağ ihtiyaçlarına cevap vererek Kubernetes ekosisteminin zenginliğini artırır.

Bu makalede ele aldığımız tüm bu kavramlar, Kubernetes'in sadece konteynerleri çalıştırmakla kalmayıp, aynı zamanda onları bir bütün olarak yönetilebilir, ölçeklenebilir ve yüksek erişilebilir bir uygulama platformuna dönüştürdüğünü açıkça göstermektedir. Geliştiriciler ve operasyon ekipleri, doğru servis türünü seçerek ve ağ yapılandırmalarını optimize ederek, uygulamalarının performansını ve güvenliğini artırabilirler. Kubernetes'te servisleri anlamak, bu platformun sunduğu potansiyeli tam olarak kullanmanın ilk ve en önemli adımıdır. Unutmayın, iyi tasarlanmış bir servis mimarisi, uygulamanızın gelecekteki büyümesine ve değişimine uyum sağlamasına olanak tanır.

Sıkça Sorulan Sorular (SSS)

1. Bir Pod'a doğrudan IP adresiyle erişmek neden iyi bir fikir değil?

   Pod'lar geçicidir; IP adresleri değişebilir, Pod'lar yeniden başlatılabilir veya ölçeklenebilir. Doğrudan IP adresiyle erişim, bağlantı sorunlarına ve uygulamanın kararsız çalışmasına neden olur. Kubernetes Servisleri, bu dinamik Pod IP'leri üzerinde kararlı bir soyutlama katmanı sağlayarak bu sorunu çözer.

2. NodePort ve LoadBalancer arasındaki temel fark nedir?

   NodePort, Kubernetes kümesindeki her bir düğümde (Node) belirli bir portu açarak servisi dışarıya açar. Her düğümün IP adresi ve NodePort üzerinden erişim sağlanır. LoadBalancer ise, bulut sağlayıcınız tarafından otomatik olarak sağlanan harici bir yük dengeleyiciyi tetikler ve bu yük dengeleyiciye sabit bir harici IP adresi atanır. LoadBalancer, genellikle üretim ortamlarında daha sağlam ve esnek bir çözümdür, NodePort ise daha çok geliştirme ve test için kullanılır.

3. Ingress, LoadBalancer'ın yerini mi alır?

   Tamamen yerini almaz, ancak birbirini tamamlarlar. Ingress, HTTP/S seviyesinde daha akıllı yönlendirme (URL tabanlı, host tabanlı) sağlarken, LoadBalancer genellikle Ingress Controller'ın kendisini dış dünyaya açmak için kullanılır. Yani, birden fazla Ingress kaynağı tek bir LoadBalancer Servisi'nin arkasında çalışabilir, bu da maliyet ve yönetim açısından avantaj sağlar.

4. Headless Servisleri ne zaman kullanmalıyım?

   Headless Servisleri, Kubernetes'in dahili yük dengelemesini veya sanal IP'sini istemediğiniz durumlarda kullanmalısınız. Özellikle StatefulSet'ler ile çalışan veritabanı kümeleri (örn. Kafka, Cassandra, MySQL kümesi) gibi her Pod'un kendi başına servis keşfi yapması veya benzersiz bir ağ kimliğine sahip olması gereken durumlarda idealdir. DNS sorguları doğrudan Pod IP'lerini döndürür.

5. Servis Mesh varken Kubernetes Servislerine hala ihtiyacım var mı?

   Evet, kesinlikle ihtiyacınız var. Servis Mesh (örneğin Istio), Kubernetes Servislerinin üzerine inşa edilen bir katmandır. Servis Mesh, Pod'lar ve Servisler arasında gelişmiş trafik yönetimi, güvenlik, gözlemlenebilirlik gibi özellikleri sağlarken, Kubernetes Servisleri yine de uygulamanızın Pod'larına kararlı erişim noktaları sağlamanın ve servis keşfinin temelini oluşturur. Servis Mesh, bu temel yapı üzerinden çalışır ve onu zenginleştirir.