Kubernetes概述

![image-20250927130827274](https://oss.maolin101.com/image-20250927130827274.png-101.webp)

## 概述

Kubernetes（简称 K8s）是目前全球最主流的容器编排平台，核心目标是实现容器化应用的自动化部署、弹性伸缩、故障自愈和跨环境管理。

起源于 Google 内部的 Borg 系统（一款运行了十余年的大规模集群管理工具），2014 年开源后由云原生计算基金会（CNCF）托管，现已成为云原生技术栈的 “操作系统”，支撑着从互联网巨头到中小企业的容器化业务。

其具有以下特点：

- 可移植：支持公有云、私有云、混合云、多重云。
- 可扩展：模块化、插件化、可挂载、可组合。
- 自动化：自动部署、自动重启、自动复制、自动扩缩容。

## 为什么需要 K8s？

当容器技术（如 Docker）解决了 “应用打包与环境一致性” 问题后，新的挑战随之而来：

- 如何管理成百上千个容器（如微服务拆分后的数十个服务）？
- 如何在容器故障时自动恢复？
- 如何根据流量自动增减容器数量（如电商大促扩容）？
- 如何实现容器间的网络通信与负载均衡？

Kubernetes 的出现正是为了回答这些问题 —— 它通过声明式配置和自动化控制，将容器的部署、扩展、网络、存储等复杂操作抽象为 “API 调用”，让开发者无需关注底层细节，专注业务逻辑。

## 发展历史

2004年，Borg系统诞生。Borg系是Google内部的一个大规模集群管理系统，它可以管理拥有数万台机器的大型集群，并在集群上运行数十万个作业。

2014年6月7日，Google推出了Borg的开源版本Kubernetes。

2015年7月21日，Kubernetes V1.0发布，与此同时，Google与Linux基金会组建了云原生计算基金会（CNCF）。

2016年，Kubernetes相继发布了1.2、1.3、1.4、1.5，进行性能和功能上的改进。期间推出了Kubernetes的软件包管理系统Helm，并在1.4推出了Kubeadm，用于提高Kubernetes的可安装性。

| 时间      | 关键事件 / 版本                 | 核心意义                                       |
| --------- | ------------------------------- | ---------------------------------------------- |
| 2014.06   | 首次公开，发布 0.1 版本         | 基于 Borg 思想的容器编排工具诞生               |
| 2015.07   | 1.0 版本发布                    | 进入生产可用阶段，奠定核心 API 规范            |
| 2015.12   | 成为 CNCF 首个托管项目          | 脱离 Google 单独运营，加速行业 adoption        |
| 2016.03   | 1.2 版本引入 Deployment         | 简化滚动更新与回滚，成为最常用的工作负载控制器 |
| 2018.03   | 成为 CNCF 首个毕业项目          | 技术成熟度获行业认可，确立事实标准地位         |
| 2019.08   | Docker 全面拥抱 K8s             | 容器编排战争结束，K8s 成为唯一主流标准         |
| 2020 至今 | Serverless / 边缘 / AI 场景扩展 | 从通用平台向垂直场景延伸，覆盖更广泛的业务需求 |

## 核心概念

Pod：Pod由一个或多个紧密相关的容器组合而成，是一个容器组。一般来说，同一个Pod中包含的容器都是紧耦合的关系，它们必须相互配合才能体现完整的功能。为了让这些容器更好的协作，一个Pod中的所有容器会共享同一个网络和存储。Pod是Kubernetes调度的最小单元。

Controller：Kubernetes通过Controller创建和管理Pod，包括在集群中部署Pod，副本管理，滚动升级等等。Controller还可以为Pod提供自愈能力，比如某一个Pod因意外挂掉了，Controller可以自动在集群中创建一个一模一样的Pod。

Label：Label即标签，其实就是一对key/value。标签可以被附加到各种资源对象上，比如Node、Pod、Service等等。标签通常在对象定义时添加，但也可以在创建后动态添加和修改。标签的key和value皆由用户指定，且对于用户来说是有意义的。之后，用户可以通过标签查找到特定分组的对象。

Service：Service是一种特殊的对象，它有自己的IP和端口，并与一组Pod相关联。Service 所关联的 Pod 集合通常由Label选择器确定。Service的IP并不会频繁改变，当我们想从外部访问这组Pod时，可以通过访问Service来实现。

Namespace：Namespace是将集群资源划分为不同用途的一种措施，它可以将一个集群划分为多个虚拟集群，虚拟集群之间互不干扰。

> Controller类别

Job：Job用于运行结束就删除的Pod。Job 创建一个或多个 Pod副本，并将持续重试 Pod 的执行，直到指定数量的 Pod 成功完成任务。当指定数量的Pod完成后，Job会删除所有Pod副本。

StatefulSet：StatefulSet用于管理有状态应用程序。StatefulSet为每个Pod副本维护一个永久性的标识符，并根据标识符保证Pod副本部署和扩展的顺序和唯一性。

Deployment：Deployment是最常用的一种Controller，它可以管理Pod的多个副本。通过Deployment我们可以设置Pod副本数量、配置更新方式，并且支持回滚。Deployment使用ReplicaSet管理多个副本。

DaemonSet：DaemonSet确保集群中的每一个节点都会运行一个Pod副本。DaemonSet通常用于运行守护进程。

## 架构

![image-20250927131923417](https://oss.maolin101.com/image-20250927131923417.png-101.webp)

Master：Master是集群的控制节点，负责对集群进行控制和管理。Master上运行着许多组件，主要包括四个，API Server、Controller Manager、Scheduler和etcd。

Node：Node是Kubernetes集群中真正的工作节点，是Pod运行的地方。Node中有两个主要的组件，kubelet和kube-proxy。

> Master运行的组件

![image-20250927132232505](https://oss.maolin101.com/image-20250927132232505.png-101.webp)

API Server：API Server负责处理API操作。API Server起到了交通枢纽的作用，Kubernetes的其他所有组件包括客户端在内都需要与API server进行连接，所有组件之间的消息传递都依赖API Server进行。

Controller Manager：Controller Manager负责集群资源管理，维护集群状态。Controller Manager由多种Controller组成，每种负责管理一种资源。

Scheduler：Scheduler是调度器，其负责为Pod选择合适的Node。Scheduler在调度Pod时会考虑多方面的需求，包括节点负载、性能、数据亲和性等等。

etcd：etcd是一个分布式的存储系统，用于保存整个集群的配置信息和状态信息。

> Node

![image-20250927132336996](https://oss.maolin101.com/image-20250927132336996.png-101.webp)

Kubelet：Kubelet相当于Master在Node节点上的代理人，负责对Master发来的消息进行真正的执行。kubelet实现了本节点上对Pod、容器、镜像等资源的管理，并监控容器运行情况反馈给Master。

Kube-proxy：Kube-proxy用于Pod的访问管理。Service是一组功能相同的Pod的抽象，当外界想访问这组Pod时，可以通过Service提供的统一入口进行访问。Kube-porxy用于Service功能的实现，它可以引导访问到Service，实现Service到Pod的路由和转发，以及实现负载均衡。

## 应用部署

在Kubernetes中进行资源的编排部署可以通过声明配置文件（YAML文件）来解决。

YAML文件中写明了资源部署时的所需参数，比如资源类型、资源的名字，资源规格等等。

![image-20250927132642671](https://oss.maolin101.com/image-20250927132642671.png-101.webp)

> 部署Deployment

Deployment是最常用的一种Controller，其主要用于部署无状态应用。

Deployment通过ReplicaSet管理Pod的多个副本。创建Deployment后，Deployment会自动创建一个ReplicaSet，再由ReplicaSet创建Pod。ReplicaSet只用于保证集群中Pod副本数量与期望数量保持一致，即提供Pod的自愈能力，而不会提供其他服务。

Deployment还可以实现应用的升级、扩缩容和回滚等操作。

```yaml
1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   creationTimestamp: null
5.   labels:
6.     app: mydeployment
7.   name: mydeployment
8. spec:
9.   replicas: 1
10.   selector:
11.     matchLabels:
12.       app: mydeployment
13.   template:
14.     metadata:
15.       creationTimestamp: null
16.       labels:
17.         app: mydeployment
18.     spec:
19.       containers:
20.       - image: nginx:1.16
21.         name: nginx

```

> 部署DaemonSet

DaemonSet保证集群中的每个Node节点上都会运行一个Pod副本。可以通过replicas指定Deployment中Pod的副本数，但DaemonSet不允许。DaemonSet中Pod的副本数量与Node节点的个数保持一致，并且每个Node运行一个Pod副本。如果一个新的Node节点加入了集群，马上便会运行一个新的Pod副本。

DaemonSet主要用于运行守护程序，比如运行集群监控程序、日志收集程序等等。

![image-20250927132845546](https://oss.maolin101.com/image-20250927132845546.png-101.webp)

> 部署Job

Job用于运行一次性任务。使用Deployment或DaemonSet创建的Pod会持续运行，除非运行出错或者用户进行手动删除。而使用Job创建的Pod会在任务结束后自动结束运行。Job常用于运行一些计算任务。

![image-20250927132947976](https://oss.maolin101.com/image-20250927132947976.png-101.webp)

## Service

在Kubernetes中应用的访问通过Service实现。Service的主要功能有两个，服务发现和负载均衡。

服务发现：Pod的生命周期是短暂的，扩缩容、滚动升级或故障重启等操作都会更改Pod的IP。如果直接使用Pod的IP访问Pod便很可能出现失联的情况。因此Kubernetes使用Service作为服务发现的中介，外界直接访问IP固定的Service，再由Service引导访问至指定的Pod。

负载均衡：一个Service通常与一组Pod相关联，这一组Pod的功能相同。当访问来临时，Service会尽可能平均地将访问流量分摊到所有Pod上。

![image-20250927133035634](https://oss.maolin101.com/image-20250927133035634.png-101.webp)

## Secret和ConfigNap

> Secret

Kubernetes部署的应用中可能会包含着一些敏感数据，比如说密码、令牌或密钥等等。如果将这样的敏感数据直接暴露在配置文件或者镜像当中，是非常不安全的。

因此Kubernetes使用Secret来存储这些敏感数据。在创建Secret时，Secret会将敏感数据以base64的方式加密，并保存加密后的结果。如果要使用这些数据，Pod会引用Secret，这便避免了将敏感数据直接暴露出来。

```yaml
1. apiVersion: v1
2. kind: Secret
3. metadata:
4.   name: mysecret
5. type: Opaque
6. data:
7.   username: YWRtaW4=
8.   password: MTExMTEx

```

> ConfigMap

Configmap与Secret十分相似，唯一的不同就是Configmap不会对存储的数据进行加密。Configmap主要用于保存配置文件。Configmap将环境配置信息和容器镜像解耦，便于应用配置的修改。

```yaml
1. apiVersion: v1
2. kind: ConfigMap
3. metadata:
4.   name: human-config
5. data:
6.   height: "175cm"
7.   first-name: "Tom"
8. 
9.   face.properties: |
10.     eye.color=black
11.     eye.size=large    
12.     nose.size=small

```

## HELM

![image-20250927133143328](https://oss.maolin101.com/image-20250927133143328.png-101.webp)

Helm是一个用于Kubernetes集群的软件包管理工具，类似于Linux中的apt或者yum。Helm可以帮助用户更加方便地部署和管理应用。

Helm可以将应用所使用的所有资源YAML文件打包成一个chart，并且可以将chart上传到仓库中。当需要部署应用时，只需要从仓库中拉取chart，再使用简单的命令便可以完成部署。Helm还支持对应用的一键升级、回滚和删除等。

Helm中有两个重要的概念，chart和release。

chart是一组YAML文件的集合，这些YAML文件定义的资源组合在一起便是一个完整的应用。可以将chart理解为一个软件安装包，方便在Kubernetes集群中安装应用。

release是使用chart在Kubernetes集群中安装的应用实例。一个chart可以被多次安装，每次安装都是一个release。

## 存储管理

![image-20250927133252859](https://oss.maolin101.com/image-20250927133252859.png-101.webp)

volume即存储卷，与Docker中的卷相同，Kubernetes卷同样用于数据存储。Kubernetes卷主要用于解决两个问题。

一个是防止数据丢失。容器中的数据在磁盘中是临时保存的，如果容器因崩溃而重启，容器中的数据便会丢失，卷可以独立于容器进行数据存储防止数据丢失。

二是Pod中容器的数据共享。卷可以被同时挂载到多个容器上，可以很好地解决容器间的数据共享问题。

Kubernetes中的卷可以分为临时卷和持久卷。临时卷的生命周期与Pod相同，当删除Pod时临时卷也会被删除。持久卷的生命周期可以比Pod更长，当Pod被删除时它依然存在。

> PV和PVC

![image-20250927133613184](https://oss.maolin101.com/image-20250927133613184.png-101.webp)

PV和PVC应用于持久卷的挂载。通过在配置文件中指定存储路径来对卷进行挂载非常不灵活而且耦合性高。PV和PVC提供了一种更加灵活并且松耦合的挂载方式。

PV（PersistentVolume）是集群中的一块存储空间，由管理员事先供应或者使用StorageClass动态供应。与普通持久卷一样，PV的生命周期独立于使用它的Pod。事实上，PV底部的存储细节就是使用持久卷实现的，它们被作为PV的插件使用。

PVC（PersistentVolumeClaim）表达的是用户对PV的调用请求。当用户需要使用PV时，可以创建PVC对PV进行申请，PVC会根据用户提供的规格参数（容量大小和访问模式）寻找并绑定合适的PV。

PV和PVC像是两个相互对应的接口，PV用于卷的一方，PVC用于使用卷的一方。用户通过PVC声明需要使用的卷的规格，PVC便会自动寻找合适的PV。通过这样的方式，Kubernetes为用户隐去了卷的实现细节，不管这个卷是通过NFS、FC、iSCSI还是其他方式实现，都不会影响用户的使用。

## 集群监控

要想保证集群的平稳运行，必须对集群进行有效的监控。集群监控的指标包括集群和Pod两方面的内容，集群方面包括节点资源利用率、节点数目、节点中运行的Pod等，Pod方面包括容器指标和应用程序等。Kubernetes支持多种监控方案，每种监控方案都各自的特点。

| 监控方案                             | 特点                                                         |
| ------------------------------------ | ------------------------------------------------------------ |
| Zabbix                               | 非常成熟的网络监控解决方案，大量定制工作、适用于大部分互联网公司 |
| open-falcon                          | 较年轻的监控系统，其将功能模块分解地非常细致，用户自定义插件，灵活性更高 |
| cAdvisor+Heapster+InfluxDB+Grafana   | 简单易用                                                     |
| cAdvisor/exporter+Prometheus+Grafana | 扩展性好                                                     |

## 日志

应用日志即在集群中运行的容器化应用产生的日志，其默认输出到stdout或stderr中。写入到stdout或stderr中的数据会被容器引擎捕获并以文件的形式保存下来。

如果删除Pod，Pod中所有容器的日志也会被删除，Kubernetes将日志存储在节点上，为了不会消耗掉节点上的所有空间，需要对日志进行轮转，每隔一段时间或者当日志文件过大时清理日志。

![image-20250927133736323](https://oss.maolin101.com/image-20250927133736323.png-101.webp)