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"
