Kubernetes初识——基本概念了解

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

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

除了核心组件，还有一些推荐的Add-ons：

• kube-dns：负责为整个集群提供DNS服务；
• Ingress Controller：为服务提供外网入口；
• Heapster：提供资源监控；
• Dashboard：提供GUI；
• Federation：提供跨可用区的集群；
• Fluentd-elasticsearch 提供集群日志采集、存储与查询

Pod

K8s有很多技术概念，同时对应很多API对象，最重要的也是最基础的是微服务Pod。 Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设 计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和 文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理 念。比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一 个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是 他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容 器镜像，在部署的时候组合成一个微服务对外提供服务。 Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类 型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服 型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态 应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、 DaemonSet和StatefulSet。

复制控制器（Replication Controller，RC）

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中 运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就 会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数 目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可 用的能力，保证永远有1个Pod在运行。

副本集（Replica Set，RS）

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

部署(Deployment)

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

服务（Service）

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访 问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止， 在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服 务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客 户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务 就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟 IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy 是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一 个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端使用反向 代理作负载均衡，还要进一步解决反向代理的高可用问题。

任务（Job）

Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是 批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管 理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的 spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任 务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

后台支撑服务集（DaemonSet）

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

有状态服务集（StatefulSet）

RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设 置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名 字和启动在哪儿都不重要，重要的只是Pod总数；而StatefulSet是用来控制有状态服 务，StatefulSet中的每个Pod的名字都是事先确定的，不能更改。StatefulSet中Pod的名 字的作用，是关联与该Pod对应的状态。
对于RC和RS中的Pod，一般不挂载存储或者挂载共享存储，保存的是所有Pod共享的状 态，适合于StatefulSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务 Zookeeper、etcd等有状态服务。

存储卷（Volume）

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

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

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

节点（Node）

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

密钥对象（Secret）

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好 处是可以避免把敏感信息明文写在配置文件里。在K8s集群中配置和使用服务不可避免 的要用到各种敏感信息实现登录、认证等功能，例如访问AWS存储的用户名密码。为了 避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个 Secret对象，而在配置文件中通过Secret对象引用这些敏感信息。这种方式的好处包 括：意图明确，避免重复，减少暴露机会。

用户帐户（User Account）和服务帐户（Service Account）

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

名字空间（Namespace）

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

RBAC访问授权

K8s在1.3版本中发布了alpha版的基于角色的访问控制（Role-based Access Control， RBAC）的授权模式。相对于基于属性的访问控制（Attribute-based Access Control， ABAC），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。 在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略可以 跟某个角色关联，具体的用户在跟一个或多个角色相关联。显然，RBAC像其他新功能 一样，每次引入新功能，都会引入新的API对象，从而引入新的概念抽象，而这一新的 概念抽象一定会使集群服务管理和使用更容易扩展和重用。