Kubernetes已经成为事实上的容器应用编排引擎。Docker引领了一股构建、打包和容器化应用的风潮。在这股浪潮中首先到来的是Docker和后面Kubernetes的无状态应用。什么是无状态应用？什么是有状态应用？为什么编排有状态应用很困难？让我们一起深入理解这些核心概念吧。
状态是什么
关于状态有很多定义，这里是我自己的定义：
- 连接/请求状态：DB连接、会话，HTTP会话等等
- 进程状态：内存进程状态，或者共享内存的进程组
- 持久化状态：应用的持久化状态
连接/请求状态
HTTP协议的定义里标明了它是无状态的。每个请求应该包含服务器能够完成请求的所有信息。HTTP请求不应该依赖于前面或者后继的任何请求。这就是说会有一些例外的情况，比如会话。注意到HTTP协议的无状态性表示的是协议自身不包含两端维持状态的信息，客户端和服务器端可以存储状态。
然而数据库连接是另外一回事。数据库会话和事务依赖于状态。考虑一下，一个通过JDBC或者ODBC发起的数据库操作——使用数据库凭据打开连接，创建会话，执行多个插入或者更新语句，然后提交或者回滚会话。所有这些动作不能分开完成，不能通过多个连接或客户端完成。
进程状态
每个进程都有保留在磁盘上的状态，也有内存存储的状态。同样还有网络状态，比如打开的TCP会话等。还有一些比如Memcached或者Redis这样的完全建立在内存状态的缓存服务。对于HDFS namenodes，SAPHANA等这样的应用来说，会周期性将内存状态刷新到磁盘上。
持久化状态
对于任何读、处理和写数据的应用来说这都是一个核心功能。一个进程可能消亡和恢复。当它们恢复时，需要和最近存放在持久化介质上的应用状态进行同步。目前有很多提供和保护这样持久化状态的产品。存储业界和备份恢复业界都因为状态保护而繁荣。
