如何做微信网站做广告网络营销战略推广规划

当前位置： 首页 > news >正文

如何做微信网站做广告,网络营销战略推广规划,嘉兴市建设教育网站,文化网站建设一、资源限制 总结#xff1a; requests表示创建pod时预留的资源#xff0c;limits表示pod能够使用资源的最大值。requests值可以被超#xff0c;limits值不能超过#xff0c;如果是内存使用超过limits会触发oom然后杀掉进程#xff0c;如果是cpu超过limits会压缩cpu的使用…一、资源限制 总结 requests表示创建pod时预留的资源limits表示pod能够使用资源的最大值。requests值可以被超limits值不能超过如果是内存使用超过limits会触发oom然后杀掉进程如果是cpu超过limits会压缩cpu的使用率。 官网示例如下 Resource Management for Pods and Containers | Kubernetes 1.1Pod 和 容器的资源请求和限制  spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源 spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源 spec.containers[].resources.limits.cpu #定义 cpu 的资源上限 spec.containers[].resources.limits.memory #定义内存的资源上限spec.containers[].resources.limits.hugepages-size spec.containers[].resources.requests.hugepages-size 1.2Kubernetes 中的资源单位 1.2.1CPU 资源单位 CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU1个超线程。 Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的  、一半 CPU 资源类似于Cgroup对CPU资源的时间分片。表达式 0.1 等价于表达式 100m毫核表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。 Kubernetes 不允许设置精度小于 1m 的 CPU 资源。  1.2.2内存 资源单位 内存的 request 和 limit 以字节为单位。可以以整数表示或者以10为底数的指数的单位E、P、T、G、M、K来表示 或者以2为底数的指数的单位Ei、Pi、Ti、Gi、Mi、Ki来表示。 如1KB10^310001MB10^610000001000KB1GB10^910000000001000MB 1KiB2^1010241MiB2^2010485761024KiB 例如在买硬盘的时候操作系统报的数量要比产品标出或商家号称的小一些主要原因是标出的是以 MB、GB为单位的1GB 就是1,000,000,000Byte而操作系统是以2进制为处理单位的因此检查硬盘容量时是以MiB、GiB为单位1GiB2^301,073,741,824相比较而言1GiB要比1GB多出1,073,741,824-1,000,000,00073,741,824Byte所以检测实际结果要比标出的少一些。 cpu的单位可以是核个数如1.250.5等可以是毫核如500m1250m memory的单位可以是128M或128Mi 分别是1000k1M或1024Ki1Mi 1.3容器资源示例  官方文档 https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/ 以下 Pod 有两个容器。每个容器的请求为 0.25 CPU 和 64MiB226 字节内存 每个容器的资源限制为 0.5 CPU 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 CPU 和 128 MiB 内存资源限制为 1 CPU 和 256MiB 内存 apiVersion: v1 kind: Pod metadata:name: frontend spec:containers:- name: appimage: images.my-company.example/app:v4env:- name: MYSQL_ROOT_PASSWORDvalue: passwordresources:requests:memory: 64Micpu: 250m limits:memory: 128Micpu: 500m- name: log-aggregatorimage: images.my-company.example/log-aggregator:v6resources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m 1.4部署容器资源限制 mkdir /opt/pod/ cd /opt/pod/ apiVersion: v1 kind: Pod metadata:name: zzz-web-db spec:containers:- name: webimage: nginxenv:- name: WEB_ROOT_PASSWORDvalue: passwordresources:requests:memory: 64Micpu: 250mlimits:memory: 128Micpu: 500m- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: abc123resources:requests:memory: 64Micpu: 0.25limits:memory: 128Micpu: 500m 可以看到状态是OOMKilled、表示资源不足、需要修改资源 OOMKilled资源不足被杀死 kubectl logs zzz-web-db -c db 然后进入修改配置 现在状态正常running状态创建成功 查看pod的详细信息 kubectl describe pod zzz-web-db kubectl get pods -owide 看到调度到了node01上面我们可以去查看详细信息如下图 kubectl describe nodes #查看资源占用多少 预分配request  Pod 和 容器 的资源请求和限制 spec.containers[].resources.requests.cpu        #定义创建容器时预分配的CPU资源 spec.containers[].resources.requests.memory       # 定义创建容器时预分配的内存资源 #创建pod容器时需要预留你的资源量   示例0.5  500m  内存 MI、GI2为底的MG(10为底的) 上限limits    内存超过limits大小就会报omm内存资源不足的错误  spec.containers[].resources.limits.cpu   #定义 cpu 的资源上限  spec.containers[].resources.limits.memory        #定义内存的资源上限 #pod容器能够使用资源量的一个上限  示例 4Gi内存上限 (不允许超过上限值) kubectl describe 名称#查看pod或者查看node资源使情况 k8s中的应用服务质量 可以用查看pod的详细信息 qos优先级 二、健康检查又称为探针Probe⭐⭐⭐⭐⭐ 健康检查又称为探针Probe 探针是由kubelet对容器执行的定期诊断 2.1探针的三种规则  总结 不提供存活探针默认为success表示如果没有存活探针的情况下都是认为探针成功正常的 在就绪探针中判断容器是否准备好接受请求表示pod是否准备好接受客户端和通过service转发来的请求 先启动启动探针——随后启动存活探针或者就绪探针 2.2Probe支持三种检查方法 exec 在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。tcpSocket 对指定端口上的容器的IP地址进行TCP检查三次握手。如果端口打开则诊断被认为是成功的。httpGet 对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400则诊断被认为是成功的 建议使用httpget和tcpsocket   2.3每次探测都将获得以下三种结果之一 成功容器通过了诊断。失败容器未通过诊断。未知诊断失败因此不会采取任何行动 官网示例 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 三、验证存活探针三大健康检查的方式 官网示例exec方式 apiVersion: v1 kind: Pod metadata:labels:test: livenessname: liveness-exec spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs: - /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60livenessProbe:exec:command:- cat- /tmp/healthyfailureThreshold: 1 initialDelaySeconds: 5periodSeconds: 5#initialDelaySeconds指定 kubelet 在执行第一次探测前应该等待5秒即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒最小值是 0。#periodSeconds指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。#failureThreshold: 当探测失败时Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。#timeoutSeconds探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。在 Kubernetes 1.20 版本之前exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行甚至可能超过所配置的限期直到返回结果为止。 在这个配置文件中可以看到 Pod 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时这个命令返回非 0 值kubelet 会杀死这个容器并重新启动它 随后自己写一个例子 apiVersion: v1 kind: Pod metadata:labels:test: livenessname: liveness-exec spec:containers:- name: livenessimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 15livenessProbe:exec:command:- cat- /tmp/healthyfailureThreshold: 2initialDelaySeconds: 5periodSeconds: 5 kubectl apply -f exec.yaml kubectl get pod -w 随后去查看pod的详细信息当82秒时检测存活探针失败kubelet便会删除pod随后重启pod kubectl describe pod liveness-exec 3.2httpget健康检查方式必不可少的时portpath路径 可以通过检测是否端口没有开启或者path路径下面的html页面是否存在 检验httpget 示例httpGet方式 apiVersion: v1 kind: Pod metadata:labels:test: livenessname: liveness-http spec:containers:- name: livenessimage: k8s.gcr.io/livenessargs:- /serverlivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3 在这个配置文件中可以看到 Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒则第4秒开始。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。kubelet 会向容器内运行的服务服务会监听 8080 端口发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码则 kubelet 会杀死这个容器并且重新启动它。 任何大于或等于 200 并且小于 400 的返回代码标示成功其它返回代码都标示失败。 apiVersion: v1 kind: Pod metadata:name: liveness-httpgetnamespace: default spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10 kubectl describe pod liveness-httpget 这里的重启 不是停止容器再次重启而是删除容器 再次启动!!!  3.3tcpsocket健康检查方式  指定端口号 示例tcpSocket方式 apiVersion: v1 kind: Pod metadata:name: goproxylabels:app: goproxy spec:containers:- name: goproxyimage: k8s.gcr.io/goproxy:0.1ports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20 这个例子同时使用 readinessProbe 和 livenessProbe 探测。kubelet 会在容器启动 5 秒后发送第一个 readinessProbe 探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功kubelet 将继续每隔 10 秒运行一次检测。除了 readinessProbe 探测这个配置包括了一个 livenessProbe 探测。kubelet 会在容器启动 15 秒后进行第一次 livenessProbe 探测。就像 readinessProbe 探测一样会尝试连接 goproxy 容器的 8080 端口。如果 livenessProbe 探测失败这个容器会被重新启动。 apiVersion: v1 kind: Pod metadata:name: probe-tcp spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10failureThreshold: 2 kubectl apply -f tcpsocket.yaml kubectl exec -it probe-tcp – netstat -natpkubectl describe pod probe-tcp #查看pod详细信息 重启原因因为nginx的端口是80而在yaml文件里面设置的tcpsocket的检测端口是8080 检测不到因此kubectl会杀死容器随后重启。  四、就绪探针 4.1就绪探针1 vim readiness-httpget.yaml apiVersion: v1 kind: Pod metadata:name: readiness-httpgetnamespace: default spec:containers:- name: readiness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10 kubectl apply -f readiness-httpget.yamlkubectl get pods 出现0/1 running 表示其中一个pod无法接受请求svc要在endpoints删除未请求的ip地址 kubectl describe pod readiness-httpget kubectl exec -it readiness-httpget sh cd /usr/share/nginx/html/ echo qin yu nian2 index1.html kubectl exec -it readiness-httpget – rm -rf /usr/share/nginx/html/index.html kubectl get pods -w完成启动探针成功以后、就绪和存活探针才会生效 就绪探针与存活探针  是在启动探针探测成功以后才会生效 4.2就绪检测2 apiVersion: v1 kind: Pod metadata:name: myapp1labels:app: myapp

spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10

apiVersion: v1 kind: Pod metadata:name: myapp2labels:app: myapp

spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10

apiVersion: v1 kind: Pod metadata:name: myapp3labels:app: myapp

spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10

apiVersion: v1 kind: Service metadata:name: myapp spec:selector:app: myapptype: ClusterIPports:- name: httpport: 80targetPort: 80 kubectl apply -f readiness-myapp.yamlkubectl get pod -owide -wkubectl get pods,svc,endpoints -owide 删除页面看效果 kubectl exec -it  myapp1 – rm -rf /usr/share/nginx/html/index.html kubectl get svc,pod,endpoints -owide readiness探测失败Pod 无法进入READY状态且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址  kubectl get pods -owide -w 恢复页面查看内容 4.3启动、退出动作 poststart 启动动作 prestop  推出动作 vim demo-pod02.yaml apiVersion: v1 kind: Pod metadata:name: lifecycle-demo spec:containers:- name: lifecycle-demo-containerimage: soscscs/myapp:v1lifecycle: #此为关键字段postStart:exec:command: [/bin/sh, -c, echo Hello from the postStart handler /var/log/nginx/message]preStop:exec:command: [/bin/sh, -c, echo Hello from the poststop handler /var/log/nginx/message]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falseinitContainers:- name: init-myserviceimage: soscscs/myapp:v1command: [/bin/sh, -c, echo Hello initContainers /var/log/nginx/message]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falsevolumes:- name: message-loghostPath:path: /data/volumes/nginx/log/type: DirectoryOrCreate kubectl apply -f demo-pod02.yaml kubectl get pods -owidekubectl exec -it lifecycle-demo – cat /var/log/nginx/message 在 node02 节点上查看 #由上可知init Container先执行然后当一个主容器启动后Kubernetes 将立即发送 postStart 事件。 删除 pod 后再在 node02 节点上查看 kubectl delete pod lifecycle-demonode02操作 cd /data/volumes/nginx/log/ cat message #由上可知当在容器被终结之前 Kubernetes 将发送一个 preStop 事件。  4.4验证启动探针、 就绪探针、存活探针的顺序 vim demo-pod03.yaml apiVersion: v1 kind: Pod metadata:labels:test: demo1name: demo1 spec:containers:- name: nginximage: soscscs/myapp:v1ports:- containerPort: 80name: http #设置存活探针探测pod容器的运行状态一旦探测失败那么就会通过kubelet杀掉容器livenessProbe:httpGet: #采用httpGet的方式 会像podip的指定端口发送http GET请求port: httppath: /index.html #做http健康检查的页面failureThreshold: 2 #表示连续探测失败2次才为探测失败initialDelaySeconds: 2 #表示初始等待2秒后再才是启动存活探针periodSeconds: 8 #表示探测周期为8秒 #设置就绪探针探测pod是否处于就绪状态如果说探测失败则为未就绪状态service会将其从关联的pod中删除请求也不转发给该podreadinessProbe:httpGet: #采用httpGet的方式 会像podip的指定端口发送http GET请求port: httppath: /index.html #做http健康检查的页面failureThreshold: 2 #表示连续探测失败2次才为探测失败initialDelaySeconds: 2 #表示初始等待2秒后再才是启动存活探针periodSeconds: 10 #表示探测周期为10秒 #启动探针为了探测容器应用是否处于运行状态只有启动探针探测成功以后就绪探针和存活探针才有效startupProbe:httpGet: #采用httpGet的方式 会像podip的指定端口发送http GET请求port: httppath: /index1.html #做http健康检查的页面failureThreshold: 3 #表示连续探测失败3次才为探测失败initialDelaySeconds: 2 #表示初始等待2秒后再才是启动存活探针periodSeconds: 15 #表示探测周期为15秒 kubectl apply -f demo-pod03.yamlkubectl describe pod demo1 kubectl get pods -owide -w 查看日志 可验证 就绪探针与存活探针  是在启动探针探测成功以后才会生效启动探针探测成功之后不会再运行接下来存活探针和就绪探针同时开始运行。 4.5k8s探针图解 五、 pod的状态 1、pendingpod已经被系统认可了但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间会持续一小段时间。 2、Runningpod已经与node绑定了调度成功而且pod中所有的container已经创建出来至少有一个容器在运行中或者容器的进程正在启动或者重启状态。–这里需要注意pod虽然已经Running了但是内部的container不一定完全可用。因此需要进一步检测container的状态。 3、Succeeded这个状态很少出现表明pod中的所有container已经成功的terminated了而且不会再被拉起了。 4、Failedpod中的所有容器都被terminated至少一个container是非正常终止的。退出的时候返回了一个非0的值或者是被系统直接终止 5、unknown由于某些原因pod的状态获取不到有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候需要进一步关注container的状态 六、Container生命周期 1、Waiting启动到运行中间的一个等待状态。 2、Running运行状态。 3、Terminated终止状态。 如果没有任何异常的情况下container应该会从Waiting状态变为Running状态这时容器可用。 但如果长时间处于Waiting状态container会有一个字段reason表明它所处的状态和原因如果这个原因很容易能标识这个容器再也无法启动起来时例如ContainerCannotRun整个服务启动就会迅速返回。这里是一个失败状态返回的特性不详细阐述 三种探针 存活探针livenessProbe探测Pod容器是否在正常运行。如果探测失败则kubelet杀掉容器并根据容器重启策略决定是否重启容器 就绪探针readinessProbe探测Pod是否进入就绪状态(ready状态栏是否100%比例)并做好接收service转发来的请求准备。 如果探测失败则Pod变成未就绪状态(0/1 ¹⁄₂)service就会删除相关联的Pod端点并不再转发请求给处于未就绪状态的Pod 启动探针startupProbe探测Pod容器内的应用进程是否启动成功。在启动探针探测成功之前存活探针和就绪探针都会处于暂停状态直到启动探针探测成功为止 如果探测失败则kubelet杀掉容器并根据容器重启策略决定是否重启容器 关于探针的3种探测方式 exec在容器里执行linux命令如果命令返回码为0则认为探测成功如果命令返回码为非0值则认为探测失败 httpGet向PodIP和指定的端口及URL路径发送HTTP GET请求如果HTTP响应状态码为2XX 3XX则认为探测成功如果HTTP响应状态码为4XX 5XX则认为探测失败 tcpSocket向PodIP和指定的端口发送TCP连接请求三次握手如果端口正确且TCP连接成功则认为探测成功如果TCP连接失败则认为探测失败 探针参数 initialDelaySeconds指定容器启动后延迟探测的时间单位为秒 periodSeconds指定每次探测的间隔时间 failureThreshold指定判定探测失败的连续失败次数 timeoutSeconds指定探测超时等待的时间 Pod容器的启动动作和退出动作lifecycle.postStart|preStoplifecycle与image字段同一层级 lifecycle.postStart      设置Pod容器启动时额外执行的操作此操作不会作为容器pid1的主进程 lifecycle.preStop        设置Pod容器被kubelet杀掉退出时执行的操作