目录
[2. 解释Service Account的用途。](#2. 解释Service Account的用途。)
[3. 详细解释Role和ClusterRole。](#3. 详细解释Role和ClusterRole。)
[4. 什么是K8s的NetworkPolicy？](#4. 什么是K8s的NetworkPolicy？)
[5. 详细描述在K8s中如何控制跨Namespace的Pod访问？](#5. 详细描述在K8s中如何控制跨Namespace的Pod访问？)
1.解释ResourceQuota的作用。
ResourceQuota（资源配额） 是K8s中用于限制命名空间资源使用总量的机制，它的作用是防止某个命名空间消耗过多集群资源，影响其他命名空间的正常运行。
资源配额的核心作用有以下三个：
（1）限制计算资源总量：可以限制一个命名空间内所有Pod的CPU和内存请求和限制的总和。
（2）限制对象数量：可以限制命名空间内可创建的特定Kubernetes对象数量，例如Pod、Service、Deployment、PVC等。
（3）保障公平分配：在多租户集群中，为每个命名空间设置配额，确保资源公平分配，避免"吵闹的邻居"问题。
2. 解释Service Account的用途。
Service Account（服务账户） 是K8s中用于为Pod中运行的程序提供身份标识的机制，它允许Pod通过API Server与K8s控制平面进行安全通信。
它的核心用途有以下四个：
（1）身份认证：Pod中的容器可以使用Service Account的凭证（通常以Secret形式挂载）向API Server证明自己的身份。
（2）权限授权：通过将Service Account绑定到Role或ClusterRole，可以授予Pod特定的操作权限（例如读取Pod列表、创建Deployment等）。
（3）自动挂载：每个Pod创建时，Kubernetes会自动将默认的Service Account（或在Pod中指定的Service Account）的认证信息挂载到/var/run/secrets/kubernetes.io/serviceaccount目录。
（4）区分用户类型：User Account 对应真实的人（管理员、开发者），用于kubectl访问；Service Account对应运行在Pod中的程序，用于程序间通信或调用API Server。
3. 详细解释Role和ClusterRole。
Role（角色） 和 ClusterRole（集群角色） 都是 K8s RBAC（基于角色的访问控制） 系统中用来定义权限集合的资源对象。它们本身不指定"谁"拥有这些权限，只定义"可以对哪些资源执行哪些操作"（例如：可以读取 Pod、可以创建 Deployment）。
两者的根本区别在于 生效范围：
Role 是命名空间级别的：它定义的权限只适用于 某一个具体的命名空间。你无法使用 Role 来授予访问集群级别资源（如 Node、PersistentVolume）的权限，也无法跨命名空间生效。
ClusterRole 是集群级别的：它定义的权限 在整个集群范围内生效。它可以用来授予访问集群级别资源的权限，也可以用来授予访问所有命名空间中某种资源的权限（例如：查看所有命名空间中的 Pod）。
设计这两种角色是为了满足 K8s 的多租户隔离和最小权限原则。Role 和 ClusterRole 只是静态的"规则清单"，要让权限真正生效，必须将它们与具体的主体（可以是 User、Group 或 ServiceAccount）进行绑定：
RoleBinding ：在某个命名空间内，将 Role 或 ClusterRole 的权限授予给某个主体。绑定后，该主体就在 这个命名空间内 拥有了角色定义的权限。
ClusterRoleBinding ：在集群范围内，将 ClusterRole 的权限授予给某个主体。绑定后，该主体就 在整个集群中所有命名空间（以及集群级别资源）拥有权限。
4. 什么是K8s的NetworkPolicy？
NetworkPolicy（网络策略） 是Kubernetes中用于定义Pod之间或Pod与外部之间网络流量规则的API资源，它实现了网络层的访问控制，类似于防火墙规则，实行的是"白名单制"。
它的核心功能有：
（1）隔离Pod网络：默认情况下，Kubernetes集群中所有Pod之间可以互相通信（"全连通"）。NetworkPolicy可以限制哪些Pod可以访问特定Pod，哪些外部IP可以访问。
（2）控制出入流量：入站流量（Ingress）限制哪些来源可以访问当前Pod；出站流量（Egress）限制当前Pod可以访问哪些目标。
（3）标签选择器：通过Pod标签、命名空间标签、IP地址段等条件来定义允许或拒绝的流量。
工作原理 ：NetworkPolicy需要网络插件（CNI）支持，例如Calico、Cilium、Weave Net等。不支持的CNI插件会直接忽略NetworkPolicy。
5. 详细描述在K8s中如何控制跨Namespace的Pod访问？
默认情况下，Pod之间没有任何访问限制，可以自由通信。一旦命名空间中存在选择某个Pod的NetworkPolicy，该Pod就进入隔离状态，只接受策略允许的连接。多个策略同时选中一个Pod时候不会冲突，而是将各自规则合并起来------所有入站规则取并集，所有出站规则也取并集（规则是可以叠加的）。特别要注意的是：两个Pod要想成功通信，必须同时满足两个方向的要求------源端Pod的出站规则要允许，目标端Pod的入站规则也要允许；任何一方的拒绝都会导致流量被阻断。