刚哥带你参加国际顶级技术会议 - Kubecon西雅图2018 - Kubernetes设计原则
软件业有如时尚业,新产品,新技术,新概念层出不穷,作为码农,如果不了解业内最新的技术动向,往往会陷入闭门造车的困境。睁眼看世界对于我们的产品开发和设计都是非常有意的一件事情。但是如今,各种会议层出不穷,会议质量良莠不齐,或者很多我想参加的会议发生在离我十万八千里的美洲,欧洲,非洲,南极洲,作为码农的我们既没钱,又没时间去参加这些会议。不要担心,刚哥这里会找一些顶级会议的内容,分享给大家,能让大家坐在家里,也依然能够领略这些顶级会议的精彩内容。
今天我要带给大家的是2018年底,在西雅图举办的Kubecon的一场分享,来自谷歌K8s团队的工程师Saad Ali分享的《Kubernetes设计原则》。这场会议虽然已经过去一年了,但是我觉得本会议的内容非常值得学习,我们大都知道K8s是如何工作的,但是本文带我们了解k8s背后的设计原则,以及为什么要这样设计。以下是该分享的摘要:
Kubernetes设计原则:了解原因
Kubecon西雅图2018
对于跨云和本地环境在分布式系统上管理和部署工作负载,Kubernetes很快变得不可或缺。
虽然现在大多数人都熟悉如何使用Kubernetes,但很少有人知道其背后的“为什么”?为什么Kubernetes API看起来是这样的?为什么Kubernetes组件仅通过Kubernetes API相互交互?当您可以轻松地直接从pod引用卷时,为什么会有PersistentVolumeClaim对象?
为了回答这些问题并帮助您对Kubernetes进行更深入的了解,本讲座将揭示支撑Kubernetes设计的原理。
原则1. Kubernetes APIs 是声明性的而非命令性的
我们从最简单的一个例子开始,要如何在一台节点上启动需要运行的任务。
最简单的方式就是发送一个命令,启动容器。
但是这样做的话,如果容器,节点崩溃,或者节点临时不可访问的时候,用户就必须监控和存储每一个节点和容器的状态,捕获所有的异常,并做异常处理。也就是说把所有的复杂的异常处理的逻辑交给客户端来做。
这就引入了Kubernetes的第一个设计原则:
Kubernetes APIs 是声明性的而非命令性的 ( Kubernetes APIs are declarative rather then imperative )
命令式:
- 用户:提供一系列的指令来驱动系统达到制定状态。
- 系统:执行指令
- 用户:监控系统,根据系统状态,提供进一步的指令
声明式:
- 用户:定义期望的状态
- 系统:向着指定的状态工作
下图是一个声明式API的例子:
- 用户创建一个API对象
- 所用的组件并行工作来达到该状态。
声明式的API支持自动恢复。例如
- 节点B挂了
- 系统自主地把Pod移动到健康的节点A上
这里需要注意主节点只是存储了Pod的定义声明,而不会向节点B发送命令,如果那样做,主节点就会变得和我们之前提到的客户端一样,复杂而脆弱,且难以扩展。这就引入了K8s的第二个设计原则:
Kubernetes控制平面是透明的,没有隐藏的内部API ( The Kubernetes control plane is transparent. There are no hidden internal APIs. )
原则2. Kubernetes控制平面是透明的,没有隐藏的内部API
之前:
- 主节点:提供一系列的指令来驱动节点达到制定状态。
- 节点:执行主节点发来的指令
- 主节点:监控每一个节点,根据节点状态,提供进一步的指令
现在:
- 主节点:定义想要达到的状态
- 节点:独立工作以达到主节点定义的状态
我们来看一个Pod创建的例子:
如下图所示,所有的组件都监视Kubernetes API,然后决定自己应该怎么做。
用户调用API声明要创建的Pod
主节点创建Pod的定义
Scheduler通过API观察到Pod A的定义,通过调度运算,决定要在Node B上创建Pod A,并通过API更新主节点上的Pod A的定义。
Node B观察到Pod A的定义是在自己的管辖范围,启动Pod A
用户通过API删除 Pod A
节点B发现 Pod A被删除
节点B删除Pod A
这样做的能促成一个更简单,跟健壮的系统设计,并很容易从故障状态中恢复。系统没有单点故障,主节点的职责非常简单
这样做的另一个好处是,系统更容易扩展和组合。因为没有内部隐藏的API,用户可以很容易的用自定的组件替代已有组件,或者增加自定义的功能。
K8s还有很多对象对业务是很重要的,例如存储密码的密匙文件secret,配置configmap,或者下行API提供Pod的基本信息。那么应用程序必须修改为调用KubeAPI来或者这些信息么?
这就引入了Kubernetes的第三个设计原则
满足用户的需求 ( Meet the user where they are )
原则3. 满足用户的需求
之前:
- 应用程序必须被修改为知道K8s的存在,调用KubeAPI
现在:
- 应用程序可以从环境变量加载配置文件或者密匙文件,所以不需要修改
我们可以举一个例子,是关于远程存储的。
如上图所示,Pod可以直接引用一个远程的存储卷(GCE PD,AWS EBS,NFS等),kubernetes会自动使得该卷被用于Pod。但是这样做的话,有一个问题,如果你要迁移到一个新的基础架构上,那么它就不工作了。于是这就引入了kubernetes设计的第四个原则:
可移植的工作负载 ( Workload portability )
原则4. 可移植的工作负载
持久卷(PersistentVolumn,PV)和持久卷声明(PersistenVolumnClaim, PVC)就是这样一个例子。
如上图所示,通过PVC的抽象,用户Pod并不直接引用GCE PD或者EBS,这样就使得该Pod可以在不同的基础架构中互相迁移,做到可移植。就像操作系统一样,该设计使得系统应用和底层的硬件或者架构实现分离解耦。
总结
本文总结了Kubecon 2018的一场由谷歌高级软件工程师,kubernete开发人员Saad Ali分享的《Kubernetes设计原则》。其中的四个设计原则分别是:
- Kubernetes APIs 是声明性的而非命令性的
- Kubernetes控制平面是透明的,没有隐藏的内部API
- 满足用户的需求
- 可移植的工作负载
通过该分享,我们可以发现,K8s的背后设计原则的原因,其实它软件设计的一些一般性原则是一致的,虽然面向对象已经不在是什么流行的术语,但是本文中的设计原则和面向对象的设计原则高度一致。
- 对象要对自己负责。在设计对象的时候,对象应该尽可能的封装内部的状态,对自己负责,我们设计一辆可行驶的车。一种设计是两个对象,driver和car,然后diver.run(car)。而更好的设计是不需要driver,或者把dirver看成Car的一个属性,这样就是Car.run()。第二种设计更符合面向对象的设计原则。这正是声明式API背后的原则,组件对自己负责。
- Kube API类似对象的接口,对象对修改封闭,对扩展开放。通过开放的API,用户可以很容易的实现功能扩展,但是你无法修改已有的组件,你可以开发自定义的组件来替换已有的组件。
- 可移植性的设计类似面向对象的多态,定义抽象接口,隐藏具体的实现细节。
希望本文的分享能帮助你理解K8s背后的设计原则。如果你有什么好的顶级会议想要了解,欢迎联系我。
参考
- 该分享的视频,已添加中英文字幕
- Slides 2018-12-12_Kubernetes_Design_Principles__Understand_the_Why.pdf
- Slides Kubernetes_Design_Principles.pdf
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
阿里云新品发布会第36期 丨 移动开发平台mPaaS重磅发布
点击订阅新品发布会! 新产品、新版本、新技术、新功能、价格调整,评论在下方,下期更新!关注更多新品发布会! 新品发布会动态 移动开发平台mPaaS重磅发布 快速构建一款 App 并不难,但如何从容应对复杂机型及系统版本,构建快速迭代的端上架构,实现动态更新、稳定流畅的应用移动开发者的核心课题。围绕支付宝在移动端如何实现轻耦合、弹性动态的开发模式,深度解析其技术选型及实战经验。 直播时间:2020年1月15日 15:00 - 16:00 欢迎订阅 产品动态 新产品 : 智能用户增长 - 阿里云大数据产品 - Quick Audience(公测)发布 产品文档 Quick Audience以消费者为核心,通过丰富的用户洞察模型和便捷的策略配置,完成消费者多维洞察分析和多渠道触达,助力企业实现用户增长。产品共包含以下几大功能模块:数据源及数据集配置、洞察分析(透视分析、AIPL及其流转分析、RFM分析、受众分析)、受众圈选、受众管理。可帮助企业实现快速人群圈选以及多渠道触达,由其可将企业一方消费者人群推送至品牌数据银行侧,连同用户线上线下数据,全面提能提效消费者运营。 1) 高效模型创建:通...
- 下一篇
微服务业务日志收集方案
背景 日志内容复杂多样,如何去收集有价值的日志是我们重点关注的。日志的价值其实是取决于业务操作的,不同的业务场景下相同类型的日志的价值会截然不同。 根据以往的业务实践,结合企业级的一些业务需求,我们选定关注以下几类日志。 • 跟踪日志【trace.log】 Server引擎的调试日志,用于系统维护人员定位系统运行问题使用。 • 系统日志【system.log】 大粒度的引擎运行的入口、出口的日志,用于调用栈分析,可以进行性能分析使用。 • 部署日志【deploy.log】 记录系统启动、停止、构件包部署、集群通知等信息的日志。 • 引擎日志【engine.log】 细粒度的引擎运行日志,可以打印上下文数据,用于定位业务问题。 • 构件包日志【contribution.log】 构件包记录的业务日志(使用基础构件库的日志输出API写日志) 这里我们专门针对系统日志收集讨论几种收集方案 方案一:通过日志组件来收集 这里是指通过logback、log4j等日志组件来输出文件,然后再通过文件输出到logstash、kibana等日志组件中,通过这些日志组件来进行可视化统计与分析,这里需要统一关...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS6,CentOS7官方镜像安装Oracle11G