面试题手册

Kubernetes Ingress 是一种 API 对象，用于管理外部访问集群内服务的规则，通常是 HTTP 和 HTTPS 路由。Ingress 提供了基于域名和路径的路由、TLS 终止等功能。Ingress 的作用路由规则：根据域名和路径将流量路由到不同的 Service负载均衡：在多个 Service 实例之间分发流量SSL/TLS 终止：在 Ingress 层面处理 HTTPS，简化后端配置基于名称的虚拟主机：支持多个域名指向同一个集群路径重写：支持 URL 路径重写Ingress ControllerIngress Controller 是实现 Ingress 功能的组件，它监听 Ingress 资源的变化并配置负载均衡器。常见的 Ingress ControllerNGINX Ingress Controller：最流行的 Ingress Controller基于 NGINX/OpenResty功能丰富，性能优秀支持高级路由、限流、认证等Traefik：云原生设计自动服务发现支持 Let's Encrypt 自动证书配置简单HAProxy Ingress：基于 HAProxy高性能支持高级负载均衡算法Istio Gateway：服务网格的一部分支持高级流量管理集成 mTLS、流量镜像等AWS ALB Ingress Controller：专门为 AWS 设计使用 AWS Application Load Balancer原生集成 AWS 服务Ingress 资源示例基本路由apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: simple-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /spec: rules: - host: example.com http: paths: - path: /app1 pathType: Prefix backend: service: name: app1-service port: number: 80 - path: /app2 pathType: Prefix backend: service: name: app2-service port: number: 80TLS 配置apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: tls-ingressspec: tls: - hosts: - secure.example.com secretName: tls-secret rules: - host: secure.example.com http: paths: - path: / pathType: Prefix backend: service: name: secure-service port: number: 443默认后端apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: default-backend-ingressspec: defaultBackend: service: name: default-service port: number: 80 rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80Ingress 注解（Annotations）注解用于配置 Ingress Controller 的特定行为。NGINX Ingress Controller 常用注解重写路径：nginx.ingress.kubernetes.io/rewrite-target: /$2启用 SSL 重定向：nginx.ingress.kubernetes.io/ssl-redirect: "true"限流配置：nginx.ingress.kubernetes.io/limit-rps: "10"nginx.ingress.kubernetes.io/limit-connections: "5"CORS 配置：nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-origin: "*"认证配置：nginx.ingress.kubernetes.io/auth-type: basicnginx.ingress.kubernetes.io/auth-secret: basic-auth自定义错误页面：nginx.ingress.kubernetes.io/custom-http-errors: "404,503"Ingress vs Service| 特性 | Ingress | Service ||------|---------|---------|| 协议 | HTTP/HTTPS | TCP/UDP || 路由 | 基于域名和路径 | 基于端口 || 负载均衡 | L7（应用层） | L4（传输层） || SSL 终止 | 支持 | 不支持 || 使用场景 | Web 应用 | 通用服务 |Ingress vs LoadBalancer| 特性 | Ingress | LoadBalancer ||------|---------|--------------|| 成本 | 低（共享 IP） | 高（每个 Service 一个 IP） || 路由能力 | 强（域名、路径） | 弱（仅端口） || SSL 终止 | 支持 | 部分支持 || 适用场景 | 多个 HTTP/HTTPS 服务 | 少量服务或非 HTTP 服务 |部署 Ingress Controller部署 NGINX Ingress Controller# 添加 Helm 仓库helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm repo update# 安装helm install ingress-nginx ingress-nginx/ingress-nginx \ --namespace ingress-nginx \ --create-namespace验证安装kubectl get pods -n ingress-nginxkubectl get svc -n ingress-nginx最佳实践使用命名空间隔离：将 Ingress Controller 部署在独立的命名空间配置资源限制：为 Ingress Controller 设置合理的 CPU 和内存限制启用监控：监控 Ingress Controller 的性能指标使用 TLS：为生产环境配置 TLS 证书配置健康检查：确保后端 Service 的健康检查正常使用注解优化：根据应用需求配置合适的注解备份配置：定期备份 Ingress 配置版本管理：跟踪 Ingress Controller 的版本更新故障排查查看 Ingress 状态：kubectl get ingresskubectl describe ingress <ingress-name>查看 Ingress Controller 日志：kubectl logs -n ingress-nginx <pod-name>测试 DNS 解析：nslookup example.com检查 Service 和 Endpoint：kubectl get svckubectl get endpoints验证证书：kubectl get secret tls-secret -o yaml

Kubernetes Deployment 是用于管理 Pod 和 ReplicaSet 的声明式更新控制器，它提供了声明式的应用部署和更新能力。Deployment 的核心功能声明式管理：通过 YAML 文件定义期望状态，Kubernetes 自动实现当前状态到期望状态的转换。滚动更新：支持零停机时间的应用更新，逐步替换旧版本的 Pod。回滚能力：可以轻松回滚到之前的版本，支持查看更新历史。自动扩缩容：支持手动或自动调整 Pod 的副本数量。自愈能力：当 Pod 故障或被删除时，自动创建新的 Pod 以维持期望的副本数。Deployment 的工作原理Deployment 通过 ReplicaSet 管理 Pod：ReplicaSet：确保指定数量的 Pod 副本始终运行。Pod 模板：定义 Pod 的规格，包括容器镜像、资源限制等。更新策略：控制滚动更新的行为，如最大不可用 Pod 数量、最大激增 Pod 数量。Deployment 的 YAML 示例apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80更新策略Deployment 支持两种更新策略：RollingUpdate（默认）：逐步替换 Pod，确保始终有可用 Pod可配置 maxUnavailable 和 maxSurge适用于大多数应用Recreate：先删除所有旧 Pod，再创建新 Pod会导致短暂的服务中断适用于无法同时运行新旧版本的应用滚动更新参数maxUnavailable：更新过程中最多允许多少个 Pod 不可用（默认 25%）maxSurge：更新过程中最多允许多少个额外的 Pod（默认 25%）回滚操作查看更新历史：kubectl rollout history deployment/nginx-deployment回滚到上一个版本：kubectl rollout undo deployment/nginx-deployment回滚到指定版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2扩缩容手动扩缩容：kubectl scale deployment/nginx-deployment --replicas=5自动扩缩容（HPA）：apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata: name: nginx-hpaspec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50Deployment 与其他控制器的区别vs ReplicaSet：Deployment 是 ReplicaSet 的上层控制器Deployment 提供更新和回滚能力，ReplicaSet 只能维持副本数vs StatefulSet：Deployment 适用于无状态应用StatefulSet 适用于有状态应用，提供稳定的网络标识和持久化存储vs DaemonSet：Deployment 可以在任意节点运行指定数量的 PodDaemonSet 确保在每个节点上运行一个 Pod 副本最佳实践使用声明式配置：始终使用 YAML 文件定义 Deployment，而不是命令式命令。设置合理的资源限制：为容器设置 CPU 和内存的 requests 和 limits。配置健康检查：使用 livenessProbe 和 readinessProbe 确保应用健康。使用多阶段构建：优化镜像大小，提高部署速度。设置适当的更新策略：根据应用特性选择 RollingUpdate 或 Recreate。使用标签和注解：为 Deployment 添加有意义的标签和注解，便于管理和追踪。监控更新过程：使用 kubectl rollout status 监控更新进度。

Kubernetes ConfigMap 和 Secret 是用于管理配置数据的两种重要资源，它们允许将配置与容器镜像分离，提高应用的可移植性和安全性。ConfigMapConfigMap 用于存储非敏感的配置数据，如应用配置文件、命令行参数、环境变量等。ConfigMap 的创建方式从字面值创建：kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2从文件创建：kubectl create configmap my-config --from-file=config.properties从目录创建：kubectl create configmap my-config --from-file=./config-dir/从 YAML 文件创建：apiVersion: v1kind: ConfigMapmetadata: name: my-configdata: key1: value1 key2: value2 app.properties: | server.port=8080 database.url=jdbc:mysql://localhost:3306/mydbConfigMap 的使用方式作为环境变量：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx env: - name: KEY1 valueFrom: configMapKeyRef: name: my-config key: key1作为命令行参数：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx command: ["/bin/sh", "-c"] args: ["echo $(KEY1)"] env: - name: KEY1 valueFrom: configMapKeyRef: name: my-config key: key1挂载为文件：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: my-configSecretSecret 用于存储敏感信息，如密码、OAuth 令牌、SSH 密钥、证书等。Secret 的类型Opaque：默认类型，用于存储任意用户数据kubernetes.io/service-account-token：用于存储 Service Account 令牌kubernetes.io/dockercfg：用于存储 Docker registry 凭据kubernetes.io/dockerconfigjson：用于存储 Docker registry JSON 配置kubernetes.io/basic-auth：用于存储基本认证凭据kubernetes.io/ssh-auth：用于存储 SSH 认证凭据kubernetes.io/tls：用于存储 TLS 证书Secret 的创建方式从字面值创建：kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123从文件创建：kubectl create secret generic my-secret --from-file=./username.txt --from-file=./password.txt从 YAML 文件创建：apiVersion: v1kind: Secretmetadata: name: my-secrettype: Opaquedata: username: YWRtaW4= password: c2VjcmV0MTIz注意：Secret 的 data 字段中的值必须是 Base64 编码的。使用 stringData：apiVersion: v1kind: Secretmetadata: name: my-secrettype: OpaquestringData: username: admin password: secret123stringData 会自动进行 Base64 编码。Secret 的使用方式Secret 的使用方式与 ConfigMap 类似：作为环境变量：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx env: - name: USERNAME valueFrom: secretKeyRef: name: my-secret key: username挂载为文件：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx volumeMounts: - name: secret-volume mountPath: /etc/secrets volumes: - name: secret-volume secret: secretName: my-secret拉取镜像：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: my-private-registry/my-image imagePullSecrets: - name: registry-secretConfigMap 与 Secret 的区别| 特性 | ConfigMap | Secret ||------|-----------|--------|| 数据类型 | 非敏感数据 | 敏感数据 || 存储方式 | 明文存储 | Base64 编码（非加密） || 访问控制 | 普通 RBAC | 更严格的 RBAC || 大小限制 | 1 MiB | 1 MiB || 挂载方式 | 文件、环境变量 | 文件、环境变量 |安全最佳实践使用 Secret 存储敏感数据：永远不要将密码、密钥等敏感信息存储在 ConfigMap 中。启用 Secret 加密：使用 KMS（Key Management Service）对 etcd 中的 Secret 进行加密。限制 Secret 访问：使用 RBAC 限制对 Secret 的访问权限。使用临时文件：将 Secret 挂载为临时文件（tmpfs），避免持久化到磁盘。定期轮换密钥：定期更新 Secret 中的敏感信息。使用外部密钥管理：对于高安全性要求，考虑使用外部密钥管理系统（如 HashiCorp Vault）。审计 Secret 访问：启用审计日志，记录对 Secret 的访问。注意事项Base64 不是加密：Secret 中的数据只是 Base64 编码，不是加密，需要额外的安全措施。大小限制：ConfigMap 和 Secret 都有 1 MiB 的大小限制，超出限制需要拆分。版本管理：ConfigMap 和 Secret 的更新不会自动触发 Pod 重启，需要使用 Deployment 的滚动更新或手动重启。不可变性：可以将 ConfigMap 和 Secret 设置为不可变（immutable），提高性能和安全性。

Kubernetes 污点（Taints）和容忍度（Tolerations）是用于控制 Pod 调度的机制，它们允许节点拒绝（或接受）具有特定容忍度的 Pod。污点（Taints）污点是应用于节点上的键值对，用于阻止 Pod 调度到该节点，除非 Pod 具有匹配的容忍度。污点的组成每个污点包含三个部分：Key：污点的键（必需）Value：污点的值（可选）Effect：污点的影响（必需）污点的影响类型NoSchedule：不会调度新的 Pod 到该节点已存在的 Pod 不受影响适用于专用节点（如 GPU 节点）PreferNoSchedule：尽量不调度新的 Pod 到该节点但如果没有其他可用节点，仍可能调度适用于软性限制NoExecute：不会调度新的 Pod 到该节点已存在的 Pod 如果没有匹配的容忍度，将被驱逐适用于节点维护或故障场景添加污点# 添加 NoSchedule 污点kubectl taint nodes node1 key=value:NoSchedule# 添加 NoExecute 污点kubectl taint nodes node1 key=value:NoExecute# 添加没有值的污点kubectl taint nodes node1 key:NoSchedule查看污点# 查看节点的污点kubectl describe node node1 | grep Taint# 查看所有节点的污点kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints删除污点# 删除指定污点kubectl taint nodes node1 key:NoSchedule-# 删除所有指定键的污点kubectl taint nodes node1 key-容忍度（Tolerations）容忍度是应用于 Pod 上的配置，允许 Pod 调度到具有匹配污点的节点。容忍度的组成容忍度包含以下字段：Key：要容忍的污点键Operator：操作符（Equal 或 Exists）Value：要容忍的污点值（当 Operator 为 Equal 时需要）Effect：要容忍的污点影响TolerationSeconds：容忍时间（仅适用于 NoExecute）容忍度操作符Equal：键和值都必须匹配需要指定 ValueExists：只需要键匹配不需要指定 Value添加容忍度apiVersion: v1kind: Podmetadata: name: my-podspec: tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule" containers: - name: my-container image: nginx容忍度示例容忍特定污点：tolerations:- key: "dedicated" operator: "Equal" value: "gpu" effect: "NoSchedule"容忍所有具有特定键的污点：tolerations:- key: "dedicated" operator: "Exists"容忍所有污点：tolerations:- operator: "Exists"容忍 NoExecute 污点并设置容忍时间：tolerations:- key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute" tolerationSeconds: 300污点和容忍度的匹配规则键匹配：如果容忍度的键为空，则匹配所有污点如果污点的键为空，则不能被任何容忍度匹配操作符匹配：Equal：键和值都必须匹配Exists：只需要键匹配影响匹配：如果容忍度的影响为空，则匹配所有影响否则，影响必须匹配常见使用场景1. 专用节点为特定用途的节点添加污点，确保只有特定的 Pod 可以调度到这些节点。# 为 GPU 节点添加污点kubectl taint nodes gpu-node dedicated=gpu:NoSchedule# 只有 GPU Pod 可以调度到 GPU 节点apiVersion: v1kind: Podmetadata: name: gpu-podspec: tolerations: - key: "dedicated" operator: "Equal" value: "gpu" effect: "NoSchedule" containers: - name: gpu-container image: nvidia/cuda:11.0.3-base-ubuntu20.042. 节点维护使用 NoExecute 污点驱逐 Pod，进行节点维护。# 标记节点为维护状态kubectl taint nodes node1 maintenance:NoExecute3. 特殊硬件节点为具有特殊硬件的节点添加污点，确保只有需要这些硬件的 Pod 可以调度。# 为 SSD 节点添加污点kubectl taint nodes ssd-node disktype=ssd:NoSchedule4. 故障节点Kubernetes 自动为故障节点添加污点，驱逐 Pod。# Pod 容忍节点故障tolerations:- key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute" tolerationSeconds: 300- key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute" tolerationSeconds: 300污点和容忍度 vs 亲和性| 特性 | 污点和容忍度 | 亲和性 ||------|-------------|--------|| 作用对象 | 节点和 Pod | 节点和 Pod || 作用方向 | 节点拒绝 Pod | Pod 选择节点 || 灵活性 | 较低 | 较高 || 使用场景 | 专用节点、节点维护 | 性能优化、高可用性 |最佳实践合理使用污点：避免过度使用污点，可能导致调度失败为专用节点添加污点：确保只有特定的 Pod 可以调度到专用节点设置合理的容忍时间：为 NoExecute 污点设置合理的容忍时间，避免频繁驱逐结合亲和性使用：结合使用污点/容忍度和亲和性，实现更精细的调度控制监控节点状态：监控节点的污点状态，及时处理故障节点文档化污点策略：记录污点和容忍度的使用策略，便于团队协作测试容忍度配置：在非生产环境测试容忍度配置，确保正确性故障排查查看节点污点：kubectl describe node <node-name>查看 Pod 容忍度：kubectl describe pod <pod-name>检查调度失败原因：kubectl describe pod <pod-name> | grep -A 10 Events查看调度器日志：kubectl logs -n kube-system <scheduler-pod-name>示例：多节点类型集群# Master 节点apiVersion: v1kind: Nodemetadata: name: master-nodespec: taints: - key: "node-role.kubernetes.io/master" effect: "NoSchedule"# GPU 节点apiVersion: v1kind: Nodemetadata: name: gpu-nodespec: taints: - key: "dedicated" value: "gpu" effect: "NoSchedule"# 普通 Pod（可以调度到普通节点）apiVersion: v1kind: Podmetadata: name: normal-podspec: containers: - name: nginx image: nginx# GPU Pod（只能调度到 GPU 节点）apiVersion: v1kind: Podmetadata: name: gpu-podspec: tolerations: - key: "dedicated" operator: "Equal" value: "gpu" effect: "NoSchedule" containers: - name: gpu-app image: nvidia/cuda:11.0.3-base-ubuntu20.04

Kubernetes 是一个开源的容器编排平台，用于自动化容器应用的部署、扩展和管理。它最初由 Google 设计并开发，于 2014 年开源，现在由 Cloud Native Computing Foundation（CNCF）管理。核心概念Kubernetes 的核心概念包括：Pod：Kubernetes 中最小的可部署单元，一个 Pod 可以包含一个或多个容器，这些容器共享网络和存储资源。Node：集群中的工作机器，可以是物理机或虚拟机。每个 Node 都运行着容器运行时（如 Docker）、kubelet 和 kube-proxy。Cluster：由多个 Node 组成的集合，是 Kubernetes 管理的计算资源池。Service：定义一组 Pod 的访问策略，提供稳定的网络端点，即使 Pod 的 IP 地址发生变化。Deployment：管理 Pod 和 ReplicaSet 的声明式更新，支持滚动更新和回滚。ConfigMap：用于存储非敏感的配置数据，可以挂载到 Pod 中或作为环境变量使用。Secret：用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。Namespace：用于在同一个集群中创建多个虚拟集群，实现资源隔离。工作原理Kubernetes 采用主从架构：Control Plane（控制平面）：负责集群的决策和响应，包括 API Server、Scheduler、Controller Manager 和 etcd。Worker Node（工作节点）：运行容器化应用，包括 kubelet、kube-proxy 和容器运行时。主要特性自动化部署和回滚：支持声明式配置，自动实现应用的部署和更新。服务发现和负载均衡：自动为容器分配 IP 和 DNS 名称，实现负载均衡。自动扩缩容：根据 CPU 使用率或其他指标自动调整 Pod 数量。自愈能力：自动重启失败的容器、替换节点、重新调度 Pod。存储编排：自动挂载存储系统，如本地存储、云存储等。应用场景Kubernetes 广泛应用于微服务架构、CI/CD 流水线、大数据处理、机器学习等场景，是云原生应用的标准平台。

Kubernetes 工作节点（Worker Node）是集群中运行容器化应用的工作机器，可以是物理机或虚拟机。每个工作节点都运行着必要的组件来管理和运行 Pod。工作节点组件1. kubeletkubelet 是工作节点上的主要代理，负责与控制平面通信并管理 Pod。主要职责：监听 API Server，获取 Pod 的期望状态确保容器按照 Pod 规范运行定期向控制平面报告节点和 Pod 的状态处理容器的生命周期（创建、启动、停止、删除）挂载和卸载存储卷运行健康检查（livenessProbe、readinessProbe、startupProbe）工作原理：kubelet 从 API Server 获取分配到该节点的 Pod 规范通过容器运行时接口（CRI）与容器运行时交互使用容器运行时创建和管理容器定期向 API Server 汇报节点和 Pod 状态配置文件：/var/lib/kubelet/config.yaml默认端口：10250（HTTPS）、10248（健康检查）、10255（只读 HTTP）2. kube-proxykube-proxy 负责维护节点上的网络规则，实现 Service 的负载均衡和服务发现。主要职责：监听 API Server 的 Service 和 Endpoint 变化维护网络规则（iptables 或 IPVS）将流量转发到后端 Pod实现 Service 的负载均衡工作模式：iptables 模式（默认）：使用 iptables 规则实现流量转发性能较好，但规则更新有延迟不支持复杂的负载均衡算法ipvs 模式：使用 Linux IPVS 实现负载均衡支持多种负载均衡算法（轮询、最少连接、源地址哈希等）性能更高，适合大规模集群需要加载 ipvs 内核模块userspace 模式（已废弃）：在用户空间实现负载均衡性能较差，已不再推荐使用配置示例：apiVersion: kubeproxy.config.k8s.io/v1alpha1kind: KubeProxyConfigurationmode: "ipvs"3. 容器运行时（Container Runtime）容器运行时负责运行容器的核心组件。Kubernetes 使用容器运行时接口（CRI）与容器运行时交互。支持的容器运行时：containerd（推荐）：CNCF 毕业项目轻量级、高性能Docker 的底层运行时CRI-O：专为 Kubernetes 设计轻量级、安全OCI 兼容Docker Engine（通过 dockershim，已废弃）：Kubernetes 1.24+ 已移除 dockershim不再推荐使用CRI 工作流程：kubelet 通过 CRI 接口调用容器运行时容器运行时创建和管理容器容器运行时返回容器状态信息节点状态节点条件（Conditions）节点条件描述节点的健康状态：Ready：节点是否健康并可以运行 PodTrue：节点健康False：节点不健康Unknown：节点控制器无法获取节点状态MemoryPressure：节点内存压力True：节点内存不足DiskPressure：节点磁盘压力True：节点磁盘空间不足PIDPressure：节点进程压力True：节点进程数过多NetworkUnavailable：节点网络不可用True：节点网络配置有问题节点容量和可分配资源Capacity：节点的总资源（CPU、内存、存储）Allocatable：节点可分配给 Pod 的资源（扣除系统预留）节点信息OS Image：操作系统镜像Kernel Version：内核版本Kubelet Version：kubelet 版本Container Runtime Version：容器运行时版本节点管理节点维护安全驱逐 Pod：kubectl drain <node-name> --ignore-daemonsets标记节点为不可调度：kubectl cordon <node-name>取消节点不可调度标记：kubectl uncordon <node-name>节点污点（Taints）污点用于阻止 Pod 调度到特定节点：# 添加污点kubectl taint nodes <node-name> key=value:NoSchedule# 查看污点kubectl describe node <node-name> | grep Taint# 删除污点kubectl taint nodes <node-name> key:NoSchedule-污点类型：NoSchedule：不调度新 Pod，已有 Pod 不受影响PreferNoSchedule：尽量不调度，但不是强制NoExecute：不调度新 Pod，已有 Pod 会被驱逐（除非有容忍度）节点标签（Labels）标签用于组织和选择节点：# 添加标签kubectl label nodes <node-name> disktype=ssd# 查看标签kubectl get nodes --show-labels# 删除标签kubectl label nodes <node-name> disktype-节点健康检查kubelet 定期执行健康检查：节点状态检查：检查节点资源是否充足容器健康检查：执行 livenessProbe 和 readinessProbe镜像拉取检查：检查镜像是否可用最佳实践资源预留：为系统进程和 kubelet 预留足够的 CPU 和内存监控节点：监控节点的 CPU、内存、磁盘和网络使用情况日志收集：收集 kubelet 和容器运行时的日志安全加固：使用 TLS 加密通信限制 kubelet API 访问定期更新组件版本节点维护：使用 drain 命令安全维护节点自动扩缩容：使用 Cluster Autoscaler 自动调整节点数量污点和容忍度：合理使用污点和容忍度控制 Pod 调度节点亲和性：使用节点亲和性优化 Pod 分配故障排查查看节点状态：kubectl describe node <node-name>查看 kubelet 日志：journalctl -u kubelet查看容器运行时日志：journalctl -u containerd检查节点资源：kubectl top nodes

Kubernetes 亲和性（Affinity）和反亲和性（Anti-Affinity）是用于控制 Pod 调度的机制，它们允许用户定义 Pod 与节点或其他 Pod 之间的关系，从而影响调度决策。亲和性类型1. 节点亲和性（Node Affinity）节点亲和性用于控制 Pod 调度到哪些节点上。requiredDuringSchedulingIgnoredDuringExecution硬性要求，Pod 必须调度到满足条件的节点上，否则调度失败。apiVersion: v1kind: Podmetadata: name: with-node-affinityspec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - us-west-1a containers: - name: my-container image: nginxpreferredDuringSchedulingIgnoredDuringExecution软性偏好，调度器优先选择满足条件的节点，但如果没有满足条件的节点，也可以调度到其他节点。apiVersion: v1kind: Podmetadata: name: with-node-affinityspec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: disktype operator: In values: - ssd containers: - name: my-container image: nginx2. Pod 亲和性（Pod Affinity）Pod 亲和性用于控制 Pod 调度到哪些节点上，基于已经运行在该节点上的 Pod。requiredDuringSchedulingIgnoredDuringExecutionapiVersion: v1kind: Podmetadata: name: with-pod-affinityspec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: topology.kubernetes.io/zone containers: - name: my-container image: nginxpreferredDuringSchedulingIgnoredDuringExecutionapiVersion: v1kind: Podmetadata: name: with-pod-affinityspec: affinity: podAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: topology.kubernetes.io/zone containers: - name: my-container image: nginx3. Pod 反亲和性（Pod Anti-Affinity）Pod 反亲和性用于控制 Pod 不调度到哪些节点上，基于已经运行在该节点上的 Pod。requiredDuringSchedulingIgnoredDuringExecutionapiVersion: v1kind: Podmetadata: name: with-pod-antiaffinityspec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - web topologyKey: kubernetes.io/hostname containers: - name: my-container image: nginxpreferredDuringSchedulingIgnoredDuringExecutionapiVersion: v1kind: Podmetadata: name: with-pod-antiaffinityspec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - web topologyKey: kubernetes.io/hostname containers: - name: my-container image: nginx操作符类型In：标签的值在给定的列表中NotIn：标签的值不在给定的列表中Exists：标签存在DoesNotExist：标签不存在Gt：标签的值大于给定值（仅适用于数值）Lt：标签的值小于给定值（仅适用于数值）拓扑域键（Topology Key）拓扑域键用于定义节点的分组方式，常见的拓扑域键包括：kubernetes.io/hostname：按主机名分组topology.kubernetes.io/zone：按可用区分组topology.kubernetes.io/region：按区域分组node.kubernetes.io/instance-type：按实例类型分组亲和性规则的行为调度阶段（During Scheduling）required：硬性要求，必须满足preferred：软性偏好，优先满足执行阶段（During Execution）Ignored：Pod 运行后，如果条件不再满足，不影响已运行的 PodRequired：Pod 运行后，如果条件不再满足，需要驱逐 Pod（目前不支持）亲和性 vs nodeSelector| 特性 | nodeSelector | 节点亲和性 ||------|--------------|-----------|| 复杂度 | 简单 | 复杂 || 灵活性 | 低 | 高 || 支持的操作符 | 等值 | 多种操作符 || 优先级 | 无 | 支持权重 |使用场景节点亲和性使用场景硬件要求：将 Pod 调度到具有特定硬件的节点（如 GPU、SSD）区域要求：将 Pod 调度到特定区域或可用区操作系统要求：将 Pod 调度到运行特定操作系统的节点Pod 亲和性使用场景通信优化：将需要频繁通信的 Pod 调度到同一节点，减少网络延迟依赖关系：将依赖的 Pod 调度到同一节点，提高性能数据局部性：将 Pod 调度到存储数据的节点附近Pod 反亲和性使用场景高可用性：将相同应用的 Pod 分散到不同节点，避免单点故障资源竞争：避免资源密集型 Pod 调度到同一节点故障隔离：将不同应用的 Pod 分散到不同节点，减少故障影响范围最佳实践合理使用硬性要求：避免过度使用 required 规则，可能导致调度失败设置合理的权重：为 preferred 规则设置合适的权重，影响调度决策使用标签和注解：为节点和 Pod 添加有意义的标签，便于使用亲和性规则监控调度结果：监控 Pod 的调度情况，确保亲和性规则按预期工作结合污点和容忍度：结合使用亲和性和污点/容忍度，实现更精细的调度控制避免过度复杂：避免创建过于复杂的亲和性规则，影响调度性能测试规则：在非生产环境测试亲和性规则，确保正确性示例：高可用 Web 应用apiVersion: apps/v1kind: Deploymentmetadata: name: web-appspec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - web topologyKey: kubernetes.io/hostname nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: disktype operator: In values: - ssd containers: - name: web image: nginx ports: - containerPort: 80这个示例确保：每个 Web Pod 调度到不同的节点（高可用性）优先选择具有 SSD 的节点（性能优化）

Kubernetes 中的 Pod 是最小的可部署单元，它包含一个或多个紧密相关的容器，这些容器共享网络和存储资源。Pod 的特点共享网络命名空间：同一个 Pod 中的容器共享同一个 IP 地址和端口空间，可以通过 localhost 相互通信。共享存储卷：Pod 中的容器可以共享挂载的存储卷，实现数据共享和持久化。原子性调度：Pod 作为一个整体被调度到同一个 Node 上运行。临时性：Pod 是临时的、可替换的，当 Pod 被删除或 Node 发生故障时，Pod 不会自动恢复。Pod 的生命周期Pod 的生命周期包括以下阶段：Pending：Pod 已被创建，但容器尚未启动，可能是因为镜像下载中或资源不足。Running：Pod 中的所有容器都已创建，至少有一个容器正在运行。Succeeded：Pod 中的所有容器都已成功终止。Failed：Pod 中的所有容器都已终止，但至少有一个容器以失败状态终止。Unknown：无法获取 Pod 的状态，通常是因为与 Pod 所在的 Node 通信失败。Pod 的重启策略Kubernetes 支持三种 Pod 重启策略：Always：容器失败时总是重启，这是默认策略。OnFailure：只有在容器以非零退出码失败时才重启。Never：容器失败时不重启。Pod 与容器的关系Pod 是容器的封装，一个 Pod 可以包含：单个主容器（最常见）一个主容器加一个或多个辅助容器（Sidecar 模式）多个协作的容器最佳实践一个 Pod 一个容器：对于大多数应用，建议一个 Pod 只包含一个容器，这样可以更好地管理和扩展。使用 Sidecar 模式：当需要多个紧密协作的容器时，可以使用 Sidecar 模式，例如日志收集、监控代理等。避免在 Pod 中运行多个不相关的容器：这会增加管理的复杂性，不利于扩展和故障排查。合理设置资源限制：为 Pod 设置 CPU 和内存的 requests 和 limits，避免资源争用。使用健康检查：配置 livenessProbe 和 readinessProbe，确保 Pod 的健康状态。

Kubernetes Service 是定义一组 Pod 的访问策略的抽象，它为 Pod 提供稳定的网络端点，即使 Pod 的 IP 地址发生变化，Service 也能保证服务的可访问性。Service 的作用服务发现：Service 为一组 Pod 提供统一的访问入口，客户端不需要知道具体的 Pod IP 地址。负载均衡：Service 自动将流量分发到后端的多个 Pod，实现负载均衡。稳定的网络标识：Service 拥有固定的 IP 地址和 DNS 名称，即使 Pod 重新创建，Service 的地址也不会改变。Service 的类型Kubernetes 支持四种 Service 类型：ClusterIP（默认）：在集群内部暴露服务只能从集群内部访问适合内部服务之间的通信NodePort：在每个 Node 上开放一个端口可以通过 NodeIP:Port 从外部访问端口范围：30000-32767LoadBalancer：在云提供商处创建外部负载均衡器自动将流量分发到 NodePort需要云提供商支持ExternalName：将服务映射到外部 DNS 名称不创建代理或负载均衡器适用于访问外部服务Service 的工作原理Service 通过 kube-proxy 实现：iptables 模式（默认）：kube-proxy 监听 API Server 的 Service 和 Endpoint 变化使用 iptables 规则将流量转发到后端 Pod性能较好，但更新规则时会有延迟IPVS 模式：使用 Linux IPVS（IP Virtual Server）实现负载均衡支持多种负载均衡算法（轮询、最少连接等）性能更高，适合大规模集群Service 的选择器Service 通过 selector 选择要代理的 Pod：apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 8080EndpointService 的后端由 Endpoint 对象维护，Endpoint 包含所有匹配 selector 的 Pod 的 IP 地址和端口。无选择器的 ServiceService 可以不指定 selector，此时需要手动创建 Endpoint 对象，用于：访问集群外部的服务访问其他命名空间的服务访问外部数据库等最佳实践使用 ClusterIP 作为默认类型：除非需要外部访问，否则使用 ClusterIP 以提高安全性。合理设置 sessionAffinity：对于有状态的应用，可以设置 sessionAffinity 为 ClientIP，实现会话保持。使用 Headless Service：对于需要直接访问 Pod 的场景（如 StatefulSet），可以使用 Headless Service（ClusterIP: None）。监控 Service 的健康状态：定期检查 Endpoint 的状态，确保后端 Pod 正常。使用 Ingress 替代 LoadBalancer：对于 HTTP/HTTPS 服务，使用 Ingress 可以更灵活地管理路由和 SSL。

Kubernetes PersistentVolume（PV）和 PersistentVolumeClaim（PVC）是用于管理存储的两种重要资源，它们实现了存储资源的声明式管理和动态分配。PersistentVolume（PV）PersistentVolume 是集群中的一块存储，由管理员预先配置或通过存储类动态创建。PV 是集群级别的资源，独立于 Pod 的生命周期。PV 的生命周期Provisioning（配置）：静态配置：管理员手动创建 PV动态配置：通过 StorageClass 自动创建Binding（绑定）：PVC 请求存储时，控制器将 PVC 绑定到合适的 PV绑定是一对一的，一旦绑定，PV 就专属于该 PVCUsing（使用）：Pod 通过 PVC 使用存储存储可以挂载到 Pod 的指定路径Releasing（释放）：PVC 删除后，PV 进入 Released 状态PV 中的数据仍然保留Reclaiming（回收）：Retain（保留）：手动回收Recycle（回收）：已废弃，使用动态配置替代Delete（删除）：自动删除 PV 和底层存储PV 的访问模式ReadWriteOnce（RWO）：卷可以被单个节点以读写模式挂载适用于块存储ReadOnlyMany（ROX）：卷可以被多个节点以只读模式挂载适用于共享只读数据ReadWriteMany（RWX）：卷可以被多个节点以读写模式挂载适用于文件系统（如 NFS）ReadWriteOncePod（RWOP）：卷可以被单个 Pod 以读写模式挂载确保同一时间只有一个 Pod 访问PV 的状态Available：可用，未绑定到任何 PVCBound：已绑定到 PVCReleased：PVC 已删除，但资源尚未被集群回收Failed：自动回收失败PersistentVolumeClaim（PVC）PVC 是用户对存储的请求，类似于 Pod 对计算资源的请求。PVC 是命名空间级别的资源。PVC 的配置apiVersion: v1kind: PersistentVolumeClaimmetadata: name: my-pvcspec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: standard selector: matchLabels: environment: productionPVC 的使用在 Pod 中使用 PVC：apiVersion: v1kind: Podmetadata: name: my-podspec: containers: - name: my-container image: nginx volumeMounts: - name: my-volume mountPath: /data volumes: - name: my-volume persistentVolumeClaim: claimName: my-pvc在 Deployment 中使用 PVC：apiVersion: apps/v1kind: Deploymentmetadata: name: my-deploymentspec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: volumes: - name: my-volume persistentVolumeClaim: claimName: my-pvc containers: - name: my-container image: nginx volumeMounts: - name: my-volume mountPath: /dataStorageClassStorageClass 定义了不同类型的存储，支持动态配置 PV。StorageClass 的配置apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: fastprovisioner: kubernetes.io/aws-ebsparameters: type: gp2 iopsPerGB: "10"reclaimPolicy: DeletevolumeBindingMode: WaitForFirstConsumerallowVolumeExpansion: true常见的 Provisionerkubernetes.io/aws-ebs：AWS EBS 块存储kubernetes.io/gce-pd：GCE 持久化磁盘kubernetes.io/azure-disk：Azure 磁盘kubernetes.io/azure-file：Azure 文件存储kubernetes.io/cinder：OpenStack Cinderkubernetes.io/nfs：NFS 存储rancher.io/local-path：本地路径存储StorageClass 参数provisioner：存储提供者parameters：存储提供者特定的参数reclaimPolicy：回收策略（Delete 或 Retain）volumeBindingMode：Immediate：立即绑定WaitForFirstConsumer：等待第一个消费者allowVolumeExpansion：是否允许卷扩展动态配置动态配置允许根据 PVC 自动创建 PV，无需管理员手动创建。动态配置流程用户创建 PVC，指定 StorageClassPersistentVolumeController 监听到 PVC控制器调用 StorageClass 的 provisioner 创建 PVPV 绑定到 PVCPod 可以使用 PVC动态配置示例apiVersion: v1kind: PersistentVolumeClaimmetadata: name: dynamic-pvcspec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: fast静态配置静态配置需要管理员手动创建 PV，适用于特定的存储需求。静态 PV 示例apiVersion: v1kind: PersistentVolumemetadata: name: manual-pv labels: type: localspec: storageClassName: manual capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /mnt/dataPV 和 PVC 的区别| 特性 | PV | PVC ||------|----|-----|| 作用域 | 集群级别 | 命名空间级别 || 创建者 | 管理员或动态配置 | 用户 || 用途 | 提供存储资源 | 请求存储资源 || 生命周期 | 独立于 Pod | 依赖于 Pod |最佳实践使用动态配置：优先使用 StorageClass 动态配置，减少手动管理设置合理的回收策略：生产环境使用 Retain，测试环境使用 Delete使用访问模式：根据应用需求选择合适的访问模式监控存储使用：监控 PV 和 PVC 的使用情况备份重要数据：定期备份 PV 中的重要数据使用标签和注解：为 PV 和 PVC 添加有意义的标签和注解设置资源限制：为 PVC 设置合理的存储请求使用存储类：为不同的应用需求创建不同的 StorageClass故障排查查看 PV 状态：kubectl get pvkubectl describe pv <pv-name>查看 PVC 状态：kubectl get pvckubectl describe pvc <pvc-name>查看 StorageClass：kubectl get storageclasskubectl describe storageclass <sc-name>查看 Pod 挂载情况：kubectl describe pod <pod-name>查看事件：kubectl get events --sort-by=.metadata.creationTimestamp