Gectiğimiz bir bucuk yıldır Cloudflare, uc olmayan lokasyonlarımızda calışan arka uc hizmetlerimizi cıplak metal cozumlerinden ve Mesos Marathon'dan Kubernetes (K8s) kullanarak daha birleşik bir yaklaşıma taşımakta zorlandı . Kubernetes'i sectik cunku monolitik uygulamamızı iletişimin ayrıntılı denetimiyle bircok farklı mikro hizmete bolmemize izin verdi.

Orneğin, Kubernetes'teki bir ReplicaSet , doğru sayıda kapsulun her zaman kullanılabilir olmasını sağlayarak yuksek kullanılabilirlik sağlayabilir. Bir Pod Kubernetes in bir kaba benzer Docker . Her ikisi de gercek uygulamanın calıştırılmasından sorumludur. Bu bolmeler daha sonra , arkasındaki bolmelere yuk dengeleyen tek bir uc nokta sağlayarak coğaltma sayısını soyutlamak icin bir Kubernetes Hizmeti aracılığıyla acığa cıkarılabilir . Hizmetler daha sonra bir Giriş yoluyla İnternete sunulabilir . Son olarak, bir ağ politikası, uygulamaya doğru politikaların uygulanmasını sağlayarak istenmeyen iletişime karşı koruma sağlayabilir. Bu politikalar L3 veya L4 kurallarını icerebilir.

Aşağıdaki şema, bu kurulumun basit bir orneğini gostermektedir.

Kubernetes, iletişim ve trafik yonetimi icin araclar sağlamada mukemmel bir iş cıkarsa da, geliştiricinin bolmelerde calışan uygulamalar arasında iletişim kurmanın en iyi yoluna karar vermesine yardımcı olmaz. Bu blog boyunca, aldığımız kararlardan bazılarına ve bunları yaygın olarak kullanılan iki API mimarisinin, REST ve gRPC'nin artılarını ve eksilerini tartışmak icin neden yaptığımıza bakacağız.