一个服务器做一样的网站吗,制作网站的全过程,怎么修改网站图片,中小企业网络营销存在的问题1.概念 什么是Kubernetes 官网#xff1a;Kubernetes 文档 | Kubernetes K8S的本质是一组服务器集群#xff0c;可以在对应服务器集群的每个节点上运行程序#xff0c;来对节点中的容器进行管理 类似Master-Work方式#xff0c;每个服务器上安装特定的K8S组件#xff0c…1.概念 什么是Kubernetes 官网Kubernetes 文档 | Kubernetes K8S的本质是一组服务器集群可以在对应服务器集群的每个节点上运行程序来对节点中的容器进行管理 类似Master-Work方式每个服务器上安装特定的K8S组件就可以形成集群然后部署对应的应用即可 K8S常见的功能 服务发现和负载均衡 Kubernetes可以使用DNS名称或自己的IP地址来暴露容器如果进入容器的流量很大Kubernetes能够自动实现请求的负载均衡分配网络流量从而使部署稳定 存储编排 Kubernetes允许自动挂载选择的存储系统例如本地存储、云提供商存储等 自动部署和回滚 可以用K8S自动化部署创建新容器删除现有容器并将它们的所有资源用于新容器当版本发布错误可以立刻回退到之前的版本 自我修复 如果某个容器宕机了K8S可以快速重新启动新的容器替换旧的容器 密钥与配置管理 K8S允许存储和管理敏感信息例如密码、OAuth令牌和ssh密钥
2.K8S常见概念组件 K8S整体架构也是Client-Server模型 控制节点Master-Node负责集群的管理工作节点Worker-Node负责为集群提供运行环境 K8S常见概念 Master 集群控制节点相当于整个集群的指挥中心在每个Kubernetes集群里都需要一个Master来负责整个集群的管理和控制 Node 除了MasterK8S集群中的其他机器被称为Node节点Node节点才是Kubernetes集群中的工作负载节点每个Node节点都会被Master分配一些工作负载docker容器Node节点上的docker负责容器的运行 Pod Pod是一组容器在K8S中最小的单位是Pod一个Pod可以包含多个容器但通常情况下我们在每个Pod中仅使用一个容器可以理解成豌豆荚Pod内的每个容器是一颗颗豌豆分类 自主创建直接创建出来的Pod这种Pod删除后就没有了也不会自动重建控制器创建通过控制器创建的Pod这类Pod删除了之后还会自动重建 Pod Controller 控制器是管理Pod的中间层只需要告诉Pod控制器想要创建多少个什么样的Pod它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod在运行中出现故障它会基于指定策略重新编排Pod通过它来实现对Pod的管理比如启动Pod、停止Pod、扩展Pod的数量等等类型 ReplicaSet、Deployment、Horizontal Pod Autoscaler、DaemonSet等 Service 在K8S里面每个Pod都会被分配一个单独的IP地址但这个IP地址会随着Pod的销毁而消失Service服务就是用来解决这个问题的对外服务的统一入口用于为一组提供服务的Pod抽象一个稳定的网络访问地址一个Service可以看作一组提供相同服务的Pod的对外访问接口作用于哪些Pod是通过标签选择器来定义的 Label K8S提供了一种机制来为Pod进行分类那就是Label标签同一类Pod会拥有相同的标签Label的具体形式是key-value的标记对可以在创建资源的时候设置也可以在后期添加和修改给某个资源对象定义一个Label就相当于给它打了一个标签可以通过Label Selector标签选择器查询和筛选拥有哪些Label的资源对象K8S通过这种方式实现了类似SQL的对象查询机制 Label选择器 对应的资源打上标签后可以使用标签选择器过滤指定的标签标签选择器目前有两个 基于等值关系等于、不等于基于集合关系属于、不属于、存在 NameSpace 可以在一个物理集群上运行多个虚拟集群这种虚拟集群被称为命名空间用来隔离Pod的运行环境同一个命名空间中的资源名称必须唯一NameSpace是不能嵌套的每一个Kubernetes的资源都只能在一个NameSpace内命名空间是在多个用户之间划分集群资源的一种方法通过资源配额不必使用多个命名空间来分隔轻微不同的资源例如同一软件的不同版本应该使用标签来区分Kubernetes会创建四个初始NameSpace命名空间 default没有指明使用其它命名空间的对象所使用的默认命名空间kube-system Kubernetes系统创建对象所使用的命名空间kube-public是自动创建的命名空间下的资源可以被所有人访问包括未认证用户kube-node-lease集群节点之间的心跳维护 应用分类 有状态应用 不能简单的实现负载均衡的服务有数据产生的服务redis、mysql、rabbitMQ等相关服务需通过一些较复杂的配置才能做到负载均衡有状态的应用建议直接在物理机部署方便维护管理 无状态应用 没有对应业务数据的应用可以简单的实现负载均衡复制一个节点即可快速扩容如SpringCloud中的业务服务无状态的应用适合部署在K8S中或者容器中
3.K8S整体架构 K8S整体架构也是Client-Server模型 控制节点Master-Node负责集群的管理 apiserver提供操作K8S集群资源的唯一入口restful方式请求并提供认证、授权、访问控制、API注册和发现等scheduler负责资源调度按照预定的调度策略计算将Pod调度到相应的Node节点进行应用部署controller-manager控制器管理中心负责维护集群的状态比如故障检测、滚动更新等根据调度器的安排通知对应的节点创建Podetcd存储中心是兼具一致性和高可用性的键值数据库可以作为保存Kubernetes所有集群数据的后台数据库 工作节点Worker-Node负责为集群提供运行环境 Node是Pod真正运行的主机可以是物理机也可以是虚拟机Node本质上不是K8S创建的K8S只是管理Node上的资源为了管理Pod每个Node节点上至少需要运行container runtime(Docker)、kubelet和kube-proxy服务kubelet相当于主节点派到工作节点的一个代表用于管理本机容器相当于master节点的化身负责维护容器的生命周期也负责VolumeCVI和网络CNI的管理kube-proxy负责为Service提供cluster内部的服务发现/网络代理/负载均衡等操作为部署的应用程序提供访问入口和apiserver是不一样的后者是操作K8S集群内部 架构图
