【Kubernetes】常见面试题汇总（三十一）
目录
83.简述你知道的 K8s 中几种 Controller 控制器并详述其工作原理。简述 ingress-controller 的工作机制。
特别说明：
题目 1-68 属于【Kubernetes】的常规概念题，即 “ 汇总（一）~（二十二）” 。
题目 69-113 属于【Kubernetes】的生产应用题。
83.简述你知道的 K8s 中几种 Controller 控制器并详述其工作原理。简述 ingress-controller 的工作机制。
（一）deployment（适合无状态的服务部署）：
（1）适合部署无状态的应用服务，用来管理 pod 和 replicaset，具有上线部署、副本设定、滚动更新、回滚等功能，还可提供声明式更新，例如只更新一个新的 Image。
（2）编写 yaml 文件，并创建 nginx 服务 pod 资源。
[root@master test] # vim nginx-deployment.yam
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:nginx1
image: nginx:1.15.4
ports:
- containerPort: 80
（3）查看控制器参数：可以使用 describe 或者 edit 两种方式。
① describe 方式：[root@master test] # kubectl describe deploy nginx-deployment
② edit 方 式 ：[root@master test] # kubectl edit deploy nginx-deployment/
（二）Statefulset（适合有状态的服务部署）：
（1）特点：
① 适合部署有状态应用；
② 解决 Pod 的独立生命周期，保持 Pod 启动顺序和唯一性；
③ 稳定，唯一的网络标识符，持久存储（例如：etcd 配置文件，节点地址发生变化，将无法使用）；
④ 有序，优雅的部署和扩展、删除和终止（例如：mysql 主从关系，先启动主，再启动从）；
⑤ 有序，滚动更新。
（2）应用场景：例如数据库
（3）无状态服务的特点：
① deployment 认为所有的 pod 都是一样的；
② 不用考虑顺序的要求；
③ 不用考虑在哪个 node 节点上运行；
④ 可以随意扩容和缩容。
（4）有状态服务的特点：
① 实例之间有差别，每个实例都有自己的独特性，元数据不同，例如 etcd，zookeeper；
② 实例之间不对等的关系，以及依靠外部存储的应用；
（5）常规的 service 服务和无头服务的区别：
① service：一组 Pod 访问策略，提供 cluster-IP 群集之间通讯，还提供负载均衡和服务发现。
② Headless service 无头服务，不需要 cluster-IP，直接绑定具体的 Pod 的 IP，无头服务经常用于 statefulset 的有状态部署。
③ 创建无头服务的 service 资源和 dns 资源：由于有状态服务的 IP 地址是动态的，所以使用无头服务的时候要绑定 dns服务。
（三）Daemonset（一次部署）：
（1）一次部署，所有的 node 节点都会部署，例如一些典型的应用场景：
① 运行集群存储 daemon，例如在每个Node 上运行 glusterd、ceph；
② 在每个 Node 上运行日志收集 daemon，例如 fluentd、logstash；
③ 在每个Node 上运行监控 daemon，例如 Prometheus Node Exporter；
④ 在每一个 Node 上运行一个 Pod；
⑤ 新加入的 Node 也同样会自动运行一个 Pod。
（2）应用场景：
监控，分布式存储，日志收集等。
（四）Job（一次性的执行任务）：
一次性执行任务，类似 Linux 中的 job。
应用场景：如离线数据处理，视频解码等业务。
（五）Cronjob（周期性的执行任务）：
周期性任务，像 Linux 的 Crontab 一样。
应用场景：如通知，备份等。
使用 cronjob 要慎重，用完之后要删掉，不然会占用很多资源。
（六）ingress-controller 的工作机制：
（1）诞生：
- 通常情况下，service 和 pod 的 IP 仅可在集群内部访问。
- k8s 提供了 service 方式：NodePort 来提供对外的服务，外部的服务可以通过访问 Node 节点 ip+NodePort 端口来访问集群内部的资源，外部的请求先到达 service 所选中的节点上，然后负载均衡到每一个节点上。
- NodePort 虽然提供了对外的方式但也有很大弊端：
① 由于 service 的实现方式：user_space 、iptebles、3ipvs、方式这三种方式只支持在 4 层协议通信，不支持 7 层协议，因此 NodePort 不能代理 https服务；
② NodePort 需要暴露 service 所属每个 node 节点上端口，当需求越来越多，端口数量过多，导致维护成本过高，并且集群不好管理。
（2）原理：
- Ingress 也是 Kubernetes APl 的标准资源类型之一，它其实就是一组基于 DNS 名称（host）或 URL 路径把请求转发到指定的 Service 资源的规则。用于将集群外部的请求流量转发到集群内部完成的服务发布。
- 我们需要明白的是，Ingress 资源自身不能进行 “ 流量穿透 ”，仅仅是一组规则的集合，这些集合规则还需要其他功能的辅助，比如监听某套接字，然后根据这些规则的匹配进行路由转发，这些能够为 Ingress 资源监听套接字并将流量转发的组件就是 IngressController。
- Ingress 控制器不同于 Deployment 等 pod 控制器的是，Ingress 控制器不直接运行为 kube-controller-manager 的一部分，它仅仅是 Kubernetes 集群的一个附件，类似于 CoreDNS，需要在集群上单独部署。
- ingress controller 通过监视 api server 获取相关 ingress、service、endpoint、secret、node、configmap 对象，并在程序内部不断循环监视相关 service 是否有新的 endpoints 变化，一旦发生变化则自动更新 nginx.conf 模板配置并产生新的配置文件进行 reload。
“【Kubernetes】常见面试题汇总” 系列文章，可点击链接查看专栏详情：K8s 面试题汇总