kubernetes - 如何从存储编排的角度解释 "mount storage in a seamless manner"

Question

正在上课 Introduction to Kubernetes我遇到了这句话:

借助 Kubernetes 及其插件，我们可以基于软件定义存储 (SDS)，以无缝方式自动将本地、外部和存储解决方案挂载到容器。

我以前见过，但从未见过seamless manner的解释。

什么是无缝方式？存储编排有哪些方式？

Answer 1

作为noted here ，所有这些资源都将以相同的方式声明/安装:

使用卷持久化数据

When a Pod is deleted or a container restarts, any and all data in the container’s filesystem is also deleted.

To persist data beyond the pod, use Volumes.

There are 2 additions to add volumes to pods:

• spec.volumes
  This array defines all of the volumes that may be accessed by containers in the Pod manifest. Note that not all containers are required to mount all volumes defined in the Pod.
• volumeMounts
  This array defines the volumes that are mounted into a particular container, and the path where each volume should be mounted. Note that two different containers in a Pod can mount the same volume at different mount paths.

So, first in spec.volumes, we define what volumes may be used by the containers in the Pod.
And, in volumeMounts, we actually use them

示例(来自同一篇文章):

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  volumes:
    - name: "kuard-data"
      hostPath:
        path: "/var/lib/kuard"
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      volumeMounts:
        - mountPath: "/data"
          name: "kuard-data"
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

Here, we define kuard-data as the volume, and then mount it on the kuard container.

There are various types of volumes:

• emptyDir
  • Such a volume is scoped to the Pod’s lifespan, but it can be shared between two containers. (in our example above, this forms the basis for communication between our Git sync and web serving containers). This survives the pod restart
• hostDir
  • this can mount arbitrary locations on the worker node into the container
  • this was used in the example above
  • This can be used when the pod wants to direct access to the instance’s block storage for eg. But shouldn’t be used to store ordinary data since not all the hosts would have the same underlying dir structure.
• network storage
  • if you want the data to stay with the Pod even when the pod is moved around, restarted etc, use one of the several options available in the network based storage
  • Kubernetes includes support for standard protocols such as NFS and iSCSI as well as cloud provider–based storage APIs for the major cloud providers (both public and private)

即:

# Rest of pod definition above here
   volumes:
       - name: "kuard-data"
         nfs:
           server: my.nfs.server.local
           path: "/exports"

---

“无缝”部分指的是“Migrating to CSI drivers from in-tree plugins”中提出的类似概念

The CSI Migration feature, when enabled, directs operations against existing in-tree plugins to corresponding CSI plugins (which are expected to be installed and configured).
The feature implements the necessary translation logic and shims to re-route the operations in a seamless fashion.
As a result, operators do not have to make any configuration changes to existing Storage Classes, PVs or PVCs (referring to in-tree plugins) when transitioning to a CSI driver that supersedes an in-tree plugin.

Before the introduction of CSI and Flexvolume, all volume plugins (like volume types listed above) were “in-tree” meaning they were built, linked, compiled, and shipped with the core Kubernetes binaries and extend the core Kubernetes API.
This meant that adding a new storage system to Kubernetes (a volume plugin) required checking code into the core Kubernetes code repository.

因此这里的“无缝方式”除了初始卷声明外很少或根本没有配置。