20250707-3-Kubernetes 核心概念-有了Docker，为什么还用K8s_笔记

一、Kubernetes核心概念

1. 有了Docker，为什么还用Kubernetes

1）企业需求



• 
• 独立性问题：Docker容器本质上是独立存在的，多个容器跨主机提供服务时缺乏统一管理机制
• 负载均衡需求：为提高业务并发和高可用，企业会使用多台服务器部署多个容器实例，但Docker本身不具备负载均衡能力
• 管理复杂度：随着Docker主机和容器数量增加，面临部署、升级、监控等统一管理难题
• 运维效率：单机升级成本高，需要集中管理多节点容器升级流程
• 为提高业务并发和高可用，会使用多台服务器

  

  • 类比说明：类似传统网站集群架构，通过负载均衡器+多台WEB服务器解决并发和单点故障问题
  • 容器场景：需要在多台Docker服务器上部署相同应用的多个容器实例，但缺乏转发机制
• 多容器分布节点部署
   
  • 鸡蛋篮子理论：用50元买大量鸡蛋时，需要篮子/袋子才能有效运输，类比容器管理需要编排系统
  • 管理维度：包括部署效率、版本升级、负载均衡、高可用保障等多个运维层面
• 多容器怎么升级

  

  • 版本迭代问题：应用更新时需要批量升级分布在多节点的容器实例
  • 传统局限：单机升级方式在分布式环境下效率低下，成本高昂
• 高效管理这些容器

  

  • 规模挑战：容器数量超过数十个时，手工管理完全不现实
  • 生产需求：企业级环境需要自动化管理工具解决部署、监控、扩缩容等问题

2）容器编排系统



• 
• 技术演进：为满足容器管理需求，先后出现三种主流方案：
  • Swarm：Docker官方方案（2016年推出），优势是简单易用但功能薄弱，2018年已停止维护
  • Mesos Marathon：基于大数据调度系统Mesos的容器框架，非专为容器设计
  • Kubernetes：专为生产级容器管理设计，现已成为行业标准（99%企业采用）
• 市场现状：Kubernetes是唯一主流选择，支持管理上千节点（官方数据）
• 架构类比：类似虚拟化技术中的Hypervisor层，但实现机制完全不同

二、容器云平台架构

1. 层次结构



• 基础设施层：物理机/虚拟机、网络、存储等硬件资源
• 容器引擎层：Docker等运行时，作为"执行者"负责容器生命周期管理
• 编排层：Kubernetes抽象集群资源，提供部署、升级、负载均衡等核心功能
• 开发平台层：基于K8s构建的PaaS环境，供开发者使用
• 应用层：最终部署的业务应用

2. 各层角色



• 运维职责：主要维护平台建设和技术栈扩展，而非日常应用部署
• 开发者使用：开发人员通过平台完成应用部署、监控等全生命周期管理
• 规模说明：实际企业部署会考虑多机房、混合云等容灾方案，不将所有节点集中管理

三、知识小结

知识点	核心内容	考试重点/易混淆点	难度系数
Docker与Kubernetes的关系	Docker是单机容器引擎，Kubernetes是容器编排系统，用于管理多节点容器集群	Docker适合单机，Kubernetes适合集群	⭐⭐⭐
容器化部署的适用场景	无状态应用适合容器化，有状态应用（如MySQL集群、ETCD）需谨慎	有状态应用需熟悉容器运维	⭐⭐⭐⭐
Kubernetes集群管理能力	支持上千节点管理，提供负载均衡、部署升级、回滚等功能	集群规模与运维复杂度成正比	⭐⭐⭐⭐⭐
容器挂载目录权限问题	容器与宿主机用户体系隔离，需确保容器内用户对挂载目录有权限	Root用户默认可访问宿主机目录	⭐⭐
Docker安装与基础运维	Docker安装简单（yum install或二进制部署），Kubernetes需额外学习	Kubernetes学习曲线陡峭	⭐⭐
技术选型对比（Swarm/Mesos/K8s）	Swarm已淘汰，Mesos非容器原生，Kubernetes是行业标准	无备选方案	⭐⭐⭐
Kubernetes架构分层	基础设施层→容器引擎层→编排层→应用层→开发者平台	编排层实现核心管理功能	⭐⭐⭐⭐
运维人员与开发者的角色	运维搭建平台，开发者使用平台部署应用	开发者需掌握基础K8s知识	⭐⭐
学习路径建议	从Docker基础到K8s集群搭建，逐步掌握核心概念	避免因畏难情绪放弃学习	⭐⭐