10 个问题测试你对 K8s 的理解程度【转】

10 个问题测试你对 K8s 的理解程度

问题

1. 在一个有两个节点的集群中，一个节点有 Pod，另一个没有，新的 Pod 会被调度到哪个节点？
2. 如果容器中的应用程序遇到 OOM（内存不足）错误，容器会重启，还是整个 Pod 会被重新创建？
3. 应用程序配置（如环境变量或 ConfigMap 更新）是否可以动态应用而无需重新创建 Pod？
4. 一旦创建了 Pod，即使用户不采取进一步操作，Pod 是否稳定？
5. ClusterIP 类型的 Service 能否确保 TCP 流量的负载均衡？
6. 应该如何收集应用程序日志，是否存在日志丢失的风险？
7. 如果 HTTP Server Pod 的 livenessProbe 正常工作，是否意味着应用程序没有问题？
8. 应用程序如何扩展以应对流量波动？
9. 当你执行 kubectl exec -it <pod> -- bash 时，你是否登录到了 Pod？
10. 如果 Pod 中的容器反复退出并重启，你会如何排查问题？

答案

1. 在一个有两个节点的集群中，一个节点有 Pod，另一个没有，新的 Pod 会被调度到哪个节点？

调度过程涉及多个阶段，结果取决于 Pod 亲和性、污点和容忍度以及调度插件的配置。假设默认配置且两个节点资源可用性相同，NodeResourcesFit 插件起关键作用。其评分策略包括 LeastAllocated（默认，优先选择资源使用最少的节点）、MostAllocated（优先选择资源使用较多的节点）和 RequestedToCapacityRatio（平衡资源利用率）。使用 MostAllocated 策略，新 Pod 会被调度到已有 Pod 的节点，而其他两种策略则倾向于空节点。

2. 如果容器中的应用程序遇到 OOM（内存不足）错误，容器会重启，还是整个 Pod 会被重新创建？

当容器内存不足时，通常会根据 Pod 的 RestartPolicy（默认为 Always）重启容器。Pod 本身保持不变。但在极端情况下，如节点内存压力过大，Pod 可能会被驱逐，导致其重新创建。

3. 应用程序配置（如环境变量或 ConfigMap 更新）是否可以动态应用而无需重新创建 Pod？

环境变量无法动态更新。但如果 ConfigMap 以文件形式挂载（不使用 subPath），则可以动态应用更新。同步延迟取决于 kubelet 的 syncFrequency（默认 1 分钟）和 configMapAndSecretChangeDetectionStrategy。

4. 一旦创建了 Pod，即使用户不采取进一步操作，Pod 是否稳定？

Pod 并不保证稳定。资源短缺或网络中断等因素可能导致 Pod 被驱逐，即使没有用户干预。

5. ClusterIP 类型的 Service 能否确保 TCP 流量的负载均衡？

基于 ClusterIP 的 Service 依赖 Linux 内核的 Netfilter 进行负载均衡。其 connection tracking 机制为已建立的 TCP 连接保持会话持久性。这可能导致长连接负载分布不均。

6. 应该如何收集应用程序日志，是否存在日志丢失的风险？

日志可以输出到 stdout/stderr 或写入文件。对于 stdout/stderr，日志保存在节点上，可以使用 Fluentd 或 Filebeat 等日志代理收集（通常以 DaemonSet 部署）。但如果 Pod 被删除，日志可能在代理收集之前丢失。将日志写入持久存储的文件可以防止丢失。

7. 如果 HTTP Server Pod 的 livenessProbe 正常工作，是否意味着应用程序没有问题？

从应用程序角度看，livenessProbe 仅检查应用程序是否存活，而不检查其功能是否正常。应用程序可能处于降级状态但仍通过探针。从网络角度看，livenessProbe（如 httpGet）检查来自节点 kubelet 的请求，这并不能保证跨节点网络的可靠性。

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

Kubernetes 支持水平 Pod 自动扩展（HPA）和垂直 Pod 自动扩展（VPA）。VPA 涉及重新创建 Pod 并调整资源，限制了其使用场景。HPA 更常用，根据 CPU 使用率、请求速率或自定义指标动态调整 Pod 数量。外部系统也可以通过向 kube-apiserver 发送请求触发扩展。

9. 当你执行 kubectl exec -it <pod> -- bash 时，你是否登录到了 Pod？

不，kubectl exec 需要指定容器（默认为单容器 Pod 中的唯一容器）。Pod 是隔离的 Linux 命名空间的集合。容器共享 Network、IPC 和 UTS 命名空间，而 PID 和 Mount 命名空间保持独立。kubectl exec -it <pod> -- bash 在目标容器的隔离环境中启动一个新的 bash 进程，但并未“登录”到 Pod。

10. 如果 Pod 中的容器反复退出并重启，你会如何排查问题？

如果容器反复崩溃，kubectl exec 将无法使用。可以检查节点和容器日志，检查 Pod 的状态，并使用 kubectl debug 启动临时容器以调查环境和依赖关系。

转自

10 个问题测试你对 K8s 的理解程度
https://mp.weixin.qq.com/s/QQG-uakVUPQz4JpMtXZ97g