Quick Notes

在边缘计算云原生领域，Rancher开源的k3s侧重于在边缘运行完整的k8s集群，而华为开源的kubeedge则是在边缘运行可以脱机的k8s节点。刚好手上有aliyun和腾讯云上各一台配置比较差的虚拟机，平时用来跑下基本的k8s服务，做个调试验证用的，一跑应用就卡死，内存严重不足。这场景似乎与边缘计算资源局限的窘境很类似；于是，大胆的想像在其中一台机器上跑k3s，同时用其作为kubeedge的k8s server侧；在另外一台上跑kubeedge的edge节点，组成一个集群。

serverless需要有一套广泛兼容多种事件的时间触发框架，从而支持在不同应用场景下基于事件来创建server，对外提供服务。knative的eventing的目标就是提供这样一套框架。当前knative原生支持的event类型还比较有限，但是系统提供了开放的container source，可以基于需求自定义实现。本篇的示例主要基于系统sample文档的in-memory-channel来论述其实现原理。

Tekton作为google开源出来的一个CD工具，与knative之前的build有很多相似的地方。build的功能相对来将较单一，且社区提出了很多改进的地方都由于其现有的架构设计局限而找不到解决方案。那么tekton基于build，都有哪些提升？

knative自v0.7.0开始废弃现有的build而拥抱tekton，由于均是基于google的项目，所以镜像下载成为一个大问题。本文采用类似于knative墙内安装 的方式来处理镜像和安装脚本，适用于墙内安装体验。

knative在service里面实现了serverless的功能，其中最重要的莫过于按需来启动服务，并基于流量来弹性伸缩。在社区的文档里面找到这样一张架构设计图，先初略理解一下，详细介绍一下其流量转发流程。

该文基于knative v0.6.0版本。

knative-build提供将源码编译、构建、打包的整个流水线流程。其核心原理是基于pod的init contaier来定义一系列串行执行的stage。由于每一个stage都可以由用户自定义，若加以扩展，还可以用于更多场景。

最近开发环境的k8s出现过一次读取不出来configmap，并导致api-server OOM重启的现象，供应商说是因为configmap条目太多，导致api-server大量decode etcd的数据为yaml所致。在原生k8s上反复重试过多次，均无法复现该现象，所以又看了一遍api-server大致的代码逻辑，这里简单记录一下。

在Istio和Knative，以及众多中间件operator中都会经常看到有使用informer去watch自定义CRD资源，然后reconsile的代码。其实每一个controller/operator都是使用api-server的客户端在操作资源。对于k8s支持的核心资源类型可以直接引用client-go，对于CRD，当前主要有三种方案。

以前在基于k8s做应用开发的时候，都是使用admin来使用k8s，基本不用去关注授权的问题。但是，当我们将k8s作为PaaS平台的容器编排引擎，并引入多租户时，就涉及到权限管理相关的问题了。那么，如果你刚好是公司的系统管理员，当你部署完一套k8s，准备将其提供给多个部门使用的时候（他们希望彼此互不影响），接下来的内容就特别适合你了。

基于K8s之上的声明式API编程可以说Etcd起到了至关重要的作用。一方面，API Server使用了etcd的特性从而提供了订阅，选举等功能。另一方面，k8s集群的所有配置信息也都集中存放于etcd中，etcd完好的情况下，可以随意的变动node节点，k8s最终会保障服务都按照预期来编排和对外提供服务。