kubernetes介绍

---

发展历史

Kubernetes是Google在2014年6月开源的一个容器集群管理系统，使用Go语言开发，Kubernetes也叫K8S。

K8S是Google内部一个叫Borg的容器集群管理系统衍生出来的，Borg已经在Google大规模生产运行十年之久。

K8S主要用于自动化部署、扩展和管理容器应用，提供了资源调度、部署管理、服务发现、扩容缩容、监控等一整套功能。

2015年7月，Kubernetes v1.0正式发布，截止到2018年1月27日最新稳定版本是v1.9.2。Kubernetes目标是让部署容器化应用简单高效。

官方网站：www.kubernetes.io

主要功能

数据卷

Pod中容器之间共享数据，可以使用数据卷。

应用程序健康检查

容器内服务可能进程堵塞无法处理请求，可以设置监控检查策略保证应用健壮性。

复制应用程序实例

控制器维护着Pod副本数量，保证一个Pod或一组同类的Pod数量始终可用。

弹性伸缩

根据设定的指标（CPU利用率）自动缩放Pod副本数。

服务发现

使用环境变量或DNS服务插件保证容器中程序发现Pod入口访问地址。

负载均衡

一组Pod副本分配一个私有的集群IP地址，负载均衡转发请求到后端容器。在集群内部其他Pod可通过这个ClusterIP访问应用。

滚动更新

更新服务不中断，一次更新一个Pod，而不是同时删除整个服务。

服务编排

通过文件描述部署服务，使得应用程序部署变得更高效。

资源监控

Node节点组件集成cAdvisor资源收集工具，可通过Heapster汇总整个集群节点资源数据，然后存储到InfluxDB时序数据库，再由Grafana展示。

提供认证和授权

支持角色访问控制（RBAC）认证授权等策略。

基本对象

---

node

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

Pod

Pod是最小部署单元，一个Pod有一个或多个容器组成，Pod中容器共享存储和网络，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。在同一台Docker主机上运行。

K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（nodedaemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet

Service

Service一个应用服务抽象，定义了Pod逻辑集合和访问这个Pod集合的策略。

一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。

Service代理Pod集合对外表现是为一个访问入口，分配一个集群IP地址，来自这个IP的请求将负载均衡转发后端Pod中的容器。

Service通过Lable Selector选择一组Pod提供服务。

Volume

存储卷，共享Pod中容器使用的数据及持久化数据。K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。

Namespace

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

命名空间将对象逻辑上分配到不同Namespace，可以是不同的项目、用户等区分管理，并设定控制策略，从而实现多租户。

Lable

标签用于区分对象（比如Pod、Service），键/值对存在；每个对象可以有多个标签，通过标签关联对象

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

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

基本对象的更高层次抽象

---

ReplicaSet

下一代Replication Controller。确保任何给定时间指定的Pod副本数量，并提供声明式更新等功能。

RC与RS唯一区别就是lable selector支持不同，RS支持新的基于集合的标签，RC仅支持基于等式的标签。

Deployment

Deployment是一个更高层次的API对象，它管理ReplicaSet和Pod，并提供声明式更新等功能。

官方建议使用Deployment管理ReplicaSets，而不是直接使用ReplicaSets，这就意味着可能永远不需要直接操作ReplicaSet对象。

实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。

StatefulSet

有状态服务集（StatefulSet）适合持久性的应用程序，有唯一的网络标识符（IP），持久存储，有序的部署、扩展、删除和滚动更新。

StatefulSet中的每个Pod的名字都是事先确定的，不能更改。

对于RC和RS中的Pod，一般不挂载存储或者挂载共享存储，保存的是所有Pod共享的状态，Pod像牲畜一样没有分别；对于StatefulSet中的Pod，每个Pod挂载自己独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

适合于StatefulSet的业务包括数据库服务MySQL和PostgreSQL，集群化管理服务Zookeeper、etcd等有状态服务

DaemonSet

后台支撑服务集（DaemonSet）确保所有（或一些）节点运行同一个Pod。当节点加入Kubernetes集群中，Pod会被调度到该节点上运行，当节点从集群中移除时，DaemonSet的Pod会被删除。删除DaemonSet会清理它所有创建的Pod。

典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支撑K8s集群运行的服务。

Job

Job是K8s用来控制批处理型任务的API对象，用于执行一次性任务，运行完成后Pod销毁，不再重新启动新容器。还可以任务定时运行。

成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

RBAC

相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联。

k8s集群架构图及组件功能

---

架构图

最上层是kubectl，用户通过这个工具来管理整个集群。用户通过kubectl来调用master上的kube api接口。

在节点上主要跑kubelet、kube-proxy、docker组件。

etcd用于保存集群的状态。

基本组件及功能

Master组件

kube-apiserver
Kubernetes API，集群的统一入口，各组件协调者，以HTTP API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。并提供认证、授权、访问控制、API 注册和发现等机制；

kube-controller-manager
负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

kube-scheduler
它监听apiserver，查询还未分配node的pod，然后根据调度算法为新创建的Pod选择一个Node节点。

Node组件

kubelet
kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如负责 Volume（CVI）和网络（CNI）的管理、创建容器、下载secret、获取容器和节点状态等工作。

kube-proxy
负责为 Service 提供 cluster 内部的服务发现和负载均衡；

docker或rocket/rkt
负责镜像管理以及 Pod 和容器的真正运行（CRI）；

第三方服务

etcd
分布式键值存储系统。用于保持集群状态，比如Pod、Service等对象信息

flannel
提供跨主机的pod通信的功能。

组件间通信

• apiserver 负责 etcd 存储的所有操作，且只有 apiserver 才直接操作 etcd 集群

• apiserver 对内（集群中的其他组件）和对外（用户）提供统一的 REST API，其他组件均通过 apiserver 进行通信

  controller manager、scheduler、kube-proxy 和 kubelet 等均通过 apiserver watch API 监测资源变化情况，并对资源作相应的操作

• 所有需要更新资源状态的操作均通过 apiserver 的 REST API 进行

• apiserver 也会直接调用 kubelet API（如 logs, exec, attach 等），默认不校验 kubelet 证书，但可以通过 –kubeletcertificate-
  authority 开启（而 GKE 通过 SSH 隧道保护它们之间的通信）

用户创建一个pod的过程

1. 用户通过 REST API 创建一个 Pod
2. apiserver 将其写入 etcd
3. scheduluer 检测到未绑定 Node 的 Pod，开始调度并更新 Pod 的 Node 绑定
4. kubelet 检测到有新的 Pod 调度过来，通过 docker 运行该 Pod
5. kubelet 通过 docker 取到 Pod 状态，并更新到 apiserver 中

技术核心和API对象

---

API对象

API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。

每个API对象都有3大类属性：元数据metadata、规范spec和状态status。

K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统

元数据metadata

元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象

例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务

规范spec

规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State）

例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3

状态status

status描述了系统实际当前达到的状态（Status）

例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。