玛卡巴卡的k8s知识点问答题（七）

25. 说明 Job 与 CronJob 的功能

Job

功能：

• 用于运行一次性任务（批处理任务），确保一个或多个 Pod 成功完成任务后退出。

• 适用于数据处理、备份、测试等场景，任务完成后 Pod 不会自动重启。

特点：

1. 任务完成机制：

   • 当 Pod 成功完成任务（容器退出码为 0），Job 标记为完成。

   • 如果 Pod 失败（非 0 退出码），Job 会根据配置重试（通过 spec.backoffLimit 控制重试次数）。

2. 并行控制：

   • 支持并行运行多个 Pod（通过 spec.parallelism 设置并发数）。

   • 可通过 spec.completions 指定需要成功完成的 Pod 总数。

示例：

apiVersion: batch/v1
kind: Job
metadata:
  name: pi-calculation
spec:
  completions: 1
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

---

CronJob

功能：

• 基于时间计划（Cron 表达式）周期性运行 Job ，类似于 Linux 的 crontab。

• 适用于定时任务（如每日日志清理、定期数据同步）。

特点：

1. 调度语法：

   • 使用标准 Cron 表达式（如 "0 * * * *" 表示每小时运行一次）。

2. 任务历史记录：

   • 保留最近成功或失败的 Job 记录（通过 spec.successfulJobsHistoryLimit 和 spec.failedJobsHistoryLimit 控制）。

3. 并发策略：

   • 如果前一个 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: cleanup
            image: busybox
            command: ["/bin/sh", "-c", "rm -rf /tmp/old-files"]
          restartPolicy: OnFailure

---

26. 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. 通信流程

1. Pod-to-Pod 直接通信：

   • 通过 CNI 插件实现的网络方案（如 VXLAN、主机路由）直接路由流量。

2. 通过 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"