Kubernetes 十大问题测试你对K8s的了解程度

Kubernetes 十个问题

1. 在一个包含两个节点的集群中，一个节点上有Pod，另一个节点上没有，新的Pod会被调度到哪个节点上？
2. 如果运行在容器中的应用程序遇到OOM（内存溢出）错误，容器会重启，还是整个Pod会重建？
3. 应用配置如环境变量或ConfigMap的更新是否可以在不重新创建Pod的情况下动态更新？
4. 一旦Pod被创建，即便用户不再进行任何操作，Pod是否就能保持稳定？
5. 类型为ClusterIP的Service能否确保TCP流量的负载均衡能力？
6. 应用日志如何收集，收集过程中是否会丢失日志？
7. 如果HTTP服务器Pod的livenessProbe运行正常，是否意味着应用程序没有问题？注意，livenessProbe正常运行仅表示Pod状态良好，不保证应用程序无问题。
8. 应用程序如何扩展以应对流量波动？
9. 当你执行kubectl exec -it <pod> -- bash时，是否进入Pod？
10. 如果Pod中的容器反复退出并重启，应如何排查和解决该问题？

你能又快又准地回答这些问题，抓住要点吗？

安排计划的过程包括几个步骤：

结果取决于诸如 Pod 亲和性、污点和容忍度以及调度插件之类的配置。然而，假设默认配置且两个节点上的资源可用性相同，NodeResourcesFit 插件扮演着关键角色。其评分策略包括 LeastAllocated（默认，优先考虑资源使用最少的节点）、MostAllocated（优先选择资源使用更多的节点）和 RequestedToCapacityRatio（平衡资源使用率）。使用 MostAllocated 策略，新 Pod 会被调度到已有 Pod 的节点，而其他两种策略则更偏好空闲节点。

当容器内存不足时，它通常会根据Pod的RestartPolicy（默认为Always）重新启动，而Pod本身不会受到影响。然而，在极端情况下，例如节点内存压力过大，Pod可能会被驱逐，从而重建Pod。

环境变量不能动态更新。然而，如果以文件形式挂载（而不是使用 subPath），ConfigMap 的更新可以动态生效。通常，同步延迟主要由 kubelet 的 syncFrequency（默认为每分钟一次）和 ConfigMap 和 Secret 的变更检测策略 决定。

Pod 并不能保证稳定。资源不足或网络中断等问题，即便没有用户干预，也可能导致 Pod 被淘汰。

ClusterIP 基础的服务依赖于 Linux 内核的 Netfilter 实现负载均衡。其 连接跟踪 机制保持已建立 TCP 连接的会话持久性。这可能会导致长期存活的连接的负载分布不均。

日志可以输出到 stdout/stderr，或者写入到文件。在 stdout/stderr 的情况下，日志会被保存在节点上，并通过这些日志代理（如 Fluentd 或 Filebeat，通常作为 DaemonSet 部署）收集。如果一个 Pod 被删除，其日志可能在代理收集之前就已经丢失。将日志写入持久存储中的文件可以避免日志丢失。

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

Kubernetes 支持水平 Pod 自动扩展（HPA）和垂直 Pod 自动扩展（VPA）。VPA 通过重新创建并调整资源的 Pod 来实现，但其应用场景较为有限。相比之下，HPA 更为常用，它可以根据 CPU 使用率、请求数量或自定义指标等动态调整 Pod 的数量。外部系统也可以通过向 kube-apiserver 发送请求来触发扩展操作。

不，kubectl exec 需要指定一个容器（默认为单容器 Pod 中的唯一容器）。Pod 是一组隔离的 Linux 命名空间。容器共享 Network、IPC 和 UTS 命名空间，而每个容器的 PID 和 Mount 命名空间则保持独立。执行 kubectl exec -it <pod> -- bash 启动一个新的 bash 会话，但并不会真正登录到 Pod 中。

如果一个容器频繁崩溃，kubectl exec 就无法使用了，。相反，可以查看节点和容器的日志，检查 Pod 的状态，，并使用 kubectl debug 来启动一个临时容器来调查环境和依赖项。