25. 说明 Job 与 CronJob 的功能
Job
功能：
-
用于运行一次性任务（批处理任务），确保一个或多个 Pod 成功完成任务后退出。
-
适用于数据处理、备份、测试等场景，任务完成后 Pod 不会自动重启。
特点：
-
任务完成机制：
-
当 Pod 成功完成任务（容器退出码为
0），Job 标记为完成。 -
如果 Pod 失败（非
0退出码），Job 会根据配置重试（通过spec.backoffLimit控制重试次数）。
-
-
并行控制：
-
支持并行运行多个 Pod（通过
spec.parallelism设置并发数）。 -
可通过
spec.completions指定需要成功完成的 Pod 总数。
-
示例：
apiVersion: batch/v1
kind: Job
metadata:name: pi-calculation
spec:completions: 1template:spec:containers:- name: piimage: perlcommand: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: NeverCronJob
功能：
-
基于时间计划（Cron 表达式）周期性运行 Job，类似于 Linux 的
crontab。 -
适用于定时任务（如每日日志清理、定期数据同步）。
特点：
-
调度语法：
-
使用标准 Cron 表达式（如
"0 * * * *"表示每小时运行一次）。
-
-
任务历史记录：
-
保留最近成功或失败的 Job 记录（通过
spec.successfulJobsHistoryLimit和spec.failedJobsHistoryLimit控制）。
-
-
并发策略：
-
如果前一个 Job 未完成，可以配置是否允许并发运行（
spec.concurrencyPolicy可选Allow、Forbid或Replace）。
-
示例：
apiVersion: batch/v1
kind: CronJob
metadata:name: daily-cleanup
spec:schedule: "0 0 * * *" # 每天午夜执行jobTemplate:spec:template:spec:containers:- name: cleanupimage: busyboxcommand: ["/bin/sh", "-c", "rm -rf /tmp/old-files"]restartPolicy: OnFailure26. Kubernetes 如何在集群的 Pod 之间提供网络服务？
Kubernetes 通过以下机制实现 Pod 间网络通信：
1. 网络模型要求
-
每个 Pod 拥有唯一 IP：
-
所有 Pod 直接通过 IP 地址通信，无需 NAT。
-
IP 分配给 Pod 而非节点，确保跨节点通信透明化。
-
-
Flat 网络空间：所有 Pod 无论位于哪个节点，都在同一逻辑网络中。
2. 核心组件
-
CNI（Container Network Interface）插件：
-
负责为 Pod 分配 IP 并配置网络规则（如 Calico、Flannel、Cilium）。
-
实现跨节点网络互通（通常基于 Overlay 网络或 BGP 路由）。
-
-
kube-proxy：
-
维护节点上的网络规则（如 iptables/IPVS），将 Service 的虚拟 IP（ClusterIP）映射到后端 Pod。
-
3. 通信流程
-
Pod-to-Pod 直接通信：
-
通过 CNI 插件实现的网络方案（如 VXLAN、主机路由）直接路由流量。
-
-
通过 Service 通信：
-
Service 提供稳定的虚拟 IP 和 DNS 名称，流量由 kube-proxy 负载均衡到后端 Pod。
-
4. DNS 服务
-
CoreDNS：为 Service 和 Pod 提供集群内 DNS 解析（如
my-svc.default.svc.cluster.local）。
27. 解释 iptables 和 IPVS 代理模式 Service 的区别
iptables 代理模式的 Service：
- kube-proxy 会监视 K8s 控制节点对 Service 对象和 Endpoints 对象的添加和移除。对每个
Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，
进而将请求重定向到 Service 的一组后端中的某个 Pod 上面。对于每个 Endpoints 对象，它也
会配置 iptables 规则，这个规则会选择一个后端组合。默认的策略是，kube-proxy 在
iptables 模式下随机选择一个后端。
使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在
用户空间和内核空间之间切换。
IPVS 代理模式的 Service：
- 在 IPVS (IP Virtual Server)模式下，kube-proxy 监视 K8s 服务和端点，并调用 netlink
接口创建相应的 IPVS 规则，并定期将 IPVS 规则与 K8s 服务和端点同步。该控制循环可确保
IPVS 状态与所需状态匹配。访问服务时，IPVS 将流量定向到其中之一的后端 Pod。
IPVS 代理模式基于类似于 iptables 模式的 netfilter 挂钩函数，但是使用哈希表作为基础
数据结构，并且在内核空间中工作，这意味着，与 iptables 模式下的 kube-proxy 相比，IPVS
模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他
代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。
对比总结
| 特性 | iptables | IPVS |
|---|---|---|
| 实现基础 | iptables 规则链 | 内核 IPVS 模块 |
| 性能 | 随规则数量线性下降 | 恒定时间复杂度（O(1)） |
| 负载均衡算法 | 仅随机 | 轮询、最少连接、目标哈希等 |
| 适用规模 | 中小集群（<1000 Service） | 大规模集群 |
| 会话保持 | 不支持 | 支持 |
配置示例：
在 kube-proxy 中指定模式：
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs" # 默认为 "iptables"
