K8S常规用法

K8S常规用法

1. 标签
2. 标签是什么
    标签是k8s特色的管理方式，便于分类管理资源对象。
   一个标签可以对应多个资源，一个资源也可以有多个标签，它们是多对多的关系。 
   一个资源拥有多个标签，可以实现不同https://so.csdn.net/so/search?q=%E7%BB%B4%E5%BA%A6&spm=1001.2101.3001.7020的管理。 
   可以使用标签https://so.csdn.net/so/search?q=%E9%80%89%E6%8B%A9%E5%99%A8&spm=1001.2101.3001.7020来指定能使用哪些标签。
3. 让pod 飘到指定节点上
   

应用场景 例如 建模应用pod 飘到node2节点上有问题 但是重启pod之后飘到node3节点上 服务正常 此时简单认为node2节点异常 为了方便排查错误需要将pod飘到指定node节点上

https://blog.csdn.net/u010502101/article/details/108817716
2. 指定标签
spec:
nodeSelector:
bigdata-node: bigdata
containers:
- env:
缺点:它仅能基于简单的等值关系定义标签选择器

3. 节点亲和力
   requiredDuringSchedulingIgnoredDuringExecution
   表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。

requiredDuringSchedulingRequiredDuringExecution
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。

preferredDuringSchedulingIgnoredDuringExecution
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。

preferredDuringSchedulingRequiredDuringExecution
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。其中RequiredDuringExecution表示如果后面节点标签发生了变化，满足了条件，则重新调度到满足条件的节点

观察线上环境标签情况
nodeAffinity 节点亲和力
kubectl edit deployment deployment.apps/dmp-prod-dmp-flow-priority -n dmp-prod

4. pod间亲和性和反亲和性

apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity: #亲和性
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:

• name: with-pod-affinity
  image: docker.io/ocpqe/hello-pod
  pod必须部署在一个节点上，这个节点上至少有一个正在运行的pod，这个pod中security=S1

bigdata大数据中间件trino设置反亲和

apiVersion: v1
kind: Pod
metadata:
name: with-pod-antiaffinity
spec:
affinity:
podAntiAffinity: #反亲和性
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: kubernetes.io/hostname
containers:

• name: with-pod-affinity
  image: docker.io/ocpqe/hello-pod
  pod不太会部署在一个节点上，这个节点上正在运行的pod中有security=S2

2. 污点

2.1 污点和标签区别
污点与标签有什么不同呢？这是我们在学习污点时首先要搞清楚的问题。
由于标签和污点工作原理的不同，他们的适用场景也不一样。标签通常用于为 Pod 指定分组，规定了 Pod 只能调度到这些分组里的 node 中，这是一种强制的做法。污点通常用于将 Node 设置为专用节点，默认情况下普通 Pod 是无法调度过来，仅当你在 Pod 中指定了对应的容忍度才能调度。
目前临安服务器情况

● NoSchedule：不能容忍此污点的 Pod 不会被调度到节点上；现有 Pod 不会从节点中逐出。
● PreferNoSchedule：Kubernetes 会避免将不能容忍此污点的 Pod 安排到节点上。
● NoExecute：如果 Pod 已在节点上运行，则会将该 Pod 从节点中逐出；如果尚未在节点上运行，则不会将其安排到节点上。

DMP设置了标签和污点

1. 设置污点只能保证数见pod 可以运行在带有点的服务器 数见pod还有可能飘在到其他服务器上

2. 给数见Pod打了标签让其只能飘到大数据服务器上,

3. 资源限制
   对应容器云位置
   

CPU
0.1代表一颗CPU使用百分之10
1代表使用1颗CPU
request 是pod 希望的最小的配置 如果服务器剩下配置不满足则容器不会在对应节点上跑
但是并不是实际所需要的值 如果不满足条件 pod 状态为Pending
生产中一般是将pod 实际需要的配置设置为 request 以保障pod正常运行limit是最高限制 一旦超过则直接强杀
3.1 按列分析-设置不可调度
临安服务器node3节点内存爆满

如果重启跑在node3节点上pod 不会解决问题 主要是因为重启之后的pod 还是继续运行在node3节点上
通过发现运行在Node3 节点上数据塔台很多 和开发确认过白天平滑重启不影响
先把node3设置为不可调度  kubectl cordon k8s-node-3
让数据塔台pod 飘到其他服务器上

继续观察node3节点内存 发现正常 在将node3设置为可以调度
 kubectl uncordon k8s-node-3

3.1 按列分析-大数据节点内存爆满
临安大数据节点node-9节点爆满服务器都挂了

通过检查发现starrocks-be  trino

得出事故结论: starrocks-be和trino中间件随着时间推移内存会从刚开始几百M 到后面13G如果不重启还要继续增大 有理由怀疑会增大到limit值 而limit设置太高了 30G 两个中间件都有三个副本
和容器云同事确认过30G内存也是正常的 但是服务器配置也就 50G 而已

解决办法:
1调大request值
2.将pod 设置反亲和尽量将pod 平均到每台服务器上
   affinity:
        podAntiAffinity:                   # 工作负载反亲和
          preferredDuringSchedulingIgnoredDuringExecution:    # 尽量满足如下条件
            - podAffinityTerm:
                labelSelector:                       # 选择Pod的标签，与工作负载本身反亲和
                  matchExpressions:
                    - key: app
                      operator: In
                      values:
                        - nginx
                namespaces:
                  - default
                topologyKey: kubernetes.io/hostname     # 在节点上起作用
3.以上办法挺多只能延缓节点爆炸的时间而已解决不了根本问题 原因就在于pod 内存会不停的增长到限制最大值即30G 一台服务器上两个这个pod 服务器也会炸
绝招定时重启pod 释放内存

4. 有状态和无状态区别
   4.1 无状态
   Deployment被设计用来管理无状态服务的pod,每个pod完全一致.什么意思呢?
   无状态服务内的多个Pod创建的顺序是没有顺序的.
   无状态服务内的多个Pod的名称是随机的.pod被重新启动调度后,它的名称与IP都会发生变化.
   无状态服务内的多个Pod背后是共享存储的.
   4.2 有状态
   Deployment组件是为无状态服务而设计的,其中的Pod名称,主机名,存储都是随机,不稳定的,并且Pod的创建与销毁也是无序的.这个设计决定了无状态服务并 不适合数据库领域的应用.
   而Stateful管理有状态的应用,它的Pod有如下特征:
   唯一性: 每个Pod会被分配一个唯一序号.
   顺序性: Pod启动,更新,销毁是按顺序进行.
   稳定的网络标识: Pod主机名,DNS地址不会随着Pod被重新调度而发生变化.
   稳定的持久化存储: Pod被重新调度后,仍然能挂载原有的PV,从而保证了数据的完整性和一致性.
   4.3 举列子说明
   
   

minio rabbitq都是有状态的statefulset 主机名 pod 名称都是有顺序的 并且在重启的时候也是按照顺序依次生成新的pod 然后删除老的pod

dmp-flow-priority 四个副本数 名字是随机的 并且重启也是随机重启 他们是无状态的 带有deployment

4.4 nacos 之所以为有状态原因
nacos本身只会连接mysql 没有涉及到存储 讲道理应该是无状态才对 但是 nacos 看着写法是有状态

参看官网 https://nacos.io/zh-cn/docs/use-nacos-with-kubernetes.html
高级用法:
在高级使用中,Nacos在K8S拥有自动扩容缩容和数据持久特性,请注意如果需要使用这部分功能请使用PVC持久卷,Nacos的自动扩容缩容需要依赖持久卷,以及数据持久化也是一样,本例中使用的是NFS来使用PVC.