kubernetes1.4 基础篇：Learn Kubernetes 1.4 by 6 steps（4）：Step 3. Explore Your App

在上一篇文章中我们了解了如何在kubernetes中部署kubernetes的dashboard，本文我们将进一步了解到其背后的kubernetes的基础知识以及如何使用常用的kubectl进行故障排除的确认。

Pod

我们在前面的文章中讲到过node，node就是作为整个集群中的worker，它是和Master这个节点向比较的。而pod是什么呢，我们在上一篇文章中创建了一个dashboard的Deployment，这就是一个容器化了的应用被部署的实例。而Pod是kubernetes的一组应用容器的抽象，为什么要做这层抽象呢，容器间资源的共享。比如容器的Volume，在比如容器的port，如何在多个容器之间共享，docker-compose就是基于这个目的对docker机能的扩展和延伸。pod里面可以是单独的一个container也可以是多个。pod将一组耦合度很高的容器紧密地结合在一起作为一个整体的方式。比如我们在DevOps的Automation的时候很多项目都倒入了Sonarqube，sonarqube使用一个内部缺省的DB的话一个容器就解决问题，但是如果我们希望把数据能单独进行管理比如使用mysql或者mariadb等的话，我们至少可能需要2个容器，这个时候就可以使用一个pod把这两个都塞进去就可以了。

比如上图中的Pod4，我们就可以理解为有多个被容器化了的应用程序的组合，这些应用程序共享一个集群内部的IP10.10.10.4，共享内部的Volume。

Node

了解完pod之后，在来审视一下塞了pod的node吧。pod作为kubernetes上的最小单位，当我们创建一个kubernetes的Deployment的时候，Deployment其实也自然会使用所需的容器创建pod。通过kubernetes的分配，pod会与node建立联系。我们过去通过使用小机作双机双活等技巧在kubernetes面前显得非常无力，无论是从规模还是控制等，在这里死掉一个pod希望其自动恢复之需要调整它的重启策略，node发生故障的时候也可以在其他的node上自动启动该pod，而这些都可以调整。多年之前给客户做的Tuxedo+MC/SG等作的负载均衡和高可用的架构骄傲过几天，而从去年看到象kubernetes这样的神器的出现感到极其的悲伤和无力，又有很多技能和知识变成废纸了。在这里，所有需要做的已经没有什么了，调节一下参数的程度。

使用kubectl故障排查

我们已经使用过kubectl做过好多事情，在接下来的内容中我们将会进一步的使用kubectl来探寻我们已经部署到kubernetes上的应用，而这些将会是在使用kubernetes进行工作的时候故障排查和确认所会使用的最常用的命令。

命令	说明
kubectl get	诸如kubectl get nodes等等列出资源一览
kubectl describe	对kubectl取到的信息进一步对某一resource进行更深入的确认
kubectl logs	确认pod的某个container的log信息
kubectl exec	类似于docker exec，可以在某个container中执行命令等

确认应用配置信息

我们在前面提到过创建Deployment会创建pod，接下来我们会使用kubectl get pods来进行确认

[root@host31 ~]# kubectl get pods --namespace=kube-system
NAME                                    READY     STATUS    RESTARTS   AGE
dummy-2088944543-rp84q                  1/1       Running   0          6h
etcd-host31                             1/1       Running   0          6h
kube-apiserver-host31                   1/1       Running   0          6h
kube-controller-manager-host31          1/1       Running   0          6h
kube-discovery-982812725-t71i9          1/1       Running   0          6h
kube-dns-2247936740-eez6o               3/3       Running   0          6h
kube-proxy-amd64-4jxh6                  1/1       Running   0          5h
kube-proxy-amd64-5ahum                  1/1       Running   0          6h
kube-proxy-amd64-6wql2                  1/1       Running   0          5h
kube-proxy-amd64-qu4bs                  1/1       Running   0          5h
kube-scheduler-host31                   1/1       Running   0          6h
kubernetes-dashboard-3000474083-y1htc   1/1       Running   0          3h
weave-net-7tvvm                         2/2       Running   0          5h
weave-net-q17ey                         2/2       Running   0          5h
weave-net-uktxs                         2/2       Running   0          6h
weave-net-y8zpe                         2/2       Running   0          5h
[root@host31 ~]#

我们清楚地看到kubernetes-dashboard-3000474083-y1htc作为其中一个pod果然被生成了，接下来想进一步察看这个pod的话需要使用kubectl describe pods来进行了。

[root@host31 ~]# kubectl describe pods kubernetes-dashboard-3000474083-y1htc --namespace=kube-system
Name:           kubernetes-dashboard-3000474083-y1htc
Namespace:      kube-system
Node:           host34/192.168.32.34
Start Time:     Wed, 09 Nov 2016 07:37:22 -0500
Labels:         app=kubernetes-dashboard
                pod-template-hash=3000474083
Status:         Running
IP:             10.36.0.1
Controllers:    ReplicaSet/kubernetes-dashboard-3000474083
Containers:
  kubernetes-dashboard:
    Container ID:       docker://f97b36f8de62d911356b20f3e8840c14b7ed11a35443a865ae78d79d439a7667
    Image:              gcr.io/google_containers/kubernetes-dashboard-amd64:v1.4.1
    Image ID:           docker://sha256:1dda73f463b239955d4cf94a9cd525ab5306bee0eb53c17534d3282bc50ae7aa
    Port:               9090/TCP
    State:              Running
      Started:          Wed, 09 Nov 2016 07:37:24 -0500
    Ready:              True
    Restart Count:      0
    Liveness:           http-get http://:9090/ delay=30s timeout=30s period=10s #success=1 #failure=3
    Volume Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-852jy (ro)
    Environment Variables:      <none>
Conditions:
  Type          Status
  Initialized   True
  Ready         True
  PodScheduled  True
Volumes:
  default-token-852jy:
    Type:       Secret (a volume populated by a Secret)
    SecretName: default-token-852jy
QoS Class:      BestEffort
Tolerations:    dedicated=master:Equal:NoSchedule
No events.[root@host31 ~]#

在这里我们看到了很多信息：Port/状态/ContainerID/Namespace等更细的信息。
关于其他kubectl相关的命令我们会在别的文章中展开，此处不再赘述。