【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 面试题汇总