Kubernetes的Controller进阶(十二)
一、Controller
既然学习了Pod进阶，对于管理Pod的Controller肯定也要进阶一下，之前我们已经学习过的Controller有RC、RS和Deployment，除此之外还有吗，如果感兴趣的可以自己根据官网网址了解下
官网：https://kubernetes.io/docs/concepts/architecture/controller/
1.1、Job & CronJob
1.1.1 、Job
官网：https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
为啥要说这玩意呢，举个例子来说吧，如果我有一个需求，用pod跑一个累加计算，当达到一定条件时我希望这个pod能结束；用之前Deployment的方式进行管理是做不到的，他只能做到无状态的管理，对这种有状态的管理就要通过我们接下来聊的jobs来处理;下面就实战下说明；
（1）创建job.yaml文件
apiVersion: batch/v1 kind: Job metadata: name: job-demo spec: template: metadata: name: job-demo spec: restartPolicy: Never containers: - name: counter image: busybox command: - "bin/sh" - "-c" - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"
（2）启动脚本命令
kubectl apply -f job.yaml
（3）用下面命令查看会发现任务完成了
kubectl get pods | grep job
（4）jobs的状态查看
kubectl describe jobs/pi
(5) 查看日志
kubectl logs pod-name
总结：
- 非并行Job：
- 通常只运行一个Pod，Pod成功结束Job就退出。
- 固定完成次数的并行Job:
- 并发运行指定数量的Pod，直到指定数量的Pod成功，Job结束。
- 带有工作队列的并行Job:
- 用户可以指定并行的Pod数量，当任何Pod成功结束后，不会再创建新的Pod
- 一旦有一个Pod成功结束，并且所有的Pods都结束了，该Job就成功结束。
- 一旦有一个Pod成功结束，其他Pods都会准备退出。
1.1.2 、CronJob
官网：https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
jobs是任务执行一次就结束了，而cronJob是基于时间进行任务的定时管理。在特定的时间点运行任务，反复在指定的时间点运行任务：比如定时进行数据库备份，定时发送电子邮件等等。
1.2、StatefulSet
官网：https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
之前接触的Pod的管理对象比如RC、Deployment、DaemonSet和Job都是面向无状态的服务，但是现实中有很多服务是有状态的，比如MySQL集群、MongoDB集群、ZK集群等，它们都有以下共同的特点：
- 每个节点都有固定的ID，通过该ID，集群中的成员可以互相发现并且通信
- 集群的规模是比较固定的，集群规模不能随意变动
- 集群里的每个节点都是有状态的，通常会持久化数据到永久存储中
- 如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损
而之前的RC/Deployment没办法满足要求，所以从Kubernetes v1.4版本就引入了PetSet资源对象，在v1.5版本时更名为StatefulSet。从本质上说，StatefulSet可以看作是Deployment/RC对象的特殊变种
- StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内其他的成员
- Pod的启动顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态
- StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷
- StatefulSet需要与Headless Service配合使用
实战案例
（1）创建nginx-st.yaml文件
# 定义Service apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- # 定义StatefulSet apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 3 template: metadata: labels: app: nginx spec: terminationGracePeriodSeconds: 10 containers: - name: nginx image: nginx ports: - containerPort: 80 name: web
（2）运行脚本文件
kubectl apply nginx-st.yaml
（3）查看资源
kubectl get statefulset
1.3、DaemonSet
官网：https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
根据官网可以知道这玩意也是用来管理pod的，DaemonSet应用场景：
- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理，或 Ganglia `gmond`。
1.4、Horizontal Pod Autoscaler
pod如果能根据并发量和cpu性能进行动态的扩缩容，那么对宿主机的性能是一个大的提升。下面这玩意就是实现这种思想的
官网：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
（1）配置nginx-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80
（2）执行脚本创建
kubectl apply -f nginx-deployment.yaml
（3）创建hpa，使nginx pod的数量介于2和10之间，CPU使用率维持在50％
kubectl autoscale deployment nginx-deployment --min=2 --max=10 --cpu-percent=50
（4）查看所有创建的资源
kubectl get pods
kubectl get deploy
kubectl get hpa
（5）修改replicas值为1或者11
kubectl edit deployment nginx-deployment.yaml
可以发现最终最小还是2，最大还是10
kubectl edit deployment nginx-deployment
(6)再次理解什么是hpa
Horizontal Pod Autoscaling可以根据CPU使用率或应用自定义metrics自动扩展Pod数量（支持replication controller、deployment和replica set）
- 控制管理器每隔30s查询metrics的资源使用情况
- 通过kubectl创建一个horizontalPodAutoscaler对象，并存储到etcd中
- APIServer:负责接受创建hpa对象，然后存入etcd
