Kubernetes连载之08 Stateful Apps

[andy2046]

Stateful versus stateless applications in Kubernetes

无状态的Kubernetes应用程序是一种不在Kubernetes集群内管理其状态的应用程序。所有状态都存储在集群之外，集群中的容器以某种方式访问它。

Understanding the nature of distributed data-intensive apps

分布式应用程序是在多台机器上运行的进程的集合，处理输入，处理数据，暴露API以及可能具有的其他副作用。每个进程都是其程序，运行时环境以及其输入和输出的组合。一些程序将状态保存在内存中，并可通过网络提供请求。简单的程序可以在一台机器上运行，可以将所有状态保存在内存中或从文件中读取。他们的运行环境是他们的操作系统。如果它们崩溃，用户必须手动重新启动它们。他们被绑在他们的机器上。分布式应用程序是一种不同的动物。一台机器不足以处理所有数据或足够快地提供所有请求。单台机器无法保存所有数据。需要处理的数据非常大，以至于不能经济有效地将其下载到每台处理机器中。机器可能会失败并需要更换。升级需要在所有的加工机器上进行。用户可能分布在全球各地。

考虑到所有这些问题，很明显，传统的方法是行不通的。数据成为限制因素。用户/客户端必须只接收摘要或处理的数据。所有海量数据处理必须靠近数据本身完成，因为传输数据的速度非常缓慢而且非常昂贵。相反，大量处理代码必须在数据的相同数据中心和网络环境中运行。

Why manage states in Kubernetes

在Kubernetes本身而不是单独的集群中管理状态的主要原因在于Kubernetes已经提供了监视，扩展，分配，安全和操作存储集群所需的大量基础架构。运行并行的存储集群将导致大量重复工作。

Why manage states outside of Kubernetes

我们不排除另一种选择。只要它共享相同的内部网络（数据接近度胜过一切），在某些情况下在单独的非Kubernetes集群中管理状态可能会更好。一些有效的原因是：

• 你已经拥有一个独立的存储集群
• 你的存储集群由其他非Kubernetes应用程序使用
• Kubernetes对你的存储集群的支持不够稳定或不够成熟

Shared environment variables versus DNS records for discovery

Kubernetes为整个集群提供了多种全局发现机制。如果你的存储集群不由Kubernetes管理，你仍然需要告诉Kubernetes Pod如何找到并访问它。有两种主要方法：

• DNS
• 环境变量

在某些情况下，你可能希望同时两者，但是环境变量可以覆盖DNS。

Accessing external data stores via DNS

DNS方法简单直接。假设你的外部存储集群是负载平衡的并且可以提供一个稳定的端点，那么pod可以直接命中那个端点并连接到外部集群。

Accessing external data stores via environment variables

另一个简单的方法是使用环境变量将连接信息传递到外部存储群集。Kubernetes提供ConfigMap资源作为保持配置独立于容器镜像的一种方式。该配置是一组键值对。配置信息可以作为容器或卷内的环境变量显示。你可能更喜欢使用secret来获取敏感的连接信息。

Creating a ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: db-config
  namespace: default
data:
  db-ip-addresses: 1.2.3.4,5.6.7.8

> kubectl create -f ./configmap.yaml
configmap "db-config" created
> kubectl get configmap db-config -o yaml
apiVersion: v1
data:
  db-ip-addresses: 1.2.3.4,5.6.7.8
kind: ConfigMap
metadata:
  creationTimestamp: 2017-01-09T03:14:07Z
  name: db-config
  namespace: default
  resourceVersion: "551258"
  selfLink: /api/v1/namespaces/default/configmaps/db-config
  uid: aebcc007-d619-11e6-91f1-3a7ae2a25c7d

Consuming a ConfigMap as an environment variable

apiVersion: v1
kind: Pod
metadata:
  name: some-pod
spec:
  containers:
    - name: some-container
      image: busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: DB_IP_ADDRESSES
          valueFrom:
            configMapKeyRef:
              name: db-config
              key: db-ip-addresses
  restartPolicy: Never

> kubectl logs some-pod
KUBERNETES_PORT=tcp://10.0.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=some-pod
SHLVL=1
HOME=/root
DB_IP_ADDRESSES=1.2.3.4,5.6.7.8

Using a redundant in-memory state

在某些情况下，你可能需要在内存中保留一个瞬时状态。分布式缓存是一种常见的情况。对时间敏感的信息是另一个。对于这些用例，不需要持久性存储，并且通过服务访问多个Pod可能是正确的解决方案。我们可以使用标准Kubernetes技术（如标签）来识别属于相同状态的冗余副本的Pod并通过服务公开它。如果一个pod挂了，Kubernetes将创建一个新pod，其他pod将继续服务。我们甚至可以使用pod anti-affity功能来确保维护相同状态的冗余副本的pod不会安排到同一节点。

Using DaemonSet for redundant persistent storage

一些有状态的应用程序（如分布式数据库或队列）会冗余地管理它们的状态并自动同步它们的节点。在这些情况下，重要的是将pod分开排列到不同节点。将Pod安排到具有特定硬件配置的节点或甚至专用于有状态应用程序的节点也很重要。DaemonSet功能非常适合此用例。我们可以标记一组节点，并确保将有状态的pod按照一个一个的顺序排列到所选的一组节点上。

Applying persistent volume claims

如果有状态的应用程序可以有效地使用共享持久性存储，那么在每个pod中使用持久性卷声明是一种可行的方法。有状态的应用程序将会显示一个看起来就像本地文件系统的安装卷。

Utilizing StatefulSet

StatefulSet控制器是Kubernetes的一个相对新的补充。它特别设计用于支持分布式有状态应用程序，其中成员身份很重要，如果某个pod重新启动，则必须保留其身份。它提供有序的部署和缩放。与普通的pod不同，有状态集的pod与持久性存储相关联。

When to use StatefulSet

StatefulSet适用于需要以下一项或多项的应用程序：

• 稳定，唯一的网络标识符
• 稳定，持久的存储
• 有序，优雅的部署和扩展
• 有序，优雅的删除和终止

The components of StatefulSet

有几件需要正确配置才能生成StatefulSet：

• 负责管理StatefulSet pods的网络身份的headless服务
• Stateful自身及多个副本
• 动态或由管理员提供的持久存储

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx