We currently use the kubernetes nginx-ingress-controller and would like to add Linkerd in a basic service mesh configuration (deloyed as a daemonset). I’ve read the guide at https://buoyant.io/2016/11/18/a-service-mesh-for-kubernetes-part-v-dogfood-environments-ingress-and-edge-routing/ which explains how to configure nginx to proxy to Linkerd and I think this is more or less what I am aiming for, except I would like to continue to use the Ingress objects to configure nginx-ingress-controller, rather than create a custom nginx deployment and config.
The first thing I have tried is using the Linkerd config from the article above, and routing traffic via the
backend configuration in the Ingress definition to point at the Service for Linkerd. This sends requests to a Linkerd with the expected service hostname. E.g
rules: - host: my-service.platform-stage.gcp0.my-host.net http: paths: - path: / backend: serviceName: l5d servicePort: 4142
With the correct dtabs in place I can route traffic to the backend service successfully and see requests coming through the ingress and incoming routers. But I’m not sure exactly whether what I’ve configured is totally sound.
The main concern is that I am not forwarding requests from nginx through an outbound local linkerd (I assume this is why I see no traffic on the outbound router?). However, I think this is also the case with the article above, where nginx is configured to proxy_pass to
http://l5d.default.svc.cluster.local, which resolves to the cluster VIP of the Kubernetes Service not the node-local linkerd IP.
If I am correct, what are the implications of this? And is it a suitably reliable configuration to use?