Mikroservis mimarisinin hayatımıza girmesiyle birlikte büyük çaplı uygulamaların yönetiminde bazı problemler ortaya çıkmaya başladı. Bu problemlerin küçük uygulamalarda izlenebilirlik kolaylığı sebebiyle çözümü çok fazla efor istemese de büyük ve çok sayıda mikroservisten oluşan uygulamalarda izlenebilirlik zor olduğu için çok fazla efor istemektedir. Örnek olarak 80 mikroservisten oluşan bir uygulamamızdaki trafiğin nasıl aktığını ve eğer bu trafikte bir kayıp olursa bunun hangi iki servis arasında yaşandığını çözümlemek oldukça zor olacaktır. Tam olarak bu noktada bizlere önemli bir çözüm sunan service mesh, uygulamamızdaki mikroservislerin yanında bir sidecar proxy olarak çalışarak trafiği üstlenir ve izlenebilirliği arttırır. Service mesh sayesinde bütün trafiği izleyebilir, trafiği yönetebilir, trafik yönetme sayesinde blue-green deployment yapabilir ve mikroservisler arasındaki trafiği virtual TLS ile şifreleyebiliriz.
Kubernetes'in kendisi bu gibi durumlar için bizlere bir çözüm sağlamamakta anca biz daha sonrasından cluster bazında tüm trafiğimizi kontrol etmek ve yönetmek için farklı araçları cluster üzerine entegre ederek kullanabiliriz.
Özetle service mesh bizlere aşağıdaki konularda çözümler sunar:
- Routing & Load Balancing
- Canary Deployment
- Dağıtılmış izleme yoluyla gözlemlenebilirlik
- mutual Transport Level Security (mTLS)
- "Service-to-Service" trafiği loglarına erişim
Linkerd, service mesh teknolojisinde bizlere çözüm sunan bir araçtır. CNCF tarafından yönetilmektedir. Çalışma prensibi olarak Linkerd bir API kurmaktadır ve bütün komponentler bu API ile haberleşir. Ek olarak linkerd dahsboard ve CLI da bu API ile haberleşerek bizler için gerekli bilgileri sağlar. Linkerd genel olarak iki ana başlıktaki yapıya bölünmektedir. Bunlardan ilki linkerd'nin çalışmasında core görevi gören Control Plane'dir. Diğeri ise uygulamalarımızın yanında sidecar proxy olarak çalışan Data Plane dir.
Ek olarak linkerd ve Istio OSI Reference Model Layer 7(Application) çalışır. HTTP veya GRPC protokolleri kullanır.
Bu katmanda üç adet araç bulunur. Bunlar "destination", "identity" ve "proxy-injector" dür.
Destination: Görevi A servisi ile B servisi arasındaki trafiği yöntemek veya sonrasında trafiğin nereye gideceğini belirlemektir. Genel olarak trafiğin yönlendirilmesinden sorumludur.
Identity: Virtual TLS altyapısını sağlayabilmek için gerekli sertifikaları podlara inject eder. Yeni bir servis oluşuturup bu servisi linkerd altına aldığımızda da bu servisin sertifika işlemleri Identity tarafından sağlanır.
Proxy-Injector: Çalışan bir cluster için öncelikle servislerimizin yanlarına sidecar olarak linkerd proxy kurmamız gerekmektedir. Proxy-injector ise burada bu sidecar proxylerin kurulumu ve yönetiminden sorumludur.
Bu katman linkerd'nin uygulama tarafında çalışan kısmıdır. İçerisinde linkerd aracı olarak sadece sidecar proxy bulunur. Her servise entegre olarak bu sayede bütün trafiği üstlenir ve izleyip yönetmemize olanak sağlar.
Data Plane uygulamamıza infrastructure seviyesinde dahil olur.
Anlaşılması ve basitliği sebebiyle Linkerd üzerinden bir kurulum gerçekleştirip ardından bir tane de örnek uygulama kurarak uygulama özelindeki trafiği inceleyeceğiz.
Ön Gereksinimler:
- Docker Desktop (İsteğe Bağlı)
- Kubernetes Cluster
- Lens (İsteğe Bağlı)
Bu aşamada k8s clusterı docker desktop ile ayağa kaldırdık. Farklı bir ortamdaki cluster da kullanılabilir. Ek olarak Lens uygulamasını ile cluster bilgilerini görüntülemek için kullandık. kubectl cli kullanılarak da gerekli kontroller sağlanabilir.
kubectl version --short
Öncelikle bu komut ile mevcut clustera erişimimiz olup olmadığının kontrolünü sağlıyoruz.
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
Bu komutu shell üzerinde çalıştırarak bilgisayarımıza linkerd cli kurulumunu yapıyoruz. Ardından
export PATH=$PATH:/home/nadi/.linkerd2/bin
linkerd version
sırasıyla komutları çalıştırarak kurulumun gerçekleştiğini doğruluyoruz.
linkerd check --pre
Bu adımda clusterımız için linkerd gereksinimlerinin kontrollerini sağlıyoruz. Eğer bir sorun ile karşılaşılmazsa komut sonucunda 'Status check results are ok' şeklinde bir çıktı alıyoruz.
linkerd install | kubectl apply -f -
Buradaki "linkerd install" komutu control plane için gerekli manifest dosyalarını oluşturur. Sonrasında ise "kubectl apply -f -" ile ilgili dosyalar cluster içerisine kurulur.
linkerd check
Control plane kurulumu aşamasında bir hata ile karşılaşılmadı ve control plane clustera doğru bir şekilde kurulduysa komut sonucunda "Status check results are ok" şeklinde bir çıktı alıyoruz.
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/emojivoto.yml | kubectl apply -f -
Bu adımda emojivoto isimli ve içerisinde hata bulunan bir uygulamayı deploy ediyoruz. İçerisindeki hata bilinçi olarak oluşturulmuş, uygulamada trafik kaybına neden olan bir hatadır.
NOT: Linkerd şu anda uygulamaya inject:syringe: edilmemiştir, yani çalışmamaktadır.
kubectl -n emojivoto port-forward svc/web-svc 8080:80
Kubernetes port-forward ile uygulamamızın web servisine http://localhost:8080 adresinden erişim sağlayalım. Uygulamamız basit bir şekilde emoji oylama uygulamasıdır. Açılan ekranda rastgele oylama yaparak uygulamayı kontrol edebiliriz. Donut emojisine tıkladığımızda hata aldığımızı görüntüleyeceksiniz. Bu kısım uygulamanın bilinçli olarak hatalı oluşturulan kısmıdır.
NOT: Linkerd şu anda hala uygulamaya inject:syringe: edilmemiştir, yani çalışmamaktadır.
kubectl get -n emojivoto deploy -o yaml | linkerd inject - | kubectl apply -f -
Bu komut satırında sırası ile "emojivoto" namespace içerisindeki deployment objelerinin yaml dosyalarını alıyoruz. Ardından linkerd inject komutu ile uygulamamıza linkerd data plane ekliyoruz, yani uygulamıza linkerd ekliyoruz. Son olarak ise aynı dosyaları tekrar deploy ediyoruz.
linkerd -n emojivoto check --proxy
Bu aşamada oluşturduğumuz data plane çalışıyor mu kontrolünü sağlıyoruz. Eğer bir hata ile karşılaşılmamış ise sonucunca "Status check results are ok" çıktısını elde ediyoruz.
linkerd viz install | kubectl apply -f -
Sırası ile bu komutumuzda viz eklentisinin gerekli manifest dosyalarını oluşturup ardından clustera deploy ediyoruz.
NOT: Viz eklentisi beraberinde monitoring için prometheus ve grafana da kuruyor. Bu nedenle mevcut prometheus kurulumunuz var ise çakışma veya başka bir problem olmaması için kaldırmanız gerekiyor.
linkerd check
Bu komut ile yüklediğimiz eklenti çalışıyor mu ve eklenti kurulduktan sonra linkerd komponentleri düzgün çalışıyor mu bunların kontrollerini sağlıyoruz. Eğer bir hata ile karşılaşılmamış ise sonucunca "Status check results are ok" çıktısını elde ediyoruz.
linkerd viz dashboard &
Komutu bizleri http://localhost:50750 adresine yönlendiriyor ve karşımıza linkerd dahboard ekranı geliyor. Ek olarak grafa üzerinde oluşturulmuş default dasboard için http://localhost:50750/grafana bağlantısını kullanabiliriz.
Dört mikroservisten oluşan uygulamamızdaki "Voting" servisi içersinde donut APİ hatalı olduğu için bu kısımda bağlantı kaybı oluşmaktadır. Bu kayıp üstteki resimde başarı oranı altında gözlenmektedir. Aynı zamanda web servisi ile arasındaki trafiği de bozduğu için web servisinde de bağlantı kaybı görüntülenmesine neden olmaktadır.