新書推薦：
《
微观经济学（第三版）【2024诺贝尔经济学奖获奖者作品】
》
售價：HK$
159.9
《
Python贝叶斯深度学习
》
售價：HK$
91.8
《
文本的密码：社会语境中的宋代文学
》
售價：HK$
69.0
《
启微·狂骉年代：西洋赛马在中国
》
售價：HK$
80.5
《
有趣的中国古建筑
》
售價：HK$
68.8
《
十一年夏至
》
售價：HK$
78.2
《
如何打造成功的商业赛事
》
售價：HK$
91.9
《
万千教育学前·透视学前儿童的发展：解析幼儿教师常问的那些问题
》
售價：HK$
59.8
|
| 編輯推薦： |
本书是容器圈Kubernetes重磅开山作《Kubernetes权威指南》的纪念版，内容更新到Kubernetes
v1.6 版本。
本书作者全部来自惠普公司云计算实战一线，敏锐地捕获和探索着各种IT前瞻技术，有着全面而扎实的技术架构体系、对创新技术天生的热情、国际技术领先者的视野，还有着对企业级IT架构的深入把握。
纪念并不是为了结束，而是为了新的写作思路的展开。我们用尽全力更新和修改本书的内容，把能想到的和K8s新的更新都详细地写进去了，致使本书厚达700页，同时，我们深感不能再接着更新下去了。还好，本书记录了K8s近的很重要的里程碑版本，之后的各种版本变化应该都是基于这个版本的小范围内的更新，本书应该还能陪伴大家很长一段时间。
奉上寄语：我轻轻地招手，迎接明天的云彩
|
| 內容簡介： |
Kubernetes 是由谷歌开源的Docker
容器集群管理系统，为容器化的应用提供了资源调度、部署运行、服务发现、扩容及缩容等一整套功能。《Kubernetes 权威指南：从Docker
到Kubernetes 实践全接触（纪念版）》从架构师、开发人员和运维人员的角度，阐述了Kubernetes
的基本概念、实践指南、核心原理、开发指导、运维指南及源码分析等内容，图文并茂、内容丰富、由浅入深、讲解全面；围绕着生产环境中可能出现的问题，给出了大量的典型案例，比如安全配置、网络方案、共享存储方案、高可用性方案及Trouble
Shooting
技巧等，有很强的实战指导意义。《Kubernetes权威指南：从Docker到Kubernetes实践全接触（纪念版）》随着Kubernetes
版本更新不断完善，目前涵盖了Kubernetes 从v1.0 到v1.6 版本的全部特性，尽力为Kubernetes
用户提供全方位的指南。
无论是对于软件工程师、测试工程师、运维工程师、软件架构师、技术经理，还是对于资深 IT
人士来说，《Kubernetes权威指南：从Docker到Kubernetes实践全接触（纪念版）》都极具参考价值。
|
| 關於作者： |
龚正，HPE高级顾问
拥有十多年的IT从业经验，具备丰富的云计算、大数据分析和大型企业级应用的架构设计和实施经验，是电信、金融、互联网等领域的资深专家。
吴治辉，HPE资深架构师
拥有超过15年的软件研发经验，专注于电信软件和云计算方面的软件研发，拥有丰富的大型项目架构设计经验，是业界少有的具备很强Coding能力的S级资深架构师，也是《ZeroC Ice木权指南》《架构解密：从分布式到微服务》的作者。
王伟，HPE资深系统架构师、大数据和云计算技术专家 龚正，HPE高级顾问
拥有十多年的IT从业经验，具备丰富的云计算、大数据分析和大型企业级应用的架构设计和实施经验，是电信、金融、互联网等领域的资深专家。
吴治辉，HPE资深架构师
拥有超过15年的软件研发经验，专注于电信软件和云计算方面的软件研发，拥有丰富的大型项目架构设计经验，是业界少有的具备很强Coding能力的S级资深架构师，也是《ZeroC
Ice木权指南》《架构解密：从分布式到微服务》的作者。
王伟，HPE资深系统架构师、大数据和云计算技术专家
拥有多年IT行业从业经验，参与过多个大型应用的架构设计、系统开发和实施落地，精通大数据、云计算及大型系统架构和开发的相关技术，对互联网和电信行业的热点技术有着深刻的理解，是云计算和大数据方面的技术专家。
崔秀龙，HPE资深架构师
开源软件、自动化爱好者，拥有十多年从业经验，对软件生命周期的各个环节均有深刻的理解。
闫健勇，HPE高级项目经理、总架构师
拥有超过15年的电信行业系统建设经验，主导了多项电信大型系统的架构设计和管理，对于云计算和大数据在电信行业中的应用拥有丰富的经验。
崔晓宁，HPE高级顾问
拥有超过7年的测试咨询和质量管理经验，在云计算、大数据和分布式运算架构下的业务质量控制方面有非常丰富的项目实践和心得，并对推动组织架构优化有丰富的经验。帮助多个超过百人的大型项目建立软件产品管理规范和体系，并对其运营提供指导。
刘晓红，HPE高级咨询顾问
拥有超过10年的电信行业从业经验，亲历中国移动BSSOSS领域核心系统的建设发展历程，具备丰富的咨询规划、需求分析、产品设计、项目管理、测试管理经验，专注于云计算、大数据等前沿技术的研究。
|
| 目錄：
|
第1章Kubernetes入门1
1.1Kubernetes是什么1
1.2为什么要用Kubernetes4
1.3从一个简单的例子开始5
1.3.1环境准备6
1.3.2启动MySQL服务6
1.3.3启动Tomcat应用9
1.3.4通过浏览器访问网页10
1.4Kubernetes基本概念和术语12
1.4.1Master12
1.4.2Node12
1.4.3Pod15
1.4.4Label（标签）18
1.4.5Replication Controller22
1.4.6Deployment26
1.4.7Horizontal Pod Autoscaler28
1.4.8StatefulSet29
1.4.9Service（服务）30
1.4.10Volume（存储卷）37
1.4.11Persistent Volume41
1.4.12Namespace（命名空间）42
1.4.13Annotation（注解）43
1.4.14小结44
第2章Kubernetes实践指南45
2.1Kubernetes安装与配置45
2.1.1系统要求45
2.1.2使用kubeadm工具快速安装Kubernetes集群46
2.1.3以二进制文件方式安装Kubernetes集群51
2.1.4Kubernetes集群的安全设置59
2.1.5Kubernetes集群的网络配置64
2.1.6内网中的Kubernetes相关配置64
2.1.7Kubernetes的版本升级65
2.1.8Kubernetes核心服务配置详解66
2.2kubectl命令行工具用法详解86
2.2.1kubectl用法概述86
2.2.2kubectl子命令详解88
2.2.3kubectl参数列表90
2.2.4kubectl输出格式90
2.2.5kubectl操作示例92
2.3深入掌握Pod93
2.3.1Pod定义详解93
2.3.2Pod的基本用法98
2.3.3静态Pod103
2.3.4Pod容器共享Volume104
2.3.5Pod的配置管理106
2.3.6在容器内获取Pod信息（Downward API）119
2.3.7Pod生命周期和重启策略124
2.3.8Pod健康检查125
2.3.9玩转Pod调度127
2.3.10Init Container（初始化容器）149
2.3.11Pod的升级和回滚152
2.3.12Pod的扩容和缩容166
2.3.13使用StatefulSet搭建MongoDB集群171
2.4深入掌握Service180
2.4.1Service定义详解181
2.4.2Service基本用法182
2.4.3Headless Service187
2.4.4集群外部访问Pod或Service192
2.4.5DNS服务搭建指南196
2.4.6自定义DNS和上游DNS服务器204
2.4.7Ingress：HTTP 7层路由机制208
第3章Kubernetes核心原理226
3.1Kubernetes API Server 原理分析226
3.1.1Kubernetes API Server概述226
3.1.2独特的Kubernetes Proxy API接口229
3.1.3集群功能模块之间的通信230
3.2Controller Manager 原理分析231
3.2.1Replication Controller232
3.2.2Node Controller234
3.2.3ResourceQuota Controller235
3.2.4Namespace Controller237
3.2.5Service Controller与Endpoint Controller237
3.3Scheduler原理分析238
3.4kubelet运行机制分析242
3.4.1节点管理242
3.4.2Pod管理243
3.4.3容器健康检查244
3.4.4cAdvisor资源监控245
3.5kube-proxy 运行机制分析247
3.6深入分析集群安全机制251
3.6.1API Server认证管理（Authentication）251
3.6.2API Server授权管理（Authorization）253
3.6.3Admission Control（准入控制）272
3.6.4Service Account274
3.6.5Secret私密凭据279
3.7网络原理282
3.7.1Kubernetes网络模型282
3.7.2Docker的网络基础284
3.7.3Docker的网络实现296
3.7.4Kubernetes的网络实现304
3.7.5Pod和Service网络实战308
3.7.6CNI网络模型321
3.7.7Kubernetes网络策略331
3.7.8开源的网络组件333
3.8共享存储原理363
3.8.1共享存储机制概述363
3.8.2PV详解364
3.8.3PVC详解368
3.8.4PV和PVC的生命周期370
3.8.5StorageClass详解373
3.8.6动态存储管理实战：GlusterFS376
第4章Kubernetes开发指南388
4.1REST简述388
4.2Kubernetes API详解390
4.2.1Kubernetes API概述390
4.2.2API版本395
4.2.3API Groups（API组）395
4.2.4API方法说明397
4.2.5API响应说明398
4.3使用Java程序访问Kubernetes API400
4.3.1Jersey401
4.3.2Fabric8412
4.3.3使用说明413
第5章Kubernetes运维指南434
5.1Kubernetes集群管理指南434
5.1.1Node的管理434
5.1.2更新资源对象的Label436
5.1.3Namespace：集群环境共享与隔离437
5.1.4Kubernetes资源管理441
5.1.5资源紧缺时的Pod驱逐机制475
5.1.6Pod Disruption Budget（主动驱逐保护）483
5.1.7Kubernetes集群的高可用部署方案485
5.1.8Kubernetes集群监控496
5.1.9集群统一日志管理513
5.1.10Kubernetes审计日志（Audit Log）522
5.1.11使用Web UI（Dashboard）管理集群523
5.1.12Helm：Kubernetes应用包管理工具527
5.2Trouble Shooting指导538
5.2.1查看系统Event事件538
5.2.2查看容器日志540
5.2.3查看Kubernetes服务日志541
5.2.4常见问题542
5.2.5寻求帮助546
5.3Kubernetes开发中的新功能546
5.3.1Pod Preset（运行时参数注入策略）546
5.3.2Cluster Federation（集群联邦）553
5.3.3容器运行时接口（Container Runtime Interface-CRI）557
5.3.4对GPU的支持561
5.3.5Kubernetes的演进路线（Roadmap）和开发模式565
第6章Kubernetes源码导读568
6.1Kubernetes源码结构和编译步骤568
6.2kube-apiserver进程源码分析572
6.2.1进程启动过程572
6.2.2关键代码分析574
6.2.3设计总结589
6.3kube-controller-manager进程源码分析592
6.3.1进程启动过程592
6.3.2关键代码分析595
6.3.3设计总结603
6.4kube-scheduler进程源码分析605
6.4.1进程启动过程605
6.4.2关键代码分析610
6.4.3设计总结617
6.5kubelet进程源码分析619
6.5.1进程启动过程619
6.5.2关键代码分析624
6.5.3设计总结647
6.6kube-proxy进程源码分析648
6.6.1进程启动过程648
6.6.2关键代码分析650
6.6.3设计总结665
6.7kubectl进程源码分析666
6.7.1kubectl create命令667
6.7.2rolling-update命令671
|
| 內容試閱：
|
我不知道你是如何获得这本书的，可能是在百度头条、网络广告、朋友圈中听说本书后购买的，也可能是某一天逛书店时，这本书恰好神奇地出现在你面前的书架上，让你想起一千多年前那个意外得到《太公兵法》的传奇少年，你觉得这是冥冥之中上天的恩赐，于是果断带走。不管怎样，我相信多年以后，这本书仍然值得你回忆。
Kubernetes这个名字起源于古希腊，是舵手的意思，所以它的Logo既像一张渔网，又像一个罗盘。谷歌采用这个名字的一层深意就是：既然Docker把自己定位为驮着集装箱在大海上自在遨游的鲸鱼，那么谷歌就要以Kubernetes掌舵大航海时代的话语木又，捕获和指引这条鲸鱼按照主人设定的路线巡游，确保谷歌倾力打造的新一代容器世界的宏伟蓝图顺利实现。
虽然Kubernetes自诞生至今才1年多，其第一个正式版本Kubernetes
1.0于2015年7月才发布，完全是个新生事物，但其影响力巨大，已经吸引了包括IBM、惠普、微软、红帽、Intel、VMware、CoreOS、Docker、Mesosphere、Mirantis等在内的众多业界巨头纷纷加入。红帽这个软件虚拟化领域的领导者之一，在容器技术方面已经完全跟从谷歌了，不仅把自家的第三代OpenShift产品的架构底层换成了Docker Kubernetes，还直接在其新一代容器操作系统Atomic内原生集成了Kubernetes。
Kubernetes是第一个将一切以服务（Service）为中心，一切围绕服务运转作为指导思想的创新型产品，它的功能和架构设计自始至终地遵循了这一指导思想，构建在Kubernetes上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也可以被托管在公有云中。Kubernetes方案的另一个亮点是自动化，在Kubernetes的解决方案中，一个服务可以自我扩展、自我诊断，并且容易升级，在收到服务扩容的请求后，Kubernetes会触发调度流程，最终在选定的目标节点上启动相应数量的服务实例副本，这些副本在启动成功后会自动加入负载均衡器中并生效，整个过程无须额外的人工操作。另外，Kubernetes会定时巡查每个服务的所有实例的可用性，确保服务实例的数量始终保持为预期的数量，当它发现某个实例不可用时，会自动重启该实例或者在其他节点重新调度、运行一个新实例，这样，一个复杂的过程无须人工干预即可全部自动化完成。试想一下，如果一个包括几十个节点且运行着几万个容器的复杂系统，其负载均衡、故障检测和故障修复等都需要人工介入进行处理，那将是多么的难以想象。
通常我们会把Kubernetes看作Docker的上层架构，就好像Java与J2EE的关系一样：J2EE是以Java为基础的企业级软件架构，而Kubernetes则以Docker为基础打造了一个云计算时代的全新分布式系统架构。但Kubernetes与Docker之间还存在着更为复杂的关系，从表面上看，似乎Kubernetes离不开Docker，但实际上在Kubernetes的架构里，Docker只是其目前支持的两种底层容器技术之一，另一个容器技术则是Rocket，后者来源于CoreOS这个Docker昔日的恋人所推出的竞争产品。
Kubernetes同时支持这两种互相竞争的容器技术，这是有深刻的历史原因的。快速发展的Docker打败了谷歌曾经名噪一时的开源容器技术lmctfy，并迅速风靡世界。但是，作为一个已经对全球IT公司产生重要影响的技术，Docker背后的容器标准的制定注定不可能被任何一个公司私有控制，于是就有了后来引发危机的CoreOS与Docker分手事件，其导火索是CoreOS撇开了Docker，推出了与Docker相对抗的开源容器项目Rocket，并动员一些知名IT公司成立委员会来试图主导容器技术的标准化，该分手事件愈演愈烈，最终导致CoreOS傍上谷歌一起宣布叛逃Docker阵营，共同发起了基于CoreOS Rocket Kubernetes的新项目Tectonic。这让当时的Docker阵营和Docker粉丝们无比担心Docker的命运，不管最终鹿死谁手，容器技术分裂态势的加剧对所有牵涉其中的人来说都没有好处，于是Linux基金会出面调和矛盾，双方都退让一步，最终的结果是Linux基金会于2015年6月宣布成立开放容器技术项目（Open
Container
Project），谷歌、CoreOS及Docker都加入了OCP项目。但通过查看OCP项目的成员名单，你会发现Docker在这个名单中只能算一个小角色了。OCP的成立最终结束了这场让无数人揪心的战争，Docker公司被迫放弃了自己的独家控制木又。作为回报，Docker的容器格式被OCP采纳为新标准的基础，并且由Docker负责起草OCP草案规范的初稿文档，当然这个标准起草者的角色也不是那么容易担当的，Docker要提交自己的容器执行引擎的源码作为OCP项目的启动资源。
事到如今，我们再来回顾当初CoreOS与谷歌的叛逃事件，从表面上看，谷歌貌似是被诱拐出柜的，但局里人都明白，谷歌才是这一系列事件背后的主谋，其不仅为当年失败的lmctfy报了一箭之仇，还重新掌控了容器技术的未来。容器标准之战大捷之后，谷歌进一步扩大了联盟并提高了自身影响力。2015年7月，谷歌正式宣布加入OpenStack阵营，其目标是确保
Linux
容器及关联的容器管理技术Kubernetes能够被OpenStack生态圈所容纳，并且成为OpenStack平台上与KVM虚拟机一样的一等公民。谷歌加入OpenStack意味着对数据中心控制平面的争夺已经结束，以容器为代表的应用形态与以虚拟化为代表的系统形态将会完美融合于OpenStack之上，并与软件定义网络和软件定义存储一起统治下一代数据中心。
谷歌凭借着几十年大规模容器使用的丰富经验，步步为营，先是祭出Kubernetes这个神器，然后又掌控了容器技术的制定标准，最后又入驻OpenStack阵营全力将Kubernetes扶上位，谷歌这个IT界的领导者和创新者再次王者归来。我们都明白，在IT世界里只有那些被大公司掌控和推广的，同时被业界众多巨头都认可和支持的新技术才能生存和壮大下去。Kubernetes就是当今IT界里符合要求且为数不多的热门技术之一，它的影响力可能长达十年，所以，我们每个IT人都有理由重视这门新技术。
谁能比别人领先一步掌握新技术，谁就在竞争中赢得了先机。惠普中国电信解决方案领域的资深专家团一起分工协作，并行研究，废寝忘食地合力撰写，完成了这部近700页的Kubernetes木又威指南。经过两年的高速发展，Kubernetes先后发布了v1.0～v1.6这6个大版本，每个版本都带来了大量的新特性，能够处理的应用场景也越来越丰富。本书遵循从入门到精通的学习路线，全书共分为六大章节，涵盖了入门、实践指南、架构原理、开发指南、高级案例、运维指南和源码分析等内容，内容详实、图文并茂，几乎囊括了Kubernetes到v1.6版本的方方面面，无论是对于软件工程师、测试工程师、运维工程师、软件架构师、技术经理，还是对于资深IT人士来说，本书都极具参考价值。
吴治辉
惠普公司系统架构师
5.3.2 Cluster Federation（集群联邦）
集群联邦从Kubernetes
v1.3版本开始引入，目标是对多个Kubernetes集群进行统一管理，将用户的应用部署到全球各地的不同数据中心或者云环境中，同时通过动态优化部署来节约运营成本。本节介绍Kubernetes中Federation（集群联邦）的主要特性和使用Federation管理多集群的原理。
1.
Federation的主要特性
Federation主要通过以下特性来实现多集群的统一管理。
◎
跨群集资源同步：Federation提供在多个集群之间保持资源同步的能力，比如通过Federation可以确保跨集群的Deployment在多个集群中始终同时存在并保持一致。
◎
跨集群服务发现：Federation提供了自动配置DNS服务器和全局负载均衡器（可访问所有Kubernetes集群后端服务的负载均衡器）的能力，比如通过Federation可以确保使用一条全局虚拟IP（VIP）或DNS记录即可访问部署在多个Kubernetes集群中的后端服务。
◎
高可用性：Kubernetes
Federation可以在集群之间分发负载，并且支持自动配置DNS服务器和全局负载均衡器，大大降低了发生系统故障的几率，提高了系统的可用性。
◎
避免厂商锁定：Federation使得应用进行跨不同类型的云平台联合部署变得很容易，而集群中应用程序的迁移也变得更加轻松，因此可以有效地避免出现厂商锁定的情况。
2.
Federation要解决的主要挑战
在Federation的实际使用场景中，会面对一些非常重要的挑战。
1）位置亲和性
在使用多集群部署分布式应用时，前端应用与后端资源（可以Pod形式的应用、存储或者其他为前端应用提供服务的资源）的相对位置对于访问延迟、资源开销和系统稳定性具有决定性的影响。那么Federation中应该如何考虑这种位置亲和决策呢？在Federation的设计理念中，针对前后端的相对位置，将前后端关系分为三类：严格耦合、严格解耦和优先耦合。三者分别对应前后端必须绑定、可以完全分离及优先绑定这三种应用场景。通过位置亲和性，就可以将严格解耦的应用进行基于Pod的平均分配或者随机分配，对优先耦合的应用进行优先分配到同一集群并接受部分移动，而对于严格耦合的应用则严格分配到同一集群环境中。
2）跨集群服务发现
在Federation中Pod使用外部DNS客户端来实现与单集群类似的标准服务发现。DNS将服务解析为本地集群地址或者外部集群地址。除严格耦合的前后端场景外，前端都可以不用关心DNS解析的结果是位于同一集群内还是同一集群外。
3）跨集群应用调度
Federation的跨集群调度机制中，Federation控制平面在接收到所有集群的资源对象创建请求后，可以简单地将这个请求重定向给某个集群，也可以将请求分解为多个子请求发送给不同的集群。同时，Federation控制平面需要分析应用的属性（位置亲和性、隐私级别等），并以此作为依据执行更优化的跨集群调度。此外，完善的跨集群调度机制还需要支持准入控制机制、自动扩容和缩容机制、故障重调度机制及基于计算能力的调度优化等。
4）跨集群应用迁移
在Federation的使用过程中，可能会遇到部分集群容量将满、转换云供应商、变换核心集群位置等需要进行应用迁移的场景。在这种情况下，Federation的跨集群迁移工作是按照应用位置亲和性来分别进行的：对严格解耦的应用采取一次或多次分步迁移的方式进行，每次迁移的粒度也很自由；对优先耦合的应用，需要首先找到具有足够多的资源容量可以容纳待迁移应用的目标集群，并锁定该部分的资源容量，之后按照特定的顺序在特定的时间内完成迁移工作；而对于严格耦合的程序而言，除了需要符合与优先耦合类似的资源要求，在迁移过程中还需要考虑是否能满足数据一致性和应用一致性的要求，如果不能满足要求，则不建议直接进行迁移。
5）故障隔离
Federation保留了Kubernetes集群的应用隔离机制，一般情况下并不会显著地增加多个集群之间故障的关联性。Federation控制平面与每个Kubernetes集群的控制平面是严格独立的，Federation控制平面的故障应不影响每个Kubernetes自身的正常运行。
◎
统一监控、统一预警和跨集群联合审计。
◎ 统一认证授木又、跨集群的配额管理。
3.
Federation的架构设计
针对这些调整，Federation的整体架构设计采用了解耦和分层的思路：Federation控制平面位于所有Kubernetes集群之上，而每个Kubernetes集群都是可以独立运行的。除了部分基础配置信息，每个Kubernetes集群都不知道其他Kubernetes集群的存在，也不知道Federation控制平面的存在。在这种设计中，Federation控制平面就像每个Kubernetes集群的API客户端，因此与每个集群解除了耦合关系。与Federation解耦和分层的架构相对的是一体式架构设计：即为每个Kubernetes集群搭建一个控制平面，这个控制平面只负责管理这个Kubernetes集群，而多个控制平面之间通过通信的方式来实现对所有Kubernetes集群的联合管理。
Federation分层解耦的设计具有如下优势。
1）故障隔离性好
如前面所述，Federation分层解耦的设计保证了Federation控制平面与集群的隔离，每个集群和Federation控制平面都可以独立运行，出现故障时可以进行单独隔离而互不影响。另外，每个集群和Federation控制平台的软件和配置都可以进行独立更新，这为系统的维护提供了极大的便利。
2）失效几率更低
整体而言，分层设计的系统比一体式设计的系统出现故障的概率要高（概率叠加），但由于各系统解除了耦合，所以系统完全失效的几率要低于一体式设计的系统。
3）可扩展性高
在Federation的分层解耦设计中，每个底层的Kubernetes集群内部都可以完全独立地进行扩展，而Federation中也可以很容易扩展加入新的集群而不影响现有集群。基于分层架构的优势，在未来的Kubernetes版本里，甚至可能会提供集群联邦的联邦功能（Federation
of
Federation）。
4）代码模块化和分离
Federation控制平面的代码与每个云供应商的Kubernetes控制平面的代码是分离的，它们之间通过共享库的方式来实现部分代码共享。这种设计允许Kubernetes和Federation的代码开发工作在很大程度上独立进行，同时促进了更好的代码模块化和独立的接口设计。
5）更灵活的管理策略
一体式设计的系统看似管理工作更简单，但是由于不同的云供应商和本地数据中心有不同的特点（硬件、定价、限制等），而Federation的分层解耦架构允许独立地管理每个Kubernetes集群，这虽然看似提高了管理的复杂性，但是对于整个系统而言，提供了更丰富的控制手段和管理策略。
◎
更好的代码模块化和界面设计。
◎
控制平面的成本更低。
在一体式设计的系统中，每个Kubernetes集群均需要部署自己的控制平面，而在分层解耦的设计中，Federation的控制平面只需要独立部署一次。如果我们需要实现控制平面的高可用，那么也只需要再部署一个Federation控制平面。可见Federation的分层设计在控制平面的成本开销上的优势非常明显。
4.
Federation的优势
Federation是Kubernetes多集群的解决方案，如果不需要使用多个Kubernetes集群，则Federation并没有太大用处。在下列情况下，可以考虑引入Federation。
◎
低延迟：通过多地区部署服务，配合就近选择集群提供服务的方式，Federation可以最小化服务访问的延迟。
◎
故障隔离：当系统发生故障时，由多个小型集群（这些集群通常分布在不同的区域）组成的Federation比单个大型集群更适合快速有效地隔离，而且对整体服务的影响会更小。
◎
可扩展性：根据谷歌的经验，在超大规模的生产环境中，单个Kubernetes集群的扩展性受到集群规模的制约。当单个集群规模过大时，集群性能下降。而多集群Federation则可以提高集群规模的上限，提供更好的可扩展性。
◎
混合云：Federation支持私有云和公有云的组合，可以使用Federation在不同的云供应商或多个本地数据中心上搭建多个Kubernetes集群，实现混合云部署。
5.
Federation的局限性
除了上述优势，在使用Federation之前也应充分考虑一些潜在问题。
◎
网络带宽和成本的增加：为确保所有的集群运行状态符合预期，Federation控制平面会持续监控所有集群。如果Federation中的集群运行在同一个云供应商的不同地区上（一般同一云供应商跨地区的网络通信是需要收费的）或者运行在不同的云供应商上，那么将会导致显著的网络开销和成本的提升。
◎
削弱了多集群之间的隔离性：Federation控制平面一旦出现问题，就可能会影响到所有的集群。一种可能的方案是，通过尽可能减少Federation控制平面中的逻辑，将Federation控制平面的逻辑尽可能多地传递给各Kubernetes子集群的控制平面，来减缓这种情况。但这类问题很难完全避免。同样，目前Federation这种中心控制的设计思路和实现方式还可能导致安全性及多集群同时不可用方面的问题。
◎
成熟度：相对而言，Federation出现较晚，还不是很成熟。目前Kubernetes中的资源对象只有一部分在Federation中是可用的，而且很多可用的资源对象目前还只是Alpha状态。此外，Federation的设计、实现和用法目前随着Kubernetes大版本的变更都发生了很多改变，因此给使用者带来了不少困难。
5.3.3
容器运行时接口（Container Runtime Interface-CRI）
归根结底，Kubernetes
Node（kubelet）的主要功能就是启动和停止容器的组件，我们称之为容器运行时（Container
Runtime），其中最知名的就是Docker了。为了让Kubernetes更具扩展性，从其v1.5版本开始加入了容器运行时插件API，我们称之为Container
Runtime Interface，简称CRI。
1.
CRI概述
每种容器运行时都有其特点，因此不少用户希望Kubernetes能够支持更多的运行时。Kubernetes从v1.5版本开始引入了CRI接口规范，通过插件接口模式，让Kubernetes无须重新编译就可以使用更多的容器运行时。CRI包含Protocol
Buffers、gRPC API、运行库支持及开发中的标准规范和工具。Docker-CRI的实现在Kubernetes
v1.6版本时更新为Beta版本，并在kubelet启动时默认启动。
可替代的容器运行时支持是Kubernetes中的新概念。在Kubernetes
v1.3发布时，rktnetes项目同时发布，让rkt容器引擎成为除Docker外的又一选择。然而，不管是Docker还是rkt，都用到了kubelet的内部接口，同kubelet源码纠缠不清。这种程度的集成需要对kubelet的内部机制有非常深入的了解，还会给社区带来管理压力，这就给新生代容器运行时造成了难于跨越的集成壁垒。CRI接口规范试图用定义清晰的抽象层清除这一壁垒，让开发者能够专注于容器运行时本身。在通向插件式容器支持及建设健康生态环境的路上，这是一小步，也是重要的一步。
2.
CRI的主要组件
kubelet使用gRPC框架利用UNIX
Socket与容器运行时（或CRI代理）进行通信。在这个过程中kubelet是客户端，CRI代理（shim）是服务端。
Protocol
Buffers
API包含两个gRPC服务：ImageService和RuntimeService。
ImageService提供了从仓库拉取镜像、查看和移除镜像的功能。
RuntimeService负责Pod和容器的生命周期管理、与容器的交互（execattachport-forward）。rkt和Docker这样的容器运行时可以使用一个Socket同时提供两个服务。在kubelet中可以用--container-runtime-endpoint和--image-service-endpoint参数设置这个Socket。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
