Kubernetes 基本概念介绍

什么是Kubernetes？

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。

如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。

Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

使用Kubernetes可以：

• 自动化容器的部署和复制

• 随时扩展或收缩容器规模

• 将容器组织成组，并且提供容器间的负载均衡

• 很容易地升级应用程序容器的新版本

• 提供容器弹性，如果容器失效就替换它，等等...

cluster 

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

一组 node 需要被集中管理，统一叫一个cluster。

一个cluster有一个 master 和多个 node，每个 node 里面有一个kubelet用来服从master调度并管理 node本身。

下图展示一个典型的Kubernetes架构图。

使用特别的图标表示Service和Label：

• Pod

• Container（容器）

• Label()（标签）

• Replication Controller（复制控制器）

• Service（）（服务）

• Node（节点）

• Kubernetes Master（Kubernetes主节点）

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会完成如下两件重要的事情：

• 会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。

• 现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。这里有更多技术细节。

下述动画展示了Service的功能。

当一个 node 挂了时，上面的 pod 及 pod 里面的 container 也自然都挂了。为了死不掉，需要有个 pod 上层的抽象，pod 挂了，service 还在。service 通过如下几种方式暴露出来。

• ClusterIP (default)，cluser 的内网ip，只能此cluster内可见；

• NodePort，端口 NAT 到 cluster 外面；

• LoadBalancer，在 cluster 外面搞个 LB 并分配个外面可见的固定IP给LB；

• ExternalName，类似 CNAME 方式；

​

node

一个物理机器，或一个虚拟机（KVM类型，而不是容器类型），将虚拟机作为 node 一般是历史原因，或是为了彻底隔绝杜绝安全问题。

app containers 

一个 node 里面可以有一个或多个容器化的应用程序，即app container。可以简单认为就是docker容器。

pod

多个 app containers 之间可能需要共享硬盘，或共享同一个ip，这样一组app containers合起来叫一个 pod。典型应用如：一个容器不停产生日志到本地硬盘，另一个容器不停读本地硬盘并上传日志到日志服务器。

deployment

配置 yaml 格式，存在 master 上，当机器故障或需要横向 scale 时或需要更新 binary 时，master 根据配置搞定一切。

一张图总结下