Integration with EKS about aws-app-mesh-roadmap

[jamsajones]

@polothy and @mumoshu thanks for the input. We like the idea of having a tool (or API) that can produce the valid YAML for the Envoy sidecar(s). This would allow you to create a mutating webhook - to a Lambda function you own for example - and you could then do the injection. Alternatively, you could call the same tool/API in your CICD pipelines to pre-gen the correct YAML and not have the kubediff issue.

[polothy]

Is this for automatic sidecar injection of the Envoy proxy in a K8s namespace?

[jamsajones]

@polothy This will be more of an epic to cover all of the integration. Sidecar injection will likely be an option as part of this integration. Would injection be something you need to adopt App Mesh?

[mumoshu]

I personally don't need automatic sidecar injection, due to that it makes "diff"ing between the current and the desired state of k8s resources difficult. For example, kubediff would always show the injected parts of the k8s resource as added, which may confuse the user.

I'd say a well-documented process of a manual sidecar injection, possibly supported by a command in awscli, would be enough. An example of such thing is istioctl kube-inject. Something like aws appmesh kube-inject-sidecar -f manifest.yaml would make sense to me.

[polothy]

Right now, it would certainly ease adoption. One of the things that I like about sidecar injection is that it keeps the sidecar up-to-date on each deployment. In addition, our service developers don't need manage it themselves.

If sidecar is somehow not possible, tooling for generating the YAML (like what @mumoshu mentions) would certainly be appreciated so we can build a very process around the tooling. Ideally the command can be ran against the same YAML file any number of times to help with updates and maybe then it could just be automated (or at least validated).

[coultn]

See here: https://github.com/aws/aws-app-mesh-controller-for-k8s
https://github.com/aws/aws-app-mesh-inject