Service, birbirleri ile entegra çalışacak sistemlerin bir arada tanımlandığı YAML konfigürasyon dosyalarıdır. Kubernetes’teki ile aynı mantıktadır. Service, bir Pod’un IP adresine veya DNS adına güvenmek yerine, farklı uygulamaları veya Pod gruplarını birbirine bağlamaya yardımcı olur.
Service, mikro servis mimarimizin her Pod’u için bir load balancer görevi gördüğünden bir Service kullanılması önerilir. Bu durumda, frontend, bir Service aracılığıyla backend ile konuşur. Backend iletişimi, bir Service aracılığıyla bir veri işleme uygulaması gerçekleştirir. Frontend, uygulamamızı bir Service aracılığıyla tekrar son kullanıcılara sunabilir ve external data store’a erişmemiz gerektiğinde, yine servisler yardımıyla gerçekleştirilir.
Service’ler, diğer bağımlı uygulamaların yapılandırmasını değiştirme konusunda endişelenmenize gerek kalmadan, temeldeki mikro servisleri değiştirme ve re-deployment esnekliği sağlar.
Openshift içindeki her Service, diğer uygulamalardan bağlantı kurmak için kullanılabilecek kendi IP adresini ve DNS kayıtlarını alır.Pod’lar gibi her Service, atanmış bir internal IP adresi alır. Buna Cluster IP’si denir, çünkü cluster içindeki iç iletişim için Service’e atanan ip’dir. Web UI’da, Projeye girip Application –> Services kısmına girdiğinizde görebilirsiniz:
Pod’ları bir Service‘e Selector aracılığıyla bağlarız.
Service’i, simple webapp docker deployment’ı ile oluşturulan tüm Pod’lara bağlamak için selectordeploymentconfig = simple-webapp-docker’ı kullanıyoruz. Ayrıca, Service’te dinlenecek port ve istekleri iletmek için Pod’lardaki target port’u da belirtiyoruz. Yine bunu Web UI’dan görebiliriz.
Şu durumda Service’i yalnızca backend’e bağlamış olduk. Peki dışarından kullanıcılar nasıl erişecek? Kullanıcılar uygulamamıza www.somewebapp.com gibi bir hostname kullanarak erişmek ister. İşte burada Router’lar devreye giriyor. Bir Router, Service’i bir hostname aracılığıyla dış kullanıcılara göstermemize yardımcı olur.
Router’ı, HAProxy veya F5 gibi bir proxy sunucusu olarak düşünün. Router’ları olan Service’ler arasında yük dengelemeyi, güvenliği yapılandırabilir ve trafiği bölebilirsiniz. Router, deployment’taki farklı Pod’lardaki yükü dengelemekten sorumludur. Bunu yapmak için, roundrobin, lessconn ve source gibi farklı yük dengeleme stratejilerine güvenir.
Source, default olarak kullanılan stratejidir. Source stratejisi, uygulamaya erişen kullanıcının IP adresine bakar ve kullanıcının o oturum süresince her zaman aynı back’e ve sunucuya yönlendirilmesini sağlar ve böylece sticky session işlevi sağlar.
İkinci router stratejisi Roundrobin‘dir. Her istek, aynı kullanıcı IP adresinden gelse bile her seferinde ayrı bir backend’e yönlendirilir.
Üçüncü yönlendirme stratejisi Lessconn, trafiği en düşük bağlantı sayısına sahip endpoint’e yönlendirir.
Security bölümü altında, web uygulamasına HTTPS kullanılarak erişilebilmesi için SSL güvenliğini yapılandırabilirsiniz. Ayrıca, insecure traffic bölümü altında, kullanıcıların sitenize HTTP kullanarak erişmesine izin vermek isteyip istemediğinize veya HTTP’ye erişmeye çalıştıklarında kullanıcıyı otomatik olarak sitenin HTTPS sürümüne yönlendirmeyi yapabilirsiniz.
Aynı bölümde sertifikaları ve özel anahtarları da yapılandırabilirsiniz. Router’lar ayrıca, trafiği A / B testi amacıyla iki hizmet arasında bölmemize izin verir. Web UI’daki alternative services bölümü, bu durumda trafiği iki Service arasında böler. Test sonuçlarına göre slider’ı gitmek istediğimiz yönde hareket ettirmek kadar kolaydır.