Kubernetes（k8s）生产级实践指南 ，从部署到核心应用 (一）

一、环境参数

• k8s 1.20.2
• Containerd 1.4.3
• Harbor 1.6.0
• Docker 17.03.x
• Prometheus 2.8.1
• Java 1.8
• Istio 1.1.2

二、核心概念与架构

Pod

Pod特征：
①、Pod里边的所有容器都是运行在一台机器
②、Pod里边的所有容器共享网络，有一个唯一的IP
③、每个Pod都有一个特殊的被称为“根容器”的Pause 容器，它的作用是将其他的容器关联(link)起来，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，也会负责整个容器的健康检查

ReplicaSet(RS)副本集

Pod上边有一层，副本集，一个应用可以起两个Pod，RS就是来管这个的，当有一个pod挂了之后，会在另一台机器拉起一个Pod；

Deployment

在RS上一层，还有一个概念，叫Deployment （部署），常见的场景即旧的应用运行了两个实例，更新应用的时候，一般是更新 Deployment，Deployment 会自动的帮我们创建一个 ReplicaSet（副本集），并且会滚动的先启动一个Pod，

Service

首先要了解Service，就要先了解 Label 标签，deployment、Pod 都可以打标签，

三、k8s架构设计

k8s选择的存储组件以 ETCD集群作为存储；
scheduler会收集每个节点的信息，包括资源、内存、CPU，以及节点运行的服务等，通过一系列的算法，预选策略或优选策略，最终会选择一个最优的节点，然后把这个节点跟Pod建立起一个关系，告诉ApiServer，这个Pod可以运行在某个节点上，APIServer会把这个消息存在 ETCD 里边作为池化，Pod和Node作为一个绑定之后，接下来就需要把这个Pod真正的启动起来，这时用到另外一个模块 ControllerManager，它是这个集群内部的控制中心，负责维护各种各样的 k8s 对象，比如还有 serverController 管理服务的，ControllerManager 会通过 APIServer获取节点的变化，比如说刚才Pod和Node的绑定关系。

Pod怎么在Worker上边运行起来呢？这就需要每个 Worker 节点都需要安装 kubelet 服务，负责维护Pod的生命周期，包括Pod的Volume、网络等，最终 kubelet 会调用本地的 Docker，去实现运行起容器，以及一个个Pod。

四、认证与授权

k8s 认证的密码学原理

认证：你去面试，说你是清华大学毕业的，面试官可能还不相信，但是当你拿出毕业证的时候，这时候面试官就会相信，这就是认证；
授权：授权之后才会有权限操作；

对称加密和非对称加密：

对称加密：有相同的私钥；
非对称加密：两个不同的私钥，解密非常复杂，如果每次通讯都用非对称加密，性能损耗是无法接受的。

相较于非对称加密，对称加密的性能是非常非常高的，在这种情况，能否将两种算法结合在一起？

第一次通讯使用非对称加密，将对称加密的私钥安全发送到对方，对方解密后拿到对称加密的秘钥，第二次通讯就可以使用对称加密来进行通讯，在通讯的时候也就不需要公钥了。

这个过程就是 SSL/TLS 协议

上边的过程很完美吗？其实还有被截获的风险

在 serverB 返回给 ServerA 公钥的时候可能被截获，篡改公钥后，ServerA 拿着黑客篡改后的公钥进行加密，然后发给 ServerB，在这个过程中，黑客就可以拦截拿到加密后的密文，通过黑客的公钥进行解密。

需要通过CA来认证来解决上述问题：

认证与授权

生产级用户环境
在生产环境中，情况可能不再是你或者一小组人在访问集群，而是几十 上百人需要访问集群。在学习环境或者平台原型环境中，你可能具有一个 可以执行任何操作的管理账号。在生产环境中，你可需要对不同名字空间 具有不同访问权限级别的很多账号。

建立一个生产级别的集群意味着你需要决定如何有选择地允许其他用户访问集群。 具体而言，你需要选择验证尝试访问集群的人的身份标识（身份认证），并确定 他们是否被许可执行他们所请求的操作（鉴权）：

认证（Authentication）：API 服务器可以使用客户端证书、持有者令牌、身份 认证代理或者 HTTP 基本认证机制来完成身份认证操作。 你可以选择你要使用的认证方法。通过使用插件，API 服务器可以充分利用你所在 组织的现有身份认证方法，例如 LDAP 或者 Kerberos。 关于认证 Kubernetes 用户身份的不同方法的描述，可参阅 身份认证。
鉴权（Authorization）：当你准备为一般用户执行权限判定时，你可能会需要 在 RBAC 和 ABAC 鉴权机制之间做出选择。参阅 鉴权概述，了解 对用户账户（以及访问你的集群的服务账户）执行鉴权的不同模式。
基于角色的访问控制（RBAC）： 让你通过为通过身份认证的用户授权特定的许可集合来控制集群访问。 访问许可可以针对某特定名字空间（Role）或者针对整个集群（ClusterRole）。 通过使用 RoleBinding 和 ClusterRoleBinding 对象，这些访问许可可以被 关联到特定的用户身上。
基于属性的访问控制（ABAC）： 让你能够基于集群中资源的属性来创建访问控制策略，基于对应的属性来决定 允许还是拒绝访问。策略文件的每一行都给出版本属性（apiVersion 和 kind） 以及一个规约属性的映射，用来匹配主体（用户或组）、资源属性、非资源属性 （/version 或 /apis）和只读属性。 参阅示例以了解细节。

认证

ApiServer 为集群的唯一入口

最常用的三种认证方式：CA，BearerToken(通过python调用APIServer可用这种方式来认证)，ServiceAccount

授权

认证？你是谁；授权：你能做什么。

ClusterRole (node 节点资源不属于任何一个namespace，如果要给某一个人分配某个节点的资源，则把node的资源加到角色里边。

AdminssionController插件

k8s架构

五、集群搭建方案对比

社区方案

• 杂乱
• 不可靠
• 升级难

kubeadm

• 优雅
• 简单
• 支持高可用
• 升级方便
• 不易维护
• 文档不够细致

Binary（二进制方式）

• 易于维护
• 灵活
• 升级方便
• 没有文档（缺点）
• 安装复杂

相关文章：
Kubernetes（k8s）生产级实践指南 ，从部署到核心应用
K8S学习笔记之九-pause容器
理解认证授权
K8S - Kubernetes(K8S)整体概述与组件架构通俗讲解
kubernetes.io官网

为者常成，行者常至