水滴石穿,点滴记忆铭记于心。
云平台、云业务经常出现的一个词,k8s,全称kubernetes,与Docker类似现阶段更胜一筹的容器服务。严谨一点说,Docker不算是容器,它本身的口号是build,ship and run。
容器服务很多人第一时间想到的应该会有VMWare,这个在国内的占有率还是很高的,很多windows系统开一个VM,里面在搞几个Linux,很常见的模式。k8s是怎么在这种情况下胜出的呢,首先VM有自身的弊端,虚拟出来的系统后,占用主机大量的性能,内部系统启动会逐渐慢到你无法忍受,占用的空间让你需要经常去扩容是所在的主机,迁移?这个难度更大了。
Docker呢,java的小伙伴很熟悉,但是这一层一层的镜像,创建的服务越来越大,容器数量越来越多,维护的成本居高,那怎么去更好的管理Docker呢,k8s在可用性和伸缩性解决这些痛点。所以对docker及容器的高级灵活管理服务k8s诞生了。
- 服务发现与调度
- 负载均衡
- 服务自愈
- 服务弹性扩容
- 横向扩容
- 存储卷挂载
k8s集群也同样是master和node这种组成方式。
- master:主要控制节点,k8s的所有控制命令都发给它,负责执行过程。内部主要运行
- Kubernetes Controller Manager:控制管理,所有的资源对象的自动化控制中心,维护管理集群的状态,如故障检测,自动扩展,滚动更新等。
- Kubernetes Scheduler:资源调度中心,按照预定的调度策略将Pod调度到响应的机器上;
- etcd:保存整个集群的状态;
- node:master之外的所有节点,master中使用命令kubectl get nodes就可以查看集群中的node节点。每个node节点都会被Master分配一些工作负载,如果没有node节点宕机了,这个节点的工作负载就会被master自动转移到其他节点上,node的主要工作是:
- kubelet:负载Pod对应的容器创建、启动、停止等任务,同时与Master密切协作,实现集群管理的基本能力;
- kube-proxy:实现service通信与负载均衡;
- docker(docker-engine):Docker引擎,负责本机的容器创建和管理。
POD
Pod是Kubernetes创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器或者多个应用容器,存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位:Kunbernetes中单个应用的实例,他可能由单个容器或多个容器共享组成的资源。
Docker是Kubernetes Pod中最常见的runtime,Pods也支持其他容器的rentimes。
Pod的两种使用方式:
- Pod中运行一个容器,one-container-per-Pod模式,这种模式最常见,在这种情况里,Pod可以视为单个封装的容器,但是kubernetes是直接管理Pod而不是容器。
- Pods中运行多个需要一起工作的容器。Pod是可以疯转紧密耦合的应用,它们需要由多个容器组成,它们之间能够共享资源,这些容器可以形成一个单一的内部service单位-一个容器共享文件,另一个sidecar容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
– 摘自Kubernetes中文文档
Sidecar
sidecar这种设计模式现在使用是越来越多,服务组网Service Mesh的重要组成元素,这种模式对于构建高度可伸缩、有弹性、安全且便于监控的微服务架构系统十分重要。
Sidecar模式将应用功能从应用本身剥离出来作为单独进程的方式。也就是sidecar附加到主应用上,以扩展/增强功能。类似早期的功能插件,游戏里面的DLC之类的。
- Sidecar的工作模式:service mesh层可以位于应用侧的sidecar容器中,同一个sidecar的多个副本可以负载每一个应用。来自单个服务的所有传入和传出网络流量均通过Sidecar代理,完成微服务之间的流量管理、遥测数据收集以及策略的执行等等。从某种意义上来说,服务对于网络是无感知的,只知道所附加的sidecar代理。这就是Sidecar模式工作的本质,它将网络依赖抽象成了Sidecar。
- 上面Service Mesh中,还有两个概念:Data Plane和Control Plane
- Data Plane的作用是处理网格内服务间的通信,并完成服务发现、负载均衡、流量管理、健康检查等功能;数据平面的作用是处理网格内服务之间的通信,并负责实现服务发现、负载平衡、流量管理、健康检查等功能;
- Control Plane的作用是管理和配置Sidecar来执行策略并收集telemetry;