psp资源网站,psp中文游戏资源

来源：优游网责编：网络时间：2025-09-03 18:35:04

老玩家泪流满面！这些PSP的经典软件你都记得吗

1PSP播片看书神器回顶部

【PConline 应用】不知不觉一年又快过去了，时间已经走到了12月份。如果你是一名老玩家，也许这个月份会唤起你一些久远的记忆——在2004年12月，索尼发布了经典的PSP游戏掌机，这机器在不少人的心中就是神一般的存在。尽管它的销量并不如竞争对手任天堂NDS，但在很多老玩家特别是中国玩家的心目中，PSP才是真正的神机。

你还记得PSP上的种种经典么？

PSP之所以神，不仅在于其本职的游戏表现，还在于破解后的PSP简直就是同年代无出其右的“智能机”。没错，在iPhone和Android出现之前，最强大的掌上娱乐设备绝不是什么塞班WM，而是PSP这部游戏机！得益于破解，PSP能够安装很多在当时令人啧啧称奇的软件。那么PSP上到底有什么经典软件呢？今天，我们就一起来回顾PSP上曾经风靡一时的经典软件，不知老玩家看了心里是否会有一丝触动？

PMPlayer Advance（PPA）：让PSP化身播片神器

PSP之所以能在那个年代压塞班、WM和Plam一头，成为最受欢迎的掌上娱乐设备，除了游戏外，看片绝对是最有力的理由了。得益于PSP的CPU和屏幕，它拥有媲美同年代MP4播放器的播片能力。破解PSP后，安装PPA播放器，PSP俨然就是你的掌上电影院！

PPA是PSP上的播片神器

PPA播放器是PSP上最流行的视频播放软件，它支持MP4、MKV、FLA等视频格式，难得的是它竟然可以支持AVC编码——直到现在，AVC编码的视频仍在被广泛使用。PPA不仅视频播放能力强劲，而且还支持外挂字幕、皮肤切换、音轨选择、查看视频详细信息等功能，这相当了不起，要知道现在iOS和Android上的视频播放器最有用的功能无非也就是这几项。

PPA的功能还是很强的

安装了PPA后，只要把视频放到VIDEO目录，就可以读取播放了。PPA在PSP上最高可以播放480p的视频，不过考虑到流畅和节电，还是480×272分辨率、AVC编码的MP4视频最为合适。虽然这个规格现在看起来有点怪，但在PSP风靡的时代，大量站点都提供这种PSP专有规格的视频下载，电脑也有PSPVC这样的专门转格式软件，资源根本不是问题。无数小伙伴用手中的PSP看完了一部部片，翻翻你久未开机的PSP的记忆棒，里面说不定还有火影的动画。

xReader：PSP上最好的电子书阅读器

PSP的大屏幕造就了看片时得天独厚的优势，也令它得到了同年代无与伦比的看书体验。在PSP上，xReader或许是就是最好的电子书阅读器了。使用xReader，你可以在PSP上看txt、umd、pbd、chm等格式的电子书，甚至还支持zip和rar这样的压缩文件。能够调整字号字体以及背景。由于PSP有实体按键，因此用xReader来看书，操作还是非常舒爽的。

在PSP上用xReader看书体验明显好于当时的手机

PSP流行之时也正值网络小说的爆发，不少朋友都在PSP上用xReader看了一本本经典的网络小说，例如《诛仙》、、《搜神记》等等。除了xReader外，PSP上还存在其他看书软件，例如用来看PDF的Bookr、用来看漫画的PSP Comic等等，它们的存在令PSP的看书体验在同年代出类拔萃。由于用PSP看电子书不会发出声音、不需要做什么激烈操作，因此偷偷用PSP看书也是很多小伙伴最常见的课堂小动作。回忆起上课不认真听讲的自己，心里会不会有些许后悔呢？

2PSP听歌录音工具回顶部

LyricShow/Cover Flow：PSP上的听歌利器

除了可以看视频看书，PSP也完全能够充当音乐播放器。平心而论，PSP的推力并不强，但音色却比较讨喜，是比较柔和的风格。加上拥有3.5mm耳机接口以及索尼的牌子，所以还是很多人选择用PSP听歌的。实际上，PSP本身就自带音乐播放功能，不过通过安装一些音乐播放器，还能够实现更多音乐播放的相关功能。例如通过安装LyricShow，PSP在播放音乐时可以显示歌词。

在网络音乐App尚未流行的时候，听歌想要看歌词，最便利的方法或许就是通过LRC歌词文件来实现歌词滚动。而LyricShow这款PSP上的软件，就能够让PSP支持LRC歌词显示。在当年，不少MP3播放器都把LRC显示作为卖点，而PSP通过安装软件就可以实现，绝对算得上是性价比之选了。

可以听歌看歌词的LyricShow

除了显示歌词，封面的显示也是当年听歌的噱头之一。还记得初代iPhone发布时华丽的Cover Flow界面吗？会3D旋转的音乐播放器瞬间俘获了很多人的心。而PSP通过安装Cover Flow软件，也可以实现iPhone音乐播放器那样的封面切换效果，非常华丽。

PSP也可以做到华丽的Cover Flow

Audio Mechanica：PSP能当录音笔

除了听歌，PSP还可以录音。通过安装Audio Mechanica这款软件，就可以轻松实现录音功能。

Audio Mechanica是PSP上的录音软件

Audio Mechanica能够让PSP进行录音，后期的PSP型号是带有麦克风的，利用Audio Mechanica能够进一步发挥机器的潜力。不过，Audio Mechanica录音是用WAV格式保存的，体积比较大，这也许是由于PSP的机能不足以实现边录音边压缩吧。不过Audio Mechanica的录音效果还不错，想要简单录音的话，还是可以尝试一下的。

3PSP逆天的模拟器回顶部

PSPKVM：手机能做的PSP也能做

之所以说PSP是当年最强的掌上娱乐设备，力压同年代手机，PSPKVM也功不可没。当年的非智能机例如索爱、诺基亚S40等也是可以通过JAVA来安装第三方软件的，这些非智能机和S60之类的智能机，体验差距并非天差地别；而PSP则可以通过PSPKVM这款软件，运行JAVA程序，手机能干的事它也能干！

PSPKVM让PSP也可以运行手机JAVA程序

PSPKVM能够让PSP运行j2me程序，而且它还支持虚拟键盘，因此一些手机软件在PSP上是可以比较完美地运行的。由于PSP是一部游戏机，因此很多朋友会用PSPKVM来运行一些手游，毕竟PSP的操作可比手机好得多。PSPKVM在后期还加入了诺基亚UI，兼容性更上一层楼。

某些可以自适应分辨率的JAVA程序在PSP上体验挺好，例如Opera Mini

当然，要玩游戏的话，PSP本身的游戏远比手游出彩，因此用PSP来运行一些手机软件才更体现PSPKVM的价值。利用PSPKVM，PSP能够运行起UC浏览器、QQ等手机软件。PSP运行这类软件还是有优势的，一来屏幕大，而来它支持WiFi，当年的手机要出国行却得把WiFi先阉割了。因此，用PSPKVM运行手机浏览器上网，体验也别有一番风味。

各种游戏模拟器：通杀街机小霸王GBA

不得不说，PSP“神机”的名号，很大一部分是各种各样的模拟器造就的。前面提到模拟JAVA手机的PSPKVM自然是一个，但PSP上最神的模拟器，还是各种各样的游戏机模拟器。

PSP可以通过模拟器运行很多游戏，例如NesterJ可以运行红白机游戏

PSP上有啥模拟器？就算是老玩家，恐怕一时半会儿也是数不清的。例如通过NesterJ这款模拟器，PSP就可以运行任天堂红白机FC游戏，而FC在中国最著名的化身莫过就是小霸王了；而利用CPS1PSP模拟器，PSP就可以运行街机NEOGEO的游戏，像三国战记、拳皇等以前放学后才能偷偷去玩的经典街机游戏，也可以在PSP上与你重逢。除此以外，PSP还能够模拟GBA、SFC、MD等游戏机，相当逆天。

PSP能够模拟如此多的游戏机，是和其强劲的性能分不开关系的。由于对手任天堂同期竞品NDS性能较弱，以至于不少PSP玩家都对模拟NDS翘首以待。当然，这只是个幻想，直到PSP退市，这一幻想仍未成为现实。不过，这也从侧面可以看出，PSP性能的领先幅度到底有多大。

CheatMaster（CMF）：PSP上的金手指作弊神器

既然PSP是游戏机，那么和游戏相关的软件就会特别多特别强。而和PSP游戏相关的软件，CheatMaster绝对绕不过去——这可谓是PSP上最强的作弊软件了。想要在游戏中开挂？CMF是你的唯一之选。

CMF几乎是破解PSP人手必备的神器，就算不作弊也可以用来玩机

CMF的原理是通过读取内存来确定某个游戏的参数，然后再进行修改。这需要玩家来先让某个参数发生变化（例如血量、等级、攻击力等），然后用CMF来定位变化了的参数，从而修改。不过实际使用起来，并没有那么麻烦，网络上直接提供了一些热门游戏的现成金手指，按照代码直接修改相应的参数就可以了。

CMF除了作弊外，其实还是有很多其他实用用途的。例如，它可以改变PSP上按键的功能，可以调整CPU的频率等等，基本上是PSP上玩机必备的工具。破解PSP后，不少人唯一安装的PSP软件就是CMF，可见它的地位之高。

总结

除了上文所提到的，PSP还存在其他很多经典软件，限于篇幅这里就不一一列举了。得益于破解以及领先于时代的硬件，PSP的功用完全超乎了人们的想象，在众多的软件加持下它当之无愧可以被称之为一代神机。不过，PSP终归落幕了，在触屏智能手机们的冲击下，它的这些卖点也慢慢变得不值一提。

PSP的继任者PSV并没有延续PSP的辉煌，它不能安装大量第三方软件，游戏也依然没有对手3DS好玩，索尼掌机似乎再也无法在历史的舞台上站住脚，PSP一脉或许从此断绝。俱往矣！你家是否还有能开机的PSP呢？不妨开机再见一次熟悉的XMB界面，相信老玩家一定会感慨万分！

问题解决流程 PSP

丹纳赫经营体系DBS的改善工具《问题解决流程》PSP，源于丰田生产系统，以PDCA为基础，以A3报告为载体，成为全体员工的共同语言。

PDCA也叫做戴明环，大胆假设、快速试跑、小心求证、迭代升级，循环往复。

丹纳赫的PSP中采用的是四步法（DIVE）：确认，调查，验证与执行，确保维持。

其实，这些方法工具并没有本质的区别，都是遵循戴明的PDCA循环。叫什么名字，分几步走也不重要，重要的是用：干什么用？谁来用？如何用？用的结果？

PSP是解决问题的思路、技能、流程、纪律，不是简单的工具，PSP在战略部署和日常管理中都是必不可少的。

我们要建立的是一种A3文化氛围，让所有部门、不同职能的领导及员工能通过以下方法有效地解决问题：

把问题当作团队及个人改进的机会；

关注问题的关键点，以有事实根据的数据来分析问题的根本原因；

执行那些与根本原因系统性相联系的可维持的对策从而解决问题；

以团队合作的方式解决问题；

确保对策的维持。

在工作中，我们总是找不到正确的解决方案，问题反复发生，是因为我们不能找到正确的问题。就像往往我们成功了，但我们不知道自己是怎么成功的，失败了也不知道自己是怎么失败的，缺少了前进的根基。

用PSP解决问题，一定要拿数据说话，经过了科学的分析理性的思考,有凭有据有说服力。

PSP采用的是四步法（DIVE）：确认，调查，验证与执行，确保维持。

第一步，确定问题是什么?

一个好的问题描述需要有的四个要素……

目标 : 标准或要去哪里

现状：我们目前在什么地方

差异：目标/标准与现状间的差距

趋势：时间、数量、成本等的变化趋势

思考问题背后：

从趋势上看问题有哪些特点？

问题的范围是什么？

问题存在了多久？

是孤立的现象吗？

确切的问题是什么？

谁负责这个流程？

合理性是什么？

你决定如何解决这个问题？

你了解了什么？是如何了解到的？

你有没有去现场去收集和验证事实，以清楚地了解现在的状况，而不光是依照数据和传闻？

有其他的人一起参与么？

团队跟上进度了，还是落后于进度，还是处于停滞不前的状态？

第二步，根据80/20柏拉图原则,缩小关注范围，直到找到真实的“问题发生点”和原因。

缩小关注点到3个（或更少）的真实原因，用5Why、鱼骨图等方法对真实原因继续深入分析，找到根本原因，根据根因找对策：

确认发生了什么？

确认现在和发生前的情况和条件

什么时候发生的？

在流程的哪步发生？

什么样的措施也许可以防止问题的发生，但是却没有采取这个措施？

什么发生了变化了？

真实的部件，发生问题的真实事物，真实发生地，发生的真实条件（情况）

调查次品位置、使用方法、环境、状况、调查次品类别、物料、产品差异

第三步，验证，迭代复制

确保问题不会再次出现，确认是否有进一步完善的机会；

用PDCA来推进对策的实施，确保实施和监控各方对计划的理解一致性；

确保团队按计划执行，确定“谁”在“何时”去做“什么事”，有什么样的交付物。

第四步，建立日常管理，确保改善的维持

是否有持续性的和跟进的计划？

计划的详细内容是否完整，是否有可执行性?

如何在现场验证对策的有效性?

谁是负责人?每个团队的成员是否都认可各自承担的责任？

团队进度是按照计划，还是脱离了轨道，还是停滞不前？

任何不合理的地方或逻辑断裂处都需要被关注和予以思考判断。

丰田和丹纳赫人事管理的制胜点是把人当资源，把“人”看成公司扩大与发展的关键，训练人用正确的态度来面对问题，并解决问题，仅仅有程序而没有正确态度是没有用的。

只有人能够思考问题、解决问题和改进问题。一个学习型组织往往会拥有最好的组织绩效。有了员工智慧的主动发挥，才有真正的企业竞争力。

个人能力＋思维模式＋流程＝组织的能力

DBS还有一个改善工具《日常管理》，日常管理的目的就是及时暴露问题、解决问题、达成目标。

【云原生】K8s PSP 和 securityContext 介绍与使用

Pod Security Policies(Adminssion Controller)授予users和service accounts创建或更新pods使用资源的权限。这是一种集群级别的资源类型，用来限制pod对敏感资源的使用。它能够控制Pod的各个安全方面。

举例来说PSP可以做的事情：

是否允许Pod使用宿主节点的PID,IPC,网络命名空间。
Pod是否允许绑定到宿主节点端口。
容器运行时允许使用的用户ID。
是否允许特权模式的POD。

【温馨提示】PodSecurityPolicy 在 Kubernetes v1.21 中被弃用，在 Kubernetes v1.25 中被移除。

作为替代，你可以使用下面任一方式执行类似的限制，或者同时使用下面这两种方式。

PodSecurity admission
自行部署并配置第三方插件

官方文档：https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/关于 k8s RBAC的介绍，可以参考我这篇文章：

在 Kubernetes 中，我们定义了 Deployment、StatefulSet 和 Service 等资源。这些资源代表软件应用程序的构建块。Kubernetes 集群中的各种控制器根据这些资源做出反应，创建更多的 Kubernetes 资源或配置一些软件或硬件来实现我们的目标。
在大多数 Kubernetes 集群中，由 RBAC（基于角色的访问控制）规则控制对这些资源的访问。 list、get、create、edit 和 delete 是 RBAC 关心的 API 操作类型，但 RBAC 不考虑其所控制的资源中加入了哪些设置。例如， Pod 几乎可以是任何东西，例如简单的网络服务器，或者是特权命令提示（提供对底层服务器节点和所有数据的完全访问权限）。这对 RBAC 来说都是一样的：Pod 就是 Pod 而已。
要控制集群中定义的资源允许哪些类型的设置，除了 RBAC 之外，还需要访问控制。从 Kubernetes 1.3 开始，内置 PodSecurityPolicy 一直被作为 Pod 安全相关字段的访问控制机制。使用 PodSecurityPolicy，可以防止“创建 Pod”这个能力自动变成“每个集群节点上的 root 用户”，并且无需部署额外的外部访问控制器。

自从首次引入 PodSecurityPolicy 以来，我们已经意识到 PSP 存在一些严重的可用性问题，只有做出断裂式的改变才能解决。
实践证明，PSP 应用于 Pod 的方式让几乎所有尝试使用它们的人都感到困惑。很容易意外授予比预期更广泛的权限，并且难以查看某种特定情况下应用了哪些 PSP。 “更改 Pod 默认值”功能很方便，但仅支持某些 Pod 设置，而且无法明确知道它们何时会或不会应用于的 Pod。如果没有“试运行”或审计模式，将 PSP 安全地改造并应用到现有集群是不切实际的，并且永远都不可能默认启用 PSP。

因为PSP在高版本中已经不再使用了，所以这里稍微了解即可。目前，如果我们想要使用PSP，需要手动配置启动。PSP控制pod的方面包容如下：

在Master上编辑/etc/kubernetes/manifests/kube-apiserver.yaml文件，然后我们需要在command下的enable-admission-plugins下添加PodSecurityPolicy

重启kubelet

【注意】开启PodSecurityPolicy功能后，即使没有使用任何安全策略，都会使得创建pods（包括调度任务重新创建pods）失败

通过下面的deployment yaml文件测试在没有PSP策略的情况下是否可以创建pod:

使用下面的命令创建deployment资源：

使用下面的命令检查pod是否创建：

通过上图可见deployments和relicaset正在运行，由于缺少PSP policy，集群并没有创建相应的pods。

这里定义两个不同权限的PSP策略：

下面是典型的限制资源使用的restrictive policy：

下面是允许使用资源的permissive policy,多条permissive policy规则被用来设置相应user或者sevice account使用相关类型的资源。

上面两种poicies可以使用下面的命令创建对应的PSP资源：

核对psp是否创建成功与否：

下面将通过cluster role和cluster role binding在集群中使用刚才定义的安全策略(Pod Security Policy)。

关于restrictive policy的restrictive cluster role

关于permissive policy的permissive cluster role

通过下面命令创建相应的cluster role资源：

上面的role binding会将restrictive cluster role绑定到所有的system service account。

使用下面的命令生成role binding资源：

通过上图可知，可以正常调度pod，启动pod了。

Pod security admission 是 Kubernetes 内置的一种准入控制器，在 Kubernetes V1.23版本中这一特性门是默认开启的，在V1.22中需要通过 Kube-apiserver 参数feature-gates="...,PodSecurity=true"开启。在低于V1.22的 Kuberntes 版本中也可以自行安装 Pod Security Admission Webhook。

PodSecurity admission 是通过执行内置的 Pod Security Standards 来限制集群中的 pod 的创建。
Pod 安全性标准定义了三种不同的策略（Policy），以广泛覆盖安全应用场景。这些策略是叠加式的（Cumulative），安全级别从高度宽松至高度受限。本指南概述了每个策略的要求。

官方文档：https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/为了广泛的覆盖安全应用场景， Pod Security Standards 渐进式的定义了三种不同的 Pod 安全标准策略：

官方文档：https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-admission/

在 Kubernetes 集群中开启了 podSecurity admission 后，就可以通过给 namespace 设置 label 的方式来实施 Pod Security Standards。其中有三种设定模式可选用：

label 设置模板解释：

通过准入控制器配置文件，可以为 Pod security admission 设置默认配置：

podSecurity admission 可以从 username，runtimeClassName，namespace三个维度对 Pod 进行安全标准检查的豁免。

Baseline 策略目标是应用于常见的容器化应用，禁止已知的特权提升，在官方的介绍中此策略针对的是应用运维人员和非关键性应用开发人员，在该策略中包括：

必须禁止共享宿主命名空间、禁止容器特权、限制 Linux 能力、禁止 hostPath 卷、限制宿主机端口、设定 AppArmor、SElinux、Seccomp、Sysctls 等。

违反 Baseline 策略存在的风险：

特权容器可以看到宿主机设备
挂载 procfs 后可以看到宿主机进程，打破进程隔离
可以打破网络隔离
挂载运行时 socket 后可以不受限制的与运行时通信

【1】创建名为 my-baseline-namespace 的 namespace，并设定 enforce 和 warn 两种模式都对应 Baseline 等级的 Pod 安全标准策略：

【2】创建一个违反 baseline 策略的 pod

执行 apply 命令，显示不能设置hostPID=true，securityContext.privileged=true，Pod 创建被拒绝，特权容器的运行，并且开启 hostPID，容器进程没有与宿主机进程隔离，容易造成 Pod 容器逃逸：

【3】创建不违反 baseline 策略的 pod，设定 Pod 的hostPID=false，securityContext.privileged=false

执行 apply 命令，pod 被允许创建。

Restricted 策略目标是实施当前保护 Pod 的最佳实践，在官方介绍中此策略主要针对运维人员和安全性很重要的应用开发人员，以及不太被信任的用户。该策略包含所有的 baseline 策略的内容，额外增加：限制可以通过 PersistentVolumes 定义的非核心卷类型、禁止（通过 SetUID 或 SetGID 文件模式）获得特权提升、必须要求容器以非 root 用户运行、Containers 不可以将 runAsUser 设置为 0、容器组必须弃用 ALL capabilities 并且只允许添加 NET_BIND_SERVICE 能力。

Restricted 策略进一步的限制在容器内获取 root 权限，linux 内核功能。例如针对 kubernetes 网络的中间人攻击需要拥有 Linux 系统的 CAP_NET_RAW 权限来发送 ARP 包。

【1】创建名为 my-restricted-namespace的namespace，并设定 enforce 和 warn 两种模式都对应 Restricted 等级的 Pod 安全标准策略：

【2】创建一个违反 Restricted 策略的 pod

执行 apply 命令，显示必须设置 securityContext.runAsNonRoot=true，securityContext.capabilities.drop=["ALL"]，Pod 创建被拒绝，容器以 root 用户运行时容器获取权限过大，结合没有 Drop linux 内核能力有 kubernetes 网络中间人攻击的风险。

【3】创建不违反 Restricted 策略的 pod，设定 Pod 的 securityContext.runAsNonRoot=true，Drop 所有 linux 能力。

执行 apply 命令，pod 被允许创建。

如果你的集群中已经配置 PodSecurityPolicy，考虑把它们迁移到 podSecurity admission 是需要一定的工作量的。首先需要考虑当前的 podSecurity admission 是否适合你的集群，目前它旨在满足开箱即用的最常见的安全需求，与 PSP 相比它存在以下差异：

podSecurity admission 只是对 pod 进行安全标准的检查，不支持对 pod 进行修改，不能为 pod 设置默认的安全配置。
podSecurity admission 只支持官方定义的三种安全标准策略，不支持灵活的自定义安全标准策略。这使得不能完全将PSP规则迁移到 podSecurity admission，需要进行具体的安全规则考量。
podSecurity admission 不像 PSP 一样可以与具体的用户进行绑定，只支持豁免特定的用户或者 RuntimeClass 及 namespace。

官方文档：https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context

SecurityContext 包含 Pod 级别的安全属性和常见的容器设置。可选：默认为空。每个字段的默认值见类型描述。

【温馨提示】PodSecurityContext 包含 Pod 级别的安全属性和常用容器设置。一些字段也存在于 container.securityContext 中。container.securityContext 中的字段值优先于 PodSecurityContext 的字段值。

securityContext.runAsUser——运行容器进程入口点（Entrypoint）的 UID。如果未指定，则默认为镜像元数据中指定的用户。也可以在 SecurityContext 中设置。如果同时在 SecurityContext 和 PodSecurityContext 中设置，则在对应容器中所设置的 SecurityContext 值优先。注意，spec.os.name 为 "windows" 时不能设置此字段。
securityContext.runAsGroup——运行容器进程入口点（Entrypoint）的 GID。如果未设置，则使用运行时的默认值。也可以在 SecurityContext 中设置。如果同时在 SecurityContext 和 PodSecurityContext 中设置，则在对应容器中设置的 SecurityContext 值优先。注意，spec.os.name 为 "windows" 时不能设置该字段。
securityContext.privileged——以特权模式运行容器。特权容器中的进程本质上等同于主机上的 root。默认为 false。默认情况下，容器是不可以访问宿主上的任何设备的，不过一个“privileged（特权的）” 容器则被授权访问宿主上所有设备。这种容器几乎享有宿主上运行的进程的所有访问权限。【注意】这个参数不能在 PodSecurityContext 中设置。注意，spec.os.name 为 "windows" 时不能设置此字段。
securityContext.fsGroup——应用到 Pod 中所有容器的特殊补充组。某些卷类型允许 kubelet 将该卷的所有权更改为由 Pod 拥有：文件系统的属主 GID 将是 fsGroup 字段值setgid 位已设置（在卷中创建的新文件将归 fsGroup 所有）权限位将与 rw-rw---- 进行按位或操作
securityContext.fsGroupChangePolicy——fsGroupChangePolicy 定义了在卷被在 Pod 中暴露之前更改其属主和权限的行为。此字段仅适用于支持基于 fsGroup 的属主权（和权限）的卷类型。它不会影响临时卷类型，例如：secret、configmap 和 emptydir。有效值为 "OnRootMismatch" 和 "Always"。如果未设置，则使用 "Always"。注意，spec.os.name 为 "windows" 时不能设置此字段。

上面只是列出了几个常用的参数，更多参数，可以参考官方文档。对应的字段如下：