企业官网建设流程全解析

1. 从“集装箱”到“超级码头”：一个形象的比喻

如果你刚接触容器和Kubernetes，面对一堆陌生的术语和概念，可能会感到一头雾水。别担心，我们可以用一个非常经典的比喻来理解它们：Docker就像是标准化的“集装箱”，而Kubernetes（K8s）则是管理这些集装箱的“超级自动化码头”。

想象一下在集装箱出现之前的航运业。货物五花八门，有袋装的、箱装的、散装的，每艘船都需要根据货物形状定制装载方案，装卸效率极低，不同运输工具之间也难以衔接。Docker容器技术所做的，就是为软件应用定义了一个标准的“集装箱”。无论你的应用是用Java、Python还是Go写的，无论它需要什么依赖库，Docker都能把它和它运行所需的一切环境（代码、运行时、系统工具、系统库、设置）打包成一个轻量级、可移植的“镜像”。这个镜像在任何安装了Docker引擎的机器上，都能以完全一致的方式运行起来，就像集装箱可以在任何标准货轮、火车、卡车上运输一样。这彻底解决了“在我机器上能跑，到你那就出问题”的经典难题。

那么，当你的业务规模扩大，需要运行成百上千个这样的“集装箱”（微服务应用）时，问题就来了：谁来调度这些集装箱到最合适的服务器（轮船）上？某个集装箱挂了怎么办？如何让外界访问到集装箱里的服务？如何根据流量自动增减集装箱的数量？这时，你就需要一个“超级码头”管理系统。这就是Kubernetes（K8s）的角色。它来自希腊语，意为“舵手”或“飞行员”，非常贴切。K8s这个自动化码头，负责管理一个由多台服务器（物理机或虚拟机）组成的“集群”。它能自动部署你的容器应用，保证指定数量的容器副本始终运行，在容器失败时自动重启或迁移，根据资源使用情况或自定义指标自动扩缩容，并提供统一的网络、存储和安全策略。你只需要告诉K8s你想要的应用状态（例如：运行3个副本的Web服务，每个需要1核CPU、2G内存），它就会自动、持续地调整实际状态去匹配你的期望状态。

简单来说，Docker解决了应用“构建”和“封装”的标准化问题，而Kubernetes解决了大规模容器化应用的“编排”和“管理”问题。两者结合，构成了现代云原生应用架构的基石。接下来，我们就深入这个“码头”，看看Docker和K8s各自的核心组件是如何工作的。

2. Docker核心：镜像、容器与引擎的三层架构

要理解Docker，必须厘清三个核心概念：镜像（Image）、容器（Container）和Docker引擎（Docker Engine）。它们的关系，类似于面向对象编程中的“类”和“对象”。

2.1 镜像：不可变的蓝图

镜像是创建容器的模板，是一个只读的、分层的文件系统快照。你可以把它理解为一个应用程序及其所有依赖的“安装包”或“蓝图”。这个蓝图一旦创建就不可更改。镜像是通过一个名为Dockerfile的文本文件定义构建的。Dockerfile里是一系列指令，例如从某个基础镜像开始（FROM ubuntu:20.04）、复制文件（COPY . /app）、运行安装命令（RUN apt-get update && apt-get install -y python3）、声明启动命令（CMD ["python3", "app.py"]）等。

分层存储是镜像设计的关键。Docker镜像由一系列只读层（Layer）堆叠而成。每一层代表Dockerfile中的一条指令。例如，第一层是基础操作系统层，第二层是添加的软件包，第三层是复制的应用代码。这种设计带来了巨大优势：

1. 共享与复用：如果两个镜像都基于同一个ubuntu:20.04层，那么宿主机上只需要存储一份该层数据，极大地节省了磁盘空间。
2. 快速构建：当你修改Dockerfile并重新构建镜像时，Docker只会重建那些发生变化的层及其之后的层，未变化的层会直接复用缓存，使得构建速度极快。

2.2 容器：运行时的实例

容器是镜像的一个运行时的、可写的实例。当你执行docker run命令时，Docker引擎会基于指定的镜像创建一个容器。这个过程相当于根据“蓝图”（镜像）启动了一个“进程”（容器）。

关键点在于，容器在镜像的只读层之上，添加了一个可写的容器层（Container Layer）。所有对运行中容器的文件修改（如写入日志、生成临时文件、安装新软件）都发生在这个可写层。当容器被删除时，这个可写层也会随之消失，因此容器本身是无状态的。这种特性使得容器具有极致的轻量性和一致性：基于同一个镜像启动的多个容器，初始状态完全一致。

容器与虚拟机的本质区别也在于此。传统虚拟机（VM）需要模拟完整的硬件，并在上面运行一个完整的客户操作系统（Guest OS），资源开销大，启动慢。而容器直接共享宿主机的操作系统内核，通过Linux的命名空间（Namespace）实现进程、网络、文件系统等资源的隔离，通过控制组（Cgroup）实现CPU、内存等资源的限制。因此，容器本质上是一个被隔离的进程，它比虚拟机更轻量、启动更快（秒级 vs 分钟级）、资源利用率更高。

2.3 Docker引擎：背后的驱动者

Docker引擎是一个客户端-服务器架构的应用，主要包含以下组件：

• Docker守护进程（Dockerd）：一个常驻后台的进程，负责管理镜像、容器、网络和存储卷。它监听Docker API请求。
• Docker客户端（Docker CLI）：我们常用的docker命令工具。它通过命令行或API与守护进程通信，发送构建、运行等指令。
• 容器运行时（Containerd）：一个更底层的、专注于容器生命周期管理的守护进程。Docker引擎实际上调用containerd来创建和运行容器。现在，containerd已经成为一个行业标准的容器运行时，也被Kubernetes所采用。

注意：在实际生产环境中，尤其是在Linux服务器上，直接安装Docker引擎（Docker CE/EE）是最常见的方式。但在Windows或macOS上，由于内核不同，需要安装Docker Desktop，它内置了一个轻量级Linux虚拟机来运行容器，这也是为什么有时会遇到“virtualization support not detected”这类错误，需要检查BIOS中的虚拟化（VT-x/AMD-V）是否开启。

理解了Docker这个“集装箱”的制造和运行原理，我们再来看看当我们需要管理一个遍布全球、拥有无数船舶和集装箱的庞大航运公司时，所需要的“超级码头”系统——Kubernetes。

3. Kubernetes架构：Master与Node的协同作战

Kubernetes集群由一组称为节点（Node）的机器组成，这些节点被分为两类角色：控制平面（Control Plane，旧称Master）和工作节点（Worker Node）。这种主从架构确保了管理职责的清晰分离和高可用性。

3.1 控制平面：集群的大脑与指挥中心

控制平面负责管理集群的全局状态和决策。它通常部署在独立的、高可用的服务器上，包含以下核心组件：

1. kube-apiserver：集群的唯一入口和“前台”。所有内部组件（如控制器）和外部用户（通过kubectl或API）与集群的交互都必须经过它。它负责验证请求、处理RESTful操作，并将状态更新存储到etcd。
2. etcd：一个高可用的分布式键值存储数据库，是Kubernetes的“记忆中枢”。集群的所有配置数据、状态信息（如Pod、Service、Deployment的定义和当前状态）都持久化保存在这里。它的数据安全性和一致性至关重要。
3. kube-scheduler：调度器。它监视新创建的、还未被分配到任何节点的Pod（K8s的最小调度单元，通常包含一个或多个容器），根据资源需求、亲和性/反亲和性规则、数据位置等因素，为Pod选择一个最合适的工作节点。
4. kube-controller-manager：控制器管理器。它运行着一系列控制器进程，每个控制器都是一个独立的控制循环，负责将集群的当前状态驱向期望状态。例如：
   • Node控制器：负责在节点出现故障时做出响应。
   • Replication控制器：确保Pod的副本数量始终符合预期。
   • Deployment控制器：为Pod和ReplicaSet提供声明式更新。
   • Service控制器：负责创建和管理Service（网络服务）。

3.2 工作节点：任务的执行者

工作节点是容器（Pod）实际运行的地方。每个节点上都需要运行以下组件：

1. kubelet：节点上的代理。它负责与控制平面通信，接收指令（如运行某个Pod），并管理本节点上Pod的生命周期（创建、启动、停止、监控）。同时，它也向apiserver报告本节点的状态和资源使用情况。
2. 容器运行时（Container Runtime）：负责运行容器的软件。早期主要是Docker，但现在Kubernetes通过容器运行时接口（CRI）支持多种运行时，如containerd（目前最主流）、CRI-O等。kubelet通过CRI与容器运行时交互，拉取镜像、启动和停止容器。
3. kube-proxy：网络代理。它运行在每个节点上，维护节点上的网络规则（如iptables或ipvs规则），实现Kubernetes Service概念。正是kube-proxy使得Pod可以通过一个稳定的虚拟IP（ClusterIP）被访问，无论后端Pod如何变化或迁移。

它们如何协同工作？假设你通过kubectl提交了一个Deployment配置文件，要求运行3个Nginx副本。

1. kubectl将请求发送给kube-apiserver。
2. kube-apiserver验证请求后，将Deployment的期望状态写入etcd。
3. Deployment控制器（在kube-controller-manager内）监听到etcd中有了新的Deployment对象，它意识到需要创建对应的ReplicaSet和Pod来满足副本数要求，于是创建这些对象并写入etcd。
4. kube-scheduler监听到有新的Pod被创建且尚未调度，它根据算法选择一个最优的工作节点，并将该节点信息更新到Pod对象（在etcd中）。
5. 目标节点上的kubelet通过watch机制，从apiserver得知有一个Pod被调度到了自己这里。它通过CRI调用本地的容器运行时，拉取Nginx镜像并启动容器。
6. 同时，Service控制器可能会为这些Pod创建对应的Service。kube-proxy在所有节点上监听到Service和Pod的变化，更新本地的iptables/ipvs规则，使得Service的虚拟IP能够正确路由到后端的Pod。

这套精密的协作机制，使得Kubernetes能够以高度自动化的方式管理大规模的容器化应用。接下来，我们看看在这个体系中，最核心的抽象概念——Pod。

4. Pod：Kubernetes的最小调度与部署单元

这是Kubernetes中最重要也最容易让人困惑的概念之一。很多人会问：“既然有了容器，为什么还需要Pod？” 理解Pod是理解K8s设计哲学的关键。

4.1 为什么是Pod，而不是单个容器？

Kubernetes不直接管理容器，而是管理Pod。一个Pod是一组紧密关联、共享资源的容器集合。你可以把它想象成一个“逻辑主机”，里面的容器就像运行在同一台物理机上的多个进程，它们共享：

• 网络命名空间：同一个Pod内的所有容器共享同一个IP地址和端口空间。它们可以通过localhost互相通信，避免了复杂的端口映射。
• 存储卷（Volume）：Pod可以定义一组存储卷，这些卷可以被Pod内的所有容器挂载到各自的文件系统路径，从而实现容器间的数据共享。
• UTS命名空间：共享主机名。

这种设计是为了支持**“边车模式（Sidecar Pattern）”**。例如，你的主应用容器是一个Web服务器，而另一个容器（Sidecar）负责从服务器拉取日志文件并发送到日志中心。这两个容器需要共享日志目录，并且网络通信紧密，将它们放在同一个Pod里是最自然、最高效的方式。

4.2 Pod的生命周期与设计模式

Pod的生命周期是短暂的、非持久的。它会被调度到某个节点上运行，当节点故障、资源不足或Pod本身失败时，它会被终止并在其他节点上重新创建。因此，Pod的IP地址是不稳定的。这正是Kubernetes引入更高层次抽象（如Service）的原因。

基于Pod，Kubernetes定义了多种控制器（Controller）来管理Pod的部署和更新策略：

• Deployment：最常用的控制器，用于部署无状态应用。它管理ReplicaSet，而ReplicaSet确保指定数量的Pod副本始终运行。它支持声明式的滚动更新和回滚，是管理应用发布的利器。
• StatefulSet：用于部署有状态应用（如数据库）。它为每个Pod提供稳定的、唯一的网络标识符（主机名）和持久化存储，并规定了Pod的创建、扩缩容和删除顺序。
• DaemonSet：确保集群中所有（或部分）节点上都运行一个Pod副本。常用于运行集群级别的守护进程，如日志收集器（Fluentd）、监控代理（Node Exporter）或网络插件。
• Job/CronJob：用于运行一次性任务或定时任务。任务完成后，Pod会结束运行。

Pod的设计体现了Kubernetes的核心思想：声明式API和控制器模式。你通过YAML文件声明“期望状态”（例如，运行3个Nginx Pod），而控制器则持续地检查“当前状态”，并驱动系统向“期望状态”收敛。这种模式将运维人员从繁琐的手动操作和故障处理中解放出来。然而，要让这些动态创建和销毁的Pod能够被稳定地访问，就需要Kubernetes的另一个核心概念——Service。

5. Service与Ingress：暴露和访问服务的稳定方式

由于Pod是短暂且IP不固定的，客户端不能直接依赖Pod IP来访问服务。Kubernetes提供了Service和Ingress来提供稳定的网络端点。

5.1 Service：稳定的网络抽象

Service定义了一组Pod的逻辑集合和一个访问它们的策略。它为这组Pod提供了一个统一的、稳定的虚拟IP（ClusterIP）和DNS名称。Service通过标签选择器（Label Selector）来匹配属于它的Pod。

Service主要有三种类型：

1. ClusterIP（默认）：在集群内部提供一个虚拟IP，只能从集群内部访问。这是服务间通信的主要方式。
2. NodePort：在ClusterIP的基础上，在每个节点的指定端口（30000-32767范围）上暴露服务。这样，集群外的客户端可以通过<任意节点IP>:<NodePort>来访问服务。适用于开发测试或需要直接从外部访问的简单场景。
3. LoadBalancer：通常与云提供商（如AWS、GCP、Azure）集成，自动创建一个外部负载均衡器，并将流量转发到Service（通常是NodePort）。这是在生产环境向公网暴露服务的标准方式。

Service是如何工作的？当你创建一个Service时，kube-proxy组件会监听到这个事件。它会根据Service的类型，在本节点上配置相应的网络规则（如iptables或ipvs）。当有流量发往Service的虚拟IP时，这些规则会将流量负载均衡到后端健康的Pod上。整个过程对Pod和客户端都是透明的。

5.2 Ingress：集群的HTTP/HTTPS流量入口

Service的LoadBalancer类型每个服务都会创建一个云负载均衡器，成本高且不便管理。Ingress是一个更上层的抽象，它充当集群的“智能路由层”或“入口控制器”。

• Ingress资源：本身只是一个API对象，定义了一系列路由规则。例如，将www.example.com/app1的流量路由到app1-service，将/app2的流量路由到app2-service，并可以配置TLS终止、重写路径等。
• Ingress Controller：这才是真正干活的部分。它是一个Pod，负责监听Ingress资源的变化，并动态配置一个实际的负载均衡器或反向代理服务器（如Nginx、Traefik、HAProxy）来实现这些规则。云厂商也提供自己的Ingress Controller。

简单来说，一个Ingress Controller + 多条Ingress规则，就可以替代多个LoadBalancer类型的Service，用一个公网IP和负载均衡器来管理所有对集群内服务的HTTP/HTTPS访问，极大地简化了网络管理和成本。

掌握了服务暴露，应用就可以被访问了。但在生产环境中，我们还需要考虑如何管理应用的配置、存储持久化数据以及保障应用安全。这就引出了Kubernetes的另外三个核心概念：ConfigMap、Secret和Volume。

6. 配置、存储与安全：ConfigMap、Secret与Volume

在微服务架构中，应用配置、敏感信息和持久化数据的管理至关重要。Kubernetes提供了原生资源对象来优雅地处理这些问题。

6.1 ConfigMap：解耦配置与镜像

将配置信息（如环境变量、配置文件）硬编码在容器镜像中是极不灵活的。ConfigMap允许你将配置数据从容器镜像中解耦出来，以键值对的形式存储。这些数据可以通过以下方式注入到Pod中：

• 环境变量：在Pod定义中，将ConfigMap的某个键值设置为容器的环境变量。
• 挂载为文件：将整个ConfigMap或其中部分数据，以卷（Volume）的形式挂载到容器内的指定目录。目录下会生成以键名命名的文件，文件内容即为键值。这样，应用就可以像读取本地配置文件一样读取配置。

这使得你可以为不同环境（开发、测试、生产）创建不同的ConfigMap，而使用同一个应用镜像，实现了“一次构建，多处部署”。

6.2 Secret：安全地管理敏感信息

Secret与ConfigMap类似，但专门用于存储敏感数据，如密码、OAuth令牌、SSH密钥等。Kubernetes会对Secret数据进行Base64编码（并非加密），并以相对安全的方式处理它（例如，在etcd中可配置加密存储，在节点上仅以tmpfs文件形式存在）。使用方法与ConfigMap相同，可以挂载为文件或设置为环境变量。

重要实操心得：尽管Secret提供了一定保护，但它并非绝对安全。任何有权限读取该Secret的用户或Pod都能看到其内容。对于更高安全级别的需求（如数据库根密码），应考虑与云厂商的密钥管理服务（如AWS KMS, Azure Key Vault）集成，或使用像SealedSecrets这样的第三方工具进行加密。

6.3 Volume：持久化存储的抽象

容器的文件系统是临时的，容器重启后，写入容器层的数据会丢失。Volume（存储卷）提供了在Pod生命周期内持久化存储数据的能力，并且卷中的数据可以在Pod重启后保留。更重要的是，一些类型的卷可以被同一个Pod内的多个容器共享。

Kubernetes支持多种卷类型：

• 本地卷：如emptyDir（临时空目录，Pod删除则数据丢失）、hostPath（挂载节点主机文件系统，慎用，破坏可移植性）。
• 网络存储卷：这才是生产环境的主流。它们将外部存储系统抽象成卷，供Pod使用。例如：
  • awsElasticBlockStore(EBS) /azureDisk/gcePersistentDisk：云平台提供的块存储。
  • nfs：网络文件系统。
  • cephfs/glusterfs：分布式文件系统。
  • PersistentVolume (PV) / PersistentVolumeClaim (PVC)：这是Kubernetes提供的动态存储供应机制。管理员可以预先创建一批PV（存储资源池），用户通过创建PVC（存储声明）来“申请”存储。Kubernetes会自动为PVC绑定一个符合条件的PV。对于云环境，更常用的是StorageClass，它允许动态按需创建PV，无需管理员预先创建。

通过ConfigMap、Secret和Volume，Kubernetes为应用提供了完善的外部资源集成方案。当我们的应用和配置都就绪后，如何将其交付到Kubernetes集群并管理其生命周期呢？这就需要用到声明式的配置文件和强大的命令行工具。

7. 实战入门：从YAML文件到kubectl命令

理论最终要服务于实践。要操作Kubernetes，你需要掌握两样东西：声明式的YAML配置文件和命令式的kubectl命令行工具。

7.1 声明式配置：YAML文件

Kubernetes的所有资源对象（Pod、Deployment、Service等）都可以通过YAML或JSON格式的文件来定义。这是一种“声明式”的操作：你描述期望的状态，Kubernetes负责使其变为现实。

一个典型的Deployment YAML文件结构如下：

apiVersion: apps/v1 # API版本 kind: Deployment # 资源类型 metadata: # 元数据 name: nginx-deployment labels: app: nginx spec: # 规格，描述期望状态 replicas: 3 # 期望的Pod副本数 selector: # 标签选择器，管理哪些Pod matchLabels: app: nginx template: # Pod模板 metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80

关键字段解析：

• apiVersion和kind：唯一确定资源类型。
• metadata.name：资源在命名空间内的唯一名称。
• spec.selector：控制器通过这个选择器来查找它要管理的Pod。它必须与spec.template.metadata.labels匹配。
• spec.template：定义Pod的规格，当需要创建新Pod时，就按这个模板来。

7.2 核心kubectl命令

kubectl是与Kubernetes集群交互的主要命令行工具。

基础操作：

• kubectl apply -f <file.yaml>：最常用的命令。创建或更新资源。如果资源不存在则创建，存在则根据文件内容更新。它是声明式操作的代表。
• kubectl get <resource>：列出资源。如kubectl get pods,kubectl get deployments。加-w参数可以watch实时变化。
• kubectl describe <resource> <name>：查看某个资源的详细信息，包括事件（Events），这对于排错至关重要。
• kubectl logs <pod-name>：查看Pod内容器的日志。加-f可以实时跟踪日志流。
• kubectl exec -it <pod-name> -- /bin/bash：进入Pod内的容器执行命令，类似于docker exec，常用于调试。

排错与调试：

• kubectl get events --sort-by=.metadata.creationTimestamp：查看集群事件，按时间排序，有助于发现调度失败、镜像拉取错误等问题。
• 当Pod处于Pending状态时，使用kubectl describe pod <pod-name>查看原因，通常是资源不足或节点选择器不匹配。
• 当Pod处于CrashLoopBackOff状态时，首先用kubectl logs查看应用日志，然后用kubectl describe查看详细事件。

实操心得：资源管理

• 始终为Pod中的容器设置资源请求（requests）和限制（limits）。requests用于调度决策（kube-scheduler根据这个值选择有足够资源的节点），limits是容器能使用的资源上限。不设置limits可能导致某个容器耗尽节点资源，影响其他应用。

  resources: requests: memory: "64Mi" cpu: "250m" # 250 milli-cores limits: memory: "128Mi" cpu: "500m"

• 使用命名空间（Namespace）来隔离不同环境（如dev, staging, prod）或不同团队的项目。kubectl get pods -n dev。

从单机Docker到集群化的Kubernetes，技术栈的复杂度显著提升。在实际学习和生产部署中，你会遇到比本地开发复杂得多的情况。接下来，我们就聊聊从学习到生产，你需要跨越的那些关键阶梯和常见陷阱。

8. 从学习到生产：部署考量与常见陷阱

在个人电脑上通过Minikube或Docker Desktop成功运行一个K8s集群，与在生产环境中部署一个高可用、可扩展、安全的K8s集群，完全是两回事。这里梳理几个关键的进阶考量和常见陷阱。

8.1 部署模式选择

1. 托管Kubernetes服务（推荐给大多数团队）：如AWS EKS， Google GKE， Azure AKS， 阿里云ACK。云服务商负责管理控制平面（Master节点）的高可用、安全补丁和升级，你只需要管理工作节点。这极大地降低了运维复杂度，是快速上云的首选。
2. 自建集群：使用kubeadm、kubespray、Rancher等工具在自有基础设施（物理机、虚拟机）上部署。这需要你负责控制平面和所有节点的运维，包括etcd备份、证书轮换、版本升级等，技术挑战大，适合有深厚运维能力的团队或对数据主权有严格要求的场景。
3. 发行版与安装工具：
   • kubeadm：Kubernetes官方提供的集群引导工具，灵活但需要手动配置很多组件（网络、存储、Ingress等），适合学习和定制化高的场景。
   • Rancher：提供了极简的UI来部署和管理K8s集群（RKE或导入现有集群），内置了丰富的应用商店和运维工具，对初学者和中小团队非常友好。
   • Kubespray：基于Ansible，可以一键部署高可用的生产级集群，支持多种基础设施和插件。

8.2 生产环境核心组件与陷阱

网络插件（CNI）选择：K8s集群必须安装网络插件才能实现Pod间通信。常见的有Calico（性能好，网络策略强大）、Flannel（简单易用）、Cilium（基于eBPF，提供高级可观测性和安全能力）。选择需考虑网络性能、安全策略需求和对底层网络的兼容性。

镜像仓库：生产环境必须使用私有镜像仓库（如Harbor， AWS ECR， Google Container Registry）来存储和管理自定义镜像。需要配置K8s节点的镜像拉取密钥（imagePullSecrets）。

持久化存储：根据应用类型选择存储方案。有状态服务（数据库）通常需要块存储（如云盘），并通过StatefulSet配合PVC使用；文件共享场景可用NFS或CephFS。务必测试存储的备份、恢复和扩容流程。

Ingress Controller：生产环境必须部署。Nginx Ingress Controller是最流行的选择，功能成熟，文档丰富。需要为其配置一个公网负载均衡器（云厂商的LoadBalancer或自建HAProxy/Nginx）。

监控与日志：这是生产运维的“眼睛”。必须部署监控系统（如Prometheus + Grafana）来收集集群和应用的指标；部署日志收集系统（如EFK Stack: Elasticsearch, Fluentd, Kibana 或 Loki + Grafana）来集中管理日志。K8s自身的资源（CPU、内存）监控和Pod日志查看是远远不够的。

常见陷阱：

• 资源请求/限制配置不当：不设置或设置不合理会导致节点资源耗尽（OOM Kill）或应用饥饿。需要通过监控持续观察和调整。
• 就绪探针（Readiness Probe）缺失：应用启动慢或依赖外部服务，如果没有配置就绪探针，Service会在Pod启动后立即向其转发流量，导致请求失败。务必为所有服务配置合适的就绪探针。
• 滚动更新策略配置不当：Deployment的maxUnavailable和maxSurge参数控制着更新过程中不可用和额外创建的Pod数量。设置过于激进可能导致服务中断。
• 节点亲和性/反亲和性使用不足：未使用Pod反亲和性可能导致同一服务的所有副本都调度到同一个节点，该节点故障则服务全挂。未使用节点亲和性可能导致Pod被调度到没有GPU或特定存储类型的节点上。
• 忽视HPA（Horizontal Pod Autoscaler）：没有配置基于CPU/内存或自定义指标的自动扩缩容，在流量高峰时无法自动应对，低谷时又浪费资源。

从容器化到编排，从概念到生产，这条路上充满了细节和挑战。但正是Docker和Kubernetes这一对组合，定义了云原生时代应用构建、交付和运行的标准范式。理解它们的核心思想和基本组件，是驾驭现代基础设施的第一步。剩下的，就是在不断的实践、踩坑和总结中，积累属于你自己的“码头管理员”经验了。