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