运维入坑必看：Kubernetes平台架构分析
发布时间：2022-08-04 16:12:19 所属栏目：云计算 来源：互联网
导读：Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用， 是云计算发展演进的一次彻底革命性的突破。Kubernetes是谷歌的第三代容器管理系统，是Borg独特的控制器和Omega灵活的调度器的组合。Kubernetes中的应用被打包成与环境完全分离的容器镜
|
Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用， 是云计算发展演进的一次彻底革命性的突破。Kubernetes是谷歌的第三代容器管理系统，是Borg独特的控制器和Omega灵活的调度器的组合。Kubernetes中的应用被打包成与环境完全分离的容器镜像，并且自动配置应用并维护跟踪资源分配。 敏捷的弹性伸缩能力： 不同于虚拟机分钟级的弹性伸缩响应，容器应用可实现秒级甚至毫秒级的弹性伸缩响应； 智能的服务故障自愈能力： 容器应用具有极强的自愈能力，可实现应用故障的自动摘除与重构； 大规模的复制分发能力： 容器应用标准化的交付制品，可实现跨平台、跨区域，云边一体规模化复制分发部署能力。 一、Kubernetes整体架构 Kubernetes是典型的 主从分布式架构， 由 集中式管理节点（Master Node）,分布式的工作节点（Worker Node） 以及 辅助工具 组成。 1、集中式管理节点 集中式管理节点，对集群进行调度管理，有 四大核心组件： API Server： 承担集群的网关，实现统一认证鉴权对外服务，同时也是管理Node/Pod资源代理通道； 2、分布式的工作节点 分布式的工作节点，工作节点运行业务应用容器；默认会运行 三大核心组件 ： Kubelet： 与管理节点通信并触发指令执行，管理驱动网络，存储及容器运行时； Kube Proxy： 通过DNS实现服务发现，借助iptables规则引导访问至服务IP，并将重定向至正确的后端应用，实现高可用负载均衡能力； 3、辅助工具 辅助工具，主要是辅助集群管理及网络扩展: kubectl 通过API Server进行交互，实现 集群管理的命令行工具； Dashboard 是Kubernetes的web 用户管理监控界面； Core DNS 是可扩展的DNS服务器，实现 集群服务发现能力。 二、Kubernetes核心理念 1、POD容器组，Kubernetes最小调度单元 Pod是Kubernetes的 最小调度及资源分配单元， Pod之间相互隔离，通常情况一个Pod只建议运行一个容器，当某些容器之间关系非常紧密（Tightly coupled），可以运行在同一Pod运行多个容器方便一起调度管理。一个Pod就是一个应用运行实例，通过同时运行多个Pod来实现应用 横向扩展 能力。Pod本身没有自恢复能力，当调度或运行失败时，需要管理节点的Controller根绝配置触发实现Pod重启、重建或迁移等操作。 从Pod启动过程来看， Pod容器主要是 Pause Container，Init Container 以及 App Container 三种类型容器组成： Pause Container： 又叫Infra Container，Pod通过Pause Container实现Pod多个容器网络共享， Pause Container最先启动并绑定Pod唯一IP地址与各种网络资源，其他容器通过加入Pause Container的Network namespace来实现网络共享。Pause是C语言实现，镜像非常小只有700KB左右，并且永远处于Pause(暂停)状态；官方镜像是gcr.io/google_containers/pause-amd64:3.0，同时也支持自定义。 Init Container： Pod中可以自定义一个或者多个 Init Container ， 按照顺序依次启动 ，在应用Container之前启动并执行一些辅助任务，比如执行脚本、拷贝文件到共享目录、日志收集、应用监控等。将辅助功能与主业务容器解耦，实现独立发布和能力重用。除了不支持Readiness Probe，其他与特性与普通容器保持一致。 App Container： Pod真正承接业务的Container，一般情况会独立运行，如果是有微服务治理等需求会搭配Sidecar Container一起运行。在Init Container启动完成之后， App Container会并行启动， 但是需要等待所有 App Container 处于就绪状态，整个Pod才算启动成功。 从POD的资源隔离来看， Pod容器主要由Linux提供的Namespace和Cgroup能力实现的，Namespace实现进程间隔离，Cgroup实现进程资源控制；其中Namespace由ipc 、uts 、net 、mnt 、pid 各种资源空间联合组成。 CRI 是Kubernetes v1.5引入的，将Kubelet与容器运行时解耦；CRI中定义了 容器 和 镜像 的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，所以定义了 RuntimeService 和 ImageService 两个服务，其中RuntimeService主要包含Sandbox和Container两种容器的管理gRPC接口，Sandbox就是上面Pod启动过程中提到的 Pause容器 。目前支持CRI的后端有cri-o，cri-containerd，rkt，frakti，docker等，cri-o是由redhat发起并开源且由社区驱动的container-runtime， 轻量化专为kubernetes而生， 主要目的就是替代docker作为kubernetes集群的容器运行时。 2、Volume存储卷，Kubernetes复杂的存储架构 存储非常重要关键，同时也是生态与技术都比较复杂的领域，就linux、window两个生态支持的文件系统就多达20+。 对于Kubernete存储架构设计一直在持续演进完善，为了尽可能多地兼容各种存储平台，Kubernetes以in-tree plugin的形式默认对接很多不同类型的存储系统； 同时也支持基于FlexVolume和CSI插件以out-of-tree plugin来实现自定义存储服务。 对Kubernetes存储，主要有 应用的基本配置文件读取、密码密钥管理；应用的存储状态、数据存取，不同应用间数据共享 等三大使用场景。目前Kubernetes支持的Volume Plugins如下表： Empty Dir： 生命周期与Pod保持一致，当Pod删除后emptyDir中的数据也会被自动清除。当前 emptyDir支持的类型有内存、大页内存、Node节点上Pod所在的文件系统。 ConfigMap： 主要是承担配置中心，用于存储应用的配置数据，比如Springboot应用properties配置文件数据，但是空间大小限制在1MB内。 Secret： 功能与ConfigMap类似，用于存储应用的敏感数据，比如数据密码、token、证书等，可以与ConfigMap联合使用，同样空间大小限制在1MB内。 HostPath： 将Node节点本地文件系统路径映射到pod容器中使用。与emptyDir不同之处就是Pod删除后，HostPath中的数据Kubernetes根据用户的配置，可以不被清除。 In-tree网络存储： 网络存储跟随Pod的生命周期，通过存储插件对接不同类型存储；其中FlexVolume虽然允许自定义开发驱动来挂载卷到集群Node节点上供Pod使用，但生命周期与pod同步。 PersistentVolumeClaim网络存储： 具有独立的生命周期，可以通过存储的out-tree插件对接不同类型存储。当前支持的存储插件类型有FlexVolume与CSI。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号