如何优化企业网站以适应国际市场，特别是针对出国工作的需求？

出国做网站工作,企业网站宽度,网站怎样做权重,软件开发工程师就是程序员吗一、POD状态 Pod 常见的状态 Pending#xff1a;挂起#xff0c;我们在请求创建pod时#xff0c;条件不满足#xff0c;调度没有完成#xff0c;没有任何一个节点能满足调度条件。已经创建了但是没有适合它运行的节点叫做挂起#xff0c;这其中也包含集群为容器创建网络…一、POD状态 Pod 常见的状态 Pending挂起我们在请求创建pod时条件不满足调度没有完成没有任何一个节点能满足调度条件。已经创建了但是没有适合它运行的节点叫做挂起这其中也包含集群为容器创建网络或者下载镜像的过程。     RunningPod内所有的容器都已经被创建且至少一个容器正在处于运行状态、正在启动状态或者重启状态。     SucceededPod中所以容器都执行成功后退出并且没有处于重启的容器。 FailedPod中所以容器都已退出但是至少还有一个容器退出时为失败状态。 Unknown未知状态所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的如果节点之上的kubelet本身出故障那么apiserver就连不上kubelet得不到信息了就会看Unknown Pod重启策略 Always:      只要容器失效退出就重新启动容器。OnFailure:  当容器以非正常(异常)退出后才自动重新启动容器。Never:        无论容器状态如何都不重新启动容器。 如果pod的restartpolicy没有设置那么默认值是Always。 Pod常见状态转换场景 二、就绪、存活两种探针 K8S 提供了3种探针 readinessProbelivenessProbestartupProbe这个1.16版本增加的 探针介绍 在 Kubernetes 中 Pod 是最小的计算单元而一个 Pod 又由多个容器组成相当于每个容器就是一个应用应用在运行期间可能因为某也意外情况致使程序挂掉。那么如何监控这些容器状态稳定性保证服务在运行期间不会发生问题发生问题后进行重启等机制就成为了重中之重的事情考虑到这点 kubernetes 推出了活性探针机制。有了存活性探针能保证程序在运行中如果挂掉能够自动重启但是还有个经常遇到的问题比如说在Kubernetes 中启动Pod显示明明Pod已经启动成功且能访问里面的端口但是却返回错误信息。还有就是在执行滚动更新时候总会出现一段时间Pod对外提供网络访问但是访问却发生404这两个原因都是因为Pod已经成功启动但是 Pod 的的容器中应用程序还在启动中导致考虑到这点Kubernetes推出了就绪性探针机制。 1、livenessProbe livenessProbe存活性探针用于判断容器是不是健康如果不满足健康条件那么 Kubelet 将根据 Pod 中设置的 restartPolicy 重启策略来判断Pod 是否要进行重启操作。LivenessProbe按照配置去探测 ( 进程、或者端口、或者命令执行后是否成功等等)来判断容器是不是正常。如果探测不到代表容器不健康可以配置连续多少次失败才记为不健康则 kubelet 会杀掉该容器并根据容器的重启策略做相应的处理。如果未配置存活探针则默认容器启动为通过Success状态。即探针返回的值永远是 Success。即Success后pod状态是RUNING 2、readinessProbe readinessProbe 就绪性探针用于判断容器内的程序是否存活或者说是否健康只有程序(服务)正常 容器开始对外提供网络访问启动完成并就绪。容器启动后按照readinessProbe配置进行探测无问题后结果为成功即状态为 Success。pod的READY状态为 true从0/1变为1/1。如果失败继续为0/1状态为 false。若未配置就绪探针则默认状态容器启动后为Success。对于此pod、此pod关联的Service资源、EndPoint 的关系也将基于 Pod 的 Ready 状态进行设置如果 Pod 运行过程中 Ready 状态变为 false则系统自动从 Service资源 关联的 EndPoint 列表中去除此pod届时service资源接收到GET请求后kube-proxy将一定不会把流量引入此pod中通过这种机制就能防止将流量转发到不可用的 Pod 上。如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。kube-proxy也将有概率通过负载机制会引入流量到此pod中。 3、就绪、存活两种探针的区别 ReadinessProbe 和 livenessProbe 可以使用相同探测方式只是对 Pod 的处置方式不同 readinessProbe 当检测失败后将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。 livenessProbe 当检测失败后将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。 4、就绪、存活两种探针的使用方法 目前 LivenessProbe 和 ReadinessProbe 两种探针都支持下面三种探测方法 ExecAction在容器中执行指定的命令如果执行成功退出码为 0 则探测成功。 HTTPGetAction通过容器的IP地址、端口号及路径调用 HTTP Get方法如果响应的状态码大于等于200且小于400则认为容器 健康。 TCPSocketAction通过容器的 IP 地址和端口号执行 TCP 检 查如果能够建立 TCP 连接则表明容器健康。探针探测结果有以下值 Success表示通过检测。 Failure表示未通过检测。 Unknown表示检测没有正常进行。 LivenessProbe 和 ReadinessProbe 两种探针的相关属性 探针(Probe)有许多可选字段可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe)initialDelaySeconds容器启动后要等待多少秒后就探针开始工作单位“秒”默认是 0 秒最小值是 0 periodSeconds执行探测的时间间隔单位是秒默认为 10s单位“秒”最小值是 1 timeoutSeconds探针执行检测请求后等待响应的超时时间默认为 1s单位“秒”最小值是 1 successThreshold探针检测失败后认为成功的最小连接成功次数默认为 1s在 Liveness 探针中必须为 1s最小值为 1s。 failureThreshold探测失败的重试次数重试一定次数后将认为失败在 readiness 探针中Pod会被标记为未就绪默认为 3s最小值为 1s注initialDelaySeconds在readinessProbe其实可以不用配置不配置默认pod刚启动开始进行readinessProbe探测但那有怎么样除了 startupProbereadinessProbe、livenessProbe运行在pod的整个生命周期刚启动的时候readinessProbe检测失败了只不过显示READY状 态一直是0/1readinessProbe失败并不会导致重启pod只有startupProbe、livenessProbe失败才会重启pod。而等到多少s后真正服务启动 后检查success成功后READY状态自然正常 5、探针使用示例 5.1、LivenessProbe 探针使用示例 1、通过exec方式做健康探测 [rootlocalhost ~]# vi liveness-exec.yaml apiVersion: v1 kind: Pod metadata:name: liveness-execlabels:app: liveness spec:containers:- name: livenessimage: busyboxargs: #创建测试探针探测的文件- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:initialDelaySeconds: 10 #延迟检测时间periodSeconds: 5 #检测时间间隔exec: #使用命令检查command: #指令类似于运行命令sh- cat #sh 后的第一个内容直到需要输入空格变成下一行- /tmp/healthy #由于不能输入空格需要另外声明结果为sh cat空格/tmp/healthy # 解释整体意思 容器在初始化后执行/bin/sh -c touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600首先创建一个 /tmp/healthy 文件然后执行睡眠命令睡眠 30 秒到时间后执行删除 /tmp/healthy 文件命令。而设置的存活探针检检测方式为执行 shell 命令用 cat 命令输出 healthy 文件的内容如果能成功执行这条命令一次(默认successThreshold:1)存活探针就认为探测成功由于没有配置(failureThreshold、timeoutSeconds)所以执行cat /tmp/healthy并只等待1s如果1s内执行后返回失败探测失败。在前 30 秒内由于文件存在所以存活探针探测时执行 cat /tmp/healthy 命令成功执行。30 秒后 healthy 文件被删除所以执行命令失败Kubernetes 会根据 Pod 设置的重启策略来判断是否重启 Pod。 2、通过HTTP方式做健康探测 httpGet探测方式有如下可选的控制字段: scheme: 用于连接host的协议默认为HTTP。 host要连接的主机名默认为Pod IP可以在http request head中设置host头部。 port容器上要访问端口号或名称。 pathhttp服务器上的访问URI。 httpHeaders自定义HTTP请求headersHTTP允许重复headers。 [rootlocalhost ~]# vi liveness-http.yaml   # 通过httpGet访问url apiVersion: v1 kind: Pod metadata:name: liveness-httplabels:test: liveness spec:containers:- name: livenessimage: mydlqclub/springboot-helloworld:0.0.1livenessProbe:failureThreshold: 5 #检测失败5次表示未就绪initialDelaySeconds: 20 #延迟加载时间periodSeconds: 10 #重试时间间隔timeoutSeconds: 5 #超时时间设置successThreshold: 2 #检查成功为2次表示就绪httpGet:scheme: HTTPport: 8081path: /actuator/health # 解释整体意思 上面 Pod 中启动的容器是一个 SpringBoot 应用其中引用了 Actuator 组件提供了 /actuator/health 健康检查地址在pod启动后初始化等待20s后livenessProbe开始工作去请求HTTP://podIP:8081/actuator/health 接口类似于curl -I HTTP://podIP:8081/actuator/health接口,考虑到请求会有延迟(curl -I后一直出现假死状态)所以给这次请求操作一直持续5s如果5s内访问返回数值在200且400代表第一次检测success如果是其他的数值或者5s后还是假死状态执行类似ctrlc中断并反回failure失败。等待10s后再一次的去请求HTTP://podIP:8081/actuator/health接口。如果有连续的2次都是success代表无问题。如果期间有连续的5次都是failure代表有问题直接重启pod此操作会伴随pod的整个生命周期 通过自定义HTTP请求headers livenessProbe:failureThreshold: 5 #检测失败5次表示未就绪initialDelaySeconds: 20 #延迟加载时间periodSeconds: 10 #重试时间间隔timeoutSeconds: 5 #超时时间设置successThreshold: 2 #检查成功为2次表示就绪httpGet:port: 8080path: /healthhttpHeaders:- name: end-user- value: Jason 3、通过TCP方式做健康探测 [rootlocalhost ~]# vi liveness-tcp.yaml apiVersion: v1 kind: Pod metadata:name: liveness-tcplabels:app: liveness spec:containers:- name: livenessimage: nginxlivenessProbe:initialDelaySeconds: 15periodSeconds: 20tcpSocket:port: 80 # 解释整体意思 TCP 检查方式和 HTTP 检查方式非常相似在容器启动 initialDelaySeconds 参数设定的时间后kubelet 将发送第一个 livenessProbe 探针尝试连接容器的 80 端口类似于telnet 80端口如果连接失败则将杀死 Pod 重启容器。 5.2、ReadinessProbe 探针使用示例 (1)、Pod 的ReadinessProbe 探针使用方式和 LivenessProbe 探针探测方法一样也是支持三种只是一个是用于探测应用的存活一个是判断是否对外提供流量的条件。这里用一个 Springboot 项目设置 ReadinessProbe 探测 SpringBoot 项目的 8081 端口下的 /actuator/health 接口如果探测成功则代表内部程序以及启动就开放对外提供接口访问否则内部应用没有成功启动暂不对外提供访问直到就绪探针探测成功。顺便书写service资源查看调度规则。 [rootlocalhost ~]# vi readiness-exec.yaml apiVersion: v1 kind: Service metadata:name: springbootlabels:app: springboot spec:type: NodePortports:- name: serverport: 8080targetPort: 8080nodePort: 31180- name: managementport: 8081targetPort: 8081nodePort: 31181selector:app: springboot --- apiVersion: v1 kind: Pod metadata:name: springbootlabels:app: springboot spec:containers:- name: springbootimage: mydlqclub/springboot-helloworld:0.0.1ports:- name: servercontainerPort: 8080- name: managementcontainerPort: 8081readinessProbe:initialDelaySeconds: 20 periodSeconds: 5 timeoutSeconds: 10 httpGet:scheme: HTTPport: 8081path: /actuator/health (2)、ReadinessProbe LivenessProbe 配合使用示例 一般程序中需要设置两种探针结合使用并且也要结合实际情况来配置初始化检查时间和检测间隔下面列一个简单的 SpringBoot 项目的 Deployment 例子。 apiVersion: v1 kind: Service metadata:name: springbootlabels:app: springboot spec:type: NodePortports:- name: serverport: 8080targetPort: 8080nodePort: 31180- name: managementport: 8081targetPort: 8081nodePort: 31181selector:app: springboot --- apiVersion: apps/v1 kind: Deployment metadata:name: springbootlabels:app: springboot spec:replicas: 1selector:matchLabels:app: springboottemplate:metadata:name: springbootlabels:app: springbootspec:containers:- name: readinessimage: mydlqclub/springboot-helloworld:0.0.1ports:- name: server containerPort: 8080- name: managementcontainerPort: 8081readinessProbe:initialDelaySeconds: 20 periodSeconds: 5 timeoutSeconds: 10 httpGet:scheme: HTTPport: 8081path: /actuator/healthlivenessProbe:initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 httpGet:scheme: HTTPport: 8081path: /actuator/health (3)、注意terminationGracePeriodSeconds不能用于就绪态探针readinessProbe如果将它应用于readinessProbe将会被APIserver接口所拒绝 ---------------------------------- livenessProbe: httpGet:path: /healthzport: liveness-port failureThreshold: 1 periodSeconds: 60 terminationGracePeriodSeconds: 60 # 宽限时间60s ----------------------------------三、startupProbe探针 1、startupProbe探针介绍 k8s 在1.16版本后增加startupProbe探针主要解决在复杂的程序中readinessProbe、livenessProbe探针无法更好的判断程序是否启动、是否存活。进而引入startupProbe探针为readinessProbe、livenessProbe探针服务。 2、startupProbe探针与另两种区别 如果三个探针同时存在先执行startupProbe探针其他两个探针将会被暂时禁用直到pod满足startupProbe探针配置的条件其他2个探针启动如果不满足按照规则重启容器 另外两种探针在容器启动后会按照配置直到容器消亡才停止探测而startupProbe探针只是在容器启动后按照配置满足一次后不在进行后续的探测。 3、startupProbe探针方法、属性 startupProbe探针的使用方法跟 ReadinessProbe 和 livenessProbe 相同对 Pod 的处置跟livenessProbe 方式相同失败重启。 ExecAction在容器中执行指定的命令如果执行成功退出码为 0 则探测成功。 HTTPGetAction通过容器的IP地址、端口号及路径调用 HTTP Get方法如果响应的状态码大于等于200且小于400则认为容器 健康。 TCPSocketAction通过容器的 IP 地址和端口号执行 TCP 检 查如果能够建立 TCP 连接则表明容器健康。探针探测结果有以下值 Success表示通过检测。 Failure表示未通过检测。 Unknown表示检测没有正常进行。 startupProbe探针属性跟 ReadinessProbe 和 livenessProbe 相同 initialDelaySeconds容器启动后要等待多少秒后就探针开始工作单位“秒”默认是 0 秒最小值是 0 periodSeconds执行探测的时间间隔单位是秒默认为 10s单位“秒”最小值是 1 timeoutSeconds探针执行检测请求后等待响应的超时时间默认为 1s单位“秒”最小值是 1 successThreshold探针检测失败后认为成功的最小连接成功次数默认为 1s在 Liveness 探针中必须为 1s最小值为 1s。 failureThreshold探测失败的重试次数重试一定次数后将认为失败在 readiness 探针中Pod会被标记为未就绪默认为 3s最小值为 1s注在startupProbe执行完之后其他2种探针的所有配置才全部启动相当于容器刚启动的时候所以其他2种探针如果配置了initialDelaySeconds建议不要给太长 4、为什么要使用startupProbe、使用场景 思考startupProbe官方的解释可以定义一个启动探针该探针将推迟所有其他探针直到 Pod 完成启动为止startupProbe 启动探针存在的意义是不是 如果服务A启动需要1分钟 我们存活探针探测的时候设置的是initialDelaySeconds 10s后开始探测然后她探测的时候发现服务不正常然后就开始重启Pod陷入死循环但是如果意义在这个地方那我们可以把探测时间调整大一点failureThreshold 把这个也多设置几次就行了啊。 为什么还要单独的设置一个satrtupProbe呢 startupProbe的存在意义 startupProbe 和 livenessProbe 最大的区别就是startupProbe在探测成功之后就不会继续探测了而livenessProbe在pod的生命周期中一直在探测。 如果没有startupProbe探针的话我们只设置livenessProbe探针话会存在如下问题 一个服务如果前期启动需要很长时间那么它后面死亡未被发现的时间就越长为什么会这么说呢假设我们一个服务A启动完成需要2分钟那么我们如下开始定义livenessProbe livenessProbe:httpGet:path: /testprot: 80 failureThreshold: 1 initialDelay5 periodSeconds: 5 如果我们这样定义的话那pod 5s就会根据重启策略进行一次重启这个时候你会发现pod一直会陷入死循环那我们可以按照上面的猜想把配置改成这样 livenessProbe:httpGet:path: /testprot: 80 failureThreshold: 6 initialDelay40 periodSeconds: 5 你肯定会说你看这样不就行了吗这样的话pod就不会陷入死循环能启动起来了确实这样pod能够启动起来了但是你有没有考虑过这样一个问题当我们启动完成之后在后期的探测中你需要6*530s才能发现这个pod不可用这个时候你的服务已经停止运行了30s你才发现这在生产中有可能是不会被原谅的。 还有就是这边只是我们假设一个服务A需要1分钟才能起来但是在实际生产中你如何定义这些值呢 针对上面这两个问题引入startupProbe之后都解决了 livenessProbe:httpGet:path: /testprot: 80 failureThreshold: 1 initialDelay5 periodSeconds: 5startupProbe:httpGet:path: /testprot: 80 failureThreshold: 60 initialDelay5 periodSeconds: 5 我们这样设置之后由于startupProbe探针的存在程序有605s300s的启动时间一旦startupProbe探针探测成功之后就会被livenessProbe接管这样在运行中出问题livenessProbe就能在155s内发现。如果启动探测是3分钟内还没有探测成功则接受Pod的重启策略进行重启。