CCP2 CNA Service Mesh
Page content
Service Mesh
Disadvantages of Microservice Architectures
- Overall System is more complex then in a “big” Application
- each component needs to implement a new set of cross cutting concerns
(Network communication, asychronous requests, distributed state, security, …)- large effort to implement seamless and polyglot
- tendency to uniform frameworks (spring, .net, …)
- Coordination of API, Protocol Version, migration, …
- Additional operations overhead (monitorin, logging, debugging, certificate mgmt)
8 common fallacies of distributed computing
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology does not change
- There is one Administrator
- Transport cost is zero
- The network is homogenous
Challanges of microservice Architectures
Network Resilience
- Services can become bottlenecks for other services
- use QoS to limit rogue services
- for efficient control, create policies with allowed calls per service
Security
- in monolithic applications, all function to function calls are secure inside the monolith
- Microservices need authentication, autorizsation, encryption and communication between them
- Use auditing tools to trace service-to-service communication
Observability
- Observability is more important in microservice architecture, in monolithic apps, logfiles are usually sufficient to identify an issue.
- in a microservice architecture, multiple services can span a single request. Latency errors, and failures can happen in any service within the architecture.
- Developers need loggin, network metrics, and distributed tracing and topology to investigate problems and pinpoint their location.
Pros and Cons of Service Meshes
Pros
- Commodity features implemented outside microservice code and are reusable
- solves most problems of microservice architectures (Distributed tracing, logging, security, access control etc.)
- more freedom to select a microservice implementation language. no need to worry about libraries to build network application functions.
Cons
- Adds Complexity: drastically increases the number of runtime instances
- Adds extra hops: all calls have to go through the service mesh sidecar proxy
- only solves a subset of problems: some complex problems, like routing, transormation/type mapping, integrating with other services and systems have to be solved in the business logic
- immature: service mesh technologies are relativly new
LAB
Files
gw-istio.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: microservice-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*" #this should be a proper hostname like: osi.<IP-Address>.nip.io
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: apache
spec:
hosts:
- "*"
gateways:
- microservice-gateway
http:
- match:
- uri:
prefix: /
route:
- destination:
port:
number: 80
host: apache
#host: apache.default.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: order
spec:
hosts:
- "*"
gateways:
- microservice-gateway
http:
- match:
- uri:
prefix: /order/
rewrite:
uri: /
headers:
request:
set:
X-Forwarded-Prefix: /order
route:
- destination:
port:
number: 80
host: order
#host: order.default.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: shipping
spec:
hosts:
- "*"
gateways:
- microservice-gateway
http:
- match:
- uri:
prefix: /shipping/
rewrite:
uri: /
headers:
request:
set:
X-Forwarded-Prefix: /shipping
route:
- destination:
port:
number: 80
host: shipping
#host: shipping.default.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: invoicing
spec:
hosts:
- "*"
gateways:
- microservice-gateway
http:
- match:
- uri:
prefix: /invoicing/
rewrite:
uri: /
headers:
request:
set:
X-Forwarded-Prefix: /invoicing
route:
- destination:
port:
number: 80
host: invoicing
#host: invoicing.default.svc.cluster.local
mesh/fault-injection.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: order-fault
spec:
hosts:
- order.default.svc.cluster.local
http:
- fault:
abort:
httpStatus: 500
percentage:
value: 100
route:
- destination:
host: order.default.svc.cluster.local
mesh/delay-injection.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: order-delay
spec:
hosts:
- order.default.svc.cluster.local
http:
- fault:
delay:
fixedDelay: 7s
percentage:
value: 100
route:
- destination:
host: order.default.svc.cluster.local
mesh/circuit-braker.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: order-circuit-breaker
spec:
host: order.default.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
http2MaxRequests: 1
mesh/circuit-breaker-outlier-detection.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: order-circuit-breaker
spec:
host: order.default.svc.cluster.local
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
http2MaxRequests: 1
outlierDetection:
consecutive5xxErrors: 1
interval: 1m
baseEjectionTime: 3m
maxEjectionPercent: 100
mesh/retry.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: order-retry
spec:
hosts:
- order.default.svc.cluster.local
http:
- retries:
attempts: 20
perTryTimeout: 5s
retryOn: connect-failure,5xx
timeout: 10s
route:
- destination:
host: order.default.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: order
spec:
hosts:
- "*"
gateways:
- microservice-gateway
http:
- match:
- uri:
prefix: /order
rewrite:
uri: /
headers:
request:
set:
X-Forwarded-Prefix: /order
retries:
attempts: 20
perTryTimeout: 5s
retryOn: connect-failure,5xx
timeout: 10s
route:
- destination:
port:
number: 80
host: order
#host: order.default.svc.cluster.local