kubernetes关键组件之API-SERVER

       Kubernetes的API Server在集群架构中扮演核心角色，提供REST API接口，支持资源对象如node、pod、service的增删改查以及watch功能。其主要特性包括集群管理API、cnvcs.com源码数据交互枢纽、资源配额控制入口、集群安全机制拥有者。

       API Server的工作原理涉及集群管理的REST API，包括认证授权、数据校验和集群状态变更。它是数据交互和通信的核心，仅直接操作etcd，提供集群安全机制。访问方式多样，包括Kubernetes REST API、kubectl代理、kubectl客户端命令行调用及用户进程调用API。

       常用API接口通过kube-apiserver提供，监听和端口，后者提供更高安全性。Kubernetes Proxy用于代理REST请求，将API Server收到的请求转发至Node上的kubelet，由其响应。创建Proxy接口可实现此功能。

       API Server与集群模块交互，客服单页源码负责通信，各模块通过API Server存取etcd数据库信息。获取数据可通过API Server提供的REST接口，使用GET、LIST或Watch方法。查看ETCD数据时，可通过Node、Pod、Service相关接口，访问节点、Pod和Service信息。

       Node相关接口包括节点名称或IP地址指定的节点信息查询，列出节点内所有Pod信息、物理资源统计和概要信息。Pod相关接口允许访问特定服务或Pod，实现集群外部访问Pod服务的目的。Service相关接口则提供访问特定Namespace中服务的途径。

       API Server的proxy接口在集群外部访问Pod服务时尤为重要，用于管理目的，如逐一排查Service的Pod副本或检查服务异常。通过这种方式，API Server成为实现集群内部交互和外部访问的关键组件。

apiserver 开启聚合层

       é€šè¿‡ä»¥ä¸‹ kube-apiserver 标记启用汇聚层。这些标记必须已经被服务提供商实现。

        --requestheader-client-ca-file=<path to aggregator CA cert>

        --requestheader-allowed-names=aggregator

        --requestheader-extra-headers-prefix=X-Remote-Extra-

        --requestheader-group-headers=X-Remote-Group

        --requestheader-username-headers=X-Remote-User

        --proxy-client-cert-file=<path to aggregator proxy cert>

        --proxy-client-key-file=<path to aggregator proxy key>

        如果 kube-proxy 没有和 API server 运行在同一台主机上，那么需要确保启用了如下 apiserver 标记：

        --enable-aggregator-routing=true

Kubernetes API

       kube-apiserver是Kubernetes架构的核心组件，负责接收所有组件的API请求，它在集群中起着中枢神经的作用，任何操作都需要通过kube-apiserver进行。广告推广的源码在Kubernetes中，我们通常提及的资源，如Deployment、Service等，实际上就是API操作的对象，这些资源最终被存储在etcd中，本质上是对etcd中资源进行增删改查(CRUD)。

       当我们使用kubectl命令查看集群中某个命令空间的Deployment时，实际上kubectl将命令转化为API请求发送给kube-apiserver，然后将kube-apiserver返回的数据以特定格式输出。

       API设计遵循一组和版本的规则，即groupVersion，例如`/apis/apps/v1/deployment`。其中`apis`表示API的组集合，`apps`是特定的组，`v1`是版本。而`/api/v1`这一组API则被视为核心组，因为Kubernetes在初期并未预期到未来API的丰富性，将所有资源API置于`/api/v1`下，以适应不断增长的需求。

       每一个API都包含组和版本属性，版本定义了API的稳定性，以便在多次迭代后达到成熟状态。通过`kubectl get -raw /`命令可以查看集群中的所有API。

       Kubernetes的API对象组织方式分为核心组和命名组，核心组包含所有资源，qq飞车源码全套命名组则针对特定资源，如`/apis/$NAME/$VERSION`。命名组和系统范围内的实体，如metrics，共同组成API结构。

       资源可分为命名空间资源和集群资源。命名空间资源，如Pod、Deployment、Service，属于特定命名空间，其API请求遵循特定的组织形式。集群资源，如ClusterRole，则不在任何命名空间和版本下。非资源URL则与Pod、ClusterRole不同，用于验证etcd服务健康状态，不属于任何命名空间或版本。

       自定义API用于开发自定义功能，例如`custom.io`表示自定义的API组，`test`为自定义资源。Kubernetes的REST API设计遵循一组和版本的规则，以实现API的组织和稳定性。

       理解Kubernetes的API结构对于深入阅读源代码和开发自定义API至关重要。明确API的爱发源码交易组织方式和规则能够帮助开发者更高效地与Kubernetes系统进行交互，构建更复杂的部署和管理逻辑。

听GPT 讲K8s源代码--cmd(一)

       在 Kubernetes（K8s）的cmd目录中，包含了一系列命令行入口文件或二进制文件，它们主要负责启动、管理和操控Kubernetes相关组件或工具。这些文件各司其职，如：

       1. **check_cli_conventions.go**: 该文件作用于检查CLI约定的规范性，确保命令行工具的一致性和易用性。它提供函数逐项验证命令行工具的帮助文本、标志名称、标志使用、输出格式等，输出检查结果并提供改进意见。

       2. **cloud_controller_manager**: 这是启动Cloud Controller Manager的入口文件。Cloud Controller Manager是Kubernetes控制器之一，负责管理和调度与云平台相关的资源，包括负载均衡、存储卷和云硬盘等。

       3. **kube_controller_manager**: 定义了NodeIPAMControllerOptions结构体，用于配置和管理Kubernetes集群中的Node IPAM（IP地址管理）控制器。此文件包含配置选项、添加选项的函数、应用配置的函数以及验证配置合法性的函数。

       4. **providers.go**: 用于定义和管理云提供商的资源。与底层云提供商进行交互，转换资源对象并执行操作，确保Kubernetes集群与云提供商之间的一致性和集成。

       5. **dependencycheck**: 用于检查项目依赖关系和版本冲突，确保依赖关系的正确性和没有版本冲突。

       6. **fieldnamedocs_check**: 检查Kubernetes代码库中的字段名称和文档是否符合规范，确保代码的规范性和文档的准确性。

       7. **gendocs**: 生成Kubernetes命令行工具kubectl的文档，提供命令的用法说明、示例、参数解释等信息，方便用户查阅和使用。

       8. **genkubedocs**: 生成用于文档生成的Kubernetes API文档，遍历API组生成相应的API文档。

       9. **genman**: 用于生成Kubernetes命令的man手册页面，提供命令的说明、示例和参数等信息。

       . **genswaggertypedocs**: 生成Kubernetes API的Swagger类型文档，提供API的详细描述和示例。

       . **genutils**: 提供代码生成任务所需的通用工具函数，帮助在代码生成过程中创建目录和文件。

       . **genyaml**: 为kubectl命令生成YAML配置文件，方便用户定义Kubernetes资源。

       . **importverifier**: 检查代码中的导入依赖，并验证其是否符合项目中的导入规则。

       . **kube_apiserver**: 实现kube-apiserver二进制文件的入口点，负责初始化和启动关键逻辑。

       . **aggregator**: 为聚合API提供支持，允许用户将自定义API服务注册到Kubernetes API服务器中，实现与核心API服务的集成。

       这些文件共同构建了Kubernetes命令行界面的底层逻辑，使得Kubernetes的管理与操作变得更加高效和灵活。

一文详解kube-apiserver认证鉴权能力

       本文详细解析kube-apiserver的认证与鉴权功能，由华为云社区作者分享。HTTPS安全连接的基础在于身份验证，确保客户端与服务端的安全通信。

       通过API接口访问kube-apiserver时，若遇到访问失败，通常是因为客户端无法验证服务端证书，这时需要验证服务端身份。虽然可以在公网环境中不验证服务端证书，但不建议这样做，因为这可能导致访问的是虚假服务端。确保服务端证书真实性的关键在于第三方权威机构CA，服务端将信息和公钥发送给CA，CA进行签名并生成证书。

       HTTPS认证过程涉及CA私钥的保密性，签名的不可篡改性，以及证书内容的完整性。通过携带K8S集群CA证书，可以成功建立HTTPS连接并完成完整的认证流程。

       Kubernetes认证方式包括Token认证和证书认证。Token认证通过serviceaccount和secret中的token进行，而证书认证则需要生成私钥和CSR文件，并通过CertificateSigningRequest申请证书。鉴权环节，kube-apiserver通过RBAC机制管理权限，允许用户、组或serviceaccount访问特定资源。

       通过以上步骤，我们可以为创建的serviceaccount和用户myuser分配权限，创建角色、角色绑定，并在访问kube-apiserver时验证和授权。

kube-apiserver审计功能介绍及使用

       åœ¨kubernetes集群中，API Server是操作集群资源的入口，API server的审计功能可以记录每个到达的请求，进而可以帮助集群管理人员记录或者追溯不同用户的日常操作。记录的信息可以包括但不限于以下信息。

        API Server的处理包括很多个步骤，认证、限流、鉴权、跨域处理、webhook、审计处理，真正的处理单元、回复响应等等。审计功能是API Server请求处理流水线上的一环，是对API Sever能力的扩展。

        如上图所示，审计可以发生在三个位置，其中RequestReceived表示审计单元接受到请求，未将请求下发到下一级流水线单元之前；ResponseComplete表示API Server已经回复了响应body之后； ResponseStarted表示回复了响应头，但未回复响应body之前，只用于long-runtime的请求，如log，watch，exec等。

        审计可以通过两种方式记录请求，log和webhook，log是指将请求记录到本地的文件系统，webhook是指将请求记录发送到外部api去处理。

        在生产实践中，请求也是可以分优先级的，如configmap的list请求，显然是没有必要将configmap的所有内容都记录下来的。所以对于每一个请求，可以配置不同的审计策略，如None表示不记录该请求，Metadata表示只记录该请求的元信息，其中元信息是指请求的User，URI，类型等等。

        审计功能的特性在API Server中默认是开启的，但不配置审计后端，则无法进行日志记录。

        审计相关的配置项是直接配置在API Server的命令行参数中的，多达项。因此这里需要先将功能梳理请求，才能理解这个配置项。这里以后端日志记录log为例，首先日志要记录到什么地方，随着日志的写入，日志文件的大小逐渐增大，是否要将文件进行拆分，保留多少份拆分日志文件，拆分的日志文件是否要压缩，为了日志文件不占用过多的磁盘资源，需要对旧的日志文件进行清理，这就涉及到日志文件最多保留多少天。 审计单元的处理是否要处理完成后，再将请求移交到到下一步的流水线单元中进行处理，这个就涉及到是否阻塞API Server。

        假如log模式设置为batch，就表示要积累一定数量的请求，然后一次性写入，这就涉及到batch相关的配置

        假如单个请求的大小过大，是否要对请求进行拆分，这就涉及到truncate相关的配置。

        在下图中，将配置项分为3类，通用配置，batch类配置和truncate类配置（未写出webhook类型的配置）。

        审计策略

        审计功能提供了非常灵活的策略项配置。配置策略的目的就是要精细化得对请求做日志记录，重要的请求，记录的信息要全一些，如create，delete请求，非关键性的请求，可以少记录一些，如leases请求。

        审计策略中重要的字段如下 ：

        下面的配置是在官方审计示例策略的基础上增加了一些配置。

        以下是阿里产品文档给的一些示例配置信息

        经过上面的分析，审计功能是API Server处理请求流水线的一环，增加审计功能，会增加API Server的内存消耗（官方文档明确写出的），另外log模式配置为默认值blocking的话，会略微增加API Server的响应延迟，所以这里建议使用batch模式。

如何通过kube-apiserver访问K8s集群中的App

       通过kube-apiserver访问K8s集群中的App是一种可行且方便的方式。传统上，App可以通过ClusterIP、NodePort或LoadBalancer等方式进行访问，但利用kube-apiserver也能实现访问。在实现过程中，涉及到容器的启动、设置svc通道、访问权限配置以及访问方式调整等多个步骤。

       首先，创建一个名为ng-dp.yaml的文件，内容用于启动一个nginx容器并监听端口。执行相应命令，启动容器。

       接着，创建ng-svc.yaml文件，定义svc通道，使得集群内部可以访问该App。执行命令部署svc。

       获取kube-apiserver地址，以便后续访问App。访问方式有两种：通过token或证书。获取sa（service-account）信息，查询sa内容以找到token值，设置env环境后即可访问App。若权限不足，需调整sa权限，如提高权限等级。另一种方式是直接配置证书访问，从kubeconfig文件中获取所需证书，配置证书后尝试访问。

       访问App时，可以使用kube-apiserver提供的代理URL格式，该格式基于es的NodePort范围，可以通过编辑kube-apiserver的配置文件来实现。以下是具体步骤：

       首先，定位到kube-apiserver的配置文件，通常在/etc/kubernetes/manifests/kube-apiserver.yaml中。默认情况下，NodePort范围为-。要修改这个范围，只需在该文件中添加或更新相应的参数行，如：

       --service-node-port-range=-

       这个选项应放置在`--service-cluster-ip-range=..0.0/`下方，以确保配置的顺序正确。

       由于kubelet会自动监视目录变化，一旦你保存了修改，kubelet会检测到并使用新的配置自动重启kube-apiserver。无需额外手动操作，只需等待kubelet处理并确认kube-apiserver的重启。你可以通过查看kube-apiserver的启动时间来验证这个过程，如果发现重启，说明更改已经生效。

       这样，你就可以成功将Kubernetes的NodePort范围调整为你需要的范围。记得在执行这些操作时要谨慎，确保理解配置的含义，以避免影响集群的正常运行。