k8s 架构浅析

Kubernetes 的电梯间演讲

Kubernetes 是一个 面向应用 的容器集群部署、管理及编排系统,旨在为最终用户屏蔽物理/虚拟计算、网络、存储基础设施的复杂度,关注以应用为核心、以容器为原语的自动化运营平台。

image

Kubernetes 具备完善的集群管理能力,包括多层次的安全认证和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

Kubernetes 的核心层级对象

image

Cluster: 是一个被 k8s 协调的高可用集群,作为 k8s 集群的根操作对象,将多台计算节点(Master/Node)连接成一个工作整体,是计算、存储和网络资源的集合。

Master:下属于 Cluster,充当集群中的中央控制角色,负责管理、协调集群中的所有活动(e.g. scheduler app、维护 app 状态机、 弹性扩展 apps、发布 app 更新 etc.)。

Node:下属于 Cluster,作为集群中的 Worker,受 Master 指使。是 Containers 及其 runtime 引擎的允许载体。

Pod: 是一个抽象而统一的概念,屏蔽底层异构 Container Runtime 技术实现。k8s 的最小工作单元,是 Containers 的 “Container”。

Container:下属于 Pod,是真正意义上的、常规的容器。

NOTE:为什么要引入 Pod 逻辑对象?

可管理性:有些容器天生就是需要紧密联系,一起工作的。例如:微服务中的 Side Car 模式,Pod 中的一个 ContainerA 提供业务,另一个 ContainerB 专门负责对 ContainerA 进行收集、监控日志和流量信息;又例如:ContainerA 作为 File Puller 定期从外部拉取最新的文件,将其存放到共享 Volume 中,ContainerB 作为 Web Server 直接从 Volume 读取文件,两个 Containers 紧密合作;Pod 将 Containers 封装到一个部署单元中,k8s 以 Pod 为最小单位进行调度、扩展、资源分配、管理生命周期。

通信和资源共享:Pod 中的所有 Containers 使用同一个 network namespace,即 Containers 具有相同的 IP 地址和 Port 空间,它们互相之间可以直接用 localhost 进行通信。同样的,这些容器也会共享存储,当 k8s 挂载 Volume 到 Pod,本质上是将 Volume 挂载到 Pod 中的每一个 Container。

简单的理解, 是不是有点类似与进程和线程的关系?

Kubernetes 的组件架构

image

Kubernetes 是典型的中控分布式架构(Central control distributed architecture),下面分别列举 Master、Node 的组件。

Master:

etcd:提供高可用性、严格数据一致性的非关系型数据库,具有共享配置、服务发现、分布式等特点。常被用于构建服务发现系统。

API Server:统一且唯一的 Cluster 北向访问接口,依靠 CA 认证体系提供身份认证、授权、鉴权等访问控制功能,统称 3A(Authentication、Authorization、Admission),是 Kubernets Security Mechanism 的门神。

Controller Manager:中央控制管理器,Cluster 的核心管理模块,负责整个 Cluster 的 “运”(e.g. 故障检测、弹性扩展、滚动更新,etc.)

Scheduler:资源调度器,按照预设的策略将 Pod 调度到目的(最佳)Node 上启动。

Node:

kubelet:维护 Container 的生命周期,同时也负责存储(CSI)和网络(CNI)的管理。

kube-proxy:为 Service 提供 Cluster 内部的服务发现和负载均衡功能。

Container runtime:负责镜像管理以及 Pod 和 Container 的运行(CRI)。

Kubernetes 的组件通信协议/接口

image

Kubernetes 的分层架构

image

Kubernetes 的术语词典

Controller:Pod 的控制器,k8s 提供了多种控制器来对 Pod 进行管理,包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等,以满足不同的业务需求。

Deployment:负责 Pod 的部署,并维护部署拓扑(e.g. 创建、监控、自修复 Pod),保证 Pod 按照期望的状态运行。

ReplicaSet:负责 Pod 的多副本管理,使用 Deployment 的同时会自动创建 ReplicaSet,也就是说 Deployment 实际是通过 ReplicaSet 来管理 Pod 多副本的,通常不需要直接使用 ReplicaSet。

DaemonSet:用于每个 Nodes 都运行且只运行一个 Pod 副本的场景。通常用于运行 daemon 服务进程。

StatefuleSet:保证 Pod 的所有副本的名称在其整个生命周期中是不变的。一般的,当 Pod 因为故障需要删除并重新启动时,它的名称是会发生变化的。StatefuleSet 还可以保证 Pod 的副本按照固定的顺序启动、更新或者删除。

Job:特殊的任务控制器,用于 App 运行结束就可以立即删除 Pod 的场景。

Service:用于定义外界访问一组特定 Pod 的方式。是一个北向提供外部访问方式(e.g. ClusterIP、NodePort、LoadBalancer),南向通过 Label 和 Selectors 来匹配 Pods 的 逻辑对象,还可以为 Pods 提供了负载均衡。

Namespace:k8s 实现多租户的方式,将一个物理 Cluster 从逻辑上划分成多个虚拟 Cluster,每个虚拟 Cluster 就是一个 Namespace,不同 Namespace 间的资源完全隔离。

default Namespace:默认的 Namespace,如果创建任意资源时 不特别指定,就会将资源放到这个 namespace 下。

kube-system Namespace:k8s 自己创建的系统资源将放到这个 namespace 下。

最后

一图抵万语,上文图源均来自互联网。实话说,并没有找到一张笔者满意的架构图,还是找个时间自己画一画吧。但依旧感谢这些图的原创作者们的贡献。

回到主题,Kubernets 的架构和整个部署的复杂度相较于 OpenStack 要更低,从这个角度来看好像的确为企业用户的运维成本省了不少。当然笔者对 k8s 也只是初学,做不得准。但可以肯定的是,k8s 的核心精髓在于 编排 二字,这是由 Container 的基因决定的。将 Container 当作 VM 来使用,那就是一个天大的误解了。所以每每看见市场上哪些为容器而容器,毫无编排特征的产品,笔者实在是难免感慨。

你可能感兴趣的:(k8s 架构浅析)