小编jt9*_*t97的帖子

根据这个官方文档，Kubernetes Persistent Volumes 支持三种类型的访问模式。

1. 只读多
2. 一次读写
3. 读写多

文档中对它们的给定定义是非常高级的。如果有人可以更详细地解释它们以及我们应该使用一个与另一个的不同用例的一些示例，那就太好了。

我正在从这里检查 proxy_read_timeout 的描述。

Syntax : proxy_read_timeout time;
Default: proxy_read_timeout 60s;
Context: http, server, location

定义从代理服务器读取响应的超时。仅在两个连续的读取操作之间设置超时，而不是为整个响应的传输设置超时。如果代理服务器在此时间内未传输任何内容，则连接将关闭。

粗体语句的实际含义是什么？

在 GKE 中部署了弹性搜索 Kubernetes。配备 2GB 内存和 1GB 持久化磁盘。

我们在存储异常中遇到错误。在那之后，我们已经增加到 2GB，第二天它达到了 2GB，但我们没有运行任何大查询。然后我们再次将持久性磁盘大小增加到 10 GB。之后，数据持久化磁盘存储量不再增加。

在进一步的分析中，我们发现总的 Indices 占用了 20MB 的内存，无法存储磁盘中的数据。

使用弹性搜索节点统计 API来获取有关磁盘和节点统计信息的详细信息。

我无法找到内存超出的确切原因以及磁盘中的数据是什么。另外，提出防止这种未来的方法。

我正在尝试将一个部署转换为 Kubernetes 中的 StatefulSet。以下是我的部署说明。

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "4"
  creationTimestamp: "2020-04-02T07:43:32Z"
  generation: 6
  labels:
    run: jbpm-server-full
  name: jbpm-server-full
  namespace: dice-jbpm
  resourceVersion: "2689379"
  selfLink: /apis/apps/v1/namespaces/dice-jbpm/deployments/jbpm-server-full
  uid: 8aff5d46-533a-4178-b9b5-5015ff1cdd5d
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      run: jbpm-server-full …

我上个月开始在一家新公司工作。我将负责SAAS的基础架构和后端。

我们目前每个客户只有一个小滴/实例。在公司当前阶段，这是一个不错的选择。但是在将来实例数量增加时，将很难维护它。目前有150个实例联机，每个实例具有1个CPU和1GB内存。

我们的客户仅在一周，一个月或一年的时间内使用环境。所以大多数时候，他们什么都不做。所以我们要改变它。我在想Kubernetes，Docker Swarm或其他工具。

您能给我们什么建议？我们应该迈入Kubernetes还是Docker Swarm，还是在DigitalOcean，AWS或GCP停留在Droplet / VM上？

如果我们改用AWS或GCP，我们的平均价格将从每平方米5美元上涨至每平方米10美元以上。

我们希望采取下一步措施，以减少资源浪费，同时还要考虑每月的账单。在我看来，最好让我们的3个较大的VM中有2个运行Kubernetes或Docker Swarm，以降低每月账单并减少我们的预留资源。

你怎么看？