我有一个配置如下的容器：
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
目录或创建
如用户@DazWilkin:所示
IIUC，如果您的集群使用容器优化虚拟机，您需要了解这些实例的文件系统结构。
请参阅https://cloud.google.com/container-optimized-os/docs/concepts/disks-and-filesystem
这是正确的理解。由于：，您不能像：/那样写入只读位置(即使有SYS_ADMIN和privileged参数)
根文件系统以只读方式安装，以保护系统完整性。但是，主目录和/mnt/stateful_partition是持久的和可写的。
--Cloud.google.com：容器优化操作系统：文档：概念：磁盘和文件系统：文件系统
对于解决方案，您可以更改hostPath在节点上的位置，或者对使用Ubuntu图像而不是Container Optimized OS图像的节点使用GKE。您将能够使用问题中指定路径的hostPath卷。您可以通过以下官方文档阅读更多关于可用节点图像的信息：
- Cloud.google.com:Kubernetes引擎：节点映像
如果您的工作负载/用例允许使用Persistent Volumes，我鼓励您这样做。
PersistentVolume资源用于管理群集中的持久存储。在GKE中，PersistentVolumes通常由计算引擎持久磁盘支持。
<--->；
PersistentVolumes是独立于Pod存在的集群资源。这意味着，随着集群的更改以及Pod的删除和重新创建，由PersistentVolume表示的磁盘和数据将继续存在。PersistentVolume资源可以通过PersistentVolumeClaims动态配置，也可以由集群管理员显式创建。
--Cloud.google.com:Kubernetes引擎：持久卷
您也可以考虑使用hostPath类型的Volume:的Local SSD解决方案
- Cloud.google.com:Kubernetes引擎：持久卷：本地SSD
在创建集群时，由于其他原因，我给了它一个
devstorage.read_write作用域，但我想知道是否也需要其他作用域？
您可以创建GKE集群，而无需添加任何其他作用域，如：
$ gcloud container clusters create --zone=ZONE
：--scopes=SCOPE将取决于您打算在其上运行的工作负载。您可以分配将授予您访问特定云平台服务(例如，云存储)的权限的作用域。
您可以通过以下gcloud在线手册了解更多信息：
- Cloud.google.com:SDK:Gcloud:Container:Clusters:Create:Scopes
添加到云平台服务的身份验证主题：
有三种方法可以使用GKE中的服务帐户对谷歌云服务进行身份验证：
- 使用工作负载标识
WorkloadIdentity是从GKE向谷歌云服务进行身份验证的推荐方式。Workload Identity允许您使用Kubernetes资源配置Google Cloud服务帐户。如果这适合您的用例，那么它应该是您的第一个选择。此示例旨在涵盖WorkloadIdentity不太适合的用例。
- 使用默认的计算引擎服务帐户
GKE集群中的每个节点都是一个计算引擎实例。因此，在GKE集群上运行的应用程序默认情况下将尝试使用"；计算引擎默认服务帐户"；，并继承关联的作用域。
此默认服务帐户可能有权也可能没有权使用您需要的谷歌云服务。可以扩展默认服务帐户的作用域，但这可能会产生安全风险，因此不建议使用。
- 使用机密管理服务帐户凭据
您的最终选择是为应用程序创建一个服务帐户，并将身份验证密钥作为Kubernetes机密注入。这将是本教程的重点。
--Cloud.google.com:Kubernetes引擎：云平台身份验证
IIUC，如果您的集群使用容器优化虚拟机，则需要了解这些实例的文件系统结构。
请参阅https://cloud.google.com/container-optimized-os/docs/concepts/disks-and-filesystem