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