k8s架构及核心组件

Kubernetes设计目标

• 集中管理所有容器
• 资源编排
• 资源调度
• *资源隔离
• 弹性伸缩

etcd:它是一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。

高可用集群副本数据最好是 >=3 的奇数个

master节点：

api server:所有服务访问的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。

controller Manager:维持副本期望数目

Scheduler:负责接收任务，选择合适的节点进行分配任务，为新建的Pod选择一个Node节点，可以任意部署，可以部署在同一节点上，也可以部署在不同的节点上。

etcd:键值对数据库，存储k8s集群的所有重要信息（持久化）

node节点：

kubelet：是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作，kubelet将每个Pod转换成一组容器。

kube-proxy:实现Pod网络代理，维护网络规则和四层负载均衡工作，负责写入规则至IPtables、IPVS实现服务映射访问

其他组件：

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

Dashboard:给k8s集群提供一个B/S结构访问体系

Ingress controller：官方只能实现四层代理，Ingress可以实现七层代理

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

Prometheus:提供K8S集群的监控能力

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

Pod

在一个pod中的容器即共享网络也共享存储卷

• Pod类型
• 自主式Pod
• 控制器管理的Pod

控制器类型

ReplicaSet：确保预期的Pod副本数量
Deployment:无状态应用部署
StatefulSet: 有状态应用部署
DaemonSet:确保所有Node运行同一个Pod
Job：一次性任务
Cronjob:定时任务

• ReplicationController (RC)& ReplicatSet(RS) & Deployment

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

  ReplicatSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicatSet支持集合式的selector

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

• HPA(HorizontalPodAutoScale)

  Horizontal Pod AutoScaling仅适用于Deployment和ReplicaSet,在v1版本中仅支持根据Pod的CPU利用率扩缩容，在V1a1pha版本中，支持根据内存和用户自定义的metric扩缩容

• StatefulSet

  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

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

  使用DaemonSet的一些典型用法：

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

• Job,Cronjob

  Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束

  Crontab Job管理基于时间的Job，即：

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

Service

• 防止Pod失联
• 定义一组Pod的访问策略

网络通讯方式

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

同一个Pod内的多个容器之间：lo

各Pod之间的通讯：Overlay Network

Pod与Service之间的通讯：各节点的iptables规则

• 网络解决方案 Kubernetes+Flannel

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

ETCD之Flannel提供说明：

（1）存储管理Flannel可分配的IP地址段资源

（2）监控ETCD中每个Pod的实际地址，并在内存中建立维护Pod节点路由表

不同情况下网络铜通讯方式：

• 同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈（pause的协议栈）
• 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,把源IP更改为宿主机网卡的IP，然后向外网服务器发送请求。
• 外网访问Pod：通过Service方式