Interfaces
This section defines the Go Interfaces needed for the development of the OSM in this repository.
This section adopts the following assumptions:
- 1:1 relationship between a proxy and an instance of a service. (No more than one service fronted by the same proxy.)
- 1:1 relationship between an endpoint (port and IP) and a proxy
Proxy Control Plane
The Proxy control plane handles gRPC connections from the service mesh sidecar proxies and implements Envoy’s go-control-plane
.
For a fully functional Envoy-based service mesh, the proxy control plane must implement the following interface:
- Aggregated Discovery Service - source
Aggregated Discovery Service
The StreamAggregatedResources
method is the entrypoint into the ADS vertical of OSM. This is
declared in the AggregatedDiscoveryServiceServer
interface, which is provided by the
Envoy Go control plane. It is declared in ads.pb.go.
Method DeltaAggregatedResources
is used by the ADS REST API. This project
implements gRPC only and this method will not be implemented.
When the Envoy Go control plane evaluates
StreamAggregatedResources
it passes a AggregatedDiscoveryService_StreamAggregatedResourcesServer
server. The
implementation of the StreamAggregatedResources
method will then use server.Send(response)
to send
an envoy.DiscoveryResponce
to all connected proxies.
An MVP implementation of StreamAggregatedResources
would require:
- Depending on the
DiscoveryRequest.TypeUrl
theDiscoveryResponse
struct for CDS, EDS, RDS, LDS or SDS is created. This will provide connected Envoy proxies with a list of clusters, mapping of service name to list of routable IP addresses, list of permitted routes, listeners and secrets respectively. - a method of notifying the system when the method described in #1 needs to be evaluated to refresh the connected Envoy proxies with the latest available resources (endpoints, clusters, routes, listeners or secrets)
Mesh Catalog Interface
In the previous section, we proposed implementation of the StreamAggregatedResources
method. This provides
connected Envoy proxies with a list of clusters, mapping of service name to list of routable IP addresses, list of permitted routes, listeners and secrets for CDS, EDS, RDS, LDS and SDS respectively.
The ListEndpointsForService
, ListTrafficPolicies
methods will be provided by the OSM component, which we refer to
as the Mesh Catalog in this document.
The Mesh Catalog will have access to the MeshSpec
, CertificateManager
, and the list of EndpointsProvider
s.
Additional types needed for this interface:
Endpoints Providers Interface
The Endpoints providers component provides abstractions around the Go SDKs of various Kubernetes clusters, or cloud vendor’s virtual machines and other compute, which participate in the service mesh. Each endpoint provider is responsible for either a particular Kubernetes cluster, or a cloud vendor subscription. The Mesh catalog will query each Endpoints provider for a particular service, and obtain the IP addresses and ports of the endpoints handling traffic for service.
The Endpoints providers are aware of:
- Kubernetes Service and their own CRD
- vendor-specific APIs and methods to retrieve IP addresses and Port numbers for Endpoints
The Endpoints providers has no awareness of:
- what SMI Spec is
- what Proxy or sidecar is
Note: As of this iteration of OSM we deliberately choose to leak the Mesh Specification implementation into the EndpointsProvider. The Endpoints Providers are responsible for implementing a method to resolve an SMI-declared service to the provider’s specific resource definition. For instance, when Azure EndpointProvider’s
ListEndpointsForService
is invoked with some a service name the provider would use its own method to resolve the service to a list of Azure URIs (example:/resource/subscriptions/e3f0/resourceGroups/mesh-rg/providers/Microsoft.Compute/virtualMachineScaleSets/baz
). These URIs are unique identifiers of Azure VMs, VMSS, or other compute with Envoy reverse-proxies, participating in the service mesh.
In the sample ListEndpointsForService
implementation, the Mesh Catalog loops over a list of Endpoints providers:
For each provider
registered in the Mesh Catalog, we invoke ListEndpointsForService
.
The function will be provided a ServiceName
, which is an SMI-declared service. The provider will
resolve the service to its own resource ID. For example ListEndpointsForService
invoked on the
Azure EndpointsProvider with service webservice
, will resolve webservice
to the URI of an
Azure VM hosting an instance of
the service: /resource/subscriptions/e3f0/resourceGroups/mesh-rg/providers/Microsoft.Compute/virtualMachineScaleSets/baz
.
From the URI the provider will resolve the list of IP addresses of participating Envoy proxies.
Mesh Specification
This component provides an abstraction around the SMI Spec Go SDK.
The abstraction hides the Kubernetes primitives. This allows us to implement SMI Spec providers
that do not rely exclusively on Kubernetes for storage etc. MeshSpec
Interface provides
a set of methods, listing all services, traffic splits, and policy definitions for the
entire service mesh.
The MeshSpec
implementation has no awareness of:
- what Envoy or reverse-proxy is
- what IP address, Port number, or Endpoint is
- what Azure, Azure Resource Manager etc. is or how it works
Certificate Manager
The certificate.Manager
as shown below is as simple as having a single method for issuing certificates, and another for obtaining a notification channel.
Additionally we define an interface for the Certificate
object, which requires the following methods:
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.