Kubernetes 高级开发指南容器级高级特性与 API 扩展的完整实践手册【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook本文面向已经熟悉 Kubernetes 核心概念、能够独立部署应用的开发者系统讲解两类进阶能力一是使用高级功能部署应用Sidecar / Init 容器、Taint 与 Toleration、Downward API、PodPreset、HPA、联邦集群对象二是扩展 Kubernetes APICRD、API 聚合、自定义控制器、Service Catalog。读完本文你将掌握在不动核心代码的前提下按需定制 Kubernetes 行为、编写自定义资源与控制器、接入外部托管服务的方法并结合本仓库kubernetes-handbook的概念文档、Manifests 示例与源码分析章节获得可直接落地的实战方案。使用高级功能部署应用在掌握 DaemonSet 与 Deployment 等核心对象之后日常部署通常已经够用。但 Kubernetes 还提供了一系列鲜为人知却威力强大的高级功能它们在特定场景下能显著简化架构、提升弹性。下面按容器级功能、Pod 配置、其他 API 对象三个维度展开。容器级功能超越 1:1 的 Pod 模型把整个应用例如 Rails 应用、MySQL 数据库及其所有组件塞进单个 Pod 是一种反模式。但容器与 Pod 之间并非只能一一对应有两种非常有用的模式值得掌握Sidecar 容器Pod 中依然需要一个主容器main container同时你可以添加一个或多个副容器作为辅助这类副容器即Sidecar 容器。单个 Pod 中的多个容器共享网络命名空间并可通过共享卷进行通信。本仓库 Sidecar 模式 一节对该模式做了专门阐述将应用程序的功能拆分为独立进程、运行在同一个最小调度单元Pod中就可以在不动应用代码的前提下为其附加日志采集、监控、代理、配置同步等能力。Sidecar 与主应用松散耦合可屏蔽编程语言差异统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。使用 Sidecar 模式部署服务网格时无需在每个节点上运行代理而是为每个应用容器注入一个伴生 Sidecar 容器接管进出应用容器的所有流量。两个容器共享存储、网络等资源可以广义地把这个包含 Sidecar 容器的 Pod 理解为一台主机。其核心优势包括将与业务逻辑无关的功能抽象到公共基础设施降低微服务代码复杂度不再为每个服务重复编写第三方组件配置与代码降低代码重复度Sidecar 可独立升级降低应用代码与底层平台的耦合度。在 Service Mesh 实践中Sidecar 模式正是 Envoy 等数据面代理的部署基础可参见本仓库 理解 Istio Service Mesh 中的 Sidecar 注入与流量劫持 与 Sidecar 规范。Init 容器Init 容器是一种专用容器在 Pod 的应用容器主容器与 Sidecar 容器之前运行。本仓库 Init 容器 详细说明了它的两个核心特性Init 容器总是运行到成功完成为止每个 Init 容器都必须在前一个 Init 容器成功完成后才启动按顺序依次执行。如果 Init 容器失败Kubernetes 会不断重启该 Pod直到成功为止但如果 Pod 的restartPolicy为Never则不会重启。指定容器为 Init 容器只需在 PodSpec 中增加initContainers字段其状态在status.initContainerStatuses字段中返回。Init 容器的典型用途等待一个 Service 创建完成例如循环执行dig myservice直到 DNS 解析成功通过调用管理 API 将 Pod 注册到远程服务器在启动应用容器前延迟一段时间如sleep 60克隆 Git 仓库到共享数据卷运行模板工具如 Jinja用 POD_IP 等动态值生成主应用配置文件。以下 YAML 展示了一个带两个 Init 容器的 Pod第一个等待myservice启动第二个等待mydb启动两个 Service 就绪后应用容器才启动apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: [sh, -c, echo The app is running! sleep 3600] initContainers: - name: init-myservice image: busybox command: [sh, -c, until nslookup myservice; do echo waiting for myservice; sleep 2; done;] - name: init-mydb image: busybox command: [sh, -c, until nslookup mydb; do echo waiting for mydb; sleep 2; done;]版本兼容性说明Kubernetes 1.5 时代使用 annotationpod.beta.kubernetes.io/init-containers声明 Init 容器1.6 起支持spec.initContainers字段1.8 以后只支持新语法。API Server 版本为 1.6 或更高时均通过spec.initContainers支持 Init 容器。对应两个依赖 Service 的 YAMLkind: Service apiVersion: v1 metadata: name: myservice spec: ports: - protocol: TCP port: 80 targetPort: 9376 --- kind: Service apiVersion: v1 metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377启动与调试命令$ kubectl create -f myapp.yaml pod myapp-pod created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m $ kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器日志 $ kubectl logs myapp-pod -c init-mydb # 查看第二个 Init 容器日志启动myservice与mydb两个 Service 后Init 容器完成myapp-pod转为 Running$ kubectl create -f services.yaml service myservice created service mydb created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9mInit 容器的具体行为要点在 Pod 启动过程中Init 容器按顺序在网络和数据卷初始化之后启动每个必须在下一个启动之前成功退出在所有 Init 容器成功之前Pod 不会变成Ready正在初始化中的 Pod 处于Pending状态但Initializing状态会被置为 true如果 Pod 重启所有 Init 容器必须重新执行对 Init 容器 spec 的修改被限制在image字段其他字段修改不生效因为可能被重启、重试或重新执行Init 容器的代码应当幂等尤其注意写入EmptyDir的代码要容忍输出文件已存在Init 容器支持应用容器的全部字段和特性资源限制、数据卷、安全设置唯一例外是不支持readinessProbe因为它必须在 Pod 就绪前运行完成Pod 上可使用activeDeadlineSeconds、容器上使用livenessProbe来避免 Init 容器无限失败Pod 中每个应用容器与 Init 容器的名称必须唯一。资源规则所有 Init 容器上定义的任一资源请求/限制的最大值是有效初始请求/限制Pod 对资源的有效请求/限制要高于所有应用容器请求/限制之和与有效初始请求/限制两者。调度基于有效请求/限制完成因此 Init 容器可以为初始化预留资源这些资源在 Pod 生命周期内不会被应用容器占用。配额、限制与 Pod 级 cgroups 均基于有效 Pod 请求/限制计算。Pod 配置元数据注入与调度约束通常使用Label 与 Annotation为资源附加元数据使用ConfigMap非机密数据或Secret机密数据向资源注入数据。除此之外还有几种不太为人所知的配置手段Taint污点与 Toleration容忍Taint 与 Toleration 用于优化 Pod 在集群间的调度与节点亲和性作用方向相反具有 taint 的节点与未容忍它的 Pod 是互斥关系而节点亲和性使 node 与 pod相吸。每个节点可应用一个或多个 taint不能容忍这些 taint 的 Pod 不会被该节点接受为 Pod 设置 toleration 后它可以但不要求被调度到具有相应 taint 的节点上。为 node1 设置 taintkubectl taint nodes node1 key1value1:NoSchedule kubectl taint nodes node1 key1value1:NoExecute kubectl taint nodes node1 key2value2:NoSchedule删除 taintkubectl taint nodes node1 key1:NoSchedule- kubectl taint nodes node1 key1:NoExecute- kubectl taint nodes node1 key2:NoSchedule-查看节点上的 taintkubectl describe nodes node1为 Pod 设置 toleration只需在 spec 中声明tolerations字段可包含多个 keytolerations: - key: key1 operator: Equal value: value1 effect: NoSchedule - key: key1 operator: Equal value: value1 effect: NoExecute - key: node.alpha.kubernetes.io/unreachable operator: Exists effect: NoExecute tolerationSeconds: 6000要点说明effect的值可以是NoSchedule、PreferNoSchedule或NoExecutetolerationSeconds是当 Pod 需要被驱逐时可以继续在节点上运行的时间秒当需要把应用调度到特定硬件例如科学计算用的 GPU时Taint/Toleration 是常用手段。Downward API向下 APIDownward API允许容器使用关于自己或集群的信息而无需过度耦合到 Kubernetes API Server。它有两种暴露方式环境变量将 Pod 的 name、namespace、Pod IP、node 名称等信息以环境变量注入容器DownwardAPIVolumeFile以文件形式挂载这些字段容器可动态读取。apiVersion: v1 kind: Pod metadata: name: downward-demo spec: containers: - name: main image: busybox env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIPPodPresetPod 预设通常要把环境变量、ConfigMap、Secret 等运行时需求注入资源需要在资源配置文件中逐个声明。PodPreset允许你在资源创建时动态注入这些需求例如团队 A 可以把任意数量的新 Secret 注入到团队 B、C 创建的资源中而无需 B、C 团队参与操作。本仓库 Pod Preset 一节说明PodPreset 通过label selector指定作用于哪些 Pod从而让 Pod 模板作者不必为每个 Pod 明确提供全部信息。工作原理准入控制器Kubernetes 提供了PodPreset准入控制器Pod 创建请求到达时执行以下流程检索所有可用的 PodPresets检查 PodPreset 标签选择器是否匹配正在创建的 Pod 上的标签尝试将 PodPreset 定义的各种资源合并到正在创建的 Pod 中出现错误时在该 Pod 上引发记录合并错误的事件PodPreset不会注入任何资源为修改后的 Pod spec 添加注解podpreset.admission.kubernetes.io/podpreset-pod-preset name: resource version。每个 Pod 可匹配零个或多个 PodPreset每个 PodPreset 可应用于零个或多个 Pod。对于Env、EnvFrom和VolumeMounts的修改作用于 Pod 中所有容器的容器 spec对于Volume的修改作用于 Pod Spec。注意PodPreset 中的资源定义不会应用于initContainers字段。如果希望某个 Pod 不被任何 PodPreset 修改可在其 spec 中添加注解annotations: podpreset.admission.kubernetes.io/exclude: true启用 PodPreset 需要满足三个条件启用settings.k8s.io/v1alpha1/podpresetAPI 类型——在 API Server 的--runtime-config中包含settings.k8s.io/v1alpha1true启用PodPreset准入控制器——将其加入 API Server 的--admission-control选项在目标命名空间中创建PodPreset对象。注意PodPreset 资源对象自 Kubernetes 1.8 以上版本才支持。其他 API 对象HPA 与联邦集群对象以下资源在创建前请先确认是否属于集群管理员cluster admin的职责范围。Horizontal Pod AutoscalerHPA应用资源使用率通常有高峰低谷。HPAHorizontal Pod Autoscaler让 Service 中的 Pod 数量根据 CPU 利用率或其他自定义度量标准自动伸缩是 Kubernetes 自动化运维能力的集中体现。HPA 属于 autoscaling SIG 的范畴自 Kubernetes 1.2 引入1.6 之前通过 kubelet 获取监控指标1.6 之后必须通过 API Server、Heapster 或 kube-aggregator 获取监控指标。Metrics 支持按 API 版本autoscaling/v1仅支持 CPUautoscaling/v1alpha1支持内存、自定义 metricsKubernetes 1.6 起需在 kube-controller-manager 中配置--horizontal-pod-autoscaler-use-rest-clientstrue并让--api-server指向 kube-aggregator 或启用--api-servertrue的 heapster、以及多种 metrics 组合HPA 根据每个 metric 分别计算 scale 值取最大者作为扩容结果。HPA 只适用于 Deployment 和 ReplicaSet。与普通资源一样可通过 kubectl 管理资源名hpakubectl create hpa kubectl get hpa kubectl describe hpa kubectl delete hpa也可直接用kubectl autoscale一行命令创建kubectl autoscale deployment foo --min2 --max5 --cpu-percent80上述命令为 Deployment foo 创建 autoscaler当 Pod 的 CPU 利用率达到 80% 时副本数在 25 之间伸缩。工作原理HPA 由一个控制循环实现周期由 controller manager 的--horizontal-pod-autoscaler-sync-period标志指定默认 30 秒。每个周期内controller manager 查询 HPA 定义的 metric 利用率对每个 Pod 的 resource metric如 CPU从 resource metric API 获取每个 Pod 的指标结合容器 resource request 计算利用率或使用原始值再对所有目标 Pod 求平均得出所需副本数的比率对每个 Pod 的自定义 metric类似上述逻辑但直接使用原始值对object metric获取描述对象本身的单一度量与目标值比较得出比率。HPA 控制器可通过两种方式获取 metric直接访问 Heapster通过 API Server 的服务代理子资源需在 kube-system 命名空间部署 Heapster或使用 REST 客户端。最终通过 Scale 子资源/scale调整副本数。注意不能把 HPA 绑定到裸 ReplicationController 做滚动更新滚动更新创建新 RC 后 HPA 不会绑定到新 RC应绑定到 Deployment由 Deployment 管理底层 RC 的滚动更新。自定义 metric 前提条件在 controller manager 中设置--horizontal-pod-autoscaler-use-rest-clientstrue将--apiserver指向 API server aggregatorresource metric API 与自定义 metric API 必须向 aggregator 注册并由集群内 API Server 提供。Heapster 可通过--api-servertrue实现 resource metric API自定义 metric API 需独立组件提供。本仓库在 Horizontal Pod Autoscaling 与 Custom Metrics HPA 中有完整讲解并提供了可直接使用的清单示例HPA 配置、自定义 metrics 示例、示例应用。联邦集群对象Federation如果使用Federation在多个 Kubernetes 集群上运行应用程序则需要部署标准 Kubernetes API 对象的联合版本。本仓库 联邦Federation 与 多集群Multicluster 章节介绍了跨集群部署与管理思路可结合 联邦概念图 理解控制平面如何编排多个成员集群的 Deployment、Service 等对象。扩展 Kubernetes APIKubernetes 在设计之初就考虑了可扩展性。如果内置 API 资源与功能不够用可以在不修改核心 Kubernetes 代码的前提下自定义其行为。理解 Kubernetes 的默认行为做任何自定义之前先理解所有 API 对象背后的一般抽象。虽然 Deployment 与 Secret 看起来完全不同但对任何对象而言以下概念都成立Kubernetes 对象是存储集群结构化数据的一种方式Deployment 的数据代表期望状态如应该运行多少副本Secret 则是通用元数据如数据库凭证Kubernetes 对象通过 Kubernetes API 修改可以对特定资源路径如api-server-url/api/v1/namespaces/default/deployments执行GET、POST请求来读取或修改对应对象类型利用 Controller 模式对象可被确保达到期望状态Controller 模式可以看作一个连续循环——(1) 检查当前状态副本数、容器镜像等(2) 对比当前状态与期望状态(3) 若不匹配则更新当前状态。状态均通过 Kubernetes API 获取。并非所有对象都需要 ControllerDeployment 会触发集群状态变更而 ConfigMap 纯粹作为存储。创建自定义资源基于上述抽象你可以定义与 Deployment 一样合法的自定义资源。例如如果内置CronJob不能满足需求你可以定义Backup对象来做定期备份。创建自定义资源有两条路径自定义资源定义CRDCustomResourceDefinition工作量最小的实现方式API 聚合Aggregation需要先配置聚合层再运行独立的扩展 API Server。注意与依赖内置kube-controller-manager不同你需要自己编写并运行自定义控制器。选择方法时请考虑如何判断自定义资源是否适合你的场景 以及 CRD 与 API 聚合的取舍详见 使用自定义资源扩展 API。CRD最小工作量的扩展方式创建新的 CRD 时Kubernetes API Server 会为每个指定版本创建新的 RESTful 资源路径。CRD 可以是命名空间的也可以是集群范围的由scope字段指定CRD 本身是非命名空间的可供所有命名空间使用。本仓库 使用 CRD 扩展 Kubernetes API 提供了完整教程下面给出一个经典示例resourcedefinition.yamlapiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: # 名称必须符合格式plural.group name: crontabs.stable.example.com spec: # REST API 使用的组名称/apis/group/version group: stable.example.com versions: - name: v1 # 通过 served 开关每个 version served: true # 有且仅有一个 version 开启存储 storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer # Namespaced 或 Cluster scope: Namespaced names: # URL 中使用的复数名称/apis/group/version/plural plural: crontabs # CLI 中使用的单数名称 singular: crontab # CamelCased 格式的单数类型在清单文件中使用 kind: CronTab # CLI 中使用的资源简称 shortNames: - ct说明apiextensions.k8s.io/v1与旧版v1beta1的主要区别是改用 OpenAPI v3 校验 schema。创建 CRD 并验证端点kubectl create -f resourcedefinition.yaml # 访问 RESTful API 端点可见已创建的 API 路径 # /apis/stable.example.com/v1/namespaces/*/crontabs/...端点创建可能需要数秒可监控 CRD 的Established状态或查看 API 资源发现信息。创建自定义对象my-crontab.yamlapiVersion: stable.example.com/v1 kind: CronTab metadata: name: my-new-cron-object spec: cronSpec: * * * * */5 image: my-awesome-cron-imagekubectl create -f my-crontab.yaml kubectl get crontab kubectl get ct -o yaml # 资源名不区分大小写可用单数/复数/短名称删除 CRD 会删除 RESTful API 端点并级联删除其中存储的所有自定义对象重新创建同名 CRD 将从空开始。高级主题详见 CRD 教程Finalizer终结器允许控制器实现异步预删除 hook。带终结器的对象收到删除请求时仅设置metadata.deletionTimestamp不会立即删除控制器监控对象并轮询更新执行完所有终结器后资源才被删除。每个控制器负责从列表中删除自己的终结器。apiVersion: stable.example.com/v1 kind: CronTab metadata: finalizers: - finalizer.stable.example.comValidation验证通过 OpenAPI v3 schema 校验自定义对象Kubernetes v1.12 起 beta。可用--feature-gatesCustomResourceValidationfalse禁用。示例中spec.cronSpec必须是匹配正则的字符串、spec.replicas必须是 110 的整数非法值如cronSpec: * * * *、replicas: 15会被 API 拒绝并返回详细校验错误Additional Printer Columns从 Kubernetes 1.11 起 kubectl 使用服务器端打印可用additionalPrinterColumns自定义kubectl get输出列type支持 integer/number/string/boolean/datepriority决定标准视图或 wide 视图子资源自定义资源支持/status与/scale子资源Kubernetes v1.12 起 beta/scale需要定义specReplicasPath必需、statusReplicasPath必需与labelSelectorPath可选配合 HPA 使用启用后可执行kubectl scale --replicas5 crontabs/my-new-cron-objectCategory分类将自定义资源归入all等分组即可用kubectl get all一并列出。自定义控制器与 Operator单纯创建自定义资源没有太大价值只有与自定义控制器结合才能把声明式 API 翻译为用户期望的状态。自定义控制器可管理任何资源类型通常与自定义资源结合使用。本仓库 自定义资源 一节强调可以参考Operator 模式把开发者对领域的运维知识operational knowledge编码进特定的 Kubernetes API 扩展中。仓库提供了完整的开发路径Kubebuilder 与 Kubebuilder 示例、Operator SDK、Operator以及 client-go 实践示例 与 Informer 源码分析。仓库中还有基于 OpenKruise 的扩展示例OpenKruise 实践、CloneSet 清单与 OAM 体系的应用模型示例OAM、containerized-workload 清单可供参考。API 聚合Aggregated API ServerAggregated API Server旨在把原来的 API Server 这个巨石应用拆分让用户开发自己的 API Server 集成进来而无需直接修改官方代码便于使用实验特性。这些 API Server 可与 core API Server 无缝衔接用 kubectl 即可管理详见 Aggregated API Server 与 APIService。聚合架构引入kube-aggregator组件负责三件事提供用于注册 API Server 的 API汇总所有 API Server 信息代理所有客户端到 API Server 的请求。kube-aggregator有两种启用方式test mode / single-user mode作为独立进程运行与gateway modekube-apiserver嵌入kube-aggregator作为集群 gateway 聚合所有 apiserver。kube-aggregator二进制已包含在 Kubernetes release 中。相比 CRDAPI 聚合适合需要完整自定义行为如自定义校验逻辑、子资源语义、非 CRD 存储后端的场景。Service Catalog接入完整托管服务如果需要的不是单个资源而是完整的服务例如云厂商托管的消息队列、数据库Service Catalog为此提供了基于 Open Service Broker API 的规范。这些服务通过Service Broker注册由第三方AWS、GCP、Azure 等云厂商提供和维护。Service Catalog 通过扩展 API Server 和控制器实现使用 etcd 存储并借助 Kubernetes 1.7 的聚合层呈现其 API详见本仓库 服务目录Service Catalog 与 架构图。核心 API 资源servicecatalog.k8s.io API 组资源作用ClusterServiceBroker作为 service broker 的集群内代理封装其服务器连接信息由集群运营者创建ClusterServiceClass特定 service broker 提供的托管服务添加新 broker 时 controller 连接 broker 拉取清单并生成对应资源ClusterServicePlan托管服务的特定产品/套餐免费/付费、SSD 存储、资源配置差异等ServiceInstance一个已提供好的 ClusterServiceClass 实例由集群运营者创建ServiceBinding访问 ServiceInstance 的凭据创建后 controller 生成对应 Kubernetes Secret可挂载到 PodService Catalog 支持 Basicusername/password与 OAuth 2.0 Bearer Token 两种认证方式。使用流程四步列出托管服务清单与套餐——创建 ClusterServiceBrokerapiVersion: servicecatalog.k8s.io/v1beta1 kind: ClusterServiceBroker metadata: name: cloud-broker spec: # 指向 service broker 的端点 url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default随后可用 kubectl 查看可用服务与套餐kubectl get clusterserviceclasses -ocustom-columnsSERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName kubectl get clusterserviceplans -ocustom-columnsPLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName提供provision新实例——创建 ServiceInstanceapiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceInstance metadata: name: cloud-queue-instance namespace: cloud-apps spec: # 引用前面返回的服务 clusterServiceClassExternalName: cloud-provider-service clusterServicePlanExternalName: service-plan-name绑定bind到托管服务——创建 ServiceBinding 获取连接凭证apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceBinding metadata: name: cloud-queue-binding namespace: cloud-apps spec: instanceRef: name: cloud-queue-instance映射连接凭证到应用——绑定产生的 Secret 可通过声明式 Pod 配置挂载/注入spec: volumes: - name: provider-cloud-key secret: secretName: sa-key containers: volumeMounts: - name: provider-cloud-key mountPath: /var/secrets/provider env: - name: PROVIDER_APPLICATION_CREDENTIALS value: /var/secrets/provider/key.json - name: TOPIC valueFrom: secretKeyRef: name: provider-queue-credentials key: topic安装方式若没有集群管理员代为安装 Service Catalog可使用 Helm 或二进制安装器。前提包括 Kubernetes ≥ 1.7启用 API Aggregator、kubectl ≥ 1.7、集群内 DNS、Helm ≥ 2.7.0需为 Tiller 授予 cluster-admin、RBAC 已启用。典型安装命令helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com helm install svc-cat/catalog --name catalog --namespace catalog安装后可通过svcatCLI可单独使用或作为 kubectl 插件与 Service Catalog 交互。探索其他资源参考更多扩展点与客户端库Kubernetes 中的其他扩展点在哪里可以挂接到 Kubernetes 架构的概念性总览见 扩展Extension 与 开放接口Open Interfaces、聚合 API ServerKubernetes 客户端库用于构建需要与 Kubernetes API 大量交互的应用程序。本仓库的 client-go 示例 演示了如何用官方客户端操作资源client-go informer 源码分析 则深入剖析了 ListAndWatch 机制与 DeltaFIFO 等核心实现是编写自定义控制器前必读的源码级资料。下一步至此应用开发者之旅已经走完你了解了 Kubernetes 提供的大部分功能。如果想推荐新功能或跟进 Kubernetes 应用开发的最新进展可以参与 SIG 讨论参见本仓库 SIGs 与工作组 以及 贡献指南若想深入了解上述高级特性的完整中文讲解与可运行清单可继续阅读本仓库的 concepts、practice 与 usecases 三组文档。【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes 高级开发指南：容器级高级特性与 API 扩展的完整实践手册
Kubernetes 高级开发指南容器级高级特性与 API 扩展的完整实践手册【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook本文面向已经熟悉 Kubernetes 核心概念、能够独立部署应用的开发者系统讲解两类进阶能力一是使用高级功能部署应用Sidecar / Init 容器、Taint 与 Toleration、Downward API、PodPreset、HPA、联邦集群对象二是扩展 Kubernetes APICRD、API 聚合、自定义控制器、Service Catalog。读完本文你将掌握在不动核心代码的前提下按需定制 Kubernetes 行为、编写自定义资源与控制器、接入外部托管服务的方法并结合本仓库kubernetes-handbook的概念文档、Manifests 示例与源码分析章节获得可直接落地的实战方案。使用高级功能部署应用在掌握 DaemonSet 与 Deployment 等核心对象之后日常部署通常已经够用。但 Kubernetes 还提供了一系列鲜为人知却威力强大的高级功能它们在特定场景下能显著简化架构、提升弹性。下面按容器级功能、Pod 配置、其他 API 对象三个维度展开。容器级功能超越 1:1 的 Pod 模型把整个应用例如 Rails 应用、MySQL 数据库及其所有组件塞进单个 Pod 是一种反模式。但容器与 Pod 之间并非只能一一对应有两种非常有用的模式值得掌握Sidecar 容器Pod 中依然需要一个主容器main container同时你可以添加一个或多个副容器作为辅助这类副容器即Sidecar 容器。单个 Pod 中的多个容器共享网络命名空间并可通过共享卷进行通信。本仓库 Sidecar 模式 一节对该模式做了专门阐述将应用程序的功能拆分为独立进程、运行在同一个最小调度单元Pod中就可以在不动应用代码的前提下为其附加日志采集、监控、代理、配置同步等能力。Sidecar 与主应用松散耦合可屏蔽编程语言差异统一实现微服务的可观察性、监控、日志记录、配置、断路器等功能。使用 Sidecar 模式部署服务网格时无需在每个节点上运行代理而是为每个应用容器注入一个伴生 Sidecar 容器接管进出应用容器的所有流量。两个容器共享存储、网络等资源可以广义地把这个包含 Sidecar 容器的 Pod 理解为一台主机。其核心优势包括将与业务逻辑无关的功能抽象到公共基础设施降低微服务代码复杂度不再为每个服务重复编写第三方组件配置与代码降低代码重复度Sidecar 可独立升级降低应用代码与底层平台的耦合度。在 Service Mesh 实践中Sidecar 模式正是 Envoy 等数据面代理的部署基础可参见本仓库 理解 Istio Service Mesh 中的 Sidecar 注入与流量劫持 与 Sidecar 规范。Init 容器Init 容器是一种专用容器在 Pod 的应用容器主容器与 Sidecar 容器之前运行。本仓库 Init 容器 详细说明了它的两个核心特性Init 容器总是运行到成功完成为止每个 Init 容器都必须在前一个 Init 容器成功完成后才启动按顺序依次执行。如果 Init 容器失败Kubernetes 会不断重启该 Pod直到成功为止但如果 Pod 的restartPolicy为Never则不会重启。指定容器为 Init 容器只需在 PodSpec 中增加initContainers字段其状态在status.initContainerStatuses字段中返回。Init 容器的典型用途等待一个 Service 创建完成例如循环执行dig myservice直到 DNS 解析成功通过调用管理 API 将 Pod 注册到远程服务器在启动应用容器前延迟一段时间如sleep 60克隆 Git 仓库到共享数据卷运行模板工具如 Jinja用 POD_IP 等动态值生成主应用配置文件。以下 YAML 展示了一个带两个 Init 容器的 Pod第一个等待myservice启动第二个等待mydb启动两个 Service 就绪后应用容器才启动apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: [sh, -c, echo The app is running! sleep 3600] initContainers: - name: init-myservice image: busybox command: [sh, -c, until nslookup myservice; do echo waiting for myservice; sleep 2; done;] - name: init-mydb image: busybox command: [sh, -c, until nslookup mydb; do echo waiting for mydb; sleep 2; done;]版本兼容性说明Kubernetes 1.5 时代使用 annotationpod.beta.kubernetes.io/init-containers声明 Init 容器1.6 起支持spec.initContainers字段1.8 以后只支持新语法。API Server 版本为 1.6 或更高时均通过spec.initContainers支持 Init 容器。对应两个依赖 Service 的 YAMLkind: Service apiVersion: v1 metadata: name: myservice spec: ports: - protocol: TCP port: 80 targetPort: 9376 --- kind: Service apiVersion: v1 metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377启动与调试命令$ kubectl create -f myapp.yaml pod myapp-pod created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m $ kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器日志 $ kubectl logs myapp-pod -c init-mydb # 查看第二个 Init 容器日志启动myservice与mydb两个 Service 后Init 容器完成myapp-pod转为 Running$ kubectl create -f services.yaml service myservice created service mydb created $ kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9mInit 容器的具体行为要点在 Pod 启动过程中Init 容器按顺序在网络和数据卷初始化之后启动每个必须在下一个启动之前成功退出在所有 Init 容器成功之前Pod 不会变成Ready正在初始化中的 Pod 处于Pending状态但Initializing状态会被置为 true如果 Pod 重启所有 Init 容器必须重新执行对 Init 容器 spec 的修改被限制在image字段其他字段修改不生效因为可能被重启、重试或重新执行Init 容器的代码应当幂等尤其注意写入EmptyDir的代码要容忍输出文件已存在Init 容器支持应用容器的全部字段和特性资源限制、数据卷、安全设置唯一例外是不支持readinessProbe因为它必须在 Pod 就绪前运行完成Pod 上可使用activeDeadlineSeconds、容器上使用livenessProbe来避免 Init 容器无限失败Pod 中每个应用容器与 Init 容器的名称必须唯一。资源规则所有 Init 容器上定义的任一资源请求/限制的最大值是有效初始请求/限制Pod 对资源的有效请求/限制要高于所有应用容器请求/限制之和与有效初始请求/限制两者。调度基于有效请求/限制完成因此 Init 容器可以为初始化预留资源这些资源在 Pod 生命周期内不会被应用容器占用。配额、限制与 Pod 级 cgroups 均基于有效 Pod 请求/限制计算。Pod 配置元数据注入与调度约束通常使用Label 与 Annotation为资源附加元数据使用ConfigMap非机密数据或Secret机密数据向资源注入数据。除此之外还有几种不太为人所知的配置手段Taint污点与 Toleration容忍Taint 与 Toleration 用于优化 Pod 在集群间的调度与节点亲和性作用方向相反具有 taint 的节点与未容忍它的 Pod 是互斥关系而节点亲和性使 node 与 pod相吸。每个节点可应用一个或多个 taint不能容忍这些 taint 的 Pod 不会被该节点接受为 Pod 设置 toleration 后它可以但不要求被调度到具有相应 taint 的节点上。为 node1 设置 taintkubectl taint nodes node1 key1value1:NoSchedule kubectl taint nodes node1 key1value1:NoExecute kubectl taint nodes node1 key2value2:NoSchedule删除 taintkubectl taint nodes node1 key1:NoSchedule- kubectl taint nodes node1 key1:NoExecute- kubectl taint nodes node1 key2:NoSchedule-查看节点上的 taintkubectl describe nodes node1为 Pod 设置 toleration只需在 spec 中声明tolerations字段可包含多个 keytolerations: - key: key1 operator: Equal value: value1 effect: NoSchedule - key: key1 operator: Equal value: value1 effect: NoExecute - key: node.alpha.kubernetes.io/unreachable operator: Exists effect: NoExecute tolerationSeconds: 6000要点说明effect的值可以是NoSchedule、PreferNoSchedule或NoExecutetolerationSeconds是当 Pod 需要被驱逐时可以继续在节点上运行的时间秒当需要把应用调度到特定硬件例如科学计算用的 GPU时Taint/Toleration 是常用手段。Downward API向下 APIDownward API允许容器使用关于自己或集群的信息而无需过度耦合到 Kubernetes API Server。它有两种暴露方式环境变量将 Pod 的 name、namespace、Pod IP、node 名称等信息以环境变量注入容器DownwardAPIVolumeFile以文件形式挂载这些字段容器可动态读取。apiVersion: v1 kind: Pod metadata: name: downward-demo spec: containers: - name: main image: busybox env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIPPodPresetPod 预设通常要把环境变量、ConfigMap、Secret 等运行时需求注入资源需要在资源配置文件中逐个声明。PodPreset允许你在资源创建时动态注入这些需求例如团队 A 可以把任意数量的新 Secret 注入到团队 B、C 创建的资源中而无需 B、C 团队参与操作。本仓库 Pod Preset 一节说明PodPreset 通过label selector指定作用于哪些 Pod从而让 Pod 模板作者不必为每个 Pod 明确提供全部信息。工作原理准入控制器Kubernetes 提供了PodPreset准入控制器Pod 创建请求到达时执行以下流程检索所有可用的 PodPresets检查 PodPreset 标签选择器是否匹配正在创建的 Pod 上的标签尝试将 PodPreset 定义的各种资源合并到正在创建的 Pod 中出现错误时在该 Pod 上引发记录合并错误的事件PodPreset不会注入任何资源为修改后的 Pod spec 添加注解podpreset.admission.kubernetes.io/podpreset-pod-preset name: resource version。每个 Pod 可匹配零个或多个 PodPreset每个 PodPreset 可应用于零个或多个 Pod。对于Env、EnvFrom和VolumeMounts的修改作用于 Pod 中所有容器的容器 spec对于Volume的修改作用于 Pod Spec。注意PodPreset 中的资源定义不会应用于initContainers字段。如果希望某个 Pod 不被任何 PodPreset 修改可在其 spec 中添加注解annotations: podpreset.admission.kubernetes.io/exclude: true启用 PodPreset 需要满足三个条件启用settings.k8s.io/v1alpha1/podpresetAPI 类型——在 API Server 的--runtime-config中包含settings.k8s.io/v1alpha1true启用PodPreset准入控制器——将其加入 API Server 的--admission-control选项在目标命名空间中创建PodPreset对象。注意PodPreset 资源对象自 Kubernetes 1.8 以上版本才支持。其他 API 对象HPA 与联邦集群对象以下资源在创建前请先确认是否属于集群管理员cluster admin的职责范围。Horizontal Pod AutoscalerHPA应用资源使用率通常有高峰低谷。HPAHorizontal Pod Autoscaler让 Service 中的 Pod 数量根据 CPU 利用率或其他自定义度量标准自动伸缩是 Kubernetes 自动化运维能力的集中体现。HPA 属于 autoscaling SIG 的范畴自 Kubernetes 1.2 引入1.6 之前通过 kubelet 获取监控指标1.6 之后必须通过 API Server、Heapster 或 kube-aggregator 获取监控指标。Metrics 支持按 API 版本autoscaling/v1仅支持 CPUautoscaling/v1alpha1支持内存、自定义 metricsKubernetes 1.6 起需在 kube-controller-manager 中配置--horizontal-pod-autoscaler-use-rest-clientstrue并让--api-server指向 kube-aggregator 或启用--api-servertrue的 heapster、以及多种 metrics 组合HPA 根据每个 metric 分别计算 scale 值取最大者作为扩容结果。HPA 只适用于 Deployment 和 ReplicaSet。与普通资源一样可通过 kubectl 管理资源名hpakubectl create hpa kubectl get hpa kubectl describe hpa kubectl delete hpa也可直接用kubectl autoscale一行命令创建kubectl autoscale deployment foo --min2 --max5 --cpu-percent80上述命令为 Deployment foo 创建 autoscaler当 Pod 的 CPU 利用率达到 80% 时副本数在 25 之间伸缩。工作原理HPA 由一个控制循环实现周期由 controller manager 的--horizontal-pod-autoscaler-sync-period标志指定默认 30 秒。每个周期内controller manager 查询 HPA 定义的 metric 利用率对每个 Pod 的 resource metric如 CPU从 resource metric API 获取每个 Pod 的指标结合容器 resource request 计算利用率或使用原始值再对所有目标 Pod 求平均得出所需副本数的比率对每个 Pod 的自定义 metric类似上述逻辑但直接使用原始值对object metric获取描述对象本身的单一度量与目标值比较得出比率。HPA 控制器可通过两种方式获取 metric直接访问 Heapster通过 API Server 的服务代理子资源需在 kube-system 命名空间部署 Heapster或使用 REST 客户端。最终通过 Scale 子资源/scale调整副本数。注意不能把 HPA 绑定到裸 ReplicationController 做滚动更新滚动更新创建新 RC 后 HPA 不会绑定到新 RC应绑定到 Deployment由 Deployment 管理底层 RC 的滚动更新。自定义 metric 前提条件在 controller manager 中设置--horizontal-pod-autoscaler-use-rest-clientstrue将--apiserver指向 API server aggregatorresource metric API 与自定义 metric API 必须向 aggregator 注册并由集群内 API Server 提供。Heapster 可通过--api-servertrue实现 resource metric API自定义 metric API 需独立组件提供。本仓库在 Horizontal Pod Autoscaling 与 Custom Metrics HPA 中有完整讲解并提供了可直接使用的清单示例HPA 配置、自定义 metrics 示例、示例应用。联邦集群对象Federation如果使用Federation在多个 Kubernetes 集群上运行应用程序则需要部署标准 Kubernetes API 对象的联合版本。本仓库 联邦Federation 与 多集群Multicluster 章节介绍了跨集群部署与管理思路可结合 联邦概念图 理解控制平面如何编排多个成员集群的 Deployment、Service 等对象。扩展 Kubernetes APIKubernetes 在设计之初就考虑了可扩展性。如果内置 API 资源与功能不够用可以在不修改核心 Kubernetes 代码的前提下自定义其行为。理解 Kubernetes 的默认行为做任何自定义之前先理解所有 API 对象背后的一般抽象。虽然 Deployment 与 Secret 看起来完全不同但对任何对象而言以下概念都成立Kubernetes 对象是存储集群结构化数据的一种方式Deployment 的数据代表期望状态如应该运行多少副本Secret 则是通用元数据如数据库凭证Kubernetes 对象通过 Kubernetes API 修改可以对特定资源路径如api-server-url/api/v1/namespaces/default/deployments执行GET、POST请求来读取或修改对应对象类型利用 Controller 模式对象可被确保达到期望状态Controller 模式可以看作一个连续循环——(1) 检查当前状态副本数、容器镜像等(2) 对比当前状态与期望状态(3) 若不匹配则更新当前状态。状态均通过 Kubernetes API 获取。并非所有对象都需要 ControllerDeployment 会触发集群状态变更而 ConfigMap 纯粹作为存储。创建自定义资源基于上述抽象你可以定义与 Deployment 一样合法的自定义资源。例如如果内置CronJob不能满足需求你可以定义Backup对象来做定期备份。创建自定义资源有两条路径自定义资源定义CRDCustomResourceDefinition工作量最小的实现方式API 聚合Aggregation需要先配置聚合层再运行独立的扩展 API Server。注意与依赖内置kube-controller-manager不同你需要自己编写并运行自定义控制器。选择方法时请考虑如何判断自定义资源是否适合你的场景 以及 CRD 与 API 聚合的取舍详见 使用自定义资源扩展 API。CRD最小工作量的扩展方式创建新的 CRD 时Kubernetes API Server 会为每个指定版本创建新的 RESTful 资源路径。CRD 可以是命名空间的也可以是集群范围的由scope字段指定CRD 本身是非命名空间的可供所有命名空间使用。本仓库 使用 CRD 扩展 Kubernetes API 提供了完整教程下面给出一个经典示例resourcedefinition.yamlapiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: # 名称必须符合格式plural.group name: crontabs.stable.example.com spec: # REST API 使用的组名称/apis/group/version group: stable.example.com versions: - name: v1 # 通过 served 开关每个 version served: true # 有且仅有一个 version 开启存储 storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer # Namespaced 或 Cluster scope: Namespaced names: # URL 中使用的复数名称/apis/group/version/plural plural: crontabs # CLI 中使用的单数名称 singular: crontab # CamelCased 格式的单数类型在清单文件中使用 kind: CronTab # CLI 中使用的资源简称 shortNames: - ct说明apiextensions.k8s.io/v1与旧版v1beta1的主要区别是改用 OpenAPI v3 校验 schema。创建 CRD 并验证端点kubectl create -f resourcedefinition.yaml # 访问 RESTful API 端点可见已创建的 API 路径 # /apis/stable.example.com/v1/namespaces/*/crontabs/...端点创建可能需要数秒可监控 CRD 的Established状态或查看 API 资源发现信息。创建自定义对象my-crontab.yamlapiVersion: stable.example.com/v1 kind: CronTab metadata: name: my-new-cron-object spec: cronSpec: * * * * */5 image: my-awesome-cron-imagekubectl create -f my-crontab.yaml kubectl get crontab kubectl get ct -o yaml # 资源名不区分大小写可用单数/复数/短名称删除 CRD 会删除 RESTful API 端点并级联删除其中存储的所有自定义对象重新创建同名 CRD 将从空开始。高级主题详见 CRD 教程Finalizer终结器允许控制器实现异步预删除 hook。带终结器的对象收到删除请求时仅设置metadata.deletionTimestamp不会立即删除控制器监控对象并轮询更新执行完所有终结器后资源才被删除。每个控制器负责从列表中删除自己的终结器。apiVersion: stable.example.com/v1 kind: CronTab metadata: finalizers: - finalizer.stable.example.comValidation验证通过 OpenAPI v3 schema 校验自定义对象Kubernetes v1.12 起 beta。可用--feature-gatesCustomResourceValidationfalse禁用。示例中spec.cronSpec必须是匹配正则的字符串、spec.replicas必须是 110 的整数非法值如cronSpec: * * * *、replicas: 15会被 API 拒绝并返回详细校验错误Additional Printer Columns从 Kubernetes 1.11 起 kubectl 使用服务器端打印可用additionalPrinterColumns自定义kubectl get输出列type支持 integer/number/string/boolean/datepriority决定标准视图或 wide 视图子资源自定义资源支持/status与/scale子资源Kubernetes v1.12 起 beta/scale需要定义specReplicasPath必需、statusReplicasPath必需与labelSelectorPath可选配合 HPA 使用启用后可执行kubectl scale --replicas5 crontabs/my-new-cron-objectCategory分类将自定义资源归入all等分组即可用kubectl get all一并列出。自定义控制器与 Operator单纯创建自定义资源没有太大价值只有与自定义控制器结合才能把声明式 API 翻译为用户期望的状态。自定义控制器可管理任何资源类型通常与自定义资源结合使用。本仓库 自定义资源 一节强调可以参考Operator 模式把开发者对领域的运维知识operational knowledge编码进特定的 Kubernetes API 扩展中。仓库提供了完整的开发路径Kubebuilder 与 Kubebuilder 示例、Operator SDK、Operator以及 client-go 实践示例 与 Informer 源码分析。仓库中还有基于 OpenKruise 的扩展示例OpenKruise 实践、CloneSet 清单与 OAM 体系的应用模型示例OAM、containerized-workload 清单可供参考。API 聚合Aggregated API ServerAggregated API Server旨在把原来的 API Server 这个巨石应用拆分让用户开发自己的 API Server 集成进来而无需直接修改官方代码便于使用实验特性。这些 API Server 可与 core API Server 无缝衔接用 kubectl 即可管理详见 Aggregated API Server 与 APIService。聚合架构引入kube-aggregator组件负责三件事提供用于注册 API Server 的 API汇总所有 API Server 信息代理所有客户端到 API Server 的请求。kube-aggregator有两种启用方式test mode / single-user mode作为独立进程运行与gateway modekube-apiserver嵌入kube-aggregator作为集群 gateway 聚合所有 apiserver。kube-aggregator二进制已包含在 Kubernetes release 中。相比 CRDAPI 聚合适合需要完整自定义行为如自定义校验逻辑、子资源语义、非 CRD 存储后端的场景。Service Catalog接入完整托管服务如果需要的不是单个资源而是完整的服务例如云厂商托管的消息队列、数据库Service Catalog为此提供了基于 Open Service Broker API 的规范。这些服务通过Service Broker注册由第三方AWS、GCP、Azure 等云厂商提供和维护。Service Catalog 通过扩展 API Server 和控制器实现使用 etcd 存储并借助 Kubernetes 1.7 的聚合层呈现其 API详见本仓库 服务目录Service Catalog 与 架构图。核心 API 资源servicecatalog.k8s.io API 组资源作用ClusterServiceBroker作为 service broker 的集群内代理封装其服务器连接信息由集群运营者创建ClusterServiceClass特定 service broker 提供的托管服务添加新 broker 时 controller 连接 broker 拉取清单并生成对应资源ClusterServicePlan托管服务的特定产品/套餐免费/付费、SSD 存储、资源配置差异等ServiceInstance一个已提供好的 ClusterServiceClass 实例由集群运营者创建ServiceBinding访问 ServiceInstance 的凭据创建后 controller 生成对应 Kubernetes Secret可挂载到 PodService Catalog 支持 Basicusername/password与 OAuth 2.0 Bearer Token 两种认证方式。使用流程四步列出托管服务清单与套餐——创建 ClusterServiceBrokerapiVersion: servicecatalog.k8s.io/v1beta1 kind: ClusterServiceBroker metadata: name: cloud-broker spec: # 指向 service broker 的端点 url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default随后可用 kubectl 查看可用服务与套餐kubectl get clusterserviceclasses -ocustom-columnsSERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName kubectl get clusterserviceplans -ocustom-columnsPLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName提供provision新实例——创建 ServiceInstanceapiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceInstance metadata: name: cloud-queue-instance namespace: cloud-apps spec: # 引用前面返回的服务 clusterServiceClassExternalName: cloud-provider-service clusterServicePlanExternalName: service-plan-name绑定bind到托管服务——创建 ServiceBinding 获取连接凭证apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceBinding metadata: name: cloud-queue-binding namespace: cloud-apps spec: instanceRef: name: cloud-queue-instance映射连接凭证到应用——绑定产生的 Secret 可通过声明式 Pod 配置挂载/注入spec: volumes: - name: provider-cloud-key secret: secretName: sa-key containers: volumeMounts: - name: provider-cloud-key mountPath: /var/secrets/provider env: - name: PROVIDER_APPLICATION_CREDENTIALS value: /var/secrets/provider/key.json - name: TOPIC valueFrom: secretKeyRef: name: provider-queue-credentials key: topic安装方式若没有集群管理员代为安装 Service Catalog可使用 Helm 或二进制安装器。前提包括 Kubernetes ≥ 1.7启用 API Aggregator、kubectl ≥ 1.7、集群内 DNS、Helm ≥ 2.7.0需为 Tiller 授予 cluster-admin、RBAC 已启用。典型安装命令helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com helm install svc-cat/catalog --name catalog --namespace catalog安装后可通过svcatCLI可单独使用或作为 kubectl 插件与 Service Catalog 交互。探索其他资源参考更多扩展点与客户端库Kubernetes 中的其他扩展点在哪里可以挂接到 Kubernetes 架构的概念性总览见 扩展Extension 与 开放接口Open Interfaces、聚合 API ServerKubernetes 客户端库用于构建需要与 Kubernetes API 大量交互的应用程序。本仓库的 client-go 示例 演示了如何用官方客户端操作资源client-go informer 源码分析 则深入剖析了 ListAndWatch 机制与 DeltaFIFO 等核心实现是编写自定义控制器前必读的源码级资料。下一步至此应用开发者之旅已经走完你了解了 Kubernetes 提供的大部分功能。如果想推荐新功能或跟进 Kubernetes 应用开发的最新进展可以参与 SIG 讨论参见本仓库 SIGs 与工作组 以及 贡献指南若想深入了解上述高级特性的完整中文讲解与可运行清单可继续阅读本仓库的 concepts、practice 与 usecases 三组文档。【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址: https://gitcode.com/gh_mirrors/ku/kubernetes-handbook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考