[英]Statefulset with replicas : 1 pod has unbound immediate PersistentVolumeClaims
我正在尝试在我的单节点集群(Docker Desktop Windows)中设置一个弹性集群。 为此,我创建了如下的 PV(工作)
apiVersion: v1
kind: PersistentVolume
metadata:
name: elastic-pv-data
labels:
type: local
spec:
storageClassName: elasticdata
accessModes:
- ReadWriteOnce
capacity:
storage: 20Gi
hostPath:
path: "/mnt/data/elastic"
然后这里是配置:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: esnode
spec:
selector:
matchLabels:
app: es-cluster # has to match .spec.template.metadata.labels
serviceName: elasticsearch
replicas: 2
updateStrategy:
type: RollingUpdate
template:
metadata:
labels:
app: es-cluster
spec:
securityContext:
fsGroup: 1000
initContainers:
- name: init-sysctl
image: busybox
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
command: ["sysctl", "-w", "vm.max_map_count=262144"]
containers:
- name: elasticsearch
resources:
requests:
memory: 1Gi
securityContext:
privileged: true
runAsUser: 1000
capabilities:
add:
- IPC_LOCK
- SYS_RESOURCE
image: docker.elastic.co/elasticsearch/elasticsearch-oss:7.7.1
env:
- name: ES_JAVA_OPTS
valueFrom:
configMapKeyRef:
name: es-config
key: ES_JAVA_OPTS
readinessProbe:
httpGet:
scheme: HTTP
path: /_cluster/health?local=true
port: 9200
initialDelaySeconds: 5
ports:
- containerPort: 9200
name: es-http
- containerPort: 9300
name: es-transport
volumeMounts:
- name: es-data
mountPath: /usr/share/elasticsearch/data
volumeClaimTemplates:
- metadata:
name: es-data
spec:
storageClassName: elasticdata
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
结果是只有一个“pod”将其 pvc 绑定到 pv,另一个出现错误循环“0/1 个节点可用:1 个 pod 具有未绑定的即时 PersistentVolumeClaims”。 这是kubectl get pv,pvc结果:
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/elastic-pv-data 20Gi RWO Retain Bound default/es-data-esnode-0 elasticdata 14m
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/es-data-esnode-0 Bound elastic-pv-data 20Gi RWO elasticdata 13m
如果我理解正确,我应该有第二个具有以下标识符的 persistantolumeclaim:es-data-esnode-1 有什么我遗漏或没有正确理解的吗? 谢谢你的帮助
我在这里跳过不相关的部分(configmap、loadbalancer、..)
当使用带有volumeClaimTemplates
的StatefulSet
时,它将为每个副本创建一个PersistentVolumeClaim
。 因此,如果您使用replicas: 2
,将创建两个不同的 PersistentVolumeClaims, es-data-esnode-0
和es-data-esnode-1
。
每个PersistentVolumeClaim
都将绑定到一个唯一的PersistentVolume
,因此在有两个 PVC 的情况下,您将需要两个不同的PersistentVolumes
。 但这在桌面设置中使用volumeClaimTemplate
和hostPath
-volumes 并不容易。
在这种情况下,您出于什么原因需要replicas: 2
? 它通常用于提供更好的可用性,例如使用多个节点。 但是对于桌面环境中的本地设置,通常单个节点上的单个副本应该没问题? 我认为对您来说最简单的解决方案是使用replicas: 1
。
让我在评论和乔纳斯的回答中已经说过的内容中添加一些细节。
从评论中推断,您尚未定义名为elasticdata
的StorageClass
。 如果它不存在,则不能在PV
和PVC
中引用它。
快速浏览一下如何使用hostPath
来定义PersistentVolume
以及如何在PersistentVolumeClaim
中引用它。 在这里您可以看到示例中使用了storageClassName: manual
。 Kube.netes 文档没有明确说明,但如果您查看Openshift 文档,它会非常清楚地说明:
使用 hostPath 卷的 Pod 必须通过手动(静态)配置进行引用。
它不仅仅是一些用于将PVC
请求绑定到这个特定PV
的值。 所以如果没有定义elasticdata
StorageClass
,你不应该在这里使用它。
第二件事。 正如Jonas在他的评论中已经指出的那样, PVC
和PV
之间存在一对一的绑定,因此无论您的PV
是否仍有足够的容量,它已经被另一个PVC
并且不再可用。 正如您在官方文档中所读:
PVC 到 PV 的绑定是一对一的映射,使用 ClaimRef,它是 PersistentVolume 和 PersistentVolumeClaim 之间的双向绑定。
如果不存在匹配的卷,索赔将无限期保持不受约束。 当匹配卷可用时,声明将被绑定。 例如,配置有许多 50Gi PV 的集群将无法匹配请求 100Gi 的 PVC。 当一个100Gi的PV加入集群时,PVC就可以绑定了。
反之亦然。 如果只有一个 100Gi PV,它将无法满足两个PVC
要求每个 50Gi 的请求。 请注意,在您发布的kubectl get pv,pvc
的结果中, PV
和PVC
的容量均为20Gi
,尽管您在从PVC
模板创建的每个PVC
中仅请求3Gi
。
您在这里不使用任何动态存储配置器,因此您需要根据用例的需要手动提供尽可能多的PersistentVolumes
。
顺便说一句,我宁愿建议您使用具有正确定义的StorageClass
的local
卷,而不是使用hostPath
。 与HostPath
相比,它有一些优势。 此外,可以单独运行外部 static 供应器,以改进对本地卷生命周期的管理
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.