03、Kubernetes - 实战：Kubernetes组件详解

一、Kubernetes组件详解

Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

1、Kubernetes组件组成

Kubernetes 主要由以下几个核心组件组成：

• etcd ：保存了整个集群的状态；
• kube-apiserver ：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• kube-controller-manager： 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• kube-scheduler： 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
• kubelet ：负责维持容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
• Container runtime ：负责镜像管理以及 Pod 和容器的真正运行（CRI），默认的容器运行时为 Docker；
• kube-proxy： 负责为 Service 提供 cluster 内部的服务发现和负载均衡；
• kube-dns： 负责为整个集群提供 DNS 服务
• Ingress Controller ：为服务提供外网入口
• Heapster ：提供资源监控
• Dashboard ：提供 GUI
• Federation ：提供跨可用区的集群
• Fluentd-elasticsearch ：提供集群日志采集、存储与查询

2、API设计原则

• 所有API应该是声明式的。
• API对象是彼此互补而且可组合的。
• 高层API以操作意图为基础设计。
• 低层API根据高层API的控制需要设计。
• 尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。
• API操作复杂度与对象数量成正比。
• API对象状态不能依赖于网络连接状态。
• 尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

3、控制机制设计原则

• 控制逻辑应该只依赖于当前状态。
• 假设任何错误的可能，并做容错处理。
• 量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。
• 假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。
• 每个模块都可以在出错后自动恢复。
• 每个模块都可以在必要时优雅地降级服务。

4、架构设计原则

• 只有apiserver可以直接访问etcd存储，其他服务必须通过Kubernetes API来访问集群状态
• 单节点故障不应该影响集群的状态
• 在没有新请求的情况下，所有组件应该在故障恢复后继续执行上次最后收到的请求（比如网络分区或服务重启等）
• 所有组件都应该在内存中保持所需要的状态，apiserver将状态写入etcd存储，而其他组件则通过apiserver更新并监听所有的变化
• 优先使用事件监听而不是轮询

5、核心 技术概念和API对象

API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区
分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod设计理念副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复本控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。

6、控制节点（Master）

Kubernates集群控制节点，部署了集群的核心组件（kube-apiserver、kube-controller-manager、kube-scheduler、etcd）承担整个集群的控制能力。

7、工作节点（Node）

最初Node称为服务节点Minion，后来改名为Node。K8s集群中的Node也就等同于Mesos集群中的Slave节点，是所有Pod运行所在的工作主机，可以是物理机也可以是虚拟机。不论是物理机还是虚拟机，工作主机的统一特征是上面要运行kubelet管理节点上运行的容器。

8、容器（Container）

Container（容器）是一种便携式、轻量级的操作系统级虚拟化技术。它使用namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。

9、POD

Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

10、标签（Labels）

Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）
Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如ReplicaSet 和 Service 用 label 来选择一组 Pod）。Label Selector 支持以下几种方式：

• 等式，如 app=nginx 和 env!=production
• 集合，如 env in (production, qa)
• 多个 label（它们之间是 AND 关系），如 app=nginx,env=test

11、注解（Annotations）

Annotations 是 key/value 形式附加于对象的注解。不同于 Labels 用于标志和选择对象，Annotations 则是用来记录一些附加信息，用来辅助应用部署、安全策略以及调度策略等。比如 deployment 使用 annotations 来记录 rolling update 的状态。

12、名字空间（Namespace）

名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以创建新的名字空间满足需要。

13、复制控制器（Replication Controller，RC）

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。

14、副本集（Replica Set，RS）

RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用。

15、部署(Deployment)

部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。

16、服务（Service）

在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

17、任务（Job）

Job管理的Pod根据用户的设置把任务成功完成就自动退出

18、定时任务（ConJob）

类似linux的Cron，用来在给定时间点或者是周期循环执行任务。

19、后台支撑服务集（DaemonSet）

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支撑K8s集群运行的服务。

20、有状态服务集（StatefulSet）

StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。
适合于StatefulSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务。

21、存储卷（Volume）

K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。K8s支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent VolumeClaim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如AWS，Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。

22、持久存储卷（Persistent Volume，PV）和持久存储卷声明（Persistent Volume Claim，PVC）

PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，由K8s集群的使用者即服务的管理员来配置。

23、密钥对象（Secret）

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好处是可以避免把敏感信息明文写在配置文件里。

24、配置管理（Configmap）

ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。

25、用户帐户（User Account）和服务帐户（ServiceAccount）

用户帐户为人提供账户标识，而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。

26、RBAC访问授权

K8s在1.3版本中发布了alpha版的基于角色的访问控制（Role-based Access Control，RBAC）的授权模式。相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。