Kubernetes - 接続拒否診断

Question

私は実行中のGCP Kubernetesクラスタを持っています。いくつかのサービスを展開し、kubectl expose ... type = "LoadBalancer"を使用してそれらを公開しました...しかし、特定の新しいサービスが動作していません。何千もの原因を調べることができますが、ビルドしたDockerイメージは非常にコンパクトなので、ポッドやコンテナ内でkubectl execを実行するのに便利なツールは見つけられません。

質問：可能性のあるクラスタツールのみを使用した診断オプションは何ですか？どのようなログを調べることができますか、どの環境変数を読むことができますか？

UPDATED

：

$ kubectl GET

NAME        READY  STATUS RESTARTS AGE 
helianto-mailer-1024769093-6407d 2/2  Running 0   6d 
helianto-spring-2246525676-l54p9 2/2  Running 0   6d 
iservport-shipfo-12873703-wrh37 2/2  Running 0   13h 

$はポッドiservport-shipfo-12873703-wrh37

Name:   iservport-shipfo-12873703-wrh37 
Namespace:  default 
Node:   gke-iservport01-default-pool-xxx/xx.xx.xx.xx 
Start Time:  Tue, 14 Mar 2017 17:28:18 -0300 
Labels:   app=SHIPFO 
       pod-template-hash=12873703 
Status:   Running 
IP:    yy.yy.yy.yy 
Controllers: ReplicaSet/iservport-shipfo-12873703 
Containers: 
    iservport-shipfo: 
    Container ID:   docker://... 
Image:    us.gcr.io/mvps-156214/iservport-xxx 
Image ID:   docker://... 
    Port:    8085/TCP 
    Requests: 
     cpu:    100m 
    State:    Running 
     Started:   Tue, 14 Mar 2017 17:28:33 -0300 
    Ready:    True 
    Restart Count:  0 
    Volume Mounts: 
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-mmeza (ro) 
    Environment Variables: 
    SPRING_PROFILES_ACTIVE: gcp 
     HELIANTO_MAILER_URL:  http://10.35.254.197:8082 
    cloudsql-proxy: 
    Container ID:  docker://... 
    Image:    b.gcr.io/cloudsql-docker/gce-proxy:1.05 
    Image ID:   docker://... 
    Port:    
    Command: 
    /cloud_sql_proxy 
    --dir=/cloudsql 
    -instances=mvps-156214:us-east1-b:helianto01=tcp:3306 
    -credential_file=/secrets/cloudsql/credentials.json 
    Requests: 
     cpu:    100m 
    State:    Running 
     Started:   Tue, 14 Mar 2017 17:28:33 -0300 
    Ready:    True 
    Restart Count:  0 
    Volume Mounts: 
     /cloudsql from cloudsql (rw) 
     /etc/ssl/certs from ssl-certs (rw) 
     /secrets/cloudsql from cloudsql-oauth-credentials (ro) 
     /var/run/secrets/kubernetes.io/serviceaccount from default-token-mmeza (ro) 
    Environment Variables:  <none> 
Conditions: 
Type   Status 
    Initialized True 
    Ready   True 
    PodScheduled True 
Volumes: 
    cloudsql-oauth-credentials: 
    Type:  Secret (a volume populated by a Secret) 
    SecretName: cloudsql-oauth-credentials 
    ssl-certs: 
    Type:  HostPath (bare host directory volume) 
    Path:  /etc/ssl/certs 
    cloudsql: 
    Type:  EmptyDir (a temporary directory that shares a pod's lifetime) 
    Medium:  
    default-token-mmeza: 
    Type:  Secret (a volume populated by a Secret) 
    SecretName: default-token-mmeza 
QoS Class:  Burstable 
Tolerations: <none> 
No events. 

$ kubectl GET SVC

を記述kubectlポッド

NAME      CLUSTER-IP  EXTERNAL-IP  PORT(S)      AGE 
helianto-mailer-service 10.35.254.197 <nodes>   443:32178/TCP,80:30771/TCP 12d 
helianto-spring   10.35.241.27 xxx.xxx.xxx.xxx 80:30974/TCP     52d 
iservport-shipfo   10.35.240.129 xx.xxx.xxx.xxx 80:32598/TCP     14h 
kubernetes    10.35.240.1  <none>   443/TCP      53d 

$ビューのホストの観点から、コンテナが唯一proccessあるので、あなたは、Kubernetesワーカーホストに接続し、そこに診断を行うことができ

Name:     iservport-shipfo 
Namespace:    default 
Labels:     app=SHIPFO 
Selector:    app=SHIPFO 
Type:     LoadBalancer 
IP:      10.35.240.129 
LoadBalancer Ingress: xx.xxx.xxx.xxx 
Port:     <unset> 80/TCP 
NodePort:    <unset> 32598/TCP 
Endpoints:    10.32.4.26:8085 
Session Affinity:  None 
No events. 

Answer 1

SVCのiservport-shipfoを記述kubectl 。

Answer 2

サービスがhttpポートで応答しているかどうかを確認する必要があります。おそらく、あなたのポッドから自分のデスクトップのポートフォワードを行うことができます。以下のコマンドで、pod_name、pod_port、およびlocal_portの値を置き換えてください。この後

kubectl port-forward <pod_name> <local_port>:<pod_port>

、アクセスhttp://localhost:local_portと何かを返すかどうかを確認します。これにより、アプリケーションが応答しているかどうかを確認できます。