k8s教程（03）-基本概念和术语

k8s教程（03）-基本概念和术语

文章目录

​​01 资源对象概述​​​​02 集群类​​

​​2.1 Master​​​​2.2 Node​​​​2.3 命名空间​​

​​03 应用类​​

​​3.1 service和pod​​​​3.2 label与标签选择器​​​​3.3 Pod和Deployment​​​​3.4 Service和ClusterIp​​​​3.5 Service外网访问​​​​3.6 有状态的应用集群​​​​3.7 批处理应用​​​​3.8 应用的配置​​

​​3.8.1 ConfigMap​​​​3.8.2 Secret​​

​​3.9 应用的运维​​

​​3.9.1 HPA横向扩容​​​​3.9.2 VPA垂直扩容​​

​​04 存储类​​

​​4.1 Volume（存储卷）​​

​​4.1.1 emptyDir（临时目录）​​​​4.1.2 hostPath（宿主机目录）​​​​4.1.3 公有云Volume​​​​4.1.4 其它类型的Volume​​​​4.1.5 动态存储​​

​​05 安全类​​

​​5.1 Service Account​​​​5.2 Role​​​​5.2 Role Binding​​​​5.3 NetworkPolicy（网络策略）​​

01 资源对象概述

​​Kubernetes​​ 中的基本概念和术语大多是围绕 资源对象（​​Resource Object​​）来说 的，而资源对象在总体上可分为以下两类：

某种资源的对象。例如节点​​Node​​​、​​Pod​​​、服务​​Service​​​、存储卷​​Volume​​。与资源对象相关的事物与动作。例如标签​​Label​​​、注解​​Annotation​​​、命名空间​​Namespace​​​、部署​​Deployment​​​、​​HPA​​​、​​PVC​​。

资源对象一般包括几个通用属性：版本、类别（​​Kind​​）、名称、标签、注解，如下所述。

版本信息：包括了此对象所属的资源组，一些资源对象的属性会随着版本的升级而变化，在定义资源对象时要特别注意这一点。类别属性：用于定义资源对象的类型。资源对象的名称（​​Name​​​）、标签、注解这三个属性属于资源对象的元数据（​​metadata​​​)，资源对象的名称要唯一。资源对象的标签是很重要的数据，也是​​Kubernetes​​ 的一大设计特性，比如通过标签来表明资源对象的特征、类别，以及通过标签筛选不同的资源对象并实现对象之间的关联、控制或协作功能。注解：可被理解为一种特殊的标签，不过更多地是与程序挂钩，通常用于实现资源对象属性的自定义扩展。

这里按照功能或用途对众多资源对象其进行分类，将其分为集群类、应用类、存储类及安全类这四大类，下面来讲解。

02 集群类

集群（​​Cluster​​​）表示一个由​​ Master​​​ 和 ​​Node ​​​组成的 ​​Kubernetes ​​集群。

2.1 Master

​​Master​​​指的是集群的控制节点。在每个 ​​Kubernetes​​​ 集群中都需要有一个或一组被称为 ​​Master ​​​的节点，来负责整个集群的管理和控制。​​Master ​​通常占据一个独立的服务器（在高可用部署中建议至少使用 3 台服务器），是整个集群的“大脑”，如果它发生宕机或者不可用，那么对集群内容器应用的管理都将无法实施。

在 ​​Master​​上运行着以下关键进程:

Kubernetes API Server (kube-apiserver）：提供 HTTP RESTful API 接口的主要服务，是 Kubernetes 里对所有资源进行增、删、改、查等操作的唯一入口，也是集群控制的入口进程。Kubernetes Controller Manager：Kubernetes 里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。Kubernetes Scheduler：负责资源调度（Pod 调度）的进程，相当于公交公司的调度室。在​​Master​​​上通常还需要部署​​etcd​​服务。

2.2 Node

​​Kubernetes​​​集群中除 ​​Master​​​ 外的其他服务器被称为 ​​Node​​​。​​Node​​​ 可以是一台物理主机，也可以是一台虚拟机。​​Node​​​ 是​​Kubernetes​​​集群中的工作负载节点，每个 ​​Node​​​ 都会被 ​​Master ​​​分配一些工作负载（​​Docker ​​​容器），当某个​​Node​​​宕机时，其上的工作负载会被 ​​Master ​​​自动转移到其他 ​​Node​​ 上。

在每个 ​​Node​​ 上都运行着以下关键进程：

kubelet：负责 Pod 对应容器的创建、启停等任务，同时与 Master 密切协作，实现集群管理的基本功能。kube-proxy：实现​​Kubernetes Service​​ 的通信与负载均衡机制的服务。容器运行时（如 ​​Docker​​）: 负责本机的容器创建和管理。

2.3 命名空间

在集群类里还有一个重要的基础概念一一命名空间，它在很多情况下用于实现多租户的资源隔离，典型的一种思路就是给每个租户都分配一个命名空间。每个命名空间都是相互独立的存在，属于不同命名空间的资源对象从逻辑上相互隔离。

在每个 ​​Kubernetes ​​​集群安装完成且正常运行之后，​​Master ​​会自动创建两个命名空间。

默认级（​​default​​）：用户创建的资源对象如果没有指定命名空间，则被默认存放在​​default​​命名空间中；系统级（​​kube-system​​）：系统相关的资源对象如网络组件、​​DNS​​​ 组件、监控类组件等，都被安装在​​kube-system ​​命名空间中。

我们可以通过命名空间将集群内部的资源对象“分配”到不同的命名空间中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时能被分别管理。当给每个租户都创建一个命名空间来实现多租户的资源隔离时，还能结合 ​​Kubernetes​​​ 的资源配额管理，限定不同租户能占用的资源，例如 ​​CPU ​​使用量、内存使用量等。

03 应用类

3.1 service和pod

应用类相关的资源对象主要是围绕 Service（服务）和 Pod 这两个核心对象展开的。

Service：一般指的是无状态服务，通常由多个程序副本提供服务，在特殊情况下也可以是有状态的单实例服务，比如 MySQL 这种数据存储类的服务。Pod：有一个特殊的被称为“根容器”的 Pause 容器，Pause 容器对应的镜像属于 Kubernetes 平台的一部分，还包含一个或多个紧密相关的用户业务容器。

3.2 label与标签选择器

给某个资源对象定义一个​​ label​​​，就相当于给它打了一个标签，随后可以通过 ​​Label Selector​​（标签选择器）查询和筛选拥有某些 Label 的资源对象，Kubernetes 通过这种方式实现了类似 SQL 的简单又通用的对象查询机制。

3.3 Pod和Deployment

3.4 Service和ClusterIp

​​Kubernetes​​​ 内部在每个 ​​Node​​​ 上都运行了一套全局的虚拟负载均衡器，自动注入并自动实时更新集群中所有 ​​Service​​​ 的路由表，通过 ​​iptables​​​或者 ​​IPVS​​​ 机制，把对 ​​Service​​​ 的请求转发到其后端对应的某个 ​​Pod​​ 实例上，并在内部实现服务的负载均衡与会话保持机制。

不仅如此，​​Kubernetes​​ 还采用了一种很巧妙又影响深远的设计一 ​​ClusterIP​​ 地址。

3.5 Service外网访问

我们需要先弄明白 Kubernetes 的三种 IP，分别如下：

NodePort 的确功能强大且通用性强，但也存在一个问题，即每个 Service 都需要在 Node 上独占一个端口，而端口又是有限的物理资源，那能不能让多个 Service 共用一个对外端口呢，这就是后来增加的 Ingress资源对象所要解决的问题。

Ingress其实只能将多个 HTTP (HTTPS）的 Service“聚合”，通过虚拟域名或者 URL Path 的特征进行路由转发功能，考虑到常见的微服务都采用了 HTTP REST 协议，所以 Ingress 这种聚合多个 Service 并将其暴露到外网的做法还是很有效的。

3.6 有状态的应用集群

我们知道，​​Deployment​​ 对象是用来实现无状态服务的多副本自动控制功能的，那么有状态的服务，比如: ZooKeeper：集群、MySQL 高可用集群（3 节点集群）、Kafka 集群等是怎么实现自动部署和管理的呢？

这个问题就复杂多了，这些一开始是依赖 ​​StatefulSet ​​​解决的，但后来发现对于一些复杂的有状态的集群应用来说，StatefulSet 还是不够通用和强大，所以后面又出现了​​ Kubernetes Operator​​。

平台开发者借助 ​​Operator​​​ 框架提供的 ​​API​​​，可以更方便地开发一个类似 ​​StatefulSet ​​的控制器。在这个控制器里，开发者通过编码方式实现对目标集群的自定义操控，包括集群部署、故障发现及集群调整等方面都可以实现有针对性的操控，从而实现更好的自动部署和智能运维功能。

从发展趋势来看，未来主流的有状态集群基本都会以 Operator 方式部署到 Kubernetes集群中。

3.7 批处理应用

除了无状态服务、有状态集群、常见的第三种应用，还有批处理应用。批处理应用的特点是一个或多个进程处理一组数据（图像、文件、视频等），在这组数据都处理完成后，批处理任务自动结束。为了支持这类应用，Kubernetes 引入了新的资源对象一一 Job，下面是一个计算圆周率的经典例子：

3.8 应用的配置

通过前面的学习，我们初步理解了三种应用建模的资源对象，总结如下。

无状态服务的建模：Deployment有状态集群的建模：StatefulSet批处理应用的建模：Job

3.8.1 ConfigMap

用户将配置文件的内容保存到 ConfigMap 中，文件名可作为 key, value 就是整个文件的内容，多个配置文件都可被放入同一个 ConfigMap。

在建模用户应用时，在 Pod 里将 ConfigMap。定义为特殊的 Volume 进行挂载。在 Pod 被调度到某个具体 Node 上时，ConfigMap 里的配置文件会被自动还原到本地目录下，然后映射到 Pod 里指定的配置目录下，这样用户的程序就可以无感知地读取配置了。

在 ConfigMap 的内容发生修改后，Kubernetes 会自动重新获取 ConfigMap 的内容，并在目标节点上更新对应的文件。

3.8.2 Secret

Secrett也用于解决应用配置的问题，不过它解决的是对敏感信息的配置问题，比如数据库的用户名和密码、应用的数字证书、Tokn、SSH 密钥及其他需要保密的敏感配置。对于这类敏感信息，我们可以创建一个 Secret 对象，然后被 Pod 引用。Secret 中的数据要求以 BASE64 编码格式存放。注意，BASE64 编码并不是加密的，在 Kubernetes1.7 版本以后，Secret 中的数据才可以以加密的形式进行保存，更加安全。

3.9 应用的运维

3.9.1 HPA横向扩容

首先就是​​ HPA (Horizontal Pod Autoscaler）​​​，我们可以将​​ HPA​​​ 理解为 ​​Pod​​​ 横向自动扩容，即自动控制 ​​Pod ​​​数量的增加或减少。通过追踪分析指定 ​​Deployment​​​ 控制的所有目标​​Pod​​​的负载变化情况，来确定是否需要有针对性地调整目标​​ Pod​​​ 的副本数量，这是 ​​HPA​​ 的实现原理。

3.9.2 VPA垂直扩容

​​VPA (Vertical Pod Autoscaler）​​ 即垂直 ​​Pod​​​ 自动扩缩容，它根据容器资源使用率自动推测并设置 ​​Pod​​​ 合理的​​CPU​​​和内存的需求指标，从而更加精确地调度 ​​Pod​​，实现整体上节省集群资源的目标，因为无须人为操作，因此也进一步提升了运维自动化的水平。

04 存储类

存储类的资源对象主要包括: ​​Volume​​、​​Persistent Volume​​、​​PVC​​ 和 ​​StorageClass​​。

4.1 Volume（存储卷）

​​Volume​​​ 是​​ Pod​​ 中能够被多个容器访问的共享目录。

首先​​Kubernetes​​​ 中的 ​​Volume​​​ 被定义在​​ Pod​​​上，被一个 ​​Pod​​​ 里的多个容器挂载到具体的文件目录下；其次，​​Kubernetes​​​ 中的 ​​Volume​​​ 与 ​​Pod​​​ 的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，​​Volume​​​ 中的数据也不会丢失；最后，​​Kubernetes​​​支持多种类型的 ​​Volume​​​，例如 ​​GlusterFS、Ceph ​​等分布式文件系统。

4.1.1 emptyDir（临时目录）

一个 ​​emptyDir ​​​是在 ​​Pod​​​ 分配到 ​​Node​​​ 时创建的。从它的名称就可以看出，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为这是 ​​Kubernetes​​​ 自动分配的一个目录，当 ​​Pod​​​ 从 ​​Node​​​ 上移除时，​​emptyDir ​​中的数据也被永久移除。

​​emptyDir​​ 的一些用途如下。

临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。长时间任务执行过程中使用的临时目录。一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。在默认情况下，​​emptyDir​​ 使用的是节点的存储介质，例如磁盘或者网络存储。

还可以使用 ​​emptyDir. Nedium​​​ 属性，把这个属性设置为“​​Memory​​​”，就可以使用更快的基于内存的后端存储了。需要注意的是，这种情况下的 ​​emptyDir ​​使用的内存会被计入容器的内存消耗，将受到资源限制和配额机制的管理。

4.1.2 hostPath（宿主机目录）

​​HostPath​​​ 为在 ​​Pod​​ 上挂载宿主机上的文件或目录，通常可以用于以下几方面：

在容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统对其进行存储。需要访问宿主机上​​Docker ​​​引擎内部数据结构的容器应用时，可以通过定​​hostPath​​​为宿主机​​/var/Iib/docker​​​目录，使容器内部的应用可以直接访问​​Docker ​​的文件系统。

在使用这种类型的 ​​Volume​​时，需要注意以下几点。

在不同的​​Node ​​​上具有相同配置的​​ Pod​​​，可能会因为宿主机上的目录和文件不同，而导致对​​Volume​​上目录和文件的访问结果不一致。如果使用了资源配额管理，则​​Kubernetes ​​​无法将​​hostPath​​ 在宿主机上使用的资源纳入管理。

4.1.3 公有云Volume

公有云提供的 ​​Volume ​​​类型包括谷歌公有云提供的 ​​GCEPersistentDisk​​​、亚马逊公有云提供的 ​​AWS Elastic Block Store (EBS Volume）​​​等。当我们的​​Kubernetes​​​集群运行在公有云上或者使用公有云厂家提供的​​ Kubernetes​​​ 集群时，就可以使用这类 ​​Volume​​。

4.1.4 其它类型的Volume

Iscsi：将​​SCSI​​​ 存储设备上的目录挂载到​​Pod​​ 中。nfs：将​​NFS Server​​​上的目录挂载到​​Pod​​ 中。glusterfs：将开源​​GlusterFS​​​ 网络文件系统的目录挂载到​​ Pod​​ 中。rbd：将​​ Ceph​​​ 块设备共享存储（​​Rados Block Device​​​）挂载到​​Pod​​中。gitRepo：通过挂载一个空目录，并从​​Git​​​ 库克隆（​​clone​​​）一个​​ git repository​​​ 以供​​Pod​​ 使用。configmap：将配置数据挂载为容器内的文件。secret：将​​Secret​​数据挂载为容器内的文件。

4.1.5 动态存储

​​Volume​​​属于静态管理的存储，即我们需要事先定义每个 ​​Volume​​​，然后将其挂载到 ​​Pod​​ 中去用，这种方式存在很多弊端，典型的弊端如下。

配置参数烦琐，存在大量手工操作，违背了​​Kubernetes ​​自动化的追求目标。预定义的静态​​Volume​​ 可能不符合目标应用的需求，比如容量问题、性能问题。

所以 Kubernetes 后面就发展了存储动态化的新机制，来实现存储的自动化管理。相关的核心对象（概念）有三个：Persistent Volume（简称 PV）、StorageClass、PVC。

05 安全类

安全始终是 Kubernetes 发展过程中的一个关键领域。

从本质上来说 ，​​Kubernetes​​ 可被看作一个多用户共享资源的资源管理系统，这里的资源主要是各种​​Kubernetes​​里的各类资源对象，比如 ​​Pod、Service、Deployment ​​​等。只有通过认证的用户才能通过 ​​Kubernetes​​​ 的 ​​API Server​​ 查询、创建及维护相应的资源对象，理解这一点很关键。

5.1 Service Account

​​Service Account​​​ 是通过​​ Secret​​​ 来保存对应的用户（应用）身份凭证的，这些凭证信息有 ​​CA ​​​根证书数据（​​ca.crt​​​）和签名后的​​Token​​​信息（​​Token​​）。

在 ​​Token​​​ 信息中就包括了对应的​​Service Account​​​的名称，因此 ​​API Server​​​ 通过接收到的​​Token​​​信息就能确定 ​​Service Account ​​​的身份。在默认情况下，用户创建一个​​ Pod​​​ 时，​​Pod ​​​会绑定对应命名空间中的 ​​default​​​ 这个 ​​Service Account ​​作为其“公民身份证”。

当 ​​Pod​​​ 里的容器被创建时，​​Kubernetes​​​ 会把对应的​​Secret​​​对象中的身份信息（​​ca.crt、Token​​​ 等）持久化保存到容器里固定位置的本地文件中，因此当容器里的用户进程通过 ​​Kubernetes ​​​提供的客户端 ​​API​​​ 去访问 ​​API Server ​​​时，这些​​API​​​会自动读取这些身份信息文件，并将其附加到 ​​HTTPS​​​ 请求中传递给​​API Server​​​以完成身份认证逻辑。在身份认证通过以后，就涉及“访问授权”的问题，这就是 ​​RBAC​​ 要解决的问题了。

5.2 Role

首先我们要学习的是 ​​Role ​​​这个资源对象，包括 ​​Role​​​ 与 ​​ClusterRole​​​两种类型的角色。角色定义了一组特定权限的规则，比如可以操作某类资源对象。局限于某个命名空间的角色由​​Role​​​对象定义，作用于整个 ​​Kubernetes​​​ 集群范围内的角色则通过 ​​Cluster Role ​​对象定义。

5.2 Role Binding

5.3 NetworkPolicy（网络策略）

在安全领域，除了以上针对 ​​API Server​​​ 访问安全相关的资源对象，还有一种特殊的资源对象一一 ​​NetworkPolicy​​（网络策略），它是网络安全相关的资源对象，用于解决用户应用之间的网络隔离和授权问题。

​​NetworkPolicy​​​ 是一种关于​​ Pod​​​ 间相互通信，以及 ​​Pod ​​与其他网络端点间相互通信的安全规则设定。

​​NetworkPolicy​​​资源使用标签选择​​ Pod​​​，并定义选定 ​​Pod ​​​所允许的通信规则。在默认情况下，​​Pod​​​ 间及​​Pod​​​与其他网络端点间的访问是没有限制的，这假设了 ​​Kubernetes​​​集群被一个厂商（公司/租户）独占，其中部署的应用都是相互可信的，无须相互防范。但是，如果存在多个厂商共同使用一个​​Kubernetes​​​集群的情况，则特别是在公有云环境中，不同厂商的应用要相互隔离以增加安全性，这就可以通过 ​​NetworkPolicy ​​来实现了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。