二、Kubernetes—基础概念
目录
一、Pod概念
1、Pod的类型
2、Pod控制器类型
3、服务发现
二、网络通讯方式
1、网络通讯模式
2、网络解决方案
3、不同情况下网络通信方式
一、Pod概念
kubernetes中的一切都可以理解为是一种资源对象，pod,rc,service,都可以理解是 一种资源对象。Pod是k8s调度的最小单元，其组成示意图如下：
由一个叫”pause“的根容器，加上一个或多个用户自定义的容器构造，pod里多个业务容器共享pod的Ip和数据卷。它们处在同一扁平化网络中，在同一个pod中的容器应注意开启的端口是否重复，避免端口冲突导致pod创建失败。
1、Pod的类型
Pod大致分为两类，一类自主式Pod，一类为控制器管理的Pod。
1） 自主式Pod
所谓自主式pod为由yaml文件来创建的pod，也就是pod自己去控制自己，防止pod被控制器杀死。
2）控制器管理的Pod
由控制器控制管理的Pod，比如Deployment、RS等。
2、Pod控制器类型
Pod控制器是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。
pod控制器有多种类型：
1）ReplicationController
ReplicationController用于确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。在新版本的Kubernetes中建议使用ReplicaSet来取代ReplicationController。
2）ReplicaSet
ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector。虽然ReplicaSet可以独立使用，但一般还是建议使用Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持滚动更新rolling-update但Deployment支持）
3）Deployment
Deployment为Pod和ReplicaSet提供了一个声明式定义（declarative）方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括：
- 定义Deployment来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
在Deployment升级的时候，不会立即删除ReplicaSet和其下的Pod，而是采用创建一个新的ReplicaSet，然后创建一个新版本Pod，删除旧ReplicaSet下的一个Pod，以此类推，直至升级所有的Pod为新版本。
4）HPA
HPA（Horizontal Pod Autoscaler）Pod自动弹性伸缩，K8S通过对Pod中运行的容器各项指标（CPU占用、内存占用、网络请求量）的检测，实现对Pod实例个数的动态新增和减少。
HPA仅适用于Deployment和ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩缩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容。
5）StatefulSet
RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的，而StatefulSet是什么？顾名思义，有状态的集合，管理所有有状态的服务，比如MySQL、MongoDB集群等。StatefulSet是为了解决有状态服务的问题（对应Deployment和ReplicaSet是为了无状态服务而设计的），其应用场景包括：
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现。
- 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要根据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running 和 Ready状态），基于init containers来实现。
- 有序收缩，有序删除（即从N - 1 到 0）
6）DaemonSet
DaemonSet确保全部（或者一些）Node上运行一个Pod的副本，当有Node加入集群时，也会为它们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
使用DaemonSet的一些典型用法：
- 运行集群存储daemon，例如在每个Node上运行glusterd、ceph。
- 在每个Node上运行日志收集daemon，例如fluentd、logstash
- 在每个Node上运行监控daemon，例如Prometheus Node Exporter
7）Job
Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或者多个Pod成功结束
8）CronJob
CronJob其实就是在Job的基础上加上了时间调度，我们可以：在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。这个实际上和我们Linux中的crontab就非常类似了。一个CronJob对象其实就对应中crontab文件中的一行，它根据配置的时间格式周期性地运行一个Job，格式和crontab也是一样的。
3、服务发现
service：服务，是一个虚拟概念，逻辑上代理后端pod。众所周知，pod生命周期短，状态不稳定，pod异常后新生成的pod ip会发生变化，之前pod的访问方式均不可达。通过service对pod做代理，service有固定的ip和port，ip:port组合自动关联后端pod，即使pod发生改变，kubernetes内部更新这组关联关系，使得service能够匹配到新的pod。这样，通过service提供的固定ip，用户再也不用关心需要访问哪个pod，以及pod是否发生改变，大大提高了服务质量。如果pod使用rc创建了多个副本，那么service就能代理多个相同的pod，通过kube-proxy，实现负载均衡。
二、网络通讯方式
1、网络通讯模式
Kubernetes的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行Kubernetes。
- 同一个Pod内的多个容器之间：lo
- 各Pod之间的通讯：Overlay Network
- Pod与Service之间的通讯：各节点的IPtables规则（IPVS）
2、网络解决方案
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
ETCD之Flannel提供说明：
- 存储管理Flannel可分配的IP地址段资源
- 监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表
3、不同情况下网络通信方式
1）同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈。
2）不同Pod之间通讯（Pod1至Pod2）
- Pod1与Pod2不在同一台主机：Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡运行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
- Pod1与pod2在同一台主机：由Docker0网桥直接转发请求至Pod2，不需要经过Flannel。
3）Pod至Service的网络：目前基于性能考虑，全部为iptables维护和转发。
4）Pod到外网：Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求。
4）外网访问Pod：service
组件通讯示意图如下所示：
Hello，大家好，我是菜鸟HSS，始终坚信没有天生的高手，更没有永远的菜鸟。专注于Linux云计算和大数据的学习和研究。欢迎扫码关注我的公众号「菜鸟自学大数据Hadoop」，本公众号一切分享、资源皆免费，希望能尽自己一己之力帮助到更多的朋友，同时自己的技术也能得到提升，达到一种双赢的效果。
