Exercise for the blog post on external ingress proxies in Istio #19
Conversation
| @@ -0,0 +1,14 @@ | |||
| # ingress-ingress-ns.yaml | |||
There was a problem hiding this comment.
@ZackButcher Just to verify my understanding, since there's another Ingress resource in the default namespace, which nginx-ingress-controller will enforce this Ingress resource? Is it the nginx-ingress-controller in the same namespace, i.e. ingress namespace?
| kubernetes.io/ingress.class: nginx | ||
| nginx.ingress.kubernetes.io/service-upstream: "true" | ||
| nginx.ingress.kubernetes.io/upstream-vhost: httpbin.default.svc.cluster.local | ||
| spec: | ||
| backend: | ||
| serviceName: httpbin | ||
| servicePort: 8000 |
There was a problem hiding this comment.
@ZackButcher Also, currently there is only one httpbin service in the default namespace. The same httpbin service is exposed to external traffics by the two Ingress resources in the default and the ingress namespaces. Would it be better if we have two httpbin services in the default namespace, each exposed by a different Ingress resource?
| 2. Create ingress resource routing to httpbin | ||
| ```shell script | ||
| kubectl apply -f ingress-ingress-ns.yaml | ||
| ``` | ||
| 3. Create sidecar resource to allow traffic from pods in ingress namespace to pods in default namespace | ||
| ```shell script | ||
| kubectl apply -f sidecar-ingress-ns.yaml | ||
| ``` |
There was a problem hiding this comment.
@ZackButcher Another observation is that as of the current setup, these two steps does not seem to be necessary. The verification steps below behave normally when these steps are omitted
Task Accomplished
Reference