1、Kubernetes简介

1.1 Kubernetes是什么

• 服务发现和负载均衡（Service discovery and load balancing）：通过 DNS 实现内部解析，Service 实现负载均衡，自动将流量分配到健康的 Pod 实例。

• 存储编排（Storage orchestration）：通过 plugin 的形式支持多种存储，如本地，NFS，ceph，公有云快存储等

• 自动发布与回滚（Automated rollouts and rollbacks）：通过匹配当前状态与目标状态一致，更新失败时可回滚

• 自动资源调度（Automatic bin packing）：可以设置 Pod 调度的所需（requests）资源和限制资源（limits）

• 自我修复（Self-healing）：内置的健康检查策略，自动发现和处理集群内的异常，更换，需重启的 Pod 节点

• 密钥和配置管理（Secret and configuration management）：敏感信息通过 Secret 存储，应用的配置文件通过 Configmap 存储，避免将配置文件固定在镜像中，增加容器编排的灵活性

• 批处理执行（Batch execution）：通过 Job 和 Cron Job 提供单次批处理任务和循环计划任务功能的实现

• 横向扩展功能（Horizontal scaling）：包含有 HPA 和AS，即应用的基于 CPU 利用率的弹性伸缩和基于平台级的弹性伸缩，如自动增加和删除 Node 节点。

相关容器编排引擎：

• Docker-Compose：Docker 原生提供的容器编排工具，只需要一个配置文件即可管理多个容器的启动，但是只适用于单机环境。

• Swarm：Docker 原生提供的容器化编排引擎，支持多节点的容器管理，弥补了 Docker-Compose 单节点的缺陷，随着 Docker 支持 Kubernetes 逐渐废弃。

• Mesos：结合 Marathon 提供容器调度编排的能力，还能提供其他 framwork 的调度。

• Kubernetes：已成为容器编排引擎的唯一标准，越来越多程序支持 Kubernetes。

1.2 Kubernetes的设计理念

1. 声明式 API (Declarative API):
• 你告诉 Kubernetes “期望的状态是什么”（What），而不是“如何达到这个状态”（How）。
• 例如你只需要告诉 Kubernetes 你“期望”的系统最终状态（例如，我需要运行3个Nginx实例），而不需要指定具体的操作步骤（例如，手动运行3条 docker run 命令）。Kubernetes 会不断地工作，确保现实与你的声明一致。

2. 控制器模式 (Controller Pattern / Reconciliation Loop):
• 控制器是 Kubernetes 的“自动化引擎”。
• 它们持续地观察系统的当前状态，并将其与期望状态进行比较。
• 如果发现差异（例如，只有一个 Pod 在运行，但你期望3个），控制器就会采取行动（例如，再创建两个 Pod），使当前状态无限接近期望状态。这个“观察-对比-行动”的循环就是调和循环。

3. 自愈能力 (Self-Healing):
• 这是声明式API和控制器模式带来的直接好处。如果一个 Pod 崩溃了，控制器（如 Deployment）会观察到当前状态（2个Pod）与期望状态（3个Pod）不符，并立即创建一个新的 Pod 来替换它，无需任何人工干预。

2、Kubernetes的核心概念

• Namespace：虚拟隔离机制，将资源对象划分为不同的逻辑组，为不同的团队、项目或环境（如开发、测试、生产）提供了独立的资源分组和隔离边界。Kubernetes 集群初始有两个命名空间，分别是默认命名空间 default 和系统命名空间 kube-system 。

• Node：运行容器应用（例如 Pod）的机器，可以是物理机也可以是虚拟机。每个 Node 都由 Master（控制平面）进行管理，一个 Kubernetes 集群通常至少有一个 Node。

• Pod：Kubernetes 中部署和管理应用的最小单元。一个 Pod 包含一个或多个应用容器，或者共享资源的容器（如网络、存储卷）。Pod 内的所有容器总是被调度到同一个节点上。Pod 是 ephemeral（短暂的），会被频繁地创建和销毁。

• Replication Controller（RC）：最早保证 Pod 按指定数量运行的副本控制器。当前运行的 Pod 数目少于指定的数目，RC 就会启动新的 Pod 副本；当前运行的 Pod 数目大于指定的数目，RC 就会杀死多余的 Pod 副本。因为 RC 无法与 Deployment 协同工作。它只是一个独立的、功能单一的副本控制器，目前基本废弃。

• ReplicaSet（RS）：RC 的升级版，支持功能更强的集合选择器。现代应用通常不直接创建 RS，通过创建 Deployment 来间接创建它。

• Deployment：管理无状态应用的控制器。Deployment 直接管理 ReplicaSet，而 ReplicaSet 又确保指定数量的 Pod 副本始终运行，实现了滚动更新、回滚、扩缩容等关键功能。

• StatefulSet：管理有状态应用的控制器，例如数据库、缓存等。为每个 Pod 提供稳定的标识符（有序的编号、稳定的网络标识、持久的存储）。Pod 的创建、扩缩容、更新都是有顺序的，保证了数据的可靠性。

• Service: 定义了一种访问一组 Pod 的稳定策略。 Pod 是动态创建和销毁的（IP会变），Service 提供了一个稳定的 IP 地址、DNS 名称和端口，作为一组提供相同服务的 Pod 的前端负载均衡器。服务发现和负载均衡主要通过 Service 实现。

• Ingress：为 Kubernetes 集群提供外部访问能力的对象。它提供了基于域名和路径的路由规则，可以将流量分发到不同的后端 Service。通常需要一个 Ingress Controller（如 Nginx Ingress Controller）来解析 Ingress 规则，Ingress Controller 根据这些规则将请求转发到对应的 Service。

• Volume：外部存储的抽象，为 Pod 提供数据的持久化存储。Pod 中的容器的文件是临时性的。当容器崩溃、重启或终止时，容器内部的文件系统会被清除，数据会丢失。Volume 允许数据在容器重启后依然存在。一个 Volume 可以被挂载到 Pod 中的一个或多个容器的指定路径上，支持各种类型的实际存储（如本地磁盘、云存储、NFS等）。

3、Kubernetes的核心组件

3.1 控制平面组件

• kube-apiserver：在整个集群的入口，暴露 Kubernetes API，接收集群所有的请求（如 kubectl 或 Dashboard 的请求）。

• kube-controller-scheduler：集群资源调度，通过 watch 监视 pod 的创建，负责将 pod 调度到合适的 node 节点。

• kube-controller-manager：运行多个控制器（Controller），确保集群状态符合预期。包含
• Node Controller：监控节点状态（如节点不可用时驱逐 Pod）。
• Replication Controller：确保副本数（如 Deployment 的 replicas）符合预期。
• Endpoints Controller：维护 Service 与 Pod 的映射关系。
• 其他：如 Namespace、ServiceAccount 控制器等。

• kube-scheduler：决定 Pod 应该运行在哪个节点上，调度策略基于资源需求（CPU/内存）、亲和性（Affinity）、污点（Taint）等。

• etcd：分布式键值存储数据库，保存集群的所有配置数据和状态（如 Pod、Service、Namespace 等）。

• cloud-controller-manager（可选）：用于公有云的接入实现，提供节点管理(node)、路由管理、服务管理(LoadBalancer和Ingress)、存储管理(Volume，如云盘，NAS接入)，需要由公有云厂商实现具体的细节。

3.2 Node组件

• kubelet：运行在 Node 节点上的守护进程，它的主要职责是确保该节点上的 Pod 按照 API Server 指定的状态正确运行。kubelet 负责接收来自 API Server 的指令，创建、监控和管理 Pod 及其容器，还负责卷管理、健康检查、生命周期管理以及与容器运行时（比如 Docker）进行交互以执行具体容器操作。简而言之，kubelet 是 Kubernetes 集群在每个节点上的“管家”，确保集群的实际状态符合期望状态。

• kube-proxy：提供网络代理和均衡负载的功能。Service 服务的抽象层，负责维护节点上的网络规则（如 iptables/IPVS），这些网络规则实现从集群内部或外部与 Pod 进行网络通信。

• Container Runtime：负责运行容器并管理容器的生命周期，容器运行时实现有 Docker、Containerd、CRI-O 以及 Kubernetes CRI 的其他任何实现。kubelet 通过 CRI（Container Runtime Interface）与容器运行时交互。

3.3 用户交互工具

• kubernetes-dashboard：Web UI 管理界面，需要另外部署。

• kubectl：命令行工具，用户可以通过它与 Kubernetes 集群进行交互，执行各种操作，例如部署应用、管理资源（如 Pods、Services、Deployments等）、查看集群状态以及调试问题等。它是与 API Server 通信的主要方式，允许用户控制和配置集群中的各个组件。

3.4 插件（Addons）

• DNS 服务：为集群内的 Service 和 Pod 提供 DNS 解析。常用组件是 CoreDNS。

• 网络插件 (CNI)：负责 Pod 的网络配置（IP 分配、路由设置等），常用组件：
• Calico：支持网络策略和高性能路由。
• Flannel：简单的 overlay 网络方案。
• Cilium：基于 eBPF，支持高级网络策略和可观测性。
• Weave Net：自动配置网络，适合小型集群。

• 存储插件（CSI）：用于动态提供持久化存储卷（PV）。常用组件：
• 公有云：AWS EBS CSI Driver、Google Persistent Disk CSI Driver、Azure Disk CSI Driver。
• 本地存储：Local Volume CSI Driver（用于本地磁盘）。
• 分布式存储：Ceph CSI、Rook（基于Ceph）、Longhorn。
• 网络存储：NFS CSI Driver、GlusterFS CSI。

• Ingress 控制器：管理集群外部访问（HTTP/HTTPS 路由）。常用组件：
• Nginx Ingress Controller：基于 Nginx 的流行方案。
• Traefik：支持动态配置的现代反向代理。
• HAProxy Ingress：高性能负载均衡器。

• 监控与日志插件：用于采集 Node 和 Pod 的监控数据。常用组件：
• metric-server：核心指标监控
• Prometheus + Grafana：监控指标收集与可视化。
• Elasticsearch + Fluentd + Kibana (EFK)：日志收集与分析。

• 服务网格（Server Mesh）：网络基础层，负责 Kubernetes 集群的底层网络通讯，实现应用和网络解耦，使开发人员更专注于业务本身。常用组件：
• Istio：流量管理、安全性和可观测性。
• Linkerd：轻量级服务网格。
• Consul：基于 HashiCorp Consul 的服务网格。

4、Kubernetes的整体架构

1. Kubernetes 由一个控制平面（Master 节点）和多个用于运行容器化应用的 Node（Worker 节点）组成。

2. Master 节点上运行着集群管理相关的一组进程（如 etcd、API Server、Controller Manager、Scheduler），这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。

3. Node 节点上运行 kubelet、kube-proxy、Container Runtime（例如 Docker、Containerd） 等组件，负责对本节点上的 Pod 的生命周期进行管理以及实现服务代理的功能，用户应用运行在 Node 节点上。

4. 用户通过 kubectl、dashboard 等工具与 Kubernetes 进行交互，向集群下达操作命令。

1. 通过 kubectl 向 kube-apiserver 提交一个 YAML 文件，声明你的期望状态（例如，一个 Deployment）。

2. API Server 将这份期望状态写入 etcd。

3. 相关的控制器（如 Deployment Controller）从 API Server 观察到这个新的期望状态。

4. 控制器开始工作，为了达到期望状态，它可能会创建新的资源（如 ReplicaSet）。

5. Scheduler 观察到有未调度的 Pod，根据规则调度它到一个合适的 Node 上。

6. 该 Node 上的 kubelet 通过 API Server 接收到 Pod 的定义，指挥容器运行时拉取镜像并启动容器。

7. 同时，kube-proxy 和 Ingress Controller 等组件会设置网络规则，让你的服务可以被访问。

8. 整个过程结束后，当前状态被更新到 etcd。

9. 控制器会持续不断地对比 etcd 中的期望状态和汇报上来的当前状态，确保它们一致。

5、Kubernetes的应用部署过程

5.1 创建命名空间

5.2 使用Deployment部署Pod

5.3 为服务创建Service

5.4 配置Ingress实现外部访问

6、常见问题

Pod 为什么是最小的部署单元，而不是直接管理容器

• 共享网络命名空间 (Network Namespace)：它们拥有同一个 IP 地址和端口空间。它们可以通过 localhost 直接通信，不会发生端口冲突。

• 共享存储卷 (Storage Volumes)：Pod 可以定义一组共享的存储卷（Volumes），这些卷可以被挂载到其中的多个容器中，从而实现数据共享。

• 共享生命周期：Pod 被创建、调度、销毁。Pod 是调度的单位，Kubernetes 的调度器（Scheduler）是以 Pod 为单位，而不是以单个容器为单位，将其整体调度到一个 Node 上。

• 主容器：运行应用程序的主要功能（例如，一个 Web 服务器）。

• 辅助容器（Sidecar）：增强或扩展主容器的功能，而不需要修改主容器的代码。例如日志收集、服务网格（如 Istio）等。

Deployment 和 ReplicaSet 的区别和联系

• 单独使用 ReplicaSet 的弊端：ReplicaSet 的作用是确保 Pod 副本按指定数量运行。如果直接操作 ReplicaSet，当 Pod 副本有更新时（例如使用新的容器镜像版本），只能先停止旧的 ReplicaSet，再创建新的 ReplicaSet，在新的 ReplicaSet 里面运行新的 Pod 副本，这样会导致服务中断，用户体验较差。

• 使用 Deployment 管理 ReplicaSet 的好处：如果使用 Deployment 创建并管理 ReplicaSet，当 Deployment 的 Pod 模板时，Deployment 会创建一个新的 ReplicaSet，然后逐步调整新旧两个 ReplicaSet 的副本数量，逐步用新版本的 Pod 替换旧版本的 Pod，实现了无中断的服务滚动更新。

• 滚动更新（Rolling Update）：最重要的功能。当你更新 Pod 模板（如镜像版本）时，Deployment 会创建一个新的 ReplicaSet，然后逐步增加新 ReplicaSet 的 Pod 数量，同时减少旧 ReplicaSet 的 Pod 数量，直到所有 Pod 都迁移到新版本。这个过程是零宕机的。

• 版本回滚（Rollback）：Kubernetes 默认保存更新历史（修订版本），如果新版本有问题，可以将 Deployment 回滚到之前的修订版本。Deployment 会再次操作 ReplicaSet，将 Pod 从新版切回旧版。

• 暂停与恢复（Pause/Resume）：可以暂停一个正在进行的滚动更新，检查新版本Pod没问题后，再继续更新。