数据库做网站做网站首页有什么

数据库做网站,做网站首页有什么,竞价推广平台,响应式网页设计与实现论文在上一章节中#xff0c;介绍了pod#xff0c;以及介绍了如何使用命令行来创建一个pod。那么问题来了#xff0c;一般来说#xff0c;我们部署微服务不可能只部署一个噻#xff0c;肯定是部署多个#xff0c;但是我们总不可能说#xff0c;写一个for循环#xff0c;启动…在上一章节中介绍了pod以及介绍了如何使用命令行来创建一个pod。那么问题来了一般来说我们部署微服务不可能只部署一个噻肯定是部署多个但是我们总不可能说写一个for循环启动多个pod并且如果pod挂了我们又不能说实时观察肯定是希望pod能够自动创建重启。那么这些如何做到呢这便是今天我们介绍的Deployment的功能了。1. ReplicaSetRS在介绍Deployment之前首先需要介绍一下RS。RS顾名思义就是副本集本质上就是一个资源对象它定义了pod副本的数量如何创建新pod以及通过标签识别pod目的就是确保集群中始终运行指定数量的pod副本。他的作用很简单Pod 挂了 → 自动重建Pod 被删了 → 自动补上Pod 数量 ≠ 期望值 → 调整到期望值看到上面这些问题是不是似曾相似这不就是之前在k8s基础概念[^1]提到的kube-controller-manager吗YESsir是的kube-controller-manager运行着多个控制器controller负责管理对应的资源对象其中有一个就是Replication Controller当我们创建一个ReplicaSet的时候kube-controller-manager就是监听RS这个资源对象然后检查。例如如下yaml定义便是创建一个RS在yaml定义中我们会定义rs管理的标签也就是nginx和prob同时我们也会定义pod的创建模板在模板中我们定义了pod的标签也为nginx和prob。 这样RS在管理的时候就是将对应标签的pod纳入到管理中。当他发现少了pod则会创建多了则会删除。apiVersion: apps/v1kind: ReplicaSetmetadata:name: nginx-rsspec:replicas: 3selector: # ← 标签这就是“认亲规则”matchLabels:app: nginxenv: prodtemplate: # 创建pod的规则metadata:labels:app: nginx # ← 必须满足 selectorenv: prodspec:containers:- name: nginximage: nginx:latest下面是RS的工作原理图可以结合前面章节的内容进行参考image‍2. Deployment在上面小节中详细的介绍了ReplicaSet相关的作用以及工作流程RS通过定义pod的数量相关资源对象来确保集群中pod数量。那么有了这个为什么我们还需要Deployment呢Deployment提供了对pod和ReplicatSet的管理方式从名字上我们就能看出Deployment对应了的集群中的一次部署。当我们创建一个Deployment资源对象的时候Deployment控制器就会自动创建一个RS资源对象。然后RS控制器又会根据RS里面定义的规则最终创建对应数量的pod。看起来似乎Deployment的功能和RS类似但是相比于RSdeployment提供了更多的功能。让我们想想RS有什么局限性在实际的开发生产中我们的应用需要更新或者在必要时进行回滚。那么就需要进行如下操作升级应用镜像版本比如说nginx从1.0→2.0滚动更新逐步替换旧pod更新失败自动回滚到上一版本更新速度控制例如一次只更新一个pod灰度发布那么问题来了RS能提供这些功能吗答案是不能。如果我们需要更新镜像版本那么必须要先创建新的RS等新的pod启动后再删除老的pod。但是却没法控制更新速度以及进行自动归滚。当然你要是说我手动模拟这个过程那确实也行不过这样的风险就太高了毕竟手动操作怎么比得上程序自动操作的有序性和精准性。image如下便是一个deployment的定义apiVersion: apps/v1kind: Deploymentmetadata:name: nginx-deploymentlabels:app: nginxspec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80运行之后则会生成3个podimage同时也生成了1个rsimage如果我此时更新deployment对应的镜像我们可以看到k8s自动生成了新的rs并且保留了之前版本的历史记录image3. Deployment资源配置在Docker中我们可以配置容器的计算资源比如说CPU内存当然在k8s中我们也当然可以进行相关的配置。apiVersion: apps/v1kind: Deploymentmetaname: my-appspec:replicas: 2selector:matchLabels:app: my-apptemplate:metalabels:app: my-appspec:containers:- name: app-containerimage: nginx:1.25resources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500mk8s调度器会根据 requests​ 值选择有足够资源的节点,表示容器至少需要这么多资源才能正常运行。limits则表示容器最多可以使用的上线如果内存超过limit则会OOMKilled如果cpu超过limit则会被节流。CPU的单位有点奇葩是m其中1000m1核。​requests​和limit主要有以下用途平时Pod 按 requests 保证最低资源用于调度和资源预留。高峰期如果节点有空闲资源Pod 可以 临时使用更多资源最多到 limits实现“爆发”。资源紧张时Kubernetes 会优先保障 requests并可能限制或驱逐低 QoS 的 Pod。学过操作系统的我们知道在Linux系统中会实现某些调度器比如CFS来将cpu的时间分配给某些进程。因此在k8s中配置pod的cpu资源大小本质上就是在配置cpu的调度时间。具体的可以参考linux的cgroup是如何分配CPU资源。但是在使用中我们需要注意尽量让内存的requests和limits大小尽量不要偏差太大。因为cpu从limits大小的资源变成requests无非就是算的慢一点。但是如果是内存从大变小便可能会出现OOMKilled问题因为本来程序占用了4G的内存资源现在变成了1G能不OOM吗。4. 总结