目录
1、kubectl命令说明
1.1、查看pod的命令
###查询某个namespace下所有pod信息
kubectl get pod -n=base-service
命令结果如下所示：
ubuntu@vm-192-168-163-56:~$ kubectl get pod -n=base-service
NAME READY STATUS RESTARTS AGE
sport-boss-5b8b878b56-9fh2d 1/1 Running 0 45h
sport-web-6c855954cdwsd-lwzsj 1/1 Running 6 57d
spillow-web-558fd89-9bjfs 1/1 Running 0 45h
sport-task-66c688d7-fphhb 1/1 Running 0 45h
sport-module-5cd6756ff-zzt6r 1/1 Running 0 7d19h
sport-task-98ddfdb49-pcvp6 1/1 Running 0 5d19h
sport-library-d7f55fd9b-kdbsv 1/1 Running 0 13d
sport-manage-54784df8d7-5hr5s 1/1 Running 0 5d14h
cix-conne-54784dwddf8d7-srbkh 1/1 Running 0 5d14h
cix-manage-service-d75bc6bc5-v2slc 1/1 Running 0 46h
cix-service-6cccf9b69d-4pnds 1/1 Running 0 17h
cix-web-conne-5bes33f5c8bfc4-5pcpw 1/1 Running 0 45h
cix-web-conne-5bfew3e5c8bfc4-g4df8 1/1 Running 0 45h
eas-5ccfcd87f8-whgql 1/1 Running 0 15d
eas-web-b84997b59-d4vsf 1/1 Running 0 57d
food-service-64684c9894-xlzpk 1/1 Running 7 57d
intergation-service-87b9f665f-ghss7 1/1 Running 0 21d
push-gateway-6885cbcdc6-vzcjp 1/1 Running 0 6d
###根据pod名称筛选
kubectl get pod -n firt-sport |grep sport
命令结果如下所示：
sport-boss-5b8b878b56-9fh2d 1/1 Running 0 45h
sport-web-6c855954cdwsd-lwzsj 1/1 Running 6 57d
sport-module-5cd6756ff-zzt6r 1/1 Running 0 7d19h
sport-task-98ddfdb49-pcvp6 1/1 Running 0 5d19h
sport-library-d7f55fd9b-kdbsv 1/1 Running 0 13d
sport-manage-54784df8d7-5hr5s 1/1 Running 0 5d14h
注:如果namespace是default时，命令中可以去掉-n firt-sport部分。
1.2、查看pod对应ip的命令
###查询某个namespace下所有的pod对应的ip及端口号
kubectl get svc -n firt-sport | grep sport
结果显示如下：
sport-boss ClusterIP 172.18.91.157 <none> 8080/TCP 714d
sport-web ClusterIP 172.18.252.55 <none> 8080/TCP 352d
sport-task ClusterIP 172.18.170.76 <none> 8080/TCP 353d
sport-module ClusterIP 172.18.27.14 <none> 8080/TCP 18d
sport-library ClusterIP 172.18.139.206 <none> 8080/TCP 493d
sport-manage ClusterIP 172.18.166.3 <none> 80/TCP 319d
1.3、查看日志
###查询某个namespace下某个服务的日志， --tail=100标识打印100行，-f表示打印实时日志
kubectl logs -f -n firt-sport sport-web-67b68d8948-dsdrq
结果显示如下
com.ctrip.framework.apollo.internals.RemoteConfigLongPollService.doLongPollingRefresh(RemoteConfigLongPollService.java:197)
com.ctrip.framework.apollo.internals.RemoteConfigLongPollService.access$100(RemoteConfigLongPollService.java:51)
com.ctrip.framework.apollo.internals.RemoteConfigLongPollService$2.run(RemoteConfigLongPollService.java:123)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
java.util.concurrent.FutureTask.run(FutureTask.java:266)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
03-Jul-2019 19:24:42.050 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /usr/local/apache-tomcat-8.5.9/webapps/sport.war has finished in 45,146 ms
03-Jul-2019 19:24:42.077 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [http-nio-8080]
03-Jul-2019 19:24:42.113 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler [ajp-nio-8009]
03-Jul-2019 19:24:42.120 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 45454 ms
1.4、重启pod
### namespace不是default时，需要添加上对应的namespace信息
kubectl delete pod sport-web-67b68d8948-dsdrq -n firt-sport
显示结果如图：
pod "sport-web-67b68d8948-dsdrq" deleted
1.5、进入pod内部
###有些接口是直接提供给内部服务调用的，这个时候如果确认某个接口是否可以正确调用，可以直接跳转到对应服务内部机器上，通过curl命令进行测试，进入服务内部命令如下：
kubectl exec -it -n firt-sport sport-web-67b68d8948-dsdrq bash
###退出，返回到跳板机
exit
命令结果如图
ubuntu@vm-192-168-163-56:~$ kubectl exec -it -n firt-sport sport-web-67b68d8948-wsktl bash
root@sport-web-67b68d8948-wsktl:/# exit
exit
ubuntu@vm-192-168-163-56:~$
1.6、查看节点及命名空间
###可以同时查询多类内容，用“,”隔开，也可以单独查询
kubectl get node,namespace
ubuntu@vm-192-168-163-56:~$ kubectl get node,namespace
NAME STATUS ROLES AGE VERSION
node/192.168.163.50 Ready <none> 54d v1.12.3
node/192.168.163.51 Ready <none> 46d v1.12.3
node/192.168.163.52 Ready <none> 2y79d v1.12.3
node/192.168.163.53 Ready <none> 686d v1.12.3
node/192.168.163.54 Ready <none> 463d v1.12.3
node/192.168.163.55 Ready <none> 248d v1.12.3
node/192.168.163.56 Ready <none> 34d v1.12.3
NAME STATUS AGE
namespace/test Active 267d
namespace/base-service Active 266d
namespace/firt-sport Active 266d
namespace/default Active 2y149d
namespace/heal-bky Active 27d
namespace/ingy Active 266d
namespace/test-nginx Active 420d
namespace/kube-public Active 2y149d
namespace/kube-system Active 2y149d
namespace/lelf Active 273d
1.7、查看pod运行在哪个Node
###namespace不是default时，需要加上对应的namespace信息
kubectl get pod sport-web -n firt-sport
结果如下显示：
ubuntu@vm-192-168-163-56:~$ kubectl get pod -n firt-sport sport-web-67b68d8948-wsktl -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
sport-web-67b68d8948-wsktl 1/1 Running 0 13m 172.20.65.46 192.168.163.51 <none>
ubuntu@vm-192-168-163-56:~$
2、linux安装命令
apt updata && apt-get intall xx
###xx替换成对应命令
eg：apt update && apt-get install curl
3、监控Mongodb
###进入Mongodb服务内部
kubectl exec -it -n firt-sport mongo-controller-d8b79686-2hf2x bash
###监控命令
mongostat
监控结果显示
root@mongo-controller-d8b79686-2hf2x:/# mongostat
insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time
1 8 *0 *0 0 24|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 4.46k 53.9k 163 Sep 4 10:59:34.917
*0 *0 *0 *0 0 16|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 1.03k 50.8k 163 Sep 4 10:59:35.918
*0 *0 *0 *0 0 14|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 1.48k 49.2k 163 Sep 4 10:59:36.922
*0 *0 *0 *0 0 19|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 1.13k 50.5k 163 Sep 4 10:59:37.915
1 1 *0 *0 0 14|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 3.21k 52.5k 163 Sep 4 10:59:38.914
*0 3 *0 *0 0 20|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 5.32k 52.5k 163 Sep 4 10:59:39.914
*0 3 *0 *0 0 9|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 2.08k 89.1k 163 Sep 4 10:59:40.915
*0 *0 *0 *0 0 10|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 617b 44.5k 163 Sep 4 10:59:42.004
*0 *0 *0 *0 0 12|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 732b 53.3k 163 Sep 4 10:59:42.914
2 4 *0 *0 0 16|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 3.95k 95.0k 163 Sep 4 10:59:43.914
insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time
*0 3 *0 *0 0 18|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 2.83k 60.0k 163 Sep 4 10:59:44.914
*0 3 *0 *0 0 15|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 1.87k 47.5k 163 Sep 4 10:59:46.004
1 *0 *0 *0 0 21|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 2.27k 55.4k 163 Sep 4 10:59:46.914
1 *0 *0 *0 0 20|0 0.0% 19.7% 0 5.56G 4.54G 0|0 0|0 2.67k 50.4k 163 Sep 4 10:59:47.914
字段解释说明：
insert/s : 官方解释是每秒插入数据库的对象数量，如果是slave，则数值前有*,则表示复制集操作
query/s : 每秒的查询操作次数
update/s : 每秒的更新操作次数
delete/s : 每秒的删除操作次数
getmore/s: 每秒查询cursor(游标)时的getmore操作数
command: 每秒执行的命令数，在主从系统中会显示两个值(例如 3|0),分表代表 本地|复制 命令
注： 一秒内执行的命令数比如批量插入，只认为是一条命令（所以意义应该不大）
dirty： 仅仅针对WiredTiger引擎，官网解释是脏数据字节的缓存百分比
used：仅仅针对WiredTiger引擎，官网解释是正在使用中的缓存百分比
flushes：
For WiredTiger引擎：指checkpoint的触发次数在一个轮询间隔期间
For MMAPv1 引擎：每秒执行fsync将数据写入硬盘的次数
注：一般都是0，间断性会是1， 通过计算两个1之间的间隔时间，可以大致了解多长时间flush一次。flush开销是很大的，如果频繁的flush，可能就要找找原因了
vsize：虚拟内存使用量，单位MB （这是 在mongostat 最后一次调用的总数据）
res：物理内存使用量，单位MB （这是 在mongostat 最后一次调用的总数据）
注：这个和你用top看到的一样, vsize一般不会有大的变动， res会慢慢的上升，如果res经常突然下降，去查查是否有别的程序狂吃内存。
qr：客户端等待从MongoDB实例读数据的队列长度
qw：客户端等待从MongoDB实例写入数据的队列长度
ar：执行读操作的活跃客户端数量
aw：执行写操作的活客户端数量
注：如果这两个数值很大，那么就是DB被堵住了，DB的处理速度不及请求速度。看看是否有开销很大的慢查询。如果查询一切正常，确实是负载很大，就需要加机器了
netIn：MongoDB实例的网络进流量
netOut：MongoDB实例的网络出流量
注：此两项字段表名网络带宽压力，一般情况下，不会成为瓶颈
conn： 打开连接的总数，是qr,qw,ar,aw的总和
注：MongoDB为每一个连接创建一个线程，线程的创建与释放也会有开销，所以尽量要适当配置连接数的启动参数，maxIncomingConnections，阿里工程师建议在5000以下，基本满足多数场景