小楼一夜听春雨，深巷明朝卖杏花

比如数据处理管道的场景，扩容指标是队列中的事件数量， 当队列中堆积了大量事件时，我们希望可以快速扩容，但又不希望太灵敏，因为可能只是短时间内的事件堆积，即使不扩容也可以很快处理掉。如果流量高峰过了，并发量骤降，如果用默认的缩容策略，等几分钟后 Pod 数量也会随之骤降，如果 Pod 缩容后突然又来一个流量高峰，虽然可以快速扩容，但扩容的过程毕竟还是需要一定时间的，如果流量高峰足够高，默认的扩容算法会在较短的时间内扩容，针对这种场景我们可以给扩容增加一个时间窗口以避免毛刺导致扩容带来的资源浪费，

API 聚合机制是 Kubernetes 1.7 版本引入的特性，能够将用户扩展的 API 注册到 kube-apiserver 上，仍然通过 API Server 的 HTTP URL 对新的 API 进行访问和操作。为了实现这个机制，Kubernetes 在 kube-apiserver 服务中引入了一个 API 聚合层（API Aggregation Layer），用于将扩展 API 的访问请求转发到用户服务的功能。设计 API 聚合机制的主要目标如下。

这两个月和博云合作的项目是要用于客户生产环境的，这个和我以前做的东西有很大的不同，所有基础架构必须给出高可用的解决方案。在这之前我只做过一些流量较小的用户产品或者一些原型项目，一开始基础架构都只给出了单节点的解决方案，结果被大师兄喷这个在生产环境根本不可用。不过事实确实是在一个真实的分布式系统中硬件损坏、进程崩溃、网络不通都可能直接导致系统不可用。...

APIServer kube-APIServer 是 Kubernetes 最重要的核心组件之一，主要提供以下的功能： 提供集群管理的 REST API 接口，包括: • 认证 Authentication • 授权 Authorization • 准入 Admission（Mutating & Valiating）下面可以看到etcd就一根线连出来了，连到了apiserver，所以apiserver是整个集群的核心，......

1. 认证2.鉴权3.准入4.限流5.API Server 对象的实现 所谓的api-server其实就是整个kubernetes集群控制面的api网关。针对于任何api网关，它都要做自我保护，第一你需要做认证，我要知道你这个请求来自哪里，鉴权我要知道一个请求有没有操作权限。任何的请求都会以一个对象，object形式发过来，发到apiserver这一端，我还要去校验你这个请求的合法性，除了我要知道你是谁，你有没有这个操作权限，还要看你的request是不是合法的，比如说你的属性设置错了，或者说需要对你的re

开启 TLS时，所有的请求都需要首先认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的 username 会传入授权模块做进一步授权验证;而对于认证失败的请求则返回 HTTP 401。当apiserver启动的时候，其实有两个和安全相关的配置，一个叫insecure-port，一个叫secure-port，早期大家很习惯的将insecure-port打开，经过insecure-port端口所有的请求其实是没有做任何的安全校验的，也就是认证

在上文中，用户A在发起API请求时，管理员如何道该请求是用户A发起的呢？所以，客户端在发起API请求时，必须要携带一个身份信息来表明"我是谁"，Apiserver在收到请求后，需要对这个身份信息进行认证（“不是你说你是谁，你就是谁，而是我核实你是谁，你才是谁”）apiserver可以通过启动参数--basic-auth-file=/path/to/file来开启密码认证，该文件的每一行如下：第一个字段为密码，第二个为用户名，第三个为用户id，后面为组名（可选，如果有多个组，则需要用双引号引起来）

的SerivceAccount后，我们来看一下这个ServiceAccount的内容。我们按照前面yaml文件创建Pod，那么apiserver将会把该ServiceAccount的Secret挂载到Pod的路径。然后，然后apiserver的serviceaccount认证器拿到这个ServiceAccountToken后，利用参数。从外部访问Apiserver的安全端口时，客户端需要携带一个身份凭证，能够让apiserver认证为某个用户以及所属的组。我们来看一下这个Secret的内容，如下。

本文将主要分享以下三方面的内容：Kubernetes API 请求访问控制 Kubernetes 认证 Kubernetes RBAC Security Context 的使用一、Kubernetes API 请求访问控制访问控制大家都知道访问控制是云原生中的一个重要组成部分。也是一个 Kubernetes 集群在多租户环境下必须要采取的一个基本的安全架构手段。那么在概念上可以抽象的定义为谁在何种条件下可以对什么资源做什么操作。这里的资源就是在 Kubernetes 中我们.

众所周知 TLS 的作用就是对通讯加密，防止中间人窃听；同时如果证书不信任的话根本就无法与 apiserver建立连接，更不用提有没有权限向 apiserver 请求指定内容。在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式。当集群开启了 TLS 认证后，每个节点的 kubelet 组件都要使用由 apiserver 使用的 CA 签发的有效证书才能与 apiserver 通讯；此时如果节.

ServiceAccount 介绍接下来，我们讲一下 ServiceAccount。ServiceAccount 首先是用于解决 pod 在集群里面的身份认证问题，身份认证信息是存在于 Secret 里面。[root@k8s-master ~]# kubectl get secretNAME TYPE DATA AGEdefault-token-j9294 kubernetes.io/s

之前我们学习了kubernetes有哪些认证插件，通过几个简单的最基础的认证方式，包括静态token，包括x509，包括serviceaccount，理解了认证插件是如何运作的。如果要将一个k8s集群落地到你的企业，要做生产化运维的时候，你往往要做的的第一步就是和企业内部的认证平台去做集成。如果只是小的集群，只有几个人使用，那么是没有必要的，因为k8s本身是开放式的平台，一般落地生产集群的时候，可以通过一些机制把它构建为多租户的平台，可以让企业用户都来使用这个平台。可以通过和认证集成，通过权限控制，通过配额

作为多租户集群方案中的一环，我们需要在namespace的准入控制中，获取用户信息，并将用户信息更新的namespace的annotation。只有当namespace中有有效用户信息时，我们才可以在namespace创建时，自动绑定用户权限，namespace才可用。准入控制通常有两种主要的目的，一个是你给了我request，这个request长的这个样子，是你填的所有的属性，但是我从平台的一个层面，我希望给它添加一些附加属性。......

前面介绍看k8s的各种认证方式，以及和企业认证如何集成，认证完之后，认证是用来知道request代表的人，或者个体，组件是谁。认证结束了只能认清楚你是谁了，你能够做什么操作我还是不确定的，这个事情就要通过鉴权来解决。 k8s有各种各样的对象，因为是声明式的系统，在任何用户操作这些对象的时候，我要去知道你有没有这个操作权限，所以要通过严格的鉴权策略来定义整个集群，哪些用户有哪些对象的操作权限。授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略

k8s 内置的集群角色 systemk8s为了让用户使用某些特定的权限，给大家预留了四个集群角色，这个是可以是直接使用的。以system开头的都是k8s内置的，不要随便删除，删除了可能导致集群功能不正常[root@k8s-master ~]# kubectl get clusterroleNAME CREATED ATsystem:aggregate-to-.

Admission Webhook：准入控制器Webhook是准入控制插件的一种，用于拦截所有向APISERVER发送的请求，并且可以修改请求或拒绝请求。 Admission webhook为开发者提供了非常灵活的插件模式，在kubernetes资源持久化之前，管理员通过程序可以对指定资源做校验、修改等操作。例如为资源自动打标签、pod设置默认SA，自动注入sidecar容器等。 相关Webhook准入控制器： • MutatingAdmissionWebhook：修改资源，理论上可以监

资源 Quota在生产中我们还会遇到一个场景：假如集群是由多个人同时提交的，或者是多个业务同时在使用，我们肯定要限制某个业务或某个人提交的总量，防止整个集群的资源都会被使用掉，导致另一个业务没有资源使用。Kubernetes 给我们提供了一个能力叫：ResourceQuota 方法。它可以做到限制 namespace 资源用量。具体的做法如上图右侧的 yaml 所示，可以看到它的 spec 包括了一个 hard 和 scopeSelector。hard 内容其实和 Resourcelist

资源配额 ResourceQuota当多个团队、多个用户共享使用K8s集群时，会出现不均匀资源使用，默认情况下先到先得，这时可以通过ResourceQuota来对命名空间资源使用总量做限制，从而解决这个问题。使用流程：k8s管理员为每个命名空间创建一个或多个ResourceQuota对象，定义资源使用总量，K8s会跟踪命名空间资源使用情况，当超过定义的资源配额会返回拒绝。ResourceQuota功能是一个准入控制插件，默认已经启用。还可以基于存储类来控制PVC请求的总量。计算资源配

资源配额 LimitRange默认情况下，K8s集群上的容器对计算资源没有任何限制，可能会导致个别容器资源过大导致影响其他容器正常工作，这时可以使用LimitRange定义容器默认CPU和内存请求值或者最大上限。(默认是使用宿主机上面所有的资源)在哪个命名空间下面创建，那么就是应用在哪个命名空间。LimitRange限制维度： • 限制容器配置requests.cpu/memory，limits.cpu/memory的最小、最大值 • 限制容器配置requests.cpu/

What are Kubernetes audit logs?Audit logsrecord requests to theKubernetes API. Because the API server processes all changes to Kubernetes state—and serves as the gatekeeper to the backend database that stores this state—the API server is an ideal po.....

之前说过了，认证，鉴权，准入，这三个重要的环节。到此为止k8sapiserver就已经将请求继续往后传递了，作为rest服务器，它一定要有自我保护机制，这个自我保护的机制最核心的就是限流。作为web服务器，处理能力是有上限的，不能无休止的接受用户的请求，所以要做一个约定说这边能够接受多少请求。下面来看看限流有哪些传统的方法。............

第三种 Metrics，是 Kubernetes 相关的监控数据。这部分数据，一般叫作 Kubernetes 核心监控数据（core metrics）。这其中包括了 Pod、Node、容器、Service 等主要 Kubernetes 核心概念的 Metrics。其中，容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务。在 kubelet 启动后，cAdvisor 服务也随之启动，而它能够提供的信息，可以细化到每一个容器的 CPU 、文件系统、内存、网络等资源的使用情

--enable-bootstrap-token-auth=truetoken.csv该文件为一个用户的描述文件，基本格式为 Token,用户名,UID,用户组；这个文件在 apiserver 启动时被 apiserver 加载，然后就相当于在集群内创建了一个这个用户；接下来就可以用 RBAC 给他授权。bootstrap.kubeconfig该文件中内置了 token.csv 中用户的 Token，以及 apiserver CA 证书；kubelet 首次启动会加载此文件，使用 apis.

APIServerd的一些硬核原理其实前面说的差不多了，就是认证，鉴权，准入，限流。这是APIserver里面最核心的能力，还有一些watch的缓存，因为apiserver除了承担之前的那些职责之外，它还承担了一些角色是保护etcd，apiserver是唯一可以访问etcd这样一个组件，可以有效的收敛外面过来的请求，从apiserver通过同一个客户端，以长连接连到etcd里面，有效的减小etcd的压力。同时它在这边有基于内存的缓存机制，有些读操作你直接到apiserver。...

之前的apiserver其实讲解的差不多了，其实就是认证，鉴权，准入，以及限流。这是apiserver里面最核心的能力，当然还有一些比如watch的缓存，除了承担上面的职责之外，它还承担的了重要的角色就是保护etcd，apiserver是唯一一个可以访问etcd这样一个组件，因为我可以收敛从外面过来的请求，从apiserver同一个客户端以长连接连接到etcd里面，有效的减小etcd的压力。

如果其中一个负载均衡器发生故障，那么该负载均衡器上的流量将被移除，流量将被转移到其他负载均衡器，最终转发到API Server。当某个实例处于不健康的状态时，负载均衡器应停止向这个实例分发请求。这样，当外部的负载均衡器出现问题时，不会影响集群内部客户端访问API Server。所示，最直接的方案是客户端及其他控制平面组件使用负载均衡器与API Server。因此，在这个基础上还应进行一些优化配置，以获得更高的容错性和灵活性。的负载，但是将单点故障转移到了负载均衡器上。所示，在配置多个负载均衡器时，