zifuy 的个人笔记

事件查看

kubectl describe 

日志信息

kubectl logs --tail=10 -f pods/podname -n namespaces

监控信息

docker stats 

维护模式(Cordon)

kubectl cordon node01   #先设置节点不可调度

疏散pod(Drain)

当我们需要对一个节点进行维护，或者删除这个节点的时候，需要手动将布置在上面的Pod主动驱逐出来，以便不影响业务的连续性。

kubectl drain node01  #驱逐node01节点上的Pod（先设置node为cordon不可调度状态，然后驱逐Pod）

维护完后需要将节点设置为可调度

kubectl uncordon node01

示例：

以上命令执行完后

1. kubectl cordon node01 设置了节点不可调度
2. kubectl drain node01 使用drain 命令驱逐node01上的pod
3. kubectl uncordon node01 恢复调度后，新增副本又可以调度到node01

污点与容忍

taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置 nodeSelector 将 pod 调度到具有匹配标签的节点上。

Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上。

node节点设置污点

1. 设置taint

NoSchedule: 一定不能被调度
PreferNoSchedule: 尽量不要调度
NoExecute: 不仅不会调度, 还会驱逐Node上已有的Pod

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:PreferNoSchedule

2. 查看taint

kubectl describe node node1

3. 删除taint:

kubectl taint node node1 key1:NoSchedule-  # 这里的key可以不用指定value
kubectl taint node node1 key1:NoExecute-
kubectl taint node node1 key1-             # 删除指定key所有的effect
kubectl taint node node1 key2:PreferNoSchedule-

示列

设置污点

kubectl taint nodes k8s-node-01 k8s=node:NoSchedule

删除污点

kubectl taint nodes k8s-node-01 k8s:NoSchedule-

设置pod容忍污点

容忍某个污点标签值的节点

参考链接 https://blog.frognew.com/2018/05/taint-and-toleration.html

      containers:
      '''
      tolerations:
      - effect: NoSchedule
        key: app
        operator: Equal
        value: nginx-ingress

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
  tolerationSeconds: 3600

上面的key1 value1 NoSchedule分别对应下面节点设置污点时的值

kubectl taint nodes node1 key1=value1:NoSchedule

• operator: 为 Equal 时只匹配定义的value相应值的节点
• operator的值为Exists将会忽略value值
• tolerationSeconds用于描述Pod调度到node后可以运行的时间，之后会被驱逐。

容忍所有污点的节点

      containers:
      '''
      tolerations:
      - effect: NoSchedule
        operator: Exists

节点标签 Label

查询节点已有的标签

kubectl get node --show-labels=true

打标签

kubectl label nodes [node_name] key1=val1 key2=val2

删除标签

kubectl label nodes [node_name] key1- key2-

集群均衡器

通过 Descheduler 实现 Kubernetes 的二次调度

为什么需要二次调试 Pod

• 一些节点不足或过度使用。
• 原始调度决策不再适用，因为在节点中添加或删除了污点或标签，不再满足 pod/node 亲和性要求。
• 某些节点发生故障，其pod已移至其他节点
• 集群添加新节点

策略介绍

https://cloud.tencent.com/developer/article/1638799

方案实施

https://www.qikqiak.com/post/k8s-cluster-balancer

当 Descheduler 程序决定从节点驱逐 Pod 时，它采用以下常规机制：

• 关键Pod（priorityClassName 设置为 system-cluster-critical 或 system-node-critical）不会被驱逐。
• 永远不会驱逐不属于RC，RS，Deployment或Job的Pod（静态或镜像 Pod 或 独立Pod），因为不会重新创建这些Pod。
• 与 DaemonSets 关联的Pod不会被逐出。
• 永远不会驱逐具有本地存储的 Pod。
• 首先驱逐Best-Effort，再驱逐Burstabl、最后驱逐Guarant 的优先级。
• 带有注释descheduler.alpha.kubernetes.io/evict 的所有类型的Pod都会被逐出。该注释用于覆盖防止驱逐的检查，用户可以选择驱逐哪个 Pod。用户应该知道如何以及是否可以重新创建容器。

注意：PDB 不受 Descheduler 控制

资源对象的备份

以yaml文件方式备份命名空间下所有资源对象

包含 Deployment、DaemonSet、StatefulSet、Ingress、Service、Secret、job、Configmap等

待开始---

强制删除命名空间

删除一直处于 Terminating 状态下的 namespace

下面命令中替换成自己的 namespace 然后执行

kubectl get namespace cattle-system -o json | tr -d "\n" | sed "s/\"finalizers\": \[[^]]\+\]/\"finalizers\": []/" | kubectl replace --raw /api/v1/namespaces/cattle-system/finalize -f -