目录
5. 详细描述在 K8s 中如何控制跨 Namespace 的 Pod 访问？
1. 解释 ResourceQuota 的作用。
- ResourceQuota（资源配额）用来在有多个用户或团队共享具有固定节点数目的集群时，可以解决有人使用超过其基于公平原则所分配到的资源量的问题。
- 通过 ResourceQuota 对象可以对每个命名空间的资源消耗总量提供限制。它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。
2. 解释 Service Account 的用途。
- Service Account （服务账号）为 Pod 中运行的进程提供身份标识，并映射到 ServiceAccount 对象。
- 当应用向 API 服务器执行身份认证时，应用会将自己标识为某个用户，K8s 能够识别用户的概念，但是 K8s 自身并不提供 User API。
- 因此，Service Account 是为了方便 Pod 里面的进程调用 K8s API 或其他外部服务而设计的。
3. 详细解释 Role 和 ClusterRole。
- 基于角色（ Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。
- RBAC API 声明了四种 K8s 对象： Role、 ClusterRole、RoleBinding 和 ClusterRoleBinding。
① Role 总是用来在某个命名空间内设置访问权限，在创建 Role 时，必须指定该 Role 所属的名字空间。
② ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole）是因为 K8s 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。
- 如果希望在命名空间内定义角色，就应该使用 Role；如果希望定义集群范围的角色，则应该使用
ClusterRole。
4. 什么是 K8s 的 NetworkPolicy？
- NetworkPolicy （网络策略）是一种以应用为中心的结构，允许我们设置如何允许 Pod 与网络上的各类网络“实体”通信。
- NetworkPolicy 适用于一端或两端与 Pod 的连接，与其他连接无关。
- 网络策略对 Pod 间的流量控制是通过如下三个标识符的组合来辩识的：
① 其他被允许的 Pods（例外：Pod 无法阻塞对自身的访问）；
② 被允许的名字空间；
③ IP 组块（例外：与 Pod 运行所在的节点的通信总是被允许的，无论 Pod 或节点的 IP 地址）。
5. 详细描述在 K8s 中如何控制跨 Namespace 的 Pod 访问？
- 默认情况下， Pod 是非隔离的，它们接受任何来源的流量。
- Pod 在被某 NetworkPolicy 选中时进入被隔离状态，一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，则该 Pod 就会拒绝该 NetworkPolicy 所不允许的连接。
- 网络策略不会冲突，它们是累积的。如果任何一个或多个策略选择了一个 Pod，则该 Pod 受限于这些策略的入站（Ingress）/出站（Egress）规则的并集，评估的顺序并不会影响策略的结果。
- 为了允许两个 Pods 之间的网络数据流，源端 Pod 上的出站规则和目标端 Pod 上的入站规则都需要允许该流量。如果源端的出站规则或目标端的入站规则拒绝该流量，则流量将被拒绝。