【Linux&Kubernetes】必学知识点合集三

Kubernetes 集群内 Pod 间的网络通信核心遵循 CNI（Container Network Interface）容器网络接口 标准，通过集群网络插件（如 Calico/Flannel）实现 Pod 跨节点 / 同节点的三层网络互通；再结合 K8s 核心的 Service 资源 实现 Pod 服务的发现、负载均衡和稳定访问；同时依托 DNS 服务（CoreDNS） 完成服务名到 ClusterIP 的解析，三者结合形成完整的 Pod 间网络服务体系。其中 ClusterIP 为 Service 的虚拟 IP 地址，仅集群内可访问，是 Pod 间、Pod 与节点间访问的默认类型。

3. 解释 iptables 和 IPVS 代理模式 Service 的区别

两者均基于 Linux netfilter 挂钩函数实现 Service 流量转发，核心差异在于数据结构和性能，也是 kube-proxy 最主流的两种工作模式：

iptables 模式：基于规则链实现转发，规则随 Pod 数量线性增加，同步规则时性能损耗大，高并发下延迟较高，无原生负载均衡策略；
IPVS 模式：基于哈希表作为基础数据结构，全程在内核空间工作，重定向通信延迟更短，规则同步性能更优，支持更高的网络吞吐量；同时提供轮询、加权轮询、IP 哈希、最少连接等多种负载均衡策略，是大规模集群的首选。

4. 举例说明 ClusterIP 类型 Service 的用法

ClusterIP 是 K8s Service 的默认类型，通过集群内部唯一虚拟 IP 暴露服务，仅能在集群内部（Pod / 节点）访问，适用于集群内服务间的相互调用。

核心 YAML 示例

yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
  namespace: default
spec:
  type: ClusterIP  # 可省略，默认即为ClusterIP
  selector:
    app: nginx     # 匹配带有该标签的Pod
  ports:
  - port: 8000        # Service对外暴露的端口
    targetPort: 80    # 后端Pod的容器监听端口
    protocol: TCP     # 协议类型，默认TCP

访问方式

先获取 Service 的 ClusterIP：kubectl get svc nginx-clusterip
集群内访问：curl <ClusterIP>:8000

5. 举例说明 NodePort 类型 Service 的用法

NodePort 类型通过集群所有节点的物理 IP + 静态端口（NodePort） 暴露服务，实现集群外部访问，底层会自动创建对应的 ClusterIP 服务，流量先转发到 ClusterIP 再到后端 Pod。K8s 中 NodePort 的默认端口范围为 30000-32767，可手动指定（需在范围内）或由集群自动分配。

核心 YAML 示例

yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
  namespace: default
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 80          # Service内部端口
    targetPort: 80    # Pod容器端口
    nodePort: 31788   # 手动指定节点端口（可选）
    protocol: TCP

访问方式

集群外部通过任意节点的 IP 访问：curl <任意节点IP>:31788

6. 举例说明 Headless 类型 Service 的用法

Headless（无头服务）是特殊的 Service 类型，不分配 ClusterIP，访问时会通过集群 DNS 直接返回所有匹配的 Pod IP 列表，而非虚拟 IP，适用于需要直接访问单个 Pod 的场景（如分布式数据库、主从架构、节点发现）。

核心 YAML 示例

yaml

apiVersion: v1
kind: Service
metadata:
  name: mysql-headless
  namespace: default
spec:
  clusterIP: None     # 核心配置：设置为无头服务
  selector:
    app: mysql        # 匹配MySQL Pod
  ports:
  - port: 3306
    targetPort: 3306
    protocol: TCP

测试方式

需进入集群内任意 Pod，通过 DNS 解析获取 Pod IP 列表：

bash

运行

# 进入测试Pod
kubectl run test-pod --image=busybox:1.35 --rm -it -- sh
# 执行DNS解析（nslookup需安装：apk add bind-tools）
nslookup mysql-headless.default.svc.cluster.local

解析结果会直接列出所有匹配的 MySQL Pod 实际 IP 地址。

7. 说明 MetalLB 所实现的 LoadBalancer Service 的原理

LoadBalancer 类型 Service 用于通过外部负载均衡器对外暴露服务，K8s 本身不提供原生的负载均衡组件，仅提供标准 API，需通过第三方组件集成，MetalLB 是开源的 K8s 负载均衡器实现，专为裸金属集群设计，由 Controller 和 Speaker 两个核心组件实现，原理如下：

Controller 组件：以 Deployment 形式运行，监听 K8s 中 Service 资源的变化；当检测到 Service 类型为 LoadBalancer 时，从预先配置的 IP 地址池中为该 Service 分配一个外部可访问的 IP，并管理该 IP 的生命周期（创建、更新、释放）；
Speaker 组件：以 DaemonSet 形式运行在集群每个节点上，将 Service 分配的外部 IP，通过标准路由协议（BGP/ARP） 广播到集群所在的物理网络，确保外部流量能正确路由到集群节点，最终转发到后端 Pod。

核心 YAML 示例

yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
  namespace: default
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  # 可选：指定MetalLB分配的IP
  # loadBalancerIP: 192.168.1.200

访问方式

MetalLB 自动为该 Service 分配外部 IP，外部直接通过该 IP 访问：curl <MetalLB分配的外部IP>

8. 详细说明 Ingress 的实现原理和它所实现的功能

核心功能

Ingress 是 K8s 中用于管理集群外部 HTTP/HTTPS 访问的 API 对象，解决了 Service 仅能实现四层（TCP/UDP） 流量转发的局限性，实现七层（HTTP/HTTPS） 流量管理，核心功能包括：

基于域名 / URL 路径的流量路由；
提供 HTTP/HTTPS 负载均衡；
实现 SSL 终结（HTTPS 解密）；
支持基于名称的虚拟托管（多个域名指向同一集群）。

实现原理

Ingress 本身仅为规则配置，不提供实际的转发能力，需配合 Ingress 控制器才能工作；
Ingress 控制器（如 Nginx Ingress Controller、Traefik、HAProxy）是实际运行的 Pod 组件，以 DaemonSet/Deployment 形式部署，负责监听 APIServer 中 Ingress 资源的变化；
用户通过 YAML 定义 Ingress 路由规则（域名 / 路径对应哪个 Service）；
控制器检测到规则变化后，自动生成对应的代理配置（如 Nginx 配置），并加载到自身的代理服务中；
外部流量通过节点 IP / 负载均衡器 IP 进入 Ingress 控制器，控制器根据规则将流量转发到对应的后端 Service，最终到达 Pod。

核心 YAML 示例（Nginx Ingress）

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: default
  annotations:
    # Nginx Ingress专属注解：路径重写
    nginx.ingress.kubernetes.io/rewrite-target: /
    # 开启HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  # 可选：配置TLS证书（HTTPS）
  # tls:
  # - hosts:
  #   - nginx.example.com
  #   secretName: nginx-tls-secret
  rules:
  # 域名路由规则
  - host: nginx.example.com
    http:
      paths:
      - path: /
        pathType: Prefix  # 路径匹配类型：前缀匹配
        backend:
          service:
            name: nginx-clusterip  # 指向后端ClusterIP服务
            port:
              number: 8000         # 服务端口

访问方式

本地配置域名解析（hosts 文件）后，外部直接通过域名访问：curl http://nginx.example.com

9. Kubernetes 对集群 Pod 和容器健康状态如何进行监控和检测的

Kubernetes 通过三类探针（Probe） 实现对 Pod / 容器健康状态的精准监控和检测，所有探针均由节点上的 kubelet 组件本地执行，无需额外外部组件，探针可配置检测方式和阈值，在容器生命周期的不同阶段发挥作用，从启动、运行到就绪全链路监控。三类探针分别为：

startupProbe（启动探针）：检测容器是否完成启动，解决慢启动应用误判问题；
livenessProbe（存活探针）：检测容器是否正常运行，异常则重启容器；
readinessProbe（就绪探针）：检测容器是否准备就绪，未就绪则移出 Service 端点，停止接收流量。支持的检测方式：

httpGet：发送 HTTP/HTTPS 请求，返回 200-399 状态码则判定成功；
tcpSocket：尝试建立 TCP 连接，连接成功则判定成功；
exec：在容器内执行命令，命令退出码为 0 则判定成功。

10. 解释 LivenessProbes 探针的作用及其适用场景

核心作用

LivenessProbes（存活探针）用于检测容器是否处于正常运行状态，当探针检测失败并达到阈值时，kubelet 会根据 Pod 的重启策略（restartPolicy，默认 Always）对容器执行重启操作，保证应用程序的可用性，是容器 “故障自愈” 的核心能力。核心特点：探针失败仅重启容器，不会删除 Pod，Pod 名称和 IP 保持不变。

适用场景

容器进程卡死、死循环、服务崩溃无法自行恢复、应用进程挂掉但容器仍存活的场景，典型示例：

Java 应用 OOM 导致进程退出，容器未自行重启；
应用代码死循环，无法处理新请求；
容器内进程卡死，端口监听失效。

核心 YAML 示例（HTTP GET 方式）

yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-liveness
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /          # 检测路径
        port: 80         # 检测端口
        scheme: HTTP     # 协议（HTTP/HTTPS）
      initialDelaySeconds: 5  # 容器启动后，延迟5秒开始首次检测
      periodSeconds: 10       # 检测间隔：每10秒检测一次
      failureThreshold: 3     # 失败阈值：连续3次失败则判定容器异常
      successThreshold: 1     # 成功阈值：连续1次成功则恢复正常

11. 解释 ReadinessProbe 探针的作用及其适用场景

核心作用

ReadinessProbes（就绪探针）用于检测容器是否准备就绪，可正常接收并处理用户请求流量；只有当一个 Pod 内的所有容器的就绪探针都检测成功时，该 Pod 才会被标记为 “就绪” 状态，并加入到对应 Service 的 Endpoints 列表中接收流量；若探针检测失败，Pod 会被立即从 Endpoints 中移除，停止接收新流量，直至探针恢复成功，不会重启容器。

适用场景

容器启动后需要初始化、依赖服务未就绪或临时无法处理请求的场景，典型示例：

应用启动后加载大量配置文件 / 缓存数据，启动完成但未就绪；
应用依赖的数据库 / Redis/MQ 未启动，无法建立连接；
数据库启动后初始化表结构 / 导入数据，暂时无法提供查询；
应用高峰期负载过高，暂时无法处理新请求。

核心 YAML 示例（exec 命令方式）

yaml

apiVersion: v1
kind: Pod
metadata:
  name: mysql-readiness
  namespace: default
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: 123456
    ports:
    - containerPort: 3306
    readinessProbe:
      # 执行命令检测：mysql服务是否就绪
      exec:
        command: ["mysqladmin", "ping", "-h", "127.0.0.1", "-u", "root", "-p123456"]
      initialDelaySeconds: 10  # 延迟10秒开始检测（MySQL启动较慢）
      periodSeconds: 5         # 每5秒检测一次
      failureThreshold: 2      # 连续2次失败则移出Endpoints

12. 解释 StartupProbe 探针的作用及其适用场景

核心作用

StartupProbes（启动探针）用于检测应用程序容器是否完成启动，是 K8s 1.16 版本引入的新特性，专门解决慢启动应用被其他探针误判的问题；核心特点：启动探针检测成功前，存活探针和就绪探针均不会执行；启动探针检测成功后，由存活 / 就绪探针接管后续的监控；若启动探针超时失败，kubelet 会杀死容器并根据重启策略重启。

适用场景

启动耗时较长的应用，这类应用启动时间超过存活 / 就绪探针的默认阈值，易被误判为异常而重启或拒绝流量，典型示例：

大型 Java 应用（Spring Boot），启动时加载大量依赖和配置，耗时 10 + 秒；
大数据组件（Hadoop/Spark/Flink），启动流程复杂，耗时数十秒；
AI 应用，启动时加载预训练模型，耗时数分钟；
传统应用，启动时执行大量初始化脚本。

核心 YAML 示例（TCP Socket 方式）

yaml

apiVersion: v1
kind: Pod
metadata:
  name: java-app-startup
  namespace: default
spec:
  containers:
  - name: java-app
    image: my-java-app:v1
    ports:
    - containerPort: 8080
    # 启动探针：给300秒启动时间（30次*10秒）
    startupProbe:
      tcpSocket:
        port: 8080
      failureThreshold: 30  # 失败阈值：最多重试30次
      periodSeconds: 10     # 每10秒检测一次
    # 启动成功后，存活探针接管
    livenessProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      periodSeconds: 10
    # 启动成功后，就绪探针接管
    readinessProbe:
      httpGet:
        path: /actuator/health
        port: 8080
      periodSeconds: 5

13. 说明 K8s 中 Pod 级别的 Graceful Shutdown（优雅关闭）

Graceful Shutdown（优雅关闭）是 K8s 中 Pod 被删除 / 驱逐时的有序关闭流程，核心目的是避免请求丢失、保证数据一致性，让容器有足够的时间处理完现有请求、释放资源、持久化数据，而非被强制杀死，是生产环境中保障服务高可用的重要特性。K8s 默认识别并处理容器的优雅退出，也可通过配置自定义退出时长。

核心执行流程

移除流量：当 Pod 收到删除 / 驱逐指令（kubectl delete pod/ 节点驱逐）时，kubelet 首先将该 Pod 从对应 Service 的 Endpoints 列表中移出，APIServer 会更新 Endpoints 资源，后续流量不再分配给该 Pod；
发送退出信号：kubelet 向 Pod 内的所有容器发送 SIGTERM 信号，通知容器开始优雅退出，默认等待 30 秒（可自定义）；
容器优雅退出：容器内的应用程序捕获 SIGTERM 信号后，执行收尾操作：处理完当前正在处理的请求、关闭数据库 / 缓存连接、释放文件句柄、将内存中的临时数据持久化到磁盘；
强制杀死容器：若等待时间结束，容器仍未自行退出（未返回退出码），kubelet 会发送 SIGKILL 信号强制杀死未退出的容器；
删除 Pod：所有容器退出后，kubelet 向 APIServer 上报 Pod 状态，最终完成 Pod 的删除。

核心 YAML 配置示例（自定义优雅关闭时长）

yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-graceful
  namespace: default
spec:
  # 自定义优雅关闭等待时间：60秒（默认30秒）
  terminationGracePeriodSeconds: 60
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80
    # 可选：配置容器的预停止钩子（优雅退出前执行自定义命令）
    lifecycle:
      preStop:
        exec:
          # 延迟10秒退出，确保流量完全移出（配合Endpoints更新延迟）
          command: ["sh", "-c", "sleep 10"]

关键配置说明

terminationGracePeriodSeconds：Pod 优雅关闭的总等待时间，包含 preStop 钩子执行时间，建议根据业务场景调整（如数据处理服务设置 60-120 秒）；
preStop：容器预停止钩子，在发送 SIGTERM 信号前执行自定义命令，可用于延迟退出、执行清理脚本，解决 Endpoints 同步的毫秒级延迟问题。