云原生俱乐部-k8s知识点归纳（6）

写到这感觉我对k8s的理解也仅仅是理论上的，因为说实话，没怎么手写过创建资源的yml文件，我做的知识点归纳也很少涉及yml文件的编写。因为内容有很多，而且里面的字段也没有很熟悉。

但是yml文件容易看懂，毕竟是声明式的。但是想要记住，就不是一件那么容易的事情了。或许后面我可以将k8s资源的yml文件的字段进行总结，现在的话加快进度将各种k8s的资源等内容总结完，将整体框架构建出来。

这一篇主要讲一讲configMaps、Secrets、资源配额以及访问控制这四部分内容，内容相对来说比较简单，除了RBAC访问控制。

configMaps

当介绍一个资源的时候，该怎么介绍呢？其实就两部分，一是如何创建这个资源，而是如何使用这个资源。把握住这两方面，自然就能够理解清楚它的意义与作用了。

[1]创建configMaps

其实也就只有三种创建方式，第一种是通过字面值创建该资源，如kubectl create configmap my-config  --from-literal=LOG_LEVEL=debug  --from-literal=DB_HOST=mysql。可以使用kubectl describe configmaps name来查看指定名称的map的情况。

第二种就是通过文件来创建configMaps资源，如kubectl create configmap nginx-config --from-file=nginx.conf 从单个文件中创建map，键名为文件名，值为文件内容。还有kubectl create configmap app-config --from-file=configs/从目录下创建。

第三种就是通过定义yml文件，使用data字段来写入键值对，不过要注意的是，这些都是明文的。

[2]使用configMaps

其实configMaps可以提供环境变量给其他资源来使用，甚至可以作为存储设备来挂载。原理是configMaps中的键值对键名转为文件名，值转为内容，以文件的形式放到挂载点目录中，并且修改configMaps后，已挂载的文件默认会自动更新​​。

Secrets

前面提到了configMaps是明文存储的，那么secrets则用于存储敏感数据，使用kubectl describe secrets name看不到保存的数据。该部分内容的和configMaps差不多，就是如何创建以及如何使用secrets资源。

在 `kubectl create secret generic`命令中，`generic`表示创建的 secret 类型为通用型secret（Base64编码）。secret同样使用键值对的形式保存数据，如使用字面量--from-literal=username=admin。

当然，我们可以通过yml文件来定义资源，注意的是如果yml文件中使用data字段，需要自己手动用Base64编码敏感内容。如果用stringData，就会在创建secret资源的时候自动进行Base64编码，但是敏感内容本身存放在secrets资源的定义文件中。

资源配额

资源配额（Resource Quotas）​是 Kubernetes 中用于​限制命名空间内资源使用量​的机制。确保不同团队或项目共享集群时公平分配资源，避免单一命名空间耗尽集群资源，可以为每个命名空间设置一个或多个ResourceQuota。

可以使用spec.containers.resources字段来给每个容器都设置资源配额（如cpu、memory），分别有requests和limits两个限制，前者是申请的资源，后者是容器最大能够使用的资源，如果容器占用的资源超过limits则会被终止（pod其他容器不受影响），然后根据重启策略决定是否重启。

如果 Pod 的  `requests`资源总和（所有容器的  `requests`累加）​超过命名空间的  `ResourceQuota`中  `requests`的硬性限制​，则无法创建该pod（request和limit两者独立校验）。若节点资源不足（无法满足requests），Pod 无法调度到该节点上。

访问控制

[1]serviceAccount

当创建新命名空间时，Kubernetes 会自动在该命名空间中生成一个名为  `default`的 ServiceAccount。`default`ServiceAccount ​​默认没有任何权限​，并且若不显式指定，pod使用命名空间下的  `default`ServiceAccount。

可以通过kubectl -n namespacename serviceaccount servicename来在指定的命名空间创建账户，如果要查看的话，可以使用kubectl -n namespacename describe servicecount servicename来查看指定的账户。

Pod 的 ServiceAccount Token 会自动挂载到  `/var/run/secrets/kubernetes.io/serviceaccount`。如果 Pod 需要访问 Kubernetes API，会使用 ServiceAccount 的 Token 向  `kube-apiserver`发送 HTTP 请求。

默认 API 地址是`https://kubernetes.default`（通过 DNS 解析到 apiserver）。apiserver会检查 Token 对应的 ServiceAccount 是否被授权执行该操作（通过 RBAC），若权限足够，返回请求的资源或执行操作，若权限不足，返回  `403 Forbidden`。

[2]role和clusterRole

如果需要让 Pod 访问 Kubernetes API，必须通过 RBAC 显式绑定权限（serviceAccount），如创建roleBinding或者clusterRoleBinding。

role是一组权限规则的集合​，它定义了​在特定命名空间内​允许的操作（如  `get`、`list`、`create`）和资源（如  `pods`、`services`）。clusterRole 是集群级别的 Role​，定义​跨所有命名空间​的权限，或用于集群级资源，如  `nodes`、`persistentvolumes`。

可以通古kubectl -n nsname create rolebinding --role=rolename --serviceaccount=nsname:accountname，如果是clusterRoleBinding的话，就不需要指定集群权限的命名空间了。

要注意的是，role和clusterrole不及能够绑定到k8s中的服务账户，还能绑定到linux的用户和组！控制用户能对哪些资源执行哪些操作​。

[3]networkPolicy

Kubernetes 网络策略(NetworkPolicy)是一种资源对象，用于控制 Pod 之间的网络通信规则。它允许管理员定义精细的网络访问控制策略，实现 Pod 级别的网络安全隔离。网络策略的实现依赖于 CNI(Container Network Interface)插件。

当然，如果未实施任何网络策略，则是接受所有的入站流量和允许所有的出站流量。使用networkPolicy需要指定命名空间，spec.podSelector​用于选择策略适用的 Pod，为{}则表示该命名空间的所有pod都应用该网络策略。

还有个spec.ingress.from.podSelector指定允许哪些pod访问，如果只用podSelector表示仅匹配当前命名空间的，可以使用spec.ingress.from.namespaceSelector指定其他命名空间，如果为{}则表示所有的命名空间。

egress​则用于定义出站规则，​使用to​定义流量的目标（from定义来源），ports​则指定允许的端口和协议。如果使用egress: [] 不定义规则，那么就相当于允许所有流量出站。网络策略的直接管控对象是 Pod 而非 Service，不过通过组合 `podSelector`+ `ports`可以实现 Service 端口的访问控制。