kubernetes 扩展：扩展点和方法（api/cr/plugin...）
目录
说明
kubernetes 用的越多，定制的需求越强，作为基础设施存在的 kubernetes 有强大的扩展能力，能够应对各种各样的场景。这里梳理一下 kubernetes 支持的扩展点和扩展方法。
主要参考资料：
扩展点
kubernetes 的扩展点现在（2019-12-15 18:30:28）有以下几个：
- kubectl plugins：主要影响本地操作体验，非核心功能
- Authentication/Authorization/Admission Control：请求处理过程扩展，Admission Control 是重点
- Custom Resources：API 扩展，CRD 方式，扩展 kubernetes 的资源种类，和 Operator 配合使用
- Apiserver-aggregation：API 扩展，一种区别于 CRD 的方式
- Scheduler Extensions：调度器扩展
- CNI/CSI/CRI：kubelet 扩展，分别是网络插件、存储插件、运行虚拟化插件
Authen
支持对接 Webhook，交互的数据格式见 Authentication Webhook。设置方法：
--authentication-token-webhook-config-file=CONFIG_FILENAME # webhook 配置文件
--authentication-token-webhook-cache-ttl # 结果缓存时间，默认 2min
认证的 webhook 地址在配置文件中指定，格式如下，clusters 是 webhook 地址：
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
- name: name-of-remote-authn-service
cluster:
certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
client-key: /path/to/key.pem # key matching the cert
# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authn-service
user: name-of-api-sever
name: webhook
Authz
支持对接 Webhook，交互的数据格式见Authorization Webhook。设置方法：
--authorization-webhook-config-file=CONFIG_FILENAME
授权的 webhook 地址在配置文件中指定，格式如下，clusters 是 webhook 地址：
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
- name: name-of-remote-authz-service
cluster:
# CA for verifying the remote service.
certificate-authority: /path/to/ca.pem
# URL of remote service to query. Must use 'https'. May not include parameters.
server: https://authz.example.com/authorize
# users refers to the API Server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
client-key: /path/to/key.pem # key matching the cert
# kubeconfig files require a context. Provide one for the API Server.
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authz-service
user: name-of-api-server
name: webhook
Admission Control
Admission Control 的作用位置在认证和授权之后，用下面的方式启用：
1.10版本之后：--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,...
1.9 版本之前：--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,...
Admission Control 的数量非常多（十几个），个别 Admission Control 还会用到比较复杂的配置文件，有的 Admission Control 会修改用户提交的数据。
AlwaysPullImages： 强制将 image pull policy 设置为 Always
DefaultStorageClass: 为没有指定 StorageClass 的 PVC 设置默认的 StorageClass
DefaultTolerationSeconds: node 被设置 NoExecute Taint 后，pod 的容忍时间，超过后被驱逐
EventRateLimit: 事件限速
ExtendedResourceToleration: 自动为带有 extended resources（GPU/FPGA等）的 node 设置 taint
ImagePolicyWebhook: 镜像访问控制的 webhook
LimitPodHardAntiAffinityTopology： 反亲和性
LimitRanger: 为没有设置 cpu/memory 的 pod 设置默认数量
NamespaceAutoProvision: 自动创建 namespace
NamespaceExists: 检查 namespace 是否存在
NamespaceLifecycle： namespace 删除期间，不接受相关请求
NodeRestriction： 限制 kubelet 可以对 node 和 pod 做出的修改
OwnerReferencesPermissionEnforcement： 限制对 metadata.ownerReferences 的访问
PodNodeSelector: 设置 namespace 的中的 pod 的选择 node 的条件
PersistentVolumeClaimResize: pvc 扩容检查
PodPreset： 自动在 Pod 创建时注入信息
PodSecurityPolicy: Pod 操作的细粒度权限控制
PodTolerationRestriction: 检查合并 Pod 和 Namespace 的 Toleration，并与 namespace 的 Toleration 白名单比对
Priority: Pod 的优先级设置 priorityClassName
ResourceQuota: 资源配额检查
RuntimeClass: 自动为 Pod 设置 pod.Spec.Overhead（额外开销）
SecurityContextDeny: 禁止 SecurityContext 权限提升
ServiceAccount: ServiceAccount 设置
StorageObjectInUseProtection: 为 PV 和 PVC 设置 Finalizers，防止正在使用时被删除，从而造成数据丢失
TaintNodesByCondition： 为新建的 Node 设置 NotReady 和 NoSchedule taint。
MutatingAdmissionWebhook: 顺序调用会修改 object 的 webhook
ValidatingAdmissionWebhook: 并发调用检验 object 的 webhook
Apiserver Aggregation
apiserver-aggregation 是一种扩展 kubernetes API 的方法。kubernetes 有一个 API 是 APIService：
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
name: <name of the registration object>
spec:
group: <API group name this extension apiserver hosts>
version: <API version this extension apiserver hosts>
groupPriorityMinimum: <priority this APIService for this group, see API documentation>
versionPriority: <prioritizes ordering of this version within a group, see API documentation>
service:
namespace: <namespace of the extension apiserver service>
name: <name of the extension apiserver service>
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
APIService 定义的是请求的转发规则，kube-apiserver 把收到的匹配了 group 和 version 请求转发给 servcie 处理。 service 就是单独开发的专门处理这些扩展的 API 的服务。
CRD 和 Operator
kubernetes 提供了 Custom Resources 功能，允许增加自定义的 Resource。为自定义的 Resource 开发的 controller 是 operator。kubernetes 提供了一系列工具简化 operator 的开发，譬如自动为 crd 生成相应的 informer 等等。
CRD 使用见: kubernetes api 扩展：CRD 方式（用户自定义资源）
Scheduler Extensions
kube-scheduler 是 kubernetes 提供的默认调度器，一般情况下，直接使用默认调度器就足够了。如果有需要可以自行开发调度器，可以同时用多个调度器分别调度不同的资源。
同时启动多个调度器的方法见：Multiple Scheduler
kube-scheduler 的 webhook：Scheduler extender
kube-scheduler 的调度策略可以通过配置文件调整：调度策略的调整方法
Kubelet
kubelet 扩展主要是各种本地插件：
参考
