k8s基础概念

这里我们先简单了解一下什么是pod，资源清单，控制器类型，k8s网络通讯模式等等，以及重点掌握的知识点，后面的话会进行详细的实验介绍。

那什么是pod呢？在我们k8s里面它是最小的封装集合，在我们容器化里的每一个运行的容器就是一个封装集合，那一个pod里面会封装多个容器，达到一个子节点的运行环境，它是我们k8s里面管理的最小单位。

资源清单：资源，掌握资源清单的语法，编写pod，掌握pod的生命周期（这个很重要）

pod控制器：掌握各种控制器的特点以及使用定义方式

（pod控制器用通俗的话来讲就是，我们本来有四盆花，我们心中的理想的状态就是四盆花，但是突然有一天，有一盆花死了，那么我们的pod控制就可以把这个死的踢掉，然后再去“买”一盆，把这个四盆花补全，达到我们心中理想的状态，这个就是pod控制器的功能）

server发现：掌握SVC（服务发现）原理及其构建方式。

（通俗来讲，我们开始的时候运行了很多的pod，是通过我们控制器运行的pod，这些pod其实是没法提供给我们的客户端去访问的，这些客户端可能是一组服务，也可能是一个用户，但是由于我们k8s集群里面都是一些私有的IP地址，无法提供给这些客户端去访问。。我们可以通过服务发现，把这些服务暴露给我们的客户端，这样我们的客户端就可以根据我们的暴露地址加端口的方式访问我们多个pod。例如我们上面提到的四盆花，我们给他们定义一个统一的访问入口，如果我们的用户想要访问这些“花”，我们只需要访问到这个统一的入口即可）如下图：

扩展

服务分类：

有状态服务：生活中的示例就是，一个人开始的时候进行的是某一个项目的工作，但是由于出现意外的情况，需要停止手头上的工作去做另外的工作，当把另外的工作完成之后，又回来执行当初的工作，由于时间的过去，项目的工作已经进行了一部分，此时不能够继续执行当初的工作。。。。DBMS（数据库管理系统）

无状态服务：生活中的示例就是，一个人开始的时候进行的是某一个项目的工作，但是由于出现意外的情况，需要停止手头上的工作去做另外的工作，当把另外的工作完成之后，又回来执行当初的工作，还是能够继续执行当初的工作。。。。LVS（调度器） APACHE（阿帕奇）

存储：掌握多种存储类型的特点，并且能够在不同的环境中选择合适的方案

调度器：掌握调度器的原理，能够根据要求把pod定义到想要的节点运行。

安全：集群的认证，鉴权，访问控制，原理以及其流程。

HELM：相当于Linux的yum管理器（我们可以通过简单的命令就可把对于的服务去安装，但是我们yum安装的是rpm包，而我们的HELM安装的是一个集群，我们只需要一个命令就可以把集群部署到我们的k8s中），掌握HELM原理，模板自定义，通过HELM部署一些常用的插件。

 关于网络

Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平的网络空间中，这在GCE （ Google Compute Engine ）里面是现成的网络模型， Kubernetes 假定这个网络已经存在。而在私有云里搭建 Kubernetes 集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的 Docker 容器之间的互相访问先打通，然后运行 Kubernetes。

k8s中的网络通讯

1.  同一个 Pod 内的多个容器之间： lo（localhost）

（我们上面那三个容器之间是怎么访问的呢，我们之前也说过，只要是同一个pod，他们会共用一个pause容器的网络栈，他们三之间的访问走的就是这个网路栈的lo虚拟网卡，通过localhost的方式）。。。

2. 各 Pod 之间的通讯： Overlay Network（全覆盖网络）

3. Pod 与 Service 之间的通讯：各节点的 Iptables （或者lvs）

网络插件flannel

Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务，简单来说，它的功能是

让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。而且它还能在

这些 IP 地址之间建立一个覆盖网络（ Overlay Network ），通过这个覆盖网络，将数据包原封

不动地传递到目标容器内部。

分析：上图运行着四个pod（web app2,web app1,web app3，Backend）,我们的Backend是一个前端组件，他们四个之间的关系是如下图：

（这里我们需要知道一个事情就是web app2和web app1是同主机通讯，和web app3，Backend是跨主机通讯，还有就是我们的k8s可以让同一个服务跑在不同的主机之上）

我们的所有的流量都访问到Backend上，然后Backend经过自己的网关去处理，把什么样的请求分配到什么样的服务上（也就是哪个web app），也就是说，我们的Backend想要跟某个web app去建立通讯，例如说跟web app2,那么此时就需要跨主机了，若跟web app3,那就是同主机的了，如何解决这两种情况呢？？？如下分析：

首先在我们的真实的node服务器上会创建一个Flanneld的守护进程，这个进程会监听一个端口，这个端口的作用就是用于后期转发数据包和接收数据包的一个服务端口，这个Flanneld守护进程一旦启动之后，会开启一个Flannel0的网桥，这Flannel0网桥专门收集docker0转发出来的数据报。这个docker0会分配自己ip到对应的pod上。若我们是同一台主机的不同pod的话，它们之间的通讯方式通过docker0的网桥，如下图所示：

那么不同的主机是如何进行通讯的呢？？

假设我们的web app2想要把数据发送到我们的Backend上，它的数据包的源地址就写自己的（这里是10.1.15.2/24），目标写10.1.20.3/24，由于目标的网段跟源网段不是同一个网段。所以，我们源的操作是把它的数据报发送到docker0的网关，docker0上有对应的钩子函数（hook）把数据报抓到我们的Flannel0，Flannel0会有一堆的路由表记录，这个路由表记录是从etcd中获取到的，用于判断到底路由到哪台机器。。。由于Flannel0是我们FlannelD开启的一个网桥，所以数据包会到Flanneld，到Flanneld会对我们的数据包进行封装，封装的方式就是

 由于上图的目标地址是192.168.6.12那么就会转发到如下的

并且转发的端口一定是FlannelD（上图）的端口，所以就会被FlannelD截获，并且拆封，然后转发到Flanneld0，Flanneld0转发到docker0，docker0会转发到Backend端。这里要想明白的话，需要对我们的iptables的四链五表有一定的认识，这个我们后边会学习到。

ETCD 之 Flannel 提供说明：

> 存储管理 Flannel 可分配的 IP 地址段资源

(也就意味着，我们的Flannel 启动之后，会向etcd去插入可以被分配的网段，并且把哪个网段分配到哪台机器上，也要记录上，防止这个网段再次被Flannel 利用分配给其他的节点，避免出现ip冲突)

> 监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod

（为什么要维护pod路由表？？？我们在封装的时候，怎么知道封装的目标地址是哪个，而且这个目标地址得是主机的地址，不能是Backend的那个10.1.20.3/24，而我们的pod路由表就是把10.1.20.3/24和主机地址192.168.66.12联系起来的）

总结：

同一个 Pod 内部通讯：同一个 Pod 共享同一个网络命名空间，共享同一个 Linux 协议栈。

不同的pod之间通讯，例如：Pod1 至 Pod2

> Pod1 与 Pod2 不在同一台主机， Pod 的地址是与 docker0 在同一个网段的，但 docker0 网段与宿主机网卡是两个完全不同的 IP 网段，并且不同 Node 之间的通信只能通过宿主机的物理网卡进行。将 Pod 的 IP 和所在 Node 的 IP 关联起来，通过这个关联让 Pod 可以互相访问

> Pod1 与 Pod2 在同一台机器，由 Docker0 网桥直接转发请求至 Pod2 ，不需要经过 Flannel。Pod 至 Service 的网络：目前基于性能考虑，全部为 iptables 维护和转发。。。这个是比较旧的方式，最新的方式通过lvs的方式。。。

> Pod 到外网： Pod 向外网发送请求，查找路由表 , 转发数据包到宿主机的网卡，宿主网卡完成路由选择后， iptables 执行 Masquerade（SNAT源地址转换） ，把源 IP 更改为宿主网卡的 IP ，然后向外网服务器发送请求。。。

外网访问 Pod ：service的NodePort方式，暴露端口的方式 。

在我们的k8s种有以下三层网络，真实的物理网络只有节点网络。其余都是虚拟网络。