利用Kubernetes实现容器的持久化存储

　　有时我们的应用程序不希望或不需要负载平衡或单个服务IP，诸如此类的应用程序(主数据库和副本数据库、分布式应用程序中的代理等)需要一种将流量路由到支持服务的各个分离Pod的方法。具有唯一网络标识符的Headless服务和Pod (例如使用statefulset创建的那些标识符)可以在此用例中一起使用。能够直接路由到单个Pod将大量的性能重新交到开发人员手中，从处理服务发现到直接路由到主数据库Pod。

　　下面是一个Headless服务的例子：

　　apiVersion: v1

　　kind: Service

　　metadata:

　　      name: nginx-svc

　　spec:

　　      clusterIP: None

　　      selector:

　　      app: nginx

　　      ports:

　　      — name: http

　　            protocol: TCP

　　            port: 80

　　            targetPort: 30001

　　      — name: https

　　            protocol: TCP

　　            port: 443

　　            targetPort: 30002

　　使该规范真正“Headless”的属性是设置.spec下的clusterIP为None。这个特殊的示例使用spec下的selector字段，以指定应该如何配置DNS。在这个例子中，所有匹配app: nginx选择器的Pods将创建一条A记录，直接指向支持服务的Pod。关于DNS如何为Headless服务自动配置的更多信息，可以在这里(https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)找到。这个特殊的规范将创建端点nginx-svc-0、nginx-svc-1、nginx-svc-2，它们将分别直接路由到名为web-0、web-1和web-2的Pod。

　　Headless服务的要点:

　　*无头服务允许直接路由到特定的豆荚

　　*使应用程序开发人员能够以他们认为合适的方式处理服务发现

　　结论

　　Kubernetes使有状态应用程序开发在容器世界中成为现实，特别是在管理应用程序状态和持久数据时。持久卷和持久卷声明建立在卷的基础之上，以支持持久数据存储，从而支持在一个主要是短暂性的环境中保持数据持久性。存储类进一步扩展了这一思想，允许按需提供存储资源。StatefulSet提供Pod惟一性和粘滞标识，为每个Pod提供有状态标识，这些标识在Pod中断和重启期间持续存在。Headless服务可以与StatefulSet一起使用，为应用程序开发人员提供根据应用程序需求来利用Pod的独特性的能力。

　　本文介绍了Kubernetes中有状态应用程序所需的基本元素。随着Kubernetes的不断发展，围绕有状态应用程序的功能将继续出现。对于有状态应用程序开发人员和集群管理员来说，了解这些基本元素是非常重要的。

　　原文作者：Nick Groszewski 来源：Medium

　　原文链接：https://medium.com/capital-one-tech/conquering-statefulness-on-kubernetes-26336d5f4f17

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!