2017-03-14 77 views
0

我有一个正在运行的GCP Kubernetes集群。我设法部署了一些服务,并使用kubectl expose ... type =“LoadBalancer”成功地公开了它们......但是,一个特定的新服务无法正常工作。我知道可能有一千个原因需要检查,但是我构建的Docker镜像非常紧凑,所以我找不到有用的工具通过pod或容器中的kubectl exec运行。Kubernetes - 连接拒绝诊断

问题:什么可能是我的诊断选项使用任何可能的群集工具只?我可以检查什么样的日志,或者我可以读取哪些环境变量?

更新:

$ kubectl得到荚

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 

$ kubectl描述荚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得到SVC

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 

$ kubectl描述SVC iservport-shipfo

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. 

回答

0

你可以连接到Kubernetes工人主机和从视主机点做诊断那里,因为,容器只是下面的一个进程。

+0

好点,gcloud compute ssh xxx帮助。但是,我没有找到我的连接失败的原因。 –

2

您需要确定您的服务是否在http端口中响应。也许你可以从你的pod到你的桌面本地端口。请在命令行中将值pod_name,pod_port和local_port替换。

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

在此之后,获得http://localhost:local_port和验证,如果回报。这样,您可以确定您的应用程序是否正在响应。