K8S面试应知必回

目录

• 面试不要不懂装懂，不会就是不会，不可能每个人都接触过所有的知识！
  • 1. 基础问题
    • 1.1 Service是怎么关联Pod的？（课程Service章节）
    • 1.2 HPA V1 V2的区别
    • 1.3 Pod生命周期（课程Pod章节）
    • 1.4 Kubernetes Master节点高可用（课程Master节点和Node节点章节）
    • 1.5 QoS
    • 1.6 flannel和calico（课程安装章节）
    • 1.7 Helm优点
    • 1.8 公司的架构是什么样的？
  • 2. 日志监控
    • 2.1 容器内日志怎么采集的？
    • 2.2 Fluentd
    • 2.3 日志的索引
    • 2.4 etcd怎么监控的？（课程自带metrics接口应用的监控）
    • 2.5 黑盒监控blackbox
    • 2.6 状态码监控
    • 2.7 你之前是怎么监控K8S的，监控哪些指标
    • 2.8 你之前是怎么收集K8S日志的，有哪些方案
  • 3. 存储问题
    • 3.1 Rook问题
    • 3.2 如何对接外部CEPH
    • 3.3 生产环境的pv回收策略如何选择？
    • 3.4 K8S持久化对接过哪些储存，为什么要选择它？
  • 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 发布详细流程

答：可以看一下课程流水线设计的文档

以上问答只是个人见解，不一定是最好的回答，大家可以自行查阅网上资料。