Kubernetes浅析基本概念和原理

Posted 2021-06-03 inet_ygssoftware

摘要：本文从 Kubernetes (K8S) 的几个核心概念入手，对 K8S 的整体架构设计进行了概括性分析，进而对 K8S 的认证、授权、准入控制的相关内容进行了介绍。

1 核心概念和架构设计

1.1 概念与层级关系

Image 镜像的运行得到 Container 容器。

Pod 内可以有一个或者多个容器，Pod 中的容器运行在一台机器上且共享网络，有一个唯一的 IP，每个 Pod 中会有一个 Pause 容器，Pause 容器作为根容器，将 Pod 中的其他容器连接在一起。Pod 会负责内部容器的健康检查，几个关系紧密的容器可以放在一个 Pod 中。

ReplicaSet 是 Pod 的上级，是 K8S 中的一种副本控制器，负责多个 Pod 的管理。K8S 官方推荐不要直接使用 ReplicaSet，用 Deployment 取而代之。

Deployment 是 ReplicaSet 的上级，负责 ReplicaSet 的创建和销毁，管理 ReplicaSet 并提供很多有用的特性，最重要的是 Deployment 支持声明式更新，声明式对比命令式更新的优势在于不会丢失历史变更，可以通过 Deployment 实现滚动部署。

Service 可以使用 Selector 找到指定 label 的 Pod，Service 对外有一个 ClusterIP，客户端/其他服务可以通过 ClusterIP 访问到 Pod 服务。

1.2 架构设计

K8S 使用主从架构，内部的节点分别主节点 Master 和从节点 Worker ，Master 负责管理 Worker 节点，K8S 使用 ETCD 做存储，用于节点和服务信息的管理，持久化地存储这些信息，保证数据不丢失，可以进行服务的恢复。

服务 API Servser 接到客户端的请求后，调度器 Scheduler 会收集每一个 Worker 的详细信息（资源、内存、GPU、服务），根据预选策略或优选策略选择一个最优节点和 Pod 建立联系，告诉 API Server 该 Pod 可以运行在某个节点上，并将信息存放到 ETCD 中。

Controller Manager 是集群控制中心，负责维护 K8S 对象，内部有 Service Controller 管理服务，Pod Controller 管理 Pod 列表，Replication Controller 管理副本，ResourceQuota 管理资源的配额。Controller Manager 通过 Api Server 获取 ETCD 中一些节点的变化（例如Pod和Node的绑定关系）

每个 Worker 都有 Kubelet 服务，负责维护 Pod 的生命周期，管理容器的 Volume 和网络。 Kubelet 会调用本地的 Docker 去实现 Pod 中容器的运行。

2 K8S的认证和授权

2.1 前置知识

在 K8S 中，当客户端发起 API Server 调用时，API Server 会先认证 (Authentication) 用户，再给用户授权 (Authorization)，最后执行准入控制 (Admission Control)

• 认证：确认请求方是否合法
• 授权：授予请求方 API 请求权限，并鉴别请求方访问的 API 请求是否合法
• 准入控制：在认证和授权后补充额外的检查机制，用于做最后的拦截

对称加密：双方都使用相同私钥进行加密和解密。性能损耗小。

非对称加密：使用公钥对数据加密，使用私钥对数据解密。性能损耗大。

组合加密：第一次通过公钥加密一个密钥，将密钥安全的传送到另一方，另一方通过私钥获得密钥，之后使用对称加密的密钥进行通信。

组合加密的安全隐患：中间人截获公钥，发送一个伪造的公钥。可以通过CA验证公钥的真伪。

2.2 认证

客户端证书认证（TLS双向认证）

Kubectl 在访问 API Server 的时候会验证 API Server 的真伪，API Server 会验证 Kubectl 是否是合法的客户端。

首先 K8S 会通过 CA 判断和保证证书的合法性，K8S 使用的是自己的认证中心，CA 会给各个组件办法证书。组件间通信通过这个证书判断双方的合法性。

Bearer Token认证

Bearer Token认证是生成一个长串 Token ，并放入 Header 发起 HTTP 请求，API Server 依据 Token 识别用户，通过–token-auth-file=XXXXX加载所有用户 Token ，请求的时候 Header加上 Token即可，这种方式操作简单，但是需要重启 API Server才能更新，灵活性和安全性较弱。

Service Account认证

Service Account认证是 Pod 内部访问 API Server 的鉴权方式。

Controller Manager 和 API Server 会利用 Server 端的私钥为每个 Pod 创建一个 Token，通过目录挂载的方式挂载在 Pod 的目录系统中，应用通过读取指定目录的文件获取到这些信息，拿到这些信息后就可以和 API Server 进行交互。

2.3 授权

Attribute-based access control (ABAC)

通过使用将属性组合在一起的策略来向用户授予访问权限。可以通过–authorization-policy-file=SOME_FILENAME指定策略文件，策略文件是 JSON 格式的，每一行代表一个策略对象。

当用户发送请求到 API Server 时，用户识别用户所拥有的权限策略信息，并与策略文件中的策略对象进行匹配，如果至少一行匹配成功，该请求就通过了授权。

WebHook

WebHook 是一种 HTTP 回调：某些条件下触发的 HTTP POST 请求；通过 HTTP POST 发送的简单事件通知。一个基于 web 应用实现的 WebHook 会在特定事件发生时把消息发送给特定的 URL。

当判断用户权限时，WebHook 模式会让 K8S 查询外部的 REST 服务。

Role Based Access Control (RBAC)

RBAC是K8S中比较推荐的授权方式，RBAC是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组 来驱动鉴权决定，允许通过 Kubernetes API 动态配置策略。要启用 RBAC，在启动API Server时设置 --authorization-mode=RBAC 。

使用RBAC可以对集群资源和非资源权限都有完整的覆盖，可以通过kubectl或者api来操作，可以运行时调整，无需重启API Server

RBAC包括四个资源对象：

1. Role：一个角色就是一组权限的集合，拥有某个 namespace 下的权限
2. ClusterRole：集群角色，拥有整个 cluster 下的权限。如果希望在名字空间内定义角色，应该使用 Role； 如果希望定义集群范围的角色，应该使用 ClusterRole。
3. RoleBinding：将Role绑定目标 (user、group、service account)，K8S 没有数据库，通过 RoleBinding 记录。
4. ClusterRoleBinding：将ClusterRole绑定目标。

2.4 准入控制

经过认证和授权后，还需要经过多个准入控制器的审核，用户向 API Server 的请求才能成功得到相应。

准入控制器包括：AlwaysAdmit（允许所有请求）、AlwaysDeny（禁止所有请求）、ServiceAccount（让ServiceAccount实现自动化）、DenyEscolatingExec（拦截所有exec和attach到特权pod上的请求）等。

3 集群搭建方案

社区方案：杂乱、不可靠、升级困难。

Kubeadm：安装过程简单、支持高可用、升级方便、不易维护、文档简陋。

Binary：易于维护，Binary通过进程直接运行，手动配置和运行，可以轻松的理解组件间调用关系。灵活性好、升级方便。没有文档、安装过程复杂。