描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121399473
遨游海域的座头鲸、成群结队的角马、群聚飞翔的火烈鸟……构成了一幅幅壮美的生存画面，迁徙是自然界令人叹为观止的景观。
数智时代的“上云”与自然界的“迁徙”何其相似啊！
2021年伊始，我们博文视点的编辑团队联合阿里云技术团队，为广大IT技术人员奉上“阿里云数字新基建系列”。这个系列包括5本书，题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维（Windows），囊括了领先的云技术知识与阿里云技术团队独到的实践经验，是国内IT技术图书中又一套重磅作品！
《云原生操作系统Kubernetes》是这套系列书较早出版的一本，本书的特点请见宝贝长图！强烈建议您阅读！
阿里云数字新基建系列包括5本书，题材涉及Kubernetes、混合云架构、云数据库、CDN原理与流媒体技术、云服务器运维（Windows），囊括了领先的云技术知识与阿里云技术团队独到的实践经验，是国内IT技术图书又一套重磅作品！本书是阿里云容器服务产品线上实践的技术沉淀，主要包括理论篇和实践篇两部分内容。理论篇注重理论介绍，核心是Kubernetes on Cloud，即着重介绍Kubernetes和阿里云产品的结合。实践篇是疑难问题的诊断案例，希望通过案例来和读者分享Kubernetes深度问题诊断经验。 我们相信，Kubernetes on Cloud是未来十年云原生应用的底座，在这个底座之上势必会产生无数创新和实践，所以我们希望这本书可以对此技术的发展产生些许推动作用。
上篇 理论篇（技术进阶）
第1章 鸟瞰云上Kubernetes
1.1 内容概要 002
1.2 云资源层
1.2.1 专有版
1.2.2 托管版
1.2.3 Serverless版
1.3 单机系统层
1.4 集群系统层
1.4.1 专有版
1.4.2 托管版
1.4.3 Serverless版
1.5 功能扩展层
1.5.1 监控
1.5.2 日志
1.5.3 DNS
1.6 总结
第2章 认识集群的大脑
2.1 从控制器视角看集群
2.2 控制器的产生与演进
2.2.1 设计一台冰箱
2.2.2 统一操作入口
2.2.3 引入控制器
2.2.4 统一管理控制器
2.2.5 Shared Informer
2.2.6 List Watcher
2.3 控制器示例
2.3.1 服务控制器
2.3.2 路由控制器
2.4 总结
第3章 网络与通信原理
3.1 背景
3.2 阿里云Kubernetes集群网络大图
3.3 集群网络搭建
3.3.1 初始阶段
3.3.2 集群阶段
3.3.3 节点阶段
3.3.4 Pod阶段
3.4 通信原理
3.5 总结
第4章 节点伸缩的实现
4.1 节点增加原理
4.1.1 手动添加已有节点
4.1.2 自动添加已有节点
4.1.3 集群扩容
4.1.4 自动伸缩
4.2 节点减少原理
4.3 节点池原理
4.4 总结
第5章 认证与调度系统
5.1 “关在笼子里”的程序
5.1.1 代码
5.1.2 “笼子”
5.1.3 地址
5.2 得其门而入
5.2.1 入口
5.2.2 双向数字证书验证
5.2.3 KubeConfig文件
5.2.4 访问
5.3 择优而居
5.3.1 两种节点，一种任务
5.3.2 择优而居
5.3.3 Pod配置
5.3.4 日志级别
5.3.5 创建Pod
5.3.6 预选
5.3.7 优选
5.3.8 得分
5.4 总结
第6章 简洁的服务模型
6.1 服务的本质是什么
6.2 自带通信员
6.3 让服务照进现实
6.4 基于Netfilter的实现
6.4.1 过滤器框架
6.4.2 节点网络大图
6.4.3 升级过滤器框架
6.4.4 用自定义链实现服务的反向代理
6.5 总结
第7章 监控与弹性能力
7.1 阿里云容器服务Kubernetes的监控总览
7.1.1 云服务集成
7.1.2 开源集成方案
7.2 阿里云容器服务Kubernetes的弹性总览
7.2.1 调度层弹性组件
7.2.2 资源层弹性组件
7.3 总结
第8章 镜像下载自动化
8.1 镜像下载这件小事
8.2 理解OAuth 2.0协议
8.3 Docker扮演的角色
8.3.1 整体结构
8.3.2 理解docker login
8.3.3 拉取镜像是怎么回事
8.4 Kubernetes实现的私有镜像自动拉取
8.4.1 基本功能
8.4.2 进阶方式
8.5 阿里云实现的ACR credential helper
8.6 总结
第9章 日志服务的集成
9.1 日志服务介绍
9.2 采集方案介绍
9.2.1 方案简介
9.2.2 运行流程
9.2.3 配置方式
9.3 核心技术介绍
9.3.1 背景
9.3.2 实现方式
9.3.3 alibaba-log-controller内部实现
9.4 总结
第10章 集群与存储系统
10.1 从应用的状态谈起
10.1.1 无状态的应用
10.1.2 有状态的应用
10.2 基本单元：Pod Volume
10.3 核心设计：PVC与PV体系
10.4 与特定存储系统解耦
10.4.1 Volume Plugin
10.4.2 in-tree（内置） Volume Plugin
10.4.3 out-of-tree（外置） Volume Plugin
10.5 Kubernetes CSI管控组件容器化部署
10.6 基于Kubernetes的存储
10.7 总结
第11章 流量路由Ingress
11.1 基本原理
11.1.1 解决的问题
11.1.2 基础用法
11.1.3 配置安全路由
11.1.4 全局配置和局部配置
11.1.5 实现原理
11.2 场景化需求
11.2.1 多入口访问Ingress
11.2.2 部署多套Ingress Controller
11.3 获取客户端真实IP地址
11.3.1 理解客户端真实IP地址的传递过程
11.3.2 ExternalTrafficPolicy的影响
11.3.3 如何获取客户端真实IP地址
11.4 白名单功能
11.5 总结
第12章 升级设计与实现
12.1 升级预检
12.1.1 核心组件检查项
12.1.2 前置检查增项
12.2 原地升级与替代升级
12.2.1 原地升级
12.2.2 替代升级
12.3 升级三部曲
12.3.1 升级Master节点
12.3.2 升级Worker节点
12.3.3 核心组件升级
12.4 总结
下篇 实践篇（诊断之美）
第13章 节点就绪状态异常（一）
13.1 问题介绍
13.1.1 就绪状态异常
13.1.2 背景知识
13.1.3 关于PLEG机制
13.2 Docker 栈
13.2.1 docker daemon调用栈分析
13.2.2 Containerd调用栈分析
13.3 什么是D-Bus
13.3.1 runC请求D-Bus
13.3.2 原因并不在D-Bus
13.4 Systemd是硬骨头
13.4.1 “没用”的core dump
13.4.2 零散的信息
13.4.3 代码分析
13.4.4 Live Debugging
13.4.5 怎么判断集群节点NotReady是这个问题导致的
13.5 问题的解决
13.6 总结
第14章 节点就绪状态异常（二）
14.1 问题介绍
14.2 节点状态机
14.3 就绪三分钟
14.4 止步不前的PLEG
14.5 无响应的Terwayd
14.6 原因
14.7 修复
14.8 总结
第15章 命名空间回收机制失效
15.1 问题背景介绍
15.2 集群管控入口
15.3 命名空间控制器的行为
15.3.1 删除收纳盒里的资源
15.3.2 API、Group、Version
15.3.3 控制器不能删除命名空间里的资源
15.4 回到集群管控入口
15.5 节点与Pod的通信
15.6 集群节点访问云资源
15.7 问题回顾
15.8 总结
第16章 网络安全组加固对与错
16.1 安全组扮演的角色
16.2 安全组与集群网络
16.3 怎么管理安全组规则
16.3.1 限制集群访问外网
16.3.2 IDC与集群互访
16.3.3 使用新的安全组管理节点
16.4 典型问题与解决方案
16.4.1 使用多个安全组管理集群节点
16.4.2 限制集群访问公网或运营商级NAT保留地址
16.4.3 容器组跨节点通信异常
16.5 总结
第17章 网格应用存活状态异常
17.1 在线一半的微服务
17.2 认识服务网格
17.3 代理与代理的生命周期管理
17.4 就绪检查的实现
17.5 控制面和数据面
17.6 简单的原因
17.7 阿里云服务网格（ASM）介绍
17.8 总结
第18章 网格自签名根证书过期
18.1 连续重启的Citadel
18.2 一般意义上的证书验证
18.3 自签名证书验证失败
18.4 大神定理
18.5 Citadel证书体系
18.6 经验
18.7 总结
附录A 本书插图索引
附录B 本书部分缩略语 P210
这是一个人们对上云已经有了共识，但是对怎么样上好云还在深入讨论和探索的新阶段。
在上云之后，我们会遇到一些典型的问题，比如怎么样使用云服务器的问题。如果我们把多个业务混合部署在云服务器上，这些业务可能会因为使用了不同版本的库文件出现兼容性问题 ；而如果我们让每个业务实例独享一个云服务器，又会有明显的资源碎片问题。
包括了容器、编排调度、服务网格、持续集成交付（CICD）等在内的云原生技术，是“上好云”这个新阶段的核心技术，也是解决“上好云”这个问题的最佳实践策略和方法论。
作为本书的开篇，我们希望在序章部分交代清楚几件事情：
（1）多角度下的云原生“操作系统”——Kubernetes 的基本理论 ；（2）学习和研究 Kubernetes 的方法 ；（3）本书的成书背景。
什么是 Kubernetes
我们来看一下什么是 Kubernetes。在这一部分，我们会从四个角度和大家 分享我们的看法。
第一个角度，未来是什么样的
图 0-1 是一张未来企业的 IT 基础设施架构图。简单来说，未来基本上所有的企业都会把 IT 基础设施部署在云上，用户会基于 Kubernetes 把底层云资源分割成具体的集群单元，给不同的业务使用。
之后，随着业务微服务化的落地，服务治理会越来越重要。像服务网格这类把服务治理逻辑下沉到基础设施层的思路，势必成为下一个趋势。
目前，阿里巴巴几乎所有的业务都“跑”在云上，其中一大半业务已经迁移到了内部定制版的 Kubernetes 集群上，而且这个比例还在迅速增加中。
对于服务网格技术来说，一些企业（比如蚂蚁集团）其实已经有线上业务在 使用了。大家可以通过蚂蚁集团一些技术专家的公开分享来了解他们的实践过程。
虽然这张图里的观点可能有一些绝对，但是目前这个趋势是非常明显的。 未来几年，Kubernetes 肯定会像 Linux 一样，作为集群的操作系统无处不在。
第二个角度，Kubernetes 与操作系统
图 0-2 是传统操作系统（单机操作系统）和云原生系统（集群操作系统）的比较图。大家知道，像 Linux 或者 Windows 这些传统的操作系统，它们扮演 的角色是底层硬件的抽象层。它们向下管理计算机硬件，如内存和 CPU，然后把底层硬件抽象成易用的接口，向上对应用层提供支持。
而 Kubernetes 技术，我们也可以理解为一个操作系统。这个操作系统也是一个抽象层。它向下管理的硬件，不是内存或者 CPU 这种硬件，而是多台计算机组成的集群。这些计算机本身就是普通的单机系统，有自己的操作系统和硬件。Kubernetes 把这些计算机当成一个资源池统一管理，向上对应用层提供支撑。
Kubernetes 上的应用的特别之处在于，它们都是容器化应用。对容器不太 了解的读者，可以简单地把它们理解成安装包。安装包里包括了所有的依赖库， 如 libc 函数库等，使得这些应用不必依赖底层操作系统库文件就可以直接运行。
第三个角度，Kubernetes 与 Google 运维解密
图 0-3 的左边是 Kubernetes 集群示意图，右边是一本非常有名的书《SRE Google 运维解密》。相信很多人都看过这本书，而且有很多公司正在实践这本 书里的方法，如故障管理、运维排班等。
Kubernetes 和这本书的关系，可以比作剑法和气功的关系。读者看过金庸的《笑傲江湖》的话，可能会记得，《笑傲江湖》里的华山派分为两个派别，剑宗和气宗。
剑宗强调剑法的精妙，而气宗更注重气功修炼。实际上剑宗和气宗的“分 家”，是因为华山派两个弟子偷学了同一本《葵花宝典》，但是两个人各记了一 部分内容，最终因为观点分歧分成了两派。
Kubernetes 实际上源自 Google 的集群自动化管理和调度系统 Borg，也就 是这本书里讲的运维方法所管理的对象。Borg 系统和书里讲的方法论，可以被看作一件事情的两个方面。如果一个公司只学习他们的运维方法（比如设了很多 SRE 职位）而不懂这套方法所管理的对象，其实就是学习《葵花宝典》，但是只学了一部分。
Borg 因为是 Google 内部的系统，所以一般人是看不到的，而 Kubernetes 基本上继承了Borg 在集群自动化管理方面非常核心的一些理念。所以大家如 果看了这本书，觉得非常有参考价值，或者已经在实践这本书里的方法，就一定要深入理解 Kubernetes。
第四个角度，技术演进史
在早期，我们做一个网站后端，可能只需要把所有的模块放在一个可执行文件里，就如同图 0-4 中第一个架构图一样。网站后端包括界面、数据和业务三个模块，这三个模块被编译成一个可执行文件，“跑”在一台服务器上。
但是随着业务的大幅增长，我们没有办法通过升级服务器配置的方式来使 后端扩容，这时候我们就必须做微服务了。
微服务会把单体应用拆分成低耦合的小应用。这些应用各自负责一块相对 独立的业务，每个小应用实例独占一台服务器，它们之间通过网络互相调用。 这就是图 0-4 中第二个架构图的模式。
这里最关键的是，我们可以通过增加实例个数，来对小应用做横向扩容。这就解决了单台服务器无法扩容的问题。
微服务之后会出现一个问题，就是一个实例独占一台服务器的问题，这种部署方式的资源浪费其实是比较严重的。这时我们自然会想到，把这些实例混合部署到底层服务器上。
但是混合部署会引出两个新问题。一个是依赖库兼容性问题，这些应用依赖的库文件版本可能完全不一样，安装到一个操作系统里，就会有兼容性问题；另一个问题是应用调度和集群资源管理的问题，比如一个新的应用被 创建出来，我们需要考虑这个应用被调度到哪台服务器，以及调度之后资源 够不够用的问题。
依赖库兼容性问题，实际上是靠容器化来解决的，也就是每个应用自带依赖库，只跟其他应用共享内核，而调度和资源管理问题就是 Kubernetes 所要解决的问题。
所以整个架构最终会演变成图 0-4 中第三个架构图的模式。
如何学习 Kubernetes
我们会从三个方面总结我们的经验 ：一是为什么 Kubernetes 学习起来比较难，二是一些方法和建议，三是一个实际例子。
如图 0-5 所示，总体来说，之所以 Kubernetes 门槛比较高，学习起来比较困难，一个原因是它的技术栈非常深，包括内核和系统，以及虚拟化、容器技 术、网络、存储、安全，甚至可信计算等，绝对可以称得上全栈技术。
同时，Kubernetes 在云环境中的实现，肯定会涉及非常多的云产品，比如在阿里云上，Kubernetes 集群的实现用到了云服务器、虚拟网络、负载均衡、安全组、日志服务、云监控、ahas 和 arms 等中间件产品、服务网格、弹性伸缩等。
最后，因为 Kubernetes 是一个通用的计算平台，所以它会被用到各种业务 场景中去，比如数据库、边缘计算、机器学习、流计算等。
基于我们的经验，学习 Kubernetes 需要从了解、动手、思考三个方面去把 握，如图 0-6 所示。
首先，了解其实很重要，特别是了解技术的演进史，以及技术的全景图。
一方面，我们需要知道各种技术的演进历史，比如容器技术是怎么从 chroot 这个命令发展而来的，以及技术演进背后要解决的问题是什么，只有知道技术的演进史和发展的动力，我们才能对未来技术方向有自己的判断。
另一方面，我们需要了解技术全景图。对 Kubernetes 来说，我们需要了解 整个云原生技术栈，包括容器、CICD、微服务、服务网格等，知道 Kubernetes 在整个技术栈里所处的位置。
其次，除了这些基本的背景知识以外，学习 Kubernetes 技术，动手实践是 非常关键的。
从我们和大量工程师一起解决问题的经验来说，很多人其实不会去深入研 究技术细节。我们经常开玩笑说工程师有两种，一种是 search engineer，就是 搜索工程师，一种是 research engineer，就是研究工程师。很多工程师遇到问题，就用搜索引擎搜索一下，如果找不到答案，就直接请别人帮忙了。这样是很难深入理解一个技术的。
最后，就是怎么去思考，怎么去总结了。我们需要在理解技术细节之后，不断地问自己，细节的背后有没有什么更本质的东西。也就是我们要把复杂的细节看简单，然后找出普遍的模式来。
下面用一个例子来具体解释上面的方法。
这个例子是关于集群控制器的，如图 0-7 所示。我们在学习 Kubernetes 的 时候会听到几个概念，像声明式 API、Operator、面向终态设计等。这些概念本质上都是在讲一件事情，就是控制器模式。
我们怎么来理解 Kubernetes 的控制器呢？请大家先看一下第一张图。这张 图是一个经典的 Kubernetes 架构图，这张图里有集群 Master（管控）节点和 Worker（工作）节点，Master 节点上有中心数据库（Database）、集群接口（API Server）、调度器（Scheduler）以及各类控制器（Controller）。
中心数据库是集群的核心存储系统，API Server 是集群的管控入口，调度 器负责把应用调度到资源充沛的节点上，而控制器是我们这里要说的重点。
控制器的作用，我们用一句话概括，就是“让梦想照进现实”。从这个意义上来讲，我自己（罗建龙）也经常扮演控制器的角色，我女儿如果说，“爸爸， 我要吃冰激凌”，那我女儿就是集群的用户，我就是负责把她这个愿望实现的人， 也就是控制器。
除了 Master 节点以外，Kubernetes 集群有很多 Worker 节点，这些节点都 部署了 Kubelet 和 Proxy 这两个代理。Kubelet 负责管理 Worker 节点，包括应用在节点上启动和停止之类的工作。Proxy 负责把服务的定义落实成具体的 iptables 或者 ipvs 规则。其实这里服务的概念，简单来说就是利用 iptables 或者 ipvs 来实现负载均衡。
如果从控制器的角度来看第一张图的话，我们就会得到第二张图，也就是 说，集群实际上就包括一个数据库、一个集群入口，以及很多个控制器。这些组件，包括调度器、Kubelet 和 Proxy 在内，实际上都是在不断地观察集群里各种资源的定义，然后把这些定义落实成具体的配置，比如容器启动或 iptables 配置。
从控制器的角度观察 Kubernetes，我们其实得到了 Kubernetes 最根本的一条原理，就是 Kubernetes 是按照控制器模式运行的。
控制器模式在我们的生活中无处不在，这里我拿冰箱举个例子。我们在控制冰箱的时候，并不会直接去控制冰箱里的制冷系统或者照明系统。我们打开冰箱的时候，里边的灯会打开，在我们设置了想要的温度之后，就算我们不在家，制冷系统也会一直保持这个温度。这背后就是因为有控制器模式在起作用。
在阿里云智能技术发展过程中，阿里云和我们的伙伴、客户都会碰到非常多的技术理论和实践场景，其中Kubernetes 是在云原生环境下为大家熟知的开源技术，应用范围非常广泛。本书聚焦在体系化的案例分享，结合云计算的各种环境和应用部署优化，期望能帮助大家对云原生环境中的 Kubernetes 有更多的理解和创新。
——李津 阿里云智能副总裁，全球技术服务部总经理
5G、AI等新技术的突破，使云计算的应用进入了一个全新阶段，从以提供数据存储和互联网服务为主，到成为人机共融和万物互联的基础设施。传统IT基础设施存在可靠性、伸缩性、灵活性、环境依赖、系统性能、运维成本等方面的诸多缺点，而以 Kubernetes 为代表的云原生基础设施则给这一系列问题提供了“杀手”级的解决方案。本书系统地介绍了阿里云构建的云原生操作系统，是各类云原生应用的基石，对推动数字新基建具有重要的参考价值。
——侯迪波 浙江大学控制科学与工程学院教授
在过去的发展中，我们看到互联网公司牵引着技术从小型机、X86 架构、分布式、微服务，一路升级到今天的云计算、容器化，而这些新技术在互联网公司得到验证后，又被更多的企业采用，极大地提升了效率和稳定性。今天，我们也希望把在 Kubernetes 领域的一些经验和*实践分享给大家，让更多的公司能享受新技术的红利，让更多技术人工作更轻松，为更多客户提供更好的服务体验。
——沈乘黄 阿里云智能全球技术服务部总监
第 6 章 简洁的服务模型
在 CNCF（云原生计算基金会）对云原生的定义中，容器、微服务、服务网格、不可变基础设施和声明式 API 被作为云原生的代表性技术。其中的容器、不可变基础设施和声明式 API 的作用是建立一个自动化的、容错性强的应用承载平台 ；而微服务和服务网格的作用则是为应用提供优秀的内部模块间的互通机制和对外服务接口机制。
Kubernetes 作为云原生的操作系统，实现了一套默认的服务机制。这套机制的特点是足够健壮且足够简单，基本上能够满足大多数业务需求，用户可以在这套机制的基础上搭建自己的微服务环境。
虽然 Kubernetes 的服务机制上手比较容易，但是在对云上海量问题的处理过程中，我们发现大多数工程师对服务机制，或者说机制背后的原理不是很清楚，这会严重影响工程师的运维开发效率。
本章以 Kubernetes 服务为主题，希望通过深入的解释，可以让读者理解服务的本质及实现原理。
6.1 服务的本质是什么
从概念上来讲，Kubernetes 集群的服务，其实就是负载均衡或反向代理。这跟阿里云的负载均衡产品有很多类似的地方。和负载均衡一样，服务有它的 IP 地址以及前端端口，同时服务后面会挂载多个容器组作为其“后端服务器”，这些“后端服务器”有自己的 IP 地址以及监听端口，如图 6-1 所示。
当这样的负载均衡和后端的架构与 Kubernetes 集群结合的时候，我们可以想到的最直观的实现方式，就是集群中某一个节点专门做负载均衡（类似Linux 虚拟服务器）的角色（见图 6-2），而其他节点则用来承载后端容器组。
这样的实现方法有一个巨大的缺陷，就是单点问题。Kubernetes 集群是 Google 多年来自动化运维实践的结晶，这样的实现显然与其自动化运维的哲学是相背离的。
6.2 自带通信员
边车（sidecar）模式是微服务领域的核心概念。边车模式换一个通俗一点的说法，就是自带通信员模式。熟悉服务网格的读者肯定对它很熟悉了，但是可能很少有人注意到，其实 Kubernetes 集群原始服务的实现，也是基于边车模式的，如图 6-3 所示。
在 Kubernetes 集群中，服务的实现实际上是为每一个集群节点部署了一个反向代理 sidecar。而所有对集群服务的访问，都会被节点上的反向代理转换成对服务后端容器组的访问。基本上，节点和这些 sidecar 的关系如图 6-4所示。
6.3 让服务照进现实
我们在前面两节中看到了，Kubernetes 集群的服务本质上是负载均衡，即反向代理 ；同时我们知道了，在具体实现中，这个反向代理，并不是部署在集群某一个节点上的，而是作为集群节点的 sidecar 部署在每个节点上的。
在这里让服务“照”进反向代理这个“现实”的，是 Kubernetes 集群的一个控制器，即 kube-proxy。简单来说，kube-proxy 作为部署在集群节点上的控制器，通过集群 API Server 监听着集群状态变化。当有新的服务被创建的时候，kube-proxy 会把集群服务的状态、属性，翻译成反向代理的配置，整个过程如图 6-5 所示。
那剩下的问题就是反向代理（即图 6-5 中的 Proxy）的实现了。
评论
还没有评论。