kubernetes - Istio - Connection timeout when calling service-two from service-one (examples) -

i'm following tutorials evaluate istio service mesh k8s cluster, reason cannot make simple example uses couple of services work properly:

https://istio.io/docs/tasks/integrating-services-into-istio.html

if try call service-two service-one, error:

# kubectl exec -ti ${client} -- curl -v service-two:80 defaulting container name app. use 'kubectl describe pod/service-one-714088666-73fkp' see of containers in pod. * rebuilt url to: service-two:80/ *   trying 10.102.51.89... * connect 10.102.51.89 port 80 failed: connection refused * failed connect service-two port 80: connection refused * closing connection 0 curl: (7) failed connect service-two port 80: connection refused 

however, if try connect service-two service in cluster, in different namespace, works:

# kubectl exec -ti redis-4054078334-mj287 -n redis -- curl -v service-two.default:80 * rebuilt url to: service-two.default:80/ * hostname not found in dns cache *   trying 10.102.51.89... * connected service-two.default (10.102.51.89) port 80 (#0) > / http/1.1 > user-agent: curl/7.38.0 > host: service-two.default > accept: */* >  < http/1.1 200 ok * server envoy not blacklisted < server: envoy < date: sat, 19 aug 2017 14:43:01 gmt < content-type: text/plain < x-envoy-upstream-service-time: 2 < transfer-encoding: chunked <  client values: client_address=127.0.0.1 command=get real path=/ query=nil request_version=1.1 request_uri=http://service-two.default:8080/   server values: server_version=nginx: 1.10.0 - lua: 10001   headers received: accept=*/* content-length=0 host=service-two.default user-agent=curl/7.38.0 x-b3-sampled=1 x-b3-spanid=00000caf6e052e86 x-b3-traceid=00000caf6e052e86 x-envoy-expected-rq-timeout-ms=15000 x-forwarded-proto=http x-ot-span-context=00000caf6e052e86;00000caf6e052e86;0000000000000000;cs x-request-id=1290973c-7bca-95d2-8fa8-80917bb404ad body: * connection #0 host service-two.default left intact -no body in request- 

any reason or explanation why unexpected behaviour?

thanks.

i figured out happened: on service-one init containers had not been completed, not resolving correctly.