Kubernetes YAML Manifests 生产级编写指南awesome-copilot 指令驱动的安全、可靠与可运维实践【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本指南围绕开源仓库 awesome-copilot 中面向 GitHub Copilot 的 kubernetes-manifests.instructions.md 指令文件展开系统讲解如何编写生产就绪的 Kubernetes YAML 清单从推荐标签体系、安全上下文与 Pod 安全标准到资源配额、三类健康探针、滚动发布与回滚再到 apply 前的多层级校验命令。阅读完本文你将获得一套可直接复制到日常工作中的清单编写规范与验证工作流并理解这些规范在仓库源码与配套 Agent/指令中的一致性实现。说明该指令文件的applyTo元数据为k8s/**/*.yaml、manifests/**/*.yaml、deploy/**/*.yaml、charts/**/templates/**/*.yaml等路径即当你编辑 Kubernetes 相关 YAML 时Copilot 会自动套用本规范。仓库中还提供了同主题的 kubernetes-deployment-best-practices.instructions.md覆盖 Pod/Deployment/Service/Ingress/ConfigMap/Secret 全链路与 platform-sre-kubernetes.agent.mdSRE 视角的发布/回滚/验证流程三者可配合阅读。一、标签与注解清单的身份系统Kubernetes 官方推荐的标签约定是清单可被 Selector、监控与账单系统稳定引用的基础。指令文件明确要求以下必备标签标签 Key语义app.kubernetes.io/name应用名称app.kubernetes.io/instance实例标识区分同一应用的多个部署app.kubernetes.io/version应用版本app.kubernetes.io/component组件角色如 api、workerapp.kubernetes.io/part-of所属应用组app.kubernetes.io/managed-by管理工具如 Helm、kubectl在此基础上指令建议补充运营类标签environment环境名、team归属团队、cost-center用于成本分摊与账单核算。实用注解Annotations文档与归属信息如联系人、文档链接监控采集注解prometheus.io/scrape、prometheus.io/port、prometheus.io/path配合 kubernetes-deployment-best-practices.instructions.md 中的 Prometheus kube-state-metrics 监控方案使用变更追踪注解git commit、部署日期。一个遵循规范的标签示例metadata: labels: app.kubernetes.io/name: order-service app.kubernetes.io/instance: order-service-prod app.kubernetes.io/version: 1.4.2 app.kubernetes.io/component: api app.kubernetes.io/part-of: commerce app.kubernetes.io/managed-by: helm environment: production team: checkout cost-center: cc-2031 annotations: prometheus.io/scrape: true prometheus.io/port: 8080 prometheus.io/path: /metrics app.kubernetes.io/git-commit: 9f2c4a1二、SecurityContext 安全默认值不可协商的底线指令文件与 platform-sre-kubernetes.agent.md 将安全上下文列为Non-Negotiable不可协商的默认项分为 Pod 级与容器级两层Pod 级spec.securityContextrunAsNonRoot: true禁止以 root 运行runAsUser/runAsGroup指定具体 UID/GIDfsGroup文件系统组用于卷权限seccompProfile.type: RuntimeDefault启用运行时默认 seccomp 配置。容器级containers[].securityContextallowPrivilegeEscalation: false禁止权限提升readOnlyRootFilesystem: true只读根文件系统需要写入的目录用 tmpfs 挂载capabilities.drop: [ALL]丢弃全部 Linux capabilities仅按需添加。组合示例来自 kubernetes-deployment-best-practices.instructions.md 的完整版本并补充 seccomp 与启动探针spec: securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 1000 fsGroup: 2000 seccompProfile: type: RuntimeDefault containers: - name: my-app image: my-repo/my-app:1.0.0 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: [ALL] volumeMounts: - name: tmp mountPath: /tmp volumes: - name: tmp emptyDir: {}其中只读根文件系统需要可写目录时用emptyDir临时卷承载/tmp等路径这正是指令中with tmpfs mounts for writable dirs的具体落地。三、Pod 安全标准在命名空间层面实施准入控制指令建议通过Pod Security AdmissionPSA在命名空间层面实施安全基线共三档Restricted推荐用于生产最严格档位强制安全加固要求 runAsNonRoot、禁止特权容器、限制 capabilities、要求 seccomp 等Baseline最小安全要求允许一些已知的受限配置Privileged无限制仅用于系统组件生产应用应避免。在 Namespace 上的实施示例apiVersion: v1 kind: Namespace metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted当工作负载无法完全满足 Restricted 时应显式评估并选择 Baseline而不是无提示地降级audit/warn标签可以在不拦截的情况下暴露违规清单便于渐进收敛。四、资源请求与限制保证 QoS 类与调度稳定性指令强调每个容器都必须定义Requests请求调度时保证的最小资源用于节点调度决策Limits限制允许使用的硬上限防止资源耗尽与吵闹邻居。三种 QoS 类别的取舍QoS 类条件适用场景Guaranteedrequests limits关键应用首选资源确定性最强Burstablerequests limits灵活资源使用允许突发BestEffort未定义资源生产中应避免kubernetes-deployment-best-practices.instructions.md 给出了可直接套用的数值范例resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi对于负载波动的无状态应用可配合Horizontal Pod AutoscalerHPA自动伸缩关键配置项为minReplicas、maxReplicas、targetCPUUtilizationPercentage长期内存/CPU 曲线不稳定的服务可评估Vertical Pod AutoscalerVPA自动调整 requests/limits详见 kubernetes-deployment-best-practices.instructions.md。五、三类健康探针启动、存活与就绪的分工指令要求三类探针各司其职Liveness存活探针容器是否仍存活失败则 kubelet 重启容器Readiness就绪探针容器是否可接收流量失败则从 Service Endpoints 中摘除Startup启动探针保护启动缓慢的应用在启动探针成功前禁用 liveness/readiness 探针。每个探针需根据应用特征配置initialDelaySeconds首次探测延迟、periodSeconds探测周期、timeoutSeconds超时、failureThreshold失败阈值、successThreshold成功阈值。platform-sre-kubernetes.agent.md 给出一个实用公式Startup 探针的 failureThreshold × periodSeconds 允许的最大启动时间。综合示例startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10 # 允许最长 300s 启动 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3仓库配套技能 gem-devops-guidelines/SKILL.md 同样强调为工作负载配置与初始延迟和阈值匹配的 startup/readiness/liveness 探针并要求服务暴露有意义的/health端点并优雅处理SIGTERM。六、滚动发布与高可用零停机与跨节点容错Deployment 策略默认使用RollingUpdate通过maxSurge与maxUnavailable精细控制滚动节奏关键应用设置maxUnavailable: 0实现零停机更新一次最多额外多启动maxSurge个新 Pod旧 Pod 逐个下线。高可用组合拳副本数生产环境至少23 个副本PodDisruptionBudgetPDB通过minAvailable或maxUnavailable约束自愿中断如节点维护时允许同时不可用的 Pod 数反亲和性Anti-affinity将 Pod 打散到不同节点/可用区避免单点故障HPA应对可变负载。滚动策略与反亲和示例spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/name: my-app topologyKey: kubernetes.io/hostnameapiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app.kubernetes.io/name: my-app七、验证命令apply 之前先过三关指令将先验证、后发布固化为流程platform-sre-kubernetes.agent.md 的Validation输出标准与其完全一致第一关客户端 dry-run不访问集群kubectl apply --dry-runclient -f manifest.yaml第二关服务端 dry-run由 API server 做 schema 校验kubectl apply --dry-runserver -f manifest.yaml第三关Schema 严格校验# 直接校验清单文件 kubeconform -strict manifest.yaml # Helm Chart 先渲染再校验 helm template ./chart | kubeconform -strict策略校验OPA Conftest、Kyverno 或 Datree 可用于对清单施加组织级策略如强制 Restricted PSA、禁止:latest标签。八、部署、回滚与重启让每一次变更都可逆部署kubectl apply -f manifest.yaml kubectl rollout status deployment/NAMEplatform-sre-kubernetes.agent.md 建议为rollout status增加超时上限如--timeout5m避免命令无限等待。回滚kubectl rollout undo deployment/NAME # 回滚到上一版本 kubectl rollout undo deployment/NAME --to-revisionN # 回滚到指定修订 kubectl rollout history deployment/NAME # 查看历史修订重启滚动重启常用于重新加载 ConfigMap/Secretkubectl rollout restart deployment/NAME仓库配套技能 gem-devops-guidelines/SKILL.md 将kubectl rollout undo列为 Kubernetes 的标准回滚手段se-gitops-ci-specialist.agent.md 的 GitOps 回滚方案也是kubectl rollout undo deployment/myapp。发布后的运维纪律来自 platform-sre-kubernetes.agent.md任何变更前先 dry-run发布后至少监控 15 分钟正式使用前测试回滚流程。九、Manifest 发布前检查清单指令给出了完整的 14 项清单逐项核对后再 apply标签应用了标准标签app.kubernetes.io/*系列注解包含文档说明与监控注解prometheus.io/*安全runAsNonRoot、readOnlyRootFilesystem、dropped capabilities资源Requests 与 Limits 均已定义探针Liveness、readiness、startup 均已配置镜像使用具体标签绝不使用:latest生产可用 digest 保证不可变性副本生产环境至少 23 个策略RollingUpdate 且 surge/unavailable 取值合理关键应用maxUnavailable: 0PDB生产环境已定义反亲和已配置以实现高可用优雅关闭设置terminationGracePeriodSeconds验证dry-run 与 kubeconform 均已通过密钥敏感数据放在 Secret 资源中绝不放入 ConfigMapNetworkPolicy如适用实施最小权限的网络访问控制十、最佳实践总览使用标准标签与注解始终以非 root 运行并丢弃多余 capabilities为所有容器定义资源 requests 与 limits实现全部三类探针liveness/readiness/startup将镜像标签固定到具体版本platform-sre-kubernetes.agent.md 建议进一步使用sha256:DIGEST保证不可变性为高可用配置反亲和规则设置 Pod Disruption Budget采用零不可用的滚动更新在 apply 之前验证清单dry-run kubeconform尽可能启用只读根文件系统。结语Kubernetes YAML 清单是集群安全、可靠与可运维性的第一道防线。本文基于 awesome-copilot 仓库的 kubernetes-manifests.instructions.md 主指令结合 kubernetes-deployment-best-practices.instructions.md 的完整示例、platform-sre-kubernetes.agent.md 的 SRE 发布纪律以及 gem-devops-guidelines/SKILL.md 的运维条目给出了从标签、安全、资源、探针到发布验证的一整套可落地规范。将这套规范以.instructions.md形式放入工作区的.github/instructions/参见 docs/README.instructions.md 的安装方式即可让 GitHub Copilot 在编辑k8s/**、manifests/**、deploy/**或 Helm Chart 模板时自动遵守这些生产级标准。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes YAML Manifests 生产级编写指南：awesome-copilot 指令驱动的安全、可靠与可运维实践
Kubernetes YAML Manifests 生产级编写指南awesome-copilot 指令驱动的安全、可靠与可运维实践【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本指南围绕开源仓库 awesome-copilot 中面向 GitHub Copilot 的 kubernetes-manifests.instructions.md 指令文件展开系统讲解如何编写生产就绪的 Kubernetes YAML 清单从推荐标签体系、安全上下文与 Pod 安全标准到资源配额、三类健康探针、滚动发布与回滚再到 apply 前的多层级校验命令。阅读完本文你将获得一套可直接复制到日常工作中的清单编写规范与验证工作流并理解这些规范在仓库源码与配套 Agent/指令中的一致性实现。说明该指令文件的applyTo元数据为k8s/**/*.yaml、manifests/**/*.yaml、deploy/**/*.yaml、charts/**/templates/**/*.yaml等路径即当你编辑 Kubernetes 相关 YAML 时Copilot 会自动套用本规范。仓库中还提供了同主题的 kubernetes-deployment-best-practices.instructions.md覆盖 Pod/Deployment/Service/Ingress/ConfigMap/Secret 全链路与 platform-sre-kubernetes.agent.mdSRE 视角的发布/回滚/验证流程三者可配合阅读。一、标签与注解清单的身份系统Kubernetes 官方推荐的标签约定是清单可被 Selector、监控与账单系统稳定引用的基础。指令文件明确要求以下必备标签标签 Key语义app.kubernetes.io/name应用名称app.kubernetes.io/instance实例标识区分同一应用的多个部署app.kubernetes.io/version应用版本app.kubernetes.io/component组件角色如 api、workerapp.kubernetes.io/part-of所属应用组app.kubernetes.io/managed-by管理工具如 Helm、kubectl在此基础上指令建议补充运营类标签environment环境名、team归属团队、cost-center用于成本分摊与账单核算。实用注解Annotations文档与归属信息如联系人、文档链接监控采集注解prometheus.io/scrape、prometheus.io/port、prometheus.io/path配合 kubernetes-deployment-best-practices.instructions.md 中的 Prometheus kube-state-metrics 监控方案使用变更追踪注解git commit、部署日期。一个遵循规范的标签示例metadata: labels: app.kubernetes.io/name: order-service app.kubernetes.io/instance: order-service-prod app.kubernetes.io/version: 1.4.2 app.kubernetes.io/component: api app.kubernetes.io/part-of: commerce app.kubernetes.io/managed-by: helm environment: production team: checkout cost-center: cc-2031 annotations: prometheus.io/scrape: true prometheus.io/port: 8080 prometheus.io/path: /metrics app.kubernetes.io/git-commit: 9f2c4a1二、SecurityContext 安全默认值不可协商的底线指令文件与 platform-sre-kubernetes.agent.md 将安全上下文列为Non-Negotiable不可协商的默认项分为 Pod 级与容器级两层Pod 级spec.securityContextrunAsNonRoot: true禁止以 root 运行runAsUser/runAsGroup指定具体 UID/GIDfsGroup文件系统组用于卷权限seccompProfile.type: RuntimeDefault启用运行时默认 seccomp 配置。容器级containers[].securityContextallowPrivilegeEscalation: false禁止权限提升readOnlyRootFilesystem: true只读根文件系统需要写入的目录用 tmpfs 挂载capabilities.drop: [ALL]丢弃全部 Linux capabilities仅按需添加。组合示例来自 kubernetes-deployment-best-practices.instructions.md 的完整版本并补充 seccomp 与启动探针spec: securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 1000 fsGroup: 2000 seccompProfile: type: RuntimeDefault containers: - name: my-app image: my-repo/my-app:1.0.0 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: [ALL] volumeMounts: - name: tmp mountPath: /tmp volumes: - name: tmp emptyDir: {}其中只读根文件系统需要可写目录时用emptyDir临时卷承载/tmp等路径这正是指令中with tmpfs mounts for writable dirs的具体落地。三、Pod 安全标准在命名空间层面实施准入控制指令建议通过Pod Security AdmissionPSA在命名空间层面实施安全基线共三档Restricted推荐用于生产最严格档位强制安全加固要求 runAsNonRoot、禁止特权容器、限制 capabilities、要求 seccomp 等Baseline最小安全要求允许一些已知的受限配置Privileged无限制仅用于系统组件生产应用应避免。在 Namespace 上的实施示例apiVersion: v1 kind: Namespace metadata: name: production labels: pod-security.kubernetes.io/enforce: restricted pod-security.kubernetes.io/audit: restricted pod-security.kubernetes.io/warn: restricted当工作负载无法完全满足 Restricted 时应显式评估并选择 Baseline而不是无提示地降级audit/warn标签可以在不拦截的情况下暴露违规清单便于渐进收敛。四、资源请求与限制保证 QoS 类与调度稳定性指令强调每个容器都必须定义Requests请求调度时保证的最小资源用于节点调度决策Limits限制允许使用的硬上限防止资源耗尽与吵闹邻居。三种 QoS 类别的取舍QoS 类条件适用场景Guaranteedrequests limits关键应用首选资源确定性最强Burstablerequests limits灵活资源使用允许突发BestEffort未定义资源生产中应避免kubernetes-deployment-best-practices.instructions.md 给出了可直接套用的数值范例resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi对于负载波动的无状态应用可配合Horizontal Pod AutoscalerHPA自动伸缩关键配置项为minReplicas、maxReplicas、targetCPUUtilizationPercentage长期内存/CPU 曲线不稳定的服务可评估Vertical Pod AutoscalerVPA自动调整 requests/limits详见 kubernetes-deployment-best-practices.instructions.md。五、三类健康探针启动、存活与就绪的分工指令要求三类探针各司其职Liveness存活探针容器是否仍存活失败则 kubelet 重启容器Readiness就绪探针容器是否可接收流量失败则从 Service Endpoints 中摘除Startup启动探针保护启动缓慢的应用在启动探针成功前禁用 liveness/readiness 探针。每个探针需根据应用特征配置initialDelaySeconds首次探测延迟、periodSeconds探测周期、timeoutSeconds超时、failureThreshold失败阈值、successThreshold成功阈值。platform-sre-kubernetes.agent.md 给出一个实用公式Startup 探针的 failureThreshold × periodSeconds 允许的最大启动时间。综合示例startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10 # 允许最长 300s 启动 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 timeoutSeconds: 5 failureThreshold: 3 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3仓库配套技能 gem-devops-guidelines/SKILL.md 同样强调为工作负载配置与初始延迟和阈值匹配的 startup/readiness/liveness 探针并要求服务暴露有意义的/health端点并优雅处理SIGTERM。六、滚动发布与高可用零停机与跨节点容错Deployment 策略默认使用RollingUpdate通过maxSurge与maxUnavailable精细控制滚动节奏关键应用设置maxUnavailable: 0实现零停机更新一次最多额外多启动maxSurge个新 Pod旧 Pod 逐个下线。高可用组合拳副本数生产环境至少23 个副本PodDisruptionBudgetPDB通过minAvailable或maxUnavailable约束自愿中断如节点维护时允许同时不可用的 Pod 数反亲和性Anti-affinity将 Pod 打散到不同节点/可用区避免单点故障HPA应对可变负载。滚动策略与反亲和示例spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/name: my-app topologyKey: kubernetes.io/hostnameapiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: my-app-pdb spec: minAvailable: 2 selector: matchLabels: app.kubernetes.io/name: my-app七、验证命令apply 之前先过三关指令将先验证、后发布固化为流程platform-sre-kubernetes.agent.md 的Validation输出标准与其完全一致第一关客户端 dry-run不访问集群kubectl apply --dry-runclient -f manifest.yaml第二关服务端 dry-run由 API server 做 schema 校验kubectl apply --dry-runserver -f manifest.yaml第三关Schema 严格校验# 直接校验清单文件 kubeconform -strict manifest.yaml # Helm Chart 先渲染再校验 helm template ./chart | kubeconform -strict策略校验OPA Conftest、Kyverno 或 Datree 可用于对清单施加组织级策略如强制 Restricted PSA、禁止:latest标签。八、部署、回滚与重启让每一次变更都可逆部署kubectl apply -f manifest.yaml kubectl rollout status deployment/NAMEplatform-sre-kubernetes.agent.md 建议为rollout status增加超时上限如--timeout5m避免命令无限等待。回滚kubectl rollout undo deployment/NAME # 回滚到上一版本 kubectl rollout undo deployment/NAME --to-revisionN # 回滚到指定修订 kubectl rollout history deployment/NAME # 查看历史修订重启滚动重启常用于重新加载 ConfigMap/Secretkubectl rollout restart deployment/NAME仓库配套技能 gem-devops-guidelines/SKILL.md 将kubectl rollout undo列为 Kubernetes 的标准回滚手段se-gitops-ci-specialist.agent.md 的 GitOps 回滚方案也是kubectl rollout undo deployment/myapp。发布后的运维纪律来自 platform-sre-kubernetes.agent.md任何变更前先 dry-run发布后至少监控 15 分钟正式使用前测试回滚流程。九、Manifest 发布前检查清单指令给出了完整的 14 项清单逐项核对后再 apply标签应用了标准标签app.kubernetes.io/*系列注解包含文档说明与监控注解prometheus.io/*安全runAsNonRoot、readOnlyRootFilesystem、dropped capabilities资源Requests 与 Limits 均已定义探针Liveness、readiness、startup 均已配置镜像使用具体标签绝不使用:latest生产可用 digest 保证不可变性副本生产环境至少 23 个策略RollingUpdate 且 surge/unavailable 取值合理关键应用maxUnavailable: 0PDB生产环境已定义反亲和已配置以实现高可用优雅关闭设置terminationGracePeriodSeconds验证dry-run 与 kubeconform 均已通过密钥敏感数据放在 Secret 资源中绝不放入 ConfigMapNetworkPolicy如适用实施最小权限的网络访问控制十、最佳实践总览使用标准标签与注解始终以非 root 运行并丢弃多余 capabilities为所有容器定义资源 requests 与 limits实现全部三类探针liveness/readiness/startup将镜像标签固定到具体版本platform-sre-kubernetes.agent.md 建议进一步使用sha256:DIGEST保证不可变性为高可用配置反亲和规则设置 Pod Disruption Budget采用零不可用的滚动更新在 apply 之前验证清单dry-run kubeconform尽可能启用只读根文件系统。结语Kubernetes YAML 清单是集群安全、可靠与可运维性的第一道防线。本文基于 awesome-copilot 仓库的 kubernetes-manifests.instructions.md 主指令结合 kubernetes-deployment-best-practices.instructions.md 的完整示例、platform-sre-kubernetes.agent.md 的 SRE 发布纪律以及 gem-devops-guidelines/SKILL.md 的运维条目给出了从标签、安全、资源、探针到发布验证的一整套可落地规范。将这套规范以.instructions.md形式放入工作区的.github/instructions/参见 docs/README.instructions.md 的安装方式即可让 GitHub Copilot 在编辑k8s/**、manifests/**、deploy/**或 Helm Chart 模板时自动遵守这些生产级标准。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考