辽宁网站建设论坛,校园内部网站平台建设方案,蚌埠专业制作网站的公司,金融理财网站开发传统部署时代#xff1a; 早期#xff0c;组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界#xff0c;这会导致资源分配问题。例如#xff0c;如果在物理服务器上运行多个应用程序#xff0c;则可能会出现一个应用程序占用大部分资源的情况 早期组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界这会导致资源分配问题。例如如果在物理服务器上运行多个应用程序则可能会出现一个应用程序占用大部分资源的情况结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序但是由于资源利用不足而无法扩展并且组织维护许多物理服务器的成本很高。
虚拟化部署时代 作为解决方案引入了虚拟化功能它允许您在单个物理服务器的 CPU 上运行多个虚拟机VM。虚拟化功能允许应用程序在 VM 之间隔离并提供安全级别因为一个应用程序的信息不能被另一应用程序自由地访问。
因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等所以虚拟化可以更好地利用物理服务器中的资源并可以实现更好的可伸缩性。
每个 VM 是一台完整的计算机在虚拟化硬件之上运行所有组件包括其自己的操作系统。
容器部署时代 容器类似于 VM但是它们具有轻量级的隔离属性可以在应用程序之间共享操作系统OS。因此容器被认为是轻量级的。容器与 VM 类似具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离因此可以跨云和 OS 分发进行移植。
容器当下大家比较熟知的是docker而Kubernetes可以看作docker的管理工具。
为什么需要Kubernetes
真正的生产型应用会涉及多个容器。这些容器必须跨多个服务器主机进行部署。容器安全性需要多层部署因此可能会比较复杂。但 Kubernetes 有助于解决这一问题。简单来说就是Kubernetes 可以帮助开发者构建跨多个容器的应用服务、跨集群调度、扩展这些容器并长期持续管理这些容器的健康状况。
专业术语
主机Master 用于控制 Kubernetes 节点的计算机。所有任务分配都来自于此。 API SERVER:用户不论用命令行还是图形界面请求都发送至api server内部系统与外部用户也通过相同的api通信
etcd存储集群的配置和状态主节点通过etcd查询节点容器与容器的状态参数
Controllers:从api server获取到所需状态控制节点的当前状态有差异就解决
Scheduler:监听来自api的新请求对节点进行排名把pod部署到合适的节点不合适就先挂着不部署 节点Node负责执行请求和所分配任务的计算机。由 Kubernetes 主机负责对节点进行控制。 容器集Pod被部署在单个节点上的且包含一个或多个容器的容器组。同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。容器集会将网络和存储从底层容器中抽象出来。这样您就能更加轻松地在集群中移动容器。
Kubelet运行在节点上的服务1.监视来自api的任务执行任务并向主节点报告。2.监视podpod有问题会向控制程序报告控制程序会改变分配策略。
Container Runtime容器运行时从镜像库拉取镜像。
kube-proxy让每个节点获得他的IP地址实现负载均衡。
复制控制器Replication controller用于控制应在集群某处运行的完全相同的容器集副本数量。 当pod有问题时kubernetes会创造一个和原来一样的pod但是IP不一样。service用来解决这个问题。
服务Service将工作内容与容器集分离。Kubernetes 服务代理会自动将服务请求分发到正确的容器集——无论这个容器集会移到集群中的哪个位置甚至可以被替换掉。 Kubernetes 工作的简单流程
主机(master)接收开发者的命令自动选择从属节点(node)进行分发之后它将在该节点分配资源并指派容器集来完成任务请求。
当 kubernetes 将容器集调度到一个节点上时该节点上的 kubelet 会发送指令让 docker 启动指定的容器。kubelet 随后会不断从 docker 收集这些容器的状态并将这些信息汇集至主机。
