Kubernetes云计算分布式概念（一）

目录

Kubernetes入门及概念介绍 

Kubernetes平台组件概念

Kubernetes平台工作原理剖析

Pod概念

Node概念剖析

Kubernetes Master概念剖析

Lable概念

Replication Controller（复制控制器）

Service概念

---

Kubernetes入门及概念介绍 

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，可以将Docker看成Kubernetes内部使用的低级别组件。  换言之Kubernetes支持Docker。使用Kubernetes可以实现如下功能：

1. 自动化容器的部署和复制；
2. 随时扩展或收缩容器规模；
3. 将容器组织成组，并且提供容器间的负载均衡；
4. 很容易地升级应用程序容器的新版本；
5. 提供容器弹性，如果容器失效就替换它等。

Kubernetes平台组件概念

Kubernetes集群中主要存在两种类型的节点：master、node节点，node节点为运行 Docker容器的节点，负责和节点上运行的 Docker 进行交互，并且提供了代理功能。

1. Kubelect Master：Master节点负责对外提供一系列管理集群的API接口，并且通过和node 节点交互来实现对集群的操作管理。
2. Apiserver：用户和 kubernetes 集群交互的入口，封装了核心对象的增删改查操作，提供了 RESTFul 风格的 API 接口，通过etcd来实现持久化并维护对象的一致性。
3. Scheduler：负责集群资源的调度和管理，例如当有 pod 异常退出需要重新分配机器时，scheduler 通过一定的调度算法从而找到最合适的节点。
4. Controller-manager：主要是用于保证 replication Controller 定义的复制数量和实际运行的 pod 数量一致，另外还保证了从 service 到 pod 的映射关系总是最新的。
5. Kubelet：运行在 node节点，负责和节点上的Docker交互，例如启停容器，监控运行状态等。
6. Proxy：运行在 node节点，负责为 pod 提供代理功能，会定期从 etcd 获取 service 信息，并根据 service 信息通过修改 iptables 来实现流量转发（最初的版本是直接通过程序提供转发功能，效率较低。），将流量转发到要访问的 pod 所在的节点上去。
7. Etcd：etcd 是一个分布式一致性k-v存储系统数据库，可用于服务注册发现与共享配置储数据库，用来存储kubernetes的信息的,etcd组件作为一个高可用、强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，etcd的诞生就是为解决该问题。
8. Flannel：Flannel是CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，Flannel 目的就是为集群中的所有节点重新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。

 

Kubernetes平台工作原理剖析

Kubernetes集群是一组节点，这些节点可以是物理服务器或者虚拟机，在其上安装Kubernetes平台。

下图为了强调核心概念有所简化。Kubernetes架构图。

上图可以看到如下组件，使用特别的图标表示Service和Label：

1. Pod：​​​​​​​
2. Container（容器）；
3. Label（标签）；
4. Replication Controller（复制控制器）；
5. Service（服务）；
6. Node（节点）；
7. Kubernetes Master（Kubernetes主节点）；

Pod概念

Pod（上图绿色方框）安排在节点上，包含一组容器和卷。也称为容器。同一个Pod里的容器共享同一个网络命名空间，可以使用localhost互相通信，Pod是短暂的，不是持续性实体。

 

​​​​​​​Node概念剖析

Node节点（上图橘色方框）是物理或者虚拟机器，作为Kubernetes worker，通常称为node节点服务器，操作docker。每个节点都运行如下Kubernetes关键组件：

1. Kubelet：是主节点代理；
2. Kube-proxy：Service使用其将链接路由到Pod，如上文所述；
3. Docker或Rocket：Kubernetes使用的容器技术来创建容器。

node服务器通过调用kubelet中的config的KUBE_MASTER来和master进行关联及通信

 

Kubernetes Master概念剖析

Kubernetes集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角，并且拥有一系列组件，比如Kubernetes API Server。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。

管理node节点服务器、Replication Controller

 

Lable概念

如图所示，一些Pod有Label。一个Label是attach到Pod的一对键/值对，用来传递用户定义的属性。例如你可能创建了一个"tier"和“app”标签，通过Label（tier=frontend, app=myapp）来标记前端Pod容器，使用Label（tier=backend, app=myapp）标记后台Pod。然后可以使用Selectors选择带有特定Label的Pod，并且将Service或者Replication Controller应用到上面。

 

​​​​​​​Replication Controller（复制控制器）

是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么，能否将Pods划到逻辑组里？
Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。

如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3.如下面的动画所示：

如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时很有用。
当创建Replication Controller时，需要指定两个东西：

1. Pod模板：用来创建Pod副本的模板
2. Label：Replication Controller需要监控的Pod的标签。

现在已经创建了Pod的一些副本，那么在这些副本上如何均衡负载呢？我们需要的是Service。

 

​​​​​​​Service概念

如果Pods是短暂的，那么重启时IP地址可能会改变，怎么才能从前端容器正确可靠地指向后台容器呢？

Service是定义一系列Pod以及访问这些Pod的策略的一层抽象。Service通过Label找到Pod组。因为Service是抽象的，所以在图表里通常看不到它们的存在，这也就让这一概念更难以理解。

现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（tier=backend, app=myapp）。backend-service 的Service会完成如下两件重要的事情：

1. 会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。
2. 现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。这里有更多技术细节。
   下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。

​​​​​​​
有一个特别类型的Kubernetes Service，称为'LoadBalancer'，作为外部负载均衡器使用，在一定数量的Pod之间均衡流量。

无论内部pod如何变换，service会给予固定的集群IP，保证在pod变化时都可以通过集群IP访问。