Kubernetes指南
Linux性能优化实战eBPF 核心技术与实战SDN指南个人博客
中文
中文
  • 序言
  • 基础入门
    • Kubernetes 简介
    • Kubernetes 基本概念
    • Kubernetes 101
    • Kubernetes 201
    • Kubernetes 集群
  • 核心原理
    • 核心原理
    • 架构原理
    • 设计理念
    • 核心组件
      • etcd
      • kube-apiserver
      • kube-scheduler
      • kube-controller-manager
      • kubelet
      • kube-proxy
      • kube-dns
      • Federation
      • kubeadm
      • hyperkube
      • kubectl
    • 资源对象
      • Autoscaling
      • ConfigMap
      • CronJob
      • CustomResourceDefinition
      • DaemonSet
      • Deployment
      • Ingress
      • Job
      • LocalVolume
      • Namespace
      • NetworkPolicy
      • Node
      • PersistentVolume
      • Pod
      • PodPreset
      • ReplicaSet
      • Resource Quota
      • Secret
      • SecurityContext
      • Service
      • ServiceAccount
      • StatefulSet
      • Volume
  • 部署配置
    • 部署指南
    • kubectl 安装
    • 单机部署
    • 特性开关
    • 最佳配置
    • 版本支持
    • 集群部署
      • kubeadm
      • kops
      • Kubespray
      • Azure
      • Windows
      • LinuxKit
      • kubeasz
    • 附加组件
      • Addon-manager
      • DNS
      • Dashboard
      • 监控
      • 日志
      • Metrics
      • GPU
      • Cluster Autoscaler
      • ip-masq-agent
    • Kubernetes-The-Hard-Way
      • 准备部署环境
      • 安装必要工具
      • 创建计算资源
      • 配置创建证书
      • 配置生成配置
      • 配置生成密钥
      • 部署 Etcd 群集
      • 部署控制节点
      • 部署计算节点
      • 配置 Kubectl
      • 配置网络路由
      • 部署 DNS 扩展
      • 烟雾测试
      • 删除集群
  • 插件扩展
    • API 扩展
      • Aggregation
      • CustomResourceDefinition
    • 访问控制
      • 认证
      • RBAC 授权
      • 准入控制
    • Scheduler 扩展
    • 网络插件
      • CNI
      • Flannel
      • Calico
      • Weave
      • Cilium
      • OVN
      • Contiv
      • SR-IOV
      • Romana
      • OpenContrail
      • Kuryr
    • 运行时插件 CRI
      • CRI-tools
      • Frakti
    • 存储插件
      • 容器存储接口 CSI
      • FlexVolume
      • glusterfs
    • 网络策略
    • Ingress Controller
      • Ingress + Letsencrypt
      • minikube Ingress
      • Traefik Ingress
      • Keepalived-VIP
    • Cloud Provider 扩展
    • Device 插件
  • 服务治理
    • 服务治理
      • 一般准则
      • 滚动升级
      • Helm
      • Operator
      • Service Mesh
      • Linkerd
      • Linkerd2
    • Istio
      • 安装
      • 流量管理
      • 安全管理
      • 策略管理
      • 度量管理
      • 排错
      • 社区
    • Devops
      • Draft
      • Jenkins X
      • Spinnaker
      • Kompose
      • Skaffold
      • Argo
      • Flux GitOps
  • 实践案例
    • 实践概览
    • 资源控制
    • 集群高可用
    • 应用高可用
    • 调试
    • 端口映射
    • 端口转发
    • 用户管理
    • GPU
    • HugePage
    • 安全
    • 审计
    • 备份恢复
    • 证书轮换
    • 大规模集群
    • 大数据与机器学习
      • Spark
      • Tensorflow
    • Serverless
  • 排错指南
    • 排错概览
    • 集群排错
    • Pod 排错
    • 网络排错
    • PV 排错
      • AzureDisk
      • AzureFile
    • Windows 排错
    • 云平台排错
      • Azure
    • 排错工具
  • 社区贡献
    • 开发指南
    • 单元测试和集成测试
    • 社区贡献
  • 附录
    • 生态圈
    • 学习资源
    • 国内镜像
    • 如何贡献
    • 参考文档
由 GitBook 提供支持
在本页
  1. 插件扩展

API 扩展

上一页删除集群下一页Aggregation

最后更新于2年前

Kubernetes 的架构非常灵活,提供了从 API、认证授权、准入控制、网络、存储、运行时以及云平台等一系列的,方便用户无侵入的扩展集群的功能。

从 API 的角度来说,可以通过 Aggregation 和 CustomResourceDefinition(CRD) 等扩展 Kubernetes API。

  • API Aggregation 允许在不修改 Kubernetes 核心代码的同时将第三方服务注册到 Kubernetes API 中,这样就可以通过 Kubernetes API 来访问外部服务。

  • CustomResourceDefinition 则可以在集群中新增资源对象,并可以与已有资源对象(如 Pod、Deployment 等)相同的方式来管理它们。

CRD 相比 Aggregation 更易用,两者对比如下

CRDs
Aggregated API

无需编程即可使用 CRD 管理资源

需要使用 Go 来构建 Aggregated APIserver

不需要运行额外服务,但一般需要一个 CRD 控制器同步和管理这些资源

需要独立的第三方服务

任何缺陷都会在 Kubernetes 核心中修复

可能需要定期从 Kubernetes 社区同步缺陷修复方法并重新构建 Aggregated APIserver.

无需额外管理版本

需要第三方服务来管理版本

更多的特性对比

Feature
Description
CRDs
Aggregated API

Validation

Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can’t all update at the same time.

Yes, arbitrary validation checks

Defaulting

See above

Yes, via a Mutating Webhook; Planned, via CRD OpenAPI schema.

Yes

Multi-versioning

Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions.

No, but planned

Yes

Custom Storage

If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different

No

Yes

Custom Business Logic

Perform arbitrary checks or actions when creating, reading, updating or deleting an object

Yes, using Webhooks.

Yes

Scale Subresource

Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource

Yes

Status Subresource

Finer-grained access control: user writes spec section, controller writes status section.Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)

Yes

Other Subresources

Add operations other than CRUD, such as “logs” or “exec”.

No

Yes

strategic-merge-patch

No, but similar functionality planned

Yes

Protocol Buffers

The new resource supports clients that want to use Protocol Buffers

No

Yes

OpenAPI Schema

Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don’t put an int in a string field?)

No, but planned

Yes

使用方法

详细的使用方法请参考

Yes. Most validation can be specified in the CRD using . Any other validations supported by addition of a Validating Webhook.

The new endpoints support PATCH with Content-Type: application/strategic-merge-patch+json. Useful for updating objects that may be modified both locally, and by the server. For more information, see

扩展机制
Aggregation
CustomResourceDefinition
OpenAPI v3.0 validation
Yes
Yes
“Update API Objects in Place Using kubectl patch”