Kubernetes学习笔记1——概览

1. k8s 基本概览

 Kubernetes (k8s) 是一种支持容器化应用自动部署、集群调度、灵活可扩展的开源平台，像 Docker 这类容器只是集成在 Kubernetes 中去部署容器的低级组件，除了 docker， k8s 还支持 rocket 容器技术，总的来说，它其实是一个大规模容器集群的管理平台，用于管理云平台中多主机的容器化应用，对这些应用合理编排以使得它们可以高效合作，下面是一些支持的具体行为（并不局限于下面这些）：

• 自动化部署和替换容器；
• 动态缩放容器；
• 组织容器群并提供它们之间的负载均衡；
• 轻松推出容器化应用的新版本；
• 提供容器化应用的快速恢复能力（比如容器挂掉后直接进行替换）；

其实，使用一个配置文件就可以部署一个多尝试容器的完整集群，生成这个配置文件的命令为：

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

k8s 提供了命令行工具 kubectl ，通过它可以和 k8s 进行交互。

2. 基本概念

2.1 集群

 k8s 同样有集群的概念，指一群安装了 Kubernetes 平台的节点（包含了物理机和虚拟机）形成的集群，下面是 k8s 的经典体系架构（仅突出显示了一些重要概念）：

上图主要包含了下面一些名词：

• Pods
• Containers
• Label(s)
• Replication Controllers
• Service
• Nodes
• Kubernetes Master

 集群中的每个节点可以是物理机也可以是虚拟机，它们作为 k8s 的 worker 进行工作（以前叫做“走狗”Minion），每个节点都将运行下面的 k8s 关键组件：

• Kubelet：主节点代理；
• kube-proxy：主要提供给Service使用代理到各个Pod（负载均衡）；
• Docker or Rocket：k8s 用于创建容器的容器技术；

 搞完上述的这些东西后，集群中还有一个节点称之为Kubernetes Master，有从节点也有主节点，那作为主节点总有点特权吧，kubernetes master 提供了集群的统一视图，并具有许多组件，如kubernetes api服务器（通过Restful的URL和集群通信），主节点也包含了用于创建Pod副本的Replication Controllers。

2.1.1 Pods

 Pods 是 k8s 中最小可部署的单元，它可以被计划性创建和管理，所有的东西都是基于 Pods，就算部署单独一个容器那它必定要部署它自己的 Pod。pods（绿箱）被调度到节点，并包含一组位于同一位置的容器和卷（磁盘）。同一个 Pod 中的容器可以共享网络命名空间（context），可以通过 localhost 来进行通信。有下面一些注意点：

• Pods 的生命周期很短，那在重启时，数据的持久化可以通过磁盘完成（k8s 支持 Volumes 的概念）；
• Pods 通常是不需要手动一个一个单独去创建的，可以使用 Replication Controller 借助 Pod 模板来搞出多个 Pod 副本；
• 由于 Pods 的生命周期很短，在重启后 IP 地址可能会变，那前端容器引用后端容器的接口可能会非常不可靠，这个问题需要使用 Service 来解决；

2.1.2 Labels

 有些 Pod 是标签的，标签是一个 key-value 的键值对，主要用于表达用户自定义的属性，比如在一个应用中通过标签和标识不同的层级，在前端 Pods 上贴上标签 tier=frontend, app=myapp，在后端的 Pods 上贴上标签tier=backend, app=myapp，可以使用“选择器”选择出带有特定标签的 Pods，然后将一些 Service 和 Replication Controllers 应用到这些 Pods 上。

2.1.3 Replication Controllers

 Replication Controllers 可以确保指定 Pod 特定数量的副本在任何时刻都在运行，如果想为一个 Pod 创建3个副本并持续的对它们进行监控，那就需要创建一个 Replication Controller，如果一个 Pod 挂掉那这个 Replication Controller 将会替换它以保持数目还是3，过程如下：

如果之前挂掉的 Pod 又活了那就出现4个 Pod 了，因此 Replication Controller 将会杀死其中一个以便总数为3，如果将副本的数目动态地改成5，那 Replication Controller 将会立刻启动2个新的 Pod 以便总数为5，当然也可以通过这种方式来砍掉 Pod 的规模。在创建 Replication Controller 的时候，需要指定2个参数：

• Pod Template：用于创建 Pod 副本的模板；
• Labels：Replication Controller 将会持续监测的Pod的标签；

2.1.4 Services

 由于 Pod 的生命周期很短，重启后怎么确保前端容器可以可靠引用后端容器（因为IP可能变了），这就需要 Service 了，Service 是一个定义了一系列 Pod 和获取这些 Pod 的凭证的抽象，Service 通过标签Labels来查找到Pod，由于Service是抽象的，所以上面 k8s 架构图中并不经常看到它，假设后端有2个Pod，定义了一个后端的Service取名为backend-service，标签为tier=backend, app=myapp，那后端的Service将会促进2件事：

• 将为该Service创建群集本地DNS条目，因此前端Pod只需对主机名backend-service进行DNS查找，这将解析为前端应用程序可以使用的稳定IP地址；
• 经过上一步骤，前端已经可以获取到backend-service的IP地址了，因为后端有2个Pod，具体获取的是哪个呢？此时backend-service将在两个后端Pod之间提供透明的负载平衡，并将请求转发给其中任意一个Pod，具体通过使用在每个节点上运行的代理（kube代理）来完成的。

具体的过程可以通过下面的gif来表示：

【注】

推荐的 k8s 学习路线