在线服务器网站,网站咨询弹窗怎么做,小程序免费制作平台凡科网页版,女士新能源小型车K8S核心原理
K8S的网络模型
K8S的网络中主要存在4种类型的通信#xff1a;
同一Pod内的容器间通信各个Pod彼此间的通信Pod和Service间的通信集群外部流量和Service之间的通信
K8S为Pod和Service资源对象分别使用了各自的专有网络#xff0c;Pod网络由K8S的网络插件配置实…K8S核心原理
K8S的网络模型
K8S的网络中主要存在4种类型的通信
同一Pod内的容器间通信各个Pod彼此间的通信Pod和Service间的通信集群外部流量和Service之间的通信
K8S为Pod和Service资源对象分别使用了各自的专有网络Pod网络由K8S的网络插件配置实现而Service网络则由K8S集群进行指定。如下图 K8S使用的网络插件需要为每个Pod配置至少一个特定的地址即Pod IP。Pod IP地址实际存在于某个网卡可以是虚拟机设备上。 而Service的地址却是一个虚拟IP地址没有任何网络接口配置在此地址上它由Kube-proxy借助iptables规则或ipvs规则重定向到本地端口再将其调度到后端的Pod对象。Service的IP地址是集群提供服务的接口也称为Cluster IP。 Pod网络和IP由K8S的网络插件负责配置和管理具体使用的网络地址可以在管理配置网络插件时进行指定如10.244.0.0/16网络。而Cluster网络和IP是由K8S集群负责配置和管理如10.96.0.0/12网络。 从上图进行总结起来一个K8S集群包含是三个网络。
节点网络各主机Master、Node、ETCD等自身所属的网络地址配置在主机的网络接口用于各主机之间的通信又称为节点网络。Pod网络专用于Pod资源对象的网络它是一个虚拟网络用于为各Pod对象设定IP地址等网络参数其地址配置在Pod中容器的网络接口上。Pod网络需要借助kubenet插件或CNI插件实现。Service网络专用于Service资源对象的网络它也是一个虚拟网络用于为K8S集群之中的Service配置IP地址但是该地址不会配置在任何主机或容器的网络接口上而是通过Node上的kube-proxy配置为iptables或ipvs规则从而将发往该地址的所有流量调度到后端的各Pod对象之上。
K8S的工作流程
用K8S部署Nginx的过程中K8S内部各组件是如何协同工作的 我们在master节点执行一条命令要master部署一个nginx应用(kubectl create deployment nginx --imagenginx)
这条命令首先发到master节点的网关api server这是matser的唯一入口api server将命令请求交给controller mannager进行控制controller mannager 进行应用部署解析controller mannager 会生成一次部署信息并通过api server将信息存入etcd存储中scheduler调度器通过api server从etcd存储中拿到要部署的应用开始调度看哪个节点有资源适合部署scheduler把计算出来的调度信息通过api server再放到etcd中每一个node节点的监控组件kubelet随时和master保持联系给api-server发送请求不断获取最新数据拿到master节点存储在etcd中的部署信息假设node2的kubelet拿到部署信息显示他自己节点要部署某某应用kubelet就自己run一个应用在当前机器上并随时给master汇报当前应用的状态信息node和master也是通过master的api-server组件联系的每一个机器上的kube-proxy能知道集群的所有网络只要node访问别人或者别人访问nodenode上的kube-proxy网络代理自动计算进行流量转发 k8s架构原理
K8S 是一个基于容器技术的分布式集群管理系统。既然是个分布式系统那势必有多个 Node 节点物理主机或虚拟机它们共同组成一个分布式集群并且这些节点中会有一个 Master 节点由它来统一管理 Node 节点。 如图所示 一主节点和工作节点的通讯原理 首先Master 节点启动时会运行一个 kube-apiserver 进程它提供了集群管理的 API 接口是集群内各个功能模块之间数据交互和通信的中心枢纽并且它页提供了完备的集群安全机制。 在 Node 节点上使用 K8S 中的 kubelet 组件在每个 Node 节点上都会运行一个 kubelet 进程它负责向 Master 汇报自身节点的运行情况如 Node 节点的注册、终止、定时上报健康状况等以及接收 Master 发出的命令创建相应 Pod。 在 K8S 中Pod 是最基本的操作单元它与 docker 的容器有略微的不同因为 Pod 可能包含一个或多个容器可以是 docker 容器这些内部的容器是共享网络资源的即可以通过 localhost 进行相互访问。 关于 Pod 内是如何做到网络共享的每个 Pod 启动内部都会启动一个 pause 容器google的一个镜像它使用默认的网络模式而其他容器的网络都设置给它以此来完成网络的共享问题。 如图所示 二Master 是如何将 Pod 调度到指定的 Node 上的 该工作由 kube-scheduler 来完成整个调度过程通过执行一些列复杂的算法最终为每个 Pod 计算出一个最佳的目标 Node该过程由 kube-scheduler 进程自动完成。常见的有轮询调度RR。当然也有可能我们需要将 Pod 调度到一个指定的 Node 上我们可以通过节点的标签Label和 Pod 的 nodeSelector 属性的相互匹配来达到指定的效果。 如图所示 三各节点、Pod 的信息都是统一维护在哪里的由谁来维护 从上面的 Pod 调度的角度看我们得有一个存储中心用来存储各节点资源使用情况、健康状态、以及各 Pod 的基本信息等这样 Pod 的调度来能正常进行。 在 K8S 中采用 etcd 组件 作为一个高可用强一致性的存储仓库该组件可以内置在 K8S 中也可以外部搭建供 K8S 使用。 集群上的所有配置信息都存储在了 etcd为了考虑各个组件的相对独立以及整体的维护性对于这些存储数据的增、删、改、查统一由 kube-apiserver 来进行调用apiserver 也提供了 REST 的支持不仅对各个内部组件提供服务外还对集群外部用户暴露服务。 外部用户可以通过 REST 接口或者 kubectl 命令行工具进行集群管理其内在都是与 apiserver 进行通信。 如图所示 四外部用户访问集群内运行Pod的原理 前面讲了外部用户如何管理 K8S而我们更关心的是内部运行的 Pod 如何对外访问。使用过Docker 的同学应该知道如果使用 bridge 模式在容器创建时都会分配一个虚拟 IP该 IP 外部是没法访问到的我们需要做一层端口映射将容器内端口与宿主机端口进行映射绑定这样外部通过访问宿主机的指定端口就可以访问到内部容器端口了。 那么K8S 的外部访问是否也是这样实现的答案是否定的K8S 中情况要复杂一些。因为上面讲的 Docker 是单机模式下的而且一个容器对外就暴露一个服务。在分布式集群下一个服务往往由多个 Application 提供用来分担访问压力而且这些 Application 可能会分布在多个节点上这样又涉及到了跨主机的通信。 这里K8S 引入了 Service 的概念将多个相同的 Pod 包装成一个完整的 service 对外提供服务至于获取到这些相同的 Pod每个 Pod 启动时都会设置 labels 属性在 Service 中我们通过选择器 Selector选择具有相同 Name 标签属性的 Pod作为整体服务并将服务信息通过 Apiserver 存入 etcd 中该工作由 Service Controller 来完成。同时每个节点上会启动一个 kube-proxy 进程由它来负责服务地址到 Pod 地址的代理以及负载均衡等工作。 如图所示 五Pod 动态扩容和缩放原理 既然知道了服务是由 Pod 组成的那么服务的扩容也就意味着 Pod 的扩容。通俗点讲就是在需要时将 Pod 复制多份在不需要后将 Pod 缩减至指定份数。K8S 中通过 Replication Controller 来进行管理为每个 Pod 设置一个期望的副本数当实际副本数与期望不符时就动态的进行数量调整以达到期望值。期望数值可以由我们手动更新或自动扩容代理来完成。 如图所示 六各个组件之间相互协作的原理 最后讲一下 kube-controller-manager 这个进程的作用。我们知道了 ectd 是作为集群数据的存储中心 apiserver 是管理数据中心作为其他进程与数据中心通信的桥梁。而 Service Controller、Replication Controller 这些统一交由 kube-controller-manager 来管理kube-controller-manager 作为一个守护进程每个 Controller 都是一个控制循环通过 apiserver 监视集群的共享状态并尝试将实际状态与期望不符的进行改变。关于 Controllermanager 中还包含了 Node 节点控制器Node Controller、资源配额管控制器ResourceQuota Controller、命名空间控制器Namespace Controller等。 如图所示
