2020年4月14日，Github 发布了一项重大的决定（福利），所有人都可以免费的使用私有协作仓库了。相比1年之前的免费的私有仓库（有人数限制），这次放开了人数限制，所以针对一些小型团队算是不错的福利了。当然如果需要使用更多的高级特性，类似代码所有者功能，SAML等，还是需要花费的，具体详情可以查看Github 官博。

Kubernetes 组件和架构介绍

Kubernetes 组件

一个 Kubernetes(k8s) 集群的基本构成采用的主从方式，包含 Master Node（主节点） 和 Worker Node（从节点）

Master 节点

主节点属于 K8s 的控制平面，掌管着集群的全局调度，集群的事件的检测和处理等。主节点内部包含若干组件，尽管每个组件本身可以在集群中任意一台机器上运行，启动脚本为了简化，将组件部署在同样的一台机器上，为了保证集群的高可用，集群环境一般包括多个主节点。下面简单梳理一下主节点的各个组件构成：

• kube-apiserver

  kuber-apiserver 是 k8s 控制平面的前端，对外提供 API 服务，可以方便的水平扩展

• etcd

  为 k8s 集群数据的提供一致性高可用 K, V 存储

• kube-scheduler

  负责将 pod 调度到合适的 Worker Node 上，调度综合考虑，硬件，软件，策略限制，亲和性设置，数据本地化，不同负载之间的干扰等

• kube-controller-manager

  控制器主要是主节点对于从节点管理，服务层面的鉴权，服务端点维护等，包括：

  • Node Controller：负责从节点失效的监测和处理
  • Replication Controller： 维护 Pod 服务数量的一致性
  • Endpoints Controller： 服务端点的变化相关的维护
  • Service Account & Token Controllers： 名字空间下的账户和 API 访问口令的管理

• cloud-controller-manager

  k8s 和不同云服务厂商对接的管理器，主要包含不同云厂商的定制化相关的功能管理，社区希望云厂商相关的代码和 k8s 核心代码尽量减少依赖，各自独立开发，依靠 cloud-controller-manager 的链接方式运行云厂商相关的管理器，但是历史原因还是有一些相关的控制器依赖，主要包括：

  • Node Controller： 节点停止服务后，节点是否在云厂商那边真正删除
  • Route Controller： 路由的建立
  • Service Controller： 云负载均衡器
  • Volume Controller： 卷存储的生命周期交互

Worker 节点

Worker 节点主要是提供 k8s 的容器运行环境，维护运行的 pods，从节点组件包括：

• kubelet

  从节点上运行 Agent，保证 pod 中容器正常运行，健康检查管理等

• kube-proxy

  从节点运行的网络代理，提供路由转发

• container runtime

  容器运行环境，支持 docker，containerd， cri-o，rktlet，只要是符合 CRI 接口要求的运行环境都支持。

其他扩展

扩展插件利用 k8s 资源等机制实现了集群相关的一些特性功能，主要包括：

• 提供网络通信和网络策略管理

• 服务发现（DNS）

• 可视化和管理 Web 平台

• 集群内部容器资源的监控

• 集群级别的日志处理

Kubernetes 架构

来自 Kubernetes 官方的文档中给出 k8s 和云控制管理器演化的架构对比，其中也包含了关于不同组件的架构组成：

Kubernetes 高可用

k8s 的高可用多主节点架构如下：

除了上面这种堆叠式架构外，还可以采用另外一种外部的 etcd 节点架构，

两种架构各有优缺点，根据自身的需求进行选择。

Kubernetes Service 网络架构

在 k8s 中， service 这个对象代表一个提供网络服务的应用，这个应用背后就是一组 pods。 pods 在每个从节点上运行，利用 kube-proxy 进行相应的网络转发和代理，kube-proxy 的实现方式是虚拟 IP 的方式，具体有以下几种形式：

• 用户空间代理模式 （默认是 round-robin）

  

• iptables 代理模式 （默认是 random）

  

• ipvs 代理模式 （支持多种，rr，lc，dh，sh, sed, nq)

  

  k8s 主要支持两类服务发现模型，环境变量和DNS

  k8s 中服务对外的发布主要有四类方式：

  • ClusterIP （集群内部 IP）

  • NodePort (每个节点 IP， Port)

  • LoadBalancer（云厂商的负载均衡器）

  • ExternalName（CNAME 方式，无需代理方式）

Kubernetes 生产环境部署

k8s 集群按照相应层次的面向对象不同，涵盖应用，数据面，控制面，集群基础设施，常规集群运维等方面，究竟是自身管理还是使用云产品打包方案，有如下几种形式：

对于上面的几种解决方案，各个云厂商支持的粒度有很大差别，具体可以见参考资料中表格总结

参考资料

• https://kubernetes.io/docs/concepts/cluster-administration/addons/
• https://kubernetes.io/docs/concepts/overview/components/
• https://kubernetes.io/docs/concepts/architecture/cloud-controller/https://kubernetes.io/docs/concepts/architecture/cloud-controller/
• https://kubernetes.io/docs/tasks/administer-cluster/highly-available-master/
• https://kubernetes.io/docs/concepts/services-networking/service/
• https://kubernetes.io/docs/setup/#production-environment

HTTP/3 是什么？

HTTP3 是为了解决现有的 HTTP2 一些性能，安全上的问题而提出的，最初的原型来自于 Google 的内部
QUIC 传输层协议，基于 UDP 开发。

HTTP2 历经了 16 年洗礼，才逐渐被各大浏览器产商，软件厂商接受和应用起来， HTTP2 的座位还没稳固，
HTTP3 就已经开始迈向历史舞台， 发展过程大致如下：

1

QUIC （2012 Google） --》  IETF 进行标准化（2015）  --》 QUIC（核心规范提交 IESG  2019）

HTTP/3 做了什么改进？

HTTP/2 相比 HTTP /1.1 最大程度解决了 HTTP head of line blocking， 引入了 Multiplexing 方法，
通过一个 TCP 连接就可以实现客户端，服务端之间的双向数据流并行发送，带来了一定条件下的性能提升。

HTTP/2 确实大大减少了 TCP 连接数，但是却没有解决 TCP 协议层面的引发的 head of line blocking，
这个主要是 TCP 本身是有序传输的，单个流的数据丢失会导致其他的数据流受影响而等待，直到丢失的数据
被重传接收。 这个问题在丢包率较高的环境下，会让 HTTP/2 相对于的 HTTP/1.1 的性能优势荡然全无。

为了克服 TCP 协议的这个固有问题，QUIC 引入了基于 UDP 之上的类 TCP 实现，使用独立的数据流进行并行传输，
单个流的数据丢失只是影响自身，其他的数据流不必停下来等待。

至于为什么选择 UDP， 而不是改进 TCP 或者设计一个新的协议，这个还是历史包袱的问题，大量的网络基础设施
已经遍布世界各地，更换代价和时间成本很高，全新的协议基本不靠谱；TCP 协议又因为被广泛使用，改动变更和
落实也是很头疼的事情，基本是出力不讨好。 为了让改进特性更快的尝试和兼容，最终选择了基于 UDP 进行传输，
同时上层的放在用户态空间实现，减少了对不同操作系统内核的过度依赖。

HTTP/3 协议栈

下面的这个图形象的说明了 HTTP/3 相对 HTTP/2 协议栈的不同：

来源：https://http3-explained.haxx.se/zh/the-protocol.html

HTTP/3 的未来

尽管 HTTP/3 已经在标准化的路上走得越来越稳，摆在面前的一些质疑和问题依然不断，主要是

• UDP 的性能
• QUIC 资源占用
• 成长太慢

参考资料

1. https://datatracker.ietf.org/wg/quic/charter/
2. https://http3-explained.haxx.se/zh/why-h2.html
3. https://tools.ietf.org/html/draft-ietf-quic-transport-18
4. https://tools.ietf.org/html/draft-ietf-quic-transport-20
5. https://diophant.com/blog/what-is-http3-and-why-is-it-needed/

过去的一年里，陆陆续续的将过去 Chinaunix 上的文章都迁移到 Git 上进行管理了，
一方面，不太希望自己的文章绑定到一个平台上，如果平台没有提供合适的保存文章工具，
我很担心某天告诉我，你的文章无法继续维护，请自行进行备份迁移。

另外一方面，工具化的发布流程，相比平台的富文本化的工具编辑来说，更加灵活和可控。

2019 年已经到来，新的一代也将进入舞台，我们老胳膊老腿的人也要不甘落后，历史改革滚滚向前，我们自己不能因循守旧，随着年龄越来越大，更要保持初心，对新事物更加包容，就是一句话，直接上，向前进。

致敬我的 2018 年的技术生活。

随着微信，头条，知乎等自媒体平台的丰富，传统的 Blog 站点相对来讲不再如同以往那样流行了。不过对于技术爱好者来说，Blog 站点仍然是一个可以 free style 的地方，不必受到平台等统一的约束，可以发挥很多 Hack 的地方，结合 Git 玩转的很溜。如果从追风的角度看，单独的沉迷于个人站点是不可以取的，几个原因：

周六大早上北京的天气仍然很糟糕，寒冷并且浓重的雾霾。 为了参加 WOT 会议，所以这个周末起的有点早。 最近因为工作太忙，周五的一天没有来参加，
也就今天来赶个晚场了。

签到后，看了一些各个分会场的主题内容，听了听搜索和推荐相关的 AI 实战，主要是各种算法模型的利用和优化，因为没有做过这方面的工作，听得不是很深入。
下午，有几个 AI 在行业的赋能场景和平台化建设的话题，蛮有意思。 相对来说，技术打法差别不大，主要是行业的深入应用和场景化剪裁，使得AI落地更加容易。

总体下来，收货不少，有些议题干货充足，每个分会场针对提问的观众都会随机发一些技术书，我自己收到了 3 本书，分别是关于算法，机器学习和社会媒体挖掘，
关于议题的更多内容大家可以到官网 http://www.51cto.com/ 了解更多，我就不再赘述了。

今天写博客的时候，突然感觉这个 landscape 主题不优雅，想换一个简约优雅的主题风格。
查找了一下，发现 Hexo 的 Next 风格很协调，所以打算切换一下看看效果。

Go Module

Go 1.11 引入对于 Module 概念的初步支持，这个特性具体是什么？ 为什么要引入这个概念，我觉得有必要给大家简单的介绍一下。

作为一个忠实的 Ubuntu 用户，从 8.04 追随到如今，的确也算对 Ubuntu 有所偏爱了。每次系统的更新和升级总给我带来不一样的感受。不管是喜欢的，还是吐槽的，慢慢的体会到在 Linux 世界中，作为一款易用的，有美感的桌面系统实属不易，自认为在 Linux 纷繁复杂的世界中。

Ubuntu 一路的设计和改进，对 Linux 桌面系统普及使用，有着不小的贡献。18.04 作为 Ubuntu 下一个 LTS 版本，融合较大的改进，其中最突出的莫过于，从 Unity 切换到 GNOME 了。

一. LBS 的实际问题
LBS 有一个经典的使用场景，就是查找当前位置附近的商家，车辆，或者交通站点。对于如何利用现有的技术来实现这个简单的需求，网上已经有成堆的资料可以查到，这里就不再赘述了，简单的说一下其中的一个关键的技术点 GeoHash 算法，仅此备忘。