kubernetes高级之动态准入控制

系列目录html

动态准入控制器文档介绍了如何使用标准的,插件式的准入控制器.可是,可是因为如下缘由,插件式的准入控制器在一些场景下并不灵活:前端

  • 它们须要编译到kube-apiserver里git

  • 它们仅在apiserver启动的时候能够配置github

准入钩子(Admission Webhooks 从1.9版本开始)解决了这些问题,它容许准入控制器独立于核心代码编译而且能够在运行时配置.web

什么是准入钩子

准入钩子是一种http回调,它接收准入请求而后作一些处理.你能够定义两种类型的准入钩子:验证钩子变换钩子.对于验证钩子,你能够拒绝请求以使自定义准入策略生效.对于变换钩子,你能够改变请求来使自定义的默认配置生效.api

体验准入钩子

准入控制钩子是集群管制面板不可缺乏的一部分.你在编写部署它们时必需要警戒.若是你想要编写/布置生产级别的准入控制器,请阅读如下用户指南.下面咱们将介绍如何快速体验准入钩子.服务器

准备工做:app

  • 确保你的kubernetes集群版本至少是1.9版本.测试

  • 确保变换钩子(MutatingAdmissionWebhook) 和验证钩子(ValidatingAdmissionWebhook)已经启用.这里是推荐开启的一组准入控制器.this

编写一个准入钩子服务器(admission webhook server)

请参阅已经被kubernetes e2e测试验证经过的准入服务器钩子( admission webhook server)的实现.这个web钩子处理apiserver发出的admissionReview请求,而后把结果封装成一个admissionResponse返回给请求者.

admissionReview请求可能有多个版本( v1beta1 或者 将来的v1),web钩子能够经过admissionReviewVersions字段来定义它们接受的版本.apiserver会尝试使用列表中出现的,支持的第一个版本.若是列表中的版本没有一个是被支持的,验证将失败.若是webhook配置已经持久化,对web钩子的请求将会失败并被失败策略控制.

示例钩子服务器(admission webhook server)把ClientAuth字段留空,默认为NoClientCert.这意味着钩子服务器不验证客户端身份.若是你须要使用mutual TLS或者其它方法来验证客户端请求,请参考如何认证apiserver

部署准入控制服务

e2e测试的钩子服务器经过部署api(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#deployment-v1beta1-apps)被部署到kubernetes集群中.测试项目也为钩子服务器建立了一个前端服务,代码

你也能够把你的钩子服务部署到集群外,你须要相应地更新web钩子客户端配置

运行时配置准入web钩子

你能够经过ValidatingWebhookConfigurationMutatingWebhookConfiguration动态地配置哪些资源被哪些web钩子控制.

如下是一个validatingWebhookConfiguration配置的示例,变换钩子的配置也相似

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  name: <name of this configuration object>
webhooks:
- name: <webhook name, e.g., pod-policy.example.io>
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: "Namespaced"
  clientConfig:
    service:
      namespace: <namespace of the front-end service>
      name: <name of the front-end service>
    caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
  admissionReviewVersions:
  - v1beta1
  timeoutSeconds: 1

scope字段指定了集群级别的资源("Cluster")或者名称空间级别的资源("Namespaced")须要匹配这些规则."*"表示没有任何范围限制.

注意,若是使用clientConfig.service,服务端证书必须对<svc_name>.<svc_namespace>.svc有效.

web钩子请求默认超时时间为30秒,可是从1.14版本开始,你能够自由设置超时时间可是建议设置较小的时间.若是web钩子请求超时,请求将被web钩子的失败策略处理.

当apiserver接收到一个匹配规则的请求,apiserver将会发送一个admissionReview请求到clientConfig配置的web钩子里.

建立web钩子配置之后,系统将会通过一段时间使新配置生效.

认证apiserver

若是你的准入web钩子须要认证,你能够配置apiserver使用基本认证(basic auth), bearer token 或者证书认证.须要三个步骤来完成认证配置.

  • 当启动apiserver时,经过--admission-control-config-file选项来指定准入控制配置文件的位置.

  • 在准入控制配置文件里,指定变换控制器(MutatingAdmissionWebhook)和验证控制器(ValidatingAdmissionWebhook)从哪里读取证书.证书存储在kubeConfig文件里(和kubectl使用的相同),字段名为kubeConfigFile.下面是准入控制配置文件示例

apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: <path-to-kubeconfig-file>
- name: MutatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: <path-to-kubeconfig-file>

这里是admissionConfigurationschema定义

  • 在kubeConfig文件里,提供证书
apiVersion: v1
kind: Config
users:
# DNS name of webhook service, i.e., <service name>.<namespace>.svc, or the URL
# of the webhook server.
- name: 'webhook1.ns1.svc'
  user:
    client-certificate-data: <pem encoded certificate>
    client-key-data: <pem encoded key>
# The `name` supports using * to wildmatch prefixing segments.
- name: '*.webhook-company.org'
  user:
    password: <password>
    username: <name>
# '*' is the default match.
- name: '*'
  user:
    token: <token>

固然,你须要设置web钩子服务器来处理这些认证.

相关文章
相关标签/搜索