{"id":2760,"date":"2019-06-27T21:20:16","date_gmt":"2019-06-27T18:20:16","guid":{"rendered":"https:\/\/gokhan-gokalp.com\/?p=2760"},"modified":"2019-06-27T21:20:16","modified_gmt":"2019-06-27T18:20:16","slug":"playing-with-service-mesh-linkerd-ve-azure-kubernetes-service","status":"publish","type":"post","link":"https:\/\/gokhan-gokalp.com\/tr\/playing-with-service-mesh-linkerd-ve-azure-kubernetes-service\/","title":{"rendered":"Playing with Service Mesh – Linkerd ve Azure Kubernetes Service"},"content":{"rendered":"

Bildi\u011fimiz gibi Microsoft<\/em>, bu y\u0131l Barcelona<\/em> KubeCon<\/em>‘da bir \u00e7ok yeniliklerini duyurdu. Bence bunlardan \u00f6nemli bir tanesi ise SMI<\/strong><\/a><\/em>(Service Mesh Interface<\/em>) idi.<\/p>\n

\"\"<\/a><\/p>\n

\u0130nceledi\u011fim kadar\u0131yla SMI<\/em>‘\u0131n tan\u0131m\u0131 i\u00e7in k\u0131saca, t\u0131pk\u0131 AMQP<\/em>‘de oldu\u011fu gibi “interoperability<\/em>” konusunu service mesh’ler aras\u0131nda sa\u011flayabilmek diyebilirim. \u00d6z\u00fcnde service mesh’ler i\u00e7in Kubernetes<\/em> \u00fczerinde standart bir interface sunmaktad\u0131r. B\u00f6ylece service mesh i\u00e7in provider-lock durumuna d\u00fc\u015fmeden, istedi\u011fimiz teknolojiyi kullanabilmemiz i\u00e7in bir olanak, abstraction sa\u011flamaktad\u0131r.<\/p>\n

SMI<\/em>‘\u0131n duyurulmas\u0131n\u0131n ard\u0131ndan, uzun s\u00fcredir incelemek i\u00e7in akl\u0131mda olan Linkerd<\/em><\/a><\/strong> service mesh’i inceleyebilmek i\u00e7in bir f\u0131rsat buldum ve hakk\u0131nda bir \u015feyler yazmak istedim.<\/p>\n

Service Mesh, huh?<\/h2>\n

\u0130lk olarak service mesh nedir ve bize neler sa\u011fl\u0131yor, k\u0131saca de\u011finmek istiyorum.<\/p>\n

Bildi\u011fimiz gibi bir \u00e7ok organizasyon g\u00fcn\u00fcm\u00fcz teknolojisine ve marketine ayak uydurabilmek ve o marketten b\u00fcy\u00fck bir pay alabilmek i\u00e7in, microservice mimarisine ayak uydurmaya, adapte olmaya \u00e7al\u0131\u015f\u0131yor.<\/p>\n

Bu adaptasyon s\u00fcrecinde ise as\u0131l \u00f6nemli olan nokta, birbirlerinden decoupled hale getirilmi\u015f olan servislerin, birbirleriyle nas\u0131l h\u0131zl\u0131<\/strong>, resilient<\/strong> ve secure<\/strong> bir \u015fekilde ileti\u015fim i\u00e7erisinde olacaklar\u0131d\u0131r. Elbette load-balancing<\/em>, traffic management<\/em> ve health monitoring <\/em>de cabas\u0131. Bu gereksinimlerin bir \u00e7o\u011funu, zaten farkl\u0131 tool’lar vas\u0131tas\u0131yla implemente ediyoruz. \u00d6rne\u011fin resiliency konusunu, gerek API<\/em> Gateway’ler, gerekse de Polly<\/em> gibi baz\u0131 framework’ler vas\u0131tas\u0131yla uygulamalar\u0131n i\u00e7erisinde implemente ediyoruz.<\/p>\n

Peki, service mesh ne sunuyor?<\/p>\n

Service mesh ise, service-to-service<\/strong> communication’\u0131n\u0131 manage ederek, “resiliency<\/em>“, “scalability<\/em>“, “security<\/em>” ve “monitoring<\/em>” gibi baz\u0131 kavramlar\u0131 farkl\u0131 \u00e7\u00f6z\u00fcmler ile ele almam\u0131z yerine, bu tarz network i\u015flemlerini kodumuzdan decoupled etmemize olanak sa\u011fl\u0131yor. Ayr\u0131ca bu gereksinimleri bize kendisi tek bir elden sunuyor.<\/p>\n

Peki, Linkerd?<\/h2>\n

Linkerd<\/em>, CNCF<\/strong><\/em> taraf\u0131ndan desteklenen kubernetes<\/em> i\u00e7in open source bir service mesh’dir.<\/p>\n

\u00c7al\u0131\u015fma \u015fekline bakt\u0131\u011f\u0131m\u0131zda ise, transparent bir sidecar proxy<\/strong> instance’\u0131 olarak her bir servis’in yan\u0131nda konumland\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz. A servis’inden B servisini direkt olarak \u00e7a\u011f\u0131rmak yerine, B servis’inin local proxy’sini \u00e7a\u011f\u0131rarak, buradaki “service-to-service” communication complexitiy’lerini bizim i\u00e7in encapsulate etmektedir.<\/p>\n

Genel hatlar\u0131yla Linkerd’nin baz\u0131 key \u00f6zellikleri:<\/strong><\/p>\n

\"\"<\/a><\/p>\n