Devops

Coral生态以及技术 References: Coral AI 介绍下google coral edge TPU computing整个生态： 用于生产环境的SoM以及带PCI接口的加速器。 用于开发测试的四款口袋型开发板。 外围传感器包括环境检测模块以及摄像头，Wi-Fi/PoE扩展板。 Cloud TPU / Edge TPU 介绍 技术 Coral Edge TPU是谷歌为加速边缘设备神经网络推理而研发的专用芯片，并且在保持低功耗的前提下运行专门优化过的神经网络模型。 Edge TPU 运行速度为4 Tops，并且功耗为0.5W/Tops，相当于如果Edge TPU全天满负荷运行，那么一天的功耗总共为48WH，这样对于工业环境的要求，低功耗绝对是一个优势。上图为嵌入式CPU和Edge TPU推理速度的比较，可以看出在edge TPU上运行时间远远低于embedded cpu，降低功耗但保持模型推理的准确度并且加速运算，这就是edge tpu在工业领域的优点。 可扩展性 Coral产品线包括最初的原型设计开发板，到产品PCI edge TPU模块，最后再到微控制器micro dev board，整个生态链都有供应，缺点就是由于芯片限制的原因在中国很难买到，国外因为生产原因的关系，也需要时刻关注供应商的库存。像我之前购买的Environmental Sensor Board是通过HK代购进入中国的，还有micro dev board是通过pi3g供应商从EU发货到达国内的。 模型兼容 edge TPU可以运行tensorflow以及keras构建的模型，当然模型需要转换成int8 tensorflow lite ，这一步称之为quantized，这样就可以降低模型在edge device上内存的开销，然后tflite模型通过edge tpu compiler的编译，最后运行在edge tpu上。 Mendel Linux Coral Dev Board和Coral Dev Mini Board以及SOM都可以运行google自己维护的Mendel Linux，系统的缺点就是独立性太强，使用的linux内核是4.x系列，比起raspberry pi生态，coral的内核已经相当老旧了，并且无法使用linux内核的新功能，而像raspberry pi官方一直支持Linux内核到6.x系列。在编程接口方面，google提供了，pycoral + libcoral，还有shell命令行工具MDT。 Coral Micro ...

我自己设计了一套简陋的k8s persistentvolumeclaims方案，后端采用Moosefs做为分布式数据存储，原理是基于kubernetes events机制，当接收到create pvc的消息时，后台control应用会在moosefs上创建对应的pv，并绑定相应的pvc，为了方便应用在各个节点间移动，我将moosefs文件系统挂载到了每一个worker节点下，这里就产生了一个问题：如何保证moosefs master高可用！moosefs官方有两个版本一个是opensource，另外一个是Pro，Pro版本自带HA功能，而opensource只有备份master的功能，当出现故障时只能通过手动恢复master。为了满足高可用的需求，我申请了Pro版本为期一个月的使用权限，购买永久授权官方价格是1425EUR/10TBi，其中包括了一年的维护费570EUR，这个价格对于我个人使用Raspberry Pi来说实在过于昂贵，并且我测试了mfsmaster pro的性能，发现和opensource版本相比没有显著的提升，考虑到mfsmaster是单线程应用，我决定以后自己维护一套mfs源码，增加它在kubernetes上的功能。这样经过调研，我发现了mfs master高可用的方案（上图所示）。 MFS Opensource Master HA 总共分为三部分： mfsmaster DRBD Keepalived mfsmaster：存储mfs的元数据。 DRBD：实现网络层块设备的实时复制，类似RAID 1。 Keepalived：监控两台mfsmaster的健康状况。 当mfsmaster A出现异常时，keepalived会将VIP迁移到mfsmaster B上，并将A由原先的master变成backup，同时卸载mfs metadata的DRBD USB磁盘，将B由原先的backup变成master，同时挂载mfs metadata的DRBD USB磁盘，启动mfsmaster，这样就完成了故障节点的恢复。 在使用moosefs之前，我测试过openebs，longhorn，beegfs，glusterfs这些分布式文件系统，对比了它们之间的性能和易用性，最终还是选择了moosefs，因为mfs的扩展实在是太方便了，并且客户端是通过fuse访问文件系统，像macos，freebsd，netbsd都可以使用，在ARM64平台上的读写性能也是优于其他几个分布式文件系统的。当然最后的缺点是官方好像停止维护mfs v3版本了（github一直没有更新），v4版本仍然处于闭源状态。

今天我将自运营的kubernetes生产环境集群升级到了v1.25.0，升级过程中遇到了一个问题，集群中使用了PodSecurityPolicy，然而在kube v1.25.0中PodSecurityPolicy已经被移除，并且被pod security admission(psa)取代。于是我需要将PodSecurityPolicy合并到psa中。对此我对psa进行了一些调研。 PSA在v1.25.0版本中已经被定义为稳定接口，并且默认开启了PodSecurity控制器。PSA控制器将pod强制在一个特定权限的环境中运行，通过在namespace中创建权限规则，该namespace下的所有pod对宿主环境的访问将被限制在该权限之下。 pod security 级别分为： privileged：拥有系统级别的特权 apiVersion: v1 kind: Namespace metadata: name: my-privileged-namespace labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/enforce-version: latest baseline：基础权限，满足大部分pod的运行时权限 - 详细阅读 apiVersion: v1 kind: Namespace metadata: name: my-baseline-namespace labels: pod-security.kubernetes.io/enforce: baseline pod-security.kubernetes.io/enforce-version: latest pod-security.kubernetes.io/warn: baseline pod-security.kubernetes.io/warn-version: latest restricted：非常严格的限制权限 - 详细阅读 apiVersion: v1 kind: Namespace metadata: name: my-restricted-namespace labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/enforce-version: latest pod-security.kubernetes.io/warn: restricted pod-security.kubernetes.io/warn-version: latest kubernetes 控制器通过给namespace标记标签来定义pod的权限级别，其中的security mode分为enforce，audit，warn。 Enforce：违反权限级别的pod将被拒绝运行 Audit：违反权限级别的pod的信息将被记录到审计日志中，但照常运行 Warn：有违反权限级别的pod，集群只发出警告 具体定义如下： # The per-mode level label indicates which policy level to apply for the mode. # # MODE must be one of `enforce`, `audit`, or `warn`. # LEVEL must be one of `privileged`, `baseline`, or `restricted`. pod-security.kubernetes.io/<MODE>: <LEVEL> # Optional: per-mode version label that can be used to pin the policy to the # version that shipped with a given Kubernetes minor version (for example v1.25). # # MODE must be one of `enforce`, `audit`, or `warn`. # VERSION must be a valid Kubernetes minor version, or `latest`. pod-security.kubernetes.io/<MODE>-version: <VERSION>

这是我目前使用的内容管理平台的架构，前端的两台google comput engine 用于连接全球互联网以及托管静态站点，后端的集群全部运行在自己托管的ARM64系统平台上，集群内部运行着Cloudflared隧道，当用户请求invisibleart时，请求会通过cloudflare edge network发送到隧道中，cloudflared会将请求发往目标地址wordpress engine，后端的数据库采用的是vitess mysql集群，前期使用过tidb，发现与wordpress存在兼容性问题，最后决定使用vitess，在备份，扩容，和灾难恢复中，vitess还是非常可靠的。

2018年我以Devops的职位加入了sparkpool团队之后，扩宽了我对数字加密货币的认知，在这接近四年的工作中，我在sparkpool学习了数字金融与传统金融体系的相关知识，什么是健全的货币体系，加密货币与传统货币的区别，可以这么说，在sparkpool我学到了大量的金融知识，同时也在工作之余自学了前沿科技的相关技术，比如深度学习和量化交易，虽然自己还没有做出一套完整的相关产品，但我一直在朝着这个方向努力。非常庆幸自己能够加入sparkpool大家庭，在此感谢sparkpool的两位创始人。最后的最后，聚是一团火，散是满天星。

Reference TIDB architecture 为什么使用 TIDB 机器采用的架构是ARM64。 尝试使用分布式数据库架构。 解决高可用问题，当一台Raspberry Pi数据库节点宕机时，不会影响数据的写入。 对比了vitess和TIDB，TIDB更加兼容ARM64，容易上手实验。 为后面的金融交易系统作准备。 架构 组件及功能 TIDB Server TIDB Server 是一个无状态应用，它本身并不存储数据，前面可以放置负载均衡，外部应用请求到TIDB Cluster中的节点，TIDB server将分析和计算应用请求的SQL，并将请求转发给底层的数据存储TiKV。 PD Server 整个TiDB集群的元信息管理模块，存储每个TiKV节点的数据分布情况，以及集群的整体拓扑情况，根据TiKV节点实时上报的数据分布状态，PD server向TiKV节点发布数据调度命令。 Storage Server TiKV 负责数据存储，是一个提供事务的key-Value分布式存储引擎，存储的基本单位是Region，每个Region存储一个Key Range的数据，每个TiKV节点会负责多个Region，TiDB的SQL对SQL做完解析后，会将SQL的执行计划转化为对TiKV API的实际调用，所有的SQL数据全部存储在TiKV中。 TiFLASH Server 特殊的存储节点，数据存储是以列式的方式进行存储，主要功能式为分析型的场景加速。

本文图片来源Openebs 前言 关于 OpenEBS OpenEBS是一个运行在Kubernets上的开源存储项目，符合CAS(Container Attached Storage)架构， 它的所有组件全部运行在用户层，属于在k8s上云原生的分布式文件系统。 OpenEBS文件系统提供如下类别的特性，每个特性都可以用于某个特定环境下的解决方案。 cStor: 支持容错，高可用性，副本拷贝，支持快照，克隆等技术，其后端是由ZFS支持。 Jiva: 后端引擎为年轻的Longhorn，支持容错，副本拷贝，但没有cStor的快照和克隆技术。 Dynamic Local PV HostPath: 直接使用本地文件存储，优点是低延时，缺点是不支持高可用，一旦本地节点宕机或者本地磁盘损坏，则导致数据丢失， Dynamic Local PV Devices: 和HostPath类似，直接使用本地的硬盘进行存储，缺点也是无法支持高可用，但是低延迟。 Dynamic Local PV ZFS: 不支持高可用，但可以使用ZFS的功能(制作快照和克隆技术)，从而提升数据的保护能力，便于从灾难中恢复数据。 特性(Features) CAS 架构: PV和PVC都是容器化的，便于kubernets进行管理。 同步副本: 当采用cStor Jiva Mayastor存储引擎时，实现多副本同步拷贝，从而提供数据的高可用冗错机制。 快照和克隆: 采用cStor存储引擎时，支持写时复制快照技术，生成快照有助于我们可以回滚数据，克隆可以快速的生成一套生产环境数据以便开发在测试环境使用真实的生产数据。 备份和恢复: 使用备份工具及插件，快速的备份文件和恢复文件。 监控: openebs 组件会提供Metric接口，从而方便prometheus对其监控，进而调优整套存储方案的性能。 Alpha特性 支持ARM64，这也是我目前在使用的原因，自己在组建一套7*24小时运行的Polkadot委托节点，因为直接和收益挂钩，所以我调研了很多容器化的存储架构方案，虽然Openebs性能不如其他的老牌分布式存储系统，像Ceph，glusterfs这样的，但是它提供的CAS架构和高容错机制，以及支持ARM64，就让我决定选择它用于金融行业的云存储架构方案。 架构 基于单一服务的PV架构 整个PV的底层读写操作全部在内核层面完成，Kubernets只是增加了一层抽象，将PV通过底层的分布式文件读写接口导出到用户层，Pods通过PVC与PV绑定进行数据的读写处理。 基于微服务的PV架构 典型的CAS架构，数据的读写操作全部在用户层处理，CAS架构中的副本拷贝以及存储控制器全部由kubernets自身来进行调度，PV直接从CAS控制器的底层资源中获取存储设备，Pods通过PVC与PV绑定，从而完成数据的读写处理。 None CAS 与 CAS 对比 CAS的优势: 更加敏捷，可以直接在Pods层面去优化存储控制器。 更加精细的监控，能够直接监控到每一个Volume的IOPS，读写延迟。 解耦合，不依赖于第三方的云存储系统，比如你可以不改变yaml文件的情况下，将应用从一个集群，迁移到另一个集群，如果采用None CAS，则会非常依赖对于Kubenets不可见的存储管理系统，迁移过程中需要修改yaml文件中关于PV的描述。 云原生，好处就在于能够直接与其他系统对接，比如文件系统监控，管理，采用Kube CRD的方式直接调用底层的存储系统。 微服务架构 采用微服务的方式极大的提高了分布式文件系统的高可用性，因为整个存储的服务全部运行在用户层，每一个服务都可以从一个节点迁移到另外一个节点，只要我们满足副本的可用性，即使某一个节点宕机也不会影像我们线上的数据访问，保证系统的可用。 从上图中，我们可以看出Storage Controller直接管理底层的副本处理的相关Pods，应用层的Pods通过PV与Storage Controller沟通。 ...

题外话 为什么深度学习有这么强大的功能，这背后我们可以想到人类的大脑神经元，单个神经元不能起到任何作用，但是一堆神经元在一起的力量是无穷的。 观看一部关于生命体中细胞和蛋白质都是怎么运作的，我们会非常惊讶为什么小小的微观世界会以如此精妙的方式运作。 Inner Life Of A Cell - Full Version 有时候想到上面的问题，自己就有点冲动，想去了解更多关于这个世界是如何运作的知识，人与人之间的沟通交流是否可以类比成分子间的相互作用，为什么一堆神经元组成在一起就可以造就智慧的生命体，这种生命体的自由意识是如何形成的，神经元之间的信息传递是如何编码的，在深度学习领域是否还能继续利用大脑神经元的某些特点来增强模型的设计。 为了解开这些困惑的问题，开阔自己的见识，我买了四本重要的外文书籍。 关于引力理论的探索 有关基因与遗传方面的介绍 神经理论科学 分子机器理论 这里的每一本书或许都可以帮助我们在深度学习领域里走得更远。 最低价格看Oreilly动物书 因为工作原因需要购买programming Kubernetes这本书，我在国内找了好几家线上书店，价格都非常贵，基本上一本就要600RMB，自己又不想使用盗版书籍，所以就想办法能不能通过第三方渠道低价格去看这些技术书，于是就有了下面的解决方案。 购买途径 注册ACM会员，ACM全称是Association For Computing Machinery 国际计算机协会，进入发展中国家会员注册，在国家里面选择中国，然后按照流程注册即可，最后支付年费就可以了。 目前的费用表单: 如果只是为单纯的获取电子刊物信息，可以选择最基本的170RMB。 注册完成之后我们就可以进入动物园看书了。 访问ACM Learning Center 点击右上角的O’Reilly就可以登入到O’Reilly上在线查看和学习各种新技术的书籍，因为新技术一直会更新迭代，如果纯粹是为了学习一门新技术，那么还是建议购买电子书，外文纸质书一般都比较贵，省下的钱可以考虑买经典的纸质书，就像我上面列举的那四本，经典的永远不会过时。

Kubernets Wiki 最近看了Large-scale cluster management at Google with Borg，Borg是谷歌公司自己内部开发的一套集群管理系统，后来开源社区也就慢慢开始孵化和推出了Kubernets集群管理系统，k8s和Borg有着很深的渊源关系。 先从Kubernets入手，我们来看下K8s的组件: Kubelet 在每一台节点上都会运行Kubelet，管理节点上的容器。 kube-apiServer 验证和配置关于Pods,Services,ReplicationControllers等数据，其他kube都需要通过调用api来获取所需的数据。 kube-Controller-Manager 用于控制系统的状态，通过API接口来同步系统数据，比如将系统从A状态同步更新到B状态。 kube-proxy 运行在每一台的节点上，主要作用充当网络代理，能够简单的处理TCP UDP 转发和轮询。 kube-scheduler 用来调度Pods，当有新的Pods需要创建时，调度器会给每一台工作节点打分，然后将Pods分配到满足要求的节点上。 然后再看关于Borg系统的描述，每一个集群都称之为一个Cell，每一个Cell都运行在一个独立的数据中心里。 Borg 架构 Borg 设计准则主要是以下三点: 隐藏对系统底层资源的管理以及容错处理，方便开发者将注意力集中在开发上，而不过多注意底层细节。 系统中运行的应用都是高可用的，某台节点的宕机，不会引起服务的不可用。 必须非常高效的在数万台节点上完成对应用的扩展。 Borg的用户基本上是google内部开发人员和SRE，正是因为google注重对SRE的发展，才慢慢在google内部形成了上述三点的认知体系，提到google SRE不得不提GOOGLE SRE How Google Runs Production Systems这本书，我只看过中文版，看完英文版之后会写一篇博客专门详细讨论这本书里的内容。 集群设计架构 Borg系统有一套自己的配置文件语法体系BCL，然后通过borgcfg加载到基于Paxos的分布式数据库存储中，在k8s中我们是通过编写Yaml状态配置文件，然后使用kubectl将状态配置通过kube-api接口提交到后端分布式ETCD存储中，在边缘设施的k8s场景中，像k3s，microk8s会默认使用基于SQL的数据库引擎Dqlite，dqlite也采用了Raft一致性存储协议，这样就可以做到边缘设备上的k8s高可用。 在Borg系统中，SRE工程师大部分通过Borgctl命令行工具对系统进行访问和修改。 Borg的核心组成部分有Scheduler，BorgMaster，Paxos Datastore，LinkShard，Borglet。 BorgMaster: master分为两部分，第一部分是对外处理请求，比如RPC调用获取集群状态，任务分配信息，获取borglet的状态，第二部分是用于处理集群内部的任务调度模块，master 支持高可用，所有的数据都是通过基于Paxos的数据库进行存储，当前master leader宕机之后，master 副本中会选举出新的master节点继续对外提供服务。最引人注目的是，master节点的数据存储使用了CheckPoint技术，每隔一段时间，系统都会自动保存当前的状态到checkpoint中，这样在集群发生问题的时候，我们就能将集群回退到前一个正常的checkpoint的状态，并且在线下使用这些point来做debug。 BorgScheduler: 当任务通过master提交之后，master会将数据存储到paxos中，并且将任务放到待处理队列中，Scheduler会根据这些任务的优先级进行先后处理，Scheduler拿到任务之后，计算哪些机器是符合要求的，根据一定的打分算法给这些机器打分，再根据分数将任务分配到对应的节点上。 Borglet: 运行在每一台节点上，用于管理任务的生命周期，比如停止运行重启，维护操作系统的内核配置，borgmaster会定期去拉取let上的状态信息，如果let没有应答那么master就认为这个对应节点已经下线或者宕机。 Jobs&&Tasks: Borgs运行的对象以Jobs Tasks来进行管理，一个Job可以由多个Tasks组成。以下是任务的生命周期。 当任务被提交到Borg Master时，如果任务被master接受则会进入Pending状态，等待Scheduler进行调度，调度完成之后，组成job’s Tasks就开始运行，如果超出系统的资源限制，Tasks就会被Evicted，然后进入Pending状态，继续等待被调度到新的节点上，当Tasks运行结束，任务的状态会被更新为Dead，有点像进程的生命周期，整个主干过程就是 Create -> Pending -> Scheduling -> Runing -> Dead。 然后我们看下k8s整个架构以及任务的调度是如何完成的，可以与Borg对比，发现两者的优缺点。 ...