Kubernetes 核心认知与集群架构（从Docker过渡到K8s）

文章目录前言一、彻底厘清Docker Compose 为什么不能上生产1.1 Docker Compose 核心局限性1.2 企业技术分工必考认知二、K8s 是什么核心作用与企业价值2.1 什么是 Kubernetes2.2 K8s 专门解决的生产痛点2.3 Compose vs K8s 核心对比表三、K8s 整体集群架构通俗详解3.1 两大核心角色1、Master 节点控制平面2、Node 节点工作平面3.2 架构核心总结必背四、K8s 四大核心资源入门重中之重4.1 PodK8s 最小运行单元4.2 Deployment无状态服务部署控制器4.3 Service服务网络与负载均衡4.4 YAML资源声明式配置文件五、Docker 与 K8s 企业联动终极解答5.1 完整企业链路5.2 一句话总结六、总结前言通过前六篇 Docker 系列教程我们已经完整掌握了容器开发的全套基础能力Docker 镜像制作、容器运行、数据持久化、网络配置、Docker Compose 多容器编排、Harbor 私有镜像仓库搭建与镜像管理。到这里很多同学会产生一个疑问既然 Docker Compose 已经能一键启动多容器、统一管理开发环境为什么企业生产环境还要用复杂的 K8s这也是新手学习容器技术最大的误区混淆「开发环境」和「生产环境」的技术选型。我们前面学的 Docker Compose Harbor完全适配本地开发、单机测试场景但完全无法应对企业线上生产的核心需求高可用、容灾自愈、弹性扩容、集群调度、滚动更新、灰度发布。所以容器技术的学习必须完成最后一块核心拼图Kubernetes简称 K8s。本篇作为 K8s 入门第一篇带你彻底搞懂 K8s 核心价值、技术定位、集群架构、核心概念清晰区分 Docker Compose 与 K8s 的企业分工为后续 K8s 实操、企业 CI/CD 自动化部署打下坚实基础。一、彻底厘清Docker Compose 为什么不能上生产先明确核心结论Docker Compose 只适合单机开发/测试绝对不适合生产环境。我们结合企业真实生产场景拆解 Compose 的致命短板这也是 K8s 存在的核心意义。1.1 Docker Compose 核心局限性仅限单机运行Compose 所有服务只能运行在一台服务器上无法搭建集群服务器宕机则整套服务全部瘫痪无任何容灾能力。无自愈能力容器崩溃后Compose 仅能通过 restart 策略重启容器无法自动调度、迁移服务也无法补偿实例。无弹性扩容业务流量暴涨时无法自动新增容器实例分担压力只能手动修改配置重启服务。发布风险极高更新服务只能停止重建存在服务中断时间不支持滚动更新、灰度发布无法满足线上 7*24 小时不间断服务需求。无资源调度能力无法监控服务器 CPU、内存资源不能合理分配容器运行节点极易出现资源闲置或过载问题。1.2 企业技术分工必考认知至此我们可以敲定企业容器技术标准分工体系适配 99% 互联网公司本地开发环境Docker Docker Compose轻量、快速、简单高效镜像存储管理Docker Harbor统一打包、私有存储、版本管控线上生产环境K8s 集群编排高可用、自愈、扩容、不停机发布二、K8s 是什么核心作用与企业价值2.1 什么是 KubernetesKubernetes 是 Google 基于 Borg 系统开源的容器集群编排管理平台是目前容器 orchestration编排领域的行业标准、事实王者。通俗大白话解释Docker 负责把应用打包成镜像、运行单个容器K8s 负责管理成千上万台服务器上的成千上万个 Docker 容器。2.2 K8s 专门解决的生产痛点所有功能都是为生产高可用、高并发、高稳定量身打造故障自愈容器崩溃、节点宕机自动重启、自动迁移服务业务无感知弹性扩缩容流量高峰期自动增加容器实例低峰期自动缩减节省服务器资源不停机发布支持滚动更新、灰度发布、版本回滚线上服务零中断更新集群调度自动监控集群资源智能将容器调度到资源充足的服务器负载均衡内置集群负载均衡自动分发流量到多个服务实例2.3 Compose vs K8s 核心对比表对比维度Docker ComposeKubernetes运行架构单机架构分布式集群架构适用环境开发、测试、单机小项目企业生产、大规模集群自愈能力弱仅支持容器重启强节点/容器故障自动迁移恢复扩容能力手动扩容无自动机制支持自动弹性扩缩容发布方式停机更新有服务中断滚动更新零停机发布运维难度极低开箱即用较高功能强大、配置规范三、K8s 整体集群架构通俗详解K8s 是典型的主从架构Master Node整个集群分为控制平面和工作节点两大部分新手无需死记硬背理解分工即可。3.1 两大核心角色1、Master 节点控制平面集群的「大脑」不运行业务容器只负责管理、调度、管控整个集群统一指挥所有工作节点。Master 包含 4 个核心组件kube-apiserver集群统一入口所有操作命令创建、删除、更新服务都通过它接收处理是 K8s 的网关kube-controller-manager控制器管理器负责监控集群状态实现故障自愈、实例数量维持kube-scheduler调度器负责将新的容器任务智能分配到资源充足的 Node 节点etcd集群数据库存储集群所有配置、状态数据是 K8s 的核心存储2、Node 节点工作平面集群的「干活小弟」真正运行业务容器所有项目服务、中间件容器都运行在 Node 节点上。每个 Node 节点都包含 3 个必备组件kubelet节点代理接收 Master 指令管理当前节点的所有 Pod容器组kube-proxy网络代理负责节点网络转发、负载均衡实现服务互通、外网访问container runtime默认 Docker负责真正拉取镜像、启动、停止容器核心这就是 Docker 和 K8s 的联动点3.2 架构核心总结必背Master管调度、管管理、不管业务Node跑业务、跑容器、接受 Master 管理DockerK8s 的容器运行底层依赖负责容器生命周期四、K8s 四大核心资源入门重中之重K8s 所有操作都是围绕「资源对象」实现新手先吃透 4 个最核心、最常用的资源覆盖 95% 日常开发部署场景。4.1 PodK8s 最小运行单元Pod 是 K8s 中最小、最基本的部署单元。通俗理解一个 Pod 可以包含一个或多个 Docker 容器K8s 不直接管理容器只管理 Pod同一 Pod 内的容器共享网络、存储本地互通企业规范一个 Pod 只跑一个业务容器结构清晰、方便运维。4.2 Deployment无状态服务部署控制器Pod 本身是临时性、易销毁的单独创建的 Pod 崩溃后不会自动恢复。Deployment 是用来管理 Pod 的控制器企业 99% 的业务服务都通过它部署。核心能力指定 Pod 运行副本数保证服务实例数量稳定Pod 崩溃、节点宕机自动重建 Pod实现自愈支持滚动更新、版本回滚、扩容缩容4.3 Service服务网络与负载均衡每个 Pod 的 IP 是动态变化的重启后 IP 会改变无法直接对外提供稳定访问。Service 的作用就是给一组 Pod 提供固定访问入口 负载均衡。无论后端 Pod 如何重启、迁移、扩容访问地址永远不变彻底解决动态 IP 失联问题。4.4 YAML资源声明式配置文件和 Docker Compose 一致K8s 所有资源创建、配置全部通过 YAML 文件声明。优势配置标准化、可版本控制、可复用、团队统一适配自动化部署。五、Docker 与 K8s 企业联动终极解答这里解答所有开发者的终极疑惑有了 K8sDocker 是不是没用了答案完全不是二者是上下级、互补关系不是替代关系。5.1 完整企业链路Docker负责底层应用打包将 Java/Go/Vue 代码打包成标准镜像是容器的载体Harbor负责存储 Docker 镜像统一版本管理、权限管控K8s负责拉取 Harbor 镜像调度、运行、维护容器保障线上高可用5.2 一句话总结Docker 负责造容器、跑容器K8s 负责管容器、管集群、管服务稳定性。六、总结1、Docker Compose 仅限单机开发测试使用因无集群、自愈、扩容、零停机发布能力无法用于企业生产环境2、K8s 是企业生产级容器编排标准核心解决集群高可用、故障自愈、弹性扩缩容、不停机发布等线上核心问题3、K8s 采用 MasterNode 主从架构Master 管控集群Node 运行业务容器Docker 作为底层运行时支撑 K8s 容器启动4、K8s 入门核心四要素Pod、Deployment、Service、YAML是后续所有实操的基础5、企业标准技术栈Docker 打包 Harbor 存镜像 K8s 跑生产三者缺一不可。