一、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集群搭建,逐步掌握核心概念 |
避免因畏难情绪放弃学习 |
⭐⭐ |