查看集群巡检项及修复方案
介绍如何在 KubeSphere Cloud 云原生应用服务平台上查看集群巡检项及修复方案。
本节介绍如何在 KubeSphere Cloud 云原生应用服务平台上查看集群巡检项及修复方案。
告警级别：危险
NoCPULimits
告警描述：配置 CPU 限制可确保容器永远不会使用过多的 CPU。如果未设置 CPU 限制，则行为不端的应用程序最终可能会利用其节点上的大部分可用CPU，从而可能会减慢其他工作负载或在集群尝试扩展时导致成本超支。 与内存限制相比，CPU 限制永远不会导致您的应用程序崩溃。相反，它会受到限制--它只被允许每秒运行一定数量的操作。
修复方案：为每个容器规范添加 CPU 限制，CPU 可以根据整个 CPU 来设置(例如10或25)，或者更常见地，根据 Millicpus (例如1000m或250m)来设置。 由您决定为您的应用程序分配多少 CPU。将 CPU 限制设置得太高可能会导致成本超支，而将其设置得太低可能会导致您的应用程序受到限制。 对于任务关键型或面向用户的应用程序，KubeEye 建议设置较高的CPU限制，这样只会限制行为不端的应用程序。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "64Mi" cpu: "250m"
NoCPURequests
告警描述：设置 CPU 资源请求，kube-scheduler 就利用该信息决定将 Pod 调度到哪个节点上。
修复方案：为每个容器规范添加 CPU 资源请求，CPU 可以根据整个CPU来设置(例如10或25)，或者更常见地，根据 Millicpus (例如1000m或250m)来设置。 由您决定为您的应用程序分配多少 CPU。将 CPU 限制设置得太高可能会导致应用无法调度，而将其设置得太低可能会导致您的应用程序抢占资源。 对于任务关键型或面向用户的应用程序，KubeEye 建议将 CPU 资源请求与 CPU 资源限制设置一致，这样可以确保应用程序资源独占。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "64Mi" cpu: "250m"
HostNetworkAllowed
告警描述：控制是否 Pod 可以使用节点的网络名字空间。 此类授权将允许 Pod 访问本地回路（loopback）设备、在本地主机（localhost） 上监听的服务、还可能用来监听同一节点上其他 Pod 的网络活动。
修复方案：禁止 hostNetwork。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-policy/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: hostPID: false
HostPIDAllowed
告警描述：控制 Pod 中容器是否可以共享宿主上的进程 ID 空间。注意，如果与 ptrace 相结合，这种授权可能被利用，导致向容器外的特权逃逸（默认情况下 ptrace 是被禁止的）。
修复方案：禁止 hostPID。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-policy/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: hostPID: false
NotRunAsNonRoot
告警描述：要求提交的 Pod 具有非零 runAsUser 值，或在镜像中 （使用 UID 数值）定义了 USER 环境变量。 如果 Pod 既没有设置 runAsNonRoot，也没有设置 runAsUser，则该 Pod 会被修改以设置 runAsNonRoot=true，从而要求容器通过 USER 指令给出非零的数值形式的用户 ID。 此配置没有默认值。采用此配置时，强烈建议设置 allowPrivilegeEscalation=false。
修复方案：设置 readOnlyRootFilesystem 为 true。
参考文档：https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true
NoMemoryLimits
告警描述：配置内存限制可确保容器永远不会使用过多的内存。如果未设置内存限制，则行为不端的应用程序最终可能会利用其节点上的大部分可用内存。
修复方案：为每个容器规范添加内存限制。 由您决定为您的应用程序分配多少内存。将内存限制设置得太高可能会导致成本超支，而将其设置得太低可能会导致您的应用程序OOM。 对于任务关键型或面向用户的应用程序，KubeEye 建议设置较高的内存限制。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "64Mi" cpu: "250m"
NoMemoryRequests
告警描述：设置内存资源请求，kube-scheduler 就利用该信息决定将 Pod 调度到哪个节点上。
修复方案：为每个容器规范添加内存资源请求。由您决定为您的应用程序分配多少内存。将内存限制设置得太高可能会导致应用无法调度，而将其设置得太低可能会导致您的应用程序抢占资源。对于任务关键型或面向用户的应用程序，KubeEye 建议将内存资源请求与内存资源限制设置一致，这样可以确保应用程序资源独占。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "64Mi" cpu: "250m"
PrivilegedAllowed
告警描述：在 Linux 中，Pod 中的任何容器都可以使用容器规约中的安全性上下文中的 privileged（Linux）参数启用特权模式。这对于想要使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）的容器很有用。
修复方案：禁止特权模式。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo securityContext: allowPrivilegeEscalation: false
告警级别：警告
ImagePullPolicyNotAlways
告警描述：每当 kubelet 启动一个容器时，kubelet 会查询容器的镜像仓库， 将名称解析为一个镜像摘要。 如果 kubelet 有一个容器镜像，并且对应的摘要已在本地缓存，kubelet 就会使用其缓存的镜像； 否则，kubelet 就会使用解析后的摘要拉取镜像，并使用该镜像来启动容器。
修复方案：将 imagePullPolicy 设置为 Always。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/containers/images/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo imagePullPolicy: Always
NotReadOnlyRootFilesystem
告警描述：要求容器必须以只读方式挂载根文件系统来运行 （即不允许存在可写入层）。
修复方案：设置 readOnlyRootFilesystem。
参考文档：https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-policy/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: readOnlyRootFilesystem: false containers: - name: demo image: demo
InsecureCapabilities
告警描述：设置不安全的能力将导致 Pod 具有较高的权限，如 KILL 权限将使容器具有杀死宿主机进程的权限。
修复方案：不使用 CHOWN/FSETID/SETFCAP/SETPCAP/KILL 等不安全的能力
参考文档：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo imagePullPolicy: Always
NoReadinessProbe
告警描述：注意如果就绪态探针的实现不正确，可能会导致容器中进程的数量不断上升。 如果不对其采取措施，很可能导致资源枯竭的状况。
修复方案：设置正确的 readinessProbe。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo readinessProbe: httpGet: path: /healthy port: 8080 initialDelaySeconds: 5 periodSeconds: 5
NoLivenessProbe
告警描述：存活探测器用来发现并处理应用程序损坏状态。
修复方案：设置存活探测器
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5
CanImpersonateUser
告警描述：一个用户可以通过伪装（Impersonation）头部字段来以另一个用户的身份执行操作。 使用这一能力，你可以手动重载请求被身份认证所识别出来的用户信息。 例如，管理员可以使用这一功能特性来临时伪装成另一个用户，查看请求是否被拒绝， 从而调试鉴权策略中的问题， 带伪装的请求首先会被身份认证识别为发出请求的用户， 之后会切换到使用被伪装的用户的用户信息。
修复方案：基于伪装成一个用户或用户组的能力，你可以执行任何操作，好像你就是那个用户或用户组一样。出于这一原因，伪装操作是不受名字空间约束的。
参考文档：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/。
CanModifyWorkloads
告警描述：用户有创建、修改、删除工作负载的权限。
修复方案：检查 RBAC 权限设置，减少非必要权限。
参考文档：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/。
示例
apiVersion: v1 kind: Pod metadata: name: demo spec: containers: - name: demo image: demo securityContext: allowPrivilegeEscalation: false