乐山的网站建设公司,小视频剪辑app哪个好,瑞幸咖啡网络营销策划方案,经纪公司排名云原生学习路线导航页#xff08;持续更新中#xff09;
kubernetes学习系列快捷链接 Kubernetes架构原则和对象设计#xff08;一#xff09;Kubernetes架构原则和对象设计#xff08;二#xff09;Kubernetes架构原则和对象设计#xff08;三#xff09;Kubernetes控…云原生学习路线导航页持续更新中
kubernetes学习系列快捷链接 Kubernetes架构原则和对象设计一Kubernetes架构原则和对象设计二Kubernetes架构原则和对象设计三Kubernetes控制平面组件etcd一Kubernetes控制平面组件etcd二Kubernetes控制平面组件API Server详解一Kubernetes常见问题解答查看云机器的一些常用配置 本文是kubernetes的控制面组件API Server详解二首先总览了API Server的整个处理流程然后对 max-in-flight限流限制、authorization授权鉴权机制、aggregator扩展apiserver机制、内置apiserver的请求转换处理和admission准入控制模块 分别进行了详细介绍 希望大家多多 点赞 关注 评论 收藏作者会更有动力继续编写技术文章 1.API Server处理流程概览 request-timeoutrequest进来会先去做request-timeoutauthenatication进行身份认证audit认证通过后会进行 审计日志 Audit 的记录主要是记录什么人做了什么修改操作方便在出问题时定位请求的来源比如对象被删时可以用来定责impersonation用于模拟用户身份的字段 在request-header中有一个impersonation header可以指定该值来模拟用户身份。比如a用户发起的一个请求但是它可以通过 impersonation header 把这个请求模拟成b用户Kubernetes会把该请求认为是b用户即a用户代替b用户来做操作且后续的鉴权将会按照b用户进行一个不太常用的功能 max-in-flight用于做限流正在飞的请求–正在运行的请求 可以配置 允许API Server同时处理多少请求即允许有多少尚未返回的请求 authorization鉴权kubernetes aggregator扩展API Server处理器 Kubernetes为 内置资源提供了 默认的 API Server处理器可以处理pod、deployment等内置资源但如果你希望自己来处理资源也可以自己编写一个API Server处理器挂载上来那么在kubernetes aggregator这里就会判断使用哪个处理器进而往下走 resource handler kubernetes内置apiserver处理器的核心逻辑包括解码、版本转换、默认值填充、准入、校验、和etcd交互等decoding解码request conversion defaulting当用户请求的 API 版本与最新版本不一致时转成内部通用版本然后进行默认值填充admission准入校验rest logicrest处理模块 storage conversion defaulting将请求转成rest请求操作存储etcd result conversion处理响应encoding对响应编码 request-timeout、authenatication、audit、impersonation 模块请见 Kubernetes控制平面组件API Server详解一 2.max-in-flight 请求限流
Kubernetes控制平面组件APIServer 限流机制详解
3.authorization授权鉴权 3.1.认证和授权概念辨析
在 Kubernetes控制平面组件API Server详解一 中我们详细讲解了 apiserver 的认证机制那么认证和授权有什么区别呢认证Authentication 目的验证请求者的身份侧重于身份的校验拦截非法身份支持方式 静态密码文件X509证书Bearer TokenServiceAccount TokenWebhook 等 失败响应认证失败返回 401 Unauthorized 授权鉴权Authorization 目的验证请求者 有没有权限 执行当前操作此时已经知道请求者身份了侧重于权限校验拦截 用户越权 的行为三要素 操作主体Subject目标资源Resource操作动作Verb 核心问题谁Who能对什么资源What执行什么操作How失败响应鉴权失败返回 403 Forbidden
3.2.API Server 支持的授权模式
以下是补充了缩写全称的表格
模式全称特点适用场景ABACAttribute-Based Access Control基于属性配置需重启API Server简单测试环境RBACRole-Based Access Control通过API对象动态配置生产环境主流方案WebhookWebhook Authorization对接外部授权系统企业统一权限体系NodeNode Authorization节点组件专用授权kubelet权限控制
3.3.RBAC 与 ABAC 对比 3.3.1.ABAC 特点
使用方法# 需在 apiserver master 节点配置策略文件
--authorization-policy-file/etc/kubernetes/policy.json缺点 静态文件方式定义授权策略每次更改都需要重启API Server策略更新困难缺乏灵活性
3.3.2.RBAC 优势
通过API对象管理权限Role/ClusterRole无需重启API Server即可更新授权策略支持动态更新细粒度权限控制支持命名空间隔离
3.4. authorization 4种授权模式详解
3.4.1.ABAC授权模式详解
3.4.2.RBAC授权模式详解
3.4.3.Webhook授权模式详解
3.4.4.Node授权模式详解
3.5.与权限相关的最佳实践 4.kubernetes aggregator 扩展 APIServer 处理器
4.1.APIServer扩展 基本原理
4.1.1.APIServer 扩展核心组件
Kubernetes Aggregator聚合层是 Kubernetes APIServer 的扩展机制允许将自定义或第三方 APIServer 无缝集成到主 APIServerkube-apiserver中。核心组件包括 APIService 对象声明 API 组和版本的访问规则并关联后端服务Service。聚合层Aggregator作为七层负载均衡动态路由请求到扩展APIServer。GenericAPIServer提供通用 APIServer 功能如认证、鉴权、路由所有子 APIServer 均基于此构建。
4.1.2.APIServer扩展工作流程
请求入口客户端通过主 APIServer 发起请求如 /apis/custom.group/v1。路由决策聚合层根据 APIService 配置匹配请求路径转发到扩展 APIService 的 Service。安全认证主 APIServer 使用 TLS 证书与扩展 APIServer 双向认证确保通信安全。代理与响应扩展 APIServer 处理请求后结果通过主 APIServer 返回客户端。
4.2.自定义 APIServer 的开发步骤
4.2.1.开发准备
技术选型基于 k8s.io/apiserver 库构建实现标准的 Kubernetes API 接口。核心接口 REST.Storage处理资源的增删查改操作需实现 Getter、Lister 等接口。Scheme 注册定义资源的序列化规则如 runtime.Object 结构体。
4.2.2.代码结构
// 示例代码框架基于 k8s.io/apiserver
func main() {config : genericapiserver.NewConfig() // 创建通用配置config.EnableMetrics true// 注册自定义资源 Schemescheme : runtime.NewScheme()customv1.AddToScheme(scheme)// 构建 APIGroupInfoapiGroupInfo : genericapiserver.NewDefaultAPIGroupInfo(...)apiGroupInfo.VersionedResourcesStorageMap[v1] storageMap// 初始化 GenericAPIServerserver, _ : config.Complete().New(my-apiserver, genericapiserver.NewEmptyDelegate())server.InstallAPIGroup(apiGroupInfo)server.PrepareRun().Run(stopCh)
}4.2.3.关键组件实现
存储层对接数据库或自定义存储需实现 etcd3.Store 接口。认证与鉴权 复用 Kubernetes 的 RBAC 机制通过 SubjectAccessReview 验证权限。使用 --requestheader-client-ca-file 和 --proxy-client-cert-file 配置 TLS 证书。
4.3.与 kube-apiserver 的集成
4.3.1.创建 APIService 对象
# APIService 定义示例
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:name: v1.custom.group
spec:group: custom.groupversion: v1service:namespace: custom-systemname: custom-api-server # 指向自定义 APIServer 的 Serviceport: 443caBundle: base64-encoded-CA # 用于验证扩展 APIServer 的 CA4.3.2.服务发现与负载均衡
Service 配置需创建 ClusterIP 或 NodePort 类型的 Service确保主 APIServer 可访问。Endpoints 验证通过 kubectl get endpoints 检查后端 Pod 状态。
4.3.3.权限配置
RBAC 规则需为自定义 APIServer 分配 system:auth-delegator 角色允许代理请求。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: custom-apiserver-auth-delegator
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:auth-delegator
subjects:
- kind: ServiceAccountname: custom-apiservernamespace: custom-system4.4.注意事项
1. 安全与证书管理
CA 一致性主 APIServer 与扩展 APIServer 的证书必须由同一 CA 签发。证书轮换定期更新 TLS 证书避免过期导致通信中断。
2. 性能与调试
请求代理开销聚合层代理可能增加延迟建议优化扩展 APIServer 处理逻辑。日志与监控启用 APIServer 的 --v4 日志级别结合 Prometheus 监控指标。
3. 版本兼容性
多版本共存支持 v1 和 v1beta1 等版本通过 spec.versionPriority 控制优先级。废弃策略逐步淘汰旧版本使用 deprecated 注解标记。
4.5.实操案例Metrics Server 的实现
4.5.1.案例背景
Metrics Server 是 Kubernetes 官方提供的聚合 APIServer用于采集 Node 和 Pod 的 CPU/内存指标。
4.5.2.实现步骤
APIService 注册apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:name: v1beta1.metrics.k8s.io
spec:service:name: metrics-servernamespace: kube-systemgroup: metrics.k8s.ioversion: v1beta1自定义 APIServer实现 metrics/v1beta1 组资源的 GET /nodes/{node}/metrics 接口。权限配置为 metrics-server ServiceAccount 绑定 system:metrics-server 角色。
4.5.3.验证
kubectl top nodes # 查看节点指标
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | jq # 直接访问 API5.resource handler 内置 APIServer 处理器
5.1.请求conversion defaulting
5.1.1.基础概念 Conversion版本转换 • 定义将不同 API 版本的资源对象转换为统一 内部版本Internal Version 的机制确保多版本兼容性。例如用户提交的 apps/v1beta1.Deployment 会被转换为 apps/v1.Deployment 的内部表示。 • 核心目标实现 API 版本的平滑升级和降级避免因版本变更导致数据丢失或服务中断。 Defaulting默认值填充 • 定义为资源对象中未显式指定的字段填充默认值的机制。例如未设置 Pod 的 imagePullPolicy 时默认填充 IfNotPresent。 • 核心目标简化用户配置确保资源的完整性和一致性避免因字段缺失导致运行时错误。
5.1.2.设计理念
多版本兼容性
向后兼容通过版本转换支持旧版本 API 请求允许用户逐步迁移到新版本。版本共存API Server 可同时处理多个版本的资源对象如 v1 和 v1beta1。
配置简洁性
用户友好通过默认值隐藏复杂配置细节例如自动填充 Service 的 ClusterIP 或 Deployment 的滚动更新策略。规范化确保资源对象符合 Schema 定义减少人工校验成本。
扩展性与解耦
插件化机制Conversion 和 Defaulting 均可通过扩展点如 CustomResourceDefinition 或 Admission Webhook实现自定义逻辑。 mutatingwebhookconfigurations修改资源属性validatingwebhookconfigurations校验资源
5.1.3.实现原理
Conversion 实现机制
版本注册表每个 API 组如 apps、batch注册其支持的版本及转换函数。转换链Conversion Chain 步骤1将用户提交的外部版本如 v1beta1转换为内部版本。步骤2持久化到 etcd 时转换为存储版本Storage Version。步骤3响应时根据请求的 API 版本反向转换。 转换函数通过 conversion-gen 工具自动生成或手动实现字段映射逻辑。
Defaulting 实现机制
Schema 定义在资源的 OpenAPI Schema 中声明字段的 default 值如 spec.replicas: 1。准入控制阶段在请求验证前由 Mutating Admission Controller 或内置逻辑填充默认值。自定义默认值通过编写 Admission Webhook 动态填充如根据 Namespace 设置资源配额。
5.1.4.处理流程 #mermaid-svg-KZi9kHoVhEdcw0Mc {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .error-icon{fill:#552222;}#mermaid-svg-KZi9kHoVhEdcw0Mc .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-KZi9kHoVhEdcw0Mc .marker{fill:#333333;stroke:#333333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .marker.cross{stroke:#333333;}#mermaid-svg-KZi9kHoVhEdcw0Mc svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-KZi9kHoVhEdcw0Mc .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .cluster-label text{fill:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .cluster-label span{color:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .label text,#mermaid-svg-KZi9kHoVhEdcw0Mc span{fill:#333;color:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .node rect,#mermaid-svg-KZi9kHoVhEdcw0Mc .node circle,#mermaid-svg-KZi9kHoVhEdcw0Mc .node ellipse,#mermaid-svg-KZi9kHoVhEdcw0Mc .node polygon,#mermaid-svg-KZi9kHoVhEdcw0Mc .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-KZi9kHoVhEdcw0Mc .node .label{text-align:center;}#mermaid-svg-KZi9kHoVhEdcw0Mc .node.clickable{cursor:pointer;}#mermaid-svg-KZi9kHoVhEdcw0Mc .arrowheadPath{fill:#333333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-KZi9kHoVhEdcw0Mc .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-KZi9kHoVhEdcw0Mc .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-KZi9kHoVhEdcw0Mc .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-KZi9kHoVhEdcw0Mc .cluster text{fill:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc .cluster span{color:#333;}#mermaid-svg-KZi9kHoVhEdcw0Mc div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-KZi9kHoVhEdcw0Mc :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是 否 用户请求 版本转换 Conversion 是否需转换? 调用转换函数 生成内部版本 默认值填充 Defaulting 填充 Schema 定义的默认值 执行 Admission Control 验证 持久化到 etcd Conversion 流程 • 用户请求携带 apiVersion 字段如 apps/v1beta1。 • API Server 根据注册的转换函数将对象转换为内部版本。 • 存储到 etcd 时转换为存储版本由 --storage-versions 指定。 Defaulting 流程 • 在验证阶段前遍历资源对象字段。 • 若字段未设置且 Schema 中定义默认值则自动填充。 5.1.5.参数配置 Conversion 相关配置 • API 版本启用通过 --runtime-configapps/v1beta1true 启用特定 API 版本。 • 存储版本设置在 CRD 中指定 spec.versions.storage: true 定义存储版本。 Defaulting 相关配置 • Schema 默认值在 CRD 的 OpenAPI Schema 中定义 default 字段 spec:versions:- name: v1schema:openAPIV3Schema:properties:spec:properties:replicas:type: integerdefault: 1• Admission Webhook配置 Mutating Webhook 实现动态默认值。
5.1.6.实操案例 自定义 Conversion 函数 场景将自定义资源 MyApp 从 v1alpha1 升级到 v1。 步骤 • 定义转换函数 func Convert_v1alpha1_MyApp_To_v1_MyApp(in *v1alpha1.MyApp, out *v1.MyApp, s conversion.Scope) error {out.Spec.Replicas in.Spec.ReplicaCount // 字段重命名映射return nil
}• 注册转换函数到 scheme scheme.AddConversionFunc(v1alpha1.MyApp{}, v1.MyApp{}, Convert_v1alpha1_MyApp_To_v1_MyApp)• 更新 CRD 的 spec.versions 和 storage 标志。 动态 Defaulting 示例 场景为所有新创建的 Pod 自动添加 env: prod 标签。 步骤 • 编写 Mutating Webhook func mutatePod(ar v1.AdmissionReview) *v1.AdmissionResponse {pod : corev1.Pod{}if err : json.Unmarshal(ar.Request.Object.Raw, pod); err ! nil {return denyRequest(err)}if pod.Labels nil {pod.Labels make(map[string]string)}pod.Labels[env] prodreturn createPatchResponse(ar.Request.Object.Raw, pod)
}• 配置 Webhook 的 ValidatingWebhookConfiguration指定匹配规则为 CREATE Pod。
5.1.7.优化与注意事项 性能优化 • Conversion 缓存缓存常用版本的转换结果减少重复计算。 • Defaulting 延迟加载仅在必要时填充默认值避免资源浪费。 兼容性风险 • 版本废弃策略通过 deprecated 注解标记旧版本逐步淘汰。 • 默认值变更修改 Schema 默认值时需考虑已存在资源的影响。 调试工具 • 查看内部版本使用 kubectl get --raw /apis/group/version/resource?asinternal 查看转换后的内部对象。 • Dry-Run 模式通过 kubectl apply --dry-runserver 验证默认值填充逻辑。
5.2.admission准入控制
请见Kubernetes控制平面组件APIServer 准入控制机制详解
6.API Server代码学习
Kubernetes控制平面组件API Server代码基础概念
7.应用案例如何搭建一个多租户的kubernetes集群 基于前面对kubernetes集群架构 API Server的学习现在应该具备设计一个多租户kubernetes集群的能力。下面介绍基本思路。 1.以ns为隔离域的租户隔离设计 首先通过准入控制的 Webhook Controller在ns create阶段自动为ns绑定用户权限实现只有指定用户才可以访问某个ns。具体实现如下在ns创建时通过一个mutatingwebhookconfigurations变形webhook插件将用户信息写入ns的annotation 2.做好用户访问的授权鉴权 关闭匿名访问只允许可信用户操作鉴权时判断请求用户信息是否存在于ns的annotation即可判断当前用户是否有权限访问该ns管理员可以控制指定用户的ns权限和可见范围其实就是控制ns上anno中是否包含某个用户的信息 3.做好ns的配额管理 通过在ns下创建ResourceQuota定义ns下资源的配额比如最多允许的pod数量、cm数量、service/ingress数量等还可以编写一个Controller监听ns create事件自动创建配额。 用户视角下的隔离性 可见性隔离用户只能看到自己创建的ns下面的应用和服务没有其他ns权限资源隔离用户只能使用自己ns下的资源配额之内的资源其他的用不了另外特有node上可以通过 打上污点Taint 的方式防止其他用户调度上来实现资源层隔离应用访问隔离用户可以对自己应用配置访问限制 实现以上内容集群其实就已经是一个多租户集群了
8.应用案例如何与企业现有认证系统集成
