Istio - Verbindungszeitüberschreitung beim Aufruf von service-two von service-one (Beispiele) - kubernetes, istio

Ich folge den Tutorials, um Istio als Servicegitter für meinen K8-Cluster zu bewerten, kann aber aus irgendeinem Grund kein einfaches Beispiel erstellen, in dem einige Services für die ordnungsgemäße Funktion verwendet werden:

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

Wenn ich versuche, service-two von service-one aus aufzurufen, erhalte ich folgende Fehlermeldung:

# kubectl exec -ti ${CLIENT} -- curl -v service-two:80
Defaulting container name to app.
Use "kubectl describe pod/service-one-714088666-73fkp" to see all of the containers in this pod.
* Rebuilt URL to: service-two:80/
*   Trying 10.102.51.89...
* connect to 10.102.51.89 port 80 failed: Connection refused
* Failed to connect to service-two port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to service-two port 80: Connection refused

Wenn ich jedoch versuche, von einem anderen Dienst in meinem Cluster aus, auch in einem anderen Namespace, eine Verbindung zu Dienst zwei herzustellen, funktioniert Folgendes:

# kubectl exec -ti redis-4054078334-mj287 -n redis -- curl -v service-two.default:80
* Rebuilt URL to: service-two.default:80/
* Hostname was NOT found in DNS cache
*   Trying 10.102.51.89...
* Connected to service-two.default (10.102.51.89) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: service-two.default
> Accept: */*
>
< HTTP/1.1 200 OK
* Server envoy is 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 to host service-two.default left intact
-no body in request-

Gibt es einen Grund oder eine Erklärung, warum ich dieses unerwartete Verhalten erhalte?

Vielen Dank.

Antworten:

Ich habe herausgefunden, was passiert ist: am service-one Die Init-Container wurden nicht ordnungsgemäß ausgefüllt, sodass sie nicht ordnungsgemäß aufgelöst wurden.