为什么将GCE卷安装在kubernetes容器中会导致延迟? [英] Why does a GCE volume mount in a kubernetes pod cause a delay?

问题描述

我有一个kubernetes容器，我使用持久性卷声明将GCE持久性卷附加到了该容器. (有关更严重的问题，但没有批量声明，请参阅:安装gcePersistentDisk kubernetes卷非常慢)

I have a kubernetes pod to which I attach a GCE persistent volume using a persistence volume claim. (For the even worse issue without a volume claim see: Mounting a gcePersistentDisk kubernetes volume is very slow)

如果没有连接任何卷，则窗格将立即启动(最多2秒).但是，如果Pod具有GCE持久卷安装，则在20到60秒之间到达Running状态.我正在使用不同的磁盘大小(10、200、500 GiB)和创建多个Pod进行测试，该大小似乎与延迟无关.

When there is no volume attached, the pod starts in no time (max 2 seconds). But when the pod has a GCE persistent volume mount, the Running state is reached somewhere between 20 and 60 seconds. I was testing with different disk sizes (10, 200, 500 GiB) and multiple pod creations and the size does not seem to be correlated with the delay.

这种延迟不仅发生在开始中，而且发生在开始中，而且还发生在使​​用复制控制器执行滚动更新或 >代码在运行时崩溃.

And this delay is not only happening in the beginning but also when rolling updates are performed with the replication controllers or when the code crashes during runtime.

下面我有kubernetes规范:

Below I have the kubernetes specifications:

复制控制器

{
    "apiVersion": "v1",
    "kind": "ReplicationController",
    "metadata": {
        "name": "a1"
    },
    "spec": {
        "replicas": 1,
        "template": {
            "metadata": {
                "labels": {
                    "app": "a1"
                }
            },
            "spec": {
                "containers": [
                    {
                        "name": "a1-setup",
                        "image": "nginx",
                        "ports": [
                            {
                                "containerPort": 80
                            },
                            {
                                "containerPort": 443
                            }
                        ]
                    }
                ]
            }
        }
    }
}

批量索赔

{
    "apiVersion": "v1",
    "kind": "PersistentVolumeClaim",
    "metadata": {
        "name": "myclaim"
    },
    "spec": {
        "accessModes": [
            "ReadWriteOnce"
        ],
        "resources": {
            "requests": {
                "storage": "10Gi"
            }
        }
    }
}

和音量

{
    "apiVersion": "v1",
    "kind": "PersistentVolume",
    "metadata": {
        "name": "mydisk",
        "labels": {
             "name": "mydisk"
        }
    },
    "spec": {
        "capacity": {
            "storage": "10Gi"
        },
        "accessModes": [
            "ReadWriteOnce"
        ],
        "gcePersistentDisk": {
            "pdName": "a1-drive",
            "fsType": "ext4"
        }
    }
}

也

推荐答案

GCE(以及AWS和OpenStack)必须首先将磁盘/卷附加到节点上，然后才能将其挂载并公开到您的Pod中.连接所需的时间取决于云提供商.

GCE (along with AWS and OpenStack) must first attach a disk/volume to the node before it can be mounted and exposed to your pod. The time required for attachment is dependent on the cloud provider.

对于由ReplicationController创建的Pod，必须执行附加的分离操作.同一磁盘不能连接到多个节点(至少不能以读/写模式).分离和pod清理发生在与附加线程不同的线程中.具体来说，在节点上运行的Kubelet必须将其当前具有的Pod(及其体积之和)与节点上当前存在的体积进行协调.孤立的卷将被卸载和分离.如果您的Pod已安排在其他节点上，则它必须等待，直到原始节点分离该卷为止.

In the case of pods created by a ReplicationController, there is an additional detach operation that has to happen. The same disk cannot be attached to more than one node (at least not in read/write mode). Detaching and pod cleanup happen in a different thread than attaching. To be specific, Kubelet running on a node has to reconcile the pods it currently has (and the sum of their volumes) with the volumes currently present on the node. Orphaned volumes are unmounted and detached. If your pod was scheduled on a different node, it must wait until the original node detaches the volume.

集群最终会达到正确的状态，但是每个组件可能要花一些时间才能到达那里.这是您的等待时间.

The cluster eventually reaches the correct state, but it might take time for each component to get there. This is your wait time.

这篇关于为什么将GCE卷安装在kubernetes容器中会导致延迟?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！