Kubernetes(K8s)初探

Docker技术

Docker本身并不是容器，它是创建容器的工具，是应用容器引擎。

Docker技术的三大核心概念，分别是：

镜像（Image）
容器（Container）
仓库（Repository）

负责对Docker镜像进行管理的，是Docker Registry服务（类似仓库管理员）。最常使用的Registry公开服务，是官方的Docker Hub，这也是默认的Registry，并拥有大量的高质量的官方镜像。

Kerbernetes (K8S)

Kubernetes这个单词来自于希腊语，含义是舵手或领航员。K8S是它的缩写，用“8”字替代了“ubernete”这8个字符。一个K8S系统，通常称为一个K8S集群（Cluster）。

API对象

对于云计算系统，系统API实际上处于系统设计的统领地位，API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作，例如副本集Replica Set对应的API对象是RS。理解掌握的API，就好比抓住了K8s系统的牛鼻子。

每个API对象都有3大类属性：

元数据metadata
规范spec
状态status。

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

集群管理(架构)

这个集群主要包括两个部分：

一个Master节点（主节点）
一群Node节点（计算节点）

如下图所示：

image

首先是Master节点。

Master节点结构

Master节点包括API Server、Scheduler、Controller manager、etcd。

API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。
Scheduler负责对集群内部的资源进行调度，相当于“调度室”。
Controller manager负责管理控制器，相当于“大总管”。
Etcd 所有master的持续状态都存在etcd的一个实例中，可Zookeeper作用类似。这可以很好地存储配置数据。因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。用人话来讲etcd是一个高可用强一致性的集群化管理服务

在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。

然后是Node节点：

Node节点结构

Node节点包括Pod、Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选）。

Pod，Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。
Docker，创建容器的。
Kubelet，主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。
Kube-proxy，主要负责为Pod对象提供代理。
Fluentd，主要负责日志收集、存储与查询。

Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁以及实现软件模式的负载均衡器。

Kubernetes组件概念

Service

除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。

Service是分布式集群架构的核心，一个Service对象拥有如下关键特征：

拥有一个唯一指定的名字
拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
能够体统某种远程服务能力
被映射到了提供这种服务能力的一组容器应用上

Service的服务进程目前都是基于Socket通信方式对外提供服务，或者是实现了某个具体业务的一个特定的TCP Server进程。

虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint（IP+Port）访问点

但Kubernetes能够让我们通过服务连接到指定的Service上。有了Kubernetes内奸的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响我们队服务的正常调用。且服务的IP不会改变，十分方便。

Pod

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

容器提供了强大的隔离功能，所有有必要把为Service提供服务的这组进程放入容器中进行隔离，每个服务进程包装到相对应的Pod中，成为Pod中运行的一个容器，通信与文件共享更高效。

为了建立Service与Pod间的关联管理，Kubernetes给每个Pod贴上一个标签Label，比如运行MySQL的Pod贴上name=mysql标签，给运行PHP的Pod贴上name=php标签，然后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题。

Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为

长期伺服型（long-running）
批处理型（batch）
节点后台支撑型（node-daemon）
有状态应用型（stateful application）；

分别对应的小机器人控制器为

Deployment
Job
DaemonSet
PetSet

Replication Controller

它解决了传统IT系统中服务扩容和升级的两大难题。你只需为需要扩容的Service关联的Pod创建一个复制控制器Replication Controller简称（RC），则该Service的扩容及后续的升级等问题将迎刃而解。在一个RC定义文件中包括以下3个关键信息。

目标Pod的定义
目标Pod需要运行的副本数量（Replicas）
要监控的目标Pod标签（Label）

Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

副本集（Replica Set，RS）

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

Label

Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key于value由用户自己指定。Label可以附加在各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。

Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。
我们可以通过给指定的资源对象捆绑一个或者多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置等管理工作。

Label类似将不同的Pod或者Node加入不同群组，类比有Fabric联盟链的Topic/Fisco的群组，不同节点可以在同一个Topic中处理数据

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

Label Selector在Kubernetes中重要使用场景如下:
kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程
kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service岛对应Pod的请求转发路由表，从而实现Service的智能负载均衡
通过对某些Node定义特定的Label，并且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程可以实现Pod”定向调度“的特性

总结一下上文

如下图所示：

Kubernetes架构和组件

可以看到，图中字简单描述了K8S的架构以及上文提到的各个组件，Master节点中的api server, scheduler, rc, etcd, kubectl, 还要Node节点中的kubelet, kebe-proxy, pod和pod中的container容器(docker)

还记得各个组件的具体功能描述吗？

Master工作
- 用户提交Kubectl(Kubernetes control)控制容器在Pod中运行
- API Server是对外接口，把请求API对象存储在etcd（一致性集群消息服务）中
- etcd: api请求的消息通知服务，就像Fabric中的Zookeeper，快速察觉消息并通知集群的各个服务
- scheduler 扫描集群内部资源进行调度，分配机器
Node工作
- kubelet（kubernetes let) 顾名思义，监控、控制Node上的Pod，并找到Pod中需要运行的容器container在本机（scheduler分配的机器）上运行
- 用户提交Replication COntroller RC请求，设置Pod运行的数目，RC会监控集群的Pod，维持指定数目的Pod副本在运行。这是K8s集群最早保证Pod高可用API对象的机制
- 用户提交Service描述文件，Service是一组提供相同接口服务的Pod组成，Pod是最小的服务基本单位，Service由多个Pod与多个服务组成。
- Kube-proxy 顾名思义，和Nginx的代理类似，实现k8s的Service通信与负载均衡，他会建立Service对应每个Pod的请求转发路由表

总结

从K8s的系统架构、技术概念和设计理念，我们可以看到K8s系统最核心的两个设计理念：一个是容错性，一个是易扩展性。容错性实际是保证K8s系统稳定性和安全性的基础，易扩展性是保证K8s对变更友好，可以快速迭代增加新功能的基础。

K8s内容繁多，还没来得及看完所有的文档，实战内容可以在后续的学习笔记中补充完成。

引用：

2019-08-25

k8s官方中文文档 https://www.kubernetes.org.cn/kubernetes%e8%ae%be%e8%ae%a1%e7%90%86%e5%bf%b5

K8s介绍与docker集群实战 https://blog.csdn.net/skh2015java/article/details/80300562

十分钟了解Docker与k8s https://my.oschina.net/jamesview/blog/2994112

Etcd简介 https://blog.csdn.net/bbwangj/article/details/82584988

Zookeeper功能与工作原理 https://www.cnblogs.com/felixzh/p/5869212.html