目录
Pod 资源
spec.containers <[]object>
- name <string>
image <string>
imagePullPolicy <string> 镜像获取策略
imagesPullPolicy：IfNotPresen # 行8解释
Always总是去远程仓库拉取, Never从来不去远程仓库拉取, IfNotPresent如果本地仓库不存在就去下载
默认情况：如果镜像指定为latest版本，那默认为Always，如果不是那默认就是IfNotPresent
如果镜像指定为latest版本，但不想去远程拉取，那么可以加上imagesPullPolicy：IfNotPresent
spec字段常用的选项：
spec.containers <[]object>
spec.containers.name <string> #pod的名称，必须字段，名称唯一且对象创建后不可以被修改
spec.containers.image <string> #镜像仓库的路径/镜像的名称：镜像的标签
spec.containers.image.imagePullPolicy <string> #镜像的下载策略。有三种：Always(总是去仓库下载) ,Never(从不去仓库下载) , IfNotPresent(如果本地没有就去仓库下载) ，默认是"IfNotPresent" 但是，如果镜像的标签是latest，则总会是"Always，并且对象一旦被创建，这个字段不允许被改变
spec.containers.ports: #容器公开的端口列表。在这里公开端口可以为系统提供关于容器使用的网络连接的额外信息，但主要是提供信息。在这里不指定端口不会阻止该端口被公开。任何监听容器内默认的“0.0.0.0”地址的端口都可以从网络访问
spec.containers.ports.containerPort <integer> -required- #pod暴露的端口，此端口仅是额外的信息，对端口是否被暴露没有影响
spec.containers.ports.hostPort <integer> #主机上公开的端口
spec.containers.ports.protocol <string> #端口的协议
spec.containers.ports.hostIP <string> #指定要绑定的主机
spec.containers.command <[]string> #运行的程序，类似于docker中的entrypiont,并且这里的命令不会运行在shell中，如果没有这个字段docker镜像会运行自己entrypiont中的指令
spec.containers.args <[]string> #向docker镜像中传递参数 如果定义了这个字段，docker镜像中cmd命令不会被执行，如果引用变量使用$(VAR_NAME)格式引用，如果想使用命令引用的的方式，需要使用$$(VAR_NAME)方式来引用 #关于args和command的官方文档链接：https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/
pod.spec.containers.volumeMounts pod.spec.containers.volumeMounts.name pod.spec.containers.volumeMounts.mountPath #可以被容器挂载的存储卷的路径，路径不能包含':' 符号
pod.spec.containers.volumeMounts.subPath #可以被容器挂载的存储卷的路径，并且不会覆盖挂载点中的文件
pod.spec.containers.volumeMounts.readOnly #是否只读，默认为false
pod.spec.containers.resources
spec.containers.resources.limits #资源限制
spec.containers.resources.limits.cpu ： CPU 上限， 可以短暂超过， 容器也不会被停止 spec.containers.resources.limits.memory ： 内存上限， 不可以超过； 如果超过， 容器可能会被终止或调度到其他资源充足的机器上
spec.containers.resources.requests #资源需求
spec.containers.resources.requests.cpu ： CPU 请求， 也是调度 CPU 资源的依据， 可以超过
spec.containers.resources.requests.memory ： 内存请求， 也是调度内存资源的依据， 可以超过； 但如果超过， 容器可能会在 Node 内存不足时清理
spec.containers.liveness：存活性探测
spec.containers.readiness：就绪性探测
标签
每个资源都可以有多个标签，每个标签也可以添加到多个对象资源之上。
标签格式：key= value 注：键值最多使用63个字符
key: 字母 、 数字 、
-、.
value: 可以为空，只能字母或数字开头结尾，中间可使用-、.
查看pods 的标签：
[root@master manifests]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myapp-84cd4b7f95-44qch 1/1 Running 0 7d5h pod-template-hash=84cd4b7f95,run=myapp
myapp-84cd4b7f95-fzvsd 1/1 Running 0 7d5h pod-template-hash=84cd4b7f95,run=myapp
myapp-84cd4b7f95-mlphg 1/1 Running 0 7d5h pod-template-hash=84cd4b7f95,run=myapp
nginx-deploy-7689897d8d-lf8p7 1/1 Running 0 7d6h pod-template-hash=7689897d8d,run=nginx-deploy
pod-demo 2/2 Running 0 29s app=myapp,tier=frontend
使用 -l 参数，来过滤标签
[root@master manifests]# kubectl get pods -l app
NAME READY STATUS RESTARTS AGE
pod-demo 2/2 Running 0 3m21s
给资源打标签
使用 kubectl label
Usage:
kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [options]
实例：
kubectl label pods pod-demo release=canary #给pod-demo打标签
kubectl label pods pod-demo release=stable --overwrite #修改pod-demo的release标签
标签选择器
- 等之关系：=、==、!= 来进行操作
- 集合关系
KEY in (VALUE1,VALUE2,...)
KEY notin (VALUE1,VALUE2,...)
[root@master manifests]# kubectl get pods -l release
NAME READY STATUS RESTARTS AGE
nginx-deploy-7689897d8d-lf8p7 1/1 Running 0 7d6h
pod-demo 2/2 Running 0 11m
[root@master manifests]# kubectl get pods -l release=canary
NAME READY STATUS RESTARTS AGE
nginx-deploy-7689897d8d-lf8p7 1/1 Running 0 7d6h
[root@master manifests]# kubectl get pods -l release,app
NAME READY STATUS RESTARTS AGE
pod-demo 2/2 Running 0 12m
[root@master manifests]# kubectl get pods -l release=stable,app=myapp
NAME READY STATUS RESTARTS AGE
pod-demo 2/2 Running 0 12m
许多资源支持内嵌字段定义其使用的标签选择器：
-
matchLabels: 直接给定键值
-
matchExpressions: 基于给定的表达式来定义使用标签选择器，{key:"KEY", operator: "OPERATOR", values: [VAL1,VAL2,...]}
操作符:
In, NotIn: values 字段的值必须为非空列表；
Exists, NotExists: values字段的值必须为空列表；
nodeSelector <map[string]string>
节点标签选择器，是可以影响pods调度算法的。
案例:
[root@master manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deploy-7689897d8d-lf8p7 1/1 Running 0 8d 10.244.3.2 node02.kubernetes <none> <none>
[root@master manifests]# kubectl delete -f pod-demo.yaml
pod "pod-demo" deleted
[root@master manifests]# vim pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-demo
namespace: default
labels:
app: myapp
tier: frontend #自行定义备注，此处意为层级架构中的最前端
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
- "sleep 3600"
nodeSelector:
disktype: ssd
[root@master manifests]# kubectl create -f pod-demo.yaml
pod/pod-demo created
[root@master manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-demo 2/2 Running 0 4s 10.244.3.10 node01.kubernetes <none> <none>
nodeName
指定调度到节点的名称
annoitations （pod的注解信息，可用kubectl describe pod xxx查看）
与label不同的是，不能用于挑选资源对象，仅用于为对象提供"元数据"，某些场景是必须的，无键值长度限制。
Pod 生命周期
Pod生命周期主要分为两个阶段：
1. 初始化容器初始化阶段
2. 主容器正常运行阶段
Pod 状态：
1. 首先Pod进入初始化阶段，使用初始化容器完成初始化，可以有多个初始化容器，但是串行。（上图中inin c）
2. 初始化之后主容器进入正式运行阶段。
3. 主容器启动之后，会执行一次命令，就是 'post start'，也就是启动后钩子，执行结束后就退出了。
4. 命令执行只有，会有一个主容器存活状态检测，就是'liveness probe'。
5. 同时也会做就容器就绪性检测，检测主容器是否正常运行，就是 'readiness probe'。
6. 当主容器要退出的时候，也会有个结束前执行的命令，就是 'pre stop'，结束前钩子，这个Pod就退出。
pod容器探测：
-
liveness probe # 用于探测主容器是否存活（存活性检测）
-
readiness probe # 判定容器中的主进程是否就绪，是否对外提供服务（服务就绪性检测）
无论哪一种，都支持三种。
- 自定义命令
- 向指定的TCP套接字发请求
- 向指定的HTTP服务发请求
Pod 状态：
Pending : 挂起状态，调度尚未完成，没有适合创建的节点，不满足存活的状态。
Runing : 运行状态
Failed : 失败状态
Succeeded : 成功状态
Unknown : 未知状态，有可能是目标node上的kubectl出现故障
创建Pod所经历的状态
1. 当用户创建Pod的时候，会去请求提交给apiserver，然后会把目标状态保存在etcd中，
2. 然后 apiserver 会去请求 scheduler进行调度，并且把调度的结果保存在ETCD中之前保存的Pod状态中。
3. 一旦存在ETCD中发生更新，假如调度在node01上，node01 上的kubelet通过apiserver当中状态变化会知道。
restartPolicy:(pod的重启策略)
Always（总是重启）, OnFailure（只有状态为错误时才重启）, Never（不重启）。默认是Always
pod状态探测
新加入pod，会有一定的启动时间，所以一定要做存活性探测和就绪性探测，否则会造成一段时间内的访问异常
探针类型有三种：
1. ExecAction（直接执行自定义的命令）
2. TCPsocketAction
3. HTTPGetAction
这三种探针，livenessProbe 和 readinessProbe 都可以使用。
livenessProbe 状态探测
livenessProbe exec 测试
创建Pod的yaml文件：
[root@master manifests]# cat liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
containers:
- name: liveness-exec-container
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 3600"] # 生成存活性文件
livenessProbe:
exec:
command: ["test", "-e", "/tmp/healthy"] # 使用命令探测文件是否存在
initialDelaySeconds: 1 # 容器启动后，多久开始探测，单位秒
periodSeconds: 3 # 每次探测间隔时间，单位秒
successThreshold: 1 # 成功几次
failureThreshold: 2 # 失败几次后重启
timeoutSeconds: 2 # 开始探测后的超时时间，单位秒
[root@master manifests]# kubectl create -f liveness-exec.yaml
pod/liveness-exec-pod created
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-exec-pod 1/1 Running 0 4s
等一会之后：
[root@master manifests]#kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-exec-pod 1/1 Running 1 2m20s
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-exec-pod 1/1 Running 2 2m40s
查看详细信息：
[root@master manifests]# kubectl describe pod liveness-exec-pod
Name: liveness-exec-pod
Namespace: default
Priority: 0
Node: node03.kubernetes/10.0.20.23
Start Time: Fri, 19 Jul 2019 11:13:19 +0800
Labels: <none>
Annotations: <none>
Status: Running
IP: 10.244.1.8
Containers:
liveness-exec-container:
Container ID: docker://e028a5c4796c9e138e9669292f5b82fc76244017463039ef2141dab3da9d5cdd
Image: busybox:latest
Image ID: docker-pullable://busybox@sha256:c94cf1b87ccb80f2e6414ef913c748b105060debda482058d2b8d0fce39f11b9
Port: <none>
Host Port: <none>
Command:
/bin/sh
-c
touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 3600
State: Running
Started: Fri, 19 Jul 2019 11:14:34 +0800
Last State: Terminated
Reason: Error # 这里提示错误
Exit Code: 137
Started: Fri, 19 Jul 2019 11:13:20 +0800
Finished: Fri, 19 Jul 2019 11:14:34 +0800
Ready: True
Restart Count: 1 # 提示被重启过一次
Liveness: exec [test -e /tmp/healthy] delay=1s timeout=2s period=10s #success=1 #failure=2
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-bc86p (ro)
........
........
livenessProbe httpGet 测试
创建Pod的yaml文件：
[root@master manifests]# cat liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: ikubernetes/myapp:v1 # 此镜像自带80端口
imagePullPolicy: IfNotPresent
ports:
- name: http # 这里定义映射端口名称
containerPort: 80 # 指定端口
livenessProbe:
httpGet:
port: http # 这里直接使用定义的端口名称即可
path: /index.html # 定义探测http对应的路径
initialDelaySeconds: 1
periodSeconds: 3
successThreshold: 1
failureThreshold: 2
timeoutSeconds: 2
[root@master manifests]# kubectl create -f liveness-httpget.yaml
pod/liveness-httpget-pod created
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-httpget-pod 1/1 Running 0 3s
手动进入到容器中，然后删除index.html 文件
[root@master ~]# kubectl exec -it liveness-httpget-pod -- /bin/sh
/ # rm -f /usr/share/nginx/html/index.html
/ # command terminated with exit code 137
再来查看刚刚创建的pod状态：
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness-httpget-pod 1/1 Running 1 7m14s # 这里可以看到已经被重启过一次了
[root@master manifests]# kubectl describe pods liveness-httpget-pod # 查看详细信息
Name: liveness-httpget-pod
Namespace: default
Priority: 0
Node: node02.kubernetes/10.0.20.22
Start Time: Fri, 19 Jul 2019 11:26:56 +0800
Labels: <none>
Annotations: <none>
Status: Running
IP: 10.244.2.6
Containers:
liveness-httpget-container:
Container ID: docker://39d3905acd7dac561905e77772522e652843dc3f2e0023a07586d3db088ca87f
Image: ikubernetes/myapp:v1
Image ID: docker-pullable://ikubernetes/myapp@sha256:9c3dc30b5219788b2b8a4b065f548b922a34479577befb54b03330999d30d513
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Fri, 19 Jul 2019 11:29:06 +0800
Last State: Terminated # 状态不正常
Reason: Completed
Exit Code: 0
Started: Fri, 19 Jul 2019 11:26:57 +0800
Finished: Fri, 19 Jul 2019 11:29:06 +0800
Ready: True
Restart Count: 1 # 这里看到被重启过一次
Liveness: http-get http://:http/index.html delay=1s timeout=2s period=3s #success=1 #failure=2
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-bc86p (ro)
.... ....
.... ....
这里只会被重启过一次，因为当readinessProbe侦察到容器不处于就绪状态后，就会重启容器，重启的容器中index.html 文件又会被重新生产。
readinessProbe 就绪性探针
创建Pod的yaml文件，配置readinessProbe就绪性探针：
[root@master manifests]# cat readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
successThreshold: 1
failureThreshold: 2
timeoutSeconds: 2
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget-pod 1/1 Running 0 53s
进入到 readiness-httpget-pod 中，手动删除index.html 主页文件，再次查看：
[root@master ~]# kubectl exec -it readiness-httpget-pod -- /bin/sh
/ # rm -rf /usr/share/nginx/html/index.html
/ # ps aux
PID USER TIME COMMAND
1 root 0:00 nginx: master process nginx -g daemon off; # nginx依然运行这
6 nginx 0:00 nginx: worker process
7 root 0:00 /bin/sh
13 root 0:00 ps aux
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget-pod 0/1 Running 0 60s # 就绪状态的pod为 0 个
[root@master manifests]# kubectl describe pods readiness-httpget-pod
Name: readiness-httpget-pod
Namespace: default
Priority: 0
Node: node03.kubernetes/10.0.20.23
Start Time: Mon, 22 Jul 2019 09:09:50 +0800
Labels: <none>
Annotations: <none>
Status: Running
IP: 10.244.1.9
Containers:
readiness-httpget-container:
Container ID: docker://71009463c970b6712d97c8692990caa8c2192841b6e075a1d0db9ac15a2d1cd7
Image: ikubernetes/myapp:v1
Image ID: docker-pullable://ikubernetes/myapp@sha256:9c3dc30b5219788b2b8a4b065f548b922a34479577befb54b03330999d30d513
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 22 Jul 2019 09:09:51 +0800
Ready: False
Restart Count: 0
Readiness: http-get http://:http/index.html delay=1s timeout=2s period=3s #success=1 #failure=2
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-bc86p (ro)
Conditions:
Type Status
Initialized True
Ready False # 详细信息中，显示为错误。
ContainersReady False
PodScheduled True
.... ....
.... ....
当就绪性探针发现此Pod不可用时，service 调度会把此pod剔除集群
手动此创建Pod中的index.html文件：
/ # echo 'hi' > /usr/share/nginx/html/index.html
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget-pod 1/1 Running 0 118s
已经恢复，此时service 又会把此Pod 重新加入到集群中。
Pod 控制器
-
ReplicaSet:(可简写为：rs)
- 用户期望的Pod副本数量，支持多删少补
- 标签选择器，一遍选择自己管理和控制Pod副本
- Pod资源模板来完成Pod资源的新建
-
Deployment:（重点，可简写为：deploy，创建一个deploy会自动生成一个rs）
- 工作在ReplicaSet之上，不直接控制Pod，而是控制ReplicaSet
- 支持滚动更新和回滚等， 可滚动更新或回滚
- 提供声明式配置功能
-
DaemonSet（简写ds）
- 无状态的，必须是守护进程类的，持续运行
- 确保kubernetes所有节点只运行一个Pod
- 保障系统级的后台任务
- 只能管控无状态应用，关注群体，不关注个体
-
Job
- 只能执行一次性的作业，未完成任务异常停止，会重建。
-
Cronjob
- 周期性执行，不执行不启动
-
StatefulSet
- 管理有状态应用，新增节点时会进行必要的初始化，如redis，mysql等。
-
TPR
1.Third Party Resources, 1.2 版本开始能用，1.7版本后不可用
第三方资源 -
CDR
Custom Defined Resource, 1.8 版本之后可用
第三方资源
ReplicaSet 控制器
创建一个ReplicaSet清单文件
[root@master manifests]# cat rs-demo.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp
namespace: default
spec:
replicas: 2 # Pod 副本数为 2
selector:
matchLabels: # 定义标签选择器，如只有一个标签，那可以省略
app: myapp
release: canary
template: # 这里以下定义的和一个单独的Pod清单文件一样
metadata: # 定义Pod对应的标签，会被ReplicaSet控制器选择
name: myapp-pod
namespace: default
labels:
app: myapp
release: canary
environment: qa
spec:
containers:
- name: myapp-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
[root@master manifests]# kubectl create -f rs-demo.yaml
replicaset.apps/myapp created
[root@master manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-k4m9l 1/1 Running 0 27s 10.244.1.13 node03.kubernetes <none> <none>
myapp-p9dk9 1/1 Running 0 27s 10.244.3.14 node01.kubernetes <none> <none>
两个副本的Pod已经被创建。
可以直接使用kubectl edit 来编辑：
[root@master manifests]# kubectl edit rs myapp
replicaset.extensions/myapp edited # 这里打开后，把replicas的值变更为3，也就是增加一个后。
[root@master manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-p9dk9 1/1 Running 0 14m 10.244.3.14 node01.kubernetes <none> <none>
myapp-vjnlq 1/1 Running 0 8s 10.244.1.14 node03.kubernetes <none> <none>
myapp-wl9nh 1/1 Running 0 10m 10.244.2.10 node02.kubernetes <none> <none> # 这里立刻就会再次创建一个Pod 出来
道理相同，减少replicas的数量的时候，Pod对应的数量也会减少，、
也可以直接编辑对应的Pod版本，只是编辑后不会自动更新，但当手动删除一个Pod的时候，再次自动创建新的Pod的时候，就会更新清单中的Pod。
[root@master manifests]# kubectl edit rs myapp
replicaset.extensions/myapp edited
[root@master manifests]# kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myapp 3 3 3 15m myapp-container ikubernetes/myapp:v2 app=myapp,release=canary
[root@master manifests]# curl 10.244.3.14
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@master manifests]# kubectl delete pods myapp-p9dk9
pod "myapp-p9dk9" deleted
[root@master manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-fwnwz 1/1 Running 0 14s 10.244.3.15 node01.kubernetes <none> <none>
myapp-vjnlq 1/1 Running 0 2m33s 10.244.1.14 node03.kubernetes <none> <none>
myapp-wl9nh 1/1 Running 0 12m 10.244.2.10 node02.kubernetes <none> <none>
[root@master manifests]# curl 10.244.3.15
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>
基于这种策略，可以实现蓝绿发布，具体实现如下图：
Deployment 控制器
Deployment控制器的特性：
-
更新策略 （spec字段下的strategy下的rollingUpdate）
-
depoly只需要由用户指定在pod模板中要改动的内容交由其自动完成更新，更新应用程序的规模也只需要修改期望的副本数量，余下的事情交给deploy控制器即可。
-
deploy控制器支持两种更新策略：滚动更新和重新创建，默认为滚动更新。重新创建即首先删除现有的pod对象，而后由控制器基于新模板重新创建出新版本资源对象。通常，只应该在应用的新旧版本不兼容时才会使用recreate策略。
-
滚动更新在删除一部分旧版本pod资源的同时，补充创建一部分新版本的pod对象进行应用升级，其优势是升级期间，容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形。
-
deploy控制器的滚动更新操作并非在同一个rs控制器对象下删除并创建pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的pod对象数量不断减少的同时，新控制器的pod对象数量不断增加，直到旧控制器不再拥有pod对象，而新控制器的副本数量变得完全符合期望值为止。
-
滚动更新时，应用升级期间还要确保可用的pod对象数量不低于某阈值以确保可以持续处理客户端的服务请求，变动的方式和pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和spec.rollingUpdate.maxUnavailable两个属性协同进行定义。
-
maxSurge：指定升级期间存在的总pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是一个期望值的百分比
-
maxUnavailable：升级期间正常可用的pod副本数（包括新旧版本）最多不能低于期望数值的个数，其值可以是0或正整数，也可以是一个期望值的百分比；默认值为1.
-
maxSurge和maxUnavailable属性的值不可同时为0，否则pod对象的副本数在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。
-
配置时，用户还可以使用deploy控制器的spec.minReadySeconds属性来控制应用的升级速度。新旧更替过程中，新创建的pod对象一旦成功响应就绪探测即被视为可用，而后即可立即开始下一轮的替换操作。而spec.minReadySeconds能够定义在新的pod对象来让k8s在每次创建出pod资源后都要等上一段时长后再开始下一轮的更替，这个时间长度的理想值是等到pod对象中的应用已经可以接受并处理请求流量。
-
deploy控制器也支持用户保留其滚动更新历史中的旧rs对象版本，控制器可保存的历史版本数量由spec.revisionHistoryLimit属性进行定义。在创建deploy对象时使用“--record”选项来保存版本升级的历史。
-
-
升级deploy
- 修改pod模板相关的配置参数便能完成deploy控制器资源的更新，对deploy控制器资源的修改尤其适合使用apply和patch命令来进行；
-
金丝雀发布
- deploy控制器还支持自定义控制更新过程中的滚动节奏，如暂停（pause）或继续（resume）更新操作，尤其时借助于maxSurge和maxUnavailable属性还能实现更为精巧的过程控制。例如，待第一批新pod对象创建完成后立即暂停更新过程，此时，仅存在一小部分新版本的应用，主体部分还是旧版本。然后再根据用户特征精心筛选出小部分用户的请求路由至新版本的pod应用，并持续观察其是否能稳定低按期望的方式运行。确定没有问题后再继续完成余下pod资源的滚动更新，否则立即回滚更新操作，这便是金丝雀发布。
-
回滚deploy控制器下的应用发布
- 若因各种原因导致滚动更新无法正常进行，则应将应用回滚到之前的版本，或者回滚到由用户指定的历史记录中的版本，可使用命令“kubectl rollout undo”完成，也可使用选项“--to-version=*”来指定版本。回滚操作中，其revision记录中的信息会发生变动，回滚操作会被当作一次滚动更新追加进历史记录中，而被回滚的条目则会被删除。需要注意的是，如果此前的滚动更新过程处于暂停状态，那么回滚操作就需要先将pod模板的版本改回到之前的版本，然后继续更新，否则，其将一直处于暂停状态无法回滚。
-
扩容和缩容
- 通过修改spec.replicas即可修改deploy中pod资源副本数量，它将实时作用于控制器并直接生效。deploy是声明式配置，replicas属性的值可直接修改资源配置文件，然后使用kubectl apply进行应用，也可以使用kubectl edit对其进行实时修改。而前一种方式能够将修改结果予以长期留存。另外，kubectl scale命令是专用于扩展某些控制器类型的应用规模的，包括deploy和job等。而deploy通过replicaset控制其pod资源，因此扩缩容的方式是相同的。
deployment与replicasets之间的关系：
Deployment是置于replicaSets控制器之上的，replicasets控制底层pod如图所示
这里直接使用声明式创建，使用kubectl apply命令
首先创建清单
root@master manifests]# cat deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deploy
namespace: default
spec:
replicas: 2 # 副本数为 2
selector:
matchLabels:
app: myapp
release: canary
template:
metadata:
labels:
app: myapp
release: canary
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
[root@master manifests]# kubectl apply -f deploy-demo.yaml
deployment.apps/myapp-deploy created
查看：
root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-f4db5d79c-md2kk 1/1 Running 0 4s
myapp-deploy-f4db5d79c-wwx5n 1/1 Running 0 4s
[root@master manifests]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-deploy 2/2 2 2 11s
[root@master manifests]# kubectl get rs
NAME DESIRED CURRENT READY AGE
myapp-deploy-f4db5d79c 2 2 2 43s
上方rs即为创建deploy而自动生成的rs，f4db5d79c为模板的hash值，用于追踪关联模板
- 2个Pod创建成功并正常运行
- Deployment 正常
- Deployment 会自动创建一个ReplicaSet，通过管理ReplicaSet，ReplicaSet再去管理Pod。
- Pod的名称是Deployment名称加上ReplicaSet最后面生产的hash值，再跟上自己的Hash值组成
查看 deployment 详细信息
root@master manifests]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-deploy 3/3 3 3 2m34s
[root@master manifests]# kubectl describe deploy myapp-deploy
Name: myapp-deploy
Namespace: default
CreationTimestamp: Tue, 23 Jul 2019 17:05:49 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1 # 每次的变化，都会被保存在 Annotations当中
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"myapp-deploy","namespace":"default"},"spec":{"replicas":3...
Selector: app=myapp,release=canary
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate # 默认的更新策略，滚动更新
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge # 最大不可用是25%，最大可用是25%，不足一个的时候，补足一个
Pod Template:
Labels: app=myapp
release=canary
Containers:
myapp:
Image: ikubernetes/myapp:v1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Progressing True NewReplicaSetAvailable
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: myapp-deploy-f4db5d79c (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 3m15s deployment-controller Scaled up replica set myapp-deploy-f4db5d79c to 2
Normal ScalingReplicaSet 50s deployment-controller Scaled up replica set myapp-deploy-f4db5d79c to 3
测试滚动更新
在一个窗口上来监控标签 app=myapp 的Pod
[root@master manifests]# kubectl get pods -l app=myapp -w # 这里执行后，会一直等待不动，知道有变化才会有更新
NAME READY STATUS RESTARTS AGE
myapp-deploy-f4db5d79c-cvvl6 1/1 Running 0 2m20s
myapp-deploy-f4db5d79c-md2kk 1/1 Running 0 4m45s
myapp-deploy-f4db5d79c-wwx5n 1/1 Running 0 4m45s
在另一个窗口，重新编辑清单deploy-demo.yaml文件中的副本数为 5
[root@master manifests]# cat deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deploy
namespace: default
spec:
replicas: 5 # 这里副本数修改为 5
selector:
matchLabels:
app: myapp
release: canary
template:
metadata:
labels:
app: myapp
release: canary
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v2
ports:
- name: http
containerPort: 80
修改yaml文件外, 其他修改控制器方法
kubectl patch deployments myapp-deploy -p '{"spec":{"replicas":5}}'
kubectl patch deploy myapp-deploy -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'
然后直接使用kubectl apply命令 声明式方式来变更
[root@master manifests]# kubectl apply -f deploy-demo.yaml
deployment.apps/myapp-deploy configured
当执行完成后，监控的窗口就会出现变化
[root@master manifests]# kubectl get pods -l app=myapp -w
NAME READY STATUS RESTARTS AGE
myapp-deploy-f4db5d79c-cvvl6 1/1 Running 0 2m20s
myapp-deploy-f4db5d79c-md2kk 1/1 Running 0 4m45s
myapp-deploy-f4db5d79c-wwx5n 1/1 Running 0 4m45s
myapp-deploy-f4db5d79c-cvvl6 1/1 Terminating 0 3m26s
myapp-deploy-55b78d8548-zsl5d 0/1 Pending 0 0s
myapp-deploy-55b78d8548-zsl5d 0/1 Pending 0 0s
myapp-deploy-55b78d8548-zsl5d 0/1 ContainerCreating 0 0s
myapp-deploy-f4db5d79c-cvvl6 0/1 Terminating 0 3m27s
myapp-deploy-55b78d8548-zsl5d 1/1 Running 0 1s
myapp-deploy-f4db5d79c-md2kk 1/1 Terminating 0 5m52s
myapp-deploy-55b78d8548-l264b 0/1 Pending 0 0s
myapp-deploy-55b78d8548-l264b 0/1 Pending 0 0s
myapp-deploy-55b78d8548-l264b 0/1 ContainerCreating 0 0s
myapp-deploy-f4db5d79c-cvvl6 0/1 Terminating 0 3m28s
myapp-deploy-f4db5d79c-cvvl6 0/1 Terminating 0 3m28s
myapp-deploy-f4db5d79c-md2kk 0/1 Terminating 0 5m53s
myapp-deploy-55b78d8548-l264b 1/1 Running 0 2s
myapp-deploy-f4db5d79c-wwx5n 1/1 Terminating 0 5m54s
myapp-deploy-f4db5d79c-wwx5n 0/1 Terminating 0 5m54s
myapp-deploy-f4db5d79c-md2kk 0/1 Terminating 0 6m1s
myapp-deploy-f4db5d79c-md2kk 0/1 Terminating 0 6m1s
myapp-deploy-f4db5d79c-wwx5n 0/1 Terminating 0 6m4s
myapp-deploy-f4db5d79c-wwx5n 0/1 Terminating 0 6m4s
此时来再查看
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-55b78d8548-cw4r5 1/1 Running 0 5s
myapp-deploy-55b78d8548-jwj2j 1/1 Running 0 5s
myapp-deploy-55b78d8548-l264b 1/1 Running 0 4m20s
myapp-deploy-55b78d8548-mnm95 1/1 Running 0 5s
myapp-deploy-55b78d8548-zsl5d 1/1 Running 0 4m21s
查看滚动历史
kubectl rollout history deployment myapp-deploy
查看 ReplicaSet
[root@master manifests]# kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myapp-deploy-55b78d8548 5 5 5 59s myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=55b78d8548,release=canary
myapp-deploy-f4db5d79c 0 0 0 6m50s myapp ikubernetes/myapp:v1 app=myapp,pod-template-hash=f4db5d79c,release=canary
查看ReplicaSet后发现有两个，因为Deployment 会重新创建一个ReplicaSet来更新，IMAGES版本一列可以看出版本的不同，通过把新的Pod创建在新的ReplicaSet上来实现滚动更新
DaemonSet 控制器
DaemonSet 控制器主要用于系统级别的无状态环境。
默认创会在 kubernetes 集群中每一个节点创建一个Pod。
创建一个DaemonSet配置清单
[root@master manifests]# cat daemonset-demo.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: myapp-ds
namespace: default
spec:
selector:
matchLabels:
app: filebeat
release: stable
template:
metadata:
labels:
app: filebeat
release: stable
spec:
containers:
- name: filebeat
image: ikubernetes/filebeat:5.6.5-alpine # 这里使用filebeat来进行测试
env: # 增加两个环境变量
- name: REDIS_HOST # 指定redis地址
value: redis.default.svc.cluster.local # 这里使用集群域名来解析redis地址
- name: REDIS_LOG_LEVEL # 指定日志级别
value: info # 日志级别为info
[root@master manifests]# kubectl apply -f daemonset-demo.yaml
daemonset.apps/myapp-ds created
[root@master manifests]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-ds-jxwfq 1/1 Running 0 9s 10.244.1.22 node03.kubernetes <none> <none>
myapp-ds-mw9vw 1/1 Running 0 9s 10.244.3.25 node01.kubernetes <none> <none>
myapp-ds-xjqdb 1/1 Running 0 9s 10.244.2.18 node02.kubernetes <none> <none>
可以看到已经被创建成功，并且是每个节点都只有一个Pod。
查看详细信息
[root@master manifests]# kubectl describe ds myapp-ds
Name: myapp-ds
Selector: app=filebeat,release=stable
Node-Selector: <none>
Labels: <none>
Annotations: deprecated.daemonset.template.generation: 1
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"DaemonSet","metadata":{"annotations":{},"name":"myapp-ds","namespace":"default"},"spec":{"selector":{"matc...
Desired Number of Nodes Scheduled: 3
Current Number of Nodes Scheduled: 3
Number of Nodes Scheduled with Up-to-date Pods: 3
Number of Nodes Scheduled with Available Pods: 3
Number of Nodes Misscheduled: 0
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=filebeat
release=stable
Containers:
filebeat:
Image: ikubernetes/filebeat:5.6.5-alpine
Port: <none>
Host Port: <none>
Environment:
REDIS_HOST: redis.default.svc.cluster.local
REDIS_LOG_LEVEL: info
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 22m daemonset-controller Created pod: myapp-ds-qjg6w
Normal SuccessfulCreate 22m daemonset-controller Created pod: myapp-ds-ftxzb
Normal SuccessfulCreate 22m daemonset-controller Created pod: myapp-ds-66hnj
同样，一个配置清单中，可以把多个资源配置写在一个清单中，使用 --- 来分割
在相同的清单文件中，再定义一个redis 的 Deployment
[root@master manifests]# cat daemonset-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: redis
role: logstor
template:
metadata:
labels:
app: redis
role: logstor
spec:
containers:
- name: redis
image: redis:4.0-alpine
ports:
- name: redis
containerPort: 6379
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: myapp-ds
namespace: default
spec:
selector:
matchLabels:
app: filebeat
release: stable
template:
metadata:
labels:
app: filebeat
release: stable
spec:
containers:
- name: filebeat
image: ikubernetes/filebeat:5.6.5-alpine
env:
- name: REDIS_HOST
value: redis.default.svc.cluster.local
- name: REDIS_LOG_LEVEL
value: info
再次使用 kubectl apply 来执行此清单文件
[root@master manifests]# kubectl apply -f daemonset-demo.yaml
deployment.apps/redis created
daemonset.apps/myapp-ds created
[root@master manifests]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-ds-66hnj 1/1 Running 0 59s
myapp-ds-ftxzb 1/1 Running 0 59s
myapp-ds-qjg6w 1/1 Running 0 59s
redis-5c998b644f-wnzrd 1/1 Running 0 59s
创建一个redis 的service
[root@master manifests]# kubectl expose deployment redis --port=6379
service/redis exposed
[root@master manifests]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 15d
redis ClusterIP 10.111.151.200 <none> 6379/TCP 4s
进入到redis pod中，并尝试解析redis
[root@master manifests]# kubectl exec -it redis-5c998b644f-wnzrd -- /bin/sh
/data # netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN
tcp 0 0 :::6379 :::* LISTEN
/data # ls
/data # nslookup redis.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve
Name: redis.default.svc.cluster.local
Address 1: 10.111.151.200 redis.default.svc.cluster.local # 可以看到解析正常
同样，DaemonSet 也支持滚动更新，但个Deployment不同的时候，DaemonSet只支持删除Pod后再次新建，来进行更新
更新方式有好几种，这里使用 kubectl set image 来更新
[root@master manifests]# kubectl set image daemonset myapp-ds filebeat=ikubernetes/filebeat:5.6.6-alpine
daemonset.extensions/myapp-ds image updated
[root@master manifests]# kubectl get pods -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-deploy-f4db5d79c-7hnfg 1/1 Running 0 22h 10.244.2.16 node02.kubernetes <none> <none>
myapp-deploy-f4db5d79c-85hpm 1/1 Running 0 22h 10.244.3.22 node01.kubernetes <none> <none>
myapp-deploy-f4db5d79c-b9h4s 1/1 Running 0 22h 10.244.2.15 node02.kubernetes <none> <none>
myapp-deploy-f4db5d79c-tm9mt 1/1 Running 0 22h 10.244.1.20 node03.kubernetes <none> <none>
myapp-deploy-f4db5d79c-xp8t6 1/1 Running 0 22h 10.244.3.23 node01.kubernetes <none> <none>
myapp-ds-8tvmc 0/1 ContainerCreating 0 10s <none> node03.kubernetes <none> <none>
myapp-ds-f2pp8 1/1 Running 0 30s 10.244.2.20 node02.kubernetes <none> <none>
myapp-ds-ftxzb 1/1 Running 0 25m 10.244.3.26 node01.kubernetes <none> <none>
redis-5c998b644f-wnzrd 1/1 Running 0 25m 10.244.1.24 node03.kubernetes <none> <none>
myapp-ds-8tvmc 1/1 Running 0 14s 10.244.1.25 node03.kubernetes <none> <none>
myapp-ds-ftxzb 1/1 Terminating 0 25m 10.244.3.26 node01.kubernetes <none> <none>
myapp-ds-ftxzb 0/1 Terminating 0 25m 10.244.3.26 node01.kubernetes <none> <none>
myapp-ds-ftxzb 0/1 Terminating 0 25m 10.244.3.26 node01.kubernetes <none> <none>
myapp-ds-ftxzb 0/1 Terminating 0 25m 10.244.3.26 node01.kubernetes <none> <none>
myapp-ds-cs2hw 0/1 Pending 0 0s <none> <none> <none> <none>
myapp-ds-cs2hw 0/1 Pending 0 0s <none> node01.kubernetes <none> <none>
myapp-ds-cs2hw 0/1 ContainerCreating 0 0s <none> node01.kubernetes <none> <none>
myapp-ds-cs2hw 1/1 Running 0 17s 10.244.3.27 node01.kubernetes <none> <none>
这里会一个一个更新，删除后下载镜像更新启动Pod。