Background
L7 Proxy Service Mesh Controller intends to provide connectivity, shape the traffic, apply policies, RBAC and provide
mutual TLS for applications/microservices running across clusters (with service mesh), within the cluster
and with external applications. The functionalities are subjected to the usage of underlying service mesh technology.
Design Overview
Traffic Controller Design Internals
NOTE - Current implementation will support the ISTIO service mesh technology and SD-WAN load balancer. The plugin architecture of the controller makes it extensible to work with any Service mesh technology and any external load balancer as well. It is also designed to configure and communicate with external DNS servers.
JIRA
API
RESTful North API (with examples)
Inter Micro-service communication intents
Considering microservice replication across multiple locations with replication within each cluster. - Testing Scenarios - HTTP Applications
Intent
URL: /v2/project/{project-name}/rb/{rb-name}/{version}/intent/{intent-name}/connectivity/servicerecord/{servicerecord-name}/ POST BODY: { "intent-name": "test-connectivity", "servicerecord-name": "test-servicerecord", "description": "connectivity intent for microservice replication across multiple locations and clusters" "connectivityResource": [ { "microservice01": "egressgateway": "true", // All the outbound traffic from this service will flow through a dedicated egress gateway "externalPrefix": "httpservice", // This is the prefix used to expose this service outside the cluster. "mutualTLS": "true" [{ "targetServiceName": "httpbin", "type": "kubernetes" "serviceMesh": "istio" "protocol": "HTTP", "port" : "80", "loadbalancing": "true", "traffic percentage" : "33", "egress" : "true", // Setting this to true will create a dedicated egrees gateway for the service httpbin on whichever cluster it is running on }, { "targetServiceName": "sleep", "type": "kubernetes" "serviceMesh": "istio" "protocol": "HTTP", "port" : "80", // "loadbalancing": "true", "traffic percentage" : "34", "egress" : "false", // Setting this to true will create a dedicated egrees gateway for the service sleep on whichever cluster it is running on }, { "targetServiceName": "johndoe.com", "type": "externalservice" "serviceMesh": "" "protocol": "HTTP", "port" : "80", // "loadbalancing": "true", "traffic percentage" : "33", "egress" : "false" // This has to be false as a service external to a k8s cluster/service mesh will not be handled by administrator }] }, { "microservice02": [ { "targetServiceName": "edition.cnn.com", "type": "externalService" "serviceMesh": "" "protocol": "HTTPS", "port" : "443", // "loadbalancing": "false", "traffic percentage" : "", "egress" : "false", // Setting this to true will create a dedicated egrees gateway for the service httpbin on whichever cluster it is running on }, { "targetServiceName": "sleep", "type": "kubernetes" "serviceMesh": "istio" "protocol": "HTTP", "port" : "80", // "loadbalancing": "false", "traffic percentage" : "", "egress" : "false", // Setting this to true will create a dedicated egrees gateway for the service sleep on whichever cluster it is running on }] } RETURN STATUS: 201 RETURN BODY: { "intent-name": "test-connectivity", "description": "connectivity intent for microservice replication across multiple locations and clusters" }
Considering instantiation of the same application multiple times in multiple logical clouds that span across the same edge locations. - The investigation is in Progress
Considering instantiation of the same application multiple times in the same logical cloud - Testing Scenarios - HTTP Applications
Considering RBAC/ABAC - TBD
External application communication intents
Considering DNS resolution, No DNS resolution (IP addresses), Egress proxies of the Service Mesh, Third-party egress proxy
User facing communication intents
Considering Multiple DNS Servers
Considering multiple user-facing entities
Considering RBAC/ABAC
Internal Design details
Guidelines that need to kept in mind
- Support for metrics that can be retrieved by Prometheus
- Support for Jaeger distributed tracing by including opentracing libraries around HTTP calls.
- Support for logging that is understood by fluentd
- Mutual exclusion of database operations (keeping internal modules accessing database records simultaneously and also by replication entities of the scheduler micro-service).
- Resilience - ensure that the information returned by controllers is not lost as the synchronization of resources to remote edge clouds can take hours or even days when the edge is not up and running and possibility of restart of scheduler micro service in the meantime.
- Concurrency - Support multiple operations at a time and even synchronizing resources in various edge clouds in parallel.
- Performance - Avoiding file system operations as much as possible.
Modules (Description, internal structures etc..)
....