Kubernetes 相关问题集（二）

Kubernetes 相关问题集

15. 什么是Pod的根容器？

答：Pod的根容器是最底层的容器，所有Pod的基础架构容器；官方名称叫做pause容器，它是Linux中专门为Pod分配的命名空间基础，所有的Pod都运行在这个命名空间里，所有的Pod都属于Pod根容器的子进程。

16. 解释Pod的生命周期。

答：Pod的生命周期指Pod的状态轮转过程，在最大限度保证集群业务连续性的同时，通过用户定义的声明去转换在服务中的期望状态，使用控制器协调管理以实现生命周期的转换，保证K8s保证服务的实时性、可靠性和高效性。

17. Init类型容器有什么特点，主要用途？

答：

• 特点：
  • 会在Pod内的应用容器启动前运行；
  • 正常运行后最终会处于completed状态；
  • 会在下一个容器启动前启动。
• 主要用途：
  • 用来做节点的初始化检测（如数据库连接情况）；
  • 初始化配置，用来确定Pod可以正常运行；
  • 防止应用容器在运行时出故障影响集群性能等（业务分离、故障隔离）。

18. Sidecar类型容器和Init容器的区别在哪？

答：

• Init容器：在应用容器运行之前就会完成从启动到completed的过程；
• Sidecar容器：生命周期是伴随着应用容器一起运行的，它会协助应用容器完成一些诸如日志转发、代理等辅助性工作，增强和扩展应用容器的性能。

19. 什么是静态Pod？

答：

• 静态Pod会通过镜像映射到API服务来显示，但它不由API服务器监管，而是直接被kubelet的守护进程管理；
• 每一个静态Pod都会被绑定在一个指定节点的kubelet上，其名字后带有所运行节点主机名作为后缀；
• 把yaml文件复制到/etc/kubernetes/manifests就会将此文件创建的容器初始化为静态Pod。

20. 说明K8s控制器的作用？

答：

• Kubernetes控制器是集群的核心控制组件，通过持续的监控和调节集群状态，并将状态转换为需要的期望状态；
• 每个控制器都管理集群的某个特定方面，可以在有需求时改变集群的状态以适应实时需求，协助容器完成生命周期中的状态转换；
• 它也是声明式编程的核心组件。

21. 什么是ReplicaSet，说明它的主要用途。

答：

• ReplicaSet（副本集）**是 Kubernetes 中的一种控制器资源，它可以维护集群中始终有一组处于稳定运行状态的Pod副本；
• 副本的数量是可以设置的，它们之间是完全相同的，随机取出来一个都是可以提供服务的；
• 它是 Deployment 的底层实现（通常不直接使用，而是通过 Deployment 间接管理），通过选择器（Selector）匹配并监控 Pod，并在副本数量不足或过多时自动调整。

22. Deployment控制器是如何工作的，举例说明其常见用途。

答：

• Deployment控制器通过管理ReplicaSet来进行集群控制，确保集群中任何时间都有指定数量的Pod运行；
• 在进行版本更新或版本回调时，可以使用Deployment创建多个ReplicaSet；
• 若当前被使用的ReplicaSet里的应用容器需要进行版本变更时，可以实现无中断部署，Deployment会立刻重新链接上另一个完全相同的ReplicaSet（内部也有完全相同的Pod）来持续服务，在用户看来服务是没有任何中断的。

23. 解释DaemonSet，列举其使用场景。

答：

• DaemonSet控制器能确保Pod在集群内多个节点的同步管理，同时安装同时移除；
• 典型的应用场景：
  • 控制集群内各个节点的集群守护进程；
  • 日志收集守护进程；
  • 监控守护进程。

24. 什么是StatefulSet，其主要作用是什么？

答：

• StatefulSet控制器用来管理相同容器约束的一组Pod，会给这些Pod分配一个唯一的粘性ID，使得它们具有命名规范性，以满足一些如回滚、日志查询、版本滚动等操作；
• 同时可以长期维持集群中的Pod保持在所定义的数量，使集群能稳定提供服务。

25. 说明Job与CronJob的功能。

答：

• Job：用来处理一次性短时任务，确保任务完成指定次数的成功执行；
• CronJob：负责管理周期性定时任务，类似 Linux 的 crontab；CronJob会随着服务的启动与完成反复创建、回收以保证资源利用率。

26. Kubernetes如何在集群的Pod之间提供网络服务？

答：

• Kubernetes中提供了Service服务来供其集群内部不同Pod之间作为前后端来进行通信以维持网络服务；
• Service作为一个特殊的进程拥有自己的虚拟IP，前端Pod通过Service来连接需要提供工作负载的后端Pod，此时Service会在多个Pod副本中随机分配一个来提供所需服务。

27. 解释iptables和IPVS代理模式Service的区别。

答：

• iptables代理模式：
  • Service会对每一个创建的Service配置iptables规则，这样就能够捕获这个节点上的端口请求，将其重定向到集群内部的Pod上；
  • 在此模式下网络流量会由Linux netfilter处理，无需用户切换空间去处理这些流量。
• IPVS代理模式：
  • Service会调用netlink建立并定时同步IPVS规则使得流量可以被定向到后端的Pod中去；
  • IPVS代理模式在内核空间工作，建立信道的延迟低，较iptables模式有更好的性能和更高的网络吞吐量。

28. 举例说明ClusterIP类型Service的用法。

答：

• ClusterIP类型服务会通过搜索集群内部暴露的IP来提供服务，规定只能在集群内部访问。
• 示例：
  • 在定义服务时不选择type类型会默认选择ClusterIP类型服务；
  • 根据此yml文件创建的服务会搜索集群内标签为nginx的Pod并把容器的80端口映射到Service上的8000端口以对外暴露；
  • 接着使用kubectl get service命令可详细查看服务信息。
  • 此时通过访问service提供的IP以及端口：10.108.51.155:8000来访问集群内部。

29. 举例说明NodePort类型Service的用法。

答：

• NodePort类型Service会把自动创建的ClusterIP服务建立的集群内部访问IP和端口映射（路由）到一个可供外部访问的静态IP和端口上，支持使用集群外部的IP访问该服务，相当于给CluserIP类型的服务添加了外部接口。
• 示例：
  • 在定义服务时选择type为NodePort类型服务；
  • 根据此yml文件创建的服务会搜索集群内标签为nginx的Pod并把容器的80端口映射到Service上的8000端口，Service提供的8000端口又会与集群外部的31788端口建立映射；
  • 接着使用kubectl get service命令可详细查看服务信息。
  • 此时通过访问公网静态IP以及外部端口就可以访问集群内部。

30. 举例说明Headless类型Service的用法。

答：

• Headless类型服务只能从Pod内部测试，需要到集群内部去查看IP信息。
• 示例：
  • 在定义服务时声明clusterIP为None即可将此服务设置为Headless类型服务；
  • 使用kubectl get service即可查看服务信息；
  • 可以通过创建一个新的测试节点进入集群内部，搜索类型为headless的内部Pod；
  • 通过显示IP来实现控制访问。