【K8s】整体认识K8s之Configmap、Secret/ResourceQuota资源配额/访问控制

Configmap、Secret

ConfigMap是一个API对象，将K8s中的非机密数据以键值对的形式保存。使用的时候，可以将它用作环境变量、配置文件、参数。他的核心功能是将配置数据和应用数据分开。他里面的数据大小不能超过1MiB。

Secret的功能类似于Configmap，但是他保存的是机密数据，如密码、口令和密钥。这意味着不需要在应用程序代码中包含机密数据，增强了数据的安全性。

ResourceQuota资源配额

多个团队共享集群资源时，人们担心有人使用过多的资源量，资源配额来解决这个问题。资源配额怎么使用呢？不同的团队在不同的命名空间里工作，管理员给每个命名空间创建一个或多个ResourceQuota对象，定义这个命名空间可以使用的最大资源总量。用户在命名空间下下创建资源时，配额系统将会跟踪集群资源使用情况，保证命名空间的资源使用量不超过最大配额。配额被启用时，用户在请求资源时，必须设定请求值(request)和约束值（limit），否则系统将拒绝pod的创建。

K8s访问控制

Service account服务账号，它是k8s中一种特殊的账户，它不同于user， user的服务对象是人，而它的服务对象不是人，而是运行在pod中的应用程序，当Pod中的应用程程序需要调用k8 api来获取所有pod状态时，就需要使用服务账号。每一个pod在创建的时候都会被自动分配一个service account，默认是default，这个身份信息被编码到一个token中，并且自动挂载到pod内部的一个固定目录，当pod中的应用程序需要访问API服务器的时候，API服务服务器收到请求后会验证令牌的有效性，从而确认这个请求是来自某个命名空间下的某个service account。

但是仅仅有身份还不够，还需要有权限，这就是下面要说的role和cluster role，Service account就像给一个服务器发的工作证，这个工作证上写着我是后端服务***，k8s认证机制看到这个工作证就会知道你是内部的员工，允许你进入，但是进去之后你能访问哪些资源取决于你的权限设置（RBAC）。

角色其实就是一组权限的集合。role，它是作用在命名空间级别的，cluster role是作用在集群级别的，仅仅定义了角色还是不够，还需要将这个角色绑定到一个主体（user group或者service account）上，这个绑定操作才会真正的赋予权限。这需要通过rolebinding和clusterrole binding完成，将一个role或者cluster role的权限授予主体，但权限的有效范围取决于他引用的角色类型和绑定本身所在的命名空间

应用示例：

1. 场景A（精细控制）： 在 web 命名空间中创建一个 Role（规则：对 Pods 有 get, list 权限），然后创建一个 RoleBinding，将这个 Role 绑定到 Service Account web-app-sa。结果：web-app-sa 只能在 web 命名空间内列表和查看 Pod。

2. 场景B（集群范围只读）： 使用内置的 view ClusterRole（规则：对大多数资源有只读权限），在 kube-system 命名空间中创建一个 RoleBinding，将这个 ClusterRole 绑定到 Service Account monitor-sa。结果：monitor-sa 可以读取 kube-system 命名空间内的所有资源，但不能读取其他命名空间的资源。（因为 RoleBinding 限制了权限的作用域）。

3. 场景C（集群管理员）： 使用内置的 cluster-admin ClusterRole，创建一个 ClusterRoleBinding，将其绑定给一个用户。结果：该用户获得对整个集群的超级管理员权限。

Networkpolicy

Network policy，它是用于控制pod之间网络流量的防火墙规则，默认情况下k8s集群中所有的pod是可以自由通信的，而network policy允许你实施精细化的网络访问控制。

传统的防火墙是基于IP地址和端口来制定规则，而network policy它是基于pod的标签命名空间来定义规则，它主要控制流入pod的流量（ingress）和从pod流出的流量（egress），他有三个要素来定义允许或者拒绝的流量：podselector，通过标签选择器来选择哪些源pod或者目标pod可以通信；通过namespace selector来选择允许哪些命名空间中的pod进行通信；还可以使用ipblock来允许或者拒绝特定的CIDR网段

一旦你为某个pod创建了一个network policy，他就从非隔离状态变成了被隔离状态，被隔离的pod只允许network policy规则中明确允许的流量，其他所有的流量都会拒绝，这是一种白名单模型。规则是叠加的，如果一个pod被多个network policy选中，那么它的最终的有效规则是所有policy规则的叠加，为了允许两个pod之间的网络数据流，源端pod上的出站规则和目标端pod上的入站规则，都要允许该流量。

Network policy是一个独立的k8s资源对象，它有自己的yaml定义文件，使用kubectl apply -f <network-policy-file.yaml>来创建它，Networkpolicy如何与pod关联呢？通过在networkpolicy的spec.podSelector字段中指定标签来选择该策略应用于哪些pod