【云原生训练营】模块六 Kubernetes 控制平面组件：API Server

0、API Server概念

kube-apiserver是Kubernetes最重要的核心组件之一，主要提供以下的功
能

• 提供集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更
  等
• 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）
• 属于通信枢纽，各个k8s模块交互中心

Kubernetes API的每个请求都会经过多阶段的访问控制之后才会被接受，这包括 认证、授权以及准入控制（Admission Control） 等。

访问控制细节

max-in-flight：设置API Server处理请求上限

1、认证

开启TLS时，所有的请求都需要首先认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的username会传入授权模块做进一步授权验证；而对于认证失败的请求则返回HTTP 401。

• X509证书
  使用X509客户端证书只需要API Server启动时配置–client-ca-file=SOMEFILE。在证书认证时，其CN域用作用户名，而组织机构域则用作group名。

• 静态Token文件

  • 使用静态Token文件认证只需要API Server启动时配置–token-auth-file=SOMEFILE。
  • 该文件为csv格式，每行至少包括三列token,username,user id，
    token,user,uid,"group1,group2,group3”

• 引导Token

  • 为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型， 称作 启动引导令牌（Bootstrap Token）。
  • 这些令牌以 Secret 的形式保存在 kube-system 名字空间中，可以被动态管理和创建。
  • 控制器管理器包含的 TokenCleaner 控制器能够在启动引导令牌过期时将其删除。
  • 在使用kubeadm部署Kubernetes时，可通过kubeadm token list命令查询。

• 静态密码文件

  • 需要API Server启动时配置–basic-auth-file=SOMEFILE，文件格式为csv，每行至少三列password, user, uid，后面是可选的group名
    password,user,uid,"group1,group2,group3”

• ServiceAccount

  • ServiceAccount是Kubernetes自动生成的，并会自动挂载到容器的/run/secrets/kubernetes.io/serviceaccount目录中。kubectl get serviceaccount default -o yaml

OpenID
- OAuth 2.0的认证机制

Webhook 令牌身份认证

• –authentication-token-webhook-config-file 指向一个配置文件，其中描述 如何访问远程的 Webhook 服务。
• –authentication-token-webhook-cache-ttl 用来设定身份认证决定的缓存时间。 默认时长为 2 分钟。

匿名请求

• 如果使用AlwaysAllow以外的认证模式，则匿名请求默认开启，但可用–anonymous-auth=false禁止匿名请求。

基于webhook的认证服务集成

构建符合Kubernetes规范的认证服务

https://github.com/cncamp/101/tree/master/module6/basic-auth

1、开发认证服务

2、配置apiserver

2、鉴权

授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略才能被处理。跟认证类似，Kubernetes也支持多种授权机制，并支持同时开启多个授权插件（只要有一个验证通过即可）。如果授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证；对于授权失败的请求则返回HTTP 403。

Kubernetes授权仅处理以下的请求属性：

• user, group, extra
• API、请求方法（如get、post、update、patch和delete）和请求路径（如/api）
• 请求资源和子资源
• Namespace
• API Group

目前，Kubernetes支持以下授权插件：

• ABAC
• RBAC
• Webhook
• Node

RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在 Kubernetes中被映射为 API 资源和操作。

Role与ClusterRole

Role（角色）是一系列权限的集合，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限。Role只能用来给某个特定namespace中的资源作鉴权，对多namespace和集群级的资源或者是非资源类的API（如/healthz）使用ClusterRole。

1、创建角色

2、binding绑定

账户／组的管理

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。它包含若干 主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。
组的概念：

• 当与外部认证系统对接时，用户信息（UserInfo）可包含Group信息，授权可针对用户群组
• 当对ServiceAccount授权时，Group代表某个Namespace下的所有ServiceAccount，（如下下图右侧）

组与ROLE角色的概念
认证系统通常会说属于哪个组的，角色是指该角色的权限。 该组是什么角色，拥有什么权限。

3、准入

Mutating
Validating
Admission

准入控制

为资源增加自定义属性

• 作为多租户集群方案中的一环，我们需要在namespace的准入控制中，获取用户信息，并将用户信息更新的namespace的annotation

只有当namespace中有有效用户信息时，我们才可以在namespace创建时，自动绑定用户权限，namespace才可用。

准入控制（Admission Control）在授权后对请求做进一步的验证或添加默认参数。不同于授权和认证只关心请求的用户和操作，准入控制还处理请求的内容，并且仅对创建、更新、删除或连接（如代理）等有效，而对读操作无效。

准入控制支持同时开启多个插件，它们依次调用，只有全部插件都通过的请求才可以放过进入系统。

准入控制插件

• AlwaysAdmit: 接受所有请求。

• AlwaysPullImages: 总是拉取最新镜像。在多租户场景下非常有用。

• DenyEscalatingExec: 禁止特权容器的exec和attach操作。

• ImagePolicyWebhook: 通过webhook决定image策略，需要同时配置--admission-control-config-file

• ServiceAccount：自动创建默认ServiceAccount，并确保Pod引用的ServiceAccount已经存在

• SecurityContextDeny：拒绝包含非法SecurityContext配置的容器

• ResourceQuota：限制Pod的请求不会超过配额，需要在namespace中创建一个ResourceQuota对象

• LimitRanger：为Pod设置默认资源请求和限制，需要在namespace中创建一个LimitRange对象

• InitialResources：根据镜像的历史使用记录，为容器设置默认资源请求和限制

• NamespaceLifecycle：确保处于termination状态的namespace不再接收新的对象创建请求，并拒绝请求不存在的namespace

• DefaultStorageClass：为PVC设置默认StorageClass

• DefaultTolerationSeconds：设置Pod的默认forgiveness toleration为5分钟

• PodSecurityPolicy：使用Pod Security Policies时必须开启

• NodeRestriction：限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源

除默认的准入控制插件以外，Kubernetes预留了准入控制插件的扩展点，用户可自定义准入控制插件实现自定义准入功能

• MutatingWebhookConfiguration：变形插件，支持对准入对象的修改
• ValidatingWebhookConfiguration：校验插件，只能对准入对象合法性进行校验，不能修改

4、限流

计数器固定窗口算法

原理就是对一段固定时间窗口内的请求进行计数，如果请求数超过了阈值，则舍弃该请求；
如果没有达到设定的阈值，则接受该请求，且计数加1。
当时间窗口结束时，重置计数器为0。

在固定窗口的基础上，将一个计时窗口分成了若干个小窗口，然后每个小窗口维护一个独立的计数器。
当请求的时间大于当前窗口的最大时间时，则将计时窗口向前平移一个小窗口。
平移时，将第一个小窗口的数据丢弃，然后将第二个小窗口设置为第一个小窗口，同时在最后面新增一个小窗口，将新的请求放在新增的小窗口中。
同时要保证整个窗口中所有小窗口的请求数目之后不能超过设定的阈值。

漏斗算法

漏斗算法的原理也很容易理解。请求来了之后会首先进到漏斗里，然后漏斗以恒定的速率将请求流出进行处理，从而起到平滑流量的作用。
当请求的流量过大时，漏斗达到最大容量时会溢出，此时请求被丢弃。
在系统看来，请求永远是以平滑的传输速率过来，从而起到了保护系统的作用。

令牌桶算法

• 令牌桶算法是对漏斗算法的一种改进，除了能够起到限流的作用外，还允许一定程度的流量突发。
• 在令牌桶算法中，存在一个令牌桶，算法中存在一种机制以恒定的速率向令牌桶中放入令牌。
• 令牌桶也有一定的容量，如果满了令牌就无法放进去了。
• 当请求来时，会首先到令牌桶中去拿令牌，如果拿到了令牌，则该请求会被处理，并消耗掉拿到的令牌；
• 如果令牌桶为空，则该请求会被丢弃。
  

APIServer对象的实现

后续详细内容看PPT