目录
- “Kubernetes”这个名字来自希腊语，意思是“舵手”
- 舵手是一个航海/航行术语，指掌舵的人
- 从本质上说，Kubernetes是云原生微服务(cloud-native microservice)应用的编排器(orchestrator)
何为微服务
- 在过去，开发人员构建和部署的是单体应用
- 单体应用中每个功能都被捆绑在一起作为单个大的包
- 如图所示：
- Web前端、认证、日志生成、数据存储、报告系统等被紧密地耦合在一起，捆绑成一个应用
- 这意味着，如果想改变某个部分，必须改变每一部分
- 举个简单的例子，如果需要修补或更新上图中的应用的报告功能，必须关闭整个应用并修补/更新整个应用
- 像这样的工作需要详尽的计划，面临巨大的风险且十分复杂
- 但是，单体应用带来的痛苦还不止于此
- 如果想对它们的某个功能进行扩缩容，不得不对整个单体应用扩缩容
- 基本上，应用的每个功能都被作为一个单体的单元捆绑、部署、升级和扩缩容，这是很笨拙的，显然不是很理想
- 另外，微服务应用采用完全相同的一组功能——Web前端、认证、日志生成、数据存储、报告系统等
- 并将每个功能拆分为自己的小应用
- “小”的另一个词是“微”，“应用”的另一个词是“服务”
- 这就是“微服务”这个术语的由来
- 如果仔细观察下图你会发现，它就是和上图完全相同的一组应用功能
- 不同的是，每个功能都是独立开发、独立部署的，并且可以独立更新和扩缩容
- 但它们依然协同工作，创造与单体应用完全相同的应用体验
- 最常见的模式是每个微服务都作为独立的容器来开发和部署
- 例如，Web前端微服务会是一个容器，认证微服务会是另一个不同的容器，报告系统微服务又会再是不同的容器
- 以此类推
- 每个微服务都是独立的，但又是通过网络松散耦合的，以创建相同的应用体验
- 通过设计让微服务之间是松散耦合的，这是修改一个微服务而不影响其他微服务的基础
- 从技术上讲，每个微服务都通过IP网络暴露一个API，让其他微服务能够通过这个API来使用它
- 如果不熟悉API这个概念，下面这个类比对你可能会有所帮助
- 汽车的外形和大小各异，它们配置的可能是直列四缸、水平对卧六缸、八缸的发动机，甚至可能是电动发动机
- 但是，所有这些复杂的细节都通过使用标准化控制器---方向盘、加速器、刹车踏板和车速表对驾驶员隐藏了
- 在这个模型中，控制器相当于汽车的API---驾驶员通过它们来使用汽车的功能
- 这种模型的一个主要优点是，学会驾驶后就能驾驶任何一款汽车
- 例如，我学开车时用的是一辆前轮驱动的汽车，它配置的是四缸汽油发动机
- 但我无须学习任何新的驾驶技能就能开全轮驱动的电动汽车
- 这就是因为标准化的方向盘和脚踏板(API)将发动机和传动系统的复杂细节隐藏起来了
- 同样，更换汽车的发动机、替换其方向盘和轮胎、升级其排气系统后，驾驶员依然能够驾驶它，而无须学习任何新的驾驶技能
- 回到正题---微服务应用
- 只要没有修改微服务的API，就可以在其他微服务和应用用户不会注意到的情况下对微服务进行修补或更新
- 除了让微服务能够独立地更新和扩缩容，微服务设计模式还让开发团队更小、更敏捷，能够更快地迭代功能
- 一般来说，与大团队相比，2～8人团队的沟通和合作的职场政治因素会更少，也会更敏捷
- 微服务设计模式还有其他优点---将功能开发成独立的微服务，可以在不影响应用任何部件的情况下对它们进行开发、部署、更新、扩缩容等
- 但是，微服务并不完美
- 如果有很多由不同团队管理的移动部件，微服务可能会变得很复杂
- 最后，这两种设计应用的方式——单体与微服务---被称为设计模式
- 微服务设计模式是当前云时代最常见的模式
何为云原生
- 一个云原生应用必须能够：
- 按需扩缩容
- 自我修复
- 支持滚动更新
- 可以在任何有Kubernetes的地方运行
- 让我们花点时间来定义其中一些流行术语的含义
- 按需扩缩容是指应用和相关基础设施为了满足当前需求的自动增长和收缩的能力
- 例如，在线零售应用可能需要在特殊的假期增加基础设施和应用资源，然后在假期结束时缩小规模
- 如果配置正确，Kubernetes可以在需求增加时自动对应用和基础设施进行扩容，也可以在需求下降时对它们进行缩容
- 这不仅有助于企业对突发变化做出更快速的反应，还能在缩容时帮助其降低基础设施的成本
- Kubernetes还可以自我修复应用和单个微服务，这需要更多关于Kubernetes的知识，将会在后面介绍
- 但现在要知道的是，当用户把一个应用部署到Kubernetes时，用户告诉Kubernetes这个应用应该是什么样子
- 例如，每个微服务有多少个实例，应该连接到哪些网络
- Kubernetes将其保存为期望状态(desired state)，并监视应用，以确保它始终与期望状态匹配
- 如果有什么变化，例如，某个微服务崩溃，Kubernetes会注意到这一点，并启动一个副本作为替代，这就是所谓的自我修复或弹性
- 滚动更新是一种在不让应用离线甚至客户不会注意到的情况下更新应用的某些部分的能力
- 它改变了现代商业世界的游戏规则，稍后我们就可以看到它的实际效果
- 关于云原生还有最后一点要讲
- 云原生几乎是与公有云无关的，它是一组我们讨论过的功能和能力
- 因此，云原生应用可以在任何有Kubernetes的地方运行，如AWS、Azure、Linode、本地数据中心或者家中的树莓派集群
- 总之，云原生应用是具有弹性的、可以自动扩缩容的，并且可以在不停机的情况下进行更新
- 它们还可以在任何拥有Kubernetes的地方甚至是内部环境运行
何为编排器
- 借助一个类比可以更好地解释编排器这个概念
- 一个管弦乐队由一群演奏不同乐器的音乐家组成
- 每位音乐家都可以用不同的乐器，在演奏开始后发挥着不同的作用
- 乐器包括小提琴、大提琴、竖琴、双簧管、长笛、单簧管、小号、长号、鼓，甚至三角琴
- 每一个音乐家在管弦乐队中扮演着不同的角色
- 如下图所示，每位乐器都是独立的个体，还没有被指定扮演什么样的角色——这简直是一团糟，鼓甚至是上下颠倒的
- 一位指挥家拿着乐谱和指挥棒走过来，维持秩序
- 她把弦乐器都安排到舞台前面，木管乐器安排在中间，铜管乐器安排在后面一点儿，打击乐器安排在后面高一些的地方
- 她还指挥一切，告诉每组乐器什么时候演奏、演奏多大声以及以什么速度演奏
- 简而言之，指挥家将上图中的混乱情况变成如下图所示那样井井有条，以确保音乐按照作曲家的意图演奏
- 云原生微服务应用就像管弦乐队
- 每个云原生应用都是由很多小的微服务组成的
- 它们各司其职：有的服务于Web请求，有的用于认证会话，有的进行日志记录，有的用于持久化数据，还有一些生成报告
- 但就像一个管弦乐队一样，它们需要有人或某种东西将它们组织成一个有用的应用
- 由此，我们真正走进Kubernetes世界
- Kubernetes将独立的微服务组织成一个有意义的应用，如下图所示
- 如前所述，它可以对应用进行扩缩容、自我修复和更新等操作
- 总之，像Kubernetes这样的编排器将不同的微服务组合在一起，并将它们组织成一个有用的应用
- 它还提供并管理云原生功能，如扩缩容、自我修复和更新
