融数数据基于Kubernetes的微服务治理和构建平台

融数数据基于Kubernetes的微服务治理和构建平台

DNS：A——IP地址CName——主机名PTR——与A相反SRV——DNSSRV是DNS记录中一种，用来指定服务地址。与常见的A记录、cname不同的是，SRV中除了记录服务器的地址，还记录了服务的端口，并且可以设置每个服务地址的优先级和权重。访问服务的时候，本地的DNSresolver从DNS服务器查询到一个地址列表，根据优先级和权重，从中选取一个地址作为本次请求的目标地址。

我们都知道CAP是EricBrewer提出的分布式系统三要素：

强一致性(Consistency)

可用性(Availability)

分区容忍性(PartitionTolerance)几乎所有的服务发现和注册方案都是CP系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持stalereads）。

服务发现之EtcdVSConsul

值得注意的是，分布式系统中的数据分为控制数据和应用数据。使用etcd的场景默认处理的数据都是控制数据，对于应用数据，只推荐数据量很小，但是更新访问频繁的情况。

抄自这里

************************************************************************************************网上找来找去都是zk和etcd的比较，和consul的比较很少，这个感觉还算靠谱，也在别的地方看到过对consul的吐槽，记录下************************************************************************************************

导语在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需要一个注册服务的机制，注册某个服务或者某个节点是可用的，还需要一个发现服务的机制来找到哪些服务或者哪些节点还在提供服务。在实际应用中，通常还都需要一个配置文件告诉我们一些配置信息，比如数据连接的地址，redis的地址等等。但很多时候，我们想要动态地在不修改代码的情况下得到这些信息，并且能很好地管理它们。有了这些需求，于是发展出了一系列的开源框架，比如ZooKeeper,Etcd,Consul等等。这些框架一般会提供这样的服务：服务注册

主机名，端口号，版本号，或者一些环境信息。服务发现

可以让客户端拿到服务端地址。一个分布式的通用k/v存储系统

基于Paxos算法或者Raft算法领导者选举(LeaderElection)其它一些例子：

分布式锁(Distributedlocking)

原子广播(Atomicbroadcast)

序列号(Sequencenumbers)

…我们都知道CAP是EricBrewer提出的分布式系统三要素：

强一致性(Consistency)

可用性(Availability)

分区容忍性(PartitionTolerance)几乎所有的服务发现和注册方案都是CP系统，也就是说满足了在同一个数据有多个副本的情况下，对于数据的更新操作达到最终的效果和操作一份数据是一样的，但是在出现网络分区（分区间的节点无法进行网络通信）这样的故障的时候，在节点之间恢复通信并且同步数据之前，一些节点将会无法提供服务（一些系统在节点丢失的情况下支持stalereads）。ZooKeeper作为这类框架中历史最悠久的之一，是由Java编写。Java在许多方面非常伟大，然而对于这种类型的工作还是显得有些沉重，也正因为其复杂性和对新鲜事物的向往，我们第一时间就放弃了选择它。本文将从协议和应用层来比较Etcd和Consul，并最终给出了笔者的偏好。EtcdEtcd是一个使用go语言写的分布式k/v存储系统。考虑到它是coreos公司的项目，以及在GitHub上的star数量(9000+)，Google著名的容器管理工具Kuberbetes就是基于Etcd的。我们最先考虑的就是它。在介绍Etcd之前，我们需要了解一些基本的概念。我们知道在单台服务器单个进程中维护一个状态是很容易的，读写的时候不会产生冲突。即便在多进程或者多线程环境中，使用锁机制或者协程（coroutine）也可以让读写有序地进行。但是在分布式系统中，情况就会复杂很多，服务器可能崩溃，节点间的机器可能网络不通等等。所以一致性协议就是用来在一个集群里的多台机器中维护一个一致的状态。很多的分布式系统都会采用Paxos协议，但是Paxos协议难以理解，并且在实际实现中差别比较大。所以Etcd选择了Raft作为它的一致性协议。Raft是DiegoOngaro和JohnOusterhout在‘InSearchofanUnderstandableConsensusAlgorithm’中提出的。它在牺牲很少可用性，达到相似功能的情况下，对Paxos做了很大的优化，并且比Paxos简单易懂很多。它主要集中在解决两个问题：领导者选举(LeaderElection)

Raft先通过领导选举选出一个Leader，后续的一致性维护都由Leader来完成，这就简化了一致性的问题。Raft会保证一个时间下只会有一个Leader，并且在超过一半节点投票的情况下才会被选为Leader。当Leader挂掉的时候，新的Leader将会被选出来。日志复制(LogReplication)

为了维护状态，系统会记录下来所有的操作命令日志。Leader在收到客户端操作命令后，会追加到日志的尾部。然后Leader会向集群里所有其它节点发送AppendEntriesRPC请求，每个节点都通过两阶段提交来复制命令，这保证了大部分的节点都能完成。在实际的应用中，一般Etcd集群以5个或者7个为宜，可以忍受2个或者3个节点挂掉，为什么不是越多越好呢？是出于性能的考虑，因为节点多了以后，日志的复制会导致CPU和网络都出现瓶颈。Etcd的API比较简单，可以对一个目录或者一个key进行GET，PUT，DELETE操作，是基于HTTP的。Etcd提供watch某个目录或者某个key的功能，客户端和Etcd集群之间保持着长连接(longpolling)。基于这个长连接，一旦数据发生改变，客户端马上就会收到通知，并且返回的结果是改变后的值和改变前的值，这一点在实际应用中会很有用（这也是后面的Consul的槽点之一）。Etcd的watch和在一般情况下不会漏掉任何的变更。因为Etcd不仅存储了当前的键值对，还存储了最近的变更记录，所以如果一个落后于当前状态的watch还是可以通过遍历历史变更记录来获取到所有的更新。Etcd还支持CompareAndSwap这个原子操作，首先对一个key进行值比较，只有结果一致才会进行下一步的赋值操作。利用这个特性就像利用x86的CAS实现锁一样可以实现分布式锁。在Etcd中有个proxy的概念，它其实是个转发服务器，启动的时候需要指定集群的地址，然后就可以转发客户端的请求到集群，它本身不存储数据。一般来说，在每个服务节点都会启动一个proxy，所以这个proxy也是一个本地proxy，这样服务节点就不需要知道Etcd集群的具体地址，只需要请求本地proxy。之前提到过一个k/v系统还应该支持leaderelection，Etcd可以通过TTL(timetolive)key来实现。ConsulConsul和Etcd一样也有两种节点，一种叫client(和Etcd的proxy一样)只负责转发请求，另一种是server，是真正存储和处理事务的节点。Consul使用基于Serf实现的gossip协议来管理从属关系，失败检测，事件广播等等。gossip协议是一个神奇的一致性协议，之所以取名叫gossip是因为这个协议是模拟人类中传播谣言的行为而来。要传播谣言就要有种子节点，种子节点每秒都会随机向其它节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想要信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达。Consul使用了两个不同的gossippool，分别叫做LAN和WAN，这是因为Consul原生支持多数据中心。在一个数据中心内部，LANgossippool包含了这个数据中心所有的节点，包括proxy和servers。WANpool是全局唯一的，所有数据中心的servers都在这个pool中。这两个pool的区别就是LAN处理的是数据中心内部的失败检测，事件广播等等，而WAN关心的是跨数据中心的。除了gossip协议之外，Consul还使用了Raft协议来进行leaderelection，选出leader之后复制日志的过程和Etcd基本一致。回到应用层面上来说，Consul更像是一个fullstack的解决方案，它不仅提供了一致性k/v存储，还封装了服务发现，健康检查，内置了DNSserver等等。这看上去非常美好，简直可以开箱即用。于是，我们初步选定了Consul作为我们的服务发现和动态配置的框架。但现实往往是冰冷的，在深入研究它的API之后发现了比较多的坑，可能设计者有他自己的考虑。在使用获取所有services的API的时候返回的只是所有服务的名字和tag，如果想要每个服务的具体信息，你还需要挨个去请求。这在客户端就会十分不方便，因为在笔者看来，获取所有服务的列表以及具体信息应该是一个很常见的需求，并且请求的次数越少越好。如果watch服务是否有变化，当值发生改变的时候，返回的结果居然是相当于重新读取所有services，没有能够体现出服务信息的变化，这会导致客户端很难进行更新操作。健康检查是Consul的内置功能，在注册一个服务的时候可以加上自定义的健康检查，这听上去很不错。但是如果你忘记给你某个服务加上健康检查，那它在各种API的返回结果中变得难以预料。

…结语在折腾了数天之后，最终我们决定回归Etcd，事实证明这个决定是正确的。我们基于Etcd实现了稳定的服务发现和动态配置功能，当然还有一些比较细节的问题没有在文中阐述，欢迎一起探讨。

传输层安全(TLS)是SSL的继承协议。TLS是SSL的升级版。其工作方式与SSL极为相似，都是通过加密来保护数据和信息的传输。尽管SSL的应用仍然非常广泛，在业内这两个术语通常可以互换使用。

隧道协议（TunnelingProtocol）是一类网络协议，它是一种数据包封装技术，它是将原始IP包（其报头包含原始发送者和最终目的地）封装在另一个数据包（称为封装的IP包）的数据净荷中进行传输。使用隧道的原因是在不兼容的网络上传输数据，或在不安全网络上提供一个安全路径。隧道协议通常（但并非总是）在一个比负载协议还高的层级，或同一层。---------------------

备注：说白了，通过网络隧道技术，使隧道两端的网络组合成一个更大的内部网络。

终止协议意味着客户端使用期望的协议连接代理服务器，比如TLS或HTTP/2，然后代理服务器再去连接应用服务器、数据库服务器等，但不需要使用相同的协议，如下图所示。/2015-11-13_56455e89a4a1f.png

使用独立的服务器终止协议意味着使用多服务器架构。多服务器可能是多个物理服务器、多个虚拟服务器，或者AWS这样的云环境中的多个虚拟服务器实例。多服务器就比单服务器复杂，或者比应用服务器/数据库服务器的组合复杂。不过，多服务器架构有很多好处，而且很多流量大的网站也必须用这种架构。配置了服务器或者虚拟服务器之后，很多事情都成为可能。新服务器可以分担其他服务器的负载，可用于负载平衡、静态文件缓存和其他用途。另外，也可以让添加和替换应用服务器或其他服务器更容易。NGINX和NGINXPlus经常被用来终止TLS和HTTP/2协议、负载平衡。已有环境不必改动，除非要把NGINX服务器挪到前端。

Service实现了基于iptables的分布式负载均衡iptables是Linux防火墙工作在用户空间的管理工具，是netfilter/iptablesIP信息包过滤系统是一部分，用来设置、维护和检查Linux内核的IP数据包过滤规则。iptables可以检测、修改、转发、重定向和丢弃IP数据包。其代码已经内置于内核中，并且按照不同的目的被组织成表（table）的集合。表由一组预先定义的链(chain)组成，链包含遍历顺序规则。每一条规则包含条件匹配和相应的动作（称为目标），如果条件匹配为真，该动作会被执行。

谷歌计算引擎(GCE)

融数数据基于Kubernetes的微服务治理和构建平台.pdf

第一代监控：Zipkin+BraveDapper：小型ORM之王

pinpoint分布式性能监控工具(docker安装)在做性能压测的时候，你是不是有只能看到测试报告？在做性能压测的时候，你是不是想知道每一个方法执行了多长时间？Pinpoint几乎可以帮助你查看你想看到的每一个细节。

Pinpoint是什么？Pinpoint是一款全链路分析工具，提供了无侵入式的调用链监控、方法执行详情查看、应用状态信息监控等功能。基于GoogleDapper论文进行的实现，与另一款开源的全链路分析工具Zipkin类似，但相比Zipkin提供了无侵入式、代码维度的监控等更多的特性。Pinpoint支持的功能比较丰富，可以支持如下几种功能：服务拓扑图：对整个系统中应用的调用关系进行了可视化的展示，单击某个服务节点，可以显示该节点的详细信息，比如当前节点状态、请求数量等实时活跃线程图：监控应用内活跃线程的执行情况，对应用的线程执行性能可以有比较直观的了解请求响应散点图：以时间维度进行请求计数和响应时间的展示，拖过拖动图表可以选择对应的请求查看执行的详细情况请求调用栈查看：对分布式环境中每个请求提供了代码维度的可见性，可以在页面中查看请求针对到代码维度的执行详情，帮助查找请求的瓶颈和故障原因。应用状态、机器状态检查：通过这个功能可以查看相关应用程序的其他的一些详细信息，比如CPU使用情况，内存状态、垃圾收集状态，TPS和JVM信息等参数。Java在1.5引入java.lang.instrument，你可以由此实现一个Java

agent,通过此agent来修改类的字节码即改变一个类。

Pinpoint是一个分析大型分布式系统的平台，提供解决方案来处理海量跟踪数据。

Pinpoint,2012年七月开始开发，在2015年1月作为一个开源项目启动,是一个为大型分布式系统服务的n层架构跟踪平台。Pinpoint的特点如下:分布式事务跟踪，跟踪跨分布式应用的消息自动检测应用拓扑，帮助你搞清楚应用的架构水平扩展以便支持大规模服务器集群提供代码级别的可见性以便轻松定位失败点和瓶颈使用字节码增强技术，添加新功能而无需修改代码

无法识别从Node1发送的第N个消息和Node2接收到的N'消息之间的关系——Googledapper实现了一个简单的解决方案来解决这个问题。这个解决方案通过在发送消息时添加应用级别的标签作为消息之间的关联。例如，在HTTP请求中的HTTPheader中为消息添加一个标签信息并使用这个标签跟踪消息。

Pinpoint中的数据结构Pinpoint中，核心数据结构由Span,Trace,和TraceId组成。Span:RPC(远程过程调用/remoteprocedurecall)跟踪的基本单元;当一个RPC调用到达时指示工作已经处理完成并包含跟踪数据。为了确保代码级别的可见性，Span拥有带SpanEvent标签的子结构作为数据结构。每个Span包含一个TraceId。Trace:多个Span的集合;由关联的RPC(Spans)组成.在同一个trace中的span共享相同的TransactionId。Trace通过SpanId和ParentSpanId整理为继承树结构.TraceId:由TransactionId,SpanId,和ParentSpanId组成的key的集合.TransactionId指明消息ID，而SpanId和ParentSpanId表示RPC的父-子关系。TransactionId(TxId):在分布式系统间单个事务发送/接收的消息的ID;必须跨整个服务器集群做到全局唯一.SpanId:当收到RPC消息时处理的工作的ID;在RPC请求到达节点时生成。ParentSpanId(pSpanId):发起RPC调用的父span的SpanId.如果节点是事务的起点，这里将没有父span-对于这种情况，使用值-1来表示这个span是事务的根span。GoogleDapper和NAVERPinpoint在术语上的不同Pinpoint中的术语"TransactionId"和googledapper中的术语"TraceId"有相同的含义。而Pinpoint中的术语"TraceId"引用到多个key的集合。

作者：小清新同学

链接：/p/a803571cd570

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。Dapper和

Zipkin,Twitter的一个分布式系统跟踪平台,生成随机TraceIds(Pinpoint是TransactionIds)并将冲突情况视为正常。然而,在Pinpiont中我们想避免冲突的可能，因此实现了上面描述的系统。有两种选择：一是数据量小但是冲突的可能性高，二是数据量大但是冲突的可能性低。我们选择了第二种。

AgentId：64位长度整型

可能有更好的方式来处理transaction。我们起先有一个想法，通过中央key服务器来生成key。如果实现这个模式，可能导致性能问题和网络错误。因此，大量生成key被考虑作为备选。后面这个方法可能被开发。现在采用简单方法。在pinpoint中，TransactionId被当成可变数据来对待。

使用字节码增强技术，我们就不必担心暴露跟踪API而可以持续改进设计，不用考虑依赖关系。——就是可以瞎JB变了撒

针对PinPoint的扩展和改造：-通信机制异步化调整；-探针引导程序premain改造；-gRPC探针；

DDD领域驱动／CQRS读写分离／ES事件溯源这些前沿的时髦的技术理念汇聚在一次，落地到一套完整实现方案。这就是Axon

Command执行过程：Command通过mandhandling.CommandBus分发，其中DistributedCommandBus实现了分布式的派发，它可以适配SpringCloud.主要逻辑是通过

AggregateIdentifier做一致性HASH。确保次对同一个聚合根发到同一台机器，这样保证了缓存的命中。Aggregate本质上在应用内缓存了当前状态，如果该服务宕机。另一台机器会通过事件溯源重新构造出当前状态。Command的事务处理：Axon通过UnitofWork控制一致性，其中嵌入了JDBC事务。并且在回滚时会清除Aggregate缓存，下次会重新加载。当然对于远程的子事务无法保证一致性。这是个大的隐患Saga最终一致性，补偿机制。Saga的理念没问题，当是实现起来问题很大。一个是每个command都要创建event非常繁琐，并且saga来来回回非常多另一个是没有考虑到幂等，本地宕机，状态，分布事务等细节的处理。自己实现也不灵活确保分布式事务一致性是个非常繁琐的事情，请参考转账交易这件小事，是如何被程序员玩坏的.说说其他实现困难的情况如果Aggregate存在继承关系，或者实现一些通用的行为接口。框架并不支持无法实现延迟触发的功能对大量聚合实现批量操作不太容易几乎所有的操作都要靠command触发，然后转成event,非常繁琐。取其思想，寻找替代在交易中的订单模型，本质上就是ES中的Event.账户余额是用订单累加出来的。只不过订单不止记录事件。还用来记录更新审核状态，系统状态，事务状态等，不那么纯粹。通过订单回溯账户状态是个人工过程而不是自动的。在这方面，Axon对事件的存储采用统一的表，事件序列化到表中，并不有利于数据库的查看。需要额外的记录一个查询视图快照模型也在交易对账中有所体现。每日对账后生成当日的一个快照，第二天的交易从快照开始累计Command模型配合只insert没有update的操作，可以在高并发下实现无锁处理。这个可以通过Kafka。或者数据库先插入，后异步读取处理的方式来实现。充血模型是Axon的一个特色。不过并不难实现。通过自定义一个SpringCloudLoadBalancerRule实现哈希一致也可以实现。另外传统的失血模型使用无状态服务更简单，它可以在数据库层面通过一致性hash来存储数据，比如mongodb。对于订单这样的单一记录低频操作完全可以处理。对于同一记录的高频处理Axon也是有其优势的，不过Akka可能也是不错的选择Saga异常难写，在网络异常，幂等，重试方面并不友好总结：DDD领域驱动／CQRS读写分离／ES事件溯源，这些思想都很棒，但是并不用拘泥于特定的实现。Axon对于学习这些概念具有非常大的帮助，但是在实践的过程中并不高效、灵活

作者：黄大海

链接：/p/4a7854e4b8f2

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

Reveno是一个全新的无锁事务处理框架，它支持JVM平台，并基于CQRS及事件溯源模式实现。虽然它只是一个简单而强大的工具，但在性能方面也毫不逊色。所有事务都被持久化为只读的日志，并且可以通过按顺序重演事件的方式恢复领域模型的最新状态。所有的运行时操作都是在内存中执行的，从而使其吞吐量可达到每秒种几百万次事务的数量级，平均延迟时间则限制在微秒级。虽然Reveno的功能如此强大，但它仍然是一个通用目的的框架，涵盖了大量不同种类的用例，并提供了丰富的引擎配置选项。举例来说，你可以调整它的持久性配置，在极其随意（为了提高系统吞吐量）与高度受限（对于数据丢失的情况具有较低的容忍度）之间进行选择。对于不同的用例来说，其需求也是千差万别的。作为一个通用框架，它需要考虑所有不同的可能性。在本文中，我将通过示例为读者展现如何使用Reveno框架开发一个简单的交易系统。首先让我们来了解一下Reveno如何处理你的领域模型。作为一个基于CQRS的框架，Reveno会将你的领域切分为事务模型与查询模型。对这两个模型的定义没有任何限制，你无需使用任何强制性的注解、基类，甚至不需要实现Serializable接口，只需使用最简单的POJO就可以完成任务。没有任何一种单一的途径能够应对所有不同的用例，因此应用程序的设计者需要决定如何处理事务模型的回滚操作。Reveno为实现模型对象提供了两种主要方式：可变与不可变模型。这两种方式各有不同的底层处理机制，并且各有其优缺点。在Java中，不可变对象的开销很低，并且无需进行同步操作，这种方式目前非常流行。Reveno能够非常高效地处理不可变对象，但每种使用不可变类型的领域都会产生额外的垃圾对象，Reveno也不例外。因此，如果你能够接受一些额外的GC开销，那么就应当将这种方式作为默认的选择。反之，如果使用可变模型，那么在进行事务运行时，就要为已使用的对象生成额外的序列化快照，而这将影响到你的性能。幸运的是，如果你坚持使用可变模型，并且仍需要保证性能的最大化及GC影响的最小化，那么你可以选择一种额外的可变模型特性，“补偿行为”（CompensatingActions）。简单来说，补偿行为是指在实现常规的事务处理函数时，一并实现的一种手动回滚行为。如果读者想了解这方面的更多细节，请参考Reveno的官方文档页面。

Kubernetes

的核心概念讲解入门Kubernetes

是非常困难的，因为这会涉及到许多的概念和新理念，本文以图文并茂的形式总结了Kubernetes

中的核心概念。

它本不必如此困难？掌握Kubernetes

是非常困难的，因为互联网上有如此多的信息，有时候很难找到理解Kubernetes

的“核心”信息，当我们看到

kubernetes.io

站点上概念页面和文档如此密集时更会如此。在本文中，我们将会探索Kubernetes

的核心概念，以便于获取关于它的基础知识，这样我们就可以一起揭开Kubernetes

的神秘面纱。

什么是Kubernetes？Kubernetes

提供了基础设置和构造，帮助我们的团队构建适用于开发和部署的可用平台。用户可以通过图形化的用户界面以及命令式和声明式命令行接口管理Kubernetes

集群，Kubernetes

旨在管理容器化应用程序和服务的整个生命周期。借助Kubernetes，我们可以扩展和收缩应用程序、执行滚动部署并管理由哪些服务处理特定的请求。它还提供了一个可扩展的开发框架，允许我们的团队扩展核心的Kubernetes

原语（primitive）以满足个性化的需求。同时，它还支持创建自己的概念。但是，与大多数框架一样，它的缺点之一是缺少许多现成的功能，无法被视为交钥匙（turn-key）解决方案。在标准发行版中，它不包含服务如何相互通信的方法（甚至不包含网络组件!），因此存在其他的发行版，另外我们也可以构建自己的版本。容器容器是独立、可执行的软件，它包含了运行所需的所有内容，比如代码、库和所有的外部依赖。它会确保运行的内容是完全相同的，即便是位于不同的环境中也是如此。这是通过将要运行的代码与它的运行上下文隔离开实现的。在Linux

中，这是通过使用名为cgroups

的API

来分割Linux

内核的一个子集来实现的。这种方式提供了与操作系统的高度隔离，但不会带来像虚拟化环境（如VMWare、KVM

等）那样的性能损耗。

Podpod

是Kubernetes

中最基本的对象。pod

是容器的集合，它们共享存储和网络，并且具备如何运行它们的规范。每个pod

会分配自己的IP

地址。pod

中的容器会共享这个IP

地址、端口空间，并且能够使用localhost

实现彼此查找。pod

应该被视为短暂存活的原子单元。

Replicaset根据给定的模板，replicaset

可以运行n

个pod。replicaset

并不会直接使用，但是需要理解这种资源，因为在Kubernetes

构建应用的时候，它是基础的构建块。（按照指令）replicaset

可以按需扩展和收缩pod

的数量。

Service因为pod

是短期存活的（replicaset

通过扩展和收缩pod

的数量实现这一点），那么这就带来了一个问题，现在，除非使用非常复杂的逻辑，否则我们几乎不可能引用单个pod

以便于跟踪拓扑结构的变化。Service

通过在pod

之上提供抽象来解决这个问题，它提供了一个可寻址的方法来与pod

进行通信。Service

操作的是OSI

模型之中的“第4

层”（IP

之上的TCP/UDP）。

DeploymentDeployment

管理replicaset，可以在应用的不同版本间执行滚动更新。这是最常用的资源类型，它通过一个接口提供了对replicaset

和pod

的抽象。

在更新Deployment

的时候，换句话说，也就是部署应用的新版本，Deployment

控制器会创建一个新的replicaset，并管理新版本替换旧版本的滚动更新。

在Kubernetes1.11

版本中，Deployment

目前不会自动处理回滚。ConfigMap设计良好的应用应该遵循十二要素应用宣言，应用的配置应该保存到“环境”中。尽管现在通用的安全实践指出，在环境中存储配置可能会导致私密的意外泄漏，因为一些应用程序在失败时会暴露了它们的环境信息，但是无论如何，如果配置随环境（开发、staging、生产）而变化的话，那么就应该将它们与要构建的应用分开进行存储。ConfigMaps

允许将配置文件作为环境变量或文件系统挂载到Pod

中，从而解决了这个问题。

SecretSecret

与ConfigMap

非常类似，顾名思义，它们对应的是“Secret”信息。

DaemonsetDaemonset

会确保所有的节点都运行特定的Pod。如果要在所有节点上运行像日志代理（如fluentd）这样的内容的话，这是非常有用的。

它还能够通过使用Taints

忽略特定的节点。Kubernetes之Taints与Tolerations污点和容忍作者：Flywithmeto

2018-04-10

来源：51CTO

NodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

Taints(污点)是Node的一个属性，设置了Taints(污点)后，因为有了污点，所以Kubernetes是不会将Pod调度到这个Node上的，

于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。

因此

Taints(污点)通常与Tolerations(容忍)配合使用。

Ingress在大多数情况下，Service

和Pod

的IP

地址只能在Kubernetes

集群中进行访问。Service

是与互联网流量隔离的。“Ingress

是一组规则集合，它允许入站的连接访问集群Service。”它可以用于负载平衡、终止TLS、为外部提供可路由的URL

等等。Ingress

只是另外一种Kubernetes

资源，但是，在大多数情况下,

它需要有一个Ingress

控制器，如Nginx

或Træfik

等。Kubernetes

是一个自动化容器编排平台，能够允许应用程序在大型平台上大规模运行，这些平台可以包含不同处理器体系结构和操作系统的组合，这完全由实现者决定。借助这些核心概念，Kubernetes

可以将Pod

安排到适当的节点上，以确保Pod

的最大密度，这会由Kubernetes

实现的多种算法来控制，比如BinPacking，从而实现更高的硬件利用率。参考资料：[1]

/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b[2]

/google-cloud/kubernetes-configmaps-and-secrets-part-2-3dc37111f0dc[3]

https://kubernetes.io/docs/concepts/configuration/secret/[4]

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/本文最初发表于

云原生计算基金会

官方博客，由InfoQ

中文站翻译分享。KubernetesGitBook

https://kubernetes.feisky.xyz/he-xin-yuan-li/architecture

Kubernetes提供了两种探针（Probe，支持exec、tcp和http方式）来探测容器的状态：Kubelet使用livenessprobe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的情况下依然能够继续运行下去（谁的程序还没几个bug呢）。Kubelet使用readinessprobe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的loadbalancer中移除。

一个Kubernetes集群由分布式存储

etcd、控制节点controller以及服务节点Node组成。

Play-with-k8s提供了一个免费的k8s体验环境K8splayground

K8s借鉴了Borg->Omega的设计理念（谷歌），比如Pod、Service、Labels和单Pod单IP等。容器的资源隔离特性使得谷歌的资源使用率远远高出业界同行。例如，Borg使用容器将对延迟敏感、面向用户的任务和批量任务放在相通的物理机上，并会为它们预留更多的资源，这样可以解决loadspikes、fail-over等问题。容器提供的资源管理工具使这些得以实现，稳定的内核层面的资源隔离也使进程之间不互相干扰。我们通过在研发Borg的同时加强Linux容器的方式来获得成功。然而，隔离并不是完美的，容器在内核操作系统不能管理的资源隔离方面鞭长莫及，比如level3processorcaches、内存带宽、以及容器需要被一个额外的安全层支持以抵抗云端的各种恶意攻击。

Kubernetes主要由以下几个核心组件组成：etcd保存了整个集群的状态；kube-apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；kube-controller-manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；kube-scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；kubelet负责维持容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；Containerruntime负责镜像管理以及Pod和容器的真正运行（CRI），默认的容器运行时为Docker；kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；除了核心组件，还有一些推荐的Add-ons：kube-dns负责为整个集群提供DNS服务IngressController为服务提供外网入口Heapster提供资源监控Dashboard提供GUIFederation提供跨可用区的集群Fluentd-elasticsearch提供集群日志采集、存储与查询分层架构：Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）——（k8s实践利用storageclass实现pvc的动态provision(volume使用cephrbd)）——存储(Storage)是运行有状态容器的关键要素，Kubernetes提供了强大的原语来管理存储。动态卷配置(Dynamicprovisioning)是Kubernetes的独有功能，它可以根据需要动态的创建存储卷。在动态配置之前，集群管理员必须手动调用云/存储服务提供商的接口来配置新的存储卷，然后创建PersistentVolume对象以在Kubernetes中表示和使用他们。通过动态配置，可以实现两个步骤的自动化，无须集群管理员预先配置存储资源，而是使用StorageClass对象制定的供应商来动态配置存储资源，具体请参考用户指南）。StorageClass本质上是为底层存储提供者描绘了蓝图，以及各种参数，例如磁盘类型（例如固态和标准磁盘）。——QuotaResourceQuotas资源配额（ResourceQuotas）是用来限制用户资源用量的一种机制。它的工作原理为资源配额应用在Namespace上，并且每个Namespace最多只能有一个

ResourceQuota

对象开启计算资源配额后，创建容器时必须配置计算资源请求或限制（也可以用

LimitRange

设置默认值）用户超额后禁止创建新的资源开启资源配额功能首先，在APIServer启动时配置准入控制

--admission-control=ResourceQuota然后，在namespace中创建一个

ResourceQuota

对象资源配额的类型计算资源，包括cpu和memorycpu,limits.cpu,requests.cpumemory,limits.memory,requests.memory存储资源，包括存储资源的总量以及指定storageclass的总量requests.storage：存储资源总量，如500Gipersistentvolumeclaims：pvc的个数.storageclass.storage.k8s.io/requests.storage.storageclass.storage.k8s.io/persistentvolumeclaimsrequests.ephemeral-storage和limits.ephemeral-storage（需要v1.8+）对象数，即可创建的对象的个数pods,replicationcontrollers,configmaps,secretsresourcequotas,persistentvolumeclaimsservices,services.loadbalancers,services.nodeports——PSP：Pod安全策略；——接口层：kubectl命令行工具、客户端SDK以及集群联邦生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等Kubernetes内部：CRI、CNI、CVI、镜像仓库、CloudProvider、集群自身的配置和管理等——OTS：offtheshell？——

核心组件：核心API：

生态系统：Etcd是CoreOS基于Raft开发的分布式key-value存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。

DaemonSet保证在每个Node上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：日志收集，比如fluentd，logstash等系统监控，比如PrometheusNodeExporter，collectd，NewRelicagent，Gangliagmond等系统程序，比如kube-proxy,kube-dns,glusterd,ceph等

PersistentVolume(PV)和PersistentVolumeClaim(PVC)提供了方便的持久化卷：PV提供网络存储资源，而PVC请求存储资源。这样，设置持久化的工作流包括配置底层文件系统或者云数据卷、创建持久性数据卷、最后创建PVC来将Pod跟数据卷关联起来。PV和PVC可以将pod和数据卷解耦，pod不需要知道确切的文件系统或者支持它的持久化引擎。

Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了Service资源，并通过kube-proxy配合cloudprovider来适应不同的应用场景。随着kubernetes用户的激增，用户场景的不断丰富，又产生了一些新的负载均衡机制。目前，kubernetes中的负载均衡大致可以分为以下几种机制，每种机制都有其特定的应用场景：Service：直接用Service提供cluster内部的负载均衡，并借助cloudprovider提供的LB提供外部访问IngressController：还是用Service提供cluster内部的负载均衡，但是通过自定义IngressController提供外部访问ServiceLoadBalancer：把loadbalancer直接跑在容器中，实现BareMetal的ServiceLoadBalancerCustomLoadBalancer：自定义负载均衡，并替代kube-proxy，一般在物理部署Kubernetes时使用，方便接入公司已有的外部服务

网络插件：https://kubernetes.feisky.xyz/cha-jian-kuo-zhan/network

Cilium是一个基于eBPF和XDP的高性能容器网络方案，提供了CNI和CNM插件。

Frakti是一个基于KubeletCRI的运行时，它提供了hypervisor级别的隔离性，特别适用于运行不可信应用以及多租户场景下。Frakti实现了一个混合运行时：特权容器以Dockercontainer的方式运行而普通容器则以hypercontainer的方法运行在VM内

服务治理：

一般准则分离构建和运行环境使用dumb-int等避免僵尸进程不推荐直接使用Pod，而是推荐使用Deployment/DaemonSet等不推荐在容器中使用后台进程，而是推荐将进程前台运行，并使用探针保证服务确实在运行中推荐容器中应用日志打到stdout和stderr，方便日志插件的处理由于容器采用了COW，大量数据写入有可能会有性能问题，推荐将数据写入到Volume中不推荐生产环境镜像使用latest标签，但开发环境推荐使用并设置imagePullPolicy为Always推荐使用Readiness探针检测服务是否真正运行起来了使用activeDeadlineSeconds避免快速失败的Job无限重启引入Sidecar处理代理、请求速率控制和连接控制等问题

分离构建和运行环境注意分离构建和运行环境，直接通过Dockerfile构建的镜像不仅体积大，包含了很多运行时不必要的包，并且还容易引入安全隐患，如包含了应用的源代码。可以使用Docker多阶段构建来简化这个步骤。

COW：copyonwrite技术

https://juejin.im/post/5bd96bcaf265da396b72f855写入时复制（英语：Copy-on-write，简称COW）是一种计算机程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private