Service Account是为了方便 Pod 中的容器访问API Server。由于 Pod 的创建、销毁是动态的,所
以要为每一个 Pod 手动天生证书就不可行了。 Kubenetes 使用了 Service Account 来循环认证,
从而解决了 Pod 访问API Server的认证标题。
2.6.Secret 与 SA 的关系
Kubernetes 计划了一种资源对象叫做 Secret,分为两类:
用于保存 ServiceAccount 的 service-account-token
用于保存用户自界说保密信息的 Opaque
Service Account 中包罗三个部分
Token:是使用 API Server 私钥署名的 Token 字符串序列号,用于访问 API Server 时,Server 端认证
ca.crt:ca 根证书,用于 Client 端验证 API Server 发送来的证书
namespace:标识这个 service-account-token 的作用域名空间
默认环境下,每个 namespace 都会有一个 Service Account,如果 Pod 在创建时没有指定
Service Account,就会使用 Pod 所属的 namespace 的 Service Account。每个 Pod 在创建后都会
自动设置 spec.serviceAccount 为 default(除非指定了其他 Service Accout)
二.鉴权
1.鉴权的方式
之前的认证(Authentication)过程,只是确定通讯的双方都确认了对方是可信的,可以相互通
信。而鉴权是确定请求方有哪些资源的权限。API Server 目前支持以下几种授权策略:(通过 API
Server 的启动参数 “--authorization-mode” 设置)
准入控制是 API Server 的一个准入控制器插件列表,通过添加不同的插件,实现额外的准入控制
规则。发送到 API Server 的请求都需要颠末这个列表中的每个准入控制器插件的查抄,查抄不通
过,则拒绝请求
一般建议直接接纳官方默认的准入控制器 官方准入控制器推荐列表(不同版本各有不同)
NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSecond
s,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,NodeRestriction 列举几个插件的功能
官方文档参考:https://kubernetes.io/zh/docs/reference/access-authn-authz/admission- controllers/ 资源限制 - Pod
Kubernetes对资源的限制现实上是通过cgroup来控制的,cgroup是容器的一组用来控制内核如何
运行历程的相干属性集合。针对内存、CPU 和各种设备都有对应的 cgroup
默认环境下,Pod 运行没有 CPU 和内存的限额。这意味着系统中的任何 Pod 将能够像实行该 Pod
所在的节点一样, 斲丧足够多的 CPU 和内存。一般会针对某些应用的 pod 资源进行资源限制,
这个资源限制是通过 resources 的 requests 和 limits 来实现。requests 为创建 Pod 时初始要分配
的资源,limits 为 Pod 最高请求的资源值