Kubernetes自测题

1. 假设集群有 2 个 node 节点，其中一个有 pod，另一个则没有，那么新的 pod 会被调度到哪个节点上？

调度过程需要经过一系列处理阶段：

各个阶段的配置、以及 Pod 的配置（强制调度、亲和性、污点容忍等等）可能都会影响调度的结果。

然而，在不考虑各种配置、节点资源也相同的情况下，默认插件 NodeResourcesFit 的评分策略会起到比较关键的作用，NodeResourcesFit 有三种评分策略：LeastAllocated（默认，优先选择资源使用率最低的节点）、MostAllocated（优先选择资源使用率较高的节点）和 RequestedToCapacityRatio（平衡节点的资源使用率）。这也就是说，在使用 MostAllocated 策略的时候，新的 pod 会被调度到已经有 pod 的节点上，而使用另外两种策略时，则调度到没有 pod 的节点。

2. 应用程序通过容器的形式运行，如果 OOM（Out-of-Memory）了，是容器重启还是所在的 Pod 被重建？

当容器 OOM 了，一般情况下根据 Pod 的 RestartPolicy 配置（默认是 Always），容器会被重启，Pod 不会被重建。但在特殊情况下，节点内存压力很大时，可能会触发 Pod 驱逐，从而导致 Pod 被重建。

3. 应用程序配置如环境变量或者 ConfigMap 可以不重建 Pod 实现动态更新吗？

环境变量无法动态更新，ConfigMap 通过挂载的方式可以动态更新，但要求挂载时不能使用 subPath，挂载的同步延时受 kubelet 的配置 syncFrequency（默认 1 分钟）和 configMapAndSecretChangeDetectionStrategy 影响。

4. Pod 被创建后是稳定的吗，即使用户不进行任何操作？

即使用户不操作，也可能发生节点资源不足或者网络异常导致 Pod 被驱逐。

5. 使用 ClusterIP 类型的 Service 能保证 TCP 流量的负载均衡吗？

ClusterIP 类型的 Service 不论使用的是 iptables 还是 ipvs，其都依赖于 Linux 内核的 Netfilter，而其内部的 connection tracking 机制会跟踪和记录每个连接的状态，进而让已经建立了 TCP 连接的双方一直使用这条连接。所以，针对长连接，是有可能出现负载不均衡的情况。

6. 应用日志要怎么采集，会不会有丢失的情况？

应用日志一般输出为 stdout/stderr，或者写入日志文件。针对前者，容器日志会被保存到节点上的特定位置，此时可以使用日志代理（如 Fluentd、Filebeat）并部署为 Daemonset 的方式进行采集，但是存在日志丢失的可能，因为一旦 pod 被删除，对应的容器日志文件也会被删除，而日志代理可能还未完成全部日志的采集。通过挂载持久化存储并写入日志文件的方式则可以避免丢失。

7. 某个 HTTP Server Pod 的 livenessProbe 正常是否就一定没问题？

站在应用的角度看，livenessProbe 只检查应用是否存活，无法验证其功能是否正常，例如应用可能进入了非健康但仍存活的状态。
站在网络的角度看，livenessProbe（假设配置的是 httpGet）是由本机的 kubelet 发起的请求，无法保证跨节点的网络是正常的。

8. 应用程序如何扩展以应对流量波动的情况？

Kubernetes 提供了水平扩展（HPA）和垂直扩展（VPA）两种机制，由于 VPA 不是原地资源扩展，会删除 Pod 再创建，使用场景往往受限，所以使用更多是 HPA，可以根据指标（如 CPU 使用率、请求速率、其它自定义指标）动态调整 Pod 数量。
当然，也可以在外部监测指标然后向 kube-apiserver 发起请求扩展 Pod 的数量。

9. 当你执行 kubectl exec -it <pod> -- bash 之后是登录到了 pod 里吗？

首先，使用 kubectl exec 需要指定容器，当 Pod 只有一个容器时则可以忽略。其次，Pod 是一组独立的 Linux 命名空间，容器本质上是一个进程，Pod 内容器共享 Network、IPC、UTS namespace，而每个容器的 PID、Mount namespace 则是独立的。"登录"的说法并不准确，kubectl exec -it <pod> -- bash 既不是进入了 Pod，也不是进入了容器，而是在目标容器的隔离环境中创建了一个新的 bash 进程。

10. 如果 Pod 里的容器反复退出并重启，如何排查？

如果 Pod 里的容器反复退出并重启，是无法使用 kubectl exec 的。此时，除了检查节点或容器状态和日志之外，还可以使用 kubectl debug 的方式在 Pod 上启动一个临时容器，用于检查环境和依赖。

11.Kubernetes和Openstack发展方向是怎样的？它们之间存在很多分歧吗？

Kubernetes和Openstack是两个完全不同的东西；真的没有必要去比较它们，因为它们根本从来都碰不到一起。你可以在Openstack上跑Kubernetes，你也可以使用Kubernetes来编排Openstack，但是它们始终还是两个截然不同的东西。

12. 如何开发一个自定义的Kubernetes Operator？

答：开发步骤包括：

• 定义CRD：自定义资源定义。
• 编写Controller：处理CRD事件。
• 部署Operator：将Operator部署到集群中。

13. 什么是Kubernetes的Serverless架构？ 

答：Serverless架构是指在Kubernetes中运行无服务器应用，通过函数计算实现自动扩展和资源管理。

14. 什么是无头服务？

无头服务（headless service）是一种不依赖于ClusterIP就能与服务发现机制交互的服务。它允许你直接访问Pod，而无需通过代理。当既不需要负载均衡，也不需要单个服务IP时，无头服务就很有用。

15. 无头service使用场景：

无头service一般用于有状态的应用场景，如Kaka集群、Redis集群等，这类pod之间需要相互通信相互组成集群，不在需要所谓的service负载均衡。

16. 无头service和普通的service有什么区别，无头service使用场景是什么？

答：无头service没有cluster ip，在定义service时设置 service.spec.clusterIP：None，就表示创建的是无头service。

17. 如何在Kubernetes中实现边缘计算？ 

答：实现步骤包括：

• 部署边缘节点：在边缘设备上部署Kubernetes节点。
• 使用KubeEdge：连接边缘节点和中心集群。
• 配置网络：实现边缘节点与中心集群的通信。
• 部署应用：在边缘节点上部署应用。

18. 请举例说明Kubernetes推荐的安全措施。

Kubernetes标准的安全措施示例包括定义资源配额、支持审计、限制etcd访问、定期更新环境安全性、进行网络分段、定义严格的资源策略、持续扫描安全漏洞，以及使用来自授权仓库的镜像。

19. 在 Kubernetes 中，为了保证 Pod 重启后其 IP 地址不变，通常需要采取一些特定的措施和配置。以下是保证 Pod IP 稳定性的一些关键点：

1. 使用 StatefulSet ：StatefulSet 是 Kubernetes 的一种资源对象，它保证了 Pod 的名称和网络标识的稳定性。即使在 Pod 重启或迁移后，StatefulSet 也能够确保 Pod 的 DNS 名称和 IP 地址保持不变。

2. Service 与 Endpoint 的关联 ：通过创建 Service 并将其与 Pod 的 Endpoint 关联，即使 Pod 重启，只要 Endpoint 中的 Pod 名称不变，Service 就能保持与 Pod 的稳定连接。这样，即使 Pod 的 IP 发生变化，Service 也可以通过 Endpoint 来维持稳定的访问。

3. CNI（容器网络接口）的配置 ：CNI 负责 Pod 的网络配置，包括 IP 分配。通过正确配置 CNI，可以确保 Pod 在重启后仍然保持相同的 IP 地址。这可能涉及到对 IPAM（IP 地址管理）插件的配置，以确保 IP 地址的连续性。

4. 避免手动指定 IP ：不建议手动为 Pod 指定 IP 地址，因为这可能导致在 Pod 重启时 IP 地址的变化。相反，应该让 Kubernetes 的网络插件自动管理 IP 分配。

5. 更新镜像而不改变 IP ：在某些情况下，可能需要更新 Pod 中的容器镜像。通过 kubectl 命令修改容器镜像时，可以保持 Pod 的 IP 地址不变。这通常涉及到编辑现有的 Pod 定义或使用kubectl set image命令来更新镜像。

6. 监控和日志记录 ：持续监控 Pod 的状态和使用kubectl describe命令来查看 Pod 的详细信息，可以帮助理解 Pod 重启后 IP 地址是否发生了变化。日志记录也是排查问题的重要手段。

综上所述，通过这些措施，可以在 Kubernetes 中实现 Pod 重启后其 IP 地址的稳定性，从而保证了服务的连续性和可靠性。

20. 你能简要介绍一下 Kubernetes 控制管理器吗？

多个控制器进程在主节点上运行，但是一起编译为单个进程运行，即 Kubernetes 控制器管理器。因此，Controller Manager 是一个嵌入控制器并执行命名空间创建和垃圾收集的守护程序。它拥有与 API 服务器通信以管理端点的责任。

21. pod的重启策略有哪些？

pod重启容器策略是指针对pod内所有容器的重启策略，不是重启pod，其可以通过restartPolicy字段配置pod重启容器的策略，如下：

    Always: 当容器终止退出后，总是重启容器，默认策略就是Always。

    OnFailure: 当容器异常退出，退出状态码非0时，才重启容器。

    Never: 当容器终止退出，不管退出状态码是什么，从不重启容器。

22. 就绪探针（ReadinessProbe探针）与存活探针（livenessProbe探针）区别是什么？

两者作用不一样，存活探针是将检查失败的容器杀死，创建新的启动容器来保持pod正常工作；

就绪探针是，当就绪探针检查失败，并不重启容器，而是将pod移出endpoint，就绪探针确保了service中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题。

23. 简单描述一下pod的终止过程

1、用户向apiserver发送删除pod对象的命令；
2、apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；
3、将pod标记为terminating状态；
4、kubectl在监控到pod对象为terminating状态了就会启动pod关闭过程；
5、endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；
6、如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会以同步的方式启动执行（preStop钩子一般定义了如何优雅的结束进程；）；
7、pod对象中的容器进程收到停止信息；
8、宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；
9、kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。

24. pause容器作用是什么？

每个pod里运行着一个特殊的被称之为pause的容器，也称根容器，而其他容器则称为业务容器；创建pause容器主要是为了为业务容器提供 Linux命名空间，共享基础：包括 pid、icp、net 等，以及启动 init 进程，并收割僵尸进程；这些业务容器共享pause容器的网络命名空间和volume挂载卷。

25. service是如何与pod关联的？

答案是通过标签选择器，每一个由deployment创建的pod都带有标签，这样，service就可以定义标签选择器来关联哪些pod是作为其后端了，就是这样，service就与pod管联在一起了。

26. service的类型有哪几种？

service的类型一般有4中，分别是：

    ClusterIP：表示service仅供集群内部使用，默认值就是ClusterIP类型

    NodePort：表示service可以对外访问应用，会在每个节点上暴露一个端口，这样外部浏览器访问地址为：任意节点的IP：NodePort就能连上service了

    LoadBalancer：表示service对外访问应用，这种类型的service是公有云环境下的service，此模式需要外部云厂商的支持，需要有一个公网IP地址

    ExternalName：这种类型的service会把集群外部的服务引入集群内部，这样集群内直接访问service就可以间接的使用集群外部服务了

一般情况下，service都是ClusterIP类型的，通过ingress接入的外部流量。

27. 简述kube-proxy ipvs原理?

答：IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式；在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配；可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗；

28. 简述kube-proxy ipvs和iptables的异同?

答：iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。与iptables相比，IPVS拥有以下明显优势：为大型集群提供了更好的可扩展性和性能；支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；支持服务器健康检查和连接重试等功能；可以动态修改ipset的集合，即使iptables的规则正在使用这个集合；

29. 简述Kubernetes网络模型?

答：Kubernetes网络模型中每个Pod都拥有一个独立的IP地址，不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问；同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口；在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈；

30. 简述Kubernetes CNI模型?

答：Kubernetes CNI模型是对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。

31. 简述Kubernetes网络策略原理?

​答：Network Policy的工作原理主要为：policy controller需要实现一个API Listener，监听用户设置的Network Policy定义，并将网络访问规则通过各Node的Agent进行实际设置（Agent则需要通过CNI网络插件实现）；

32. 简述Kubernetes PV和PVC?

答：PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”；PVC则是用户对存储资源的一个“申请”。

33. 简述Kubernetes Worker节点加入集群的过程?

​答：在该Node上安装Docker、kubelet和kube-proxy服务； 然后配置kubelet和kubeproxy的启动参数，将Master URL指定为当前Kubernetes集群Master的地址，最后启动这些服务； 通过kubelet默认的自动注册机制，新的Worker将会自动加入现有的Kubernetes集群中； Kubernetes Master在接受了新Worker的注册之后，会自动将其纳入当前集群的调度范围；

34. 简述Kubernetes如何进行优雅的节点关机维护?

​答：由于Kubernetes节点运行大量Pod，因此在进行关机维护之前，建议先使用kubectl drain将该节点的Pod进行驱逐，然后进行关机维护。

35. 简述Kubernetes Metric Service?

答：在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成；

36. k8s是怎么进行服务注册的?

​答：（1）Service创建的时候会向 API Server 用 POST 方式提交一个新的 Service 定义，这个请求需要经过认证、鉴权以及其它的准入策略检查过程之后才会放行；（2）CoreDns 会为Service创建一个dns记录，Service 得到一个 ClusterIP（虚拟 IP 地址），并保存到集群数据仓库；（3）在集群范围内传播 Service 配置。

37. etcd集群节点可以设置为偶数个吗，为什么要设置为基数个呢？

不能，也不建议这么设置。底层的原理，涉及到集群的脑裂 。

38. keepalived的2种心跳传播模式？

keepalived有2种vrrp协议心跳传播模式，一种是组播模式，一种是单播模式，keepalived默认在组播模式下工作，主服务器会往组播地址如224.0.0.18发送心跳包，当局域网内有多个keepalived实例的时候，如果都用组播模式，会存在冲突干扰的情况，所以官方建议使用单播模式通信，单播模式就是点对点通行，即主向备服务器一对一的发送心跳包，减少脑裂现象。

--end--