15.4 回到集群管控入口

在上一节中，我们发现Kube Controller Manager在获取metrics.Kubernetes. io/v1beta1这个API分组/版本的时候失败了。而这个查询请求，显然是发给API Server的。所以我们回到API Server日志，分析metrics.Kubernetes.io/v1beta1相关的记录。在相同的时间点，我们看到API Server也报了同样的错误“the server is currently unable to handle the request”。

● API Server报了和命名空间控制器一样的错误。

显然这里有一个矛盾，就是API Server明显在正常工作，为什么在获取metrics.Kubernetes.io/v1beta1这个API分组版本的时候会返回Server不可用呢？为了回答这个问题，我们需要理解一下API Server的“外挂”机制。

集群API Server有扩展自己的机制，开发者可以利用这个机制，来实现API Server的“外挂”。这个“外挂”的主要功能，就是实现新的API分组/版本。API Server作为代理，会把相应的API调用，转发给自己的“外挂”，如图15-4所示。

图15-4 API Server的扩展机制

以Metrics Server为例，它实现了metrics.Kubernetes.io/v1beta1这个API分组/版本。所有针对这个分组/版本的调用，都会被转发到Metrics Server。如下面命令行输出所示，Metrics Server的实现，主要用到一个服务和一个Pod。

以上命令行输出的apiservice，则是把“外挂”和API Server联系起来的机制。通过下面的Yaml代码可以看到这个apiservice的详细定义。它包括API分组/版本，以及实现了Metrics Server的服务名。有了这些信息，API Server就能把针对metrics.Kubernetes.io/v1beta1的调用转发给Metrics Server。