Dont Need Kubernates

Kubernates 是个分布式系统：有主服务器控制工作服务器。工作会分配到不同的工作服务器上面。每个服务器在容器里面完成这些工作。

所以，你可能已经使用2台服务器或者虚拟机把事情都解决了。And that just gives you … one machine. If you’re going to scale (the whole point of the exercise) you need three or four or seventeen VMs.

Kubernates 截止到 2020 3月初已经有超过 580000 行 go 代码了。这是真实的代码量，不包括注释和空行，也不包括第三方包。2019 年有一个安全 review 对这些代码有如下描述：

Kubernates 的代码有很大提升空间。代码量大且复杂，有大量代码只有少量注释并且还有很多依赖，包括 kubernates 系统外的。有很多重复的逻辑应该用支持库的形式来减少复杂度，方便打补丁，减少在代码各处写文档的负担。

公平的说，这个和其他大型项目类似，但是这些都是需要你处理的，如果你想让你的程序正常运行。

kubernates 是个有很多服务，系统和组件的复杂系统。

在你运行一个简单程序前，你需要先理解已经被简化过的系统架构。

在 kubernates 概念的文档里面，包含很多类似下面的声明：

Kubernates 里面 EndpointSlice 包括一些针对 network endpoints 的引用。当指定选择器的时候，EndpointSlice 控制器会为 kubernates 服务自动创建 EndpointSlice。这些 EndpointSlice 会包括对符合服务器选择器的 Pods 的引用。 EndpointSlice 通过唯一的服务器和端口来组合 network endpoints。

默认情况下，每个 EndpointSlice 控制器可以管理不超过 100 endpoints。Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

里面上文需要很多概念：EndpointSlice, Service, selector, Pod, Endpoint。

大部分情况下你并不需要这些特性，不过大部分情况下你也不需要 kubernates 。。

另一段随机选的文字：

默认情况下，发送到 ClusterIP 或者 NodePort 服务的流量会路由到这个服务的任意一个后端。从 Kubernates 1.7 开始，可以支持把 “外部” 流量路由到接受到外来流量的节点上面的 pod，但是这个不支持 ClusterIP 方式的服务，以及更复杂的拓扑，例如 route zonally。服务拓扑特性通过允许服务创建者定义一个基于为源节点和目标节点的节点标签的路由策略来解决这个问题。

前面提到的安全 review 里面提到的：

Kubernates 是一个复杂的大系统。评估团队发现配置和部署 kubernates 并不简单，很多组件有令人迷惑的默认设置，缺失的运作控制，和隐含的安全控制。

越深入 kubernates，会发现越难进行普通的开发：你需要理解这些不同的概念（Pod，Deployment，Server，等等）才能运行你的代码。所以你需要运行一个完整的 k8s 系统，仅仅为了测试，通过 VM 或者嵌套的 Docker 容器。

因为你的程序很难在本地运行，开发变的更难，有一些不同的解决方案，从 staging 环境代理本地进程到集群里面（多年前我为这个写了一个工具），代理远程进程到本地机器。

有很多不那么完美的方案可以使用，最简单完美的方案就是不用 kubernates。

第二个问题是，因为这个系统允许你跑很多的 service，所以会更倾向于写很多的 service。这不是个好主意。

分布式的系统很难写正确。更多的组件，意味着更多的问题需要处理。

分布式系统也很难 debug。You need whole new categories of instrumentation and logging to getting understanding that isn’t quite as good as what you’d get from the logs of a monolithic application.

微服务是一种 organizational scaling 技术：当有 500 人为一个网站做开发的时候，为了让大家可以独立工作而为分布式系统付出的代价是值得的。划分成多个 5 个人的微服务团队，他们把其他微服务当作是外部不可可信赖的服务。

如果你是个 5 人团队，有 20 个微服务，你并不迫切需要分布式系统。不像人家大公司是 5 个人维护一个服务，你是 0.25 人维护一个服务。

当你经常需要扩展的时候 Kubernates 是有用的。不过有一些替代方案

• 你可以使用云虚拟机，最多可以支持 416 vCPU 和 8T 内存，a scale I can only truly express with profanity。虽然贵，但是它保持了简单。
• 可以简单的使用类似 Heroku 的服务扩展比较简单的网站服务。

这是基于假定，增加更多的工作节点会带来更多的好处：

• 大部分程序不需要扩展很多，一些明智的优化足够了。
• 大部分网站程序的扩展瓶颈是在数据库，不是 web 工作节点。

越多的组件表示越多的错误的可能性。

Kubernates 提供的可用性特性（健康检查，滚动更新），可以用更简单的方式实现，或者很多时候都内置了。例如，nginx 可以针对工作节点做健康检查，你也可以使用 docker-autoheal 或者类似的东西来重启服务。

如果你关心宕机时间，首先想的不应该是：我如何把部署引起的宕机时间从 1 秒减少到 1 毫秒。应该是：当出问题的时候如何保证数据库结构变化不会阻止回滚操作。

如果你想要高可用，不想要单点故障，有很多的方法可以在不使用 kubernates 的情况下实现。