Kubernetes 可扩展 Admission 进入 Beta 阶段-低调大师

Kubernetes 可扩展 Admission 进入 Beta 阶段

2018-12-13 561

Kubernetes API Server 中有一个功能，能让用户（对工作负载）进行决策，这一功能在 1.9 中已经走入成熟期。

Admission 是 Kubernetes 中最强大的工具之一，可以通过限制创建对象的方式来增强 Kubernetes 集群的安全性，这部分一直是编译在代码之中的。在 1.9 中，我们将 Admission 的 Webhook 升级成 Beta，让用户可以在 API Server 之外对 Admission 施加影响。

Admission 是什么？

Admission（注1），是在认证之后，资源持久化之前的一个处理 API Server 请求的步骤。Admission 能获取到和认证过程一致的信息（用户、URL 等），以及绝大多数 API 请求的完整报文。

Admission 阶段由不同插件组成，每个 Admission 都会对一个侧面进行观察和操作。例如：影响调度决策的PodNodeSelector、阻止恶意容器的PodSecurityPolicy以及实现 Namespace 资源分配的ResourceQuota。

Admission 内部分为两个阶段：

变更（Mutation，突变？）：能够修改 API 请求的报文，还可以拒绝 API 请求。
验证：允许进行查询，以及拒绝 API 请求。

Admission 插件可以在这两个阶段起作用，但是变更总是在验证之前。

Mutation

Admission 的变更功能可以在资源生成之前进行修改。在 Admission 链条上可以多次修改同一个字段，因此插件不是无序的。

PodNodeSelector就是一个例子，他使用 Namespace 的一个注解namespace.annotations[“scheduler.alpha.kubernetes.io/node-selector”]，在其中查找标签选择器，并将其加入pod.spec.nodeselector字段。这一功能限制某个 Namespace 的 Pod，只能运行在指定节点上，同 Taint 的功能正好相反（也是 Admission 插件）。

验证

Admission 的验证阶段用来对特定 API 资源进行验证。这一阶段会在所有变更执行结束之后，API 资源不再发生变化的情况下进行。

PodNodeSelector插件同样演示了这一活动，他确保 Pod 的spec.nodeSelector字段符合该 Namespace 的限制。如果变更链上有其他 Admission 尝试在PodNodeSelector之后修改了资源的spec.nodeSelector，就会在验证阶段因为不符合限制而被拒绝创建。

Admission Webhook 是什么？

Admission webhook 允许 Kubernetes 安装者或集群管理员无需重新编译就可以加入 Admission 插件，像其他基于 k8s.io/apiserver 1.9 的扩展 API Server（例如 metrics（注 2）, service-catalog（注 3）、以及 kube-projects（注 4））一样。两种 Admission Webhook 都在各自的链条尾端运行，和编译的 Admission 插件具有同样的能力和限制。

有什么好处？

Webhook Admission 插件允许对任何 API Server 的任何资源进行变更和验证，所以可能有多种形态的应用，比较普通的用例包括：

修改 Pod 这样的资源。Istio 使用这一功能来把 Sidecar 注入到 Pod 之中。当然也可以编写插件强制把 Image Tag 改写为 Image SHA。
在多租户系统中，保留命名空间是一个常见情况。
复杂的 CustomResource 校验。对插件来说，整个资源都是可见的，因此可以对依赖字段甚至外部依赖资源进行复杂的校验（例如 LimitRanges）。
安全响应。可以编写一个插件，强制将 Image Tag 转换为 Image SHA，并阻止特定的 Image 运行。

注册

Webhook Admission 插件需要注册，所有的 API Server（Kube API server 以及所有扩展 API Server）都共享一个配置。在注册过程中插件需要提供如下信息：

如何连接到 Webhook Admission 服务。
如何验证 Webhook Admission Server。
把请求发送到这个服务器的哪里（URL）。
处理哪些资源和 HTTP 动词。
如果连接失败，API Server 怎么办。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
 name: namespacereservations.admission.online.openshift.io
webhooks: - name: namespacereservations.admission.online.openshift.io
 clientConfig:
 service: namespace: default
 name: kubernetes
 path: /apis/admission.online.openshift.io/v1alpha1/namespacereservations
 caBundle: KUBE_CA_HERE
 rules: - operations: - CREATE
 apiGroups: - ""
 apiVersions: - "*"
 resources: - namespaces
 failurePolicy: Fail

name：Webhook 的名称。变更类的 Hook 会使用名称进行排序。 clientConfig：如何连接，证书信任，以及如何向 Webhook Admission 服务器发送数据。 rules：API Server 应该在什么时机调用 Webhook。这里只有创建 Namespace 的时候才触发。这里可以指定任何资源，例如serviceinstances.servicecatalog.k8s.io的create操作也是可以定义的。 failurePolicy：如果 Webhook Admission 服务器无法连接，如何处置？有两个选项分别是 ”Ignore“（失败就通过）和 ”Fail“（失败就拒绝）。失败则通过的设置，可能会导致无法预测的行为。

认证和信任

因为 Webhoo Admission 插件能够获取任何发送过来的请求资源的内容，并且能进行变更，所以很有必要回答下面的问题：

API Server 如何检验 Webhook Admission Server。
Webhook Server 如何精确认证接入进来的 API Server。
接入的 API Server 是否被授权发送请求。

连接主要分为三种：

从 Kube API Server 以及扩展 API Server 到外部的 Admission Webhook（可能是部署在集群之外）。
从 Kube API Server 到自有 Admission Webhooks。
从扩展 API Server 到自有 Admission Webhooks。

要支持这些类别，Webhook Admission 插件可以用一个 kubeconfig 文件来得知如何连接到独立的服务器。为了和外部的 Admission Webook 进行通信，因为认证、授权都是外部服务器处理的，因此只能手工指定，别无他法。

自有服务来说，一个明智的插件会提供缺省的安全设施，提供简单、安全、可移植、零配置，并可以在各个 API Server 运行的能力。

简单、安全、可移植、零配置

如果把 Webhook Admission 服务器构建成扩展 API Server 的模式，就有可能把它聚合为一个普通的 API 服务器，会收到如下益处：

你的 Webhook 会和其他 API 一样，以类似 kube-apiserver kubernetes.default.svc （例如 https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews）服务的面目出现。可以使用kubectl进行测试。
无需任何配置，你的 Webhook 自动具有了集群内置的认证和授权能力，可以使用 RBAC 规则进行访问控制。
API Server 和 Webhook 之间可以直接使用内置认证进行通信。
因为通过 Kube API Server 代理通信，因此扩展 API Server 不会泄露 Service Account Token。

简单说来，这一安全拓扑可以使用 API Server 的所有安全机制，并且无需额外配置。

其他用法也是可以的，不过就需要附加的手工配置，以及大量的额外工作来完成同等目标。

如何开发 Webhook admission 服务器？

编写一个具有认证和鉴权能力的完整的服务是个令人生畏的任务。为简化这一工作，有些基于 Kubernetes 1.9 的项目提供了库支持，能把代码量缩减到两百行甚至更少。可以参考 generic-admission-apiserver（注 5）以及 kubernetes-namespace-reservation（注 6）作为创建自己的安全、可移植的 Webhook Server 的示例。

在 1.9 中有了 Admission Webhook，让 Kubernetes 更加贴近用户需求，我们希望 Red Hat 和 Google 的这一工作能让支持更多的工作负载，为整体生态贡献更多（例如 Istio），现在是时候试一试了！

本文转自kubernetes中文社区-Kubernetes 可扩展 Admission 进入 Beta 阶段

微信关注我们

原文链接：https://yq.aliyun.com/articles/679431

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Kubernetes源码之旅：从kubectl到API Server

概述： Kubernetes项目目前依然延续着之前爆炸式的扩张。急需能够理解Kubernetes原理并且贡献代码的软件开发者。学习Kubernetes源码并不容易。Kubernetes是使用相对年轻的Go语言编写，并且拥有大量的源代码。在这个系列的多篇文章里，我将为大家深入分析Kubernetes的关键源码，以及介绍那些帮助我理解源码的技术。我的目标是提供一系列的文章，让对于Kubernetes还较为陌生的开发者能够快速学习Kubernetes源码。在第一篇文章里，我会分析从运行一个简单的kubectl命令到向API Server发送REST调用的源码执行过程。在开始深入Kubernetes之前，我建议你先阅读一下Julia Evans对Kubernetes架构的高级概述分析的文章。 Kubectl命令的基本运行 Kubernetes里的命令行接口叫做kubectl。它用来控制Kubernetes集群。阅读这部分源码实现是一个好的开始。我们要追踪的命令是kubectl create -f——它会从文件创建K8s资源。我们要创建的资源是使用了Nginx基础镜像的单副本Pod。下面是它的...

2018-12-14

502

calico是一个安全的 L3 网络和网络策略提供者。 calico使用bgp的原因：why bgp not ospf 有关BGP rr的介绍安装方式标准托管安装（ETCD存储）需要提前安装etcd集群 # 创建calico连接etcd的secret kubectl create secret generic calico-etcd-secrets \ --from-file=etcd-key=/etc/kubernetes/ssl/kubernetes-key.pem \ --from-file=etcd-cert=/etc/kubernetes/ssl/kubernetes.pem \ --from-file=etcd-ca=/etc/kubernetes/ssl/ca.pem # 部署 kubectl create -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/calico.yaml # rbac kubectl apply -f https://d...

2018-12-14

758

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。