Cncf meetup-service-mesh-sk

SERVICE
MESH
Trendy v oblasti mikro
služieb
Ladislav Horváth

Tech. manažér v Accenture
Zameranie:
• Projektový manažment a
dodanie softwéru
• Architektúra
• Devops
Projektový tech. manažér s viac
ako 10 ročnou praxou v obore
vývoja softvéru a riadenia IT 20-
30 členných teamov.
Aktuálne sa angažuje v oblasti
digital decoupling, ktorá súvisí s
architektúrou mikro služieb.
Súčasťou role je návrh a
príprava riešenia, plánovanie a
monitoring implementácie.
Technické zázemie v oblasti
návrhu a vývoja MIS a CRM s
aplikáciou monolitickej
architektúry aj decouping
aplikácii s využitím prístupu
event-driven mikro služieb.
Certifikovaný Avanade Scrum
Project Manager, PRINCE 2
Foundation
PoA: Orchestrácia
mikroslužieb pre banku
Návrh a riadenie vývoja
prototypu za účelom
identifikácie vhodného
orchestračného komponentu.
Vernostná platforma pre
oblasť leteckých spoločností
Postupné odpájanie mainframe a
nahrádzanie jeho funkcionality
novou platformou na báze
domain driven design a event-
driven mikro služieb.
B2B cestovný portál
Implementácia nového B2B
produktu ako služby s podporou
multitenancy pre schvaľovanie
nákupu leteniek, hotelov a iných
služieb týkajúcich sa služobných
ciest.
Platforma Digital Decoupling
Návrh a príprava architektúry,
plánu na dodávku, skladby
teamu, rozbeh a riadenie
projektu
Riadenie platformy,
zabezpečenie teamov
vyškolených a skúsených v
oblasti event-driven mikro
služieb.
Copyright © 2020 Accenture. All rights reserved. 2
LADISLAV
HORVÁTH

1
2
3
4
5
Architektúra mikro služieb
Stručné porovnanie s monolitom
Projektové výzvy
Skladba teamu, krátky čas na dodanie, technické
požiadavky
Service mesh
Definícia, architektúra, funkcionalita
Demo
Traffic manažment, zabezpečenie mikro služieb
Otázky a odpovede

MIKRO SLUŽBY
ARCHITEKTÚRA

ARCHITEKTÚRA
DEMO: MIKRO SLUŽBY
Microservice
CustomerCustomer
Microservice
PreferencePreference
Microservice
Recommendatio
n v1
Recommendatio
n v1
Microservice
Recommendatio
n v2
Recommendatio
n v2
API Gateway / Proxy
http
http
http
IAM
Metrics
Dashboard
* https://redhat-developer-demos.github.io/istio-tutorial/istio-tutorial/1.3.x/index.html

PROJEKTOVÉ
VÝZVY

Ako riadiť premávku? Akú
gateway/proxy použiť?
Ak je požiadavka na canary
alebo green/blue
nasadzovanie, ako nastaviť
gateway?
Validácia JWT tokenu. Je
potreba validovať pre každé
volanie a každého klienta?
Kam umiestniť konfiguráciu
alebo implementáciu čo
najefektívnejšie?
Ak bude konfigurácia
súčasťou kontajnerov, ako
zabezpečiť nasadenie
zmeny?
Autorizačné pravidlá (RBAC)
je náročné implementovať,
ak je požiadavka vyhnúť sa
hard-kódu.
Ako implementovať load
balancing medzi službami?
Zahrnúť do služieb kód pre
circuit breaker, retries on
failure alebo timeout?
Ako zabezpečiť perzistenciu
stavu pre circuit breaker pre
rovnaké služby v rámci
rôznych kubernetes podov?
Ako zbierať telemetriu a
zobrazovať ich na
dashboarde? Je potreba
použiť napr. java
dependenciu alebo knižnicu
pre zber metrík pre každú
službu?
Ako nastaviť nástroje pre
zber, agregovanie a
zobrazovanie metrík?
OPERAČNÉ OBLASTI, KTORÉ
VÝVOJOVÝ TEAM MUSÍ
PRIPRAVIŤ
KONTROLA PREMÁVKY MONITORING ODOLNOSŤ SLUŽIEB ZABEZPEČENIE

8Copyright © 2020 Accenture. All rights reserved.
SKLADBA TEAMU
Existujú buď programátori
alebo ops ľudia. Kombinácia je
veľmi zriedkavá, každá oblasť
vyžaduje istú mieru
špecializácie.
Väčšina preferuje vývoj pred
ops zadaním  nedostatok
skúsených ops administrátorov
na trhu.
Team je obvykle zložený z 1-2
ops, zvyšok sú programátori.
Vývoj na zelenej lúke formou
tzv. Minimum Viable Product
trvá priemerne 5-6 mesiacov.
Obvykle kapacita pre
operations je alokovaná na
prípravu rôznych test prostredí
a CI/CD. Problém je, že nástroje
pre monitoring a správu musia
byť pripravené v rovnaký čas
ako samotné riešenie.
Iba sieť mikro služieb tvorí
funkčný celok s hodnotou pre
klienta. Ich závislosti môžu
narásť behom pár mesiacov,
čím rastie komplexnosť celého
riešenia.
Dôsledkom je fakt, že team
viac času venuje implementácii
biznis požiadaviek ako kladeniu
základov pre prevádzku
systému.
KOMPLEXITA KRÁTKY ČAS NA DODANIE
FAKTORY, KTORÉ MÔŽU MAŤ
VPLYV NA VOĽBU SERVICE
MESHU

SERVICE MESH

DEFINÍCIA
HTTPS://DZONE.COM/ARTICLES/WHAT-
IS-A-SERVICE-MESH-AND-WHY-DO-
YOU-NEED-ONE
“IS AN UMBRELLA TERM FOR
PRODUCTS THAT SEEK TO
SOLVE THE PROBLEMS THAT
MICROSERVICES'
ARCHITECTURES CREATE.
THESE CHALLENGES INCLUDE
SECURITY, NETWORK TRAFFIC
CONTROL, AND APPLICATION
TELEMETRY”

„data plane“ pozostáva zo sady Envoy proxín, ktoré
sú nasadené ako „sajdkári“. Sprostredkovávajú a
kontrolujú komunikáciu medzi mikro službami. Tiež
zbierajú a reportujú telemetriu o premávke v meshi.
„control plane“ riadi a konfiguruje proxiny na
smerovanie premávky.
ARCHITEKTÚRA
ISTIO
* https://istio.io/docs/ops/deployment/architecture/

• Load balancing
• TLS termination
• HTTP/2 and gRPC proxies
• Circuit breakers
• Health checks
• Staged rollouts with %-
based traffic split
• Fault injection
• Rich metrics
12Copyright © 2020 Accenture. All rights reserved.
Vyvinutá v jazyku C++. Sprostredkováva vstupno-
výstupnú premávku pre všetky služby v service meshi.
Nasadená formou „sajdkáry“ v tom istom kubernetes pode
ako samotná mikroslužba, čím ju obohacuje o mnoho
funkcionalít (viď zoznam vpravo).
Umožňuje Istiu extrahovať množstvo signálov o premávke
ako atribúty (napr. obsah http header), ktoré je možné
použiť v rámci konfigurácie alebo ako informáciu v
monitoring nástrojoch (Grafana, Kiali).
ENVOY
PROXY

PILOT
Konvertuje konfiguráciu z Istio CRD yaml definície pre
kontrolu premávky na konfiguráciu špecifickú pre Envoy a
propaguje ju na všetky sajdkáry bez prerušenia behu
aplikácie.
ROUTING PRÍKLAD
50% všetkých requestov na verziu 1 služby a 50% na
verziu 2.

PRÍKLAD
Zabezpečuje autentizáciu konečných uživateľov
použitím OAuth2 s validáciou JWT tokenu a
komunikáciu medzi službami navzájom.
CITADEL

Istio umožňuje pripojiť mikro
službu v meshi na databázu
mimo meshu, ktorá môže
napr. bežať v kubernetes
pode.
V prípade MySQL je ale
potreba workaround z
dôvodu bugu v Istiu. Jediná
možnosť ktorá fungovala,
bolo mTLS pripojenie.
Istio dokáže monitorovať a
kontrolovať premávku pre
viacero prostredí pod
rovnakým clusterom v
rôznych kubernetes
namespaceoch. Je ale nutné
konfigurovať zvlášť ingress
gateway pre každé
prostredie.
Istio umožňuje autorizáciu na
základe atribútov v JWT
tokene resp HTTP hlavičke. V
prípade špecifických
požiadaviek autorizácie na
základe hodnôt v databáze
mikro služby bola nutnosť
skombinovať Istio autorizáciu
na vyššej úrovni s
implementáciou v službe.
Konfigurácia RBAC pre rôzne
endpointy nepodporuje
regex.
Istio validuje aj atribút Issuer.
V prípade lokálneho IAM
nástroja, Keycloak, bol Issuer
rozdielny podľa toho, či bol
token vystavený cez url
obsahujúcu public hostname
alebo kubernetes FQDN.
Spôsob konfigurácie
viacerých JWT providerov
pod jedným meshom nie je
dokumentovaný.
PRVÁ SKÚSENOSŤ S
KONFIGURÁCIOU
KONEKTIVITA NA DB JWT VALIDÁCIA AUTORIZÁCIA
1 CLUSTER VIAC
PROSTREDÍ

DEMO

Kubernetes
Pod
ARCHITECTURE
ISTIO DEMO
Microservice
CustomerCustomer
Microservice
PreferencePreference
Istio ingress gateway
http
http
http
IAM
Keycloak
Metrics
Prometheu
s
Dashboard
Grafana
Kiali
Envoy
Pod
Envoy Microservice
Recommendatio
n v1
Recommendatio
n v1
Pod
Envoy
Pod
Envoy
Recommnedation
v2
* https://redhat-developer-demos.github.io/istio-tutorial/istio-tutorial/1.3.x/index.html

OTÁZKY
ODPOVEDE

POUŽITÉ ZDROJE
https://istio.io/docs/ops/deployment/architecture/
https://redhat-developer-demos.github.io/istio-tutorial/istio
-tutorial/1.3.x/index.html
https://dzone.com/articles/what-is-a-service-mesh-and-wh
y-do-you-need-one

Cncf meetup-service-mesh-sk

More Related Content

Similar to Cncf meetup-service-mesh-sk

More from Juraj Hantak

Cncf meetup-service-mesh-sk