【容器架构】Kubernetes API 架构

Kubernetes API服务器处理对您的Kubernete集群的所有请求。

但它实际上是如何工作的呢？

当您输入kubectl apply-f my.yaml时，您的yaml将被发送到API并存储在etcd中。

但是API服务器在做什么呢？

Kubernetes API高级概述

API在图中有一个单独的块，但实际情况是，多个组件按顺序处理您的请求。

第一个模块是HTTP处理程序。

这不过是一个普通的网络服务器。

Kubernetes API是模块化的。第一个组件是HTTP处理程序。
一旦API收到请求，它必须确保：

• 您有权访问群集（身份验证）。
• 您可以创建、删除、列出等资源（授权）。

这是评估RBAC规则（RBAC rules are evaluated）的部分。

在Kubernetes API服务器中，请求经过身份验证和授权。
因此，您通过了身份验证，可以创建Pods；接下来是什么？

API将请求传递给突变允许控制器（Mutation Admission Controller.）。

这个组件负责查看您的YAML并对其进行修改。

不过，你能用它改变什么样的YAML？

Kubernetes API服务器使用变异允许控制器向资源添加额外的字段。
你的pod有图片拉取政策吗？

如果没有，准入控制器将为您添加“始终”。

资源是pod吗？

• 它设置默认的服务帐户（如果未设置）。
• 添加带有标记的卷。

还有更多！

突变准入控制器附带一组默认控制器。
经过所有修改后，Pod看起来还像Pod吗？

API进行快速检查，以确保资源对内部架构有效。

您不希望在集群中存储格式错误的YAML。

Kubernetes API服务器验证对象定义的规范是否有效。
如果你试图在一个不存在的命名空间中部署Pod，有人阻止你吗？

验证准入控制器会这样做(The Validation Admission Controller does.)。

您是否试图部署超出配额的资源？

控制器也会防止这种情况发生。

验证准入webhook检查YAML定义并检查其有效性。
验证和突变准入控制器也是可定制的。

您可以注册脚本并设计检查，以决定是否应拒绝资源访问etcd。

您可以使用webhook扩展突变和验证准入控制器。
自定义准入控制器的两个优秀示例：

• Istio自动为所有Pod注入一个额外的容器（突变）。
• Gatekeeper（开放策略代理[Open Policy Agent]）根据策略检查您的资源并报告违规行为（验证）。

Istio和OPA Gatekeeper使用准入控制器来增加和验证Kubernetes资源
如果您成功地通过了验证准入控制器，那么您的资源将安全地存储在etcd中。

1. 请求被反序列化。
2. 在内存中创建一个运行时对象。
3. 最后，新的表示在etcd中被持久化。

在Kubernetes API的最后一步中，资源存储在etcd中。
值得注意的是，当您在YAML中定义Pod时，它们是有版本的。

然而，当存储在数据库中时，相同的Pod没有版本。

它与一个内部表示形式一起存储，该内部表示形式稍后可以反序列化为一个版本。

最后，Kubernetes API也是可扩展的！

您可以添加自己的API并在Kubernetes中注册它们。

度量API服务器就是一个很好的例子。

Kubernetes API是可扩展的
度量API服务器向API注册自己，并公开额外的API端点。

值得注意的是，您可以与API的其余部分集成，并使用API服务器中现有的身份验证和授权模块。

Metrics服务器是扩展Kubernetes API的一个例子。

最后，如果你喜欢这个帖子，你可能也会喜欢我们在Learnk8s上举办的Kubernetes研讨会https://learnk8s.io/training

直到下一次！