我正在使用mysql Kubernetes statefulset,我将PV映射到主机目录(CentOS 8 VM),但得到“ pod具有未绑定的立即PersistentVolumeClaims”
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql-container
spec:
serviceName: mysql
replicas: 1
selector:
matchLabels:
app: mysql-container
template:
metadata:
labels:
app: mysql-container
spec:
containers:
- name: mysql-container
image: mysql:dev
imagePullPolicy: "IfNotPresent"
envFrom:
- secretRef:
name: prod-secrets
ports:
- containerPort: 3306
# container (pod) path
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pvc
volumeClaimTemplates:
- metadata:
name: data
spec:
storageClassName: localstorage
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 3Gi
selector:
matchLabels:
type: local
存储类是 defaulr 且 PV 中没有事件
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: localstorage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
reclaimPolicy: Delete
allowVolumeExpansion: True
kind: PersistentVolume
apiVersion: v1
metadata:
name: mysql-01
labels:
type: local
spec:
storageClassName: localstorage
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/mysql01"
---
kind: PersistentVolume
apiVersion: v1
metadata:
name: mysql-02
labels:
type: local
spec:
storageClassName: localstorage
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/mysql02"
存储类为默认存储类 1
get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
localstorage (default) kubernetes.io/no-provisioner Delete Immediate true 35m
PVC 也不显示任何事件:
Name: data-mysql-0
Namespace: default
StorageClass: localstorage
Status: Pending
Volume: mysql-storage
Labels: app=mysql
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 0
Access Modes:
VolumeMode: Filesystem
Mounted By: mysql-0
Events: <none>
Name: mysql-01
Labels: type=local
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-01"},"spec":{"accessMode...
Finalizers: [kubernetes.io/pv-protection]
StorageClass: localstorage
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 10Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/mysql01
HostPathType:
Events: <none>
Name: mysql-02
Labels: type=local
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-02"},"spec":{"accessMode...
Finalizers: [kubernetes.io/pv-protection]
StorageClass: localstorage
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 10Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/mysql02
HostPathType:
Events: <none>
Pod 处于挂起状态:
> Events:
> Type Reason Age From Message
> ---- ------ ---- ---- -------
> Warning FailedScheduling 27s (x2 over 27s) default-scheduler error while running >"VolumeBinding" filter plugin for pod "mysql-0": pod has unbound immediate PersistentVolumeClaims
有人可以指出这里还应该做什么吗,谢谢
上述错误可能由多种原因引起 - 以下是我遇到的几个选项。
例 1
持久卷控制器
无法找到容量大小等于或大于 PVC
中指定的值的 PV
。
因此,如果我们举这个例子:
# PVC
resources:
requests:
storage: 3Gi
# PV
capacity:
storage: 10Gi
所以:
如果光伏容量
如果不是,那么我们将在 pod 级别收到
未绑定的即时 PersistentVolumeClaims
错误,并且在描述 PVC 时没有与名称匹配的卷插件
。
例 2
PVC的数量高于PV。
例如,如果只创建一个 PV(或删除其他 PV):
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mongo-local-pv 50Gi RWO Retain Bound default/mongo-persistent-storage-mongo-0 local-storage 106m
我们可以看到一些工作负载(Pods 或有状态集)将停留在挂起状态:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongo-0 2/2 Running 0 3m38s
mongo-1 0/2 Pending 0 3m23s
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mongo-persistent-storage-mongo-0 Bound mongo-local-pv 50Gi RWO local-storage 80m
mongo-persistent-storage-mongo-1 Pending local-storage 45m
我们将在挂起的资源上收到上述错误。
例 3
如果调度程序未能将节点与 PV 匹配。
使用本地卷时,PV 的节点关联性是必需的,并且应该是群集中现有
节点
的值:
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-mongo-pv
.
.
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node-which-doesnt-exists # <----- Will lead to the error
例 4
群集上已存在具有相同名称和不同配置的旧
PV
,并根据它们创建新的 PVC
。
使用本地卷时,管理员每次都必须执行手动清理并重新设置本地卷以供重复使用。
(*)创建此本地静态配置器是为了帮助完成 PV 生命周期。
如果匹配的 PersistentVolume
不存在,则 PersistentVolumeClaims
将无限期地保持未绑定状态。持久卷
与访问模式
和容量
相匹配。在这种情况下,PV的容量
为10Gi
,而PVC的容量
为3Gi
。
PV 中的容量
需要与声明中的容量相同,即 3Gi
以修复未绑定的即时 PersistentVolumeClaims
问题。
我已经定义了以下复制控制器JSON: 使用“docker run-t-I-p 0 . 0 . 0 . 0:9021:80-v/mnt/NFS/WordPress _ a:/mnt/NFS/WordPress _ a:rw internal user/PHP 53”运行时,容器正确启动。 /mnt/nfs/wordpress_a是一个nfs共享,安装在所有的minions上。每个minion都有完全
我正在尝试在DigitalOcean的Kubernetes中运行一个Redis集群。作为一个poc,我只是尝试运行了我在网上找到的一个示例(https://github.com/sanderploegsma/redis-cluster/blob/master/redis-cluster.yml),该示例能够在使用Minikube本地运行时适当地旋转POD。 然而,当在Digital Ocean上运
由于绑定是在绑定模块中定义的,Google Guice 会在需要注入依赖项时使用它们。如果不存在绑定,它可以尝试创建即时绑定。绑定模块中存在的绑定称为显式绑定并且具有更高的优先级,而即时绑定称为隐式绑定。如果两种类型的绑定都存在,则考虑使用显式绑定进行映射。 以下是三种类型的即时绑定的示例。 绑定类型 描述 可注入的构造函数 非私有、无参数构造函数有资格进行即时绑定。另一种方法是使用@Inject
《Kubernetes权威指南第五版 4.5.2节》 在这个yaml文件中创建了一个 pod,并指定了hostname和subdomain 同时创建了一个service, 书中提到 service的名称必须要和subdomain保持一致。 测试发现如果不保持一致 那么在其他Pod的容器中执行 wget webapp-1.mysubdomain.default.svc.cluster.local:8
由于绑定是在绑定模块中定义的,因此只要需要注入依赖关系,Guice就会使用它们。 如果不存在绑定,它可以尝试创建即时绑定。 绑定模块中存在的绑定称为显式绑定,具有更高的优先级,而即时绑定称为隐式绑定。 如果存在两种类型的绑定,则考虑使用显式绑定进行映射。 以下是三种即时绑定的示例。 Sr.No. 绑定类型和描述 1 可注射的构造函数 非私有,无参数构造函数符合即时绑定的条件。 另一种方法是使用@I
Kubernetes中需要考虑三个级别的度量集合—节点、Pod和在Pod中运行的应用程序。 对于节点和应用程序指标,我有非常有效的解决方案,但我仍停留在pod指标上。 我尝试过cAdvisor和Kube状态指标,但它们都没有给我想要的东西。Kube状态指标仅提供已知的信息,例如pod CPU限制和请求。cAdvisor不会将pod标签插入容器名称,因此我无法知道哪个pod行为不端。 给定一个pod
Kubernetes Pod Chaos Monkey This repository contains a Dockerfile and associated Kubernetes configuration for a Deployment that will randomly delete pods in a given namespace. This is implemented in B
我希望一个应用程序从队列中提取一个项目,在队列中处理该项目,然后销毁它自己。拉->过程->破坏。 我已经研究了使用作业模式队列和每个工作项的Pod,因为这适合于使用,但是,当我需要作业在队列为空时自动缩放AKA0/1 Pod,并且在添加项时缩放到某个点时,这是不合适的。我能看到的唯一方法是通过部署,但这将删除每个工作项带有Pod的队列模式。每个项目必须有一个新鲜容器。 有没有一种方法可以让每个工作