Closed electrocucaracha closed 3 years ago
So... perhaps I'm missing something... but this seems a lot more complicated than our previous annotation scheme...
This issue has been automatically marked as stale because it has not had activity in 30 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has been inactive for 37 days. Feel free to reopen it if you feel it has been closed in error.
@edwarnicke I have created this Mutating Admission Webhook which injects the NSM sidecar base on the annotations. This change allows to support multiple cni-multiplexers:
apiVersion: v1
kind: Pod
metadata:
name: example
annotations:
danm.k8s.io/interfaces: |
[
{"clusterNetwork":"default"},
{"clusterNetwork":"lte-s5u"},
{"clusterNetwork":"lte-s5c"},
{"clusterNetwork":"lte-sgi"}
]
k8s.v1.cni.cncf.io/networks: |
[
{"name": "lte-s5u", "interface": "s5u1"},
{"name": "lte-s5c", "interface": "s5c2"},
{"name": "lte-sgi", "interface": "sgi3"}
]
ns.networkservicemesh.io/endpoints: |
{
"name": "lte-network",
"networkServices": [
{"link": "sgi", "labels": "app=http-server-sgi", "ipaddress": "10.0.1.0/24", "route": "10.0.3.0/24"},
{"link": "s5u", "labels": "app=pgw-s5u", "ipaddress": "172.25.0.0/24"},
{"link": "s5c", "labels": "app=pgw-s5c", "ipaddress": "172.25.1.0/24"}
]
}
spec:
containers:
- image: busybox:stable
name: instance
command:
- sleep
args:
- infinity
@electrocucaracha This is interesting... but we typically keep our annotations far simpler, basically of a form
ns.networkservicemesh.io/endpoints: ${nsmurl}
we don't generally specify IP addresses or routes on the NSC side... the NSC has no sayin that, it all comes down from the NSE.
I'm curious to understand more about your thought process though :)
@edwarnicke those annotations are for the Endpoint, clients use the traditional ns.networkservicemesh.io
annotation
apiVersion: v1
kind: Pod
metadata:
name: client
annotations:
ns.networkservicemesh.io: lte-network/s5u3?link=s5u,lte-network?link=sgi
spec:
containers:
- image: busybox:stable
name: instance
command:
- sleep
args:
- infinity
Overview
Istio project provides a method to automatic inject sidecars. This approach helps developers to focus on the business logic putting on side trivial things managed by the sidecars.
This feature can be implemented on this project having an universal sidecar implementation for covering most of the scenarios and the creation of an admission controller.
The following source code examples provides an idea of this proposal.
Pod definition (defined by user)
Pods can specify their requirements through the usage of annotations, like this one:
Pod definition (modified by admission controller)
The previous Pod definition can be modified by the Admission controller and inject the sidecar and take advantage of the downwardAPI feature to define Network Services.
Universal sidecar
The following code is an example of the universal sidecar implementation.