一、前世今生
二、知识图谱
三、组件说明
1、goole的Borglet(k8s的前身)
BorgMaster
负责调度Borglet
工作,为了保证高可用BorgMaster
有很多副本,一般副本数为奇数
(投票)。
访问方式有 configfile(borgcfg)
、command-line tools
、web browsers
几种。这几种访问方式都会接入BorgMaster
,然后再做分发任务。
任务分发由 secheduler
将任务写到Paxos
(google的键值对数据库)中,并且Borglet
会实时的在Paxos
中监听,如果有自己的请求,那会把这个请求取出来,处理这个任务。
2、k8s 组件
任务分发
kubectl、web UI 的请求发送到 api service,然后由 scheduler 将任务交给api service写到 etcd,scheduler 和 etcd 不会直接交互。replication controller 是维护副本数目的,一旦副本数不满足期望值,由rc来负责将多余的pod删除,或者添加缺少的pod。api service 是一切访问的入口。etcd(键值对数据库) 是整个集群的持久化方案,并且etcd 的官方将它定位成一个可信赖的分布式键值存储服务,它能够为整个分布式集群存储一些关键数据,协助分布式集群的正常运转。
etcd
推荐在 Kubernetes 集群中使用 Etcd v3,v2 版本已在 Kubernetes v1.11 中弃用
etcd的所有的数据都存在Raft,并且还有WAL(预写日志),每次更改都会记录到Entry,并且定时整理一个大版本的快照Snapshot。这样可以防止增量备份太多,还原的时候比较麻烦,所以采用了临时+完整的备份方案。并且它还会将数据和日志实时的写入到本地磁盘(Store)中。
node节点
kubelet 会和 docker 进行交互,创建对应的容器,维持pod的生命周期
cri(容器、运行环境、接口) 也就是docker的表现形式。
负载的组件通过 kube proxy 来完成的,也就意味着怎样实现pod与pod之间的访问,包括负载均衡,要借助 kube proxy,它的默认操作对象是 firewall,通过操作 firewall 来实现pod的映射。新版本还支持ipvs。
总结:
- APISERVER:所有服务访问统一入口
- CrontrollerManager:维持副本期望数目
- Scheduler::负责介绍任务,选择合适的节点进行分配任务
- ETCD:键值对数据库 储存K8S集群所有重要信息(持久化)
- Kubelet:直接跟容器引擎交互实现容器的生命周期管理
- Kube-proxy:负责写入规则至 IPTABLES、IPVS 实现服务映射访问的
- COREDNS:可以为集群中的SVC创建一个域名IP的对应关系解析
- DASHBOARD:给 K8S 集群提供一个 B/S 结构访问体系
- INGRESS CONTROLLER:官方只能实现四层代理,INGRESS 可以实现七层代理
- FEDERATION:提供一个可以跨集群中心多K8S统一管理功能
- PROMETHEUS:提供K8S集群的监控能力
- ELK:提供 K8S 集群日志统一分析介入平台
四、pod 概念
1、pod 分类
1)、自主式pod
一旦死亡,不能自动重新创建。
2)、控制器管理的pod
2、pod控制器类型
1)ReplicationController & ReplicaSet & Deployment
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。在新版本的 Kubernetes中建议使用 Replicaset来取代 ReplicationController
ReplicaSet 跟 ReplicationController 没有本质的不同,只是名字不一样, 并且 ReplicaSet 支持集合式的 selector。也就是给pod打标签,列如:app=Apache;version=v1 。当我们要删除pod的时候就,就可以通过 app=Apache;version=v1 来删除对应的pod。
虽然 Replicaset 可以独立使用,但一般还是建议使用 Deployment 来自动管理 ReplicaSet ,这样就无需担心跟其他机制的不兼容问题(比如 Replicaset 不支持rolling- update 但 Deployment 支持)
使用 Deployment 进行滚动更新。
2)HPA(HorizontalPodAutoScale)
Horizontal Pod Autoscaling仅适用于 Deployment 和 Replicaset,在V1版本中仅支持根据Pod的CPU利用率扩所容,在 vlalpha版本中,支持根据内存和用户自定义的 metric扩缩容。
配置最小2个pod,最多10个pod,当cpu达到80的时候,会自动新增pod,直到最大值10个。一旦cpu利用率变低之后,pod就会被回收,直到最小值2个。
3)StatefullSet
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)
4)DaemonSet
Daemon Set确保全部(或者一些)Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除 Daemon Set将会删除它创建的所有Pod
使用 Daemon Set的一些典型用法:
- 运行集群存储 daemon,例如在每个Node上运行 glusterd、ceph
- 在每个Node上运行日志收集 daemon,例如 fluent、 logstash
- 在每个Node上运行监控 daemon,例如 Prometheus Node Exporter
5)Job,Cronjob
Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束
Cron Job管理基于时间的Job,即:
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
3、pause
一个pod启动,就会有一个pause容器。在这个pod上的容器可以共用这个pause的网络栈、存储卷。也就意味着在同一个pod里,容器公用一个网络栈、存储卷。
五、网络通讯方式
1、网络通讯模式
Kubernetes 的网络模型假定了所有 Pod 都在一个可以直接连通的扁平的网络空间中,这在 GCE(Google Compute Engine)里面是现成的网络模型,Kubernetes 假定这个网络已经存在。而在私有云里搭建 Kubernetes 集群,就不能假定这个网络已经存在了。我们需要自己实现这个网络假设,将不同节点上的 Docker 容器之间的互相访问先打通,然后运行 Kubernetes
同一个 Pod 内的多个容器之间:localhost
各 Pod 之间的通讯:Overlay Network
Pod 与 Service 之间的通讯:各节点的 Iptables 规则
2、网络解决方案 Kubernetes + Flannel -1
Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟IP地址。而且它还能在这些 IP 地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内
3、网络解决方案 Kubernetes + Flannel -2
4、网络解决方案 Kubernetes + Flannel -3
ETCD 之 Flannel 提供说明:
存储管理 Flannel 可分配的 IP 地址段资源
监控 ETCD 中每个 Pod 的实际地址,并在内存中建立维护 Pod 节点路由表
5、不同情况下网络通信方式
-
同一个 Pod 内部通讯:同一个 Pod 共享同一个网络命名空间,共享同一个 Linux 协议栈
-
Pod1 至 Pod2
Pod1 与 Pod2 不在同一台主机,Pod的地址是与docker0在同一个网段的,但docker0网段与宿主机网卡是两个完全不同的IP网段,并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来,通过这个关联让Pod可以互相访问
Pod1 与 Pod2 在同一台机器,由 Docker0 网桥直接转发请求至 Pod2,不需要经过 Flannel 演示 -
Pod 至 Service 的网络:目前基于性能考虑,全部为 iptables 维护和转发
-
Pod 到外网:Pod 向外网发送请求,查找路由表, 转发数据包到宿主机的网卡,宿主网卡完成路由选择后,iptables执行Masquerade,把源 IP 更改为宿主网卡的 IP,然后向外网服务器发送请求
-
外网访问 Pod:Service