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

25. 说明 Job 与 CronJob 的功能

Job

功能：

• 用于运行一次性使命（批处置惩罚使命），确保一个或多个 Pod 成功完成使命退却出。
  
• 实用于数据处置惩罚、备份、测试等场景，使命完成后 Pod 不会主动重启。
  

特点：

• 使命完成机制：
  
  
  
  • 当 Pod 成功完成使命（容器退出码为 0），Job 标志为完成。
    
  • 假如 Pod 失败（非 0 退出码），Job 会根据配置重试（通过 spec.backoffLimit 控制重试次数）。
    
  
  
• 并行控制：
  
  
  
  • 支持并行运行多个 Pod（通过 spec.parallelism 设置并发数）。
    
  • 可通过 spec.completions 指定需要成功完成的 Pod 总数。
    
  
  

示例：

1. apiVersion: batch/v1
2. kind: Job
3. metadata:
4.   name: pi-calculation
5. spec:
6.   completions: 1
7.   template:
8.     spec:
9.       containers:
10.       - name: pi
11.         image: perl
12.         command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
13.       restartPolicy: Never

复制代码

---

CronJob

功能：

• 基于时间操持（Cron 表达式）周期性运行 Job，雷同于 Linux 的 crontab。
  
• 实用于定时使命（如每日日志清算、定期数据同步）。
  

特点：

• 调理语法：
  
  
  
  • 使用标准 Cron 表达式（如 "0 * * * *" 表示每小时运行一次）。
    
  
  
• 使命历史记载：
  
  
  
  • 保留迩来成功或失败的 Job 记载（通过 spec.successfulJobsHistoryLimit 和 spec.failedJobsHistoryLimit 控制）。
    
  
  
• 并发策略：
  
  
  
  • 假如前一个 Job 未完成，可以配置是否允许并发运行（spec.concurrencyPolicy 可选 Allow、Forbid 或 Replace）。
    
  
  

示例：

1. apiVersion: batch/v1
2. kind: CronJob
3. metadata:
4.   name: daily-cleanup
5. spec:
6.   schedule: "0 0 * * *"  # 每天午夜执行
7.   jobTemplate:
8.     spec:
9.       template:
10.         spec:
11.           containers:
12.           - name: cleanup
13.             image: busybox
14.             command: ["/bin/sh", "-c", "rm -rf /tmp/old-files"]
15.           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. 通讯流程

• 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 模式还支持更高的网络流量吞吐量。

---

对比总结

特性iptablesIPVS实现底子iptables 规则链内核 IPVS 模块性能随规则数目线性下降恒定时间复杂度（O(1)）负载均衡算法仅随机轮询、最少连接、目标哈希等实用规模中小集群（<1000 Service）大规模集群会话保持不支持支持 配置示例：
在 kube-proxy 中指定模式：

1. apiVersion: kubeproxy.config.k8s.io/v1alpha1
2. kind: KubeProxyConfiguration
3. mode: "ipvs"  # 默认为 "iptables"

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。