update admission.md documentation
@@ -36,7 +36,7 @@ secure-intranet-connectivity/eth2?app=firewall&version=2
Would imply a network service named `secure-intranet-connectivity` connected on `eth2`, with labels: `app=firewall` and `version=2`.
-Merging this example to the full `yaml` above, we ccan let the client connect with two netowrk services simlutaneously:
+Merging this example to the full `yaml` above, we can let the client connect with two network services simultaneously:
```yaml
apiVersion: v1
@@ -55,7 +55,7 @@ If and only if the Pod has the `ns.networkservicemesh.io` annotation exists, and
```yaml
initContainers:
- - name: nsc
+ - name: nsm-init-container
image: ${REPO}/${INITCONTAINER}:${TAG}
imagePullPolicy: IfNotPresent
env:
@@ -70,7 +70,8 @@ The ${INITCONTAINER} is based on the SDK's `NSMClientList` which parses `${NS_NE
${REPO}, ${INITCONTAINER}, and ${TAG} are specifiable for the mutating admission webhook container, defaulting to REPO=networkservicemesh, INITCONTAINER=nsc, TAG=latest.
-
+The nsm-init container will be added to the beginning of the `initContainers` list of the POD. It means that other init containers on the list can do some work with a created connection/network setup prepared by `nsm-init-container`.
+NOTE: Depending on the value of annotation `ns.networkservicemesh.io` NSM init container can prepare multiple connections (see the merge example above).
## Possible Augmentations
Because the Mutating Admission Controller allows us to add complexity to the initcontainer without taxing the user, it is desirable to have the initcontainer add additional information, for example, the Pod id, or Node name via the downward API as env variables that can be then added as labels to the Network Service Request. This will likely be handy for #708.
