在上一篇文章中我们了解了如何在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相关的命令我们会在别的文章中展开,此处不再赘述。