yaml文件+各组件介绍
一、YAML基础
YAML是专门用来写配置文件的语言，非常简洁和强大，使用比json更方便。它实质上是一种通用的数据串行化格式。
YAML语法规则：
大小写敏感
使用缩进表示层级关系
缩进时不允许使用Tal键，只允许使用空格
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
”#” 表示注释，从这个字符一直到行尾，都会被解析器忽略
在Kubernetes中，只需要知道两种结构类型即可：
Lists
Maps
1.maps
类似python中的字典，key：value形式
apiVersion: v1
kind: Pod
metadata:
name: kube100-site
labels:
app: web
2.lists
切片，类似python中的列表
args:
-beijing
-shanghai
-shenzhen
-guangzhou
# 等同于json格式中
{
"args": ["beijing", "shanghai", "shenzhen", "guangzhou"]
}
二.pod
1.示例
#test-pod
apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中
kind: Pod #指定创建资源的角色/类型
metadata: #资源的元数据/属性
name: test-pod #资源的名字，在同一个namespace中必须唯一
labels: #设定资源的标签
k8s-app: apache
version: v1
kubernetes.io/cluster-service: "true"
annotations: #自定义注解列表,可以随便写键值对
- name: String #自定义注解名字
- age: 10
spec: #specification of the resource content 指定该资源的内容（最主要）
#1、Always：当容器终止退出后，总是重启容器，默认策略。
#2、OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
#3、Never：当容器终止退出，从不重启容器。
restartPolicy: Always
#当前pod依附于哪个node节点，先给主机打标签kubectl label nodes kube-node1 zone=node1
nodeSelector:
zone: node1
#参考：http://events.jianshu.io/p/e84008d67e86 初始化容器之前需要做的一些操作
#init容器修改或生成的配置，必须用volume挂载到容器中
initContainers:
- image: xx
containers:
- name: test-pod #容器的名字
image: 10.192.21.18:5000/test/chat:latest #容器使用的镜像地址，不写ip就会从dockerhub拉
imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略，
# Always，每次都检查
# Never，每次都不检查（不管本地是否有）
# IfNotPresent，如果本地有就不检查，如果没有就拉取
command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT
args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数
env: #指定容器中的环境变量
- name: str #变量的名字
value: "/etc/run.sh" #变量的值
resources: #资源管理
requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
memory: 32Mi #内存使用量
limits: #资源限制
cpu: 0.5
memory: 1000Mi
ports:
- containerPort: 80 #容器开发对外的端口
name: httpd #名称
protocol: TCP
livenessProbe: #pod内容器健康检查的设置
httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常
path: / #URI地址
port: 80
#host: 127.0.0.1 #主机地址
scheme: HTTP
initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始
timeoutSeconds: 2 #检测访问接口的超时时间，一般2s
periodSeconds: 15 #检查间隔时间
successThreshold: 1 #检查成功1次表示就绪
failureThreshold: 2 #检查失败2次表示未就绪
#也可以用这种方法
#exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常
# command:
# - cat
# - /tmp/health
#也可以用这种方法
#tcpSocket: //通过tcpSocket检查健康
# port: number
lifecycle: #生命周期管理
postStart: #容器运行之前运行的任务
exec:
command:
- 'sh'
- 'yum upgrade -y'
preStop: #容器关闭之前运行的任务，用于优雅关闭应用程序、通知其他系统等等。
exec:
command: ['service httpd stop']
#httpGet: #可以通过http接口发送pod所在ip，提示不能用
#host: monitor.com
#path: /waring
#port: 8080
#scheme: HTTP
volumeMounts: #挂载持久存储卷
- name: volume #挂载设备的名字，与volumes[*].name 需要对应
mountPath: /data #挂载到容器的某个路径下
readOnly: True
volumes: #定义一组挂载设备
- name: volume #定义一个挂载设备的名字
#meptyDir: {}
hostPath:
path: /opt #挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种
#nfs
命令kubectl create -f ./pod.yaml
命令kubectl apply -f ./pod.yaml
两者区别：当修改了yaml文件，可直接用apply命令，直接会覆盖原有镜像
2.k8s中command和docker中entrypoint
1.如果command和args都没写，那么用dockerfile中默认的配置
2.如果command写了，但args没写，那么dockerfile默认命令会被忽略，仅仅执行yaml文件中的
3.如果command没写，但args写了，那么dockerfile中ENTRYPOINT会执行，但调用的是yaml文件的args
4.如果command和args都写了，那么dockerfile默认配置会被忽略，使用yaml文件的配置
3.pod的yaml文件启动顺序
参考：https://www.quwenqing.com/archives/1995.html
1.先挂载对应数据卷
2.env环境变量设置（command中可以引用）
3.initC容器执行
3.执行command或poststart（两者异步，无法确定哪个先执行）
4.执行livenessProbe等健康检测
如k8s部署mysql，会自动启动容器，yaml文件中没有command，如果有的话按照上面规则注意
4.pod几种状态
Pending：挂起，我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件。已经创建了但是没有适合它运行的节点叫做挂起，这其中也包含集群为容器创建网络，或者下载镜像的过程。
Running：Pod内所有的容器都已经被创建，且至少一个容器正在处于运行状态、正在启动状态或者重启状态。
Succeeded：Pod中所以容器都执行成功后退出，并且没有处于重启的容器。
Failed：Pod中所以容器都已退出，但是至少还有一个容器退出时为失败状态。
Unknown：未知状态，所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障，那么apiserver就连不上kubelet，得不到信息了，就会看Unknown
下图对应解释
- namespace:命名空间
- name：pod名称，在同一命名空间下唯一
- ready：0/2证明pod中有2个容器，0个启动，2/2证明可以接受流量
- status：当前pod状态
- restarts：重启次数
三.deployment
3.1 deployment认识
k8s1.2版本之后，引入deployment（无状态应用副本控制器），它不直接管理pod，而是结合rs来管理
主要配置文件，当创建dp，会自动创建rs、pod
apiVersion: apps/v1
kind: Deployment
metadata: #deploy元数据
name: pc-deployment
namespace: dev
spec: #定义副本数量，deploy的标签
replicas: 3
selector:
matchLabels:
app: nginx-pod
template: #pod相关
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
当使用命令kubectl create -f xx.yaml后，再使用命令查看rskubectl get rs -n dev
3.2 deployment和rs、rc区别
rc：副本控制器，只能管理pod的数量，使用标签选择器
apiVersion: v1
kind: ReplicationController
metadata:
name: my-nginx
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
rs：副本控制器，是rc的升级版本，变成标签集合选择器
deployment：无状态应用部署， 完全不需要保存任何数据，随时可以重启发布回滚
apiVersion: apps/v1
kind: Deployment
metadata: #deploy元数据
name: pc-deployment
namespace: dev
spec: #定义副本数量，deploy的标签
replicas: 3
selector:
matchLabels:
app: nginx-pod
template: #pod相关
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.17.1
3.3 相关命令解析
[root@master1 ~]# kubectl get deploy -owide -n kube-system
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
calico-kube-controllers 1/1 1 1 11d calico-kube-controllers docker.io/calico/kube-controllers:v3.19.4 k8s-app=calico-kube-controllers
- name：deployment名称
- ready：管理的pod启动数量/pod总数量
- up-to-date：达到期望值的pod数量
- available：可用的pod数量
- containers：容器名称
- images：镜像名称
- selector：标签
3.4 更新
当改变spec.template下面的内容，会重新创建rs，重新生成版本(触发上线)，扩容缩容是不会触发上线的
更新完yaml文件之后 kubectl replace -f xx.yaml
3.5 回滚
1.查看历史记录
kubectl rollout history deploy 现在的name名称
2.回滚到上一版本
kubectl rollout undo deploy 现在的name名称
3.查看指定版本的信息
kubectl rollout history deploy 现在的name名称 --revision=4
4.回滚到指定版本
kubectl rollout undo deploy 现在的name名称 --revision=4
5.查看回滚过程状态
kubectl rollout status deploy deploy名称
3.6 扩容
1.扩容缩容（修改pod副本数）
kubectl scale --replicas=2 deploy nginx
3.7 暂停和更新
多次修改，一次更新
#暂停
kubectl rollout pause deploy nginx # 暂停名为nginx的deploy
#第一次修改(更新镜像)
kubectl set image deploy nginx nginx=xxx --record
#第二次修改(更新资源，requests为最小占用、limits为最大占用)
kubectl set resources deploy nginx -c nginx --limits=cpu=200m,memory=128Mi --requests=cpu=10m,memory=16Mi
#恢复
kubectl rollout resume deploy nginx
3.8 总结
- 当node节点刚开始没启动时，
kubectl create -f x.yaml无法正常调度，启动了node节点之后，会自动调度到相应节点 - 创建deployment时，名称为pc-deployment，那么rs的名称为pc-deployment-xxxrs，pod的名称为pc-deployment-xxxrs-xxxpod(rs和pod)
四.satefulset
4.1 认识
satefulset：有状态应用副本集控制器
总结：
ps：创建完成后，pod名称为sts名称-序号，pod的DNS域名为pod名称.svc名称，pod的全DNS域名为pod名称.svc名称.命名空间.svc.cluster.local
1.什么是无状态服务
1. 认为pod都是一样的，创建的副本都是一样的
2. 没有顺序要求 #没有启动顺序要求
3.不用考虑在那个node上运行
4. 随意进行伸缩和扩展
2.什么是有状态服务
让每个pod都是独立的，c保持pod的启动顺序和唯一性（假设部署mysql主从，要固定对方的ip，一旦ip改动将无法正常使用，此时就要用到satefulset，是通过无头svc，也就是域名来访问）
两者区别：
4.2 创建一个sts
-
创建一个service（service.yaml）
apiVersion: v1 kind: Service metadata: name: nginx # svc名称 labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None #无头svc，不会被kube-proxy加入发现且加入路由规则 selector: # 会绑定app=nginx标签的pod app: nginx
-
创建一个sts
apiVersion: apps/v1 kind: StatefulSet metadata: name: nginx-statefulset namespace: default spec: # 指定使用的service serviceName: nginx #必须要有，是headless的名称 replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: 192.168.181.131:5000/nginx:latest ports: - containerPort: 80
查看pods，可看到pod的名称为sts名称-x
4.3 创建busybox
busybox是继承了linux常用命令的软件，一般用来测试使用：https://blog.csdn.net/weixin_44896406/article/details/120916356
yaml文件：
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: default
spec:
containers:
- name: busybox
image: busybox:1.34
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
restartPolicy: Always
创建好之后，kubectl exec -it busybox -- sh进入容器，通过nslookup pod得到的域名方式查看DNS映射关系
由图看到，创建sts后，pod的域名和ip是一一对应的，当重启sts后，或者当前node故障，pod的ip发生变化，但是域名生成规则是固定的，不会变化
4.4 扩容缩容
使用
-
原本sts副本数为3，缩容
kubectl scale --replicas=1 sts nginx-statefulset，使用kubectl get po -w查看缩容过程，可以看到是从后往前删除pod
-
扩容
kubectl scale --replicas=3 sts nginx-statefulset,看到是从前往后添加pod，只有pod1为ready状态才会启用pod2
4.5 更新
参考：https://blog.csdn.net/VIP099/article/details/124785422
和deployment相同，只有更新了yaml文件的spec.template下的内容，再使用命令kubectl replace -f xx.yaml才会触发更新操作。
更新策略updateStrategy为rollingUpdate:
statefulset controller会删除并创建statefulset的相关pod对象，其处理顺序和statefulset终止pod的顺序一样，即从最大的pod开始重建，每次更新一个pod
更新策略为ondelete
statefulset controller不会自动更新statefulset的pod示例，而是需要用户手动删除这些pod(执行kubectl delete -f po po名称)触发statefulset controller创建新的pod来弥补
partitioned，用户指定序号，大于等于此序号的pod实例会被升级，这也是灰度发布
4.6 级联删除和非级联删除
satefulset默认是级联删除：删除sts的同时会删除对应的pod
kubectl delete sts sts名称
非级联删除：删除sts后，pod会变成孤儿pod，此时再删除pod不会再被重建
kubectl delete sts sts名称 --cascade=false
4.7 相关命令
kubectl get po -w #查看pod的变化
kubectl get po -l app=nginx -w #通过labels查看相关变化
五.daemonset
参考：https://www.jianshu.com/p/9e6ce0e78d2e
DaemonSet 的主要作用，是在 Kubernetes 集群里，运行一个 Daemon Pod。 DaemonSet 只管理 Pod 对象，然后通过 nodeAffinity 和 Toleration 这两个调度器的小功能，保证了每个节点上有且只有一个 Pod。
daemonset没有replicas这一说法，会在每个node上有且仅有一个replicas
dademonset会时刻监控含对应标签的node进行调度。 yaml文件中nodeselector中配置ds=true，然后kubectl label node master ds=true,可自动调度到master节点上，使用 kubectl label node master ds-可去除标签，
三个主要特征：
- 每个节点上只有一个这样的 Pod 实例。
- 当有新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被创建出来。
- 当旧节点被删除后，它上面的 Pod 也相应地会被回收掉。
应用场景：
- calico网络插件，需要在每个节点上运行，就是daemonset创建的，因此之后新加入的node或者master节点都会自动创建calico相关pod
- kube-proxy也是在每个节点上都有
六.labels和selector
此处需要了解亲和和反亲和：http://www.yaotu.net/biancheng/389.html
