Kubernetes API Yönetimi için Kong & Local Kubernetes Ortamında Kurulum

Bu makalede Kubernetes ekosisteminde adını sıkça duyduğumuz Kong’u daha yakından tanıyacak ve bir deneyim fırsatı oluşturmak için onu local Kubernetes ortamımıza uygulayacağız.

“APIs run everything. Kong runs APIs.”

Şimdi biraz Kong’dan bahsedelim.

Kong API yönetimi sağlamak için oluşturulmuş bir üründür. Kubernetes ortamında uygulamalarımız var ve bunlar arasındaki iletişimi regüle etmek istiyorsak Kong karşımıza çıkan ilk seçeneklerden biri olacaktır. Kong ile API Gateway, Traffic Routing, Authentication, Security, Monitoring, Load Balancing gibi birçok farklı alanda çalışmalar sağlanabilir.

Kaynak: https://github.com/Kong/kong

Peki neden Kong’u tercih etmeliyiz?

Kong Client’ler ile servislerimiz arasında birçok fonksiyonu da yanında getirerek konumlanır. Kong’un sağladığı özellikler ile servislerimizin gereksinimlerine göre birçok farklı senaryo oluşturulabilecektir.

Kong bir açık kaynak projedir. Buna ek olarak geniş bir topluluk desteği mevcuttur. Bu sayede değişimlere hızlı adapte olabilecektir. Kong’un plugin sistemi ile Kong’a birçok farklı eklenti eklenebilir ve Kong ihtiyaçlar doğrultusunda özelleştirilebilir. Pluginler Kong’un zengin olanaklarının geldiği noktadır.

Bunlara bazı örnekler verelim:

Traffic Routing: En başta tahmin edeceğimiz bir durum olarak HTTP & path tabanlı yönlendirme ile servisler ile bağlantı sağlanabilir. Deploymentlar esnasında Canary Deployment yolu izlenebilir. Buna ek olarak farklı stratejilerin uygulanması amacıyla dağıtım farklı oranlarda farklı servislere yönlendirilebilir. (Örneğin /products yoluna gelen isteklerin %35’i product-service-1 servisine ve %65’i product-service-2 servisine yönlendirilsin)

Authentication Çözümleri: Erişim sağlanması esnasında Basic Authentication, OAuth2, JWT, ACL, LDAP gibi metotlar uygulanabilir.

Logging: Kong’un Log tutma özelliğinin var olduğundan bahsetmek oldukça önemli. API trafiği hakkında istek, yanıt, hata gibi olaylar Kong’da kayıt altına alınır. Bu sayede ortamımızın günlük akışı esnasında neler olduğu daima kayıtlı olacaktır.

Monitoring: API trafiği takip edilebilir, gecikmeler-yanıt süreleri gözlemlenebilir. Hangi istemcilerden hangi API’lere yönelim olduğu analiz edilebilir. Monitoring ile elde edilecek çıkarımlardan hata oranları azaltılabilir ve ek olarak daha iyi ölçeklenmiş bir sistem elde edilebilir.

Rate Limiting: API’nin zaman dilimleri içerisinde istekler üzerinde sınırlandırmalar yapılabilir. Kötü niyetli fazla trafik oluşturulması veya API aşırı yüklenmesinin engellenmesi sağlanabilir. Limiting istemci bazlı, IP adresi bazlı, Route bazlı(örn. /products route için saniyede 50 istek), API Key bazlı, Oluşturulmuş gruplar üzerinden grup bazlı, Coğrafi bölge bazlı gibi farklı noktalara bakılarak yapılabilir.

Security: CORS ile yetkilendirilmemiş kaynakları engelleme, SSL/TLS, Request-Response Transformation ile istek-yanıtlar üzerinde hassas verileri gizlemek veya değiştirmek vb. gibi çeşitli güvenlik özellikleri sağlamaktadır.

Caching: Sık kullanılan ve değişmeyen verileri cacheleyerek direkt hafızadan veya veritabanından sağlar bu sayede sunucu üzerinde yük azaltılabilir.

Bunlar ve bunlara benzer daha birçok sebepten dolayı Kong sıklıkla tercih edilmektedir. Esnek yapısı ile farklı gereksinimler bulunduran sistemlere adapte olabilmektedir.

Local Kubernetes Ortamında Kurulum

Local Kubernetes olarak single node bir minikube kurulumu yapacağız.

Kurulum için aşağıdaki adres takip edilebilir. Kurulum hızlıdır ve sisteminize dayanarak farklı opsiyonlara göre yöntemler açıklanmıştır.

https://minikube.sigs.k8s.io/docs/start/

Windows için Docker Desktop kurulu olmalı. Ek olarak ben genellikle Chocolatey üzerinden kurulumu tercih ediyorum. 2–3 komutla Chocolatey’i kurduktan sonra minikube kurulum adresinden Chocolatey ile kurulumu tek komutla sağlayabilirsiniz.

Chocolatey için kurulum: https://chocolatey.org/install

Kong Kurulumu

İlk olarak bir yaml ile Kong kurulumunu gerçekleştiriyoruz.

kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/master/deploy/single/all-in-one-dbless.yaml

Kurulum sonrası kontrol için:

kubectl get pods –n kong

kubectl get pods –n kong

komutu sonrası bizi 1 ingress ve 2 proxy podu olmak üzere 3 pod karşılamalı.

Şimdi bir de serviceleri kontrol edelim:

kubectl get svc –A

kubectl get svc –A

Kong service’imiz External-IP’e sahip değil. Takdir edersiniz ki bu durum yukarıda bahsettiklerimize uygun değil. Kong clienti External-IP ile karşılamalıdır.

Bu esnada minikube tunnel ile LoadBalancer’ımıza erişim sağlayacağız. Kong privileged portlara erişim istiyor, bu sayede o kısmı da çözmüş olacağız. Bunun için yönetici olarak çalıştırdığımız ayrı bir PowerShell penceresinde minikube tunnel komutunu çalıştırıyoruz. O pencere arkada açık kalmalı, kapatmayalım.

minikube tunnel

minikube tunnel — Bu pencere arkada açık kalmalı, kapatmayalım.

Ardından tekrar kontrol için kubectl’i kullanmış olduğumuz PowerShell’e dönüyor ve tekrar kontrol sağlıyoruz:

kubectl get svc –A

kubectl get svc –A

External-IP’yi gözlemleyebiliyoruz. Localhostumuza da bakıp Kong’un durumunu inceleyelim.

localhost

Gördüğümüz üzere Kong artık dış dünyaya açık vaziyette.

Şimdi demo için bazı uygulamalara ihtiyaç duyuyoruz. Bunun için örnek bir uygulama çalıştıralım. GitHub üzerinden Kong demo uygulamalarının bulunduğu repoyu localimize çekelim ve ilgili klasöre gidelim. Komutları sırasıyla uygulayalım.

git clone https://github.com/Kong/demo-scene.git

cd demo-scene/kong-builders/01-19-2022

Şimdi repodaki uygulamayı k8s üzerinde şu komutla çalıştıralım.

kubectl apply –f usage.yaml

Şimdi kontrol sağlayalım:

kubectl get svc –A 

kubectl get svc –A

2 yeni servisimizi gözlemleyebilmekteyiz: bar-service ve foo-service. Bir external-IP’leri yok. Dışarıdan gelen client bu servislere erişmek isteyecektir. İşte sizin de tahmin edeceğiniz üzere bunun için önlerine Kong’u konumlandıracağız.

Az önce “apply” yapmış olduğumuz usage.yaml’ında Ingress tanımını incelersek:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  #ingressClassName: kong
  rules:
  - http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: foo-service
            port:
              number: 5678
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: bar-service
            port:
              number: 5678

Burada foo ve bar path’lerimizin belirlenmiş olduğunu göreceğiz. Yalnız orada ingressClassName: kong comment edilmiş. Bu bizim için problem oluşturmakta, onu düzeltmeliyiz.

Peki neden?

Ingress’leri inceleyelim:

kubectl get ingress

kubectl get ingress

Class’ın “none” olduğunu görüyoruz. Kong class’ına atanmadığı için Kong bu ingress’i almamakta. Buna dikkat edelim.

Bu kısmı düzeltelim, komutu çalıştıralım ve açılan textbookta ilgili kısmı düzeltelim ve spec altına ingressClassName: kong ekleyelim.

kubectl edit ingress example-ingress

Açılan yaml’da spec altına ingressClassName olarak kong ekliyoruz.

Tekrar kontrol edelim:

kubectl get ingress

Class’ın değişmiş durumda ve “kong” olduğunu görüyoruz.

Artık her şey hazır.

localhost/foo ve localhost/bar adreslerine gidelim ve çıktıları inceleyelim.

localhost/foo & localhost/bar

Bu noktada Kong aracılığıyla Kubernetes üzerindeki 2 service’e erişmiş olduk.

Bu kısımdan sonra pluginler ile servislerinize erişim noktasında farklı yöntemler ekleyebilirsiniz. Örneğin Rate Limiting, Authentication, Request-Response Transformation gibi birçok farklı yol izlenebilir.

Bunun için Kong dokümanını takip edebilirsiniz.

Okuduğunuz için teşekkürler, umarım fayda sağlamıştır 😊.