一、kubernetes简介
1.1、kubernetes是什么
Kubernetes（简称 K8s）是 Google 开源、CNCF 维护的容器编排平台 ，核心是自动化容器化应用的部署、扩缩、自愈与运维，解决大规模容器 "难管、难扩、易挂" 的痛点Kubernetes。
**Kubernetes最主要的设计思想是：**从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的任务留足余地。
**Kubernetes所擅长的：**是按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。这种功能，就是我们经常听到的一个概念：编排。
**Kubernetes的本质：**是为用户提供一个具有普遍意义的容器编排工具。
| kubernetes内容 | 说明 |
|---|---|
| 容器 | 把应用 + 依赖打包，轻量、可移植、环境一致（解决 "在我电脑能跑" 问题）。 |
| k8s | 管理成百上千容器的 "智能运维大脑"，负责调度、容错、弹性、发布，让容器像一个整体高效运转。 |
| 核心架构 | * Cluster（集群）：由控制平面（管理节点）和多个 Node（工作节点，物理机 / 虚拟机）组成。 * Pod：最小部署单元，含 1 个或多个共享网络 / 存储的容器。 * Service ：给 Pod 提供稳定 IP/DNS，实现服务发现 + 负载均衡。 * Deployment：定义应用期望状态（如 "跑 3 个 Pod"），负责滚动更新、回滚、扩缩容。 |
1.2、kubernetes有啥用
| kubernetes核心能力 | 说明 |
|---|---|
| ✅ 自愈能力（永不宕机） | 容器崩溃→自动重启；节点故障→Pod 漂移到其他节点；健康检查异常→自动替换，保障服务高可用Kubernetes。 |
| 📈 弹性伸缩（降本增效） | 按 CPU / 内存 / 自定义指标（如 QPS）自动扩缩 Pod；流量高峰（如电商大促）秒级扩容，低谷缩容节省资源。 |
| 🚀 滚动更新与一键回滚 | 升级时逐步替换旧 Pod，零停机发布；出问题一键回滚到历史版本，降低发布风险。 |
| 🔍 服务发现与负载均衡 | 自动分配 Pod IP + 集群 DNS，Service 做负载均衡，无需改代码即可实现服务互访与流量分发。 |
| ☁️ 跨环境一致(一次打包，到处运行) | 支持本地、自建机房、公有云、混合云，配置统一，应用可无缝迁移，避免厂商锁定。 |
| 🔐 配置与密钥管理 | ConfigMap 存配置、Secret 存密码 / 密钥，无需重新打包镜像即可更新配置，敏感信息不泄露Kubernetes |
1.3、Kubernetes的应用场景
| Kubernetes的应用场景 | 说明 |
|---|---|
| 微服务架构（互联网 / 电商） | 拆分为独立微服务（订单 / 支付 / 商品），K8s 管理服务生命周期、通信、治理；案例 ：淘宝、京东、微博，支撑大促百万级 QPS。 |
| CI/CD 自动化交付（研发效能） | 与 Jenkins/GitLab CI/Argo CD 集成，代码提交→自动构建镜像→部署到 K8s，全流程自动化，迭代周期从 "周" 缩到 "天 / 小时"。 |
| AI / 机器学习（算力调度） | 管理 TensorFlow/PyTorch 模型训练与推理，GPU 共享调度 、弹性扩缩；案例：AI 推荐、自动驾驶、NLP 服务。 |
| 大数据与实时计算（数据处理） | 运行 Spark/Flink/Hadoop，弹性集群、动态资源调度，应对海量数据实时分析（如用户行为、风控）。 |
| 混合云 / 多云（企业 IT） | 统一管理阿里云 / 华为云 / 自建机房，应用跨云迁移与灾备，避免单一云厂商绑定。 |
| 边缘计算（IoT / 工业） | 在工厂 / 基站 / 终端设备部署轻量 K8s（如 K3s），管理边缘应用，低时延处理数据，云端统一管控。 |
| 游戏与直播（高并发） | 游戏服 / 直播推流服务弹性扩缩，灰度发布、多版本共存，应对突发流量（如新区开服、热点直播）。 |
总结：K8s 是云原生时代的 "操作系统" ：帮你自动化管容器、稳运行、快迭代、省成本 ，是微服务、AI、大数据、混合云的核心底座。
1.4、Kubernetes的优缺点
✅ 适合：微服务、中大型项目、高并发、需要频繁发版、需要弹性扩容、团队有运维 / 云原生人员。
❌ 不适合：个人小项目、单体简单应用、小团队没人懂 K8s、业务量常年固定没波动。
| kubernetes的优点 | kubernetes的缺点 |
|---|---|
| 《1》自动化能力拉满 自动部署、自动重启故障容器、节点挂了自动迁移 Pod，自愈强，减少人工运维熬夜救火。 | 《1》学习成本极高、概念多又抽象 Pod/Deployment/Service/Ingress/ConfigMap/Namespace 一堆概念，新手入门很吃力。 |
| 《2》弹性伸缩，省钱又抗高并发 支持按 CPU / 内存 / QPS 自动扩缩容，大促扩容、低谷缩容，不用常年堆服务器资源。 | 《2》架构复杂、维护门槛高 组件多（kube-apiserver、etcd、scheduler、控制器），集群搭建、调优、排障都需要专业人员，小团队 hold 不住。 |
| 《3》零停机发布、支持灰度 / 回滚 滚动更新、金丝雀发布、一键回滚，升级不宕机，发版风险极低。 | 《3》资源开销大 控制平面、各类组件、监控日志插件本身要占用不少服务器资源，小业务用有点 "杀鸡用牛刀"。 |
| 《4》微服务标配，服务治理完善 自带服务发现、负载均衡、DNS、配置管理、密钥管理，天然适配微服务架构。 | 《4》故障排查难度大 网络问题、调度问题、镜像问题、权限问题错综复杂，出问题不容易定位。 |
| 《5》跨环境、跨云统一 本地、私有机房、阿里云 / 华为云都能跑，一次打包到处运行，迁移方便，不被云厂商绑定。 | 《5》网络方案复杂 需要额外装 CNI 网络插件（Calico/Flannel 等），网络策略、跨节点通信配置容易踩坑。 |
| 《6》生态极其丰富 监控 (Prometheus)、日志 (ELK)、网关 (Istio/Ingress)、CI/CD、AI、大数据全都有，云原生事实标准。 | 《6》版本迭代快、兼容性坑多 K8s 版本更新快，插件、工具经常版本不兼容，升级集群有风险。 |
| 《7》资源利用率高 容器轻量化，K8s 自动调度把服务器资源榨干用好，比传统虚拟机更省机器。 | 《7》不适合超小型简单应用 就一个单体小项目、没并发、不用扩容，上 K8s 反而增加复杂度和维护成本。 |
二、kubernetes的重要概念
| 序号 | k8s的重要概念 | 说明 |
|---|---|---|
| 1 | Cluster | Cluster是计算、存储和网络资源的集合，k8s利用这些资源运行各种基于容器的应用。 |
| 2 | Master | Master是cluster的大脑，他的主要职责是调度，即决定将应用放在那里运行。master运行linux操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个master。 |
| 3 | Node | Node的职责是运行容器应用。node由master管理，node负责监控并汇报容器的状态，同时根据master的要求管理容器的生命周期。node运行在linux的操作系统上，可以是物理机或者是虚拟机。 |
| 4 | pod | pod是k8s的最小工作单元。每个pod可以包含一个或者多个容器。pod中的容器会作为一个整体被master调度到一个node上运行。 Pod有两种使用方式，运行单一容器和运行多个容器， 运行单一容器是Kubernetes 最常见的模型，即便是只有一个容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。而pod中运行多个容器的话，哪些容器应该放到一个Pod中？答案是：这些容器联系必须非常紧密，而且需要直接共享资源。 |
| 5 | controller | k8s不会直接创建pod,而是通过controller来管理pod的。controller中定义了pod的部署特性，比如有几个副本，在什么样的node上运行等。为了满足不同的业务场景，k8s提供了多种controller，包括Replication Controller（RC）、Replica Set （RS）、 Deployment 、daemonset、statefulset、job等。 RC是K8s集群中最早的保证Pod高可用的API对象，通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。 RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型。比如提供高可用的Web服务。 |
| 6 | Replica Set(RS) | RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。RS对象一般不单独使用，而是作为Deployment的理想状态参数使用。 使用deployment时会自动创建Replica Set ，也就是说deployment是通过Replica Set来管理pod的多个副本的，我们通常不需要直接使用Replica Set 。 |
| 7 | deployment(部署) | Deployment表示用户对K8s集群的一次更新操作，它是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。 |
| 8 | daemonset（后台支撑型服务） | 长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持K8s集群运行的服务。 |
| 9 | statefuleset | 能够保证pod的每个副本在整个生命周期中名称是不变的，而其他controller不提供这个功能。当某个pod发生故障需要删除并重新启动时，pod的名称不会发生变化，同时statefulset会保证副本按照固定的顺序启动、更新或者删除。 |
| 10 | job | 用于运行结束就删除的应用，而其他controller中的pod通常是长期持续运行的。 |
| 11 | service | deployment可以部署多个副本，每个pod 都有自己的IP，外界如何访问这些副本那？答案是service。 k8s的 service定义了外界访问一组特定pod的方式。service有自己的IP和端口，service为pod提供了负载均衡。 k8s运行容器pod与访问容器这两项任务分别由controller和service执行。 |
| 12 | namespace | 可以将一个物理的cluster逻辑上划分成多个虚拟cluster，每个cluster就是一个namespace。不同的namespace里的资源是完全隔离的。Kubernetes 默认创建了两个 Namespace。 default -- 创建资源时如果不指定，将被放到这个 Namespace 中。 kube-system ：Kubernetes 自己创建的系统资源将放到这个 Namespace 中。 |
三、kubernetes的架构解析
k8s的集群由master和node组成，节点上运行着若干k8s服务：
3.1、k8s中master的组成
master节点之上运行着的后台服务有【kube-apiserver】【kube-scheduler】【kube-controller-manager】【Etcd】【pod网络（ flannel ）】：
| k8s中master的后台服务 | 说明 |
|---|---|
| API Server (kube-apiserver) | API Server是k8s的前端接口，各种客户端工具以及k8s其他组件可以通过它管理集群的各种资源。 |
| Scheduler (kube-scheduler) | scheduler负责决定将pod放在哪个node上运行。另外scheduler在调度时会充分考虑集群的架构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。 |
| Controller Manager (kube-controller-manager) | 负责维护集群的状态（如故障检测、自动扩展、滚动更新等）。Controller Manager 由多种 controller 组成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。 不同的 controller 管理不同的资源（如：replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源）。 |
| etcd | 负责保存k8s集群的配置信息和各种资源的状态信息，K8S中所有的服务节点的信息数据、配置数据都是存储在ETCD中，当数据发生变化时，etcd会快速的通知k8s相关组件。 |
| pod网络（ flannel ） | pod要能够相互通信，k8s集群必须掌握pod网络， flannel是其中一个可选的方案。 |
3.2、k8s中node的组成
node节点上运行着的后台服务有【kubelet】【kube-proxy】【pod网络(flannel)】：
| k8s中node的后台服务 | 说明 |
|---|---|
| kubelet | 是node的agent，当scheduler去确定在某个node上运行pod后，会将pod的具体配置信息发送给该节点的kubelet，kubelet会根据这些信息创建和运行容器，并向master报告运行状态。 |
| kube-proxy | service 在逻辑上代表了后端的多个 Pod，外界通过 service 访问 Pod。service 接收到的请求是如何转发到 Pod 的呢？这就是 kube-proxy 要完成的工作。proxy是配合service实现从pod到service， 以及从外部的node port 到 service的访问。 每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。 |
| pod网络 | pod能能够互相通信，k8s集群必须部署pod网络，flannel是其中一个可以选择的方案 |
3.3、k8s的整体功能
3.4、k8s的整体运行架构
