kubernetes（K8s）学习笔记：第七期核心知识点自测与详解

本自测解析针对 Kubernetes 系列第七期（网络与服务暴露------Service + kube-proxy + Ingress）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固 Kubernetes 网络与服务暴露的核心技能。
文章索引：kubernetes（K8s）学习笔记（第七期）：网络与服务暴露

更多自我检测系列欢迎浏览：每日知识点小问答

题目一：Service 的核心作用与 Endpoints 机制

题目：Kubernetes 中 Service 的核心作用是什么？Service 与 Endpoints 之间是什么关系？当后端 Pod 发生变动时，Endpoints 会自动更新吗？

考查知识点

Service 概述与基本管理 ------ 第七期 §1
Service 与 Endpoints 的关系

详细解答

Service 的核心作用：

固定 IP 和 DNS 名称：无论后端 Pod 如何变化，Service 的 IP 和 DNS 保持不变
负载均衡：将流量分发到多个后端 Pod
服务发现：通过 DNS 或环境变量让应用自动发现服务

Service 与 Endpoints 的关系：

Service 通过标签选择器（selector） 匹配后端 Pod
被匹配的 Pod IP 和端口会记录在 Endpoints 对象中
Endpoints 是 Service 和 Pod 之间的桥梁------Service 不直接连接 Pod，而是通过 Endpoints 获取所有匹配 Pod 的地址列表

自动更新机制：

✅ 当后端 Pod 发生变动（创建/删除/重启）时，Endpoints 会自动更新
Service 无需任何配置变更即可感知新 Pod
这一机制是 Kubernetes 服务发现的核心基础

验证命令：

bash 复制代码

kubectl get endpoints
kubectl describe svc web

题目二：Service 的三种发现方式

题目：Kubernetes 中 Pod 发现 Service 有哪三种方式？各有什么优缺点？生产环境推荐使用哪种？

考查知识点

Service 发现 ------ 第七期 §2

详细解答

发现方式	说明	优点	缺点
IP 访问	直接使用 Service 的 ClusterIP	简单直接	IP 可能变化，硬编码不推荐
环境变量	Pod 启动时自动注入 Service 信息	自动注入，使用方便	依赖创建顺序（Service 必须在 Pod 之前创建）
DNS 访问	通过 CoreDNS 解析 Service 名称	灵活、动态、无需依赖顺序	需要 CoreDNS 组件

生产环境推荐 ：DNS 访问方式

原因：

不依赖创建顺序
支持跨命名空间访问（<service>.<namespace>.svc.cluster.local）
同命名空间可直接使用 Service 名称
动态更新，Pod 重启后无需修改配置

DNS 记录格式：

text 复制代码

<service-name>.<namespace>.svc.cluster.local

验证命令：

bash 复制代码

kubectl run test --rm -it --image=busybox -- nslookup web

题目三：五种 Service 类型的区别

题目：Kubernetes Service 支持哪五种类型？请分别说明其特点和适用场景。NodePort 的三个端口（nodePort / port / targetPort）分别是什么含义？

考查知识点

Service 类型 ------ 第七期 §3

详细解答

类型	说明	访问范围	适用场景
ClusterIP（默认）	集群内部 IP	仅集群内	内部服务通信
NodePort	节点端口映射	集群内外（节点 IP+端口）	简单外部暴露、测试环境
LoadBalancer	外部负载均衡器 IP	集群内外（LB IP）	生产环境外部暴露
ExternalName	DNS CNAME 映射	集群内（DNS 级别）	外部服务别名
Headless	ClusterIP=None	集群内（直接访问 Pod IP）	StatefulSet 直接访问 Pod

NodePort 三个端口的含义：

端口	含义	示例
nodePort	节点上监听的端口（用户访问入口）	31917
port	ClusterIP 上监听的端口	8080
targetPort	Pod 监听的端口	80

访问方式：

bash 复制代码

# 通过任意节点 IP + nodePort 访问
curl http://10.1.8.30:31917
curl http://10.1.8.31:31917

题目四：会话保持（sessionAffinity）

题目：如何让来自同一客户端的请求始终访问同一个后端 Pod？请写出配置命令并说明原理。

考查知识点

Service 高级特性 ------ 第七期 §4.1
会话保持

详细解答

配置方法：

bash 复制代码

# 启用会话保持（基于客户端 IP）
kubectl patch svc web -p '{"spec":{"sessionAffinity":"ClientIP"}}'

YAML 配置：

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 7200   # 2 小时
  selector:
    app: web
  ports:
  - port: 80

工作原理：

Service 记录客户端 IP 和 Pod 的对应关系
同一客户端的后续请求继续转发给同一个 Pod
默认超时时间为 10800 秒（3 小时）

验证：

bash 复制代码

# 启用前：请求轮询分发
for i in {1..20}; do curl -s 10.111.90.183; done | sort | uniq -c
     10 web-6db76cb4fc-5gbx2
     10 web-6db76cb4fc-b8f7l

# 启用后：所有请求发往同一个 Pod
kubectl patch svc web -p '{"spec":{"sessionAffinity":"ClientIP"}}'
for i in {1..20}; do curl -s 10.111.90.183; done | sort | uniq -c
     20 web-6db76cb4fc-5gbx2

与 IPVS 的关系：

Service 配置 sessionAffinity: ClientIP → kube-proxy 自动使用 IPVS 的 SH（源地址哈希） 算法

题目五：金丝雀发布的流量控制原理

题目：如何利用 Service 的标签选择器实现金丝雀发布？请说明核心原理，并写出关键命令。

考查知识点

Service 高级特性 ------ 第七期 §4.2
金丝雀发布

详细解答

核心原理：

同一个 Service 匹配多个 Deployment（它们有相同的 app 和 tier 标签，但 track 不同）
通过调整不同 Deployment 的副本数来控制流量比例
新版本（金丝雀）与旧版本（稳定版）同时运行，共享同一个 Service

关键步骤：

bash 复制代码

# 1. 准备 ConfigMap（不同版本的页面内容）
echo "hello nginx 1.28" > web/index28.html
echo "hello nginx 1.29" > web/index29.html
kubectl create configmap web --from-file=./web

# 2. 部署稳定版（track: stable）
kubectl apply -f webapp-1.28.yaml

# 3. 部署金丝雀版（track: canary）
kubectl apply -f webapp-1.29.yaml

# 4. 创建 Service（匹配 app: web, tier: frontend）
kubectl apply -f webapp-svc.yaml

# 5. 调整副本数控制流量比例
kubectl scale deployment web-28 --replicas=8   # 稳定版 8 个副本
kubectl scale deployment web-29 --replicas=2   # 金丝雀版 2 个副本

# 6. 验证流量比例
for i in {1..50}; do curl -s 10.98.235.36; done | sort | uniq -c
     39 hello nginx 1.28
     11 hello nginx 1.29

题目六：kube-proxy 的 iptables 模式工作原理

题目：请简述 kube-proxy 在 iptables 模式下的工作原理，并画出流量转发链路。该模式存在什么缺点？

考查知识点

kube-proxy 原理 ------ 第七期 §5.2
iptables 模式

详细解答

iptables 模式工作原理：

kube-proxy 监听 Service 和 Endpoint 变化
在宿主机内核中动态生成 iptables 规则链
流量进入时通过 netfilter 框架逐条匹配规则
实现 DNAT（目标地址转换）和负载均衡

流量转发链路：

text 复制代码

客户端访问 ClusterIP
    ↓
PREROUTING 链 (nat 表)
    ↓
KUBE-SERVICES（服务总入口链）
    ↓ 匹配目的 IP = ClusterIP
KUBE-SVC-XXX（Service 专属调度链）
    ├── SNAT 标记（非 Pod 网段流量）
    ├── 概率 1/3 → KUBE-SEP-A → DNAT → Pod 1
    ├── 概率 1/3 → KUBE-SEP-B → DNAT → Pod 2
    └── 概率 1/3 → KUBE-SEP-C → DNAT → Pod 3

缺点：

每增加一个 Service 或 Endpoint，都会新增/修改 iptables 规则
服务数超过 1000 时，规则链膨胀，CPU 占用飙升
规则查找是 O(n) 线性 复杂度

iptables 模式适合小规模集群（服务数 < 1000）

题目七：kube-proxy 的 IPVS 模式

题目：IPVS 模式相比 iptables 模式有哪些优势？如何将 kube-proxy 从 iptables 模式切换到 IPVS 模式？IPVS 支持哪些调度算法？

考查知识点

kube-proxy 原理 ------ 第七期 §5.3
IPVS 模式

详细解答

IPVS 模式优势：

对比项	iptables	IPVS
规则查找	O(n) 线性	O(1) 哈希
服务数上限	~1000	100000+
规则同步延迟	随规则数增加	恒定
调度算法	仅随机概率	8 种算法

切换步骤：

bash 复制代码

# 1. 修改 kube-proxy ConfigMap
kubectl edit configmap -n kube-system kube-proxy
# 将 mode: "" 改为 mode: "ipvs"

# 2. 重启 kube-proxy
kubectl rollout restart daemonset -n kube-system kube-proxy

# 3. 验证模式
kubectl logs -n kube-system kube-proxy-72b7j | grep "Using ipvs"

IPVS 支持的调度算法：

算法	说明
`rr`	轮询（默认）
`wrr`	加权轮询
`lc`	最少连接
`sh`	源地址哈希
`sed`	最短预期延迟
`nq`	最少队列

验证 IPVS 规则：

bash 复制代码

ipvsadm -Lnt 10.103.143.120:80

题目八：Ingress 与 Service 的关系

题目：Ingress 和 Service 有什么区别？为什么要使用 Ingress 而不是直接用 NodePort 或 LoadBalancer？

考查知识点

Ingress 概述 ------ 第七期 §6.1
Ingress vs Service

详细解答

Ingress vs Service：

对比项	Service（NodePort/LoadBalancer）	Ingress
协议	TCP/UDP	HTTP/HTTPS（7 层）
路由能力	仅端口映射	域名、路径、SSL 等
成本	每个服务一个 LB IP	多个服务共享一个 LB IP

为什么使用 Ingress：

降低成本：多个服务共享一个负载均衡器 IP，而不是每个服务单独一个 LB
7 层路由：支持基于域名和路径的细粒度路由
SSL/TLS 终止：统一管理证书
高级功能：支持限流、重写、跨域等

Ingress 架构：

text 复制代码

客户端 → Ingress Controller (Nginx) → Service → Pod

Ingress 资源：定义路由规则（YAML）
Ingress Controller：负责执行路由规则（如 ingress-nginx）

题目九：Ingress 路径重写（rewrite-target）

题目：前端访问 /webapp01/api/hello，但后端只识别 /api/hello，需要剥离 /webapp01 前缀。请写出对应的 Ingress YAML 配置。

考查知识点

Ingress 规则实践 ------ 第七期 §7.2
路径重写

详细解答

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  ingressClassName: nginx
  rules:
  - host: www.whisky.cloud
    http:
      paths:
      - path: /webapp01/(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: webapp01
            port:
              number: 80

关键注解说明：

注解	值	作用
`use-regex`	`"true"`	启用正则表达式匹配
`rewrite-target`	`/$1`	将正则表达式中第一个括号匹配的内容作为新路径

效果：

请求：/webapp01/api/hello → 重写为 /api/hello 转发给后端

题目十：Ingress 生产级注解实践

题目：在生产环境中，Ingress 常用的安全与防护配置有哪些？请写出以下配置的 YAML 注解：① 强制 HTTPS 跳转 ② 单 IP 限流（20 RPS）③ IP 白名单。

考查知识点

Ingress 规则实践 ------ 第七期 §7.2-7.3
生产级注解

详细解答

完整 YAML 示例：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: production-ingress
  annotations:
    # ① 强制 HTTPS 跳转
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

    # ② 单 IP 限流（20 RPS，50 并发连接）
    nginx.ingress.kubernetes.io/limit-rps: "20"
    nginx.ingress.kubernetes.io/limit-connections: "50"

    # ③ IP 白名单
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.1.8.0/24,127.0.0.1/32"

    # ④ 自定义超时（可选）
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - www.whisky.cloud
    secretName: www-tls
  rules:
  - host: www.whisky.cloud
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp01
            port:
              number: 80

生产常用注解速查表：

注解	作用	示例值
`ssl-redirect`	80 端口强制跳转 HTTPS	`"true"`
`limit-rps`	单 IP 每秒请求数限制	`"20"`
`limit-connections`	单 IP 最大并发连接数	`"50"`
`whitelist-source-range`	IP 白名单	`"10.1.8.0/24,127.0.0.1/32"`
`enable-cors`	启用跨域	`"true"`
`proxy-read-timeout`	读取超时	`"60"`

附：知识点对应总表

题号	主要考查知识点（对应笔记章节）
1	第七期 §1 Service 概述与 Endpoints
2	第七期 §2 Service 发现（IP/环境变量/DNS）
3	第七期 §3 Service 五种类型与 NodePort
4	第七期 §4.1 会话保持（sessionAffinity）
5	第七期 §4.2 金丝雀发布
6	第七期 §5.2 kube-proxy iptables 模式
7	第七期 §5.3 kube-proxy IPVS 模式
8	第七期 §6.1 Ingress vs Service
9	第七期 §7.2 路径重写（rewrite-target）
10	第七期 §7.3 生产高频注解速查表

学习建议：对于答错的题目，请回看第七期对应章节，并动手在集群环境中执行相关命令。Service 和 Ingress 是 Kubernetes 对外提供服务的关键组件，熟练掌握其配置是生产运维的基本要求。
--- Compiled and Authored by Whisky --- July 1 st, 2026