SDC Service Mesh Compliance

This page will act as a basic planning/progress guide on the compliance of SDC to the new Service Mesh requirements in the OOM Helm Charts.

Common Principles

In order to make the service mesh work, here are the common principles/requirements:

• Prefer use of (non headless) services. Pod to pod communication is not a first class citizen in a Service mesh (as the name stands). Thus using non headless services in the preferred way.

• Listen at least on 127.0.0.1. Service Mesh sidecar will listen on the public POD IP. If the traffic is allowed, it needs to pass it to the "real" POD. For that, it sends it to 127.0.0.1. Then, the POD must listen on this interface

• Name the ports in the service / pod with their protocol. In order to detect protocol, service mesh tends to use the naming of the port (on the service and pod part). Naming it "foo" doesn't help whereas "http" or "http-foo" helps the service mesh provider to know which protocol is used. allowed protocols are "tcp", "http", "https", "http2", "grpc".

• Allow to disable https (or enable http). As the ssl part can be done by the service mesh, there's no need to do it on the pod side. Thus, we should be able to disable https (or enable http).

Principles specific to ONAP

• As AAF is used for certificates generation and as AAF is not compliant with service mesh, we need to be able to disable AAF integration in ONAP components.

SDC Sub-Components

Additional Related Documentation: 

• Service Mesh Risk Analysis

• ONAP on Service Mesh