API server:所有服务访问同一入口
controllerManager:维持副本的期望数目
shceduler:调度器,负责接收任务,选择合适的节点分配任务
etcd:键值对数据库 存储k8s集群的所有重要信息(持久化)
kubelet:直接跟docker交互实现容器的生命周期管理
kube proxy:负责写入规则至IPTABLES、IPVS实现服务映射访问的路径
COREDNS:可以为集群中的SVC创建一个域名IP的对应关系解析
DASHBOARD:给k8s集群提供一个B/S结构访问体系
INGRESS CONTROLLER:官方只能实现四层代理,INGRESS可以实现七层代理
FEDETATION:可以跨集群中心多k8s同一管理的功能
PROMETHEUS:提供一个k8s集群的监控能力
ELK:提供k8s集群日志统一分析介入平台
HTTP server:使用HTTP协议
raft:所有信息存到这里
WAL:如果你想更改数据,WAL会存储一下,并且定期进行完整备份
Store:WAL会把这些日志持久化到本地磁盘
-
Pod概念
- 自主式Pod
- 控制器管理的Pod
K8s不直接管理container,管理的对象是pod,pod一般一个中只有一个container,也可以有多个container,pod的网络是共享的
RC用来确保容器应用的副本数据始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收。在新版本的Kubernetes中建议使用RS来取代RC。
RS和RC没有本质的不同,只是名字不一样,并且RS支持集合式的selector
虽然RS可以独立使用,但一般还是建议使用Deployment来自动管理RS,这样就无需担心和其他机制的不兼容问题(比如RS不支持Rolling-update)
Horizontal Pod Autoscaling仅适用于Deployment和ReplicaSet,在V1版本中仅支持根据Pod的CPU利用率扩容。在vlalpha版本中,支持根据内存和用户自定义的metric扩缩容
StatefulSet为了解决有状态服务的问题
应用场景包括
- 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
- 稳定的网络标志,即Pod重新调度后其PodName和HostName不变基于Headless Service实现
- 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行,基于init containers来实现
- 有序收缩,有序删除
DaemonSet确保全部或者一些Node上运行一个Pod的副本,当有Node加入集群时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod
典型用法
- 运行集群存储daemon,例如在每个Node上运行glusterd、ceph
- 在每个Node上运行日志手机daemon,例如fluentd、logstash
- 在每个Node上运行监控daemon,例如Prometheus Node Exporter
Job负责批处理 任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束
Cron Job管理基于时间的Job即:
在给定时间点只运行一次
周期性地在给定时间点运行
-
网络通讯方式
kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中,这在GCE(Google Compute Engine)里面是现成的网络模型,Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群,就不能假定这个网络已经存在了。我们需要自己实现这个网络假设,将不同节点上的Docker容器之间的互相访问先打通,然后运行Kubernetes
同一个Pod内的多个容器之间:lo
各Pod之间的通讯:Overlay Network
Pod与Service之间的通讯:各节点的Iptables规则
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能再这些IP地址之间简历一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内
ETCD之Flannel提供说明:
- 存储管理Flannel可分配地IP地址段资源
- 监控ETCD中每个Pod的实际地址,并在内存中建立维护Pod节点路由表