如何解决Google Kubernetes EngineGKE集群由于“只读文件系统”而在创建安装源路径时出错
我有一个具有以下配置的容器：
spec:
template:
spec:
restartPolicy: OnFailure
volumes:
- name: local-src
hostPath:
path: /src/analysis/src
type: DirectoryOrCreate
containers:
securityContext:
privileged: true
capabilities:
add:
- SYS_ADMIN
- 请注意，我故意省略了一些其他配置参数，以使问题简短一些
但是，当我将其部署到gcloud上的kubernetes上的群集中时，看到以下错误：
Error: failed to start container "market-state": Error response from daemon: error while creating mount source path '/src/analysis/src': mkdir /src: read-only file system
我尝试使用minikube在本地部署完全相同的作业，并且效果很好。
我的猜测是，这与相对于主机的pod的权限有关，但是在我设置的SYS_ADMIN权限下，我希望它可以正常工作。创建群集时，出于其他原因，我给它提供了devstorage.read_write范围，但想知道是否还需要其他范围？
gcloud container clusters create my_cluster \
--zone us-west1-a \
--node-locations us-west1-a \
--scopes=https://www.googleapis.com/auth/devstorage.read_write
DirectoryOrCreate
解决方法
IIUC，如果您的群集使用的是容器优化的VM，则需要了解这些实例的文件系统结构。
请参见https://cloud.google.com/container-optimized-os/docs/concepts/disks-and-filesystem
,@DazWilkin用户指出：
IIUC，如果您的群集使用的是容器优化的VM，则需要了解这些实例的文件系统结构。
请参见https://cloud.google.com/container-optimized-os/docs/concepts/disks-and-filesystem
这是正确的理解。由于以下原因，您无法写入/这样的只读位置（即使使用SYS_ADMIN和privileged参数也是如此）：
根文件系统被挂载为只读文件，以保护系统完整性。但是，主目录和/ mnt / stateful_partition是持久的且可写的。
- Cloud.google.com: Container optimized OS: Docs: Concepts: Disk and filesystem: Filesystem
对于解决方法解决方案，您可以更改hostPath在节点上的位置，或者将GKE与使用Ubuntu图像而不是{ {1}}张图片。您将可以将Container Optimized OS卷与问题中指定的路径一起使用。您可以通过以下官方文档了解有关可用节点映像的更多信息：
如果您的工作量/用例允许使用hostPath，我鼓励您这样做。
PersistentVolume资源用于管理集群中的持久存储。在GKE中，PersistentVolume通常由Compute Engine永久磁盘支持。
PersistentVolume是独立于Pods存在的群集资源。这意味着，随着群集的更改以及Pod的删除和重新创建，PersistentVolume表示的磁盘和数据将继续存在。可以通过PersistentVolumeClaims动态设置PersistentVolume资源，也可以由集群管理员显式创建它们。
您还可以考虑使用Persistent Volumes类型的Local SSD的{{1}}解决方案：
创建集群时，出于其他原因，我给它提供了一个
hostPath范围，但想知道是否还需要其他范围？
您可以创建Volume集群，而无需添加任何其他范围，例如：
-
devstorage.read_write
GKE将取决于您打算在其上运行的工作负载。您可以分配范围，以授予您访问特定Cloud Platform服务（例如Cloud Storage）的权限。
您可以通过阅读$ gcloud container clusters create --zone=ZONE在线手册来了解有关此内容的更多信息：
要添加到Cloud Platform服务的身份验证主题：
有三种方法可以使用GKE中的服务帐户对Google Cloud服务进行身份验证：
- 使用工作负载身份
工作负载身份是从GKE向Google Cloud服务进行身份验证的推荐方法。通过Workload Identity，您可以使用Kubernetes资源配置Google Cloud服务帐户。如果适合您的用例，则应该是首选。该示例旨在涵盖Workload Identity不适合的用例。
- 使用默认的Compute Engine服务帐户
GKE群集中的每个节点都是Compute Engine实例。因此，默认情况下，在GKE群集上运行的应用程序将尝试使用“ Compute Engine默认服务帐户”进行身份验证，并继承关联的作用域。
此默认服务帐户可能具有或不具有使用所需的Google Cloud服务的权限。可以扩展默认服务帐户的范围，但这会带来安全风险，因此不建议这样做。
- 使用机密管理服务帐户凭据
您最后的选择是为您的应用程序创建一个服务帐户，并将身份验证密钥作为Kubernetes机密注入。这将是本教程的重点。
- Cloud.google.com: Kubernetes Engine: Authenticating to Cloud Platform
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。