A-A+

Kubernetes有状态应用的状态是什么?

2019年09月22日 学习小计 暂无评论 阅读 73 次

Kubernetes有状态应用的状态是什么?

本文转载自"容器时代"

Kubernetes已经成为事实上的容器应用编排引擎。Docker引领了一股构建、打包和容器化应用的风潮。在这股浪潮中首先到来的是Docker和后面Kubernetes的无状态应用。什么是无状态应用?什么是有状态应用?为什么编排有状态应用很困难?让我们一起深入理解这些核心概念吧。

状态是什么
关于状态有很多定义,这里是我自己的定义:•连接/请求状态:DB连接、会话,HTTP会话等等

•进程状态:内存进程状态,或者共享内存的进程组

•持久化状态:应用的持久化状态

连接/请求状态
HTTP协议的定义里标明了它是无状态的。每个请求应该包含服务器能够完成请求的所有信息。HTTP请求不应该依赖于前面或者后继的任何请求。这就是说会有一些例外的情况,比如会话。注意到HTTP协议的无状态性表示的是协议自身不包含两端维持状态的信息,客户端和服务器端可以存储状态。然而数据库连接是另外一回事。数据库会话和事务依赖于状态。考虑一下,一个通过JDBC或者ODBC发起的数据库操作——使用数据库凭据打开连接,创建会话,执行多个插入或者更新语句,然后提交或者回滚会话。所有这些动作不能分开完成,不能通过多个连接或客户端完成。

进程状态
每个进程都有保留在磁盘上的状态,也有内存存储的状态。同样还有网络状态,比如打开的TCP会话等。还有一些比如Memcached或者Redis这样的完全建立在内存状态的缓存服务。对于HDFS namenodes,SAPHANA等这样的应用来说,会周期性将内存状态刷新到磁盘上。
持久化状态
对于任何读、处理和写数据的应用来说这都是一个核心功能。一个进程可能消亡和恢复。当它们恢复时,需要和最近存放在持久化介质上的应用状态进行同步。目前有很多提供和保护这样持久化状态的产品。存储业界和备份恢复业界都因为状态保护而繁荣。
Docker化的应用
让我们看看无状态应用之典范:Nginx。Nginx是一个开源的反向代理,支持HTTP,HTTPS,SMTP,POP3和IMAP协议,也可以作为负载均衡器,HTTP缓存和Web服务器使用。我们使用Docker来运行Nginx服务器来承载我们的HTML静态页面。下面是我们的Docker命令:
 $ docker run\--name my-custom-nginx-container\

# Configuration\ -v /host/path/nginx.conf:/etc/nginx/nginx.conf:ro\ # Data (Content)\

-v /some/content:/usr/share/nginx/html:ro\ -d nginx

注意绑定挂载点用来将状态写到本地文件系统。我们可以将容器看做是无状态的,但是应用不是无状态的。再说一次,没有无状态应用,只有无状态进程。

  • “我们已经明确了状态的第一种形式:‘内容或数据’”
  • “宿主机文件系统保存了状态,是这种状态保管最主要的形式”
  • “没有无状态应用,只有无状态进程”
Kubernetes上的应用
Kubernetes对于应用部署和管理有独到设计。比如POD,Egress,Ingress,PersistentVolumeClaim,PersistentVolume这些设计元素。应用可以利用这些特性并且在某些场景里使用相应的原语。这需要整篇文章描述。Pods被设计为不维持IP地址(注意,这个行为可以被覆盖)。POD的DNS域名会随着每次重启而改变。对于固定的用户应用访问,需要设置一个固定的服务端点。让我们看看有状态应用MySQL,我把MySQL分为简单的有状态应用。

helm install -name salesdb stable/mysql
这样就启动了一个MySQL运行实例。让我们来看看这个实例的组成。我们注意到这个应用组成不只是一个POD,PVC和Service。Kubernetes为构建应用提供了很多基础的构建块。让我们来看看这些状态概念:
https://github.com/helm/charts/tree/master/stable/mysql
我们讨论一下持久化状态。对于“重”数据的应用而言,状态就是允许应用实现延续性的东西。我们需要问问自己:“应用从重启、失败或灾难中恢复时都需要的数据集是什么?”下面的检查清单有助于回答上面的问题:

  1. 重启Rack的时候应用可以恢复吗?
  2. 可以为应用提供一个持久化快照吗?
  3. 可以将应用迁移到不同的Kubernetes集群吗?
  4. 可以为了灾备备份我的应用吗?
PVC(Persistent Volume Claim)
这其实无需多言,PVC代表了应用的存储,这就是MySQL数据库存在的地方。可以为了隔离工作负载、性能或者其他考虑而给每个POD配置多个PVC。所有的这些PVC构成了应用状态。“我认为我们都同意这些PVC构成了应用状态”

ConfigMap
在Kubernetes里,ConfigMap用于保存应用配置。另外,ConfigMap可以作为共享配置存储。对于一个多层应用来说,Web层需要与数据库层进行通信,ConfigMap就可以为Web层提供数据库配置。如果数据库启动时的某些配置,并且Web层需要这些配置来访问数据库,那么只保存到PVC里面是不够恢复这个多层应用的。想一想SSL。启用SSL需要同时在客户端和服务端进行设置。

“ConfigMaps确实可以构成状态”

Secrets
Secrets类似于ConfigMaps,用来存储数据以及那些认为敏感的数据,比如密码,认证Token,私钥,证书等等。当应用创建好以后,密码存放在Secrets里。然后它被设置到MySQL系统表中。这样Web层通过这个密码连接数据库。这样在某处被共享的数据Secrets就是状态。如果我们丢失了这个Secrets,数据库可以正常运行,但是Web服务器再也没法连到数据库,然后我们应用就宕机了。

“Secrets确实可以构成状态”

Topology
Surprise!假设我们拥有MariaDB或MySQL集群,那么不只有一个MySQL服务器运行在Master-Slave或Active-Active配置上。同样也不只有一组PVC。在这个例子里的服务器数量构成了状态。那么数量一定是状态吗?也不一定。我们可以重新构建这个拓扑但是经常会遇到各种问题。在K8s里,拓扑信息保存在Deployment、ReplicaSet和StatefulSet里。“最终,拓扑信息可以认定为状态”

结论
没有无状态应用,只有无状态进程。应用的状态通常分配到多个有状态的进程中。这些状态不仅会是数据卷,也可能是应用配置和拓扑信息。

 

 

给我留言

Copyright © 浩然东方 保留所有权利.   Theme  Ality 07032740

用户登录