Masterin ang Service Mesh Architecture gamit ang Istio
1. Panimula
Tuklasin ang mahika ng service mesh architecture at kung paano nito pinapalakas ang iyong distributed systems.
Lubos na alamin ang Istio, ang superstar ng service mesh, at kung paano nito ipinapaloob ang iyong Kubernetes cluster sa pagiging perpekto.
2. Ano ang Service Mesh?
Ang mga monolithic applications ay naging mas maliliit at independent na serbisyo. Ang pagbabagong ito ay sumikat kasabay ng cloud-native computing at microservices architecture. Ang mga tool tulad ng Docker at Kubernetes ang nagsilbing pabilis ng trend na ito.
Ang mga microservices sa mga platform tulad ng Kubernetes ay nagbibigay ng maraming benepisyo, ngunit nagpapakilala din ng mga komplikasyon. Ang pamamahala sa komunikasyon ng mga serbisyong ito ay nangangailangan ng masusing pag-aaral ng discovery, routing, retries, at failover.
Bukod pa rito, may mga hamon sa seguridad at observability.
Ang pagtatayo ng communication capabilities sa bawat serbisyo ay nakakaubos ng oras, lalo na habang lumalaki ang dami ng mga serbisyo. Dito papasok ang service mesh. Pinangangasiwaan nito ang lahat ng komunikasyon sa pagitan ng mga serbisyo sa loob ng distributed system.
Ginagawa ito ng service mesh sa pamamagitan ng paggamit ng network proxies. Ang mga request sa pagitan ng mga serbisyo ay dumadaan sa mga proxy na nakaposisyon sa infrastructure layer.
Ang mga proxies na ito ay bumubuo ng isang mesh network para sa mga serbisyo, kaya't tinawag itong service mesh. Kinokontrol ng service mesh ang bawat aspeto ng komunikasyon ng serbisyo-serbisyo, pinapayagan nito ang pagresolba sa walong fallacies ng distributed computing.
3. Superpowers ng Service Mesh
I-unleash ang buong potensyal ng iyong mga serbisyo gamit ang isang service mesh! Tuklasin kung paano binabago ng kahanga-hangang tool na ito ang iyong application landscape.
Suriin natin ang mga core na abilidad nito: traffic wizardry, bakal na seguridad, at kristal na kalinawan ng visibility.
3.1. Traffic Wizardry
Ang isang service mesh ay ang ultimate na traffic cop, pinangangasiwaan nito ang mga interaksyon ng serbisyo nang may katumpakan. Makinabang sa dynamic na routing, matalinong discovery, at mga kamangha-manghang feature tulad ng traffic shadowing at splitting para sa seamless na canary releases at A/B testing experiments.
Ipaalam sa unreliable na koneksyon ang pamamaalam! Pinapabalutan ng service mesh ang iyong mga serbisyo ng matatag na kaligtasan, na may retries, timeouts, rate limiting, at circuit breakers upang maprotektahan ang iyong mga app mula sa kaguluhan.
3.2. Bakal na Seguridad
Bantayan ang iyong mga serbisyo gamit ang isang hindi masusupil na kuta! Ang service mesh ay nagpapakilala ng encryption sa lahat ng komunikasyon gamit ang matatag na MTLS, sinusuri ang pagkakakilanlan gamit ang mahigpit na authentication, at nagpapatupad ng access rules para sa pinakamataas na proteksyon.
Tuklasin ang mga nakatagong kapangyarihan ng seguridad! I-isolate ang mga serbisyo, subaybayan ang bawat kilos para sa auditing, at bumuo ng isang ligtas na perimeter sa paligid ng iyong application gamit ang isang service mesh.
3.3. Kristal na Kalinawan ng Visibility
Gamitin ang service mesh upang mas madaling mag-navigate sa mga kumplikasyon ng iyong distributed system! Ang service mesh ay nagbibigay ng walang katulad na visibility sa mga proseso ng iyong aplikasyon sa pamamagitan ng distributed tracing.
Tuklasin ang mahahalagang insights gamit ang mga metrics, logs, at performance data. I-optimize ang iyong mga serbisyo at ayusin ang mga isyu nang tulad ng isang eksperto gamit ang isang service mesh.
4. Pagbubunyag ng Istio
Ang Istio, isang open-source service mesh mula sa IBM, Google, at Lyft, ay lihim na nagpapahusay sa mga distributed na applications gamit ang traffic management, seguridad, at performance insights.
Nae-deploy nang flexible on-premise, sa cloud, sa loob ng Kubernetes, o sa mga virtual machines, ang Istio ay makintab sa microservices sa Kubernetes. Kahit na platform-agnostic ito, natural itong kasang-ayon sa containerized environments.
Sa core nito, ang Istio ay nagde-deploy ng mga Envoy proxies bilang mga sidecar na kasama ng bawat microservice.
Ang proxy network na ito ang bumubuo sa data plane ng Istio, na pinangangasiwaan ng control plane:
Ang control plane, ang utak ng Istio, ay nagbibigay kapangyarihan sa Envoy proxies gamit ang discovery, configuration, at certificate management.
I-unleash ang potensyal ng Istio gamit ang maraming interconnected na microservices, kung saan ang mga sidecar proxies ay bumubuo ng isang matibay na service mesh infrastructure.
Ang adaptability ng Istio ay nagniningning sa seamless integration nito sa mga external logging, telemetry, at policy systems.
5. Paghimay sa mga Building Blocks ng Istio
Ang architecture ng Istio ay binubuo ng dalawang makapangyarihang bahagi: ang data plane at ang control plane. Sama-sama silang nagpapatakbo ng mahika sa likod ng mga kakayahan ng Istio. Tuklasin natin ang mga core components na nagpapatakbo sa kamangha-manghang platform na ito.
Maghanda upang alamin ang mga detalyadong bahagi ng core components ng Istio.
5.1. Ang Data Plane: Sentro ng Envoy
Ang data plane ng Istio ay isang amplified na bersyon ng Envoy proxy. Ang open-source na marvel na ito ay humahawak sa mga intricacies ng network, pinapalaya ang mga application upang makapag-focus sa kanilang core na negosyo. Ang mga application ay nag-iinteract nang seamless, hindi alam ang komplikadong network infrastructure.
Sa core nito, ang Envoy ay isang network wizard na nagpapatakbo sa layers 3 at 4 ng OSI model. Madali nitong pinamamahalaan ang mga koneksyon gamit ang isang chain ng adaptable network filters. Bukod pa rito, ang L7 layer filter ng Envoy ay nagbibigay-daan upang matapang nitong hawakan ang HTTP traffic. At higit pa roon - ito'y natural sa HTTP/2 at gRPC protocols.
Maraming standout features ng Istio ay mga superpowers na namana mula sa built-in abilities ng Envoy.
- Traffic Control: Ang Envoy ay may granular control sa HTTP, gRPC, WebSocket, at TCP traffic, na idinidirekta ito nang may katumpakan.
- Network Resiliency: Automatic retries, circuit breaking, at fault injection na built-in upang masiguro ang walang humpay na reliability ng network.
- Seguridad: Protektahan ang iyong komunikasyon gamit ang mga matibay na security policies, access control, at rate limiting.
Ang tunay na potensyal ng Envoy ay lumalabas kapag pinagsama sa Istio. Ang extensibility nito, na pinapatakbo ng WebAssembly, ay game-changer para sa custom policy enforcement at telemetry. Bukod pa rito, binubuksan ng Proxy-Wasm sandbox API ng Istio ang pintuan sa mas marami pang customizations para sa Envoy.
5.2. Ang Control Plane: Maestro ng Istiod
Kilalanin si istiod, ang conductor ng orchestra ng Istio control plane. Ang maestro na ito ay nagpapalit ng high-level routing rules at traffic management directives sa Envoy-friendly configurations, ipinapamahagi ito nang seamless sa mga sidecars.
Tandaan ang mas lumang architecture ng Istio na may kanya-kanyang components? Upang gawing simple, ang mga component na ito ay pinagsama sa unified na istiod. Ngunit huwag mag-alala, intact pa rin ang mga core functionalities.
Sa core nito, ang istiod ay gumagamit ng parehong code at APIs tulad ng mga nauna nito. Ang Pilot, halimbawa, ay nananatiling maestro ng service discovery, na isinasalin ang platform-specific details sa universal na wika na nauunawaan ng mga sidecars. Ang flexibility na ito ay nagbibigay-daan sa Istio na makipag-harmonize sa iba't ibang environment tulad ng Kubernetes at Virtual Machines.
Ang istiod ay namamahala din sa seguridad, itinatatag ang malalakas na service-to-service at end-user authentication gamit ang built-in na identity at credential management system nito. Madaling ipatupad ang granular na security policies batay sa service identity. Bukod pa rito, ang istiod ay nagsisilbing trusted Certificate Authority (CA), nag-iisyu ng certificates upang protektahan ang komunikasyon sa pagitan ng mga serbisyo gamit ang mutual TLS (MTLS).
6. Paano Gumagana ang Istio
Tinalakay na natin ang mga tipikal na features ng isang service mesh at inisa-isa ang architecture at core components ng Istio. Ngayon, tuklasin natin kung paano naihahatid ng Istio ang mga feature na ito gamit ang mga core components nito.
Babalikan natin ang mga kategorya ng features na tinalakay natin kanina.
6.1. Traffic Management
Ang traffic management API ng Istio ay nagbibigay ng granular na kontrol sa traffic sa service mesh. I-configure ang traffic gamit ang APIs at tukuyin ang API resources gamit ang Kubernetes custom resource definitions (CRDs). Ang mga pangunahing API resources para sa traffic routing ay ang virtual services at destination rules.
Ang isang virtual service ay nagtatalaga kung paano ipapasa ang mga request sa isang serbisyo sa loob ng Istio mesh. Binubuo ito ng isa o higit pang routing rules na sinusuri nang sunod-sunod. Pagkatapos ng virtual service routing, ang destination rules ay ipinapatupad upang kontrolin ang traffic sa isang destinasyon, tulad ng paghahati ng mga instance ng serbisyo ayon sa bersyon.
6.2. Seguridad
Ang pundasyon ng seguridad ng Istio ay ang malalakas na pagkakakilanlan para sa bawat serbisyo. Ang mga Istio agents na kasama ng bawat Envoy proxy ay nakikipagtulungan sa istiod upang i-automate ang key at certificate rotation.
Signing RequestSigned
Certificate
Ang Istio ay sumusuporta sa dalawang uri ng authentication: peer authentication at request authentication. Ang peer authentication ay nagseseguro ng service-to-service communication gamit ang mutual TLS solution ng Istio. Ang request authentication ay humahawak ng end-user authentication sa pamamagitan ng JSON Web Token (JWT) validation gamit ang isang custom na authentication provider o OpenID Connect (OIDC) provider.
Ipinapatupad ng Istio ang service access control sa pamamagitan ng authorization policies. Ang mga policy na ito ay kinokontrol ang inbound traffic sa Envoy proxy, nagbibigay-daan para sa kontrol ng access sa mesh, namespace, at service levels.
6.3. Observability
Ang Istio ay bumubuo ng komprehensibong telemetry, kabilang ang metrics, distributed traces, at access logs, para sa lahat ng service communication sa loob ng mesh. Ang telemetry na ito ay sumasaklaw sa proxy-level, service-oriented, at control plane metrics.
Noong una, ang Mixer ang sentral na component sa telemetry architecture ng Istio. Gayunpaman, ang Telemetry v2 ay pumalit sa mga feature ng Mixer gamit ang Envoy proxy plugins.
Service-level metrics
Service-level metrics
Ang Istio ay lumilikha ng distributed traces sa pamamagitan ng Envoy proxies at sumusuporta sa iba't ibang tracing backends tulad ng Zipkin, Jaeger, Lightstep, at Datadog. Ang trace generation sampling rate ay maaring i-configure. Bukod pa rito, ang Istio ay bumubuo ng access logs para sa service traffic sa customizable na formats.
7. Sumisid sa Istio
Tama na ang background, silipin natin ang Istio sa aksyon! Mag-install tayo ng Istio sa isang Kubernetes cluster at gagamit ng isang simpleng microservices app para ipakita ang kapangyarihan nito.
7.1 Pag-install
Maraming paraan para i-install ang Istio, ngunit ang pinakamadali ay i-download at i-extract ang pinakabagong release para sa iyong operating system (tulad ng Windows). Kasama sa na-extract na package ang istioctl client sa bin folder. Gamitin ang istioctl para i-install ang Istio sa iyong Kubernetes cluster.
istioctl install --set profile=demo -yIni-install nito ang mga components ng Istio sa default na Kubernetes cluster gamit ang demo profile. Palitan ang 'demo' ng isa pang vendor-specific profile kung kinakailangan.
Sunod, sabihin sa Istio na awtomatikong mag-inject ng Envoy sidecar proxies kapag nagde-deploy ng mga app sa Kubernetes cluster na ito.
kubectl label namespace default istio-injection=enabledGinagamit natin dito ang kubectl, na nangangahulugang mayroon ka nang Kubernetes cluster (tulad ng Minikube) at na-set up na ang Kubernetes CLI kubectl.
7.2 Sample Application
Isipin ang isang simpleng online ordering app para sa demo na ito. Binubuo ito ng tatlong microservices na nagtutulungan upang mag-fulfill ng orders.
Hindi natin tatalakayin ang mga detalye ng microservices, ngunit madali itong gawin gamit ang Spring Boot at REST APIs. Importante, gumawa ng Docker images para sa mga microservices na ito upang mai-deploy sa Kubernetes.
7.3 Deployment
Ang pag-deploy ng mga containerized na workloads sa mga Kubernetes clusters tulad ng Minikube ay simple. Gumamit ng Deployment at Service resources para ideklara at ma-access ang workload. Karaniwang tinutukoy ito sa isang YAML file.
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: order-service
namespace: default
spec:
replicas: 1
template:
metadata:
labels:
app: order-service
version: v1
spec:
containers:
- name: order-service
image: kchandrakant/order-service:v1
resources:
requests:
cpu: 0.1
memory: 200
---
apiVersion: v1
kind: Service
metadata:
name: order-service
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
name: http
selector:
app: order-serviceIto ay isang basic Deployment at Service definition para sa order-service. Gumawa ng katulad na YAML files para sa inventory-service at shipping-service.
Madali mong i-deploy ang mga resources na ito gamit ang kubectl.
kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yamlDahil enabled na ang auto-injection ng Envoy sidecar proxies para sa default namespace, lahat ay nakaayos na. O kaya, manu-manong i-inject ang Envoy sidecar proxies gamit ang kube-inject command ng istioctl.
7.4 Pag-access sa Aplikasyon
Ang pangunahing role ng Istio ay ang pamamahala sa mesh traffic. Karaniwan, ang traffic papasok o palabas ng mesh ay blocked. Ginagamit ng Istio ang gateways upang pamahalaan ang inbound at outbound traffic, na nagbibigay ng precise na control sa kung ano ang pumapasok o umaalis. Ang Istio ay may preconfigured na gateway proxy deployments: istio-ingressgateway at istio-egressgateway.
Gumawa ng Gateway at Virtual Service para sa iyong app.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: booking-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: booking
spec:
hosts:
- "*"
gateways:
- booking-gateway
http:
- match:
- uri:
prefix: /api/v1/booking
route:
- destination:
host: booking-service
port:
number: 8080Ginagamit natin dito ang default na Istio ingress controller. Bukod pa rito, nagtukoy tayo ng isang virtual service para mag-route ng requests sa booking-service.
Pwede ka ring mag-set ng egress gateway para sa outbound traffic ng mesh.
8 Mga Karaniwang Use Cases ng Istio
Na-deploy na natin ang isang simpleng app sa Kubernetes gamit ang Istio. Tuklasin natin ang mga powerful features ng Istio at tingnan kung paano nito mapapahusay ang ating aplikasyon.
8.1 Request Routing
Isipin ang pag-deploy ng maraming bersyon ng isang microservice tulad ng shipping-service. Gusto mong dahan-dahang ipakilala ang mga bagong features nang hindi naapektuhan ang lahat ng users. Pinapayagan ka ng request routing na gawin ito sa pamamagitan ng pagdirekta ng bahagi ng traffic sa pinakabagong bersyon.
Gamitin ang mga routing rules ng virtual service para makamit ito.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: shipping-service
spec:
hosts:
- shipping-service
http:
- route:
- destination:
host: shipping-service
subset: v1
weight: 90
- destination:
host: shipping-service
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: shipping-service
spec:
host: shipping-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2Ang mga routing rules ay pwede ring magsala ng traffic batay sa headers o iba pang attributes. Ang destination field ang nagtutukoy ng target na serbisyo para sa mga tumutugmang requests.
8.2 Circuit Breaking
Iwasan ang cascading failures gamit ang circuit breakers. Ang pattern na ito ay nakakatukoy ng mga error at pansamantalang humihinto ng traffic papunta sa mga nagfifail na serbisyo, pinoprotektahan ang kalusugan ng buong aplikasyon.
Pinapayagan ka ng DestinationRule ng Istio na i-configure ang circuit breaking behavior para sa mga serbisyo tulad ng inventory-service.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: inventory-service
spec:
host: inventory-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
maxRequestsPerConnection: 1
outlierDetection:
consecutive5xxErrors: 1
interval: 1s
baseEjectionTime: 3m
maxEjectionPercent: 100Sa pamamagitan ng paglimit ng maximum connections, pending requests, at requests per connection, maari mong epektibong pamahalaan ang traffic at maiwasan ang overload.
8.3 Pag-enable ng Mutual TLS
Ang mutual TLS ay nagbibigay ng seguridad sa komunikasyon sa pagitan ng mga serbisyo sa pamamagitan ng pag-require sa parehong partido na mag-authenticate. Awtomatikong ina-enable ng Istio ang mutual TLS para sa mga serbisyo gamit ang proxies nito.
Habang ipinapatupad ng Istio ang mutual TLS sa pagitan ng proxied services, ang plain-text traffic ay maaari pa ring makarating sa mga serbisyo na walang proxies. Gamitin ang PeerAuthentication policies para ipatupad ang mutual TLS sa buong mesh.
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICTMaari mong ipatupad ang mutual TLS sa mesh, namespace, o service level. Ang mga service-specific policies ay nag-ooverride sa namespace-wide settings.
8.4 Pagkontrol ng Access gamit ang JWT
Ang JSON Web Tokens (JWT) ay isang standard para sa ligtas na pagpapadala ng user information. Karaniwan itong ginagamit para sa authentication at authorization.
Pinapayagan ka ng AuthorizationPolicy ng Istio na kontrolin ang access sa mga serbisyo tulad ng booking-service batay sa JWT claims.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt
namespace: default
spec:
selector:
matchLabels:
app: booking-service
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["[email protected]/[email protected]"]I-require ang valid JWTs na may specific claims para sa authorized access. Ang Istio ay lumilikha ng isang requestPrincipal attribute mula sa JWT's issuer at subject claims.
9. Pangwakas na Kaisipan
Pinapadali ng Istio ang pamamahala sa mga karaniwang hamon sa distributed microservice architectures. Gayunpaman, ang komplikasyon nito ay maaaring magdagdag ng overhead sa mga deployments. Tulad ng anumang tool, ang Istio ay hindi isang magic solution at nangangailangan ng maingat na pagsasaalang-alang.
9.1. Kailangan ba Palagi ang Service Mesh?
Habang nag-aalok ng mga benepisyo ang mga service mesh, isaalang-alang ang mga drawbacks na ito:
- Ang mga service mesh ay nagdadagdag ng overhead sa pamamagitan ng pamamahala ng lahat ng service-to-service communication. Maaari itong hindi kinakailangan para sa mas simpleng mga aplikasyon.
- Kung pinapamahalaan mo na ang mga concern tulad ng circuit breaking sa application code, ang paggamit ng service mesh ay maaaring humantong sa dobleng trabaho.
- Ang labis na pagtitiwala sa isang service mesh ay maaaring makahadlang sa portability ng aplikasyon dahil sa kakulangan ng industry standards.
- Ang mga proxies ng service mesh ay maaaring magdagdag ng latency sa mga request.
- Ang mga service mesh ay nangangailangan ng expertise para pamahalaan ang kanilang kumplikadong mga components at configurations.
- Ang paghahalo ng operational logic (ideal para sa mga service meshes) sa business logic (na dapat manatili sa labas) ay maaaring maging problema.
Nag-aalok ng mga benepisyo ang mga service mesh, ngunit ang maingat na pagsusuri sa pagiging kumplikado ng iyong aplikasyon ay mahalaga. Timbangin ang mga benepisyo laban sa idinagdag na komplikasyon.
9.2. Mga Alternatibo sa Istio
Ang Istio ay isang popular na service mesh na sinusuportahan ng mga industry leaders, ngunit hindi ito ang tanging opsyon. Narito ang isang maikling overview ng Linkerd at Consul.
Linkerd ay isang Kubernetes-native, open-source na service mesh na nakakuha ng kasikatan. Isa itong CNCF incubating project at gumagana nang katulad sa Istio, gamit ang TCP proxies. Ang Rust-based micro-proxy ng Linkerd ay tinatawag na Linkerd-proxy.
Ang Linkerd ay karaniwang mas simple kaysa sa Istio dahil sa Kubernetes focus nito. Gayunpaman, ang feature set nito ay halos kahawig ng Istio, at ang core architecture nito ay katulad. Ang Linkerd ay binubuo ng isang user interface, data plane, at control plane.
Consul ay isang open-source service mesh mula sa HashiCorp na umaangkop sa iba pang HashiCorp infrastructure tools. Sinusuportahan ng data plane ng Consul ang parehong proxy at native integration models. Mayroon itong built-in na proxy ngunit maaaring gumana rin kasama ang Envoy.
Ang Consul ay gumagana nang higit pa sa Kubernetes, sinusuportahan nito ang mga platform tulad ng Nomad. Gumagamit ito ng mga agents sa bawat node para sa health checks at nakikipag-ugnayan sa mga Consul servers para sa data storage at replication. Habang nag-aalok ng mga standard service mesh features, ang Consul ay mas kumplikado sa pag-deploy at pamahalaan.
10. Pagwawakas
Ang tutorial na ito ay tinalakay ang mga pangunahing kaalaman ng service mesh architecture at ang mga kapangyarihan ng Istio. Inisa-isa natin ang core structure, components, at praktikal na aplikasyon ng Istio. Sa huli, dapat ay mayroon ka nang solidong pag-unawa kung paano i-install at gamitin ang Istio para sa mga karaniwang senaryo.
Pagsusuri ng Kustomer
Ang mga sumusunod na pagsusuri ay nakolekta sa aming website.
May Mga Katanungan? Hanapin ang mga Sagot Dito!
Ang Aming Pinaka-Madalas Itanong
© Copyright 2022-2024 Standupcode