我理解的云原生.md

下面都是说的无状态服务，有状态的类似，除了 1 2 再多一句话就能描述

最开始的状态：不云，但原生

没有好用的隔离方案，通常会在一个机器上部署一个东西：

1. 我们知道机器的资源（这个进程最多能用多少 CPU 内存）
   • 以便让服务运行在资源足够的地方
2. 我们知道哪些机器运行着这个服务（服务发现），服务可能直接监听 80 这样的端口
   • 以便做负载均衡

容器化以后的状态：云，但不原生

容器化让资源和环境更容易隔离，我们会在一台机器上部署超过一个服务：

1. 我们大概估计容器要用的资源，然后手动编排它们
   • 例如在 ansible 脚本里写好机器1上运行 A B C，机器2上运行 C D
2. 部署的规模变大了，而且一个机器上不同端口运行着多个服务，我们需要一个服务发现的方案
   • 例如在服务启动的时候在 consul 注册自己 / 让服务广播自己等等

现在的状态；云，且原生

1. 我们知道进程要用多少资源
   • k8s 会自动编排
2. 不论数量多大，是用什么端口，也能直接通过 service 或者 endpoint 做负载均衡

总结

容器化方案虽然解决了裸部署的一些问题，但也带来了一些麻烦；云原生旨在解决这些麻烦。

概括一下我的理解是：k8s 终极目标是希望你在任何云环境里部署服务时，不用考虑他怎么编排的、我怎么发现这些服务、怎么给可能被任意调度的服务分配固定的 ip、怎么持久化存储等等这些问题；做到这些事情步骤不会比裸机部署更多。

PS

其实在我看来云原生还有相当多问题没解决，很多公司要自己想办法，比如用 service mesh 监控流量具体怎么走的；比如用一些保存现场的方案，以便在挂掉的时候有信息可以用来 debug 等等。

虽然有 OAM 这样的规范出来用来规定应用应该怎么做，但似乎和前面描述的思路刚好相反；而且现在还没有解决例如上面两个问题。

总结下来，期望能把所有组件都跑在 k8s 里，在 DB 这种有状态的业务都在往 cloud 上迁移的今天，也许也不是不可能

总结下来，期望能把所有组件都跑在 k8s 里，在 DB 这种有状态的业务都在往 cloud 上迁移的今天，也许也不是不可能

如果服务比较复杂，放在 k8s 集群里可能会比裸机部署更容易：比如 Elastic 家的各种东西做了 CRD，只要部署一个 Elasricsearch 资源或者 Kibana 资源就能起来；后面的升级、扩容节点、扩容磁盘都只是修改 yaml 里一行的事情。

---

虽然这或许不是云原生直接带来的好处，但 k8s 是现在云原生编排的事实标准；这是 k8s 的声明式管理带来的直接好处，我们关心结果而不关心过程。