kube-scheduler 运行在 Kubernetes 的管理节点(Master 节点)上,负责完成从 Pod 到 Node 的调度过程。Scheduler 会跟踪集群中所有 Node 的资源利用情况,并采取合适的调度策略,确保调度的均衡性,避免集群中的某些节点过载。
一言以蔽之,kube-scheduler 用来为 Pod 找到一个合适的 Node。
kube-scheduler 运行在 Kubernetes 的管理节点(Master 节点)上,负责完成从 Pod 到 Node 的调度过程。Scheduler 会跟踪集群中所有 Node 的资源利用情况,并采取合适的调度策略,确保调度的均衡性,避免集群中的某些节点过载。
一言以蔽之,kube-scheduler 用来为 Pod 找到一个合适的 Node。
kube-proxy 运行在 Kubernetes 集群的计算节点上,负责 Service 的负载均衡及服务代理。
最近在看 KubeCon 的视频,囫囵吞枣,感觉吸收了不到一成,但是感觉功力大增。
看 KubeCon,可以学习跟 Kubernetes 相关的各种解决方案,了解 CNCF 下的各个项目的进展,跟着核心开发者深入每个子项目的架构,原理,这些自然不用说,更有意思的一点是,可以通过这个窗口看到世界各地各行各业的动态,这是 KubeCon 特别的地方,因为 Kubernetes 是基础架构,来宣讲的基本都是架构师,布道师,这和 React Conf 之类的专注于一个技术点的会议是不一样的。举个例子,有一个分享是欧洲的一个公司借助 kube-scheduler 议题向大家介绍他们公司的案例,他们把服务器安装在每一户的家里,将这些机器组成一个 Kubernetes 集群,当集群运行一个 job 时,服务器就会加热,用户使用热水时就能省电,平时在家里也可以起到增温的作用,而他们公司也可以省一些机房,电费等运维费用,他们的工作内容就是借助这个 Kubernetes 集群,通过自定义调度算法,增加整个系统的利用率。对于这种系统,以前我也略有耳闻,在真的看到这样的公司的分享时,还是觉得奇妙有趣,好像思路打开了一样,同时,我还学习了怎么写一个自定义的 Kubernetes 调度算法,这样的分享怎么可能不讨人喜欢呢。
这么多视频,你要问我记住了多少?呵呵呵呵
在 Kubernetes 发展初期,部署 Kubernetes 一直是一件让初学者头疼的事情,Kubernetes 也开始重视这个问题,2017年,在社区志愿者的推动下,社区发起了一个独立的部署 Kubernetes 的项目,kubeadm。
经过一年多的发展,kubeadm 已经可以一键式进行 Kubernetes 集群的快速初始化和安装,极大地简化了部署过程。值得一提的是,在很长一段时间里 kubeadm 有个比较欠缺的地方是无法做到一键部署一个高可用的 Kubernetes 集群,这是 kubeadm 目前的工作重点,好在这个功能已经在 1.11 版本刚刚发布,可以参考 Creating Highly Available Clusters with kubeadm。
长轮询(long polling) | Webhook | |
---|---|---|
简述 | 利用 API 中的 getUpdates 方法, 如果 Bot 上次标记完成后没有收到信息,或消息已保存超过24小时,该方法会保持等待直到超时,在等待期间收到信息将会立刻返回结果;反之,该方法会返回一组包含了24小时内所有未标记信息的 Updates。利用 offset 参数可以将部分消息标记为已处理。 | 利用 setWebhook 方法告知服务器一个 url, 服务器将会在收到新消息时,通过 POST 方法将 json 格式的 Update 对象发送到指定的 url 地址。如果发送失败,Telegram 会重试一定次数。这个 url 必须是 https 的。 |
性能 | 没法做负载均衡,数据量比较大的情况话,性能瓶颈可能出现在 worker 上。 | 与传统服务器没有太大差异,可以做负载均衡(高可用),可以横向扩展。未来可以对接 Serverless,可扩展性更强 |
开发效率 | 不需要搭建服务器,不需要处理 https 证书,有一个机器人的 token 就可以在本地开发 | 在不搭建服务器的情况下,可以用 google script 开发,但只能用类 Javascript 语言。如果要用其他语言开发,需搭建服务器,需 https |
交互体验 | 响应速度较 Webhook 慢 | 响应速度取决于网络延迟,体验一般比长轮询好 |
结论:如果追求开发速度,并且不需要考虑服务的高可用性,在可预知用户量不会增长过快的情况下,建议使用长轮询的方式,未来用户增长比较多再改也来得及,否则用 Webhook 的方式。如果对交互体验要求高的话,最好采用 Webhook 的方式。
阅读这部分代码之前需要对 Solidity 里的事件,以太坊的日志有所了解。
前面的文章 go-ethereum 源码笔记(core 模块-世界状态,交易收据管理) 讨论了 geth 中对交易的处理,其中有一个阶段需要通过 EVM 执行,如果交易转入方地址为空,则调用 EVM 的 Create 函数创建合约;如果不为空,则为普通转账,调用 Call() 函数。这一篇我们将深入以太坊的虚拟机看看具体的过程。
这一篇需要对智能合约, ERC-20 标准,编译原理(了解编译器,解释器,虚拟机等概念),计算机组成原理(了解基于栈的虚拟机与基于寄存器的虚拟机的区别)有所了解。
通过前面的文章,我们了解了 geth 的大致原理,知道了区块链是怎么组织构成的,有了 rlp,MPT 这些数据结构的基础,也知道了账户是怎么组织的,交易是如何管理的,挖矿是一个什么样的流程,这一篇我们将深入到交易的具体处理过程,看看交易过程中是如何修改世界状态,生成交易收据的。
这篇文章将涉及到 core/types/transaction.go
, core/state
模块,需要对交易池,账户等基本概念有所了解。
通过前面的文章,我们知道了有工作量证明的区块链是怎么构建的,然而区块链一直在内存中当然是不行的,我们需要将区块链持久化到数据库中。
前面的章节 go-ethereum 源码笔记(core 模块-区块链操作) 描述了区块链世界的核心:区块,区块链。我们已经知道区块链可以用来存储交易的数据,也知道了如何在区块链里发起一笔交易,而问题是,往区块链中增加数据应该是一个较困难的操作,按照比特币论文里的说法,即需要一个 PoW(Proof of Work,工作量证明),否则每个人都能轻易往区块链中增加数据,安全性和一致性无法保证。这一点上,以太坊法和比特币类似,尽管略有不同,但大致都需要矿工的角色贡献计算力,完成一个复杂的计算,即找到一个区块的哈希值,验证正确之后才能加入到区块链中。这个过程就叫做挖矿。矿工们去做这件事当然是有一定利益驱使的,每完成一次挖矿,他们就能获得一些以太币奖励。