一, Kubernetes 是 Google 团队发起并维护的基于 Docker 的开源容器集群管理系统, 它不仅支持常见的云平台, 而且支持内部数据中心.
建于 Docker 之上的 Kubernetes 可以构建一个容器的调度服务, 其目的是让用户透过 Kubernetes 集群来进行云端容器集群的管理, 而无需用户进行复杂的设置工作. 系统会自动选取合适的工作节点来执行具体的容器集群调度处理工作. 其核心概念是 Container Pod. 一个 Pod 由一组工作于同一物理工作节点的容器构成. 这些组容器拥有相同的网络命名空间, IP 以及存储配额, 也可以根据实际情况对每一个 Pod 进行端口映射. 此外, Kubernetes 工作节点会由主系统进行管理, 节点包含了能够运行 Docker 容器所用到的服务.
二, 架构模型为 master/nodes(work)
可以理解 master 为蜂后, nodes 为工蜂(干活的)
master 为集群唯一入口, 需要做高可用.
每一个 node 节点都提供一部分计算能力和存储能力.(运行容器的节点)
请求过程:
1 客户端请求 (创建启动容器) 首先发往 master,master 当中有一个调度器, 会去分析各 node 节点的资源状态.
2 找一个最佳适配运行用户所请求的容器的节点, 并把它调度上去, 由这个 node 的 docker 或是其他容器引擎来负责把这个容器启动起来.
3 启动容器时检查本地是否有镜像, 如果没有需要从镜像仓库中 pull 来启动(镜像仓库可以是云上的, 也可以是自检的私有仓库, 也可以以容器运行在 node 节点上).
三, Master 集群组件
API Server 接收并处理用户请求
Scheduler 调度容器创建的请求
- ### 两级调度
- #### 第一步: 先做预选
1. 评估各 node 有几个是符合需求的
#### 第二部: 再做优选
2. 再从符合需求中的几个选出最优的(优选算法)
> 负责观测每一个 node 之上总共可用的计算和存储资源, 并根据用户所请求创建的容器所需要的资源量来评估
controller-manager 确保已创建的容器处于健康状态
控制器管理器是确保控制器健康的, 控制器是用来确保容器健康的.
label selector 可以通过控制器给 pod 打标签, 之后控制器可以根据 tag 来识别出 pod
创建 pod 时可以给 pod 直接打上一个标签, 然后让控制器通过标签的值来识别出 pod 来
四, Node 集群组件
kubelet 与 apiserver 交互运行的, 接收并处理 master 调度过来的各种任务.
docker 运行 pod 中的容器
在 K8s 上运行的最小单元不是容器, 而是 pod
kubernets 并不直接调度容器, 而是调度 pod,pod 是对容器的一层封装.
pod 里可以有多个容器, 他们共享同一网络协议栈, 存储卷
一般一个 pod 只有一个容器
kube-proxy 与 apiserver 进行通信, 每一个 pod 发生变化, 结果是需要保存到 apiserver 中, apiserver 会生成一个通知事件, 该事件可以被任何关联的组建所接收到, 管理 service,service 的创建及变动是依靠 kube-proxy 在 iptables 上创建出规则
Pod 简介
pod 中的每一个容器有自己的 user,mnt,pid 的名称空间, 然后他们共享 pod 的 net,uts,ipc 的名称空间.
一般一个 pod 中只有一个容器, 除非容器之间有特别特别紧密的关系需要放在同一 pod 中, 如果一个 pod 放置了多个容器, 通常有一个为主容器, 其他容器来辅助主容器上的应用程序完成更多功能来实现.
创建 pod 时可以给 pod 直接打上一个标签, 然后让控制器通过标签的值来识别出 pod 来
由于 pod 为 kubernet 集群中的原子单元, 是不可再分割的, 一个 pod 中无论是一个容器还是多个容器, 当 pod 被 master 调度至某一 node 上时, 这个 pod 中的所有容器都被调度到了一台 node 上
自主式 Pod
自我管理, 创建后仍然要提交给 apiserver, 由 apiserver 将其调度至指定的 node 的节点, 由 node 启动此 pod, 如果一个 pod 中的容器出现故障, 需要重启容器, 需要又 kubelet 来完成. 但是, 如果节点故障了, 该容器就消失了. 无法实现全局进行调度.
控制管理的 Pod
正是有控制器机制的引入使得 pod 成为有生命周期的对象, 而后由调度器将其调度至集群中的某节点运行以后, 有一些任务作为守护进程运行为 pod 或容器, 要确保它们随时处于运行状态, 一旦发生故障, 要随时重启它或者替代它.
pod 控制器种类
Replication Controller
多退少补, 必须精确符合人定义的期望
滚动更新(类似用户无感知发布)
回滚
ReplicaSet
Deployment 只能管理无状态应用
StatefulSet 管理有状态的应用
DaemonSet 每个 node 上运行一个副本, 而不是随意运行
Job,Cronjob 运行作业或者周期性作业
有些任务是临时需要而运行, 运行完以后结束, 这种不需要一直处于运行状态, 可以运行为一个 job
HPA(HorizontalPodAutoscaler) 自动监控并系统负载分析添加或减少 pod
服务发现功能
每重新生成一个 pod 都是一个全新的 pod, 比如 ip 地址和主机名之前的是不一样的.
kubernets 为每一组提供同类服务的 pod 和它的客户端之间添加了一个中间层, 这个中间层 (service) 是固定的, service 再将客户端请求端口代理至后端 pod 上(通过 dnat 规则 ), 一旦其中一个 pod 宕机了, 一个新的 pod 会立即被关联上来(通过标签选择器, 具有相同标签的来关联起来), 然后在动态探测新关联的 pod 的 ip 地址和主机名,
五, k8s 网络模型
pod 网络. 各 pod 运行在同一个网络, pod 的网络地址是真实的地址, 存在于它的网络名称空间当中.
service 网络(集群网络).service 地址不是真的地址, 存在于 iptables 中或者 ipvs 规则中.
节点网络 .
六, k8s 通信分类
同一 pod 内的多个容器间: lo 网络
各 pod 之间通信.(overlay network, 叠加网络)
各 pod 之间直接通信, 无论 pod 运行在哪个节点之上, 各 pod 的地址是不应该也绝对不可以相同.
pod 与 servic 之间通信
service 地址只不过是主机上的一条 iptables 规则中的地址, 所以需要配置一下目标地址不是自己的指向网关. 每个主机上都应该有所有的 service 的地址规则. 当 pod 试图访问 service 的地址时, 首先将请求送给网关(一般为 docker0 桥), 然后 docker0 桥通过内核发现当前访问的地址为一条 iptables 或 ipvs 规则, 然后将请求送达.
之前说过, 当 service 后端的 node 节点宕机, pod 的控制器通过标签选择器会自动创建一个新的 pod 并加入至该服务中, 而 node 中的另一个组件, kube-proxy 在此时会将 service 的变动存储在 master 上的 API server 中, 然后 API server 生成通知事件, 又 kube-porxy 将 iptables 规则的变化反映至每一个节点的 iptables 规则上.
七, etcd k8s 的存储
Etcd 是 Kubernetes 集群中的一个十分重要的组件, 用于保存集群所有的网络配置和对象的状态信息.
存储集群的所有变化信息以及网络配置, 非常重要, 所以需要做高可用.
八, k8s 集群组成要件
如图所示, 每一个服务都有一个 service, 用来调度请求流量. 如果其中的某个服务中的 pod 宕机了, pod 控制器会自动创建一个新的 pod 并加入到该服务中. 不同的 pod 的控制器通过 pod 标签来管理其所属的 pod. 当然 k8s 集群内部也是需要主机名来表示不同的主机的, 提供 dns 服务的也是通过 pod, 同样的它也有一个 service, 也有一个 pod 控制器来管着的 dns 的 pod.
总结.
画了个图总结一下整个的 k8s 集群, 如下.
喜欢我写的东西的朋友可以关注一下我的公众号, 上面有我的学习资源以及一些其他福利.:Devops 部落
来源: http://www.jianshu.com/p/15ed0984ba77