5.2 得其门而入

5.2.1 入口

Kubernetes作为操作系统，和普通的操作系统一样有API的概念。有了API，集群就有了入口；有了API，我们使用集群才能得其门而入。

Kubernetes的API被实现为运行在集群节点上的组件API Server，如图5-3所示。这个组件是典型的Web服务器程序，通过对外暴露http(s)接口来提供服务。

这里我们创建一个阿里云Kubernetes集群。登录集群管理页面，我们可以看到API Server的公网入口。

API Server内网连接端点：https://xx.xx.197.238:6443

5.2.2 双向数字证书验证

阿里云Kubernetes集群API Server组件，使用基于CA签名的双向数字证书认证来保证客户端与API Server之间的安全通信。这句话很拗口，初学者不太好理解，我们来深入解释一下。

从概念上来讲，数字证书是用来验证网络通信参与者的一个文件。这和学校颁发给学生的毕业证书类似。

在学校和学生之间，学校是可信第三方CA，而学生是通信参与者。如果人们普遍信任一个学校的话，那么这个学校颁发的毕业证书也会得到社会认可。参与者证书和CA证书好比毕业证和学校的办学许可证。

这里有两类参与者：CA和普通参与者。与此对应，我们有两种证书：CA证书和参与者证书。另外我们还有两种关系：证书签发关系和信任关系。这两种关系至关重要。

我们先看签发关系。如图5-4所示，我们有两张CA证书，三张参与者证书。其中最上面的CA证书签发了两张证书，一张是中间的CA证书，另一张是右边的参与者证书；中间的CA证书签发了下面两张参与者证书。这五张证书以签发关系为联系，形成了树状的证书签发关系图。

然而，证书以及签发关系本身，并不能保证可信的通信可以在参与者之间进行。

以图5-4为例，假设最右边的参与者是一个网站，最左边的参与者是一个浏览器，浏览器“相信”网站的数据，不是因为网站有证书，也不是因为网站的证书是CA签发的，而是因为浏览器相信最上面的CA，这就是信任关系。

理解了CA证书、参与者证书、签发关系以及信任关系之后，我们回头看看“基于CA签名的双向数字证书认证”是什么意思。

客户端和API Server作为通信的普通参与者，各有一张证书，如图5-5所示。这两张证书都是由CA签发的，我们简单地称它们为集群CA和客户端CA。客户端信任集群CA，所以它信任拥有集群CA签发证书的API Server；反过来，API Server需要信任客户端CA，然后才愿意与客户端通信。

阿里云Kubernetes集群CA证书和客户端CA证书，在实现上其实是一张证书，所以我们有图5-5所示的关系图。

5.2.3 KubeConfig文件

登录集群管理控制台，我们可以看到KubeConfig文件。这个文件包括了客户端证书、集群CA证书，以及其他证书。

证书使用Base64编码，所以我们可以使用Base64工具解码证书，并使用openssl查看证书文本。

首先，客户端证书签发者的公用名CN是集群ID：c0256a，而证书本身的CN是子账号252771。

其次，只有在API Server信任客户端CA证书的情况下，上面的客户端证书才能通过API Server的验证。kube-apiserver进程通过client-ca-file这个参数指定其信任的客户端CA证书，其指定的证书是/etc/kubernetes/pki/apiserver-ca. crt。这个文件实际上包含了两张客户端CA证书，其中一张和集群管控有关系，这里不做解释，另外一张如下，它的CN与客户端证书的签发者CN一致。

再次，API Server使用的证书，由kube-apiserver的参数tls-cert-file决定，这个参数指向证书/etc/kubernetes/pki/apiserver.crt。这个证书的CN是kube-apiserver，签发者是c0256a，即集群CA证书。

最后，客户端需要验证上面这张API Server的证书，因而KubeConfig文件里包含了其签发者，即集群CA证书。对比集群CA证书和客户端CA证书，发现两张证书完全一样，这符合我们的预期。

5.2.4 访问

理解了原理之后，我们可以做一次简单的测试。我们以证书作为参数，使用curl访问API Server，并得到预期结果。