问题标签 [kubernetes-rook]

我有一个使用 Kube-spray 创建的 k8s 集群。使用 Rook 支持卷配置。到目前为止，我一直在使用持久卷。

该应用程序是使用 helm 图表部署的。为了测试目的，helm 版本会多次升级。我希望每次升级图表时 pod 都使用新卷。我不希望 pod 在 helm 升级后使用旧数据。

我怎样才能做到这一点？如何使用临时卷？

在执行 helm 升级之前已经尝试删除 PV。

I'm trying to create a Persistent Volume on top of/based off of an existing Storage Class Name. Then I want to attach the PVC to it; so that they are bound. Running the code below, will give me the "sftp-pv-claim" I want, but it is not bound to my PV ("sftp-pv-storage"). It's status is "pending".

The error message I receive is: "The PersistentVolume "sftp-pv-storage" is invalid: spec: Required value: must specify a volume type". If anyone can point me in the right direction as to why I'm getting the error message, it'd be much appreciated.

Specs:

I'm creating the PV and PVC using a helm chart.

I'm using the Rancher UI to see if they are bound or not and if the PV is generated.

The storage I'm using is Ceph with Rook (to allow for dynamic provisioning of PVs).

Error:

The error message I receive is: "The PersistentVolume "sftp-pv-storage" is invalid: spec: Required value: must specify a volume type".

Attempts:

I've tried using claimRef and matchLabels to no avail.

I've added "volumetype: none" to my PV specs.

If I add "hostPath: path: "/mnt/data"" as a spec to the PV, it will show up as an Available PV (with a local node path), but my PVC is not bonded to it. (Also, for deployment purposes I don't want to use hostPath.

我目前正在使用 Rook v1.2.2 在我的 Kubernetes 集群（v1.16.3）上创建一个 Ceph 集群，但我未能在我的 CrushMap 上添加机架级别。

我想从：

类似于：

就像官方 rook 文档 ( https://rook.io/docs/rook/v1.2/ceph-cluster-crd.html#osd-topology ) 中解释的那样。

我遵循的步骤：

我有一个 v1.16.3 Kubernetes 集群，其中有 1 个主服务器（test-m1）和两个工作人员（test-w1 和 test-w2）。我使用 Kubespray 的默认配置（https://kubespray.io/#/docs/getting-started）安装了这个集群。

我将我的节点标记为：

我添加了标签role=storage-node和污点storage-node=true:NoSchedule以强制 Rook 在特定存储节点上执行，以下是一个存储节点的标签和污点的完整示例：

我开始部署 Rook 的 common.yml ：https://github.com/rook/rook/blob/master/cluster/examples/kubernetes/ceph/common.yaml

我应用了一个自定义的 operator.yml 文件，以便能够在标记为“role=storage-node”的节点上运行操作员、csi-plugin 和代理：

然后我应用了我自己的自定义 ceph-cluster.yml 文件以允许 pod 在标记为“role=storage-node”的节点上运行

使用此配置，Rook 不会在 Crush Map 上应用标签。如果我安装 toolbox.yml ( https://rook.io/docs/rook/v1.2/ceph-toolbox.html )，进入并运行

我有以下输出：

如您所见，没有定义机架。即使我正确标记了我的节点。

令人惊讶的是，pod prepare-osd 可以检索以下日志第一行的信息：

您知道问题出在哪里，我该如何解决？

我几乎用这个命令添加了 repo

然后我运行命令

运算符首先创建，但随后变成 crashloopbackoff 错误。

下面是日志。

关于如何解决这个问题的任何想法？

我似乎在 fedora-coreos 上的 k8s 集群中部署 rook ceph 时遇到问题。我希望有人可以帮助我解决这个问题，我已经用谷歌搜索但找不到解决方案。下面是我的集群 yaml 和错误。在部署自定义 cluster.yaml 之前，我使用了默认的 common.yaml 和 operator.yaml。谢谢

集群-h2.yaml：

kubectl 日志 -f rook-ceph-mon-a-5cf78848c7-jthsn -n rook-ceph -c chown-container-data-dir：

kubectl -n rook-ceph 获取 pod：

前段时间，我在单节点k3s集群上用rook创建了一个ceph集群，就是为了试一试，效果很好。我能够通过 cephfs 为其他 pod 提供存储空间。我按照 rook quickstart 文档中给出的示例来执行此操作。

然而，两天前，在我没有任何干预的情况下，ceph 集群停止了工作。ceph manager pod 似乎有一个问题：我的 podrook-ceph-mgr-a-6447569f69-5prdw在循环中崩溃，这是它的事件：

不知道failed to sync secret cache是原因还是结果。是车问题还是k3s问题？

没有输出k3s kubectl logs rook-ceph-mgr-a-6447569f69-5prdw -n rook-ceph（添加 -p 没有任何改变）

谢谢你的帮助，这是我关于stackoverflow的第一个问题，希望它是正确的:)

尝试按照本指南在 kubernetes 上安装 rook-ceph：

https://rook.io/docs/rook/v1.3/ceph-quickstart.html

当我检查所有的豆荚

做一些其他操作

创建文件系统

再检查一遍

无法将 pod 视为rook-ceph-osd-.

而rook-ceph-mon-c-canary-78b48dbfb7-kfzzxpod 总是Pending.

如果安装工具箱为

https://rook.io/docs/rook/v1.3/ceph-toolbox.html

在容器内，检查 ceph 状态

它在 Ubuntu 16.04.6 上运行。

再次部署

描述待处理的 pod

测试支架

创建一个 nginx.yaml 文件

部署它并描述 pod 详细信息

我有以下内容Volume：

对于 pod dev-cockroachdb-0，我收到以下错误：

并且该吊舱x-namespace/dev-cockroachdb-0当前计划为node-5.xyz.com.

因此，如您所见，pod 本身与VolumeAttachment. node-6.xyz.com与node-5.xyz.com。

问题：

• Nodein是否Volume.Attachments指向 pod（卷所附加的）所在的节点？（因此，如果卷附加到 node 上的 pod NodeA，那么卷附加的 node 字段的值将是NodeA）
• 由于未能正确分离某个节点上的卷，是否可能会发生此错误？

我正在将 rook-ceph 部署到 minikube 集群中。一切似乎都在工作。我在 vm 中添加了 3 个未格式化的磁盘并连接了它。我遇到的问题是，当我运行 ceph status 时，我收到一条健康温暖的消息，告诉我“1 pg 过小”。我该如何解决这个问题？

文档（https://docs.ceph.com/docs/mimic/rados/troubleshooting/troubleshooting-pg/）声明“如果您尝试在单个节点上创建集群，则必须更改 osd crush 的默认值在创建监视器和 OSD 之前，在 Ceph 配置文件中将 chooseleaf 类型设置从 1（表示主机或节点）到 0（表示 osd）。 “我不知道在哪里进行此配置，但如果有任何其他方法可以解决此问题我应该知道的，请告诉我。谢谢！

如果 1 个 OSD 崩溃，rook-ceph 最终会尝试将丢失的数据复制到仍在工作的 OSD 上，还是等待所有 OSD 恢复健康？假设是这样，我可以解释我是如何计算的：

我开始为 kubernetes PVC 和 3 个 745 GB 的节点（总共 2.23 TB）预置 1.71 TB。Rook 的复制因子为 2 (RF=2)。

为了使复制工作，我需要 2 倍 1,71 TB（3,42 TB），所以我添加了 2 个节点，每个节点 745 GB（总共 3,72 TB）假设我使用了所有 1,71 TB 的预置。

如果我丢失了一个 OSD，我的 K8S 集群仍然运行，因为数据被复制了，但是当丢失的数据在仍然工作的 OSD 上被复制时，其他 OSD 可能会崩溃，因为假设 OSD 总是均匀分布（我知道这在很长一段时间内是不正确的）跑） ：

• 我的集群上有 290 GB 未使用空间（总共 3,72 - 3,42 PVC 配置）
• 每个 OSD 58 GB (290 / 5)
• 崩溃的 OSD 有 687 GB（总共 745 个磁盘 - 58 GB 未使用）
• Ceph 尝试在剩余的每个 OSD 上复制 172 GB 缺失数据 (687/4)
• 这太多了，因为我们只剩下 58 GB，这应该会导致 OSD 故障级联

如果我有 6 个节点而不是 5 个，我可以无限期地释放 1 个 OSD：

• 新池为 4.5 TB (6x745)
• 我在集群上有 1+ TB 可用空间（总共 4,5 - 3,42 PVC 配置）
• 每个 OSD 166+ GB (~1 TB / 6)
• 崩溃的 OSD 最大有 579+ GB 数据。(745 - 166)
• Ceph 尝试在剩余的每个 OSD 上复制少于 100 GB 的缺失数据 (579 / 6)
• 这小于每个 OSD 上的可用空间（166+ GB）所以复制再次工作只剩下 5 个节点但如果另一个 OSD 崩溃我注定要失败。

最初的假设是否正确？如果是这样，数学听起来对你吗？