网站记录

K8S训练营

kubectl自动补全以及命令大全

kubectl自动补全以及命令大全github地址

k8s中文文档1

k8s中文文档2

k8s API 参考

关于Deployment的资源文件编写

1
2
3
4
5
1,在Deployment中必须写matchLables, 

2,在定义模板的时候必须定义labels,因为Deployment.spec.selector是必须字段,而他又必须和template.labels对应, 

3,template里面定义的内容会应用到下面所有的副本集里面,在template.spec.containers里面不能定义labels标签.

指令记录

k8s 清理namespace(命名空间)资源

1
2
3
4
5
6
7
1. 查找所有当前namespace下的资源
kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <ns>
2. 删除对应资源
kubectl get ingress -n <ns> |grep <rs-name> |awk '{print $1}'|xargs kubectl delete ingress -n <ns>
kubectl get service -n <ns> |grep <rs-name> |awk '{print $1}'|xargs kubectl delete service -n <ns>
kubectl get deployment -n <ns> |grep <rs-name> |awk '{print $1}'|xargs kubectl delete deployment -n <ns>
...

查看集群的CPU和内存资源的声明占用情况

可以使用下面的指令进行查看和过滤

1
kubectl describe node |grep -E '((Name|Roles):\s{6,})|(\s+(memory|cpu)\s+[0-9]+\w{0,2}.+%\))'

下图是对k8s集群的检查结果。可以明显地看到，所有的worker节点的内存Requests都已经达到99%，剩余的1%不足1G

container执行指令

1
kubectl  exec podName -c containerName -n namespace -- <shell comand>

replace和aplly的区别

1
2
3
kubectl replace 的执行过程，是使用新的 YAML 文件中的 API 对象，替换原有的 API 对象(前提是有这个原有api对象, 否则会报错)

kubectl apply，则是执行了一个对原有 API 对象的 PATCH 操作。(如果原有yaml文件内容没有变化,则不执行任何操作)

删除标签

1
2
kubectl describe node <node> |grep Labels
kubectl label nodes <node> k3s-worker1-

查看pod中的容器

1
kubectl get pods sapi-customer-696cc7cc8f-6frfc -n sopei-biz -o jsonpath={.spec.containers[*].name}

重启pod

1
kubectl get pod {podname} -n {namespace} -o yaml | kubectl replace --force -f -

查询某个node节点下{NAME_SPACE}所有pod的资源使用情况以及每个pod所在节点名称

1
2
3
4
5
6
# sort -nrk 3：按cpu使用情况倒序
# sort -nrk 3：按memory使用情况倒序
NAME_SPACE={查询namespace}
NODE={查询node节点}
# 此结果是9列/11列，所以做判断：awk '{if(NF > 9){print $1,$9}else{print $1,$7}}'
kubectl get pods --namespace=$NAME_SPACE -o wide | awk '{if(NF > 9){print $1,$9}else{print $1,$7}}' | grep -v NAME | grep $NODE| while read -r name node; do echo -n "$name $node "; kubectl top pod $name -n $NAME_SPACE |grep -v NAME| tail -1 | awk '{print $2,$3,$5}'; done|sort -nrk 3

为什么当一个节点故障时，一个 Pod 需要大于 5 分钟时间才能被重新调度？#

这是因为下列默认 Kubernetes 设置共同产生的效果：

  • kubelet
    • node-status-update-frequency：设置 kubelet 上报节点信息给 master 的频率。(默认 10s)
  • kube-controller-manager
    • node-monitor-period：NodeController 中 NodeStatus 的同步周期(默认 5s)
    • node-monitor-grace-period：节点被认定为不健康前，节点不作响应的总的时间。(默认 40s)
    • pod-eviction-timeout：优雅删除故障节点上容器的周期。(默认 5m0s)

获取更多信息请参阅

  1. Kubernetes：kubelet
  2. Kubernetes: kube-controller-manager
  3. Kubernetes Kubelet 状态更新机制 node-status-update-frequency

在 Kubernetes v1.13 版本中，TaintBasedEvictions特性是默认开启的。请查阅 Kubernetes: Taint based Evictions 获取更多信息。

  • kube-apiserver (Kubernetes v1.13 版本及以后)
    • default-not-ready-toleration-seconds: 表示 notReady:NoExecute 容忍的容忍时间。notReady:NoExecute 被默认添加到没有该容忍的所有 Pod。
    • default-unreachable-toleration-seconds: 表示 unreachable:NoExecute 容忍的容忍时间。unreachable:NoExecute 被默认添加到没有该容忍的所有 Pod。

解决办法

可以参考下面这个示例调整tolerationSeconds时间：

1
https://raw.githubusercontent.com/kingsd041/rancher-k3s/master/demo-busybox.yaml