Pod、Service、Ingress 与网络 - 面试题

#

★★★

1. Gateway API（Gateway/HTTPRoute）相对 Ingress 的演进中角色分离（GatewayClass/Gateway/HTTPRoute）、跨命名空间路由与 gRPC 支持

问题

Gateway API 相对 Ingress 有哪些演进？GatewayClass/Gateway/HTTPRoute 如何实现角色分离，如何支持跨命名空间路由与 gRPC？

考察点

角色分离（GatewayClass/Gateway/HTTPRoute）
跨命名空间路由与引用权限
gRPC 与其他协议支持

答案

Gateway API 是 Ingress 的演进，核心是角色分离：GatewayClass 描述可实现网关的类（如 nginx、istio），由平台管理员定义；Gateway 描述具体网关实例（监听端口、协议、承载的 listener），由基础设施团队管理；HTTPRoute 描述具体的路由规则（匹配+转发），由应用开发者管理。三者分离让不同角色各管其责。相比 Ingress：支持跨命名空间引用（HTTPRoute 可引用其他命名空间的 Backend/Service，需 referenceGrant 授权），支持多协议（HTTP、gRPC、TCP、TLS），更丰富的匹配与后端（weight、filter、retry）。gRPC 通过 GRPCRoute 或 HTTPRoute 的 protocol 支持。

解析

核心是"标准化、角色分离、可移植、多协议"。Ingress 缺乏标准规则与跨 ns 支持，Gateway API 正在成为新一代标准。

示例代码

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata: { name: my-gw }
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: app-route }
spec:
  parentRefs: [{ name: my-gw, namespace: infra }]
  rules:
    - matches: [{ path: { type: PathPrefix, value: /api } }]
      backendRefs: [{ name: app-svc, port: 8080 }]

#

★★★

2. Pod 使用 hostNetwork 时的网络行为、适用场景与安全风险？

问题

Pod 使用 hostNetwork 时的网络行为、适用场景与安全风险是什么？

考察点

hostNetwork 的含义（使用宿主网络命名空间）
适用场景（nodePort 类、系统组件）
安全风险（端口冲突、绕过 NetworkPolicy）

答案

hostNetwork: true 让 Pod 直接使用宿主机的网络命名空间，Pod 不再有独立 IP，直接用节点 IP 和宿主机端口。适用场景：系统组件（如 kube-proxy、flannel、metrics-server）、需要监听宿主机端口或做集群网络功能的 Pod、以及需要绕过 Container 网络栈的高性能场景。安全风险：Pod 与宿主机共享网络栈，端口冲突、无隔离；CNI 的 NetworkPolicy 默认不作用于 hostNetwork Pod（hostNetwork Pod 不经过 CNI 数据面），可能绕过网络策略；可用宿主机端口，提升攻击面。

解析

核心是"共享宿主网络命名空间"。因此 hostNetwork Pod 无独立 IP、端口与宿主机共享，NetworkPolicy 不生效。

示例代码

apiVersion: v1
kind: Pod
metadata:
  name: system-pod
spec:
  hostNetwork: true
  containers:
    - name: c
      image: myapp
      ports: [{ containerPort: 8080, hostPort: 8080 }]

#

★★★

3. Pod 如何通过 seccompProfile type=Localhost 加载节点自定义 seccomp 配置？

问题

Pod 如何通过 seccompProfile type=Localhost 加载节点自定义 seccomp 配置？

考察点

seccomp 的意义
type=Localhost 与 localhostProfile
配置存放路径

答案

seccomp 限制容器可调用的系统调用，增强隔离。Pod 的 securityContext.seccompProfile 可设 type=Localhost，此时需在节点上预置 seccomp 配置文件（JSON），并通过 localhostProfile 指定文件名（相对路径）。Kubelet 从节点默认目录（--seccomp-default-profile-root，默认 /var/lib/kubelet/seccomp）读取该文件，并挂载给容器运行时。相比 type=RuntimeDefault（使用运行时默认配置，如 containerd 的默认 seccomp），Localhost 用自定义策略，可精确允许/禁止 syscall，但需在节点上维护配置文件。

解析

核心是"节点预置配置文件 + localhostProfile 引用"。配置文件需在所有运行该 Pod 的节点上存在。

示例代码

apiVersion: v1
kind: Pod
metadata:
  name: secure
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/audit.json
  containers:
    - name: c
      image: nginx

#

★★★

4. readOnlyRootFilesystem 如何强制容器只读根文件系统并配合 emptyDir 写临时数据？

问题

readOnlyRootFilesystem 如何强制容器只读根文件系统，并配合 emptyDir 写临时数据？

考察点

readOnlyRootFilesystem 的含义
需要写临时文件的处理
emptyDir 的使用

答案

readOnlyRootFilesystem: true 使容器的根文件系统只读挂载，防止容器内写入（增强安全、减少镜像被篡改）。但很多应用需要写临时数据（/tmp、日志、运行状态），此时需挂载 emptyDir 卷到可写路径，emptyDir 是 Pod 生命周期内的临时卷，随 Pod 删除而清空。容器对只读根文件系统写操作会失败（只读文件系统错误），因此应用需将可写路径指向已挂载的空卷。

解析

核心是"根只读 + 显式可写挂载点"。安全实践常配合非 root、securityContext 使用。

示例代码

apiVersion: v1
kind: Pod
metadata: { name: app }
spec:
  containers:
    - name: c
      image: app
      securityContext:
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

#

★★★

5. securityContext 的 fsGroup 与 fsGroupChangePolicy 如何控制卷所有权变更？

问题

securityContext 的 fsGroup 与 fsGroupChangePolicy 如何控制卷所有权变更？

考察点

fsGroup 的含义（所有卷的组所有权）
fsGroupChangePolicy 控制变更时机
与卷挂载的配合

答案

Pod 的 securityContext.fsGroup 指定一个补充组 GID，Kubelet 会把挂载的卷的所有权（group）改为该 GID，使容器内进程能访问卷。fsGroupChangePolicy 控制所有权变更的时机，有两个值：Always（每次挂载都递归 chown，保证组一致但可能慢）与 OnRootMismatch（仅当根目录所有权与 fsGroup 不一致时才变更，避免大目录递归 chown 的性能开销）。默认行为取决于版本（多为 OnRootMismatch）。适用于需要多容器共享卷、或卷默认属主不是运行用户的情况。

解析

核心是"设定卷的组所有权 + 控制变更时机"。OnRootMismatch 可避免大卷递归 chown 卡住。

示例代码

apiVersion: v1
kind: Pod
metadata: { name: app }
spec:
  securityContext:
    fsGroup: 2000
    fsGroupChangePolicy: OnRootMismatch

#

★★★

6. securityContext 的 runAsUser/runAsGroup/runAsNonRoot 如何控制进程身份？

问题

securityContext 的 runAsUser/runAsGroup/runAsNonRoot 如何控制进程身份？

考察点

runAsUser/runAsGroup 指定 UID/GID
runAsNonRoot 强制非 root
与卷权限的配合

答案

runAsUser 指定容器进程运行的用户 UID，runAsGroup 指定 GID（默认继承镜像用户主组）。runAsNonRoot: true 强制容器以非 root 运行，若镜像以 root 运行会拒绝启动（Admission 检查）。三者配合可让容器以最小权限运行。注意：runAsUser 的 UID 必须能访问所挂载卷（配合 fsGroup 或卷属主），否则出现权限不足。Pod 级与 container 级 securityContext 的优先级：container 级覆盖 Pod 级。

解析

核心是"进程身份控制 + 非 root 强制"。这是安全基线（baseline/restricted）的核心要求。

示例代码

apiVersion: v1
kind: Pod
metadata: { name: app }
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000

#

★★

7. ExternalName 类型 Service 如何通过 DNS CNAME 指向外部域名？

问题

ExternalName 类型 Service 如何通过 DNS CNAME 指向外部域名？

考察点

ExternalName 的含义
CNAME 记录转发
用途与限制

答案

ExternalName Service 没有 selector 和 ClusterIP，它的 externalName 字段指定一个外部域名。Kubernetes 的 DNS（CoreDNS）会为该 Service 生成一个 CNAME 记录，指向 externalName 指定的域名。应用通过 Service 的 DNS 名称访问时，由 DNS 解析转发到外部域名。适用于把集群内服务名映射到外部服务（如外部数据库、SaaS）。限制：不能与 selector 同时使用，不能直接面向 TCP/UDP 端口做负载（只是 DNS 转发），且依赖 DNS 解析。

解析

核心是"通过 DNS CNAME 转发到外部域名"。用于优雅地通过 Service 名访问外部主机。

示例代码

apiVersion: v1
kind: Service
metadata:
  name: ext-svc
spec:
  type: ExternalName
  externalName: db.example.com

#

★★

8. Ingress TLS 终止与证书管理中 tls 字段配置、cert-manager 集成、TLS 版本与加密套件限制

问题

Ingress TLS 终止与证书管理：tls 字段配置、cert-manager 集成、TLS 版本与加密套件限制如何处理？

考察点

Ingress 的 tls 字段与 secret
cert-manager 自动签发
TLS 版本与加密套件

答案

Ingress 通过 spec.tls 配置 TLS：hosts 与 secretName（保存证书的 Secret，字段 tls.crt/tls.key）。控制器在网关终止 TLS 并转发明文到后端。cert-manager 可自动签发证书：通过 Certificate/Issuer 资源，配合 ACME（HTTP-01/DNS-01）自动获取 Let's Encrypt 证书，并自动更新 Secret。若要限制 TLS 版本与加密套件，需通过 Ingress 控制器的注解/配置（如 Nginx Ingress 的 ssl-protocols、ssl-ciphers），或 Gateway API 的 TLS options。

解析

核心是"网关终止 TLS + Secret 存储证书 + cert-manager 自动续期"。TLS 版本/套件在控制器层配置。

示例代码

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    nginx.ingress.kubernetes.io/ssl-protocols: "TLSv1.2 TLSv1.3"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
    - hosts: [app.example.com]
      secretName: app-tls
  rules:
    - host: app.example.com
      http:
        paths: [{ path: /, pathType: Prefix, backend: { service: { name: app-svc, port: { number: 80 } } } }]

#

★★

9. Ingress 与 LoadBalancer 的关系中 Ingress controller 如何与云厂商 NLB/ALB 协同以及 targetPort 与 NodePort 的流量路径

问题

Ingress 与 LoadBalancer 的关系：Ingress controller 如何与云厂商 NLB/ALB 协同，targetPort 与 NodePort 的流量路径是怎样的？

考察点

Ingress 与 LoadBalancer 的分层
云 LB 与 Ingress controller
targetPort/NodePort 流量路径

答案

LoadBalancer 类型的 Service 由云厂商提供外部负载均衡（NLB/ALB），将流量导入集群；Ingress 是在集群内提供更高层（HTTP/L7）路由的入口。Ingress controller 通常以 LoadBalancer Service 暴露（获取外部 IP），Ingress 控制器监听 Ingress 资源并配置转发。流量路径：客户端 → 云 LB → LoadBalancer Service（NodePort）→ 节点 kube-proxy → Ingress controller Pod → 按 Ingress 规则转发到后端 Service 的 targetPort → Pod。云厂商的 ALB Ingress Controller 也支持直接由 ALB 转发到 NodePort。

解析

核心是"云 LB 负责入流量 + Ingress 负责 L7 路由"。Ingress controller 常以 LoadBalancer/NodePort 暴露。

#

★★

10. Service 的 ClusterIP 如何分配并实现集群内虚拟 IP 负载均衡？

问题

Service 的 ClusterIP 如何分配并实现集群内虚拟 IP 负载均衡？

考察点

ClusterIP 分配方式
虚拟 IP 与 kube-proxy
负载均衡机制

答案

ClusterIP 是 Service 的集群内虚拟 IP，由 kube-apiserver 在创建 Service 时从 --service-cluster-ip-range 分配的 CIDR 中分配（或指定具体 IP）。它不绑定任何真实设备，而是由各节点的 kube-proxy 维护转发规则（iptables/IPVS/IPVS 规则），把发往 ClusterIP 的流量负载均衡到 Endpoints（后端 Pod IP）。ipvs 模式基于内核 LVS 做负载均衡，性能好；iptables 模式用规则链 NAT。DNS 解析 Service 名到 ClusterIP。

解析

核心是"虚拟 IP + kube-proxy 数据面转发"。ClusterIP 只在集群内可达。

示例代码

apiVersion: v1
kind: Service
metadata: { name: app }
spec:
  selector: { app: myapp }
  ports:
    - port: 80
      targetPort: 8080

#

★★

11. Service 的 NodePort 如何暴露服务（端口范围与流量转发路径）？

问题

Service 的 NodePort 如何暴露服务？端口范围与流量转发路径是什么？

考察点

NodePort 端口范围
每个节点的端口监听
流量路径

答案

NodePort 类型 Service 在 ClusterIP 基础上，还在每个节点上开放一个静态端口（默认范围 30000-32767，可通过 --service-node-port-range 配置）。节点上的 kube-proxy 监听该端口，将流量转发到 ClusterIP→Endpoints→Pod。外部客户端可通过 任意节点IP:NodePort 访问。流量路径：客户端 → 节点IP:NodePort → kube-proxy（iptables/IPVS）→ ClusterIP → Endpoints → Pod。NodePort 通常作为 LoadBalancer 或 Ingress 的底层实现。

解析

核心是"每节点开放端口 + 转发到后端"。NodePort 不提供 LB 高可用，依赖各节点。

示例代码

apiVersion: v1
kind: Service
metadata: { name: app }
spec:
  type: NodePort
  selector: { app: myapp }
  ports:
    - port: 80
      nodePort: 30080
      targetPort: 8080

#

★★

12. Service 的负载均衡中 iptables 与 IPVS 模式如何选型？

问题

Service 的负载均衡在 iptables 与 IPVS 模式下有什么区别？

考察点

iptables 模式原理
IPVS 模式原理
两者差异与选型

答案

kube-proxy 支持两种核心模式。iptables 模式：为每个 Service 生成 iptables 规则链，通过 NAT 与随机选择（statistic 模块）把流量 DNAT 到后端 Endpoints，规则随 Endpoints 变化而更新；缺点是规则多、更新慢、性能在大量 Service 时下降。IPVS 模式：用内核 LVS 的 IPVS 虚拟服务器，支持多种负载均衡算法（rr、wrr、lc 等），扩展性好、性能高、规则更新效率高，适合大规模集群。选型：小集群用 iptables 简单，大规模/高并发用 IPVS。

解析

核心是"iptables 用 NAT 链 vs IPVS 用内核 LVS"。IPVS 性能和可扩展性更优。

#

★

13. Ingress 的选型中 Nginx、Traefik 与 Gateway API 如何取舍？

问题

Ingress 的选型：Nginx、Traefik、Gateway API 如何选择？

考察点

各控制器的特点
适用场景
选型考虑

答案

Nginx Ingress（ingress-nginx）：使用 Nginx 引擎，功能全面、生态成熟、性能好，是默认选择，支持丰富注解（重写、限流、认证、canary）。Traefik：动态配置、自动发现（无需重载）、内置 Dashboard、与云原生集成好，适合中规模与快速迭代，默认支持 HTTP/2、gRPC。Gateway API：新一代标准，角色分离、多协议、可移植，是未来方向，但需控制器实现（Nginx Gateway Fabric、Traefik 等）。选型考虑：团队熟悉度、功能需求（注解 vs 标准）、性能、多协议支持、可移植性。

解析

核心是"按场景权衡"。大规模生产常选 Nginx；新一代项目可考虑 Gateway API；Traefik 追求简洁。

#

★

14. Ingress-NGINX controller 部署与注解中自定义错误页面、速率限制、重写规则、白名单与 canary 流量分割

问题

Ingress-NGINX controller 常用的注解：自定义错误页面、速率限制、重写规则、白名单、canary 流量分割如何配置？

考察点

常用注解
速率限制与重写
canary 与白名单

答案

ingress-nginx 通过注解扩展功能。自定义错误页面：nginx.ingress.kubernetes.io/custom-errors / default-backend 配置；速率限制：nginx.ingress.kubernetes.io/limit-rps、limit-connections、limit-burst；重写规则：nginx.ingress.kubernetes.io/rewrite-target（路径重写）；白名单：nginx.ingress.kubernetes.io/whitelist-source-range（IP 白名单）；canary：nginx.ingress.kubernetes.io/canary: "true" + canary-weight（按权重分割流量）或 canary-header（按 header 灰度）。

解析

核心是"注解驱动 Nginx 配置"。canary 用于灰度发布，weight 按百分比分流。

示例代码

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/limit-rps: "10"
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"

#

★

15. Pod 网络模型中 CNI 与 overlay 的关系？

问题

Pod 网络模型：CNI 与 overlay 是什么？

考察点

CNI 插件职责
overlay 网络原理
常见插件（Calico/Flannel/Cilium）

答案

CNI（Container Network Interface）是容器网络的标准接口，kubelet 在创建 Pod 时调用 CNI 插件为 Pod 配置网络（创建 veth、分配 IP、配置路由）。overlay 网络是在物理网络之上用隧道（VXLAN、Geneve、IP-in-IP）封装包，使跨节点 Pod 能互通，无需底层网络适配。常见插件：Flannel（VXLAN overlay，简单）、Calico（BGP 直连或 IPIP，支持 NetworkPolicy）、Cilium（基于 eBPF，高性能，支持 NetworkPolicy/服务网格）。Pod 网络模型要求每个 Pod 有独立 IP，且 Pod 间直接互通。

解析

核心是"CNI 负责配置 Pod 网络，overlay 提供跨节点封装"。Calico 用 BGP 较少封装，Cilium 用 eBPF。

#

★

16. Service 的 DNS 中 headless 与 ExternalName 的使用场景？

问题

Service 的 DNS：headless 与 ExternalName 分别如何工作？

考察点

headless（clusterIP: None）
ExternalName（CNAME）
DNS 记录差异

答案

headless Service 设置 clusterIP: None，不分配 ClusterIP，DNS 直接返回所有后端 Pod 的 IP（A 记录列表），应用可自行负载均衡，适合 StatefulSet 的稳定网络标识（如 pod-0.svc.namespace.svc.cluster.local）。ExternalName Service 通过 CNAME 记录指向外部域名。普通 Service 的 DNS 返回 ClusterIP。headless 通常配 selector，返回 Pod IP；ExternalName 无 selector，返回 CNAME。

解析

核心是"headless 返回 Pod IP 列表，ExternalName 返回 CNAME"。两者都无 ClusterIP 负载均衡。

示例代码

apiVersion: v1
kind: Service
metadata: { name: headless }
spec:
  clusterIP: None
  selector: { app: myapp }

#

★

17. 网络策略中 NetworkPolicy 的实现与排障？

问题

NetworkPolicy 的实现与排障如何做？

考察点

NetworkPolicy 的 selector 与规则
实现依赖 CNI 插件
排障方法

答案

NetworkPolicy 通过选择器（podSelector、namespaceSelector）+ 规则（ingress/egress、from/to、ports）控制 Pod 间流量。它需要 CNI 插件支持（Calico、Cilium 支持；Flannel 默认不支持）。默认 deny-all，若没有任何 NetworkPolicy 则允许所有流量。排障：1）确认 CNI 支持 NetworkPolicy；2）检查 policy 的 selector 是否匹配 Pod；3）确认没有默认 deny 策略误伤；4）用 kubectl exec 测试连通性、查看 CNI 日志；5）检查规则的 ports 与方向（ingress/egress）。

解析

核心是"依赖 CNI 实现 + selector 匹配"。排障重点在确认策略是否匹配目标 Pod 与规则方向。

示例代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-api }
spec:
  podSelector: { matchLabels: { app: api } }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: { matchLabels: { app: web } }
      ports:
        - protocol: TCP
          port: 8080