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 总结

1. 当node节点刚开始没启动时，kubectl create -f x.yaml无法正常调度，启动了node节点之后，会自动调度到相应节点
2. 创建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

1. 创建一个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
   
   

   

2. 创建一个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 扩容缩容

使用

1. 原本sts副本数为3，缩容kubectl scale --replicas=1 sts nginx-statefulset，使用kubectl get po -w查看缩容过程，可以看到是从后往前删除pod

   

2. 扩容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