原文：https://kubernetes.io/docs/concepts/extend-kubernetes/extend-cluster/
Kubernetes高高度可配置可扩展的平台，因此，很少有必要向kubernetes项目提交补丁类的代码。
本文描述kubernetes集群自定义，帮助集群管理员理解如何自定义、调整集群以满足实际工作环境需求。同时也有助于平台开发者、kubernetes项目贡献者了解存在那些扩展点、模式，它们的优缺、限制等。
综述
集群自定义的方法宽泛的分为配置、扩展两种方法。配置只涉及修改标志、本地配置文件、API资源。扩展的话，则需要运行额外的程序或者service。本文主要关于扩展。
配置
配置主要涉及以下四个组件，具体可参考链接指向的在线文档：
关于配置，有如下问题。首先就是权限问题，在某些部署环境下，使用者不被允许修改标志、配置文件等，只允许使用安装完成以后确定的配置项，如果变更的话可能会产生错误。再有就是有些配置项在kubernetes将来的版本中很有可能发生变更，这样的话在版本升级的时候就会出现问题，用户修改过的旧配置将无法使用。最后就是有些配置变更生效的话需要重新启动程序。综合以上原因，除非别无它选，否则尽量不要改变安装完成以后确定下来的配置。总之一句，在安装部署的时候确定配置，以后最好不要修改配置。
ResourceQuota, PodSecurityPolicies, NetworkPolicy and Role-based Access Control (RBAC)这些东西，也是先声明然后创建，语法惯例与pod等资源相同。不一样的地方是pod最终会被系统创建实例，但以上这几个资源不会，它们属于配置性性、约束类对象，只在创建对象的过程中动态的发生作用，并不会被创建实实例。用户可以像使用普通对象一样放心大胆的使用这些对象，不存在上文中说的配置项存在的问题。
扩展
扩展是与kubernetes深度集成的软件组件，主是用来适配不同的低层硬件。大多数时候用户只需安装无需已经存的在扩展，而不用新开发。
通过编写调用kubernetes api的客户端，来读取、控制对象，被称之为控制器模式，主要用来实现一些自动化操作，当然编写客户端时要遵守特定的规范。按照本文介绍的方法可以编写出高可用、强壮的客户端
另外一种是kubernetes本身是某种远程服务的客户端，这种模式称为Webhook模式，远程的服务器称为Webhook Backend。kubernetes的组件，主要是kubelet、kubectl等调用指定的二进制插件向远程的Webhook Backend发起请求，从而实现交互。
扩展点
- Kubectl扩展
- apiserver扩展
- 自定义资源类型
- Kubernetes scheduler扩展
- Kubernetes控制管理扩展
- Pod网络扩展，kubelet通过扩展网络为pod分配网络资源
- 存储扩展， kubelet将扩展的存储资源分配给pod
API扩展
用户自定义类型
如果用户定义新的资源类型，那么也需要定义管理、控制、访问这种新类型资源的API。
自定义API与控制循环的结合
如果新自定义了资源类型与访问管理控制资源的API，那么也需要修改控制面的控制循环以管理控制新资源类型。
修改内置资源类型
如果新自定义了资源类型，与访问管理控制资源的API，新加入的API属于一个新的组，用户不可以修改替换系统内置的API，不可以改变内置API的行为。
API访问控制扩展
apiserver处理请求时，先是认证、然后是鉴权、再然后是各种各样的入口控制器。每步都是一个扩展点，都可以扩展。
基础设施扩展
- Storage Plugins
- Device Plugins
- Network Plugins
- Scheduler Extensions