云原生Kubernetes全栈架构师实战

本书比较全面的介绍了k8s以及以其为基础所涉及到云原生应用各方面的知识，理论知识涉及相对较少，全书充斥着大量的实践应用，对于k8s的学习来说这是合适的，因为k8s不是看会的，是练会的，正如作者所言，要想学会k8s至少要搭建8次k8s集群，所以一定要动手实践反复练习。

一本详略得当的书，既可当作工具书用来翻阅，对 k8s 的初学者来说，作为入门书籍也比较恰当。书中讲解了云原生涉及到的大部分比较实用的技术栈，但是有些技术则是大公司不屑用小公司不会用，不过拿来学习和练习也是比较不错的。

虽然读不太懂，但感觉内容很全，面面俱到，可以作为实操的辅助工具书，比较实用

太细节了，光装 k8s 就有40 页，第一遍看直接劝退。第二遍勉强翻到了最后。

写的挺好，虽然有些地方讲的不够深入

比较适合开发和运维阅读了解云原生和k8s的一本书，有概念、原理和实践讲述，循序渐进。 可以挑着看，比如k8s核心概念相关的1～10章（除第二章外）详读，有利于对k8s有大致理解。其他章节是扩展内容略读，有助于了解云原生生态组件，窥探企业级实践的一部分。 不过个人觉得还是要有一定的devops实践/使用经验，才能更好理解书中讲述的知识点。我阅读的时候总会联想到这几年来使用公司内部devops平台的一些场景，有助于理解，偶尔会有“原来如此”的感叹。假如我是没有任何使用经验的开发者，我估计很难看下去。 我相信k8s还会在服务端屹立不倒十几年，因为它是从全球最大的生产流量实战中诞生的。它的核心设计是简洁的，比如用抽象的CRI/CNI/CSI标准描述服务端应用最核心的基础设施；它的功能非常丰富，满足服务应用在持续扩张和运维的需求（高可用，低维护成本，高资源利用率，使用灵活，安全防护，可扩展性高）；它的生态十分完善，全球互联网公司都在用k8s，各式各样的生产场景落地不断反哺k8s，云原生基金会陆续孵化衍生产品，扩大影响力。 这次阅读挺有收获的，特别推荐和我一样，一直有使用devops平台但未了解过其原理的服务端开发者阅读。

一、K8S的基础概念在应用端口方面，传统架构中，一台服务器可能跑了很多进程，每个进程都有一个端口，需要人为地去配置端口，并且还需要考虑端口冲突的问题，如果有防火墙的话，还需要配置防火墙。在Kubernetes中，端口统一管理、统一配置，每个应用的端口都可以设置成一样的，之后通过Service进行负载均衡，大大降低了端口管理的复杂度和端口冲突。 Kubernetes架构可简单分为主（Master）节点、从（工作/Worker/Node）节点和数据库Etcd。其中主节点为集群的控制单元，一般不会运行业务应用程序，主要包含的组件有Kube-APIServer、Kube-ControllerManager、Kube-Scheduler。从节点为工作节点，也就是部署应用程序容器的节点，主要包含的组件有Kubelet、Kube-Proxy，当然如果Master节点也要部署容器，也会包含这两个组件。 负载均衡可以使用软件负载均衡Nginx/LVS/HAProxy+KeepAlived或者硬件负载均衡F5等，通过负载均衡对Kube-APIServer提供的VIP即可实现Master节点的高可用，其他组件通过该VIP连接至Kube-APIServer。 Node节点包括：·　Kubelet：负责与Master通信协作，管理该节点上的Pod，对容器进行健康检查及监控，同时负责上报节点和节点上面Pod的状态。·　Kube-Proxy：负责各Pod之间的通信和负载均衡，将指定的流量分发到后端正确的机器上。·　Docker Engine：Docker引擎，负载对容器的管理。 Pod可简单地理解为一组、一个或多个容器，每个Pod还包含一个Pause容器，Pause容器是Pod的父容器，它主要负责僵尸进程的回收管理，同时通过Pause容器可以使同一个Pod里面的不同容器共享存储、网络、PID、IPC等，容器之间可以使用localhost:port相互访问，可以使用Volume等实现数据共享。根据Docker的构造，Pod可被建模为一组具有共享命名空间、卷、IP地址和端口的容器。 在生产环境中，很少单独运行一个Pod，因为单独创建的Pod并不能实现一些高级的发布策略，所以在实际使用中经常会用Deployment、DaemonSet、StatefulSet等高级控制器调度并管理Pod。 二、K8S的调度基础Replication Controller和ReplicaSet的创建、删除和Pod并无太大区别，Replication Controller目前几乎已经不在生产环境中使用，ReplicaSet也很少单独被使用，都是使用更高级的资源Deployment、DaemonSet、StatefulSet管理Pod。 ReplicaSet可以确保在任何给定时间运行的Pod副本达到指定的数量，但是Deployment是一个更高级的概念，它管理ReplicaSet并为Pod和ReplicaSet提供声明性更新以及许多其他有用的功能，所以建议在生产环境下使用Deployment代替ReplicaSet。Deployment一般用于部署公司的无状态服务，这个也是最常用的控制器，因为企业内部现在都是以微服务为主，而微服务实现无状态化也是最佳实践，可以利用Deployment的高级功能做到无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚等功能。 StatefulSet管理的Pod部署和扩展规则如下：·　对于具有N个副本的StatefulSet，将按顺序从0到N‒1开始创建Pod。·　当删除Pod时，将按照N‒1到0的反顺序终止。·　在缩放Pod之前，必须保证当前的Pod是Running（运行中）或者Ready（就绪）。·　在终止Pod之前，它所有的继任者必须是完全关闭状态。 有时候我们需要在每个Kubernetes节点或符合条件的节点上都部署某个应用，那么就可以使用Kubernetes的DaemonSet调度Pod。 三、K8S的服务发布基础在传统架构配置多个相同服务的负载均衡可能使用的是Nginx的upstream，在Kubernetes中用Service实现。在传统架构配置域名访问应用可能使用Nginx的Server配置，在Kubernetes中用Ingress实现域名路由的配置（最终通过Ingress的配置生成对应控制器的配置，比如使用Nginx作为Ingress控制器，Ingress资源最终生成的就是Nginx的配置文件）。 很多情况下，我们需要对各类资源进行分组管理，或者同一个应用的Pod可能会根据不同的功能进行划分，比如有一个后端的应用，需要提供API接口供前端调用，也需要进行一些周期性的计划任务，相当于同一个镜像分两个身份运行，所以就需要对这两个资源文件用标签进行区分，这样的话就可以让流量进入提供API接口的Pod，执行计划任务的Pod不接收任何流量。 Service主要用于Pod之间的通信，对于Pod的IP地址而言，Service是提前定义好并且是不变的资源类型，在生产环境中最佳的实践方式就是每个应用互相调用时使用Service的名字进行连接，而非IP地址。 假设有一个用作图片处理的backend（后端），运行了3个副本，每个副本具有一个app=backend的Label，这些副本是可互换（无状态）的，之后创建一个Service指定Selector为app=backend，那么frontend（前端）即可通过这个Service的名称直接访问backend，所以frontend不需要关心它调用了哪个backend副本。即使组成这一组backend程序的Pod发生了变化，frontend也没有必要知道，而且也不需要跟踪这一组backend的状态，因为Service能够解耦这种关联。 Kubernetes Service Type（服务类型）主要包括以下几种：·　ClusterIP：在集群内部使用，默认值，只能从集群中访问。·　NodePort：在所有安装了Kube-Proxy的节点上打开一个端口，此端口可以代理至后端Pod，可以通过NodePort从集群外部访问集群内的服务，格式为NodeIP:NodePort。·　LoadBalancer：使用云提供商的负载均衡器公开服务，成本较高。·　ExternalName：通过返回定义的CNAME别名，将Service映射到可被DNS解析的其他域名，需要1.7或更高版本kube-dns的支持。 在使用Kubernetes时，部署一个应用并使用域名进行发布的流程如下：1）部署应用至Kubernetes集群，容器内定义了程序启动的方式。2）配置ClusterIP类型的Service，通过Selector链接到容器内的应用。3）配置Ingress链接到该应用的Service，之后将域名解析到Ingress（Ingress前面可能还有其他代理服务器）对应的宿主机上即可。 本章讲解了服务发布的两种方式，即Service和Ingress。通常情况下，Service用于程序间的内部访问，即后端服务之间的相互调用。而Ingress多用于对外发布服务，即通过域名的形式让用户能访问到内部服务，这也是最普遍的发布方式，但是如果一个不需要对外发布的后端服务，通过Ingress被另一个后端服务调用，则相当于从外部绕了一圈，这不是推荐的方式。 实际使用时，也会有架构直接通过Service的NodePort暴露服务，然后由上层的网关进行代理，域名都配置在上层，这样的话，服务过多会引起端口维护非常复杂，可能还会有性能损耗。所以一般推荐在上层配置通配符域名，比如*.test.com到Kubernetes的Ingress Controller，之后由Ingress再做路由。比如a.test.com指向A项目，a.test.com/xxx指向A项目的xxx服务。 另外在程序设计时，有了Service无须再考虑负载均衡等问题，所以如果有程序间的调用，首选Service，并且以后可以无缝地接入服务网格，进行服务治理。在使用Kubernetes时，其实并不推荐使用Spring Cloud这类架构，因为很多功能都是类似的，在Kubernetes上仍旧使用Spring Cloud属于“套娃”型架构，应该向着单服务方向进行开发，比如直接使用Spring Boot即可。 虽然Operator和Helm实现的功能类似，但是两者还是有很大的区别的。Operator更倾向于管理复杂的有状态服务，比如MySQL集群、Redis集群、TiDB集群等，而Helm更倾向于管理无状态应用的部署，比如公司的服务、某些不需要持久化数据的中间件、不需要实现额外功能的服务等。 四、拓展篇服务网格（Service Mesh）是由Buoyant公司的CEO William Morgan发起的，他对服务网格的定义如下：·　专用基础设施层：独立的运行单元。·　包括数据层和控制层：数据层负责交付应用请求，控制层控制服务如何通信。·　轻量级透明代理：实现形式为轻量级网络代理。·　处理服务间通信：主要目的是实现复杂网络中的服务间通信。·　可靠地交付服务请求：提供网络弹性机制，确保可靠交付请求。·　与服务部署一起，但服务无须感知：尽管跟应用部署在一起，但对应用是透明的。 Istio最为重要的一个概念就是VirtualService（虚拟服务），和Kubernetes的Service类似，但是两种并不是对等的资源类型。VirtualService基于Istio和对应平台提供的基本连通性和服务发现能力，将请求路由到对应的目标。每一个VirtualService包含一组路由规则，Istio将每个请求根据路由匹配到指定的目标地址。 和Kubernetes的Service不同的是，Kubernetes的Service只提供了最简单的服务发现和负载均衡的能力，如果想要实现更加细粒度的流量分发，比如灰度、蓝绿等流量管理，Kubernetes的Service显得比较吃力或者无法实现，而VirtualService在流量管理方面有着比较好的灵活性和有效性，可以在代码零侵入的情况下实现更加丰富的流量管理，比如灰度等。

二进制部署那节没问题，我修改TLS Bootstrapping的$token_id"和"$token_secret，相应在bootstrap.secret.yaml修改3个地方： metadata: name: bootstrap-token-${token_id} stringData: token-id: ${token_id} token-secret: ${token_secret}

这本书内容全面，虽然没有很深入，但对于入门和建立全局视角很有帮助

基本上方方面面都讲到了，可以作为入门或者检验自己知识体系的工具书