1.核心组件原理——pod核心原理1.1什么是pod？pod也可以理解为容器，是docker创建的容器，用来封装container的一个容器；pod是一个虚拟化的group，有自己的IP地址和hostname，使用namespace进行资源隔离，相当于一个独立的沙盒环境；pod相当于一个独立的主机，可以封装一个或多个容器（通常是一组相关的容器），内部容器之间的访问使用localhost。1.2pod是做什么用的？通常，在服务部署时，一个pod用于管理一组相关的服务（要么在一个pod中部署一个服务，要么部署一组相关的服务）。下图是部署了一组相关服务的结构图，其中C代表一个容器，下面的pod中有很多容器。如何理解一套相关的服务？如下图：有一个访问Nginx的请求，然后Nginx部署的容器将请求转发给web服务部署的容器，web再访问数据库，然后请求返回数据在转，最后返回给用户。因此，链式调用的调用链路上的服务称为相关服务的集合。1.3实现一个web服务集群，只需要复制多个pod副本，这也是k8s管理的高级点。如果k8s需要扩容或者缩容，只需要控制pod的数量即可。例如，在上面的部署模式中，服务集群复制了多个这样的Pod。1.4pod的底层网络和数据存储是如何进行的前面说过，pod内部的容器也是一个独立的沙箱环境，所以也有自己的ip和端口。如果内部容器仍然通过ip:port通信，相当于远程访问，所以性能会受到一定影响。如何提高内部容器之间的访问性能？暂停容器必须在创建pod的底层pod内部容器之前创建。pause有两个作用：共享网络和共享存储。每个服务容器共享pause存储，不需要自己存储数据，交给pause维护。pause也相当于这三个容器的网卡，所以它们之间的访问可以通过localhost访问，相当于访问本地服务，性能很高（就像本地几个虚拟机之间的ping）。2.ReplicaSet副本控制器2.1副本控制器的基本理解：管理和控制pod副本（服务集群）的数量，使其始终与预期的set数量一致。例如：replicas=3（创建3个replicas，这是提前设置的）当replicas设置为3时，replicacontroller会一直保证replicas的数量为3。因此，当一个pod服务宕机时（比如上面第三个pod），replicacontroller会立即重新创建一个新的pod，这样可以保证replicas的数量一直是预设的3个。2.2ReplicaSet和ReplicationController的区别ReplicaSet和ReplicationController都是replicacontroller，其中：相同点：两者都具有第2.1节中描述的功能。区别：标签选择器的功能不同。ReplicaSet可以使用标签选择器进行单选和复合选择；而ReplicationController只支持单选操作。这意味着什么？假设下面有两个不同机器上的Node节点，怎么知道它们的pod其实是一样的呢？答案是通过标签。给每个pod打标签（下图中key=value格式，app=web，release=stable，有两个选项，同一个pod副本有相同的label），所以replicacontroller可以通过labelselector选择器来选择一组的相关服务。一旦selector和pod的标签匹配，则表明pod被当前的replicacontroller控制，表明replicacontroller和pod之间的所有权关系。如下图，seletor指定app=web和release=stable为复合选择，只能使用ReplicaSet实现。如果使用ReplicationController，则只能选择一个，比如只匹配app=web标签。这样，下面三个pod就被这个replicacontroller管理了。可以看出ReplicaSet的功能更加完善，所以在新版本的k8s中，推荐使用ReplicaSet作为replicacontroller，而不是ReplicationController。3.Deployment部署对象3.1滚动更新ReplicaSet副本控制器可以永久保持pod副本的数量。但是项目的需求在不断的迭代更新，项目也在不断的发布版本。那么如何做服务更新呢？是否应该停止服务并部署新版本？当然不是，答案是使用滚动更新。就是重新创建一个pod（v2版本）来替换之前的pod（v1版本）。滚动更新怎么样？涉及到下面要说的部署模型。3.2Deployment模型单独的ReplicaSet不支持滚动更新，但是Deployment对象支持滚动更新，通常和ReplicaSet一起使用。需要滚动更新时的步骤：DeploymentcreatesanewReplicasetReplicasetrecreatesanewpod，所以它们之间存在层级关系。Deployment管理Replicaset，Replicaset维护Pod。更新时会删除旧的pod，不会删除旧版本的ReplicaSet，所以需要的时候可以回滚之前的状态。4.StatefulSet有状态服务的部署4.1引入定义思路：如果MySQL（有状态服务）采用容器化部署，会存在哪些问题？容器有生命周期。一旦宕机，数据很可能丢失。Pod也有生命周期。在部署Pod时，重启Pod集群副本也可能会导致数据丢失。所以对于k8s来说，Deployment是不能用来部署有状态服务的。通常，Deployment用于部署无状态服务。那么StatefulSet就是解决一个有状态服务容器化部署的问题。4.2如何理解有状态服务有状态服务有实时数据，需要存储在有状态服务集群中。如果某个服务在一段时间后被抽取出来重新加入到集群网络中，集群网络将无法使用无状态服务，没有实时数据需要存储在无状态服务集群中。如果某个服务拉出来，过一段时间再重新加入到集群网络中，对集群服务是没有影响的，因为它们不需要交互，不需要数据同步等等。4.3部署模型StatefulSet的部署模型与Deployment非常相似。比如下图中，实时数据是借助于一个PVC（存储相关）文件系统来存储的，所以下图是一个有状态服务的部署。当pod宕机后重新建立pod时，StatefulSet保证hostname不发生变化，保证数据不丢失。所以pod可以通过hostname关联（查找）之前存储的数据。
