【01】Kubernets：捋一捋概念性东西

写在前面的话

docker 先告一段，现在开始进入 Kubernets（K8S） 的学习阶段，在学习过程中，可结合之前学的 docker swarm 比对着理解。

啥是 K8S

先来看一下两个 logo：

之前说过，docker 是 “码头工人”，而 K8S 则是 “舵手”，从这两个名字可以大致猜出他们的关系。

那 K8S 到底算是啥？这得从编排工具说起，之前学过了一个编排工具，swarm。

总而言之，编排工具就是能扩展管理容器，能实现跨主机通信，能指定容器运行关系，从而实现让复杂的程序运行简单的工具。

就目前而言，有几款比较出名的：

1. docker 本身的：docker machine + swarm + compose。

2. mesos + marathon：系统资源调度，能够调度 hadoop 或者容器，多以他并不算专业的容器编排工具。

3. Kubernets（K8S）：将容器归类，以 Pod 管理。属于业界标准。

和 docker 一样，K8S 也是 Go 语言开发的，由谷歌根据自己内部容器调度系统 Borg 重写。由此可以看出 Go 在未来的地位。

为啥选择 K8S：

1. 自动装箱，自动部署，保证服务可用性。

2. 自我修复，在某个容器 down 掉以后会自动启动新的。

3. 自动水平扩展，服务发现，负载均衡。

4. 自动发布，回滚。

5. 支持密钥和配置管理，能够将服务的配置通过服务来加载，而不用本地配置，保证了配置的一致性。

6. 存储编排和任务批处理。

其实这些说出来，很干涩，也很懵逼，后面慢慢通过实践来理解。

K8S 集群

在 K8S 集群中，由两种角色：Master 和 Node，这和 docker swarm 类似，Master 和 Worker，也可以将 Worker 叫做 Node。

Master 作为集群的总控制，这就意味着不能是单节点，得让他高可用，但现在是测试，我们还是将其部署为单节点。

Node 就是干活的节点，这个就是没啥数量限制了，大于 1 就行了。用于运行 Pod。

那啥是 Pod？Pod 是 K8S 能够调度的最小单位，而不是 docker 容器。Pod 是将一个或多个关系非常密切的容器打包在一起的集合。

而管理 Pod 怎么运行，运行多少个，使用多少资源，这些都是 Master 的活。

以搭建 LAMP 环境为例，这几个看似有很大的关系，但是他们关系又不是非常紧密，所以对于这种服务，一般将其拆开运行为 3 个 Pod。

K8S 内部通信一共需要 5 套证书：

1. etcd 内部通信需要 CA 和对应证书。

2. etcd 与外部通信需要 CA 和对应证书。

3. APIServer 间通讯需要一套证书。

4. APIServer 与 Node 通信需要一套证书。

5. Node 与 Node 间通信需要一套证书。

而这些证书，可以选择手动创建，也可以自动生成。

这里得说明一件事情：

K8S 真香，但这并不意味着我们的所有服务都适合在上面运行，为了便于维护，建议有状态的应用都单独运行，类似数据库这种。

看下一个通用的集群架构：

简单来说，Master 通过 API 来管理 Node 节点，Node 节点运行服务从 Registry 中拉取镜像。

然后再将 Master 和 Node 进行细化：

Master 和 Node

Master 有三个重要组件：

1. APIServer：请求入口，负责解析，处理请求，即网关。

2. Scheduler：调度器，请求到达后，计算 Node 的资源情况，将服务调度到适合的 Node，然后该节点的 Kubelet 启动和操作 Pod。

3. Controller-manager：控制管理器，统一管控资源，监控 Master 节点的健康状态，给 Master 节点做高可用。

Controller：控制器，用于创建启动 Pod。通过标签选择器（Label Selector）来关联 Pod，管理 Pod 的健康性，以确保 Pod 的运行数量为用户定义的。

每一组 Pod 都需要独立的控制器来运行，实现跨节点的自愈。

在 K8S 中，控制器一般有以下几种：

1. ReplicationController：严格控制 Pod 数量和更新的 Pod，在更新过程中会临时超出预定的 Pod 数量，支持回滚。

2. RelicaSet：声明更新控制器。

3. Deployment：负责无状态应用 Pod 控制，支持二级控制器。

4. StatefulSet：负责有状态 Pod 控制。

5. DeamonSet：守护进程集，在集群的每个 Node 上启动一个 Pod，如果 Pod 挂掉，会重新起一个，如果新增 Pod，会自动添加。

6. Job/Cronjob：周期性 Pod 控制，如定时任务。

Master 节点其他组件：

Label Selector：标签选择器，根据标签选择符合条件的资源对象机制，不仅用于 Pod 资源，所有对象都可以打标签，K/V 格式数据。Controller 可以根据这个标签识别 Pod 资源。

etcd：分布式高性能键值存储数据库，保存集群对象状态信息。apiserver 的所有操作都保存在这里，这意味着，这个服务挂了整个集群就瘫痪了。前面 docker 中用它来跨主机通信。

Node 节点有三个重要组件：

1. Kubelet：相当于 K8S 的 agent，有点像 Zabbix 的 agent。检测当前节点的健康状态，和 apiserver 交互。

2. Kube-proxy：为当前节点的 Pod 生成 iptables 或者 ipvs 规则将请求调度到 Pod。和 apiserver 进行通信，当自身改变或者 apiserver 发生改变都能做到及时更新规则。包含 3 个模型：userspace/iptables/ipvs。

3. Container engine：这里没有说 docker，是因为 K8S 不只是编排 docker，还有 RKT 这些。

逻辑组件

除了 Master 和 Node 的关键组件，还有一些逻辑组件：

Service：

Service 通过标签选择器（label selector）来关联 Pod，使得用户流量在导向后端 Pod 的时候能够有个固定的访问端点。配合 DNS Addons 实现把主机名和 Cluster IP 实现解析，使得可以通过主机名加端口的形式访问访问。

Service 在应用前面加了个代理层，该代理层的主机名对应的 IP 不变，由手动创建。如图：

以简单的 Nginx 代理后端 Tomcat 为例，那么 Nginx 里面配置 Tomcat 的 IP 就可以变更为 Tomcat 在代理层上面的主机名即可（因为 IP 也可能变）。代理层上通过 Service 来感知后端 Pod，所以即使 Pod 的 IP 发生改变也不影响，只要你 label 不变。

Service 相当于由 Kube-proxy 创建的 iptables 规则。在 K8S 1.11 版本之后，规则调整为 ipvs。但是 Service 也有可能被删除掉的可能性，为了确保服务能够正常被发现，又加了 DNS 服务，能够动态的解析。每次创建一个 Service 就会将名称和 IP 关系写入。删除同理。

因此，只要前端应用配置的是 Service 的主机名，那么即使服务重建，依旧能够找到。

当客户端发起请求，到达 Service，然后调度到不同的机器上，跨主机的通信采用的是叠加网络（overlay）。

每个应用的 Pod 都需要专有的 Service 来调度。

存储卷：

Pod 级别的卷，建议使用外部专用卷，而不是本地容器的卷。当容器重启时，需要挂载相同的卷。

存储卷包含 4 级概念：pv（持久卷），pvc（持久卷申请），volume（存储卷），volume mount（存储卷挂载）。

Pod：

容器集，一个 Pod 的所有容器运行在同一节点，K8S 调度的目标就是 Pod。跨 Pod 通信需要借助外部网络插件，每一个 Pod 有一个 Pod IP。一个 Pod 就像一个虚拟机。

K8S 的核心就在于运行 Pod，至于其他组件，也是为了保证 Pod 正常运行。

Pod 一般分为两类：

1. 自主式 Pod。

2. 控制器管理 Pod。

一个 Pod 上由两类元素据，Label 和 Annotation。

外部访问内部 Pod，需要经过转发：现在节点的 IP 和指定端口，然后转发到 Service 的 IP 和端口，最后转到 Pod 的 IP 和端口。

K8S 运行空间需要分区，用于区分不同项目，每一个逻辑分区为一个 userspace。用于隔离 Pod，提供管理边界。

K8S 通信

Service 和 Pod 地址不在同一网段，且 Service 地址为虚拟地址，不配置在网卡上。同一 Pod 中多个容器使用 lo 通信。

各 Pod 间通信使用 overlay 网络进行跨主机隧道通信。

Pod 和 Servce 通信：

CNI：容器网络集接口，有三种 IP，Node IP，Cluster IP，Pod IP。

Node IP：就是宿主机 IP 地址。

Cluster IP：集群 IP 地址，也就是 Service IP 地址。

Pod IP：Pod 的 IP 地址。使  Pod 间可直接通信。但是集群间的 Pod 通信需要借助 Cluster IP，和集群外通信还得借助于 Node IP。

虚拟化网络的插件：

flannel：简单易用，不支持网络策略和网络配置，为该主机的 Pod 提供 IP。

project calico：支持网络策略和配置，默认基于 BGP 构建网络，实现直接通信，三层隧道网络，是生产使用较多的模型。

canel：flannel + calico 的结合，flannel 提供网络，calico 实现策略。

其他都不常用。

小结

本节内容比较枯燥，先有个基本的概念，后面用到再回过头来对照着理解。