k8s-进阶-工作负载
# 一、控制器
Pod（容器组）是 Kubernetes 中最小的调度单元，您可以通过 kubectl 直接创建一个 Pod。**Pod 本身并不能自愈（self-healing）**。如果一个 Pod 所在的 Node （节点）出现故障，或者调度程序自身出现故障，Pod 将被删除；同理，当因为节点资源不够或节点维护而驱逐 Pod 时，Pod 也将被删除。
Kubernetes 通过引入 Controller（控制器）的概念来管理 Pod 实例。
**控制器可以提供如下特性：**
- 水平扩展（运行 Pod 的多个副本）
- rollout（版本更新）
- self-healing（故障恢复） 例如：当一个节点出现故障，控制器可以自动地在另一个节点调度一个配置完全一样的 Pod，以替换故障节点上的 Pod。
**k8s支持的控制器**
- **Deployment**
> 为Pod，提供强大功能；自愈，滚动更新，副本，回滚等
- StatefulSet
> 有状态副本集
- DaemonSet
> daemon方式，每个节点都有
- CronJob
> 定时任务
- Jobs
> 任务
- **ReplicaSet**
> Kubernetes 官方推荐使用 Deployment 替代 ReplicaSet
- **ReplicationController**
> Kubernetes 官方推荐使用 Deployment 替代 ReplicationController
- Garbage Collection
> 垃圾回收
- TTL Controller for Finished Resources
> time to live；自动清理Job
# 二、实战-Deployment、ReplicationController、ReplicaSet
## 1、rs
ReplicaSet
```shell
#rs看定义就知道，可用内容不多
kubectl explain rs.spec
#属性解释
minReadySeconds:
Kubernetes在等待设置的时间后才进行升级
如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
如果没有设置该值，在某些极端情况下可能会造成服务服务正常运行
replicas:
保证的副本数
2、rc
ReplicationController
#rc看定义就知道，可用内容不多
kubectl explain rc.spec
#和rs一模一样。但是不支持复杂的matchLabel机制
3、Deploy
#kubectl explain deploy.spec
paused <boolean>
用于暂停记录部署版本信息.（后面演示）
progressDeadlineSeconds: 600
等待多少秒才能确定Deployment进程是卡住的。如果卡住，这次部署失败，并汇报自己状态，我们可以用kubectl describe查看原因，进行手动修复等
replicas: 1
副本
revisionHistoryLimit: 10 #见3.1实验
历史总记录数
strategy: #见3.5实验
滚动更新策略；
3.1、创建deploy-设置历史记录数
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
revisionHistoryLimit: 4
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
#实验更新，见3.2
3.2、更新
#kubectl set image deployment资源名 容器名=镜像名
kubectl set image deployment.apps/nginx-deployment php-redis=tomcat:8
#或者直接修改定义也行
kubectl edit deployment.v1.apps/nginx-deployment
#查看状态
kubectl rollout status deployment.v1.apps/nginx-deployment
3.3、回滚
#查看更新历史-看看我们设置的历史总记录数是否生效了
kubectl rollout history deployment.v1.apps/nginx-deployment
#回滚
kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
3.4、累计更新暂停/恢复
#之前spec.paused是什么意思呢
#暂停记录版本
kubectl rollout pause deployment.v1.apps/nginx-deployment
#多次更新操作。
##比如更新了资源限制
kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
##比如更新了镜像版本
kubectl set image deployment.apps/nginx-deployment php-redis=tomcat:8
##在继续操作多次
##看看历史版本有没有记录变化
kubectl rollout history deployment.v1.apps/nginx-deployment
#让多次累计生效
kubectl rollout resume deployment.v1.apps/nginx-deployment
3.5、滚动更新策略
kubectl explain deploy.spec.strategy.rollingUpdate
#这两个属性，解释见下表格
maxSurge:
maxUnavailable: #设置了最大不可用量。
| 字段名称 | 可选值 | 字段描述 |
|---|---|---|
| 类型 | 滚动更新 重新创建 | 如果选择重新创建，Deployment将先删除原有副本集中的所有 Pod，然后再创建新的副本集和新的 Pod。如此，更新过程中将出现一段应用程序不可用的情况； |
| 最大超出副本数 | 数字或百分比 | 滚动更新过程中，可以超出期望副本数的最大值。 该取值可以是一个绝对值（例如：5），也可以是一个相对于期望副本数的百分比（例如：10%）； 如果填写百分比，则以期望副本数乘以该百分比后向上取整的方式计算对应的绝对值； 当最大超出副本数 maxUnavailable 为 0 时，此数值不能为 0；默认值为 25%。 例如：假设此值被设定为 30%，当滚动更新开始时，新的副本集（ReplicaSet）可以立刻扩容， 但是旧 Pod 和新 Pod 的总数不超过 Deployment 期待副本数（spec.repilcas）的 130%。 一旦旧 Pod 被终止后，新的副本集可以进一步扩容，但是整个滚动更新过程中，新旧 Pod 的总 数不超过 Deployment 期待副本数（spec.repilcas）的 130%。 |
| 最大不可用副本数 | 数字或百分比 | 滚动更新过程中，不可用副本数的最大值。 该取值可以是一个绝对值（例如：5），也可以是一个相对于期望副本数的百分比（例如：10%）； 如果填写百分比，则以期望副本数乘以该百分比后向下取整的方式计算对应的绝对值； 当最大超出副本数 maxSurge 为 0 时，此数值不能为 0；默认值为 25%； 例如：假设此值被设定为 30%，当滚动更新开始时，旧的副本集（ReplicaSet）可以缩容到期望 副本数的 70%；在新副本集扩容的过程中，一旦新的 Pod 已就绪，旧的副本集可以进一步缩容， 整个滚动更新过程中，确保新旧就绪副本数之和不低于期望副本数的 70%。 |
3.6、HPA（动态扩缩容）
#1、先安装metrics-server(yaml如下，已经改好了镜像和配置，可以直接使用)，这样就能监控到pod。node的资源情况（默认只有cpu、memory的资源审计信息哟，更专业的我们后面对接 Prometheus）
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: system:aggregated-metrics-reader
labels:
rbac.authorization.k8s.io/aggregate-to-view: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: metrics-server:system:auth-delegator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: metrics-server-auth-reader
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
name: v1beta1.metrics.k8s.io
spec:
service:
name: metrics-server
namespace: kube-system
group: metrics.k8s.io
version: v1beta1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: metrics-server
namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: metrics-server
namespace: kube-system
labels:
k8s-app: metrics-server
spec:
selector:
matchLabels:
k8s-app: metrics-server
template:
metadata:
name: metrics-server
labels:
k8s-app: metrics-server
spec:
serviceAccountName: metrics-server
volumes:
# mount in tmp so we can safely use from-scratch images and/or read-only containers
- name: tmp-dir
emptyDir: {}
containers:
- name: metrics-server
image: mirrorgooglecontainers/metrics-server-amd64:v0.3.6
imagePullPolicy: IfNotPresent
args:
- --cert-dir=/tmp
- --secure-port=4443
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
ports:
- name: main-port
containerPort: 4443
protocol: TCP
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
volumeMounts:
- name: tmp-dir
mountPath: /tmp
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: "amd64"
---
apiVersion: v1
kind: Service
metadata:
name: metrics-server
namespace: kube-system
labels:
kubernetes.io/name: "Metrics-server"
kubernetes.io/cluster-service: "true"
spec:
selector:
k8s-app: metrics-server
ports:
- port: 443
protocol: TCP
targetPort: main-port
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: system:metrics-server
rules:
- apiGroups:
- ""
resources:
- pods
- nodes
- nodes/stats
- namespaces
- configmaps
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:metrics-server
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:metrics-server
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
#2、再配置应用
##应用的yaml已经做好
apiVersion: v1
kind: Service
metadata:
name: php-apache
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: php-apache
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: php-apache
name: php-apache
spec:
replicas: 1
selector:
matchLabels:
run: php-apache
template:
metadata:
creationTimestamp: null
labels:
run: php-apache
spec:
containers:
- image: registry.cn-zhangjiakou.aliyuncs.com/allenicodingdocker/myphp:v1.0
name: php-apache
ports:
- containerPort: 80
resources:
requests:
cpu: 200m
##hpa配置 hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
targetCPUUtilizationPercentage: 50
#3、进行压力测试
kubectl run -i --tty load-generator --image=busybox /bin/sh
#回车然后敲下面的命令
while true; do wget -q -O- http://php-apache; done
3.7、一个金丝雀部署案例
为应用的两个不同版本，创建deploy，这样应用程序的新旧两个版本都可以同时获得生产上的流量。
#部署第一个版本
第一个版本的 Deployment 包含了 3 个Pod副本，Service 通过 label selector app: nginx 选择对应的 Pod，nginx 的标签为 1.7.9
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-old
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
app: nginx
spec:
selector:
app: nginx
ports:
- name: nginx-port
protocol: TCP
port: 80
nodePort: 32600 #Service -NodePort-ClusterIP
targetPort: 80
type: NodePort
#假设此时想要发布新的版本 nginx 1.18.0，可以创建第二个 Deployment：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-canary
labels:
app: nginx
track: canary
spec:
replicas: 1
selector:
matchLabels:
app: nginx
track: canary
template:
metadata:
labels:
app: nginx
track: canary
spec:
volumes:
- emptyDir: {}
name: ourfile
containers:
- name: nginx
image: nginx:1.18.0
volumeMounts:
- mountPath: /usr/share/nginx/html
name: ourfile
initContainers:
- image: alpine
name: initc-1
command: ["/bin/sh","-c","echo 'canary page
' > /html/index.html"]
volumeMounts:
- name: ourfile
mountPath: /html
三、实战-StatefulSet
有状态副本集；Deployment等属于无状态的应用部署（stateless）
StatefulSet 使用场景
对于有如下要求的应用程序，StatefulSet 非常适用：
- 稳定、唯一的网络标识（dnsname）
- StatefulSet通过与其相关的无头服务为每个pod提供DNS解析条目。假如无头服务的DNS条目为:
“ ( s e r v i c e n a m e ) . (service name). (servicename).(namespace).svc.cluster.local”，
那么pod的解析条目就是" ( p o d n a m e ) . (pod name). (podname).(service name).$(namespace).svc.cluster.local"，每个pod name也是唯一的。
- StatefulSet通过与其相关的无头服务为每个pod提供DNS解析条目。假如无头服务的DNS条目为:
- 每个Pod始终对应各自的存储路径（PersistantVolumeClaimTemplate）
- 按顺序地增加副本、减少副本，并在减少副本时执行清理
- 按顺序自动地执行滚动更新
如果一个应用程序不需要稳定的网络标识，或者不需要按顺序部署、删除、增加副本，就应该考虑使用 Deployment 这类无状态（stateless）的控制器
apiVersion: v1
kind: Service #定义一个负载均衡网络
metadata:
name: stateful-tomcat
labels:
app: stateful-tomcat
spec:
ports:
- port: 8123
name: web
targetPort: 8080
clusterIP: None #NodePort：任意机器+NodePort都能访问，ClusterIP：集群内能用这个ip、service域名能访问，clusterIP: None；不要分配集群ip。headless；无头服务。稳定的域名
selector:
app: stateful-tomcat
---
apiVersion: apps/v1
kind: StatefulSet #控制器。
metadata:
name: stateful-tomcat
spec:
selector:
matchLabels:
app: stateful-tomcat # has to match .spec.template.metadata.labels
serviceName: "stateful-tomcat" #这里一定注意，必须提前有个service名字叫这个的
replicas: 3 # by default is 1
template:
metadata:
labels:
app: stateful-tomcat # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: tomcat
image: tomcat:7
ports:
- containerPort: 8080
name: web
#观察效果。
删除一个，重启后名字，ip等都是一样的。保证了状态
#细节
kubectl explain StatefulSet.spec
podManagementPolicy：
OrderedReady（按序）、Parallel（并发）
serviceName -required-
设置服务名，就可以用域名访问pod了。
pod-specific-string.serviceName.default.svc.cluster.local
#测试
kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh
ping stateful-tomcat-0.stateful-tomcat
#我们在这里没有加存储卷。如果有的话 kubectl get pvc -l app=stateful-tomcat 我们就能看到即使Pod删了再拉起，卷还是同样的。
四、实战-DaemonSet
DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。
- 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
- 当节点从集群中移除时，Pod 也就被垃圾回收了
- 删除一个 DaemonSet 可以清理所有由其创建的 Pod
DaemonSet 的典型使用场景有：
- 在每个节点上运行集群的存储守护进程，例如 glusterd、ceph
- 在每个节点上运行日志收集守护进程，例如 fluentd、logstash
- 在每个节点上运行监控守护进程，例如 Prometheus Node Exporter、Sysdig Agent、collectd、Dynatrace OneAgent、APPDynamics Agent、Datadog agent、New Relic agent、Ganglia gmond、Instana Agent 等
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: logging
labels:
app: logging
spec:
selector:
matchLabels:
name: logging
template:
metadata:
labels:
name: logging
spec:
containers:
- name: logging
image: nginx
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
tolerations: #设置容忍master的污点
- key: node-role.kubernetes.io/master
effect: NoSchedule
#查看效果
kubectl get pod -l name=logging -o wide
五、实战-Job、CronJob
1、Job
Kubernetes中的 Job 对象将创建一个或多个 Pod，并确保指定数量的 Pod 可以成功执行到进程正常结束：
- 当 Job 创建的 Pod 执行成功并正常结束时，Job 将记录成功结束的 Pod 数量
- 当成功结束的 Pod 达到指定的数量时，Job 将完成执行
- 删除 Job 对象时，将清理掉由 Job 创建的 Pod
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never #Job情况下，不支持Always
backoffLimit: 4 #任务4次都没成，认为失败
activeDeadlineSeconds: 10
#默认这个任务需要成功执行一次。
#查看job情况
kubectl get job
#修改下面参数设置再试试
#千万不要用阻塞容器。nginx。job由于Pod一直running状态。下一个永远得不到执行，而且超时了，当前running的Pod还会删掉
kubectl api-resources
#参数说明
kubectl explain job.spec
activeDeadlineSeconds：10 总共维持10s
#该字段限定了 Job 对象在集群中的存活时长，一旦达到 .spec.activeDeadlineSeconds 指定的时长，该 Job 创建的所有的 Pod 都将被终止。但是Job不会删除，Job需要手动删除，或者使用ttl进行清理
backoffLimit：
#设定 Job 最大的重试次数。该字段的默认值为 6；一旦重试次数达到了 backoffLimit 中的值，Job 将被标记为失败，且尤其创建的所有 Pod 将被终止；
completions： #Job结束需要成功运行的Pods。默认为1
manualSelector：
parallelism： #并行运行的Pod个数，默认为1
ttlSecondsAfterFinished：
ttlSecondsAfterFinished: 0 #在job执行完时马上删除
ttlSecondsAfterFinished: 100 #在job执行完后，等待100s再删除
#除了 CronJob 之外，TTL 机制是另外一种自动清理已结束Job（Completed 或 Finished）的方式：
#TTL 机制由 TTL 控制器 提供，ttlSecondsAfterFinished 字段可激活该特性
#当 TTL 控制器清理 Job 时，TTL 控制器将删除 Job 对象，以及由该 Job 创建的所有 Pod 对象。
# job超时以后 已经完成的不删，正在运行的Pod就删除
#单个Pod时，Pod成功运行，Job就结束了
#如果Job中定义了多个容器，则Job的状态将根据所有容器的执行状态来变化。
#Job任务不建议去运行nginx，tomcat，mysql等阻塞式的，否则这些任务永远完不了。
##如果Job定义的容器中存在http server、mysql等长期的容器和一些批处理容器，则Job状态不会发生变化（因为长期运行的容器不会主动结束）。此时可以通过Pod的.status.containerStatuses获取指定容器的运行状态。
-
manualSelector：
- job同样可以指定selector来关联pod。需要注意的是job目前可以使用两个API组来操作，batch/v1和extensions/v1beta1。当用户需要自定义selector时，使用两种API组时定义的参数有所差异。
- 使用batch/v1时，用户需要将jod的spec.manualSelector设置为true，才可以定制selector。默认为false。
- 使用extensions/v1beta1时，用户不需要额外的操作。因为extensions/v1beta1的spec.autoSelector默认为false，该项与batch/v1的spec.manualSelector含义正好相反。换句话说，使用extensions/v1beta1时，用户不想定制selector时，需要手动将spec.autoSelector设置为true。
2、CronJob
CronJob 按照预定的时间计划（schedule）创建 Job（注意：启动的是Job不是Deploy，rs）。一个 CronJob 对象类似于 crontab (cron table) 文件中的一行记录。该对象根据 Cron 格式定义的时间计划，周期性地创建 Job 对象。
Schedule
所有 CronJob 的
schedule中所定义的时间，都是基于 master 所在时区来进行计算的。
一个 CronJob 在时间计划中的每次执行时刻，都创建 大约 一个 Job 对象。这里用到了 大约 ，是因为在少数情况下会创建两个 Job 对象，或者不创建 Job 对象。尽管 K8S 尽最大的可能性避免这种情况的出现，但是并不能完全杜绝此现象的发生。因此，Job 程序必须是 幂等的。
当以下两个条件都满足时，Job 将至少运行一次：
startingDeadlineSeconds被设置为一个较大的值，或者不设置该值（默认值将被采纳）concurrencyPolicy被设置为Allow
# kubectl explain cronjob.spec
concurrencyPolicy：并发策略
"Allow" (允许，default):
"Forbid"(禁止): forbids；前个任务没执行完，要并发下一个的话，下一个会被跳过
"Replace"(替换): 新任务，替换当前运行的任务
failedJobsHistoryLimit：记录失败数的上限，Defaults to 1.
successfulJobsHistoryLimit： 记录成功任务的上限。 Defaults to 3.
#指定了 CronJob 应该保留多少个 completed 和 failed 的 Job 记录。将其设置为 0，则 CronJob 不会保留已经结束的 Job 的记录。
jobTemplate： job怎么定义（与前面我们说的job一样定义法）
schedule： cron 表达式；
startingDeadlineSeconds： 表示如果Job因为某种原因无法按调度准时启动，在spec.startingDeadlineSeconds时间段之内，CronJob仍然试图重新启动Job，如果在.spec.startingDeadlineSeconds时间之内没有启动成功，则不再试图重新启动。如果spec.startingDeadlineSeconds的值没有设置，则没有按时启动的任务不会被尝试重新启动。
suspend 暂停定时任务，对已经执行了的任务，不会生效； Defaults to false.
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *" #分、时、日、月、周
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
六、了解-TTL控制器
https://kubernetes.io/zh/docs/concepts/workloads/controllers/ttlafterfinished/
这是alpha版本
这个特性现在在v1.12版本是alpha阶段，而且默认关闭的，需要手动开启。
-
需要修改的组件包括apiserver、controller还要scheduler。
-
apiserver、controller还要scheduler都是以pod的形式运行的，所以直接修改/etc/kubernetes/manifests下面对应的三个.yaml静态文件，加入
- --feature-gates=TTLAfterFinished=true命令，然后重启对应的pod即可。
例如修改后的kube-scheduler.yaml的spec部分如下，kube-apiserver.yaml和kube-controller-manager.yaml也在spec部分加入- --feature-gates=TTLAfterFinished=true即可。
七、什么是垃圾回收
Kubernetes garbage collector（垃圾回收器）的作用是删除那些曾经有 owner，后来又不再有 owner 的对象。描述
垃圾收集器如何删除从属对象
当删除某个对象时，可以指定该对象的从属对象是否同时被自动删除，这种操作叫做级联删除（cascading deletion）。级联删除有两种模式：后台（background）和前台（foreground）
如果删除对象时不删除自动删除其从属对象，此时，从属对象被认为是孤儿（或孤立的 orphaned）
通过参数 --cascade，kubectl delete 命令也可以选择不同的级联删除策略：
- –cascade=true 级联删除
- –cascade=false 不级联删除 orphan
#删除rs，但不删除级联Pod
kubectl delete replicaset my-repset --cascade=false