Fatih Boy

Bir önceki makalemde ile ilk adımı attığımız Kubernetes kavramlarında sizlere pod’lardan bahsetmiştim. Pod’lar için aklınızda tutmanız gereken ilk şeylerden birisi de fani olduklarıdır. Herhangi bir problem kaynaklı olarak ya da kaynak kısıtlarından dolayı her an tahliye edilebilirler. Pod’lar tahliyeleri adından yeniden ayağa kalktıklarında ise farklı bir ip adresi ve hostname atanacaktır. Bu durumda aklınıza pod’lara Cluster dışından stabil olarak nasıl erişebileceğiniz sorusu gelecektir. İşte tam bu noktada sahneye Service kavramı çıkmakta.

Kubernetes Service kavramı pod’ların faniliği karşısında konumlandırılmıştır. Servisler bir ya da daha fazla port’un bir ya da bir grup pod’a yönlendirilmesinden sorumlu bileşenlerdir. Açılan servis portlarına sadece cluster içerisinden erişelebileceği gibi aynı zamanda node üzerinden ya da load balancer üzerinden de erişim sunulabilir. Bu özellikleri sayesinden servisler podların erişim açısından grupladıkları gibi dışarıya açılabilmelerini de sağlamaktadırlar.

Pod’larla kıyaslandıklarında oldukça ucuz kaynak olan servislerden Kubernetes Cluster’ınızda istediğiniz kadar oluşturabilmeniz mümkündür.  Pod’ların faniliğinin aksine, sabit bir ip adresine sahip olan servisler aksi istenmediği sürece kalıcıdırlar. Sahip oldukları yük dengeleme, servis bulunurluğu, sabitlik ve zero down-time özellikleri sayesinde Kubernetes mimarinin önemli taşlarından birisidir. Arkaplanda verilen etiketlere sahip pod’lara erişimi soyutlaşarak hayat herkes için daha yaşanabilir hale gelmektedir

Bir Kubernetes Servisi ClusterIP, NodePort, LoadBalacer ve ExternalName olmak üzere 4 farklı tür olabilir. Seçilen servis türü aynı zamanda servisin erişim ve davranışını da belirlemektedir. Bu türleri ve servis davranışlarını aşağıda bulabilirsiniz;

ClusterIP

ClusterIP türü ile tanımlanan bir Kubernetes Service’i cluster dışından erişilebilir değildir. ClusterIP türü için servise sanal bir cluster ip adresi oluşturularak atanır. Erişimler atanan bu ip adresi üzerinden gerçekleştirilir.

NodePort

NodePort türü ile tanımlanan bir Kubernetes Service’i cluster dışından da erişilebilir olacaktır. Tanımlama sırasında verilen NodePort değeri ile her bir Cluster Node’u üzerinde port açılarak servise yönlendirilir. Bu haliyle, aksi belirtilmediği sürece, herhangi bir node üzerinden servise erişilebilir.

Yukarıda yer alan şema için aşağıdaki yaml dosyası kullanılabilir;

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: enterprisecoding-app
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30006

Yukarıda sıralanan port, nodePort ve targetPort değerlerinden sadece port değeri zorunludur. targetPort değeri belirtilmemiş ise port ile aynı değere sahip olduğu varsayılmaktadır. nodePort değeri belirtilmemiş ise varsayılan olarak 30000-32767 aralığındaki boş bir değer otomatik olarak atanacaktır.

Kubernetes 1.5 itibari ile NodePort olarak tanımlanan Servislerde varsayılan olarak Source NAT uygulamaktadır. Yani talebin yapıldığı node’dan farklı bir node’da yer alan pod’a yönlendirilen hedef paket içerisindeki istemci ip’si talebin yapıldığı node ip’si ile değiştirilmektedir. Bu durumda hedef pod içerisindeki uygulama gerçek istemci ip adresini göremeyecektir.

LoadBalancer

LoadBalancer türü ile tanımlanan bir Kubernetes Service’i aynı NodePort türünde olduğu gibi dışarıdan erişilebilir olacaktır. NodePort’tan farklı olarak LoadBalancer türünde Kubernetes Node’larının önünde önceden konumlanmış yük dengeleyiciler bulunmaktadır. Dışarıdan load balancer’a gelen trafik arkaplandaki pod’lara yönledirilecektir. LoadBalancer türü daha çok bulut tabanlı hizmet sağlayıcılarında görülmekle birlikte MetalLB gibi çözümler sayesinde on-premise sistemlerde de kullanılabilmektedir.

ExternalName

ExternalName türü ile tanımlanan bir Kubernetes Service’i önceki türlerde olduğu gibi selector kullanmak yerine DNS adını kullanacaktır. Bu türde, önceki türlerde olan proxy ya da forward işlemleri kullanılmamaktadır. Yönlendirme işlemi DNS seviyesinde gerçekleşmektedir. Konuyu daha net anlamak için aşağıdaki örneği inceleyelim;

apiVersion: v1
kind: Service
metadata:
  name: test-service
namespace: prod
spec:
  type: ExternalName
  externalName: database.fatihboy.com

Örnekteki service test-service.prod.svc.cluster.local adresi üzerinden yapılan isteklerde DNS servisi CNAME düzeyinde yer alan database.fatihboy.com değerini dönecektir. Bu yanıtı alan istemciler taleplerini bu adrese yapacaklardır.