1. kuberbetes应用接入准则篇

准备篇

作为当前正在运行的程序无论各种语言， 如果将程序迁入kubernetes中运行，为了更好的兼容K8S的相关特性， 程序都需要进行一些改造。 参考https://12factor.net/zh_cn

Factor详解

2.1. 一份基准代码，多份部署

每一个应用只有一份用来跟中所有修订版本的代码仓库， 基准代码和应用之间是一一对应关系

• 当应用可以被拆分为不同模块时，就不能被称为一个应用，而是一个分布式系统，其中的模块就对应一个应用。

• 多个应用共享一份基准代码是有悖于12-Factor原则的， 解决办法是将共享的代码拆分为独立的库， 使用以来管理策略加载

• 每个应用只对应一份基准代码，但可以同时存在多份部署。每份部署相当于运行了一个应用的实例。如将应用部署到生产环境、多个预发布环境、测试环境等。

推荐使用git作为应用的版本管理系统， 使用自建gitlab或者github做为在线仓库， 分支的管理策略参考/git分支管理流程， 或者完全按照gitflow

2.2. 显式声明依赖关系

在应用运行中需要其他工具类库等依赖项，需要通过依赖清单，确切地声明所有依赖项。 例如，Ruby的 Bundler 使用 Gemfile 作为依赖项声明清单，使用 bundle exec 来进行依赖隔离。Python 中则可分别使用Pip 用作依赖声明。显式声明依赖的优点之一是简化了环境配置流程，只需通过一个构建命令来安装所有的依赖项，即可开始工作。

2.3. 在环境中存储配置

应用在不同的环境中部署时，有不同的配置，如数据库连接配置、第三方服务的证书等。要求代码与配置严格分离开。

可以通过将配置写入配置文件，且不纳入代码仓库的版本管理中来实现。

12-Factor推荐将配置存到环境变量中，非常方便地在不同的部署间做修改，却不动一行代码

2.4. 把后端服务当作附加资源

对于后端服务，如mysql、redis等本地服务和邮件、api等第三方服务都应该作为附加资源存在配置中。可以通过更改配置来切换后端服务。

2.5. 严格分离构建和运行

应用部署需要以下三个阶段：

构建阶段 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 依赖项，编译成二进制文件和资源文件。

发布阶段 会将构建的结果和当前部署所需 配置 相结合，并能够立刻在运行环境中投入使用。

运行阶段 （或者说"运行时"）是指针对选定的发布版本，在执行环境中启动一系列应用程序进程。12-factor要求应用严格区分构建，发布，运行这三个步骤。

2.6. 以一个或多个无状态进程运行应用

1以一个或多个无状态进程 运行应用，需要持久化的数据放到后端服务中。

2不可使用粘性 session（将用户 session 中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程）。

2.7. 通过端口绑定提供服务

12-Factor 要求应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用 通过端口绑定来提供服务 ，并监听发送至该端口的请求。

依赖网络服务器的应用，如PHP应用作为 Apache HTTPD 的一个模块来运行， Java应用运行于 Tomcat 。

自我加载网络服务的应用如，Python的Tornado, Ruby的Thin , Java以及其他基于JVM语言的Jetty。完全由应用的代码，绑定端口，提供服务。

2.8. 通过进程模型进行扩展

（自己理解，有待讨论）

1开发人员将不同的工作分配给不同的进程类型。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。定时任务交由 clock 来处理，这样扩展每一类的进程就非常方便，如下图所示：

2与通过进程模型进行扩展相反的方式是通过线程模型进行扩展，这是一种相对较为传统的方式。当我们启动一个Java进程的时候，通常会在应用层面为其设置一个或者多个线程池的容量上下限，当外部负载变化时，进程所占用的内存容量和进程内部的线程数量可以在这些预先设置好的上下限之间进行扩展，这种方式也被称为纵向扩展或者垂直扩展。

现在更为推崇使用"固定的"进程（对前面Java应用的例子来说，就是固定的内存容量和线程池容量），在外部负载提高时，启动更多的进程，在外部负载降低时，停止一部分进程，这种方式就是本原则所说的通过进程模型进行扩展，有时候也被称为横向扩展或者水平扩展。

2.9. 快速启动和优雅终止可最大化健壮性

12-Factor 应用的 进程 是 易处理（disposable）的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的 代码 或 配置 ，稳健的部署应用。

2.10. 尽可能的保持开发，预发布，线上环境相同

12-Facto应用缩小本地与线上差异有利于实现持续部署。主要是以下三个差异:

缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。

缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。

缩小工具差异：尽量保证开发环境以及线上环境的一致性。

2.11. 把日志当作事件流

1应用程序应该将其产生的事件以每个事件一行的格式按时间顺序输出

2应用程序不要自行管理日志文件。要求应用程序将日志以事件流的方式输出到标准输出STDOUT和标准错误输出STDERR，然后由运行环境捕获这些事件流，并转发到专门的日志处理服务进行处理。

2.12. 后台管理任务当作一次性进程运行

该原则反对通过SSH接入线上环境执行管理任务，建议后台管理任务当作一次性进程运行。

如果管理任务是修改应用配置，那么应该通过配置管理服务进行操作；如果管理任务是批处理任务，例如数据的迁移、清洗或者检查，那么应该通过云平台的批处理机制进行操作，大多数的云平台都会提供这种机制，例如Kubernetes的Jobs。