K8S组件

APISERVER 所有服务访问统一入口

ReplicationController（RC） 用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收。

在新版本中的kubernetes中建议使用replicaSet来取代ReplicationController.

ReplicaSet（RS） 跟ReplicationController没有本质区别，只是名字不一样，而且ReplicaSet支持集合式的selector

虽然ReplicaSet 可以独立使用，但一般还是建议使用Deploryment来自动管理ReplicaSet ，这样就无需担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update 但 Deployment支持）

Horizontal Pod Autoscaling（HA） 仅适用于Deployment 和 ReplicaSet ,在V1版本中仅支持根据Pod 的CPU利用率扩容，在vlalpha版本中，支持根据内存和用户自定义的metric扩缩容。

StatefulSet 是为了解决有状态服务的问题（对应Deployments 和 ReplicaSets 是为无状态服务而设计），其应用包括：

• 稳定的持久化存储，即Pod重新调度后还是能访问到相同持久化数据，基于PVC来实现
• 稳定的网络标志，即Pod重新调度后，其PodName和Hostname不变，基于Headless Service （即没有Cluster IP的Service）来实现
• 有序部署，有序扩展，即pod是有序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个pod运行之前所有之前的pod都必须是Running和Ready状态），基于init containers 来实现
• 有序收缩，有序删除（即从N-1 到 0）

DaemonSet 确保全部（或一些）Node上运行一个Pod副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群中移除时，这些pod也会被回收。删除DaemonSet将会删除它创建的所有pod。
使用DaemonSet的一些典型用法：

• 运行集群存储daemon，例如在每个Node上运行 glusterd、ceph。
• 在每个Node上运行日志手机daemon,例如fluentd、logstash。
• 在每个Node上运行监控daemon，例如Prometheus Node Exporter

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束
Cron Job 管理基于时间的job，即：

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

Scheduler 负责介绍任务，选择合适的节点进行分配任务

ETCD 键值对数据库 存储K8S集群所有重要信息（配置信息持久化）

Kubelet 直接跟容器引擎交互实现容器的生命周期管理

Kube-proxy 负责写入规则 到 iptables ipvs 实现服务映射访问

CoreDNS 可以为集群中的SVC 创建一个域名IP的对应关系解析

DASHBoard 给K8S 集群提供一个B/S结构访问体系

Ingress Controller 官方只能实现4层代理，Ingress可以实现7层代理

Federation 提供一个可以跨集群中心的K8S统一管理功能

promethus 提供K8S集群的监控能力

ELK 提供 K8S 集群日志统一分析介入平台

K8S的网络通讯

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

同一个pod内的多个容器之间：lo
各pod之间的通讯：overlay network
pod与service之间的通讯：各节点的IPtables规则

Flannel是CoreOS团队针对k8s设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些ip之间建立一个覆盖网络（overlay network），通过这个覆盖网络，将数据包原封不动的传递到目标容器内

etcd 之 flannel提供说明：

• 存储管理flannel可分配的ip地址段资源
• 监控etcd中每个pod的实际地址，并在内存中建立维护pod节点路由表

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

pod1 到 pod2

• pod1 与 pod2 在同一台机器，由docker0网桥直接转发请求至pod2，不需要经过flannel

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

• pod至service的网络：目前基于性能考虑，全部为iptables（现在使用lvs，性能更高）维护和转发
  pod 到外网：pod 向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，IPtables执行masquerade,把源ip更改为宿主机网卡的ip，然后向外网服务器发送请求

• 外网访问pod：service