Updated on Kubernetes

什么是Kubernetes？

1、什么是Kubernetes？

Kubernetes是Google开源的一款容器编排工具，它是诞生在Google内部运行N多年的博格系统之上的产物，因此其成熟度从其诞生初期就广泛受到业界的关注，并且迅速成为编排工具市场的主流，其社区活跃度非常高，版本迭代速度也很惊人，它的主要作用是对Docker容器做编排工作，当然，Docker只是容器工具的一种引擎，K8s可支持多种容器引擎，但从目前来说Docker容器引擎是具有绝对优势的，容器需要编排，也很容易理解，因为我们最核心要跑到业务通常都是LNMT/P的不同形式的扩展，但NMT/P他们的运行是有先后顺序的，也就是说MySQL要先启动，然后是Tomcat或PHP，最后是Nginx，而控制这种顺序就需要有容器编排工具来帮我们实现，另外，我们的业务希望7×24小时在线，如何保障？靠人是很难做到实时的，但编排工具可以，K8s帮我们实现了很多控制器，这控制器可以帮我们监控容器运行的状态，并自动帮我们重建(在容器时代重启就是重建)容器，并且还可以在容器处理能力不足时，自动根据我们定义的扩展规则，自动创建新Pod(k8s中最小单元,每个Pod中可有一个或多个容器)，并且在压力下去后，自动删除Pod等等功能。

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

使用Kubernetes可以：

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

实际上，使用Kubernetes只需一个部署文件，使用一条命令就可以部署多层容器（前端，后台等）的完整集群：

$ kubectl create -f single-config-file.yaml

下面我们来讲一讲Kubernetes的一些基本概念，方便辅助理解Kubernetes。

2、Kubernetes集群

通俗讲：集群就是一组节点，这些节点可以是物理服务器或者虚拟机，之上安装了Kubernetes平台。下图展示这样的集群。注意该图为了强调核心概念有所简化：

img

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

  • Pod
  • Container（容器）
  • Labels（标签）
  • Replication Controller（复制控制器）
  • Service（服务）
  • Node（节点）
  • Kubernetes Master（Kubernetes主节点）

3、Pod

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

  • 如果Pod是短暂的，那么我怎么才能持久化容器数据使其能够跨重启而存在呢？ 是的，Kubernetes支持卷的概念，因此可以使用持久化的卷类型。
  • 是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么？可以手动创建单个Pod，但是也可以使用Replication Controller使用Pod模板创建出多份拷贝，下文会详细介绍。
  • 如果Pod是短暂的，那么重启时IP地址可能会改变，那么怎么才能从前端容器正确可靠地指向后台容器呢？这时可以使用Service，下文会详细介绍。

img

在Kubernetes中，所有对象都使用manifest（yaml或json）来定义，比如一个简单的nginx服务可以定义为nginx.yaml，它包含一个镜像为nginx的容器：

apiVersion: v1
kind: Pod
metadata: 
name: nginx 
labels: 
app: nginx
     spec: 
          containers: 
          - name: nginx 
            image: nginx 
            ports: 
          - containerPort: 80

3、Label

正如图所示，一些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应用到上面。

Label不提供唯一性，并且实际上经常是很多对象（如Pods）都使用相同的label来标志具体的应用。 Label定义好后其他对象可以使用Label Selector来选择一组相同label的对象（比如Service用label来选择一组Pod）。Label Selector支持以下几种方式：

  • 等式，如app=nginx和env!=production
  • 集合，如env in (production, qa)
  • 多个label（它们之间是AND关系），如app=nginx,env=test

4、Deployment

是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么，能否将Pods划到逻辑组里？

Deployment 可以确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Deployment 并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Deployment 会替换它，并保持总数为3。如下面的动画所示：

img

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

当创建Replication Controller时，需要指定两个东西：

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

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

注：有一些文档里面会把Replication Controller和DeployMent 混为一谈、其实两者最大的区别是：DeployMent是通过Replication Controller来部署pod的。

5、NameSpace

Namespace是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services,和deployments等都是属于某一个namespace的（默认是default），而 Node, PersistentVolumes等则不属于任何NameSpace。通俗讲：我们可以通过NameSpace来区分出测试环境、开发环境、生产环境；亮点在于各NameSpace之间互不影响、这就是NameSpace的好处。

6、Service

img

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

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

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

  • 会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。
  • 现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。

下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。

img

7、Kubernetes Master

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

Master 负责管理集群。 master 协调集群中的所有活动，例如调度应用程序、维护应用程序的所需状态、扩展应用程序和滚动更新。节点是 Kubernetes 集群中的工作机器，可以是物理机或虚拟机。 每个工作节点都有一个 kubelet，它是管理节点并与 Kubernetes Master 节点进行通信的代理。节点上还应具有处理容器操作的容器运行时，例如 Docker 或 rkt。一个 Kubernetes 工作集群至少有三个节点。

Master 管理集群，而 节点 用于托管正在运行的应用程序。

当您在 Kubernetes 上部署应用程序时，您可以告诉 master 启动应用程序容器。Master 调度容器在集群的节点上运行。 节点使用 Master 公开的 Kubernetes API 与 Master 通信。用户也可以直接使用 Kubernetes 的 API 与集群交互。

img

推荐文章