- 面试不要不懂装懂,不会就是不会,不可能每个人都接触过所有的知识!
- 1. 基础问题
- 2. 日志监控
- 3. 存储问题
- 4. 大厂面试题
- 4.1 介绍下工作经历,从事过哪些和K8s相关的工作
- 4.2 主要语言是什么?平时这些项目上云有哪些注意的点
- 4.3 有遇到过容器的OOM的问题吗?怎么处理的?
- 4.4 有状态应用如何上云?
- 4.5 解析下CRD和Operator?有没有自己开发过CRD和Operator?
- 4.6 什么是CNI?平时K8s集群用的是哪个网络插件?
- 4.7 为什么Pod中关于资源有request和limit两个字段?有想过这么设计的原因吗?
- 4.8 OpenShift和K8s相比有哪些不同?
- 4.9 Pod被调度到一个节点的具体过程?
- 4.10 有了解过istio吗,和springcould有什么区别
- 在k8s Jenkins 发布详细流程
- 以上问答只是个人见解,不一定是最好的回答,大家可以自行查阅网上资料。
面试不要不懂装懂,不会就是不会,不可能每个人都接触过所有的知识!
1. 基础问题
1.1 Service是怎么关联Pod的?(课程Service章节)
答:创建Pod是都会定义Pod的便签,比如role=frontend,Service通过Selector字段匹配该标签即可关联至该Pod,Pod和Service需要在同一个namespace,中文文档。
1.2 HPA V1 V2的区别
答:HPA v1为稳定版自动水平伸缩,只支持CPU指标。V2为beta版本,分为v2beta1(支持CPU、内存和自定义指标),v2beta2(支持CPU、内存、自定义指标Custom和额外指标ExternalMetrics),从k8s 1.11之后,度量指标的采集依赖metrics-server,弃用了heapster,中文文档。
1.3 Pod生命周期(课程Pod章节)
答:
Pod创建:
1. API Server 在接收到创建pod的请求之后,会根据用户提交的参数值来创建一个运行时的pod对象。
2. 根据 API Server 请求的上下文的元数据来验证两者的 namespace 是否匹配,如果不匹配则创建失败。
3. Namespace 匹配成功之后,会向 pod 对象注入一些系统数据,如果 pod 未提供 pod 的名字,则 API Server 会将 pod 的 uid 作为 pod 的名字。
4. API Server 接下来会检查 pod 对象的必需字段是否为空,如果为空,创建失败。
5. 上述准备工作完成之后会将在 etcd 中持久化这个对象,将异步调用返回结果封装成 restful.response,完成结果反馈。
6. API Server 创建过程完成,剩下的由 scheduler 和 kubelet 来完成,此时 pod 处于 pending 状态。
7. Scheduler选择出最优节点。
8. Kubelet启动该Pod。
Pod删除:
1. 用户发出删除 pod 命令
2. 将 pod 标记为“Terminating”状态
监控到 pod 对象为“Terminating”状态的同时启动 pod 关闭过程
endpoints 控制器监控到 pod 对象关闭,将pod与service匹配的 endpoints 列表中删除
Pod执行PreStop定义的内容
3. 宽限期(默认30秒)结束之后,若存在任何一个运行的进程,pod 会收到 SIGKILL 信号
4. Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0从而完成删除操作
1.4 Kubernetes Master节点高可用(课程Master节点和Node节点章节)
答:Kube-APIServer为无状态服务,可以启动多个,通过负载均衡进行轮训。ControllerManager和Scheduler为有状态服务,多节点启动会进行选主,主节点信息保存在kube-system命名空间下的对应名称的endpoint中
1.5 QoS
答: 最高级别:Guaranteed节点资源不够时最后一个被杀掉, Burstable第二个被杀掉,BestEffort第一个被杀掉
1.6 flannel和calico(课程安装章节)
答:如果没有用过flannel可以直接说没有用过flannel,都是用的calico,因为calico性能强大,并且配置简单。Flannel的host-gw虽然性能好,但是只能用于大二层网络,vxlan对内核要求高,并且flannel不支持网络策略,所以采用calico。因为公司和公有云网络环境不支持BGP,所以目前采用的都是IPIP模式。
1.7 Helm优点
答:大型项目更加方便管理,可以一键创建一个环境,可以对整个项目进行版本升级、回滚,部署更加方便。
1.8 公司的架构是什么样的?
答:我们的架构是这样的,三台master,三台etcd。然后在指定的节点上部署了ingress nginx,然后外部有个网关(可以选择性说网关是硬件设备F5或者DMZ的nginx,或者公有云的LB)连接到了k8s ingress节点的80和433,然后有个通配符域名指向了ingress,在ingress上面又做的分发。
2. 日志监控
2.1 容器内日志怎么采集的?
答:容器内日志我们是使用filebeat进行采集的,filebeat以sidecar的形式和业务应用运行在同一个Pod内,使用emptyDir进行日志文件的共享。
2.2 Fluentd
答:Fluentd配置简单,并且Docker日志一般是json输出,使用fluentd收集更加方便,当然filebeat也是可以采集节点日志的。
2.3 日志的索引
答:为了更快的查询日志,一般我们会根据集群、命名空间、资源名称进行添加索引。
2.4 etcd怎么监控的?(课程自带metrics接口应用的监控)
答:etcd属于云原生应用,自带了metrics接口,可以直接请求metrics接口即可获取到监控数据,一般监控etcd的状态、leader是否正常、选择次数、选主失败次数、集群延迟、落盘延迟等。(此问题可以根据监控项自行补充)
2.5 黑盒监控blackbox
答:黑盒监控可以监控http、tcp的监控状态、延迟、解析速度、证书到期时间等指标,可以根据课程的监控图自行补充。
2.6 状态码监控
答:可以这么回答,我们使用的是ingress,ingress也是用Prometheus监控的,可以监控到某个应用的请求状态,比如多个200、502、403等,课程ingress监控章节。
2.7 你之前是怎么监控K8S的,监控哪些指标
答:我是利用Prometheus监控的,主要是监控宿主机的指标、Pod指标,比如内存CPU使用率,是否有重启这类的。然后也使用了黑盒监控,监控应用是否是正常的等。在k8s的监控和传统架构区别不大,该监控的还要监控,可以想一下之前是怎么监控的,那在k8s里面同样也可以监控。
2.8 你之前是怎么收集K8S日志的,有哪些方案
答:可以回答使用filebeat进行收集的,因为filebeat比较轻量级,并且配置比较简单。同时也支持以sidecar的方式部署到Pod里面,这样同时也能收集Pod容器内的日志。一般会采用filebeat+kafka+logstash+es+kibana这种架构。
3. 存储问题
3.1 Rook问题
答:Rook现在已经毕业了,之前虽然没有毕业,但是对ceph的支持已经是stable了,并且rook降低了ceph的学习成本,几乎不用运维,所以我们采用了Rook。使用Rook操作ceph扩容也是非常简单的,只需要更改rook创建ceph集群的资源文件即可。
3.2 如何对接外部CEPH
答:对接的方式有很多,使用Rook可以对接外部ceph,使用volume、pvc、storageClass和CSI插件都可以对接外部ceph。
3.3 生产环境的pv回收策略如何选择?
答:目前pv的回收策略分为recycle、delete、retain,具体用法可以参考课程的pv章节。其中recycle(相当于对数据目录进行rm -rf /xxx/* ,进行回收的时候会创建一个Pod进行rm操作)将被官方使用动态存储供应(dynamic provisioning)逐步替代。所以面试遇到这类问题,可以着重回答delete和retain。其中Delete回收策略一般用于动态存储,比如ceph、GFS这类的,也就是通过StorageClass进行管理创建的pv,Delete的策略也是StorageClass的默认策略,因为当一个项目用到存储时,会通过pvc或者volumeTemplateClaim申请存储,然后后端存储会自动创建pv,所以当你删除pvc或者pv时,就认为你已经不需要这个存储了,就会触发自动删除pv,防止造成存储池存储过多无人使用的垃圾pv。而静态文件建议使用Retain,比如NFS、NAS这类的,因为这些文件一般都是手动管理的,所以最好是尽量保持这些文件的可用性,就算不用了,也是可以根据目录名称进行手动删除。所以retain和delete是用的比较多的。
3.4 K8S持久化对接过哪些储存,为什么要选择它?
答:可以写自己的实际情况,不能没有做过就胡说。比如常见的NFS和ceph,可以回答CEPH,因为ceph是比较常用的分布式存储,支持文件存储、块存储和对象存储,而且性能还是比较好的。GFS和NFS可以不说,因为GFS可能会被淘汰,NFS是单点的。
4. 大厂面试题
4.1 介绍下工作经历,从事过哪些和K8s相关的工作
答:真是的工作要说,你在学习过程中做的一些项目或者经验都可以说一下,但是自己没有经过手的最好不要说,防止露馅。比如高可用集群搭建和维护、Prometheus监控的使用、CICD的建设等。要往自己会的方向引导。
4.2 主要语言是什么?平时这些项目上云有哪些注意的点
答:主要考察的是你对项目上云以及对某个语言的发版流程是否熟悉。比如Java语言是mvn编译,go语言是go build,nodejs是npm run build等。你可以说一下自己做过的容器化项目,比如Java语言的或者是nodejs。注意事项就是一个应用上云的步骤的一些细节。比如如何发版、如何回滚、如何配置QoS和健康检查等。
4.3 有遇到过容器的OOM的问题吗?怎么处理的?
答:遇到OOM有两种情况,第一种情况是这个程序确实需要4Gi(假设)内存,但是你的limit配置只给了3Gi,这样就会有OOM。另外一种情况是程序本身是有内存溢出的,可能没有做好垃圾回收,导致内存一直往上涨,这样的可能需要开发人员加上相应的垃圾回收,还有一种程序内存溢出是因为limit设置的太低导致不能正常的垃圾回收,比如一个程序正常运行需要3Gi,但是垃圾回收可能也需要占用内存,所以此时给3Gi肯定是不行的,一般需要超过3Gi,也就是limit配置要超过程序需求的800M-1Gi。
4.4 有状态应用如何上云?
答:有状态应用其实也分为需要存储数据的和不需要存储数据的。如果是有需要存储数据的部署在K8s上,最好有后端可靠的存储支持,比如分布式的ceph或者公有云的存储,最极端的情况是没有后端存储支持,可以采用hostPath挂载,采用固定节点的形式,可以参考csi hostpath,或者storageClass hostPath。而有的有状态应用并不需要存储数据,只是想要有规定的标识符。
4.5 解析下CRD和Operator?有没有自己开发过CRD和Operator?
答:operator规范的说是operator = crd+controller,也就是operator可以理解为是一个自定义的控制器,CRD是一个自定义的资源类型,就像我们定义的deployment、service等,这些是官方自带的控制器,CRD则是扩展的资源类型。开发过就说开发过,可以讲一下如何开发的,没有开发过就说没有用到这种场景,目前还没有这个需求,因为一些中间件他们官方已经写好了operator,然后自己公司的项目一键部署使用helm管理的,因为helm比较简单(不会helm这句话不要说)。
4.6 什么是CNI?平时K8s集群用的是哪个网络插件?
答:CNI是k8s提出的容器网络接口,相当于一种规范,只要网络厂商的产品符合了这个规范,那么这个网络厂商的产品就能为k8s提供网络管理。常用的有calico、cilium、flannel等,可以回答说现在常用的是calico,因为他部署方便,很多大厂都在用,并且原生支持网络策略,flannel不支持网络策略。
4.7 为什么Pod中关于资源有request和limit两个字段?有想过这么设计的原因吗?
答:request是用于程序的最小请求,limit是用于程序的最大请求。另一方面request可以防止节点部署过多的Pod,limit可以防止拖垮节点。
4.8 OpenShift和K8s相比有哪些不同?
答:以我个人的理解,openshift是一个企业级的平台,包含了很多开箱即用的东西,比如可以很方便的创建一个Java应用,或者很方面的进行服务发布,他是对k8s进行了一层封装,并且提供了S2I的形式用于应用的构建和发布。而K8s是原生的下一代云计算平台,很多东西都需要自己去维护,比如你想要监控程序,就需要自己去搭建一个Prometheus或者其他的。如果大家对openshift不太熟悉,切记不能说太多openshift的东西。
4.9 Pod被调度到一个节点的具体过程?
答:见本页1.3
4.10 有了解过istio吗,和springcould有什么区别
答:有过一些了解Istio是Google开源的服务网格,号称可以让开发人员无需关心流量管理方面的代码,只需要关心业务逻辑,可以提高开发效率。而springcloud是专门为Java语言设计,虽然他可以很方面实现流量管理的功能,比如灰度、熔断、负载均衡等,但是也需要开发写少量代码,并且只能Java使用,而istio和语言无关,并且不需要开发写代码。
在k8s Jenkins 发布详细流程
答:可以看一下课程流水线设计的文档