书籍作者:闫健勇 | ISBN:9787121323515 |
书籍语言:简体中文 | 连载状态:全集 |
电子书格式:pdf,txt,epub,mobi,azw3 | 下载次数:5389 |
创建日期:2021-02-14 | 发布日期:2021-02-14 |
运行环境:PC/Windows/Linux/Mac/IOS/iPhone/iPad/Kindle/Android/安卓/平板 |
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资深系统架构师、大数据和云计算技术专家
拥有多年IT行业从业经验,参与过多个大型应用的架构设计、系统开发和实施落地,精通大数据、云计算及大型系统架构和开发的相关技术,对互联网和电信行业的热点技术有着深刻的理解,是云计算和大数据方面的技术专家。
崔秀龙,HPE资深架构师
开源软件、自动化爱好者,拥有十多年从业经验,对软件生命周期的各个环节均有深刻的理解。
闫健勇,HPE高级项目经理、总架构师
拥有超过15年的电信行业系统建设经验,主导了多项电信大型系统的架构设计和管理,对于云计算和大数据在电信行业中的应用拥有丰富的经验。
崔晓宁,HPE高级顾问
拥有超过7年的测试咨询和质量管理经验,在云计算、大数据和分布式运算架构下的业务质量控制方面有非常丰富的项目实践和心得,并对推动组织架构优化有丰富的经验。帮助多个超过百人的大型项目建立软件产品管理规范和体系,并对其运营提供指导。
刘晓红,HPE高级咨询顾问
拥有超过10年的电信行业从业经验,亲历中国移动BSS/OSS领域核心系统的建设发展历程,具备丰富的咨询规划、需求分析、产品设计、项目管理、测试管理经验,专注于云计算、大数据等前沿技术的研究。
本书是容器圈Kubernetes重磅开山作《Kubernetes木又威指南》的纪念版,内容更新到Kubernetes v1.6+版本。
本书作者全部来自惠普公司云计算实战一线,敏锐地捕获和探索着各种IT前瞻技术,有着全面而扎实的技术架构体系、对创新技术天生的热情、国际技术领先者的视野,还有着对企业级IT架构的深入把握。
纪念并不是为了结束,而是为了新的写作思路的展开。我们用尽全力更新和修改本书的内容,把能想到的和K8s新的更新都详细地写进去了,致使本书厚达700页,同时,我们深感不能再接着更新下去了。还好,本书记录了K8s近的很重要的里程碑版本,之后的各种版本变化应该都是基于这个版本的小范围内的更新,本书应该还能陪伴大家很长一段时间。
奉上寄语:“我轻轻地招手,迎接明天的云彩……”
我不知道你是如何获得这本书的,可能是在百度头条、网络广告、朋友圈中听说本书后购买的,也可能是某一天逛书店时,这本书恰好神奇地出现在你面前的书架上,让你想起一千多年前那个意外得到《太公兵法》的传奇少年,你觉得这是冥冥之中上天的恩赐,于是果断带走。不管怎样,我相信多年以后,这本书仍然值得你回忆。
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人士来说,本书都极具参考价值。
吴治辉
惠普公司系统架构师
第1章 Kubernetes入门 1
1.1 Kubernetes是什么 1
1.2 为什么要用Kubernetes 4
1.3 从一个简单的例子开始 5
1.3.1 环境准备 6
1.3.2 启动MySQL服务 6
1.3.3 启动Tomcat应用 9
1.3.4 通过浏览器访问网页 10
1.4 Kubernetes基本概念和术语 12
1.4.1 Master 12
1.4.2 Node 12
1.4.3 Pod 15
1.4.4 Label(标签) 18
1.4.5 Replication Controller 22
1.4.6 Deployment 26
1.4.7 Horizontal Pod Autoscaler 28
1.4.8 StatefulSet 29
1.4.9 Service(服务) 30
1.4.10 Volume(存储卷) 37
1.4.11 Persistent Volume 41
1.4.12 Namespace(命名空间) 42
1.4.13 Annotation(注解) 43
1.4.14 小结 44
第2章 Kubernetes实践指南 45
2.1 Kubernetes安装与配置 45
2.1.1 系统要求 45
2.1.2 使用kubeadm工具快速安装Kubernetes集群 46
2.1.3 以二进制文件方式安装Kubernetes集群 51
2.1.4 Kubernetes集群的安全设置 59
2.1.5 Kubernetes集群的网络配置 64
2.1.6 内网中的Kubernetes相关配置 64
2.1.7 Kubernetes的版本升级 65
2.1.8 Kubernetes核心服务配置详解 66
2.2 kubectl命令行工具用法详解 86
2.2.1 kubectl用法概述 86
2.2.2 kubectl子命令详解 88
2.2.3 kubectl参数列表 90
2.2.4 kubectl输出格式 90
2.2.5 kubectl操作示例 92
2.3 深入掌握Pod 93
2.3.1 Pod定义详解 93
2.3.2 Pod的基本用法 98
2.3.3 静态Pod 103
2.3.4 Pod容器共享Volume 104
2.3.5 Pod的配置管理 106
2.3.6 在容器内获取Pod信息(Downward API) 119
2.3.7 Pod生命周期和重启策略 124
2.3.8 Pod健康检查 125
2.3.9 玩转Pod调度 127
2.3.10 Init Container(初始化容器) 149
2.3.11 Pod的升级和回滚 152
2.3.12 Pod的扩容和缩容 166
2.3.13 使用StatefulSet搭建MongoDB集群 171
2.4 深入掌握Service 180
2.4.1 Service定义详解 181
2.4.2 Service基本用法 182
2.4.3 Headless Service 187
2.4.4 集群外部访问Pod或Service 192
2.4.5 DNS服务搭建指南 196
2.4.6 自定义DNS和上游DNS服务器 204
2.4.7 Ingress:HTTP 7层路由机制 208
第3章 Kubernetes核心原理 226
3.1 Kubernetes API Server 原理分析 226
3.1.1 Kubernetes API Server概述 226
3.1.2 独特的Kubernetes Proxy API接口 229
3.1.3 集群功能模块之间的通信 230
3.2 Controller Manager 原理分析 231
3.2.1 Replication Controller 232
3.2.2 Node Controller 234
3.2.3 ResourceQuota Controller 235
3.2.4 Namespace Controller 237
3.2.5 Service Controller与Endpoint Controller 237
3.3 Scheduler原理分析 238
3.4 kubelet运行机制分析 242
3.4.1 节点管理 242
3.4.2 Pod管理 243
3.4.3 容器健康检查 244
3.4.4 cAdvisor资源监控 245
3.5 kube-proxy 运行机制分析 247
3.6 深入分析集群安全机制 251
3.6.1 API Server认证管理(Authentication) 251
3.6.2 API Server授木又管理(Authorization) 253
3.6.3 Admission Control(准入控制) 272
3.6.4 Service Account 274
3.6.5 Secret私密凭据 279
3.7 网络原理 282
3.7.1 Kubernetes网络模型 282
3.7.2 Docker的网络基础 284
3.7.3 Docker的网络实现 296
3.7.4 Kubernetes的网络实现 304
3.7.5 Pod和Service网络实战 308
3.7.6 CNI网络模型 321
3.7.7 Kubernetes网络策略 331
3.7.8 开源的网络组件 333
3.8 共享存储原理 363
3.8.1 共享存储机制概述 363
3.8.2 PV详解 364
3.8.3 PVC详解 368
3.8.4 PV和PVC的生命周期 370
3.8.5 StorageClass详解 373
3.8.6 动态存储管理实战:GlusterFS 376
第4章 Kubernetes开发指南 388
4.1 REST简述 388
4.2 Kubernetes API详解 390
4.2.1 Kubernetes API概述 390
4.2.2 API版本 395
4.2.3 API Groups(API组) 395
4.2.4 API方法说明 397
4.2.5 API响应说明 398
4.3 使用Java程序访问Kubernetes API 400
4.3.1 Jersey 401
4.3.2 Fabric8 412
4.3.3 使用说明 413
第5章 Kubernetes运维指南 434
5.1 Kubernetes集群管理指南 434
5.1.1 Node的管理 434
5.1.2 更新资源对象的Label 436
5.1.3 Namespace:集群环境共享与隔离 437
5.1.4 Kubernetes资源管理 441
5.1.5 资源紧缺时的Pod驱逐机制 475
5.1.6 Pod Disruption Budget(主动驱逐保护) 483
5.1.7 Kubernetes集群的高可用部署方案 485
5.1.8 Kubernetes集群监控 496
5.1.9 集群统一日志管理 513
5.1.10 Kubernetes审计日志(Audit Log) 522
5.1.11 使用Web UI(Dashboard)管理集群 523
5.1.12 Helm:Kubernetes应用包管理工具 527
5.2 Trouble 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.3 Kubernetes开发中的新功能 546
5.3.1 Pod Preset(运行时参数注入策略) 546
5.3.2 Cluster Federation(集群联邦) 553
5.3.3 容器运行时接口(Container Runtime Interface-CRI) 557
5.3.4 对GPU的支持 561
5.3.5 Kubernetes的演进路线(Roadmap)和开发模式 565
第6章 Kubernetes源码导读 568
6.1 Kubernetes源码结构和编译步骤 568
6.2 kube-apiserver进程源码分析 572
6.2.1 进程启动过程 572
6.2.2 关键代码分析 574
6.2.3 设计总结 589
6.3 kube-controller-manager进程源码分析 592
6.3.1 进程启动过程 592
6.3.2 关键代码分析 595
6.3.3 设计总结 603
6.4 kube-scheduler进程源码分析 605
6.4.1 进程启动过程 605
6.4.2 关键代码分析 610
6.4.3 设计总结 617
6.5 kubelet进程源码分析 619
6.5.1 进程启动过程 619
6.5.2 关键代码分析 624
6.5.3 设计总结 647
6.6 kube-proxy进程源码分析 648
6.6.1 进程启动过程 648
6.6.2 关键代码分析 650
6.6.3 设计总结 665
6.7 kubectl进程源码分析 666
6.7.1 kubectl create命令 667
6.7.2 rolling-update命令 671