kubernetes,简称K8s,是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。
传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定,这样做并不利于应用的升级更新/回滚等操作,当然也可以通过创建虚拟机的方式来实现某些功能,但是虚拟机非常重,并不利于可移植性。
新的方式是通过部署容器方式实现,每个容器之间互相隔离,每个容器有自己的文件系统 ,容器之间进程不会相互影响,能区分计算资源。相对于虚拟机,容器能快速部署,由于容器与底层设施、机器文件系统解耦的,所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快,每个应用可以被打包成一个容器镜像,每个应用与容器间成一对一关系也使容器有更大优势,使用容器可以在build或release 的阶段,为应用创建容器镜像,因为每个应用不需要与其余的应用堆栈组合,也不依赖于生产环境基础结构,这使得从研发到测试、生产能提供一致环境。类似地,容器比虚拟机轻量、更“透明”,这更便于监控和管理。
kubernetes高可用集群的典型架构 kubernetes github
组件 ### 控制面组件: etcd:多实例并行运行,通过Raft保证一致; apiserver:多实例并行运行; controller-manager:多实例仅有1个节点active; scheduler:多实例仅有1个节点active; ### 工作节点组件: kubelet kube-proxy ### 注: 1. apiserver多实例运行: apiserver是无状态的,所有数据保存在etcd中,apiserver不做缓存。apiserver多个实例并行运行,通过Loadbalancer负载均衡用户的请求。 2. scheduler和controller-manager单实例运行: scheduler和controller-manager会修改集群状态,多实例运行会产生竞争状态。通过--leader-elect机制,只有领导者实例才能运行,其它实例处于standby状态;当领导者实例宕机时,剩余的实例选举产生新的领导者。领导者选举的方法:多个实例抢占创建endpoints资源,创建成功者为领导者。比如多个scheduler实例抢占创建endpoints资源:kube-scheduler sh# kubectl get endpoints kube-scheduler -n kube-system -o yaml apiVersion: v1 kind: Endpoints metadata: annotations: control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"master1_293eaef2-fd7e-4ae9-aae7-e78615454881","leaseDurationSeconds":15,"acquireTime":"2021-10-06T20:46:43Z","renewTime":"2021-10-19T02:49:21Z","leaderTransitions":165}' creationTimestamp: "2021-02-01T03:10:48Z" ...... # 查询kube-scheduler endpoint资源,可以看到此时master1上的scheduler是active状态,其它实例则为standby。 3. kubelet和kube-proxy在工作节点上运行 1. kubelet负责:向apiserver创建一个node资源,以注册该节点; 持续监控apiserver,若有pod部署到该节点上,创建并启动pod; 持续监控运行的pod,向apiserver报告pod的状态、事件和资源消耗; 周期性的运行容器的livenessProbe,当探针失败时,则重启容器; 持续监控apiserver,若有pod删除,则终止该容器; 2. kube-proxy负责: 负责确保对服务ip和port的访问最终能到达pod中,通过节点上的iptables/ipvs来实现; 3. 控制平台组件开启和关闭实验结果: 3个kube-apiserver关掉2个,只保留1个,可以正常接收kubectl命令操作、 3个kube-scheduler和kube-controller-manager关掉2个节点,只保留1个节点可以正常操作 只保留1个kube-controller-manager,而kube-scheduler3个节点全部关闭,在创建deployment和service时候,任务会被创建成功,但是pod会被一直pending,因为pod没有调度器调度,此时开启一个kube-scheduler后,pending状态的pod正常运行。 只保留1个kube-scheduler,而kube-controller-manager3个节点全部关闭,在创建deployment和service时候,任务不会被创建成功,因为kube-controller-manager没有运行,无法使用deployment控制器创建pod,虽然kube-scheduler运行,但是控制器没有运行,后面的调度任务也就不会被运行。